cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
891 Views
Registered: ‎01-31-2018

UltraZed + IOCC: Why not booting from SD?

Jump to solution

SW2 is set correctly to boot from SD card (on-off-on-off 4:1)

The board is booting ok! and correctly finding the NFS root and using it.

 

But... the board is NOT using the BOOT.BIN and image.ub (kernel) of the SD card - it uses a DIFFERENT VERSION. No idea how it went there.

This drives me nuts!

 

Trying to solve, I was build from scratch the latest u-boot from Xilinx and the latest kernel from Xilinx, but it doesn't help because copying the final binaries into the SD card does nothing!

 

I was also following the instructions of this note without getting any improvement: note-69780

 

The boot log shows u-boot and kernel which I was building a few days ago, but it is not the one present in the SD card!

 

Here is my boot log:

 

Release 2017.2   Jul  1 2018  -  09:01:12

NOTICE:  ATF running on XCZU3EG/silicon v4/RTL5.1 at 0xfffea000, with PMU firmware

NOTICE:  BL31: Secure code at 0x0

NOTICE:  BL31: Non secure code at 0x8000000

NOTICE:  BL31: v1.3(release):0d9d51a

NOTICE:  BL31: Built : 05:57:48, Jul  1 2018

 

U-Boot 2017.01 (Jul 01 2018 - 08:59:03 +0300) Xilinx ZynqMP ZCU102 revB

 

I2C:   Error, wrong i2c adapter 0 max 0 possible

Error, wrong i2c adapter 0 max 0 possible

ready

DRAM:  2 GiB

EL Level:       EL2

Chip ID:        xczu3eg

MMC:   sdhci@ff160000: 0 (eMMC), sdhci@ff170000: 1 (SD)

SF: Detected n25q256a with page size 512 Bytes, erase size 128 KiB, total 64 MiB

Error, wrong i2c adapter 0 max 0 possible

Error, wrong i2c adapter 0 max 0 possible

In:    serial

Out:   serial

Err:   serial

Net:   ZYNQ GEM: ff0e0000, phyaddr 9, interface rgmii-id

eth0: ethernet@ff0e0000

U-BOOT for uz3eg-iocc-2017-2

 

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete.... done

BOOTP broadcast 1

DHCP client bound to address 192.168.1.105 (131 ms)

Hit any key to stop autoboot:  0 

Device: sdhci@ff160000

Manufacturer ID: 13

OEM: 14e

Name: Q2J55 

Tran Speed: 25000000

Rd Block Len: 512

MMC version 5.0

High Capacity: Yes

Capacity: 7.1 GiB

Bus Width: 8-bit

Erase Group Size: 512 KiB

HC WP Group Size: 8 MiB

User Capacity: 7.1 GiB WRREL

Boot Capacity: 16 MiB ENH

RPMB Capacity: 4 MiB ENH

reading image.ub

13336040 bytes read in 897 ms (14.2 MiB/s)

## Loading kernel from FIT Image at 10000000 ...

   Using 'conf@2' configuration

   Trying 'kernel@0' kernel subimage

     Description:  Linux Kernel

     Type:         Kernel Image

     Compression:  uncompressed

     Data Start:   0x100000d8

     Data Size:    13302272 Bytes = 12.7 MiB

     Architecture: AArch64

     OS:           Linux

     Load Address: 0x00080000

     Entry Point:  0x00080000

     Hash algo:    sha1

     Hash value:   4ebfca226a4bd90acd758d0d6e7949604574914d

   Verifying Hash Integrity ... sha1+ OK

## Loading fdt from FIT Image at 10000000 ...

   Using 'conf@2' configuration

   Trying 'fdt@0' fdt subimage

     Description:  Flattened Device Tree blob

     Type:         Flat Device Tree

     Compression:  uncompressed

     Data Start:   0x10cafbd0

     Data Size:    32461 Bytes = 31.7 KiB

     Architecture: AArch64

     Hash algo:    sha1

     Hash value:   3086a75754d02d6277ab1648e0e7e9d7b37f1da3

   Verifying Hash Integrity ... sha1+ OK

   Booting using the fdt blob at 0x10cafbd0

   Loading Kernel Image ... OK

   Loading Device Tree to 0000000007ff5000, end 0000000007fffecc ... OK

 

