Le 24/02/2012 17:03, Alexander Graf a écrit :

Hi Guillaume,

On 24.02.2012, at 16:51, Guillaume Gardet wrote:

...

Hi,

I downloaded images from : http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ for the beagleboard xM Ah, cool, thanks a lot for trying it out! :) Thanks for the fast answer.

...

I managed to boot using this kernel and rootfs but I have no modules loaded and there is nothing in /lib/modules, so I can only use built-in drivers.

The thing is I did not used initrd since I am not sure how to handle it. I think initrd has all the kernel modules. Yeah, most device drivers are part of the initrd. And since we use LVM for /, you definitely need an initrd.

...

Could you tell me how to use the initrd with u-boot, please? If you just take the beagle image and directly dump it onto your board, it should load the kiwi initrd with our kernel automatically. IIRC things will break after reboot, because mkinitrd isn't fixed yet, but you should be able to properly boot up the image at least once.

I do not think it will work since there is no MLO nor u-boot.bin nor boot.scr script in the archive. If I dd files, it won't boot since it is not an image file (and there is no MLO). If I copy files (cp) it won't work since u-boot does not know about it. I need the kernel cmdline to boot properly. Any idea ? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 24.02.2012, at 17:24, Guillaume Gardet wrote:

Le 24/02/2012 17:19, Guillaume Gardet a écrit :

...

Le 24/02/2012 17:03, Alexander Graf a écrit :

...

Hi Guillaume,

On 24.02.2012, at 16:51, Guillaume Gardet wrote:

...

Hi,

I downloaded images from : http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ for the beagleboard xM Ah, cool, thanks a lot for trying it out! :) Thanks for the fast answer. I managed to boot using this kernel and rootfs but I have no modules loaded and there is nothing in /lib/modules, so I can only use built-in drivers.

The thing is I did not used initrd since I am not sure how to handle it. I think initrd has all the kernel modules. Yeah, most device drivers are part of the initrd. And since we use LVM for /, you definitely need an initrd.

...

Could you tell me how to use the initrd with u-boot, please? If you just take the beagle image and directly dump it onto your board, it should load the kiwi initrd with our kernel automatically. IIRC things will break after reboot, because mkinitrd isn't fixed yet, but you should be able to properly boot up the image at least once. I do not think it will work since there is no MLO nor u-boot.bin nor boot.scr script in the archive. If I dd files, it won't boot since it is not an image file (and there is no MLO). If I copy files (cp) it won't work since u-boot does not know about it. I need the kernel cmdline to boot properly.

Ooops. I just noticed there are 2 files: LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw.bz2 LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6-raw.tar.bz2

I will try the .raw right now and tell it if it is working!

Yeah, I still need to figure out why we generate 2 files :o. Also, you won't find MLO - it's directly written to offset 128kb on the raw image for us, since that allows us to be completely FAT-less :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 24.02.2012, at 18:07, Guillaume Gardet wrote:

Le 24/02/2012 17:44, Alexander Graf a écrit :

...

On 24.02.2012, at 17:24, Guillaume Gardet wrote:

...

Le 24/02/2012 17:19, Guillaume Gardet a écrit :

...

Le 24/02/2012 17:03, Alexander Graf a écrit :

...

Hi Guillaume,

On 24.02.2012, at 16:51, Guillaume Gardet wrote:

...

Hi,

I downloaded images from : http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ for the beagleboard xM Ah, cool, thanks a lot for trying it out! :) Thanks for the fast answer. I managed to boot using this kernel and rootfs but I have no modules loaded and there is nothing in /lib/modules, so I can only use built-in drivers.

The thing is I did not used initrd since I am not sure how to handle it. I think initrd has all the kernel modules. Yeah, most device drivers are part of the initrd. And since we use LVM for /, you definitely need an initrd.

...

Could you tell me how to use the initrd with u-boot, please? If you just take the beagle image and directly dump it onto your board, it should load the kiwi initrd with our kernel automatically. IIRC things will break after reboot, because mkinitrd isn't fixed yet, but you should be able to properly boot up the image at least once. I do not think it will work since there is no MLO nor u-boot.bin nor boot.scr script in the archive. If I dd files, it won't boot since it is not an image file (and there is no MLO). If I copy files (cp) it won't work since u-boot does not know about it. I need the kernel cmdline to boot properly. Ooops. I just noticed there are 2 files: LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw.bz2 LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6-raw.tar.bz2

I will try the .raw right now and tell it if it is working!

Yeah, I still need to figure out why we generate 2 files :o. Also, you won't find MLO - it's directly written to offset 128kb on the raw image for us, since that allows us to be completely FAT-less :)

The -raw.tar image is usefull to get files and using those as we want. The .raw is very good to dd it.

It is nice to be FAT-less but how do you handle update? Well, MLO and u-boot do not need lots of update.

U-boot can still be updated and resides in /boot.

I do that: sudo dd if=LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw of=/dev/sdb where /dev/sdb is my µSD card. But I cannot boot anymore. Any idea? Do I need to format my card in a special way?

No, it should just work like that. Do you get any output on the serial console? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 24.02.2012, at 18:13, Guillaume Gardet wrote:

Le 24/02/2012 18:09, Alexander Graf a écrit :

...

On 24.02.2012, at 18:07, Guillaume Gardet wrote:

...

Le 24/02/2012 17:44, Alexander Graf a écrit :

