[U-Boot] [PATCH] arm: socfpga: make socfpga_socrates_defconfig boot from QSPI
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
---
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay"; + u-boot,dm-pre-reloc;
flash0: n25q00@0 { #address-cells = <1>; @@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>; + u-boot,dm-pre-reloc; }; };
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay";
u-boot,dm-pre-reloc;
flash0: n25q00@0 { #address-cells = <1>;
@@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>;
u-boot,dm-pre-reloc;};
But the SoCrates boots from SDMMC :-)
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts
b/arch/arm/dts/socfpga_cyclone5_socrates.dts
index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay";
u-boot,dm-pre-reloc; flash0: n25q00@0 { #address-cells = <1>;@@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>;
u-boot,dm-pre-reloc; };};
But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
Simon Goldschmidt
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay";
u-boot,dm-pre-reloc; flash0: n25q00@0 { #address-cells = <1>;@@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>;
u-boot,dm-pre-reloc; };};
But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
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.
Simon Goldschmidt
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay";
u-boot,dm-pre-reloc; flash0: n25q00@0 { #address-cells = <1>;@@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>;
u-boot,dm-pre-reloc; };};
But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
If it works with both out of the box, then that's fine.
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 ?
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?
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...
Simon
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.
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.
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
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
On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut marex@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
On 08/11/2018 09:26 PM, Simon Goldschmidt wrote:
On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut marex@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.
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 ?
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.
On Sun, Aug 12, 2018 at 12:05 AM Marek Vasut marex@denx.de wrote:
On 08/11/2018 09:26 PM, Simon Goldschmidt wrote:
On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut marex@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.
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/bd65fe35fffd9a9e8c8abe5321a51a8c43ed...
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
On 08/12/2018 10:04 PM, Simon Goldschmidt wrote:
On Sun, Aug 12, 2018 at 12:05 AM Marek Vasut marex@denx.de wrote:
On 08/11/2018 09:26 PM, Simon Goldschmidt wrote:
On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut marex@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.
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.
OK. Please double-check that the first 1 MiB of RAM is behaving correctly in U-Boot if you fiddle with that 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/bd65fe35fffd9a9e8c8abe5321a51a8c43ed...
Can we remove this 2nd reset?
AFAIR to keep as much stuff in reset as possible when handing over to U-Boot.
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
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay";
u-boot,dm-pre-reloc; flash0: n25q00@0 { #address-cells = <1>;@@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>;
u-boot,dm-pre-reloc; };But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
If it works with both out of the box, then that's fine.
Gentle ping?
Is there anything missing for this to be merged? Or should we rather merge all current socfpga device trees from linux now that this has missed 2018.09?
Simon
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 ?
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay";
u-boot,dm-pre-reloc; flash0: n25q00@0 { #address-cells = <1>;@@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>;
u-boot,dm-pre-reloc; };But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
If it works with both out of the box, then that's fine.
So can this be merged? I need different config settings than the defconfig by now to get qspi running, but the device tree works without changes with this added and I can boot the socrates from all its 3 sources available from the DIP switches (MMC, QSPI, FPGA).
Simon
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 ?
On 10/07/2018 08:43 AM, Simon Goldschmidt wrote:
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
This fixes the board's dts to supply SPL with QSPI info.
The EBV Socrates board has DIP switches to boot from SD card or QSPI, so let's fix its defconfig to work for both cases.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts b/arch/arm/dts/socfpga_cyclone5_socrates.dts index 0d452ae300..46d7eabdc8 100644 --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts @@ -63,6 +63,7 @@
&qspi { status = "okay"; + u-boot,dm-pre-reloc;
flash0: n25q00@0 { #address-cells = <1>; @@ -77,6 +78,7 @@ cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>; + u-boot,dm-pre-reloc; }; };
But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
If it works with both out of the box, then that's fine.
So can this be merged? I need different config settings than the defconfig by now to get qspi running, but the device tree works without changes with this added and I can boot the socrates from all its 3 sources available from the DIP switches (MMC, QSPI, FPGA).
Yes, applied
On Mon, Oct 8, 2018 at 2:20 AM Marek Vasut marex@denx.de wrote:
On 10/07/2018 08:43 AM, Simon Goldschmidt wrote:
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19:
On 08/06/2018 03:05 PM, Simon Goldschmidt wrote: > This fixes the board's dts to supply SPL with QSPI info. > > The EBV Socrates board has DIP switches to boot from SD card or > QSPI, so let's fix its defconfig to work for both cases. > > Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com > > --- > > arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts > b/arch/arm/dts/socfpga_cyclone5_socrates.dts > index 0d452ae300..46d7eabdc8 100644 > --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts > +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts > @@ -63,6 +63,7 @@ > > &qspi { > status = "okay"; > + u-boot,dm-pre-reloc; > > flash0: n25q00@0 { > #address-cells = <1>; > @@ -77,6 +78,7 @@ > cdns,tsd2d-ns = <50>; > cdns,tchsh-ns = <4>; > cdns,tslch-ns = <4>; > + u-boot,dm-pre-reloc; > }; > }; > > But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
If it works with both out of the box, then that's fine.
So can this be merged? I need different config settings than the defconfig by now to get qspi running, but the device tree works without changes with this added and I can boot the socrates from all its 3 sources available from the DIP switches (MMC, QSPI, FPGA).
Yes, applied
To which tree? I can't find it on http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=summary
Is there any delay involved in syncing that?
Simon
On 10/08/2018 08:45 PM, Simon Goldschmidt wrote:
On Mon, Oct 8, 2018 at 2:20 AM Marek Vasut marex@denx.de wrote:
On 10/07/2018 08:43 AM, Simon Goldschmidt wrote:
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Marek Vasut marex@denx.de schrieb am Mo., 6. Aug. 2018, 15:19: > On 08/06/2018 03:05 PM, Simon Goldschmidt wrote: >> This fixes the board's dts to supply SPL with QSPI info. >> >> The EBV Socrates board has DIP switches to boot from SD card or >> QSPI, so let's fix its defconfig to work for both cases. >> >> Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com >> >> --- >> >> arch/arm/dts/socfpga_cyclone5_socrates.dts | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/dts/socfpga_cyclone5_socrates.dts >> b/arch/arm/dts/socfpga_cyclone5_socrates.dts >> index 0d452ae300..46d7eabdc8 100644 >> --- a/arch/arm/dts/socfpga_cyclone5_socrates.dts >> +++ b/arch/arm/dts/socfpga_cyclone5_socrates.dts >> @@ -63,6 +63,7 @@ >> >> &qspi { >> status = "okay"; >> + u-boot,dm-pre-reloc; >> >> flash0: n25q00@0 { >> #address-cells = <1>; >> @@ -77,6 +78,7 @@ >> cdns,tsd2d-ns = <50>; >> cdns,tchsh-ns = <4>; >> cdns,tslch-ns = <4>; >> + u-boot,dm-pre-reloc; >> }; >> }; >> >> > But the SoCrates boots from SDMMC :-)
Yours might :-)
As written above, the board has an 8 digit dip switch to control both hps and fpga boot sources. And I use this board to verify that mainline U-Boot (without our private board configs, which boot from qspi) works on the architecture.
So, will it be ok to merge this patch or do we need a separate dts for running from qspi (much like you did recently for the gen10 clk items)? That might be a bad choice though, as my configuration currently runs for both boot types (when enabling both environment drivers).
If it works with both out of the box, then that's fine.
So can this be merged? I need different config settings than the defconfig by now to get qspi running, but the device tree works without changes with this added and I can boot the socrates from all its 3 sources available from the DIP switches (MMC, QSPI, FPGA).
Yes, applied
To which tree? I can't find it on http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=summary
Is there any delay involved in syncing that?
Locally, yes, I didn't push it yet. I'm a bit busy, sorry.
participants (3)
-
Marek Vasut -
Marek Vasut -
Simon Goldschmidt