Starting kernel ...

 

[    0.000000] Booting Linux on physical CPU 0x0

[    0.000000] Linux version 4.9.0-xilinx-v2017.2 (osboxes@osboxes) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 8

[    0.000000] Boot CPU: AArch64 Processor [410fd034]

[    0.000000] earlycon: cdns0 at MMIO 0x00000000ff000000 (options '115200n8')

[    0.000000] bootconsole [cdns0] enabled

[    0.000000] efi: Getting EFI parameters from FDT:

[    0.000000] efi: UEFI not found.

[    0.000000] cma: Reserved 128 MiB at 0x0000000078000000

[    0.000000] psci: probing for conduit method from DT.

[    0.000000] psci: PSCIv1.0 detected in firmware.

[    0.000000] psci: Using standard PSCI v0.2 function IDs

[    0.000000] psci: MIGRATE_INFO_TYPE not supported.

[    0.000000] percpu: Embedded 21 pages/cpu @ffffffc077f7a000 s48152 r8192 d29672 u86016

[    0.000000] Detected VIPT I-cache on CPU0

[    0.000000] CPU features: enabling workaround for ARM erratum 845719

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 517120

[    0.000000] Kernel command line: earlycon clk_ignore_unused root=/dev/nfs nfsroot=192.168.1.111:/home/NFSShare,tcp ip=dhcp w

[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)

[    0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)

[    0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)

[    0.000000] Memory: 1920340K/2097152K available (9020K kernel code, 574K rwdata, 2828K rodata, 512K init, 395K bss, 45740K )

[    0.000000] Virtual kernel memory layout:

[    0.000000]     modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)

[    0.000000]     vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000   (   250 GB)

[    0.000000]       .text : 0xffffff8008080000 - 0xffffff8008950000   (  9024 KB)

[    0.000000]     .rodata : 0xffffff8008950000 - 0xffffff8008c20000   (  2880 KB)

[    0.000000]       .init : 0xffffff8008c20000 - 0xffffff8008ca0000   (   512 KB)

[    0.000000]       .data : 0xffffff8008ca0000 - 0xffffff8008d2fa00   (   575 KB)

[    0.000000]        .bss : 0xffffff8008d2fa00 - 0xffffff8008d926ac   (   396 KB)

[    0.000000]     fixed   : 0xffffffbefe7fd000 - 0xffffffbefec00000   (  4108 KB)

[    0.000000]     PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000   (    16 MB)

[    0.000000]     vmemmap : 0xffffffbf00000000 - 0xffffffc000000000   (     4 GB maximum)

[    0.000000]               0xffffffbf00000000 - 0xffffffbf01c00000   (    28 MB actual)

[    0.000000]     memory  : 0xffffffc000000000 - 0xffffffc080000000   (  2048 MB)

[    0.000000] Hierarchical RCU implementation.

[    0.000000]  Build-time adjustment of leaf fanout to 64.

