Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux
Kris2007
Sep 30 2010, 06:52
Собираю Linux из исходников с LSP под конкретный проц).
Исходники для dev-board. Плата для которой собираю очень похожа но не dev-board.

Вот такой вывод:

U-boot:
Код
U-Boot 1.1.4 (Sep 15 2010 - 16:55:08) Marvell version: 5.3.4_0012

U-Boot code: 01200000 -> 0128FFF0  BSS: -> 012A7E14
IRQ Stack: 009fff7c
FIQ Stack: 009fef7c

Soc: 88F6281 A0 (DDR2)
CPU running @ 333Mhz L2 running @ 166Mhz
SysClock = 0Mhz , TClock = 166Mhz

DRAM CAS Latency = 5 tRP = 4 tRAS = 15 tRCD=4
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
[16384kB@f8000000] Flash: 16 MB
Addresses 30M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (30M - 22M): Done

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX0 interface detected no Link.
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME], ppsdma
Hit any key to stop autoboot:  0
Marvell>> printenv
bootdelay=3
baudrate=115200
loads_echo=0
netmask=255.255.255.0
CASset=min
MALLOC_len=8
ethprime=egiga0
rootpath=/tftpboot/rootfs_arm-gnueabi
consoledev=ttyS0
linux_loadaddr=0x2000000
fix_nfsroot_to_BE=no
linux_parts=mtdparts=spi_flash:0x00100000(uboot)ro,0x001c0000(kernel),0x00d40000(rootfs)
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off console=$(consoledev),$(baudrate) $(othbootargs) $(linux_parts); tftp $(linux_loadaddr) $(image_name);bootm $(linux_loadaddr)
standalone_mtd=setenv bootargs root=/dev/mtdblock2 rw rootfstype=jffs2 ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off console=$(consoledev),$(baudrate) $(othbootargs) $(linux_parts); bootm 0xf8100000
netdev=eth0
image_name=uImage_xcat
vx_burn=mtdburn $(vx_image_name)
vx_image_name=vxWorks.st
vx=setenv bootargs mgi(0,0) host:VxWorks h=$(serverip) e=$(ipaddr):FFFF0000 u=anonymous pw=target; setenv bootaddr 0x700; setenv loadaddr 0x3000000; tftpboot $(loadaddr) $(vx_image_name); bootvx
vx_flash=setenv bootargs mgi(0,0) host:VxWorks h=$(serverip) e=$(ipaddr):FFFF0000 u=anonymous pw=target; setenv bootaddr 0x700; vx_unc_boot
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
ethaddr=00:50:43:5b:a9:a3
ethmtu=1500
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
serverip=192.168.0.20
ipaddr=192.168.0.88
bootargs=root=/dev/nfs rw nfsroot=192.168.0.20:/tftpboot/rootfs_arm-gnueabi ip=192.168.0.88:192.168.0.20::255.255.255.0::eth0:off console=ttyS0,115200 mtdparts=spi_flash:0x00100000(uboot)ro,0x001c0000(kernel),0x00d40000(rootfs)
filesize=13132c
fileaddr=2000000
ethact=egiga0
bootcmd=run standalone_mtd
stdin=serial
stdout=serial
stderr=serial
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
disaMvPnp=no
enaAutoRecovery=yes

Environment size: 2082/4092 bytes


Linux:
Код

Booting image at f8100000 ...
Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1252744 Bytes =  1.2 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Checking for Linux kernel endianess at 0xf8100040 = 0xe1a00000
Linux Kernel is LE

Starting kernel in LE mode ...
Uncompressing Linux...........................................................................
......... done, booting the kernel.
Linux version 2.6.22.18 (root@vechkanov1) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #6 Wed Sep 29 17:20:56 MSD 2010
CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053977
Machine: Feroceon-KW
Using UBoot passing parameters structure
BoardID from uboot=10
Memory policy: ECC disabled, Data cache writeback
calling iotable_init. MEM_TABLE=
  virt=0xef800000, phys=0x0f800000, lengh=0x00800000
  virt=0xe0000000, phys=0xe0000000, lengh=0x08000000
  virt=0xf1000000, phys=0xf1000000, lengh=0x00100000
  virt=0xf8000000, phys=0xf8000000, lengh=0x01000000
  virt=0xf4000000, phys=0xf4000000, lengh=0x04000000
  virt=0xfb000000, phys=0xfb000000, lengh=0x00010000
  virt=0xf2000000, phys=0xf2000000, lengh=0x00010000