...

On 24.02.2012, at 17:24, Guillaume Gardet wrote:

...

Le 24/02/2012 17:19, Guillaume Gardet a écrit :

...

Le 24/02/2012 17:03, Alexander Graf a écrit : > Hi Guillaume, > > On 24.02.2012, at 16:51, Guillaume Gardet wrote: > >> Hi, >> >> I downloaded images from : http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ >> for the beagleboard xM > Ah, cool, thanks a lot for trying it out! :) Thanks for the fast answer. >> I managed to boot using this kernel and rootfs but I have no modules loaded and there is nothing in /lib/modules, so I can only use built-in drivers. >> >> The thing is I did not used initrd since I am not sure how to handle it. I think initrd has all the kernel modules. > Yeah, most device drivers are part of the initrd. And since we use LVM for /, you definitely need an initrd. > >> Could you tell me how to use the initrd with u-boot, please? > If you just take the beagle image and directly dump it onto your board, it should load the kiwi initrd with our kernel automatically. IIRC things will break after reboot, because mkinitrd isn't fixed yet, but you should be able to properly boot up the image at least once. I do not think it will work since there is no MLO nor u-boot.bin nor boot.scr script in the archive. If I dd files, it won't boot since it is not an image file (and there is no MLO). If I copy files (cp) it won't work since u-boot does not know about it. I need the kernel cmdline to boot properly. Ooops. I just noticed there are 2 files: LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw.bz2 LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6-raw.tar.bz2

I will try the .raw right now and tell it if it is working! Yeah, I still need to figure out why we generate 2 files :o. Also, you won't find MLO - it's directly written to offset 128kb on the raw image for us, since that allows us to be completely FAT-less :) The -raw.tar image is usefull to get files and using those as we want. The .raw is very good to dd it.

It is nice to be FAT-less but how do you handle update? Well, MLO and u-boot do not need lots of update.

U-boot can still be updated and resides in /boot.

Once monted on my PC I can also see MLO.

Yup, but it's unused :).

...

...

I do that: sudo dd if=LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw of=/dev/sdb where /dev/sdb is my µSD card. But I cannot boot anymore. Any idea? Do I need to format my card in a special way? No, it should just work like that. Do you get any output on the serial console?

No, nothing. I think MLO is not found.

That is odd. Could you please try to rewrite MLO to offset 128kb on the sd card? If that doesn't work, maybe we should try to take a known-good x-loader and dump that on there. Unfortunately, we need x-loader with a special header for raw boot which usually isn't present with the FAT based MLOs. Do you have source code to an x-loader that you're sure works? Or could you try to use the MLO that you found on the SD card with a FAT partition? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 24.02.2012, at 19:34, Guillaume Gardet wrote:

Le 24/02/2012 18:58, Alexander Graf a écrit :

...

On 24.02.2012, at 18:13, Guillaume Gardet wrote:

...

Le 24/02/2012 18:09, Alexander Graf a écrit :

...

On 24.02.2012, at 18:07, Guillaume Gardet wrote:

...

Le 24/02/2012 17:44, Alexander Graf a écrit :

...

On 24.02.2012, at 17:24, Guillaume Gardet wrote:

> Le 24/02/2012 17:19, Guillaume Gardet a écrit : >> Le 24/02/2012 17:03, Alexander Graf a écrit : >>> Hi Guillaume, >>> >>> On 24.02.2012, at 16:51, Guillaume Gardet wrote: >>> >>>> Hi, >>>> >>>> I downloaded images from : http://download.opensuse.org/repositories/openSUSE:/Factory:/ARM/images/ >>>> for the beagleboard xM >>> Ah, cool, thanks a lot for trying it out! >> :) Thanks for the fast answer. >>>> I managed to boot using this kernel and rootfs but I have no modules loaded and there is nothing in /lib/modules, so I can only use built-in drivers. >>>> >>>> The thing is I did not used initrd since I am not sure how to handle it. I think initrd has all the kernel modules. >>> Yeah, most device drivers are part of the initrd. And since we use LVM for /, you definitely need an initrd. >>> >>>> Could you tell me how to use the initrd with u-boot, please? >>> If you just take the beagle image and directly dump it onto your board, it should load the kiwi initrd with our kernel automatically. IIRC things will break after reboot, because mkinitrd isn't fixed yet, but you should be able to properly boot up the image at least once. >> I do not think it will work since there is no MLO nor u-boot.bin nor boot.scr script in the archive. >> If I dd files, it won't boot since it is not an image file (and there is no MLO). >> If I copy files (cp) it won't work since u-boot does not know about it. I need the kernel cmdline to boot properly. > Ooops. I just noticed there are 2 files: > LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw.bz2 > LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6-raw.tar.bz2 > > I will try the .raw right now and tell it if it is working! Yeah, I still need to figure out why we generate 2 files :o. Also, you won't find MLO - it's directly written to offset 128kb on the raw image for us, since that allows us to be completely FAT-less :) The -raw.tar image is usefull to get files and using those as we want. The .raw is very good to dd it.

It is nice to be FAT-less but how do you handle update? Well, MLO and u-boot do not need lots of update. U-boot can still be updated and resides in /boot. Once monted on my PC I can also see MLO.

Yup, but it's unused :).

...

...

...

