Problem while booting with uImage and xipImage

I am facing problem while booting with uImage and xipImage, please see following log:

1. I get following error message when I am trying to boot with uImage:

sh-rtc sh-rtc: setting system clock to 1970-01-01 00:00:00 UTC (0)
ALSA device list:
No soundcards found.
SQUASHFS error: unable to read id index table
List of all partitions:
1f00 57344 mtdblock0 (driver?)
No filesystem could mount root, tried: ext3 ext2 squashfs vfat msdos
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)
CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.28-ltsi #1
[<c0011b28>] (unwind_backtrace) from [<c00101a4>] (show_stack+0x10/0x14)
[<c00101a4>] (show_stack) from [<c0389f28>] (panic+0x70/0x1b8)
[<c0389f28>] (panic) from [<c047b0bc>] (mount_block_root+0x210/0x258)
[<c047b0bc>] (mount_block_root) from [<c047b1e0>] (mount_root+0xdc/0x100)
[<c047b1e0>] (mount_root) from [<c047b328>] (prepare_namespace+0x124/0x184)
[<c047b328>] (prepare_namespace) from [<c047acdc>] (kernel_init_freeable+0x170/0x1b4)
[<c047acdc>] (kernel_init_freeable) from [<c0388b90>] (kernel_init+0x8/0xe4)
[<c0388b90>] (kernel_init) from [<c000d598>] (ret_from_fork+0x14/0x3c)

2. I get following error message when I am trying to boot with xipImage:

=> run xsa_boot
SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
SF: 32768 bytes @ 0xc0000 Read: OK
Current Mode: Read Mode (3-byte Addr) (RZ/A1 reset value)
SF: Dual SPI mode
SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB

INFO: clock is now 22.22Mbps (see function enable_quad_micron)

New Mode: Quad I/O Read Mode (4-byte Addr)
Booting Linux...
undefined instruction
pc : [<1820c474>] lr : [<18200004>]
sp : 208b1c80 ip : 208b2db9 fp : 208b2dd8
r10: 209a7118 r9 : 208b1f08 r8 : 00000003
r7 : 208b2dc0 r6 : 0000009b r5 : e7df3c8e r4 : e7df3c4f
r3 : 2098a304 r2 : 0d800000 r1 : 00001388 r0 : 00000000
Flags: Nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...

resetting ...

NOTE: I am using SDRAM on CS3. I have modified u-boot address in xsa_boot and s_boot command. following is output of "printenv" command:

=> printenv
baudrate=115200
bootargs=console=ttySC3,115200
bootdelay=3
ipaddr=192.168.0.55
loadaddr=0x20000000
s1=sf probe 0; sf read 0D800000 C0000 8000
s2=sf probe 0:1; sf read 0D000000 100000 500000
s3=bootm start 0x0D000000 - 0x0D800000 ; bootm loados ;fdt memory 0x0C000000 0x02000000
s4=qspi dual
s_boot=run s1 s2 s3 s4; set bootargs ${sargs}; fdt chosen; bootm go
sargs=console=ttySC3,115200 console=tty0 ignore_loglevel root=/dev/mtdblock0 earlyprintk
serverip=192.168.0.1
stderr=serial
stdin=serial
stdout=serial
x1=sf probe 0; sf read 20500000 C0000 8000
x2=fdt addr 20500000 ; fdt memory 0x20000000 0x00A00000
x3=qspi dual
x_boot=run x1 x2 x3; set bootargs ${xargs}; fdt chosen; bootx 18200000 20500000
xa1=sf probe 0; sf read 20500000 C0000 8000
xa2=fdt addr 20500000 ; fdt memory 0x20000000 0x00A00000
xa3=qspi dual
xa_boot=run xa1 xa2 xa3; set bootargs ${xaargs}; fdt chosen; bootx 18200000 20500000
xaargs=console=ttySC3,115200 console=tty0 ignore_loglevel root=/dev/null rootflags=physaddr=0x18800000 earlyprintk
xargs=console=ttySC3,115200 console=tty0 ignore_loglevel root=/dev/mtdblock0 earlyprintk
xsa1=sf probe 0; sf read 0D800000 C0000 8000
xsa2=fdt addr 0D800000 ; fdt memory 0x0C000000 0x02000000
xsa3=qspi dual
xsa_boot=run xsa1 xsa2 xsa3; set bootargs ${xsaargs}; fdt chosen; bootx 18200000 0D800000
xsaargs=console=ttySC3,115200 console=tty0 ignore_loglevel root=/dev/null rootflags=physaddr=0x18800000 earlyprintk

