Цитата(PavelG @ Dec 7 2011, 21:13) 
Прочитав мануалы.
сама нанд флеш позволяет бутиться с нее?
Полная версия этой страницы: AM1705 первый запуск
сама нанд флеш позволяет бутиться с нее?
Цитата(am1808 @ Dec 7 2011, 20:15)
сама нанд флеш позволяет бутиться с нее?
А вот этот вопрос интересный... а разве не процессор инициализирует загрузку из Flash памяти?
По крайней мере в описание на Flash я ничего подобного не читал, но есть документ от fresscale, где они как раз рассказывают про загрузку boot'a из этой флешки.
Даже в документе от TI про Bootloader, где рассказывается про NAND, таких подробностей не указывается.
Цитата(PavelG @ Dec 7 2011, 21:25)
А вот этот вопрос интересный... а разве не процессор инициализирует загрузку из Flash памяти?
не каждая nand flash позволяет грузиться с нее.
по поводу вашей флешки и возможности грузиться с нее задайте вопрос на TI форуме
Цитата(am1808 @ Dec 7 2011, 21:37)
не каждая nand flash позволяет грузиться с нее.
Как то с ног на голову формулировка поставлена. Flash все равно, она и знать не знает, грузятся с нее, или еще что.
Другое дело, что bootloader процессора может не дружить с конкретной флеш, если она не ONFI-совместимая. Для такого случая в документации на загрузчик есть список поддерживаемых кристаллов.
Цитата(PavelG @ Dec 7 2011, 21:13)
От Samsung'а 32 Мбитная.
32 мегабита - это что-то ой как мало, ничего не путаете?
Цитата(am1808 @ Dec 7 2011, 21:02)
вечер добрый!
образовалась проблема с ethernet в u-boot.
используемая микросхема PHY KSZ8893MQL/MBL, схема подключения к AM1705 изменена по минимуму, не использую eeprom для хранения ethaddr и KSZ8893MQL/MBL соединена с процессором по i2c1, в отличии от референсной платы, где она висела на i2c0.
в юбуте настроил i2c1, поправил частоту шины i2c1, запись/чтение работают.
ethernet вроде бы поднимается после старта юбута, dhcp отрабатывает.
проблема в том, что пинги на любой хост в сети идут нестабильно, через раз пинг есть, и если заново сделать пинг на тот же хост, то юбут говорит, что хост уже недоступен. а на третий раз опять пинг есть и т.д. т.е. как то через раз ethernet в юбуте работает.
и не понятно, куда копать, что поправить?? кто нибудь сталкивался с подобной проблемой?
и да, при попытки через tftp загрузить ядро, то юбут грузит их кусками, один кусок uImage нормально загрузит в память, следующий уже не может, потом опять кусок загрузит и опять следующий уже не может загрузить. явно что то с ethernetом в юбуте что то не то, а куда копать - совершенно не понятно?
образовалась проблема с ethernet в u-boot.
используемая микросхема PHY KSZ8893MQL/MBL, схема подключения к AM1705 изменена по минимуму, не использую eeprom для хранения ethaddr и KSZ8893MQL/MBL соединена с процессором по i2c1, в отличии от референсной платы, где она висела на i2c0.
в юбуте настроил i2c1, поправил частоту шины i2c1, запись/чтение работают.
ethernet вроде бы поднимается после старта юбута, dhcp отрабатывает.
проблема в том, что пинги на любой хост в сети идут нестабильно, через раз пинг есть, и если заново сделать пинг на тот же хост, то юбут говорит, что хост уже недоступен. а на третий раз опять пинг есть и т.д. т.е. как то через раз ethernet в юбуте работает.
и не понятно, куда копать, что поправить?? кто нибудь сталкивался с подобной проблемой?
и да, при попытки через tftp загрузить ядро, то юбут грузит их кусками, один кусок uImage нормально загрузит в память, следующий уже не может, потом опять кусок загрузит и опять следующий уже не может загрузить. явно что то с ethernetом в юбуте что то не то, а куда копать - совершенно не понятно?
up
Цитата(aaarrr @ Dec 7 2011, 21:57)
Как то с ног на голову формулировка поставлена. Flash все равно, она и знать не знает, грузятся с нее, или еще что.
Другое дело, что bootloader процессора может не дружить с конкретной флеш, если она не ONFI-совместимая. Для такого случая в документации на загрузчик есть список поддерживаемых кристаллов.
Другое дело, что bootloader процессора может не дружить с конкретной флеш, если она не ONFI-совместимая. Для такого случая в документации на загрузчик есть список поддерживаемых кристаллов.
при загрузке с nand дело не в знании бута о том, какая флэш и что на ней, а в настройках соответствующего emiX контролера, который со стартовыми параметрами (подставленными по умолчанию) сможет обеспечить процессору доступ в nand память.
а вот про список собственно правильно
для AM1705 такими флэшками могут быть перечисленные в http://focus.ti.com/lit/an/spraba4b/spraba4b.pdf (Apendix B )
Цитата(am1808 @ Dec 7 2011, 20:02)
вечер добрый!
образовалась проблема с ethernet в u-boot.
используемая микросхема PHY KSZ8893MQL/MBL, схема подключения к AM1705 изменена по минимуму, не использую eeprom для хранения ethaddr и KSZ8893MQL/MBL соединена с процессором по i2c1, в отличии от референсной платы, где она висела на i2c0.
в юбуте настроил i2c1, поправил частоту шины i2c1, запись/чтение работают.
ethernet вроде бы поднимается после старта юбута, dhcp отрабатывает.
проблема в том, что пинги на любой хост в сети идут нестабильно, через раз пинг есть, и если заново сделать пинг на тот же хост, то юбут говорит, что хост уже недоступен. а на третий раз опять пинг есть и т.д. т.е. как то через раз ethernet в юбуте работает.
и не понятно, куда копать, что поправить?? кто нибудь сталкивался с подобной проблемой?
и да, при попытки через tftp загрузить ядро, то юбут грузит их кусками, один кусок uImage нормально загрузит в память, следующий уже не может, потом опять кусок загрузит и опять следующий уже не может загрузить. явно что то с ethernetом в юбуте что то не то, а куда копать - совершенно не понятно?
образовалась проблема с ethernet в u-boot.
используемая микросхема PHY KSZ8893MQL/MBL, схема подключения к AM1705 изменена по минимуму, не использую eeprom для хранения ethaddr и KSZ8893MQL/MBL соединена с процессором по i2c1, в отличии от референсной платы, где она висела на i2c0.
в юбуте настроил i2c1, поправил частоту шины i2c1, запись/чтение работают.
ethernet вроде бы поднимается после старта юбута, dhcp отрабатывает.
проблема в том, что пинги на любой хост в сети идут нестабильно, через раз пинг есть, и если заново сделать пинг на тот же хост, то юбут говорит, что хост уже недоступен. а на третий раз опять пинг есть и т.д. т.е. как то через раз ethernet в юбуте работает.
и не понятно, куда копать, что поправить?? кто нибудь сталкивался с подобной проблемой?
и да, при попытки через tftp загрузить ядро, то юбут грузит их кусками, один кусок uImage нормально загрузит в память, следующий уже не может, потом опять кусок загрузит и опять следующий уже не может загрузить. явно что то с ethernetом в юбуте что то не то, а куда копать - совершенно не понятно?
Проверьте частоту. Для RMII должна быть точно 50 МГц. Проверьте провод, и попробуйте поработать на скорости 10.
Цитата(aaarrr @ Dec 7 2011, 20:57)
Как то с ног на голову формулировка поставлена. Flash все равно, она и знать не знает, грузятся с нее, или еще что.
Другое дело, что bootloader процессора может не дружить с конкретной флеш, если она не ONFI-совместимая. Для такого случая в документации на загрузчик есть список поддерживаемых кристаллов.
32 мегабита - это что-то ой как мало, ничего не путаете?
Другое дело, что bootloader процессора может не дружить с конкретной флеш, если она не ONFI-совместимая. Для такого случая в документации на загрузчик есть список поддерживаемых кристаллов.
32 мегабита - это что-то ой как мало, ничего не путаете?
Да, Вы правы, 32 Мбайта. Сравнивал с табличкой, должна поддерживаться. И размер страницы меньше 4К.
Выяснилось, что во флешку ничего не пишится. Разбираюсь.
Цитата(PavelG @ Dec 9 2011, 17:23)
Выяснилось, что во флешку ничего не пишится. Разбираюсь.
ну тут варианта, как правило, 3и:
- сигналы ALE/CLE/CS (для первых двух надо правильно указать адрес, для последнего сконфигурить рег)
- еще есть рег в котором выбирается тип флэша и ширина шины (кажется 1 битом в нужный тип) - это где-то в настройках контроллера emi
- ошибки в реализации CFI. Дело в том, каким бы CFI общим не был - у каждой флэхи все равно есть отличия
Цитата(osipovvo @ Dec 10 2011, 23:39)
ну тут варианта, как правило, 3и
о них собственно тут : Нажмите для просмотра прикрепленного файла
Цитата(PavelG @ Dec 9 2011, 17:23)
Да, Вы правы, 32 Мбайта. Сравнивал с табличкой, должна поддерживаться. И размер страницы меньше 4К.
Выяснилось, что во флешку ничего не пишится. Разбираюсь.
Выяснилось, что во флешку ничего не пишится. Разбираюсь.
еще траблы возникнуть могут с правильным размаппиванием nand, лучше сравнить в исходниках структуру конкретной флеш с даташитом
да, еще на офиц. сайте TI на AM1705 обновились доки, можно там скачать полноценный даташит на AM1705, с полным описанием регов и периферии
Пока искал где в U-boot'е инициализируются регистры для асинхронной памяти возник вопрос. В исходниках нашел два варианта, на память с размером страницы 2кбита и 4кбита, у меня же страница в 512 бит, может ли быть проблема в этом?
PS
При выборе команды nand info, U-boot выводит, что подключена память с размером 32 Mib, напряжение 3,3В, 16k сектор. Так как все это определяется считыванием из флеша, как я понял, то получается проблема именно в работе с областью памяти где хранятся данные, а не с настройками регистров EMIFA?
PS
При выборе команды nand info, U-boot выводит, что подключена память с размером 32 Mib, напряжение 3,3В, 16k сектор. Так как все это определяется считыванием из флеша, как я понял, то получается проблема именно в работе с областью памяти где хранятся данные, а не с настройками регистров EMIFA?
У EMIF'а настроек как таковых минимум - тайминги, разрядность шины, возможность прогнать 1/4bit ECC.
U-boot может правильно идентифицировать память, но это отнюдь не значит, что он будет корректно с ней работать. А память в вашем случае несколько экзотическая.
U-boot может правильно идентифицировать память, но это отнюдь не значит, что он будет корректно с ней работать. А память в вашем случае несколько экзотическая.
приветствую всех!
у кого нибудь была проблема с запуском ядра без использования ubl?
я гружу ядро через rs232 по протоколу kermit
загрузка ядра и декомпрессия проходят удачно и после передачи управления ядра больше ничего не вижу.
процессор AM1705, использую UART2
о своей проблеме написал на http://e2e.ti.com/support/embedded/linux/f...579.aspx#560785
подскажите пожалуйста куда копать и в чем может быть проблема?
у кого нибудь была проблема с запуском ядра без использования ubl?
я гружу ядро через rs232 по протоколу kermit
загрузка ядра и декомпрессия проходят удачно и после передачи управления ядра больше ничего не вижу.
процессор AM1705, использую UART2
о своей проблеме написал на http://e2e.ti.com/support/embedded/linux/f...579.aspx#560785
подскажите пожалуйста куда копать и в чем может быть проблема?
IDs, как я понимаю, неоднократно проверяли. А с памятью точно все в порядке?
Цитата(aaarrr @ Dec 23 2011, 23:20)
IDs, как я понимаю, неоднократно проверяли. А с памятью точно все в порядке?
да, id проверил и на стороне юбута, и на стороне ядра, по крайней мере юбут передает ядру верный machid и при конфиге ядра такой же machid статически выставляется в исходниках.
с паматью, хм, вот тут не могу однозначно сказать.
юбут там работает, ядро тоже туда гружу, iminfo из юбута выдает правильную информацию, которую он берет из образа ядра, которое я загрузил в оперативку. поэтому, делаю вывод, что вроде память как нормально работает и нормально сконфигурирована в AISgene
Ну, чтобы быть уверенным, нужно бы ее всю проверить. А то вдруг реально работает 1/4 часть, например? Загрузить uboot и ядро хватит, а вот при распаковке все и упадет.
Цитата(aaarrr @ Dec 23 2011, 23:36)
Ну, чтобы быть уверенным, нужно бы ее всю проверить. А то вдруг реально работает 1/4 часть, например? Загрузить uboot и ядро хватит, а вот при распаковке все и упадет.
протестировал записью определенного числа так, что бы в цикле поочередно каждая адресная ножка поднималась.
потом считывал записанное число и оно было равно всегда тому значению, которое записал.
делал это из юбута путем добавления своей тестируемой функцией, ошибок не было.
как еще можно проверить полностью память?
Цитата(am1808 @ Dec 23 2011, 23:43)
протестировал записью определенного числа так, что бы в цикле поочередно каждая адресная ножка поднималась.
потом считывал записанное число и оно было равно всегда тому значению, которое записал.
делал это из юбута путем добавления своей тестируемой функцией, ошибок не было.
как еще можно проверить полностью память?
потом считывал записанное число и оно было равно всегда тому значению, которое записал.
делал это из юбута путем добавления своей тестируемой функцией, ошибок не было.
как еще можно проверить полностью память?
протестирую каждую ячейку памяти sdram.
если предположить, что с оперативкой все в порядке, куда можно еще смотреть, куда копать?
Цитата(am1808 @ Dec 23 2011, 23:45)
если предположить, что с оперативкой все в порядке, куда можно еще смотреть, куда копать?
Пока у меня больше идей нет.
Цитата(am1808 @ Dec 23 2011, 22:57)
загрузка ядра и декомпрессия проходят удачно и после передачи управления ядра больше ничего не вижу.
1 Включите в ядре поддержку early printk и смотрите лог загрузки. (Kernel hacking --->[*] Kernel debugging) - если есть поддержка early printk для этого процессора проблему с ID вы сразу обнаружите если она есть.
2 Проверьте - включена ли поддержка консоли для последовательного порта
3 Проверьте - в какой порт по умолчанию в ядре сконфигуирован вывод консоли.
4 память можно протестировать в u-boot - там есть простейший mtest.
К сожалению точные указания не могу дать по ядру - у TI они кастомные для каждого процессора.
Нажмите для просмотра прикрепленного файла
Цитата(sasamy @ Dec 24 2011, 02:39)
1 Включите в ядре поддержку early printk и смотрите лог загрузки. (Kernel hacking --->[*] Kernel debugging) - если есть поддержка early printk для этого процессора проблему с ID вы сразу обнаружите если она есть.
2 Проверьте - включена ли поддержка консоли для последовательного порта
3 Проверьте - в какой порт по умолчанию в ядре сконфигуирован вывод консоли.
4 память можно протестировать в u-boot - там есть простейший mtest.
К сожалению точные указания не могу дать по ядру - у TI они кастомные для каждого процессора.
Нажмите для просмотра прикрепленного файла
2 Проверьте - включена ли поддержка консоли для последовательного порта
3 Проверьте - в какой порт по умолчанию в ядре сконфигуирован вывод консоли.
4 память можно протестировать в u-boot - там есть простейший mtest.
К сожалению точные указания не могу дать по ядру - у TI они кастомные для каждого процессора.
Нажмите для просмотра прикрепленного файла
спасибо.
пункты 1,3,4 я проделывал, не помогло.
на счет поддержки консоли - попробую еще раз посмотреть, хотя по дефолту скорее всего с этим в порядке
еще вот можно как нибудь сделать, чтобы буффер консоли как можно раньше вывалился на последовательный порт?
если говорить про то, что ядро просто падает до инициализации консоли в ядре
Цитата(am1808 @ Dec 24 2011, 12:17)
еще вот можно как нибудь сделать, чтобы буффер консоли как можно раньше вывалился на последовательный порт?
если говорить про то, что ядро просто падает до инициализации консоли в ядре
если говорить про то, что ядро просто падает до инициализации консоли в ядре
Вы лучше лог загрузки от начала и до остановки покажите и выложите свой конфиг ядра. Еще я не помню - это не у вас 16М вместо 64M EVM распаяно ? при распаковке ядро может банально само себя затереть если имидж неправильно в RAM разместить.
Цитата(sasamy @ Dec 24 2011, 12:22)
Вы лучше лог загрузки от начала и до остановки покажите и выложите свой конфиг ядра. Еще я не помню - это не у вас 16М вместо 64M EVM распаяно ? при распаковке ядро может банально само себя затереть если имидж неправильно в RAM разместить.
нет, у меня на борде 32 MB оперативки.
конфиг ядра отличается только от дефолтного включением early_printk() и отключением NET я ядре для быстроты сборки и загрузки по терминалу ядра в плату (хотя и пробовал с поддержкой сети, результат тот же)
вот лог
U-Boot > loadb
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x0016c1f4 = 1491444 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1491380 Bytes = 1.4 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
еще хотел добавить, что я не использую ни initrd, ни rootfs.
тот же самый юбут и это же ядро через UartBootHost гружу на EVM1707, ядро запускается, лог загрузки ядра вываливается на терминал.
и для EVM1707 и для своей платы в параметре bootargs установлено mem=32M, хотя на EVM1707 фактически стоит 64 MB
Цитата(am1808 @ Dec 24 2011, 12:28)
нет, у меня на борде 32 MB оперативки.
конфиг ядра отличается только от дефолтного включением early_printk() и отключением NET я ядре для быстроты сборки и загрузки по терминалу ядра в плату (хотя и пробовал с поддержкой сети, результат тот же)
конфиг ядра отличается только от дефолтного включением early_printk() и отключением NET я ядре для быстроты сборки и загрузки по терминалу ядра в плату (хотя и пробовал с поддержкой сети, результат тот же)
Дайте прямой линк чтобы я мог скачать ваше ядро (или ссылку на сайт TI откуда скачивали). И какой там defconfig ? при первичной конфигурации вы там делали make ARCH=arm какой-то.defconfig
Цитата(sasamy @ Dec 24 2011, 12:42)
Дайте прямой линк чтобы я мог скачать ваше ядро (или ссылку на сайт TI откуда скачивали). И какой там defconfig ? при первичной конфигурации вы там делали make ARCH=arm какой-то.defconfig
могу выслать и исходный код ядра, и уже собранное ядро.
да, конфигурирую ядро под определенную конфигурацию вот так:
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- clean
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- da830_omapl137_defconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage
ядро: linux-03.20.00.12 из состава DaVinci-PSP-SDK-03.20.00.12, скаченного с офиц. сайта TI для AM1707
Цитата(am1808 @ Dec 24 2011, 12:48)
ядро: linux-03.20.00.12 из состава DaVinci-PSP-SDK-03.20.00.12, скаченного с офиц. сайта TI для AM1707
Скачал, посмотрел - с uart вроде все в порядке, из подозрительного - у вас сконфигурировано под am1707, у вас как я понял am1705 (нет LCD) а поддержка включена для LCD вместо NAND
Нажмите для просмотра прикрепленного файла
Цитата(sasamy @ Dec 24 2011, 16:01)
Скачал, посмотрел - с uart вроде все в порядке, из подозрительного - у вас сконфигурировано под am1707, у вас как я понял am1705 (нет LCD) а поддержка включена для LCD вместо NAND
спасибо,
да, я пробовал и с выбирать нанд вместо LCD, но это тоже не влияет
Цитата(am1808 @ Dec 24 2011, 16:11)
да, я пробовал и с выбирать нанд вместо LCD, но это тоже не влияет
Не пробовали отключать кеши ? это так - как жест отчаяния
Нажмите для просмотра прикрепленного файла
Цитата(sasamy @ Dec 24 2011, 16:38)
Не пробовали отключать кеши ? это так - как жест отчаяния
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
нет, не пробовал.
как то можно вывести буффер до start_kernel() и инициализации консоли?
Цитата(am1808 @ Dec 24 2011, 16:49)
как то можно вывести буффер до start_kernel() и инициализации консоли?
Поддержка вывода отладочной информации до инициализации консоли для davinci есть
arch/arm/mach-davinci/include/mach/debug-macro.S
так что ничего не мешает ее использовать, странно что вообще все молчит после распаковщика..
Я забыл сказать - вы добавили в параметры загрузки ядра в u-boot ?
bootargs console=ttyS2,115200n8 earlyprintk
bootargs console=ttyS2,115200n8 earlyprintk
Цитата(sasamy @ Dec 24 2011, 19:06)
Я забыл сказать - вы добавили в параметры загрузки ядра в u-boot ?
bootargs console=ttyS2,115200n8 earlyprintk
bootargs console=ttyS2,115200n8 earlyprintk
нет, такой аргумент не добавлял.
даже не знал, и нигде не написано про это
Цитата(am1808 @ Dec 24 2011, 19:10)
даже не знал, и нигде не написано про это
Да это я прошляпил - забыл сказать. Кстати напрямую в порт выводить символы есть ф-ции printascii, printch, printhex. Нпример в early_write
Код
static void early_write(const char *s, unsigned n)
{
while (n-- > 0) {
if (*s == '\n')
printch('\r');
printch(*s);
s++;
}
}
{
while (n-- > 0) {
if (*s == '\n')
printch('\r');
printch(*s);
s++;
}
}
arch/arm/kernel/debug.S
UPD Еще - чтобы проверить работоспособность earlyprintk можно намеренно неправильный MACH_ID передать из u-boot - если до загрузки ядра дело доходит и earlyprintk работает - должны увидеть как начальный загрузчик ядра заругается на неправильный MACH_ID. Вернее это даже раньше регистрации отладочной консоли сработает - через ф-ции printch пр. из arch/arm/kernel/debug.S
sasamy,
спасибо преогромное, как раз разбираю эти функции.
machid я намеренно передам другой из u-boot, в нем же выставлю правильные параметры для early_printk().
результат к сожалению смогу сказать только в понедельник.
скажите пожалуйста, до какого момента я могу использовать функции early_write(), printascii(), printch(), printhex()?
и еще такой момент,
я не использую ubl, при портировании u-boot были проблемы с выводом на консоль с его стороны, связанные с неправильной работой UART, помогла запись 0 в регистр MDR UART ( 16× over-sampling ). в драйверах ядра этот регистр никак не используется. Как то можно предположить, что проблемы с ядром связаны с регистром UART MDR?
спасибо преогромное, как раз разбираю эти функции.
machid я намеренно передам другой из u-boot, в нем же выставлю правильные параметры для early_printk().
результат к сожалению смогу сказать только в понедельник.
скажите пожалуйста, до какого момента я могу использовать функции early_write(), printascii(), printch(), printhex()?
и еще такой момент,
я не использую ubl, при портировании u-boot были проблемы с выводом на консоль с его стороны, связанные с неправильной работой UART, помогла запись 0 в регистр MDR UART ( 16× over-sampling ). в драйверах ядра этот регистр никак не используется. Как то можно предположить, что проблемы с ядром связаны с регистром UART MDR?
Цитата(am1808 @ Dec 24 2011, 20:30)
скажите пожалуйста, до какого момента я могу использовать функции early_write(), printascii(), printch(), printhex()?
Регистры периферии в kernel space всегда мапятся на определенные виртуальные адреса, в макросе проверяется, включен ли MMU
Код
.macro addruart, rx
mrc p15, 0, \rx, c1, c0
tst \rx, #1 @ MMU enabled?
moveq \rx, #0x01000000 @ physical base address
movne \rx, #0xfe000000 @ virtual base
mrc p15, 0, \rx, c1, c0
tst \rx, #1 @ MMU enabled?
moveq \rx, #0x01000000 @ physical base address
movne \rx, #0xfe000000 @ virtual base
так что до инита UART-ов в ядре должно все работать, а потом они уже в принципе и не нужны.
Цитата
запись 0 в регистр MDR UART ( 16Ч over-sampling ). в драйверах ядра этот регистр никак не используется. Как то можно предположить, что проблемы с ядром связаны с регистром UART MDR?
До инита UART-ов порт остается с настройками кототрые сделаны в u-boot так что до этого момента все равно должно что-то валиться в порт нормально, а там видно будет - проверьте сначала как работает early printk.
спасибо огромное,
в понедельник проверю и отпишусь
в понедельник проверю и отпишусь
Цитата(am1808 @ Dec 24 2011, 21:01)
в понедельник проверю и отпишусь
Есть еще один момент, начальный загрузчик может уходить в бесконечный цикл если включен вывод начальной отладки, в этих местах
Код
.macro waituart,rd,rx
#ifdef FLOW_CONTROL
1001: ldr \rd, [\rx, #UART_MSR << UART_SHIFT]
tst \rd, #UART_MSR_CTS
beq 1001b
#endif
#ifdef FLOW_CONTROL
1001: ldr \rd, [\rx, #UART_MSR << UART_SHIFT]
tst \rd, #UART_MSR_CTS
beq 1001b
#endif
Код
.macro busyuart,rd,rx
1002: ldr \rd, [\rx, #UART_LSR << UART_SHIFT]
and \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
teq \rd, #UART_LSR_TEMT | UART_LSR_THRE
bne 1002b
.endm
1002: ldr \rd, [\rx, #UART_LSR << UART_SHIFT]
and \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
teq \rd, #UART_LSR_TEMT | UART_LSR_THRE
bne 1002b
.endm
Так что имейте это ввиду. Например я бы вообще временно принудительно убрал управление потоком
#undef FLOW_CONTROL
ага, понял, спасибо.
а где лучше и рекомендательнее убрать FLOW_CONTROL ?
и еще вот не совсем понятно, в файле arch/arm/boot/compressed/head.S
есть по всей видимости отладка, которая спрятана под #ifdef DEBUG
никак не могу понять, где он определен, то ли через gcc передается, то ли где то статически забит или нет.
мне нужно задефайнить DEBUG или же нет? и где это лучше сделать?
и еще вот такой вопрос, как то можно включить фичу при сборке ядра, чтобы посмотреть на исходный модуль(файл) после препроцессора, например, через опцию -E gcc?
а где лучше и рекомендательнее убрать FLOW_CONTROL ?
и еще вот не совсем понятно, в файле arch/arm/boot/compressed/head.S
есть по всей видимости отладка, которая спрятана под #ifdef DEBUG
никак не могу понять, где он определен, то ли через gcc передается, то ли где то статически забит или нет.
мне нужно задефайнить DEBUG или же нет? и где это лучше сделать?
и еще вот такой вопрос, как то можно включить фичу при сборке ядра, чтобы посмотреть на исходный модуль(файл) после препроцессора, например, через опцию -E gcc?
Цитата(am1808 @ Dec 24 2011, 22:33)
а где лучше и рекомендательнее убрать FLOW_CONTROL ?
Прямо перед проверкой
#undef FLOW_CONTROL
#ifdef FLOW_CONTROL
Цитата
и еще вот такой вопрос, как то можно включить фичу при сборке ядра, чтобы посмотреть на исходный модуль(файл) после препроцессора, например, через опцию -E gcc?
Для файлов С совсем просто, например для arch/arm/kernel/dma.с
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/dma.i
Для ассемблера можно объектный файл дизассемблировать, например
arm-none-linux-gnueabi-objdump -d arch/arm/kernel/debug.o
Цитата(sasamy @ Dec 25 2011, 00:50)
Прямо перед проверкой
#undef FLOW_CONTROL
#ifdef FLOW_CONTROL
#undef FLOW_CONTROL
#ifdef FLOW_CONTROL
ясно, так и сделал. я к чему спросил, потому что вдруг какой то модуль тоже максрос этот подцепляет
Цитата(sasamy @ Dec 25 2011, 00:50)
Для файлов С совсем просто, например для arch/arm/kernel/dma.с
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/dma.i
Для ассемблера можно объектный файл дизассемблировать, например
arm-none-linux-gnueabi-objdump -d arch/arm/kernel/debug.o
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/dma.i
Для ассемблера можно объектный файл дизассемблировать, например
arm-none-linux-gnueabi-objdump -d arch/arm/kernel/debug.o
ага, ясно.
я так понимаю, в первом случае для целей с расширением i выполняется какая то шаблонная цель для препроцессинга?
еще раз спасибо большое!
Цитата(am1808 @ Dec 25 2011, 01:30)
я так понимаю, в первом случае для целей с расширением i выполняется какая то шаблонная цель для препроцессинга?
да - это такая отладочная "фича" в ядре, то же самое можно сделать чтобы посмотреть что сгенерировал компилятор
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/compat.s
итак, earlyprintk выручило.
ядро запускалось, и зависало вот где:
в чем причина - не понятно, исследование кода касаемо этой проблемы ни к чему не привело.
Но вот что интересно,
скачал последнюю версию ядра с kernel.org
собрал его с теми же опциями и все удачно!
ну плюс тут я грузил ФС через NFS, но ФС не влияет ни на что(я о проблеме выше)
вот лог:
в чем причина такого?
и по каким причинам калибровка не происходит?
ядро запускалось, и зависало вот где:
Код
U-Boot >
U-Boot > printenv
bootdelay=5
baudrate=115200
bootfile="uImage"
ethaddr=00:16:76:4e:64:da
bootcmd=bootm 0xC0700000
bootargs=console=ttyS2,115200n8 earlyprintk mem=32M
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.11 (Dec 09 2011 - 17:49:53)
Environment size: 234/16380 bytes
U-Boot > loadb
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x001eb588 = 2012552 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2012488 Bytes = 1.9 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.33-rc4 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 20
09q1-203) ) #2 PREEMPT Fri Dec 23 16:24:34 MSK 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA830/OMAP-L137/AM17xx EVM
Memory policy: ECC disabled, Data cache writethrough
DaVinci da830/omap-l137 rev2.0 variant 0x9
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS2,115200n8 earlyprintk mem=32M
bootconsole [earlycon0] enabled
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28268KB available (3736K code, 297K data, 140K init, 0K highmem)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop...
U-Boot > printenv
bootdelay=5
baudrate=115200
bootfile="uImage"
ethaddr=00:16:76:4e:64:da
bootcmd=bootm 0xC0700000
bootargs=console=ttyS2,115200n8 earlyprintk mem=32M
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.11 (Dec 09 2011 - 17:49:53)
Environment size: 234/16380 bytes
U-Boot > loadb
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x001eb588 = 2012552 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2012488 Bytes = 1.9 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.33-rc4 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 20
09q1-203) ) #2 PREEMPT Fri Dec 23 16:24:34 MSK 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA830/OMAP-L137/AM17xx EVM
Memory policy: ECC disabled, Data cache writethrough
DaVinci da830/omap-l137 rev2.0 variant 0x9
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS2,115200n8 earlyprintk mem=32M
bootconsole [earlycon0] enabled
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28268KB available (3736K code, 297K data, 140K init, 0K highmem)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop...
в чем причина - не понятно, исследование кода касаемо этой проблемы ни к чему не привело.
Но вот что интересно,
скачал последнюю версию ядра с kernel.org
собрал его с теми же опциями и все удачно!
ну плюс тут я грузил ФС через NFS, но ФС не влияет ни на что(я о проблеме выше)
вот лог:
Код
U-Boot > loadb
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x001b9f80 = 1810304 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-3.1.6
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1810240 Bytes = 1.7 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
mem.start: c0000000
mem.size: 2000000 bytes 32 MB
Starting kernel ...
debug: jump to c0008000 address
debug: start boot params address: c0000100
debug: data
debug: machID 1781
Uncompressing Linux... done, booting the kernel.
Linux version 3.1.6 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-
203) ) #5 PREEMPT Mon Dec 26 15:22:34 MSK 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA830/OMAP-L137/AM17x EVM
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writethrough
DaVinci da830/omap-l137 rev2.0 variant 0x9
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS2,115200n8 mem=32M noinitrd rw earlyprintk ip=1
92.168.2.144:192.168.2.87:192.168.0.1:255.255.240.0:uspd:eth0:bootp root=/dev/nf
s nfsroot=192.168.2.87:/home/xxx/Desktop/sdk_1_10_00_01/filesys,nolock
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28808k/28808k available, 3960k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xff000000 - 0xffe00000 ( 14 MB)
vmalloc : 0xc2800000 - 0xfea00000 ( 962 MB)
lowmem : 0xc0000000 - 0xc2000000 ( 32 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc032389c (3183 kB)
.init : 0xc0324000 - 0xc0346000 ( 136 kB)
.data : 0xc0346000 - 0xc0365e60 ( 128 kB)
.bss : 0xc0365e84 - 0xc038c24c ( 153 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
DaVinci: 128 gpio irqs
print_constraints: dummy:
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource timer0_0
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
msgmni has been set to 56
io scheduler noop registered (default)
start plist test
end plist test
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
console [ttyS2] enabled, bootconsole disabled
console [ttyS2] enabled, bootconsole disabled
brd: module loaded
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffff1
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver unknown
davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown
rtc-test rtc-test.0: rtc core: registered test as rtc0
rtc-test rtc-test.1: rtc core: registered test as rtc1
i2c /dev entries driver
cpuidle: using governor ladder
cpuidle: using governor menu
TCP cubic registered
NET: Registered protocol family 17
davinci_emac davinci_emac.1: using random MAC addr: 5e:8e:3f:87:58:15
console [netcon0] enabled
netconsole: network logging started
rtc-test rtc-test.0: setting system clock to 1970-01-01 00:00:02 UTC (2)
net eth0: no phy, defaulting to 100/full
IP-Config: Complete:
device=eth0, addr=192.168.2.144, mask=255.255.240.0, gw=192.168.0.1,
host=xxx, domain=, nis-domain=(none),
bootserver=192.168.2.87, rootserver=192.168.2.87, rootpath=
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 136K
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x001b9f80 = 1810304 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-3.1.6
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1810240 Bytes = 1.7 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
mem.start: c0000000
mem.size: 2000000 bytes 32 MB
Starting kernel ...
debug: jump to c0008000 address
debug: start boot params address: c0000100
debug: data
debug: machID 1781
Uncompressing Linux... done, booting the kernel.
Linux version 3.1.6 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-
203) ) #5 PREEMPT Mon Dec 26 15:22:34 MSK 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA830/OMAP-L137/AM17x EVM
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writethrough
DaVinci da830/omap-l137 rev2.0 variant 0x9
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS2,115200n8 mem=32M noinitrd rw earlyprintk ip=1
92.168.2.144:192.168.2.87:192.168.0.1:255.255.240.0:uspd:eth0:bootp root=/dev/nf
s nfsroot=192.168.2.87:/home/xxx/Desktop/sdk_1_10_00_01/filesys,nolock
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28808k/28808k available, 3960k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xff000000 - 0xffe00000 ( 14 MB)
vmalloc : 0xc2800000 - 0xfea00000 ( 962 MB)
lowmem : 0xc0000000 - 0xc2000000 ( 32 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc032389c (3183 kB)
.init : 0xc0324000 - 0xc0346000 ( 136 kB)
.data : 0xc0346000 - 0xc0365e60 ( 128 kB)
.bss : 0xc0365e84 - 0xc038c24c ( 153 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
DaVinci: 128 gpio irqs
print_constraints: dummy:
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource timer0_0
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
msgmni has been set to 56
io scheduler noop registered (default)
start plist test
end plist test
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
console [ttyS2] enabled, bootconsole disabled
console [ttyS2] enabled, bootconsole disabled
brd: module loaded
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffff1
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver unknown
davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown
rtc-test rtc-test.0: rtc core: registered test as rtc0
rtc-test rtc-test.1: rtc core: registered test as rtc1
i2c /dev entries driver
cpuidle: using governor ladder
cpuidle: using governor menu
TCP cubic registered
NET: Registered protocol family 17
davinci_emac davinci_emac.1: using random MAC addr: 5e:8e:3f:87:58:15
console [netcon0] enabled
netconsole: network logging started
rtc-test rtc-test.0: setting system clock to 1970-01-01 00:00:02 UTC (2)
net eth0: no phy, defaulting to 100/full
IP-Config: Complete:
device=eth0, addr=192.168.2.144, mask=255.255.240.0, gw=192.168.0.1,
host=xxx, domain=, nis-domain=(none),
bootserver=192.168.2.87, rootserver=192.168.2.87, rootpath=
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 136K
в чем причина такого?
и по каким причинам калибровка не происходит?
Цитата
Calibrating delay loop...
Скорей всего не работает системный таймер - прерывания не приходят от него, поэтому зацикливается.
Цитата
pr_info("Calibrating delay loop... ");
while ((loops_per_jiffy <<= 1) != 0) {
/* wait for "start of" clock tick */
ticks = jiffies;
while (ticks == jiffies)
/* nothing */;
while ((loops_per_jiffy <<= 1) != 0) {
/* wait for "start of" clock tick */
ticks = jiffies;
while (ticks == jiffies)
/* nothing */;
А вот почему не работает - это другой вопрос. Сравните инициализацию таймеров в старом и новом ядре, в старом она тут
arch/arm/mach-davinci/time.c
я не знаком с этим процессором, тут ничего не подскажу. Еще на рабочем ядре погоняйте на всякий случай мемтестер нормальный - то что в убуте не находит ошибок не дает 100% гарантии, там он слишком примитивный.
Цитата(sasamy @ Dec 26 2011, 23:07)
Еще на рабочем ядра погоняйте на всякий случай мемтестер нормальный - то что в убуте не находит ошибок не дает 100% гарантии, там он слишком примитивный.
извиняюсь, не совсем понял, а как же еще ячейки памяти проверить? разве не запись числа/чтение его и сравнение с записывемым, в юбуте реализовано именно так.
еще раз спасибо
Цитата(am1808 @ Dec 26 2011, 23:17)
извиняюсь, не совсем понял?
Ядро у вас есть рабочее - запустите memtester из-под Linux (есть например в составе buildroot), корневую в initramfs соберите, у меня какие смутные воспоминания остались что было такое из-за ошибок памяти, хотя я не уверен - для успокоения своего же потестируйте память
Цитата(sasamy @ Dec 26 2011, 23:24)
Ядро у вас есть рабочее - запустите там memtester (есть например в составе buildroot), корневую в initramfs соберите, у меня какие смутные воспоминания остались что было такое из-за ошибок памяти, хотя я не уверен - для успокоения своего же потестируйте память
спасибо
, для 100% уверенности, свой тестер напишу
Цитата(am1808 @ Dec 26 2011, 23:26)
спасибо , для 100% уверенности, свой тестер напишу
, для 100% уверенности, свой тестер напишу100% получить затруднительно. Как минимум прогоните длительно псевдослучайную последовательность и проверьте ground bounce.
Но и это не даст гарантии. Например, доработанный хавкборд замечательно проходит любые тесты памяти и работает под linux, но падает
буквально за секунды под WinCE.
В общем, если есть хоть малейшие подозрения на работу памяти - тестировать безжалостно. Потом будет меньше проблем "неясной этиологии".
Цитата(am1808 @ Dec 26 2011, 23:26)
спасибо , для 100% уверенности, свой тестер напишу
, для 100% уверенности, свой тестер напишуЕще гденибуть перед этим циклом распечатайте содержимое регистров контроллера прерываний, он там как раз незадолго до этого инициализируется
Цитата
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop...
Console: colour dummy device 80x30
Calibrating delay loop...
и проверьте - разрешено ли вообще прервание для таймера который там используется.
UPD все же непонятно - если это ядро работает на почти таком же процессоре но на другой плате - как оно там не зависает... и тут как раз такой ключевой момент - ожидание первого тика от таймера - это помоему первое переключение контекста в системе после старта, попробуйте все же кеши отключить, и еще в меню есть такой грозный пункт
тоже можно попробовать отключитьНажмите для просмотра прикрепленного файла
спасибо, завтра сравню регистры и конфиги для старого ядра.
сегодня весь день провел за программированием ФС в нанд.
все казалось бы делаю по инструкции, все вроде отрабатывает, а ядро при загрузке вот паникует и вываливает следующий лог:
bootargs=console=ttyS2,115200n8 mem=32M earlyprintk root=/dev/mtdblock0 rw rootfstype=jffs2 ip=off
корневую ФС базовую скачал с офиц. сайта.
распаковал и установил туда kernel headers and modules.
собирал jffs2.bin следующим образом:
# mkfs.jffs2 -p -d rootfs -s 2048 -e 0x20000 -l -q -o rootfs.jffs2 -v –n
NAND Organization:
– Page size x8: 2112 bytes (2048 + 64 bytes)
– Page size x16: 1056 words (1024 + 32 words)
– Block size: 64 pages (128K + 4K bytes)
– Device size: 1Gb: 1024 blocks
получившийся образ ФС я заливаю по терминалу в оперативку борды, затем делаю:
1. nand erase 0 0x08000000
2. nand write.jffs2 0xc0700000 0 $filesize
все удачно программируется, затем гружу ядро( NAND & JFFS2 включены при сборке ядра)
куда копать и что делать?
подскажите пожалуйста.
и еще, почему ядро первым делом пытается примонтировать ФС по NFS, когда я ему четко указал откуда брать корневую ФС?
сегодня весь день провел за программированием ФС в нанд.
все казалось бы делаю по инструкции, все вроде отрабатывает, а ядро при загрузке вот паникует и вываливает следующий лог:
Код
U-Boot > loadb
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x001d48c0 = 1919168 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-3.1.6
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1919104 Bytes = 1.8 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
mem.start: c0000000
mem.size: 2000000 bytes 32 MB
Starting kernel ...
debug: jump to c0008000 address
debug: start boot params address: c0000100
debug: data
debug: machID 1781
Uncompressing Linux... done, booting the kernel.
Linux version 3.1.6 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-
203) ) #10 PREEMPT Tue Dec 27 11:33:39 MSK 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA830/OMAP-L137/AM17x EVM
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writethrough
DaVinci da830/omap-l137 rev2.0 variant 0x9
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS2,115200n8 mem=32M earlyprintk ip=off root=/dev
/mtdblock0 rw rootfstype=jffs2
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28584k/28584k available, 4184k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xff000000 - 0xffe00000 ( 14 MB)
vmalloc : 0xc2800000 - 0xfea00000 ( 962 MB)
lowmem : 0xc0000000 - 0xc2000000 ( 32 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0358508 (3394 kB)
.init : 0xc0359000 - 0xc037a000 ( 132 kB)
.data : 0xc037a000 - 0xc039f080 ( 149 kB)
.bss : 0xc039f0a4 - 0xc03c40ac ( 149 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
DaVinci: 128 gpio irqs
print_constraints: dummy:
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource timer0_0
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
msgmni has been set to 55
io scheduler noop registered (default)
start plist test
end plist test
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
console [ttyS2] enabled, bootconsole disabled
console [ttyS2] enabled, bootconsole disabled
brd: module loaded
ONFI flash detected
ONFI param page 0 valid
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron MT29F1G08ABADAWP)
Creating 1 MTD partitions on "davinci_nand.1":
0x000000000000-0x000008000000 : "filesystem"
davinci_nand davinci_nand.1: controller rev. 2.5
spi_davinci spi_davinci.0: DMA: supported
spi_davinci spi_davinci.0: DMA: RX channel: 14, TX channel: 15, event queue: 0
spi_davinci spi_davinci.0: Controller at 0xfec41000
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffff1
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver unknown
davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown
rtc-test rtc-test.0: rtc core: registered test as rtc0
rtc-test rtc-test.1: rtc core: registered test as rtc1
i2c /dev entries driver
watchdog watchdog: heartbeat 60 sec
SoftDog: cannot register miscdev on minor=130 (err=-16)
cpuidle: using governor ladder
cpuidle: using governor menu
TCP cubic registered
NET: Registered protocol family 17
davinci_emac davinci_emac.1: using random MAC addr: d2:0d:54:78:68:1c
console [netcon0] enabled
netconsole: network logging started
rtc-test rtc-test.0: setting system clock to 1970-01-01 00:00:02 UTC (2)
Root-NFS: no NFS server address
VFS: Unable to mount root fs via NFS, trying floppy.
List of all partitions:
No filesystem could mount root, tried: jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[<c000d830>] (unwind_backtrace+0x0/0xf8) from [<c0284cd4>] (panic+0x60/0x1a8)
[<c0284cd4>] (panic+0x60/0x1a8) from [<c0359dcc>] (mount_block_root+0x1c8/0x224)
[<c0359dcc>] (mount_block_root+0x1c8/0x224) from [<c0359ea8>] (mount_root+0x80/0
xc8)
[<c0359ea8>] (mount_root+0x80/0xc8) from [<c0359ffc>] (prepare_namespace+0x10c/0
x1c8)
[<c0359ffc>] (prepare_namespace+0x10c/0x1c8) from [<c035928c>] (kernel_init+0xec
/0x12c)
[<c035928c>] (kernel_init+0xec/0x12c) from [<c0009c9c>] (kernel_thread_exit+0x0/
0x8)
BOOTME
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x001d48c0 = 1919168 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-3.1.6
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1919104 Bytes = 1.8 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
mem.start: c0000000
mem.size: 2000000 bytes 32 MB
Starting kernel ...
debug: jump to c0008000 address
debug: start boot params address: c0000100
debug: data
debug: machID 1781
Uncompressing Linux... done, booting the kernel.
Linux version 3.1.6 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-
203) ) #10 PREEMPT Tue Dec 27 11:33:39 MSK 2011
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DA830/OMAP-L137/AM17x EVM
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writethrough
DaVinci da830/omap-l137 rev2.0 variant 0x9
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
Kernel command line: console=ttyS2,115200n8 mem=32M earlyprintk ip=off root=/dev
/mtdblock0 rw rootfstype=jffs2
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 28584k/28584k available, 4184k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xff000000 - 0xffe00000 ( 14 MB)
vmalloc : 0xc2800000 - 0xfea00000 ( 962 MB)
lowmem : 0xc0000000 - 0xc2000000 ( 32 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0358508 (3394 kB)
.init : 0xc0359000 - 0xc037a000 ( 132 kB)
.data : 0xc037a000 - 0xc039f080 ( 149 kB)
.bss : 0xc039f0a4 - 0xc03c40ac ( 149 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:245
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
DaVinci: 128 gpio irqs
print_constraints: dummy:
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource timer0_0
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
msgmni has been set to 55
io scheduler noop registered (default)
start plist test
end plist test
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
console [ttyS2] enabled, bootconsole disabled
console [ttyS2] enabled, bootconsole disabled
brd: module loaded
ONFI flash detected
ONFI param page 0 valid
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron MT29F1G08ABADAWP)
Creating 1 MTD partitions on "davinci_nand.1":
0x000000000000-0x000008000000 : "filesystem"
davinci_nand davinci_nand.1: controller rev. 2.5
spi_davinci spi_davinci.0: DMA: supported
spi_davinci spi_davinci.0: DMA: RX channel: 14, TX channel: 15, event queue: 0
spi_davinci spi_davinci.0: Controller at 0xfec41000
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffff1
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver unknown
davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown
rtc-test rtc-test.0: rtc core: registered test as rtc0
rtc-test rtc-test.1: rtc core: registered test as rtc1
i2c /dev entries driver
watchdog watchdog: heartbeat 60 sec
SoftDog: cannot register miscdev on minor=130 (err=-16)
cpuidle: using governor ladder
cpuidle: using governor menu
TCP cubic registered
NET: Registered protocol family 17
davinci_emac davinci_emac.1: using random MAC addr: d2:0d:54:78:68:1c
console [netcon0] enabled
netconsole: network logging started
rtc-test rtc-test.0: setting system clock to 1970-01-01 00:00:02 UTC (2)
Root-NFS: no NFS server address
VFS: Unable to mount root fs via NFS, trying floppy.
List of all partitions:
No filesystem could mount root, tried: jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[<c000d830>] (unwind_backtrace+0x0/0xf8) from [<c0284cd4>] (panic+0x60/0x1a8)
[<c0284cd4>] (panic+0x60/0x1a8) from [<c0359dcc>] (mount_block_root+0x1c8/0x224)
[<c0359dcc>] (mount_block_root+0x1c8/0x224) from [<c0359ea8>] (mount_root+0x80/0
xc8)
[<c0359ea8>] (mount_root+0x80/0xc8) from [<c0359ffc>] (prepare_namespace+0x10c/0
x1c8)
[<c0359ffc>] (prepare_namespace+0x10c/0x1c8) from [<c035928c>] (kernel_init+0xec
/0x12c)
[<c035928c>] (kernel_init+0xec/0x12c) from [<c0009c9c>] (kernel_thread_exit+0x0/
0x8)
BOOTME
bootargs=console=ttyS2,115200n8 mem=32M earlyprintk root=/dev/mtdblock0 rw rootfstype=jffs2 ip=off
корневую ФС базовую скачал с офиц. сайта.
распаковал и установил туда kernel headers and modules.
собирал jffs2.bin следующим образом:
# mkfs.jffs2 -p -d rootfs -s 2048 -e 0x20000 -l -q -o rootfs.jffs2 -v –n
NAND Organization:
– Page size x8: 2112 bytes (2048 + 64 bytes)
– Page size x16: 1056 words (1024 + 32 words)
– Block size: 64 pages (128K + 4K bytes)
– Device size: 1Gb: 1024 blocks
получившийся образ ФС я заливаю по терминалу в оперативку борды, затем делаю:
1. nand erase 0 0x08000000
2. nand write.jffs2 0xc0700000 0 $filesize
все удачно программируется, затем гружу ядро( NAND & JFFS2 включены при сборке ядра)
куда копать и что делать?
подскажите пожалуйста.
и еще, почему ядро первым делом пытается примонтировать ФС по NFS, когда я ему четко указал откуда брать корневую ФС?
Кстати, попробовать отключить кэши на "неработающем" ядре - это весьма дельный совет. Если оно после этого начнет запускаться, значит с весьма высокой вероятностью ваша железка имеет проблемы с памятью. Я бы проверил, по крайней мере.
Цитата(aaarrr @ Dec 27 2011, 19:17)
Кстати, попробовать отключить кэши на "неработающем" ядре - это весьма дельный совет. Если оно после этого начнет запускаться, значит с весьма высокой вероятностью ваша железка имеет проблемы с памятью. Я бы проверил, по крайней мере.
да, спасибо,
для ядра 3.1.6 кеши точно отключены и пунк "Reset unusing clock during boot" включен.
завтра обращу внимание на ядро 2.6.34, которое TI поставляло к EVM1707
всем преогромное спасибо,
весь прикол был только в Reset unusing clock during boot, неободимо включить такой параметр.
с корневой фс вопрос решен
весь прикол был только в Reset unusing clock during boot, неободимо включить такой параметр.
с корневой фс вопрос решен
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.