I do that: sudo dd if=LimeJeOS-openSUSE-Factory-ARM-beagle.armv7l-1.12.1-Build6.6.raw of=/dev/sdb where /dev/sdb is my µSD card. But I cannot boot anymore. Any idea? Do I need to format my card in a special way? No, it should just work like that. Do you get any output on the serial console? No, nothing. I think MLO is not found. That is odd. Could you please try to rewrite MLO to offset 128kb on the sd card? If that doesn't work, maybe we should try to take a known-good x-loader and dump that on there. Unfortunately, we need x-loader with a special header for raw boot which usually isn't present with the FAT based MLOs.

Well, I noticed something funny! I dd the image and then repartitionned and reformat my SD card with 1 FAT partition and copy nothing and tried to boot and openSUSE MLO started: ************************************************************ Texas Instruments X-Loader 1.5.0 (Feb 6 2012 - 17:53:20) Beagle xM Failed to mount ext2 filesystem... Reading boot sector fat load failed, trying ext2 u-boot.bin not found or blank nand contents - attempting serial boot . . . ## Ready for binary (kermit) download to 0x80008000 at 115200 bps... ************************************************************

So MLO (x-loader) from openSUSE is here and able to boot. Very Strange.

...

Do you have source code to an x-loader that you're sure works? Or could you try to use the MLO that you found on the SD card with a FAT partition?

x-loader/MLO I use is here: *********************************************************** git clone git://gitorious.org/x­load­omap3/mainline.git x­loader cd x­loader make distclean make omap3530beagle_config make CROSS_COMPILE=arm­-none­-linux­-gnueabi­ ***********************************************************

But openSUSE MLO seems to work.

Maybe the problem comes from partitions?

When MLO does not start, fdisk tells: *********************************************************** Disk /dev/sdb: 3941 MB, 3941597184 bytes 122 heads, 62 sectors/track, 1017 cylinders, total 7698432 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xf6569bc1

Device Boot Start End Blocks Id System /dev/sdb1 * 2048 309247 153600 83 Linux /dev/sdb2 309248 1398783 544768 8e Linux LVM ***********************************************************

When MLO starts, fdisk tells: *********************************************************** Disk /dev/sdb: 3941 MB, 3941597184 bytes 72 heads, 16 sectors/track, 6682 cylinders, total 7698432 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xa2d775df

Device Boot Start End Blocks Id System /dev/sdb1 * 2048 7698431 3848192 83 Linux ***********************************************************

So, heads, sectors and cylinders are different... Could it be a problem?

That is very likely, Marcus, Arnd, Peter, any ideas? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi,

The start sector 2048 is the only thing that matters here to some tools. The sdcard standard requires all devices to have a single FAT32 partition starting at sector 8192, while some ancient (broken) versions of xloader required the first partition to start at sector 63, which is what old versions of fdisk used to do ms-dos compatibility.

With the two partition layouts above, the first one is halfway sensible, because it actually fits the entire drive into the C/H/S layout with 122* 62*1017 blocks. The second one is not strictly valid in some tools because larger than 1024 cylinders should only be used together with 255 heads and 63 sectors on devices that have more than 8GB. For a 4GB card, the most reliable layout would be 128 heads and 32 sectors, because that lets you align the partitions to 4 MB while also allowing fdisk to detect the layout (which it cannot do otherwise). This trick does not work for 8GB cards though.

What I think we do in Linaro is to always force a 255*63*xxxx layout when creating the partitions and aligning the partitions to 4MB but not a cylinder boundary.

I think what we do in kiwi is close to that. the geometry information if not set by options is taken from what parted thinks about it. As this happens through loop devices when the image is build the faked geomtry used by the loop driver is always 255*63*xxxx. The start sectors are aligned to be %8 clean and the to the cylinder boundary. So far I did not had any trouble with that setup on 4G SD cards (did not try on 8G cards though). For MLO loading I think only the start address might matter... not sure The start sector is set to 2048 because it's the default :) It's possible to override that with kiwi --create ... --start-sector XX at build time of the image Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 26.02.2012, at 10:25, Arnd Bergmann wrote:

On Saturday 25 February 2012, Marcus Schäfer wrote:

...

The start sectors are aligned to be %8 clean and the to the cylinder boundary. So far I did not had any trouble with that setup on 4G SD cards (did not try on 8G cards though). For MLO loading I think only the start address might matter... not sure

Aligning to 8 sectors is not going to help at all, that is much smaller than the normal erase block size (4MB) and also smaller than typical page sizes (8kb or 16kb). If you want good performance, you should always align to 4MB or more. Using the regular geometry (255/63/1024), that will never be cylinder aligned, which is ok. Don't try to do cylinder alignment.

Hrm - does that also have any implications on not being able to boot from the beagleboard? :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 26/02/2012 21:11, Arnd Bergmann a écrit :

On Sunday 26 February 2012, Alexander Graf wrote:

...

On 26.02.2012, at 10:25, Arnd Bergmann wrote:

...

...

The start sectors are aligned to be %8 clean and the to the cylinder boundary. So far I did not had any trouble with that setup on 4G SD cards (did not try on 8G cards though). For MLO loading I think only the start address might matter... not sure Aligning to 8 sectors is not going to help at all, that is much smaller than the normal erase block size (4MB) and also smaller

On Saturday 25 February 2012, Marcus Schäfer wrote: than typical page sizes (8kb or 16kb). If you want good performance, you should always align to 4MB or more. Using the regular geometry (255/63/1024), that will never be cylinder aligned, which is ok. Don't try to do cylinder alignment. Hrm - does that also have any implications on not being able to boot from the beagleboard? :)

