LINUX.ORG.RU
Форум — General  

Проблема с ядром

 , ,


0

2

Всем привет. Уже 4 день ломаю голову вот с какой проблемой Принесли на ремонт панель оператора от промышленной установке На борту проц Samsung ARM9 S3C2410, 64 мб озу и 16 мб NOR Flash Панелька мертвая, подключился в дебаг порт при влючении имеем такую картину: 

 
------------------
PPCBoot 2.0.0 (Nov 13 2008 - 15:14:46)

PPCBoot code: 33F00000 -> 33F15E48  BSS: -> 33F192DC
DRAM Configuration:
Bank #0: 30000000 64 MB
Flash Memory Start 0x0
Device ID of the Flash is 18
intel E28F128J3A150 init finished!!!
Flash: 16 MB
Write 18 to Watchdog and it is ff now
start linux now(y/n):## Booting image at 30008000 ...
copy kernel done
copy ramdisk done
Setup linux parameters at 0x30000100
cpu_arm920_cache_clean_invalidate_all finished
before call_linux
Uncompressing Linux.............................................................

crc error

 -- System halted

Далее...прервваю загрузку, попадаю в загрузчик. Команда iminfo ответ - bad magic number Была мысль что может быть проблема с ОЗУ, перепаял микросхемы местами, не помогло Прошивок нет, производитель на морозе, мол покупайте новую панель за овердохера денег.

Есть полный дамп флеши, но полностью мне расколупаль ее не удалось. Что можно придумать?



Последнее исправление: Debian (всего исправлений: 2)

Попробовать поискать такое-же ядро или похожий случай или собрать, но видимо глюк в зу или битое ядро или намеренное поведение.

Должны быть доступны средства сторонней отладки ядра, закгрузчика.

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

Ещё можно все электролиты поменять, АТО вдруг высохли.

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

Попробовать поискать такое-же ядро

= «попробуй найти такую же панель в рабочем состоянии и слить с нее ядро»

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

Как я понял, пзу и озу имеют единое адрессное пространство, например ядро лежит во флеше по адресу 0x00040000 а потом загрузчик копирует его по адресу 0x30008000 это уже область озу. Так вот если бы была битая ячейка в озу замена микросхем местами, благо их там всего две, проблему бы решила, но увы, не в озу дедо

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

возможно но!

я тут колупался в бинарнике считанном и в исходниках PPCboot 2.0.0 так вот из интернетоф 

Offset  into zImage	Value	Description
0x24	0x016F2818	Magic number used to identify this is an ARM Linux zImage
0x28	start address	The address the zImage starts at
0x2C	end address	The address the zImage ends at

смотрим в бинарник смещение 0x00400000

00 00 A0 E1 00 00 A0 E1 00 00 A0 E1 00 00 A0 E1 00 00 A0 E1 00 00 A0 E1 00 00 A0 E1 00 00 A0 E1 02 00 00 EA --->18 28 6F 01<--- 00 00 00 00 94 9E 0C 00

Попался!

а теперь самое интересное, смотрим исходник загрузчика

	/* Copy header so we can blank CRC field for re-calculation */
	memcpy (&header, (char *)addr, sizeof(image_header_t));
	
	if (ntohl(hdr->ih_magic) != IH_MAGIC) {
	    printf ("Bad Magic Number\n");
	    do_reset (cmdtp, flag, argc, argv);
	}

находим HI_MAGIC в image.h


#define IH_MAGIC	0x27051956	/* Image Magic Number		*/
#define IH_NMLEN		32	/* Image Name Length		*/

в бинарнике последовательность 0x27051956 встречается в 4х местах в то время, как 0x016F2818 встречается только один раз

по логике то если происходит операция сравнения продефайненного магического числа ядра с тем что имеется значит это число должно встречаться в бинарнике как минимум два раза верно?

я в дизасемблинге не силен если кто знает помогите подумать :)

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

А зачем сравнивать два зашитых в бинарь числа? Проверять целостность пары ячеек?

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