create ramdisk.gz

I think that link does have the instructions to make a ramdisk.gz. It is just a bit unclear. I've never done it myself but here my interpretation of the instructions:

# DO all the work in temp.
cd /tmp

# Login as root
su

# Tar up your NFS directory. Note period at end of line.
tar -cvpf rootfs.tar -C PATH_TO_YOUR_NFS_ROOT .

# Mount a file as an EXT formatted drive.
dd if=/dev/zero of=ramdisk bs=1M count=10
/sbin/mkfs.ext2 ramdisk
mount ramdisk /mnt -o loop

# Untar your NFS directory into the mounted drive.
tar -xvpf rootfs.tar -C /mnt

# Unmount the drive and zip up the file.
umount /mnt
gzip ramdisk

#Logout as root
exit

# Copy zipped file to TFTP server directory.
cp -a ramdisk.gz /tftpboot

Assumes nothing else is mounted in /mnt.

Hi Norman,

Thanks for the clear explanation, I haven't tried it yet.
I'll update again when it will also be tested.

Thank you for your time,

Ran

Hi Ran, Norman.

I can succesfully create  ramdisk (ext2) as described in  "How_to_Create_a_Ramdisk_with_Auto-run_Demo"  for DM365 board.
It runs fine, i can flash it to nand by uBoot with  nand erase/nand write commands, or sd_boot utility.
But i can not flash it within Linux with mtd-utils : nad_eraseall, nandwrite.

flash_eraseall /dev/mtd2
nandwrite -p /dev/mtd2 /mnt/mmc/uImage
flash_eraseall /dev/mtd3
nandwrite -p /dev/mtd3 /mnt/mmc/ramdisk.gz

All commands seems to execute OK, but when i reboot there are no changes on nand flash.

The same commands works fine in DVSDK2, but not in DVSDK4.
It seems there were some changes in mtd drivers.

Actually i was able to replace ony yffs flash image, but not ramdisk, with DVSDK4.

I need to reflash kernel and filesystem images within Linux, so user can reflash new SW by web browser.
Can anybody help.

Regards,
Marko. 

Hi!

Maybe you need to do sync, after nandwrite?

sync

Thanks for suggestion,
but it doesn't work even with "sync".

Regards,
Marko.

Maybe the memory map for NAND changed between DVSDK2 and DVSDK4. The assumed device block size might have changed as well. Check your bootup messages or your board.c file.

Hi Norman,

Thanks, i have checked as you suggested.
If i adjust  uboot boot arguments load addresses for kernel and filesystem,
with mtd partition addreses that are printed from kernel booting ,
it seems kernel is somehow flashed, but it doesn't load due to CRC errors.
Filesystem is not flashed (kernel can't find filesystem, even if i properly reflash kernel from uboot).

I can set nand partition sizes  in board-dm365-evm.c.
Is there any other place to set nand block size ? 

After nandwrite kernel and restart i get:

Loading from NAND 1GiB 3,3V 8-bit, offset 0x1000000
** Read error
## Booting kernel from Legacy Image at 80700000 ...
   Image Name:   Arago/2.6.32.17-psp03.01.01.38/d
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2148212 Bytes =  2 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

Partitions are as follows:

Creating 5 MTD partitions on "davinci_nand.0":
0x000000000000-0x000000f00000 : "bootloader"
0x000000f00000-0x000001000000 : "params"
0x000001000000-0x000001400000 : "kernel"
0x000001400000-0x000021400000 : "filesystem1"
0x000021400000-0x000080000000 : "filesystem2"

So i set bootargs:

setenv bootcmd 'nand read 0x82000000 0x1400000 0xD00000;nboot 0x80700000 0 0x1000000; bootm 0x80700000'
setenv bootargs 'mem=70M console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x82000000,13M ip=192.168.2.122:192.168.2.23:192.168.2.1:255.255.255.0:::off video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K dm365_imp.oper_mode=0 davinci_capture.device_type=1'

kernel: 0x1400000
filesystem:0x1000000

Regards,
Marko.

I've never had to use NAND myself. Take this with a grain of salt. I'd suggest modifying the NAND memory map in board-dm365-evm.c in DVSDK4 to match the one in DVSDK2 version. Keep all else unchanged. Reflash everything from U-boot in the original locations. A mismatch between the U-boot and Linux memory map might result in partially overlapping writes that would corrupt the image.

I thought NAND had special initialization involving the ECC. Does that depend on the memory map?

I  replaced  uBoot with newer version, and now "nandwrite"  from Linux works fine.

Thanks.

Hi Norman,

Sorry to bother you on this topic.  Thank you for helping me on other topic.

I got error message when I do "tar -xvpf rootfs.tar -C /mnt" such as 

./etc/rc5.d/S99loadmodule-rc
tar: ./etc/rc5.d/S99loadmodule-rc: Cannot open: No such file or directory

I do check the file exists in the source rootfs folder. 

Any suggestion? Thank you

Joe

No much to suggest. I last worked on embedded Linux several years ago. Sounds like the tar file could be corrupt. Are you untaring as "root"? Those special files might need "root" privilege. Similarly, you need to be "root" to tar up the source rootfs directory. That's all I got.

Norman, 

You are great. Your reply does help. Find the problem.

I was followed a link form wiki about to create the ramdisk. Over there it uses cp -r rootfs mnt, I did use sudo cp, but still have same error message, then I found your this post and forgot to use sudo tar.

Thank you for help me again

Joe