cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
marcoventurini
Adventurer
Adventurer
11,049 Views
Registered: ‎10-02-2014

[U-Boot] GUNZIP: uncompress, out-of-mem or overwrite error

Jump to solution

Hi all,

 

I was tryng to compile the OpenCV xilinx example to be included in a Zynq design.

After including the opencv libraries into the Linux image the system is no logere booting bocause of the size of the rootfs.

 

I get this error :

 

[U-Boot] GUNZIP: uncompress, out-of-mem or overwrite error

 

i understand that i need to change the sise of the initial ramdisk and probily some other offset.

 

Very bad thing is that it seems that i need to dig into the Uboot sources to find the values to update.

 

so far i added

 

 #define CONFIG_SYS_BOOTM_LEN   (80 * 1024 * 1024)

 

into zynq_common.h but without any result

 

The problem seem very common, can someone point me out what i need to change and where?

 

i'm usign petalinux 2013.10 and i'm booting from SD card.

 

Thanks!!

 

0 Kudos
Reply
1 Solution

Accepted Solutions
norman_wong
Scholar
Scholar
19,107 Views
Registered: ‎05-28-2012

The locations of the uncompressed kernel, device tree and ramdisk are hard-coded in the u-boot environment variables. Yeah, it would be nice if the sizes were automatically adjusted but that would require modification of the u-boot code and not just the config header file.

---File: include/configs/zynq_zc70x.h---
...
#include <configs/zynq_common.h>
...

---File: include/configs/zynq_common.h---
...
#define CONFIG_EXTRA_ENV_SETTINGS    \
...
"sdboot=if mmcinfo; then " \
"run uenvboot; " \
"echo Copying Linux from SD to RAM... && " \
"fatload mmc 0 0x3000000 ${kernel_image} && " \
"fatload mmc 0 0x2A00000 ${devicetree_image} && " \
"fatload mmc 0 0x2000000 ${ramdisk_image} && " \
"bootm 0x3000000 0x2000000 0x2A00000; " \
...

I am not sure if the u-boot compilation uses the actual zynq_zc70x.h file. I think it creates a config.h from your speicified config file. Maybe a  symbolic link. Not sure. You might need to do a clean, config and rebuild of u-boot. Also, if you have u-boot environment variables stored in flash, the flash values will take precedence over the default valuesin the header file.

View solution in original post

8 Replies
norman_wong
Scholar
Scholar
11,032 Views
Registered: ‎05-28-2012

How big is you uramdisk.image.gz file? If it is bigger than 0xA00000 or 10MiB then it will overwrite your devicetree. If it is bigger than 0x01000000 or 16MiB then it will overwrite the kernel uImage. Suggect executing each command of the "sdboot" environment vairable with increased numbers. Try pushing the kernel and devicetree an additional 0x01000000.

mmcinfo
run uenvboot
fatload mmc 0 0x4000000 ${kernel_image}
fatload mmc 0 0x4A00000 ${devicetree_image}
fatload mmc 0 0x2000000 ${ramdisk_image}
bootm 0x4000000 0x2000000 0x4A00000

 

0 Kudos
Reply
marcoventurini
Adventurer
Adventurer
11,024 Views
Registered: ‎10-02-2014

Thanks norman i got it working, but how do i set these values in the u-boot sources?

And ... is there a reason why these operations must be done manually? I think the tool has all the information needed to change to offssets based on the image size.

 

Thanks again,

 

Marco

0 Kudos
Reply
marcoventurini
Adventurer
Adventurer
11,019 Views
Registered: ‎10-02-2014

In addition i notice that the file zynq_common.h is not loaded at all (i tried changing the boot timeout without effect), where am i suppose to set default enviroment variables?

 

We are developing on a custom board.

0 Kudos
Reply
norman_wong
Scholar
Scholar
19,108 Views
Registered: ‎05-28-2012

The locations of the uncompressed kernel, device tree and ramdisk are hard-coded in the u-boot environment variables. Yeah, it would be nice if the sizes were automatically adjusted but that would require modification of the u-boot code and not just the config header file.

---File: include/configs/zynq_zc70x.h---
...
#include <configs/zynq_common.h>
...

---File: include/configs/zynq_common.h---
...
#define CONFIG_EXTRA_ENV_SETTINGS    \
...
"sdboot=if mmcinfo; then " \
"run uenvboot; " \
"echo Copying Linux from SD to RAM... && " \
"fatload mmc 0 0x3000000 ${kernel_image} && " \
"fatload mmc 0 0x2A00000 ${devicetree_image} && " \
"fatload mmc 0 0x2000000 ${ramdisk_image} && " \
"bootm 0x3000000 0x2000000 0x2A00000; " \
...

I am not sure if the u-boot compilation uses the actual zynq_zc70x.h file. I think it creates a config.h from your speicified config file. Maybe a  symbolic link. Not sure. You might need to do a clean, config and rebuild of u-boot. Also, if you have u-boot environment variables stored in flash, the flash values will take precedence over the default valuesin the header file.

View solution in original post

marcoventurini
Adventurer
Adventurer
10,954 Views
Registered: ‎10-02-2014

I really appreciate your Help, thanks.

 

The problem is solved but don't like how i did it.

Apparrently the default config is zynq_zc70x.h is not linked... beacuse (i suppose) i did not started my project form a demo board template.

 

The config file used is generated (as you stated) by the petalinunx config command, but there is no parameters to config for u-boot.

 

Basically the tools will lead you into a deadlock... i think xilinx can afford few more software engineers.

 

Thanks again.

 

Marco

0 Kudos
Reply
norman_wong
Scholar
Scholar
10,943 Views
Registered: ‎05-28-2012

Can't say about Petalinux. I've been avoiding using their framework. Just a GIT snapshot and the cross-compiler for me. Avoids the deadlock. In my case, I think the zynq_common.h file does get included directly or indirectly via a copy. I have to manually do everything but I have control over everything.

 

Eventually I would expect Vivado to generate the device tree, u-boot config and linux config outside their respective trees. SDSoc seems nearing that sort of thing. XIlinx doen't need more SW engineers, they just need to release a tested completely automated solution rather than a buggy half-automated solution. Xilinx automates just enough to be a hindrance. A lot of patching of auto-generated code that could get lost on every clean and rebuild.

0 Kudos
Reply
marcoventurini
Adventurer
Adventurer
10,931 Views
Registered: ‎10-02-2014

I'm not yet familar enough with linux to do my own toolchain (i'm the FPGA designer) but i think it would be the best way to go... maybe in a year ;)

 

0 Kudos
Reply
norman_wong
Scholar
Scholar
10,924 Views
Registered: ‎05-28-2012

I usually don't build the the toolchain and I'm firmware. Most manufacturers, including Xilinx, have pre-built toolchains available. Odds are that if you gone down the the PetaLinux path, the toolchain is already installed. I would actually be happy if the FPGA guy could generate a complete turn-key solution from his side in Vivado. A lot of manual firmware tweaking still. Maybe in a year, you won't need to invoke the toolchain manually.

0 Kudos
Reply