News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

Bug report: Dual parallel QSPI read access in U-Boot does not work correctly

Started by timor.knudsen, February 01, 2019, 06:33:43 PM

Previous topic - Next topic

timor.knudsen

Not sure if this is a Trenz issue or Xilinx. Just want to ask if this behavior is already known.

I use TE703-05 together with TE0820-03-03EG SoM. Flashed firmware is default Trenz image 2018.2. CPLD Rev 4 for QSPI boot mode. Boot mode is QSPI32.

In u-boot, reading QSPI flash across 64 MiB boundary doesn't work, independent of flash beeing in linear mode or I/O mode.

You can simply reproduce the behavior with the mentioned hardware and default Trenz pre-built firmware and the following command sequence in u-boot:

ZynqMP> sf read ${netstart} 0x3fffff0 0x20

device 0 offset 0x3fffff0, size 0x20
SF: 32 bytes @ 0x3fffff0 Read: OK

ZynqMP> md ${netstart} 10

10000000: ffffffff ffffffff ffffffff ffffffff    ................
10000010: 14000000 14000000 14000000 14000000    ................
10000020: ffffffff ffffffff ffffffff ffffffff    ................
10000030: ffffffff ffffffff ffffffff ffffffff    ................


Reading across the 64 MiB boundary at 0x4000000 results in the value 0x14000000 beeing read. This is actually the content of the flash at address 0, e.g. the start of FSBL. Actually, the flash is empty at that address, which can be confirmed by reading from 0x4000000 directly (note that this transfer does not cross the 64 MiB boundary):


ZynqMP> sf read ${netstart} 0x4000000 0x20

device 0 offset 0x4000000, size 0x20
SF: 32 bytes @ 0x4000000 Read: OK

ZynqMP> md ${netstart} 10

10000000: ffffffff ffffffff ffffffff ffffffff    ................
10000010: ffffffff ffffffff ffffffff ffffffff    ................
10000020: ffffffff ffffffff ffffffff ffffffff    ................
10000030: ffffffff ffffffff ffffffff ffffffff    ................


We discovered this when trying to boot a huge 70 MiB FIT image from QSPI, which doesn't work when read in a single transfer. There is much more analysis that we conducted until we found this behavior, so please feel free to ask for more data or information.

Please let me know whether you think this is a Trenz-related issue or whether we should report this bug to Xilinx.

Thanks in advance!

JH

Hi,
i've ordered a 64MB variant to check this issue on my place. Until I get one, you can try out to check flash content with vivado. Create and write boot.bin with with your content into the flash and verify content with vivado. Can you tell me if verification works?

br
John

timor.knudsen

Hi John,
thank you very much for your answer! We have a 128 MiB variant of TE820, 64 MiB variant would not be enough to demonstrate this behavior.

Of course we tested the QSPI flash content. Vivado "verify" completes fine. Also, when booted to Linux, a


dd if=/dev/mtdblock1 of=/mnt/ramdisk/dump.bin


also retrieves the correct flash content.

JH

Hi,
Quotei've ordered a 64MB variant to check this issue on my place.
Sorry my mistake. I mean, I've ordered 128MB(2x64). I've 64MB(2x32) on place.

I've tested the 64MB(2x32) with Vivado 18.3(I prepare new designs at the moment) now. It seems to work with this size.
So it's like you also find out, that this is not reproducible with the 64MB(2x32) version.

But when Vivado and linux can load it correctly, it seems to be only a problem with petalinux 2018.2 uboot.
I will come back to you when I've checked it with a 128MB version.

br
John

JH

Hi,
I've tried out with Vivado/Petalinux 2018.3 and it seems that it works there.
I wrote Boot.bin with image.ub on 0x4000000 and start linux manually.


U-Boot 2018.01 (Jan 29 2019 - 10:59:41 +0000) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  1023 MiB
EL Level:       EL2
Chip ID:        zu4cg
MMC:   Card did not respond to voltage select!
mmc_init: -95, time 27
mmc@ff170000 - probe failed: -95
mmc@ff160000: 0 (eMMC)Card did not respond to voltage select!
mmc_init: -95, time 28

SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
*** Warning - bad CRC, using default environment