I tried the beagle image of today and it does not help. fdisk output: (only the end of 2nd partition seems to have moved and is no more Linux LVM type but Linux type) *********************************************************** Disk /dev/sdb: 3941 MB, 3941597184 bytes 122 heads, 62 sectors/track, 1017 cylinders, total 7698432 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x929ea0a6 Device Boot Start End Blocks Id System /dev/sdb1 * 2048 309247 153600 83 Linux /dev/sdb2 309248 1368063 529408 83 Linux ***********************************************************

...

I only know of one bug on beagleboard where an old xloader requires the boot partition to start at sector 63 independent of the geometry. It is well possible that there are other bugs though. Which x-loader is currently used for openSUSE?

Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 27/02/2012 19:10, Alexander Graf a écrit :

On 02/27/2012 07:08 PM, Guillaume Gardet wrote:

...

Le 26/02/2012 21:11, Arnd Bergmann a écrit :

...

On Sunday 26 February 2012, Alexander Graf wrote:

...

On 26.02.2012, at 10:25, Arnd Bergmann wrote:

...

...

The start sectors are aligned to be %8 clean and the to the cylinder boundary. So far I did not had any trouble with that setup on 4G SD cards (did not try on 8G cards though). For MLO loading I think only the start address might matter... not sure Aligning to 8 sectors is not going to help at all, that is much smaller than the normal erase block size (4MB) and also smaller

On Saturday 25 February 2012, Marcus Schäfer wrote: than typical page sizes (8kb or 16kb). If you want good performance, you should always align to 4MB or more. Using the regular geometry (255/63/1024), that will never be cylinder aligned, which is ok. Don't try to do cylinder alignment. Hrm - does that also have any implications on not being able to boot from the beagleboard? :) I tried the beagle image of today and it does not help.

fdisk output: (only the end of 2nd partition seems to have moved and is no more Linux LVM type but Linux type)

So if you remove the second partition, it works?

No. My previous trick no more works. Well, I tried another thing. I dd if=/dev/zero to erase the first sectors to be sure to have a good card to start and then dd the raw image. Then I tried to boot and get a "60" on the serial port which means no suitable MLO where found where it is ecpected!

...

***********************************************************

Disk /dev/sdb: 3941 MB, 3941597184 bytes 122 heads, 62 sectors/track, 1017 cylinders, total 7698432 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x929ea0a6

Device Boot Start End Blocks Id System /dev/sdb1 * 2048 309247 153600 83 Linux /dev/sdb2 309248 1368063 529408 83 Linux

***********************************************************

...

I only know of one bug on beagleboard where an old xloader requires the boot partition to start at sector 63 independent of the geometry. It is well possible that there are other bugs though. Which x-loader is currently used for openSUSE?

X-loader is MLO and you don't even get that far, so I don't think that's the issue you're hitting here. It looks more like a bootrom bug.

Yes, MLO is an x-loader signed. Could you give me the sources so that I can have a look at it, please? I tried the openSUSE MLO on a FAT partition and it boot on it since the "60" is no more shown but I get nothing on the serial port which means MLO is booted but crashed somewhere. If you want info about MLO (for DM3730, means beagleboard xM version), have a look on this PDF from TI (Pages 3593+): http://www.ti.com/lit/ug/sprugn4o/sprugn4o.pdf I think, there is a problem on the MLO file itself and maybe also on the MLO location for the raw mode. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 27/02/2012 22:01, Alexander Graf a écrit :

On 27.02.2012, at 20:05, Guillaume Gardet wrote:

...

[...]

...

No. My previous trick no more works. Well, I tried another thing. I dd if=/dev/zero to erase the first sectors to be sure to have a good card to start and then dd the raw image. Then I tried to boot and get a "60" on the serial port which means no suitable MLO where found where it is ecpected! Hrm - weird. Could you please try to dd if=/dev/zero the first couple MB and then just dd MLO straight into offset 128kb? Try again for offset 0.

With openSUSE MLO it boots something (since it does not try UART boot, which print 60) but nothing is printed on screen (crash?). With the openSUSE sources and patches with a code sourcery toolchain, I get a running MLO. So, it should be a problem with the toolchain or some optimisations flag (which are not supported by beagleboard?). Could you please provide the full compilation line to see what flags could lead to problems? Or maybe did you use the pandaboard MLO instead of the beagle MLO? That could explain why it start to boot but crash. Note that u-boot.bin do not boot either. It seems I cannot download u-boot-linaro-20111213.tar.bz2 from https://build.opensuse.org/package/files?package=u-boot-omap3beagle&project=openSUSE%3AFactory%3AARM to try to build it. COuld you please tell me where I can download it? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 29.02.2012, at 20:55, Alexander Graf wrote:

On 29.02.2012, at 20:26, Guillaume Gardet wrote:

...

Le 27/02/2012 22:01, Alexander Graf a écrit :

...

On 27.02.2012, at 20:05, Guillaume Gardet wrote:

...

[...]

...

No. My previous trick no more works. Well, I tried another thing. I dd if=/dev/zero to erase the first sectors to be sure to have a good card to start and then dd the raw image. Then I tried to boot and get a "60" on the serial port which means no suitable MLO where found where it is ecpected! Hrm - weird. Could you please try to dd if=/dev/zero the first couple MB and then just dd MLO straight into offset 128kb? Try again for offset 0.