[    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.

[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=4

[    0.000000] NR_IRQS:64 nr_irqs:64 0

[    0.000000] GIC: Adjusting CPU interface base to 0x00000000f902f000

[    0.000000] GIC: Using split EOI/Deactivate mode

[    0.000000] arm_arch_timer: Architected cp15 timer(s) running at 99.99MHz (phys).

[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x171015c90f, max_idle_ns: 440795203080 ns

[    0.000003] sched_clock: 56 bits at 99MHz, resolution 10ns, wraps every 4398046511101ns

[    0.008266] Console: colour dummy device 80x25

[    0.012525] console [tty0] enabled

[    0.015889] bootconsole [cdns0] disabled

 

Will appreciate any help!!

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
956 Views
Registered: ‎01-31-2018

OK guys,.

I have learned that there is a bug causing u-boot to show the wrong log.

But the kernel is correctly loaded from the SD card

 

 


On U-Boot log:

MMC:   sdhci@ff160000: 0 (eMMC), sdhci@ff170000: 1 (SD)

 

Also, on kernel log:

[    1.916662] mmc0: SDHCI controller on ff160000.sdhci [ff160000.sdhci] using ADMA 64-bit

[    1.972658] mmc1: SDHCI controller on ff170000.sdhci [ff170000.sdhci] using ADMA 64-bit

[    2.023288] mmc0: new HS200 MMC card at address 0001

[    2.023571] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB 

[    2.049315] mmc1: new high speed SDHC card at address aaaa

[    2.049553] mmcblk1: mmc1:aaaa SL08G 7.40 GiB 

 

 

Conclusion: 0 is eMMC, 1 is SD card.

 

The sequence of commands which loads the kernel is [[bootcmd]] > [[default_bootcmd]] > [[cp_kernel2ram]]

Let's take a close look at "cp_kernel2ram". It is doing stupid step of calling "mmcinfo" without first calling "mmc dev 0/1". It means that "mmcinfo" will always give info for the 0 device. Let's fix that and review the results.


selecting device "1" to load from SD, and making sure that mmcinfo dumps the correct device:

 

setenv cp_kernel2ram 'echo "[[cp_kernel2ram]]"; mmc dev 1 && mmcinfo && fatload mmc 1 ${netstart} ${kernel_img}'

 

[[cp_kernel2ram]]

switch to partitions #0, OK

mmc1 is current device

Device: sdhci@ff170000

Manufacturer ID: 3

OEM: 5344

Name: SL08G 

 

 

Ok! now I see the correct log, and indeed the image.ub is loaded from the SD card as expected, as pointed out by the note.

 

 

 

View solution in original post

0 Kudos
1 Reply
Highlighted
Observer
Observer
957 Views
Registered: ‎01-31-2018

OK guys,.

I have learned that there is a bug causing u-boot to show the wrong log.

But the kernel is correctly loaded from the SD card

 

 


On U-Boot log:

MMC:   sdhci@ff160000: 0 (eMMC), sdhci@ff170000: 1 (SD)

 

Also, on kernel log:

[    1.916662] mmc0: SDHCI controller on ff160000.sdhci [ff160000.sdhci] using ADMA 64-bit

[    1.972658] mmc1: SDHCI controller on ff170000.sdhci [ff170000.sdhci] using ADMA 64-bit

[    2.023288] mmc0: new HS200 MMC card at address 0001

[    2.023571] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB 

[    2.049315] mmc1: new high speed SDHC card at address aaaa

[    2.049553] mmcblk1: mmc1:aaaa SL08G 7.40 GiB 

 

 

Conclusion: 0 is eMMC, 1 is SD card.

 

The sequence of commands which loads the kernel is [[bootcmd]] > [[default_bootcmd]] > [[cp_kernel2ram]]

Let's take a close look at "cp_kernel2ram". It is doing stupid step of calling "mmcinfo" without first calling "mmc dev 0/1". It means that "mmcinfo" will always give info for the 0 device. Let's fix that and review the results.


selecting device "1" to load from SD, and making sure that mmcinfo dumps the correct device:

 

setenv cp_kernel2ram 'echo "[[cp_kernel2ram]]"; mmc dev 1 && mmcinfo && fatload mmc 1 ${netstart} ${kernel_img}'

 

[[cp_kernel2ram]]

switch to partitions #0, OK

mmc1 is current device

Device: sdhci@ff170000

Manufacturer ID: 3

OEM: 5344

Name: SL08G 

 

 

Ok! now I see the correct log, and indeed the image.ub is loaded from the SD card as expected, as pointed out by the note.

 

 

 

View solution in original post

0 Kudos