Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Pali, On 2/25/23 23:00, Pali Rohár wrote: On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote: This patch series contains various improvements and fixes for existing logical errors. Boot phase was adjusted to match behavior of Armada 385 BootROM by inspecting and disassembling of BootROM binary dump itself. Important information are included in documentation patch for kwboot. Most of the changes are untested, hence this patch series is just RFC. So please test changes before applying, idealy on SPI, SATA and SD/MMC. Nevertheless all patches on github passed CI testing in this PR: https://github.com/u-boot/u-boot/pull/275 Patches were tested on more boards and seems there is no reported issue, but other improvements. So do you need something to modify in this relatively big patch series? If it is not really needed I would like to not send it again because denx servers are not able to handle it. And it take me lot of time to send patches over emails to denx servers. I'm fine with applying the series as-is. I'm a bit hesitant though, if it should be applied to master or to next. As Tom clearly noticed, that only fixes should be added after rc2 this time. What is your thinking on this? Thanks, Stefan Pali Rohár (59): tools: kwbimage: Fix generating, verifying and extracting SDIO kwbimage tools: kwboot: Fix parsing SDIO kwbimage arm: mvebu: spl: Fix parsing SDIO kwbimage cmd: mvebu/bubt: Fix parsing SDIO kwbimage tools: kwbimage: Fix generating, verifying and extracting SATA kwbimage tools: kwboot: Fix parsing SATA kwbimage arm: mvebu: spl: Fix parsing SATA kwbimage cmd: mvebu/bubt: Fix parsing SATA kwbimage arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2 arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION arm: mvebu: spl: Fix support for loading U-Boot proper from SD card tools: kwboot: Add more documentation references tools: kwboot: Add image type documentation tools: kwboot: Fix parsing UART image without data checksum tools: kwboot: Validate optional kwbimage v1 headers tools: kwboot: Add check that kwbimage contains DDR init code tools: kwboot: Fix patching of SPI/NOR XIP images tools: kwboot: Show image type and error parsing reasons cmd: mvebu/bubt: Add support for selecting eMMC HW partition cmd: mvebu/bubt: Add support for writing image to SATA disk cmd: mvebu/bubt: Add support for reading image from the SATA disk partition cmd: mvebu/bubt: Rename variable image_size to hdr_size cmd: mvebu/bubt: Mark all local symbols as static cmd: mvebu/bubt: Do not modify image in A8K check_image_header() cmd: mvebu/bubt: Check also A8K boot image checksum cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and 'fuse_read_u64' defined but not used cmd: mvebu/bubt: Enable command by default tools: kwbimage: Fix dumping register set / DATA commands tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION tools: kwbimage: Fix dumping NAND_BLKSZ tools: kwbimage: Fix generating of kwbimage v0 header checksum tools: kwbimage: Fix endianity when printing kwbimage header tools: kwbimage: Reject mkimage -F option tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images tools: kwbimage: Print binary image offset as size tools: kwbimage: Print image data offset when printing kwbimage header tools: kwbimage: Simplify add_secure_header_v1() tools: kwbimage: Rename imagesz to dataoff tools: kwbimage: Fix generating secure boot data image signature tools: kwbimage: Fix invalid secure boot header signature tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images tools: kwbimage: Add support for XIP SPI/NOR images tools: mkimage: Print human readable error when -d is not specified tools: mkimage: Do not try to open datafile when it is skipped tools: kwbimage: Add support for creating an image with no data arm: mvebu: Add support for generating NAND kwbimage arm: mvebu: Add support for generating PEX kwbimage arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting arm: mvebu: clearfog: Add defconfig for SATA booting arm: mvebu: Remove A39x relicts arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot arm: mvebu: Define SPL memory maps doc/kwboot.1: Update example description arch/arm/mach-mvebu/Kconfig | 23 +- arch/arm/mach-mvebu/Makefile | 13 + arch/arm/mach-mvebu/cpu.c | 11 +-
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Tony, On 2/27/23 01:11, Tony Dinh wrote: Hi Pali, On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: Hi Martin, On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: I'm not sure how to run proper timing tests on the process, but stopwatch timing just between seeing "Trying to boot" and "U-Boot 2023.04-rc2" showed the return to BootROM under 1 second, and the direct from SPI around 4 seconds. I thought the goal of loading from SPI directly was speed, but returning to BootROM is significantly faster on this board. You should check SPI speed in DTS file and also in the defconfig. I think we have probably seen this slowdown before. There is a TODO in the way the DTS nodes are parsed by DM uclass. So this config must be set in defconfig to get around that bug: CONFIG_SF_DEFAULT_SPEED=5000 That works and is much faster now. I'll submit it in a V2 for these two patches once Pali's mvebu changes are accepted. Only question I have is: should the faster speed be applied to all three defconfigs? CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the MMC and SATA configs at the moment. This is only a workaround to get the SPI probe to work correctly. The real fix should be in spi_flash_probe() ./common/spl/spl_spi.c flash = spi_flash_probe(sf_bus, sf_cs, CONFIG_SF_DEFAULT_SPEED, CONFIG_SF_DEFAULT_MODE); If spi_flash_probe() failed to get SPI max_hz from the DTS, the fallback is CONFIG_SF_DEFAULT_SPEED. IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or some other common place. And when we will have fixed the DTS parsing problem, they can be removed. I'd like to hear from Stefan and Pali if this approach sounds good. All the best, Tony Well, the maximal SPI speed depends on the wiring. You can have on the board some SPI device which does not support high frequency. But having some sane defaults in Kconfig for mvebu makes sense. Agreed. The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig does not specify it. I think the sane default value is 10_000_000 (grepping the Armada* DTS files showing the slowest spi-max-frequency is 10_000_000). While a big improvement, it is not fast enough for many other boards. So we still need to define it in those board defconfigs (before fixing that bug), or use return to BootROM. I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. Not sure if this should be done in drivers/mtd/spi/Kconfig, as this currently has no platform- / board- specific configurations. Perhaps it can be done in a mach-mvebu Kconfig file instead? Thanks, Stefan
Re: [PATCH v1 09/11] rockchip: move dwc3 config to chip specific handler
On Tue, Feb 22, 2022 at 7:03 AM Peter Geis wrote: > > The dwc3 code in the mach-rockchip board file is specific to the rk3399. > Move it to the rk3399 chip specific code. Though it is rk3399, there is no new SoC that requires OTG as of now even if needed it is easy to support here instead of moving this redundant on each board file. https://patchwork.ozlabs.org/project/uboot/patch/20230226132234.31949-2-abbaraju.manoj...@amarulasolutions.com/ So, please don't move. Jagan.
Re: [PATCH] kconfig: Proposed language extension for multiple builds
Hi Masahiro, On Sun, 26 Feb 2023 at 20:36, Masahiro Yamada wrote: > > Hi Simon, > > On Mon, Feb 27, 2023 at 4:23 AM Simon Glass wrote: > > > > Hi Masahiro, > > > > On Sun, 26 Feb 2023 at 10:36, Masahiro Yamada wrote: > > > > > > On Sun, Feb 26, 2023 at 11:44 PM Tom Rini wrote: > > > > > > > > On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > > > > > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass > > > > > wrote: > > > > > > > > > > > > Hi Masahiro, > > > > > > > > > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not know. > > > > > > > This seems a shorthand in Kconfig level. > > > > > > > > > > > > > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > > > > > 5401080 24872 > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > > > > > 163 3267462 > > > > > > > > > > > > > > If hundreds of duplications are not manageable, > > > > > > > go for it, but kconfig will be out-of-sync from the > > > > > > > upstream Kconfig. > > > > > > > > > > > > Yes that's right, it is a shorthand in Kconfig. > > > > > > > > > > > > The counts above understand the problem a little since quite a few > > > > > > CONFIG options without an SPL prefix are used in SPL. We don't have > > > > > > tools to estimate how many, and we sometimes add a new symbol to > > > > > > 'gain > > > > > > control' of a particular feature in a phase. > > > > > > > > > > > > My intent in sending this patch was to check whether this support > > > > > > for > > > > > > configuring multiple related builds (or something like it) could go > > > > > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > > > > > > > > > > > > > This complexity is absolutely unneeded for Linux. > > > > > > > > > > So, the answer is no. > > > > > > > > Well, I think Simon summarized himself a bit shorter here than he did in > > > > the patch itself. So, to what extent does the kernel want to consider > > > > all of the other projects using the Kconfig language and their needs / > > > > use cases? > > > > > > > > -- > > > > Tom > > > > > > > > > > > > In principle, only features that are useful for Linux. > > > > I'm disappointed in this attitude. It is the same thing that we saw > > from the DT bindings until recently. > > > Sorry, but this is the maintainer's job. > Saying no is one of the most important jobs as a maintainer. > > I must avoid Kconfig getting Frankenstein mechanisms. Can you suggest a better approach? > > > > > > Kconfig has small piece of code that is useful for other projects, > > > for example, > > > > > > #ifndef CONFIG_ > > > #define CONFIG_ "CONFIG_" > > > #endif > > > > > > which might be useful for Buildroot, but this is exceptionally small. > > > > How about refactoring patches that would make a possible > > implementation easier to maintain, like [1] ? Would they be > > acceptable? > > > Code refactoring is welcome, but [1] is not applicable. > U-Boot kconfig is synced with Linux 4.20, way behind the mainline Linux. Sure, I wasn't suggesting that exact patch. It should be easy enough to move to the latest version. It sounds like it may be possible to make the Frankenstein patches easier to maintain out of tree, if we go that way. > > > > > > > > > The multi-phase is too cluttered, and that is not what Linux wants to > > > have. > > > > Clearly it is not useful to Linux, which only has one build. > > > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-...@chromium.org/ Regards, Simon
Re: [PATCH] kconfig: Proposed language extension for multiple builds
Hi Simon, On Mon, Feb 27, 2023 at 4:23 AM Simon Glass wrote: > > Hi Masahiro, > > On Sun, 26 Feb 2023 at 10:36, Masahiro Yamada wrote: > > > > On Sun, Feb 26, 2023 at 11:44 PM Tom Rini wrote: > > > > > > On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > > > > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > > > > > > > > > Hi Masahiro, > > > > > > > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada > > > > > wrote: > > > > > > > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not know. > > > > > > This seems a shorthand in Kconfig level. > > > > > > > > > > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > > > > 5401080 24872 > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > > > > 163 3267462 > > > > > > > > > > > > If hundreds of duplications are not manageable, > > > > > > go for it, but kconfig will be out-of-sync from the > > > > > > upstream Kconfig. > > > > > > > > > > Yes that's right, it is a shorthand in Kconfig. > > > > > > > > > > The counts above understand the problem a little since quite a few > > > > > CONFIG options without an SPL prefix are used in SPL. We don't have > > > > > tools to estimate how many, and we sometimes add a new symbol to 'gain > > > > > control' of a particular feature in a phase. > > > > > > > > > > My intent in sending this patch was to check whether this support for > > > > > configuring multiple related builds (or something like it) could go > > > > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > > > > > > > > > > This complexity is absolutely unneeded for Linux. > > > > > > > > So, the answer is no. > > > > > > Well, I think Simon summarized himself a bit shorter here than he did in > > > the patch itself. So, to what extent does the kernel want to consider > > > all of the other projects using the Kconfig language and their needs / > > > use cases? > > > > > > -- > > > Tom > > > > > > > > In principle, only features that are useful for Linux. > > I'm disappointed in this attitude. It is the same thing that we saw > from the DT bindings until recently. Sorry, but this is the maintainer's job. Saying no is one of the most important jobs as a maintainer. I must avoid Kconfig getting Frankenstein mechanisms. > > > > Kconfig has small piece of code that is useful for other projects, > > for example, > > > > #ifndef CONFIG_ > > #define CONFIG_ "CONFIG_" > > #endif > > > > which might be useful for Buildroot, but this is exceptionally small. > > How about refactoring patches that would make a possible > implementation easier to maintain, like [1] ? Would they be > acceptable? Code refactoring is welcome, but [1] is not applicable. U-Boot kconfig is synced with Linux 4.20, way behind the mainline Linux. > > > > > > The multi-phase is too cluttered, and that is not what Linux wants to have. > > Clearly it is not useful to Linux, which only has one build. > > Regards, > Simon > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-...@chromium.org/ -- Best Regards Masahiro Yamada
Re: i.MX8M binman
Hi Simon, On 2/13/2023 9:09 AM, Simon Glass wrote: Hi Peng, On Fri, 10 Feb 2023 at 07:06, Simon Glass wrote: Hi Peng, On Fri, 10 Feb 2023 at 04:55, Peng Fan wrote: +Marek, I heard that from Marek on IRC, but Marek ask me to reach you. Actually I am not sure what is the issue with i.MX8M binman node. Was this to do with getting the security stuff into binman properly? I do recall trying that, but them Marek ran out of time. That is here: https://github.com/sjg20/u-boot/tree/mx8 It should be pretty close to working. Do you want to take a look? sorry for late reply. Busy on other stuff. I will give a look and back to you later. Thanks, Peng. Regards, Simon Regards, Simon Thanks, Peng. On 2/7/2023 9:38 PM, Simon Glass wrote: Hi Peng, On Mon, 6 Feb 2023 at 05:43, Peng Fan wrote: Hi Simon, I heard that you found i.MX8M binman has some issues, would you please share me the details? Then I could find some time to address those issues. Sorry, I can't remember that. Do you have more context? Regards, SImon
Re: [PATCH] arm: dts: ls1088a-rdb: replace 'xgmii' with '10gbase-r'
On 2/22/2023 10:17 PM, Ioana Ciornei wrote:
When the first device tree description was added for the ethernet nodes,
the 2 10G ports on the LS1088ARDB were wrongly described as 'xgmii'.
Fix this by replacing the two last occurrences of 'xgmii' in the device
trees of the Layerscape DPAA2 devices.
Fixes: 68c7c008e84a ("arm: dts: ls1088ardb: add DPMAC and PHY nodes")
Signed-off-by: Ioana Ciornei
Reviewed-by: Peng Fan
---
arch/arm/dts/fsl-ls1088a-rdb.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1088a-rdb.dts b/arch/arm/dts/fsl-ls1088a-rdb.dts
index ad059437b534..01f8fcb61aef 100644
--- a/arch/arm/dts/fsl-ls1088a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1088a-rdb.dts
@@ -19,13 +19,13 @@
{
status = "okay";
- phy-connection-type = "xgmii";
+ phy-connection-type = "10gbase-r";
};
{
status = "okay";
phy-handle = <_phy1>;
- phy-connection-type = "xgmii";
+ phy-connection-type = "10gbase-r";
};
{
Re: [PATCH 0/5] board: freescale: remove non-DM_ETH code for Layerscape DPAA2 platforms
For the patchset,
Reviewed-by: Peng Fan
On 2/15/2023 11:31 PM, Ioana Ciornei wrote:
Now that DM_ETH is enabled by default and even the ldpaa_eth driver
doesn't have support for the non-DM_ETH use case (see commit below),
remove non-DM_ETH code from the board files.
commit cde5a844fbba ("net: ldpaa_eth: Remove non-DM_ETH code")
There is no point in keeping around the creation of the MDIO bus or the
hardcoded MDIO PHY addresses since we have these described in the DTS.
And if there is any RCW combination which is still not supported /
described by DTS we can always look in the commit history.
Ioana Ciornei (5):
board: freescale: lx2160a: remove hardcoded ethernet initialization
board: freescale: lx2160a: remove code under !CONFIG_DM_ETH
board: freescale: ls2080rdb: remove code under !CONFIG_DM_ETH
board: freescale: ls2080aqds: remove code under !CONFIG_DM_ETH
board: freescale: ls1088a: remove code under !CONFIG_DM_ETH
board/freescale/ls1088a/eth_ls1088aqds.c | 739 +---
board/freescale/ls1088a/eth_ls1088ardb.c | 93 --
board/freescale/ls1088a/ls1088a.c | 2 +-
board/freescale/ls2080aqds/eth.c | 981 +
board/freescale/ls2080aqds/ls2080aqds.c| 2 +-
board/freescale/ls2080ardb/eth_ls2080rdb.c | 95 --
board/freescale/ls2080ardb/ls2080ardb.c| 2 +-
board/freescale/lx2160a/eth_lx2160aqds.c | 825 +
board/freescale/lx2160a/eth_lx2160ardb.c | 176
board/freescale/lx2160a/eth_lx2162aqds.c | 844 +-
board/freescale/lx2160a/lx2160a.c | 6 +-
11 files changed, 17 insertions(+), 3748 deletions(-)
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Pali, On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: > > On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > > Hi Martin, > > > > On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: > > > > > > > > > I'm not sure how to run proper timing tests on the process, but > > > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > > > > SPI directly was speed, but returning to BootROM is significantly > > > > > > faster on this board. > > > > > > > > > > You should check SPI speed in DTS file and also in the defconfig. > > > > > > > > I think we have probably seen this slowdown before. There is a TODO in > > > > the way the DTS nodes are parsed by DM uclass. So this config must be > > > > set in defconfig to get around that bug: > > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > > > That works and is much faster now. I'll submit it in a V2 for these > > > two patches once Pali's mvebu changes are accepted. Only question I > > > have is: should the faster speed be applied to all three defconfigs? > > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > > MMC and SATA configs at the moment. > > > > This is only a workaround to get the SPI probe to work correctly. The > > real fix should be in spi_flash_probe() > > ./common/spl/spl_spi.c > > flash = spi_flash_probe(sf_bus, sf_cs, > > CONFIG_SF_DEFAULT_SPEED, > > CONFIG_SF_DEFAULT_MODE); > > If spi_flash_probe() failed to get SPI max_hz from the DTS, the > > fallback is CONFIG_SF_DEFAULT_SPEED. > > > > IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > > CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > > some other common place. And when we will have fixed the DTS parsing > > problem, they can be removed. > > > > I'd like to hear from Stefan and Pali if this approach sounds good. > > > > All the best, > > Tony > > Well, the maximal SPI speed depends on the wiring. You can have on the > board some SPI device which does not support high frequency. > > But having some sane defaults in Kconfig for mvebu makes sense. The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig does not specify it. I think the sane default value is 10_000_000 (grepping the Armada* DTS files showing the slowest spi-max-frequency is 10_000_000). While a big improvement, it is not fast enough for many other boards. So we still need to define it in those board defconfigs (before fixing that bug), or use return to BootROM. All the best, Tony,
Re: [PATCH] kconfig: Proposed language extension for multiple builds
Hi Masahiro, On Sun, 26 Feb 2023 at 10:36, Masahiro Yamada wrote: > > On Sun, Feb 26, 2023 at 11:44 PM Tom Rini wrote: > > > > On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > > > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > > > > > > > Hi Masahiro, > > > > > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada > > > > wrote: > > > > > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass > > > > > wrote: > > > > > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > > > > > > > > > > > I do not know. > > > > > This seems a shorthand in Kconfig level. > > > > > > > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > > > 5401080 24872 > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > > > 163 3267462 > > > > > > > > > > If hundreds of duplications are not manageable, > > > > > go for it, but kconfig will be out-of-sync from the > > > > > upstream Kconfig. > > > > > > > > Yes that's right, it is a shorthand in Kconfig. > > > > > > > > The counts above understand the problem a little since quite a few > > > > CONFIG options without an SPL prefix are used in SPL. We don't have > > > > tools to estimate how many, and we sometimes add a new symbol to 'gain > > > > control' of a particular feature in a phase. > > > > > > > > My intent in sending this patch was to check whether this support for > > > > configuring multiple related builds (or something like it) could go > > > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > > > > > > > This complexity is absolutely unneeded for Linux. > > > > > > So, the answer is no. > > > > Well, I think Simon summarized himself a bit shorter here than he did in > > the patch itself. So, to what extent does the kernel want to consider > > all of the other projects using the Kconfig language and their needs / > > use cases? > > > > -- > > Tom > > > > In principle, only features that are useful for Linux. I'm disappointed in this attitude. It is the same thing that we saw from the DT bindings until recently. > > Kconfig has small piece of code that is useful for other projects, > for example, > > #ifndef CONFIG_ > #define CONFIG_ "CONFIG_" > #endif > > which might be useful for Buildroot, but this is exceptionally small. How about refactoring patches that would make a possible implementation easier to maintain, like [1] ? Would they be acceptable? > > > The multi-phase is too cluttered, and that is not what Linux wants to have. Clearly it is not useful to Linux, which only has one build. Regards, Simon [1] https://patchwork.ozlabs.org/project/uboot/patch/20230212231638.1134219-61-...@chromium.org/
[PATCH v2 09/11] video: tegra20: add DSI controller driver
Adds support for both DSI outputs found on Tegra. Only very
minimal functionality is implemented, so advanced features
like ganged mode won't work. Driver is heavily based on
mainline Tegra DSI and re-uses much of its features.
Only T30 is supported for now but T20 support can be added
if any supported devices will be found.
Driver is wrapped as panel driver since Tegra DC driver supports
only panel drivers calls.
Tested-by: Andreas Westman Dorcsak # ASUS TF600T T30
Tested-by: Svyatoslav Ryhel # HTC One X T30
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/include/asm/arch-tegra30/dsi.h | 217 ++
drivers/video/tegra20/Kconfig | 9 +
drivers/video/tegra20/Makefile | 1 +
drivers/video/tegra20/mipi-phy.c| 134
drivers/video/tegra20/mipi-phy.h| 48 ++
drivers/video/tegra20/tegra-dsi.c | 864
6 files changed, 1273 insertions(+)
create mode 100644 arch/arm/include/asm/arch-tegra30/dsi.h
create mode 100644 drivers/video/tegra20/mipi-phy.c
create mode 100644 drivers/video/tegra20/mipi-phy.h
create mode 100644 drivers/video/tegra20/tegra-dsi.c
diff --git a/arch/arm/include/asm/arch-tegra30/dsi.h
b/arch/arm/include/asm/arch-tegra30/dsi.h
new file mode 100644
index 00..7ade132613
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra30/dsi.h
@@ -0,0 +1,217 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2010
+ * NVIDIA Corporation
+ */
+
+#ifndef __ASM_ARCH_TEGRA_DSI_H
+#define __ASM_ARCH_TEGRA_DSI_H
+
+#ifndef __ASSEMBLY__
+#include
+#endif
+
+/* Register definitions for the Tegra display serial interface */
+
+/* DSI syncpoint register 0x000 ~ 0x002 */
+struct dsi_syncpt_reg {
+ /* Address 0x000 ~ 0x002 */
+ uint incr_syncpt; /* _INCR_SYNCPT_0 */
+ uint incr_syncpt_ctrl; /* _INCR_SYNCPT_CNTRL_0 */
+ uint incr_syncpt_err; /* _INCR_SYNCPT_ERROR_0 */
+};
+
+/* DSI misc register 0x008 ~ 0x015 */
+struct dsi_misc_reg {
+ /* Address 0x008 ~ 0x015 */
+ uint ctxsw; /* _CTXSW_0 */
+ uint dsi_rd_data; /* _DSI_RD_DATA_0 */
+ uint dsi_wr_data; /* _DSI_WR_DATA_0 */
+ uint dsi_pwr_ctrl; /* _DSI_POWER_CONTROL_0 */
+ uint int_enable;/* _INT_ENABLE_0 */
+ uint int_status;/* _INT_STATUS_0 */
+ uint int_mask; /* _INT_MASK_0 */
+ uint host_dsi_ctrl; /* _HOST_DSI_CONTROL_0 */
+ uint dsi_ctrl; /* _DSI_CONTROL_0 */
+ uint dsi_sol_delay; /* _DSI_SOL_DELAY_0 */
+ uint dsi_max_threshold; /* _DSI_MAX_THRESHOLD_0 */
+ uint dsi_trigger; /* _DSI_TRIGGER_0 */
+ uint dsi_tx_crc;/* _DSI_TX_CRC_0 */
+ uint dsi_status;/* _DSI_STATUS_0 */
+};
+
+/* DSI init sequence register 0x01a ~ 0x022 */
+struct dsi_init_seq_reg {
+ /* Address 0x01a ~ 0x022 */
+ uint dsi_init_seq_ctrl; /* _DSI_INIT_SEQ_CONTROL_0 */
+ uint dsi_init_seq_data_0; /* _DSI_INIT_SEQ_DATA_0_0 */
+ uint dsi_init_seq_data_1; /* _DSI_INIT_SEQ_DATA_1_0 */
+ uint dsi_init_seq_data_2; /* _DSI_INIT_SEQ_DATA_2_0 */
+ uint dsi_init_seq_data_3; /* _DSI_INIT_SEQ_DATA_3_0 */
+ uint dsi_init_seq_data_4; /* _DSI_INIT_SEQ_DATA_4_0 */
+ uint dsi_init_seq_data_5; /* _DSI_INIT_SEQ_DATA_5_0 */
+ uint dsi_init_seq_data_6; /* _DSI_INIT_SEQ_DATA_6_0 */
+ uint dsi_init_seq_data_7; /* _DSI_INIT_SEQ_DATA_7_0 */
+};
+
+/* DSI packet sequence register 0x023 ~ 0x02e */
+struct dsi_pkt_seq_reg {
+ /* Address 0x023 ~ 0x02e */
+ uint dsi_pkt_seq_0_lo; /* _DSI_PKT_SEQ_0_LO_0 */
+ uint dsi_pkt_seq_0_hi; /* _DSI_PKT_SEQ_0_HI_0 */
+ uint dsi_pkt_seq_1_lo; /* _DSI_PKT_SEQ_1_LO_0 */
+ uint dsi_pkt_seq_1_hi; /* _DSI_PKT_SEQ_1_HI_0 */
+ uint dsi_pkt_seq_2_lo; /* _DSI_PKT_SEQ_2_LO_0 */
+ uint dsi_pkt_seq_2_hi; /* _DSI_PKT_SEQ_2_HI_0 */
+ uint dsi_pkt_seq_3_lo; /* _DSI_PKT_SEQ_3_LO_0 */
+ uint dsi_pkt_seq_3_hi; /* _DSI_PKT_SEQ_3_HI_0 */
+ uint dsi_pkt_seq_4_lo; /* _DSI_PKT_SEQ_4_LO_0 */
+ uint dsi_pkt_seq_4_hi; /* _DSI_PKT_SEQ_4_HI_0 */
+ uint dsi_pkt_seq_5_lo; /* _DSI_PKT_SEQ_5_LO_0 */
+ uint dsi_pkt_seq_5_hi; /* _DSI_PKT_SEQ_5_HI_0 */
+};
+
+/* DSI packet length register 0x033 ~ 0x037 */
+struct dsi_pkt_len_reg {
+ /* Address 0x033 ~ 0x037 */
+ uint dsi_dcs_cmds; /* _DSI_DCS_CMDS_0 */
+ uint dsi_pkt_len_0_1; /* _DSI_PKT_LEN_0_1_0 */
+ uint dsi_pkt_len_2_3; /* _DSI_PKT_LEN_2_3_0 */
+ uint dsi_pkt_len_4_5; /* _DSI_PKT_LEN_4_5_0 */
+ uint dsi_pkt_len_6_7; /* _DSI_PKT_LEN_6_7_0 */
+};
[PATCH v2 11/11] simple_panel: support simple MIPI DSI panels
Re-use simple panel driver for MIPI DSI panels
which do not require additional DSI commands
for setup.
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Andreas Westman Dorcsak # ASUS TF700T T30
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/simple_panel.c | 37
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c
index 5a8262669a..81fcafb9f5 100644
--- a/drivers/video/simple_panel.c
+++ b/drivers/video/simple_panel.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,6 +19,19 @@ struct simple_panel_priv {
struct gpio_desc enable;
};
+/* List of supported DSI panels */
+enum {
+ PANEL_NON_DSI,
+ PANASONIC_VVX10F004B00,
+};
+
+static const struct mipi_dsi_panel_plat panasonic_vvx10f004b00 = {
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+ .format = MIPI_DSI_FMT_RGB888,
+ .lanes = 4,
+};
+
static int simple_panel_enable_backlight(struct udevice *dev)
{
struct simple_panel_priv *priv = dev_get_priv(dev);
@@ -96,6 +110,8 @@ static int simple_panel_of_to_plat(struct udevice *dev)
static int simple_panel_probe(struct udevice *dev)
{
struct simple_panel_priv *priv = dev_get_priv(dev);
+ struct mipi_dsi_panel_plat *plat = dev_get_plat(dev);
+ const u32 dsi_data = dev_get_driver_data(dev);
int ret;
if (IS_ENABLED(CONFIG_DM_REGULATOR) && priv->reg) {
@@ -105,6 +121,16 @@ static int simple_panel_probe(struct udevice *dev)
return ret;
}
+ switch (dsi_data) {
+ case PANASONIC_VVX10F004B00:
+ memcpy(plat, _vvx10f004b00,
+ sizeof(panasonic_vvx10f004b00));
+ break;
+ case PANEL_NON_DSI:
+ default:
+ break;
+ }
+
return 0;
}
@@ -123,15 +149,18 @@ static const struct udevice_id simple_panel_ids[] = {
{ .compatible = "lg,lb070wv8" },
{ .compatible = "sharp,lq123p1jx31" },
{ .compatible = "boe,nv101wxmn51" },
+ { .compatible = "panasonic,vvx10f004b00",
+ .data = PANASONIC_VVX10F004B00 },
{ }
};
U_BOOT_DRIVER(simple_panel) = {
- .name = "simple_panel",
- .id = UCLASS_PANEL,
- .of_match = simple_panel_ids,
- .ops= _panel_ops,
+ .name = "simple_panel",
+ .id = UCLASS_PANEL,
+ .of_match = simple_panel_ids,
+ .ops= _panel_ops,
.of_to_plat = simple_panel_of_to_plat,
.probe = simple_panel_probe,
.priv_auto = sizeof(struct simple_panel_priv),
+ .plat_auto = sizeof(struct mipi_dsi_panel_plat),
};
--
2.37.2
[PATCH v2 10/11] simple_panel: add support for get_display_timing
Some cases may require passing display timings from
panel driver. To handle such cases support parsing
device tree panel node for timing subnode.
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Svyatoslav Ryhel # Google Nexus 7 2012
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/simple_panel.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c
index 91c91ee75d..5a8262669a 100644
--- a/drivers/video/simple_panel.c
+++ b/drivers/video/simple_panel.c
@@ -48,6 +48,15 @@ static int simple_panel_set_backlight(struct udevice *dev,
int percent)
return 0;
}
+static int simple_panel_get_display_timing(struct udevice *dev,
+ struct display_timing *timings)
+{
+ const void *blob = gd->fdt_blob;
+
+ return fdtdec_decode_display_timing(blob, dev_of_offset(dev),
+ 0, timings);
+}
+
static int simple_panel_of_to_plat(struct udevice *dev)
{
struct simple_panel_priv *priv = dev_get_priv(dev);
@@ -102,6 +111,7 @@ static int simple_panel_probe(struct udevice *dev)
static const struct panel_ops simple_panel_ops = {
.enable_backlight = simple_panel_enable_backlight,
.set_backlight = simple_panel_set_backlight,
+ .get_display_timing = simple_panel_get_display_timing,
};
static const struct udevice_id simple_panel_ids[] = {
--
2.37.2
[PATCH v2 08/11] video: tegra-dc: pass DC regmap to internal devices
Internal video devices like DSI and HDMI controllers
require sending commands into DC register field.
To make this available, lets create platform data,
which is restricted to pass DC regmap only to
pre-defined devices.
Tested-by: Andreas Westman Dorcsak # ASUS TF T30
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Svyatoslav Ryhel # HTC One X T30
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/include/asm/arch-tegra/dc.h | 8
drivers/video/tegra20/tegra-dc.c | 8
2 files changed, 16 insertions(+)
diff --git a/arch/arm/include/asm/arch-tegra/dc.h
b/arch/arm/include/asm/arch-tegra/dc.h
index 6444af2993..7613d84f22 100644
--- a/arch/arm/include/asm/arch-tegra/dc.h
+++ b/arch/arm/include/asm/arch-tegra/dc.h
@@ -569,4 +569,12 @@ enum {
#define DC_N_WINDOWS 5
#define DC_REG_SAVE_SPACE (DC_N_WINDOWS + 5)
+#define TEGRA_DSI_A"dsi@5430"
+#define TEGRA_DSI_B"dsi@5440"
+
+struct tegra_dc_plat {
+ struct udevice *dev;/* Display controller device */
+ struct dc_ctlr *dc; /* Display controller regmap */
+};
+
#endif /* __ASM_ARCH_TEGRA_DC_H */
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 00462fa188..f53ad46397 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -417,6 +417,14 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
return ret;
}
+ if (!strcmp(priv->panel->name, TEGRA_DSI_A) ||
+ !strcmp(priv->panel->name, TEGRA_DSI_B)) {
+ struct tegra_dc_plat *dc_plat = dev_get_plat(priv->panel);
+
+ dc_plat->dev = dev;
+ dc_plat->dc = priv->dc;
+ }
+
ret = panel_get_display_timing(priv->panel, >timing);
if (ret) {
ret = fdtdec_decode_display_timing(blob, rgb, 0, >timing);
--
2.37.2
[PATCH v2 07/11] video: tegra-dc: add panel_set_backlight call
Tegra DC driver does not call panel_set_backlight, which can
result in absence of backlight on device. Fix this by calling
panel_set_backlight with BACKLIGHT_DEFAULT just after
panel_enable_backlight.
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Andreas Westman Dorcsak # ASUS TF T30
Tested-by: Svyatoslav Ryhel # LG P895 T30
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/tegra20/tegra-dc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index e279650922..00462fa188 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -345,6 +346,12 @@ static int tegra_lcd_probe(struct udevice *dev)
return ret;
}
+ ret = panel_set_backlight(priv->panel, BACKLIGHT_DEFAULT);
+ if (ret) {
+ debug("%s: Cannot set backlight to default, ret=%d\n",
__func__, ret);
+ return ret;
+ }
+
mmu_set_region_dcache_behaviour(priv->frame_buffer, plat->size,
DCACHE_WRITETHROUGH);
--
2.37.2
[PATCH v2 06/11] video: tegra-dc: add 180 degree panel rotation
Unlike 90 and 270 degree rotation, 180 degree rotation is more
common and does not require scaling. Implement it for correct
grouper support.
Tested-by: Andreas Westman Dorcsak # Google Nexus 7 2012
Tested-by: Svyatoslav Ryhel # Google Nexus 7 2012
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/tegra20/tegra-dc.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index e004ee362f..e279650922 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -37,6 +37,7 @@ struct tegra_lcd_priv {
fdt_addr_t frame_buffer;/* Address of frame buffer */
unsigned pixel_clock; /* Pixel clock in Hz */
int dc_clk[2]; /* Contains clk and its parent */
+ bool rotation; /* 180 degree panel turn */
};
enum {
@@ -46,8 +47,10 @@ enum {
LCD_MAX_LOG2_BPP= VIDEO_BPP16,
};
-static void update_window(struct dc_ctlr *dc, struct disp_ctl_win *win)
+static void update_window(struct tegra_lcd_priv *priv,
+ struct disp_ctl_win *win)
{
+ struct dc_ctlr *dc = priv->dc;
unsigned h_dda, v_dda;
unsigned long val;
@@ -88,6 +91,10 @@ static void update_window(struct dc_ctlr *dc, struct
disp_ctl_win *win)
val = WIN_ENABLE;
if (win->bpp < 24)
val |= COLOR_EXPAND;
+
+ if (priv->rotation)
+ val |= H_DIRECTION | V_DIRECTION;
+
writel(val, >win.win_opt);
writel((unsigned long)win->phys_addr, >winbuf.start_addr);
@@ -224,8 +231,14 @@ static void rgb_enable(struct dc_com_reg *com)
static int setup_window(struct disp_ctl_win *win,
struct tegra_lcd_priv *priv)
{
- win->x = 0;
- win->y = 0;
+ if (priv->rotation) {
+ win->x = priv->width * 2;
+ win->y = priv->height;
+ } else {
+ win->x = 0;
+ win->y = 0;
+ }
+
win->w = priv->width;
win->h = priv->height;
win->out_x = 0;
@@ -298,7 +311,7 @@ static int tegra_display_probe(const void *blob, struct
tegra_lcd_priv *priv,
if (setup_window(, priv))
return -1;
- update_window(priv->dc, );
+ update_window(priv, );
return 0;
}
@@ -370,6 +383,8 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
return -EINVAL;
}
+ priv->rotation = dev_read_bool(dev, "nvidia,180-rotation");
+
rgb = fdt_subnode_offset(blob, node, "rgb");
if (rgb < 0) {
debug("%s: Cannot find rgb subnode for '%s' (ret=%d)\n",
--
2.37.2
[PATCH v2 05/11] video: tegra-dc: assign regmap directly
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Andreas Westman Dorcsak # ASUS TF T30
Tested-by: Svyatoslav Ryhel # LG P895 T30
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/tegra20/tegra-dc.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 91298b7b7f..e004ee362f 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -33,7 +33,7 @@ struct tegra_lcd_priv {
enum video_log2_bpp log2_bpp; /* colour depth */
struct display_timing timing;
struct udevice *panel;
- struct disp_ctlr *disp; /* Display controller to use */
+ struct dc_ctlr *dc; /* Display controller regmap */
fdt_addr_t frame_buffer;/* Address of frame buffer */
unsigned pixel_clock; /* Pixel clock in Hz */
int dc_clk[2]; /* Contains clk and its parent */
@@ -269,13 +269,10 @@ static int tegra_display_probe(const void *blob, struct
tegra_lcd_priv *priv,
void *default_lcd_base)
{
struct disp_ctl_win window;
- struct dc_ctlr *dc;
unsigned long rate = clock_get_rate(priv->dc_clk[1]);
priv->frame_buffer = (u32)default_lcd_base;
- dc = (struct dc_ctlr *)priv->disp;
-
/*
* We halve the rate if DISP1 paret is PLLD, since actual parent
* is plld_out0 which is PLLD divided by 2.
@@ -291,17 +288,17 @@ static int tegra_display_probe(const void *blob, struct
tegra_lcd_priv *priv,
clock_start_periph_pll(priv->dc_clk[0], priv->dc_clk[1],
rate);
- basic_init(>cmd);
- basic_init_timer(>disp);
- rgb_enable(>com);
+ basic_init(>dc->cmd);
+ basic_init_timer(>dc->disp);
+ rgb_enable(>dc->com);
if (priv->pixel_clock)
- update_display_mode(>disp, priv);
+ update_display_mode(>dc->disp, priv);
if (setup_window(, priv))
return -1;
- update_window(dc, );
+ update_window(priv->dc, );
return 0;
}
@@ -360,8 +357,8 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
int rgb;
int ret;
- priv->disp = dev_read_addr_ptr(dev);
- if (!priv->disp) {
+ priv->dc = (struct dc_ctlr *)dev_read_addr_ptr(dev);
+ if (!priv->dc) {
debug("%s: No display controller address\n", __func__);
return -EINVAL;
}
--
2.37.2
[PATCH v2 04/11] video: tegra-dc: request timings from panel driver first
Check if panel driver has display timings and get those.
If panel driver does not pass timing, try to find timing
under rgb node for backwards compatibility.
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Andreas Westman Dorcsak # ASUS TF T30
Tested-by: Svyatoslav Ryhel # LG P895 T30
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/tegra20/tegra-dc.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index ff67cc8989..91298b7b7f 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -380,18 +380,6 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
return -EINVAL;
}
- ret = fdtdec_decode_display_timing(blob, rgb, 0, >timing);
- if (ret) {
- debug("%s: Cannot read display timing for '%s' (ret=%d)\n",
- __func__, dev->name, ret);
- return -EINVAL;
- }
- timing = >timing;
- priv->width = timing->hactive.typ;
- priv->height = timing->vactive.typ;
- priv->pixel_clock = timing->pixelclock.typ;
- priv->log2_bpp = VIDEO_BPP16;
-
/*
* Sadly the panel phandle is in an rgb subnode so we cannot use
* uclass_get_device_by_phandle().
@@ -401,6 +389,7 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
debug("%s: Cannot find panel information\n", __func__);
return -EINVAL;
}
+
ret = uclass_get_device_by_of_offset(UCLASS_PANEL, panel_node,
>panel);
if (ret) {
@@ -409,6 +398,22 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
return ret;
}
+ ret = panel_get_display_timing(priv->panel, >timing);
+ if (ret) {
+ ret = fdtdec_decode_display_timing(blob, rgb, 0, >timing);
+ if (ret) {
+ debug("%s: Cannot read display timing for '%s'
(ret=%d)\n",
+ __func__, dev->name, ret);
+ return -EINVAL;
+ }
+ }
+
+ timing = >timing;
+ priv->width = timing->hactive.typ;
+ priv->height = timing->vactive.typ;
+ priv->pixel_clock = timing->pixelclock.typ;
+ priv->log2_bpp = VIDEO_BPP16;
+
return 0;
}
--
2.37.2
[PATCH v2 03/11] video: tegra-dc: get clocks from device tree
DISP1 clock may use PLLP, PLLC and PLLD as parents.
Instead of hardcoding, lets pass clock and its
parent from device tree. Default parent is PLLP.
Tested-by: Robert Eckelmann # ASUS TF101 T20
Tested-by: Nicolas Chauvet # Paz00
Tested-by: Andreas Westman Dorcsak # ASUS TF T30
Tested-by: Svyatoslav Ryhel # HTC One X T30
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/tegra20/tegra-dc.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/video/tegra20/tegra-dc.c b/drivers/video/tegra20/tegra-dc.c
index 5e3f6bf029..ff67cc8989 100644
--- a/drivers/video/tegra20/tegra-dc.c
+++ b/drivers/video/tegra20/tegra-dc.c
@@ -36,6 +36,7 @@ struct tegra_lcd_priv {
struct disp_ctlr *disp; /* Display controller to use */
fdt_addr_t frame_buffer;/* Address of frame buffer */
unsigned pixel_clock; /* Pixel clock in Hz */
+ int dc_clk[2]; /* Contains clk and its parent */
};
enum {
@@ -134,7 +135,7 @@ static int update_display_mode(struct dc_disp_reg *disp,
* the display clock (typically 600MHz) to the pixel clock. We round
* up or down as requried.
*/
- rate = clock_get_periph_rate(PERIPH_ID_DISP1, CLOCK_ID_CGENERAL);
+ rate = clock_get_periph_rate(priv->dc_clk[0], priv->dc_clk[1]);
div = ((rate * 2 + priv->pixel_clock / 2) / priv->pixel_clock) - 2;
debug("Display clock %lu, divider %lu\n", rate, div);
@@ -269,20 +270,27 @@ static int tegra_display_probe(const void *blob, struct
tegra_lcd_priv *priv,
{
struct disp_ctl_win window;
struct dc_ctlr *dc;
+ unsigned long rate = clock_get_rate(priv->dc_clk[1]);
priv->frame_buffer = (u32)default_lcd_base;
dc = (struct dc_ctlr *)priv->disp;
/*
-* A header file for clock constants was NAKed upstream.
-* TODO: Put this into the FDT and fdt_lcd struct when we have clock
-* support there
+* We halve the rate if DISP1 paret is PLLD, since actual parent
+* is plld_out0 which is PLLD divided by 2.
*/
- clock_start_periph_pll(PERIPH_ID_HOST1X, CLOCK_ID_PERIPH,
- 144 * 100);
- clock_start_periph_pll(PERIPH_ID_DISP1, CLOCK_ID_CGENERAL,
- 600 * 100);
+ if (priv->dc_clk[1] == CLOCK_ID_DISPLAY)
+ rate /= 2;
+
+ /*
+* HOST1X is init by default at 150MHz with PLLC as parent
+*/
+ clock_start_periph_pll(PERIPH_ID_HOST1X, CLOCK_ID_CGENERAL,
+ 150 * 100);
+ clock_start_periph_pll(priv->dc_clk[0], priv->dc_clk[1],
+ rate);
+
basic_init(>cmd);
basic_init_timer(>disp);
rgb_enable(>com);
@@ -358,6 +366,13 @@ static int tegra_lcd_of_to_plat(struct udevice *dev)
return -EINVAL;
}
+ ret = clock_decode_pair(dev, priv->dc_clk);
+ if (ret < 0) {
+ debug("%s: Cannot decode clocks for '%s' (ret = %d)\n",
+ __func__, dev->name, ret);
+ return -EINVAL;
+ }
+
rgb = fdt_subnode_offset(blob, node, "rgb");
if (rgb < 0) {
debug("%s: Cannot find rgb subnode for '%s' (ret=%d)\n",
--
2.37.2
[PATCH v2 01/11] tegra: lcd: video: integrate display driver for t30
From: Marcel Ziswiler
On popular request make the display driver from T20 work on T30 as
well. Turned out to be quite straight forward. However a few notes
about some things encountered during porting: Of course the T30 device
tree was completely missing host1x as well as PWM support but it turns
out this can simply be copied from T20. The only trouble compiling the
Tegra video driver for T30 had to do with some hard-coded PWM pin
muxing for T20 which is quite ugly anyway. On T30 this gets handled by
a board specific complete pin muxing table. The older Chromium U-Boot
2011.06 which to my knowledge was the only prior attempt at enabling a
display driver for T30 for whatever reason got some clocking stuff
mixed up. Turns out at least for a single display controller T20 and
T30 can be clocked quite similar. Enjoy.
Tested-by: Andreas Westman Dorcsak # ASUS TF T30
Tested-by: Jonas Schwöbel # Surface RT T30
Tested-by: Svyatoslav Ryhel # LG P895 T30
Signed-off-by: Marcel Ziswiler
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/dts/tegra30-u-boot.dtsi| 9 +++
arch/arm/include/asm/arch-tegra30/display.h | 28 +
arch/arm/include/asm/arch-tegra30/pwm.h | 13 ++
drivers/video/tegra.c | 10 ++--
4 files changed, 58 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra30/display.h
create mode 100644 arch/arm/include/asm/arch-tegra30/pwm.h
diff --git a/arch/arm/dts/tegra30-u-boot.dtsi b/arch/arm/dts/tegra30-u-boot.dtsi
index 7c11972552..cf17fa803b 100644
--- a/arch/arm/dts/tegra30-u-boot.dtsi
+++ b/arch/arm/dts/tegra30-u-boot.dtsi
@@ -1,3 +1,12 @@
#include
#include "tegra-u-boot.dtsi"
+
+/ {
+ host1x@5000 {
+ u-boot,dm-pre-reloc;
+ dc@5420 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
diff --git a/arch/arm/include/asm/arch-tegra30/display.h
b/arch/arm/include/asm/arch-tegra30/display.h
new file mode 100644
index 00..9411525799
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra30/display.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2010
+ * NVIDIA Corporation
+ */
+
+#ifndef __ASM_ARCH_TEGRA_DISPLAY_H
+#define __ASM_ARCH_TEGRA_DISPLAY_H
+
+#include
+
+/* This holds information about a window which can be displayed */
+struct disp_ctl_win {
+ enum win_color_depth_id fmt;/* Color depth/format */
+ unsigned intbpp;/* Bits per pixel */
+ phys_addr_t phys_addr; /* Physical address in memory */
+ unsigned intx; /* Horizontal address offset (bytes) */
+ unsigned inty; /* Veritical address offset (bytes) */
+ unsigned intw; /* Width of source window */
+ unsigned inth; /* Height of source window */
+ unsigned intstride; /* Number of bytes per line */
+ unsigned intout_x; /* Left edge of output window (col) */
+ unsigned intout_y; /* Top edge of output window (row) */
+ unsigned intout_w; /* Width of output window in pixels */
+ unsigned intout_h; /* Height of output window in pixels */
+};
+
+#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/
diff --git a/arch/arm/include/asm/arch-tegra30/pwm.h
b/arch/arm/include/asm/arch-tegra30/pwm.h
new file mode 100644
index 00..c314e2b5ad
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra30/pwm.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Tegra pulse width frequency modulator definitions
+ *
+ * Copyright (c) 2011 The Chromium OS Authors.
+ */
+
+#ifndef __ASM_ARCH_TEGRA30_PWM_H
+#define __ASM_ARCH_TEGRA30_PWM_H
+
+#include
+
+#endif /* __ASM_ARCH_TEGRA30_PWM_H */
diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c
index 3f9fcd0403..5e3f6bf029 100644
--- a/drivers/video/tegra.c
+++ b/drivers/video/tegra.c
@@ -40,8 +40,8 @@ struct tegra_lcd_priv {
enum {
/* Maximum LCD size we support */
- LCD_MAX_WIDTH = 1366,
- LCD_MAX_HEIGHT = 768,
+ LCD_MAX_WIDTH = 1920,
+ LCD_MAX_HEIGHT = 1200,
LCD_MAX_LOG2_BPP= VIDEO_BPP16,
};
@@ -307,14 +307,19 @@ static int tegra_lcd_probe(struct udevice *dev)
int ret;
/* Initialize the Tegra display controller */
+#ifdef CONFIG_TEGRA20
funcmux_select(PERIPH_ID_DISP1, FUNCMUX_DEFAULT);
+#endif
+
if (tegra_display_probe(blob, priv, (void *)plat->base)) {
printf("%s: Failed to probe display driver\n", __func__);
return -1;
}
+#ifdef CONFIG_TEGRA20
pinmux_set_func(PMUX_PINGRP_GPU, PMUX_FUNC_PWM);
pinmux_tristate_disable(PMUX_PINGRP_GPU);
+#endif
ret = panel_enable_backlight(priv->panel);
if (ret) {
@@ -414,6 +419,7 @@ static const struct video_ops tegra_lcd_ops = {
static
[PATCH v2 02/11] video: move tegra dc driver into own folder
Signed-off-by: Svyatoslav Ryhel
---
drivers/video/Kconfig | 11 ++-
drivers/video/Makefile| 2 +-
drivers/video/tegra20/Kconfig | 8
drivers/video/tegra20/Makefile| 3 +++
drivers/video/{tegra.c => tegra20/tegra-dc.c} | 0
5 files changed, 14 insertions(+), 10 deletions(-)
create mode 100644 drivers/video/tegra20/Kconfig
create mode 100644 drivers/video/tegra20/Makefile
rename drivers/video/{tegra.c => tegra20/tegra-dc.c} (100%)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2a76d19cc8..a7f38efbb7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -638,15 +638,6 @@ source "drivers/video/stm32/Kconfig"
source "drivers/video/tidss/Kconfig"
-config VIDEO_TEGRA20
- bool "Enable LCD support on Tegra20"
- depends on OF_CONTROL
- help
- Tegra20 supports video output to an attached LCD panel as well as
- other options such as HDMI. Only the LCD is supported in U-Boot.
- This option enables this support which can be used on devices which
- have an LCD display connected.
-
config VIDEO_TEGRA124
bool "Enable video support on Tegra124"
help
@@ -657,6 +648,8 @@ config VIDEO_TEGRA124
source "drivers/video/bridge/Kconfig"
+source "drivers/video/tegra20/Kconfig"
+
source "drivers/video/imx/Kconfig"
config VIDEO_MXS
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index cdb7d9a54d..e3c7b15d15 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -61,10 +61,10 @@ obj-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o
obj-$(CONFIG_VIDEO_DSI_HOST_SANDBOX) += sandbox_dsi_host.o
obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
-obj-$(CONFIG_VIDEO_TEGRA20) += tegra.o
obj-$(CONFIG_VIDEO_VESA) += vesa.o
obj-$(CONFIG_VIDEO_SEPS525) += seps525.o
obj-$(CONFIG_VIDEO_ZYNQMP_DPSUB) += zynqmp_dpsub.o
obj-y += bridge/
obj-y += sunxi/
+obj-y += tegra20/
diff --git a/drivers/video/tegra20/Kconfig b/drivers/video/tegra20/Kconfig
new file mode 100644
index 00..2a4036b898
--- /dev/null
+++ b/drivers/video/tegra20/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_TEGRA20
+ bool "Enable Display Controller support on Tegra20 and Tegra 30"
+ depends on OF_CONTROL
+ help
+ T20/T30 support video output to an attached LCD panel as well as
+ other options such as HDMI. Only the LCD is supported in U-Boot.
+ This option enables this support which can be used on devices which
+ have an LCD display connected.
diff --git a/drivers/video/tegra20/Makefile b/drivers/video/tegra20/Makefile
new file mode 100644
index 00..4517923025
--- /dev/null
+++ b/drivers/video/tegra20/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_VIDEO_TEGRA20) += tegra-dc.o
diff --git a/drivers/video/tegra.c b/drivers/video/tegra20/tegra-dc.c
similarity index 100%
rename from drivers/video/tegra.c
rename to drivers/video/tegra20/tegra-dc.c
--
2.37.2
[PATCH v2 00/11] Tegra DC improvements
This patch set is dedicated to improvement of video support
on T20 and T30 devices. It contains:
- DC driver improvements (T30 support was added into existing T20
DC driver, it was moved into own folder, added support of reading
clocks from dts, improved work with panel ops and implemented
native 180 degree panel rotation support)
- DSI driver bring up (driver is based on mainline Linux one with
minor adjustments, only T30 tested)
- Simple panel driver tweaks (added get_display_timing ops and
implemented simple MIPI DSI panels support)
Patches were successfully tested on Paz00 board with unmodified state
and on TF101 (Ventana board T20) with old binding and with updated
binding. All work without any regressions.
---
Changes from v1:
- DSI driver headers were optimized
- Tested on Paz00 board
---
Marcel Ziswiler (1):
tegra: lcd: video: integrate display driver for t30
Svyatoslav Ryhel (10):
video: move tegra dc driver into own folder
video: tegra-dc: get clocks from device tree
video: tegra-dc: request timings from panel driver first
video: tegra-dc: assign regmap directly
video: tegra-dc: add 180 degree panel rotation
video: tegra-dc: add panel_set_backlight call
video: tegra-dc: pass DC regmap to internal devices
video: tegra20: add DSI controller driver
simple_panel: add support for get_display_timing
simple_panel: support simple MIPI DSI panels
arch/arm/dts/tegra30-u-boot.dtsi | 9 +
arch/arm/include/asm/arch-tegra/dc.h | 8 +
arch/arm/include/asm/arch-tegra30/display.h | 28 +
arch/arm/include/asm/arch-tegra30/dsi.h | 217 +
arch/arm/include/asm/arch-tegra30/pwm.h | 13 +
drivers/video/Kconfig | 11 +-
drivers/video/Makefile| 2 +-
drivers/video/simple_panel.c | 47 +-
drivers/video/tegra20/Kconfig | 17 +
drivers/video/tegra20/Makefile| 4 +
drivers/video/tegra20/mipi-phy.c | 134 +++
drivers/video/tegra20/mipi-phy.h | 48 +
drivers/video/{tegra.c => tegra20/tegra-dc.c} | 123 ++-
drivers/video/tegra20/tegra-dsi.c | 864 ++
14 files changed, 1476 insertions(+), 49 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra30/display.h
create mode 100644 arch/arm/include/asm/arch-tegra30/dsi.h
create mode 100644 arch/arm/include/asm/arch-tegra30/pwm.h
create mode 100644 drivers/video/tegra20/Kconfig
create mode 100644 drivers/video/tegra20/Makefile
create mode 100644 drivers/video/tegra20/mipi-phy.c
create mode 100644 drivers/video/tegra20/mipi-phy.h
rename drivers/video/{tegra.c => tegra20/tegra-dc.c} (82%)
create mode 100644 drivers/video/tegra20/tegra-dsi.c
--
2.37.2
Re: [PATCH] kconfig: Proposed language extension for multiple builds
On Sun, Feb 26, 2023 at 11:44 PM Tom Rini wrote: > > On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > > > > > Hi Masahiro, > > > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada > > > wrote: > > > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass wrote: > > > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > > > > > > I do not know. > > > > This seems a shorthand in Kconfig level. > > > > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > > 5401080 24872 > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > > 163 3267462 > > > > > > > > If hundreds of duplications are not manageable, > > > > go for it, but kconfig will be out-of-sync from the > > > > upstream Kconfig. > > > > > > Yes that's right, it is a shorthand in Kconfig. > > > > > > The counts above understand the problem a little since quite a few > > > CONFIG options without an SPL prefix are used in SPL. We don't have > > > tools to estimate how many, and we sometimes add a new symbol to 'gain > > > control' of a particular feature in a phase. > > > > > > My intent in sending this patch was to check whether this support for > > > configuring multiple related builds (or something like it) could go > > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > > > > This complexity is absolutely unneeded for Linux. > > > > So, the answer is no. > > Well, I think Simon summarized himself a bit shorter here than he did in > the patch itself. So, to what extent does the kernel want to consider > all of the other projects using the Kconfig language and their needs / > use cases? > > -- > Tom In principle, only features that are useful for Linux. Kconfig has small piece of code that is useful for other projects, for example, #ifndef CONFIG_ #define CONFIG_ "CONFIG_" #endif which might be useful for Buildroot, but this is exceptionally small. The multi-phase is too cluttered, and that is not what Linux wants to have. -- Best Regards Masahiro Yamada
Re: [PATCH] Reads high bits of DDR type for Rockchip
Hi,
Please try the series at [1], it should solve the same issue you are
trying to solve with this patch. That series is also queued in the
rockchip U-Boot Custodian Tree.
[1]
https://patchwork.ozlabs.org/project/uboot/cover/20230207172707.4094859-1-jo...@kwiboo.se/
Regards,
Jonas
On 2023-02-25 20:15, Recursive G wrote:
> Bit layout decipered from
> https://github.com/rockchip-linux/u-boot/commit/c69667e0e2bf4290ab1f408fcde58b8806ac266b>>
> Tested on a rk3568 device.
>
> Signed-off-by: Recursive G
> ---
> arch/arm/include/asm/arch-rockchip/sdram.h | 3 +++
> arch/arm/mach-rockchip/sdram.c | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/sdram.h
> b/arch/arm/include/asm/arch-rockchip/sdram.h
> index cf2a7b7d10..dec83420bc 100644
> --- a/arch/arm/include/asm/arch-rockchip/sdram.h
> +++ b/arch/arm/include/asm/arch-rockchip/sdram.h
> @@ -61,6 +61,7 @@ enum {
>
> /*
> * sys_reg3 bitfield struct
> + * [13:12] high bits of ddrtype
> * [7] high bit of cs0_row_ch1
> * [6] high bit of cs1_row_ch1
> * [5] high bit of cs0_row_ch0
> @@ -76,6 +77,8 @@ enum {
> #define SYS_REG_EXTEND_CS1_ROW_MASK 1
> #define SYS_REG_CS1_COL_SHIFT(ch) (0 + (ch) * 2)
> #define SYS_REG_CS1_COL_MASK 3
> +#define SYS_REG_DDRTYPE_HI_SHIFT 9
> +#define SYS_REG_DDRTYPE_HI_MASK 0x18
>
> /* Get sdram size decode from reg */
> size_t rockchip_sdram_size(phys_addr_t reg);
> diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
> index e086c47f3c..60ef48eb67 100644
> --- a/arch/arm/mach-rockchip/sdram.c
> +++ b/arch/arm/mach-rockchip/sdram.c
> @@ -90,6 +90,7 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> & SYS_REG_NUM_CH_MASK);
>
> dram_type = (sys_reg2 >> SYS_REG_DDRTYPE_SHIFT) & SYS_REG_DDRTYPE_MASK;
> + dram_type |= (sys_reg3 >> SYS_REG_DDRTYPE_HI_SHIFT) &
> SYS_REG_DDRTYPE_HI_MASK;
> debug("%s %x %x\n", __func__, (u32)reg, sys_reg2);
> for (ch = 0; ch < ch_num; ch++) {
> rank = 1 + (sys_reg2 >> SYS_REG_RANK_SHIFT(ch) &
Re: [PATCH v2 13/26] ringneck-px30: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > When usage_of_is_enabled_check.sh is added, this will show a false > positive for IS_ENABLED(CONFIG_ENV_IS_NOWHERE). > Use IS_ENABLED_NOCHECK to avoid check and error on SPL builds. > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - keep #error, but change condition to use IS_ENABLED_NOCHECK > > board/theobroma-systems/ringneck_px30/ringneck-px30.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 1/1] sandbox: allow building sandbox_spl with CONFIG_DEBUG
Hi Eugen, On Fri, 24 Feb 2023 at 06:59, Eugen Hristev wrote: > > On 2/21/23 21:35, Simon Glass wrote: > > On Sat, 18 Feb 2023 at 01:34, Heinrich Schuchardt > > wrote: > >> > >> Building sandbox_spl with CONFIG_DEBUG leads to errors due to missing > >> symbols: > >> > >> /usr/bin/ld: common/spl/spl_fit.o: in function `spl_fit_upload_fpga': > >> common/spl/spl_fit.c:595: undefined reference to `fpga_load' > >> /usr/bin/ld: test/test-main.o: in function `dm_test_post_run': > >> test/test-main.c:124: undefined reference to `crc8' > >> /usr/bin/ld: test/test-main.o: in function `dm_test_pre_run': > >> test/test-main.c:95: undefined reference to `crc8' > >> collect2: error: ld returned 1 exit status > >> > >> This is due to -Og not eliminating unused functions. > >> > >> Add FPGA and CRC8 support to the defconfig. Sandbox tests for > >> SPL_FPGA and CRC8 should be created. So enabling these setting > >> is advised anyway. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> configs/sandbox_spl_defconfig | 4 > >> 1 file changed, 4 insertions(+) > >> > > > > Reviewed-by: Simon Glass > > Hello Heinrich, Simon, > > I am facing similar issues on different defconfig when enabling > OPTIMIZE_DEBUG. > I don't think enabling SPL_FPGA and DM_FPGA is the solution there. > Do you know why is the drivers/fpga/fpga.c built all the time, with no > Kconfig selected ? That's because the fpga/ directory itself is guarded. > I think that maybe spl_fit_upload_fpga and fpga_load should be built > conditionally , I would like to have SPL load a FIT, but not anything > related to FPGA in my config. Sounds right. Overall the FPGA subsystem could use some work, i.e. a proper uclass API with methods, etc. There is discussion about it elsewhere on the mailing list. Regards, Simon
Re: [PATCH v2 22/26] x86: cpu: i386: cpu: only set pci_ram_top if CONFIG_IS_ENABLED(PCI)
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > This avoids an error when ifdef CONFIG_PCI is changed to > if CONFIG_IS_ENABLED(PCI) > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - use an accessor function gd_set_pci_ram_top > > arch/x86/cpu/i386/cpu.c | 2 +- > include/asm-generic/global_data.h | 6 ++ > 2 files changed, 7 insertions(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 14/26] puma-rk3399: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > When usage_of_is_enabled_check.sh is added, this will show a false > positive for IS_ENABLED(CONFIG_ENV_IS_NOWHERE). > Use IS_ENABLED_NOCHECK to avoid check and error on SPL builds. > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - keep #error, but change condition to use IS_ENABLED_NOCHECK > > board/theobroma-systems/puma_rk3399/puma-rk3399.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v2 20/26] wandboard: use CONFIG_IS_ENABLED(SATA) instead of ifdef CONFIG_SATA
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > Prepare for linking setup_sata only when CONFIG_SATA/CONFIG_SPL_SATA > is defined. > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - new in series > > board/wandboard/wandboard.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v6 5/9] video console: move vidconsole_get_font_size() to test.h
Hi Dzmitry, On Thu, 23 Feb 2023 at 11:10, Dzmitry Sankouski wrote: > > vidconsole_get_font_size is only used in tests and in font > command. It's role in 'font size' command was to only fetch > current font name, to be used in select font function. > This is redundant, because it's easy to check for empty > string, and reuse current name right in select function. > > Test functions in public API use memory and clutter interface. > > Move vidconsole_get_font_size to new cmd/test.h file. > Wrap it's implementation with #ifdef only when tests enabled. > > Signed-off-by: Dzmitry Sankouski > --- > Changes for v2: N/A > Changes for v3: N/A > Charges for v4: N/A > Charges for v5: N/A > Charges for v6: N/A > > cmd/font.c | 5 ++--- > drivers/video/console_truetype.c | 8 +++- > include/cmd/test.h | 19 +++ > include/video_console.h | 9 - > test/cmd/font.c | 1 + > 5 files changed, 29 insertions(+), 13 deletions(-) > create mode 100644 include/cmd/test.h I'm not a fan of this for three reasons: - it changes the current select_font() API, in which NULL currently means to select the default font, not the current one (although that seems to be broken in the code!) - we may want to allow checking the size of a font - don't want #ifdefs for test in console_truetype.c (tests should ideally just work with the normal plumbing) Regards, Simon
Re: [PATCH v2 19/26] solidrun: mx6cuboxi: use CONFIG_IS_ENABLED(SATA) instead of CONFIG_CMD_SATA
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > setup_sata is linked with > obj-$(CONFIG_SATA) += sata.o > > So use SATA instead of CMD_SATA. > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - use normal if, not preprocessor > > board/solidrun/mx6cuboxi/mx6cuboxi.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v5 6/6] binman: Mark mkimage entry missing when its subnodes is missing
On Sat, 25 Feb 2023 at 12:01, Jonas Karlman wrote: > > Using the mkimage entry with the multiple-data-files prop and having a > missing external blob result in an unexpected ValueError exception using > the --allow-missing flag. > > ValueError: Filename 'missing.bin' not found in input path (...) > > Fix this by using _pathname that is resolved by ObtainContents for blob > entries, ObtainContents also handles allow missing for external blobs. > > Mark mkimage entry as missing and return without running mkimage when > missing entries is reported by CheckMissing. > > Signed-off-by: Jonas Karlman > --- > v5: > - New patch based on [1] > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20230219220158.4160763-7-jo...@kwiboo.se/ > > tools/binman/etype/mkimage.py | 24 ++- > tools/binman/ftest.py | 11 + > .../test/278_mkimage_missing_multiple.dts | 19 +++ > 3 files changed, 53 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/test/278_mkimage_missing_multiple.dts Reviewed-by: Simon Glass
Re: [PATCH v2 23/26] gateworks: venice: Always define setup_fec and setup_eqos
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > The compiler will optimize away base on IS_ENABLED(CONFIG_FEC_MXC). > It avoids an error in converting to CONFIG_IS_ENABLED(NET). > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - Always define function instead of using same protection > > board/gateworks/venice/venice.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v2 01/26] kconfig: add IS_ENABLED_NOCHECK to bypass usage_of_is_enabled_check
On Fri, 24 Feb 2023 at 11:11, Troy Kisky wrote: > > This is for use when a config with an SPL version needs to always > check the non-spl verion of the config. It avoids error messages > from CI test script usage_of_is_enabled_check.sh > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - new patch > > include/linux/kconfig.h | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH v2 1/1] spl: allow loading via partition type GUID
Hi Heinrich,
On Tue, 21 Feb 2023 at 12:41, Simon Glass wrote:
>
> Hi Heinrich,
>
> On Thu, 16 Feb 2023 at 23:56, Heinrich Schuchardt
> wrote:
> >
> >
> >
> > On 2/17/23 03:55, Simon Glass wrote:
> > > " properHi Heinrich,
> > >
> > > On Thu, 16 Feb 2023 at 14:31, Heinrich Schuchardt
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 2/16/23 21:17, Simon Glass wrote:
> > >>> Hi Heinrich,
> > >>>
> > >>> On Thu, 16 Feb 2023 at 08:30, Heinrich Schuchardt
> > >>> wrote:
> >
> > Some boards provide main U-Boot as a dedicated partition to SPL.
> > Currently we can define either a fixed partition number or an MBR
> > partition type to define which partition is to be used.
> >
> > Partition numbers tend to conflict with established partitioning
> > schemes
> > of Linux distros. MBR partitioning is more and more replaced by GPT
> > partitioning.
> >
> > Allow defining a partition type GUID identifying the partition to load
> > main U-Boot from.
> >
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > v2:
> > avoid if/endif in Kconfig
> > ---
> > common/spl/Kconfig | 27 ++-
> > common/spl/spl_mmc.c | 13 +
> > 2 files changed, 35 insertions(+), 5 deletions(-)
> >
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index 3c2af453ab..9d12b48297 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -514,19 +514,36 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> > used in raw mode
> >
> > config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> > - bool "MMC raw mode: by partition type"
> > + bool "MMC raw mode: by MBR partition type"
> > depends on DOS_PARTITION &&
> > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> > help
> > - Use partition type for specifying U-Boot partition on MMC/SD
> > in
> > + Use MBR partition type for specifying U-Boot partition on
> > MMC/SD in
> > raw mode. U-Boot will be loaded from the first partition
> > of this
> > type to be found.
> >
> > config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
> > - hex "Partition Type on the MMC to load U-Boot from"
> > + hex "MBR Partition Type on the MMC to load U-Boot from"
> > depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> > help
> > - Partition Type on the MMC to load U-Boot from, when the MMC
> > is being
> > - used in raw mode.
> > + MBR Partition Type on the MMC to load U-Boot from, when the
> > MMC is
> > + being used in raw mode.
> > +
> > +config SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> > + bool "MMC raw mode: GPT by partition type"
> > + depends on PARTITION_TYPE_GUID &&
> > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> > + help
> > + Use GPT partition type for specifying U-Boot partition on
> > MMC/SD in
> > + raw mode. U-Boot will be loaded from the first partition of
> > this
> > + type to be found.
> > +
> > +config SYS_MMCSD_RAW_MODE_U_BOOT_GPT_PARTITION_TYPE
> > + string "GPT Partition Type on the MMC to load U-Boot from"
> > + depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> > + default d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6
> > >>>
> > >>> What is this? Can we have a register of these hideous things and call
> > >>> them by name?
> > >
> > > Further, I don't see any documentation on this in U-Boot. Could you at
> > > least add a list of these things?
> > >
> > >>>
> > + help
> > + GPT Partition Type on the MMC to load U-Boot from, when the
> > MMC is
> > + being used in raw mode. The GUID must be lower case, low
> > endian,
> > + and formatted like d2f002f8-e4e7-4269-b8ac-3bb6fabeaff6.
> >
> > config SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
> > bool "Override eMMC EXT_CSC_PART_CONFIG by user defined
> > partition"
> > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > index e4135b2048..69bf1d6e98 100644
> > --- a/common/spl/spl_mmc.c
> > +++ b/common/spl/spl_mmc.c
> > @@ -191,6 +191,19 @@ static int mmc_load_image_raw_partition(struct
> > spl_image_info *spl_image,
> > struct disk_partition info;
> > int err;
> >
> > +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_GPT_PARTITION_TYPE
> > + for (int i = 1; i <= MAX_SEARCH_PARTITIONS; ++i) {
> > + err = part_get_info(mmc_get_blk_desc(mmc), i, );
> > + if (err)
> > + continue;
> > +
Re: [PATCH v6 00/10] vidconsole: refactoring and support for wider fonts
Hi Dzmitry, On Thu, 23 Feb 2023 at 11:10, Dzmitry Sankouski wrote: > > Version 6 contains entire rebased patch series. > New patch 'move vidconsole_get_font_size() to test.h' added. > > Version 5 contain minor changes: > - move common functions to console-core.c file > - remove static keyword from shared functions > > In version 4, only first patch sent, because review fixes to this would add > large rebase & patch formatting overhead. When it'll receive reviewed tag, > I'll resent entire rebased series. > > Modern mobile phones typically have high pixel density. > Bootmenu is hardly readable on those with 8x16 font. > > This patch series aims to add wider fonts for devices with high ppi. > > Add 16x32, 12x22 fonts from linux, and allow font size configuration. > > There was significant changes in version 2: > - fix video tests failures > - add runtime font size configuration > - add test for 12x22 font > > In version 3, > 'video console: add select font logic to vidconsole uclass driver' > patch was removed in favor of already merged patch > 'video: Add font functions to the vidconsole API' > > Dzmitry Sankouski (10): > video console: refactoring and optimization > video console: add support for fonts wider than 1 byte > video console: move 8x16 font data in named header > video console: implement multiple fonts configuration > video console: move vidconsole_get_font_size() to test.h > video console: allow font size configuration at runtime > video console: add 12x22 Sun font from linux > video console: add 16x32 Terminus font from linux > video console: sandbox_defconfig: add 12x22 font > video console: add 12x22 console simple font test > > cmd/Kconfig |8 + > cmd/Makefile|2 +- > cmd/font.c |5 +- > common/splash.c | 17 +- > configs/sandbox_defconfig |5 +- > drivers/video/Kconfig | 30 + > drivers/video/Makefile |6 + > drivers/video/console_core.c| 203 + > drivers/video/console_normal.c | 176 +- > drivers/video/console_rotate.c | 368 +- > drivers/video/console_truetype.c|8 +- > drivers/video/vidconsole_internal.h | 114 + > include/cmd/test.h | 19 + > include/video_console.h |9 - > include/video_font.h| 31 +- > include/video_font_4x6.h| 11 +- > include/video_font_8x16.h | 4624 > include/video_font_data.h | 4644 +--- > include/video_font_sun12x22.h | 6158 +++ > include/video_font_ter16x32.h | 2062 + > test/cmd/font.c |1 + > test/dm/video.c | 41 + > 22 files changed, 13488 insertions(+), 5054 deletions(-) > create mode 100644 drivers/video/console_core.c > create mode 100644 drivers/video/vidconsole_internal.h > create mode 100644 include/cmd/test.h > create mode 100644 include/video_font_8x16.h > create mode 100644 include/video_font_sun12x22.h > create mode 100644 include/video_font_ter16x32.h Apart from my comment on the test code, some minor nits here: If I do this to sandbox_defconfig: #CONFIG_CONSOLE_TRUETYPE=y CONFIG_CMD_SELECT_FONT=y CONFIG_VIDEO_FONT_4X6=y CONFIG_VIDEO_FONT_SUN12X22=y CONFIG_VIDEO_FONT_16X32=y then the 'font list' command crashes. I think console_simple_get_font() needs to check if it is in range. Some odd C code I noticed so please check that: [0]- fonts ([seq])->name- fonts[seq].name Try to keep in 80cols unless it is painful or splits a string. Could we make the 8x16 font first in the list so it is the default? At present if 4x6 is enabled too it comes up, which is a bit hard to read. It would be great if we could get this over the line soon! Regards, Simon
Re: [PATCH] kconfig: Proposed language extension for multiple builds
On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > > > Hi Masahiro, > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada wrote: > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass wrote: > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > I do not know. > > > This seems a shorthand in Kconfig level. > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > 5401080 24872 > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > 163 3267462 > > > > > > If hundreds of duplications are not manageable, > > > go for it, but kconfig will be out-of-sync from the > > > upstream Kconfig. > > > > Yes that's right, it is a shorthand in Kconfig. > > > > The counts above understand the problem a little since quite a few > > CONFIG options without an SPL prefix are used in SPL. We don't have > > tools to estimate how many, and we sometimes add a new symbol to 'gain > > control' of a particular feature in a phase. > > > > My intent in sending this patch was to check whether this support for > > configuring multiple related builds (or something like it) could go > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > This complexity is absolutely unneeded for Linux. > > So, the answer is no. Well, I think Simon summarized himself a bit shorter here than he did in the patch itself. So, to what extent does the kernel want to consider all of the other projects using the Kconfig language and their needs / use cases? -- Tom signature.asc Description: PGP signature
Re: [PATCH] kconfig: Proposed language extension for multiple builds
On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > Hi Masahiro, > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada wrote: > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass wrote: > > > > > > +Masahiro Yamada > > > > > > > > > > I do not know. > > This seems a shorthand in Kconfig level. > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > 5401080 24872 > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > 163 3267462 > > > > If hundreds of duplications are not manageable, > > go for it, but kconfig will be out-of-sync from the > > upstream Kconfig. > > Yes that's right, it is a shorthand in Kconfig. > > The counts above understand the problem a little since quite a few > CONFIG options without an SPL prefix are used in SPL. We don't have > tools to estimate how many, and we sometimes add a new symbol to 'gain > control' of a particular feature in a phase. > > My intent in sending this patch was to check whether this support for > configuring multiple related builds (or something like it) could go > upstream, which for Kconfig is Linux, I believe. What do you think? This complexity is absolutely unneeded for Linux. So, the answer is no. -- Best Regards Masahiro Yamada
Re: [PATCH] kconfig: Proposed language extension for multiple builds
Hi Masahiro, On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada wrote: > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass wrote: > > > > +Masahiro Yamada > > > > > I do not know. > This seems a shorthand in Kconfig level. > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > 5401080 24872 > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > 163 3267462 > > If hundreds of duplications are not manageable, > go for it, but kconfig will be out-of-sync from the > upstream Kconfig. Yes that's right, it is a shorthand in Kconfig. The counts above understand the problem a little since quite a few CONFIG options without an SPL prefix are used in SPL. We don't have tools to estimate how many, and we sometimes add a new symbol to 'gain control' of a particular feature in a phase. My intent in sending this patch was to check whether this support for configuring multiple related builds (or something like it) could go upstream, which for Kconfig is Linux, I believe. What do you think? Regards, Simon > > > > On Fri, 24 Feb 2023 at 19:04, Simon Glass wrote: > >> > >> +lk > >> > >> On Sun, 19 Feb 2023 at 14:55, Simon Glass wrote: > >> > > >> > In the case of Linux, only one build is produced so there is only a > >> > single configuration. For other projects, such as U-Boot and Zephyr, the > >> > same code is used to produce multiple builds, each with related (but > >> > different) options enabled. > >> > > >> > This can be handled with the existing kconfig language, but it is quite > >> > verbose, somewhat tedious and very error-prone, since there is a lot of > >> > duplication. The result is hard to maintain. > >> > > >> > Describe an extension to the Kconfig language to support easier handling > >> > of this use case. > >> > > >> > Signed-off-by: Simon Glass > >> > --- > >> > > >> > Documentation/kbuild/kconfig-language.rst | 134 ++ > >> > 1 file changed, 134 insertions(+) > >> > > >> > diff --git a/Documentation/kbuild/kconfig-language.rst > >> > b/Documentation/kbuild/kconfig-language.rst > >> > index 858ed5d80defe..73fb016a5533f 100644 > >> > --- a/Documentation/kbuild/kconfig-language.rst > >> > +++ b/Documentation/kbuild/kconfig-language.rst > >> > @@ -228,6 +228,24 @@ applicable everywhere (see syntax). > >> >enables the third modular state for all config symbols. > >> >At most one symbol may have the "modules" option set. > >> > > >> > +- phase declaration: "defphase" > >> > + This defines a new build phase. See `Build Phases`_. > >> > + > >> > +- default phase: "phasedefault" > >> > + This indicates the default build phase. See `Build Phases`_. > >> > + > >> > +- add entries for phases: "addphases" > >> > + This creates new phase-specific entries based on a template entry and > >> > adds > >> > + the same attributes to it. See `Build Phases`_. > >> > + > >> > +- set entries for phases: "setphases" > >> > + This sets the phases which need an entry. This allows creating an > >> > entry that > >> > + only has a primary phase. See `Build Phases`_. > >> > + > >> > +- indicate a phase-specific attribute: "forphases" > >> > + This marks an attribute as being applicable only to a particular > >> > phase or > >> > + group of phases. See `Build Phases`_. > >> > + > >> > Menu dependencies > >> > - > >> > > >> > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this > >> > means it's only visible if > >> > MODULES is different from 'n'. The comment on the other hand is only > >> > visible when MODULES is set to 'n'. > >> > > >> > +Build Phases > >> > + > >> > + > >> > +Some projects use Kconfig to control multiple build phases, each phase > >> > +resulting in a separate set of object files and executable. This is the > >> > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_. > >> > + > >> > +Generally the phases are related, so that enabling an entry in the > >> > primary > >> > +phase also enables it by default in the others. But in some cases it may > >> > +be desirable to use separate conditions for each phase. > >> > + > >> > +All phases have a phase name, for example `SPL`. This name is used as a > >> > +prefix to each entry used in that phase, with an underscore in between. > >> > +So if FOO is the primary entry, the equivalent entry for the SPL phase > >> > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry. > >> > + > >> > +Phases are declared like any other menu entry except that also have a > >> > +"defphase" keyword. Phase entries are normally hidden so do not have a > >> > +prompt:: > >> > + > >> > +config PPL > >> > +bool > >> > +defphase "Primary Program Loader" > >> > +phasedefault > >> > +help > >> > + This is the primary bootloader. > >> > + > >> > +config SPL > >> > +bool > >> > +defphase "Secondary Program Loader" > >> > +help > >> > + This is
[PATCH v2 3/3] rk3566: radxa-cm3: Enable USB OTG
Enable USB OTG support and update the fastboot buffer address for Radxa Compute Module 3 IO Board. This would help to use fastboot by default. Signed-off-by: Manoj Sai --- Changes for v2 :- - Updated the fastboot buffer address in drivers/fastboot/Kconfig. --- configs/radxa-cm3-io-rk3566_defconfig | 2 ++ drivers/fastboot/Kconfig | 1 + 2 files changed, 3 insertions(+) diff --git a/configs/radxa-cm3-io-rk3566_defconfig b/configs/radxa-cm3-io-rk3566_defconfig index 2100cf2cb2..aba3a65e7f 100644 --- a/configs/radxa-cm3-io-rk3566_defconfig +++ b/configs/radxa-cm3-io-rk3566_defconfig @@ -21,6 +21,7 @@ CONFIG_DEBUG_UART_BASE=0xFE66 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SYS_LOAD_ADDR=0xc00800 CONFIG_DEBUG_UART=y +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_SPL_LOAD_FIT=y @@ -74,4 +75,5 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_GADGET=y CONFIG_ERRNO_STR=y diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig index eefa34779c..53f0b3a659 100644 --- a/drivers/fastboot/Kconfig +++ b/drivers/fastboot/Kconfig @@ -41,6 +41,7 @@ config FASTBOOT_BUF_ADDR default 0x800800 if ROCKCHIP_RK3288 || ROCKCHIP_RK3329 || \ ROCKCHIP_RK3399 default 0x28 if ROCKCHIP_RK3368 + default 0xc00800 if ROCKCHIP_RK3568 default 0x10 if ARCH_ZYNQMP default 0 if SANDBOX help -- 2.25.1
[PATCH v2 2/3] rockchip: rk356x: update the dwc3_device register offset
update the dwc3_device register offset in board_usb_init()
for rk3568 platforms.
Signed-off-by: Manoj Sai
Reviewed-by: Jagan Teki
---
Changes for v2:-
- None
---
arch/arm/mach-rockchip/board.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index f1f70c81d0..c7729c966a 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -300,6 +300,9 @@ int usb_gadget_handle_interrupts(int index)
int board_usb_init(int index, enum usb_init_type init)
{
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3568))
+ dwc3_device_data.base = 0xfcc0;
+
return dwc3_uboot_init(_device_data);
}
#endif /* CONFIG_USB_DWC3_GADGET */
--
2.25.1
[PATCH v2 1/3] arm: dts: rockchip: rk3566: Enable USB OTG for Radxa CM3
Enable USB OTG support for Radxa Compute Module 3 IO Board
Signed-off-by: Manoj Sai
---
Changes for v2 :-
- None.
Note: Above changeset has sent to kernel mailing list, which is currently under
review.
https://lore.kernel.org/linux-arm-kernel/20230223135929.630787-1-abbaraju.manoj...@amarulasolutions.com/T/#u
---
arch/arm/dts/rk3566-radxa-cm3-io.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io.dts
b/arch/arm/dts/rk3566-radxa-cm3-io.dts
index d89d5263cb..5e4236af4f 100644
--- a/arch/arm/dts/rk3566-radxa-cm3-io.dts
+++ b/arch/arm/dts/rk3566-radxa-cm3-io.dts
@@ -254,6 +254,14 @@
status = "okay";
};
+_otg {
+ status = "okay";
+};
+
+_host0_xhci {
+ status = "okay";
+};
+
{
assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
--
2.25.1
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
On Sun, 26 Feb 2023 at 11:18, Pali Rohár wrote: > On Sunday 26 February 2023 01:45:16 Martin Rowe wrote: > > On Sat, 25 Feb 2023 at 22:14, Pali Rohár wrote: > > > On Saturday 25 February 2023 22:49:56 Pali Rohár wrote: > > > > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote: > > > > > A388 Clearfog MMC is either SD Card or eMMC with different > behaviour for > > > > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. > > > > > > > > > > Signed-off-by: Martin Rowe > > > > > > > > It looks like a hack but I think we do not have a better option for > now. > > > > > > > > If I understand the issue correctly then card-detect pin is > unconnected > > > > for eMMC variant and used for checking if SD card is present for SD > > > > variant. Unconnected pin seems to have some internal pull-up/down > which > > > > reports not-present state for eMMC variant. eMMC does not have any > > > > presence signal, so card-detect pin must be ignored for eMMC. > > > > > > > > This looks like a chicken and egg problem and the only option to > support > > > > both variants is to ignore card-detect pin and always try to > initialize > > > > device connected to mmc controller (which may be eMMC or SD). > > > > > > Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi > > > file and add there this? /delete-property/ cd-gpios; > > > > I just tried this and the device is not detected again; adding > > "non-removable" seems to be required if changing the dts. > > > > > > I do not know if there is a better option for ignoring card-detect > pin > > > > in u-boot, so: > > > > I should point out that I did investigate runtime detection. > > But how you want to do that runtime detection? As I pointed above I > think it is impossible do runtime detection because it is chicken and > egg problem. > > You can patch fdt only after u-boot initialize mmc, so this can be used > just for patching kernel fdt. > I was just trying to address your concerns about the solution looking like a "hack". I did investigate it, and that work confirmed the issues you expected, so that's confirmation that there isn't a better option. I think we're saying the same thing :) I'll look at runtime patching the kernel fdt, but it might not be as quick a turn around as the defconfig work. If anyone looks at it before me, the fdt memory allocation needs to be increased by 2 to fit "non-removable" in the space left by removing the "cd-gpios". > Patching > > the fdt alone didn't seem to work using the hooks that were available, > > so I started looking into how MMC was being initialised to figure out > > if there was something changing the state of the device before it was > > returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init > > trying to figure out how we always end up with the "MMC: no card > > present" message in the eMMC case. I was going to write some extra > > logic around the mmc_getcd call, but realised there was already an > > ifndef with a config that seemed like this exact use-case. Given that > > config solved the problem it seemed like the cleanest solution. > > > > > > Acked-by: Pali Rohár > > > > > > > > > --- > > > > > configs/clearfog_defconfig | 3 +-- > > > > > configs/clearfog_sata_defconfig | 8 > > > > > 2 files changed, 5 insertions(+), 6 deletions(-) > > > > > > > > > > diff --git a/configs/clearfog_defconfig > b/configs/clearfog_defconfig > > > > > index 8cd35f9f1a..24e7c16ac7 100644 > > > > > --- a/configs/clearfog_defconfig > > > > > +++ b/configs/clearfog_defconfig > > > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > > > > CONFIG_CMD_TFTPPUT=y > > > > > CONFIG_CMD_CACHE=y > > > > > CONFIG_CMD_TIME=y > > > > > -CONFIG_CMD_MVEBU_BUBT=y > > > > > CONFIG_ENV_OVERWRITE=y > > > > > CONFIG_ENV_MIN_ENTRIES=128 > > > > > CONFIG_ARP_TIMEOUT=200 > > > > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y > > > > > CONFIG_SYS_I2C_MVTWSI=y > > > > > CONFIG_I2C_EEPROM=y > > > > > CONFIG_SPL_I2C_EEPROM=y > > > > > -CONFIG_SUPPORT_EMMC_BOOT=y > > > > > +CONFIG_MMC_BROKEN_CD=y > > > > > CONFIG_MMC_SDHCI=y > > > > > CONFIG_MMC_SDHCI_SDMA=y > > > > > CONFIG_MMC_SDHCI_MV=y > > > > > diff --git a/configs/clearfog_sata_defconfig > b/configs/clearfog_sata_defconfig > > > > > index e9b36150ea..84f900bf50 100644 > > > > > --- a/configs/clearfog_sata_defconfig > > > > > +++ b/configs/clearfog_sata_defconfig > > > > > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 > > > > > CONFIG_SPL_LIBCOMMON_SUPPORT=y > > > > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > > > > CONFIG_NR_DRAM_BANKS=2 > > > > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > > > > CONFIG_TARGET_CLEARFOG=y > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > > > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > > > > CONFIG_SPL_TEXT_BASE=0x4030 > > > > > CONFIG_SPL_SERIAL=y > > > > > +CONFIG_SPL_STACK=0x4002c000 > > > > > CONFIG_SPL=y > > > > > CONFIG_DEBUG_UART_BASE=0xf1012000 > >
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
On Sunday 26 February 2023 01:45:16 Martin Rowe wrote: > On Sat, 25 Feb 2023 at 22:14, Pali Rohár wrote: > > On Saturday 25 February 2023 22:49:56 Pali Rohár wrote: > > > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote: > > > > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for > > > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. > > > > > > > > Signed-off-by: Martin Rowe > > > > > > It looks like a hack but I think we do not have a better option for now. > > > > > > If I understand the issue correctly then card-detect pin is unconnected > > > for eMMC variant and used for checking if SD card is present for SD > > > variant. Unconnected pin seems to have some internal pull-up/down which > > > reports not-present state for eMMC variant. eMMC does not have any > > > presence signal, so card-detect pin must be ignored for eMMC. > > > > > > This looks like a chicken and egg problem and the only option to support > > > both variants is to ignore card-detect pin and always try to initialize > > > device connected to mmc controller (which may be eMMC or SD). > > > > Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi > > file and add there this? /delete-property/ cd-gpios; > > I just tried this and the device is not detected again; adding > "non-removable" seems to be required if changing the dts. > > > > I do not know if there is a better option for ignoring card-detect pin > > > in u-boot, so: > > I should point out that I did investigate runtime detection. But how you want to do that runtime detection? As I pointed above I think it is impossible do runtime detection because it is chicken and egg problem. You can patch fdt only after u-boot initialize mmc, so this can be used just for patching kernel fdt. > Patching > the fdt alone didn't seem to work using the hooks that were available, > so I started looking into how MMC was being initialised to figure out > if there was something changing the state of the device before it was > returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init > trying to figure out how we always end up with the "MMC: no card > present" message in the eMMC case. I was going to write some extra > logic around the mmc_getcd call, but realised there was already an > ifndef with a config that seemed like this exact use-case. Given that > config solved the problem it seemed like the cleanest solution. > > > > Acked-by: Pali Rohár > > > > > > > --- > > > > configs/clearfog_defconfig | 3 +-- > > > > configs/clearfog_sata_defconfig | 8 > > > > 2 files changed, 5 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig > > > > index 8cd35f9f1a..24e7c16ac7 100644 > > > > --- a/configs/clearfog_defconfig > > > > +++ b/configs/clearfog_defconfig > > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > > > CONFIG_CMD_TFTPPUT=y > > > > CONFIG_CMD_CACHE=y > > > > CONFIG_CMD_TIME=y > > > > -CONFIG_CMD_MVEBU_BUBT=y > > > > CONFIG_ENV_OVERWRITE=y > > > > CONFIG_ENV_MIN_ENTRIES=128 > > > > CONFIG_ARP_TIMEOUT=200 > > > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y > > > > CONFIG_SYS_I2C_MVTWSI=y > > > > CONFIG_I2C_EEPROM=y > > > > CONFIG_SPL_I2C_EEPROM=y > > > > -CONFIG_SUPPORT_EMMC_BOOT=y > > > > +CONFIG_MMC_BROKEN_CD=y > > > > CONFIG_MMC_SDHCI=y > > > > CONFIG_MMC_SDHCI_SDMA=y > > > > CONFIG_MMC_SDHCI_MV=y > > > > diff --git a/configs/clearfog_sata_defconfig > > > > b/configs/clearfog_sata_defconfig > > > > index e9b36150ea..84f900bf50 100644 > > > > --- a/configs/clearfog_sata_defconfig > > > > +++ b/configs/clearfog_sata_defconfig > > > > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 > > > > CONFIG_SPL_LIBCOMMON_SUPPORT=y > > > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > > > CONFIG_NR_DRAM_BANKS=2 > > > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > > > CONFIG_TARGET_CLEARFOG=y > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > > > CONFIG_SPL_TEXT_BASE=0x4030 > > > > CONFIG_SPL_SERIAL=y > > > > +CONFIG_SPL_STACK=0x4002c000 > > > > CONFIG_SPL=y > > > > CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > CONFIG_DEBUG_UART_CLOCK=25000 > > > > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > > > > CONFIG_DEBUG_UART=y > > > > CONFIG_AHCI=y > > > > CONFIG_DISTRO_DEFAULTS=y > > > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > > > CONFIG_BOOTDELAY=3 > > > > CONFIG_USE_PREBOOT=y > > > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > > > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > > > > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > > > > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > > > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > > > > -CONFIG_SPL_STACK=0x4002c000 > > > > CONFIG_SPL_I2C=y > > > > CONFIG_SYS_MAXARGS=32 > > > > CONFIG_CMD_TLV_EEPROM=y > > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > > >
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > Hi Martin, > > On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: > > > > > > > I'm not sure how to run proper timing tests on the process, but > > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > > > SPI directly was speed, but returning to BootROM is significantly > > > > > faster on this board. > > > > > > > > You should check SPI speed in DTS file and also in the defconfig. > > > > > > I think we have probably seen this slowdown before. There is a TODO in > > > the way the DTS nodes are parsed by DM uclass. So this config must be > > > set in defconfig to get around that bug: > > > CONFIG_SF_DEFAULT_SPEED=5000 > > > > That works and is much faster now. I'll submit it in a V2 for these > > two patches once Pali's mvebu changes are accepted. Only question I > > have is: should the faster speed be applied to all three defconfigs? > > CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the > > MMC and SATA configs at the moment. > > This is only a workaround to get the SPI probe to work correctly. The > real fix should be in spi_flash_probe() > ./common/spl/spl_spi.c > flash = spi_flash_probe(sf_bus, sf_cs, > CONFIG_SF_DEFAULT_SPEED, > CONFIG_SF_DEFAULT_MODE); > If spi_flash_probe() failed to get SPI max_hz from the DTS, the > fallback is CONFIG_SF_DEFAULT_SPEED. > > IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > some other common place. And when we will have fixed the DTS parsing > problem, they can be removed. > > I'd like to hear from Stefan and Pali if this approach sounds good. > > All the best, > Tony Well, the maximal SPI speed depends on the wiring. You can have on the board some SPI device which does not support high frequency. But having some sane defaults in Kconfig for mvebu makes sense.
[PATCH] powerpc, mpc83xx: Remove CONFIG_ELBC_BRx_ORx
Commit fe7d654d04 ("mpc83xx: Migrate CONFIG_SYS_{BR, OR}*_PRELIM to
Kconfig") converted CONFIG_SYS_{BRx/ORx}_PRELIM to Kconfig by
implementing a fine-grained selection of every bit in Kconfig.
But commit c7fad78ec0 ("Convert CONFIG_SYS_BR0_PRELIM et al to
Kconfig") reworked it so that you now just have to provide the raw
value of each register in Kconfig. However, all fine-grained
Kconfig items remained allthough they are not used anymore.
Remove them all.
Fixes: c7fad78ec0 ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig")
Signed-off-by: Christophe Leroy
---
arch/powerpc/cpu/mpc83xx/elbc/Kconfig | 6 -
arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc0 | 733
arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc1 | 733
arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc2 | 733
arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc3 | 733
arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc4 | 733
configs/MPC837XERDB_defconfig | 31 -
configs/gazerbeam_defconfig | 25 -
configs/kmcoge5ne_defconfig | 37 -
configs/kmeter1_defconfig | 28 -
configs/kmopti2_defconfig | 34 -
configs/kmsupx5_defconfig | 28 -
configs/kmtepr2_defconfig | 34 -
configs/tuge1_defconfig | 28 -
configs/tuxx1_defconfig | 36 -
15 files changed, 3952 deletions(-)
delete mode 100644 arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc0
delete mode 100644 arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc1
delete mode 100644 arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc2
delete mode 100644 arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc3
delete mode 100644 arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc4
diff --git a/arch/powerpc/cpu/mpc83xx/elbc/Kconfig
b/arch/powerpc/cpu/mpc83xx/elbc/Kconfig
index 74c4ff3ed4..06841523ef 100644
--- a/arch/powerpc/cpu/mpc83xx/elbc/Kconfig
+++ b/arch/powerpc/cpu/mpc83xx/elbc/Kconfig
@@ -23,10 +23,4 @@ config ELBC_BR_OR_NAND_PRELIM_4
endchoice
-source "arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc0"
-source "arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc1"
-source "arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc2"
-source "arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc3"
-source "arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc4"
-
endmenu
diff --git a/arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc0
b/arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc0
deleted file mode 100644
index 208eed0495..00
--- a/arch/powerpc/cpu/mpc83xx/elbc/Kconfig.elbc0
+++ /dev/null
@@ -1,733 +0,0 @@
-menuconfig ELBC_BR0_OR0
- bool "ELBC BR0/OR0"
-
-if ELBC_BR0_OR0
-
-config BR0_OR0_NAME
- string "Identifier"
-
-config BR0_OR0_BASE
- hex "Port base"
-
-choice
- prompt "Port size"
-
-config BR0_PORTSIZE_8BIT
- bool "8-bit"
-
-config BR0_PORTSIZE_16BIT
- depends on !BR0_MACHINE_FCM
- bool "16-bit"
-
-
-config BR0_PORTSIZE_32BIT
- depends on !BR0_MACHINE_FCM
- depends on ARCH_MPC8360 || ARCH_MPC8379
- bool "32-bit"
-
-endchoice
-
-if BR0_MACHINE_FCM
-
-choice
- prompt "Data Error Checking"
-
-config BR0_ERRORCHECKING_DISABLED
- bool "Disabled"
-
-config BR0_ERRORCHECKING_ECC_CHECKING
- bool "ECC checking / No ECC generation"
-
-config BR0_ERRORCHECKING_BOTH
- bool "ECC checking and generation"
-
-endchoice
-
-endif
-
-config BR0_WRITE_PROTECT
- bool "Write-protect"
-
-config BR0_MACHINE_UPM
- bool
-
-choice
- prompt "Machine select"
-
-config BR0_MACHINE_GPCM
- bool "GPCM"
-
-config BR0_MACHINE_FCM
- depends on !ARCH_MPC832X && !ARCH_MPC8360
- bool "FCM"
-
-config BR0_MACHINE_SDRAM
- depends on ARCH_MPC8360
- bool "SDRAM"
-
-config BR0_MACHINE_UPMA
- select BR0_MACHINE_UPM
- bool "UPM (A)"
-
-config BR0_MACHINE_UPMB
- select BR0_MACHINE_UPM
- bool "UPM (B)"
-
-config BR0_MACHINE_UPMC
- select BR0_MACHINE_UPM
- bool "UPM (C)"
-
-endchoice
-
-if ARCH_MPC8313 || ARCH_MPC8323 || ARCH_MPC8360
-
-choice
- prompt "Atomic operations"
-
-config BR0_ATOMIC_NONE
- bool "No atomic operations"
-
-config BR0_ATOMIC_RAWA
- bool "Read-after-write-atomic"
-
-config BR0_ATOMIC_WARA
- bool "Write-after-read-atomic"
-
-endchoice
-
-endif
-
-if BR0_MACHINE_GPCM || BR0_MACHINE_FCM || BR0_MACHINE_UPM || BR0_MACHINE_SDRAM
-
-choice
- prompt "Address mask"
-
-config OR0_AM_32_KBYTES
- depends on !BR0_MACHINE_SDRAM
- bool "32 kb"
-
-config OR0_AM_64_KBYTES
- bool "64 kb"
-
-config OR0_AM_128_KBYTES
- bool "128 kb"
-
-config OR0_AM_256_KBYTES
- bool "256 kb"
-
-config OR0_AM_512_KBYTES
- bool "512 kb"
-
-config OR0_AM_1_MBYTES
- bool "1 mb"
-
-config OR0_AM_2_MBYTES
- bool "2 mb"
-
-config OR0_AM_4_MBYTES
- bool "4 mb"
-
-config OR0_AM_8_MBYTES
- bool "8 mb"
-
-config OR0_AM_16_MBYTES
- bool "16 mb"
-
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Sunday 26 February 2023 01:56:23 Martin Rowe wrote: > On Sat, 25 Feb 2023 at 21:16, Pali Rohár wrote: > > I think that the remaining part is to patch linux DTB file at runtime > > for emmc support. So if u-boot mmc device is of eMMC type then fixup > > linux dtb file and others do nothing. > > One question I didn't think of when suggesting this: does runtime > patching the kernel's dtb break signed/verified booting I do not think so. Signature verification should be done before patching. > The reason I > ask is because we now only need to patch the kernel dtb, not the > u-boot one. If we needed to do both, then it would make sense to > handle them in the same way through u-boot. The barrier to creating a > patched kernel dtb file on its own is very low, so I'm not sure adding > some "magic" to u-boot to make it work is the best solution, > especially if it might break verified boot.