Internal prestera id register = 0x000dc153
xCat revision = A1
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
Built 1 zonelists.  Total pages: 62992
Kernel command line: root=/dev/mtdblock2 rw rootfstype=jffs2 ip=192.168.0.88:192.168.0.20::255.255.255.0::eth0:off console=ttyS0,115200 mtdparts=spi_flash:0x00100000(uboot)ro,0x001c0000(kernel),0x00d40000(rootfs)
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 248MB 0MB 0MB 0MB = 248MB total
Memory: 248960KB available (2372K code, 214K data, 96K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16

CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 256MB
SDRAM_CS1 ....disable
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
PEX0_MEM ....base e8000000, size 128MB
PEX0_IO ....base fc000000, size   1MB
INTER_REGS ....base f1000000, size   1MB
NFLASH_CS ....base d8000000, size 128MB
SPI_CS ....base f8000000, size  16MB
BOOT_ROM_CS ....no such
DEV_BOOTCS ....no such
CRYPT_ENG ....base fb000000, size  64KB
SAGE_UNIT ....base f4000000, size  64MB
DRAGONITE_DTCM ....base f2000000, size  64KB

  Marvell Development Board (LSP Version KW_LSP_5.3.4_00018)-- DB-98DX4122-48G  Soc: 88F6281 A0 LE

Detected Tclk 166666667 and SysClk 0
Switch decoding windows init is done.
MV Buttons Device Load
PEX0 interface detected no Link.
PCI: bus0: Fast back to back transfers enabled
Time: kw_clocksource clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
Use the XOR engines (acceleration) for enhancing the following functions:
  o RAID 5 Xor calculation
  o kernel memcpy
  o kenrel memzero
Number of XOR engines to use: 2
MV Buttons Driver Load
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
serial8250.0: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
Loading Marvell Ethernet Driver:
  o Cached descriptors in DRAM
  o DRAM SW cache-coherency
  o Multi RX Queue support - 8 RX queues
  o Multi TX Queue support - 8 TX Queues
  o TCP segmentation offload enabled
  o Receive checksum offload enabled
  o Transmit checksum offload enabled
  o Network Fast Processing (Routing) supported
  o Driver ERROR statistics enabled
  o Driver INFO statistics enabled
  o Proc tool API enabled
  o Rx descripors: q0=64  q1=64  q2=64  q3=64  q4=64  q5=64  q6=64  q7=64
  o Tx descripors: q0=532 q1=532 q2=532 q3=532 q4=532 q5=532 q6=532 q7=532
  o Loading network interface(s):
    o eth0, ifindex = 28, GbE port = 0

Warning: Giga 1 is Forced Skipped Off

mvFpRuleDb (c052c000): 2048 entries, 8192 bytes
NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $
SPI Serial flash detected @ 0xf4000000, 16384KB (256sec x 64KB)
3 cmdlinepart partitions found on MTD device spi_flash
Creating 3 MTD partitions on "spi_flash":
0x00000000-0x00100000 : "uboot"
0x00100000-0x002c0000 : "kernel"
0x002c0000-0x01000000 : "rootfs"
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: started
IP-Config: Complete:
      device=eth0, addr=192.168.0.88, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.0.88, domain=, nis-domain=(none),
     bootserver=192.168.0.20, rootserver=192.168.0.20, rootpath=
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 96K
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.


И чешу в затылке... Linux не нашел init... А что делать то? Как выяснить почему?
kurtis
Sep 30 2010, 08:46
У вас рутфс точно есть? Я так понимаю что система пытается грузить рутфс с spi флешки, но по какой-то причине не находит. Может память затерли? Или забыли записать рутфс на флешку (или записали не по нужному адресу)?
Kris2007
Sep 30 2010, 09:08
Спасибо за ответ.
Думаю вы правы, во всяком случае я плохо понимаю откуда rootfs там возьмется.
В spi flash зашиваю u-boot от фирмы производителя чипов.
Дальше я гружу собранный образ Linux через TFTP.
Linux тож с LSP от производителя, но не факт что собран правильно.

А как сие можно исправить? Linux нужен rootfs из внешнего источника, сама из образа uImage она его грузить не может?
Я подобными вещами не занимался никогда до этого.
kurtis
Sep 30 2010, 14:26
Вы пытаетесь грузить рутфс по сети, может у вас в ядре отключена поддержка сети (nfs)? но это так,пальцем в небо...
Цитата
В spi flash зашиваю u-boot от фирмы производителя чипов.

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

Цитата
Linux тож с LSP от производителя, но не факт что собран правильно.

Конфиги где брали?
dch
Oct 1 2010, 02:58
У Вас флэш разбита на три партиции, рутфс должнабыть на третьей
0x002c0000-0x01000000 : "rootfs"
те начиная с такого смещения Вы должны прописать образ фс, командная строка
Kernel command line: root=/dev/mtdblock2 rw rootfstype=jffs2
задаёт где искать эту фс, уточните партиция называется как mtdblock2 или mtdblk2, у Вас устройство не находится.
Kris2007
Oct 1 2010, 07:22
А как прописать этот образ???
Собирается файл uImage(make uImage) и после mtdburn uImage и перезагрузки он грузится.
Распаковывается...
На spi_flash Linux при этом сама rootfs не записывает?

Думаю mtdblock2 именно, При смене на mtdblk2 следующий вывод:
Код
IP-Config: Complete:
      device=eth0, addr=192.168.0.89, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.0.89, domain=, nis-domain=(none),
     bootserver=192.168.0.20, rootserver=192.168.0.20, rootpath=
VFS: Cannot open root device "nfs" or unknown-block(0,255)
Please append a correct "root=" boot option; here are the available partitions:
1f00       1024 mtdblock0 (driver?)
1f01       1792 mtdblock1 (driver?)
1f02      13568 mtdblock2 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)



