Re: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, socfpga-stmmac
Hi Joe, > -Original Message- > From: Joe Hershberger > Sent: Wednesday, September 4, 2019 1:10 AM > To: Alexey Brodkin > Cc: Ralph Siemsen ; Joseph Hershberger > ; u- > b...@lists.denx.de; linux-snps-...@lists.infradead.org; Eugeniy Paltsev > > Subject: Re: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, > socfpga-stmmac > > On Tue, Aug 20, 2019 at 3:07 AM Alexey Brodkin > wrote: > > > > Hi Ralph, > > > > > -Original Message- > > > From: Ralph Siemsen > > > Sent: Monday, August 19, 2019 9:43 PM > > > To: u-boot@lists.denx.de; Joe Hershberger ; > > > Alexey Brodkin > > > ; Vlad Zakharov > > > Cc: Ralph Siemsen > > > Subject: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac > > > > > > The same compatible = "altr,socfpga-stmmac" appears in both > > > drivers/net/designware.c and drivers/net/dwmac_socfgpa.c, > > > creating ambiguity in which driver will be bound. > > > > > > For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver. > > > So drop the compatible string from designware.c. > > > > > > Signed-off-by: Ralph Siemsen > > > --- > > > This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts. > > > Maintainers of those boards have been copied, kindly review. > > > > Thanks for this clean-up. > > > > Speaking about AXS10x board where we do have DW GMAC > > I cannot recall the reason I chose to use "altr,socfpga-stmmac" > > for the board here [1] 3 years ago. > > > > But given we don't have any special quirks implemented whatever > > is the most generic DW GMAC compatible string is should be good for us. > > > > Joe, could you please suggest if we need to use just "st,stm32-dwmac" > > or add our own compatible as the ASIC is not from ST obviously but > > an FPGA with Synopsys ARC SoC? > > I think we should only be using what Linux does, so I'm afraid I have > to defer to what exists in the DTs there. In the Linux kernel we use "snps,dwmac", see [1]. But maybe we need to switch to "snps,dwmac-3.70a" even as what we really have is 3.73a. While in U-Boot we don't have either one, the most generic is "st,stm32-dwmac", see [2]. So maybe we want to add at least "snps,dwmac". @Jose Abreu could you please confirm if "snps,dwmac-3.70a" is OK for GMAC IP v3.73a? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/boot/dts/axs10x_mb.dtsi#n74 [2] https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/net/designware.c#L855 -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] lx2160: Correct serdes frequency print.
Signed-off-by: Meenakshi Aggarwal
---
changed for v2:
- corrected typo in commit message.
---
board/freescale/lx2160a/lx2160a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/lx2160a/lx2160a.c
b/board/freescale/lx2160a/lx2160a.c
index 8140f3e..eff5d9f 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -372,7 +372,7 @@ int checkboard(void)
puts("SERDES1 Reference: Clock1 = 161.13MHz Clock2 = 161.13MHz\n");
puts("SERDES2 Reference: Clock1 = 100MHz Clock2 = 100MHz\n");
- puts("SERDES3 Reference: Clock1 = 100MHz Clock2 = 100Hz\n");
+ puts("SERDES3 Reference: Clock1 = 100MHz Clock2 = 100MHz\n");
#endif
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] DFU and UBIFS Volume upgrade
Hello Loic, added Lukasz as he is the DFU custodian. Am 03.09.2019 um 09:59 schrieb Loic Poulain: Hi, AFAIU, today it's possible to update a UBI partition via DFU with a new UBI blob using 'partubi'. Yes. However, this causes two issues/limitations: - It erases the partition, causing PEB erase counters amnesia (contrary to Linux ubiformat) Yes, patches which fixes this are welcome :-P - It's no possible to have a volume-grained upgrade (per UBIFS volume) I am not to deep in the DFU topic involved, but I think the problem is that ubi is not an interface like "nand" or "mmc" it is more something like a partition type ... The big problem with writting an ubi image into nand is, that you need to store the image first in RAM and you may have not enough ... so may writting volume serverally it may help out here. On the other side, it is may possible to introduce an ubi interface for UBI volumes. But what if your board has not setup yet UBI, nor the UBI Volumes? Is there an interface in DFU for setting up something like "partitions" ? You need to pass several parameters to create a new UBI Volume ... May Lukasz can say here more ... I prefer nowadays to boot a linux and use swupdate, which can handle UBI Volumes ... I saw some (very) old threads on this subject but no conclusion. Did I miss something? any recommendations? No there is no update on this, or I do not know it. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Environment flags broken for U-Boot
Hello Joe, Am 04.09.2019 um 01:03 schrieb Joe Hershberger: On Tue, Sep 3, 2019 at 3:05 AM Wolfgang Denk wrote: Dear Tom, In message Heiko Schocher wrote: I am just testing U-Boot Environment flags and they do not work anymore with current mainline U-Boot ... ... reason is your commit: commit 7d4776545b0f8a8827e5d061206faf61c9ba6ea9 Author: Patrick Delaunay Date: Thu Apr 18 17:32:49 2019 +0200 env: solve compilation error in SPL Looking into the history of this, I wonder if we could / should have prevented this. As far as I can see, Patrick's patch series has not been reviewed by others, probably because general intetest in STM32 is not that big at the moment. I can see no Acked-by:, Reviewed-by: nor Tested-by: tags - nothing. The whole patch series was then pulled from the u-boot-stm repository. However, there was not only STM related code in there. There were changes to common code like the environment handling. common code was changed without review and without testing. It seems this should be unacceptable even if it's in the area of interest. Isn't an Acked-by generally accepted as required? Yes, but it seems we are not strict enough here. Are there ways to prevent this? Yes, we can appeal to the custodians to be more careful, but I assume they are already doing their best. It seems the diffstat should be a quick way to see this, so I would think not quite their best. Maybe a reminder / recommendation that it be reviewed by custodians? Yes. I recommend to use patman for sending patches, or at least to do a dry run with it, so you get a cc list (which is sometimes to long) of people who may interested in the patch. It might have even been better if this had been a sub-system with a clear maintainer, but there is no such person for the environment code. How can we prevent this in the future? Is there any tooling around the MAINTAINERS file that can be used to reg-flag PRs that contain changes outside of the tree's area of effect? I do not know. Should we define "interested developers" for such areas that have no custodian (the "Designated reviewer") entry in the MAINTAINERS file could be used for this, for example)? I like that idea, though in this specific case I think there should be a maintainer for env. Wasn;t aware of the the "Designated reviewer" entry in MAINTAINERS, I think, this is a good idea. And of course, if someone volunteers for mainting env, this would be good. But we should monitor (or find a script which checks this), that patches not acked by a subsystem custodian not go in outside of a pull request from the custodian. Problem is here, that we have parts of code, which have no custodian ... I can only speak for i2c, which often get patches in patchseries for other custodians. I try to catch such patches and add a Review or Acked-by ... but I do not catch all... so using patman would help, as I get added to cc ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Buffer overrun risk in UBI SPL for secure boot
It seems that, in the process of doing any sort of secure boot chain of trust, anything loading a UBI volume in preparation to authenticate it, will load a volume of unknown size into a buffer prior to checking the signature of that volume. Has anyone considered a solution for this? Should all implementations just carve out a buffer at the top of memory for ubispl_load_volume or should the ubispl_load data structure be amended to include a size? It would seem appropriate to include a size, but not clear how to do that without breaking compatibility with existing implementations. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode
Hello Lukasz,
added Stefano to cc as he is the imx custodian.
Am 03.09.2019 um 23:43 schrieb Lukasz Majewski:
This change tries to fix the following problem:
- The board boots (to be more precise - ROM loads SPL) from a slow SPI-NOR
memory.
As a result the spl_boot_device() will return SPI-NOR as a boot device
(which is correct).
- The problem is that in 'falcon boot' the eMMC is used as a boot medium to
load kernel from its partition.
Calling spl_boot_device() will break things as it returns SPI-NOR device.
To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig flag is
introduced to handle this special use case. By default it is not defined,
so there is no change in the legacy code flow.
Signed-off-by: Lukasz Majewski
---
This patch is a follow up of previous discussion/fix:
https://patchwork.ozlabs.org/patch/796237/
Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/580272414
---
arch/arm/mach-imx/spl.c | 11 +++
common/spl/Kconfig | 7 +++
2 files changed, 18 insertions(+)
I have just similiar change for an imx6ull based board ...
just antoher usecase: In factory empty board boots into USB SDP mode,
and SPL gets loaded with usb_loader ... SPL detects a sd card (there
is no sd card slot mounted, mmc boot is disabled! They attach only one
for installing software) and boots U-Boot and system from sd card.
Than all software gets installed fully automated with the help of
swupdate ...
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1f230aca3397..daa3d8f7ed94 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -178,7 +178,18 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
/* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
u32 spl_boot_mode(const u32 boot_device)
{
+/*
+ * When CONFIG_SPL_FORCE_MMC_BOOT is defined the 'boot_device' is used
+ * unconditionally to decide about device to use for booting.
+ * This is crucial for falcon boot mode, when board boots up (i.e. ROM
+ * loads SPL) from slow SPI-NOR memory and afterwards the SPL's 'falcon' boot
+ * mode is used to load Linux OS from eMMC partition.
+ */
+#ifdef CONFIG_SPL_FORCE_MMC_BOOT
+ switch (boot_device) {
+#else
switch (spl_boot_device()) {
+#endif
Just dummy question .. couldn;t we switch to use always boot_device?
In my case I had a board specific:
void board_boot_order(u32 *spl_boot_list)
{
spl_boot_list[0] = BOOT_DEVICE_MMC1;
spl_boot_list[1] = BOOT_DEVICE_SPI;
spl_boot_list[2] = BOOT_DEVICE_BOARD;
spl_boot_list[3] = BOOT_DEVICE_NONE;
}
which leads that BOOT_DEVICE_MMC1 is passed to spl_boot_mode()
If MMC1 is not found, it tries to boot U-Boot from SPI, and if this is
empty, as fallback board go into USB SDP mode.
The weak function of board_boot_order is:
__weak void board_boot_order(u32 *spl_boot_list)
{
spl_boot_list[0] = spl_boot_device();
}
which is exactly what we pass to spl_boot_mode() ... so instead calling
spl_boot_device() twice we can use the passed boot_device ... and
save the ifdef and new Kconfig option.
But may I oversee something ?
/* for MMC return either RAW or FAT mode */
case BOOT_DEVICE_MMC1:
case BOOT_DEVICE_MMC2:
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index f467eca2be72..3460beb62d59 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -607,6 +607,13 @@ config SPL_MMC_SUPPORT
this option to build the drivers in drivers/mmc as part of an SPL
build.
+config SPL_FORCE_MMC_BOOT
+ bool "Force SPL's falcon boot from MMC"
+ depends on SPL_MMC_SUPPORT
+ default n
+ help
+ Force SPL's falcon boot to use MMC device for Linux kernel booting.
Hmm... falcon boot is just one use case. I would drop "falcon boot"
It just to force boot from MMC.
+
config SPL_MMC_TINY
bool "Tiny MMC framework in SPL"
depends on SPL_MMC_SUPPORT
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] mmc: fsl_esdhc: clean up code
Any comments? Thanks:) > -Original Message- > From: Yangbo Lu > Sent: Monday, August 19, 2019 4:28 PM > To: u-boot@lists.denx.de; Peng Fan > Cc: Y.b. Lu > Subject: [PATCH 0/3] mmc: fsl_esdhc: clean up code > > This patch-set is to clean up fsl_esdhc code. > > Yangbo Lu (3): > mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC > mmc: fsl_esdhc: clean up code > mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg > > drivers/mmc/fsl_esdhc.c | 371 > +++- > include/fsl_esdhc.h | 203 -- > 2 files changed, 240 insertions(+), 334 deletions(-) > > -- > 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: ls1028a: Updated lane C configuration to PCIe2 for 0x13BB
From: Hou Zhiqiang
In SerDes protocol 0x13BB, lane C was erroneously asigned
to PCIe1, so fix it.
Fixes: 36f50b75238e ("armv8: ls1028a: Add other serdes protocal support")
Signed-off-by: Hou Zhiqiang
---
arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
index 5835a3a69e..313f3f1e8a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
@@ -24,7 +24,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x, {PCIE1, PCIE1, PCIE1, PCIE1} },
{0xE031, {SXGMII1, QXGMII2, NONE, SATA1} },
{0xB991, {SXGMII1, SGMII1, SGMII2, PCIE1} },
- {0xBB31, {SXGMII1, QXGMII2, PCIE1, PCIE1} },
+ {0xBB31, {SXGMII1, QXGMII2, PCIE2, PCIE1} },
{0xCC31, {SXGMII1, QXGMII2, PCIE2, PCIE2} },
{0xBB51, {SXGMII1, QSGMII_B, PCIE2, PCIE1} },
{0xBB38, {SGMII_T1, QXGMII2, PCIE2, PCIE1} },
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] What if ATF can be part of U-Boot source, like SPL?
On Sun, Jun 30, 2019 at 11:20 PM Marek Vasut wrote: > > On 6/30/19 4:17 PM, Tom Rini wrote: > > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote: > >> On 6/30/19 3:57 PM, Tom Rini wrote: > >>> On Sat, Jun 29, 2019 at 08:32:00PM +0530, Jagan Teki wrote: > >>> > In terms of code maintenance and development feasibility it is always > a better approach to have out-of-tree code or binary to be part of > in-house source tree. > > This is what exactly it was done for SPL, if I'm not wrong. So can we > do the same thing for ATF on ARM64 SoCs? > > We are using ATF (on Allwinner) to switch EL3 to EL2 for start loading > U-Boot proper and minimal PSCI, PMIC initialization. So assuming the > functionality of ATF (like here) is limited so the code it require can > be limited too, so why can't this code to be part of U-Boot tree? > > This would ultimately avoid out-off-tree ATF builds with associated > variable exporting during u-boot builds. > > More over this idea would also help to design a single-step bootloader > where it can't depends on out-of-tree sources. > > Code sync from ATF source to U-Boot can be possible in-terms licensing > point-of-view since ATF licensed under BSD-3-Clause. > > I'm thinking this can be a worth-idea to look at it and I'm sure It > may require some hard changes and other things to consider but just > posted to understand how hard or feasible or meaningful it is? > > Feel free for any comments? > >>> > >>> Given that we have "TPL" and "SPL", my "pie in the sky" wish would be > >>> for the ability to build different U-Boots to fill the different aspects > >>> of the aarch64 boot flow. > >>> > >>> That said, patches that would in turn allow for users to locally add ATF > >>> as a git submodule and then build that, if cleanly done, could be > >>> interesting. But must not impact the normal build flow. > >> > >> So can we also add Linux as a submodule ? And glibc ? Maybe busybox too ? > > > > Just as you suggested Jagan look at other SoCs and how they assemble > > images, I think you also need to take a wider look around. The concept > > of "take U-Boot, other firmware blobs, combine and mangle that" is > > somewhat widely used. It's not just sunxi that spits out a "can't find > > ATF, this image won't boot!" warning. > > So, U-Boot spits out that it cannot find kernel image and refuses to > boot, do we also import Linux into the codebase because of that ? > > But Linux also spits that it cannot find init and refuses to boot. Do we > import systemd/sysvinit/upstart/... because of that ? > > No, we do not. That's what build systems like OE or buildroot or whatnot > are for. If you want to assemble your image by hand, that's also fine, > surely you should be capable of replicating what the documentation / OE > / buildroot recipe suggests. I agree with Marek. U-Boot should be independent. I do not like the git-submodule approach. Jagan's proposal..., no way! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] What if ATF can be part of U-Boot source, like SPL?
Hi, On Tue, 2 Jul 2019 at 11:42, Marek Vasut wrote: > > On 6/30/19 3:38 AM, André Przywara wrote: > > On 30/06/2019 00:03, Marek Vasut wrote: > > > > Marek, > > > > you seem to be quite defensive in your answer > > I am just correcting the mistakes I perceive in the previous email. > > >, but I was just talking > > against merging ATF into U-Boot, not against U-Boot - I think we agree > > on this. I don't think there is much of a point in comparing ATF and > > U-Boot, as the two do not compete against each other. They just > > complement each other nicely, hence we use ATF and save us the burden of > > having to reprogram something in U-Boot. > > I suspect I answered those already in the thread. > > >> On 6/29/19 8:49 PM, André Przywara wrote: > >>> On 29/06/2019 16:02, Jagan Teki wrote: > In terms of code maintenance and development feasibility it is always > a better approach to have out-of-tree code or binary to be part of > in-house source tree. > >>> > >>> I am not sure this is really true. If I get you right, you want to > >>> mirror and sync the ATF source into the U-Boot tree, which sounds like a > >>> pain: > >>> - ATF development is quite dynamic, with just shy of 1000 commits alone > >>> this year. > >> > >> I don't think ATF development is anywhere near as dynamic as U-Boot, > >> there's over 1000 commits in each U-Boot release, with quarterly release > >> cycle. > > > > Wasn't comparing, just saying that it's nothing you want to sync > > regularly. Unlike libfdt, for instance. > > > >>> This would mean constant churn of keeping the source up-to-date. > >>> - The overlap of U-Boot and ATF users is not that big: ATF has support > >>> for a lot more platforms (most of them typically paired with EDK-2), > >> > >> Can you elaborate on how you came to this conclusion ? Last time I > >> counted (a few days ago, in ATF master), the upstream ATF supported some > >> low tens of boards, upstream U-Boot around a thousand. And then there's > >> the part where ATF is ARM-centric while U-Boot is platform-agnostic. > > > > I now see that my wording was unclear: ATF supports more platforms than > > those that also use U-Boot. So you pull in code that you will never need. > > I think s/more/different/ > > [...] > > >>> I am not questioning the current design, but just want to point out that > >>> this might not be best thing since sliced bread. > >> > >> It would certainly help if we could have one, or a few, bootloader > >> project(s) and work on those few, to make them great. Currently there > >> are many, each with a limited developer community. Adding more does not > >> help, it only increases the fragmentation and the mess. > > > > And that's exactly the point of ATF: You can use the tested PSCI code, > > the secure GIC setup and all those core errata workarounds and spare > > yourself from wrongly implementing this on your own. > > Which is a benefit of one single vendor being in control of everything? > Surely, this single vendor has perfect engineers that make no mistakes, > right? I think we had that before, and it didn't work out very well :) > > > Also ATF is not a bootloader, it explicitly leaves out that part. > > > So can we > do the same thing for ATF on ARM64 SoCs? > > We are using ATF (on Allwinner) to switch EL3 to EL2 for start loading > U-Boot proper and minimal PSCI > >>> > >>> Minimal PSCI? TF-A is the full fledged reference implementation of PSCI, > >>> it always supports the newest revisions, including Spectre/Meltdown > >>> support. This alone is a killer argument for me to use ATF. > >> > >> So ARM creates new PSCI version, ARM implements it into ARM trusted > >> firmware, and then presents it to the users as the latest greatest. > > > > Yes, that's the definition of a reference implementation. And it's Open > > Source with a permissive license. > > Yes, it's Open Source and it's not Free Software, which is unfortunate. > It allows disasters like vendors taking ATF, reaping all the benefits of > external contributions, but releasing only closed-source blobs and > giving everyone who wants to study the code or change it the finger. > > >> That sounds a bit like the old windows development model -- one company > >> does everything and then presents it to developers for them to consume. > > > > PSCI is an interface, with a publicly available spec. You can go ahead > > and implement it yourself - and U-Boot does. And by using PSCI, you win > > so much, because SMP in *any* kernel suddenly becomes very straightforward. > > Just about like ACPI on x86. > > > So if you mean with "Windows model" that there is a standard that makes > > everyone's life easier by providing compatibility and well defined > > interfaces - I agree. For everything else I fail to see how it would > > compare. > > I meant more like one company in control of everything, just providing > consumables for developers. > > >> My recent impression of ATF development is there is no
Re: [U-Boot] Please pull from u-boot-i2c
On Mon, Sep 02, 2019 at 11:41:20AM +0200, Heiko Schocher wrote: > Hello Tom, > > one late pull request for u-boot-i2c as I missed Pengs patch... > > The following changes since commit 877294b56a52f1cb60bbfa7e4722fcc33451f7b2: > > Merge tag 'efi-2019-10-rc4' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2019-08-29 07:26:42 > -0400) > > are available in the Git repository at: > > origin/master for-v2019.10-v2 > > for you to fetch changes up to 6dba0864ece3f4006abae8ff9e2ad74f4374359d: > > i2c: mxc: add CONFIG_CLK support (2019-09-02 06:35:08 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull ARC fixes for 2019.10-rc4
On Tue, Sep 03, 2019 at 04:10:31PM +, Alexey Brodkin wrote: > Hi Tom, > > The following changes since commit d22c8be964a870f59d2fdab6c67cefa0c4799364: > > Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-09-01 13:33:12 > -0400) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-arc.git > tags/arc-for-2019.10-rc4 > > for you to fetch changes up to 968b98bc27c2b228323c53761075422ebbb098bd: > > arc: emsdp: Add more platform-specific compiler options (2019-09-03 > 19:05:34 +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-riscv/master
On Tue, Sep 03, 2019 at 10:15:42AM +0800, ub...@andestech.com wrote: > Hi Tom, > > Please pull some riscv updates: > > - Skip unavailable hart in the get_count(). > - fu540 set serial env from otp. > - fu540 add mmc0 as a boot target device. > - Update fix_rela_dyn and add absolute reloc addend. > - Andestech PLIC driver will skip unavailable hart. > - Support Andestech V5L2 cache driver. > > https://travis-ci.org/rickchen36/u-boot-riscv/builds/579707002 > > Thanks > Rick > > > The following changes since commit d22c8be964a870f59d2fdab6c67cefa0c4799364: > > Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-09-01 13:33:12 > -0400) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 61ce84b2cf1a6672c8e402ce8174554b25629692: > > riscv: cache: use CCTL to flush d-cache (2019-09-03 09:31:03 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: nfs: remove superfluous packed attribute
On Mon, Sep 2, 2019 at 5:05 PM Heinrich Schuchardt wrote: > > With GCC 9.2.1 net/nfs.c leads to multiple errors of type > address-of-packed-member. > > net/nfs.c: In function ‘rpc_req’: > net/nfs.c:199:18: error: taking address of packed member of > ‘struct rpc_t’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] > 199 | p = (uint32_t *)&(rpc_pkt.u.call.data); > | ^~ > net/nfs.c: In function ‘nfs_readlink_reply’: > net/nfs.c:631:46: error: taking address of packed member of > ‘struct rpc_t’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] > 631 |nfs3_get_attributes_offset(rpc_pkt.u.reply.data); > | ~~~^ > LD drivers/block/built-in.o > net/nfs.c: In function ‘nfs_read_reply’: > net/nfs.c:692:46: error: taking address of packed member of > ‘struct rpc_t’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] > 692 |nfs3_get_attributes_offset(rpc_pkt.u.reply.data); > | ~~~^ > > struct rpc_t is only used as local variable. It is naturally packed. So > there is no need for the attribute packed. > > Signed-off-by: Heinrich Schuchardt Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] net: nfs: -Werror=address-of-packed-member
On 9/3/19 11:32 PM, Joe Hershberger wrote: Hi Heinrich, On Mon, Sep 2, 2019 at 4:39 PM Heinrich Schuchardt wrote: Hello Joe, GCC 9.2.1 (of Debian Bullseye) produces the warnings below when building pine64-lts_defconfig. Is it really necessary to define struct rpc_t as packed? The structure is composed out of uint32_t only. So shouldn't it be naturally packed without the attribute? I guess this won't cause problems on 64-bit with the union sharing memory, right? The addresses of all members of a union is the same. See C99 standard 6.2.7.1, paragraph 14. The alignment requirement on an array is not stricter than on its elements. Anyway the arrays in the union start at a multiple of 64bit after the start of the structure. Both on x86_64 and on arm64 is 24 bytes after without 'packed' - just where you would expect it. Best regards Heinrich net/nfs.c: In function ‘rpc_req’: net/nfs.c:199:18: error: taking address of packed member of ‘struct rpc_t’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 199 | p = (uint32_t *)&(rpc_pkt.u.call.data); | ^~ net/nfs.c: In function ‘nfs_readlink_reply’: net/nfs.c:631:46: error: taking address of packed member of ‘struct rpc_t’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 631 |nfs3_get_attributes_offset(rpc_pkt.u.reply.data); | ~~~^ LD drivers/block/built-in.o net/nfs.c: In function ‘nfs_read_reply’: net/nfs.c:692:46: error: taking address of packed member of ‘struct rpc_t’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 692 |nfs3_get_attributes_offset(rpc_pkt.u.reply.data); | ~~~^ Best regards Heinrich ___ 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] U-Boot: Environment flags broken for U-Boot
On Tue, Sep 3, 2019 at 3:05 AM Wolfgang Denk wrote: > > Dear Tom, > > In message Heiko Schocher > wrote: > > > > I am just testing U-Boot Environment flags and they do not work anymore with > > current mainline U-Boot ... > ... > > reason is your commit: > > > > commit 7d4776545b0f8a8827e5d061206faf61c9ba6ea9 > > Author: Patrick Delaunay > > Date: Thu Apr 18 17:32:49 2019 +0200 > > > > env: solve compilation error in SPL > > > Looking into the history of this, I wonder if we could / should > have prevented this. > > As far as I can see, Patrick's patch series has not been reviewed by > others, probably because general intetest in STM32 is not that big > at the moment. I can see no Acked-by:, Reviewed-by: nor Tested-by: > tags - nothing. > > The whole patch series was then pulled from the u-boot-stm > repository. > > > However, there was not only STM related code in there. There were > changes to common code like the environment handling. common code > was changed without review and without testing. It seems this should be unacceptable even if it's in the area of interest. Isn't an Acked-by generally accepted as required? > Are there ways to prevent this? > > Yes, we can appeal to the custodians to be more careful, but I > assume they are already doing their best. It seems the diffstat should be a quick way to see this, so I would think not quite their best. Maybe a reminder / recommendation that it be reviewed by custodians? > It might have even been better if this had been a sub-system with a > clear maintainer, but there is no such person for the environment > code. > > How can we prevent this in the future? Is there any tooling around the MAINTAINERS file that can be used to reg-flag PRs that contain changes outside of the tree's area of effect? > Should we define "interested developers" for such areas that have no > custodian (the "Designated reviewer") entry in the MAINTAINERS file > could be used for this, for example)? I like that idea, though in this specific case I think there should be a maintainer for env. > Better ideas? > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > To make this work we'd need a patch, as nobody of us tests this. > - L. Poettering in https://bugs.freedesktop.org/show_bug.cgi?id=74589 > ___ > 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 3/4] env: add missing header file
On Mon, Aug 26, 2019 at 6:08 AM Pierre-Jean Texier wrote:
>
> Since commit af95f20 ("env: Create a new file for environment functions"),
> a new header file exists.
>
> So, this commit add a missing header file.
>
> Fixes:
>
> include/env.h:158:1: error: unknown type name ‘ulong’; did you mean ‘long’?
> ulong env_get_ulong(const char *name, int base, ulong default_val);
> ^
> long
> include/env.h:158:49: error: unknown type name ‘ulong’; did you mean ‘long’?
> ulong env_get_ulong(const char *name, int base, ulong default_val);
>
> Signed-off-by: Pierre-Jean Texier
> Tested-by: Joris Offouga
> Tested-by: Heiko Schocher
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] fw_env: fix build error
On Mon, Aug 26, 2019 at 6:08 AM Pierre-Jean Texier wrote:
>
> The following error appears:
>
> tools/env/fw_env.c:1149:25: error: lvalue required as unary ‘&’ operand
> rc = write(fd, _REDUND_OBSOLETE, sizeof(ENV_REDUND_OBSOLETE));
>
> Fixes: d3716dd ("env: Rename the redundancy flags")
>
> Signed-off-by: Pierre-Jean Texier
> Tested-by: Joris Offouga
> Tested-by: Heiko Schocher
> Suggested-by: Heiko Schocher
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] fw_env: remove duplicated definitions
On Mon, Aug 26, 2019 at 6:08 AM Pierre-Jean Texier wrote:
>
> Since commit d3716dd ("env: Rename the redundancy flags"), the
> definitions of ENV_REDUND_OBSOLETE & ENV_REDUND_ACTIVE was moved
> to env.h.
>
> Fixes:
>
> tools/env/fw_env.c:122:22: error: ‘ENV_REDUND_ACTIVE’ redeclared as different
> kind of symbol
> static unsigned char ENV_REDUND_ACTIVE = 1;
> ^
> In file included from tools/env/fw_env.c:13:
> include/env.h:63:2: note: previous definition of ‘ENV_REDUND_ACTIVE’ was here
> ENV_REDUND_ACTIVE = 1,
> ^
> tools/env/fw_env.c:127:22: error: ‘ENV_REDUND_OBSOLETE’ redeclared as
> different kind of symbol
> static unsigned char ENV_REDUND_OBSOLETE;
> ^~~
> In file included from tools/env/fw_env.c:13:
> include/env.h:62:2: note: previous definition of ‘ENV_REDUND_OBSOLETE’ was
> here
> ENV_REDUND_OBSOLETE = 0,
>
> Signed-off-by: Pierre-Jean Texier
> Tested-by: Joris Offouga
> Tested-by: Heiko Schocher
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] fw_env: remove duplicated definitions
On Fri, Aug 23, 2019 at 4:04 PM Pierre-Jean Texier wrote:
>
> Since commit d3716dd ("env: Rename the redundancy flags"), the
> definitions of ENV_REDUND_OBSOLETE & ENV_REDUND_ACTIVE was moved
> to env.h.
>
> Fixes:
>
> tools/env/fw_env.c:122:22: error: ‘ENV_REDUND_ACTIVE’ redeclared as different
> kind of symbol
> static unsigned char ENV_REDUND_ACTIVE = 1;
> ^
> In file included from tools/env/fw_env.c:13:
> include/env.h:63:2: note: previous definition of ‘ENV_REDUND_ACTIVE’ was here
> ENV_REDUND_ACTIVE = 1,
> ^
> tools/env/fw_env.c:127:22: error: ‘ENV_REDUND_OBSOLETE’ redeclared as
> different kind of symbol
> static unsigned char ENV_REDUND_OBSOLETE;
> ^~~
> In file included from tools/env/fw_env.c:13:
> include/env.h:62:2: note: previous definition of ‘ENV_REDUND_OBSOLETE’ was
> here
> ENV_REDUND_OBSOLETE = 0,
>
> Signed-off-by: Pierre-Jean Texier
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, socfpga-stmmac
On Mon, Aug 19, 2019 at 1:43 PM Ralph Siemsen wrote: > > The same compatible = "altr,socfpga-stmmac" appears in both > drivers/net/designware.c and drivers/net/dwmac_socfgpa.c, > creating ambiguity in which driver will be bound. > > For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver. > So drop the compatible string from designware.c. > > Signed-off-by: Ralph Siemsen Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, socfpga-stmmac
On Tue, Aug 20, 2019 at 3:07 AM Alexey Brodkin wrote: > > Hi Ralph, > > > -Original Message- > > From: Ralph Siemsen > > Sent: Monday, August 19, 2019 9:43 PM > > To: u-boot@lists.denx.de; Joe Hershberger ; Alexey > > Brodkin > > ; Vlad Zakharov > > Cc: Ralph Siemsen > > Subject: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac > > > > The same compatible = "altr,socfpga-stmmac" appears in both > > drivers/net/designware.c and drivers/net/dwmac_socfgpa.c, > > creating ambiguity in which driver will be bound. > > > > For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver. > > So drop the compatible string from designware.c. > > > > Signed-off-by: Ralph Siemsen > > --- > > This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts. > > Maintainers of those boards have been copied, kindly review. > > Thanks for this clean-up. > > Speaking about AXS10x board where we do have DW GMAC > I cannot recall the reason I chose to use "altr,socfpga-stmmac" > for the board here [1] 3 years ago. > > But given we don't have any special quirks implemented whatever > is the most generic DW GMAC compatible string is should be good for us. > > Joe, could you please suggest if we need to use just "st,stm32-dwmac" > or add our own compatible as the ASIC is not from ST obviously but > an FPGA with Synopsys ARC SoC? I think we should only be using what Linux does, so I'm afraid I have to defer to what exists in the DTs there. -Joe > [1] > https://gitlab.denx.de/u-boot/u-boot/commit/fb2dea60e8f355ae00d427db09112a90839c96ec > > -Alexey > ___ > 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] drivers: net: fsl_enet_mdio: fix missing terminator in PCI ID array
On Wed, Aug 7, 2019 at 11:33 AM Alex Marginean wrote: > > It was missing in the original submission and not having it in place causes > issues with probing of PCI devices. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] doc: pcap: add pcap cmd documentation
On Thu, Jul 18, 2019 at 1:44 PM Ramon Fried wrote: > > Add documentation for new "pcap" command. > > Signed-off-by: Ramon Fried > > --- > > Changes in v4: > * Document the new $pcapsize environment variable. > * update doc regarding error message when there's not > enough memory left. > > Changes in v3: None > Changes in v2: None I guess we can figure out the sandbox testing later. Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] net: phy: mv88E61xx: add config option for mv88E6071 support
On Mon, Jul 29, 2019 at 6:17 PM Joe Hershberger wrote: > > On Thu, Jul 25, 2019 at 4:42 PM Anatolij Gustschin wrote: > > > > On Tue, 23 Jul 2019 04:26:17 + > > Joe Hershberger joe.hershber...@ni.com wrote: > > ... > > > > +config MV88E61XX_88E6020_FAMILY > > > > + bool "Marvell MV88E6020 family support." > > > > + help > > > > + The driver supports 6172/6176/6240/6352 devices in the > > > > + default configuration. Select this option to enable support > > > > + for 6250/6220/6020/6070/6071 switches. > > > > > > Is there a rhyme or reason to the model numbers here? This option > > > seems oddly named, especially since the help doesn't have the model > > > numbers in numerical order. Can you make it a choice instead? > > > > We want to be able to use single U-Boot images which support different > > switches, a choice will make it not possible. > > I don't see how choice is any different than what you have here in > that respect. You have a hard-coded selection among families. If you > have a need to run the same binary on multiple switches, then this > option should be removed and the pre-init should be detecting the > target. Any response here? > > -Joe > > > > > -- > > Anatolij > > ___ > > 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 2/2] net: dwc_et_qos: update weak function board_interface_eth_init
On Thu, Aug 1, 2019 at 4:32 AM Patrick Delaunay wrote: > > Align the board and driver prototype for board_interface_eth_init > to avoid execution issue (the interface_type parameter is defined > as int or phy_interface_t). > > To have a generic weak function (it should be reused by other driver) > I change the prototype to use directly udevice. > > This prototype is added in netdev.h to allow compilation check > and avoid warning when compiling with W=1 on file > board/st/stm32mp1/stm32mp1.c > > warning: no previous prototype for 'board_interface_eth_init'\ > [-Wmissing-prototypes] > int board_interface_eth_init(int interface_type, > ^~~~ > > Signed-off-by: Patrice Chotard > Signed-off-by: Patrick Delaunay Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: macb: Fix rx buffer cache handling
On Mon, Aug 26, 2019 at 2:18 AM Stefan Roese wrote:
>
> With commit c6d07bf440bc ("net/macb: increase RX buffer size for GEM")
> ethernet support does not work any more with d-cache enabled on the
> AT91SAM. The reason is, that MACB_RX_BUFFER_SIZE was changed from 4096
> to 128 but this change was not refected in the rx_buffer flush and
> invalidate functions, as these also use this macro.
>
> This patch now fixes this by calculating the rx buffer size correctly
> again in those functions. With this change, ethernet works again
> reliably on my AT91SAM board.
>
> Signed-off-by: Stefan Roese
> Fixes: c6d07bf440bc ("net/macb: increase RX buffer size for GEM")
> Cc: Ramon Fried
> Cc: Eugen Hristev
> Cc: Anup Patel
> Cc: Bin Meng
> Cc: Joe Hershberger
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: make net_random_ethaddr() more random
On Tue, Aug 27, 2019 at 3:14 AM Michael Walle wrote: > > The net_random_ethaddr() tries to get some entropy from different > startup times of a board. The seed is initialized with get_timer() which > has only a granularity of milliseconds. We can do better if we use > get_ticks() which returns the raw timer ticks. Using this we have a > higher chance of getting different values at startup. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode
This change tries to fix the following problem:
- The board boots (to be more precise - ROM loads SPL) from a slow SPI-NOR
memory.
As a result the spl_boot_device() will return SPI-NOR as a boot device
(which is correct).
- The problem is that in 'falcon boot' the eMMC is used as a boot medium to
load kernel from its partition.
Calling spl_boot_device() will break things as it returns SPI-NOR device.
To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig flag is
introduced to handle this special use case. By default it is not defined,
so there is no change in the legacy code flow.
Signed-off-by: Lukasz Majewski
---
This patch is a follow up of previous discussion/fix:
https://patchwork.ozlabs.org/patch/796237/
Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/580272414
---
arch/arm/mach-imx/spl.c | 11 +++
common/spl/Kconfig | 7 +++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1f230aca3397..daa3d8f7ed94 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -178,7 +178,18 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
/* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
u32 spl_boot_mode(const u32 boot_device)
{
+/*
+ * When CONFIG_SPL_FORCE_MMC_BOOT is defined the 'boot_device' is used
+ * unconditionally to decide about device to use for booting.
+ * This is crucial for falcon boot mode, when board boots up (i.e. ROM
+ * loads SPL) from slow SPI-NOR memory and afterwards the SPL's 'falcon' boot
+ * mode is used to load Linux OS from eMMC partition.
+ */
+#ifdef CONFIG_SPL_FORCE_MMC_BOOT
+ switch (boot_device) {
+#else
switch (spl_boot_device()) {
+#endif
/* for MMC return either RAW or FAT mode */
case BOOT_DEVICE_MMC1:
case BOOT_DEVICE_MMC2:
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index f467eca2be72..3460beb62d59 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -607,6 +607,13 @@ config SPL_MMC_SUPPORT
this option to build the drivers in drivers/mmc as part of an SPL
build.
+config SPL_FORCE_MMC_BOOT
+ bool "Force SPL's falcon boot from MMC"
+ depends on SPL_MMC_SUPPORT
+ default n
+ help
+ Force SPL's falcon boot to use MMC device for Linux kernel booting.
+
config SPL_MMC_TINY
bool "Tiny MMC framework in SPL"
depends on SPL_MMC_SUPPORT
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] net: nfs: -Werror=address-of-packed-member
Hi Heinrich, On Mon, Sep 2, 2019 at 4:39 PM Heinrich Schuchardt wrote: > > Hello Joe, > > GCC 9.2.1 (of Debian Bullseye) produces the warnings below when building > pine64-lts_defconfig. Is it really necessary to define struct rpc_t as > packed? The structure is composed out of uint32_t only. So shouldn't it > be naturally packed without the attribute? I guess this won't cuase problems on 64-bit with the union sharing memory, right? > > net/nfs.c: In function ‘rpc_req’: > net/nfs.c:199:18: error: taking address of packed member of ‘struct > rpc_t’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] >199 | p = (uint32_t *)&(rpc_pkt.u.call.data); >| ^~ > net/nfs.c: In function ‘nfs_readlink_reply’: > net/nfs.c:631:46: error: taking address of packed member of ‘struct > rpc_t’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] >631 |nfs3_get_attributes_offset(rpc_pkt.u.reply.data); >| ~~~^ >LD drivers/block/built-in.o > net/nfs.c: In function ‘nfs_read_reply’: > net/nfs.c:692:46: error: taking address of packed member of ‘struct > rpc_t’ may result in an unaligned pointer value > [-Werror=address-of-packed-member] >692 |nfs3_get_attributes_offset(rpc_pkt.u.reply.data); >| ~~~^ > > Best regards > > Heinrich > ___ > 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 1/1] net: nfs: remove superfluous conversions
On Mon, Sep 2, 2019 at 4:55 PM Heinrich Schuchardt wrote: > > rpc_pkt.u.call.data is an array of uint32_t. There is no need to convert > it to uint32_t *. > > memcpy() expects void * as it 1st and 2nd argument. There is no point in > converting pointers to char * before passing them to memcpy(). > > In ntohl(data[1]) != 0 calling ntohl() is superfluous. If the value is > zero, does not depend on the byte order. > > Signed-off-by: Heinrich Schuchardt Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] env: net: U_BOOT_ENV_CALLBACKs should not depend on CMD_NET
Hi Heinrich, On Mon, Sep 2, 2019 at 3:11 AM Heinrich Schuchardt wrote: > > Some environment variables are relevant for networking. For these > U_BOOT_ENV_CALLBACKs have been defined. When the corresponding environment > variable is updated the callback updates the state of the network > sub-system. > > In the UEFI subsystem we can use the network even if CONFIG_CMD_NET is not > defined. > > Let the usage of the U_BOOT_ENV_CALLBACKs depend on CONFIG_NET and not on > CONFIG_CMD_NET. > > Signed-off-by: Heinrich Schuchardt Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: env: extend "env [set|print] -e" to manage UEFI variables
On 9/3/19 7:41 AM, AKASHI Takahiro wrote:
With this patch, when setting UEFI variable with "env set -e" command,
we will be able to
- specify vendor guid with "-guid guid",
- specify variable attributes, BOOTSERVICE_ACCESS, RUNTIME_ACCESS,
TIME_BASED_AUTHENTICATED_WRITE_ACCESS respectively with
Doesn't TIME_BASED_AUTHENTICATED_WRITE_ACCESS mandate changes in
SetVariable() too?
I could not find the EFI_VARIABLE_AUTHENTICATION_2 descriptor in the patch.
I think we should not provide "-at" as a parameter of this command if it
is not supported. So there should be first a patch to change
SetVariable(). Then a patch implementing efidebug -at may follow.
In a case of an error, please, provide a meaningful error message. (A
variable might be READ_ONLY or NOT_FOUND. -rt might be specified without
-bs.)
Best regards
Heinrich
"-bs", "-rt" and "-at",
- append a value instead of overwriting with "-a",
- use memory as variable's value instead of explicit values given
at the command line with "-i address,size"
If guid is not explicitly given, default value will be used.
When "-at" is given, a variable should be authenticated with
appropriate signature database before setting or modifying its value.
(Authentication is not supported yet though.)
Meanwhile, "env print -e," will be modified so that it will dump
a variable's value only if '-v' (verbose) is specified.
Signed-off-by: AKASHI Takahiro
---
cmd/nvedit.c | 20 +++--
cmd/nvedit_efi.c | 192 ++-
2 files changed, 172 insertions(+), 40 deletions(-)
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 1cb0bc1460b9..2d2adc8529db 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -1387,7 +1387,7 @@ static char env_help_text[] =
#endif
"env print [-a | name ...] - print environment\n"
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "env print -e [name ...] - print UEFI environment\n"
+ "env print -e [-v] [name ...] - print UEFI environment\n"
#endif
#if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
@@ -1399,7 +1399,8 @@ static char env_help_text[] =
#endif
#endif
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "env set -e name [arg ...] - set UEFI variable; unset if 'arg' not
specified\n"
+ "env set -e [-nv][-bs][-rt][-at][-a][-i addr,size][-v] name [arg ...]\n"
+ "- set UEFI variable; unset if '-i' or 'arg' not specified\n"
#endif
"env set [-f] name [arg ...]\n";
#endif
@@ -1428,8 +1429,9 @@ U_BOOT_CMD_COMPLETE(
"print environment variables",
"[-a]\n- print [all] values of all environment variables\n"
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "printenv -e [name ...]\n"
+ "printenv -e [-v] [name ...]\n"
"- print UEFI variable 'name' or all the variables\n"
+ " \"-v\": verbose for signature database\n"
#endif
"printenv name ...\n"
"- print value of environment variable 'name'",
@@ -1459,9 +1461,17 @@ U_BOOT_CMD_COMPLETE(
setenv, CONFIG_SYS_MAXARGS, 0, do_env_set,
"set environment variables",
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "-e [-nv] name [value ...]\n"
+ "-e [-guid guid][-nv][-bs][-rt][-at][-a][-v]\n"
+ "[-i addr,size name], or [name [value ...]]\n"
"- set UEFI variable 'name' to 'value' ...'\n"
- " 'nv' option makes the variable non-volatile\n"
+ " \"-guid\": set vendor guid\n"
+ " \"-nv\": set non-volatile attribute\n"
+ " \"-bs\": set boot-service attribute\n"
+ " \"-rt\": set runtime attribute\n"
+ " \"-at\": set time-based authentication attribute\n"
+ " \"-a\": append-write\n"
+ " \"-i addr,size\": use as variable's value\n"
+ " \"-v\": verbose print\n"
"- delete UEFI variable 'name' if 'value' not specified\n"
#endif
"setenv [-f] name value ...\n"
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index ed6d09a53046..a9ecb3ee4dc3 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
/*
@@ -34,15 +35,48 @@ static const struct {
{EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, "AT"},
};
+static const struct {
+ efi_guid_t guid;
+ char *text;
+} efi_guid_text[] = {
+ /* signature database */
+ {EFI_GLOBAL_VARIABLE_GUID, "EFI_GLOBAL_VARIABLE_GUID"},
+};
+
+/* "----" */
+static char unknown_guid[37];
+
+/**
+ * efi_guid_to_str() - convert guid to readable name
+ *
+ * @guid: GUID
+ * Return: string for GUID
+ *
+ * convert guid to readable name
+ */
+static const char *efi_guid_to_str(efi_guid_t *guid)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(efi_guid_text); i++)
+ if (!guidcmp(guid, _guid_text[i].guid))
+ return efi_guid_text[i].text;
+
+
Re: [U-Boot] [PATCH] spl: mmc: Add option to set eMMC HW boot partition
Hi Marek, > On 9/3/19 5:49 PM, Lukasz Majewski wrote: > > Hi Måns, Marek, > > > >> Marek Vasut writes: > >> > >>> On 9/3/19 4:16 PM, Lukasz Majewski wrote: > From: Mans Rullgard > > This change allows setting pre-defined eMMC boot partition for > SPL eMMC booting. It is necessary in the case when one wants to > boot (through falcon boot) from eMMC after loading SPL from other > memory (like SPI-NOR). > > Signed-off-by: Mans Rullgard > [lukma: Edit the commit message] > Signed-off-by: Lukasz Majewski > Acked-by: Andreas Dannenberg > >>> > >>> Would it be better if this came from /chosen node in DT ? > >> > >> This patch was made for an imx28 based board. Fitting DT support > >> into SPL on that chip won't be easy. > > > > Unfortunately, on purpose the DT support for SPL on this board is > > disabled. > > > > This is the case where the only eligible option is to use > > OF_PLATDATA, to benefit from DM drivers, but also to keep the size > > as small as possible. > > > > (Please refer to xea board support patches for more details). > > Hm, then shall we use platdata ? Yes, correct. The OF_PLATDATA allows you to use DM/DTS converted driver with platform data encoded in the C structures. For example such patch adds support for OF_PLATDATA to DM/DTS driver: https://patchwork.ozlabs.org/patch/1148906/ > I don't think that fits common code > like this either. Please see above link. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpgrwJaphLp3.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: variable: support APPEND_WRITE
On 9/3/19 7:40 AM, AKASHI Takahiro wrote:
If EFI_VARIABLE_APPEND_WRITE is specified in attributes at
efi_set_variable(), specified data will be appended to the variable's
original value. Attributes other than APPEND_WRITE should not be
modified.
With this patch, APPEND_WRITE test in 'variables' selftest will pass.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/efi_variable.c | 50 +--
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6687b69a400d..5d1ee50a606e 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -423,18 +423,17 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
const efi_guid_t *vendor, u32 attributes,
efi_uintn_t data_size, const void *data)
{
- char *native_name = NULL, *val = NULL, *s;
+ char *native_name = NULL, *oval, *val = NULL, *s;
Please, use old_val install of oval.
+ size_t oval_size;
Please, use old_val_size.
efi_status_t ret = EFI_SUCCESS;
u32 attr;
EFI_ENTRY("\"%ls\" %pUl %x %zu %p", variable_name, vendor, attributes,
data_size, data);
- /* TODO: implement APPEND_WRITE */
if (!variable_name || !*variable_name || !vendor ||
((attributes & EFI_VARIABLE_RUNTIME_ACCESS) &&
-!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)) ||
- (attributes & EFI_VARIABLE_APPEND_WRITE)) {
+!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS))) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
Append with data_size = 0 should not delete the variable. See UEFI 2.8 spec.
If a variable does not exist, trying to delete it should return
EFI_NOT_FOUND.
If a variable is READ_ONLY we have to return EFI_WRITE_PROTECTED and
should not delete it.
I know these deficiencies are not caused by your patch. But as you are
touching the code now, could you, please, consider them.
@@ -452,28 +451,37 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
goto out;
}
- val = env_get(native_name);
- if (val) {
- parse_attr(val, );
+ oval = env_get(native_name);
+ if (oval) {
+ oval = parse_attr(oval, );
- /* We should not free val */
- val = NULL;
if (attr & READ_ONLY) {
ret = EFI_WRITE_PROTECTED;
goto out;
}
- /*
-* attributes won't be changed
-* TODO: take care of APPEND_WRITE once supported
-*/
- if (attr != attributes) {
+ /* attributes won't be changed */
+ if (attr != (attributes & ~EFI_VARIABLE_APPEND_WRITE)) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
+
+ if (attributes & EFI_VARIABLE_APPEND_WRITE) {
+ if (!prefix(oval, "(blob)")) {
+ /* TODO: should support utf8? */
If the variable is read_only we should not append to it but return
EFI_WRITE_PROTECTED.
We never stored any data as utf8. We can eliminate all references to the
(utf8) prefix in a future patch.
In lib/efi_selftest/efi_selftest_variables.c we already have a test for
APPEND. We should change the efi_st_todo() into efi_st_error() in a
follow-up patch.
Thanks for taking care of this gap.
Best regards
Heinrich
+ return EFI_DEVICE_ERROR;
+ goto out;
+ }
+ oval_size = strlen(oval);
+ } else {
+ oval_size = 0;
+ }
+ } else {
+ oval_size = 0;
}
- val = malloc(2 * data_size + strlen("{ro,run,boot,nv}(blob)") + 1);
+ val = malloc(oval_size + 2 * data_size
++ strlen("{ro,run,boot,nv}(blob)") + 1);
if (!val) {
ret = EFI_OUT_OF_RESOURCES;
goto out;
@@ -481,10 +489,7 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
s = val;
- /*
-* store attributes
-* TODO: several attributes are not supported
-*/
+ /* store attributes */
attributes &= (EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS);
@@ -505,8 +510,13 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
}
s += sprintf(s, "}");
+ if (oval_size)
+ /* APPEND_WRITE */
+ s += sprintf(s, oval);
+ else
+ s += sprintf(s, "(blob)");
+
/* store payload: */
- s += sprintf(s, "(blob)");
s = bin2hex(s,
[U-Boot] [PATCH v2] patman: Use the Change-Id, version, and prefix in the Message-Id
As per the centithread on ksummit-discuss [1], there are folks who
feel that if a Change-Id is present in a developer's local commit that
said Change-Id could be interesting to include in upstream posts.
Specifically if two commits are posted with the same Change-Id there's
a reasonable chance that they are either the same commit or a newer
version of the same commit. Specifically this is because that's how
gerrit has trained people to work.
There is much angst about Change-Id in upstream Linux, but one thing
that seems safe and non-controversial is to include the Change-Id as
part of the string of crud that makes up a Message-Id.
Let's give that a try.
In theory (if there is enough adoption) this could help a tool more
reliably find various versions of a commit. This actually might work
pretty well for U-Boot where (I believe) quite a number of developers
use patman, so there could be critical mass (assuming that enough of
these people also use a git hook that adds Change-Id to their
commits). I was able to find this git hook by searching for "gerrit
change id git hook" in my favorite search engine.
In theory one could imagine something like this could be integrated
into other tools, possibly even git-send-email. Getting it into
patman seems like a sane first step, though.
NOTE: this patch is being posted using a patman containing this patch,
so you should be able to see the Message-Id of this patch and see that
it contains my local Change-Id, which ends in 2b9 if you want to
check.
[1]
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Add a "v" before the version part of the Message-Id
- Reorder the parts of the Message-Id as per Johannes.
tools/patman/README | 8 +-
tools/patman/commit.py | 3 ++
tools/patman/patchstream.py | 57 +++--
3 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/tools/patman/README b/tools/patman/README
index 7917fc8bdc33..02d582974495 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -259,12 +259,18 @@ Series-process-log: sort, uniq
unique entries. If omitted, no change log processing is done.
Separate each tag with a comma.
+Change-Id:
+ This tag is stripped out but is used to generate the Message-Id
+ of the emails that will be sent. When you keep the Change-Id the
+ same you are asserting that this is a slightly different version
+ (but logically the same patch) as other patches that have been
+ sent out with the same Change-Id.
+
Various other tags are silently removed, like these Chrome OS and
Gerrit tags:
BUG=...
TEST=...
-Change-Id:
Review URL:
Reviewed-on:
Commit-: (except Commit-notes)
diff --git a/tools/patman/commit.py b/tools/patman/commit.py
index 2bf3a0ba5b92..48d0529c5365 100644
--- a/tools/patman/commit.py
+++ b/tools/patman/commit.py
@@ -21,6 +21,8 @@ class Commit:
The dict is indexed by change version (an integer)
cc_list: List of people to aliases/emails to cc on this commit
notes: List of lines in the commit (not series) notes
+change_id: the Change-Id: tag that was stripped from this commit
+and can be used to generate the Message-Id.
"""
def __init__(self, hash):
self.hash = hash
@@ -30,6 +32,7 @@ class Commit:
self.cc_list = []
self.signoff_set = set()
self.notes = []
+self.change_id = None
def AddChange(self, version, info):
"""Add a new change line to the change list for a version.
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index b6455b0fa383..2dd6a778d4ff 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -2,6 +2,7 @@
# Copyright (c) 2011 The Chromium OS Authors.
#
+import datetime
import math
import os
import re
@@ -14,7 +15,7 @@ import gitutil
from series import Series
# Tags that we detect and remove
-re_remove = re.compile('^BUG=|^TEST=|^BRANCH=|^Change-Id:|^Review URL:'
+re_remove = re.compile('^BUG=|^TEST=|^BRANCH=|^Review URL:'
'|Reviewed-on:|Commit-\w*:')
# Lines which are allowed after a TEST= line
@@ -32,6 +33,9 @@ re_cover_cc = re.compile('^Cover-letter-cc: *(.*)')
# Patch series tag
re_series_tag = re.compile('^Series-([a-z-]*): *(.*)')
+# Change-Id will be used to generate the Message-Id and then be stripped
+re_change_id = re.compile('^Change-Id: *(.*)')
+
# Commit series tag
re_commit_tag = re.compile('^Commit-([a-z-]*): *(.*)')
@@ -156,6 +160,7 @@ class PatchStream:
# Handle state transition and skipping blank lines
series_tag_match = re_series_tag.match(line)
+change_id_match = re_change_id.match(line)
commit_tag_match = re_commit_tag.match(line)
cover_match = re_cover.match(line)
cover_cc_match = re_cover_cc.match(line)
@@ -177,7 +182,7 @@ class
Re: [U-Boot] [PATCH v3 2/2] x86: efi_loader: Use efi_add_conventional_memory_map()
On 9/3/19 7:43 PM, Park, Aiden wrote: Use efi_add_conventional_memory_map() to configure EFI conventional memory properly with ram_top value. This will give 32bit mode U-Boot proper conventional memory regions even if e820 has a entry which is greater than 32bit address space. Signed-off-by: Aiden Park Together with Bin's patch series for supporting >3GB (https://lists.denx.de/pipermail/u-boot/2019-August/382332.html) I see the following memory map on an 8GB qemu-x86_defconfig (CONFIG_CMD_EFIDEBUG=y): ==> efidebug memmap Type StartEnd Attributes == CONVENTIONAL -000a WB RESERVED 000a-0010 WB CONVENTIONAL 0010-becf4000 WB LOADER DATA becf4000-becf5000 WB BOOT DATAbecf5000-becf6000 WB RUNTIME DATA becf6000-bed07000 WB|RT BOOT DATAbed07000-bed09000 WB RESERVED bed09000-bed0a000 WB BOOT DATAbed0a000-bed0c000 WB RUNTIME DATA bed0c000-bed0d000 WB|RT LOADER DATA bed0d000-bff4f000 WB RUNTIME CODE bff4f000-bff5 WB|RT LOADER DATA bff5-c000 WB RESERVED e000-f000 WB BOOT DATA0001-00024000 WB Close to 3GB in low memory and 5 GB above the 4GB boundary. Tested-by: Heinrich Schuchardt Reviewed-by: Heinrich Schuchardt @Bin: If you plan to create a pull request for RC4, you can take both patches to avoid unnecessary dependencies. Otherwise I will try to get patch 1/2 into RC4. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply //RE: [PATCH 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length ch
On Thu, Aug 29, 2019 at 8:49 AM liucheng (G) wrote: > > Changes in v2: > - Add reported-by tag for patch 5/5 > -- > CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at > nfs_lookup_reply > > This patch adds a check to rpc_pkt.u.reply.data at nfs_lookup_reply. > > Signed-off-by: Cheng Liu > Reported-by: Fermín Serna Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply //RE: [PATCH 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length
On Thu, Aug 29, 2019 at 8:50 AM liucheng (G) wrote: > > Changes in v2: > - Add reported-by tag for patch 4/5 > -- > CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at > nfs_readlink_reply > > This patch adds a check to rpc_pkt.u.reply.data at nfs_readlink_reply. > > Signed-off-by: Cheng Liu > Reported-by: Fermín Serna Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] efi_loader: Extract adding a conventional memory in separate routine
On 9/3/19 7:43 PM, Park, Aiden wrote: Adding a conventional memory region to the memory map may require ram_top limitation and it can be also commonly used. Extract adding a conventional memory to the memory map in a separate routine for generic use. Signed-off-by: Aiden Park Tested with EDK2 SCT on qemu_arm64_defconfig. Tested-by: Heinrich Schuchardt Reviewed-by: Heinrich Schuchardt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply //RE: [PATCH 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded me
On Thu, Aug 29, 2019 at 8:50 AM liucheng (G) wrote: > > Changes in v2: > - Add reported-by tag for patch 3/5 > -- > CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length > check at nfs_read_reply > > This patch adds a check to rpc_pkt.u.reply.data at nfs_read_reply. > > Signed-off-by: Cheng Liu > Reported-by: Fermín Serna Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] CVE: net: fix unbounded memcpy of UDP packet//RE: [PATCH 1/5] CVE: net: fix unbounded memcpy of UDP packet
On Thu, Aug 29, 2019 at 8:48 AM liucheng (G) wrote: > > Changes in v2: > - Add reviewed-by and reported-by tags for patch 1/5 > -- > CVE: net: fix unbounded memcpy of UDP packet > > This patch adds a check to udp_len to fix unbounded memcpy for > CVE-2019-14192, CVE-2019-14193 and CVE-2019-14199. > > Signed-off-by: Cheng Liu > Reviewed-by: Simon Goldschmidt > Reported-by: Fermín Serna Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions //RE: [PATCH 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply h
On Thu, Aug 29, 2019 at 8:48 AM liucheng (G) wrote: > > Changes in v2: > - Add reported-by tag for patch 2/5 > -- > CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper > functions > > This patch adds a check to nfs_handler to fix buffer overflow for > CVE-2019-14197, > CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and > CVE-2019-14204. > > Signed-off-by: Cheng Liu > Reported-by: Fermín Serna Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request for UEFI sub-system for v2019.10-rc4 (2)
The following changes since commit d22c8be964a870f59d2fdab6c67cefa0c4799364: Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-09-01 13:33:12 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2019-10-rc4-2 for you to fetch changes up to cd41d618d3a99ba5d1c01317c89d56285c03a981: efi_loader: implement MCastIPtoMAC (2019-09-03 00:07:18 +0200) Gitlab CI and Travis CI showed no problem: https://travis-ci.org/xypron2/u-boot/builds/579993939 https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/597 Pull request for UEFI sub-system for v2019.10-rc4 (2) Fix UEFI specification compliance issues in the simple network protocol: * Correctly set and reset the interrupt status. * Support filling the header in the Transmit() service. * Correct the checking and setting of the network state. * Implement the MCastIPtoMAC() service. * Adjust the simple network protocol unit test. Enable unit testing of the UEFI sub-system on QEMU RISC-V. Heinrich Schuchardt (6): riscv: qemu: enable CONFIG_CMD_BOOTEFI_SELFTEST efi_loader: interrupts in simple network protocol efi_selftest: check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT efi_loader: EFI_SIMPLE_NETWORK.Transmit() fill header efi_loader: fix status management in network stack efi_loader: implement MCastIPtoMAC configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + include/efi_api.h| 2 + lib/efi_loader/efi_net.c | 184 +-- lib/efi_selftest/efi_selftest_snp.c | 64 ++-- 7 files changed, 216 insertions(+), 38 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] include/net.h: warning: 'eth_is_on_demand_init' defined but not used
Hi Heinrich, On Fri, Aug 30, 2019 at 12:21 PM Heinrich Schuchardt wrote: > > Hello Joe, > > compiling U-Boot creates dozens of warnings for include/net.h: > >CC arch/arm/lib/asm-offsets.s > In file included from include/common.h:342, > from lib/asm-offsets.c:14: > include/net.h:689:28: warning: always_inline function might not be > inlinable [-Wattributes] >689 | static __always_inline int eth_is_on_demand_init(void) >|^ > include/net.h:689:28: warning: 'eth_is_on_demand_init' defined but not > used [-Wunused-function] >HOSTCC scripts/dtc/srcpos.o > In file included from include/common.h:342, > from arch/arm/lib/asm-offsets.c:14: > include/net.h:689:28: warning: always_inline function might not be > inlinable [-Wattributes] >689 | static __always_inline int eth_is_on_demand_init(void) >|^ > include/net.h:689:28: warning: 'eth_is_on_demand_init' defined but not > used [-Wunused-function] > > Software used for building U-Boot: > > U-Boot HEAD, rpi_3_b_plus_defconfig > gcc (FreeBSD Ports Collection) 9.1.0 > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r351591 GENERIC arm64 > > Why should we create this function in every file that by chance includes > net.h? > > The function is only used in drivers/net/netconsole.c and net/net.c. > > One solution would be to create a dedicated include that is only > referenced in these two files. We could, but it might also be reasonable to allow the compiler the prerogative to inline it or not and just define it as a regular function that can be stripped by the linker. Thoughts? -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] efi_loader: Extract adding a conventional memory in separate routine
Adding a conventional memory region to the memory map may require ram_top
limitation and it can be also commonly used. Extract adding a conventional
memory to the memory map in a separate routine for generic use.
Signed-off-by: Aiden Park
---
Changes in v3:
* Split a single commit to two relevant commits
Changes in v2:
* Add efi_add_conventional_memory_map() for common code re-use
include/efi_loader.h| 4 ++
lib/efi_loader/efi_memory.c | 82 ++---
2 files changed, 54 insertions(+), 32 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 5298ea7997..00eba8afa4 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -478,6 +478,10 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
/* Adds a range into the EFI memory map */
efi_status_t efi_add_memory_map(uint64_t start, uint64_t pages, int
memory_type,
bool overlap_only_ram);
+/* Adds a conventional range into the EFI memory map */
+efi_status_t efi_add_conventional_memory_map(u64 ram_start, u64 ram_end,
+u64 ram_top);
+
/* Called by board init to initialize the EFI drivers */
efi_status_t efi_driver_init(void);
/* Called by board init to initialize the EFI memory map */
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index b5775e0399..83cbc9154f 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -655,6 +655,54 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
return EFI_SUCCESS;
}
+/**
+ * efi_add_conventional_memory_map() - add a RAM memory area to the map
+ *
+ * @ram_start: start address of a RAM memory area
+ * @ram_end: end address of a RAM memory area
+ * @ram_top: max address to be used as conventional memory
+ * Return: status code
+ */
+efi_status_t efi_add_conventional_memory_map(u64 ram_start, u64 ram_end,
+u64 ram_top)
+{
+ u64 pages;
+
+ /* Remove partial pages */
+ ram_end &= ~EFI_PAGE_MASK;
+ ram_start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+
+ if (ram_end <= ram_start) {
+ /* Invalid mapping */
+ return EFI_INVALID_PARAMETER;
+ }
+
+ pages = (ram_end - ram_start) >> EFI_PAGE_SHIFT;
+
+ efi_add_memory_map(ram_start, pages,
+ EFI_CONVENTIONAL_MEMORY, false);
+
+ /*
+* Boards may indicate to the U-Boot memory core that they
+* can not support memory above ram_top. Let's honor this
+* in the efi_loader subsystem too by declaring any memory
+* above ram_top as "already occupied by firmware".
+*/
+ if (ram_top < ram_start) {
+ /* ram_top is before this region, reserve all */
+ efi_add_memory_map(ram_start, pages,
+ EFI_BOOT_SERVICES_DATA, true);
+ } else if ((ram_top >= ram_start) && (ram_top < ram_end)) {
+ /* ram_top is inside this region, reserve parts */
+ pages = (ram_end - ram_top) >> EFI_PAGE_SHIFT;
+
+ efi_add_memory_map(ram_top, pages,
+ EFI_BOOT_SERVICES_DATA, true);
+ }
+
+ return EFI_SUCCESS;
+}
+
__weak void efi_add_known_memory(void)
{
u64 ram_top = board_get_usable_ram_top(0) & ~EFI_PAGE_MASK;
@@ -672,42 +720,12 @@ __weak void efi_add_known_memory(void)
/* Add RAM */
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
- u64 ram_end, ram_start, pages;
+ u64 ram_end, ram_start;
ram_start = (uintptr_t)map_sysmem(gd->bd->bi_dram[i].start, 0);
ram_end = ram_start + gd->bd->bi_dram[i].size;
- /* Remove partial pages */
- ram_end &= ~EFI_PAGE_MASK;
- ram_start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
-
- if (ram_end <= ram_start) {
- /* Invalid mapping, keep going. */
- continue;
- }
-
- pages = (ram_end - ram_start) >> EFI_PAGE_SHIFT;
-
- efi_add_memory_map(ram_start, pages,
- EFI_CONVENTIONAL_MEMORY, false);
-
- /*
-* Boards may indicate to the U-Boot memory core that they
-* can not support memory above ram_top. Let's honor this
-* in the efi_loader subsystem too by declaring any memory
-* above ram_top as "already occupied by firmware".
-*/
- if (ram_top < ram_start) {
- /* ram_top is before this region, reserve all */
- efi_add_memory_map(ram_start, pages,
- EFI_BOOT_SERVICES_DATA, true);
- } else if ((ram_top >= ram_start)
[U-Boot] [PATCH v3 2/2] x86: efi_loader: Use efi_add_conventional_memory_map()
Use efi_add_conventional_memory_map() to configure EFI conventional memory
properly with ram_top value. This will give 32bit mode U-Boot proper
conventional memory regions even if e820 has a entry which is greater than
32bit address space.
Signed-off-by: Aiden Park
---
Changes in v3:
* Split a single commit to two relevant commits
Changes in v2:
* Add efi_add_conventional_memory_map() for common code re-use
arch/x86/lib/e820.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c
index d6ae2c4e9d..26da4d2f27 100644
--- a/arch/x86/lib/e820.c
+++ b/arch/x86/lib/e820.c
@@ -41,14 +41,17 @@ void efi_add_known_memory(void)
{
struct e820_entry e820[E820MAX];
unsigned int i, num;
- u64 start, pages;
+ u64 start, pages, ram_top;
int type;
num = install_e820_map(ARRAY_SIZE(e820), e820);
+ ram_top = (u64)gd->ram_top & ~EFI_PAGE_MASK;
+ if (!ram_top)
+ ram_top = 0x1ULL;
+
for (i = 0; i < num; ++i) {
start = e820[i].addr;
- pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT;
switch (e820[i].type) {
case E820_RAM:
@@ -69,7 +72,15 @@ void efi_add_known_memory(void)
break;
}
- efi_add_memory_map(start, pages, type, false);
+ if (type == EFI_CONVENTIONAL_MEMORY) {
+ efi_add_conventional_memory_map(start,
+ start + e820[i].size,
+ ram_top);
+ } else {
+ pages = ALIGN(e820[i].size, EFI_PAGE_SIZE)
+ >> EFI_PAGE_SHIFT;
+ efi_add_memory_map(start, pages, type, false);
+ }
}
}
#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/2] x86: efi_loader: Fix invalid address return from efi_alloc()
This issue can be seen on 32bit operation when one of E820_RAM type entries is greater than 4GB memory space. The efi_alloc() finds a free memory in the conventional memory which is greater than 4GB. But, it does type cast to 32bit address space and eventually returns invalid address. Changes in v3: * Split a single commit to two relevant commits Changes in v2: * Add efi_add_conventional_memory_map() for common code re-use Aiden Park (2): efi_loader: Extract adding a conventional memory in separate routine x86: efi_loader: Use efi_add_conventional_memory_map() arch/x86/lib/e820.c | 17 ++-- include/efi_loader.h| 4 ++ lib/efi_loader/efi_memory.c | 82 ++--- 3 files changed, 68 insertions(+), 35 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] env: Add CONFIG_ENV_SUPPORT
Add a new flag CONFIG_ENV_SUPPORT to compile all
the environment features in U-Boot (attributes, callbacks
and flags). It is the equivalent of the 2 existing flags
- CONFIG_SPL_ENV_SUPPORT for SPL
- CONFIG_TPL_ENV_SUPPORT for TPL
This new configuration allows to use the macro
CONFIG_IS_ENABLED(ENV_SUPPORT) in the code without
issue and solves the regression introduced by
commit 7d4776545b0f ("env: solve compilation error
in SPL"); change_ok was always NULL in U-Boot.
Signed-off-by: Patrick Delaunay
---
cmd/Kconfig| 2 ++
env/Kconfig| 7 +++
env/Makefile | 11 ---
include/env_callback.h | 4
include/env_flags.h| 4
5 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 05872fa..f7a1b1f 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -465,6 +465,7 @@ config CMD_ENV_EXISTS
config CMD_ENV_CALLBACK
bool "env callbacks - print callbacks and their associated variables"
+ depends on ENV_SUPPORT
help
Some environment variable have callbacks defined by
U_BOOT_ENV_CALLBACK. These are called when the variable changes.
@@ -473,6 +474,7 @@ config CMD_ENV_CALLBACK
config CMD_ENV_FLAGS
bool "env flags -print variables that have non-default flags"
+ depends on ENV_SUPPORT
help
Some environment variables have special flags that control their
behaviour. For example, serial# can only be written once and cannot
diff --git a/env/Kconfig b/env/Kconfig
index 74db2f3..f0c5a7a 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -1,5 +1,12 @@
menu "Environment"
+config ENV_SUPPORT
+ bool "Support all environment features"
+ default y
+ help
+ Enable full environment support in U-Boot,
+ including attributes, callbacks and flags.
+
config ENV_IS_NOWHERE
bool "Environment is not stored"
default y if !ENV_IS_IN_EEPROM && !ENV_IS_IN_EXT4 && \
diff --git a/env/Makefile b/env/Makefile
index 90144d6..2a468ac 100644
--- a/env/Makefile
+++ b/env/Makefile
@@ -5,10 +5,11 @@
obj-y += common.o env.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
+
ifndef CONFIG_SPL_BUILD
-obj-y += attr.o
-obj-y += callback.o
-obj-y += flags.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
extra-$(CONFIG_ENV_IS_EMBEDDED) += embedded.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += embedded.o
@@ -19,10 +20,6 @@ obj-$(CONFIG_ENV_IS_IN_ONENAND) += onenand.o
obj-$(CONFIG_ENV_IS_IN_SATA) += sata.o
obj-$(CONFIG_ENV_IS_IN_REMOTE) += remote.o
obj-$(CONFIG_ENV_IS_IN_UBI) += ubi.o
-else
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
endif
obj-$(CONFIG_$(SPL_TPL_)ENV_IS_NOWHERE) += nowhere.o
diff --git a/include/env_callback.h b/include/env_callback.h
index 982c078..a757fe6 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -72,6 +72,10 @@
"serial#:serialno," \
CONFIG_ENV_CALLBACK_LIST_STATIC
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
void env_callback_init(struct env_entry *var_entry);
+#else
+static inline void env_callback_init(struct env_entry *var_entry) { }
+#endif
#endif /* __ENV_CALLBACK_H__ */
diff --git a/include/env_flags.h b/include/env_flags.h
index e5380f2..ec480e3 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -153,7 +153,11 @@ int env_flags_validate_env_set_params(char *name, char
*const val[], int count);
* When adding a variable to the environment, initialize the flags for that
* variable.
*/
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
void env_flags_init(struct env_entry *var_entry);
+#else
+static inline void env_flags_init(struct env_entry *var_entry) { }
+#endif
/*
* Validate the newval for to conform with the requirements defined by its
flags
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Add option to set eMMC HW boot partition
On 9/3/19 5:49 PM, Lukasz Majewski wrote: > Hi Måns, Marek, > >> Marek Vasut writes: >> >>> On 9/3/19 4:16 PM, Lukasz Majewski wrote: From: Mans Rullgard This change allows setting pre-defined eMMC boot partition for SPL eMMC booting. It is necessary in the case when one wants to boot (through falcon boot) from eMMC after loading SPL from other memory (like SPI-NOR). Signed-off-by: Mans Rullgard [lukma: Edit the commit message] Signed-off-by: Lukasz Majewski Acked-by: Andreas Dannenberg >>> >>> Would it be better if this came from /chosen node in DT ? >> >> This patch was made for an imx28 based board. Fitting DT support into >> SPL on that chip won't be easy. > > Unfortunately, on purpose the DT support for SPL on this board is > disabled. > > This is the case where the only eligible option is to use OF_PLATDATA, > to benefit from DM drivers, but also to keep the size as small as > possible. > > (Please refer to xea board support patches for more details). Hm, then shall we use platdata ? I don't think that fits common code like this either. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] x86: qemu: Report high memory in the E820 table
> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, August 29, 2019 2:53 AM
> To: Simon Glass ; Park, Aiden ;
> U-Boot Mailing List
> Cc: Heinrich Schuchardt
> Subject: [PATCH 4/4] x86: qemu: Report high memory in the E820 table
>
> Now that we are able to get the size of high memory from QEMU, report its
> memory range as usable ram.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/cpu/qemu/e820.c | 59 --
> --
> 1 file changed, 40 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/cpu/qemu/e820.c b/arch/x86/cpu/qemu/e820.c index
> e682486..a4136eb 100644
> --- a/arch/x86/cpu/qemu/e820.c
> +++ b/arch/x86/cpu/qemu/e820.c
> @@ -1,46 +1,67 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> + * QEMU x86 specific E820 table generation
> + *
> * (C) Copyright 2015 Miao Yan
> + * (C) Copyright 2019 Bin Meng
> */
>
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> unsigned int install_e820_map(unsigned int max_entries,
> struct e820_entry *entries)
> {
> - entries[0].addr = 0;
> - entries[0].size = ISA_START_ADDRESS;
> - entries[0].type = E820_RAM;
> + u64 high_mem_size;
> + int n = 0;
>
> - entries[1].addr = ISA_START_ADDRESS;
> - entries[1].size = ISA_END_ADDRESS - ISA_START_ADDRESS;
> - entries[1].type = E820_RESERVED;
> + entries[n].addr = 0;
> + entries[n].size = ISA_START_ADDRESS;
> + entries[n].type = E820_RAM;
> + n++;
> +
> + entries[n].addr = ISA_START_ADDRESS;
> + entries[n].size = ISA_END_ADDRESS - ISA_START_ADDRESS;
> + entries[n].type = E820_RESERVED;
> + n++;
>
> /*
>* since we use memalign(malloc) to allocate high memory for
>* storing ACPI tables, we need to reserve them in e820 tables,
>* otherwise kernel will reclaim them and data will be corrupted
>*/
> - entries[2].addr = ISA_END_ADDRESS;
> - entries[2].size = gd->relocaddr - TOTAL_MALLOC_LEN -
> ISA_END_ADDRESS;
> - entries[2].type = E820_RAM;
> + entries[n].addr = ISA_END_ADDRESS;
> + entries[n].size = gd->relocaddr - TOTAL_MALLOC_LEN -
> ISA_END_ADDRESS;
> + entries[n].type = E820_RAM;
> + n++;
>
> /* for simplicity, reserve entire malloc space */
> - entries[3].addr = gd->relocaddr - TOTAL_MALLOC_LEN;
> - entries[3].size = TOTAL_MALLOC_LEN;
> - entries[3].type = E820_RESERVED;
> + entries[n].addr = gd->relocaddr - TOTAL_MALLOC_LEN;
> + entries[n].size = TOTAL_MALLOC_LEN;
> + entries[n].type = E820_RESERVED;
> + n++;
> +
> + entries[n].addr = gd->relocaddr;
> + entries[n].size = qemu_get_low_memory_size() - gd->relocaddr;
> + entries[n].type = E820_RESERVED;
> + n++;
>
> - entries[4].addr = gd->relocaddr;
> - entries[4].size = gd->ram_size - gd->relocaddr;
> - entries[4].type = E820_RESERVED;
> + entries[n].addr = CONFIG_PCIE_ECAM_BASE;
> + entries[n].size = CONFIG_PCIE_ECAM_SIZE;
> + entries[n].type = E820_RESERVED;
> + n++;
>
> - entries[5].addr = CONFIG_PCIE_ECAM_BASE;
> - entries[5].size = CONFIG_PCIE_ECAM_SIZE;
> - entries[5].type = E820_RESERVED;
> + high_mem_size = qemu_get_high_memory_size();
> + if (high_mem_size) {
> + entries[n].addr = SZ_4G;
> + entries[n].size = high_mem_size;
> + entries[n].type = E820_RAM;
> + n++;
> + }
>
> - return 6;
> + return n;
> }
> --
> 2.7.4
Reviewed-by: Aiden Park
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: qemu: Support getting high memory size
> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, August 29, 2019 2:53 AM
> To: Simon Glass ; Park, Aiden ;
> U-Boot Mailing List
> Cc: Heinrich Schuchardt
> Subject: [PATCH 3/4] x86: qemu: Support getting high memory size
>
> At present only size of memory that is below 4GiB is retrieved from QEMU.
> Add a function that gets size of memory that is above 4GiB.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/cpu/qemu/dram.c | 27 +--
> arch/x86/include/asm/arch-qemu/qemu.h | 11 +++
> 2 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/cpu/qemu/dram.c b/arch/x86/cpu/qemu/dram.c index
> c29b073..6707b7b 100644
> --- a/arch/x86/cpu/qemu/dram.c
> +++ b/arch/x86/cpu/qemu/dram.c
> @@ -22,9 +22,24 @@ u32 qemu_get_low_memory_size(void)
> return ram * 1024;
> }
>
> +u64 qemu_get_high_memory_size(void)
> +{
> + u64 ram;
> +
> + outb(HIGH_HIGHRAM_ADDR, CMOS_ADDR_PORT);
> + ram = ((u64)inb(CMOS_DATA_PORT)) << 22;
> + outb(MID_HIGHRAM_ADDR, CMOS_ADDR_PORT);
> + ram |= ((u64)inb(CMOS_DATA_PORT)) << 14;
> + outb(LOW_HIGHRAM_ADDR, CMOS_ADDR_PORT);
> + ram |= ((u64)inb(CMOS_DATA_PORT)) << 6;
> +
> + return ram * 1024;
> +}
> +
> int dram_init(void)
> {
> gd->ram_size = qemu_get_low_memory_size();
> + gd->ram_size += qemu_get_high_memory_size();
> post_code(POST_DRAM);
>
> return 0;
> @@ -32,8 +47,16 @@ int dram_init(void)
>
> int dram_init_banksize(void)
> {
> + u64 high_mem_size;
> +
> gd->bd->bi_dram[0].start = 0;
> - gd->bd->bi_dram[0].size = gd->ram_size;
> + gd->bd->bi_dram[0].size = qemu_get_low_memory_size();
> +
> + high_mem_size = qemu_get_high_memory_size();
> + if (high_mem_size) {
> + gd->bd->bi_dram[1].start = SZ_4G;
> + gd->bd->bi_dram[1].size = high_mem_size;
> + }
>
> return 0;
> }
> @@ -48,5 +71,5 @@ int dram_init_banksize(void)
> */
> ulong board_get_usable_ram_top(ulong total_size) {
> - return gd->ram_size;
> + return qemu_get_low_memory_size();
> }
> diff --git a/arch/x86/include/asm/arch-qemu/qemu.h
> b/arch/x86/include/asm/arch-qemu/qemu.h
> index c98deb2..061735b 100644
> --- a/arch/x86/include/asm/arch-qemu/qemu.h
> +++ b/arch/x86/include/asm/arch-qemu/qemu.h
> @@ -32,6 +32,10 @@
> #define LOW_RAM_ADDR 0x34
> #define HIGH_RAM_ADDR0x35
>
> +#define LOW_HIGHRAM_ADDR 0x5b
> +#define MID_HIGHRAM_ADDR 0x5c
> +#define HIGH_HIGHRAM_ADDR0x5d
> +
> /* PM registers */
> #define PMBA 0x40
> #define PMREGMISC0x80
> @@ -44,4 +48,11 @@
> */
> u32 qemu_get_low_memory_size(void);
>
> +/**
> + * qemu_get_high_memory_size() - Get high memory size
> + *
> + * @return: size of memory above 4GiB
> + */
> +u64 qemu_get_high_memory_size(void);
> +
> #endif /* _ARCH_QEMU_H_ */
> --
> 2.7.4
Reviewed-by: Aiden Park
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] x86: qemu: Extract getting memory size to a separate routine
> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, August 29, 2019 2:53 AM
> To: Simon Glass ; Park, Aiden ;
> U-Boot Mailing List
> Cc: Heinrich Schuchardt
> Subject: [PATCH 2/4] x86: qemu: Extract getting memory size to a separate
> routine
>
> This extracts getting memory size logic in dram_init() to a separate routine
> qemu_get_low_memory_size(). No functional changes.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/cpu/qemu/dram.c | 9 +++--
> arch/x86/include/asm/arch-qemu/qemu.h | 7 +++
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/cpu/qemu/dram.c b/arch/x86/cpu/qemu/dram.c index
> 736c4c3..c29b073 100644
> --- a/arch/x86/cpu/qemu/dram.c
> +++ b/arch/x86/cpu/qemu/dram.c
> @@ -9,7 +9,7 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -int dram_init(void)
> +u32 qemu_get_low_memory_size(void)
> {
> u32 ram;
>
> @@ -19,7 +19,12 @@ int dram_init(void)
> ram |= ((u32)inb(CMOS_DATA_PORT)) << 6;
> ram += 16 * 1024;
>
> - gd->ram_size = ram * 1024;
> + return ram * 1024;
> +}
> +
> +int dram_init(void)
> +{
> + gd->ram_size = qemu_get_low_memory_size();
> post_code(POST_DRAM);
>
> return 0;
> diff --git a/arch/x86/include/asm/arch-qemu/qemu.h
> b/arch/x86/include/asm/arch-qemu/qemu.h
> index 100eb8e..c98deb2 100644
> --- a/arch/x86/include/asm/arch-qemu/qemu.h
> +++ b/arch/x86/include/asm/arch-qemu/qemu.h
> @@ -37,4 +37,11 @@
> #define PMREGMISC0x80
> #define PMIOSE (1 << 0)
>
> +/**
> + * qemu_get_low_memory_size() - Get low memory size
> + *
> + * @return: size of memory below 4GiB
> + */
> +u32 qemu_get_low_memory_size(void);
> +
> #endif /* _ARCH_QEMU_H_ */
> --
> 2.7.4
Reviewed-by: Aiden Park
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] spi: Convert CONFIG_DM_SPI* to CONFIG_$(SPL_TPL_)DM_SPI*
On Tue, Sep 03, 2019 at 05:56:36PM +0200, Lukasz Majewski wrote:
> Hi Tom,
>
> > On Fri, Aug 23, 2019 at 11:02:27PM +0200, Lukasz Majewski wrote:
> > > Hi Tom,
> > >
> > > > On Tue, Aug 13, 2019 at 03:47:31PM +0200, Lukasz Majewski wrote:
> > > > > This change allows more fine tuning of driver model based SPI
> > > > > support in SPL and TPL. It is now possible to explicitly
> > > > > enable/disable the DM_SPI support in SPL and TPL via Kconfig
> > > > > option.
> > > > >
> > > > > Before this change it was necessary to use:
> > > > > /* SPI Flash Configs */
> > > > > #if defined(CONFIG_SPL_BUILD)
> > > > > #undef CONFIG_DM_SPI
> > > > > #undef CONFIG_DM_SPI_FLASH
> > > > > #undef CONFIG_SPI_FLASH_MTD
> > > > > #endif
> > > > >
> > > > > in the ./include/configs/.h, which is error prone and
> > > > > shall be avoided when we strive to switch to Kconfig.
> > > > >
> > > > > The goal of this patch:
> > > > >
> > > > > Provide distinction for DM_SPI support in both U-Boot proper and
> > > > > SPL (TPL). Valid use case is when U-Boot proper wants to use
> > > > > DM_SPI, but SPL must still support non DM driver.
> > > > >
> > > > > Another use case is the conversion of non DM/DTS SPI driver to
> > > > > support DM/DTS. When such driver needs to work in both SPL and
> > > > > U-Boot proper, the distinction is needed in Kconfig (also if SPL
> > > > > version of the driver supports OF_PLATDATA).
> > > > >
> > > > > In the end of the day one would have to support following use
> > > > > cases (in single driver file - e.g. mxs_spi.c):
> > > > >
> > > > > - U-Boot proper driver supporting DT/DTS
> > > > > - U-Boot proper driver without DT/DTS support (deprecated)
> > > > > - SPL driver without DT/DTS support
> > > > > - SPL (and TPL) driver with DT/DTS (when the SoC has enough
> > > > > resources to run full blown DT/DTS)
> > > > > - SPL driver with DT/DTS and SPL_OF_PLATDATA (when one have
> > > > > constrained environment with no fitImage and OF_LIBFDT support).
> > > > >
> > > > > Some boards do require SPI support (with DM) in SPL (TPL) and
> > > > > some only have DM_SPI{_FLASH} defined to allow compiling SPL.
> > > > >
> > > > > This patch converts #ifdef CONFIG_DM_SPI* to #if
> > > > > CONFIG_IS_ENABLED(DM_SPI) and provides corresponding defines in
> > > > > Kconfig.
> > > > >
> > > > > Signed-off-by: Lukasz Majewski
> > > > > Tested-by: Adam Ford #da850-evm
> > > >
> > > > Sorry I didn't bisect down to which part of the series is doing
> > > > this, but I see problems with:
> > > > ls1046ardb_sdcard ls1046ardb_qspi_spl ls1043ardb_nand
> > > > ls1046aqds_tfa ls1046aq ds_nand ls1046ardb_qspi
> > > > ls1046aqds_sdcard_ifc ls1046aqds_SECURE_BOOT
> > > > ls1046aqds_sdcard_qspi ls1 046aqds_qspi ls1043ardb_sdcard
> > > > ls1043aqds_sdcard_ifc ls1046ardb_tfa ls1046ardb_tfa_SECURE_BOOT
> > > > ls1043aqds_nand ls1046aqds_lpuart ls1046ardb_emmc
> > > > ls1046aqds_tfa_SECURE_BOOT ls1046afrwy_tfa ls 1046aqds
> > > > ls1043ardb_nand_SECURE_BOOT ls1046ardb_qspi_SECURE_BOOT
> > > > ls1043aqds_sdcard_qspi
> > > >
> > > > Some of which are dependency problems about SPL/SPL_DM. I also
> > > > see: aarch64: (for 225/225 boards) all -294.2 bss -0.0 data -11.7
> > > > rodata -72.5 spl/u-boot-spl:all -0.3 spl/u-boot-spl:text -0.3 text
> > > > -210.0 [snip] ls1043ardb_nand: all -9435 data -376 rodata -2331
> > > > text -6728 ls1043ardb_sdcard: all -9435 data -376 rodata -2331
> > > > text -6728 ls1043aqds_sdcard_ifc: all -9435 data -376 rodata -2331
> > > > text -6728 ls1043aqds_nand: all -9435 data -376 rodata -2331 text
> > > > -6728 ls1043ardb_nand_SECURE_BOOT: all -9435 data -376 rodata
> > > > -2331 text -6728 ls1043ardb_sdcard_SECURE_BOOT: all -9435 data
> > > > -376 rodata -2331 text -6728 ls1043aqds_sdcard_qspi: all -9436
> > > > bss -8 data -376 rodata -2324 text -6728
> > > >
> > > > which I think means a few conversions weren't right.
> > >
> > > It looks like some parts of the SPL are not build
> >
> > Yes, there's some dependency problem Kconfig is spotting related to
> > SPL/SPL_DM.
> >
> > > Is the delta of size available from travis-CI or from any other
> > > script (maybe there is some buildman switch)?
> >
> > Yes, it's part of buildman. I do:
> > $ export SOURCE_DATE_EPOCH=`date +%s`
> > $ ./tools/buildman/buildman -o /tmp/test --step 0 -b origin/master..
> > --force-build -CveE $ ./tools/buildman/buildman -o /tmp/test --step
> > 0 -b origin/master.. -Ssdel
> >
> > to get size changes between point A and point Z in a branch, and omit
> > --step 0 when I need to see which patch in between them caused the
> > size change.
> >
>
> I cannot reproduce your results on current master branch:
> SHA1:d22c8be964a870f59d2fdab6c67cefa0c4799364
>
> for this series applied.
>
> echo $SOURCE_DATE_EPOCH
> 1567523778
>
> ./tools/buildman/buildman.py -b HEAD --count=3 ls1043
> --output-dir=../BUILD/ --force-build -CveE
>
> ./tools/buildman/buildman.py -b
[U-Boot] [PATCH v2 3/3] doc: lion_rk3368: use idbloader.img for rk3368
Makefile now produces ready-to-deploy idbloader.img file. Signed-off-by: Matwey V. Kornilov --- board/theobroma-systems/lion_rk3368/README | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/board/theobroma-systems/lion_rk3368/README b/board/theobroma-systems/lion_rk3368/README index 83e4332984..ad3ac93bd4 100644 --- a/board/theobroma-systems/lion_rk3368/README +++ b/board/theobroma-systems/lion_rk3368/README @@ -18,8 +18,6 @@ Build the TPL/SPL stage === > make CROSS_COMPILE=aarch64-unknown-elf- ARCH=arm - > tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img - > cat spl/u-boot-spl-dtb.bin >> spl-3368.img Build the full U-Boot and a FIT image including the ATF === @@ -35,7 +33,7 @@ Copy the SPL to offset 32k and the FIT image containing the payloads SD-Card --- - > dd if=spl-3368.img of=/dev/sdb seek=64 + > dd if=idbloader.img of=/dev/sdb seek=64 > dd if=u-boot.itb of=/dev/sdb seek=512 eMMC -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] rockchip, Makefile: add idbloader.img target
Many Rockchip platforms require the same u-boot deploy procedure when TPL and SPL both enabled. The following examples are taken from doc/README.rockchip and board/theobroma-systems/lion_rk3368/README: RK3288: ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out cat ./spl/u-boot-spl-dtb.bin >> out sudo dd if=out of=/dev/mmcblk0 seek=64 RK3328: ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img cat ./spl/u-boot-spl.bin >> idbloader.img sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 RK3368: ./tools/mkimage -n rk3368 -T rksd -d tpl/u-boot-tpl.bin spl-3368.img cat spl/u-boot-spl-dtb.bin >> spl-3368.img dd if=spl-3368.img of=/dev/sdb seek=64 RK3399: ./tools/mkimage -n rk3399 -T rksd -d ./tpl/u-boot-tpl-dtb.bin out cat ./spl/u-boot-spl-dtb.bin >> out sudo dd if=out of=/dev/sdc seek=64 Here, we introduce generic idbloader.img target which is the TPL image followed by the SPL binary. Signed-off-by: Matwey V. Kornilov Reviewed-by: Kever Yang --- Makefile | 12 1 file changed, 12 insertions(+) diff --git a/Makefile b/Makefile index 3b0864ae8e..eb12af9364 100644 --- a/Makefile +++ b/Makefile @@ -882,6 +882,10 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy) ALL-y += u-boot-with-dtb.bin endif +ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy) +ALL-y += idbloader.img +endif + LDFLAGS_u-boot += $(LDFLAGS_FINAL) # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards. @@ -1293,6 +1297,14 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE $(call if_changed,pad_cat) +ifeq ($(CONFIG_ARCH_ROCKCHIP),y) +MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd +tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE + $(call if_changed,mkimage) +idbloader.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE + $(call if_changed,cat) +endif + ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy) MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE) -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] doc: rockchip: use idbloader.img for rk3288, rk3328, rk3399
Makefile now produces ready-to-deploy idbloader.img file. Signed-off-by: Matwey V. Kornilov --- doc/README.rockchip | 21 ++--- 1 file changed, 2 insertions(+), 19 deletions(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index 7d4dc1b33b..6007f3321e 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -276,9 +276,7 @@ As of now TPL is added on Vyasa-RK3288 board. To write an image that boots from an SD card (assumed to be /dev/mmcblk0): - ./tools/mkimage -n rk3288 -T rksd -d ./tpl/u-boot-tpl.bin out && -cat ./spl/u-boot-spl-dtb.bin >> out && -sudo dd if=out of=/dev/mmcblk0 seek=64 && +sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 && sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 seek=16384 Booting from an SD card on RK3188 @@ -311,11 +309,6 @@ Booting from an SD card on Pine64 Rock64 (RK3328) For Rock64 rk3328 board the following three parts are required: TPL, SPL, and the u-boot image tree blob. - - Create TPL/SPL image - -=> tools/mkimage -n rk3328 -T rksd -d tpl/u-boot-tpl.bin idbloader.img -=> cat spl/u-boot-spl.bin >> idbloader.img - - Write TPL/SPL image at 64 sector => sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 @@ -474,19 +467,9 @@ Hit any key to stop autoboot: 0 Option 3: Package the image with TPL: - - Prefix rk3399 header to TPL image - -=> cd /path/to/u-boot -=> ./tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin out - - - Concatinate tpl with spl - -=> cd /path/to/u-boot -=> cat ./spl/u-boot-spl-dtb.bin >> out - - Write tpl+spl at 64th sector -=> sudo dd if=out of=/dev/sdc seek=64 +=> sudo dd if=idbloader.img of=/dev/sdc seek=64 - Write U-Boot proper at 16384 sector -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Introduce idbloader.img target for Makefile
Rockchip SoCs reqire the following deployment procedure for TPL/SPL: ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img cat ./spl/u-boot-spl-dtb.bin >> idbloader.img dd if=idbloader.img of=/dev/mmcblk0 seek=64 The series is organized as the following. First patch introduces idbloader.img target for Makefile. The rest is for keeping the documentation up-to-date. Changes since v2: - fix patch 5 - squash patches 2,3,5 into 2 Matwey V. Kornilov (3): rockchip, Makefile: add idbloader.img target doc: rockchip: use idbloader.img for rk3288, rk3328, rk3399 doc: lion_rk3368: use idbloader.img for rk3368 Makefile | 12 board/theobroma-systems/lion_rk3368/README | 4 +--- doc/README.rockchip| 21 ++--- 3 files changed, 15 insertions(+), 22 deletions(-) -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] cmd: pxe: Use internal FDT if retrieving from FDTDIR fails
On 9/3/19 1:52 AM, Anton Leontiev wrote:
From: Anton Leontiev
As FDTDIR label doesn't specify exact file to be loaded, it should
not fail if no file exists in the directory. In this case try to boot
with internal FDT if it exists.
Signed-off-by: Anton Leontiev
---
cmd/pxe.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/cmd/pxe.c b/cmd/pxe.c
index 2059975446..1eec6d29bf 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -727,11 +727,14 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
/*
* fdt usage is optional:
-* It handles the following scenarios. All scenarios are exclusive
+* It handles the following scenarios.
*
-* Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
-* pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
-* and adjust argc appropriately.
+* Scenario 1: If fdt_addr_r specified and "fdt" or "fdtdir" label is
+* defined in pxe file, retrieve fdt blob from server. Pass fdt_addr_r
to
+* bootm, and adjust argc appropriately.
+*
+* If retrieve fails and no exact fdt blob is specified in pxe file with
+* "fdt" label, try Scenario 2.
Is it possible/sensible to distinguish between "file not found" and
"error during retrieval"? "File not found" indicates the case you care
about, and continuing to use a built-in DT makes sense here. "Error
during retrieval" indicates that the file was found, and hence really
should be use, yet couldn't be due to download failure. In this case, I
wonder if we shouldn't outright fail this boot option, just like the
existing code does?
But either way, I suppose this patch is reasonable.
* Scenario 2: If there is an fdt_addr specified, pass it along to
* bootm, and adjust argc appropriately.
@@ -795,9 +798,13 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
int err = get_relfile_envaddr(cmdtp, fdtfile,
"fdt_addr_r");
free(fdtfilefree);
if (err < 0) {
- printf("Skipping %s for failure retrieving
fdt\n",
- label->name);
- goto cleanup;
+ bootm_argv[3] = NULL;
+
+ if (label->fdt) {
+ printf("Skipping %s for failure retrieving
FDT\n",
+ label->name);
+ goto cleanup;
+ }
}
} else {
bootm_argv[3] = NULL;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: pxe: Use internal FDT if external one cannot be retrieved
On 8/31/19 1:52 PM, Anton Leontiev wrote: чт, 29 авг. 2019 г. в 23:35, Stephen Warren : On 8/29/19 5:20 AM, Anton Leontiev wrote: 2019-08-26 at 18:59, Stephen Warren : We have a GNU/Linux distribution that use FDTDIR in its extlinux.conf to support several boards. But some boards have FDT embedded in U-Boot and it is't present in FDTDIR. In such configuration U-Boot fails to boot an entry, despite no exact FDT is specified in it. Distribution itself is designed to work on any board. I lookead at that referenced commit description in full and the code, and I believe what you want is for U-Boot to set fdt_addr to the location of the in-RAM DT, and leave fdt_addr_r unset. This will indicate to the pxe code that no FDT should be loaded when parsing extlinux.conf, but instead to use fdt_addr directly. Does that work for you, or does it break some other script/use-case on this board? Indeed, it's a possible option. However, if fdt_addr_r is not set, user can't override embedded FDT using extlinux.conf. README.distro says about fdt_addr_r: "This is mandatory even when fdt_addr is provided, since extlinux.conf must always be able to provide a DTB which overrides any copy provided by the HW." So it should be considered as a workaround rather than a solution. OK, I guess that makes sense. I suppose it's not reasonable to ask that extlinux.conf doesn't contain an FDTDIR statement in the case where the specific board has a built-in DT, since the extlinux.conf content is supposed to be generic, and not tailored to the current HW. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method
H Tom, [snip] > > > This is the patch with problem, and here is the link on patchwork: > > > https://patchwork.ozlabs.org/patch/1146845/ > > > > Please find my fixes here: > > https://patchwork.ozlabs.org/patch/1156541/ > > https://patchwork.ozlabs.org/patch/1156617/ > > > > Tom do we want https://patchwork.ozlabs.org/patch/1146845/ and fixes for it > > (see 2 items above) to become a part of upcoming v2019.10 release or > > it will be slated for the next one? > > I think we should aim to get all the fixes in for this release. Done, see https://lists.denx.de/pipermail/u-boot/2019-September/382628.html -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull ARC fixes for 2019.10-rc4
Hi Tom, The following changes since commit d22c8be964a870f59d2fdab6c67cefa0c4799364: Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-09-01 13:33:12 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-arc.git tags/arc-for-2019.10-rc4 for you to fetch changes up to 968b98bc27c2b228323c53761075422ebbb098bd: arc: emsdp: Add more platform-specific compiler options (2019-09-03 19:05:34 +0300) These are some very late changes mostly required to get 64-bit division working on ARC boards. For that we had to import missing parts of libgcc and add compiler flags to EMSDP which otherwise used very simple profile for compliation. And while at it another fix for EM SDP initialization is inluded as well. Alexey Brodkin (3): arc: emsdp: Add initialization of PSRAM arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit division arc: emsdp: Add more platform-specific compiler options arch/arc/lib/libgcc2.c | 75 +++ board/synopsys/emsdp/config.mk | 2 ++ board/synopsys/emsdp/emsdp.c | 37 + configs/emsdp_defconfig| 1 + 4 files changed, 115 insertions(+) create mode 100644 board/synopsys/emsdp/config.mk Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] spi: Convert CONFIG_DM_SPI* to CONFIG_$(SPL_TPL_)DM_SPI*
Hi Tom,
> On Fri, Aug 23, 2019 at 11:02:27PM +0200, Lukasz Majewski wrote:
> > Hi Tom,
> >
> > > On Tue, Aug 13, 2019 at 03:47:31PM +0200, Lukasz Majewski wrote:
> > > > This change allows more fine tuning of driver model based SPI
> > > > support in SPL and TPL. It is now possible to explicitly
> > > > enable/disable the DM_SPI support in SPL and TPL via Kconfig
> > > > option.
> > > >
> > > > Before this change it was necessary to use:
> > > > /* SPI Flash Configs */
> > > > #if defined(CONFIG_SPL_BUILD)
> > > > #undef CONFIG_DM_SPI
> > > > #undef CONFIG_DM_SPI_FLASH
> > > > #undef CONFIG_SPI_FLASH_MTD
> > > > #endif
> > > >
> > > > in the ./include/configs/.h, which is error prone and
> > > > shall be avoided when we strive to switch to Kconfig.
> > > >
> > > > The goal of this patch:
> > > >
> > > > Provide distinction for DM_SPI support in both U-Boot proper and
> > > > SPL (TPL). Valid use case is when U-Boot proper wants to use
> > > > DM_SPI, but SPL must still support non DM driver.
> > > >
> > > > Another use case is the conversion of non DM/DTS SPI driver to
> > > > support DM/DTS. When such driver needs to work in both SPL and
> > > > U-Boot proper, the distinction is needed in Kconfig (also if SPL
> > > > version of the driver supports OF_PLATDATA).
> > > >
> > > > In the end of the day one would have to support following use
> > > > cases (in single driver file - e.g. mxs_spi.c):
> > > >
> > > > - U-Boot proper driver supporting DT/DTS
> > > > - U-Boot proper driver without DT/DTS support (deprecated)
> > > > - SPL driver without DT/DTS support
> > > > - SPL (and TPL) driver with DT/DTS (when the SoC has enough
> > > > resources to run full blown DT/DTS)
> > > > - SPL driver with DT/DTS and SPL_OF_PLATDATA (when one have
> > > > constrained environment with no fitImage and OF_LIBFDT support).
> > > >
> > > > Some boards do require SPI support (with DM) in SPL (TPL) and
> > > > some only have DM_SPI{_FLASH} defined to allow compiling SPL.
> > > >
> > > > This patch converts #ifdef CONFIG_DM_SPI* to #if
> > > > CONFIG_IS_ENABLED(DM_SPI) and provides corresponding defines in
> > > > Kconfig.
> > > >
> > > > Signed-off-by: Lukasz Majewski
> > > > Tested-by: Adam Ford #da850-evm
> > >
> > > Sorry I didn't bisect down to which part of the series is doing
> > > this, but I see problems with:
> > > ls1046ardb_sdcard ls1046ardb_qspi_spl ls1043ardb_nand
> > > ls1046aqds_tfa ls1046aq ds_nand ls1046ardb_qspi
> > > ls1046aqds_sdcard_ifc ls1046aqds_SECURE_BOOT
> > > ls1046aqds_sdcard_qspi ls1 046aqds_qspi ls1043ardb_sdcard
> > > ls1043aqds_sdcard_ifc ls1046ardb_tfa ls1046ardb_tfa_SECURE_BOOT
> > > ls1043aqds_nand ls1046aqds_lpuart ls1046ardb_emmc
> > > ls1046aqds_tfa_SECURE_BOOT ls1046afrwy_tfa ls 1046aqds
> > > ls1043ardb_nand_SECURE_BOOT ls1046ardb_qspi_SECURE_BOOT
> > > ls1043aqds_sdcard_qspi
> > >
> > > Some of which are dependency problems about SPL/SPL_DM. I also
> > > see: aarch64: (for 225/225 boards) all -294.2 bss -0.0 data -11.7
> > > rodata -72.5 spl/u-boot-spl:all -0.3 spl/u-boot-spl:text -0.3 text
> > > -210.0 [snip] ls1043ardb_nand: all -9435 data -376 rodata -2331
> > > text -6728 ls1043ardb_sdcard: all -9435 data -376 rodata -2331
> > > text -6728 ls1043aqds_sdcard_ifc: all -9435 data -376 rodata -2331
> > > text -6728 ls1043aqds_nand: all -9435 data -376 rodata -2331 text
> > > -6728 ls1043ardb_nand_SECURE_BOOT: all -9435 data -376 rodata
> > > -2331 text -6728 ls1043ardb_sdcard_SECURE_BOOT: all -9435 data
> > > -376 rodata -2331 text -6728 ls1043aqds_sdcard_qspi: all -9436
> > > bss -8 data -376 rodata -2324 text -6728
> > >
> > > which I think means a few conversions weren't right.
> >
> > It looks like some parts of the SPL are not build
>
> Yes, there's some dependency problem Kconfig is spotting related to
> SPL/SPL_DM.
>
> > Is the delta of size available from travis-CI or from any other
> > script (maybe there is some buildman switch)?
>
> Yes, it's part of buildman. I do:
> $ export SOURCE_DATE_EPOCH=`date +%s`
> $ ./tools/buildman/buildman -o /tmp/test --step 0 -b origin/master..
> --force-build -CveE $ ./tools/buildman/buildman -o /tmp/test --step
> 0 -b origin/master.. -Ssdel
>
> to get size changes between point A and point Z in a branch, and omit
> --step 0 when I need to see which patch in between them caused the
> size change.
>
I cannot reproduce your results on current master branch:
SHA1:d22c8be964a870f59d2fdab6c67cefa0c4799364
for this series applied.
echo $SOURCE_DATE_EPOCH
1567523778
./tools/buildman/buildman.py -b HEAD --count=3 ls1043
--output-dir=../BUILD/ --force-build -CveE
./tools/buildman/buildman.py -b HEAD --count=3 ls1043
--output-dir=../BUILD/ -Ssdel
Just gives me some warnings (without the size difference):
aarch64: w+ ls1043aqds_nand ls1043ardb_nand
ls1043aqds_sdcard_qspi ls1043aqds_sdcard_ifc
ls1043ardb_nand_SECURE_BOOT ls1043ardb_sdcard
Re: [U-Boot] [PATCH] spl: mmc: Add option to set eMMC HW boot partition
Hi Måns, Marek, > Marek Vasut writes: > > > On 9/3/19 4:16 PM, Lukasz Majewski wrote: > >> From: Mans Rullgard > >> > >> This change allows setting pre-defined eMMC boot partition for SPL > >> eMMC booting. It is necessary in the case when one wants to boot > >> (through falcon boot) from eMMC after loading SPL from other > >> memory (like SPI-NOR). > >> > >> Signed-off-by: Mans Rullgard > >> [lukma: Edit the commit message] > >> Signed-off-by: Lukasz Majewski > >> Acked-by: Andreas Dannenberg > > > > Would it be better if this came from /chosen node in DT ? > > This patch was made for an imx28 based board. Fitting DT support into > SPL on that chip won't be easy. Unfortunately, on purpose the DT support for SPL on this board is disabled. This is the case where the only eligible option is to use OF_PLATDATA, to benefit from DM drivers, but also to keep the size as small as possible. (Please refer to xea board support patches for more details). > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpDBy3huo2T9.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] colibri_imx6: fix broken fsl_esdhc_imx conversion
On Tue, 2019-09-03 at 11:53 -0300, Ricardo Salveti wrote:
> Commit e37ac71 converted FSL_ESDHC to FSL_ESDHC_IMX, but the config
> check for colibri_imx6 wasn't updated accordantly.
>
> Signed-off-by: Ricardo Salveti
> ---
> board/toradex/colibri_imx6/colibri_imx6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/toradex/colibri_imx6/colibri_imx6.c
> b/board/toradex/colibri_imx6/colibri_imx6.c
> index ad40b589c1..44173dde1f 100644
> --- a/board/toradex/colibri_imx6/colibri_imx6.c
> +++ b/board/toradex/colibri_imx6/colibri_imx6.c
> @@ -83,7 +83,7 @@ iomux_v3_cfg_t const uart1_pads[] = {
> MX6_PAD_CSI0_DAT11__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
> };
>
> -#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
> +#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
> /* Colibri MMC */
> iomux_v3_cfg_t const usdhc1_pads[] = {
> MX6_PAD_SD1_CLK__SD1_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
> @@ -304,7 +304,7 @@ int board_ehci_hcd_init(int port)
> }
> #endif
>
> -#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
> +#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
> /* use the following sequence: eMMC, MMC */
> struct fsl_esdhc_cfg usdhc_cfg[CONFIG_SYS_FSL_USDHC_NUM] = {
> {USDHC3_BASE_ADDR},
Acked-by: Max Krummenacher
Thanks!
Max
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Add option to set eMMC HW boot partition
Marek Vasut writes: > On 9/3/19 4:16 PM, Lukasz Majewski wrote: >> From: Mans Rullgard >> >> This change allows setting pre-defined eMMC boot partition for SPL eMMC >> booting. It is necessary in the case when one wants to boot (through falcon >> boot) from eMMC after loading SPL from other memory (like SPI-NOR). >> >> Signed-off-by: Mans Rullgard >> [lukma: Edit the commit message] >> Signed-off-by: Lukasz Majewski >> Acked-by: Andreas Dannenberg > > Would it be better if this came from /chosen node in DT ? This patch was made for an imx28 based board. Fitting DT support into SPL on that chip won't be easy. -- Måns Rullgård ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Add option to set eMMC HW boot partition
On 9/3/19 4:16 PM, Lukasz Majewski wrote: > From: Mans Rullgard > > This change allows setting pre-defined eMMC boot partition for SPL eMMC > booting. It is necessary in the case when one wants to boot (through falcon > boot) from eMMC after loading SPL from other memory (like SPI-NOR). > > Signed-off-by: Mans Rullgard > [lukma: Edit the commit message] > Signed-off-by: Lukasz Majewski > Acked-by: Andreas Dannenberg Would it be better if this came from /chosen node in DT ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] colibri_imx6: fix broken fsl_esdhc_imx conversion
Commit e37ac71 converted FSL_ESDHC to FSL_ESDHC_IMX, but the config
check for colibri_imx6 wasn't updated accordantly.
Signed-off-by: Ricardo Salveti
---
board/toradex/colibri_imx6/colibri_imx6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/toradex/colibri_imx6/colibri_imx6.c
b/board/toradex/colibri_imx6/colibri_imx6.c
index ad40b589c1..44173dde1f 100644
--- a/board/toradex/colibri_imx6/colibri_imx6.c
+++ b/board/toradex/colibri_imx6/colibri_imx6.c
@@ -83,7 +83,7 @@ iomux_v3_cfg_t const uart1_pads[] = {
MX6_PAD_CSI0_DAT11__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
};
-#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
/* Colibri MMC */
iomux_v3_cfg_t const usdhc1_pads[] = {
MX6_PAD_SD1_CLK__SD1_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -304,7 +304,7 @@ int board_ehci_hcd_init(int port)
}
#endif
-#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
/* use the following sequence: eMMC, MMC */
struct fsl_esdhc_cfg usdhc_cfg[CONFIG_SYS_FSL_USDHC_NUM] = {
{USDHC3_BASE_ADDR},
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE
On Tue, Sep 3, 2019 at 11:34 AM Igor Opaniuk wrote: > Hi Ricardo, > > On Tue, Sep 3, 2019 at 4:53 PM Ricardo Salveti wrote: > > > > On Tue, Sep 3, 2019 at 12:09 AM Peng Fan wrote: > > > > > > > Subject: [PATCH] apalis_imx6: allocate specific region of memory to > > > > OP-TEE > > > > > > > > OP-TEE uses the memory region defined by the maximum DRAM address > > > > minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > > > > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > > > > conflicts. > > > > > > > > Signed-off-by: Ricardo Salveti > > > > --- > > > > board/toradex/apalis_imx6/apalis_imx6.c | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/board/toradex/apalis_imx6/apalis_imx6.c > > > > b/board/toradex/apalis_imx6/apalis_imx6.c > > > > index 6421a22c25..fa7fcc8d46 100644 > > > > --- a/board/toradex/apalis_imx6/apalis_imx6.c > > > > +++ b/board/toradex/apalis_imx6/apalis_imx6.c > > > > @@ -75,6 +75,11 @@ int dram_init(void) > > > > gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, > > > > (ulong)imx_ddr_size()); > > > > > > > > + /* Subtract the defined OPTEE runtime firmware length */ #ifdef > > > > +CONFIG_OPTEE_TZDRAM_SIZE > > > > + gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE; #endif > > > > + > > > > > > Has OPTEE been enabled? I not see that in defconfig. > > > > Not yet enable by default, this is just to make it compatible with OP-TEE. > > > > Should we have it enabled by default at apalis_imx6_defconfig? I could > > also send another patch to add a new config that has secure boot and > > OP-TEE enabled by default, as done with a few other imx targets. > > IMHO, idea with a new config makes sense, as besides CONFIG_BOOTM_OPTEE=y > we should also add CONFIG_ARMV7_BOOT_SEC_DEFAULT=y and provide > appropriate CONFIG_BOOTCOMMAND to boot TEE blob (although we're currently > in the middle of transition to distroboot usage by default, where we > can handle all this > in a boot script instead). The flow I'm currently using is a bit different, using SPL FIT and loading OP-TEE from SPL itself (in order to load secure world earlier in the boot chain), which then loads U-Boot in normal world. That way we don't actually need to change the default bootcommand logic, as most of the heavy work is done by SPL instead of u-boot. Once some of the needed patches land (e.g. supporting larger SPL on iMX6DQ) I will propose a new config with this setup, so we can all review it. Cheers, -- Ricardo Salveti ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/14] DM: WDT: Convert WDT driver to use DM/DTS (including SYSRESET)
This commit enables support for CONFIG_WDT in the U-Boot proper. Moreover,
the SYSRESET_WATCHDOG driver is used to support 'reset' command.
As SPL is not yet ready for DM conversion, the CONFIG_HW_WATCHDOG is
enabled for it. This allows the legacy SPL code to work properly.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
arch/arm/dts/imx6q-display5-u-boot.dtsi | 5 +
configs/display5_defconfig | 3 +++
include/configs/display5.h | 6 +-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6q-display5-u-boot.dtsi
b/arch/arm/dts/imx6q-display5-u-boot.dtsi
index b942218b7ab8..aa660b5aeb65 100644
--- a/arch/arm/dts/imx6q-display5-u-boot.dtsi
+++ b/arch/arm/dts/imx6q-display5-u-boot.dtsi
@@ -31,6 +31,11 @@
chosen {
stdout-path =
};
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ };
};
{
diff --git a/configs/display5_defconfig b/configs/display5_defconfig
index 3719eb40d5ea..a3062854d89c 100644
--- a/configs/display5_defconfig
+++ b/configs/display5_defconfig
@@ -49,6 +49,7 @@ CONFIG_CMD_PART=y
# CONFIG_CMD_PINMUX is not set
CONFIG_CMD_SF=y
CONFIG_CMD_SPI=y
+CONFIG_CMD_WDT=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_MII=y
CONFIG_CMD_PING=y
@@ -107,5 +108,7 @@ CONFIG_DM_REGULATOR_PFUZE100=y
CONFIG_MXC_UART=y
CONFIG_SPI=y
CONFIG_MXC_SPI=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
CONFIG_I2C_EDID=y
CONFIG_IMX_WATCHDOG=y
diff --git a/include/configs/display5.h b/include/configs/display5.h
index a3cb62367c4c..e66bb65c21c6 100644
--- a/include/configs/display5.h
+++ b/include/configs/display5.h
@@ -348,7 +348,11 @@
/* Watchdog */
#define CONFIG_WATCHDOG_TIMEOUT_MSECS 15000
-
+#if defined(CONFIG_SPL_BUILD)
+#undef CONFIG_WDT
+#undef CONFIG_WATCHDOG
+#define CONFIG_HW_WATCHDOG
+#endif
/* ENV config */
#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_ENV_SIZE(SZ_64K)
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 11/14] ARM: Update display5_factory_defconfig after switch to DM/DTS and uuu utility
This commit updates the display5_factory_defconfig file after the switch to DM/DTS for this board. Moreover, the VID and PID for SPL running SDP gadget have been updated to allow seamless work with 'uuu' utility from NXP (the imx_usb doesn't work properly after embedding the u-boot proper into fitImage - problem with IVT embedding in FIT). Example to use 'uuu' session: cat << EOF > display5_recovery.lst uuu_version 1.2.135 SDP: boot -f /srv/tftp/SPL SDPU: write -f /srv/tftp/u-boot-dtb.img -addr 0x1000 SDPU: jump -addr 0x1000 SDPU: done EOF sudo ./uuu/uuu display5_recovery.lst Signed-off-by: Lukasz Majewski --- Changes in v2: None configs/display5_factory_defconfig | 41 ++ 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/configs/display5_factory_defconfig b/configs/display5_factory_defconfig index c467e8c92890..b4b030a32b76 100644 --- a/configs/display5_factory_defconfig +++ b/configs/display5_factory_defconfig @@ -4,13 +4,19 @@ CONFIG_SYS_TEXT_BASE=0x1780 CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x1000 +CONFIG_MX6_DDRCAL=y CONFIG_TARGET_DISPLAY5=y +CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400 CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y +CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_FIT=y +CONFIG_SPL_LOAD_FIT=y CONFIG_OF_BOARD_SETUP=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q" CONFIG_BOOTDELAY=3 @@ -19,8 +25,6 @@ CONFIG_BOOTCOMMAND="echo SDP Display5 recovery" CONFIG_SUPPORT_RAW_INITRD=y CONFIG_MISC_INIT_R=y CONFIG_BOUNCE_BUFFER=y -CONFIG_SPL_TEXT_BASE=0x00908000 -# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set CONFIG_SPL_DMA_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y @@ -47,11 +51,14 @@ CONFIG_CMD_PART=y CONFIG_CMD_SF=y CONFIG_CMD_SPI=y CONFIG_CMD_USB_SDP=y +CONFIG_CMD_WDT=y CONFIG_CMD_DHCP=y CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y @@ -67,26 +74,52 @@ CONFIG_DEFAULT_DEVICE_TREE="imx6q-display5" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_DFU_MMC=y CONFIG_DFU_SF=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_I2C_DEFAULT_BUS_NUMBER=0x2 +CONFIG_SYS_I2C_MXC=y +CONFIG_SYS_I2C_MXC_I2C1=y +CONFIG_SYS_I2C_MXC_I2C2=y +CONFIG_SYS_I2C_MXC_I2C3=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x50 +CONFIG_SYS_I2C_EEPROM_BUS=2 +CONFIG_SYS_EEPROM_SIZE=32768 +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=5 +CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_USDHC=y CONFIG_MTD_DEVICE=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_MODE=0 CONFIG_SF_DEFAULT_SPEED=5000 +CONFIG_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MTD=y CONFIG_PHYLIB=y +CONFIG_PHY_MARVELL=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_DM_PMIC=y +CONFIG_DM_PMIC_PFUZE100=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_PFUZE100=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_MXC_SPI=y +CONFIG_SYSRESET=y +CONFIG_SYSRESET_WATCHDOG=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Liebherr" -CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 -CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 +CONFIG_USB_GADGET_VENDOR_NUM=0x0525 +CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_I2C_EDID=y CONFIG_IMX_WATCHDOG=y +CONFIG_PANIC_HANG=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/14] DM: eth: Switch display5 board to use DM_ETH
After this commit the display5 device would use FEC driver supporting
driver model (DM_ETH).
Signed-off-by: Lukasz Majewski
---
Changes in v2:
- Use dm_gpio* functions instead of gpio_* ones
arch/arm/mach-imx/mx6/Kconfig | 1 +
board/liebherr/display5/display5.c | 134 +
include/configs/display5.h | 8 ---
3 files changed, 31 insertions(+), 112 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 2496ecacb104..aef18726702b 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -187,6 +187,7 @@ config TARGET_DHCOMIMX6
config TARGET_DISPLAY5
bool "LWN DISPLAY5 board"
select DM
+ select DM_ETH
select DM_I2C
select DM_MMC
select DM_GPIO
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index 0cc77dac0fa1..e008ea9a3fb8 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -155,130 +155,42 @@ static void displ5_setup_ecspi(void)
gpio_direction_output(IMX_GPIO_NR(7, 0), 1);
}
-#ifdef CONFIG_FEC_MXC
-iomux_v3_cfg_t const enet_pads[] = {
- MX6_PAD_ENET_TXD1__ENET_1588_EVENT0_IN | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_RXD1__ENET_1588_EVENT3_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
-
- /* for old evalboard with R159 present and R160 not populated */
- MX6_PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(NO_PAD_CTRL),
-
- MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
-
- MX6_PAD_RGMII_RXC__RGMII_RXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD0__RGMII_RD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD1__RGMII_RD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD2__RGMII_RD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD3__RGMII_RD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
- /*INT#_GBE*/
- MX6_PAD_ENET_TX_EN__GPIO1_IO28 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static void setup_iomux_enet(void)
+/*
+ * Do not overwrite the console
+ * Always use serial for U-Boot console
+ */
+int overwrite_console(void)
{
- SETUP_IOMUX_PADS(enet_pads);
- gpio_direction_input(IMX_GPIO_NR(1, 28)); /*INT#_GBE*/
+ return 1;
}
-static int setup_mac_from_fuse(void)
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
{
- unsigned char enetaddr[6];
- int ret;
-
- ret = eth_env_get_enetaddr("ethaddr", enetaddr);
- if (ret)/* ethaddr is already set */
- return 0;
-
- imx_get_mac_from_fuse(0, enetaddr);
-
- if (is_valid_ethaddr(enetaddr)) {
- eth_env_set_enetaddr("ethaddr", enetaddr);
- return 0;
- }
-
+ fdt_fixup_ethernet(blob);
return 0;
}
+#endif
-int board_eth_init(bd_t *bd)
+int board_phy_config(struct phy_device *phydev)
{
- struct phy_device *phydev;
- struct mii_dev *bus;
- int ret;
-
- setup_iomux_enet();
-
- iomuxc_set_rgmii_io_voltage(DDR_SEL_1P5V_IO);
-
- ret = enable_fec_anatop_clock(0, ENET_125MHZ);
- if (ret)
- return ret;
-
- setup_mac_from_fuse();
-
- bus = fec_get_miibus(IMX_FEC_BASE, -1);
- if (!bus)
- return -ENODEV;
-
- /*
-* We use here the "rgmii-id" mode of operation and allow M88E1512
-* PHY to use its internally callibrated RX/TX delays
-*/
- phydev = phy_find_by_mask(bus, 0x /* (0xf << 4) */,
- PHY_INTERFACE_MODE_RGMII_ID);
- if (!phydev) {
- ret = -ENODEV;
- goto err_phy;
- }
-
/* display5 due to PCB routing can only work with 100 Mbps */
phydev->advertising &= ~(ADVERTISED_1000baseX_Half |
ADVERTISED_1000baseX_Full |
SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full);
- ret = fec_probe(bd, -1, IMX_FEC_BASE, bus, phydev);
- if (ret)
- goto err_sw;
-
- return 0;
-
[U-Boot] [PATCH v2 03/14] DM: I2C: Switch display5 board to use DM_I2C
After this commit the display5 device would use I2C driver supporting
driver model (DM_I2C).
The 'i2c' and 'eeprom' commands now use DM I2C drivers and initialize
on-bus devices according to device tree description.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
arch/arm/mach-imx/mx6/Kconfig | 2 ++
board/liebherr/display5/display5.c | 48 --
configs/display5_defconfig | 14 +++
include/configs/display5.h | 8 ---
4 files changed, 16 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index fe5991e7c6db..39f0e548f5f1 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -187,6 +187,8 @@ config TARGET_DHCOMIMX6
config TARGET_DISPLAY5
bool "LWN DISPLAY5 board"
select DM
+ select DM_I2C
+ select DM_GPIO
select DM_SERIAL
select SUPPORT_SPL
imply CMD_DM
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index 037c4e69e59c..5ebc8529e9c7 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -119,49 +118,6 @@ int dram_init(void)
return 0;
}
-#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-/* I2C1: TFA9879 */
-struct i2c_pads_info i2c_pad_info0 = {
- .scl = {
- .i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
- .gpio_mode = MX6_PAD_EIM_D21__GPIO3_IO21 | PC,
- .gp = IMX_GPIO_NR(3, 21)
- },
- .sda = {
- .i2c_mode = MX6_PAD_EIM_D28__I2C1_SDA | PC,
- .gpio_mode = MX6_PAD_EIM_D28__GPIO3_IO28 | PC,
- .gp = IMX_GPIO_NR(3, 28)
- }
-};
-
-/* I2C2: TIVO TM4C123 */
-struct i2c_pads_info i2c_pad_info1 = {
- .scl = {
- .i2c_mode = MX6_PAD_EIM_EB2__I2C2_SCL | PC,
- .gpio_mode = MX6_PAD_EIM_EB2__GPIO2_IO30 | PC,
- .gp = IMX_GPIO_NR(2, 30)
- },
- .sda = {
- .i2c_mode = MX6_PAD_EIM_D16__I2C2_SDA | PC,
- .gpio_mode = MX6_PAD_EIM_D16__GPIO3_IO16 | PC,
- .gp = IMX_GPIO_NR(3, 16)
- }
-};
-
-/* I2C3: PMIC PF0100, EEPROM AT24C256C */
-struct i2c_pads_info i2c_pad_info2 = {
- .scl = {
- .i2c_mode = MX6_PAD_EIM_D17__I2C3_SCL | PC,
- .gpio_mode = MX6_PAD_EIM_D17__GPIO3_IO17 | PC,
- .gp = IMX_GPIO_NR(3, 17)
- },
- .sda = {
- .i2c_mode = MX6_PAD_EIM_D18__I2C3_SDA | PC,
- .gpio_mode = MX6_PAD_EIM_D18__GPIO3_IO18 | PC,
- .gp = IMX_GPIO_NR(3, 18)
- }
-};
-
iomux_v3_cfg_t const misc_pads[] = {
/* Prod ID GPIO pins */
MX6_PAD_NANDF_D4__GPIO2_IO04| MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -369,10 +325,6 @@ int board_init(void)
udelay(25);
- setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info0);
- setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
- setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info2);
-
return 0;
}
diff --git a/configs/display5_defconfig b/configs/display5_defconfig
index 69f3ceee098b..9ab055ac5587 100644
--- a/configs/display5_defconfig
+++ b/configs/display5_defconfig
@@ -67,6 +67,19 @@ CONFIG_DEFAULT_DEVICE_TREE="imx6q-display5"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_BOOTCOUNT_LIMIT=y
CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_I2C_DEFAULT_BUS_NUMBER=0x2
+CONFIG_SYS_I2C_MXC=y
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_MISC=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SYS_I2C_EEPROM_ADDR=0x50
+CONFIG_SYS_I2C_EEPROM_BUS=2
+CONFIG_SYS_EEPROM_SIZE=32768
+CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=5
+CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_FSL_USDHC=y
CONFIG_MTD_DEVICE=y
@@ -85,4 +98,5 @@ CONFIG_PINCTRL_IMX6=y
CONFIG_MXC_UART=y
CONFIG_SPI=y
CONFIG_MXC_SPI=y
+CONFIG_I2C_EDID=y
CONFIG_IMX_WATCHDOG=y
diff --git a/include/configs/display5.h b/include/configs/display5.h
index 550b7c09f4f6..2a039c24288f 100644
--- a/include/configs/display5.h
+++ b/include/configs/display5.h
@@ -57,15 +57,7 @@
#define CONFIG_MXC_UART_BASE UART5_BASE
/* I2C Configs */
-#define CONFIG_SYS_I2C
-#define CONFIG_SYS_I2C_MXC
-#define CONFIG_SYS_I2C_MXC_I2C1
-#define CONFIG_SYS_I2C_MXC_I2C2
-#define CONFIG_SYS_I2C_MXC_I2C3
#define CONFIG_I2C_MULTI_BUS
-#define CONFIG_SYS_I2C_SPEED 10
-#define CONFIG_I2C_EDID
-#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2
/* Ethernet */
#ifdef CONFIG_FEC_MXC
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/14] ARM: display5: Remove common.c file (after DM/DTS U-Boot proper conversion)
The common.c file content can be safely moved to spl.c file after
performing the DM/DTS conversion for the U-Boot proper.
It contains the non DM/DTS setup code, which now is only used by SPL.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
board/liebherr/display5/Makefile | 4 +-
board/liebherr/display5/common.c | 83
board/liebherr/display5/common.h | 5 ---
board/liebherr/display5/spl.c| 74 +++
4 files changed, 76 insertions(+), 90 deletions(-)
delete mode 100644 board/liebherr/display5/common.c
diff --git a/board/liebherr/display5/Makefile b/board/liebherr/display5/Makefile
index f934672428ab..ee503add75d3 100644
--- a/board/liebherr/display5/Makefile
+++ b/board/liebherr/display5/Makefile
@@ -5,7 +5,7 @@
# SPDX-License-Identifier:GPL-2.0+
#
ifdef CONFIG_SPL_BUILD
-obj-y = common.o spl.o
+obj-y = spl.o
else
-obj-y := common.o display5.o
+obj-y := display5.o
endif
diff --git a/board/liebherr/display5/common.c b/board/liebherr/display5/common.c
deleted file mode 100644
index 5e714076a49c..
--- a/board/liebherr/display5/common.c
+++ /dev/null
@@ -1,83 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2017 DENX Software Engineering
- * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
- */
-
-#include
-#include
-#include "common.h"
-
-iomux_v3_cfg_t const uart_console_pads[] = {
- /* UART5 */
- MX6_PAD_CSI0_DAT14__UART5_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT15__UART5_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT18__UART5_RTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT19__UART5_CTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
-};
-
-void displ5_set_iomux_uart_spl(void)
-{
- SETUP_IOMUX_PADS(uart_console_pads);
-}
-
-iomux_v3_cfg_t const misc_pads_spl[] = {
- /* Emergency recovery pin */
- MX6_PAD_EIM_D29__GPIO3_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-void displ5_set_iomux_misc_spl(void)
-{
- SETUP_IOMUX_PADS(misc_pads_spl);
-}
-
-#ifdef CONFIG_MXC_SPI
-iomux_v3_cfg_t const ecspi2_pads[] = {
- /* SPI2, NOR Flash nWP, CS0 */
- MX6_PAD_CSI0_DAT10__ECSPI2_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
- MX6_PAD_CSI0_DAT9__ECSPI2_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
- MX6_PAD_CSI0_DAT8__ECSPI2_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
- MX6_PAD_CSI0_DAT11__GPIO5_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_SD3_DAT5__GPIO7_IO00| MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-int board_spi_cs_gpio(unsigned int bus, unsigned int cs)
-{
- if (bus != 1 || cs != 0)
- return -EINVAL;
-
- return IMX_GPIO_NR(5, 29);
-}
-
-void displ5_set_iomux_ecspi_spl(void)
-{
- SETUP_IOMUX_PADS(ecspi2_pads);
-}
-
-#else
-void displ5_set_iomux_ecspi_spl(void) {}
-#endif
-
-#ifdef CONFIG_FSL_ESDHC_IMX
-iomux_v3_cfg_t const usdhc4_pads[] = {
- MX6_PAD_SD4_CLK__SD4_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_CMD__SD4_CMD| MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT0__SD4_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT1__SD4_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT2__SD4_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT3__SD4_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT4__SD4_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT5__SD4_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT6__SD4_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD4_DAT7__SD4_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_NANDF_ALE__SD4_RESET| MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-
-void displ5_set_iomux_usdhc_spl(void)
-{
- SETUP_IOMUX_PADS(usdhc4_pads);
-}
-
-#else
-void displ5_set_iomux_usdhc_spl(void) {}
-#endif
diff --git a/board/liebherr/display5/common.h b/board/liebherr/display5/common.h
index 4eb70dc42fb6..44c7470074ce 100644
--- a/board/liebherr/display5/common.h
+++ b/board/liebherr/display5/common.h
@@ -31,9 +31,4 @@
#define ENET_PAD_CTRL_CLK ((PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE) | \
PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
-void displ5_set_iomux_uart_spl(void);
-void displ5_set_iomux_ecspi_spl(void);
-void displ5_set_iomux_usdhc_spl(void);
-void displ5_set_iomux_misc_spl(void);
-
#endif /* __DISPL5_COMMON_H_ */
diff --git a/board/liebherr/display5/spl.c b/board/liebherr/display5/spl.c
index 354b63e431f6..311edaf939cc 100644
--- a/board/liebherr/display5/spl.c
+++ b/board/liebherr/display5/spl.c
@@ -104,6 +104,80 @@ static const struct mx6_ddr3_cfg mt41k128m16jt_125 = {
.trasmin = 3500,
};
+iomux_v3_cfg_t const uart_console_pads[] = {
+ /* UART5 */
+ MX6_PAD_CSI0_DAT14__UART5_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_CSI0_DAT15__UART5_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_CSI0_DAT18__UART5_RTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
+
[U-Boot] [PATCH v2 12/14] cosmetic: Cleanup display5_defconfig with make savedefconfig
Fix the structure of configs/display5_defconfig file by using th make savedefconfig. Signed-off-by: Lukasz Majewski --- Changes in v2: None configs/display5_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/display5_defconfig b/configs/display5_defconfig index a3062854d89c..46bcdaffc835 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -16,6 +16,7 @@ CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_SYS_BOOTCOUNT_ADDR=0x020CC068 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y +CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT=y CONFIG_OF_BOARD_SETUP=y @@ -23,7 +24,6 @@ CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q" CONFIG_SUPPORT_RAW_INITRD=y CONFIG_MISC_INIT_R=y CONFIG_BOUNCE_BUFFER=y -CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_BOOTCOUNT_LIMIT=y # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set CONFIG_SPL_DMA_SUPPORT=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/14] ARM: imx: defconfig: Enable 'regulator' and 'pmic' commands on display5
Signed-off-by: Lukasz Majewski --- Changes in v2: None configs/display5_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/display5_defconfig b/configs/display5_defconfig index 9ab055ac5587..6c80a4d46678 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -54,6 +54,8 @@ CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y @@ -95,6 +97,10 @@ CONFIG_FEC_MXC=y CONFIG_MII=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y +CONFIG_DM_PMIC=y +CONFIG_DM_PMIC_PFUZE100=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_PFUZE100=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_MXC_SPI=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/14] ARM: display5: Remove UART initialization code after DM/DTS conversion (non-console)
This UART is not used in U-Boot, so there is no need to initialize it.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
board/liebherr/display5/common.c | 13 -
board/liebherr/display5/common.h | 1 -
board/liebherr/display5/display5.c | 2 --
3 files changed, 16 deletions(-)
diff --git a/board/liebherr/display5/common.c b/board/liebherr/display5/common.c
index d2d174beaa0d..5e714076a49c 100644
--- a/board/liebherr/display5/common.c
+++ b/board/liebherr/display5/common.c
@@ -8,14 +8,6 @@
#include
#include "common.h"
-iomux_v3_cfg_t const uart_pads[] = {
- /* UART4 */
- MX6_PAD_CSI0_DAT12__UART4_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT13__UART4_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT16__UART4_RTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT17__UART4_CTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
-};
-
iomux_v3_cfg_t const uart_console_pads[] = {
/* UART5 */
MX6_PAD_CSI0_DAT14__UART5_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
@@ -29,11 +21,6 @@ void displ5_set_iomux_uart_spl(void)
SETUP_IOMUX_PADS(uart_console_pads);
}
-void displ5_set_iomux_uart(void)
-{
- SETUP_IOMUX_PADS(uart_pads);
-}
-
iomux_v3_cfg_t const misc_pads_spl[] = {
/* Emergency recovery pin */
MX6_PAD_EIM_D29__GPIO3_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
diff --git a/board/liebherr/display5/common.h b/board/liebherr/display5/common.h
index 2bbd934e7a70..4eb70dc42fb6 100644
--- a/board/liebherr/display5/common.h
+++ b/board/liebherr/display5/common.h
@@ -32,7 +32,6 @@
PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
void displ5_set_iomux_uart_spl(void);
-void displ5_set_iomux_uart(void);
void displ5_set_iomux_ecspi_spl(void);
void displ5_set_iomux_usdhc_spl(void);
void displ5_set_iomux_misc_spl(void);
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index 541e3e94a5eb..5713401ed954 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -174,8 +174,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
- /* Setup iomux for non console UARTS */
- displ5_set_iomux_uart();
/* Setup misc (application specific) stuff */
SETUP_IOMUX_PADS(misc_pads);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 14/14] imx: Rewrite display5 get_board_id() function to use dm_gpio_* API
The get_board_id() function was using the old gpio_* compatibility layer
to read HW and SW ID numbers encoded on the PCB board.
After this change the new dm_gpio* API is used for this purpose.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
board/liebherr/display5/display5.c | 53 +++---
1 file changed, 21 insertions(+), 32 deletions(-)
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index b8dcd03fd9b6..85ca777c1d22 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -36,60 +36,49 @@ static bool sw_ids_valid;
static u32 cpu_id;
static u32 unit_id;
-#define SW0IMX_GPIO_NR(2, 4)
-#define SW1IMX_GPIO_NR(2, 5)
-#define SW2IMX_GPIO_NR(2, 6)
-#define SW3IMX_GPIO_NR(2, 7)
-#define HW0IMX_GPIO_NR(6, 7)
-#define HW1IMX_GPIO_NR(6, 9)
-#define HW2IMX_GPIO_NR(6, 10)
-#define HW3IMX_GPIO_NR(6, 11)
-#define HW4IMX_GPIO_NR(4, 7)
-#define HW5IMX_GPIO_NR(4, 11)
-#define HW6IMX_GPIO_NR(4, 13)
-#define HW7IMX_GPIO_NR(4, 15)
-
-int gpio_table_sw_ids[] = {
- SW0, SW1, SW2, SW3
+const char *gpio_table_sw_names[] = {
+ "GPIO2_4", "GPIO2_5", "GPIO2_6", "GPIO2_7"
};
const char *gpio_table_sw_ids_names[] = {
"sw0", "sw1", "sw2", "sw3"
};
-int gpio_table_hw_ids[] = {
- HW0, HW1, HW2, HW3, HW4, HW5, HW6, HW7
+const char *gpio_table_hw_names[] = {
+ "GPIO6_7", "GPIO6_9", "GPIO6_10", "GPIO6_11",
+ "GPIO4_7", "GPIO4_11", "GPIO4_13", "GPIO4_15"
};
const char *gpio_table_hw_ids_names[] = {
"hw0", "hw1", "hw2", "hw3", "hw4", "hw5", "hw6", "hw7"
};
-static int get_board_id(int *ids, const char **c, int size,
- bool *valid, u32 *id)
+static int get_board_id(const char **pin_names, const char **ids_names,
+ int size, bool *valid, u32 *id)
{
+ struct gpio_desc desc;
int i, ret, val;
*valid = false;
for (i = 0; i < size; i++) {
- ret = gpio_request(ids[i], c[i]);
+ memset(, 0, sizeof(desc));
+
+ ret = dm_gpio_lookup_name(pin_names[i], );
if (ret) {
- printf("Can't request SWx gpios\n");
+ printf("Can't lookup request SWx gpios\n");
return ret;
}
- }
- for (i = 0; i < size; i++) {
- ret = gpio_direction_input(ids[i]);
+ ret = dm_gpio_request(, ids_names[i]);
if (ret) {
- printf("Can't set SWx gpios direction\n");
+ printf("Can't lookup request SWx gpios\n");
return ret;
}
- }
- for (i = 0; i < size; i++) {
- val = gpio_get_value(ids[i]);
+ dm_gpio_set_dir_flags(, GPIOD_IS_IN);
+
+ val = dm_gpio_get_value();
if (val < 0) {
printf("Can't get SW%d ID\n", i);
*id = 0;
@@ -176,12 +165,12 @@ int board_init(void)
/* Setup misc (application specific) stuff */
SETUP_IOMUX_PADS(misc_pads);
- get_board_id(gpio_table_sw_ids, _table_sw_ids_names[0],
-ARRAY_SIZE(gpio_table_sw_ids), _ids_valid, _id);
+ get_board_id(gpio_table_sw_names, _table_sw_ids_names[0],
+ARRAY_SIZE(gpio_table_sw_names), _ids_valid, _id);
debug("SWx unit_id 0x%x\n", unit_id);
- get_board_id(gpio_table_hw_ids, _table_hw_ids_names[0],
-ARRAY_SIZE(gpio_table_hw_ids), _ids_valid, _id);
+ get_board_id(gpio_table_hw_names, _table_hw_ids_names[0],
+ARRAY_SIZE(gpio_table_hw_names), _ids_valid, _id);
debug("HWx cpu_id 0x%x\n", cpu_id);
if (hw_ids_valid && sw_ids_valid)
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 13/14] imx: Convert emergency pad of display5 to use dm_gpio* functions
After this change the display5's emergency gpio use dm_gpio* functions
instead of legacy ones (gpio*) to read its state.
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
board/liebherr/display5/display5.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index 5713401ed954..b8dcd03fd9b6 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -36,7 +36,6 @@ static bool sw_ids_valid;
static u32 cpu_id;
static u32 unit_id;
-#define EM_PAD IMX_GPIO_NR(3, 29)
#define SW0IMX_GPIO_NR(2, 4)
#define SW1IMX_GPIO_NR(2, 5)
#define SW2IMX_GPIO_NR(2, 6)
@@ -236,21 +235,24 @@ static inline void setup_boot_modes(void) {}
int misc_init_r(void)
{
+ struct gpio_desc em_pad;
int ret;
setup_boot_modes();
- ret = gpio_request(EM_PAD, "Emergency_PAD");
+ ret = dm_gpio_lookup_name("GPIO3_29", _pad);
if (ret) {
- printf("Can't request emergency PAD gpio\n");
+ printf("Can't find emergency PAD gpio\n");
return ret;
}
- ret = gpio_direction_input(EM_PAD);
+ ret = dm_gpio_request(_pad, "Emergency_PAD");
if (ret) {
- printf("Can't set emergency PAD direction\n");
+ printf("Can't request emergency PAD gpio\n");
return ret;
}
+ dm_gpio_set_dir_flags(_pad, GPIOD_IS_IN);
+
return 0;
}
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 07/14] DM: SPI: Convert display5 to use SPI with DM/DTS (but no in SPL)
The DM/DTS support for SPI is disabled on purpose for SPL, as it is not
supported as of time of this conversion.
Signed-off-by: Lukasz Majewski
---
Changes in v2:
- Use dm_gpio_* instead of legacy gpio_* functions
arch/arm/mach-imx/mx6/Kconfig | 1 +
board/liebherr/display5/common.c | 18 --
board/liebherr/display5/common.h | 1 -
board/liebherr/display5/display5.c | 37 -
configs/display5_defconfig | 3 +++
include/configs/display5.h | 7 +--
6 files changed, 21 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index aef18726702b..f0786b5ffb40 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -190,6 +190,7 @@ config TARGET_DISPLAY5
select DM_ETH
select DM_I2C
select DM_MMC
+ select DM_SPI
select DM_GPIO
select DM_SERIAL
select SUPPORT_SPL
diff --git a/board/liebherr/display5/common.c b/board/liebherr/display5/common.c
index 754c442427f8..d2d174beaa0d 100644
--- a/board/liebherr/display5/common.c
+++ b/board/liebherr/display5/common.c
@@ -45,18 +45,6 @@ void displ5_set_iomux_misc_spl(void)
}
#ifdef CONFIG_MXC_SPI
-iomux_v3_cfg_t const ecspi_pads[] = {
- /* SPI3 */
- MX6_PAD_DISP0_DAT2__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
- MX6_PAD_DISP0_DAT1__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
- MX6_PAD_DISP0_DAT0__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
- MX6_PAD_DISP0_DAT3__ECSPI3_SS0 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_DISP0_DAT4__ECSPI3_SS1 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_DISP0_DAT5__ECSPI3_SS2 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_DISP0_DAT6__ECSPI3_SS3 | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_DISP0_DAT7__ECSPI3_RDY | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
iomux_v3_cfg_t const ecspi2_pads[] = {
/* SPI2, NOR Flash nWP, CS0 */
MX6_PAD_CSI0_DAT10__ECSPI2_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
@@ -79,14 +67,8 @@ void displ5_set_iomux_ecspi_spl(void)
SETUP_IOMUX_PADS(ecspi2_pads);
}
-void displ5_set_iomux_ecspi(void)
-{
- SETUP_IOMUX_PADS(ecspi_pads);
-}
-
#else
void displ5_set_iomux_ecspi_spl(void) {}
-void displ5_set_iomux_ecspi(void) {}
#endif
#ifdef CONFIG_FSL_ESDHC_IMX
diff --git a/board/liebherr/display5/common.h b/board/liebherr/display5/common.h
index 231cefc96009..2bbd934e7a70 100644
--- a/board/liebherr/display5/common.h
+++ b/board/liebherr/display5/common.h
@@ -34,7 +34,6 @@
void displ5_set_iomux_uart_spl(void);
void displ5_set_iomux_uart(void);
void displ5_set_iomux_ecspi_spl(void);
-void displ5_set_iomux_ecspi(void);
void displ5_set_iomux_usdhc_spl(void);
void displ5_set_iomux_misc_spl(void);
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index e008ea9a3fb8..541e3e94a5eb 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -28,11 +27,6 @@
#include
#include
-#ifndef CONFIG_MXC_SPI
-#error "CONFIG_SPI must be set for this board"
-#error "Please check your config file"
-#endif
-
#include "common.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -140,21 +134,6 @@ iomux_v3_cfg_t const misc_pads[] = {
MX6_PAD_EIM_D29__GPIO3_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
-static void displ5_setup_ecspi(void)
-{
- int ret;
-
- displ5_set_iomux_ecspi();
-
- ret = gpio_request(IMX_GPIO_NR(5, 29), "spi2_cs0");
- if (!ret)
- gpio_direction_output(IMX_GPIO_NR(5, 29), 1);
-
- ret = gpio_request(IMX_GPIO_NR(7, 0), "spi2_#wp");
- if (!ret)
- gpio_direction_output(IMX_GPIO_NR(7, 0), 1);
-}
-
/*
* Do not overwrite the console
* Always use serial for U-Boot console
@@ -188,7 +167,7 @@ int board_phy_config(struct phy_device *phydev)
int board_init(void)
{
- struct gpio_desc phy_int_gbe;
+ struct gpio_desc phy_int_gbe, spi2_wp;
int ret;
debug("board init\n");
@@ -197,9 +176,6 @@ int board_init(void)
/* Setup iomux for non console UARTS */
displ5_set_iomux_uart();
-
- displ5_setup_ecspi();
-
/* Setup misc (application specific) stuff */
SETUP_IOMUX_PADS(misc_pads);
@@ -229,6 +205,17 @@ int board_init(void)
iomuxc_set_rgmii_io_voltage(DDR_SEL_1P5V_IO);
enable_fec_anatop_clock(0, ENET_125MHZ);
+ /* Setup #WP for SPI-NOR memory */
+ ret = dm_gpio_lookup_name("GPIO7_0", _wp);
+ if (ret) {
+ printf("Cannot get GPIO7_0\n");
+ } else {
+ ret = dm_gpio_request(_wp, "spi2_#wp");
+ if (!ret)
+ dm_gpio_set_dir_flags(_wp, GPIOD_IS_OUT |
+ GPIOD_IS_OUT_ACTIVE);
+ }
+
return 0;
}
diff --git a/configs/display5_defconfig
[U-Boot] [PATCH v2 02/14] ARM: imx: defconfig: Enable CONFIG_PINCTRL{_IMX6} on display5's defconfig
Enable PINCTRL for i.MX6 soc based display5 after DM/DTS conversion. Signed-off-by: Lukasz Majewski --- Changes in v2: None configs/display5_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/display5_defconfig b/configs/display5_defconfig index 8609cd5a8cf6..69f3ceee098b 100644 --- a/configs/display5_defconfig +++ b/configs/display5_defconfig @@ -46,6 +46,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +# CONFIG_CMD_PINMUX is not set CONFIG_CMD_SF=y CONFIG_CMD_SPI=y CONFIG_CMD_DHCP=y @@ -79,6 +80,8 @@ CONFIG_PHYLIB=y CONFIG_PHY_MARVELL=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_MXC_SPI=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 01/14] fix: defconfig: Enable OF_CONTROL for display5_factory
This change fixes issue with building display5 "factory" U-Boot variant when the display5 board gains DM/DTS support. Signed-off-by: Lukasz Majewski --- Changes in v2: None configs/display5_factory_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/display5_factory_defconfig b/configs/display5_factory_defconfig index 70c64260d87b..c467e8c92890 100644 --- a/configs/display5_factory_defconfig +++ b/configs/display5_factory_defconfig @@ -62,6 +62,8 @@ CONFIG_MTDIDS_DEFAULT="nor0=02008000.spi.1" CONFIG_MTDPARTS_DEFAULT="mtdparts=02008000.spi.1:128k(SPL),1m(u-boot),64k(env1),64k(env2),4m(swu-kernel),16m(swu-initramfs),1m(factory),-(reserved)" # CONFIG_SPL_EFI_PARTITION is not set CONFIG_PARTITION_TYPE_GUID=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx6q-display5" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_DFU_MMC=y CONFIG_DFU_SF=y @@ -88,4 +90,3 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y -CONFIG_OF_LIBFDT=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/14] DM: mmc: Switch display5 board to use DM_MMC and BLK (USDHC)
After this commit the display5 device would use eMMC driver supporting
driver model (DM_MMC and BLK).
Signed-off-by: Lukasz Majewski
---
Changes in v2: None
arch/arm/mach-imx/mx6/Kconfig | 1 +
board/liebherr/display5/common.c | 6 --
board/liebherr/display5/common.h | 1 -
board/liebherr/display5/display5.c | 22 --
4 files changed, 1 insertion(+), 29 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 39f0e548f5f1..2496ecacb104 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -188,6 +188,7 @@ config TARGET_DISPLAY5
bool "LWN DISPLAY5 board"
select DM
select DM_I2C
+ select DM_MMC
select DM_GPIO
select DM_SERIAL
select SUPPORT_SPL
diff --git a/board/liebherr/display5/common.c b/board/liebherr/display5/common.c
index 8390d9a0f31c..754c442427f8 100644
--- a/board/liebherr/display5/common.c
+++ b/board/liebherr/display5/common.c
@@ -109,12 +109,6 @@ void displ5_set_iomux_usdhc_spl(void)
SETUP_IOMUX_PADS(usdhc4_pads);
}
-void displ5_set_iomux_usdhc(void)
-{
- SETUP_IOMUX_PADS(usdhc4_pads);
-}
-
#else
void displ5_set_iomux_usdhc_spl(void) {}
-void displ5_set_iomux_usdhc(void) {}
#endif
diff --git a/board/liebherr/display5/common.h b/board/liebherr/display5/common.h
index 78c64b02e280..231cefc96009 100644
--- a/board/liebherr/display5/common.h
+++ b/board/liebherr/display5/common.h
@@ -36,7 +36,6 @@ void displ5_set_iomux_uart(void);
void displ5_set_iomux_ecspi_spl(void);
void displ5_set_iomux_ecspi(void);
void displ5_set_iomux_usdhc_spl(void);
-void displ5_set_iomux_usdhc(void);
void displ5_set_iomux_misc_spl(void);
#endif /* __DISPL5_COMMON_H_ */
diff --git a/board/liebherr/display5/display5.c
b/board/liebherr/display5/display5.c
index 5ebc8529e9c7..0cc77dac0fa1 100644
--- a/board/liebherr/display5/display5.c
+++ b/board/liebherr/display5/display5.c
@@ -20,8 +20,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -142,26 +140,6 @@ iomux_v3_cfg_t const misc_pads[] = {
MX6_PAD_EIM_D29__GPIO3_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
-#ifdef CONFIG_FSL_ESDHC_IMX
-struct fsl_esdhc_cfg usdhc_cfg[1] = {
- { USDHC4_BASE_ADDR, 0, 8, },
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- return 1;
-}
-
-int board_mmc_init(bd_t *bis)
-{
- displ5_set_iomux_usdhc();
-
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
-
- return fsl_esdhc_initialize(bis, _cfg[0]);
-}
-#endif /* CONFIG_FSL_ESDHC_IMX */
-
static void displ5_setup_ecspi(void)
{
int ret;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/14] DM: display5: Convert display5 board to DM/DTS (including 'factory' setup)
This patch series converts display5 to use DM/DTS.
The SPL conversion to DM/DTS has been omitted.
The previous series due to some Kconfig issues was applied partially.
Following patches were NOT applied:
https://patchwork.ozlabs.org/patch/1112757/
https://patchwork.ozlabs.org/patch/1112755/
https://patchwork.ozlabs.org/patch/1112756/
This series supersedes conversion from above patches by:
- Fixing issues after porting to newest mainline (FSL_MMC_IMX conversion)
- Converts usage of gpio* legacy API to dm_gpio*
- Cleans up the display5_{factory_}defconfig
Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/580153865
Applied on top of u-boot/master branch
SHA1: 877294b56a52f1cb60bbfa7e4722fcc33451f7b2
Buildman:
./tools/buildman/buildman.py --branch=HEAD mx6 --show_errors --force-build
--count=14 --output-dir=../BUILD/
Changes in v2:
- Use dm_gpio* functions instead of gpio_* ones
- Use dm_gpio_* instead of legacy gpio_* functions
Lukasz Majewski (14):
fix: defconfig: Enable OF_CONTROL for display5_factory
ARM: imx: defconfig: Enable CONFIG_PINCTRL{_IMX6} on display5's
defconfig
DM: I2C: Switch display5 board to use DM_I2C
ARM: imx: defconfig: Enable 'regulator' and 'pmic' commands on
display5
DM: mmc: Switch display5 board to use DM_MMC and BLK (USDHC)
DM: eth: Switch display5 board to use DM_ETH
DM: SPI: Convert display5 to use SPI with DM/DTS (but no in SPL)
ARM: display5: Remove UART initialization code after DM/DTS conversion
(non-console)
DM: WDT: Convert WDT driver to use DM/DTS (including SYSRESET)
ARM: display5: Remove common.c file (after DM/DTS U-Boot proper
conversion)
ARM: Update display5_factory_defconfig after switch to DM/DTS and uuu
utility
cosmetic: Cleanup display5_defconfig with make savedefconfig
imx: Convert emergency pad of display5 to use dm_gpio* functions
imx: Rewrite display5 get_board_id() function to use dm_gpio_* API
arch/arm/dts/imx6q-display5-u-boot.dtsi | 5 +
arch/arm/mach-imx/mx6/Kconfig | 5 +
board/liebherr/display5/Makefile| 4 +-
board/liebherr/display5/common.c| 120 -
board/liebherr/display5/common.h| 8 -
board/liebherr/display5/display5.c | 302 +++-
board/liebherr/display5/spl.c | 74
configs/display5_defconfig | 31 +++-
configs/display5_factory_defconfig | 44 -
include/configs/display5.h | 29 ++-
10 files changed, 232 insertions(+), 390 deletions(-)
delete mode 100644 board/liebherr/display5/common.c
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix U-Boot corruption after saving the environment
On Mon, Sep 02, 2019 at 01:40:27PM -0300, Fabio Estevam wrote: > Hi Tom, > > On Fri, Aug 30, 2019 at 3:14 PM Tom Rini wrote: > > > Are there more i.mx platforms that are not setting BOARD_SIZE_LIMIT > > today? I assume there are, sadly. Can you audit and catch the rest of > > Yes, only a very few i.MX boards set BOARD_SIZE_LIMIT currently. > > > these likely problems, and add limits so we won't repeat this again. > > Yes, I can audit this, but this task requires more time and I can do > that after 2019.10 is released. > > Could this one that fixes mx53qsb be applied for 2019.10? As some is better than none, yes, we should fix and detect this for this platform. But I am a little frustrated in that this is not a new problem and the hook to check for this problem was put in back in June, so I had hoped for more preemptive conversions. It's also on me for having not reminded folks about that too. So please, can we make sure to get this covered ASAP? I think the kludge patch I've posted and linked to before (http://patchwork.ozlabs.org/patch/790476/) can be used here to get a current value calculated and spit out. Moving the question to Kconfig would then make it easier still to: 1. sync all configs 2. loop over appending value to defconfigs 3. re-sync all defconfigs 4. drop first patch, squash next approximately anyhow. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE
Hi Ricardo, On Tue, Sep 3, 2019 at 4:53 PM Ricardo Salveti wrote: > > On Tue, Sep 3, 2019 at 12:09 AM Peng Fan wrote: > > > > > Subject: [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE > > > > > > OP-TEE uses the memory region defined by the maximum DRAM address > > > minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > > > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > > > conflicts. > > > > > > Signed-off-by: Ricardo Salveti > > > --- > > > board/toradex/apalis_imx6/apalis_imx6.c | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/board/toradex/apalis_imx6/apalis_imx6.c > > > b/board/toradex/apalis_imx6/apalis_imx6.c > > > index 6421a22c25..fa7fcc8d46 100644 > > > --- a/board/toradex/apalis_imx6/apalis_imx6.c > > > +++ b/board/toradex/apalis_imx6/apalis_imx6.c > > > @@ -75,6 +75,11 @@ int dram_init(void) > > > gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, > > > (ulong)imx_ddr_size()); > > > > > > + /* Subtract the defined OPTEE runtime firmware length */ #ifdef > > > +CONFIG_OPTEE_TZDRAM_SIZE > > > + gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE; #endif > > > + > > > > Has OPTEE been enabled? I not see that in defconfig. > > Not yet enable by default, this is just to make it compatible with OP-TEE. > > Should we have it enabled by default at apalis_imx6_defconfig? I could > also send another patch to add a new config that has secure boot and > OP-TEE enabled by default, as done with a few other imx targets. IMHO, idea with a new config makes sense, as besides CONFIG_BOOTM_OPTEE=y we should also add CONFIG_ARMV7_BOOT_SEC_DEFAULT=y and provide appropriate CONFIG_BOOTCOMMAND to boot TEE blob (although we're currently in the middle of transition to distroboot usage by default, where we can handle all this in a boot script instead). > > Thanks, > -- > Ricardo Salveti > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Thanks -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "spi: Kconfig: Mark MXS_SPI has DEPRECATED"
Hi Jagan,
> This reverts commit d5ded320a14b0a2f97cbed072286748895ad18ac.
>
> The mxs_spi.c driver for i.MX2{38} devices has been converted:
> 'commit d99b018a6e3d ("spi: mxs: Add support DM/DTS for i.MX28 mxs
> SPI driver (DM_SPI conversion)")'
>
> to use Device Tree and Device Model, so the DEPRECATED Kconfig
> symbol can be now removed.
Gentle ping on this patch.
>
> Signed-off-by: Lukasz Majewski
>
> ---
>
> drivers/spi/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index f459c0a411..8dd3213d48 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -419,7 +419,6 @@ config MXC_SPI
>
> config MXS_SPI
> bool "MXS SPI Driver"
> - depends on DEPRECATED
> help
> Enable the MXS SPI controller driver. This driver can be
> used on the i.MX23 and i.MX28 SoCs.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpZu0WZtFUyU.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: mmc: Fix indentation in spl_mmc.c file
From: Mans Rullgard
This fixes a wrongly indented block of code.
Signed-off-by: Mans Rullgard
[lukma: Make the commit message more verbose]
Signed-off-by: Lukasz Majewski
---
common/spl/spl_mmc.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index b3619889f7..2caceb5186 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -334,28 +334,28 @@ int spl_mmc_load(struct spl_image_info *spl_image,
err = -EINVAL;
switch (boot_mode) {
case MMCSD_MODE_EMMCBOOT:
- /*
-* We need to check what the partition is configured to.
-* 1 and 2 match up to boot0 / boot1 and 7 is user data
-* which is the first physical partition (0).
-*/
- part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
-
- if (part == 7)
- part = 0;
-
- if (CONFIG_IS_ENABLED(MMC_TINY))
- err = mmc_switch_part(mmc, part);
- else
- err = blk_dselect_hwpart(mmc_get_blk_desc(mmc),
part);
-
- if (err) {
+ /*
+* We need to check what the partition is configured to.
+* 1 and 2 match up to boot0 / boot1 and 7 is user data
+* which is the first physical partition (0).
+*/
+ part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+ if (part == 7)
+ part = 0;
+
+ if (CONFIG_IS_ENABLED(MMC_TINY))
+ err = mmc_switch_part(mmc, part);
+ else
+ err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
+
+ if (err) {
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
- puts("spl: mmc partition switch failed\n");
+ puts("spl: mmc partition switch failed\n");
#endif
- return err;
- }
- /* Fall through */
+ return err;
+ }
+ /* Fall through */
case MMCSD_MODE_RAW:
debug("spl: mmc boot mode: raw\n");
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: mmc: Add option to set eMMC HW boot partition
From: Mans Rullgard
This change allows setting pre-defined eMMC boot partition for SPL eMMC
booting. It is necessary in the case when one wants to boot (through falcon
boot) from eMMC after loading SPL from other memory (like SPI-NOR).
Signed-off-by: Mans Rullgard
[lukma: Edit the commit message]
Signed-off-by: Lukasz Majewski
Acked-by: Andreas Dannenberg
---
common/spl/Kconfig | 6 ++
common/spl/spl_mmc.c | 4
2 files changed, 10 insertions(+)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index f467eca2be..5b7667ea16 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -314,6 +314,12 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
Address on the MMC to load U-Boot from, when the MMC is being used
in raw mode. Units: MMC sectors (1 sector = 512 bytes).
+config SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
+ int "Number of the eMMC boot partition to use"
+ default 1
+ help
+ eMMC boot partition number to use when the eMMC in raw mode.
+
config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
bool "MMC Raw mode: by partition"
help
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 2caceb5186..a4d2e63b82 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -334,6 +334,9 @@ int spl_mmc_load(struct spl_image_info *spl_image,
err = -EINVAL;
switch (boot_mode) {
case MMCSD_MODE_EMMCBOOT:
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
+ part = CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION;
+#else
/*
* We need to check what the partition is configured to.
* 1 and 2 match up to boot0 / boot1 and 7 is user data
@@ -343,6 +346,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
if (part == 7)
part = 0;
+#endif
if (CONFIG_IS_ENABLED(MMC_TINY))
err = mmc_switch_part(mmc, part);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spl: Introduce SPL_DM_GPIO Kconfig define
This define indicates if DM_GPIO shall be supported in SPL. This allows proper operation of DM converted GPIO drivers in SPL, which use #if !CONFIG_IS_ENABLED(DM_GPIO) to also support not yet DM/DTS converted boards. Signed-off-by: Lukasz Majewski --- common/spl/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 5b7667ea16..7c3391cabe 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -458,6 +458,12 @@ config SPL_DMA_SUPPORT the CPU moving the data. Enable this option to build the drivers in drivers/dma as part of an SPL build. +config SPL_DM_GPIO + bool "Support Driver Model GPIO drivers" + depends on SPL_GPIO_SUPPORT + help + Enable support for Driver Model based GPIO drivers in SPL. + config SPL_DRIVERS_MISC_SUPPORT bool "Support misc drivers" help -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Environment flags broken for U-Boot
Hi Heiko
> From: Heiko Schocher
> Sent: mardi 3 septembre 2019 06:45
> Subject: Re: U-Boot: Environment flags broken for U-Boot
>
> Hello Patrick,
>
> Am 02.09.2019 um 17:35 schrieb Patrick DELAUNAY:
> > Hi Heiko,
> >
> >
> >> From: Heiko Schocher
> >> Sent: lundi 2 septembre 2019 16:03
> >>
> >> Hello Patrick,
> >>
> >> I am just testing U-Boot Environment flags and they do not work
> >> anymore with current mainline U-Boot ... I should have made some tbot
> >> test for it, but did not found yet time for it ...
> >>
> >> Here log with current mainline:
> >>
> >>
> >> => printenv heiko
> >> heiko=changed
> >> => env flags
> >> Available variable type flags (position 0):
> >> FlagVariable Type Name
> >> --
> >> s - string
> >> d - decimal
> >> x - hexadecimal
> >> b - boolean
> >> i - IP address
> >> m - MAC address
> >>
> >> Available variable access flags (position 1):
> >> FlagVariable Access Name
> >>
> >> a - any
> >> r - read-only
> >> o - write-once
> >> c - change-default
> >>
> >> Static flags:
> >> Variable NameVariable TypeVariable Access
> >> -----
> >> eth\d*addr MAC address any
> >> ipaddr IP address any
> >> gatewayipIP address any
> >> netmask IP address any
> >> serverip IP address any
> >> nvlandecimal any
> >> vlan decimal any
> >> dnsipIP address any
> >> heikostring write-once
> >>
> >> Active flags:
> >> Variable NameVariable TypeVariable Access
> >> -----
> >> .flags string write-once
> >> netmask IP address any
> >> serverip IP address any
> >> heikostring write-once
> >> ipaddr IP address any
> >> => setenv heiko foo
> >> => print heiko
> >> heiko=foo
> >> => setenv heiko bar
> >> => print heiko
> >> heiko=bar
> >>
> >> I can change Environment variable "heiko" but flag is write-once !
> >>
> >> Ok, digging around and I found, that in env/common.c changed_ok is
> >> NULL which results in not checking U-Boot flags:
> >>
> >>26 struct hsearch_data env_htab = {
> >>27 #if CONFIG_IS_ENABLED(ENV_SUPPORT)
> >>28 /* defined in flags.c, only compile with ENV_SUPPORT */
> >>29 .change_ok = env_flags_validate,
> >>30 #endif
> >>31 };
> >>
> >> reason is your commit:
> >>
> >> commit 7d4776545b0f8a8827e5d061206faf61c9ba6ea9
> >> Author: Patrick Delaunay
> >> Date: Thu Apr 18 17:32:49 2019 +0200
> >>
> >> env: solve compilation error in SPL
> >>
> >> Solve compilation issue when cli_simple.o is used in SPL
> >> and CONFIG_SPL_ENV_SUPPORT is not defined.
> >>
> >> env/built-in.o:(.data.env_htab+0xc): undefined reference to
> `env_flags_validate'
> >> u-boot/scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl'
> >> failed
> >> make[2]: *** [spl/u-boot-spl] Error 1
> >> u-boot/Makefile:1649: recipe for target 'spl/u-boot-spl' failed
> >> make[1]: *** [spl/u-boot-spl] Error 2
> >>
> >> Signed-off-by: Patrick Delaunay
> >>
> >>
> >> ENV_SUPPORT is only defined for SPL and TPL not for U-Boot, which
> >> leads in change_ok always NULL in U-Boot ...
> >>
> >> :-(
> >>
> >> reverting this commit and it works again as expected ...
> >>
> >> Urgs ... since april 2019 nobody tested this feature
> >>
> >> :-(
> >>
> >> Nevertheless, reverting commit and I see:
> >>
> >> => print heiko
> >> heiko=test
> >> => setenv heiko foo
> >> ## Error inserting "heiko" variable, errno=1 =>
> >>
> >> So we should find a solution for this.
> >>
> >> Any ideas?
> >
> > Hi,
> >
> > Yes I am responsible of the regression, sorry.
> >
> > When I see the definition CONFIG_SPL_ENV_SUPPORT and
> CONFIG_TPL_ENV_SUPPORT, I use the generic macro to check the activation
> of these TPL/SPL feature in the SPL/TPL builds
> > But I don't check the existence of the U-Boot flag CONFIG_ENV_SUPPORT
> when I propose my patch... so my patch is incorrect.
> >
> > As flags.o is always compiled for U-Boot :
> >
> > ifndef CONFIG_SPL_BUILD
> > obj-y += attr.o
> > obj-y += callback.o
> > obj-y += flags.o
> > ...
> > else
> > obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
> > obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
> >
Re: [U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE
On Tue, Sep 3, 2019 at 12:09 AM Peng Fan wrote: > > > Subject: [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE > > > > OP-TEE uses the memory region defined by the maximum DRAM address > > minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > > conflicts. > > > > Signed-off-by: Ricardo Salveti > > --- > > board/toradex/apalis_imx6/apalis_imx6.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/board/toradex/apalis_imx6/apalis_imx6.c > > b/board/toradex/apalis_imx6/apalis_imx6.c > > index 6421a22c25..fa7fcc8d46 100644 > > --- a/board/toradex/apalis_imx6/apalis_imx6.c > > +++ b/board/toradex/apalis_imx6/apalis_imx6.c > > @@ -75,6 +75,11 @@ int dram_init(void) > > gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, > > (ulong)imx_ddr_size()); > > > > + /* Subtract the defined OPTEE runtime firmware length */ #ifdef > > +CONFIG_OPTEE_TZDRAM_SIZE > > + gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE; #endif > > + > > Has OPTEE been enabled? I not see that in defconfig. Not yet enable by default, this is just to make it compatible with OP-TEE. Should we have it enabled by default at apalis_imx6_defconfig? I could also send another patch to add a new config that has secure boot and OP-TEE enabled by default, as done with a few other imx targets. Thanks, -- Ricardo Salveti ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] apalis_imx6: fix broken fsl_esdhc_imx conversion
On Tue, Sep 3, 2019 at 9:58 AM Max Krummenacher <
max.krummenac...@toradex.com> wrote:
> On Mon, 2019-09-02 at 18:12 -0300, Ricardo Salveti wrote:
> > Commit e37ac717d796 ("Convert to use fsl_esdhc_imx for i.MX platforms")
> > converted FSL_ESDHC to FSL_ESDHC_IMX, but the config check for
> > apalis_imx6 wasn't updated accordantly.
> >
> > Signed-off-by: Ricardo Salveti
> > ---
> > board/toradex/apalis_imx6/apalis_imx6.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/toradex/apalis_imx6/apalis_imx6.c
> b/board/toradex/apalis_imx6/apalis_imx6.c
> > index ef668fcedc..89680da53f 100644
> > --- a/board/toradex/apalis_imx6/apalis_imx6.c
> > +++ b/board/toradex/apalis_imx6/apalis_imx6.c
> > @@ -93,7 +93,7 @@ iomux_v3_cfg_t const uart1_pads_dte[] = {
> > MX6_PAD_CSI0_DAT11__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
> > };
> >
> > -#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
> > +#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
> > /* Apalis MMC1 */
> > iomux_v3_cfg_t const usdhc1_pads[] = {
> > MX6_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > @@ -290,7 +290,7 @@ int board_ehci_hcd_init(int port)
> > }
> > #endif
> >
> > -#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
> > +#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
> > /* use the following sequence: eMMC, MMC1, SD1 */
> > struct fsl_esdhc_cfg usdhc_cfg[CONFIG_SYS_FSL_USDHC_NUM] = {
> > {USDHC3_BASE_ADDR},
>
> Acked-by: Max Krummenacher
>
> Thanks for fixing this.
>
> I only found two locations where the conversion from FSL_ESDHC
> to FSL_ESDHC_IMX failed, the one fixed with this patch and of
> the
> same pattern one in the colibri_imx6.c board file.
>
> Do you anyway plan to send a similar patch set for Colibri iMX6?
> Otherwise I will prepare a fixup patch for the specific issue
> addressed here for Colibri iMX6.
>
Indeed, no worries, I will send a similar one fixing colibri as well.
Thanks,
--
Ricardo Salveti
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] kconfig: doc: Update comment regarding CONFIG_IS_ENABLED(FOO) for TPL
This patch adds some commit info for CONFIG_IS_ENABLED(FOO) when used in TPL context. Signed-off-by: Lukasz Majewski --- include/linux/kconfig.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h index fbfc7188b8..3a2da738c4 100644 --- a/include/linux/kconfig.h +++ b/include/linux/kconfig.h @@ -75,6 +75,7 @@ * CONFIG_VAL(FOO) evaluates to the value of * CONFIG_FOO if CONFIG_SPL_BUILD is undefined, * CONFIG_SPL_FOO if CONFIG_SPL_BUILD is defined. + * CONFIG_TPL_FOO if CONFIG_TPL_BUILD is defined. */ #define CONFIG_VAL(option) config_val(option) @@ -82,6 +83,7 @@ * CONFIG_IS_ENABLED(FOO) evaluates to * 1 if CONFIG_SPL_BUILD is undefined and CONFIG_FOO is set to 'y' or 'm', * 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y' or 'm', + * 1 if CONFIG_TPL_BUILD is defined and CONFIG_TPL_FOO is set to 'y' or 'm', * 0 otherwise. */ #define CONFIG_IS_ENABLED(option) \ -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] doc: fix: Replace SPL_OF_PLATDATA with OF_PLATDATA in examples
The of-plat.rst file till this change has been using
This is at best misleading as SPL_OF_PLATDATA is always defined when we
want to use this SPL tinification feature (also in U-Boot proper).
As a result the OF_PLATDATA SPL specific code is also compiled in when
U-Boot proper is build.
Signed-off-by: Lukasz Majewski
Reviewed-by: Peng Fan
---
doc/driver-model/of-plat.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/driver-model/of-plat.rst b/doc/driver-model/of-plat.rst
index 0d3cd8c01e..a38e58e4d2 100644
--- a/doc/driver-model/of-plat.rst
+++ b/doc/driver-model/of-plat.rst
@@ -224,7 +224,7 @@ For example:
#include
struct mmc_platdata {
-#if CONFIG_IS_ENABLED(SPL_OF_PLATDATA)
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
/* Put this first since driver model will copy the data here */
struct dtd_mmc dtplat;
#endif
@@ -237,7 +237,7 @@ For example:
static int mmc_ofdata_to_platdata(struct udevice *dev)
{
-#if !CONFIG_IS_ENABLED(SPL_OF_PLATDATA)
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
/* Decode the device tree data */
struct mmc_platdata *plat = dev_get_platdata(dev);
const void *blob = gd->fdt_blob;
@@ -253,7 +253,7 @@ For example:
{
struct mmc_platdata *plat = dev_get_platdata(dev);
-#if CONFIG_IS_ENABLED(SPL_OF_PLATDATA)
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
/* Decode the of-platdata from the C structures */
struct dtd_mmc *dtplat = >dtplat;
@@ -308,7 +308,7 @@ The dt-structs.h file includes the generated file
(include/generated//dt-structs.h) if CONFIG_SPL_OF_PLATDATA is enabled.
Otherwise (such as in U-Boot proper) these structs are not available. This
prevents them being used inadvertently. All usage must be bracketed with
-#if CONFIG_IS_ENABLED(SPL_OF_PLATDATA).
+#if CONFIG_IS_ENABLED(OF_PLATDATA).
The dt-platdata.c file contains the device declarations and is is built in
spl/dt-platdata.c.
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] apalis_imx6: fix broken fsl_esdhc_imx conversion
On Mon, 2019-09-02 at 18:12 -0300, Ricardo Salveti wrote:
> Commit e37ac717d796 ("Convert to use fsl_esdhc_imx for i.MX platforms")
> converted FSL_ESDHC to FSL_ESDHC_IMX, but the config check for
> apalis_imx6 wasn't updated accordantly.
>
> Signed-off-by: Ricardo Salveti
> ---
> board/toradex/apalis_imx6/apalis_imx6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/toradex/apalis_imx6/apalis_imx6.c
> b/board/toradex/apalis_imx6/apalis_imx6.c
> index ef668fcedc..89680da53f 100644
> --- a/board/toradex/apalis_imx6/apalis_imx6.c
> +++ b/board/toradex/apalis_imx6/apalis_imx6.c
> @@ -93,7 +93,7 @@ iomux_v3_cfg_t const uart1_pads_dte[] = {
> MX6_PAD_CSI0_DAT11__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
> };
>
> -#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
> +#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
> /* Apalis MMC1 */
> iomux_v3_cfg_t const usdhc1_pads[] = {
> MX6_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> @@ -290,7 +290,7 @@ int board_ehci_hcd_init(int port)
> }
> #endif
>
> -#if defined(CONFIG_FSL_ESDHC) && defined(CONFIG_SPL_BUILD)
> +#if defined(CONFIG_FSL_ESDHC_IMX) && defined(CONFIG_SPL_BUILD)
> /* use the following sequence: eMMC, MMC1, SD1 */
> struct fsl_esdhc_cfg usdhc_cfg[CONFIG_SYS_FSL_USDHC_NUM] = {
> {USDHC3_BASE_ADDR},
Acked-by: Max Krummenacher
Thanks for fixing this.
I only found two locations where the conversion from FSL_ESDHC
to FSL_ESDHC_IMX failed, the one fixed with this patch and of
the
same pattern one in the colibri_imx6.c board file.
Do you anyway plan to send a similar patch set for Colibri iMX6?
Otherwise I will prepare a fixup patch for the specific issue
addressed here for Colibri iMX6.
Max
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE
On Mon, 2019-09-02 at 18:21 -0300, Ricardo Salveti wrote: > OP-TEE uses the memory region defined by the maximum DRAM address minus > CONFIG_OPTEE_TZDRAM_SIZE, so subtract CONFIG_OPTEE_TZDRAM_SIZE from the > available DRAM size to avoid conflicts. > > Signed-off-by: Ricardo Salveti > --- > board/toradex/apalis_imx6/apalis_imx6.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/board/toradex/apalis_imx6/apalis_imx6.c > b/board/toradex/apalis_imx6/apalis_imx6.c > index 6421a22c25..fa7fcc8d46 100644 > --- a/board/toradex/apalis_imx6/apalis_imx6.c > +++ b/board/toradex/apalis_imx6/apalis_imx6.c > @@ -75,6 +75,11 @@ int dram_init(void) > gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, > (ulong)imx_ddr_size()); > > + /* Subtract the defined OPTEE runtime firmware length */ > +#ifdef CONFIG_OPTEE_TZDRAM_SIZE > + gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE; > +#endif > + > return 0; > } > > Acked-by: Max Krummenacher ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] apalis_imx6: add board_fit_config_name_match to support FIT in SPL
On Mon, 2019-09-02 at 18:23 -0300, Ricardo Salveti wrote:
> Only one dtb is currently supported, so match with imx6-apalis.
>
> Signed-off-by: Ricardo Salveti
> ---
> board/toradex/apalis_imx6/apalis_imx6.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/board/toradex/apalis_imx6/apalis_imx6.c
> b/board/toradex/apalis_imx6/apalis_imx6.c
> index fa7fcc8d46..ef668fcedc 100644
> --- a/board/toradex/apalis_imx6/apalis_imx6.c
> +++ b/board/toradex/apalis_imx6/apalis_imx6.c
> @@ -1121,6 +1121,16 @@ void board_init_f(ulong dummy)
> board_init_r(NULL, 0);
> }
>
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + if (!strcmp(name, "imx6-apalis"))
> + return 0;
> +
> + return -1;
> +}
> +#endif
> +
> void reset_cpu(ulong addr)
> {
> }
I assume that you do not want to switch on CONFIG_SPL_LOAD_FIT
(or OP-TEE) for the apalis_imx6_defconfig but do this rather as
a preparation for a board variant.
Acked-by: Max Krummenacher
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: apalis_imx6: select MX6Q via Kconfig
On Mon, 2019-09-02 at 18:26 -0300, Ricardo Salveti wrote: > Toradex Apalis iMX6 modules are available in the iMX6D and iMX6Q > variants, which are quite similar and already managed via only one > dtb in u-boot (imx6-apalis.dtb). Select MX6Q via Kconfig by default in > order to automatically enable the HAS_CAAM and MX6_SMP features. > > Signed-off-by: Ricardo Salveti > --- > arch/arm/mach-imx/mx6/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig > index 9c27176ba0..36e1c98fb5 100644 > --- a/arch/arm/mach-imx/mx6/Kconfig > +++ b/arch/arm/mach-imx/mx6/Kconfig > @@ -117,6 +117,7 @@ config TARGET_ADVANTECH_DMS_BA16 > config TARGET_APALIS_IMX6 > bool "Toradex Apalis iMX6 board" > select BOARD_LATE_INIT > + select MX6Q > select DM > select DM_SERIAL > select DM_THERMAL Acked-by: Max Krummenacher ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver
Hi Jean,
>
>
> On 02/09/2019 13:29, Sherry Sun wrote:
> > Hi Vignesh,
> >
> >> Hi Sherry,
> >>
> >> [...]
> AFAIK, U-Boot does not support runtime switching of USB port to
> host from device and vice versa. This is the case for existing
> driver like
> >> DWC3/MUSB etc.
> Ideally we would need a role switch driver that unbinds and rebinds
> host vs device driver as when required based on U-Boot cmd or via
> an API (if required to be done during SPL stage etc).
> >>> I wonder if we can add two subnodes under the wrapper node as below,
> >> one bind to usb gadget driver and another bind to usb host driver.
> >>> So if we want to use usb device, just call the gadget driver, and if
> >>> want to
> >> use usb host, just call the host driver. The driver will probe correspond
> node.
> >>> I'm not sure if it is feasible, what do you think about it?
> >>>
> >>>usbss0: cdns_usb@4104000 {
> >>>compatible = "ti,j721e-usb";
> >>>[]
> >>>usb0: usb@601 {/* xhci reg address*/
> >>>compatible = "cdns,usb3-1.0.1";
> >>> dr_mode = "host";
> >>> []
> >>> }
> >>>usb1: usb@602 {/* dev reg address*/
> >>>compatible = "cdns,usb3-1.0.1";
> >>> dr_mode = "peripheral";
> >>> []
> >>> }
> >>> }
> >>>
> >> But this is not how DT would look in kernel. There will be single DT
> >> node representing both Host and Device node. DT repesentation should
> >> not be changed based on OS/bootloader, its HW description and must
> remain same.
> >> Unbinding host/gadget driver and rebinding with a different role
> >> should not be hard as the U-Boot core infrastructure exists.
> >>
> >> Moreover if xhci reg and dev reg are separated into different nodes
> >> dont we still need access to OTG register block to switch b/w host and
> device mode?
> > I think we may not need to access OTG register if we add two subnodes for
> gadget and host.
> >
> > But I see a for loop in dwc3_glue_bind() as follows, if there only one
> > single
> node representing both Host and Device node under usb wrapper node, why
> we need this for loop?
> >
> > 212 for (node = fdt_first_subnode(fdt, dev_of_offset(parent)); node > 0;
> > 213 node = fdt_next_subnode(fdt, node)) {
>
> I believe this is a legacy from the code it was inspired from.
>
> Indeed the loop is not required.
>
> Like Vignesh I think we must stick with the dt-bindings used by the kernel.
Thanks for your reply, I understand now.
>
> BTW we are working on the USB3 support right now that is lacking in our tree.
> I choose to keep the PHY drivers as close as possible to their linux version.
> I'll
> probably start posting preliminary patches this week.
>
> If you have the USB3 working in the kernel, can you point to a tree where I
> can have a look at the drivers and dt-bindings ?
Sure, you can see our downstream kernel code at my github, here is the link
address: https://github.com/sherrysun1/linux-imx.git.
And look forward to seeing your patches in uboot maillist.
Best regards
Sherry sun
>
> JJ
>
> >
> > Best regards
> > Sherry sun
> >
> >> Regards
> >> Vignesh
> >>
> >>> Best regards
> >>> Sherry sun
> >>>
> Regards
> Vignesh
>
> > Best regards
> > Sherry sun
> >
> >> JJ
> >>
> Then when binding the wrapper node, it will hard-coded the two
> >> subnodes
> to different driver(gadge/host driver) according to the dr_mode
> property
> >> in
> nodes.
>
> >>> Do you think I understand it right?
> >>> Best regards
> >>> Sherry sun
> >>>
> Best regards
> Sherry sun
>
> > JJ
> >
> >
> >
> >>> + { }
> >>> +};
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://l
>
> >>
> ists.ddata=02%7C01%7Csherry.sun%40nxp.com%7C7d1d76a7124f4c3f
> e9
> >>
> 9d08d72d3ddf82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 70276
> >>
> 16080089878sdata=70BPVQkomokcNpxsHRD3njfZQvuG51VSD1QKBjQ
> o1kA%3
> Dreserved=0
> enx.de%2Flistinfo%2Fu-
>
> >>
> bootdata=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
> >>
> 670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> >>
> C637025710721487079sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI
> GrNOxDH6HC0%3Dreserved=0
> --
> Regards
> Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