In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Board: Xilinx ZynqMP
Bootmode: QSPI_MODE
Net:   ZYNQ GEM: ff0e0000, phyaddr ffffffff, interface rgmii-id
Error, wrong i2c adapter 1 max 1 possible

Warning: ethernet@ff0e0000 using MAC address from ROM
eth0: ethernet@ff0e0000
U-BOOT for petalinux

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete..... done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.150.126 (1759 ms)
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
mmc_init: -95, time 27
** Bad device mmc 1 **
Device: mmc@ff160000
Manufacturer ID: 13
OEM: 14e
Name: Q2J54
Tran Speed: 200000000
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 16 MiB ENH
RPMB Capacity: 512 KiB ENH
Card did not respond to voltage select!
mmc_init: -95, time 27
** Bad device mmc 1 **
ZynqMP>  sf probe
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
ZynqMP>  sf read ${netstart} 0x4000000 0x1000000
device 0 offset 0x4000000, size 0x1000000
SF: 16777216 bytes @ 0x4000000 Read: OK
ZynqMP>  md ${netstart} 100
10000000: edfe0dd0 284bcf00 38000000 3447cf00    ......K(...8..G4
10000010: 28000000 11000000 10000000 00000000    ...(............
10000020: 74000000 fc46cf00 00000000 00000000    ...t..F.........
10000030: 00000000 00000000 01000000 00000000    ................
10000040: 03000000 04000000 64000000 3e35505c    ...........d\P5>
10000050: 03000000 54000000 00000000 6f422d55    .......T....U-Bo
10000060: 6620746f 6d497469 20656761 20726f66    ot fitImage for
10000070: 61746550 756e694c 2e342f78 782d3431    PetaLinux/4.14-x
10000080: 6e696c69 32762d78 2e383130 69672b33    ilinx-v2018.3+gi
10000090: 54554174 434e494f 6165652b 64333762    tAUTOINC+eeab73d
100000a0: 2f303231 786e6c70 6e797a2d 00706d71    120/plnx-zynqmp.
100000b0: 03000000 04000000 0c000000 01000000    ................
100000c0: 01000000 67616d69 00007365 01000000    ....images......
100000d0: 6e72656b 31406c65 00000000 03000000    kernel@1........
100000e0: 0d000000 00000000 756e694c 656b2078    ........Linux ke
100000f0: 6c656e72 00000000 03000000 ffa86b00    rnel.........k..
10000100: 1b000000 08088b1f 5c50353e 696c0302    ........>5P\..li
10000110: 2e78756e 006e6962 780bbdec 07b5d554    nux.bin....xT...
10000120: 9339cebe 90804907 68842409 31e41266    ..9..I...$.hf..1
10000130: 81092b3e 49939b4a 939f0450 6bd5b5b4    >+..J..IP......k
10000140: a96d0926 b401b6d1 0939a908 7b69ad68    &.m.......9.h.i{
10000150: 8b4a3039 02499bde 16969996 dac65125    90J...I.....%Q..
10000160: 287d8026 820c5ede 4eb7b6de 7d2b5502    &.}(.^.....N.U+}
10000170: 810326f0 3ed6fff9 212664e7 7affebda    .&.....>.d&!...z
10000180: 7dfff4ff 3be6fbe6 c7ece739 b5af6b5a    ...}...;9...Zk..
10000190: af7b5af6 5fcdcebd 525a3d20 4c944998    .Z{...._ =ZR.I.L
100001a0: 904b4fe2 1f4292f8 b9ea57fc eb8ab179    .OK...B..W..y...
100001b0: 1689f36d ef61e507 a72894fc 692672ca    m.....a...(..r&i
100001c0: 5c8e8807 eb7b3465 71e9446b 797ff885    ...\e4{.kD.q...y
100001d0: 7fb98694 823fdcb3 a44bfac1 d577ff0f    ......?...K...w.
100001e0: 58ae2ff2 603bfa2e e35d62c0 de441cfe    ./.X..;`.b]...D.
100001f0: 2f5716ab c61be6af ecca2d63 71ae334a    ..W/....c-..J3.q
10000200: 4f43a07f ffd9439e dfe3eff1 7f8fbfc7    ..CO.C..........
10000210: fe3eff1f f8fbfc7d e3eff1f7 8fbfc7df    ..>.}...........
10000220: 3eff1f7f feb3fdfe 317aadce fd214e70    ...>......z1pN!.
10000230: 8e452a78 777c142b 44fcf92c d553c745    x*E.+.|w,..DE.S.
10000240: 2f55b9c8 aa51e96d ef39700e 2f246a23    ..U/m.Q..p9.#j$/
10000250: 24d63d4d 78e76553 566f2c8a c6650e23    M=.$Se.x.,oV#.e.
10000260: 50a7e7ec 0664ac24 ece74ab3 23544bef    ...P$.d..J...KT#
10000270: c8cf4c94 e99e94d7 c6eb56ff ecea24fc    .L.......V...$..
10000280: 700e53ba 79a449fd 07d5971e c953fff9    .S.p.I.y......S.
10000290: 46f9d854 b7b9e069 c57e81dc 9de2741e    T..Fi.....~..t..
100002a0: 1cd7df86 afd91be4 7db97684 a76d0da7    .........v.}..m.
100002b0: 1396dac7 229db6d0 b68c865c 1b7fe243    ......."\...C...
100002c0: 45973d15 69ebd791 8afd13ed f49f207e    .=.E...i....~ ..
100002d0: 782932b0 fba7a7c5 ded1f76c 7ae5da35    .2)x....l...5..z
100002e0: 40d95a73 7b0ed915 7012a893 3288daf5    sZ.@...{...p...2
100002f0: f846a4dd cafc0699 3b33dd32 91a52564    ..F.....2.3;d%..
10000300: a34aea12 7debcad1 e05a81a5 8f894b5f    ..J....}..Z._K..
10000310: b6e1d9e1 cfcad1f3 e391aa66 e75668d1    ........f....hV.
10000320: fcf23578 5bf23514 33fdcffc e7cc7b5e    x5...5.[...3^{..
10000330: 03eae32f aba07d0c 03a63806 d46c2786    /....}...8...'l.
10000340: 744ca7d9 8f778185 b9e0725c 75c2352c    ..Lt..w.\r..,5.u
10000350: c2d113b4 d77ca39f 8c2329a7 24af1bf7    ......|..)#....$
10000360: 2d2e5e5f 4be3c025 cb699d21 6fa78874    _^.-%..K!.i.t..o
10000370: 2768c9ff 7499a9f7 b464e07d 0651e688    ..h'...t}.d...Q.
10000380: 9d5133c3 7b46eae8 cbb73ffc 121d3030    .3Q...F{.?..00..
10000390: 67d58301 e3c9c31b 377ffb80 a34057e1    ...g.......7.W@.
100003a0: 86a8d05a aadcfd24 e51bc16e 8921fda0    Z...$...n.....!.
100003b0: 35556b3a 86a6df34 d3683214 0e395447    :kU54....2h.GT9.
100003c0: 657ae3b4 eb4cea99 4aa243b9 2bd46ab7    ..ze..L..C.J.j.+
100003d0: c2bb468f 52fc148a dce1ba34 e3439daa    .F.....R4.....C.
100003e0: 01c951aa 50d79eeb 2329320a e73cd141    .Q.....P.2)#A.<.
100003f0: a6057556 f2718ade 0db5ea26 bc149f9b    Vu....q.&.......
ZynqMP>  bootm ${netstart}
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x10000104
     Data Size:    7055615 Bytes = 6.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x00080000
     Entry Point:  0x00080000
     Hash algo:    sha1
     Hash value:   ce12e0f53ee09f9dbceba47b072545803d44f4c5
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  petalinux-user-image
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x106c2980
     Data Size:    6495253 Bytes = 6.2 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   23500275cacf81fa1b5037904bbecd0b2e45c0c9
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'fdt@system-top.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x106bab08
     Data Size:    32178 Bytes = 31.4 KiB
     Architecture: AArch64
     Hash algo:    sha1
     Hash value:   1d6ccaf9a6e92c5d1e3042e85b212f6af329d7b8
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x106bab08
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 079ce000, end 07fffc15 ... OK
   Loading Device Tree to 00000000079c3000, end 00000000079cddb1 ... OK

Starting kernel ...



I've put the 2018.2 prebuilt file on SD and tried also to start linux from flash, it also works.


U-Boot 2018.01 (Sep 28 2018 - 12:42:22 +0200) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  1023 MiB
EL Level:       EL2
Chip ID:        zu4cg
MMC:   sdhci@ff160000: 0 (eMMC), sdhci@ff170000: 1 (SD)
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
*** Warning - bad CRC, using default environment

In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Board: Xilinx ZynqMP
Bootmode: SD_MODE1
Net:   ZYNQ GEM: ff0e0000, phyaddr ffffffff, interface rgmii-id
eth0: ethernet@ff0e0000
U-BOOT for petalinux

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete..... done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.150.129 (1758 ms)
Hit any key to stop autoboot:  0
Device: sdhci@ff160000
Manufacturer ID: 13
OEM: 14e
Name: Q2J54
Tran Speed: 200000000
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 16 MiB ENH
RPMB Capacity: 512 KiB ENH
** Unable to read file image.ub **
ZynqMP> sf probe
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
ZynqMP>  sf read ${netstart} 0x4000000 0x1000000
device 0 offset 0x4000000, size 0x1000000
SF: 16777216 bytes @ 0x4000000 Read: OK
ZynqMP>  md ${netstart} 100
10000000: edfe0dd0 284bcf00 38000000 3447cf00    ......K(...8..G4
10000010: 28000000 11000000 10000000 00000000    ...(............
10000020: 74000000 fc46cf00 00000000 00000000    ...t..F.........
10000030: 00000000 00000000 01000000 00000000    ................
10000040: 03000000 04000000 64000000 3e35505c    ...........d\P5>
10000050: 03000000 54000000 00000000 6f422d55    .......T....U-Bo
10000060: 6620746f 6d497469 20656761 20726f66    ot fitImage for
10000070: 61746550 756e694c 2e342f78 782d3431    PetaLinux/4.14-x
10000080: 6e696c69 32762d78 2e383130 69672b33    ilinx-v2018.3+gi
10000090: 54554174 434e494f 6165652b 64333762    tAUTOINC+eeab73d
100000a0: 2f303231 786e6c70 6e797a2d 00706d71    120/plnx-zynqmp.
100000b0: 03000000 04000000 0c000000 01000000    ................
100000c0: 01000000 67616d69 00007365 01000000    ....images......
100000d0: 6e72656b 31406c65 00000000 03000000    kernel@1........
100000e0: 0d000000 00000000 756e694c 656b2078    ........Linux ke
100000f0: 6c656e72 00000000 03000000 ffa86b00    rnel.........k..
10000100: 1b000000 08088b1f 5c50353e 696c0302    ........>5P\..li
10000110: 2e78756e 006e6962 780bbdec 07b5d554    nux.bin....xT...
10000120: 9339cebe 90804907 68842409 31e41266    ..9..I...$.hf..1
10000130: 81092b3e 49939b4a 939f0450 6bd5b5b4    >+..J..IP......k
10000140: a96d0926 b401b6d1 0939a908 7b69ad68    &.m.......9.h.i{
10000150: 8b4a3039 02499bde 16969996 dac65125    90J...I.....%Q..
10000160: 287d8026 820c5ede 4eb7b6de 7d2b5502    &.}(.^.....N.U+}
10000170: 810326f0 3ed6fff9 212664e7 7affebda    .&.....>.d&!...z
10000180: 7dfff4ff 3be6fbe6 c7ece739 b5af6b5a    ...}...;9...Zk..
10000190: af7b5af6 5fcdcebd 525a3d20 4c944998    .Z{...._ =ZR.I.L
100001a0: 904b4fe2 1f4292f8 b9ea57fc eb8ab179    .OK...B..W..y...
100001b0: 1689f36d ef61e507 a72894fc 692672ca    m.....a...(..r&i
100001c0: 5c8e8807 eb7b3465 71e9446b 797ff885    ...\e4{.kD.q...y
100001d0: 7fb98694 823fdcb3 a44bfac1 d577ff0f    ......?...K...w.
100001e0: 58ae2ff2 603bfa2e e35d62c0 de441cfe    ./.X..;`.b]...D.
100001f0: 2f5716ab c61be6af ecca2d63 71ae334a    ..W/....c-..J3.q
10000200: 4f43a07f ffd9439e dfe3eff1 7f8fbfc7    ..CO.C..........
10000210: fe3eff1f f8fbfc7d e3eff1f7 8fbfc7df    ..>.}...........
10000220: 3eff1f7f feb3fdfe 317aadce fd214e70    ...>......z1pN!.
10000230: 8e452a78 777c142b 44fcf92c d553c745    x*E.+.|w,..DE.S.
10000240: 2f55b9c8 aa51e96d ef39700e 2f246a23    ..U/m.Q..p9.#j$/
10000250: 24d63d4d 78e76553 566f2c8a c6650e23    M=.$Se.x.,oV#.e.
10000260: 50a7e7ec 0664ac24 ece74ab3 23544bef    ...P$.d..J...KT#
10000270: c8cf4c94 e99e94d7 c6eb56ff ecea24fc    .L.......V...$..
10000280: 700e53ba 79a449fd 07d5971e c953fff9    .S.p.I.y......S.
10000290: 46f9d854 b7b9e069 c57e81dc 9de2741e    T..Fi.....~..t..
100002a0: 1cd7df86 afd91be4 7db97684 a76d0da7    .........v.}..m.
100002b0: 1396dac7 229db6d0 b68c865c 1b7fe243    ......."\...C...
100002c0: 45973d15 69ebd791 8afd13ed f49f207e    .=.E...i....~ ..
100002d0: 782932b0 fba7a7c5 ded1f76c 7ae5da35    .2)x....l...5..z
100002e0: 40d95a73 7b0ed915 7012a893 3288daf5    sZ.@...{...p...2
100002f0: f846a4dd cafc0699 3b33dd32 91a52564    ..F.....2.3;d%..
10000300: a34aea12 7debcad1 e05a81a5 8f894b5f    ..J....}..Z._K..
10000310: b6e1d9e1 cfcad1f3 e391aa66 e75668d1    ........f....hV.
10000320: fcf23578 5bf23514 33fdcffc e7cc7b5e    x5...5.[...3^{..
10000330: 03eae32f aba07d0c 03a63806 d46c2786    /....}...8...'l.
10000340: 744ca7d9 8f778185 b9e0725c 75c2352c    ..Lt..w.\r..,5.u
10000350: c2d113b4 d77ca39f 8c2329a7 24af1bf7    ......|..)#....$
10000360: 2d2e5e5f 4be3c025 cb699d21 6fa78874    _^.-%..K!.i.t..o
10000370: 2768c9ff 7499a9f7 b464e07d 0651e688    ..h'...t}.d...Q.
10000380: 9d5133c3 7b46eae8 cbb73ffc 121d3030    .3Q...F{.?..00..
10000390: 67d58301 e3c9c31b 377ffb80 a34057e1    ...g.......7.W@.
100003a0: 86a8d05a aadcfd24 e51bc16e 8921fda0    Z...$...n.....!.
100003b0: 35556b3a 86a6df34 d3683214 0e395447    :kU54....2h.GT9.
100003c0: 657ae3b4 eb4cea99 4aa243b9 2bd46ab7    ..ze..L..C.J.j.+
100003d0: c2bb468f 52fc148a dce1ba34 e3439daa    .F.....R4.....C.
100003e0: 01c951aa 50d79eeb 2329320a e73cd141    .Q.....P.2)#A.<.
100003f0: a6057556 f2718ade 0db5ea26 bc149f9b    Vu....q.&.......
ZynqMP>  bootm ${netstart}
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x10000104
     Data Size:    7055615 Bytes = 6.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x00080000
     Entry Point:  0x00080000
     Hash algo:    sha1
     Hash value:   ce12e0f53ee09f9dbceba47b072545803d44f4c5
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  petalinux-user-image
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x106c2980
     Data Size:    6495253 Bytes = 6.2 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   23500275cacf81fa1b5037904bbecd0b2e45c0c9
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'fdt@system-top.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x106bab08
     Data Size:    32178 Bytes = 31.4 KiB
     Architecture: AArch64
     Hash algo:    sha1
     Hash value:   1d6ccaf9a6e92c5d1e3042e85b212f6af329d7b8
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x106bab08
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 079ce000, end 07fffc15 ... OK
   Loading Device Tree to 00000000079c3000, end 00000000079cddb1 ... OK

