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

[Marek Vasut <marex@denx.de>]

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.

> 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.

> 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 .

>>> Additionally, to add the binary into an fpga, we need a hex file, maybe
>>> these can be automatically generated by mach-socfpga's Makefile when
>>> creating the SPL...
>> Don't we have a hex file target already ? Maybe you do want some
>> socrates_fpga custom defconfig for this setup.
> 
> Never stumbled accross that one, yet. Let me check.
> 
> 
> Simon
> 


-- 
Best regards,
Marek Vasut