Please suggest what may be causing the problem.

Thanks

  • For the squashfs issue, my guess is that you did not program in the entire image, or your mtd partition is too small for the image you programmed.

  • In reply to Chris:

    For the XIP boot issues, here's my comments:

    >   Booting Linux...

    >   undefined instruction

    >   pc : [<1820c474>] lr : [<18200004>]

    >   sp : 208b1c80 ip : 208b2db9 fp : 208b2dd8

    >   r10: 209a7118 r9 : 208b1f08 r8 : 00000003

    >   r7 : 208b2dc0 r6 : 0000009b r5 : e7df3c8e r4 : e7df3c4f

    >   r3 : 2098a304 r2 : 0d800000 r1 : 00001388 r0 : 00000000

    This is very early in boot since you LR (return from subroutine address) is only 4 bytes after the start of your xipImage, so your PC is probably in or at  __hyp_stub_install which is the first subroutine jump:

    lxr.free-electrons.com/.../head.S

    You can check your System.map file (created during build) and check the address.

    But, what that would mean is that the first QSPI access was good because you at least got valid instructions and the CPU knew to do the branch to the correct address.

    However....the QSPI fetches after that were not good...hence the "undefined instruction"

    So, unless you are using the exact same Spansion flash on the RSK board, you might have to take a look at the specification for the SPI flash you chose and see if you have to make any modifications to the XIP setup in u-boot. Remember, each SPI flash manufacture is different and even chips from the same manufacture  can be different, so you always have to go through and check that you have the correct number of dummy cycles, commands, etc...

    In u-boot, a good way to check is to run the command to set the RZ QSPI controller into XIP mode ( => qspi single  or => qspi dual ), then try to read the location where xipImage was programmed and see if it looks exactly the same as the binary file still on your host PC.

    for example, assuming dual QSPI XIP:

    (in u-boot)

    => qspi dual

    => md.b 0x18200000 100

    (on host pc)

    $ hexdump -C -n 100 xipImage

  • In reply to Chris:

    Thanks Chris

    Ill try above steps and will post the results.

    I am using MICRON flash on RSK board, I can see that RSK BSP V1.20 supports Spansion as well as MICRON Flash.

  • In reply to nikhilesh:

    As a side note:

    In u-boot, it shows that I added and tested support for a MICRON N25Q512A Quad-SPI device. That's a 512Mb (64M Byte) SPI Flash.

    The reason was that I got a hold of a board that someone made with a with N25Q512A devices on it.

    But....putting two 64MB SPI flashes for XIP makes no sense for RZ/A.

    The maximum XIP memory mapped window is 64MB, so that would be:

     1 x 64MB SPI flash

     2 x 32MB SPI flash

    So, a real product should not use two N25Q512A devices.

    The reason my board had a 2x64MB Micron Flashes (and the RSK board has 2x64MB Spansion flashes) is so customers can evaluate both single flash and dual flash configurations.

    I assume N25Q256A devices will work exactly same as the N25Q512A, but I've never confirmed.

    Chris

  • In reply to Chris:

    My board has two N25Q512A devices on it, and I am working in dual flash configuration.

    I am loading "UImage" and "squashfs" image in dual flash configuration.

    => sf probe 0:1

    SF: Dual SPI mode

    SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB

    for writing uImage to flash:

    => sf erase 100000 280000      

    => sf write 0x0C000000 100000 500000

    for writing  squashfs to flash:

    => sf erase 400000 1C00000

    => sf write  0x0C000000 400000 3800000

    To use single flash of 64MB do i need to make some changes to u-boot and kernel?

    Thanks

  • In reply to nikhilesh:

    > To use single flash of 64MB do i need to make some changes to u-boot and kernel?

    You do not have to make any code changes. You just:

    1. Program everything (u-boot, dtb, kernel, rootfs) into 1 SPI flash

    2. Change your boot sequence from "qspi dual" to "qspi single"

    NOTE: Your SPI addresses will be different because now you are only writing to 1 SPI flash.

    So, from your example above:

    # for writing 5MB uImage image to flash:

    => sf probe 0

    => sf erase 200000 500000

    => sf write 0x0C000000 200000 500000

    # for writing  56MB squashfs image to flash:

    => sf probe 0

    => sf erase 800000 3800000

    => sf write  0x0C000000 800000 3800000

    ## NOTE ##

    Now that I look at it, you are trying to program in a 56MB image.

    Meaning...if you only have 32MB of SDRAM on your board, you can't download a 56MB image to SDRAM with the Jlink to then be programmed into with u-boot.

    You have to split up your 56MB image into smaller images (that will fit into your SDRAM).

    You can use the Linux 'split' command to cut your file into smaller fixed sizes.

    For example, to split into 16M chunks:

    $ split -b 16M -d rootfs.squashfs rootfs.squashfs_

    Chris

  • In reply to Chris:

    Thanks Chris

    uImage:

    for uImage I will Program everything (u-boot, dtb, kernel, rootfs) into 1 SPI flash and will split up the sqashfs image if necessary. I will post the results.

    xipImage:

    > In u-boot, a good way to check is to run the command to set the RZ QSPI controller into XIP mode ( => qspi single  or => qspi dual ), then try to read the location where xipImage was programmed and see if it looks exactly the same as the binary file still on your host PC.

    > for example, assuming dual QSPI XIP:

    > (in u-boot)

    > => qspi dual

    > => md.b 0x18200000 100

    > (on host pc)

    > $ hexdump -C -n 100 xipImage

    For xipImage I tried reading location where xipImage was programmed and compared it with binary file on my host PC, both look exactly the same.

    here is the result for md.b and hexdump

    => qspi dual

    Current Mode: Read Mode (3-byte Addr) (RZ/A1 reset value)

    SF: Dual SPI mode

    SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB

    INFO: clock is now 22.22Mbps (see function enable_quad_micron)

    New Mode: Quad I/O Read Mode (4-byte Addr)

    => md.b 18200000 100

    18200000: 16 31 00 eb 00 90 0f e1 1a 90 29 e2 1f 00 19 e3    .1........).....

    18200010: 1f 90 c9 e3 d3 90 89 e3 04 00 00 1a 01 9c 89 e3    ................

    18200020: 0c e0 8f e2 09 f0 6f e1 0e f3 2e e1 6e 00 60 e1    ......o.....n.`.

    18200030: 09 f0 21 e1 10 9f 10 ee 35 01 00 eb 05 a0 b0 e1    ..!.....5.......

    18200040: 45 01 00 0a 02 82 a0 e3 4c 00 00 eb 05 00 00 eb    E.......L.......

    18200050: 0c d0 9f e5 04 e0 8f e2 04 80 a0 e1 10 f0 8a e2    ................

    18200060: 3b 00 00 ea 40 e8 3a bf 02 49 88 e2 01 49 44 e2    ;...@.:..I...ID.

    18200070: 04 00 a0 e1 00 30 a0 e3 01 69 80 e2 04 30 80 e4    .....0...i...0..

    18200080: 04 30 80 e4 04 30 80 e4 04 30 80 e4 06 00 30 e1    .0...0...0....0.

    18200090: f9 ff ff 1a 08 70 9a e5 a8 00 8f e2 68 00 90 e8    .....p......h...

    182000a0: 03 00 40 e0 00 50 85 e0 00 60 86 e0 25 5a a0 e1    ..@..P...`..%Z..

    182000b0: 26 6a a0 e1 05 3a 87 e1 05 31 84 e7 06 00 55 e1    &j...:...1....U.

    182000c0: 01 50 85 32 fa ff ff 3a 03 0a 84 e2 6c 60 9f e5    .P.2...:....l`..

    182000d0: 07 30 88 e1 26 69 84 e0 04 30 80 e4 01 36 83 e2    .0..&i...0...6..

    182000e0: 06 00 50 e1 fb ff ff 9a 0f 30 a0 e1 23 3a a0 e1    ..P......0..#:..

    182000f0: 03 3a 87 e1 bf 0d 84 e2 00 30 a0 e5 40 60 9f e5    .:.......0..@`..

    =>

    $ hexdump -C -n 256 xipImage.bin

    00000000  16 31 00 eb 00 90 0f e1  1a 90 29 e2 1f 00 19 e3  |.1........).....|

    00000010  1f 90 c9 e3 d3 90 89 e3  04 00 00 1a 01 9c 89 e3  |................|

    00000020  0c e0 8f e2 09 f0 6f e1  0e f3 2e e1 6e 00 60 e1  |......o.....n.`.|

    00000030  09 f0 21 e1 10 9f 10 ee  35 01 00 eb 05 a0 b0 e1  |..!.....5.......|

    00000040  45 01 00 0a 02 82 a0 e3  4c 00 00 eb 05 00 00 eb  |E.......L.......|

    00000050  0c d0 9f e5 04 e0 8f e2  04 80 a0 e1 10 f0 8a e2  |................|

    00000060  3b 00 00 ea 40 e8 3a bf  02 49 88 e2 01 49 44 e2  |;...@.:..I...ID.|

    00000070  04 00 a0 e1 00 30 a0 e3  01 69 80 e2 04 30 80 e4  |.....0...i...0..|

    00000080  04 30 80 e4 04 30 80 e4  04 30 80 e4 06 00 30 e1  |.0...0...0....0.|

    00000090  f9 ff ff 1a 08 70 9a e5  a8 00 8f e2 68 00 90 e8  |.....p......h...|

    000000a0  03 00 40 e0 00 50 85 e0  00 60 86 e0 25 5a a0 e1  |..@..P...`..%Z..|

    000000b0  26 6a a0 e1 05 3a 87 e1  05 31 84 e7 06 00 55 e1  |&j...:...1....U.|

    000000c0  01 50 85 32 fa ff ff 3a  03 0a 84 e2 6c 60 9f e5  |.P.2...:....l`..|

    000000d0  07 30 88 e1 26 69 84 e0  04 30 80 e4 01 36 83 e2  |.0..&i...0...6..|

    000000e0  06 00 50 e1 fb ff ff 9a  0f 30 a0 e1 23 3a a0 e1  |..P......0..#:..|

    000000f0  03 3a 87 e1 bf 0d 84 e2  00 30 a0 e5 40 60 9f e5  |.:.......0..@`..|

  • In reply to nikhilesh:

    > For xipImage I tried reading location where xipImage was programmed and compared it with binary file on my host PC, both look exactly the same.

     

    OK, then your image seems to be programmed correctly. And, it seems that it is reading it OK.

    I think the next step is to try and connect with GDB/J-Link and see what happens when you step through the code.

    Please have a look at the "AppNote: GDB Debugging for RZ/A1 Linux with J-Link" in the Files section:

    http://renesasrulz.com/renesas_forum_home/rz/m/mediagallery/2714.aspx

    You will see a section in there about how to debug the kernel very early in boot (before the MMU is turned on). Essentially, you can set a breakpoint at the very beginning of xipImage by doing this:

    (gdb) break *0x18200000

    (gdb) continue

    Unfortunately, getting a new "dual QSPI XIP" HW configuration working correctly is the hardest part of porting to a new board because not all SPI flash devices work the same.

    I might find my board with the MICRON N25Q512A parts on it and make sure the current u-boot/kernel still work on it.


    Chris

  • In reply to nikhilesh:

    Hi Nikhilesh,

    can you please tell me the procedures to enable uImage support in rz/a1h.

    if i use uImage will my rootfs(file system) become read/write.