Re: [PATCH 00/16] LoongArch initial support
On Thu, 23 May 2024 at 16:39, Jiaxun Yang wrote: > > > > 在2024年5月23日五月 下午4:25，Tom Rini写道： > > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote: > > > >> Hi all, > >> > >> Sorry for flooding the mailing list recently, yet another huge RFC series > >> ahead. > >> > >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as > >> suggested > >> by Heinrich. > > > > My big feedback here, and it applies to all of your other series as > > well, is to please update CI to make use of and test this. On the Docker > > side, update tools/docker/Dockerfile as needed. For Azure, you can tell > > it to use a different image and then follow the documentation on > > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab > > you can at least use their "linter" to make sure that your additions > > have the correct syntax. Thanks. > > Hi Tom, > > Thanks for the feedback, I thought CI is for custodians only :-) Well when this lands you'll become a custodian ;-) > Do you mean I should include azure/gitlab pipeline file to create > pipeline for those new qemu targets? > > Thanks > > > > > -- > > Tom > > > > 附件: > > * signature.asc > > -- > - Jiaxun
Re: [PATCH 10/15] test: dm: dsa, eth: disable tests when CONFIG_NET_LWIP=y
On Wed, 22 May 2024 at 19:08, Ilias Apalodimas
wrote:
>
> Hi Jerome,
>
> On Wed, 22 May 2024 at 19:04, Jerome Forissier
> wrote:
> >
> > Some sandbox tests make strong assumptions on how the network stack is
> > implemented. For example, the ping tests assume that ARP resolution
> > occurs upon sending out the ICMP packet. This is not always the case
> > with the lwIP stack which can cache ARP information.
> > Therefore, disable these tests when CONFIG_NET_LWIP is enabled.
>
> Is the ARP Caching the only issue?
> U-Boot isn't supposed to use the network stack that much, so it might
> be a better idea to disable arp-caching in LWIP (assuming it's
> doable). We might even get a few size of bytes back
You end up hitting an arp cache a lot because of references to say
DNS, IP GW or server end point for downloading, so while at first it
doesn't appear you'd need it you also don't want to do ARP for every
packet sent.
Peter
> Cheers
> /Ilias
> >
> > Signed-off-by: Jerome Forissier
> > ---
> > test/dm/dsa.c | 2 ++
> > test/dm/eth.c | 4
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/test/dm/dsa.c b/test/dm/dsa.c
> > index c857106eaf..147e2a4afe 100644
> > --- a/test/dm/dsa.c
> > +++ b/test/dm/dsa.c
> > @@ -59,6 +59,7 @@ static int dm_test_dsa_probe(struct unit_test_state *uts)
> >
> > DM_TEST(dm_test_dsa_probe, UT_TESTF_SCAN_FDT);
> >
> > +#if !defined(CONFIG_NET_LWIP)
> > /* This test sends ping requests with the local address through each DSA
> > port
> > * via the sandbox DSA master Eth.
> > */
> > @@ -80,3 +81,4 @@ static int dm_test_dsa(struct unit_test_state *uts)
> > }
> >
> > DM_TEST(dm_test_dsa, UT_TESTF_SCAN_FDT);
> > +#endif /* !defined(CONFIG_NET_LWIP) */
> > diff --git a/test/dm/eth.c b/test/dm/eth.c
> > index bb3dcc6b95..cf97b1c1ab 100644
> > --- a/test/dm/eth.c
> > +++ b/test/dm/eth.c
> > @@ -170,6 +170,7 @@ static int dm_test_ip6_make_lladdr(struct
> > unit_test_state *uts)
> > DM_TEST(dm_test_ip6_make_lladdr, UT_TESTF_SCAN_FDT);
> > #endif
> >
> > +#if !defined(CONFIG_NET_LWIP)
> > static int dm_test_eth(struct unit_test_state *uts)
> > {
> > net_ping_ip = string_to_ip("1.1.2.2");
> > @@ -298,6 +299,7 @@ static int dm_test_eth_act(struct unit_test_state *uts)
> > return 0;
> > }
> > DM_TEST(dm_test_eth_act, UT_TESTF_SCAN_FDT);
> > +#endif /* !CONFIG_NET_LWIP */
> >
> > /* Ensure that all addresses are loaded properly */
> > static int dm_test_ethaddr(struct unit_test_state *uts)
> > @@ -332,6 +334,7 @@ static int dm_test_ethaddr(struct unit_test_state *uts)
> > }
> > DM_TEST(dm_test_ethaddr, UT_TESTF_SCAN_FDT);
> >
> > +#if !defined(CONFIG_NET_LWIP)
> > /* The asserts include a return on fail; cleanup in the caller */
> > static int _dm_test_eth_rotate1(struct unit_test_state *uts)
> > {
> > @@ -616,6 +619,7 @@ static int dm_test_eth_async_ping_reply(struct
> > unit_test_state *uts)
> > }
> >
> > DM_TEST(dm_test_eth_async_ping_reply, UT_TESTF_SCAN_FDT);
> > +#endif /* !CONFIG_NET_LWIP */
> >
> > #if IS_ENABLED(CONFIG_IPV6_ROUTER_DISCOVERY)
> >
> > --
> > 2.40.1
> >
Re: [PATCH 0/6] power: pmic: sunxi: consolidate AXP SPL drivers
On Mon, 20 May 2024 at 15:18, Andre Przywara wrote:
>
> On Mon, 20 May 2024 13:48:41 +0100
> Peter Robinson wrote:
>
> Hi Peter,
>
> thanks for having a look!
>
> > Hi Andre,
> >
> > > this is the first series in an attempt to clean up the X-Powers AXP PMIC
> > > drivers used by the SPL for sunxi boards. So far we have a separate
> > > driver file for each AXP variant, but the code was largely the same,
> > > just differing by the regulator ranges.
> > >
> > > This adds a new generic driver, which reads the regulator description
> > > from an array of structs. This is similar to how the DM AXP driver used
> > > for U-Boot proper works, but is simplified, since we won't need the full
> > > feature set for the SPL, and we want to keep the code size small.
> >
> > Overall seems a reasonable approach, would it make sense to put the
> > regulator descriptions in a file that could be shared between this and
> > the DM driver so the information isn't duplicated and hence may
> > diverge over time with things like copy/paste errors?
>
> Yes, I thought about it, but it gets nasty:
> - The SPL should only have the regulator descriptions for the *one*
> selected AXP chip, whereas the DM driver can afford to describe all
> regulators and select the right ones via the compatible at runtime. This
> is to conserve memory for the SPL.
> - The SPL should only be interested in the DC/DC buck converters, we don't
> really need any LDOs. Again saves memory.
> - Each regulator entry for the SPL should be as small as possible, we don't
> want and need the regulator name, for instance, or the table pointer.
> Again to save memory.
>
> Currently the array for the three AXP313 regulators in the SPL is exactly
> 30 bytes long; in the DM driver, just for the small AXP313: 192 bytes. The
> difference is even more pronounced for the larger AXPs.
>
> I am hopeful there might be some macro magic to express this, like:
> static const struct axp_regulator_plat axp313_regulators[] = {
>SPL( "dcdc1", 0x10, BIT(0), 0x13, 0x7f, 500, 1540, 10, 70 )
>SPL( "dcdc2", 0x10, BIT(1), 0x14, 0x7f, 500, 1540, 10, 70 )
>SPL( "dcdc3", 0x10, BIT(2), 0x15, 0x7f, 500, 1840, 10, 70 )
> PROPER( "aldo1", 0x10, BIT(3), 0x16, 0x1f, 500, 3500, 100, NA )
> PROPER( "dldo1", 0x10, BIT(4), 0x17, 0x1f, 500, 3500, 100, NA )
> {}
> };
> But we still need something to avoid the array altogether when another AXP
> is selected, which might require #ifdefs.
> So it might be possible, but the devil is probably in the details.
>
> For now I just wanted to avoid adding more AXP driver files to
> the drivers/power directory, so I consider this a future optimisation.
That all makes sense, thanks for the great explanation!
> Happy to take patches :-D
>
> Cheers,
> Andre
>
> > Peter
> >
> > > To help bisect-ability, and to simplify review, each of the simpler AXP
> > > drivers covered by this approach is handled in a separate patch.
> > > We just convert the AXP313, AXP305, AXP717 for now, and on the way add
> > > support for the AXP707, just because it's now very easy, and we will
> > > need it soon enough.
> > > The other AXP SPL drivers are more complex, and support more regulators,
> > > but my hunch is that we really just need the DC/DC converters in the
> > > SPL. However I need to prove and test this, so I will convert the other
> > > AXP chips later.
> > >
> > > Please have a look and comment whether the approach in general is a good
> > > idea.
> > >
> > > Cheers,
> > > Andre
> > >
> > > Andre Przywara (6):
> > > power: pmic: sunxi: only build AXP drivers for SPL
> > > power: pmic: sunxi: introduce generic SPL AXP DC/DC driver
> > > power: pmic: sunxi: replace AXP717 SPL driver
> > > power: pmic: sunxi: use generic AXP SPL driver for AXP313
> > > power: pmic: sunxi: use generic AXP SPL driver for AXP305
> > > power: pmic: sunxi: add AXP707 support
> > >
> > > drivers/power/Makefile | 8 +-
> > > drivers/power/axp305.c | 82 --
> > > drivers/power/axp313.c | 133 -
> > > drivers/power/axp717.c | 92
> > > drivers/power/axp_spl.c | 184
> > > 5 files changed, 189 insertions(+), 310 deletions(-)
> > > delete mode 100644 drivers/power/axp305.c
> > > delete mode 100644 drivers/power/axp313.c
> > > delete mode 100644 drivers/power/axp717.c
> > > create mode 100644 drivers/power/axp_spl.c
> > >
> > > --
> > > 2.35.8
> > >
>
Re: [PATCH 0/6] power: pmic: sunxi: consolidate AXP SPL drivers
Hi Andre, > this is the first series in an attempt to clean up the X-Powers AXP PMIC > drivers used by the SPL for sunxi boards. So far we have a separate > driver file for each AXP variant, but the code was largely the same, > just differing by the regulator ranges. > > This adds a new generic driver, which reads the regulator description > from an array of structs. This is similar to how the DM AXP driver used > for U-Boot proper works, but is simplified, since we won't need the full > feature set for the SPL, and we want to keep the code size small. Overall seems a reasonable approach, would it make sense to put the regulator descriptions in a file that could be shared between this and the DM driver so the information isn't duplicated and hence may diverge over time with things like copy/paste errors? Peter > To help bisect-ability, and to simplify review, each of the simpler AXP > drivers covered by this approach is handled in a separate patch. > We just convert the AXP313, AXP305, AXP717 for now, and on the way add > support for the AXP707, just because it's now very easy, and we will > need it soon enough. > The other AXP SPL drivers are more complex, and support more regulators, > but my hunch is that we really just need the DC/DC converters in the > SPL. However I need to prove and test this, so I will convert the other > AXP chips later. > > Please have a look and comment whether the approach in general is a good > idea. > > Cheers, > Andre > > Andre Przywara (6): > power: pmic: sunxi: only build AXP drivers for SPL > power: pmic: sunxi: introduce generic SPL AXP DC/DC driver > power: pmic: sunxi: replace AXP717 SPL driver > power: pmic: sunxi: use generic AXP SPL driver for AXP313 > power: pmic: sunxi: use generic AXP SPL driver for AXP305 > power: pmic: sunxi: add AXP707 support > > drivers/power/Makefile | 8 +- > drivers/power/axp305.c | 82 -- > drivers/power/axp313.c | 133 - > drivers/power/axp717.c | 92 > drivers/power/axp_spl.c | 184 > 5 files changed, 189 insertions(+), 310 deletions(-) > delete mode 100644 drivers/power/axp305.c > delete mode 100644 drivers/power/axp313.c > delete mode 100644 drivers/power/axp717.c > create mode 100644 drivers/power/axp_spl.c > > -- > 2.35.8 >
[PATCH] Revert "arm: dts: bcm283x: Add minimal smbios information"
This reverts commit 33041972727e84d3f95e26c83322521f61827584.
With the ability to generate this SMBIOS details autmotically the
small amount of details that this patch provided are generated
automatically so this is now obsolete so we can just drop it.
Signed-off-by: Peter Robinson
---
arch/arm/dts/bcm283x-u-boot.dtsi | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi b/arch/arm/dts/bcm283x-u-boot.dtsi
index 8c17c6f6a52..ec0f93dd850 100644
--- a/arch/arm/dts/bcm283x-u-boot.dtsi
+++ b/arch/arm/dts/bcm283x-u-boot.dtsi
@@ -6,25 +6,6 @@
* (C) Copyright 2016 Fabian Vogt
*/
-/ {
- smbios {
- compatible = "u-boot,sysinfo-smbios";
- smbios {
- system {
- manufacturer = "raspberrypi";
- product = "rpi";
- };
- baseboard {
- manufacturer = "raspberrypi";
- product = "rpi";
- };
- chassis {
- manufacturer = "raspberrypi";
- };
- };
- };
-};
-
{
skip-init;
bootph-all;
--
2.45.0
Pull request: rpi-2024.07 rc3
Hi Tom, Please pull the updates for the Raspberry Pi: Updates for RPi for 2024.07: - Switch to OF_HAS_PRIOR_STAGE by default The following changes since commit 52835266d3e933656a217233eaf672dd9ccd7352: Prepare v2024.07-rc2 (2024-05-06 13:54:17 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-2024.07-rc3
Re: [PATCH v2 00/28] [RFC] Integrate MbedTLS v3.6 LTS with U-Boot
On Tue, 7 May 2024 at 19:30, Raymond Mao wrote: > > Integrate MbedTLS v3.6 LTS (currently v3.6.0-RC1) with U-Boot. > > Motivations: > > 1. MbedTLS is well maintained with LTS versions. > 2. LWIP is integrated with MbedTLS and easily to enable HTTPS. > 3. MbedTLS recently switched license back to GPLv2. > > Prerequisite: > - > This patch series requires mbedtls git repo to be added as a > subtree to the main U-Boot repo via: > $ git subtree add --prefix lib/mbedtls/external/mbedtls \ > https://github.com/Mbed-TLS/mbedtls.git \ > v3.6.0 --squash > Moreover, due to the Windows-style files from mbedtls git repo, > we need to convert the CRLF endings to LF and do a commit manually: > $ git add --renormalize . > $ git commit > > New Kconfig options: > > `MBEDTLS_LIB` is for MbedTLS general switch. > `MBEDTLS_LIB_CRYPTO` is for replacing original digest and crypto libs with > MbedTLS. > `MBEDTLS_LIB_X509` is for replacing original X509, PKCS7, MSCode, ASN1, > and Pubkey parser with MbedTLS. > `MBEDTLS_LIB_TLS` is for SSL/TLS (Disabled until LWIP port for MbedTLS is > ready) > In this patch set, MBEDTLS_LIB, MBEDTLS_LIB_CRYPTO and MBEDTLS_LIB_X509 > are by default enabled in qemu_arm64_defconfig for testing purpose. > > Patches for external MbedTLS project: > - > Since U-Boot uses Microsoft Authentication Code to verify PE/COFFs > executables which is not supported by MbedTLS at the moment, > addtional patches for MbedTLS are created to adapt with the EFI loader: > 1. Decoding of Microsoft Authentication Code. > 2. Decoding of PKCS#9 Authenticate Attributes. > 3. Extending MbedTLS PKCS#7 lib to support multiple signer's certificates. > 4. MbedTLS native test suites for PKCS#7 signer's info. > All above 4 patches (tagged with `mbedtls/external`) are submitted to > MbedTLS project and being reviewed, eventually they should be part of > MbedTLS release. > See below PR for the reference: > https://github.com/Mbed-TLS/mbedtls/pull/9001 > > Miscellaneous: > -- > Minor fixes for arm EFI linker script for testing EFI secure boot. > > Optimized MbedTLS library size by tailoring the config file. > After disabling all unnecessary features for EFI loader, enabling MbedTLS > increases U-Boot size by 6.03% (V1). > For V2, this figure drops to about 4.66% by completely replacing > original libs (rsa, asn1_decoder, rsa_helper, md5, sha1, sha256, sha512) > with MbedTLS when related Kconfig options are enabled. > Please see the output of bloat-o-meter for the reference of the size-growth > on QEMU arm64 target [1]. > > Tests done: > --- > EFI Secure Boot test (EFI variables loading and verifying, EFI signed image > verifying and booting) via U-Boot console. > EFI Secure Boot and Capsule sandbox test passed. > > Known issues: > - > None. > > [1]: bloat-o-meter output between disabling/enabling MbedTLS (QEMU arm64) > ``` > add/remove: 212/81 grow/shrink: 20/17 up/down: 56376/-17495 (38881) > Function old new delta > mbedtls_internal_sha1_process -4540 +4540 > mbedtls_x509_crt_parse_der_internal-3072 +3072 > mbedtls_internal_md5_process -2928 +2928 > mbedtls_internal_sha256_process-2052 +2052 > mbedtls_pkcs7_parse_der-1608 +1608 > mbedtls_rsa_private-1468 +1468 > pkcs7_parse_message 3721648 +1276 > mbedtls_mpi_div_mpi-1168 +1168 > mbedtls_internal_sha512_process-1056 +1056 > mbedtls_mpi_inv_mod-1000 +1000 > mbedtls_x509_dn_gets - 996+996 > x509_populate_cert - 948+948 > K - 896+896 > oid_x520_attr_type - 840+840 > __udivti3 - 832+832 > mbedtls_x509_parse_subject_alt_name- 724+724 > mbedtls_rsa_deduce_primes - 720+720 > mbedtls_mpi_exp_mod- 668+668 > mbedtls_rsa_rsaes_pkcs1_v15_decrypt- 652+652 > pkcs7_get_signer_info - 632+632 > mbedtls_rsa_complete - 624+624 > mbedtls_rsa_validate_params- 608+608 > mbedtls_mpi_core_exp_mod - 560+560 > mbedtls_sha512_finish - 556+556 > mscode_parse 28 580+552 > mbedtls_x509_get_time - 552+552 > mbedtls_x509_get_name - 516+516 > mbedtls_sha256_finish - 484
Re: [PATCH 60/81] serial: Remove and add needed includes
On Thu, 2 May 2024 at 02:33, Tom Rini wrote: > > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Reviewed-by: Peter Robinson Looks good. > --- > Cc: Tom Rini > Cc: Simon Glass > Cc: Matthias Brugger > Cc: Peter Robinson > Cc: Alex Nemirovsky > Cc: Neil Armstrong > Cc: Caleb Connolly > Cc: Sumit Garg > Cc: This contributor prefers not to receive mails > Cc: Stefan Roese > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: "NXP i.MX U-Boot Team" > Cc: Manivannan Sadhasivam > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Stefan Bosch > Cc: Sean Anderson > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Kunihiko Hayashi > Cc: Dai Okamura > Cc: Anastasiia Lukianenko > Cc: Oleksandr Andrushchenko > Cc: Michal Simek > Cc: Rasmus Villemoes > Cc: Marek Vasut > Cc: Venkatesh Yadav Abbarapu > Cc: Maksim Kiselev > Cc: Algapally Santosh Sagar > Cc: Heinrich Schuchardt > Cc: Bin Meng > Cc: Peng Fan > Cc: "Sébastien Szymanski" > Cc: Ye Li > Cc: Christophe Leroy > Cc: Weijie Gao > Cc: Sam Shih > Cc: Jim Liu > Cc: Lukasz Majewski > Cc: Yang Xiwen > --- > drivers/serial/altera_jtag_uart.c | 1 - > drivers/serial/altera_uart.c | 1 - > drivers/serial/arm_dcc.c | 1 - > drivers/serial/atmel_usart.c | 1 - > drivers/serial/ns16550.c | 2 +- > drivers/serial/sandbox.c | 1 - > drivers/serial/serial-uclass.c| 2 +- > drivers/serial/serial.c | 2 +- > drivers/serial/serial_ar933x.c| 1 - > drivers/serial/serial_arc.c | 1 - > drivers/serial/serial_bcm283x_mu.c| 1 - > drivers/serial/serial_bcm283x_pl011.c | 1 - > drivers/serial/serial_coreboot.c | 1 - > drivers/serial/serial_cortina.c | 1 - > drivers/serial/serial_efi.c | 1 - > drivers/serial/serial_htif.c | 1 - > drivers/serial/serial_intel_mid.c | 1 - > drivers/serial/serial_linflexuart.c | 1 - > drivers/serial/serial_lpuart.c| 1 - > drivers/serial/serial_mcf.c | 1 - > drivers/serial/serial_meson.c | 1 - > drivers/serial/serial_mpc8xx.c| 1 - > drivers/serial/serial_msm.c | 1 - > drivers/serial/serial_msm_geni.c | 1 - > drivers/serial/serial_mtk.c | 2 +- > drivers/serial/serial_mvebu_a3700.c | 1 - > drivers/serial/serial_mxc.c | 1 - > drivers/serial/serial_mxs.c | 1 - > drivers/serial/serial_npcm.c | 1 - > drivers/serial/serial_ns16550.c | 2 +- > drivers/serial/serial_nulldev.c | 1 - > drivers/serial/serial_omap.c | 2 +- > drivers/serial/serial_owl.c | 1 - > drivers/serial/serial_pic32.c | 1 - > drivers/serial/serial_pl01x.c | 1 - > drivers/serial/serial_rockchip.c | 1 - > drivers/serial/serial_s5p4418_pl011.c | 1 - > drivers/serial/serial_semihosting.c | 1 - > drivers/serial/serial_sifive.c| 1 - > drivers/serial/serial_sti_asc.c | 1 - > drivers/serial/serial_stm32.c | 1 - > drivers/serial/serial_uniphier.c | 1 - > drivers/serial/serial_xen.c | 1 - > drivers/serial/serial_xuartlite.c | 1 - > drivers/serial/serial_zynq.c | 1 - > drivers/serial/usbtty.c | 1 - > 46 files changed, 6 insertions(+), 46 deletions(-) > > diff --git a/drivers/serial/altera_jtag_uart.c > b/drivers/serial/altera_jtag_uart.c > index 9e39da7dd246..3f706e1839f2 100644 > --- a/drivers/serial/altera_jtag_uart.c > +++ b/drivers/serial/altera_jtag_uart.c > @@ -4,7 +4,6 @@ > * Scott McNutt > */ > > -#include > #include > #include > #include > diff --git a/drivers/serial/altera_uart.c b/drivers/serial/altera_uart.c > index 35920480841a..3c13ef25bb49 100644 > --- a/drivers/serial/altera_uart.c > +++ b/drivers/serial/altera_uart.c > @@ -4,7 +4,6 @@ > * Scott McNutt > */ > > -#include > #include > #include > #include > diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c > index a402a123b6d6..66af136695d0 100644 > --- a/drivers/serial/arm_dcc.c > +++ b/drivers/serial/arm_dcc.c > @@ -15,7 +15,6 @@ > * this file might be covered by the GNU General Public License. > */ > > -#include > #include > #include > > diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c > index 9827c006fa88..7e45a80969e8 100644 > --- a/drivers/serial/atmel_usart.c > +++ b/drivers/serial/atmel_usart.c > @@ -5,7 +5,6 @@ > * Modified to support C structur SoC access by
Re: [PATCH 51/81] pinctrl: Remove and add needed includes
On Thu, 2 May 2024 at 02:33, Tom Rini wrote: > > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Reviewed-by: Peter Robinson Looks fine > --- > Cc: Ryan Chen > Cc: Chia-Wei Wang > Cc: Aspeed BMC SW team > Cc: Joel Stanley > Cc: Tom Rini > Cc: Matthias Brugger > Cc: Peter Robinson > Cc: Ryder Lee > Cc: Weijie Gao > Cc: Chunfeng Yun > Cc: GSS_MTK_Uboot_upstream > Cc: Neil Armstrong > Cc: Gregory CLEMENT > Cc: Lars Povlsen > Cc: Horatiu Vultur > Cc: Stefan Roese > Cc: Stefan Bosch > Cc: Mark Kettenis > Cc: Sean Anderson > Cc: Simon Glass > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Michal Simek > Cc: Caleb Connolly > Cc: Sumit Garg > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Thierry Reding > Cc: Svyatoslav Ryhel > Cc: Kunihiko Hayashi > Cc: Dai Okamura > Cc: Minkyu Kang > Cc: Sam Protsenko > Cc: Peng Fan > Cc: Stefano Babic > Cc: Matthias Schiffer > Cc: Quentin Schulz > Cc: Jonas Karlman > Cc: Volodymyr Babchuk > Cc: Robert Marko > --- > drivers/pinctrl/aspeed/pinctrl_ast2500.c | 1 - > drivers/pinctrl/aspeed/pinctrl_ast2600.c | 1 - > drivers/pinctrl/ath79/pinctrl_ar933x.c | 1 - > drivers/pinctrl/ath79/pinctrl_qca953x.c | 1 - > drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 1 - > drivers/pinctrl/broadcom/pinctrl-bcm6838.c | 1 - > drivers/pinctrl/exynos/pinctrl-exynos.c | 1 - > drivers/pinctrl/exynos/pinctrl-exynos7420.c | 1 - > drivers/pinctrl/exynos/pinctrl-exynos78x0.c | 1 - > drivers/pinctrl/intel/pinctrl.c | 1 - > drivers/pinctrl/intel/pinctrl_apl.c | 1 - > drivers/pinctrl/mediatek/pinctrl-mtk-common.c| 1 - > drivers/pinctrl/meson/pinctrl-meson-a1.c | 1 - > drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c| 1 - > drivers/pinctrl/meson/pinctrl-meson-axg.c| 1 - > drivers/pinctrl/meson/pinctrl-meson-g12a.c | 1 - > drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c | 1 - > drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 1 - > drivers/pinctrl/meson/pinctrl-meson-gxl.c| 1 - > drivers/pinctrl/meson/pinctrl-meson.c| 1 - > drivers/pinctrl/mscc/mscc-common.c | 1 - > drivers/pinctrl/mscc/pinctrl-jr2.c | 1 - > drivers/pinctrl/mscc/pinctrl-luton.c | 1 - > drivers/pinctrl/mscc/pinctrl-ocelot.c| 1 - > drivers/pinctrl/mscc/pinctrl-serval.c| 1 - > drivers/pinctrl/mscc/pinctrl-servalt.c | 1 - > drivers/pinctrl/mtmips/pinctrl-mt7628.c | 1 - > drivers/pinctrl/mtmips/pinctrl-mtmips-common.c | 1 - > drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 1 - > drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 1 - > drivers/pinctrl/mvebu/pinctrl-mvebu.c| 1 - > drivers/pinctrl/nexell/pinctrl-nexell.c | 1 - > drivers/pinctrl/nexell/pinctrl-s5pxx18.c | 1 - > drivers/pinctrl/nxp/pinctrl-imx.c| 1 - > drivers/pinctrl/nxp/pinctrl-imx5.c | 1 - > drivers/pinctrl/nxp/pinctrl-imx6.c | 1 - > drivers/pinctrl/nxp/pinctrl-imx7.c | 1 - > drivers/pinctrl/nxp/pinctrl-imx7ulp.c| 1 - > drivers/pinctrl/nxp/pinctrl-imx8.c | 1 - > drivers/pinctrl/nxp/pinctrl-imx8ulp.c| 1 - > drivers/pinctrl/nxp/pinctrl-imxrt.c | 1 - > drivers/pinctrl/nxp/pinctrl-mxs.c| 1 - > drivers/pinctrl/nxp/pinctrl-scu.c| 1 - > drivers/pinctrl/nxp/pinctrl-vf610.c | 1 - > drivers/pinctrl/pinctrl-apple.c | 1 - > drivers/pinctrl/pinctrl-at91-pio4.c | 1 - > drivers/pinctrl/pinctrl-at91.c | 1 - > drivers/pinctrl/pinctrl-generic.c| 1 - > drivers/pinctrl/pinctrl-k210.c | 1 - > drivers/pinctrl/pinctrl-qe-io.c | 1 - > drivers/pinctrl/pinctrl-sandbox.c| 1 - > drivers/pinctrl/pinctrl-single.c | 1 - > drivers/pinctrl/pinctrl-sti.c| 1 - > drivers/pinctrl/pinctrl-stmfx.c | 1 - > drivers/pinctrl/pinctrl-uclass.c | 1 - > drivers/pinctrl/pinctrl-zynqmp.c | 1 - > drivers/pinctrl/pinctrl_pic32.c | 1 - > drivers/pinctrl/pinctrl_stm32.c | 1 - > drivers/pinctrl/qcom/pinctrl-apq8016.c | 1 - > drivers/pinctrl/qcom/pinctrl-apq8096.c | 1 - > drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1 - > drivers/pinctrl/qcom/pinctrl-qcom.c | 1 - > d
Re: [PATCH 42/81] mmc: Remove and add needed includes
On Thu, 2 May 2024 at 02:32, Tom Rini wrote: > > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Reviewed-by: Peter Robinson Looks good. > --- > Cc: Peng Fan > Cc: Jaehoon Chung > Cc: Tom Rini > Cc: Ryan Chen > Cc: Chia-Wei Wang > Cc: Aspeed BMC SW team > Cc: Joel Stanley > Cc: Matthias Brugger > Cc: Peter Robinson > Cc: Thomas Fitzsimmons > Cc: Alex Nemirovsky > Cc: Masahisa Kojima > Cc: Neil Armstrong > Cc: Simon Glass > Cc: Caleb Connolly > Cc: Sumit Garg > Cc: Ryder Lee > Cc: Weijie Gao > Cc: Chunfeng Yun > Cc: GSS_MTK_Uboot_upstream > Cc: Tianrui Wei > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Nobuhiro Iwamatsu > Cc: Marek Vasut > Cc: Eugeniy Paltsev > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Thierry Reding > Cc: Svyatoslav Ryhel > Cc: Kunihiko Hayashi > Cc: Dai Okamura > Cc: Stefan Roese > Cc: Michal Simek > --- > drivers/mmc/am654_sdhci.c | 1 - > drivers/mmc/arm_pl180_mmci.c | 1 - > drivers/mmc/aspeed_sdhci.c| 1 - > drivers/mmc/atmel_sdhci.c | 1 - > drivers/mmc/bcm2835_sdhci.c | 1 - > drivers/mmc/bcm2835_sdhost.c | 1 - > drivers/mmc/bcmstb_sdhci.c| 1 - > drivers/mmc/ca_dw_mmc.c | 1 - > drivers/mmc/davinci_mmc.c | 1 - > drivers/mmc/dw_mmc.c | 1 - > drivers/mmc/exynos_dw_mmc.c | 1 - > drivers/mmc/f_sdh30.c | 1 - > drivers/mmc/fsl_esdhc.c | 1 - > drivers/mmc/fsl_esdhc_imx.c | 1 - > drivers/mmc/fsl_esdhc_spl.c | 2 +- > drivers/mmc/ftsdc010_mci.c| 1 - > drivers/mmc/gen_atmel_mci.c | 2 +- > drivers/mmc/hi6220_dw_mmc.c | 1 - > drivers/mmc/iproc_sdhci.c | 1 - > drivers/mmc/jz_mmc.c | 1 - > drivers/mmc/kona_sdhci.c | 1 - > drivers/mmc/meson_gx_mmc.c| 1 - > drivers/mmc/mmc-pwrseq.c | 1 - > drivers/mmc/mmc-uclass.c | 1 - > drivers/mmc/mmc.c | 3 ++- > drivers/mmc/mmc_boot.c| 1 - > drivers/mmc/mmc_bootdev.c | 1 - > drivers/mmc/mmc_legacy.c | 1 - > drivers/mmc/mmc_spi.c | 1 - > drivers/mmc/mmc_write.c | 1 - > drivers/mmc/msm_sdhci.c | 1 - > drivers/mmc/mtk-sd.c | 1 - > drivers/mmc/mv_sdhci.c| 1 - > drivers/mmc/mvebu_mmc.c | 1 - > drivers/mmc/mxcmmc.c | 1 - > drivers/mmc/mxsmmc.c | 1 - > drivers/mmc/nexell_dw_mmc.c | 1 - > drivers/mmc/npcm_sdhci.c | 1 - > drivers/mmc/omap_hsmmc.c | 1 - > drivers/mmc/owl_mmc.c | 1 - > drivers/mmc/pci_mmc.c | 1 - > drivers/mmc/piton_mmc.c | 1 - > drivers/mmc/rockchip_dw_mmc.c | 1 - > drivers/mmc/rockchip_sdhci.c | 1 - > drivers/mmc/rpmb.c| 1 - > drivers/mmc/s5p_sdhci.c | 1 - > drivers/mmc/sandbox_mmc.c | 1 - > drivers/mmc/sdhci-adma.c | 1 - > drivers/mmc/sdhci-cadence.c | 1 - > drivers/mmc/sdhci.c | 2 +- > drivers/mmc/sh_mmcif.c| 1 - > drivers/mmc/snps_dw_mmc.c | 1 - > drivers/mmc/socfpga_dw_mmc.c | 1 - > drivers/mmc/sti_sdhci.c | 1 - > drivers/mmc/stm32_sdmmc2.c| 1 - > drivers/mmc/sunxi_mmc.c | 1 - > drivers/mmc/tangier_sdhci.c | 1 - > drivers/mmc/tegra_mmc.c | 1 - > drivers/mmc/tmio-common.c | 1 - > drivers/mmc/uniphier-sd.c | 1 - > drivers/mmc/xenon_sdhci.c | 1 - > drivers/mmc/zynq_sdhci.c | 1 - > 62 files changed, 5 insertions(+), 62 deletions(-) > > diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c > index ffb461c2f6c1..48fac7a11b48 100644 > --- a/drivers/mmc/am654_sdhci.c > +++ b/drivers/mmc/am654_sdhci.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > #include > #include > diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c > index cecc7ad783d0..f00b0ff0dc95 100644 > --- a/drivers/mmc/arm_pl180_mmci.c > +++ b/drivers/mmc/arm_pl180_mmci.c > @@ -11,7 +11,6 @@ > > /* #define DEBUG */ > > -#include "common.h" > #include > #include > #include > diff --git a/drivers/mmc/aspeed_sdhci.c b/drivers/mmc/aspeed_sdhci.c > index c9626c6beb8f..87a6f66ebb37 100644 > --- a/drivers/mmc/aspeed_sdhci.c > +++ b/drivers/mmc/aspeed_sdhci.c > @@ -4,7 +4,6 @@ > * Eddie James > */ > > -#include > #include > #include > #include > diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c > index d92bad97b71e..0b265196f025 100644 > --- a/drivers/mmc/atmel_sdhci.c > +++ b/drivers/mmc/atmel_sdhci.c > @@ -4,7 +4,6 @@ > * Wenyou.Yang > */ > > -#include >
Re: [PATCH 33/81] gpio: Remove and add needed includes
On Thu, 2 May 2024 at 02:32, Tom Rini wrote: > > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Reviewed-by: Peter Robinson Looks fine to me. > --- > Cc: Tom Rini > Cc: Matthias Brugger > Cc: Peter Robinson > Cc: Alex Nemirovsky > Cc: Ryan Chen > Cc: Chia-Wei Wang > Cc: Aspeed BMC SW team > Cc: Joel Stanley > Cc: Nobuhiro Iwamatsu > Cc: Marek Vasut > Cc: Kunihiko Hayashi > Cc: Dai Okamura > Cc: Michal Simek > Cc: Eugeniy Paltsev > Cc: Gregory CLEMENT > Cc: Lars Povlsen > Cc: Horatiu Vultur > Cc: Caleb Connolly > Cc: Neil Armstrong > Cc: Sumit Garg > Cc: Stefan Roese > Cc: Stephan Gerhold > Cc: Linus Walleij > Cc: Stefan Bosch > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Michael Walle > Cc: Patrick Delaunay > Cc: Patrice Chotard > Cc: Thierry Reding > Cc: Svyatoslav Ryhel > Cc: Sean Anderson > Cc: Andre Przywara > Cc: Qu Wenruo > Cc: Ilias Apalodimas > Cc: Heiko Schocher > Cc: Peng Fan > Cc: Bin Meng > Cc: Piotr Wojtaszczyk > Cc: Jim Liu > Cc: Nishanth Menon > Cc: Samuel Holland > Cc: Sam Edwards > --- > drivers/gpio/74x164_gpio.c | 1 - > drivers/gpio/altera_pio.c | 1 - > drivers/gpio/at91_gpio.c| 1 - > drivers/gpio/atmel_pio4.c | 1 - > drivers/gpio/axp_gpio.c | 1 - > drivers/gpio/bcm2835_gpio.c | 1 - > drivers/gpio/bcm6345_gpio.c | 1 - > drivers/gpio/cortina_gpio.c | 1 - > drivers/gpio/da8xx_gpio.c | 1 - > drivers/gpio/ftgpio010.c| 1 - > drivers/gpio/gpio-aspeed.c | 1 - > drivers/gpio/gpio-fxl6408.c | 1 - > drivers/gpio/gpio-rcar.c| 1 - > drivers/gpio/gpio-rza1.c| 1 - > drivers/gpio/gpio-uclass.c | 1 - > drivers/gpio/gpio-uniphier.c| 1 - > drivers/gpio/gpio_slg7xl45106.c | 1 - > drivers/gpio/hi6220_gpio.c | 1 - > drivers/gpio/hsdk-creg-gpio.c | 1 - > drivers/gpio/imx_rgpio2p.c | 1 - > drivers/gpio/intel_broadwell_gpio.c | 1 - > drivers/gpio/intel_gpio.c | 1 - > drivers/gpio/intel_ich6_gpio.c | 1 - > drivers/gpio/iproc_gpio.c | 1 - > drivers/gpio/kw_gpio.c | 1 - > drivers/gpio/lpc32xx_gpio.c | 1 - > drivers/gpio/max7320_gpio.c | 1 - > drivers/gpio/mcp230xx_gpio.c| 1 - > drivers/gpio/mpc83xx_spisel_boot.c | 1 - > drivers/gpio/mpc8xx_gpio.c | 1 - > drivers/gpio/mpc8xxx_gpio.c | 1 - > drivers/gpio/mscc_sgpio.c | 1 - > drivers/gpio/msm_gpio.c | 1 - > drivers/gpio/mt7621_gpio.c | 1 - > drivers/gpio/mvebu_gpio.c | 1 - > drivers/gpio/mxc_gpio.c | 1 - > drivers/gpio/mxs_gpio.c | 1 - > drivers/gpio/nmk_gpio.c | 1 - > drivers/gpio/npcm_gpio.c| 1 - > drivers/gpio/nx_gpio.c | 1 - > drivers/gpio/omap_gpio.c| 1 - > drivers/gpio/pca953x.c | 3 ++- > drivers/gpio/pca953x_gpio.c | 1 - > drivers/gpio/pcf8575_gpio.c | 1 - > drivers/gpio/pic32_gpio.c | 1 - > drivers/gpio/qcom_pmic_gpio.c | 1 - > drivers/gpio/qe_gpio.c | 1 - > drivers/gpio/rk_gpio.c | 1 - > drivers/gpio/s5p_gpio.c | 1 - > drivers/gpio/sandbox.c | 1 - > drivers/gpio/sandbox_test.c | 1 - > drivers/gpio/sh_pfc.c | 1 - > drivers/gpio/sifive-gpio.c | 1 - > drivers/gpio/sl28cpld-gpio.c| 1 - > drivers/gpio/stm32_gpio.c | 1 - > drivers/gpio/sunxi_gpio.c | 1 - > drivers/gpio/tca642x.c | 2 +- > drivers/gpio/tegra186_gpio.c| 1 - > drivers/gpio/tegra_gpio.c | 1 - > drivers/gpio/vybrid_gpio.c | 1 - > drivers/gpio/xilinx_gpio.c | 1 - > drivers/gpio/zynq_gpio.c| 1 - > drivers/gpio/zynqmp_gpio_modepin.c | 1 - > 63 files changed, 3 insertions(+), 63 deletions(-) > > diff --git a/drivers/gpio/74x164_gpio.c b/drivers/gpio/74x164_gpio.c > index 7a7cfe86114b..331428ccdb9a 100644 > --- a/drivers/gpio/74x164_gpio.c > +++ b/drivers/gpio/74x164_gpio.c > @@ -8,7 +8,6 @@ > * > */ > > -#include > #include > #include > #include > diff --git a/drivers/gpio/altera_pio.c b/drivers/gpio/altera_pio.c > index edc5a8093b0c..7ba1595e4ae3 100644 > --- a/drivers/gpio/altera_pio.c > +++ b/drivers/gpio/altera_pio.c > @@ -4,7 +4,6 @@ > * Copyright (C) 2011 Missing Link Electronics > *
Re: [PATCH 74/81] video: Remove and add needed includes
On Thu, 2 May 2024 at 02:34, Tom Rini wrote: > > Remove from this driver directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Reviewed-by: Peter Robinson LGTM. > --- > Cc: Anatolij Gustschin > Cc: Tom Rini > Cc: Matthias Brugger > Cc: Peter Robinson > Cc: Liviu Dudau > Cc: Stephan Gerhold > Cc: Linus Walleij > Cc: Neil Armstrong > Cc: Stefan Bosch > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Michal Simek > Cc: Patrick Delaunay > Cc: Patrice Chotard > Cc: Jagan Teki > Cc: Andre Przywara > Cc: Thierry Reding > Cc: Svyatoslav Ryhel > Cc: Johan Jonker > --- > drivers/video/anx9804.c | 1 - > drivers/video/atmel_hlcdfb.c| 1 - > drivers/video/atmel_lcdfb.c | 1 - > drivers/video/backlight-uclass.c| 1 - > drivers/video/backlight_gpio.c | 1 - > drivers/video/bcm2835.c | 1 - > drivers/video/bmp.c | 1 - > drivers/video/bochs.c | 1 - > drivers/video/bridge/anx6345.c | 1 - > drivers/video/bridge/ps862x.c | 1 - > drivers/video/bridge/ptn3460.c | 1 - > drivers/video/bridge/ssd2825.c | 1 - > drivers/video/bridge/video-bridge-uclass.c | 1 - > drivers/video/broadwell_igd.c | 2 +- > drivers/video/console_normal.c | 1 - > drivers/video/console_rotate.c | 1 - > drivers/video/console_truetype.c| 1 - > drivers/video/coreboot.c| 1 - > drivers/video/display-uclass.c | 1 - > drivers/video/dsi-host-uclass.c | 1 - > drivers/video/dw_hdmi.c | 3 ++- > drivers/video/dw_mipi_dsi.c | 1 - > drivers/video/efi.c | 1 - > drivers/video/endeavoru-panel.c | 1 - > drivers/video/exynos/exynos_dp.c| 1 - > drivers/video/exynos/exynos_dp_lowlevel.c | 1 - > drivers/video/exynos/exynos_fb.c| 1 - > drivers/video/exynos/exynos_mipi_dsi.c | 1 - > drivers/video/exynos/exynos_mipi_dsi_common.c | 1 - > drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 1 - > drivers/video/himax-hx8394.c| 1 - > drivers/video/hitachi_tx18d42vm_lcd.c | 1 - > drivers/video/hx8238d.c | 1 - > drivers/video/ihs_video_out.c | 1 - > drivers/video/imx/ipu_common.c | 2 +- > drivers/video/imx/ipu_disp.c| 1 - > drivers/video/imx/mxc_ipuv3_fb.c| 1 - > drivers/video/ivybridge_igd.c | 1 - > drivers/video/lm3533_backlight.c| 1 - > drivers/video/logicore_dp_tx.c | 1 - > drivers/video/mali_dp.c | 1 - > drivers/video/mcde_simple.c | 1 - > drivers/video/meson/meson_canvas.c | 1 - > drivers/video/meson/meson_dw_hdmi.c | 1 - > drivers/video/meson/meson_plane.c | 1 - > drivers/video/meson/meson_vclk.c| 1 - > drivers/video/meson/meson_venc.c| 1 - > drivers/video/meson/meson_vpu.c | 1 - > drivers/video/meson/meson_vpu_init.c| 1 - > drivers/video/mipi_dsi.c| 1 - > drivers/video/mvebu_lcd.c | 1 - > drivers/video/mxsfb.c | 1 - > drivers/video/nexell/s5pxx18_dp.c | 1 - > drivers/video/nexell/s5pxx18_dp_hdmi.c | 1 - > drivers/video/nexell/s5pxx18_dp_lvds.c | 2 +- > drivers/video/nexell/s5pxx18_dp_mipi.c | 1 - > drivers/video/nexell/s5pxx18_dp_rgb.c | 2 +- > drivers/video/nexell/soc/s5pxx18_soc_disptop.h | 1 + > drivers/video/nexell_display.c | 1 - > drivers/video/omap3_dss.c | 1 - > drivers/video/orisetech_otm8009a.c | 1 - > drivers/video/panel-uclass.c| 1 - > drivers/video/pwm_backlight.c | 1 - > drivers/video/raydium-rm68200.c | 1 - > drivers/video/renesas-r61307.c | 1 - > drivers/video/renesas-r69328.c | 1 - > drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 1 - > drivers/video/rockchip/rk3288_hdmi.c| 1 - > drivers/video/rockchip/rk3288_mipi.c| 1 - > drivers/video/rockchip/rk3288_vop.c | 1 - > drivers/video/rockchip/rk3399_hdmi.c| 1 - > d
Re: [PATCH v2 22/22] rockchip: rk3399: Drop ethernet0 alias from SoC u-boot.dtsi
On Wed, 1 May 2024 at 17:25, Jonas Karlman wrote:
>
> Remove the obsolete ethernet0 alias now that all board device tree files
> have been fully synced with Linux kernel v6.8.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Peter Robinson
> ---
> v2: New patch
> ---
> arch/arm/dts/rk3399-u-boot.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 6af9621ac3d0..b6b43271172e 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -6,7 +6,6 @@
>
> / {
> aliases {
> - ethernet0 =
> mmc0 =
> mmc1 =
> pci0 =
> --
> 2.43.2
>
Re: [PATCH 26/31] rockchip: rk3399-rock960: Sync device tree from linux v6.8
On Sun, 31 Mar 2024 at 21:34, Jonas Karlman wrote:
>
> Sync rk3399-rock960 related device tree from linux v6.8.
TBH I wouldn't class this as "Sync device tree from linux v6.8", it
does a dozen other things as well!
> Add DM_RESET=y to support reset signals.
>
> Add PCI=y, CMD_PCI=y and NVME_PCI=y to support PCIe and NVMe boot.
>
> Add AHCI=y, SCSI_AHCI=y, AHCI_PCI=y and SCSI=y to support PCIe SATA boot.
>
> Change to SPL_MAX_SIZE=0x4, SPL can be up to 256 KiB.
>
> Remove CONFIG_NET_RANDOM_ETHADDR=y, ethaddr and eth1addr is set based on
> cpuid read from eFUSE.
>
> Add MMC_SDHCI_SDMA=y to use DMA transfer for eMMC.
>
> Add PHY_REALTEK=y and DM_ETH_PHY=y to support ethernet PHY.
>
> Add PHY_ROCKCHIP_INNO_USB2=y and PHY_ROCKCHIP_TYPEC=y to support USB PHY.
>
> Remove REGULATOR_PWM=y and DM_REGULATOR_GPIO=y, boards does not use
> pwm-regulator or regulator-gpio compatible.
>
> Add USB_XHCI_HCD=y, USB_DWC3=y and USB_DWC3_GENERIC=y to support USB3.
>
> Remove USE_PREBOOT=y to speed up booting, standard boot will init USB
> after faster boot media has been evaluated.
Does it init nvme and friends?
> Add CMD_ROCKUSB=y, CMD_USB_MASS_STORAGE=y and USB_GADGET=y to support
> RockUSB and UMS gadget.
Does this have effect on boot speed?
> Remove SPL_TINY_MEMSET=y to use full memset in SPL.
>
> Signed-off-by: Jonas Karlman
> ---
> arch/arm/dts/rk3399-ficus.dts| 4
> arch/arm/dts/rk3399-rock960.dtsi | 5 -
> configs/ficus-rk3399_defconfig | 22 +-
> configs/rock960-rk3399_defconfig | 14 +++---
> 4 files changed, 36 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
> index 1ce85a5816e4..30e4879f322c 100644
> --- a/arch/arm/dts/rk3399-ficus.dts
> +++ b/arch/arm/dts/rk3399-ficus.dts
> @@ -13,6 +13,10 @@
> model = "96boards RK3399 Ficus";
> compatible = "vamrs,ficus", "rockchip,rk3399";
>
> + aliases {
> + ethernet0 =
> + };
> +
> chosen {
> stdout-path = "serial2:150n8";
> };
> diff --git a/arch/arm/dts/rk3399-rock960.dtsi
> b/arch/arm/dts/rk3399-rock960.dtsi
> index 25dc61c26a94..c920ddf44baf 100644
> --- a/arch/arm/dts/rk3399-rock960.dtsi
> +++ b/arch/arm/dts/rk3399-rock960.dtsi
> @@ -7,6 +7,7 @@
>
> #include "rk3399.dtsi"
> #include "rk3399-opp.dtsi"
> +#include
>
> / {
> aliases {
> @@ -127,6 +128,8 @@
> };
>
> {
> + avdd-0v9-supply = <_hdmi>;
> + avdd-1v8-supply = <_hdmi>;
> ddc-i2c-bus = <>;
> pinctrl-names = "default";
> pinctrl-0 = <_cec>;
> @@ -528,7 +531,7 @@
> compatible = "brcm,bcm4329-fmac";
> reg = <1>;
> interrupt-parent = <>;
> - interrupts = ;
> + interrupts = ;
> interrupt-names = "host-wake";
> pinctrl-names = "default";
> pinctrl-0 = <_host_wake_l>;
> diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
> index f4e3ebba8f46..0d97b7ecb3c7 100644
> --- a/configs/ficus-rk3399_defconfig
> +++ b/configs/ficus-rk3399_defconfig
> @@ -5,15 +5,18 @@ CONFIG_ARCH_ROCKCHIP=y
> CONFIG_SF_DEFAULT_SPEED=2000
> CONFIG_ENV_OFFSET=0x3F8000
> CONFIG_DEFAULT_DEVICE_TREE="rk3399-ficus"
> +CONFIG_DM_RESET=y
> CONFIG_ROCKCHIP_RK3399=y
> CONFIG_TARGET_ROCK960_RK3399=y
> CONFIG_DEBUG_UART_BASE=0xFF1A
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_SYS_LOAD_ADDR=0x800800
> +CONFIG_PCI=y
> CONFIG_DEBUG_UART=y
> +CONFIG_AHCI=y
> CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-ficus.dtb"
> CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_SPL_MAX_SIZE=0x2e000
> +CONFIG_SPL_MAX_SIZE=0x4
> CONFIG_SPL_PAD_TO=0x7f8000
> # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> @@ -21,6 +24,7 @@ CONFIG_TPL=y
> CONFIG_CMD_BOOTZ=y
> CONFIG_CMD_GPT=y
> CONFIG_CMD_MMC=y
> +CONFIG_CMD_PCI=y
> CONFIG_CMD_USB=y
> # CONFIG_CMD_SETEXPR is not set
> CONFIG_CMD_TIME=y
> @@ -29,27 +33,35 @@ CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent
> assigned-clocks assigne
> CONFIG_ENV_IS_IN_MMC=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_SYS_MMC_ENV_DEV=1
> -CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_SCSI_AHCI=y
> +CONFIG_AHCI_PCI=y
> CONFIG_ROCKCHIP_GPIO=y
> CONFIG_SYS_I2C_ROCKCHIP=y
> CONFIG_ROCKCHIP_IODOMAIN=y
> CONFIG_MMC_DW=y
> CONFIG_MMC_DW_ROCKCHIP=y
> CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_SDMA=y
> CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH_PHY=y
> CONFIG_ETH_DESIGNWARE=y
> -CONFIG_RGMII=y
> CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_NVME_PCI=y
> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> +CONFIG_PHY_ROCKCHIP_TYPEC=y
> CONFIG_PMIC_RK8XX=y
> -CONFIG_REGULATOR_PWM=y
> -CONFIG_DM_REGULATOR_GPIO=y
> CONFIG_REGULATOR_RK8XX=y
> CONFIG_PWM_ROCKCHIP=y
> +CONFIG_SCSI=y
> CONFIG_BAUDRATE=150
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYS_NS16550_MEM32=y
> CONFIG_SYSRESET=y
> CONFIG_USB=y
>
Re: [PATCH 02/31] rockchip: rk3399-ficus: Enable TPL and use common bss and stack addr
On Sun, 31 Mar 2024 at 21:30, Jonas Karlman wrote: > > The rk3399-ficus board is only using SPL and not TPL+SPL like all other > RK3399 boards, chromebook bob/kevin excluded. It does not seem to be any > technical reason why this board was left using only SPL. > > Switch to use TPL+SPL and use common bss and stack addresses to allow > for more options to be enabled in a future patch. Also add the missing > DEFAULT_FDT_FILE option. > > Signed-off-by: Jonas Karlman Reviewed-by: Peter Robinson I believe I have one of these if you need anything tested. P > --- > configs/ficus-rk3399_defconfig | 14 ++ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig > index 4859042d6b56..3bcd0fd66b91 100644 > --- a/configs/ficus-rk3399_defconfig > +++ b/configs/ficus-rk3399_defconfig > @@ -2,32 +2,22 @@ CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_COUNTER_FREQUENCY=2400 > CONFIG_ARCH_ROCKCHIP=y > -CONFIG_TEXT_BASE=0x0020 > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 > CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-ficus" > -CONFIG_SPL_TEXT_BASE=0xff8c2000 > CONFIG_ROCKCHIP_RK3399=y > -CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 > CONFIG_TARGET_ROCK960_RK3399=y > -CONFIG_SPL_STACK=0xff8e > CONFIG_DEBUG_UART_BASE=0xFF1A > CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_DEBUG_UART=y > +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-ficus.dtb" > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_SPL_MAX_SIZE=0x2e000 > CONFIG_SPL_PAD_TO=0x7f8000 > -CONFIG_SPL_HAS_BSS_LINKER_SECTION=y > -CONFIG_SPL_BSS_START_ADDR=0xff8e > -CONFIG_SPL_BSS_MAX_SIZE=0x1 > # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set > -# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > -CONFIG_SPL_STACK_R=y > -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 > CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > +CONFIG_TPL=y > CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPT=y > CONFIG_CMD_MMC=y > -- > 2.43.2 >
Re: [PATCH 05/31] rockchip: rk3399: Enable random generator on all boards
On Sun, 31 Mar 2024 at 21:29, Jonas Karlman wrote: > > The RK3399 SoC contain a crypto engine block that can generate random > numbers. > > Imply DM_RNG and RNG_ROCKCHIP Kconfig options to take advantage of the > random generator on all RK3399 boards. > > Signed-off-by: Jonas Karlman Reviewed-by: Peter Robinson Looks good, I meant to do this ages ago. > --- > arch/arm/mach-rockchip/Kconfig | 2 ++ > configs/chromebook_bob_defconfig | 2 -- > configs/chromebook_kevin_defconfig | 2 -- > configs/evb-rk3399_defconfig | 2 -- > configs/firefly-rk3399_defconfig | 2 -- > configs/pinebook-pro-rk3399_defconfig | 2 -- > configs/pinephone-pro-rk3399_defconfig | 2 -- > configs/roc-pc-rk3399_defconfig| 2 -- > configs/rock960-rk3399_defconfig | 2 -- > configs/rockpro64-rk3399_defconfig | 2 -- > 10 files changed, 2 insertions(+), 18 deletions(-) > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index eb74cd850409..e18d7f373f77 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -264,12 +264,14 @@ config ROCKCHIP_RK3399 > imply ARMV8_SET_SMPEN > imply BOOTSTD_FULL > imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT > + imply DM_RNG > imply LEGACY_IMAGE_FORMAT > imply MISC > imply MISC_INIT_R > imply OF_LIVE > imply PARTITION_TYPE_GUID > imply PRE_CONSOLE_BUFFER > + imply RNG_ROCKCHIP > imply ROCKCHIP_COMMON_BOARD > imply ROCKCHIP_EFUSE > imply ROCKCHIP_SDRAM_COMMON > diff --git a/configs/chromebook_bob_defconfig > b/configs/chromebook_bob_defconfig > index 5d8037d31422..6e203a6cf0e1 100644 > --- a/configs/chromebook_bob_defconfig > +++ b/configs/chromebook_bob_defconfig > @@ -89,8 +89,6 @@ CONFIG_DM_REGULATOR_GPIO=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_CROS_EC=y > CONFIG_PWM_ROCKCHIP=y > -CONFIG_DM_RNG=y > -CONFIG_RNG_ROCKCHIP=y > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYS_NS16550_MEM32=y > CONFIG_ROCKCHIP_SPI=y > diff --git a/configs/chromebook_kevin_defconfig > b/configs/chromebook_kevin_defconfig > index 54ba2fdd136f..e3d16f44d62a 100644 > --- a/configs/chromebook_kevin_defconfig > +++ b/configs/chromebook_kevin_defconfig > @@ -90,8 +90,6 @@ CONFIG_DM_REGULATOR_GPIO=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_CROS_EC=y > CONFIG_PWM_ROCKCHIP=y > -CONFIG_DM_RNG=y > -CONFIG_RNG_ROCKCHIP=y > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYS_NS16550_MEM32=y > CONFIG_ROCKCHIP_SPI=y > diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig > index d81c7f9604e1..c4936768ffb6 100644 > --- a/configs/evb-rk3399_defconfig > +++ b/configs/evb-rk3399_defconfig > @@ -47,8 +47,6 @@ CONFIG_PMIC_RK8XX=y > CONFIG_REGULATOR_PWM=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_ROCKCHIP=y > -CONFIG_DM_RNG=y > -CONFIG_RNG_ROCKCHIP=y > CONFIG_BAUDRATE=150 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYS_NS16550_MEM32=y > diff --git a/configs/firefly-rk3399_defconfig > b/configs/firefly-rk3399_defconfig > index 545c047c6df8..8f68ffbd3a49 100644 > --- a/configs/firefly-rk3399_defconfig > +++ b/configs/firefly-rk3399_defconfig > @@ -45,8 +45,6 @@ CONFIG_PMIC_RK8XX=y > CONFIG_REGULATOR_PWM=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_ROCKCHIP=y > -CONFIG_DM_RNG=y > -CONFIG_RNG_ROCKCHIP=y > CONFIG_BAUDRATE=150 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYS_NS16550_MEM32=y > diff --git a/configs/pinebook-pro-rk3399_defconfig > b/configs/pinebook-pro-rk3399_defconfig > index 23ac24a0bffe..e4aad1b710cb 100644 > --- a/configs/pinebook-pro-rk3399_defconfig > +++ b/configs/pinebook-pro-rk3399_defconfig > @@ -75,8 +75,6 @@ CONFIG_REGULATOR_PWM=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_ROCKCHIP=y > CONFIG_RAM_ROCKCHIP_LPDDR4=y > -CONFIG_DM_RNG=y > -CONFIG_RNG_ROCKCHIP=y > CONFIG_BAUDRATE=150 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYS_NS16550_MEM32=y > diff --git a/configs/pinephone-pro-rk3399_defconfig > b/configs/pinephone-pro-rk3399_defconfig > index 8c6323f6c516..285c47d76b6e 100644 > --- a/configs/pinephone-pro-rk3399_defconfig > +++ b/configs/pinephone-pro-rk3399_defconfig > @@ -65,8 +65,6 @@ CONFIG_REGULATOR_PWM=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_ROCKCHIP=y > CONFIG_RAM_ROCKCHIP_LPDDR4=y > -CONFIG_DM_RNG=y > -CONFIG_RNG_ROCKCHIP=y > CONFIG_BAUDRATE=150 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_ROCKCHIP_SPI=y > diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig > index a41f71d9e167..5d6e6b17091f 100644 > --- a/configs/roc-pc-rk3399_defconfig > +++ b/configs/roc-pc-rk3399_defconfig
Re: [PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs
Hi Jonas, Overall this series looks good, and I'll be able to test it fro next week when I'm back near devices. > This series adds support for new clocks used in linux v6.8 device trees, > enables use of FIT signature check for checksum validation and fixes > loading FIT from SD-card when loading FIT from eMMC fails. That's quite a lot for a single series, it can make it hard to review and test all across a number of devices. > After this series it should be possible to move RK3399 boards to use > OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag. This I like :) I should be able to test this on, from mem, 6 rk3399 devices once I'm back home. Peter > I have runtime tested this series on following devices: > - 96boards Rock960 > - Khadas Edge Captain > - Pine64 PineBook Pro > - Pine64 RockPro64 > - Radxa ROCK 4C+ > - Radxa ROCK 4SE > - Radxa ROCK Pi 4A > - Radxa ROCK Pi 4B+ > > This series depends on the following series: > - Enable booting from SPI flash on ROCK Pi 4 [1] > - rockchip: spl: Cache boot source id for later use [2] > > A copy of this series and all its depends can be found at [3] > > [1] https://patchwork.ozlabs.org/cover/1912469/ > [2] https://patchwork.ozlabs.org/cover/1915071/ > [3] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-dt-sync-v1 > > Jonas Karlman (31): > rockchip: rk3399-gru: Fix max SPL size on bob and kevin > rockchip: rk3399-ficus: Enable TPL and use common bss and stack addr > rockchip: rk3399: Sort imply statements alphabetically > rockchip: rk3399: Enable ARMv8 crypto and FIT checksum validation > rockchip: rk3399: Enable random generator on all boards > rockchip: rk3399: Imply support for GbE PHY > rockchip: rk3399: Enable DT overlay support on all boards > rockchip: rk3399: Remove use of xPL_MISC_DRIVERS options > rockchip: rk3399: Add a default spl-boot-order prop > rockchip: rk3399: Fix loading FIT from SD-card when booting from eMMC > clk: rockchip: rk3399: Rename SCLK_DDRCLK to SCLK_DDRC > clk: rockchip: rk3399: Add dummy support for ACLK_VDU clock > clk: rockchip: rk3399: Add dummy support for SCLK_PCIEPHY_REF clock > clk: rockchip: rk3399: Add SCLK_USB3OTGx_REF support > rockchip: rk3399: Sync soc device tree from linux v6.8 > rockchip: rk3399-gru: Sync device tree from linux v6.8 > rockchip: rk3399-puma: Sync DT from linux v6.8 > rockchip: rk3399-rock-pi-n10: Sync device tree from linux v6.8 > rockchip: rk3399-eaidk-610: Sync device tree from linux v6.8 > rockchip: rk3399-leez: Sync device tree from linux v6.8 > rockchip: rk3399-evb: Sync device tree from linux v6.8 > rockchip: rk3399-firefly: Sync device tree from linux v6.8 > rockchip: rk3399-orangepi: Sync device tree from linux v6.8 > rockchip: rk3399-roc-pc: Sync device tree from linux v6.8 > rockchip: rk3399-nanopi-4: Sync device tree from linux v6.8 > rockchip: rk3399-rock960: Sync device tree from linux v6.8 > rockchip: rk3399-khadas: Sync device tree from linux v6.8 > rockchip: rk3399-rock-pi-4: Sync device tree from linux v6.8 > rockchip: rk3399-rockpro64: Sync device tree from linux v6.8 > rockchip: rk3399-pinebook-pro: Sync device tree from linux v6.8 > rockchip: rk3399-pinephone-pro: Sync device tree from linux v6.8 > > arch/arm/dts/rk3288-vmarc-som.dtsi| 48 +++ > arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi | 1 - > arch/arm/dts/rk3399-eaidk-610.dts | 3 +- > arch/arm/dts/rk3399-evb-u-boot.dtsi | 13 +- > arch/arm/dts/rk3399-evb.dts | 3 +- > arch/arm/dts/rk3399-ficus-u-boot.dtsi | 10 +- > arch/arm/dts/rk3399-ficus.dts | 4 + > arch/arm/dts/rk3399-firefly-u-boot.dtsi | 6 - > arch/arm/dts/rk3399-firefly.dts | 17 +- > arch/arm/dts/rk3399-gru-bob.dts | 8 +- > arch/arm/dts/rk3399-gru-chromebook.dtsi | 200 +++- > arch/arm/dts/rk3399-gru-kevin.dts | 3 +- > arch/arm/dts/rk3399-gru-u-boot.dtsi | 34 ++- > arch/arm/dts/rk3399-gru.dtsi | 52 +++- > arch/arm/dts/rk3399-khadas-edge-captain.dts | 4 + > arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +- > arch/arm/dts/rk3399-khadas-edge-v.dts | 4 + > arch/arm/dts/rk3399-khadas-edge.dtsi | 10 +- > arch/arm/dts/rk3399-leez-p710-u-boot.dtsi | 6 - > arch/arm/dts/rk3399-leez-p710.dts | 8 +- > arch/arm/dts/rk3399-nanopc-t4.dts | 2 +- > arch/arm/dts/rk3399-nanopi-m4-2gb.dts | 55 +--- > arch/arm/dts/rk3399-nanopi-m4b.dts| 2 +- > arch/arm/dts/rk3399-nanopi-r4s.dts| 4 +- > arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 18 +- > arch/arm/dts/rk3399-nanopi4.dtsi | 7 +- > arch/arm/dts/rk3399-op1-opp.dtsi | 31 +- > arch/arm/dts/rk3399-opp.dtsi | 6 +- > arch/arm/dts/rk3399-orangepi-u-boot.dtsi | 12 + >
Re: [PATCH v2] rpi: Copy eth MAC address from fw DT to loaded DT
Hi Martin, > I reworked the commit message because I noticed the upstream Linux kernel has > a > difference with the Raspberry Pi fork of the kernel regarding the algorithm > used to determine the MAC address of the smsc95xx. So looking at this on an original 3B because that's what I had booted for other testing. > There is no smsc95xx.macaddr in the upstream kernel, and using the upstream > kernel is actually the real use case for the patch. In most cases in device tree this is dealt with aliases [1] to ethernet0, 1 etc. In the U-Boot env I have two env set, ethaddr and usbethaddr both to the same MAC address with b8:27:eb prefix which is assigned to RPi foundation [2]. When I boot Linux I get that MAC address on the interface as expected. > I'm now wondering whether some users are using the module parameter > smsc95xx.macaddr of the Raspberry Pi fork of the kernel to try to change the > MAC, and put one which is not the factory default? I would have thought that the recent RPi kernels would also fall back to the upstream variation too if their fork option wasn't available. > Does this use case exists? If this is the case, the current algorithm in the > forked kernel would mean that, the FDT-provided MAC would have priority over > anything set in the module parameter. > This is already the case anyway when people give to the forked kernel the > firmware-provided FDT (smsc95xx.macaddr is ignored). So this patch aligns > behaviors. > But we should be aware that applying this patch would change the behavior in > the following situation (all conditions need to be true): > - Forked kernel is used > - Fresh FDT (not firmware one) is provided to the kernel > - Custom (not factory) MAC was set in smsc95xx.macaddr parameter Can we take a step back, I'm still unsure what you're trying to resolve here. For me with the upstream U-Boot and the upstream kernel I get the vendor MAC address as I would expect. It should work on any kernel/DT combo as long as the ether ethernet alias is present in the DT. Peter [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi#n3 [2] https://maclookup.app/search/result?mac=b8:27:eb:
Re: [PATCH v3 00/11] imx8mp: Enable PCIe/NVMe support
On Tue, 12 Mar 2024 at 09:55, Sumit Garg wrote:
>
> Hi Peter,
>
> On Tue, 12 Mar 2024 at 15:13, Peter Robinson wrote:
> >
> > Hi Sumit,
> >
> > > pcie_imx doesn't seem to share any useful code for iMX8MP SoC and it is
> > > rather tied to quite old port of pcie_designware driver from Linux which
> > > suffices only iMX6 specific needs.
> > >
> > > But currently we have the common DWC specific bits which alligns pretty
> > > well with DW PCIe controller on iMX8MP SoC. So lets reuse those common
> > > bits instead as a new driver for iMX8 SoCs. It should be fairly easy to
> > > add support for other iMX8 variants to this driver.
> >
> > The upstream Linux driver is moving towards a single driver [1] for
> > imx6 -> imx9, would it be possible to add support for all generations
> > to this driver and then remove the old driver?
>
> Sorry but that's not in scope of this patch-set and neither do I
> possess boards with all the imx* SoC variants.
>
> > That would allow this
> > single modern driver and removing the old imx6 specific driver.
>
> Folks interested in this can build up on this patch-set and port other
> imx* variants and then we could have a single modern driver.
That's fine but I think you should document that this can be future
because the case is that these devices are clearly related.
> -Sumit
>
> >
> > Peter
> >
> > [1] https://www.spinics.net/lists/linux-pci/msg150359.html
> >
> > > iMX8MP SoC also comes up with standalone PCIe PHY support, so hence we
> > > can reuse the generic PHY infrastructure to power on PCIe PHY.
> > >
> > > Testing with this patch-set included:
> > >
> > > Verdin iMX8MP # pci enum
> > > PCIE-0: Link up (Gen1-x1, Bus0)
> > > Verdin iMX8MP #
> > > Verdin iMX8MP # nvme scan
> > > Verdin iMX8MP #
> > > Verdin iMX8MP # nvme info
> > > Device 0: Vendor: 0x126f Rev: T0828A0 Prod: AA000720
> > > Type: Hard Disk
> > > Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
> > > Verdin iMX8MP #
> > > Verdin iMX8MP # load nvme 0 $loadaddr
> > >
> > > Changes in v3:
> > > - Rebased on top of U-Boot next.
> > > - Incorporated misc. updates to commit messages.
> > > - New patch#2 to refactor reset driver function names.
> > > - Patch#3: Refactored further for better code reuse.
> > > - New patch#4 to fix refcount issue with power domain bus.
> > > - Patch#5: Refactored further for better code reuse.
> > > - Patch#7 & #8: Added dependency on REGMAP and SYSCON. Also, added
> > > support for vpcie-supply regulator.
> > > - Patch#7 & #8: Added error paths and .remove callback.
> > > - New patch#10 to enable PCIe/NVMe for imx8mp_venice*.
> > >
> > > Changes in v2:
> > > - Renamed PCIe IMX driver pcie_dw_imx8.c -> pcie_dw_imx.c.
> > > - Added myself as maintainer for PCIe DWC IMX driver support.
> > > - Incorporated various code and commit message improvement suggestions
> > > from Marek, thanks.
> > > - Patch#3: Gate PCIe and USB clocks behind corresponding power domain
> > > IDs.
> > > - Patch#4: Expose HSIO PLL clocks as a regular clock driver instead
> > > similar to what Linux kernel does.
> > > - Patch#7: Picked up tags.
> > >
> > > Sumit Garg (10):
> > > clk: imx8mp: Add support for PCIe clocks
> > > reset: imx: Refactor driver to simplify function names
> > > reset: imx: Add support for i.MX8MP reset controller
> > > imx8mp: power-domain: Don't power off pd_bus
> > > imx8mp: power-domain: Add PCIe support
> > > imx8mp: power-domain: Expose high performance PLL clock
> > > phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
> > > pci: Add DW PCIe controller support for iMX8MP SoC
> > > verdin-imx8mp_defconfig: Enable PCIe/NVMe support
> > > MAINTAINERS: Add entry for PCIe DWC IMX driver
> > >
> > > Tim Harvey (1):
> > > imx8mp_venice_defconfig: Enable PCIe/NVMe support
> > >
> > > MAINTAINERS | 6 +
> > > configs/imx8mp_venice_defconfig | 8 +
> > > configs/verdin-imx8mp_defconfig | 6 +
> > > drivers/clk/imx/clk-imx8mp.c | 6 +
> > > drivers/pci/Kconfig | 11 +
> > > drivers/pci/Makefile | 1 +
> > > drivers/pci/pcie_dw_imx.c | 338 ++
> > > drivers/phy/Kconfig | 11 +
> > > drivers/phy/Makefile | 1 +
> > > drivers/phy/phy-imx8m-pcie.c | 283 +
> > > drivers/power/domain/imx8mp-hsiomix.c | 191 ---
> > > drivers/reset/reset-imx7.c| 125 +-
> > > 12 files changed, 937 insertions(+), 50 deletions(-)
> > > create mode 100644 drivers/pci/pcie_dw_imx.c
> > > create mode 100644 drivers/phy/phy-imx8m-pcie.c
> > >
> > > --
> > > 2.34.1
> > >
Re: [PATCH v3 00/11] imx8mp: Enable PCIe/NVMe support
Hi Sumit,
> pcie_imx doesn't seem to share any useful code for iMX8MP SoC and it is
> rather tied to quite old port of pcie_designware driver from Linux which
> suffices only iMX6 specific needs.
>
> But currently we have the common DWC specific bits which alligns pretty
> well with DW PCIe controller on iMX8MP SoC. So lets reuse those common
> bits instead as a new driver for iMX8 SoCs. It should be fairly easy to
> add support for other iMX8 variants to this driver.
The upstream Linux driver is moving towards a single driver [1] for
imx6 -> imx9, would it be possible to add support for all generations
to this driver and then remove the old driver? That would allow this
single modern driver and removing the old imx6 specific driver.
Peter
[1] https://www.spinics.net/lists/linux-pci/msg150359.html
> iMX8MP SoC also comes up with standalone PCIe PHY support, so hence we
> can reuse the generic PHY infrastructure to power on PCIe PHY.
>
> Testing with this patch-set included:
>
> Verdin iMX8MP # pci enum
> PCIE-0: Link up (Gen1-x1, Bus0)
> Verdin iMX8MP #
> Verdin iMX8MP # nvme scan
> Verdin iMX8MP #
> Verdin iMX8MP # nvme info
> Device 0: Vendor: 0x126f Rev: T0828A0 Prod: AA000720
> Type: Hard Disk
> Capacity: 122104.3 MB = 119.2 GB (250069680 x 512)
> Verdin iMX8MP #
> Verdin iMX8MP # load nvme 0 $loadaddr
>
> Changes in v3:
> - Rebased on top of U-Boot next.
> - Incorporated misc. updates to commit messages.
> - New patch#2 to refactor reset driver function names.
> - Patch#3: Refactored further for better code reuse.
> - New patch#4 to fix refcount issue with power domain bus.
> - Patch#5: Refactored further for better code reuse.
> - Patch#7 & #8: Added dependency on REGMAP and SYSCON. Also, added
> support for vpcie-supply regulator.
> - Patch#7 & #8: Added error paths and .remove callback.
> - New patch#10 to enable PCIe/NVMe for imx8mp_venice*.
>
> Changes in v2:
> - Renamed PCIe IMX driver pcie_dw_imx8.c -> pcie_dw_imx.c.
> - Added myself as maintainer for PCIe DWC IMX driver support.
> - Incorporated various code and commit message improvement suggestions
> from Marek, thanks.
> - Patch#3: Gate PCIe and USB clocks behind corresponding power domain
> IDs.
> - Patch#4: Expose HSIO PLL clocks as a regular clock driver instead
> similar to what Linux kernel does.
> - Patch#7: Picked up tags.
>
> Sumit Garg (10):
> clk: imx8mp: Add support for PCIe clocks
> reset: imx: Refactor driver to simplify function names
> reset: imx: Add support for i.MX8MP reset controller
> imx8mp: power-domain: Don't power off pd_bus
> imx8mp: power-domain: Add PCIe support
> imx8mp: power-domain: Expose high performance PLL clock
> phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
> pci: Add DW PCIe controller support for iMX8MP SoC
> verdin-imx8mp_defconfig: Enable PCIe/NVMe support
> MAINTAINERS: Add entry for PCIe DWC IMX driver
>
> Tim Harvey (1):
> imx8mp_venice_defconfig: Enable PCIe/NVMe support
>
> MAINTAINERS | 6 +
> configs/imx8mp_venice_defconfig | 8 +
> configs/verdin-imx8mp_defconfig | 6 +
> drivers/clk/imx/clk-imx8mp.c | 6 +
> drivers/pci/Kconfig | 11 +
> drivers/pci/Makefile | 1 +
> drivers/pci/pcie_dw_imx.c | 338 ++
> drivers/phy/Kconfig | 11 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-imx8m-pcie.c | 283 +
> drivers/power/domain/imx8mp-hsiomix.c | 191 ---
> drivers/reset/reset-imx7.c| 125 +-
> 12 files changed, 937 insertions(+), 50 deletions(-)
> create mode 100644 drivers/pci/pcie_dw_imx.c
> create mode 100644 drivers/phy/phy-imx8m-pcie.c
>
> --
> 2.34.1
>
[PATCH v4] disk: dos: Add all options for EFI System Partitions
The EFI spec states that the ESP can be any of FAT12/16/32 but for
compatibility doesn't necssarily require the partition to be the
EFI partition table ID of 0xef. A number of arm devices will not
find their firmware on a FAT partition with an ID of 0xef so also
allow the original FAT12/16/32 partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
v2:
- Add 0x0c option
- Make hex constants consistent
- Move from if to switch statement
v3:
- Fix switch brain fart
v4:
- Drop boot_ind out of switch
disk/part_dos.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 567ead7511d..a35181dff4f 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -40,10 +40,21 @@ static int get_bootable(dos_partition_t *p)
{
int ret = 0;
- if (p->sys_ind == 0xef)
+ switch (p->sys_ind) {
+ case 0x01:
+ case 0x06:
+ case 0x0b:
+ case 0x0c:
+ case 0xef:
ret |= PART_EFI_SYSTEM_PARTITION;
+ break;
+ default:
+ break;
+ }
+
if (p->boot_ind == 0x80)
ret |= PART_BOOTABLE;
+
return ret;
}
--
2.44.0
[PATCH v3] disk: dos: Add all options for EFI System Partitions
The EFI spec states that the ESP can be any of FAT12/16/32 but for
compatibility doesn't necssarily require the partition to be the
EFI partition table ID of 0xef. A number of arm devices will not
find their firmware on a FAT partition with an ID of 0xef so also
allow the original FAT12/16/32 partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
v2:
- Add 0x0c option
- Make hex constants consistent
- Move from if to switch statement
v3:
- Fix switch brain fart
disk/part_dos.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 567ead7511d..97f4ce32bed 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -40,10 +40,21 @@ static int get_bootable(dos_partition_t *p)
{
int ret = 0;
- if (p->sys_ind == 0xef)
+ switch (p->sys_ind) {
+ case 0x01:
+ case 0x06:
+ case 0x0b:
+ case 0x0c:
+ case 0xef:
ret |= PART_EFI_SYSTEM_PARTITION;
- if (p->boot_ind == 0x80)
+ break;
+ case 0x80:
ret |= PART_BOOTABLE;
+ break;
+ default:
+ break;
+ }
+
return ret;
}
--
2.44.0
Re: [PATCH v2] disk: dos: Add all options for EFI System Partitions
On Sun, 25 Feb 2024 at 14:23, Mark Kettenis wrote:
>
> > From: Peter Robinson
> > Date: Sun, 25 Feb 2024 14:14:55 +
> >
> > The EFI spec states that the ESP can be any of FAT12/16/32 but for
> > compatibility doesn't necssarily require the partition to be the
> > EFI partition table ID of 0xef. A number of arm devices will not
> > find their firmware on a FAT partition with an ID of 0xef so also
> > allow the original FAT12/16/32 partition IDs as they are also
> > permissable for an ESP.
> >
> > Signed-off-by: Peter Robinson
> > ---
> >
> > v2:
> > - Add 0x0c option
> > - Make hex constants consistent
> > - Move from if to switch statement
>
> Erh...
>
> > disk/part_dos.c | 17 +++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/disk/part_dos.c b/disk/part_dos.c
> > index 567ead7511d..ab855adf347 100644
> > --- a/disk/part_dos.c
> > +++ b/disk/part_dos.c
> > @@ -40,10 +40,23 @@ static int get_bootable(dos_partition_t *p)
> > {
> > int ret = 0;
> >
> > - if (p->sys_ind == 0xef)
> > + switch (p->sys_ind){
> > + case 0x01:
> > ret |= PART_EFI_SYSTEM_PARTITION;
> > - if (p->boot_ind == 0x80)
> > + case 0x06:
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > + case 0x0b:
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > + case 0x0c:
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > + case 0xef:
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > + case 0x80:
> > ret |= PART_BOOTABLE;
> > + default:
> > + break;
> > + }
> > +
>
> That really didn't go well. The 0x80 check was for a different struct
> member and there are missing break statements. And I suppose the
> suggestion to use a switch was to bunch up the EFI partition type
> cases.
>
> ENOCOFFEE?
It was worse, no coffee and an early start for a flight OOPS!
> > return ret;
> > }
> >
> > --
> > 2.43.2
> >
> >
Re: [PATCH v1 0/5] TEE: minor cleanup
On Thu, 29 Feb 2024 at 19:11, Igor Opaniuk wrote: > > Hi Ilias, > > On Wed, Feb 14, 2024 at 7:34 PM Igor Opaniuk > wrote: > > > - Address some spelling errors and typos > > - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests > > - Remove common.h inclusion for drivers/tee > > > > Igor Opaniuk (5): > > tee: optee: fix description in Kconfig > > tee: sandbox: fix spelling errors > > cmd: optee_rpmb: build cmd for sandbox > > test: py: add optee_rpmb tests > > tee: remove common.h inclusion > > > > cmd/Kconfig| 4 +++- > > drivers/tee/broadcom/chimp_optee.c | 2 +- > > drivers/tee/optee/Kconfig | 2 +- > > drivers/tee/optee/core.c | 1 - > > drivers/tee/optee/i2c.c| 1 - > > drivers/tee/optee/rpmb.c | 1 - > > drivers/tee/optee/supplicant.c | 2 +- > > drivers/tee/sandbox.c | 10 +- > > drivers/tee/tee-uclass.c | 1 - > > test/py/tests/test_optee_rpmb.py | 20 > > 10 files changed, 31 insertions(+), 13 deletions(-) > > create mode 100644 test/py/tests/test_optee_rpmb.py > > > > -- > > 2.34.1 > > > > > Are there currently any comments/objections that can prevent these cosmetic > changes from being applied? If there are - just let me know, thanks Probably awaiting the next dev cycle, we're post RC3 now so it's mostly fixes landing ATM.
Re: [RFC PATCH 0/6] Clean up arm linker scripts
On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
wrote:
>
> The arm linker scripts had a mix of symbols and C defined variables in an
> effort to emit relative references instead of absolute ones e.g [0].
> This has led to confusion over the years, ending up with mixed section
> definitions. Some sections being defined with overlays and different
> definitions between v7 and v8 architectures.
> For example __efi_runtime_rel_start/end is defined as a linker symbol for
> armv8 and a C variable in armv7.
>
> I am not sure if this used to be a compiler bug, but linker scripts nowadays
> can emit relative references, as long as the symbol definition is contained
> within the section definition. So let's switch most of the C defined variables
Should we be setting/upping the minimum version of the linker version
as part of this?
> and clean up the arm sections.c file. There's still a few symbols remaining --
> __secure_start/end, __secure_stack_start/end and __end which can be cleaned up
> in a followup series.
>
> The resulting binary (tested in QEMU v7/v8) had no size differences apart from
> the emited sections and object types of those variables. I've also added
> prints
> throughout the U-Boot init sequence. The offsets and delta for 'end - start'
> section sizes is unchanged.
>
> For example on QEMU v8:
> $~ ./scripts/bloat-o-meter u-boot u-boot.new
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Function old new delta
> Total: Before=798861, After=798861, chg +0.00%
>
> $~ readelf -sW u-boot | grep bss_s
> 12: 001029b8 0 SECTION LOCAL DEFAULT 12 .bss_start
> 8088: 0018 0 NOTYPE GLOBAL DEFAULT1 _bss_start_ofs
> 8376: 001029b8 0 OBJECT GLOBAL DEFAULT 12 __bss_start
> $~ readelf -sW u-boot.new | grep bss_s
> 8085: 0018 0 NOTYPE GLOBAL DEFAULT1 _bss_start_ofs
> 8373: 001029b8 0 NOTYPE GLOBAL DEFAULT 12 __bss_start
>
> For QEMU v7 the differences are a bit bigger but only affect the variables
> placed in the .bss section because that was defined as an OVERLAY in the
> existing linker script.
> For example:
> $~ nm u-boot | grep tftp_prev_block
> 000ca0dc ? tftp_prev_block
> $~ nm u-boot.new | grep tftp_prev_block
> 000e0a5c b tftp_prev_block -> The symbol is now placed into .bss
>
> It's worth noting that since the efi regions are affected by the change,
> booting
> with EFI is preferable while testing. Booting the kernel only should be enough
> since the efi stub and the kernel proper do request boottime and runtime
> services respectively.
> Something along the lines of
> > virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r
> will work for QEMU aarch64.
>
> Tested platforms:
> - QEMU aarch64
> - Xilinx kv260 kria starter kit & zynq
> - QEMU armv7
> - STM32MP157C-DK2
>
> [0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__
> compiler-generated")
>
> Ilias Apalodimas (6):
> arm: baltos: remove custom linker script
> arm: clean up v7 and v8 linker scripts for bss_start/end
> arm: fix __efi_runtime_rel_start/end definitions
> arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end
> arm: fix __efi_runtime_start/end definitions
> arm: move image_copy_start/end to linker symbols
>
> arch/arm/cpu/armv8/u-boot-spl.lds | 14 +--
> arch/arm/cpu/armv8/u-boot.lds | 45 ++--
> arch/arm/cpu/u-boot.lds | 74 +++--
> arch/arm/lib/sections.c | 10 --
> arch/arm/mach-rockchip/u-boot-tpl-v8.lds | 22 +---
> arch/arm/mach-zynq/u-boot.lds | 72 +++-
> board/qualcomm/dragonboard820c/u-boot.lds | 41 ++-
> board/vscom/baltos/u-boot.lds | 128 --
> include/asm-generic/sections.h| 3 +
> lib/efi_loader/efi_runtime.c | 1 +
> 10 files changed, 58 insertions(+), 352 deletions(-)
> delete mode 100644 board/vscom/baltos/u-boot.lds
>
> --
> 2.37.2
>
[PATCH v2] disk: dos: Add all options for EFI System Partitions
The EFI spec states that the ESP can be any of FAT12/16/32 but for
compatibility doesn't necssarily require the partition to be the
EFI partition table ID of 0xef. A number of arm devices will not
find their firmware on a FAT partition with an ID of 0xef so also
allow the original FAT12/16/32 partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
v2:
- Add 0x0c option
- Make hex constants consistent
- Move from if to switch statement
disk/part_dos.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 567ead7511d..ab855adf347 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -40,10 +40,23 @@ static int get_bootable(dos_partition_t *p)
{
int ret = 0;
- if (p->sys_ind == 0xef)
+ switch (p->sys_ind){
+ case 0x01:
ret |= PART_EFI_SYSTEM_PARTITION;
- if (p->boot_ind == 0x80)
+ case 0x06:
+ ret |= PART_EFI_SYSTEM_PARTITION;
+ case 0x0b:
+ ret |= PART_EFI_SYSTEM_PARTITION;
+ case 0x0c:
+ ret |= PART_EFI_SYSTEM_PARTITION;
+ case 0xef:
+ ret |= PART_EFI_SYSTEM_PARTITION;
+ case 0x80:
ret |= PART_BOOTABLE;
+ default:
+ break;
+ }
+
return ret;
}
--
2.43.2
Re: Raspberry Pi 3b Plus USB-Ethernet lan78xx_eth address not set
Hi, > I have a Raspberry Pi 3B Plus which I want to integrate with U-boot > (v2023.10) . > > I am using rpi_3_32b_defconfig to generate u-boot.bin. But while booting I > am getting below error > > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > In:serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: No ethernet found. > starting USB... > Bus usb@7e98: USB DWC2 > scanning bus usb@7e98 for devices... > Error: lan78xx_eth address not set. > 3 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > > In the "bdinfo", "current eth" is not set The ethernet address is set by the ethaddr variable, it can be viewed by running printenv. That is then set to the ethernet0 alias in the device tree. > U-Boot> bdinfo > boot_params = 0x0100 > DRAM bank = 0x > -> start= 0x > -> size = 0x3b40 > flashstart = 0x > flashsize = 0x > flashoffset = 0x > baudrate= 115200 bps > relocaddr = 0x3b36 > reloc off = 0x3b358000 > Build = 32-bit > current eth = unknown > eth-1addr = (not set) > IP addr = > > I also enabled LAN75xx in menuconfig and re-compiled u-boot. But still the > same error. I believe the driver for the USB network interface on the 3B+ is the USB_ETHER_LAN78XX driver, > However on Raspberry Pi 3B, I don't see this error and "current eth" is set > to "smsc95xx_eth" and "ethaddr" is also available. Do you mean it's set at U-Boot stage or when you boot into Linux? Peter
Re: ECDSA related PRs
On Wed, 21 Feb 2024, 11:30 Bob Wolff, wrote: > Hi there, > I have two separate but related pull requests I'd like to contribute. They > both have to do with ECDSA support. > - The simple one is a lack of null-pointer check that can cause a crash in > certain situations. Easy peasy. > Just send that one on it's own - The less simple one (and hopefully not too controversial) adds an ecdsa > verify driver (UCLASS_ECDSA) which utilizes tinycrypt to do the crypto > work. > Do we already use tiny crypt in the project, if not things like license need to be taken into account in the context of the GPLv2 Please advise on how best to proceed. Happy to work within the confines of > what works best for the larger group. > > Thanks, > Bob Wolff >
Re: [PATCH v4 16/39] board: dragonboard410c: add chainloaded config fragment
On Thu, 15 Feb 2024 at 21:03, Caleb Connolly wrote: > > Add a config fragment for building U-Boot such that it can be > chainloaded by aboot/LK rather than being flashed directly to the aboot > partition. How does this work in practice? I think a lot of devices, one example I see is signed vs unsigned, or emmc vs other storage, have to configs, how would a user choose with LK vs the other option here? > Reviewed-by: Neil Armstrong > Signed-off-by: Caleb Connolly > --- > board/qualcomm/dragonboard410c/configs/chainloaded.config | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/board/qualcomm/dragonboard410c/configs/chainloaded.config > b/board/qualcomm/dragonboard410c/configs/chainloaded.config > new file mode 100644 > index ..3fd064924a1f > --- /dev/null > +++ b/board/qualcomm/dragonboard410c/configs/chainloaded.config > @@ -0,0 +1,7 @@ > +# CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set > +CONFIG_TEXT_BASE=0x0 > +# CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR is not set > +# CONFIG_REMAKE_ELF is not set > +CONFIG_POSITION_INDEPENDENT=y > +CONFIG_INIT_SP_RELATIVE=y > +CONFIG_SYS_INIT_SP_BSS_OFFSET=524288 > > -- > 2.43.1 >
Re: [PATCH] disk: dos: Add all options for EFI System Partitions
On Mon, 19 Feb 2024 at 10:24, Mark Kettenis wrote:
>
> > From: Peter Robinson
> > Date: Mon, 19 Feb 2024 09:12:15 +
> >
> > The EFI spec states that the ESP can be any of FAT12/16/32 but for
> > compatibility doesn't necssarily require the partition to be the
> > EFI partition table ID of 0xef. A number of arm devices will not
> > find their firmware on a FAT partition with an ID of 0xef so also
> > allow the original FAT12/16/32 partition IDs as they are also
> > permissable for an ESP.
>
> Hi Peter,
>
> Any reason not to include 0x0c as well? That is what we use on
> OpenBSD/armv7 and OpenBSD/arm64. And as far as I know all UEFI
> implementations (on arm64 at least) boot from such a partition.
I wasn't 100% the support with LBA so I erred with caution, but no
reason I can't add it.
> (And yes, we use that partition type because we want to have a
> bootable image that works on the various Raspberry Pi models).
Yes, that is the same reason for us, plus a few other random other Arm
devices that won't recognise EF as VFAT and won't boot.
> That said, what problem does this fix? And what happens if we have
> both a 0xea and a 0x01/0x06/0x0b/0x0c partition? In that case U-Boot
> should probably prefer the 0xea over the others as the ESP.
The reason is because the support to write EFI vars on ESP, and yes I
realise it's got security issues but for most boards it's the least of
their problem, as the support won't do that without the flag and you
get a bunch of these on boot:
No EFI system partition
Failed to persist EFI variables
As for multiple partitions UEFI should handle that and I believe the
EFI var support has logic around which partition it chooses.
> Oh, and while your're at it, the hex constants are a bit inconsistent
> (0x1/0x6 vs. 0x0b).
Will fix with v2 when I add 0x0c, I'll await other feedback for a bit.
Thanks,
Peter
> Cheers,
>
> Mark
>
> > Signed-off-by: Peter Robinson
> > ---
> > disk/part_dos.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/disk/part_dos.c b/disk/part_dos.c
> > index 567ead7511d..303eb1d13ee 100644
> > --- a/disk/part_dos.c
> > +++ b/disk/part_dos.c
> > @@ -40,6 +40,12 @@ static int get_bootable(dos_partition_t *p)
> > {
> > int ret = 0;
> >
> > + if (p->sys_ind == 0x1)
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > + if (p->sys_ind == 0x6)
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > + if (p->sys_ind == 0x0b)
> > + ret |= PART_EFI_SYSTEM_PARTITION;
> > if (p->sys_ind == 0xef)
> > ret |= PART_EFI_SYSTEM_PARTITION;
> > if (p->boot_ind == 0x80)
> > --
> > 2.43.1
> >
> >
[PATCH] disk: dos: Add all options for EFI System Partitions
The EFI spec states that the ESP can be any of FAT12/16/32 but for
compatibility doesn't necssarily require the partition to be the
EFI partition table ID of 0xef. A number of arm devices will not
find their firmware on a FAT partition with an ID of 0xef so also
allow the original FAT12/16/32 partition IDs as they are also
permissable for an ESP.
Signed-off-by: Peter Robinson
---
disk/part_dos.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 567ead7511d..303eb1d13ee 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -40,6 +40,12 @@ static int get_bootable(dos_partition_t *p)
{
int ret = 0;
+ if (p->sys_ind == 0x1)
+ ret |= PART_EFI_SYSTEM_PARTITION;
+ if (p->sys_ind == 0x6)
+ ret |= PART_EFI_SYSTEM_PARTITION;
+ if (p->sys_ind == 0x0b)
+ ret |= PART_EFI_SYSTEM_PARTITION;
if (p->sys_ind == 0xef)
ret |= PART_EFI_SYSTEM_PARTITION;
if (p->boot_ind == 0x80)
--
2.43.1
[PATCH 1/2] configs: ethernut5: Drop reiserfs
This is the only board that enables it, and looking generally I don't believe it's used. All use cases I could fine for the board rub by default off jffs on the nand and it doesn't enable USB storage. Signed-off-by: Peter Robinson Cc: egnite GmbH --- configs/ethernut5_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/ethernut5_defconfig b/configs/ethernut5_defconfig index bdd8f4db8b7..cc2f567c8a8 100644 --- a/configs/ethernut5_defconfig +++ b/configs/ethernut5_defconfig @@ -53,7 +53,6 @@ CONFIG_CMD_JFFS2=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nand0=atmel_nand" CONFIG_MTDPARTS_DEFAULT="mtdparts=atmel_nand:-(root)" -CONFIG_CMD_REISER=y CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_ENV_IS_IN_SPI_FLASH=y -- 2.43.1
[PATCH 2/2] fs: drop reiserfs
It was only included by a single board which doesn't appear to have
ever used it for any default use cases so drop the filesystem now
that isn't used by any in-tree configurations.
Signed-off-by: Peter Robinson
---
cmd/Kconfig| 9 -
cmd/reiser.c | 171 --
fs/Kconfig | 2 -
fs/Makefile| 1 -
fs/reiserfs/Kconfig| 0
fs/reiserfs/Makefile | 10 -
fs/reiserfs/dev.c | 28 -
fs/reiserfs/mode_string.c | 124 -
fs/reiserfs/reiserfs.c | 971 -
fs/reiserfs/reiserfs_private.h | 509 -
include/reiserfs.h | 72 ---
11 files changed, 1897 deletions(-)
delete mode 100644 cmd/reiser.c
delete mode 100644 fs/reiserfs/Kconfig
delete mode 100644 fs/reiserfs/Makefile
delete mode 100644 fs/reiserfs/dev.c
delete mode 100644 fs/reiserfs/mode_string.c
delete mode 100644 fs/reiserfs/reiserfs.c
delete mode 100644 fs/reiserfs/reiserfs_private.h
delete mode 100644 include/reiserfs.h
diff --git a/cmd/Kconfig b/cmd/Kconfig
index a854a4e8312..62ba7347dd4 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2751,15 +2751,6 @@ config MTDPARTS_DEFAULT
Defines a default MTD partitioning scheme in the Linux MTD command
line partitions format
-config CMD_REISER
- bool "reiser - Access to reiserfs filesystems"
- help
- This provides two commands which operate on a resierfs filesystem,
- commonly used some years ago:
-
- reiserls - list files
- reiserload - load a file
-
config CMD_YAFFS2
bool "yaffs2 - Access of YAFFS2 filesystem"
depends on YAFFS2
diff --git a/cmd/reiser.c b/cmd/reiser.c
deleted file mode 100644
index 707167fcd59..000
--- a/cmd/reiser.c
+++ /dev/null
@@ -1,171 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2003 - 2004
- * Sysgo Real-Time Solutions, AG
- * Pavel Bartusek
- */
-
-/*
- * Reiserfs support
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#if !CONFIG_IS_ENABLED(DOS_PARTITION)
-#error DOS partition support must be selected
-#endif
-
-/* #define REISER_DEBUG */
-
-#ifdef REISER_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
-#else
-#define PRINTF(fmt,args...)
-#endif
-
-int do_reiserls(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
-{
- char *filename = "/";
- int dev, part;
- struct blk_desc *dev_desc = NULL;
- struct disk_partition info;
-
- if (argc < 3)
- return CMD_RET_USAGE;
-
- part = blk_get_device_part_str(argv[1], argv[2], _desc, , 1);
- if (part < 0)
- return 1;
-
- if (argc == 4) {
- filename = argv[3];
- }
-
- dev = dev_desc->devnum;
- PRINTF("Using device %s %d:%d, directory: %s\n", argv[1], dev, part,
filename);
-
- reiserfs_set_blk_dev(dev_desc, );
-
- if (!reiserfs_mount(info.size)) {
- printf ("** Bad Reiserfs partition or disk - %s %d:%d **\n",
argv[1], dev, part);
- return 1;
- }
-
- if (reiserfs_ls (filename)) {
- printf ("** Error reiserfs_ls() **\n");
- return 1;
- };
-
- return 0;
-}
-
-U_BOOT_CMD(
- reiserls, 4, 1, do_reiserls,
- "list files in a directory (default /)",
- " [directory]\n"
- "- list files from 'dev' on 'interface' in a 'directory'"
-);
-
-/**
- * Reiserfs boot command intepreter. Derived from diskboot
- */
-int do_reiserload(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
-{
- char *filename = NULL;
- int dev, part;
- ulong addr = 0, filelen;
- struct disk_partition info;
- struct blk_desc *dev_desc = NULL;
- unsigned long count;
- char *addr_str;
-
- switch (argc) {
- case 3:
- addr_str = env_get("loadaddr");
- if (addr_str != NULL) {
- addr = hextoul(addr_str, NULL);
- } else {
- addr = CONFIG_SYS_LOAD_ADDR;
- }
- filename = env_get("bootfile");
- count = 0;
- break;
- case 4:
- addr = hextoul(argv[3], NULL);
- filename = env_get("bootfile");
- count = 0;
- break;
- case 5:
- addr = hextoul(argv[3], NULL);
- filename = argv[4];
- count = 0;
- break;
- case 6:
- addr = hextoul(argv[3], NULL);
- filename = argv[4];
- count = hextoul(
[PATCH 0/2] Drop reiserfs support
The reiserfs filesystem was only enabled by the ethernut5 which appears to use jffs on nand for all default usecases (Nut/OS, Yocto) and doesn't have USB Storage support enabled, but does have MMC. It's also scheduled for removal in upstream Linux. Looking at the logs for ethernut5 it doesn't actually appear to be actively maintained either for the best part of 10+ years but I don't remove that as part of this PR but leave it to someone who may know the AT91 ecosystem better than me. Peter Robinson (2): configs: ethernut5: Drop reiserfs fs: drop reiserfs cmd/Kconfig| 9 - cmd/reiser.c | 171 -- configs/ethernut5_defconfig| 1 - fs/Kconfig | 2 - fs/Makefile| 1 - fs/reiserfs/Kconfig| 0 fs/reiserfs/Makefile | 10 - fs/reiserfs/dev.c | 28 - fs/reiserfs/mode_string.c | 124 - fs/reiserfs/reiserfs.c | 971 - fs/reiserfs/reiserfs_private.h | 509 - include/reiserfs.h | 72 --- 12 files changed, 1898 deletions(-) delete mode 100644 cmd/reiser.c delete mode 100644 fs/reiserfs/Kconfig delete mode 100644 fs/reiserfs/Makefile delete mode 100644 fs/reiserfs/dev.c delete mode 100644 fs/reiserfs/mode_string.c delete mode 100644 fs/reiserfs/reiserfs.c delete mode 100644 fs/reiserfs/reiserfs_private.h delete mode 100644 include/reiserfs.h -- 2.43.1
Re: [PATCH 04/11] board: rockchip: Add a common ROCK Pi 4 target
On Sat, 17 Feb 2024 at 18:40, Jonas Karlman wrote:
>
> Move ROCK Pi 4 specific board code from the shared evb_rk3399 target
> into its own board target and update related defconfigs to use the new
> TARGET_ROCKPI4_RK3399 option.
>
> Also move the call to gpt_capsule_update_setup() from the weak function
> rk_board_late_init() into the main board_late_init() function.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Peter Robinson
Looks good.
> ---
> arch/arm/mach-rockchip/board.c| 10 +++---
> arch/arm/mach-rockchip/rk3399/Kconfig | 6
> board/radxa/rockpi4-rk3399/Kconfig| 15 +
> board/radxa/rockpi4-rk3399/MAINTAINERS| 29 +
> .../rockpi4-rk3399}/Makefile | 2 +-
> .../rockpi4-rk3399/rockpi4-rk3399.c} | 13 ++--
> board/rockchip/evb_rk3399/MAINTAINERS | 29 -
> configs/rock-4c-plus-rk3399_defconfig | 2 +-
> configs/rock-4se-rk3399_defconfig | 2 +-
> configs/rock-pi-4-rk3399_defconfig| 2 +-
> configs/rock-pi-4c-rk3399_defconfig | 2 +-
> include/configs/rk3399_common.h | 16 --
> include/configs/rockpi4-rk3399.h | 32 +++
> 13 files changed, 95 insertions(+), 65 deletions(-)
> create mode 100644 board/radxa/rockpi4-rk3399/Kconfig
> create mode 100644 board/radxa/rockpi4-rk3399/MAINTAINERS
> rename board/{rockchip/evb_rk3399 => radxa/rockpi4-rk3399}/Makefile (79%)
> rename board/{rockchip/evb_rk3399/evb-rk3399.c =>
> radxa/rockpi4-rk3399/rockpi4-rk3399.c} (79%)
> create mode 100644 include/configs/rockpi4-rk3399.h
>
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 4f666aee706f..dea5805c4665 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -34,7 +34,7 @@
> #include
> #include
>
> -#if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
> +#if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
> IS_ENABLED(CONFIG_EFI_PARTITION)
>
> #define DFU_ALT_BUF_LENSZ_1K
>
> @@ -185,10 +185,6 @@ static void gpt_capsule_update_setup(void)
>
> __weak int rk_board_late_init(void)
> {
> -#if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
> - gpt_capsule_update_setup();
> -#endif
> -
> return 0;
> }
>
> @@ -196,6 +192,10 @@ int board_late_init(void)
> {
> setup_boot_mode();
>
> +#if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) &&
> IS_ENABLED(CONFIG_EFI_PARTITION)
> + gpt_capsule_update_setup();
> +#endif
> +
> return rk_board_late_init();
> }
>
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig
> b/arch/arm/mach-rockchip/rk3399/Kconfig
> index d01063ac98b6..bf3600aee2ad 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -89,6 +89,11 @@ config TARGET_ROCK960_RK3399
>* 2x USB 3.0 type A, 2x USB 2.0 type A (host mode only),
> 1x USB 3.0 type C OTG
>
> +config TARGET_ROCKPI4_RK3399
> + bool "Radxa ROCK Pi 4 board"
> + help
> + Support for ROCK Pi 4 board family by Radxa.
> +
> config TARGET_ROCKPRO64_RK3399
> bool "Pine64 Rockpro64 board"
> help
> @@ -174,6 +179,7 @@ source "board/google/gru/Kconfig"
> source "board/pine64/pinebook-pro-rk3399/Kconfig"
> source "board/pine64/pinephone-pro-rk3399/Kconfig"
> source "board/pine64/rockpro64_rk3399/Kconfig"
> +source "board/radxa/rockpi4-rk3399/Kconfig"
> source "board/rockchip/evb_rk3399/Kconfig"
> source "board/theobroma-systems/puma_rk3399/Kconfig"
> source "board/vamrs/rock960_rk3399/Kconfig"
> diff --git a/board/radxa/rockpi4-rk3399/Kconfig
> b/board/radxa/rockpi4-rk3399/Kconfig
> new file mode 100644
> index ..d82663506b12
> --- /dev/null
> +++ b/board/radxa/rockpi4-rk3399/Kconfig
> @@ -0,0 +1,15 @@
> +if TARGET_ROCKPI4_RK3399
> +
> +config SYS_BOARD
> + default "rockpi4-rk3399"
> +
> +config SYS_VENDOR
> + default "radxa"
> +
> +config SYS_CONFIG_NAME
> + default "rockpi4-rk3399"
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> + def_bool y
> +
> +endif
> diff --git a/board/radxa/rockpi4-rk3399/MAINTAINERS
> b/board/radxa/rockpi4-rk3399/MAINTAINERS
> new file mode 100644
> index ..12d4f35af881
> --- /dev/null
> +++ b/board/radxa/rockpi4-rk3399/MAINTAINERS
>
[PATCH] remove Broadcom Northstar 2 Target entry
The Broadcom Northstar 2 support was removed when the
bcm958712k board was removed but the target entry was
missed so clean that up as well.
Fixes: d59bc09d829 ("arm: Remove bcm958712k board")
Signed-off-by: Peter Robinson
---
arch/arm/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b072be2463..9367287327d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,15 +699,6 @@ config TARGET_BCMNS
ARMv7 Cortex-A9 SoC family including BCM4708, BCM47094,
BCM5301x etc.
-config TARGET_BCMNS2
- bool "Support Broadcom Northstar2"
- select ARM64
- select GPIO_EXTRA_HEADER
- help
- Support for Broadcom Northstar 2 SoCs. NS2 is a quad-core 64-bit
- ARMv8 Cortex-A57 processors targeting a broad range of networking
- applications.
-
config TARGET_BCMNS3
bool "Support Broadcom NS3"
select ARM64
--
2.43.1
Re: Booting RPi5B with latest git
On Sat, 17 Feb 2024 at 16:53, John wrote: > > I am running Arch ARM on a RPi4B and also on a RPi5B. My RPi4B can boot the > vanilla kernel package (linux-aarch64) with the latest uboot-raspberrypi > (2024.04-rc2) just fine. Yet, if I take that uSD card and place it in my > RPi5B, it does not boot. I only see the "U-Boot" submarine logo in the upper > right of the screen/no debug output. Any thoughts are appreciated. > > I built u-boot like this: > > unset CFLAGS > unset CXXFLAGS > unset CPPFLAGS > > make rpi_arm64_config > echo 'CONFIG_IDENT_STRING=" Arch Linux ARM"' >> .config > make EXTRAVERSION=-2024.04rc2 Do you have a serial console to attach? The current support is very basic, I don't believe display output is supported yet, and thinks like USB for keyboard input most definitely isn't. Peter
Re: How To Move Root Partition From eMMC to SSD
> I am running the NanoPi R6C. The device is not capable of booting from > the SSD, the next best thing is to load the root filesystem from the SSD. By booting you mean loading the firmware from SSD (by which I think you mean NVME right). > Using rockchip's repos, I compile from source the images to boot 1) from > the microSD card and 2) from eMMC. I install to the eMMC. Then, so as > not to mount any partitions from eMMC, I boot from the microSD card, and > I clone the root partition from the eMMC (/dev/mmcblk2p8) to the SSD > (/dev/nvme0n1p1). > > I boot from the eMMC, the output of "cat /proc/cmdline" is: > > storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal > androidboot.dtbo_idx=0 androidboot.verifiedbootstate=orange > earlycon=uart8250,mmio32,0xfeb5 console=ttyFIQ0 coherent_pool=1m > irqchip.gicv3_pseudo_nmi=0 rw root=/dev/mmcblk2p8 rootfstype=ext4 > rootflags=discard data=/dev/mmcblk2p9 consoleblank=0 > cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 > androidboot.fwver=uboot-a83a7263ef-01/09/2024 > > How do I change "root=/dev/mmcblk2p8" to "root=/dev/nvme0n1p1"? > > I connect to the serial port and get to the U-Boot monitor. I examine > the variables. "bootcmd" runs "bootrkp" which boots the system. > "bootrkp" ignores "bootargs", I confirm this by deleting "bootargs" > before running "bootrkp", the system boots up as before with no change > in behavior. "bootrkp" is implemented in file "cmd/bootrkp.c". That > code emits the equivalent of: > > setenv bootm-no-reloc y > booti 0x40 0xa20:0x7b2bc0 0x830 > > Can I tell U-Boot to load the root partition from /dev/nvme0n1p1, either > by entering commands at the monitor, or by modifying the source code of > U-Boot, or through any other means? You don't mention what OS you're trying to load, is it Android? So upstream U-Boot can boot a Linux OS from NVME on a rk3588 device, but it appears you're using the Rockchip fork and I have no idea of the state of that. The upstream U-Boot doesn't yet have the R6C. Generally if a device doesn't have something like a SPI flash where you can put firmware it's fine to use the eMMC for firmware and it should be able to run an OS from NVME. If you're not using Android and are using a standard Linux distro I would look at enabling "distro boot" in the rockchip fork which will give you a standard UEFI boot interface and things should work. I have no idea if the U-Boot fork you're using includes PCI or NVME support but obviously make sure the appropriate drivers are enabled for that (look at the upstream Rock5B config). Unfortunately I can't offer much more help from there as I generally only deal with upstream. Peter
Re: Booting from NFSv4 file system?
On Tue, 13 Feb 2024 at 12:18, Cedric Blancher wrote: > > Good morning! > > Does U-Boot support booting from a NFSv4 file system? Explicitly > neither NFSv2 or NFSv3 will work in our case, as both protocol > versions are depreciated and no longer allowed by our IT department. Not that I am aware of, at least not upstream, there is work being done to support booting using UEFI HTTP boot if HTTP is more straight forward for network booting.
Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c
On Mon, 12 Feb 2024 at 14:16, Dragan Simic wrote: > > Hello Peter, > > On 2024-02-12 14:56, Peter Robinson wrote: > > On Fri, 9 Feb 2024 at 18:57, Dragan Simic wrote: > >> On 2024-02-09 19:36, Mark Kettenis wrote: > >> >> Date: Fri, 09 Feb 2024 18:58:01 +0100 > >> >> From: Dragan Simic > >> >> Please, see my comments below. > >> >> > >> >> On 2024-02-09 10:50, Quentin Schulz wrote: > >> >> > From: Quentin Schulz > >> >> > > >> >> > The functions aren't used anywhere else than in board.c, therefore, > >> >> > let's not expose them anymore at all. > >> >> > > >> >> > This merges misc.c and board.c together and removes the functions from > >> >> > the misc.h header file. > >> >> > >> >> The patches I'm going to send, which exclude the unneeded code > >> >> from the U-Boot images for the Pinebook Pro and the Pinebook Pro, > >> >> change the code that this patch moves around. > >> >> > >> >> Perhaps it would be better to have the move of the code and the > >> >> subsequent changes to it performed in a separate series, to make > >> >> checking and accepting the patches simpler as a group, and to > >> >> perhaps make it a bit more clear what actually happened to anyone > >> >> going through the repository history later. > >> >> > >> >> Thus, I was wondering would you, please, be fine with excluding > >> >> this patch from this series and letting me submit it, with proper > >> >> attribution tags, of course, as part of the series I'll submit > >> >> in the next couple of days? > >> > > >> > I'm not covinced your patches are a good idea. Unless we're running > >> > into space constraints, or if there are noticable slowdowns in the > >> > boot process because of the extra code, I really don't see what the > >> > benefit of further differentiation between rk3399 boards would be. It > >> > just makes testing things harder. > >> > >> Oh, I fully understand your position, but please let's also keep in > >> mind that the subject of those patches are actual devices with pretty > >> much fixed hardware configurations, instead of targeting development > >> boards whose actual hardware configurations, at least in theory, > >> depend on the user. > >> > >> In addition to preventing the unneeded code from entering the U-Boot > >> images, my patches would also prevent useless "ethaddr" and "eth1addr" > >> from appearing in the saved environments on those devices. I think > >> that's useful and may actually prevent some confusion when the saved > >> environment is checked by the users on those devices. > > > > Maybe that code should be guarded on if the wired ethernet is enabled > > or not. Would allow one code but the ability to disable it when the > > ethernet isn't used. > > Basically, we can't know for sure are the users going to supply > some DT overlays that add another Ethernet interface to an SBC, > for example a Fast Ethernet interface on RK3328-based SBCs, which > is the reason why we can't rely on the built-in DT to decide > whether to provide the stable MAC addresses or not. That will likely not be solvable with purely an overlay, they may need to enable drivers that aren't by default. > However, it's highly unlikely that an Ethernet interface is going > to be added to a fixed-configuration device such as the Pinebook > Pro or the Pinephone. Other than plugging in a USB Ethernet dongle, > that is, which already come with fixed MACA addresses. Thus, not > providing stable MAC addresses should be just fine for such fixed- > configuration devices. Don't disagree with that, which is why I did those configs like that. > >> > The smaller the number of special snow flakes, the better! > >> > >> I'd agree that having fewer special cases helps, but again, handling > >> the specifics of some devices also has its benefits. Additionally, > >> perhaps simply the fact that those are actual devices makes them some > >> kind of special snowflakes. :) > >> > >> >> > Cc: Quentin Schulz > >> >> > Reviewed-by: Kever Yang > >> >> > Signed-off-by: Quentin Schulz > >> >> > --- > >> >> > arch/arm/include/asm/arch-rockchip/misc.h | 5 -- > >> >> > arc
Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399
On Sat, 10 Feb 2024 at 06:32, Chen-Yu Tsai wrote: > > From: Chen-Yu Tsai > > Hi folks, > > This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328 > and RK3399 so that the cpuid is read from the efuse and used to generate > a serial number and MAC addresses for all boards. For the series: Reviewed-by: Peter Robinson > This stacks on top of the recent defconfig update series [1] from Jonas. > > [1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/ > > > Chen-Yu Tsai (4): > rockchip: rk3328: Read cpuid and generate MAC address from efuse > rockchip: rk3399: Read cpuid and generate MAC address from efuse > rockchip: rk3328: regenerate defconfigs > rockchip: rk3399: regenerate defconfigs > > arch/arm/mach-rockchip/Kconfig| 4 > configs/chromebook_bob_defconfig | 2 -- > configs/chromebook_kevin_defconfig| 2 -- > configs/evb-rk3328_defconfig | 2 -- > configs/firefly-rk3399_defconfig | 2 -- > configs/nanopi-r2c-plus-rk3328_defconfig | 2 -- > configs/nanopi-r2c-rk3328_defconfig | 2 -- > configs/nanopi-r2s-rk3328_defconfig | 2 -- > configs/nanopi-r4s-rk3399_defconfig | 2 -- > configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 -- > configs/orangepi-r1-plus-rk3328_defconfig | 2 -- > configs/pinebook-pro-rk3399_defconfig | 2 -- > configs/pinephone-pro-rk3399_defconfig| 2 -- > configs/puma-rk3399_defconfig | 2 -- > configs/roc-cc-rk3328_defconfig | 2 -- > configs/roc-pc-mezzanine-rk3399_defconfig | 2 -- > configs/roc-pc-rk3399_defconfig | 2 -- > configs/rock-4c-plus-rk3399_defconfig | 3 --- > configs/rock-4se-rk3399_defconfig | 3 --- > configs/rock-pi-4-rk3399_defconfig| 3 --- > configs/rock-pi-4c-rk3399_defconfig | 3 --- > configs/rock-pi-e-rk3328_defconfig| 2 -- > configs/rock-pi-n10-rk3399pro_defconfig | 1 - > configs/rock64-rk3328_defconfig | 2 -- > configs/rock960-rk3399_defconfig | 1 - > configs/rockpro64-rk3399_defconfig| 2 -- > 26 files changed, 4 insertions(+), 52 deletions(-) > > -- > 2.39.2 >
Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c
On Fri, 9 Feb 2024 at 18:57, Dragan Simic wrote: > > Hello Mark, > > On 2024-02-09 19:36, Mark Kettenis wrote: > >> Date: Fri, 09 Feb 2024 18:58:01 +0100 > >> From: Dragan Simic > >> Please, see my comments below. > >> > >> On 2024-02-09 10:50, Quentin Schulz wrote: > >> > From: Quentin Schulz > >> > > >> > The functions aren't used anywhere else than in board.c, therefore, > >> > let's not expose them anymore at all. > >> > > >> > This merges misc.c and board.c together and removes the functions from > >> > the misc.h header file. > >> > >> The patches I'm going to send, which exclude the unneeded code > >> from the U-Boot images for the Pinebook Pro and the Pinebook Pro, > >> change the code that this patch moves around. > >> > >> Perhaps it would be better to have the move of the code and the > >> subsequent changes to it performed in a separate series, to make > >> checking and accepting the patches simpler as a group, and to > >> perhaps make it a bit more clear what actually happened to anyone > >> going through the repository history later. > >> > >> Thus, I was wondering would you, please, be fine with excluding > >> this patch from this series and letting me submit it, with proper > >> attribution tags, of course, as part of the series I'll submit > >> in the next couple of days? > > > > I'm not covinced your patches are a good idea. Unless we're running > > into space constraints, or if there are noticable slowdowns in the > > boot process because of the extra code, I really don't see what the > > benefit of further differentiation between rk3399 boards would be. It > > just makes testing things harder. > > Oh, I fully understand your position, but please let's also keep in > mind that the subject of those patches are actual devices with pretty > much fixed hardware configurations, instead of targeting development > boards whose actual hardware configurations, at least in theory, > depend on the user. > > In addition to preventing the unneeded code from entering the U-Boot > images, my patches would also prevent useless "ethaddr" and "eth1addr" > from appearing in the saved environments on those devices. I think > that's useful and may actually prevent some confusion when the saved > environment is checked by the users on those devices. Maybe that code should be guarded on if the wired ethernet is enabled or not. Would allow one code but the ability to disable it when the ethernet isn't used. > > The smaller the number of special snow flakes, the better! > > I'd agree that having fewer special cases helps, but again, handling > the specifics of some devices also has its benefits. Additionally, > perhaps simply the fact that those are actual devices makes them some > kind of special snowflakes. :) > > >> > Cc: Quentin Schulz > >> > Reviewed-by: Kever Yang > >> > Signed-off-by: Quentin Schulz > >> > --- > >> > arch/arm/include/asm/arch-rockchip/misc.h | 5 -- > >> > arch/arm/mach-rockchip/Makefile | 1 - > >> > arch/arm/mach-rockchip/board.c| 125 > >> > +++ > >> > arch/arm/mach-rockchip/misc.c | 135 > >> > -- > >> > 4 files changed, 125 insertions(+), 141 deletions(-) > >> > > >> > diff --git a/arch/arm/include/asm/arch-rockchip/misc.h > >> > b/arch/arm/include/asm/arch-rockchip/misc.h > >> > index 4155af8c3b0..ef37ff1661a 100644 > >> > --- a/arch/arm/include/asm/arch-rockchip/misc.h > >> > +++ b/arch/arm/include/asm/arch-rockchip/misc.h > >> > @@ -6,9 +6,4 @@ > >> > * Rohan Garg > >> > */ > >> > > >> > -int rockchip_cpuid_from_efuse(const u32 cpuid_offset, > >> > -const u32 cpuid_length, > >> > -u8 *cpuid); > >> > -int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length); > >> > -int rockchip_setup_macaddr(void); > >> > void rockchip_capsule_update_board_setup(void); > >> > diff --git a/arch/arm/mach-rockchip/Makefile > >> > b/arch/arm/mach-rockchip/Makefile > >> > index 1dc92066bbf..c07bdaee4c3 100644 > >> > --- a/arch/arm/mach-rockchip/Makefile > >> > +++ b/arch/arm/mach-rockchip/Makefile > >> > @@ -23,7 +23,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) > >> > # meaning "turn it off". > >> > obj-y += boot_mode.o > >> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o > >> > -obj-$(CONFIG_MISC_INIT_R) += misc.o > >> > endif > >> > > >> > ifeq ($(CONFIG_TPL_BUILD),) > >> > diff --git a/arch/arm/mach-rockchip/board.c > >> > b/arch/arm/mach-rockchip/board.c > >> > index d5cb59c10fa..80b4514852f 100644 > >> > --- a/arch/arm/mach-rockchip/board.c > >> > +++ b/arch/arm/mach-rockchip/board.c > >> > @@ -1,20 +1,32 @@ > >> > // SPDX-License-Identifier: GPL-2.0+ > >> > /* > >> > * (C) Copyright 2019 Rockchip Electronics Co., Ltd. > >> > + * > >> > + * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/ > >> > + * Rohan Garg > >> > + * > >> > + * Based on puma-rk3399.c: > >> > + * (C) Copyright 2017
Re: [PATCH v2 10/20] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol
On Fri, 9 Feb 2024 at 09:50, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> There's only one user of rockchip_capsule_update_board_setup, which is
> in board.c, and only one board defines it, so instead of having a header
> only for one function symbol, let's just use a weak symbol instead.
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> arch/arm/include/asm/arch-rockchip/misc.h | 9 -
> arch/arm/mach-rockchip/board.c| 5 -
> 2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
> b/arch/arm/include/asm/arch-rockchip/misc.h
> deleted file mode 100644
> index ef37ff1661a..000
> --- a/arch/arm/include/asm/arch-rockchip/misc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * RK3399: Architecture common definitions
> - *
> - * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> - * Rohan Garg
> - */
> -
> -void rockchip_capsule_update_board_setup(void);
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 80b4514852f..4f666aee706 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -32,7 +32,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
> @@ -148,6 +147,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
> env_set("dfu_alt_info", buf);
> }
>
> +__weak void rockchip_capsule_update_board_setup(void)
> +{
> +}
> +
> static void gpt_capsule_update_setup(void)
> {
> int p, i, ret;
>
> --
> 2.43.0
>
Re: [PATCH v2 06/20] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r
On Fri, 9 Feb 2024 at 09:50, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> Only setup_iodomain() differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20 ++--
> 1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> index d79084614f1..d0a694ead1d 100644
> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> @@ -11,7 +11,6 @@
> #include
> #include
> #include
> -#include
>
> #define GRF_IO_VSEL_BT565_SHIFT 0
> #define PMUGRF_CON0_VSEL_SHIFT 8
> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
> rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
> }
>
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
> {
> - const u32 cpuid_offset = 0x7;
> - const u32 cpuid_length = 0x10;
> - u8 cpuid[cpuid_length];
> - int ret;
> -
> setup_iodomain();
>
> - ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> - if (ret)
> - return ret;
> -
> - ret = rockchip_cpuid_set(cpuid, cpuid_length);
> - if (ret)
> - return ret;
> -
> - ret = rockchip_setup_macaddr();
> -
> - return ret;
> + return 0;
> }
>
> #endif
>
> --
> 2.43.0
>
Re: [PATCH v2 05/20] rockchip: pine64: pinephone-pro: migrate to rockchip_early_misc_init_r
On Fri, 9 Feb 2024 at 09:50, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).
Same as for my comment on the Pinebook Pro, there's no wired ethernet
on these devices and the GMAC driver isn't enabled, I vaguely remember
we might have excluded rockchip_setup_macaddr because of an error but
that was some time ago.
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> .../pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c | 17
> ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> index b6ccbb9c1c4..de75ee329d8 100644
> --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> @@ -12,7 +12,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #define GRF_IO_VSEL_BT565_GPIO2AB 1
> @@ -56,23 +55,11 @@ static void setup_iodomain(void)
> rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
> }
>
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
> {
> - const u32 cpuid_offset = 0x7;
> - const u32 cpuid_length = 0x10;
> - u8 cpuid[cpuid_length];
> - int ret;
> -
> setup_iodomain();
>
> - ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> - if (ret)
> - return ret;
> -
> - ret = rockchip_cpuid_set(cpuid, cpuid_length);
> - if (ret)
> - return ret;
> + return 0;
>
> - return ret;
> }
> #endif
>
> --
> 2.43.0
>
Re: [PATCH v2 04/20] rockchip: pine64: pinebook-pro: migrate to rockchip_early_misc_init_r
On Fri, 9 Feb 2024 at 09:50, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).
The Pinebook Pro doesn't have onboard ethernet, nor an alias defined,
I wonder if rockchip_setup_macaddr should be gated on GMAC_ROCKCHIP or
something similar. Otherwise:
Reviewed-by: Peter Robinson
> Cc: Quentin Schulz
> Reviewed-by: Kever Yang
> Signed-off-by: Quentin Schulz
> ---
> board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18
> ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> index 4ad780767ea..2408a367305 100644
> --- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> +++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> @@ -11,7 +11,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
> @@ -54,23 +53,10 @@ static void setup_iodomain(void)
> rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
> }
>
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
> {
> - const u32 cpuid_offset = 0x7;
> - const u32 cpuid_length = 0x10;
> - u8 cpuid[cpuid_length];
> - int ret;
> -
> setup_iodomain();
>
> - ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> - if (ret)
> - return ret;
> -
> - ret = rockchip_cpuid_set(cpuid, cpuid_length);
> - if (ret)
> - return ret;
> -
> - return ret;
> + return 0;
> }
> #endif
>
> --
> 2.43.0
>
Re: [PATCH] sunxi: defconfig: Add pstore support for pinephone
On Sun, 11 Feb 2024 at 16:02, Andrey Skvortsov wrote: > > In general any DRAM address, that isn't overwritten during a boot is > suitable for pstore. What's this functionality providing? The details below give the technical reasons for the memory address but I'm not sure what enabling pstore provides to PinePhone users. > Range from 0x4000 - 0x5000 is heavily used by u-boot for > internal use and to load kernel, fdt, fdto, scripts, pxefile and ramdisk > later in the boot process. Ramdisk start address is 0x4FF0, > initramfs for kernel with some hacking features and debug info enabled > can take more than 100Mb and final address will be around 0x5800. > Address 0x6100 will most likely not overlap with that. > > Signed-off-by: Andrey Skvortsov > --- > configs/pinephone_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig > index 9d39204a43..7b80cc3131 100644 > --- a/configs/pinephone_defconfig > +++ b/configs/pinephone_defconfig > @@ -10,6 +10,8 @@ CONFIG_DRAM_ZQ=3881949 > CONFIG_MMC_SUNXI_SLOT_EXTRA=2 > CONFIG_PINEPHONE_DT_SELECTION=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_CMD_PSTORE=y > +CONFIG_CMD_PSTORE_MEM_ADDR=0x6100 > CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" > CONFIG_LED_STATUS=y > CONFIG_LED_STATUS_GPIO=y > -- > 2.43.0 >
Re: [RFC] Drop md5sum, crc32 and sha1 cmds in favor of hash cmd
On Wed, 7 Feb 2024 at 13:48, Tom Rini wrote: > > On Wed, Feb 07, 2024 at 02:00:16PM +0100, Igor Opaniuk wrote: > > Hello, > > > > I was playing a bit with different hash functions recently, and > > it turned out that md5sum, crc32, sha1 cmds just duplicate > > what is already covered by generic `hash` cmd. > > > > => sha1 0x6000 0x200 > > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 > > => hash sha1 0x6000 0x200 > > sha1 for 6000 ... 61ff ==> 4ff5ffc91d00a95155518b920f46e2483d0e1437 > > > > => crc32 0x6000 0x200 > > crc32 for 6000 ... 61ff ==> 6fe352e8 > > => hash crc32 0x6000 0x200 > > crc32 for 6000 ... 61ff ==> 6fe352e8 > > > > => md5sum 0x6000 0x200 > > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > > => hash md5 0x6000 0x200 > > md5 for 6000 ... 61ff ==> e6bbbe95f5b41996f4a9b9af7bbd4050 > > > > Considering that most of them (besides md5sum) are using the same > > int hash_command() function under the hood, but have a lot of duplicated > > code for handling params, does it make sense to do some cleanup and > > drop all them in favour `hash`? > > > > I also plan to extend usage info for `hash` by adding a list > > compiled-in algos based on hash related compiled flags > > (CONFIG_SHA1, CONFIG_CRC32 etc), so it's clear what algos > > are available for hash calculation. > > > > Comments/objections are welcome! > > It would be good, implementation wise, if each of those commands was > just a redirect to hash ..., similar to how "load " will call the > right filesystem calls. Does that make sense? Thanks. Yes, I actually have that one my todo list to basically alias the individual commands to the hash command to remove those commands. My intention there was a first step to allow us to eventually minimise or even remove the use of obsolete hashes etc.
Re: [GIT PULL] rpi: updates for v2024.04
On Wed, 31 Jan 2024 at 17:00, Matthias Brugger wrote: > > Hi Tom, > > Here come a small set of patches for v2024.04 for the RaspberryPi. > It adds basic support for RPi5 to be able to boot on a SD card. > > You can find the passing tests here: > https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/19512 > > It's the same commit ID as the tag, although it's not the same test-run. > > Regards, > Matthias > > --- > The following changes since commit 6faba41927bdc8973b59678649ef83c564cc421e: > >Prepare v2024.04-rc1 (2024-01-29 20:53:19 -0500) > > are available in the Git repository at: > >https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git > tags/rpi-next-2024.04 > > for you to fetch changes up to 12d479d01849c164020e17c3ae921f974b96372d: > >configs: rpi_arm64: build position independent code (2024-01-30 17:40:13 > +0100) > > ---- > Add RaspberryPi5 basic support. Acked-by: Peter Robinson > > Dmitry Malkin (2): >rpi5: add initial memory map for bcm2712 >rpi5: Use devicetree as alternative way to read IO base addresses > > Ivan T. Ivanov (5): >rpi5: Use devicetree to retrieve board revision >bcm2835: Dynamically calculate bytes per pixel parameter >mmc: bcmstb: Add support for bcm2712 SD controller >configs: rpi_arm64: enable SDHCI BCMSTB driver >configs: rpi_arm64: build position independent code > > arch/arm/mach-bcm283x/include/mach/base.h | 5 +- > arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- > arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- > arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- > arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- > arch/arm/mach-bcm283x/init.c | 74 > ++ > board/raspberrypi/rpi/rpi.c| 22 +++-- > configs/rpi_arm64_defconfig| 3 +- > drivers/mmc/bcmstb_sdhci.c | 64 -- > drivers/video/bcm2835.c| 18 +++- > 10 files changed, 171 insertions(+), 27 deletions(-)
Re: [PATCH v2 2/4] cmd: provide command to display SMBIOS information
On Thu, 25 Jan 2024 at 03:02, Heinrich Schuchardt wrote: > > On 1/24/24 22:16, Tom Rini wrote: > > On Wed, Jan 17, 2024 at 04:33:45PM +0100, Heinrich Schuchardt wrote: > > > >> U-Boot can either generated an SMBIOS table or copy it from a prior boot > >> stage, e.g. QEMU. > >> > >> Provide a command to display the SMBIOS information. > >> > >> Currently only type 1 and 2 are translated to human readable text. > >> Other types may be added later. Currently only a hexdump and the list of > >> strings is provided for these. > >> > >> Signed-off-by: Heinrich Schuchardt > >> Reviewed-by: Simon Glass > >> Reviewed-by: Ilias Apalodimas > > [snip] > >> @@ -227,6 +227,13 @@ config CMD_SBI > >> help > >>Display information about the SBI implementation. > >> > >> +config CMD_SMBIOS > >> +bool "smbios" > >> +depends on SMBIOS > >> +default y > >> +help > >> + Display the SMBIOS information. > >> + > > > > So this would be enabled (today) on 888 boards and is a bit more than a > > kilobyte. I think we can just let this be enabled as needed in > > defconfigs? > > > > As needed would be the boards where we want to run the related Python > test. Sandbox and QEMU should be good enough? Yes, I think for most users seeing the smbios tables is probably not particularly useful.
Re: [PATCH v1 1/1] cmd: bootmenu: rename U-Boot console to Exit
On Sun, 14 Jan 2024 at 10:23, Svyatoslav Ryhel wrote:
>
> It seems that the U-Boot console entry of the bootmenu has lost
> its original meaning. Now, even if it is chosen, the probability
> that you will enter the actual U-Boot console is quite low.
> Boot env, bootflow, bootcommand script may appear, but not the
> actual console. Hense, let's remove ambiguity and name this
Hence
> entry by what it actually does: 'Exit' the bootmenu.
>
> Signed-off-by: Svyatoslav Ryhel
> ---
> cmd/bootmenu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
> index 987b16889f..69fca710a8 100644
> --- a/cmd/bootmenu.c
> +++ b/cmd/bootmenu.c
> @@ -119,7 +119,7 @@ static char *bootmenu_choice_entry(void *data)
> iter = iter->next;
> return iter->key;
> case BKEY_QUIT:
> - /* Quit by choosing the last entry - U-Boot console */
> + /* Quit by choosing the last entry - Exit */
I think just put "Set the last entry to Exit"
> iter = menu->first;
> while (iter->next)
> iter = iter->next;
> @@ -361,15 +361,15 @@ static struct bootmenu_data *bootmenu_create(int delay)
> }
> #endif
>
> - /* Add U-Boot console entry at the end */
> + /* Add Exit entry at the end */
> if (i <= MAX_COUNT - 1) {
> entry = malloc(sizeof(struct bootmenu_entry));
> if (!entry)
> goto cleanup;
>
> - /* Add Quit entry if entering U-Boot console is disabled */
> + /* Add Quit entry if exiting to U-Boot console is disabled */
s/Quit/Exit/
> if (!IS_ENABLED(CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE))
> - entry->title = strdup("U-Boot console");
> + entry->title = strdup("Exit");
> else
> entry->title = strdup("Quit");
>
> @@ -532,7 +532,7 @@ static enum bootmenu_ret bootmenu_show(int delay)
> title = strdup(iter->title);
> command = strdup(iter->command);
>
> - /* last entry is U-Boot console or Quit */
> + /* last entry is Exit or Quit */
"Last entry is Exit" as I don't see Quit referred to.
> if (iter->num == iter->menu->count - 1) {
> ret = BOOTMENU_RET_QUIT;
> goto cleanup;
> --
> 2.40.1
>
Re: [PATCH] mach-snapdragon: Move APQ8016 SoC derived board code
On Wed, Jan 3, 2024 at 2:03 PM Tom Rini wrote: > > On Wed, Jan 03, 2024 at 06:37:16PM +0530, Sumit Garg wrote: > > [snip] > > Tom, Simon, > > > > Is there any U-Boot policy in regards to board code going forward? Are > > we moving in a direction to get rid of most board specific stubs from > > generic U-Boot code? > > There's not a policy, no. But this brings this platform more in to line > with others (assorted TI SoCs) that already have "board" files under > arch/arm/mach-foo as most of the board hooks are already abstracted such > that it's per-SoC with only an occasional further hook for true > board-specific changes. I think AQP8016 is a QCom device (db410c) not a TI device.
Re: [PATCH v5 08/12] smbios: Drop support for SMBIOS2 tables
On Sun, Dec 31, 2023 at 3:26 PM Simon Glass wrote:
>
> These tables are a pain since there is no way to handle memory above
> 4GB. Use SMBIOS3 always.
>
> This should hopefully not create problems on x86 devices, since SMBIOS3
> was released seven years ago (2015).
>
> Signed-off-by: Simon Glass
Reviewed-by: Peter Robinson
It's also worth noting here the aarch64 Server Base Boot Requirements
(SBBR) has required SMBIOS v3 since version 1.0 of the spec [1].
[1] https://documentation-service.arm.com/static/5fb7e5adca04df4095c1d64d
> ---
>
> Changes in v5:
> - Add new patch to drop support for SMBIOS2 tables
>
> lib/smbios.c | 76
> 1 file changed, 17 insertions(+), 59 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index cfd451e4088..d9d52bd58d7 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -545,13 +545,12 @@ ulong write_smbios_table(ulong addr)
> {
> ofnode parent_node = ofnode_null();
> ulong table_addr, start_addr;
> + struct smbios3_entry *se;
> struct smbios_ctx ctx;
> ulong tables;
> int len = 0;
> int max_struct_size = 0;
> int handle = 0;
> - char *istart;
> - int isize;
> int i;
>
> ctx.node = ofnode_null();
> @@ -565,12 +564,8 @@ ulong write_smbios_table(ulong addr)
>
> start_addr = addr;
>
> - /*
> -* So far we don't know which struct will be used, but they both end
> -* up using the same amount of 16-bit-aligned space
> -*/
> - addr += max(sizeof(struct smbios_entry), sizeof(struct
> smbios3_entry));
> - addr = ALIGN(addr, 16);
> + /* move past the (so-far-unwritten) header to start writing structs */
> + addr = ALIGN(addr + sizeof(struct smbios3_entry), 16);
> tables = addr;
>
> /* populate minimum required tables */
> @@ -592,59 +587,22 @@ ulong write_smbios_table(ulong addr)
> * We must use a pointer here so things work correctly on sandbox. The
> * user of this table is not aware of the mapping of addresses to
> * sandbox's DRAM buffer.
> -*
> -* Check the address of the end of the tables. If it is above 4GB then
> -* it is sensible to use SMBIOS3 even if the start of the table is
> below
> -* 4GB (this case is very unlikely to happen in practice)
> */
> table_addr = (ulong)map_sysmem(tables, 0);
> - if (sizeof(table_addr) > sizeof(u32) && addr >= (ulong)UINT_MAX) {
> - struct smbios3_entry *se;
> - /*
> -* We need to put this >32-bit pointer into the table but the
> -* field is only 32 bits wide.
> -*/
> - log_debug("WARNING: Using SMBIOS3.0 due to table-address
> overflow %lx\n",
> - table_addr);
> - se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> - memset(se, '\0', sizeof(struct smbios_entry));
> - memcpy(se->anchor, "_SM3_", 5);
> - se->length = sizeof(struct smbios3_entry);
> - se->major_ver = SMBIOS_MAJOR_VER;
> - se->minor_ver = SMBIOS_MINOR_VER;
> - se->doc_rev = 0;
> - se->entry_point_rev = 1;
> - se->max_struct_size = len;
> - se->struct_table_address = table_addr;
> - se->checksum = table_compute_checksum(se,
> - sizeof(struct smbios3_entry));
> - } else {
> - struct smbios_entry *se;
> -
> - se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> - memset(se, '\0', sizeof(struct smbios_entry));
> - memcpy(se->anchor, "_SM_", 4);
> - se->length = sizeof(struct smbios_entry);
> - se->major_ver = SMBIOS_MAJOR_VER;
> - se->minor_ver = SMBIOS_MINOR_VER;
> - se->max_struct_size = max_struct_size;
> - memcpy(se->intermediate_anchor, "_DMI_", 5);
> - se->struct_table_length = len;
> -
> - se->struct_table_address = table_addr;
> -
> - se->struct_count = handle;
> -
> - /* calculate checksums */
> - istart = (char *)se + SMBIOS_INTERMEDIATE_OFFSET;
> - isize = sizeof(struct smbios_entry) -
> - SMBIOS_INTERMEDIATE_OFFSET;
> - se->intermediate_checksum = table_compute_chec
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
On Mon, Oct 23, 2023 at 4:55 PM Mark Kettenis wrote: > > > From: Simon Glass > > Date: Mon, 23 Oct 2023 00:08:40 -0700 > > > > > > fdt_node_check_compatible() does most of the work...then you need to > > > > check which FDT has the most specific match (i.e. latest in the string > > > > list). That handles things like board revisions, variants, etc. > > > > > > > > My concern is about adding a feature when there is already a defined > > > > spec and mechanism for this to work. What happens when we load the > > > > file and the compatible is wrong? > > > > > > > > At best, I see the filename as a hint. > > > > > > > > [Perhaps this is the wrong time to ask, but why are kernels +DT not > > > > shipped in FIT on ARM?] > > > > > > FIT is U-Boot specific. For Linux distributions it is easier to use a > > > firmware agnostic method of booting. > > > > I'd like to suggest that distros use both. Then U-Boot can work as it > > was designed and we can avoid these work-arounds. > > > > FIT is actually implemented in various other bootloaders. In fact > > perhaps grub is the only one that doesn't? I can't think of any > > others. > > Simon, please stop pushing this. OpenBSD's bootloader does not > support FIT and we have no interest in supporting it. Our users > expect to be able to just copy a new kernel in place and use it and > our OS upgrade procedure depends on this as well. And this is > incompatble with FIT. I've explained this about a dozen times to you > now. For reference Fedora and related ecosystems have no interest in supporting FIT either, we have enough moving targets, we're not supporting more, it's very much why we're focused on UEFI, it provides one way, one kernel, for booting all various different devices we actively support in main Fedora, it's very much the way the x86 ecosystem has gone as well as the aarch64 server ecosystem. Fedora has no interest in using FIT in this context either. Peter
Re: [PATCH 3/5] cmd: provide command to display SMBIOS information
On Sat, Dec 23, 2023 at 12:53 AM Heinrich Schuchardt wrote:
>
> U-Boot can either generated an SMBIOS table or copy it from a prior boot
> stage, e.g. QEMU.
>
> Provide a command to display the SMBIOS information.
>
> Currently only type 1 and 2 are translated to human readable text.
> Other types may be added later. Currently only a hexdump and the list of
> strings is provided for these.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/Kconfig | 7 ++
> cmd/Makefile | 1 +
> cmd/smbios.c | 191 +++
> 3 files changed, 199 insertions(+)
> create mode 100644 cmd/smbios.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 5a7678f0ac..580aeec8ee 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -206,6 +206,13 @@ config CMD_SBI
> help
> Display information about the SBI implementation.
>
> +config CMD_SMBIOS
> + bool "smbios"
> + depends on SMBIOS
> + default y
Should this be default? Maybe default if SMBIOS or similar?
> + help
> + Display the SMBIOS information.
> +
> endmenu
>
> menu "Boot commands"
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 5ed0e4011d..8a5dfd8ca9 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -168,6 +168,7 @@ obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
> obj-$(CONFIG_CMD_SETEXPR_FMT) += printf.o
> obj-$(CONFIG_CMD_SPI) += spi.o
> obj-$(CONFIG_CMD_STRINGS) += strings.o
> +obj-$(CONFIG_CMD_SMBIOS) += smbios.o
> obj-$(CONFIG_CMD_SMC) += smccc.o
> obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o
> obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o
> diff --git a/cmd/smbios.c b/cmd/smbios.c
> new file mode 100644
> index 00..63f908e92c
> --- /dev/null
> +++ b/cmd/smbios.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * The 'smbios' command displays information from the SMBIOS table.
> + *
> + * Copyright (c) 2023, Heinrich Schuchardt
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/**
> + * smbios_get_string() - get SMBIOS string from table
> + *
> + * @table: SMBIOS table
> + * @index: index of the string
> + * Return: address of string, may point to empty string
> + */
> +static const char *smbios_get_string(void *table, int index)
> +{
> + const char *str = (char *)table +
> + ((struct smbios_header *)table)->length;
> +
> + if (!*str)
> + ++str;
> + for (--index; *str && index; --index)
> + str += strlen(str) + 1;
> +
> + return str;
> +}
> +
> +static struct smbios_header *next_table(struct smbios_header *table)
> +{
> + const char *str;
> +
> + if (table->type == SMBIOS_END_OF_TABLE)
> + return NULL;
> +
> + str = smbios_get_string(table, 0);
> + return (struct smbios_header *)(++str);
> +}
> +
> +static void smbios_print_generic(struct smbios_header *table)
> +{
> + char *str = (char *)table + table->length;
> +
> + if (CONFIG_IS_ENABLED(HEXDUMP)) {
> + printf("Header and Data:\n");
> + print_hex_dump("\t", DUMP_PREFIX_OFFSET, 16, 1,
> + table, table->length, false);
> + }
> + if (*str) {
> + printf("Strings:\n");
> + for (int index = 1; *str; ++index) {
> + printf("\tString %u: %s\n", index, str);
> + str += strlen(str) + 1;
> + }
> + }
> +}
> +
> +void smbios_print_str(const char *label, void *table, u8 index)
> +{
> + printf("\t%s: %s\n", label, smbios_get_string(table, index));
> +}
> +
> +static void smbios_print_type1(struct smbios_type1 *table)
> +{
> + printf("System Information\n");
> + smbios_print_str("Manufacturer", table, table->manufacturer);
> + smbios_print_str("Product Name", table, table->product_name);
> + smbios_print_str("Version", table, table->version);
> + smbios_print_str("Serial Number", table, table->serial_number);
> + if (table->length >= 0x19) {
> + printf("\tUUID %pUl\n", table->uuid);
> + smbios_print_str("Wake Up Type", table, table->serial_number);
> + }
> + if (table->length >= 0x1b) {
> + smbios_print_str("Serial Number", table,
> table->serial_number);
> + smbios_print_str("SKU Number", table, table->sku_number);
> + }
> +}
> +
> +static void smbios_print_type2(struct smbios_type2 *table)
> +{
> + u16 *handle;
> +
> + printf("Base Board Information\n");
> + smbios_print_str("Manufacturer", table, table->manufacturer);
> + smbios_print_str("Product Name", table, table->product_name);
> + smbios_print_str("Version", table, table->version);
> + smbios_print_str("Serial Number", table, table->serial_number);
> + smbios_print_str("Asset Tag", table,
Re: [PATCH 0/9] dts: Move to SoC-specific build rules
On Fri, Dec 29, 2023 at 12:23 AM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote: > > Hi Tom, > > > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini wrote: > > > > > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini wrote: > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini wrote: > > > > > > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass wrote: > > > > > > > > > > > > > > > U-Boot builds devicetree binaries from its source tree. As part > > > > > > > > of the > > > > > > > > Kconfig conversion, the Makefiles were updated to align with > > > > > > > > how this > > > > > > > > is done in Linux: a single target for each SoC is used to build > > > > > > > > all the > > > > > > > > .dtb files for that SoC. > > > > > > > > > > > > > > > > Since then, the Makefiles have devolved in some cases, > > > > > > > > resulting in > > > > > > > > lots of target-specific build rules. Also Linux has moved to > > > > > > > > using > > > > > > > > subdirectories for each vendor. > > > > > > > > > > > > > > > > Recent work aims to allow U-Boot to directly use devicetree > > > > > > > > files from > > > > > > > > Linux. This would be easier if the directory structure were the > > > > > > > > same. > > > > > > > > Another recent discussion involved dropping the build rules > > > > > > > > altogether. > > > > > > > > > > > > > > > > This series makes a start at cleaning up some of the build > > > > > > > > rules, to > > > > > > > > reduce the amount of code and make it easier to add new boards > > > > > > > > for the > > > > > > > > same SoC. > > > > > > > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options between U-Boot > > > > > > > > and Linux > > > > > > > > are not always the same. Given the large number of SoCs and > > > > > > > > boards > > > > > > > > supported by U-Boot, it would be useful to align these where > > > > > > > > possible. > > > > > > > > > > > > > > I don't know why we should start with this now, and further not > > > > > > > being on > > > > > > > top of Sumit's series to remove our duplicate dts files. And > > > > > > > that's > > > > > > > where we can have the conversation about for which cases it even > > > > > > > makes > > > > > > > sense to build all of the dts files for a given SoC. > > > > > > > > > > > > This is a completely different series - there are no conflicts with > > > > > > Sumit's series so it can be applied before or after it. > > > > > > > > > > > > My goal here is to clean up our build rules, rather than just > > > > > > throwing > > > > > > them all away, for reasons we have discussed previously. I filed [1] > > > > > > to track that. > > > > > > > > > > Yes, I'm saying we shouldn't be doing anything this series does until > > > > > after Sumit's series has landed. Along with the fact that I don't like > > > > > what's going on in this series. > > > > > > > > This seems to again be the disagreement over whether a single DT > > > > should be build for each board, or all the DTs for an SoC? > > > > > > It's about the disagreement on what we should be building, and what that > > > infrastructure looks like. I do not like adding extra rules for > > > "clarity" because they don't make things clearer, they lead to the > > > unclear mess we have today getting worse. Most instructions are _not_ > > > "now take this dtb and this binary and .." but just "take this binary", > > > because we already have the rules and logic to ensure we build the > > > required dtbs. I also don't like the parts of this series that amount > > > to deck shuffling when we should just be taking the chairs away. There's > > > just not nor will there be a case for omap3/4/5 platforms of "change the > > > dtb", so building more is pointless. For other SoCs, there may be some > > > cases of "this could have been just a DT change", like > > > rock5b-rk3588_defconfig / rock5a-rk3588s_defconfig could share a board > > > dir, but the configs are different and the dts are different, so I don't > > > know that you could really just swap the dtbs. > > > > It is true that we have a different defconfig for each board, but IMO > > that is not good. It is an artifact of the way the build system works. > > IMO Kconfig should be used to define sensible defaults so that the > > defconfigs are nearly empty. Perhaps config fragments can be part of > > the mix, if we can agree on [1]. > > > > But if we let this genie out of the bottle, it will be impossible to > > put back in. The devicetree should control the hardware in U-Boot and > > it should be possible to use the same U-Boot proper on all boards > > which use the same SoC. > > We've never been past the point where a few examples of closely related > boards can re-use the same U-Boot build and just
Re: [PATCH 1/1] bootmeth: pass size to efi_binary_run()
On Fri, Dec 22, 2023 at 3:37 PM Tom Rini wrote: > > On Fri, 22 Dec 2023 16:01:56 +0100, Heinrich Schuchardt wrote: > > > If we call efi_binary_run() with size parameter set to zero, we get an error > > > > Not a PE-COFF file > > > > Fill the missing value. > > > > > > [...] > > Applied to u-boot/next, thanks! Is this a fix that should land for 2024.01?
Re: [PATCH 2/2 v3] smbios: Fallback to the default DT if sysinfo nodes are missing
On Sat, Dec 16, 2023 at 6:57 PM Simon Glass wrote: > > Hi Tom, > > On Thu, 14 Dec 2023 at 06:11, Tom Rini wrote: > > > > On Wed, Dec 13, 2023 at 08:19:11PM -0700, Simon Glass wrote: > > > > [snip] > > > The new DT nodes / SMBIOS binding [1] allows for the correct > > > information to be provided, though. > > [snip] > > > [1] > > > https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/sysinfo/smbios.txt > > > > I think the only feedback I can give on your message here is to please > > go upstream that binding, and then we can see what to do afterwards. > > I am still tearing my hair out waiting for the reserved-memory and > binman patches to be accepted. Every few weeks there is another > comment, but no action. Rob seems to be the only one engaged. > > Perhaps I should do a conference talk about what is wrong with DT? > This is my experience so far: > > - there is no urgency to apply anything > - no one wins acclaim for applying a patch > - everyone complains later if a patch is applied that they didn't agree with > - people chime in wanting to understand the use case, but don't/can't/won't > - any sort of expressed doubt results in delay > - maintainers hope that the submitter will lose interest and go away > - not enough people add review tags, even if they look at it >... because they are worried about looking bad to others on the ML You miss this: * Patch submitter ignores questions, feedback, concerns from maintainers to the point that people mute the thread > I would be happy to discuss how to improve matters, but that is what I see. > > Anyway, the lowest-hanging fruit at present is the U-Boot /options > stuff. I was hoping someone else would step up to clean it up. There > should be no impediment. > > Regards, > Simon
Re: [PATCH 2/2 v3] smbios: Fallback to the default DT if sysinfo nodes are missing
> > > > Maybe we need to turn this discussion on its head slightly. What do you > > > > want to do to get SMBIOS fields to be widely populated with > > > > generally-correct information? What we have been doing has seen very > > > > little adoption so we need something else. > > > > > > Well, who or what is actually using this info? Is the problem just > > > that it doesn't actually matter, so no one bothers? I'm just not sure. > > > > Users are using this information. Peter has explained that Fedora has > > been carrying Ilias' original version of this patch since it was posted > > so that bug reports say (something close enough and that can be tracked > > down) what device they're on, rather than "Unknown" / "Unknown Product". > > Unfortunately I failed to get the latest Fedora running on rpi4. Is > this the only ARM board it supports a download for? (I must be missing > something) We support 100s of devices, I replied to your query there. Let's keep that conversation on that thread. > Anyway, so this presumably requires EFI? If so, this is the kind of > vertical integration and legacy promotion that really frustrates me. > If not, then what is the mechanism to supply SMBIOS to user space? I don't know what you mean by legacy in this context, UEFI is far from legacy and is being actively developed, it's widely used across enterprise and numerous other verticals. It seems by legacy you mean "Not used by ChromeOS" sure > I believe we have been here before, too. What program is used to > collect the bug reports? Is it sos, perhaps? There's literally 100s across enterprise platforms, some open, some closed. Two used in Fedora are: sosreport: https://github.com/sosreport/sos cockpit management: https://github.com/cockpit-project/cockpit/ But even in Fedora there's dozens more and with enterprise management platforms I suspect there's 100s or more. > > > The fact that on ARM you cannot pass it to the kernel without EFI > > > might be inhibiting its usefulness, too? Usefulness is the key > > > question for me. > > > > I'm setting aside the discussion of how one will tell the kernel where > > the SMBIOS is, outside of EFI as it's not a U-Boot problem and belongs > > on other lists. > > OK, but in my mind this is a concern. > > > > > > Anyway, my suggestion (once we understand why we care about SMBIOS > > > tables) is patches like we just saw from rockpro64, perhaps even with > > > a few more fields filled out. This series seems like a backup for > > > board maintainers that don't care, which is fine, but we should at > > > least be able to disable it. > > > > The issue is that this series adds, for free, useful and sufficiently > > correct information in the common cases. The "for free" is a huge > > feature too. Drawing on the rockpro64 patch, I would suggest seeing if > > /version (or /hardware-rev or whatever) is something Rob is interested > > in adding so it can be something filled out or not and then pulled from > > DT instead of a new set of DT nodes that look a whole lot like the > > existing DT nodes and properties that already exist. > > The new DT nodes / SMBIOS binding [1] allows for the correct > information to be provided, though. You are completely ignoring the numerous points that myself, Tom and others have made. > I'm fine with this as a Kconfig option, but it is a hack. It purports > to provide SMBIOS info but (for both of the two fields it fills in) it > is not in the correct format. It only works with EFI. If someone comes > along and adds the proper info for a board, the name will change in > the bug reports. Keep beating that drum and ignoring everyone else's opinions. This patch set in my opinion sets two fields, I have ideas around expanding it out to fll out more of the information. Just like DM or numerous other ideas you have they start with initial useful things and expand with time. > Which system-info tool is used? I see that hardinfo records the model > [2] and produces a sensible name for the compatible string [3]. > > Regards, > Simon > > [1] > https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/sysinfo/smbios.txt > [2] https://github.com/lpereira/hardinfo/blob/master/modules/devices.c#L547 > [3] > https://github.com/lpereira/hardinfo/blob/master/modules/devices/arm/processor.c#L433
Re: [PATCH 1/2 v2] smbios: Simplify reporting of unknown values
Hi Simon, > > > > > Hmm I don't know, but I wonder why I am not just checking t->bios_ver > > > > > for Unknown. > > > > > I'll have a look and change it > > > > > > > > Ok, this can't be changed as easily. smbios_add_prop() will not > > > > return NULL in any case. It returns an integer. With the cleanup, it > > > > will always writes 'Uknown' and not return 0 anymore. > > > > I can add that default value you suggested but the ctx->last_str is > > > > still used on the next line anyway. > > > > > > Would you mind if I tried to create a version of the patch which does > > > the same thing but with less code, and perhaps a test? It might be > > > easier to discuss it then. I can't claim to understand all the > > > different code paths at this point. > > > > > > My main concern is that with so many code paths it will be hard even > > > to refactor the code in the future, since it will become > > > 'load-bearing' and anyone might turn up and say it breaks their board > > > because different information is provided. > > > > I don't buy this argument at all, sorry. > > OK. > > > > > > Overall, so long as the information isn't used for anything important > > > in userspace, and we find a way to report SMBIOS to Linux without EFI, > > > > No, you can't tie random requirements to improving the SMBIOS support. > > We *already* report SMBIOS to Linux, reporting SMBIOS to Linux without > > EFI is changing things that will need different or extra standards, > > that could take years. > > > > You are arbitrarily adding extra requirements just to suite yourself, > > please STOP trying to hold things like this hostage. > > Isn't that what is happening with Linux and ffi? My understanding is > that there is no way to pass SMBIOS to Linux without EFI. Is that > correct? I know some people at their wit's end about that. Maybe the uses that want to go from a minimal firmware straight to a minimal kernel don't care about SMBIOS tables for their use cases, things don't need to be full parity to move forward the existing well defined usecase. > You may know that I have tried for years to get bindings upstream to > Linuxright now there is a reserved-memory binding which has been > held up for longer than I can remember, because of EFI. How about a > little give and take? I actually caught up on the reserved-memory binding thread a week or so ago and my general thoughts from that thread was that there was a lot of outstanding questions being asked of you that you haven't clearly articulated or even replied to and the thread ended with you asking a number of times "can this be merged now?" and my thought at the time was "No, because there's a bunch of outstanding details". May I suggest you re-read that thread and take some notes while you do so and make sure all the outstanding questions have been answered and reply with a single response addressing the remaining details, from there we may be able to move on. > > > > > it is OK to enable this feature (with a new Kconfig so it can be > > > disabled). But there is already authoritative info in the DT, so this > > > > There is two types of information in DT, the smbios "entries" in DT > > are not standardised in the dtschema and in most cases they're > > unnecessarily replicating data ALREADY in DT which is being produced > > automatically with these patches, making it zero effort for vendors to > > produce. > > > > > transformation into SMBIOS really should just be used for user > > > display, etc., not for anything which affects operation of the device. > > > > Well SMBIOS tables are used for a number of different things already > > in the kernel. > > > > > Do you agree? If you do, how to ensure that? Perhaps a special string > > > in the table like 'GENERATED'? > > > > Nope, I do not agree, at all. > > OK, well there it is. > > Anyway, as I said, I am happy for this to go in with a Kconfig > controlling it (so it can be enabled/disabled). Then SoCs that don't > want to go to the bother of adding authoritative info can just enable > this Kconfig. > > I would very much like to see some signal that it is not > authoritative. That should not be a big imposition. > > For my own interest, I would like to understand what actually uses it > as I suspect it is just for display. The two programs I managed to > find both handle devicetree and don't need SMBIOS. > > Regards, > Simon
Re: Adding EFI runtime support to the Arm's FF-A bus
On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas wrote: > > Hi Michael > > On Tue, 19 Dec 2023 at 14:47, Michael Walle wrote: > > > > Hi Mark, > > > > >> > Any runtime device drivers for variable storage should not be in the > > >> > U-Boot runtime but live in the secure world (e.g. OP-TEE) FF-A is the > > >> > new ARM protocol for talking to the secure world and hence fits into > > >> > the picture. > > >> > > >> What if I just want a simple embedded boot stack where I don't > > >> want any secure world and just want to be able to boot a COTS linux > > >> distribution via EFI? > > > > > > That already works for many Linux distros. As long as the distro > > > installs the appropriate BOOTxxx.EFI file you don't actually need to > > > set any EFI variables for the OS to boot. It can't get any simpler > > > than that. Of the main Linux distros it seems that only Debian > > > doesn't do this. Someone should probably lobby Debian to do this as > > > well as it would mean that Debian would just work on an EBBR compliant > > > system. > > > > I know. Last time I checked CentOS (or was it Ubuntu?) tried to > > set EFI variables and the installer just failed. Might be fixed now, > > though. > > It's not. The error message is less scary in distros nowadays, but > setting the variable for Boot is still not working. That being > said I have a plan to fix it for variables stored in a file, that's > why we standardized the efi variable format in EBBR. The actual error is coming from efibootmgr, which is the tool trying to set the variable and is just passed up to installers. It's now mostly a soft error as if you confirm the error the device still boots via the EFI Fallback methods. > > > > > Things get more complicated if you want to install multiple OSes. > > > Then having EFI variable support makes things a lot more > > > straightforward. > > > > > > And of course EFI secure boot needs EFI variable support as well (with > > > proper support) for authenticated EFI variables. But IMHO that no > > > longer falls into "simple embedded boot stack" territory. > > > > Thats clear. > > > > >> Assuming, that there might be a simple dedicated EEPROM to store the > > >> variables which is not exposed to linux, is that something which would > > >> be rejected by u-boot mainline now? > > Depends by 'not exposed'. And keep in mind that with a simple SPI > flash you also have to worry about easy hardware attacks. E.g. someone > replaces your SPI flash with his version of authenticated EFI > variables. > > We have patches on the ML adding variable support to SPI a SPI flash, > but excluding authenticated variables. [0] > > > > > > > Not necessarily. But such an approach will have limitations: > > > > > > * Completely hiding the EEPROM from the OS may be hard. Even if you > > > have a dedicated SPI controller for the EEPROM things like the SPI > > > bus clock or power domains may still be under OS control. > > > > Fair point, but I was thinking about the ls1028a for example, where - if > > I remember correctly - there was one dedicated i2c controller in a sense > > of isolation, probably to use with a secure OS. Also there is no dynamic > > clocking. > > > > So, technically it should be possible, even with a low overhead, like no> > > device model etc, which could reside in the efi os services. Just > > testing > > the waters here, not that I'm interested in adding support for that in > > u-boot. Just a bit concerned that it (EFI variables) will only work with > > a full stack (tf-a, optee) in the future. > > > > > * It is not possible to properly implement authenticated variables for > > > secure boot if the EEPROM and associated hardware is just removed > > > from the device tree but still accessable to the OS. An > > > implementation that pretends the variables are "secure" will > > > probably be rejected. > > That would be an EEPROM dedicated to the secure world. At some point, > I got involved with an EDK2 implementation for supporting EFI > variables on a SolidRun honeycomb. We even fixed SetVariableRT and we > run the whole thing via OP-TEE (just like we do for RPMB in U-Boot). > So this (minus the physical attacks) is quite secure, because even the > code running the crypto checks for authenticating variables, runs > isolated in the secure world. > > It's been a while, but IIRC StMM has FVBs (firmware block protocols) > in EDK2 parlance. We have StMM FVBs for RPMBs and EEPROMs and we can > launch StMM from OP-TEE. Adding runtime variable support for the RPMB > is close to impossible if you want to adhere to the EFI spec, but for > it's doable for the EEPROM. > > Ping me on IRC if you start adding support, I can help. > > > > > Sure. I excluded any secure stuff. But, with that i2c controller i was > > talking about earlier, it should be possible to mark it as EL3 access > > only. > > Yes, there was a slight implication. NXP some had timer on that I2C or > something, but it's been too long to
[PATCH] test: fs: fs-test: Move the tests to use sha256sum
Move the use of md5s for recording filesystem file integrity
checks to sha256 hashes as they're preferred due to being
less likely to produce clashing hashes. In the process
generalise some of the wording to use the more generic
hash term.
Signed-off-by: Peter Robinson
---
test/fs/fs-test.sh | 118 ++---
1 file changed, 59 insertions(+), 59 deletions(-)
diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
index dec2634de37..257b50fd063 100755
--- a/test/fs/fs-test.sh
+++ b/test/fs/fs-test.sh
@@ -23,7 +23,7 @@
#
# pre-requisite binaries list.
-PREREQ_BINS="md5sum mkfs mount umount dd fallocate mkdir"
+PREREQ_BINS="sha256sum mkfs mount umount dd fallocate mkdir"
# All generated output files from this test will be in $OUT_DIR
# Hence everything is sandboxed.
@@ -44,9 +44,9 @@ SMALL_FILE="1MB.file"
# $BIG_FILE is the name of the 2.5GB file in the file system image
BIG_FILE="2.5GB.file"
-# $MD5_FILE will have the expected md5s when we do the test
+# $HASH_FILE will have the expected hashes when we do the test
# They shall have a suffix which represents their file system (ext4/fat16/...)
-MD5_FILE="${OUT_DIR}/md5s.list"
+HASH_FILE="${OUT_DIR}/hash.list"
# $OUT shall be the prefix of the test output. Their suffix will be .out
OUT="${OUT_DIR}/fs-test"
@@ -103,7 +103,7 @@ function compile_sandbox() {
# Clean out all generated files other than the file system images
# We save time by not deleting and recreating the file system images
function prepare_env() {
- rm -f ${MD5_FILE}.* ${OUT}.*
+ rm -f ${HASH_FILE}.* ${OUT}.*
mkdir -p ${OUT_DIR}
}
@@ -254,14 +254,14 @@ setenv filesize
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_SMALL
printenv filesize
# Test Case 4b - Read full 1MB of small file
-md5sum $addr \$filesize
+hash sha256 $addr \$filesize
setenv filesize
# Test Case 5a - First 1MB of big file
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_BIG $length 0x0
printenv filesize
# Test Case 5b - First 1MB of big file
-md5sum $addr \$filesize
+hash sha256 $addr \$filesize
setenv filesize
# fails for ext as no offset support
@@ -269,7 +269,7 @@ setenv filesize
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_BIG $length 0x9C30
printenv filesize
# Test Case 6b - Last 1MB of big file
-md5sum $addr \$filesize
+hash sha256 $addr \$filesize
setenv filesize
# fails for ext as no offset support
@@ -277,7 +277,7 @@ setenv filesize
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_BIG $length 0x7FF0
printenv filesize
# Test Case 7b - One from the last 1MB chunk of 2GB
-md5sum $addr \$filesize
+hash sha256 $addr \$filesize
setenv filesize
# fails for ext as no offset support
@@ -285,7 +285,7 @@ setenv filesize
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_BIG $length 0x8000
printenv filesize
# Test Case 8b - One from the start 1MB chunk from 2GB
-md5sum $addr \$filesize
+hash sha256 $addr \$filesize
setenv filesize
# fails for ext as no offset support
@@ -293,7 +293,7 @@ setenv filesize
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_BIG $length 0x7FF8
printenv filesize
# Test Case 9b - One 1MB chunk crossing the 2GB boundary
-md5sum $addr \$filesize
+hash sha256 $addr \$filesize
setenv filesize
# Generic failure case
@@ -309,8 +309,8 @@ ${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_SMALL
${PREFIX}${WRITE} host${SUFFIX} $addr ${FPATH}$FILE_WRITE \$filesize
mw.b $addr 00 100
${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_WRITE
-# Test Case 11b - Check md5 of written to is same as the one read from
-md5sum $addr \$filesize
+# Test Case 11b - Check hash of written to is same as the one read from
+hash sha256 $addr \$filesize
setenv filesize
#
@@ -327,13 +327,13 @@ ${PREFIX}load host${SUFFIX} $addr ${FPATH}$FILE_SMALL
${PREFIX}${WRITE} host${SUFFIX} $addr ${FPATH}./${FILE_WRITE}2 \$filesize
mw.b $addr 00 100
${PREFIX}load host${SUFFIX} $addr ${FPATH}./${FILE_WRITE}2
-# Test Case 13b - Check md5 of written to is same as the one read from
-md5sum $addr \$filesize
+# Test Case 13b - Check hash of written to is same as the one read from
+hash sha256 $addr \$filesize
setenv filesize
mw.b $addr 00 100
${PREFIX}load host${SUFFIX} $addr ${FPATH}${FILE_WRITE}2
-# Test Case 13c - Check md5 of written to is same as the one read from
-md5sum $addr \$filesize
+# Test Case 13c - Check hash of written to is same as the one read from
+ hasheshash sha256 $addr \$filesize
setenv filesize
#
reset
@@ -342,7 +342,7 @@ EOF
}
# 1st argument is the name of the image file.
-# 2nd argument is the file where we generate the md5s of the files
+# 2nd argument is the file where we generate the hashes of the files
# generated with the appropriate start and length that we use to test.
# It creates the necessary files in the image to test.
# $GB2p5 is the path of the big file (2
Re: [PATCH 1/2 v2] smbios: Simplify reporting of unknown values
Hi Simon,
On Mon, Dec 18, 2023 at 3:02 PM Simon Glass wrote:
>
> Hi Ilias,
>
> On Wed, 6 Dec 2023 at 04:36, Ilias Apalodimas
> wrote:
> >
> > [...]
> >
> > >
> > >>
> > >> > str = "Unknown";
> > >> >
> > >> > for (;;) {
> > >> > @@ -151,8 +151,7 @@ static int smbios_add_prop_si(struct smbios_ctx
> > >> > *ctx, const char *prop,
> > >> > const char *str;
> > >> >
> > >> > str = ofnode_read_string(ctx->node, prop);
> > >> > - if (str)
> > >> > - return smbios_add_string(ctx, str);
> > >> > + return smbios_add_string(ctx, str);
> > >> > }
> > >> >
> > >> > return 0;
> > >> > @@ -231,7 +230,7 @@ static int smbios_write_type0(ulong *current, int
> > >> > handle,
> > >> > t->vendor = smbios_add_string(ctx, "U-Boot");
> > >> >
> > >> > t->bios_ver = smbios_add_prop(ctx, "version");
> > >> > - if (!t->bios_ver)
> > >> > + if (!strcmp(ctx->last_str, "Unknown"))
> > >>
> > >> That is really ugly...checking the ctx value looking for a side effect.
> > >>
> > >> Can you not have smbios_add_prop() continue to return NULL in this case?
> > >
> > >
> > > Hmm I don't know, but I wonder why I am not just checking t->bios_ver for
> > > Unknown.
> > > I'll have a look and change it
> >
> > Ok, this can't be changed as easily. smbios_add_prop() will not
> > return NULL in any case. It returns an integer. With the cleanup, it
> > will always writes 'Uknown' and not return 0 anymore.
> > I can add that default value you suggested but the ctx->last_str is
> > still used on the next line anyway.
>
> Would you mind if I tried to create a version of the patch which does
> the same thing but with less code, and perhaps a test? It might be
> easier to discuss it then. I can't claim to understand all the
> different code paths at this point.
>
> My main concern is that with so many code paths it will be hard even
> to refactor the code in the future, since it will become
> 'load-bearing' and anyone might turn up and say it breaks their board
> because different information is provided.
I don't buy this argument at all, sorry.
> Overall, so long as the information isn't used for anything important
> in userspace, and we find a way to report SMBIOS to Linux without EFI,
No, you can't tie random requirements to improving the SMBIOS support.
We *already* report SMBIOS to Linux, reporting SMBIOS to Linux without
EFI is changing things that will need different or extra standards,
that could take years.
You are arbitrarily adding extra requirements just to suite yourself,
please STOP trying to hold things like this hostage.
> it is OK to enable this feature (with a new Kconfig so it can be
> disabled). But there is already authoritative info in the DT, so this
There is two types of information in DT, the smbios "entries" in DT
are not standardised in the dtschema and in most cases they're
unnecessarily replicating data ALREADY in DT which is being produced
automatically with these patches, making it zero effort for vendors to
produce.
> transformation into SMBIOS really should just be used for user
> display, etc., not for anything which affects operation of the device.
Well SMBIOS tables are used for a number of different things already
in the kernel.
> Do you agree? If you do, how to ensure that? Perhaps a special string
> in the table like 'GENERATED'?
Nope, I do not agree, at all.
Regards,
Peter
Re: [PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing
> > > > What do you mean wrong, exactly? > > > > > > "raspberrypi" instead of "Raspberry Pi", for example, or "friendlyarm" > > > instead of "FriendlyElec" > > > > Heh, well, even in the x86 world vendors can't even spell their own > > name consistently. > > > > > I just wonder what this information is actually used for. If it is > > > just for fun, that is fine, but I believe some tools do use dmidecode, > > > at which point it needs to be accurate and should not change later, > > > e.g. when someone decides to actually add the info. > > > > So the Linux kernel uses this information to apply quirks for specific > > machines. But I hope that on platforms that have a device tree folks > > will just use the board compatible string for that purpose. > > Right. > > > > > Otherwise I think this information is mostly used to populate system > > information UIs and asset databases. > > So perhaps the devicetree should be used instead? How do these things > work today? And what are they, exactly? Device tree used for what? To populate the SMBIOS tables? Or to populate "system information UIs and asset databases." If you mean the later, that is not going to work. These platforms are often proprietary, and are generally remote. They have local agents that use dmidecode to populate things for support and management. It's kind of in the name "System Management". To get all these platforms updated to "just use devicetree" will take decades. No thanks!
Re: [PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing
> > > > > > Not always. I am not sure if x86 does that, but on the rest of the > > > > > > architectures, they are only initialized when the efi smbios code > > > > > > runs. Wasn't this something you were trying to change? > > > > > > > > > > One of those things I keep repeating is that we don't know for sure > > > > > what > > > > > the right values here are until we load the DT the OS _will_ use. It's > > > > > quite valid to start U-Boot and pass it a generic "good enough" DT at > > > > > run time until U-Boot can see (GPIOs, EEPROM, whatever) what it's on > > > > > and > > > > > what the real DT to load before passing to the OS is. Since U-Boot > > > > > doesn't need SMBIOS tables itself, we should make these "late" not > > > > > "early". > > > > > > > > Fair enough, we can defer the init and testing of those late, just > > > > before we are about to boot. But this is irrelevant to what this patch > > > > does, can we get the fallback mechanism in first, assuming everyone is > > > > ok with the patch now? > > > > > > > > > > I would like this behind a Kconfig. Making it the default means people > > > are going to start relying on (in user space) and then discover later > > > that it is wrong. > > > > What do you mean wrong, exactly? > > "raspberrypi" instead of "Raspberry Pi", for example, or "friendlyarm" > instead of "FriendlyElec" Well "raspberrypi" is better that what we get on the Raspberry Pi with my testing at the moment which is "Unknown", which from what I can tell from commit 330419727 should have at least the minimal amount but it doesn't. > I just wonder what this information is actually used for. If it is > just for fun, that is fine, but I believe some tools do use dmidecode, > at which point it needs to be accurate and should not change later, > e.g. when someone decides to actually add the info. So a lot of tools use the output of dmidecode, it's used extensively through various support platforms and management tools. In Fedora I would generally get around a dozen reports every few months because anything booted with U-Boot was basically populated with "Unknown". At the moment, on the RPi4 with default upstream I get Unkown [1] with these patches I get at least some useful information [2]. I've been shipping this patch set, in various versions, for a while and have not had a single bug report about wrong information. When Ilias and I first spoke about these patches the intention was to get initial useful information, them they could be possibly expanded using things like information from eFuses (serial numbers etc). In some cases with U-Boot you get SMBIOS tables that are incorrect and crash the tools. With this patch set you get at least the basics which is important because support teams can easily work out the basics of what they're working with even if they don't have physical access all without the vendor of the HW having to work out what to do in firmware to make something work. This patch set moves the needle forward, if we wait for everything to be properly formatted we will wait for ever, with information we already have available ON EVERY DEVICE. Peter [1] https://pbrobinson.fedorapeople.org/dmi-decode-rpi-defaults.txt [2] https://pbrobinson.fedorapeople.org/dmi-decode-rpi-auto-fallback-patchset.txt
Re: How to boot Fedora 39
Hi Simon, Sorry for the delayed response, I was out with COVID. > I tried the instructions here with a rpi4: > > https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#_installing_fedora_on_a_raspberry_pi_for_linux_users > > xzcat Fedora-Workstation-39-1.5.aarch64.raw.xz | sudo dd > status=progress bs=4M of=/dev/sdb > 16843096064 bytes (17 GB, 16 GiB) copied, 151 s, 112 MB/s > 0+2051288 records in > 0+2051288 records out > 17179869184 bytes (17 GB, 16 GiB) copied, 152.023 s, 113 MB/s Hmm, I have not had any reports of Workstation failing to boot. Did you check the sha256sum against the published ones to make sure it came down properly? I generally do all my U-Boot testing with the Minimal spin as it's a little more straight forward for low level debugging like boots as it doesn't have fun things like btrfs and graphical stacks. You can get the F-39 one here: https://dl.fedoraproject.org/pub/fedora-secondary/releases/39/Spins/aarch64/images/Fedora-Minimal-39-1.5.aarch64.raw.xz Let me know how you get on. Peter > > Then booted: > > > U-Boot 2023.07 (Oct 25 2023 - 00:00:00 +) > > DRAM: 992 MiB (effective 3.9 GiB) > RPI 4 Model B (0xc03111) > Core: 211 devices, 17 uclasses, devicetree: board > MMC: mmcnr@7e30: 1, mmc@7e34: 0 > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > In:serial > Out: vidconsole > Err: vidconsole > Net: eth0: ethernet@7d58 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus usb@7e98: USB DWC2 > Bus xhci_pci: Register 5000420 NbrPorts 5 > Starting the controller > USB XHCI 1.00 > scanning bus usb@7e98 for devices... 1 USB Device(s) found > scanning bus xhci_pci for devices... 3 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > 966711 bytes read in 105 ms (8.8 MiB/s) > Card did not respond to voltage select! : -110 > No EFI system partition > No EFI system partition > Failed to persist EFI variables > Booting /efi\boot\bootaa64.efi > No EFI system partition > Failed to persist EFI variables > No EFI system partition > Failed to persist EFI variables > No EFI system partition > Failed to persist EFI variables > error: ../../grub-core/commands/search.c:315:no such device: > 77e306d4-532a-4d8c-b023-5bde5c8689ac. > > > >GRUB version 2.06 > >Minimal BASH-like line editing is supported. For the first word, > TAB lists >possible command completions. Anywhere else TAB lists possible > device or file >completions. > > > grub> > > > I looked at the partition list and don't see that GUID, but perhaps > U-Boot is missing some config? > > U-Boot> part list mmc 0 > > Partition Map for MMC device 0 -- Partition Type: DOS > > PartStart SectorNum Sectors UUIDType > 1 20481228800 7d51a49c-01 06 Boot > 2 1230848 2097152 7d51a49c-02 83 > 3 3328000 302264327d51a49c-03 83 > U-Boot> > > Regards, > Simon
Re: [PATCH 2/2 v3] smbios: Fallback to the default DT if sysinfo nodes are missing
On Thu, Dec 7, 2023 at 12:57 PM Ilias Apalodimas
wrote:
>
> In order to fill in the SMBIOS tables U-Boot currently relies on a
> "u-boot,sysinfo-smbios" compatible node. This is fine for the boards
> that already include such nodes. However with some recent EFI changes,
> the majority of boards can boot up distros, which usually rely on
> things like dmidecode etc for their reporting. For boards that
> lack this special node the SMBIOS output looks like:
>
> System Information
> Manufacturer: Unknown
> Product Name: Unknown
> Version: Unknown
> Serial Number: Unknown
> UUID: Not Settable
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
>
> This looks problematic since most of the info are "Unknown". The DT spec
> specifies standard properties containing relevant information like
> 'model' and 'compatible' for which the suggested format is
> . Unfortunately the 'model' string found in DTs is
> usually lacking the manufacturer so we can't use it for both
> 'Manufacturer' and 'Product Name' SMBIOS entries reliably.
>
> So let's add a last resort to our current smbios parsing. If none of
> the sysinfo properties are found, scan for those information in the
> root node of the device tree. Use the 'model' to fill the 'Product
> Name' and the first value of 'compatible' for the 'Manufacturer', since
> that always contains one.
>
> pre-patch:
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Unknown
> Product Name: Unknown
> Version: Unknown
> Serial Number: 1bb24ceb
> UUID: 30303031-3030-3030-3061-613234636435
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> and post patch:
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: raspberrypi
> Product Name: Raspberry Pi 4 Model B Rev 1.1
> Version: Unknown
> Serial Number: 1bb24ceb
> UUID: 30303031-3030-3030-3061-613234636435
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> Signed-off-by: Ilias Apalodimas
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
> ---
> Simon, I'll work with tou on the refactoring you wanted and
> remove the EFI requirement of SMBIOS in !x86 platforms.
> Since this code has no tests, I'll add some once the refactoring
> is done
>
> Changes since v2:
> - Spelling mistakes
> - rebase on top of patch #1 changes
> Changes since v1:
> - Tokenize the DT node entry and use the appropriate value instead of
> the entire string
> - Removed Peters tested/reviewed-by tags due to the above
> lib/smbios.c | 94 +---
> 1 file changed, 89 insertions(+), 5 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 444aa245a273..3f0e1d529537 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -9,11 +9,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> +#include
> #ifdef CONFIG_CPU
> #include
> #include
> @@ -43,6 +46,25 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +/**
> + * struct map_sysinfo - Mapping of sysinfo strings to DT
> + *
> + * @sysinfo_str: sysinfo string
> + * @dt_str: DT string
> + * @max: Max index of the tokenized string to pick. Counting starts from 0
> + *
> + */
> +struct map_sysinfo {
> + const char *sysinfo_str;
> + const char *dt_str;
> + int max;
> +};
> +
> +static const struct map_sysinfo sysinfo_to_dt[] = {
> + { .sysinfo_str = "product", .dt_str = "model", 2 },
> + { .sysinfo_str = "manufacturer", .dt_str = "compatible", 1 },
> +};
> +
> /**
> * struct smbios_ctx - context for writing SMBIOS tables
> *
> @@ -87,6 +109,18 @@ struct smbios_write_method {
> const char *subnode_name;
> };
>
> +static const struct map_sysinfo *convert_sysinfo_to_dt(const char
> *sysinfo_str)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(sysinfo_to_dt); i++) {
> + if (!strcmp(sysinfo_str, sysinfo_to_dt[i].sysinfo_str))
> + return _to_dt[i];
> + }
> +
> + return NULL;
> +}
> +
> /**
> * smbios_add_string() - add a string to the string area
> *
> @@ -124,6 +158,42 @@ static int smbios_add_string(struct smbios_ctx *ctx,
> const char *str)
> }
> }
>
> +/**
> + * get_
Re: [PATCH 1/2 v3] smbios: Simplify reporting of unknown values
On Thu, Dec 7, 2023 at 10:17 PM Ilias Apalodimas
wrote:
>
> If a value is not valid during the DT or SYSINFO parsing, we explicitly
> set that to "Unknown Product" and "Unknown" for the product and
> manufacturer respectively. It's cleaner if we move the checks insisde
> smbios_add_prop_si() and provide an alternative string in case the
> primary is NULL or empty
>
> pre-patch dmidecode
>
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Unknown
> Product Name: Unknown Product
> Version: Not Specified
> Serial Number: Not Specified
> UUID: Not Settable
> Wake-up Type: Reserved
> SKU Number: Not Specified
> Family: Not Specified
>
> [...]
>
> post-patch dmidecode:
>
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Unknown
> Product Name: Unknown
> Version: Unknown
> Serial Number: Unknown
> UUID: Not Settable
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> While at it make smbios_add_prop_si() add a string directly if the prop
> node is NULL and replace smbios_add_string() calls with
> smbios_add_prop_si(ctx, NULL, )
>
> Signed-off-by: Ilias Apalodimas
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
> ---
> Changes since v2:
> - refactor even more code and remove the smbios_add_string calls from the
> main code. Instead use smbios_add_prop() foir everything and add a
> default value, in case the parsed one is NULL or emtpy
> Changes since v1:
> - None
>
> lib/smbios.c | 73 +---
> 1 file changed, 35 insertions(+), 38 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index d7f4999e8b2a..444aa245a273 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -102,9 +102,6 @@ static int smbios_add_string(struct smbios_ctx *ctx,
> const char *str)
> int i = 1;
> char *p = ctx->eos;
>
> - if (!*str)
> - str = "Unknown";
> -
> for (;;) {
> if (!*p) {
> ctx->last_str = p;
> @@ -134,11 +131,18 @@ static int smbios_add_string(struct smbios_ctx *ctx,
> const char *str)
> *
> * @ctx: context for writing the tables
> * @prop: property to write
> + * @dval: Default value to use if the string is not found or is empty
> * Return: 0 if not found, else SMBIOS string number (1 or more)
> */
> static int smbios_add_prop_si(struct smbios_ctx *ctx, const char *prop,
> - int sysinfo_id)
> + int sysinfo_id, const char *dval)
> {
> + if (!dval || !*dval)
> + dval = "Unknown";
> +
> + if (!prop)
> + return smbios_add_string(ctx, dval);
> +
> if (sysinfo_id && ctx->dev) {
> char val[SMBIOS_STR_MAX];
> int ret;
> @@ -151,8 +155,8 @@ static int smbios_add_prop_si(struct smbios_ctx *ctx,
> const char *prop,
> const char *str;
>
> str = ofnode_read_string(ctx->node, prop);
> - if (str)
> - return smbios_add_string(ctx, str);
> +
> + return smbios_add_string(ctx, str ? str : dval);
> }
>
> return 0;
> @@ -161,12 +165,15 @@ static int smbios_add_prop_si(struct smbios_ctx *ctx,
> const char *prop,
> /**
> * smbios_add_prop() - Add a property from the devicetree
> *
> - * @prop: property to write
> + * @prop: property to write. The default string will be written if
> + * prop is NULL
> + * @dval: Default value to use if the string is not found or is empty
> * Return: 0 if not found, else SMBIOS string number (1 or more)
> */
> -static int smbios_add_prop(struct smbios_ctx *ctx, const char *prop)
> +static int smbios_add_prop(struct smbios_ctx *ctx, const char *prop,
> + const char *dval)
> {
> - return smbios_add_prop_si(ctx, prop, SYSINFO_ID_NONE);
> + return smbios_add_prop_si(ctx, prop, SYSINFO_ID_NONE, dval);
> }
>
> static void smbios_set_eos(struct smbios_ctx *ctx, char *eos)
> @@ -228,11 +235,9 @@ static int smbios_write_type0(ulong *current, int handle,
> memset(t, 0, sizeof(struct smbios_type0));
> fill_smbios_header(t, SMBIOS_BIOS_INFORMATION, len, handle);
> smbios_set_eos(ctx, t->eos);
> - t->vendor = smbios_add_string(ctx, "U-Boot");
> +
Re: [PATCH v3] arch: arm: Kconfig: Enable BOOTSTD_FULL for Rockchip SoCs
On Fri, Dec 8, 2023 at 12:52 PM Shantur Rathore wrote: > > Hi Jagan, > > On Fri, Dec 8, 2023 at 11:13 AM Jagan Teki wrote: > > > > On Sun, Nov 19, 2023 at 10:54 PM Shantur Rathore wrote: > > > > > > Rockchip SoCs can support wide range of bootflows. > > > Without full bootflow commands, it can be difficult to > > > figure out issues if any, hence enable by default. > > > > > > Reviewed-by: Simon Glass > > > > > > Signed-off-by: Shantur Rathore > > > --- > > > > > > (no changes since v1) > > > > > > arch/arm/Kconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > index d812685c98..fca6ef6d7e 100644 > > > --- a/arch/arm/Kconfig > > > +++ b/arch/arm/Kconfig > > > @@ -1986,6 +1986,7 @@ config ARCH_ROCKCHIP > > > imply CMD_DM > > > imply DEBUG_UART_BOARD_INIT > > > imply BOOTSTD_DEFAULTS > > > + imply BOOTSTD_FULL if BOOTSTD_DEFAULTS > > > > Yes, but better to give this option to specific board vendors as > > defaults are enough to boot 1st bootflow and what ever media's it has. > > > > Yes, that's correct it is enough to boot but by default there is no option > to choose what to boot from. > This was discussed in an earlier version of this patch [0] where I was > explicitly enabling only for RP64. What actual extra functionality does this provide, what is the impact on the size of images? You've not provided reasonable justification outside of very vague statements, it would be useful to know what the added options actually solves.
Re: bootstd: Support for distro specific EFI folders
On Sun, Nov 19, 2023 at 6:55 PM Mark Kettenis wrote: > > > Date: Sat, 18 Nov 2023 23:52:11 +0100 > > From: Heinrich Schuchardt > > Hi Heinrich, > > > On 11/18/23 22:28, Shantur Rathore wrote: > > > Hi Heinrich, > > > > > > On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt > > > wrote: > > >> > > >> On 11/16/23 19:45, Shantur Rathore wrote: > > >>> On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > > >>> wrote: > > > > On 11/16/23 17:52, Shantur Rathore wrote: > > > Hi Simon, > > > > > > Currently bootstd - bootmethod_efi only looks for the default > > > bootxx64.efi in /EFI/boot folder only. > > > Generally many distros end up putting their bootloaders in > > > EFI/ folders like EFI/ubuntu and EFI/debian etc. > > > > > > In x86 worlds, the NVRAM is modified and new boot entries are added to > > > support these but in the U-boot world the NVRAM variables are > > > read-only. > > > > I guess you are referring to UEFI boot options. These typically are not > > stored in non-volatile RAM but on a SPI flash device. > > > > >>> > > >>> Thanks for correcting me. > > >>> > > > > > > What would be the best way to implement this? > > > > > > I was thinking of having a "efi_prefixes" environment variable which > > > can be set to "ubuntu debian centos" etc and bootmethod_efi can try > > > all of them. Will bootmethod_efi be able to support multiple entries ( > > > thinking of multiboot ) ? > > > > On my laptop I have: > > > > EFI/Microsoft/Boot/bootmgr.efi > > EFI/Microsoft/Boot/memtest.efi > > EFI/Boot/bootx64.efi > > EFI/Boot/fbx64.efi > > EFI/Boot/mmx64.efi > > EFI/debian/shimx64.efi > > EFI/debian/grubx64.efi > > EFI/debian/mmx64.efi > > EFI/debian/fbx64.efi > > EFI/ubuntu/grubx64.efi > > EFI/ubuntu/shimx64.efi > > EFI/ubuntu/mmx64.efi > > > > Obviously each installed operating system provides multiple EFI > > binaries > > and non uses the fallback file name BOOT.EFI. A value "ubuntu > > debian centos" would not be able to describe which file you are looking > > for. > > > > We already have the U-Boot command line eficonfig and efidebug commands > > to set up UEFI boot options which can describe which EFI binary to load > > and which command line to pass to it. These are considered by the > > existing boot flows. > > >>> > > >>> So, I am building a new RockPro64 based cluster and using Canonical > > >>> MAAS to set them up automatically, booting them up using DHCP and > > >>> installing them over the network. > > >>> I configured an Armbian image using Packer to be compatible with MAAS > > >>> and it happily installs it. As part of installation process, a > > >>> grub-install is run which installs the grub efi, > > >>> this EFI ends up in EFI/debian instead of expected EFI/boot. > > >>> To be able to make it boot, I have to add commands to move it to > > >>> EFI/boot. I am trying to find a way in U-Boot that would allow me to > > >>> skip this step. > > >>> With eficonfig if I understand correctly, it would need manual > > >>> intervention to create boot entries. > > >>> > > > > If you are installing the shim-signed package on Ubuntu, the EFI boot > > option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the > > content > > of EFI/ubuntu/BOOT.CSV. This is done before ExitBootServices() > > and > > therefore should work with current U-Boot. > > > > Patches are pending upstream to make EFI variables writable from Linux > > if they are stored in the RPMB partition in the eMMC. See this series: > > > > https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ > > > > >>> > > >>> Would it be possible to save it in SPI Flash as the U-Boot environment ? > > >> > > >> Currently this is not supported by U-Boot. > > >> > > >> The U-Boot environment variables can be stored in lots of different > > >> places SPI flash is only one of these. But none of these locations is > > >> protected from OS access which would be preferable for UEFI variables > > >> for security reasons. > > >> > > >> To support boards without eMMC the right way forward would be writing a > > >> new implementation of the OP-TEE standalone MM which writes the > > >> variables to SPI flash instead of the RPMB partition and ensures that > > >> the SPI flash' MMIO registers are protected against access from the > > >> non-secure world. > > > > > > Thanks for explaining this to me. > > > This seems like a long way to go, for now what would be an acceptable > > > solution, some options are > > > > > > 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu > > > debian") variable which is ready by bootmeth_efi and used as > > > efi/ instead of efi/boot. > > > 2. Improve bootmeth_efi to find all boot.efi in efi/ folder and
Re: [PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing
On Thu, Nov 30, 2023 at 2:45 AM Simon Glass wrote:
>
> Hi Ilias,
>
> On Mon, 27 Nov 2023 at 10:11, Ilias Apalodimas
> wrote:
> >
> > In order to fill in the SMBIOS tables U-Boot currently relies on a
> > "u-boot,sysinfo-smbios" compatible node. This is fine for the boards
> > that already include such nodes. However with some recent EFI changes,
> > the majority of boards can boot up distros, which usually rely on
> > things like dmidecode etc for their reporting. For boards that
> > lack this special node the SMBIOS output looks like:
> >
> > System Information
> > Manufacturer: Unknown
> > Product Name: Unknown
> > Version: Unknown
> > Serial Number: Unknown
> > UUID: Not Settable
> > Wake-up Type: Reserved
> > SKU Number: Unknown
> > Family: Unknown
> >
> > This looks problematic since most of the info are "Unknown". The DT spec
> > specifies standard properties containing relevant information like
> > 'model' and 'compatible' for which the suggested format is
> > . Unfortunately the 'model' string found in DTs is
> > usually lacking the manufacturer so we can't use it for both
> > 'Manufacturer' and 'Product Name' SMBIOS entries reliably.
> >
> > So let's add a last resort to our current smbios parsing. If none of
> > the sysinfo properties are found, scan for those information in the
> > root node of the device tree. Use the 'model' to fill the 'Product
> > Name' and the first value of 'compatible' for the 'Manufacturer', since
> > that always contains one.
> >
> > pre-patch:
> > Handle 0x0001, DMI type 1, 27 bytes
> > System Information
> > Manufacturer: Unknown
> > Product Name: Unknown
> > Version: Unknown
> > Serial Number: 1bb24ceb
> > UUID: 30303031-3030-3030-3061-613234636435
> > Wake-up Type: Reserved
> > SKU Number: Unknown
> > Family: Unknown
> > [...]
> >
> > and post patch:
> > Handle 0x0001, DMI type 1, 27 bytes
> > System Information
> > Manufacturer: raspberrypi
> > Product Name: Raspberry Pi 4 Model B Rev 1.1
> > Version: Unknown
> > Serial Number: 1bb24ceb
> > UUID: 30303031-3030-3030-3061-613234636435
> > Wake-up Type: Reserved
> > SKU Number: Unknown
> > Family: Unknown
> > [...]
> >
> > Signed-off-by: Ilias Apalodimas
> > ---
> > Changes since v1:
> > - Tokenize the DT node entry and use the appropriate value instead of
> > the entire string
> > - Removed Peters tested/reviewed-by tags due to the above
> > lib/smbios.c | 94 +---
> > 1 file changed, 90 insertions(+), 4 deletions(-)
> >
>
> Can this be put behind a Kconfig? It adds quite a bit of code which
> punishes those boards which do the right thing.
What's the size difference? By putting it behind a Kconfig you're
assuming the boards that don't do the right thing are going to enable
this at which point we punish users by not having some level of
usability. By "right thing" do you mean the smbios entries in the
-u-boot.dtsi?
> > diff --git a/lib/smbios.c b/lib/smbios.c
> > index fcc8686993ef..423893639ff0 100644
> > --- a/lib/smbios.c
> > +++ b/lib/smbios.c
> > @@ -9,11 +9,14 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #ifdef CONFIG_CPU
> > #include
> > #include
> > @@ -43,6 +46,25 @@
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > +/**
> > + * struct map_sysinfo - Mapping of sysinfo strings to DT
> > + *
> > + * @sysinfo_str: sysinfo string
> > + * @dt_str: DT string
> > + * @max: Max index of the tokenized string to pick. Counting starts from 0
> > + *
> > + */
> > +struct map_sysinfo {
> > + const char *sysinfo_str;
> > + const char *dt_str;
> > + int max;
> > +};
> > +
> > +static const struct map_sysinfo sysinfo_to_dt[] = {
> > + { .sysinfo_str = "product", .dt_str = "model", 2 },
> > + { .sysinfo_str = "manufacturer", .dt_str = "compatible", 1 },
> > +};
> > +
> > /**
> > * struct smbios_ctx - context for writing SMBIOS tables
> > *
> > @@ -87,6 +109,18 @@ struct smbios_write_method {
> > const char *subnode_name;
> > };
> >
> > +static const struct map_sysinfo *convert_sysinfo_to_dt(const char
> > *sysinfo_str)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(sysinfo_to_dt); i++) {
> > + if (!strcmp(sysinfo_str, sysinfo_to_dt[i].sysinfo_str))
> > + return _to_dt[i];
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > /**
> > * smbios_add_string() - add a string to the string area
> > *
> > @@ -127,6 +161,42 @@ static int smbios_add_string(struct smbios_ctx *ctx,
> > const char *str)
> > }
> > }
> >
> > +/**
> > + * get_str_from_dt - Get a substring from a DT property.
> > + * After
Re: [PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing
On Mon, Nov 27, 2023 at 5:11 PM Ilias Apalodimas
wrote:
>
> In order to fill in the SMBIOS tables U-Boot currently relies on a
> "u-boot,sysinfo-smbios" compatible node. This is fine for the boards
> that already include such nodes. However with some recent EFI changes,
> the majority of boards can boot up distros, which usually rely on
> things like dmidecode etc for their reporting. For boards that
> lack this special node the SMBIOS output looks like:
>
> System Information
> Manufacturer: Unknown
> Product Name: Unknown
> Version: Unknown
> Serial Number: Unknown
> UUID: Not Settable
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
>
> This looks problematic since most of the info are "Unknown". The DT spec
> specifies standard properties containing relevant information like
> 'model' and 'compatible' for which the suggested format is
> . Unfortunately the 'model' string found in DTs is
> usually lacking the manufacturer so we can't use it for both
> 'Manufacturer' and 'Product Name' SMBIOS entries reliably.
>
> So let's add a last resort to our current smbios parsing. If none of
> the sysinfo properties are found, scan for those information in the
> root node of the device tree. Use the 'model' to fill the 'Product
> Name' and the first value of 'compatible' for the 'Manufacturer', since
> that always contains one.
>
> pre-patch:
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: Unknown
> Product Name: Unknown
> Version: Unknown
> Serial Number: 1bb24ceb
> UUID: 30303031-3030-3030-3061-613234636435
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> and post patch:
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
> Manufacturer: raspberrypi
> Product Name: Raspberry Pi 4 Model B Rev 1.1
> Version: Unknown
> Serial Number: 1bb24ceb
> UUID: 30303031-3030-3030-3061-613234636435
> Wake-up Type: Reserved
> SKU Number: Unknown
> Family: Unknown
> [...]
>
> Signed-off-by: Ilias Apalodimas
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
> ---
> Changes since v1:
> - Tokenize the DT node entry and use the appropriate value instead of
> the entire string
> - Removed Peters tested/reviewed-by tags due to the above
> lib/smbios.c | 94 +---
> 1 file changed, 90 insertions(+), 4 deletions(-)
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index fcc8686993ef..423893639ff0 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -9,11 +9,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> +#include
> #ifdef CONFIG_CPU
> #include
> #include
> @@ -43,6 +46,25 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +/**
> + * struct map_sysinfo - Mapping of sysinfo strings to DT
> + *
> + * @sysinfo_str: sysinfo string
> + * @dt_str: DT string
> + * @max: Max index of the tokenized string to pick. Counting starts from 0
> + *
> + */
> +struct map_sysinfo {
> + const char *sysinfo_str;
> + const char *dt_str;
> + int max;
> +};
> +
> +static const struct map_sysinfo sysinfo_to_dt[] = {
> + { .sysinfo_str = "product", .dt_str = "model", 2 },
> + { .sysinfo_str = "manufacturer", .dt_str = "compatible", 1 },
> +};
> +
> /**
> * struct smbios_ctx - context for writing SMBIOS tables
> *
> @@ -87,6 +109,18 @@ struct smbios_write_method {
> const char *subnode_name;
> };
>
> +static const struct map_sysinfo *convert_sysinfo_to_dt(const char
> *sysinfo_str)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(sysinfo_to_dt); i++) {
> + if (!strcmp(sysinfo_str, sysinfo_to_dt[i].sysinfo_str))
> + return _to_dt[i];
> + }
> +
> + return NULL;
> +}
> +
> /**
> * smbios_add_string() - add a string to the string area
> *
> @@ -127,6 +161,42 @@ static int smbios_add_string(struct smbios_ctx *ctx,
> const char *str)
> }
> }
>
> +/**
> + * get_str_from_dt - Get a substring from a DT property.
> + * After finding the property in the DT, the function
> + * will parse comma separted values and return the value.
> + * If nprop->max exceeds the number of comma separated
Re: [PATCH 1/1] efi_loader: boot options should relate to the ESP
On Wed, Dec 6, 2023 at 9:31 AM Heinrich Schuchardt
wrote:
>
> On 05.12.23 07:23, Masahisa Kojima wrote:
> > Hi Heinrich,
> >
> > On Tue, 5 Dec 2023 at 11:38, Heinrich Schuchardt
> > wrote:
> >>
> >> * Only generate removable media entries for EFI system partitions.
> >> * Only offer EFI system partitions for boot options in the eficonfig
> >>command.
> >>
> >> Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> >> Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
> >> Signed-off-by: Heinrich Schuchardt
> >> ---
> >> cmd/eficonfig.c | 6 --
> >> lib/efi_loader/efi_bootmgr.c | 3 ++-
> >> 2 files changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> >> index 34a59cb15d..c066b28b6b 100644
> >> --- a/cmd/eficonfig.c
> >> +++ b/cmd/eficonfig.c
> >> @@ -626,8 +626,10 @@ static efi_status_t eficonfig_select_volume(struct
> >> eficonfig_select_file_info *f
> >> efi_handle_t *volume_handles = NULL;
> >> struct efi_simple_file_system_protocol *v;
> >>
> >> - ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> >> _simple_file_system_protocol_guid,
> >> - NULL, , (efi_handle_t
> >> **)_handles);
> >> + /* Find all EFI system partitions */
> >> + ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> >> + _system_partition_guid,
> >> + NULL, , _handles);
> >
> > UEFI specification v2.10 section '3.5 Boot Mechanisms' says
> > "EFI can boot from a device using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or the
> > EFI_LOAD_FILE_PROTOCOL."
> >
> > So in my understanding of the UEFI spec, I think
> > efi_simple_file_system_protocol_guid
> > is correct here.
> >
> >> if (ret != EFI_SUCCESS) {
> >> eficonfig_print_msg("No block device found!");
> >> return ret;
> >> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> >> index 48153bd5ff..9e84391186 100644
> >> --- a/lib/efi_loader/efi_bootmgr.c
> >> +++ b/lib/efi_loader/efi_bootmgr.c
> >> @@ -1047,8 +1047,9 @@ efi_status_t
> >> efi_bootmgr_update_media_device_boot_option(void)
> >> efi_handle_t *volume_handles = NULL;
> >> struct eficonfig_media_boot_option *opt = NULL;
> >>
> >> + /* Find all EFI system partitions */
> >> ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> >> -
> >> _simple_file_system_protocol_guid,
> >> + _system_partition_guid,
> >
> > In EDK II reference implementation[0], it enumerates all
> > block_io_protocol devices
> > and eliminates logical partitions.
> > Should we do the same? If yes, I can prepare the patch on this.
>
> This is what the boot options look like on an EDK II system:
>
> $ efibootmgr -v
> BootCurrent: 000D
> Timeout: 3 seconds
> BootOrder:
> 000D,000B,000C,0003,0004,0005,0006,0007,0008,0009,000A,,0001,0002
> Boot* UiApp
> FvVol(5eda4200-2c5f-43cb-9da3-0baf74b1b30c)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
> Boot0001* helloworld
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,54f200)/Sata(1,65535,0)/HD(1,GPT,40c323d0-6b76-47c4-bc82-e05bf5d23c9f,0x2000,0x20)/File(\helloworld.efi)h.e.l.l.o.
> .w.o.r.l.d...
> Boot0002* UEFI Crucial_CT128M550SSD1 14270C7CFEFE
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,54f200)/Sata(1,65535,0)N.YMR,Y.
> Boot0003* UEFI eMMC Device
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,6ef000)/eMMC(0)/Ctrl(0x0)N.YMR,Y.
> Boot0004* UEFI eMMC Device 2
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,6ef000)/eMMC(0)/Ctrl(0x1)N.YMR,Y.
> Boot0005* UEFI eMMC Device 3
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,6ef000)/eMMC(0)/Ctrl(0x2)N.YMR,Y.
> Boot0006* UEFI PXEv4 (MAC:0001)
> MAC(0001,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> Boot0007* UEFI PXEv4 (MAC:0002)
> MAC(0002,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> Boot0008* UEFI PXEv4 (MAC:0003)
> MAC(0003,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> Boot0009* UEFI PXEv4 (MAC:0004)
> MAC(0004,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> Boot000A* UEFI Shell
> FvVol(5eda4200-2c5f-43cb-9da3-0baf74b1b30c)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
> Boot000B* UEFI HL-DT-ST DVDRAM GTC0N
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,54f400)/Sata(1,65535,0)N.YMR,Y.
> Boot000C* ubuntu
> HD(1,GPT,5a1ba4fc-f9b4-4da2-b5e1-065e9cd10e3a,0x800,0x10)/File(\EFI\ubuntu\grubaa64.efi)
> Boot000D* grub
> HD(1,GPT,5a1ba4fc-f9b4-4da2-b5e1-065e9cd10e3a,0x800,0x10)/File(\EFI\grub\shimaa64.efi)
> Boot1001* helloworld
> HD(1,GPT,40c323d0-6b76-47c4-bc82-e05bf5d23c8f,0x2000,0x20)/File(helloworld.efi)
>
> As you described autogenerated boot options are on block
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry,
> First of all, thank you for all your reviews. I hope I can answer all
> your questions here. If I forget something please let me know.
Absolutely.
> I don't have much experience with arm/arm64 and I don't have previous
> experience with u-boot and contributing to it. So please guide me for
> next steps.
I think you're doing fine, generally the process is wait for some
review, incorporate the feedback into patches and after a little while
send a new rev.
> Also I don't think it makes sense to expect all devices or any device
> may/should work after initial boot support. I would suggest going with
> small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> after initial support is being merged.
I agree with that point mostly, and that is my intention, from my PoV
it was more me replying to the comments you had made about outsanding
issues and what my thoughts were to address them.
That being said I think we need two things to be able to land this
upstream 1) working output such as serial console (this is ticket) 2)
working storage so it can load things like the Linux kernel off disk
and boot, the shortest path to this is likely MMC. Everything else
(gfx/net/usb etc) can be added later in incremental patches. I
apologies if my reply didn't come across at that, it was as much
documented my discoveries for everyone else on the list following
along.
> > Could this be the title for the patch, "initial support" is fine for
> > the cover letter, but doesn't really out line what this specific patch
> > actually does.
> Can confirm. My bad. Will fix it in the next patchset.
>
> >> includes:
> >> * 1GB of RAM (from 4GB or 8GB total)
> >> * VPU memory interface
> >> * SOC range (main peripherals)
>
> > Could you include details where this information came from as well please?
> By looking into FDT for memory, framebuffer, and soc nodes. I can add
> this info in v3.
>
>
> > When you say it doesn't work, does it just not output display or does
> > the device lock up and you need to disable it?
> There are artifacts on the screen and the system locks up.
OK, good to know, we can't really disable display ATM as it'll regress
other rpi devices supported in this config.
>
> > For the rpi4 it was as simple as adding a new compatible [1] for the
> > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > updating registers [2] so I'm not sure if we're going to need to do
> > more for this or not.
> I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> And no luck. Still visible artifacts on the screen. I see valid debug
> output from bcm2835_video_probe() so the mailbox for set/get
> base/resolution/pitch/stride works. But still observe the same issue
> with artifacts and lock up. FYI by default the probing starts due to
> "bcm2708-fb".
>
>
> > Might be worth looking to see if there's changes in the kernel for
> > this. In an initial look I didn't see any changes to their kernel
> > here.
> I don't see any changes either. I'm not able to find any official
> confirmation. But most of 'tags' work except two or three. And all of
> them have response code 0x8000_0001. And FDT contains new info
> compared to old versions (for these tags). Which leads to the
> conclusion they are deprecated.
>
>
> > We probably need a patch to the identifier too similar to the following:
> > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> Honestly I didn't get the reason/goal besides old/new scheme except
> there is a final print:
> > printf("RPI %s (0x%x)\n", model->name, revision);
> which is kind of simular to my:
> > printf("FW FDT model : %s\n", fdt_model);
The main reason for the detection is if there needs to be a kernel DT
loaded off disk, it's a more definitive way of detecting the HW rev
because the fdt model could be repeated across different revs of the
same variant.
> Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> revision from it? Format is unknown and nobody knows what will be
> changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> suggest parsing OTP to get precise info with known format.
Hence the reason to use the official hex identifiers.
> P.S.: Please let me know if I answered all the questions so I can send v3.
I think so. The outstanding things we will need to resolve to land
this, other than the polish I've outlined in various replies, is:
1) working storage to load an OS
2) not disabling the display driver and not have it crash. The display
on the rpi5 doesn't need to work, we just don't want to regress
existing users.
This won't be landing in 2024.01 now so we have time to get this
ready. I'll start to play in the coming days.
Peter
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry,
> > I've given these a cursory look over, I have a system to test and will
> > give them a whirl in the next few days, I was planning to start
> > playing over the weekend so you've provided a great start :)
>
> Did you have any chance to test my patches?
Not yet, apologies, work has been a bit intense over the last couple
of weeks so I've not had many cycles in the free time I use for RPi
outside of work to do this. I do have the RPi5 up and running now
though so I can start to test.
I was going to reply to your last reply, I will do that in a moment.
Peter
> > Hi guys,
> >
> > First of all, thank you for all your reviews. I hope I can answer all
> > your questions here. If I forget something please let me know.
> >
> > I don't have much experience with arm/arm64 and I don't have previous
> > experience with u-boot and contributing to it. So please guide me for
> > next steps.
> >
> > Also I don't think it makes sense to expect all devices or any device
> > may/should work after initial boot support. I would suggest going with
> > small steps and talking about gfx/usb/net/mmc in dedicated patchsets
> > after initial support is being merged.
> >
> > > Could this be the title for the patch, "initial support" is fine for
> > > the cover letter, but doesn't really out line what this specific patch
> > > actually does.
> > Can confirm. My bad. Will fix it in the next patchset.
> >
> > >> includes:
> > >> * 1GB of RAM (from 4GB or 8GB total)
> > >> * VPU memory interface
> > >> * SOC range (main peripherals)
> >
> > > Could you include details where this information came from as well please?
> > By looking into FDT for memory, framebuffer, and soc nodes. I can add
> > this info in v3.
> >
> >
> > > When you say it doesn't work, does it just not output display or does
> > > the device lock up and you need to disable it?
> > There are artifacts on the screen and the system locks up.
> >
> >
> > > For the rpi4 it was as simple as adding a new compatible [1] for the
> > > rev6 of the IP block as for the bits that we use in U-Boot nothing
> > > changed, but the kernel changes for the rev7 that's in the RPi5 needed
> > > updating registers [2] so I'm not sure if we're going to need to do
> > > more for this or not.
> > I've tried it by playing with "simple-fb" and with "bcm2712-hdmi0".
> > And no luck. Still visible artifacts on the screen. I see valid debug
> > output from bcm2835_video_probe() so the mailbox for set/get
> > base/resolution/pitch/stride works. But still observe the same issue
> > with artifacts and lock up. FYI by default the probing starts due to
> > "bcm2708-fb".
> >
> >
> > > Might be worth looking to see if there's changes in the kernel for
> > > this. In an initial look I didn't see any changes to their kernel
> > > here.
> > I don't see any changes either. I'm not able to find any official
> > confirmation. But most of 'tags' work except two or three. And all of
> > them have response code 0x8000_0001. And FDT contains new info
> > compared to old versions (for these tags). Which leads to the
> > conclusion they are deprecated.
> >
> >
> > > We probably need a patch to the identifier too similar to the following:
> > > https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12
> > Honestly I didn't get the reason/goal besides old/new scheme except
> > there is a final print:
> > > printf("RPI %s (0x%x)\n", model->name, revision);
> > which is kind of simular to my:
> > > printf("FW FDT model : %s\n", fdt_model);
> >
> > Besides parsing the "Raspberry Pi 5 Model B Rev 1.0" string to get
> > revision from it? Format is unknown and nobody knows what will be
> > changed. Will it be "Raspberry Pi 5 Model B Rev 1.0a" or Raspberry Pi
> > 5 Model B Rev 1.01"? I don't know. If it's really needed then I would
> > suggest parsing OTP to get precise info with known format.
> >
> > P.S.: Please let me know if I answered all the questions so I can send v3.
> >
> > Regards,
> > Dmitry
>
> I haven't heard any updates. Should I send v3?
Re: [PATCH] rockchip: rk3328: Set efuse auto mode and timing control
On Mon, Nov 27, 2023 at 7:31 PM Jonas Karlman wrote:
>
> Hi Quentin,
>
> On 2023-11-27 19:42, Quentin Schulz wrote:
> > Hi Jonas,
> >
> >
> > From: U-Boot on behalf of Jonas Karlman
> >
> > Sent: 26 November 2023 20:46
> > To: Kever Yang; Simon Glass; Philipp Tomsich
> > Cc: Jonas Karlman; u-boot@lists.denx.de
> > Subject: [PATCH] rockchip: rk3328: Set efuse auto mode and timing control
> >
> > Reading from efuse return zero when mainline TF-A is used.
> >
> > => dump_efuse
> > : 00 00 00 00
> > 0004: 00 00 00 00
> > 0008: 00 00 00 00
> > 000c: 00 00 00 00
> > 0010: 00 00 00 00
> > 0014: 00 00 00 00
> > 0018: 00 00 00 00
> > 001c: 00 00 00 00
> >
> > However, when vendor TF-A blobs is used reading from efuse works.
> >
> > Change to use auto mode, enable finish and auto access err interrupts
> > and set timing control using same values that vendor TF-A blob use to
> > fix this.
> >
> > With this efuse can be read when either of mainline TF-A or vendor blob
> > is used.
> >
> > => dump_efuse
> > : 52 4b 33 82 RK3.
> > 0004: 00 fe 21 55 ..!U
> > 0008: 52 4b 57 34 RKW4
> > 000c: 35 30 32 39 5029
> > 0010: 00 00 00 00
> > 0014: 08 25 0c 0f .%..
> > 0018: 02 0d 08 00
> > 001c: 00 00 f0 00
> >
> > Signed-off-by: Jonas Karlman
> > ---
> > arch/arm/mach-rockchip/rk3328/rk3328.c | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c
> > b/arch/arm/mach-rockchip/rk3328/rk3328.c
> > index de17b8868273..edb22a58fc67 100644
> > --- a/arch/arm/mach-rockchip/rk3328/rk3328.c
> > +++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
> > @@ -19,6 +19,22 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define GRF_BASE 0xFF10
> > #define UART2_BASE 0xFF13
> > #define FW_DDR_CON_REG 0xFF7C0040
> > +#define EFUSE_NS_BASE 0xFF26
> > +
> > +#define EFUSE_MOD 0x
> > +#define EFUSE_INT_CON 0x0014
> > +#define EFUSE_T_CSB_P 0x0028
> > +#define EFUSE_T_PGENB_P0x002C
> > +#define EFUSE_T_LOAD_P 0x0030
> > +#define EFUSE_T_ADDR_P 0x0034
> > +#define EFUSE_T_STROBE_P 0x0038
> > +#define EFUSE_T_CSB_R 0x003C
> > +#define EFUSE_T_PGENB_R0x0040
> > +#define EFUSE_T_LOAD_R 0x0044
> > +#define EFUSE_T_ADDR_R 0x0048
> > +#define EFUSE_T_STROBE_R 0x004C
> > +
> > +#define EFUSE_TIMING(s, l) (((s) << 16) | (l))
> >
> > const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > [BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
> > @@ -54,6 +70,24 @@ int arch_cpu_init(void)
> >
> > /* Disable the ddr secure region setting to make it non-secure */
> > rk_setreg(FW_DDR_CON_REG, 0x200);
> > +
> > + /* Use efuse auto mode */
> > + writel(0x46, EFUSE_NS_BASE + EFUSE_MOD);
> > +
> > + /* Enable efuse finish and auto access err interrupt */
> > + writel(0x07, EFUSE_NS_BASE + EFUSE_INT_CON);
> > +
> > + /* Set efuse timing control */
> > + writel(EFUSE_TIMING(1, 241), EFUSE_NS_BASE + EFUSE_T_CSB_P);
> > + writel(EFUSE_TIMING(1, 241), EFUSE_NS_BASE + EFUSE_T_PGENB_P);
> > + writel(EFUSE_TIMING(1, 241), EFUSE_NS_BASE + EFUSE_T_LOAD_P);
> > + writel(EFUSE_TIMING(1, 241), EFUSE_NS_BASE + EFUSE_T_ADDR_P);
> > + writel(EFUSE_TIMING(2, 240), EFUSE_NS_BASE + EFUSE_T_STROBE_P);
> > + writel(EFUSE_TIMING(1, 4), EFUSE_NS_BASE + EFUSE_T_CSB_R);
> > + writel(EFUSE_TIMING(1, 4), EFUSE_NS_BASE + EFUSE_T_PGENB_R);
> > + writel(EFUSE_TIMING(1, 4), EFUSE_NS_BASE + EFUSE_T_LOAD_R);
> > + writel(EFUSE_TIMING(1, 4), EFUSE_NS_BASE + EFUSE_T_ADDR_R);
> > + writel(EFUSE_TIMING(2, 3), EFUSE_NS_BASE + EFUSE_T_STROBE_R);
> >
> > Shouldn't this be done in the efuse driver instead?
>
> I was considering the same and was unsure if these values would need to
> be initialized at EL3 in SPL or could be initialized at EL1 in U-Boot
> proper (in the efuse driver).
>
> Did not have time to investigate further and decided to just do it at
> EL3 same as vendor TF-A, so code ended up here.
Is there a reason not to do it in the upstream TF-A like the vendor
one does? I'm sure I've seen patches around that do this when I've dug
into it in the past. Is there reasons where TF-A would need access to
the information the efuses provide, I'm guessing things like serial
numbers etc, given the vendor TF-A does this I suspect that's where
the patch should go rather than U-Boot.
Peter
[PATCH] maintainers: bcmns3: remove maintainer
Remove Bharat Gooty as a maintainer as his mail is bouncing. Signed-off-by: Peter Robinson Cc: Rayagonda Kokatanur --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9f74c0aacaa..87e5ee04978 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1528,7 +1528,6 @@ F:cmd/stackprot_test.c F: test/py/tests/test_stackprotector.py TARGET_BCMNS3 -M: Bharat Gooty M: Rayagonda Kokatanur S: Maintained F: board/broadcom/bcmns3/ -- 2.43.0
Re: [PATHv1 7/9] bcm_ns3: fix overlap define with lwip
On Tue, Dec 5, 2023 at 8:56 AM Maxim Uvarov wrote:
>
> Rename declaration to not overlap with lwip.
I think the commit message can be made more generic like "Use device
specific naming for variables so as to not overlap with common
function names", I also don't think you need to include the compile
error in the commit. Code itself looks good so:
Reviewed-by: Peter Robinson
> aarch64: + bcm_ns3
> +In file included from net/lwip/lwip-external/src/include/lwip/etharp.h:53,
> + from net/lwip/lwip-external/src/core/init.c:55:
> +net/lwip/lwip-external/src/include/lwip/prot/ethernet.h:69:
> error: "ETH_ADDR" redefined [-Werror]
> + 69 | #define ETH_ADDR(b0, b1, b2, b3, b4, b5) {{b0, b1, b2, b3, b4, b5}}
> + |
> +In file included from include/config.h:3,
> + from arch/arm/include/asm/string.h:4,
> + from include/linux/string.h:21,
> + from include/malloc.h:369,
> + from include/stdlib.h:9,
> + from net/lwip/lwip-external/src/include/lwip/arch.h:83,
> + from net/lwip/lwip-external/src/include/lwip/debug.h:40,
> + from net/lwip/lwipopts.h:93,
> + from net/lwip/lwip-external/src/include/lwip/opt.h:51,
> + from net/lwip/lwip-external/src/core/init.c:38:
> +include/configs/bcm_ns3.h:52: note: this is the location of the previous
> definition
> + 52 | #define ETH_ADDR
>
> Signed-off-by: Maxim Uvarov
> Reviewed-by: Tom Rini
> ---
> include/configs/bcm_ns3.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/bcm_ns3.h b/include/configs/bcm_ns3.h
> index 47de4bc201..7c6e0725a6 100644
> --- a/include/configs/bcm_ns3.h
> +++ b/include/configs/bcm_ns3.h
> @@ -45,11 +45,11 @@
> #define PCIE_ARGS "pcie_args=pci=pcie_bus_safe pcie_ports=native
> vfio_pci.disable_idle_d3=1\0"
>
> #ifdef CONFIG_BCM_SF2_ETH
> -#define ETH_ADDR "ethaddr=00:0A:F7:95:65:A4\0"
> +#define BCM_ETH_ADDR "ethaddr=00:0A:F7:95:65:A4\0"
> #define NET_ARGS "bgmac_platform.ethaddr=${ethaddr} " \
> "ip=${ipaddr}::${gatewayip}:${netmask}::${ethif}:off"
> #else
> -#define ETH_ADDR
> +#define BMC_ETH_ADDR
> #define NET_ARGS
> #endif
>
> @@ -749,7 +749,7 @@
> OS_LOG_LEVEL \
> EXTRA_ARGS \
> PCIE_ARGS \
> - ETH_ADDR \
> + BMC_ETH_ADDR \
> RESERVED_MEM \
> SETBOOTARGS \
> UPDATEME_FLASH_PARAMS \
> --
> 2.30.2
>
Re: [PATCH] doc: Replace examples of MD5 and SHA1 with SHA256
algo = "sha256";
> value = <...kernel hash 1...>
> };
> };
> kernel-2 {
> data =
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> value = <...kernel hash 2...>
> };
> };
> fdt-1 {
> data = ;
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> value = <...fdt hash 1...>
> };
> };
> fdt-2 {
> data = ;
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> value = <...fdt hash 2...>
> };
> };
> @@ -323,7 +323,7 @@ So the above example is adjusted to look like this::
> kernel = "kernel-1";
> fdt = "fdt-1";
> signature-1 {
> -algo = "sha1,rsa2048";
> +algo = "sha256,rsa2048";
> value = <...conf 1 signature...>;
> };
> };
> @@ -331,7 +331,7 @@ So the above example is adjusted to look like this::
> kernel = "kernel-2";
> fdt = "fdt-2";
> signature-1 {
> -algo = "sha1,rsa2048";
> +algo = "sha256,rsa2048";
> value = <...conf 1 signature...>;
> };
> };
> diff --git a/doc/usage/fit/update3.rst b/doc/usage/fit/update3.rst
> index 4ff3950c01e..24235801470 100644
> --- a/doc/usage/fit/update3.rst
> +++ b/doc/usage/fit/update3.rst
> @@ -19,7 +19,7 @@ Automatic software update: multiple files
> type = "firmware";
> load = ;
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> };
> };
> update-2 {
> @@ -29,7 +29,7 @@ Automatic software update: multiple files
> type = "firmware";
> load = ;
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> };
> };
>
> @@ -40,7 +40,7 @@ Automatic software update: multiple files
> type = "firmware";
> load = ;
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> };
> };
> };
> diff --git a/doc/usage/fit/update_uboot.rst b/doc/usage/fit/update_uboot.rst
> index a9288ee6367..811d008d13d 100644
> --- a/doc/usage/fit/update_uboot.rst
> +++ b/doc/usage/fit/update_uboot.rst
> @@ -21,7 +21,7 @@ Make sure the flashing addresses ('load' prop) is correct
> for your board!
> type = "firmware";
> load = <0xFFFC>;
> hash-1 {
> -algo = "sha1";
> +algo = "sha256";
> };
> };
> };
> diff --git a/doc/usage/fit/x86-fit-boot.rst b/doc/usage/fit/x86-fit-boot.rst
> index 93b73bb9019..9e3e32204d5 100644
> --- a/doc/usage/fit/x86-fit-boot.rst
> +++ b/doc/usage/fit/x86-fit-boot.rst
> @@ -207,16 +207,16 @@ You can take a look at the resulting fit file if you
> like::
>OS: Linux
>Load Address: 0x0100
>Entry Point: 0x
> - Hash algo:sha1
> - Hash value: 446b5163ebfe0fb6ee20cbb7a8501b263cd92392
> + Hash algo:sha256
> + Hash value:
> 4bbf49981ade163ed089f8525236fedfe44508e9b02a21a48294a96a1518107b
> Image 1 (setup)
>Description: Linux setup.bin
>Created: Tue Oct 7 10:57:24 2014
>Type: x86 setup.bin
>Compression: uncompressed
>Data Size:12912 Bytes = 12.61 kB = 0.01 MB
> - Hash algo:sha1
> - Hash value: a1f2099cf47ff9816236cd534c77af86e713faad
> + Hash algo:sha256
> + Hash value:
> 6aa50c2e0392cb119cdf0971dce8339f100608ed3757c8200b0e39e889e432d2
> Default Configuration: 'config-1'
> Configuration 0 (config-1)
>Description: Boot Linux kernel
Reviewed-by: Peter Robinson
Looks good to me. Do we know if we need to update any sample configs
with the options for those checksums?
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
Hi Maxim, > Please find updated version of lwip patches. Changes are in the > changelog bellow. > > Thank you, > Maxim. > > changelog: > v11: - v11 is mosly respin of v10 patches with CI error fixes. > Gitlab CI: > > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/18368 > Azure CI: > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=7366=results > (Azure CI, which is connected to github. Sometime I can see > tftp timeout after some part of download there, but that can > not be > reproduced locally. While Gitblab CI is stable. Because of > num tries in > CI I suspect this CI was not always reliable.) > Azure and Gitlab also have different toolchains and I > would say Gitlab generates bigger code then Azure CI. > > Also many boards have a binary limit size of 800k (even > qemu has limits). And increased limits to fit all the code. > Specially did it > patch by board config to show which boards are failing to > build. There I have > a question if we really want to support new functionality for > old boards (mips, > arm32 and etc...). I hope board owners can help me if > it's valid to increase these limits. > > In this version I used git submodules and friend CI with > submodules. But I don't mind if you decide to maintain it in > a different > way. > > > v10: - fix ping with following tftp command issue with incorrect > ping timeout clear. > - Makefile on make will init submodules and if needed will >do git clone. > - wget - some minor code style changes. > v9: - added first patch describing git submodule for lwip. So > the build procedure is: > git submodule init > git submodule update > make > - reworked a little bit dhcp cmd state polling > - fixed review comments for v8 > v8: - comments for previous review > - removed lwip timeout callback pointer > - made lwip timeouts works, that also allowed to remove > static vars. > - setenv for filesize tftp and wget has to be in hex. > - Makefile changes always compile it tftp,dns,wget,ping due > to it can be used not only by CONFIG_CMD_. > - Kconfig changes - simplify lwIP settings and support only > one configuration. > - tested with mini debian.iso load over http or tftp, mount > and boot it (qemu, arm64). > v7: - more review fixes. > - support of multiply eth devices, were "ethact" selects the > active device. > v6: - fixed review comments for v5 (thanks Ilias and Simon). > v5: - fixed Iliases comments and split big patch on the small > ones. > v4: - tested with tests/py/ did some minor fixes (out of tree > build, variables set after downloads). > - accounted review comments for documentation. > - implemented dns command > - corrected wget command to not use serverip variable and use just > url string. > v3: - use lwip commands for ping,tftp,wget,dhcp if this patch > applied. Drop CONFIG_LIB_LWIP_REPLACE_ option. > - docs: use rst variant and drop references to RFC. > > Maxim Uvarov (43): > submodule: add lwIP as git submodule > net/lwip: add doc/develop/net_lwip.rst > net/lwip: integrate lwIP library > net/lwip: implement dns cmd > net/lwip: implement dhcp cmd > net/lwip: implement tftp cmd > net/lwip: implement wget cmd > net/lwip: implement ping cmd > net/lwip: add lwIP configuration > net/lwip: implement lwIP port to U-Boot > net/lwip: update .gitignore with lwIP > net/lwip: connection between cmd and lwip apps > net/lwip: replace original net commands with lwip > net/lwip: split net.h to net.h, arp.h and eth.h I think the patches below likely make sense to be split out, either into individual patches or a fixes/cleanup series that the LWIP series depends upon. A bunch of the patches below look like they would even be reasonable fixes for the current release cycle. Peter > test_efi_loader.py: use $filesize var > test_net: print out net list > net: sandbox: fix NULL pointer derefences > net/smc911x: fix return from smc911x_send > sandbox: eth-raw-os: successful return code is 0 > driver/net/rtl8139: remove debug print > mach-socfpga: do not overlap defines with lwip > bcm_ns3: fix overlap define with lwip > rcar3_salvator-x_defconfig: increase binary size limit > lwip: omap3: rename mem_init >
Re: [PATHv11 33/43] configs/am335x_evm_defconfig: inc SPL size
On Mon, Nov 27, 2023 at 3:32 PM Maxim Uvarov wrote: > > > > On Mon, 27 Nov 2023 at 20:08, Tom Rini wrote: >> >> On Mon, Nov 27, 2023 at 08:06:23PM +0600, Maxim Uvarov wrote: >> > On Mon, 27 Nov 2023 at 19:08, Tom Rini wrote: >> > >> > > On Mon, Nov 27, 2023 at 06:57:16PM +0600, Maxim Uvarov wrote: >> > > >> > > > Increase allowed binary size to fit lwip code. >> > > > >> > > > Signed-off-by: Maxim Uvarov >> > > > --- >> > > > configs/am335x_evm_defconfig | 1 + >> > > > 1 file changed, 1 insertion(+) >> > > > >> > > > diff --git a/configs/am335x_evm_defconfig >> > > > b/configs/am335x_evm_defconfig >> > > > index f048e60f7f..9fd608bd76 100644 >> > > > --- a/configs/am335x_evm_defconfig >> > > > +++ b/configs/am335x_evm_defconfig >> > > > @@ -124,3 +124,4 @@ CONFIG_WDT=y >> > > > CONFIG_DYNAMIC_CRC_TABLE=y >> > > > CONFIG_RSA=y >> > > > CONFIG_LZO=y >> > > > +CONFIG_SPL_MAX_SIZE=0x29000 >> > > >> > > As probably a problem for other platforms you made this change on too, >> > > you can't do this. The link limit is here because that's the limit the >> > > hardware (and ROM) imposes. >> > > >> > > You might need to either: >> > > - Figure out how to make lwip even tinier for the SPL case >> > > - Limit the old network stack to just for SPL, and a later task is to >> > > reduce what's in the old stack to just what's also needed within SPL. >> > > >> > > >> > Thanks Tom. All these size changes need to be reviewed. Some of them are >> > ok, I think like for x86 or qemu virt, but some of them might not work. >> > >> > Question - Do we need networking inside SPL rather than in the main binary? >> > Is it a real use case? >> >> Yes, the device supports loading SPL, and then SPL loading U-Boot both >> over USB RNDIS as well as regular physical ethernet. >> >> -- >> Tom > > > That looks like not a production use case. USB + NET + drivers + EXT4 + NAND > + MTD and everything else and trying to fit into SPL. > With enabling LTO I still need 4k (without dropping current code). From one > point it's too synthetic use case here and might be a historical > limitation which we will not see on future boards. From the other point it > will be good to not break it somehow Does this still include the old network code? Also I wonder if we can have a paired down SPL_LWIP option that removes things like PXE and HTTP/wget because none of those would be used in the SPL use case as they're all brand new. Peter
Re: [PATHv11 33/43] configs/am335x_evm_defconfig: inc SPL size
On Mon, Nov 27, 2023 at 1:08 PM Tom Rini wrote: > > On Mon, Nov 27, 2023 at 06:57:16PM +0600, Maxim Uvarov wrote: > > > Increase allowed binary size to fit lwip code. > > > > Signed-off-by: Maxim Uvarov > > --- > > configs/am335x_evm_defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig > > index f048e60f7f..9fd608bd76 100644 > > --- a/configs/am335x_evm_defconfig > > +++ b/configs/am335x_evm_defconfig > > @@ -124,3 +124,4 @@ CONFIG_WDT=y > > CONFIG_DYNAMIC_CRC_TABLE=y > > CONFIG_RSA=y > > CONFIG_LZO=y > > +CONFIG_SPL_MAX_SIZE=0x29000 > > As probably a problem for other platforms you made this change on too, > you can't do this. The link limit is here because that's the limit the > hardware (and ROM) imposes. > > You might need to either: > - Figure out how to make lwip even tinier for the SPL case > - Limit the old network stack to just for SPL, and a later task is to > reduce what's in the old stack to just what's also needed within SPL. Maybe also verify if network is actually needed/used in SPL for those devices.
Re: [PATCH] boards: Disable NET on platforms without NETDEVICES
On Mon, Nov 27, 2023 at 1:06 PM Tom Rini wrote: > > On Mon, Nov 27, 2023 at 5:45 AM Winker Matthias (HC-CW/ENG-PJM) > wrote: > > > > Hello Tom, > > > > Just to be sure. In the past we had NET enabled such that the fused MAC is > > taken over, although we don’t use NET CMD. > > With your changes, does I.mx6 evaluate the MAC fuses and forward it to > > Linux? > > > > Our board: Bosch ACC. > > I honestly don't know as I don't see how it's doing that today in > current master (which does not have this change) so you might > need to start by confirming behavior in the current tree and working > from there, thanks. It's usually reading from eFUSES and populates details via DT using alias bits, whether or not that uses/depends on code in net I'm not sure.
Re: efi: Set Variable Runtime implementation
Hi Shantur, > > > > > I am trying to work out how to enable the SetVariableRT service in > > > > > U-Boot and came across your patch [1] which initially had the > > > > > SetVariable RT service enabled in EFI but in the final patch this was > > > > > removed. > > > > > I am hoping to implement it on top of the SPI Flash EFI store [2] to > > > > > be able to set Boot order and boot items from Linux the UEFI way. > > > > > > > > > > Can I pick your brain on why it was dropped in the patch? > > > > > Is there any limitation in SetVariableRT service ? > > > > > > > > I recently had a talk about it in Plumbers [0]. Generally speaking, RT > > > > + hardware owned by the kernel is a very weird combination since you > > > > can't guarantee exclusive access to the flash or the bus and you have > > > > to preserve a *lot* of code alive in u-boot. > > > > > > > > I'll respond to your v1 patchset and we can discuss details there as > > > > well. > > > > > > > > [0] https://lpc.events/event/17/contributions/1653/ > > > > > > Thanks for the background and helping me understand the problem. > > > Makes me wonder how things work in the PC world. > > > U-boot being only ~1MB, can we not leave it all in memory and maybe > > > just disable SPI access to Linux. > > > > That's basically it, on x86 there's specific HW that's owned by > > firmware, I don't know the exact low level details of how that works. > > > > I think x86 devices generally use eSPI for this HW [1] but I don't > > know the low level details. The Arm SBSA (Server HW spec) and SBBR > > (Server Base Boot Requirements) specs that are key to ServerReady may > > go into some details too if you're curious. > > Thanks, > I think the firmware is still accessible to PCs as one could update the > firmware > in Windows so Windows has access to that device. I believe in most cases what happens is the OS sets up the update ready so the firmware itself can apply it on a reboot. This is how UEFI Capsule update works. If you run "fwupdmgr security" on a Linux system you can see some security features like "SPI lock" and "SPI write". I have at least one x86 hobbyist system where you can enable/disable the SPI access/lock but even with that the firmware update is done from the UEFI shell. > I had some try myself and found that setting a variable to memory backed > storage > is doable with SetVariable call but we want to store it in any > non-volatile storage > things really don't look good. > > To be able to write SetVariable to any device, the whole u-boot driver > model would need > to be kept in memory, might as well just keep the whole u-boot in > memory at this point, it's anyway small. > I don't have much knowledge on how to or pros and cons of doing this. I believe when set variable is running there is a small subset of U-Boot in memory but Ilias will definitely know the details there. > > > > BTW I plan to test your other patches on the Pinebook Pro. > > > > [1] > > https://www.totalphase.com/blog/2021/09/what-is-the-espi-protocol-and-how-does-it-improve-upon-lpc/ > > Thanks, that would be helpful. > I am particularly keen on the usb patch here > https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-...@shantur.com/ I'll take a look. Peter
Re: efi: Set Variable Runtime implementation
Hi Shantur, On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore wrote: > > Hi Ilias, > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas > wrote: > > > > Hi Shantur > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore wrote: > > > > > > Hi Heinrich, > > > > > > I am trying to work out how to enable the SetVariableRT service in > > > U-Boot and came across your patch [1] which initially had the > > > SetVariable RT service enabled in EFI but in the final patch this was > > > removed. > > > I am hoping to implement it on top of the SPI Flash EFI store [2] to > > > be able to set Boot order and boot items from Linux the UEFI way. > > > > > > Can I pick your brain on why it was dropped in the patch? > > > Is there any limitation in SetVariableRT service ? > > > > I recently had a talk about it in Plumbers [0]. Generally speaking, RT > > + hardware owned by the kernel is a very weird combination since you > > can't guarantee exclusive access to the flash or the bus and you have > > to preserve a *lot* of code alive in u-boot. > > > > I'll respond to your v1 patchset and we can discuss details there as well. > > > > [0] https://lpc.events/event/17/contributions/1653/ > > Thanks for the background and helping me understand the problem. > Makes me wonder how things work in the PC world. > U-boot being only ~1MB, can we not leave it all in memory and maybe > just disable SPI access to Linux. That's basically it, on x86 there's specific HW that's owned by firmware, I don't know the exact low level details of how that works. I think x86 devices generally use eSPI for this HW [1] but I don't know the low level details. The Arm SBSA (Server HW spec) and SBBR (Server Base Boot Requirements) specs that are key to ServerReady may go into some details too if you're curious. BTW I plan to test your other patches on the Pinebook Pro. [1] https://www.totalphase.com/blog/2021/09/what-is-the-espi-protocol-and-how-does-it-improve-upon-lpc/
[PATCH] doc: Remove README.sha1 file
The contents of README.sha1 only refer to process around verification
of the pcs440ep board firmware in flash. The device was removed in
commit 242836a893ae ("powerpc: ppc4xx: remove pcs440ep support") in
2015 so this readme isn't really relevant anymore so can be removed.
Signed-off-by: Peter Robinson
---
With the wide deprecation of sha1 in general we should likely also
review the use of sha1 in U-Boot as a whole and look to move the
remaining users of sha1 to sha2 or sha3 in general.
doc/README.sha1 | 58 -
1 file changed, 58 deletions(-)
delete mode 100644 doc/README.sha1
diff --git a/doc/README.sha1 b/doc/README.sha1
deleted file mode 100644
index f178f372643..000
--- a/doc/README.sha1
+++ /dev/null
@@ -1,58 +0,0 @@
-SHA1 usage:
-
-In the U-Boot Image for the pcs440ep board is a SHA1 checksum integrated.
-This SHA1 sum is used, to check, if the U-Boot Image in Flash is not
-corrupted.
-
-The following command is available:
-
-=> help sha1
-sha1 address len [addr] calculate the SHA1 sum [save at addr]
- -p calculate the SHA1 sum from the U-Boot image in flash and print
- -c check the U-Boot image in flash
-
-"sha1 -p"
- calculates and prints the SHA1 sum, from the Image stored in Flash
-
-"sha1 -c"
- check, if the SHA1 sum from the Image stored in Flash is correct
-
-
-It is possible to calculate a SHA1 checksum from a memoryrange with:
-
-"sha1 address len"
-
-If you want to store a new Image in Flash for the pcs440ep board,
-which has no SHA1 sum, you can do the following:
-
-a) cp the new Image on a position in RAM (here 0x30)
- (for this example we use the Image from Flash, stored at 0xfffa and
-0x6 Bytes long)
-
-"cp.b fffa 30 6"
-
-b) Initialize the SHA1 sum in the Image with 0x00
- The SHA1 sum is stored in Flash at:
- CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN +
SHA1_SUM_POS
- for the pcs440ep Flash: 0xfffa + 0x6 +-0x20
- = 0xffe0
- for the example in RAM:0x30 + 0x6 +-0x20
- = 0x35ffe0
-
- note: a SHA1 checksum is 20 bytes long.
-
-"mw.b 35ffe0 0 14"
-
-c) now calculate the SHA1 sum from the memoryrange and write
- the calculated checksum at the right place:
-
-"sha1 30 6 35ffe0"
-
-Now you have a U-Boot-Image for the pcs440ep board with the correct SHA1 sum.
-
-If you do a "buildman -k pcs440ep" or a "make all" to get the U-Boot image,
-which will be found in ../current/ipam390/ - the correct SHA1 sum will be
-automagically included in the U-Boot image.
-
-Heiko Schocher, 11 Jul 2007
--
2.42.0
Re: add orangepi zero3 to u-boot
Hi Stephen, > I have been able to build a working (tested on my orangepi zero3 1G) > u-boot for the orangepi zero3 with the following defconfig. Would it be > possible to add this config to the working boards. I would test it > again with an official build. The dtb/dts is in linux 6.6 and in u-boot. > > The H618 processor is software compatible with the H616 and the zero3 > board is very similar to the zero2 with the exception of DDR3 replaced > with LPDDR4 and the Realtek phy with Motorcomm. You've sent a variantion on this email twice today. The usual process for sending support upstream is via a git commit with appropriate pieces. I suggest having a look at the means of git commit/format-patch/send-email. Other than just a config file, you'll also need to add the upstream (from Linux) dts file. The OrangePi Zero2 commit [1] would be a good example to base you patch on. Peter [1] https://source.denx.de/u-boot/u-boot/-/commit/38be6b838780e8ad0ee80e716752c8843cd87e05 > CONFIG_ARM=y > CONFIG_ARCH_SUNXI=y > CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3" > CONFIG_SPL=y > CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707 > CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e > CONFIG_DRAM_SUN50I_H616_ODT_EN=0x > CONFIG_DRAM_SUN50I_H616_TPR0=0x0 > CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 > CONFIG_DRAM_SUN50I_H616_TPR10=0x402f0663 > CONFIG_DRAM_SUN50I_H616_TPR11=0x24242323 > CONFIG_DRAM_SUN50I_H616_TPR12=0x0e0e0e0e > CONFIG_MACH_SUN50I_H616=y > CONFIG_SUNXI_DRAM_H616_LPDDR4=y > CONFIG_DRAM_CLK=792 > CONFIG_R_I2C_ENABLE=y > CONFIG_SPL_SPI_SUNXI=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL_I2C=y > CONFIG_SPL_SYS_I2C_LEGACY=y > CONFIG_SYS_I2C_MVTWSI=y > CONFIG_SYS_I2C_SLAVE=0x7f > CONFIG_SYS_I2C_SPEED=40 > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_PHY_MOTORCOMM=y > CONFIG_SUN8I_EMAC=y > CONFIG_SPI=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > CONFIG_USB_MUSB_GADGET=y > CONFIG_AXP313_POWER=y > CONFIG_AXP_DCDC3_VOLT=1100 > CONFIG_CMD_BOOTZ=y >
Re: [PATCH] libretech-cc: Populate SMBIOS information
On Tue, Nov 21, 2023 at 2:50 PM Neil Armstrong
wrote:
>
> On 21/11/2023 15:09, Tom Rini wrote:
> > On Tue, Nov 21, 2023 at 02:46:29PM +0100, Neil Armstrong wrote:
> >> On 21/11/2023 14:15, Tom Rini wrote:
> >>> On Tue, Nov 21, 2023 at 10:18:04AM +0100, Neil Armstrong wrote:
> Hi Tom,
>
> On 20/11/2023 21:16, Tom Rini wrote:
> > Enable CONFIG_SYSINFO_SMBIOS and populate the nodes so that Linux can
> > eventually display this information
> >
> > Signed-off-by: Tom Rini
> > ---
> > Posting this as this was the easiest platform for me to test some SMBIOS
> > related patches on and I needed to populate the nodes so I could check
> > things in dmidecode once Linux was up.
>
> Sorry to be late a the party, but can't this be dynamically found from
> DT's compatible & model ?
> Since I'll probably need to add this to all boards, it seems like a
> duplicate of what's already in the DT.
> >>>
> >>> Part of the "fun" as to why we have the binding here is that while we
> >>> could use the top-level model property, there's not a corresponding one
> >>> for manufacturer. I'm fine ignoring the patch I posted here and having a
> >>> longer discussion about populating SMBIOS more usefully, globally, as I
> >>> think has been suggested a time or two.
> >>>
> >>
> >> I'm ok landing it with the same data as from the vendor.
> >> but couldn't we use the first top-level compatible as default smbios data ?
> >>
> >> compatible = "vendor1,board-name", "vendor1,soc-name";
> >>
> >> and translate to:
> >>
> >>
> >> smbios {
> >> system {
> >> manufacturer = "vendor1";
> >> product = "board-name";
> >> };
> >>
> >> baseboard {
> >> manufacturer = "vendor1";
> >> product = "board-name";
> >> };
> >>
> >> chassis {
> >> manufacturer = "vendor1";
> >> product = "board-name";
> >> };
> >> };
> >>
> >> since the vendor name should be already documented in the linux
> >> bindings, same for the board name.
> >> And we would be free to add some custom data in the DT if needed.
> >>
> >> Anyway, not sure it's the right place to discuss about that !
> >
> > That's essentially
> > https://patchwork.ozlabs.org/project/uboot/patch/20220906134426.53748-2-ilias.apalodi...@linaro.org/
> > which had a bunch of comments on 1/2:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220906134426.53748-1-ilias.apalodi...@linaro.org/
> >
> > But I think that since then some thoughts on the subject have changed
> > and that approach might be more welcome now than it was then.
> >
>
> Thanks for the pointer, seems I had the exact same idea.
> Hope this will be re-spinned, I don't want to add this to the 45 amlogic
> boards when we have the necessary info already available and documented...
Fedora has carried this patch for some time for the same reason, a lot
of the tools in distros around support use dmidecode for HW
information and reporting "Unknown" meant there was lots of reports
against tools all over the place. I'd been asking Ilias to upstream it
for a while so I'm in full agreement here and he did mention he would
resend it soon :)
Peter
Re: [PATCH v2 0/3] rpi5: initial support
Hi Dmitry, > These patches bring initial boot support for RPI5. Without it the I've given these a cursory look over, I have a system to test and will give them a whirl in the next few days, I was planning to start playing over the weekend so you've provided a great start :) > latest master fails with the message: > > DRAM: mbox: Timeout waiting for response > > bcm2835: Could not query ARM memory size > > With those patches and rpi_arm64_defconfig (with disabled > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > serial). FDT comes from firmware (EEPROM). > > > U-Boot 2024.01-rc3-3 > > > > DRAM: 1016 MiB (effective 8 GiB) > > mbox: Header response code invalid > > bcm2835: Could not query board revision > > FDT model : Raspberry Pi 5 Model B Rev 1.0 > > Core: 14 devices, 7 uclasses, devicetree: board > > MMC: > > Loading Environment from FAT... ** Bad device specification mmc 0 ** > > In:serial,usbkbd > > Out: serial,vidconsole > > Err: serial,vidconsole > > Net: No ethernet found. > > starting USB... > > No working controllers found > > Hit any key to stop autoboot: 0 > > No working controllers found > > No ethernet found. > > No ethernet found. > > U-Boot> > > These patches are based on v2024.01-rc3 and tested with RPI5 8GB. > > Known issues: > * CONFIG_VIDEO_BCM2835 doesn't work. When you say it doesn't work, does it just not output display or does the device lock up and you need to disable it? For the rpi4 it was as simple as adding a new compatible [1] for the rev6 of the IP block as for the bits that we use in U-Boot nothing changed, but the kernel changes for the rev7 that's in the RPi5 needed updating registers [2] so I'm not sure if we're going to need to do more for this or not. > * MBOX get board revision (0x10002) doesn't work (the response status > is 0x8000_0001). Looks like a number of tags doesn't work anymore > (board/serial/MAC) but could be fetched from FW FDT. Might be worth looking to see if there's changes in the kernel for this. In an initial look I didn't see any changes to their kernel here. We probably need a patch to the identifier too similar to the following: https://source.denx.de/u-boot/u-boot/-/commit/5e7e6619c85c090f6b62685a9d90f748f1729d12 Also probably worth adding a note about reviewing support in bcmstb_sdhci.c Regards, Peter > v2: > explicitly set .data section for rpi_bcm283x_mbox_addr due to relocation > issue > update memory map with VPU range > add a patch to get human readable model from FW FDT > > Dmitry Malkin (3): > rpi5: add initial memory map for bcm2712 > rpi5: add alternative way to get MBOX address via FDT node > rpi5: get_board is no longer works. Print model name from FW FDT > > arch/arm/mach-bcm283x/include/mach/base.h | 1 + > arch/arm/mach-bcm283x/include/mach/mbox.h | 4 +-- > arch/arm/mach-bcm283x/init.c | 40 ++- > board/raspberrypi/rpi/rpi.c | 6 > 4 files changed, 48 insertions(+), 3 deletions(-) [1] https://source.denx.de/u-boot/u-boot/-/commit/0059ef0be903a1f0a9afe5259fb2e0874f78a8ac [2] https://lists.freedesktop.org/archives/dri-devel/2023-October/428453.html
Re: [PATCH v2 3/3] rpi5: initial support
On Tue, Nov 21, 2023 at 10:55 PM Dmitry Malkin
wrote:
>
> rpi5: get_board is no longer works. Print model name from
> FW FDT
Diito
> rpi5 deprecated some calls/tags for MBOX. Better to use FW FDT.
> However it does not give all information.
Is that deprecation documented somewhere, in a forum post or something?
> Signed-off-by: Dmitry Malkin
> ---
> v2:
> new patch
> ---
> board/raspberrypi/rpi/rpi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index cd823ad746..6b678c5d23 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -429,6 +429,7 @@ static void get_board_revision(void)
> int ret;
> const struct rpi_model *models;
> uint32_t models_count;
> +const char *fdt_model;
>
> BCM2835_MBOX_INIT_HDR(msg);
> BCM2835_MBOX_INIT_TAG(>get_board_rev, GET_BOARD_REV);
> @@ -437,6 +438,11 @@ static void get_board_revision(void)
> if (ret) {
> printf("bcm2835: Could not query board revision\n");
> /* Ignore error; not critical */
> +if (fdt_magic(fw_dtb_pointer) == FDT_MAGIC) {
> +fdt_model = fdt_getprop((void *)fw_dtb_pointer, 0, "model",
> NULL);
> +if (fdt_model != 0)
> +printf("FW FDT model : %s\n", fdt_model);
> +}
> return;
> }
>
> --
> 2.40.1
Re: [PATCH v2 2/3] rpi5: initial support
> rpi5: add alternative way to get MBOX address via FDT
> node
Same note about descriptive commit titles, it's useful not to have 3
consecutive commits with the same title.
> MBOX on RPI5/bcm2712 has a different offset. Find it via
> "brcm,bcm2835-mbox" node.
Do we do use the DT node just for the RPi5 and the old method for all
older RPi, or do we move all generations to finding it by DT?
> Signed-off-by: Dmitry Malkin
> ---
> v2:
> new patch
> ---
> arch/arm/mach-bcm283x/include/mach/base.h | 1 +
> arch/arm/mach-bcm283x/include/mach/mbox.h | 4 ++--
> arch/arm/mach-bcm283x/init.c | 12 +++-
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
> b/arch/arm/mach-bcm283x/include/mach/base.h
> index 4ccaf69693..8cd224921e 100644
> --- a/arch/arm/mach-bcm283x/include/mach/base.h
> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> @@ -7,6 +7,7 @@
> #define _BCM283x_BASE_H_
>
> extern unsigned long rpi_bcm283x_base;
> +extern unsigned long rpi_bcm283x_mbox_addr;
>
> #ifdef CONFIG_ARMV7_LPAE
> #ifdef CONFIG_TARGET_RPI_4_32B
> diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
> b/arch/arm/mach-bcm283x/include/mach/mbox.h
> index 490664f878..ad086be467 100644
> --- a/arch/arm/mach-bcm283x/include/mach/mbox.h
> +++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
> @@ -38,8 +38,8 @@
>
> /* Raw mailbox HW */
>
> -#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
> - rpi_bcm283x_base + 0xb880; })
> +#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_mbox_addr); \
> + rpi_bcm283x_mbox_addr; })
>
> struct bcm2835_mbox_regs {
> u32 read;
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 362838e9b9..aef3a31f29 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -145,6 +145,11 @@ static void rpi_update_mem_map(void) {}
>
> unsigned long rpi_bcm283x_base = 0x3f00;
>
> +/* This is intialized before relocation. Enforce .data section usage.
> + * Otherwise it's going to .bss and will be zero after relocation.
> + */
> +unsigned long __section(".data") rpi_bcm283x_mbox_addr;
> +
> int arch_cpu_init(void)
> {
> icache_enable();
> @@ -154,7 +159,7 @@ int arch_cpu_init(void)
>
> int mach_cpu_init(void)
> {
> -int ret, soc_offset;
> +int ret, soc_offset, mbox_offset;
> u64 io_base, size;
>
> rpi_update_mem_map();
> @@ -170,6 +175,11 @@ int mach_cpu_init(void)
> return ret;
>
> rpi_bcm283x_base = io_base;
> +rpi_bcm283x_mbox_addr = rpi_bcm283x_base + 0xb880;
> +
> +mbox_offset = fdt_node_offset_by_compatible((void*)gd->fdt_blob,
> soc_offset, "brcm,bcm2835-mbox");
> +if (mbox_offset > soc_offset)
> +rpi_bcm283x_mbox_addr =
> fdt_get_base_address((void*)gd->fdt_blob, mbox_offset);
>
> return 0;
> }
> --
> 2.40.1
Re: [PATCH v2 1/3] rpi5: initial support
On Tue, Nov 21, 2023 at 10:54 PM Dmitry Malkin
wrote:
>
> rpi5: add initial memory map for bcm2712
Could this be the title for the patch, "initial support" is fine for
the cover letter, but doesn't really out line what this specific patch
actually does.
> includes:
> * 1GB of RAM (from 4GB or 8GB total)
> * VPU memory interface
> * SOC range (main peripherals)
Could you include details where this information came from as well please?
> Signed-off-by: Dmitry Malkin
> ---
> v2:
> new patch
> ---
> arch/arm/mach-bcm283x/init.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 7265faf6ce..362838e9b9 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -68,6 +68,33 @@ static struct mm_region
> bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
> }
> };
>
> +static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
> +{
> +.virt = 0xUL,
> +.phys = 0xUL,
> +.size = 0x3f80UL,
> +.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> + PTE_BLOCK_INNER_SHARE
> +}, {
> +.virt = 0x3f80UL,
> +.phys = 0x3f80UL,
> +.size = 0x0080UL,
> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +}, {
> +.virt = 0x107c00UL,
> +.phys = 0x107c00UL,
> +.size = 0x000400UL,
> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +}, {
> +/* List terminator */
> +0,
> +}
> +};
> +
> struct mm_region *mem_map = bcm283x_mem_map;
>
> /*
> @@ -78,6 +105,7 @@ static const struct udevice_id board_ids[] = {
> { .compatible = "brcm,bcm2837", .data = (ulong)_mem_map},
> { .compatible = "brcm,bcm2838", .data = (ulong)_mem_map},
> { .compatible = "brcm,bcm2711", .data = (ulong)_mem_map},
> +{ .compatible = "brcm,bcm2712", .data = (ulong)_mem_map},
> { },
> };
>
> --
> 2.40.1
Re: [PATCH v2 0/3] rpi5: initial support
> > These patches bring initial boot support for RPI5. Without it the > > latest master fails with the message: > > > DRAM: mbox: Timeout waiting for response > > > bcm2835: Could not query ARM memory size > > > > With those patches and rpi_arm64_defconfig (with disabled > > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > > serial). FDT comes from firmware (EEPROM). > > > > > U-Boot 2024.01-rc3-3 > > > > > > DRAM: 1016 MiB (effective 8 GiB) > > > mbox: Header response code invalid > > > bcm2835: Could not query board revision > > > FDT model : Raspberry Pi 5 Model B Rev 1.0 > > > Core: 14 devices, 7 uclasses, devicetree: board > > > MMC: > > > Loading Environment from FAT... ** Bad device specification mmc 0 ** > > > In:serial,usbkbd > > > Out: serial,vidconsole > > > Err: serial,vidconsole > > > Net: No ethernet found. > > > starting USB... > > > No working controllers found > > > Hit any key to stop autoboot: 0 > > > No working controllers found > > > No ethernet found. > > > No ethernet found. > > > U-Boot> > > > > These patches are based on v2024.01-rc3 and tested with RPI5 8GB. > > > > Known issues: > > * CONFIG_VIDEO_BCM2835 doesn't work. > > * MBOX get board revision (0x10002) doesn't work (the response status > > is 0x8000_0001). Looks like a number of tags doesn't work anymore > > (board/serial/MAC) but could be fetched from FW FDT. > > Nice. I think it's the MMC controller that we should be able to support > with just a little more work as it's shared with rockchip, and we just > need to match the compatible, and mirror whatever tweak is also in the > rpi kernel tree for it. Is it? According to the RPi DT the sdio1 interface is used to drive the mSD card (it's SD Express capable which I think is essentially PCIe/NVME) which has a "brcm,bcm2712-sdhci" compatible [2] which is added to the sdhci-brcmstb.c driver[3]. We do have a driver for this but it's not the rockchip driver, I think you may be confused with the sdhci interface in the RP1 chip which is a designware sdhci IP called dwcmshc [4]. For the brcmstb sdhci driver we currently have I suspect it'll need at least a few patches to get the basics working, in the short term I'm not sure we need the extra bits to drive the SD Express side of things as I'm sure it can fall back to old modes, looking at the patch it maybe just enough to add the compatible for what we need, that's what I was going to start with as it looks like it's similar to other IP [5]. Peter [1] https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/bcm2712-rpi-5-b.dts#L354 [2] https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/bcm2712.dtsi#L1164 [3] https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9 [4] https://github.com/raspberrypi/linux/commit/80dd8795ca631ac692fd3079487aea6d934a829c [5] https://github.com/raspberrypi/linux/commit/b627647c4500d39cb026924b608841fdf4d4d7e9#diff-8c952b8cbbb6b3d89e1a401d558b4bd0ecbdf1679cbc5004a31039bc5235c020R172
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
> > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > > > > to convert boards which I maintain to use DM drivers instead of > > > > > > > board hacks. > > > > > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > > > > > Is there a reason why the two above devices don't appear to have > > > > > > their > > > > > > .dts files in the upstream kernel? > > > > > > > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > > > existential enemies or as dirt at least. I was trying to work with > > > > > linux but I have no desire to spend any time to upstream endeavoru or > > > > > lg_x3. > > > > > > > > The usual policy for acceptance into U-Boot is to have upstream review > > > > in the kernel first. > > > > > > > > > > May you point to a policy which clearly and explicitly states this as > > > a mandatory condition? > > > > There have been a number of devices rejected in the past until their > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:, > > to clarify the exact policy. > > Well, here is where it's tricky. I brought this up for one of the > Broadcom MIPS platforms a week or two back, and Linus Walleij's point > (and I'm paraphrasing) is there's not really an upstream for it to go. > > What we cannot have is device tree bindings[1] that aren't upstream or > worse yet conflict with the official bindings. > > So the general way to resolve that is have device tree file be drop-in > from the linux kernel, and what additions we must have be done via > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in > sync with the kernel than other SoCs are. > > Now, upstream being actively hostile to dts files, especially for older > platforms? That's unfortunate. So long as we aren't violating the rules > about bindings, the intention is that we don't have device trees that > are either (a) massively out of sync with the kernel[2] or (b) kept > intentionally mismatched from the kernel. I don't believe I've seen upstream Tegra maintainers being actively hostile towards updates for older devices, I know they have certainly defocused them, but I'm not sure that's what I'd consider hostile. > [1]: There are both examples like binman that Simon is working on at > least but this is more exception than intentional rule. > [2]: Per our other conversions, I know the tegra ones are in this > unfortunate state in general
Re: rockpro64 rk3399 dwc3 issue
Hi, > I am trying to boot OS via USB3.0 ports on RK3399 base RockPro64. > U-boot is failing to detect the drive in the USB3.0 port. > > If I boot linux through other mediums the drive is detected and works fine. > Can anyone please help me figure out the issue? Can you share the version of U-Boot you're using?
Re: [PATCH v2 1/3] net: Get pxe config file from dhcp option 209
> > > > > > Allow dhcp server pass pxe config file full path by using option 209 > > > > > > > > > > > > Signed-off-by: Sean Edmond > > > > > > --- > > > > > > cmd/Kconfig | 4 > > > > > > cmd/pxe.c | 10 ++ > > > > > > net/bootp.c | 21 + > > > > > > 3 files changed, 35 insertions(+) > > > > > > > > > > > > diff --git a/cmd/Kconfig b/cmd/Kconfig > > > > > > index 5bc0a92d57..adbb1a6187 100644 > > > > > > --- a/cmd/Kconfig > > > > > > +++ b/cmd/Kconfig > > > > > > @@ -1826,6 +1826,10 @@ config BOOTP_PXE_CLIENTARCH > > > > > > default 0x15 if ARM > > > > > > default 0x0 if X86 > > > > > > > > > > > > +config BOOTP_PXE_DHCP_OPTION > > > > > > +bool "Request & store 'pxe_configfile' from BOOTP/DHCP server" > > > > > > +depends on BOOTP_PXE > > > > > > > > > > Why should this be disabled by default? > > > > > > > > > > Do we really want a separate config variable? > > > > > > > > > I expect most won't use this option to get the file path (they'll use > > > > the default paths as per the PXE specification). It makes more sense > > > > for me to keep it optional, like many of the other options? > > > > > > RFC 5701 seems to require this option. Hence we should make it default > > > yes. Boards that have a build size issue can opt out. > > > > The PXELINUX specification > > (https://wiki.syslinux.org/wiki/index.php?title=PXELINUX) doesn't state that > > option 209 is required. In the abense of option 209, PXELINUX will try the > > following default configuration files (this example is provided on the wiki > > link): > > /mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d > > /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd > > /mybootdir/pxelinux.cfg/C0A8025B > > /mybootdir/pxelinux.cfg/C0A8025 > > /mybootdir/pxelinux.cfg/C0A802 > > /mybootdir/pxelinux.cfg/C0A80 > > /mybootdir/pxelinux.cfg/C0A8 > > /mybootdir/pxelinux.cfg/C0A > > /mybootdir/pxelinux.cfg/C0 > > /mybootdir/pxelinux.cfg/C > > /mybootdir/pxelinux.cfg/default > > > > If 209 is requested/provided it tries the provided "config file" before the > > default paths. RFC 5071 should be seen as an extension for PXELINUX (not a > > requirement). RFC 5071 only states "The Config File Option MUST be supplied > > by the DHCP server if it appears on the Parameter Request List". > > We also want to be careful about overall size growth on common options, > even if someone can opt-out. Those are usually last-ditch stop-gaps and > it's better to make sure we really need functionality X/Y/Z by default, > for everyone. Especially with all of the work going on to make HTTP(s) > based network installs a viable option, how much more do we want to > change the PXE case, for everyone. I'm personally somewhat looking for > the use case to be well defined for a "this must be default". Network > provisioning is a thing, yes, but for whom/what, and in turn how broadly > do we need this to be in the vast majority of our boards (since it would > come in via BOOT*DEFAULTS or DISTRO_DEFAULTS). If PXE is being enabled I think it's useful in that it means the PXE client can be largely stateless because it can all be provided by central netowork configs as opposed to either hard wiring it into firmware or someone having to manually set them. This is likely also useful from the PoV less reasons to have a shell if it can be dealt with in code. >From the PoV of defaults, with or without HTTP boot, I suspect it probably makes sense to review whether PXE as a whole is enabled by default. That said a number of silicon vendors are actually actively removing PXE from their reference FW in favour of HTTP Boot due to security and a number of other reasons (easier for firewalls, caching/CDN, edge use cases outside of the data centre). Peter
Re: [PATCH v11 00/24] Modernize U-Boot shell
On Wed, Nov 8, 2023 at 12:49 AM Francis Laniel
wrote:
>
> Hi.
>
>
> During 2021 summer, Sean Anderson wrote a contribution to add a new shell,
> based
> on LIL, to U-Boot [1, 2].
> While one of the goals of this contribution was to address the fact actual
> U-Boot shell, which is based on Busybox hush, is old there was a discussion
> about adding a new shell versus updating the actual one [3, 4].
>
> So, in this series, with Harald Seiler, we updated the actual U-Boot shell to
> reflect what is currently in Busybox source code.
> Basically, this contribution is about taking a snapshot of Busybox
> shell/hush.c
> file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.
>
> This contribution was written to be as backward-compatible as possible to
> avoid
> breaking the existing.
> So, the 2021 hush flavor offers the same as the actual, that is to say:
> 1. Variable expansion.
> 2. Instruction lists (;, && and ||).
> 3. If, then and else.
> 4. Loops (for, while and until).
> No new features offered by Busybox hush were implemented (e.g. functions).
>
> It is possible to change the parser at runtime using the "cli" command:
> => cli print
> old
> => cli set 2021
> => cli print
> 2021
> => cli set old
> The default parser is the old one.
> Note that to use both parser, you would need to set both
> CONFIG_HUSH_2021_PARSER
> and CONFIG_HUSH_OLD_PARSER.
>
> In terms of testing, new unit tests were added to ut to ensure the new
> behavior
> is the same as the old one and it does not add regression.
> Nonetheless, if old behavior was buggy and fixed upstream, the fix is then
> added
> to U-Boot [5].
> In sandbox, all of these tests pass smoothly:
> => printenv board
> board=sandbox
> => ut hush
> Running 20 hush tests
> ...
> Failures: 0
> => parser set 2021
> => ut hush
> Running 20 hush tests
> ...
> Failures: 0
>
> Thanks to the effort of Harald Seiler, I was successful booting a board:
> => printenv fdtfile
> fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
> => cli get
> old
> => boot
> ...
> root@lepotato:~#
> root@lepotato:~# reboot
> ...
> => cli set 2021
> => cli get
> 2021
> => printenv fdtfile
> fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
> => boot
> ...
> root@lepotato:~#
>
> I had to not use CONFIG_HUSH_2021_PARSER for the keymile board.
> Indeed, the keymile board family is the only set of boards to call
> get_local_var(), set_local_var() and unset_local_var().
> Sadly, these functions are static in this contribution.
> I could have change all of them to introduce code like this:
> *_local_var(/*...*/)
> {
> if (gd->flags & GD_FLG_HUSH_OLD_PARSER)
> return *_local_var_old(/*...*/);
> if (gd->flags & GD_FLG_HUSH_2021_PARSER)
> return *_local_var_2021(/*...*/);
> }
> But this would have mean renaming all old hush functions calls and I did not
> want to change the old hush particularly to avoid breaking things.
> Instead, I change the keymile board to use environment variable instead of
> local
> ones.
> I think this particularities can be addressed in future works.
>
> I also had to enable CONFIG_LTO for kirkwoord sheevaplug and phytec bk4r1, so
> they do not hit their limits.
With nearly 15K lines of code added and the above limits being reached
how much does this increase the size of a binary if it's selected?
Those sorts of details are useful in these cover letters. Also of the
13k lines in cli_hush_upstream.c how much of that functionality is
actually used in U-Boot? You mention functions are not, while I
understand adding it straight from busybox has it's advantages for
easier rebasing, if it's also pulling in a lot of code that is never
used there's also detractions to adding 13k lines of code.
> For all these reasons, I marked this contribution as RFC to indeed collect
> your
> opinions.
> My goal is not to change suddenly actual shell to this one, we clearly need a
> transition period to think about it.
> I think it is better to see this contribution as a proof of concept which
> shows
> it is possible to update the actual shell.
>
> If you want to review it - your review will really be appreciated - here are
> some information regarding the commits:
> * commits marked as "test:" deal with unit tests.
> * commit "cli: Add Busybox upstream hush.c file." copies Busybox shell/hush.c
> into U-Boot tree, this explain why this commit contains around 12000
> additions.
> * commit "cli: Port Busybox 2021 hush to U-Boot." modifies previously added
> file
> to permit us to use this as new shell.
> The really good idea of #include'ing Busybox code into a wrapper file to
> define
> some particular functions while minimizing modifications to upstream code
> comes
> from Harald Seiler.
> * commit "cmd: Add new parser command" adds a new command which permits
> selecting parser at runtime.
> I am not really satisfied with the fact it calls cli_init() and cli_loop()
> each
> time the parser is set, so your reviews would be
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel wrote: > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel wrote: > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > > > > > > > Hi Svyatoslav, > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > > > to convert boards which I maintain to use DM drivers instead of board > > > > > hacks. > > > > > > > > > > Svyatoslav Ryhel (5): > > > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > > > > > Is there a reason why the two above devices don't appear to have their > > > > .dts files in the upstream kernel? > > > > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as > > > existential enemies or as dirt at least. I was trying to work with > > > linux but I have no desire to spend any time to upstream endeavoru or > > > lg_x3. > > > > The usual policy for acceptance into U-Boot is to have upstream review > > in the kernel first. > > > > May you point to a policy which clearly and explicitly states this as > a mandatory condition? There have been a number of devices rejected in the past until their DT are upstream but I'll leave Tom, who I've explicitly added on cc:, to clarify the exact policy. > > > > > board: transformer-t30: convert ASUS Transformers to use DM PMIC > > > > > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > > > > > ARM: dts: tegra30: enable USB PHY node on some devices > > > > > > > > > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > > > > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > > > > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > > > > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > > > > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > > > > > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > > > > > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > > > > > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > > > > > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > > > > > board/asus/grouper/Kconfig| 8 - > > > > > board/asus/grouper/Makefile | 4 +- > > > > > .../asus/grouper/configs/grouper_E1565.config | 6 +- > > > > > .../asus/grouper/configs/grouper_PM269.config | 6 +- > > > > > board/asus/grouper/configs/tilapia.config | 6 +- > > > > > board/asus/grouper/grouper-spl-max.c | 2 +- > > > > > board/asus/grouper/grouper-spl-ti.c | 2 +- > > > > > board/asus/grouper/grouper.c | 154 > > > > > +- > > > > > board/asus/transformer-t30/Kconfig| 10 -- > > > > > .../transformer-t30/configs/tf600t.config | 2 +- > > > > > .../transformer-t30/transformer-t30-spl.c | 2 +- > > > > > board/asus/transformer-t30/transformer-t30.c | 121 +- > > > > > board/htc/endeavoru/endeavoru-spl.c | 2 +- > > > > > board/htc/endeavoru/endeavoru.c | 72 +--- > > > > > board/lg/x3-t30/x3-t30-spl.c | 2 +- > > > > > board/lg/x3-t30/x3-t30.c | 97 +-- > > > > > configs/endeavoru_defconfig | 4 + > > > > > configs/grouper_common_defconfig | 1 + > > > > > configs/transformer_t30_defconfig | 5 + > > > > > configs/x3_t30_defconfig | 4 + > > > > > 29 files changed, 128 insertions(+), 450 deletions(-) > > > > > > > > > > -- > > > > > 2.40.1 > > > > >
Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC
On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel wrote: > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > > > > Hi Svyatoslav, > > > > > Since the proposed PMIC patches have been accepted, I see the need > > > to convert boards which I maintain to use DM drivers instead of board > > > hacks. > > > > > > Svyatoslav Ryhel (5): > > > board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC > > > board: endeavoru: convert HTC One X to use DM PMIC > > > > Is there a reason why the two above devices don't appear to have their > > .dts files in the upstream kernel? > > > > Yes, there is a reason. Linux maintainers treat submitters as > existential enemies or as dirt at least. I was trying to work with > linux but I have no desire to spend any time to upstream endeavoru or > lg_x3. The usual policy for acceptance into U-Boot is to have upstream review in the kernel first. > > > board: transformer-t30: convert ASUS Transformers to use DM PMIC > > > board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC > > > ARM: dts: tegra30: enable USB PHY node on some devices > > > > > > arch/arm/dts/tegra30-asus-grouper-common.dtsi | 7 + > > > .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 1 + > > > .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 1 + > > > .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 1 + > > > arch/arm/dts/tegra30-asus-p1801-t.dts | 17 ++ > > > arch/arm/dts/tegra30-asus-tf600t.dts | 15 ++ > > > arch/arm/dts/tegra30-asus-transformer.dtsi| 9 + > > > arch/arm/dts/tegra30-htc-endeavoru.dts| 8 + > > > arch/arm/dts/tegra30-lg-x3.dtsi | 9 + > > > board/asus/grouper/Kconfig| 8 - > > > board/asus/grouper/Makefile | 4 +- > > > .../asus/grouper/configs/grouper_E1565.config | 6 +- > > > .../asus/grouper/configs/grouper_PM269.config | 6 +- > > > board/asus/grouper/configs/tilapia.config | 6 +- > > > board/asus/grouper/grouper-spl-max.c | 2 +- > > > board/asus/grouper/grouper-spl-ti.c | 2 +- > > > board/asus/grouper/grouper.c | 154 +- > > > board/asus/transformer-t30/Kconfig| 10 -- > > > .../transformer-t30/configs/tf600t.config | 2 +- > > > .../transformer-t30/transformer-t30-spl.c | 2 +- > > > board/asus/transformer-t30/transformer-t30.c | 121 +- > > > board/htc/endeavoru/endeavoru-spl.c | 2 +- > > > board/htc/endeavoru/endeavoru.c | 72 +--- > > > board/lg/x3-t30/x3-t30-spl.c | 2 +- > > > board/lg/x3-t30/x3-t30.c | 97 +-- > > > configs/endeavoru_defconfig | 4 + > > > configs/grouper_common_defconfig | 1 + > > > configs/transformer_t30_defconfig | 5 + > > > configs/x3_t30_defconfig | 4 + > > > 29 files changed, 128 insertions(+), 450 deletions(-) > > > > > > -- > > > 2.40.1 > > >
Re: [PATCH v2 0/3] Implement GPIO cells for PALMAS and MAX77663 PMICs
On Mon, Nov 6, 2023 at 10:18 AM Svyatoslav Ryhel wrote: > > This patchset adds support for gpio-uclass to work with pmic gpio childrens > properly and implements MAX77663 and PALMAS GPIO cells/children as a > reference and to be further used in devices I am currently maintaining. > > All drivers are tested on actual hardware and confirmed to work as > expected. MAX77663 GPIO cell is tested on wexler qc750 tegra 3 device Is the MAX77663 seems more related to the MAX77686 PMIC, why is it being done as s a GPIO and not a PMIC driver or the existing driver extended to support this chip? > and PALMAS GPIO cell is tested on tegra note 7 tegra 4 device. > > --- > Changes from v1: > - isolate PMIC GPIO cells parsing behind enabling DM_PMIC > --- > > Svyatoslav Ryhel (3): > drivers: gpio-uclass: support PMIC GPIO children > drivers: gpio: implement MAX77663 GPIO cell > drivers: gpio: implement PALMAS GPIO cell > > drivers/gpio/Kconfig| 16 +++ > drivers/gpio/Makefile | 2 + > drivers/gpio/gpio-uclass.c | 19 +++ > drivers/gpio/max77663_gpio.c| 178 > drivers/gpio/palmas_gpio.c | 132 + > drivers/power/pmic/max77663.c | 9 ++ > drivers/power/pmic/palmas.c | 10 +- > include/dt-bindings/pmic/max77663.h | 18 +++ > include/power/max77663.h| 1 + > include/power/palmas.h | 12 ++ > 10 files changed, 396 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpio/max77663_gpio.c > create mode 100644 drivers/gpio/palmas_gpio.c > create mode 100644 include/dt-bindings/pmic/max77663.h > > -- > 2.40.1 >