kurtis, а я из флеша гружусь, не по сети. Конфиги все от производителя, но т.к. плата другаю(и другая флеш) то могут быть нестыковки.
Я поправил код для spi_flash, т.е. добавил описание define-ов и.т.п. для впаянного spi_flash. Без него система стопилась при попытке опознать флеш ID.
Но правил очень аккуратно и думаю дело не в этом. Там много типов флеш возможно разных размеров и фирм, я добавил описание еще одной.
edo
Oct 2 2010, 06:44
Цитата(Kris2007 @ Oct 1 2010, 11:22) *
А как прописать этот образ???
Собирается файл uImage(make uImage) и после mtdburn uImage и перезагрузки он грузится.
Распаковывается...
На spi_flash Linux при этом сама rootfs не записывает?
операционную систему обычно можно представить как ядро + userspace.
ядро управляет процессами, памятью, устройствами.
userspace - это всевозможные приложения.

uImage - это ядро.
rootfs - это файловая система, которая будет смонтирована в "/" (root).

загрузка linux'а выглядит так:
- бутлоадер (u-boot например) грузит в память ядро и передаёт ему управление;
- ядро грузится
- ядро монтирует rootfs;
- ядро запускает init на rootfs.
init - это "главное" приложение, которое запускает остальные.

то есть Вам нужно озадачится созданием (или поиском) rootfs с init и (скорее всего) прочими приложениями wink.gif
dch
Oct 3 2010, 03:07
Цитата(Kris2007 @ Oct 1 2010, 11:22) *
На spi_flash Linux при этом сама rootfs не записывает?

Вы её прописывайте в u-boot-е командочкой
cp <адресс рам> <адрес смещение флэш> <количество байт>

Командочка flinfo должна показать Вам как u-boot видит флэши, и в частности разбивку их на сектора и по какому адресу
к ним можно обратиться. Обычно спи флэш с адреса C0000000 идёт для u-boot-а. Если в скобочках (RO) - это значит
сейктор реад онли, разблокировать их можно командочкой protect off
Kris2007
Oct 3 2010, 18:27
edu, да спасибо, этот процесс я так себе и представляю.
Тока вот где взять rootfs c файлами представляю плохо.

