Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
On Mon, 2020-03-16 at 20:06 +0100, Marek Vasut wrote: > On 3/16/20 8:04 PM, Simon Goldschmidt wrote: > > Am 16.03.2020 um 19:04 schrieb Dalon L Westergreen: > > > > > > On Thu, 2020-03-12 at 16:57 +0100, Marek Vasut wrote: > > > > On 3/12/20 4:54 PM, Dalon L Westergreen wrote: > > > > [...] > > > > > > > > (thanks for fixing your mailer :)) > > > > > > > > > > > > > > The problem was that this was causing weird sporadic hangs > > > > > > > > > > on > > > > > > > > > > Gen5, > > > > > > > > > > which is why it was removed. So until there is an > > > > > > > > > > explanation for > > > > > > > > > > those > > > > > > > > > > hangs, I'm not really OK with this. > > > > > > > > > > > > > > > > > > These sporadic hangs you saw were on devices without an FPGA > > > > > > > > > image > > > > > > > > > directly > > > > > > > > > accessing the SDRAM ports, right? > > > > > > > > > > > > > > > > Yes > > > > > > > > > > > > > > > > > > Maybe the application of static config should happen in SPL, > > > > > > > > > > before > > > > > > > > > > the > > > > > > > > > > DRAM is running, or something like that ? > > > > > > > > > > > > > > > > > > Thinking this further, limiting it to applying in SPL is not a > > > > > > > > > good > > > > > > > > > idea > > > > > > > > > since > > > > > > > > > that prevents us from implementing different FPGA > > > > > > > > > images/configs by > > > > > > > > > loading a > > > > > > > > > config later in the boot (i.e. in U-Boot from a FIT-image). > > > > > > > > > > > > > > > > Well, but later we have SDRAM running and we cannot make it go > > > > > > > > idle, > > > > > > > > can > > > > > > > > we? > > > > > > > > > > > > > > > > > > Unfortunately the sdram cfg apply must occur AFTER the fpga is > > > > > configured. This > > > > > is because the FPGA drives configuration bits, around the interfaces > > > > > datawidth > > > > > for example, that are used in setting up the dram interface. I > > > > > believe the > > > > > intent is for the command to only run when the ridge enable function > > > > > is > > > > > called. > > > > > > > > So that's one part of the fix -- only run this apply_static_cfg if the > > > > bitstream uses the F2S bridge. > > > > > > actually, the restriction is to apply this only if the FPGA is configured, > > > whether the bridge is used is irrelevant. you can further restrict this > > > to only when the bridge is used, but to me that means devicetree entries > > > or something to determine whether it is used. > > > > In my opinion, we need an FPGA-specific devicetree (or something > > similar) to describe the FPGA image, anyway. > > Like a DTO ? DTOs are how i suggest solving this in linux, so i would assume a dto would be best here too. > > > Today, too much > > configuration is applied at compile time (or when programming SPL to > > flash at latest) - there's currently no way to switch peripherals to > > FPGA for one image but not for another, for example. > > Yes > > > Worse: if you enable bridges but there's no slave attached, the CPU can > > be stuck. That would need to be described with the FPGA image as well. > > Can you propose a patch ? >
Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
On Thu, 2020-03-12 at 16:57 +0100, Marek Vasut wrote: > On 3/12/20 4:54 PM, Dalon L Westergreen wrote: > [...] > > (thanks for fixing your mailer :)) > > > > > > > > The problem was that this was causing weird sporadic hangs on > > > > > > > Gen5, > > > > > > > which is why it was removed. So until there is an explanation for > > > > > > > those > > > > > > > hangs, I'm not really OK with this. > > > > > > > > > > > > These sporadic hangs you saw were on devices without an FPGA image > > > > > > directly > > > > > > accessing the SDRAM ports, right? > > > > > > > > > > Yes > > > > > > > > > > > > Maybe the application of static config should happen in SPL, > > > > > > > before > > > > > > > the > > > > > > > DRAM is running, or something like that ? > > > > > > > > > > > > Thinking this further, limiting it to applying in SPL is not a good > > > > > > idea > > > > > > since > > > > > > that prevents us from implementing different FPGA images/configs by > > > > > > loading a > > > > > > config later in the boot (i.e. in U-Boot from a FIT-image). > > > > > > > > > > Well, but later we have SDRAM running and we cannot make it go idle, > > > > > can > > > > > we? > > > > > > > > > Unfortunately the sdram cfg apply must occur AFTER the fpga is > > configured. This > > is because the FPGA drives configuration bits, around the interfaces > > datawidth > > for example, that are used in setting up the dram interface. I believe the > > intent is for the command to only run when the ridge enable function is > > called. > > So that's one part of the fix -- only run this apply_static_cfg if the > bitstream uses the F2S bridge. actually, the restriction is to apply this only if the FPGA is configured, whether the bridge is used is irrelevant. you can further restrict this to only when the bridge is used, but to me that means devicetree entries or something to determine whether it is used. > > > > > > > Would it work to make setting this optional, i.e. only write the bit > > > > > > if > > > > > > an FPGA > > > > > > config actually uses these ports? Then it couldn't lead to problems > > > > > > on > > > > > > other > > > > > > hardware... > > > > > > > > > > Can you make SDRAM bus really idle ? > > > > > > > > From the CPU side, that should work, no? Of course you have to make sure > > > > no > > > > other peripheraly (including FPGA!) are using the RAM. > > > > > > > > And if this would be an explicit command, people needing this could > > > > experiment with it - and hopefully give better hints as to what's going > > > > wrong > > > > if we *do* see problems again. > > > > > > Maybe altera has something hidden somewhere in the bus tunables ? :) > > > > The only trick i am aware of, and Ley Foon, please comment, is isolating > > relevant code to the caches before executing. > > How do you make sure some DMA doesn't do something funny or some pending > write doesn't trigger DRAM write ? There is more than the CPU that can > access the DRAM and cause bus traffic. True, and it is unclear how we could ensure there is absolutely no traffic. --dalon
Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
On Mon, 2020-03-09 at 15:25 +0100, Marek Vasut wrote: > On 3/9/20 3:24 PM, Simon Goldschmidt wrote: > > On Mon, Mar 9, 2020 at 3:15 PM Marek Vasut wrote: > > > On 3/9/20 3:10 PM, Simon Goldschmidt wrote: > > > > On Mon, Mar 9, 2020 at 1:57 PM Marek Vasut wrote: > > > > > On 3/9/20 9:50 AM, Ley Foon Tan wrote: > > > > > > On Thu, Feb 13, 2020 at 2:52 AM Dalon L Westergreen > > > > > > wrote: > > > > > > > I am reading through this thread, and want to point out that it is > > > > > > > not that the > > > > > > > FPGA bridge need be actively used in the fpga, but > > > > > > > rather that this port be configured in the FPGA > > > > > > > configuration. This is an > > > > > > > important distinction, ecery FPGA design that > > > > > > > instantiates the HPS does configure the F2S Bridge. it drives > > > > > > > select pins, > > > > > > > control pins, data pins, etc, on the interface to known values, > > > > > > > and so the apply can always be done as all SoC FPGA designs have > > > > > > > the soc > > > > > > > instantiated. If someone boots the arm, and uses an > > > > > > > FPGA design without having the soc instantiated, it may then cause > > > > > > > issues, but i > > > > > > > would argue that is not a supported use > > > > > > > in the first place. > > > > > > > > > > > > > > --dalon > > > > > > > > > > > > > > > > > > > I can reproduce the issue if without setting applycfg bit. Access to > > > > > > F2sdram interface will cause system hang. > > > > > > > > > > > > From the Cyclone 5 Soc datasheet: > > > > > > applycfg - Write with this bit set to apply all the settings loaded > > > > > > in > > > > > > SDR registers to the memory interface. This bit is write-only and > > > > > > always returns 0 if read. > > > > > > > > > > > > Software should set applycfg bit if change any register under SDR > > > > > > register range. SW is allowed to set this bit multiple times, the > > > > > > only > > > > > > condition is SDRAM need to be idle. > > > > > > My suggestion is we add back socfpga_sdram_apply_static_cfg(), but > > > > > > change the sequence to below: > > > > > > writel(iswgrp_handoff[3], &sdr_ctrl->fpgaport_rst); > > > > > > socfpga_sdram_apply_static_cfg(); > > > > > > > > > > > > Marek and Simon, are you okay with this? If yes, I will submit patch > > > > > > for this. > > > > > > > > > > The problem was that this was causing weird sporadic hangs on Gen5, > > > > > which is why it was removed. So until there is an explanation for > > > > > those > > > > > hangs, I'm not really OK with this. > > > > > > > > These sporadic hangs you saw were on devices without an FPGA image > > > > directly > > > > accessing the SDRAM ports, right? > > > > > > Yes > > > > > > > > Maybe the application of static config should happen in SPL, before > > > > > the > > > > > DRAM is running, or something like that ? > > > > > > > > Thinking this further, limiting it to applying in SPL is not a good idea > > > > since > > > > that prevents us from implementing different FPGA images/configs by > > > > loading a > > > > config later in the boot (i.e. in U-Boot from a FIT-image). > > > > > > Well, but later we have SDRAM running and we cannot make it go idle, can > > > we? > > > Unfortunately the sdram cfg apply must occur AFTER the fpga is configured. This is because the FPGA drives configuration bits, around the interfaces datawidth for example, that are used in setting up the dram interface. I believe the intent is for the command to only run when the ridge enable function is called. > > > > Would it work to make setting this optional, i.e. only write the bit if > > > > an FPGA > > > > config actually uses these ports? Then it couldn't lead to problems on > > > > other > > > > hardware... > > > > > > Can you make SDRAM bus really idle ? > > > > From the CPU side, that should work, no? Of course you have to make sure no > > other peripheraly (including FPGA!) are using the RAM. > > > > And if this would be an explicit command, people needing this could > > experiment with it - and hopefully give better hints as to what's going > > wrong > > if we *do* see problems again. > > Maybe altera has something hidden somewhere in the bus tunables ? :) The only trick i am aware of, and Ley Foon, please comment, is isolating relevant code to the caches before executing. --dalon
Re: [PATCH v2 03/21] arm: socfpga: Add function for checking description from FIT image
On Wed, 2020-02-19 at 18:11 +0100, Marek Vasut wrote: > On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > > From: Chee Hong Ang > > Add board_fit_config_name_match() for matching board name withdevice tree > > files in FIT image. This will ensure correct DTBfile is loaded for different > > board type. Currently, we are notsupporting multiple device tree files in > > FIT image therefore thisfunction basically do nothing for now. > > Signed-off-by: Chee Hong Ang --- arch/arm/mach- > > socfpga/board.c | 10 ++ 1 file changed, 10 insertions(+) > > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach- > > socfpga/board.cindex 7c8c05c..5757041 100644--- a/arch/arm/mach- > > socfpga/board.c+++ b/arch/arm/mach-socfpga/board.c@@ -86,3 +86,13 @@ int > > g_dnl_board_usb_cable_connected(void) return 1; } #endif++#ifdef > > CONFIG_SPL_BUILD+__weak int board_fit_config_name_match(const char *name) > > Why is this __weak ? The intent is to allow users to override this in their specific board implementation. > > [...]
Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
I am reading through this thread, and want to point out that it is not that the FPGA bridge need be actively used in the fpga, but rather that this port be configured in the FPGA configuration. This is an important distinction, ecery FPGA design that instantiates the HPS does configure the F2S Bridge. it drives select pins, control pins, data pins, etc, on the interface to known values, and so the apply can always be done as all SoC FPGA designs have the soc instantiated. If someone boots the arm, and uses an FPGA design without having the soc instantiated, it may then cause issues, but i would argue that is not a supported use in the first place. --dalon On Fri, 2020-02-07 at 14:49 +0100, Marek Vasut wrote: > On 2/7/20 2:44 PM, Simon Goldschmidt wrote: > > [...] > > > > > This depends on the FPGA image, while currently the Altera work flow > > > > compiles > > > > it into the U-Boot binary.While I'm still working on moving this into > > > > the U-Boot > > > > dts (I still have size issues there), it's still not encoded with the > > > > FPGA. > > > > > > Well you can dig this information out of the handoff files , so you can > > > also make this somehow configurable via either DT or bridge command args. > > > > > > My point was this can differ between FPGA images. Once you load an FPGA > > image > > that doesn't match what you expected when building (or flashing) U-Boot, the > > system may lock up again. > > > > DT is not an option, as you hard-code it when flashing U-Boot. > > You can apply a DTO on the U-Boot DT :-) > > > The loaded FPGA > > image can still change.Bridge command args is a way of how to get this info > > into > > the code that runs, but from where do these command args come? You need to > > somehow parse this info from an FPGA image file read from storage. > > Maybe this could be part of a fitImage or DTO bundled with the FPGA image ? > > > > > What we would need is some kind of meta info with the FPGA image that > > > > tells us > > > > how to configure the bridges (and maybe some clocks or hardware handed > > > > off into > > > > the FPGA) after programming the FPGA. > > > > > > fitImage ? :) > > I thought of that, too. Maybe a short dts (maybe overlay) beside the FPGA. > > But > > then it would again not work when loading a pure rbf. But then again, that > > might > > be ok... > > That's probably OK. If you're loading pure RBF, then you know what > you're doing. > > > So I could imagine this to "just work" when someday I finally have finished > > my > > series of moving this handoff info into dts and then including an overlay > > dts > > into a fit image that gets applied after programming the FPGA (and by/after > > applying it, the code that applies bridge settings would run). Would that > > work? > > I think so.
Re: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
On Tue, 2019-12-03 at 14:45 +, Ang, Chee Hong wrote: > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong < > > chee.hong@intel.com > > > > > wrote: > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > > > > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > > > > < > > > > > > chee.hong@intel.com > > > > > > > > > > > > > wrote: > > > > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > > > > < > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > > > > > > < > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM < > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > From: "Ang, Chee Hong" < > > > > > > > > > > > > > chee.hong@intel.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) > > > > > > > > > > > > > support: > > > > > > > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> > > > > > > > > > > > > > Linux > > > > > > > > > > > > > (EL1) > > > > > > > > > > > > > > > > > > > > > > > > Adding support for ATF means that using U-Boot on > > > > > > > > > > > > Stratix10 > > > > > > > > > > > > and Agilex without ATF keeps working, right? > > > > > > > > > > > > > > > > > > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot > > > > > > > > > > > to work. > > > > > > > > > > > > > > > > > > > > Is there a technical requirement for that? > > > > > > > > > > > > > > > > > > Yes. We are using ATF to provide PSCI services such as system > > > > > > > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and > > > > > > > > > other secure services such as mailbox communications with > > > > > > > > > Secure Device Manager and accessing the System Manager > > > > > > > > > registers which are > > > > > > > > > > > > secure. > > > > > > > > > Without PSCI services, we are able to boot until U-Boot proper > > > > > > > > > only. > > > > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux due to > > > > > > > > > these missing > > > > > > > > > > > > > > > > PSCI services. > > > > > > > > > Another reason is we have another boot flow which is using ATF > > > > > > > > > + > > > > UEFI. > > > > > > > > > So now we are re-using the PSCI services from ATF so that now > > > > > > > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't > > > > > > > > > have to > > > > > > > > > > > > > > > > reimplement another sets of PSCI services for U-Boot again. > > > > > > > > > This will greatly reduce our engineering efforts. > > > > > > > > > > > > > > > > Hmm, thanks for the explanation. > > > > > > > > > > > > > > > > I don't really think I can review this, given the lack of > > > > > > > > knowledge about that PSCI stuff. > > > > > > > > > > > > > > I believe you can review it. > > > > > > > Have you briefly gone through the patches ? It has nothing to do > > > > > > > with the PSCI > > > > > > > > > > > > stuff. > > > > > > > It just call the invoke_smc() function to call the ATF's PSCI > > > > > > > functions. Those PSCI functions in ATF will do the rest. > > > > > > > > > > > > No, not yet. But see below. > > > > > > > > > > > > > > I must say it seems strange to me that U-Boot would have to > > > > > > > > rely on ATF > > > > > > > > > > > > though. > > > > > > > > How do other platforms implement this? Shouldn't PSCI be > > > > > > > > generic or is it really platform specific? If it's generic, > > > > > > > > isn't that a dupliation of code if you implement e.g. a reset > > > > > > > > driver for > > > > > > > > Stratix10 but call > > > > > > > > > > > > into PSCI? > > > > > > > It's not strange at all. A lot of U-Boot users already using > > > > > > > this boot flow (ATF + > > > > > > > > > > > > U-Boot). > > > > > > > > > > > > Just because other boards do this doesn't mean it's not strange. > > > > > > Wasn't there some kind of discussion around that PSCI stuff to > > > > > > make it > > > > > > > > available from U-Boot? > > > > > > What's wrong with that way? > > > > > > > > > > Our downstream U-Boot branch is already implemented the PSCI > > > > > stuffs in U- > > > > > > > > Boot. > > > > > I tried to upstream my PSCI code: > > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html > > > > > > > > > > > > > > > Marek pointed me to this thread: > > > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html > > > > > > > > > > > > > > > He had a point. He suggested maybe we can implement the PSCI > > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out > > > > > ATF is already well > > > > > > > > supported. Why don't we just use the PSCI code from ATF rather than > > > > re- implementing the
Re: [U-Boot] [RFC PATCH v2 08/18] socfpga: gen5: add new tool to create handoff dtsi files
On Thu, 2019-10-24 at 16:29 +0200, Simon Goldschmidt wrote: > On Thu, Oct 24, 2019 at 4:25 PM Dalon L Westergreen< > dalon.westergr...@linux.intel.com> wrote: > > > > On Wed, 2019-10-23 at 21:22 +0200, Simon Goldschmidt wrote: > > Am 23.10.2019 um 18:03 schrieb Dalon L Westergreen: > > > > > > On Tue, 2019-10-22 at 19:13 +0200, Simon Goldschmidt wrote: > > > > > > Dalon L Westergreen < > > dalon.westergr...@linux.intel.com > > > > > > > > > dalon.westergr...@linux.intel.com > > > > > > schrieb am Di., 22. Okt. > > > > 2019, 19:10: > > I mentioned this before, it would be great to not rely on the > > generated files > > and do this based purely on the handoff data generated during a quartus > > build. Did you look at the python source i pointed you to? > > > > No, not yet. But I don't think that will be a problem. I sent this > > series mainly to discuss the dts format (boardspecific handoff dtsi vs > > genetic dtsi plus boardspecific header file). > > > > The board specific dtsi does look cleaner, but i do like the simplicity > > of generating the header in arria10. > > > > I could easily replicate what you do, generate the header, and use it to > > create the dtsi. > > > > I'm not too fond myself of that tool I created, as it requires you to > > have a compiler. I just was too lazy write a script for that. > > > > However, I would prefer having a script that does it. And if the sources > > are quartus output files instead of existing qts files, my tool doesn't > > work any more, anway. > > > > So I think we should come up with a script (e.g. sh or py) that parses > > quartus output and creates a handoff dtsi (without a header). We'll only > > need something different for converting existing qts files then... > > > > In that case, i would stick with adding a .h file along with a common > > handoff dtsi as i didin the a10 filter script i sent the other week. I would > > suggest your source is perfectfor migrating existing c5/a5 platforms. > > Why can't we change that a10 script to create handoff dtsi files as well? I just dont like building the dtsi in source, the code to create a header is simpler and cleaner. Froma files perspective, 1 dtsi + a header for each board, or a dtsi for each board, not sure there is muchdifference either way. but using headers keeps the utility simpler. --dalon > > Is there a preference for python? It would fit nicely b/c we could re-use > > the codeI pointed out previously for binary parsing. > > Well, *my* preference would be to not depend on having gcc installed to > convertfrom quartus output to dtsi. I just did that because C was easier toget > started. > I'm not a big fan of python, but since it's used everywhere in U-Boot, > Ifigured it should be ok? Having a standard shell script do the job would > evenlower the requirements of course. > Regards,Simon > > Dinh, Marek, Ley Foon, comments? > > --dalon > > > > Regards, > > Simon > > > > > > --dalon > > > > > > I still favor boardspecific handoff dtsi, but I would like to use the > > same style for all socfpga flavours. > > > > Plus this tool is required to convert existing boards where we don't > > have the quartus project files at hand. > > > > Regards, > > Simon > > > > > > --dalon > > > > On Tue, 2019-10-15 at 22:10 +0200, Simon Goldschmidt wrote: > > This new tool converts handoff information from quartus to "*_handoff.dtsi" > > devicetree files. This is in preparation to move from ad-hoc code in arch > > that parses the 'qts' header files to drivers parsing the same information > > from devicetree. > > > > Converting existing U-Boot 'qts' files is also supported. > > > > Signed-off-by: Simon Goldschmidt < > > simon.k.r.goldschm...@gmail.com > > > > > > > simon.k.r.goldschm...@gmail.com > > > > > > --- > > > > Changes in v2: None > > > > arch/arm/mach-socfpga/create_handoff_gen5.c | 660 > > arch/arm/mach-socfpga/qts-to-handoff.sh | 83 +++ > > 2 files changed, 743 insertions(+) > > create mode 100644 arch/arm/mach-socfpga/create_handoff_gen5.c > > create mode 100755 arch/arm/mach-socfpga/qts-to-handoff.sh > > > > diff --git a/arch/arm/mach-socfpga/create_handoff_gen5.c b/arch/arm/mach- > > socfpga/create_handoff_gen5.c > > new
Re: [U-Boot] [RFC PATCH v2 08/18] socfpga: gen5: add new tool to create handoff dtsi files
On Wed, 2019-10-23 at 21:22 +0200, Simon Goldschmidt wrote: > Am 23.10.2019 um 18:03 schrieb Dalon L Westergreen: > > On Tue, 2019-10-22 at 19:13 +0200, Simon Goldschmidt wrote: > > > Dalon L Westergreen > > dalon.westergr...@linux.intel.com>> schrieb am Di., 22. Okt. 2019, 19:10: > > > > I mentioned this before, it would be great to not rely on the generated > > > > filesand do this based purely on the handoff data generated during a > > > > quartusbuild. Did you look at the python source i pointed you to? > > > > > > No, not yet. But I don't think that will be a problem. I sent this series > > > mainly to discuss the dts format (boardspecific handoff dtsi vs genetic > > > dtsi plus boardspecific header file). > > > > The board specific dtsi does look cleaner, but i do like the simplicity of > > generating the header in arria10. > > I could easily replicate what you do, generate the header, and use it to > > create the dtsi. > > I'm not too fond myself of that tool I created, as it requires you to have a > compiler. I just was too lazy write a script for that. > However, I would prefer having a script that does it. And if the sources are > quartus output files instead of existing qts files, my tool doesn't work any > more, anway. > So I think we should come up with a script (e.g. sh or py) that parses quartus > output and creates a handoff dtsi (without a header). We'll only need > something different for converting existing qts files then... In that case, i would stick with adding a .h file along with a common handoff dtsi as i didin the a10 filter script i sent the other week. I would suggest your source is perfectfor migrating existing c5/a5 platforms. Is there a preference for python? It would fit nicely b/c we could re-use the codeI pointed out previously for binary parsing. Dinh, Marek, Ley Foon, comments? --dalon > Regards,Simon > > --dalon > > > I still favor boardspecific handoff dtsi, but I would like to use the same > > > style for all socfpga flavours. > > > Plus this tool is required to convert existing boards where we don't have > > > the quartus project files at hand. > > > Regards,Simon > > > > --dalon > > > > On Tue, 2019-10-15 at 22:10 +0200, Simon Goldschmidt wrote: > > > > > This new tool converts handoff information from quartus to > > > > > "*_handoff.dtsi"devicetree files. This is in preparation to move from > > > > > ad-hoc code in archthat parses the 'qts' header files to drivers > > > > > parsing the same informationfrom devicetree. > > > > > Converting existing U-Boot 'qts' files is also supported. > > > > > Signed-off-by: Simon Goldschmidt > > > > <mailto:simon.k.r.goldschm...@gmail.com> > > > > > --- > > > > > Changes in v2: None > > > > > arch/arm/mach-socfpga/create_handoff_gen5.c | 660 > > > > > arch/arm/mach-socfpga/qts-to- > > > > > handoff.sh | 83 +++ 2 files changed, 743 insertions(+) create > > > > > mode 100644 arch/arm/mach-socfpga/create_handoff_gen5.c create mode > > > > > 100755 arch/arm/mach-socfpga/qts-to-handoff.sh > > > > > diff --git a/arch/arm/mach-socfpga/create_handoff_gen5.c > > > > > b/arch/arm/mach-socfpga/create_handoff_gen5.cnew file mode 100644index > > > > > 00..6ec436719d--- /dev/null+++ b/arch/arm/mach- > > > > > socfpga/create_handoff_gen5.c@@ -0,0 +1,660 @@+// SPDX-License- > > > > > Identifier: GPL-2.0+/*+ * This is a host-tool that needs to be > > > > > compiled per board and prints the+ * handoff.dtsi to stdout.+ > > > > > */++#include +#include ++/* Define kernel types > > > > > */+typedef uint8_t u8;+typedef uint32_t u32;++#ifdef > > > > > USE_QUARTUS_OUTPUT+#ifdef ARRIA5+#include > > > > > "iocsr_config_arria5.c"+#include > > > > > "pinmux_config_arria5.c"+#else+#include > > > > > "iocsr_config_cyclone5.c"+#include > > > > > "pinmux_config_cyclone5.c"+#endif+#include "pll_config.h"+#include > > > > > "sdram/sdram_config.h"+#include "sequencer_auto.h"+#include > > > > > "sequencer_defines.h"+#include "sequencer_auto_ac_init.c"+#include > > > > > "sequencer_auto_inst_init.c"+#define RW_MGR(x) > > > > > __RW_MGR_#
Re: [U-Boot] [RFC PATCH v2 08/18] socfpga: gen5: add new tool to create handoff dtsi files
On Tue, 2019-10-22 at 19:13 +0200, Simon Goldschmidt wrote: > Dalon L Westergreen schrieb am Di., 22. > Okt. 2019, 19:10: > > I mentioned this before, it would be great to not rely on the generated > > files > > and do this based purely on the handoff data generated during a quartus > > build. Did you look at the python source i pointed you to? > > No, not yet. But I don't think that will be a problem. I sent this series > mainly to discuss the dts format (boardspecific handoff dtsi vs genetic dtsi > plus boardspecific header file). The board specific dtsi does look cleaner, but i do like the simplicity of generating the header in arria10. I could easily replicate what you do, generate the header, and use it to create the dtsi. --dalon > I still favor boardspecific handoff dtsi, but I would like to use the same > style for all socfpga flavours. > > Plus this tool is required to convert existing boards where we don't have the > quartus project files at hand. > > Regards, > Simon > > > --dalon > > On Tue, 2019-10-15 at 22:10 +0200, Simon Goldschmidt wrote: > > > This new tool converts handoff information from quartus to > > > "*_handoff.dtsi"devicetree files. This is in preparation to move from ad- > > > hoc code in archthat parses the 'qts' header files to drivers parsing the > > > same informationfrom devicetree. > > > Converting existing U-Boot 'qts' files is also supported. > > > Signed-off-by: Simon Goldschmidt --- > > > Changes in v2: None > > > arch/arm/mach-socfpga/create_handoff_gen5.c | 660 > > > arch/arm/mach-socfpga/qts-to-handoff.sh | 83 +++ 2 files changed, 743 > > > insertions(+) create mode 100644 arch/arm/mach- > > > socfpga/create_handoff_gen5.c create mode 100755 arch/arm/mach- > > > socfpga/qts-to-handoff.sh > > > diff --git a/arch/arm/mach-socfpga/create_handoff_gen5.c b/arch/arm/mach- > > > socfpga/create_handoff_gen5.cnew file mode 100644index > > > 00..6ec436719d--- /dev/null+++ b/arch/arm/mach- > > > socfpga/create_handoff_gen5.c@@ -0,0 +1,660 @@+// > > > SPDX-License-Identifier: > > > GPL-2.0+/*+ * This is a host-tool that needs to be compiled per board and > > > prints the+ * handoff.dtsi to stdout.+ */++#include +#include > > > ++/* Define kernel types */+typedef uint8_t u8;+typedef uint32_t > > > u32;++#ifdef USE_QUARTUS_OUTPUT+#ifdef ARRIA5+#include > > > "iocsr_config_arria5.c"+#include "pinmux_config_arria5.c"+#else+#include > > > "iocsr_config_cyclone5.c"+#include > > > "pinmux_config_cyclone5.c"+#endif+#include "pll_config.h"+#include > > > "sdram/sdram_config.h"+#include "sequencer_auto.h"+#include > > > "sequencer_defines.h"+#include "sequencer_auto_ac_init.c"+#include > > > "sequencer_auto_inst_init.c"+#define RW_MGR(x) __RW_MGR_##x+#else+#define > > > RW_MGR(x) RW_MGR_##x+#include +#include > > > +#include +#include > > > +#endif++#include > > > "include/mach/clock_manager_gen5.h"+#include > > > "include/mach/sdram_gen5.h"++#ifndef ARRAY_SIZE+#define ARRAY_SIZE(x) > > > (sizeof(x)/sizeof((x)[0]))+#endif++const char handoff_dtsi_hdr[] =+ > > > "// SPDX-License-Identifier: GPL-2.0\n"+ "/*\n"+ " * > > generated>\n"+" * This code was generated by a tool based on\n"+ > > > " > > > * handoffs from both Qsys and Quartus.\n"+" *\n"+ " * Changes > > > to > > > this file may be lost if\n"+ " * the code is regenerated.\n"+ > > > " > > > *\n"+" */\n";++/* Wrap PLL config */++#define > > > MAIN_VCO_BASE ( \+ > > > (CONFIG_HPS_MAINPL > > > LGRP_VCO_DENOM << \+ > > > CLKMGR_MAINPLLGRP_VCO_DENOM_OFFSET > > > ) | \+ (CONFIG_HPS_MAINPLLGRP_VCO_NUMER << \+ > > > > > > CLKMGR_MAINPLLGRP_VCO_NUMER_OFFSET) \+ )++#define > > > PERI_VCO_BASE ( > > > \+ (CONFIG_HPS_PERPLLGRP_VCO_ > > > PSRC << \+ CLKMGR_PERPLLGRP_VCO_PSRC_OFFSET) | > > > \+ > > > (CONFIG_HPS_PERPLLGRP_VCO_DENOM << \+ CL > > > KMGR_PERPLLGRP_VCO_DENOM_OFFSET) |\+ > > >
Re: [U-Boot] [RFC PATCH v2 08/18] socfpga: gen5: add new tool to create handoff dtsi files
I mentioned this before, it would be great to not rely on the generated filesand
do this based purely on the handoff data generated during a quartusbuild. Did
you look at the python source i pointed you to?
--dalon
On Tue, 2019-10-15 at 22:10 +0200, Simon Goldschmidt wrote:
> This new tool converts handoff information from quartus to
> "*_handoff.dtsi"devicetree files. This is in preparation to move from ad-hoc
> code in archthat parses the 'qts' header files to drivers parsing the same
> informationfrom devicetree.
> Converting existing U-Boot 'qts' files is also supported.
> Signed-off-by: Simon Goldschmidt ---
> Changes in v2: None
> arch/arm/mach-socfpga/create_handoff_gen5.c | 660
> arch/arm/mach-socfpga/qts-to-handoff.sh | 83 +++ 2 files changed, 743
> insertions(+) create mode 100644 arch/arm/mach-socfpga/create_handoff_gen5.c
> create mode 100755 arch/arm/mach-socfpga/qts-to-handoff.sh
> diff --git a/arch/arm/mach-socfpga/create_handoff_gen5.c b/arch/arm/mach-
> socfpga/create_handoff_gen5.cnew file mode 100644index 00..6ec436719d-
> -- /dev/null+++ b/arch/arm/mach-socfpga/create_handoff_gen5.c@@ -0,0 +1,660
> @@+// SPDX-License-Identifier: GPL-2.0+/*+ * This is a host-tool that needs to
> be compiled per board and prints the+ * handoff.dtsi to stdout.+ */++#include
> +#include ++/* Define kernel types */+typedef uint8_t
> u8;+typedef uint32_t u32;++#ifdef USE_QUARTUS_OUTPUT+#ifdef ARRIA5+#include
> "iocsr_config_arria5.c"+#include "pinmux_config_arria5.c"+#else+#include
> "iocsr_config_cyclone5.c"+#include "pinmux_config_cyclone5.c"+#endif+#include
> "pll_config.h"+#include "sdram/sdram_config.h"+#include
> "sequencer_auto.h"+#include "sequencer_defines.h"+#include
> "sequencer_auto_ac_init.c"+#include "sequencer_auto_inst_init.c"+#define
> RW_MGR(x) __RW_MGR_##x+#else+#define RW_MGR(x) RW_MGR_##x+#include
> +#include +#include +#include
> +#endif++#include "include/mach/clock_manager_gen5.h"+#include
> "include/mach/sdram_gen5.h"++#ifndef ARRAY_SIZE+#define ARRAY_SIZE(x)
> (sizeof(x)/sizeof((x)[0]))+#endif++const char handoff_dtsi_hdr[] =+ "//
> SPDX-License-Identifier: GPL-2.0\n"+ "/*\n"+ " *\n"+ " *
> This code was generated by a tool based on\n"+" * handoffs from
> both Qsys and Quartus.\n"+" *\n"+ " * Changes to this file may be
> lost if\n"+ " * the code is regenerated.\n"+" * generated>\n"+" */\n";++/* Wrap PLL config */++#define MAIN_VCO_BASE (
> \+ (CONFIG_HPS_MAINPLLGRP_VCO_DEN
> OM << \+ CLKMGR_MAINPLLGRP_VCO_DENOM_OFFSET) | \+
> (CONFIG_HPS_MAINPLLGRP_VCO_NUMER << \+ CLKMGR_MAINPLL
> GRP_VCO_NUMER_OFFSET) \+ )++#define PERI_VCO_BASE (
> \+ (CONFIG_HPS_PERPLLGRP_VCO_PSRC << \+
> CLKMGR_PERPLLGRP_VCO_PSRC_OFFSET) | \+ (CONFIG_HPS_PERPLLGRP_
> VCO_DENOM << \+ CLKMGR_PERPLLGRP_VCO_DENOM_OFFSET) |
> \+(CONFIG_HPS_PERPLLGRP_VCO_NUMER << \+ CLKMGR
> _PERPLLGRP_VCO_NUMER_OFFSET) \+ )++#define SDR_VCO_BASE (
> \+ (CONFIG_HPS_SDRPLLGRP_VCO_SSRC <<
> \+CLKMGR_SDRPLLGRP_VCO_SSRC_OFFSET) | \+ (CONFIG_HPS_SD
> RPLLGRP_VCO_DENOM << \+ CLKMGR_SDRPLLGRP_VCO_DENOM_OFF
> SET) |\+ (CONFIG_HPS_SDRPLLGRP_VCO_NUMER << \+
> CLKMGR_SDRPLLGRP_VCO_NUMER_OFFSET) \+ )++static const struct
> cm_config cm_default = {+ /* main group */+ MAIN_VCO_BASE,+
> (CONFIG_HPS_MA
> INPLLGRP_MPUCLK_CNT <<+ CLKMGR_MAINPLLGRP_MPUCLK_CNT_OFFSET),+
> (CONFIG_HPS_MAINPLLGRP_MAINCLK_CNT <<+CLKMGR_MAINPLLGRP_MAINCL
> K_CNT_OFFSET),+ (CONFIG_HPS_MAINPLLGRP_DBGATCLK_CNT <<+ CLKMGR
> _MAINPLLGRP_DBGATCLK_CNT_OFFSET),+(CONFIG_HPS_MAINPLLGRP_MAINQSPICLK_CNT
> <<+ CLKMGR_MAINPLLGRP_MAINQSPICLK_CNT_OFFSET),+ (CONFIG_HPS_MA
> INPLLGRP_MAINNANDSDMMCCLK_CNT <<+ CLKMGR_PERPLLGRP_PERNANDSDMMCCLK
> _CNT_OFFSET),+(CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT <<+
> CLKMGR_MAINPLLGRP_CFGS2FUSER0CLK_CNT_OFFSET),+(CONFIG_HPS_MAINPLLGRP_M
> AINDIV_L3MPCLK <<+CLKMGR_MAINPLLGRP_MAINDIV_L3MPCLK_OFFSET) |+
> (CONFIG_HPS_MAINPLLGRP_MAINDIV_L3SPCLK <<+CLKMGR_MAINPLLGRP_MAINDI
> V_L3SPCLK_OFFSET) |+ (CONFIG_HPS_MAINPLLGRP_MAINDIV_L4MPCLK <<+
> CLKMGR_MAINPLLGRP_MAINDIV_L4MPCLK_OFFSET) |+ (CONFIG_HPS_MAINPLLGRP_MAINDIV_L
> 4SPCLK <<+CLKMGR_MAINPLLGRP_MAINDIV_L4SPCLK_OFFSET),+ (CONFI
> G_HPS_MAINPLLGRP_DBGDIV_DBGATCLK <<+ CLKMGR_MAINPLLGRP_DBGDIV_DBGATCL
> K_OFFSET) |+ (CONFIG_HPS_MAINPLLGRP_DBGDIV_DBGCLK <<+
> CLKMGR_MAINPLL
> GRP_DBGDIV_DBGCLK_OFFSET),+ (CONFIG_HPS_MAINPLLGRP_TRACEDIV_TRACECLK <<+
>
Re: [U-Boot] [RESEND PATCH v3 1/2] Makefile: Add target to generate hex output for combined spl and dtb
On Sat, 2019-10-05 at 21:40 +0200, Simon Goldschmidt wrote:
> Am 27.09.2019 um 20:27 schrieb Dalon Westergreen:
> > From: Dalon Westergreen
> > Stratix10 requires a hex image of the spl plus spl devicetree offset tothe
> > Stratix10 onchip memory located at SPL_TEXT_BASE. This patch addsa target
> > to generate a hex file from the u-boot-spl binary including thedtb offset at
> > SPL_TEST_BASE.
> > Objcopy is used to convert the $(SPL_BIN).bin, which includes the spldtb, to
> > a hex file. the --change-address option is used to offset thehex to
> > SPL_TEXT_BASE as objcopy on the spl binary will not result ina hex file
> > appropriately offset at SPL_TEXT_BASE.
> > Signed-off-by: Dalon Westergreen
> > ---Changes in v3: -> Cleanup commit message and better describe the problem
> > being resolved -> Remove extraneous hunk -> use SPL_BIN instead of u-
> > boot-splChanges in v2: -> Move spl hex file generation to SPL Makefile ->
> > Create hexfile from $(SPL_BIN).bin which will include the
> > dtb ifneq(build_dtb,)--- Makefile | 8 +++--
> > --- scripts/Makefile.spl | 7 +++ 2 files changed, 10 insertions(+), 5
> > deletions(-)
> > diff --git a/Makefile b/Makefileindex 1d9ade948b..0bc9d1589f 100644---
> > a/Makefile+++ b/Makefile@@ -1152,11 +1152,6 @@
> > OBJCOPYFLAGS_u-boot-nodtb.bin
> > := -O binary \ $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R
> > .resetvec) \$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R
> > .bootpg -R .resetvec) -OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-
> > boot.hex)--spl/u-boot-spl.hex: spl/u-boot-spl FORCE-$(call
> > if_changed,objcopy)- binary_size_check: u-boot-nodtb.bin FORCE @file_si
> > ze=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \ map_size
> > =$(shell cat u-boot.map | \@@ -1756,6 +1751,9 @@ spl/u-boot-spl.bin: spl/u-
> > boot-spl@: $(SPL_SIZE_CHECK) +spl/u-boot-spl.hex: spl/u-boot-
> > spl+@:+ spl/u-boot-spl: tools prepare \$(if
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb)
> > \ $(if
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
> > diff --git a/scripts/Makefile.spl b/scripts/Makefile.splindex
> > 7af6b120b6..551002194e 100644--- a/scripts/Makefile.spl+++
> > b/scripts/Makefile.spl@@ -216,6 +216,8 @@ ifneq
> > ($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),) ALL-y
> > += $(obj)/$(SPL_BIN).sfp endif +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) +=
> > $(obj)/$(SPL_BIN).hex+ ifdef CONFIG_ARCH_SUNXI ALL-y += $(obj)/sunxi-
> > spl.bin @@ -363,6 +365,11 @@ endif $(obj)/$(SPL_BIN).sfp:
> > $(obj)/$(SPL_BIN).bin FORCE $(call
> > if_changed,mkimage) +OBJCOPYFLAGS_$(SPL_BIN).hex := -I binary -O ihex --
> > change-address=$(CONFIG_SPL_TEXT_BASE)++$(obj)/$(SPL_BIN).hex:
> > $(obj)/$(SPL_BIN).bin FORCE+$(call if_changed,objcopy)+
>
> While I like the idea of this patch, and I *think* that this is what an SPL
> hex should look like for all platforms, I'm not 100% sure that globally
> changing the rule and objcopy flags for u-boot-spl.hex is OK for all
> architectures?
> Let's try to apply this at the start of next merge window, then we'll
> hopefully see if this does break any board.
> Reviewed-by: Simon Goldschmidt
> Regards,Simon
sounds good, i dont believe there are other boards with SPL hex as atarget, at
least none that i found.
--dalon
> > quiet_cmd_mksunxiboot = MKSUNXI $@ cmd_mksunxiboot =
> > $(objtree)/tools/mksunxiboot \ --default-dt
> > $(CONFIG_DEFAULT_DEVICE_TREE) $< $@
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v3 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Sat, 2019-10-05 at 21:41 +0200, Simon Goldschmidt wrote: > Am 27.09.2019 um 20:27 schrieb Dalon Westergreen: > > From: Dalon Westergreen > > CONFIG_OF_EMBED was primarily enabled to support the stratix10spl hex file > > requirements. Since this option now produces awarning during build, and the > > spl hex can be created usingalternate methods, CONFIG_OF_EMBED is no longer > > needed. > > Signed-off-by: Dalon Westergreen > > --- configs/socfpga_stratix10_defconfig | 1 > > - include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 1 > > insertion(+), 2 deletions(-) > > diff --git a/configs/socfpga_stratix10_defconfig > > b/configs/socfpga_stratix10_defconfigindex 5ae53a4db9..ae1b9bead1 100644--- > > a/configs/socfpga_stratix10_defconfig+++ > > b/configs/socfpga_stratix10_defconfig@@ -27,7 +27,6 @@ > > CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENER > > IC=y- > > CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" CON > > FIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=ydiff --git > > a/include/configs/socfpga_stratix10_socdk.h > > b/include/configs/socfpga_stratix10_socdk.hindex 7b55dd14da..f9ecf9d2df > > 100644--- a/include/configs/socfpga_stratix10_socdk.h+++ > > b/include/configs/socfpga_stratix10_socdk.h@@ -204,6 +204,6 @@ unsigned int > > cm_get_l4_sys_free_clk_hz(void);/* SPL SDMMC boot support */ #define > > CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1-#define > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img"+#define > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img" > > Didn't we have this before? The payload name "u-boot.img" is correct for all > configurations. Without CONFIG_OF_EMBED the two above are the same, but > changing the name should not be necessary. > Regards,Simon Correct, but it seems convention is to just use u-boot.img and i would like all the socfpga devicesto do the same thing. --dalon > > #endif /* __CONFIG_H */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Mon, 2019-10-07 at 16:45 +0200, Simon Goldschmidt wrote:
> There's something wrong with your mailer: indentation of replies doesn't
> seemto work. It gets kind of hard to read who wrote what...
> On Mon, Oct 7, 2019 at 4:34 PM Dalon L Westergreen<
> dalon.westergr...@linux.intel.com> wrote:
> > On Sun, 2019-10-06 at 20:05 +0200, Simon Goldschmidt wrote:
> > Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen:
> > On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> > On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > From: Dalon Westergreen <
> > dalon.westergr...@intel.com
> >
> >
> > > dalon.westergr...@intel.com
> >
> >
> > Generic handoff devicetree include uses a header generated bythe qts-filter-
> > a10.sh script in mach-socfpga. The scriptcreates the header based on design
> > specific implementationsfor clock and pinmux configurations.
> >
> > [...]
> > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> >
> > [...]
> > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+ compatible =
> > "altr,socfpga-a10-clk-init";+ reg = <0xffd04000 0x0200>;+
> > reg-names = "soc_clock_manager_OCP_SLV"; u-boot,dm-pre-
> > reloc; mainpll {+ vco0-psrc =
> > ;+ vco1-denom =
> > ;+ vco1-numer =
> > ;
> >
> > But these bits are board-specific , they shouldn't be in common DT.
> >
> > This common dtsi requires that the top level u-boot.dtsi include the board
> > specific header. The format
> > and #define names are in fact common.
> >
> > OK, I now see what you're doing here. Can you explain that in a bit more
> > detail in the commit message ?
> >
> > Basically socfpga_board.h is included socfpga_board.dts , and then the
> > preprocessor correctly expands the values from socfpga_board.h in the
> > socfpga_board.dts , so this works for multiple boards too ?
> >
> > Exactly. Will add more detail in the commit message, and slim down the
> > included clocks in
> > the u-boot.dtsi
> >
> > I'm (still) working on a series to bring gen5 completely to devicetree,
> > so that the 'qts' directories can be removed. I chose a different
> > approach however, in that I generated everything into a '-handoff.dtsi'
> > file (*). I'd be happy if we could find a common mechanism for all
> > socfpga sub-archs. How does S10/Agilex handle this?
> >
> > (*): Gen5 has the downside that we're low on memory in SPL (regarding
> > DM), and as we require large binary arrays there, I chose to encode the
> > binary blob arrays in host byte order so that they could be used
> > in-place instead of copying them from BE (dtb) to LE (stack/heap). Maybe
> > that doesn't fit A10/S10/Agilex anyway?
> >
> > Can you share your patch set with me, privately or otherwise, just so we can
> > take a similarapproach in the devicetree?
>
> Give me a week max. and I'll send the series as RFC.
> > Also, have you looked at the bsp-editor python source that generates the
> > "generated" filesfrom the bsp-editor?
> > 19.1std/647/linux64/ip/altera/preloader/scripts
>
> No, I mainly focused on the U-Boot part for now. I just wrote a C programthat
> did the conversion from 'official generated' files to DTS...
> > I am hoping to replace these with a script included in the u-boot source.
> > iocsr.py doesa bunch of binary parsing.
>
> Right, a direct conversion from compilation output to U-Boot would be
> better.However, that would require Intel to keep that output consistent!
It should be consistent at this point. i would not worry about that.
> Regards,Simon
> > --dalon
> >
> > Regards,
> > Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] ARM: socfpga: arria10: Sync A10 SoCDK devicetrees
On Mon, 2019-10-07 at 07:49 -0700, Dalon L Westergreen wrote: > On Mon, 2019-10-07 at 16:06 +0200, Marek Vasut wrote: > > On 10/7/19 4:03 PM, Dalon L Westergreen wrote: > > > On Sat, 2019-10-05 at 16:23 -0700, Dalon L Westergreen wrote: > > > > On Sat, 2019-10-05 at 01:47 +0200, Marek Vasut wrote: > > > > > On 10/5/19 12:30 AM, Dalon Westergreen wrote: > > > > > > From: Dalon Westergreen Sync > > > > > > devicetreefrom5.2 kernel. > > > > > > > > > > Linux 5.3 was already released, can you update this ?Also, make > > > > > suretolistthe exact commit ID in the commit message whenimporting > > > > > stufffromLinux. > > > > > > > > Sure. will do.--dalon > > > > > > The 5.3 mainline devicetrees do not as of yet have all > > > appropriatecompatibilitystringsfor the socfpga platform and still differs > > > slightly fromthe linux-socfpga/5.2 kernelas can be seen below.I would > > > suggest stickingwith the linux-socfpga/5.2 kernel devicetrees and i > > > canappendthe commitmessage with the commit and git repo if that works? > > > > What's linux-socfpga , is that something else than linux mainline ?If > > there's stuff missing in the DTs, put it into -u-boot.dtsi for now,until > > ittrickles upstream. > > Sounds good. digging a little deeper, it is just that the dwmac-socfpga add on to the ethernet driver in u-bootis lagging a bit and doesnt have the altr,socfpga- stmmac-a10-s10 for a10/s10 differences. i'll look at updating the driver in another patch set. --dalon > > > --dalon[dwesterg@dwesterg-mobl1 linux-socfpga]$ diff > > > socfpga_arria10.dtsi/home/dwesterg/data/git/uboot/u- > > > boot/arch/arm/dts/socfpga_arria10.dtsi diff:socfpga_arria10.dtsi: No such > > > file or directory[dwesterg@dwesterg-mobl1 linux-socfpga]$ diff > > > arch/arm/boot/dts/socfpga_arria10.dtsi/home/dwesterg/data/git/uboot/u- > > > boot/arch/arm/dts/socfpga_arria10.dtsi 70a71> > > > microcode-cached;421c422< compatible > > > ="altr,socfpga- > > > stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";---> > > > compatible = "altr,socfpga-stmmac", "snps,dwmac- > > > 3.72a","snps,dwmac";441,442c442,443< compatible = > > > "altr,socfpga-stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";< > > > > > > altr,sys > > > > [...] > ___U-Boot mailing > listu-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] ARM: socfpga: arria10: Sync A10 SoCDK devicetrees
On Mon, 2019-10-07 at 16:06 +0200, Marek Vasut wrote: > On 10/7/19 4:03 PM, Dalon L Westergreen wrote: > > On Sat, 2019-10-05 at 16:23 -0700, Dalon L Westergreen wrote: > > > On Sat, 2019-10-05 at 01:47 +0200, Marek Vasut wrote: > > > > On 10/5/19 12:30 AM, Dalon Westergreen wrote: > > > > > From: Dalon Westergreen Sync devicetree > > > > > from5.2 kernel. > > > > > > > > Linux 5.3 was already released, can you update this ?Also, make sure > > > > tolistthe exact commit ID in the commit message whenimporting stuff > > > > fromLinux. > > > > > > Sure. will do.--dalon > > > > The 5.3 mainline devicetrees do not as of yet have all appropriate > > compatibilitystringsfor the socfpga platform and still differs slightly from > > the linux-socfpga/5.2 kernelas can be seen below.I would suggest sticking > > with the linux-socfpga/5.2 kernel devicetrees and i canappendthe commit > > message with the commit and git repo if that works? > > What's linux-socfpga , is that something else than linux mainline ? > If there's stuff missing in the DTs, put it into -u-boot.dtsi for now,until it > trickles upstream. Sounds good. > > > --dalon > > [dwesterg@dwesterg-mobl1 linux-socfpga]$ diff socfpga_arria10.dtsi > > /home/dwesterg/data/git/uboot/u-boot/arch/arm/dts/socfpga_arria10.dtsi diff: > > socfpga_arria10.dtsi: No such file or directory[dwesterg@dwesterg-mobl1 > > linux- > > socfpga]$ diff arch/arm/boot/dts/socfpga_arria10.dtsi > > /home/dwesterg/data/git/uboot/u-boot/arch/arm/dts/socfpga_arria10.dtsi > > 70a71> > > microcode-cached;421c422< compatible = > > "altr,socfpga-stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";---> > > > > compatible = "altr,socfpga-stmmac", "snps,dwmac-3.72a", > > "snps,dwmac";441,442c442,443< compatible = > > "altr,socfpga- > > stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";< > > altr,sys > > [...] ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Sun, 2019-10-06 at 20:05 +0200, Simon Goldschmidt wrote:
> Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen:
> > On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> > > On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > > > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > > > From: Dalon Westergreen > > > > > <mailto:dalon.westergr...@intel.com>
> > > > > > Generic handoff devicetree include uses a header generated bythe
> > > > > > qts-filter-a10.sh script in mach-socfpga. The scriptcreates the
> > > > > > header based on designspecific implementationsfor clock and pinmux
> > > > > > configurations.
> > > > >
> > > > > [...]
> > > > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > > > >
> > > > > [...]
> > > > > > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > > > comp
> > > > > > atible ="altr,socfpga-a10-clk-init";+ reg =
> > > > > > <0xffd04000 0x0200>;+ reg-names =
> > > > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > > > mainpll {+ vco0-psrc
> > > > > > =;+
> > > > > > vco1-denom =;+
> > > > > > vco1-numer =;
> > > > >
> > > > > But these bits are board-specific , they shouldn't be in common DT.
> > > >
> > > > This common dtsi requires that the top level u-boot.dtsi include the
> > > > boardspecific header. The formatand #define names are in fact common.
> > >
> > > OK, I now see what you're doing here. Can you explain that in a bit
> > > moredetail in the commit message ?
> > > Basically socfpga_board.h is included socfpga_board.dts , and then
> > > thepreprocessor correctly expands the values from socfpga_board.h in
> > > thesocfpga_board.dts , so this works for multiple boards too ?
> >
> > Exactly. Will add more detail in the commit message, and slim down the
> > included clocks inthe u-boot.dtsi
>
> I'm (still) working on a series to bring gen5 completely to devicetree, so
> that the 'qts' directories can be removed. I chose a different approach
> however, in that I generated everything into a '-handoff.dtsi' file (*). I'd
> be happy if we could find a common mechanism for all socfpga sub-archs. How
> does S10/Agilex handle this?
> (*): Gen5 has the downside that we're low on memory in SPL (regarding DM), and
> as we require large binary arrays there, I chose to encode the binary blob
> arrays in host byte order so that they could be used in-place instead of
> copying them from BE (dtb) to LE (stack/heap). Maybe that doesn't fit
> A10/S10/Agilex anyway?
Can you share your patch set with me, privately or otherwise, just so we can
take a similarapproach in the devicetree?
Also, have you looked at the bsp-editor python source that generates the
"generated" filesfrom the bsp-editor?
19.1std/647/linux64/ip/altera/preloader/scripts
I am hoping to replace these with a script included in the u-boot
source. iocsr.py doesa bunch of binary parsing.
--dalon
> Regards,Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] ARM: socfpga: arria10: Sync A10 SoCDK devicetrees
On Sat, 2019-10-05 at 16:23 -0700, Dalon L Westergreen wrote:
> On Sat, 2019-10-05 at 01:47 +0200, Marek Vasut wrote:
> > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > From: Dalon Westergreen Sync devicetree from
> > > 5.2 kernel.
> >
> > Linux 5.3 was already released, can you update this ?Also, make sure to
> > listthe exact commit ID in the commit message whenimporting stuff from
> > Linux.
>
> Sure. will do.
> --dalon
The 5.3 mainline devicetrees do not as of yet have all appropriate compatibility
stringsfor the socfpga platform and still differs slightly from the linux-
socfpga/5.2 kernelas can be seen below.
I would suggest sticking with the linux-socfpga/5.2 kernel devicetrees and i can
appendthe commit message with the commit and git repo if that works?
--dalon
[dwesterg@dwesterg-mobl1 linux-socfpga]$ diff socfpga_arria10.dtsi
/home/dwesterg/data/git/uboot/u-boot/arch/arm/dts/socfpga_arria10.dtsi diff:
socfpga_arria10.dtsi: No such file or directory[dwesterg@dwesterg-mobl1 linux-
socfpga]$ diff arch/arm/boot/dts/socfpga_arria10.dtsi
/home/dwesterg/data/git/uboot/u-boot/arch/arm/dts/socfpga_arria10.dtsi 70a71>
microcode-cached;421c422< compatible =
"altr,socfpga-stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";--->
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.72a",
"snps,dwmac";441,442c442,443< compatible = "altr,socfpga-
stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";< altr,sys
mgr-syscon = <&sysmgr 0x48 8>;---> compatible =
"altr,socfpga-stmmac", "snps,dwmac-3.72a", "snps,dwmac";>
altr,sysmgr-syscon = <&sysmgr 0x48 0>;461,462c462,463< compatib
le = "altr,socfpga-stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";<
altr,sysmgr-syscon = <&sysmgr 0x4C 16>;---> compatible =
"altr,socfpga-stmmac", "snps,dwmac-3.72a", "snps,dwmac";>
altr,sysmgr-syscon = <&sysmgr 0x4C 0>;[dwesterg@dwesterg-mobl1 linux-socfpga]$
diff arch/arm/boot/dts/socfpga_arria10.dtsi /home/dwesterg/data/git/uboot/u-
boot/arch/arm/dts/socfpga_arria10socfpga_arria10-common-u-
boot.dtsi socfpga_arria10_handoff_u-
boot.dtsi~ socfpga_arria10_socdk_sdmmc.dts socfpga_arria10.dtsi
socfpga_arria10_socdk.dtsi socfpga_arria10_socdk_
sdmmc_handoff.hsocfpga_arria10-
handoff.dtsi socfpga_arria10_socdk_sdmmc.dtb socfpga_arria1
0_socdk_sdmmc-u-boot.dtsi [dwesterg@dwesterg-mobl1 linux-socfpga]$ diff
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi /home/dwesterg/data/git/uboot/u-
boot/arch/arm/dts/socfpga_arria10_socdk.dtsi 123a124,127> > ps_alarm
{> compatible = "altr,a10sr-hwmon";> };149a15
4,161> lcd: lcd@28 {> compatible = "newhaven,nhd-0216k3z-nsw-bbw";>
reg = <0x28>;> height = <2>;> width = <16>;> brightne
ss = <8>;> };> 158a171,175>};> > max@4c {> compatib
le = "max1619";>reg = <0x4c>;
> ___U-Boot mailing
> listu-b...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] ARM: socfpga: arria10: Add common u-boot devicetree include
On Sat, 2019-10-05 at 01:49 +0200, Marek Vasut wrote:
> On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > From: Dalon Westergreen
> > Add a common u-boot devicetree include file for the SocFPGAArria10 device.
>
> Isn't arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi doing basicallythe same
> thing, except more fine-grained ?
I wanted to keep the dts fragment dependent on the handoff header separate from
thegeneric base u-boot include.
> > diff --git a/arch/arm/dts/socfpga_arria10-common-u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria10-common-u-boot.dtsinew file mode 100644index
> > 00..bd4f1271f3--- /dev/null+++ b/arch/arm/dts/socfpga_arria10-
> > common-u-boot.dtsi@@ -0,0 +1,206 @@+// SPDX-License-Identifier: GPL-2.0+/*+
> > * Copyright Altera Corporation (C) 2014. All rights reserved.+ */++/ {+
> > #address-cells = <1>;+ #size-cells = <1>;++chosen {+
> > tick
> > -timer = &timer2;+ u-boot,dm-pre-reloc;+ };++memory@0 {+
> > u-boot,dm-pre-reloc;+ };++soc {+ u-boot,dm-pre-
> > reloc;++clkmgr@ffd04000 {+ u-boot,dm-pre-
> > reloc;++clocks {+
> > u-
> > boot,dm-pre-reloc;++cb_intosc_hs_div
> > 2_clk {+u-boot,dm-pre-reloc;+
> > };++cb_i
> > ntosc_ls_clk {+ u-boot,dm-pre-
> > reloc;+ };++
> > f2s_free_clk {+ u-boot,dm-
> > pre-reloc;+ };++
> > osc1 {+ u-boot,dm-pre-
> > reloc;+ };++
> > main_pll@40 {+ u-boot,dm-
> > pre-reloc;++main_mpu_base_cl
> > k {+u-boot,dm-pre-
> > reloc;+ };++
> > main_noc_base_clk {+
> > u-boot,dm-pre-reloc;+
> > };++main_emaca_clk@68 {+
> > u-boot,dm-pre-reloc;+
> > };
>
> Do we really need all this in SPL for every board ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > From: Dalon Westergreen Generic handoff
> > > > devicetree include uses a header generated bythe qts-filter-a10.sh
> > > > script in mach-socfpga. The scriptcreates the header based on
> > > > designspecific implementationsfor clock and pinmux configurations.
> > >
> > > [...]
> > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > >
> > > [...]
> > > > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > compatible ="altr,socfpga-a10-clk-init";+ reg =
> > > > <0xffd04000 0x0200>;+ reg-names =
> > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > mainpll {+ vco0-psrc =;+
> > > >
> > > > vco1-denom =;+ vco1-
> > > > numer =;
> > >
> > > But these bits are board-specific , they shouldn't be in common DT.
> >
> > This common dtsi requires that the top level u-boot.dtsi include the
> > boardspecific header. The formatand #define names are in fact common.
>
> OK, I now see what you're doing here. Can you explain that in a bit moredetail
> in the commit message ?
> Basically socfpga_board.h is included socfpga_board.dts , and then
> thepreprocessor correctly expands the values from socfpga_board.h in
> thesocfpga_board.dts , so this works for multiple boards too ?
oh, and yes, it does work for multiple boards, i have already tested this.
--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Sun, 2019-10-06 at 20:05 +0200, Simon Goldschmidt wrote:
> Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen:
> > On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> > > On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > > > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > > > From: Dalon Westergreen > > > > > <mailto:dalon.westergr...@intel.com>
> > > > > > Generic handoff devicetree include uses a header generated bythe
> > > > > > qts-filter-a10.sh script in mach-socfpga. The scriptcreates the
> > > > > > header based on designspecific implementationsfor clock and pinmux
> > > > > > configurations.
> > > > >
> > > > > [...]
> > > > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > > > >
> > > > > [...]
> > > > > > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > > > comp
> > > > > > atible ="altr,socfpga-a10-clk-init";+ reg =
> > > > > > <0xffd04000 0x0200>;+ reg-names =
> > > > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > > > mainpll {+ vco0-psrc
> > > > > > =;+
> > > > > > vco1-denom =;+
> > > > > > vco1-numer =;
> > > > >
> > > > > But these bits are board-specific , they shouldn't be in common DT.
> > > >
> > > > This common dtsi requires that the top level u-boot.dtsi include the
> > > > boardspecific header. The formatand #define names are in fact common.
> > >
> > > OK, I now see what you're doing here. Can you explain that in a bit
> > > moredetail in the commit message ?
> > > Basically socfpga_board.h is included socfpga_board.dts , and then
> > > thepreprocessor correctly expands the values from socfpga_board.h in
> > > thesocfpga_board.dts , so this works for multiple boards too ?
> >
> > Exactly. Will add more detail in the commit message, and slim down the
> > included clocks inthe u-boot.dtsi
>
> I'm (still) working on a series to bring gen5 completely to devicetree, so
> that the 'qts' directories can be removed. I chose a different approach
> however, in that I generated everything into a '-handoff.dtsi' file (*). I'd
> be happy if we could find a common mechanism for all socfpga sub-archs. How
> does S10/Agilex handle this?
> (*): Gen5 has the downside that we're low on memory in SPL (regarding DM), and
> as we require large binary arrays there, I chose to encode the binary blob
> arrays in host byte order so that they could be used in-place instead of
> copying them from BE (dtb) to LE (stack/heap). Maybe that doesn't fit
> A10/S10/Agilex anyway?
S10/Agilex are entirely different. The onchip ram is loaded with any
configuration data bythe secure device manager. There is no need to modify the
dts for any io/pll/bridgeconfiguration.
A10 is better than cv/av in that is requires far less configuration data, and no
dataregarding the dram is needed. Also, there is no binary parsing required for
extractingthe required data, hence the simple qts-filter-a10.sh.
I think a -handoff.dtsi is a good approach, but why not do the same thing i do
here anduse a header file for the config data. that way the -handoff.dtsi can
be common and theheader only needs to be included in the toplevel -u-boot.dtsi?
--dalon
> Regards,Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > > > From: Dalon Westergreen Generic handoff
> > > > devicetree include uses a header generated bythe qts-filter-a10.sh
> > > > script in mach-socfpga. The scriptcreates the header based on
> > > > designspecific implementationsfor clock and pinmux configurations.
> > >
> > > [...]
> > > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-
> > > > boot.dtsib/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > >
> > > [...]
> > > > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > > > compatible ="altr,socfpga-a10-clk-init";+ reg =
> > > > <0xffd04000 0x0200>;+ reg-names =
> > > > "soc_clock_manager_OCP_SLV";u-boot,dm-pre-reloc;
> > > > mainpll {+ vco0-psrc =;+
> > > >
> > > > vco1-denom =;+ vco1-
> > > > numer =;
> > >
> > > But these bits are board-specific , they shouldn't be in common DT.
> >
> > This common dtsi requires that the top level u-boot.dtsi include the
> > boardspecific header. The formatand #define names are in fact common.
>
> OK, I now see what you're doing here. Can you explain that in a bit moredetail
> in the commit message ?
> Basically socfpga_board.h is included socfpga_board.dts , and then
> thepreprocessor correctly expands the values from socfpga_board.h in
> thesocfpga_board.dts , so this works for multiple boards too ?
Exactly. Will add more detail in the commit message, and slim down the included
clocks in
the u-boot.dtsi
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] ARM: socfpga: arria10: Add common u-boot devicetree include
On Sat, 2019-10-05 at 01:49 +0200, Marek Vasut wrote:
> On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > From: Dalon Westergreen
> > Add a common u-boot devicetree include file for the SocFPGAArria10 device.
>
> Isn't arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi doing basicallythe same
> thing, except more fine-grained ?
> > diff --git a/arch/arm/dts/socfpga_arria10-common-u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria10-common-u-boot.dtsinew file mode 100644index
> > 00..bd4f1271f3--- /dev/null+++ b/arch/arm/dts/socfpga_arria10-
> > common-u-boot.dtsi@@ -0,0 +1,206 @@+// SPDX-License-Identifier: GPL-2.0+/*+
> > * Copyright Altera Corporation (C) 2014. All rights reserved.+ */++/ {+
> > #address-cells = <1>;+ #size-cells = <1>;++chosen {+
> > tick
> > -timer = &timer2;+ u-boot,dm-pre-reloc;+ };++memory@0 {+
> > u-boot,dm-pre-reloc;+ };++soc {+ u-boot,dm-pre-
> > reloc;++clkmgr@ffd04000 {+ u-boot,dm-pre-
> > reloc;++clocks {+
> > u-
> > boot,dm-pre-reloc;++cb_intosc_hs_div
> > 2_clk {+u-boot,dm-pre-reloc;+
> > };++cb_i
> > ntosc_ls_clk {+ u-boot,dm-pre-
> > reloc;+ };++
> > f2s_free_clk {+ u-boot,dm-
> > pre-reloc;+ };++
> > osc1 {+ u-boot,dm-pre-
> > reloc;+ };++
> > main_pll@40 {+ u-boot,dm-
> > pre-reloc;++main_mpu_base_cl
> > k {+u-boot,dm-pre-
> > reloc;+ };++
> > main_noc_base_clk {+
> > u-boot,dm-pre-reloc;+
> > };++main_emaca_clk@68 {+
> > u-boot,dm-pre-reloc;+
> > };
>
> Do we really need all this in SPL for every board ?
We likely don't, but we arent that memory constrained in a10 and this simplifies
devicetree creation for custom boards. We do have customers using ethernet
in spl, for example. I can slim this down, but is it necessary?
--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] ARM: socfpga: arria10: Sync A10 SoCDK devicetrees
On Sat, 2019-10-05 at 01:47 +0200, Marek Vasut wrote: > On 10/5/19 12:30 AM, Dalon Westergreen wrote: > > From: Dalon Westergreen > > Sync devicetree from 5.2 kernel. > > Linux 5.3 was already released, can you update this ?Also, make sure to list > the exact commit ID in the commit message whenimporting stuff from Linux. Sure. will do. --dalon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] ARM: socfpga: arria10: Add qts-filter for arria10 socfpga
On Sat, 2019-10-05 at 01:47 +0200, Marek Vasut wrote: > On 10/5/19 12:30 AM, Dalon Westergreen wrote: > > From: Dalon Westergreen > > Add a script to process hps handoff data and generate a headerfor inclusion > > in u-boot specific devicetree addons. The headershould be included in the > > top level u-boot.dtsi. > > A10 should already be completely DT based and should directly use the > DTgenerated by quartus, why is this script needed? The bsp-editor is on the path to being deprecated, this completely removes the need for the generated devicetree > Also, if this is to be included in u-boot.dtsi , how does this work > withmultiple distinct boards ? Each board has its own top-level devicetree name. the intent is that the header is included in the top-level u-boot.dtsi, as in socfpga_arria10_socdk_sdmmc-u-boot.dtsi which is for a specific board implementation. Other implementations should have their own devicetree. In this patch set, the header is socfpga_arria10_socdk_sdmmc_handoff.h included in socfpga_arria10_socdk_sdmmc-u-boot.dtsi. --dalon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > From: Dalon Westergreen
> > Generic handoff devicetree include uses a header generated bythe qts-filter-
> > a10.sh script in mach-socfpga. The scriptcreates the header based on design
> > specific implementationsfor clock and pinmux configurations.
>
> [...]
> > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
>
> [...]
> > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+
> > compatible =
> > "altr,socfpga-a10-clk-init";+ reg = <0xffd04000 0x0200>;+
> > reg-names = "soc_clock_manager_OCP_SLV";u-boot,dm-pre-
> > reloc; mainpll {+ vco0-psrc =
> > ;+vco1-denom =
> > ;+ vco1-numer =
> > ;
>
> But these bits are board-specific , they shouldn't be in common DT.
This common dtsi requires that the top level u-boot.dtsi include the board
specific header. The format
and #define names are in fact common.
--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Tue, 2019-06-04 at 08:12 +0200, Simon Goldschmidt wrote: > On Tue, Jun 4, 2019 at 7:58 AM See, Chin Liang > wrote: > > On Tue, 2019-06-04 at 07:13 +0200, Simon Goldschmidt wrote: > > > On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen< > > > dalon.westergr...@linux.intel.com> wrote: > > > > From: Dalon Westergreen > > > > CONFIG_OF_EMBED was primarily enabled to support the stratix10spl hex > > > > file requirements. Since this option now produces awarning during > > > > build, and the spl hex can be created usingalternate methods, > > > > CONFIG_OF_EMBED is no longer needed. > > > > Signed-off-by: Dalon Westergreen > > > > ---Changes in v2: -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex--- > > > > configs/socfpga_stratix10_defconfig | 1 - > > > > include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 1 > > > > insertion(+), 2 deletions(-) > > > > diff --git > > > > a/configs/socfpga_stratix10_defconfigb/configs/socfpga_stratix10_defconf > > > > igindex fbab388b43..f27180385d 100644--- > > > > a/configs/socfpga_stratix10_defconfig+++ > > > > b/configs/socfpga_stratix10_defconfig@@ -26,7 +26,6 @@ > > > > CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y > > > > CONFIG_CMD_FS_GENERIC=y-CONFIG_OF_EMBED=y > > > > CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" > > > > CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=ydiff --git > > > > a/include/configs/socfpga_stratix10_socdk.hb/include/configs/socfpga_str > > > > atix10_socdk.hindex 39d757d737..66855ff0d8 100644--- > > > > a/include/configs/socfpga_stratix10_socdk.h+++ > > > > b/include/configs/socfpga_stratix10_socdk.h@@ -210,6 +210,6 @@ unsigned > > > > int cm_get_l4_sys_free_clk_hz(void); > > > > /* SPL SDMMC boot support */ #define > > > > CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1-#define > > > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"+#define > > > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" > > > Is that really necessary? I don't have the aarch64 compiler at hand,but > > > when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img"are the > > > same. Changing to "u-boot-dtb.img" here only complicatesthings for the > > > user, I think. > > > > I would agree with Dalon since we want to make sure we use same name > > assocfpga_common.h, which is for CV, A10 SoCs. This would help tostandardize > > our internal test infra. > > But that 'dtb' thing is an implementation detail. Who of the testers > careswhether the devicetree is embedded or not? "u-boot.img" exists > withOF_EMBED and without it, or doesn't it? > Regards,Simon Yes, it exists either way. I have no issue leaving it as u-boot.img but i do agree that it should bethe same across the socfpga family. As u-boot.img exists regardless of CONFIG_OF_EMBEDi would suggest just using u-boot.img, agreed? I will submit another patch to changesocfpga_common.h? --dalon > > ThanksChin Liang > > > Regards,Simon > > > > #endif /* __CONFIG_H */--2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Makefile: Add target to generate hex output for combined spl and dtb
On Tue, 2019-06-04 at 02:00 +0200, Marek Vasut wrote: > On 6/4/19 1:57 AM, Dalon Westergreen wrote: > > From: Dalon Westergreen < > > dalon.westergr...@intel.com > > > > > > > Some architectures, Stratix10, require a hex formatted spl that combines > > the spl image and dtb. This adds a target to create said hex file with > > and offset of SPL_TEXT_BASE. > > > > Signed-off-by: Dalon Westergreen < > > dalon.westergr...@intel.com > > > > > > > [...] > > > @@ -363,6 +365,11 @@ endif > > $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE > > $(call if_changed,mkimage) > > > > +OBJCOPYFLAGS_$(SPL_BIN).hex := -I binary -O ihex --change- > > address=$(CONFIG_SPL_TEXT_BASE) > > Do we really need to do it here ? The commit message is not clear why > this is needed ; I think if you link the SPl against the correct > address, this should not be needed. > This objcopy is from the binary including the dtb and not the elf. If you objcopy using the elf, and link to the correct address, you are correct. It is not true when just taking a binary and converting to a hex file. The binary combined with the dtb is what is needed. I can try be more descriptive in the commit message. perhaps.. --- Stratix10 requires a hex image of the spl plus spl devicetree offset to the Stratix10 onchip memory located at SPL_TEXT_BASE. This patch adds a target to generate a hex file from the u-boot-spl binary including the dtb offset at SPL_TEST_BASE. --- > > +$(obj)/$(SPL_BIN).hex: $(obj)/u-boot-spl.bin FORCE > > + $(call if_changed,objcopy) > > + > > quiet_cmd_mksunxiboot = MKSUNXI $@ > > cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \ > > --default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@ > > @@ -463,3 +470,4 @@ ifdef CONFIG_ARCH_K3 > > tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE > > $(call if_changed,mkfitimage) > > endif > > + > > Drop this hunk Will do, and i likely should have used (SPL_BIN).bin rather than u-boot-spl.bin. --dalon > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Makefile: Add target to generate hex output for combined spl and dtb
On Sat, 2019-03-30 at 15:18 -0600, Simon Glass wrote:
> Hi,
> On Fri, 22 Mar 2019 at 09:32, Dalon Westergreen<
> dalon.westergr...@linux.intel.com> wrote:
> > From: Dalon Westergreen
> > Some architectures, Stratix10, require a hex formatted spl that combinesthe
> > spl image and dtb. This adds a target to create said hex file withand
> > offset of SPL_TEXT_BASE.
> > Signed-off-by: Dalon Westergreen --- Makefile |
> > 9 + 1 file changed, 9 insertions(+)
>
> Reviewed-by: Simon Glass
> Please see below.
> > diff --git a/Makefile b/Makefileindex c52a33b403..ecba06ffce 100644---
> > a/Makefile+++ b/Makefile@@ -1074,6 +1074,11 @@ OBJCOPYFLAGS_u-boot-spl.hex =
> > $(OBJCOPYFLAGS_u-boot.hex) spl/u-boot-spl.hex: spl/u-boot-spl
> > FORCE$(call if_changed,objcopy)
> > +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex --change-
> > address=$(CONFIG_SPL_TEXT_BASE)
>
> Can we drop the -dtb part here? u-boot-spl includes the DTB anyway. Itis the
> -nodtb version which does not.
sure thing.
>
> > +
> > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl-dtb.bin FORCE
> > + $(call if_changed,objcopy)
> > +
> > binary_size_check: u-boot-nodtb.bin FORCE
> > @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
> > map_size=$(shell cat u-boot.map | \
> > @@ -1643,6 +1648,10 @@ u-boot.lds: $(LDSCRIPT) prepare FORCE
> >
> > spl/u-boot-spl.bin: spl/u-boot-spl
> > @:
> > +
> > +spl/u-boot-spl-dtb.bin: spl/u-boot-spl
> > + @:
> > +
> > spl/u-boot-spl: tools prepare \
> > $(if
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb)
> > \
> > $(if
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
> > --
> > 2.20.1
> >
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CONFIG_OF_EMBED
On Fri, 2019-03-22 at 10:11 +0800, Simon Glass wrote: > Hi, > > On Fri, 22 Mar 2019 at 05:37, Marek Vasut wrote: > > On 3/21/19 5:37 PM, Dalon L Westergreen wrote: > > > On Thu, 2019-03-21 at 16:48 +0100, Marek Vasut wrote: > > > > On 3/21/19 3:33 PM, Dalon L Westergreen wrote: > > > > > On Thu, 2019-03-21 at 03:30 +0100, Marek Vasut wrote: > > > > > > On 3/20/19 9:24 PM, Dalon L Westergreen wrote: > > > > > > > On Wed, 2019-03-20 at 19:37 +0100, Marek Vasut wrote: > > > > > > > > On 3/20/19 6:28 PM, Dalon L Westergreen wrote: > > > > > > > > > Hey Marek, > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > A while ago, when adding the hex output required for > > > > > > > > > stratix10, I > > > > > > > > > enabled > > > > > > > > > CONFIG_OF_EMBED so that the spl elf included the dtb. This > > > > > > > > > avoided > > > > > > > > > the > > > > > > > > > -- > > > > > > > > > change-address option when using objcopy to convert the u- > > > > > > > > > boot-spl- > > > > > > > > > dtb.bin > > > > > > > > > into > > > > > > > > > a hex file with the correct address as required by the quartus > > > > > > > > > tools. > > > > > > > > > > > > > > > > > > In any case, there is now a warning that CONFIG_OF_EMBED > > > > > > > > > should only > > > > > > > > > be > > > > > > > > > used > > > > > > > > > for > > > > > > > > > development and debug. I am wondering how best to resolve > > > > > > > > > this > > > > > > > > > issue, > > > > > > > > > should i > > > > > > > > > revert back to using objcopy with the u-boot-spl-dtb.bin, is > > > > > > > > > there a > > > > > > > > > way > > > > > > > > > to > > > > > > > > > have > > > > > > > > > CONFIG_OF_EMBED only apply to SPL? > > > > > > > > > > > > > > > > CONFIG_OF_SEPARATE is what you want. > > > > > > > > > > > > > > I dont think this is what i want exactly. I was thinking of this. > > > > > > > From 82c1d1bc6092ce40f33a04f2bc7713b0143e30a5 Mon Sep 17 00:00:00 > > > > > > > 2001 > > > > > > > From: Dalon Westergreen > > > > > > > Date: Wed, 20 Mar 2019 11:21:20 -0700 > > > > > > > Subject: [PATCH 1/2] Makefile: Add target to generate hex output > > > > > > > for > > > > > > > combined > > > > > > > spl and dtb > > > > > > > > > > > > > > Some architectures, Stratix10, require a hex formatted spl that > > > > > > > combines > > > > > > > the spl image and dtb. This adds a target to create said hex file > > > > > > > with > > > > > > > and offset of SPL_TEXT_BASE. > > I don't really follow this thread, but you should not use > CONFIG_OF_EMBED. If there is a problem with setting up the image with > CONFIG_OF_SEPARATE, we should discuss it. > > - Simon Simon, Did you see my patches following this email? They resolve the issues with S10 around CONFIG_OF_EMBED. --dalon > > > > > > > The CONFIG_OF_SEPARATE doesn't generate a combined image anymore ? > > > > > > Seems > > > > > > like it does at least on the renesas platforms (cfr e.g. > > > > > > stout_defconfig, where I use exactly that). > > > > > > > > > > It generates a combined binary, u-boot-spl-dtb.bin, as far as i know. > > > > > The elf is not combined, so using objcopy on the elf results in a hex > > > > > file without the dtb. Stratix 10 needs a combined hex file that > > > > > starts > > > > > at CONFIG_SPL_TEXT_BASE. This file is then combined by quartus with > > > > > the fpga image. The SDM loads the spl image into the cpu's onchip ram > > > > > and releases it from reset. > > > > > > > > > > So what i am trying to do is get a hex file generated that is > > > > > appriopriate > > > > > for the quartus tools. With CONFIG_OF_EMBED, this was easy, as you > > > > > just > > > > > run objcopy on the elf to create the hex output. With > > > > > CONFIG_OF_SEPARATE > > > > > you need the combined binary to do the same. hence, > > > > > > > > > > +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex --change- > > > > > > > address=$(CONFIG_SPL_TEXT_BASE) > > > > > > > + > > > > > > > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl-dtb.bin FORCE > > > > > > > + $(call if_changed,objcopy) > > > > Aha, right. CCing Simon, maybe he has some better idea. > > > > > > > > Otherwise, let's add the custom target. Maybe we can add it to > > > > arch/arm/mach-socfpga instead though. > > > > > > After a quick test to add the target to mach-socfpga instead of the root > > > Makefile, it seems i would still need to modify the root Makefile to call > > > the mach-socfpga makefile for the target in any case. If acceptable, i > > > think it cleaner to just add the target to the root Makefile. > > > > I think that's fine. The root Makefile is growing like dough. that needs > > to stop. > > > > -- > > Best regards, > > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: Build sfp image only for Gen5 and Arria10 devices
On Wed, 2019-03-20 at 18:09 +0100, Marek Vasut wrote: > On 3/20/19 4:40 PM, Dalon Westergreen wrote: > > From: Dalon Westergreen > > > > The sfp file is only valid for Gen5 (Cyclone5 & Arria5) and Arria10 > > devices. The file should only be built for these devices. > > > > Signed-off-by: Dalon Westergreen > > --- > > Kconfig | 3 ++- > > scripts/Makefile.spl | 6 +- > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Kconfig b/Kconfig > > index 512c7beb89..305b265ed7 100644 > > --- a/Kconfig > > +++ b/Kconfig > > @@ -226,7 +226,8 @@ config BUILD_ROM > > > > config BUILD_TARGET > > string "Build target special images" > > - default "u-boot-with-spl.sfp" if ARCH_SOCFPGA > > + default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_ARRIA10 > > + default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_GEN5 > > default "u-boot-spl.kwb" if ARCH_MVEBU && SPL > > default "u-boot-elf.srec" if RCAR_GEN3 > > default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > > index 9d5921606e..592c5dfe57 100644 > > --- a/scripts/Makefile.spl > > +++ b/scripts/Makefile.spl > > @@ -212,7 +212,11 @@ ifdef CONFIG_SAMSUNG > > ALL-y += $(obj)/$(BOARD)-spl.bin > > endif > > > > -ifdef CONFIG_ARCH_SOCFPGA > > +ifdef CONFIG_TARGET_SOCFPGA_ARRIA10 > > ifneq ($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),) > ALL-y ... > endif > > Then you don't need to duplicate the entry. sure thing. > > > +ALL-y += $(obj)/$(SPL_BIN).sfp > > +endif > > + > > +ifdef CONFIG_TARGET_SOCFPGA_GEN5 > > ALL-y += $(obj)/$(SPL_BIN).sfp > > endif > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v9 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote: > On 26. 02. 19 15:28, Chee, Tien Fong wrote: > > On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote: > > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > > > > > This patch adds description on properties about file name used for > > > > both > > > > peripheral bitstream and core bitstream. > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > > --- > > > > > > > > changes for v8 > > > > - Removed explanation about support for altr,bitstream-core > > > > > > > > changes for v7 > > > > - Provided example of setting FPGA FIT image for both early IO > > > > release > > > > and full release FPGA configuration. > > > > --- > > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 26 > > > > +- > > > > 1 file changed, 25 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga- > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga- > > > > mgr.txt > > > > index 2fd8e7a..da210bf 100644 > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > > > > @@ -7,8 +7,31 @@ Required properties: > > > > - The second index is for writing FPGA > > > > configuration data. > > > > - resets : Phandle and reset specifier for the device's reset. > > > > - clocks : Clocks used by the device. > > > > +- altr,bitstream : Fit image file name for both FPGA peripheral > > > > bitstream, > > > > + FPGA core bitstream and full bitstream. > > > > > > > By adding new required property you are automatically saying that you > > > want to break all current users. > > This is company's product specific property, that's why with prefix > > "altr". DT allows that ,right? > > no issue with altr prefix. Issue is that you add a required property and > breaking all current users. > It should be optional. This parameter is only for Arria10, which at this point is not fully supported in mainline uboot. So this doesnt affect any existing designs, no? --dalon > > M > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/8] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
On Wed, 2019-02-13 at 17:10 +0100, Marek Vasut wrote:
> On 2/13/19 3:18 PM, tien.fong.c...@intel.com wrote:
> > From: Tien Fong Chee
> >
> > Add default fitImage file bundling FPGA bitstreams for Arria10.
> >
> > Signed-off-by: Tien Fong Chee
> >
> > ---
> >
> > changes for v8
> > - Changed the FPGA node name to fpga-core and fpga-periph for both core and
> > periph bitstreams respectively.
> > ---
> > board/altera/arria10-socdk/fit_spl_fpga.its | 39
> > +
> > 1 file changed, 39 insertions(+)
> > create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
> >
> > diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
> > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > new file mode 100644
> > index 000..8ce175b
> > --- /dev/null
> > +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > + /*
> > + * Copyright (C) 2019 Intel Corporation
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > + description = "FIT image with FPGA bistream";
> > + #address-cells = <1>;
> > +
> > + images {
> > + fpga-core@1 {
> > + description = "FPGA core bitstream";
> > + data = /incbin/("../../../ghrd_10as066n2.core.rbf");
> > + type = "fpga";
> > + arch = "arm";
> > + compression = "none";
> > + load = <0x400>;
>
> Is the load address required ?
>
> > + };
> > +
> > + fpga-periph@2 {
> > + description = "FPGA peripheral bitstream";
> > + data = /incbin/("../../../ghrd_10as066n2.periph.rbf");
> > + type = "fpga";
> > + arch = "arm";
> > + compression = "none";
> > + };
> > + };
> > +
> > + configurations {
> > + default = "config-1";
> > + config-1 {
> > + description = "Boot with FPGA early IO release config";
> > + fpga = "fpga-periph@2", "fpga-core@1";
>
> Don't you need to load the core first ?
No, the periphery is first. This brings up the dram and i/o.
--dalon
>
> > + };
> > + };
> > +};
> >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Tue, 2019-02-12 at 11:17 +0100, Marek Vasut wrote:
> On 2/12/19 11:13 AM, Chee, Tien Fong wrote:
> > On Tue, 2019-02-12 at 10:43 +0100, Marek Vasut wrote:
> > > On 2/12/19 10:35 AM, Chee, Tien Fong wrote:
> > > [...]
> > >
> > > > > my preference for the fit image would be
> > > > >
> > > > > ...
> > > > > images {
> > > > > fpga@1 {
> > > > > description = "FPGA Periph";
> > > > > ...
> > > > > type = "fpga_periph";
> > > > > ...
> > > > > }
> > > > > fpga@2 {
> > > > > description = "FPGA Core";
> > > > > ...
> > > > > type = "fpga" or
> > > > > "fpga_core";
> > > > I'm good with "fpga".
> > > > > ...
> > > > > }
> > > > > };
> > > > > configurations {
> > > > > default = "config@1"
> > > > > config@1 {
> > > > > fpga = "fpga@1"; // periph only
> > > > > };
> > > > > config@2 {
> > > > > fpga = "fpga@1", "fpga@2";
> > > > > };
> > > > > };
> > > > >
> > > > > with the expectation that the order of fpga@1 and fpga@2 in confi
> > > > > g@2
> > > > > is not relevant. the code should find the fpga_periph type and
> > > > > program
> > > > > it first. just my comment, i dont like rellying on the order or
> > > > > name.
> > > > I can add support for above implementation although this adds more
> > > > complexity to the driver.
> > > You can have fpga node and e.g. fpga-name node in the configurations
> > > section to discern which phandle there is the core and which is the
> > > peripheral RBF. Would that work ?
> > >
> > So something like that?
> >
> > ...
> >
> > images {
> > fpga-periph@1 {
> > description = "FPGA Periph";
> > ...
> > type = "fpga_periph";
>
> Do we need a new type for the periph/core distinction ?
not really, using the node name is fine with me as is shown below.
when i suggested that my intent was to allow the name to be
independant of the node name still envisioning scenarios where
the fit image has multiple fpga images.
>
> > ...
> > }
> > fpga-core@2 {
> > description = "FPGA Core";
> > ...
> > type = "fpga";
> > ...
> > }
> > };
> > configurations {
> > default = "config@1"
> > config@1 {
> > fpga = "fpga-periph@1"; // periph only
> > };
> > config@2 {
> > fpga = "fpga-periph@1", "fpga-core@2";
> > };
> > };
> >
> > > > Marek, are you OK with this implementation?
> > > Looks OK to me. Dalon ?
> > >
> > > [...]
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM
On Sat, 2019-02-09 at 11:02 +0100, Marek Vasut wrote: > On 2/8/19 11:51 PM, Dalon L Westergreen wrote: > > On Fri, 2019-02-08 at 21:36 +0100, Simon Goldschmidt wrote: > > > > > > Am Fr., 8. Feb. 2019, 21:28 hat Dalon L Westergreen < > > > dalon.westergr...@linux.intel.com> geschrieben: > > > > On Thu, 2019-02-07 at 22:23 +0100, Simon Goldschmidt wrote: ... > > > > All you need is to have the h2f bridge enabled during the boot. We used to > > do > > this for you if spl found that the FPGA was already configured. On the FPGA > > side, a nios in the ddr controller runs the ddr calibration code. > > This is stratix10 you're talking about, isn't it ? I recall S10 has > nios2 hard block to start up the DRAM, but Gen5 and A10 do not have > that, do they ? > S10 and A10 both have a hard nios for ddr callibration, in cv / av for the soc emif, the A9 performs this functions, but for FPGA only DDR controllers there is a soft nios included in the FPGA ddr RTL that does the ddr callibration. The cv/av code that does this is based on the soft nios core code that performs this function for fpga ddr controllers. --dalon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Mon, 2019-02-11 at 12:01 +0100, Marek Vasut wrote:
> On 2/11/19 6:36 AM, Chee, Tien Fong wrote:
> > On Tue, 2019-02-05 at 09:46 +0100, Marek Vasut wrote:
> > > On 2/1/19 5:02 PM, Chee, Tien Fong wrote:
> > > > On Fri, 2019-02-01 at 09:25 +0100, Marek Vasut wrote:
> > > > > On 2/1/19 4:48 AM, Chee, Tien Fong wrote:
> > > > > > On Thu, 2019-01-31 at 15:54 +0100, Marek Vasut wrote:
> > > > > > > On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote:
> > > > > > > >
> > > > > > > > From: Tien Fong Chee
> > > > > > > >
> > > > > > > > This patch adds description on properties about file name
> > > > > > > > used
> > > > > > > > for
> > > > > > > > both
> > > > > > > > peripheral bitstream and core bitstream.
> > > > > > > >
> > > > > > > > Signed-off-by: Tien Fong Chee
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > changes for v7
> > > > > > > > - Provided example of setting FPGA FIT image for both early
> > > > > > > > IO
> > > > > > > > release
> > > > > > > > and full release FPGA configuration.
> > > > > > > > ---
> > > > > > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 34
> > > > > > > > +-
> > > > > > > > 1 file changed, 33 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
> > > > > > > > a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt
> > > > > > > > index 2fd8e7a..5f81a32 100644
> > > > > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt
> > > > > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt
> > > > > > > > @@ -7,8 +7,39 @@ Required properties:
> > > > > > > > - The second index is for writing FPGA
> > > > > > > > configuration data.
> > > > > > > > - resets : Phandle and reset specifier for the
> > > > > > > > device's
> > > > > > > > reset.
> > > > > > > > - clocks : Clocks used by the device.
> > > > > > > > +- altr,bitstream : File name for FPGA peripheral bitstream
> > > > > > > > which
> > > > > > > > is used
> > > > > > > > + to initialize FPGA IOs, PLL, IO48 and
> > > > > > > > DDR.
> > > > > > > > This
> > > > > > > > bitstream is
> > > > > > > > + required to get DDR up running.
> > > > > > > > + or
> > > > > > > > + File name for full bitstream, consist
> > > > > > > > of
> > > > > > > > peripheral bitstream
> > > > > > > > + and core bitstream.
> > > > > > > > +- altr,bitstream-core(optional) : File name for core
> > > > > > > > bitstream
> > > > > > > > which contains
> > > > > > > Is the name of the property 'altr,bitstream-core(optional)' ?
> > > > > > > I
> > > > > > > think
> > > > > > > the "optional" part should be in the description.
> > > > > > Yes, you are right.
> > > > > > >
> > > > > > > >
> > > > > > > > + FPGA design which is
> > > > > > > > used to
> > > > > > > > program FPGA CRAM
> > > > > > > > + and ERAM.
> > > > > > > >
> > > > > > > > -Example:
> > > > > > > > +Example: Bundles both peripheral bitstream and core
> > > > > > > > bitstream
> > > > > > > > into
> > > > > > > > FIT image
> > > > > > > > +called fit_spl_fpga.itb. This FIT image can be
> > > > > > > > created
> > > > > > > > through running
> > > > > > > > +this command: tools/mkimage
> > > > > > > > + -E -p 400
> > > > > > > > + -f board/altera/arria10-
> > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > + fit_spl_fpga.itb
> > > > > > > > +
> > > > > > > > +For details of describing structure and contents
> > > > > > > > of
> > > > > > > > the
> > > > > > > > FIT image,
> > > > > > > > +please refer board/altera/arria10-
> > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > +
> > > > > > > > +- Examples for booting with early IO release, and enter
> > > > > > > > early
> > > > > > > > user
> > > > > > > > mode:
> > > > > > > > +
> > > > > > > > + fpga_mgr: fpga-mgr@ffd03000 {
> > > > > > > > + compatible = "altr,socfpga-a10-fpga-mgr";
> > > > > > > > + reg = <0xffd03000 0x100
> > > > > > > > + 0xffcfe400 0x20>;
> > > > > > > > + clocks = <&l4_mp_clk>;
> > > > > > > > + resets = <&rst FPGAMGR_RESET>;
> > > > > > > > + altr,bitstream = "fit_spl_fpga.itb";
> > > > > > > > + altr,bitstream-core = "fit_spl_fpga.itb";
> > > > > > > It's the same file, why does it use two properties ?
> > > > > > 1. Allows user to run optional for program core. When "" is set
> > > > > > to
> > > > > > altr,bitstream-core, then SPL would skip programming FPGA with
> > > > > > core, so
> > > > > > u
Re: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM
On Fri, 2019-02-08 at 21:36 +0100, Simon Goldschmidt wrote: > > > Am Fr., 8. Feb. 2019, 21:28 hat Dalon L Westergreen < > dalon.westergr...@linux.intel.com> geschrieben: > > On Thu, 2019-02-07 at 22:23 +0100, Simon Goldschmidt wrote: > > > To clean up reset handling for socfpga gen5, let's move the code snippet > > > taking the DDR controller out of reset from SPL to the DDR driver. > > > > > > While at it, port the ddr driver to UCLASS_RAM and use dts. > > > > > > Signed-off-by: Simon Goldschmidt > > > --- > > > > > > This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) > > would > > > look like. It's RFC both because Dinh did not seem too fond of changing > > the > > > register address of the SDR in devicetree to include what the undocumented > > > registers 'sequencer.c' uses as well as because of my observed code > > growth. > > > > > > Basically, I want to move this to UCLASS_RAM and I want to read the reset > > > property for SDR from devicetree. What remains RFC is: do we want/need to > > > read the base address from devicetree, or can we live with it being hard- > > > coded (and maybe sanity-checked during probe)? > > > > > > > My 2 cents, i love the idea of moving all of the socfgpa sdram code to DM. > > Looking at the code, i would suggest that we should handle the case where > > there is no HPS sdram controller, and instead an FPGA based controller is > > used. Although not common, it is a use case i have seen repeatedly. > > While I haven't used it like that (I did use an FPGA RAM controller, but that > was with a NIOS and not Linux, not HPS), I guess it should work with my > changed. Just disable the 'sdr' node in the devicetree. You'll need a driver > for the FPGA based RAM controller though. > > Or, in the setup you mentioned, would the existing driver be the same? I.e. > just use a different base address? Or is it a different IP? All you need is to have the h2f bridge enabled during the boot. We used to do this for you if spl found that the FPGA was already configured. On the FPGA side, a nios in the ddr controller runs the ddr calibration code. -dalon > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Fri, 2019-02-01 at 12:02 -0800, Dalon L Westergreen wrote: > On Sat, 2019-02-02 at 00:02 +0800, Chee, Tien Fong wrote: > > On Fri, 2019-02-01 at 09:25 +0100, Marek Vasut wrote: > > > On 2/1/19 4:48 AM, Chee, Tien Fong wrote: > > > > On Thu, 2019-01-31 at 15:54 +0100, Marek Vasut wrote: > > > > > On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote: > > > > > > From: Tien Fong Chee > > > > > > > > > > > > This patch adds description on properties about file name used > > > > > > for > > > > > > both > > > > > > peripheral bitstream and core bitstream. > > > > > > > > > > > > Signed-off-by: Tien Fong Chee > > > > > > > > > > > > --- > > > > > > > > > > > > changes for v7 > > > > > > - Provided example of setting FPGA FIT image for both early IO > > > > > > release > > > > > > and full release FPGA configuration. > > > > > > --- > > > > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 34 > > > > > > +- > > > > > > 1 file changed, 33 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10- > > > > > > fpga- > > > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10- > > > > > > fpga- > > > > > > mgr.txt > > > > > > index 2fd8e7a..5f81a32 100644 > > > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga- > > > > > > mgr.txt > > > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga- > > > > > > mgr.txt > > > > > > @@ -7,8 +7,39 @@ Required properties: > > > > > > - The second index is for writing FPGA > > > > > > configuration data. > > > > > > - resets : Phandle and reset specifier for the device's > > > > > > reset. > > > > > > - clocks : Clocks used by the device. > > > > > > +- altr,bitstream : File name for FPGA peripheral bitstream > > > > > > which > > > > > > is used > > > > > > + to initialize FPGA IOs, PLL, IO48 and DDR. > > > > > > This > > > > > > bitstream is > > > > > > + required to get DDR up running. > > > > > > + or > > > > > > + File name for full bitstream, consist of > > > > > > peripheral bitstream > > > > > > + and core bitstream. > > > > > > +- altr,bitstream-core(optional) : File name for core bitstream > > > > > > which contains > > > > > Is the name of the property 'altr,bitstream-core(optional)' ? I > > > > > think > > > > > the "optional" part should be in the description. > > > > Yes, you are right. > > > > > > + FPGA design which is used to > > > > > > program FPGA CRAM > > > > > > + and ERAM. > > > > > > > > > > > > -Example: > > > > > > +Example: Bundles both peripheral bitstream and core bitstream > > > > > > into > > > > > > FIT image > > > > > > +called fit_spl_fpga.itb. This FIT image can be > > > > > > created > > > > > > through running > > > > > > +this command: tools/mkimage > > > > > > + -E -p 400 > > > > > > + -f board/altera/arria10- > > > > > > socdk/fit_spl_fpga.its > > > > > > + fit_spl_fpga.itb > > > > > > + > > > > > > +For details of describing structure and contents of > > > > > > the > > > > > > FIT image, > > > > > > +please refer board/altera/arria10- > > > > > > socdk/fit_spl_fpga.its > > > > > > + > > > > > > +- Examples for booting with early IO release, and enter early > > > > > > user > > > > > > mode: > > > > > > + > > > > >
Re: [U-Boot] [PATCH v7 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
On Thu, 2019-01-31 at 22:51 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Add FPGA driver to support program FPGA with FPGA bitstream loading from
> filesystem. The driver are designed based on generic firmware loader
> framework. The driver can handle FPGA program operation from loading FPGA
> bitstream in flash to memory and then to program FPGA.
>
> Signed-off-by: Tien Fong Chee
>
> ---
>
> changes for v7
> - Restructure the FPGA driver to support both peripheral bitstream and core
> bitstream bundled into FIT image.
> - Support loadable property for core bitstream. User can set loadable
> in DDR for better performance. This loading would be done in one large
> chunk instead of chunk by chunk loading with small memory buffer.
> ---
> arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 18 +
> .../include/mach/fpga_manager_arria10.h| 39 +-
> drivers/fpga/socfpga_arria10.c | 417
> -
> 3 files changed, 457 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> index 998d811..dc55618 100644
> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> @@ -18,6 +18,24 @@
> /dts-v1/;
> #include "socfpga_arria10_socdk.dtsi"
>
> +/ {
> + chosen {
> + firmware-loader = &fs_loader0;
> + };
> +
> + fs_loader0: fs-loader@0 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + phandlepart = <&mmc 1>;
> + };
> +};
> +
> +&fpga_mgr {
> + u-boot,dm-pre-reloc;
> + altr,bitstream = "fit_spl_fpga.itb";
> + altr,bitstream-core = "fit_spl_fpga.itb";
> +};
> +
> &mmc {
> u-boot,dm-pre-reloc;
> status = "okay";
> diff --git a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> index 09d13f6..683c84c 100644
> --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> @@ -1,9 +1,13 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> /*
> - * Copyright (C) 2017 Intel Corporation
> + * Copyright (C) 2017-2019 Intel Corporation
> * All rights reserved.
> */
>
>
[...] }
> +
> + if (!is_fpgamgr_early_user_mode() || is_fpgamgr_user_mode()) {
> + fpga_node_name = "fpga-1";
> + printf("FPGA: Start to program peripheral bitstream ...\n");
> + } else if (!is_fpgamgr_user_mode()) {
> + fpga_node_name = "fpga-2";
> + printf("FPGA: Start to program core bitstream ...\n");
> + }
Why are you relying on the node name to define the core / periph RBF? Would
it not be better to define this in a property? how would one have multiple
core and periph rbfs in a single fit image?
--dalon
> +
> + node_offset = fit_image_get_node(buffer_p, fpga_node_name);
> + if (node_offset < 0) {
> + debug("FPGA: Could not find node '%s' in FIT\n",
> + fpga_node_name);
> + return -ENOENT;
> + }
> +
> + const char *uname = fit_get_name(buffer_p, node_offset, NULL);
> +
> + if (uname)
> + debug("FPGA: %s\n", uname);
> +
> + ret = fit_image_get_data_position(buffer_p, node_offset, &rbf_offset);
> + if (ret < 0) {
> + debug("FPGA: Could not find data position (err=%d)\n", ret);
> + return -ENOENT;
> + }
> +
> + ret = fit_image_get_data_size(buffer_p, node_offset, &rbf_size);
> + if (ret < 0) {
> + debug("FPGA: Could not find data size (err=%d)\n", ret);
> + return -ENOENT;
> + }
> +
> + ret = fit_image_get_load(buffer_p, node_offset, (ulong *)loadable);
> + if (ret < 0) {
> + debug("FPGA: Could not find loadable (err=%d)\n", ret);
> + debug("FPGA: Using default buffer and size\n");
> + } else {
> + buffer_p = (u32 *)*loadable;
> + buffer_size = rbf_size;
> + debug("FPGA: Found loadable address = 0x%x\n", *loadable);
> + }
> +
> + debug("FPGA: External data: offset = 0x%x, size = 0x%x\n",
> + rbf_offset, rbf_size);
> +
> + fpga_loadfs->remaining = rbf_size;
> +
> + /*
> + * Determine buffer size vs bitstream size, and calculating number of
> + * chunk by chunk transfer is required due to smaller buffer size
> + * compare to bitstream
> + */
> + if (rbf_size <= buffer_size) {
> + /* Loading whole bitstream into buffer */
> + buffer_size = rbf_size;
> + fpga_loadfs->remaining = 0;
> + } else {
> + fpga_loadfs->remaining -= buffer_size;
> + }
> +
> + fpga_loadfs->offset = rbf_offset;
> + /* Loading bitstream into buffer */
> + ret = request_firmware_into_buf(dev,
> + fpga_lo
Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
On Sat, 2019-02-02 at 00:02 +0800, Chee, Tien Fong wrote:
> On Fri, 2019-02-01 at 09:25 +0100, Marek Vasut wrote:
> > On 2/1/19 4:48 AM, Chee, Tien Fong wrote:
> > > On Thu, 2019-01-31 at 15:54 +0100, Marek Vasut wrote:
> > > > On 1/31/19 3:51 PM, tien.fong.c...@intel.com wrote:
> > > > >
> > > > > From: Tien Fong Chee
> > > > >
> > > > > This patch adds description on properties about file name used
> > > > > for
> > > > > both
> > > > > peripheral bitstream and core bitstream.
> > > > >
> > > > > Signed-off-by: Tien Fong Chee
> > > > >
> > > > > ---
> > > > >
> > > > > changes for v7
> > > > > - Provided example of setting FPGA FIT image for both early IO
> > > > > release
> > > > > and full release FPGA configuration.
> > > > > ---
> > > > > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 34
> > > > > +-
> > > > > 1 file changed, 33 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > fpga-
> > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > fpga-
> > > > > mgr.txt
> > > > > index 2fd8e7a..5f81a32 100644
> > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > > mgr.txt
> > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > > mgr.txt
> > > > > @@ -7,8 +7,39 @@ Required properties:
> > > > > - The second index is for writing FPGA
> > > > > configuration data.
> > > > > - resets : Phandle and reset specifier for the device's
> > > > > reset.
> > > > > - clocks : Clocks used by the device.
> > > > > +- altr,bitstream : File name for FPGA peripheral bitstream
> > > > > which
> > > > > is used
> > > > > +to initialize FPGA IOs, PLL, IO48 and DDR.
> > > > > This
> > > > > bitstream is
> > > > > +required to get DDR up running.
> > > > > +or
> > > > > +File name for full bitstream, consist of
> > > > > peripheral bitstream
> > > > > +and core bitstream.
> > > > > +- altr,bitstream-core(optional) : File name for core bitstream
> > > > > which contains
> > > > Is the name of the property 'altr,bitstream-core(optional)' ? I
> > > > think
> > > > the "optional" part should be in the description.
> > > Yes, you are right.
> > > >
> > > > >
> > > > > + FPGA design which is used to
> > > > > program FPGA CRAM
> > > > > + and ERAM.
> > > > >
> > > > > -Example:
> > > > > +Example: Bundles both peripheral bitstream and core bitstream
> > > > > into
> > > > > FIT image
> > > > > + called fit_spl_fpga.itb. This FIT image can be
> > > > > created
> > > > > through running
> > > > > + this command: tools/mkimage
> > > > > +-E -p 400
> > > > > +-f board/altera/arria10-
> > > > > socdk/fit_spl_fpga.its
> > > > > +fit_spl_fpga.itb
> > > > > +
> > > > > + For details of describing structure and contents of
> > > > > the
> > > > > FIT image,
> > > > > + please refer board/altera/arria10-
> > > > > socdk/fit_spl_fpga.its
> > > > > +
> > > > > +- Examples for booting with early IO release, and enter early
> > > > > user
> > > > > mode:
> > > > > +
> > > > > + fpga_mgr: fpga-mgr@ffd03000 {
> > > > > + compatible = "altr,socfpga-a10-fpga-mgr";
> > > > > + reg = <0xffd03000 0x100
> > > > > +0xffcfe400 0x20>;
> > > > > + clocks = <&l4_mp_clk>;
> > > > > + resets = <&rst FPGAMGR_RESET>;
> > > > > + altr,bitstream = "fit_spl_fpga.itb";
> > > > > + altr,bitstream-core = "fit_spl_fpga.itb";
> > > > It's the same file, why does it use two properties ?
> > > 1. Allows user to run optional for program core. When "" is set to
> > > altr,bitstream-core, then SPL would skip programming FPGA with
> > > core, so
> > > user can program it later on U-Boot or Linux.
> > You can just pass in a fitImage with only the periph image in it in
> > such
> > a case.
> What if user want to program the core on U-Boot? User need to create
> two FIT images, one FIT with periph image, and another FIT with core
> image only.
>
> Current implementation supports one FIT image for above configuration.
> > > 2. Allows core in different FIT file.
> > Is this really useful ?
> Yes, for the use case which support different core image for different
> revision of board but using same periph image.
I would have to disagree here. This is not a supported flow, the periph image
and core image must come from the same compilation of quartus for arria10 to
guarantee functionality. That is unless something has changed that I am not
aware of? I believe this holds true in S10, the difference being that in s10
you can reconfigure the periph rbf without affecting the processor IO.
Why are there separate fit images for uboot and the fpga? would it not
make sen
Re: [U-Boot] [PATCH] arm: socfpga: crc-protect SPL on warm boot
On Tue, 2018-11-20 at 21:54 +0100, Simon Goldschmidt wrote:
> On 20.11.2018 20:33, Marek Vasut wrote:
> > On 11/20/2018 08:22 PM, Simon Goldschmidt wrote:
> > > From: Simon Goldschmidt
> > >
> > > On socfpga gen5, a warm reboot from Linux currently triggers a warm
> > > reset via reset manager ctrl register.
is there any reason to not just promote these to cold resets?
> > >
> > > This currently leads to the boot rom just jumping to onchip ram
> > > executing the SPL that is supposed to still be there. This is
> > > because we tell the boot rom to do so by writing a magin value
> > > the warmramgrp_enable register in arch_early_init_r().
> > >
> > > However, this can lead to lockups on reboot if this register still
> > > contains its magic value but the SPL is not intact any more (e.g.
> > > partly overwritten onchip ram).
> > >
> > > To fis this, store a crc calculated over SPL in sysmgr registers to
> > > let the boot rom check it on next warm boot. If the crc is still
> > > correct, SPL can be executd from onchip ram. If the crc fails, SPL
> > > is loaded from original boot source.
> > >
> > > The crc that is written to the warmramgrp_crc register is the crc
> > > found in the SPL sfp image but with one addiional u32 added. For
> > > this, we need to add a function to calculate the updated crc. This
> > > is done as a bitwise calculation to keep the code increase small.
> > >
> > > This whole patch added 96 bytes to .text for SPL for
> > > socfpga_socrates_defconfig.
> > >
> > > Signed-off-by: Simon Goldschmidt
> > > ---
> > >
> > > arch/arm/mach-socfpga/misc_gen5.c | 9
> > > arch/arm/mach-socfpga/spl_gen5.c | 73 +++
> > > 2 files changed, 73 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-socfpga/misc_gen5.c b/arch/arm/mach-
> > > socfpga/misc_gen5.c
> > > index 5fa40937c4..492a3082de 100644
> > > --- a/arch/arm/mach-socfpga/misc_gen5.c
> > > +++ b/arch/arm/mach-socfpga/misc_gen5.c
> > > @@ -204,15 +204,6 @@ int arch_early_init_r(void)
> > > {
> > > int i;
> > >
> > > - /*
> > > - * Write magic value into magic register to unlock support for
> > > - * issuing warm reset. The ancient kernel code expects this
> > > - * value to be written into the register by the bootloader, so
> > > - * to support that old code, we write it here instead of in the
> > > - * reset_cpu() function just before resetting the CPU.
> > > - */
> > > - writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
> > > -
> > > for (i = 0; i < 8; i++) /* Cache initial SW setting regs
> > > */
> > > iswgrp_handoff[i] = readl(&sysmgr_regs-
> > > >iswgrp_handoff[i]);
> > >
> > > diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-
> > > socfpga/spl_gen5.c
> > > index ccdc661d05..3416e19f79 100644
> > > --- a/arch/arm/mach-socfpga/spl_gen5.c
> > > +++ b/arch/arm/mach-socfpga/spl_gen5.c
> > > @@ -63,6 +63,76 @@ u32 spl_boot_mode(const u32 boot_device)
> > > }
> > > #endif
> > >
> > > +/* This function calculates the CRC32 used by the Cyclone 5 SoC Boot Rom
> > > */
> > > +static u32 socfpga_boot_crc(u32 crc, const unsigned char *ptr, u32
> > > length)
> > > +{
> > > + uint i;
> > > + u8 bit;
> > > + unsigned char data;
> > > + const u32 poly = 0x02608edb;
> > > +
> > > + for (; length > 0; length--, ptr++) {
> > > + data = *ptr;
> > > + for (i = 0; i < 8; i++) {
> > > + if (data & 0x80)
> > > + bit = 1;
> > > + else
> > > + bit = 0;
> > > +
> > > + data = data << 1;
> > > + if (crc & 0x8000)
> > > + bit = 1 - bit;
> > > +
> > > + if (bit) {
> > > + crc ^= poly;
> > > + crc = crc << 1;
> > > + crc |= 1;
> > > + } else {
> > > + crc = crc << 1;
> > > + }
> > > + }
> > > + }
> > > + return crc;
> > > +}
> > > +
> > > +/*
> > > + * Write magic value into magic register to unlock support for the boot
> > > rom to
> > > + * execute spl from sram on warm reset. This may be required at least on
> > > some
> > > + * boards that start from qspi where the flash chip might be in a state
> > > that
> > > + * cannot be handled by the boot rom (e.g. 4 byte mode).
> > > + *
> > > + * To prevent just jumping to corrupted memory, a crc of the spl is
> > > calculated.
> > > + * This crc is loaded from the running image, but has to be extended by
> > > the
> > > + * modified contents of the "datastart" register (i.e. 0x).
> > > + */
> > > +static void spl_init_reboot_config(void)
> > > +{
> > > + u32 spl_crc, spl_length;
> > > + const u32 spl_start = (u32)__image_copy_start;
> > > + const u32 spl_start_16 = spl_start & 0x;
> > > + u32 spl_length_u32;
> > > +
> > > + /* load image length from sfp he
Re: [U-Boot] socfpga cyclone5 dts
On Mon, 2018-10-22 at 22:48 +0200, Simon Goldschmidt wrote: > On 18.10.2018 23:04, Marek Vasut wrote: > > On 10/18/2018 10:20 PM, Simon Goldschmidt wrote: > > > Marek Vasut mailto:marek.va...@gmail.com>> > schrieb am Do., 18. Okt. 2018, 22:15: > > On 10/18/2018 09:28 PM, Simon Goldschmidt wrote: > > Hi Marek, > > Hi, > > > I was playing with updating the dts files for cyclone5 (and > arria5) from > > current kernel sources, but I found that the kernel as 4 boards that > > U-Boot doesn't have and U-Boot has 6 boards that the kernel > doesn't have. > > Thanks for doing this, really appreciated (even though it probably > doesn't look that way most of the time). > > And yikes, which boards are where , can you list the problematic ones? > > > How should I proceed here? Should I copy new boards from the kernel? > > Should I keep U-Boot-only boards and try to adjust them to changes (if > > any)? > > I'd say sync as much as possible with kernel and the rest, update. I > don't think there are any real board specific things which would prevent > the update in those DTs missing in the kernel. > > > Ok, I'll just try and prepare a patch that ports the existing boards and > mentions the boards not ported from current kernel sources. I don't want > to remove boards from U-Boot, so we'll just have to test those not in Linux. > > Sounds good! > > > After a short test run, I decided to first ask for the boards before > preparing a patch: > > Boards in U-Boot but not in Linux (not updated): > - socfpga_cyclone5_dbm_soc1.dts > - socfpga_cyclone5_de0_nano_soc.dts (is this > 'socfpga_cyclone5_de0_sockit.dts'?) Yes, these are the same board. > - socfpga_cyclone5_de1_soc.dts- socfpga_cyclone5_de10_nano.dts- > socfpga_cyclone5_is1.dts- socfpga_cyclone5_sr1500.dts > Boards in Linux but not in U-Boot:- socfpga_cyclone5_de0_sockit.dts (is this > 'socfpga_cyclone5_de0_nano_soc.dts'?)- socfpga_cyclone5_sodia.dts > Also, Dinh has enabled the watchdog nearly 4 years ago in > socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable > it in the U-Boot specific dts files? > Thanks,Simon___U-Boot mailing > listu-b...@lists.denx.dehttps://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Socfpga ocram warm boot
On Thu, 2018-09-20 at 09:25 -0400, Thomas Epperson wrote: > I've done some troubleshooting on warm resets and determined that the ocramis > not being set correctly for warm reset to run properly (it hangs theprocessor > on my de0-nano-soc board).I think it should be not enabled or fully setup so > it properly works. That is likely an issue specific to the silicon on that board, and is not a general issue in production devices. I do not believe this is an issue on newer production silicon. --dalon > ___U-Boot mailing listU- > b...@lists.denx.dehttps://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm; socfpga: stratix10: Add CONFIG_OF_EMBED
On Wed, 2018-09-12 at 02:03 +0200, Marek Vasut wrote: > On 09/12/2018 01:55 AM, Dalon L Westergreen wrote: > On Tue, 2018-09-11 at 23:55 +0200, Marek Vasut wrote: > On 09/10/2018 07:28 PM, Dalon Westergreen wrote:The dtb should be embedded in > the u-boot-spl image so thatthe CONFIG_SPL_TARGET of spl/u-boot-spl.hex > includes it. > This also affects the main u-boot image, so > adjustCONFIG_SPL_FS_LOAD_PAYLOAD_NAME to u-boot,img which nowalso includes the > dtb. > Signed-off-by: Dalon Westergreen dwest...@gmail.com>>--- configs/socfpga_stratix10_defconfig | 1 + > include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 2 > insertions(+), 1 deletion(-) > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfigindex c27985ad43..b6d804f38e 100644--- > a/configs/socfpga_stratix10_defconfig+++ > b/configs/socfpga_stratix10_defconfig@@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y+CONFIG_OF_EMBED=y > Did make savedefconfig put this here ? > No, i put it there myself > You should always run make savedefconfig to update the defconfig insteadof ad- > hoc hacking the value at random place. i'll fix it and send a new patch. You already accepted patch 1 & 2 from the series, so i will just sendthe one. > I am fine with this patch, but if Simon has any objections, let's hear them. > great! > > diff --git a/include/configs/socfpga_stratix10_socdk.h > b/include/configs/socfpga_stratix10_socdk.hindex 91315a0031..e190b3d988 > 100644--- a/include/configs/socfpga_stratix10_socdk.h+++ > b/include/configs/socfpga_stratix10_socdk.h@@ -216,6 +216,6 @@ unsigned int > cm_get_l4_sys_free_clk_hz(void); /* SPL SDMMC boot support */ #define > CONFIG_SYS_MMCSD_FS_BOOT_PARTITION1-#define > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"+#define > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" #endif/* > __CONFIG_H */ > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm; socfpga: stratix10: Add CONFIG_OF_EMBED
On Tue, 2018-09-11 at 23:55 +0200, Marek Vasut wrote: > On 09/10/2018 07:28 PM, Dalon Westergreen wrote: > The dtb should be embedded in the u-boot-spl image so thatthe > CONFIG_SPL_TARGET of spl/u-boot-spl.hex includes it. > This also affects the main u-boot image, so > adjustCONFIG_SPL_FS_LOAD_PAYLOAD_NAME to u-boot,img which nowalso includes the > dtb. > Signed-off-by: Dalon Westergreen --- > configs/socfpga_stratix10_defconfig | 1 + > include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 2 > insertions(+), 1 deletion(-) > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfigindex c27985ad43..b6d804f38e 100644--- > a/configs/socfpga_stratix10_defconfig+++ > b/configs/socfpga_stratix10_defconfig@@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y+CONFIG_OF_EMBED=y > Did make savedefconfig put this here ? No, i put it there myself > I am fine with this patch, but if Simon has any objections, let's hear them. great! > diff --git a/include/configs/socfpga_stratix10_socdk.h > b/include/configs/socfpga_stratix10_socdk.hindex 91315a0031..e190b3d988 > 100644--- a/include/configs/socfpga_stratix10_socdk.h+++ > b/include/configs/socfpga_stratix10_socdk.h@@ -216,6 +216,6 @@ unsigned int > cm_get_l4_sys_free_clk_hz(void); /* SPL SDMMC boot support */ #define > CONFIG_SYS_MMCSD_FS_BOOT_PARTITION1-#define > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"+#define > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" #endif/* > __CONFIG_H */ > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] socfpga: stratix10: fix sdram_calculate_size
On Tue, 2018-09-11 at 15:52 +0200, Marek Vasut wrote:
> On 09/11/2018 03:28 PM, Dalon L Westergreen wrote:
> On Tue, 2018-09-11 at 11:31 +0200, Marek Vasut wrote:
> On 09/10/2018 10:41 PM, Dalon Westergreen wrote:Incorrect type of size
> variable results in 0 beingreturned for sdram sizes greater than or equal
> to4GB.
> Signed-off-by: Dalon Westergreen dwest...@gmail.com>>--- drivers/ddr/altera/sdram_s10.c | 2 +- 1 file changed,
> 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/ddr/altera/sdram_s10.c
> b/drivers/ddr/altera/sdram_s10.cindex 48f4f47b14..dad0147b64 100644---
> a/drivers/ddr/altera/sdram_s10.c+++ b/drivers/ddr/altera/sdram_s10.c@@ -375,7
> +375,7 @@ unsigned long sdram_calculate_size(void) { u32 dramaddrw =
> hmc_readl(DRAMADDRW); - u32 size = 1 <<
> (DRAMADDRW_CFG_CS_ADDR_WIDTH(dramaddrw) ++unsigned long size = 1 <<
> (DRAMADDRW_CFG_CS_ADDR_WIDTH(dramaddrw) + DRAMADDRW_CFG_B
> ANK_GRP_ADDR_WIDTH(dramaddrw) +DRAMADDRW_CFG_BANK_ADDR
> _WIDTH(dramaddrw) +DRAMADDRW_CFG_ROW_ADDR_WIDTH(dramaddrw)
> +
>
> Change the function to report size in MiB, prescale it here and youwon't have
> problems for a while . How does that sound ?
> Prefer not to as this will be used for comparisons later which wouldmean we
> would need to scale #defines from linux/sizes.h.
> What comparisons ? I only see it assigned to gd->sdram_size , in whichcase it
> might rather make sense to adjust the type of the function tounsigned long
> long (so it returns u64).
Yes, i think the function should be phys_size_t type, i will adjust it. There
are no comparisons as ofyet, but there likely will be a need to do so to deal
with some corner cases.
--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] socfpga: stratix10: fix sdram_calculate_size
On Tue, 2018-09-11 at 11:31 +0200, Marek Vasut wrote:
> On 09/10/2018 10:41 PM, Dalon Westergreen wrote:
> Incorrect type of size variable results in 0 beingreturned for sdram sizes
> greater than or equal to4GB.
> Signed-off-by: Dalon Westergreen ---
> drivers/ddr/altera/sdram_s10.c | 2 +- 1 file changed, 1 insertion(+), 1
> deletion(-)
> diff --git a/drivers/ddr/altera/sdram_s10.c
> b/drivers/ddr/altera/sdram_s10.cindex 48f4f47b14..dad0147b64 100644---
> a/drivers/ddr/altera/sdram_s10.c+++ b/drivers/ddr/altera/sdram_s10.c@@ -375,7
> +375,7 @@ unsigned long sdram_calculate_size(void) { u32 dramaddrw =
> hmc_readl(DRAMADDRW); - u32 size = 1 <<
> (DRAMADDRW_CFG_CS_ADDR_WIDTH(dramaddrw) ++unsigned long size = 1 <<
> (DRAMADDRW_CFG_CS_ADDR_WIDTH(dramaddrw) + DRAMADDRW_CFG_B
> ANK_GRP_ADDR_WIDTH(dramaddrw) +DRAMADDRW_CFG_BANK_ADDR
> _WIDTH(dramaddrw) +DRAMADDRW_CFG_ROW_ADDR_WIDTH(dramaddrw)
> +
>
> Change the function to report size in MiB, prescale it here and youwon't have
> problems for a while . How does that sound ?
Prefer not to as this will be used for comparisons later which would mean we
would need to scale #defines from linux/sizes.h.
--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm; socfpga: stratix10: Add CONFIG_OF_EMBED
On Mon, 2018-09-10 at 20:14 +0200, Simon Goldschmidt wrote: > On 10.09.2018 19:28, Dalon Westergreen wrote: > The dtb should be embedded in the u-boot-spl image so that > the CONFIG_SPL_TARGET of spl/u-boot-spl.hex includes it. > > This also affects the main u-boot image, so adjust > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME to u-boot,img which now > > Tiny typo: replace comma by dot. Thanks > Although this side effect seems a little unwanted...? I would love to think of a use case where this would matter? > also includes the dtb. > > Signed-off-by: Dalon Westergreen > --- > configs/socfpga_stratix10_defconfig | 1 + > include/configs/socfpga_stratix10_socdk.h | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > index c27985ad43..b6d804f38e 100644 > --- a/configs/socfpga_stratix10_defconfig > +++ b/configs/socfpga_stratix10_defconfig > @@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y > CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y > +CONFIG_OF_EMBED=y > diff --git a/include/configs/socfpga_stratix10_socdk.h > b/include/configs/socfpga_stratix10_socdk.h > index 91315a0031..e190b3d988 100644 > --- a/include/configs/socfpga_stratix10_socdk.h > +++ b/include/configs/socfpga_stratix10_socdk.h > @@ -216,6 +216,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); > > /* SPL SDMMC boot support */ > #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 > -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img" > +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img" > > #endif /* __CONFIG_H */ > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] add optional hex output of u-boot-spl
On Mon, 2018-09-10 at 20:06 +0200, Simon Goldschmidt wrote: > On 10.09.2018 19:28, Dalon Westergreen wrote: > This patch set adds a possible hex output of the > u-boot-spl elf and enables said output for the > Intel Stratix10 device. Stratix10 requires a hex > output of the elf for creating the secure device manager > configuration bitstream. > > I don't use Stratix10 but Cyclone5, but as I need a .hex to boot from > FPGA, I want to know how to solve this best. > > So to understand this, again a question: is this the only way to boot > Stratix10? Or one of the possible boot methods? > Because reading "Intel® Stratix® 10 SoC FPGA Boot User Guide", it seems > like you would need the hex for "FPGA Configuration First Mode", but not > for "HPS Boot First Mode"? Stratix 10 always requires this for boot. The configuration method in s10 is very different. The SDM, which is a security processor, copies the u-boot-spl data to the S10 HPS onchip memory. After this is done, the SDM releases the hps from reset. This is regardless of the HPS boot media, which could be SDMMC, etc, etc. > > If so, it would make Stratix10 and Cyclone5 more alike and a > configuration option (like "Boot from FPGA") could be used to control > CONFIG_OF_EMBED and enable creating the hex file for SPL. I looked into how i could enable CONFIG_OF_EMBED only for the SPL build and found no easy way. It was suggested to add something like CONFIG_SPL_OF_EMBED but it still seemed this would require touching a bunch of code. In the end, i really see no reason in socfpga to have the devicetree separated from u-boot / spl. > > I *am* working on fixing the "boot from FPGA" case for Cyclone5, so I'd > appreaciate it if we could share as much as possible between those > sub-architectures. > What difficulties are you having? > > Simon > > > Dalon Westergreen (3): >common: add spl/u-boot-spl.hex target >arm: socfpga: stratix10: add CONFIG_SPL_TARGET >arm; socfpga: stratix10: Add CONFIG_OF_EMBED > > Makefile | 5 + > configs/socfpga_stratix10_defconfig | 1 + > include/configs/socfpga_stratix10_socdk.h | 3 ++- > 3 files changed, 8 insertions(+), 1 deletion(-) > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Fri, 2018-09-07 at 18:25 +0200, Marek Vasut wrote: > On 09/07/2018 06:15 PM, Dalon L Westergreen wrote: > On Thu, 2018-09-06 at 23:56 +0200, Marek Vasut wrote: > On 09/06/2018 11:26 PM, Dalon L Westergreen wrote: > On Thu, 2018-09-06 at 15:41 +0200, Marek Vasut wrote: > On 09/06/2018 03:39 PM, Dalon L Westergreen wrote: > On Thu, 2018-09-06 at 12:09 +0200, Marek Vasut wrote: > On 09/06/2018 05:02 AM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > v2: > -> add CONFIG_OF_EMBED to include dtb in elf > -> generate hex from elf source > > Signed-off-by: Dalon Westergreen <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>>>> > --- > configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ > 2 files changed, 7 insertions(+) > > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > index dceadff439..17cc732cbe 100644 > --- a/configs/socfpga_stratix10_defconfig > +++ b/configs/socfpga_stratix10_defconfig > @@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y > CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y > +CONFIG_OF_EMBED=y > > Why is this needed ? And where did the objcopy hack go ? What is the > explanation here ? > > You suggested the use of CONFIG_OF_EMBED as an alternative to using the > u-boot-spl-dtb.bin for objcopy. > The intent is to ensure that the spl elf has the dtb included, and then > a simple objcopy to elf to hex is fine. > You no longer need the --change-address as the elf indicates the correct > start address, unlike the binary. > > And that's fine with your usecase ? Fine be me then ... > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..b09bd40b2a 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > > CONFIG_SPL_TARGET "u-boot-spl.hex" can replace this addition I think ? > > This doesnt actually work as CONFIG_SPL_TARGET doesnt appear to be an > SPL target, but rather a > target for creating combined u-boot + spl images at the top level. Adding > > ALL-$(CONFIG_SPL_TARGET) += $(obj)/$(SPL_BIN).hex > > in Makefile.spl and > CONFIG_SPL_TARGET="u-boot-spl.hex" > in the socfpga_stratix10_config > > results in a build failure with no target for u-boot-spl.hex > > I mean, just define CONFIG_SPL_TARGET and it should generate the > matching file automatically. See the README, it explains this macro. > > I still get: > > make: *** No rule to make target 'u-boot-spl.hex', needed by 'all'. Stop. > > > When i look at all of the other defined CONFIG_SPL_TARGET, for example > > I guess you did add the u-boot-spl.hex target already ? > > [dwesterg@dwesterg-mobl <mailto:dwesterg@dwesterg-mobl> u-boot]$ grep -R > u-boot-with-spl.bin * > > ... > > ... > > include/configs/uniphier.h:#define CONFIG_SPL_TARGET > "u-boot-with-spl.bin" > > Makefile:OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ > > Makefile:u-boot-with-spl.bin: spl/u-boot-spl.bin $(SPL_PAYLOAD) FORCE > > Makefile:u-boot.ubl: u-boot-with-spl.bin FORCE > > [dwesterg@dwesterg-mobl <mailto:dwesterg@dwesterg-mobl> u-boot]$ > > > or > > > [dwesterg@dwesterg-mobl <mailto:dwesterg@dwesterg-mobl> u-boot]$ grep -R > u-boot-with-nand-spl.imx * > > arch/arm/mach-imx/Makefile:u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx > u-boot.uim FORCE > > include/configs/m53evk.h:#define CONFIG_SPL_TARGET > "u-boot-with-nand-spl.imx" > > Makefile:u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL u-boot.bin FORCE > > > you find the corresponding target in the makefile. There is no target for > u-boot-spl.hex, > > furthermore the CONFIG_SPL_TARGET seems to combine spl with uboot to create a > combined image. > > > ifdef CONFIG_TPL > > SPL_PAYLOAD := tpl/u-boot-with-tpl.bin > > else > > SPL_PAYLOAD := u-boot.bin > > endif > > > OBJCOPYFLAGS_u-boot-with-
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Thu, 2018-09-06 at 23:56 +0200, Marek Vasut wrote: > On 09/06/2018 11:26 PM, Dalon L Westergreen wrote:On Thu, 2018-09-06 at 15:41 > +0200, Marek Vasut wrote:On 09/06/2018 03:39 PM, Dalon L Westergreen wrote:On > Thu, 2018-09-06 at 12:09 +0200, Marek Vasut wrote:On 09/06/2018 05:02 AM, > Dalon Westergreen wrote:Stratix10 requires a hex image of the spl for > boot. The heximage is added to the FPGA configuration image and loaded tothe > processor memory by the configuration engine. > v2: -> add CONFIG_OF_EMBED to include dtb in elf -> generate hex from elf > source > Signed-off-by: Dalon Westergreen dwest...@gmail.com> <mailto:dwest...@gmail.com <mailto:dwest...@gmail.com>>> > --- configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ 2 files changed, 7 > insertions(+) > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfigindex dceadff439..17cc732cbe 100644--- > a/configs/socfpga_stratix10_defconfig+++ > b/configs/socfpga_stratix10_defconfig@@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y+CONFIG_OF_EMBED=y > Why is this needed ? And where did the objcopy hack go ? What is > theexplanation here ? > You suggested the use of CONFIG_OF_EMBED as an alternative to using theu-boot- > spl-dtb.bin for objcopy.The intent is to ensure that the spl elf has the dtb > included, and thena simple objcopy to elf to hex is fine.You no longer need > the --change-address as the elf indicates the correctstart address, unlike the > binary. > And that's fine with your usecase ? Fine be me then ... > diff --git a/scripts/Makefile.spl b/scripts/Makefile.splindex > 76d08fd92b..b09bd40b2a 100644--- a/scripts/Makefile.spl+++ > b/scripts/Makefile.spl@@ -190,6 +190,7 @@ endif ifdef CONFIG_ARCH_SOCFPGA ALL- > $(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp ALL- > $(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp+ALL- > $(CONFIG_TARGET_SOCFPGA_STRATIX10)+= $(obj)/$(SPL_BIN).hex > CONFIG_SPL_TARGET "u-boot-spl.hex" can replace this addition I think ? > This doesnt actually work as CONFIG_SPL_TARGET doesnt appear to be anSPL > target, but rather atarget for creating combined u-boot + spl images at the > top level. Adding > ALL-$(CONFIG_SPL_TARGET) += $(obj)/$(SPL_BIN).hex > in Makefile.spl andCONFIG_SPL_TARGET="u-boot-spl.hex"in the > socfpga_stratix10_config > results in a build failure with no target for u-boot-spl.hex > I mean, just define CONFIG_SPL_TARGET and it should generate thematching file > automatically. See the README, it explains this macro. I still get:make: *** No rule to make target 'u-boot-spl.hex', needed by 'all'. Stop. When i look at all of the other defined CONFIG_SPL_TARGET, for example [dwesterg@dwesterg-mobl u-boot]$ grep -R u-boot-with-spl.bin *..include/configs/uniphier.h:#define CONFIG_SPL_TARGET "u-boot-with-spl.bin"Makefile:OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \Makefile:u-boot-with-spl.bin: spl/u-boot-spl.bin $(SPL_PAYLOAD) FORCEMakefile:u-boot.ubl: u-boot-with-spl.bin FORCE[dwesterg@dwesterg-mobl u- boot]$ or [dwesterg@dwesterg-mobl u-boot]$ grep -R u-boot-with-nand-spl.imx *arch/arm/mach-imx/Makefile:u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx u- boot.uim FORCEinclude/configs/m53evk.h:#define CONFIG_SPL_TARGET "u-boot-with-nand-spl.imx"Makefile:u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL u-boot.bin FORCE you find the corresponding target in the makefile. There is no target for u- boot-spl.hex,furthermore the CONFIG_SPL_TARGET seems to combine spl with uboot to create a combined image. ifdef CONFIG_TPLSPL_PAYLOAD := tpl/u-boot-with-tpl.binelseSPL_PAYLOAD := u- boot.binendif OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ --pad-to=$(CONFIG_SPL_PAD_TO)u-boot-with- spl.bin: spl/u-boot-spl.bin $(SPL_PAYLOAD) FORCE$(call if_changed,pad_cat) So I can add a simple u-boot-spl.hex target, but all of the other CONFIG_SPL_TARGETi see combine spl and u-boot. --dalon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Thu, 2018-09-06 at 15:41 +0200, Marek Vasut wrote: > On 09/06/2018 03:39 PM, Dalon L Westergreen wrote: > > On Thu, 2018-09-06 at 12:09 +0200, Marek Vasut wrote: > > On 09/06/2018 05:02 AM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > v2: > -> add CONFIG_OF_EMBED to include dtb in elf > -> generate hex from elf source > > Signed-off-by: Dalon Westergreen <mailto:dwest...@gmail.com>> > --- > configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ > 2 files changed, 7 insertions(+) > > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > index dceadff439..17cc732cbe 100644 > --- a/configs/socfpga_stratix10_defconfig > +++ b/configs/socfpga_stratix10_defconfig > @@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y > CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y > +CONFIG_OF_EMBED=y > > Why is this needed ? And where did the objcopy hack go ? What is the > explanation here ? > > You suggested the use of CONFIG_OF_EMBED as an alternative to using the > u-boot-spl-dtb.bin for objcopy. > The intent is to ensure that the spl elf has the dtb included, and then > a simple objcopy to elf to hex is fine. > You no longer need the --change-address as the elf indicates the correct > start address, unlike the binary. > > And that's fine with your usecase ? Fine be me then ... > > > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..b09bd40b2a 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > > CONFIG_SPL_TARGET "u-boot-spl.hex" can replace this addition I think ? This doesnt actually work as CONFIG_SPL_TARGET doesnt appear to be an SPL target, but rather a target for creating combined u-boot + spl images at the top level. Adding ALL-$(CONFIG_SPL_TARGET) += $(obj)/$(SPL_BIN).hex in Makefile.spl and CONFIG_SPL_TARGET="u-boot-spl.hex" in the socfpga_stratix10_config results in a build failure with no target for u-boot-spl.hex > > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,11 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex > + > +$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN) FORCE > + $(call if_changed,objcopy) > + > > This is generic, separate patch please. > > LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL) > > > Will do > > Thanks > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Thu, 2018-09-06 at 15:41 +0200, Marek Vasut wrote: > On 09/06/2018 03:39 PM, Dalon L Westergreen wrote: > On Thu, 2018-09-06 at 12:09 +0200, Marek Vasut wrote: > On 09/06/2018 05:02 AM, Dalon Westergreen wrote:Stratix10 requires a hex image > of the spl for boot. The heximage is added to the FPGA configuration image > and loaded tothe processor memory by the configuration engine. > v2: -> add CONFIG_OF_EMBED to include dtb in elf -> generate hex from elf > source > Signed-off-by: Dalon Westergreen dwest...@gmail.com>>--- configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ 2 files changed, 7 > insertions(+) > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfigindex dceadff439..17cc732cbe 100644--- > a/configs/socfpga_stratix10_defconfig+++ > b/configs/socfpga_stratix10_defconfig@@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y+CONFIG_OF_EMBED=y > Why is this needed ? And where did the objcopy hack go ? What is > theexplanation here ? > You suggested the use of CONFIG_OF_EMBED as an alternative to using theu-boot- > spl-dtb.bin for objcopy.The intent is to ensure that the spl elf has the dtb > included, and thena simple objcopy to elf to hex is fine.You no longer need > the --change-address as the elf indicates the correctstart address, unlike the > binary. > And that's fine with your usecase ? Fine be me then ... Is it possible to apply CONFIG_OF_EMBED=y only to the SPL build? > diff --git a/scripts/Makefile.spl b/scripts/Makefile.splindex > 76d08fd92b..b09bd40b2a 100644--- a/scripts/Makefile.spl+++ > b/scripts/Makefile.spl@@ -190,6 +190,7 @@ endif ifdef CONFIG_ARCH_SOCFPGA ALL- > $(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp ALL- > $(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp+ALL- > $(CONFIG_TARGET_SOCFPGA_STRATIX10)+= $(obj)/$(SPL_BIN).hex > CONFIG_SPL_TARGET "u-boot-spl.hex" can replace this addition I think ? > endif ifdef CONFIG_ARCH_SUNXI@@ -299,6 +300,11 @@ OBJCOPYFLAGS_u-boot-x86- > 16bit-spl.bin := -O binary -j .start16 -j .resetvec $(obj)/u-boot-x86-16bit- > spl.bin: $(obj)/u-boot-spl FORCE $(call if_changed,objcopy) > +OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex++$(obj)/$(SPL_BIN).hex: > $(obj)/$(SPL_BIN) FORCE+ $(call if_changed,objcopy)+ > This is generic, separate patch please. > LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL) > Will do > Thanks > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Thu, 2018-09-06 at 07:51 +0200, Simon Goldschmidt wrote: > On Thu, Sep 6, 2018 at 5:04 AM Dalon Westergreen wrote: > > Stratix10 requires a hex image of the spl for boot. The heximage is added to > the FPGA configuration image and loaded tothe processor memory by the > configuration engine. > Although not running a Stratix10, I also need a hex image for spl toboot > unconfigured CycloneV devices.However, for this, it is enough to objcopy u- > boot.spl.sfp to hex andadd the resulting file to the FPGA configuration image. > Quartus does complain about the format a bit, but it does work. Isthis > different for Stratix10? The difference is that in stratix10 the SDM loads the spl image into the HPS onchip ram. The SPL image is actually a part of the fpga configuration image. The tool that adds the image to the fpga configuration image validates its address span, so using objcopy on the binary requires a --change- address. Since the file is always needed for stratix10, it seems prudent to generate it as part of the build. > Simon > > v2: -> add CONFIG_OF_EMBED to include dtb in elf -> generate hex from elf > source > Signed-off-by: Dalon Westergreen --- > configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ 2 files changed, 7 > insertions(+) > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfigindex dceadff439..17cc732cbe 100644--- > a/configs/socfpga_stratix10_defconfig+++ > b/configs/socfpga_stratix10_defconfig@@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y+CONFIG_OF_EMBED=ydiff --git a/scripts/Makefile.spl > b/scripts/Makefile.splindex 76d08fd92b..b09bd40b2a 100644--- > a/scripts/Makefile.spl+++ b/scripts/Makefile.spl@@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA ALL-$(CONFIG_TARGET_SOCFPGA_GEN5) += > $(obj)/$(SPL_BIN).sfp ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += > $(obj)/$(SPL_BIN).sfp+ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += > $(obj)/$(SPL_BIN).hex endif > ifdef CONFIG_ARCH_SUNXI@@ -299,6 +300,11 @@ OBJCOPYFLAGS_u-boot-x86-16bit- > spl.bin := -O binary -j .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: > $(obj)/u-boot-spl FORCE$(call if_changed,objcopy) > +OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex++$(obj)/$(SPL_BIN).hex: > $(obj)/$(SPL_BIN) FORCE+ $(call if_changed,objcopy)+ LDFLAGS_$(SPL_BIN) > += -T u-boot-spl.lds $(LDFLAGS_FINAL) > # Avoid 'Not enough room for program headers' error on binutils 2.28 > onwards.--2.17.1 > ___U-Boot mailing listU- > b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot___U-Boot > mailing listu-b...@lists.denx.dehttps://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Thu, 2018-09-06 at 12:09 +0200, Marek Vasut wrote: > On 09/06/2018 05:02 AM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The heximage is added to > the FPGA configuration image and loaded tothe processor memory by the > configuration engine. > v2: -> add CONFIG_OF_EMBED to include dtb in elf -> generate hex from elf > source > Signed-off-by: Dalon Westergreen --- > configs/socfpga_stratix10_defconfig | 1 + > scripts/Makefile.spl| 6 ++ 2 files changed, 7 > insertions(+) > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfigindex dceadff439..17cc732cbe 100644--- > a/configs/socfpga_stratix10_defconfig+++ > b/configs/socfpga_stratix10_defconfig@@ -56,3 +56,4 @@ CONFIG_DM_USB=y > CONFIG_USB_DWC2=y CONFIG_USB_STORAGE=y > CONFIG_USE_TINY_PRINTF=y+CONFIG_OF_EMBED=y > Why is this needed ? And where did the objcopy hack go ? What is > theexplanation here ? You suggested the use of CONFIG_OF_EMBED as an alternative to using the u-boot- spl-dtb.bin for objcopy. The intent is to ensure that the spl elf has the dtb included, and then a simple objcopy to elf to hex is fine.You no longer need the --change-address as the elf indicates the correct start address, unlike the binary. > diff --git a/scripts/Makefile.spl b/scripts/Makefile.splindex > 76d08fd92b..b09bd40b2a 100644--- a/scripts/Makefile.spl+++ > b/scripts/Makefile.spl@@ -190,6 +190,7 @@ endif ifdef CONFIG_ARCH_SOCFPGA ALL- > $(CONFIG_TARGET_SOCFPGA_GEN5) += $(obj)/$(SPL_BIN).sfp ALL- > $(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp+ALL- > $(CONFIG_TARGET_SOCFPGA_STRATIX10)+= $(obj)/$(SPL_BIN).hex > CONFIG_SPL_TARGET "u-boot-spl.hex" can replace this addition I think ? > endif ifdef CONFIG_ARCH_SUNXI@@ -299,6 +300,11 @@ OBJCOPYFLAGS_u-boot-x86- > 16bit-spl.bin := -O binary -j .start16 -j .resetvec $(obj)/u-boot-x86-16bit- > spl.bin: $(obj)/u-boot-spl FORCE $(call if_changed,objcopy) > +OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex++$(obj)/$(SPL_BIN).hex: > $(obj)/$(SPL_BIN) FORCE+ $(call if_changed,objcopy)+ > This is generic, separate patch please. > LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL) Will do > # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] spl: socfpga: only gen5 devices and arria10 require sfp image
On Thu, 2018-09-06 at 12:08 +0200, Marek Vasut wrote: > On 09/06/2018 05:02 AM, Dalon Westergreen wrote: > > Only the Cyclone5/Arria5 and Arria10 devices require the sfp > formated image for booting. This path ensures that the file is > only generated for those devices. > > Signed-off-by: Dalon Westergreen > --- > scripts/Makefile.spl | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 252f13826d..76d08fd92b 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -188,7 +188,8 @@ ALL-y += $(obj)/$(BOARD)-spl.bin > endif > > ifdef CONFIG_ARCH_SOCFPGA > -ALL-y+= $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > endif > > ifdef CONFIG_ARCH_SUNXI > > What about adding Kconfig option , something like > CONFIG_TARGET_SOCFPGA_SFP , using it above and enabling it on Gen5 and > A10 ? That way ,we won't have two entries with the same content. > Good idea. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Tue, 2018-08-28 at 17:51 +0200, Marek Vasut wrote: > On 08/28/2018 05:43 PM, Dalon L Westergreen wrote: > > On Tue, 2018-08-28 at 01:54 +0200, Marek Vasut wrote: > > On 08/28/2018 12:03 AM, Dalon L Westergreen wrote: > On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote: > On 08/27/2018 05:30 PM, Dalon L Westergreen wrote: > On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote: > On 08/20/2018 11:04 PM, Dalon L Westergreen wrote: > On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote: > On 08/20/2018 03:54 PM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > Signed-off-by: Dalon Westergreen <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>>> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>>>>> > --- > scripts/Makefile.spl | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..c424f87e6e 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0 > > Why is this --change-address needed ? This smells like a hack of some > sort ... > > I believe the tool that uses this file expects this offset, that said i have > not > > tried using a hex file without this change address applied. I will try > without > > this, and see what happens. > > You probably need to adjust the link address of the SPL or U-Boot too. > > The link address appears to be correctly set to 0xffe0 which is the > location of the onchip ram. > > The quartus_cpf tool itself errors out when the --change-address option is > not used. The quartus_cpf > > checks that the address range of the hex is entirely within the onchip ram. > My suggestion would > > be to leave the --change-address option as is. > > So what is _not_ in the onchip RAM then ? Is something sticking out of > the OCRAM , that's why the quartus_cpf fails ? Maybe that's something > you should fix. > > Thanks Marek, I'm m not very familiar with the hex format > > The intel ihex is terrible (sorry), it's really hard to decode. But > here's some example: > https://en.wikipedia.org/wiki/Intel_HEX > > but there only 2 lines that differ when > > using the change address option, the first and last, of the hex. > > > in the file with the change-address option :0204FFE01B is prepended to > the file, and > > :0405FFE018 is added to the second to last line. It is followed by > :0001FF (end of file). > > > My belief is the change-address is simply specifying the start address of the > hex data converted from > > the binary. This offset is required by the quartus_cpf tool as a form of > validation. > > This is what objcopy(1) says: > >--change-addresses incr >--adjust-vma incr >Change the VMA and LMA addresses of all sections, as well as > the start address, by adding incr. Some object file formats do not > permit section addresses to be changed >arbitrarily. Note that this does not relocate the sections; > if the program expects sections to be loaded at a certain address, and > this option is used to change the sections such >that they are loaded at a different address, the program may > fail. > > So I ran make V=1 , to see how the hex file is generated, and this is how: > aarch64-linux-gnu-objcopy -j .text -j .secure_text -j .secure_data -j > .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j > .binman_sym_
Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Tue, 2018-08-28 at 01:54 +0200, Marek Vasut wrote: > On 08/28/2018 12:03 AM, Dalon L Westergreen wrote: > On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote: > On 08/27/2018 05:30 PM, Dalon L Westergreen wrote: > On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote: > On 08/20/2018 11:04 PM, Dalon L Westergreen wrote: > On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote: > On 08/20/2018 03:54 PM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > Signed-off-by: Dalon Westergreen <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>>>> > --- > scripts/Makefile.spl | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..c424f87e6e 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0 > > Why is this --change-address needed ? This smells like a hack of some > sort ... > > I believe the tool that uses this file expects this offset, that said i have > not > > tried using a hex file without this change address applied. I will try > without > > this, and see what happens. > > You probably need to adjust the link address of the SPL or U-Boot too. > > The link address appears to be correctly set to 0xffe0 which is the > location of the onchip ram. > > The quartus_cpf tool itself errors out when the --change-address option is > not used. The quartus_cpf > > checks that the address range of the hex is entirely within the onchip ram. > My suggestion would > > be to leave the --change-address option as is. > > So what is _not_ in the onchip RAM then ? Is something sticking out of > the OCRAM , that's why the quartus_cpf fails ? Maybe that's something > you should fix. > > Thanks Marek, I'm m not very familiar with the hex format > > The intel ihex is terrible (sorry), it's really hard to decode. But > here's some example: > https://en.wikipedia.org/wiki/Intel_HEX > > but there only 2 lines that differ when > > using the change address option, the first and last, of the hex. > > > in the file with the change-address option :0204FFE01B is prepended to > the file, and > > :0405FFE018 is added to the second to last line. It is followed by > :0001FF (end of file). > > > My belief is the change-address is simply specifying the start address of the > hex data converted from > > the binary. This offset is required by the quartus_cpf tool as a form of > validation. > > This is what objcopy(1) says: > >--change-addresses incr >--adjust-vma incr >Change the VMA and LMA addresses of all sections, as well as > the start address, by adding incr. Some object file formats do not > permit section addresses to be changed >arbitrarily. Note that this does not relocate the sections; > if the program expects sections to be loaded at a certain address, and > this option is used to change the sections such >that they are loaded at a different address, the program may > fail. > > So I ran make V=1 , to see how the hex file is generated, and this is how: > aarch64-linux-gnu-objcopy -j .text -j .secure_text -j .secure_data -j > .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j > .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j > .efi_runtime_rel -I binary -O ihex --change-addresses 0xffe0 > spl/u-boot-spl.bin spl/u-boot-spl.hex > > It's generated from u-boot-spl.bin , which is weird. The u-boot.hex is > generated from u-boot (ELF binary). I think that's what the SPL hex > should be generated from too, since the ELF binary contains all the > relocation
Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote: > On 08/27/2018 05:30 PM, Dalon L Westergreen wrote: > On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote: > On 08/20/2018 11:04 PM, Dalon L Westergreen wrote: > On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote: > On 08/20/2018 03:54 PM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > Signed-off-by: Dalon Westergreen <mailto:dwest...@gmail.com> <mailto:dwest...@gmail.com > <mailto:dwest...@gmail.com>>> > --- > scripts/Makefile.spl | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..c424f87e6e 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0 > > Why is this --change-address needed ? This smells like a hack of some > sort ... > > I believe the tool that uses this file expects this offset, that said i have > not > > tried using a hex file without this change address applied. I will try > without > > this, and see what happens. > > You probably need to adjust the link address of the SPL or U-Boot too. > > The link address appears to be correctly set to 0xffe0 which is the > location of the onchip ram. > > The quartus_cpf tool itself errors out when the --change-address option is > not used. The quartus_cpf > > checks that the address range of the hex is entirely within the onchip ram. > My suggestion would > > be to leave the --change-address option as is. > > So what is _not_ in the onchip RAM then ? Is something sticking out of > the OCRAM , that's why the quartus_cpf fails ? Maybe that's something > you should fix. > Thanks Marek, I'm m not very familiar with the hex format, but there only 2 lines that differ when using the change address option, the first and last, of the hex. in the file with the change-address option :0204FFE01B is prepended to the file, and :0405FFE018 is added to the second to last line. It is followed by :0001FF (end of file). My belief is the change-address is simply specifying the start address of the hex data converted from the binary. This offset is required by the quartus_cpf tool as a form of validation. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote: > On 08/20/2018 11:04 PM, Dalon L Westergreen wrote: > On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote: > On 08/20/2018 03:54 PM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > Signed-off-by: Dalon Westergreen <mailto:dwest...@gmail.com>> > --- > scripts/Makefile.spl | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..c424f87e6e 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0 > > Why is this --change-address needed ? This smells like a hack of some > sort ... > > I believe the tool that uses this file expects this offset, that said i have > not > > tried using a hex file without this change address applied. I will try > without > > this, and see what happens. > > You probably need to adjust the link address of the SPL or U-Boot too. > The link address appears to be correctly set to 0xffe0 which is the location of the onchip ram. The quartus_cpf tool itself errors out when the --change-address option is not used. The quartus_cpf checks that the address range of the hex is entirely within the onchip ram. My suggestion would be to leave the --change-address option as is. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image
On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote: > On 08/20/2018 03:54 PM, Dalon Westergreen wrote: > Stratix10 requires a hex image of the spl for boot. The hex > image is added to the FPGA configuration image and loaded to > the processor memory by the configuration engine. > > Signed-off-by: Dalon Westergreen > --- > scripts/Makefile.spl | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl > index 76d08fd92b..c424f87e6e 100644 > --- a/scripts/Makefile.spl > +++ b/scripts/Makefile.spl > @@ -190,6 +190,7 @@ endif > ifdef CONFIG_ARCH_SOCFPGA > ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp > ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp > +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex > endif > > ifdef CONFIG_ARCH_SUNXI > @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j > .start16 -j .resetvec > $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE > $(call if_changed,objcopy) > > +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10 > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0 > > Why is this --change-address needed ? This smells like a hack of some > sort ... > I believe the tool that uses this file expects this offset, that said i have not tried using a hex file without this change address applied. I will try without this, and see what happens. > > +else > +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex > +endif > + > +$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN).bin FORCE > + $(call if_changed,objcopy) > + > LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL) > > # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