With openSUSE MLO it boots something (since it does not try UART boot, which print 60) but nothing is printed on screen (crash?). With the openSUSE sources and patches with a code sourcery toolchain, I get a running MLO. So, it should be a problem with the toolchain or some optimisations flag (which are not supported by beagleboard?).

Very interesting. What I'm still not grasping is why you actually had a booting x-loader a while back.

Ok, so I have good and bad news on this. The good news is, it breaks in QEMU the same way. The bad news is, it breaks :): R00=40014060 R01=40304350 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=4020fcb0 R14=00000000 R15=40014168 PSR=400001df -Z-- A sys32 ---------------- IN: 0x40014168: e240001c sub r0, r0, #28 ; 0x1c 0x4001416c: e1a0f001 mov pc, r1 R00=40014044 R01=40304350 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=4020fcb0 R14=00000000 R15=40304350 PSR=400001df -Z-- A sys32 qemu: fatal: Trying to execute code outside RAM or ROM at 0x40304350 Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth wrote:

On Wed, Feb 29, 2012 at 16:32, Alexander Graf wrote:

...

Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. Wondering why we could'nt move to denx.com u-boot SPL instead of using x-loader MLO?

+1. SPL is the right choice today. Nishanth did a great job maintaining x-loader, but it was always a fork of u-boot and with SPL we've eliminated that fork. Thanks Nishanth for highlighting this. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 01/03/2012 10:44, Alexander Graf a écrit :

On 01.03.2012, at 09:04, Jason Kridner wrote:

...

...

On Wed, Feb 29, 2012 at 16:32, Alexander Graf wrote:

...

Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. Wondering why we could'nt move to denx.com u-boot SPL instead of using x-loader MLO? +1. SPL is the right choice today. Nishanth did a great job

On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth wrote: maintaining x-loader, but it was always a fork of u-boot and with SPL we've eliminated that fork. Thanks Nishanth for highlighting this. Yeah, good point. We already use SPL for the Panda, but somehow didn't manage to get the OMAP3 x-loader also based on it. I honestly don't remember why.

Just tried to compile u-boot with SPL and it is 329K which is greater than the 128K limit for beagleboard (OMAP3/DM37x). So we have to use MLO+u-boot.

But given the new issues, we probably should give it another try :). I'll try to hack on this in a spare minute. Or if anyone else wants to pick it up, please check the u-boot-omap4panda package in openSUSE:Factory:ARM on how it's done for OMAP4 :).

Alex

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 01/03/2012 13:17, Aneesh V a écrit :

On Thursday 01 March 2012 04:56 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 10:44, Alexander Graf a écrit :

...

On 01.03.2012, at 09:04, Jason Kridner wrote:

...

...

On Wed, Feb 29, 2012 at 16:32, Alexander Graf wrote:

...

Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. Wondering why we could'nt move to denx.com u-boot SPL instead of using x-loader MLO? +1. SPL is the right choice today. Nishanth did a great job

On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth wrote: maintaining x-loader, but it was always a fork of u-boot and with SPL we've eliminated that fork. Thanks Nishanth for highlighting this. Yeah, good point. We already use SPL for the Panda, but somehow didn't manage to get the OMAP3 x-loader also based on it. I honestly don't remember why.

Just tried to compile u-boot with SPL and it is 329K which is greater than the 128K limit for beagleboard (OMAP3/DM37x). So we have to use MLO+u-boot.

I tried building u-boot and SPL for beagle using recent mainline code. Here are the results:

SPL(MLO): 43828 bytes u-boot.bin: 329992 bytes - this seems to be what you have reported.

If I add my Thumb patches and enable Thumb for Beagle: SPL: 32420 bytes u-boot.bin: 248168 bytes

AFAIK, standard u-boot had never been less than 128 KB in the recent past. SPL will never be as big as 128K. Is there a confusion here? And what is the 128K limitation based on?

Oups, did only watch on u-boot.bin, not u-boot-spl.bin sorry. I thought we get only one file and save 1 stage but it does not. 128K limitation is due to ROM boot loader of OMAP3/DM37x SoC. What is the difference between SPL and MLO? Is it just an include of x-loader/MLO in u-boot? Maybe some improvments? Guillaume

br, Aneesh

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 01.03.2012, at 14:46, Aneesh V wrote:

On Thursday 01 March 2012 07:10 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 13:17, Aneesh V a écrit :

...

On Thursday 01 March 2012 04:56 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 10:44, Alexander Graf a écrit :

...

On 01.03.2012, at 09:04, Jason Kridner wrote:

...

On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth wrote: > On Wed, Feb 29, 2012 at 16:32, Alexander Graf wrote: >> Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. > Wondering why we could'nt move to denx.com u-boot SPL instead of using > x-loader MLO? +1. SPL is the right choice today. Nishanth did a great job maintaining x-loader, but it was always a fork of u-boot and with SPL we've eliminated that fork. Thanks Nishanth for highlighting this. Yeah, good point. We already use SPL for the Panda, but somehow didn't manage to get the OMAP3 x-loader also based on it. I honestly don't remember why.

Just tried to compile u-boot with SPL and it is 329K which is greater than the 128K limit for beagleboard (OMAP3/DM37x). So we have to use MLO+u-boot.

