[vladimir_kh 0]

Глупости пишете. Как он у меня работает, если я строю ядро под другой процессор?

А файл 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 0]

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

Обсуждаем вроде как, почему странные вещи приходится писать, чтобы заработало. Я же 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 0]

Обсуждаем вроде как, почему странные вещи приходится писать, чтобы заработало. Я же 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 0]

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

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, надо будет поразмыслить как следует.

[sekil 0]

.

 

Привет!

 

Помоги пожалуйста :

Есть плата от starterkit с lpc1788 + sdram k4s561632N - не запускается UBOOT взятый с LPCware...

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

В файле в исходнике есть еще строчка не понятная -

Файл mem.c

/* Enable clock for EMC */

lpc17_clk_enable(LPC17_CLK_ADC, 1);

 

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

 

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

 

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

 

Как решить?

Изменено 3 октября, 2012 пользователем IgorKossak
бездумное цитирование