From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Fri, 10 Aug 2018 22:11:41 +0200 Subject: [U-Boot] [PATCH] arm: socfpga: make socfpga_socrates_defconfig boot from QSPI In-Reply-To: <6b15b531-a7d3-a90f-257c-ecfb2aafad81@denx.de> References: <20180806130509.21967-1-simon.k.r.goldschmidt@gmail.com> <1f5e8a25-55c6-ada0-9c01-d42a94980ba8@denx.de> <8c12ed86-8156-f730-4491-e164c9632ebc@gmail.com> <7b1e9dac-62e5-5223-e578-90b3ba5140bd@gmail.com> <6b15b531-a7d3-a90f-257c-ecfb2aafad81@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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