[Gta04-owner] rationale behind having uImage on the first partition?
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon Oct 24 07:01:21 CEST 2011
first of all, there isn't much rational decision behind... We have just done the
same as the BeagleBoard does. And since it works, there was no need
But if there are two ways how you can do it, there are always arguments
for one solution or the other.
Am 23.10.2011 um 13:55 schrieb Johannes Schauer:
> while I was researching and at the same time composing this email I got
> more and more disappointed. I wanted to make a point for having uImage
> on the second partition by default as I didnt see any advantages of
> having it on the first but only disadvantages but even though some of my
> reasons got moot after trying out if it works in practice let me
> reiterate my initial reasoning anyways.
> So what would the advantages of having uImage on the second ext2/3
> partition be:
> 1. smaller boot partition - the first partition can be very minimal as
> one doesnt have to leave space for alternative kernels or very big
> kernels but only for things that will never be changed anyways. MLO, and
> u-boot occupy less than 2mb while the first partition is created with
> 70MB right now. Lots of space is just wasted and could be used better by
> giving it to the second partition. Due to the 255 heads, 63 sectors
> geometry restriction, the minimal possible size for the first partition
> would be 7.8mb.
I think the same topic was discussed on the beagle board lists
but I don't remember the reasons why a small FAT partition does
> 2. one would be able to use symlinks. With many kernels to try out or
> switch inbetween during development it is more comfortable for me to
> change the target of a symlink instead of copying files from temporary
> locations around. FAT doesnt allow symlinks.
Ok, this is an argument. Although I think copying or changing a symlink
isn't much difference:
ln -sf kernel2 uImage
cp kernel2 uImage
IMHO the current setup also has its benefits. It allows to change the
boot loader, boot splash etc. through /boot like changing the kernel.
I.e. everything is accessed through a simple method being the same
Finally you have to reboot after changing the kernel, so this consumes
What I did was to cross-compile the kernel and then automatically scp
it to root at 192.168.0.202:/boot/uImage. And ssh to issue a reboot.
So I had always only one kernel on the SD card (and multiple ones
on the host).
> 3. Distributions might want to ship their own kernel and it is easier to
> just extract the tarball they to the second partition and being done
> in contrast to additionally having to put their kernel on the first
> partition. Instead of having two downloads and copy operations (kernel
> and rootfs) it would only be one and by that simplifying the process.
Only if there weren't subtle dependencies between U-Boot and the
kernel. If U-Boot or the kernel command line has to be touched,
you are back the two separate downloads.
This is the reason why we have made the makesd script that pulls
together everything it needs. One SD card - one call to makeds. So our
"Distribution" includes everything.
> 4. Reducing possible sources of error. When users dont have to play with
> the first partition anymore to exchange the kernel one source of
> failure is automatically eradicated.
If they don't have a chance to change the kernel through the rootfs, it
would also remove one major source of failure... So this is more an
argument for the current setup.
> 5. Distributions can ship a simpler fstab that doesnt have to mount the
> first partition as /boot to be able to access it. They would be able
> to just ignore it which would further reduce complexity.
Well, is this really a problem in practice? The simplification of the fstab
is just one line.
> As a proof of concept that my idea works in practice I was editing
> http://download.goldelico.com/gta04/unstable/src/boot.txt and converting
> it to boot.scr by doing:
> mkimage -T script -d boot.txt boot.scr
> Simply enough one just needs to change
> fatload mmc 0 0x82000000 uImage
> ext2load mmc 0:2 0x82000000 /boot/uImage
> After this was working fine I investigated how small one could make the
> first partition and was very disappointed when I discovered that nothing
> under a size of 7 cylinders was working with X-Loader. How can this be?
I think the problem is not X-Loader (MLO) itself but the Boot ROM. The
Boot ROM assumes that it can find a sector with a "MLO" signature at
a specific offset from the beginning of the "disk". Maybe, specifying less than
7 cylinders for a FAT filesystem places the MLO file at the wrong absolute
position. But this is only a rough guess. One would have to study the 3500
pages OMAP3 technical manual (there is one chapter about the Boot ROM)
to find out the details.
> Why does the first partition have to be so big? FAT32 (or FAT16 which
> should also work) support partitions much smaller than 55mb (at least
> mkdosfs only complains at sizes much less than that).
Well, after the partition was so big, the kernel could easily find some
> I then investigated further. I created a first partition of 7 cylinders
> (the smallest size that was still working), formatted it with mkdosfs,
> copied all the files over and then created a new partition table with
> the first partition only having 1 cylinder. According to a binary diff,
> this change only affected a couple of bytes in the partition table (as
> expected) but again booting didnt work again. So since this time I left
> the fat partition untouched and only changed the partition sizes, I
> suspect that X-Loader really fails because of the partition table
> properties and not because some troubles with fat.
> Is there any way to fix the issue and have X-Loader cope with smaller
> partition sizes?
> Sadly, due to this problem (if it can't be fixed easily) my main point
> (less space wasted) isnt of so much importance anymore.
It becomes difficult to buy 2G SD cards nowadays and 4 or 8 GB is
becoming the standard. So 70 MB out of 4 GB is <2%. I.e. the waste
> But even if this can't (easily) be fixed, I still want to ask: what is
> your reasoning behind putting uImage on the first partition? I only see
> disadvantages of that and only (even if albeit small) advantages of
> doing otherwise.
> But even if there is a good reason for putting uImage on the first
> partition, how about implementing a fallback mechanism in boot.scr so
> that the kernel is loaded from the ext2/3 fs on the second partition if
> it is not found on the first. Or the other way round, that the kernel is
> loaded from the first fat partition if not found in the ext2/3 one. If
This is a good idea! The boot script already tries to load the Kernel from NAND
or SD wherever it is successfull.
> there is an advantage of having uImage on the first partition, then such
> a solution would allow the user to choose whatever he deems best for
> himself without him having to touch boot.scr.
> So what do you think?
I think it works both ways. Wiithout significant advantages or
disadvantages of either solution.
But we are free and open source - and therefore you are free to spin your own
variant(s) - even a different boot.scr. Distributions (SHR, QtMoko etc.)
can adopt either method they like. It may also be better to distribute
images as dd files instead of a makesd script (although they are tied
to a specific SD card size).
More information about the Gta04-owner