помогите с u-boot lpc1788 Опции

[vladimir_kh]

Глупости пишете. Как он у меня работает, если я строю ядро под другой процессор?
А файл head.S есть в разных директориях. Я говорю о том, который в каталоге /arch/arm/boot/compressed. И там нет никаких head-nommu.

Если у Вас все работает, что мы тогда тут обсуждаем?

Если верить Вашему описанию выше, работает не все. В частности, Unaligned access exceptions в ядре возникать не должны. По крайней мере, мы в Emcraft Systems этого не наблюдаем ни на LPC1788, на на какой-либо из других Cortex-M3 / M4, которые мы поддерживаем.

Мы действительно добавили в ядро конфигурационную опцию, позволяющую отключать в ядре процессора генерацию Unaligned access exceptions, однако, назначение ее - заставить работать пользовательские приложения, которые по каким-то своим соображениям лезут в память по невыровненным адресам (код Qt/Embedded этим грешит, в частности). Использовать эту опция для того, чтобы обойти проблемы в ядре, я бы не стал; это лечение симптомов, а не проблемы. В лучшем случае, потеряете в производительности, в худшем - просто маскируете какую-то проблему.

По моему мнению, причины проблем, которые Вы наблюдаете что-то одно из нижеследующего (а может, комбинация этих факторов):

- неверная конфигурация ядра. Если работает код, предназначенный для другой конфигурации или даже для другого процессора, ничего хорошего не получится.

- не та версия toolchain. Код Emcraft Systems работает с конкретной версией GNU Toolchain. Мы пробовали более поздние версии, с ними возникли проблемы. Естественно, их тоже можно заставить работать, но пока не дошли руки.

- какая-то несовместимость с U-boot от NXP (lpcware.com). На самом деле, у нас есть клиент (тоже LPC1788), который тоже взял порт U-boot от lpcware (ему была нужна поддержка NAND Flash, а мы это пока не поддерживаем в U-boot для LPC1788), и он тоже видит похожие проблемы.

[andrewlekar]

Если у Вас все работает, что мы тогда тут обсуждаем?

Обсуждаем вроде как, почему странные вещи приходится писать, чтобы заработало. Я же emcraft не обвиняю - просто описываю, какие проблемы возникали и как я их решал.

По моему мнению, причины проблем, которые Вы наблюдаете что-то одно из нижеследующего (а может, комбинация этих факторов):

- неверная конфигурация ядра. Если работает код, предназначенный для другой конфигурации или даже для другого процессора, ничего хорошего не получится.

- не та версия toolchain. Код Emcraft Systems работает с конкретной версией GNU Toolchain. Мы пробовали более поздние версии, с ними возникли проблемы. Естественно, их тоже можно заставить работать, но пока не дошли руки.

- какая-то несовместимость с U-boot от NXP (lpcware.com). На самом деле, у нас есть клиент (тоже LPC1788), который тоже взял порт U-boot от lpcware (ему была нужна поддержка NAND Flash, а мы это пока не поддерживаем в U-boot для LPC1788), и он тоже видит похожие проблемы.

- ядро однозначно то самое.
- тулчейн G++ Lite 2011.03.46 uclinux, 2011.03.41 linux gnueabi, 2011.03.42 arm none.
- вот несовместимость с u-boot - это внезапно. Я думал, что u-boot тупо копирует софт и отдаёт управление и дальше никак не влияет (ну где-то environment передаёт ещё)... Но ваш u-boot крайне странно себя вёл, когда я его пытался запустить. То есть как есть он работал нормально, но при любых попытках что-то подправить, всё валилось со странными симптомами. Как-то смахивало на порченую память, что и не удивительно для софта заточенного под работу из внешней озу.

[vladimir_kh]

Обсуждаем вроде как, почему странные вещи приходится писать, чтобы заработало. Я же emcraft не обвиняю - просто описываю, какие проблемы возникали и как я их решал.

- ядро однозначно то самое.

Просто из любопытства, какой конфигурационный файл Вы используете для сборки ядра?

- тулчейн G++ Lite 2011.03.46 uclinux, 2011.03.41 linux gnueabi, 2011.03.42 arm none.

Emcraft Systems использует другую версию тулчейн. Я бы начал с того, чтобы перейти на эту версию, про которую известно, что с ней U-boot и Linux работают правильно.

- вот несовместимость с u-boot - это внезапно. Я думал, что u-boot тупо копирует софт и отдаёт управление и дальше никак не влияет (ну где-то environment передаёт ещё)... Но ваш u-boot крайне странно себя вёл, когда я его пытался запустить. То есть как есть он работал нормально, но при любых попытках что-то подправить, всё валилось со странными симптомами. Как-то смахивало на порченую память, что и не удивительно для софта заточенного под работу из внешней озу.

Наш порт U-boot работает из внутренней памяти (код из embedded Flash, данные и стек - в eSRAM).

Приятно знать, что как есть он все же работал нормально.

[andrewlekar]

Просто из любопытства, какой конфигурационный файл Вы используете для сборки ядра?

ea-lpc1788_defconfig

Emcraft Systems использует другую версию тулчейн. Я бы начал с того, чтобы перейти на эту версию, про которую известно, что с ней U-boot и Linux работают правильно.

Возможно из-за другой версии memcpy неверно обрабатывает невыровненный доступ к памяти...

В частности, падает с ошибкой невыровненного доступа вот на этом коде:

Код

int i;
__u32 hash[5], workspace[SHA_WORKSPACE_WORDS];
__u8 extract[64];
memcpy(out, hash, EXTRACT_SIZE);

Если поменять на:

Код

for(i = 0; i < EXTRACT_SIZE; i++)
{
   out[i] = (hash[i / 4] >> ((i % 4) * 4)) & 0xFF;
}

То в этом месте падать перестаёт.

Наш порт U-boot работает из внутренней памяти (код из embedded Flash, данные и стек - в eSRAM).

Я имел в виду, что софт изначально был заточен под релокацию.

Приятно знать, что как есть он все же работал нормально.

Точно не помню, в чём были проблемы, но, кажется, CONFIG_ALTMEMTEST вешал систему.

UPD: О чудо, сборка g++ lite 2010q1-189-arm-uclinuxeabi решила проблему с невыровненным доступом! Свежая версия g++ lite вероятно поломана. Насчёт того, какой u-boot использовать: стандартный или emcraft, надо будет поразмыслить как следует.

[Sekila]

.

Привет!

Помоги пожалуйста :
Есть плата от starterkit с lpc1788 + sdram k4s561632N - не запускается UBOOT взятый с LPCware...
Пробовал сам компилировать - такая же беда.. Может просто консоль не работает...
В файле в исходнике есть еще строчка не понятная -
Файл mem.c
/* Enable clock for EMC */
lpc17_clk_enable(LPC17_CLK_ADC, 1);

Разве клок на EMC включается через регистр ADC ?

Я так понял проблема в SDRAM, точнее в настройках задержек?

Emcraftовский запускается, но тест sdram не проходит((

Как решить?

Сообщение отредактировал IgorKossak - Oct 3 2012, 20:17

Причина редактирования: бездумное цитирование