This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Using OMAP3530, PSP 3.00.01.06. I would like to build a ramdisk image and load it over tftp. Unfortunately, the boot process is hanging after "RAMDISK: gzip image found at block 0".
The process I am using to build the ramdisk image: mkdir -p ramdisk dd if=/dev/zero of=ramdisk_file bs=40M count=1 mkfs.ext2 ramdisk_file sudo mount -o loop ramdisk_file ramdisk sudo tar -xvzf arago-console-image-omap3evm.tar.gz -C ramdisk sudo umount ramdisk gzip ramdisk_file
My boot arguments:
setenv get_kernel run nand_kernel setenv get_initrd run tftp_initrd setenv nand_kernel nand read.i 0x80000000 280000 300000 setenv tftp_initrd tftpboot 0x81600000 ramdisk_file.gz setenv rdargs 'setenv bootargs mem=99M console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x81600000,40M ramdisk_size=40960' setenv boot_rd 'run get_kernel; run get_initrd; run rdargs; bootm 0x80000000'
I load the ramdisk over tftp fine, the kernel boots up as normal, it gets to the ramdisk section, spits out "RAMDISK: gzip image found at block 0" and then hangs. I have tried this with a prebuilt ramdisk image from DVSDK 3.00 and it boots fine. What might I be doing wrong in my process?
Changing the compression type doesn't seem to make any difference. Perhaps that minimal filesystem package is unsuitable for using in a ramdisk? Is there another in DVSDK 4.00 that would be better?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Glenn Wainwright:
Nope, unzipping a known good ramdisk image and using the same contents to create a new ramdisk image with the above process gives the same results. What could be wrong with the process?
Seems like the problem here is "mem=99M". Changing that to "mem=128M" appears to give it enough space to load the ramdisk image without issue. Since our memory's currently only 128 MB total, using CMEM with the ramdisk is probably out of the question, but I can work around that.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.