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

[Simon Goldschmidt]

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.

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

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


Simon