Am 08.05.19 um 13:34 schrieb Wolfgang Grandegger: > > > Am 08.05.19 um 13:07 schrieb Simon Goldschmidt: >> >> >> Wolfgang Grandegger <w...@aries-embedded.de <mailto:w...@aries-embedded.de>> >> schrieb am Mi., 8. Mai 2019, 12:23: >> >> Hello, >> >> Am 07.05.19 um 21:25 schrieb Simon Goldschmidt: >> > >> > >> > On 07.05.19 21:14, Wolfgang Grandegger wrote: >> >> >> >> Am 07.05.19 um 13:37 schrieb Simon Goldschmidt: >> >>> On Tue, May 7, 2019 at 9:41 AM Wolfgang Grandegger >> >>> <w...@aries-embedded.de <mailto:w...@aries-embedded.de>> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Am 06.05.19 um 22:16 schrieb Simon Goldschmidt: >> >>>>> Am 06.05.2019 um 17:45 schrieb Wolfgang Grandegger: >> >>>>>> Re-add support for Aries Embedded MCV SoM, which is CycloneV >> based >> >>>>>> and the associated MCVEVK baseboard. The board can boot from >> eMMC. >> >>>>>> Ethernet and USB is supported. >> >>>>>> >> >>>>>> The Aries Embedded boards have been removed with commit >> 03b54997d568 >> >>>>>> ("board/aries: Remove"). I will now take care of them. >> >>>>>> >> >>>>>> Signed-off-by: Wolfgang Grandegger <w...@aries-embedded.de >> <mailto:w...@aries-embedded.de>> >> >>>>>> CC: Marek Vasut <ma...@denx.de <mailto:ma...@denx.de>> >> >>>>>> CC: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com >> <mailto:simon.k.r.goldschm...@gmail.com>> >> >>>>>> --- >> >>>>>> .travis.yml | 2 +- >> >>>>>> arch/arm/dts/Makefile | 1 + >> >>>>>> arch/arm/dts/socfpga_cyclone5_mcv.dtsi | 22 + >> >>>>>> arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi | 38 ++ >> >>>>>> arch/arm/dts/socfpga_cyclone5_mcvevk.dts | 81 +++ >> >>>>>> arch/arm/mach-socfpga/Kconfig | 7 + >> >>>>>> board/aries/mcvevk/MAINTAINERS | 6 + >> >>>>>> board/aries/mcvevk/Makefile | 7 + >> >>>>>> board/aries/mcvevk/qts/iocsr_config.h | 659 >> >>>>>> +++++++++++++++++++++++ >> >>>>>> board/aries/mcvevk/qts/pinmux_config.h | 218 >> ++++++++ >> >>>>>> board/aries/mcvevk/qts/pll_config.h | 84 +++ >> >>>>>> board/aries/mcvevk/qts/sdram_config.h | 343 >> >>>>>> ++++++++++++ >> >>>>> >> >>>>> These files are always a mystery. Would you be able to provide >> >>>>> (long-lived) link to a simplistic quartus project so that >> everyone can >> >>>>> regenerate these? >> >>>>> >> >>>>> I'll try to provide such a quartus project for the socrates >> board, and >> >>>>> I'd be very happy if the original Intel dev boards could do so as >> >>>>> well! >> >>>> >> >>>> There is a Quartus example project for that module/board here: >> >>>> >> >>>> https://github.com/ARIES-Embedded/mcv >> >>> >> >>> Cool. And is this a permanent link that we could add to some kind >> >>> of documentation for this board in the U-Boot sources? That would >> >>> ensure U-Boot maintainers can find it in the future... >> >> >> >> I will check with the author! >> >> >> >> BTW: My patch works fine on top of v2019.04 but the boot hangs >> without >> >> console output with the latest HEAD. The problems start with commit: >> >> >> >> ede6e7b reset: socfpga: add reset handling for old kernels >> >> >> >> Then I get: >> >> >> >> U-Boot SPL 2019.04-00508-g03b5c7e-dirty (May 07 2019 - >> 21:03:52 +0200) >> >> ### ERROR ### Please RESET the board ### >> >> >> >> Any idea how to fix that? >> > >> > No, sorry, I don't have an idea right now. Are you sure you're not >> > missing any of the "u-boot,dm-pre-reloc" tags? >> > >> > And you're absolutely sure this very commit produces this error? >> >> Well, I somehow fooled myself. Sorry for the noise. The problem was the >> missing "u-boot,dm-pre-reloc" for the "rst" odr "sdr" node and >> "CONFIG_SPL_TEXT_BASE=0xFFFF0000" in the defconfig. Now U-Boot starts >> but the kernel does not... >> >> >> Good to know U-Boot works. What's the output of the kernel? Have you >> added the env variable the above mentioned commit checks? Without it, >> all peripherals are out into reset and have to be re-enabled by Linux >> drivers... > > OK, have set that variable now. > > => boot > 4519072 bytes read in 147 ms (29.3 MiB/s) > 26106 bytes read in 2 ms (12.4 MiB/s) > ## Flattened Device Tree blob at 00f00000 > Booting using the fdt blob at 0xf00000 > Loading Device Tree to 3bf4b000, end 3bf545f9 ... OK > > Starting kernel ... > > Deasserting all peripheral resets > > ... nothing ... > >> But this variable should be added by socfpga_common.h > > But only if "CONFIG_EXTRA_ENV_SETTINGS" is used from that file, which is > not the case for a few boards.
Linux now boots with "setenv bootm_size 0xa000000" ! That's obviously missing in my env seetup as well. Wolfgang _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot