RFC: kernel.bbclass and collie changes

RFC: kernel.bbclass and collie changes

[Thomas Kunze]

Hi all,

recently I finished a version of the spi driver for collie that is stable enough to use it as rootfs.
I already changed linux-rp to use mmc as root for collie but the resulting kernel is to large to fit
into flash. My solution is to flash a small initramfsed kernel that mounts the mmc card and kexecs
the real kernel from there.

How to use it:
1.) Apply the patch and build and image.  
2.) Rename zImage-collie-initramfs-kexec-image.bin to zImage.bin and flash as usual.
3.) untar your image to and ext2 formated card.
4.) pluck card into collie and switch on ;)

The only thing that affects non-collie builds is the change to device-table-minimal.txt. 
(I think nobody besides me uses the initramfs stuff ;)

Regards,
Thomas


#
# old_revision [d2f1a9f3ef64d23cec1e794848e1bb2ac1a92e63]
#
# patch "classes/kernel.bbclass"
#  from [7cbc09d4f4fd3e7051928da4ba4f8a6034393be9]
#    to [1a63b385323bcf314f65bd05cc5963ec6180ad6d]
# 
# patch "conf/machine/collie.conf"
#  from [c23a85835bc13ac978f36742cfc8ccf5880e0ec8]
#    to [aaae77a5a101fd08c9c0ca4d7f3257dd366367c4]
# 
# patch "conf/machine/include/zaurus-2.6.inc"
#  from [f56c5d7f00ad90430d1cfa3e9ff6283245f5e5c6]
#    to [08ade12cfdbf640f48c99ad3ad0be3a17ec5b626]
# 
# patch "files/device_table-minimal.txt"
#  from [3bd5796d9d4d302802ffbab0580fb8dc852b27c9]
#    to [dc5b02b6b72706c570908f014c45cafb6301c452]
#
============================================================
--- classes/kernel.bbclass	7cbc09d4f4fd3e7051928da4ba4f8a6034393be9
+++ classes/kernel.bbclass	1a63b385323bcf314f65bd05cc5963ec6180ad6d
@@ -91,13 +91,31 @@ do_builtin_initramfs() {
 	 if [ ! -z "${INITRAMFS_IMAGE}" ]; then
 		unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
 		cp "${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.cpio.gz" usr/initramfs_data.cpio.gz
+		
+		if [ -e "../initramfs-config-${MACHINE}" ]; then
+			cp .config config.bak
+			cp ../initramfs-config-${MACHINE} .config
+		fi
+		
 		oe_runmake ${KERNEL_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}"
 	
+		if [ ! -z "${KERNEL_IMAGE_MAXSIZE}" ]; then
+        		size=`ls -l arch/${ARCH}/boot/${KERNEL_IMAGETYPE} | awk '{ print $5}'`
+        		if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
+                		rm arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
+				die  "This kernel with buildin initramfs (size=$size > ${KERNEL_IMAGE_MAXSIZE}) is too big for your device. Please reduce the size of the kernel by making more of it modular, or reduce the size it the initramfs-image"
+        		fi
+    		fi
+		
 		install -d ${DEPLOY_DIR_IMAGE}
 		install -m 0644 arch/${ARCH}/boot/${KERNEL_IMAGETYPE} ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}-${INITRAMFS_IMAGE}.bin
 		package_stagefile_shell ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGE_BASE_NAME}-${INITRAMFS_IMAGE}.bin
-	
-		# Make sure to kill injected initramfs, in case someone will do "-c compile -f"
+		
+		
+		# Make sure to kill injected initramfs and config, in case someone will do "-c compile -f"
+		if [ -e "../initramfs-config-${MACHINE}" ]; then
+			cp config.bak .config
+		fi
 		rm usr/initramfs_data.cpio.gz
 		
 		cd ${DEPLOY_DIR_IMAGE}
