[U-Boot] [PATCH v2 3/4] ARM: atmel: at91sam9x5ek: enable spl support

[Stefan Roese]

Hi Eugene,

On 22.02.19 16:57, Eugen.Hristev at microchip.com wrote:
> 
> 
> On 21.02.2019 19:00, Stefan Roese wrote:
>> Hi Eugene,
>>
>> On 19.02.19 15:56, Stefan Roese wrote:
>>
>> <snip>
>>
>>>> I did not test myself the SPL for any 9x5 board. The DDR2 init code
>>>> should be executed inside the SPL. Once you build your board with a
>>>> CONFIG_SPL enabled, you should get the spl binary built, then you can
>>>> add both SPL + U-boot proper on the boot media and have SPL boot
>>>> (execute DDR init code and load U-boot proper). I would suggest to try
>>>> on Sd-card first because it's easier (filesystem), but the commit says
>>>> only SPI and NAND tested.
>>>
>>> On this board I only have NAND, so there is no option to first test
>>> some other boot device unfortunately.
>>>
>>>> You can also look at the U-boot version which first included this patch,
>>>> some things may have changed since...
>>>
>>> Sure, I can and will check this. But I first wanted to check with
>>> you guys about the status, since you implemented and most likely
>>> also tested this stuff.
>>>> Let me know of your findings. I will let you know if I have the chance
>>>> to test this myself.
>>>
>>> Okay. I'll try to test this stuff (even though I don't have JTAG on
>>> this board) and will get back to you with findings and most likely
>>> also some further questions.
>>
>> So I did make some progress here but building and testing the SPL
>> version by loading it to 0x30.0000 and starting it there via the
>> "go" command. I'm not brave enough to flash it right now, since
>> de-bricking might be tricky here, as I don't have JTAG. With the
>> loaded version I'm able to fully load the main U-Boot image from
>> NAND and run it from there to the prompt.
> 
> Hi Stefan,
> 
> Send me a patch and I can apply and test, but I cannot promise to have
> it very fast :) (or your git tree from where I can pull...)
> Have to make it for 9x5-ek board, as I do not have anything else at my
> disposal

I might come back to your offer, thanks!
  
> 
>>
>> But then I looked at the latest AT91Bootstrap code and noticed the
>> many changes in the lowlevel boot code (clocking, DDR2, etc). I'm
>> a bit hesitant to port all this code to mainline U-Boot SPL here.
>> One reason being that you at Microchip / Atmel will most likely
>> continue to work on the AT91Bootstrap code and not on the
>> potentially ported SPL code version. So what's you opinion here on
>> this? Why do you not integrate all this code into U-Boot SPL and
>> drop this bootstrap version completely? What is your suggestion for
>> me on how to handle this? Stay with AT91Bootstrap or move to SPL?
> 
> At91boostrap is always recommended as we have the latest implementation
> and it's used by most of the people using at91 boards and more tested.

I see. The decision to completely move to SPL should have probably been
made some years ago then (as other SoC vendors have done). Nothing to be
done about this now.

Still, what I really like in this SPL approach vs the vendor pre U-Boot
loader is, that all is encapsulated in one source code repository and
one image usually is generated, simplifying the bootloader building
and programming quite a bit.

> We always try to keep SPL in sync , but it's only on best-effort at this
> moment
> I will review/take patches for SPL of course. There are people who use
> it so we try to have it working at all times.

Okay, good to know.

Thanks,
Stefan