Starting kernel ...



Is the flash size detected correctly on your place?
"SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB"

Has you completly used our prebuilt boot.bin? Or only our U-boot with your FSBL?

br
John

timor.knudsen

Hi John,
the tests you conducted are expected to work in our configuration, too.

The error occurs when trying to read across the 64 MiB boundary, e.g. you can easily verify this by issuing a command like this:


sf read ${netstart} 0x3FFFFF0 0x20


and compare the memory region after ${netstart} to your previous output. Of course you need to take the offset into account, but still I'd expect you to see some data that doesnt belong. Instead of a starting address of 0x3FFFFF0 you can use any valid address, just make sure you read long enough and account for the offset in netstart when comparing the data.

JH

Hi,

ZynqMP> sf read ${netstart} 0x3ffffc0 80
device 0 offset 0x3ffffc0, size 0x80
SF: 128 bytes @ 0x3ffffc0 Read: OK
ZynqMP> md ${netstart} 20
10000000: edfe0dd0 284bcf00 38000000 3447cf00    ......K(...8..G4
10000010: 28000000 11000000 10000000 00000000    ...(............
10000020: 74000000 fc46cf00 00000000 00000000    ...t..F.........
10000030: 00000000 00000000 01000000 00000000    ................
10000040: 03000000 04000000 64000000 3e35505c    ...........d\P5>
10000050: 03000000 54000000 00000000 6f422d55    .......T....U-Bo
10000060: 6620746f 6d497469 20656761 20726f66    ot fitImage for
10000070: 61746550 756e694c 2e342f78 782d3431    PetaLinux/4.14-x
ZynqMP> mw ${netstart} 0xffffffff 20
ZynqMP> md ${netstart} 20
10000000: ffffffff ffffffff ffffffff ffffffff    ................
10000010: ffffffff ffffffff ffffffff ffffffff    ................
10000020: ffffffff ffffffff ffffffff ffffffff    ................
10000030: ffffffff ffffffff ffffffff ffffffff    ................
10000040: ffffffff ffffffff ffffffff ffffffff    ................
10000050: ffffffff ffffffff ffffffff ffffffff    ................
10000060: ffffffff ffffffff ffffffff ffffffff    ................
10000070: ffffffff ffffffff ffffffff ffffffff    ................
ZynqMP> sf read ${netstart} 0x4000000 80
device 0 offset 0x4000000, size 0x80
SF: 128 bytes @ 0x4000000 Read: OK
ZynqMP> md ${netstart} 20
10000000: 03000000 04000000 64000000 3e35505c    ...........d\P5>
10000010: 03000000 54000000 00000000 6f422d55    .......T....U-Bo
10000020: 6620746f 6d497469 20656761 20726f66    ot fitImage for
10000030: 61746550 756e694c 2e342f78 782d3431    PetaLinux/4.14-x
10000040: 6e696c69 32762d78 2e383130 69672b33    ilinx-v2018.3+gi
10000050: 54554174 434e494f 6165652b 64333762    tAUTOINC+eeab73d
10000060: 2f303231 786e6c70 6e797a2d 00706d71    120/plnx-zynqmp.
10000070: 03000000 04000000 0c000000 01000000    ................
ZynqMP> sf read ${netstart} 0x3ffffc0 0x100000
device 0 offset 0x3ffffc0, size 0x100000
SF: 1048576 bytes @ 0x3ffffc0 Read: OK
ZynqMP> bootm ${netstart}
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x10000104
     Data Size:    7055615 Bytes = 6.7 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x00080000
     Entry Point:  0x00080000
     Hash algo:    sha1
     Hash value:   ce12e0f53ee09f9dbceba47b072545803d44f4c5
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  petalinux-user-image
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x106c2980
     Data Size:    6495253 Bytes = 6.2 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   23500275cacf81fa1b5037904bbecd0b2e45c0c9
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'fdt@system-top.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x106bab08
     Data Size:    32178 Bytes = 31.4 KiB
     Architecture: AArch64
     Hash algo:    sha1
     Hash value:   1d6ccaf9a6e92c5d1e3042e85b212f6af329d7b8
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x106bab08
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 079ce000, end 07fffc15 ... OK
   Loading Device Tree to 00000000079c3000, end 00000000079cddb1 ... OK

Starting kernel ...




  • I read over the boundary (64 before 64 after)
  • I cleared the RAM
  • I read at the boundary (128)
  • I copied the whole image.ub
  • I boot the image

I think something with alignment was not correct in your case.

br
John

timor.knudsen

Ok, I am going to review this in more detail. Really strange that you are not able to reproduce the behavior we see. One question though, is this 2018.2 or 2018.3?

JH

Hi,
18.3 but uboot seems to be the same, see my log:
2018.3:
"U-Boot 2018.01 (Jan 29 2019 - 10:59:41 +0000) Xilinx ZynqMP ZCU102 rev1.0"
2018.2
"U-Boot 2018.01 (Sep 28 2018 - 12:42:22 +0200) Xilinx ZynqMP ZCU102 rev1.0"

Try out my address:

  • sf read ${netstart} 0x3ffffc0 80
  • mw ${netstart} 0xffffffff 20
  • md ${netstart} 20
  • sf read ${netstart} 0x4000000 80
  • md ${netstart} 20
generate boot.bin needs offset multiple of 64 that's the reason for 0x3ffffc0 ...

So does it works on your place with the another offset, which also multiple of 64?

br
John

simon.beaudoin

Hi John,

I have started a thread on the same issue some months ago. I had let down booting from the flash and moved to booting from a M.2 SSD drive. It was fine for a while, but now it is time to make our baseline work (booting entirely from flash, use external m.2 for other things, but not for boot)

I have exactly the same symptoms as timor : I have a 128mb TE0803 SOM, and when I try to boot with a big FIT image, the u-boot complains about the SHA1 checksum of the ramsidk. We deduce of course that the  ramfs is the thing that is stored over the 64mb boundary in the FIT image.

SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
device 0 offset 0x940000, size 0x56c0000
SF: 90963968 bytes @ 0x940000 Read: OK
## Loading kernel from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x10000104
     Data Size:    5770803 Bytes = 5.5 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x00080000
     Entry Point:  0x00080000
     Hash algo:    sha1
     Hash value:   76acd97dfe31f51ee6cb2c29c76fc00748f7adb5
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 10000000 ...
   Using 'conf@system-top.dtb' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  petalinux-user-image
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x10590348
     Data Size:    82621839 Bytes = 78.8 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   5e8820e4a56f79214cfc6e2b42d0a9b29cde61c7
   Verifying Hash Integrity ... sha1 error!
Bad hash value for 'hash@1' hash node in 'ramdisk@1' image node



John, when I execute your the test you made in your previous post, I get the same kind of behavior that timor got :

First I show you the content of the beginning of the flash :
ZynqMP> sf read ${netstart} 0x0000000 80
device 0 offset 0x0, size 0x80
SF: 128 bytes @ 0x0 Read: OK
ZynqMP> md ${netstart} 20
10000000: 14000000 14000000 14000000 14000000    ................
10000010: 14000000 14000000 14000000 14000000    ................
10000020: aa995566 584c4e58 00000000 fffc0000    fU..XNLX........
10000030: 00002800 0001fae0 0001fae0 00017188    .(...........q..
10000040: 00017188 00000800 fd175371 00000000    .q......qS......
10000050: 00000000 00000000 00000000 00000000    ................
10000060: 00000000 00000000 00000000 01000020    ............ ...
10000070: 00000000 00000000 00000000 00000000    ................


We can see it is indeed the start of a boot.bin : the XNLX string somewhere at the beginning.

Now I read 128 bytes, 64 before the boundary, 64 after :
ZynqMP> sf read ${netstart} 0x3ffffc0 80
device 0 offset 0x3ffffc0, size 0x80
SF: 128 bytes @ 0x3ffffc0 Read: OK
ZynqMP> md ${netstart} 20
10000000: 5853f0ad 7d2a2cb4 89dbf111 4321ce72    ..SX.,*}....r.!C
10000010: 5d99ccfb 9bf71734 c95c79a6 dd7d74ea    ...]4....y\..t}.
10000020: 13dd88d9 63968f63 1e6b157c 64c6bcc3    ....c..c|.k....d
10000030: 57d966f5 c3ac97ef 3b99390d d477ef15    .f.W.....9.;..w.
10000040: 14000000 14000000 14000000 14000000    ................
10000050: 14000000 14000000 14000000 14000000    ................
10000060: aa995566 584c4e58 00000000 fffc0000    fU..XNLX........
10000070: 00002800 0001fae0 0001fae0 00017188    .(...........q..


We can see that the bottom half of the data is exactly the same as the first half of the previous data sample

Now, if I read the same amount of data, starting exactly at the 64mb boundary :
ZynqMP> sf read ${netstart} 0x4000000 80
device 0 offset 0x4000000, size 0x80
SF: 128 bytes @ 0x4000000 Read: OK
ZynqMP> md ${netstart} 20
10000000: 5afa9d37 15dcb106 7dc0bdc8 c8abc6df    7..Z.......}....
10000010: 8afb838b 65419262 3caee0f7 3ade435d    ....b.Ae...<]C.:
10000020: c77c36fe f6ca73c3 a12b8620 31688be2    .6|..s.. .+...h1
10000030: 671a32ce 78838d3e 5c964cff 02e43d01    .2.g>..x.L.\.=..
10000040: 7e6a9b3a a29be85e 7a8ad6f5 d5e32441    :.j~^......zA$..
10000050: 1a6c5165 8f7d128b e03f7bc8 3ccce9ab    eQl...}..{?....<
10000060: ad3a6a89 d16b1eff be08cfdc 177c1377    .j:...k.....w.|.
10000070: fce97c13 fa7be1bc d5e682eb 66e704cd    .|....{........f


I can only presume that this is the right data

Now, the beautiful thing is that I can make it work with this workaround :

My kernel partition starts at 0x0094_0000 and has size 0x056c_0000.

I start by asking to read 0x036C_0000 bytes (0x0400_0000 - 0x0094_0000) from this address to ${netstart}. Like this, I read up to the very limit of the 64mb boundary.

I then read the rest of the data : read 0x0200_0000 bytes starting at address 0x0400_0000 to ${netstart + 0x036C_0000)

Like this, I never cross the 64mb boundary:


sf read 0x10000000 0x940000 0x36C0000
sf read 0x136c0000 0x4000000 0x2000000
bootm ${netstart}


Now, to make this hack work automatically on boot, I ' setenv' the cp_kernel2ram variable :

setenv cp_kernel2ram sf probe 0 && sf read 0x10000000 0x940000 0x36C0000 && sf read 0x136c0000 0x4000000 0x2000000

We have found that we have several Te0803 SOM with rev 2 written on them, and they all do the same behavior. My collegue (who got tasked to make this work) told us that we happen to have one TE0803 with rev 3, and that with it the problem vanished.

Unfortunately I can't test with the rev3 SOM and confirm it first hand, I am going to do it in the near future.

I will let you think about this one ;)

Thank you! 


timor.knudsen

Hi Simon,
interesting to know that you have the same behavior. We employed the very same workaround as you did, e.g. reading the image sequentially in 64 MByte chunks.

Also really interesting that the behavior may be gone in Rev. 3, which could explain why I saw the issue and John didn't.

Timor

simon.beaudoin

I confirm that rev 3 uses different flash chips than both previous revisions. I will confirm soon about my coworker statement

simon.beaudoin

I now confirm that with rev 3 som, the bug doesn't manifest itself.

the cp_kernel2ram = sf probe 0 && sd read ${netstart} ${kernelstart} ${kernelsize}

is working perfectly fine

JH

Hi,
yes we have changes Flash type  two times, because older ones was obsolete and not longer available.
https://wiki.trenz-electronic.de/display/PD/PCN-20171115+TE0803-01+SPI+Flash+Change
https://wiki.trenz-electronic.de/display/PD/PCN-20190107+TE0803-02-*-*+to+TE0803-03-*-*+Hardware+Revision+Change

Newer flash was footprint compatible, so HW itself was not change on this part.
So from your description, it seems to be a driver bug for some flash types.

br
John