From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Sun, 12 Aug 2018 22:04:14 +0200 Subject: [U-Boot] [PATCH] arm: socfpga: make socfpga_socrates_defconfig boot from QSPI In-Reply-To: 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 Sun, Aug 12, 2018 at 12:05 AM Marek Vasut wrote: > > On 08/11/2018 09:26 PM, Simon Goldschmidt wrote: > > On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut 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. > > OK > > >>> 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? > > Oh, the sacr/remap/scu settings ? There is some obscure behavior of the > chip which requires things to be done in that order and early on, > otherwise the first 0x100000 of RAM misbehave. > > If you manage to deduplicate the code, excellent, just be careful with > this beginning of RAM thing, it's quite nasty. > > Or do you mean some other init ? No, that's basically what I meant. It is done in SPL *and* U-Boot, that sounds a bit strange, but it's OK to leave it like that. I only would change SPL to call the same code in misc_gen5.c as U-Boot does to deduplicate the C code. Another thing that I don't get is: why are the FPGA bridges reset again at the end of SPL board_init_f()? Introduced by you with this commit: https://github.com/u-boot/u-boot/commit/bd65fe35fffd9a9e8c8abe5321a51a8c43eda97d Can we remove this 2nd reset? > > >>> 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. > > Sounds good, thanks. CONFIG_SYS_EXTRA_ENV_RELOC does the trick in U-Boot. > > -- > Best regards, > Marek Vasut