[ELDK] U-Boot configuration kernel + rootfs squashfs image in NAND Flash, copy rootfs to ram, mount rootfs from ram
Christoph Petzold
cpetzoldatwork at gmx.de
Tue Jan 15 16:29:31 CET 2013
Dear Wolfgang Denk,
thank you for your detailed answer.
On 15.01.2013 11:02, Wolfgang Denk wrote:
> Second, you write some 200+ lines of description what you did and what
> you think, and then ask for "help or suggestions", but I cannot see
> any clear statement of what your specific questions are,
I stated my problem in the Subject and at the beginning of my mail.
It is hard to find the "right" questions to ask and to find the "right"
"steps", which do not work. I do my best and try to become better.
Here is my problem statement again:
"Now id like to get the following boot configuration to work:
- kernel from NAND and root file system with squashfs from ram"
Why do i want to do this? Because the company i work for had an embedded
system using redboot boot loader, linux 2.4 and cramfs as root file
system image. The redboot boot configuration did load the kernel and the
rootfs image into ram and startet. The original developers are gone. I
cannot ask them. I assume the chose the "rootfs miage in ram"
configuration because of speed, and security. No changes in the root
file system image where possible. Now i have a new hardware board based
on tx28 and i need a starting point. So i try to copy the configuration
i have found, when i came here. In http://lwn.net/Articles/219827/
in section SquashFS i read that squashfs is newer, more flexible and
actively developed. Thats why i wanted to try sqashfs. I need bootup and
application startup speed and i need a read only root file system for
security.
Boot and start of our main application with standard nand boot
configuration (Kernel + rootfsimage(Jffs2)) take around one minute.
> [1] http://catb.org/esr/faqs/smart-questions.html
Exactly which section should i read?
>> MX28 U-Boot > nand write.trimffs ${fileaddr} rootfs ${filesize}
>
> Why are you using write.trimffs? Please see "doc/README.nand".
Thanks for pointing that out. I believe i only should use the nand
write.trimffs command when using ubi.
>
>> MX28 U-Boot > printenv bootargs_ram_squashfs
>> bootargs_ram_squashfs=run default_bootargs; setenv bootargs ${bootargs}
>> root=/dev/ram r initrd=${rootfsaddr} rootfstype=squashfs
>
> This makes no sense to me. Why do you use /dev/ram here? Your
> squashfs file system is in NAND flash, so the normal way would be to
> just access it through the MTD block device emulation in Linux.
Yes,this standard process works fine. I would like to find out if my
"unusual" configuration differs from the standard configuration with
respect to the boot time and application start time.
>> The kernel documentation for the use of initramfs and initrd is quite
>> confusing for me and there are nearly no kernel docs for squashfs in
>> kernel 3.0. As far as i understand the initramfs method combines a kernel
>> and the rootfs in one image. But this method does not use
>> squashfs.
>
> This should make you stop and wonder if you are doing the right thing.
> Normally it gets used via MTD's block device emulation (as IIRC squashfs
> lacks native MTD support).
>
>> Load Address: 40008000
>> Entry Point: 40008000
>
> Are you sure these are correct?
It is the output of nboot. I do not know if these values are correct.
>
>> I believe that u-boot loads the kernel image from the 'linux'
>> partition of my NAND-flash into the ram at starting address
>> 0x40008000. What is the difference between Load Address
>> and Entry Point by the way? In which case do they differ?
>
> The load address is the start address of the area where the Linux
> kernel image gets loaded/unpacked to, and the entry point is where the
> code execution begins (which may or may not be the very start of the
> image). Aren't the names pretty much self-explaining?
Yes, they are. But they do not explain in which case kernel load address
and kernel entry point differ.
>
>> 8000(hex) is 32Kbyte. Where is this parameter defined?
>
> You define these yourself when configuring and building your Linux
> kernel image.
Ok, fine. This value must be preconfigured in my kernel sources.
> And what would your specific questions be?
I actually have two specific question. But i will give an explanation of
what i did with my current boot configuration.
On Host-PC:
mksquashfs filesystem squashfs.one
where filesystem contains a rootfile system and squashfs.one is the
image to be built.
mkimage -A arm -O linux -T ramdisk -a 0x40800000 -n "ramdisk_sqashfs" -C
none -d sqashfs.one uramdisk_squashf
Here i wrap the rootfs squashfs image into a u-boot image.
uramdisk_squashf is the name of this u-boot image.
0x40800000 is the value of the ${rootfsaddr} variable in my u-boot
environment.
Now on the target device:
MX28 U-Boot > print bootargs
bootargs=consoleblank=0 console=ttyAMA0,115200 tx28_base=stkv3
tx28_otg_mode=device rw debug panic=1 mxsfb.mode=VGA root=/dev/ram0 rw
MX28 U-Boot > tftp ${rootfsaddr} uramdisk_squashfs
Using FEC0 device TFTP from server 192.168.1.212; our IP address is
192.168.1.214 Filename 'uramdisk_squashfs'.
Load address: 0x40800000
Loading: * #################################################################
[snip]
#########################
done
Bytes transferred = 33755200 (2031040 hex)
MX28 U-Boot > nboot linux
Loading from nand0, offset 0x140000
Image Name: Linux-3.3.0-karo
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2629304 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
MX28 U-Boot > bootm ${loadaddr} ${rootfsaddr} ## Booting kernel from
Legacy Image at 40100000 ...
Image Name: Linux-3.3.0-karo
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2629304 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 40800000 ...
Image Name: ramdisk_sqashfs
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 33755136 Bytes = 32.2 MiB
Load Address: 40800000
Entry Point: 40800000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Booting Linux on physical CPU 0
Linux version 3.3.0-karo (entwickler at entwickler-vm) (gcc version 4.5.2
20101204 (prerelease) (GCC) ) #8 PREEMPT Wed Jan 9 15:18:41 CET 2013
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Ka-Ro electronics TX28 module
Memory policy: ECC disabled, Data cache writeback ...
[snip]
...
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t) Registering the
dns_resolver key type
rtc-ds1307 0-0068: setting system clock to 2000-01-01 05:18:46 UTC
(946703926) List of all partitions:
1f00 128 mtdblock0 (driver?)
1f01 1024 mtdblock1 (driver?)
1f02 16384 mtdblock2 (driver?)
1f03 110336 mtdblock3 (driver?)
1f04 4096 mtdblock4 (driver?)
No filesystem could mount root, tried: ext3 ext2 cramfs squashfs vfat
msdos iso9660 Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(1,0) Rebooting in 1 seconds..
Why does the Kernel not find the squashfs root file system image in ram?
Which kernel parameters do i have to specify to have the kernel find and
mount the squashfs root file system image in ram?
I have squashfs, initramfs and RAM block device support compiled into
the kernel.
I believe i did some thing wrong but i do not know what.
best regards
Christoph
More information about the eldk
mailing list