[RFC PATCH] i2c: mvtwsi: reinitialize controller to clear bus errors
Hi I²C maintainers, My target has the following devices sharing one bus: - 24C02 EEPROM - Realtek 8370 Ethernet switch - Allwinner T113-s3 (running U-Boot, interfacing via MVTWSI) The RTL8370 is configured in "EEPROM autoload" mode, so on reset it will load the full contents of the EEPROM. During this sequence, it does an odd move where it sends a re-start, stop, pulses scl low, and then a fresh start. Something about this sequence (I'm betting the scl pulse after stop) upsets the MVTWSI controller, causing it to retreat into state 0x00, which the documentation for my chip names "bus error." I'd guess this is a feature for slave operation: in slave mode, the controller FSM is completely at the mercy of the bus, and so a misbehaving/glitching bus can result in essentially a random walk through the states. Rather than allow that (and risk a potentially dangerous accidental write), the controller goes to a failsafe "bus error" state and remains there, effectively shutting down the whole controller. However, in master mode (which U-Boot uses exclusively), this feature is a nuisance. We do not care what another master was doing on the bus previously, as long as it is in the proper idle state when we want to use it. We also don't care if the bus error was our fault in a previous transaction, since the error would have been reported at that time. I reckon that it makes sense to check for this "bus error" state at the beginning of each new read/write and clear it if detected. Unfortunately, I couldn't find any way to coax the FSM out of the error state just by poking at the control register. It's possible I didn't look hard enough (I'm willing to try other things), but I'm otherwise left with only the obvious way out: a reset. Since that also resets the baud and address registers, I have to save and restore those too. Attached here is my RFC patch (which DOES resolve my problem), for feedback and suggestions on what I might try differently, as I'm not sure whether or not I like this approach: - I would be happier if the code did a fresh init instead of saving and restoring register state, but this driver is plumbed in a way that the config struct isn't readily accessible at the low level. - I don't really like having to duplicate the state check in the read and write functions; is there anything I can do that's more DRY? - Avoiding a reset would be nice, ideally avoiding the "bus error" state altogether by disabling the error detection somehow. Thoughts? Cheers, Sam --- drivers/i2c/mvtwsi.c | 42 ++ 1 file changed, 42 insertions(+) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index d088ea75b9..38a3bdade0 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -142,6 +142,8 @@ enum mvtwsi_ctrl_register_fields { * code. */ enum mvstwsi_status_values { + /* Protocol violation on bus; this is a terminal state */ + MVTWSI_BUS_ERROR= 0x00, /* START condition transmitted */ MVTWSI_STATUS_START = 0x08, /* Repeated START condition transmitted */ @@ -525,6 +527,36 @@ static void __twsi_i2c_init(struct mvtwsi_registers *twsi, int speed, #endif } +/* + * __twsi_i2c_reinit() - Reset and reinitialize the I2C controller. + * + * This function should be called to get the MVTWSI controller out of the + * "bus error" state. It saves and restores the baud and address registers. + * + * @twsi: The MVTWSI register structure to use. + * @tick: The duration of a clock cycle at the current I2C speed. + */ +static void __twsi_i2c_reinit(struct mvtwsi_registers *twsi, uint tick) +{ + uint baud; + uint slaveadd; + + /* Save baud, address registers */ + baud = readl(&twsi->baudrate); + slaveadd = readl(&twsi->slave_address); + + /* Reset controller */ + twsi_reset(twsi); + + /* Restore baud, address registers */ + writel(baud, &twsi->baudrate); + writel(slaveadd, &twsi->slave_address); + writel(0, &twsi->xtnd_slave_addr); + + /* Assert STOP, but don't care for the result */ + (void) twsi_stop(twsi, tick); +} + /* * i2c_begin() - Start a I2C transaction. * @@ -621,6 +653,11 @@ static int __twsi_i2c_read(struct mvtwsi_registers *twsi, uchar chip, int stop_status; int expected_start = MVTWSI_STATUS_START; + /* Check for (and clear) a bus error from a previous failed transaction +* or another master on the same bus */ + if (readl(&twsi->status) == MVTWSI_BUS_ERROR) + __twsi_i2c_reinit(twsi, tick); + if (alen > 0) { /* Begin i2c write to send the address bytes */ status = i2c_begin(twsi, expected_start, (chip << 1), tick); @@ -668,6 +705,11 @@ static int __twsi_i2c_write(struct mvtwsi_registers *twsi, uchar chip, { int status, stop_status; + /* Check for (and clear) a bus error from a previous fai
Re: [PATCH 2/3] drivers: musb-new: add allwinner f1c100s
On Fri, 9 Jun 2023 14:11:53 + 路辉 wrote: Hi, > From fe7d48e84bb3c72d219f37eed51ea766f83b4bec Mon Sep 17 00:00:00 2001 > From: Lu Hui > Date: Fri, 9 Jun 2023 22:05:23 +0800 > Subject: [PATCH 2/3] drivers: musb-new: add allwinner f1c100s configuration thanks for sending this. If this patch should be considered for merging, you need a few lines of commit message, and more importantly your Signed-off-by: line. > --- > drivers/usb/musb-new/sunxi.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c > index dc4cfc2194..1c90739cea 100644 > --- a/drivers/usb/musb-new/sunxi.c > +++ b/drivers/usb/musb-new/sunxi.c > @@ -4,6 +4,7 @@ > * > * Copyright © 2015 Hans de Goede > * Copyright © 2013 Jussi Kivilinna > + * Copyright © 2023 Lu Hui This is not needed, only significant contributions require adding a copyright line. The license is much more important. > * > * Based on the sw_usb "Allwinner OTG Dual Role Controller" code. > * Copyright 2007-2012 (C) Allwinner Technology Co., Ltd. > @@ -519,6 +520,10 @@ static const struct sunxi_musb_config sun8i_h3_cfg = { > .config = &musb_config_h3, > }; > > +static const struct sunxi_musb_config suniv_f1c100s_cfg = { > +.config = &musb_config, > +}; Since is not needed, as it's identical to the A10 structure ... > + > static const struct udevice_id sunxi_musb_ids[] = { > { .compatible = "allwinner,sun4i-a10-musb", > .data = (ulong)&sun4i_a10_cfg }, > @@ -528,6 +533,8 @@ static const struct udevice_id sunxi_musb_ids[] = { > .data = (ulong)&sun6i_a31_cfg }, > { .compatible = "allwinner,sun8i-h3-musb", > .data = (ulong)&sun8i_h3_cfg }, > +{ .compatible = "allwinner,suniv-f1c100s-musb", > +.data = (ulong)&suniv_f1c100s_cfg }, ... which you can just reference here directly. Otherwise this matches the patch I have prepared here as well, I just wanted to test host mode before sending. If you resend this one patch with your Signed-off-by: (instead of Copyright), and using sun4i_a10_cfg, I am happy to take it. Thanks, Andre
Re: [PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode
On Fri, 9 Jun 2023 14:12:31 + 路辉 wrote: Hi, > From fff53ba354c8eca33cb9901888778420db637073 Mon Sep 17 00:00:00 2001 > From: Lu Hui > Date: Fri, 9 Jun 2023 22:05:53 +0800 > Subject: [PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode thanks for sending this, but this snippet was merged into the U-Boot tree just a few days ago: https://source.denx.de/u-boot/u-boot/-/commit/57285737cbae4638112a96e4b3ee78eda6182b6e Cheers, Andre > --- > arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts > b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts > index 43896723a9..0ab6353727 100644 > --- a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts > +++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts > @@ -5,6 +5,7 @@ > > /dts-v1/; > #include "suniv-f1c100s.dtsi" > +#include > > #include > > @@ -71,3 +72,17 @@ > usb0_id_det-gpios = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */ > status = "okay"; > }; > + > +&otg_sram { > +status = "okay"; > +}; > + > +&usb_otg { > +dr_mode = "peripheral"; > +status = "okay"; > +}; > + > +&usbphy { > +usb0_id_det-gpio = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */ > +status = "okay"; > +};
Re: [PATCH v2 0/6] corstone1000: fwu metadata and GPT
On Mon, May 29, 2023 at 03:02:23PM +0100, Rui Miguel Silva wrote: > Now that the nvmxip block driver is merged we can add on top > of it the platform code to use GPT and FWU metadata in the > Corstone1000. > > But first, push 2 fixes that are needed to make all this work: > - move nvmxip header to include > - setup fwu metadata structures as packed (we have a 32bit >writer - Secure enclave Cortex-M0 and a 64bit reader host >Cortex-A35) > > Cheers, > Rui > > v1 [0]-> v2: > Ilias: > - add Reviewed-by tag in patch 1/6 > > Heinrich: > - fix test include nvmxip header after the move to include/ > in patch 2/6 > > [0]: > https://lore.kernel.org/u-boot/20230502131200.2551513-1-rui.si...@linaro.org/ > > Rui Miguel Silva (6): > fwu_metadata: make sure structures are packed This patch leads to build failures now, please rebase on top of current -next, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox
On Wed, 31 May 2023 00:28:04 -0500, jaswinder.si...@linaro.org wrote: > From: Jassi Brar > > Introduce support for mtd backed storage for FWU feature and enable it on > Synquacer platform based DeveloperBox. > > This revision is rebased onto patchset that trims the FWU api > > https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/ > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v6 0/7] fwu: gpt: implement read_mdata and write_mdata callbacks
On Mon, 06 Mar 2023 17:17:47 -0600, jassisinghb...@gmail.com wrote: > From: Jassi Brar > > The patchset reduces ~400 lines of code, while keeping the functionality same > and making > meta-data operations much faster (by using cached structures). > > Issue: > meta-data copies (primary and secondary) are being handled by the > backend/storage layer > instead of the common core in fwu.c (as also noted by Ilias) that is, > gpt_blk.c manages > meta-data and similarly raw_mtd.c will have to do the same when it arrives. > The code > could by make smaller, cleaner and optimised. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration
On Fri, 9 Jun 2023 14:11:07 + 路辉 wrote: Hi, > From 09a85536f92cfd22f2a6feba8ea91fae4bc41ed8 Mon Sep 17 00:00:00 2001 > From: Lu Hui > Date: Fri, 9 Jun 2023 22:04:56 +0800 > Subject: [PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration I sent a similar patch literally just a few hours ago: https://lore.kernel.org/u-boot/20230609105621.1410483-1-andre.przyw...@arm.com/T/ Can you please check whether this works for you as well? My series missed the final MUSB enablement (because I wanted to test host mode first), but at least the PHY part should work. In the future, please add a commit message, describing your patch, and also your Signed-off-by: line, otherwise the patch cannot be merged. Cheers, Andre > > --- > drivers/phy/allwinner/phy-sun4i-usb.c | 14 +- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > b/drivers/phy/allwinner/phy-sun4i-usb.c > index 6428163c18..8425a83c84 100644 > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > @@ -4,6 +4,7 @@ > * Copyright (C) 2017 Jagan Teki > * Copyright (C) 2015 Hans de Goede > * Copyright (C) 2014 Roman Byshko > + * Copyright (C) 2023 Lu Hui > * > * Modelled arch/arm/mach-sunxi/usb_phy.c to compatible with generic-phy. > * > @@ -83,6 +84,7 @@ enum sun4i_usb_phy_type { > sun8i_v3s_phy, > sun50i_a64_phy, > sun50i_h6_phy, > +suniv_f1c100s_phy, > }; > > struct sun4i_usb_phy_cfg { > @@ -372,8 +374,9 @@ static int sun4i_usb_phy_xlate(struct phy *phy, > { > struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev); > > -if (args->args_count >= data->cfg->num_phys) > +if (args->args_count > data->cfg->num_phys) { > return -EINVAL; > +} > > if (data->cfg->missing_phys & BIT(args->args[0])) > return -ENODEV; > @@ -531,6 +534,14 @@ static int sun4i_usb_phy_probe(struct udevice *dev) > return 0; > } > > +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { > +.num_phys = 1, > +.type = suniv_f1c100s_phy, > +.disc_thresh = 3, > +.phyctl_offset = REG_PHYCTL_A10, > +.dedicated_clocks = true, > +}; > + > static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = { > .num_phys = 3, > .type = sun4i_a10_phy, > @@ -659,6 +670,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = { > { .compatible = "allwinner,sun20i-d1-usb-phy", .data = > (ulong)&sun20i_d1_cfg }, > { .compatible = "allwinner,sun50i-a64-usb-phy", .data = > (ulong)&sun50i_a64_cfg}, > { .compatible = "allwinner,sun50i-h6-usb-phy", .data = > (ulong)&sun50i_h6_cfg}, > +{ .compatible = "allwinner,suniv-f1c100s-usb-phy", .data = > (ulong)&suniv_f1c100s_cfg}, > { } > }; >
Re: [PATCH 3/5] sunxi: H616: dram: split struct dram_para
On Fri, 09 Jun 2023 22:26:21 +0200 Jernej Škrabec wrote: Hi, > Dne sreda, 07. junij 2023 ob 02:07:43 CEST je Andre Przywara napisal(a): > > Currently there is one DRAM parameter struct for the Allwinner H616 DRAM > > "driver". It contains many fields that are compile time constants > > (set by Kconfig variables), though there are also some fields that are > > probed and changed over the runtime of the DRAM initialisation. > > > > Because of this mixture, the compiler cannot properly optimise the code > > for size, as it does not consider constant propagation in its full > > potential. > > > > Help the compiler out by splitting that structure into two: one that only > > contains values known at compile time, and another one where the values > > will actually change. The former can then be declared "const", which will > > let the compiler fold its values directly into the code using it. > > > > We also add "const" tags for some new "struct dram_config" pointers, to > > further increase code optimisation. > > To help the compiler optimise the code further, the definition of the > > now "const struct dram_para" has to happen at a file-global level, so > > move that part out of sunxi_dram_init(). > > > > That results in quite some code savings (almost 2KB), and helps to keep > > the code small with the LPDDR3 support added later. > > > > Signed-off-by: Andre Przywara > > Nice trick. It could be used also in other DRAM drivers. You bet ;-) I have a patch for the H6 already. It doesn't save as much there (merely 500 bytes), I guess because we don't have as many build time parameters, but the H6 SPL is very big, so every byte saved there is a win. Will post this ASAP. > Reviewed-by: Jernej Skrabec Many thanks for that! Cheers, Andre
Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support
Hi Andre, On 12/5/22 17:45, Andre Przywara wrote: Please let me know if you have any opinions! I believe I promised you last month I'd let you know once I had a build I'm happy with, and I'm pleased to say that I think I've reached that point. I'm running quite rapidly out of sharp edges to sand down, too. I have a build of U-Boot for my target, complete with: - UART3 initialized correctly - DRAM coming up correctly - SPL sets configured boot clock correctly - SPI-NAND support (SPL and U-Boot proper) - MMC support (SPL and U-Boot proper) - SPL boot from FEL - USB gadget support - Ethernet MAC+PHY support - I²C support * - GPIO support (LEDs, buttons, misc. board management) - `reset` working (requries CONFIG_SYSRESET unset, WDT key) - PSCI, nonsec - Able to boot Linux ;) * Requires nonzero `MVTWSI_CONTROL_CLEAR_IFLG` for NCAT2, and a patch to the pinctrl driver to configure the proper mux function for my necessary pins. I figured I'd share this list as a sort of checklist for your own work, too. The remainder of my efforts now will probably be focused on mainlining this stuff (let me know how else I can be of help), and then I'm afraid I'll have to disappear back downstream to the Turing Pi 2 development effort, but maybe our paths will cross again in the kernel lists. :) Thank you greatly, Sam P.S. I figure the reason there aren't I²C function defs in the d1 pinctrl table already is because Allwinner tends to kick around the I²C mux values a lot and we would need a per-pin lookup table that would eat up too much valuable image space? In an entirely JUST FOR FUN exercise to give myself a break from staring at datasheets/patches and do a "pure CS" coding challenge for a change, I came up with a terse encoding scheme for this table. Here is the size (in bits) for a selection of D1's functions (pin assignments harvested from Linux): 'emac': 50, 'i2c0': 101, 'i2c1': 64, 'i2c2': 109, 'i2c3': 91, 'mmc0': 23, 'mmc1': 23, 'mmc2': 20, 'spi0': 41, 'spi1': 48, 'uart0': 78, 'uart1': 87, 'uart2': 88, 'uart3': 102, 'uart4': 68, 'uart5': 66, ...and yes, it also identifies invalid pin assignments! I'd be willing to contribute something like this if there's big interest, but I figure needing to compress this at build-time might be a bit too complicated for the U-Boot project's liking.
[PATCH v2 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization
This is largely a cosmetic change, with one functional distinction: We are now only setting BIT(0), and no longer clearing BIT(1). The A20 manual confirms the purpose and bitwidth of this field, and we have also been doing it this way for a while in Linux-land: The prior narrative about this initialization being about configuring a FIFO has pretty much been debunked for years now. This cleanup also adds a TODO comment about runtime discovery of the SYSCON base, per discussion with Andre. Signed-off-by: Sam Edwards Cc: Andre Przywara --- drivers/usb/musb-new/sunxi.c | 38 +++- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index a67eaf..be7faaa11e 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -171,15 +171,29 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base) musb_writel(base, USBC_REG_o_ISCR, reg_val); } -static void USBC_ConfigFIFO_Base(void) -{ - u32 reg_value; +/** + * Non-USBC register access needed for initialization + **/ - /* config usb fifo, 8kb mode */ - reg_value = readl(SUNXI_SRAMC_BASE + 0x04); - reg_value &= ~(0x03 << 0); - reg_value |= BIT(0); - writel(reg_value, SUNXI_SRAMC_BASE + 0x04); +/* + * A10(s), A13, GR8, A20: + * switch ownership of SRAM block 'D' to the USB-OTG controller + */ +static void sunxi_musb_claim_sram(void) +{ + /* +* TODO: Do not use hardcoded SUNXI_SRAMC_BASE; find the syscon base by +* traversing this OTG device's `allwinner,sram` FDT property and +* working upward to the system controller. +*/ + void *syscon_base = (void *)SUNXI_SRAMC_BASE; + + /* +* BIT(0) of SRAM_CTRL_REG1 (syscon+0x04) controls SRAM-D ownership: +* '0' -> exclusive access by CPU +* '1' -> exclusive access by USB0 +*/ + setbits_le32(syscon_base + 0x04, BIT(0)); } /** @@ -313,7 +327,13 @@ static int sunxi_musb_init(struct musb *musb) musb->isr = sunxi_musb_interrupt; if (glue->cfg->has_sram) { - USBC_ConfigFIFO_Base(); + /* +* This is an older USB-OTG controller that Allwinner did not +* endow with a dedicated SRAM block; it instead uses SRAM +* block 'D', ownership of which needs to be handed over by +* the CPU +*/ + sunxi_musb_claim_sram(); } USBC_EnableDpDmPullUp(musb->mregs); -- 2.39.2
[PATCH v2 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary
Only the older (ca. A10, A20) sunxis need this poke for the MUSB to function. Mimic the Linux kernel and add a `has_sram` flag to the config structure that is only set for the specific compatibles that require this initialization. Signed-off-by: Sam Edwards Reviewed-by: Andre Przywara Tested-by: Andre Przywara --- drivers/usb/musb-new/sunxi.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index c5c63249aa..a67eaf 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -83,6 +83,7 @@ struct sunxi_musb_config { struct musb_hdrc_config *config; + bool has_sram; }; struct sunxi_glue { @@ -311,7 +312,10 @@ static int sunxi_musb_init(struct musb *musb) musb->isr = sunxi_musb_interrupt; - USBC_ConfigFIFO_Base(); + if (glue->cfg->has_sram) { + USBC_ConfigFIFO_Base(); + } + USBC_EnableDpDmPullUp(musb->mregs); USBC_EnableIdPullUp(musb->mregs); @@ -517,6 +521,7 @@ static int musb_usb_remove(struct udevice *dev) static const struct sunxi_musb_config sun4i_a10_cfg = { .config = &musb_config, + .has_sram = true, }; static const struct sunxi_musb_config sun6i_a31_cfg = { -- 2.39.2
[PATCH v2 0/2] sunxi, usb: Clean up SRAM initialization code
Hi list, This is the second version of cleaning up the SRAM initialization code in the musb-new variant for sunxis. Patch 1 ("only perform ... when necessary") has not changed since v1. Patch 2 has had the following changes: - Remove one-off bit/reg #defines, per feedback from Andre. - Switch to the Linux multiline comment style, per feedback from Andre. - Reword the commit message, since this change isn't as "speculative" as I had originally thought. - Perhaps controversially, introduce a `void *syscon_base;` under that TODO comment I mentioned before, to further invite somebody to "DO" it. :) Thank you once again for your continued efforts, Sam Sam Edwards (2): usb: musb-new: sunxi: only perform SRAM initialization when necessary usb: musb-new: sunxi: clarify the purpose of SRAM initialization drivers/usb/musb-new/sunxi.c | 43 1 file changed, 34 insertions(+), 9 deletions(-) -- 2.39.2
Re: [PATCH 5/5] sunxi: H616: add LPDDR3 DRAM support
On Fri, 09 Jun 2023 22:38:38 +0200 Jernej Škrabec wrote: Hi, > Dne sreda, 07. junij 2023 ob 02:07:45 CEST je Andre Przywara napisal(a): > > From: iuncuim > > > > The H616 SoC has support for several types of DRAM: DDR3, LPDDR3, > > DDR4 and LPDDR4. > > At the moment, the driver only supports DDR3 memory. > > Let's extend the driver to support the LPDDR3 memory. All "magic" > > values obtained from the boot0. > > --- > > arch/arm/mach-sunxi/Kconfig | 8 + > > arch/arm/mach-sunxi/dram_sun50i_h616.c| 193 +- > > arch/arm/mach-sunxi/dram_timings/Makefile | 1 + > > .../arm/mach-sunxi/dram_timings/h616_lpddr3.c | 95 + > > 4 files changed, 242 insertions(+), 55 deletions(-) > > create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c > > > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > > index 197d77ea658..5ce82a955c6 100644 > > --- a/arch/arm/mach-sunxi/Kconfig > > +++ b/arch/arm/mach-sunxi/Kconfig > > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333 > > This option is the DDR3 timing used by the boot0 on H6 TV boxes > > which use a DDR3-1333 timing. > > > > +config SUNXI_DRAM_H616_LPDDR3 > > + bool "LPDDR3 DRAM chips on the H616 DRAM controller" > > + select SUNXI_DRAM_LPDDR3 > > + depends on DRAM_SUN50I_H616 > > + ---help--- > > + This option is the LPDDR3 timing used by the stock boot0 by > > + Allwinner. > > + > > config SUNXI_DRAM_H616_DDR3_1333 > > bool "DDR3-1333 boot0 timings on the H616 DRAM controller" > > select SUNXI_DRAM_DDR3 > > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > > b/arch/arm/mach-sunxi/dram_sun50i_h616.c > > index 4e988cebf59..082746ea7f3 100644 > > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > > @@ -228,10 +228,17 @@ static void mctl_set_addrmap(const struct dram_config > > *config) > > } > > > > static const u8 phy_init[] = { > > +#ifdef CONFIG_SUNXI_DRAM_H616_DDR3_1333 > > 0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19, > > 0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06, > > 0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08, > > 0x09, 0x05, 0x18 > > +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR3) > > + 0x18, 0x06, 0x00, 0x05, 0x04, 0x03, 0x09, 0x02, > > + 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, > > + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07, > > + 0x17, 0x19, 0x1a > > +#endif > > }; > > > > static void mctl_phy_configure_odt(const struct dram_para *para) > > @@ -263,19 +270,31 @@ static void mctl_phy_configure_odt(const struct > > dram_para *para) > > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c); > > > > val = para->dx_odt & 0x1f; > > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380); > > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380); > > + else > > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380); > > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384); > > > > val = (para->dx_odt >> 8) & 0x1f; > > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0); > > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0); > > + else > > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0); > > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4); > > > > val = (para->dx_odt >> 16) & 0x1f; > > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400); > > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400); > > + else > > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400); > > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404); > > > > val = (para->dx_odt >> 24) & 0x1f; > > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440); > > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440); > > + else > > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440); > > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444); > > Above dx_odt oriented changes are not needed. They depend on Kconfig symbol, > which can simply be set to 0. Ha, I thought so as well, but if you look closely, it's only *one* of the two writes which turn to zero, the other register stays at the Kconfig value. Annoying, I know ;-) I couldn't think of a shorter or even cleaner way to express this, really, apart from a macro maybe, so I guess we have to live with it. Cheers, Andre > I didn't do detailed check, but if it works, it should be ok. Were calculated > values here compared to vendor driver? > > Best regards, > Jernej > > > > > dmb(); > > @@ -794,31 +813,47 @@ static void mctl_phy_ca_bit_delay_compensation(const > > struct dram_para *para, > > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0); > > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4); > > > > - /* fo
Re: [PATCH 3/3] sunxi: Kconfig: rework PHY_USB_SUN4I selection
Dne petek, 09. junij 2023 ob 12:56:21 CEST je Andre Przywara napisal(a): > At the moment we use "select" in each Allwinner SoC's Kconfig section to > include the USB PHY driver in the build. This means it cannot be disabled > via Kconfig, although USB is not really a strictly required core > functionality, and a particular board might not even include USB ports. > > Rework the Kconfig part by removing the "select" lines for each SoC's > section, and instead letting it default to "y" in the PHY driver section > itself. We use "depends on !" to exclude the few SoCs we don't support > (yet). The Allwinner V3s does not enable USB (PHY) support at the moment, > even though it should work: let the PHY default to "n" to keep the > current behaviour. > > Signed-off-by: Andre Przywara I stumbled on this issue before, but it didn't bother me enough to actually do something about that. Thanks! Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 2/3] phy: sun4i-usb: add Allwinner F1C100s support
Dne petek, 09. junij 2023 ob 12:56:20 CEST je Andre Przywara napisal(a): > The Allwinner F1C100s implements a single USB PHY, connected to its MUSB > OTG controller. The USB PHY is of the simpler, older type (like the A10), > the only real difference is that it's indeed only one PHY. > > Add a struct describing those F1C100s USB PHY properties, and connect it > to the new compatible string. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 1/3] phy: sun4i-usb: Fix of_xlate() argument check
Dne petek, 09. junij 2023 ob 12:56:19 CEST je Andre Przywara napisal(a): > In its of_xlate() function, the Allwinner USB PHY driver compares the > args_count variable against the number of implemented USB PHYs, although > this is the *number of arguments* to the DT phandle property. Per the DT > binding for this PHY device, this number is always one, so this check > will always fail if the particular SoC implements exactly one USB PHY. > So far this affected only the V3s (which has USB support disabled), but > the F1C100s also sports one PHY only. > > Fix that check to compare args_count against exactly 1, and the args[0] > content (requested PHY number) against the number of implemented PHYs. > > This fixes USB operation on the Allwinner V3s and allows to enable USB > on the Allwinner F1C100s SoC. > > Signed-off-by: Andre Przywara Nice catch! Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 5/5] sunxi: H616: add LPDDR3 DRAM support
Dne sreda, 07. junij 2023 ob 02:07:45 CEST je Andre Przywara napisal(a): > From: iuncuim > > The H616 SoC has support for several types of DRAM: DDR3, LPDDR3, > DDR4 and LPDDR4. > At the moment, the driver only supports DDR3 memory. > Let's extend the driver to support the LPDDR3 memory. All "magic" > values obtained from the boot0. > --- > arch/arm/mach-sunxi/Kconfig | 8 + > arch/arm/mach-sunxi/dram_sun50i_h616.c| 193 +- > arch/arm/mach-sunxi/dram_timings/Makefile | 1 + > .../arm/mach-sunxi/dram_timings/h616_lpddr3.c | 95 + > 4 files changed, 242 insertions(+), 55 deletions(-) > create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 197d77ea658..5ce82a955c6 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333 > This option is the DDR3 timing used by the boot0 on H6 TV boxes > which use a DDR3-1333 timing. > > +config SUNXI_DRAM_H616_LPDDR3 > + bool "LPDDR3 DRAM chips on the H616 DRAM controller" > + select SUNXI_DRAM_LPDDR3 > + depends on DRAM_SUN50I_H616 > + ---help--- > + This option is the LPDDR3 timing used by the stock boot0 by > + Allwinner. > + > config SUNXI_DRAM_H616_DDR3_1333 > bool "DDR3-1333 boot0 timings on the H616 DRAM controller" > select SUNXI_DRAM_DDR3 > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > b/arch/arm/mach-sunxi/dram_sun50i_h616.c > index 4e988cebf59..082746ea7f3 100644 > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > @@ -228,10 +228,17 @@ static void mctl_set_addrmap(const struct dram_config > *config) > } > > static const u8 phy_init[] = { > +#ifdef CONFIG_SUNXI_DRAM_H616_DDR3_1333 > 0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19, > 0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06, > 0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08, > 0x09, 0x05, 0x18 > +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR3) > + 0x18, 0x06, 0x00, 0x05, 0x04, 0x03, 0x09, 0x02, > + 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, > + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07, > + 0x17, 0x19, 0x1a > +#endif > }; > > static void mctl_phy_configure_odt(const struct dram_para *para) > @@ -263,19 +270,31 @@ static void mctl_phy_configure_odt(const struct > dram_para *para) > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c); > > val = para->dx_odt & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384); > > val = (para->dx_odt >> 8) & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4); > > val = (para->dx_odt >> 16) & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404); > > val = (para->dx_odt >> 24) & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444); Above dx_odt oriented changes are not needed. They depend on Kconfig symbol, which can simply be set to 0. I didn't do detailed check, but if it works, it should be ok. Were calculated values here compared to vendor driver? Best regards, Jernej > > dmb(); > @@ -794,31 +813,47 @@ static void mctl_phy_ca_bit_delay_compensation(const > struct dram_para *para, > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0); > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4); > > - /* following configuration is DDR3 specific */ > - val = (para->tpr10 >> 7) & 0x1e; > - if (para->tpr2 & 1) { > - writel(val, SUNXI_DRAM_PHY0_BASE + 0x794); > - if (config->ranks == 2) { > - val = (para->tpr10 >> 11) & 0x1e; > - writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e4); > - } > - if (para->tpr0 & BIT(31)) { > - val = (para->tpr0 << 1) & 0x3e; > - writel(val, SUNXI_DRAM_PHY0_BASE
Re: [PATCH 4/5] sunxi: H616: add DRAM type selection
Dne sreda, 07. junij 2023 ob 02:07:44 CEST je Andre Przywara napisal(a): > From: iuncuim > > Allwinner H616 SoC supports several types of DRAM memory. To further > integrate other types of memory, we need to add this delimitation. > --- > arch/arm/mach-sunxi/Kconfig | 10 +- > arch/arm/mach-sunxi/dram_timings/Makefile | 3 +-- > configs/orangepi_zero2_defconfig | 1 + > configs/x96_mate_defconfig| 1 + > 4 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 6dcbb096f74..197d77ea658 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -442,7 +442,7 @@ config ARM_BOOT_HOOK_RMR > This allows both the SPL and the U-Boot proper to be entered in > either mode and switch to AArch64 if needed. > > -if SUNXI_DRAM_DW || DRAM_SUN50I_H6 > +if SUNXI_DRAM_DW || DRAM_SUN50I_H6 || DRAM_SUN50I_H616 > config SUNXI_DRAM_DDR3 > bool > > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333 > This option is the DDR3 timing used by the boot0 on H6 TV boxes > which use a DDR3-1333 timing. > > +config SUNXI_DRAM_H616_DDR3_1333 > + bool "DDR3-1333 boot0 timings on the H616 DRAM controller" > + select SUNXI_DRAM_DDR3 > + depends on DRAM_SUN50I_H616 > + ---help--- > + This option is the DDR3 timing used by the boot0 on H616 TV boxes > + which use a DDR3-1333 timing. I'm always a bit unsure about help part. There is no need for "---", right? I also usually ident help block with extra two spaces. Do we have any rules for that? Apart from that and SoB tag, it looks good. Best regards, Jernej > + > config SUNXI_DRAM_DDR2_V3S > bool "DDR2 found in V3s chip" > select SUNXI_DRAM_DDR2 > diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile > b/arch/arm/mach-sunxi/dram_timings/Makefile > index 39a8756c297..4d78c04c9ae 100644 > --- a/arch/arm/mach-sunxi/dram_timings/Makefile > +++ b/arch/arm/mach-sunxi/dram_timings/Makefile > @@ -3,5 +3,4 @@ obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK) += lpddr3_stock.o > obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)+= ddr2_v3s.o > obj-$(CONFIG_SUNXI_DRAM_H6_LPDDR3) += h6_lpddr3.o > obj-$(CONFIG_SUNXI_DRAM_H6_DDR3_1333)+= h6_ddr3_1333.o > -# currently only DDR3 is supported on H616 > -obj-$(CONFIG_MACH_SUN50I_H616) += h616_ddr3_1333.o > +obj-$(CONFIG_SUNXI_DRAM_H616_DDR3_1333) += h616_ddr3_1333.o > diff --git a/configs/orangepi_zero2_defconfig > b/configs/orangepi_zero2_defconfig > index 6cb942f511a..e38cc20ac72 100644 > --- a/configs/orangepi_zero2_defconfig > +++ b/configs/orangepi_zero2_defconfig > @@ -7,6 +7,7 @@ CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e > CONFIG_DRAM_SUN50I_H616_TPR10=0xf83438 > CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y > CONFIG_R_I2C_ENABLE=y > CONFIG_SPL_SPI_SUNXI=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig > index 122c1a99e32..c86cf43771c 100644 > --- a/configs/x96_mate_defconfig > +++ b/configs/x96_mate_defconfig > @@ -10,6 +10,7 @@ CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007 > CONFIG_DRAM_SUN50I_H616_TPR11=0x > CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557 > CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y > CONFIG_R_I2C_ENABLE=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL_I2C=y >
Re: [PATCH 3/5] sunxi: H616: dram: split struct dram_para
Dne sreda, 07. junij 2023 ob 02:07:43 CEST je Andre Przywara napisal(a): > Currently there is one DRAM parameter struct for the Allwinner H616 DRAM > "driver". It contains many fields that are compile time constants > (set by Kconfig variables), though there are also some fields that are > probed and changed over the runtime of the DRAM initialisation. > > Because of this mixture, the compiler cannot properly optimise the code > for size, as it does not consider constant propagation in its full > potential. > > Help the compiler out by splitting that structure into two: one that only > contains values known at compile time, and another one where the values > will actually change. The former can then be declared "const", which will > let the compiler fold its values directly into the code using it. > > We also add "const" tags for some new "struct dram_config" pointers, to > further increase code optimisation. > To help the compiler optimise the code further, the definition of the > now "const struct dram_para" has to happen at a file-global level, so > move that part out of sunxi_dram_init(). > > That results in quite some code savings (almost 2KB), and helps to keep > the code small with the LPDDR3 support added later. > > Signed-off-by: Andre Przywara Nice trick. It could be used also in other DRAM drivers. Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 2/5] sunxi: H616: dram: const-ify DRAM function parameters
Dne sreda, 07. junij 2023 ob 02:07:42 CEST je Andre Przywara napisal(a): > There are quite some functions in the Allwinner H616 DRAM "driver", some > of them actually change the parameters in the structure passed to them, > but many are actually not. > To increase the optimisation potential for the code, mark those functions > that just read members of the passed dram_para struct as "const". > This in itself does not decrease the code size, but lays the groundwork > for future changes doing so. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 1/5] sunxi: dram: make MBUS configuration functions static
Dne sreda, 07. junij 2023 ob 02:07:41 CEST je Andre Przywara napisal(a): > The usage of the C keyword "inline" seems to be a common > misunderstanding: it's a *hint* only, and modern compilers will inline > (or not) functions based on their own judgement and provided compiler > options. > So while marking functions as "inline" does not do much, missing the > "static" keyword will force to compiler to spell out a version of the > function for potential external callers, which actually increases the > code size (though hopefully the linker will drop the function). > > Change the "inline" attribute for the mbus_configure_port() functions in > some Allwinner DRAM drivers to "static", so that the explicit version > can actually be dropped from the object file, reducing the code size. > > "static inline" has a use case in header files, where it avoids a warning > if a .c file including this header does not use the particular function. > In a .c file itself "static inline" is not useful otherwise, so just use > static here as well. > > Signed-off-by: Andre Przywara Nice catch! Could it be put into common functions? These functions look the same. Anyway: Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > arch/arm/mach-sunxi/dram_sun50i_h6.c | 3 ++- > arch/arm/mach-sunxi/dram_sun50i_h616.c | 2 +- > arch/arm/mach-sunxi/dram_sunxi_dw.c| 18 +- > 3 files changed, 12 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c > b/arch/arm/mach-sunxi/dram_sun50i_h6.c > index b332f3a3e4a..bff2e42513c 100644 > --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c > +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c > @@ -93,7 +93,8 @@ enum { > MBUS_QOS_HIGH, > MBUS_QOS_HIGHEST > }; > -inline void mbus_configure_port(u8 port, > + > +static void mbus_configure_port(u8 port, > bool bwlimit, > bool priority, > u8 qos, > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > b/arch/arm/mach-sunxi/dram_sun50i_h616.c > index 1f9416d6eaf..02f6b2a06d4 100644 > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > @@ -31,7 +31,7 @@ enum { > MBUS_QOS_HIGHEST > }; > > -inline void mbus_configure_port(u8 port, > +static void mbus_configure_port(u8 port, > bool bwlimit, > bool priority, > u8 qos, > diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c > b/arch/arm/mach-sunxi/dram_sunxi_dw.c > index 4af5922f334..9382d3d0be8 100644 > --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c > +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c > @@ -81,15 +81,15 @@ enum { > MBUS_QOS_HIGHEST > }; > > -static inline void mbus_configure_port(u8 port, > -bool bwlimit, > -bool priority, > -u8 qos, /* MBUS_QOS_LOWEST .. > MBUS_QOS_HIGEST */ > -u8 waittime,/* 0 .. 0xf */ > -u8 acs, /* 0 .. 0xff */ > -u16 bwl0, /* 0 .. 0x, > bandwidth limit in MB/s */ > -u16 bwl1, > -u16 bwl2) > +static void mbus_configure_port(u8 port, > + bool bwlimit, > + bool priority, > + u8 qos, /* MBUS_QOS_LOWEST .. > MBUS_QOS_HIGEST */ > + u8 waittime,/* 0 .. 0xf */ > + u8 acs, /* 0 .. 0xff */ > + u16 bwl0, /* 0 .. 0x, bandwidth limit > in MB/s */ > + u16 bwl1, > + u16 bwl2) > { > struct sunxi_mctl_com_reg * const mctl_com = > (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE; >
Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization
On Fri, 9 Jun 2023 13:16:00 -0600 Sam Edwards wrote: Hi Sam, > I've applied most of this feedback (most of which comes as a relief; I > dislike inventing names for mystery bits) in preparation to send a v2, > but had two questions: > > On 6/9/23 04:13, Andre Przywara wrote: > >> The new comments and function name are not from any official source, > >> but are updated to mirror how the Linux kernel sources treat this > >> mystery magic bit. If we wanted to confirm that this speculation is > >> correct, we could verify that SRAM-D is inaccessible whenever the > >> bit is set, and then try clearing it again while the MUSB is in use > >> to see what debris gets left behind in SRAM-D. > >> > >> This cleanup also adds a TODO comment about runtime discovery > >> of the SYSCON base, per discussion with Andre. > > > > thanks for sending this, looks good. Some stylistic comments below. > > I take it that this (in combination with your review on 1/2) means you > concur with my speculated purpose of the mystery bit. If so, I'd like to Oh, but why mystery bit? The A20 manual [1] spells that out: Offset: 0x4 | SRAM_CTRL_REG1 ... Bit 0: R/W, default 0x0: SRAMD_MAP: SRAM D Area Config: 0: map to CPU/DMA 1: map to USB0 So I am afraid you need to rephrase the commit message again ;-) > rephrase the above paragraph in the commit message to: > > """ > The new comments and function name are not from any official source, > but are updated to mirror how the Linux kernel sources treat this > mystery magic bit. This also reflects what's been observed on actual > hardware: SRAM-D is inaccessible by the CPU when the bit is set, and > the MUSB unit crashes when this bit is cleared while USB is in use, > leaving behind debris in SRAM-D from its use as a "scratch space." > """ > > Does this accurately reflect what you've seen, particularly (especially) > that last line, or should I end the commentary at "is in use."? We mostly gave up on finding 100% proof for everything, especially in U-Boot there is more pragmatic approach (check the DRAM controller init code): it if works and the BSP code does it like this, it's good to go. I confirmed that setting this bit before calling "ums" makes the difference between the gadget appearing on the other end or not. I did not turn it off while the gadget was in literal use - which is tricky to pull off anyway, since you don't have a prompt while a gadget is running. So while it's honourable to make sure that this is correct, there is no real need to provide mathematical proof for those bits, especially if they have been working over years now ;-) > > I think we should use "non-net" commenting style, with the "/*" on a line > > on its own. > > This seems to be an obscure term of art, and searching "non-net comment" > and "non-net style" on Google isn't finding me any style guide or set of > rules to check against. (Amusingly: if I search for the "net" style, I > get a lot of .NET suggestions.) Ah, sorry, I somewhat made this term up, apparently in a non-Google compatible way ;-) The Linux kernel recommends this "/* on a line of its own" commenting style, but inside the net/ folder the rules are slightly different: https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting Hope that helps! Cheers, Andre > The main thing I'm trying to figure out is if it also demands */ on its > own line, which I would intuitively think makes sense (it does look > better to me that way), but I'm unsure if your lack of critique at the > closing side of my multiline comments means you would prefer: > /* > * A block of text that's long enough to become a > * multiline comment and ends up looking like this */ > > Thanks for your quick and thorough feedback, > Sam
Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization
Hi Andre, I've applied most of this feedback (most of which comes as a relief; I dislike inventing names for mystery bits) in preparation to send a v2, but had two questions: On 6/9/23 04:13, Andre Przywara wrote: The new comments and function name are not from any official source, but are updated to mirror how the Linux kernel sources treat this mystery magic bit. If we wanted to confirm that this speculation is correct, we could verify that SRAM-D is inaccessible whenever the bit is set, and then try clearing it again while the MUSB is in use to see what debris gets left behind in SRAM-D. This cleanup also adds a TODO comment about runtime discovery of the SYSCON base, per discussion with Andre. thanks for sending this, looks good. Some stylistic comments below. I take it that this (in combination with your review on 1/2) means you concur with my speculated purpose of the mystery bit. If so, I'd like to rephrase the above paragraph in the commit message to: """ The new comments and function name are not from any official source, but are updated to mirror how the Linux kernel sources treat this mystery magic bit. This also reflects what's been observed on actual hardware: SRAM-D is inaccessible by the CPU when the bit is set, and the MUSB unit crashes when this bit is cleared while USB is in use, leaving behind debris in SRAM-D from its use as a "scratch space." """ Does this accurately reflect what you've seen, particularly (especially) that last line, or should I end the commentary at "is in use."? I think we should use "non-net" commenting style, with the "/*" on a line on its own. This seems to be an obscure term of art, and searching "non-net comment" and "non-net style" on Google isn't finding me any style guide or set of rules to check against. (Amusingly: if I search for the "net" style, I get a lot of .NET suggestions.) The main thing I'm trying to figure out is if it also demands */ on its own line, which I would intuitively think makes sense (it does look better to me that way), but I'm unsure if your lack of critique at the closing side of my multiline comments means you would prefer: /* * A block of text that's long enough to become a * multiline comment and ends up looking like this */ Thanks for your quick and thorough feedback, Sam
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
Sorry, I replied to Marek only but meant to reply to all. El Fri, Jun 09, 2023 at 03:20:33AM +0200, Marek Vasut deia: > > No. Well, in some tests yes and some no, but I got the error in all cases. > > This is doubtful. It is mandatory to run 'usb start' or 'usb reset' before > you would get any meaningful result out of 'usb info'. Without either, you > would get 'USB is stopped.' message. Could it be there are some extra > scripts in your environment that manipulate the USB ? > I saw usb_boootdev_hunt() calls usb_init() in drivers/usb/host/usb_bootdev.c But maybe I don't get that called and it's really something silly in my setup as you say later... Maybe it doesn't get called unless it finds nothing else useful to boot. > > Can you test with stock U-Boot ? > I don't know. I'll see if I have time ... I'd rather read the code to understand what's the condition for finding bootdevices... > Can you test with another USB stick, i.e. is the issue specific to this USB > stick ? > I could test this, yes. > Is the issue specific to this partition layout of this USB stick, i.e. if > you clone (dd if=... of=...) the content of the USB stick to another USB > stick, does the error still occur. > I'll try to partition and flash a new USB. > [...] > > > Model: Radxa ROCK Pi 4B > > Net: eth0: ethernet@fe30 > > Hit any key to stop autoboot: 2 1 0 > > rockchip_pcie pcie@f800: PCIe link training gen1 timeout! > > Bus usb@fe38: USB EHCI 1.00 > > Bus usb@fe3c: USB EHCI 1.00 > > Bus usb@fe80: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > Bus usb@fe90: Register 2000140 NbrPorts 2 > > Starting the controller > > USB XHCI 1.10 > > scanning bus usb@fe38 for devices... 1 USB Device(s) found > > scanning bus usb@fe3c for devices... 2 USB Device(s) found > > scanning bus usb@fe80 for devices... 1 USB Device(s) found > > scanning bus usb@fe90 for devices... 1 USB Device(s) found > > rockchip_pcie pcie@f800: failed to find ep-gpios property > > ethernet@fe30 Waiting for PHY auto negotiation to complete. > > TIMEOUT ! > > Could not initialize PHY ethernet@fe30 > > rockchip_pcie pcie@f800: failed to find ep-gpios property > > ethernet@fe30 Waiting for PHY auto negotiation to complete. > > TIMEOUT ! > > Could not initialize PHY ethernet@fe30 > > Is this some $preboot script which initializes your hardware ? > Mmm... yes, I used to have it... I thought not in this test, but I'd better recheck Anyway, one should be allowed to stop the boot, call usb start and usb tree and don't get a reset, shouldn't one? > => printenv preboot > I'll send this later when I repeat the test. I'd like to find a minimal test case or something... > > => usb tree > > USB device tree: > >1 Hub (480 Mb/s, 0mA) > > u-boot EHCI Host Controller > >1 Hub (480 Mb/s, 0mA) > >| u-boot EHCI Host Controller > >| > > uclass_id=64 > >|+-2 Mass Storage (480 Mb/s, 200mA) > > TDK LoR TF10 07032B6B1D0ACB96 > > uclass_id=22 > > uclass_id=25 > > "Synchronous Abort" handler, esr 0x9610, far 0x948 > > elr: 002157d4 lr : 002157d4 (reloc) > > elr: f3f4f7d4 lr : f3f4f7d4 > > Take the u-boot (unstripped elf) which matches this binary, and run > aarch64-...objdump -lSD on it, then search for the $lr value, see > doc/develop/crash_dumps.rst for details. That should tell you where exactly > the crash occurred. Where did it occur ? > I didn't do it exactly so, but from u-boot.map I gathered that it was in cmd/usb.c and the fact that my patch fixed it implies the problem is the functions usb_show_tree_graph() or usb_show_info() get called recursively with null as a first parameter. Now I don't have that u-boot.map anymore and would have to repeat the experiment, to find out exactly as you say, so I won't do it right now. But thanks, understood. The reason usb_show_tree_graph() gets called with a null usb_device * is that the code in cmd/usb.c for usb info and usb tree assumes everything a UCLASS_MASS_STORAGE device can have as children are devices with some usb_device in their dev_get_parent_priv(). It carves out exceptions to this general rule for UCLASS_USB_EMUL and UCLASS_BLK, but not for UCLASS_BOOTDEV. When it finds a child that is UCLASS_BOOTDEV it happily recurses on it passing its parent_priv as usb_device, but the bootdev code did not put any usb_device there, it's null. So the first access causes a null pointer dereference. I would have to wrap my mind around more code to start understanding if it's better to give that UCLASS_BOOTDEV some usb_device as parent priv data, or it is better to give USB devices that can be enumerated for listing (usb tree or usb info) some RECURSIBLE flag that indicates their priv parent data is reliably a usb_device. So checking that the alledged usb_de
Re: [PULL] u-boot-usb/master
On Fri, Jun 09, 2023 at 12:03:06AM +0200, Marek Vasut wrote: > The following changes since commit 0a8a4b86422650d6955a2382796089735453902d: > > Merge tag 'u-boot-amlogic-20230607' of > https://source.denx.de/u-boot/custodians/u-boot-amlogic (2023-06-07 12:17:06 > -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to e10f96414934edaca958e4323f82149a030e56a4: > > usb: musb-new: sunxi: remove unused define (2023-06-08 21:57:01 +0200) > I see I replied to the SH one twice, oops. This has been applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] sunxi: H616: add LPDDR3 DRAM support
Signed-off-by: Mikhail Kalashnikov From: iuncuim > > The H616 SoC has support for several types of DRAM: DDR3, LPDDR3, > DDR4 and LPDDR4. > At the moment, the driver only supports DDR3 memory. > Let's extend the driver to support the LPDDR3 memory. All "magic" > values obtained from the boot0. > --- > .../include/asm/arch-sunxi/dram_sun50i_h616.h | 1 + > arch/arm/mach-sunxi/Kconfig | 10 +- > arch/arm/mach-sunxi/dram_sun50i_h616.c| 215 -- > arch/arm/mach-sunxi/dram_timings/Makefile | 1 + > .../arm/mach-sunxi/dram_timings/h616_lpddr3.c | 95 > 5 files changed, 255 insertions(+), 67 deletions(-) > create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c > > diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > index 6db869c098..bf4188fa89 100644 > --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h > @@ -148,6 +148,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240); > struct dram_para { > u32 clk; > enum sunxi_dram_type type; > + u8 phy_init[27]; > u8 cols; > u8 rows; > u8 ranks; > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 3ad37ef6ba..5ce82a955c 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333 > This option is the DDR3 timing used by the boot0 on H6 TV boxes > which use a DDR3-1333 timing. > > +config SUNXI_DRAM_H616_LPDDR3 > + bool "LPDDR3 DRAM chips on the H616 DRAM controller" > + select SUNXI_DRAM_LPDDR3 > + depends on DRAM_SUN50I_H616 > + ---help--- > + This option is the LPDDR3 timing used by the stock boot0 by > + Allwinner. > + > config SUNXI_DRAM_H616_DDR3_1333 > bool "DDR3-1333 boot0 timings on the H616 DRAM controller" > select SUNXI_DRAM_DDR3 > @@ -1083,4 +1091,4 @@ config CHIP_DIP_SCAN > select W1_GPIO > select W1_EEPROM > select W1_EEPROM_DS24XXX > - select CMD_EXTENSION > \ No newline at end of file > + select CMD_EXTENSION > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c > b/arch/arm/mach-sunxi/dram_sun50i_h616.c > index 1f9416d6ea..d34b218ee5 100644 > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c > @@ -227,13 +227,6 @@ static void mctl_set_addrmap(struct dram_para *para) > mctl_ctl->addrmap[8] = 0x3F3F; > } > > -static const u8 phy_init[] = { > - 0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19, > - 0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06, > - 0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08, > - 0x09, 0x05, 0x18 > -}; > - > static void mctl_phy_configure_odt(struct dram_para *para) > { > unsigned int val; > @@ -263,19 +256,31 @@ static void mctl_phy_configure_odt(struct dram_para > *para) > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c); > > val = para->dx_odt & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384); > > val = (para->dx_odt >> 8) & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4); > > val = (para->dx_odt >> 16) & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404); > > val = (para->dx_odt >> 24) & 0x1f; > - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440); > + if (para->type == SUNXI_DRAM_TYPE_LPDDR3) > + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440); > + else > + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440); > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444); > > dmb(); > @@ -793,31 +798,47 @@ static void > mctl_phy_ca_bit_delay_compensation(struct dram_para *para) > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0); > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4); > > - /* following configuration is DDR3 specific */ > - val = (para->tpr10 >> 7) & 0x1e; > - if (para->tpr2 & 1) { > - writel(val, SUNXI_DRAM_PHY0_BASE + 0x794); > -
Re: [PATCH 1/2] sunxi: H616: add DRAM type selection
Signed-off-by: Mikhail Kalashnikov сб, 3 июн. 2023 г. в 16:55, Mikhail Kalashnikov : > From: iuncuim > > Allwinner H616 SoC supports several types of DRAM memory. To further > integrate other types of memory, we need to add this delimitation. > --- > arch/arm/mach-sunxi/Kconfig | 12 ++-- > arch/arm/mach-sunxi/dram_timings/Makefile | 3 +-- > configs/orangepi_zero2_defconfig | 1 + > configs/x96_mate_defconfig| 1 + > 4 files changed, 13 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 6dcbb096f7..3ad37ef6ba 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -442,7 +442,7 @@ config ARM_BOOT_HOOK_RMR > This allows both the SPL and the U-Boot proper to be entered in > either mode and switch to AArch64 if needed. > > -if SUNXI_DRAM_DW || DRAM_SUN50I_H6 > +if SUNXI_DRAM_DW || DRAM_SUN50I_H6 || DRAM_SUN50I_H616 > config SUNXI_DRAM_DDR3 > bool > > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333 > This option is the DDR3 timing used by the boot0 on H6 TV boxes > which use a DDR3-1333 timing. > > +config SUNXI_DRAM_H616_DDR3_1333 > + bool "DDR3-1333 boot0 timings on the H616 DRAM controller" > + select SUNXI_DRAM_DDR3 > + depends on DRAM_SUN50I_H616 > + ---help--- > + This option is the DDR3 timing used by the boot0 on H616 TV boxes > + which use a DDR3-1333 timing. > + > config SUNXI_DRAM_DDR2_V3S > bool "DDR2 found in V3s chip" > select SUNXI_DRAM_DDR2 > @@ -1075,4 +1083,4 @@ config CHIP_DIP_SCAN > select W1_GPIO > select W1_EEPROM > select W1_EEPROM_DS24XXX > - select CMD_EXTENSION > + select CMD_EXTENSION > \ No newline at end of file > diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile > b/arch/arm/mach-sunxi/dram_timings/Makefile > index 39a8756c29..4d78c04c9a 100644 > --- a/arch/arm/mach-sunxi/dram_timings/Makefile > +++ b/arch/arm/mach-sunxi/dram_timings/Makefile > @@ -3,5 +3,4 @@ obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK) += lpddr3_stock.o > obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S) += ddr2_v3s.o > obj-$(CONFIG_SUNXI_DRAM_H6_LPDDR3) += h6_lpddr3.o > obj-$(CONFIG_SUNXI_DRAM_H6_DDR3_1333) += h6_ddr3_1333.o > -# currently only DDR3 is supported on H616 > -obj-$(CONFIG_MACH_SUN50I_H616) += h616_ddr3_1333.o > +obj-$(CONFIG_SUNXI_DRAM_H616_DDR3_1333)+= h616_ddr3_1333.o > diff --git a/configs/orangepi_zero2_defconfig > b/configs/orangepi_zero2_defconfig > index 6cb942f511..e38cc20ac7 100644 > --- a/configs/orangepi_zero2_defconfig > +++ b/configs/orangepi_zero2_defconfig > @@ -7,6 +7,7 @@ CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e > CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e > CONFIG_DRAM_SUN50I_H616_TPR10=0xf83438 > CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y > CONFIG_R_I2C_ENABLE=y > CONFIG_SPL_SPI_SUNXI=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig > index aedb327702..2a326bf202 100644 > --- a/configs/x96_mate_defconfig > +++ b/configs/x96_mate_defconfig > @@ -11,6 +11,7 @@ CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007 > CONFIG_DRAM_SUN50I_H616_TPR11=0x > CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557 > CONFIG_MACH_SUN50I_H616=y > +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y > CONFIG_R_I2C_ENABLE=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL_I2C=y > -- > 2.40.1 > >
[PATCH v2] phy: phy-imx8mq-usb: add vbus regulator support
Add support for enabling and disabling vbus-supply regulator found on several imx8mp boards in the usb3_phy0 and usb3_phy1 nodes. Signed-off-by: Tim Harvey Reviewed-by: Adam Ford --- v2: - protect ret with __maybe_unused in case CONFIG_CLK and CONFIG_DM_REGULATOR not defined - add error prints on failures - add Adam's rb tag --- drivers/phy/phy-imx8mq-usb.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/phy/phy-imx8mq-usb.c b/drivers/phy/phy-imx8mq-usb.c index 69f01de55538..53099436b04b 100644 --- a/drivers/phy/phy-imx8mq-usb.c +++ b/drivers/phy/phy-imx8mq-usb.c @@ -14,6 +14,7 @@ #include #include #include +#include #define PHY_CTRL0 0x0 #define PHY_CTRL0_REF_SSP_EN BIT(2) @@ -81,6 +82,7 @@ struct imx8mq_usb_phy { #endif void __iomem *base; enum imx8mpq_phy_type type; + struct udevice *vbus_supply; }; static const struct udevice_id imx8mq_usb_phy_of_match[] = { @@ -172,10 +174,10 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy) { struct udevice *dev = usb_phy->dev; struct imx8mq_usb_phy *imx_phy = dev_get_priv(dev); + __maybe_unused int ret; u32 value; #if CONFIG_IS_ENABLED(CLK) - int ret; ret = clk_enable(&imx_phy->phy_clk); if (ret) { printf("Failed to enable usb phy clock\n"); @@ -183,6 +185,14 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy) } #endif + if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) { + ret = regulator_set_enable(imx_phy->vbus_supply, true); + if (ret) { + pr_err("Failed to enable VBUS regulator: %d\n", ret); + return ret; + } + } + /* Disable rx term override */ value = readl(imx_phy->base + PHY_CTRL6); value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL; @@ -195,6 +205,7 @@ static int imx8mq_usb_phy_power_off(struct phy *usb_phy) { struct udevice *dev = usb_phy->dev; struct imx8mq_usb_phy *imx_phy = dev_get_priv(dev); + __maybe_unused int ret; u32 value; /* Override rx term to be 0 */ @@ -206,6 +217,14 @@ static int imx8mq_usb_phy_power_off(struct phy *usb_phy) clk_disable(&imx_phy->phy_clk); #endif + if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) { + ret = regulator_set_enable(imx_phy->vbus_supply, false); + if (ret) { + pr_err("Failed to disable VBUS regulator: %d\n", ret); + return ret; + } + } + return 0; } @@ -224,6 +243,7 @@ struct phy_ops imx8mq_usb_phy_ops = { int imx8mq_usb_phy_probe(struct udevice *dev) { struct imx8mq_usb_phy *priv = dev_get_priv(dev); + __maybe_unused int ret; priv->type = dev_get_driver_data(dev); priv->base = dev_read_addr_ptr(dev); @@ -232,7 +252,6 @@ int imx8mq_usb_phy_probe(struct udevice *dev) return -EINVAL; #if CONFIG_IS_ENABLED(CLK) - int ret; /* Assigned clock already set clock */ ret = clk_get_by_name(dev, "phy", &priv->phy_clk); @@ -242,6 +261,15 @@ int imx8mq_usb_phy_probe(struct udevice *dev) } #endif + if (CONFIG_IS_ENABLED(DM_REGULATOR)) { + ret = device_get_supply_regulator(dev, "vbus-supply", + &priv->vbus_supply); + if (ret && ret != -ENOENT) { + pr_err("Failed to get VBUS regulator: %d\n", ret); + return ret; + } + } + return 0; } -- 2.25.1
[PATCH] board: gateworks: venice: add imx8mp-gw7905-2x support
The Gateworks imx8mp-venice-gw7905-2x consists of a SOM + baseboard. The GW702x SOM contains the following: - i.MX8M Plus SoC - LPDDR4 memory - eMMC Boot device - Gateworks System Controller (GSC) with integrated EEPROM, button controller, and ADC's - PMIC - SOM connector providing: - eQoS GbE MII - 1x SPI - 2x I2C - 4x UART - 2x USB 3.0 - 1x PCI - 1x SDIO (4-bit 3.3V) - 1x SDIO (4-bit 3.3V/1.8V) - GPIO The GW7905 Baseboard contains the following: - GPS - microSD - off-board I/O connector with I2C, SPI, GPIO - EERPOM - PCIe clock generator - 1x full-length miniPCIe socket with PCI/USB3 (via mux) and USB2.0 - 1x half-length miniPCIe socket with USB2.0 and USB3.0 - USB 3.0 HUB - USB Type-C with USB PD Sink capability and peripheral support - USB Type-C with USB 3.0 host support Signed-off-by: Tim Harvey --- arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi | 12 + arch/arm/dts/imx8mp-venice-gw702x.dtsi| 587 ++ .../dts/imx8mp-venice-gw7905-2x-u-boot.dtsi | 51 ++ arch/arm/dts/imx8mp-venice-gw7905-2x.dts | 28 + arch/arm/dts/imx8mp-venice-gw7905.dtsi| 309 + board/gateworks/venice/eeprom.c | 5 + board/gateworks/venice/lpddr4_timing.h| 1 + board/gateworks/venice/lpddr4_timing_imx8mp.c | 532 board/gateworks/venice/spl.c | 19 +- configs/imx8mp_venice_defconfig | 2 +- 11 files changed, 1544 insertions(+), 3 deletions(-) create mode 100644 arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mp-venice-gw702x.dtsi create mode 100644 arch/arm/dts/imx8mp-venice-gw7905-2x-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mp-venice-gw7905-2x.dts create mode 100644 arch/arm/dts/imx8mp-venice-gw7905.dtsi diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 480269fa6065..909a4d23f4a7 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1016,6 +1016,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \ imx8mp-phyboard-pollux-rdk.dtb \ imx8mp-venice.dtb \ imx8mp-venice-gw74xx.dtb \ + imx8mp-venice-gw7905-2x.dtb \ imx8mp-verdin-wifi-dev.dtb \ imx8mq-pico-pi.dtb \ imx8mq-kontron-pitx-imx8m.dtb \ diff --git a/arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi b/arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi new file mode 100644 index ..b9e3db7de937 --- /dev/null +++ b/arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2023 Gateworks Corporation + */ + +#include "imx8mp-venice-u-boot.dtsi" + +&eqos { + /delete-property/ assigned-clocks; + /delete-property/ assigned-clock-parents; + /delete-property/ assigned-clock-rates; +}; diff --git a/arch/arm/dts/imx8mp-venice-gw702x.dtsi b/arch/arm/dts/imx8mp-venice-gw702x.dtsi new file mode 100644 index ..560c68e4da6d --- /dev/null +++ b/arch/arm/dts/imx8mp-venice-gw702x.dtsi @@ -0,0 +1,587 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright 2023 Gateworks Corporation + */ + +#include +#include +#include + +/ { + aliases { + ethernet0 = &eqos; + }; + + memory@4000 { + device_type = "memory"; + reg = <0x0 0x4000 0 0x8000>; + }; + + gpio-keys { + compatible = "gpio-keys"; + + key-user-pb { + label = "user_pb"; + gpios = <&gpio 2 GPIO_ACTIVE_LOW>; + linux,code = ; + }; + + key-user-pb1x { + label = "user_pb1x"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <0>; + }; + + key-erased { + label = "key_erased"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <1>; + }; + + key-eeprom-wp { + label = "eeprom_wp"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <2>; + }; + + key-tamper { + label = "tamper"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <5>; + }; + + switch-hold { + label = "switch_hold"; + linux,code = ; + interrupt-parent = <&gsc>; + interrupts = <7>; + }; + }; +}; + +&A53_0 { + cpu-supply = <&buck3_reg>; +}; + +&A53_1 { + cpu-supply = <&buck3_reg>; +}; + +&A53_2 { + cpu-supply = <&buck3_reg>; +}; + +&A53_3 { +
[PATCH] board: gateworks: venice: display dram speed
Display dram speed during configuration. Signed-off-by: Tim Harvey --- board/gateworks/venice/spl.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c index 50056da3ee0f..c81498e830d6 100644 --- a/board/gateworks/venice/spl.c +++ b/board/gateworks/venice/spl.c @@ -83,9 +83,12 @@ static void spl_dram_init(int size) printf("DRAM: LPDDR4 "); if (size > 512) - printf("%d GiB\n", size / 1024); + printf("%d GiB", size / 1024); else - printf("%d MiB\n", size); + printf("%d MiB", size); + printf(" %dMT/s %dMHz\n", + dram_timing->fsp_msg[0].drate, + dram_timing->fsp_msg[0].drate / 2); ddr_init(dram_timing); } -- 2.25.1
[PATCH] board: gateworks: venice: assume emmc device for USB boot
When booting from USB (SDP) setup firmware-update environment for emmc device. Signed-off-by: Tim Harvey --- board/gateworks/venice/venice.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c index 803582c55b99..3067480e6ac7 100644 --- a/board/gateworks/venice/venice.c +++ b/board/gateworks/venice/venice.c @@ -155,6 +155,7 @@ int board_late_init(void) bootdev = 2; break; default: + bootdev = 2; /* assume SDHC3 (eMMC) if booting over SDP */ break; } if (bootdev != -1) -- 2.25.1
Re: [PULL] u-boot-sh/next_soc/v3x
On Thu, Jun 08, 2023 at 11:32:22PM +0200, Marek Vasut wrote: > The following changes since commit 3aa4fb12f4abd31bce7fe6294dd47fd0966a791a: > > Merge tag 'efi-next-20230608' of > https://source.denx.de/u-boot/custodians/u-boot-efi into next (2023-06-08 > 11:19:27 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git next_soc/v3x > > for you to fetch changes up to ed2f65f0105dacb98e5c4d2b435dd009de06c2d1: > > ARM: renesas: Add R8A77980 V3HSK board and CPLD code (2023-06-08 22:26:52 > +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] phy: phy-imx8mq-usb: add vbus regulator support
On Thu, Jun 8, 2023 at 8:12 PM Adam Ford wrote: > > On Thu, Jun 8, 2023 at 8:29 PM Tim Harvey wrote: > > > > Add support for enabling and disabling vbus-supply regulator found > > on several imx8mp boards in the usb3_phy0 and usb3_phy1 nodes. > > > > Without this I suspect U-Boot usb does not work on the following: > > - imx8mp-beacon-kit > > The Host-only port works on the Beacon board, but the dual-role, usb > type-c port doesn't appear to have been impacted. I am guessing it's > due to the lack of a proper type-c driver. Despite that, I think it's > the right thing to do for this platform, and I'll give some feedback > below. Adam, Is perhaps the pca6416 gpio0 pulled up externally or defaults to driving high? If you put a print in regulator_set_enable() you'll see that reg_usb1_host_vbus never gets called without this patch so I don't see how a device on that host would work. Right - the type-c doesn't work because there is no driver for the ptn5110. Even if there were I'm not clear what the right mechanism is for calling out from the dwc3 driver to see what role the usb controller should be. I don't believe U-Boot already has any common method for usb host controllers to ask for role other than reading the dr_mode prop. Perhaps there needs to be a usb connector uclass added with a global function to check the role that various typec controller drivers could use. I have some imx8mp boards that have OTG connectors where I need to check the USB_ID gpio for the role which can be handled that way as well. If you did want to default your type-c to host mode until such support exists you can add 'dr_mode = "host"' to the usb_dwc3_0 node in your imx8mp-beacon-kit-u-boot.dtsi: > > > - imx8mp-msc-sm2s > > - imx8mp-verdin-wifi-dev > > > > Reviewed-by: Adam Ford > > > Signed-off-by: Tim Harvey > > --- > > drivers/phy/phy-imx8mq-usb.c | 24 ++-- > > 1 file changed, 22 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/phy/phy-imx8mq-usb.c b/drivers/phy/phy-imx8mq-usb.c > > index 69f01de55538..eed9c07848f4 100644 > > --- a/drivers/phy/phy-imx8mq-usb.c > > +++ b/drivers/phy/phy-imx8mq-usb.c > > @@ -14,6 +14,7 @@ > > #include > > #include > > #include > > +#include > > > > #define PHY_CTRL0 0x0 > > #define PHY_CTRL0_REF_SSP_EN BIT(2) > > @@ -81,6 +82,7 @@ struct imx8mq_usb_phy { > > #endif > > void __iomem *base; > > enum imx8mpq_phy_type type; > > + struct udevice *vbus_supply; > > }; > > > > static const struct udevice_id imx8mq_usb_phy_of_match[] = { > > @@ -173,9 +175,9 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy) > > struct udevice *dev = usb_phy->dev; > > struct imx8mq_usb_phy *imx_phy = dev_get_priv(dev); > > u32 value; > > + int ret; > > In the unlikely event that neither CONFIG_CLK nor CONFIG_DM_REGULATOR > is configured, will defining ret here throw a compiler warning that > it's unused? I wonder if __maybe_unused attribute would be permissible > here or if this should be inside an #if statement. > good point, I'll add for v2 > > > > #if CONFIG_IS_ENABLED(CLK) > > - int ret; > > ret = clk_enable(&imx_phy->phy_clk); > > if (ret) { > > printf("Failed to enable usb phy clock\n"); > > @@ -183,6 +185,12 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy) > > } > > #endif > > > > + if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) { > > + ret = regulator_set_enable(imx_phy->vbus_supply, true); > > + if (ret) > > I am personally a fan of error messages. There is an error message if > the clock fails, so unless there is an objection, can we have one here > too? One was also added to the probe function. ok, I'll add this for v2 > > > + return ret; > > + } > > + > > /* Disable rx term override */ > > value = readl(imx_phy->base + PHY_CTRL6); > > value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL; > > @@ -206,6 +214,9 @@ static int imx8mq_usb_phy_power_off(struct phy *usb_phy) > > clk_disable(&imx_phy->phy_clk); > > #endif > > > > + if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) > > + return regulator_set_enable(imx_phy->vbus_supply, false); > > + > > return 0; > > } > > > > @@ -224,6 +235,7 @@ struct phy_ops imx8mq_usb_phy_ops = { > > int imx8mq_usb_phy_probe(struct udevice *dev) > > { > > struct imx8mq_usb_phy *priv = dev_get_priv(dev); > > + int ret; > > Same comment as above regarding whether or not this might be unused. yep - will address. Thanks for the review! Tim
[PATCH 2/2] renesas: rcar3: Load the correct device tree
The Renesas R-Car Gen3 H3e (Starter Kit Premier) uses a different device tree than the default one. This uses the sysinfo's board id to determine if the board needs a specific device tree. Signed-off-by: Detlev Casanova --- board/renesas/ulcb/ulcb.c| 34 ++ configs/rcar3_ulcb_defconfig | 1 + 2 files changed, 35 insertions(+) diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c index 1477750f921..3e2fe3a3ca9 100644 --- a/board/renesas/ulcb/ulcb.c +++ b/board/renesas/ulcb/ulcb.c @@ -28,6 +28,8 @@ #include #include +#include "../../../drivers/sysinfo/rcar3.h" + DECLARE_GLOBAL_DATA_PTR; #define DVFS_MSTP926 BIT(26) @@ -65,6 +67,38 @@ int board_init(void) return 0; } +int misc_init_r(void) +{ + struct udevice *dev; + int board_id; + int ret = sysinfo_get(&dev); +if (ret) { + debug("Cannot get sysinfo: %d\n", ret); + return 0; + } + + ret = sysinfo_detect(dev); + if (ret) { + debug("Cannot detect sysinfo: %d\n", ret); + return 0; + } + + ret = sysinfo_get_int(dev, + SYSINFO_ID_BOARD_MODEL, + &board_id); + + if (ret) { + debug("Cannot get sysinfo int: %d\n", ret); + return 0; + } + + if (board_id == BOARD_STARTER_KIT_PRE) { + env_set("fdtfile", "renesas/r8a779m1-ulcb.dtb"); + } + + return 0; +} + #ifdef CONFIG_MULTI_DTB_FIT int board_fit_config_name_match(const char *name) { diff --git a/configs/rcar3_ulcb_defconfig b/configs/rcar3_ulcb_defconfig index b8fdb5e3826..752d33d77ec 100644 --- a/configs/rcar3_ulcb_defconfig +++ b/configs/rcar3_ulcb_defconfig @@ -111,3 +111,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_STORAGE=y +CONFIG_MISC_INIT_R=y -- 2.39.3
[PATCH 1/2] renesas: rcar3: Expose the board id in sysinfo
This is a preparation commit for selecting the correct device tree name to be loaded depending on the board id. Signed-off-by: Detlev Casanova --- drivers/sysinfo/rcar3.c | 31 ++- drivers/sysinfo/rcar3.h | 21 + 2 files changed, 39 insertions(+), 13 deletions(-) create mode 100644 drivers/sysinfo/rcar3.h diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c index 7b127986da7..4252f8d452c 100644 --- a/drivers/sysinfo/rcar3.c +++ b/drivers/sysinfo/rcar3.c @@ -7,24 +7,12 @@ #include #include #include -#include +#include "rcar3.h" #define BOARD_CODE_MASK0xF8 #define BOARD_REV_MASK 0x07 #define BOARD_CODE_SHIFT 0x03 -#define BOARD_SALVATOR_X 0x0 -#define BOARD_KRIEK0x1 -#define BOARD_STARTER_KIT 0x2 -#define BOARD_EAGLE0x3 -#define BOARD_SALVATOR_XS 0x4 -#define BOARD_CONDOR 0x6 -#define BOARD_DRAAK0x7 -#define BOARD_EBISU0x8 -#define BOARD_STARTER_KIT_PRE 0xB -#define BOARD_EBISU_4D 0xD -#define BOARD_CONDOR_I 0x10 - /** * struct sysinfo_rcar_priv - sysinfo private data * @boardname: board model and revision @@ -32,6 +20,7 @@ */ struct sysinfo_rcar_priv { charboardmodel[64]; + u8 board_id; u8 val; }; @@ -42,6 +31,19 @@ static int sysinfo_rcar_detect(struct udevice *dev) return priv->val == 0xff; } +static int sysinfo_rcar_get_int(struct udevice *dev, int id, int *val) +{ + struct sysinfo_rcar_priv *priv = dev_get_priv(dev); + + switch (id) { + case SYSINFO_ID_BOARD_MODEL: + *val = priv->board_id; + return 0; + default: + return -EINVAL; + }; +} + static int sysinfo_rcar_get_str(struct udevice *dev, int id, size_t size, char *val) { struct sysinfo_rcar_priv *priv = dev_get_priv(dev); @@ -59,6 +61,7 @@ static int sysinfo_rcar_get_str(struct udevice *dev, int id, size_t size, char * static const struct sysinfo_ops sysinfo_rcar_ops = { .detect = sysinfo_rcar_detect, .get_str = sysinfo_rcar_get_str, + .get_int = sysinfo_rcar_get_int, }; static void sysinfo_rcar_parse(struct sysinfo_rcar_priv *priv) @@ -68,6 +71,8 @@ static void sysinfo_rcar_parse(struct sysinfo_rcar_priv *priv) bool salvator_xs = false; bool ebisu_4d = false; bool condor_i = false; + + priv->board_id = board_id; char rev_major = '?'; char rev_minor = '?'; diff --git a/drivers/sysinfo/rcar3.h b/drivers/sysinfo/rcar3.h new file mode 100644 index 000..21ae918d9bb --- /dev/null +++ b/drivers/sysinfo/rcar3.h @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2023 Detlev Casanova + */ + +#include + +#define BOARD_SALVATOR_X 0x0 +#define BOARD_KRIEK0x1 +#define BOARD_STARTER_KIT 0x2 +#define BOARD_EAGLE0x3 +#define BOARD_SALVATOR_XS 0x4 +#define BOARD_CONDOR 0x6 +#define BOARD_DRAAK0x7 +#define BOARD_EBISU0x8 +#define BOARD_STARTER_KIT_PRE 0xB +#define BOARD_EBISU_4D 0xD +#define BOARD_CONDOR_I 0x10 + + + -- 2.39.3
[PATCH 0/2] rcar: Select the correct device tree
The R-Car Starter Kit Premier(H3e WS3.0) uses the r8a779m1-ulcb.dtb. As u-boot can detect the board id, let's use this to set the correct device tree for that board when using pxe. Detlev Casanova (2): renesas: rcar3: Expose the board id in sysinfo renesas: rcar3: Load the correct device tree board/renesas/ulcb/ulcb.c| 34 ++ configs/rcar3_ulcb_defconfig | 1 + drivers/sysinfo/rcar3.c | 31 ++- drivers/sysinfo/rcar3.h | 21 + 4 files changed, 74 insertions(+), 13 deletions(-) create mode 100644 drivers/sysinfo/rcar3.h -- 2.39.3
[PATCH] renesas: rcar: Apply ATF overlay for reserved-memory
The function fdtdec_board_setup() is called early and adds the overlay from ATF to the u-boot device tree. That is necessary so that u-boot doesn't use reserved memory. Linux also needs to know about that reserved memory so the overlay from ATF needs to be aplied on the linux device tree as well. This commit makes sure that the ATF overlay is applied to both device trees. Signed-off-by: Detlev Casanova --- board/renesas/rcar-common/common.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/board/renesas/rcar-common/common.c b/board/renesas/rcar-common/common.c index f38453af82c..f976c99028a 100644 --- a/board/renesas/rcar-common/common.c +++ b/board/renesas/rcar-common/common.c @@ -25,12 +25,17 @@ extern u64 rcar_atf_boot_args[]; #define FDT_RPC_PATH "/soc/spi@ee20" -int fdtdec_board_setup(const void *fdt_blob) +static void apply_atf_overlay(void *fdt_blob) { void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]); if (fdt_magic(atf_fdt_blob) == FDT_MAGIC) - fdt_overlay_apply_node((void *)fdt_blob, 0, atf_fdt_blob, 0); + fdt_overlay_apply_node(fdt_blob, 0, atf_fdt_blob, 0); +} + +int fdtdec_board_setup(const void *fdt_blob) +{ + apply_atf_overlay((void *)fdt_blob); return 0; } @@ -159,6 +164,7 @@ static void update_rpc_status(void *blob) int ft_board_setup(void *blob, struct bd_info *bd) { + apply_atf_overlay(blob); scrub_duplicate_memory(blob); update_rpc_status(blob); -- 2.39.3
[PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode
>From fff53ba354c8eca33cb9901888778420db637073 Mon Sep 17 00:00:00 2001 From: Lu Hui Date: Fri, 9 Jun 2023 22:05:53 +0800 Subject: [PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode --- arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts index 43896723a9..0ab6353727 100644 --- a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts +++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts @@ -5,6 +5,7 @@ /dts-v1/; #include "suniv-f1c100s.dtsi" +#include #include @@ -71,3 +72,17 @@ usb0_id_det-gpios = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */ status = "okay"; }; + +&otg_sram { +status = "okay"; +}; + +&usb_otg { +dr_mode = "peripheral"; +status = "okay"; +}; + +&usbphy { +usb0_id_det-gpio = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */ +status = "okay"; +}; -- 2.40.1
[PATCH 2/3] drivers: musb-new: add allwinner f1c100s
>From fe7d48e84bb3c72d219f37eed51ea766f83b4bec Mon Sep 17 00:00:00 2001 From: Lu Hui Date: Fri, 9 Jun 2023 22:05:23 +0800 Subject: [PATCH 2/3] drivers: musb-new: add allwinner f1c100s configuration --- drivers/usb/musb-new/sunxi.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index dc4cfc2194..1c90739cea 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -4,6 +4,7 @@ * * Copyright © 2015 Hans de Goede * Copyright © 2013 Jussi Kivilinna + * Copyright © 2023 Lu Hui * * Based on the sw_usb "Allwinner OTG Dual Role Controller" code. * Copyright 2007-2012 (C) Allwinner Technology Co., Ltd. @@ -519,6 +520,10 @@ static const struct sunxi_musb_config sun8i_h3_cfg = { .config = &musb_config_h3, }; +static const struct sunxi_musb_config suniv_f1c100s_cfg = { +.config = &musb_config, +}; + static const struct udevice_id sunxi_musb_ids[] = { { .compatible = "allwinner,sun4i-a10-musb", .data = (ulong)&sun4i_a10_cfg }, @@ -528,6 +533,8 @@ static const struct udevice_id sunxi_musb_ids[] = { .data = (ulong)&sun6i_a31_cfg }, { .compatible = "allwinner,sun8i-h3-musb", .data = (ulong)&sun8i_h3_cfg }, +{ .compatible = "allwinner,suniv-f1c100s-musb", +.data = (ulong)&suniv_f1c100s_cfg }, { } }; -- 2.40.1
[PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration
>From 09a85536f92cfd22f2a6feba8ea91fae4bc41ed8 Mon Sep 17 00:00:00 2001 From: Lu Hui Date: Fri, 9 Jun 2023 22:04:56 +0800 Subject: [PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration --- drivers/phy/allwinner/phy-sun4i-usb.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c index 6428163c18..8425a83c84 100644 --- a/drivers/phy/allwinner/phy-sun4i-usb.c +++ b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -4,6 +4,7 @@ * Copyright (C) 2017 Jagan Teki * Copyright (C) 2015 Hans de Goede * Copyright (C) 2014 Roman Byshko + * Copyright (C) 2023 Lu Hui * * Modelled arch/arm/mach-sunxi/usb_phy.c to compatible with generic-phy. * @@ -83,6 +84,7 @@ enum sun4i_usb_phy_type { sun8i_v3s_phy, sun50i_a64_phy, sun50i_h6_phy, +suniv_f1c100s_phy, }; struct sun4i_usb_phy_cfg { @@ -372,8 +374,9 @@ static int sun4i_usb_phy_xlate(struct phy *phy, { struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev); -if (args->args_count >= data->cfg->num_phys) +if (args->args_count > data->cfg->num_phys) { return -EINVAL; +} if (data->cfg->missing_phys & BIT(args->args[0])) return -ENODEV; @@ -531,6 +534,14 @@ static int sun4i_usb_phy_probe(struct udevice *dev) return 0; } +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { +.num_phys = 1, +.type = suniv_f1c100s_phy, +.disc_thresh = 3, +.phyctl_offset = REG_PHYCTL_A10, +.dedicated_clocks = true, +}; + static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = { .num_phys = 3, .type = sun4i_a10_phy, @@ -659,6 +670,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = { { .compatible = "allwinner,sun20i-d1-usb-phy", .data = (ulong)&sun20i_d1_cfg }, { .compatible = "allwinner,sun50i-a64-usb-phy", .data = (ulong)&sun50i_a64_cfg}, { .compatible = "allwinner,sun50i-h6-usb-phy", .data = (ulong)&sun50i_h6_cfg}, +{ .compatible = "allwinner,suniv-f1c100s-usb-phy", .data = (ulong)&suniv_f1c100s_cfg}, { } }; -- 2.40.1
[PATCH] drivers: pinctrl-sunxi: add suniv spi1 function
>From 570b40e19de75511d9ce066e1a28333ada04baf2 Mon Sep 17 00:00:00 2001 From: Lu Hui Date: Mon, 29 May 2023 22:26:25 +0800 Subject: [PATCH] drivers: pinctrl-sunxi: add suniv spi1 function --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index e510218090..c448e40ab0 100644 --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -240,6 +240,7 @@ static const struct sunxi_pinctrl_function suniv_f1c100s_pinctrl_functions[] = { { "mmc0",2 },/* PF0-PF5 */ { "mmc1",3 },/* PC0-PC2 */ { "spi0",2 },/* PC0-PC3 */ +{ "spi1",6 },/* PA0-PA3 */ #if IS_ENABLED(CONFIG_UART0_PORT_F) { "uart0",3 },/* PF2-PF4 */ #else -- 2.40.1
Re: [PATCH V2 6/8] drivers: video: Kconfig: Add config remove video
On Fri, Jun 09, 2023 at 05:21:20PM +0530, Nikhil M Jain wrote: > This is required since user may want to either call the remove method > of video driver and reset the display or not call the remove method > to continue displaying until next stage. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V2: > - Add Reviewed-by tag. > > drivers/video/Kconfig | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index fcc0e85d2e..eca95dd28e 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -840,6 +840,13 @@ config IHS_VIDEO_OUT > out On-screen Display (OSD) used on gdsys FPGAs to control dynamic > textual overlays of the display outputs. > > +config VIDEO_REMOVE > + bool "Remove video driver" > + help > + Use this option to specify if user wants to call remove method > of > + video driver in u-boot proper stage. Please fix this spacing. -- Tom signature.asc Description: PGP signature
Re: [PATCH V2 4/8] include: video: Reserve video using blob
On Fri, Jun 09, 2023 at 05:21:18PM +0530, Nikhil M Jain wrote: > Add method to reserve video framebuffer information using blob, > recieved from previous stage. > > Signed-off-by: Nikhil M Jain > --- > V2: > - Remove #if CONFIG_IS_ENABLED(VIDEO) in video_reserve_from_blob. > > drivers/video/video-uclass.c | 11 +++ > include/video.h | 9 + > 2 files changed, 20 insertions(+) > > diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c > index 8396bdfb11..68ce681bb9 100644 > --- a/drivers/video/video-uclass.c > +++ b/drivers/video/video-uclass.c > @@ -142,6 +142,17 @@ int video_reserve(ulong *addrp) > return 0; > } > > +int video_reserve_from_bloblist(struct video_handoff *ho) > +{ > + gd->video_bottom = ho->fb; > + gd->fb_base = ho->fb; > + gd->video_top = ho->fb + ho->size; > + debug("Reserving %luk for video using blob at: %08x\n", > + ((unsigned long)ho->size) >> 10, (u32)ho->fb); > + > + return 0; > +} > + > int video_fill(struct udevice *dev, u32 colour) > { > struct video_priv *priv = dev_get_uclass_priv(dev); > diff --git a/include/video.h b/include/video.h > index 18ed159b8d..5f3010d641 100644 > --- a/include/video.h > +++ b/include/video.h > @@ -389,4 +389,13 @@ int bmp_display(ulong addr, int x, int y); > */ > int bmp_info(ulong addr); > > +/* > + * video_reserve_from_bloblist()- Reserve frame-buffer memory for video > devices > + * using blobs. > + * > + * @ho: video information passed from SPL > + * Returns: 0 (always) > + */ > +int video_reserve_from_bloblist(struct video_handoff *ho); > + > #endif Anatolij any thoughts? -- Tom signature.asc Description: PGP signature
Re: [PATCH V2 1/8] common: spl: spl: Update stack pointer address
On Fri, Jun 09, 2023 at 05:21:15PM +0530, Nikhil M Jain wrote: > At SPL stage when stack is relocated, the stack pointer needs to be > updated, the stack pointer may point to stack in on chip memory even > though stack is relocated. > > Signed-off-by: Nikhil M Jain Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH] bootstd: Fix relative path use in extlinux bootmeth
Using relative path in a /boot/extlinux/extlinux.conf file fails to load linux kernel. Using a /boot/extlinux/extlinux.conf file: LABEL test LINUX ../linux/Image Result in following error: Retrieving file: ../linux/Image Skipping test for failure retrieving kernel Boot failed (err=-14) However, using sysboot cmd successfully load kernel using same file: sysboot mmc 1:1 any ${scriptaddr} /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/../linux/Image Fix relative path using bootmeth extlinux by supplying bootfile path instead of subdir path in the call to pxe_setup_ctx, same as done in the sysboot command. Fixes: 31aefaf89a5b ("bootstd: Add an implementation of distro boot") Signed-off-by: Jonas Karlman --- boot/bootmeth_extlinux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/bootmeth_extlinux.c b/boot/bootmeth_extlinux.c index 24be0760229c..6b2b84003836 100644 --- a/boot/bootmeth_extlinux.c +++ b/boot/bootmeth_extlinux.c @@ -150,7 +150,7 @@ static int extlinux_boot(struct udevice *dev, struct bootflow *bflow) info.dev = dev; info.bflow = bflow; ret = pxe_setup_ctx(&ctx, &cmdtp, extlinux_getfile, &info, true, - bflow->subdir, false); + bflow->fname, false); if (ret) return log_msg_ret("ctx", -EINVAL); -- 2.40.1
Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa
On Fri, Jun 09, 2023 at 08:03:44AM -0600, Rob Herring wrote: > Nope, vendor prefixes don't go in node names. That's not explicit > anywhere, but goes against using generic node names. Yeah, that makes sense. > Also, note that looking at the DT spec, there's already prior art here > with PPC. See "power-isa-*". Though that appears in .dts files, but no > kernel code. Maybe you already saw that as your v1 is similar. There's > not really much advantage to align with it, but also not much reason > to deviate. I went back and forth on riscv-isa- versus riscv,isa-, picking the , for consistency with other properties in the file. I thought that doing it like power would be frowned upon & that it might've been done like that for historic reasons, especially given existing properties we have for riscv ISA related things are vendor properties w/ the comma. I don't have strong feelings either way though, so if you say s/,/-/ then that's good by me! Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa
On Thu, Jun 8, 2023 at 12:05 PM Conor Dooley wrote: > > On Thu, Jun 08, 2023 at 11:49:08AM -0600, Rob Herring wrote: > > On Thu, 08 Jun 2023 17:54:05 +0100, Conor Dooley wrote: > > > > As a result of implementing Sean's suggestion, I believe I need to add > > > riscv,isa-extensions as an exception to the rules preventing vendor > > > properties being of object type, otherwise dt_binding_check is less than > > > happy with me. > > > dtschema/dtc warnings/errors: > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml: > > properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be > > fixed: > > Additional properties are not allowed ('additionalProperties', > > 'properties' were unexpected) > > hint: A vendor boolean property can use "type: boolean" > > > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml: > > properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be > > fixed: > > 'enum' is a required property > > 'const' is a required property > > hint: A vendor string property with exact values has an > > implicit type > > from schema $id: > > http://devicetree.org/meta-schemas/vendor-props.yaml# > > Additional properties are not allowed ('additionalProperties', > > 'properties', 'type' were unexpected) > > hint: A vendor string property with exact values has an > > implicit type > > > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml: > > properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be > > fixed: > > '$ref' is a required property > > 'allOf' is a required property > > hint: A vendor property needs a $ref to types.yaml > > from schema $id: > > http://devicetree.org/meta-schemas/vendor-props.yaml# > > 'boolean' was expected > > hint: A vendor boolean property can use "type: boolean" > > hint: Vendor specific properties must have a type and description > > unless they have a defined, common suffix. > > from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml# > > Yeah, expected. I think I need an exception in vendor-props for this to > pass the checks. Nope, vendor prefixes don't go in node names. That's not explicit anywhere, but goes against using generic node names. Also, note that looking at the DT spec, there's already prior art here with PPC. See "power-isa-*". Though that appears in .dts files, but no kernel code. Maybe you already saw that as your v1 is similar. There's not really much advantage to align with it, but also not much reason to deviate. Rob
Re: [PULL] u-boot-sh/master_soc/fixes
On Thu, Jun 08, 2023 at 11:33:12PM +0200, Marek Vasut wrote: > The following changes since commit 661332a0744dad6a1a4bfbbdea2a4e5ae9835e52: > > Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi (2023-06-07 > 22:05:16 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git master_soc/fixes > > for you to fetch changes up to b597b6f9861c2d5531b0055249622ee0e663577c: > > pinctrl: renesas: r8a779a0: Remove incorrect AVB[01] pinmux configuration > (2023-06-08 22:22:38 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master_soc/fixes
On Thu, Jun 08, 2023 at 11:33:12PM +0200, Marek Vasut wrote: > The following changes since commit 661332a0744dad6a1a4bfbbdea2a4e5ae9835e52: > > Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi (2023-06-07 > 22:05:16 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git master_soc/fixes > > for you to fetch changes up to b597b6f9861c2d5531b0055249622ee0e663577c: > > pinctrl: renesas: r8a779a0: Remove incorrect AVB[01] pinmux configuration > (2023-06-08 22:22:38 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V2 8/8] configs: am62x_evm_a53: Add bloblist address
On 17:21-20230609, Nikhil M Jain wrote: > Define bloblist address. > > Updated Memory map > 0x8000┌─┐ > │Empty 512 KB │ > │ │ > 0x8008├─┤ > │ Text Base │ > │ 352 KB│ > │ │ > 0x800D8000├─┤ > │Empty 1.1MB │ > │ │ > 0x8020├─┤ > │ │ > │ │ > │ │ > │ BMP Image Load│ > │ │ > │ 9.4 MB│ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > 0x80B77660├─┤ > │ Stack 2KB │ > 0x80B77e60├─┤ > │GD 416 Bytes │ > 0x80B78000├─┤ > │ │ > │Malloc 352KB │ > 0x80B8├─┤ > │ │ > │ Empty 1 MB │ > │ │ > 0x80C8├─┤ > │ BSS 512 KB │ > │ │ > 0x80D0├─┤ > │ Blobs 1KB │ > 0x80D00400├─┤ > │ │ > │ Empty 2.999MB │ > │ │ > │ │ > 0x8100└─┘FIT Image load address Document in rst please. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V2: > - Add Reviewed-by tag. > > configs/am62x_evm_a53_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index 7c3bc184cf..5c572dfb33 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -102,3 +102,4 @@ CONFIG_SYSRESET=y > CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_TI_SCI=y > CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > +CONFIG_BLOBLIST_ADDR=0x80D0 > -- > 2.34.1 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH V2 8/8] configs: am62x_evm_a53: Add bloblist address
Define bloblist address. Updated Memory map 0x8000┌─┐ │Empty 512 KB │ │ │ 0x8008├─┤ │ Text Base │ │ 352 KB│ │ │ 0x800D8000├─┤ │Empty 1.1MB │ │ │ 0x8020├─┤ │ │ │ │ │ │ │ BMP Image Load│ │ │ │ 9.4 MB│ │ │ │ │ │ │ │ │ │ │ │ │ 0x80B77660├─┤ │ Stack 2KB │ 0x80B77e60├─┤ │GD 416 Bytes │ 0x80B78000├─┤ │ │ │Malloc 352KB │ 0x80B8├─┤ │ │ │ Empty 1 MB │ │ │ 0x80C8├─┤ │ BSS 512 KB │ │ │ 0x80D0├─┤ │ Blobs 1KB │ 0x80D00400├─┤ │ │ │ Empty 2.999MB │ │ │ │ │ 0x8100└─┘FIT Image load address Signed-off-by: Nikhil M Jain Reviewed-by: Devarsh Thakkar --- V2: - Add Reviewed-by tag. configs/am62x_evm_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index 7c3bc184cf..5c572dfb33 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -102,3 +102,4 @@ CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_BLOBLIST_ADDR=0x80D0 -- 2.34.1
[PATCH V2 3/8] board: ti: am62x: evm: Update function calls for splash screen
Use spl_dcache_enable, in place of setup_dram, arch_reserve_mmu to set up pagetable, initialise DRAM and enable Dcache. Signed-off-by: Nikhil M Jain --- V2: - Use CONFIG_SPL_VIDEO in place of CONFIG_SPL_VIDEO_TIDSS to reserve video and call splash at SPL. - Check SPL_SPLASH_SCREEN and SPL_BMP before calling splash display. arch/arm/mach-k3/am625_init.c | 1 + board/ti/am62x/evm.c | 41 +-- 2 files changed, 16 insertions(+), 26 deletions(-) diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c index 787fe92295..0e5d44269e 100644 --- a/arch/arm/mach-k3/am625_init.c +++ b/arch/arm/mach-k3/am625_init.c @@ -214,6 +214,7 @@ void board_init_f(ulong dummy) if (ret) panic("DRAM init failed: %d\n", ret); #endif + spl_enable_dcache(); } u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device) diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c index 34830f445f..d3c1786cd9 100644 --- a/board/ti/am62x/evm.c +++ b/board/ti/am62x/evm.c @@ -59,42 +59,31 @@ int dram_init_banksize(void) } #if defined(CONFIG_SPL_BUILD) -#ifdef CONFIG_SPL_VIDEO_TIDSS -static int setup_dram(void) -{ - dram_init(); - dram_init_banksize(); - gd->ram_base = CFG_SYS_SDRAM_BASE; - gd->ram_top = gd->ram_base + gd->ram_size; - gd->relocaddr = gd->ram_top; - return 0; -} - static int video_setup(void) { - ulong addr; - int ret; - addr = gd->relocaddr; + if (CONFIG_IS_ENABLED(VIDEO)) { + ulong addr; + int ret; + + addr = gd->relocaddr; + ret = video_reserve(&addr); + if (ret) + return ret; + debug("Reserving %luk for video at: %08lx\n", + ((unsigned long)gd->relocaddr - addr) >> 10, addr); + gd->relocaddr = addr; + } - ret = video_reserve(&addr); - if (ret) - return ret; - debug("Reserving %luk for video at: %08lx\n", - ((unsigned long)gd->relocaddr - addr) >> 10, addr); - gd->relocaddr = addr; return 0; } -#endif void spl_board_init(void) { -#if defined(CONFIG_SPL_VIDEO_TIDSS) - setup_dram(); - arch_reserve_mmu(); video_setup(); enable_caches(); - splash_display(); -#endif + if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP)) + splash_display(); + } #if defined(CONFIG_K3_AM64_DDRSS) -- 2.34.1
[PATCH V2 6/8] drivers: video: Kconfig: Add config remove video
This is required since user may want to either call the remove method of video driver and reset the display or not call the remove method to continue displaying until next stage. Signed-off-by: Nikhil M Jain Reviewed-by: Devarsh Thakkar --- V2: - Add Reviewed-by tag. drivers/video/Kconfig | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index fcc0e85d2e..eca95dd28e 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -840,6 +840,13 @@ config IHS_VIDEO_OUT out On-screen Display (OSD) used on gdsys FPGAs to control dynamic textual overlays of the display outputs. +config VIDEO_REMOVE + bool "Remove video driver" + help + Use this option to specify if user wants to call remove method of + video driver in u-boot proper stage. + + config SPLASH_SCREEN bool "Show a splash-screen image" help @@ -1063,6 +1070,12 @@ config SPL_SYS_WHITE_ON_BLACK This can be better in low-light situations or to reduce eye strain in some cases. +config SPL_VIDEO_REMOVE + bool "Remove video driver after SPL stage" + help +if this option is enabled video driver will be removed at the end of +SPL stage, beforeloading the next stage. + if SPL_SPLASH_SCREEN config SPL_SPLASH_SCREEN_ALIGN -- 2.34.1
[PATCH V2 5/8] common: board_f: Pass frame buffer info from SPL to u-boot
U-boot proper can use frame buffer address passed from SPL to reserve the memory area used by framebuffer set in SPL so that splash image set in SPL continues to get displayed while u-boot proper is running. Put the framebuffer address and size in a bloblist to make them available at u-boot proper, if in u-boot proper CONFIG_VIDEO is defined. Signed-off-by: Nikhil M Jain --- V2: - Fix commit message. - Revert use of #if. common/board_f.c | 12 +++- drivers/video/video-uclass.c | 12 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index 1688e27071..418aecc18f 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -411,7 +411,17 @@ __weak int arch_reserve_mmu(void) static int reserve_video(void) { - if (IS_ENABLED(CONFIG_VIDEO)) { + + if (IS_ENABLED(CONFIG_SPL_VIDEO) && spl_phase() > PHASE_SPL && + CONFIG_IS_ENABLED(BLOBLIST)) { + struct video_handoff *ho; + + ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho)); + if (!ho) + return log_msg_ret("blf", -ENOENT); + video_reserve_from_bloblist(ho); + gd->relocaddr = ho->fb; + } else if(CONFIG_IS_ENABLED(VIDEO)){ ulong addr; int ret; diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c index 68ce681bb9..f8f0dc0311 100644 --- a/drivers/video/video-uclass.c +++ b/drivers/video/video-uclass.c @@ -6,12 +6,14 @@ #define LOG_CATEGORY UCLASS_VIDEO #include +#include #include #include #include #include #include #include +#include #include #include #include @@ -139,6 +141,16 @@ int video_reserve(ulong *addrp) debug("Video frame buffers from %lx to %lx\n", gd->video_bottom, gd->video_top); + if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) { + struct video_handoff *ho; + + ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0); + if (!ho) + return log_msg_ret("blf", -ENOENT); + ho->fb = *addrp; + ho->size = size; + } + return 0; } -- 2.34.1
[PATCH V2 7/8] common: spl: spl: Remove video driver
Use config SPL_VIDEO_REMOVE to remove video driver at SPL stage before jumping to next stage, in place of CONFIG_SPL_VIDEO, to allow user to remove video if required. Signed-off-by: Nikhil M Jain Reviewed-by: Devarsh Thakkar --- v2: - Add Reviewed-by tag. common/spl/spl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl.c b/common/spl/spl.c index 13b55e9769..a65781002e 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -891,7 +891,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) debug("Failed to stash bootstage: err=%d\n", ret); #endif -#if defined(CONFIG_SPL_VIDEO) +#if defined(CONFIG_SPL_VIDEO_REMOVE) struct udevice *dev; int rc; -- 2.34.1
[PATCH V2 2/8] arch: arm: mach-k3: common: Return a pointer after setting page table
In spl_dcache_enable after setting up page table, set gd->relocaddr pointer to tlb_addr, to get next location to reserve memory. Align tlb_addr with 64KB address. Signed-off-by: Nikhil M Jain --- V2: - Perform 64KB alignment on tlb_addr. arch/arm/mach-k3/common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c index 0e045919dd..9cd912c523 100644 --- a/arch/arm/mach-k3/common.c +++ b/arch/arm/mach-k3/common.c @@ -624,8 +624,10 @@ void spl_enable_dcache(void) ram_top = (phys_addr_t) 0x1; gd->arch.tlb_addr = ram_top - gd->arch.tlb_size; + gd->arch.tlb_addr &= ~(0x1 - 1); debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr, gd->arch.tlb_addr + gd->arch.tlb_size); + gd->relocaddr = gd->arch.tlb_addr; dcache_enable(); #endif -- 2.34.1
[PATCH V2 1/8] common: spl: spl: Update stack pointer address
At SPL stage when stack is relocated, the stack pointer needs to be updated, the stack pointer may point to stack in on chip memory even though stack is relocated. Signed-off-by: Nikhil M Jain --- V2: - No change. common/spl/spl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/spl/spl.c b/common/spl/spl.c index 801c4b507c..13b55e9769 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -992,6 +992,7 @@ ulong spl_relocate_stack_gd(void) #endif /* Get stack position: use 8-byte alignment for ABI compliance */ ptr = CONFIG_SPL_STACK_R_ADDR - roundup(sizeof(gd_t),16); + gd->start_addr_sp = ptr; new_gd = (gd_t *)ptr; memcpy(new_gd, (void *)gd, sizeof(gd_t)); #if CONFIG_IS_ENABLED(DM) -- 2.34.1
[PATCH V2 4/8] include: video: Reserve video using blob
Add method to reserve video framebuffer information using blob, recieved from previous stage. Signed-off-by: Nikhil M Jain --- V2: - Remove #if CONFIG_IS_ENABLED(VIDEO) in video_reserve_from_blob. drivers/video/video-uclass.c | 11 +++ include/video.h | 9 + 2 files changed, 20 insertions(+) diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c index 8396bdfb11..68ce681bb9 100644 --- a/drivers/video/video-uclass.c +++ b/drivers/video/video-uclass.c @@ -142,6 +142,17 @@ int video_reserve(ulong *addrp) return 0; } +int video_reserve_from_bloblist(struct video_handoff *ho) +{ + gd->video_bottom = ho->fb; + gd->fb_base = ho->fb; + gd->video_top = ho->fb + ho->size; + debug("Reserving %luk for video using blob at: %08x\n", + ((unsigned long)ho->size) >> 10, (u32)ho->fb); + + return 0; +} + int video_fill(struct udevice *dev, u32 colour) { struct video_priv *priv = dev_get_uclass_priv(dev); diff --git a/include/video.h b/include/video.h index 18ed159b8d..5f3010d641 100644 --- a/include/video.h +++ b/include/video.h @@ -389,4 +389,13 @@ int bmp_display(ulong addr, int x, int y); */ int bmp_info(ulong addr); +/* + * video_reserve_from_bloblist()- Reserve frame-buffer memory for video devices + * using blobs. + * + * @ho: video information passed from SPL + * Returns: 0 (always) + */ +int video_reserve_from_bloblist(struct video_handoff *ho); + #endif -- 2.34.1
[PATCH V2 0/8] Update SPL splashscreen framework for AM62x
This patch series aims at updating SPL splashscreen framework for AM62x. This patch series depends on https://lore.kernel.org/u-boot/20230504225829.2537050-1-...@chromium.org/ This series: - Fixes compilation issues in case splash related configs are not defined in SPL. - Does page table setup, dram initialisation and dcache enabling in one function call spl_enable_dcache. - Allows passing of framebuffer from spl to u-boot, eliminating flicker. V2: - Update cover letter. - Fix commit message. Nikhil M Jain (8): common: spl: spl: Update stack pointer address arch: arm: mach-k3: common: Return a pointer after setting page table board: ti: am62x: evm: Update function calls for splash screen include: video: Reserve video using blob common: board_f: Pass frame buffer info from SPL to u-boot drivers: video: Kconfig: Add config remove video common: spl: spl: Remove video driver configs: am62x_evm_a53: Add bloblist address arch/arm/mach-k3/am625_init.c | 1 + arch/arm/mach-k3/common.c | 2 ++ board/ti/am62x/evm.c| 41 - common/board_f.c| 12 +- common/spl/spl.c| 3 ++- configs/am62x_evm_a53_defconfig | 1 + drivers/video/Kconfig | 13 +++ drivers/video/video-uclass.c| 23 ++ include/video.h | 9 9 files changed, 77 insertions(+), 28 deletions(-) -- 2.34.1
[PATCH 3/3] sunxi: Kconfig: rework PHY_USB_SUN4I selection
At the moment we use "select" in each Allwinner SoC's Kconfig section to include the USB PHY driver in the build. This means it cannot be disabled via Kconfig, although USB is not really a strictly required core functionality, and a particular board might not even include USB ports. Rework the Kconfig part by removing the "select" lines for each SoC's section, and instead letting it default to "y" in the PHY driver section itself. We use "depends on !" to exclude the few SoCs we don't support (yet). The Allwinner V3s does not enable USB (PHY) support at the moment, even though it should work: let the PHY default to "n" to keep the current behaviour. Signed-off-by: Andre Przywara --- arch/arm/mach-sunxi/Kconfig | 11 --- drivers/phy/allwinner/Kconfig | 6 +- 2 files changed, 5 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 6dcbb096f74..e0b1bde35a9 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -207,7 +207,6 @@ endif config MACH_SUNXI_H3_H5 bool - select PHY_SUN4I_USB select SUNXI_DE2 select SUNXI_DRAM_DW select SUNXI_DRAM_DW_32BIT @@ -236,7 +235,6 @@ config MACH_SUNIV config MACH_SUN4I bool "sun4i (Allwinner A10)" select CPU_V7A - select PHY_SUN4I_USB select DRAM_SUN4I select SUNXI_GEN_SUN4I select SUPPORT_SPL @@ -247,7 +245,6 @@ config MACH_SUN5I bool "sun5i (Allwinner A13)" select CPU_V7A select DRAM_SUN4I - select PHY_SUN4I_USB select SUNXI_GEN_SUN4I select SUPPORT_SPL imply SPL_SYS_I2C_LEGACY @@ -261,7 +258,6 @@ config MACH_SUN6I select ARCH_SUPPORT_PSCI select SPL_ARMV7_SET_CORTEX_SMPEN select DRAM_SUN6I - select PHY_SUN4I_USB select SPL_I2C select SUN6I_PRCM select SUNXI_GEN_SUN6I @@ -277,7 +273,6 @@ config MACH_SUN7I select ARCH_SUPPORT_PSCI select SPL_ARMV7_SET_CORTEX_SMPEN select DRAM_SUN4I - select PHY_SUN4I_USB select SUNXI_GEN_SUN4I select SUPPORT_SPL select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT @@ -291,7 +286,6 @@ config MACH_SUN8I_A23 select CPU_V7_HAS_VIRT select ARCH_SUPPORT_PSCI select DRAM_SUN8I_A23 - select PHY_SUN4I_USB select SPL_I2C select SUNXI_GEN_SUN6I select SUPPORT_SPL @@ -305,7 +299,6 @@ config MACH_SUN8I_A33 select CPU_V7_HAS_VIRT select ARCH_SUPPORT_PSCI select DRAM_SUN8I_A33 - select PHY_SUN4I_USB select SPL_I2C select SUNXI_GEN_SUN6I select SUPPORT_SPL @@ -316,7 +309,6 @@ config MACH_SUN8I_A83T bool "sun8i (Allwinner A83T)" select CPU_V7A select DRAM_SUN8I_A83T - select PHY_SUN4I_USB select SPL_I2C select SUNXI_GEN_SUN6I select MMC_SUNXI_HAS_NEW_MODE @@ -344,7 +336,6 @@ config MACH_SUN8I_R40 select SUPPORT_SPL select SUNXI_DRAM_DW select SUNXI_DRAM_DW_32BIT - select PHY_SUN4I_USB imply SPL_SYS_I2C_LEGACY config MACH_SUN8I_V3S @@ -372,7 +363,6 @@ config MACH_SUN9I config MACH_SUN50I bool "sun50i (Allwinner A64)" select ARM64 - select PHY_SUN4I_USB select SUN6I_PRCM select SUNXI_DE2 select SUNXI_GEN_SUN6I @@ -395,7 +385,6 @@ config MACH_SUN50I_H5 config MACH_SUN50I_H6 bool "sun50i (Allwinner H6)" select ARM64 - select PHY_SUN4I_USB select DRAM_SUN50I_H6 select SUN50I_GEN_H6 diff --git a/drivers/phy/allwinner/Kconfig b/drivers/phy/allwinner/Kconfig index f8f1e99c4f5..565b4617b01 100644 --- a/drivers/phy/allwinner/Kconfig +++ b/drivers/phy/allwinner/Kconfig @@ -4,6 +4,10 @@ config PHY_SUN4I_USB bool "Allwinner Sun4I USB PHY driver" depends on ARCH_SUNXI + depends on !MACH_SUN9I + depends on !MACH_SUN50I_H616 + default n if MACH_SUN8I_V3S + default y select DM_REGULATOR select PHY help @@ -11,7 +15,7 @@ config PHY_SUN4I_USB sunxi SoCs. This driver controls the entire USB PHY block, both the USB OTG - parts, as well as the 2 regular USB 2 host PHYs. + parts, as well as the regular USB HCI host PHYs. config INITIAL_USB_SCAN_DELAY int "Delay initial USB scan by x ms to allow builtin devices to init" -- 2.25.1
[PATCH 2/3] phy: sun4i-usb: add Allwinner F1C100s support
The Allwinner F1C100s implements a single USB PHY, connected to its MUSB OTG controller. The USB PHY is of the simpler, older type (like the A10), the only real difference is that it's indeed only one PHY. Add a struct describing those F1C100s USB PHY properties, and connect it to the new compatible string. Signed-off-by: Andre Przywara --- drivers/phy/allwinner/phy-sun4i-usb.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c index dbea70f9a5e..2bf47fc36a7 100644 --- a/drivers/phy/allwinner/phy-sun4i-usb.c +++ b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -648,6 +648,14 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = { .missing_phys = BIT(1) | BIT(2), }; +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { + .num_phys = 1, + .type = sun4i_a10_phy, + .disc_thresh = 3, + .phyctl_offset = REG_PHYCTL_A10, + .dedicated_clocks = true, +}; + static const struct udevice_id sun4i_usb_phy_ids[] = { { .compatible = "allwinner,sun4i-a10-usb-phy", .data = (ulong)&sun4i_a10_cfg }, { .compatible = "allwinner,sun5i-a13-usb-phy", .data = (ulong)&sun5i_a13_cfg }, @@ -662,6 +670,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = { { .compatible = "allwinner,sun20i-d1-usb-phy", .data = (ulong)&sun20i_d1_cfg }, { .compatible = "allwinner,sun50i-a64-usb-phy", .data = (ulong)&sun50i_a64_cfg}, { .compatible = "allwinner,sun50i-h6-usb-phy", .data = (ulong)&sun50i_h6_cfg}, + { .compatible = "allwinner,suniv-f1c100s-usb-phy", .data = (ulong)&suniv_f1c100s_cfg }, { } }; -- 2.25.1
[PATCH 1/3] phy: sun4i-usb: Fix of_xlate() argument check
In its of_xlate() function, the Allwinner USB PHY driver compares the args_count variable against the number of implemented USB PHYs, although this is the *number of arguments* to the DT phandle property. Per the DT binding for this PHY device, this number is always one, so this check will always fail if the particular SoC implements exactly one USB PHY. So far this affected only the V3s (which has USB support disabled), but the F1C100s also sports one PHY only. Fix that check to compare args_count against exactly 1, and the args[0] content (requested PHY number) against the number of implemented PHYs. This fixes USB operation on the Allwinner V3s and allows to enable USB on the Allwinner F1C100s SoC. Signed-off-by: Andre Przywara --- drivers/phy/allwinner/phy-sun4i-usb.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c index 6428163c188..dbea70f9a5e 100644 --- a/drivers/phy/allwinner/phy-sun4i-usb.c +++ b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -372,7 +372,10 @@ static int sun4i_usb_phy_xlate(struct phy *phy, { struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev); - if (args->args_count >= data->cfg->num_phys) + if (args->args_count != 1) + return -EINVAL; + + if (args->args[0] >= data->cfg->num_phys) return -EINVAL; if (data->cfg->missing_phys & BIT(args->args[0])) -- 2.25.1
[PATCH 0/3] phy: sun4i: Allwinner F1C100s support and cleanup
This mini series adds support for the Allwinner F1C100s USB PHY. There is really not much to it, we just need to connect the compatible string to a description that says we have one "old-style" PHY (patch 2/3). Doing this revealed a bug, which is fixed in patch 1/3. Also use the opportunity to fix a long-standing annoyance: we were "select"ing the USB PHY driver from each SoC's Kconfig stanza, which does not only look questionable, but also prevents USB support from being deliberately disabled, for boards without USB sockets or to save memory and boot time. The fix in patch 1/3 is not urgent, since we were not hitting this condition before, so this would all be 2023.10 material. Cheers, Andre Andre Przywara (3): phy: sun4i-usb: Fix of_xlate() argument check phy: sun4i-usb: add Allwinner F1C100s support sunxi: Kconfig: rework PHY_USB_SUN4I selection arch/arm/mach-sunxi/Kconfig | 11 --- drivers/phy/allwinner/Kconfig | 6 +- drivers/phy/allwinner/phy-sun4i-usb.c | 14 +- 3 files changed, 18 insertions(+), 13 deletions(-) -- 2.25.1
Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization
On Wed, 7 Jun 2023 17:16:44 -0600 Sam Edwards wrote: Hi Sam, > This is largely a cosmetic change, with one functional distinction: > We are now only setting BIT(0), and no longer clearing BIT(1). > > The new comments and function name are not from any official source, > but are updated to mirror how the Linux kernel sources treat this > mystery magic bit. If we wanted to confirm that this speculation is > correct, we could verify that SRAM-D is inaccessible whenever the > bit is set, and then try clearing it again while the MUSB is in use > to see what debris gets left behind in SRAM-D. > > This cleanup also adds a TODO comment about runtime discovery > of the SYSCON base, per discussion with Andre. thanks for sending this, looks good. Some stylistic comments below. > > Signed-off-by: Sam Edwards > Cc: Andre Przywara > --- > drivers/usb/musb-new/sunxi.c | 28 > 1 file changed, 20 insertions(+), 8 deletions(-) > > diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c > index c05c0d5561..2b954601a0 100644 > --- a/drivers/usb/musb-new/sunxi.c > +++ b/drivers/usb/musb-new/sunxi.c > @@ -173,15 +173,23 @@ static void USBC_ForceVbusValidToHigh(__iomem void > *base) > musb_writel(base, USBC_REG_o_ISCR, reg_val); > } > > -static void USBC_ConfigFIFO_Base(void) > +/** > + * Non-USBC register access needed for initialization > + > **/ > + > +/* A10(s), A13, GR8, A20: > + * switch ownership of SRAM block 'D' to the USB-OTG controller */ > +#define OFF_SUNXI_SRAMCTRL_D (0x04) > +#define SUNXI_SRAMCTRL_D_FLAG_USBOTG BIT(0) I am regularly not convinced that adding longish single-use macro names for simple bit flips is really easier to read, because you always have to lookup the definition first. If you decide to stick with it anyway, please lose the parentheses around the 0x04, and use OFS_ instead of OFF_. Or better use the name from the manual: SRAM_CTRL_REG1. > + > +static void sunxi_musb_claim_sram(void) > { > - u32 reg_value; > + /* TODO: Do not use hardcoded SUNXI_SRAMC_BASE; find the syscon base by I think we should use "non-net" commenting style, with the "/*" on a line on its own. > + * traversing this OTG device's `allwinner,sram` FDT property and > + * working upward to the system controller. */ > > - /* config usb fifo, 8kb mode */ > - reg_value = readl(SUNXI_SRAMC_BASE + 0x04); > - reg_value &= ~(0x03 << 0); > - reg_value |= BIT(0); > - writel(reg_value, SUNXI_SRAMC_BASE + 0x04); > + setbits_le32(SUNXI_SRAMC_BASE + OFF_SUNXI_SRAMCTRL_D, > + SUNXI_SRAMCTRL_D_FLAG_USBOTG); So this is the harder to understand part, IMO. If you stick something like "Bit 0 in SRAM_CTRL_REG (offset 0x4) controls the SRAM D ownership." in the comment above, then a simple: setbits_le32(SUNXI_SRAMC_BASE + 0x04, BIT(0)); becomes much easier to parse and relate to the manual, at least to my eyes. > } > > > /** > @@ -315,7 +323,11 @@ static int sunxi_musb_init(struct musb *musb) > musb->isr = sunxi_musb_interrupt; > > if (glue->cfg->has_sram) { > - USBC_ConfigFIFO_Base(); > + /* This is an older USB-OTG controller that Allwinner did not Same commenting style issue like above. Otherwise thanks for clearing this up, also for the future readers! Cheers, Andre > + * endow with a dedicated SRAM block; it instead uses SRAM > + * block 'D', ownership of which needs to be handed over by > + * the CPU */ > + sunxi_musb_claim_sram(); > } > > USBC_EnableDpDmPullUp(musb->mregs);
Re: [PATCH 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary
On Wed, 7 Jun 2023 17:16:43 -0600 Sam Edwards wrote: Hi, > Only the older (ca. A10, A20) sunxis need this poke for the MUSB to > function. Mimic the Linux kernel and add a `has_sram` flag to the config > structure that is only set for the specific compatibles that require > this initialization. So I grabbed a BananaPi (A20) and played with it a little. Gadgets still work with this patch, also I can confirm that this bit is necessary (turned it off with mw.l, and the gadget stopped working), and also that the bit flip works (set "has_sram = false;" and it didn't work anymore). Also tested on an OrangePi Zero (H3), which doesn't need the SRAM switch. It worked with both the bit set and cleared, also before and after the patch, so it's all fine. > Signed-off-by: Sam Edwards Reviewed-by: Andre Przywara Tested-by: Andre Przywara Thanks, Andre > --- > drivers/usb/musb-new/sunxi.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c > index ab55d68620..c05c0d5561 100644 > --- a/drivers/usb/musb-new/sunxi.c > +++ b/drivers/usb/musb-new/sunxi.c > @@ -85,6 +85,7 @@ > > struct sunxi_musb_config { > struct musb_hdrc_config *config; > + bool has_sram; > }; > > struct sunxi_glue { > @@ -313,7 +314,10 @@ static int sunxi_musb_init(struct musb *musb) > > musb->isr = sunxi_musb_interrupt; > > - USBC_ConfigFIFO_Base(); > + if (glue->cfg->has_sram) { > + USBC_ConfigFIFO_Base(); > + } > + > USBC_EnableDpDmPullUp(musb->mregs); > USBC_EnableIdPullUp(musb->mregs); > > @@ -525,6 +529,7 @@ static int musb_usb_remove(struct udevice *dev) > > static const struct sunxi_musb_config sun4i_a10_cfg = { > .config = &musb_config, > + .has_sram = true, > }; > > static const struct sunxi_musb_config sun6i_a31_cfg = {
Re: [PATCH 0/1] virtio: add driver for virtio_console devices
Hi, On Tue, Jun 6, 2023 at 9:26 PM Ying-Chun Liu (PaulLiu) wrote: > > This is an implementation of single-character virtio-console. Part of the > patch is based on barebox implementations. > > To test the patch, we can build qemu_arm64_defconfig target. Enable > CONFIG_VIRTIO_CONSOLE. And run qemu-system-aarch64 with > -device virtio-serial-pci,id=virtio-serial0 \ > -chardev file,id=charconsole0,path=/tmp/serialconsolelog \ > -device virtconsole,chardev=charconsole0,id=console0 \ > With this command, it still uses the on-board UART but not virtio-console. Would you please post test instructions on using virtio-console as the U-Boot serial console? Thanks! > When in U-boot console, type "dm tree" and we should be able to see the > virtio-console device. > > A. Cody Schuffelen (1): > virtio: add driver for virtio_console devices > > drivers/virtio/Kconfig | 8 ++ > drivers/virtio/Makefile | 1 + > drivers/virtio/virtio-uclass.c | 1 + > drivers/virtio/virtio_console.c | 158 > include/virtio.h| 2 + > 5 files changed, 170 insertions(+) > create mode 100644 drivers/virtio/virtio_console.c > > -- Regards, Bin
[PATCH 6/6] xilinx: zynq: Add the missing function prototypes
From: Algapally Santosh Sagar Add the missing prototypes for the functions pointed by the below sparse warnings warning: no previous prototype for 'set_dfu_alt_info' [-Wmissing-prototypes] warning: no previous prototype for 'board_debug_uart_init' [-Wmissing-prototypes] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/zynq/board.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c index 9a59445b44..3b6581e304 100644 --- a/board/xilinx/zynq/board.c +++ b/board/xilinx/zynq/board.c @@ -5,6 +5,8 @@ */ #include +#include +#include #include #include #include -- 2.17.1
[PATCH 5/6] arm: zynq: Pass the missing argument type in function definition
From: Algapally Santosh Sagar Pass missing argument type in the function definition to fix the sparse warning, warning: old-style function definition [-Wold-style-definition] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c index 796e5b0c5f..6b153aa379 100644 --- a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c +++ b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c @@ -12648,7 +12648,7 @@ unsigned long *ps7_ddr_init_data = ps7_ddr_init_data_3_0; unsigned long *ps7_peripherals_init_data = ps7_peripherals_init_data_3_0; int -ps7_post_config() +ps7_post_config(void) { // Get the PS_VERSION on run time unsigned long si_ver = ps7GetSiliconVersion (); @@ -12667,7 +12667,7 @@ ps7_post_config() } int -ps7_init() +ps7_init(void) { // Get the PS_VERSION on run time unsigned long si_ver = ps7GetSiliconVersion (); -- 2.17.1
[PATCH 4/6] mtd: nand: zynq_nand: Change datatype of status and ecc_status to int
From: Algapally Santosh Sagar status and ecc_status are of unsigned type where they are compared for negative value. This is pointed by below sparse warning. Change datatype to int to fix this. warning: comparison of unsigned expression in '< 0' is always false [-Wtype-limits] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/mtd/nand/raw/zynq_nand.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/raw/zynq_nand.c b/drivers/mtd/nand/raw/zynq_nand.c index 9e3ee7412d..545fdd7b69 100644 --- a/drivers/mtd/nand/raw/zynq_nand.c +++ b/drivers/mtd/nand/raw/zynq_nand.c @@ -285,7 +285,7 @@ static int zynq_nand_init_nand_flash(struct mtd_info *mtd, int option) { struct nand_chip *nand_chip = mtd_to_nand(mtd); struct nand_drv *smc = nand_get_controller_data(nand_chip); - u32 status; + int status; /* disable interrupts */ writel(ZYNQ_NAND_CLR_CONFIG, &smc->reg->cfr); @@ -332,7 +332,7 @@ static int zynq_nand_calculate_hwecc(struct mtd_info *mtd, const u8 *data, struct nand_drv *smc = nand_get_controller_data(nand_chip); u32 ecc_value = 0; u8 ecc_reg, ecc_byte; - u32 ecc_status; + int ecc_status; /* Wait till the ECC operation is complete */ ecc_status = zynq_nand_waitfor_ecc_completion(mtd); -- 2.17.1
[PATCH 3/6] spi: zynq_qspi: Add missing prototype for zynq_qspi_mem_exec_op
From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'zynq_qspi_mem_exec_op' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/spi/zynq_qspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c index d1d4048966..cb52c0f307 100644 --- a/drivers/spi/zynq_qspi.c +++ b/drivers/spi/zynq_qspi.c @@ -747,8 +747,8 @@ static int zynq_qspi_check_buswidth(struct spi_slave *slave, u8 width) return -EOPNOTSUPP; } -bool zynq_qspi_mem_exec_op(struct spi_slave *slave, - const struct spi_mem_op *op) +static bool zynq_qspi_mem_exec_op(struct spi_slave *slave, + const struct spi_mem_op *op) { if (zynq_qspi_check_buswidth(slave, op->cmd.buswidth)) return false; -- 2.17.1
[PATCH 2/6] xilinx: zynq: Add missing prototype for zynqmp_mmio_write
From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'zynqmp_mmio_write' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- arch/arm/mach-zynq/include/mach/sys_proto.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-zynq/include/mach/sys_proto.h b/arch/arm/mach-zynq/include/mach/sys_proto.h index 268ec50ad8..74f9665fbb 100644 --- a/arch/arm/mach-zynq/include/mach/sys_proto.h +++ b/arch/arm/mach-zynq/include/mach/sys_proto.h @@ -16,5 +16,6 @@ extern u32 zynq_slcr_get_idcode(void); extern int zynq_slcr_get_mio_pin_status(const char *periph); extern void zynq_ddrc_init(void); extern unsigned int zynq_get_silicon_version(void); +int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value); #endif /* _SYS_PROTO_H_ */ -- 2.17.1
[PATCH 1/6] spi: xilinx_spi: Add missing prototype for xilinx_qspi_mem_exec_op
From: Algapally Santosh Sagar Add missing prototype to fix the below sparse warning warning: no previous prototype for 'xilinx_qspi_mem_exec_op' [-Wmissing-prototypes] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/spi/xilinx_spi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c index 33575fe757..b58a3f632a 100644 --- a/drivers/spi/xilinx_spi.c +++ b/drivers/spi/xilinx_spi.c @@ -363,8 +363,8 @@ static int xilinx_qspi_check_buswidth(struct spi_slave *slave, u8 width) return -EOPNOTSUPP; } -bool xilinx_qspi_mem_exec_op(struct spi_slave *slave, -const struct spi_mem_op *op) +static bool xilinx_qspi_mem_exec_op(struct spi_slave *slave, + const struct spi_mem_op *op) { if (xilinx_qspi_check_buswidth(slave, op->cmd.buswidth)) return false; -- 2.17.1
[PATCH 0/6] Fix sparse warnings in zynq platform
Fix below sparse warnings - Add missing prototype for zynqmp_mmio_write - Add missing prototype for zynq_qspi_mem_exec_op - Change datatype of status and ecc_status from u32 to int - Pass the missing argument type in function definition - Add the missing function prototypes - Add missing prototype for xilinx_qspi_mem_exec_op Algapally Santosh Sagar (6): spi: xilinx_spi: Add missing prototype for xilinx_qspi_mem_exec_op xilinx: zynq: Add missing prototype for zynqmp_mmio_write spi: zynq_qspi: Add missing prototype for zynq_qspi_mem_exec_op mtd: nand: zynq_nand: Change datatype of status and ecc_status to int arm: zynq: Pass the missing argument type in function definition xilinx: zynq: Add the missing function prototypes arch/arm/mach-zynq/include/mach/sys_proto.h | 1 + board/xilinx/zynq/board.c | 2 ++ board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c | 4 ++-- drivers/mtd/nand/raw/zynq_nand.c| 4 ++-- drivers/spi/xilinx_spi.c| 4 ++-- drivers/spi/zynq_qspi.c | 4 ++-- 6 files changed, 11 insertions(+), 8 deletions(-) -- 2.17.1
[PATCH 2/2] arm64: versal: Add missing prototypes
From: Algapally Santosh Sagar Add missing prototypes to fix the below sparse warnings 1. warning: no previous prototype for 'set_r5_halt_mode' [-Wmissing-prototypes] 2. warning: no previous prototype for 'set_r5_tcm_mode' [-Wmissing-prototypes] 3. warning: no previous prototype for 'release_r5_reset' [-Wmissing-prototypes] 4.warning: no previous prototype for 'enable_clock_r5' [-Wmissing-prototypes] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- arch/arm/mach-versal/mp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-versal/mp.c b/arch/arm/mach-versal/mp.c index 9b0518d6a2..5b850f3f89 100644 --- a/arch/arm/mach-versal/mp.c +++ b/arch/arm/mach-versal/mp.c @@ -23,7 +23,7 @@ #define VERSAL_CRL_RST_CPU_R5_RESET_PGE_MASK 0x10 #define VERSAL_CRLAPB_CPU_R5_CTRL_CLKACT_MASK 0x100 -void set_r5_halt_mode(u8 halt, u8 mode) +static void set_r5_halt_mode(u8 halt, u8 mode) { u32 tmp; @@ -44,7 +44,7 @@ void set_r5_halt_mode(u8 halt, u8 mode) } } -void set_r5_tcm_mode(u8 mode) +static void set_r5_tcm_mode(u8 mode) { u32 tmp; @@ -62,7 +62,7 @@ void set_r5_tcm_mode(u8 mode) writel(tmp, &rpu_base->rpu_glbl_ctrl); } -void release_r5_reset(u8 mode) +static void release_r5_reset(u8 mode) { u32 tmp; @@ -77,7 +77,7 @@ void release_r5_reset(u8 mode) writel(tmp, &crlapb_base->rst_cpu_r5); } -void enable_clock_r5(void) +static void enable_clock_r5(void) { u32 tmp; -- 2.17.1
[PATCH 1/2] arm64: versal: Add missing prototype for initialize_tcm
From: Algapally Santosh Sagar Add the missing prototype pointed by below sparse warning warning: no previous prototype for 'initialize_tcm' [-Wmissing-prototypes] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- arch/arm/mach-versal/include/mach/sys_proto.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-versal/include/mach/sys_proto.h b/arch/arm/mach-versal/include/mach/sys_proto.h index 3f01508ecb..433f9ba07c 100644 --- a/arch/arm/mach-versal/include/mach/sys_proto.h +++ b/arch/arm/mach-versal/include/mach/sys_proto.h @@ -10,6 +10,7 @@ enum { TCM_SPLIT, }; +void initialize_tcm(bool mode); void tcm_init(u8 mode); void mem_map_fill(void); -- 2.17.1
[PATCH 0/2] Fix sparse warnings
In this patch series, fix sparse warnings in below files - arch/arm/mach-versal/mp.c - arch/arm/mach-versal/include/mach/sys_proto.h Algapally Santosh Sagar (2): arm64: versal: Add missing prototype for initialize_tcm arm64: versal: Add missing prototypes arch/arm/mach-versal/include/mach/sys_proto.h | 1 + arch/arm/mach-versal/mp.c | 8 2 files changed, 5 insertions(+), 4 deletions(-) -- 2.17.1
Re: rk3328 efuse return just 0
Hi Jonas, On Fri, Jun 9, 2023 at 1:06 AM Jonas Karlman wrote: > Hi Marek, > > On 2023-06-08 15:06, Belisko Marek wrote: > > Hi, > > > > I'm using tip of actual master and with this small patches: > > --- a/configs/rock-pi-e-rk3328_defconfig > > +++ b/configs/rock-pi-e-rk3328_defconfig > > @@ -73,6 +73,8 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800 > > CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > > CONFIG_ROCKCHIP_GPIO=y > > CONFIG_SYS_I2C_ROCKCHIP=y > > +CONFIG_MISC=y > > +CONFIG_ROCKCHIP_EFUSE=y > > CONFIG_MMC_DW=y > > CONFIG_MMC_DW_ROCKCHIP=y > > CONFIG_ETH_DESIGNWARE=y > > > > --- a/configs/rock-pi-e-rk3328_defconfig > > +++ b/configs/rock-pi-e-rk3328_defconfig > > @@@ -45,8 -34,6 +45,7 @@@ CONFIG_SPL_I2C= > > CONFIG_SPL_POWER=y > > CONFIG_SPL_ATF=y > > CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > > +CONFIG_TPL_SYS_MALLOC_SIMPLE=y > > - CONFIG_TPL_DRIVERS_MISC=y > > CONFIG_CMD_BOOTZ=y > > CONFIG_CMD_GPT=y > > CONFIG_CMD_MMC=y > > > > as for the following issue: > > > /home/marek/data/projects/u-boot/drivers/misc/rockchip-efuse.c:273:(.text.rockchip_efuse_of_to_plat+0x1c): > > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol > > `dev_read_addr_ptr' > How about this issue? I can send a patch to fix that. > > > > I'm trying to enable proper ethaddr handling (as in this case cpuid# is > > used for ethaddr generation). > > > > With those enabled options I'm still getting an cpuid# variable set to > all > > '0'. Is there some other fix necessary maybe? > > I was able to reproduce this issue on my Rock Pi E using plain mainline > arm-trusted-firmware. To use efuse on RK3328 the efuse block needs to be > initialized, u-boot does not do this. > Thanks for the info. I've applied a patch from armbian and it started working! > > Two options to work around this can be: > 1. Use vendor bl31 blob from [1] > 2. Patch mainline atf with a patch from [2] > > [1] > https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk322xh_bl31_v1.49.elf > [2] > https://github.com/armbian/build/blob/main/patch/atf/atf-rockchip64/rk3328-efuse-init.patch > > Regards, > Jonas > > > > > Thanks and BR, > > > > marek > > Cheers, marek
Re: [PATCH] spl: spl_fit: add weak prototype for fpga_load
On 2/27/23 12:27, Eugen Hristev wrote: In case OPTIMIZE_DEBUG is set, unused code will not be optimized out, hence the reference to fpga_load will be compiled. if DM_FPGA and SPL_FPGA are not set, the build will fail with : aarch64-none-linux-gnu-ld.bfd: common/spl/spl_fit.o: in function `spl_fit_upload_fpga': u-boot/common/spl/spl_fit.c:595: undefined reference to `fpga_load' By adding a weak prototype, build is successful. Signed-off-by: Eugen Hristev --- common/spl/spl_fit.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index c51482b3b659..ca2e337b1ec4 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -570,6 +570,12 @@ static void warn_deprecated(const char *msg) printf("\tSee doc/uImage.FIT/source_file_format.txt\n"); } +__weak int fpga_load(int devnum, const void *buf, size_t bsize, +bitstream_type bstype, int flags) +{ + return 0; +} + static int spl_fit_upload_fpga(struct spl_fit_info *ctx, int node, struct spl_image_info *fpga_image) { Gentle ping
Re: [PATCH v6 1/7] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On Mon, Mar 06, 2023 at 05:18:14PM -0600, jassisinghb...@gmail.com wrote: > From: Jassi Brar > > Any requirement of FWU should not require changes to bindings > of other subsystems. For example, for mtd-backed storage we > can do without requiring 'fixed-partitions' children to also > carry 'uuid', a property which is non-standard and not in the > bindings. > The existing bindings were constructed like that in case we wanted to upstream the dt-bindings. But I think we are fine keeping it as an internal ABI for now. Note here that we will need to strip this eventually before we hand over the dtb into linux, but that's a different story. In any case as long as the DT comes from u-boot I don't think we will have a risk of introducing compatibility issues if we ever upstream this and go back to the old format. Acked-by: Ilias Apalodimas > There exists no code yet, so we can change the fwu-mtd bindings > to contain all properties within the fwu-mdata node. > > Signed-off-by: Jassi Brar > --- > .../firmware/fwu-mdata-mtd.yaml | 105 +++--- > 1 file changed, 91 insertions(+), 14 deletions(-) > > diff --git a/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml > b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml > index 4f5404f999..6a22aeea30 100644 > --- a/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml > +++ b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml > @@ -1,13 +1,13 @@ > # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > %YAML 1.2 > --- > -$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml# > -$schema: http://devicetree.org/meta-schemas/core.yaml# > +$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-mtd.yaml# > +$schema: http://devicetree.org/meta-schemas/base.yaml# > > title: FWU metadata on MTD device without GPT > > maintainers: > - - Masami Hiramatsu > + - Jassi Brar > > properties: >compatible: > @@ -15,24 +15,101 @@ properties: >- const: u-boot,fwu-mdata-mtd > >fwu-mdata-store: > -maxItems: 1 > -description: Phandle of the MTD device which contains the FWU medatata. > +$ref: /schemas/types.yaml#/definitions/phandle > +description: Phandle of the MTD device which contains the FWU MetaData > and Banks. > > - mdata-offsets: > + mdata-parts: > +$ref: /schemas/types.yaml#/definitions/non-unique-string-array > minItems: 2 > -description: Offsets of the primary and secondary FWU metadata in the > NOR flash. > +maxItems: 2 > +description: labels of the primary and secondary FWU metadata partitions > in the 'fixed-partitions' subnode of the 'jedec,spi-nor' flash device node. > + > + patternProperties: > +"fwu-bank[0-9]": > +type: object > +description: List of FWU mtd-backed banks. Typically two banks. > + > +properties: > + id: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Index of the bank. > + > + label: > +$ref: /schemas/types.yaml#/definitions/non-unique-string-array > +minItems: 1 > +maxItems: 1 > +description: label of the partition, in the 'fixed-partitions' > subnode of the 'jedec,spi-nor' flash device node, that holds this bank. > + > + patternProperties: > +"fwu-image[0-9]": > +type: object > +description: List of images in the FWU mtd-backed bank. > + > +properties: > + id: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Index of the bank. > + > + offset: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Offset, from start of the bank, where the image is > located. > + > + size: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Size reserved for the image. > + > + uuid: > +$ref: /schemas/types.yaml#/definitions/non-unique-string-array > +minItems: 1 > +maxItems: 1 > +description: UUID of the image. > + > +required: > + - id > + - offset > + - size > + - uuid > +additionalProperties: false > + > +required: > + - id > + - label > + - fwu-images > +additionalProperties: false > > required: >- compatible >- fwu-mdata-store > - - mdata-offsets > - > + - mdata-parts > + - fwu-banks > additionalProperties: false > > examples: >- | > -fwu-mdata { > -compatible = "u-boot,fwu-mdata-mtd"; > -fwu-mdata-store = <&spi-flash>; > -mdata-offsets = <0x50 0x53>; > -}; > + fwu-mdata { > + compatible = "u-boot,fwu-mdata-mtd"; > + fwu-mdata-store = <&flash0>; > + mdata-parts = "MDATA-Pri", "MDATA-Sec"; > + > + fwu-bank0 { > + id = <0>; > + label = "FIP-Bank0"; > + fwu-image0 { >
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
On Thu, Jun 8, 2023 at 6:56 PM Ilias Apalodimas wrote: > > Thanks Maxim, > > On Thu, 8 Jun 2023 at 13:14, Maxim Uvarov wrote: > > > > Ilias asked to make more clear results to compare the original stack and > > LWIP stack. So the difference between the current U-boot stack and the LWIP > > stack with 3 network commands is: > > a) 18Kb - ls -lh size > > b) 15Kb - bloat-o-meter script total line report. > > > > BOM=linux/scripts/bloat-o-meter (script) > > > > 1. 893K - U-boot CMD_NET=n > > 2. 928K - U-boot CMD_NET=y TFTP=y PING=y WGET=y > > BOM 1-2: Total: Before=692286, After=722283, chg +4.33% > > 3. 940K - U-boot CMD_NET=n, LWIP_TFTP=y LWIP_PING=y LWIP_PING=y > > BOM 1-3: Total: Before=692286, After=738425, chg +6.66% > > That's much more readable! I discussed this with Tom over IRC and the > size difference is certainly a reasonable trade-off for the extra > functionality. Yes, this looks great! I'm also sure with a closer look there could be further optimisations here in time as well. I feel having a widely used IP stack that's also widely audited is a big win here, it will also provide things like HTTP, DNS and IPv6 without having to reinvent the wheel. > Can you tidy up the series and include DHCP and PXE done through LWIP? I'll look forward to this. > Thanks > /Ilias > > > > BOM 2-3: > > > > add/remove: 287/203 grow/shrink: 3/11 up/down: 43459/-27317 (16142) > > Function old new delta > > tcp_input -3588 +3588 > > tcp_receive-2884 +2884 > > ip4_reass -1760 +1760 > > tcp_output -1400 +1400 > > tcp_write -1300 +1300 > > tcp_slowtmr-1172 +1172 > > httpc_tcp_recv -1044 +1044 > > tftp_recv - 888+888 > > ip4_input - 700+700 > > ip4_frag - 632+632 > > icmp_input - 604+604 > > udp_input - 596+596 > > etharp_input - 512+512 > > tcp_split_unsent_seg - 500+500 > > ip4addr_aton - 492+492 > > tcp_alloc - 484+484 > > ip4_output_if_src - 476+476 > > tcp_close_shutdown - 448+448 > > etharp_query - 436+436 > > httpc_init_connection_common.constprop - 416+416 > > udp_sendto_if_src - 408+408 > > etharp_output - 404+404 > > arp_table - 400+400 > > tcp_connect- 396+396 > > pbuf_alloc - 376+376 > > etharp_find_entry - 372+372 > > tcp_abandon- 368+368 > > tcp_zero_window_probe - 356+356 > > raw_sendto_if_src - 328+328 > > pbuf_copy_partial_pbuf - 328+328 > > ip_reass_free_complete_datagram- 328+328 > > tcp_create_segment - 300+300 > > raw_input - 292+292 > > uboot_lwip_init- 284+284 > > ethernet_input - 284+284 > > etharp_raw - 284+284 > > tcp_output_alloc_header_common.constprop - 280+280 > > cmds - 280+280 > > udp_bind - 276+276 > > tcp_oos_insert_segment - 276+276 > > ip_reass_remove_oldest_datagram- 272+272 > > icmp_send_response - 268+268 > > netif_add - 260+260 > > ping_send - 244+244 > > tcp_rexmit - 232+232 > > tcp_parseopt - 220+220 > > tcp_free_acked_segments.constprop - 220+220 > > send_request - 220+220 > > inet_chksum_pseudo - 216+216 > > ip4addr_ntoa_r - 212+212 > > do_lwip_ping - 212+212 > > tcp_enqueue