@@ -468,7 +486,7 @@ do_sizecheck() {
 # Support checking the kernel size since some kernels need to reside in partitions
 # with a fixed length or there is a limit in transferring the kernel to memory
 do_sizecheck() {
-	if [ ! -z "${KERNEL_IMAGE_MAXSIZE}" ]; then
+	if [ ! -z "${KERNEL_IMAGE_MAXSIZE}" -a -z "${DONT_CHECK_KERNELSIZE}"]; then
         	size=`ls -l arch/${ARCH}/boot/${KERNEL_IMAGETYPE} | awk '{ print $5}'`
         	if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
                 	rm arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
============================================================
--- conf/machine/collie.conf	c23a85835bc13ac978f36742cfc8ccf5880e0ec8
+++ conf/machine/collie.conf	aaae77a5a101fd08c9c0ca4d7f3257dd366367c4
@@ -16,3 +16,9 @@ ROOT_FLASH_SIZE = "14"
 
 ROOT_FLASH_SIZE = "14"
 # actually 14680064, see EXTRA_IMAGECMD above
+
+# we store kernel images in rootfs and only a minimal initramfs kernel in mtd1 for booting other kernels
+INITRAMFS_IMAGE= "initramfs-kexec-image"
+DONT_CHECK_KERNELSIZE = "1"
+
+XSERVER = "xserver-kdrive-fbdev"
============================================================
--- conf/machine/include/zaurus-2.6.inc	f56c5d7f00ad90430d1cfa3e9ff6283245f5e5c6
+++ conf/machine/include/zaurus-2.6.inc	08ade12cfdbf640f48c99ad3ad0be3a17ec5b626
@@ -72,4 +72,6 @@ RDEPENDS_kernel-base = ""
 
 # Don't include kernels in standard images for Zaurus machines
 RDEPENDS_kernel-base = ""
+# collie is an exception. We use mmc as root, include kernel and use another small kernel to boot it.
+RDEPENDS_kernel-base_collie = "kernel-image" 
 KERNEL_IMAGETYPE = "zImage"
============================================================
--- files/device_table-minimal.txt	3bd5796d9d4d302802ffbab0580fb8dc852b27c9
+++ files/device_table-minimal.txt	dc5b02b6b72706c570908f014c45cafb6301c452
@@ -29,3 +29,4 @@
 /dev/random	c	644	0	0	1	8	-	-	-
 /dev/urandom	c	644	0	0	1	9	-	-	-
 /dev/ptmx	c	644	0	0	5	2	-	-	-
+/dev/mmcblk0p1	b	6600	0	6	179	1	-	-	-

Re: RFC: kernel.bbclass and collie changes

[Tom Rini]

On Fri, Jul 25, 2008 at 01:56:12AM +0200, Thomas Kunze wrote:

[snip]
> ============================================================
>  	
> +		if [ ! -z "${KERNEL_IMAGE_MAXSIZE}" ]; then
> +        		size=`ls -l arch/${ARCH}/boot/${KERNEL_IMAGETYPE} | awk '{ print $5}'`

I've got a bug and patch (4450) to fix the other instance of this,
please use ${KERNEL_OUTPUT} instead.

-- 
Tom Rini

Re: RFC: kernel.bbclass and collie changes

[Andrea Adami]

Thomas,

> I've got a bug and patch (4450) to fix the other instance of this,
> please use ${KERNEL_OUTPUT} instead.


while you're there please weak-assign too:

 KERNEL_IMAGETYPE ?= "zImage"

Andrea

Re: RFC: kernel.bbclass and collie changes

[Marcin Juszkiewicz]

On Friday 25 of July 2008 09:44:20 Andrea Adami wrote:
> Thomas,
>
> > I've got a bug and patch (4450) to fix the other instance of this,
> > please use ${KERNEL_OUTPUT} instead.
>
> while you're there please weak-assign too:
>
>  KERNEL_IMAGETYPE ?= "zImage"

Thats default set by kernel.bbclass

Re: RFC: kernel.bbclass and collie changes

[Andrea Adami]

>>while you're there please weak-assign too:
>>
>> KERNEL_IMAGETYPE ?= "zImage"

> Thats default set by kernel.bbclass

I meant in zaurus-2.6.inc

thx

Andrea

Re: RFC: kernel.bbclass and collie changes

[Tom Rini]

On Fri, Jul 25, 2008 at 10:09:04AM +0200, Andrea Adami wrote:
> >>while you're there please weak-assign too:
> >>
> >> KERNEL_IMAGETYPE ?= "zImage"
> 
> > Thats default set by kernel.bbclass
> 
> I meant in zaurus-2.6.inc

Er, isn't that at the level where you know what the board needs and do
want to enforce build choices?

-- 
Tom Rini

Re: RFC: kernel.bbclass and collie changes

[Thomas Kunze]

Tom Rini wrote:
> On Fri, Jul 25, 2008 at 10:09:04AM +0200, Andrea Adami wrote:
>   
>>>> while you're there please weak-assign too:
>>>>
>>>> KERNEL_IMAGETYPE ?= "zImage"
>>>>         
>>> Thats default set by kernel.bbclass
>>>       
>> I meant in zaurus-2.6.inc
>>     
>
> Er, isn't that at the level where you know what the board needs and do
> want to enforce build choices?
>   
In theory yes. But if you replaced sharp bootloader with u-boot then you
need to change it.
But these changes can be done after the RFCed stuff is in.

Re: RFC: kernel.bbclass and collie changes

[Phil Blundell]

On Fri, 2008-07-25 at 01:56 +0200, Thomas Kunze wrote:
> +/dev/mmcblk0p1	b	6600	0	6	179	1	-	-	-

Is that "6600" really correct?

It does also seem bit odd having an mmc device in the "minimal" device
table.  I can understand why you need it on collie but I am not sure it
is all that desirable for device-table-minimal.txt to become the union
of the devices that everybody needs on their favourite platform for
booting purposes.  Since this is truly a machine specific thing I would
be inclined to use a separate file, or a collie-specific catenation onto
the installed copy.

p.

Re: RFC: kernel.bbclass and collie changes

[Thomas Kunze]

Phil Blundell wrote:
> On Fri, 2008-07-25 at 01:56 +0200, Thomas Kunze wrote:
>   
>> +/dev/mmcblk0p1	b	6600	0	6	179	1	-	-	-
>>     
>
> Is that "6600" really correct?
>   
Of course not. Just a typo.
> It does also seem bit odd having an mmc device in the "minimal" device
> table.  I can understand why you need it on collie but I am not sure it
> is all that desirable for device-table-minimal.txt to become the union
> of the devices that everybody needs on their favourite platform for
> booting purposes.  Since this is truly a machine specific thing I would
> be inclined to use a separate file, or a collie-specific catenation onto
> the installed copy.
>   
I see your point. But OTOH we have 20 hda*, 9 serial consoles and 16 mtd
nodes in there. So its hardly minimal. In my opinion it doesn't hurt to add
a further node.

Re: RFC: kernel.bbclass and collie changes

[Richard Purdie]

On Sat, 2008-07-26 at 11:48 +0200, Thomas Kunze wrote:
> Phil Blundell wrote:
> > On Fri, 2008-07-25 at 01:56 +0200, Thomas Kunze wrote:
> >   
> >> +/dev/mmcblk0p1	b	6600	0	6	179	1	-	-	-
> >>     
> >
> > Is that "6600" really correct?
> >   
> Of course not. Just a typo.
> > It does also seem bit odd having an mmc device in the "minimal" device
> > table.  I can understand why you need it on collie but I am not sure it
> > is all that desirable for device-table-minimal.txt to become the union
> > of the devices that everybody needs on their favourite platform for
> > booting purposes.  Since this is truly a machine specific thing I would
> > be inclined to use a separate file, or a collie-specific catenation onto
> > the installed copy.
> >   
> I see your point. But OTOH we have 20 hda*, 9 serial consoles and 16 mtd
> nodes in there. So its hardly minimal. In my opinion it doesn't hurt to add
> a further node.

As mentioned on irc, there is a more fundamental problem. The mmc block
device number is assigned from the dynamic pool, not the static one. If
you have any other device which uses a dynamic block number the file
becomes incorrect. You therefore really have to create these nodes using
udev/mdev or some custom script which finds the right value from sysfs.

Regards,

Richard

Re: RFC: kernel.bbclass and collie changes

[Thomas Kunze]

Richard Purdie wrote:
> On Sat, 2008-07-26 at 11:48 +0200, Thomas Kunze wrote:
>   
>> Phil Blundell wrote:
>>     
>>> On Fri, 2008-07-25 at 01:56 +0200, Thomas Kunze wrote:
>>>   
>>>       
>>>> +/dev/mmcblk0p1	b	6600	0	6	179	1	-	-	-
>>>>     
>>>>         
>>> Is that "6600" really correct?
>>>   
>>>       
>> Of course not. Just a typo.
>>     
>>> It does also seem bit odd having an mmc device in the "minimal" device
>>> table.  I can understand why you need it on collie but I am not sure it
>>> is all that desirable for device-table-minimal.txt to become the union
>>> of the devices that everybody needs on their favourite platform for
>>> booting purposes.  Since this is truly a machine specific thing I would
>>> be inclined to use a separate file, or a collie-specific catenation onto
>>> the installed copy.
>>>   
>>>       
>> I see your point. But OTOH we have 20 hda*, 9 serial consoles and 16 mtd
>> nodes in there. So its hardly minimal. In my opinion it doesn't hurt to add
>> a further node.
>>     
>
> As mentioned on irc, there is a more fundamental problem. The mmc block
> device number is assigned from the dynamic pool, not the static one. If
> you have any other device which uses a dynamic block number the file
> becomes incorrect. You therefore really have to create these nodes using
> udev/mdev or some custom script which finds the right value from sysfs.
>   
That's bad. Ok than its a bad idea to include this in the default device
table. Using sysdev would need
an extra C program as there is no regexpr support in klibc and hence no
sed/grep etc.
As I don't have any other devices enabled that use a dynamic block
number (Otherwise it wouldn't work ;),
I will create separate file for the mmc node for now.