LINUX.ORG.RU

портирование U-Boot


0

0

Приветствую,

обсуждение встраимаемых систем скорее off-topic, но я часто встречал здесь на форуме людей, занимающихся именно embedded. Портирую u-boot на arm926ejs-based платформу. Есть вопросы, поиски в рассылке u-boot, на electronix.ru и сырцах дают ответы не на все вопросы.

Может быть найдется тот/те, кто готовы здесь пообсуждать вопросы портирования/расширения u-boot?

anonymous

Как уже говорили тут - какая платформа ? На таком ядре микроконтроллеров ведро и маленькая тележка и наверняка уже есть что-то подобное. Под конкретную модель переписать не так сложно.

koTuk
()

от ЮБута как правило требуется, чтобы он подготавливал платформу к запуску Линукса. Например, он должен пообщаться с ПЛИСой на тему подачи питания/резета всяких контроллеров на плате. Проинициализировать специальные регистры процессора. Пообщаться с MMC (если он есть). Посветить светодиодами, что мол "всё ок". Сеть поднять (если надо). Ну а потом загрузить ядро с нужными параметрами...

xydo ★★
()
Ответ на: комментарий от fghj

Приветствую,

> ты конкретные вопросы задавай


Во-первых, как определяется memory map. Понятно, что нужно смотреть в даташите, но мне хотелось бы понять как, исходя из карты памяти, размещать в памяти u-boot. Судя по исходникам, образ грузится не с начала памяти, в младших адресах создается т.н. malloc-область и стек.

Во-вторых, как рассчитать размер malloc? На arm926ej-s бордах он инициализирцется по-разному: либо 128*1024 байт, либо (CFG_ENV_SIZE + 128*1024), где CFG_ENV_SIZE - "total size of environment sector" (цитата из сырцов) - очевидно, размер отводимый под хранение переменных u-boot? Но как размер флеш сектора может быть связан с malloc областью?

Третье - таймеры. Вроде как, uboot предоставляет свой интерфейс таймеров, который предлагается использовать во всех платформах (timer_init(), reset_timer() и т.д.). Как пользоваться этим интерфейсом и как адаптировать под свою платформу? Например, на базе таймеров пишется udelay().

> Как уже говорили тут - какая платформа ? На таком ядре микроконтроллеров

> ведро и маленькая тележка и наверняка уже есть что-то подобное.

> Под конкретную модель переписать не так сложно.

Имеющиеся платформы на предмет сходства я уже посмотрел, отобрал в качестве reference - Davinci, OMAP.

anonymous
()
Ответ на: комментарий от anonymous

>Судя по исходникам, образ грузится не с начала памяти, в младших >адресах создается т.н. malloc-область и стек.

на плате с которой я работал (at91sam9263ek, кстати ядро там тоже arm926ej-s) у меня он грузиться в последний мегабайт,
в config.mk доски указываешь TEXT_BASE и пишешь u-boot.lds
там расписываешь где код, где данные, где стек и т.д.


>Но как размер флеш сектора может быть связан с malloc областью?

для меня основное назначение u-boot скачать что-то (ядро, файловая система) и записать на флеш, соотвественно области оперативной памяти имеют непосредственно отношение к erase секторам флеш,
не знаю какие были идеи у авторов u-boot

>Третье - таймеры.
>и как адаптировать под свою платформу?

нужно реализовать свой udelay,
где-нибудь cpu/arm926ejs/твой_cpu/timer.c

fghj ★★★★★
()
Ответ на: комментарий от fghj

> на плате с которой я работал (at91sam9263ek, кстати ядро там тоже arm926ej-s) у меня он грузиться в последний мегабайт, > в config.mk доски указываешь TEXT_BASE и пишешь u-boot.lds > там расписываешь где код, где данные, где стек и т.д.

вопрос был в том, как определяется TEXT_BASE? Например, на моем чипе при ресете, и соответственно до ремапа, 0x0 указывает на NOR flash, RAM отмаплено на 0x1000_0000. Значит образ uboot нужно линковать по адресу 0x0 чтобы стартовать с флеш, т.е. TEXT_BASE = 0x0000000. Но если мы потом копируем образ uboot в RAM по адресу 0x10000000, то это работать не будет (ведь исходнный образ слинкован по адресу 0x0)? Если же сначала сделать ремап, т.е. RAM начинается с 0x0, и копировать образ в память, то не будет места для стека и malloc'a (ведь TEXT_BASE=0x0, и образ будет копироваться с нулевых адресов вверх до старших).

Надеюсь, понятно изложил? :)

Как быть в таком случае?

anonymous
()
Ответ на: комментарий от anonymous

>Например, на моем чипе при ресете, и соответственно до ремапа, 0x0 >указывает на NOR flash, RAM отмаплено на 0x1000_0000. Значит образ >uboot нужно линковать по адресу 0x0 чтобы стартовать с флеш, т.е. >TEXT_BASE = 0x0000000. Но если мы потом копируем образ uboot в RAM >по адресу 0x10000000, то это работать не будет (ведь исходнный образ >слинкован по адресу 0x0)? Если же сначала сделать ремап, т.е. RAM >начинается с 0x0, и копировать образ в память, то не будет места для >стека и malloc'a (ведь TEXT_BASE=0x0, и образ будет копироваться с >нулевых адресов вверх до старших).
>Надеюсь, понятно изложил? :)

не очень

>Как быть в таком случае?

пусть сделали remap настроили, mmu и еще куда-нибудь что-нибудь отобразили, потом еще перекопировали образ в третее место,

TEXT_BASE и файл настроек линковщика должны быть сконфигурированы, чтобы работать из того последнего места в памяти где оно в конце концов окажется, а в начале кода может быть позиционно независимая часть на ассемлере котора перекинет весь оставшийся код в то место которые вы захотите использовать

fghj ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.