Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
Hi Tom, Marcel, On 16.11.23 19:42, Tom Rini wrote: On Thu, Nov 16, 2023 at 10:57:27AM +, Marcel Ziswiler wrote: Hi Tom On Thu, 2023-11-02 at 08:09 +0100, Marcel Ziswiler wrote: Hi Stefano On Thu, 2023-10-26 at 10:36 +0200, Stefano Babic wrote: On 26.10.23 10:29, Rasmus Villemoes wrote: On 26/10/2023 09.32, Marcel Ziswiler wrote: From: Marcel Ziswiler This fixes a regression in the eMMC fast boot mode case where the buffer was missing 464 bytes. The code figures out how many bytes must at least be fetched to honor the current read, rounds that up to the ss->pagesize [which is a no-op in the USB download case because that has ->pagesize==1], fetches that many bytes, but then recorded the original upper bound as the new end of the valid data. However, this did not take into account the rounding up to the ss->pagesize. Fix this by recording the actual bytes downloaded. Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size") Signed-off-by: Marcel Ziswiler Thanks for reporting and fixing this, and sorry for the trouble. Acked-by: Rasmus Villemoes And thanks for all your work - I will apply this fix soon. Any news on applying this fix? Note that master still stays broken as of today. And two weeks later still broken! I've put this in my not to forget queue for the next -rc. Anyway, I feel i.MX maintainership seems rather stalled at times most of the time. I don't want to criticise anybody knowing how busy our trade can get. However, if it helps the cause Toradex would be ready to step up. Let me know what you think. Thanks! I would be happy to see an additional custodian for the imx tree, if that's agreeable with Stefano. I have rather less time for U-Boot and it won't be better in the near future. Fabio is co-maintainer and he has accepted to take over the repository and go on maintaining u-boot-imx. Just let him some time to be confident with patchwork and CI. Thanks, Stefano -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200
Hi Tom On 17/11/23 00:10, Tom Rini wrote: On Thu, Nov 16, 2023 at 11:43:50AM +0530, Neha Malcom Francis wrote: Hi Tom, Trying to bring back this series here. On 03/10/23 20:40, Tom Rini wrote: On Tue, Oct 03, 2023 at 07:57:04PM +0530, Kumar, Udit wrote: On 10/3/2023 1:40 PM, Keerthy wrote: Enable ESM initialization for J7200 Signed-off-by: Keerthy --- board/ti/j721e/evm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c index 42fa94b7a5..070b28326f 100644 --- a/board/ti/j721e/evm.c +++ b/board/ti/j721e/evm.c @@ -543,7 +543,8 @@ void spl_board_init(void) } #ifdef CONFIG_ESM_K3 - if (board_ti_k3_is("J721EX-PM2-SOM")) { + if ((board_ti_k3_is("J721EX-PM2-SOM")) || + IS_ENABLED(CONFIG_TARGET_J7200_R5_EVM)) { Could we align on one kind of check, For J721E check is done against board-id, whereas for J7200 checking We should look at figuring out how to split this file in two. One for "generic J721E systems" and one for "TI EVMs", as I've mentioned in other threads, so that it's easier for custom platforms to drop code they don' require. Yes that does make sense. Would it be okay if we solve that problem separately in a different patch series? We can move along with this current series for now (after making the required change in CONFIG/board-id for v2) since ESM support is important for these platforms. Well, I think part of the answer to your question is (and this is a more general TI one too), what outstanding changes need to come in now to make existing platforms functional for v2024.01 ? My first thought is that this series would be taken to -next, if I took it now, which means there's time before it would be in master, and so if it really makes the re-org later easier, we could take it, but if not, can we re-org then do this? But if we need this to deal with regressions, OK, yes, we can take it like this now. Maybe focusing on the re-org after having in the changes would help give more perspective on how we can split? Not sure just a thought... in that case I prefer taking this in and having a working error signaling module in rather than delaying it if that's okay. -- Thanking You Neha Malcom Francis
Re: [PATCH v2] net: designware: Add bitbang feature for designware driver
On Fri, Nov 17, 2023 at 10:04:53AM +0800, Jim Liu wrote: > Add bb_miiphy_bus function for designware bitbang feature. > > Signed-off-by: Jim Liu > --- > Changes for v2: >- add bitbang delay dts read >- modify printf to debug > --- > drivers/net/designware.c | 105 +++ > drivers/net/designware.h | 5 ++ > 2 files changed, 110 insertions(+) > > diff --git a/drivers/net/designware.c b/drivers/net/designware.c > index a174344b3e..e86f96fc1a 100644 > --- a/drivers/net/designware.c > +++ b/drivers/net/designware.c > @@ -767,6 +767,31 @@ int designware_eth_probe(struct udevice *dev) > priv->bus = miiphy_get_dev_by_name(dev->name); > priv->dev = dev; > > +#if defined(CONFIG_BITBANGMII) && CONFIG_IS_ENABLED(DM_GPIO) > + if (dev_read_bool(dev, "snps,bitbang-mii")) { > + debug("\n%s: use bitbang mii..\n", dev->name); > + ret = gpio_request_by_name(dev, "snps,mdc-gpio", 0, > +&priv->mdc_gpio, GPIOD_IS_OUT | > GPIOD_IS_OUT_ACTIVE); > + if (ret) { > + printf("no mdc-gpio\n"); > + return ret; > + } > + ret = gpio_request_by_name(dev, "snps,mdio-gpio", 0, > +&priv->mdio_gpio, GPIOD_IS_OUT | > GPIOD_IS_OUT_ACTIVE); > + if (ret) { > + printf("no mdio-gpio\n"); > + return ret; > + } > + > + priv->bb_delay = dev_read_u32_default(dev, > "snps,bitbang-delay", 1); > + > + bb_miiphy_buses[0].priv = priv; > + sprintf(bb_miiphy_buses[0].name, dev->name); If designware_eth_probe() is called for multiple Ethernet interfaces then only the last interface to be probed will have a working MDIO bus. We should either support multiple buses here or raise an error if there is an attempt to probe a second interface. (I spotted the same issue in the ravb driver while extending it to support a board with two Ethernet interfaces) Thanks, Paul signature.asc Description: PGP signature
RE: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
Hi Eugen, I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board. I used the latest u-boot/master branch for this test. I noticed that the file size of the binaries have beed reduced with aprox 150KiB due to CONFIG_SYS_THUMB_BUILD=y. After flashing the new binaries on these boards I can confirm that on all boards the linux kernel was booted properly from mmc, qspi-flash, nand-flash and usb. I tested using bootm and bootz commands. Best regards, Mihai Sain On 11/16/23 20:47, Tom Rini wrote: > On Sat, Nov 04, 2023 at 10:27:42PM -0400, Sean Anderson wrote: > >> Several AT91 boards are quite close to their SPL size limit. For >> example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit >> and doesn't even fit with older GCCs. >> >> All AT91 processors should have thumb support. Enable >> SYS_THUMB_BUILD. This shrinks SPL by around 30%. >> >> Signed-off-by: Sean Anderson >> --- >> This has been BUILD TESTED ONLY! > > We in turn need this for Sean's other cleanup series to go in. Is this > OK? Would it be safer if it was only for CPU_V7A ? I do have > recollections of thumb being sometimes buggy prior to v7a cores. Thanks! > Hi Tom, I would like this to be tested on a few boards at least. There are boards with Cortex A5, A7 and ARM926 which are important, one of each of them and booting Linux should be enough I think. Nicolas, Aubin ? I remember you guys have also a CI tool that is fairly easy to use if you just push a branch/commit. + Mihai as well. Eugen
Re: [PATCH] bootstd: Avoid freeing a non-allocated buffer
On Thu, Nov 16, 2023 at 1:35 AM Simon Glass wrote: > > EFI applications can be very large and thus used to cause boot failures > when malloc() space was exhausted. > > A recent changed fixed this by using the kernel_addr_r environment var > as the address of the buffer. However, it still frees the buffer when > the bootflow is discarded. > > Fix this by introducing a flag to indicate whether the buffer was > allocated, or not. > > Note that kernel_addr_r is not the last word here. It might be better > to use lmb to place images. But there is a lot of refactoring to do > before we can remove the environment variables. The distro scripts rely > on them so it is safe for bootstd to do so too. > > Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file > > Signed-off-by: Simon Glass > Reported by: Simon Glass > Reported by: Shantur Rathore Tested-by: Shantur Rathore > --- > > boot/bootflow.c | 3 ++- > boot/bootmeth_efi.c | 1 + > include/bootflow.h | 5 - > 3 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/boot/bootflow.c b/boot/bootflow.c > index 6922e7e0c4e7..1ea2966ae9a5 100644 > --- a/boot/bootflow.c > +++ b/boot/bootflow.c > @@ -467,7 +467,8 @@ void bootflow_free(struct bootflow *bflow) > free(bflow->name); > free(bflow->subdir); > free(bflow->fname); > - free(bflow->buf); > + if (!(bflow->flags & BOOTFLOWF_STATIC_BUF)) > + free(bflow->buf); > free(bflow->os_name); > free(bflow->fdt_fname); > free(bflow->bootmeth_priv); > diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c > index ae936c8daa18..9ba7734911e1 100644 > --- a/boot/bootmeth_efi.c > +++ b/boot/bootmeth_efi.c > @@ -160,6 +160,7 @@ static int efiload_read_file(struct bootflow *bflow, > ulong addr) > if (ret) > return log_msg_ret("read", ret); > bflow->buf = map_sysmem(addr, bflow->size); > + bflow->flags |= BOOTFLOWF_STATIC_BUF; > > set_efi_bootdev(desc, bflow); > > diff --git a/include/bootflow.h b/include/bootflow.h > index 44d3741eacae..fede8f22a2b8 100644 > --- a/include/bootflow.h > +++ b/include/bootflow.h > @@ -43,9 +43,12 @@ enum bootflow_state_t { > * and it is using the prior-stage FDT, which is the U-Boot control FDT. > * This is only possible with the EFI bootmeth (distro-efi) and only when > * CONFIG_OF_HAS_PRIOR_STAGE is enabled > + * @BOOTFLOWF_STATIC_BUF: Indicates that @bflow->buf is statically set, > rather > + * than being allocated by malloc(). > */ > enum bootflow_flags_t { > BOOTFLOWF_USE_PRIOR_FDT = 1 << 0, > + BOOTFLOWF_STATIC_BUF= 1 << 1, > }; > > /** > @@ -72,7 +75,7 @@ enum bootflow_flags_t { > * @fname: Filename of bootflow file (allocated) > * @logo: Logo to display for this bootflow (BMP format) > * @logo_size: Size of the logo in bytes > - * @buf: Bootflow file contents (allocated) > + * @buf: Bootflow file contents (allocated unless @flags & > BOOTFLOWF_STATIC_BUF) > * @size: Size of bootflow file in bytes > * @err: Error number received (0 if OK) > * @os_name: Name of the OS / distro being booted, or NULL if not known > -- > 2.43.0.rc0.421.g78406f8d94-goog >
Re: [PATCH v3 5/5] pmic: qcom: dont use dev_read_addr to get USID
On Tue, 14 Nov 2023 at 19:18, Caleb Connolly wrote: > > Linux DTs stuff a value indicating if the USID is a USID or a GSID in the > reg property, the Linux SPMI driver then reads the two address cells > separately. U-boot's dev_read_addr() doesn't know how to handle this, so > use ofnode_read_u32_index() to get just the USID. > > The Qcom pmic driver doesn't have support for GSID handling, so just > ignore the second value for now. > Since you are trying to add Linux DT bindings compatibility here, I suggest you drop custom u-boot binding here: doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt. -Sumit > Signed-off-by: Caleb Connolly > --- > drivers/power/pmic/pmic_qcom.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/power/pmic/pmic_qcom.c b/drivers/power/pmic/pmic_qcom.c > index ad8daf43f06f..f2ac6494811d 100644 > --- a/drivers/power/pmic/pmic_qcom.c > +++ b/drivers/power/pmic/pmic_qcom.c > @@ -66,12 +66,19 @@ static const struct udevice_id pmic_qcom_ids[] = { > static int pmic_qcom_probe(struct udevice *dev) > { > struct pmic_qcom_priv *priv = dev_get_priv(dev); > + int ret; > > - priv->usid = dev_read_addr(dev); > - > - if (priv->usid == FDT_ADDR_T_NONE) > + /* > +* dev_read_addr() can't be used here because the reg property > actually > +* contains two discrete values, not a single 64-bit address. > +* The address is the first value. > +*/ > + ret = ofnode_read_u32_index(dev_ofnode(dev), "reg", 0, &priv->usid); > + if (ret < 0) > return -EINVAL; > > + debug("usid: %d\n", priv->usid); > + > return 0; > } > > > -- > 2.42.1 >
[PATCH V3] riscv: binman: fix the load field format
Using /bits/ 64 prefix for 64 bits address Signed-off-by: Randolph Reviewed-by: Simon Glass --- arch/riscv/dts/binman.dtsi | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi index 6b4eb8dc7b..9271de0ddf 100644 --- a/arch/riscv/dts/binman.dtsi +++ b/arch/riscv/dts/binman.dtsi @@ -5,9 +5,6 @@ #include -#define U64_TO_U32_H(addr) (((addr) >> 32) & 0x) -#define U64_TO_U32_L(addr) ((addr) & 0x) - / { binman: binman { multiple-images; @@ -36,8 +33,7 @@ os = "U-Boot"; arch = "riscv"; compression = "none"; - load = ; + load = /bits/ 64 ; uboot_blob: blob-ext { filename = "u-boot-nodtb.bin"; @@ -50,7 +46,7 @@ os = "Linux"; arch = "riscv"; compression = "none"; - load = ; + load = /bits/ 64 ; linux_blob: blob-ext { filename = "Image"; @@ -64,10 +60,8 @@ os = "opensbi"; arch = "riscv"; compression = "none"; - load = ; - entry = ; + load = /bits/ 64 ; + entry = /bits/ 64 ; opensbi_blob: opensbi { filename = "fw_dynamic.bin"; -- 2.34.1
[PATCH v2 0/6] some LED patches
I wanted to add support for ti,lp5562, and found an old submission from Doug. While trying to modify that to work in current U-Boot, I found a problem with the "move label handling to core" patches. Patch 1 is a prerequisite for the ti,lp5562 driver, which turned out to be needed by Christian as well. Patch 2 is an attempt at (quick-)fixing the mentioned "move label handling to core" problem. The real fix consists of changing remaining drivers to not bind the same driver to the top node as to the child nodes, but I can't test those other drivers. Patch 3 introduces a helper which should allow removing some boilerplate in most individual drivers, and 4,5 apply that in the gpio and pwm drivers. Converting remaining drivers is trivial, but left out for now. Finally patch 6 is the reworked lp5562 driver. While I've changed it to match existing DT bindings (with the goal of making it work with our .dts that is known to work with the linux driver), most of the logic is unchanged from Doug's original patch, so he is still listed as author. Changes in v2: Interchange order of patches 1 and 2, add a few R-bs, and try to trim down the commit message in patch 2. Doug Zobel (1): led: add TI LP5562 LED driver Rasmus Villemoes (5): led-uclass: honour ->label field populated by driver's own .bind led-uclass: do not create fallback label for top-level node led: introduce led_bind_generic() led: led_gpio: use led_bind_generic() helper led: led_pwm: use led_bind_generic() helper doc/device-tree-bindings/leds/leds-lp5562.txt | 63 ++ drivers/led/Kconfig | 8 + drivers/led/Makefile | 1 + drivers/led/led-uclass.c | 22 +- drivers/led/led_gpio.c| 15 +- drivers/led/led_lp5562.c | 578 ++ drivers/led/led_pwm.c | 14 +- include/led.h | 8 + 8 files changed, 681 insertions(+), 28 deletions(-) create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt create mode 100644 drivers/led/led_lp5562.c -- 2.40.1.1.g1c60b9335d
[PATCH v2 1/6] led-uclass: honour ->label field populated by driver's own .bind
If the driver's own .bind method has populated uc_plat->label, don't override that. This is necessary for an upcoming driver for ti,lp5562, where the DT binding unfortunately says to use "chan-name" and not "label". Reviewed-by: Christian Gmeiner Reviewed-by: Marek Vasut Signed-off-by: Rasmus Villemoes --- drivers/led/led-uclass.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c index 68ca3c29702..009f1080197 100644 --- a/drivers/led/led-uclass.c +++ b/drivers/led/led-uclass.c @@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev) struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev); const char *default_state; - uc_plat->label = dev_read_string(dev, "label"); + if (!uc_plat->label) + uc_plat->label = dev_read_string(dev, "label"); + if (!uc_plat->label) uc_plat->label = ofnode_get_name(dev_ofnode(dev)); -- 2.40.1.1.g1c60b9335d
[PATCH v2 3/6] led: introduce led_bind_generic()
All existing drivers in drivers/led/ contain a .bind method that does exactly the same thing, with just the actual driver name differing. Create a helper so all those individual methods can be changed to one-liners. Reviewed-by: Marek Vasut Signed-off-by: Rasmus Villemoes --- drivers/led/led-uclass.c | 18 ++ include/led.h| 8 2 files changed, 26 insertions(+) diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c index 0232fa84def..a4be56fc258 100644 --- a/drivers/led/led-uclass.c +++ b/drivers/led/led-uclass.c @@ -11,9 +11,27 @@ #include #include #include +#include #include #include +int led_bind_generic(struct udevice *parent, const char *driver_name) +{ + struct udevice *dev; + ofnode node; + int ret; + + dev_for_each_subnode(node, parent) { + ret = device_bind_driver_to_node(parent, driver_name, +ofnode_get_name(node), +node, &dev); + if (ret) + return ret; + } + + return 0; +} + int led_get_by_label(const char *label, struct udevice **devp) { struct udevice *dev; diff --git a/include/led.h b/include/led.h index 329041008c1..a6353166289 100644 --- a/include/led.h +++ b/include/led.h @@ -110,4 +110,12 @@ enum led_state_t led_get_state(struct udevice *dev); */ int led_set_period(struct udevice *dev, int period_ms); +/** + * led_bind_generic() - bind children of parent to given driver + * + * @parent: Top-level LED device + * @driver_name: Driver for handling individual child nodes + */ +int led_bind_generic(struct udevice *parent, const char *driver_name); + #endif -- 2.40.1.1.g1c60b9335d
[PATCH v2 4/6] led: led_gpio: use led_bind_generic() helper
Use the helper led_bind_generic() to reduce code duplication. Signed-off-by: Rasmus Villemoes --- drivers/led/led_gpio.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c index fbed151b5d9..71421de628c 100644 --- a/drivers/led/led_gpio.c +++ b/drivers/led/led_gpio.c @@ -11,7 +11,6 @@ #include #include #include -#include struct led_gpio_priv { struct gpio_desc gpio; @@ -80,19 +79,7 @@ static int led_gpio_remove(struct udevice *dev) static int led_gpio_bind(struct udevice *parent) { - struct udevice *dev; - ofnode node; - int ret; - - dev_for_each_subnode(node, parent) { - ret = device_bind_driver_to_node(parent, "gpio_led", -ofnode_get_name(node), -node, &dev); - if (ret) - return ret; - } - - return 0; + return led_bind_generic(parent, "gpio_led"); } static const struct led_ops gpio_led_ops = { -- 2.40.1.1.g1c60b9335d
[PATCH v2 2/6] led-uclass: do not create fallback label for top-level node
Many existing drivers, and led-uclass itself, rely on uc_plat->label being NULL for the device representing the top node, as opposed to the child nodes representing individual LEDs. This means that the drivers whose .probe methods rely on this were broken by 83c63f0d1185 ("led: Move OF "label" property parsing to core"), and also that the top node wrongly shows up with 'led list'. Binding the same driver to the top node as to the individual child nodes is arguably wrong, and the approach of using a UCLASS_NOP driver for the top node is probably better - this has for example been done in commits 01074697801b and 910b01c27c04. Until remaining affected drivers are fixed, we can use a heuristic that only sets the label to the fallback value derived from the node name if the node does not have a "compatible" property - i.e., if it has been bound to the LED driver explicitly via device_bind_driver_to_node(). This is similar to what e3aa76644c2a did for gpio_led, but that fix was then supplanted by 01074697801b. Fixes: 83c63f0d1185 ("led: Move OF "label" property parsing to core") Signed-off-by: Rasmus Villemoes --- drivers/led/led-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c index 009f1080197..0232fa84def 100644 --- a/drivers/led/led-uclass.c +++ b/drivers/led/led-uclass.c @@ -74,7 +74,7 @@ static int led_post_bind(struct udevice *dev) if (!uc_plat->label) uc_plat->label = dev_read_string(dev, "label"); - if (!uc_plat->label) + if (!uc_plat->label && !dev_read_string(dev, "compatible")) uc_plat->label = ofnode_get_name(dev_ofnode(dev)); uc_plat->default_state = LEDST_COUNT; -- 2.40.1.1.g1c60b9335d
[PATCH v2 6/6] led: add TI LP5562 LED driver
From: Doug Zobel Driver for the TI LP5562 4 channel LED controller. Supports independent on/off control of all 4 channels. Supports LED_BLINK on 3 independent channels: blue/green/red. The white channel can blink, but shares the blue channel blink rate. Heavily based on patch originally from Doug Zobel [1]. I have modified it so it matches the DT bindings in the linux tree, and also follows the linux driver implementation more closely. This should address Tom's concerns, and also matches my goal of making the U-Boot driver work with our existing .dts which is known to work in linux. As our boards only have the R,G,B outputs connected, I have not actually tested how the white channel behaves, but the R,G,B work exactly as expected. [1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zo...@climate.com/ Cc: Doug Zobel Signed-off-by: Rasmus Villemoes --- doc/device-tree-bindings/leds/leds-lp5562.txt | 63 ++ drivers/led/Kconfig | 8 + drivers/led/Makefile | 1 + drivers/led/led_lp5562.c | 578 ++ 4 files changed, 650 insertions(+) create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt create mode 100644 drivers/led/led_lp5562.c diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt b/doc/device-tree-bindings/leds/leds-lp5562.txt new file mode 100644 index 000..4e0c742959a --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-lp5562.txt @@ -0,0 +1,63 @@ +LEDs connected to TI LP5562 controller + +This driver works with a TI LP5562 4-channel LED controller. +CONFIG_LED_BLINK is supported using the controller engines. However +there are only 3 engines available for the 4 channels. This means +that the blue and white channels share the same engine. When both +blue and white LEDs are set to blink, they will share the same blink +rate. Changing the blink rate of the blue LED will affect the white +LED and vice-versa. Manual on/off is handled independently for all 4 +channels. + +Required properties: + - compatible : should be "ti,lp5562". + - #address-cells : must be 1. + - #size-cells : must be 0. + - reg : LP5562 LED controller I2C address. + +Optional properties: + - enable-gpios : Enable GPIO + - clock-mode : u8, configures the clock mode: + - 0 # automode + - 1 # internal + - 2 # external + +Each LED is represented as a sub-node of the ti,lp5562 device. + +LED sub-node required properties: + - reg : Zero-based channel identifier: +- 0 red +- 1 green +- 2 blue +- 3 white + +LED sub-node optional properties: + - chan-name : name of LED + - max-cur : LED current at max brightness in 100uA steps (0x00 - 0xFF) +Default : 100 (10 mA) + +Example: +leds0: lp5562@30 { +compatible = "ti,lp5562"; +#address-cells = <1>; +#size-cells = <0>; +enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>; +reg = <0x30>; + clock-mode = /bits/8 <1>; + +led@0 { +reg = <0>; +chan-name = "red"; +max-cur = /bits/ 8 <200>; /* 20mA */ +}; +led@1 { +reg = <1>; +chan-name = "green"; +max-cur = /bits/ 8 <200>; /* 20mA */ +}; +led@2 { +reg = <2>; +chan-name = "blue"; +max-cur = /bits/ 8 <200>; /* 20mA */ +}; +}; diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig index 996b757e6d0..9837960198d 100644 --- a/drivers/led/Kconfig +++ b/drivers/led/Kconfig @@ -49,6 +49,14 @@ config LED_CORTINA This option enables support for LEDs connected to the Cortina Access CA SOCs. +config LED_LP5562 + bool "LED Support for LP5562" + depends on LED && DM_I2C + help + This option enables support for LEDs connected to the TI LP5562 + 4 channel I2C LED controller. Driver fully supports blink on the + B/G/R LEDs. White LED can blink, but re-uses the period from blue. + config LED_PWM bool "LED PWM" depends on LED && DM_PWM diff --git a/drivers/led/Makefile b/drivers/led/Makefile index 49ae91961d5..2bcb8589087 100644 --- a/drivers/led/Makefile +++ b/drivers/led/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o obj-$(CONFIG_LED_PWM) += led_pwm.o obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o obj-$(CONFIG_LED_CORTINA) += led_cortina.o +obj-$(CONFIG_LED_LP5562) += led_lp5562.o diff --git a/drivers/led/led_lp5562.c b/drivers/led/led_lp5562.c new file mode 100644 index 000..87479ec5515 --- /dev/null +++ b/drivers/led/led_lp5562.c @@ -0,0 +1,578 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Doug Zobel + * + * Driver for TI lp5562 4
[PATCH v2 5/6] led: led_pwm: use led_bind_generic() helper
Use the helper led_bind_generic() to reduce code duplication. Signed-off-by: Rasmus Villemoes --- drivers/led/led_pwm.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/drivers/led/led_pwm.c b/drivers/led/led_pwm.c index 7c8eae9337b..ae6de3087ab 100644 --- a/drivers/led/led_pwm.c +++ b/drivers/led/led_pwm.c @@ -9,7 +9,6 @@ #include #include #include -#include #include #define LEDS_PWM_DRIVER_NAME "led_pwm" @@ -136,18 +135,7 @@ static int led_pwm_of_to_plat(struct udevice *dev) static int led_pwm_bind(struct udevice *parent) { - struct udevice *dev; - ofnode node; - int ret; - - dev_for_each_subnode(node, parent) { - ret = device_bind_driver_to_node(parent, LEDS_PWM_DRIVER_NAME, -ofnode_get_name(node), -node, &dev); - if (ret) - return ret; - } - return 0; + return led_bind_generic(parent, LEDS_PWM_DRIVER_NAME); } static const struct led_ops led_pwm_ops = { -- 2.40.1.1.g1c60b9335d
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On 11/17/23 11:15, mihai.s...@microchip.com wrote: Hi Eugen, I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board. I used the latest u-boot/master branch for this test. I noticed that the file size of the binaries have beed reduced with aprox 150KiB due to CONFIG_SYS_THUMB_BUILD=y. After flashing the new binaries on these boards I can confirm that on all boards the linux kernel was booted properly from mmc, qspi-flash, nand-flash and usb. I tested using bootm and bootz commands. Thank you Mihai, Tom, Sean, are you okay with this going in the next merge window ? It is definitely not a fix, so that would be the best. Eugen Best regards, Mihai Sain On 11/16/23 20:47, Tom Rini wrote: On Sat, Nov 04, 2023 at 10:27:42PM -0400, Sean Anderson wrote: Several AT91 boards are quite close to their SPL size limit. For example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't even fit with older GCCs. All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This shrinks SPL by around 30%. Signed-off-by: Sean Anderson --- This has been BUILD TESTED ONLY! We in turn need this for Sean's other cleanup series to go in. Is this OK? Would it be safer if it was only for CPU_V7A ? I do have recollections of thumb being sometimes buggy prior to v7a cores. Thanks! Hi Tom, I would like this to be tested on a few boards at least. There are boards with Cortex A5, A7 and ARM926 which are important, one of each of them and booting Linux should be enough I think. Nicolas, Aubin ? I remember you guys have also a CI tool that is fairly easy to use if you just push a branch/commit. + Mihai as well. Eugen
[PATCH] sbp1: Add support for IBM SBP1 board
From: Patrick Rudolph Add defconfig & devicetree for IBM SBP1 board BMC based on AST2600 SoC. Signed-off-by: Patrick Rudolph Signed-off-by: Naresh Solanki --- arch/arm/dts/Makefile | 4 +- arch/arm/dts/ast2600-sbp1.dts | 96 ++ configs/ibm-sbp1_defconfig| 126 ++ 3 files changed, 225 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/ast2600-sbp1.dts create mode 100644 configs/ibm-sbp1_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 1be08c5fdc..85514fb8ba 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1353,7 +1353,9 @@ dtb-$(CONFIG_BCM6878) += \ bcm96878.dtb dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb -dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb +dtb-$(CONFIG_ASPEED_AST2600) += \ + ast2600-evb.dtb \ + ast2600-sbp1.dtb dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb diff --git a/arch/arm/dts/ast2600-sbp1.dts b/arch/arm/dts/ast2600-sbp1.dts new file mode 100644 index 00..5c862e2c1c --- /dev/null +++ b/arch/arm/dts/ast2600-sbp1.dts @@ -0,0 +1,96 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/dts-v1/; + +#include +#include "ast2600-evb.dts" + +/ { + model = "IBM SBP1"; + compatible = "ibm,sbp1-bmc", "aspeed,ast2600"; + memory { + device_type = "memory"; + reg = <0x8000 0x2000>; + }; + + chosen { + stdout-path = &uart1; + }; + + aliases { + mmc0 = &emmc; + mmc1 = &sdhci0; + mmc2 = &sdhci1; + ethernet0 = &mac2; + ethernet1 = &mac3; + }; + + cpus { + cpu@0 { + clock-frequency = <12>; + }; + cpu@1 { + clock-frequency = <12>; + }; + }; + +}; + +&uart1 { + bootph-all; + status = "okay"; +}; + +&uart5 { + status = "disabled"; +}; + +&mdio { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mdio3_default &pinctrl_mdio4_default>; +}; + +&mac0 { + status = "disabled"; +}; + +&mac1 { + status = "disabled"; +}; + +&gpio0 { + status = "okay"; + line_50 { + gpio-hog; + gpios = <50 GPIO_ACTIVE_LOW>; + output-low; + line-name = "BMC_MAC1_RESET_N"; + }; + line_175 { + gpio-hog; + gpios = <175 GPIO_ACTIVE_LOW>; + output-low; + line-name = "BMC_MAC0_RESET_N"; + }; +}; + +&spi1 { + status = "disabled"; +}; + +&spi2 { + status = "disabled"; +}; + +&emmc { + status = "disabled"; +}; + +&sdhci0 { + status = "disabled"; +}; + +&sdhci1 { + status = "disabled"; +}; diff --git a/configs/ibm-sbp1_defconfig b/configs/ibm-sbp1_defconfig new file mode 100644 index 00..cf667217cc --- /dev/null +++ b/configs/ibm-sbp1_defconfig @@ -0,0 +1,126 @@ +CONFIG_ARM=y +CONFIG_SYS_DCACHE_OFF=y +CONFIG_POSITION_INDEPENDENT=y +CONFIG_SPL_SYS_THUMB_BUILD=y +CONFIG_ARCH_ASPEED=y +CONFIG_TEXT_BASE=0x8000 +CONFIG_SYS_MALLOC_LEN=0x200 +CONFIG_SYS_MALLOC_F_LEN=0x800 +CONFIG_ASPEED_AST2600=y +CONFIG_TARGET_EVB_AST2600=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_SPL_LDSCRIPT="arch/arm/mach-aspeed/ast2600/u-boot-spl.lds" +CONFIG_ENV_SIZE=0x1 +CONFIG_ENV_OFFSET=0xe +CONFIG_ENV_SECT_SIZE=0x1 +CONFIG_DM_GPIO=y +CONFIG_DEFAULT_DEVICE_TREE="ast2600-sbp1" +CONFIG_DM_RESET=y +CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK_R_ADDR=0x8300 +CONFIG_SPL_SIZE_LIMIT=0x1 +CONFIG_SPL=y +# CONFIG_ARMV7_NONSEC is not set +CONFIG_SYS_LOAD_ADDR=0x8300 +CONFIG_SPL_PAYLOAD="u-boot.img" +CONFIG_BUILD_TARGET="u-boot-with-spl.bin" +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_FIT=y +CONFIG_SPL_FIT_SIGNATURE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_LOAD_FIT_ADDRESS=0x1 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200n8 root=/dev/ram rw earlycon" +CONFIG_USE_BOOTCOMMAND=y +CONFIG_BOOTCOMMAND="run bootspi" +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y +CONFIG_SPL_BSS_START_ADDR=0x8300 +CONFIG_SPL_BSS_MAX_SIZE=0x100 +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200 +CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_FIT_IMAGE_TINY=y +CONFIG_SPL_DM_RESET=y +CONFIG_SPL_RAM_SUPPORT=y +CONFIG_SPL_RAM_DEVICE=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_CBSIZE=256 +CONFIG_SYS_PBSIZE=276 +CONFIG_CMD_BOOTZ=y +# CONFIG_BOOTM_NETBSD is not set +# CONFIG_BOOTM_PLAN9 is not set +# CONFIG_BOOTM_RTEMS is not set +# CONFIG_BOOTM_VXWORKS is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +CONFIG_CMD_EEPROM=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=
Re: [PATCH v4 00/16] Introduce initial TI's J784S4 and AM69 support
On November 17, 2023 thus sayeth Kumar, Udit: > > On Wed, Nov 15, 2023 at 2:54 PM Maxime Ripard > > wrote: > > > On Sun, Oct 01, 2023 at 10:25:29PM +0530, Apurva Nandan wrote: > > > ... > > > > > > SoC: J784S4 SR1.0 HS-FS > > > Model: Texas Instruments J784S4 EVM > > Maybe something changed but I'm surprised about it reporting an EVM > > board. I was expecting something like > > > > Model: Texas Instruments AM69 SK > > Board: AM69-SK rev E2 > > > > Did you use the am69_sk_a72/r5 defconfigs? > > Please apply AM69 config fragment > > https://lore.kernel.org/all/20231001165545.494212-16-a-nan...@ti.com/ > > make ARCH=arm j784s4_evm_a72_defconfig am69_sk_a72.config > make ARCH=arm > > OR > > make ARCH=arm j784s4_evm_r5_defconfig am69_sk_r5.config > make ARCH=arm Just a heads up, adding the ARCH variable isn't really needed and I've heard of this causing problems for others :) ~Bryan
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On Fri, Nov 17, 2023 at 01:58:35PM +0200, Eugen Hristev wrote: > On 11/17/23 11:15, mihai.s...@microchip.com wrote: > > Hi Eugen, > > > > I built new binaries with CONFIG_SYS_THUMB_BUILD=y for sam9x60_curiosity, > > sama5d29_curiosity, sama7g5ek and new sam9x75_curiosity board. > > I used the latest u-boot/master branch for this test. > > I noticed that the file size of the binaries have beed reduced with aprox > > 150KiB due to CONFIG_SYS_THUMB_BUILD=y. > > After flashing the new binaries on these boards I can confirm that on all > > boards the linux kernel was booted properly from mmc, qspi-flash, > > nand-flash and usb. > > I tested using bootm and bootz commands. > > Thank you Mihai, > > Tom, Sean, are you okay with this going in the next merge window ? > It is definitely not a fix, so that would be the best. Thanks. I was looking at this for a series to go in to -next at this point, so v2024.04 release. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/15] nand: Add sandbox tests
On Sat, 04 Nov 2023 16:37:38 -0400, Sean Anderson wrote: > This series tests raw nand flash in sandbox and fixes various bugs discovered > in > the process. I've tried to do things in a contemporary manner, avoiding the > (numerous) variations present on only a few boards. The test is pretty > minimal. > Future work could test the rest of the nand API as well as the MTD API. > > Bloat (for v1) at [1] (for boards with SPL_NAND_SUPPORT enabled). Almost > everything grows by a few bytes due to nand_page_size. A few boards grow more, > mostly those using nand_spl_loaders.c. CI at [2]. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: > Several AT91 boards are quite close to their SPL size limit. For example, > sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't > even fit with older GCCs. > > All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This > shrinks SPL by around 30%. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v7 00/26] spl: Use common function for loading/parsing images
On Wed, 08 Nov 2023 11:48:32 -0500, Sean Anderson wrote: > This series adds support for loading all image types (Legacy (with and without > LZMA), FIT (with and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR, > NET, FAT, EXT, NVMe, and semihosting load methods. It does this by > introducing a > helper function which handles the minutiae of invoking the proper parsing > function, and reading the rest of the image. > > Hopefully, this will make it easier for load methods to support all image > types > that U-Boot supports, without having undocumented unsupported image types. I > applied this to several loaders which were invoking spl_load_simple_fit and/or > spl_parse_image_header, but I did not use it with others (e.g. DFU/RAM) which > had complications in the mix. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH] fs/squashfs: remove unused declarations
On Mon, Nov 06, 2023 at 11:03:20AM +0100, David Oberhollenzer wrote: > This patch removes a number of struct and macro declaration that > were found through `git-grep` to be unused. Most of those are > related to compressor options and super block flags. > > For reading a SquashFS image, we do not need the compressor options > or the flags. Those only encode settings used for packing the image, > mksquashfs uses them when appending data to an existing image. The > kernel implementation does not touch those, and we don't need them > either. > > Signed-off-by: David Oberhollenzer Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: enable LZ4 compression support
On Mon, Nov 06, 2023 at 11:14:03AM +0100, David Oberhollenzer wrote: > The structure is identical to the existing compressor implementations, > trivially adding lz4 decompression to sqfs_decompress. > > The changes were tested using a sandbox build. An LZ4 compressed > squashfs image was bound as a host block device. > > Signed-off-by: David Oberhollenzer > Reviewed-by: Joao Marcos Costa Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: cssi: Remove usage of common.h
On Mon, Nov 06, 2023 at 07:12:05PM +0100, Christophe Leroy wrote: > Remove inclusion of common.h and add relevant > includes when necessary. > > Signed-off-by: Christophe Leroy Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] powerpc: mpc8xx: Remove usage of common.h
On Mon, Nov 06, 2023 at 07:12:04PM +0100, Christophe Leroy wrote: > Remove inclusion of common.h and add relevant > includes when necessary. > > Signed-off-by: Christophe Leroy Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootm: Enable legacy VxWorks booting from FITs
On Fri, Oct 27, 2023 at 04:07:40PM -0400, Sean Anderson wrote: > This works without issue, so don't fail. > > Signed-off-by: Sean Anderson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] test: eth: Don't crash if env_get returns NULL
On Sat, Oct 28, 2023 at 06:57:27PM -0400, Sean Anderson wrote: > env_get can return NULL if it fails to find the variable. Check its result > before using it. > > Fixes: 6d9764c2a87 ("dm: test: Add a new test case against dm eth codes for > NULL pointer access") > Fixes: df33fd28897 ("test: eth: Add test for ethernet addresses") > Signed-off-by: Sean Anderson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] sysreset: Fix unsupported request return values
On Wed, Nov 08, 2023 at 08:51:10AM +, Paul Barker wrote: > The description of the sysreset request method in says that > the return value should be -EPROTONOSUPPORT if the requested reset type > is not supported by this device. > > Signed-off-by: Paul Barker > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: ext4: Remove unused parameter from ext4_mount
On Wed, Nov 08, 2023 at 12:51:09PM -0500, Sean Anderson wrote: > The part_length parameter is not used. Remove it. > > Signed-off-by: Sean Anderson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: btrfs: fix reading when length specified
On Sat, Nov 11, 2023 at 08:19:04AM -0700, Sam Edwards wrote: > The btrfs read function limits the read length to ensure that it > and the read offset do not together exceed the size of the file. > However, this size was only being queried if the read length was > passed a value of zero (meaning "whole file"), and the size is > defaulted to 0 otherwise. This means the clamp will just zero out > the length if one is specified, preventing reading of the file. > > Fix this by checking the file size unconditionally, and unifying > the default length and clamping logic as a single range check instead. > > This bug was discovered when trying to boot Linux with initrd= via > 'bootefi' from a btrfs partition. The EFI stub entered an infinite > loop of zero-length reads while trying to read the initrd, and the > boot process stalled indefinitely. > > Signed-off-by: Sam Edwards > Reviewed-by: Qu Wenruo Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/2] blk: Drop reference to DM_SPL
On Sun, Nov 12, 2023 at 01:03:47PM -0700, Simon Glass wrote: > The intent here is to only allow SPL_LEGACY_BLK if !SPL_DM - i.e. that > when driver model is enabled in SPL, legacy block cannot be used. > > However this combination is used by about 240 boards, so we cannot > disallow it, at least not yet. > > So just drop the condition. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/2] dm: core: Correct reference to DM_SPL in SPL_DM_STATS
On Sun, Nov 12, 2023 at 01:03:46PM -0700, Simon Glass wrote: > This does not existing anymore. Update SPL_DM_STATS to use the correct > Kconfig option, which is SPL_DM > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] spi: meson_spifc_a1: Use define for time interval
On Thu, Nov 09, 2023 at 08:10:03PM +0300, Igor Prusov wrote: > Use USEC_PER_MSEC define for timeout to sync code with Linux version. > > Signed-off-by: Igor Prusov Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] linux/time.h: Add Linux time conversion defines
On Thu, Nov 09, 2023 at 08:10:02PM +0300, Igor Prusov wrote: > Currently there are no defines for time conversion in time.h, which > leads to drivers declaring those locally or not using defines at all, so > add them from Linux. > > Signed-off-by: Igor Prusov > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/2] poplar: use random mac address
On Thu, Nov 09, 2023 at 11:34:34PM +0100, Igor Opaniuk wrote: > Set CONFIG_NET_RANDOM_ETHADDR=y, which sets random eth address in > case there is no configuration provided neither in CONFIG_ETHADDR > nor in "ethaddr" env variable. > > This fixes the problem: > poplar# dhcp > Error: ethernet@9841000 address not set. > > Signed-off-by: Igor Opaniuk > Reviewed-by: Sam Protsenko Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/2] poplar: provide more space for kernel image
On Thu, Nov 09, 2023 at 11:34:35PM +0100, Igor Opaniuk wrote: > Adjust mem layout, providing more space for linux kernel image. > > This fixes the problem: > ERROR: FDT image overlaps OS image (OS=0x3000..0x3258) > > Signed-off-by: Igor Opaniuk > Reviewed-by: Sam Protsenko Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] cmd: bcb: support various block device interfaces for BCB command
On Fri, Nov 10, 2023 at 05:59:54AM +, Dmitrii Merkurev wrote: > Currently BCB command-line, C APIs and implementation only > support MMC interface. Extend it to allow various block > device interfaces. > > Signed-off-by: Dmitrii Merkurev > Cc: Eugeniu Rosca > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Cc: Mattijs Korpershoek > Cc: Sean Anderson > Cc: Cody Schuffelen > Tested-by: Mattijs Korpershoek # on vim3 > Reviewed-by: Mattijs Korpershoek Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] cmd: bcb: extend BCB C API to allow read/write the fields
On Fri, Nov 10, 2023 at 05:59:55AM +, Dmitrii Merkurev wrote: > Currently BCB C API only allows to modify 'command' BCB field. > Extend it so that we can also read and modify all the available > BCB fields (command, status, recovery, stage). > > Co-developed-by: Cody Schuffelen > Signed-off-by: Cody Schuffelen > Signed-off-by: Dmitrii Merkurev > Cc: Eugeniu Rosca > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Cc: Mattijs Korpershoek > Cc: Sean Anderson > Cc: Cody Schuffelen > Tested-by: Mattijs Korpershoek # on vim3 > Reviewed-by: Mattijs Korpershoek Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On 11/17/23 15:40, Tom Rini wrote: On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: Several AT91 boards are quite close to their SPL size limit. For example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't even fit with older GCCs. All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This shrinks SPL by around 30%. [...] Applied to u-boot/next, thanks! so I'd assume that it would go through at91 tree.
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On Fri, Nov 17, 2023 at 03:45:02PM +0200, Eugen Hristev wrote: > On 11/17/23 15:40, Tom Rini wrote: > > On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: > > > > > Several AT91 boards are quite close to their SPL size limit. For example, > > > sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't > > > even fit with older GCCs. > > > > > > All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. > > > This > > > shrinks SPL by around 30%. > > > > > > [...] > > > > Applied to u-boot/next, thanks! > > > > so I'd assume that it would go through at91 tree. Ah, sorry. Since it was blocking two other series from coming in and you had gotten it tested I had assumed I could pull it to -next now to unblock that work. -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On 11/17/23 15:46, Tom Rini wrote: On Fri, Nov 17, 2023 at 03:45:02PM +0200, Eugen Hristev wrote: On 11/17/23 15:40, Tom Rini wrote: On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: Several AT91 boards are quite close to their SPL size limit. For example, sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and doesn't even fit with older GCCs. All AT91 processors should have thumb support. Enable SYS_THUMB_BUILD. This shrinks SPL by around 30%. [...] Applied to u-boot/next, thanks! so I'd assume that it would go through at91 tree. Ah, sorry. Since it was blocking two other series from coming in and you had gotten it tested I had assumed I could pull it to -next now to unblock that work. This is yet another time at91 patches get applied directly. Maybe you do not really need an at91 maintainer ?
Re: [PATCH 3/3] treewide: use linux/time.h for time conversion defines
On Thu, Nov 09, 2023 at 08:10:04PM +0300, Igor Prusov wrote: > Now that we have time conversion defines from in time.h there is no need > for each driver to define their own version. > > Signed-off-by: Igor Prusov > Reviewed-by: Svyatoslav Ryhel # tegra > Reviewed-by: Eugen Hristev #at91 > Reviewed-by: Caleb Connolly #qcom geni > Reviewed-by: Stefan Bosch #nanopi2 > Reviewed-by: Patrice Chotard Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Enable SYS_THUMB_BUILD on AT91
On Fri, Nov 17, 2023 at 03:49:57PM +0200, Eugen Hristev wrote: > On 11/17/23 15:46, Tom Rini wrote: > > On Fri, Nov 17, 2023 at 03:45:02PM +0200, Eugen Hristev wrote: > > > On 11/17/23 15:40, Tom Rini wrote: > > > > On Sat, 04 Nov 2023 22:27:42 -0400, Sean Anderson wrote: > > > > > > > > > Several AT91 boards are quite close to their SPL size limit. For > > > > > example, > > > > > sama5d27_wlsom1_ek_mmc is just 173 bytes short of its limit and > > > > > doesn't > > > > > even fit with older GCCs. > > > > > > > > > > All AT91 processors should have thumb support. Enable > > > > > SYS_THUMB_BUILD. This > > > > > shrinks SPL by around 30%. > > > > > > > > > > [...] > > > > > > > > Applied to u-boot/next, thanks! > > > > > > > > > > so I'd assume that it would go through at91 tree. > > > > Ah, sorry. Since it was blocking two other series from coming in and you > > had gotten it tested I had assumed I could pull it to -next now to > > unblock that work. > > This is yet another time at91 patches get applied directly. Maybe you do not > really need an at91 maintainer ? U-Boot does not tend to have the strict sub-tree breakdown that the kernel does. Given what happened last time I was hoping that reaching out and then that you were able to have the changes tested would be sufficient for changes going to -next, rather than the current release. In future I will just wait for changes to come via the at91 tree, like I do for some other areas where the overall custodian prefers to have a more strict policy. Sorry. -- Tom signature.asc Description: PGP signature
Re: [PATCH RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200
On Fri, Nov 17, 2023 at 02:00:43PM +0530, Neha Malcom Francis wrote: > Hi Tom > > On 17/11/23 00:10, Tom Rini wrote: > > On Thu, Nov 16, 2023 at 11:43:50AM +0530, Neha Malcom Francis wrote: > > > Hi Tom, > > > > > > Trying to bring back this series here. > > > > > > On 03/10/23 20:40, Tom Rini wrote: > > > > On Tue, Oct 03, 2023 at 07:57:04PM +0530, Kumar, Udit wrote: > > > > > > > > > > On 10/3/2023 1:40 PM, Keerthy wrote: > > > > > > Enable ESM initialization for J7200 > > > > > > > > > > > > Signed-off-by: Keerthy > > > > > > --- > > > > > > board/ti/j721e/evm.c | 6 -- > > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c > > > > > > index 42fa94b7a5..070b28326f 100644 > > > > > > --- a/board/ti/j721e/evm.c > > > > > > +++ b/board/ti/j721e/evm.c > > > > > > @@ -543,7 +543,8 @@ void spl_board_init(void) > > > > > > } > > > > > > #ifdef CONFIG_ESM_K3 > > > > > > - if (board_ti_k3_is("J721EX-PM2-SOM")) { > > > > > > + if ((board_ti_k3_is("J721EX-PM2-SOM")) || > > > > > > + IS_ENABLED(CONFIG_TARGET_J7200_R5_EVM)) { > > > > > > > > > > > > > > > Could we align on one kind of check, For J721E check is done against > > > > > board-id, whereas for J7200 checking > > > > > > > > We should look at figuring out how to split this file in two. One for > > > > "generic J721E systems" and one for "TI EVMs", as I've mentioned in > > > > other threads, so that it's easier for custom platforms to drop code > > > > they don' require. > > > > > > > > > > Yes that does make sense. Would it be okay if we solve that problem > > > separately in a different patch series? We can move along with this > > > current > > > series for now (after making the required change in CONFIG/board-id for > > > v2) > > > since ESM support is important for these platforms. > > > > Well, I think part of the answer to your question is (and this is a more > > general TI one too), what outstanding changes need to come in now to > > make existing platforms functional for v2024.01 ? My first thought is > > that this series would be taken to -next, if I took it now, which means > > there's time before it would be in master, and so if it really makes the > > re-org later easier, we could take it, but if not, can we re-org then do > > this? But if we need this to deal with regressions, OK, yes, we can take > > it like this now. > > > > Maybe focusing on the re-org after having in the changes would help give > more perspective on how we can split? Not sure just a thought... in that > case I prefer taking this in and having a working error signaling module in > rather than delaying it if that's okay. OK, please rebase on top of whatever other series are needed (and note so in the cover letter) and mark it as non-RFC, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
On Fri, Nov 17, 2023 at 09:17:27AM +0100, Stefano Babic wrote: > Hi Tom, Marcel, > > On 16.11.23 19:42, Tom Rini wrote: > > On Thu, Nov 16, 2023 at 10:57:27AM +, Marcel Ziswiler wrote: > > > Hi Tom > > > > > > On Thu, 2023-11-02 at 08:09 +0100, Marcel Ziswiler wrote: > > > > Hi Stefano > > > > > > > > On Thu, 2023-10-26 at 10:36 +0200, Stefano Babic wrote: > > > > > On 26.10.23 10:29, Rasmus Villemoes wrote: > > > > > > On 26/10/2023 09.32, Marcel Ziswiler wrote: > > > > > > > From: Marcel Ziswiler > > > > > > > > > > > > > > This fixes a regression in the eMMC fast boot mode case where the > > > > > > > buffer > > > > > > > was missing 464 bytes. > > > > > > > > > > > > > > The code figures out how many bytes must at least be fetched to > > > > > > > honor > > > > > > > the current read, rounds that up to the ss->pagesize [which is a > > > > > > > no-op > > > > > > > in the USB download case because that has ->pagesize==1], fetches > > > > > > > that > > > > > > > many bytes, but then recorded the original upper bound as the new > > > > > > > end of > > > > > > > the valid data. However, this did not take into account the > > > > > > > rounding up > > > > > > > to the ss->pagesize. Fix this by recording the actual bytes > > > > > > > downloaded. > > > > > > > > > > > > > > Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of > > > > > > > spl_load_simple_fit() to get full FIT > > > > > > > size") > > > > > > > Signed-off-by: Marcel Ziswiler > > > > > > > > > > > > > > > > > > > Thanks for reporting and fixing this, and sorry for the trouble. > > > > > > > > > > > > Acked-by: Rasmus Villemoes > > > > > > > > > > > > > > > > And thanks for all your work - I will apply this fix soon. > > > > > > > > Any news on applying this fix? Note that master still stays broken as > > > > of today. > > > > > > And two weeks later still broken! > > > > I've put this in my not to forget queue for the next -rc. > > > > > Anyway, I feel i.MX maintainership seems rather stalled at times most of > > > the time. I don't want to criticise > > > anybody knowing how busy our trade can get. However, if it helps the > > > cause Toradex would be ready to step up. > > > Let me know what you think. Thanks! > > > > I would be happy to see an additional custodian for the imx tree, if > > that's agreeable with Stefano. > > I have rather less time for U-Boot and it won't be better in the near > future. Fabio is co-maintainer and he has accepted to take over the > repository and go on maintaining u-boot-imx. Just let him some time to be > confident with patchwork and CI. OK. Fabio, please send me your patchwork username off-list and I'll get you added and you can start managing patches there. I've started using some of the b4 + patchwork integration just recently and it's very nice. -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file
Hello Andrew, All, Le 03/11/2023 à 20:20, Andrew Davis a écrit : > On 11/3/23 2:06 PM, Nishanth Menon wrote: >> On 13:51-20231103, Andrew Davis wrote: >>> On 11/2/23 7:38 PM, Nishanth Menon wrote: Add defconfig fragments for J721E based BeagleBone AI-64 and corresponding customized environment. Signed-off-by: Nishanth Menon --- board/ti/j721e/beagleboneai64.env | 19 board/ti/j721e/beagleboneai64_a72.config | 55 board/ti/j721e/beagleboneai64_r5.config | 19 >>> >>> Beagle boards are not TI boards, add the board support to board/beagle/ >> >> Huh, why bring in commercials and organization changes here? am335x >> and am62 are under the TI umbrella. >> > > The SoCs used are yes, the boards are not, we only make our EVM/SK > line of boards in house. > > We did AM335x wrong, in board/ti/am335x/board.c we tried to support > like 11 different boards in one file. And while it might have made adding > our own extra EVMs easier, it only made things less clear for folks trying > to add their own AM335x based boards[0]. > > We don't integrate support for any other board partner like this. Our > friends over at Toradex or Phytec are currently upstreaming boards based > on K3 SoCs and in doing so have shown us some areas we can improve. > > We focus on these little short-cuts to make adding our EVMs (or boards > that look like our EVMs) easy. But that only leads to extra work and > code duplication for external boards. > > If something is actually common to the SoC then lets move it to > arch/arm/mach-k3/j721e. Tricks like board-variants.c only hide the > issue and doesn't help folks wanting to add their boards based on our > SoCs to their board// directory. I'm starting a new custom board bring-up based on a j721e SoC (without any SOM) and adding a now board variant from the u-boot provided in the TI SDK (based on 2023.04) is far from easy for the reasons mentioned above (extra work and code duplication for external boards). Also the build break for j7200/j721e SoC as soon as CONFIG_TARGET_J721E_A72_EVM and CONFIG_TARGET_J7200_A72_EVM are undefined: https://source.denx.de/u-boot/u-boot/-/blob/v2023.10/arch/arm/mach-k3/arm64-mmu.c?ref_type=tags#L71 I always wonder if I should work on top of EVMs board or create a new board// directory for customer boards. Best regards, Romain > > Andrew > > [0] See "Software Design" https://jaycarlson.net/embedded-linux/#am335x > >> $ git grep beagle board/|cut -d ':' -f1|sort -u >> board/ti/am335x/board.c >> board/ti/am335x/board.h >> board/ti/am57xx/board.c >> board/ti/am62x/beagleplay_a53.config >> board/ti/am62x/beagleplay_r5.config >> board/ti/am62x/MAINTAINERS >> board/ti/beagle/beagle.c >> board/ti/beagle/Kconfig >> board/ti/beagle/led.c >> board/ti/beagle/MAINTAINERS >> board/ti/beagle/Makefile >> board/ti/j721e/beagleboneai64_a72.config >> board/ti/j721e/beagleboneai64_r5.config >> board/ti/j721e/MAINTAINERS >> board/timll/devkit8000/README >>
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > A new variant of the i.MX8MP System-on-module from Beacon is > available which contains 4GB of RAM vs 6GB. The memory > timings are slightly different, so a different config is necessary > to build the different timing file. > > Signed-off-by: Adam Ford Might this be a case for using config fragments instead? See doc/develop/board_best_practices.rst -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Fri, Nov 17, 2023 at 8:41 AM Tom Rini wrote: > > On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > > > A new variant of the i.MX8MP System-on-module from Beacon is > > available which contains 4GB of RAM vs 6GB. The memory > > timings are slightly different, so a different config is necessary > > to build the different timing file. > > > > Signed-off-by: Adam Ford > > Might this be a case for using config fragments instead? I didn't realize U-Boot was supporting that. I'll submit a V2 with the defconfig option removed. Is there an example you can direct me to that does this already? thanks! adam > See doc/develop/board_best_practices.rst > > -- > Tom
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Fri, Nov 17, 2023 at 08:48:00AM -0600, Adam Ford wrote: > On Fri, Nov 17, 2023 at 8:41 AM Tom Rini wrote: > > > > On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > > > > > A new variant of the i.MX8MP System-on-module from Beacon is > > > available which contains 4GB of RAM vs 6GB. The memory > > > timings are slightly different, so a different config is necessary > > > to build the different timing file. > > > > > > Signed-off-by: Adam Ford > > > > Might this be a case for using config fragments instead? > > I didn't realize U-Boot was supporting that. I'll submit a V2 with > the defconfig option removed. Is there an example you can direct me > to that does this already? The beagleplay boards are currently handled via config fragments as well as a few asus platforms (grouper, transformer-t30). I just now noticed the latter places the fragments in a configs subdirectory which is nice I think when there's going to be a number of fragments, but not required. > > thanks! > > adam > > See doc/develop/board_best_practices.rst > > > > -- > > Tom -- Tom signature.asc Description: PGP signature
[PATCH] tqma6: Fix DDR configuration
Initially investigating a Linux network issue causing a lot of drop and poor network performances on a custom system based on a TQMA6A module (based on an iMX6Q), [1st link below]. I eventually correlated my observations with a contention at the NIC level when in concurrency with the graphics pipeline. Troubleshooting this in the kernel lead to disabling DMA bursts accesses made by the IPU in order to avoid triggering the QoS at the interconnect level, reducing from 50 to 10% the drop rate on eth0, [2nd link below]. The solution worked on my setup but not on others, which still suffered from abnormally high drop rates even with this "fix". After looking a while into TQ Systems BSP I figured out a number of differences in recent U-Boot out-of-tree patches they had in their repository [3rd link]. Parsing the differences one after the other lead me to this final solution. The reset pad of the DDR controller was apparently misconfigured, Bit 18-19 picturing the "DDR select field". The current value b11 is reserved. The only defined value as of version 6 of the iMX6Q manual was b00 "DDR3 and LPDDR2 mode". In practice no register difference has been spotted after changing this configuration but all issues tracked thus far just vanished. All previous fixes have been proven irrelevant. Just clearing this field solved all our network issues and the drop rate as measured by iperf3 felt back to 0%. Link: https://lore.kernel.org/netdev/20231012193410.3d1812cf@xps-13/ Link: https://lists.freedesktop.org/archives/dri-devel/2023-October/428251.html Link: https://github.com/tq-systems/u-boot-tqmaxx/commit/15eb6abbefbf6916c28467b85485911dad3da6bc Signed-off-by: Miquel Raynal --- board/tq/tqma6/tqma6q.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/tq/tqma6/tqma6q.cfg b/board/tq/tqma6/tqma6q.cfg index a49489aed3f..a345c4de93d 100644 --- a/board/tq/tqma6/tqma6q.cfg +++ b/board/tq/tqma6/tqma6q.cfg @@ -36,7 +36,7 @@ DATA 4, MX6_IOM_DRAM_SDCLK_1, 0x8030 DATA 4, MX6_IOM_DRAM_CAS, 0x8030 DATA 4, MX6_IOM_DRAM_RAS, 0x8030 DATA 4, MX6_IOM_GRP_ADDDS, 0x0030 -DATA 4, MX6_IOM_DRAM_RESET, 0x000C3030 +DATA 4, MX6_IOM_DRAM_RESET, 0x3030 DATA 4, MX6_IOM_DRAM_SDCKE0, 0x3000 DATA 4, MX6_IOM_DRAM_SDCKE1, 0x DATA 4, MX6_IOM_DRAM_SDBA2, 0x -- 2.34.1
Re: bootstd: Support for distro specific EFI folders
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. Best regards Heinrich
Re: [PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU
On 8/17/23 19:41, Tom Rini wrote: The implementation of this option in lib/fwu_updates/fwu_gpt.c is wholly dependent on DFU, so make that a requirement here. Signed-off-by: Tom Rini --- I'm honestly not sure how to best proceed here as drivers/fwu-mdata/gpt_blk.c doesn't need DFU, but both files are controlled by this single symbol. Cc: Masami Hiramatsu Cc: Jassi Brar Cc: Sughosh Ganu Cc: Ilias Apalodimas Cc: Heinrich Schuchardt --- drivers/fwu-mdata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig index 42736a5e43b0..0bd5fef4abfa 100644 --- a/drivers/fwu-mdata/Kconfig +++ b/drivers/fwu-mdata/Kconfig @@ -15,7 +15,7 @@ config FWU_MDATA_GPT_BLK bool "FWU Metadata access for GPT partitioned Block devices" select PARTITION_TYPE_GUID select PARTITION_UUIDS - depends on FWU_MDATA && BLK && EFI_PARTITION + depends on FWU_MDATA && BLK && EFI_PARTITION && DFU Hello Tom, This looks like the wrong level of configuration to add a DFU dependency. EFI_CAPSULE_FIRMWARE_FIT and EFI_CAPSULE_FIRMWARE_RAW select DFU and EFI_CAPSULE_FIRMWARE. We probably should let CONFIG_FWU_MDATA depend on EFI_CAPSULE_ON_DISK. Best regards Heinrich help Enable support for accessing FWU Metadata on GPT partitioned block devices.
Re: [PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU
On Fri, Nov 17, 2023 at 04:35:22PM +0100, Heinrich Schuchardt wrote: > On 8/17/23 19:41, Tom Rini wrote: > > The implementation of this option in lib/fwu_updates/fwu_gpt.c is wholly > > dependent on DFU, so make that a requirement here. > > > > Signed-off-by: Tom Rini > > --- > > I'm honestly not sure how to best proceed here as > > drivers/fwu-mdata/gpt_blk.c doesn't need DFU, but both files are > > controlled by this single symbol. > > > > Cc: Masami Hiramatsu > > Cc: Jassi Brar > > Cc: Sughosh Ganu > > Cc: Ilias Apalodimas > > Cc: Heinrich Schuchardt > > --- > > drivers/fwu-mdata/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig > > index 42736a5e43b0..0bd5fef4abfa 100644 > > --- a/drivers/fwu-mdata/Kconfig > > +++ b/drivers/fwu-mdata/Kconfig > > @@ -15,7 +15,7 @@ config FWU_MDATA_GPT_BLK > > bool "FWU Metadata access for GPT partitioned Block devices" > > select PARTITION_TYPE_GUID > > select PARTITION_UUIDS > > - depends on FWU_MDATA && BLK && EFI_PARTITION > > + depends on FWU_MDATA && BLK && EFI_PARTITION && DFU > > Hello Tom, > > This looks like the wrong level of configuration to add a DFU dependency. > > EFI_CAPSULE_FIRMWARE_FIT and EFI_CAPSULE_FIRMWARE_RAW select DFU and > EFI_CAPSULE_FIRMWARE. > > We probably should let CONFIG_FWU_MDATA depend on EFI_CAPSULE_ON_DISK. OK, but that doesn't address the dependency? The code in lib/fwu_updates/fwu_gpt.c needs DFU and is under FWU_MDATA_GPT_BLK. It provides fwu_plat_get_alt_num() which is called by fwu_get_image_index() and is under FWU_MULTI_BANK_UPDATE and in turn called by efi_firmware_raw_set_image() which is under EFI_CAPSULE_FIRMWARE_RAW. If both lib/fwu_updates/fwu_gpt.c and drivers/fwu-mdata/gpt_blk.c should be under the same symbol then it needs to depend on DFU, since it's a direct dependency in the code. We could change it up to EFI_CAPSULE_FIRMWARE_RAW I guess, but I'm not sure that's cleaner. -- Tom signature.asc Description: PGP signature
[PATCH] boards: Disable NET on platforms without NETDEVICES
None of these platforms enabled a networking devices, and disabled CMD_NET. Given that we used to gate network support on CMD_NET rather than NET, we disable CONFIG_NET on these platforms now. Signed-off-by: Tom Rini --- Cc: Simon Glass Cc: Heinrich Schuchardt Cc: Matthias Winker Cc: Philip Oberfichtner Cc: Minkyu Kang Cc: Jaehoon Chung Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Sergey Temerkhanov --- configs/efi-x86_app32_defconfig | 3 +-- configs/efi-x86_app64_defconfig | 3 +-- configs/imx6q_bosch_acc_defconfig | 3 +-- configs/origen_defconfig| 2 +- configs/s5pc210_universal_defconfig | 2 +- configs/stm32mp25_defconfig | 2 +- configs/thunderx_88xx_defconfig | 2 +- configs/trats2_defconfig| 2 +- configs/trats_defconfig | 2 +- 9 files changed, 9 insertions(+), 12 deletions(-) diff --git a/configs/efi-x86_app32_defconfig b/configs/efi-x86_app32_defconfig index 682ba5b89576..e2e6f42c9a9d 100644 --- a/configs/efi-x86_app32_defconfig +++ b/configs/efi-x86_app32_defconfig @@ -21,7 +21,6 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_BOOTZ=y CONFIG_CMD_PART=y # CONFIG_CMD_SCSI is not set -# CONFIG_CMD_NET is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y CONFIG_CMD_EXT4=y @@ -36,7 +35,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="bzImage" -CONFIG_USE_ROOTPATH=y +# CONFIG_NET is not set CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_REGEX is not set diff --git a/configs/efi-x86_app64_defconfig b/configs/efi-x86_app64_defconfig index d6b6c3d82995..14b5cd0fa0ee 100644 --- a/configs/efi-x86_app64_defconfig +++ b/configs/efi-x86_app64_defconfig @@ -22,7 +22,6 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_BOOTZ=y CONFIG_CMD_PART=y # CONFIG_CMD_SCSI is not set -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_EXT2=y @@ -38,7 +37,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="bzImage" -CONFIG_USE_ROOTPATH=y +# CONFIG_NET is not set CONFIG_REGMAP=y CONFIG_SYSCON=y CONFIG_CONSOLE_SCROLL_LINES=5 diff --git a/configs/imx6q_bosch_acc_defconfig b/configs/imx6q_bosch_acc_defconfig index 05bab034e0f9..6abb7954ba2d 100644 --- a/configs/imx6q_bosch_acc_defconfig +++ b/configs/imx6q_bosch_acc_defconfig @@ -63,7 +63,6 @@ CONFIG_CMD_PART=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SOURCE is not set # CONFIG_CMD_SETEXPR is not set -# CONFIG_CMD_NET is not set # CONFIG_CMD_BLOCK_CACHE is not set # CONFIG_CMD_SLEEP is not set # CONFIG_CMD_MP is not set @@ -82,7 +81,7 @@ CONFIG_SYS_MMC_ENV_PART=1 CONFIG_ENV_WRITEABLE_LIST=y CONFIG_ENV_ACCESS_IGNORE_FORCE=y CONFIG_VERSION_VARIABLE=y -CONFIG_TFTP_BLOCKSIZE=512 +# CONFIG_NET is not set CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_DM_BOOTCOUNT=y diff --git a/configs/origen_defconfig b/configs/origen_defconfig index 3a71d6e582a7..5e55b712df9e 100644 --- a/configs/origen_defconfig +++ b/configs/origen_defconfig @@ -35,13 +35,13 @@ CONFIG_CMD_DFU=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y # CONFIG_CMD_SLEEP is not set CONFIG_CMD_EXT4_WRITE=y CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DFU_MMC=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x200 CONFIG_MMC_DW=y diff --git a/configs/s5pc210_universal_defconfig b/configs/s5pc210_universal_defconfig index f585c510635a..ac236c82a1fc 100644 --- a/configs/s5pc210_universal_defconfig +++ b/configs/s5pc210_universal_defconfig @@ -33,7 +33,6 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y # CONFIG_CMD_SLEEP is not set CONFIG_CMD_EXT4_WRITE=y @@ -42,6 +41,7 @@ CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +# CONFIG_NET is not set CONFIG_DFU_MMC=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x200 CONFIG_SYS_I2C_S3C24X0=y diff --git a/configs/stm32mp25_defconfig b/configs/stm32mp25_defconfig index 8423943f091c..75f27c98b441 100644 --- a/configs/stm32mp25_defconfig +++ b/configs/stm32mp25_defconfig @@ -23,7 +23,6 @@ CONFIG_CMD_MEMTEST=y CONFIG_CMD_CLK=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADB is not set -# CONFIG_CMD_NET is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_RNG=y @@ -31,6 +30,7 @@ CONFIG_CMD_TIMER=y CONFIG_CMD_REGULATOR=y CONFIG_CMD_LOG=y CONFIG_OF_LIVE=y +# CONFIG_NET is not set CONFIG_GPIO_HOG=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_STM32F7=y diff --git a/configs/thunderx_88xx_defconfig b/configs/thunderx_88xx_defconfig index 5c24b38bb1fa..0c71b298ada5 100644 --- a/configs/thunderx_88xx_defconfig +++ b/configs/thunderx_88xx_defconfig @@ -32,8 +32,8 @@ CONFIG_SYS_BOOTM_LEN=0x80 # CONFIG_CMD_EDITENV is not set # CONFIG_CMD_SAVEENV is not set # CONFIG_CMD_ENV_EXISTS is not set -# CONFIG_CMD_NET is not set CONFIG_SYS_RELOC_GD_EN
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
Hi Tom, On Fri, Nov 17, 2023 at 11:25 AM Tom Rini wrote: > OK. Fabio, please send me your patchwork username off-list and I'll get > you added and you can start managing patches there. I've started using > some of the b4 + patchwork integration just recently and it's very nice. In the meantime, could you pleas directly apply this series from Marcel? Thanks
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
On Fri, Nov 17, 2023 at 01:13:07PM -0300, Fabio Estevam wrote: > Hi Tom, > > On Fri, Nov 17, 2023 at 11:25 AM Tom Rini wrote: > > > OK. Fabio, please send me your patchwork username off-list and I'll get > > you added and you can start managing patches there. I've started using > > some of the b4 + patchwork integration just recently and it's very nice. > > In the meantime, could you pleas directly apply this series from Marcel? I've put it in my list for before the next -rc. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On lis 14, 2023 15:06, Quentin Schulz wrote: > Hi Jonas, Hi Quentin > On 11/12/23 11:26, Jonas Karlman wrote: > > The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI > > NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6. > > > > At the time the reason for this new bootsource id value 6 was unknown. > > > > We now know that the BootRom on RK3588 use different bootsource id > > values depending on the iomux used by the flash spi controller, and not > > by the type of spi nor or spi nand flash used. > > > > Add the following defines and use them for RK3588 boot_devices. > > > > - BROM_BOOTSOURCE_FSPI_M0 = 3 > > - BROM_BOOTSOURCE_FSPI_M1 = 4 > > - BROM_BOOTSOURCE_FSPI_M2 = 6 > > > > Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR > > flash") > > Signed-off-by: Jonas Karlman > > --- > > arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++- > > arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++-- > > 2 files changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h > > b/arch/arm/include/asm/arch-rockchip/bootrom.h > > index 7dab18fbc3fb..f78337397d63 100644 > > --- a/arch/arm/include/asm/arch-rockchip/bootrom.h > > +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h > > @@ -47,8 +47,10 @@ enum { > > BROM_BOOTSOURCE_EMMC = 2, > > BROM_BOOTSOURCE_SPINOR = 3, > > BROM_BOOTSOURCE_SPINAND = 4, > > + BROM_BOOTSOURCE_FSPI_M0 = 3, > > + BROM_BOOTSOURCE_FSPI_M1 = 4, > > I'm a bit wary of two pairs of enums sharing the same value, especially when > we want to use them as offset in a static definition of an array. > > Should we #ifdef it (meh) for RK3588? > Should we add a suffix like before for identifying RK3588-specific options? > > At the very least explicit that those are RK3588-specific in a comment for > both conflicts (the ones that apply to everything except RK3588 to say to > use only for !RK3588, and the ones that apply to RK3588 only)? Can you say why it is so important to know that given enum is specific to given CPU here in the header file? I think that the enums in the bootrom.h should be as generic as possible. By using the possible enums in a static array, "solves" the problem of assigning the boot source to specific CPU. There is not need to make such grouping in the bootrom.h. -- Slawomir Stepien
[PATCH 1/2] board: st: common: Fix board_get_alt_info_mtd()
Since MTD devices are partioned, we got the following error when command "dfu 0" is executed: DFU alt info setting: done ERROR: Too many arguments for nor0 ERROR: DFU entities configuration failed! ERROR: (partition table does not match dfu_alt_info?) Fixes: 31325e1b8b9c ("stm32mp1: dynamically build DFU_ALT_INFO") Signed-off-by: Patrice Chotard --- board/st/common/stm32mp_dfu.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c index a8eb8d5cae2..ded3bf81961 100644 --- a/board/st/common/stm32mp_dfu.c +++ b/board/st/common/stm32mp_dfu.c @@ -73,7 +73,6 @@ static void board_get_alt_info_mmc(struct udevice *dev, char *buf) static void board_get_alt_info_mtd(struct mtd_info *mtd, char *buf) { struct mtd_info *part; - bool first = true; const char *name; int len, partnum = 0; @@ -86,17 +85,13 @@ static void board_get_alt_info_mtd(struct mtd_info *mtd, char *buf) "mtd %s=", name); len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, - "%s raw 0x0 0x%llx ", + "%s raw 0x0 0x%llx", name, mtd->size); list_for_each_entry(part, &mtd->partitions, node) { partnum++; - if (!first) - len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, ";"); - first = false; - len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, - "%s_%s part %d", + ";%s_%s part %d", name, part->name, partnum); } } -- 2.25.1
[PATCH 2/2] board: st: common: simplify MTD device parsing
Simplify the way all MTD devices are parsed. Signed-off-by: Patrice Chotard --- board/st/common/stm32mp_dfu.c | 19 ++- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c index ded3bf81961..77edb86e78c 100644 --- a/board/st/common/stm32mp_dfu.c +++ b/board/st/common/stm32mp_dfu.c @@ -123,24 +123,9 @@ void set_dfu_alt_info(char *interface, char *devstr) /* probe all MTD devices */ mtd_probe_devices(); - /* probe SPI flash device on a bus */ - if (!uclass_get_device(UCLASS_SPI_FLASH, 0, &dev)) { - mtd = get_mtd_device_nm("nor0"); - if (!IS_ERR_OR_NULL(mtd)) + mtd_for_each_device(mtd) + if (!mtd_is_partition(mtd)) board_get_alt_info_mtd(mtd, buf); - - mtd = get_mtd_device_nm("nor1"); - if (!IS_ERR_OR_NULL(mtd)) - board_get_alt_info_mtd(mtd, buf); - } - - mtd = get_mtd_device_nm("nand0"); - if (!IS_ERR_OR_NULL(mtd)) - board_get_alt_info_mtd(mtd, buf); - - mtd = get_mtd_device_nm("spi-nand0"); - if (!IS_ERR_OR_NULL(mtd)) - board_get_alt_info_mtd(mtd, buf); } if (IS_ENABLED(CONFIG_DFU_VIRT)) { -- 2.25.1
Re: [PATCH v2 06/32] bootstd: Introduce programmable boot
On Wed, Nov 15, 2023 at 09:10:06PM -0700, Simon Glass wrote: > At present bootstd requires CONFIG_CMDLINE to operate. Add a new > 'programmable' boot which can be used when no command line is available. > For now it does almost nothing, since most bootmeths require the > command line. > > Signed-off-by: Simon Glass [snip] > @@ -67,6 +68,14 @@ void main_loop(void) > > autoboot_command(s); > > + if (IS_ENABLED(CONFIG_BOOTSTD_PROG)) { > + int ret; > + > + ret = bootstd_prog_boot(); > + printf("Standard boot failed (err=%dE)\n", ret); > + } > + > cli_loop(); > + > panic("No CLI available"); I think this this brings in at least a 3rd option now, we should try and condense things a little or clean it up maybe. We have common/autoboot.c which is what will fire off menu_show() and drop things in to that menu instead of the cmdline (but that does have cmdline as an option to run, and I suspect that just exits gracefully from the cmd). With CMDLINE=n, cli_loop prints we can't do anything and then panics, so we should also maybe panic() in the case it bootstd_prog_boot fails rather than continue? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote: > On lis 14, 2023 15:06, Quentin Schulz wrote: > > Hi Jonas, > > Hi Quentin > > > On 11/12/23 11:26, Jonas Karlman wrote: > > > The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI > > > NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6. > > > > > > At the time the reason for this new bootsource id value 6 was unknown. > > > > > > We now know that the BootRom on RK3588 use different bootsource id > > > values depending on the iomux used by the flash spi controller, and not > > > by the type of spi nor or spi nand flash used. > > > > > > Add the following defines and use them for RK3588 boot_devices. > > > > > > - BROM_BOOTSOURCE_FSPI_M0 = 3 > > > - BROM_BOOTSOURCE_FSPI_M1 = 4 > > > - BROM_BOOTSOURCE_FSPI_M2 = 6 > > > > > > Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR > > > flash") > > > Signed-off-by: Jonas Karlman > > > --- > > > arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++- > > > arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++-- > > > 2 files changed, 6 insertions(+), 3 deletions(-) > > > > > > diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h > > > b/arch/arm/include/asm/arch-rockchip/bootrom.h > > > index 7dab18fbc3fb..f78337397d63 100644 > > > --- a/arch/arm/include/asm/arch-rockchip/bootrom.h > > > +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h > > > @@ -47,8 +47,10 @@ enum { > > > BROM_BOOTSOURCE_EMMC = 2, > > > BROM_BOOTSOURCE_SPINOR = 3, > > > BROM_BOOTSOURCE_SPINAND = 4, > > > + BROM_BOOTSOURCE_FSPI_M0 = 3, > > > + BROM_BOOTSOURCE_FSPI_M1 = 4, > > > > I'm a bit wary of two pairs of enums sharing the same value, especially when > > we want to use them as offset in a static definition of an array. > > > > Should we #ifdef it (meh) for RK3588? > > Should we add a suffix like before for identifying RK3588-specific options? > > > > At the very least explicit that those are RK3588-specific in a comment for > > both conflicts (the ones that apply to everything except RK3588 to say to > > use only for !RK3588, and the ones that apply to RK3588 only)? > > Can you say why it is so important to know that given enum is specific to > given CPU here in the > header file? I think that the enums in the bootrom.h should be as generic as > possible. > > By using the possible enums in a static array, "solves" the problem of > assigning the boot source to > specific CPU. There is not need to make such grouping in the bootrom.h. Do we have any insight as to why Rockchip re-used those values? Looking at the header I see RK3588 has a different SPINOR value than others. Does RK3588 share the same value for other sources? How much of bootrom.h is still correct for RK3588? I'd rather not have to move to having bootrom_${soc}.h like so many other headers are, and if it's just these values, it might be cleaner to #if .. #else .. #endif the whole enum, and then re-evaluate things abased on whatever the next new SoC does here. -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/15] board: ti: Add j721e_beagleboneai64_* config fragments and env file
On 11/17/23 8:27 AM, Romain Naour wrote: Hello Andrew, All, Le 03/11/2023 à 20:20, Andrew Davis a écrit : On 11/3/23 2:06 PM, Nishanth Menon wrote: On 13:51-20231103, Andrew Davis wrote: On 11/2/23 7:38 PM, Nishanth Menon wrote: Add defconfig fragments for J721E based BeagleBone AI-64 and corresponding customized environment. Signed-off-by: Nishanth Menon --- board/ti/j721e/beagleboneai64.env | 19 board/ti/j721e/beagleboneai64_a72.config | 55 board/ti/j721e/beagleboneai64_r5.config | 19 Beagle boards are not TI boards, add the board support to board/beagle/ Huh, why bring in commercials and organization changes here? am335x and am62 are under the TI umbrella. The SoCs used are yes, the boards are not, we only make our EVM/SK line of boards in house. We did AM335x wrong, in board/ti/am335x/board.c we tried to support like 11 different boards in one file. And while it might have made adding our own extra EVMs easier, it only made things less clear for folks trying to add their own AM335x based boards[0]. We don't integrate support for any other board partner like this. Our friends over at Toradex or Phytec are currently upstreaming boards based on K3 SoCs and in doing so have shown us some areas we can improve. We focus on these little short-cuts to make adding our EVMs (or boards that look like our EVMs) easy. But that only leads to extra work and code duplication for external boards. If something is actually common to the SoC then lets move it to arch/arm/mach-k3/j721e. Tricks like board-variants.c only hide the issue and doesn't help folks wanting to add their boards based on our SoCs to their board// directory. I'm starting a new custom board bring-up based on a j721e SoC (without any SOM) and adding a now board variant from the u-boot provided in the TI SDK (based on 2023.04) is far from easy for the reasons mentioned above (extra work and code duplication for external boards). Also the build break for j7200/j721e SoC as soon as CONFIG_TARGET_J721E_A72_EVM and CONFIG_TARGET_J7200_A72_EVM are undefined: The issue is we didn't properly split J7200 support from J721e and now that there are differences between the two, the only way we have to check which is which is to check the TARGET board, not the SOC (as there is no SOC_K3_J7200, but we are working on that [0]). So currently adding new J721E/J7200 TARGET boards breaks things :( https://source.denx.de/u-boot/u-boot/-/blob/v2023.10/arch/arm/mach-k3/arm64-mmu.c?ref_type=tags#L71 I always wonder if I should work on top of EVMs board or create a new board// directory for customer boards. New board// would be preferred, we do things in our EVM board/ti/ dir that are specific to our EVMs, and there will be more churn, etc.. If adding a new board// for our SoCs is difficult just let us know, we are working several issues to make it more easy going forward and guiding feedback always helps. Andrew [0] https://lore.kernel.org/all/20231106165044.xrmlxoyfbnkmpb5v@revolt/ Best regards, Romain Andrew [0] See "Software Design" https://jaycarlson.net/embedded-linux/#am335x $ git grep beagle board/|cut -d ':' -f1|sort -u board/ti/am335x/board.c board/ti/am335x/board.h board/ti/am57xx/board.c board/ti/am62x/beagleplay_a53.config board/ti/am62x/beagleplay_r5.config board/ti/am62x/MAINTAINERS board/ti/beagle/beagle.c board/ti/beagle/Kconfig board/ti/beagle/led.c board/ti/beagle/MAINTAINERS board/ti/beagle/Makefile board/ti/j721e/beagleboneai64_a72.config board/ti/j721e/beagleboneai64_r5.config board/ti/j721e/MAINTAINERS board/timll/devkit8000/README
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On 11/17/23 12:50 PM, Tom Rini wrote: On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote: On lis 14, 2023 15:06, Quentin Schulz wrote: Hi Jonas, Hi Quentin On 11/12/23 11:26, Jonas Karlman wrote: The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6. At the time the reason for this new bootsource id value 6 was unknown. We now know that the BootRom on RK3588 use different bootsource id values depending on the iomux used by the flash spi controller, and not by the type of spi nor or spi nand flash used. Add the following defines and use them for RK3588 boot_devices. - BROM_BOOTSOURCE_FSPI_M0 = 3 - BROM_BOOTSOURCE_FSPI_M1 = 4 - BROM_BOOTSOURCE_FSPI_M2 = 6 Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash") Signed-off-by: Jonas Karlman --- arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++- arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h b/arch/arm/include/asm/arch-rockchip/bootrom.h index 7dab18fbc3fb..f78337397d63 100644 --- a/arch/arm/include/asm/arch-rockchip/bootrom.h +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h @@ -47,8 +47,10 @@ enum { BROM_BOOTSOURCE_EMMC = 2, BROM_BOOTSOURCE_SPINOR = 3, BROM_BOOTSOURCE_SPINAND = 4, + BROM_BOOTSOURCE_FSPI_M0 = 3, + BROM_BOOTSOURCE_FSPI_M1 = 4, I'm a bit wary of two pairs of enums sharing the same value, especially when we want to use them as offset in a static definition of an array. Should we #ifdef it (meh) for RK3588? Should we add a suffix like before for identifying RK3588-specific options? At the very least explicit that those are RK3588-specific in a comment for both conflicts (the ones that apply to everything except RK3588 to say to use only for !RK3588, and the ones that apply to RK3588 only)? Can you say why it is so important to know that given enum is specific to given CPU here in the header file? I think that the enums in the bootrom.h should be as generic as possible. By using the possible enums in a static array, "solves" the problem of assigning the boot source to specific CPU. There is not need to make such grouping in the bootrom.h. Do we have any insight as to why Rockchip re-used those values? Looking at the header I see RK3588 has a different SPINOR value than others. Does RK3588 share the same value for other sources? How much of bootrom.h is still correct for RK3588? I'd rather not have to move to having bootrom_${soc}.h like so many other headers are, and if it's just these values, it might be cleaner to #if .. #else .. #endif the whole enum, and then re-evaluate things abased on whatever the next new SoC does here. Which c specification does u-boot follow? Duplicate values in enumerations are explicitly allowed in c as far as I ever have known. "The use of enumerators with = may produce enumeration constants with values that duplicate other values in the same enumeration." https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On Fri, Nov 17, 2023 at 01:50:58PM -0500, John Clark wrote: > > On 11/17/23 12:50 PM, Tom Rini wrote: > > On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote: > > > On lis 14, 2023 15:06, Quentin Schulz wrote: > > > > Hi Jonas, > > > Hi Quentin > > > > > > > On 11/12/23 11:26, Jonas Karlman wrote: > > > > > The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from > > > > > SPI > > > > > NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6. > > > > > > > > > > At the time the reason for this new bootsource id value 6 was unknown. > > > > > > > > > > We now know that the BootRom on RK3588 use different bootsource id > > > > > values depending on the iomux used by the flash spi controller, and > > > > > not > > > > > by the type of spi nor or spi nand flash used. > > > > > > > > > > Add the following defines and use them for RK3588 boot_devices. > > > > > > > > > > - BROM_BOOTSOURCE_FSPI_M0 = 3 > > > > > - BROM_BOOTSOURCE_FSPI_M1 = 4 > > > > > - BROM_BOOTSOURCE_FSPI_M2 = 6 > > > > > > > > > > Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI > > > > > NOR flash") > > > > > Signed-off-by: Jonas Karlman > > > > > --- > > > > >arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++- > > > > >arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++-- > > > > >2 files changed, 6 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h > > > > > b/arch/arm/include/asm/arch-rockchip/bootrom.h > > > > > index 7dab18fbc3fb..f78337397d63 100644 > > > > > --- a/arch/arm/include/asm/arch-rockchip/bootrom.h > > > > > +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h > > > > > @@ -47,8 +47,10 @@ enum { > > > > > BROM_BOOTSOURCE_EMMC = 2, > > > > > BROM_BOOTSOURCE_SPINOR = 3, > > > > > BROM_BOOTSOURCE_SPINAND = 4, > > > > > + BROM_BOOTSOURCE_FSPI_M0 = 3, > > > > > + BROM_BOOTSOURCE_FSPI_M1 = 4, > > > > I'm a bit wary of two pairs of enums sharing the same value, especially > > > > when > > > > we want to use them as offset in a static definition of an array. > > > > > > > > Should we #ifdef it (meh) for RK3588? > > > > Should we add a suffix like before for identifying RK3588-specific > > > > options? > > > > > > > > At the very least explicit that those are RK3588-specific in a comment > > > > for > > > > both conflicts (the ones that apply to everything except RK3588 to say > > > > to > > > > use only for !RK3588, and the ones that apply to RK3588 only)? > > > Can you say why it is so important to know that given enum is specific to > > > given CPU here in the > > > header file? I think that the enums in the bootrom.h should be as generic > > > as possible. > > > > > > By using the possible enums in a static array, "solves" the problem of > > > assigning the boot source to > > > specific CPU. There is not need to make such grouping in the bootrom.h. > > Do we have any insight as to why Rockchip re-used those values? Looking > > at the header I see RK3588 has a different SPINOR value than others. > > Does RK3588 share the same value for other sources? How much of > > bootrom.h is still correct for RK3588? I'd rather not have to move to > > having bootrom_${soc}.h like so many other headers are, and if it's just > > these values, it might be cleaner to #if .. #else .. #endif the whole > > enum, and then re-evaluate things abased on whatever the next new SoC > > does here. > > > Which c specification does u-boot follow? Duplicate values in enumerations > are explicitly allowed in c as far as I ever have known. > > "The use of enumerators with = may produce enumeration constants with values > that duplicate other values in the same enumeration." > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf Sorry I wasn't clear. It's less about C specification and more about readability. We could do, but I feel is odd readability-wise is: enum { BROM_BOOTSOURCE_NAND = 1, BROM_BOOTSOURCE_EMMC = 2, BROM_BOOTSOURCE_SPINOR = 3, BROM_BOOTSOURCE_SPINAND = 4, BROM_BOOTSOURCE_SD = 5, BROM_BOOTSOURCE_FSPI_M0_RK3588 = 3, BROM_BOOTSOURCE_FSPI_M1_RK3588 = 4, BROM_BOOTSOURCE_FSPI_M2_RK3588 = 5, BROM_BOOTSOURCE_SPINOR_RK3588 = 6, BROM_BOOTSOURCE_USB = 10, BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB }; But how many of the other values are still correct for RK3588? The TRM I found quickly does say that NAND and SD/eMMC are valid options, and USB, but I didn't see a table that mapped back to the values here. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/3] Revert HAFDBS changes
On Fri, Nov 10, 2023 at 06:38:40PM +1300, Chris Packham wrote: > On Fri, 10 Nov 2023, 10:33 am Tom Rini, wrote: > > > On Fri, Oct 27, 2023 at 01:22:37PM -0400, Tom Rini wrote: > > > On Fri, Oct 27, 2023 at 10:49:47AM +0100, Pierre-Clément Tosi wrote: > > > > Hi Chris, > > > > > > > > On Fri, Oct 27, 2023 at 01:23:51PM +1300, Chris Packham wrote: > > > > > As discussed this series reverts the HAFDBS changes that caused an > > issue > > > > > on AC5/AC5X. I think there are some improvements that can be made to > > the > > > > > initial memory map for the AC5/AC5X but so far nothing I've found > > makes > > > > > it compatible with the HAFDBS changes. > > > > > > > > Would you mind briefly explaining what those issues are and/or point > > me to the > > > > discussion where it was decided to revert these patches? > > > > > > > > The feature is quite useful for users of CONFIG_CMO_BY_VA_ONLY, to > > speed up the > > > > boot sequence: instead of reverting these patches altogether, would a > > reasonable > > > > alternative be to put them behind a build option? > > > > > > > > Also, could you confirm that the "initial memory map" you are > > referring to above > > > > only describes actual memory as, IIRC, some boards were using mappings > > **much** > > > > larger than their DRAM address space? > > > > > > The most details are in this thread: > > > > > https://lore.kernel.org/u-boot/CAFOYHZC_Dveax85n0fLr5BFyZcLqsvUssn=j0ohyvn75bta...@mail.gmail.com/ > > > with some follow-up in: > > > > > https://lore.kernel.org/u-boot/CAFOYHZB7jJWwD24oWzx6u55w2whHYjK56f=qyn0lwu4z8ds...@mail.gmail.com/ > > > > Checking to see if you have any feedback for these platforms? I would > > like to have them working again one way or another in v2024.01, thanks. > > > > Either this series or > https://lore.kernel.org/u-boot/20231018205358.1557234-1-judge.pack...@gmail.com/ > will get the AC5X boards back working. I'm out of other ideas but happy to > test patches. Following up here on the cover letter as well that I've applied the revert for now. I'm happy to revert the revert if we can get the AC5X platforms fixed, and perhaps a little documentation about what was going wrong as I believe the other thread at least hinted that other platforms might be doing a workaround as well but didn't spell out why. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/2] imx: spl_imx_romapi: fix comment about stream(usb) download failure
On Thu, Oct 26, 2023 at 09:32:19AM +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Fix comment about Stream(USB) download failure. > > Fixes: 1cbebc786276 ("imx: add rom api support") > Signed-off-by: Marcel Ziswiler > Reviewed-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
On Fri, Oct 27, 2023 at 01:23:53PM +1300, Chris Packham wrote: > This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is > part of a series trying to make use of the arm64 hardware features for > tracking dirty pages. Unfortunately this series causes problems for the > AC5/AC5X SoCs. Having exhausted other options the consensus seems to be > reverting this series is the best course of action. > > Signed-off-by: Chris Packham Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"
On Fri, Oct 27, 2023 at 01:23:52PM +1300, Chris Packham wrote: > This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. This is > part of a series trying to make use of the arm64 hardware features for > tracking dirty pages. Unfortunately this series causes problems for the > AC5/AC5X SoCs. Having exhausted other options the consensus seems to be > reverting this series is the best course of action. > > Signed-off-by: Chris Packham Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"
On Fri, Oct 27, 2023 at 01:23:54PM +1300, Chris Packham wrote: > This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. This is > part of a series trying to make use of the arm64 hardware features for > tracking dirty pages. Unfortunately this series causes problems for the > AC5/AC5X SoCs. Having exhausted other options the consensus seems to be > reverting this series is the best course of action. > > Signed-off-by: Chris Packham Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 2/2] imx: spl_imx_romapi: fix emmc fast boot mode case
On Thu, Oct 26, 2023 at 09:32:20AM +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > This fixes a regression in the eMMC fast boot mode case where the buffer > was missing 464 bytes. > > The code figures out how many bytes must at least be fetched to honor > the current read, rounds that up to the ss->pagesize [which is a no-op > in the USB download case because that has ->pagesize==1], fetches that > many bytes, but then recorded the original upper bound as the new end of > the valid data. However, this did not take into account the rounding up > to the ss->pagesize. Fix this by recording the actual bytes downloaded. > > Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of > spl_load_simple_fit() to get full FIT size") > Signed-off-by: Marcel Ziswiler > Acked-by: Rasmus Villemoes > Reviewed-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] virtio: rng: gracefully handle 0 byte returns
On Tue, Nov 07, 2023 at 04:09:00PM +, Andre Przywara wrote: > According to the virtio v1.x "entropy device" specification, a virtio-rng > device is supposed to always return at least one byte of entropy. > However the virtio v0.9 spec does not mention such a requirement. > > The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always > returns 8 bytes less of entropy than requested. If 8 bytes or less are > requested, it will return 0 bytes. > This behaviour makes U-Boot's virtio_rng_read() implementation go into an > endless loop, hanging the system. > > Work around this problem by always requesting 8 bytes more than needed, > but only if a previous call to virtqueue_get_buf() returned 0 bytes. > > This should never trigger on a v1.x spec compliant implementation, but > fixes the hang on the Arm FVP. > > Signed-off-by: Andre Przywara > Reported-by: Peter Hoyes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] spl: fix TPL_SYS_MALLOC_F description
On Tue, Nov 14, 2023 at 11:30:17AM +, John Keeping wrote: > This config option enables the malloc() pool in TPL not the SPL. Fix > the description to accurately reflect this. > > Fixes: fd8497dae54 (spl: Create proper symbols for enabling the malloc() pool) > Signed-off-by: John Keeping > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootstd: Avoid freeing a non-allocated buffer
On Wed, Nov 15, 2023 at 06:35:23PM -0700, Simon Glass wrote: > EFI applications can be very large and thus used to cause boot failures > when malloc() space was exhausted. > > A recent changed fixed this by using the kernel_addr_r environment var > as the address of the buffer. However, it still frees the buffer when > the bootflow is discarded. > > Fix this by introducing a flag to indicate whether the buffer was > allocated, or not. > > Note that kernel_addr_r is not the last word here. It might be better > to use lmb to place images. But there is a lot of refactoring to do > before we can remove the environment variables. The distro scripts rely > on them so it is safe for bootstd to do so too. > > Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file > > Signed-off-by: Simon Glass > Reported by: Simon Glass > Reported by: Shantur Rathore > Reviewed-by: Heinrich Schuchardt > Tested-by: Shantur Rathore Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On 2023-11-17 20:07, Tom Rini wrote: > On Fri, Nov 17, 2023 at 01:50:58PM -0500, John Clark wrote: >> >> On 11/17/23 12:50 PM, Tom Rini wrote: >>> On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote: On lis 14, 2023 15:06, Quentin Schulz wrote: > Hi Jonas, Hi Quentin > On 11/12/23 11:26, Jonas Karlman wrote: >> The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI >> NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6. >> >> At the time the reason for this new bootsource id value 6 was unknown. >> >> We now know that the BootRom on RK3588 use different bootsource id >> values depending on the iomux used by the flash spi controller, and not >> by the type of spi nor or spi nand flash used. >> >> Add the following defines and use them for RK3588 boot_devices. >> >> - BROM_BOOTSOURCE_FSPI_M0 = 3 >> - BROM_BOOTSOURCE_FSPI_M1 = 4 >> - BROM_BOOTSOURCE_FSPI_M2 = 6 >> >> Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI NOR >> flash") >> Signed-off-by: Jonas Karlman >> --- >>arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++- >>arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++-- >>2 files changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h >> b/arch/arm/include/asm/arch-rockchip/bootrom.h >> index 7dab18fbc3fb..f78337397d63 100644 >> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h >> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h >> @@ -47,8 +47,10 @@ enum { >> BROM_BOOTSOURCE_EMMC = 2, >> BROM_BOOTSOURCE_SPINOR = 3, >> BROM_BOOTSOURCE_SPINAND = 4, >> +BROM_BOOTSOURCE_FSPI_M0 = 3, >> +BROM_BOOTSOURCE_FSPI_M1 = 4, > I'm a bit wary of two pairs of enums sharing the same value, especially > when > we want to use them as offset in a static definition of an array. > > Should we #ifdef it (meh) for RK3588? > Should we add a suffix like before for identifying RK3588-specific > options? > > At the very least explicit that those are RK3588-specific in a comment for > both conflicts (the ones that apply to everything except RK3588 to say to > use only for !RK3588, and the ones that apply to RK3588 only)? Can you say why it is so important to know that given enum is specific to given CPU here in the header file? I think that the enums in the bootrom.h should be as generic as possible. By using the possible enums in a static array, "solves" the problem of assigning the boot source to specific CPU. There is not need to make such grouping in the bootrom.h. >>> Do we have any insight as to why Rockchip re-used those values? Looking >>> at the header I see RK3588 has a different SPINOR value than others. >>> Does RK3588 share the same value for other sources? How much of >>> bootrom.h is still correct for RK3588? I'd rather not have to move to >>> having bootrom_${soc}.h like so many other headers are, and if it's just >>> these values, it might be cleaner to #if .. #else .. #endif the whole >>> enum, and then re-evaluate things abased on whatever the next new SoC >>> does here. >>> >> Which c specification does u-boot follow? Duplicate values in enumerations >> are explicitly allowed in c as far as I ever have known. >> >> "The use of enumerators with = may produce enumeration constants with values >> that duplicate other values in the same enumeration." >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf > > Sorry I wasn't clear. It's less about C specification and more about > readability. We could do, but I feel is odd readability-wise is: > enum { > BROM_BOOTSOURCE_NAND = 1, > BROM_BOOTSOURCE_EMMC = 2, > BROM_BOOTSOURCE_SPINOR = 3, > BROM_BOOTSOURCE_SPINAND = 4, > BROM_BOOTSOURCE_SD = 5, > BROM_BOOTSOURCE_FSPI_M0_RK3588 = 3, > BROM_BOOTSOURCE_FSPI_M1_RK3588 = 4, > BROM_BOOTSOURCE_FSPI_M2_RK3588 = 5, > BROM_BOOTSOURCE_SPINOR_RK3588 = 6, > BROM_BOOTSOURCE_USB = 10, > BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB > }; > > But how many of the other values are still correct for RK3588? The TRM I > found quickly does say that NAND and SD/eMMC are valid options, and USB, > but I didn't see a table that mapped back to the values here. > Remaining values that is supported should be same, the only difference for RK3588 is that the old SPINOR=3/SPINAND=4 values now map to flash spi iomux M0 and M1, and compared to bootrom in other SoCs cannot be used to determine if SPI NOR or SPI NAND was the boot source. The new value 6 maps to flash spi iomux M2. What type of flash spi media the device was booted from, nor/nand, does not matter for RK3588. Guess I can add a enum for the rk3588 FSPI_M0/M1/M2 values directly
Re: [PATCH 1/4] rockchip: rk3588: Fix boot from SPI flash
On Fri, Nov 17, 2023 at 08:53:49PM +0100, Jonas Karlman wrote: > On 2023-11-17 20:07, Tom Rini wrote: > > On Fri, Nov 17, 2023 at 01:50:58PM -0500, John Clark wrote: > >> > >> On 11/17/23 12:50 PM, Tom Rini wrote: > >>> On Fri, Nov 17, 2023 at 03:03:39PM +0100, Slawomir Stepien wrote: > On lis 14, 2023 15:06, Quentin Schulz wrote: > > Hi Jonas, > Hi Quentin > > > On 11/12/23 11:26, Jonas Karlman wrote: > >> The commit fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from > >> SPI > >> NOR flash") added a new BROM_BOOTSOURCE_SPINOR_RK3588 with value 6. > >> > >> At the time the reason for this new bootsource id value 6 was unknown. > >> > >> We now know that the BootRom on RK3588 use different bootsource id > >> values depending on the iomux used by the flash spi controller, and not > >> by the type of spi nor or spi nand flash used. > >> > >> Add the following defines and use them for RK3588 boot_devices. > >> > >> - BROM_BOOTSOURCE_FSPI_M0 = 3 > >> - BROM_BOOTSOURCE_FSPI_M1 = 4 > >> - BROM_BOOTSOURCE_FSPI_M2 = 6 > >> > >> Fixes: fd6e425be243 ("rockchip: rk3588-rock-5b: Enable boot from SPI > >> NOR flash") > >> Signed-off-by: Jonas Karlman > >> --- > >>arch/arm/include/asm/arch-rockchip/bootrom.h | 4 +++- > >>arch/arm/mach-rockchip/rk3588/rk3588.c | 5 +++-- > >>2 files changed, 6 insertions(+), 3 deletions(-) > >> > >> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h > >> b/arch/arm/include/asm/arch-rockchip/bootrom.h > >> index 7dab18fbc3fb..f78337397d63 100644 > >> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h > >> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h > >> @@ -47,8 +47,10 @@ enum { > >>BROM_BOOTSOURCE_EMMC = 2, > >>BROM_BOOTSOURCE_SPINOR = 3, > >>BROM_BOOTSOURCE_SPINAND = 4, > >> + BROM_BOOTSOURCE_FSPI_M0 = 3, > >> + BROM_BOOTSOURCE_FSPI_M1 = 4, > > I'm a bit wary of two pairs of enums sharing the same value, especially > > when > > we want to use them as offset in a static definition of an array. > > > > Should we #ifdef it (meh) for RK3588? > > Should we add a suffix like before for identifying RK3588-specific > > options? > > > > At the very least explicit that those are RK3588-specific in a comment > > for > > both conflicts (the ones that apply to everything except RK3588 to say > > to > > use only for !RK3588, and the ones that apply to RK3588 only)? > Can you say why it is so important to know that given enum is specific > to given CPU here in the > header file? I think that the enums in the bootrom.h should be as > generic as possible. > > By using the possible enums in a static array, "solves" the problem of > assigning the boot source to > specific CPU. There is not need to make such grouping in the bootrom.h. > >>> Do we have any insight as to why Rockchip re-used those values? Looking > >>> at the header I see RK3588 has a different SPINOR value than others. > >>> Does RK3588 share the same value for other sources? How much of > >>> bootrom.h is still correct for RK3588? I'd rather not have to move to > >>> having bootrom_${soc}.h like so many other headers are, and if it's just > >>> these values, it might be cleaner to #if .. #else .. #endif the whole > >>> enum, and then re-evaluate things abased on whatever the next new SoC > >>> does here. > >>> > >> Which c specification does u-boot follow? Duplicate values in enumerations > >> are explicitly allowed in c as far as I ever have known. > >> > >> "The use of enumerators with = may produce enumeration constants with > >> values > >> that duplicate other values in the same enumeration." > >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf > > > > Sorry I wasn't clear. It's less about C specification and more about > > readability. We could do, but I feel is odd readability-wise is: > > enum { > > BROM_BOOTSOURCE_NAND = 1, > > BROM_BOOTSOURCE_EMMC = 2, > > BROM_BOOTSOURCE_SPINOR = 3, > > BROM_BOOTSOURCE_SPINAND = 4, > > BROM_BOOTSOURCE_SD = 5, > > BROM_BOOTSOURCE_FSPI_M0_RK3588 = 3, > > BROM_BOOTSOURCE_FSPI_M1_RK3588 = 4, > > BROM_BOOTSOURCE_FSPI_M2_RK3588 = 5, > > BROM_BOOTSOURCE_SPINOR_RK3588 = 6, > > BROM_BOOTSOURCE_USB = 10, > > BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB > > }; > > > > But how many of the other values are still correct for RK3588? The TRM I > > found quickly does say that NAND and SD/eMMC are valid options, and USB, > > but I didn't see a table that mapped back to the values here. > > > > Remaining values that is supported should be same, the only difference > for RK3588 is that the old SPINOR=3/SPINAND=4 values now map to flash > spi iomux M0 and M1, and compared to bootrom in
[PATCH V2 1/4] board: rockchip: Refactor panel auto-detect code
From: Chris Morgan Make the inability to detect a panel using the auto detection code not fail the entire boot process. This means that if the panel ID cannot be read we don't set an environment variable for the panel, and if an environment variable for the panel is not set we don't attempt to update the compatible string. Changes to the code also ensure that when there are multiple compatible strings required for the panel we use them both, which solves some issues that will pop up soon for the Linux driver. Signed-off-by: Chris Morgan --- board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 115 + 1 file changed, 74 insertions(+), 41 deletions(-) diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c index 3f1a42d184..3d0c614623 100644 --- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c +++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c @@ -40,6 +40,7 @@ struct rg3xx_model { const char *board; const char *board_name; const char *fdtfile; + const bool detect_panel; }; enum rgxx3_device_id { @@ -54,52 +55,67 @@ enum rgxx3_device_id { static const struct rg3xx_model rg3xx_model_details[] = { [RG353M] = { - 517, /* Observed average from device */ - "rk3566-anbernic-rg353m", - "RG353M", - DTB_DIR "rk3566-anbernic-rg353p.dtb", /* Identical devices */ + .adc_value = 517, /* Observed average from device */ + .board = "rk3566-anbernic-rg353m", + .board_name = "RG353M", + /* Device is identical to RG353P. */ + .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb", + .detect_panel = 1, }, [RG353P] = { - 860, /* Documented value of 860 */ - "rk3566-anbernic-rg353p", - "RG353P", - DTB_DIR "rk3566-anbernic-rg353p.dtb", + .adc_value = 860, /* Documented value of 860 */ + .board = "rk3566-anbernic-rg353p", + .board_name = "RG353P", + .fdtfile = DTB_DIR "rk3566-anbernic-rg353p.dtb", + .detect_panel = 1, }, [RG353V] = { - 695, /* Observed average from device */ - "rk3566-anbernic-rg353v", - "RG353V", - DTB_DIR "rk3566-anbernic-rg353v.dtb", + .adc_value = 695, /* Observed average from device */ + .board = "rk3566-anbernic-rg353v", + .board_name = "RG353V", + .fdtfile = DTB_DIR "rk3566-anbernic-rg353v.dtb", + .detect_panel = 1, }, [RG503] = { - 1023, /* Observed average from device */ - "rk3566-anbernic-rg503", - "RG503", - DTB_DIR "rk3566-anbernic-rg503.dtb", + .adc_value = 1023, /* Observed average from device */ + .board = "rk3566-anbernic-rg503", + .board_name = "RG503", + .fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb", + .detect_panel = 0, }, /* Devices with duplicate ADC value */ [RG353PS] = { - 860, /* Observed average from device */ - "rk3566-anbernic-rg353ps", - "RG353PS", - DTB_DIR "rk3566-anbernic-rg353ps.dtb", + .adc_value = 860, /* Observed average from device */ + .board = "rk3566-anbernic-rg353ps", + .board_name = "RG353PS", + .fdtfile = DTB_DIR "rk3566-anbernic-rg353ps.dtb", + .detect_panel = 1, }, [RG353VS] = { - 695, /* Gathered from second hand information */ - "rk3566-anbernic-rg353vs", - "RG353VS", - DTB_DIR "rk3566-anbernic-rg353vs.dtb", + .adc_value = 695, /* Gathered from second hand information */ + .board = "rk3566-anbernic-rg353vs", + .board_name = "RG353VS", + .fdtfile = DTB_DIR "rk3566-anbernic-rg353vs.dtb", + .detect_panel = 1, }, }; struct rg353_panel { const u16 id; - const char *panel_compat; + const char *panel_compat[2]; }; static const struct rg353_panel rg353_panel_details[] = { - { .id = 0x3052, .panel_compat = "newvision,nv3051d"}, - { .id = 0x3821, .panel_compat = "anbernic,rg353v-panel-v2"}, + { + .id = 0x3052, + .panel_compat[0] = "anbernic,rg353p-panel", + .panel_compat[1] = "newvision,nv3051d", + }, + { + .id = 0x3821, + .panel_compat[0] = "anbernic,rg353v-panel-v2", + .panel_compat[1] = NULL, + }, }; /* @@ -298,11 +314,10 @@ int rgxx3_detect_display(void) if (!panel) { printf("Unable to identify panel_id %x\n", (panel_id[0] << 8) | panel_
[PATCH V2 0/4] Add Additional Boards and Features to RGxx3
From: Chris Morgan The RGxx3 is a pseudo-device for U-Boot that works for every Anbernic RGxx3 series device on the market. Add support for another series of very similar devices from Powkiddy. Changes since V1: - Update verbiage around function button to say "recovery" mode instead of calling it "maskrom" mode, which has a specific meaning. Also note that recovery function was done in a board specific manner to ensure it can run early. - Update board level documentation for the RGxx3. Chris Morgan (4): board: rockchip: Refactor panel auto-detect code board: rockchip: Add Recovery Button for Anbernic RGxx3 board: rockchip: Add support for RGB30 and RK2023 to RGxx3 doc: board: anbernic: Update rgxx3 to add new boards board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 195 - doc/board/anbernic/rgxx3.rst | 18 +- 2 files changed, 166 insertions(+), 47 deletions(-) -- 2.34.1
[PATCH V2 3/4] board: rockchip: Add support for RGB30 and RK2023 to RGxx3
From: Chris Morgan Add support for the Powkiddy RK2023 and RGB30 to the Anbernic RGxx3. While these devices are manufactured by Powkiddy instead of Anbernic, the hardware is so similar they can all use the same bootloader. Signed-off-by: Chris Morgan Reviewed-by: Kever Yang --- board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 16 1 file changed, 16 insertions(+) diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c index a93b11cd47..dae9dc87c2 100644 --- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c +++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c @@ -60,6 +60,8 @@ enum rgxx3_device_id { RG353P, RG353V, RG503, + RGB30, + RK2023, /* Devices with duplicate ADC value */ RG353PS, RG353VS, @@ -95,6 +97,20 @@ static const struct rg3xx_model rg3xx_model_details[] = { .fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb", .detect_panel = 0, }, + [RGB30] = { + .adc_value = 383, /* Gathered from second hand information */ + .board = "rk3566-powkiddy-rgb30", + .board_name = "RGB30", + .fdtfile = DTB_DIR "rk3566-powkiddy-rgb30.dtb", + .detect_panel = 0, + }, + [RK2023] = { + .adc_value = 635, /* Observed average from device */ + .board = "rk3566-powkiddy-rk2023", + .board_name = "RK2023", + .fdtfile = DTB_DIR "rk3566-powkiddy-rk2023.dtb", + .detect_panel = 0, + }, /* Devices with duplicate ADC value */ [RG353PS] = { .adc_value = 860, /* Observed average from device */ -- 2.34.1
[PATCH V2 2/4] board: rockchip: Add Recovery Button for Anbernic RGxx3
From: Chris Morgan Add support for users to enter recovery mode by holding the function button when they power up the device. Since the device has soldered eMMC and sometimes does not expose a clk pin on the mainboard there is a small chance that a user who flashes a bad bootloader may not be able to recover if the headers themselves are valid. As a result this check is done during spl_early_init() to ensure that it runs as early as possible, and it does so by directly manipulating the ADC hardware in lieu of loading the ADC driver. Ideally, once we have an open source TPL stage we can move this to the TPL stage, so it will run even earlier. It may also be possible to make this code "more portable", but at the tradeoff of requiring to be run later in the boot process. For now it's done in a board specific way to err on the side of "do it early". Signed-off-by: Chris Morgan --- board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 64 ++ 1 file changed, 64 insertions(+) diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c index 3d0c614623..a93b11cd47 100644 --- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c +++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c @@ -6,12 +6,14 @@ #include #include #include +#include #include #include #include #include #include #include +#include #include #include #include @@ -20,6 +22,8 @@ #include #include +#define BOOT_BROM_DOWNLOAD 0xef08a53c + #define GPIO0_BASE 0xfdd6 #define GPIO4_BASE 0xfe77 #define GPIO_SWPORT_DR_L 0x @@ -33,6 +37,14 @@ #define GPIO_WRITEMASK(bits) ((bits) << 16) +#define SARADC_BASE0xfe72 +#define SARADC_DATA0x +#define SARADC_STAS0x0004 +#define SARADC_ADC_STATUS BIT(0) +#define SARADC_CTRL0x0008 +#define SARADC_INPUT_SRC_MSK 0x7 +#define SARADC_POWER_CTRL BIT(3) + #define DTB_DIR"rockchip/" struct rg3xx_model { @@ -118,12 +130,64 @@ static const struct rg353_panel rg353_panel_details[] = { }, }; +/* + * The device has internal eMMC, and while some devices have an exposed + * clk pin you can ground to force a bypass not all devices do. As a + * result it may be possible for some devices to become a perma-brick + * if a corrupted TPL or SPL stage with a valid header is flashed to + * the internal eMMC. Add functionality to read ADC channel 0 (the func + * button) as early as possible in the boot process to provide some + * protection against this. If we ever get an open TPL stage, we should + * consider moving this function there. + */ +void read_func_button(void) +{ + int ret; + u32 reg; + + /* Turn off SARADC to reset it. */ + writel(0, (SARADC_BASE + SARADC_CTRL)); + + /* Enable channel 0 and power on SARADC. */ + writel(((0 & SARADC_INPUT_SRC_MSK) | SARADC_POWER_CTRL), + (SARADC_BASE + SARADC_CTRL)); + + /* +* Wait for data to be ready. Use timeout of 2us from +* rockchip_saradc driver. +*/ + ret = readl_poll_timeout((SARADC_BASE + SARADC_STAS), reg, +!(reg & SARADC_ADC_STATUS), 2); + if (ret) { + printf("ADC Timeout"); + return; + } + + /* Read the data from the SARADC. */ + reg = readl((SARADC_BASE + SARADC_DATA)); + + /* Turn the SARADC back off so it's ready to be used again. */ + writel(0, (SARADC_BASE + SARADC_CTRL)); + + /* +* If the value is less than 30 the button is being pressed. +* Reset the device back into Rockchip download mode. +*/ + if (reg <= 30) { + printf("download key pressed, entering download mode..."); + writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG); + do_reset(NULL, 0, 0, NULL); + } +}; + /* * Start LED very early so user knows device is on. Set color * to red. */ void spl_board_init(void) { + read_func_button(); + /* Set GPIO0_C5, GPIO0_C6, and GPIO0_C7 to output. */ writel(GPIO_WRITEMASK(GPIO_C7 | GPIO_C6 | GPIO_C5) | \ (GPIO_C7 | GPIO_C6 | GPIO_C5), -- 2.34.1
[PATCH V2 4/4] doc: board: anbernic: Update rgxx3 to add new boards
From: Chris Morgan Update the RGxx3 documentation to note that it now supports two new non-Anbernic boards. Also update verbiage around panel detection to note that it is no longer hard coded to the RG503. Signed-off-by: Chris Morgan --- doc/board/anbernic/rgxx3.rst | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/doc/board/anbernic/rgxx3.rst b/doc/board/anbernic/rgxx3.rst index 7d1beb423c..89cc4ee560 100644 --- a/doc/board/anbernic/rgxx3.rst +++ b/doc/board/anbernic/rgxx3.rst @@ -12,18 +12,24 @@ This allows U-Boot to boot the following Anbernic devices: - Anbernic RG353VS - Anbernic RG503 +Additionally, the following very similar non-Anbernic devices are also +supported: + + - Powkiddy RGB30 + - Powkiddy RK2023 + The correct device is detected automatically by comparing ADC values from ADC channel 1. In the event of an RG353V or RG353P, an attempt is then made to probe for an eMMC and if it fails the device is assumed to be an RG353VS or RG353PS. Based on the detected device, the environment variables "board", "board_name", and "fdtfile" are set to the correct values corresponding to the board which can be read by a -boot script to boot with the correct device tree. If the board detected -is not of type RG503 (which currently has only 1 panel revision) a -panel detect is then performed by probing a "dummy" display on the DSI -bus and then querying the display ID. The display ID is then compared -to a table to get the known compatible string for use in Linux, and -this string is saved as an environment variable of "panel". +boot script to boot with the correct device tree. If a board is defined +as requiring panel detection, a panel detect is then performed by +probing a "dummy" display on the DSI bus and then querying the display +ID. The display ID is then compared to a table to get the known +compatible string for use in Linux, and this string is saved as an +environment variable of "panel". FDT fixups are performed in the event of an RG353M to change the device name, or in the event the panel detected does not match the devicetree. -- 2.34.1
[PATCH v2 0/4] bootflow: bootmeth_efi: Fix network eif boot.
Currently bootmeth_efi crashes while doing a network (dhcp) boot. This patch series fixes issues and both network and disk boot works. Shantur Rathore (4): bootflow: bootmeth_efi: Set bootp_arch as hex bootflow: bootmeth_efi: Don't set bootdev again bootflow: bootmeth_efi: Handle fdt not available. bootflow: bootmeth_efi: don't free buffer boot/bootmeth_efi.c | 22 -- include/bootflow.h | 1 + 2 files changed, 17 insertions(+), 6 deletions(-) -- 2.40.1
[PATCH v2 1/4] bootflow: bootmeth_efi: Set bootp_arch as hex
bootmeth_efi sets up bootp_arch which is read later in bootp.c Currently bootp_arch is being set as integer string and being read in bootp.c as hex, this sends incorrect arch value to dhcp server which in return sends wrong file for network boot. For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11 and later is read as 0x11 and 17 is sent to dhcp server. Setting it as hex string fixes the problem. Signed-off-by: Shantur Rathore --- boot/bootmeth_efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 9ba7734911..682cf5b23b 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -339,7 +339,7 @@ static int distro_efi_read_bootflow_net(struct bootflow *bflow) ret = env_set("bootp_vci", str); if (ret) return log_msg_ret("vcs", ret); - ret = env_set_ulong("bootp_arch", arch); + ret = env_set_hex("bootp_arch", arch); if (ret) return log_msg_ret("ars", ret); -- 2.40.1
[PATCH v2 2/4] bootflow: bootmeth_efi: Don't set bootdev again
efi_set_bootdev is already called as part of tftp while doing dhcp_run() Doing this again crashes U-boot and we don't need to call again. Signed-off-by: Shantur Rathore --- boot/bootmeth_efi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 682cf5b23b..5917458dc5 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -360,9 +360,6 @@ static int distro_efi_read_bootflow_net(struct bootflow *bflow) return log_msg_ret("sz", -EINVAL); bflow->size = size; - /* do the hideous EFI hack */ - efi_set_bootdev("Net", "", bflow->fname, map_sysmem(addr, 0), - bflow->size); /* read the DT file also */ fdt_addr_str = env_get("fdt_addr_r"); -- 2.40.1
[PATCH v2 3/4] bootflow: bootmeth_efi: Handle fdt not available.
While booting with efi, if fdt isn't available externally, just use the built-in one. Signed-off-by: Shantur Rathore --- boot/bootmeth_efi.c | 10 +- include/bootflow.h | 1 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 5917458dc5..5e67afed88 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -313,6 +313,7 @@ static int distro_efi_try_bootflow_files(struct udevice *dev, */ } else { log_debug("No device tree available\n"); + bflow->flags |= BOOTFLOWF_USE_BUILTIN_FDT; } return 0; @@ -382,6 +383,7 @@ static int distro_efi_read_bootflow_net(struct bootflow *bflow) bflow->fdt_addr = fdt_addr; } else { log_debug("No device tree available\n"); + bflow->flags |= BOOTFLOWF_USE_BUILTIN_FDT; } bflow->state = BOOTFLOWST_READY; @@ -443,7 +445,13 @@ static int distro_efi_boot(struct udevice *dev, struct bootflow *bflow) * At some point we can add a real interface to bootefi so we can call * this directly. For now, go through the CLI, like distro boot. */ - snprintf(cmd, sizeof(cmd), "bootefi %lx %lx", kernel, fdt); + if (bflow->flags & BOOTFLOWF_USE_BUILTIN_FDT) { + log_debug("Booting with built-in fdt\n"); + snprintf(cmd, sizeof(cmd), "bootefi %lx", kernel); + } else { + snprintf(cmd, sizeof(cmd), "bootefi %lx %lx", kernel, fdt); + } + if (run_command(cmd, 0)) return log_msg_ret("run", -EINVAL); diff --git a/include/bootflow.h b/include/bootflow.h index fede8f22a2..3890cd4bc2 100644 --- a/include/bootflow.h +++ b/include/bootflow.h @@ -49,6 +49,7 @@ enum bootflow_state_t { enum bootflow_flags_t { BOOTFLOWF_USE_PRIOR_FDT = 1 << 0, BOOTFLOWF_STATIC_BUF= 1 << 1, + BOOTFLOWF_USE_BUILTIN_FDT = 1 << 2, }; /** -- 2.40.1
[PATCH v2 4/4] bootflow: bootmeth_efi: don't free buffer
bootmeth_efi doesn't allocate any buffer to load efi in any case. enable static buffer flag for all cases. Signed-off-by: Shantur Rathore --- boot/bootmeth_efi.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 5e67afed88..045e9ac543 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -160,7 +160,6 @@ static int efiload_read_file(struct bootflow *bflow, ulong addr) if (ret) return log_msg_ret("read", ret); bflow->buf = map_sysmem(addr, bflow->size); - bflow->flags |= BOOTFLOWF_STATIC_BUF; set_efi_bootdev(desc, bflow); @@ -395,6 +394,12 @@ static int distro_efi_read_bootflow(struct udevice *dev, struct bootflow *bflow) { int ret; + /* +* bootmeth_efi doesn't allocate any buffer neither for bulk nor net device +* set flag to avoid freeing static buffer. +*/ + bflow->flags |= BOOTFLOWF_STATIC_BUF; + if (bootmeth_uses_network(bflow)) { /* we only support reading from one device, so ignore 'dev' */ ret = distro_efi_read_bootflow_net(bflow); -- 2.40.1
[PATCH v4 3/3] net: bootp: add config option BOOTP_RANDOM_XID
From: Sean Edmond The new config option BOOTP_RANDOM_XID will randomize the transaction ID for each new BOOT/DHCPv4 exchange. Signed-off-by: Sean Edmond --- cmd/Kconfig | 7 +++ net/bootp.c | 31 +-- 2 files changed, 24 insertions(+), 14 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 93bf752035c..244237e6d60 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1853,6 +1853,13 @@ config BOOTP_VCI_STRING default "U-Boot.arm" if ARM default "U-Boot" +config BOOTP_RANDOM_XID + bool "Send random transaction ID to BOOTP/DHCP server" + depends on CMD_BOOTP && (LIB_RAND || EXYNOS_ACE_SHA || RNG_NPCM) + help + Selecting this will allow for a random transaction ID to get + selected for each BOOTP/DHCPv4 exchange. + if CMD_DHCP6 config DHCP6_PXE_CLIENTARCH diff --git a/net/bootp.c b/net/bootp.c index 89425717328..49cd9064436 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -837,22 +837,25 @@ void bootp_request(void) /* Only generate a new transaction ID for each new BOOTP request */ if (bootp_try == 1) { - /* -* Bootp ID is the lower 4 bytes of our ethernet address -* plus the current time in ms. -*/ - bootp_id = ((u32)net_ethaddr[2] << 24) - | ((u32)net_ethaddr[3] << 16) - | ((u32)net_ethaddr[4] << 8) - | (u32)net_ethaddr[5]; - bootp_id += get_timer(0); - bootp_id = htonl(bootp_id); - bootp_add_id(bootp_id); - net_copy_u32(&bp->bp_id, &bootp_id); - } else { - net_copy_u32(&bp->bp_id, &bootp_id); + if (IS_ENABLED(CONFIG_BOOTP_RANDOM_XID)) { + srand(get_ticks() + rand()); + bootp_id = rand(); + } else { + /* +* Bootp ID is the lower 4 bytes of our ethernet address +* plus the current time in ms. +*/ + bootp_id = ((u32)net_ethaddr[2] << 24) + | ((u32)net_ethaddr[3] << 16) + | ((u32)net_ethaddr[4] << 8) + | (u32)net_ethaddr[5]; + bootp_id += get_timer(0); + bootp_id = htonl(bootp_id); + } } + bootp_add_id(bootp_id); + net_copy_u32(&bp->bp_id, &bootp_id); /* * Calculate proper packet lengths taking into account the * variable size of the options field -- 2.42.0
[PATCH v4 0/3] [PATCH v4 0/3] [PATCH v3 0/3] BOOTP/DHCPv4 enhancements
From: Sean Edmond In our datacenter application, a single DHCP server is servicing 36000+ clients. Improvements are required to the DHCPv4 retransmission behavior to align with RFC and ensure less pressure is exerted on the server: - retransmission backoff interval maximum is configurable (environment variable bootpretransmitperiodmax) - initial retransmission backoff interval is configurable (environment variable bootpretransmitperiodinit) - transaction ID is kept the same for each BOOTP/DHCPv4 request (not recreated on each retry) For our application we'll use: - bootpretransmitperiodmax=16000 - bootpretransmitperiodinit=2000 A new configuration BOOTP_RANDOM_XID has been added to enable a randomized BOOTP/DHCPv4 transaction ID. Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous patch was accepted. A new patch fixes a possible double free() and addresses latest review comments. changes in v4: - rebase master and resolve conflicts - change commit description for DHCP option 209 patch (this is now an enhancement patch) - default y for BOOTP_PXE_DHCP_OPTION (feedback from review) - Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission improvements require rand()) changes in v3: - add define for option 209 and rfc5071 reference - Set RETRANSMIT_PERIOD_MAX_MS=6 - Add randomization factor to retransmission timeout - Add depends for BOOTP_RANDOM_XID changes in v2: - use env_get_ulong() to get environment variables Sean Edmond (3): net: Additional fixes for dhcp option 209 net: bootp: BOOTP/DHCPv4 retransmission improvements net: bootp: add config option BOOTP_RANDOM_XID cmd/Kconfig | 10 ++- cmd/pxe.c | 2 ++ net/bootp.c | 76 + net/bootp.h | 2 ++ 4 files changed, 72 insertions(+), 18 deletions(-) -- 2.42.0
[PATCH v4 1/3] net: Additional fixes for dhcp option 209
From: Sean Edmond Addresses feedback from latest review: - Enable option 209 by default - Set pxelinux_configfile to NULL to avoid potential double free - change hardcoced 209 to a define Signed-off-by: Sean Edmond --- cmd/Kconfig | 1 + cmd/pxe.c | 2 ++ net/bootp.c | 4 ++-- net/bootp.h | 2 ++ 4 files changed, 7 insertions(+), 2 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index df6d71c103f..ae846b204dc 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1842,6 +1842,7 @@ config BOOTP_PXE_CLIENTARCH config BOOTP_PXE_DHCP_OPTION bool "Request & store 'pxe_configfile' from BOOTP/DHCP server" + default y depends on BOOTP_PXE config BOOTP_VCI_STRING diff --git a/cmd/pxe.c b/cmd/pxe.c index 21134eb7a30..9404f445187 100644 --- a/cmd/pxe.c +++ b/cmd/pxe.c @@ -65,6 +65,8 @@ static int pxe_dhcp_option_path(struct pxe_context *ctx, unsigned long pxefile_a int ret = get_pxe_file(ctx, pxelinux_configfile, pxefile_addr_r); free(pxelinux_configfile); + /* set to NULL to avoid double-free if DHCP is tried again */ + pxelinux_configfile = NULL; return ret; } diff --git a/net/bootp.c b/net/bootp.c index 68002909634..24547cf7bfd 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -603,7 +603,7 @@ static int dhcp_extended(u8 *e, int message_type, struct in_addr server_ip, *cnt += 1; #endif if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) { - *e++ = 209; /* PXELINUX Config File */ + *e++ = DHCP_OPTION_PXE_CONFIG_FILE; /* PXELINUX Config File */ *cnt += 1; } /* no options, so back up to avoid sending an empty request list */ @@ -914,7 +914,7 @@ static void dhcp_process_options(uchar *popt, uchar *end) net_boot_file_name[size] = 0; } break; - case 209: /* PXELINUX Config File */ + case DHCP_OPTION_PXE_CONFIG_FILE: /* PXELINUX Config File */ if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) { /* In case it has already been allocated when get DHCP Offer packet, * free first to avoid memory leak. diff --git a/net/bootp.h b/net/bootp.h index 4e32b19d424..24b32c73f62 100644 --- a/net/bootp.h +++ b/net/bootp.h @@ -91,6 +91,8 @@ typedef enum { INIT, #define DHCP_NAK 6 #define DHCP_RELEASE 7 +#define DHCP_OPTION_PXE_CONFIG_FILE209 /* "ConfigFile" option according to rfc5071 */ + /**/ #endif /* __BOOTP_H__ */ -- 2.42.0
[PATCH v4 2/3] net: bootp: BOOTP/DHCPv4 retransmission improvements
From: Sean Edmond This patch introduces 3 improvements to align with RFC 951: - retransmission backoff interval maximum is configurable - initial retranmission backoff interval is configurable - transaction ID is kept the same for each BOOTP/DHCPv4 request In applications where thousands of nodes are serviced by a single DHCP server, maximizing the retransmission backoff interval at 2 seconds (the current u-boot default) exerts high pressure on the DHCP server and network layer. RFC 951 “7.2. Client Retransmission Strategy” states that the retransmission backoff interval should be limited to 60 seconds. This patch allows the interval to be configurable using the environment variable "bootpretransmitperiodmax" The initial retranmission backoff period defaults to 250ms, which is also too small for these scenarios with many clients. This patch makes the initial retransmission interval to be configurable using the environment variable "bootpretransmitperiodinit". Also, on a retransmission it is not expected for the transaction ID to change (only the 'secs' field should be updated). Let's save the transaction ID and use the same transaction ID for each BOOTP/DHCPv4 exchange. Signed-off-by: Sean Edmond --- cmd/Kconfig | 2 +- net/bootp.c | 71 + 2 files changed, 56 insertions(+), 17 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index ae846b204dc..93bf752035c 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1717,6 +1717,7 @@ if CMD_NET config CMD_BOOTP bool "bootp" default y + select LIB_RAND help bootp - boot image via network using BOOTP/TFTP protocol @@ -1725,7 +1726,6 @@ config CMD_DHCP depends on CMD_BOOTP help Boot image via network using DHCP/TFTP protocol - config CMD_DHCP6 bool "dhcp6" depends on IPV6 diff --git a/net/bootp.c b/net/bootp.c index 24547cf7bfd..89425717328 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -42,6 +42,22 @@ */ #define TIMEOUT_MS ((3 + (CONFIG_NET_RETRY_COUNT * 5)) * 1000) +/* + * According to rfc951 : 7.2. Client Retransmission Strategy + * "After the 'average' backoff reaches about 60 seconds, it should be + * increased no further, but still randomized." + * + * U-Boot has saturated this backoff at 2 seconds for a long time. + * To modify, set the environment variable "bootpretransmitperiodmax" + */ +#define RETRANSMIT_PERIOD_MAX_MS 6 + +/* Retransmission timeout for the initial packet (in milliseconds). + * This timeout will double on each retry. To modify, set the + * environment variable bootpretransmitperiodinit. + */ +#define RETRANSMIT_PERIOD_INIT_MS 250 + #ifndef CFG_DHCP_MIN_EXT_LEN /* minimal length of extension list */ #define CFG_DHCP_MIN_EXT_LEN 64 #endif @@ -53,6 +69,7 @@ u32bootp_ids[CFG_BOOTP_ID_CACHE_SIZE]; unsigned int bootp_num_ids; intbootp_try; +u32bootp_id; ulong bootp_start; ulong bootp_timeout; char net_nis_domain[32] = {0,}; /* Our NIS domain */ @@ -60,6 +77,7 @@ char net_hostname[32] = {0,}; /* Our hostname */ char net_root_path[CONFIG_BOOTP_MAX_ROOT_PATH_LEN] = {0,}; /* Our bootpath */ static ulong time_taken_max; +static u32 retransmit_period_max_ms; #if defined(CONFIG_CMD_DHCP) static dhcp_state_t dhcp_state = INIT; @@ -396,6 +414,7 @@ static void bootp_handler(uchar *pkt, unsigned dest, struct in_addr sip, static void bootp_timeout_handler(void) { ulong time_taken = get_timer(bootp_start); + int rand_minus_plus_100; if (time_taken >= time_taken_max) { #ifdef CONFIG_BOOTP_MAY_FAIL @@ -414,8 +433,17 @@ static void bootp_timeout_handler(void) } } else { bootp_timeout *= 2; - if (bootp_timeout > 2000) - bootp_timeout = 2000; + if (bootp_timeout > retransmit_period_max_ms) + bootp_timeout = retransmit_period_max_ms; + + /* Randomize by adding bootp_timeout*RAND, where RAND +* is a randomization factor between -0.1..+0.1 +*/ + srand(get_ticks() + rand()); + rand_minus_plus_100 = ((rand() % 200) - 100); + bootp_timeout = bootp_timeout + + (((int)bootp_timeout * rand_minus_plus_100) / 1000); + net_set_timeout_handler(bootp_timeout, bootp_timeout_handler); bootp_request(); } @@ -711,10 +739,14 @@ static int bootp_extended(u8 *e) void bootp_reset(void) { + char *ep; /* Environment pointer */ + bootp_num_ids = 0; bootp_try = 0; bootp_start = get_timer(0); - bootp_timeout = 250; + + bootp_timeout = env_get_ulong("bootpretransmitperiodinit", 10, RETRANSMIT_PERIOD_INIT_MS); + } void bootp_request(void) @@ -726,7 +758,6 @@ void bootp_request(void) #ifdef CONFIG
Re: [PATCH v4 3/3] net: bootp: add config option BOOTP_RANDOM_XID
On Fri, Nov 17, 2023 at 01:49:25PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > The new config option BOOTP_RANDOM_XID will randomize the transaction ID > for each new BOOT/DHCPv4 exchange. > > Signed-off-by: Sean Edmond > --- > cmd/Kconfig | 7 +++ > net/bootp.c | 31 +-- > 2 files changed, 24 insertions(+), 14 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 93bf752035c..244237e6d60 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1853,6 +1853,13 @@ config BOOTP_VCI_STRING > default "U-Boot.arm" if ARM > default "U-Boot" > > +config BOOTP_RANDOM_XID > + bool "Send random transaction ID to BOOTP/DHCP server" > + depends on CMD_BOOTP && (LIB_RAND || EXYNOS_ACE_SHA || RNG_NPCM) This should be (LIB_RAND || LIB_HW_RAND) -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 0/3] [PATCH v4 0/3] [PATCH v3 0/3] BOOTP/DHCPv4 enhancements
On Fri, Nov 17, 2023 at 01:49:22PM -0800, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > In our datacenter application, a single DHCP server is servicing 36000+ > clients. > Improvements are required to the DHCPv4 retransmission behavior to align with > RFC and ensure less pressure is exerted on the server: > - retransmission backoff interval maximum is configurable > (environment variable bootpretransmitperiodmax) > - initial retransmission backoff interval is configurable > (environment variable bootpretransmitperiodinit) > - transaction ID is kept the same for each BOOTP/DHCPv4 request > (not recreated on each retry) > > For our application we'll use: > - bootpretransmitperiodmax=16000 > - bootpretransmitperiodinit=2000 > > A new configuration BOOTP_RANDOM_XID has been added to enable a randomized > BOOTP/DHCPv4 transaction ID. > > Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous > patch was accepted. A new patch fixes a possible double free() and > addresses latest review comments. The changes from revision to revision should be below the "---" in a commit and not the commit message itself. Please reword things for v5. Thanks. -- Tom signature.asc Description: PGP signature
[PATCH 1/3] configs: keystone2: Remove unused SPL_MALLOC_F_SIZE and KEYSTONE_SPL_STACK_SIZE
These are leftover definitions. While here cleanup some leftover comments. Signed-off-by: Andrew Davis --- include/configs/ti_armv7_keystone2.h | 22 -- 1 file changed, 22 deletions(-) diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 72c04d8a994..637e9e4369e 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -9,23 +9,10 @@ #ifndef __CONFIG_KS2_EVM_H #define __CONFIG_KS2_EVM_H -/* U-Boot Build Configuration */ - -/* SoC Configuration */ - /* Memory Configuration */ #define CFG_SYS_LPAE_SDRAM_BASE0x8 #define CFG_MAX_RAM_BANK_SIZE (2 << 30) /* 2GB */ -#ifdef CONFIG_SYS_MALLOC_F_LEN -#define SPL_MALLOC_F_SIZE CONFIG_SYS_MALLOC_F_LEN -#else -#define SPL_MALLOC_F_SIZE 0 -#endif - -/* SPL SPI Loader Configuration */ -#define KEYSTONE_SPL_STACK_SIZE(8 * 1024) - /* SRAM scratch space entries */ #define SRAM_SCRATCH_SPACE_ADDR0xc0c23fc @@ -53,8 +40,6 @@ #define CFG_KSNET_SERDES_SGMII2_BASE KS2_SGMII_SERDES2_BASE #define CFG_KSNET_SERDES_LANES_PER_SGMII KS2_LANES_PER_SGMII_SERDES -/* EEPROM definitions */ - /* NAND Configuration */ #define CFG_SYS_NAND_MASK_CLE 0x4000 #define CFG_SYS_NAND_MASK_ALE 0x2000 @@ -63,13 +48,6 @@ #define CFG_SYS_NAND_LARGEPAGE #define CFG_SYS_NAND_BASE_LIST { 0x3000, } - - -/* U-Boot general configuration */ - -/* EDMA3 */ - - /* Now for the remaining common defines */ #include -- 2.39.2
[PATCH 2/3] configs: keystone2: Do not include hardware.h
This is a hacky way to have this file included in all source files that include common.h, instead just include from the files that need it. Signed-off-by: Andrew Davis --- drivers/memory/ti-aemif.c| 1 + drivers/soc/ti/keystone_serdes.c | 1 + include/configs/ti_armv7_keystone2.h | 1 - 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c index c4bc88c1510..41325eb0f94 100644 --- a/drivers/memory/ti-aemif.c +++ b/drivers/memory/ti-aemif.c @@ -7,6 +7,7 @@ */ #include +#include #include #define AEMIF_WAITCYCLE_CONFIG (KS2_AEMIF_CNTRL_BASE + 0x4) diff --git a/drivers/soc/ti/keystone_serdes.c b/drivers/soc/ti/keystone_serdes.c index 2ece1a8f647..0e1bf8ff39d 100644 --- a/drivers/soc/ti/keystone_serdes.c +++ b/drivers/soc/ti/keystone_serdes.c @@ -8,6 +8,7 @@ #include #include +#include #include #include diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index 637e9e4369e..b36207cb5d1 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -52,7 +52,6 @@ #include /* we may include files below only after all above definitions */ -#include #include #ifndef CONFIG_SOC_K2G #define CFG_SYS_HZ_CLOCK ks_clk_get_rate(KS2_CLK1_6) -- 2.39.2
[PATCH 3/3] ARM: keystone2: Remove unneeded inclusions of common.h
Signed-off-by: Andrew Davis --- arch/arm/mach-keystone/clock.c| 1 - arch/arm/mach-keystone/cmd_clock.c| 2 +- arch/arm/mach-keystone/cmd_mon.c | 1 - arch/arm/mach-keystone/cmd_poweroff.c | 1 - arch/arm/mach-keystone/ddr3.c | 2 +- arch/arm/mach-keystone/ddr3_spd.c | 2 +- arch/arm/mach-keystone/include/mach/mux-k2g.h | 1 - arch/arm/mach-keystone/init.c | 1 - arch/arm/mach-keystone/keystone.c | 1 - arch/arm/mach-keystone/mon.c | 1 - arch/arm/mach-keystone/msmc.c | 1 - arch/arm/mach-keystone/psc.c | 1 - 12 files changed, 3 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-keystone/clock.c b/arch/arm/mach-keystone/clock.c index 0c59515d2eb..4f193794efb 100644 --- a/arch/arm/mach-keystone/clock.c +++ b/arch/arm/mach-keystone/clock.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include #include #include diff --git a/arch/arm/mach-keystone/cmd_clock.c b/arch/arm/mach-keystone/cmd_clock.c index 72dc394df5f..e9ecc05953a 100644 --- a/arch/arm/mach-keystone/cmd_clock.c +++ b/arch/arm/mach-keystone/cmd_clock.c @@ -6,7 +6,7 @@ * Texas Instruments Incorporated, */ -#include +#include #include #include #include diff --git a/arch/arm/mach-keystone/cmd_mon.c b/arch/arm/mach-keystone/cmd_mon.c index dc97bac8550..c6e7e2c3097 100644 --- a/arch/arm/mach-keystone/cmd_mon.c +++ b/arch/arm/mach-keystone/cmd_mon.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include #include #include diff --git a/arch/arm/mach-keystone/cmd_poweroff.c b/arch/arm/mach-keystone/cmd_poweroff.c index f0ad9173b96..0ad31ef4e28 100644 --- a/arch/arm/mach-keystone/cmd_poweroff.c +++ b/arch/arm/mach-keystone/cmd_poweroff.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include #include #include diff --git a/arch/arm/mach-keystone/ddr3.c b/arch/arm/mach-keystone/ddr3.c index ea7d0b903cf..ca0fb702d54 100644 --- a/arch/arm/mach-keystone/ddr3.c +++ b/arch/arm/mach-keystone/ddr3.c @@ -9,7 +9,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-keystone/ddr3_spd.c b/arch/arm/mach-keystone/ddr3_spd.c index 6f7f8ab7b40..d4ff442175b 100644 --- a/arch/arm/mach-keystone/ddr3_spd.c +++ b/arch/arm/mach-keystone/ddr3_spd.c @@ -5,8 +5,8 @@ * (C) Copyright 2015-2016 Texas Instruments Incorporated, */ -#include #include +#include #include #include diff --git a/arch/arm/mach-keystone/include/mach/mux-k2g.h b/arch/arm/mach-keystone/include/mach/mux-k2g.h index 67d47f81721..dfb5ad43506 100644 --- a/arch/arm/mach-keystone/include/mach/mux-k2g.h +++ b/arch/arm/mach-keystone/include/mach/mux-k2g.h @@ -9,7 +9,6 @@ #ifndef __ASM_ARCH_MUX_K2G_H #define __ASM_ARCH_MUX_K2G_H -#include #include #define K2G_PADCFG_REG (KS2_DEVICE_STATE_CTRL_BASE + 0x1000) diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c index 1954e69e9f0..39afaaa63d6 100644 --- a/arch/arm/mach-keystone/init.c +++ b/arch/arm/mach-keystone/init.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include #include #include diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c index efaabca5a7e..8846df3af48 100644 --- a/arch/arm/mach-keystone/keystone.c +++ b/arch/arm/mach-keystone/keystone.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include #include #include diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c index e91b0d68f4d..b945e19ec77 100644 --- a/arch/arm/mach-keystone/mon.c +++ b/arch/arm/mach-keystone/mon.c @@ -8,7 +8,6 @@ #include #include #include -#include #include #include #include diff --git a/arch/arm/mach-keystone/msmc.c b/arch/arm/mach-keystone/msmc.c index f5cadfbf669..a20e0c98865 100644 --- a/arch/arm/mach-keystone/msmc.c +++ b/arch/arm/mach-keystone/msmc.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include struct mpax { diff --git a/arch/arm/mach-keystone/psc.c b/arch/arm/mach-keystone/psc.c index 145aff8ac66..84d64f3bc40 100644 --- a/arch/arm/mach-keystone/psc.c +++ b/arch/arm/mach-keystone/psc.c @@ -6,7 +6,6 @@ * Texas Instruments Incorporated, */ -#include #include #include #include -- 2.39.2
Re: [PATCH 2/3] configs: keystone2: Do not include hardware.h
On Fri, Nov 17, 2023 at 04:38:28PM -0600, Andrew Davis wrote: > This is a hacky way to have this file included in all source files that > include common.h, instead just include from the files that need it. > > Signed-off-by: Andrew Davis > --- > drivers/memory/ti-aemif.c| 1 + > drivers/soc/ti/keystone_serdes.c | 1 + > include/configs/ti_armv7_keystone2.h | 1 - > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c > index c4bc88c1510..41325eb0f94 100644 > --- a/drivers/memory/ti-aemif.c > +++ b/drivers/memory/ti-aemif.c > @@ -7,6 +7,7 @@ > */ > > #include > +#include > #include > > #define AEMIF_WAITCYCLE_CONFIG (KS2_AEMIF_CNTRL_BASE + 0x4) > diff --git a/drivers/soc/ti/keystone_serdes.c > b/drivers/soc/ti/keystone_serdes.c > index 2ece1a8f647..0e1bf8ff39d 100644 > --- a/drivers/soc/ti/keystone_serdes.c > +++ b/drivers/soc/ti/keystone_serdes.c > @@ -8,6 +8,7 @@ > > #include > #include > +#include > #include > #include > Is there going to be a follow-up to remove common.h from these files then? Thanks. -- Tom signature.asc Description: PGP signature
[PATCH 1/2] global: Clean up arch/*/dts/Makefile
With commit 3609e1dc ("dts: automatically build necessary .dtb files") we now have logic that will ensure that all device trees needed in the binary are built automatically. Any device tree that the developer needs while working can still be built normally via make arch/.../foo.dtb so we can simply drop the rest of this logic. Suggested-by: Rasmus Villemoes Signed-off-by: Tom Rini --- arch/arc/dts/Makefile|8 - arch/arm/dts/Makefile| 1436 +- arch/m68k/dts/Makefile | 18 - arch/microblaze/dts/Makefile |2 - arch/mips/dts/Makefile | 37 - arch/nios2/dts/Makefile |2 - arch/powerpc/dts/Makefile| 32 - arch/riscv/dts/Makefile |9 - arch/sandbox/dts/Makefile|5 - arch/sh/dts/Makefile |2 +- arch/x86/dts/Makefile| 22 - arch/xtensa/dts/Makefile |2 - configs/iot2050_defconfig|1 + 13 files changed, 6 insertions(+), 1570 deletions(-) diff --git a/arch/arc/dts/Makefile b/arch/arc/dts/Makefile index 532a8131c599..a71db58d48a9 100644 --- a/arch/arc/dts/Makefile +++ b/arch/arc/dts/Makefile @@ -1,13 +1,5 @@ # SPDX-License-Identifier: GPL-2.0+ -dtb-$(CONFIG_TARGET_AXS101) += axs101.dtb -dtb-$(CONFIG_TARGET_AXS103) += axs103.dtb -dtb-$(CONFIG_TARGET_NSIM) += nsim.dtb -dtb-$(CONFIG_TARGET_TB100) += abilis_tb100.dtb -dtb-$(CONFIG_TARGET_EMSDP) += emsdp.dtb -dtb-$(CONFIG_TARGET_HSDK) += hsdk.dtb hsdk-4xd.dtb -dtb-$(CONFIG_TARGET_IOT_DEVKIT) += iot_devkit.dtb - include $(srctree)/scripts/Makefile.dts targets += $(dtb-y) diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index e0a0d430dab8..a8eb6a156eb1 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1,424 +1,11 @@ # SPDX-License-Identifier: GPL-2.0+ -dtb-$(CONFIG_TARGET_SMARTWEB) += at91sam9260-smartweb.dtb -dtb-$(CONFIG_TARGET_TAURUS) += at91sam9g20-taurus.dtb -dtb-$(CONFIG_TARGET_CORVUS) += at91sam9g45-corvus.dtb -dtb-$(CONFIG_TARGET_GURNARD) += at91sam9g45-gurnard.dtb - -dtb-$(CONFIG_TARGET_SMDKC100) += s5pc1xx-smdkc100.dtb -dtb-$(CONFIG_TARGET_S5P_GONI) += s5pc1xx-goni.dtb -dtb-$(CONFIG_ARCH_EXYNOS4) += exynos4210-origen.dtb \ - exynos4210-smdkv310.dtb \ - exynos4210-universal_c210.dtb \ - exynos4210-trats.dtb \ - exynos4412-trats2.dtb \ - exynos4412-odroid.dtb - -dtb-$(CONFIG_TARGET_HIKEY) += hi6220-hikey.dtb -dtb-$(CONFIG_TARGET_HIKEY960) += hi3660-hikey960.dtb - -dtb-$(CONFIG_TARGET_POPLAR) += hi3798cv200-poplar.dtb - -dtb-$(CONFIG_ARCH_EXYNOS5) += exynos5250-arndale.dtb \ - exynos5250-snow.dtb \ - exynos5250-spring.dtb \ - exynos5250-smdk5250.dtb \ - exynos5420-smdk5420.dtb \ - exynos5420-peach-pit.dtb \ - exynos5800-peach-pi.dtb \ - exynos5422-odroidxu3.dtb -dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb -dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb -dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb -dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb - -dtb-$(CONFIG_ARCH_APPLE) += \ - t8103-j274.dtb \ - t8103-j293.dtb \ - t8103-j313.dtb \ - t8103-j456.dtb \ - t8103-j457.dtb - -dtb-$(CONFIG_ARCH_DAVINCI) += \ - da850-evm.dtb \ - da850-lcdk.dtb \ - da850-lego-ev3.dtb - -dtb-$(CONFIG_ARCH_KIRKWOOD) += \ - kirkwood-atl-sbx81lifkw.dtb \ - kirkwood-atl-sbx81lifxcat.dtb \ - kirkwood-blackarmor-nas220.dtb \ - kirkwood-d2net.dtb \ - kirkwood-dns325.dtb \ - kirkwood-dockstar.dtb \ - kirkwood-dreamplug.dtb \ - kirkwood-ds109.dtb \ - kirkwood-goflexnet.dtb \ - kirkwood-guruplug-server-plus.dtb \ - kirkwood-ib62x0.dtb \ - kirkwood-iconnect.dtb \ - kirkwood-is2.dtb \ - kirkwood-lsxhl.dtb \ - kirkwood-lschlv2.dtb \ - kirkwood-net2big.dtb \ - kirkwood-ns2.dtb \ - kirkwood-ns2lite.dtb \ - kirkwood-ns2max.dtb \ - kirkwood-ns2mini.dtb \ - kirkwood-nsa310s.dtb \ - kirkwood-nsa325.dtb \ - kirkwood-openrd-base.dtb \ - kirkwood-openrd-client.dtb \ - kirkwood-openrd-ultimate.dtb \ - kirkwood-pogo_e02.dtb \ - kirkwood-pogoplug-series-4.dtb \ - kirkwood-sheevaplug.dtb - -dtb-$(CONFIG_MACH_S900) += \ - bubblegum_96.dtb -dtb-$(CONFIG_MACH_S700) += \ - s700-cubieboard7.dtb - -dtb-$(CONFIG_ROCKCHIP_PX30) += \ - px30-evb.dtb \ - px30-firefly.dtb \ - px30-engicam-px30-core-ctouch2.dtb \ - px30-engicam-px30-core-ctouch2-of10.dtb \ - px30-engicam-px30-core-edimm2.2.dtb \ - rk3326-odroid-go2.dtb - -dtb-$(CONFIG_ROCKCHIP_RK3036) += \ - rk3036-sdk.dtb - -dtb-$(CONFIG_ROCKCHIP_RK3066) += \ - rk3066a-mk808.dtb - -dtb-$(CONFIG_ROCKCHIP_RK3128) += \ - rk3128-evb.dtb - -dtb-$(CONFIG_ROCKCHIP_RK3188) += \ - rk3188-radxarock.dtb - -dtb-$(CONFIG_ROCKCHIP_RK322X) += \ - rk3229-evb.dtb - -dtb-$(CONFIG_ROCKCHIP_RK3288) += \ -
[PATCH 2/2] doc: Update board_best_practices.rst to talk about dts files
We do need to list device tree overlay files in a Makefile, to ensure they are built. However, everything else should be handled via one of the CONFIG options. Signed-off-by: Tom Rini --- doc/develop/board_best_practices.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst index f44401eab7d4..a5930be10f78 100644 --- a/doc/develop/board_best_practices.rst +++ b/doc/develop/board_best_practices.rst @@ -24,3 +24,7 @@ which are specific to creating a new board port. Kconfig fragments should reside in the board directory itself rather than in the top-level `configs/` directory. + +* A board may list device tree overlay files in `arch/$(ARCH)/dts/Makfile` but + all device trees themselves should be listed in `CONFIG_DEFAULT_DEVICE_TREE` + or `CONFIG_OF_LIST`. -- 2.34.1
[PATCH 2/5] arc: Cleanup and audit usage of
We need to include directly when a file needs to have something such as CFG_SYS_SDRAM_SIZE referenced as this file is not automatically globally included and is most commonly indirectly included via common.h. Remove most cases of arc including config.h directly, but add it where needed. Further clean up the tb100 board config.h file so that we don't rely on config.h being included there for a value used in a single place. Signed-off-by: Tom Rini --- Cc: Alexey Brodkin Cc: Eugeniy Paltsev Cc: uboot-snps-...@synopsys.com --- arch/arc/include/asm/arc-bcr.h | 2 -- arch/arc/include/asm/arcregs.h | 1 - arch/arc/include/asm/cache.h | 2 -- arch/arc/lib/cpu.c | 1 + board/abilis/tb100/tb100.c | 4 include/configs/tb100.h| 21 - 6 files changed, 5 insertions(+), 26 deletions(-) diff --git a/arch/arc/include/asm/arc-bcr.h b/arch/arc/include/asm/arc-bcr.h index 823906d946e4..a6c972bf1e31 100644 --- a/arch/arc/include/asm/arc-bcr.h +++ b/arch/arc/include/asm/arc-bcr.h @@ -13,8 +13,6 @@ #define __ARC_BCR_H #ifndef __ASSEMBLY__ -#include - union bcr_di_cache { struct { #ifdef CONFIG_CPU_BIG_ENDIAN diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h index a9f54f61e0cc..273fb8eed859 100644 --- a/arch/arc/include/asm/arcregs.h +++ b/arch/arc/include/asm/arcregs.h @@ -7,7 +7,6 @@ #define _ASM_ARC_ARCREGS_H #include -#include /* * ARC architecture has additional address space - auxiliary registers. diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h index 74cff716ef60..65dff4214830 100644 --- a/arch/arc/include/asm/cache.h +++ b/arch/arc/include/asm/cache.h @@ -6,8 +6,6 @@ #ifndef __ASM_ARC_CACHE_H #define __ASM_ARC_CACHE_H -#include - /* * As of today we may handle any L1 cache line length right in software. * For that essentially cache line length is a variable not constant. diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c index 803dfd425580..593950449f2e 100644 --- a/arch/arc/lib/cpu.c +++ b/arch/arc/lib/cpu.c @@ -3,6 +3,7 @@ * Copyright (C) 2013-2014, 2018 Synopsys, Inc. All rights reserved. */ +#include #include #include #include diff --git a/board/abilis/tb100/tb100.c b/board/abilis/tb100/tb100.c index 3dc9e14ef8c0..eb7d12908134 100644 --- a/board/abilis/tb100/tb100.c +++ b/board/abilis/tb100/tb100.c @@ -14,6 +14,10 @@ void reset_cpu(void) writel(0x1, (void *)CRM_SWRESET); } +/* + * Ethernet configuration + */ +#define ETH0_BASE_ADDRESS 0xFE10 int board_eth_init(struct bd_info *bis) { if (designware_initialize(ETH0_BASE_ADDRESS, 0) >= 0) diff --git a/include/configs/tb100.h b/include/configs/tb100.h index 1318f5e5ee44..08b6f3219c33 100644 --- a/include/configs/tb100.h +++ b/include/configs/tb100.h @@ -21,25 +21,4 @@ */ #define CFG_SYS_NS16550_CLK1 -/* - * Even though the board houses Realtek RTL8211E PHY - * corresponding PHY driver (drivers/net/phy/realtek.c) behaves unexpectedly. - * In particular "parse_status" reports link is down. - * - * Until Realtek PHY driver is fixed fall back to generic PHY driver - * which implements all required functionality and behaves much more stable. - * - * - */ - -/* - * Ethernet configuration - */ -#define ETH0_BASE_ADDRESS 0xFE10 -#define ETH1_BASE_ADDRESS 0xFE11 - -/* - * Console configuration - */ - #endif /* _CONFIG_TB100_H_ */ -- 2.34.1
[PATCH 1/5] qe: Add to linux/immap_qe.h
Given how we define QE_MURAM_SIZE today, this header needs to have added to it. Signed-off-by: Tom Rini --- include/linux/immap_qe.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/immap_qe.h b/include/linux/immap_qe.h index 45307f51c103..a692f5dfb373 100644 --- a/include/linux/immap_qe.h +++ b/include/linux/immap_qe.h @@ -11,6 +11,8 @@ #ifndef __IMMAP_QE_H__ #define __IMMAP_QE_H__ +#include + #ifdef CONFIG_MPC83xx #if defined(CONFIG_ARCH_MPC8360) #define QE_MURAM_SIZE 0xc000UL -- 2.34.1
[PATCH 3/5] arm: Partial cleanup and audit usage of
We need to include directly when a file needs to have something such as CFG_SYS_SDRAM_SIZE referenced as this file is not automatically globally included and is most commonly indirectly included via common.h. Remove most cases of arm including config.h directly, but add it where needed. This includes a few board-specific fixes. Signed-off-by: Tom Rini --- arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 -- arch/arm/include/asm/arch-ls102xa/fsl_serdes.h| 2 -- arch/arm/include/asm/assembler.h | 1 - arch/arm/include/asm/secure.h | 1 - arch/arm/include/asm/string.h | 2 -- arch/arm/mach-davinci/include/mach/pinmux_defs.h | 1 - arch/arm/mach-exynos/exynos4_setup.h | 1 - arch/arm/mach-exynos/exynos5_setup.h | 1 - arch/arm/mach-k3/common.c | 1 + arch/arm/mach-k3/include/mach/clock.h | 2 -- arch/arm/mach-k3/include/mach/j721e_hardware.h| 1 - arch/arm/mach-k3/include/mach/j721s2_hardware.h | 1 - arch/arm/mach-k3/r5_mpu.c | 1 + board/freescale/ls1088a/eth_ls1088aqds.c | 1 + board/freescale/ls2080aqds/eth.c | 1 + board/toradex/verdin-am62/verdin-am62.c | 1 + drivers/ddr/marvell/axp/ddr3_axp.h| 2 ++ 17 files changed, 7 insertions(+), 15 deletions(-) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h index 8f4365175697..9e29350ca4ba 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h @@ -7,8 +7,6 @@ #ifndef __FSL_SERDES_H__ #define __FSL_SERDES_H__ -#include - #ifdef CONFIG_FSL_LSCH3 enum srds_prtcl { /* diff --git a/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h b/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h index d99a6f318f8b..9244e0a78fd3 100644 --- a/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h +++ b/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h @@ -6,8 +6,6 @@ #ifndef __FSL_SERDES_H #define __FSL_SERDES_H -#include - enum srds_prtcl { /* * Nobody will check whether the device 'NONE' has been configured, diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 8d42ef4823e9..4fda483b8d8d 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -14,7 +14,6 @@ * assembler source. */ -#include #include /* diff --git a/arch/arm/include/asm/secure.h b/arch/arm/include/asm/secure.h index c7b00be8e0b9..abfa46470b2c 100644 --- a/arch/arm/include/asm/secure.h +++ b/arch/arm/include/asm/secure.h @@ -1,7 +1,6 @@ #ifndef __ASM_SECURE_H #define __ASM_SECURE_H -#include #include #define __secure __section("._secure.text") diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h index ead3f2c35643..c9ecdde0d3d8 100644 --- a/arch/arm/include/asm/string.h +++ b/arch/arm/include/asm/string.h @@ -1,8 +1,6 @@ #ifndef __ASM_ARM_STRING_H #define __ASM_ARM_STRING_H -#include - /* * We don't do inline string functions, since the * optimised inline asm versions are not small. diff --git a/arch/arm/mach-davinci/include/mach/pinmux_defs.h b/arch/arm/mach-davinci/include/mach/pinmux_defs.h index 4901ba49c9bb..120935310807 100644 --- a/arch/arm/mach-davinci/include/mach/pinmux_defs.h +++ b/arch/arm/mach-davinci/include/mach/pinmux_defs.h @@ -9,7 +9,6 @@ #define __ASM_ARCH_PINMUX_DEFS_H #include -#include /* SPI0 pin muxer settings */ extern const struct pinmux_config spi0_pins_base[3]; diff --git a/arch/arm/mach-exynos/exynos4_setup.h b/arch/arm/mach-exynos/exynos4_setup.h index fbb45eb897e3..23c9011fbc63 100644 --- a/arch/arm/mach-exynos/exynos4_setup.h +++ b/arch/arm/mach-exynos/exynos4_setup.h @@ -8,7 +8,6 @@ #ifndef _ORIGEN_SETUP_H #define _ORIGEN_SETUP_H -#include #include /* Bus Configuration Register Address */ diff --git a/arch/arm/mach-exynos/exynos5_setup.h b/arch/arm/mach-exynos/exynos5_setup.h index af7a5afb03cd..e9874a8c1b24 100644 --- a/arch/arm/mach-exynos/exynos5_setup.h +++ b/arch/arm/mach-exynos/exynos5_setup.h @@ -8,7 +8,6 @@ #ifndef _SMDK5250_SETUP_H #define _SMDK5250_SETUP_H -#include #include #define NOT_AVAILABLE 0 diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c index eff2fff3c706..2bbdd1077652 100644 --- a/arch/arm/mach-k3/common.c +++ b/arch/arm/mach-k3/common.c @@ -6,6 +6,7 @@ * Lokesh Vutla */ +#include #include #include #include diff --git a/arch/arm/mach-k3/include/mach/clock.h b/arch/arm/mach-k3/include/mach/clock.h index e3adbcd9dedc..850067d5afac 100644 --- a/arch/arm/mach-k3/include/mach/clock.h +++ b/arch/arm/mach-k3/include/mach/clock.h @@ -7,8 +7,6 @@ #ifndef __ASM_ARCH_CLOCK_H #define __ASM_ARCH_CLOCK_H -#include - /* Clock Define