А причем здесь cp то? Не совсем понял. В RAM что ль rootfs скопировать? но откуда ее взять?
У меня есть spi_flash куда я гружу u-boot. Я могу его прописать программатором или обновить через TFTP как угодно. Больше микросхем памяти на плате нет. Была еще EPPROM с константами инициализации для платы, но их перенесли в spi_flash, и u-boot читает их оттуда(сторонние разработчики).
flinfo видит (пишу по памяти т.к. платы нет):
u-boot 0x000000
kernel 0x100000
rootfs 0x2c0000
Почему переменная linux_paths в uboot имеет другие значения не знаю (но возможно это и правильно - на конецы разделов указывает например)

Я так понимаю, я должен где-то взять rootfs с файлами и прописать его (программатором???) в spi_flash по адресу 2с0000? Так?
Но блин, где взять???)

У меня есть U-boot от фирмы,который инициализирует PHY и.т.п. и позволяет залить образ и.т.п., даж его исходники есть.
По адресам 2с0000 согласно файлу заливаемому программатором тока 0xffff и ничего больше.
У меня есть исходнки Linux+LSP от фирмы - из них я собираю uImage, заливаю его командой mtdburn uImage(видимо в RAM).

Вместе с Linux или U-boot собирается, ли что-нибудь из чего можно вытащить файловую систему rootfs? (Начал читать про mkfs т.е. про mkfs.jffs2)
Dron_Gus
Oct 4 2010, 07:12
Почитайте лучше про buildroot и bootstrap.
timm
Oct 4 2010, 12:57
Читайте лучше RTFS
linux-XXX/arch/ARCH/mach-XXXX/boards/XXXX.c
linux-XXX/arch/ARCH/kernel/vmlinux.lds.S
linux-XXX/Documentation/ARCH/*

Полезно также запустить 'make xconfig' и посмотреть какие опции загрузки предусмотрели для вас разработчики дистрибутива.

Сама по себе rootfs может быть либо образом файловой системы для флеши (1), либо для RAM-диска (2).

В случае 1 ее надо заливать на флешь в отдельный раздел.
В случае 2 ее обычно приклеивают к образу ядра, получая один загрузочный файл.

Если ваш uImage длиннее 1MB то он возможно включает в себя rootfs, а если короче - то едва ли.

Судя по вашиему журналу, ядро ищет корень во флеши:
Kernel command line: root=/dev/mtdblock2 rw rootfstype=jffs2

Флешь описана следующим образом:
mtdparts=spi_flash:0x00100000(uboot)ro,0x001c0000(kernel),0x00d40000(rootfs)

Это и есть таблица разделов. Вероятно она забита гвоздями где-то в коде инициализации платы
linux-XXX/arch/ARCH/mach-XXXX/boards/XXXX.c

и выглядит примерно так:

static struct mtd_partition XXX_partitions[] = {
{
.name = "uboot",
.size = 0x100000,
.offset = 0,
}, {
.name = "kernel",
.size = 0x1C0000,
.offset = MTDPART_OFS_APPEND,
}, {
.name = "rootfs",
.size = MTDPART_SIZ_FULL,
.offset = MTDPART_OFS_APPEND,
}
};

Обратите внимание, что никакой таблицы разделов в самой флеши нет.
Просто uboot и ядро прописывают у себя одинаковые физические адреса.

Так же нет и определенной привязки к чипам флеши: в том же драйвере платы
вызывается platform_add_devices() со списков ядерных драйверов и физ. адресов устройств.

Таким образом ядро от другой платы может искать корень на несуществующей флеши.

Строить файловую систему на SPI-флеши IMHO не стоит.
Значит нужен RAM-диск. Смотрите в сторону initrd, initramfs, cramfs...
И изучайте make xconfig: возможно, все ваши проблемы решатся одной метко поставленной галочкой.
Kris2007
Oct 6 2010, 08:30
Спасибо! Собрал rootfs и uImage в один образ, залил все загрузилось и как-то даж работает.
Но файловая система всеж на spi flash, насколько я понимаю из log. И на ихнем тож.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.