Mailinglist Archive: opensuse-arm (74 mails)

< Previous Next >
Re: [opensuse-arm] openSUSE on Beagleboard xM

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

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:

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? :)
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!

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.

According to the spec (, page 3475) offsets
0 and 128kb should work and be checked before the MBR or file system headers
get analyzed.


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?

Sure - all of openSUSE is public:

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+):

Yeah, that's in line with the document I was reading :)

• Raw mode:

In raw mode, an image can be at offset 0 or 128KB and must not be bigger than
128KB. Raw mode is detected by reading sector 0 and sector 256. The content of
these sectors is verified for the presence of a TOC structure. In the case of a
GP device, a configuration header (CH) must be in the first sector followed by
a GP header. The CH can be void (contains only a CHSETTINGS item for which the
valid field is 0), as described in Section, Configuration Header.
Image data is read directly from continuous sectors of a card. If raw mode is
not detected, file system mode is checked.

I think, there is a problem on the MLO file itself and maybe also on the MLO
location for the raw mode.

Maybe we just need a different MLO for the xM beagleboard?


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

< Previous Next >
List Navigation
Follow Ups