I tried building u-boot and SPL for beagle using recent mainline code. Here are the results:

SPL(MLO): 43828 bytes u-boot.bin: 329992 bytes - this seems to be what you have reported.

If I add my Thumb patches and enable Thumb for Beagle: SPL: 32420 bytes u-boot.bin: 248168 bytes

AFAIK, standard u-boot had never been less than 128 KB in the recent past. SPL will never be as big as 128K. Is there a confusion here? And what is the 128K limitation based on?

Oups, did only watch on u-boot.bin, not u-boot-spl.bin sorry. I thought we get only one file and save 1 stage but it does not. 128K limitation is due to ROM boot loader of OMAP3/DM37x SoC.

What is the difference between SPL and MLO? Is it just an include of x-loader/MLO in u-boot? Maybe some improvments?

SPL is almost same as x-loader, just that it is built out of mainline u-boot sources. So, you can pick and choose anything available in u-boot to create a tiny first stage bootloader which is called SPL.

Aneesh, I have a very strange effect now. If I take our MLO binary and dd it onto the disk at offset 128kb, the bootrom doesn't find anything. Putting it on sector 0 works. With the exact same binary. Could you please verify if you can see similar effects on OMAP3? Is raw boot supposed to work there? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 02.03.2012, at 09:15, Aneesh V wrote:

On Friday 02 March 2012 08:32 AM, Alexander Graf wrote:

...

On 01.03.2012, at 14:46, Aneesh V wrote:

...

On Thursday 01 March 2012 07:10 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 13:17, Aneesh V a écrit :

...

On Thursday 01 March 2012 04:56 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 10:44, Alexander Graf a écrit : > On 01.03.2012, at 09:04, Jason Kridner wrote: > >> On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth wrote: >>> On Wed, Feb 29, 2012 at 16:32, Alexander Graf wrote: >>>> Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. >>> Wondering why we could'nt move to denx.com u-boot SPL instead of using >>> x-loader MLO? >> +1. SPL is the right choice today. Nishanth did a great job >> maintaining x-loader, but it was always a fork of u-boot and with SPL >> we've eliminated that fork. Thanks Nishanth for highlighting this. > Yeah, good point. We already use SPL for the Panda, but somehow didn't manage to get the OMAP3 x-loader also based on it. I honestly don't remember why.

Just tried to compile u-boot with SPL and it is 329K which is greater than the 128K limit for beagleboard (OMAP3/DM37x). So we have to use MLO+u-boot.

I tried building u-boot and SPL for beagle using recent mainline code. Here are the results:

SPL(MLO): 43828 bytes u-boot.bin: 329992 bytes - this seems to be what you have reported.

If I add my Thumb patches and enable Thumb for Beagle: SPL: 32420 bytes u-boot.bin: 248168 bytes

AFAIK, standard u-boot had never been less than 128 KB in the recent past. SPL will never be as big as 128K. Is there a confusion here? And what is the 128K limitation based on?

Oups, did only watch on u-boot.bin, not u-boot-spl.bin sorry. I thought we get only one file and save 1 stage but it does not. 128K limitation is due to ROM boot loader of OMAP3/DM37x SoC.

What is the difference between SPL and MLO? Is it just an include of x-loader/MLO in u-boot? Maybe some improvments?

SPL is almost same as x-loader, just that it is built out of mainline u-boot sources. So, you can pick and choose anything available in u-boot to create a tiny first stage bootloader which is called SPL.

Aneesh, I have a very strange effect now. If I take our MLO binary and dd it onto the disk at offset 128kb, the bootrom doesn't find anything. Putting it on sector 0 works. With the exact same binary.

Could you please verify if you can see similar effects on OMAP3? Is raw boot supposed to work there?

I don't have easy access to OMAP3 boards anymore. But did you try erasing the flash at offset 0.

Well - sector 0 contains the MBR, which usually doesn't look like a CH ;).

Maybe, there is a valid header there for some reason? RAW mode should be supported for both NAND and MMC/SD.

Yeah, and raw mode works for me on sector 0, but not on sector 256, which the spec also mentions as valid. Do you know anyone who could try and debug to run SPL on offset 256 in raw mode? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2012/3/2 Alexander Graf

On 02.03.2012, at 11:06, Alexander Graf wrote:

...

On 02.03.2012, at 09:15, Aneesh V wrote:

...

On Friday 02 March 2012 08:32 AM, Alexander Graf wrote:

...

On 01.03.2012, at 14:46, Aneesh V wrote:

...

On Thursday 01 March 2012 07:10 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 13:17, Aneesh V a écrit : > On Thursday 01 March 2012 04:56 PM, Guillaume Gardet wrote: >> >> >> Le 01/03/2012 10:44, Alexander Graf a écrit : >>> On 01.03.2012, at 09:04, Jason Kridner wrote: >>> >>>> On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth >>>>  wrote: >>>>> On Wed, Feb 29, 2012 at 16:32, Alexander Graf >>>>>  wrote: >>>>>> Still need to figure out what exactly is going wrong there. >>>>>> But it's definitely the MLO code that's broken, not the boot rom. >>>>> Wondering why we could'nt move to denx.com u-boot SPL instead >>>>> of using >>>>> x-loader MLO? >>>> +1.  SPL is the right choice today.  Nishanth did a great job >>>> maintaining x-loader, but it was always a fork of u-boot and >>>> with SPL >>>> we've eliminated that fork.  Thanks Nishanth for highlighting >>>> this. >>> Yeah, good point. We already use SPL for the Panda, but somehow >>> didn't manage to get the OMAP3 x-loader also based on it. I honestly don't >>> remember why. >> >> Just tried to compile u-boot with SPL and it is 329K which is >> greater than the 128K limit for beagleboard (OMAP3/DM37x). So we have to use >> MLO+u-boot. > > I tried building u-boot and SPL for beagle using recent mainline > code. > Here are the results: > > SPL(MLO): 43828 bytes > u-boot.bin: 329992 bytes - this seems to be what you have reported. > > If I add my Thumb patches and enable Thumb for Beagle: > SPL:     32420 bytes > u-boot.bin: 248168 bytes > > AFAIK, standard u-boot had never been less than 128 KB in the > recent > past. SPL will never be as big as 128K. Is there a confusion here? > And > what is the 128K limitation based on?

