On 02.03.2012, at 20:19, Menon, Nishanth wrote:
2012/3/2 Alexander Graf <agraf@suse.de>
On 02.03.2012, at 11:06, Alexander Graf wrote:
On 02.03.2012, at 09:15, Aneesh V <aneesh@ti.com> 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@ti.com> >>>>> wrote: >>>>>> On Wed, Feb 29, 2012 at 16:32, Alexander Graf<agraf@suse.de> >>>>>> 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..
Yeah, maybe the bootrom code doesn't check for the magic properly :). The same thing works just fine on OMAP4, so it's got to be something fishy in the old SoCs. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org