I am currently working on a Linux distribution created with buildroot for an ARM device. The file system is JFFS2. I am booting with Das U-Boot.

I am able to successfully boot exactly once. My initial boot is successful and I am able to login to Linux and do things one would expect via command line. The second boot produces a kernel panic.

I have compared the Kernel memory before and after initial boot and it is exactly identical.

My conclusion is that something in the file system changes upon initial boot that causes a kernel panic.

Here is the relevant excerpt from my boot (I pasted extra to provide context of where the boot fails, but only the last six lines are likely important):

cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver ftdi_sio
usbserial: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver pl2303
usbserial: USB Serial support registered for pl2303
mousedev: PS/2 mouse device common for all mice
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
atmel_nand 40000000.nand: PMECC: Too many errors
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1): error -5
Please append a correct "root=" boot option; here are the available partitions:
1f00            8192 mtdblock0  (driver?)
1f01          253952 mtdblock1  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)

Uboot config My U-Boot printenv looks like this:

bootargs=mem=128M console=ttyS0,115200 mtdparts=atmel_nand:8M(bootstrap/uboot/kernel)ro,-(rootfs) root=/dev/mtdblock1 rw rootfstype=jffs2
bootcmd=nand read 0x22000000 0x200000 0x300000; bootm 0x22000000

So my question would be if someone could help me understand what would cause a second boot to fail where the first boot succeeds. Has anybody seen this? Maybe someone has experience with a similar situation that could at least point out what might be happening here.

P.S. I can provide additional information if needed. I am trying to abstract the details that are not important, but am more than willing to add more if it helps.

  • Have you specified the right root device? Isn't mtdblock0 for uboot, mtdblock1 ubootenv, mtdblock2 for the kernel and then the rootfs on another? – ott-- Mar 24 '15 at 22:10
  • Thank you for your inquiry, @ott. I updated the post with my U-Boot printenv. To answer your question, in this case mtdblock1 is the right mount point. This is why the first boot is successful. This printenv is actually a copy of Atmel's original bootargs, except I use jffs2 instead of ubi. – Terry Mar 25 '15 at 17:09

You can try put bootargs in read only:

bootargs=mem=128M console=ttyS0,115200 mtdparts=atmel_nand:8M(bootstrap/uboot/kernel)ro,-(rootfs) root=/dev/mtdblock1 ro rootfstype=jffs2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.