Mailinglist Archive: opensuse-arm (97 mails)
|< Previous||Next >|
Re: [opensuse-arm] openSUSE on Beagleboard xM
- From: Alexander Graf <agraf@xxxxxxx>
- Date: Fri, 2 Mar 2012 17:09:56 +0100
- Message-id: <3EF0888B-B130-4641-A69F-E0612766831D@suse.de>
On 02.03.2012, at 11:06, Alexander Graf wrote:
On 02.03.2012, at 09:15, Aneesh V <aneesh@xxxxxx> 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<nm@xxxxxx> wrote:Yeah, good point. We already use SPL for the Panda, but somehow didn't
On Wed, Feb 29, 2012 at 16:32, Alexander Graf<agraf@xxxxxxx>+1. SPL is the right choice today. Nishanth did a great job
Still need to figure out what exactly is going wrong there. ButWondering why we could'nt move to denx.com u-boot SPL instead of
it's definitely the MLO code that's broken, not the boot rom.
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.
manage to get the OMAP3 x-loader also based on it. I honestly don't
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
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
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
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?
To unsubscribe, e-mail: opensuse-arm+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-arm+owner@xxxxxxxxxxxx
|< Previous||Next >|