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

[Simon Goldschmidt]

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

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?

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?

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