Re: [PATCH v2 1/3] starfive: pci: Add StarFive JH7110 pcie driver
On Monday 27 March 2023 09:03:46 Minda Chen wrote: > > > On 2023/3/25 20:31, Pali Rohár wrote: > > On Friday 24 March 2023 18:57:33 Minda Chen wrote: > >> On 2023/3/24 2:19, Pali Rohár wrote: > >> > On Thursday 23 March 2023 18:51:38 Minda Chen wrote: > >> >> On 2023/3/11 1:42, Pali Rohár wrote: > >> >> > On Friday 10 March 2023 18:36:44 Minda Chen wrote: > >> >> >> On 2023/3/8 15:31, Pali Rohár wrote: > >> >> >> > Hello! See few comments below. > >> >> >> > > >> >> >> > On Wednesday 08 March 2023 13:48:31 Minda Chen wrote: > >> >> >> >> From: Mason Huo > >> >> >> >> > >> >> >> >> Add pcie driver for StarFive JH7110, the driver depends on > >> >> >> >> starfive gpio, pinctrl, clk and reset driver to do init. > >> >> >> >> > >> >> >> >> Several devices are tested: > >> >> >> >> a) M.2 NVMe SSD > >> >> >> >> b) Realtek 8169 Ethernet adapter. > >> >> >> >> > >> >> >> >> Signed-off-by: Mason Huo > >> >> >> >> Signed-off-by: Minda Chen > >> >> >> >> --- > >> >> >> >> drivers/pci/Kconfig| 11 + > >> >> >> >> drivers/pci/Makefile | 1 + > >> >> >> >> drivers/pci/pcie_starfive_jh7110.c | 478 > >> >> >> >> + > >> >> >> >> 3 files changed, 490 insertions(+) > >> >> >> >> create mode 100644 drivers/pci/pcie_starfive_jh7110.c > >> >> >> >> > >> >> >> >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > >> >> >> >> index ef328d2652..e7b0ff5bc3 100644 > >> >> >> >> --- a/drivers/pci/Kconfig > >> >> >> >> +++ b/drivers/pci/Kconfig > >> >> >> >> @@ -374,4 +374,15 @@ config PCIE_UNIPHIER > >> >> >> >> Say Y here if you want to enable PCIe controller support on > >> >> >> >> UniPhier SoCs. > >> >> >> >> > >> >> >> >> +config PCIE_STARFIVE_JH7110 > >> >> >> >> + bool "Enable Starfive JH7110 PCIe driver" > >> >> >> >> + depends on STARFIVE_JH7110 > >> >> >> >> + depends on PINCTRL_STARFIVE_JH7110 > >> >> >> >> + depends on CLK_JH7110 > >> >> >> >> + depends on RESET_JH7110 > >> >> >> >> + default y > >> >> >> >> + help > >> >> >> >> + Say Y here if you want to enable PCIe controller support on > >> >> >> >> + StarFive JH7110 SoC. > >> >> >> >> + > >> >> >> >> endif > >> >> >> >> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile > >> >> >> >> index 49506e7ba5..bbe3323bb5 100644 > >> >> >> >> --- a/drivers/pci/Makefile > >> >> >> >> +++ b/drivers/pci/Makefile > >> >> >> >> @@ -49,3 +49,4 @@ obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o > >> >> >> >> obj-$(CONFIG_PCIE_OCTEON) += pcie_octeon.o > >> >> >> >> obj-$(CONFIG_PCIE_DW_SIFIVE) += pcie_dw_sifive.o > >> >> >> >> obj-$(CONFIG_PCIE_UNIPHIER) += pcie_uniphier.o > >> >> >> >> +obj-$(CONFIG_PCIE_STARFIVE_JH7110) += pcie_starfive_jh7110.o > >> >> >> >> diff --git a/drivers/pci/pcie_starfive_jh7110.c > >> >> >> >> b/drivers/pci/pcie_starfive_jh7110.c > >> >> >> >> new file mode 100644 > >> >> >> >> index 00..5ccef1ef02 > >> >> >> >> --- /dev/null > >> >> >> >> +++ b/drivers/pci/pcie_starfive_jh7110.c > >> >> >> >> @@ -0,0 +1,478 @@ > >> >> >> >> +// SPDX-License-Identifier: GPL-2.0+ > >> >> >> >> +/* > >> >> >> >> + * StarFive PLDA PCIe host controller driver > >> >> >> >> + * > >> >> >> >> + * Copyright (c) 2023 Starfive, Inc. > >> >> >> >> + * Author: Mason Huo > >> >> >> >> + * > >> >> >> >> + */ > >> >> >> >> + > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> +#include > >> >> >> >> + > >> >> >> >> +DECLARE_GLOBAL_DATA_PTR; > >> >> >> >> + > >> >> >> >> +#define GEN_SETTINGS 0x80 > >> >> >> >> +#define PCIE_PCI_IDS 0x9C > >> >> >> >> +#define PCIE_WINROM 0xFC > >> >> >> >> +#define PMSG_SUPPORT_RX 0x3F0 > >> >> >> >> +#define PCI_MISC 0xB4 > >> >> >> >> + > >> >> >> >> +#define PLDA_EP_ENABLE 0 > >> >> >> >> +#define PLDA_RP_ENABLE 1 > >> >> >> >> + > >> >> >> >> +#define IDS_REVISION_ID 0x02 > >> >> >> >> +#define IDS_PCI_TO_PCI_BRIDGE0x060400 > >> >> >> >> +#define IDS_CLASS_CODE_SHIFT 8 > >> >> >> > > >> >> >> > Please do not duplicate standard PCI macros and constants. In > >> >> >> > U-Boot > >> >> >> > they are already available in include/pci_ids.h header file. > >> >> >> > > >> >> >> ok > >> >> >> >> +#define PREF_MEM_WIN_64_SUPPORT BIT(3) > >> >> >> >> +#define PMSG_LTR_SUPPORT BIT(2) > >> >> >> >> +#define PLDA_FUNCTION_DISBIT(15) > >> >> >> >> +#define PLDA_FUNC_NUM4 > >> >> >> >> +#define PLDA_PHY_FUNC_SHIFT 9 > >> >> >> >> + > >> >> >> >> +#define
Re: [PATCH 4/7] arch: snapdragon: clock: Always bind before relocation
On Fri, 24 Mar 2023 at 20:54, Tom Rini wrote:
>
> On Fri, Mar 24, 2023 at 11:36:24AM +0530, Sumit Garg wrote:
> > On Fri, 24 Mar 2023 at 07:27, Konrad Dybcio
> > wrote:
> > >
> > > In preparation for supporting upstream Linux device trees on Qualcomm
> > > platforms, make this the default behavior.
> > >
> > > Signed-off-by: Konrad Dybcio
> > > ---
> > >
> > > arch/arm/mach-snapdragon/clock-snapdragon.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/mach-snapdragon/clock-snapdragon.c
> > > b/arch/arm/mach-snapdragon/clock-snapdragon.c
> > > index 0ac45dce9a92..d1af5d1fec7d 100644
> > > --- a/arch/arm/mach-snapdragon/clock-snapdragon.c
> > > +++ b/arch/arm/mach-snapdragon/clock-snapdragon.c
> > > @@ -178,4 +178,5 @@ U_BOOT_DRIVER(clk_msm) = {
> > > .ops= _clk_ops,
> > > .priv_auto = sizeof(struct msm_clk_priv),
> > > .probe = msm_clk_probe,
> > > + .flags = DM_FLAG_PRE_RELOC,
> >
> > "u-boot,dm-pre-reloc" serves the same purpose but this looks even
> > better as we would like the serial driver to be enabled by default
> > prior to relocation. So you need to get rid of redundant
> > "u-boot,dm-pre-reloc" from corresponding -uboot.dtsi files.
>
> And in turn u-boot,dm-* are now bootph-* flags which can (should!) be
> part of the upstream dts file.
>
That's good to know. Can you share a reference to the patch set adding
support for bootph-* flags?
-Sumit
> --
> Tom
[PATCH] spi: f-ospi: Add missing spi_mem_default_supports_op() helper
The .supports_op() callback function returns true by default after
performing driver-specific checks. Therefore the driver cannot apply
the buswidth in devicetree.
Call spi_mem_default_supports_op() helper to handle the buswidth
in devicetree.
Fixes: 358f803ae21c ("spi: Add Socionext F_OSPI SPI flash controller driver")
Signed-off-by: Kunihiko Hayashi
---
drivers/spi/spi-sn-f-ospi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-sn-f-ospi.c b/drivers/spi/spi-sn-f-ospi.c
index ebf2903d3e..e3633a5260 100644
--- a/drivers/spi/spi-sn-f-ospi.c
+++ b/drivers/spi/spi-sn-f-ospi.c
@@ -556,7 +556,7 @@ static bool f_ospi_supports_op(struct spi_slave *slave,
if (!f_ospi_supports_op_width(op))
return false;
- return true;
+ return spi_mem_default_supports_op(slave, op);
}
static int f_ospi_adjust_op_size(struct spi_slave *slave, struct spi_mem_op
*op)
--
2.25.1
Re: [PATCH 2/2] efi_loader: fix device-path for USB devices
On 3/27/23 06:00, Simon Glass wrote:
Hi Heinrich,
On Wed, 22 Mar 2023 at 02:21, Heinrich Schuchardt
wrote:
On 3/20/23 19:39, Simon Glass wrote:
Hi Heinrich,
On Mon, 20 Mar 2023 at 09:58, Heinrich Schuchardt
wrote:
On 3/19/23 20:29, Simon Glass wrote:
Hi Heinrich,
On Mon, 20 Mar 2023 at 04:25, Heinrich Schuchardt
wrote:
EFI device paths for block devices must be unique. If a non-unique device
path is discovered, probing of the block device fails.
Currently we use UsbClass() device path nodes. As multiple devices may
have the same vendor and product id these are non-unique. Instead we
should use Usb() device path nodes. They include the USB port on the
parent hub. Hence they are unique.
A USB storage device may contain multiple logical units. These can be
modeled as Ctrl() nodes.
Reported-by: Patrick Delaunay
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 45 +++-
1 file changed, 33 insertions(+), 12 deletions(-)
Reviewed-by: Simon Glass
[..]
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 3b267b713e..b6dd575b13 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -147,7 +147,7 @@ struct efi_device_path *efi_dp_shorten(struct
efi_device_path *dp)
* in practice fallback.efi just uses MEDIA:HARD_DRIVE
* so not sure when we would see these other cases.
*/
- if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB_CLASS) ||
+ if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) ||
EFI_DP_TYPE(dp, MEDIA_DEVICE, HARD_DRIVE_PATH) ||
EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH))
return dp;
@@ -564,6 +564,11 @@ __maybe_unused static unsigned int dp_size(struct udevice
*dev)
return dp_size(dev->parent)
+ sizeof(struct efi_device_path_vendor) + 1;
#endif
+#ifdef CONFIG_USB
+ case UCLASS_MASS_STORAGE:
Can we do:
case UCLASS_MASS_STORAGE:
if (IS_ENABLED(CONFIG_USB)) {
...
}
?
That should be possible too. Didn't you want to get rid of IS_ENABLED()?
CONFIG_IS_ENABLED() would work here too.
I was wanting to get rid of CONFIG_IS_ENABLED() for things that don't
have an SPL Kconfig, then eventually get rid of CONFIG_IS_ENABLED().
I've got a bit lost in all the problems though.
The whole way that we create device paths is not consistent. We should
have a device path node for each DM device.
With v2023.07 I want to add
struct efi_device_path *(*get_dp_node)(struct udevice *dev);
to struct uclass_driver and move the generation of device path nodes to
the individual uclass drivers.
We could also send an event (EVT_EFI_GET_DP_NODE) and connect it that
way...ie would add less space to driver model. But yes it would be
good to line up EFI and DM a bit better.
The type of device-path node to be created is uclass specific:
For an NVMe device we will always create a NVMe() node.
For a block device we will always create a Ctrl() node with the LUN number.
...
For drivers that don't implement the method yet we can create a VenHw()
node per default with uclass-id and device number encoded in the node.
You suggested yourself that the DM and the EFI implementation should be
tightly integrated.
I mean that EFI should make full use of DM rather than maintaining
parallel structures that need manual updating.
I cannot see what the use of an event should be. Why should each udevice
register to an event when all we need is a simple function like:
#if CONFIG_IS_ENABLED(EFI_LOADER)
struct efi_device_path *uclass_get_dp_node(struct udevice *dev)
{
struct uclass *uc;
struct efi_device_path_uboot *dp;
uc = dev->uclass;
if (uc->uc_drv->get_dp_node)
return uc->uc_drv->get_dp_node(dev);
dp = efi_alloc(sizeof(struct efi_device_path_uboot));
if (!dp)
return NULL;
dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
dp->dp.length = sizeof(struct efi_device_path_uboot);
dp->guid = efi_u_boot_guid;
dp->uclass_id = uc->uc_drv->id;
dp->seq_ = dev->seq_;
return >dp;
}
#endif
I'll take a look at your series. Basically the idea with an event is
that it can tell EFI when action is needed, without requiring #ifdefs
and the like to build it into DM itself.
The trigger is not on the DM side but on the EFI side. EFI is asking DM
for a device-path node for a device of a specific uclass.
So DM would have to register a listener per uclass if we use events.
Best regards
Heinrich
Re: DM SPI flash improvements
Hi Simon, On Sun, Mar 26, 2023 at 9:01 PM Simon Glass wrote: > > Hi Tony, > > On Mon, 27 Mar 2023 at 12:28, Tony Dinh wrote: > > > > Hi Simon, > > > > I'm investigating a problem with the Thecus N2350 board that has SPI > > flash on controller 1, but not on controller 0. Booting with SPI SPL > > is not possible with CONFIG_SF_DEFAULT_BUS=1. > > > > Reference: > > https://lists.denx.de/pipermail/u-boot/2023-March/511517.html > > > > That led me to the drivers/mtd/spi/sf-uclass.c and drivers/spi/spi-uclass.c. > > > > And I found there are some problems in the spi_flash_probe(), as well > > as _spi_get_bus_and_cs(). But seeing your comment in the > > spi_flash_probe function header, I'm thinking perhaps I should not try > > to fix them. > > > > /* > > * TODO(s...@chromium.org): This is an old-style function. We should remove > > * it when all SPI flash drivers use dm > > */ > > struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs, > > unsigned int max_hz, unsigned int > > spi_mode) > > > > Could you or Jagan clarify the TODO above meaning? Are we fully in DM > > SPI yet? If we are, should this be replaced with other means to probe > > the SPI bus? Or it should have been automatically probed by DM SPI > > infrastructure, and we just need to tag the SPI 1 DTS node with > > boot-phase? If that's the case then perhaps this function should be > > defined out with some configs wrapping. > > Ideally you would obtain the SPI-flash device using > spi_flash_std_probe(). The SPI buses can be added to the device tree > with 'spi0' and 'spi1' aliases. Then you can add a child noe of spi1 > with your flash chip. Thanks! What you said about spi_flash_std_probe() has confirmed what I've been reading and thinking too. > > There is definitely some work needed to remove the old code. We don't > have a proper way to select the boot device yet, Probably what is > needed ultimately is something like the u-boot.spl-device-order used > by Rockchip boards. We should really get away from using SPI-bus > numbers. Yes, indeed. Using SPI-bus numbers is problematic in this scenario. Thanks, Tony > > > > > My current SPI configs: > > > > CONFIG_SPL_DM_SPI=y > > CONFIG_SPL_DM_SPI_FLASH=y > > # CONFIG_DM_HWSPINLOCK is not set > > CONFIG_DM_SPI_FLASH=y > > CONFIG_DM_SPI=y > > CONFIG_SF_DEFAULT_SPEED=5000 > > CONFIG_SF_DEFAULT_MODE=0x0 > > # CONFIG_CMD_SF_TEST is not set > > CONFIG_SF_DEFAULT_BUS=1 > > CONFIG_SF_DEFAULT_CS=0 > > > > Thanks, > > Tony > > Regards, > Simon
[PATCH v3 16/16] x86: Allow locating UARTs by device ID
When coreboot does not pass a UART in its sysinfo struct, there is no
easy way to find it out. Add a way to specify known UARTs so we can
find them without needing help from coreboot.
Since coreboot does not actually init the serial device when serial is
disabled, it is not possible to make it add this information to the
sysinfo table.
Also, we cannot use the class information, since we don't know which
UART is being used. For example, with Alder Lake there are two:
00.16.00 0x8086 0x51e0 Simple comm. controller 0x80
00.1e.00 0x8086 0x51a8 Simple comm. controller 0x80
In our case the second one is the right one, but thre is no way to
distinguish it from the first one without using the device ID.
If we have Adler Lake hardware which uses a different UART, we could
perhaps look at the ACPI tables, or the machine information passed in
the SMBIOS tables.
This was discussed previously before: [1]
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20210407163159.3.I967ea8c85e009f870c7aa944372d32c990f1b14a@changeid/
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Move this patch to last in the series, so it can be dropped if needed
arch/x86/dts/coreboot.dts| 4
drivers/serial/serial_coreboot.c | 41
include/pci_ids.h| 3 +++
3 files changed, 48 insertions(+)
diff --git a/arch/x86/dts/coreboot.dts b/arch/x86/dts/coreboot.dts
index f9ff5346a79b..1abd3fddd15c 100644
--- a/arch/x86/dts/coreboot.dts
+++ b/arch/x86/dts/coreboot.dts
@@ -14,6 +14,8 @@
/include/ "rtc.dtsi"
#include "tsc_timer.dtsi"
+#include
+#include
/ {
model = "coreboot x86 payload";
@@ -34,6 +36,8 @@
pci {
compatible = "pci-x86";
bootph-all;
+ u-boot,pci-pre-reloc = <
+ PCI_VENDEV(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_ADP_P_UART0) >;
};
serial: serial {
diff --git a/drivers/serial/serial_coreboot.c b/drivers/serial/serial_coreboot.c
index 23066e4d0543..bb3a5362dfaf 100644
--- a/drivers/serial/serial_coreboot.c
+++ b/drivers/serial/serial_coreboot.c
@@ -17,6 +17,12 @@
DECLARE_GLOBAL_DATA_PTR;
+static const struct pci_device_id ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_APL_UART2) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ADP_P_UART0) },
+ {},
+};
+
static int read_dbg2(struct ns16550_plat *plat)
{
struct acpi_table_header *tab;
@@ -94,6 +100,39 @@ static int read_dbg2(struct ns16550_plat *plat)
return 0;
}
+/*
+ * Coreboot only sets up the UART if it uses it and doesn't bother to put the
+ * details in sysinfo if it doesn't. Try to guess in that case, using devices
+ * we know about
+ *
+ * @plat: Platform data to fill in
+ * @return 0 if found, -ve if no UART was found
+ */
+static int guess_uart(struct ns16550_plat *plat)
+{
+ struct udevice *bus, *dev;
+ ulong addr;
+ int index;
+ int ret;
+
+ ret = uclass_first_device_err(UCLASS_PCI, );
+ if (ret)
+ return ret;
+ index = 0;
+ ret = pci_bus_find_devices(bus, ids, , );
+ if (ret)
+ return ret;
+ addr = dm_pci_read_bar32(dev, 0);
+ plat->base = addr;
+ plat->reg_shift = 2;
+ plat->reg_width = 4;
+ plat->clock = 1843200;
+ plat->fcr = UART_FCR_DEFVAL;
+ plat->flags = 0;
+
+ return 0;
+}
+
static int coreboot_of_to_plat(struct udevice *dev)
{
struct ns16550_plat *plat = dev_get_plat(dev);
@@ -113,6 +152,8 @@ static int coreboot_of_to_plat(struct udevice *dev)
} else if (IS_ENABLED(CONFIG_COREBOOT_SERIAL_FROM_DBG2)) {
ret = read_dbg2(plat);
}
+ if (ret && CONFIG_IS_ENABLED(PCI))
+ ret = guess_uart(plat);
if (ret) {
/*
diff --git a/include/pci_ids.h b/include/pci_ids.h
index 88b0a6404585..5ae1b9b7fb6e 100644
--- a/include/pci_ids.h
+++ b/include/pci_ids.h
@@ -2992,6 +2992,9 @@
#define PCI_DEVICE_ID_INTEL_UNC_R3QPI1 0x3c45
#define PCI_DEVICE_ID_INTEL_JAKETOWN_UBOX 0x3ce0
#define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
+#define PCI_DEVICE_ID_INTEL_ADP_P_UART00x51a8
+#define PCI_DEVICE_ID_INTEL_ADP_P_UART10x51a9
+#define PCI_DEVICE_ID_INTEL_APL_UART2 0x5ac0
#define PCI_DEVICE_ID_INTEL_5100_160x65f0
#define PCI_DEVICE_ID_INTEL_5100_190x65f3
#define PCI_DEVICE_ID_INTEL_5100_210x65f5
--
2.40.0.348.gf938b09366-goog
[PATCH v3 15/16] coreboot: Enable ms command
This is useful when looking for tables in memory. Enable it for coreboot. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Add new patch to enable ms command configs/coreboot_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 8bb744e6e84d..cf0c9590e98d 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -24,6 +24,7 @@ CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=532 +CONFIG_CMD_MEM_SEARCH=y CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y -- 2.40.0.348.gf938b09366-goog
[PATCH v3 14/16] x86: nvme: coreboot: Enable NVMe
Enable support for NVMe storage devices. Update the driver to enable the
bus master bit, since coreboot does not do that automatically.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere
- Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed)
configs/coreboot_defconfig | 3 +++
drivers/nvme/nvme_pci.c| 8
2 files changed, 11 insertions(+)
diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
index 3030e5bf93b4..8bb744e6e84d 100644
--- a/configs/coreboot_defconfig
+++ b/configs/coreboot_defconfig
@@ -59,6 +59,9 @@ CONFIG_SYS_ATA_ALT_OFFSET=0
CONFIG_ATAPI=y
CONFIG_LBA48=y
CONFIG_SYS_64BIT_LBA=y
+CONFIG_MISC=y
+CONFIG_NVMEM=y
+CONFIG_NVME_PCI=y
# CONFIG_PCI_PNP is not set
CONFIG_SOUND=y
CONFIG_SOUND_I8254=y
diff --git a/drivers/nvme/nvme_pci.c b/drivers/nvme/nvme_pci.c
index 36bf9c5ffb73..dff19317943c 100644
--- a/drivers/nvme/nvme_pci.c
+++ b/drivers/nvme/nvme_pci.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include "nvme.h"
@@ -30,6 +31,13 @@ static int nvme_probe(struct udevice *udev)
ndev->instance = trailing_strtol(udev->name);
ndev->bar = dm_pci_map_bar(udev, PCI_BASE_ADDRESS_0, 0, 0,
PCI_REGION_TYPE, PCI_REGION_MEM);
+
+ if (!ll_boot_init()) {
+ /* Turn on bus-mastering */
+ dm_pci_clrset_config16(udev, PCI_COMMAND, 0,
+ PCI_COMMAND_MASTER);
+ }
+
return nvme_init(udev);
}
--
2.40.0.348.gf938b09366-goog
[PATCH v3 12/16] x86: coreboot: Log function names and line numbers
Turn these options on to make it easier to debug things. Also enable dhrystone so we can get some measure of performance. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) configs/coreboot_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 1bbb358a0220..3030e5bf93b4 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -16,6 +16,9 @@ CONFIG_USE_BOOTCOMMAND=y CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_LOG=y +CONFIG_LOGF_LINE=y +CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y @@ -60,5 +63,6 @@ CONFIG_SYS_64BIT_LBA=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 +CONFIG_CMD_DHRYSTONE=y # CONFIG_GZIP is not set CONFIG_SMBIOS_PARSER=y -- 2.40.0.348.gf938b09366-goog
[PATCH v3 13/16] x86: coreboot: Show unimplemented sysinfo tags
Sometimes coreboot adds new tags that U-Boot does not know about. These
are silently ignored, but it is useful to at least know what we are
missing.
Add a way to collect this information. For Brya it shows:
Unimpl. 38 41 37 34 42 40
These are:
LB_TAG_PLATFORM_BLOB_VERSION
LB_TAG_ACPI_CNVS
LB_TAG_FMAP
LB_TAG_VBOOT_WORKBUF
LB_TAG_TYPE_C_INFO
LB_TAG_BOARD_CONFIG
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
(no changes since v1)
arch/x86/include/asm/cb_sysinfo.h | 6 ++
arch/x86/lib/coreboot/cb_sysinfo.c | 2 ++
cmd/x86/cbsysinfo.c| 8
3 files changed, 16 insertions(+)
diff --git a/arch/x86/include/asm/cb_sysinfo.h
b/arch/x86/include/asm/cb_sysinfo.h
index 6b266149cf65..2c78b22d0d22 100644
--- a/arch/x86/include/asm/cb_sysinfo.h
+++ b/arch/x86/include/asm/cb_sysinfo.h
@@ -16,6 +16,8 @@
#define SYSINFO_MAX_GPIOS 8
/* Up to 10 MAC addresses */
#define SYSINFO_MAX_MACS 10
+/* Track the first 32 unimplemented tags */
+#define SYSINFO_MAX_UNIMPL 32
/**
* struct sysinfo_t - Information passed to U-Boot from coreboot
@@ -134,6 +136,8 @@
* @chromeos_vpd: Chromium OS Vital Product Data region, typically NULL,
meaning
* not used
* @rsdp: Pointer to ACPI RSDP table
+ * @unimpl_count: Number of entries in unimpl_map[]
+ * @unimpl: List of unimplemented IDs (bottom 8 bits only)
*/
struct sysinfo_t {
unsigned int cpu_khz;
@@ -213,6 +217,8 @@ struct sysinfo_t {
u32 mtc_size;
void*chromeos_vpd;
void *rsdp;
+ u32 unimpl_count;
+ u8 unimpl[SYSINFO_MAX_UNIMPL];
};
extern struct sysinfo_t lib_sysinfo;
diff --git a/arch/x86/lib/coreboot/cb_sysinfo.c
b/arch/x86/lib/coreboot/cb_sysinfo.c
index a11a2587f66b..42cc3a128d93 100644
--- a/arch/x86/lib/coreboot/cb_sysinfo.c
+++ b/arch/x86/lib/coreboot/cb_sysinfo.c
@@ -439,6 +439,8 @@ static int cb_parse_header(void *addr, int len, struct
sysinfo_t *info)
cb_parse_acpi_rsdp(rec, info);
break;
default:
+ if (info->unimpl_count < SYSINFO_MAX_UNIMPL)
+ info->unimpl[info->unimpl_count++] = rec->tag;
cb_parse_unhandled(rec->tag, ptr);
break;
}
diff --git a/cmd/x86/cbsysinfo.c b/cmd/x86/cbsysinfo.c
index 07570b00c9a0..2b8d3b0a4356 100644
--- a/cmd/x86/cbsysinfo.c
+++ b/cmd/x86/cbsysinfo.c
@@ -364,6 +364,14 @@ static void show_table(struct sysinfo_t *info, bool
verbose)
print_ptr("Chrome OS VPD", info->chromeos_vpd);
print_ptr("RSDP", info->rsdp);
+ printf("%-12s: ", "Unimpl.");
+ if (info->unimpl_count) {
+ for (i = 0; i < info->unimpl_count; i++)
+ printf("%02x ", info->unimpl[i]);
+ printf("\n");
+ } else {
+ printf("(none)\n");
+ }
}
static int do_cbsysinfo(struct cmd_tbl *cmdtp, int flag, int argc,
--
2.40.0.348.gf938b09366-goog
[PATCH v3 11/16] x86: coreboot: Scan PCI after relocation
Enable this so that PCI devices can be used correctly without needing to do a manual scan. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) configs/coreboot_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index fb4d1751108f..1bbb358a0220 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -18,6 +18,7 @@ CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y +CONFIG_PCI_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y -- 2.40.0.348.gf938b09366-goog
[PATCH v3 10/16] x86: coreboot: Document how to enable the debug UART
This is not obvious so add a little note about how it works. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- (no changes since v1) doc/board/coreboot/coreboot.rst | 29 + 1 file changed, 29 insertions(+) diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 4a5f101cad2e..0fe95af56d2d 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -71,3 +71,32 @@ Memory map (typically redirects to 7ab10030 or similar) 500 Location of coreboot sysinfo table, used during startup == == + + +Debug UART +-- + +It is possible to enable the debug UART with coreboot. To do this, use the +info from the cbsysinfo command to locate the UART base. For example:: + + => cbsysinfo + ... + Serial I/O port: + base: + pointer : 767b51bc + type: 2 + base: fe03e000 + baud: 0d115200 + regwidth: 4 + input_hz: 0d1843200 + PCI addr: 0010 + ... + +Here you can see that the UART base is fe03e000, regwidth is 4 (1 << 2) and the +input clock is 1843200. So you can add the following CONFIG options:: + + CONFIG_DEBUG_UART=y + CONFIG_DEBUG_UART_BASE=fe03e000 + CONFIG_DEBUG_UART_CLOCK=1843200 + CONFIG_DEBUG_UART_SHIFT=2 + CONFIG_DEBUG_UART_ANNOUNCE=y -- 2.40.0.348.gf938b09366-goog
[PATCH v3 09/16] x86: coreboot: Use a memory-mapped UART
This is much more common on modern hardware, so default to using it. This does not affect the normal UART, but does allow the debug UART to work, since it uses serial_out_shift(), etc. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Expand commit message to explain this is for the debug UART - Update the defconfig instead configs/coreboot64_defconfig | 1 - configs/coreboot_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index ec672e59e898..60a1924e9e53 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -62,7 +62,6 @@ CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y # CONFIG_PCI_PNP is not set -CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 4db728991692..fb4d1751108f 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -56,7 +56,6 @@ CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y # CONFIG_PCI_PNP is not set -CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 -- 2.40.0.348.gf938b09366-goog
[PATCH v3 07/16] x86: Allow locating the UART from ACPI tables
When coreboot does not pass a UART in its sysinfo struct, there is no
easy way to find it out.
Since coreboot does not actually init the serial device when serial is
disabled, it is not possible to make it add this information to the
sysinfo table.
Add a way to obtain this information from the DBG2 ACPI table, which is
normally set up by coreboot.
For now this only supports a memory-mapped 16550-style UART.
Signed-off-by: Simon Glass
---
Changes in v3:
- Disable for coreboot64 since ACPI is not available
Changes in v2:
- Add new patch to allow locating the UART from ACPI tables
drivers/serial/Kconfig | 10 +++
drivers/serial/serial_coreboot.c | 114 ---
2 files changed, 116 insertions(+), 8 deletions(-)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 10d07daf2777..08f6559c1579 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -669,6 +669,16 @@ config COREBOOT_SERIAL
a serial console on any platform without needing to change the
device tree, etc.
+config COREBOOT_SERIAL_FROM_DBG2
+ bool "Obtain UART from ACPI tables"
+ depends on COREBOOT_SERIAL
+ default y if !SPL
+ help
+ Select this to try to find a DBG2 record in the ACPI tables, in the
+ event that coreboot does not provide information about the UART in the
+ normal sysinfo tables. This provides a useful fallback when serial
+ is not enabled in coreboot.
+
config CORTINA_UART
bool "Cortina UART support"
depends on DM_SERIAL
diff --git a/drivers/serial/serial_coreboot.c b/drivers/serial/serial_coreboot.c
index de09c8681f5c..23066e4d0543 100644
--- a/drivers/serial/serial_coreboot.c
+++ b/drivers/serial/serial_coreboot.c
@@ -5,25 +5,123 @@
* Copyright 2019 Google LLC
*/
+#define LOG_CATGEGORY UCLASS_SERIAL
+
#include
#include
+#include
#include
#include
+#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
+static int read_dbg2(struct ns16550_plat *plat)
+{
+ struct acpi_table_header *tab;
+ struct acpi_dbg2_header *hdr;
+ struct acpi_dbg2_device *dbg;
+ struct acpi_gen_regaddr *addr;
+ u32 *addr_size;
+
+ log_debug("Looking for DBG2 in ACPI tables\n");
+ if (!gd->acpi_start) {
+ log_debug("No ACPI tables\n");
+ return -ENOENT;
+ }
+
+ tab = acpi_find_table("DBG2");
+ if (!tab) {
+ log_debug("No DBG2 table\n");
+ return -ENOENT;
+ }
+ hdr = container_of(tab, struct acpi_dbg2_header, header);
+
+ /* We only use the first device, but check that there is at least one */
+ if (!hdr->devices_count) {
+ log_debug("No devices\n");
+ return -ENOENT;
+ }
+ if (hdr->devices_offset >= tab->length) {
+ log_debug("Invalid offset\n");
+ return -EINVAL;
+ }
+ dbg = (void *)hdr + hdr->devices_offset;
+ if (dbg->revision) {
+ log_debug("Invalid revision %d\n", dbg->revision);
+ return -EINVAL;
+ }
+ if (!dbg->address_count) {
+ log_debug("No addresses\n");
+ return -EINVAL;
+ }
+ if (dbg->port_type != ACPI_DBG2_SERIAL_PORT) {
+ log_debug("Not a serial port\n");
+ return -EPROTOTYPE;
+ }
+ if (dbg->port_subtype != ACPI_DBG2_16550_COMPATIBLE) {
+ log_debug("Incompatible serial port\n");
+ return -EPROTOTYPE;
+ }
+ if (dbg->base_address_offset >= dbg->length ||
+ dbg->address_size_offset >= dbg->length) {
+ log_debug("Invalid base address/size offsets %d, %d\n",
+ dbg->base_address_offset, dbg->address_size_offset);
+ return -EINVAL;
+ }
+ addr_size = (void *)dbg + dbg->address_size_offset;
+ if (!*addr_size) {
+ log_debug("Zero address size\n");
+ return -EINVAL;
+ }
+ addr = (void *)dbg + dbg->base_address_offset;
+ if (addr->space_id != ACPI_ADDRESS_SPACE_MEMORY) {
+ log_debug("Incompatible space %d\n", addr->space_id);
+ return -EPROTOTYPE;
+ }
+
+ plat->base = addr->addrl;
+
+ /* ACPI_ACCESS_SIZE_DWORD_ACCESS is 3; we want 2 */
+ plat->reg_shift = addr->access_size - 1;
+ plat->reg_width = 4; /* coreboot sets bit_width to 0 */
+ plat->clock = 1843200;
+ plat->fcr = UART_FCR_DEFVAL;
+ plat->flags = 0;
+ log_debug("Collected UART from ACPI DBG2 table\n");
+
+ return 0;
+}
+
static int coreboot_of_to_plat(struct udevice *dev)
{
struct ns16550_plat *plat = dev_get_plat(dev);
struct cb_serial *cb_info = lib_sysinfo.serial;
+ int ret = -ENOENT;
- plat->base = cb_info->baseaddr;
- plat->reg_shift = cb_info->regwidth == 4 ? 2 : 0;
- plat->reg_width =
[PATCH v3 08/16] pci: coreboot: Don't read regions when booting
When U-Boot is the second-stage bootloader, PCI is already set up. We
cannot read the regions from the device tree. There is no point anyway,
since PCI devices have already been allocated according to the regions
and it is not safe for U-Boot to make any changes.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
(no changes since v1)
drivers/pci/pci-uclass.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 9343cfc62a96..8d27e40338cf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -973,6 +973,10 @@ static int decode_regions(struct pci_controller *hose,
ofnode parent_node,
int len;
int i;
+ /* handle booting from coreboot, etc. */
+ if (!ll_boot_init())
+ return 0;
+
prop = ofnode_get_property(node, "ranges", );
if (!prop) {
debug("%s: Cannot decode regions\n", __func__);
--
2.40.0.348.gf938b09366-goog
[PATCH v3 06/16] x86: coreboot: Collect the address of the ACPI tables
At present any ACPI tables created by prior-stage firmware are ignored.
It is useful to be able to view these in U-Boot.
Pick this up from the sysinfo tables and display it with the cbsysinfo
command. This allows the 'acpi list' command to work when booting from
coreboot.
Adjust the global_data condition so that acpi_start is available even if
table-generation is disabled.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Use tab instead of space in header file
- Refactor two patches into one
arch/x86/include/asm/cb_sysinfo.h | 2 ++
arch/x86/include/asm/coreboot_tables.h | 2 ++
arch/x86/lib/coreboot/cb_sysinfo.c | 11 +++
cmd/x86/cbsysinfo.c| 1 +
include/asm-generic/global_data.h | 4 ++--
5 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/cb_sysinfo.h
b/arch/x86/include/asm/cb_sysinfo.h
index 0201ac6b03a9..6b266149cf65 100644
--- a/arch/x86/include/asm/cb_sysinfo.h
+++ b/arch/x86/include/asm/cb_sysinfo.h
@@ -133,6 +133,7 @@
* @mtc_size: Size of MTC region
* @chromeos_vpd: Chromium OS Vital Product Data region, typically NULL,
meaning
* not used
+ * @rsdp: Pointer to ACPI RSDP table
*/
struct sysinfo_t {
unsigned int cpu_khz;
@@ -211,6 +212,7 @@ struct sysinfo_t {
u64 mtc_start;
u32 mtc_size;
void*chromeos_vpd;
+ void *rsdp;
};
extern struct sysinfo_t lib_sysinfo;
diff --git a/arch/x86/include/asm/coreboot_tables.h
b/arch/x86/include/asm/coreboot_tables.h
index f131de56a405..4de137fbab9d 100644
--- a/arch/x86/include/asm/coreboot_tables.h
+++ b/arch/x86/include/asm/coreboot_tables.h
@@ -422,6 +422,8 @@ struct cb_tsc_info {
#define CB_TAG_SERIALNO0x002a
#define CB_MAX_SERIALNO_LENGTH 32
+#define CB_TAG_ACPI_RSDP 0x0043
+
#define CB_TAG_CMOS_OPTION_TABLE 0x00c8
struct cb_cmos_option_table {
diff --git a/arch/x86/lib/coreboot/cb_sysinfo.c
b/arch/x86/lib/coreboot/cb_sysinfo.c
index 748fa4ee53bb..a11a2587f66b 100644
--- a/arch/x86/lib/coreboot/cb_sysinfo.c
+++ b/arch/x86/lib/coreboot/cb_sysinfo.c
@@ -264,6 +264,13 @@ static void cb_parse_mrc_cache(void *ptr, struct sysinfo_t
*info)
info->mrc_cache = map_sysmem(cbmem->cbmem_tab, 0);
}
+static void cb_parse_acpi_rsdp(void *ptr, struct sysinfo_t *info)
+{
+ struct cb_cbmem_tab *const cbmem = (struct cb_cbmem_tab *)ptr;
+
+ info->rsdp = map_sysmem(cbmem->cbmem_tab, 0);
+}
+
__weak void cb_parse_unhandled(u32 tag, unsigned char *ptr)
{
}
@@ -428,6 +435,9 @@ static int cb_parse_header(void *addr, int len, struct
sysinfo_t *info)
case CB_TAG_MRC_CACHE:
cb_parse_mrc_cache(rec, info);
break;
+ case CB_TAG_ACPI_RSDP:
+ cb_parse_acpi_rsdp(rec, info);
+ break;
default:
cb_parse_unhandled(rec->tag, ptr);
break;
@@ -454,6 +464,7 @@ int get_coreboot_info(struct sysinfo_t *info)
if (!ret)
return -ENOENT;
gd->arch.coreboot_table = addr;
+ gd_set_acpi_start(map_to_sysmem(info->rsdp));
gd->flags |= GD_FLG_SKIP_LL_INIT;
return 0;
diff --git a/cmd/x86/cbsysinfo.c b/cmd/x86/cbsysinfo.c
index 34fdaf5b1b1c..07570b00c9a0 100644
--- a/cmd/x86/cbsysinfo.c
+++ b/cmd/x86/cbsysinfo.c
@@ -363,6 +363,7 @@ static void show_table(struct sysinfo_t *info, bool verbose)
print_hex("MTC size", info->mtc_size);
print_ptr("Chrome OS VPD", info->chromeos_vpd);
+ print_ptr("RSDP", info->rsdp);
}
static int do_cbsysinfo(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 987fb66c17a3..422e0cf4720f 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -457,7 +457,7 @@ struct global_data {
*/
fdt_addr_t translation_offset;
#endif
-#ifdef CONFIG_GENERATE_ACPI_TABLE
+#ifdef CONFIG_ACPI
/**
* @acpi_ctx: ACPI context pointer
*/
@@ -536,7 +536,7 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
#define gd_dm_priv_base() NULL
#endif
-#ifdef CONFIG_GENERATE_ACPI_TABLE
+#ifdef CONFIG_ACPI
#define gd_acpi_ctx() gd->acpi_ctx
#define gd_acpi_start()gd->acpi_start
#define gd_set_acpi_start(addr)gd->acpi_start = addr
--
2.40.0.348.gf938b09366-goog
[PATCH v3 04/16] acpi: Create a new Kconfig for ACPI
We have several Kconfig options for ACPI, but all relate to specific
functions, such as generating tables and AML code.
Add a new option which controls including basic ACPI library code,
including the lib/acpi directory. This will allow us to add functions
which are available even if table generation is not supported.
Adjust the command to avoid a build error when ACPIGEN is not enabled.
Signed-off-by: Simon Glass
---
Changes in v3:
- Don't enable ACPI by default except on x86 and sandbox
Changes in v2:
- Add new patch to create a new Kconfig for ACPI
arch/Kconfig | 2 ++
cmd/Kconfig | 2 +-
cmd/acpi.c | 4
drivers/core/Kconfig | 1 +
lib/Kconfig | 10 +-
lib/Makefile | 2 +-
lib/acpi/Makefile| 4
7 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index d30676ae817b..e4831aeaa075 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -194,6 +194,7 @@ config SANDBOX
imply PHYLIB
imply DM_MDIO
imply DM_MDIO_MUX
+ imply ACPI
imply ACPI_PMC
imply ACPI_PMC_SANDBOX
imply CMD_PMC
@@ -260,6 +261,7 @@ config X86
imply PCH
imply PHYSMEM
imply RTC_MC146818
+ imply ACPI
imply ACPIGEN if !QEMU && !EFI_APP
imply SYSINFO if GENERATE_SMBIOS_TABLE
imply SYSINFO_SMBIOS if GENERATE_SMBIOS_TABLE
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ba5ec69293fd..1bffbe2e2ba0 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -109,7 +109,7 @@ menu "Info commands"
config CMD_ACPI
bool "acpi"
- depends on ACPIGEN
+ depends on ACPI
default y
help
List and dump ACPI tables. ACPI (Advanced Configuration and Power
diff --git a/cmd/acpi.c b/cmd/acpi.c
index d0fc062ef8cb..991b5235e289 100644
--- a/cmd/acpi.c
+++ b/cmd/acpi.c
@@ -162,6 +162,10 @@ static int do_acpi_items(struct cmd_tbl *cmdtp, int flag,
int argc,
bool dump_contents;
dump_contents = argc >= 2 && !strcmp("-d", argv[1]);
+ if (!IS_ENABLED(CONFIG_ACPIGEN)) {
+ printf("Not supported (enable ACPIGEN)\n");
+ return CMD_RET_FAILURE;
+ }
acpi_dump_items(dump_contents ? ACPI_DUMP_CONTENTS : ACPI_DUMP_LIST);
return 0;
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 0f755aa702ee..f0d848f45d8e 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -448,6 +448,7 @@ config OFNODE_MULTI_TREE_MAX
config ACPIGEN
bool "Support ACPI table generation in driver model"
+ depends on ACPI
default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
select LIB_UUID
help
diff --git a/lib/Kconfig b/lib/Kconfig
index 4278b2405546..475797d9b391 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -281,9 +281,17 @@ config SUPPORT_ACPI
U-Boot can generate these tables and pass them to the Operating
System.
+config ACPI
+ bool "Enable support for ACPI libraries"
+ depends on SUPPORT_ACPI
+ help
+ Provides library functions for dealing with ACPI tables. This does
+ not necessarily include generation of tables
+ (see GENERATE_ACPI_TABLE), but allows for tables to be located.
+
config GENERATE_ACPI_TABLE
bool "Generate an ACPI (Advanced Configuration and Power Interface)
table"
- depends on SUPPORT_ACPI
+ depends on ACPI
select QFW if QEMU
help
The Advanced Configuration and Power Interface (ACPI) specification
diff --git a/lib/Makefile b/lib/Makefile
index 10aa7ac02985..8d8ccc8bbc39 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -66,7 +66,7 @@ obj-$(CONFIG_$(SPL_TPL_)CRC8) += crc8.o
obj-y += crypto/
-obj-$(CONFIG_$(SPL_TPL_)GENERATE_ACPI_TABLE) += acpi/
+obj-$(CONFIG_$(SPL_TPL_)ACPI) += acpi/
obj-$(CONFIG_$(SPL_)MD5) += md5.o
obj-$(CONFIG_ECDSA) += ecdsa/
obj-$(CONFIG_$(SPL_)RSA) += rsa/
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index 956b5a0d7265..12337abaecfa 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0+
#
+ifdef CONFIG_$(SPL_TPL_)GENERATE_ACPI_TABLE
+
obj-$(CONFIG_$(SPL_)ACPIGEN) += acpigen.o
obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi_device.o
obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi_dp.o
@@ -21,3 +23,5 @@ endif
obj-y += facs.o
obj-y += ssdt.o
endif
+
+endif # GENERATE_ACPI_TABLE
--
2.40.0.348.gf938b09366-goog
[PATCH v3 05/16] acpi: Move the table-finding functions into the libary
This is useful for other features. Move the function into library code
so it can be used outside just the 'acpi' command.
Signed-off-by: Simon Glass
---
Changes in v3:
- Avoid a build error with the ASL compiler
Changes in v2:
- Add new patch to move acpi-table-finding functions into the library
cmd/acpi.c| 40 +-
include/acpi/acpi_table.h | 8 +++
lib/acpi/Makefile | 2 ++
lib/acpi/acpi.c | 45 +++
4 files changed, 56 insertions(+), 39 deletions(-)
create mode 100644 lib/acpi/acpi.c
diff --git a/cmd/acpi.c b/cmd/acpi.c
index 991b5235e289..e70913e40bfe 100644
--- a/cmd/acpi.c
+++ b/cmd/acpi.c
@@ -36,49 +36,11 @@ static void dump_hdr(struct acpi_table_header *hdr)
}
}
-/**
- * find_table() - Look up an ACPI table
- *
- * @sig: Signature of table (4 characters, upper case)
- * Return: pointer to table header, or NULL if not found
- */
-struct acpi_table_header *find_table(const char *sig)
-{
- struct acpi_rsdp *rsdp;
- struct acpi_rsdt *rsdt;
- int len, i, count;
-
- rsdp = map_sysmem(gd_acpi_start(), 0);
- if (!rsdp)
- return NULL;
- rsdt = map_sysmem(rsdp->rsdt_address, 0);
- len = rsdt->header.length - sizeof(rsdt->header);
- count = len / sizeof(u32);
- for (i = 0; i < count; i++) {
- struct acpi_table_header *hdr;
-
- hdr = map_sysmem(rsdt->entry[i], 0);
- if (!memcmp(hdr->signature, sig, ACPI_NAME_LEN))
- return hdr;
- if (!memcmp(hdr->signature, "FACP", ACPI_NAME_LEN)) {
- struct acpi_fadt *fadt = (struct acpi_fadt *)hdr;
-
- if (!memcmp(sig, "DSDT", ACPI_NAME_LEN) && fadt->dsdt)
- return map_sysmem(fadt->dsdt, 0);
- if (!memcmp(sig, "FACS", ACPI_NAME_LEN) &&
- fadt->firmware_ctrl)
- return map_sysmem(fadt->firmware_ctrl, 0);
- }
- }
-
- return NULL;
-}
-
static int dump_table_name(const char *sig)
{
struct acpi_table_header *hdr;
- hdr = find_table(sig);
+ hdr = acpi_find_table(sig);
if (!hdr)
return -ENOENT;
printf("%.*s @ %08lx\n", ACPI_NAME_LEN, hdr->signature,
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index 4030d25c66a0..7ed0443c821a 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -923,6 +923,14 @@ int acpi_fill_csrt(struct acpi_ctx *ctx);
*/
ulong write_acpi_tables(ulong start);
+/**
+ * acpi_find_table() - Look up an ACPI table
+ *
+ * @sig: Signature of table (4 characters, upper case)
+ * Return: pointer to table header, or NULL if not found
+ */
+struct acpi_table_header *acpi_find_table(const char *sig);
+
#endif /* !__ACPI__*/
#include
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index 12337abaecfa..c1c9675b5d2a 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-y += acpi.o
+
ifdef CONFIG_$(SPL_TPL_)GENERATE_ACPI_TABLE
obj-$(CONFIG_$(SPL_)ACPIGEN) += acpigen.o
diff --git a/lib/acpi/acpi.c b/lib/acpi/acpi.c
new file mode 100644
index ..14b15754f492
--- /dev/null
+++ b/lib/acpi/acpi.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Utility functions for ACPI
+ *
+ * Copyright 2023 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct acpi_table_header *acpi_find_table(const char *sig)
+{
+ struct acpi_rsdp *rsdp;
+ struct acpi_rsdt *rsdt;
+ int len, i, count;
+
+ rsdp = map_sysmem(gd_acpi_start(), 0);
+ if (!rsdp)
+ return NULL;
+ rsdt = map_sysmem(rsdp->rsdt_address, 0);
+ len = rsdt->header.length - sizeof(rsdt->header);
+ count = len / sizeof(u32);
+ for (i = 0; i < count; i++) {
+ struct acpi_table_header *hdr;
+
+ hdr = map_sysmem(rsdt->entry[i], 0);
+ if (!memcmp(hdr->signature, sig, ACPI_NAME_LEN))
+ return hdr;
+ if (!memcmp(hdr->signature, "FACP", ACPI_NAME_LEN)) {
+ struct acpi_fadt *fadt = (struct acpi_fadt *)hdr;
+
+ if (!memcmp(sig, "DSDT", ACPI_NAME_LEN) && fadt->dsdt)
+ return map_sysmem(fadt->dsdt, 0);
+ if (!memcmp(sig, "FACS", ACPI_NAME_LEN) &&
+ fadt->firmware_ctrl)
+ return map_sysmem(fadt->firmware_ctrl, 0);
+ }
+ }
+
+ return NULL;
+}
--
2.40.0.348.gf938b09366-goog
[PATCH v3 03/16] input: Flush the keyboard buffer before resetting it
If U-Boot is not the first-stage bootloader the keyboard may already be
set up. Make sure to flush any data before trying to reset it. This
avoids a long timeout / hang.
Add some comments and a log category while we are here.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Flush the buffer instead of skipping the reset
drivers/input/i8042.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 3563dc98838f..e6070ca01529 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -6,6 +6,8 @@
/* i8042.c - Intel 8042 keyboard driver routines */
+#define LOG_CATEGORY UCLASS_KEYBOARD
+
#include
#include
#include
@@ -54,6 +56,14 @@ static unsigned char ext_key_map[] = {
0x00 /* map end */
};
+/**
+ * kbd_input_empty() - Wait until the keyboard is ready for a command
+ *
+ * Checks the IBF flag (input buffer full), waiting for it to indicate that
+ * any previous command has been processed.
+ *
+ * Return: true if ready, false if it timed out
+ */
static int kbd_input_empty(void)
{
int kbd_timeout = KBD_TIMEOUT * 1000;
@@ -64,6 +74,12 @@ static int kbd_input_empty(void)
return kbd_timeout != -1;
}
+/**
+ * kbd_output_full() - Wait until the keyboard has data available
+ *
+ * Checks the OBF flag (output buffer full), waiting for it to indicate that
+ * a response to a previous command is available
+ */
static int kbd_output_full(void)
{
int kbd_timeout = KBD_TIMEOUT * 1000;
@@ -127,6 +143,9 @@ static int kbd_reset(int quirk)
{
int config;
+ if (!kbd_input_empty())
+ goto err;
+
/* controller self test */
if (kbd_cmd_read(CMD_SELF_TEST) != KBC_TEST_OK)
goto err;
--
2.40.0.348.gf938b09366-goog
[PATCH v3 02/16] x86: Adjust search range for sysinfo table
Avoid searching starting at 0 since this memory may not be available,
e.g. if protection against NULL-pointer access is enabled. The table
cannot be there anyway, since the first 1KB of memory was originally
used for the interrupt table and coreboot avoids it.
Start at 0x400 instead.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Update commit message with more detail
- Update code comment to mention that addresses <1KB are ignored
arch/x86/cpu/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 6fe6eaf6c84e..281e966c 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -351,8 +351,8 @@ long locate_coreboot_table(void)
{
long addr;
- /* We look for LBIO in the first 4K of RAM and again at 960KB */
- addr = detect_coreboot_table_at(0x0, 0x1000);
+ /* We look for LBIO from addresses 1K-4K and again at 960KB */
+ addr = detect_coreboot_table_at(0x400, 0xc00);
if (addr < 0)
addr = detect_coreboot_table_at(0xf, 0x1000);
--
2.40.0.348.gf938b09366-goog
[PATCH v3 01/16] mtrr: Don't show an invalid CPU number
When U-Boot did not do the MP init, we don't get an actual CPU number
here. Skip printing it in that case.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Don't show an invalid CPU number on error
cmd/x86/mtrr.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cmd/x86/mtrr.c b/cmd/x86/mtrr.c
index b213a942fde4..ff4be6b7bf5b 100644
--- a/cmd/x86/mtrr.c
+++ b/cmd/x86/mtrr.c
@@ -145,10 +145,12 @@ static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int
argc,
for (; i >= 0; i = mp_next_cpu(cpu_select, i)) {
if (!first)
printf("\n");
- printf("CPU %d:\n", i);
+ if (i < MP_SELECT_ALL)
+ printf("CPU %d:\n", i);
ret = do_mtrr_list(reg_count, i);
if (ret) {
- printf("Failed to read CPU %d (err=%d)\n", i,
+ printf("Failed to read CPU %s (err=%d)\n",
+ i < MP_SELECT_ALL ? simple_itoa(i) : "",
ret);
return CMD_RET_FAILURE;
}
--
2.40.0.348.gf938b09366-goog
[PATCH v3 00/16] x86: Various minor enhancements for coreboot
This series includes some patches generated while getting U-Boot to boot more nicely on Brya, an Adler Lake Chromebook. This includes: - show the ACPI tables with 'acpi list' - get the UART to work even if coreboot doesn't enable it - show unimplemented sysinfo tags - fix for keyboard not working - fix for trying to set up PCI regions when the info is not available - fix for looking at inaccessible memory to find the sysinfo table Changes in v3: - Don't enable ACPI by default except on x86 and sandbox - Avoid a build error with the ASL compiler - Disable for coreboot64 since ACPI is not available Changes in v2: - Don't show an invalid CPU number on error - Update commit message with more detail - Update code comment to mention that addresses <1KB are ignored - Flush the buffer instead of skipping the reset - Add new patch to create a new Kconfig for ACPI - Add new patch to move acpi-table-finding functions into the library - Use tab instead of space in header file - Refactor two patches into one - Add new patch to allow locating the UART from ACPI tables - Expand commit message to explain this is for the debug UART - Update the defconfig instead - Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere - Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed) - Add new patch to enable ms command - Move this patch to last in the series, so it can be dropped if needed Simon Glass (16): mtrr: Don't show an invalid CPU number x86: Adjust search range for sysinfo table input: Flush the keyboard buffer before resetting it acpi: Create a new Kconfig for ACPI acpi: Move the table-finding functions into the libary x86: coreboot: Collect the address of the ACPI tables x86: Allow locating the UART from ACPI tables pci: coreboot: Don't read regions when booting x86: coreboot: Use a memory-mapped UART x86: coreboot: Document how to enable the debug UART x86: coreboot: Scan PCI after relocation x86: coreboot: Log function names and line numbers x86: coreboot: Show unimplemented sysinfo tags x86: nvme: coreboot: Enable NVMe coreboot: Enable ms command x86: Allow locating UARTs by device ID arch/Kconfig | 2 + arch/x86/cpu/cpu.c | 4 +- arch/x86/dts/coreboot.dts | 4 + arch/x86/include/asm/cb_sysinfo.h | 8 ++ arch/x86/include/asm/coreboot_tables.h | 2 + arch/x86/lib/coreboot/cb_sysinfo.c | 13 +++ cmd/Kconfig| 2 +- cmd/acpi.c | 44 +-- cmd/x86/cbsysinfo.c| 9 ++ cmd/x86/mtrr.c | 6 +- configs/coreboot64_defconfig | 1 - configs/coreboot_defconfig | 10 +- doc/board/coreboot/coreboot.rst| 29 + drivers/core/Kconfig | 1 + drivers/input/i8042.c | 19 +++ drivers/nvme/nvme_pci.c| 8 ++ drivers/pci/pci-uclass.c | 4 + drivers/serial/Kconfig | 10 ++ drivers/serial/serial_coreboot.c | 155 +++-- include/acpi/acpi_table.h | 8 ++ include/asm-generic/global_data.h | 4 +- include/pci_ids.h | 3 + lib/Kconfig| 10 +- lib/Makefile | 2 +- lib/acpi/Makefile | 6 + lib/acpi/acpi.c| 45 +++ 26 files changed, 351 insertions(+), 58 deletions(-) create mode 100644 lib/acpi/acpi.c -- 2.40.0.348.gf938b09366-goog
Re: [RFC 7/7] efi_loader: use uclass_get_dp_node
Hi Heinrich,
On Mon, 27 Mar 2023 at 06:28, Heinrich Schuchardt
wrote:
>
> Use function uclass_get_dp_node() to construct device paths.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_device_path.c | 325 +++
> 1 file changed, 28 insertions(+), 297 deletions(-)
This is definitely a step in the right direction. Thank you for working on it.
[..]
> + dp = uclass_get_dp_node(dev);
> + if (dp) {
> + memcpy(buf, dp, dp->length);
> + buf += dp->length;
> + efi_free_pool(dp);
This suggests that the API should be:
int uclass_get_dp_node(struct xxx *dp)
with it writing the data to the provided pointer address and returning
the number of bytes used. That would avoid the malloc() / free().
> }
> +
> + return buf;
> }
>
> static unsigned dp_part_size(struct blk_desc *desc, int part)
> --
> 2.39.2
>
Regards,
Simon
Re: [RFC 1/7] dm: add get_dp_node() to struct uclass_driver
Hi Heinrich,
On Mon, 27 Mar 2023 at 06:27, Heinrich Schuchardt
wrote:
>
> Currently the device paths don't match the dm tree.
> We should create a device path node per dm tree node.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/dm/uclass.h | 5 +
> 1 file changed, 5 insertions(+)
This affects very few uclasses but adds a field to all of them. I
think an event might be best for this. We can add an event spy in each
of the affected uclasses.
>
> diff --git a/include/dm/uclass.h b/include/dm/uclass.h
> index ee15c92063..e11637ce4d 100644
> --- a/include/dm/uclass.h
> +++ b/include/dm/uclass.h
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -68,6 +69,7 @@ struct udevice;
> * @child_post_probe: Called after a child in this uclass is probed
> * @init: Called to set up the uclass
> * @destroy: Called to destroy the uclass
> + * @get_dp_node: Get EFI device path node
> * @priv_auto: If non-zero this is the size of the private data
> * to be allocated in the uclass's ->priv pointer. If zero, then the uclass
> * driver is responsible for allocating any data required.
> @@ -99,6 +101,9 @@ struct uclass_driver {
> int (*child_post_probe)(struct udevice *dev);
> int (*init)(struct uclass *class);
> int (*destroy)(struct uclass *class);
> +#if CONFIG_IS_ENABLED(EFI_LOADER)
> + struct efi_device_path *(*get_dp_node)(struct udevice *dev);
> +#endif
> int priv_auto;
> int per_device_auto;
> int per_device_plat_auto;
> --
> 2.39.2
>
Re: Default value for bootcmd not defined
Hi Stefan, On Thu, 16 Mar 2023 at 17:09, Stefan Nagy wrote: > > Hello, > > I followed the official documentation [1] to build U-Boot for my Rock > Pi 4, instead of evb-rk3399_defconfig I used the config file for my > board (rock-pi-4-rk3399_defconfig). > > After I flashed the single boot image to an SD card and put it in I got > stuck with the error message: "distro_bootcmd" not defined. > > Since I have no idea of U-Boot it took me some time to find out that > all I needed was to set a different default value for bootcmd. Now I > use CONFIG_BOOTCOMMAND="bootflow scan" and it boots my OS as expected. > > The official documentation looks straightforward for simple users like > me, so I thought it might not be intended that the default value for > the bootcmd entry is (still) distro_bootcmd. Yes we are working through the migration. For this release, Tom is fixing the rk3399 boards so it should boot correctly. Regards, Simon
Re: [RFC 3/7] dm: implement get_dp_node for block devices
Hi Heinrich,
On Mon, 27 Mar 2023 at 06:27, Heinrich Schuchardt
wrote:
>
> Generate a Ctrl() node for block devices.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/block/blk-uclass.c | 56 ++
> 1 file changed, 56 insertions(+)
Can this go in drivers/block/blk_efi.c ?
Can you create a function which returns the path given a device? Then
we are discuss the get_dp_node() member or moving to an event. I
favour the event for now.
>
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index c69fc4d518..08202aaaba 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -779,9 +780,64 @@ static int blk_post_probe(struct udevice *dev)
> return 0;
> }
>
> +#if CONFIG_IS_ENABLED(EFI_LOADER)
> +__maybe_unused
> +static struct efi_device_path *blk_scsi_get_dp_node(struct udevice *dev)
> +{
> + struct efi_device_path_scsi *dp;
> + struct blk_desc *desc = dev_get_uclass_plat(dev);
> +
> + dp = efi_alloc(sizeof(struct efi_device_path_scsi));
> + if (!dp)
> + return NULL;
> +
> + dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
> + dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_SCSI;
> + dp->dp.length = sizeof(*dp);
> + dp->logical_unit_number = desc->lun;
> + dp->target_id = desc->target;
> +
> + return >dp;
> +}
> +
> +static struct efi_device_path *blk_get_dp_node(struct udevice *dev)
> +{
> + struct efi_device_path_controller *dp;
> + struct blk_desc *desc = dev_get_uclass_plat(dev);
> + u32 controller_number;
> +
> + switch (device_get_uclass_id(dev->parent)) {
> +#if CONFIG_IS_ENABLED(SCSI)
> + case UCLASS_SCSI:
> + return blk_scsi_get_dp_node(dev);
> +#endif
> + case UCLASS_MMC:
> + dp->controller_number = desc->hwpart;
> + break;
> + default:
Since this is checking the parent class, it seems to me that this info
should be attacked there (the 'media' device) instead of the block
device.
> + dp->controller_number = desc->lun;
> + break;
> + }
> +
> + dp = efi_alloc(sizeof(struct efi_device_path_controller));
> + if (!dp)
> + return NULL;
> +
> + dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
> + dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_CONTROLLER;
> + dp->dp.length = sizeof(*dp);
> + dp->controller_number = controller_number;
> +
> + return >dp;
> +}
> +#endif
> +
> UCLASS_DRIVER(blk) = {
> .id = UCLASS_BLK,
> .name = "blk",
> .post_probe = blk_post_probe,
> .per_device_plat_auto = sizeof(struct blk_desc),
> +#if CONFIG_IS_ENABLED(EFI_LOADER)
> + .get_dp_node= blk_get_dp_node,
> +#endif
> };
> --
> 2.39.2
>
Regards,
Simon
Re: [PATCH v2 0/4] NFSv1 support
Hi Peter, On Sat, 25 Mar 2023 at 02:14, Peter Robinson wrote: > > On Fri, Mar 24, 2023 at 1:05 PM Christian Gmeiner > wrote: > > > > Hi Peter > > > > > > > > > > Hi Peter, > > > > > > > > Am Fr., 24. März 2023 um 11:10 Uhr schrieb Peter Robinson > > > > : > > > > > > > > > > On Fri, Mar 24, 2023 at 9:35 AM Christian Gmeiner > > > > > wrote: > > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > > > > > > > > > > > This patch series adds support for NFSv1 and is more > > > > > > > > or less a rebased version of an older series. > > > > > > > > > > > > > > > > During V1 there was a discussion if it really makes sense > > > > > > > > to bring more features into the network stack of U-Boot as it > > > > > > > > is just a bootloader. As TCP support landed I thought I might > > > > > > > > give this patch series another try. > > > > > > > > > > > > > > So the real question is what use does this bring? TCP is useful > > > > > > > because it can enable support for modern features like UEFI HTTP > > > > > > > boot. > > > > > > > What is the use of NFSc1? The Linux kernel is removing support for > > > > > > > NFSv2 and according to wikipedia v1 was only ever used internally > > > > > > > to > > > > > > > Sun so I'm not sure what the wider use of this functionality > > > > > > > would be? > > > > > > > > > > > > > > > > > > > You know there are other operating systems used in the wild. One of > > > > > > them is > > > > > > vxworks. The company I work for supports software versions for more > > > > > > than 10 > > > > > > years and customers do not want to update to newer software versions > > > > > > as the process > > > > > > of approval for wind turbines/parks is very costly and time > > > > > > intensive. > > > > > > For security > > > > > > issues we provide patches for older versions that the customers are > > > > > > switching to. > > > > > > > > > > Are there deployments that are updating to new versions of U-Boot that > > > > > require NFSv1 though? > > > > > > > > > > > > > Sadly, yes .. There are so called drop-in replacements for "processor > > > > modules" where > > > > we update the old design (e.g. AMD LX800 based 26G MHz one) to a new > > > > recent Intel SoC. > > > > Our customer can order a replacement HW for the old LX800 based design > > > > and they get > > > > the new one with fully compatible software. > > > > > > > > > > We are shipping devices right now which are based on vxworks 5. Some > > > > > > customers are using our "processor modules" as NFS server for e.g. > > > > > > other > > > > > > "processor modules" to boot from. If you want/need I can go into > > > > > > further details > > > > > > about our use case. > > > > > > > > > > So they're using a 25 year old version of vxworks with the latest > > > > > version of U-Boot? And vxworks supports only NFSv1, and not NFSv2, > > > > > which has been out since 1989 and was the first version that even Sun > > > > > supported publicly? > > > > > > > > > > > > > There are newer versions of NFS supported on more recent vxworks > > > > versions but as our > > > > customers do not want to change software of an approved wind turbine we > > > > need to > > > > support the old feature. > > > > > > > > Also we are allowed to include only critical fixes in patch version, > > > > which can be used > > > > without the whole approval process. For any new feature our customer > > > > would > > > > need to redo the whole approval process. > > > > > > Yet they allow you to update the entire version of U-Boot to the latest > > > one? > > > > U-Boot is used as coreboot payload and both together are the bios. None of > > our > > customers do bios updates in the field as the risk of bricking the > > device is too high. > > > > > > > > I understand how the process works when they don't want to change > > > things, but it doesn't make sense to update U-Boot to the latest > > > version yet not other pieces of the infrastructure. NFSv1 was > > > basically obsolete from the outset because Sun's first public release > > > was v2. > > > > > > It doesn't make sense to me to upstream a long obsolete version, and > > > no doubt insecure, version of a protocol which is seemingly used by a > > > single customer of yours. > > > > I am fine with that decision .. but I hope you know that NFSv2 is an > > insecure version too! > > Oh I'm well aware of that, it's at least been more widely reviewed and > the issues are better known. Personally I've never particularly seen > the point of NFS in a firmware at all. These days I think HTTP would > provide equivalence of functionality with the better support for > things like proxy/caching/CDN and other such functionality. But here we are talking about supporting old software. So it doesn't much matter that HTTP is now available. Regards, Simon > > > > > > > > > > > > > > > So I know It is a quite specific use case but we want to upstream > > > > > > most > > > > > > of our downstream > > > > > > patches. > > >
Re: [PATCH 1/1] cmd: CONFIG_CMD_SCSI depends on CONFIG_SCSI
On Mon, 27 Mar 2023 at 06:10, Heinrich Schuchardt wrote: > > Compiling with CONFIG_CMD_SCSI=y, CONFIG_SCSI results in > > cmd/scsi.c:46: undefined reference to `scsi_scan' > > Signed-off-by: Heinrich Schuchardt > --- > cmd/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 2caa4af71c..5c1b353c90 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1436,7 +1436,8 @@ config CMD_SATA Reviewed-by: Simon Glass
Re: [RFC 2/7] dm: implement uclass_get_dp_node()
Hi Heinrich,
On Mon, 27 Mar 2023 at 06:27, Heinrich Schuchardt
wrote:
>
> Provide a function to get the EFI device path node representing a
> device.
>
> If implemented, it invokes the uclass driver's get_dp_node() function.
> Otherwise a vendor hardware node is created.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/core/uclass.c | 26 ++
> include/dm/uclass.h | 8
> include/efi_loader.h | 7 +++
> 3 files changed, 41 insertions(+)
Can you add a new file, like drivers/core/efi.c for this stuff?
You should also pull out the header stuff you need and put it in
include/dm/efi.h since we don't want to include efi_loader.h from
driver/core.
>
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index 1762a0796d..153c954ee3 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -10,6 +10,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -802,6 +803,31 @@ int uclass_pre_remove_device(struct udevice *dev)
> }
> #endif
>
> +#if CONFIG_IS_ENABLED(EFI_LOADER)
> +struct efi_device_path *uclass_get_dp_node(struct udevice *dev)
> +{
> + struct uclass *uc;
> + struct efi_device_path_uboot *dp;
> +
> + uc = dev->uclass;
> + if (uc->uc_drv->get_dp_node)
> + return uc->uc_drv->get_dp_node(dev);
> +
> + dp = efi_alloc(sizeof(struct efi_device_path_uboot));
This should call malloc(), right?
How does this memory get freed? How do we avoid allocating it twice if
it is called twice?
> + if (!dp)
> + return NULL;
-ENOMEM ? I suggest changing the function return value to an int.
> +
> + dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
> + dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
> + dp->dp.length = sizeof(struct efi_device_path_uboot);
> + dp->guid = efi_u_boot_guid;
> + dp->uclass_id = uc->uc_drv->id;
> + dp->seq_ = dev->seq_;
> +
> + return >dp;
> +}
> +#endif
> +
> int uclass_probe_all(enum uclass_id id)
> {
> struct udevice *dev;
> diff --git a/include/dm/uclass.h b/include/dm/uclass.h
> index e11637ce4d..f39dbac21d 100644
> --- a/include/dm/uclass.h
> +++ b/include/dm/uclass.h
> @@ -503,3 +503,11 @@ int uclass_id_count(enum uclass_id id);
> uclass_next_device())
>
> #endif
> +
> +/**
> + * uclass_get_dp_node() - get EFI device path node for device
> + *
> + * @dev: device
> + * Return: device path node or NULL if out of memory
> + */
> +struct efi_device_path *uclass_get_dp_node(struct udevice *dev);
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index cee04cbb9d..f111bc616d 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -22,6 +22,13 @@
> struct blk_desc;
> struct jmp_buf_data;
>
> +struct efi_device_path_uboot {
> + struct efi_device_path dp;
> + efi_guid_t guid;
> + enum uclass_id uclass_id;
> + int seq_;
What is this member for? Can you please comment this struct?
> +} __packed;
> +
> static inline int guidcmp(const void *g1, const void *g2)
> {
> return memcmp(g1, g2, sizeof(efi_guid_t));
> --
> 2.39.2
>
Regards,
Simon
Re: [PATCH 2/2] ata: don't use SYS_SCSI_MAX_SCSI_ID for SATA
On Mon, 27 Mar 2023 at 05:58, Heinrich Schuchardt wrote: > > CONFIG_SYS_SCSI_MAX_SCSI_ID is not defined if CONFIG_SCSI=n. > > Signed-off-by: Heinrich Schuchardt > --- > configs/controlcenterdc_defconfig | 1 + > configs/highbank_defconfig| 1 + > drivers/ata/Kconfig | 8 > drivers/ata/ahci.c| 4 ++-- > 4 files changed, 12 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration
Hi Tom, On Sat, 25 Mar 2023 at 09:58, Tom Rini wrote: > > Hey all, > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration, > and it changed too much for everything else. I took about half of that > series and then reworked a few things. Now only rk3399 platforms change > at all and aside from bootcmd changes, the only thing is they now > disable true/test/sysboot/showvar/false/exit commands as those were > being pulled in from distro and now we don't set that flag. I think the > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to > perform more SoC migrations. Thanks for digging into this. I haven't seen any comments on the rpi conversion, so perhaps people could test that? Regards, Simon
Re: DM SPI flash improvements
Hi Tony, On Mon, 27 Mar 2023 at 12:28, Tony Dinh wrote: > > Hi Simon, > > I'm investigating a problem with the Thecus N2350 board that has SPI > flash on controller 1, but not on controller 0. Booting with SPI SPL > is not possible with CONFIG_SF_DEFAULT_BUS=1. > > Reference: > https://lists.denx.de/pipermail/u-boot/2023-March/511517.html > > That led me to the drivers/mtd/spi/sf-uclass.c and drivers/spi/spi-uclass.c. > > And I found there are some problems in the spi_flash_probe(), as well > as _spi_get_bus_and_cs(). But seeing your comment in the > spi_flash_probe function header, I'm thinking perhaps I should not try > to fix them. > > /* > * TODO(s...@chromium.org): This is an old-style function. We should remove > * it when all SPI flash drivers use dm > */ > struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs, > unsigned int max_hz, unsigned int spi_mode) > > Could you or Jagan clarify the TODO above meaning? Are we fully in DM > SPI yet? If we are, should this be replaced with other means to probe > the SPI bus? Or it should have been automatically probed by DM SPI > infrastructure, and we just need to tag the SPI 1 DTS node with > boot-phase? If that's the case then perhaps this function should be > defined out with some configs wrapping. Ideally you would obtain the SPI-flash device using spi_flash_std_probe(). The SPI buses can be added to the device tree with 'spi0' and 'spi1' aliases. Then you can add a child noe of spi1 with your flash chip. There is definitely some work needed to remove the old code. We don't have a proper way to select the boot device yet, Probably what is needed ultimately is something like the u-boot.spl-device-order used by Rockchip boards. We should really get away from using SPI-bus numbers. > > My current SPI configs: > > CONFIG_SPL_DM_SPI=y > CONFIG_SPL_DM_SPI_FLASH=y > # CONFIG_DM_HWSPINLOCK is not set > CONFIG_DM_SPI_FLASH=y > CONFIG_DM_SPI=y > CONFIG_SF_DEFAULT_SPEED=5000 > CONFIG_SF_DEFAULT_MODE=0x0 > # CONFIG_CMD_SF_TEST is not set > CONFIG_SF_DEFAULT_BUS=1 > CONFIG_SF_DEFAULT_CS=0 > > Thanks, > Tony Regards, Simon
Re: [PATCH 2/2] efi_loader: fix device-path for USB devices
Hi Heinrich,
On Wed, 22 Mar 2023 at 02:21, Heinrich Schuchardt
wrote:
>
> On 3/20/23 19:39, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 20 Mar 2023 at 09:58, Heinrich Schuchardt
> > wrote:
> >>
> >>
> >>
> >> On 3/19/23 20:29, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Mon, 20 Mar 2023 at 04:25, Heinrich Schuchardt
> >>> wrote:
>
> EFI device paths for block devices must be unique. If a non-unique device
> path is discovered, probing of the block device fails.
>
> Currently we use UsbClass() device path nodes. As multiple devices may
> have the same vendor and product id these are non-unique. Instead we
> should use Usb() device path nodes. They include the USB port on the
> parent hub. Hence they are unique.
>
> A USB storage device may contain multiple logical units. These can be
> modeled as Ctrl() nodes.
>
> Reported-by: Patrick Delaunay
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_device_path.c | 45 +++-
> 1 file changed, 33 insertions(+), 12 deletions(-)
> >>>
> >>> Reviewed-by: Simon Glass
> >>>
> >>> [..]
> >>>
>
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index 3b267b713e..b6dd575b13 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -147,7 +147,7 @@ struct efi_device_path *efi_dp_shorten(struct
> efi_device_path *dp)
> * in practice fallback.efi just uses MEDIA:HARD_DRIVE
> * so not sure when we would see these other cases.
> */
> - if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB_CLASS) ||
> + if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) ||
> EFI_DP_TYPE(dp, MEDIA_DEVICE, HARD_DRIVE_PATH) ||
> EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH))
> return dp;
> @@ -564,6 +564,11 @@ __maybe_unused static unsigned int dp_size(struct
> udevice *dev)
> return dp_size(dev->parent)
> + sizeof(struct
> efi_device_path_vendor) + 1;
> #endif
> +#ifdef CONFIG_USB
> + case UCLASS_MASS_STORAGE:
> >>>
> >>> Can we do:
> >>>
> >>> case UCLASS_MASS_STORAGE:
> >>> if (IS_ENABLED(CONFIG_USB)) {
> >>> ...
> >>> }
> >>>
> >>> ?
> >>
> >> That should be possible too. Didn't you want to get rid of IS_ENABLED()?
> >> CONFIG_IS_ENABLED() would work here too.
> >
> > I was wanting to get rid of CONFIG_IS_ENABLED() for things that don't
> > have an SPL Kconfig, then eventually get rid of CONFIG_IS_ENABLED().
> > I've got a bit lost in all the problems though.
> >
> >>
> >> The whole way that we create device paths is not consistent. We should
> >> have a device path node for each DM device.
> >>
> >> With v2023.07 I want to add
> >>
> >> struct efi_device_path *(*get_dp_node)(struct udevice *dev);
> >>
> >> to struct uclass_driver and move the generation of device path nodes to
> >> the individual uclass drivers.
> >
> > We could also send an event (EVT_EFI_GET_DP_NODE) and connect it that
> > way...ie would add less space to driver model. But yes it would be
> > good to line up EFI and DM a bit better.
>
> The type of device-path node to be created is uclass specific:
>
> For an NVMe device we will always create a NVMe() node.
> For a block device we will always create a Ctrl() node with the LUN number.
> ...
>
> For drivers that don't implement the method yet we can create a VenHw()
> node per default with uclass-id and device number encoded in the node.
>
> You suggested yourself that the DM and the EFI implementation should be
> tightly integrated.
I mean that EFI should make full use of DM rather than maintaining
parallel structures that need manual updating.
>
> I cannot see what the use of an event should be. Why should each udevice
> register to an event when all we need is a simple function like:
>
> #if CONFIG_IS_ENABLED(EFI_LOADER)
> struct efi_device_path *uclass_get_dp_node(struct udevice *dev)
> {
> struct uclass *uc;
> struct efi_device_path_uboot *dp;
>
> uc = dev->uclass;
> if (uc->uc_drv->get_dp_node)
> return uc->uc_drv->get_dp_node(dev);
>
> dp = efi_alloc(sizeof(struct efi_device_path_uboot));
> if (!dp)
> return NULL;
>
> dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
> dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
> dp->dp.length = sizeof(struct efi_device_path_uboot);
> dp->guid = efi_u_boot_guid;
> dp->uclass_id = uc->uc_drv->id;
> dp->seq_ = dev->seq_;
>
> return >dp;
> }
> #endif
>
Re: [PATCH] CI: Move to clang-16
Hi Tom, On Wed, 22 Mar 2023 at 08:07, Tom Rini wrote: > > As this is now the stable release, move to using that now for our tests. > > Signed-off-by: Tom Rini > --- > .azure-pipelines.yml| 6 +++--- > .gitlab-ci.yml | 4 ++-- > tools/docker/Dockerfile | 4 ++-- > 3 files changed, 7 insertions(+), 7 deletions(-) > Reviewed-by: Simon Glass I haven't figured out the linker_list problem yet though. Regards, Simon
Re: [PATCH 1/2] ata: fix requirements for CONFIG_AHCI_PCI
On Mon, 27 Mar 2023 at 05:58, Heinrich Schuchardt wrote: > > Building with CONFIG_AHCI_PCI=y and CONFIG_SCSI_AHCI=n leads to > > drivers/ata/ahci-pci.o: in function `ahci_pci_probe': > drivers/ata/ahci-pci.c:21: undefined reference to `ahci_probe_scsi_pci' > > Signed-off-by: Heinrich Schuchardt > --- > drivers/ata/Kconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass
Re: [PATCH 1/1] doc: describe skipping triggering a pipeline in Gitlab
On Sun, 26 Mar 2023 at 15:55, Heinrich Schuchardt wrote: > > 'git push -o ci.skip' can be used to push to Gitlab without triggering a > pipeline. > > Signed-off-by: Heinrich Schuchardt > --- > doc/develop/ci_testing.rst | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Simon Glass
Re: [v2 2/2] Dockerfile: Populate a pip cache
On Fri, 24 Mar 2023 at 07:58, Tom Rini wrote: > > Given the number of jobs in CI we have which use python and pip install > packages, we should do this once in the Dockerfile, in order to populate > the cache. We let each job continue to create and use the virtual > environments they need to facilitate making updates to these > environments easier. > > Signed-off-by: Tom Rini > --- > Changes in v2: > - Comment on why we wget > - Drop commented out portion > --- > tools/docker/Dockerfile | 11 +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 1/1] scsi: typo supporedt
On Mon, 27 Mar 2023 at 04:11, Heinrich Schuchardt
wrote:
>
> %s/supporedt/supported/
>
> Fixes: edca8cf72130 ("Convert CONFIG_SCSI_AHCI_PLAT et al to Kconfig")
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/scsi/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Simon Glass
Re: [v2 1/2] pytest: Update requirements to match sphinx versions
On Fri, 24 Mar 2023 at 07:58, Tom Rini wrote: > > In order to better make use of pip caches, and also for better overall > consistency, we should use the same versions of packages in each of our > python requirements files. Update pytest to use the newer versions of > packages we use in sphinx builds. > > Signed-off-by: Tom Rini > --- > Changes in v2: > - Don't forget to send this patch, this time. > --- > test/py/requirements.txt | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v2 00/16] x86: Various minor enhancements for coreboot
Hi Bin, On Fri, 24 Mar 2023 at 07:32, Simon Glass wrote: > > This series includes some patches generated while getting U-Boot to boot > more nicely on Brya, an Adler Lake Chromebook. > > This includes: > - show the ACPI tables with 'acpi list' > - get the UART to work even if coreboot doesn't enable it > - show unimplemented sysinfo tags > - fix for keyboard not working > - fix for trying to set up PCI regions when the info is not available > - fix for looking at inaccessible memory to find the sysinfo table > > Changes in v2: > - Don't show an invalid CPU number on error > - Update commit message with more detail > - Update code comment to mention that addresses <1KB are ignored > - Flush the buffer instead of skipping the reset > - Add new patch to create a new Kconfig for ACPI > - Add new patch to move acpi-table-finding functions into the library > - Use tab instead of space in header file > - Refactor two patches into one > - Add new patch to allow locating the UART from ACPI tables > - Expand commit message to explain this is for the debug UART > - Update the defconfig instead > - Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere > - Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed) > - Add new patch to enable ms command > - Move this patch to last in the series, so it can be dropped if needed > > Simon Glass (16): > mtrr: Don't show an invalid CPU number > x86: Adjust search range for sysinfo table > input: Flush the keyboard buffer before resetting it > acpi: Create a new Kconfig for ACPI > acpi: Move the table-finding functions into the libary > x86: coreboot: Collect the address of the ACPI tables > x86: Allow locating the UART from ACPI tables > pci: coreboot: Don't read regions when booting > x86: coreboot: Use a memory-mapped UART > x86: coreboot: Document how to enable the debug UART > x86: coreboot: Scan PCI after relocation > x86: coreboot: Log function names and line numbers > x86: coreboot: Show unimplemented sysinfo tags > x86: nvme: coreboot: Enable NVMe > coreboot: Enable ms command > x86: Allow locating UARTs by device ID > > arch/x86/cpu/cpu.c | 4 +- > arch/x86/dts/coreboot.dts | 4 + > arch/x86/include/asm/cb_sysinfo.h | 8 ++ > arch/x86/include/asm/coreboot_tables.h | 2 + > arch/x86/lib/coreboot/cb_sysinfo.c | 13 +++ > cmd/Kconfig| 2 +- > cmd/acpi.c | 44 +-- > cmd/x86/cbsysinfo.c| 9 ++ > cmd/x86/mtrr.c | 6 +- > configs/coreboot64_defconfig | 1 - > configs/coreboot_defconfig | 10 +- > doc/board/coreboot/coreboot.rst| 29 + > drivers/core/Kconfig | 1 + > drivers/input/i8042.c | 19 +++ > drivers/nvme/nvme_pci.c| 8 ++ > drivers/pci/pci-uclass.c | 4 + > drivers/serial/Kconfig | 10 ++ > drivers/serial/serial_coreboot.c | 155 +++-- > include/acpi/acpi_table.h | 8 ++ > include/asm-generic/global_data.h | 4 +- > include/pci_ids.h | 3 + > lib/Kconfig| 11 +- > lib/Makefile | 2 +- > lib/acpi/Makefile | 6 + > lib/acpi/acpi.c| 45 +++ > 25 files changed, 350 insertions(+), 58 deletions(-) > create mode 100644 lib/acpi/acpi.c > > -- > 2.40.0.348.gf938b09366-goog > I found a few problems with this series on other boards, so will send a v3. Regards, Simon
Re: [PATCH v1 0/5] Add Ethernet driver for StarFive JH7110 SoC
On 2023/3/24 20:53, Torsten Duwe wrote: > On Fri, 17 Mar 2023 09:05:31 +0800 > Yanhong Wang wrote: > >> This series adds ethernet support for the StarFive JH7110 RISC-V SoC. >> The series includes PHY and MAC drivers. The PHY model is >> YT8531 (from Motorcomm Inc), and the MAC version is dwmac-5.20 >> (from Synopsys DesignWare). >> >> The implementation of the phy driver is ported from linux, but it >> has been adjusted for the u-boot framework. >> >> The PHY and MAC driver has been tested on the StarFive VisionFive 2 1.2A >> and 1.3B boards and works normally. > > At least a smoke test here succeeded as well, I'm seeing replies to DHCP. > However: > > | Model: StarFive VisionFive 2 v1.3B > [...] > | Net: > | Warning: ethernet@1604 (eth1) using random MAC address - > e2:b9:39:bd:92:24 > | > | Warning: ethernet@1603 (eth0) using random MAC address - > 22:da:dc:e6:2c:17 > | eth0: ethernet@1603, eth1: ethernet@1604 > [...] > > What's missing to read the correct MACs from the EEPROM? > The minimum system of u-boot supporting JH7110 does not contain EEPROM and cannot read the MAC address from EEPROM, so enable the CONFIG_NET_RANDOM_ETHADDR, EEPROM will be supported in the future, and the MAC address will be read from EEPROM. > Torsten > >
Re: [PATCH v4 17/17] configs: starfive: add starfive_visionfive2_defconfig
On 2023/3/23 16:31, Andreas Schwab wrote: > On Mär 22 2023, yanhong wang wrote: > >> On 2023/3/21 21:51, Andreas Schwab wrote: >>> On Mär 21 2023, yanhong wang wrote: >>> Except for CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE, 1.2a and 1.3b versions use the same config. Version 1.3b uses the following configuration: CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b" CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" Version 1.2a uses the following configuration: CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.2a" CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.2a.dtb" Is it necessary to separate the configs for 1.2a and 1.3b as separate defconfig files? >>> >>> It makes a difference for when ethernet support is added. >>> >> >> The difference between 1.2a and 1.3b versions is mainly in ethernet, so the >> definition of >> dts is separated. Defconfig file in addition to the differences mentioned >> above, the others >> are the same. Your suggestion is to define defconfig file separately, is >> that right? > > Yes, a 1.2a board will need to use the 1.2a device tree to get a working > ethernet, IIUC. > Okay, I will define the defconfig for 1.2A and 1.3B separately in the next version.
Please pull u-boot-x86
Hi Tom, This PR contains the following x86 changes for v2023.04 release: - x86: Bug fixes of previous BayTrail platform CONFIG_TEXT_BASE changes The following changes since commit 8be7b4629e87ff8db08dd087c81d58129d029bad: Merge tag 'efi-2023.04-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-03-25 09:40:19 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-x86.git for you to fetch changes up to 843e840dbacbf5b419f230d63f00990ac8efe7e4: x86: som-db5800-som-6867: Fix up adjustment of CONFIG_TEXT_BASE (2023-03-27 09:38:44 +0800) Simon Glass (5): x86: minnowmax: Fix up adjustment of CONFIG_TEXT_BASE x86: bayleybay: Fix up adjustment of CONFIG_TEXT_BASE x86: conga-qeval20-qa3-e3845: Fix up adjustment of CONFIG_TEXT_BASE x86: dfi-bt700: Fix up adjustment of CONFIG_TEXT_BASE x86: som-db5800-som-6867: Fix up adjustment of CONFIG_TEXT_BASE arch/x86/dts/bayleybay.dts| 2 +- arch/x86/dts/baytrail_som-db5800-som-6867.dts | 2 +- arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +- arch/x86/dts/dfi-bt700.dtsi | 2 +- arch/x86/dts/minnowmax.dts| 2 +- configs/bayleybay_defconfig | 1 + configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 + configs/conga-qeval20-qa3-e3845_defconfig | 1 + configs/dfi-bt700-q7x-151_defconfig | 1 + configs/minnowmax_defconfig | 1 + configs/som-db5800-som-6867_defconfig | 1 + configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 1 + configs/theadorable-x86-conga-qa3-e3845_defconfig | 1 + configs/theadorable-x86-dfi-bt700_defconfig | 1 + doc/board/intel/minnowmax.rst | 15 +-- 15 files changed, 27 insertions(+), 7 deletions(-) Regards, Bin
Re: [PATCH v2 3/3] riscv: dts: starfive: Enable PCIe host controller
On 2023/3/25 21:22, Pali Rohár wrote:
> On Wednesday 08 March 2023 13:48:33 Minda Chen wrote:
>> From: Mason Huo
>>
>> Enable and add pinctrl configuration for PCIe host controller.
>> Also add JH7110 stg syscon configuration.
>>
>> Signed-off-by: Mason Huo
>> Signed-off-by: Minda Chen
>> ---
>> .../dts/jh7110-starfive-visionfive-2.dtsi | 99 +++
>> arch/riscv/dts/jh7110.dtsi| 75 ++
>> 2 files changed, 174 insertions(+)
>>
>> diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> index e669c2a26a..995f842a6b 100644
>> --- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
>> @@ -178,6 +178,87 @@
>> slew-rate = <0>;
>> };
>> };
>> +
>> +pcie0_perst_default: pcie0_perst_default {
>> +perst-pins {
>> +pinmux = > GPI_NONE)>;
>> +drive-strength = <2>;
>> +input-disable;
>> +input-schmitt-disable;
>> +slew-rate = <0>;
>> +};
>> +};
>> +
>> +pcie0_perst_active: pcie0_perst_active {
>> +perst-pins {
>> +pinmux = > GPI_NONE)>;
>> +drive-strength = <2>;
>> +input-disable;
>> +input-schmitt-disable;
>> +slew-rate = <0>;
>> +};
>> +};
> ...
>> + {
>> +pinctrl-names = "perst-default", "perst-active", "wake-default",
>> "clkreq-default";
>> +pinctrl-0 = <_perst_default>;
>> +pinctrl-1 = <_perst_active>;
>> +pinctrl-2 = <_wake_default>;
>> +pinctrl-3 = <_clkreq_default>;
>> +status = "disabled";
>> +};
>
> This is not correct declaration of PERST# signal. You should define in
> node "reset-gpios" property with plain gpio definition with
> active state.
>
> "reset-gpios" is standard PCIe property for controlling PERST# signal
> over GPIO. Look for example into drivers/pci/pci-aardvark.c and
> arch/arm/dts/armada-3720-espressobin.dtsi files how it is used.
OK, I will change this, thanks
Re: [PATCH v2 1/3] starfive: pci: Add StarFive JH7110 pcie driver
On 2023/3/25 20:31, Pali Rohár wrote: > On Friday 24 March 2023 18:57:33 Minda Chen wrote: >> On 2023/3/24 2:19, Pali Rohár wrote: >> > On Thursday 23 March 2023 18:51:38 Minda Chen wrote: >> >> On 2023/3/11 1:42, Pali Rohár wrote: >> >> > On Friday 10 March 2023 18:36:44 Minda Chen wrote: >> >> >> On 2023/3/8 15:31, Pali Rohár wrote: >> >> >> > Hello! See few comments below. >> >> >> > >> >> >> > On Wednesday 08 March 2023 13:48:31 Minda Chen wrote: >> >> >> >> From: Mason Huo >> >> >> >> >> >> >> >> Add pcie driver for StarFive JH7110, the driver depends on >> >> >> >> starfive gpio, pinctrl, clk and reset driver to do init. >> >> >> >> >> >> >> >> Several devices are tested: >> >> >> >> a) M.2 NVMe SSD >> >> >> >> b) Realtek 8169 Ethernet adapter. >> >> >> >> >> >> >> >> Signed-off-by: Mason Huo >> >> >> >> Signed-off-by: Minda Chen >> >> >> >> --- >> >> >> >> drivers/pci/Kconfig| 11 + >> >> >> >> drivers/pci/Makefile | 1 + >> >> >> >> drivers/pci/pcie_starfive_jh7110.c | 478 >> >> >> >> + >> >> >> >> 3 files changed, 490 insertions(+) >> >> >> >> create mode 100644 drivers/pci/pcie_starfive_jh7110.c >> >> >> >> >> >> >> >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig >> >> >> >> index ef328d2652..e7b0ff5bc3 100644 >> >> >> >> --- a/drivers/pci/Kconfig >> >> >> >> +++ b/drivers/pci/Kconfig >> >> >> >> @@ -374,4 +374,15 @@ config PCIE_UNIPHIER >> >> >> >> Say Y here if you want to enable PCIe controller support on >> >> >> >> UniPhier SoCs. >> >> >> >> >> >> >> >> +config PCIE_STARFIVE_JH7110 >> >> >> >> + bool "Enable Starfive JH7110 PCIe driver" >> >> >> >> + depends on STARFIVE_JH7110 >> >> >> >> + depends on PINCTRL_STARFIVE_JH7110 >> >> >> >> + depends on CLK_JH7110 >> >> >> >> + depends on RESET_JH7110 >> >> >> >> + default y >> >> >> >> + help >> >> >> >> + Say Y here if you want to enable PCIe controller support on >> >> >> >> + StarFive JH7110 SoC. >> >> >> >> + >> >> >> >> endif >> >> >> >> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile >> >> >> >> index 49506e7ba5..bbe3323bb5 100644 >> >> >> >> --- a/drivers/pci/Makefile >> >> >> >> +++ b/drivers/pci/Makefile >> >> >> >> @@ -49,3 +49,4 @@ obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o >> >> >> >> obj-$(CONFIG_PCIE_OCTEON) += pcie_octeon.o >> >> >> >> obj-$(CONFIG_PCIE_DW_SIFIVE) += pcie_dw_sifive.o >> >> >> >> obj-$(CONFIG_PCIE_UNIPHIER) += pcie_uniphier.o >> >> >> >> +obj-$(CONFIG_PCIE_STARFIVE_JH7110) += pcie_starfive_jh7110.o >> >> >> >> diff --git a/drivers/pci/pcie_starfive_jh7110.c >> >> >> >> b/drivers/pci/pcie_starfive_jh7110.c >> >> >> >> new file mode 100644 >> >> >> >> index 00..5ccef1ef02 >> >> >> >> --- /dev/null >> >> >> >> +++ b/drivers/pci/pcie_starfive_jh7110.c >> >> >> >> @@ -0,0 +1,478 @@ >> >> >> >> +// SPDX-License-Identifier: GPL-2.0+ >> >> >> >> +/* >> >> >> >> + * StarFive PLDA PCIe host controller driver >> >> >> >> + * >> >> >> >> + * Copyright (c) 2023 Starfive, Inc. >> >> >> >> + * Author: Mason Huo >> >> >> >> + * >> >> >> >> + */ >> >> >> >> + >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> +#include >> >> >> >> + >> >> >> >> +DECLARE_GLOBAL_DATA_PTR; >> >> >> >> + >> >> >> >> +#define GEN_SETTINGS 0x80 >> >> >> >> +#define PCIE_PCI_IDS 0x9C >> >> >> >> +#define PCIE_WINROM0xFC >> >> >> >> +#define PMSG_SUPPORT_RX0x3F0 >> >> >> >> +#define PCI_MISC 0xB4 >> >> >> >> + >> >> >> >> +#define PLDA_EP_ENABLE 0 >> >> >> >> +#define PLDA_RP_ENABLE 1 >> >> >> >> + >> >> >> >> +#define IDS_REVISION_ID0x02 >> >> >> >> +#define IDS_PCI_TO_PCI_BRIDGE 0x060400 >> >> >> >> +#define IDS_CLASS_CODE_SHIFT 8 >> >> >> > >> >> >> > Please do not duplicate standard PCI macros and constants. In U-Boot >> >> >> > they are already available in include/pci_ids.h header file. >> >> >> > >> >> >> ok >> >> >> >> +#define PREF_MEM_WIN_64_SUPPORTBIT(3) >> >> >> >> +#define PMSG_LTR_SUPPORT BIT(2) >> >> >> >> +#define PLDA_FUNCTION_DIS BIT(15) >> >> >> >> +#define PLDA_FUNC_NUM 4 >> >> >> >> +#define PLDA_PHY_FUNC_SHIFT9 >> >> >> >> + >> >> >> >> +#define XR3PCI_ATR_AXI4_SLV0 0x800 >> >> >> >> +#define XR3PCI_ATR_SRC_ADDR_LOW0x0 >> >> >> >> +#define XR3PCI_ATR_SRC_ADDR_HIGH 0x4 >> >> >> >> +#define XR3PCI_ATR_TRSL_ADDR_LOW 0x8 >> >> >> >> +#define XR3PCI_ATR_TRSL_ADDR_HIGH 0xc >> >> >>
DM SPI flash improvements
Hi Simon, I'm investigating a problem with the Thecus N2350 board that has SPI flash on controller 1, but not on controller 0. Booting with SPI SPL is not possible with CONFIG_SF_DEFAULT_BUS=1. Reference: https://lists.denx.de/pipermail/u-boot/2023-March/511517.html That led me to the drivers/mtd/spi/sf-uclass.c and drivers/spi/spi-uclass.c. And I found there are some problems in the spi_flash_probe(), as well as _spi_get_bus_and_cs(). But seeing your comment in the spi_flash_probe function header, I'm thinking perhaps I should not try to fix them. /* * TODO(s...@chromium.org): This is an old-style function. We should remove * it when all SPI flash drivers use dm */ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs, unsigned int max_hz, unsigned int spi_mode) Could you or Jagan clarify the TODO above meaning? Are we fully in DM SPI yet? If we are, should this be replaced with other means to probe the SPI bus? Or it should have been automatically probed by DM SPI infrastructure, and we just need to tag the SPI 1 DTS node with boot-phase? If that's the case then perhaps this function should be defined out with some configs wrapping. My current SPI configs: CONFIG_SPL_DM_SPI=y CONFIG_SPL_DM_SPI_FLASH=y # CONFIG_DM_HWSPINLOCK is not set CONFIG_DM_SPI_FLASH=y CONFIG_DM_SPI=y CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_SF_DEFAULT_MODE=0x0 # CONFIG_CMD_SF_TEST is not set CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_CS=0 Thanks, Tony
Re: [PATCH v2 2/2] rockchip: otp: fix misc_read() return values
Hi John, On 2023-03-20 19:39, Simon Glass wrote: > On Tue, 21 Mar 2023 at 06:18, John Keeping wrote: >> >> The documentation for misc_read() says: >> >> Return: number of bytes read if OK (may be 0 if EOF), -ve on error >> >> The Rockchip efuse driver implements this so it should return the number >> of bytes read rather than zero on success. Fix this so that the driver >> follows the usual contract for read operations. >> >> Signed-off-by: John Keeping >> --- >> v2: >> - New patch >> >> drivers/misc/rockchip-otp.c | 12 >> 1 file changed, 8 insertions(+), 4 deletions(-) > > Reviewed-by: Simon Glass Reviewed-by: Jonas Karlman Regards, Jonas
Re: [PATCH v2 1/2] rockchip: efuse: fix misc_read() return values
Hi John,
On 2023-03-20 19:39, Simon Glass wrote:
> On Tue, 21 Mar 2023 at 06:18, John Keeping wrote:
>>
>> The documentation for misc_read() says:
>>
>> Return: number of bytes read if OK (may be 0 if EOF), -ve on error
>>
>> The Rockchip efuse driver implements this so it should return the number
>> of bytes read rather than zero on success. Fix this so that the driver
>> follows the usual contract for read operations.
>>
>> Signed-off-by: John Keeping
>> ---
>> v2:
>> - Fix when block_size > 1 by moving the return value to the main
>> rockchip_efuse_read() wrapper and leaving the individual
>> implementations alone (Jonas)
>>
>> drivers/misc/rockchip-efuse.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> Reviewed-by: Simon Glass
With these changes I get the following trying to boot my boards
and having ROCKCHIP_EFUSE/OTP enabled.
initcall sequence 7ffcecc0 failed at call 00202610 (err=-1)
### ERROR ### Please RESET the board ###
We need a change to ret value handling in rockchip_cpuid_from_efuse in
arch/arm/mach-rockchip/misc.c to fix this, maybe something like:
/* read the cpu_id range from the efuses */
ret = misc_read(dev, cpuid_offset, cpuid, cpuid_length);
- if (ret) {
+ if (ret < 0) {
Reviewed-by: Jonas Karlman
Regards,
Jonas
Re: [PATCH 1/1] efi_loader: correct shortening of device-paths
On 3/26/23 12:45, Mark Kettenis wrote:
From: Heinrich Schuchardt
Date: Sun, 26 Mar 2023 12:25:54 +0200
We use short device-paths in boot options so that a file on a block device
can be found independent of the port into which the device is plugged.
Usb() device-path nodes only contain port and interface information and
therefore cannot identify a block device.
UsbWwi() device-path nodes contain the serial number of USB devices.
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h| 1 +
lib/efi_loader/efi_device_path.c | 21 ++---
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index c4512eeb86..dc6e5ce236 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -604,6 +604,7 @@ struct efi_device_path_acpi_path {
# define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR 0x0b
# define DEVICE_PATH_SUB_TYPE_MSG_UART 0x0e
# define DEVICE_PATH_SUB_TYPE_MSG_USB_CLASS 0x0f
+# define DEVICE_PATH_SUB_TYPE_MSG_USB_WWI 0x10
# define DEVICE_PATH_SUB_TYPE_MSG_SATA 0x12
# define DEVICE_PATH_SUB_TYPE_MSG_NVME 0x17
# define DEVICE_PATH_SUB_TYPE_MSG_URI0x18
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 288baa1ca7..9ed5e6273d 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -92,17 +92,13 @@ int efi_dp_match(const struct efi_device_path *a,
/**
* efi_dp_shorten() - shorten device-path
*
- * We can have device paths that start with a USB WWID or a USB Class node,
- * and a few other cases which don't encode the full device path with bus
- * hierarchy:
+ * When creating a short boot option we want to use a device-path that is
+ * independent of the location where the block device is plugged in.
*
- * * MESSAGING:USB_WWID
- * * MESSAGING:USB_CLASS
- * * MEDIA:FILE_PATH
- * * MEDIA:HARD_DRIVE
- * * MESSAGING:URI
+ * UsbWwi() nodes contain a serial number, hard drive paths a partition
+ * UUID. Both should be unique.
This sentence makes no sense. Do they contain a serial number, a hard
drive path *and* a partition UUID? But then all *three* should be
unique.
* UsbWWi() nodes contain a unique serial number
* HD() nodes contain a unique UUID.
Shortened device paths for files will only be created if the device path
is not a block device. Currently neither the eficonfig nor the efidebug
command allow to specify such a device path.
Best regards
Heinrich
*
- * See UEFI spec (section 3.1.2, about short-form device-paths)
+ * See UEFI spec, section 3.1.2 for "short-form device path".
*
* @dp: original device-path
* @Return: shortened device-path or NULL
@@ -110,12 +106,7 @@ int efi_dp_match(const struct efi_device_path *a,
struct efi_device_path *efi_dp_shorten(struct efi_device_path *dp)
{
while (dp) {
- /*
-* TODO: Add MESSAGING:USB_WWID and MESSAGING:URI..
-* in practice fallback.efi just uses MEDIA:HARD_DRIVE
-* so not sure when we would see these other cases.
-*/
- if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) ||
+ 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))
return dp;
--
2.39.2
Re: [v4 7/7] rockchip: rk3399: Drop altbootcmd
Hi Tom, On 2023-03-24 21:58, Tom Rini wrote: > The defined altbootcmd was specific to distro_bootcmd which is not > longer in use on these platforms, so drop it. > > Signed-off-by: Tom Rini > --- > Changes in v4: > - New patch > > Cc: Kever Yang > Cc: Simon Glass > Cc: Jonas Karlman > --- > include/configs/rk3399_common.h | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h > index 04dcbf20bcb5..96ba19c659bd 100644 > --- a/include/configs/rk3399_common.h > +++ b/include/configs/rk3399_common.h > @@ -52,10 +52,7 @@ > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > "partitions=" PARTS_DEFAULT \ > ROCKCHIP_DEVICE_SETTINGS \ > - "boot_targets=" BOOT_TARGETS "\0" \ > - "altbootcmd=" \ > - "setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \ > - "run distro_bootcmd\0" > + "boot_targets=" BOOT_TARGETS "\0" > > #endif > With this series my rk3399 boards stop trying to use distro_bootcmd and will now successfully boot using default bootcmd=bootflow scan. So for the entire series: Tested-by: Jonas Karlman Reviewed-by: Jonas Karlman Regards, Jonas
[RFC 7/7] efi_loader: use uclass_get_dp_node
Use function uclass_get_dp_node() to construct device paths.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 325 +++
1 file changed, 28 insertions(+), 297 deletions(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index d5cc495830..288baa1ca7 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -45,24 +45,6 @@ static const struct efi_device_path_vendor ROOT = {
.guid = U_BOOT_GUID,
};
-#if defined(CONFIG_MMC)
-/*
- * Determine if an MMC device is an SD card.
- *
- * @desc block device descriptor
- * Return: true if the device is an SD card
- */
-static bool is_sd(struct blk_desc *desc)
-{
- struct mmc *mmc = find_mmc_device(desc->devnum);
-
- if (!mmc)
- return false;
-
- return IS_SD(mmc) != 0U;
-}
-#endif
-
/*
* Iterate to next block in device-path, terminating (returning NULL)
* at /End* node.
@@ -500,87 +482,24 @@ bool efi_dp_is_multi_instance(const struct
efi_device_path *dp)
/* size of device-path not including END node for device and all parents
* up to the root device.
*/
-__maybe_unused static unsigned int dp_size(struct udevice *dev)
+__maybe_unused static size_t dp_size(struct udevice *dev)
{
- if (!dev || !dev->driver)
- return sizeof(ROOT);
-
- switch (device_get_uclass_id(dev)) {
- case UCLASS_ROOT:
- case UCLASS_SIMPLE_BUS:
- /* stop traversing parents at this point: */
- return sizeof(ROOT);
- case UCLASS_ETH:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_mac_addr);
- case UCLASS_BLK:
- switch (dev->parent->uclass->uc_drv->id) {
-#ifdef CONFIG_IDE
- case UCLASS_IDE:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_atapi);
-#endif
-#if defined(CONFIG_SCSI)
- case UCLASS_SCSI:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_scsi);
-#endif
-#if defined(CONFIG_MMC)
- case UCLASS_MMC:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_sd_mmc_path);
-#endif
-#if defined(CONFIG_AHCI) || defined(CONFIG_SATA)
- case UCLASS_AHCI:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_sata);
-#endif
-#if defined(CONFIG_NVME)
- case UCLASS_NVME:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_nvme);
-#endif
-#ifdef CONFIG_SANDBOX
- case UCLASS_HOST:
-/*
- * Sandbox's host device will be represented
- * as vendor device with extra one byte for
- * device number
- */
- return dp_size(dev->parent)
- + sizeof(struct efi_device_path_vendor) + 1;
-#endif
-#ifdef CONFIG_USB
- case UCLASS_MASS_STORAGE:
- return dp_size(dev->parent)
- + sizeof(struct efi_device_path_controller);
-#endif
-#ifdef CONFIG_VIRTIO_BLK
- case UCLASS_VIRTIO:
-/*
- * Virtio devices will be represented as a vendor
- * device node with an extra byte for the device
- * number.
- */
- return dp_size(dev->parent)
- + sizeof(struct efi_device_path_vendor) + 1;
-#endif
- default:
- return dp_size(dev->parent);
- }
-#if defined(CONFIG_MMC)
- case UCLASS_MMC:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_sd_mmc_path);
-#endif
- case UCLASS_MASS_STORAGE:
- case UCLASS_USB_HUB:
- return dp_size(dev->parent) +
- sizeof(struct efi_device_path_usb);
- default:
- /* just skip over unknown classes: */
- return dp_size(dev->parent);
+ unsigned int size = 0;
+ struct efi_device_path *dp;
+
+ if (!dev)
+ return 0;
+
+ if (dev->parent)
+ size = dp_size(dev->parent);
+
+ dp = uclass_get_dp_node(dev);
+ if (dp) {
+ size += dp->length;
+ efi_free_pool(dp);
}
+
+ return size;
}
/*
@@ -592,210 +511,22 @@ __maybe_unused static unsigned int dp_size(struct
udevice *dev)
*/
__maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
{
- if (!dev || !dev->driver)
- return buf;
+
[RFC 5/7] dm: implement get_dp_node for USB mass storage devices
Generate a Usb() node for USB mass storage devices.
Signed-off-by: Heinrich Schuchardt
---
common/usb_storage.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index ac64275773..03bc136156 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1534,6 +1535,35 @@ static int usb_mass_storage_probe(struct udevice *dev)
return ret;
}
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+struct efi_device_path *usb_storage_get_dp_node(struct udevice *dev)
+{
+ struct efi_device_path_usb *dp;
+
+ dp = efi_alloc(sizeof(struct efi_device_path_usb));
+ if (!dp)
+ return NULL;
+
+ switch (device_get_uclass_id(dev->parent)) {
+ case UCLASS_USB_HUB: {
+ struct usb_device *udev = dev_get_parent_priv(dev);
+
+ dp->parent_port_number = udev->portnr;
+ break;
+ }
+ default:
+ dp->parent_port_number = 0;
+ }
+
+ dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_USB;
+ dp->dp.length = sizeof(*dp);
+ dp->usb_interface = 0;
+
+ return >dp;
+}
+#endif
+
static const struct udevice_id usb_mass_storage_ids[] = {
{ .compatible = "usb-mass-storage" },
{ }
@@ -1552,6 +1582,9 @@ U_BOOT_DRIVER(usb_mass_storage) = {
UCLASS_DRIVER(usb_mass_storage) = {
.id = UCLASS_MASS_STORAGE,
.name = "usb_mass_storage",
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ .get_dp_node= usb_storage_get_dp_node,
+#endif
};
static const struct usb_device_id mass_storage_id_table[] = {
--
2.39.2
[RFC 6/7] dm: implement get_dp_node for MMC devices
Generate an SD() or eMMC() node for MMC devices.
Signed-off-by: Heinrich Schuchardt
---
drivers/mmc/mmc-uclass.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 01d9b0201f..4f85d80273 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -505,6 +506,27 @@ static int mmc_blk_probe(struct udevice *dev)
return 0;
}
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+struct efi_device_path *mmc_get_dp_node(struct udevice *dev)
+{
+ struct efi_device_path_sd_mmc_path *dp;
+ struct mmc *mmc = mmc_get_mmc_dev(dev);
+
+ dp = efi_alloc(sizeof(struct efi_device_path_sd_mmc_path));
+ if (!dp)
+ return NULL;
+
+ dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ dp->dp.sub_type = IS_SD(mmc) ?
+ DEVICE_PATH_SUB_TYPE_MSG_SD :
+ DEVICE_PATH_SUB_TYPE_MSG_MMC;
+ dp->dp.length = sizeof(*dp);
+ dp->slot_number = dev_seq(dev);
+
+ return >dp;
+}
+#endif
+
#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \
CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
@@ -547,4 +569,7 @@ UCLASS_DRIVER(mmc) = {
.name = "mmc",
.flags = DM_UC_FLAG_SEQ_ALIAS,
.per_device_auto= sizeof(struct mmc_uclass_priv),
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ .get_dp_node= mmc_get_dp_node,
+#endif
};
--
2.39.2
[RFC 4/7] dm: implement get_dp_node for USB hub devices
Generate a Usb() node for USB hub devices.
Signed-off-by: Heinrich Schuchardt
---
common/usb_hub.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 85c0822d8b..ccf9e16023 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -939,6 +940,35 @@ static int usb_hub_post_probe(struct udevice *dev)
return usb_hub_scan(dev);
}
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+struct efi_device_path *usb_hub_get_dp_node(struct udevice *dev)
+{
+ struct efi_device_path_usb *dp;
+
+ dp = efi_alloc(sizeof(struct efi_device_path_usb));
+ if (!dp)
+ return NULL;
+
+ switch (device_get_uclass_id(dev->parent)) {
+ case UCLASS_USB_HUB: {
+ struct usb_device *udev = dev_get_parent_priv(dev);
+
+ dp->parent_port_number = udev->portnr;
+ break;
+ }
+ default:
+ dp->parent_port_number = 0;
+ }
+
+ dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_USB;
+ dp->dp.length = sizeof(*dp);
+ dp->usb_interface = 0;
+
+ return >dp;
+}
+#endif
+
static const struct udevice_id usb_hub_ids[] = {
{ .compatible = "usb-hub" },
{ }
@@ -960,6 +990,9 @@ UCLASS_DRIVER(usb_hub) = {
.per_child_auto = sizeof(struct usb_device),
.per_child_plat_auto= sizeof(struct usb_dev_plat),
.per_device_auto= sizeof(struct usb_hub_device),
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ .get_dp_node= usb_hub_get_dp_node,
+#endif
};
static const struct usb_device_id hub_id_table[] = {
--
2.39.2
[RFC 3/7] dm: implement get_dp_node for block devices
Generate a Ctrl() node for block devices.
Signed-off-by: Heinrich Schuchardt
---
drivers/block/blk-uclass.c | 56 ++
1 file changed, 56 insertions(+)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index c69fc4d518..08202aaaba 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -779,9 +780,64 @@ static int blk_post_probe(struct udevice *dev)
return 0;
}
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+__maybe_unused
+static struct efi_device_path *blk_scsi_get_dp_node(struct udevice *dev)
+{
+ struct efi_device_path_scsi *dp;
+ struct blk_desc *desc = dev_get_uclass_plat(dev);
+
+ dp = efi_alloc(sizeof(struct efi_device_path_scsi));
+ if (!dp)
+ return NULL;
+
+ dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_SCSI;
+ dp->dp.length = sizeof(*dp);
+ dp->logical_unit_number = desc->lun;
+ dp->target_id = desc->target;
+
+ return >dp;
+}
+
+static struct efi_device_path *blk_get_dp_node(struct udevice *dev)
+{
+ struct efi_device_path_controller *dp;
+ struct blk_desc *desc = dev_get_uclass_plat(dev);
+ u32 controller_number;
+
+ switch (device_get_uclass_id(dev->parent)) {
+#if CONFIG_IS_ENABLED(SCSI)
+ case UCLASS_SCSI:
+ return blk_scsi_get_dp_node(dev);
+#endif
+ case UCLASS_MMC:
+ dp->controller_number = desc->hwpart;
+ break;
+ default:
+ dp->controller_number = desc->lun;
+ break;
+ }
+
+ dp = efi_alloc(sizeof(struct efi_device_path_controller));
+ if (!dp)
+ return NULL;
+
+ dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_CONTROLLER;
+ dp->dp.length = sizeof(*dp);
+ dp->controller_number = controller_number;
+
+ return >dp;
+}
+#endif
+
UCLASS_DRIVER(blk) = {
.id = UCLASS_BLK,
.name = "blk",
.post_probe = blk_post_probe,
.per_device_plat_auto = sizeof(struct blk_desc),
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ .get_dp_node= blk_get_dp_node,
+#endif
};
--
2.39.2
[RFC 1/7] dm: add get_dp_node() to struct uclass_driver
Currently the device paths don't match the dm tree.
We should create a device path node per dm tree node.
Signed-off-by: Heinrich Schuchardt
---
include/dm/uclass.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index ee15c92063..e11637ce4d 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
@@ -68,6 +69,7 @@ struct udevice;
* @child_post_probe: Called after a child in this uclass is probed
* @init: Called to set up the uclass
* @destroy: Called to destroy the uclass
+ * @get_dp_node: Get EFI device path node
* @priv_auto: If non-zero this is the size of the private data
* to be allocated in the uclass's ->priv pointer. If zero, then the uclass
* driver is responsible for allocating any data required.
@@ -99,6 +101,9 @@ struct uclass_driver {
int (*child_post_probe)(struct udevice *dev);
int (*init)(struct uclass *class);
int (*destroy)(struct uclass *class);
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+ struct efi_device_path *(*get_dp_node)(struct udevice *dev);
+#endif
int priv_auto;
int per_device_auto;
int per_device_plat_auto;
--
2.39.2
[RFC 2/7] dm: implement uclass_get_dp_node()
Provide a function to get the EFI device path node representing a
device.
If implemented, it invokes the uclass driver's get_dp_node() function.
Otherwise a vendor hardware node is created.
Signed-off-by: Heinrich Schuchardt
---
drivers/core/uclass.c | 26 ++
include/dm/uclass.h | 8
include/efi_loader.h | 7 +++
3 files changed, 41 insertions(+)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 1762a0796d..153c954ee3 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
#include
@@ -802,6 +803,31 @@ int uclass_pre_remove_device(struct udevice *dev)
}
#endif
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+struct efi_device_path *uclass_get_dp_node(struct udevice *dev)
+{
+ struct uclass *uc;
+ struct efi_device_path_uboot *dp;
+
+ uc = dev->uclass;
+ if (uc->uc_drv->get_dp_node)
+ return uc->uc_drv->get_dp_node(dev);
+
+ dp = efi_alloc(sizeof(struct efi_device_path_uboot));
+ if (!dp)
+ return NULL;
+
+ dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
+ dp->dp.length = sizeof(struct efi_device_path_uboot);
+ dp->guid = efi_u_boot_guid;
+ dp->uclass_id = uc->uc_drv->id;
+ dp->seq_ = dev->seq_;
+
+ return >dp;
+}
+#endif
+
int uclass_probe_all(enum uclass_id id)
{
struct udevice *dev;
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index e11637ce4d..f39dbac21d 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -503,3 +503,11 @@ int uclass_id_count(enum uclass_id id);
uclass_next_device())
#endif
+
+/**
+ * uclass_get_dp_node() - get EFI device path node for device
+ *
+ * @dev: device
+ * Return: device path node or NULL if out of memory
+ */
+struct efi_device_path *uclass_get_dp_node(struct udevice *dev);
diff --git a/include/efi_loader.h b/include/efi_loader.h
index cee04cbb9d..f111bc616d 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -22,6 +22,13 @@
struct blk_desc;
struct jmp_buf_data;
+struct efi_device_path_uboot {
+ struct efi_device_path dp;
+ efi_guid_t guid;
+ enum uclass_id uclass_id;
+ int seq_;
+} __packed;
+
static inline int guidcmp(const void *g1, const void *g2)
{
return memcmp(g1, g2, sizeof(efi_guid_t));
--
2.39.2
[RFC 0/7] efi_loader: move device-path node generation to DM
UEFI device-paths are used in the EFI world to depict the parent-child relationship between devices. No two device can have the same device-path. Currently we fail to generate unique devices-paths. The nodes in UEFI device paths should match the devices on the path to the DM root node. I have started drafting a solution. Several block device classes still need to be handled (IDE, NVMe, EFI, VirtIO). Also handling of PCI addresses is missing. But this series contains enough to see the direction of development. Heinrich Schuchardt (7): dm: add get_dp_node() to struct uclass_driver dm: implement uclass_get_dp_node() dm: implement get_dp_node for block devices dm: implement get_dp_node for USB hub devices dm: implement get_dp_node for USB mass storage devices dm: implement get_dp_node for MMC devices efi_loader: use uclass_get_dp_node common/usb_hub.c | 33 common/usb_storage.c | 33 drivers/block/blk-uclass.c | 56 ++ drivers/core/uclass.c| 26 +++ drivers/mmc/mmc-uclass.c | 25 +++ include/dm/uclass.h | 13 ++ include/efi_loader.h | 7 + lib/efi_loader/efi_device_path.c | 325 +++ 8 files changed, 221 insertions(+), 297 deletions(-) -- 2.39.2
[PATCH 1/1] cmd: CONFIG_CMD_SCSI depends on CONFIG_SCSI
Compiling with CONFIG_CMD_SCSI=y, CONFIG_SCSI results in cmd/scsi.c:46: undefined reference to `scsi_scan' Signed-off-by: Heinrich Schuchardt --- cmd/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 2caa4af71c..5c1b353c90 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1436,7 +1436,8 @@ config CMD_SATA config CMD_SCSI bool "scsi - Access to SCSI devices" - default y if SCSI + depends on SCSI + default y help This provides a 'scsi' command which provides access to SCSI (Small Computer System Interface) devices. The command provides a way to -- 2.39.2
[PATCH 1/2] ata: fix requirements for CONFIG_AHCI_PCI
Building with CONFIG_AHCI_PCI=y and CONFIG_SCSI_AHCI=n leads to drivers/ata/ahci-pci.o: in function `ahci_pci_probe': drivers/ata/ahci-pci.c:21: undefined reference to `ahci_probe_scsi_pci' Signed-off-by: Heinrich Schuchardt --- drivers/ata/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 3fe53d6d4f..2ab502c260 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -37,6 +37,7 @@ config AHCI_PCI bool "Support for PCI-based AHCI controller" depends on PCI depends on DM_SCSI + depends on SCSI_AHCI help Enables support for the PCI-based AHCI controller. -- 2.39.2
[PATCH 2/2] ata: don't use SYS_SCSI_MAX_SCSI_ID for SATA
CONFIG_SYS_SCSI_MAX_SCSI_ID is not defined if CONFIG_SCSI=n.
Signed-off-by: Heinrich Schuchardt
---
configs/controlcenterdc_defconfig | 1 +
configs/highbank_defconfig| 1 +
drivers/ata/Kconfig | 8
drivers/ata/ahci.c| 4 ++--
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/configs/controlcenterdc_defconfig
b/configs/controlcenterdc_defconfig
index 9c906edf1e..9940258881 100644
--- a/configs/controlcenterdc_defconfig
+++ b/configs/controlcenterdc_defconfig
@@ -72,6 +72,7 @@ CONFIG_ARP_TIMEOUT=200
CONFIG_NET_RETRY_COUNT=50
CONFIG_USE_ROOTPATH=y
CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_SYS_SATA_MAX_PORTS=2
CONFIG_SCSI_AHCI=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig
index 49339d9a55..f21a0f3d86 100644
--- a/configs/highbank_defconfig
+++ b/configs/highbank_defconfig
@@ -30,6 +30,7 @@ CONFIG_RESET_TO_RETRY=y
CONFIG_MISC_INIT_R=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_ENV_IS_IN_NVRAM=y
+CONFIG_SYS_SATA_MAX_PORTS=5
CONFIG_SCSI_AHCI=y
CONFIG_SYS_64BIT_LBA=y
CONFIG_BOOTCOUNT_LIMIT=y
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2ab502c260..049f7efd10 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -20,6 +20,14 @@ config SATA
See also CMD_SATA which provides command-line support.
+config SYS_SATA_MAX_PORTS
+ int "Maximum supported SATA ports"
+ depends on SCSI_AHCI && !DM_SCSI
+ default 1
+ help
+ Sets the maximum number of ports to scan when looking for devices.
+ Ports from 0 to (this value - 1) are scanned.
+
config LIBATA
bool
help
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 272c48b8e5..6998b82aa5 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -211,8 +211,8 @@ static int ahci_host_init(struct ahci_uc_priv *uc_priv)
uc_priv->cap, uc_priv->port_map, uc_priv->n_ports);
#if !defined(CONFIG_DM_SCSI)
- if (uc_priv->n_ports > CONFIG_SYS_SCSI_MAX_SCSI_ID)
- uc_priv->n_ports = CONFIG_SYS_SCSI_MAX_SCSI_ID;
+ if (uc_priv->n_ports > CONFIG_SYS_SATA_MAX_PORTS)
+ uc_priv->n_ports = CONFIG_SYS_SATA_MAX_PORTS;
#endif
for (i = 0; i < uc_priv->n_ports; i++) {
--
2.39.2
[PATCH 0/2] ata: fix build failures for SATA w/o SCSI
Trying to compile U-Boot for SATA but wo/o SCSI leads to multiple build failures. Gitlab CI showed no problems for these patches: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15763 Heinrich Schuchardt (2): ata: fix requirements for CONFIG_AHCI_PCI ata: don't use SYS_SCSI_MAX_SCSI_ID for SATA configs/controlcenterdc_defconfig | 1 + configs/highbank_defconfig| 1 + drivers/ata/Kconfig | 9 + drivers/ata/ahci.c| 4 ++-- 4 files changed, 13 insertions(+), 2 deletions(-) -- 2.39.2
[PATCH 1/1] scsi: typo supporedt
%s/supporedt/supported/
Fixes: edca8cf72130 ("Convert CONFIG_SCSI_AHCI_PLAT et al to Kconfig")
Signed-off-by: Heinrich Schuchardt
---
drivers/scsi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index ad484ce8e8..a8014129d3 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -26,7 +26,7 @@ config SCSI_AHCI_PLAT
This is deprecated. An AHCI driver should be provided instead.
config SYS_SCSI_MAX_SCSI_ID
- int "Maximum supporedt SCSI ID"
+ int "Maximum supported SCSI ID"
default 1
help
Sets the maximum number of SCSI IDs to scan when looking for devices.
--
2.39.2
Re: NEXT: Pull request for efi-next-20230325
On Sat, Mar 25, 2023 at 05:10:08PM +0100, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit 884d626d8357853c012d535bf26c143bb7b5e6a5: > > Merge branch '2023-03-22-assorted-minor-code-cleanups' into next > (2023-03-22 20:57:39 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-next-20230325 > > for you to fetch changes up to 93e3364804ffd4a5d4a0df9c750a1859f9fe298b: > > cmd: bootefi: allocate device-tree copy from high memory (2023-03-25 > 12:04:49 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15736 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] travis-ci: Add m68k M5208EVBE machine
On Mon, 20 Mar 2023 20:46:47 +0100, Marek Vasut wrote: > Add m68k M5208EVBE machine configured to test U-Boot m68k support. > > Applied, thanks! [1/1] travis-ci: Add m68k M5208EVBE machine commit: 3f604a1b68a07e6c20f617c38fc849eb796f9af0 Best regards, -- Tom
Re: Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail
On 2023-03-24 13:58, Vagrant Cascadian wrote:
> Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson)
> platforms and u-boot list to CC.
>
> On 2023-03-22, Salvatore Bonaccorso wrote:
> > Thanks for tracking this down. I would like to loop in Masahiro and
> > upstream to see if something can/should be done on upstream side.
> >
> > Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
> > special treatment for the link order of head.o") (which got backported
> > as well to 6.1.14) caused the vmlinuz size to icrease significantly,
> > causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
> > parameters previously working. Full quoting the Debian report below
>
> In general it would be nice to not have the kernel grow nearly 25% in
> size from a single commit; was that an expected outcome from the above
> upstream change? Was the "special treament" originally done to keep the
> kernel size down?
This is currently being tracked [1], but the issue seems to be linked to
the version of the tools used in Debian, and the fact that we build our
kernels with BTF support, so the issue is likely to be difficult to find.
[1] https://lore.kernel.org/linux-arm-kernel/zbovcrmxjk7np...@aurel32.net/
> As for u-boot, It seems u-boot might need to update the various load
> addresses for the kernel, device tree and ramdisk at some point
> regardless of weather this particular issue gets fixed in the kernel, as
> the kernel will likely continue to grow a bit over time...
Yes that's probably a sane thing to do, at least in Debian.
> Aurelien Jarno included a patch referenced below which bumps the
> tolerances in u-boot from 36MB to 42MB.
>
>
> > On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
> >> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> >> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> >> to boot with:
> >>
> >> | 40175552 bytes read in 1695 ms (23 MiB/s)
> >> | 43794863 bytes read in 1817 ms (23 MiB/s)
> >> | Moving Image from 0x8 to 0x20, end=299
> >> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> >>
> >> I tracked the issue to a significant increase of the kernel size between
> >> version 6.1.12-1 and 6.15-1:
> >>
> >> | 31492 /boot/vmlinuz-6.1.0-5-arm64
> >> | 39236 /boot/vmlinuz-6.1.0-6-arm64
> >>
> >> This is more than the 36MB that is allowed by u-boot with the default
> >> load addresses. A workaround is to shift the load addresses at the
> >> u-boot level as in the attached patch.
> >>
> >> I have tracked issue on the upstream kernel side to the following commit
> >> on the stable tree:
> >>
> >> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> >> | Author: Masahiro Yamada
> >> | Date: Thu Oct 13 08:35:00 2022 +0900
> >> |
> >> | arm64: remove special treatment for the link order of head.o
> >> |
> >> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> >> |
> >> | In the previous discussion (see the Link tag), Ard pointed out that
> >> | arm/arm64/kernel/head.o does not need any special treatment - the
> >> only
> >> | piece that must appear right at the start of the binary image is the
> >> | image header which is emitted into .head.text.
> >> |
> >> | The linker script does the right thing to do. The build system does
> >> | not need to manipulate the link order of head.o.
> >> |
> >> | Link:
> >> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> >> | Suggested-by: Ard Biesheuvel
> >> | Signed-off-by: Masahiro Yamada
> >> | Reviewed-by: Nicolas Schier
> >> | Link:
> >> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> >> | Signed-off-by: Will Deacon
> >> | Signed-off-by: Tom Saeger
> >> | Signed-off-by: Greg Kroah-Hartman
> >>
> >> The problem is still reproducible on Linus' master.
> >>
> >> I am reporting the bug to the linux package as I believed there is no
> >> real reason for such an increase in the kernel size. In case I missed
> >> something and this is actually wanted, the bug can be reassigned to the
> >> u-boot package.
> >>
> >> Regards
> >> Aurelien
> >
> >> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
> >> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
> >> @@ -95,32 +95,32 @@
> >> * text_offset bytes (specified in the header of the Image) into a 2MB
> >> * boundary. The 'booti' command relocates the image if necessary.
> >> Linux uses
> >> * a default text_offset of 0x8. In summary, loading at 0x8
> >> - * satisfies all these constraints and reserving memory up to 0x0240
> >> - * permits fairly large (roughly 36M) kernels.
> >> + * satisfies all these constraints and reserving memory up to 0x02a0
> >> + * permits fairly large (roughly 42M) kernels.
> >> *
> >> * scriptaddr and pxefile_addr_r can be pretty much anywhere
Re: [PATCH 1/1] efi_loader: correct shortening of device-paths
> From: Heinrich Schuchardt
> Date: Sun, 26 Mar 2023 12:25:54 +0200
>
> We use short device-paths in boot options so that a file on a block device
> can be found independent of the port into which the device is plugged.
>
> Usb() device-path nodes only contain port and interface information and
> therefore cannot identify a block device.
> UsbWwi() device-path nodes contain the serial number of USB devices.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_api.h| 1 +
> lib/efi_loader/efi_device_path.c | 21 ++---
> 2 files changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index c4512eeb86..dc6e5ce236 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -604,6 +604,7 @@ struct efi_device_path_acpi_path {
> # define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR 0x0b
> # define DEVICE_PATH_SUB_TYPE_MSG_UART 0x0e
> # define DEVICE_PATH_SUB_TYPE_MSG_USB_CLASS 0x0f
> +# define DEVICE_PATH_SUB_TYPE_MSG_USB_WWI 0x10
> # define DEVICE_PATH_SUB_TYPE_MSG_SATA 0x12
> # define DEVICE_PATH_SUB_TYPE_MSG_NVME 0x17
> # define DEVICE_PATH_SUB_TYPE_MSG_URI 0x18
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index 288baa1ca7..9ed5e6273d 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -92,17 +92,13 @@ int efi_dp_match(const struct efi_device_path *a,
> /**
> * efi_dp_shorten() - shorten device-path
> *
> - * We can have device paths that start with a USB WWID or a USB Class node,
> - * and a few other cases which don't encode the full device path with bus
> - * hierarchy:
> + * When creating a short boot option we want to use a device-path that is
> + * independent of the location where the block device is plugged in.
> *
> - * * MESSAGING:USB_WWID
> - * * MESSAGING:USB_CLASS
> - * * MEDIA:FILE_PATH
> - * * MEDIA:HARD_DRIVE
> - * * MESSAGING:URI
> + * UsbWwi() nodes contain a serial number, hard drive paths a partition
> + * UUID. Both should be unique.
This sentence makes no sense. Do they contain a serial number, a hard
drive path *and* a partition UUID? But then all *three* should be
unique.
> *
> - * See UEFI spec (section 3.1.2, about short-form device-paths)
> + * See UEFI spec, section 3.1.2 for "short-form device path".
> *
> * @dp: original device-path
> * @Return: shortened device-path or NULL
> @@ -110,12 +106,7 @@ int efi_dp_match(const struct efi_device_path *a,
> struct efi_device_path *efi_dp_shorten(struct efi_device_path *dp)
> {
> while (dp) {
> - /*
> - * TODO: Add MESSAGING:USB_WWID and MESSAGING:URI..
> - * in practice fallback.efi just uses MEDIA:HARD_DRIVE
> - * so not sure when we would see these other cases.
> - */
> - if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) ||
> + 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))
> return dp;
> --
> 2.39.2
>
>
[PATCH 1/1] efi_loader: correct shortening of device-paths
We use short device-paths in boot options so that a file on a block device
can be found independent of the port into which the device is plugged.
Usb() device-path nodes only contain port and interface information and
therefore cannot identify a block device.
UsbWwi() device-path nodes contain the serial number of USB devices.
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h| 1 +
lib/efi_loader/efi_device_path.c | 21 ++---
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index c4512eeb86..dc6e5ce236 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -604,6 +604,7 @@ struct efi_device_path_acpi_path {
# define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR0x0b
# define DEVICE_PATH_SUB_TYPE_MSG_UART0x0e
# define DEVICE_PATH_SUB_TYPE_MSG_USB_CLASS 0x0f
+# define DEVICE_PATH_SUB_TYPE_MSG_USB_WWI 0x10
# define DEVICE_PATH_SUB_TYPE_MSG_SATA0x12
# define DEVICE_PATH_SUB_TYPE_MSG_NVME0x17
# define DEVICE_PATH_SUB_TYPE_MSG_URI 0x18
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 288baa1ca7..9ed5e6273d 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -92,17 +92,13 @@ int efi_dp_match(const struct efi_device_path *a,
/**
* efi_dp_shorten() - shorten device-path
*
- * We can have device paths that start with a USB WWID or a USB Class node,
- * and a few other cases which don't encode the full device path with bus
- * hierarchy:
+ * When creating a short boot option we want to use a device-path that is
+ * independent of the location where the block device is plugged in.
*
- * * MESSAGING:USB_WWID
- * * MESSAGING:USB_CLASS
- * * MEDIA:FILE_PATH
- * * MEDIA:HARD_DRIVE
- * * MESSAGING:URI
+ * UsbWwi() nodes contain a serial number, hard drive paths a partition
+ * UUID. Both should be unique.
*
- * See UEFI spec (section 3.1.2, about short-form device-paths)
+ * See UEFI spec, section 3.1.2 for "short-form device path".
*
* @dp:original device-path
* @Return:shortened device-path or NULL
@@ -110,12 +106,7 @@ int efi_dp_match(const struct efi_device_path *a,
struct efi_device_path *efi_dp_shorten(struct efi_device_path *dp)
{
while (dp) {
- /*
-* TODO: Add MESSAGING:USB_WWID and MESSAGING:URI..
-* in practice fallback.efi just uses MEDIA:HARD_DRIVE
-* so not sure when we would see these other cases.
-*/
- if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) ||
+ 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))
return dp;
--
2.39.2
[PATCH] boards: amlogic: switch LibreTech-CC v2 and WeTek Core2 to EE powerdomain
The LibreTech-CC (LePotato) v2 and WeTek Core2 boards are still using the older GX VPU powerdomain driver. Update their configs to use the newer EE driver like other Amlogic boards [0]. [0] https://lore.kernel.org/all/20201106101901.2472557-5-narmstr...@baylibre.com/T/#u Signed-off-by: Christian Hewitt --- configs/libretech-cc_v2_defconfig | 2 +- configs/wetek-core2_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/libretech-cc_v2_defconfig b/configs/libretech-cc_v2_defconfig index 30b1651554..ea71f055d9 100644 --- a/configs/libretech-cc_v2_defconfig +++ b/configs/libretech-cc_v2_defconfig @@ -51,7 +51,7 @@ CONFIG_MESON_GXL_USB_PHY=y CONFIG_PINCTRL=y CONFIG_PINCTRL_MESON_GXL=y CONFIG_POWER_DOMAIN=y -CONFIG_MESON_GX_VPU_POWER_DOMAIN=y +CONFIG_MESON_EE_POWER_DOMAIN=y CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_DEBUG_UART_SKIP_INIT=y CONFIG_MESON_SERIAL=y diff --git a/configs/wetek-core2_defconfig b/configs/wetek-core2_defconfig index f5149fc002..07d2587f77 100644 --- a/configs/wetek-core2_defconfig +++ b/configs/wetek-core2_defconfig @@ -44,7 +44,7 @@ CONFIG_MESON_GXL_USB_PHY=y CONFIG_PINCTRL=y CONFIG_PINCTRL_MESON_GXL=y CONFIG_POWER_DOMAIN=y -CONFIG_MESON_GX_VPU_POWER_DOMAIN=y +CONFIG_MESON_EE_POWER_DOMAIN=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DEBUG_UART_ANNOUNCE=y -- 2.34.1
