Re: [PATCH v3] wdt: nuvoton: Fix reset/expire function error
On 10/18/23 04:09, Jim Liu wrote:
Fix npcm845 watchdog halt for reset function and expire function.
Reset function is restart wdt.
Signed-off-by: Jim Liu
Changes for v3:
- Modify start sentences
- Remove empty line
Changes for v2:
- Add commit message
- Fix no empty line problem
- Remove dts
---
The revision history should be placed below the "---" line. This way
it will not be included in the commit text when committing. No need to
change this though, I'll fix it up.
Reviewed-by: Stefan Roese
Thanks,
Stefan
drivers/watchdog/npcm_wdt.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
index e56aa0ebe1..57b61215a2 100644
--- a/drivers/watchdog/npcm_wdt.c
+++ b/drivers/watchdog/npcm_wdt.c
@@ -69,15 +69,21 @@ static int npcm_wdt_stop(struct udevice *dev)
static int npcm_wdt_reset(struct udevice *dev)
{
struct npcm_wdt_priv *priv = dev_get_priv(dev);
+ u32 val;
- writel(NPCM_WTR | NPCM_WTRE | NPCM_WTE, priv->regs);
+ val = readl(priv->regs);
+ writel(val | NPCM_WTR, priv->regs);
return 0;
}
static int npcm_wdt_expire_now(struct udevice *dev, ulong flags)
{
- return npcm_wdt_reset(dev);
+ struct npcm_wdt_priv *priv = dev_get_priv(dev);
+
+ writel(NPCM_WTR | NPCM_WTRE | NPCM_WTE, priv->regs);
+
+ return 0;
}
static int npcm_wdt_of_to_plat(struct udevice *dev)
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 0/9] ufs: Add a PCI UFS controller support
+ Marek, On Wed, Oct 11, 2023 at 9:16 PM Bin Meng wrote: > > This adds a PCI UFS controller support and enables the support on > QEMU RISC-V for testing. > > Requiring QEMU v8.2+. > > This series is avaiable at u-boot-x86/ufs for testing. > > Changes in v2: > - fix a build warning > > Bin Meng (9): > ufs: Correct the UFS terminlogy > ufs: Add a line feed to the end of some dev_xxx() messages > cmd: kconfig: Make ufs prompt look similar to other commands > cmd: ufs: Correct the help text > pci_ids: Add Red Hat vendor and device IDs > ufs: Allow mmio registers on the PCI bus > ufs: Add a PCI based UFS controller driver > ufs: Handle UFS 3.1 controllers > qemu: riscv: Enable UFS support > > board/emulation/qemu-riscv/Kconfig | 2 ++ > cmd/Kconfig| 2 +- > cmd/ufs.c | 2 +- > doc/board/emulation/qemu-riscv.rst | 8 +- > drivers/ufs/Kconfig| 11 > drivers/ufs/Makefile | 1 + > drivers/ufs/ufs-pci.c | 45 ++ > drivers/ufs/ufs-uclass.c | 2 +- > drivers/ufs/ufs.c | 31 > drivers/ufs/ufs.h | 1 + > include/pci_ids.h | 7 + > 11 files changed, 97 insertions(+), 15 deletions(-) > create mode 100644 drivers/ufs/ufs-pci.c > Ping?
Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event
On 10/19/23 04:46, Minda Chen wrote:
[...]
4024a376 :
{
4024a376: 7179 addi sp,sp,-48
4024a378: f406 sd ra,40(sp)
4024a37a: f022 sd s0,32(sp)
4024a37c: ec26 sd s1,24(sp)
4024a37e: e84a sd s2,16(sp)
4024a380: e44e sd s3,8(sp)
4024a382: e052 sd s4,0(sp)
4024a384: 89ae mv s3,a1
4024a386: 84aa mv s1,a0
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
4024a388: 8c4fe0ef jal ra,4024844c
struct xhci_ring *ring =
ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a38c: 6785 lui a5,0x1
4024a38e: 94be add s1,s1,a5
4024a390: 9444a603 lw a2,-1724(s1)
4024a394: 00198713 addi a4,s3,1
4024a398: 0712 slli a4,a4,0x4
4024a39a: 02061793 slli a5,a2,0x20
4024a39e: 9381 srli a5,a5,0x20
4024a3a0: 07c9 addi a5,a5,18
4024a3a2: 078e slli a5,a5,0x3
4024a3a4: 97aa add a5,a5,a0
4024a3a6: 679c ld a5,8(a5)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index,
TRB_STOP_RING);
4024a3a8: 2981 sext.w s3,s3
4024a3aa: 86ce mv a3,s3
struct xhci_ring *ring =
ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a3ac: 97ba add a5,a5,a4
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index,
TRB_STOP_RING);
4024a3ae: 4581 li a1,0
4024a3b0: 473d li a4,15
struct xhci_ring *ring =
ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a3b2: 0087ba03 ld s4,8(a5) # 1008
<_start-0x401feff8>
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
4024a3b6: 842a mv s0,a0
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index,
TRB_STOP_RING);
4024a3b8: d75ff0ef jal ra,4024a12c
event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
4024a3bc: 02000593 li a1,32
4024a3c0: 8522 mv a0,s0
4024a3c2: ebdff0ef jal ra,4024a27e
field = le32_to_cpu(event->trans_event.flags);
epc-> 4024a3c6: 455c lw a5,12(a0)
So the fault occurs when reading the controller register(s), do I understand it
right ?
I think it is right. Actually this error occur in error path, control tx
transfer TRB_TRANSFER error occur and jump to error path.
sending TRB_TRANSFER again.
Could it be the problem is rather some clock, which are turned off after a
fault ?
I think not. Just this udisk can reproduce this issue.
Can you take a closer look into this ? Is there maybe some hardware
debug tool which can clarify what is going on better ?
It seems weird that controller register access would trigger this kind
of bus fault (it is a bus fault, right ?)
Re: [PATCH v7 6/9] efi_loader: add CDROM short-form device path
Hi Heinrich,
On Wed, 18 Oct 2023 at 19:25, Heinrich Schuchardt wrote:
>
> On 10/16/23 08:45, Masahisa Kojima wrote:
> > UEFI specification does not mandate to support the short-form
> > of the CDROM media device path.
> > Fedora installation ISO image is identified as CDROM media
> > device path, supporting short-form CDROM media device path is
> > required to automatically add the boot option having default
> > file of Fedora installation image.
>
> How is the CDROM media path created?
Fedora installation media only has a ISO 9660 filesystem without
MBR/GPT partition table.
U-Boot disk driver classifies it as PART_TYPE_ISO, then EFI-subsystem
creates a CDROM media path for it.
> Why would the image not be found if the path is not shortened?
We discussed in the separate patch that we drop the patch#4(automatically
create the boot option with default application file path appended),
so this patch is also dropped.
> What is Fedora specific here?
Fedora installation media has ISO 9660 filesystem only.
Other disto such as Debian has a MBR partition table, U-Boot creates
HardDisk device path for these medias.
> What does EDK II do?
EDK II does the same for Fedora install image, CDROM media path is created.
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > lib/efi_loader/efi_device_path.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_device_path.c
> > b/lib/efi_loader/efi_device_path.c
> > index ed7214f3a3..ac673ab117 100644
> > --- a/lib/efi_loader/efi_device_path.c
> > +++ b/lib/efi_loader/efi_device_path.c
> > @@ -110,7 +110,8 @@ struct efi_device_path *efi_dp_shorten(struct
> > efi_device_path *dp)
> > while (dp) {
> > if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB_WWI) ||
> > EFI_DP_TYPE(dp, MEDIA_DEVICE, HARD_DRIVE_PATH) ||
> > - EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH))
> > + EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH) ||
> > + EFI_DP_TYPE(dp, MEDIA_DEVICE, CDROM_PATH))
> > return dp;
> >
> > dp = efi_dp_next(dp);
>
[PATCH] mtd: spinand: Add support for XTX XT26xxxDxxxxx
Add Support XTX Technology XT26G01DX, XT26G11DX, XT26Q01DX,
XT26G02DX, XT26G12DX, XT26Q02DX, XT26G04DX, and
XT26Q04DX SPI NAND.
These are 3V/1.8V 1G/2G/4Gbit serial SLC NAND flash device with on-die
ECC(8bit strength per 512bytes).
Datasheet Links:
- http://www.xtxtech.com/download/?AId=458
- http://www.xtxtech.com/download/?AId=495
Signed-off-by: Bruce Suen
---
drivers/mtd/nand/spi/Makefile | 1 +
drivers/mtd/nand/spi/core.c | 1 +
drivers/mtd/nand/spi/xtx.c| 180 ++
include/linux/mtd/spinand.h | 1 +
4 files changed, 183 insertions(+)
create mode 100644 drivers/mtd/nand/spi/xtx.c
diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index 3051de4f7e..e46cfed446 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
spinand-objs := core.o gigadevice.o macronix.o micron.o paragon.o toshiba.o
winbond.o
+spinand-objs += xtx.o
obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 597b088ca7..0b4c067425 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -828,6 +828,7 @@ static const struct spinand_manufacturer
*spinand_manufacturers[] = {
_spinand_manufacturer,
_spinand_manufacturer,
_spinand_manufacturer,
+ _spinand_manufacturer,
};
static int spinand_manufacturer_match(struct spinand_device *spinand,
diff --git a/drivers/mtd/nand/spi/xtx.c b/drivers/mtd/nand/spi/xtx.c
new file mode 100644
index 00..ced05b5895
--- /dev/null
+++ b/drivers/mtd/nand/spi/xtx.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Stefan Roese
+ *
+ * Derived from drivers/mtd/nand/spi/micron.c
+ * Copyright (c) 2016-2017 Micron Technology, Inc.
+ */
+
+#ifndef __UBOOT__
+#include
+#include
+#endif
+#include
+#include
+
+#define SPINAND_MFR_XTX0x0B
+
+#define XT26XXXD_STATUS_ECC3_ECC2_MASK GENMASK(7, 6)
+#define XT26XXXD_STATUS_ECC_NO_DETECTED (0)
+#define XT26XXXD_STATUS_ECC_1_7_CORRECTED (1)
+#define XT26XXXD_STATUS_ECC_8_CORRECTED (3)
+#define XT26XXXD_STATUS_ECC_UNCOR_ERROR (2)
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+ SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_DUALIO_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+ SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+ SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+ SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+ SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+ SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int xt26xxxd_ooblayout_ecc(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = mtd->oobsize / 2;
+ region->length = mtd->oobsize / 2;
+
+ return 0;
+}
+
+static int xt26xxxd_ooblayout_free(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *region)
+{
+ if (section)
+ return -ERANGE;
+
+ region->offset = 2;
+ region->length = mtd->oobsize / 2 - 2;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops xt26xxxd_ooblayout = {
+ .ecc = xt26xxxd_ooblayout_ecc,
+ .rfree = xt26xxxd_ooblayout_free,
+};
+
+static int xt26xxxd_ecc_get_status(struct spinand_device *spinand,
+ u8 status)
+{
+ switch (FIELD_GET(STATUS_ECC_MASK, status)) {
+ case XT26XXXD_STATUS_ECC_NO_DETECTED:
+ return 0;
+ case XT26XXXD_STATUS_ECC_UNCOR_ERROR:
+ return -EBADMSG;
+ case XT26XXXD_STATUS_ECC_1_7_CORRECTED:
+ return 4 + FIELD_GET(XT26XXXD_STATUS_ECC3_ECC2_MASK, status);
+ case XT26XXXD_STATUS_ECC_8_CORRECTED:
+ return 8;
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static const struct spinand_info xtx_spinand_table[] = {
+ SPINAND_INFO("XT26G01D",
+SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x31),
+NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+
Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event
On 2023/10/18 18:55, Marek Vasut wrote:
> On 10/18/23 12:16, Minda Chen wrote:
>>
>>
>> On 2023/10/18 18:11, Marek Vasut wrote:
>>> On 10/18/23 05:46, Minda Chen wrote:
On 2023/10/18 10:35, Marek Vasut wrote:
> On 10/18/23 03:22, Minda Chen wrote:
>>
>>
>> On 2023/10/17 19:20, Marek Vasut wrote:
>>> On 10/17/23 08:20, Minda Chen wrote:
xhci_wait_for_event() waiting TRB_TRANSFER event may return
NULL. Checking the return value to avoid crash.
Signed-off-by: Minda Chen
>>>
>>> How did you trigger this error ? Is there a reproducer ? Details please
>>> ...
>>
>> While Scanning a lenovo usb2.0 udisk， not 100 % reproduce
>
> Can you include Linux
>
> lsusb -vvv
>
> output for this device and include that information in the commit message
> ? (or the U-Boot info below, that works too, just please add it into the
> commit message, it is important for future reference).
>
OK， I will add lsusb -vvv Linux udisk message and crash dump info to
commit message
>>>
>>> Thank you
>>>
>> This is log.
>>
>> StarFive # usb reset
>> resetting USB...
>> Bus xhci_pci: Register 5000420 NbrPorts 5
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB
>> anyway.
>> Unexpected XHCI event TRB, skipping... (f77141f0 1300
>> 02008401)
>> Unhandled exception: Load access fault
>> EPC: f7f563c6 RA: f7f563c6 TVAL: 000c
>> EPC: 4024a3c6 RA: 4024a3c6 reloc adjusted
>
> Where does the crash point to in code, can you disassemble the PC pointer
> ? (or maybe you can use scripts/decodecode I think)
>
OK， I will add EPC pointer disassemble to commit message
>>>
>>> This part probably doesn't need to be in the commit message. I'd like to
>>> know where the crash occurred in the code.
>>
>>
>> 4024a376 :
>> {
>> 4024a376: 7179 addi sp,sp,-48
>> 4024a378: f406 sd ra,40(sp)
>> 4024a37a: f022 sd s0,32(sp)
>> 4024a37c: ec26 sd s1,24(sp)
>> 4024a37e: e84a sd s2,16(sp)
>> 4024a380: e44e sd s3,8(sp)
>> 4024a382: e052 sd s4,0(sp)
>> 4024a384: 89ae mv s3,a1
>> 4024a386: 84aa mv s1,a0
>> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
>> 4024a388: 8c4fe0ef jal ra,4024844c
>> struct xhci_ring *ring =
>> ctrl->devs[udev->slot_id]->eps[ep_index].ring;
>> 4024a38c: 6785 lui a5,0x1
>> 4024a38e: 94be add s1,s1,a5
>> 4024a390: 9444a603 lw a2,-1724(s1)
>> 4024a394: 00198713 addi a4,s3,1
>> 4024a398: 0712 slli a4,a4,0x4
>> 4024a39a: 02061793 slli a5,a2,0x20
>> 4024a39e: 9381 srli a5,a5,0x20
>> 4024a3a0: 07c9 addi a5,a5,18
>> 4024a3a2: 078e slli a5,a5,0x3
>> 4024a3a4: 97aa add a5,a5,a0
>> 4024a3a6: 679c ld a5,8(a5)
>> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index,
>> TRB_STOP_RING);
>> 4024a3a8: 2981 sext.w s3,s3
>> 4024a3aa: 86ce mv a3,s3
>> struct xhci_ring *ring =
>> ctrl->devs[udev->slot_id]->eps[ep_index].ring;
>> 4024a3ac: 97ba add a5,a5,a4
>> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index,
>> TRB_STOP_RING);
>> 4024a3ae: 4581 li a1,0
>> 4024a3b0: 473d li a4,15
>> struct xhci_ring *ring =
>> ctrl->devs[udev->slot_id]->eps[ep_index].ring;
>> 4024a3b2: 0087ba03 ld s4,8(a5) # 1008
>> <_start-0x401feff8>
>> struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
>> 4024a3b6: 842a mv s0,a0
>> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index,
>> TRB_STOP_RING);
>> 4024a3b8: d75ff0ef jal ra,4024a12c
>>
>> event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
>> 4024a3bc: 02000593 li a1,32
>> 4024a3c0: 8522 mv a0,s0
>> 4024a3c2: ebdff0ef jal ra,4024a27e
>>
>> field = le32_to_cpu(event->trans_event.flags);
>> epc-> 4024a3c6: 455c lw a5,12(a0)
>
> So the fault occurs when reading the controller register(s), do I understand
> it right ?
>
I think it is right.
Re: [PATCH v3 32/32] sandbox: Add a test for disabling CONFIG_CMDLINE
On Mon, Oct 16, 2023 at 04:28:23PM -0600, Simon Glass wrote: > Now that everything is working, add a test to make sure that this > builds correctly. > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini > --- > > Changes in v3: > - Rebase on Tom's LONGHELP series > - Correct 'of' typo > > test/py/tests/test_sandbox_opts.py | 20 > 1 file changed, 20 insertions(+) > create mode 100644 test/py/tests/test_sandbox_opts.py This is not doing the equivalent of: make sandbox_config sed -i -e 's/CONFIG_CMDLINE=y/CONFIG_CMDLINE=n/' .config make oldconfig make all -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 04/22] pinctrl: sunxi: move pinctrl code
On Thu, 28 Sep 2023 22:54:37 +0100
Andre Przywara wrote:
Hi Samuel,
> Move the existing sunxi-specific low level pinctrl routines from
> arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so
> that the common code can be shared outside of arch/arm.
I was wondering if you would find a moment to have a quick look at this
and the next few patches (04/22 till 09/22)?
I tried to address the ideas you brought up the other day on how to
best restructure the GPIO driver, to accommodate both the new D1
pinctrl device, as well as preparing to use the GPIO functionality from
outside of arch/arm.
Any feedback would be appreciated. If I get it still this week, I am
inclined to push the series into the currently open merge window still,
since I believe the other T113 patches are good to go.
Many thanks,
Andre
>
> This also takes the opportunity to move some definitions from our
> header file into the driver C file, as they are private to the driver
> and are not needed elsewhere.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/include/asm/arch-sunxi/gpio.h | 20 +
> arch/arm/mach-sunxi/Makefile | 1 -
> arch/arm/mach-sunxi/pinmux.c | 78 ---
> drivers/gpio/sunxi_gpio.c | 102 -
> 4 files changed, 105 insertions(+), 96 deletions(-)
> delete mode 100644 arch/arm/mach-sunxi/pinmux.c
>
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 6eaeece4e24..4bc9e8ffcc9 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -3,6 +3,9 @@
> * (C) Copyright 2007-2012
> * Allwinner Technology Co., Ltd.
> * Tom Cubie
> + *
> + * Definitions that are shared between the Allwinner pinctrl and GPIO
> drivers,
> + * also used by some non-DM SPL code directly.
> */
>
> #ifndef _SUNXI_GPIO_H
> @@ -76,22 +79,6 @@ struct sunxi_gpio_reg {
> #define SUN50I_H6_GPIO_POW_MOD_SEL 0x340
> #define SUN50I_H6_GPIO_POW_MOD_VAL 0x348
>
> -#define BANK_TO_GPIO(bank) (((bank) < SUNXI_GPIO_L) ? \
> - &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank] : \
> - &((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)->gpio_bank[(bank) -
> SUNXI_GPIO_L])
> -
> -#define GPIO_BANK(pin) ((pin) >> 5)
> -#define GPIO_NUM(pin)((pin) & 0x1f)
> -
> -#define GPIO_CFG_INDEX(pin) (((pin) & 0x1f) >> 3)
> -#define GPIO_CFG_OFFSET(pin) pin) & 0x1f) & 0x7) << 2)
> -
> -#define GPIO_DRV_INDEX(pin) (((pin) & 0x1f) >> 4)
> -#define GPIO_DRV_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
> -
> -#define GPIO_PULL_INDEX(pin) (((pin) & 0x1f) >> 4)
> -#define GPIO_PULL_OFFSET(pin)pin) & 0x1f) & 0xf) << 1)
> -
> /* GPIO bank sizes */
> #define SUNXI_GPIOS_PER_BANK 32
>
> @@ -217,6 +204,7 @@ struct sunxi_gpio_plat {
> charbank_name[3];
> };
>
> +/* prototypes for the non-DM GPIO/pinctrl functions, used in the SPL */
> void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32
> val);
> void sunxi_gpio_set_cfgpin(u32 pin, u32 val);
> int sunxi_gpio_get_cfgbank(struct sunxi_gpio *pio, int bank_offset);
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index 58f807cb82d..671211e9322 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -10,7 +10,6 @@ obj-y += board.o
> obj-y+= clock.o
> obj-y+= cpu_info.o
> obj-y+= dram_helpers.o
> -obj-y+= pinmux.o
> obj-$(CONFIG_SUN6I_PRCM) += prcm.o
> obj-$(CONFIG_AXP_PMIC_BUS) += pmic_bus.o
> obj-$(CONFIG_MACH_SUNIV) += clock_sun6i.o
> diff --git a/arch/arm/mach-sunxi/pinmux.c b/arch/arm/mach-sunxi/pinmux.c
> deleted file mode 100644
> index c95fcee9f6c..000
> --- a/arch/arm/mach-sunxi/pinmux.c
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * (C) Copyright 2007-2011
> - * Allwinner Technology Co., Ltd.
> - * Tom Cubie
> - */
> -
> -#include
> -#include
> -#include
> -
> -void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32 val)
> -{
> - u32 index = GPIO_CFG_INDEX(bank_offset);
> - u32 offset = GPIO_CFG_OFFSET(bank_offset);
> -
> - clrsetbits_le32(>cfg[index], 0xf << offset, val << offset);
> -}
> -
> -void sunxi_gpio_set_cfgpin(u32 pin, u32 val)
> -{
> - u32 bank = GPIO_BANK(pin);
> - struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
> -
> - sunxi_gpio_set_cfgbank(pio, pin, val);
> -}
> -
> -int sunxi_gpio_get_cfgbank(struct sunxi_gpio *pio, int bank_offset)
> -{
> - u32 index = GPIO_CFG_INDEX(bank_offset);
> - u32 offset = GPIO_CFG_OFFSET(bank_offset);
> - u32 cfg;
> -
> - cfg = readl(>cfg[index]);
> - cfg >>= offset;
> -
> - return cfg & 0xf;
> -}
> -
> -int sunxi_gpio_get_cfgpin(u32 pin)
> -{
> - u32 bank = GPIO_BANK(pin);
> - struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
> -
> -
Re: [PATCH v3 06/32] sifive: Drop an unnecessary #ifdef
On Wed, Oct 18, 2023 at 01:23:13PM -0400, Sean Anderson wrote:
> On 10/18/23 09:51, Heinrich Schuchardt wrote:
> > On 10/17/23 00:27, Simon Glass wrote:
> > > This code is normally compiled for sifive, but sandbox can also compile
> > > it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
> > > possible to disable UNIT_TEST for sandbox.
> > >
> > > Drop the condition since it isn't needed.
> >
> > This is not what the patch does. It introduces another condition.
> >
> > >
> > > Signed-off-by: Simon Glass
> > > Suggested-by: Sean Anderson
> > > ---
> > >
> > > Changes in v3:
> > > - Just drop the condition instead
> > >
> > > include/k210/pll.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/k210/pll.h b/include/k210/pll.h
> > > index fd16a89cb203..6dd60b2eb4fc 100644
> > > --- a/include/k210/pll.h
> > > +++ b/include/k210/pll.h
> > > @@ -13,7 +13,7 @@ struct k210_pll_config {
> > > u8 od;
> > > };
> > >
> > > -#ifdef CONFIG_UNIT_TEST
> > > +#ifdef CONFIG_SANDBOX
> >
> > We should be able to compile with and without unit tests on the MAIX
> > boards. Why should CONFIG_SANDBOX have any relevance here?
> >
> > Why don't we make k210_pll_calc_config() non-static in all cases?
>
> U-Boot is smaller when it is static. But the forward declaration can be made
> unconditionally, as long as it is unused.
I think part of the problem with this patch is confusing what it's
doing. The issue here is that we can (and this is good!) and do compile
drivers/clk/clk_k210.c for sandbox, so it gets coverity scans and so
forth. However, if we build sandbox with UNIT_TEST=n then we get an
undefined reference to 'nop'. Because sandbox doesn't define nop().
This header then provides nop for sandbox. But, we can do something
clearer, now that this is spelled out.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/2] configs: rockchip: Use dwc3-generic driver on RK3328 and RK3399
On 10/19/23 00:30, Jonas Karlman wrote: [..] +++ b/configs/rock960-rk3399_defconfig @@ -50,6 +50,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -70,12 +71,12 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y Why not add 'default y if ROCKCHIP' into the Kconfig instead ? This will have the same effect, without requiring such massive modification of config files. (seems some of the CC domains are not even working, so CC list clipped)
Re: [PATCH 5/9] ram: k3-ddrss: Add exit retention support
Hi Thomas! On October 16, 2023 thus sayeth Thomas Richard: > Add the exit retention support. > The enter retention is done by DM-Firmware. > A part of the exit retention sequence is specific to the board. > It is done in board_k3_ddrss_lpddr4_release_retention. > > Based on the work of Gregory CLEMENT > > Signed-off-by: Thomas Richard > Signed-off-by: Gregory CLEMENT > --- > > drivers/ram/k3-ddrss/k3-ddrss.c | 302 > 1 file changed, 302 insertions(+) > Do you mind putting this behind some type of Kconfig option? For the am62* class of devices the amount of SRAM we have is really stretched thin. I'm worried this may put us over the top. ~Bryan
[PATCH 1/2] configs: rockchip: Use dwc3-generic driver on RK3328 and RK3399
Change to use the dwc3-generic driver on all RK3328 and RK3399 boards. MISC, USB_DWC3 and USB_DWC3_GENERIC are enabled on boards that enabled USB_XHCI_DWC3. Also enable DM_USB_GADGET for any board that enable USB_DWC3_GADGET. Signed-off-by: Jonas Karlman --- configs/chromebook_bob_defconfig | 2 +- configs/chromebook_kevin_defconfig| 2 +- configs/eaidk-610-rk3399_defconfig| 4 +++- configs/evb-rk3399_defconfig | 1 - configs/firefly-rk3399_defconfig | 1 - configs/khadas-edge-captain-rk3399_defconfig | 4 +++- configs/khadas-edge-rk3399_defconfig | 4 +++- configs/khadas-edge-v-rk3399_defconfig| 4 +++- configs/leez-rk3399_defconfig | 4 +++- configs/nanopc-t4-rk3399_defconfig| 4 +++- configs/nanopi-m4-2gb-rk3399_defconfig| 4 +++- configs/nanopi-m4-rk3399_defconfig| 4 +++- configs/nanopi-m4b-rk3399_defconfig | 4 +++- configs/nanopi-neo4-rk3399_defconfig | 4 +++- configs/nanopi-r4s-rk3399_defconfig | 3 ++- configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ++- configs/orangepi-r1-plus-rk3328_defconfig | 3 ++- configs/orangepi-rk3399_defconfig | 4 +++- configs/pinebook-pro-rk3399_defconfig | 1 - configs/pinephone-pro-rk3399_defconfig| 1 - configs/puma-rk3399_defconfig | 1 - configs/roc-pc-mezzanine-rk3399_defconfig | 2 +- configs/roc-pc-rk3399_defconfig | 2 +- configs/rock-4c-plus-rk3399_defconfig | 2 +- configs/rock-4se-rk3399_defconfig | 2 +- configs/rock-pi-4-rk3399_defconfig| 2 +- configs/rock-pi-4c-rk3399_defconfig | 2 +- configs/rock-pi-n10-rk3399pro_defconfig | 2 +- configs/rock960-rk3399_defconfig | 3 ++- configs/rockpro64-rk3399_defconfig| 1 - drivers/usb/host/Kconfig | 1 - 31 files changed, 50 insertions(+), 31 deletions(-) diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig index 1807e838223a..b5a5ae737e52 100644 --- a/configs/chromebook_bob_defconfig +++ b/configs/chromebook_bob_defconfig @@ -98,12 +98,12 @@ CONFIG_ROCKCHIP_SPI=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/chromebook_kevin_defconfig b/configs/chromebook_kevin_defconfig index 638beee2c6d3..20913d2cf0fe 100644 --- a/configs/chromebook_kevin_defconfig +++ b/configs/chromebook_kevin_defconfig @@ -99,12 +99,12 @@ CONFIG_ROCKCHIP_SPI=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/configs/eaidk-610-rk3399_defconfig b/configs/eaidk-610-rk3399_defconfig index 77edbdbf9597..22ad98b95ad3 100644 --- a/configs/eaidk-610-rk3399_defconfig +++ b/configs/eaidk-610-rk3399_defconfig @@ -40,6 +40,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -56,8 +57,9 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index 5740ffc38f6c..d6140527b752 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -66,7 +66,6 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig index b4660a051dfd..b7c8e95b7b89 100644 --- a/configs/firefly-rk3399_defconfig +++ b/configs/firefly-rk3399_defconfig @@ -66,7 +66,6 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig index ed06fe7846e6..8b6935d86730 100644 --- a/configs/khadas-edge-captain-rk3399_defconfig +++ b/configs/khadas-edge-captain-rk3399_defconfig @@ -43,6 +43,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y
[PATCH 2/2] rockchip: board: Remove dwc3 usb init and gadget handler functions
Remove board_usb_init() and dm_usb_gadget_handle_interrupts() functions
related to dwc3, they use e.g. a hard-coded reg address for RK3399 and
are obsolete with use of DM_USB_GADGET.
Use of DM_USB_GADGET, USB_DWC3_GENERIC and USB_DWC3_GADGET have replaced
same feature provided by the removed functions on RK3399 boards.
Signed-off-by: Jonas Karlman
---
arch/arm/mach-rockchip/board.c | 24
1 file changed, 24 deletions(-)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 57f08e0be0e9..3496839c879c 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -287,30 +287,6 @@ int board_usb_cleanup(int index, enum usb_init_type init)
}
#endif /* CONFIG_USB_GADGET_DWC2_OTG */
-#if defined(CONFIG_USB_DWC3_GADGET) && !defined(CONFIG_DM_USB_GADGET)
-#include
-
-static struct dwc3_device dwc3_device_data = {
- .maximum_speed = USB_SPEED_HIGH,
- .base = 0xfe80,
- .dr_mode = USB_DR_MODE_PERIPHERAL,
- .index = 0,
- .dis_u2_susphy_quirk = 1,
- .hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
-};
-
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
- dwc3_uboot_handle_interrupt(dev);
- return 0;
-}
-
-int board_usb_init(int index, enum usb_init_type init)
-{
- return dwc3_uboot_init(_device_data);
-}
-#endif /* CONFIG_USB_DWC3_GADGET */
-
#endif /* CONFIG_USB_GADGET */
#if IS_ENABLED(CONFIG_FASTBOOT)
--
2.42.0
[PATCH 0/2] rockchip: Use dwc3-generic driver on RK3328 and RK3399
This series change to use the dwc3-generic driver on all RK3328 and RK3399 boards. Also switch to use DM_USB_GADGET and remove then obsolete board_usb_init() and dm_usb_gadget_handle_interrupts() functions. First patch change all RK33xx boards to use dwc3-generic driver. Second patch remove obsolete rk3399 usb gadget functions. This has been tested and validated on rockpro64 and rock-pi-4 boards. Jonas Karlman (2): configs: rockchip: Use dwc3-generic driver on RK3328 and RK3399 rockchip: board: Remove dwc3 usb init and gadget handler functions arch/arm/mach-rockchip/board.c| 24 --- configs/chromebook_bob_defconfig | 2 +- configs/chromebook_kevin_defconfig| 2 +- configs/eaidk-610-rk3399_defconfig| 4 +++- configs/evb-rk3399_defconfig | 1 - configs/firefly-rk3399_defconfig | 1 - configs/khadas-edge-captain-rk3399_defconfig | 4 +++- configs/khadas-edge-rk3399_defconfig | 4 +++- configs/khadas-edge-v-rk3399_defconfig| 4 +++- configs/leez-rk3399_defconfig | 4 +++- configs/nanopc-t4-rk3399_defconfig| 4 +++- configs/nanopi-m4-2gb-rk3399_defconfig| 4 +++- configs/nanopi-m4-rk3399_defconfig| 4 +++- configs/nanopi-m4b-rk3399_defconfig | 4 +++- configs/nanopi-neo4-rk3399_defconfig | 4 +++- configs/nanopi-r4s-rk3399_defconfig | 3 ++- configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ++- configs/orangepi-r1-plus-rk3328_defconfig | 3 ++- configs/orangepi-rk3399_defconfig | 4 +++- configs/pinebook-pro-rk3399_defconfig | 1 - configs/pinephone-pro-rk3399_defconfig| 1 - configs/puma-rk3399_defconfig | 1 - configs/roc-pc-mezzanine-rk3399_defconfig | 2 +- configs/roc-pc-rk3399_defconfig | 2 +- configs/rock-4c-plus-rk3399_defconfig | 2 +- configs/rock-4se-rk3399_defconfig | 2 +- configs/rock-pi-4-rk3399_defconfig| 2 +- configs/rock-pi-4c-rk3399_defconfig | 2 +- configs/rock-pi-n10-rk3399pro_defconfig | 2 +- configs/rock960-rk3399_defconfig | 3 ++- configs/rockpro64-rk3399_defconfig| 1 - drivers/usb/host/Kconfig | 1 - 32 files changed, 50 insertions(+), 55 deletions(-) -- 2.42.0
[PATCH] arm: mvebu: AC5/AC5X: use fixed page table size
Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
when available") the default get_page_table_size() sets some flags for
more efficient handling of dirty page table entries. This causes
problems on the AC5/AC5X SoC (specifically a lockup when calling
__asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
The reason for the lockup isn't at all clear but it can be avoided if we
provide our own get_page_table_size() which stops gd->arch.has_hafdbs
from being set to true effectively returning the AC5/AC5X to the older
behaviour. This also opts for a simple fixed page table size rather than
trying to duplicate the more complicated logic to optimise the table
size.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
b/arch/arm/mach-mvebu/alleycat5/cpu.c
index 8204d9627515..7ba57ae75e76 100644
--- a/arch/arm/mach-mvebu/alleycat5/cpu.c
+++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
@@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
struct mm_region *mem_map = ac5_mem_map;
+u64 get_page_table_size(void)
+{
+ return 0x8;
+}
+
void reset_cpu(void)
{
}
--
2.42.0
[PATCH 2/2] imx8mp_evk: Add myself to MAINTAINERS
From: Fabio Estevam I would like to help maintaining the imx8mp_evk board. Add myself to MAINTAINERS. Signed-off-by: Fabio Estevam --- board/freescale/imx8mp_evk/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/freescale/imx8mp_evk/MAINTAINERS b/board/freescale/imx8mp_evk/MAINTAINERS index 2759652cc425..c2c7c830b5d2 100644 --- a/board/freescale/imx8mp_evk/MAINTAINERS +++ b/board/freescale/imx8mp_evk/MAINTAINERS @@ -1,4 +1,5 @@ i.MX8MP EVK BOARD +M: Fabio Estevm M: Peng Fan S: Maintained F: board/freescale/imx8mp_evk/ -- 2.34.1
[PATCH 1/2] imx8mp_evk: Convert to DM_PMIC
From: Fabio Estevam
Currently, the imx8mp_evk uses the non-DM code to initialize the PMIC.
Convert to DM_PMIC, which is the recommended way to access the PMIC.
While at it, fix multi-line comments style.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx8mp-evk-u-boot.dtsi | 18 ++-
board/freescale/imx8mp_evk/spl.c| 50 +++--
configs/imx8mp_evk_defconfig| 12 +++
3 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index 9ed62f1bb02d..0bf489b46248 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -13,6 +13,22 @@
};
};
+_i2c1 {
+ bootph-all;
+};
+
+_pmic {
+ bootph-all;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
+ bootph-all;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
+ bootph-all;
+};
+
_usdhc2_vmmc {
u-boot,off-on-delay-us = <2>;
};
@@ -66,7 +82,7 @@
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c
index 246826a0d482..9dd2cbc799c3 100644
--- a/board/freescale/imx8mp_evk/spl.c
+++ b/board/freescale/imx8mp_evk/spl.c
@@ -67,40 +67,44 @@ struct i2c_pads_info i2c_pad_info1 = {
},
};
-#if CONFIG_IS_ENABLED(POWER_LEGACY)
-#define I2C_PMIC 0
+#if CONFIG_IS_ENABLED(DM_PMIC_PCA9450)
int power_init_board(void)
{
- struct pmic *p;
+ struct udevice *dev;
int ret;
- ret = power_pca9450_init(I2C_PMIC, 0x25);
- if (ret)
- printf("power init failed");
- p = pmic_get("PCA9450");
- pmic_probe(p);
+ ret = pmic_get("pmic@25", );
+ if (ret == -ENODEV) {
+ puts("No pmic@25\n");
+ return 0;
+ }
+ if (ret < 0)
+ return ret;
/* BUCKxOUT_DVS0/1 control BUCK123 output */
- pmic_reg_write(p, PCA9450_BUCK123_DVS, 0x29);
+ pmic_reg_write(dev, PCA9450_BUCK123_DVS, 0x29);
/*
-* increase VDD_SOC to typical value 0.95V before first
-* DRAM access, set DVS1 to 0.85v for suspend.
+* Increase VDD_SOC to typical value 0.95V before first
+* DRAM access, set DVS1 to 0.85V for suspend.
* Enable DVS control through PMIC_STBY_REQ and
* set B1_ENMODE=1 (ON by PMIC_ON_REQ=H)
*/
-#ifdef CONFIG_IMX8M_VDD_SOC_850MV
- /* set DVS0 to 0.85v for special case*/
- pmic_reg_write(p, PCA9450_BUCK1OUT_DVS0, 0x14);
-#else
- pmic_reg_write(p, PCA9450_BUCK1OUT_DVS0, 0x1C);
-#endif
- pmic_reg_write(p, PCA9450_BUCK1OUT_DVS1, 0x14);
- pmic_reg_write(p, PCA9450_BUCK1CTRL, 0x59);
+ if (CONFIG_IS_ENABLED(IMX8M_VDD_SOC_850MV))
+ pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS0, 0x14);
+ else
+ pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS0, 0x1C);
- /* Kernel uses OD/OD freq for SOC */
- /* To avoid timing risk from SOC to ARM,increase VDD_ARM to OD voltage
0.95v */
- pmic_reg_write(p, PCA9450_BUCK2OUT_DVS0, 0x1C);
+ pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS1, 0x14);
+ pmic_reg_write(dev, PCA9450_BUCK1CTRL, 0x59);
+
+ /*
+* Kernel uses OD/OD freq for SOC.
+* To avoid timing risk from SOC to ARM,increase VDD_ARM to OD
+* voltage 0.95V.
+*/
+
+ pmic_reg_write(dev, PCA9450_BUCK2OUT_DVS0, 0x1C);
return 0;
}
@@ -135,8 +139,6 @@ void board_init_f(ulong dummy)
enable_tzc380();
- setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
-
power_init_board();
/* DDR initialization */
diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
index 820dc36e9cdd..0675f0f4f41b 100644
--- a/configs/imx8mp_evk_defconfig
+++ b/configs/imx8mp_evk_defconfig
@@ -7,9 +7,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_ENV_SIZE=0x1000
CONFIG_ENV_OFFSET=0x40
-CONFIG_SYS_I2C_MXC_I2C1=y
-CONFIG_SYS_I2C_MXC_I2C2=y
-CONFIG_SYS_I2C_MXC_I2C3=y
CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk"
CONFIG_SPL_TEXT_BASE=0x92
@@ -88,8 +85,6 @@ CONFIG_FASTBOOT_MMC_USER_SUPPORT=y
CONFIG_MXC_GPIO=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
-# CONFIG_SPL_DM_I2C is not set
-CONFIG_SPL_SYS_I2C_LEGACY=y
CONFIG_LED=y
CONFIG_LED_GPIO=y
CONFIG_SUPPORT_EMMC_BOOT=y
@@ -110,15 +105,16 @@ CONFIG_PHY_IMX8MQ_USB=y
CONFIG_PINCTRL=y
CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_IMX8M=y
-CONFIG_SPL_POWER_LEGACY=y
CONFIG_POWER_DOMAIN=y
CONFIG_IMX8M_POWER_DOMAIN=y
CONFIG_IMX8MP_HSIOMIX_BLKCTRL=y
-CONFIG_POWER_PCA9450=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_PCA9450=y
+CONFIG_SPL_DM_PMIC_PCA9450=y
CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PCA9450=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
-CONFIG_SPL_POWER_I2C=y
CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
CONFIG_SYSRESET=y
--
2.34.1
Re: [PATCH v4] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
On 10/18/23 20:55, Fabio Estevam wrote:
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Also change the Ethernet PHY address to 5, as per Marek's feedback.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Change the Ethernet PHY address to 5 for good :-). (Marek)
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429abe4..bad015536166 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@5 {
+ reg = <5>;
The reg should be 'reg = <7>' ;-) It's just the node name which should
be 'ethernet-phy@5'. (Yes, I know, it is not consistent, that's because
the DTO cannot "rename" the node itself easily).
[PATCH v4] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Also change the Ethernet PHY address to 5, as per Marek's feedback.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Change the Ethernet PHY address to 5 for good :-). (Marek)
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429abe4..bad015536166 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@5 {
+ reg = <5>;
+ };
+ };
};
--
2.34.1
Re: [PATCH v3] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
On 10/18/23 20:52, Fabio Estevam wrote:
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Also change the Ethernet PHY address to 5, as per Marek's feedback.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Change the Ethernet PHY address to 5. (Marek)
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429abe4..bad015536166 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@7 {
Did you miss git commit --amend or git rebase --autosquash ? :)
This is still @7 here .
[PATCH v3] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Also change the Ethernet PHY address to 5, as per Marek's feedback.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Change the Ethernet PHY address to 5. (Marek)
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429abe4..bad015536166 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@7 {
+ reg = <7>;
+ };
+ };
};
--
2.34.1
[PATCH v2] arm: mxs: Clear CPSR V bit to activate low vectors
The MXS starts with CPSR V bit set, which makes the CPU jump to high vectors
in case of an exception. Those high vectors are located at 0x, which
is where the BootROM exception table is located as well. U-Boot should handle
exceptions on its own using its own exception handling code, which is located
at 0x0, i.e. at low vectors. Clear the CPSR V bit, so that the CPU would jump
to low vectors on exception instead, and therefore run the U-Boot exception
handling code.
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Fabio Estevam
Cc: Lukasz Majewski
Cc: Stefano Babic
---
V2: Mark both get_cr()/set_cr() callsites as __attribute__((target("arm")))
and noinline to force generation of ARM version of those functions,
as this core cannot run mrc/mcr in Thumb mode. This is truly hideous
workaround right here.
---
arch/arm/cpu/arm926ejs/mxs/mxs.c | 4
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 8 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs.c b/arch/arm/cpu/arm926ejs/mxs/mxs.c
index 6d6166cb839..4f3cb63c56d 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs.c
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs.c
@@ -71,6 +71,7 @@ void reset_cpu(void)
* actually 0x20, this the associated . Loading the PC
* register with an address performs a jump to that address.
*/
+noinline __attribute__((target("arm")))
void mx28_fixup_vt(uint32_t start_addr)
{
/* ldr pc, [pc, #0x18] */
@@ -85,6 +86,9 @@ void mx28_fixup_vt(uint32_t start_addr)
/* cppcheck-suppress nullPointer */
vt[i + 8] = start_addr + (4 * i);
}
+
+ /* Make sure ARM core points to low vectors */
+ set_cr(get_cr() & ~CR_V);
}
#ifdef CONFIG_ARCH_MISC_INIT
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 5e7bdb78be1..249f8de8fbe 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "mxs_init.h"
@@ -93,7 +94,9 @@ static uint8_t mxs_get_bootmode_index(void)
return i;
}
-static void mxs_spl_fixup_vectors(void)
+static noinline
+__attribute__((target("arm")))
+void mxs_spl_fixup_vectors(void)
{
/*
* Copy our vector table to 0x0, since due to HAB, we cannot
@@ -104,6 +107,9 @@ static void mxs_spl_fixup_vectors(void)
/* cppcheck-suppress nullPointer */
memcpy(0x0, _start, 0x60);
+
+ /* Make sure ARM core points to low vectors */
+ set_cr(get_cr() & ~CR_V);
}
static void mxs_spl_console_init(void)
--
2.42.0
[PATCH] arm: dts: imx8mp-venice-gw73xx: add TPM device
Add the TPM device found on the GW73xx revision F PCB.
This hangs off of SPI2, uses gpio1_10 as a CS and gpio1_11 as RST#.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi | 9 +
arch/arm/dts/imx8mp-venice-gw73xx.dtsi | 9 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
b/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
index 70433c073293..4d0e9a1e67c5 100644
--- a/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
@@ -10,6 +10,15 @@
reset-post-delay-us = <30>;
};
+ {
+ tpm_rst {
+ gpio-hog;
+ output-high;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ line-name = "tpm_rst#";
+ };
+};
+
{
dio_1 {
gpio-hog;
diff --git a/arch/arm/dts/imx8mp-venice-gw73xx.dtsi
b/arch/arm/dts/imx8mp-venice-gw73xx.dtsi
index 1c05398c862c..88c3c006fa20 100644
--- a/arch/arm/dts/imx8mp-venice-gw73xx.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw73xx.dtsi
@@ -95,8 +95,14 @@
{
pinctrl-names = "default";
pinctrl-0 = <_spi2>;
- cs-gpios = < 13 GPIO_ACTIVE_LOW>;
+ cs-gpios = < 13 GPIO_ACTIVE_LOW>,
+ < 10 GPIO_ACTIVE_LOW>;
status = "okay";
+ tpm@1 {
+ compatible = "tcg,tpm_tis-spi";
+ reg = <0x1>;
+ spi-max-frequency = <3600>;
+ };
};
{
@@ -327,6 +333,7 @@
MX8MP_IOMUXC_ECSPI2_MOSI__ECSPI2_MOSI 0x140
MX8MP_IOMUXC_ECSPI2_MISO__ECSPI2_MISO 0x140
MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x140
+ MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10 0x140
>;
};
--
2.25.1
[PATCH] arm: dts: imx8mm-venice-gw73xx: add TPM device
Add the TPM device found on the GW73xx revision F PCB.
This hangs off of SPI2, uses gpio1_10 as a CS and gpio1_11 as RST#.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi | 7 +++
arch/arm/dts/imx8mm-venice-gw73xx.dtsi | 10 +-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
index 92e44d4ba96b..31f9d47bced8 100644
--- a/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
@@ -39,6 +39,13 @@
gpios = <9 GPIO_ACTIVE_HIGH>;
line-name = "dio1";
};
+
+ tpm_rst {
+ gpio-hog;
+ output-high;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ line-name = "tpm_rst#";
+ };
};
{
diff --git a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
index 244ef8d6cc68..7b2130dbdb21 100644
--- a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
@@ -104,8 +104,15 @@
{
pinctrl-names = "default";
pinctrl-0 = <_spi2>;
- cs-gpios = < 13 GPIO_ACTIVE_LOW>;
+ cs-gpios = < 13 GPIO_ACTIVE_LOW>,
+ < 10 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ tpm@1 {
+ compatible = "tcg,tpm_tis-spi";
+ reg = <0x1>;
+ spi-max-frequency = <3600>;
+ };
};
{
@@ -364,6 +371,7 @@
MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI0xd6
MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO0xd6
MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0xd6
+ MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0xd6
>;
};
--
2.25.1
[PATCH] board: gateworks: venice: add fixup for GW73xx-F+
GW73xx-F board revision switched back to the original PCIe switch due to
part availability.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/venice.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
index a39ae58c8a09..0902a1da3e26 100644
--- a/board/gateworks/venice/venice.c
+++ b/board/gateworks/venice/venice.c
@@ -238,12 +238,12 @@ int ft_board_setup(void *fdt, struct bd_info *bd)
if (!strncmp(base_model, "GW73", 4)) {
pcbrev = get_pcb_rev(base_model);
- if (pcbrev > 'B') {
+ if (pcbrev > 'B' && pcbrev < 'E') {
printf("adjusting dt for %s\n", base_model);
/*
-* revC replaced PCIe 5-port switch with 4-port
-* which changed ethernet1 PCIe GbE
+* revC/D/E has PCIe 4-port switch which changes
+* ethernet1 PCIe GbE:
* from: pcie@0,0/pcie@1,0/pcie@2,4/pcie@6.0
* to: pcie@0,0/pcie@1,0/pcie@2,3/pcie@5.0
*/
--
2.25.1
[PATCH v2 2/4] ARM: imx: Factor out parsing of ROM log
> From: Fedor Ross > Factor out parsing of ROM log in function spl_mmc_emmc_boot_partition(). > This can be helpful to detect a secondary image boot without fiddling > around with MMC partitions. This way for example, U-Boot is able to > detect a secondary image boot and can enter some fallback scenario like > starting a recovery mode. > Signed-off-by: Fedor Ross > Signed-off-by: Marek Vasut Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH 2/2] dm: adc: imx93-adc depends on ADC (fix boot)
> The i.MX93 11x11 EVK fails to boot with following error:
> Model: NXP i.MX93 11X11 EVK board
> DRAM: 2 GiB
> Error binding driver 'imx93-adc': -96
> Some drivers failed to bind
> Error binding driver 'simple_bus': -96
> Some drivers failed to bind
> Error binding driver 'simple_bus': -96
> Some drivers failed to bind
> initcall sequence fffb8f28 failed at call 8021e0d4 (err=-96)
> ### ERROR ### Please RESET the board ###
> That's because since commit e7ff54d96303 ("imx93_evk: defconfig: add adc
> support") CONFIG_ADC_IMX93 is enabled but CONFIG_ADC is not.
> Fix this by enabling CONFIG_ADC in imx93_11x11_evk_defconfig.
> Make sure this situation won't happen again in future i.MX93 defconfig by
> making CONFIG_ADC_IMX93 depend on CONFIG_ADC.
> Signed-off-by: Sébastien Szymanski
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
[PATCH 1/2] arm: dts: imx93-11x11-evk: add bootph-some-ram property
> i.MX93 11x11 EVK fails to boot:
> U-Boot SPL 2023.10-00558-g65b9b3462bec-dirty (Oct 03 2023 - 17:40:10 +0200)
> SOC: 0xa0009300
> LC: 0x40010
> M33 prepare ok
> Normal Boot
> Trying to boot from BOOTROM
> Boot Stage: Primary boot
> image offset 0x8000, pagesize 0x200, ivt offset 0x0
> Load image from 0x44400 by ROM_API
> NOTICE: BL31: v2.8(release):android-13.0.0_2.0.0-0-ge4b2dbfa52f5
> NOTICE: BL31: Built : 17:52:46, Sep 28 2023
> That's because commit 9e644284ab81 ("dm: core: Report
> bootph-pre-ram/sram node as pre-reloc after relocation"):
> "[This] changes behavior of what nodes are bound in the U-Boot
> proper pre-relocation phase. Change to bootph-all or add
> bootph-some-ram prop to restore prior behavior."
> Fix this by adding bootph-some-ram prop as suggested by the commit
> above.
> Fixes: 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
> after relocation")
> Signed-off-by: Sébastien Szymanski
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
[PATCH v2 3/4] ARM: imx: Use correct U-Boot offset in case of secondary boot from eMMC
> From: Fedor Ross > In case of a secondary image boot from the user area of an eMMC device, > the correct offset must be calculated. The offset is fused in the fuse > IMG_CNTN_SET1_OFFSET of the i.MX8M Nano and Plus. The calculation of the > offset is described in the reference manual (IMX8MNRM Rev. 2, 07/2022 > and IMX8MPRM Rev. 1, 06/2021): > The fuse IMG_CNTN_SET1_OFFSET (0x490[22:19]) is defined as follows: > * Secondary boot is disabled if fuse value is bigger than 10, > n = fuse value bigger than 10. > * n == 0: Offset = 4MB > * n == 2: Offset = 1MB > * Others & n <= 10 : Offset = 1MB*2^n > Signed-off-by: Fedor Ross > Signed-off-by: Marek Vasut Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 1/4] spl: mmc: Introduce proper layering for spl_mmc_get_uboot_raw_sector()
> Introduce two new weak functions, arch_spl_mmc_get_uboot_raw_sector() and > board_spl_mmc_get_uboot_raw_sector(), each of which can be overridden at > a matching level, that is arch/ and board/ , in addition to the existing > weak function spl_mmc_get_uboot_raw_sector(). > This way, architecture code can define a default architecture specific > implementation of arch_spl_mmc_get_uboot_raw_sector(), while the board > code can override that using board_spl_mmc_get_uboot_raw_sector() which > takes precedence over the architecture code. In some sort of unlikely > special case where code has to take precedence over board code too, the > spl_mmc_get_uboot_raw_sector() is still left out to be a weak function, > but it should be unlikely that this is ever needed to be overridden. > Signed-off-by: Marek Vasut Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 4/4] ARM: imx: Add support for detecting primary/secondary bmode on MX8M
> From: Fedor Ross > Implement the 'getprisec' subcommand of 'bmode' command for i.MX8M by > reading out the ROM log events. This event is set by the BootROM if it > switched to the secondary copy due to primary copy being corrupted. > Signed-off-by: Fedor Ross > Signed-off-by: Marek Vasut Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH v2] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
On 10/18/23 19:54, Fabio Estevam wrote:
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Signed-off-by: Fabio Estevam
Reviewed-by: Marek Vasut
---
Changes since v1:
- Remove the ethphy0g label. (Marek)
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429abe4..bad015536166 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@7 {
One more thing to fix, this should be ethernet-phy@5 , not
ethernet-phy@7 . This is a local fix up for old hardware, which
overrides the PHY MDIO address, see:
arch/arm/dts/imx8mp-dhcom-som.dtsi: ethphy0g: ethernet-phy@5
{ /* Micrel KSZ9131RNXI */
[PATCH v2] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Signed-off-by: Fabio Estevam
Reviewed-by: Marek Vasut
---
Changes since v1:
- Remove the ethphy0g label. (Marek)
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429abe4..bad015536166 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@7 {
+ reg = <7>;
+ };
+ };
};
--
2.34.1
Re: [PATCH] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
On 10/18/23 19:21, Fabio Estevam wrote:
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429ab..94bee3c508 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0g: ethernet-phy@7 {
I think the ethphy0g: label shouldn't be needed, in fact it would
override whatever label is already in the base DT. So please drop that
one. With that fixed:
Reviewed-by: Marek Vasut
Re: [PATCH v5 00/11] spl: Use common function for loading/parsing images
On 8/3/23 00:41, Heinrich Schuchardt wrote: On 8/3/23 03:31, Tom Rini wrote: On Wed, Aug 02, 2023 at 09:13:21PM -0400, Sean Anderson wrote: On 8/2/23 16:11, Tom Rini wrote: On Mon, Jul 31, 2023 at 06:42:52PM -0400, Sean Anderson wrote: This series adds support for loading all image types (Legacy, FIT (with and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR, NET, FAT, and EXT load methods. It does this by introducing a helper function which handles the minutiae of invoking the proper parsing function, and reading the rest of the image. Hopefully, this will make it easier for load methods to support all image types that U-Boot supports, without having undocumented unsupported image types. I applied this to several loaders which were invoking spl_load_simple_fit and/or spl_parse_image_header, but I did not use it with others (e.g. DFU/RAM) which had complications in the mix. In order to meet size requirements for some boards, the first two patches of this series are general size-reduction changes. The ffs/fls change in particular should reduce code size across the board. The malloc change also has the potential to reduce code size. I've left it disabled by default, but maybe we can reverse that in the future. Here's some bloat-o-meter for j7200_evm_a72_defconfig with ext4 support enabed: add/remove: 2/1 grow/shrink: 1/5 up/down: 444/-584 (-140) Function old new delta spl_load - 216 +216 spl_simple_read - 184 +184 spl_fit_read 60 104 +44 file_fat_read 40 - -40 spl_nor_load_image 120 76 -44 spl_load_image_ext 364 296 -68 spl_load_image_fat 320 200 -120 spl_spi_load_image 304 176 -128 spl_mmc_load 716 532 -184 Total: Before=233618, After=233478, chg -0.06% For most boards with a few load methods, this series should break even. However, in the worst case this series will add around 100 bytes. I have only tested a few loaders. Please try booting your favorite board with NOR/SPI flash or SPI falcon mode. On sama5d27_wlsom1_ek_mmc_defconfig, 100 bytes is too much, so this series depends on [1] to fit everything in. CI run at [2]. [1] https://lore.kernel.org/u-boot/20230731223327.109865-1-sean.ander...@seco.com/ [2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/17116 I've boot-tested this on my lab and a handful of SD+FAT or SD+raw boot devices, and it's all worked. I also did my usual world build before/after to check out the size changes and well, I don't know. The size wins come on platforms where there's both FAT+EXT support. And then on mips with say mt7620_rfb I wonder if we're loosing functionality. Yes we are. I'll address this in v6. But most platforms grow a bit, especially if they're just a single load type (which is the most common case). Maybe this problem needs to be approached another way? I've put the whole log over at https://gist.github.com/trini/e6772b2134e0eb44393364ea98729e06 and maybe something will jump out to you. The fls/ffs patch [1] reduces the growth by around 80 bytes on ARM platforms. I sent it separately for ease of review, but it really should be applied before this series, since a good portion of the growth is due to that one function call. It seems like MIPS also has this instruction (and Linux uses it), so I can try putting together a patch for it as well. In the future, I would like to convert bl_len to bl_shift or something, which would remove the need for fls (and going from bl_shift to bl_len is just a shift). spl_load_info is used in a lot of places, so I wanted to do that in a follow-up. On arches with efficient fls implementations the difference is only around 3 instructions or so. But fundamentally some of the problem is that the logic is being moved into multiple translation units, so the compiler can't see enough to make optimizations. For example, all filesystems use a bl_len of 1, so all the multiplications/roundings/etc. can be eliminated if the compiler can see that. For example, on arm64 copying spl_load into spl_fat.c (as fat_load) and making it static saves us 100 bytes: add/remove: 3/1 grow/shrink: 0/1 up/down: 324/-92 (232) Function old new delta spl_load - 160 +160 spl_simple_read - 104 +104 spl_fit_read - 60 +60 file_fat_read 40 - -40 spl_load_image_fat 252 200 -52 Total: Before=66833, After=67065, chg +0.35% add/remove: 2/1 grow/shrink: 1/0 up/down: 172/-40 (132) Function
Re: [PATCH v3 06/32] sifive: Drop an unnecessary #ifdef
On 10/18/23 09:51, Heinrich Schuchardt wrote:
On 10/17/23 00:27, Simon Glass wrote:
This code is normally compiled for sifive, but sandbox can also compile
it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
possible to disable UNIT_TEST for sandbox.
Drop the condition since it isn't needed.
This is not what the patch does. It introduces another condition.
Signed-off-by: Simon Glass
Suggested-by: Sean Anderson
---
Changes in v3:
- Just drop the condition instead
include/k210/pll.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/k210/pll.h b/include/k210/pll.h
index fd16a89cb203..6dd60b2eb4fc 100644
--- a/include/k210/pll.h
+++ b/include/k210/pll.h
@@ -13,7 +13,7 @@ struct k210_pll_config {
u8 od;
};
-#ifdef CONFIG_UNIT_TEST
+#ifdef CONFIG_SANDBOX
We should be able to compile with and without unit tests on the MAIX
boards. Why should CONFIG_SANDBOX have any relevance here?
Why don't we make k210_pll_calc_config() non-static in all cases?
U-Boot is smaller when it is static. But the forward declaration can be made
unconditionally, as long as it is unused.
--Sean
[PATCH] imx8mp-dhcom-pdk3-overlay-rev100: Pass #address-cells/size-cells
From: Fabio Estevam
Pass #address-cells/size-cells in the mdio node to avoid the following
DTC warning:
DTCOarch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo
Warning (reg_format): /fragment@0/__overlay__:reg: property has invalid length
(4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#address-cells value
Warning (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
#size-cells value
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
index f27e6429ab..94bee3c508 100644
--- a/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
+++ b/arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dts
@@ -5,6 +5,13 @@
/dts-v1/;
/plugin/;
- {
- reg = <7>;
+ {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0g: ethernet-phy@7 {
+ reg = <7>;
+ };
+ };
};
--
2.34.1
Re: [PATCH v5 1/6] sysinfo: Add IDs for board id and revision
On Monday, October 16, 2023 1:37:40 P.M. EDT Heinrich Schuchardt wrote:
> On 10/2/23 17:20, Detlev Casanova wrote:
> > These IDs will be used by the sysinfo command. The new IDs are:
> > * SYSINFO_ID_BOARD_ID: The board ID as an integer
> > * SYSINFO_ID_BOARD_REV_MAJOR: The board major revision as int
> > * SYSINFO_ID_BOARD_REV_MINOR: The board minor revision as int
>
> Integers will not work in the generic case. E.g. for the VisionFive 2
> board we have seen board revisions:
>
> 1.2A, 1.2B, 1.3B
>
> For the Wandboard:
>
> B1, D1
>From this, I gather that the revision should just be a string value, as there
is no generic way to represent all variations of the revision "numbers".
> > Reviewed-by: Marek Vasut
> > Signed-off-by: Detlev Casanova
> > ---
> >
> > include/sysinfo.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/include/sysinfo.h b/include/sysinfo.h
> > index b140d742e93..13815600ae6 100644
> > --- a/include/sysinfo.h
> > +++ b/include/sysinfo.h
> > @@ -47,6 +47,11 @@ enum sysinfo_id {
> >
> > /* For show_board_info() */
> > SYSINFO_ID_BOARD_MODEL,
> >
> > + /* For sysinfo command (all int) */
>
> Please, provide a Sphinx style documentation for every value. Cf.
> https://www.kernel.org/doc/html/v5.3/doc-guide/kernel-doc.html#structure-uni
> on-and-enumeration-documentation
>
> Best regards
>
> Heinrich
>
> > + SYSINFO_ID_BOARD_ID,
> > + SYSINFO_ID_BOARD_REV_MAJOR,
> > + SYSINFO_ID_BOARD_REV_MINOR,
> > +
> >
> > /* First value available for downstream/board used */
> > SYSINFO_ID_USER = 0x1000,
> >
> > };
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
Hi Tom, On Wed, 18 Oct 2023 at 09:27, Tom Rini wrote: > > On Wed, Oct 18, 2023 at 09:23:42AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 18 Oct 2023 at 07:37, Tom Rini wrote: > > > > > > On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote: > > > > > > > Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is > > > > available, add it as an explicit dependency. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > (no changes since v2) > > > > > > > > Changes in v2: > > > > - Add new patch to update EFI_LOADER to depend on DM_ETH > > > > > > > > lib/efi_loader/Kconfig | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > index 13cad6342c36..fca4b3eef270 100644 > > > > --- a/lib/efi_loader/Kconfig > > > > +++ b/lib/efi_loader/Kconfig > > > > @@ -11,6 +11,7 @@ config EFI_LOADER > > > > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > > > > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > > > > depends on BLK > > > > + depends on DM_ETH > > > > depends on !EFI_APP > > > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 > > > > select CHARSET > > > > > > I don't think this is needed. After reconfiguring qemu_arm64 to be able > > > to disable networking entirely, we still are able to build with > > > EFI_LOADER enabled, and no warning / link errors. > > > > Fair enough. > > > > As of this patch the following errors are generated with -a ~CMDLINE : > > > > +lib/efi_loader/efi_device_path.c:985:(.text+0xca4): undefined > > reference to `eth_get_dev' > > +/bin/ld: lib/efi_loader/efi_device_path.c:987:(.text+0xca9): > > undefined reference to `eth_get_dev' > > +/bin/ld: lib/efi_loader/efi_device_path.c:993:(.text+0xcc9): > > undefined reference to `eth_get_dev' > > +/bin/ld: lib/efi_loader/efi_device_path.o: in function `efi_dp_from_name': > > +lib/efi_loader/efi_device_path.c:1095:(.text+0xe00): undefined > > reference to `efi_get_image_parameters' > > > > which is why I added this patch. A later patch disables networking > > entirely with ~CMDLINE so that is why this problem goes away. > > > > This series was basically built up by disabling CMDLINE and then > > fixing the errors one by one. I didn't go back and check whether (at > > the end) all the patches were needed. > > Yes, part of the issue with the series is that you didn't go and rework > things after getting CMDLINE to link for sandbox, to see what else is or > is not still needed. > > > I could do that and send a v4, if your more general concerns can be sorted > > out. > > Don't worry about a v4 currently please, I'm working through the issues > now picking out parts of v3 and re-working others. OK, thanks. Regards, Simon
Re: [PATCH v2 1/1] sunxi: H616: add LPDDR4 DRAM support
On Mon, 16 Oct 2023 08:34:41 +0300
Mikhail Kalashnikov wrote:
Hi Mikhail,
many thanks for resending this, and particularly for making this work on
the OrangePi Zero3!
> From: iuncuim
>
> The H616 SoC family has support for several types of DRAM: DDR3,
> LPDDR3, DDR4 and LPDDR4.
> At the moment, the driver only supports DDR3 and LPDDR3 memory.
> Let's extend the driver to support the LPDDR4 memory. This type
> of memory widely used in device with T507(-H) SoC and new orangepi
> zero3 with H618.
> The compatibility with T507 is not yet complete, because there
> is difference in the phy_init array.
> The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT
> found on the Orangepi Zero 3 4GB.
>
> Signed-off-by: Mikhail Kalashnikov
>
> ---
> .../include/asm/arch-sunxi/dram_sun50i_h616.h | 2 +
> arch/arm/mach-sunxi/Kconfig | 16 ++
> arch/arm/mach-sunxi/dram_sun50i_h616.c| 176 ++
> arch/arm/mach-sunxi/dram_timings/Makefile | 1 +
> .../dram_timings/h616_lpddr4_2133.c | 97 ++
> 5 files changed, 258 insertions(+), 34 deletions(-)
> create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr4_2133.c
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index 11774deded..a8fdda124a 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -130,6 +130,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
> #define MSTR_DEVICETYPE_LPDDR2 BIT(2)
> #define MSTR_DEVICETYPE_LPDDR3 BIT(3)
> #define MSTR_DEVICETYPE_DDR4 BIT(4)
> +#define MSTR_DEVICETYPE_LPDDR4 BIT(5)
> #define MSTR_DEVICETYPE_MASK GENMASK(5, 0)
> #define MSTR_2TMODE BIT(10)
> #define MSTR_BUSWIDTH_FULL (0 << 12)
> @@ -154,6 +155,7 @@ struct dram_para {
> u32 odt_en;
> u32 tpr0;
> u32 tpr2;
> + u32 tpr6;
> u32 tpr10;
> u32 tpr11;
> u32 tpr12;
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 9d5df2c102..71e2f40b9e 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -85,6 +85,11 @@ config DRAM_SUN50I_H616_TPR2
> help
> TPR2 value from vendor DRAM settings.
>
> +config DRAM_SUN50I_H616_TPR6
> + hex "H616 DRAM TPR6 parameter"
I think that deserves some default value, otherwise a simple "make" for
existing boards will now ask for that value.
What about 0x3300c080? Looking down, that should cover the existing cases,
since the different DDR types use different bytes in this word?
> + help
> + TPR6 value from vendor DRAM settings.
> +
> config DRAM_SUN50I_H616_TPR10
> hex "H616 DRAM TPR10 parameter"
> help
> @@ -441,6 +446,9 @@ config SUNXI_DRAM_DDR2
> config SUNXI_DRAM_LPDDR3
> bool
>
> +config SUNXI_DRAM_LPDDR4
> + bool
> +
> choice
> prompt "DRAM Type and Timing"
> default SUNXI_DRAM_DDR3_1333 if !MACH_SUN8I_V3S
> @@ -484,6 +492,14 @@ config SUNXI_DRAM_H616_LPDDR3
> This option is the LPDDR3 timing used by the stock boot0 by
> Allwinner.
>
> +config SUNXI_DRAM_H616_LPDDR4
> + bool "LPDDR4 DRAM chips on the H616 DRAM controller"
> + select SUNXI_DRAM_LPDDR4
> + depends on DRAM_SUN50I_H616
> + help
> + This option is the LPDDR4 timing used by the stock boot0 by
> + Allwinner.
> +
> config SUNXI_DRAM_H616_DDR3_1333
> bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> select SUNXI_DRAM_DDR3
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index ba5659d409..2c4b47bae7 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -238,6 +238,11 @@ static const u8 phy_init[] = {
> 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
> 0x17, 0x19, 0x1a
> +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR4)
> + 0x02, 0x00, 0x17, 0x05, 0x04, 0x19, 0x06, 0x07,
> + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x01,
> + 0x18, 0x03, 0x1a
> #endif
> };
>
> @@ -246,8 +251,13 @@ static void mctl_phy_configure_odt(const struct
> dram_para *para)
> {
> uint32_t val_lo, val_hi;
>
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x390, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x3d0, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x410, BIT(5), BIT(4));
> + clrsetbits_le32(SUNXI_DRAM_PHY0_BASE + 0x450, BIT(5), BIT(4));
> +
> val_lo = para->dx_dri;
> - val_hi = para->dx_dri;
> + val_hi = (para->type == SUNXI_DRAM_TYPE_LPDDR4) ? 0x04040404 :
> para->dx_dri;
> writel_relaxed(MASK_BYTE(val_lo, 0), SUNXI_DRAM_PHY0_BASE + 0x388);
> writel_relaxed(MASK_BYTE(val_hi, 0),
Re: [PATCH 2/2] bootcount: Add driver model I2C driver
Hi Philip, On Wed, 18 Oct 2023 at 05:00, Philip Oberfichtner wrote: > > Hi Heiko, > > On Wed, Oct 18, 2023 at 06:31:57AM +0200, Heiko Schocher wrote: > > [...] > > > > May Philip can use uclass_get_device_by_phandle and try a list of > > possible UCLASS candidates, like UCLASS_RTC, UCLASS_I2C_EEPROM, > > UCLASS_POWER,... and if found, check if parent is UCLASS_I2C... > > > > may not so expensive ... > > Looks more cheap and elegant than the other variants indeed. But I'm not > sure if we can maintain generality using this approach. > > What if the specific I2C driver is not included in the build, because > the devices "actual" functionality is not required? Then the device will not be bound and the function will fail. There needs to be a node and a bound device. > Or what if a driver > for the specific device does not even exist in U-Boot? > > Wouldn't the device fail to probe then? The DT should specify the compatible string so the correct i2c driver is used. If there isn't one,I believe it uses I2C_GENERIC but you'll need to check it. > > Please correct me if I'm wrong, I'd give it a shot in that case. > Otherwise I'll try it with the aforementioned > device_find_global_by_ofnode() followed by device_bind_driver() using > UCLASS_I2C_GENERIC (I hope that works). That is the same approach, I think. But anyway I think Heiko knows more about this than me. Regards, Simon
Re: [PATCH v5 4/8] rockchip: block: blk-uclass: add bounce buffer flag to blk_desc
On Wed, 18 Oct 2023 at 08:01, Johan Jonker wrote: > > Currently bounce buffer support is enabled for all block devices > when available. Add a flag to blk_desc to enable only on demand. > > Signed-off-by: Johan Jonker > --- > > Changed V5: > New patch > --- > drivers/block/blk-uclass.c | 4 ++-- > drivers/scsi/scsi.c| 4 > include/blk.h | 1 + > 3 files changed, 7 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v5 2/8] rockchip: dm: prepare rkmtd UCLASS
On Wed, 18 Oct 2023 at 08:00, Johan Jonker wrote: > > Prepare a rkmtd UCLASS in use for writing Rockchip boot blocks > in combination with existing userspace tools and rockusb command. > > Signed-off-by: Johan Jonker > Reviewed-by: Kever Yang > --- > disk/part.c| 4 > drivers/block/blk-uclass.c | 1 + > include/dm/uclass-id.h | 1 + > 3 files changed, 6 insertions(+) Reviewed-by: Simon Glass
[PATCH 3/3] power: regulator: add AXP313 support
The X-Powers AXP313a is a small PMIC with just three buck converters and
three LDOs, one of which is actually fixed (so not modelled here).
Add the compatible string and the respective regulator ranges to allow
drivers to adjust voltages.
Signed-off-by: Andre Przywara
---
drivers/power/pmic/axp.c| 1 +
drivers/power/regulator/axp_regulator.c | 17 +
include/axp_pmic.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/power/pmic/axp.c b/drivers/power/pmic/axp.c
index 025dac24f28..0e1e45fba74 100644
--- a/drivers/power/pmic/axp.c
+++ b/drivers/power/pmic/axp.c
@@ -87,6 +87,7 @@ static const struct udevice_id axp_pmic_ids[] = {
{ .compatible = "x-powers,axp209", .data = AXP209_ID },
{ .compatible = "x-powers,axp221", .data = AXP221_ID },
{ .compatible = "x-powers,axp223", .data = AXP223_ID },
+ { .compatible = "x-powers,axp313a", .data = AXP313_ID },
{ .compatible = "x-powers,axp803", .data = AXP803_ID },
{ .compatible = "x-powers,axp806", .data = AXP806_ID },
{ .compatible = "x-powers,axp809", .data = AXP809_ID },
diff --git a/drivers/power/regulator/axp_regulator.c
b/drivers/power/regulator/axp_regulator.c
index 02f320eac1e..d27e09538e0 100644
--- a/drivers/power/regulator/axp_regulator.c
+++ b/drivers/power/regulator/axp_regulator.c
@@ -173,6 +173,22 @@ static const struct axp_regulator_plat axp22x_regulators[]
= {
{ }
};
+/*
+ * The "dcdc1" regulator has another range, beyond 1.54V up to 3.4V, in
+ * steps of 100mV. We cannot model this easily, but also don't need that,
+ * since it's typically only used for ~1.1V anyway, so just ignore it.
+ * Also the DCDC3 regulator is described wrongly in the (available) manual,
+ * experiments show that the split point is at 1200mV, as for DCDC1/2.
+ */
+static const struct axp_regulator_plat axp313_regulators[] = {
+ { "dcdc1", 0x10, BIT(0), 0x13, 0x7f, 500, 1540, 10, 70 },
+ { "dcdc2", 0x10, BIT(1), 0x14, 0x7f, 500, 1540, 10, 70 },
+ { "dcdc3", 0x10, BIT(2), 0x15, 0x7f, 500, 1840, 10, 70 },
+ { "aldo1", 0x10, BIT(3), 0x16, 0x1f, 500, 3500, 100, NA },
+ { "dldo1", 0x10, BIT(4), 0x17, 0x1f, 500, 3500, 100, NA },
+ { }
+};
+
static const struct axp_regulator_plat axp803_regulators[] = {
{ "dcdc1", 0x10, BIT(0), 0x20, 0x1f, 1600, 3400, 100, NA },
{ "dcdc2", 0x10, BIT(1), 0x21, 0x7f, 500, 1300, 10, 70 },
@@ -274,6 +290,7 @@ static const struct axp_regulator_plat *const
axp_regulators[] = {
[AXP209_ID] = axp20x_regulators,
[AXP221_ID] = axp22x_regulators,
[AXP223_ID] = axp22x_regulators,
+ [AXP313_ID] = axp313_regulators,
[AXP803_ID] = axp803_regulators,
[AXP806_ID] = axp806_regulators,
[AXP809_ID] = axp809_regulators,
diff --git a/include/axp_pmic.h b/include/axp_pmic.h
index 4ac64865831..aabafc8501b 100644
--- a/include/axp_pmic.h
+++ b/include/axp_pmic.h
@@ -32,6 +32,7 @@ enum {
AXP209_ID,
AXP221_ID,
AXP223_ID,
+ AXP313_ID,
AXP803_ID,
AXP806_ID,
AXP809_ID,
--
2.25.1
[PATCH 2/3] power: pmic: sunxi: add AXP313 SPL driver
On boards using the AXP313 PMIC, the DRAM rail is often not setup
correctly at reset time, so we have to program the PMIC very early in
the SPL, before running the DRAM initialisation.
Add a simple AXP313 PMIC driver that knows about DCDC2(CPU) and
DCDC3(DRAM), so that we can bump up the voltage before the DRAM init.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/pmic_bus.c | 3 +
board/sunxi/board.c| 3 +-
drivers/power/Kconfig | 17 -
drivers/power/Makefile | 1 +
drivers/power/axp313.c | 134 +
5 files changed, 155 insertions(+), 3 deletions(-)
create mode 100644 drivers/power/axp313.c
diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index c0908406370..8e7625fe057 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -22,6 +22,7 @@
#define AXP209_I2C_ADDR0x34
#define AXP305_I2C_ADDR0x36
+#define AXP313_I2C_ADDR0x36
#define AXP221_CHIP_ADDR 0x68
@@ -34,6 +35,8 @@ static int pmic_i2c_address(void)
return AXP152_I2C_ADDR;
if (IS_ENABLED(CONFIG_AXP305_POWER))
return AXP305_I2C_ADDR;
+ if (IS_ENABLED(CONFIG_AXP313_POWER))
+ return AXP313_I2C_ADDR;
/* Other AXP2xx and AXP8xx variants */
return AXP209_I2C_ADDR;
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 65d79a02c25..39b0ad73a9c 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -584,7 +584,8 @@ void sunxi_board_init(void)
#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \
- defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
+ defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER || \
+ defined CONFIG_AXP313_POWER
power_failed = axp_init();
if (IS_ENABLED(CONFIG_AXP_DISABLE_BOOT_ON_POWERON) && !power_failed) {
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 83cb31c937a..a9117d215eb 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -101,6 +101,15 @@ config AXP305_POWER
Select this to enable support for the axp305 pmic found on most
H616 boards.
+config AXP313_POWER
+ bool "axp311 pmic support"
+ depends on MACH_SUN50I_H616
+ select AXP_PMIC_BUS
+ select CMD_POWEROFF
+ ---help---
+ Select this to enable support for the AXP313 PMIC found on some
+ H616 boards.
+
config AXP809_POWER
bool "axp809 pmic support"
depends on MACH_SUN9I
@@ -143,9 +152,10 @@ config AXP_DCDC1_VOLT
config AXP_DCDC2_VOLT
int "axp pmic dcdc2 voltage"
- depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || AXP809_POWER
|| AXP818_POWER
+ depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || AXP809_POWER
|| AXP818_POWER || AXP313_POWER
default 900 if AXP818_POWER
default 1400 if AXP152_POWER || AXP209_POWER
+ default 1000 if AXP313_POWER
default 1200 if MACH_SUN6I
default 1100 if MACH_SUN8I
default 0 if MACH_SUN9I
@@ -158,13 +168,15 @@ config AXP_DCDC2_VOLT
On A80 boards dcdc2 powers the GPU and can be left off.
On A83T boards dcdc2 is used for VDD-CPUA(cluster 0) and should be 0.9V.
On R40 boards dcdc2 is VDD-CPU and should be 1.1V
+ On boards using the AXP313 it's often VDD-CPU.
config AXP_DCDC3_VOLT
int "axp pmic dcdc3 voltage"
- depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || AXP809_POWER
|| AXP818_POWER
+ depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || AXP809_POWER
|| AXP818_POWER || AXP313_POWER
default 900 if AXP809_POWER || AXP818_POWER
default 1500 if AXP152_POWER
default 1250 if AXP209_POWER
+ default 1100 if AXP313_POWER
default 1100 if MACH_SUN8I_R40
default 1200 if MACH_SUN6I || MACH_SUN8I
---help---
@@ -177,6 +189,7 @@ config AXP_DCDC3_VOLT
On A80 boards dcdc3 is used for VDD-CPUA(cluster 0) and should be 0.9V.
On A83T boards dcdc3 is used for VDD-CPUB(cluster 1) and should be 0.9V.
On R40 boards dcdc3 is VDD-SYS and VDD-GPU and should be 1.1V.
+ On boards using the AXP313 it's often VDD-DRAM and should be 1.1V for
LPDDR4.
config AXP_DCDC4_VOLT
int "axp pmic dcdc4 voltage"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ba64b2c5938..c7ee4595fc8 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_AXP152_POWER)+= axp152.o
obj-$(CONFIG_AXP209_POWER) += axp209.o
obj-$(CONFIG_AXP221_POWER) += axp221.o
obj-$(CONFIG_AXP305_POWER) += axp305.o
+obj-$(CONFIG_AXP313_POWER) += axp313.o
obj-$(CONFIG_AXP809_POWER) += axp809.o
obj-$(CONFIG_AXP818_POWER) +=
[PATCH 1/3] sunxi: board: simplify early PMIC setup conditions
So far we have a convoluted #ifdef mesh that guards the early AXP PMIC
setup in board.c. That combination of &&, || and negations is very hard
to read, maintain and especially to extend.
Fortunately we have those same conditions already modelled in the
Kconfig file, so they are actually redundant. On top of that the real
reason we have those preprocessor guards in the first place is about the
symbols that are *conditionally* defined: without #ifdefs the build
would break because of them being undefined for many boards.
To simplify this, just change the guards to actually look at the symbols
needed, so CONFIG_AXP_xxx_VOLT instead of CONFIG_AXPyyy_POWER.
This drastically improves the readability of this code, and makes adding
PMIC support a pure Kconfig matter.
Signed-off-by: Andre Przywara
---
board/sunxi/board.c | 32 ++--
drivers/power/Kconfig | 2 +-
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index ebaa9431984..65d79a02c25 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -597,50 +597,46 @@ void sunxi_board_init(void)
}
}
-#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
- defined CONFIG_AXP818_POWER
+#ifdef CONFIG_AXP_DCDC1_VOLT
power_failed |= axp_set_dcdc1(CONFIG_AXP_DCDC1_VOLT);
+ power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
#endif
-#if !defined(CONFIG_AXP305_POWER)
+#ifdef CONFIG_AXP_DCDC2_VOLT
power_failed |= axp_set_dcdc2(CONFIG_AXP_DCDC2_VOLT);
power_failed |= axp_set_dcdc3(CONFIG_AXP_DCDC3_VOLT);
#endif
-#if !defined(CONFIG_AXP209_POWER) && !defined(CONFIG_AXP818_POWER)
+#ifdef CONFIG_AXP_DCDC4_VOLT
power_failed |= axp_set_dcdc4(CONFIG_AXP_DCDC4_VOLT);
#endif
-#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
- defined CONFIG_AXP818_POWER
- power_failed |= axp_set_dcdc5(CONFIG_AXP_DCDC5_VOLT);
-#endif
-#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || \
- defined CONFIG_AXP818_POWER
+#ifdef CONFIG_AXP_ALDO1_VOLT
power_failed |= axp_set_aldo1(CONFIG_AXP_ALDO1_VOLT);
#endif
-#if !defined(CONFIG_AXP305_POWER)
+#ifdef CONFIG_AXP_ALDO2_VOLT
power_failed |= axp_set_aldo2(CONFIG_AXP_ALDO2_VOLT);
#endif
-#if !defined(CONFIG_AXP152_POWER) && !defined(CONFIG_AXP305_POWER)
+#ifdef CONFIG_AXP_ALDO3_VOLT
power_failed |= axp_set_aldo3(CONFIG_AXP_ALDO3_VOLT);
#endif
-#ifdef CONFIG_AXP209_POWER
+#ifdef CONFIG_AXP_ALDO4_VOLT
power_failed |= axp_set_aldo4(CONFIG_AXP_ALDO4_VOLT);
#endif
-#if defined(CONFIG_AXP221_POWER) || defined(CONFIG_AXP809_POWER) || \
- defined(CONFIG_AXP818_POWER)
+#ifdef CONFIG_AXP_DLDO1_VOLT
power_failed |= axp_set_dldo(1, CONFIG_AXP_DLDO1_VOLT);
power_failed |= axp_set_dldo(2, CONFIG_AXP_DLDO2_VOLT);
-#if !defined CONFIG_AXP809_POWER
+#endif
+#ifdef CONFIG_AXP_DLDO3_VOLT
power_failed |= axp_set_dldo(3, CONFIG_AXP_DLDO3_VOLT);
power_failed |= axp_set_dldo(4, CONFIG_AXP_DLDO4_VOLT);
#endif
+#ifdef CONFIG_AXP_ELDO1_VOLT
power_failed |= axp_set_eldo(1, CONFIG_AXP_ELDO1_VOLT);
power_failed |= axp_set_eldo(2, CONFIG_AXP_ELDO2_VOLT);
power_failed |= axp_set_eldo(3, CONFIG_AXP_ELDO3_VOLT);
#endif
-#ifdef CONFIG_AXP818_POWER
+#ifdef CONFIG_AXP_FLDO1_VOLT
power_failed |= axp_set_fldo(1, CONFIG_AXP_FLDO1_VOLT);
power_failed |= axp_set_fldo(2, CONFIG_AXP_FLDO2_VOLT);
power_failed |= axp_set_fldo(3, CONFIG_AXP_FLDO3_VOLT);
@@ -649,7 +645,7 @@ void sunxi_board_init(void)
#if defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
#endif
-#endif
+#endif /* CONFIG_AXPxxx_POWER */
printf("DRAM:");
gd->ram_size = sunxi_dram_init();
printf(" %d MiB\n", (int)(gd->ram_size >> 20));
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 7f3b990d231..83cb31c937a 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -180,7 +180,7 @@ config AXP_DCDC3_VOLT
config AXP_DCDC4_VOLT
int "axp pmic dcdc4 voltage"
- depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || AXP818_POWER
|| AXP305_POWER
+ depends on AXP152_POWER || AXP221_POWER || AXP809_POWER || AXP305_POWER
default 1250 if AXP152_POWER
default 1200 if MACH_SUN6I
default 0 if MACH_SUN8I
--
2.25.1
[PATCH 0/3] power: add AXP313 PMIC support
The X-Powers AXP313 is a small PMIC that is controlled via I2C and provides just three buck converters and three LDOs, plus a power button. It is used on many newer boards using the Allwinner H616 or H618 SoCs. Mostly all rails need to be always on, since each of them supplies an essential part of the system, consequentially the reset default is to have all of them enabled. However the voltages need to be adjusted, especially the DRAM rail is typically at 900mV, for instance, which is too low. This series adds support for the proper DM AXP PMIC driver (patch 3/3), but also adds a small driver to be used in (our non-DM) SPL, to adjust the DRAM voltage before the DRAM initialisation starts (patch 2/3). This also uses the opportunity to clean up an #ifdef nightmare in our board.c (patch 1/3), which was actually duplicating some dependencies already described in Kconfig. This is one part of the enablement of many newer boards with the H616/H618 SoC: without the DRAM voltage increased to 1.1V they won't boot. Cheers, Andre Andre Przywara (3): sunxi: board: simplify early PMIC setup conditions power: pmic: sunxi: add AXP313 SPL driver power: regulator: add AXP313 support arch/arm/mach-sunxi/pmic_bus.c | 3 + board/sunxi/board.c | 35 +++ drivers/power/Kconfig | 19 +++- drivers/power/Makefile | 1 + drivers/power/axp313.c | 134 drivers/power/pmic/axp.c| 1 + drivers/power/regulator/axp_regulator.c | 17 +++ include/axp_pmic.h | 1 + 8 files changed, 189 insertions(+), 22 deletions(-) create mode 100644 drivers/power/axp313.c -- 2.25.1
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
On Wed, Oct 18, 2023 at 09:23:42AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 18 Oct 2023 at 07:37, Tom Rini wrote: > > > > On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote: > > > > > Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is > > > available, add it as an explicit dependency. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > (no changes since v2) > > > > > > Changes in v2: > > > - Add new patch to update EFI_LOADER to depend on DM_ETH > > > > > > lib/efi_loader/Kconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > index 13cad6342c36..fca4b3eef270 100644 > > > --- a/lib/efi_loader/Kconfig > > > +++ b/lib/efi_loader/Kconfig > > > @@ -11,6 +11,7 @@ config EFI_LOADER > > > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > > > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > > > depends on BLK > > > + depends on DM_ETH > > > depends on !EFI_APP > > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 > > > select CHARSET > > > > I don't think this is needed. After reconfiguring qemu_arm64 to be able > > to disable networking entirely, we still are able to build with > > EFI_LOADER enabled, and no warning / link errors. > > Fair enough. > > As of this patch the following errors are generated with -a ~CMDLINE : > > +lib/efi_loader/efi_device_path.c:985:(.text+0xca4): undefined > reference to `eth_get_dev' > +/bin/ld: lib/efi_loader/efi_device_path.c:987:(.text+0xca9): > undefined reference to `eth_get_dev' > +/bin/ld: lib/efi_loader/efi_device_path.c:993:(.text+0xcc9): > undefined reference to `eth_get_dev' > +/bin/ld: lib/efi_loader/efi_device_path.o: in function `efi_dp_from_name': > +lib/efi_loader/efi_device_path.c:1095:(.text+0xe00): undefined > reference to `efi_get_image_parameters' > > which is why I added this patch. A later patch disables networking > entirely with ~CMDLINE so that is why this problem goes away. > > This series was basically built up by disabling CMDLINE and then > fixing the errors one by one. I didn't go back and check whether (at > the end) all the patches were needed. Yes, part of the issue with the series is that you didn't go and rework things after getting CMDLINE to link for sandbox, to see what else is or is not still needed. > I could do that and send a v4, if your more general concerns can be sorted > out. Don't worry about a v4 currently please, I'm working through the issues now picking out parts of v3 and re-working others. -- Tom signature.asc Description: PGP signature
Re: [PATCH 30/32] fdt: Allow the devicetree to come from a bloblist
Hi Ilias, On Mon, 25 Sept 2023 at 04:19, Ilias Apalodimas wrote: > > Hi Simon, > > [...] > > > > > >> +config OF_BLOBLIST > > > > >> + bool "DTB is provided by a bloblist" > > > > >> + help > > > > >> + Select this to read the devicetree from the > > > > >> bloblist. This allows > > > > >> + using a bloblist to transfer the devicetree between > > > > >> U-Boot phases. > > > > >> + The devicetree is stored in the bloblist by an early > > > > >> phase so that > > > > >> + U-Boot can read it. > > > > >> + > > > > > > > > > > I dont think this is a good idea. We used to have 4-5 > > > > > different options > > > > > here, which we tried to clean up and ended up with two very > > > > > discrete > > > > > options. Why do we have to reintroduce a new one? Doesn't > > > > > that bloblist > > > > > have a header of some sort? The bloblist literally comes > > > > > from a previous > > > > > stage bootloader which is what OF_BOARD is here for. So why > > > > > can't we just > > > > > read the header and figure out if the magic of the bloblist > > > > > matches? > > > > > > > > No, OF_BOARD is a hack to allow boards to do what they like > > > > with the FDT. > > > > > > > > This patch is a standard mechanism to pass the DT from one > > > > firmware > > > > phase to the next. We have spent quite a bit of time creating > > > > a spec > > > > for it, and we should use it. > > > > >>> > > > > >>> Where exactly am I objecting using the spec? Can you please > > > > >>> re-read my email? > > > > >>> I am actually pointing out we should use the spec *properly*. > > > > >>> So > > > > >>> instead of having a Kconfig option for the DT, which is pretty > > > > >>> pointless, we should parse the bloblist. If the header > > > > >>> defined by > > > > >>> the *spec* is found, we should just search for the DT in there. > > > > >>> What you are doing here, is take the spec, pick a very specific > > > > >>> item > > > > >>> that the list contains, and create a Kconfig option out of it. > > > > >>> Which > > > > >>> basically ignores the discoverable options of the bloblist. For > > > > >>> example, that bloblist can also contain an entry to a TPM > > > > >>> eventlog. > > > > >>> Should we start creating Kconfig options for all the firmware > > > > >>> handoff > > > > >>> entries that are defined on that spec? > > > > >> > > > > >> OK so that is a different thing. What should it do if it expects > > > > >> to find a bloblist but cannot? I want it to throw an error, > > > > >> because I am trying to make the boot deterministic. What do you > > > > >> think? > > > > > > > > > > That's fine by me. You can even put that under IS_ENABLED for the > > > > > bloblist inside the existing OF_BOARD check. So I was thinking > > > > > - If no bloblist is required in Kconfig options we do the hacks > > > > > we used to > > > > > - if bloblist is selected and the config option is OF_BOARD, > > > > > throw an > > > > > error and mention that the previous stage loader should hand over > > > > > a DT > > > > > > > > > > Is that what you had in mind? > > > > > > > > Yes, that sounds good to me. > > > > > > > > But I still think we need an OF_BLOBLIST option to control whether > > > > the > > > > devicetree comes from there. > > > > Otherwise we will end up with people > > > > using OF_BOARD to work around it. We also have the SPL case which > > > > does > > > > not pass the DT in a bloblist...in fact SPL typically doesn't even > > > > have the full DT. > > > > >>> > > > > >>> Wouldn't IS_ENABLED(BLOBLIST) || IS_ENABLED(SPL_BLOBLIST) be enough? > > > > >>> Inside the OF_BOARD portion of the function, search for a bloblist > > > > >>> if > > > > >>> the option is enabled. If you can't find a bloblist and the DT > > > > >>> within > > > > >>> that bloblist, then error out > > > > >> > > > > >> Just my 2c here. > > > > >> I think all options should be possible to disable. It means I can > > > > >> imagine to > > > > >> disable u-boot not to take care about DT provided from previous > > > > >> stage. The same > > > > >> is for TPM event log. IMHO every stage should have an option to > > > > >> simply ignore > > > > >> data pass from previous stage. I don't really mind how it is done > > > > >> but there > > > > >> should be an option to by purpose say to ignore the part of pass > > > > >> data. > > > > > > > > > > That would be done by disabling BLOBLIST. I don't think having a > > > > > Kconfig to say > > > > >
Re: [PATCH v3 02/32] bootstd: Correct dependencies on CMDLINE
Hi Tom, On Wed, 18 Oct 2023 at 08:42, Tom Rini wrote: > > On Mon, Oct 16, 2023 at 04:27:53PM -0600, Simon Glass wrote: > > With recent changes over the last few years in boot/Kconfig it is > > no-longer possible to disable CMDLINE. It results in various link > > errors because some options which require CMDLINE are enabled > > regardless of whether it is available. > > > > Add the necessary conditions to fix this. > > > > Note that it would be better to have all commands depend on CMDLINE, > > but that is extremely difficult at present, since some functions use > > CMD_xxx to enable feature xxx. For example networking and environment > > have a number of problems to tease apart. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Reword commit message slightly > > > > boot/Kconfig | 19 --- > > lib/efi_loader/Kconfig | 1 + > > 2 files changed, 13 insertions(+), 7 deletions(-) > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > index a01e6cb8aafe..f74ac7e9cc72 100644 > > --- a/boot/Kconfig > > +++ b/boot/Kconfig > > @@ -342,6 +342,7 @@ endif # FIT > > > > config PXE_UTILS > > bool > > + depends on CMDLINE > > select MENU > > help > > Utilities for parsing PXE file formats. > > So, this part here is because of CONFIG_SYS_PBSIZE, which I think we can > / should solve another way. Perhaps it would help if you just clarify your goal. My goal with this series is to allow CMDLINE to be disabled without build errors, so we can start the work booting via bootstd (with CMDLINE disabled). This isn't a straight-line activity. It involves changes that will become redundant later, simply because I haven't written the 100s of patches needed to figure it all out. Even if I did it would be unreviewable and require lots of rework based on feedback. Regards, Simon
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
Hi Tom, On Wed, 18 Oct 2023 at 07:37, Tom Rini wrote: > > On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote: > > > Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is > > available, add it as an explicit dependency. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v2) > > > > Changes in v2: > > - Add new patch to update EFI_LOADER to depend on DM_ETH > > > > lib/efi_loader/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index 13cad6342c36..fca4b3eef270 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -11,6 +11,7 @@ config EFI_LOADER > > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > > depends on BLK > > + depends on DM_ETH > > depends on !EFI_APP > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 > > select CHARSET > > I don't think this is needed. After reconfiguring qemu_arm64 to be able > to disable networking entirely, we still are able to build with > EFI_LOADER enabled, and no warning / link errors. Fair enough. As of this patch the following errors are generated with -a ~CMDLINE : +lib/efi_loader/efi_device_path.c:985:(.text+0xca4): undefined reference to `eth_get_dev' +/bin/ld: lib/efi_loader/efi_device_path.c:987:(.text+0xca9): undefined reference to `eth_get_dev' +/bin/ld: lib/efi_loader/efi_device_path.c:993:(.text+0xcc9): undefined reference to `eth_get_dev' +/bin/ld: lib/efi_loader/efi_device_path.o: in function `efi_dp_from_name': +lib/efi_loader/efi_device_path.c:1095:(.text+0xe00): undefined reference to `efi_get_image_parameters' which is why I added this patch. A later patch disables networking entirely with ~CMDLINE so that is why this problem goes away. This series was basically built up by disabling CMDLINE and then fixing the errors one by one. I didn't go back and check whether (at the end) all the patches were needed. I could do that and send a v4, if your more general concerns can be sorted out. Regards, Simon
Re: [PATCH v3 02/32] bootstd: Correct dependencies on CMDLINE
On Mon, Oct 16, 2023 at 04:27:53PM -0600, Simon Glass wrote: > With recent changes over the last few years in boot/Kconfig it is > no-longer possible to disable CMDLINE. It results in various link > errors because some options which require CMDLINE are enabled > regardless of whether it is available. > > Add the necessary conditions to fix this. > > Note that it would be better to have all commands depend on CMDLINE, > but that is extremely difficult at present, since some functions use > CMD_xxx to enable feature xxx. For example networking and environment > have a number of problems to tease apart. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Reword commit message slightly > > boot/Kconfig | 19 --- > lib/efi_loader/Kconfig | 1 + > 2 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/boot/Kconfig b/boot/Kconfig > index a01e6cb8aafe..f74ac7e9cc72 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -342,6 +342,7 @@ endif # FIT > > config PXE_UTILS > bool > + depends on CMDLINE > select MENU > help > Utilities for parsing PXE file formats. So, this part here is because of CONFIG_SYS_PBSIZE, which I think we can / should solve another way. -- Tom signature.asc Description: PGP signature
[PATCH v5 8/8] rockchip: configs: sandbox: enable rkmtd command
Enable rkmtd command for testing with sandbox_defconfig and sandbox64_defconfig. Signed-off-by: Johan Jonker Reviewed-by: Simon Glass --- Changed V3: New patch --- configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig index 1a033b22018b..1a01f51a0b75 100644 --- a/configs/sandbox64_defconfig +++ b/configs/sandbox64_defconfig @@ -58,6 +58,7 @@ CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_SPI=y CONFIG_CMD_TEMPERATURE=y CONFIG_CMD_USB=y +CONFIG_CMD_RKMTD=y CONFIG_CMD_WDT=y CONFIG_CMD_WRITE=y CONFIG_CMD_CAT=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 01830c7bd255..cc54e6dec5af 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -84,6 +84,7 @@ CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_SPI=y CONFIG_CMD_TEMPERATURE=y CONFIG_CMD_USB=y +CONFIG_CMD_RKMTD=y CONFIG_CMD_WDT=y CONFIG_CMD_WRITE=y CONFIG_CMD_AXI=y -- 2.39.2
[PATCH v5 7/8] rockchip: doc: add rkmtd.rst
Add documention for Rockchip rkmtd virtual block device. Signed-off-by: Johan Jonker Reviewed-by: Kever Yang Reviewed-by: Simon Glass --- Changed V3: New patch --- doc/board/rockchip/index.rst | 1 + doc/board/rockchip/rkmtd.rst | 105 +++ 2 files changed, 106 insertions(+) create mode 100644 doc/board/rockchip/rkmtd.rst diff --git a/doc/board/rockchip/index.rst b/doc/board/rockchip/index.rst index 0c377e9bbba0..9a87a035e95e 100644 --- a/doc/board/rockchip/index.rst +++ b/doc/board/rockchip/index.rst @@ -8,3 +8,4 @@ Rockchip :maxdepth: 2 rockchip + rkmtd diff --git a/doc/board/rockchip/rkmtd.rst b/doc/board/rockchip/rkmtd.rst new file mode 100644 index ..1481380ba6c5 --- /dev/null +++ b/doc/board/rockchip/rkmtd.rst @@ -0,0 +1,105 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2023 Johan Jonker + +RKMTD += + +Info + + +The command rkmtd creates a virtual block device to transfer +Rockchip boot block data to and from NAND with block orientated +tools like "ums" and "rockusb". + +It uses the Rockchip MTD driver to scan for boot blocks and copies +data from the first block in a GPT formatted virtual disk. +Data must be written in U-boot "idbloader.img" format and start at +partition "loader1" offset 64. The data header is parsed +for length and offset. When the last sector is received +it erases up to 5 erase blocks on NAND and writes boot blocks +in a pattern depending on the NAND ID. Data is then verified. +When a block turns out bad the block header is discarded. + +Limitations +--- + +- Support with CONFIG_ROCKCHIP_NAND MTD driver only. +- Support for Rockchip boot block header type 1 only. +- Pattern for listed NAND IDs only. (Logic still not disclosed by Rockchip) +- The MTD framework driver data and NAND ID must be extracted at a lower level. + +Available rkmtd commands + + +.. code-block:: bash + +rkmtd bind - bind RKMTD device +rkmtd unbind - unbind RKMTD device +rkmtd info []- show all available RKMTD devices +rkmtd dev [] - show or set current RKMTD device + +U-boot settings +--- + +Config to enable Rockchip MTD support: + +.. code-block:: bash + +CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT=y +CONFIG_SYS_NAND_USE_FLASH_BBT=y +CONFIG_ROCKCHIP_NAND=y + +Option to keep existing NAND data unchanged: + +.. code-block:: bash + +CONFIG_ROCKCHIP_NAND_SKIP_BBTSCAN=y + +Commands to enable: + +.. code-block:: bash + +CONFIG_CMD_USB=y +CONFIG_CMD_RKMTD=y +CONFIG_CMD_ROCKUSB=y +CONFIG_CMD_USB_MASS_STORAGE=y + +Linux Host (PC) tool commands combinations that work + + +.. table:: + :widths: 20 44 + + + U-boot Linux + + rkmtd bind 0 + rockusb 0 rkmtd 0 +upgrade_tool pl + +upgrade_tool rl 64 512 idbloader_backup.img + +upgrade_tool wl 64 idbloader.img + +upgrade_tool rd + +rkdeveloptool ppt + +rkdeveloptool rl 64 512 idbloader_backup.img + +rkdeveloptool wlx loader1 idbloader.img + +rkdeveloptool wl 64 idbloader.img + +rkdeveloptool rd + +rkflashtool r 64 512 > idbloader_backup.img + +rkflashtool w 64 512 < idbloader.img + ums 0 rkmtd 0 +dd if=/dev/sda1 of=idbloader_backup.img + +dd if=idbloader.img of=/dev/sda1 + -- 2.39.2
[PATCH v5 6/8] rockchip: test: dm: add rkmtd test
Add Rockchip rkmtd test:
Create/attach/detach RKMTD device.
Send/read data with Rockchip boot block header.
Test that reusing the same label should work.
Basic test of 'rkmtd' commands.
Signed-off-by: Johan Jonker
Reviewed-by: Kever Yang
Reviewed-by: Simon Glass
---
Changed V4:
sort includes
rename define
use '\0'
use UT_TESTF_CONSOLE_REC flag
check RC4 result
Changed V3:
New patch
---
test/dm/Makefile | 1 +
test/dm/rkmtd.c | 200 +++
2 files changed, 201 insertions(+)
create mode 100644 test/dm/rkmtd.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7ed00733c1a6..a5e0a2744375 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_REMOTEPROC) += remoteproc.o
obj-$(CONFIG_DM_RESET) += reset.o
obj-$(CONFIG_SYSRESET) += sysreset.o
obj-$(CONFIG_DM_REGULATOR) += regulator.o
+obj-$(CONFIG_CMD_RKMTD) += rkmtd.o
obj-$(CONFIG_DM_RNG) += rng.o
obj-$(CONFIG_DM_RTC) += rtc.o
obj-$(CONFIG_SCMI_FIRMWARE) += scmi.o
diff --git a/test/dm/rkmtd.c b/test/dm/rkmtd.c
new file mode 100644
index ..3c3e8efa92f2
--- /dev/null
+++ b/test/dm/rkmtd.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Test derived from:
+ * /test/dm/host.c
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ *
+ * Copyright (C) 2023 Johan Jonker
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RW_BUF_SIZE12 * 512
+
+/* Basic test of the RKMTD interface */
+static int dm_test_rkmtd(struct unit_test_state *uts)
+{
+ struct udevice *dev, *part, *chk, *blk;
+ char write[RW_BUF_SIZE], read[RW_BUF_SIZE];
+ static const char label[] = "test";
+ struct rkmtd_dev *plat;
+ struct blk_desc *desc;
+ struct sector0 *sec0;
+ int i;
+
+ ut_asserteq(-ENODEV, uclass_first_device_err(UCLASS_RKMTD, ));
+ ut_asserteq(-ENODEV, uclass_first_device_err(UCLASS_PARTITION, ));
+
+ ut_assertok(rkmtd_create_device(label, ));
+
+ /* Check that the plat data has been allocated */
+ plat = dev_get_plat(dev);
+ ut_asserteq_str("test", plat->label);
+ ut_assert(label != plat->label);
+
+ /* Attach RKMTD driver */
+ ut_assertok(rkmtd_attach(dev));
+ ut_assertok(uclass_first_device_err(UCLASS_RKMTD, ));
+ ut_asserteq_ptr(chk, dev);
+
+ /* Get RKMTD block device */
+ ut_assertok(blk_get_from_parent(dev, ));
+ ut_assertok(device_probe(blk));
+
+ /* There should be a GPT partition table in this device */
+ ut_asserteq(0, uclass_first_device_err(UCLASS_PARTITION, ));
+
+ /* Write a boot block and verify that we get the same data back */
+ desc = dev_get_uclass_plat(blk);
+ ut_asserteq(true, desc->removable);
+ ut_asserteq(LBA, desc->lba);
+
+ memset(write, '\0', BLK_SIZE);
+
+ for (i = BLK_SIZE; i < sizeof(write); i++)
+ write[i] = i;
+
+ sec0 = (struct sector0 *)write;
+ sec0->magic = 0x0FF0AA55;
+ sec0->rc4_flag = 0;
+ sec0->boot_code1_offset = 4;
+ sec0->boot_code2_offset = 4;
+ sec0->flash_data_size = 4;
+ sec0->flash_boot_size = 8;
+
+ rkmtd_rc4(write, 512);
+ ut_asserteq(RK_TAG, sec0->magic);
+
+ ut_asserteq(12, blk_dwrite(desc, 64, 12, write));
+ ut_asserteq(12, blk_dread(desc, 64, 12, read));
+ ut_asserteq_mem(write, read, RW_BUF_SIZE);
+
+ ut_assertok(rkmtd_detach(dev));
+
+ ut_asserteq(-ENODEV, blk_get_from_parent(dev, ));
+ ut_assertok(device_unbind(dev));
+
+ return 0;
+}
+DM_TEST(dm_test_rkmtd, UT_TESTF_SCAN_FDT);
+
+/* Reusing the same label should work */
+static int dm_test_rkmtd_dup(struct unit_test_state *uts)
+{
+ static const char label[] = "test";
+ struct udevice *dev, *chk;
+
+ /* Create a RKMTD device with label "test" */
+ ut_asserteq(0, uclass_id_count(UCLASS_RKMTD));
+ ut_assertok(rkmtd_create_device(label, ));
+ ut_assertok(rkmtd_attach(dev));
+ ut_assertok(uclass_first_device_err(UCLASS_RKMTD, ));
+ ut_asserteq_ptr(chk, dev);
+ ut_asserteq(1, uclass_id_count(UCLASS_RKMTD));
+
+ /* Create another device with the same label (should remove old one) */
+ ut_assertok(rkmtd_create_device(label, ));
+ ut_assertok(rkmtd_attach(dev));
+ ut_assertok(uclass_first_device_err(UCLASS_RKMTD, ));
+ ut_asserteq_ptr(chk, dev);
+
+ /* Make sure there is still only one device */
+ ut_asserteq(1, uclass_id_count(UCLASS_RKMTD));
+
+ return 0;
+}
+DM_TEST(dm_test_rkmtd_dup, UT_TESTF_SCAN_FDT);
+
+/* Basic test of the 'rkmtd' command */
+static int dm_test_rkmtd_cmd(struct unit_test_state *uts)
+{
+ struct udevice *dev, *blk;
+ struct blk_desc *desc;
+
+ /* First check 'rkmtd info' with binding */
+ ut_assertok(run_command("rkmtd info", 0));
[PATCH v5 4/4] board: Add support for Conclusive KSTR-SAMA5D27
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.
Co-developed-by: Jakub Klama
Signed-off-by: Jakub Klama
Co-developed-by: Marcin Jabrzyk
Signed-off-by: Marcin Jabrzyk
Signed-off-by: Artur Rojek
---
v5: - move U-Boot specific props to at91-kstr-sama5d27-u-boot.dtsi file
- include the above file in MAINTAINERS
- assign an alias to i2c6
v4: - utilize EVT_SETTINGS_R in order to read MAC and serial number from
EEPROM
v3: - use CONFIG_ID_EEPROM to read serial number
- as side-effect of using CONFIG_ID_EEPROM, KSTR-SAMA5D27 now also
correctly uses EEPROM embedded MAC addresses (overlooked in v1-v2)
- use CONFIG_DISPLAY_BOARDINFO_LATE for printing the board model and
serial number, and provide the required checkboard() call
- drop CONFIG_BOARD_LATE_INIT, as not needed anymore
- defconfig cleanup
v2: - remove redundant license text from at91-kstr-sama5d27.dts
- when defining properties in .dts, reference nodes by labels
- drop nodes for usb0 and pmic, as these aren't used by drivers
- switch i2c to flexcom driver and make the necessary dts changes
- sort includes in at91-kstr-sama5d27.dts alphabetically
arch/arm/dts/Makefile | 3 +
arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi | 42 +++
arch/arm/dts/at91-kstr-sama5d27.dts | 127 ++
arch/arm/mach-at91/Kconfig| 12 +
board/conclusive/kstr-sama5d27/Kconfig| 15 ++
board/conclusive/kstr-sama5d27/MAINTAINERS| 9 +
board/conclusive/kstr-sama5d27/Makefile | 5 +
.../conclusive/kstr-sama5d27/kstr-sama5d27.c | 239 ++
configs/kstr_sama5d27_defconfig | 73 ++
include/configs/kstr-sama5d27.h | 15 ++
10 files changed, 540 insertions(+)
create mode 100644 arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi
create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts
create mode 100644 board/conclusive/kstr-sama5d27/Kconfig
create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS
create mode 100644 board/conclusive/kstr-sama5d27/Makefile
create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c
create mode 100644 configs/kstr_sama5d27_defconfig
create mode 100644 include/configs/kstr-sama5d27.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4569483d5fdf..f6f0d84ff77b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1232,6 +1232,9 @@ dtb-$(CONFIG_TARGET_SAMA5D27_SOM1_EK) += \
dtb-$(CONFIG_TARGET_SAMA5D27_WLSOM1_EK) += \
at91-sama5d27_wlsom1_ek.dtb
+dtb-$(CONFIG_TARGET_KSTR_SAMA5D27) += \
+ at91-kstr-sama5d27.dtb
+
dtb-$(CONFIG_TARGET_SAMA5D2_ICP) += \
at91-sama5d2_icp.dtb
diff --git a/arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi
b/arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi
new file mode 100644
index ..cec35ab621f7
--- /dev/null
+++ b/arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * at91-kstr-sama5d27-u-boot.dtsi - Device Tree Include file w/ U-Boot specific
+ * properties for Conclusive KSTR-SAMA5D27 board
+ *
+ * Copyright (C) 2023 Conclusive Engineering Sp. z o. o.
+ *
+ */
+
+/ {
+ chosen {
+ bootph-all;
+ };
+};
+
+ {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+};
+
+_uart1_default {
+ bootph-all;
+};
+
+_macb0_phy_irq {
+ bootph-all;
+};
+
+_macb0_rmii {
+ bootph-all;
+};
+
+_sdmmc0_cmd_dat_default {
+ bootph-all;
+};
+
+_sdmmc0_ck_cd_default {
+ bootph-all;
+};
diff --git a/arch/arm/dts/at91-kstr-sama5d27.dts
b/arch/arm/dts/at91-kstr-sama5d27.dts
new file mode 100644
index ..c226a214a551
--- /dev/null
+++ b/arch/arm/dts/at91-kstr-sama5d27.dts
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * at91-kstr-sama5d27.dts - Device Tree file for Conclusive KSTR-SAMA5D27 board
+ *
+ * Copyright (C) 2019-2023 Conclusive Engineering Sp. z o. o.
+ *
+ */
+/dts-v1/;
+
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+#include
+#include
+#include
+
+/ {
+ model = "Conclusive KSTR-SAMA5D27";
+ compatible = "conclusive,kstr-sama5d27", "atmel,sama5d2", "atmel,sama5";
+
+ chosen {
+ stdout-path =
+ };
+
+ aliases {
+ i2c2 =
+ };
+};
+
+_xtal {
+ clock-frequency = <1200>;
+};
+
+ {
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_sdmmc0_cmd_dat_default
_sdmmc0_ck_cd_default>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1_default>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_macb0_rmii _macb0_phy_irq>;
+ phy-mode = "rmii";
+ status = "okay";
+
+ ethernet-phy@0 {
+ reg = <0x0>;
+ reset-gpios = < 44 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+
[PATCH v5 5/8] rockchip: cmd: add rkmtd command
The command rkmtd creates a virtual block device to transfer
Rockchip boot block data to and from NAND with block orientated
tools like "ums" and "rockusb".
It uses the Rockchip MTD driver to scan for boot blocks and copies
data from the first block in a GPT formated virtual disk.
Data must be written in U-boot "idbloader.img" format and start at
partition "loader1" offset 64. The data header is parsed
for length and offset. When the last sector is received
it erases up to 5 erase blocks on NAND and writes bootblocks
in a pattern depending on the NAND ID. Data is then verified.
When a block turns out bad the block header is discarded.
Signed-off-by: Johan Jonker
Reviewed-by: Simon Glass
---
Changed V4:
Sort includes
Changed V3:
Split driver from command
Split header
Restyle
---
cmd/Kconfig | 8 ++
cmd/Makefile | 1 +
cmd/rkmtd.c | 204 +++
3 files changed, 213 insertions(+)
create mode 100644 cmd/rkmtd.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6470b138d2f8..1979c6c62aa7 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1561,6 +1561,14 @@ config CMD_USB_SDP
Enables the command "sdp" which is used to have U-Boot emulating the
Serial Download Protocol (SDP) via USB.
+config CMD_RKMTD
+ bool "rkmtd"
+ select RKMTD
+ help
+ Enable the command "rkmtd" to create a virtual block device to
transfer
+ Rockchip boot block data to and from NAND with block orientated tools
+ like "ums" and "rockusb".
+
config CMD_ROCKUSB
bool "rockusb"
depends on USB_FUNCTION_ROCKUSB
diff --git a/cmd/Makefile b/cmd/Makefile
index 9bebf321c397..11927a5904e6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_CMD_REISER) += reiser.o
obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
obj-$(CONFIG_CMD_RNG) += rng.o
obj-$(CONFIG_CMD_KASLRSEED) += kaslrseed.o
+obj-$(CONFIG_CMD_RKMTD) += rkmtd.o
obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
obj-$(CONFIG_CMD_RTC) += rtc.o
obj-$(CONFIG_SANDBOX) += host.o
diff --git a/cmd/rkmtd.c b/cmd/rkmtd.c
new file mode 100644
index ..5b80427cb949
--- /dev/null
+++ b/cmd/rkmtd.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *
+ * Driver interface derived from:
+ * /cmd/host.c
+ * Copyright (c) 2012, Google Inc.
+ *
+ * Copyright (C) 2023 Johan Jonker
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int do_rkmtd_bind(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+ struct udevice *dev;
+ const char *label;
+ int ret;
+
+ argc--;
+ argv++;
+
+ if (argc < 1)
+ return CMD_RET_USAGE;
+
+ if (argc > 1)
+ return CMD_RET_USAGE;
+
+ label = argv[0];
+ ret = rkmtd_create_attach_mtd(label, );
+ if (ret) {
+ printf("Cannot create device / bind mtd\n");
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
+
+static struct udevice *parse_rkmtd_label(const char *label)
+{
+ struct udevice *dev;
+
+ dev = rkmtd_find_by_label(label);
+ if (!dev) {
+ int devnum;
+ char *ep;
+
+ devnum = hextoul(label, );
+ if (*ep ||
+ uclass_find_device_by_seq(UCLASS_RKMTD, devnum, )) {
+ printf("No such device '%s'\n", label);
+ return NULL;
+ }
+ }
+
+ return dev;
+}
+
+static int do_rkmtd_unbind(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct udevice *dev;
+ const char *label;
+ int ret;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ label = argv[1];
+ dev = parse_rkmtd_label(label);
+ if (!dev)
+ return CMD_RET_FAILURE;
+
+ ret = rkmtd_detach(dev);
+ if (ret) {
+ printf("Cannot detach mtd\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = device_unbind(dev);
+ if (ret) {
+ printf("Cannot unbind device '%s'\n", dev->name);
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
+
+static void show_rkmtd_dev(struct udevice *dev)
+{
+ struct rkmtd_dev *plat = dev_get_plat(dev);
+ struct blk_desc *desc;
+ struct udevice *blk;
+ int ret;
+
+ printf("%3d ", dev_seq(dev));
+
+ ret = blk_get_from_parent(dev, );
+ if (ret)
+ return;
+
+ desc = dev_get_uclass_plat(blk);
+ printf("%12lu %-15s\n", (unsigned long)desc->lba, plat->label);
+}
+
+static int do_rkmtd_info(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+ struct udevice *dev;
+
+ if (argc < 1)
+ return CMD_RET_USAGE;
+
+ dev = NULL;
+ if (argc >= 2) {
+
[PATCH v5 3/4] arm: dts: at91: sama5: Add flexcom4 node
Set up flexcom4 for Microchip SAMA5D27 SoC and prepare it for usage in
I2C mode.
Signed-off-by: Artur Rojek
---
v3-v5: no change
v2: new patch
arch/arm/dts/sama5d2.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/sama5d2.dtsi b/arch/arm/dts/sama5d2.dtsi
index dd6468ed96aa..819564fdd5bb 100644
--- a/arch/arm/dts/sama5d2.dtsi
+++ b/arch/arm/dts/sama5d2.dtsi
@@ -781,6 +781,26 @@
status = "disabled";
};
+ flx4: flexcom@fc018000 {
+ compatible = "atmel,sama5d2-flexcom";
+ reg = <0xfc018000 0x200>;
+ clocks = <_clk>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xfc018000 0x800>;
+ status = "disabled";
+
+ i2c6: i2c@600 {
+ compatible = "atmel,sama5d2-i2c";
+ reg = <0x600 0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_clk>;
+ clock-names = "i2c6_clk";
+ status = "disabled";
+ };
+ };
+
aic: interrupt-controller@fc02 {
#interrupt-cells = <3>;
compatible = "atmel,sama5d2-aic";
--
2.42.0
[PATCH v5 2/4] event: add new EVT_SETTINGS_R event
Introduce EVT_SETTINGS_R, triggered post-relocation and before console
init.
This event gives an option to perform any platform-dependent setup,
which needs to take place before show_board_info(). Usage examples
include readout of EEPROM stored settings.
Signed-off-by: Artur Rojek
Reviewed-by: Simon Glass
---
v5: no change
v4: new patch
common/board_r.c | 1 +
common/event.c | 1 +
include/event.h | 9 +
3 files changed, 11 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 52786901be55..a7967849dc0c 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -693,6 +693,7 @@ static init_fnc_t init_sequence_r[] = {
#if defined(CONFIG_ID_EEPROM)
mac_read_from_eeprom,
#endif
+ INITCALL_EVENT(EVT_SETTINGS_R),
INIT_FUNC_WATCHDOG_RESET
#if defined(CONFIG_PCI_INIT_R) && !defined(CONFIG_SYS_EARLY_PCI_INIT)
/*
diff --git a/common/event.c b/common/event.c
index 3080d9ed754d..dc61b9672f32 100644
--- a/common/event.c
+++ b/common/event.c
@@ -37,6 +37,7 @@ const char *const type_name[] = {
/* init hooks */
"misc_init_f",
"fsp_init_r",
+ "settings_r",
"last_stage_init",
/* Fpga load hook */
diff --git a/include/event.h b/include/event.h
index c5646b713ad8..a8f046da3c32 100644
--- a/include/event.h
+++ b/include/event.h
@@ -104,6 +104,15 @@ enum event_t {
*/
EVT_FSP_INIT_F,
+ /**
+* @EVT_SETTINGS_R:
+* This event is triggered post-relocation and before console init.
+* This gives an option to perform any platform-dependent setup, which
+* needs to take place before show_board_info() (e.g. readout of EEPROM
+* stored settings).
+*/
+ EVT_SETTINGS_R,
+
/**
* @EVT_LAST_STAGE_INIT:
* This event is triggered just before jumping to the main loop.
--
2.42.0
[PATCH v5 1/4] common: add prototype & rename populate_serial_number()
Rename populate_serial_number() to a more descriptive
serial_read_from_eeprom() and provide the missing function prototype.
This is useful for boards that wish to read their serial number from
EEPROM at init.
Signed-off-by: Artur Rojek
Reviewed-by: Simon Glass
---
v5: no change
v4: - revert to the approach found in v2
- keep the new serial_read_from_eeprom() name
v3: - restore original function name and make it static
- provide a generic function for reading EEPROM serial number and
wrap it around the existing tlv logic
- move the env var check out of populate_serial_number() and into
the new serial_read_from_eeprom() in order to stay consistent with
the documentation
v2: - rename the function
- move function documentation from .c file to the prototype location
cmd/tlv_eeprom.c | 14 +-
include/init.h | 14 ++
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 79796394c5c8..57cfd355df1b 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -1088,19 +1088,7 @@ int mac_read_from_eeprom(void)
return 0;
}
-/**
- * populate_serial_number - read the serial number from EEPROM
- *
- * This function reads the serial number from the EEPROM and sets the
- * appropriate environment variable.
- *
- * The environment variable is only set if it has not been set
- * already. This ensures that any user-saved variables are never
- * overwritten.
- *
- * This function must be called after relocation.
- */
-int populate_serial_number(int devnum)
+int serial_read_from_eeprom(int devnum)
{
char serialstr[257];
int eeprom_index;
diff --git a/include/init.h b/include/init.h
index 4e7fe26c2004..d57a24fd00dd 100644
--- a/include/init.h
+++ b/include/init.h
@@ -271,6 +271,20 @@ void board_init_r(struct global_data *id, ulong dest_addr)
int cpu_init_r(void);
int mac_read_from_eeprom(void);
+
+/**
+ * serial_read_from_eeprom - read the serial number from EEPROM
+ *
+ * This function reads the serial number from the EEPROM and sets the
+ * appropriate environment variable.
+ *
+ * The environment variable is only set if it has not been set
+ * already. This ensures that any user-saved variables are never
+ * overwritten.
+ *
+ * This function must be called after relocation.
+ */
+int serial_read_from_eeprom(int devnum);
int set_cpu_clk_info(void);
int update_flash_size(int flash_size);
int arch_early_init_r(void);
--
2.42.0
[PATCH v5 0/4] Conclusive KSTR-SAMA5D27 support
Hi all, this is v5 of the Conclusive KSTR-SAMA5D27 support series. Patches [1/4], [2/4] and [3/4] remain unchanged. In patch [4/4], a new dtsi file has been added in order to keep U-Boot specific properties separate from the main dts. As such, MAINTAINERS has been modified to feature the new file. An alias to the i2c node holding the EEPROM has also been explicitly added, so that it always enumerates at bus 2. Artur Rojek (4): common: add prototype & rename populate_serial_number() event: add new EVT_SETTINGS_R event arm: dts: at91: sama5: Add flexcom4 node board: Add support for Conclusive KSTR-SAMA5D27 arch/arm/dts/Makefile | 3 + arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi | 42 +++ arch/arm/dts/at91-kstr-sama5d27.dts | 127 ++ arch/arm/dts/sama5d2.dtsi | 20 ++ arch/arm/mach-at91/Kconfig| 12 + board/conclusive/kstr-sama5d27/Kconfig| 15 ++ board/conclusive/kstr-sama5d27/MAINTAINERS| 9 + board/conclusive/kstr-sama5d27/Makefile | 5 + .../conclusive/kstr-sama5d27/kstr-sama5d27.c | 239 ++ cmd/tlv_eeprom.c | 14 +- common/board_r.c | 1 + common/event.c| 1 + configs/kstr_sama5d27_defconfig | 73 ++ include/configs/kstr-sama5d27.h | 15 ++ include/event.h | 9 + include/init.h| 14 + 16 files changed, 586 insertions(+), 13 deletions(-) create mode 100644 arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts create mode 100644 board/conclusive/kstr-sama5d27/Kconfig create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS create mode 100644 board/conclusive/kstr-sama5d27/Makefile create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c create mode 100644 configs/kstr_sama5d27_defconfig create mode 100644 include/configs/kstr-sama5d27.h -- 2.42.0
[PATCH v5 4/8] rockchip: block: blk-uclass: add bounce buffer flag to blk_desc
Currently bounce buffer support is enabled for all block devices
when available. Add a flag to blk_desc to enable only on demand.
Signed-off-by: Johan Jonker
---
Changed V5:
New patch
---
drivers/block/blk-uclass.c | 4 ++--
drivers/scsi/scsi.c| 4
include/blk.h | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 30ad5bbb0024..77066da352a3 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -441,7 +441,7 @@ long blk_read(struct udevice *dev, lbaint_t start, lbaint_t
blkcnt, void *buf)
start, blkcnt, desc->blksz, buf))
return blkcnt;
- if (IS_ENABLED(CONFIG_BOUNCE_BUFFER)) {
+ if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && desc->bb) {
struct blk_bounce_buffer bbstate = { .dev = dev };
int ret;
@@ -478,7 +478,7 @@ long blk_write(struct udevice *dev, lbaint_t start,
lbaint_t blkcnt,
blkcache_invalidate(desc->uclass_id, desc->devnum);
- if (IS_ENABLED(CONFIG_BOUNCE_BUFFER)) {
+ if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && desc->bb) {
struct blk_bounce_buffer bbstate = { .dev = dev };
int ret;
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 7411660d465e..779a34bd2f1c 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -459,6 +459,9 @@ static void scsi_init_dev_desc_priv(struct blk_desc
*dev_desc)
dev_desc->product[0] = 0;
dev_desc->revision[0] = 0;
dev_desc->removable = false;
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+ dev_desc->bb = true;
+#endif /* CONFIG_BOUNCE_BUFFER */
}
#if !defined(CONFIG_DM_SCSI)
@@ -606,6 +609,7 @@ static int do_scsi_scan_one(struct udevice *dev, int id,
int lun, bool verbose)
bdesc->lun = lun;
bdesc->removable = bd.removable;
bdesc->type = bd.type;
+ bdesc->bb = bd.bb;
memcpy(>vendor, , sizeof(bd.vendor));
memcpy(>product, , sizeof(bd.product));
memcpy(>revision, , sizeof(bd.revision));
diff --git a/include/blk.h b/include/blk.h
index 76bd5baf9959..7c7cf7f2b102 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -68,6 +68,7 @@ struct blk_desc {
/* device can use 48bit addr (ATA/ATAPI v7) */
boollba48;
unsigned char atapi; /* Use ATAPI protocol */
+ unsigned char bb; /* Use bounce buffer */
lbaint_tlba;/* number of blocks */
unsigned long blksz; /* block size */
int log2blksz; /* for convenience: log2(blksz) */
--
2.39.2
[PATCH v5 3/8] rockchip: block: add rkmtd class and drivers
Add rkmtd class and drivers to create a virtual block device
to transfer Rockchip boot block data to and from NAND with
block orientated tools like "ums" and "rockusb".
Signed-off-by: Johan Jonker
Reviewed-by: Kever Yang
---
Changed V5:
Use devres_alloc in bind
Restyle
Changed V4:
Sort includes
Replace constant by define
Changed V3:
New patch
Split driver from command
Split header
Use devm_kzalloc
Remove out of memory debug
Restyle
---
drivers/block/Kconfig |7 +
drivers/block/Makefile |2 +
drivers/block/rkmtd.c | 1152
include/rkmtd.h| 191 +++
4 files changed, 1352 insertions(+)
create mode 100644 drivers/block/rkmtd.c
create mode 100644 include/rkmtd.h
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 1abea3f10db4..048a6caef00f 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -262,3 +262,10 @@ config SYS_64BIT_LBA
help
Make the block subsystem use 64bit sector addresses, rather than the
default of 32bit.
+
+config RKMTD
+ bool "Rockchip rkmtd virtual block device"
+ help
+ Enable "rkmtd" class and driver to create a virtual block device
+ to transfer Rockchip boot block data to and from NAND with block
+ orientate tools like "ums" and "rockusb".
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index a161d145fd39..fdcba5c8318f 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -11,6 +11,7 @@ endif
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_IDE) += ide.o
+obj-$(CONFIG_RKMTD) += rkmtd.o
endif
obj-$(CONFIG_SANDBOX) += sandbox.o host-uclass.o host_dev.o
obj-$(CONFIG_$(SPL_TPL_)BLOCK_CACHE) += blkcache.o
@@ -19,3 +20,4 @@ obj-$(CONFIG_BLKMAP) += blkmap.o
obj-$(CONFIG_EFI_MEDIA) += efi-media-uclass.o
obj-$(CONFIG_EFI_MEDIA_SANDBOX) += sb_efi_media.o
obj-$(CONFIG_EFI_MEDIA_BLK) += efi_blk.o
+
diff --git a/drivers/block/rkmtd.c b/drivers/block/rkmtd.c
new file mode 100644
index ..c55f052e51b9
--- /dev/null
+++ b/drivers/block/rkmtd.c
@@ -0,0 +1,1152 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Some functions are derived from:
+ *
https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/rknand/rk_ftl_arm_v7.S
+ * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Driver interface derived from:
+ * /drivers/block/host_dev.c
+ * /drivers/block/host-uclass.c
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ *
+ * Copyright (C) 2023 Johan Jonker
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#if !IS_ENABLED(CONFIG_SANDBOX)
+#include
+#endif
+#include
+
+struct nand_para_info nand_para_tbl[] = {
+ {6, {0x2c, 0x64, 0x44, 0x4b, 0xa9, 0x00}, 4, 1, 16, 256, 2, 2, 2048,
0x01df, 3, 17, 40, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x44, 0x44, 0x4b, 0xa9, 0x00}, 4, 1, 16, 256, 2, 2, 1064,
0x01df, 3, 17, 40, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x68, 0x04, 0x4a, 0xa9, 0x00}, 4, 1, 8, 256, 2, 2, 2048,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {5, {0x2c, 0x88, 0x04, 0x4b, 0xa9, 0x00}, 4, 1, 16, 256, 2, 2, 2048,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0xa8, 0x05, 0xcb, 0xa9, 0x00}, 4, 2, 16, 256, 2, 2, 2048,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x68, 0x04, 0x46, 0x89, 0x00}, 4, 1, 8, 256, 2, 2, 2048,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x48, 0x04, 0x4a, 0xa5, 0x00}, 4, 1, 8, 256, 2, 2, 1024,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x84, 0x64, 0x3c, 0xa5, 0x00}, 4, 1, 32, 512, 2, 2, 1024,
0x01df, 3, 17, 40, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {5, {0x2c, 0x84, 0x64, 0x54, 0xa9, 0x00}, 4, 1, 32, 512, 2, 2, 1024,
0x01df, 4, 18, 60, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0xd7, 0x94, 0x3e, 0x84, 0x00}, 4, 1, 8, 128, 2, 2, 4096,
0x0117, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x48, 0x04, 0x46, 0x85, 0x00}, 4, 1, 8, 256, 2, 2, 1024,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x88, 0x05, 0xc6, 0x89, 0x00}, 4, 2, 8, 256, 2, 2, 2048,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {5, {0x2c, 0x88, 0x24, 0x4b, 0xa9, 0x00}, 4, 1, 16, 256, 2, 2, 2048,
0x011f, 1, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x68, 0x00, 0x27, 0xa9, 0x00}, 4, 1, 16, 128, 1, 2, 2048,
0x011f, 0, 0, 24, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {5, {0x2c, 0x64, 0x64, 0x56, 0xa5, 0x00}, 4, 1, 24, 512, 2, 2, 700,
0x01df, 4, 18, 60, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+ {6, {0x2c, 0x84, 0xc5, 0x4b, 0xa9, 0x00}, 4, 2, 16, 256, 2, 2, 2048,
0x01df, 3, 17, 40, 32, 1, 0, 1, 0, 0, {0, 0, 0, 0, 0}},
+
[PATCH v5 2/8] rockchip: dm: prepare rkmtd UCLASS
Prepare a rkmtd UCLASS in use for writing Rockchip boot blocks
in combination with existing userspace tools and rockusb command.
Signed-off-by: Johan Jonker
Reviewed-by: Kever Yang
---
disk/part.c| 4
drivers/block/blk-uclass.c | 1 +
include/dm/uclass-id.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/disk/part.c b/disk/part.c
index 85244b09f359..36b88205eca7 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -197,6 +197,7 @@ void dev_print(struct blk_desc *desc)
case UCLASS_PVBLOCK:
case UCLASS_HOST:
case UCLASS_BLKMAP:
+ case UCLASS_RKMTD:
printf ("Vendor: %s Rev: %s Prod: %s\n",
desc->vendor,
desc->revision,
@@ -330,6 +331,9 @@ static void print_part_header(const char *type, struct
blk_desc *desc)
case UCLASS_PVBLOCK:
puts("PV BLOCK");
break;
+ case UCLASS_RKMTD:
+ puts("RKMTD");
+ break;
case UCLASS_VIRTIO:
puts("VirtIO");
break;
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index f126547cc7e6..30ad5bbb0024 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -36,6 +36,7 @@ static struct {
{ UCLASS_VIRTIO, "virtio" },
{ UCLASS_PVBLOCK, "pvblock" },
{ UCLASS_BLKMAP, "blkmap" },
+ { UCLASS_RKMTD, "rkmtd" },
};
static enum uclass_id uclass_name_to_iftype(const char *uclass_idname)
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 0432c95c9edc..2fc672df0a3a 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -120,6 +120,7 @@ enum uclass_id {
UCLASS_REGULATOR, /* Regulator device */
UCLASS_REMOTEPROC, /* Remote Processor device */
UCLASS_RESET, /* Reset controller device */
+ UCLASS_RKMTD, /* Rockchip MTD device */
UCLASS_RNG, /* Random Number Generator */
UCLASS_RTC, /* Real time clock device */
UCLASS_SCMI_AGENT, /* Interface with an SCMI server */
--
2.39.2
[PATCH v5 1/8] mtd: nand: raw: rockchip_nfc: add NAND_SKIP_BBTSCAN option
On Rockchip SoCs the first boot stages are written on NAND with help of manufacturer software that uses a different format then the MTD framework. Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN option to be able to pass the driver probe function and to let the original data unchanged. Signed-off-by: Johan Jonker Reviewed-by: Kever Yang --- drivers/mtd/nand/raw/Kconfig| 9 + drivers/mtd/nand/raw/rockchip_nfc.c | 3 +++ 2 files changed, 12 insertions(+) diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index d624589a892b..72547f00fbec 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -611,6 +611,15 @@ config ROCKCHIP_NAND NFC v800: RK3308, RV1108 NFC v900: PX30, RK3326 +config ROCKCHIP_NAND_SKIP_BBTSCAN + bool "Skip the automatic BBT scan with Rockchip NAND controllers" + depends on ROCKCHIP_NAND + default n + help + Skip the automatic BBT scan with the NAND_SKIP_BBTSCAN + option when data content is not in MTD format or + must remain unchanged. + config TEGRA_NAND bool "Support for NAND controller on Tegra SoCs" depends on ARCH_TEGRA diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c b/drivers/mtd/nand/raw/rockchip_nfc.c index 6ad51df4acff..df6742c2f9bb 100644 --- a/drivers/mtd/nand/raw/rockchip_nfc.c +++ b/drivers/mtd/nand/raw/rockchip_nfc.c @@ -981,6 +981,9 @@ static int rk_nfc_nand_chip_init(ofnode node, struct rk_nfc *nfc, int devnum) chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB; chip->options |= NAND_NO_SUBPAGE_WRITE | NAND_USE_BOUNCE_BUFFER; + if (IS_ENABLED(CONFIG_ROCKCHIP_NAND_SKIP_BBTSCAN)) + chip->options |= NAND_SKIP_BBTSCAN; + rk_nfc_hw_init(nfc); ret = nand_scan_ident(mtd, nsels, NULL); if (ret) -- 2.39.2
[PATCH v5 0/8] Add rkmtd command
The command rkmtd creates a virtual block device to transfer Rockchip boot block data to and from NAND with block orientated tools like "ums" and "rockusb". It uses the Rockchip MTD driver to scan for boot blocks and copies data from the first block in a GPT formatted virtual disk. Data must be written in U-boot "idbloader.img" format and start at partition "loader1" offset 64. The data header is parsed for length and offset. When the last sector is received it erases up to 5 erase blocks on NAND and writes boot blocks in a pattern depending on the NAND ID. Data is then verified. When a block turns out bad the block header is discarded. Changed V5: Add bounce buffer flag Use devres_alloc in bind Restyle Changed V4: Sort includes Replace constant by define Enable rkmtd command in sandbox defconfig Fix minor things in test Changed V3: Add documetation Add test Split driver from command Split header Use devm_kzalloc Remove out of memory debug Restyle Changed V2: Rename to rkmtd Johan Jonker (8): mtd: nand: raw: rockchip_nfc: add NAND_SKIP_BBTSCAN option rockchip: dm: prepare rkmtd UCLASS rockchip: block: add rkmtd class and drivers rockchip: block: blk-uclass: add bounce buffer flag to blk_desc rockchip: cmd: add rkmtd command rockchip: test: dm: add rkmtd test rockchip: doc: add rkmtd.rst rockchip: configs: sandbox: enable rkmtd command cmd/Kconfig |8 + cmd/Makefile|1 + cmd/rkmtd.c | 204 + configs/sandbox64_defconfig |1 + configs/sandbox_defconfig |1 + disk/part.c |4 + doc/board/rockchip/index.rst|1 + doc/board/rockchip/rkmtd.rst| 105 +++ drivers/block/Kconfig |7 + drivers/block/Makefile |2 + drivers/block/blk-uclass.c |5 +- drivers/block/rkmtd.c | 1152 +++ drivers/mtd/nand/raw/Kconfig|9 + drivers/mtd/nand/raw/rockchip_nfc.c |3 + drivers/scsi/scsi.c |4 + include/blk.h |1 + include/dm/uclass-id.h |1 + include/rkmtd.h | 191 + test/dm/Makefile|1 + test/dm/rkmtd.c | 200 + 20 files changed, 1899 insertions(+), 2 deletions(-) create mode 100644 cmd/rkmtd.c create mode 100644 doc/board/rockchip/rkmtd.rst create mode 100644 drivers/block/rkmtd.c create mode 100644 include/rkmtd.h create mode 100644 test/dm/rkmtd.c -- 2.39.2
Re: [PATCH v3 06/32] sifive: Drop an unnecessary #ifdef
On 10/17/23 00:27, Simon Glass wrote:
This code is normally compiled for sifive, but sandbox can also compile
it. We should not use UNIT_TEST as a synonym for SANDBOX, since it is
possible to disable UNIT_TEST for sandbox.
Drop the condition since it isn't needed.
This is not what the patch does. It introduces another condition.
Signed-off-by: Simon Glass
Suggested-by: Sean Anderson
---
Changes in v3:
- Just drop the condition instead
include/k210/pll.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/k210/pll.h b/include/k210/pll.h
index fd16a89cb203..6dd60b2eb4fc 100644
--- a/include/k210/pll.h
+++ b/include/k210/pll.h
@@ -13,7 +13,7 @@ struct k210_pll_config {
u8 od;
};
-#ifdef CONFIG_UNIT_TEST
+#ifdef CONFIG_SANDBOX
We should be able to compile with and without unit tests on the MAIX
boards. Why should CONFIG_SANDBOX have any relevance here?
Why don't we make k210_pll_calc_config() non-static in all cases?
Best regards
Heinrich
TEST_STATIC int k210_pll_calc_config(u32 rate, u32 rate_in,
struct k210_pll_config *best);
#ifndef nop
[PATCH v2] cros_ec: spi: disable annoying key echo on console
on Peach-pi console every key press is echoed with message
'cros_ec_command: Returned status 1'
this is not proper fix, just hack to disable this message
Signed-off-by: Milan P. Stanić
Reviewed-by: Simon Glass
---
changed patch to use log_debug and added forgoten Signed-off-by and
and Reviewed-by Simon response mail
drivers/misc/cros_ec_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
index 001f0a85ca..591ff30df8 100644
--- a/drivers/misc/cros_ec_spi.c
+++ b/drivers/misc/cros_ec_spi.c
@@ -151,7 +151,7 @@ int cros_ec_spi_command(struct udevice *udev, uint8_t cmd,
int cmd_version,
/* Response code is first byte of message */
if (p[0] != EC_RES_SUCCESS) {
- printf("%s: Returned status %d\n", __func__, p[0]);
+ log_debug("Returned status %d\n", p[0]);
return -(int)(p[0]);
}
--
2.42.0
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote: > Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is > available, add it as an explicit dependency. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Add new patch to update EFI_LOADER to depend on DM_ETH > > lib/efi_loader/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index 13cad6342c36..fca4b3eef270 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -11,6 +11,7 @@ config EFI_LOADER > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > depends on BLK > + depends on DM_ETH > depends on !EFI_APP > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 > select CHARSET I don't think this is needed. After reconfiguring qemu_arm64 to be able to disable networking entirely, we still are able to build with EFI_LOADER enabled, and no warning / link errors. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 02/32] bootstd: Correct dependencies on CMDLINE
On Tue, Oct 17, 2023 at 09:30:30PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 17 Oct 2023 at 07:32, Tom Rini wrote: > > > > On Mon, Oct 16, 2023 at 04:27:53PM -0600, Simon Glass wrote: > > > > > With recent changes over the last few years in boot/Kconfig it is > > > no-longer possible to disable CMDLINE. It results in various link > > > errors because some options which require CMDLINE are enabled > > > regardless of whether it is available. > > > > > > Add the necessary conditions to fix this. > > > > > > Note that it would be better to have all commands depend on CMDLINE, > > > but that is extremely difficult at present, since some functions use > > > CMD_xxx to enable feature xxx. For example networking and environment > > > have a number of problems to tease apart. > > > > > > Signed-off-by: Simon Glass > > > > Since you later rework things to tease apart most, if not all of this, > > please split out the patches which tease things apart in to their own > > series so that the rest of this becomes reviewable and also reasonable > > looking. > > At this point I fear I have lost track of things, since there is just > too much going on. Yes, there is too much going on, which is why I wanted you to split this up further. I think we both agree that's a problem with this series. > Just in this version I have dealt with: > > - some EFI stuff (which needs tweaking) > - teasing apart the CLI handling (which apparently doesn't go far enough?) I don't think it's fair to call out EFI here, it's fairly well behaved and no worse / oddly using CONFIG symbols than video or networking or just about everything else is. > Before this version I already looked at environment (which you say > doesn't go far enough, and fair enough, but please review the code as > sent, not what you wish it was). Well, that's just it. I did, and I wasn't entirely sure how you were splitting things was right. There was more stuff that either didn't belong or should also have been moved, it wasn't clear. The split I'm suggesting there should make it clear. > Perhaps you could apply whatever seems reasonable and then I can take > another look? Or suggest some small changes that would allow progress > to be made. I guess I'll see what I can make some sense out of, yes. > But do note that supporting booting without CONFIG_CMDLINE is a large > effort, the subject of 5-10 series, perhaps more. It is not my > intention to undertake that in this series, or before this series > lands Well, one of my issues here, especially with the idea of cycling back and cleaning things up later is that I kind of assume you had intended to do that in some places already, having done the good and important task of breaking up the old common directory. > The problem, also, is that without this series, it isn't possible to > start that work. With this series, one can look at what code is > missing and find a way to call boot functions (for example) bypassing > the command line. Once you get it booting you are good. Without this > series, you don't even know where to look, since calls to the command > line happen silently. That's where I disagree. Step one is working towards being able to build with CMDLINE disabled, and doing it in small reviewable chunks. This is one big series that gives you "can build with CMDLINE disabled", but while I'm usually not a fan of the Linux kernel's strict "break it down per subsystem", I'd be a lot happier here, and we'd have quicker progress too I bet, if instead of 1 30 part series we had 5 or 6 smaller series. > So I think this series is a big step forward and urge another look, please. That's what I did with v3 yesterday and why I had a bunch of other feedback. But, yes, I'll take some parts of v3 and see what I can come up with. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 04/32] cmd: Add a few more dependencies on CMDLINE
On 10/17/23 00:27, Simon Glass wrote: Add this to some more commands to avoid build errors with sandbox. Note that this is a temporary solution to expose more problems. A later patch puts these behind an 'if CMDLINE' Signed-off-by: Simon Glass --- Changes in v3: - Add an explation as to why this patch is here cmd/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 5bc0a92d57ad..00a7f84bce99 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -231,6 +231,7 @@ menu "Boot commands" config CMD_BOOTD bool "bootd" + depends on CMDLINE Why don't we simply use a single "if" for all commands? Adding the same dependency to 200+ commands does not feel right. If there is any CONFIG_CMD* that is needed without CMDLINE, then that code should move to lib/ or drivers/. Best regards Heinrich default y help Run the command stored in the environment "bootcmd", i.e. @@ -420,6 +421,7 @@ source lib/efi_selftest/Kconfig config CMD_BOOTMENU bool "bootmenu" + depends on CMDLINE select MENU select CHARSET help @@ -486,6 +488,7 @@ config CMD_GO config CMD_RUN bool "run" + depends on CMDLINE default y help Run the command in the given environment variable. @@ -576,6 +579,7 @@ menu "Environment commands" config CMD_ASKENV bool "ask for env variable" + depends on CMDLINE help Ask for environment variable @@ -2132,6 +2136,7 @@ config CMD_EFICONFIG config CMD_EXCEPTION bool "exception - raise exception" + depends on CMDLINE depends on ARM || RISCV || SANDBOX || X86 help Enable the 'exception' command which allows to raise an exception. @@ -2238,6 +2243,7 @@ config CMD_SYSBOOT config CMD_QFW bool "qfw" + depends on CMDLINE select QFW help This provides access to the QEMU firmware interface. The main
Re: [PATCH 3/5] smbios: Use SMBIOS 3.0 to support an address above 4GB
On 18/10/2023 04:33, Simon Glass wrote:
> Hi Caleb,
>
> On Tue, 17 Oct 2023 at 11:59, Caleb Connolly
> wrote:
>>
>> Hi Both,
>>
>> [...]
>
> @@ -513,13 +517,23 @@ ulong write_smbios_table(ulong addr)
>*/
> table_addr = (ulong)map_sysmem(tables, 0);
> if (sizeof(table_addr) > sizeof(u32) && table_addr >
> (ulong)UINT_MAX) {
You have to check the end address of the table not the start address here.
The SMBIOS specification says that you should always supply a 32bit
SMBIOS entry point. Of course this is not possible on boards that don't
have low memory.
In install_smbios_table() this can be achieved by calling
efi_allocate_pages() with EFI_MAX_ALLOCATE_TYPE and a maximum address of
4 GiB - 1. Only if this fails use high memory.
>>>
>>> Hmm perhaps we need a way to allocate memory below 4GB in U-Boot? How
>>> does this EFI function work?
>>
>> Yes, prior to 53fab13a7b11 ("efi: Use the installed SMBIOS tables")
>> efi_allocate_pages() was called directly from efi_smbios_register(). My
>> boards all malloc() memory above the 4GB boundary and I just recently
>> rebased and hit a regression caused by this.
>>
>> In my testing, calling efi_allocate_pages() from install_smbios_table()
>> did work, but I figure that's probably not intended behaviour...
>>
>> I can confirm that this series does allow my boards to boot again, but
>> dmidecode is unable to decode the SMBIOS 3.0 table (even with
>> STRICT_DEVMEM disabled fwiw).
>
> OK thank you for digging into this. So I suppose I can repeat that in
> qemu, with a suitable distro?
I would assume so, I'm running Alpine in my testing. I'd be more than
happy to test any patches as well.
>
>>
>> Below is EFI and board memory map info after applying this patch series.
>>
>> => efidebug tables
>> Cannot read EFI system partition
>> Cannot read EFI system partition
>> Failed to persist EFI variables
>> 00017ea22040 32313633-3532-3634-2d66-3765662d3463 EFI Conformance
>> Profiles Table
>> 00017ea21040 36366265-3139-6138-2d37-6565662d3430 Runtime properties
>> 00017fb13000 64663266-3531-3434-2d39-3739342d3461 (unknown)
>> => efidebug memmap
>> Type StartEnd Attributes
>> ==
>> CONVENTIONAL 8000-00017ea1f000 WB
>> BOOT DATA00017ea1f000-00017ea21000 WB
>> RUNTIME DATA 00017ea21000-00017ea22000 WB|RT
>> BOOT DATA00017ea22000-00017ea23000 WB
>> RUNTIME DATA 00017ea23000-00017ea25000 WB|RT
>> BOOT DATA00017ea25000-00017ea26000 WB
>> RUNTIME DATA 00017ea26000-00017ea36000 WB|RT
>> BOOT DATA00017ea36000-00017eaef000 WB
>> BOOT CODE00017eaef000-00017fb13000 WB
>> RUNTIME DATA 00017fb13000-00017fb14000 WB|RT
>> BOOT CODE00017fb14000-00017ff2 WB
>> RUNTIME CODE 00017ff2-00017ff3 WB|RT
>> BOOT CODE00017ff3-00018000 WB
>> BOOT DATA00018000-00027c7a WB
>> => bdinfo
>> boot_params = 0x
>> DRAM bank = 0x
>> -> start= 0x8000
>> -> size = 0x0001
>> DRAM bank = 0x0001
>> -> start= 0x00018000
>> -> size = 0xfc7a
>> flashstart = 0x
>> flashsize = 0x
>> flashoffset = 0x
>> baudrate= 115200 bps
>> relocaddr = 0x00017ff26000
>> reloc off = 0x00017ff26000
>> Build = 64-bit
>> fdt_blob= 0x00017faef6c0
>> new_fdt = 0x00017faef6c0
>> fdt_size= 0x00017680
>> Video = framebuffer@9D40 active
>> FB base = 0x9d40
>> FB size = 1080x2160x32
>> lmb_dump_all:
>> memory.cnt = 0x1 / max = 0x40
>> memory[0] [0x8000-0x27c79], 0x1fc7a bytes flags: 0
>> reserved.cnt = 0x7 / max = 0x40
>> reserved[0][0x8570-0x85cf], 0x0060 bytes flags: 4
>> reserved[1][0x85e0-0x85ef], 0x0010 bytes flags: 4
>> reserved[2][0x85fc-0x890f], 0x0314 bytes flags: 4
>> reserved[3][0x8ab0-0x8c416fff], 0x01917000 bytes flags: 4
>> reserved[4][0x8c50-0x97bf], 0x0b70 bytes flags: 4
>> reserved[5][0x9d40-0x9f7f], 0x0240 bytes flags: 4
>> reserved[6][0x17ea1f000-0x27c79], 0xfdd81000 bytes flags: 0
>> devicetree = board
>> arch_number = 0x
>> TLB addr= 0x00017fff
>> irq_sp = 0x00017faef6b0
>> sp start= 0x00017faef6b0
>> Early malloc usage: a78 / 2000
>>>
>>> I don't think EFI has been set up by the time this function is called.
>>>
>>> Regards,
>>> Simon
>>
>> --
>> // Caleb (they/them)
>
> Regards,
> Simon
--
// Caleb (they/them)
Re: [PATCH v3 04/32] cmd: Add a few more dependencies on CMDLINE
On Tue, Oct 17, 2023 at 09:30:46PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 17 Oct 2023 at 07:32, Tom Rini wrote: > > > > On Mon, Oct 16, 2023 at 04:27:55PM -0600, Simon Glass wrote: > > > > > Add this to some more commands to avoid build errors with sandbox. > > > > > > Note that this is a temporary solution to expose more problems. A later > > > patch puts these behind an 'if CMDLINE' > > > > > > Signed-off-by: Simon Glass > > > > We're doing a bunch of churn here that I'd rather just get done at once, > > make the current #27 which guards all commands with if CMDLINE happen > > earlier in the series instead. > > Yes I did consider this when reviewing this patch for v3, but got > build-bisect failures. I cannot move #27 earlier, since all the builds > fail. Allowing #27 to pass is the point of this series, in fact. Yes, I suspect a number of the other patches need to be shuffled around as well. > If we can make progress on the thrust of this series then I will see > if I can somehow reorder some other patches to drop this patch, or > move it later, or cut it down, or something else... > > I also don't agree with 'bunch of'. This is 6 lines, which enables > another 20 patches which clean everything up. Are there other patches > with churn? Other patches in the series also added if CMDLINE or similar sets of dependencies that then get pulled out in #27. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
On 10/17/23 16:09, Tom Rini wrote: On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote: Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is available, add it as an explicit dependency. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Add new patch to update EFI_LOADER to depend on DM_ETH lib/efi_loader/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 13cad6342c36..fca4b3eef270 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -11,6 +11,7 @@ config EFI_LOADER # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT depends on BLK + depends on DM_ETH depends on !EFI_APP default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 select CHARSET Does this work for you Heinrich, or do you want to clarify the dependencies (and re-organize the code as needed) around networking? We should be able to boot via EFI on devices without U-Boot network support. We already use IS_ENABLED(CONFIG_NETDEVICES) to avoid invoking eth_get_dev() if there is no network. CONFIG_NETDEVICES=y selects CONFIG_DM_ETH. Why is this not sufficient? Is there a configuration that does not build? Best regards Heinrich
Re: [PATCH RESEND] sunxi: add axp313a support
hi, > Yes, we have been looking at this for a while, and there is code out > there. The latest drop is from Mikhail: > https://lore.kernel.org/u-boot/20231016053441.3197087-2-iunc...@gmail.com/ > If you can try this, maybe even review it, that would be great. I got mail from Mikhail and received patchset. I will try. Best regards, -- SASANO Takayoshi (JG1UAA)
Re: [PATCH] sphinx: Bump urllib3 version
On 10/18/23 14:33, Tom Rini wrote: While unlikely to be a direct issue for us, urllib3 before 2.0.7 is vulnerable to CVE-2023-45803, so bump our version up. Reported-by: GitHub dependabot Signed-off-by: Tom Rini Reviewed-by: Heinrich Schuchardt --- Cc: Heinrich Schuchardt --- doc/sphinx/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 6d45a3fefffe..39ececb96c2b 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -23,4 +23,4 @@ sphinxcontrib-htmlhelp==2.0.0 sphinxcontrib-jsmath==1.0.1 sphinxcontrib-qthelp==1.0.3 sphinxcontrib-serializinghtml==1.1.5 -urllib3==2.0.6 +urllib3==2.0.7
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
On Tue, Oct 17, 2023 at 09:31:34PM -0600, Simon Glass wrote: > Hi, > > On Tue, 17 Oct 2023 at 08:09, Tom Rini wrote: > > > > On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass wrote: > > > > > Since efi_device_path.c calls eth_get_dev() and assumes that Ethernet is > > > available, add it as an explicit dependency. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > (no changes since v2) > > > > > > Changes in v2: > > > - Add new patch to update EFI_LOADER to depend on DM_ETH > > > > > > lib/efi_loader/Kconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > index 13cad6342c36..fca4b3eef270 100644 > > > --- a/lib/efi_loader/Kconfig > > > +++ b/lib/efi_loader/Kconfig > > > @@ -11,6 +11,7 @@ config EFI_LOADER > > > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > > > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > > > depends on BLK > > > + depends on DM_ETH > > > depends on !EFI_APP > > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 > > > select CHARSET > > > > Does this work for you Heinrich, or do you want to clarify the > > dependencies (and re-organize the code as needed) around networking? > > It would be great to tidy up networking in lots of ways...perhaps we > should add ~CMDLINE support to the list of post-lwip tasks if it lands But this isn't even directly networking. It's I believe that the network related portion of EFI loader isn't optional today. But perhaps it could / should be? -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 19/32] video: Dont require the font command
On Tue, Oct 17, 2023 at 09:31:29PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 17 Oct 2023 at 08:07, Tom Rini wrote: > > > > On Mon, Oct 16, 2023 at 04:28:10PM -0600, Simon Glass wrote: > > > While it is nice to have the font command, using 'select' makes it > > > impossible to build the console code without it. Change this to use > > > 'imply' instead. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > (no changes since v1) > > > > > > drivers/video/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > > > index ab927641bb7a..21ea5c860cca 100644 > > > --- a/drivers/video/Kconfig > > > +++ b/drivers/video/Kconfig > > > @@ -180,7 +180,7 @@ config CONSOLE_ROTATION > > > > > > config CONSOLE_TRUETYPE > > > bool "Support a console that uses TrueType fonts" > > > - select CMD_SELECT_FONT > > > + imply CMD_SELECT_FONT > > > help > > > TrueTrype fonts can provide outline-drawing capability rather than > > > needing to provide a bitmap for each font and size that is needed. > > > > This is one of those cases where "if CMDLINE" makes sense to add > > somewhere. > > Maybe, if you can explain it a bit more. I want boards to be able to > enable or disable this command, independently of whether truetype > fonts are supported. Using 'select' here seems quite inflexible. Ah, OK. Checking the command itself, we should drop the select here and make CMD_SELECT_FONT default y if CONSOLE_TRUETYPE (and drop the default n line it has). -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 18/32] video: Allow use without CONFIG_CMDLINE
On Tue, Oct 17, 2023 at 09:31:22PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 17 Oct 2023 at 08:07, Tom Rini wrote:
> >
> > On Mon, Oct 16, 2023 at 04:28:09PM -0600, Simon Glass wrote:
> >
> > > Provide a fallback for when CONFIG_SYS_CBSIZE is not provided, so that
> > > the console can still be used.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > drivers/video/console_truetype.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/video/console_truetype.c
> > > b/drivers/video/console_truetype.c
> > > index 14fb81e9563c..e4dad3f9a191 100644
> > > --- a/drivers/video/console_truetype.c
> > > +++ b/drivers/video/console_truetype.c
> > > @@ -125,7 +125,11 @@ struct pos_info {
> > > * Allow one for each character on the command line plus one for each
> > > newline.
> > > * This is just an estimate, but it should not be exceeded.
> > > */
> > > +#ifdef CONFIG_SYS_CBSIZE
> > > #define POS_HISTORY_SIZE (CONFIG_SYS_CBSIZE * 11 / 10)
> > > +#else
> > > +#define POS_HISTORY_SIZE (250 * 11 / 10)
> > > +#endif
> > >
> > > /**
> > > * struct console_tt_metrics - Information about a font / size
> > > combination
> >
> > NAK, this either should be SYS_PBSIZE (output buffer) instead which you
> > move out from under CMDLINE or SYS_CBSIZE (input buffer) should also be
> > outside, and both get a help text to explain them a bit better.
>
> I think PBSIZE would be better. Even better (eventually) will be to
> drop this truetype buffer if input is not needed.
Then lets switch this to PBSIZE.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 14/32] bootm: Allow building when cleanup functions are missing
On Tue, Oct 17, 2023 at 09:31:04PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 17 Oct 2023 at 08:02, Tom Rini wrote: > > > > On Mon, Oct 16, 2023 at 04:28:05PM -0600, Simon Glass wrote: > > > > > There are two cleanup functions needed during boot which depend on > > > CMD_BOOTM: bootm_disable_interrupts() and board_quiesce_devices() > > > > > > Provide static inline versions of these for when commands are not > > > enabled. > > > > > > Signed-off-by: Simon Glass > > > > NAK, these functions need to be available to boot the OS, regardless of > > command line existing or not. Unwind things in the other direction > > please. > > That won't be a successful strategy. See my other reply on this. I > have had this idea since 2016 and have looked at it every now and > then. With bootstd it makes more sense since we actually have a > framework to boot without the command line. This series enables such > work, but cannot include it. I don't understand. The "cleanup" functions here are to ensure that any devices that we've touched are in the state the OS needs them to be. It's not "we ran a command", it's "we loaded something off of USB (or network or MMC or ..)" and so we must have those called. -- Tom signature.asc Description: PGP signature
[PATCH] sphinx: Bump urllib3 version
While unlikely to be a direct issue for us, urllib3 before 2.0.7 is vulnerable to CVE-2023-45803, so bump our version up. Reported-by: GitHub dependabot Signed-off-by: Tom Rini --- Cc: Heinrich Schuchardt --- doc/sphinx/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 6d45a3fefffe..39ececb96c2b 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -23,4 +23,4 @@ sphinxcontrib-htmlhelp==2.0.0 sphinxcontrib-jsmath==1.0.1 sphinxcontrib-qthelp==1.0.3 sphinxcontrib-serializinghtml==1.1.5 -urllib3==2.0.6 +urllib3==2.0.7 -- 2.34.1
Re: [PATCH] spl: mmc: Fix subsequent calls to spl_mmc_load with CONFIG_BLK
On Sat, 07 Oct 2023 21:47:48 -0400, Sean Anderson wrote: > MMC devices do not have uclass platdata containing blk_descs, only their > child block devices do. Fortunately, we have a function just for this > purpose. This fixes subsequent calls to spl_mmc_load. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] Revert "fs: ext4: check the minimal partition size to mount"
On Sat, 30 Sep 2023 16:42:46 -0400, Sean Anderson wrote: > This check breaks small partitions (under 1024 blocks) because part_length > is in units of part.blksz and not bytes. Given the purpose of this > function, we really want to make sure the partition is SUPERBLOCK_START + > SUPERBLOCK_SIZE (2048) bytes so we can call ext4_read_superblock without > error. > > The obvious solution is to convert callers from things like > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v2 00/29] test: spl: Test some load methods
On Sat, Oct 14, 2023 at 04:47:36PM -0400, Sean Anderson wrote: > This series adds some tests for various SPL load methods, with the intent of > helping debug v6 of [1]. With that in mind, notable omissions include NAND and > ROMAPI, which both lack sandbox implementations, and OS_BOOT, which I have > deferred due to its complexity. Semihosting is also omitted, but I think we > can > test that with qemu. > > In order to test all of these methods, we must first generate suitable images, > possibly on filesystems. While other tests have historically generated these > images using external tools (e.g. mkimage, mkfs, etc.), I have chosen to > generate them on the fly. This is for a few reasons: > > - By removing external dependencies on pytest to create certain files, the > tests > become self-contained. This makes them easier to iterate on and debug. > - By generating tests at runtime, we can dynamically vary the content. This > helps detect test failures, as even if tests are loaded to the same > location, > the expected content will be different. > - We are not testing the image parsers themselves (e.g. spl_load_simple_fit or > fs_read) but rather the load methods (e.g. spl_mmc_load_image). It is > unnecessary to exercise full functionality or generate 100% correct images. > - By reducing functionality to only what is necessary, the complexity of > various > formats can often be greatly reduced. > > This series depends on [2-3], which are small fixes identified through this > patch set. The organization of patches in this series is as follows: > > - General fixes for bugs which are unlikely to be triggered outside of this > series > - Changes to IMX8 container images to facilitate testing > - General prep. work, particularly regarding linker issues > - The tests themselves > > Passing CI at [4]. > > [1] > https://lore.kernel.org/all/20230731224304.111081-1-sean.ander...@seco.com/ > [2] https://lore.kernel.org/all/20230930204246.515254-1-sean...@gmail.com/ > [3] https://lore.kernel.org/all/20231008014748.1987840-1-sean...@gmail.com/ > [4] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/18128 For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootm: Fix flags used for bootargs string substitution
Hi Simon, Tom
Thanks for your feedback
> On Tue, 17 Oct 2023 at 10:35, Tom Rini wrote:
>>
>> Checkpatch will complain that this should be:
>> In commit 51bb33846ad2 ("bootm: Support string substitution in
>> bootargs")
Actually it did not complain, but I'll fix.
> On 18.10.2023 05:32, Simon Glass wrote:
> Oh wow that is a terrible bug. We have lots of test coverage of
> bootm_process_cmdline_env() and below, but bootm itself is still quite
> spotty.
>
> I wonder if we could add something to run_fit_test to check this. We
> have lots of tests for bootm_process_cmdline_env() but not much of
> bootm itself. It might be possible to add just a few lines there, e.g.
> to set the bootargs to something and check what ends up in bootargs?
That's a good idea, I'll check
>> +ret = bootm_process_cmdline_env(images->os.os == IH_OS_LINUX ?
>> +
>> BOOTM_CL_ALL : 0);
>> This gets hard to read. I would prefer a comment and something like:
>> int flags = 0;
>> if (images->os.os == IH_OS_LINUX)
>>flags = BOOTM_CL_ALL;
>> ret = bootm_process_cmdline_env(flags);
>>
>> As the compiler should be just as smart, and that'll be clear about
>> what's going on. Thanks.
Well, I followed previous way of coding this part and it was:
ret = bootm_process_cmdline_env(images->os.os == IH_OS_LINUX ?
BOOTM_CL_SILENT : 0);
But sure, I can update to make it more readable.
Regards,
Piotr
[PATCH 2/2] vexpress64: Add MMC card to the BOOT_TARGET_DEVICES of FVP
From: Wei Chen Add MMC disk to FVP's BOOT_TARGET_DEVICES. This allows the user to boot from MMC devices. Signed-off-by: Wei Chen Signed-off-by: Qi Feng --- include/configs/vexpress_aemv8.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/vexpress_aemv8.h b/include/configs/vexpress_aemv8.h index 43f7e454d81..24d8ca08665 100644 --- a/include/configs/vexpress_aemv8.h +++ b/include/configs/vexpress_aemv8.h @@ -148,6 +148,12 @@ #define FUNC_VIRTIO(func) #endif +#ifdef CONFIG_CMD_MMC +#define FUNC_MMC(func) func(MMC, mmc, 0) +#else +#define FUNC_MMC(func) +#endif + /* * Boot by loading an Android image, or kernel, initrd and FDT through * semihosting into DRAM. @@ -204,6 +210,7 @@ func(SMH, smh, na) \ func(MEM, mem, na) \ FUNC_VIRTIO(func) \ + FUNC_MMC(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.25.1
[PATCH 1/2] misc: vexpress_config: Use member .priv_auto to set the private data
From: Wei Chen
In current vexpress_config_probe code, it sets the uclass private data
directly. This will cause one compilation error:
drivers/misc/vexpress_config.c:114:27: error: lvalue required as left operand
of assignment
114 | dev_get_uclass_priv(dev) = priv;
| ^
In this patch we set the uclass private data through struct member
.priv_auto, and this compilation error disappears.
Signed-off-by: Wei Chen
Signed-off-by: Qi Feng
---
drivers/misc/vexpress_config.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/vexpress_config.c b/drivers/misc/vexpress_config.c
index 2baca48109f..99aad1412ae 100644
--- a/drivers/misc/vexpress_config.c
+++ b/drivers/misc/vexpress_config.c
@@ -92,7 +92,7 @@ static struct misc_ops vexpress_config_ops = {
static int vexpress_config_probe(struct udevice *dev)
{
struct ofnode_phandle_args args;
- struct vexpress_config_sysreg *priv;
+ struct vexpress_config_sysreg *priv = dev_get_priv(dev);
const char *prop;
int err, prop_size;
@@ -105,11 +105,9 @@ static int vexpress_config_probe(struct udevice *dev)
if (!prop || (strncmp(prop, "arm,vexpress-sysreg", 19) != 0))
return -ENOENT;
- priv = calloc(1, sizeof(*priv));
if (!priv)
return -ENOMEM;
- dev_get_uclass_priv(dev) = priv;
priv->addr = ofnode_get_addr(args.node);
return dev_read_u32(dev, "arm,vexpress,site", >site);
@@ -127,4 +125,5 @@ U_BOOT_DRIVER(vexpress_config_drv) = {
.bind = dm_scan_fdt_dev,
.probe = vexpress_config_probe,
.ops = _config_ops,
+ .priv_auto = sizeof(struct vexpress_config_sysreg),
};
--
2.25.1
[PATCH 0/2] vexpress64: Add MMC card to the BOOT_TARGET_DEVICES of FVP
Add MMC disk to FVP's BOOT_TARGET_DEVICES. This allows the user to boot from MMC devices. While working on that, one compilation error has been observed and fixed. Wei Chen (2): misc: vexpress_config: Use member .priv_auto to set the private data vexpress64: Add MMC card to the BOOT_TARGET_DEVICES of FVP drivers/misc/vexpress_config.c | 5 ++--- include/configs/vexpress_aemv8.h | 7 +++ 2 files changed, 9 insertions(+), 3 deletions(-) -- 2.25.1
Build failed when CONFIG_TOOLS_LIBCRYPTO is disabled on latest u-boot
Hi Experts, We need to disable CONFIG_TOOLS_LIBCRYPTO in our u-boot. But when I disable CONFIG_TOOLS_LIBCRYPTO from menuconfig, my u-boot build fails. Logs: /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: tools/image-host.o: in function `read_pub_key': image-host.c:(.text+0x8f): undefined reference to `PEM_read_X509' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: image-host.c:(.text+0x9e): undefined reference to `X509_get_pubkey' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: image-host.c:(.text+0xae): undefined reference to `i2d_PublicKey' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: image-host.c:(.text+0xc1): undefined reference to `X509_free' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: tools/kwbimage.o: in function `openssl_err': kwbimage.c:(.text+0xbb): undefined reference to `ERR_get_error' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0xd7): undefined reference to `ERR_error_string' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: tools/kwbimage.o: in function `kwb_load_rsa_key': kwbimage.c:(.text+0x19d): undefined reference to `PEM_read_RSAPrivateKey' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: tools/kwbimage.o: in function `kwb_compute_pubkey_hash': kwbimage.c:(.text+0x278): undefined reference to `EVP_MD_CTX_new' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x28c): undefined reference to `EVP_MD_CTX_reset' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x291): undefined reference to `EVP_sha256' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x29c): undefined reference to `EVP_DigestInit' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x2b6): undefined reference to `EVP_DigestUpdate' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x2ca): undefined reference to `EVP_DigestFinal' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x2d9): undefined reference to `EVP_MD_CTX_reset' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x2e1): undefined reference to `EVP_MD_CTX_free' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: tools/kwbimage.o: in function `kwb_export_pubkey': kwbimage.c:(.text+0x3b2): undefined reference to `RSA_get0_key' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x3c3): undefined reference to `RSA_get0_key' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x3f5): undefined reference to `BN_num_bits' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x408): undefined reference to `BN_num_bits' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x47e): undefined reference to `BN_bn2bin' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x49f): undefined reference to `BN_bn2bin' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: tools/kwbimage.o: in function `kwb_verify': kwbimage.c:(.text+0x66f): undefined reference to `EVP_PKEY_new' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x686): undefined reference to `EVP_PKEY_set1_RSA' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x696): undefined reference to `EVP_PKEY_size' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x6a6): undefined reference to `EVP_MD_CTX_new' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x6ba): undefined reference to `EVP_MD_CTX_reset' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x6bf): undefined reference to `EVP_sha256' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x6ca): undefined reference to `EVP_DigestInit' /opt/samba/nxa08304/gcc_cross_toolchain/5.4-zeus/sysroots/x86_64-pokysdk-linux/usr/bin/ld: kwbimage.c:(.text+0x6e2): undefined
Re: failed to build u-boot mt7621_rfb_defconfig
Thank you
Re: commit 83c63f0d118 (led: Move OF "label" property parsing to core)
On 10/18/23 11:00, Rasmus Villemoes wrote: On 18/10/2023 09.43, Rasmus Villemoes wrote: On 17/10/2023 17.33, Marek Vasut wrote: Which string ? The "bcm6753-led" is driver name , so that would have to be parametrized. Exactly. The only difference between the two examples (apart from the scope of the variables) is the driver name, but I think a generic_led_bind() could just do this inside the loop: device_bind_driver_to_node(parent, parent->driver->name, ofnode_get_name(node), node, ); Ah, no, that won't work for the drivers that do distinguish between the top-level and child nodes, e.g. the gpio one. Oh well, a one-line wrapper in each driver is still better than what we have currently. Right. I can actually test the gpio-leds one if you need that, since that is what I use anyway.
Re: [PATCH 2/2] bootcount: Add driver model I2C driver
Hi Heiko, On Wed, Oct 18, 2023 at 06:31:57AM +0200, Heiko Schocher wrote: > [...] > > May Philip can use uclass_get_device_by_phandle and try a list of > possible UCLASS candidates, like UCLASS_RTC, UCLASS_I2C_EEPROM, > UCLASS_POWER,... and if found, check if parent is UCLASS_I2C... > > may not so expensive ... Looks more cheap and elegant than the other variants indeed. But I'm not sure if we can maintain generality using this approach. What if the specific I2C driver is not included in the build, because the devices "actual" functionality is not required? Or what if a driver for the specific device does not even exist in U-Boot? Wouldn't the device fail to probe then? Please correct me if I'm wrong, I'd give it a shot in that case. Otherwise I'll try it with the aforementioned device_find_global_by_ofnode() followed by device_bind_driver() using UCLASS_I2C_GENERIC (I hope that works). Best regards, Philip > > bye, > Heiko > -- > DENX Software Engineering GmbH, Managing Director: Erika Unter > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-22 Fax: +49-8142-66989-80 Email: p...@denx.de =
Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event
On 10/18/23 12:16, Minda Chen wrote:
On 2023/10/18 18:11, Marek Vasut wrote:
On 10/18/23 05:46, Minda Chen wrote:
On 2023/10/18 10:35, Marek Vasut wrote:
On 10/18/23 03:22, Minda Chen wrote:
On 2023/10/17 19:20, Marek Vasut wrote:
On 10/17/23 08:20, Minda Chen wrote:
xhci_wait_for_event() waiting TRB_TRANSFER event may return
NULL. Checking the return value to avoid crash.
Signed-off-by: Minda Chen
How did you trigger this error ? Is there a reproducer ? Details please ...
While Scanning a lenovo usb2.0 udisk， not 100 % reproduce
Can you include Linux
lsusb -vvv
output for this device and include that information in the commit message ? (or
the U-Boot info below, that works too, just please add it into the commit
message, it is important for future reference).
OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit
message
Thank you
This is log.
StarFive # usb reset
resetting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway.
Unexpected XHCI event TRB, skipping... (f77141f0 1300 02008401)
Unhandled exception: Load access fault
EPC: f7f563c6 RA: f7f563c6 TVAL: 000c
EPC: 4024a3c6 RA: 4024a3c6 reloc adjusted
Where does the crash point to in code, can you disassemble the PC pointer ? (or
maybe you can use scripts/decodecode I think)
OK， I will add EPC pointer disassemble to commit message
This part probably doesn't need to be in the commit message. I'd like to know
where the crash occurred in the code.
4024a376 :
{
4024a376: 7179addisp,sp,-48
4024a378: f406sd ra,40(sp)
4024a37a: f022sd s0,32(sp)
4024a37c: ec26sd s1,24(sp)
4024a37e: e84asd s2,16(sp)
4024a380: e44esd s3,8(sp)
4024a382: e052sd s4,0(sp)
4024a384: 89aemv s3,a1
4024a386: 84aamv s1,a0
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
4024a388: 8c4fe0efjal ra,4024844c
struct xhci_ring *ring =
ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a38c: 6785lui a5,0x1
4024a38e: 94beadd s1,s1,a5
4024a390: 9444a603lw a2,-1724(s1)
4024a394: 00198713addia4,s3,1
4024a398: 0712sllia4,a4,0x4
4024a39a: 02061793sllia5,a2,0x20
4024a39e: 9381srlia5,a5,0x20
4024a3a0: 07c9addia5,a5,18
4024a3a2: 078esllia5,a5,0x3
4024a3a4: 97aaadd a5,a5,a0
4024a3a6: 679cld a5,8(a5)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
4024a3a8: 2981sext.w s3,s3
4024a3aa: 86cemv a3,s3
struct xhci_ring *ring =
ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a3ac: 97baadd a5,a5,a4
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
4024a3ae: 4581li a1,0
4024a3b0: 473dli a4,15
struct xhci_ring *ring =
ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a3b2: 0087ba03ld s4,8(a5) # 1008
<_start-0x401feff8>
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
4024a3b6: 842amv s0,a0
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
4024a3b8: d75ff0efjal ra,4024a12c
event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
4024a3bc: 02000593li a1,32
4024a3c0: 8522mv a0,s0
4024a3c2: ebdff0efjal ra,4024a27e
field = le32_to_cpu(event->trans_event.flags);
epc-> 4024a3c6: 455clw a5,12(a0)
So the fault occurs when reading the controller register(s), do I
understand it right ?
Could it be the problem is rather some clock, which are turned off after
a fault ?
Re: [PATCH 0/2] MAINTAINERS: Add Mattijs to USB/fastboot maintainers
Hi Mattijs, > From discussions with Marek at Kernel Recipes, it seems that the USB > subsystem in U-boot need some help. > > Since I've been asked and I'm willing to help, I've added myself to > the maintainers entry. > > I have also added myself for fastboot since I'm interested in keeping > that functional as well. > > Note that I have no previous (open-source) maintainer experience so I > will do my best to learn. > Thanks for willing to help with maintaining the code. If you need any help - then just ask :-) Acked-by: Lukasz Majewski > Signed-off-by: Mattijs Korpershoek > --- > Mattijs Korpershoek (2): > MAINTAINERS: usb gadget: add Mattijs > MAINTAINERS: fastboot: add Mattijs > > MAINTAINERS | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > --- > base-commit: 65b9b3462bec2966911658836983819ab4e4823e > change-id: 20231005-mattijs-usb-6b83dde256f0 > > Best regards, Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpZ8bUIl0ylN.pgp Description: OpenPGP digital signature
Re: [PATCH 0/2] MAINTAINERS: Add Mattijs to USB/fastboot maintainers
On 10/5/23 15:04, Mattijs Korpershoek wrote: From discussions with Marek at Kernel Recipes, it seems that the USB subsystem in U-boot need some help. Since I've been asked and I'm willing to help, I've added myself to the maintainers entry. I have also added myself for fastboot since I'm interested in keeping that functional as well. Note that I have no previous (open-source) maintainer experience so I will do my best to learn. Signed-off-by: Mattijs Korpershoek Thanks. I expect Lukasz to chime in in a bit too.
Re: [PATCH 1/2] MAINTAINERS: usb gadget: add Mattijs
On 10/5/23 15:04, Mattijs Korpershoek wrote: It seems that Lukasz and Marek could get some help in maintaining the usb gadget drivers. Assign myself as maintainer. Signed-off-by: Mattijs Korpershoek Acked-by: Marek Vasut
Re: [PATCH 2/2] MAINTAINERS: fastboot: add Mattijs
On 10/5/23 15:04, Mattijs Korpershoek wrote: Fastboot has been marked as orphaned since 2021. Since I'm interested in maintaining this, assign myself. Signed-off-by: Mattijs Korpershoek Acked-by: Marek Vasut
Re: [PATCH v7 6/9] efi_loader: add CDROM short-form device path
On 10/16/23 08:45, Masahisa Kojima wrote:
UEFI specification does not mandate to support the short-form
of the CDROM media device path.
Fedora installation ISO image is identified as CDROM media
device path, supporting short-form CDROM media device path is
required to automatically add the boot option having default
file of Fedora installation image.
How is the CDROM media path created?
Why would the image not be found if the path is not shortened?
What is Fedora specific here?
What does EDK II do?
Best regards
Heinrich
Signed-off-by: Masahisa Kojima
---
lib/efi_loader/efi_device_path.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index ed7214f3a3..ac673ab117 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -110,7 +110,8 @@ struct efi_device_path *efi_dp_shorten(struct
efi_device_path *dp)
while (dp) {
if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB_WWI) ||
EFI_DP_TYPE(dp, MEDIA_DEVICE, HARD_DRIVE_PATH) ||
- EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH))
+ EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH) ||
+ EFI_DP_TYPE(dp, MEDIA_DEVICE, CDROM_PATH))
return dp;
dp = efi_dp_next(dp);
Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event
On 2023/10/18 18:11, Marek Vasut wrote:
> On 10/18/23 05:46, Minda Chen wrote:
>>
>>
>> On 2023/10/18 10:35, Marek Vasut wrote:
>>> On 10/18/23 03:22, Minda Chen wrote:
On 2023/10/17 19:20, Marek Vasut wrote:
> On 10/17/23 08:20, Minda Chen wrote:
>> xhci_wait_for_event() waiting TRB_TRANSFER event may return
>> NULL. Checking the return value to avoid crash.
>>
>> Signed-off-by: Minda Chen
>
> How did you trigger this error ? Is there a reproducer ? Details please
> ...
While Scanning a lenovo usb2.0 udisk， not 100 % reproduce
>>>
>>> Can you include Linux
>>>
>>> lsusb -vvv
>>>
>>> output for this device and include that information in the commit message ?
>>> (or the U-Boot info below, that works too, just please add it into the
>>> commit message, it is important for future reference).
>>>
>> OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit
>> message
>
> Thank you
>
This is log.
StarFive # usb reset
resetting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB
anyway.
Unexpected XHCI event TRB, skipping... (f77141f0 1300
02008401)
Unhandled exception: Load access fault
EPC: f7f563c6 RA: f7f563c6 TVAL: 000c
EPC: 4024a3c6 RA: 4024a3c6 reloc adjusted
>>>
>>> Where does the crash point to in code, can you disassemble the PC pointer ?
>>> (or maybe you can use scripts/decodecode I think)
>>>
>> OK， I will add EPC pointer disassemble to commit message
>
> This part probably doesn't need to be in the commit message. I'd like to know
> where the crash occurred in the code.
4024a376 :
{
4024a376: 7179addisp,sp,-48
4024a378: f406sd ra,40(sp)
4024a37a: f022sd s0,32(sp)
4024a37c: ec26sd s1,24(sp)
4024a37e: e84asd s2,16(sp)
4024a380: e44esd s3,8(sp)
4024a382: e052sd s4,0(sp)
4024a384: 89aemv s3,a1
4024a386: 84aamv s1,a0
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
4024a388: 8c4fe0efjal ra,4024844c
struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a38c: 6785lui a5,0x1
4024a38e: 94beadd s1,s1,a5
4024a390: 9444a603lw a2,-1724(s1)
4024a394: 00198713addia4,s3,1
4024a398: 0712sllia4,a4,0x4
4024a39a: 02061793sllia5,a2,0x20
4024a39e: 9381srlia5,a5,0x20
4024a3a0: 07c9addia5,a5,18
4024a3a2: 078esllia5,a5,0x3
4024a3a4: 97aaadd a5,a5,a0
4024a3a6: 679cld a5,8(a5)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
4024a3a8: 2981sext.w s3,s3
4024a3aa: 86cemv a3,s3
struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a3ac: 97baadd a5,a5,a4
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
4024a3ae: 4581li a1,0
4024a3b0: 473dli a4,15
struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring;
4024a3b2: 0087ba03ld s4,8(a5) # 1008
<_start-0x401feff8>
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
4024a3b6: 842amv s0,a0
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
4024a3b8: d75ff0efjal ra,4024a12c
event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
4024a3bc: 02000593li a1,32
4024a3c0: 8522mv a0,s0
4024a3c2: ebdff0efjal ra,4024a27e
field = le32_to_cpu(event->trans_event.flags);
epc-> 4024a3c6: 455clw a5,12(a0)
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
4024a3c8: 9444a703lw a4,-1724(s1)
field = le32_to_cpu(event->trans_event.flags);
4024a3cc: 0007891bsext.w s2,a5
Re: [PATCH v1] usb: xhci: Check return value of wait for TRB_TRANSFER event
On 10/18/23 05:46, Minda Chen wrote: On 2023/10/18 10:35, Marek Vasut wrote: On 10/18/23 03:22, Minda Chen wrote: On 2023/10/17 19:20, Marek Vasut wrote: On 10/17/23 08:20, Minda Chen wrote: xhci_wait_for_event() waiting TRB_TRANSFER event may return NULL. Checking the return value to avoid crash. Signed-off-by: Minda Chen How did you trigger this error ? Is there a reproducer ? Details please ... While Scanning a lenovo usb2.0 udisk， not 100 % reproduce Can you include Linux lsusb -vvv output for this device and include that information in the commit message ? (or the U-Boot info below, that works too, just please add it into the commit message, it is important for future reference). OK， I will add lsusb -vvv Linux udisk message and crash dump info to commit message Thank you This is log. StarFive # usb reset resetting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (f77141f0 1300 02008401) Unhandled exception: Load access fault EPC: f7f563c6 RA: f7f563c6 TVAL: 000c EPC: 4024a3c6 RA: 4024a3c6 reloc adjusted Where does the crash point to in code, can you disassemble the PC pointer ? (or maybe you can use scripts/decodecode I think) OK， I will add EPC pointer disassemble to commit message This part probably doesn't need to be in the commit message. I'd like to know where the crash occurred in the code.
