Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > Hello! > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > Hi Pali, > > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385 > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which > > is not currently supported in u-boot (also cc this to Chris for > > commenting about Marvell DDR4 training driver). > > Yes, ddr4 training code is not in u-boot yet. > > A38x u-boot ddr driver is in this directory: > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > And it is copied from the original marvell driver by stripping non-a38x > code and removal of the ddr4 code from the master branch: > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > So you can try to copy code again without stripping ddr4 parts > (run git log drivers/ddr/marvell/a38x in u-boot) https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > And adjust u-boot board code for ddr4. > > I guess it could work but it would be needed to play with it. > > > So I'm building with binary.0 in the ./board/thecus/n2350/. This > > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source > > for this board (provided by Thecus). My > > ./board/thecus/n2350/kwbimage.cfg.in file looks like this > > > > # Armada 38x uses version 1 image format > > VERSION 1 > > # Boot Media configurations > > BOOT_FROM spi > > # Binary Header (bin_hdr) with DDR4 training code > > BINARY board/thecus/n2350/binary.0 005b 0068 > > > > When I kwboot the u-boot.kwb image (using kwboot binary built with > > 2023.01-rc4), the header was transferred successfully, but then the > > BootROM jumped to SPI u-boot, instead of loading the u-boot payload > > from UART. Please see the log below. > > > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb > > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty > > Patching image boot signature to UART > > Aligning image header to Xmodem block size > > Sending boot message. Please reboot the target.../ > > Sending boot image header (97792 bytes)... > > 0 % > > [..] > > 9 % > > [..] > > > > 82 % > > [..] > > 91 % [ > > ] > > Done > > > > BootROM - 1.73 > > Booting from SPI flash > > This indicates reset of the board. BootROM started execution of the > image from the primary location. > > > > > U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version: 2015_T1.0p18-tld-4 > > > > > > It seems kwboot patched the image, but the BOOT_FROM indicator was > > still recognized as from SPI. So the BootROM loaded the stock u-boot > > image from SPI and executed it. Since I am booting with bin_hdr, I'm > > not sure if there is something inside this blob that has forced this > > indicator to SPI. > > No, blob cannot force BootROM to switch boot location. This really > indicates crash of the blob or crash of the payload which results in the > board reset. > > > I'm attaching the u-boot.kwb image to this email, in case you are > > interested in taking a look at the structure. > > > > Thanks, > > Tony > >
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hello! On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > Hi Pali, > > I'm building a new u-boot for the Thecus N2350 board (Armada 385 > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which > is not currently supported in u-boot (also cc this to Chris for > commenting about Marvell DDR4 training driver). Yes, ddr4 training code is not in u-boot yet. A38x u-boot ddr driver is in this directory: https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x And it is copied from the original marvell driver by stripping non-a38x code and removal of the ddr4 code from the master branch: https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell So you can try to copy code again without stripping ddr4 parts (run git log drivers/ddr/marvell/a38x in u-boot) And adjust u-boot board code for ddr4. I guess it could work but it would be needed to play with it. > So I'm building with binary.0 in the ./board/thecus/n2350/. This > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source > for this board (provided by Thecus). My > ./board/thecus/n2350/kwbimage.cfg.in file looks like this > > # Armada 38x uses version 1 image format > VERSION 1 > # Boot Media configurations > BOOT_FROM spi > # Binary Header (bin_hdr) with DDR4 training code > BINARY board/thecus/n2350/binary.0 005b 0068 > > When I kwboot the u-boot.kwb image (using kwboot binary built with > 2023.01-rc4), the header was transferred successfully, but then the > BootROM jumped to SPI u-boot, instead of loading the u-boot payload > from UART. Please see the log below. > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty > Patching image boot signature to UART > Aligning image header to Xmodem block size > Sending boot message. Please reboot the target.../ > Sending boot image header (97792 bytes)... > 0 % [..] > 9 % [..] > > 82 % [..] > 91 % [ ] > Done > > BootROM - 1.73 > Booting from SPI flash This indicates reset of the board. BootROM started execution of the image from the primary location. > > U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version: 2015_T1.0p18-tld-4 > > > It seems kwboot patched the image, but the BOOT_FROM indicator was > still recognized as from SPI. So the BootROM loaded the stock u-boot > image from SPI and executed it. Since I am booting with bin_hdr, I'm > not sure if there is something inside this blob that has forced this > indicator to SPI. No, blob cannot force BootROM to switch boot location. This really indicates crash of the blob or crash of the payload which results in the board reset. > I'm attaching the u-boot.kwb image to this email, in case you are > interested in taking a look at the structure. > > Thanks, > Tony
Re: [PATCH 1/3] tpm: Fix spelling for tpmu_ha union
On Tue, 3 Jan 2023 at 22:42, Eddie James wrote:
>
> tmpu -> tpmu
>
> Signed-off-by: Eddie James
> ---
> include/tpm-v2.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index 737e57551d..85feda3e06 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -167,7 +167,7 @@ struct tcg_pcr_event {
> /**
> * Definition of TPMU_HA Union
> */
> -union tmpu_ha {
> +union tpmu_ha {
> u8 sha1[TPM2_SHA1_DIGEST_SIZE];
> u8 sha256[TPM2_SHA256_DIGEST_SIZE];
> u8 sm3_256[TPM2_SM3_256_DIGEST_SIZE];
> @@ -183,7 +183,7 @@ union tmpu_ha {
> */
> struct tpmt_ha {
> u16 hash_alg;
> - union tmpu_ha digest;
> + union tpmu_ha digest;
> } __packed;
>
> /**
> --
> 2.31.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH 0/3] tpm: Support boot measurements
Hi Eddie, Thanks for the patch Looking at the patch there's a lot of code duplication with lib/efi_loader/efi_tcg2.c. Any reason why we aren't reusing that ? Regards /Ilias On Tue, 3 Jan 2023 at 22:42, Eddie James wrote: > > This series adds support for measuring the boot images more generically > than the existing EFI support. The series includes optional measurement > from the bootm command. > Eventually the EFI code could be refactored to use the generic functions. > > Eddie James (3): > tpm: Fix spelling for tpmu_ha union > tpm: Support boot measurements > bootm: Support boot measurement > > boot/bootm.c | 53 > cmd/bootm.c| 2 + > common/Kconfig | 6 + > include/efi_tcg2.h | 44 --- > include/image.h| 1 + > include/tpm-v2.h | 139 - > lib/tpm-v2.c | 700 + > 7 files changed, 899 insertions(+), 46 deletions(-) > > -- > 2.31.1 >
Re: [PATCH] i2c: mxc_i2c: Use hex notation for the base address
On 04/01/23 00:33, Fabio Estevam wrote:
Printing the I2C controller base address in decimal notation
is not helpful.
Change it to hex notation, which is the standard format found
in the Reference Manual and devicetree.
Agree
Signed-off-by: Fabio Estevam
---
Acked-by: Dhruva Gole
drivers/i2c/mxc_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index f80ff5383b..9dd349d056 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -938,7 +938,7 @@ static int mxc_i2c_probe(struct udevice *bus)
* we can set pinmux here in probe function.
*/
- debug("i2c : controller bus %d at %lu , speed %d: ",
+ debug("i2c : controller bus %d at 0x%lx , speed %d: ",
dev_seq(bus), i2c_bus->base,
i2c_bus->speed);
--
Thanks and Regards,
Dhruva Gole
Re: [PATCH] ARM: dts: at91: sam9x60: add sdhci1 node and pinctrl
On 12/23/22 08:47, Mihai Sain wrote: > Add node for sdhci1 controller and its pinctrl. > > Signed-off-by: Mihai Sain > --- Applied to u-boot-at91/next, thanks !
Re: [PATCH] configs: sam9x60: add mmc config for sdmmc1
On 12/23/22 08:43, Mihai Sain wrote: > Add new config for storing environment from SDMMC1. > > Signed-off-by: Mihai Sain > --- Applied to u-boot-at91/next, thanks !
Re: [[PATCH] board: at91: sam9x60: set blue led on at boot time
On 12/23/22 08:39, Mihai Sain wrote: > Set blue led on at boot time in order to highlight that u-boot is loaded. > This is done for all sam9x60 based boards which contain an RGB led. > > Signed-off-by: Mihai Sain > --- Applied to u-boot-at91/next, thanks !
Re: [PATCH 1/6] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes
On 1/3/23 01:12, Marek Vasut wrote:
> On 12/23/22 13:33, Sergiu Moga wrote:
>> Add the OHCI and EHCI DT nodes for the sam9x60 boards.
>>
>> Signed-off-by: Sergiu Moga
>> ---
>> arch/arm/dts/at91-sam9x60_curiosity.dts | 21 +
>> arch/arm/dts/sam9x60.dtsi | 18 ++
>
> Board and SoC DT changes should be in separate patches.
>
>> arch/arm/dts/sam9x60ek.dts | 21 +
>> 3 files changed, 60 insertions(+)
>
>
> [...]
>
>> diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
>> index 17224ef771..e36a540f78 100644
>> --- a/arch/arm/dts/sam9x60.dtsi
>> +++ b/arch/arm/dts/sam9x60.dtsi
>> @@ -69,6 +69,24 @@
>> #size-cells = <1>;
>> ranges;
>>
>> + usb1: ohci@60 {
>
> This should be usb@ instead of ohci@ , if you run "make dtbs_check" on
> this DT in Linux (please do), you would likely get a warning , see Linux
> Documentation/devicetree/bindings/usb/usb.yaml .
If in Linux we have ohci@ , then we need to have the same in U-boot.
We can accept the change to usb@ , if there is a pending patch in Linux.
U-boot is not the place to review the devicetree. The devicetree must be
in sync with Linux.
Eugen
>
>> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
>> + reg = <0x0060 0x10>;
>> + clocks = < PMC_TYPE_PERIPHERAL 22>, <
>> PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
>> + clock-names = "ohci_clk", "hclk", "uhpck";
>> + status = "disabled";
>> + };
>
> [...]
>
Re: [u-boot][PATCH v2 0/8] rawnand: omap_gpmc: driver model support
Hi Roger,
applied to nand-next
Thanks and regards,
Dario
On Tue, Dec 20, 2022 at 11:22 AM Roger Quadros wrote:
>
> Hi Michael & Dario,
>
> This series adds driver model support for rawnand: omap_gpmc
> and omap_elm drivers.
>
> This will enable the driver to be used on K2/K3 platforms as well.
>
> This series along with remaining patches required to get NAND working on
> AM6x EVM is available here
> https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-2.0
>
> cheers,
> -roger
>
> Changelog:
> v2:
> - Fixed build warning and failures for am335x_guardian, chiliboard, and cm_t32
> - use __maybe_unused struct nand_chip to fix build warning
> - make elm_probe() a NOP if ELM_BASE is defined. This should not interfere
> with existing platforms that don't use Driver Model for ELM driver.
>
> Roger Quadros (8):
> mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
> mtd: rawnand: nand_base: Allow base driver to be used in SPL without
> nand_bbt
> dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
> mtd: rawnand: omap_gpmc: support u-boot driver model
> mtd: rawnand: omap_gpmc: Add SPL NAND support
> mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
> dt-bindings: mtd: Add ti,elm DT binding documentation
> mtd: rawnand: omap_elm: u-boot driver model support
>
> doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++
> .../mtd/ti,gpmc-nand.yaml | 129 +
> drivers/mtd/nand/raw/Kconfig | 9 +-
> drivers/mtd/nand/raw/Makefile | 2 +-
> drivers/mtd/nand/raw/nand_base.c | 18 +-
> drivers/mtd/nand/raw/omap_elm.c | 35 +-
> .../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 +
> drivers/mtd/nand/raw/omap_gpmc.c | 441 +-
> 8 files changed, 604 insertions(+), 108 deletions(-)
> create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
> create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
> rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
>
> --
> 2.34.1
>
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binac...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v2 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes
On 1/3/23 18:00, Marek Vasut wrote:
> On 1/3/23 16:56, sergiu.m...@microchip.com wrote:
>> On 03.01.2023 17:47, Marek Vasut wrote:
>>> On 1/3/23 16:35, Sergiu Moga wrote:
Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.
Signed-off-by: Sergiu Moga
---
v1 -> v2:
- use usb@
arch/arm/dts/sam9x60.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 17224ef771..4fcfb5c597 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,24 @@
#size-cells = <1>;
ranges;
+ usb1: usb@60 {
+ compatible = "atmel,at91rm9200-ohci", "usb-ohci";
+ reg = <0x0060 0x10>;
+ clocks = < PMC_TYPE_PERIPHERAL 22>, <
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
>>>
>>> ./scripts/checkpatch.pl on this patch indicates
>>>
>>> WARNING: line length of 121 exceeds 100 columns
>>> #93: FILE: arch/arm/dts/sam9x60.dtsi:75:
>>> + clocks = < PMC_TYPE_PERIPHERAL 22>, <
>>> PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
>>>
>>> Please run checkpatch on all your patches.
>>>
>>> Also, wait a few days before sending V2 , no need to send V2 immediately
>>> while review of V1 is still ongoing.
>>
>> It was my understanding that exceeding the character per line limit on
>> DT's is acceptable. All of our DT's are like this.
>
> Not to my knowledge or per what is in other DTs.
> Is that some exception here ?
DTs have not had restrictions on 80 chars per line. Have a look in Linux.
Also, as we have a requirement to keep the DT from Linux, we either have
to patch up Linux if there is a problem in the DT, or keep it in sync
with Linux.
We may have exceptions if there is a too big amount of work to be done
now to change things, to have differences in term of DT between Uboot
and Linux. But the general guideline is to keep the DT in sync with
Linux as it's ABI.
Eugen
Re: [PATCH V3 08/12] board: ti: j721s2: Add board_init and support for selecting DT based on EEPROM
Hi Sinthu
On 27/12/22 17:45, Sinthu Raja wrote:
From: Sinthu Raja
Add the board_init_f API for SPL and run the platform-required SoC
initialization.
Add the functionality for board name-based DTB selection from FIT
within SPL. This will make it easier to utilise one defconfig for
both the EVM and the SK.
Signed-off-by: Sinthu Raja
---
Changes in V3:
=
Address review comments:
- Rework on DTB selection API clarity about mini-U-Boot vs EVM and family
support as suggested.
v2:
https://patchwork.ozlabs.org/project/uboot/cover/20221221135219.24702-9-sinthu.r...@ti.com/
board/ti/j721s2/evm.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index a7c4082a7a..a670332fc0 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "../common/board_detect.h"
@@ -202,3 +203,66 @@ int board_late_init(void)
void spl_board_init(void)
{
}
+
+/* Support for the various EVM / SK families */
+#if defined(CONFIG_SPL_OF_LIST) && defined(CONFIG_TI_I2C_BOARD_DETECT)
+void do_dt_magic(void)
+{
+ int ret, rescan, mmc_dev = -1;
+ static struct mmc *mmc;
+
+ do_board_detect();
+
+ /*
+* Board detection has been done.
+* Let us see if another dtb wouldn't be a better match
+* for our board
+*/
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ ret = fdtdec_resetup();
+ if (!ret && rescan) {
+ dm_uninit();
+ dm_init_and_scan(true);
+ }
+ }
+
+ /*
+* Because of multi DTB configuration, the MMC device has
+* to be re-initialized after reconfiguring FDT inorder to
+* boot from MMC. Do this when boot mode is MMC and ROM has
+* not loaded SYSFW.
+*/
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC1:
+ mmc_dev = 0;
+ break;
+ case BOOT_DEVICE_MMC2:
+ case BOOT_DEVICE_MMC2_2:
+ mmc_dev = 1;
+ break;
+ }
+
+ if (mmc_dev > 0 && !check_rom_loaded_sysfw()) {
+ ret = mmc_init_device(mmc_dev);
+ if (!ret) {
+ mmc = find_mmc_device(mmc_dev);
+ if (mmc) {
+ ret = mmc_init(mmc);
+ if (ret)
+ printf("mmc init failed with error:
%d\n", ret);
+ }
+ }
+ }
+}
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+void board_init_f(ulong dummy)
+{
+ k3_spl_init();
+#ifdef CONFIG_SPL_OF_LIST
This may just be a case of formality but we'd need "if
defined(CONFIG_TI_I2C_BOARD_DETECT)" here as well right?
+ do_dt_magic();
+#endif
+ k3_mem_init();
+}
+#endif
--
Thanking You
Neha Malcom Francis
Pull request for u-boot-nand-20230103
Hi Tom,
The following changes since commit 582e3c9fb2337c2f49faa73ac86dde25f4d56901:
Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
(2023-01-02 09:36:13 -0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
tags/u-boot-nand-20230103
for you to fetch changes up to 49bf9d131284b75787dd2e6941d0e9a46d35eeb3:
mtd: rawnand: omap_elm: u-boot driver model support (2023-01-03
11:21:04 +0100)
Gitlab CI showed no issues:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14563
- rawnand: omap_gpmc: driver model support
Roger Quadros (8):
mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
mtd: rawnand: nand_base: Allow base driver to be used in SPL
without nand_bbt
dt-bindings: mtd: Add ti, gpmc-nand DT binding documentation
mtd: rawnand: omap_gpmc: support u-boot driver model
mtd: rawnand: omap_gpmc: Add SPL NAND support
mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
dt-bindings: mtd: Add ti, elm DT binding documentation
mtd: rawnand: omap_elm: u-boot driver model support
doc/device-tree-bindings/mtd/ti,elm.yaml | 72
+++
doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml | 129
+
drivers/mtd/nand/raw/Kconfig | 9 ++-
drivers/mtd/nand/raw/Makefile | 2 +-
drivers/mtd/nand/raw/nand_base.c | 18 -
drivers/mtd/nand/raw/omap_elm.c| 35 -
{include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 ++
drivers/mtd/nand/raw/omap_gpmc.c | 441
+---
8 files changed, 604 insertions(+), 108 deletions(-)
create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binac...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH V3 00/12] AM68: Add support for AM68 Starter Kit
On Tue, Dec 27, 2022 at 5:46 PM Sinthu Raja wrote: > > From: Sinthu Raja > > Hi All, > This series of patch add initial support for AM68 starter kit. > Design files can be referrred from https://www.ti.com/lit/zip/SPRR463 > > Refer below link to J721S2/AM68 Technical Reference Manual for further > details: > http://www.ti.com/lit/pdf/spruj28 > > Link to kerenl patches: > https://lore.kernel.org/linux-arm-kernel/20221115154832.19759-4-sinthu.r...@ti.com/T/#mff5847ea8cdef49337d224b7147f877bcc833aee > > Changes in V3: > = > Address review comments: > - Rework on DTB selection API clarity about mini-U-Boot vs EVM and family > support as suggested. > * board: ti: j721s2: Add board_init and support for selecting DT based > on EEPROM Tom, Any further comments on this patch series? Regards, Sinthu Raja. > > Changes in V2: > = > Address review comments: > - Remove support for detecting multiple device trees using different DTB > - Remove board specific API from K3 generic file > (arch/arm/mach-k3/j721s2_init.c) and moved to board specific file > (board/ti/j721s2/evm.c). > * arch: mach-k3: Update board specific API name to K3 generic API name > * board: ti: j721s2: Add board_init and support for selecting DT based > on EEPROM > - Move board_is_xxx within CONFIG_TI_I2C_BOARD_DETECT block to maintain the > "mini" U-Boot concept for this SoC. > > V1: > https://patchwork.ozlabs.org/project/uboot/cover/20221027104846.11820-1-sinthu.r...@ti.com/ > V2: > https://patchwork.ozlabs.org/project/uboot/cover/20221221135219.24702-1-sinthu.r...@ti.com/ > > Sinthu Raja (12): > configs: j721s2_evm_r5: Enable support for building multiple dtbs into > FIT > configs: j721s2_evm_a72: Enable support for building multiple dtbs > into FIT > configs: j721s2_evm: Enable configs to store env in MMC FAT partition > board: ti: j721s2: Add support to update board_name for am68-sk > board: ti: j721s2: Enable support for reading EEPROM at next alternate > address > board: ti: j721s2: Add support for detecting multiple device trees > arch: mach-k3: Update board specific API name to K3 generic API name > board: ti: j721s2: Add board_init and support for selecting DT based > on EEPROM > arm: dts: Add initial support for AM68 Starter Kit System on Module > arm: dts: Add support for A72 specific AM68 Starter Kit Base Board > arm: dts: k3-am68-sk: Add r5 specific dt support > include: configs: Update env for selecting right dtb > > arch/arm/dts/Makefile | 4 +- > .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 150 > arch/arm/dts/k3-am68-sk-base-board.dts| 353 ++ > arch/arm/dts/k3-am68-sk-r5-base-board.dts | 194 ++ > arch/arm/dts/k3-am68-sk-som.dtsi | 127 +++ > arch/arm/mach-k3/include/mach/sys_proto.h | 3 + > arch/arm/mach-k3/j721s2_init.c| 13 +- > board/ti/j721s2/evm.c | 118 +- > configs/j721s2_evm_a72_defconfig | 4 +- > configs/j721s2_evm_r5_defconfig | 4 + > include/configs/j721s2_evm.h | 4 + > 11 files changed, 956 insertions(+), 18 deletions(-) > create mode 100644 arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-am68-sk-base-board.dts > create mode 100644 arch/arm/dts/k3-am68-sk-r5-base-board.dts > create mode 100644 arch/arm/dts/k3-am68-sk-som.dtsi > > -- > 2.36.1 > -- With Regards Sinthu Raja
Re: [RFC PATCH 16/17] arm: sunxi: add Allwinner T113s devicetree stub
在 2023-01-03星期二的 17:38 +，Andre Przywara写道：
> On Tue, 06 Dec 2022 13:55:02 +0800
> Icenowy Zheng wrote:
>
> Hi Icenowy,
>
> > 在 2022-12-06星期二的 00:45 +，Andre Przywara写道：
> > > This adds the basic SoC .dtsi devicetree stub for the Allwinner
> > > T113s
> > > SoC. This shares a die with the Allwinner D1 SoC (with RISC-V
> > > cores),
> > > but uses two Cortex-A7 cores instead of the T-HEAD C906 RISC-V
> > > core.
> > >
> > > Include the existing D1 devicetree stub, but add the ARM specific
> > > nodes,
> > > like for the CPU, the arch timer and the GIC.
> > >
> > > Signed-off-by: Andre Przywara
> > > ---
> > > arch/arm/dts/sun8i-t113s.dtsi | 59
> > > +++
> > > 1 file changed, 59 insertions(+)
> > > create mode 100644 arch/arm/dts/sun8i-t113s.dtsi
> > >
> > > diff --git a/arch/arm/dts/sun8i-t113s.dtsi b/arch/arm/dts/sun8i-
> > > t113s.dtsi
> > > new file mode 100644
> > > index 000..0919ce559f6
> > > --- /dev/null
> > > +++ b/arch/arm/dts/sun8i-t113s.dtsi
> > > @@ -0,0 +1,59 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > +// Copyright (C) 2022 Arm Ltd.
> > > +
> > > +#define SOC_PERIPHERAL_IRQ(nr) GIC_SPI nr
> > > +
> > > +#include
> > > +#include <../../riscv/dts/sunxi-d1s-t113.dtsi>
> >
> > Should we make a R528 DTSI which includes d1-t113.dtsi, and then
> > T113
> > DTSI which includes d1s-t113.dtsi ?
>
> If I understand Samuel correctly, the T113-s includes the DSP, in
> contrast
> to the D1s, which has fused that off.
> That would make including both sunxi-d1*-t113.dtsi files the right
> choice,
> wouldn't it? According to Samuel's list, sunxi-d1-t113.dtsi contains
> DSP
> related peripherals.
Okay, although I heard that the DSP is not fused off (because DSP RAM
is used by BROM).
>
> I don't know if there is anything DT relevant that the R528 has over
> the
> T113-s, but I don't claim to provide an R528 DT anyway, at least not
> yet,
> so we can leave this for the future, should a board or manual emerge.
>
> So this file here should to be the equivalent of sun20i-d1s.dtsi,
> providing the ARM specific bits.
>
> Does that make sense? If you agree, I would post this to Linux ASAP.
It sounds good.
>
> Cheers,
> Andre
>
>
> > > +#include <../../riscv/dts/sunxi-d1-t113.dtsi>
> > > +
> > > +/ {
> > > + interrupt-parent = <>;
> > > +
> > > + cpus {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + cpu0: cpu@0 {
> > > + compatible = "arm,cortex-a7";
> > > + device_type = "cpu";
> > > + reg = <0>;
> > > + clocks = < CLK_CPUX>;
> > > + clock-names = "cpu";
> > > + };
> > > +
> > > + cpu1: cpu@1 {
> > > + compatible = "arm,cortex-a7";
> > > + device_type = "cpu";
> > > + reg = <1>;
> > > + clocks = < CLK_CPUX>;
> > > + clock-names = "cpu";
> > > + };
> > > + };
> > > +
> > > + gic: interrupt-controller@1c81000 {
> > > + compatible = "arm,gic-400";
> > > + reg = <0x03021000 0x1000>,
> > > + <0x03022000 0x2000>,
> > > + <0x03024000 0x2000>,
> > > + <0x03026000 0x2000>;
> > > + interrupts = > > |
> > > IRQ_TYPE_LEVEL_HIGH)>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > + };
> > > +
> > > + timer {
> > > + compatible = "arm,armv7-timer";
> > > + interrupts = > > |
> > > IRQ_TYPE_LEVEL_LOW)>,
> > > + > > |
> > > IRQ_TYPE_LEVEL_LOW)>,
> > > + > > |
> > > IRQ_TYPE_LEVEL_LOW)>,
> > > + > > |
> > > IRQ_TYPE_LEVEL_LOW)>;
> > > + };
> > > +
> > > + pmu {
> > > + compatible = "arm,cortex-a7-pmu";
> > > + interrupts = ,
> > > + ;
> > > + interrupt-affinity = <>, <>;
> > > + };
> > > +};
> >
>
[PATCH 1/1] efi_loader: populate console handles in system table
The fields ConsoleInHandle, ConsoleOutHandle, ConsoleErrHandle must point to the handles with the respective console protocols. Failure to do so leads to an error in the EFI Shell: No SimpleTextInputEx was found. CTRL-based features are not usable. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_boottime.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 253f9f75ef..e65ca6a4cb 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -3956,8 +3956,11 @@ efi_status_t efi_initialize_system_table(void) * These entries will be set to NULL in ExitBootServices(). To avoid * relocation in SetVirtualAddressMap(), set them dynamically. */ + systab.con_in_handle = efi_root; systab.con_in = _con_in; + systab.con_out_handle = efi_root; systab.con_out = _con_out; + systab.stderr_handle = efi_root; systab.std_err = _con_out; systab.boottime = _boot_services; -- 2.37.2
[PATCH 1/2] vexpress: adjust loadaddr
On the vexpress_ca9x4 $loadaddr points to a memory area used by the EFI sub-system. Use the same value as $kernel_addr_r which is safe. Signed-off-by: Heinrich Schuchardt --- include/configs/vexpress_common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/vexpress_common.h b/include/configs/vexpress_common.h index 5d773060d8..aac96d29ba 100644 --- a/include/configs/vexpress_common.h +++ b/include/configs/vexpress_common.h @@ -147,6 +147,7 @@ #include #define CONFIG_EXTRA_ENV_SETTINGS \ +"loadaddr=0x6010\0" \ "kernel_addr_r=0x6010\0" \ "fdt_addr_r=0x6000\0" \ "bootargs=console=tty0 console=ttyAMA0,38400n8\0" \ -- 2.37.2
[PATCH 2/2] lmb: consider EFI memory map
Add reservations for all EFI memory areas that are not
EFI_CONVENTIONAL_MEMORY.
Signed-off-by: Heinrich Schuchardt
---
lib/lmb.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/lib/lmb.c b/lib/lmb.c
index c599608fa3..aee2617593 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -7,7 +7,9 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
@@ -153,6 +155,46 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp,
ulong end, ulong align)
}
}
+/**
+ * efi_lmb_reserve() - add reservations for EFI memory
+ *
+ * Add reservations for all EFI memory areas that are not
+ * EFI_CONVENTIONAL_MEMORY.
+ *
+ * @lmb: lmb environment
+ * Return: 0 on success, 1 on failure
+ */
+static __maybe_unused int efi_lmb_reserve(struct lmb *lmb)
+{
+ struct efi_mem_desc *memmap = NULL, *map;
+ efi_uintn_t i, map_size = 0;
+ efi_status_t ret;
+
+ ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
+ if (ret == EFI_BUFFER_TOO_SMALL) {
+ map_size += sizeof(struct efi_mem_desc); /* for my own */
+ ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
+ (void *));
+ if (ret != EFI_SUCCESS)
+ return 1;
+ ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
+ }
+ if (ret != EFI_SUCCESS) {
+ efi_free_pool(memmap);
+ return 1;
+ }
+
+ for (i = 0, map = memmap; i < map_size / sizeof(*map); ++map, ++i) {
+ if (map->type != EFI_CONVENTIONAL_MEMORY)
+ lmb_reserve(lmb,
+ map_to_sysmem((void *)(uintptr_t)
+ map->physical_start),
+ map->num_pages * EFI_PAGE_SIZE);
+ }
+ efi_free_pool(memmap);
+ return 0;
+}
+
static void lmb_reserve_common(struct lmb *lmb, void *fdt_blob)
{
arch_lmb_reserve(lmb);
@@ -160,6 +202,9 @@ static void lmb_reserve_common(struct lmb *lmb, void
*fdt_blob)
if (CONFIG_IS_ENABLED(OF_LIBFDT) && fdt_blob)
boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
+
+ if (CONFIG_IS_ENABLED(EFI_LOADER))
+ efi_lmb_reserve(lmb);
}
/* Initialize the struct, add memory and call arch/board reserve functions */
--
2.37.2
[PATCH 0/2] lmb: consider EFI memory map
As reported in Debian bug #1027176 relocation of the initrd may lead to overwriting memory used by the EFI sub-system. Currently the available memory for images is determined via the lmb library functions. The lmb library has several shortcomings: * It does not protect against overwriting one image with another. * The same routines to find reserved memory are called again and again. In the long run we should move to allocating memory for images. As an intermediate solutions let's add lmb-reservations for all EFI memory areas that are not EFI_CONVENTIONAL_MEMORY. The variable $loadaddr of at least the vexpress_ca9x4 board collids with memory used by the EFI sub-system. Adjust $loadaddr for the vexpress boards to a sane value. Heinrich Schuchardt (2): vexpress: adjust loadaddr lmb: consider EFI memory map include/configs/vexpress_common.h | 1 + lib/lmb.c | 45 +++ 2 files changed, 46 insertions(+) -- 2.37.2
Re: [PATCH v2 2/3] eficonfig: refactor change boot order implementation
On Wed, 28 Dec 2022 at 00:05, Ilias Apalodimas
wrote:
>
> On Sat, Dec 24, 2022 at 07:57:43AM +0900, Masahisa Kojima wrote:
> > This commit removes the change boot order specific
> > menu implementation. The change boot order implementation
> > calls eficonfig_process_common() same as other menus.
> >
> > The change boot order menu requires own item_data_print
> > and item_choice implementation, but display_statusline
> > function can be a same function as other menus.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changes in v2:
> > - add comment when the user key press is not valid
> > - add const qualifier to eficonfig_change_boot_order_desc
> >
> > cmd/eficonfig.c | 245 +---
> > 1 file changed, 150 insertions(+), 95 deletions(-)
> >
> > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > index 2fc486dac2..13929cb003 100644
> > --- a/cmd/eficonfig.c
> > +++ b/cmd/eficonfig.c
> > @@ -24,6 +24,11 @@ static struct efi_simple_text_input_protocol *cin;
> > const char *eficonfig_menu_desc =
> > " Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit";
> >
> > +static const char *eficonfig_change_boot_order_desc =
> > + " Press UP/DOWN to move, +/- to change orde\n"
> > + " Press SPACE to activate or deactivate the entry\n"
> > + " Select [Save] to complete, ESC/CTRL+C to quit";
> > +
> > #define EFICONFIG_DESCRIPTION_MAX 32
> > #define EFICONFIG_OPTIONAL_DATA_MAX 64
> >
> > @@ -105,6 +110,17 @@ struct eficonfig_boot_order_data {
> > bool active;
> > };
> >
> > +/**
> > + * struct eficonfig_save_boot_order_data - structure to be used to change
> > boot order
> > + *
> > + * @efi_menu:pointer to efimenu structure
> > + * @selected:flag to indicate user selects "Save" entry
> > + */
> > +struct eficonfig_save_boot_order_data {
> > + struct efimenu *efi_menu;
> > + bool selected;
> > +};
> > +
> > /**
> > * eficonfig_print_msg() - print message
> > *
> > @@ -173,10 +189,9 @@ void eficonfig_display_statusline(struct menu *m)
> > "\n%s\n"
> > ANSI_CURSOR_POSITION ANSI_CLEAR_LINE ANSI_CURSOR_POSITION
> > "%s"
> > -ANSI_CLEAR_LINE_TO_END ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
> > +ANSI_CLEAR_LINE_TO_END,
> > 1, 1, entry->efi_menu->menu_header, entry->efi_menu->count +
> > 5, 1,
> > -entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc,
> > -entry->efi_menu->count + 7, 1);
> > +entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc);
> > }
> >
> > /**
> > @@ -1841,63 +1856,44 @@ out:
> > }
> >
> > /**
> > - * eficonfig_display_change_boot_order() - display the BootOrder list
> > + * eficonfig_print_change_boot_order_entry() - print the boot option entry
> > *
> > - * @efi_menu:pointer to the efimenu structure
> > - * Return: status code
> > + * @data:pointer to the data associated with each menu entry
> > */
> > -static void eficonfig_display_change_boot_order(struct efimenu *efi_menu)
> > +static void eficonfig_print_change_boot_order_entry(void *data)
> > {
> > - bool reverse;
> > - struct list_head *pos, *n;
> > - struct eficonfig_entry *entry;
> > -
> > - printf(ANSI_CLEAR_CONSOLE ANSI_CURSOR_POSITION
> > -"\n ** Change Boot Order **\n"
> > -ANSI_CURSOR_POSITION
> > -" Press UP/DOWN to move, +/- to change order"
> > -ANSI_CURSOR_POSITION
> > -" Press SPACE to activate or deactivate the entry"
> > -ANSI_CURSOR_POSITION
> > -" Select [Save] to complete, ESC/CTRL+C to quit"
> > -ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
> > -1, 1, efi_menu->count + 5, 1, efi_menu->count + 6, 1,
> > -efi_menu->count + 7, 1, efi_menu->count + 8, 1);
> > -
> > - /* draw boot option list */
> > - list_for_each_safe(pos, n, _menu->list) {
> > - entry = list_entry(pos, struct eficonfig_entry, list);
> > - reverse = (entry->num == efi_menu->active);
> > + struct eficonfig_entry *entry = data;
> > + int reverse = (entry->efi_menu->active == entry->num);
>
> Why did we change this from bool?
This should be bool. I will fix it.
Thanks,
Masahisa Kojima
>
> [...]
>
> > - printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
> > }
> >
> > /**
> > - * eficonfig_choice_change_boot_order() - handle the BootOrder update
> > + * eficonfig_choice_change_boot_order() - user key input handler
> > *
> > - * @efi_menu:pointer to the efimenu structure
> > - * Return: status code
> > + * @data:pointer to the menu entry
> > + * Return: key string to identify the selected entry
> > */
> > -static efi_status_t eficonfig_choice_change_boot_order(struct efimenu
> > *efi_menu)
> > }
> >
> > +/**
> > + * eficonfig_process_save_boot_order() - callback function for "Save" entry
> > + *
> >
Re: [PATCH v2 3/3] eficonfig: add vertical scroll support
On Tue, 27 Dec 2022 at 23:55, Ilias Apalodimas
wrote:
>
>
> This looks correct to me.
> Heinrich can you check if that solves your scrolling issues?
>
> On Sat, Dec 24, 2022 at 07:57:44AM +0900, Masahisa Kojima wrote:
> > The current eficonfig menu does not support vertical scroll,
> > so it can not display the menu entries greater than
> > the console row size.
> >
> > This commit add the vertial scroll support.
> > The console size is retrieved by
> > SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() service, then
> > calculates the row size for menu entry by subtracting
> > menu header and description row size from the console row size.
> > "start" and "end" are added in the efimenu structure.
> > "start" keeps the menu entry index at the top, "end" keeps
> > the bottom menu entry index. item_data_print() menu function
> > only draws the menu entry between "start" and "end".
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > No update since v1
> >
> > cmd/eficonfig.c | 79
> > include/efi_config.h | 4 +++
> > include/efi_loader.h | 1 +
> > 3 files changed, 70 insertions(+), 14 deletions(-)
> >
> > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > index 13929cb003..e289d95589 100644
> > --- a/cmd/eficonfig.c
> > +++ b/cmd/eficonfig.c
> > @@ -29,8 +29,13 @@ static const char *eficonfig_change_boot_order_desc =
> > " Press SPACE to activate or deactivate the entry\n"
> > " Select [Save] to complete, ESC/CTRL+C to quit";
> >
> > +static struct efi_simple_text_output_protocol *cout;
> > +static int avail_row;
> > +
> > #define EFICONFIG_DESCRIPTION_MAX 32
> > #define EFICONFIG_OPTIONAL_DATA_MAX 64
> > +#define EFICONFIG_MENU_HEADER_ROW_NUM 3
> > +#define EFICONFIG_MENU_DESC_ROW_NUM 5
> >
> > /**
> > * struct eficonfig_filepath_info - structure to be used to store file path
> > @@ -156,18 +161,16 @@ void eficonfig_print_entry(void *data)
> > struct eficonfig_entry *entry = data;
> > int reverse = (entry->efi_menu->active == entry->num);
> >
> > - /* TODO: support scroll or page for many entries */
> > + if (entry->efi_menu->start > entry->num || entry->efi_menu->end <
> > entry->num)
> > + return;
> >
> > - /*
> > - * Move cursor to line where the entry will be drawn (entry->num)
> > - * First 3 lines(menu header) + 1 empty line
> > - */
> > - printf(ANSI_CURSOR_POSITION, entry->num + 4, 7);
> > + printf(ANSI_CURSOR_POSITION, (entry->num - entry->efi_menu->start) +
> > +EFICONFIG_MENU_HEADER_ROW_NUM + 1, 7);
> >
> > if (reverse)
> > puts(ANSI_COLOR_REVERSE);
> >
> > - printf("%s", entry->title);
> > + printf(ANSI_CLEAR_LINE "%s", entry->title);
> >
> > if (reverse)
> > puts(ANSI_COLOR_RESET);
> > @@ -190,8 +193,8 @@ void eficonfig_display_statusline(struct menu *m)
> > ANSI_CURSOR_POSITION ANSI_CLEAR_LINE ANSI_CURSOR_POSITION
> > "%s"
> > ANSI_CLEAR_LINE_TO_END,
> > -1, 1, entry->efi_menu->menu_header, entry->efi_menu->count +
> > 5, 1,
> > -entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc);
> > +1, 1, entry->efi_menu->menu_header, avail_row + 4, 1,
> > +avail_row + 5, 1, entry->efi_menu->menu_desc);
> > }
> >
> > /**
> > @@ -213,13 +216,23 @@ char *eficonfig_choice_entry(void *data)
> >
> > switch (key) {
> > case KEY_UP:
> > - if (efi_menu->active > 0)
> > + if (efi_menu->active > 0) {
> > --efi_menu->active;
> > + if (efi_menu->start > efi_menu->active) {
> > + efi_menu->start--;
> > + efi_menu->end--;
> > + }
> > + }
> > /* no menu key selected, regenerate menu */
> > return NULL;
> > case KEY_DOWN:
> > - if (efi_menu->active < efi_menu->count - 1)
> > + if (efi_menu->active < efi_menu->count - 1) {
> > ++efi_menu->active;
> > + if (efi_menu->end < efi_menu->active) {
> > + efi_menu->start++;
> > + efi_menu->end++;
> > + }
> > + }
> > /* no menu key selected, regenerate menu */
> > return NULL;
> > case KEY_SELECT:
> > @@ -399,6 +412,8 @@ efi_status_t eficonfig_process_common(struct efimenu
> > *efi_menu,
> >
> > efi_menu->delay = -1;
> > efi_menu->active = 0;
> > + efi_menu->start = 0;
> > + efi_menu->end = avail_row - 1;
> >
> > if (menu_header) {
> > efi_menu->menu_header = strdup(menu_header);
> > @@ -1865,7
Re: [PATCH v3] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
> On Wed, Jan 4, 2023 at 10:08 AM Rick Chen wrote:
> >
> > Original openSBI (without FW_PIC) will relocate itself
>
> nits: OpenSBI
>
> > from 0x100 to 0x0. After openSBI added FW_PIC codes,
>
> ditto
OK, will fix it.
>
> > it will not relocate any more and always run at 0x100.
> > Hence, it may overlap with Kernel memory region. So it is
>
> with the Linux kernel?
>
> > necessary to change openSBI address from 0x100 to 0x0.
>
> ditto
OK, will fix it.
>
> >
> > More details can refer to commit cb052d771200
> > ("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
> >
> > Signed-off-by: Rick Chen
> > Reviewed-by: Samuel Holland
> > ---
> > Changes in v3
> > - fix typos
> > ---
> > board/AndesTech/ax25-ae350/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/AndesTech/ax25-ae350/Kconfig
> > b/board/AndesTech/ax25-ae350/Kconfig
> > index 36b67f0b52..4bb33b0793 100644
> > --- a/board/AndesTech/ax25-ae350/Kconfig
> > +++ b/board/AndesTech/ax25-ae350/Kconfig
> > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE
> > default 0x80
> >
> > config SPL_OPENSBI_LOAD_ADDR
> > - default 0x0100
> > + default 0x
> >
> > config SYS_FDT_BASE
> > hex
> > --
> > 2.17.1
> >
>
> Otherwise,
> Reviewed-by: Bin Meng
Thanks for reviewing.
B.R,
Rick
[PATCH v4] riscv: ae350: support OpenSBI 1.0+ which enable FW_PIC
Original OpenSBI (without FW_PIC) will relocate itself
from 0x100 to 0x0. After OpenSBI added FW_PIC codes,
it will not relocate any more and always run at 0x100.
Hence, it may overlap with Kernel memory region. So it is
necessary to change OpenSBI address from 0x100 to 0x0.
More details can refer to commit cb052d771200
("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
Signed-off-by: Rick Chen
Reviewed-by: Samuel Holland
Reviewed-by: Bin Meng
---
Changes in v4
- fix openSBI typo
---
board/AndesTech/ax25-ae350/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/Kconfig
b/board/AndesTech/ax25-ae350/Kconfig
index 36b67f0b52..4bb33b0793 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -25,7 +25,7 @@ config SPL_TEXT_BASE
default 0x80
config SPL_OPENSBI_LOAD_ADDR
- default 0x0100
+ default 0x
config SYS_FDT_BASE
hex
--
2.17.1
Re: [PATCH v2 1/3] eficonfig: refactor eficonfig_process_common function
Hi Ilias,
On Tue, 27 Dec 2022 at 23:41, Ilias Apalodimas
wrote:
>
> Hi Kojima-san
>
>
> Overall I think the cleanup is nice and easier to maintain in the long
> run.
>
> On Sat, Dec 24, 2022 at 07:57:42AM +0900, Masahisa Kojima wrote:
> > Current change boot order implementation does not call
> > eficonfig_process_common() and call own menu functions
> > for display_statusline, item_data_print and item_choice.
> > Change boot order functionality should call
> > eficonfig_process_common() to improve maintenanceability.
> >
> > This commit is a preparation to remove the change boot
> > order specific implementation. The menu functions
> > (display_statusline, item_data_print and item_choice) are
> > added as argument of eficonfig_process_common().
> > The menu description string displayed at the bottom of
> > the menu is also added as argument.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changes in v2:
> > - add const qualifier to eficonfig_menu_desc, change it to pointer
> >
> > cmd/eficonfig.c | 69 +--
> > cmd/eficonfig_sbkey.c | 18 +--
> > include/efi_config.h | 13 +++-
> > 3 files changed, 81 insertions(+), 19 deletions(-)
> >
> > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > index ce7175a566..2fc486dac2 100644
> > --- a/cmd/eficonfig.c
> > +++ b/cmd/eficonfig.c
> > @@ -21,6 +21,8 @@
> > #include
> >
> > static struct efi_simple_text_input_protocol *cin;
> > +const char *eficonfig_menu_desc =
> > + " Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit";
> >
> > #define EFICONFIG_DESCRIPTION_MAX 32
> > #define EFICONFIG_OPTIONAL_DATA_MAX 64
> > @@ -133,7 +135,7 @@ void eficonfig_print_msg(char *msg)
> > *
> > * @data:pointer to the data associated with each menu entry
> > */
> > -static void eficonfig_print_entry(void *data)
> > +void eficonfig_print_entry(void *data)
> > {
> > struct eficonfig_entry *entry = data;
> > int reverse = (entry->efi_menu->active == entry->num);
> > @@ -160,7 +162,7 @@ static void eficonfig_print_entry(void *data)
> > *
> > * @m: pointer to the menu structure
> > */
> > -static void eficonfig_display_statusline(struct menu *m)
> > +void eficonfig_display_statusline(struct menu *m)
> > {
> > struct eficonfig_entry *entry;
> >
> > @@ -170,10 +172,11 @@ static void eficonfig_display_statusline(struct menu
> > *m)
> > printf(ANSI_CURSOR_POSITION
> > "\n%s\n"
> > ANSI_CURSOR_POSITION ANSI_CLEAR_LINE ANSI_CURSOR_POSITION
> > -" Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit"
> > +"%s"
> > ANSI_CLEAR_LINE_TO_END ANSI_CURSOR_POSITION ANSI_CLEAR_LINE,
> > 1, 1, entry->efi_menu->menu_header, entry->efi_menu->count +
> > 5, 1,
> > -entry->efi_menu->count + 6, 1, entry->efi_menu->count + 7, 1);
> > +entry->efi_menu->count + 6, 1, entry->efi_menu->menu_desc,
> > +entry->efi_menu->count + 7, 1);
> > }
> >
> > /**
> > @@ -182,7 +185,7 @@ static void eficonfig_display_statusline(struct menu *m)
> > * @data:pointer to the efimenu structure
> > * Return: key string to identify the selected entry
> > */
> > -static char *eficonfig_choice_entry(void *data)
> > +char *eficonfig_choice_entry(void *data)
> > {
> > int esc = 0;
> > struct list_head *pos, *n;
> > @@ -358,9 +361,17 @@ out:
> > *
> > * @efi_menu:pointer to the efimenu structure
> > * @menu_header: pointer to the menu header string
> > + * @menu_desc: pointer to the menu description
> > + * @display_statusline: function pointer to draw statusline
> > + * @item_data_print: function pointer to draw the menu item
> > + * @item_choice: function pointer to handle the key press
> > * Return: status code
> > */
> > -efi_status_t eficonfig_process_common(struct efimenu *efi_menu, char
> > *menu_header)
> > +efi_status_t eficonfig_process_common(struct efimenu *efi_menu,
> > + char *menu_header, const char
> > *menu_desc,
> > + void (*display_statusline)(struct menu
> > *),
> > + void (*item_data_print)(void *),
> > + char *(*item_choice)(void *))
> > {
> > struct menu *menu;
> > void *choice = NULL;
> > @@ -379,10 +390,11 @@ efi_status_t eficonfig_process_common(struct efimenu
> > *efi_menu, char *menu_heade
> > if (!efi_menu->menu_header)
> > return EFI_OUT_OF_RESOURCES;
> > }
> > + if (menu_desc)
> > + efi_menu->menu_desc = menu_desc;
> >
> > - menu = menu_create(NULL, 0, 1, eficonfig_display_statusline,
> > -eficonfig_print_entry, eficonfig_choice_entry,
> > -efi_menu);
> > + menu = menu_create(NULL, 0, 1, display_statusline,
Re: [PATCH v3] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
On Wed, Jan 4, 2023 at 10:08 AM Rick Chen wrote:
>
> Original openSBI (without FW_PIC) will relocate itself
nits: OpenSBI
> from 0x100 to 0x0. After openSBI added FW_PIC codes,
ditto
> it will not relocate any more and always run at 0x100.
> Hence, it may overlap with Kernel memory region. So it is
with the Linux kernel?
> necessary to change openSBI address from 0x100 to 0x0.
ditto
>
> More details can refer to commit cb052d771200
> ("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
>
> Signed-off-by: Rick Chen
> Reviewed-by: Samuel Holland
> ---
> Changes in v3
> - fix typos
> ---
> board/AndesTech/ax25-ae350/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/AndesTech/ax25-ae350/Kconfig
> b/board/AndesTech/ax25-ae350/Kconfig
> index 36b67f0b52..4bb33b0793 100644
> --- a/board/AndesTech/ax25-ae350/Kconfig
> +++ b/board/AndesTech/ax25-ae350/Kconfig
> @@ -25,7 +25,7 @@ config SPL_TEXT_BASE
> default 0x80
>
> config SPL_OPENSBI_LOAD_ADDR
> - default 0x0100
> + default 0x
>
> config SYS_FDT_BASE
> hex
> --
> 2.17.1
>
Otherwise,
Reviewed-by: Bin Meng
[PATCH v3] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
Original openSBI (without FW_PIC) will relocate itself
from 0x100 to 0x0. After openSBI added FW_PIC codes,
it will not relocate any more and always run at 0x100.
Hence, it may overlap with Kernel memory region. So it is
necessary to change openSBI address from 0x100 to 0x0.
More details can refer to commit cb052d771200
("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
Signed-off-by: Rick Chen
Reviewed-by: Samuel Holland
---
Changes in v3
- fix typos
---
board/AndesTech/ax25-ae350/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/Kconfig
b/board/AndesTech/ax25-ae350/Kconfig
index 36b67f0b52..4bb33b0793 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -25,7 +25,7 @@ config SPL_TEXT_BASE
default 0x80
config SPL_OPENSBI_LOAD_ADDR
- default 0x0100
+ default 0x
config SYS_FDT_BASE
hex
--
2.17.1
[PATCH v3 2/2] riscv: memcpy: check src and dst before copy
Add src and dst address checking, if they are the same address, just return and don't copy data anymore. Signed-off-by: Rick Chen --- Changes in v3 - new patch: separate from [1/2] --- arch/riscv/lib/memcpy.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S index 00672c19ad..9884077c93 100644 --- a/arch/riscv/lib/memcpy.S +++ b/arch/riscv/lib/memcpy.S @@ -9,6 +9,7 @@ /* void *memcpy(void *, const void *, size_t) */ ENTRY(__memcpy) WEAK(memcpy) + beq a0, a1, .copy_end /* Save for return value */ mv t6, a0 @@ -121,6 +122,7 @@ WEAK(memcpy) 2: mv a0, t6 +.copy_end: ret .Lmisaligned_word_copy: -- 2.17.1
[PATCH v3 1/2] riscv: ax25: bypass malloc when spl fit boots from ram
When fit image boots from ram, the payload will
be prepared in the address of SPL_LOAD_FIT_ADDRESS.
In spl fit generic flow, it will malloc another
memory address and copy whole fit image to this
malloc address. But it is un-necessary for booting
from RAM.
This patch improves this flow by declare the
board_spl_fit_buffer_addr() to replace the original one.
The larger image size (eq: Kernel Image 10~20MB), it
can save more booting time.
Signed-off-by: Rick Chen
---
Changes in v3
- fix aligment
- refine board_spl_fit_buffer_addr
---
arch/riscv/cpu/ax25/Makefile | 1 +
arch/riscv/cpu/ax25/spl.c| 27 +++
2 files changed, 28 insertions(+)
create mode 100644 arch/riscv/cpu/ax25/spl.c
diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
index 318baccb09..35a1a2fb83 100644
--- a/arch/riscv/cpu/ax25/Makefile
+++ b/arch/riscv/cpu/ax25/Makefile
@@ -5,3 +5,4 @@
obj-y := cpu.o
obj-y += cache.o
+obj-y += spl.o
diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/ax25/spl.c
new file mode 100644
index 00..413849043b
--- /dev/null
+++ b/arch/riscv/cpu/ax25/spl.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if CONFIG_IS_ENABLED(RAM_SUPPORT)
+struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
+{
+ return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
+}
+
+void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
+{
+ return spl_get_load_buffer(0, sectors * bl_len);
+}
+#endif
--
2.17.1
Re: [PATCH v2] riscv: ax25: bypass malloc when spl fit boots from ram
> Hi Rick,
>
> On 1/3/23 02:20, Rick Chen wrote:
> > When fit image boots from ram, the payload will
> > be prepared in the address of SPL_LOAD_FIT_ADDRESS.
> > In spl fit generic flow, it will malloc another
> > memory address and copy whole fit image to this
> > malloc address. But it is un-necessary for booting
> > from RAM.
> >
> > This patch improves this flow by declare the
> > board_spl_fit_buffer_addr() to replace the original one.
> > The larger image size (eq: Kernel Image 10~20MB), it
> > can save more booting time.
> >
> > Also enhance memcpy function by checking source and
> > destination address. If they are the same address,
> > just return and don't copy data anymore.
>
> Starting a paragraph with "also" is a good indication that this should
> be split into two separate patches.
OK, I will separate it to another patch.
>
> > Signed-off-by: Rick Chen
> > ---
> > Changes in v2
> > - Move spl.c to board level instead of arch level
> > ---
> > arch/riscv/cpu/ax25/Makefile | 1 +
> > arch/riscv/cpu/ax25/spl.c| 31 +++
> > arch/riscv/lib/memcpy.S | 2 ++
> > 3 files changed, 34 insertions(+)
> > create mode 100644 arch/riscv/cpu/ax25/spl.c
> >
> > diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
> > index 318baccb09..f1c21eadd4 100644
> > --- a/arch/riscv/cpu/ax25/Makefile
> > +++ b/arch/riscv/cpu/ax25/Makefile
> > @@ -5,3 +5,4 @@
> >
> > obj-y:= cpu.o
> > obj-y+= cache.o
> > +obj-y += spl.o
>
> nit: alignment
OK, I will fix it.
>
> > diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/ax25/spl.c
> > new file mode 100644
> > index 00..6bf357d26d
> > --- /dev/null
> > +++ b/arch/riscv/cpu/ax25/spl.c
> > @@ -0,0 +1,31 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2023 Andes Technology Corporation
> > + * Rick Chen, Andes Technology Corporation
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#if CONFIG_IS_ENABLED(RAM_SUPPORT)
> > +struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
> > +{
> > + return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
> > +}
> > +
> > +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
> > +{
> > + void *buf;
> > +
> > + buf = spl_get_load_buffer(0, sectors * bl_len);
> > +
> > + return buf;
>
> nit: this could all be one line
OK, I will refine it.
B,R,
Rick
>
> Regards,
> Samuel
>
> > +}
> > +#endif
> > diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
> > index 00672c19ad..9884077c93 100644
> > --- a/arch/riscv/lib/memcpy.S
> > +++ b/arch/riscv/lib/memcpy.S
> > @@ -9,6 +9,7 @@
> > /* void *memcpy(void *, const void *, size_t) */
> > ENTRY(__memcpy)
> > WEAK(memcpy)
> > + beq a0, a1, .copy_end
> > /* Save for return value */
> > mv t6, a0
> >
> > @@ -121,6 +122,7 @@ WEAK(memcpy)
> > 2:
> >
> > mv a0, t6
> > +.copy_end:
> > ret
> >
> > .Lmisaligned_word_copy:
>
Re: [PATCH v2] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
Hi Samuel
> On 1/3/23 02:18, Rick Chen wrote:
> > Original openSBI (without FW_PIC) will relocate itselt
>
> typo: itself
OK, I will fix it.
>
> > from 0x100 to 0x0. After openSBI added FW_PIC codes,
> > it will not relocate any more and alaways run at 0x100.
>
> typo: always
OK, I will fix it.
>
> > Hence, it may overlap with Kernel memory region. So it is
> > necessary to change openSBI address from 0x100 to 0x0.
> >
> > More details can refer to commit cb052d771200
> > ("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
> >
> > Signed-off-by: Rick Chen
>
> Reviewed-by: Samuel Holland
Thank you for reviewing.
Best Regards,
Rick
>
> > ---
> >
> > Changes in v2
> > - fix typo
> > - describe why is this change a must have
> >
> > ---
> >
> > board/AndesTech/ax25-ae350/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/AndesTech/ax25-ae350/Kconfig
> > b/board/AndesTech/ax25-ae350/Kconfig
> > index 36b67f0b52..4bb33b0793 100644
> > --- a/board/AndesTech/ax25-ae350/Kconfig
> > +++ b/board/AndesTech/ax25-ae350/Kconfig
> > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE
> > default 0x80
> >
> > config SPL_OPENSBI_LOAD_ADDR
> > - default 0x0100
> > + default 0x
> >
> > config SYS_FDT_BASE
> > hex
> > --
> > 2.17.1
> >
>
Re: [PATCH 4/4] sunxi: move arch timer setup out of board/ directory
On Wed, 14 Dec 2022 00:14:49 -0600
Samuel Holland wrote:
Hi Samuel,
thanks for having a look!
> On 12/13/22 18:22, Andre Przywara wrote:
> > At the moment we have an #ifdef-protected routine in
> > board/sunxi/board.c, which sets up the arch timer CNTFRQ register, if
> > that hasn't been done already.
> > This only applies to ARMv7 SoCs running in secure state, and so is
> > much better located in the arch/arm/mach-sunxi directory.
> >
> > Move that routine into a separate function and file in said directory,
> > which also allows to trigger the compilation for ARMv7 in the Makefile.
> > Also move the call to it into the arch/arm version of board.c.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > arch/arm/mach-sunxi/Makefile | 4
> > arch/arm/mach-sunxi/arch_timer.c | 39
> > arch/arm/mach-sunxi/board.c | 14
> > board/sunxi/board.c | 34 +---
> > 4 files changed, 54 insertions(+), 37 deletions(-)
> > create mode 100644 arch/arm/mach-sunxi/arch_timer.c
> >
> > diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> > index 58f807cb82d..335c44476e9 100644
> > --- a/arch/arm/mach-sunxi/Makefile
> > +++ b/arch/arm/mach-sunxi/Makefile
> > @@ -26,8 +26,12 @@ obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
> > endif
> > obj-$(CONFIG_MACH_SUN9I) += clock_sun9i.o gtbus_sun9i.o
> > obj-$(CONFIG_SUN50I_GEN_H6)+= clock_sun50i_h6.o
> > +
> > ifndef CONFIG_ARM64
> > obj-y += timer.o
> > +ifndef CONFIG_MACH_SUNIV
>
> Probably Allwinner will not release any new ARMv5 SoC, but would it be
> more future-proof (and a bit more meaningful) to condition this on
> CONFIG_CPU_V7A?
Ah, of course, I forgot about that symbol, and just saw !CONFIG_ARM64.
> Alternatively, would it make sense to put this code inside
> arch/arm/cpu/armv7/arch_timer.c? I don't know why we wouldn't want to
> enable CONFIG_SYS_ARCH_TIMER on sunxi SoCs where it is available. And
> making this generic could eventually remove the need for the version in
> arch/arm/cpu/armv7/nonsec_virt.S. But this patch is still an improvement
> as-is.
Yeah, that indeed sounds even better, I will give it a try. I guess
sunxi will stay the only user for now, but we can extend this later on.
Thanks for the suggestion!
Cheers,
Andre
> Tested-by: Samuel Holland
>
> > +obj-y += arch_timer.o
> > +endif
> > endif
> >
> > ifdef CONFIG_SPL_BUILD
> > diff --git a/arch/arm/mach-sunxi/arch_timer.c
> > b/arch/arm/mach-sunxi/arch_timer.c
> > new file mode 100644
> > index 000..c0e4310741f
> > --- /dev/null
> > +++ b/arch/arm/mach-sunxi/arch_timer.c
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * ARM Generic Timer CNTFRQ setup
> > + *
> > + * (C) Copyright 2013 Oliver Schinagl
>
> `git blame` points to cba69eeeaa67d3fb93ec6f3abab1f653abf895a9 and
> d96ebc468d0dff6eb6f069bba03b3f0e33aa22de as the source for this code, so
> this authorship is incorrect.
>
> > + */
> > +
> > +#include
>
> This does not do what you expect, or really anything at all. The comment
> there suggests using linux/types.h.
>
> Regards,
> Samuel
>
> > +#include
> > +#include
> > +
> > +void setup_arch_timer(void)
> > +{
> > + uint32_t id_pfr1, freq;
> > +
> > + asm volatile("mrc p15, 0, %0, c0, c1, 1" : "=r"(id_pfr1));
> > + debug("id_pfr1: 0x%08x\n", id_pfr1);
> > + /* Generic Timer Extension available? */
> > + if (((id_pfr1 >> CPUID_ARM_GENTIMER_SHIFT) & 0xf) == 0)
> > + return;
> > +
> > + /*
> > +* CNTFRQ is a secure register, so we will crash if we try to
> > +* write this from the non-secure world (read is OK, though).
> > +* In case some bootcode has already set the correct value,
> > +* we avoid the risk of writing to it.
> > +*/
> > + asm volatile("mrc p15, 0, %0, c14, c0, 0" : "=r"(freq));
> > + if (freq == CONFIG_COUNTER_FREQUENCY)
> > + return;
> > +
> > + debug("arch timer frequency is %d Hz, should be %d, fixing ...\n",
> > + freq, CONFIG_COUNTER_FREQUENCY);
> > + if (IS_ENABLED(CONFIG_NON_SECURE))
> > + printf("arch timer frequency is wrong, but cannot adjust it\n");
> > + else
> > + asm volatile("mcr p15, 0, %0, c14, c0, 0"
> > +: : "r"(CONFIG_COUNTER_FREQUENCY));
> > +}
> > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> > index 0c4b6dd1ca3..943f89eaa78 100644
> > --- a/arch/arm/mach-sunxi/board.c
> > +++ b/arch/arm/mach-sunxi/board.c
> > @@ -347,10 +347,6 @@ u32 spl_boot_device(void)
> > return sunxi_get_boot_device();
> > }
> >
> > -__weak void sunxi_sram_init(void)
> > -{
> > -}
> > -
> > /*
> > * When booting from an eMMC boot partition, the SPL puts the same boot
> > * source code into SRAM A1 as when loading the SPL from the normal
> > @@ -434,10 +430,20 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32
> > boot_device)
> >
Re: [PATCH 0/8] sunxi: Update H616 DRAM driver
On Sun, 11 Dec 2022 17:32:05 +0100 Jernej Skrabec wrote: Hi Jernej, > Current H616 DRAM driver is completely customized to Orange Pi Zero2 > board, which is currently the only H616 board supported by U-Boot. > Needless to say, this is not ideal for adding new boards. With changes > in this series, all DDR3 boards are supported and all that is needed is > just vendor DRAM values extracted from Android image. New DRAM types > should also be easier to support, since a lot of constants used before > are not really DRAM type dependent. > > Changes were verified by decompiling driver and generated values were > compared to previous, hard coded ones. This was done without dram_para > structures, so compiler was able to heavily optimize code and produce > constants. so many thanks again for putting this together! I came to like (the idea of) this series very much lately, as this removes timing/delay values from the code, and easily allows putting the vendor provided values in the defconfig. I used that approach as well for the D1 driver, and am wondering if we should extend this to other SoCs, potentially unifying the Kconfig part? And you hinted at a v2, can you provide an estimate for this? If you send it still this week, I would like to put it into U-Boot's next branch, otherwise it goes straight into master, should the merge window open next week as planned. Btw., to verify the feasibility of drivers/ram/sunxi, I moved the H616 driver into there, together with the Kconfig parts, I wonder what you think about this? An example of how this looks is in the D1 driver patches. Cheers, Andre > > Please take a look. > > Best regards, > Jernej > > Jernej Skrabec (8): > sunxi: Fix write to H616 DRAM CR register > sunxi: cosmetic: Fix H616 DRAM driver code style > sunxi: parameterize H616 DRAM ODT values > sunxi: Convert H616 DRAM options to single setting > sunxi: Always configure ODT on H616 DRAM > sunxi: Make bit delay function in H616 DRAM code void > sunxi: Parameterize bit delay code in H616 DRAM driver > sunxi: Parameterize H616 DRAM code some more > > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 18 + > arch/arm/mach-sunxi/Kconfig | 67 +-- > arch/arm/mach-sunxi/dram_sun50i_h616.c| 445 +++--- > configs/orangepi_zero2_defconfig | 8 +- > 4 files changed, 348 insertions(+), 190 deletions(-) >
Re: [PATCH 7/8] sunxi: Parameterize bit delay code in H616 DRAM driver
On Sun, 11 Dec 2022 17:32:12 +0100
Jernej Skrabec wrote:
Hi Jernej,
> These values are highly board specific and thus make sense to add
> parameter for them. To ease adding support for new boards, let's make
> them same as in vendor DRAM settings.
So scrolling up and down: does this patch miss the TPR11 and TPR12
values in the OPi-Zero2 defconfig? And should we not default to 0 in
Kconfig to help spotting this omission more easily for new boards?
If I pieced the bits together correctly, we end up with the same values
in the register with TPR11=0xfffedddb and TPR12=0xeddca998, and ODT_EN
being irrelevant.
> Signed-off-by: Jernej Skrabec
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 4 +
> arch/arm/mach-sunxi/Kconfig | 18 ++
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 189 +-
> 3 files changed, 162 insertions(+), 49 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index b5140c79b70e..c7890c83391f 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -145,6 +145,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> #define TPR10_READ_CALIBRATION BIT(21)
> #define TPR10_READ_TRAINING BIT(22)
> #define TPR10_WRITE_TRAINING BIT(23)
> +#define TPR10_UNKNOWN_FEAT3 BIT(30)
As mentioned in the other patch: if we don't know the meaning of this
bit, I'd prefer using BIT(30) directly, or at least encode BIT30
in the name.
>
> struct dram_para {
> u32 clk;
> @@ -156,7 +157,10 @@ struct dram_para {
> u32 dx_odt;
> u32 dx_dri;
> u32 ca_dri;
> + u32 odt_en;
> u32 tpr10;
> + u32 tpr11;
> + u32 tpr12;
> };
>
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 778304b77e26..b050f0a56971 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -67,11 +67,29 @@ config DRAM_SUN50I_H616_CA_DRI
> help
> CA DRI value from vendor DRAM settings.
>
> +config DRAM_SUN50I_H616_ODT_EN
> + hex "H616 DRAM ODT EN parameter"
> + default 0x1
> + help
> + ODT EN value from vendor DRAM settings.
> +
> config DRAM_SUN50I_H616_TPR10
> hex "H616 DRAM TPR10 parameter"
> help
> TPR10 value from vendor DRAM settings. It tells which features
> should be configured, like write leveling, read calibration, etc.
> +
> +config DRAM_SUN50I_H616_TPR11
> + hex "H616 DRAM TPR11 parameter"
> + default 0x0
> + help
> + TPR11 value from vendor DRAM settings.
> +
> +config DRAM_SUN50I_H616_TPR12
> + hex "H616 DRAM TPR12 parameter"
> + default 0x0
> + help
> + TPR12 value from vendor DRAM settings.
> endif
>
> config SUN6I_PRCM
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 3b2ba168498c..df06cea42464 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -574,7 +574,7 @@ static bool mctl_phy_write_training(struct dram_para
> *para)
>
> static void mctl_phy_bit_delay_compensation(struct dram_para *para)
> {
> - u32 *ptr;
> + u32 *ptr, val;
> int i;
>
> if (para->tpr10 & TPR10_UNKNOWN_FEAT2) {
> @@ -582,49 +582,93 @@ static void mctl_phy_bit_delay_compensation(struct
> dram_para *para)
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 8);
> clrbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 0x10);
>
> + if (para->tpr10 & TPR10_UNKNOWN_FEAT3)
> + val = para->tpr11 & 0x3f;
> + else
> + val = (para->tpr11 & 0xf) << 1;
> +
> ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x484);
> for (i = 0; i < 9; i++) {
> - writel_relaxed(0x16, ptr);
> - writel_relaxed(0x16, ptr + 0x30);
> + writel_relaxed(val, ptr);
> + writel_relaxed(val, ptr + 0x30);
> ptr += 2;
> }
> - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x4d0);
> - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x590);
> - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x4cc);
> - writel_relaxed(0x1c, SUNXI_DRAM_PHY0_BASE + 0x58c);
> +
> + if (para->tpr10 & TPR10_UNKNOWN_FEAT3)
> + val = (para->odt_en >> 15) & 0x1e;
So I guess odt_en stands for "ODT enable". Looking at the D1 DRAM
driver, they have a boot0 parameter odt_en which is either 0x0 or 0x1,
so it looks like a boolean value. This seems to be also the case here?
In the D1 driver, this seems to gate the ZQ value being used, which
provides the actual timing values.
So is TPR10_UNKNOWN_FEAT3 actually this ODT_EN switch, and the variable
containing the timing bits should be zq_value or CONFIG_DRAM_ZQ?
Re: [PATCH 3/8] sunxi: parameterize H616 DRAM ODT values
On Sun, 11 Dec 2022 17:32:08 +0100
Jernej Skrabec wrote:
Hi Jernej,
> While ODT values for same memory type are similar, they are not
> necessary the same. Let's parameterize them and make parameter same as
> in vendor DRAM settings. That way it will be easy to introduce new board
> support.
checked that this results in the same parameters to writel().
One small thing below:
>
> Signed-off-by: Jernej Skrabec
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 3 +
> arch/arm/mach-sunxi/Kconfig | 15 +
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 59 ---
> configs/orangepi_zero2_defconfig | 3 +
> 4 files changed, 58 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index 134679d55205..c9e1f84bfcdd 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -144,6 +144,9 @@ struct dram_para {
> u8 rows;
> u8 ranks;
> u8 bus_full_width;
> + u32 dx_odt;
> + u32 dx_dri;
> + u32 ca_dri;
> };
>
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index dbe6005daab1..cad53f19912c 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -83,6 +83,21 @@ config DRAM_SUN50I_H616_UNKNOWN_FEATURE
> ---help---
> Select this when DRAM on your H616 board needs this unknown
> feature.
> +
> +config DRAM_SUN50I_H616_DX_ODT
> + hex "H616 DRAM DX ODT parameter"
> + help
> + DX ODT value from vendor DRAM settings.
> +
> +config DRAM_SUN50I_H616_DX_DRI
> + hex "H616 DRAM DX DRI parameter"
> + help
> + DX DRI value from vendor DRAM settings.
> +
> +config DRAM_SUN50I_H616_CA_DRI
> + hex "H616 DRAM CA DRI parameter"
> + help
> + CA DRI value from vendor DRAM settings.
> endif
>
> config SUN6I_PRCM
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 49983bf7a1b8..06a07dfbf9cc 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -234,37 +234,49 @@ static const u8 phy_init[] = {
> 0x09, 0x05, 0x18
> };
>
> -static void mctl_phy_configure_odt(void)
> +static void mctl_phy_configure_odt(struct dram_para *para)
> {
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x388);
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x38c);
> + unsigned int val;
>
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x3c8);
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x3cc);
> + val = para->dx_dri & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x388);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x38c);
>
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x408);
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x40c);
> + val = (para->dx_dri >> 8) & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c8);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3cc);
>
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x448);
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x44c);
> + val = (para->dx_dri >> 16) & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x408);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x40c);
>
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x340);
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x344);
> + val = (para->dx_dri >> 24) & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x448);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x44c);
>
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x348);
> - writel_relaxed(0xe, SUNXI_DRAM_PHY0_BASE + 0x34c);
> + val = para->ca_dri & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x340);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x344);
>
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x380);
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x384);
> + val = (para->ca_dri >> 8) & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x348);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c);
>
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x3c4);
> + val = para->dx_odt & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384);
>
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x400);
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x404);
> + val = (para->dx_odt >> 8) & 0x1f;
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4);
>
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x440);
> - writel_relaxed(0x8, SUNXI_DRAM_PHY0_BASE + 0x444);
> + val = (para->dx_odt >> 16) & 0x1f;
> +
Re: [PATCH 2/8] sunxi: cosmetic: Fix H616 DRAM driver code style
On Sun, 11 Dec 2022 17:32:07 +0100
Jernej Skrabec wrote:
Hi,
> Fix code style for pointer declaration. This is just cosmetic change to
> avoid checkpatch errors in later commits.
>
> Signed-off-by: Jernej Skrabec
confirmed to be just s/(u32\*)/(u32 *)/:
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> arch/arm/mach-sunxi/dram_sun50i_h616.c | 74 +-
> 1 file changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 039e76224367..49983bf7a1b8 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -285,7 +285,7 @@ static bool mctl_phy_write_leveling(struct dram_para
> *para)
> else
> val = 3;
>
> - mctl_await_completion((u32*)(SUNXI_DRAM_PHY0_BASE + 0x188), val, val);
> + mctl_await_completion((u32 *)(SUNXI_DRAM_PHY0_BASE + 0x188), val, val);
>
> clrbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 4);
>
> @@ -314,7 +314,7 @@ static bool mctl_phy_write_leveling(struct dram_para
> *para)
> else
> val = 3;
>
> - mctl_await_completion((u32*)(SUNXI_DRAM_PHY0_BASE + 0x188),
> val, val);
> + mctl_await_completion((u32 *)(SUNXI_DRAM_PHY0_BASE + 0x188),
> val, val);
>
> clrbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 4);
> }
> @@ -398,26 +398,26 @@ static bool mctl_phy_read_training(struct dram_para
> *para)
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 6);
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 1);
>
> - mctl_await_completion((u32*)(SUNXI_DRAM_PHY0_BASE + 0x840), 0xc, 0xc);
> + mctl_await_completion((u32 *)(SUNXI_DRAM_PHY0_BASE + 0x840), 0xc, 0xc);
> if (readl(SUNXI_DRAM_PHY0_BASE + 0x840) & 3)
> result = false;
>
> if (para->bus_full_width) {
> - mctl_await_completion((u32*)(SUNXI_DRAM_PHY0_BASE + 0xa40),
> 0xc, 0xc);
> + mctl_await_completion((u32 *)(SUNXI_DRAM_PHY0_BASE + 0xa40),
> 0xc, 0xc);
> if (readl(SUNXI_DRAM_PHY0_BASE + 0xa40) & 3)
> result = false;
> }
>
> - ptr1 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0x898);
> - ptr2 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0x850);
> + ptr1 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x898);
> + ptr2 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x850);
> for (i = 0; i < 9; i++) {
> val1 = readl([i]);
> val2 = readl([i]);
> if (val1 - val2 <= 6)
> result = false;
> }
> - ptr1 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0x8bc);
> - ptr2 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0x874);
> + ptr1 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x8bc);
> + ptr2 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x874);
> for (i = 0; i < 9; i++) {
> val1 = readl([i]);
> val2 = readl([i]);
> @@ -426,8 +426,8 @@ static bool mctl_phy_read_training(struct dram_para *para)
> }
>
> if (para->bus_full_width) {
> - ptr1 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0xa98);
> - ptr2 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0xa50);
> + ptr1 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0xa98);
> + ptr2 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0xa50);
> for (i = 0; i < 9; i++) {
> val1 = readl([i]);
> val2 = readl([i]);
> @@ -435,8 +435,8 @@ static bool mctl_phy_read_training(struct dram_para *para)
> result = false;
> }
>
> - ptr1 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0xabc);
> - ptr2 = (u32*)(SUNXI_DRAM_PHY0_BASE + 0xa74);
> + ptr1 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0xabc);
> + ptr2 = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0xa74);
> for (i = 0; i < 9; i++) {
> val1 = readl([i]);
> val2 = readl([i]);
> @@ -454,12 +454,12 @@ static bool mctl_phy_read_training(struct dram_para
> *para)
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 6);
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 1);
>
> - mctl_await_completion((u32*)(SUNXI_DRAM_PHY0_BASE + 0x840),
> 0xc, 0xc);
> + mctl_await_completion((u32 *)(SUNXI_DRAM_PHY0_BASE + 0x840),
> 0xc, 0xc);
> if (readl(SUNXI_DRAM_PHY0_BASE + 0x840) & 3)
> result = false;
>
> if (para->bus_full_width) {
> - mctl_await_completion((u32*)(SUNXI_DRAM_PHY0_BASE +
> 0xa40), 0xc, 0xc);
> + mctl_await_completion((u32 *)(SUNXI_DRAM_PHY0_BASE +
> 0xa40), 0xc, 0xc);
> if (readl(SUNXI_DRAM_PHY0_BASE + 0xa40) & 3)
> result = false;
> }
> @@ -488,26 +488,26 @@ static bool mctl_phy_write_training(struct dram_para
> *para)
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 0x10);
>
Re: [PATCH 1/8] sunxi: Fix write to H616 DRAM CR register
On Sun, 11 Dec 2022 17:32:06 +0100 Jernej Skrabec wrote: > Vendor DRAM code actually writes to whole CR register and not just sets > bit 31 in mctl_ctrl_init(). > > Just to be safe, do that here too. > > Signed-off-by: Jernej Skrabec Can't really verify this, but it seems to work (TM): Acked-by: Andre Przywara Cheers, Andre > --- > arch/arm/mach-sunxi/dram_sun50i_h616.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > b/arch/arm/mach-sunxi/dram_sun50i_h616.c > index 454c845a0010..039e76224367 100644 > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > @@ -873,7 +873,7 @@ static bool mctl_ctrl_init(struct dram_para *para) > writel(0x06000400, _ctl->unk_0x3240); > writel(0x06000400, _ctl->unk_0x4240); > > - setbits_le32(_com->cr, BIT(31)); > + writel(BIT(31), _com->cr); > > mctl_set_addrmap(para); >
Re: [PATCH 5/8] sunxi: Always configure ODT on H616 DRAM
On Sun, 11 Dec 2022 17:32:10 +0100 Jernej Skrabec wrote: > Vendor H616 DRAM code always configure part which we call ODT > configuration. Let's reflect that here too. I wonder if we need this patch at all. "depends on !H616" looks counter-intuitive, since this suggests it's always off. As it stands, it doesn't hurt. "default y" does the right thing, and if people want to shoot themselves in the foot: fine by me. At least I would like to keep the Kconfig part. We could change the condition in the code into an explaining comment, if you still want to force this on. And coming back from patch 7/8: how does this correspond to DRAM_SUN50I_H616_ODT_EN? Cheers, Andre > > Signed-off-by: Jernej Skrabec > --- > arch/arm/mach-sunxi/Kconfig| 2 +- > arch/arm/mach-sunxi/dram_sun50i_h616.c | 3 +-- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index abcbd0fb9061..778304b77e26 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -488,12 +488,12 @@ config DRAM_ZQ > > config DRAM_ODT_EN > bool "sunxi dram odt enable" > + depends on !MACH_SUN50I_H616 > default y if MACH_SUN8I_A23 > default y if MACH_SUNXI_H3_H5 > default y if MACH_SUN8I_R40 > default y if MACH_SUN50I > default y if MACH_SUN50I_H6 > - default y if MACH_SUN50I_H616 > ---help--- > Select this to enable dram odt (on die termination). > > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > b/arch/arm/mach-sunxi/dram_sun50i_h616.c > index 14a01a3c4e54..bf5b4ddfb5c2 100644 > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > @@ -736,8 +736,7 @@ static bool mctl_phy_init(struct dram_para *para) > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc); > writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x45c); > > - if (IS_ENABLED(CONFIG_DRAM_ODT_EN)) > - mctl_phy_configure_odt(para); > + mctl_phy_configure_odt(para); > > clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 4, 7, 0xa); >
Re: [PATCH 8/8] sunxi: Parameterize H616 DRAM code some more
On Sun, 11 Dec 2022 17:32:13 +0100
Jernej Skrabec wrote:
> Part of the code, previously known as "unknown feature" also doesn't
> have constant values. They are derived from TPR0 parameter in vendor
> DRAM code. Introduce that parameter here too, to ease adding new boards.
That seems to also miss the value for the OPi Zero2 defconfig.
>
> Signed-off-by: Jernej Skrabec
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 1 +
> arch/arm/mach-sunxi/Kconfig | 6
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 35 +++
> 3 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index c7890c83391f..ff736bd88d10 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -158,6 +158,7 @@ struct dram_para {
> u32 dx_dri;
> u32 ca_dri;
> u32 odt_en;
> + u32 tpr0;
> u32 tpr10;
> u32 tpr11;
> u32 tpr12;
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index b050f0a56971..7858a7045f7e 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -73,6 +73,12 @@ config DRAM_SUN50I_H616_ODT_EN
> help
> ODT EN value from vendor DRAM settings.
>
> +config DRAM_SUN50I_H616_TPR0
> + hex "H616 DRAM TPR0 parameter"
> + default 0x0
Is 0x0 really a feasible default value? I'd suggest we don't provide a
default, so force people to be prompted for a value, if nothing is in
(a new board's) defconfig.
The rest looks OK, though I can't really comment on the actual bits -
but who can anyway ;-)
Cheers,
Andre
> + help
> + TPR0 value from vendor DRAM settings.
> +
> config DRAM_SUN50I_H616_TPR10
> hex "H616 DRAM TPR10 parameter"
> help
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index df06cea42464..6d8f8d371bfe 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -808,15 +808,35 @@ static bool mctl_phy_init(struct dram_para *para)
> writel(phy_init[i], [i]);
>
> if (para->tpr10 & TPR10_UNKNOWN_FEAT0) {
> + if (para->tpr0 & BIT(30))
> + val = (para->tpr0 >> 7) & 0x3e;
> + else
> + val = (para->tpr10 >> 3) & 0x1e;
> +
> ptr = (u32 *)(SUNXI_DRAM_PHY0_BASE + 0x780);
> for (i = 0; i < 32; i++)
> - writel(0x16, [i]);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x78c);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> - writel(0x8, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> - writel(0xe, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> + writel(val, [i]);
> +
> + val = (para->tpr10 << 1) & 0x1e;
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7dc);
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> +
> + /* following configuration is DDR3 specific */
> + val = (para->tpr10 >> 7) & 0x1e;
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7d4);
> + /*
> + * TODO: Offsets 0x79c, 0x794 and 0x7e4 may need
> + * to be set here. However, this doesn't seem to
> + * be needed by any board seen in the wild for now.
> + * It's not implemented because it would unnecessarily
> + * introduce PARA2 and TPR2 options.
> + */
> + if (para->tpr0 & BIT(31)) {
> + val = (para->tpr0 << 1) & 0x3e;
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x78c);
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7a4);
> + writel(val, SUNXI_DRAM_PHY0_BASE + 0x7b8);
> + }
> }
>
> writel(0x80, SUNXI_DRAM_PHY0_BASE + 0x3dc);
> @@ -1110,6 +1130,7 @@ unsigned long sunxi_dram_init(void)
> .dx_dri = CONFIG_DRAM_SUN50I_H616_DX_DRI,
> .ca_dri = CONFIG_DRAM_SUN50I_H616_CA_DRI,
> .odt_en = CONFIG_DRAM_SUN50I_H616_ODT_EN,
> + .tpr0 = CONFIG_DRAM_SUN50I_H616_TPR0,
> .tpr10 = CONFIG_DRAM_SUN50I_H616_TPR10,
> .tpr11 = CONFIG_DRAM_SUN50I_H616_TPR11,
> .tpr12 = CONFIG_DRAM_SUN50I_H616_TPR12,
Re: [PATCH 6/8] sunxi: Make bit delay function in H616 DRAM code void
On Sun, 11 Dec 2022 17:32:11 +0100
Jernej Skrabec wrote:
> Mentioned function result is always true and result isn't checked
> anyway. Let's make it void.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> arch/arm/mach-sunxi/dram_sun50i_h616.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index bf5b4ddfb5c2..3b2ba168498c 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -572,7 +572,7 @@ static bool mctl_phy_write_training(struct dram_para
> *para)
> return result;
> }
>
> -static bool mctl_phy_bit_delay_compensation(struct dram_para *para)
> +static void mctl_phy_bit_delay_compensation(struct dram_para *para)
> {
> u32 *ptr;
> int i;
> @@ -683,8 +683,6 @@ static bool mctl_phy_bit_delay_compensation(struct
> dram_para *para)
>
> setbits_le32(SUNXI_DRAM_PHY0_BASE + 0x54, 0x80);
> }
> -
> - return true;
> }
>
> static bool mctl_phy_init(struct dram_para *para)
[PATCH v4 7/9] video: Use VIDEO_DAMAGE for VIDEO_COPY
CONFIG_VIDEO_COPY implemented a range based copying mechanism: If we print a single character, it will always copy the full range of bytes from the top left corner of the character to the lower right onto the uncached frame buffer. This includes pretty much the full line contents of the printed character. Since we now have proper damage tracking, let's make use of that to reduce the amount of data we need to copy. With this patch applied, we will only copy the tiny rectangle surrounding characters when we print them, speeding up the video console. As a bonus, we remove a lot of code. Signed-off-by: Alexander Graf --- v2 -> v3: - Rebase - Make CONFIG_COPY always select VIDEO_DAMAGE --- drivers/video/Kconfig | 5 ++ drivers/video/console_normal.c| 14 + drivers/video/console_rotate.c| 37 ++--- drivers/video/console_truetype.c | 17 +- drivers/video/vidconsole-uclass.c | 16 -- drivers/video/video-uclass.c | 91 --- drivers/video/video_bmp.c | 7 --- include/video.h | 37 - include/video_console.h | 49 - 9 files changed, 37 insertions(+), 236 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 826a1a6587..472e9c7c61 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -53,11 +53,14 @@ config VIDEO_PCI_DEFAULT_FB_SIZE config VIDEO_COPY bool "Enable copying the frame buffer to a hardware copy" + select VIDEO_DAMAGE help On some machines (e.g. x86), reading from the frame buffer is very slow because it is uncached. To improve performance, this feature allows the frame buffer to be kept in cached memory (allocated by U-Boot) and then copied to the hardware frame-buffer as needed. + It uses the VIDEO_DAMAGE feature to keep track of regions to copy + and will only copy actually touched regions. To use this, your video driver must set @copy_base in struct video_uc_plat. @@ -75,6 +78,8 @@ config VIDEO_DAMAGE regions of the frame buffer that were modified before, speeding up screen refreshes significantly. + It is also used by VIDEO_COPY to identify which regions changed. + config BACKLIGHT_PWM bool "Generic PWM based Backlight Driver" depends on BACKLIGHT && DM_PWM diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c index 5b5586fd3e..625d14516f 100644 --- a/drivers/video/console_normal.c +++ b/drivers/video/console_normal.c @@ -18,7 +18,6 @@ static int console_normal_set_row(struct udevice *dev, uint row, int clr) struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent); void *line, *end; int pixels = VIDEO_FONT_HEIGHT * vid_priv->xsize; - int ret; int i; line = vid_priv->fb + row * VIDEO_FONT_HEIGHT * vid_priv->line_length; @@ -53,9 +52,6 @@ static int console_normal_set_row(struct udevice *dev, uint row, int clr) default: return -ENOSYS; } - ret = vidconsole_sync_copy(dev, line, end); - if (ret) - return ret; video_damage(dev->parent, 0, VIDEO_FONT_HEIGHT * row, vid_priv->xsize, VIDEO_FONT_HEIGHT); @@ -70,14 +66,11 @@ static int console_normal_move_rows(struct udevice *dev, uint rowdst, void *dst; void *src; int size; - int ret; dst = vid_priv->fb + rowdst * VIDEO_FONT_HEIGHT * vid_priv->line_length; src = vid_priv->fb + rowsrc * VIDEO_FONT_HEIGHT * vid_priv->line_length; size = VIDEO_FONT_HEIGHT * vid_priv->line_length * count; - ret = vidconsole_memmove(dev, dst, src, size); - if (ret) - return ret; + memmove(dst, src, size); video_damage(dev->parent, 0, VIDEO_FONT_HEIGHT * rowdst, vid_priv->xsize, VIDEO_FONT_HEIGHT * count); @@ -94,7 +87,6 @@ static int console_normal_putc_xy(struct udevice *dev, uint x_frac, uint y, int i, row; void *start; void *line; - int ret; start = vid_priv->fb + y * vid_priv->line_length + VID_TO_PIXEL(x_frac) * VNBYTES(vid_priv->bpix); @@ -153,10 +145,6 @@ static int console_normal_putc_xy(struct udevice *dev, uint x_frac, uint y, video_damage(dev->parent, VID_TO_PIXEL(x_frac), y, VIDEO_FONT_WIDTH, VIDEO_FONT_HEIGHT); - ret = vidconsole_sync_copy(dev, start, line); - if (ret) - return ret; - return VID_TO_POS(VIDEO_FONT_WIDTH); } diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c index 56e20bb4f3..9b179a45b6 100644 --- a/drivers/video/console_rotate.c +++ b/drivers/video/console_rotate.c @@ -53,9 +53,6 @@ static int console_set_row_1(struct udevice *dev, uint row, int clr) } line
[PATCH v4 9/9] video: Enable VIDEO_DAMAGE for drivers that need it
Some drivers call video_set_flush_dcache() to indicate that they want to have the dcache flushed for the frame buffer. These drivers benefit from our new video damage control, because we can reduce the amount of memory that gets flushed significantly. This patch enables video damage control for all device drivers that call video_set_flush_dcache() to make sure they benefit from it. Signed-off-by: Alexander Graf --- arch/arm/mach-omap2/omap3/Kconfig | 1 + arch/arm/mach-sunxi/Kconfig | 1 + drivers/video/Kconfig | 9 + drivers/video/exynos/Kconfig | 1 + drivers/video/imx/Kconfig | 1 + drivers/video/meson/Kconfig | 1 + drivers/video/rockchip/Kconfig| 1 + drivers/video/stm32/Kconfig | 1 + 8 files changed, 16 insertions(+) diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig index 3e97ec2629..ea231f16a2 100644 --- a/arch/arm/mach-omap2/omap3/Kconfig +++ b/arch/arm/mach-omap2/omap3/Kconfig @@ -113,6 +113,7 @@ config TARGET_NOKIA_RX51 select CMDLINE_TAG select INITRD_TAG select REVISION_TAG + select VIDEO_DAMAGE config TARGET_TAO3530 bool "TAO3530" diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index dbe6005daa..373bf58731 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -790,6 +790,7 @@ config VIDEO_SUNXI depends on !SUN50I_GEN_H6 select VIDEO select DISPLAY + select VIDEO_DAMAGE imply VIDEO_DT_SIMPLEFB default y ---help--- diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 472e9c7c61..a186bd8525 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -436,6 +436,7 @@ config VIDEO_LCD_ANX9804 config ATMEL_LCD bool "Atmel LCD panel support" + select VIDEO_DAMAGE depends on ARCH_AT91 config ATMEL_LCD_BGR555 @@ -445,6 +446,7 @@ config ATMEL_LCD_BGR555 config VIDEO_BCM2835 bool "Display support for BCM2835" + select VIDEO_DAMAGE help The graphics processor already sets up the display so this driver simply checks the resolution and then sets up the frame buffer with @@ -554,6 +556,7 @@ source "drivers/video/meson/Kconfig" config VIDEO_MVEBU bool "Armada XP LCD controller" + select VIDEO_DAMAGE ---help--- Support for the LCD controller integrated in the Marvell Armada XP SoC. @@ -588,6 +591,7 @@ config NXP_TDA19988 config ATMEL_HLCD bool "Enable ATMEL video support using HLCDC" + select VIDEO_DAMAGE help HLCDC supports video output to an attached LCD panel. @@ -652,6 +656,7 @@ source "drivers/video/stm32/Kconfig" config VIDEO_TEGRA20 bool "Enable LCD support on Tegra20" depends on OF_CONTROL + select VIDEO_DAMAGE 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. @@ -660,6 +665,7 @@ config VIDEO_TEGRA20 config VIDEO_TEGRA124 bool "Enable video support on Tegra124" + select VIDEO_DAMAGE help Tegra124 supports many video output options including eDP and HDMI. At present only eDP is supported by U-Boot. This option @@ -672,6 +678,7 @@ source "drivers/video/imx/Kconfig" config VIDEO_MXS bool "Enable video support on i.MX28/i.MX6UL/i.MX7 SoCs" + select VIDEO_DAMAGE help Enable framebuffer driver for i.MX28/i.MX6UL/i.MX7 processors @@ -741,6 +748,7 @@ config VIDEO_DW_MIPI_DSI config VIDEO_SIMPLE bool "Simple display driver for preconfigured display" + select VIDEO_DAMAGE help Enables a simple generic display driver which utilizes the simple-framebuffer devicetree bindings. @@ -759,6 +767,7 @@ config VIDEO_DT_SIMPLEFB config VIDEO_MCDE_SIMPLE bool "Simple driver for ST-Ericsson MCDE with preconfigured display" + select VIDEO_DAMAGE help Enables a simple display driver for ST-Ericsson MCDE (Multichannel Display Engine), which reads the configuration from diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig index 599d19d5ec..66aa11661c 100644 --- a/drivers/video/exynos/Kconfig +++ b/drivers/video/exynos/Kconfig @@ -12,6 +12,7 @@ config EXYNOS_DP config EXYNOS_FB bool "Exynos FIMD support" + select VIDEO_DAMAGE config EXYNOS_MIPI_DSIM bool "Exynos MIPI DSI support" diff --git a/drivers/video/imx/Kconfig b/drivers/video/imx/Kconfig index 34e8b64059..50d8b05365 100644 --- a/drivers/video/imx/Kconfig +++ b/drivers/video/imx/Kconfig @@ -2,6 +2,7 @@ config VIDEO_IPUV3 bool "i.MX IPUv3 Core video support" depends on VIDEO && (MX5 || MX6) + select VIDEO_DAMAGE help This enables framebuffer driver for i.MX processors working
[PATCH v4 8/9] video: Always compile cache flushing code
The dcache flushing code path was conditional on ARM && !DCACHE config
options. However, dcaches exist on other platforms as well and may need
clearing if their driver requires it.
Simplify the compile logic and always enable the dcache flush logic in
the video core. That way, drivers can always rely on it to call the arch
specific callbacks.
This will increase code size for non-ARM platforms with CONFIG_VIDEO=y
slightly.
Reported-by: Heinrich Schuchardt
Signed-off-by: Alexander Graf
---
drivers/video/video-uclass.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 956863f98a..bad5eedc96 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -285,11 +285,13 @@ int video_damage(struct udevice *vid, int x, int y, int
width, int height)
return 0;
}
-#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
static void video_flush_dcache(struct udevice *vid)
{
struct video_priv *priv = dev_get_uclass_priv(vid);
+ if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
+ return;
+
if (!priv->flush_dcache)
return;
@@ -318,7 +320,6 @@ static void video_flush_dcache(struct udevice *vid)
}
}
}
-#endif
static void video_flush_copy(struct udevice *vid)
{
@@ -357,14 +358,9 @@ int video_sync(struct udevice *vid, bool force)
return ret;
}
- /*
-* flush_dcache_range() is declared in common.h but it seems that some
-* architectures do not actually implement it. Is there a way to find
-* out whether it exists? For now, ARM is safe.
-*/
-#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
video_flush_dcache(vid);
-#elif defined(CONFIG_VIDEO_SANDBOX_SDL)
+
+#if defined(CONFIG_VIDEO_SANDBOX_SDL)
static ulong last_sync;
if (force || get_timer(last_sync) > 100) {
--
2.37.1 (Apple Git-137.1)
[PATCH v4 6/9] video: Only dcache flush damaged lines
Now that we have a damage area tells us which parts of the frame buffer
actually need updating, let's only dcache flush those on video_sync()
calls. With this optimization in place, frame buffer updates - especially
on large screen such as 4k displays - speed up significantly.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Fix dcache range; we were flushing too much before
- Remove ifdefs
v3 -> v4:
- Simplify first damage logic
---
drivers/video/video-uclass.c | 45 +---
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 48fc29aeb0..37ab9f7ca4 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -289,9 +289,45 @@ int video_damage(struct udevice *vid, int x, int y, int
width, int height)
return 0;
}
+#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
+static void video_flush_dcache(struct udevice *vid)
+{
+ struct video_priv *priv = dev_get_uclass_priv(vid);
+
+ if (!priv->flush_dcache)
+ return;
+
+ if (!CONFIG_IS_ENABLED(VIDEO_DAMAGE)) {
+ flush_dcache_range((ulong)priv->fb,
+ ALIGN((ulong)priv->fb + priv->fb_size,
+CONFIG_SYS_CACHELINE_SIZE));
+
+ return;
+ }
+
+ if (priv->damage.endx > priv->damage.x) {
+ int lstart = priv->damage.x * VNBYTES(priv->bpix);
+ int lend = priv->damage.endx * VNBYTES(priv->bpix);
+ int y;
+
+ for (y = priv->damage.y; y < priv->damage.endy; y++) {
+ ulong fb = (ulong)priv->fb;
+ ulong start = fb + (y * priv->line_length) + lstart;
+ ulong end = start + lend - lstart;
+
+ start = ALIGN_DOWN(start, CONFIG_SYS_CACHELINE_SIZE);
+ end = ALIGN(end, CONFIG_SYS_CACHELINE_SIZE);
+
+ flush_dcache_range(start, end);
+ }
+ }
+}
+#endif
+
/* Flush video activity to the caches */
int video_sync(struct udevice *vid, bool force)
{
+ struct video_priv *priv = dev_get_uclass_priv(vid);
struct video_ops *ops = video_get_ops(vid);
int ret;
@@ -307,15 +343,8 @@ int video_sync(struct udevice *vid, bool force)
* out whether it exists? For now, ARM is safe.
*/
#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
- struct video_priv *priv = dev_get_uclass_priv(vid);
-
- if (priv->flush_dcache) {
- flush_dcache_range((ulong)priv->fb,
- ALIGN((ulong)priv->fb + priv->fb_size,
-CONFIG_SYS_CACHELINE_SIZE));
- }
+ video_flush_dcache(vid);
#elif defined(CONFIG_VIDEO_SANDBOX_SDL)
- struct video_priv *priv = dev_get_uclass_priv(vid);
static ulong last_sync;
if (force || get_timer(last_sync) > 100) {
--
2.37.1 (Apple Git-137.1)
[PATCH v4 4/9] video: Add damage notification on bmp display
Let's report the video damage when we draw a bitmap on the screen. This way we can later lazily flush only relevant regions to hardware. Signed-off-by: Alexander Graf Reported-by: Da Xue --- drivers/video/video_bmp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/video_bmp.c b/drivers/video/video_bmp.c index 6188a13e44..7dc5b011a8 100644 --- a/drivers/video/video_bmp.c +++ b/drivers/video/video_bmp.c @@ -424,6 +424,8 @@ int video_bmp_display(struct udevice *dev, ulong bmp_image, int x, int y, break; }; + video_damage(dev, x, y, width, height); + /* Find the position of the top left of the image in the framebuffer */ fb = (uchar *)(priv->fb + y * priv->line_length + x * bpix / 8); ret = video_sync_copy(dev, start, fb); -- 2.37.1 (Apple Git-137.1)
[PATCH v4 5/9] efi_loader: GOP: Add damage notification on BLT
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs from gop
v2 -> v3:
- Adapt to always assume DM is used
v3 -> v4:
- Skip damage on EfiBltVideoToBltBuffer
---
lib/efi_loader/efi_gop.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index d1dc2f22d0..425dcbf6b1 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -32,6 +32,7 @@ struct efi_gop_obj {
struct efi_gop ops;
struct efi_gop_mode_info info;
struct efi_gop_mode mode;
+ struct udevice *vdev;
/* Fields we only have access to during init */
u32 bpix;
void *fb;
@@ -120,6 +121,7 @@ static __always_inline efi_status_t gop_blt_int(struct
efi_gop *this,
u32 *fb32 = gopobj->fb;
u16 *fb16 = gopobj->fb;
struct efi_gop_pixel *buffer = __builtin_assume_aligned(bufferp, 4);
+ bool blt_to_video = (operation != EFI_BLT_VIDEO_TO_BLT_BUFFER);
if (delta) {
/* Check for 4 byte alignment */
@@ -243,6 +245,9 @@ static __always_inline efi_status_t gop_blt_int(struct
efi_gop *this,
dlineoff += dwidth;
}
+ if (blt_to_video)
+ video_damage(gopobj->vdev, dx, dy, width, height);
+
return EFI_SUCCESS;
}
@@ -547,6 +552,7 @@ efi_status_t efi_gop_register(void)
gopobj->info.pixels_per_scanline = col;
gopobj->bpix = bpix;
gopobj->fb = fb;
+ gopobj->vdev = vdev;
return EFI_SUCCESS;
}
--
2.37.1 (Apple Git-137.1)
[PATCH v4 3/9] vidconsole: Add damage notifications to all vidconsole drivers
Now that we have a damage tracking API, let's populate damage done by vidconsole drivers. We try to declare as little memory as damaged as possible, with the exception of rotated screens that I couldn't get my head wrapped around. On those, we revert to the old behavior and mark the full screen as damaged on every update. Signed-off-by: Alexander Graf Reported-by: Da Xue --- v1 -> v2: - Fix ranges in truetype target - Limit rotate to necessary damange --- drivers/video/console_normal.c | 10 ++ drivers/video/console_rotate.c | 54 drivers/video/console_truetype.c | 15 + 3 files changed, 79 insertions(+) diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c index 04f022491e..5b5586fd3e 100644 --- a/drivers/video/console_normal.c +++ b/drivers/video/console_normal.c @@ -57,6 +57,9 @@ static int console_normal_set_row(struct udevice *dev, uint row, int clr) if (ret) return ret; + video_damage(dev->parent, 0, VIDEO_FONT_HEIGHT * row, vid_priv->xsize, +VIDEO_FONT_HEIGHT); + return 0; } @@ -76,6 +79,9 @@ static int console_normal_move_rows(struct udevice *dev, uint rowdst, if (ret) return ret; + video_damage(dev->parent, 0, VIDEO_FONT_HEIGHT * rowdst, vid_priv->xsize, +VIDEO_FONT_HEIGHT * count); + return 0; } @@ -143,6 +149,10 @@ static int console_normal_putc_xy(struct udevice *dev, uint x_frac, uint y, } line += vid_priv->line_length; } + + video_damage(dev->parent, VID_TO_PIXEL(x_frac), y, VIDEO_FONT_WIDTH, +VIDEO_FONT_HEIGHT); + ret = vidconsole_sync_copy(dev, start, line); if (ret) return ret; diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c index 36c8d0609d..56e20bb4f3 100644 --- a/drivers/video/console_rotate.c +++ b/drivers/video/console_rotate.c @@ -57,6 +57,12 @@ static int console_set_row_1(struct udevice *dev, uint row, int clr) if (ret) return ret; + video_damage(dev->parent, +vid_priv->xsize - ((row + 1) * VIDEO_FONT_HEIGHT), +0, +VIDEO_FONT_HEIGHT, +vid_priv->ysize); + return 0; } @@ -83,6 +89,12 @@ static int console_move_rows_1(struct udevice *dev, uint rowdst, uint rowsrc, dst += vid_priv->line_length; } + video_damage(dev->parent, +vid_priv->xsize - ((rowdst + count) * VIDEO_FONT_HEIGHT), +0, +count * VIDEO_FONT_HEIGHT, +vid_priv->ysize); + return 0; } @@ -150,6 +162,12 @@ static int console_putc_xy_1(struct udevice *dev, uint x_frac, uint y, char ch) if (ret) return ret; + video_damage(dev->parent, +vid_priv->xsize - y - VIDEO_FONT_HEIGHT - 1, +linenum - 1, +VIDEO_FONT_HEIGHT, +VIDEO_FONT_WIDTH); + return VID_TO_POS(VIDEO_FONT_WIDTH); } @@ -199,6 +217,12 @@ static int console_set_row_2(struct udevice *dev, uint row, int clr) if (ret) return ret; + video_damage(dev->parent, +0, +vid_priv->ysize - (row + 1) * VIDEO_FONT_HEIGHT, +vid_priv->xsize, +VIDEO_FONT_HEIGHT); + return 0; } @@ -218,6 +242,12 @@ static int console_move_rows_2(struct udevice *dev, uint rowdst, uint rowsrc, vidconsole_memmove(dev, dst, src, VIDEO_FONT_HEIGHT * vid_priv->line_length * count); + video_damage(dev->parent, +0, +vid_priv->ysize - (rowdst + count) * VIDEO_FONT_HEIGHT, +vid_priv->xsize, +count * VIDEO_FONT_HEIGHT); + return 0; } @@ -288,6 +318,12 @@ static int console_putc_xy_2(struct udevice *dev, uint x_frac, uint y, char ch) if (ret) return ret; + video_damage(dev->parent, +x - VIDEO_FONT_WIDTH, +linenum - VIDEO_FONT_HEIGHT + 1, +VIDEO_FONT_WIDTH, +VIDEO_FONT_HEIGHT); + return VID_TO_POS(VIDEO_FONT_WIDTH); } @@ -335,6 +371,12 @@ static int console_set_row_3(struct udevice *dev, uint row, int clr) if (ret) return ret; + video_damage(dev->parent, +row * VIDEO_FONT_HEIGHT, +0, +VIDEO_FONT_HEIGHT, +vid_priv->ysize); + return 0; } @@ -359,6 +401,12 @@ static int console_move_rows_3(struct udevice *dev, uint rowdst, uint rowsrc, dst += vid_priv->line_length; } + video_damage(dev->parent,
[PATCH v4 1/9] dm: video: Add damage tracking API
We are going to introduce image damage tracking to fasten up screen
refresh on large displays. This patch adds damage tracking for up to
one rectangle of the screen which is typically enough to hold blt or
text print updates. Callers into this API and a reduced dcache flush
code path will follow in later patches.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs
v2 -> v3:
- Adapt Kconfig to DM always
v3 -> v4:
- Move damage clear from patch 6 to this one
- Simplify first damage logic
- Remove VIDEO_DAMAGE default for ARM
---
drivers/video/Kconfig| 13
drivers/video/video-uclass.c | 41
include/video.h | 29 +++--
3 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index f539977d9b..826a1a6587 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -62,6 +62,19 @@ config VIDEO_COPY
To use this, your video driver must set @copy_base in
struct video_uc_plat.
+config VIDEO_DAMAGE
+ bool "Enable damage tracking of frame buffer regions"
+ help
+ On some machines (most ARM), the display frame buffer resides in
+ RAM. To make the display controller pick up screen updates, we
+ have to flush frame buffer contents from CPU caches into RAM which
+ can be a slow operation.
+
+ This feature adds damage tracking to collect information about regions
+ that received updates. When we want to sync, we then only flush
+ regions of the frame buffer that were modified before, speeding up
+ screen refreshes significantly.
+
config BACKLIGHT_PWM
bool "Generic PWM based Backlight Driver"
depends on BACKLIGHT && DM_PWM
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 0ce376ca3f..d18c8cd2b1 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#ifdef CONFIG_SANDBOX
#include
#endif
@@ -254,6 +256,37 @@ void video_set_default_colors(struct udevice *dev, bool
invert)
priv->colour_bg = video_index_to_colour(priv, back);
}
+/* Notify about changes in the frame buffer */
+int video_damage(struct udevice *vid, int x, int y, int width, int height)
+{
+ struct video_priv *priv = dev_get_uclass_priv(vid);
+ int endx = x + width;
+ int endy = y + height;
+
+ if (!CONFIG_IS_ENABLED(VIDEO_DAMAGE))
+ return 0;
+
+ if (x > priv->xsize)
+ return 0;
+
+ if (y > priv->ysize)
+ return 0;
+
+ if (endx > priv->xsize)
+ endx = priv->xsize;
+
+ if (endy > priv->ysize)
+ endy = priv->ysize;
+
+ /* Span a rectangle across all old and new damage */
+ priv->damage.x = min(x, priv->damage.x);
+ priv->damage.y = min(y, priv->damage.y);
+ priv->damage.endx = max(endx, priv->damage.endx);
+ priv->damage.endy = max(endy, priv->damage.endy);
+
+ return 0;
+}
+
/* Flush video activity to the caches */
int video_sync(struct udevice *vid, bool force)
{
@@ -288,6 +321,14 @@ int video_sync(struct udevice *vid, bool force)
last_sync = get_timer(0);
}
#endif
+
+ if (CONFIG_IS_ENABLED(VIDEO_DAMAGE)) {
+ priv->damage.x = priv->xsize;
+ priv->damage.y = priv->ysize;
+ priv->damage.endx = 0;
+ priv->damage.endy = 0;
+ }
+
return 0;
}
diff --git a/include/video.h b/include/video.h
index 43f2e2c02f..4b35e97f79 100644
--- a/include/video.h
+++ b/include/video.h
@@ -109,6 +109,12 @@ struct video_priv {
void *fb;
int fb_size;
void *copy_fb;
+ struct {
+ int x;
+ int y;
+ int endx;
+ int endy;
+ } damage;
int line_length;
u32 colour_fg;
u32 colour_bg;
@@ -211,8 +217,9 @@ int video_fill(struct udevice *dev, u32 colour);
* @return: 0 on success, error code otherwise
*
* Some frame buffers are cached or have a secondary frame buffer. This
- * function syncs these up so that the current contents of the U-Boot frame
- * buffer are displayed to the user.
+ * function syncs the damaged parts of them up so that the current contents
+ * of the U-Boot frame buffer are displayed to the user. It clears the damage
+ * buffer.
*/
int video_sync(struct udevice *vid, bool force);
@@ -332,6 +339,24 @@ static inline int video_sync_copy_all(struct udevice *dev)
#endif
+/**
+ * video_damage() - Notify the video subsystem about screen updates.
+ *
+ * @vid: Device to sync
+ * @x: Upper left X coordinate of the damaged rectangle
+ * @y: Upper left Y coordinate of the damaged rectangle
+ * @width: Width of the damaged rectangle
+ *
[PATCH v4 2/9] dm: video: Add damage notification on display clear
Let's report the video damage when we clear the screen. This way we can later lazily flush only relevant regions to hardware. Signed-off-by: Alexander Graf Reported-by: Da Xue --- drivers/video/video-uclass.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c index d18c8cd2b1..48fc29aeb0 100644 --- a/drivers/video/video-uclass.c +++ b/drivers/video/video-uclass.c @@ -160,6 +160,8 @@ int video_fill(struct udevice *dev, u32 colour) if (ret) return ret; + video_damage(dev, 0, 0, priv->xsize, priv->ysize); + return video_sync(dev, false); } -- 2.37.1 (Apple Git-137.1)
[PATCH v4 0/9] Add video damage tracking
This patch set speeds up graphics output on ARM by a factor of 60x. On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached, but need it accessible by the display controller which reads directly from a later point of consistency. Hence, we flush the frame buffer to DRAM on every change. The full frame buffer. Unfortunately, with the advent of 4k displays, we are seeing frame buffers that can take a while to flush out. This was reported by Da Xue with grub, which happily print 1000s of spaces on the screen to draw a menu. Every printed space triggers a cache flush. This patch set implements the easiest mitigation against this problem: Damage tracking. We remember the lowest common denominator region that was touched since the last video_sync() call and only flush that. The most typical writer to the frame buffer is the video console, which always writes rectangles of characters on the screen and syncs afterwards. With this patch set applied, we reduce drawing a large grub menu (with serial console attached for size information) on an RK3399-ROC system at 1440p from 55 seconds to less than 1 second. Version 2 also implements VIDEO_COPY using this mechanism, reducing its overhead compared to before as well. So even x86 systems should be faster with this now :). Alternatives considered: 1) Lazy sync - Sandbox does this. It only calls video_sync(true) ever so often. We are missing timers to do this generically. 2) Double buffering - We could try to identify whether anything changed at all and only draw to the FB if it did. That would require maintaining a second buffer that we need to scan. 3) Text buffer - Maintain a buffer of all text printed on the screen with respective location. Don't write if the old and new character are identical. This would limit applicability to text only and is an optimization on top of this patch set. 4) Hash screen lines - Create a hash (sha256?) over every line when it changes. Only flush when it does. I'm not sure if this would waste more time, memory and cache than the current approach. It would make full screen updates much more expensive. v1 -> v2: - new patch: video: Use VIDEO_DAMAGE for VIDEO_COPY - Remove ifdefs - Fix dcache range; we were flushing too much before - Fix ranges in truetype target - Limit rotate to necessary damange v2 -> v3: - Rebase - Adapt to DM_VIDEO always - Make CONFIG_COPY always select VIDEO_DAMAGE v3 -> v4: - New patch: video: Always compile cache flushing code - New patch: video: Enable VIDEO_DAMAGE for drivers that need it - Simplify first damage logic - Skip damage on EfiBltVideoToBltBuffer - Move damage clear from patch 6 to patch 1 - Remove VIDEO_DAMAGE default for ARM Alexander Graf (9): dm: video: Add damage tracking API dm: video: Add damage notification on display clear vidconsole: Add damage notifications to all vidconsole drivers video: Add damage notification on bmp display efi_loader: GOP: Add damage notification on BLT video: Only dcache flush damaged lines video: Use VIDEO_DAMAGE for VIDEO_COPY video: Always compile cache flushing code video: Enable VIDEO_DAMAGE for drivers that need it arch/arm/mach-omap2/omap3/Kconfig | 1 + arch/arm/mach-sunxi/Kconfig | 1 + drivers/video/Kconfig | 27 + drivers/video/console_normal.c| 22 ++-- drivers/video/console_rotate.c| 87 +- drivers/video/console_truetype.c | 30 ++--- drivers/video/exynos/Kconfig | 1 + drivers/video/imx/Kconfig | 1 + drivers/video/meson/Kconfig | 1 + drivers/video/rockchip/Kconfig| 1 + drivers/video/stm32/Kconfig | 1 + drivers/video/vidconsole-uclass.c | 16 --- drivers/video/video-uclass.c | 187 +- drivers/video/video_bmp.c | 7 +- include/video.h | 54 - include/video_console.h | 49 lib/efi_loader/efi_gop.c | 6 + 17 files changed, 251 insertions(+), 241 deletions(-) -- 2.37.1 (Apple Git-137.1)
[PATCH 0/3] tpm: Support boot measurements
This series adds support for measuring the boot images more generically than the existing EFI support. The series includes optional measurement from the bootm command. Eventually the EFI code could be refactored to use the generic functions. Eddie James (3): tpm: Fix spelling for tpmu_ha union tpm: Support boot measurements bootm: Support boot measurement boot/bootm.c | 53 cmd/bootm.c| 2 + common/Kconfig | 6 + include/efi_tcg2.h | 44 --- include/image.h| 1 + include/tpm-v2.h | 139 - lib/tpm-v2.c | 700 + 7 files changed, 899 insertions(+), 46 deletions(-) -- 2.31.1
[PATCH 3/3] bootm: Support boot measurement
Add a configuration option to measure the boot through the bootm
function.
Signed-off-by: Eddie James
---
boot/bootm.c| 53 +
cmd/bootm.c | 2 ++
common/Kconfig | 6 ++
include/image.h | 1 +
4 files changed, 62 insertions(+)
diff --git a/boot/bootm.c b/boot/bootm.c
index a4c0870c0f..7f64d79035 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,9 @@
#include
#include
#include
+#if defined(CONFIG_MEASURED_BOOT)
+#include
+#endif
#if defined(CONFIG_CMD_USB)
#include
#endif
@@ -713,6 +716,56 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int
argc,
if (!ret && (states & BOOTM_STATE_FINDOTHER))
ret = bootm_find_other(cmdtp, flag, argc, argv);
+#if defined(CONFIG_MEASURED_BOOT)
+ if (!ret && (states & BOOTM_STATE_MEASURE)) {
+ void *initrd_buf;
+ void *image_buf;
+ const char *s;
+ u32 rd_len;
+
+ ret = tcg2_measurement_init();
+ if (ret)
+ goto measure_err;
+
+ image_buf = map_sysmem(images->os.image_start,
+ images->os.image_len);
+ ret = tcg2_measure_data(8, images->os.image_len, image_buf,
+ EV_COMPACT_HASH, strlen("linux") + 1,
+ (u8 *)"linux");
+ if (ret)
+ goto unmap_image;
+
+ rd_len = images->rd_end - images->rd_start;
+ initrd_buf = map_sysmem(images->rd_start, rd_len);
+ ret = tcg2_measure_data(8, rd_len, initrd_buf, EV_COMPACT_HASH,
+ strlen("initrd") + 1, (u8 *)"initrd");
+ if (ret)
+ goto unmap_initrd;
+
+ ret = tcg2_measure_data(9, images->ft_len,
+ (u8 *)images->ft_addr,
+ EV_TABLE_OF_DEVICES, strlen("dts") + 1,
+ (u8 *)"dts");
+ if (ret)
+ goto unmap_initrd;
+
+ s = env_get("bootargs");
+ if (!s)
+ s = "";
+ tcg2_measure_data(1, strlen(s) + 1, (u8 *)s,
+ EV_PLATFORM_CONFIG_FLAGS, strlen(s) + 1,
+ (u8 *)s);
+
+unmap_initrd:
+ unmap_sysmem(initrd_buf);
+unmap_image:
+ unmap_sysmem(image_buf);
+ tcg2_measurement_term();
+measure_err:
+ ret = 0;
+ }
+#endif
+
/* Load the OS */
if (!ret && (states & BOOTM_STATE_LOADOS)) {
iflag = bootm_disable_interrupts();
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 37c2af96e0..0c4a713e02 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -161,6 +161,8 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
BOOTM_STATE_OS_GO;
if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
states |= BOOTM_STATE_RAMDISK;
+ if (IS_ENABLED(CONFIG_MEASURED_BOOT))
+ states |= BOOTM_STATE_MEASURE;
if (IS_ENABLED(CONFIG_PPC) || IS_ENABLED(CONFIG_MIPS))
states |= BOOTM_STATE_OS_CMDLINE;
ret = do_bootm_states(cmdtp, flag, argc, argv, states, , 1);
diff --git a/common/Kconfig b/common/Kconfig
index 21434c5cf1..57ef68e4f3 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -799,6 +799,12 @@ config AVB_BUF_SIZE
endif # AVB_VERIFY
+config MEASURED_BOOT
+ bool "Measure the boot to TPM and event log"
+ depends on HASH && TPM_V2
+ help
+ This option enables measurement of the boot process.
+
config SCP03
bool "Build SCP03 - Secure Channel Protocol O3 - controls"
depends on OPTEE || SANDBOX
diff --git a/include/image.h b/include/image.h
index 6f21dafba8..b00803eeac 100644
--- a/include/image.h
+++ b/include/image.h
@@ -406,6 +406,7 @@ struct bootm_headers {
#define BOOTM_STATE_OS_FAKE_GO 0x0200 /* 'Almost' run the OS */
#define BOOTM_STATE_OS_GO 0x0400
#define BOOTM_STATE_PRE_LOAD 0x0800
+#define BOOTM_STATE_MEASURE0x1000
int state;
#if defined(CONFIG_LMB) && !defined(USE_HOSTCC)
--
2.31.1
[PATCH 2/3] tpm: Support boot measurements
Add TPM2 functions to support boot measurement. This includes
starting up the TPM, initializing/appending the event log, and
measuring the U-Boot version.
Signed-off-by: Eddie James
---
include/efi_tcg2.h | 44 ---
include/tpm-v2.h | 135 +
lib/tpm-v2.c | 700 +
3 files changed, 835 insertions(+), 44 deletions(-)
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 874306dc11..23016773f4 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -129,50 +129,6 @@ struct efi_tcg2_boot_service_capability {
#define BOOT_SERVICE_CAPABILITY_MIN \
offsetof(struct efi_tcg2_boot_service_capability, number_of_pcr_banks)
-#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
-#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
-
-/**
- * struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
- *
- * @algorithm_id: algorithm defined in enum tpm2_algorithms
- * @digest_size: size of the algorithm
- */
-struct tcg_efi_spec_id_event_algorithm_size {
- u16 algorithm_id;
- u16 digest_size;
-} __packed;
-
-/**
- * struct TCG_EfiSpecIDEventStruct - content of the event log header
- *
- * @signature: signature, set to Spec ID Event03
- * @platform_class:class defined in TCG ACPI Specification
- * Client Common Header.
- * @spec_version_minor:minor version
- * @spec_version_major:major version
- * @spec_version_errata: major version
- * @uintn_size:size of the efi_uintn_t fields used in
various
- * data structures used in this specification.
- * 0x01 indicates u32 and 0x02 indicates u64
- * @number_of_algorithms: hashing algorithms used in this event log
- * @digest_sizes: array of number_of_algorithms pairs
- * 1st member defines the algorithm id
- * 2nd member defines the algorithm size
- */
-struct tcg_efi_spec_id_event {
- u8 signature[16];
- u32 platform_class;
- u8 spec_version_minor;
- u8 spec_version_major;
- u8 spec_errata;
- u8 uintn_size;
- u32 number_of_algorithms;
- struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
-} __packed;
-
/**
* struct tdEFI_TCG2_FINAL_EVENTS_TABLE - log entries after Get Event Log
* @version: version number for this structure
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 85feda3e06..62a245e9d9 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -214,6 +214,50 @@ struct tcg_pcr_event2 {
u8 event[];
} __packed;
+/**
+ * struct TCG_EfiSpecIdEventAlgorithmSize - hashing algorithm information
+ *
+ * @algorithm_id: algorithm defined in enum tpm2_algorithms
+ * @digest_size: size of the algorithm
+ */
+struct tcg_efi_spec_id_event_algorithm_size {
+ u16 algorithm_id;
+ u16 digest_size;
+} __packed;
+
+#define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
+#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MAJOR_TPM2 2
+#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_MINOR_TPM2 0
+#define TCG_EFI_SPEC_ID_EVENT_SPEC_VERSION_ERRATA_TPM2 2
+
+/**
+ * struct TCG_EfiSpecIDEventStruct - content of the event log header
+ *
+ * @signature: signature, set to Spec ID Event03
+ * @platform_class:class defined in TCG ACPI Specification
+ * Client Common Header.
+ * @spec_version_minor:minor version
+ * @spec_version_major:major version
+ * @spec_version_errata: major version
+ * @uintn_size:size of the efi_uintn_t fields used in
various
+ * data structures used in this specification.
+ * 0x01 indicates u32 and 0x02 indicates u64
+ * @number_of_algorithms: hashing algorithms used in this event log
+ * @digest_sizes: array of number_of_algorithms pairs
+ * 1st member defines the algorithm id
+ * 2nd member defines the algorithm size
+ */
+struct tcg_efi_spec_id_event {
+ u8 signature[16];
+ u32 platform_class;
+ u8 spec_version_minor;
+ u8 spec_version_major;
+ u8 spec_errata;
+ u8 uintn_size;
+ u32 number_of_algorithms;
+ struct tcg_efi_spec_id_event_algorithm_size digest_sizes[];
+} __packed;
+
/**
* TPM2 Structure Tags for command/response buffers.
*
@@ -340,6 +384,24 @@ enum tpm2_algorithms {
TPM2_ALG_SM3_256= 0x12,
};
+static inline u16 tpm2_algorithm_to_len(enum tpm2_algorithms a)
+{
+ switch (a) {
+ case TPM2_ALG_SHA1:
+ return
[PATCH 1/3] tpm: Fix spelling for tpmu_ha union
tmpu -> tpmu
Signed-off-by: Eddie James
---
include/tpm-v2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 737e57551d..85feda3e06 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -167,7 +167,7 @@ struct tcg_pcr_event {
/**
* Definition of TPMU_HA Union
*/
-union tmpu_ha {
+union tpmu_ha {
u8 sha1[TPM2_SHA1_DIGEST_SIZE];
u8 sha256[TPM2_SHA256_DIGEST_SIZE];
u8 sm3_256[TPM2_SM3_256_DIGEST_SIZE];
@@ -183,7 +183,7 @@ union tmpu_ha {
*/
struct tpmt_ha {
u16 hash_alg;
- union tmpu_ha digest;
+ union tpmu_ha digest;
} __packed;
/**
--
2.31.1
Re: [PATCH] fastboot: remove #ifdef CONFIG when it is possible
On Thu, Dec 15, 2022 at 10:15:50AM +0100, Patrick Delaunay wrote:
> Much of the fastboot code predates the introduction of Kconfig and
> has quite a few #ifdefs in it which is unnecessary now that we can use
> IS_ENABLED() et al.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> cmd/fastboot.c | 35 +--
> drivers/fastboot/fb_command.c | 104
> drivers/fastboot/fb_common.c| 11 ++--
> drivers/fastboot/fb_getvar.c| 49 ++-
> drivers/usb/gadget/f_fastboot.c | 7 +--
> include/fastboot.h | 13
> net/fastboot.c | 8 +--
> 7 files changed, 82 insertions(+), 145 deletions(-)
>
> diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> index b498e4b22bb3..b94dbd548843 100644
> --- a/cmd/fastboot.c
> +++ b/cmd/fastboot.c
> @@ -19,8 +19,14 @@
> static int do_fastboot_udp(int argc, char *const argv[],
> uintptr_t buf_addr, size_t buf_size)
> {
> -#if CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)
> - int err = net_loop(FASTBOOT);
> + int err;
> +
> + if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) {
> + pr_err("Fastboot UDP not enabled\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + err = net_loop(FASTBOOT);
>
> if (err < 0) {
> printf("fastboot udp error: %d\n", err);
> @@ -28,21 +34,21 @@ static int do_fastboot_udp(int argc, char *const argv[],
> }
>
> return CMD_RET_SUCCESS;
> -#else
> - pr_err("Fastboot UDP not enabled\n");
> - return CMD_RET_FAILURE;
> -#endif
> }
This probably needs to become an if (CONFIG_IS_ENABLED(...)) { ... }
else { ... } in order to remain size-neutral.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 6/7] video: Only dcache flush damaged lines
On 30.12.22 22:12, Heinrich Schuchardt wrote: On 12/30/22 20:58, Alexander Graf wrote: Now that we have a damage area tells us which parts of the frame buffer actually need updating, let's only dcache flush those on video_sync() calls. With this optimization in place, frame buffer updates - especially on large screen such as 4k displays - speed up significantly. Signed-off-by: Alexander Graf Reported-by: Da Xue --- v1 -> v2: - Fix dcache range; we were flushing too much before - Remove ifdefs --- drivers/video/video-uclass.c | 51 ++-- 1 file changed, 43 insertions(+), 8 deletions(-) diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c index f1fbeaadcb..bf93f524c7 100644 --- a/drivers/video/video-uclass.c +++ b/drivers/video/video-uclass.c @@ -297,9 +297,45 @@ int video_damage(struct udevice *vid, int x, int y, int width, int height) return 0; } +#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) ARM isn't the only architecture implementing flush_dcache_range(). So this condition needs to be fixed as well as the one in video_sync. Why don't you simply rely on priv->flash_dcache irrespective of the architecture? Let the video drivers decide if they need it. This is code that already was #ifdef'ed before. The way I understand its history, we couldn't decisively ensure that flush_dcache_range() exists, so we couldn't build the code always. I agree that it looks weird and error prone though. I believe you're trying to say we should just make sure there's always a flush_dcache_range() function and keep the rest to the compiler? Alex
Re: [PATCH v5 3/3] arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export
On Sat, Dec 24, 2022 at 6:04 AM Paul Barker wrote:
>
> On 20/12/2022 15:55, Rob Herring wrote:
> > On Wed, Nov 23, 2022 at 05:50:06PM +, Paul Barker wrote:
> >> Add properties to the Authenta SPI flash device node to enable access by
> >> a UEFI application using a fixed GUID.
> >>
> >> Signed-off-by: Paul Barker
> >> ---
> >> arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi | 13 ++---
> >> arch/arm/dts/am335x-sancloud-bbe-lite.dts | 2 +-
> >> 2 files changed, 11 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> >> b/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> >> index 01c105ebb383..6c4ff67f9a4b 100644
> >> --- a/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> >> +++ b/arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi
> >> @@ -38,7 +38,14 @@
> >>
> >> {
> >> u-boot,dm-pre-reloc;
> >> -channel@0 {
> >> -u-boot,dm-pre-reloc;
> >> -};
> >> +};
> >> +
> >> +_flash {
> >> +u-boot,dm-pre-reloc;
> >> +
> >> +u-boot,uefi-spi-vendor = "micron";
> >> +u-boot,uefi-spi-part-number = "mt25ql128abb";
> >
> > Looks like a compatible string. Yet, the flash node compatible string,
> > micron,spi-authenta, is not documented (though in use for spidev). So
> > use a compatible string for the flash that is specific to the flash
> > model. I assume there is some reason the specific model is needed?
>
> For context, the UEFI Platform Initialization (PI) spec defines
> EFI_SPI_PART, EFI_SPI_PERIPHERAL and EFI_SPI_IO_PROTOCOL structures.
> I'm referencing v1.7 Errata A. See https://uefi.org/specifications for
> downloads.
>
> The EFI_SPI_PART structure has "Vendor" and "PartNumber" fields. We need
> something to put in those fields and the device tree is the best place
> to store the data. These properties are in the `-u-boot.dtsi` file so
> they won't be submitted to the Linux kernel.
Can't you just split the `micron,mt25ql128abb` compatible string to
populate those?
> The `micron,spi-authenta` compatible string is unfortunate in my
> opinion. I plan to replace this with two entries, `micron,mt25ql128abb`
> and `jedec,spi-nor`, once we've got MTD support for the Authenta parts
> merged into the mainline kernel. That work is currently on hold, I'll
> be working with Micron in the new year to unblock it. We could submit
> a change to the compatible property in the meantime if you think it's
> worth getting a temporary improvement in before the MTD changes are
> done.
No need to wait on driver changes to add compatible strings. Anyone
that says otherwise is wrong.
Looking at the datasheet, maybe `micron,mt25ql128abb` is too specific.
Perhaps 'abb' or just the last 'b' can be dropped? It's a trade off of
lots of compatible strings vs. whether you might need to distinguish
the parts (only before you do jedec discovery).
>
> >> +/* GUID in UEFI format: 77126730-a4ca-4386-b341-881fe18e7f7d */
> >> +u-boot,uefi-spi-io-guid = [30 67 12 77 ca a4 86 43
> >> + b3 41 88 1f e1 8e 7f 7d];
> >
> > We need to define first in the DT spec the format for GUIDs. I don't
> > think there are any existing cases though some have been proposed. IMO,
> > I would make this a string instead. The byte array is not that
> > readable with its little endian order. A GUID as a string is readily
> > identifiable as a GUID.
>
> I see there is a `uuid_str_to_bin()` function in u-boot so I could make
> this a string property and convert it to a binary GUID at runtime. This
> would make the dts more readable so I'll make the change for v6 of this
> series.
>
> > Why is this u-boot specific? Another UEFI implementation doesn't need
> > the GUID?
>
> Each EFI_SPI_IO_PROTOCOL instance needs its own GUID so that it can
> be located at runtime. These GUIDs are not pre-defined by the spec,
> instead an arbitrary per-device GUID is used and is stored in the
> SpiPeripheralDriverGuid field of the relevant EFI_SPI_PERIPHERAL
> instance. We could randomly generate these GUIDs at runtime since a UEFI
> application can walk the tree of SPI busses and peripherals, looking
> for a match in the Vendor and PartNumber fields defined above, to get
> the appropriate GUID. However, storing a known value in the device tree
> allows a UEFI application to just lookup the GUID without needing to
> walk the SPI tree.
Okay, then I guess my next question is why is it SPI IO protocol
specific? I'd assume the UEFI spec would use this for any h/w
protocol.
Generating GUIDs at runtime seems like the right way though. We simply
can't populate DT with every client's method of identifying a given
instance. That simply doesn't scale.
Rob
[PATCH] i2c: mxc_i2c: Use hex notation for the base address
Printing the I2C controller base address in decimal notation
is not helpful.
Change it to hex notation, which is the standard format found
in the Reference Manual and devicetree.
Signed-off-by: Fabio Estevam
---
drivers/i2c/mxc_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index f80ff5383b..9dd349d056 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -938,7 +938,7 @@ static int mxc_i2c_probe(struct udevice *bus)
* we can set pinmux here in probe function.
*/
- debug("i2c : controller bus %d at %lu , speed %d: ",
+ debug("i2c : controller bus %d at 0x%lx , speed %d: ",
dev_seq(bus), i2c_bus->base,
i2c_bus->speed);
--
2.25.1
Re: [PATCH 2/2] doc: ti: add the K3 generation page
On 12/19/22 2:29 PM, Bryan Brattlof wrote: Texas Instrument's entire K3 generation of SoCs use much of the same frameworks and boot flow, especially at the uboot level. Though there are small differences introduced as each new K3 based SoC is developed and as the K3 generation matures that will also need to be documented. Rather than copying the same documentation, with the small differences applicable to that specific SoC to a new page, introduce a new K3 page that can describe the general boot flow and design decisions for the entire K3 generation of chips, leaving the specifics for that particular SoC to a unique sub-page below this one. Signed-off-by: Bryan Brattlof --- doc/board/ti/index.rst | 5 +- doc/board/ti/k3.rst| 276 + 2 files changed, 278 insertions(+), 3 deletions(-) create mode 100644 doc/board/ti/k3.rst diff --git a/doc/board/ti/index.rst b/doc/board/ti/index.rst index 250d9242e82bb..89d537d195196 100644 --- a/doc/board/ti/index.rst +++ b/doc/board/ti/index.rst @@ -1,11 +1,10 @@ .. SPDX-License-Identifier: GPL-2.0+ Texas Instruments -= +# .. toctree:: :maxdepth: 2 am335x_evm - j721e_evm - am62x_sk + k3 diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst new file mode 100644 index 0..941dde931 --- /dev/null +++ b/doc/board/ti/k3.rst @@ -0,0 +1,276 @@ +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +.. sectionauthor:: Bryan Brattlof + +K3 Generation += + +Summary +--- + +Texas Instrument's K3 family of SoCs utilize a heterogeneous multicore +and highly integrated device architecture targeted to maximize +performance and power efficiency for a wide range of industrial, +automotive and other broad market segments. + +Typically the processing cores and the peripherals for these devices are +partitioned into three functional domains to provide ultra-low power +modes as well as accommodating application and industrial safety systems +on the same SoC. These functional domains are typically called the: + +* Wakeup (WKUP) domain +* Micro-controller (MCU) domain +* Main domain + +For a more detailed view of what peripherals are attached to each +domain, consult the device specific documentation. + +K3 Based SoCs +- + +.. toctree:: + :maxdepth: 1 + + j721e_evm + am62x_sk + +Boot Flow Overview +-- + +For all K3 SoCs the first core started will be inside the Security +Management Subsystem (SMS) which will secure the device and start a core This name (SMS, DMSC, HSM) changes over the K3 devices, how about just "Security Enclave". +in the wakeup domain to run the ROM code. ROM will then initialize the Not always in the wakeup domain either.. Also what "ROM code", the "Security Enclave" also has ROM code, should refer to this second ROM as "Public ROM". +boot media needed to load the binaries packaged inside `tiboot3.bin`, +including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump Does anyone call it "wakeup SPL"? I'd call it R5 SPL everywhere. +to after it has finished loading everything into internal SRAM. + +.. code-block:: text + + | WKUP Domain +ROM -> WKUP SPL -> + +The wakeup SPL, running on a wakeup domain core, will initialize DDR and +any peripherals needed load the larger binaries inside the `tispl.bin` Some of this is sounding specific to file-system based boot modes, might be good to pick a name for this blob, then point out what we expect it to be called when still on filesystems. +into DDR. Once loaded the wakeup SPL will start one of the 'big' +application cores inside the main domain to initialize the main domain, +starting with ARM Trusted Firmware (ATF), before moving on to start +OPTEE and the main domain's U-Boot SPL. + +.. code-block:: text + + | WKUP Domain | Main Domain -> +ROM -> WKUP SPL -> ATF -> OPTEE -> Main SPL + +The main domain's SPL, running on a 64bit application core, has +virtually unlimited space (billions of bytes now that DDR is working) to +initialize even more peripherals needed to load in the `u-boot.img` +which loads more firmware into the micro-controller & wakeup domains and Also loads up cores in the MAIN domain, could be easier to make this generic. +finally prepare the main domain to run Linux. + +.. code-block:: text + + | WKUP Domain | Main Domain -> +ROM -> WKUP SPL -> ATF -> OPTEE -> Main SPL -> UBoot -> Linux + Could help to lay this out virtually, since the R5 core keeps running after the MAIN domain is running, it is not a direct execution handover. +This is the typical boot flow for all K3 based SoCs, however this flow +offers quite a lot in the terms of flexibility, especially on High +Security (HS) SoCs. + +Boot Flow Variations + + +All K3 SoCs will generally use the above boot flow with two main +differences depending on the capabilities of the boot ROM and the
Re: [PATCH v2 4/9] dt-bindings: reset: add sama7g5 definitions
On 1/3/23 17:35, sergiu.m...@microchip.com wrote: On 03.01.2023 17:59, Marek Vasut wrote: On 1/3/23 16:55, sergiu.m...@microchip.com wrote: On 03.01.2023 17:48, Marek Vasut wrote: On 1/3/23 16:35, Sergiu Moga wrote: Upstream linux commit 5994f58977e0. Add reset bindings for SAMA7G5. At the moment only USB PHYs are included. Signed-off-by: Sergiu Moga --- v1 -> v2: - nothing include/dt-bindings/reset/sama7g5-reset.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 include/dt-bindings/reset/sama7g5-reset.h diff --git a/include/dt-bindings/reset/sama7g5-reset.h b/include/dt-bindings/reset/sama7g5-reset.h new file mode 100644 index 00..2116f41d04 --- /dev/null +++ b/include/dt-bindings/reset/sama7g5-reset.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ + +#ifndef __DT_BINDINGS_RESET_SAMA7G5_H +#define __DT_BINDINGS_RESET_SAMA7G5_H + +#define SAMA7G5_RESET_USB_PHY1 4 +#define SAMA7G5_RESET_USB_PHY2 5 +#define SAMA7G5_RESET_USB_PHY3 6 Is there no reset with ID 0/1/2/3 ? No, there is not. Please just add a comment into the file then, explaining that. Would this not make the commit different from the upstream linux commit referenced in the commit message? Perhaps it would be better to place this comment in the commit message instead? That works too, thanks.
Re: [PATCH v2 1/3] phy: at91: Add support for the USB 2.0 PHY's of SAMA7
On 1/3/23 17:54, sergiu.m...@microchip.com wrote:
On 03.01.2023 17:31, Marek Vasut wrote:
On 1/3/23 15:30, Sergiu Moga wrote:
In order to have USB functionality, drivers for SAMA7's
USB 2.0 PHY's have been added. There is one driver
for UTMI clock's SFR and RESET required functionalities and
one for its three possible subclocks of the phy's themselves.
In order for this layout to properly work in conjunction with
CCF and DT, the former driver will also act as a clock provider
for the three phy's with the help of a custom hook into the
driver's of_xlate method.
[...]
+static int sama7_utmi_probe(struct udevice *dev)
+{
+ struct clk *utmi_parent_clk, *utmi_clk;
+ struct regmap *regmap_sfr;
+ struct reset_ctl *phy_reset;
+ int i;
+ char name[16];
+
+ utmi_parent_clk = devm_clk_get(dev, "utmi_clk");
+ if (IS_ERR(utmi_parent_clk))
+ return PTR_ERR(utmi_parent_clk);
+
+ regmap_sfr = syscon_regmap_lookup_by_phandle(dev, "sfr-phandle");
+ if (IS_ERR(regmap_sfr))
+ return PTR_ERR(regmap_sfr);
+
+ for (i = 0; i < ARRAY_SIZE(sama7_utmick); i++) {
+ snprintf(name, sizeof(name), "usb%d_reset", i);
+ phy_reset = devm_reset_control_get(dev, name);
+ if (IS_ERR(phy_reset))
+ return PTR_ERR(phy_reset);
+
+ utmi_clk = sama7_utmi_clk_register(regmap_sfr, phy_reset,
+ sama7_utmick[i].n,
+ sama7_utmick[i].p,
+ sama7_utmick[i].id);
+ if (IS_ERR(utmi_clk))
+ return PTR_ERR(utmi_clk);
Isn't this going to leak memory if i>0 and a failure occurs ? I think it
will, since sama7_utmi_clk_register() calls kzalloc() .
Yes, you are right. Perhaps something like this should work better
instead, wouldn't you agree?
static int sama7_utmi_probe(struct udevice *dev)
{
- struct clk *utmi_parent_clk, *utmi_clk;
+ struct clk *utmi_parent_clk, *utmi_clk[ARRAY_SIZE(sama7_utmick)];
+ struct sama7_utmi_clk *uclk;
struct regmap *regmap_sfr;
struct reset_ctl *phy_reset;
- int i;
+ int i, j;
char name[16];
utmi_parent_clk = devm_clk_get(dev, "utmi_clk");
@@ -153,12 +154,18 @@ static int sama7_utmi_probe(struct udevice *dev)
if (IS_ERR(phy_reset))
return PTR_ERR(phy_reset);
- utmi_clk = sama7_utmi_clk_register(regmap_sfr, phy_reset,
+ utmi_clk[i] = sama7_utmi_clk_register(regmap_sfr, phy_reset,
sama7_utmick[i].n,
sama7_utmick[i].p,
sama7_utmick[i].id);
- if (IS_ERR(utmi_clk))
+ if (IS_ERR(utmi_clk)) {
+ for (j = 0; j < i; j++) {
+ uclk = to_sama7_utmi_clk(utmi_clk[j]);
+ kfree(uclk);
Do the usual error handling path using goto:
{
...
if (IS_ERR(...))
goto error_clk_register;
...
error_clk_register:
kfree();
error_something_else:
clean_up_other_stuff();
return ret;
}
Re: [RFC PATCH 16/17] arm: sunxi: add Allwinner T113s devicetree stub
On Tue, 06 Dec 2022 13:55:02 +0800
Icenowy Zheng wrote:
Hi Icenowy,
> 在 2022-12-06星期二的 00:45 +，Andre Przywara写道：
> > This adds the basic SoC .dtsi devicetree stub for the Allwinner T113s
> > SoC. This shares a die with the Allwinner D1 SoC (with RISC-V cores),
> > but uses two Cortex-A7 cores instead of the T-HEAD C906 RISC-V core.
> >
> > Include the existing D1 devicetree stub, but add the ARM specific
> > nodes,
> > like for the CPU, the arch timer and the GIC.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > arch/arm/dts/sun8i-t113s.dtsi | 59
> > +++
> > 1 file changed, 59 insertions(+)
> > create mode 100644 arch/arm/dts/sun8i-t113s.dtsi
> >
> > diff --git a/arch/arm/dts/sun8i-t113s.dtsi b/arch/arm/dts/sun8i-
> > t113s.dtsi
> > new file mode 100644
> > index 000..0919ce559f6
> > --- /dev/null
> > +++ b/arch/arm/dts/sun8i-t113s.dtsi
> > @@ -0,0 +1,59 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +// Copyright (C) 2022 Arm Ltd.
> > +
> > +#define SOC_PERIPHERAL_IRQ(nr) GIC_SPI nr
> > +
> > +#include
> > +#include <../../riscv/dts/sunxi-d1s-t113.dtsi>
>
> Should we make a R528 DTSI which includes d1-t113.dtsi, and then T113
> DTSI which includes d1s-t113.dtsi ?
If I understand Samuel correctly, the T113-s includes the DSP, in contrast
to the D1s, which has fused that off.
That would make including both sunxi-d1*-t113.dtsi files the right choice,
wouldn't it? According to Samuel's list, sunxi-d1-t113.dtsi contains DSP
related peripherals.
I don't know if there is anything DT relevant that the R528 has over the
T113-s, but I don't claim to provide an R528 DT anyway, at least not yet,
so we can leave this for the future, should a board or manual emerge.
So this file here should to be the equivalent of sun20i-d1s.dtsi,
providing the ARM specific bits.
Does that make sense? If you agree, I would post this to Linux ASAP.
Cheers,
Andre
> > +#include <../../riscv/dts/sunxi-d1-t113.dtsi>
> > +
> > +/ {
> > + interrupt-parent = <>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a7";
> > + device_type = "cpu";
> > + reg = <0>;
> > + clocks = < CLK_CPUX>;
> > + clock-names = "cpu";
> > + };
> > +
> > + cpu1: cpu@1 {
> > + compatible = "arm,cortex-a7";
> > + device_type = "cpu";
> > + reg = <1>;
> > + clocks = < CLK_CPUX>;
> > + clock-names = "cpu";
> > + };
> > + };
> > +
> > + gic: interrupt-controller@1c81000 {
> > + compatible = "arm,gic-400";
> > + reg = <0x03021000 0x1000>,
> > + <0x03022000 0x2000>,
> > + <0x03024000 0x2000>,
> > + <0x03026000 0x2000>;
> > + interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv7-timer";
> > + interrupts = > IRQ_TYPE_LEVEL_LOW)>,
> > + > IRQ_TYPE_LEVEL_LOW)>,
> > + > IRQ_TYPE_LEVEL_LOW)>,
> > + > IRQ_TYPE_LEVEL_LOW)>;
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a7-pmu";
> > + interrupts = ,
> > + ;
> > + interrupt-affinity = <>, <>;
> > + };
> > +};
>
[PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon,
hmm this is strange. I am hitting this usually before 10 repetitions,
for sure within 30 repetitions. 'gpu_freq' is missing, thus default.
I can see this also from stock JeOS/RPi3 from OpenSUSE.
Do you have enabled debug as it works as workaround? [usb_hub.c]
Dissected more, thoughts into record:
** not reproduced on underclocked RPi4
** not reproduced with hardcoded poll_delay=0 [common/usb_kbd.c]
** reproduced with hardcoded poll_delay=1 [common/usb_kbd.c]
** not reproduced when '#define LOG_DEBUG' enabled in common/usb_hub.c
** workaround is to output character in non 'UCLASS_USB_HUB' branch,
even mdelay(500) instead of printing character would not help.
Seems to be synchronization problem, please advise if you have any
ideas/suggestions how to troubleshoot.
%< -
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 95f1449..817e15e 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -73,8 +73,10 @@ static inline bool usb_hub_is_superspeed(struct usb_device
*hdev)
#if CONFIG_IS_ENABLED(DM_USB)
bool usb_hub_is_root_hub(struct udevice *hub)
{
- if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB)
+ if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB) {
+ puts(".");
return true;
+ }
return false;
}
%< -
Happy new year!
Regards,
Filip
On 1/3/23 18:02, Simon Glass wrote:
Hi Filip,
On Mon, 19 Dec 2022 at 14:25, Filip Žaludek wrote:
Hi Simon,
On 12/19/22 20:20, Simon Glass wrote:
Hi Filip,
On Mon, 19 Dec 2022 at 02:29, Filip Žaludek wrote:
Hi Simon,
is your testing framework connected to HDMI? Only notable discrepancy
from generic config is enabled 'efidebug' command.
Tested more (cycled 'U-Boot>' and 'reset'), both RPi3B and RPi3B+..
USB Keyboard failure rates:
connected console02/10
connected hdmi 06/10
connected console + hdmi 07/10
** USB Keyboard always detected by 'usb info', just does not respond.
USB Keyboard failure rates, reverted 96991e652f541323a03c5b7e075d54a117091618:
connected console + hdmi 00/10
Yes this one does have HDMI. Are you wanting me to run multiple runs?
With or without the display?
Yes please! With HDMI as there is better chance you will hit issue I am
experiencing,
to confirm 96991e652f541323a03c5b7e075d54a117091618 is inferior for RPi3.
You should see usb_kbd detected, but no input possible.
I am not seeing this problem, but the HDMI is not actually working. It
could be because of a setting in the silly config.txt file, e.g.
gpu_freq=250
The display comes to life and then says no signal.
But I tried it 10 times on us/next and the USB keyboard worked each time.
Regards,
Simon
Re: [PATCH v2] riscv: ax25: bypass malloc when spl fit boots from ram
Hi Rick,
On 1/3/23 02:20, Rick Chen wrote:
> When fit image boots from ram, the payload will
> be prepared in the address of SPL_LOAD_FIT_ADDRESS.
> In spl fit generic flow, it will malloc another
> memory address and copy whole fit image to this
> malloc address. But it is un-necessary for booting
> from RAM.
>
> This patch improves this flow by declare the
> board_spl_fit_buffer_addr() to replace the original one.
> The larger image size (eq: Kernel Image 10~20MB), it
> can save more booting time.
>
> Also enhance memcpy function by checking source and
> destination address. If they are the same address,
> just return and don't copy data anymore.
Starting a paragraph with "also" is a good indication that this should
be split into two separate patches.
> Signed-off-by: Rick Chen
> ---
> Changes in v2
> - Move spl.c to board level instead of arch level
> ---
> arch/riscv/cpu/ax25/Makefile | 1 +
> arch/riscv/cpu/ax25/spl.c| 31 +++
> arch/riscv/lib/memcpy.S | 2 ++
> 3 files changed, 34 insertions(+)
> create mode 100644 arch/riscv/cpu/ax25/spl.c
>
> diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
> index 318baccb09..f1c21eadd4 100644
> --- a/arch/riscv/cpu/ax25/Makefile
> +++ b/arch/riscv/cpu/ax25/Makefile
> @@ -5,3 +5,4 @@
>
> obj-y:= cpu.o
> obj-y+= cache.o
> +obj-y += spl.o
nit: alignment
> diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/ax25/spl.c
> new file mode 100644
> index 00..6bf357d26d
> --- /dev/null
> +++ b/arch/riscv/cpu/ax25/spl.c
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#if CONFIG_IS_ENABLED(RAM_SUPPORT)
> +struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
> +{
> + return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
> +}
> +
> +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
> +{
> + void *buf;
> +
> + buf = spl_get_load_buffer(0, sectors * bl_len);
> +
> + return buf;
nit: this could all be one line
Regards,
Samuel
> +}
> +#endif
> diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
> index 00672c19ad..9884077c93 100644
> --- a/arch/riscv/lib/memcpy.S
> +++ b/arch/riscv/lib/memcpy.S
> @@ -9,6 +9,7 @@
> /* void *memcpy(void *, const void *, size_t) */
> ENTRY(__memcpy)
> WEAK(memcpy)
> + beq a0, a1, .copy_end
> /* Save for return value */
> mv t6, a0
>
> @@ -121,6 +122,7 @@ WEAK(memcpy)
> 2:
>
> mv a0, t6
> +.copy_end:
> ret
>
> .Lmisaligned_word_copy:
Re: [PATCH v2] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
On 1/3/23 02:18, Rick Chen wrote:
> Original openSBI (without FW_PIC) will relocate itselt
typo: itself
> from 0x100 to 0x0. After openSBI added FW_PIC codes,
> it will not relocate any more and alaways run at 0x100.
typo: always
> Hence, it may overlap with Kernel memory region. So it is
> necessary to change openSBI address from 0x100 to 0x0.
>
> More details can refer to commit cb052d771200
> ("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
>
> Signed-off-by: Rick Chen
Reviewed-by: Samuel Holland
> ---
>
> Changes in v2
> - fix typo
> - describe why is this change a must have
>
> ---
>
> board/AndesTech/ax25-ae350/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/AndesTech/ax25-ae350/Kconfig
> b/board/AndesTech/ax25-ae350/Kconfig
> index 36b67f0b52..4bb33b0793 100644
> --- a/board/AndesTech/ax25-ae350/Kconfig
> +++ b/board/AndesTech/ax25-ae350/Kconfig
> @@ -25,7 +25,7 @@ config SPL_TEXT_BASE
> default 0x80
>
> config SPL_OPENSBI_LOAD_ADDR
> - default 0x0100
> + default 0x
>
> config SYS_FDT_BASE
> hex
> --
> 2.17.1
>
Re: [PATCH] adc: stm32mp15: add calibration support
Hi, On 12/15/22 13:51, Olivier Moysan wrote: Add support of offset and linear calibration for STM32MP15. The calibration is performed once at probe. The ADC is set in power on state for calibration. It remains in this state after calibration, to give to the kernel the opportunity to retrieve calibration data, directly from the ADC. Signed-off-by: Olivier Moysan --- drivers/adc/stm32-adc.c | 134 ++-- 1 file changed, 116 insertions(+), 18 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] dm: pinctrl: Revert "pinctrl: probe pinctrl drivers during post-bind"
Hi Robert,
On Fri, 30 Dec 2022 at 13:26, Robert Marko wrote:
>
>
>
> On Fri, Dec 30, 2022 at 8:02 PM Simon Glass wrote:
>>
>> Hi Pali,
>>
>> On Fri, 30 Dec 2022 at 12:02, Pali Rohár wrote:
>> >
>> > On Friday 30 December 2022 11:47:29 Simon Glass wrote:
>> > > Hi Pali,
>> > >
>> > > On Fri, 30 Dec 2022 at 10:13, Pali Rohár wrote:
>> > > >
>> > > > On Friday 30 December 2022 10:00:11 Simon Glass wrote:
>> > > > > Hi Pali,
>> > > > >
>> > > > > On Fri, 30 Dec 2022 at 09:53, Pali Rohár wrote:
>> > > > > >
>> > > > > > On Friday 30 December 2022 09:30:27 Simon Glass wrote:
>> > > > > > > Hi Pali,
>> > > > > > >
>> > > > > > > On Wed, 21 Dec 2022 at 17:02, Pali Rohár wrote:
>> > > > > > > >
>> > > > > > > > On Wednesday 21 December 2022 07:27:39 Simon Glass wrote:
>> > > > > > > > > This breaks chromebook_coral and it is also not how things
>> > > > > > > > > should work. If
>> > > > > > > > > a board needs to bind GPIOs as part of a pinctrl driver this
>> > > > > > > > > can be done
>> > > > > > > > > during the bind step, if needed.
>> > > > > > > > >
>> > > > > > > > > We cannot probe pinctrl devices when binding as a rule,
>> > > > > > > > > since it cannot be
>> > > > > > > > > supported on some platforms.
>> > > > > > > > >
>> > > > > > > > > The bind and probe steps are separate in U-Boot and they
>> > > > > > > > > should remain
>> > > > > > > > > separate.
>> > > > > > > > >
>> > > > > > > > > This reverts commit f9ec791b5e24378b71590877499f8683d5f54dac.
>> > > > > > > >
>> > > > > > > > Unfortunately reverting this patch would break other devices,
>> > > > > > > > mostly
>> > > > > > > > A3720 based where pinctrl driver acts also as gpio driver.
>> > > > > > > > Because no
>> > > > > > > > other caller then register gpio driver and so other drivers
>> > > > > > > > which parses
>> > > > > > > > gpios from DT (which belongs to that gpio driver) will fail
>> > > > > > > > during
>> > > > > > > > probe.
>> > > > > > >
>> > > > > > > That is something to be sorted out for that platform. You can
>> > > > > > > bind
>> > > > > > > GPIO devices in the pinctrl driver's bind() method as other SoCs
>> > > > > > > do.
>> > > > > > > Even better, the device tree typically has that info in it, i.e.
>> > > > > > > GPIO
>> > > > > > > subnodes within the pinctrl node.
>> > > > > > >
>> > > > > > > Probing pinctrl in a bind function is unfortunately just wrong.
>> > > > > > > It
>> > > > > > > will cause all sorts of problems, and perhaps already has.
>> > > > > >
>> > > > > > Ok, so it means that drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
>> > > > > > needs
>> > > > > > to be refactored and fixed to handle these restrictions.
>> > > > >
>> > > > > It is not a restriction. It is simply that binding and probing are
>> > > > > different things and we should not tie them together. It will just
>> > > > > become a nightmare for board bringup and other drivers.
>> > > > >
>> > > > > >
>> > > > > > > > Also I think that pinctrl command would not work in this case
>> > > > > > > > if pinctrl
>> > > > > > > > would not be probed.
>> > > > > > >
>> > > > > > > Devices are probed before use, including by commands.
>> > > > > > >
>> > > > > > > This is quite important to fix before the release.
>> > > > > >
>> > > > > > Unfortunately in this time I do not have any a3720 board for
>> > > > > > testing.
>> > > > > > Robert was able to easily trigger this issue and also introduced
>> > > > > > that
>> > > > > > commit f9ec791b5e24 ("pinctrl: probe pinctrl drivers during
>> > > > > > post-bind").
>> > > > > >
>> > > > > > So may I ask Robert to look at it? In past days I looked at powerpc
>> > > > > > release issues and I do not have time for other things.
>> > > > >
>> > > > > That driver has a few FIXMEs in it and could use a look anyway. I see
>> > > > > that the gpio controller is a subnode of pinctrl anyway. Adding a
>> > > > > compatible string for it would fix the problem just like that, and
>> > > > > remove a lot of ugly code in the driver. This Linux-centric nature of
>> > > > > device tree bindings really is infuriating:
>> > > >
>> > > > All a3720 DTS files are 1:1 copied from Linux. So if problem is in DTS
>> > > > file then it should be discussed with Linux dt/mvebu maintainers. This
>> > > > year I fixed U-Boot code to handle Linux a3720 DTS files and then
>> > > > copied
>> > > > DTS files from Linux. So it is not a good idea to have again different
>> > > > DTS file for u-boot and different for kernel.
>>
>> That was not my suggestion. I would simply like the bindings in Linux
>> to be more explicit, rather than having driver code manually written
>> to do what the device tree is supposed to do.
>>
>> > > >
>> > > > > /* FIXME: Use livtree and check the result of device_bind() below */
>> > > > > fdt_for_each_subnode(subnode, blob, node) {
>> > > > > if (fdtdec_get_bool(blob, subnode, "gpio-controller")) {
>> > > > > ret = 0;
>> > > > > break;
>> > > > > }
>> > >
Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx
On Tuesday 03 January 2023 11:02:17 Simon Glass wrote: > > > > > 3. Add a common binman image for u-boot.bin (used by every board) > > > > > > > > It should be u-boot-dtb.bin (not u-boot.bin). At least this is the > > > > current file name. (See this my patch series again, which aligns this > > > > naming also for powerpc/mpc85xx). > > > > > > We changed this 6 years ago and I'm not keen on going back. > > > > > > ad1ecd2063d fdt: Build a U-Boot binary without device tree > > > > I just do not understand you because in that commit is exactly what I > > wrote. In file u-boot-dtb.bin is u-boot binary with DTB and in file > > u-boot-nodtb.bin is u-boot binary without DTB. > > > > So binman should take input files u-boot-nodtb.bin and DTB binary. And > > should produce output file u-boot-dtb.bin. Is there any issue with it? > > Actually u-boot-dtb.bin is a hangover from that commit, left in to > allow people to adjust. So I think we should remove creation of > u-boot-dtb.bin Ok, complete remove of u-boot-dtb.bin creation also works.
Re: [PATCH 2/2] tee: optee: discover services dependent on tee-supplicant
Hi,
On 12/7/22 16:30, Etienne Carriere wrote:
Makes OP-TEE to enumerate also services depending on tee-supplicant
support in U-Boot. This change allows OP-TEE services like fTPM TA
to be discovered and get a TPM device registered in U-Boot.
Signed-off-by: Etienne Carriere
---
drivers/tee/optee/core.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 604fd1414f..b21031d7d8 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -102,13 +102,14 @@ static int bind_service_list(struct udevice *dev, struct
tee_shm *service_list,
return 0;
}
-static int __enum_services(struct udevice *dev, struct tee_shm *shm, size_t *shm_size, u32 tee_sess)
+static int __enum_services(struct udevice *dev, struct tee_shm *shm, size_t
*shm_size, u32 tee_sess,
+ unsigned int pta_cmd)
{
struct tee_invoke_arg arg = { };
struct tee_param param = { };
int ret = 0;
- arg.func = PTA_CMD_GET_DEVICES;
+ arg.func = pta_cmd;
arg.session = tee_sess;
/* Fill invoke cmd params */
@@ -118,7 +119,7 @@ static int __enum_services(struct udevice *dev, struct
tee_shm *shm, size_t *shm
ret = tee_invoke_func(dev, , 1, );
if (ret || (arg.ret && arg.ret != TEE_ERROR_SHORT_BUFFER)) {
- dev_err(dev, "PTA_CMD_GET_DEVICES invoke function err: 0x%x\n",
arg.ret);
+ dev_err(dev, "Enumeration command 0x%x failed: 0x%x\n",
pta_cmd, arg.ret);
return -EINVAL;
}
@@ -127,12 +128,13 @@ static int __enum_services(struct udevice *dev, struct tee_shm *shm, size_t *shm
return 0;
}
-static int enum_services(struct udevice *dev, struct tee_shm **shm, size_t *count, u32 tee_sess)
+static int enum_services(struct udevice *dev, struct tee_shm **shm, size_t
*count, u32 tee_sess,
+unsigned int pta_cmd)
{
size_t shm_size = 0;
int ret;
- ret = __enum_services(dev, NULL, _size, tee_sess);
+ ret = __enum_services(dev, NULL, _size, tee_sess, pta_cmd);
if (ret)
return ret;
@@ -142,7 +144,7 @@ static int enum_services(struct udevice *dev, struct tee_shm **shm, size_t *coun
return ret;
}
- ret = __enum_services(dev, *shm, _size, tee_sess);
+ ret = __enum_services(dev, *shm, _size, tee_sess, pta_cmd);
if (!ret)
*count = shm_size / sizeof(struct tee_optee_ta_uuid);
@@ -174,20 +176,32 @@ static int bind_service_drivers(struct udevice *dev)
struct tee_shm *service_list = NULL;
size_t service_count;
u32 tee_sess;
- int ret;
+ int ret, ret2;
ret = open_enum_session(dev, _sess);
if (ret)
return ret;
- ret = enum_services(dev, _list, _count, tee_sess);
+ ret = enum_services(dev, _list, _count, tee_sess,
+ PTA_CMD_GET_DEVICES);
if (!ret)
ret = bind_service_list(dev, service_list, service_count);
tee_shm_free(service_list);
can you move part of duplicate code in enum_services() function ?
=> variables service_list and service_count
=> call to bind_service_list()
=> call to tee_shm_free(service_list);
then the call is more simple :
static int bind_service_drivers(struct udevice *dev)
u32 tee_sess;
int ret, ret2;
ret = open_enum_session(dev, _sess);
if (ret)
return ret;
ret = enum_services(dev, tee_sess, PTA_CMD_GET_DEVICES);
ret2 = enum_services(dev, tee_sess, PTA_CMD_GET_DEVICES_SUPP);
tee_close_session(dev, tee_sess);
if (ret)
return ret;
return ret2;
}
+
+ ret2 = enum_services(dev, _list, _count, tee_sess,
+PTA_CMD_GET_DEVICES_SUPP);
+ if (!ret2)
+ ret2 = bind_service_list(dev, service_list, service_count);
+
+ tee_shm_free(service_list);
+
tee_close_session(dev, tee_sess);
- return ret;
+ if (ret)
+ return ret;
+
+ return ret2;
}
/**
with or without
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx
Hi Pali,
On Fri, 30 Dec 2022 at 13:12, Pali Rohár wrote:
>
> On Friday 30 December 2022 12:51:03 Simon Glass wrote:
> > Hi Pali,
> >
> > On Fri, 30 Dec 2022 at 11:55, Pali Rohár wrote:
> > >
> > > On Friday 30 December 2022 11:43:44 Simon Glass wrote:
> > > > Hi Pali,
> > > >
> > > > On Fri, 30 Dec 2022 at 10:06, Pali Rohár wrote:
> > > > >
> > > > > On Friday 30 December 2022 09:49:08 Simon Glass wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Fri, 30 Dec 2022 at 09:44, Pali Rohár wrote:
> > > > > > >
> > > > > > > On Friday 30 December 2022 10:41:47 Tom Rini wrote:
> > > > > > > > On Fri, Dec 30, 2022 at 04:24:43PM +0100, Pali Rohár wrote:
> > > > > > > > > On Friday 30 December 2022 10:21:04 Tom Rini wrote:
> > > > > > > > > > > In this case it would be better to build u-boot-dts.bin
> > > > > > > > > > > only by binman
> > > > > > > > > > > (for all platforms) instead of cat-ing rules in Makefile.
> > > > > > > > > >
> > > > > > > > > > This would also be an easier path forward perhaps for
> > > > > > > > > > making sure that
> > > > > > > > > > the dtb is always 8 byte aligned?
> > > > > > > > >
> > > > > > > > > Well, no. With DTB the problem is that it is not put to the
> > > > > > > > > correct
> > > > > > > > > offset as can be specified in linker script. So moving this
> > > > > > > > > code from
> > > > > > > > > Makefile to binman also moves this problem to another
> > > > > > > > > location.
> > > > > > > > > 8 byte alignment is just subset of the "correct offset"
> > > > > > > > > problem.
> > > > > > > >
> > > > > > > > Right, the high level answer is binman is intended to be the
> > > > > > > > tool to
> > > > > > > > assemble binaries, and has to deal with "make sure binary X is
> > > > > > > > at offset
> > > > > > > > Y, which also has a linker symbol for run-time references".
> > > > > > >
> > > > > > > Ok, if this tool has access to ELF/linker symbols (or will have in
> > > > > > > future in case it does not have yet) then this problem could be
> > > > > > > solved
> > > > > > > here.
> > > > > >
> > > > > > It does have this access and already updates symbols in some cases.
> > > > > > See [1].
> > > > > > [1]
> > > > > > https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#access-to-binman-entry-offsets-at-run-time-symbols
> > > > >
> > > > > I just do not see how to do it, but ok, maybe something more is
> > > > > needed.
> > > > >
> > > > > > I am a little nervous about a complete move to binman in this
> > > > > > area even for simple things like u-boot.bin, since it would set off
> > > > > > yet another migration.
> > > > >
> > > > > Yes, it sounds like a big change.
> > > > >
> > > > > > But perhaps most boards don't actually use u-boot.bin anyway?
> > > > >
> > > > > I think that most boards _use_ u-boot.bin. Or wrap u-boot.bin into
> > > > > some
> > > > > own container (by mkimage).
> > > > >
> > > > > > Part of me thinks we should solve this in the .lds files, since
> > > > > > otherwise we are blurring the line between building and packaging.
> > > > >
> > > > > Linker script files in any case would have to be adjusted / fixed to
> > > > > align _end symbol. Without it ELF symbol would not be correct and so
> > > > > obviously any solution depending on ELF symbols would not work...
> > > > >
> > > > > As I wrote recently, I proposed alternative solution without binman:
> > > > > https://lore.kernel.org/u-boot/20221217235913.w7ihsktbplbp2j7z@pali/
> > > >
> > > > I think that would work. It is a little like the BINARY_SIZE_CHECK
> > > > thing we have. It is the closest thing to what we have. As you saw I
> > > > was happy with your original 'trunc' solution too.
> > > >
> > > > After some more thought, perhaps the binman solution makes sense, so
> > > > long as we do what you say above (make the _end symbol aligned). Of
> > > > course binman can fix that up, but it feels more like a build thing
> > > > than a packaging thing to me.
> > >
> > > Yes, this is build thing/issue, not packaging one.
> > >
> > > > It could be quite confusing for people
> > > > to see a symbol change between build-time and run-time.
> > >
> > > Yes, symbol change is confusing. So I would propose to not change any
> > > symbol between build and run time.
> > >
> > > > So the steps would be something like this:
> > > >
> > > > 1. Update the align before _end in each .lds to use a constant like
> > > > #define END_ALIGN 8
> > > > 2. Update binman's dtb etypes to align to 8 bytes
> > >
> > > This is not enough. Some boards/platform may have stricter alignment
> > > (e.g. to SD card sector size = 512 bytes). So binman should not align
> > > image and instead of that, it should read _exact_ address of _end
> > > symbol and put DTB etype to this address. Step 1. already ensures that
> > > _end is aligned to 8 bytes.
> >
> > OK, we can do that I suppose, perhaps with a new binman property:
> >
> > u_boot: u-boot-nodtb {
> > };
> > u-boot-dtb {
> >align-to-sym =
Re: [PATCH 1/1] cmd: avoid endless loop in sound play command
On Fri, 30 Dec 2022 at 17:54, Heinrich Schuchardt wrote: > > A parameter starting with a hyphen leads to an endless loop in the sound > play command. > > Leave it to dectoul() to handle the hyphen. It will return 0 for a negative > number. > > Signed-off-by: Heinrich Schuchardt > --- > cmd/sound.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass Could add a test for this command perhaps
Re: [PATCH v2 2/2] rockchip: Add initial support for the PINE64 Pinephone Pro
Hi Peter,
On Sat, 31 Dec 2022 at 03:24, Peter Robinson wrote:
>
> The Pinephone Pro is another device by PINE64. It's closely related
> to the Pinebook Pro of which this initial support is derived from.
>
> Specification:
> - A variant of the Rockchip RK3399
> - A 6 inch 720*1440 DSI display
> - Front and rear cameras
> - Type-C interface with alt mode display (DP 1.2) and PD charging
> - 4GB LPDDR4 RAM
> - 128GB eMMC
> - mSD card slot
> - An AP6255 module for 802.11ac WiFi and Bluetooth 5
> - Quectel EG25-G 4G/LTE modem
>
> Signed-off-by: Peter Robinson
> ---
> arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi | 31 ++
> arch/arm/mach-rockchip/rk3399/Kconfig | 8 ++
> board/pine64/pinephone-pro-rk3399/Kconfig | 15 +++
> board/pine64/pinephone-pro-rk3399/MAINTAINERS | 8 ++
> board/pine64/pinephone-pro-rk3399/Makefile| 1 +
> .../pinephone-pro-rk3399.c| 76 +
> configs/pinephone-pro-rk3399_defconfig| 104 ++
> include/configs/pinephone-pro-rk3399.h| 19
> 8 files changed, 262 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
> create mode 100644 board/pine64/pinephone-pro-rk3399/Kconfig
> create mode 100644 board/pine64/pinephone-pro-rk3399/MAINTAINERS
> create mode 100644 board/pine64/pinephone-pro-rk3399/Makefile
> create mode 100644 board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> create mode 100644 configs/pinephone-pro-rk3399_defconfig
> create mode 100644 include/configs/pinephone-pro-rk3399.h
>
Reviewed-by: Simon Glass
Just a nit below
[..]
> new file mode 100644
> index 000..8d9203053e5
> --- /dev/null
> +++ b/board/pine64/pinephone-pro-rk3399/Makefile
> @@ -0,0 +1 @@
> +obj-y += pinephone-pro-rk3399.o
> diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> new file mode 100644
> index 000..eb639cd0d07
> --- /dev/null
> +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> + * (C) Copyright 2022 Peter Robinson
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GRF_IO_VSEL_BT565_SHIFT 0
> +#define PMUGRF_CON0_VSEL_SHIFT 8
> +
> +#ifndef CONFIG_SPL_BUILD
You should be able to use C code inside the function
if (spl_phase() == PHASE_SPL) {
..
> +int board_early_init_f(void)
> +{
> + struct udevice *regulator;
> + int ret;
> +
> + ret = regulator_get_by_platname("vcc5v0_usb", );
> + if (ret) {
> + pr_debug("%s vcc5v0_usb init fail! ret %d\n", __func__, ret);
> + goto out;
> + }
> +
> + ret = regulator_set_enable(regulator, true);
> + if (ret)
> + pr_debug("%s vcc5v0-host-en-gpio set fail! ret %d\n",
> __func__, ret);
> +
> +out:
> + return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_MISC_INIT_R
Won't the compiler drop this anyway if it is not needed? Can you drop
the #ifdef ?
> +static void setup_iodomain(void)
> +{
> + struct rk3399_grf_regs *grf =
> + syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> + struct rk3399_pmugrf_regs *pmugrf =
> + syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
> +
> + /* BT565 is in 1.8v domain */
> + rk_setreg(>io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT);
> +
> + /* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */
> + rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
> +}
> +
> +int misc_init_r(void)
> +{
> + const u32 cpuid_offset = 0x7;
> + const u32 cpuid_length = 0x10;
> + u8 cpuid[cpuid_length];
> + int ret;
> +
> + setup_iodomain();
> +
> + ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> + if (ret)
> + return ret;
> +
> + ret = rockchip_cpuid_set(cpuid, cpuid_length);
> + if (ret)
> + return ret;
> +
> + return ret;
> +}
> +#endif
> diff --git a/configs/pinephone-pro-rk3399_defconfig
> b/configs/pinephone-pro-rk3399_defconfig
> new file mode 100644
> index 000..eb979f6c051
> --- /dev/null
> +++ b/configs/pinephone-pro-rk3399_defconfig
> @@ -0,0 +1,104 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_COUNTER_FREQUENCY=2400
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_TEXT_BASE=0x0020
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_ENV_SIZE=0x8000
> +CONFIG_ENV_OFFSET=0x3F8000
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinephone-pro"
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_TARGET_PINEPHONE_PRO_RK3399=y
> +CONFIG_DEBUG_UART_BASE=0xFF1A
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
> +CONFIG_SPL_SPI=y
> +CONFIG_SYS_LOAD_ADDR=0x800800
> +CONFIG_DEBUG_UART=y
> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>
Re: [PATCH 1/1] efi_loader: fix building aarch64 EFI binaries
On Sat, 31 Dec 2022 at 05:04, Heinrich Schuchardt wrote: > > While our EFI binaries execute without problems on EDK II they crash on > a Lenovo X13s. Let our binaries look more like what EDK II produces: > > * move all writable data to a .data section > * align sections to 4 KiB boundaries (matching EFI page size) > > Signed-off-by: Heinrich Schuchardt > --- > arch/arm/lib/crt0_aarch64_efi.S | 35 ++-- > arch/arm/lib/elf_aarch64_efi.lds | 6 -- > 2 files changed, 28 insertions(+), 13 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Filip, On Mon, 19 Dec 2022 at 14:25, Filip Žaludek wrote: > > > > Hi Simon, > > > On 12/19/22 20:20, Simon Glass wrote: > > Hi Filip, > > > > On Mon, 19 Dec 2022 at 02:29, Filip Žaludek > > wrote: > >> > >> > >> > >> Hi Simon, > >> > >>is your testing framework connected to HDMI? Only notable discrepancy > >> from generic config is enabled 'efidebug' command. > >> > >> > >> Tested more (cycled 'U-Boot>' and 'reset'), both RPi3B and RPi3B+.. > >> USB Keyboard failure rates: > >> connected console02/10 > >> connected hdmi 06/10 > >> connected console + hdmi 07/10 > >> ** USB Keyboard always detected by 'usb info', just does not respond. > >> > >> USB Keyboard failure rates, reverted > >> 96991e652f541323a03c5b7e075d54a117091618: > >> connected console + hdmi 00/10 > > > > Yes this one does have HDMI. Are you wanting me to run multiple runs? > > With or without the display? > > > Yes please! With HDMI as there is better chance you will hit issue I am > experiencing, > to confirm 96991e652f541323a03c5b7e075d54a117091618 is inferior for RPi3. > You should see usb_kbd detected, but no input possible. I am not seeing this problem, but the HDMI is not actually working. It could be because of a setting in the silly config.txt file, e.g. gpu_freq=250 The display comes to life and then says no signal. But I tried it 10 times on us/next and the USB keyboard worked each time. Regards, Simon
Re: [PATCH v2 1/3] phy: at91: Add support for the USB 2.0 PHY's of SAMA7
On 03.01.2023 17:31, Marek Vasut wrote:
> On 1/3/23 15:30, Sergiu Moga wrote:
>> In order to have USB functionality, drivers for SAMA7's
>> USB 2.0 PHY's have been added. There is one driver
>> for UTMI clock's SFR and RESET required functionalities and
>> one for its three possible subclocks of the phy's themselves.
>> In order for this layout to properly work in conjunction with
>> CCF and DT, the former driver will also act as a clock provider
>> for the three phy's with the help of a custom hook into the
>> driver's of_xlate method.
>
> [...]
>
>> +static int sama7_utmi_probe(struct udevice *dev)
>> +{
>> + struct clk *utmi_parent_clk, *utmi_clk;
>> + struct regmap *regmap_sfr;
>> + struct reset_ctl *phy_reset;
>> + int i;
>> + char name[16];
>> +
>> + utmi_parent_clk = devm_clk_get(dev, "utmi_clk");
>> + if (IS_ERR(utmi_parent_clk))
>> + return PTR_ERR(utmi_parent_clk);
>> +
>> + regmap_sfr = syscon_regmap_lookup_by_phandle(dev, "sfr-phandle");
>> + if (IS_ERR(regmap_sfr))
>> + return PTR_ERR(regmap_sfr);
>> +
>> + for (i = 0; i < ARRAY_SIZE(sama7_utmick); i++) {
>> + snprintf(name, sizeof(name), "usb%d_reset", i);
>> + phy_reset = devm_reset_control_get(dev, name);
>> + if (IS_ERR(phy_reset))
>> + return PTR_ERR(phy_reset);
>> +
>> + utmi_clk = sama7_utmi_clk_register(regmap_sfr, phy_reset,
>> + sama7_utmick[i].n,
>> + sama7_utmick[i].p,
>> + sama7_utmick[i].id);
>> + if (IS_ERR(utmi_clk))
>> + return PTR_ERR(utmi_clk);
>
> Isn't this going to leak memory if i>0 and a failure occurs ? I think it
> will, since sama7_utmi_clk_register() calls kzalloc() .
Yes, you are right. Perhaps something like this should work better
instead, wouldn't you agree?
static int sama7_utmi_probe(struct udevice *dev)
{
- struct clk *utmi_parent_clk, *utmi_clk;
+ struct clk *utmi_parent_clk, *utmi_clk[ARRAY_SIZE(sama7_utmick)];
+ struct sama7_utmi_clk *uclk;
struct regmap *regmap_sfr;
struct reset_ctl *phy_reset;
- int i;
+ int i, j;
char name[16];
utmi_parent_clk = devm_clk_get(dev, "utmi_clk");
@@ -153,12 +154,18 @@ static int sama7_utmi_probe(struct udevice *dev)
if (IS_ERR(phy_reset))
return PTR_ERR(phy_reset);
- utmi_clk = sama7_utmi_clk_register(regmap_sfr, phy_reset,
+ utmi_clk[i] = sama7_utmi_clk_register(regmap_sfr, phy_reset,
sama7_utmick[i].n,
sama7_utmick[i].p,
sama7_utmick[i].id);
- if (IS_ERR(utmi_clk))
+ if (IS_ERR(utmi_clk)) {
+ for (j = 0; j < i; j++) {
+ uclk = to_sama7_utmi_clk(utmi_clk[j]);
+ kfree(uclk);
+ }
+
return PTR_ERR(utmi_clk);
+ }
}
return 0;
Re: [PATCH 1/2] tee: optee: don't fail probe because of optee-rng
Hi, On 12/7/22 16:29, Etienne Carriere wrote: Fixes optee-rng driver bind sequence in optee driver to print a warning message but not report an error status when a optee-rng service driver fails to be bound as the optee driver itself is still fully functional. Signed-off-by: Etienne Carriere --- drivers/tee/optee/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 9240277579..604fd1414f 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -834,7 +834,7 @@ static int optee_probe(struct udevice *dev) */ ret = device_bind_driver(dev, "optee-rng", "optee-rng", NULL); if (ret) - return ret; + dev_warn(dev, "ftpm_tee failed to bind: %d\n", ret); } return 0; Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 3/3] ARM: dts: stm32: add support for USB2514B onboard hub on stm32mp157c-ev1
Hi,
On 12/12/22 11:44, Fabrice Gasnier wrote:
Add support for USB2514B onboard hub on stm32mp157c EV1 board. The HUB
is supplied by a 3v3 PMIC regulator.
[backport from linux ad9591b01d24]
Signed-off-by: Fabrice Gasnier
---
arch/arm/dts/stm32mp157c-ev1.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index d142dd30e16b..07bcd7c50672 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -362,6 +362,14 @@
_ehci {
phys = <_port0>;
status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* onboard HUB */
+ hub@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ vdd-supply = <>;
+ };
};
_hs {
Reviewed-by: Patrick Delaunay
Tested-by: Patrick Delaunay
I just test the supply regulator support on EV1 when the port is used
and the regulator is no more always-on.
with modification in ./arch/arm/dts/stm32mp157c-ed1.dts:224
v3v3: buck4 {
regulator-name = "v3v3";
- regulator-always-on;
Thanks
Patrick
Re: [PATCH] ARM: dts: stm32: update vbus-supply of usbphyc_port0 on stm32mp157c-ev1
Hi Fabrice
On 12/12/22 11:32, Fabrice Gasnier wrote:
> phy-stm32-usbphyc bindings uses a connector node with vbus-supply
> property.
>
> [backport from linux 43e55d778a6b]
> Signed-off-by: Fabrice Gasnier
> ---
>
> arch/arm/dts/stm32mp157c-ev1.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp157c-ev1.dts
> b/arch/arm/dts/stm32mp157c-ev1.dts
> index 07bcd7c50672..2d5db41ed67b 100644
> --- a/arch/arm/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/dts/stm32mp157c-ev1.dts
> @@ -393,6 +393,10 @@
> st,tune-squelch-level = <3>;
> st,tune-hs-rx-offset = <2>;
> st,no-lsfs-sc;
> + connector {
> + compatible = "usb-a-connector";
> + vbus-supply = <_sw>;
> + };
> };
>
> _port1 {
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 2/3] configs: stm32: enable USB onboard HUB driver
Hi, On 12/12/22 11:44, Fabrice Gasnier wrote: Activate the USB onboard HUB driver, that is used to enable the HUB supply on STM32MP15 EVAL, DK1 and DK2 boards. This avoids marking the 3v3 corresponding regulator as always-on. Signed-off-by: Fabrice Gasnier --- configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 86ebbef0a6c8..4d2ac589931a 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -164,6 +164,7 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_ONBOARD_HUB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig index caa79e68834f..ccf65dd12223 100644 --- a/configs/stm32mp15_defconfig +++ b/configs/stm32mp15_defconfig @@ -140,6 +140,7 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_ONBOARD_HUB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 3309c2e79246..a553038a42c5 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -140,6 +140,7 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_ONBOARD_HUB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH v2 4/9] dt-bindings: reset: add sama7g5 definitions
On 03.01.2023 17:59, Marek Vasut wrote: > On 1/3/23 16:55, sergiu.m...@microchip.com wrote: >> On 03.01.2023 17:48, Marek Vasut wrote: >>> On 1/3/23 16:35, Sergiu Moga wrote: Upstream linux commit 5994f58977e0. Add reset bindings for SAMA7G5. At the moment only USB PHYs are included. Signed-off-by: Sergiu Moga --- v1 -> v2: - nothing include/dt-bindings/reset/sama7g5-reset.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 include/dt-bindings/reset/sama7g5-reset.h diff --git a/include/dt-bindings/reset/sama7g5-reset.h b/include/dt-bindings/reset/sama7g5-reset.h new file mode 100644 index 00..2116f41d04 --- /dev/null +++ b/include/dt-bindings/reset/sama7g5-reset.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ + +#ifndef __DT_BINDINGS_RESET_SAMA7G5_H +#define __DT_BINDINGS_RESET_SAMA7G5_H + +#define SAMA7G5_RESET_USB_PHY1 4 +#define SAMA7G5_RESET_USB_PHY2 5 +#define SAMA7G5_RESET_USB_PHY3 6 >>> >>> Is there no reset with ID 0/1/2/3 ? >> >> No, there is not. > > Please just add a comment into the file then, explaining that. Would this not make the commit different from the upstream linux commit referenced in the commit message? Perhaps it would be better to place this comment in the commit message instead?
Re: [PATCH 3/3] ARM: dts: stm32: add support for USB2514B onboard hub on stm32mp157c-ev1
Hi Fabrice
On 12/12/22 11:44, Fabrice Gasnier wrote:
> Add support for USB2514B onboard hub on stm32mp157c EV1 board. The HUB
> is supplied by a 3v3 PMIC regulator.
>
> [backport from linux ad9591b01d24]
> Signed-off-by: Fabrice Gasnier
> ---
>
> arch/arm/dts/stm32mp157c-ev1.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp157c-ev1.dts
> b/arch/arm/dts/stm32mp157c-ev1.dts
> index d142dd30e16b..07bcd7c50672 100644
> --- a/arch/arm/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/dts/stm32mp157c-ev1.dts
> @@ -362,6 +362,14 @@
> _ehci {
> phys = <_port0>;
> status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + /* onboard HUB */
> + hub@1 {
> + compatible = "usb424,2514";
> + reg = <1>;
> + vdd-supply = <>;
> + };
> };
>
> _hs {
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 2/3] configs: stm32: enable USB onboard HUB driver
Hi Fabrice On 12/12/22 11:44, Fabrice Gasnier wrote: > Activate the USB onboard HUB driver, that is used to enable the HUB supply > on STM32MP15 EVAL, DK1 and DK2 boards. > This avoids marking the 3v3 corresponding regulator as always-on. > > Signed-off-by: Fabrice Gasnier > --- > > configs/stm32mp15_basic_defconfig | 1 + > configs/stm32mp15_defconfig | 1 + > configs/stm32mp15_trusted_defconfig | 1 + > 3 files changed, 3 insertions(+) > > diff --git a/configs/stm32mp15_basic_defconfig > b/configs/stm32mp15_basic_defconfig > index 86ebbef0a6c8..4d2ac589931a 100644 > --- a/configs/stm32mp15_basic_defconfig > +++ b/configs/stm32mp15_basic_defconfig > @@ -164,6 +164,7 @@ CONFIG_USB=y > CONFIG_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_ONBOARD_HUB=y > CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" > CONFIG_USB_GADGET_VENDOR_NUM=0x0483 > diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig > index caa79e68834f..ccf65dd12223 100644 > --- a/configs/stm32mp15_defconfig > +++ b/configs/stm32mp15_defconfig > @@ -140,6 +140,7 @@ CONFIG_USB=y > CONFIG_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_ONBOARD_HUB=y > CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" > CONFIG_USB_GADGET_VENDOR_NUM=0x0483 > diff --git a/configs/stm32mp15_trusted_defconfig > b/configs/stm32mp15_trusted_defconfig > index 3309c2e79246..a553038a42c5 100644 > --- a/configs/stm32mp15_trusted_defconfig > +++ b/configs/stm32mp15_trusted_defconfig > @@ -140,6 +140,7 @@ CONFIG_USB=y > CONFIG_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_ONBOARD_HUB=y > CONFIG_USB_GADGET=y > CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" > CONFIG_USB_GADGET_VENDOR_NUM=0x0483 Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH 1/3] usb: onboard-hub: add driver to manage onboard hub supplies
Hi,
On 12/12/22 11:44, Fabrice Gasnier wrote:
The main issue the driver addresses is that a USB hub needs to be
powered before it can be discovered. This is often solved by using
"regulator-always-on".
This driver is inspired by the Linux v6.1 driver. It only enables (or
disables) the hub vdd (3v3) supply, so it can be enumerated.
Scanning of the device tree is done in a similar manner to the sandbox,
by the usb-uclass. DT part looks like:
_ehci {
...
#address-cells = <1>;
#size-cells = <0>;
hub@1 {
compatible = "usb424,2514";
reg = <1>;
vdd-supply = <>;
};
};
When the bus gets probed, the driver is automatically probed/removed from
the bus tree, as an example on stm32:
STM32MP> usb start
starting USB...
STM32MP> dm tree
Class Index Probed DriverName
---
usb 0 [ + ] ehci_generic | |-- usb@5800d000
usb_hub 0 [ + ] usb_onboard_hub | | `-- hub@1
usb_hub 1 [ + ] usb_hub | | `-- usb_hub
STM32MP> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 2mA)
Signed-off-by: Fabrice Gasnier
---
common/Makefile | 1 +
common/usb_onboard_hub.c | 62 +++
drivers/usb/Kconfig | 10 ++
drivers/usb/host/usb-uclass.c | 16 +
4 files changed, 83 insertions(+), 6 deletions(-)
create mode 100644 common/usb_onboard_hub.c
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 1/3] usb: onboard-hub: add driver to manage onboard hub supplies
Hi Fabrice
On 12/12/22 11:44, Fabrice Gasnier wrote:
> The main issue the driver addresses is that a USB hub needs to be
> powered before it can be discovered. This is often solved by using
> "regulator-always-on".
>
> This driver is inspired by the Linux v6.1 driver. It only enables (or
> disables) the hub vdd (3v3) supply, so it can be enumerated.
> Scanning of the device tree is done in a similar manner to the sandbox,
> by the usb-uclass. DT part looks like:
>
> _ehci {
> ...
> #address-cells = <1>;
> #size-cells = <0>;
> hub@1 {
> compatible = "usb424,2514";
> reg = <1>;
> vdd-supply = <>;
> };
> };
>
> When the bus gets probed, the driver is automatically probed/removed from
> the bus tree, as an example on stm32:
> STM32MP> usb start
> starting USB...
> STM32MP> dm tree
> Class Index Probed DriverName
> ---
> usb 0 [ + ] ehci_generic | |-- usb@5800d000
> usb_hub 0 [ + ] usb_onboard_hub | | `-- hub@1
> usb_hub 1 [ + ] usb_hub | | `-- usb_hub
>
> STM32MP> usb tree
> USB device tree:
> 1 Hub (480 Mb/s, 0mA)
> | u-boot EHCI Host Controller
> |
> +-2 Hub (480 Mb/s, 2mA)
>
> Signed-off-by: Fabrice Gasnier
> ---
>
> common/Makefile | 1 +
> common/usb_onboard_hub.c | 62 +++
> drivers/usb/Kconfig | 10 ++
> drivers/usb/host/usb-uclass.c | 16 +
> 4 files changed, 83 insertions(+), 6 deletions(-)
> create mode 100644 common/usb_onboard_hub.c
>
> diff --git a/common/Makefile b/common/Makefile
> index 20addfb244c2..7789aab484fd 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_PHYLIB) += miiphyutil.o
> obj-$(CONFIG_USB_HOST) += usb.o usb_hub.o
> obj-$(CONFIG_USB_GADGET) += usb.o usb_hub.o
> obj-$(CONFIG_USB_STORAGE) += usb_storage.o
> +obj-$(CONFIG_USB_ONBOARD_HUB) += usb_onboard_hub.o
>
> # others
> obj-$(CONFIG_CONSOLE_MUX) += iomux.o
> diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
> new file mode 100644
> index ..89e18a2ddad6
> --- /dev/null
> +++ b/common/usb_onboard_hub.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Driver for onboard USB hubs
> + *
> + * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
> + *
> + * Mostly inspired by Linux kernel v6.1 onboard_usb_hub driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct onboard_hub {
> + struct udevice *vdd;
> +};
> +
> +static int usb_onboard_hub_probe(struct udevice *dev)
> +{
> + struct onboard_hub *hub = dev_get_priv(dev);
> + int ret;
> +
> + ret = device_get_supply_regulator(dev, "vdd-supply", >vdd);
> + if (ret) {
> + dev_err(dev, "can't get vdd-supply: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regulator_set_enable_if_allowed(hub->vdd, true);
> + if (ret)
> + dev_err(dev, "can't enable vdd-supply: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int usb_onboard_hub_remove(struct udevice *dev)
> +{
> + struct onboard_hub *hub = dev_get_priv(dev);
> + int ret;
> +
> + ret = regulator_set_enable_if_allowed(hub->vdd, false);
> + if (ret)
> + dev_err(dev, "can't disable vdd-supply: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static const struct udevice_id usb_onboard_hub_ids[] = {
> + /* Use generic usbVID,PID dt-bindings (usb-device.yaml) */
> + { .compatible = "usb424,2514" }, /* USB2514B USB 2.0 */
> + { }
> +};
> +
> +U_BOOT_DRIVER(usb_onboard_hub) = {
> + .name = "usb_onboard_hub",
> + .id = UCLASS_USB_HUB,
> + .probe = usb_onboard_hub_probe,
> + .remove = usb_onboard_hub_remove,
> + .of_match = usb_onboard_hub_ids,
> + .priv_auto = sizeof(struct onboard_hub),
> +};
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 3afb45d5ccb2..d10ee6853d40 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -106,6 +106,16 @@ config USB_KEYBOARD
> Say Y here if you want to use a USB keyboard for U-Boot command line
> input.
>
> +config USB_ONBOARD_HUB
> + bool "Onboard USB hub support"
> + depends on DM_USB
> + ---help---
> + Say Y here if you want to support discrete onboard USB hubs that
> + don't require an additional control bus for initialization, but
> + need some non-trivial form of initialization, such as enabling a
> + power regulator. An example for such a hub is the Microchip
> + USB2514B.
> +
> if USB_KEYBOARD
>
> config USB_KEYBOARD_FN_KEYS
> diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
> index 060f3441df0c..f5dc93ffee39 100644
> --- a/drivers/usb/host/usb-uclass.c
> +++ b/drivers/usb/host/usb-uclass.c
> @@
Re: [PATCH 0/3] cmd: pxe: support INITRD and FDT selection with FIT
Hi Patrick,
On 1/3/23 17:10, Patrick DELAUNAY wrote:
On 12/13/22 15:48, Quentin Schulz wrote:
Hi Patrick,
On 12/13/22 15:34, neil.armstr...@linaro.org wrote:
On 13/12/2022 15:31, Patrick DELAUNAY wrote:
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check
fdtcontroladdr
in label_boot") the FDT or the FDTDIR label is required in
extlinux.conf
and the fallback done by bootm command when only the device tree
is present
in this command parameters is no more performed when FIT is used
for
kernel.
The next file "extlinux.conf" no more selects the device tree in
FIT
but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode
DEFAULT test
LABEL test
KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf
by using FDT label with the same string.
menu title Select the boot mode
DEFAULT test
LABEL test
KERNEL /fitImage
FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode
DEFAULT test
LABEL test
KERNEL /fitImage#config
FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following:
What happens for old releases (pre-v2022.04) where KERNEL worked
just fine without the FDT to load the fdt from the fitimage conf
specified in KERNEL field? Would we now need to keep an
extlinux.conf for pre-2022.04 releases where FDT wouldn't be set
and one for 2023.01 and later where FDT would be mentioned? That
does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without
spending significant effort patching v2022.01 to get it to work
on our Puma module. Does anyone have access to a board to quickly
check an extlinux.conf with KERNEL and FDT set to /fitImage on a
v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01,
I'll test with FDT set to /fitImage to see if it breaks.
It breaks:
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1: Yocto
Retrieving file: /fitImage
append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200
Retrieving file: /fitImage
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my
patch ?
It was explicitly without your patch as Quentin asked, he hoped addingh
"FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
Your implementation requires changes in extlinux.conf (which could be
fine, I'm not arguing about this specifically). I however think we
need those required changes to be backward compatible with older U-Boot.
This means, a new extlinux.conf that works on newer U-Boot should also
work on older U-Boot without your patch.
Otherwise, we would have the following:
U-Boot \ extlinux.conf || old | new
old || OK | NOK
new || NOK | OK
What I am hoping for is:
U-Boot \ extlinux.conf || old | new
old || OK | OK
new || NOK | OK
or even fix the support for new U-Boot with old extlinux.conf (but
that seems not possible because how d5ba6188dfbf ("cmd: pxe_utils:
Check fdtcontroladdr in label_boot") works?).
Yes but I don't see any possible solution to solve all the combination
with d5ba6188dfbf and without or without FIT:
the old extlinux.conf with FIT are already no more working as expected
with current U-Boot (1)
when FDT and FDTDIR are absent
extlinux.conf || kernel = uImage | kernel= FIT |
kernel = FIT
|| FDT absent | FDT absent | FDT =
FIT (my proposal)
U-Boot <= v2022.01-rc2 || KO | OK using DT in FIT | not
supported
U-Boot >= 2022.01-rc3 || OK (1) | OK(2)using U-Boot DT | not
supported
next with my proposal || OK (1) | OK(2)using U-Boot DT | OK
(using DT in FIT)
(1) with d5ba6188dfbf
(2) Risk to have unaligned DT between U-Boot (old) and kernel (new)
=> U-Boot behavior change with 2022.01-rc3(1)
This would give an easy migration path to any creator of this
extlinux.conf file by just migrating to the new format while not
requiring it to care about the version of U-Boot being used.
I agree, it is better to be backward compatible.
So I search a solution to keep the new feature introduced by
d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") but
only when FIT is not used
Re: [PATCH] ARM: dts: stm32: update vbus-supply of usbphyc_port0 on stm32mp157c-ev1
Hi,
On 12/12/22 11:32, Fabrice Gasnier wrote:
phy-stm32-usbphyc bindings uses a connector node with vbus-supply
property.
[backport from linux 43e55d778a6b]
Signed-off-by: Fabrice Gasnier
---
arch/arm/dts/stm32mp157c-ev1.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index 07bcd7c50672..2d5db41ed67b 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -393,6 +393,10 @@
st,tune-squelch-level = <3>;
st,tune-hs-rx-offset = <2>;
st,no-lsfs-sc;
+ connector {
+ compatible = "usb-a-connector";
+ vbus-supply = <_sw>;
+ };
};
_port1 {
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 0/3] cmd: pxe: support INITRD and FDT selection with FIT
On 12/13/22 15:48, Quentin Schulz wrote:
Hi Patrick,
On 12/13/22 15:34, neil.armstr...@linaro.org wrote:
On 13/12/2022 15:31, Patrick DELAUNAY wrote:
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check
fdtcontroladdr
in label_boot") the FDT or the FDTDIR label is required in
extlinux.conf
and the fallback done by bootm command when only the device tree
is present
in this command parameters is no more performed when FIT is used
for
kernel.
The next file "extlinux.conf" no more selects the device tree in
FIT
but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode
DEFAULT test
LABEL test
KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf
by using FDT label with the same string.
menu title Select the boot mode
DEFAULT test
LABEL test
KERNEL /fitImage
FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode
DEFAULT test
LABEL test
KERNEL /fitImage#config
FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following:
What happens for old releases (pre-v2022.04) where KERNEL worked
just fine without the FDT to load the fdt from the fitimage conf
specified in KERNEL field? Would we now need to keep an
extlinux.conf for pre-2022.04 releases where FDT wouldn't be set
and one for 2023.01 and later where FDT would be mentioned? That
does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without
spending significant effort patching v2022.01 to get it to work
on our Puma module. Does anyone have access to a board to quickly
check an extlinux.conf with KERNEL and FDT set to /fitImage on a
v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01,
I'll test with FDT set to /fitImage to see if it breaks.
It breaks:
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1: Yocto
Retrieving file: /fitImage
append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200
Retrieving file: /fitImage
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my
patch ?
It was explicitly without your patch as Quentin asked, he hoped addingh
"FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
Your implementation requires changes in extlinux.conf (which could be
fine, I'm not arguing about this specifically). I however think we
need those required changes to be backward compatible with older U-Boot.
This means, a new extlinux.conf that works on newer U-Boot should also
work on older U-Boot without your patch.
Otherwise, we would have the following:
U-Boot \ extlinux.conf || old | new
old || OK | NOK
new || NOK | OK
What I am hoping for is:
U-Boot \ extlinux.conf || old | new
old || OK | OK
new || NOK | OK
or even fix the support for new U-Boot with old extlinux.conf (but
that seems not possible because how d5ba6188dfbf ("cmd: pxe_utils:
Check fdtcontroladdr in label_boot") works?).
Yes but I don't see any possible solution to solve all the combination
with d5ba6188dfbf and without or without FIT:
the old extlinux.conf with FIT are already no more working as expected
with current U-Boot (1)
when FDT and FDTDIR are absent
extlinux.conf || kernel = uImage | kernel= FIT |
kernel = FIT
|| FDT absent | FDT absent | FDT =
FIT (my proposal)
U-Boot <= v2022.01-rc2 || KO | OK using DT in FIT | not
supported
U-Boot >= 2022.01-rc3 || OK (1) | OK(2)using U-Boot DT | not
supported
next with my proposal || OK (1) | OK(2)using U-Boot DT | OK
(using DT in FIT)
(1) with d5ba6188dfbf
(2) Risk to have unaligned DT between U-Boot (old) and kernel (new)
=> U-Boot behavior change with 2022.01-rc3(1)
This would give an easy migration path to any creator of this
extlinux.conf file by just migrating to the new format while not
requiring it to care about the version of U-Boot being used.
I agree, it is better to be backward compatible.
So I search a solution to keep the new feature introduced by
d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") but
only when FIT is not used and fallback to previous behavior for FIT
but it
Re: [PATCH 2/4] usb: ohci-at91: Enable OHCI functionality and register into DM
On 1/3/23 17:01, sergiu.m...@microchip.com wrote:
On 03.01.2023 17:57, Marek Vasut wrote:
On 1/3/23 16:49, sergiu.m...@microchip.com wrote:
On 03.01.2023 16:34, Marek Vasut wrote:
On 1/3/23 13:11, sergiu.m...@microchip.com wrote:
On 03.01.2023 01:26, Marek Vasut wrote:
On 12/23/22 13:34, Sergiu Moga wrote:
[...]
diff --git a/drivers/usb/host/ohci-at91.c
b/drivers/usb/host/ohci-at91.c
index 9b955c1bd6..9ae55c6e5d 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -5,6 +5,9 @@
*/
#include
+
+#if !(CONFIG_IS_ENABLED(DM_USB))
+
#include
int usb_cpu_init(void)
@@ -62,3 +65,183 @@ int usb_cpu_init_fail(void)
{
return usb_cpu_stop();
}
Would it be possible to just remove the non-DM functionality ?
Unfortunately, the other older boards would not build and work anymore
if I were to remove this.
Any chance they can be converted to DM ?
Not at the moment, no.
Why ?
My apologies, but I do not have these boards at my disposal to test them
and they are not the focus of this patch series. The reason I kept the
non-DM part is that so the build on the other boards does not break.
Perhaps in the future there will be plans to convert these as well but
at the moment I can not say for sure.
No need to apologize. Can you add a comment into the commit message,
explaining this ?
Re: [PATCH 2/4] usb: ohci-at91: Enable OHCI functionality and register into DM
On 03.01.2023 17:57, Marek Vasut wrote:
> On 1/3/23 16:49, sergiu.m...@microchip.com wrote:
>> On 03.01.2023 16:34, Marek Vasut wrote:
>>> On 1/3/23 13:11, sergiu.m...@microchip.com wrote:
On 03.01.2023 01:26, Marek Vasut wrote:
> On 12/23/22 13:34, Sergiu Moga wrote:
>
> [...]
>
>> diff --git a/drivers/usb/host/ohci-at91.c
>> b/drivers/usb/host/ohci-at91.c
>> index 9b955c1bd6..9ae55c6e5d 100644
>> --- a/drivers/usb/host/ohci-at91.c
>> +++ b/drivers/usb/host/ohci-at91.c
>> @@ -5,6 +5,9 @@
>> */
>>
>> #include
>> +
>> +#if !(CONFIG_IS_ENABLED(DM_USB))
>> +
>> #include
>>
>> int usb_cpu_init(void)
>> @@ -62,3 +65,183 @@ int usb_cpu_init_fail(void)
>> {
>> return usb_cpu_stop();
>> }
>
> Would it be possible to just remove the non-DM functionality ?
>
Unfortunately, the other older boards would not build and work anymore
if I were to remove this.
>>>
>>> Any chance they can be converted to DM ?
>>>
>>
>> Not at the moment, no.
>
> Why ?
My apologies, but I do not have these boards at my disposal to test them
and they are not the focus of this patch series. The reason I kept the
non-DM part is that so the build on the other boards does not break.
Perhaps in the future there will be plans to convert these as well but
at the moment I can not say for sure.
Re: [PATCH v2 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes
On 1/3/23 16:56, sergiu.m...@microchip.com wrote:
On 03.01.2023 17:47, Marek Vasut wrote:
On 1/3/23 16:35, Sergiu Moga wrote:
Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.
Signed-off-by: Sergiu Moga
---
v1 -> v2:
- use usb@
arch/arm/dts/sam9x60.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 17224ef771..4fcfb5c597 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,24 @@
#size-cells = <1>;
ranges;
+ usb1: usb@60 {
+ compatible = "atmel,at91rm9200-ohci", "usb-ohci";
+ reg = <0x0060 0x10>;
+ clocks = < PMC_TYPE_PERIPHERAL 22>, <
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
./scripts/checkpatch.pl on this patch indicates
WARNING: line length of 121 exceeds 100 columns
#93: FILE: arch/arm/dts/sam9x60.dtsi:75:
+ clocks = < PMC_TYPE_PERIPHERAL 22>, <
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
Please run checkpatch on all your patches.
Also, wait a few days before sending V2 , no need to send V2 immediately
while review of V1 is still ongoing.
It was my understanding that exceeding the character per line limit on
DT's is acceptable. All of our DT's are like this.
Not to my knowledge or per what is in other DTs.
Is that some exception here ?
Re: [PATCH v2 4/9] dt-bindings: reset: add sama7g5 definitions
On 1/3/23 16:55, sergiu.m...@microchip.com wrote: On 03.01.2023 17:48, Marek Vasut wrote: On 1/3/23 16:35, Sergiu Moga wrote: Upstream linux commit 5994f58977e0. Add reset bindings for SAMA7G5. At the moment only USB PHYs are included. Signed-off-by: Sergiu Moga --- v1 -> v2: - nothing include/dt-bindings/reset/sama7g5-reset.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 include/dt-bindings/reset/sama7g5-reset.h diff --git a/include/dt-bindings/reset/sama7g5-reset.h b/include/dt-bindings/reset/sama7g5-reset.h new file mode 100644 index 00..2116f41d04 --- /dev/null +++ b/include/dt-bindings/reset/sama7g5-reset.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ + +#ifndef __DT_BINDINGS_RESET_SAMA7G5_H +#define __DT_BINDINGS_RESET_SAMA7G5_H + +#define SAMA7G5_RESET_USB_PHY1 4 +#define SAMA7G5_RESET_USB_PHY2 5 +#define SAMA7G5_RESET_USB_PHY3 6 Is there no reset with ID 0/1/2/3 ? No, there is not. Please just add a comment into the file then, explaining that.
Re: [PATCH 4/6] ARM: dts: at91: sama7: Add USB related DT nodes
On 1/3/23 16:53, sergiu.m...@microchip.com wrote: On 03.01.2023 16:35, Marek Vasut wrote: On 1/3/23 12:53, sergiu.m...@microchip.com wrote: On 03.01.2023 01:07, Marek Vasut wrote: On 12/23/22 13:33, Sergiu Moga wrote: Add the USB related DT nodes for the sama7g5ek board. Signed-off-by: Sergiu Moga --- arch/arm/dts/at91-sama7g5ek.dts | 34 +++ Board DT and SoC DT should be separate patches. Are these DT changes part of upstream Linux yet ? No, but they will be integrated in the future. Were the patches at least posted ? If not, add the nodes into at91-sama7g5ek-u-boot.dtsi , so it is clear this is temporarily U-Boot specific. I am sorry, I somehow did not receive these replies before sending v2. Sure thing, I will try moving them there. Yes, I was still in the process of handling V1, just wait a few days before sending Vx of patches to give reviews time to review and comment.
Re: [PATCH 2/4] usb: ohci-at91: Enable OHCI functionality and register into DM
On 1/3/23 16:49, sergiu.m...@microchip.com wrote:
On 03.01.2023 16:34, Marek Vasut wrote:
On 1/3/23 13:11, sergiu.m...@microchip.com wrote:
On 03.01.2023 01:26, Marek Vasut wrote:
On 12/23/22 13:34, Sergiu Moga wrote:
[...]
diff --git a/drivers/usb/host/ohci-at91.c
b/drivers/usb/host/ohci-at91.c
index 9b955c1bd6..9ae55c6e5d 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -5,6 +5,9 @@
*/
#include
+
+#if !(CONFIG_IS_ENABLED(DM_USB))
+
#include
int usb_cpu_init(void)
@@ -62,3 +65,183 @@ int usb_cpu_init_fail(void)
{
return usb_cpu_stop();
}
Would it be possible to just remove the non-DM functionality ?
Unfortunately, the other older boards would not build and work anymore
if I were to remove this.
Any chance they can be converted to DM ?
Not at the moment, no.
Why ?
Re: [PATCH v2 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes
On 03.01.2023 17:47, Marek Vasut wrote:
> On 1/3/23 16:35, Sergiu Moga wrote:
>> Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.
>>
>> Signed-off-by: Sergiu Moga
>> ---
>>
>> v1 -> v2:
>> - use usb@
>>
>> arch/arm/dts/sam9x60.dtsi | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
>> index 17224ef771..4fcfb5c597 100644
>> --- a/arch/arm/dts/sam9x60.dtsi
>> +++ b/arch/arm/dts/sam9x60.dtsi
>> @@ -69,6 +69,24 @@
>> #size-cells = <1>;
>> ranges;
>>
>> + usb1: usb@60 {
>> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
>> + reg = <0x0060 0x10>;
>> + clocks = < PMC_TYPE_PERIPHERAL 22>, <
>> PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
>
> ./scripts/checkpatch.pl on this patch indicates
>
> WARNING: line length of 121 exceeds 100 columns
> #93: FILE: arch/arm/dts/sam9x60.dtsi:75:
> + clocks = < PMC_TYPE_PERIPHERAL 22>, <
> PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
>
> Please run checkpatch on all your patches.
>
> Also, wait a few days before sending V2 , no need to send V2 immediately
> while review of V1 is still ongoing.
It was my understanding that exceeding the character per line limit on
DT's is acceptable. All of our DT's are like this.
Re: [PATCH v2 4/9] dt-bindings: reset: add sama7g5 definitions
On 03.01.2023 17:48, Marek Vasut wrote: > On 1/3/23 16:35, Sergiu Moga wrote: >> Upstream linux commit 5994f58977e0. >> >> Add reset bindings for SAMA7G5. At the moment only USB PHYs are >> included. >> >> Signed-off-by: Sergiu Moga >> --- >> >> v1 -> v2: >> - nothing >> >> >> include/dt-bindings/reset/sama7g5-reset.h | 10 ++ >> 1 file changed, 10 insertions(+) >> create mode 100644 include/dt-bindings/reset/sama7g5-reset.h >> >> diff --git a/include/dt-bindings/reset/sama7g5-reset.h >> b/include/dt-bindings/reset/sama7g5-reset.h >> new file mode 100644 >> index 00..2116f41d04 >> --- /dev/null >> +++ b/include/dt-bindings/reset/sama7g5-reset.h >> @@ -0,0 +1,10 @@ >> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ >> + >> +#ifndef __DT_BINDINGS_RESET_SAMA7G5_H >> +#define __DT_BINDINGS_RESET_SAMA7G5_H >> + >> +#define SAMA7G5_RESET_USB_PHY1 4 >> +#define SAMA7G5_RESET_USB_PHY2 5 >> +#define SAMA7G5_RESET_USB_PHY3 6 > > Is there no reset with ID 0/1/2/3 ? No, there is not.
Re: [PATCH 4/6] ARM: dts: at91: sama7: Add USB related DT nodes
On 03.01.2023 16:35, Marek Vasut wrote: > On 1/3/23 12:53, sergiu.m...@microchip.com wrote: >> On 03.01.2023 01:07, Marek Vasut wrote: >>> On 12/23/22 13:33, Sergiu Moga wrote: Add the USB related DT nodes for the sama7g5ek board. Signed-off-by: Sergiu Moga --- arch/arm/dts/at91-sama7g5ek.dts | 34 +++ >>> >>> Board DT and SoC DT should be separate patches. >>> >>> Are these DT changes part of upstream Linux yet ? >>> >> >> >> No, but they will be integrated in the future. > > Were the patches at least posted ? > > If not, add the nodes into at91-sama7g5ek-u-boot.dtsi , so it is clear > this is temporarily U-Boot specific. I am sorry, I somehow did not receive these replies before sending v2. Sure thing, I will try moving them there.
Re: [PATCH 2/4] usb: ohci-at91: Enable OHCI functionality and register into DM
On 03.01.2023 16:34, Marek Vasut wrote:
> On 1/3/23 13:11, sergiu.m...@microchip.com wrote:
>> On 03.01.2023 01:26, Marek Vasut wrote:
>>> On 12/23/22 13:34, Sergiu Moga wrote:
>>>
>>> [...]
>>>
diff --git a/drivers/usb/host/ohci-at91.c
b/drivers/usb/host/ohci-at91.c
index 9b955c1bd6..9ae55c6e5d 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -5,6 +5,9 @@
*/
#include
+
+#if !(CONFIG_IS_ENABLED(DM_USB))
+
#include
int usb_cpu_init(void)
@@ -62,3 +65,183 @@ int usb_cpu_init_fail(void)
{
return usb_cpu_stop();
}
>>>
>>> Would it be possible to just remove the non-DM functionality ?
>>>
>>
>> Unfortunately, the other older boards would not build and work anymore
>> if I were to remove this.
>
> Any chance they can be converted to DM ?
>
Not at the moment, no.
+#elif CONFIG_IS_ENABLED(DM_GPIO)
>>>
>>> I think you want plain '#else' here, and then make the driver select
>>> DM_GPIO in case DM_USB is enabled in Kconfig entry.
>>>
+#include
+#include
+#include
+#include
+#include "ohci.h"
+
+#define AT91_MAX_USBH_PORTS 3
+#define at91_for_each_port(index) \
+ for ((index) = 0; (index) < AT91_MAX_USBH_PORTS;
(index)++)
+
+struct at91_usbh_data {
+ enum usb_init_type init_type;
+ struct gpio_desc vbus_pin[AT91_MAX_USBH_PORTS];
>>>
>>> drivers/usb/host/ehci-generic.c: ret =
>>> device_get_supply_regulator(dev, "vbus-supply",
>>>
>>> I wonder if we can instead use regulator for vbus-supply here too ?
>>>
>>
>> I would rather keep the same DT properties as those in Linux and have
>> them be in concordance with our USB DT binding, which specifies the
>> atmel,vbus-gpio property and no vbus-supply.
>
> Oh well, so yes, we're stuck with this GPIO stuff.
>
> [...]
Unfortunately yes...
Re: [PATCH v2 4/9] dt-bindings: reset: add sama7g5 definitions
On 1/3/23 16:35, Sergiu Moga wrote: Upstream linux commit 5994f58977e0. Add reset bindings for SAMA7G5. At the moment only USB PHYs are included. Signed-off-by: Sergiu Moga --- v1 -> v2: - nothing include/dt-bindings/reset/sama7g5-reset.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 include/dt-bindings/reset/sama7g5-reset.h diff --git a/include/dt-bindings/reset/sama7g5-reset.h b/include/dt-bindings/reset/sama7g5-reset.h new file mode 100644 index 00..2116f41d04 --- /dev/null +++ b/include/dt-bindings/reset/sama7g5-reset.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ + +#ifndef __DT_BINDINGS_RESET_SAMA7G5_H +#define __DT_BINDINGS_RESET_SAMA7G5_H + +#define SAMA7G5_RESET_USB_PHY1 4 +#define SAMA7G5_RESET_USB_PHY2 5 +#define SAMA7G5_RESET_USB_PHY3 6 Is there no reset with ID 0/1/2/3 ?
Re: [PATCH v2 1/9] ARM: dts: sam9x60: Add OHCI and EHCI DT nodes
On 1/3/23 16:35, Sergiu Moga wrote:
Add the OHCI and EHCI DT nodes for the sam9x60 SoC's.
Signed-off-by: Sergiu Moga
---
v1 -> v2:
- use usb@
arch/arm/dts/sam9x60.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index 17224ef771..4fcfb5c597 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,24 @@
#size-cells = <1>;
ranges;
+ usb1: usb@60 {
+ compatible = "atmel,at91rm9200-ohci", "usb-ohci";
+ reg = <0x0060 0x10>;
+ clocks = < PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_PERIPHERAL
22>, < PMC_TYPE_SYSTEM 21>;
./scripts/checkpatch.pl on this patch indicates
WARNING: line length of 121 exceeds 100 columns
#93: FILE: arch/arm/dts/sam9x60.dtsi:75:
+ clocks = < PMC_TYPE_PERIPHERAL 22>, <
PMC_TYPE_PERIPHERAL 22>, < PMC_TYPE_SYSTEM 21>;
Please run checkpatch on all your patches.
Also, wait a few days before sending V2 , no need to send V2 immediately
while review of V1 is still ongoing.
Re: [PATCH v2 3/3] usb: ohci-at91: Add USB PHY functionality
On 1/3/23 15:30, Sergiu Moga wrote:
Add the ability to enable/disable whatever USB PHY's are
passed to the AT91 OHCI driver through DT.
Signed-off-by: Sergiu Moga
Tested-by: Mihai Sain
---
v1 -> v2:
- use *_bulk API's
drivers/usb/host/ohci-at91.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9de67df335..fece921d39 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -74,6 +74,10 @@ int usb_cpu_init_fail(void)
#include
#include "ohci.h"
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+#include
+#endif
+
#define AT91_MAX_USBH_PORTS3
#define at91_for_each_port(index, ports) \
@@ -90,15 +94,35 @@ struct at91_usbh_data {
struct ohci_at91_priv {
ohci_t ohci;
struct clk_bulk clks;
+
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+ struct phy_bulk phys;
+#endif
};
static int at91_start_clock(struct ohci_at91_priv *ohci_at91)
{
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
if (CONFIG_IS_ENABLED(...)) please.
[...]
Re: [PATCH v2 2/3] usb: ohci-at91: Enable OHCI functionality and register into DM
On 1/3/23 15:30, Sergiu Moga wrote:
[...]
+static int ohci_atmel_probe(struct udevice *dev)
+{
+ struct at91_usbh_data *pdata = dev_get_plat(dev);
+ struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+ u32 i;
+ int ret;
+ struct ohci_regs *regs = (struct ohci_regs *)dev_read_addr(dev);
Use one space after type for indent.
Also, I think the dev_read_addr() can fail, so you want to check the
return value.
+ pdata->ports = dev_read_u32_default(dev, "num-ports", 3);
+
+ at91_for_each_port(i, pdata->ports)
+ gpio_request_by_name(dev, "atmel,vbus-gpio", i,
+>vbus_pin[i], GPIOD_IS_OUT |
+GPIOD_IS_OUT_ACTIVE);
+
+ ret = clk_get_bulk(dev, _at91->clks);
+ if (ret)
+ goto fail;
+
+ ret = clk_enable_bulk(_at91->clks);
+ if (ret)
+ goto fail;
+
+ ret = at91_start_hc(dev);
+ if (ret)
+ goto fail;
+
+ return ohci_register(dev, regs);
+
+fail:
+ at91_for_each_port(i, pdata->ports)
+ if (dm_gpio_is_valid(>vbus_pin[i]))
+ gpio_free(pdata->vbus_pin[i].offset);
Add clk_disable in case of failure after at91_start_hc , please check
all the fail paths one more time.
[...]
