[U-Boot] DE10 Nano U-Boot v2019.04 Issues
Hello, I've attempted to build u-boot v2019.04 for the DE10 Nano board using the following commands: make ARCH=arm CROSS_COMPILE=${CC} distclean make ARCH=arm CROSS_COMPILE=${CC} socfpga_de10_nano_defconfig make ARCH=arm CROSS_COMPILE=${CC} u-boot-with-spl.sfp
It builds just fine but I'm not able to make the board load U-Boot correctly. If I run the same commands using v2018.05 it builds and I'm able to boot the board.
After some attempts to find the issue, I was able to compile and boot the v2019.04 by changing the CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de10_nano” to CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de0_nano_soc” in the socfpga_de10_nano_defconfig file. That lead me to belive that there was an issue with the socfpga_cyclone5_de10_nano.dts file. After changing the socfpga_cyclone5_de10_nano.dts to be identical to the socfpga_cyclone5_de0_nano_soc.dts I wasn't able to boot the board, making me think that the issue is somewere else, since I'm also able to compile and boot the board if I rename the socfpga_cyclone5_de10_nano.dts to socfpga_cyclone5_de0_nano_soc.dts.
So would like to know if I'm missing a step in the build process or doing something wrong?
Best regards, Rafael Villatore
On 27.04.19 19:59, rafael mello wrote:
Hello, I've attempted to build u-boot v2019.04 for the DE10 Nano board using the following commands: make ARCH=arm CROSS_COMPILE=${CC} distclean
You probably should use mrproper here, not distclean?
make ARCH=arm CROSS_COMPILE=${CC} socfpga_de10_nano_defconfig make ARCH=arm CROSS_COMPILE=${CC} u-boot-with-spl.sfp
So what's $CC set to? I don't think you need ARCH=arm, works without that for me.
It builds just fine but I'm not able to make the board load U-Boot correctly.
So SPL runs fine but it doesn't load U-Boot? Or does it fail running anything? Please send the console output, if any.
If I run the same commands using v2018.05 it builds and I'm able to boot the board.
After some attempts to find the issue, I was able to compile and boot the v2019.04 by changing the CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de10_nano” to CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de0_nano_soc” in the socfpga_de10_nano_defconfig file. That lead me to belive that there was an issue with the socfpga_cyclone5_de10_nano.dts file. After changing the socfpga_cyclone5_de10_nano.dts to be identical to the socfpga_cyclone5_de0_nano_soc.dts I wasn't able to boot the board, making me think that the issue is somewere else, since I'm also able to compile and boot the board if I rename the socfpga_cyclone5_de10_nano.dts to socfpga_cyclone5_de0_nano_soc.dts.
I don't see the file socfpga_cyclone5_de0_nano_soc.dts, where does it come from?
Unfortunately, I don't have that board, so I cannot test it myself.
Regards, Simon
Hello Simon, Thank you for the repply.
You probably should use mrproper here, not distclean?
I do agree, mrproper should be used.
So what's $CC set to? I don't think you need ARCH=arm, works without that for me.
Sorry, I forgot to say that ${CC} is pointig to Linaro gcc folder.
So SPL runs fine but it doesn't load U-Boot? Or does it fail running anything? Please send the console output, if any.
Reggarding the console output, there is none when I set CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de10_nano”.
I don't see the file socfpga_cyclone5_de0_nano_soc.dts, where does it come from?
I'm relating to the original files from the U-Boot source, the path is arch/arm/dts/<filename>, but I can attach the files if it's needded.
Is there any other info that would help?
Best regards, Rafael Villatore
________________________________ De: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Enviado: domingo, 28 de abril de 2019 05:13 Para: rafael mello Cc: u-boot@lists.denx.de Assunto: Re: [U-Boot] DE10 Nano U-Boot v2019.04 Issues
On 27.04.19 19:59, rafael mello wrote:
Hello, I've attempted to build u-boot v2019.04 for the DE10 Nano board using the following commands: make ARCH=arm CROSS_COMPILE=${CC} distclean
You probably should use mrproper here, not distclean?
make ARCH=arm CROSS_COMPILE=${CC} socfpga_de10_nano_defconfig make ARCH=arm CROSS_COMPILE=${CC} u-boot-with-spl.sfp
So what's $CC set to? I don't think you need ARCH=arm, works without that for me.
It builds just fine but I'm not able to make the board load U-Boot correctly.
So SPL runs fine but it doesn't load U-Boot? Or does it fail running anything? Please send the console output, if any.
If I run the same commands using v2018.05 it builds and I'm able to boot the board.
After some attempts to find the issue, I was able to compile and boot the v2019.04 by changing the CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de10_nano” to CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de0_nano_soc” in the socfpga_de10_nano_defconfig file. That lead me to belive that there was an issue with the socfpga_cyclone5_de10_nano.dts file. After changing the socfpga_cyclone5_de10_nano.dts to be identical to the socfpga_cyclone5_de0_nano_soc.dts I wasn't able to boot the board, making me think that the issue is somewere else, since I'm also able to compile and boot the board if I rename the socfpga_cyclone5_de10_nano.dts to socfpga_cyclone5_de0_nano_soc.dts.
I don't see the file socfpga_cyclone5_de0_nano_soc.dts, where does it come from?
Unfortunately, I don't have that board, so I cannot test it myself.
Regards, Simon
On Mon, Apr 29, 2019 at 1:16 AM rafael mello rafaelmello_3@hotmail.com wrote:
Hello Simon, Thank you for the repply.
You probably should use mrproper here, not distclean?
I do agree, mrproper should be used.
So what's $CC set to? I don't think you need ARCH=arm, works without that for me.
Sorry, I forgot to say that ${CC} is pointig to Linaro gcc folder.
So SPL runs fine but it doesn't load U-Boot? Or does it fail running anything? Please send the console output, if any.
Reggarding the console output, there is none when I set CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de10_nano”.
OK, so there's probably something wrong with getting the console. After checking that dts, could you add the following line to the &uart{} node in the de10 dts:
clock-frequency = <100000000>;
If that still doesn't work, try to enable debug uart to see any output.
I don't see the file socfpga_cyclone5_de0_nano_soc.dts, where does it come from?
I'm relating to the original files from the U-Boot source, the path is arch/arm/dts/<filename>, but I can attach the files if it's needded.
Ah, no, I failed to see the "de10" vs. "de0". However,
Regards, Simon
Hello Simon,
Adding the "clock-frequency = <100000000>;" line to the dts file solved the issue, But I had found another solution before reading your repply. There is one dtsi file missing for the de10 nano board, the file should be named "socfpga_cyclone5_de10_nano-u-boot.dtsi" and it's content should be the same as the "socfpga_cyclone5_de0_nano_soc-u-boot.dtsi". For some reason the "*-u-boot.dtsi" files are loaded even whan not called in the dts file, and the clock-frequency definition was in that file for all the cyclone5 boards, except for the de10 nano. Creating the file made the board follow the current pattern/standard and solved the issue. Maybe a patch is required.
I'm attaching the socfpga_cyclone5_de10_nano-u-boot.dtsi file and the socfpga_cyclone5_de10_nano.dts files
Thank you very much for the help, even with the solution that I found, I failed to see that the clock-frequency was the real issue.
Best regards, Rafael Villatore
________________________________ De: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Enviado: segunda-feira, 29 de abril de 2019 04:23 Para: rafael mello Cc: u-boot@lists.denx.de Assunto: Re: [U-Boot] DE10 Nano U-Boot v2019.04 Issues
On Mon, Apr 29, 2019 at 1:16 AM rafael mello rafaelmello_3@hotmail.com wrote:
Hello Simon, Thank you for the repply.
You probably should use mrproper here, not distclean?
I do agree, mrproper should be used.
So what's $CC set to? I don't think you need ARCH=arm, works without that for me.
Sorry, I forgot to say that ${CC} is pointig to Linaro gcc folder.
So SPL runs fine but it doesn't load U-Boot? Or does it fail running anything? Please send the console output, if any.
Reggarding the console output, there is none when I set CONFIG_DEFAULT_DEVICE_TREE=“socfpga_cyclone5_de10_nano”.
OK, so there's probably something wrong with getting the console. After checking that dts, could you add the following line to the &uart{} node in the de10 dts:
clock-frequency = <100000000>;
If that still doesn't work, try to enable debug uart to see any output.
I don't see the file socfpga_cyclone5_de0_nano_soc.dts, where does it come from?
I'm relating to the original files from the U-Boot source, the path is arch/arm/dts/<filename>, but I can attach the files if it's needded.
Ah, no, I failed to see the "de10" vs. "de0". However,
Regards, Simon
On Mon, Apr 29, 2019 at 4:36 PM rafael mello rafaelmello_3@hotmail.com wrote:
Hello Simon,
Adding the "clock-frequency = <100000000>;" line to the dts file solved the issue,
Great to hear that. I'll post a patch to fix that.
But I had found another solution before reading your repply. There is one dtsi file missing for the de10 nano board, the file should be named "socfpga_cyclone5_de10_nano-u-boot.dtsi" and it's content should be the same as the "socfpga_cyclone5_de0_nano_soc-u-boot.dtsi".
Not exactly. There are "u-boot.dtsi" files for devicetrees copied by Linux. It's a make automatism to ensure we can use unmodified Linux devicetress and add U-Boot specific changes in different files.
However, the de10 board does not exist in Linux, so there's no point in splitting U-Boot specific code to a "u-boot.dtsi" file since the whole devicetree is U-Boot specific.
Regards, Simon
For some reason the "*-u-boot.dtsi" files are loaded even whan not called in the dts file, and the clock-frequency definition was in that file for all the cyclone5 boards, except for the de10 nano. Creating the file made the board follow the current pattern/standard and solved the issue. Maybe a patch is required.
I'm attaching the socfpga_cyclone5_de10_nano-u-boot.dtsi file and the socfpga_cyclone5_de10_nano.dts files
Thank you very much for the help, even with the solution that I found, I failed to see that the clock-frequency was the real issue.
Best regards, Rafael Villatore
participants (2)
-
rafael mello -
Simon Goldschmidt