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

[Marek Vasut]

On 08/12/2018 10:04 PM, Simon Goldschmidt wrote:
> On Sun, Aug 12, 2018 at 12:05 AM Marek Vasut <marex at denx.de> wrote:
>>
>> On 08/11/2018 09:26 PM, Simon Goldschmidt wrote:
>>> On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut <marex at 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 ?
> 
> No, that's basically what I meant. It is done in SPL *and* U-Boot,
> that sounds a bit strange, but it's OK to leave it like that.
> I only would change SPL to call the same code in misc_gen5.c as U-Boot
> does to deduplicate the C code.

OK. Please double-check that the first 1 MiB of RAM is behaving
correctly in U-Boot if you fiddle with that code.

> Another thing that I don't get is: why are the FPGA bridges reset
> again at the end of SPL board_init_f()? Introduced by you with this
> commit:
> https://github.com/u-boot/u-boot/commit/bd65fe35fffd9a9e8c8abe5321a51a8c43eda97d
> 
> Can we remove this 2nd reset?

AFAIR to keep as much stuff in reset as possible when handing over to
U-Boot.

>>>>> 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.
> 
> CONFIG_SYS_EXTRA_ENV_RELOC does the trick in U-Boot.
> 
>>
>> --
>> Best regards,
>> Marek Vasut


-- 
Best regards,
Marek Vasut