[U-Boot] [PATCH] arm: socfpga: make socfpga_socrates_defconfig boot from QSPI

[Marek Vasut <marex@denx.de>]

On 08/11/2018 09:26 PM, Simon Goldschmidt wrote:
> On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 08/10/2018 10:11 PM, Simon Goldschmidt wrote:
>>> On 10.08.2018 15:15, Marek Vasut wrote:
>>>> On 08/10/2018 02:56 PM, Simon Goldschmidt wrote:
>>>>> On 09.08.2018 23:57, Marek Vasut wrote:
>>>>>> On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
>>>>>>> [..]
>>>>>>> BTW, the DIP switches even allow the SoCrates to boot from fpga, which
>>>>>>> is what I'm currently working on. In this case, it seems like we need
>>>>>>> a separate config at least, but the dts can still be the same.
>>>>>> Presumably because the SPL needs different link address ?
>>>>> The linker address of course needs to be changed. Preventing the cpu
>>>>> accessing the FPGA OnChip RAM was a bit more tricky to debug, but it
>>>>> seems I have it working now.
>>>>>
>>>>> I guess we need a Kconfig option to enable the bridge reset changes and
>>>>> select the correct link address. I'll prepare a patch for that. Should I
>>>>> base it on top of my gen5 fixes series?
>>>> Arent you gonna repost that series anyway ? Just wrap it in I think.
>>>
>>> OK then.
>>>
>>> After getting SPL to run from FPGA, I then had problems with running
>>> U-Boot from FPGA. I do that because U-Boot allows us to boot empty
>>> boards via network by only downloading an FPGA image (in combination
>>> with fallback boot from FPGA).
>>
>> You can boot from network in SPL too.
> 
> That might be an interesting idea. Currently we might have use for the
> U-Boot console in this image, so if it works with U-Boot, the
> additional subsecond delay to boot it would be worth it.

OK

>>> Turns out the problem is the same: bridges into FPGA get disabled. Now I
>>> can deduplicate the code, but is this the right thing to do at all?
>>> Can't we expect for the SPL to have run an correctly initialize the low
>>> level hardware?
>>
>> Deduplication is always good. I don't quite understand this question though.
> 
> Sorry for being unclear. What I meant was that arch_early_init_r() in
> misc_gen5.c (called from U-Boot) does similar things that SPL has
> already done in board_init_f(). Is that expected or should U-Boot rely
> on SPL having initialized the hardware properly?

Oh, the sacr/remap/scu settings ? There is some obscure behavior of the
chip which requires things to be done in that order and early on,
otherwise the first 0x100000 of RAM misbehave.

If you manage to deduplicate the code, excellent, just be careful with
this beginning of RAM thing, it's quite nasty.

Or do you mean some other init ?

>>> On the other hand, it's a bit strange that after relocation, U-Boot
>>> tries to access pre-relocation memory anyway (gd->env_addr points to the
>>> fpga bridge). Maybe a better fix would be to relocate that pointer? In
>>> its original port, Altera has put all data into SRAM instead of fpga's
>>> OCRAM, so while code wouldn't work, data access to pre-relocation
>>> pointers would still work after the bridges got disabled...
>>>
>>> Which option would you prefer?
>>
>> I wonder why the in-ram env isn't relocated. But do you really need any
>> of that ? See above about using TFTP in SPL .
> 
> As I don't know if TFTP in SPL is an option for us, I'll check if I
> can relocate env_addr in gd.

Sounds good, thanks.

-- 
Best regards,
Marek Vasut