On 1 December 2016 at 20:28, Arno Steffens <s...@gmx.li> wrote: > Thanks Mike and Nathan for feedback. > As this is really effort to test if uboot fails (I have to flash (slow) via > xilinx jtag the hole qspi) I am asking once again:
You shouldn't need to write to QSPI to test if you have JTAG access to the Zynq. Have a read of the JTAG loading section in the README.booting. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/README.booting.md#n26 (You can substitute fsbl.elf in place of u-boot-spl.bin if you are using FSBL). You can also use this as a potentially faster way to write to your QSPI, using u-boot to load the images via TFTP and then writing them to QSPI from ram. > > So I will delete (or better said not add) CONFIG_SYS_SDRAM_SIZE? > My devicetree aready looks like this, so I expected this works > > memory { > device_type = "memory"; > reg = <0x0 0x1f000000>; This should define your entire memory. Aka 0x0 - 0x20000000. > }; > > I add than (is this optional or required?) > reserved-memory { Don't forget 'ranges;' and '#*-cells'. > buffer_fpga: buffer_fpga@1f000000 { > reg = <0x1f000000 0x1000000>; You may want to also consider 'no-map;' here depending on how you use this region, have a look at the documentation linked below. > }; > > (what meaning does have the name as here "buffer_fpga" - is it free to chose > ?) The node name is not particularly important, what you have is fine. Full documentation on how the reserved-memory node works: https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt However it is worth noting that u-boot does not handle 'reserved-memory' nodes (at least at the moment). So if your fpga buffer is needed during u-boot execution (aka you load the fpga with FSBL or U-Boot and it immediately accesses the memory segment), then the 'reserved-memory' options will not work for you and you will have to do as you have done previously and reduce the memory size. > > Than you mentions fdt_high. Honestly, not fully understand what this means. > Do I get it right, that with the default it is load to beyond my physical > memory (0x2000.0000)? > But which address I have to chose - any inbetween 0 and 0x1e00.0000 - so that > devicetree fits into the 0x1f00.0000 range for linux? > > set fdt_high 0x1e000000 ? >From the u-boot readme: fdt_high - if set this restricts the maximum address that the flattened device tree will be copied into upon boot. For example, if you have a system with 1 GB memory at physical address 0x10000000, while Linux kernel only recognizes the first 704 MB as low memory, you may need to set fdt_high as 0x3C000000 to have the device tree blob be copied to the maximum address of the 704 MB low memory, so that Linux kernel can access it during the boot procedure. The kernel does not handle relocating the dtb, so make sure fdt_high (and initrd_high) is below the reserved region. Regards, Nathan > > Thanks, > Arno > > >> Gesendet: Donnerstag, 01. Dezember 2016 um 09:44 Uhr >> Von: "Nathan Rossi" <nat...@nathanrossi.com> >> An: "Arno Steffens" <s...@gmx.li> >> Cc: meta-xilinx@yoctoproject.org >> Betreff: Re: [meta-xilinx] uboot CONFIG_SYS_SDRAM_SIZE allocation error >> >> On 1 December 2016 at 17:39, Arno Steffens <s...@gmx.li> wrote: >> > >> > I switched from an older yocto u-boot (2015.01) to recent one (2016.01). >> > Now I can't boot anymore: >> > >> > Zynq> boot >> > QSPI: Kernel/Devicetree - NFS: rootfs >> > SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, >> > total 16 MiB >> > device 0 offset 0x4b0000, size 0x10000 >> > SF: 65536 bytes @ 0x4b0000 Read: OK >> > device 0 offset 0x4c0000, size 0x380000 >> > SF: 3670016 bytes @ 0x4c0000 Read: OK >> > ## Booting kernel from Legacy Image at 02080000 ... >> > Image Name: Linux-4.4.0-xilinx >> > Image Type: ARM Linux Kernel Image (uncompressed) >> > Data Size: 3513736 Bytes = 3.4 MiB >> > Load Address: 00008000 >> > Entry Point: 00008000 >> > Verifying Checksum ... OK >> > ## Flattened Device Tree blob at 02000000 >> > Booting using the fdt blob at 0x2000000 >> > Loading Kernel Image ... OK >> > ERROR: Failed to allocate 0x82a5 bytes below 0x0. >> > device tree - allocation error >> > FDT creation failed! hanging...### ERROR ### Please RESET the board ### >> > >> > -------- >> > My guess for reason of that is following, but I can't solve it. >> > >> > My board (based on MicroZed) has 512MB Ram, but 16MB are used for FPGA. >> > >> > I managed that before with >> > #ifndef __CONFIG_ZYNQ_MICROZED_H >> > #define __CONFIG_ZYNQ_MICROZED_H >> > >> > -#define CONFIG_SYS_SDRAM_SIZE (1024 * 1024 * 1024) >> > +#define CONFIG_SYS_SDRAM_SIZE (496 * 1024 * 1024) >> > >> > In newer Uboot I can't find this definition not in that way. Nevertheless >> > I added this line. >> > (If not, that my last message is "Starting kernel ...") >> > >> > Although digging around, I couldn't find how nowadays this is handled. >> > This seems memory size is not board-specific anymore. How it is handled? >> >> Current versions of u-boot use the memory size which is provided by >> device trees now (for zynq), so make sure you update the value in your >> u-boot device tree. (you can used 'reserved-memory' for the 16MB FPGA >> segment) >> >> Also it is additionally worth noting to make sure "fdt_high" is set in >> your environment such that you can load at 0x0200_0000 or above (the >> default is normally set to 0x2000_0000). >> >> Regards, >> Nathan >> >> > >> > Thanks >> > -- >> > _______________________________________________ >> > meta-xilinx mailing list >> > meta-xilinx@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/meta-xilinx >> -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
