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

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

U-boot для этого ядра можно скачать в составе некоторых sdk, правда под специфичную платформу:

http://forum.openwrt.org/viewtopic.php?id=12290

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

Вот здесь http://www.voipac.com/downloads/pxa/270/dimm/src/linux/u-boot-1.1.2-vpac2.tar.gz
парни портировали (сильно обрезав) для PXA270

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

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

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

Во-первых, как определяется 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.

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

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


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

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

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

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

> на плате с которой я работал (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, и образ будет копироваться с нулевых адресов вверх до старших).

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

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

>Например, на моем чипе при ресете, и соответственно до ремапа, 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 и файл настроек линковщика должны быть сконфигурированы, чтобы работать из того последнего места в памяти где оно в конце концов окажется, а в начале кода может быть позиционно независимая часть на ассемлере котора перекинет весь оставшийся код в то место которые вы захотите использовать