Oups, did only watch on u-boot.bin, not u-boot-spl.bin sorry. I thought we get only one file and save 1 stage but it does not. 128K limitation is due to ROM boot loader of OMAP3/DM37x SoC.

What is the difference between SPL and MLO? Is it just an include of x-loader/MLO in u-boot? Maybe some improvments?

SPL is almost same as x-loader, just that it is built out of mainline u-boot sources. So, you can pick and choose anything available in u-boot to create a tiny first stage bootloader which is called SPL.

Aneesh, I have a very strange effect now. If I take our MLO binary and dd it onto the disk at offset 128kb, the bootrom doesn't find anything. Putting it on sector 0 works. With the exact same binary.

Could you please verify if you can see similar effects on OMAP3? Is raw boot supposed to work there?

I don't have easy access to OMAP3 boards anymore. But did you try erasing the flash at offset 0.

Well - sector 0 contains the MBR, which usually doesn't look like a CH ;).

...

Maybe, there is a valid header there for some reason? RAW mode should be supported for both NAND and MMC/SD.

Yeah, and raw mode works for me on sector 0, but not on sector 256, which the spec also mentions as valid.

Do you know anyone who could try and debug to run SPL on offset 256 in raw mode?

Ouch.

After a further bit of debugging, I managed to narrow it down:

 $ dd if=/dev/urandom of=/dev/sdc bs=1 count=4

That breaks the raw boot. If instead, there are zeros, it works. Now 2 questions arise from this:

 1) Why do we have anything in the executable area of the MBR on ARM? What is this code?  2) Why does the bootrom behave differently based on the executable area? Shouldn't it just search for the CH and if it can't find one, pass on?

without CH, https://github.com/nmenon/omap-u-boot-utils/blob/master/src/gpsign.c#L609 might give a clue - there are certain signature values that CH TOC should contain.. Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 02.03.2012, at 17:09, Alexander Graf wrote:

On 02.03.2012, at 11:06, Alexander Graf wrote:

...

On 02.03.2012, at 09:15, Aneesh V wrote:

...

On Friday 02 March 2012 08:32 AM, Alexander Graf wrote:

...

On 01.03.2012, at 14:46, Aneesh V wrote:

...

On Thursday 01 March 2012 07:10 PM, Guillaume Gardet wrote:

...

Le 01/03/2012 13:17, Aneesh V a écrit : > On Thursday 01 March 2012 04:56 PM, Guillaume Gardet wrote: >> >> >> Le 01/03/2012 10:44, Alexander Graf a écrit : >>> On 01.03.2012, at 09:04, Jason Kridner wrote: >>> >>>> On Wed, Feb 29, 2012 at 5:56 PM, Menon, Nishanth wrote: >>>>> On Wed, Feb 29, 2012 at 16:32, Alexander Graf wrote: >>>>>> Still need to figure out what exactly is going wrong there. But it's definitely the MLO code that's broken, not the boot rom. >>>>> Wondering why we could'nt move to denx.com u-boot SPL instead of using >>>>> x-loader MLO? >>>> +1. SPL is the right choice today. Nishanth did a great job >>>> maintaining x-loader, but it was always a fork of u-boot and with SPL >>>> we've eliminated that fork. Thanks Nishanth for highlighting this. >>> Yeah, good point. We already use SPL for the Panda, but somehow didn't manage to get the OMAP3 x-loader also based on it. I honestly don't remember why. >> >> Just tried to compile u-boot with SPL and it is 329K which is greater than the 128K limit for beagleboard (OMAP3/DM37x). So we have to use MLO+u-boot. > > I tried building u-boot and SPL for beagle using recent mainline code. > Here are the results: > > SPL(MLO): 43828 bytes > u-boot.bin: 329992 bytes - this seems to be what you have reported. > > If I add my Thumb patches and enable Thumb for Beagle: > SPL: 32420 bytes > u-boot.bin: 248168 bytes > > AFAIK, standard u-boot had never been less than 128 KB in the recent > past. SPL will never be as big as 128K. Is there a confusion here? And > what is the 128K limitation based on?

Oups, did only watch on u-boot.bin, not u-boot-spl.bin sorry. I thought we get only one file and save 1 stage but it does not. 128K limitation is due to ROM boot loader of OMAP3/DM37x SoC.

What is the difference between SPL and MLO? Is it just an include of x-loader/MLO in u-boot? Maybe some improvments?

