Re: [PATCH v3 0/6] Add video drivers for endeavoru and p880/p895
On Tue, 25 Apr 2023 10:51:41 +0300 Svyatoslav Ryhel clamo...@gmail.com wrote: ... > --- > Changes from v2: > - added comments to panel drivers > - fixed typo in ssd2825 driver > > Changes from v1: > - used lower-case hex for command sequences > - ssd2825 switched to dm_spi_xfer > - used log_* instead of printf > - tweaked lm3533 help description > > --- > > Svyatoslav Ryhel (6): > video: add lm3533 backlight driver > video: bridge: add Solomon SSD2825 DSI/LVDS driver > video: panel: add Renesas R61307 MIPI DSI panel driver > video: panel: add Renesas R69328 MIPI DSI panel driver > video: tegra: add DC based PWM backlight driver > video: panel: add generic endeavoru panel > > drivers/video/Kconfig | 38 ++ > drivers/video/Makefile | 4 + > drivers/video/bridge/Kconfig| 7 + > drivers/video/bridge/Makefile | 1 + > drivers/video/bridge/ssd2825.c | 520 > drivers/video/endeavoru-panel.c | 252 ++ > drivers/video/lm3533_backlight.c| 134 + > drivers/video/renesas-r61307.c | 302 > drivers/video/renesas-r69328.c | 238 + > drivers/video/tegra20/Kconfig | 7 + > drivers/video/tegra20/Makefile | 1 + > drivers/video/tegra20/tegra-pwm-backlight.c | 155 ++ > 12 files changed, 1659 insertions(+) > create mode 100644 drivers/video/bridge/ssd2825.c > create mode 100644 drivers/video/endeavoru-panel.c > create mode 100644 drivers/video/lm3533_backlight.c > create mode 100644 drivers/video/renesas-r61307.c > create mode 100644 drivers/video/renesas-r69328.c > create mode 100644 drivers/video/tegra20/tegra-pwm-backlight.c Patch series applied to u-boot-video/master, thanks! -- Anatolij
Re: [EXTERNAL] [PATCH v3 15/43] video: Allow building video drivers for SPL
Hi Simon, On 05/05/23 04:28, Simon Glass wrote: Update the Makefile rules to allow video drivers in SPL. This is useful for 64-bit QEMU on x86, since the video BIOS can only be run from 32-bit mode (i.e. in SPL). Signed-off-by: Simon Glass --- (no changes since v1) drivers/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Please rebase on this patch. https://lore.kernel.org/u-boot/20230420121112.311922-4-n-ja...@ti.com/ I had added obj-$(CONFIG_SPL_VIDEO) +=video/ to build video driver when TPL and VPL are not defined and only SPL is defined. You may have to remove this and add it for all stages. Thanks, Nikhil
Re: [PATCH v2 2/3] Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On 10:27-20230508, Vignesh Raghavendra wrote: > > > On 08/05/23 10:21, Manorit Chawdhry wrote: > > Hi Nishanth, > > > > On 08:45-20230505, Nishanth Menon wrote: > >> Manorit, > >> > >> On 20:59-20230504, Tom Rini wrote: > >>> On Thu, May 04, 2023 at 11:07:07AM +0530, Manorit Chawdhry wrote: > >>> > On K3 HS-SE devices all the firewalls are locked by default > until sysfw comes up. Rom configures some of the firewall for its usage > along with the SRAM for R5 but the PSRAM region is still locked. > > The K3 MCU Scratchpad for j721s2 was set to a PSRAM region triggering the > firewall exception before sysfw came up. The exception started happening > after adding multi dtb support that accesses the scratchpad for reading > EEPROM contents. > > Old map: > ┌─┐ 0x41c0 > │ SPL │ > ├─┤ 0x41c61f20 (approx) > │STACK│ > ├─┤ 0x41c65f20 > │ Global data │ > │ sizeof(struct global_data) = 0xd8 │ > ├─┤ gd->malloc_base = 0x41c66000 > │HEAP │ > │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ > ├─┤ CONFIG_SPL_BSS_START_ADDR > │ SPL BSS │ (0x41c76000) > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ > ├─┤ (0x41c8) > │ DM DATA │ > ├─┤ (0x41c84130) (approx) > │EMPTY│ > └─┘ > CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX > (0x41cffbfc) > > New map: > ┌─┐ 0x41c0 > │ SPL │ > ├─┤ 0x41c61f20 (approx) > │STACK│ > ├─┤ 0x41c65f20 > │ Global data │ > │ sizeof(struct global_data) = 0xd8 │ > ├─┤ gd->malloc_base = 0x41c66000 > │HEAP │ > │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ > ├─┤ CONFIG_SPL_BSS_START_ADDR > │ SPL BSS │ (0x41c76000) > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ > ├─┤ (0x41c8) > │ DM DATA │ > ├─┤ (0x41c84130) (approx) > │EMPTY│ > ├─┤ SYS_K3_MCU_SCRATCHPAD_BASE > │ SCRATCHPAD │ (0x41cff9fc) > │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │ > └─┘ > CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX > (0x41cffbfc) > > Reviewed-by: Kamlesh Gurudasani > Signed-off-by: Manorit Chawdhry > >>> Applied to u-boot/master, thanks! > >> > >> I just finally caught up with this patch, Sorry for the late > >> response-> Thank you for clearly elaborating this in commit message, > >> BUT: > >> > >> Can we start documenting this in rst after we have incorporated the > >> binman changes? The memory map on the SRAM is a black magic(at least > >> for me) that needs explanation in a single doc without needing to dig > >> through commit messages and variables and defconfigs.. > >> > >> Documentation should clearly indicate what parameters from: > >> * binman configuration. > >> * various config header files > >> * defconfig > >> > >> We should explain the rationale, variations (HS-SE for example: if any > >> or if not any) - including risks such as stack-heap collisions. Any > >> interplay with firmware components in the heterogenous system that folks > >> need to be careful about needs to be called out as well. > >> > > Thanks for the insights! Queueing this up when binman get merged. > > Would be good to let me know a place also to document all this as I > > couldn't find any j721s2 specific documentation, I believe these things > > can become device specific also based on the requirements as j721s2 and > > j721e have a different map of SPL for them. > > doc/board/ti/ is the right place IMO. We need an equivalent for > j721e_evm.rst which explains combined image boot flow and SRAM layout > for J721s2 / j784s4 (and possibly same for J7200)? > > Regards > Vignesh > Thanks Vignesh, would do the needful. Regards, Manorit > > -- > Regards > Vignesh
Re: [PATCH v3 00/19] Migration to using binman for bootloader
Hi Jan,
On 07/05/23 17:41, Jan Kiszka wrote:
On 04.05.23 08:13, Neha Malcom Francis wrote:
Hi Jan
On 04/05/23 10:13, Neha Malcom Francis wrote:
Hi Jan,
On 03/05/23 22:04, Jan Kiszka wrote:
On 03.05.23 14:56, Neha Malcom Francis wrote:
Hi Jan,
On 03/05/23 12:57, Neha Malcom Francis wrote:
Hi Tom
On 27/04/23 04:07, Tom Rini wrote:
On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote:
This series aims to eliminate the use of additional custom
repositories
such as k3-image-gen (K3 Image Generation) repo and
core-secdev-k3 (K3
Security Development Tools) that was plumbed into the U-Boot
build flow
to generate boot images for TI K3 platform devices. And instead, we
move
towards using binman that aligns better with the community standard
build
flow.
This series uses binman for all K3 platforms supported on U-Boot
currently;
both HS (High Security, both SE and FS) and GP (General Purpose)
devices.
Background on using k3-image-gen:
* TI K3 devices require a SYSFW (System Firmware) image
consisting
of a signed system firmware image and board configuration
binaries,
this is needed to bring up system firmware during U-Boot R5 SPL
startup.
* Board configuration data contain board-specific information
such as resource management, power management and security.
Background on using core-secdev-k3:
* Contains resources to sign x509 certificates for HS devices
Series intends to use binman to take over the packaging and
signing for
the R5 bootloader images tiboot3.bin (and sysfw.itb, for
non-combined
boot flow) instead of k3-image-gen.
Series also packages the A72/A53 bootloader images (tispl.bin and
u-boot.img) using ATF, OPTEE and DM (Device Manager)
So, next up is fixing this in CI. After taking Andrew's patch to
fix the
typedef issue, and after my patches to ensure we can get
pyyaml/jsonschema for python, there's problems still:
Thanks for checking this! Couple things:
Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966:
binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in
input
path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts)
(cwd='/tmp/.bm-work/j721s2_hs_evm_a72')
1. This is dependent on the patch merging J721S2 HS and GP configs
[1]. However it has been reverted on -next, seen in the same thread.
And then:
https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328
Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error
I've fixed this, minor but serious change.
2. Regarding iot2050, build fails since it uses
arch/arm/mach-k3/config.mk which is now entirely binman based. Will
try moving iot2050 to binman as well.
I'll need some help with this, might need to know the bootloader
flow to
make a clean migration.
Where do I have to look at? Is there a git repo with that experiment
somewhere?
Jan
There's no experiment yet, I will send one today; but I do not have
complete understanding of the booting; whether the tispl.bin (which I
assume is the only boot component that is affecting iot2050 boot since
k3_fit_atf.sh is no longer there) has any concept of signing? Is
core-secdev-k3 ever used?
I have a tree posted here [2] that builds flash.bin with no error for
me. Please confirm whether your build flow does the same and also let me
know if the binary actually boots.
[2]
https://github.com/nehamalcom/u-boot/tree/migration-to-binman-cicd-iot2050
I've tested the latest version in that branch in the meantime. It
compiles but it does not work. This is missing from the original script:
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index e17ffd7481f..9d83898d33f 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -92,6 +92,15 @@
};
};
};
+
+ configurations {
+ default = "spl";
+ spl {
+ fdt = "fdt-0";
+ firmware = "atf";
+ loadables = "tee", "dm", "spl";
+ };
+ };
};
fit@0x38 {
Thanks for this! I'll make sure to add this, so we are booting fine on
non-secure with this patch applied as well right?
I didn't test secure booting yet, though. We are currently still signing
via tools/iot2050-sign-fw.sh, partly due to missing features in binman
(there were a lot of proposals on the list recently, may that is solved
now), but partly also due to some remaining breakages.
Got it. To confirm, this is not modifying anything in the secure flow is
it? flash.bin is just signed manually using tools/iot2050-sign-fw.sh
correct?
Jan
--
Thanking You
Neha Malcom Francis
Re: [PATCH v2 2/3] Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On 08/05/23 10:21, Manorit Chawdhry wrote: > Hi Nishanth, > > On 08:45-20230505, Nishanth Menon wrote: >> Manorit, >> >> On 20:59-20230504, Tom Rini wrote: >>> On Thu, May 04, 2023 at 11:07:07AM +0530, Manorit Chawdhry wrote: >>> On K3 HS-SE devices all the firewalls are locked by default until sysfw comes up. Rom configures some of the firewall for its usage along with the SRAM for R5 but the PSRAM region is still locked. The K3 MCU Scratchpad for j721s2 was set to a PSRAM region triggering the firewall exception before sysfw came up. The exception started happening after adding multi dtb support that accesses the scratchpad for reading EEPROM contents. Old map: ┌─┐ 0x41c0 │ SPL │ ├─┤ 0x41c61f20 (approx) │STACK│ ├─┤ 0x41c65f20 │ Global data │ │ sizeof(struct global_data) = 0xd8 │ ├─┤ gd->malloc_base = 0x41c66000 │HEAP │ │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ ├─┤ CONFIG_SPL_BSS_START_ADDR │ SPL BSS │ (0x41c76000) │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ ├─┤ (0x41c8) │ DM DATA │ ├─┤ (0x41c84130) (approx) │EMPTY│ └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX (0x41cffbfc) New map: ┌─┐ 0x41c0 │ SPL │ ├─┤ 0x41c61f20 (approx) │STACK│ ├─┤ 0x41c65f20 │ Global data │ │ sizeof(struct global_data) = 0xd8 │ ├─┤ gd->malloc_base = 0x41c66000 │HEAP │ │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ ├─┤ CONFIG_SPL_BSS_START_ADDR │ SPL BSS │ (0x41c76000) │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ ├─┤ (0x41c8) │ DM DATA │ ├─┤ (0x41c84130) (approx) │EMPTY│ ├─┤ SYS_K3_MCU_SCRATCHPAD_BASE │ SCRATCHPAD │ (0x41cff9fc) │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │ └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX (0x41cffbfc) Reviewed-by: Kamlesh Gurudasani Signed-off-by: Manorit Chawdhry >>> Applied to u-boot/master, thanks! >> >> I just finally caught up with this patch, Sorry for the late >> response-> Thank you for clearly elaborating this in commit message, >> BUT: >> >> Can we start documenting this in rst after we have incorporated the >> binman changes? The memory map on the SRAM is a black magic(at least >> for me) that needs explanation in a single doc without needing to dig >> through commit messages and variables and defconfigs.. >> >> Documentation should clearly indicate what parameters from: >> * binman configuration. >> * various config header files >> * defconfig >> >> We should explain the rationale, variations (HS-SE for example: if any >> or if not any) - including risks such as stack-heap collisions. Any >> interplay with firmware components in the heterogenous system that folks >> need to be careful about needs to be called out as well. >> > Thanks for the insights! Queueing this up when binman get merged. > Would be good to let me know a place also to document all this as I > couldn't find any j721s2 specific documentation, I believe these things > can become device specific also based on the requirements as j721s2 and > j721e have a different map of SPL for them. doc/board/ti/ is the right place IMO. We need an equivalent for j721e_evm.rst which explains combined image boot flow and SRAM layout for J721s2 / j784s4 (and possibly same for J7200)? Regards Vignesh -- Regards Vignesh
Re: [PATCH v2 2/3] Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
Hi Nishanth, On 08:45-20230505, Nishanth Menon wrote: > Manorit, > > On 20:59-20230504, Tom Rini wrote: > > On Thu, May 04, 2023 at 11:07:07AM +0530, Manorit Chawdhry wrote: > > > > > On K3 HS-SE devices all the firewalls are locked by default > > > until sysfw comes up. Rom configures some of the firewall for its usage > > > along with the SRAM for R5 but the PSRAM region is still locked. > > > > > > The K3 MCU Scratchpad for j721s2 was set to a PSRAM region triggering the > > > firewall exception before sysfw came up. The exception started happening > > > after adding multi dtb support that accesses the scratchpad for reading > > > EEPROM contents. > > > > > > Old map: > > > ┌─┐ 0x41c0 > > > │ SPL │ > > > ├─┤ 0x41c61f20 (approx) > > > │STACK│ > > > ├─┤ 0x41c65f20 > > > │ Global data │ > > > │ sizeof(struct global_data) = 0xd8 │ > > > ├─┤ gd->malloc_base = 0x41c66000 > > > │HEAP │ > > > │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ > > > ├─┤ CONFIG_SPL_BSS_START_ADDR > > > │ SPL BSS │ (0x41c76000) > > > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ > > > ├─┤ (0x41c8) > > > │ DM DATA │ > > > ├─┤ (0x41c84130) (approx) > > > │EMPTY│ > > > └─┘ > > > CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX > > > (0x41cffbfc) > > > > > > New map: > > > ┌─┐ 0x41c0 > > > │ SPL │ > > > ├─┤ 0x41c61f20 (approx) > > > │STACK│ > > > ├─┤ 0x41c65f20 > > > │ Global data │ > > > │ sizeof(struct global_data) = 0xd8 │ > > > ├─┤ gd->malloc_base = 0x41c66000 > > > │HEAP │ > > > │ CONFIG_SYS_MALLOC_F_LEN = 0x1 │ > > > ├─┤ CONFIG_SPL_BSS_START_ADDR > > > │ SPL BSS │ (0x41c76000) > > > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │ > > > ├─┤ (0x41c8) > > > │ DM DATA │ > > > ├─┤ (0x41c84130) (approx) > > > │EMPTY│ > > > ├─┤ SYS_K3_MCU_SCRATCHPAD_BASE > > > │ SCRATCHPAD │ (0x41cff9fc) > > > │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │ > > > └─┘ > > > CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX > > > (0x41cffbfc) > > > > > > Reviewed-by: Kamlesh Gurudasani > > > Signed-off-by: Manorit Chawdhry > > > > Applied to u-boot/master, thanks! > > > I just finally caught up with this patch, Sorry for the late > response-> Thank you for clearly elaborating this in commit message, > BUT: > > Can we start documenting this in rst after we have incorporated the > binman changes? The memory map on the SRAM is a black magic(at least > for me) that needs explanation in a single doc without needing to dig > through commit messages and variables and defconfigs.. > > Documentation should clearly indicate what parameters from: > * binman configuration. > * various config header files > * defconfig > > We should explain the rationale, variations (HS-SE for example: if any > or if not any) - including risks such as stack-heap collisions. Any > interplay with firmware components in the heterogenous system that folks > need to be careful about needs to be called out as well. > Thanks for the insights! Queueing this up when binman get merged. Would be good to let me know a place also to document all this as I couldn't find any j721s2 specific documentation, I believe these things can become device specific also based on the requirements as j721s2 and j721e have a different map of SPL for them. Regards, Manorit > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D
[PATCH] configs: am62ax_evm_a53_defconfig: Enable YMODEM support at A53 SPL
This is required for UART boot flow where u-boot.img needs to be downloaded via YMODEM. Signed-off-by: Vignesh Raghavendra --- configs/am62ax_evm_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig index 41fa6f38aa72..76ec5ed40463 100644 --- a/configs/am62ax_evm_a53_defconfig +++ b/configs/am62ax_evm_a53_defconfig @@ -35,6 +35,7 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_POWER_DOMAIN=y +CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_MMC=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -- 2.40.1
Re: [RESEND PATCH v2] netconsole: various improvements
Hi Tom, On Fri, May 5, 2023 at 11:34 AM Tom Rini wrote: > > On Mon, Apr 03, 2023 at 02:41:52PM -0700, Tony Dinh wrote: > > > Use CONFIG_CONSOLE_MUX for netconsole. When netconsole is running, > > stdin/stdout/stder must be set to some primary console, in addtion to nc. > > For example, stdin=serial,nc. Some recent Linux kernels will not boot with > > only nc on the stdout list, ie. stdout=nc. When netconsole exits, remove > > nc from the list of devices in stdin/stdout/stderr. > > > > Signed-off-by: Tony Dinh > > This breaks the ut_bootstd_bootflow_cmd_boot test on sandbox. I'm not > sure if it's a test issue or something else. Thanks for trying, I'm having some difficulty building a sandbox u-boot, so I can't get to the point where I can see what's the problem yet. All the best, Tony > > -- > Tom
[UBOOT PATCH 3/3] usb: dwc3: core: Only handle soft-reset in DCTL
[ Nguyen/Greg: Ported from Linux kernel commit
f4fd84ae0765a ("usb: dwc3: core: Only handle soft-reset in DCTL") ]
Make sure not to set run_stop bit or link state change request while
initiating soft-reset. Register read-modify-write operation may
unintentionally start the controller before the initialization completes
with its previous DCTL value, which can cause initialization failure.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 8702a54efa..c80f2d0a53 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -72,7 +72,8 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg |= DWC3_DCTL_CSFTRST;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ reg &= ~DWC3_DCTL_RUN_STOP;
+ dwc3_gadget_dctl_write_safe(dwc, reg);
do {
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
--
2.17.1
[UBOOT PATCH 2/3] usb: dwc3: gadget: Don't send unintended link state change
[ Nguyen/Felipe/Greg: Ported from Linux kernel commit
5b738211fb59 ("usb: dwc3: gadget: Don't send
unintended link state change") ]
DCTL.ULSTCHNGREQ is a write-only field. When doing a read-modify-write
to DCTL, the driver must make sure that there's no unintended link state
change request from whatever is read from DCTL.ULSTCHNGREQ. Set link
state change to no-action when the driver writes to DCTL.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/gadget.c | 16 +++-
drivers/usb/dwc3/gadget.h | 14 ++
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index eb416b832a..24a2c455b0 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -62,7 +62,7 @@ int dwc3_gadget_set_test_mode(struct dwc3 *dwc, int mode)
return -EINVAL;
}
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
return 0;
}
@@ -1382,7 +1382,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
dwc->pullups_connected = false;
}
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
do {
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
@@ -2047,10 +2047,8 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3
*dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_INITU1ENA;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-
reg &= ~DWC3_DCTL_INITU2ENA;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
dwc3_disconnect_gadget(dwc);
dwc->start_config_issued = false;
@@ -2099,7 +2097,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
dwc->test_mode = false;
dwc3_stop_active_transfers(dwc);
@@ -2215,11 +2213,11 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3
*dwc)
if (dwc->has_lpm_erratum && dwc->revision >= DWC3_REVISION_240A)
reg |= DWC3_DCTL_LPM_ERRATA(dwc->lpm_nyet_threshold);
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
} else {
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_HIRD_THRES_MASK;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
}
dep = dwc->eps[0];
@@ -2327,7 +2325,7 @@ static void dwc3_gadget_linksts_change_interrupt(struct
dwc3 *dwc,
reg &= ~u1u2;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
break;
default:
/* do nothing */
diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index 7806ce59a2..b48ec6b237 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -104,4 +104,18 @@ static inline u32 dwc3_gadget_ep_get_transfer_index(struct
dwc3 *dwc, u8 number)
return DWC3_DEPCMD_GET_RSC_IDX(res_id);
}
+/**
+ * dwc3_gadget_dctl_write_safe - write to DCTL safe from link state change
+ * @dwc: pointer to our context structure
+ * @value: value to write to DCTL
+ *
+ * Use this function when doing read-modify-write to DCTL. It will not
+ * send link state change request.
+ */
+static inline void dwc3_gadget_dctl_write_safe(struct dwc3 *dwc, u32 value)
+{
+ value &= ~DWC3_DCTL_ULSTCHNGREQ_MASK;
+ dwc3_writel(dwc->regs, DWC3_DCTL, value);
+}
+
#endif /* __DRIVERS_USB_DWC3_GADGET_H */
--
2.17.1
[UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/core.c | 50 +++--
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
static int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
+ int retries = 1000;
- /* Before Resetting PHY, put Core in Reset */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg |= DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
- /* Assert USB3 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
- reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
- /* Assert USB2 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
- mdelay(100);
-
- /* Clear USB3 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
- reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
- /* Clear USB2 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ /*
+* We're resetting only the device side because, if we're in host mode,
+* XHCI driver will reset the host block. If dwc3 was configured for
+* host-only mode, then we can return early.
+*/
+ if (dwc->dr_mode == USB_DR_MODE_HOST)
+ return 0;
- mdelay(100);
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
- /* After PHYs are stable we can take Core out of reset state */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg &= ~DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ return 0;
+ udelay(1);
+ } while (--retries);
- return 0;
+ return -ETIMEDOUT;
}
/*
--
2.17.1
[UBOOT PATCH 0/3] Port the usb reset patches from linux
Port the usb reset patches from linux kernel. Venkatesh Yadav Abbarapu (3): usb: dwc3: core: improve reset sequence usb: dwc3: gadget: Don't send unintended link state change usb: dwc3: core: Only handle soft-reset in DCTL drivers/usb/dwc3/core.c | 51 +++ drivers/usb/dwc3/gadget.c | 16 ++-- drivers/usb/dwc3/gadget.h | 14 +++ 3 files changed, 40 insertions(+), 41 deletions(-) -- 2.17.1
Re: [PATCH v3 10/17] x86: spl: Show debugging for BSS
On Fri, May 5, 2023 at 6:51 AM Simon Glass wrote: > > Show the area of memory cleared for BSS, when debugging is enabled. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Drop change to memset() > > arch/x86/lib/spl.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v4 00/16] x86: Various minor enhancements for coreboot
On Fri, May 5, 2023 at 6:55 AM Simon Glass wrote: > > This series includes some patches generated while getting U-Boot to boot > more nicely on Brya, an Adler Lake Chromebook. > > This includes: > - show the ACPI tables with 'acpi list' > - get the UART to work even if coreboot doesn't enable it > - show unimplemented sysinfo tags > - fix for keyboard not working > - fix for trying to set up PCI regions when the info is not available > - fix for looking at inaccessible memory to find the sysinfo table > > Changes in v4: > - Split out patch to enable bus mastering > - Drop unnecessary CONFIG options > - Drop patch to allow locating UARTs by device ID > > Changes in v3: > - Don't enable ACPI by default except on x86 and sandbox > - Avoid a build error with the ASL compiler > - Disable for coreboot64 since ACPI is not available > > Changes in v2: > - Don't show an invalid CPU number on error > - Update commit message with more detail > - Update code comment to mention that addresses <1KB are ignored > - Flush the buffer instead of skipping the reset > - Add new patch to create a new Kconfig for ACPI > - Add new patch to move acpi-table-finding functions into the library > - Use tab instead of space in header file > - Refactor two patches into one > - Add new patch to allow locating the UART from ACPI tables > - Expand commit message to explain this is for the debug UART > - Update the defconfig instead > - Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere > - Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed) > - Add new patch to enable ms command > > Simon Glass (16): > mtrr: Don't show an invalid CPU number > x86: Adjust search range for sysinfo table > input: Flush the keyboard buffer before resetting it > acpi: Create a new Kconfig for ACPI > acpi: Move the table-finding functions into the libary > x86: coreboot: Collect the address of the ACPI tables > x86: Allow locating the UART from ACPI tables > pci: coreboot: Don't read regions when booting > x86: coreboot: Use a memory-mapped UART > x86: coreboot: Document how to enable the debug UART > x86: coreboot: Scan PCI after relocation > x86: coreboot: Log function names and line numbers > x86: coreboot: Show unimplemented sysinfo tags > nvme: Enable PCI bus mastering > x86: nvme: coreboot: Enable NVMe > coreboot: Enable ms command > series applied to u-boot-x86, thanks!
Re: [GIT PULL] Please pull u-boot-mpc8xx
On Fri, May 05, 2023 at 05:16:25PM +, Christophe Leroy wrote: > Hi Tom, > > This pull request adds misc fixes for cssi boards and activates > CPM relocation in order to enable the use of SCC4 in > QMC (QUICC Multi-Channel) mode. > > CI: https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/16261 > > Thanks > Christophe > > > The following changes since commit 6735ab59e6fd71ced1c58d8dfb3dd6baf3690d16: > >Prepare v2023.07-rc1 (2023-05-01 12:02:02 -0400) > > are available in the Git repository at: > >g...@source.denx.de:u-boot/custodians/u-boot-mpc8xx.git for-2023.07-2 > > for you to fetch changes up to 0ec8ebef87d78529d1b4f3e7beaced0b9fbea629: > >board: cssi: Activate SMC relocation on CMPC885 board for MIAE device > (2023-05-05 07:26:53 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: U-Boot Bootmenu's autoboot rendering is broken
On Sunday 07 May 2023 23:19:22 Pali Rohár wrote: > On Sunday 07 May 2023 23:08:45 Pali Rohár wrote: > > If you run bootmenu in U-Boot it will print following output: > > > > *** U-Boot Boot Menu *** > > > > Attached kernel > > Internal eMMC > > External SD card > > U-Boot boot order > > U-Boot consoleHit any key to stop autoboot: 30 Hit any key to stop > > autoboot: 29 Hit any key to stop autoboot: 28 > > > > It happens on both serial output and VGA video output, so it is not > > related to video output driver or interpreting of ANSI sequence. > > > > Last entry is being overwritten by "Hit any key to stop autoboot" and > > then every one second is new text appended after this last entry with > > updated countdown. This is broken... I run git bisect and the result is: > > > > 32bab0eae51b55898d1e2804e6614d9143840581 is the first bad commit > > commit 32bab0eae51b55898d1e2804e6614d9143840581 > > Author: Simon Glass > > Date: Fri Jan 6 08:52:26 2023 -0600 > > > > menu: Make use of CLI character processing > > > > Avoid duplicating some of the escape-sequence processing here and use > > the > > CLI function instead. > > > > Signed-off-by: Simon Glass > > > > :04 04 62275c330c72e251d79fd3f867f8c3e44a6d8f32 > > 3933deacc7661348a31e73822341b4b262bec382 M cmd > > :04 04 49ba8a914e6bd3f0438db86d290af226a1eb1272 > > 1cce113f49b3ecbb1acf6d56fa0bc8f279cf5794 M common > > :04 04 021b5af8bf4e8f1226b93e63f4cd9f2e581a9659 > > 2eb10232c77e0c4fa78677b059db3c5990c2799a M include > > > > Simon, could you look at this issue? It can be simple reproduced just by > > calling "bootmenu" command. > > Not only autoboot countdown and last boot entry is broken but also keys > UP and DOWN and broken on _terminal_. When I do not press any key on > terminal for 3 seconds then pressing DOWN quits bootmenu. Git bisect > found same above commit. Maybe added "case '\e':" in above commit into > /* ^C was pressed */ branch cause it? Hm... what does "+#define ansi 0" in that commit means? It looks like a hack for some unfinished stuff. That commit is incomplete.
Re: U-Boot Bootmenu's autoboot rendering is broken
On Sunday 07 May 2023 23:08:45 Pali Rohár wrote: > If you run bootmenu in U-Boot it will print following output: > > *** U-Boot Boot Menu *** > > Attached kernel > Internal eMMC > External SD card > U-Boot boot order > U-Boot consoleHit any key to stop autoboot: 30 Hit any key to stop > autoboot: 29 Hit any key to stop autoboot: 28 > > It happens on both serial output and VGA video output, so it is not > related to video output driver or interpreting of ANSI sequence. > > Last entry is being overwritten by "Hit any key to stop autoboot" and > then every one second is new text appended after this last entry with > updated countdown. This is broken... I run git bisect and the result is: > > 32bab0eae51b55898d1e2804e6614d9143840581 is the first bad commit > commit 32bab0eae51b55898d1e2804e6614d9143840581 > Author: Simon Glass > Date: Fri Jan 6 08:52:26 2023 -0600 > > menu: Make use of CLI character processing > > Avoid duplicating some of the escape-sequence processing here and use the > CLI function instead. > > Signed-off-by: Simon Glass > > :04 04 62275c330c72e251d79fd3f867f8c3e44a6d8f32 > 3933deacc7661348a31e73822341b4b262bec382 M cmd > :04 04 49ba8a914e6bd3f0438db86d290af226a1eb1272 > 1cce113f49b3ecbb1acf6d56fa0bc8f279cf5794 M common > :04 04 021b5af8bf4e8f1226b93e63f4cd9f2e581a9659 > 2eb10232c77e0c4fa78677b059db3c5990c2799a M include > > Simon, could you look at this issue? It can be simple reproduced just by > calling "bootmenu" command. Not only autoboot countdown and last boot entry is broken but also keys UP and DOWN and broken on _terminal_. When I do not press any key on terminal for 3 seconds then pressing DOWN quits bootmenu. Git bisect found same above commit. Maybe added "case '\e':" in above commit into /* ^C was pressed */ branch cause it?
U-Boot Bootmenu's autoboot rendering is broken
If you run bootmenu in U-Boot it will print following output: *** U-Boot Boot Menu *** Attached kernel Internal eMMC External SD card U-Boot boot order U-Boot consoleHit any key to stop autoboot: 30 Hit any key to stop autoboot: 29 Hit any key to stop autoboot: 28 It happens on both serial output and VGA video output, so it is not related to video output driver or interpreting of ANSI sequence. Last entry is being overwritten by "Hit any key to stop autoboot" and then every one second is new text appended after this last entry with updated countdown. This is broken... I run git bisect and the result is: 32bab0eae51b55898d1e2804e6614d9143840581 is the first bad commit commit 32bab0eae51b55898d1e2804e6614d9143840581 Author: Simon Glass Date: Fri Jan 6 08:52:26 2023 -0600 menu: Make use of CLI character processing Avoid duplicating some of the escape-sequence processing here and use the CLI function instead. Signed-off-by: Simon Glass :04 04 62275c330c72e251d79fd3f867f8c3e44a6d8f32 3933deacc7661348a31e73822341b4b262bec382 M cmd :04 04 49ba8a914e6bd3f0438db86d290af226a1eb1272 1cce113f49b3ecbb1acf6d56fa0bc8f279cf5794 M common :04 04 021b5af8bf4e8f1226b93e63f4cd9f2e581a9659 2eb10232c77e0c4fa78677b059db3c5990c2799a M include Simon, could you look at this issue? It can be simple reproduced just by calling "bootmenu" command.
U-Boot Bootmenu is broken on Nokia N900
Bootmenu on Nokia N900 is broken (on both HW and in qemu emulator). Bootmenu just prints garbage on the screen. I run git bisect and the result is: 72a0dd8bed010bef78028ae528763f9807758e6b is the first bad commit commit 72a0dd8bed010bef78028ae528763f9807758e6b Author: Simon Glass Date: Fri Jan 6 08:52:29 2023 -0600 video: Enable VIDEO_ANSI by default only with EFI This is not generally needed unless EFI_LOADER is used. Adjust the default setting to reduce the size of the U-Boot build. Signed-off-by: Simon Glass :04 04 7da10731b9f552cd7ff26dabe3e4787bf2b80caa 18fa5c5d7f1f14aebaa1365b8f60217bbeffabb8 M drivers Change was relatively simple: diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index f539977d9b73..440b161b8423 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -112,10 +112,13 @@ config VIDEO_BPP32 config VIDEO_ANSI bool "Support ANSI escape sequences in video console" - default y + default y if EFI_LOADER help Enable ANSI escape sequence decoding for a more fully functional - console. + console. Functionality includes changing the text colour and moving + the cursor. These date from the 1970s and are still widely used today + to control a text terminal. U-Boot implements these by decoding the + sequences and performing the appropriate operation. config VIDEO_MIPI_DSI bool "Support MIPI DSI interface" On master branch with CONFIG_VIDEO_ANSI=y is bootmenu rendering again. CONFIG_VIDEO_ANSI needs to be by default enabled also when CONFIG_CMD_BOOTMENU is enabled (not only for EFI). Simon, would you fix it?
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > > > > > NAK. With commit: > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > Author: Pali Rohár > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says that > > > > > > > all reset > > > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > > > register to > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > register before > > > > > > > issuing card reset. This allows SPL/U-Boot to get information > > > > > > > which eMMC > > > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > > > platforms this > > > > > > > is the way how to determinate boot partition from which > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > 13:10:10 -0400) > > > > > > > Trying to boot from MMC1 > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > > spl: mmc init failed with error: -110 > > > > > > > SPL: failed to boot from all boot devices > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > -- > > > > > > > Tom > > > > > > > > > > > > I do not know what to do with this... The only idea is to hide this > > > > > > code > > > > > > behind CONFIG symbol and enable it only for mvebu. For example by > > > > > > this: > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > failure I > > > > > reported was uSD and not eMMC. > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not know if > > > > card is SD or MMC. > > > > > > > > Martin, can you check if booting from SD card is working fine on mvebu > > > > clearfog? > > > > > > > > > I see a failure with this commit on > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > fsm 0, hsts > > > > > ... > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above one and > > > > > the board is fine again. > > > > > > > > > > -- > > > > > Tom > > > > > > > > Immediately after that "problematic code" is card reset function. So > > > > another reason for failure is that card reset functionality does not > > > > work correctly on your board / platform. > > > > > > Well, we're at two different platforms and controllers that this change > > > breaks things on, so I'm not sure where the fault is exactly. My > > > mx6cuboxi is still fine booting from uSD. Another TI platform from the > > > same general era as am335x fails the same way (not a surprise), amlogic > > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > > > that work are not ARCH_OMAP2PLUS). > > > > > > -- > > > Tom > > > > And do you see this problem in SPL or in proper U-Boot? > > > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > > qemu emulated version (to which can be attached gdb). But Nokia N900 is > > without SPL. > > > OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it > tries uSD. In this case, full U-Boot also fails: > Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on > cmd inhibit to clear > ** Bad device specification mmc 0 ** > > Note that N900 in QEMU passes, but I suspect that's a matter of the > emulator not being faithful to some undocumented bug/feature of the > chipset and that it would also fail like this on real HW or that we > aren't relying on MMC in such a way that the QEMU tests actually report > failure. When I booted the above, it was not a lock-up since we can > continue on in this case, rather than fail
Re: mmc: Read eMMC partition access bits before card reset
On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > > > NAK. With commit: > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > Author: Pali Rohár > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > eMMC specification in section "Access partitions" says that all > > > > > > reset > > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > > register to > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > register before > > > > > > issuing card reset. This allows SPL/U-Boot to get information > > > > > > which eMMC > > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > > platforms this > > > > > > is the way how to determinate boot partition from which BootROM > > > > > > loaded SPL. > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 > > > > > > -0400) > > > > > > Trying to boot from MMC1 > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > spl: mmc init failed with error: -110 > > > > > > SPL: failed to boot from all boot devices > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > -- > > > > > > Tom > > > > > > > > > > I do not know what to do with this... The only idea is to hide this > > > > > code > > > > > behind CONFIG symbol and enable it only for mvebu. For example by > > > > > this: > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The failure I > > > > reported was uSD and not eMMC. > > > > > > Maybe it is that reason. Problem is that at this stage we do not know if > > > card is SD or MMC. > > > > > > Martin, can you check if booting from SD card is working fine on mvebu > > > clearfog? > > > > > > > I see a failure with this commit on > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > Loading Environment from FAT... fsm 0, hsts > > > > fsm 0, hsts > > > > ... > > > > > > > > once in U-Boot itself. Going to the commit prior to the above one and > > > > the board is fine again. > > > > > > > > -- > > > > Tom > > > > > > Immediately after that "problematic code" is card reset function. So > > > another reason for failure is that card reset functionality does not > > > work correctly on your board / platform. > > > > Well, we're at two different platforms and controllers that this change > > breaks things on, so I'm not sure where the fault is exactly. My > > mx6cuboxi is still fine booting from uSD. Another TI platform from the > > same general era as am335x fails the same way (not a surprise), amlogic > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > > also fine with this. So maybe the Kconfig is fine, but we just want > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > > that work are not ARCH_OMAP2PLUS). > > > > -- > > Tom > > And do you see this problem in SPL or in proper U-Boot? > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > qemu emulated version (to which can be attached gdb). But Nokia N900 is > without SPL. OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it tries uSD. In this case, full U-Boot also fails: Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear ** Bad device specification mmc 0 ** Note that N900 in QEMU passes, but I suspect that's a matter of the emulator not being faithful to some undocumented bug/feature of the chipset and that it would also fail like this on real HW or that we aren't relying on MMC in such a way that the QEMU tests actually report failure. When I booted the above, it was not a lock-up since we can continue on in this case, rather than failure to load U-Boot itself. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 05/10] ram: cadence: add driver for Cadence EDAC
On 4/24/23 03:15, Ralph Siemsen wrote:
[...]
diff --git a/drivers/ram/cadence/ddr_ctrl.c b/drivers/ram/cadence/ddr_ctrl.c
new file mode 100644
index 00..35544fbb95
--- /dev/null
+++ b/drivers/ram/cadence/ddr_ctrl.c
[...]
+void cdns_ddr_ctrl_start(void *ddr_ctrl_basex)
+{
+ u32 *ddr_ctrl_base = (u32 *)ddr_ctrl_basex;
+ u8 *base8 = (u8 *)ddr_ctrl_basex;
+
+ /* Start */
+ ddrc_writeb(1, base8 + DDR_START_REG);
+
+ /* Wait for controller to be ready (interrupt status) */
+ while (!(readl(base8 + DDR_INTERRUPT_STATUS) & 0x100))
+ ;
If you can, use readl_poll_timeout() or wait_for_bit*() to avoid endless
loops .
Re: [PATCH v5 10/10] doc: renesas: add Renesas board docs
On 4/24/23 03:15, Ralph Siemsen wrote: [...] +++ b/doc/board/renesas/renesas.rst @@ -0,0 +1,45 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas +=== + +About this +-- + +This document describes the information about Renesas supported boards +and their usage steps. + +Renesas boards +-- + +Renesas is a SoC solutions provider for automotive and industrial applications. + +U-Boot supports several Renesas SoC families: + +* R-Car Gen2 (32-bit) +- Blanche board +- Gose board +- Koelsch board +- Lager board +- Silk board +- Porter board +- Stout board +* R-Car Gen3 (64-bit) +- Condor board +- Draak board +- Eagle board +- Ebisu board +- Salvator-X and Salvator-XS boards +- ULCB board +* R-Car Gen4 Nitpick: - R-Car Gen4 + R-Car Gen4 (64-bit) +- Falcon board +- Spider board +- Whitehawk board +* RZ/A1 (32-bit) +- GR-PEACH board +* RZ/G +- Beacon-rzg2 board +- Hihope-rzg2 board +- ek874 board +* RZ/N1 (32-bit) +- Schneider rzn1-snarc board [...] With the above fixed: Reviewed-by: Marek Vasut
Re: [PATCH v5 09/10] tools: spkgimage: add Renesas SPKG format
On 4/24/23 03:15, Ralph Siemsen wrote:
Renesas RZ/N1 devices contain BootROM code that loads a custom SPKG
image from QSPI, NAND or USB DFU. Support this format in mkimage tool.
SPKGs can optionally be signed, however creation of signed SPKG is not
currently supported.
Example of how to use it:
tools/mkimage -n board/schneider/rzn1-snarc/spkgimage.cfg \
-T spkgimage -a 0x2004 -e 0x2004 \
-d u-boot.bin u-boot.bin.spkg
The config file (spkgimage.cfg in this example) contains additional
parameters such as NAND ECC settings.
Signed-off-by: Ralph Siemsen
Reviewed-by: Simon Glass
squash! tools: spkgimage: add Renesas SPKG format
[...]
+static int spkgimage_parse_config_file(char *filename)
+{
+ FILE *fcfg;
+ char line[256];
+ size_t line_num = 0;
+
+ fcfg = fopen(filename, "r");
+ if (!fcfg)
+ return -EINVAL;
+
+ conf = calloc(1, sizeof(struct config_file));
+ if (!conf)
+ return -ENOMEM;
+
+ while (fgets(line, sizeof(line), fcfg)) {
+ line_num += 1;
+
+ /* Skip blank lines and comments */
+ if (line[0] == '\n' || line[0] == '#')
+ continue;
+
+ /* Strip any trailing newline */
+ line[strcspn(line, "\n")] = 0;
+
+ /* Parse the line */
+ if (spkgimage_parse_config_line(line, line_num))
+ return -EINVAL;
Wouldn't this return -EINVAL; leak memory allocated by the calloc() above?
[...]
With that fixed:
Reviewed-by: Marek Vasut
Re: [PATCH v5 08/10] board: schneider: add RZN1 board support
On 4/24/23 03:15, Ralph Siemsen wrote:
Add support for Schneider Electronics RZ/N1D and RZ/N1S boards, which
are based on the Reneasas RZ/N1 SoC devices.
The intention is to support both boards using a single defconfig, and to
handle the differences at runtime.
The DT comes from Linux kernel, right ? Please include commit ID from
which the DT is imported in the commit message, I suspect that would be
Linux 6.3 commit ID.
[...]
diff --git a/board/schneider/rzn1-snarc/ddr_async.c
b/board/schneider/rzn1-snarc/ddr_async.c
new file mode 100644
index 00..4b4c280e45
--- /dev/null
+++ b/board/schneider/rzn1-snarc/ddr_async.c
Please correct me if I'm wrong, but shouldn't this be in drivers/ram/ ?
[...]
+/* DDR PHY setup */
+static void ddr_phy_init(struct cadence_ddr_info *priv, int ddr_type)
+{
+ u32 val;
+
+ /* Disable DDR Controller clock and FlexWAY connection */
+ clk_disable(&priv->hclk_ddrc);
+ clk_disable(&priv->clk_ddrc);
+
+ clk_rzn1_reset_state(&priv->hclk_ddrc, 0);
+ clk_rzn1_reset_state(&priv->clk_ddrc, 0);
+
+ /* Enable DDR Controller clock and FlexWAY connection */
+ clk_enable(&priv->clk_ddrc);
+ clk_enable(&priv->hclk_ddrc);
+
+ /* DDR PHY Soft reset assert */
+ ddrc_writel(FUNCCTRL_MASKSDLOFS | FUNCCTRL_DVDDQ_1_5V, FUNCCTRL);
+
+ clk_rzn1_reset_state(&priv->hclk_ddrc, 1);
+ clk_rzn1_reset_state(&priv->clk_ddrc, 1);
+
+ /* DDR PHY setup */
+ phy_writel(DLLCTRL_MFSL_500MHz | DLLCTRL_MDLLSTBY, DLLCTRL);
+ phy_writel(0x0182, ZQCALCTRL);
+ if (ddr_type == RZN1_DDR3_DUAL_BANK)
+ phy_writel(0xAB330031, ZQODTCTRL);
+ else if (ddr_type == RZN1_DDR3_SINGLE_BANK)
+ phy_writel(0xAB320051, ZQODTCTRL);
+ else /* DDR2 */
+ phy_writel(0xAB330071, ZQODTCTRL);
+ phy_writel(0xB545B544, RDCTRL);
+ phy_writel(0x00B0, RDTMG);
+ phy_writel(0x020A0806, OUTCTRL);
+ if (ddr_type == RZN1_DDR3_DUAL_BANK)
+ phy_writel(0x80005556, WLCTRL1);
+ else
+ phy_writel(0x80005C5D, WLCTRL1);
+ phy_writel(0x0101, FIFOINIT);
+ phy_writel(0x4545, DQCALOFS1);
+
+ /* Step 9 MDLL reset release */
+ val = phy_readl(DLLCTRL);
+ val &= ~DLLCTRL_MDLLSTBY;
+ phy_writel(val, DLLCTRL);
+
+ /* Step 12 Soft reset release */
+ val = phy_readl(FUNCCTRL);
+ val |= FUNCCTRL_RESET_N;
+ phy_writel(val, FUNCCTRL);
+
+ /* Step 13 FIFO pointer initialize */
+ phy_writel(FIFOINIT_RDPTINITEXE | FIFOINIT_WRPTINITEXE, FIFOINIT);
+
+ /* Step 14 Execute ZQ Calibration */
+ val = phy_readl(ZQCALCTRL);
+ val |= ZQCALCTRL_ZQCALRSTB;
+ phy_writel(val, ZQCALCTRL);
+
+ /* Step 15 Wait for 200us or more, or wait for DFIINITCOMPLETE to be
"1" */
+ while (!(phy_readl(DLLCTRL) & DLLCTRL_ASDLLOCK))
+ ;
Please avoid endless loops, use readl_poll_timeout() or wait_for_bit*()
where possible.
+ while (!(phy_readl(ZQCALCTRL) & ZQCALCTRL_ZQCALEND))
+ ;
+
+ /* Step 16 Enable Address and Command output */
+ val = phy_readl(OUTCTRL);
+ val |= OUTCTRL_ADCMDOE;
+ phy_writel(val, OUTCTRL);
+
+ /* Step 17 Wait for 200us or more(from MRESETB=0) */
+ udelay(200);
+}
[...]
diff --git a/board/schneider/rzn1-snarc/rzn1.c
b/board/schneider/rzn1-snarc/rzn1.c
new file mode 100644
index 00..6eb86c2592
--- /dev/null
+++ b/board/schneider/rzn1-snarc/rzn1.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ /*
+* Initial values for gd->ram_base and gd->ram_size
+* are obtained from the "/memory" node in devicetree.
+* The size will be updated in later when probing DDR.
+*/
+ fdtdec_setup_mem_size_base();
Are you absolutely sure this call ^ is needed at all ?
+ gd->bd->bi_boot_params = gd->ram_base + 0x100;
+
+ return 0;
+}
+
+int dram_init(void)
+{
+ struct udevice *dev;
+ int err;
+
+ /*
+* This will end up calling cadence_ddr_probe(),
+* and will also update gd->ram_size.
+*/
+ err = uclass_get_device(UCLASS_RAM, 0, &dev);
+ if (err) {
+ debug("DRAM init failed: %d\n", err);
You can just do this here:
err = uclass...();
if (err)
debug(...);
return err;
+ return err;
+ }
+
+ return 0;
+}
[...]
narc.h b/include/configs/rzn1-snarc.h
new file mode 100644
index 00..dce0de0d4c
--- /dev/null
+++ b/include/configs/rzn1-snarc.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Configuration settings for the Schneider RZ/N1 board
+ */
+
+#ifndef __RZN1_H
Better use __RZN1_SNARC_H , so that when other boards get added, there
won't be trouble.
+#define __RZN1_H
+
+/* In
Re: [PATCH v5 07/10] ARM: rmobile: Add support for Renesas RZ/N1 SoC
On 4/24/23 03:15, Ralph Siemsen wrote:
[...]
diff --git a/arch/arm/mach-rmobile/cpu_info.c b/arch/arm/mach-rmobile/cpu_info.c
index 7e7465a2c8..15be32af31 100644
--- a/arch/arm/mach-rmobile/cpu_info.c
+++ b/arch/arm/mach-rmobile/cpu_info.c
@@ -31,6 +31,7 @@ void enable_caches(void)
#ifdef CONFIG_DISPLAY_CPUINFO
#ifndef CONFIG_RZA1
+#ifndef CONFIG_RZN1
Use:
#if !defined(CONFIG_RZA1) && !defined(CONFIG_RZN1)
__weak const u8 *rzg_get_cpu_name(void)
{
return 0;
@@ -128,6 +129,13 @@ int print_cpuinfo(void)
}
#else
#elif defined(CONFIG_RZA1)
... the RZA1 stuff ...
#else /* CONFIG_RZN1 */
... the RZN1 stuff ...
#endif
That should make the ifdeffery easier.
int print_cpuinfo(void)
+{
+ printf("CPU: Renesas Electronics RZ/N1\n");
+ return 0;
+}
+#endif
+#else
+int print_cpuinfo(void)
{
printf("CPU: Renesas Electronics RZ/A1\n");
return 0;
Re: [PATCH v5 06/10] ARM: dts: add devicetree for Renesas RZ/N1 SoC
On 4/24/23 03:15, Ralph Siemsen wrote: This is taken directly from Linux kernel 6.3-rc7. You can now use final 6.3 since it was released . A commit ID of that 6.3 (source commit in Linux) in the commit message is a good practice. Signed-off-by: Ralph Siemsen Reviewed-by: Marek Vasut
Re: [PATCH v5 03/10] clk: renesas: add R906G032 driver
On 4/24/23 03:15, Ralph Siemsen wrote:
[...]
+static int r9a06g032_clk_probe(struct udevice *dev)
+{
+ struct r9a06g032_priv *priv = dev_get_priv(dev);
+
+ priv->regmap = syscon_regmap_lookup_by_phandle(dev, "regmap");
+ if (IS_ERR(priv->regmap)) {
+ dev_dbg(dev, "unable to find regmap\n");
+ return PTR_ERR(priv->regmap);
+ }
+
+ /* Enable S/W reset */
+ regmap_write(priv->regmap, 0x120, 0x41);
Please introduce a macro for the register name and BIT()s for the
register bits.
With that,
Reviewed-by: Marek Vasut
+ /* Get master clock */
+ return clk_get_by_name(dev, "mclk", &priv->mclk);
+}
[..]
Re: [PATCH v5 02/10] clk: renesas: prepare for non R-Car clock drivers
On 4/24/23 03:15, Ralph Siemsen wrote: Add new CONFIG_CLK_RCAR to control compilation of shared code for R-Car clock drivers (renesas-cpg-mssr.c). Enable this for R-Car Gen2 and 3. This is necessary so that CONFIG_CLK_RENESAS can be enabled, allowing recursion into the drivers/clk/reneasas directory, without bringing in the R-Car support code. The support code contains platform specific access (TMU_BASE) which is not needed on other Renesas devices such as RZ/N1. Signed-off-by: Ralph Siemsen Reviewed-by: Sean Anderson Reviewed-by: Marek Vasut
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > NAK. With commit: > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > Author: Pali Rohár > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > eMMC specification in section "Access partitions" says that all > > > > > reset > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > register to > > > > > default User Data Area value (0b000). > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD register > > > > > before > > > > > issuing card reset. This allows SPL/U-Boot to get information > > > > > which eMMC > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > platforms this > > > > > is the way how to determinate boot partition from which BootROM > > > > > loaded SPL. > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 > > > > > -0400) > > > > > Trying to boot from MMC1 > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > spl: mmc init failed with error: -110 > > > > > SPL: failed to boot from all boot devices > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > -- > > > > > Tom > > > > > > > > I do not know what to do with this... The only idea is to hide this code > > > > behind CONFIG symbol and enable it only for mvebu. For example by this: > > > > > > Well, maybe the problem is we're trying this on uSD cards? The failure I > > > reported was uSD and not eMMC. > > > > Maybe it is that reason. Problem is that at this stage we do not know if > > card is SD or MMC. > > > > Martin, can you check if booting from SD card is working fine on mvebu > > clearfog? > > > > > I see a failure with this commit on > > > rpi_3_32b, also from uSD boot. This time it's: > > > Loading Environment from FAT... fsm 0, hsts > > > fsm 0, hsts > > > ... > > > > > > once in U-Boot itself. Going to the commit prior to the above one and > > > the board is fine again. > > > > > > -- > > > Tom > > > > Immediately after that "problematic code" is card reset function. So > > another reason for failure is that card reset functionality does not > > work correctly on your board / platform. > > Well, we're at two different platforms and controllers that this change > breaks things on, so I'm not sure where the fault is exactly. My > mx6cuboxi is still fine booting from uSD. Another TI platform from the > same general era as am335x fails the same way (not a surprise), amlogic > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > also fine with this. So maybe the Kconfig is fine, but we just want > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > that work are not ARCH_OMAP2PLUS). > > -- > Tom And do you see this problem in SPL or in proper U-Boot? If omap2plus is problematic then I can do tests on Nokia N900 or at its qemu emulated version (to which can be attached gdb). But Nokia N900 is without SPL.
Re: mmc: Read eMMC partition access bits before card reset
On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > NAK. With commit: > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > Author: Pali Rohár > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > eMMC specification in section "Access partitions" says that all > > > > reset > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > register to > > > > default User Data Area value (0b000). > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD register > > > > before > > > > issuing card reset. This allows SPL/U-Boot to get information which > > > > eMMC > > > > partition was in use before SPL/U-Boot was booted. For some > > > > platforms this > > > > is the way how to determinate boot partition from which BootROM > > > > loaded SPL. > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 > > > > -0400) > > > > Trying to boot from MMC1 > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > spl: mmc init failed with error: -110 > > > > SPL: failed to boot from all boot devices > > > > ### ERROR ### Please RESET the board ### > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > -- > > > > Tom > > > > > > I do not know what to do with this... The only idea is to hide this code > > > behind CONFIG symbol and enable it only for mvebu. For example by this: > > > > Well, maybe the problem is we're trying this on uSD cards? The failure I > > reported was uSD and not eMMC. > > Maybe it is that reason. Problem is that at this stage we do not know if > card is SD or MMC. > > Martin, can you check if booting from SD card is working fine on mvebu > clearfog? > > > I see a failure with this commit on > > rpi_3_32b, also from uSD boot. This time it's: > > Loading Environment from FAT... fsm 0, hsts > > fsm 0, hsts > > ... > > > > once in U-Boot itself. Going to the commit prior to the above one and > > the board is fine again. > > > > -- > > Tom > > Immediately after that "problematic code" is card reset function. So > another reason for failure is that card reset functionality does not > work correctly on your board / platform. Well, we're at two different platforms and controllers that this change breaks things on, so I'm not sure where the fault is exactly. My mx6cuboxi is still fine booting from uSD. Another TI platform from the same general era as am335x fails the same way (not a surprise), amlogic libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are also fine with this. So maybe the Kconfig is fine, but we just want default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms that work are not ARCH_OMAP2PLUS). -- Tom signature.asc Description: PGP signature
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > Hi Tom, > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > NAK. With commit: > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > Author: Pali Rohár > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > eMMC specification in section "Access partitions" says that all reset > > > events will restore the access bits in PARTITION_CONFIG CSD register > > > to > > > default User Data Area value (0b000). > > > > > > So read partition access bits from PARTITION_CONFIG CSD register > > > before > > > issuing card reset. This allows SPL/U-Boot to get information which > > > eMMC > > > partition was in use before SPL/U-Boot was booted. For some platforms > > > this > > > is the way how to determinate boot partition from which BootROM > > > loaded SPL. > > > > > > Signed-off-by: Pali Rohár > > > > > > My am335x_evm now fails to boot with: > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) > > > Trying to boot from MMC1 > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > spl: mmc init failed with error: -110 > > > SPL: failed to boot from all boot devices > > > ### ERROR ### Please RESET the board ### > > > > > > I can provide more details / test patches as needed. > > > > > > -- > > > Tom > > > > I do not know what to do with this... The only idea is to hide this code > > behind CONFIG symbol and enable it only for mvebu. For example by this: > > Well, maybe the problem is we're trying this on uSD cards? The failure I > reported was uSD and not eMMC. Maybe it is that reason. Problem is that at this stage we do not know if card is SD or MMC. Martin, can you check if booting from SD card is working fine on mvebu clearfog? > I see a failure with this commit on > rpi_3_32b, also from uSD boot. This time it's: > Loading Environment from FAT... fsm 0, hsts > fsm 0, hsts > ... > > once in U-Boot itself. Going to the commit prior to the above one and > the board is fine again. > > -- > Tom Immediately after that "problematic code" is card reset function. So another reason for failure is that card reset functionality does not work correctly on your board / platform.
Re: mmc: Read eMMC partition access bits before card reset
On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > Hi Tom, > > > > > > please pull this next batch of mostly Marvell related patches: > > > > NAK. With commit: > > commit 461fa17970de418a93832f734a595031c0b72128 > > Author: Pali Rohár > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > mmc: Read eMMC partition access bits before card reset > > > > eMMC specification in section "Access partitions" says that all reset > > events will restore the access bits in PARTITION_CONFIG CSD register to > > default User Data Area value (0b000). > > > > So read partition access bits from PARTITION_CONFIG CSD register before > > issuing card reset. This allows SPL/U-Boot to get information which eMMC > > partition was in use before SPL/U-Boot was booted. For some platforms > > this > > is the way how to determinate boot partition from which BootROM loaded > > SPL. > > > > Signed-off-by: Pali Rohár > > > > My am335x_evm now fails to boot with: > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400) > > Trying to boot from MMC1 > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > spl: mmc init failed with error: -110 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > I can provide more details / test patches as needed. > > > > -- > > Tom > > I do not know what to do with this... The only idea is to hide this code > behind CONFIG symbol and enable it only for mvebu. For example by this: Well, maybe the problem is we're trying this on uSD cards? The failure I reported was uSD and not eMMC. I see a failure with this commit on rpi_3_32b, also from uSD boot. This time it's: Loading Environment from FAT... fsm 0, hsts fsm 0, hsts ... once in U-Boot itself. Going to the commit prior to the above one and the board is fine again. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] initial support for the Videostrong KII Pro
Superseded by v3 -- f_
[PATCH v3 3/3] doc: boards: amlogic: add documentation for KII Pro
Add build instructions for the KII Pro set-top box. Signed-off-by: Ferass El Hafidi --- board/amlogic/p200/MAINTAINERS| 1 + doc/board/amlogic/index.rst | 1 + doc/board/amlogic/videostrong-kii-pro.rst | 112 ++ 3 files changed, 114 insertions(+) create mode 100644 doc/board/amlogic/videostrong-kii-pro.rst diff --git a/board/amlogic/p200/MAINTAINERS b/board/amlogic/p200/MAINTAINERS index 19e27def70..5cf0ce05dc 100644 --- a/board/amlogic/p200/MAINTAINERS +++ b/board/amlogic/p200/MAINTAINERS @@ -13,5 +13,6 @@ F:configs/videostrong-kii-pro_defconfig F: doc/board/amlogic/p200.rst F: doc/board/amlogic/nanopi-k2.rst F: doc/board/amlogic/odroid-c2.rst +F: doc/board/amlogic/videostrong-kii-pro.rst F: doc/board/amlogic/wetek-hub.rst F: doc/board/amlogic/wetek-play2.rst diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst index 66b581c837..46f44bf34e 100644 --- a/doc/board/amlogic/index.rst +++ b/doc/board/amlogic/index.rst @@ -118,6 +118,7 @@ Board Documentation sei610 s400 u200 + videostrong-kii-pro wetek-core2 wetek-hub wetek-play2 diff --git a/doc/board/amlogic/videostrong-kii-pro.rst b/doc/board/amlogic/videostrong-kii-pro.rst new file mode 100644 index 00..1c6adac996 --- /dev/null +++ b/doc/board/amlogic/videostrong-kii-pro.rst @@ -0,0 +1,112 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +U-Boot for Videostrong KII Pro (S905) += + +Videostrong KII Pro is an Android STB manufactured by Videostrong and +based on the Amlogic p201 reference board, with the following specification: + + - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz + - ARM Mali 450 GPU + - 2GB DDR3 SDRAM + - 16GB eMMC + - Gigabit Ethernet + - Boardcom BCM4335 WiFi and BT 4.0 + - HDMI 2.0 4K/60Hz display + - 3x USB 2.0 host + - 1x USB 2.0 otg + - microSD + - Infrared receiver + - Blue LED + - Red LED + - Power button (case, front) + - Reset button (underside) + - DVB Card: DVB-S and DVB-T/C + +Schematics are not publicly available. + +U-Boot Compilation +-- + +.. code-block:: bash + +$ export CROSS_COMPILE=aarch64-none-elf- +$ make videostrong-kii-pro_defconfig +$ make + +U-Boot Signing with Pre-Built FIP repo +-- + +.. code-block:: bash + +$ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 +$ cd amlogic-boot-fip +$ mkdir my-output-dir +$ ./build-fip.sh wetek-play2 /path/to/u-boot/u-boot.bin my-output-dir + +U-Boot Manual Signing +- + +Amlogic does not provide sources for the firmware and tools needed to create +a bootloader image and Videostrong has not publicly shared the U-Boot sources +needed to build FIP binaries for signing. However you can use the WeTek +Play2 binaries from the amlogic-boot-fip repo as the WeTek Play2 and the +Videostrong KII Pro share the same RAM chips. + +.. code-block:: bash + +$ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 +$ cd amlogic-boot-fip/wetek-play2 +$ export FIPDIR=$PWD + +Go back to the mainline U-Boot source tree then: + +.. code-block:: bash + +$ mkdir fip +$ cp $FIPDIR/bl2.bin fip/ +$ cp $FIPDIR/acs.bin fip/ +$ cp $FIPDIR/bl21.bin fip/ +$ cp $FIPDIR/bl30.bin fip/ +$ cp $FIPDIR/bl301.bin fip/ +$ cp $FIPDIR/bl31.img fip/ +$ cp u-boot.bin fip/bl33.bin +$ $FIPDIR/blx_fix.sh \ + fip/bl30.bin \ + fip/zero_tmp \ + fip/bl30_zero.bin \ + fip/bl301.bin \ + fip/bl301_zero.bin \ + fip/bl30_new.bin \ + bl30 +$ $FIPDIR/fip_create --bl30 fip/bl30_new.bin \ + --bl31 fip/bl31.img \ + --bl33 fip/bl33.bin \ + fip/fip.bin +$ sed -i 's/\x73\x02\x08\x91/\x1F\x20\x03\xD5/' fip/bl2.bin +$ python3 $FIPDIR/acs_tool.py fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0 +$ $FIPDIR/blx_fix.sh \ + fip/bl2_acs.bin \ + fip/zero_tmp \ + fip/bl2_zero.bin \ + fip/bl21.bin \ + fip/bl21_zero.bin \ + fip/bl2_new.bin \ + bl2 +$ cat fip/bl2_new.bin fip/fip.bin > fip/boot_new.bin +$ $FIPDIR/aml_encrypt_gxb --bootsig \ + --input fip/boot_new.bin + --output fip/u-boot.bin + +Then write U-Boot to SD or eMMC with: + +.. code-block:: bash + +$ DEV=/dev/boot_device +$ dd if=fip/u-boot.bin of=fip/u-boot.bin.gxbb bs=512 conv=fsync +$ dd if=fip/u-boot.bin of=fip/u-boot.bin.gxbb bs=512 seek=9 skip=8 count=87 conv=fsync,notrunc +$ dd if=/dev/zero of=fip/u-boot.bin.gxbb bs=512 seek=8 count=1 conv=fsync,notrunc +$ dd if=bl1.bin.hardkernel of=fip/u-boot.bin.gxbb bs=512 seek=2 skip=2 count=1 conv=fsync,notrunc +$ ./aml_chksum fip/u-boot.bin.gxbb +
[PATCH v3 2/3] boards: amlogic: add KII Pro defconfig
Add configurations for the Videostrong KII Pro set-top box. This defconfig is cloned from the WeTek Play2's. Signed-off-by: Ferass El Hafidi --- board/amlogic/p200/MAINTAINERS| 1 + configs/videostrong-kii-pro_defconfig | 70 +++ 2 files changed, 71 insertions(+) create mode 100644 configs/videostrong-kii-pro_defconfig diff --git a/board/amlogic/p200/MAINTAINERS b/board/amlogic/p200/MAINTAINERS index fe451dd7db..19e27def70 100644 --- a/board/amlogic/p200/MAINTAINERS +++ b/board/amlogic/p200/MAINTAINERS @@ -9,6 +9,7 @@ F: configs/odroid-c2_defconfig F: configs/p200_defconfig F: configs/wetek-hub_defconfig F: configs/wetek-play2_defconfig +F: configs/videostrong-kii-pro_defconfig F: doc/board/amlogic/p200.rst F: doc/board/amlogic/nanopi-k2.rst F: doc/board/amlogic/odroid-c2.rst diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig new file mode 100644 index 00..77b7a38296 --- /dev/null +++ b/configs/videostrong-kii-pro_defconfig @@ -0,0 +1,70 @@ +CONFIG_ARM=y +CONFIG_ARCH_MESON=y +CONFIG_TEXT_BASE=0x0100 +CONFIG_SYS_LOAD_ADDR=0x100 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_ENV_SIZE=0x2000 +CONFIG_DM_GPIO=y +CONFIG_DEBUG_UART_BASE=0xc81004c0 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_IDENT_STRING=" kii-pro" +CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro" +CONFIG_DEBUG_UART=y +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000 +CONFIG_OF_BOARD_SETUP=y +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_MISC_INIT_R=y +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_IMI is not set +CONFIG_CMD_ADC=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_REGULATOR=y +CONFIG_OF_CONTROL=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SARADC_MESON=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_MESON=y +CONFIG_DM_MMC=y +CONFIG_MMC_MESON_GX=y +CONFIG_PHY_REALTEK=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE_MESON8B=y +CONFIG_PHY=y +CONFIG_MESON_GXBB_USB_PHY=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_MESON_GXBB=y +CONFIG_POWER_DOMAIN=y +CONFIG_MESON_EE_POWER_DOMAIN=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_DM_REGULATOR_GPIO=y +CONFIG_DM_RESET=y +CONFIG_DEBUG_UART_ANNOUNCE=y +CONFIG_DEBUG_UART_SKIP_INIT=y +CONFIG_MESON_SERIAL=y +CONFIG_SYSINFO=y +CONFIG_SYSINFO_SMBIOS=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_KEYBOARD=y +CONFIG_VIDEO=y +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP16 is not set +CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_MESON=y +CONFIG_VIDEO_DT_SIMPLEFB=y +CONFIG_SPLASH_SCREEN=y +CONFIG_SPLASH_SCREEN_ALIGN=y +CONFIG_VIDEO_BMP_RLE8=y +CONFIG_BMP_16BPP=y +CONFIG_BMP_24BPP=y +CONFIG_BMP_32BPP=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.40.0
[PATCH v3 1/3] arm: dts: add support for Videostrong KII Pro
Import the device tree from mainline linux (v6.4-rc1) and add the
old PHY reset bindings in the PHY node, else U-Boot and linux won't
be able to use the PHY.
Signed-off-by: Ferass El Hafidi
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi | 13 ++
arch/arm/dts/meson-gxbb-kii-pro.dts | 140
3 files changed, 154 insertions(+)
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 935b2f1517..b2dec5fe73 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -187,6 +187,7 @@ dtb-$(CONFIG_ARCH_S5P4418) += \
dtb-$(CONFIG_ARCH_MESON) += \
meson-axg-s400.dtb \
meson-axg-jethome-jethub-j100.dtb \
+ meson-gxbb-kii-pro.dtb \
meson-gxbb-nanopi-k2.dtb \
meson-gxbb-odroidc2.dtb \
meson-gxbb-nanopi-k2.dtb \
diff --git a/arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
new file mode 100644
index 00..191c5192c6
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-gx-u-boot.dtsi"
+
+ðmac {
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0>, <1>, <100>;
+ snps,reset-active-low;
+};
diff --git a/arch/arm/dts/meson-gxbb-kii-pro.dts
b/arch/arm/dts/meson-gxbb-kii-pro.dts
new file mode 100644
index 00..e238f1f101
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-kii-pro.dts
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Mohammad Rasim
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "videostrong,kii-pro", "amlogic,meson-gxbb";
+ model = "Videostrong KII Pro";
+
+ spdif_dit: audio-codec-0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ status = "okay";
+ sound-name-prefix = "DIT";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ led {
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ button-reset {
+ label = "reset";
+ linux,code = ;
+ gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "KII-PRO";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-3 {
+ sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;
+
+ codec-0 {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+
+ dai-link-4 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
+ pinctrl-0 = <&spdif_out_y_pins>;
+ pinctrl-names = "default";
+};
+
+ðmac {
+ status = "okay";
+ pinctrl-0 = <ð_rmii_pins>;
+ pinctrl-names = "default";
+
+ phy-handle = <ð_phy0>;
+ phy-mode = "rmii";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ /* IC Plus IP101GR (0x02430c54) */
+ reg = <0>;
+
[PATCH v3 0/3] initial support for the Videostrong KII Pro
The Videostrong KII Pro is a set-top box based on the Amlogic p201
reference board and with the following specification:
* Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz
* ARM Mali 450 GPU
* 2GB DDR3 SDRAM
* 16GB eMMC
* Gigabit Ethernet
* Broadcom BCM4335 WiFi and BT 4.0
* HDMI 2.0 4K/60Hz display
* 3x USB 2.0 host
* 1x USB 2.0 otg
* microSD
* Infrared receiver
* Blue LED
* Red LED
* Power button (case, front)
* Reset button (underside)
* DVB Card: DVB-S and DVB-T/C
Changes since v1:
* Fix typo ("Boardcom" -> "Broadcom")
* Remove duplicate "From:"
Changes since v2:
* Update defconfig to work with U-Boot/master
Ferass El Hafidi (3):
arm: dts: add support for Videostrong KII Pro
boards: amlogic: add KII Pro defconfig
doc: boards: amlogic: add documentation for KII Pro
arch/arm/dts/Makefile | 1 +
arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi | 13 ++
arch/arm/dts/meson-gxbb-kii-pro.dts | 140
board/amlogic/p200/MAINTAINERS | 2 +
configs/videostrong-kii-pro_defconfig | 70 ++
doc/board/amlogic/index.rst | 1 +
doc/board/amlogic/videostrong-kii-pro.rst | 112
7 files changed, 339 insertions(+)
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts
create mode 100644 configs/videostrong-kii-pro_defconfig
create mode 100644 doc/board/amlogic/videostrong-kii-pro.rst
--
2.40.0
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 04.05.23 08:13, Neha Malcom Francis wrote:
> Hi Jan
>
> On 04/05/23 10:13, Neha Malcom Francis wrote:
>> Hi Jan,
>>
>> On 03/05/23 22:04, Jan Kiszka wrote:
>>> On 03.05.23 14:56, Neha Malcom Francis wrote:
Hi Jan,
On 03/05/23 12:57, Neha Malcom Francis wrote:
> Hi Tom
>
> On 27/04/23 04:07, Tom Rini wrote:
>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote:
>>
>>> This series aims to eliminate the use of additional custom
>>> repositories
>>> such as k3-image-gen (K3 Image Generation) repo and
>>> core-secdev-k3 (K3
>>> Security Development Tools) that was plumbed into the U-Boot
>>> build flow
>>> to generate boot images for TI K3 platform devices. And instead, we
>>> move
>>> towards using binman that aligns better with the community standard
>>> build
>>> flow.
>>>
>>> This series uses binman for all K3 platforms supported on U-Boot
>>> currently;
>>> both HS (High Security, both SE and FS) and GP (General Purpose)
>>> devices.
>>>
>>> Background on using k3-image-gen:
>>> * TI K3 devices require a SYSFW (System Firmware) image
>>> consisting
>>> of a signed system firmware image and board configuration
>>> binaries,
>>> this is needed to bring up system firmware during U-Boot R5 SPL
>>> startup.
>>> * Board configuration data contain board-specific information
>>> such as resource management, power management and security.
>>>
>>> Background on using core-secdev-k3:
>>> * Contains resources to sign x509 certificates for HS devices
>>>
>>> Series intends to use binman to take over the packaging and
>>> signing for
>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for
>>> non-combined
>>> boot flow) instead of k3-image-gen.
>>>
>>> Series also packages the A72/A53 bootloader images (tispl.bin and
>>> u-boot.img) using ATF, OPTEE and DM (Device Manager)
>>
>> So, next up is fixing this in CI. After taking Andrew's patch to
>> fix the
>> typedef issue, and after my patches to ensure we can get
>> pyyaml/jsonschema for python, there's problems still:
>
>
> Thanks for checking this! Couple things:
>
>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966:
>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in
>> input
>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts)
>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72')
>
> 1. This is dependent on the patch merging J721S2 HS and GP configs
> [1]. However it has been reverted on -next, seen in the same thread.
>
>>
>> And then:
>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328
>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error
>> I've fixed this, minor but serious change.
>
> 2. Regarding iot2050, build fails since it uses
> arch/arm/mach-k3/config.mk which is now entirely binman based. Will
> try moving iot2050 to binman as well.
I'll need some help with this, might need to know the bootloader
flow to
make a clean migration.
>>>
>>> Where do I have to look at? Is there a git repo with that experiment
>>> somewhere?
>>>
>>> Jan
>>>
>>
>> There's no experiment yet, I will send one today; but I do not have
>> complete understanding of the booting; whether the tispl.bin (which I
>> assume is the only boot component that is affecting iot2050 boot since
>> k3_fit_atf.sh is no longer there) has any concept of signing? Is
>> core-secdev-k3 ever used?
>>
>
> I have a tree posted here [2] that builds flash.bin with no error for
> me. Please confirm whether your build flow does the same and also let me
> know if the binary actually boots.
>
> [2]
> https://github.com/nehamalcom/u-boot/tree/migration-to-binman-cicd-iot2050
>
I've tested the latest version in that branch in the meantime. It
compiles but it does not work. This is missing from the original script:
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index e17ffd7481f..9d83898d33f 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -92,6 +92,15 @@
};
};
};
+
+ configurations {
+ default = "spl";
+ spl {
+ fdt = "fdt-0";
+ firmware = "atf";
+ loadables = "tee", "dm", "spl";
+ };
+ };
};
fit@0x38 {
I didn't test secure booting yet, though. We are currently still signing
via tools/iot2050-sign-f
Re: [PATCH 0/3] initial support for the Videostrong KII Pro
Superseded by v2 (will appear soon) -- f_
[PATCH v2 3/3] doc: boards: amlogic: add documentation for KII Pro
Add build instructions for the KII Pro set-top box. Signed-off-by: Ferass El Hafidi --- board/amlogic/p200/MAINTAINERS| 1 + doc/board/amlogic/index.rst | 1 + doc/board/amlogic/videostrong-kii-pro.rst | 112 ++ 3 files changed, 114 insertions(+) create mode 100644 doc/board/amlogic/videostrong-kii-pro.rst diff --git a/board/amlogic/p200/MAINTAINERS b/board/amlogic/p200/MAINTAINERS index 19e27def70..5cf0ce05dc 100644 --- a/board/amlogic/p200/MAINTAINERS +++ b/board/amlogic/p200/MAINTAINERS @@ -13,5 +13,6 @@ F:configs/videostrong-kii-pro_defconfig F: doc/board/amlogic/p200.rst F: doc/board/amlogic/nanopi-k2.rst F: doc/board/amlogic/odroid-c2.rst +F: doc/board/amlogic/videostrong-kii-pro.rst F: doc/board/amlogic/wetek-hub.rst F: doc/board/amlogic/wetek-play2.rst diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst index 66b581c837..46f44bf34e 100644 --- a/doc/board/amlogic/index.rst +++ b/doc/board/amlogic/index.rst @@ -118,6 +118,7 @@ Board Documentation sei610 s400 u200 + videostrong-kii-pro wetek-core2 wetek-hub wetek-play2 diff --git a/doc/board/amlogic/videostrong-kii-pro.rst b/doc/board/amlogic/videostrong-kii-pro.rst new file mode 100644 index 00..1c6adac996 --- /dev/null +++ b/doc/board/amlogic/videostrong-kii-pro.rst @@ -0,0 +1,112 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +U-Boot for Videostrong KII Pro (S905) += + +Videostrong KII Pro is an Android STB manufactured by Videostrong and +based on the Amlogic p201 reference board, with the following specification: + + - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz + - ARM Mali 450 GPU + - 2GB DDR3 SDRAM + - 16GB eMMC + - Gigabit Ethernet + - Broadcom BCM4335 WiFi and BT 4.0 + - HDMI 2.0 4K/60Hz display + - 3x USB 2.0 host + - 1x USB 2.0 otg + - microSD + - Infrared receiver + - Blue LED + - Red LED + - Power button (case, front) + - Reset button (underside) + - DVB Card: DVB-S and DVB-T/C + +Schematics are not publicly available. + +U-Boot Compilation +-- + +.. code-block:: bash + +$ export CROSS_COMPILE=aarch64-none-elf- +$ make videostrong-kii-pro_defconfig +$ make + +U-Boot Signing with Pre-Built FIP repo +-- + +.. code-block:: bash + +$ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 +$ cd amlogic-boot-fip +$ mkdir my-output-dir +$ ./build-fip.sh wetek-play2 /path/to/u-boot/u-boot.bin my-output-dir + +U-Boot Manual Signing +- + +Amlogic does not provide sources for the firmware and tools needed to create +a bootloader image and Videostrong has not publicly shared the U-Boot sources +needed to build FIP binaries for signing. However you can use the WeTek +Play2 binaries from the amlogic-boot-fip repo as the WeTek Play2 and the +Videostrong KII Pro share the same RAM chips. + +.. code-block:: bash + +$ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 +$ cd amlogic-boot-fip/wetek-play2 +$ export FIPDIR=$PWD + +Go back to the mainline U-Boot source tree then: + +.. code-block:: bash + +$ mkdir fip +$ cp $FIPDIR/bl2.bin fip/ +$ cp $FIPDIR/acs.bin fip/ +$ cp $FIPDIR/bl21.bin fip/ +$ cp $FIPDIR/bl30.bin fip/ +$ cp $FIPDIR/bl301.bin fip/ +$ cp $FIPDIR/bl31.img fip/ +$ cp u-boot.bin fip/bl33.bin +$ $FIPDIR/blx_fix.sh \ + fip/bl30.bin \ + fip/zero_tmp \ + fip/bl30_zero.bin \ + fip/bl301.bin \ + fip/bl301_zero.bin \ + fip/bl30_new.bin \ + bl30 +$ $FIPDIR/fip_create --bl30 fip/bl30_new.bin \ + --bl31 fip/bl31.img \ + --bl33 fip/bl33.bin \ + fip/fip.bin +$ sed -i 's/\x73\x02\x08\x91/\x1F\x20\x03\xD5/' fip/bl2.bin +$ python3 $FIPDIR/acs_tool.py fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0 +$ $FIPDIR/blx_fix.sh \ + fip/bl2_acs.bin \ + fip/zero_tmp \ + fip/bl2_zero.bin \ + fip/bl21.bin \ + fip/bl21_zero.bin \ + fip/bl2_new.bin \ + bl2 +$ cat fip/bl2_new.bin fip/fip.bin > fip/boot_new.bin +$ $FIPDIR/aml_encrypt_gxb --bootsig \ + --input fip/boot_new.bin + --output fip/u-boot.bin + +Then write U-Boot to SD or eMMC with: + +.. code-block:: bash + +$ DEV=/dev/boot_device +$ dd if=fip/u-boot.bin of=fip/u-boot.bin.gxbb bs=512 conv=fsync +$ dd if=fip/u-boot.bin of=fip/u-boot.bin.gxbb bs=512 seek=9 skip=8 count=87 conv=fsync,notrunc +$ dd if=/dev/zero of=fip/u-boot.bin.gxbb bs=512 seek=8 count=1 conv=fsync,notrunc +$ dd if=bl1.bin.hardkernel of=fip/u-boot.bin.gxbb bs=512 seek=2 skip=2 count=1 conv=fsync,notrunc +$ ./aml_chksum fip/u-boot.bin.gxbb +
[PATCH v2 2/3] boards: amlogic: add KII Pro defconfig
Add configurations for the Videostrong KII Pro set-top box. This defconfig is cloned from the WeTek Play2's. Signed-off-by: Ferass El Hafidi --- board/amlogic/p200/MAINTAINERS| 1 + configs/videostrong-kii-pro_defconfig | 70 +++ 2 files changed, 71 insertions(+) create mode 100644 configs/videostrong-kii-pro_defconfig diff --git a/board/amlogic/p200/MAINTAINERS b/board/amlogic/p200/MAINTAINERS index fe451dd7db..19e27def70 100644 --- a/board/amlogic/p200/MAINTAINERS +++ b/board/amlogic/p200/MAINTAINERS @@ -9,6 +9,7 @@ F: configs/odroid-c2_defconfig F: configs/p200_defconfig F: configs/wetek-hub_defconfig F: configs/wetek-play2_defconfig +F: configs/videostrong-kii-pro_defconfig F: doc/board/amlogic/p200.rst F: doc/board/amlogic/nanopi-k2.rst F: doc/board/amlogic/odroid-c2.rst diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig new file mode 100644 index 00..77b7a38296 --- /dev/null +++ b/configs/videostrong-kii-pro_defconfig @@ -0,0 +1,70 @@ +CONFIG_ARM=y +CONFIG_ARCH_MESON=y +CONFIG_SYS_TEXT_BASE=0x0100 +CONFIG_SYS_LOAD_ADDR=0x100 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_ENV_SIZE=0x2000 +CONFIG_DM_GPIO=y +CONFIG_DEBUG_UART_BASE=0xc81004c0 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_IDENT_STRING=" kii-pro" +CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro" +CONFIG_DEBUG_UART=y +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000 +CONFIG_OF_BOARD_SETUP=y +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_MISC_INIT_R=y +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_IMI is not set +CONFIG_CMD_ADC=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_REGULATOR=y +CONFIG_OF_CONTROL=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SARADC_MESON=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_MESON=y +CONFIG_DM_MMC=y +CONFIG_MMC_MESON_GX=y +CONFIG_PHY_REALTEK=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE_MESON8B=y +CONFIG_PHY=y +CONFIG_MESON_GXBB_USB_PHY=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_MESON_GXBB=y +CONFIG_POWER_DOMAIN=y +CONFIG_MESON_EE_POWER_DOMAIN=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_DM_REGULATOR_GPIO=y +CONFIG_DM_RESET=y +CONFIG_DEBUG_UART_ANNOUNCE=y +CONFIG_DEBUG_UART_SKIP_INIT=y +CONFIG_MESON_SERIAL=y +CONFIG_SYSINFO=y +CONFIG_SYSINFO_SMBIOS=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_KEYBOARD=y +CONFIG_DM_VIDEO=y +# CONFIG_VIDEO_BPP8 is not set +# CONFIG_VIDEO_BPP16 is not set +CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_MESON=y +CONFIG_VIDEO_DT_SIMPLEFB=y +CONFIG_SPLASH_SCREEN=y +CONFIG_SPLASH_SCREEN_ALIGN=y +CONFIG_VIDEO_BMP_RLE8=y +CONFIG_BMP_16BPP=y +CONFIG_BMP_24BPP=y +CONFIG_BMP_32BPP=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.40.0
[PATCH v2 1/3] arm: dts: add support for Videostrong KII Pro
Import the device tree from mainline linux (v6.4-rc1) and add the
old PHY reset bindings in the PHY node, else U-Boot and linux won't
be able to use the PHY.
Signed-off-by: Ferass El Hafidi
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi | 13 ++
arch/arm/dts/meson-gxbb-kii-pro.dts | 140
3 files changed, 154 insertions(+)
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 935b2f1517..b2dec5fe73 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -187,6 +187,7 @@ dtb-$(CONFIG_ARCH_S5P4418) += \
dtb-$(CONFIG_ARCH_MESON) += \
meson-axg-s400.dtb \
meson-axg-jethome-jethub-j100.dtb \
+ meson-gxbb-kii-pro.dtb \
meson-gxbb-nanopi-k2.dtb \
meson-gxbb-odroidc2.dtb \
meson-gxbb-nanopi-k2.dtb \
diff --git a/arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
new file mode 100644
index 00..191c5192c6
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-gx-u-boot.dtsi"
+
+ðmac {
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0>, <1>, <100>;
+ snps,reset-active-low;
+};
diff --git a/arch/arm/dts/meson-gxbb-kii-pro.dts
b/arch/arm/dts/meson-gxbb-kii-pro.dts
new file mode 100644
index 00..e238f1f101
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-kii-pro.dts
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Mohammad Rasim
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "videostrong,kii-pro", "amlogic,meson-gxbb";
+ model = "Videostrong KII Pro";
+
+ spdif_dit: audio-codec-0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ status = "okay";
+ sound-name-prefix = "DIT";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ led {
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ button-reset {
+ label = "reset";
+ linux,code = ;
+ gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "KII-PRO";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-3 {
+ sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;
+
+ codec-0 {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+
+ dai-link-4 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
+ pinctrl-0 = <&spdif_out_y_pins>;
+ pinctrl-names = "default";
+};
+
+ðmac {
+ status = "okay";
+ pinctrl-0 = <ð_rmii_pins>;
+ pinctrl-names = "default";
+
+ phy-handle = <ð_phy0>;
+ phy-mode = "rmii";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ /* IC Plus IP101GR (0x02430c54) */
+ reg = <0>;
+
[PATCH v2 0/3] initial support for the Videostrong KII Pro
The Videostrong KII Pro is a set-top box based on the Amlogic p201
reference board and with the following specification:
- Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz
- ARM Mali 450 GPU
- 2GB DDR3 SDRAM
- 16GB eMMC
- Gigabit Ethernet
- Broadcom BCM4335 WiFi and BT 4.0
- HDMI 2.0 4K/60Hz display
- 3x USB 2.0 host
- 1x USB 2.0 otg
- microSD
- Infrared receiver
- Blue LED
- Red LED
- Power button (case, front)
- Reset button (underside)
- DVB Card: DVB-S and DVB-T/C
Changes since v1:
- Fix typo ("Boardcom" -> "Broadcom")
- Remove duplicate "From:"
Ferass El Hafidi (3):
arm: dts: add support for Videostrong KII Pro
boards: amlogic: add KII Pro defconfig
doc: boards: amlogic: add documentation for KII Pro
arch/arm/dts/Makefile | 1 +
arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi | 13 ++
arch/arm/dts/meson-gxbb-kii-pro.dts | 140
board/amlogic/p200/MAINTAINERS | 2 +
configs/videostrong-kii-pro_defconfig | 70 ++
doc/board/amlogic/index.rst | 1 +
doc/board/amlogic/videostrong-kii-pro.rst | 112
7 files changed, 339 insertions(+)
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts
create mode 100644 configs/videostrong-kii-pro_defconfig
create mode 100644 doc/board/amlogic/videostrong-kii-pro.rst
--
2.40.0
[PATCH] cmd: fs: document where 'size' stores its result
Make it a little bit easier for the user to utilize the 'size' command. Signed-off-by: Baruch Siach --- cmd/fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/fs.c b/cmd/fs.c index 5ad11647c2d3..6044f73af5b4 100644 --- a/cmd/fs.c +++ b/cmd/fs.c @@ -20,7 +20,7 @@ U_BOOT_CMD( "determine a file's size", " \n" "- Find file 'filename' from 'dev' on 'interface'\n" - " and determine its size." + " determine its size, and store in the 'filesize' variable." ); static int do_load_wrapper(struct cmd_tbl *cmdtp, int flag, int argc, -- 2.39.2
U-Boot - Behaviour of 'go' command
I have written a minimal bare-metal Raspberry Pi-3B program (ARM64- CortexA53) to switch from EL2 (Exception Level 2) to EL1. U-Boot is used as the bootloader. The code is loaded to RAM using the "tftpboot" command. The "go" command is used to start the execution of my program. I am not expecting to return the control back to U-Boot. When the code switches to EL1 using "ERET" instruction the RAM (the jump location) contains the random data. When I inspect (using JTAG) the RAM (again the jump location) just before the ERET I can see the valid program there. May I know the reason for this behavior? Is there a better alternative to the "go" command? Thanks a lot, Little
