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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