SPL is almost same as x-loader, just that it is built out of mainline u-boot sources. So, you can pick and choose anything available in u-boot to create a tiny first stage bootloader which is called SPL.

Aneesh, I have a very strange effect now. If I take our MLO binary and dd it onto the disk at offset 128kb, the bootrom doesn't find anything. Putting it on sector 0 works. With the exact same binary.

Could you please verify if you can see similar effects on OMAP3? Is raw boot supposed to work there?

I don't have easy access to OMAP3 boards anymore. But did you try erasing the flash at offset 0.

Well - sector 0 contains the MBR, which usually doesn't look like a CH ;).

...

Maybe, there is a valid header there for some reason? RAW mode should be supported for both NAND and MMC/SD.

Yeah, and raw mode works for me on sector 0, but not on sector 256, which the spec also mentions as valid.

Do you know anyone who could try and debug to run SPL on offset 256 in raw mode?

Ouch.

After a further bit of debugging, I managed to narrow it down:

$ dd if=/dev/urandom of=/dev/sdc bs=1 count=4

That breaks the raw boot. If instead, there are zeros, it works. Now 2 questions arise from this:

1) Why do we have anything in the executable area of the MBR on ARM? What is this code?

Yikes. This is done by parted :(. Great... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 03.03.2012, at 18:27, Marcus Schäfer wrote:

Hi,

...

...

That breaks the raw boot. If instead, there are zeros, it works. Now 2 questions arise from this:

1) Why do we have anything in the executable area of the MBR on ARM? What is this code?

Yikes. This is done by parted :(. Great...

Thanks for narrowing this down, Alex I will include the "zero it out" patch tomorrow or Monday latest and submit new kiwi so that the beagle builds will finally work

Awesome! Thank you! Are you also running parted in the initrd? After a reboot I suddenly have the broken boot code in again O_o. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 03.03.2012, at 18:43, Marcus Schäfer wrote:

Hi,

...

...

Thanks for narrowing this down, Alex I will include the "zero it out" patch tomorrow or Monday latest and submit new kiwi so that the beagle builds will finally work

Awesome! Thank you!

Are you also running parted in the initrd? After a reboot I suddenly have the broken boot code in again O_o.

yes the image is an oem which repartitions to the real geometry so parted is used here again. I will add the patch to the boot code as well

Thanks a lot! Alex

Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de -------------------------------------------------------

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 01/03/2012 12:28, Guillaume Gardet a écrit :

Le 01/03/2012 11:17, Alexander Graf a écrit :

...

On 29.02.2012, at 20:26, Guillaume Gardet wrote:

...

Le 27/02/2012 22:01, Alexander Graf a écrit :

...

On 27.02.2012, at 20:05, Guillaume Gardet wrote:

[...]

...

...

No. My previous trick no more works. Well, I tried another thing. I dd if=/dev/zero to erase the first sectors to be sure to have a good card to start and then dd the raw image. Then I tried to boot and get a "60" on the serial port which means no suitable MLO where found where it is ecpected! Hrm - weird. Could you please try to dd if=/dev/zero the first couple MB and then just dd MLO straight into offset 128kb? Try again for offset 0. With openSUSE MLO it boots something (since it does not try UART boot, which print 60) but nothing is printed on screen (crash?). With the openSUSE sources and patches with a code sourcery toolchain, I get a running MLO. So, it should be a problem with the toolchain or some optimisations flag (which are not supported by beagleboard?). Could you please provide the full compilation line to see what flags could lead to problems?

Or maybe did you use the pandaboard MLO instead of the beagle MLO? That could explain why it start to boot but crash. ARGH. MARCUS!

Yes, you're right. Marcus changed the kiwi description to use the panda bootloader :(((. Of course that won't work... Yes, it should be better with a beagle bootloader! ;)

...

Marcus, could you please fix this up so we use x-loader-omap3beagle and u-boot-omap3beagle again for the beagle description? :)

I will try it again once done.

I tried the latest raw image (beagle build 10.3) and it is booting fine. Thanks. I will test it a bit further (audio, video, etc...) when I will have some spare time. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi Le 01/03/2012 12:29, Marcus Schäfer a écrit :

Hi,

...

...

Or maybe did you use the pandaboard MLO instead of the beagle MLO? That could explain why it start to boot but crash. ARGH. MARCUS!

Yes, you're right. Marcus changed the kiwi description to use the panda bootloader :(((. Of course that won't work... Sorry guys all my fault :(

It's fixed now. I changed the description to fit for my panda board but forgot to change it back. Will not happen again

sorry for any inconvenience

Regards, Marcus

If I dd the new raw image to my SD, it does not boot but if I take your new MLO and dd it to my SD, MLO boots but do not find any partition, since my dd overwrited the partition table (or something like that since openSUSE do not report any partition anymore after my dd). How do you create the raw image? I mean where do you dd the MLO? I think obs/kiwi is doing it automatically but there should be a config file somewhere. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi,

Aligning to 8 sectors is not going to help at all, that is much smaller than the normal erase block size (4MB) and also smaller than typical page sizes (8kb or 16kb). If you want good performance, you should always align to 4MB or more. Using the regular geometry (255/63/1024), that will never be cylinder aligned, which is ok. Don't try to do cylinder alignment.

Ok makes sense, I'm going to change that in kiwi. Thanks much But I guess this is not related to the initial boot problem Thanks Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer HRB: 21284 (AG Nürnberg) Germany http://www.suse.de ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org