Re: [PATCH 4/6] mtd: nand: zynq_nand: Change datatype of status and ecc_status to int
Hi
On Fri, Jun 9, 2023 at 11:22 AM Ashok Reddy Soma
wrote:
>
> 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);
> --
Reviewed-By: Michael Trimarchi
> 2.17.1
>
Re: [PATCH 0/6] Fix sparse warnings in zynq platform
On 6/9/23 11:21, Ashok Reddy Soma wrote: 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(-) The rest looks good to me. Thanks, Michal
Re: [PATCH 5/6] arm: zynq: Pass the missing argument type in function definition
On 6/9/23 11:22, Ashok Reddy Soma wrote: 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 ++-- I see the same thing also board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c:12430:ps7_init() board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c:12763:ps7_init() board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c:12670:ps7_init() board/xilinx/zynq/zynq-zed/ps7_init_gpl.c:12328:ps7_init() board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c:12411:ps7_post_config() board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c:12744:ps7_post_config() board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c:12651:ps7_post_config() board/xilinx/zynq/zynq-zed/ps7_init_gpl.c:12309:ps7_post_config() Thanks, Michal
Re: [PATCH 2/6] xilinx: zynq: Add missing prototype for zynqmp_mmio_write
On 6/9/23 11:21, Ashok Reddy Soma wrote: 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_ */ This should be done differently. It should go to include/zynqmp_firmware.h and remove it from platform sys_proto.h file. Thanks, Michal
Re: [PATCH 0/2] Fix sparse warnings
On 6/9/23 11:05, Ashok Reddy Soma wrote: 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(-) Applied. M
Re: [PATCH 0/2] Fix the tcminit command
On 6/8/23 05:21, Venkatesh Yadav Abbarapu wrote: Fix the tcminit mode param and cpu release lockstep functionality. Venkatesh Yadav Abbarapu (2): arm64: zynqmp: Fix tcminit mode param arm64: zynqmp: Fix lockstep mode cpu release functionality arch/arm/mach-zynqmp/mp.c | 4 board/xilinx/zynqmp/cmds.c | 5 + 2 files changed, 9 insertions(+) Applied but can you please also update command documentation to use lockstep instead of lock? 439 "zynqmp tcminit mode - Initialize the TCM with zeros. TCM needs to be\n" 440 " initialized before accessing to avoid ECC\n" 441 " errors. mode specifies in which mode TCM has\n" 442 " to be initialized. Supported modes will be\n" 443 " lock(0)/split(1)\n" Thanks, Michal
Re: [PATCH v2] PCI: zynqmp: Add ZynqMP NWL PCIe root port driver
On 6/11/23 15:08, Pali Rohár wrote: On Friday 02 June 2023 15:30:43 Michal Simek wrote: Hi Pali, On 5/25/23 11:49, Stefan Roese wrote: Any comment about the driver itself? Thanks, Michal Why you are so impatient? It is common that people have to wait months or year for review and you unhappy with needed to wait for just week... Sorry if this was too fast but it is not about impatience. On v1 you reacted the same day. This was 2 weeks after initial sent. I have no problem to wait much longer time but I need to know that any reaction will come. In kernel I see quite fast reaction time for example in networking subsystem. And then others which take ages to get patch through. I prefer shorter time when developers still have setup on their desks and images ready that they are able to retest it easily. When it takes a lot weeks people switch topics and it is much harder to finish it. Thanks, Michal
[PATCH] doc: event: Correct EVT_DM_POST_INIT_F description
EVT_DM_POST_INIT_F only works in U-Boot proper, not SPL. Signed-off-by: Bin Meng --- doc/develop/event.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/develop/event.rst b/doc/develop/event.rst index 1c1c9ef7f1..f0ee6bc4cc 100644 --- a/doc/develop/event.rst +++ b/doc/develop/event.rst @@ -29,7 +29,7 @@ To declare a spy, use something like this:: EVENT_SPY(EVT_DM_POST_INIT_F, snow_setup_cpus); Your function is called when EVT_DM_POST_INIT_F is emitted, i.e. after driver -model is inited (in SPL, or in U-Boot proper before and after relocation). +model is inited (in U-Boot proper before and after relocation). Debugging -- 2.25.1
Re: Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
On 6/11/23 David Antliff wrote:
> On 6/11/23 Sean Anderson wrote:
> > On 6/11/23 23:25, David Antliff wrote:
> > > On 11/23/22 Sean Anderson wrote:
> > >> On 11/22/22 20:23, David Antliff wrote:
[snip]
> > > From a little debugging, I see that the call in eth-uclass.c around line
>515 returns a null pointer:
> > >
> > > p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
> >
> > This is expected. If (local-)mac-address is defined then
>nvmem_cell_get_by_name/nvmem_cell_read will not be used.
This was the hint I needed to solve this - thank you.
Turns out that PetaLinux (sigh) was injecting the ff:ff:ff... MAC address into
the device-tree build, which is where local-mac-address
was coming from. As you mentioned, and as I can now see in eth-uclass.c, the
NVMEM subsystem isn't used if either of these
nodes are defined.
Although PetaLinux's own config insists on setting a MAC address, I was able to
set it to a blank string which results
in a DT node, but with no value. This seems sufficient to get past the checks
for "{local-,}mac-address" and call the NVMEM
functions instead.
project-spec/configs/config:
CONFIG_SUBSYSTEM_ETHERNET_PSU_ETHERNET_3_MAC=""
For anyone else coming across this, here's my final DT snippet:
axi {
i2c@ff03 {
i2c-mux@74 {
i2c@0 {
eeprom@54 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,24c128";
reg = <0x54>;
mac_address: mac-address@23 {
reg = <0x23 6>;
};
};
};
};
};
ethernet@ff0e {
nvmem-cells = <&mac_address>;
nvmem-cell-names = "mac-address";
};
};
Also, it appears that 'compatible = ... , "nvmem-cells";' on the EEPROM node is
not required.
Thank you for the hints!
-- David.
Re: Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
Hi Sean, thanks for getting back to me.
On 6/11/23 Sean Anderson wrote:
> On 6/11/23 23:25, David Antliff wrote:
> > On 11/23/22 Sean Anderson wrote:
> >> On 11/22/22 20:23, David Antliff wrote:
[snip]
> > So I took up your suggestion, enabled CONFIG_NVMEM & CONFIG_I2C_EEPROM, and
> > with some trial and error I have got as far as added the following to my
> > device tree:
> >
> > axi {
> > i2c@ff03 {
> > i2c-mux@74 {
> > i2c@0 {
> > eeprom@54 {
> > mac_address: mac-address@23 {
> > reg = <0x23 6>;
> > };
> > };
> > };
> > };
> > };
> >
> > ethernet@ff0e {
> > nvmem-cells = <&mac_address>;
> > nvmem-cell-names = "mac-address";
> > };
> > };
> >
> > (This is part of a user .dtsi so it's added by Yocto to the existing DT
> > provided by the vendor's board
> > definition).
> >
> > The tree builds OK and I can view the correct nodes from U-Boot / fdt
> > command.
> >
> > From a little debugging, I see that the call in eth-uclass.c around line
> >515 returns a null pointer:
> >
> > p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
>
> This is expected. If (local-)mac-address is defined then
> nvmem_cell_get_by_name/nvmem_cell_read will not be used.
Yeah, so, I think I shot myself in the foot when writing this email, because
although I am using the U-Boot device tree
for my efforts (the one appended to the U-Boot binary, a la
CONFIG_OF_SEPARATE), I actually used the Linux one in
my email, which was a mistake because the "local-mac-address" has been
populated with a valid address by that point.
I'm actually not sure where that address comes from, because in the U-Boot
device tree, I have:
local-mac-address = [ff ff ff ff ff ff];
So to be clear, I do not have a valid local-mac-address in the U-Boot device
tree at the time U-Boot is looking for the MAC address.
> > And this results in U-Boot assigning the FF:FF:FF:FF:FF:FF address instead.
> >
> > Yet, if I boot Linux, this device now appears in sysfs as
> > /sys/bus/nvmem/devices/6-00544/nvmem,
> > and I can read/write to it, so something is working. Linux ends up with the
> > wrong MAC though
> > (76:1b:db:1f:78:12, and I'm not sure where that comes from).
> >
> > I think I have the right Ethernet device, as U-Boot reports:
> >
> > ZYNQ GEM: ff0e, mdio bus ff0e, phyaddr 12, interface rgmii-id
> >
> > Do you have any thoughts as to why U-Boot is not picking up the MAC address
> > from the EEPROM,
> > in this case, please?
> >
> > The full sections of the relevant parts of the DT now look like this:
[snip]
> > ethernet@ff0e {
> > power-domains = <0x11 0x20>;
> > iommus = <0x12 0x877>;
> > #address-cells = <0x01>;
> > phy-mode = "rgmii-id";
> > nvmem-cells = <0x15>;
> > clock-names = "pclk\0hclk\0tx_clk\0rx_clk\0tsu_clk";
> > local-mac-address = [76 1b db 1f 78 12];
>
> This will prevent the nvmem-cells from being used. Is this your U-Boot device
> tree? Or is it from /sys/firmware?
Yes, this is from /sys/firmware - my mistake, as mentioned above. The U-Boot
device tree looks like this:
ZynqMP> fdt print /axi/ethernet@ff0e
ethernet@ff0e {
compatible = "xlnx,zynqmp-gem", "cdns,gem";
status = "okay";
interrupt-parent = <0x0005>;
interrupts = <0x 0x003f 0x0004 0x 0x003f
0x0004>;
reg = <0x 0xff0e 0x 0x1000>;
clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
#address-cells = <0x0001>;
#size-cells = <0x>;
iommus = <0x0012 0x0877>;
power-domains = <0x0011 0x0020>;
resets = <0x0013 0x0020>;
reset-names = "gem3_rst";
clocks = <0x0004 0x001f 0x0004 0x006b 0x0004
0x0030 0x0004 0x0034 0x0004 0x002c>;
phy-handle = <0x0014>;
phy-mode = "rgmii-id";
xlnx,ptp-enet-clock = <0x>;
local-mac-address = [ff ff ff ff ff ff];
nvmem-cells = <0x0015>;
nvmem-cell-names = "mac-address";
phandle = <0x0067>;
mdio {
#address-cells = <0x0001>;
#size-cells = <0x>;
phandle = <0x0068>;
ethernet-phy@c {
#phy-cells = <0x0001>;
compatible = "ethernet-phy-id2000.a231";
reg = <0x000c>;
ti,rx-internal-delay = <0x0008>;
ti,tx-internal-delay = <0x000a>;
ti,fifo-depth = <0x00
Re: Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
On 6/11/23 23:25, David Antliff wrote:
On 11/23/22 Sean Anderson wrote:
On 11/22/22 20:23, David Antliff wrote:
> I'm looking to extract the board's MAC address from serial I2C EEPROM at
boot time, so
> I'm trying to work out how I can tell if U-Boot is actually able to
communicate with this
> EEPROM, outside of manual i2c commands.
>
> I have set CONFIG_ZYNQ_MAC_IN_EEPROM and CONFIG_ZYNQ_MAC_IN_EEPROM
> however I'm not completely sure that this is working with UltraScale+ Zynq
MPSoC
> boards - I'm using a ZCU208. There's no log message on the U-Boot console
to say
> that there was an attempt to read the MAC address, and with ethaddr unset,
this
> variable is set by U-Boot to the value taken from the device tree rather
than EEPROM:
>
> ethernet@ff0e {
> ...
> local-mac-address = [00 0a 35 00 22 01];
> ...
>
> I would expect it to be 00 0a 35 07 60 1c based on the contents of the
EEPROM.
>
> I would like to understand how to debug this. I read that the command
"eeprom" has been
> deprecated for some time (I don't have it enabled), with some I2C serial
EEPROM devices
> now supported by the "Driver Model" - aka DM.
>
> Thus I did find:
>
>> dm uclass
> ...
> uclass 39: i2c_eeprom
> 0 eeprom@54 @ 7dd21420
> ...
>
> And I'm able to communicate with the device via commands like:
>
> ZynqMP> i2c md 54 0.2 40 20
> : 5a 43 55 32 30 38 ff ff ff ff ff ff ff ff ff ff ZCU208..
> 0010: ff 41 30 32 38 33 32 32 30 34 31 34 33 33 32 38 .A02832204143328
> 0020: 31 2e 33 00 0a 35 07 60 1c 00 0a 35 07 60 1d 00 1.3..5.`...5.`..
> 0030: 0a 35 07 60 1e 00 0a 35 07 60 1f 41 08 ff ff ff .5.`...5.`.A
>
> The MAC address is 6 bytes starting at offset 0x23 (00 0a 35 07 60 1c).
[snip]
> The EEPROM device in question is an M24128.
>
> CONFIG_SYS_I2C_EEPROM_ADDR=0x54
> CONFIG_SYS_I2C_EEPROM_BUS=6
> CONFIG_SYS_EEPROM_SIZE=16384
> CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
> CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x23
> CONFIG_ZYNQ_MAC_IN_EEPROM=y
>
> U-Boot 2021.01 (Xilinx fork: git://github.com/Xilinx/u-boot-xlnx.git)
[snip]
This doesn't directly address your question, but have you tried using
nvmem-cells?
You enable CONFIG_NVMEM and CONFIG_I2C_EEPROM, and modify your device tree like
i2c {
eeprom@54 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "atmel,24c08";
reg = <0x54>;
mac_address: mac-address@23 {
reg = <0x23 6>;
};
};
};
ethernet {
nvmem-cells = <&mac_address>;
nvmem-cell-names = "mac-address";
};
You'll need 2022.07 for this I think. This is the same method which
Linux uses. I added this specificly to be able to load MAC addresses
from EEPROMs without needing to hard code stuff into Kconfig.
Hi Sean,
Apologies for bringing this thread back to life more than 6 months later, but
I'm not
quite getting this to work.
I have finally had the opportunity to upgrade to U-Boot 2023.1, and the first
thing I
noticed was that the old way of retrieving the MAC address from the EEPROM
fails,
as is expected as I understand that support was removed sometime after 2021.
So I took up your suggestion, enabled CONFIG_NVMEM & CONFIG_I2C_EEPROM, and
with some trial and error I have got as far as added the following to my device
tree:
axi {
i2c@ff03 {
i2c-mux@74 {
i2c@0 {
eeprom@54 {
mac_address: mac-address@23 {
reg = <0x23 6>;
};
};
};
};
};
ethernet@ff0e {
nvmem-cells = <&mac_address>;
nvmem-cell-names = "mac-address";
};
};
(This is part of a user .dtsi so it's added by Yocto to the existing DT
provided by the vendor's board
definition).
The tree builds OK and I can view the correct nodes from U-Boot / fdt command.
From a little debugging, I see that the call in eth-uclass.c around line 515
returns a null pointer:
p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
This is expected. If (local-)mac-address is defined then
nvmem_cell_get_by_name/nvmem_cell_read will not be used.
And this results in U-Boot assigning the FF:FF:FF:FF:FF:FF address instead.
Yet, if I boot Linux, this device now appears in sysfs as
/sys/bus/nvmem/devices/6-00544/nvmem,
and I can read/write to it, so something is working. Linux ends up with the
wrong MAC though
(76:1b:db:1f:78:12, and I'm not sure where that comes from).
I think I have the right Ethernet device, as U-Boot reports:
ZYNQ GEM: ff0e, mdio bus ff0e, phyaddr 12, interface rgmii-id
Do you have any thoughts as to why U-Boot is not
Re: Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
On 11/23/22 Sean Anderson wrote:
> On 11/22/22 20:23, David Antliff wrote:
> >
> > I'm looking to extract the board's MAC address from serial I2C EEPROM at
>boot time, so
> > I'm trying to work out how I can tell if U-Boot is actually able to
>communicate with this
> > EEPROM, outside of manual i2c commands.
> >
> > I have set CONFIG_ZYNQ_MAC_IN_EEPROM and CONFIG_ZYNQ_MAC_IN_EEPROM
> > however I'm not completely sure that this is working with UltraScale+ Zynq
>MPSoC
> > boards - I'm using a ZCU208. There's no log message on the U-Boot console
>to say
> > that there was an attempt to read the MAC address, and with ethaddr unset,
>this
> > variable is set by U-Boot to the value taken from the device tree rather
>than EEPROM:
> >
> > ethernet@ff0e {
> > ...
> > local-mac-address = [00 0a 35 00 22 01];
> > ...
> >
> > I would expect it to be 00 0a 35 07 60 1c based on the contents of the
>EEPROM.
> >
> > I would like to understand how to debug this. I read that the command
>"eeprom" has been
> > deprecated for some time (I don't have it enabled), with some I2C serial
>EEPROM devices
> > now supported by the "Driver Model" - aka DM.
> >
> > Thus I did find:
> >
> >> dm uclass
> > ...
> > uclass 39: i2c_eeprom
> > 0 eeprom@54 @ 7dd21420
> > ...
> >
> > And I'm able to communicate with the device via commands like:
> >
> > ZynqMP> i2c md 54 0.2 40 20
> > : 5a 43 55 32 30 38 ff ff ff ff ff ff ff ff ff ff ZCU208..
> > 0010: ff 41 30 32 38 33 32 32 30 34 31 34 33 33 32 38 .A02832204143328
> > 0020: 31 2e 33 00 0a 35 07 60 1c 00 0a 35 07 60 1d 00 1.3..5.`...5.`..
> > 0030: 0a 35 07 60 1e 00 0a 35 07 60 1f 41 08 ff ff ff .5.`...5.`.A
> >
> > The MAC address is 6 bytes starting at offset 0x23 (00 0a 35 07 60 1c).
[snip]
> > The EEPROM device in question is an M24128.
> >
> > CONFIG_SYS_I2C_EEPROM_ADDR=0x54
> > CONFIG_SYS_I2C_EEPROM_BUS=6
> > CONFIG_SYS_EEPROM_SIZE=16384
> > CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
> > CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x23
> > CONFIG_ZYNQ_MAC_IN_EEPROM=y
> >
> > U-Boot 2021.01 (Xilinx fork: git://github.com/Xilinx/u-boot-xlnx.git)
[snip]
> This doesn't directly address your question, but have you tried using
>nvmem-cells?
>
> You enable CONFIG_NVMEM and CONFIG_I2C_EEPROM, and modify your device tree
>like
>
> i2c {
> eeprom@54 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "atmel,24c08";
> reg = <0x54>;
>
> mac_address: mac-address@23 {
> reg = <0x23 6>;
> };
> };
> };
>
> ethernet {
> nvmem-cells = <&mac_address>;
> nvmem-cell-names = "mac-address";
> };
>
> You'll need 2022.07 for this I think. This is the same method which
> Linux uses. I added this specificly to be able to load MAC addresses
> from EEPROMs without needing to hard code stuff into Kconfig.
Hi Sean,
Apologies for bringing this thread back to life more than 6 months later, but
I'm not
quite getting this to work.
I have finally had the opportunity to upgrade to U-Boot 2023.1, and the first
thing I
noticed was that the old way of retrieving the MAC address from the EEPROM
fails,
as is expected as I understand that support was removed sometime after 2021.
So I took up your suggestion, enabled CONFIG_NVMEM & CONFIG_I2C_EEPROM, and
with some trial and error I have got as far as added the following to my device
tree:
axi {
i2c@ff03 {
i2c-mux@74 {
i2c@0 {
eeprom@54 {
mac_address: mac-address@23 {
reg = <0x23 6>;
};
};
};
};
};
ethernet@ff0e {
nvmem-cells = <&mac_address>;
nvmem-cell-names = "mac-address";
};
};
(This is part of a user .dtsi so it's added by Yocto to the existing DT
provided by the vendor's board
definition).
The tree builds OK and I can view the correct nodes from U-Boot / fdt command.
>From a little debugging, I see that the call in eth-uclass.c around line 515
>returns a null pointer:
p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
And this results in U-Boot assigning the FF:FF:FF:FF:FF:FF address instead.
Yet, if I boot Linux, this device now appears in sysfs as
/sys/bus/nvmem/devices/6-00544/nvmem,
and I can read/write to it, so something is working. Linux ends up with the
wrong MAC though
(76:1b:db:1f:78:12, and I'm not sure where that comes from).
I think I have the right Ethernet device, as U-Boot reports:
ZYNQ GEM: ff0e, mdio bus ff0e, phyaddr 12, interface rgmii-id
Do you have any thoughts as to why U-Boot is not picking up the MAC address
from the EEPROM,
in this case, please?
The full sections of the relevant parts of the DT now look like this:
axi {
/* */
[PATCH] clk: scmi: claim the dependency on CONFIG_CLK
Without CONFIG_CLK, the build fails with the following message: LD u-boot aarch64-none-linux-gnu-ld.bfd: drivers/firmware/scmi/scmi_agent-uclass.o: \ in function `scmi_bind_protocols': .../drivers/firmware/scmi/scmi_agent-uclass.c:79: undefined reference to \ `_u_boot_list_2_driver_2_scmi_clock' Signed-off-by: AKASHI Takahiro --- drivers/clk/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 3ad5af964f3f..29859cdfa158 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -160,6 +160,7 @@ config SANDBOX_CLK_CCF config CLK_SCMI bool "Enable SCMI clock driver" + depends on CLK depends on SCMI_FIRMWARE help Enable this option if you want to support clock devices exposed -- 2.41.0
Re: [RESEND PATCH v1] arch: riscv: jh7110: Correctly zero L2 LIM
> From: Bo Gan > Sent: Monday, June 12, 2023 7:59 AM > To: u-boot@lists.denx.de > Cc: Bo Gan ; samin . guo ; > Yanhong Wang ; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; Sean > Anderson ; Lukasz Majewski > Subject: [RESEND PATCH v1] arch: riscv: jh7110: Correctly zero L2 LIM > > Background information: > JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It consists of > 16 0x2 sized regions, each one can be used as either L2 cache way or > SRAM (not both). From top to bottom, there're ways 0-15. The way 0 is always > enabled, at most 0x1e can be used. > > In SPL, we don't enable any cache ways, thus all 15 (except way 0) ways can > be used. However, due to HW requirement, we must zero the LIM before use. > This is because ECC is applied to LIM, and if not cleared first, the ECC part > is invalid, which can trigger ECC errors when reading/writing data. > > There are several issues currently. We clear L2 LIM from __bss_end to > 0x81F in `harts_early_init`. This is wrong because: > > a. Each hart (in the middle of a function call) overwriting its own > stack and other harts' stacks. > (data-race and data-corruption) > b. Lottery winner hart can be doing `board_init_f_init_reserve`, > while other harts're in the middle of zeroing L2 LIM. > (data-race) > > To fix this, we split the job, such that there's one and only one owner of > zeroing a specific region (No data-race). A new SPL config option > `SPL_ZERO_MEM_BEFORE_USE` is introduced. Allowing The zeroing to happen in > the same code path. (much easier to reason about). > > Another option `SPL_SYS_MALLOC_CLEAR_ON_INIT` also gets introduced. > It allows us to also zero late malloc (dlmalloc) area, in case it gets > configured to be inside L2 LIM (via `CUSTOM_SYS_SPL_MALLOC_ADDR`) We by > default enable it to be on the safe side. > > `CONFIG_SPL_STACK` is adjusted to reduce the waste of L2 LIM space. > When setting > > CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x810 > CONFIG_SYS_SPL_MALLOC_SIZE=0xe > > A 0.875M late malloc arena is available in L2 LIM. It's sufficient for > loading JH7110 FIT Image (gzip compressed OpenSBI+UBOOT+DTB). > The advantage of this config is allowing OpenSBI/UBOOT to be loaded at any > DDR memory address. By default the malloc arena is configured in DDR memory, > so OpenSBI/UBOOT loading address must not collide with it. > > CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000 (DDR +1GB) > CONFIG_SYS_SPL_MALLOC_SIZE=0x40 > > JH7110 SPL memory map (based on the following defconfig): > > CONFIG_NR_CPUS=8 > CONFIG_STACK_SIZE_SHIFT=14 > CONFIG_SPL_STACK=0x810 > CONFIG_SPL_SYS_MALLOC_F_LEN=0x1 > CONFIG_SPL_BSS_START_ADDR=0x804 > > ++ 0x81e > | Free | > || > ++ 0x810 > | hart 0 stack | <--- cleared by each hart (start.S) > ++ 0x80fc000 > | hart 1 stack |. > ++ 0x80f8000 . > | ..|. > ++ > | hart N-1 stack| <--- cleared by each hart (start.S) > ++ 0x80e > | ..| <--- cleared by lottery winner hart > | malloc_base | board_init_f_init_reserve() > ++ 0x80d > | GD| <--- cleared by lottery winner hart > ++ board_init_f_init_reserve() > || > | hole | > || > ++ > | BSS | <--- cleared by lottery winner hart > ++ 0x804spl_clear_bss (start.S) > | hole | > ++ > | Image+DTB | <--- Assuming cleared/loaded by ROM > ++ 0x800 > > Signed-off-by: Bo Gan > Cc: samin . guo > Cc: Yanhong Wang > Cc: Rick Chen > Cc: Leo > Cc: Sean Anderson > Cc: Lukasz Majewski > --- > > v1: > - patch is on top of > https://patchwork.ozlabs.org/project/uboot/patch/1684650044-313122-1-git-send-email-ganbo...@gmail.com/ > - Tested on VisionFive 2 board (4G) > --- > Kconfig| 11 +++ > arch/riscv/Kconfig | 7 +++ > arch/riscv/cpu/jh7110/Kconfig | 2 ++ > arch/riscv/cpu/jh7110/spl.c| 25 - > arch/riscv/cpu/start.S | 12 > common/dlmalloc.c | 6 +++--- > common/init/board_init.c | 3 +++ > configs/starfive_visionfive2_defconfig | 3 ++- > 8 files changed, 40 insertions(+), 29 deletions(-) Please separate as several PATCHs, but not mix them as one PATCH Thanks, Rick
Re: [RESEND PATCH v2] riscv: setup per-hart stack earlier
> From: Bo Gan > Sent: Monday, June 12, 2023 7:54 AM > To: u-boot@lists.denx.de > Cc: Bo Gan ; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; Sean > Anderson ; Bin Meng ; Lukas Auer > > Subject: [RESEND PATCH v2] riscv: setup per-hart stack earlier > > Harts need to use per-hart stack before any function call, even if that > function is a simple one. When the callee uses stack for register save/ > restore, especially RA, if nested call, concurrent access by multiple harts > on the same stack will cause data-race. > > This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of > this is that the memory layout has changed as the following: > > ++++ <- SPL_STACK/ > | ..|| hart 0 stack |SYS_INIT_SP_ADDR > | malloc_base |++ > ++| hart 1 stack | > | GD|++ If not SMP, N=1 > ++| ..| > | hart 0 stack |++ > ++ ==> | hart N-1 stack| > | hart 1 stack |++ > ++| ..| > | ..|| malloc_base | > ++++ > | hart N-1 stack|| GD| > ++++ > |||| > > Signed-off-by: Bo Gan > Cc: Rick Chen > Cc: Leo > Cc: Sean Anderson > Cc: Bin Meng > Cc: Lukas Auer > --- > > v2: > - Fixed macro CONFIG_SYS_INIT_SP_ADDR -> SYS_INIT_SP_ADDR > - Tested SPL with VisionFive 2 board > --- > arch/riscv/cpu/start.S | 37 - > 1 file changed, 24 insertions(+), 13 deletions(-) Reviewed-by: Rick Chen
[RESEND PATCH v1] arch: riscv: jh7110: Correctly zero L2 LIM
Background information: JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It consists of 16 0x2 sized regions, each one can be used as either L2 cache way or SRAM (not both). From top to bottom, there're ways 0-15. The way 0 is always enabled, at most 0x1e can be used. In SPL, we don't enable any cache ways, thus all 15 (except way 0) ways can be used. However, due to HW requirement, we must zero the LIM before use. This is because ECC is applied to LIM, and if not cleared first, the ECC part is invalid, which can trigger ECC errors when reading/writing data. There are several issues currently. We clear L2 LIM from __bss_end to 0x81F in `harts_early_init`. This is wrong because: a. Each hart (in the middle of a function call) overwriting its own stack and other harts' stacks. (data-race and data-corruption) b. Lottery winner hart can be doing `board_init_f_init_reserve`, while other harts're in the middle of zeroing L2 LIM. (data-race) To fix this, we split the job, such that there's one and only one owner of zeroing a specific region (No data-race). A new SPL config option `SPL_ZERO_MEM_BEFORE_USE` is introduced. Allowing The zeroing to happen in the same code path. (much easier to reason about). Another option `SPL_SYS_MALLOC_CLEAR_ON_INIT` also gets introduced. It allows us to also zero late malloc (dlmalloc) area, in case it gets configured to be inside L2 LIM (via `CUSTOM_SYS_SPL_MALLOC_ADDR`) We by default enable it to be on the safe side. `CONFIG_SPL_STACK` is adjusted to reduce the waste of L2 LIM space. When setting CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x810 CONFIG_SYS_SPL_MALLOC_SIZE=0xe A 0.875M late malloc arena is available in L2 LIM. It's sufficient for loading JH7110 FIT Image (gzip compressed OpenSBI+UBOOT+DTB). The advantage of this config is allowing OpenSBI/UBOOT to be loaded at any DDR memory address. By default the malloc arena is configured in DDR memory, so OpenSBI/UBOOT loading address must not collide with it. CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000 (DDR +1GB) CONFIG_SYS_SPL_MALLOC_SIZE=0x40 JH7110 SPL memory map (based on the following defconfig): CONFIG_NR_CPUS=8 CONFIG_STACK_SIZE_SHIFT=14 CONFIG_SPL_STACK=0x810 CONFIG_SPL_SYS_MALLOC_F_LEN=0x1 CONFIG_SPL_BSS_START_ADDR=0x804 ++ 0x81e | Free | || ++ 0x810 | hart 0 stack | <--- cleared by each hart (start.S) ++ 0x80fc000 | hart 1 stack |. ++ 0x80f8000 . | ..|. ++ | hart N-1 stack| <--- cleared by each hart (start.S) ++ 0x80e | ..| <--- cleared by lottery winner hart | malloc_base | board_init_f_init_reserve() ++ 0x80d | GD| <--- cleared by lottery winner hart ++ board_init_f_init_reserve() || | hole | || ++ | BSS | <--- cleared by lottery winner hart ++ 0x804spl_clear_bss (start.S) | hole | ++ | Image+DTB | <--- Assuming cleared/loaded by ROM ++ 0x800 Signed-off-by: Bo Gan Cc: samin . guo Cc: Yanhong Wang Cc: Rick Chen Cc: Leo Cc: Sean Anderson Cc: Lukasz Majewski --- v1: - patch is on top of https://patchwork.ozlabs.org/project/uboot/patch/1684650044-313122-1-git-send-email-ganbo...@gmail.com/ - Tested on VisionFive 2 board (4G) --- Kconfig| 11 +++ arch/riscv/Kconfig | 7 +++ arch/riscv/cpu/jh7110/Kconfig | 2 ++ arch/riscv/cpu/jh7110/spl.c| 25 - arch/riscv/cpu/start.S | 12 common/dlmalloc.c | 6 +++--- common/init/board_init.c | 3 +++ configs/starfive_visionfive2_defconfig | 3 ++- 8 files changed, 40 insertions(+), 29 deletions(-) diff --git a/Kconfig b/Kconfig index 70efb41..e5eec1b 100644 --- a/Kconfig +++ b/Kconfig @@ -372,6 +372,17 @@ if EXPERT When disabling this, please check if malloc calls, maybe should be replaced by calloc - if one expects zeroed memory. + config SPL_SYS_MALLOC_CLEAR_ON_INIT + bool "Init with zeros the memory reserved for malloc (slow) in SPL" + depends on SPL + default SYS_MALLOC_CLEAR_ON_INIT + help + Same as SYS_MALLOC_CLEAR_ON_INIT, but for SPL. It's possible to + Enable it without SYS_MALLOC_CLEAR_ON_INIT. It's useful for boards + that must have particular memory regions zero'ed before first use. + If SYS_SPL_MALLOC_START is configured to be in such region, this + option shoul
[RESEND PATCH v2] riscv: setup per-hart stack earlier
Harts need to use per-hart stack before any function call, even if that function is a simple one. When the callee uses stack for register save/ restore, especially RA, if nested call, concurrent access by multiple harts on the same stack will cause data-race. This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of this is that the memory layout has changed as the following: ++++ <- SPL_STACK/ | ..|| hart 0 stack |SYS_INIT_SP_ADDR | malloc_base |++ ++| hart 1 stack | | GD|++ If not SMP, N=1 ++| ..| | hart 0 stack |++ ++ ==> | hart N-1 stack| | hart 1 stack |++ ++| ..| | ..|| malloc_base | ++++ | hart N-1 stack|| GD| ++++ |||| Signed-off-by: Bo Gan Cc: Rick Chen Cc: Leo Cc: Sean Anderson Cc: Bin Meng Cc: Lukas Auer --- v2: - Fixed macro CONFIG_SYS_INIT_SP_ADDR -> SYS_INIT_SP_ADDR - Tested SPL with VisionFive 2 board --- arch/riscv/cpu/start.S | 37 - 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index dad22bf..59d58a5 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -91,16 +91,35 @@ _start: * Set stackpointer in internal/ex RAM to call board_init_f */ call_board_init_f: - li t0, -16 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) - li t1, CONFIG_SPL_STACK + li t0, CONFIG_SPL_STACK #else - li t1, SYS_INIT_SP_ADDR + li t0, SYS_INIT_SP_ADDR #endif - and sp, t1, t0 /* force 16 byte alignment */ + and t0, t0, -16 /* force 16 byte alignment */ + + /* setup stack */ +#if CONFIG_IS_ENABLED(SMP) + /* tp: hart id */ + sllit1, tp, CONFIG_STACK_SIZE_SHIFT + sub sp, t0, t1 +#else + mv sp, t0 +#endif +/* + * Now sp points to the right stack belonging to current CPU. + * It's essential before any function call, otherwise, we get data-race. + */ call_board_init_f_0: - mv a0, sp + /* find top of reserve space */ +#if CONFIG_IS_ENABLED(SMP) + li t1, CONFIG_NR_CPUS +#else + li t1, 1 +#endif + sllit1, t1, CONFIG_STACK_SIZE_SHIFT + sub a0, t0, t1 /* t1 -> size of all CPU stacks */ jal board_init_f_alloc_reserve /* @@ -109,14 +128,6 @@ call_board_init_f_0: */ mv s0, a0 - /* setup stack */ -#if CONFIG_IS_ENABLED(SMP) - /* tp: hart id */ - sllit0, tp, CONFIG_STACK_SIZE_SHIFT - sub sp, a0, t0 -#else - mv sp, a0 -#endif /* Configure proprietary settings and customized CSRs of harts */ call_harts_early_init: -- 2.7.4
[PATCH v2 7/7] sunxi: H616: enable USB support for H616 boards
Now that the PHY driver supports the H616 USB PHY, we can enable USB support for the two H616 boards. As the OrangePi Zero2 has a USB-C port hard-wired to peripheral mode, let's enable USB gadget mode for port 0, so people can use fastboot, ethernet or mass storage functionality. Signed-off-by: Andre Przywara --- configs/orangepi_zero2_defconfig | 3 +++ configs/x96_mate_defconfig | 2 ++ 2 files changed, 5 insertions(+) diff --git a/configs/orangepi_zero2_defconfig b/configs/orangepi_zero2_defconfig index 6cb942f511a..4178ee6a286 100644 --- a/configs/orangepi_zero2_defconfig +++ b/configs/orangepi_zero2_defconfig @@ -19,3 +19,6 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_PHY_REALTEK=y CONFIG_SUN8I_EMAC=y CONFIG_SPI=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_MUSB_GADGET=y diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig index 122c1a99e32..32ef0a42ee2 100644 --- a/configs/x96_mate_defconfig +++ b/configs/x96_mate_defconfig @@ -18,3 +18,5 @@ CONFIG_SYS_I2C_MVTWSI=y CONFIG_SYS_I2C_SLAVE=0x7f CONFIG_SYS_I2C_SPEED=40 CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y -- 2.35.8
[PATCH v2 6/7] phy: sun4i: Add H616 USB PHY support
Now that the Allwinner USB PHY driver supports the H616 quirk, let's
enable support for USB ports on that SoC.
We connect the compatible string to a new struct describing the SoCs USB
PHY properties, and unblock the PHY driver selection in Kconfig.
A later patch will enable USB support in the H616 boards' defconfigs.
Signed-off-by: Andre Przywara
---
drivers/phy/allwinner/Kconfig | 1 -
drivers/phy/allwinner/phy-sun4i-usb.c | 12
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/allwinner/Kconfig b/drivers/phy/allwinner/Kconfig
index 565b4617b01..bb0bd8d5f81 100644
--- a/drivers/phy/allwinner/Kconfig
+++ b/drivers/phy/allwinner/Kconfig
@@ -5,7 +5,6 @@ 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
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index c81811a7522..77dffcad884 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -672,6 +672,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
.missing_phys = BIT(1) | BIT(2),
};
+static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
+ .num_phys = 4,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A33,
+ .dedicated_clocks = true,
+ .phy0_dual_route = true,
+ .hci_phy_ctl_clear = PHY_CTL_SIDDQ,
+ .needs_phy2_siddq = true,
+ .siddq_in_base = true,
+};
+
static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = {
.num_phys = 1,
.disc_thresh = 3,
@@ -693,6 +704,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,sun50i-h616-usb-phy", .data =
(ulong)&sun50i_h616_cfg },
{ .compatible = "allwinner,suniv-f1c100s-usb-phy", .data =
(ulong)&suniv_f1c100s_cfg },
{ }
};
--
2.35.8
[PATCH v2 5/7] phy: sun4i-usb: Add H616 USB PHY quirk support
The H616 USB PHY is some kind of special snowflake: Only port2 works out
of the box, but all other ports need some help from this port2 to work
correctly: The CLK_BUS_PHY2 and RST_USB_PHY2 clock and reset need to be
enabled, and the SIDDQ bit in the PMU PHY control register needs to be
cleared. For this register to be accessible, CLK_BUS_ECHI2 needs to be
ungated. Don't ask
Follow the respective Linux patch (b45c6d80325b) and add a quirk bit,
triggering the special sequence as outlined above, for PHYs other than
PHY2: ungate this one special clock, and clear the SIDDQ bit. We also
pick the clock and reset from PHY2 and enable them as well.
Signed-off-by: Andre Przywara
---
drivers/phy/allwinner/phy-sun4i-usb.c | 46 +++
1 file changed, 46 insertions(+)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 88c1a3dc84a..c81811a7522 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -82,6 +82,7 @@ struct sun4i_usb_phy_cfg {
bool dedicated_clocks;
bool phy0_dual_route;
bool siddq_in_base;
+ bool needs_phy2_siddq;
int missing_phys;
};
@@ -118,6 +119,7 @@ struct sun4i_usb_phy_plat {
struct gpio_desc gpio_vbus_det;
struct gpio_desc gpio_id_det;
struct clk clocks;
+ struct clk clk2;
struct reset_ctl resets;
int id;
};
@@ -272,6 +274,41 @@ static int sun4i_usb_phy_init(struct phy *phy)
return ret;
}
+ /* Some PHYs on some SoCs (the H616) need the help of PHY2 to work. */
+ if (data->cfg->needs_phy2_siddq && phy->id != 2) {
+ struct sun4i_usb_phy_plat *phy2 = &data->usb_phy[2];
+
+ ret = clk_enable(&phy2->clocks);
+ if (ret) {
+ dev_err(phy->dev, "failed to enable aux clock\n");
+ return ret;
+ }
+
+ ret = reset_deassert(&phy2->resets);
+ if (ret) {
+ dev_err(phy->dev, "failed to deassert aux reset\n");
+ return ret;
+ }
+
+ /*
+* This extra clock is just needed to access the
+* REG_HCI_PHY_CTL PMU register for PHY2.
+*/
+ ret = clk_enable(&phy2->clk2);
+ if (ret) {
+ dev_err(phy->dev, "failed to enable PHY2 clock\n");
+ return ret;
+ }
+
+ if (phy2->pmu && data->cfg->hci_phy_ctl_clear) {
+ val = readl(phy2->pmu + REG_HCI_PHY_CTL);
+ val &= ~data->cfg->hci_phy_ctl_clear;
+ writel(val, phy2->pmu + REG_HCI_PHY_CTL);
+ }
+
+ clk_disable(&phy2->clk2);
+ }
+
if (usb_phy->pmu && data->cfg->hci_phy_ctl_clear) {
val = readl(usb_phy->pmu + REG_HCI_PHY_CTL);
val &= ~data->cfg->hci_phy_ctl_clear;
@@ -500,6 +537,15 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
return ret;
}
+ /* Helper clock from PHY2 for the H616 PHY quirk */
+ snprintf(name, sizeof(name), "pmu%d_clk", i);
+ ret = clk_get_by_name_optional(dev, name, &phy->clk2);
+ if (ret) {
+ dev_err(dev, "failed to get pmu%d_clk clock phandle\n",
+ i);
+ return ret;
+ }
+
snprintf(name, sizeof(name), "usb%d_reset", i);
ret = reset_get_by_name(dev, name, &phy->resets);
if (ret) {
--
2.35.8
[PATCH v2 4/7] phy: sun4i-usb: Replace types with explicit quirk flags
So far we were assigning some crude "type" (SoC name, really) to each
Allwinner USB PHY model, then guarding certain quirks based on this.
This does not only look weird, but gets more or more cumbersome to
maintain.
Remove the bogus type names altogether, instead introduce flags for each
quirk, and explicitly check for them.
This improves readability, and simplifies future extensions.
Port of Linux patch 8dd256bae653.
Signed-off-by: Andre Przywara
---
drivers/phy/allwinner/phy-sun4i-usb.c | 41 ++-
1 file changed, 9 insertions(+), 32 deletions(-)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 2bf47fc36a7..88c1a3dc84a 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -73,26 +73,15 @@
#define MAX_PHYS 4
-enum sun4i_usb_phy_type {
- sun4i_a10_phy,
- sun6i_a31_phy,
- sun8i_a33_phy,
- sun8i_a83t_phy,
- sun8i_h3_phy,
- sun8i_r40_phy,
- sun8i_v3s_phy,
- sun50i_a64_phy,
- sun50i_h6_phy,
-};
-
struct sun4i_usb_phy_cfg {
int num_phys;
- enum sun4i_usb_phy_type type;
+ int hsic_index;
u32 disc_thresh;
u32 hci_phy_ctl_clear;
u8 phyctl_offset;
bool dedicated_clocks;
bool phy0_dual_route;
+ bool siddq_in_base;
int missing_phys;
};
@@ -200,7 +189,7 @@ static void sun4i_usb_phy_passby(struct phy *phy, bool
enable)
SUNXI_AHB_INCRX_ALIGN_EN | SUNXI_ULPI_BYPASS_EN;
/* A83T USB2 is HSIC */
- if (data->cfg->type == sun8i_a83t_phy && usb_phy->id == 2)
+ if (data->cfg->hsic_index && usb_phy->id == data->cfg->hsic_index)
bits |= SUNXI_EHCI_HS_FORCE | SUNXI_HSIC_CONNECT_INT |
SUNXI_HSIC;
@@ -289,8 +278,7 @@ static int sun4i_usb_phy_init(struct phy *phy)
writel(val, usb_phy->pmu + REG_HCI_PHY_CTL);
}
- if (data->cfg->type == sun8i_a83t_phy ||
- data->cfg->type == sun50i_h6_phy) {
+ if (data->cfg->siddq_in_base) {
if (phy->id == 0) {
val = readl(data->base + data->cfg->phyctl_offset);
val |= PHY_CTL_VBUSVLDEXT;
@@ -339,8 +327,7 @@ static int sun4i_usb_phy_exit(struct phy *phy)
int ret;
if (phy->id == 0) {
- if (data->cfg->type == sun8i_a83t_phy ||
- data->cfg->type == sun50i_h6_phy) {
+ if (data->cfg->siddq_in_base) {
void __iomem *phyctl = data->base +
data->cfg->phyctl_offset;
@@ -536,7 +523,6 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
.num_phys = 3,
- .type = sun4i_a10_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
@@ -544,7 +530,6 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
.num_phys = 2,
- .type = sun4i_a10_phy,
.disc_thresh = 2,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
@@ -552,7 +537,6 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.num_phys = 3,
- .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
@@ -560,7 +544,6 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
.num_phys = 3,
- .type = sun4i_a10_phy,
.disc_thresh = 2,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
@@ -568,7 +551,6 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.num_phys = 2,
- .type = sun4i_a10_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
@@ -576,7 +558,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.num_phys = 2,
- .type = sun8i_a33_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
@@ -584,14 +565,14 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
.num_phys = 3,
- .type = sun8i_a83t_phy,
+ .hsic_index = 2,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
+ .siddq_in_base = true,
};
static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.num_phys = 4,
- .type = sun8i_h3_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
@@ -601,7 +582,6 @@ static c
[PATCH v2 3/7] 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 Reviewed-by: Jernej Skrabec --- 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.35.8
[PATCH v2 2/7] 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
Reviewed-by: Jernej Skrabec
---
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.35.8
[PATCH v2 1/7] 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
Reviewed-by: Jernej Skrabec
---
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.35.8
[PATCH v2 0/7] phy: sun4i: Allwinner F1C100s/H616 support and cleanup
Hi, version 2 of this series does not change anything in the first three patches adding F1C100s support (apart from adding Jernej's review tags, many thanks for that!), but also adds support for the H616 USB PHY. This is a bit more involved this time, since the USB PHY on this SoC requires some weird quirk to enable most ports. Along with this it adds some cleanup that we used in the Linux driver, which helps to keep the code clean and simplifies future support. Patch 1/7 fixes a bug that prevented the V3s from being supported, and also affects the F1C100s. Patch 2/7 adds the compatible string for the F1C100s, along with its specific properties. Patch 3/7 uses the opportunity to cleanup the U-Boot Kconfig selection of the sunxi USB PHY, and patch 4/7 continues the spring clean with copying some PHY quirk rework done in the Linux kernel recently. The remaining three patches then deal with the H616 USB PHY: patch 5 adds the quirk support, patch 6 wires up the compatible string, while the final patch enables USB support in the defconfig of the two supported boards. Please have a look and test! Cheers, Andre Andre Przywara (7): phy: sun4i-usb: Fix of_xlate() argument check phy: sun4i-usb: add Allwinner F1C100s support sunxi: Kconfig: rework PHY_USB_SUN4I selection phy: sun4i-usb: Replace types with explicit quirk flags phy: sun4i-usb: Add H616 USB PHY quirk support phy: sun4i: Add H616 USB PHY support sunxi: H616: enable USB support for H616 boards arch/arm/mach-sunxi/Kconfig | 11 --- configs/orangepi_zero2_defconfig | 3 + configs/x96_mate_defconfig| 2 + drivers/phy/allwinner/Kconfig | 5 +- drivers/phy/allwinner/phy-sun4i-usb.c | 111 ++ 5 files changed, 88 insertions(+), 44 deletions(-) -- 2.35.8
Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts
On Friday 28 April 2023 10:30:08 Pali Rohár wrote: > On Friday 28 April 2023 15:39:20 Peng Fan wrote: > > On 4/2/2023 12:43 AM, Pali Rohár wrote: > > > Can anybody help with this? > > > > I expected Jaehoon would say some words. Just a reminder... > > > > > > > > On Saturday 25 March 2023 13:25:06 Pali Rohár wrote: > > > > CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with > > > > this issue? Expected usage is following: BootROM reads and execute SPL > > > > from eMMC (BootROM has its own code for reading eMMC), SPL initialize > > > > mmc driver and after SPL finish its work it returns control back to > > > > BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue > > > > is that after SPL returns control back to BootROM it looks like that > > > > BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts > > > > (timeout takes 5 minutes!) and after it correctly reads proper U-Boot > > > > from eMMC and continues booting proper U-Boot. I guess that there is an > > > > issue that SPL's mmc driver changes eMMC state into something which > > > > BootROM does not expect. > > > > A general question is since BootROM will still using eMMC, why let > > SPL to initialize eMMC? SPL's configuration may not match ROM's expection. > > Requirement is ENV access which is stored on eMMC too and without > initializing SPL eMMC driver, SPL cannot access ENV. > > Another thing is that loading proper U-Boot via SPL eMMC driver is > sometimes faster than via BootROM eMMC code. I guess this is BootROM > does not full speed. > > Also another fact is that SPL on mvebu works in this "hybrid" mode > (initialize and access boot device; plus let BootROM to use it) for all > other bootable storages. > > > For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask > > ROM help loading images, and SPL not touch relevant USB/EMMC. > > Unfortunately there is no BootROM API for these processors. All issues > which are being resolved in this (and also other) discussions are done > by inspecting BootROM code and trying to understand how it behaves and > how it choose the eMMC boot partition. As this stuff has poor > documentation and even this documentation has documented erratas... So > nobody knows what exactly is and what not supported. > > What we need to do is to write mvebu specific SPL code which is > compatible with BootROM. > > > Regards, > > Peng. > > > > > > > > > > On Friday 24 March 2023 02:55:55 Martin Rowe wrote: > > > > > On Thu, 23 Mar 2023 at 19:01, Pali Rohár wrote: > > > > > > There is issue with that 5 minutes delay. But I think it should be > > > > > > fixed > > > > > > by the patch which I sent earlier, which restore partition config > > > > > > based > > > > > > on mmc->part_config in board_return_to_bootrom(). Could you test it? > > > > > > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/ > > > > > > Now when mmc->part_config is correctly initialized it should restore > > > > > > configuration and BootROM does not have to get that "Timeout waiting > > > > > > card ready" error. > > > > > > > > > > Still takes about 5 minutes. The output is below with MMC tracing. I > > > > > confirmed the value of mmc->part_config used for > > > > > restore_emmc_boot_part_config is the same as what is initially > > > > > detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and > > > > > zeroed boot0). > > > > > > > > > > ERROR: Invalid kwbimage v1 > > > > > mmc_load_image_raw_sector: mmc block read error > > > > > spl: mmc: wrong boot mode > > > > > Trying to boot from BOOTROM > > > > > CMD_SEND:6 > > > > > ARG 0x03b30a00 > > > > > MMC_RSP_R1b 0x0900 > > > > > CMD_SEND:13 > > > > > ARG 0x0001 > > > > > MMC_RSP_R1,5,6,7 0x0900 > > > > > CURR STATE:4 > > > > > Returning to BootROM (return address 0x05c4)... > > > > > > > > I looked at the BootROM disassembled code and error message > > > > "Timeout waiting card ready" is printed when following mmc command > > > > cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts. > > > > > > > > 0xd is in U-Boot MMC_CMD_SEND_STATUS > > > > > > > > 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY > > > > which looks like U-Boot's MMC_RSP_R2 with BUSY bit set > > > > > > > > It looks like U-Boot function mmc_send_status() where that "something" > > > > in cmdarg is mmc->rca. > > > > > > > > If command does not timeout then BootROM next checks if response has > > > > BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are > > > > truth then BootROM mark call as successful. > > > > > > > > If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints > > > > "Status Error: " with hex response value and mark call as unsuccessful. > > > > > > > > I'm looking at the U-Boot code and this BootROM logic looks very similar > > > > to U-Boot function mmc_
Re: [PATCH] mmc: Do not read eMMC partition access bits by default on OMAP2PLUS and BCM283X
Ping, what to do with this patch? It is without any response too and is a is fix for this reported issue: https://lore.kernel.org/u-boot/20230503171456.GF1134230@bill-the-cat/ On Tuesday 16 May 2023 20:49:43 Pali Rohár wrote: > OMAP2PLUS and BCM283X mmc controllers do not work correctly with new emmc > code which reads partition access bits prior mmc controller reset. > > So introduce a new config option MMC_ENABLE_PART_ACCESS, which is by > default disabled for ARCH_OMAP2PLUS and ARCH_BCM283X; and selected for > 32-bit mvebu mmc booting (which requires it). > > Signed-off-by: Pali Rohár > --- > arch/arm/mach-mvebu/Kconfig | 1 + > drivers/mmc/Kconfig | 12 > drivers/mmc/mmc.c | 2 ++ > 3 files changed, 15 insertions(+) > > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig > index ac484c73f62d..fe691cd435e7 100644 > --- a/arch/arm/mach-mvebu/Kconfig > +++ b/arch/arm/mach-mvebu/Kconfig > @@ -353,6 +353,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC > imply SPL_GPIO > imply SPL_LIBDISK_SUPPORT > imply SPL_MMC > + select MMC_ENABLE_PART_ACCESS if SPL_MMC > select SUPPORT_EMMC_BOOT if SPL_MMC > select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC > select SPL_BOOTROM_SUPPORT > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index de01b9687bad..ea50dfdb62c5 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -107,6 +107,18 @@ config MMC_HW_PARTITIONING > This adds a command and an API to do hardware partitioning on eMMC > devices. > > +config MMC_ENABLE_PART_ACCESS > + bool "Support for MMC partition access bits" > + default n if ARCH_OMAP2PLUS || ARCH_BCM283X > + default y > + help > + Read partition access bits from partition config register before card > reset command > + because these bits are reset to default value (User Data Area) during > card reset. > + This allows us to preserve original value of partition access bits > used by the code > + which loaded us (for example BootROM) and use it for board specific > boot purposes. > + . > + This is required when U-Boot is using > EXT_CSD_EXTRACT_PARTITION_ACCESS macro. > + > config SUPPORT_EMMC_RPMB > bool "Support eMMC replay protected memory block (RPMB)" > imply CMD_MMC_RPMB > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c > index 9915610d82b1..fa3c4d1937c1 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -2864,6 +2864,7 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet) > retry: > mmc_set_initial_state(mmc); > > +#ifdef CONFIG_MMC_ENABLE_PART_ACCESS > /* >* Read partition access bits from partition config register before > card reset command >* because these bits are reset to default value (User Data Area) > during card reset. > @@ -2878,6 +2879,7 @@ retry: >ext_csd[EXT_CSD_BOOT_MULT])) > mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & > PART_ACCESS_MASK; > } > +#endif > > /* Reset the Card */ > err = mmc_go_idle(mmc); > -- > 2.20.1 >
Re: [PATCH v2 0/7] rockchip: Fix RK3328 USB support
On Tue, Jun 6, 2023 at 6:09 PM Jagan Teki wrote: > > This series support fixes for RK3328 USB. > > Changes for v2: > - collect Marek RB > - update phy driver clockout_ctl for rk3328 > - retest on Xavier patches. > > Any inputs? I've done some basic testing of thing on a Rock64 and it looks good to me so for the series: Tested-by: Peter Robinson > Jagan. > > Jagan Teki (7): > arm64: dts: rockchip: Drop unused rk3328-xhci node > configs: Drop unused XHCI_DWC3 for RK3328 boards > usb: dwc3-generic: Restrict single ctrl node for RK3328 > configs: Enable DWC3 USB 3.0 on RK3328 boards > phy: rockchip-inno-usb2: Add USB2 PHY for RK3328 > clk: rockchip: rk3328: Handle usb480m phy clock > configs: rockchip: Enable USB2PHY for RK3328 boards > > arch/arm/dts/rk3328-evb-u-boot.dtsi | 5 --- > arch/arm/dts/rk3328-roc-cc-u-boot.dtsi| 14 > arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 5 --- > arch/arm/dts/rk3328-rock64-u-boot.dtsi| 15 > arch/arm/dts/rk3328-u-boot.dtsi | 11 -- > configs/evb-rk3328_defconfig | 4 ++- > configs/nanopi-r2c-rk3328_defconfig | 4 ++- > configs/nanopi-r2s-rk3328_defconfig | 4 ++- > configs/roc-cc-rk3328_defconfig | 4 ++- > configs/rock-pi-e-rk3328_defconfig| 4 ++- > configs/rock64-rk3328_defconfig | 4 ++- > drivers/clk/rockchip/clk_rk3328.c | 2 ++ > drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 34 +++ > drivers/usb/dwc3/dwc3-generic.c | 2 +- > 14 files changed, 55 insertions(+), 57 deletions(-) > > -- > 2.25.1 >
Re: [PATCH v2 5/5] rockchip: rockpro64: Build u-boot-rockchip-spi.bin
Hi Jonas, This regresses the Rockpro64 build for me when building with gcc 12/13 with the following error, if I remove CONFIG_LTO it builds, but overlaps. /usr/bin/aarch64-linux-gnu-ld: /usr/lib/gcc/aarch64-linux-gnu/13/libgcc.a(lse-init.o): in function `init_have_lse_atomics': /builddir/build/BUILD/gcc-13.1.1-20230519/aarch64-linux-gnu/aarch64-linux-gnu/libgcc/../../../gcc-13.1.1-20230519/libgcc/config/aarch64/lse-init.c:46: undefined reference to `__getauxval' collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. Peter On Wed, May 17, 2023 at 7:41 PM Jonas Karlman wrote: > > Enable CONFIG_ROCKCHIP_SPI_IMAGE to build u-boot-rockchip-spi.bin. > Define CONFIG_SYS_SPI_U_BOOT_OFFS to write u-boot.itb at the expected > offset. Enable CONFIG_LTO to reduce size of SPL so that the mkimage > output fit before the 0x6 offset in u-boot-rockchip-spi.bin. > > => sf probe > SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 > MiB > => load mmc 1:1 1000 u-boot-rockchip-spi.bin > 1442304 bytes read in 27 ms (50.9 MiB/s) > => sf update $fileaddr 0 $filesize > device 0 offset 0x0, size 0x160200 > 1421824 bytes written, 20480 bytes skipped in 9.501s, speed 155432 B/s > > Signed-off-by: Jonas Karlman > Reviewed-by: Kever Yang > --- > v2: > - Collect r-b tag > > configs/rockpro64-rk3399_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configs/rockpro64-rk3399_defconfig > b/configs/rockpro64-rk3399_defconfig > index 0ca2cecade25..f41c03067903 100644 > --- a/configs/rockpro64-rk3399_defconfig > +++ b/configs/rockpro64-rk3399_defconfig > @@ -11,6 +11,7 @@ CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64" > CONFIG_DM_RESET=y > CONFIG_ROCKCHIP_RK3399=y > +CONFIG_ROCKCHIP_SPI_IMAGE=y > CONFIG_TARGET_ROCKPRO64_RK3399=y > CONFIG_SPL_STACK=0x40 > CONFIG_DEBUG_UART_BASE=0xFF1A > @@ -20,6 +21,7 @@ CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_PCI=y > CONFIG_DEBUG_UART=y > +CONFIG_LTO=y > CONFIG_SPL_FIT_SIGNATURE=y > CONFIG_BOOTSTAGE=y > CONFIG_BOOTSTAGE_REPORT=y > @@ -37,6 +39,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000 > CONFIG_SPL_STACK_R=y > CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 > CONFIG_SPL_SPI_LOAD=y > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 > CONFIG_TPL=y > CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPT=y > -- > 2.40.1 >
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
On Sun, Jun 11, 2023 at 09:24:14AM +0100, Simon Glass wrote: > Hi, > > On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas > wrote: > > > > Hi Maxim, > > > > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov wrote: > > > > > > Greetings, > > > > > > I implemented the tftp client (that was quick due to lwip has example app > > > for tftp), and did some more measurements. > > > I uploaded patches here if somebody want to do his own measurements: > > > https://github.com/muvarov/uboot-lwip > > > > > > measure 1: > > > 976K - total (total means lwip with all 3 commands ping, tftp, wget) > > > 971K - total - tftp (total, but disable/minus tftp) > > > 965K - total - tftp - wget (disable tftp and wget) > > > 963K - total - tftp - wget - ping (disable tftp, wget, ping) > > > 931K - no lwip > > > > > > result 1: lwip tftp (+ udp protocol) protocol 976-971k = 5kb > > > result 2: lwip ping command 965- 963 = 2kb > > > result 3: lwip wget command 971- 965 = 6kb > > > result 4: lwip core stack with apps 976 - 931 = 45kb > > > > So tftp = 5kb, wget = 6kb ping =2kb and lwip = 32kb > > > > > > > > measure 2: > > > 890K - no CONFIG_NET_CMD > > > 930K - + lwip tftp only > > > 937K - + full lwip (ping wget tftp) > > > > > > result 1: 937-890=47kb ( lwip + all 3 commands) > > > result 2: 937-930=7kb (ping and lwip command) > > > > I am not sure I understand this measurement. How is this different > > from measurement 1 where the entire binary was 976K? > > > > > > > > measure 3: > > > 904K - no lwip, CMD_NET_TFTP=y > > > 900K - no lwip, CMD_NET_TFTP=n > > > result 1: original u-boot tftp command 904-900=4kb > > > 890K - no lwip, CMD_NET=n > > > result 2: 900-890=10k original u-boot net/IP stack. > > > > > > My findings for all that measurements and lwip configuration: > > > 1. The original u-boot net stack (packet process and up layers) is 10k vs > > > lwip 40k (the very minimal settings were 30k). > > > 2. Network applications size is about the same 4kb for tftp original > > > command 5kb for lwip. > > > 3. It's quite easy to reuse LWIP examples to implement the same > > > functionality for the U-boot. > > > 4. I still think that there are other criterias which might have more > > > priority than size (bug free code, code reuse, development speed, > > > compatible API to posix and etc). > > > > Yes, there are other criteria and certainly having a complete network > > stack might be worth it in many cases, but we need to keep in mind > > 30kb might be a lot for some systems. > > > > I personally think this is decent and we can optimize lwip more in the > > future. Tom, Simon, how about adding lwip as 'experimental' and > > making it depend on !CMD_NET or something similar? > > That seems OK to me, but we don't really want two network stacks, so > we'd need to set an expectation that we would move to lwip. Yes, we'll need to move on to evaluating that once we can show and use lwip as a replacement for most cases. > I wonder why it is so large? I saw mention of it supporting multiple > buffers and perhaps having a fuller implementation of the protocols. > But it makes U-Boot's stack seem super-slim in comparison. I wonder if > lwip could support just a single buffer and reduced functionality in > other areas? Well, right. Seeing what space related tuneables we can introduce and/or further tune down will be of interest. But that will be easier to do once it's easier to try out lwip in U-Boot itself. -- Tom signature.asc Description: PGP signature
Re: [PATCH] pinephone-pro: Fix I/O port voltage (GPIO3D4A is 1.8V)
On Thu, May 25, 2023 at 2:27 PM Ondřej Jirman wrote: > > From: Ondrej Jirman > > This fixes access to camera sensor over I2C during probe time in > the kernel. (Kernel will fix I/0 port voltage by itself, but the > timing depends on probe order of the drivers, so the fix can > come after the camera sensor driver already failed to probe.) > > Signed-off-by: Ondrej Jirman Reviewed-by: Peter Robinson Tested-by: Peter Robinson > Cc: Kever Yang > --- > board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c > b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c > index eb639cd0d070..b6ccbb9c1c4b 100644 > --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c > +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c > @@ -15,7 +15,8 @@ > #include > #include > > -#define GRF_IO_VSEL_BT565_SHIFT 0 > +#define GRF_IO_VSEL_BT565_GPIO2AB 1 > +#define GRF_IO_VSEL_AUDIO_GPIO3D4A 2 > #define PMUGRF_CON0_VSEL_SHIFT 8 > > #ifndef CONFIG_SPL_BUILD > @@ -48,7 +49,8 @@ static void setup_iodomain(void) >syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF); > > /* BT565 is in 1.8v domain */ > - rk_setreg(&grf->io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT); > + rk_setreg(&grf->io_vsel, > + GRF_IO_VSEL_BT565_GPIO2AB | GRF_IO_VSEL_AUDIO_GPIO3D4A); > > /* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */ > rk_setreg(&pmugrf->soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT); > -- > 2.40.1 >
[PATCH] rockchip: Pinephone Pro: Add DDR RAM type config
Add the RAM_ROCKCHIP_LPDDR4 to fix the Pinephone Pro booting. When the configs were updated in 26f92be07e2 it somehow broke the PPP boot process so let's fix it. Signed-off-by: Peter Robinson CC: Jagan Teki CC: Kever Yang --- configs/pinephone-pro-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/pinephone-pro-rk3399_defconfig b/configs/pinephone-pro-rk3399_defconfig index 4edea88665f..e4a8beeb1ab 100644 --- a/configs/pinephone-pro-rk3399_defconfig +++ b/configs/pinephone-pro-rk3399_defconfig @@ -73,6 +73,7 @@ CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y +CONFIG_RAM_ROCKCHIP_LPDDR4=y CONFIG_DM_RNG=y CONFIG_RNG_ROCKCHIP=y CONFIG_BAUDRATE=150 -- 2.41.0
Re: [PATCH v2 3/7] usb: dwc3-generic: Restrict single ctrl node for RK3328
On Sun, Jun 11, 2023 at 8:23 PM Peter Robinson wrote:
>
> On Tue, Jun 6, 2023 at 6:10 PM Jagan Teki wrote:
> >
> > Like Rockchip RK3568, the RK3328 also have single node to
> > represent the glue and ctrl for USB 3.0.
> >
> > So, use the driver data to use single ctrl for RK3328 DWC3.
> >
> > Reviewed-by: Marek Vasut
> > Signed-off-by: Jagan Teki
> > ---
> > Changes for v2:
> > - collect Marek RB
> >
> > drivers/usb/dwc3/dwc3-generic.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-generic.c
> > b/drivers/usb/dwc3/dwc3-generic.c
> > index 5f8c2613a4..dcf420bafd 100644
> > --- a/drivers/usb/dwc3/dwc3-generic.c
> > +++ b/drivers/usb/dwc3/dwc3-generic.c
> > @@ -621,7 +621,7 @@ static const struct udevice_id dwc3_glue_ids[] = {
> > { .compatible = "ti,dwc3", .data = (ulong)&ti_ops },
> > { .compatible = "ti,am437x-dwc3", .data = (ulong)&ti_ops },
> > { .compatible = "ti,am654-dwc3" },
> > - { .compatible = "rockchip,rk3328-dwc3" },
> > + { .compatible = "rockchip,rk3328-dwc3", .data = (ulong)&rk_ops },
>
> This doesn't build for me against master due to rk_ops not being
> defined, is this against another branch or builds upon another patch
> set?
This, on top of
https://patchwork.ozlabs.org/project/uboot/patch/20230530102617.3413183-5-jo...@kwiboo.se/
Jagan.
Re: [PATCH v2 4/4] net: add NFSv1 support
Am So., 11. Juni 2023 um 17:10 Uhr schrieb Pali Rohár :
>
> On Sunday 11 June 2023 16:57:07 Christian Gmeiner wrote:
> > Hello
> >
> > >
> > > Hello! I must admit that this patch is broken and does not add any NFSv1
> > > support. Just look below
> > >
> >
> > So .. let see what happend here.
> >
> > > On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > > > From: Thomas RIENOESSL
> > > >
> > > > NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > > > September 27, 2018. As of now, NFSv3 is the default choice.
> > > > if the server does not support NFSv3, we fall back to
> > > > versions 2 or 1.
> > > >
> > > > Signed-off-by: Thomas RIENOESSL
> > > > ---
> > > > net/nfs.c | 42 +-
> > > > 1 file changed, 33 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/net/nfs.c b/net/nfs.c
> > > > index 21cae52f35..7a8887ef23 100644
> > > > --- a/net/nfs.c
> > > > +++ b/net/nfs.c
> > > > @@ -26,6 +26,10 @@
> > > > * NFSv2 is still used by default. But if server does not support
> > > > NFSv2, then
> > > > * NFSv3 is used, if available on NFS server. */
> > > >
> > > > +/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > > > + * September 27, 2018. As of now, NFSv3 is the default choice. If the
> > > > server
> > > > + * does not support NFSv3, we fall back to versions 2 or 1. */
> > > > +
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -78,6 +82,7 @@ static char nfs_path_buff[2048];
> > > >
> > > > enum nfs_version {
> > > > NFS_UNKOWN = 0,
> > > > + NFS_V1 = 1,
> > > > NFS_V2 = 2,
> > > > NFS_V3 = 3,
> > > > };
> > > > @@ -192,6 +197,7 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > > > uint32_t *data, int datalen)
> > > > switch (rpc_prog) {
> > > > case PROG_NFS:
> > > > switch (choosen_nfs_version) {
> > > > + case NFS_V1:
> > > > case NFS_V2:
> > > > rpc_pkt.u.call.vers = htonl(2);
> > >
> > > So if NFSv1 is chosen then this code uses NFSv2. This is either rebasing
> > > problem or just prove that this patch does not add any NFSv1 support.
> > >
> > > > break;
> > > > @@ -205,8 +211,26 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > > > uint32_t *data, int datalen)
> > > > break;
> > > > }
> > > > break;
> > > > - case PROG_PORTMAP:
> > > > case PROG_MOUNT:
> > > > + switch (choosen_nfs_version) {
> > > > + case NFS_V1:
> > > > + rpc_pkt.u.call.vers = htonl(1);
> > > > + break;
> > >
> > > And later here for NFSv1 we are trying to use Mount Server, which NFSv1
> > > did not use at all. So this patch really does not have to work with old
> > > NFSv1 servers.
> > >
> > > Instead NFSv1 uses NFSPROC_ROOT RPC call exported by NFS server.
> > > (See that this RPC call is deprecated in NFSv2 and MNT server is used
> > > in NFSv2 instead.)
> > >
> > > MNTv1 is service used by the NFSv2 and it returns NFSv2 file handles
> > > (not NFSv1 file handles). MNTv2 is also used by NFSv2 and as addition to
> > > MNTv1, it adds DIRPATH rpc call. So if NFSv2 does not need to use
> > > DIRPATH then it is fine to use just MNTv1 in NFSv2.
> > >
> > > > +
> > > > + case NFS_V2:
> > > > + rpc_pkt.u.call.vers = htonl(2);
> > > > + break;
> > > > +
> > > > + case NFS_V3:
> > > > + rpc_pkt.u.call.vers = htonl(3);
> > > > + break;
> > > > +
> > > > + case NFS_UNKOWN:
> > > > + /* nothing to do */
> > > > + break;
> > > > + }
> > > > + break;
> > > > + case PROG_PORTMAP:
> > > > default:
> > > > rpc_pkt.u.call.vers = htonl(2); /* portmapper is version
> > > > 2 */
> > > > }
> > > > @@ -311,7 +335,7 @@ static void nfs_readlink_req(void)
> > > > p = &(data[0]);
> > > > p = rpc_add_credentials(p);
> > > >
> > > > - if (choosen_nfs_version == NFS_V2) {
> > > > + if (choosen_nfs_version != NFS_V3) {
> > > > memcpy(p, filefh, NFS_FHSIZE);
> > > > p += (NFS_FHSIZE / 4);
> > > > } else { /* NFS_V3 */
> > > > @@ -340,7 +364,7 @@ static void nfs_lookup_req(char *fname)
> > > > p = &(data[0]);
> > > > p = rpc_add_credentials(p);
> > > >
> > > > - if (choosen_nfs_version == NFS_V2) {
> > > > + if (choosen_nfs_version != NFS_V3) {
> > > > memcpy(p, dirfh, NFS_FHSIZE);
> > > > p += (NFS_FHSIZE / 4);
> > > > *p++ = htonl(fnamelen);
> > > > @@ -380,7 +404,7 @@ static void nfs_read_req(int offset, int readlen)
> > > > p = &(data[0]);
> > > > p = rpc_add_credentials(p);
> > > >
> > > > - if (choosen_nfs_version == NFS_V2) {
> > > > + if (cho
Re: [PATCH v2 4/4] net: add NFSv1 support
On Sunday 11 June 2023 16:57:07 Christian Gmeiner wrote:
> Hello
>
> >
> > Hello! I must admit that this patch is broken and does not add any NFSv1
> > support. Just look below
> >
>
> So .. let see what happend here.
>
> > On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > > From: Thomas RIENOESSL
> > >
> > > NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > > September 27, 2018. As of now, NFSv3 is the default choice.
> > > if the server does not support NFSv3, we fall back to
> > > versions 2 or 1.
> > >
> > > Signed-off-by: Thomas RIENOESSL
> > > ---
> > > net/nfs.c | 42 +-
> > > 1 file changed, 33 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/net/nfs.c b/net/nfs.c
> > > index 21cae52f35..7a8887ef23 100644
> > > --- a/net/nfs.c
> > > +++ b/net/nfs.c
> > > @@ -26,6 +26,10 @@
> > > * NFSv2 is still used by default. But if server does not support NFSv2,
> > > then
> > > * NFSv3 is used, if available on NFS server. */
> > >
> > > +/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > > + * September 27, 2018. As of now, NFSv3 is the default choice. If the
> > > server
> > > + * does not support NFSv3, we fall back to versions 2 or 1. */
> > > +
> > > #include
> > > #include
> > > #include
> > > @@ -78,6 +82,7 @@ static char nfs_path_buff[2048];
> > >
> > > enum nfs_version {
> > > NFS_UNKOWN = 0,
> > > + NFS_V1 = 1,
> > > NFS_V2 = 2,
> > > NFS_V3 = 3,
> > > };
> > > @@ -192,6 +197,7 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > > uint32_t *data, int datalen)
> > > switch (rpc_prog) {
> > > case PROG_NFS:
> > > switch (choosen_nfs_version) {
> > > + case NFS_V1:
> > > case NFS_V2:
> > > rpc_pkt.u.call.vers = htonl(2);
> >
> > So if NFSv1 is chosen then this code uses NFSv2. This is either rebasing
> > problem or just prove that this patch does not add any NFSv1 support.
> >
> > > break;
> > > @@ -205,8 +211,26 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > > uint32_t *data, int datalen)
> > > break;
> > > }
> > > break;
> > > - case PROG_PORTMAP:
> > > case PROG_MOUNT:
> > > + switch (choosen_nfs_version) {
> > > + case NFS_V1:
> > > + rpc_pkt.u.call.vers = htonl(1);
> > > + break;
> >
> > And later here for NFSv1 we are trying to use Mount Server, which NFSv1
> > did not use at all. So this patch really does not have to work with old
> > NFSv1 servers.
> >
> > Instead NFSv1 uses NFSPROC_ROOT RPC call exported by NFS server.
> > (See that this RPC call is deprecated in NFSv2 and MNT server is used
> > in NFSv2 instead.)
> >
> > MNTv1 is service used by the NFSv2 and it returns NFSv2 file handles
> > (not NFSv1 file handles). MNTv2 is also used by NFSv2 and as addition to
> > MNTv1, it adds DIRPATH rpc call. So if NFSv2 does not need to use
> > DIRPATH then it is fine to use just MNTv1 in NFSv2.
> >
> > > +
> > > + case NFS_V2:
> > > + rpc_pkt.u.call.vers = htonl(2);
> > > + break;
> > > +
> > > + case NFS_V3:
> > > + rpc_pkt.u.call.vers = htonl(3);
> > > + break;
> > > +
> > > + case NFS_UNKOWN:
> > > + /* nothing to do */
> > > + break;
> > > + }
> > > + break;
> > > + case PROG_PORTMAP:
> > > default:
> > > rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2
> > > */
> > > }
> > > @@ -311,7 +335,7 @@ static void nfs_readlink_req(void)
> > > p = &(data[0]);
> > > p = rpc_add_credentials(p);
> > >
> > > - if (choosen_nfs_version == NFS_V2) {
> > > + if (choosen_nfs_version != NFS_V3) {
> > > memcpy(p, filefh, NFS_FHSIZE);
> > > p += (NFS_FHSIZE / 4);
> > > } else { /* NFS_V3 */
> > > @@ -340,7 +364,7 @@ static void nfs_lookup_req(char *fname)
> > > p = &(data[0]);
> > > p = rpc_add_credentials(p);
> > >
> > > - if (choosen_nfs_version == NFS_V2) {
> > > + if (choosen_nfs_version != NFS_V3) {
> > > memcpy(p, dirfh, NFS_FHSIZE);
> > > p += (NFS_FHSIZE / 4);
> > > *p++ = htonl(fnamelen);
> > > @@ -380,7 +404,7 @@ static void nfs_read_req(int offset, int readlen)
> > > p = &(data[0]);
> > > p = rpc_add_credentials(p);
> > >
> > > - if (choosen_nfs_version == NFS_V2) {
> > > + if (choosen_nfs_version != NFS_V3) {
> > > memcpy(p, filefh, NFS_FHSIZE);
> > > p += (NFS_FHSIZE / 4);
> > > *p++ = htonl(offset);
> > > @@ -410,13 +434,13 @@ static void nfs_send(void)
> > >
> > > switch (nfs_state) {
> > > case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
> >
Re: [PATCH v2 4/4] net: add NFSv1 support
Am So., 11. Juni 2023 um 15:02 Uhr schrieb Peter Robinson
:
>
> On Sun, Jun 11, 2023 at 1:54 PM Pali Rohár wrote:
> >
> > Hello! I must admit that this patch is broken and does not add any NFSv1
> > support. Just look below
> >
> > On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > > From: Thomas RIENOESSL
> > >
> > > NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > > September 27, 2018. As of now, NFSv3 is the default choice.
> > > if the server does not support NFSv3, we fall back to
> > > versions 2 or 1.
> > >
> > > Signed-off-by: Thomas RIENOESSL
> > > ---
> > > net/nfs.c | 42 +-
> > > 1 file changed, 33 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/net/nfs.c b/net/nfs.c
> > > index 21cae52f35..7a8887ef23 100644
> > > --- a/net/nfs.c
> > > +++ b/net/nfs.c
> > > @@ -26,6 +26,10 @@
> > > * NFSv2 is still used by default. But if server does not support NFSv2,
> > > then
> > > * NFSv3 is used, if available on NFS server. */
> > >
> > > +/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > > + * September 27, 2018. As of now, NFSv3 is the default choice. If the
> > > server
> > > + * does not support NFSv3, we fall back to versions 2 or 1. */
> > > +
> > > #include
> > > #include
> > > #include
> > > @@ -78,6 +82,7 @@ static char nfs_path_buff[2048];
> > >
> > > enum nfs_version {
> > > NFS_UNKOWN = 0,
> > > + NFS_V1 = 1,
> > > NFS_V2 = 2,
> > > NFS_V3 = 3,
> > > };
> > > @@ -192,6 +197,7 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > > uint32_t *data, int datalen)
> > > switch (rpc_prog) {
> > > case PROG_NFS:
> > > switch (choosen_nfs_version) {
> > > + case NFS_V1:
> > > case NFS_V2:
> > > rpc_pkt.u.call.vers = htonl(2);
> >
> > So if NFSv1 is chosen then this code uses NFSv2. This is either rebasing
> > problem or just prove that this patch does not add any NFSv1 support.
> >
> > > break;
> > > @@ -205,8 +211,26 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > > uint32_t *data, int datalen)
> > > break;
> > > }
> > > break;
> > > - case PROG_PORTMAP:
> > > case PROG_MOUNT:
> > > + switch (choosen_nfs_version) {
> > > + case NFS_V1:
> > > + rpc_pkt.u.call.vers = htonl(1);
> > > + break;
> >
> > And later here for NFSv1 we are trying to use Mount Server, which NFSv1
> > did not use at all. So this patch really does not have to work with old
> > NFSv1 servers.
> >
> > Instead NFSv1 uses NFSPROC_ROOT RPC call exported by NFS server.
> > (See that this RPC call is deprecated in NFSv2 and MNT server is used
> > in NFSv2 instead.)
> >
> > MNTv1 is service used by the NFSv2 and it returns NFSv2 file handles
> > (not NFSv1 file handles). MNTv2 is also used by NFSv2 and as addition to
> > MNTv1, it adds DIRPATH rpc call. So if NFSv2 does not need to use
> > DIRPATH then it is fine to use just MNTv1 in NFSv2.
> >
> > > +
> > > + case NFS_V2:
> > > + rpc_pkt.u.call.vers = htonl(2);
> > > + break;
> > > +
> > > + case NFS_V3:
> > > + rpc_pkt.u.call.vers = htonl(3);
> > > + break;
> > > +
> > > + case NFS_UNKOWN:
> > > + /* nothing to do */
> > > + break;
> > > + }
> > > + break;
> > > + case PROG_PORTMAP:
> > > default:
> > > rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2
> > > */
> > > }
> > > @@ -311,7 +335,7 @@ static void nfs_readlink_req(void)
> > > p = &(data[0]);
> > > p = rpc_add_credentials(p);
> > >
> > > - if (choosen_nfs_version == NFS_V2) {
> > > + if (choosen_nfs_version != NFS_V3) {
> > > memcpy(p, filefh, NFS_FHSIZE);
> > > p += (NFS_FHSIZE / 4);
> > > } else { /* NFS_V3 */
> > > @@ -340,7 +364,7 @@ static void nfs_lookup_req(char *fname)
> > > p = &(data[0]);
> > > p = rpc_add_credentials(p);
> > >
> > > - if (choosen_nfs_version == NFS_V2) {
> > > + if (choosen_nfs_version != NFS_V3) {
> > > memcpy(p, dirfh, NFS_FHSIZE);
> > > p += (NFS_FHSIZE / 4);
> > > *p++ = htonl(fnamelen);
> > > @@ -380,7 +404,7 @@ static void nfs_read_req(int offset, int readlen)
> > > p = &(data[0]);
> > > p = rpc_add_credentials(p);
> > >
> > > - if (choosen_nfs_version == NFS_V2) {
> > > + if (choosen_nfs_version != NFS_V3) {
> > > memcpy(p, filefh, NFS_FHSIZE);
> > > p += (NFS_FHSIZE / 4);
> > > *p++ = htonl(offset);
> > > @@ -410,13 +434,13 @@ static void nfs_send(void)
> > >
> > > switch (nfs_state) {
> > > case STATE_PRCLOOKUP_PROG_MOUNT_REQ
Re: [PATCH v2 4/4] net: add NFSv1 support
Hello
>
> Hello! I must admit that this patch is broken and does not add any NFSv1
> support. Just look below
>
So .. let see what happend here.
> On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > From: Thomas RIENOESSL
> >
> > NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > September 27, 2018. As of now, NFSv3 is the default choice.
> > if the server does not support NFSv3, we fall back to
> > versions 2 or 1.
> >
> > Signed-off-by: Thomas RIENOESSL
> > ---
> > net/nfs.c | 42 +-
> > 1 file changed, 33 insertions(+), 9 deletions(-)
> >
> > diff --git a/net/nfs.c b/net/nfs.c
> > index 21cae52f35..7a8887ef23 100644
> > --- a/net/nfs.c
> > +++ b/net/nfs.c
> > @@ -26,6 +26,10 @@
> > * NFSv2 is still used by default. But if server does not support NFSv2,
> > then
> > * NFSv3 is used, if available on NFS server. */
> >
> > +/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > + * September 27, 2018. As of now, NFSv3 is the default choice. If the
> > server
> > + * does not support NFSv3, we fall back to versions 2 or 1. */
> > +
> > #include
> > #include
> > #include
> > @@ -78,6 +82,7 @@ static char nfs_path_buff[2048];
> >
> > enum nfs_version {
> > NFS_UNKOWN = 0,
> > + NFS_V1 = 1,
> > NFS_V2 = 2,
> > NFS_V3 = 3,
> > };
> > @@ -192,6 +197,7 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > uint32_t *data, int datalen)
> > switch (rpc_prog) {
> > case PROG_NFS:
> > switch (choosen_nfs_version) {
> > + case NFS_V1:
> > case NFS_V2:
> > rpc_pkt.u.call.vers = htonl(2);
>
> So if NFSv1 is chosen then this code uses NFSv2. This is either rebasing
> problem or just prove that this patch does not add any NFSv1 support.
>
> > break;
> > @@ -205,8 +211,26 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > uint32_t *data, int datalen)
> > break;
> > }
> > break;
> > - case PROG_PORTMAP:
> > case PROG_MOUNT:
> > + switch (choosen_nfs_version) {
> > + case NFS_V1:
> > + rpc_pkt.u.call.vers = htonl(1);
> > + break;
>
> And later here for NFSv1 we are trying to use Mount Server, which NFSv1
> did not use at all. So this patch really does not have to work with old
> NFSv1 servers.
>
> Instead NFSv1 uses NFSPROC_ROOT RPC call exported by NFS server.
> (See that this RPC call is deprecated in NFSv2 and MNT server is used
> in NFSv2 instead.)
>
> MNTv1 is service used by the NFSv2 and it returns NFSv2 file handles
> (not NFSv1 file handles). MNTv2 is also used by NFSv2 and as addition to
> MNTv1, it adds DIRPATH rpc call. So if NFSv2 does not need to use
> DIRPATH then it is fine to use just MNTv1 in NFSv2.
>
> > +
> > + case NFS_V2:
> > + rpc_pkt.u.call.vers = htonl(2);
> > + break;
> > +
> > + case NFS_V3:
> > + rpc_pkt.u.call.vers = htonl(3);
> > + break;
> > +
> > + case NFS_UNKOWN:
> > + /* nothing to do */
> > + break;
> > + }
> > + break;
> > + case PROG_PORTMAP:
> > default:
> > rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2 */
> > }
> > @@ -311,7 +335,7 @@ static void nfs_readlink_req(void)
> > p = &(data[0]);
> > p = rpc_add_credentials(p);
> >
> > - if (choosen_nfs_version == NFS_V2) {
> > + if (choosen_nfs_version != NFS_V3) {
> > memcpy(p, filefh, NFS_FHSIZE);
> > p += (NFS_FHSIZE / 4);
> > } else { /* NFS_V3 */
> > @@ -340,7 +364,7 @@ static void nfs_lookup_req(char *fname)
> > p = &(data[0]);
> > p = rpc_add_credentials(p);
> >
> > - if (choosen_nfs_version == NFS_V2) {
> > + if (choosen_nfs_version != NFS_V3) {
> > memcpy(p, dirfh, NFS_FHSIZE);
> > p += (NFS_FHSIZE / 4);
> > *p++ = htonl(fnamelen);
> > @@ -380,7 +404,7 @@ static void nfs_read_req(int offset, int readlen)
> > p = &(data[0]);
> > p = rpc_add_credentials(p);
> >
> > - if (choosen_nfs_version == NFS_V2) {
> > + if (choosen_nfs_version != NFS_V3) {
> > memcpy(p, filefh, NFS_FHSIZE);
> > p += (NFS_FHSIZE / 4);
> > *p++ = htonl(offset);
> > @@ -410,13 +434,13 @@ static void nfs_send(void)
> >
> > switch (nfs_state) {
> > case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
> > - if (choosen_nfs_version == NFS_V2)
> > + if (choosen_nfs_version != NFS_V3)
> > rpc_lookup_req(PROG_MOUNT, 1);
> > else /* NFS_V3 */
> > rpc_lookup_req(PROG_MOUNT, 3);
> > break;
> > case STATE_PRCLOOKUP_PROG_NFS_REQ:
> > -
Re: [PATCH v2 3/7] usb: dwc3-generic: Restrict single ctrl node for RK3328
On Tue, Jun 6, 2023 at 6:10 PM Jagan Teki wrote:
>
> Like Rockchip RK3568, the RK3328 also have single node to
> represent the glue and ctrl for USB 3.0.
>
> So, use the driver data to use single ctrl for RK3328 DWC3.
>
> Reviewed-by: Marek Vasut
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - collect Marek RB
>
> drivers/usb/dwc3/dwc3-generic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
> index 5f8c2613a4..dcf420bafd 100644
> --- a/drivers/usb/dwc3/dwc3-generic.c
> +++ b/drivers/usb/dwc3/dwc3-generic.c
> @@ -621,7 +621,7 @@ static const struct udevice_id dwc3_glue_ids[] = {
> { .compatible = "ti,dwc3", .data = (ulong)&ti_ops },
> { .compatible = "ti,am437x-dwc3", .data = (ulong)&ti_ops },
> { .compatible = "ti,am654-dwc3" },
> - { .compatible = "rockchip,rk3328-dwc3" },
> + { .compatible = "rockchip,rk3328-dwc3", .data = (ulong)&rk_ops },
This doesn't build for me against master due to rk_ops not being
defined, is this against another branch or builds upon another patch
set?
> { .compatible = "rockchip,rk3399-dwc3" },
> { .compatible = "rockchip,rk3568-dwc3", .data = (ulong)&rk_ops },
> { .compatible = "qcom,dwc3" },
> --
> 2.25.1
>
Re: [PATCH v2] PCI: zynqmp: Add ZynqMP NWL PCIe root port driver
On Thursday 25 May 2023 11:49:18 Stefan Roese wrote: > This patch adds the PCIe controller driver for the Xilinx / AMD ZynqMP > NWL PCIe Bridge as root port. The driver source is partly copied from > the Linux PCI driver and modified to enable usage in U-Boot (e.g. > simplified and interrupt support removed). > > Signed-off-by: Stefan Roese > Cc: Simon Glass > Cc: Pali Rohár > Cc: Bin Meng > Cc: Michal Simek Looks good, Reviewed-by: Pali Rohár > --- > v2: > - Remove some unused members from struct nwl_pcie > - Fix usage of dev_seq() in nwl_pcie_config_address() > - Remove writing to PCI_PRIMARY_BUS reg as this is done by the > common U-Boot PCI code later > > MAINTAINERS | 1 + > drivers/pci/Kconfig | 7 + > drivers/pci/Makefile | 1 + > drivers/pci/pcie-xilinx-nwl.c | 352 ++ > 4 files changed, 361 insertions(+) > create mode 100644 drivers/pci/pcie-xilinx-nwl.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index c8f72e9ec6a2..2bc19d9daa75 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -343,6 +343,7 @@ F:drivers/rtc/armada38x.c > F: drivers/spi/kirkwood_spi.c > F: drivers/spi/mvebu_a3700_spi.c > F: drivers/pci/pcie_dw_mvebu.c > +F: drivers/pci/pcie-xilinx-nwl.c > F: drivers/watchdog/armada-37xx-wdt.c > F: drivers/watchdog/orion_wdt.c > F: include/configs/mv-common.h > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > index ef328d26525b..60d98d14640d 100644 > --- a/drivers/pci/Kconfig > +++ b/drivers/pci/Kconfig > @@ -374,4 +374,11 @@ config PCIE_UNIPHIER > Say Y here if you want to enable PCIe controller support on > UniPhier SoCs. > > +config PCIE_XILINX_NWL > + bool "Xilinx NWL PCIe controller" > + depends on ARCH_ZYNQMP > + help > + Say 'Y' here if you want support for Xilinx / AMD NWL PCIe > + controller as Root Port. > + > endif > diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile > index 49506e7ba59b..11f60c6991d9 100644 > --- a/drivers/pci/Makefile > +++ b/drivers/pci/Makefile > @@ -49,3 +49,4 @@ obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o > obj-$(CONFIG_PCIE_OCTEON) += pcie_octeon.o > obj-$(CONFIG_PCIE_DW_SIFIVE) += pcie_dw_sifive.o > obj-$(CONFIG_PCIE_UNIPHIER) += pcie_uniphier.o > +obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o > diff --git a/drivers/pci/pcie-xilinx-nwl.c b/drivers/pci/pcie-xilinx-nwl.c > new file mode 100644 > index ..7ef2bdf57b56 > --- /dev/null > +++ b/drivers/pci/pcie-xilinx-nwl.c > @@ -0,0 +1,352 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * PCIe host bridge driver for Xilinx / AMD ZynqMP NWL PCIe Bridge > + * > + * Based on the Linux driver which is: > + * (C) Copyright 2014 - 2015, Xilinx, Inc. > + * > + * Author: Stefan Roese > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Bridge core config registers */ > +#define BRCFG_PCIE_RX0 0x > +#define BRCFG_PCIE_RX1 0x0004 > +#define BRCFG_INTERRUPT 0x0010 > +#define BRCFG_PCIE_RX_MSG_FILTER 0x0020 > + > +/* Egress - Bridge translation registers */ > +#define E_BREG_CAPABILITIES 0x0200 > +#define E_BREG_CONTROL 0x0208 > +#define E_BREG_BASE_LO 0x0210 > +#define E_BREG_BASE_HI 0x0214 > +#define E_ECAM_CAPABILITIES 0x0220 > +#define E_ECAM_CONTROL 0x0228 > +#define E_ECAM_BASE_LO 0x0230 > +#define E_ECAM_BASE_HI 0x0234 > + > +#define I_ISUB_CONTROL 0x03E8 > +#define SET_ISUB_CONTROL BIT(0) > +/* Rxed msg fifo - Interrupt status registers */ > +#define MSGF_MISC_STATUS 0x0400 > +#define MSGF_MISC_MASK 0x0404 > +#define MSGF_LEG_STATUS 0x0420 > +#define MSGF_LEG_MASK0x0424 > +#define MSGF_MSI_STATUS_LO 0x0440 > +#define MSGF_MSI_STATUS_HI 0x0444 > +#define MSGF_MSI_MASK_LO 0x0448 > +#define MSGF_MSI_MASK_HI 0x044C > + > +/* Msg filter mask bits */ > +#define CFG_ENABLE_PM_MSG_FWDBIT(1) > +#define CFG_ENABLE_INT_MSG_FWD BIT(2) > +#define CFG_ENABLE_ERR_MSG_FWD BIT(3) > +#define CFG_ENABLE_MSG_FILTER_MASK (CFG_ENABLE_PM_MSG_FWD |\ > + CFG_ENABLE_INT_MSG_FWD | \ > + CFG_ENABLE_ERR_MSG_FWD) > + > +/* Misc interrupt status mask bits */ > +#define MSGF_MISC_SR_RXMSG_AVAIL BIT(0) > +#define MSGF_MISC_SR_RXMSG_OVER BIT(1) > +#define MSGF_MISC_SR_SLAVE_ERR BIT(4) > +#define MSGF_MISC_SR_MASTER_ERR BIT(5) > +#define MSGF_
Re: bootmenu regression
On Saturday 10 June 2023 16:31:06 Mark Kettenis wrote: > Hi Simon, > > In commit 32bab0eae51 you added a > > #define ansi 0 > > and put the code that positions the cursor to print the "Hit any key > to stop autoboot" message behind an > > if (ansi) > > condition. As a result that message is now printed in whatever place > the cursor happens to be, which happens to be the last menu entry that > gets printed, making that menu option confusing. > > The commit message makes no mention of any intended side-effect of the > change, so am I right assuming that this is debugging code that > accidentally made it out of your tree? Hello! This is known issue and it broke support for bootmenu (tested on nokia n900). I reported it month ago, but there was no reaction for it. So now I sent a revert patches, to make bootmenu work again. I guess that this issue can be later fixed properly.
Re: [PATCH v2] PCI: zynqmp: Add ZynqMP NWL PCIe root port driver
On Friday 02 June 2023 15:30:43 Michal Simek wrote: > Hi Pali, > > On 5/25/23 11:49, Stefan Roese wrote: > Any comment about the driver itself? > > Thanks, > Michal > Why you are so impatient? It is common that people have to wait months or year for review and you unhappy with needed to wait for just week...
Re: mmc: Read eMMC partition access bits before card reset
On Thursday 25 May 2023 14:57:32 Stefan Roese wrote: > Hi Tony, > Hi Pali, > > On 5/18/23 22:55, Tony Dinh wrote: > > Hi Stefan, > > > > On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote: > > > > > > Hi Pali, > > > > > > On 5/17/23 00:30, Pali Rohár wrote: > > > > On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > > > > > On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > > > > > > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > > > > > > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > > > > > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > > > > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > > > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > > > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali > > > > > > > > > > > > > > Rohár wrote: > > > > > > > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, > > > > > > > > > > > > > > > > Stefan Roese wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell > > > > > > > > > > > > > > > > > related patches: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits > > > > > > > > > > > > > > > > before card reset > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access > > > > > > > > > > > > > > > > partitions" says that all reset > > > > > > > > > > > > > > > > events will restore the access bits in > > > > > > > > > > > > > > > > PARTITION_CONFIG CSD register to > > > > > > > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So read partition access bits from > > > > > > > > > > > > > > > > PARTITION_CONFIG CSD register before > > > > > > > > > > > > > > > > issuing card reset. This allows > > > > > > > > > > > > > > > > SPL/U-Boot to get information which eMMC > > > > > > > > > > > > > > > > partition was in use before SPL/U-Boot > > > > > > > > > > > > > > > > was booted. For some platforms this > > > > > > > > > > > > > > > > is the way how to determinate boot > > > > > > > > > > > > > > > > partition from which BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May > > > > > > > > > > > > > > > > 03 2023 - 13:10:10 -0400) > > > > > > > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd > > > > > > > > > > > > > > > > inhibit to clear > > > > > > > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as > > > > > > > > > > > > > > > > needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only > > > > > > > > > > > > > > > idea is to hide this code > > > > > > > > > > > > > > > behind CONFIG symbol and enable it only for > > > > > > > > > > > > > > > mvebu. For example by this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD > > > > > > > > > > > > > > cards? The failure I > > > > > > > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this > > > > > > > > > > > > > stage we do not know if > > > > > > > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > > > > > > > > > > > > > Martin, can you check if booting from SD card is > > > > > > > > > > > > > working fine on mvebu > > > > > > > > > > > > > clearfog? > > > > > > > > > > > > > > > > >
Re: [PATCH v2 4/4] net: add NFSv1 support
On Sun, Jun 11, 2023 at 1:54 PM Pali Rohár wrote:
>
> Hello! I must admit that this patch is broken and does not add any NFSv1
> support. Just look below
>
> On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> > From: Thomas RIENOESSL
> >
> > NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > September 27, 2018. As of now, NFSv3 is the default choice.
> > if the server does not support NFSv3, we fall back to
> > versions 2 or 1.
> >
> > Signed-off-by: Thomas RIENOESSL
> > ---
> > net/nfs.c | 42 +-
> > 1 file changed, 33 insertions(+), 9 deletions(-)
> >
> > diff --git a/net/nfs.c b/net/nfs.c
> > index 21cae52f35..7a8887ef23 100644
> > --- a/net/nfs.c
> > +++ b/net/nfs.c
> > @@ -26,6 +26,10 @@
> > * NFSv2 is still used by default. But if server does not support NFSv2,
> > then
> > * NFSv3 is used, if available on NFS server. */
> >
> > +/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> > + * September 27, 2018. As of now, NFSv3 is the default choice. If the
> > server
> > + * does not support NFSv3, we fall back to versions 2 or 1. */
> > +
> > #include
> > #include
> > #include
> > @@ -78,6 +82,7 @@ static char nfs_path_buff[2048];
> >
> > enum nfs_version {
> > NFS_UNKOWN = 0,
> > + NFS_V1 = 1,
> > NFS_V2 = 2,
> > NFS_V3 = 3,
> > };
> > @@ -192,6 +197,7 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > uint32_t *data, int datalen)
> > switch (rpc_prog) {
> > case PROG_NFS:
> > switch (choosen_nfs_version) {
> > + case NFS_V1:
> > case NFS_V2:
> > rpc_pkt.u.call.vers = htonl(2);
>
> So if NFSv1 is chosen then this code uses NFSv2. This is either rebasing
> problem or just prove that this patch does not add any NFSv1 support.
>
> > break;
> > @@ -205,8 +211,26 @@ static void rpc_req(int rpc_prog, int rpc_proc,
> > uint32_t *data, int datalen)
> > break;
> > }
> > break;
> > - case PROG_PORTMAP:
> > case PROG_MOUNT:
> > + switch (choosen_nfs_version) {
> > + case NFS_V1:
> > + rpc_pkt.u.call.vers = htonl(1);
> > + break;
>
> And later here for NFSv1 we are trying to use Mount Server, which NFSv1
> did not use at all. So this patch really does not have to work with old
> NFSv1 servers.
>
> Instead NFSv1 uses NFSPROC_ROOT RPC call exported by NFS server.
> (See that this RPC call is deprecated in NFSv2 and MNT server is used
> in NFSv2 instead.)
>
> MNTv1 is service used by the NFSv2 and it returns NFSv2 file handles
> (not NFSv1 file handles). MNTv2 is also used by NFSv2 and as addition to
> MNTv1, it adds DIRPATH rpc call. So if NFSv2 does not need to use
> DIRPATH then it is fine to use just MNTv1 in NFSv2.
>
> > +
> > + case NFS_V2:
> > + rpc_pkt.u.call.vers = htonl(2);
> > + break;
> > +
> > + case NFS_V3:
> > + rpc_pkt.u.call.vers = htonl(3);
> > + break;
> > +
> > + case NFS_UNKOWN:
> > + /* nothing to do */
> > + break;
> > + }
> > + break;
> > + case PROG_PORTMAP:
> > default:
> > rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2 */
> > }
> > @@ -311,7 +335,7 @@ static void nfs_readlink_req(void)
> > p = &(data[0]);
> > p = rpc_add_credentials(p);
> >
> > - if (choosen_nfs_version == NFS_V2) {
> > + if (choosen_nfs_version != NFS_V3) {
> > memcpy(p, filefh, NFS_FHSIZE);
> > p += (NFS_FHSIZE / 4);
> > } else { /* NFS_V3 */
> > @@ -340,7 +364,7 @@ static void nfs_lookup_req(char *fname)
> > p = &(data[0]);
> > p = rpc_add_credentials(p);
> >
> > - if (choosen_nfs_version == NFS_V2) {
> > + if (choosen_nfs_version != NFS_V3) {
> > memcpy(p, dirfh, NFS_FHSIZE);
> > p += (NFS_FHSIZE / 4);
> > *p++ = htonl(fnamelen);
> > @@ -380,7 +404,7 @@ static void nfs_read_req(int offset, int readlen)
> > p = &(data[0]);
> > p = rpc_add_credentials(p);
> >
> > - if (choosen_nfs_version == NFS_V2) {
> > + if (choosen_nfs_version != NFS_V3) {
> > memcpy(p, filefh, NFS_FHSIZE);
> > p += (NFS_FHSIZE / 4);
> > *p++ = htonl(offset);
> > @@ -410,13 +434,13 @@ static void nfs_send(void)
> >
> > switch (nfs_state) {
> > case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
> > - if (choosen_nfs_version == NFS_V2)
> > + if (choosen_nfs_version != NFS_V3)
> > rpc_lookup_req(PROG_MOUNT, 1);
> > else /* NFS_V3 */
> > rpc_lookup_req(PROG_MOUNT, 3);
> > break;
> > case STATE_PRCLOOKUP_PROG_NFS_REQ:
Re: [PATCH v2 4/4] net: add NFSv1 support
Hello! I must admit that this patch is broken and does not add any NFSv1
support. Just look below
On Friday 10 March 2023 10:51:55 Christian Gmeiner wrote:
> From: Thomas RIENOESSL
>
> NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> September 27, 2018. As of now, NFSv3 is the default choice.
> if the server does not support NFSv3, we fall back to
> versions 2 or 1.
>
> Signed-off-by: Thomas RIENOESSL
> ---
> net/nfs.c | 42 +-
> 1 file changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/net/nfs.c b/net/nfs.c
> index 21cae52f35..7a8887ef23 100644
> --- a/net/nfs.c
> +++ b/net/nfs.c
> @@ -26,6 +26,10 @@
> * NFSv2 is still used by default. But if server does not support NFSv2, then
> * NFSv3 is used, if available on NFS server. */
>
> +/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
> + * September 27, 2018. As of now, NFSv3 is the default choice. If the server
> + * does not support NFSv3, we fall back to versions 2 or 1. */
> +
> #include
> #include
> #include
> @@ -78,6 +82,7 @@ static char nfs_path_buff[2048];
>
> enum nfs_version {
> NFS_UNKOWN = 0,
> + NFS_V1 = 1,
> NFS_V2 = 2,
> NFS_V3 = 3,
> };
> @@ -192,6 +197,7 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t
> *data, int datalen)
> switch (rpc_prog) {
> case PROG_NFS:
> switch (choosen_nfs_version) {
> + case NFS_V1:
> case NFS_V2:
> rpc_pkt.u.call.vers = htonl(2);
So if NFSv1 is chosen then this code uses NFSv2. This is either rebasing
problem or just prove that this patch does not add any NFSv1 support.
> break;
> @@ -205,8 +211,26 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t
> *data, int datalen)
> break;
> }
> break;
> - case PROG_PORTMAP:
> case PROG_MOUNT:
> + switch (choosen_nfs_version) {
> + case NFS_V1:
> + rpc_pkt.u.call.vers = htonl(1);
> + break;
And later here for NFSv1 we are trying to use Mount Server, which NFSv1
did not use at all. So this patch really does not have to work with old
NFSv1 servers.
Instead NFSv1 uses NFSPROC_ROOT RPC call exported by NFS server.
(See that this RPC call is deprecated in NFSv2 and MNT server is used
in NFSv2 instead.)
MNTv1 is service used by the NFSv2 and it returns NFSv2 file handles
(not NFSv1 file handles). MNTv2 is also used by NFSv2 and as addition to
MNTv1, it adds DIRPATH rpc call. So if NFSv2 does not need to use
DIRPATH then it is fine to use just MNTv1 in NFSv2.
> +
> + case NFS_V2:
> + rpc_pkt.u.call.vers = htonl(2);
> + break;
> +
> + case NFS_V3:
> + rpc_pkt.u.call.vers = htonl(3);
> + break;
> +
> + case NFS_UNKOWN:
> + /* nothing to do */
> + break;
> + }
> + break;
> + case PROG_PORTMAP:
> default:
> rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2 */
> }
> @@ -311,7 +335,7 @@ static void nfs_readlink_req(void)
> p = &(data[0]);
> p = rpc_add_credentials(p);
>
> - if (choosen_nfs_version == NFS_V2) {
> + if (choosen_nfs_version != NFS_V3) {
> memcpy(p, filefh, NFS_FHSIZE);
> p += (NFS_FHSIZE / 4);
> } else { /* NFS_V3 */
> @@ -340,7 +364,7 @@ static void nfs_lookup_req(char *fname)
> p = &(data[0]);
> p = rpc_add_credentials(p);
>
> - if (choosen_nfs_version == NFS_V2) {
> + if (choosen_nfs_version != NFS_V3) {
> memcpy(p, dirfh, NFS_FHSIZE);
> p += (NFS_FHSIZE / 4);
> *p++ = htonl(fnamelen);
> @@ -380,7 +404,7 @@ static void nfs_read_req(int offset, int readlen)
> p = &(data[0]);
> p = rpc_add_credentials(p);
>
> - if (choosen_nfs_version == NFS_V2) {
> + if (choosen_nfs_version != NFS_V3) {
> memcpy(p, filefh, NFS_FHSIZE);
> p += (NFS_FHSIZE / 4);
> *p++ = htonl(offset);
> @@ -410,13 +434,13 @@ static void nfs_send(void)
>
> switch (nfs_state) {
> case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
> - if (choosen_nfs_version == NFS_V2)
> + if (choosen_nfs_version != NFS_V3)
> rpc_lookup_req(PROG_MOUNT, 1);
> else /* NFS_V3 */
> rpc_lookup_req(PROG_MOUNT, 3);
> break;
> case STATE_PRCLOOKUP_PROG_NFS_REQ:
> - if (choosen_nfs_version == NFS_V2)
> + if (choosen_nfs_version != NFS_V3)
> rpc_lookup_req(PROG_NFS, 2);
> else /* NFS_V3 */
> rpc_lookup_req(PROG_NFS, 3);
> @@ -457,7 +481,7 @@ static int rpc_handle_error(struct rpc_t *
[PATCH u-boot 3/3] Revert "menu: Make use of CLI character processing"
This reverts commit 32bab0eae51b55898d1e2804e6614d9143840581.
Signed-off-by: Pali Rohár
---
cmd/bootmenu.c | 9 ++---
cmd/eficonfig.c| 12 ++
common/cli_getch.c | 12 ++
common/menu.c | 92 +-
include/cli.h | 4 +-
include/menu.h | 7 +---
6 files changed, 80 insertions(+), 56 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 6baeedc69f91..c02dc6269283 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -4,7 +4,6 @@
*/
#include
-#include
#include
#include
#include
@@ -85,21 +84,19 @@ static void bootmenu_print_entry(void *data)
static char *bootmenu_choice_entry(void *data)
{
- struct cli_ch_state s_cch, *cch = &s_cch;
struct bootmenu_data *menu = data;
struct bootmenu_entry *iter;
enum bootmenu_key key = BKEY_NONE;
+ int esc = 0;
int i;
- cli_ch_init(cch);
-
while (1) {
if (menu->delay >= 0) {
/* Autoboot was not stopped */
- key = bootmenu_autoboot_loop(menu, cch);
+ key = bootmenu_autoboot_loop(menu, &esc);
} else {
/* Some key was pressed, so autoboot was stopped */
- key = bootmenu_loop(menu, cch);
+ key = bootmenu_loop(menu, &esc);
}
switch (key) {
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 720f52b48b8c..5c3ed76e78f5 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -6,7 +6,6 @@
*/
#include
-#include
#include
#include
#include
@@ -230,16 +229,14 @@ void eficonfig_display_statusline(struct menu *m)
*/
char *eficonfig_choice_entry(void *data)
{
- struct cli_ch_state s_cch, *cch = &s_cch;
+ int esc = 0;
struct list_head *pos, *n;
struct eficonfig_entry *entry;
enum bootmenu_key key = BKEY_NONE;
struct efimenu *efi_menu = data;
- cli_ch_init(cch);
-
while (1) {
- key = bootmenu_loop((struct bootmenu_data *)efi_menu, cch);
+ key = bootmenu_loop((struct bootmenu_data *)efi_menu, &esc);
switch (key) {
case BKEY_UP:
@@ -1929,15 +1926,14 @@ static void
eficonfig_print_change_boot_order_entry(void *data)
*/
char *eficonfig_choice_change_boot_order(void *data)
{
- struct cli_ch_state s_cch, *cch = &s_cch;
+ int esc = 0;
struct list_head *pos, *n;
struct efimenu *efi_menu = data;
enum bootmenu_key key = BKEY_NONE;
struct eficonfig_entry *entry, *tmp;
- cli_ch_init(cch);
while (1) {
- key = bootmenu_loop(NULL, cch);
+ key = bootmenu_loop(NULL, &esc);
switch (key) {
case BKEY_PLUS:
diff --git a/common/cli_getch.c b/common/cli_getch.c
index 61d4cb261b81..8080ff814eff 100644
--- a/common/cli_getch.c
+++ b/common/cli_getch.c
@@ -140,11 +140,10 @@ int cli_ch_process(struct cli_ch_state *cch, int ichar)
* sequence
*/
if (!ichar) {
- if (cch->emitting) {
+ if (cch->emit_upto) {
if (cch->emit_upto < cch->esc_len)
return cch->esc_save[cch->emit_upto++];
cch->emit_upto = 0;
- cch->emitting = false;
cch->esc_len = 0;
}
return 0;
@@ -176,21 +175,18 @@ int cli_ch_process(struct cli_ch_state *cch, int ichar)
case ESC_SAVE:
/* save this character and return nothing */
cch->esc_save[cch->esc_len++] = ichar;
- ichar = 0;
- break;
+ return 0;
case ESC_REJECT:
/*
* invalid escape sequence, start returning the
* characters in it
*/
cch->esc_save[cch->esc_len++] = ichar;
- ichar = cch->esc_save[cch->emit_upto++];
- cch->emitting = true;
- return ichar;
+ return cch->esc_save[cch->emit_upto++];
case ESC_CONVERTED:
/* valid escape sequence, return the resulting char */
cch->esc_len = 0;
- break;
+ return ichar;
}
}
diff --git a/common/menu.c b/common/menu.c
index b6ec2e9c616c..5b614eafa413 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -15,8 +15,6 @@
#include "menu.h"
-#define ansi 0
-
/*
* Internally, each item in a menu is represented by a struct menu_item.
*
@@ -427,19 +425,15 @@ int menu_destroy(struct menu *m)
return 1;
}
-enum bootmenu_key bootmenu_autoboot_loop(struct bootme
[PATCH u-boot 2/3] Revert "menu: Factor out menu-keypress decoding"
This reverts commit 9e7ac0b0be5cb663e539716554d66f8f0890ca83.
Signed-off-by: Pali Rohár
---
common/menu.c | 48 ++--
include/menu.h | 10 --
2 files changed, 18 insertions(+), 40 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index 94514177e4e9..b6ec2e9c616c 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -483,11 +483,26 @@ enum bootmenu_key bootmenu_autoboot_loop(struct
bootmenu_data *menu,
return key;
}
-enum bootmenu_key bootmenu_conv_key(int ichar)
+enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
+ struct cli_ch_state *cch)
{
- enum bootmenu_key key;
+ enum bootmenu_key key = BKEY_NONE;
+ int c;
+
+ c = cli_ch_process(cch, 0);
+ if (!c) {
+ while (!c && !tstc()) {
+ schedule();
+ mdelay(10);
+ c = cli_ch_process(cch, -ETIMEDOUT);
+ }
+ if (!c) {
+ c = getchar();
+ c = cli_ch_process(cch, c);
+ }
+ }
- switch (ichar) {
+ switch (c) {
case '\n':
/* enter key was pressed */
key = BKEY_SELECT;
@@ -515,34 +530,7 @@ enum bootmenu_key bootmenu_conv_key(int ichar)
case ' ':
key = BKEY_SPACE;
break;
- default:
- key = BKEY_NONE;
- break;
- }
-
- return key;
-}
-
-enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
- struct cli_ch_state *cch)
-{
- enum bootmenu_key key;
- int c;
-
- c = cli_ch_process(cch, 0);
- if (!c) {
- while (!c && !tstc()) {
- schedule();
- mdelay(10);
- c = cli_ch_process(cch, -ETIMEDOUT);
- }
- if (!c) {
- c = getchar();
- c = cli_ch_process(cch, c);
- }
}
- key = bootmenu_conv_key(c);
-
return key;
}
diff --git a/include/menu.h b/include/menu.h
index 64ce89b7d263..5e54f033dfa4 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -54,8 +54,6 @@ enum bootmenu_key {
BKEY_MINUS,
BKEY_SPACE,
BKEY_SAVE,
-
- BKEY_COUNT,
};
/**
@@ -104,12 +102,4 @@ enum bootmenu_key bootmenu_autoboot_loop(struct
bootmenu_data *menu,
enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
struct cli_ch_state *cch);
-/**
- * bootmenu_conv_key() - Convert a U-Boot keypress into a menu key
- *
- * @ichar: Keypress to convert (ASCII, including control characters)
- * Returns: Menu key that corresponds to @ichar, or BKEY_NONE if none
- */
-enum bootmenu_key bootmenu_conv_key(int ichar);
-
#endif /* __MENU_H__ */
--
2.20.1
[PATCH u-boot 1/3] Revert "video: Enable VIDEO_ANSI by default only with EFI"
This reverts commit 72a0dd8bed010bef78028ae528763f9807758e6b. Signed-off-by: Pali Rohár --- drivers/video/Kconfig | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 1e2f4e6de4a5..52f7eac1e6a3 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -141,13 +141,10 @@ config VIDEO_BPP32 config VIDEO_ANSI bool "Support ANSI escape sequences in video console" - default y if EFI_LOADER + default y help Enable ANSI escape sequence decoding for a more fully functional - console. Functionality includes changing the text colour and moving - the cursor. These date from the 1970s and are still widely used today - to control a text terminal. U-Boot implements these by decoding the - sequences and performing the appropriate operation. + console. config VIDEO_MIPI_DSI bool "Support MIPI DSI interface" -- 2.20.1
[PATCH u-boot 0/3] Revert broken Bootmenu commits
These 3 commits broke support for U-Boot Bootmenu on Nokia N900. Issues were reported more than month ago, but nobody reacted to them. So revert these broken commits for now, to fix U-Boot Bootmenu support. With these revered commits, U-Boot Bootmenu from master branch is working fine again on Nokia N900. Pali Rohár (3): Revert "video: Enable VIDEO_ANSI by default only with EFI" Revert "menu: Factor out menu-keypress decoding" Revert "menu: Make use of CLI character processing" cmd/bootmenu.c| 9 ++-- cmd/eficonfig.c | 12 ++--- common/cli_getch.c| 12 ++--- common/menu.c | 122 ++ drivers/video/Kconfig | 7 +-- include/cli.h | 4 +- include/menu.h| 17 +- 7 files changed, 91 insertions(+), 92 deletions(-) -- 2.20.1
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
On 6/9/23 20:52, Xavier Drudis Ferran wrote: 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... Thank you => 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_device at least isn't null as in my patch is possibly a partial solution. I'm sure if it's null we shouldn't call, but if it
Re: [PATCH] mtd: spi-nor-ids: add xtxtech part#
On Wed, Jun 7, 2023 at 8:48 AM Bruce Suen wrote:
>
> adding xtxtech part numbers
>
> Signed-off-by: Bruce Suen
> ---
Rework on commit head, it is unclear.
> drivers/mtd/spi/spi-nor-ids.c | 38 +--
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 3f8b796789..9a079c851d 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -528,8 +528,42 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("XM25QH128A", 0x207018, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> #endif
> #ifdef CONFIG_SPI_FLASH_XTX
> - /* XTX Technology (Shenzhen) Limited */
> - { INFO("xt25f128b", 0x0b4018, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
Why were these existing id's removed?
Jagan
Re: [PATCH v3 06/10] dt-bindings: spi: Add bcm63xx-hsspi controller support
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote: > > Bring the device tree binding document from Linux to u-boot > > Port from linux patches: > Link: > https://lore.kernel.org/r/20230207065826.285013-2-william.zh...@broadcom.com > Link: > https://lore.kernel.org/r/20230207065826.285013-3-william.zh...@broadcom.com > Signed-off-by: William Zhang > --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master
Re: [PATCH v3 05/10] spi: bcmbca-hsspi: Add driver for newer HSSPI controller
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote: > > The newer BCMBCA SoCs such as BCM6756, BCM4912 and BCM6855 include an > updated SPI controller that add the capability to allow the driver to > control chip select explicitly. Driver can control and keep cs low > between the transfers natively. Hence the dummy cs workaround or prepend > mode found in the bcm63xx-hsspi driver are no longer needed and this new > driver is much cleaner. > > Port from linux patch: > Link: > https://lore.kernel.org/r/20230209200246.141520-15-william.zh...@broadcom.com > Signed-off-by: William Zhang > --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master
Re: [PATCH v3 04/10] spi: bcm63xx-hsspi: Add prepend mode support
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote: > > Due to the controller limitation to keep the chip select low during the > bus idle time between the transfer, a dummy cs workaround was used when > this driver was first upstreamed to the u-boot based on linux kernel > driver. It basically picks the dummy cs as !actual_cs so typically dummy > cs is 1 when most of the case only cs 0 is used in the board design. > Then invert the polarity of both cs and tell the controller to start the > transfers using dummy cs. Assuming both cs are active low before the > inversion, effectively this keeps dummy cs high and actual cs low during > the transfer and workaround the issue. > > This workaround requires that dummy cs 1 pin to is set to SPI chip > selection function in the pinmux when the transfer clock is above 25MHz. > The old chips likely have default pinmux set to chip select on the dummy > cs pin so it works but this is not case for the new Broadband BCA chips > and this workaround stop working. This is specifically an issue to > support SPI NAND and SPI NOR flash because these flash devices can > typically run at or above 100MHz. > > This patch utilizes the prepend feature of the controller to combine the > multiple transfers in the same message to a single transfer when > possible. This way there is no need to keep clock low between transfers > and solve the issue without any pinmux requirement. > > Multiple transfers within a SPI message may be combined into one > transfer if the following are all true: > * One or more half duplex write transfer in single bit mode > * Optional full duplex read/write at the end > * No delay and cs_change between transfers > > Most of the SPI device meets this requirements such as SPI NOR, SPI NAND > flash, Broadcom SPI voice card and etc. So this change switches to the > prepend mode as the default mode. For any SPI message that does not meet > the above requirement, we switch to original dummy cs mode but limit the > clock rate to the safe 25MHz. > > Port from linux patch: > Link: > https://lore.kernel.org/r/20230209200246.141520-12-william.zh...@broadcom.com > > Signed-off-by: William Zhang > --- Acked-by: Jagan Teki Applied to u-boot-spi/master
Re: [PATCH v3 03/10] spi: bcm63xx-hsspi: Add new compatible string support
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote: > > New compatible string brcm,bcmbca-hsspi-v1.0 is introduced based on > dts document brcm,bcm63xx-hsspi.yaml. Add it to the driver to support > this new binding. > > Port from linux patch: > Link: > https://lore.kernel.org/r/20230207065826.285013-6-william.zh...@broadcom.com > Signed-off-by: William Zhang > Reviewed-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH v3 02/10] spi: bcm63xx-hsspi: Fix multi-bit mode setting
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote:
>
> Currently the driver always sets the controller to dual data bit mode
> for both tx and rx data in the profile mode control register even for
> single data bit transfer. Luckily the opcode is set correctly according
> to SPI transfer data bit width so it does not actually cause issues.
>
> This change fixes the problem by setting tx and rx data bit mode field
> correctly according to the actual SPI transfer tx and rx data bit width.
>
> Fixes: 29cc4368ad4b ("dm: spi: add BCM63xx HSSPI driver")
> Port from linux patch:
> Link:
> https://lore.kernel.org/r/20230209200246.141520-11-william.zh...@broadcom.com
> Signed-off-by: William Zhang
> Reviewed-by: Jagan Teki
> ---
Applied to u-boot-spi/master
Re: [PATCH v3 01/10] spi: bcm63xx-hsspi: Make driver depend on BCMBCA arch
On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote: > > ARCH_BCMBCA was introduced to cover individual Broadcom broadband SoC > for common features and IP blocks. Use this config instead of each chip > config as the Kconfig dependency for Broadcom HSSPI driver. > > Signed-off-by: William Zhang > --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master
Re: [PATCH 1/2] spi: soft_spi: Support the recommended soft spi properties
On Fri, May 19, 2023 at 3:52 AM Fabio Estevam wrote: > > From: Fabio Estevam > > According to Documentation/devicetree/bindings/spi/spi-gpio.yaml > from Linux, the recommended spio-gpio properties are: > > sck-gpios, miso-gpios and mosi-gpios. > > gpio-sck, gpio-mosi and gpio-miso are considered deprecated. > > Currently, U-Boot only supports the deprecated properties. > > Allow the soft_spi driver to support both the new and old properties. > > Signed-off-by: Fabio Estevam > --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master
Re: [PATCH 2/2] doc: bindings: soft-spi: Remove the usage of deprecated properties
On Fri, May 19, 2023 at 3:52 AM Fabio Estevam wrote: > > From: Fabio Estevam > > According to Documentation/devicetree/bindings/spi/spi-gpio.yaml > from Linux, the recommended spio-gpio properties are: > > sck-gpios, miso-gpios and mosi-gpios. > > gpio-sck, gpio-mosi and gpio-miso are considered deprecated. > > Update the bindings to suggest the recommeded properties. > > Signed-off-by: Fabio Estevam > --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master
Re: [PATCH] spi: synquacer: remove SPI_TX_BYTE handling
On Wed, May 24, 2023 at 1:03 PM Masahisa Kojima wrote: > > Current code expects that SPI_TX_BYTE is single bit mode > but it is wrong. It indicates byte program mode, > not single bit mode. > > If SPI_TX_DUAL, SPI_TX_QUAD and SPI_TX_OCTAL bits are not set, > the default transfer bus width is single bit. > > Signed-off-by: Masahisa Kojima > --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Hi, On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas wrote: > > Hi Maxim, > > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov wrote: > > > > Greetings, > > > > I implemented the tftp client (that was quick due to lwip has example app > > for tftp), and did some more measurements. > > I uploaded patches here if somebody want to do his own measurements: > > https://github.com/muvarov/uboot-lwip > > > > measure 1: > > 976K - total (total means lwip with all 3 commands ping, tftp, wget) > > 971K - total - tftp (total, but disable/minus tftp) > > 965K - total - tftp - wget (disable tftp and wget) > > 963K - total - tftp - wget - ping (disable tftp, wget, ping) > > 931K - no lwip > > > > result 1: lwip tftp (+ udp protocol) protocol 976-971k = 5kb > > result 2: lwip ping command 965- 963 = 2kb > > result 3: lwip wget command 971- 965 = 6kb > > result 4: lwip core stack with apps 976 - 931 = 45kb > > So tftp = 5kb, wget = 6kb ping =2kb and lwip = 32kb > > > > > measure 2: > > 890K - no CONFIG_NET_CMD > > 930K - + lwip tftp only > > 937K - + full lwip (ping wget tftp) > > > > result 1: 937-890=47kb ( lwip + all 3 commands) > > result 2: 937-930=7kb (ping and lwip command) > > I am not sure I understand this measurement. How is this different > from measurement 1 where the entire binary was 976K? > > > > > measure 3: > > 904K - no lwip, CMD_NET_TFTP=y > > 900K - no lwip, CMD_NET_TFTP=n > > result 1: original u-boot tftp command 904-900=4kb > > 890K - no lwip, CMD_NET=n > > result 2: 900-890=10k original u-boot net/IP stack. > > > > My findings for all that measurements and lwip configuration: > > 1. The original u-boot net stack (packet process and up layers) is 10k vs > > lwip 40k (the very minimal settings were 30k). > > 2. Network applications size is about the same 4kb for tftp original > > command 5kb for lwip. > > 3. It's quite easy to reuse LWIP examples to implement the same > > functionality for the U-boot. > > 4. I still think that there are other criterias which might have more > > priority than size (bug free code, code reuse, development speed, > > compatible API to posix and etc). > > Yes, there are other criteria and certainly having a complete network > stack might be worth it in many cases, but we need to keep in mind > 30kb might be a lot for some systems. > > I personally think this is decent and we can optimize lwip more in the > future. Tom, Simon, how about adding lwip as 'experimental' and > making it depend on !CMD_NET or something similar? That seems OK to me, but we don't really want two network stacks, so we'd need to set an expectation that we would move to lwip. I wonder why it is so large? I saw mention of it supporting multiple buffers and perhaps having a fuller implementation of the protocols. But it makes U-Boot's stack seem super-slim in comparison. I wonder if lwip could support just a single buffer and reduced functionality in other areas? Regards, Simon > > Thanks > /Ilias > > > > BR, > > Maxim. > > > > On Thu, 25 May 2023 at 02:18, Simon Goldschmidt wrote: > >> > >> Hi Maxim, Tom, > >> > >> On 24.05.2023 16:05, Maxim Uvarov wrote: > >> > On Tue, 23 May 2023 at 03:23, Tom Rini wrote: > >> > > >> >> On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: > >> >>> On Mon, 22 May 2023 at 10:20, Tom Rini wrote: > >> >>> > >> On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: > >> > Hi Maxim > >> > > >> > On Mon, 22 May 2023 at 12:01, Maxim Uvarov > >> wrote: > >> >> > >> >> My measurements for binary after LTO looks like: > >> >> > >> >> U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % > >> >> 870728| 915000| 912560 | > >> 41832| 4.8 > >> > > >> > > >> > I think you'll need to analyze that a bit more. First of all I don't > >> > think the '+ping' tab is useful. What is is trying to achieve? > >> > >> >>> > >> >>> To show the difference of extra bytes if we add a ping app on top. > >> >>> > >> >>> > >> > - How was LWIP compiled? > >> > >> >>> > >> >>> It has a really huge configuration. I tried to turn off everything off > >> >>> everything what can impact on size but still make http app work: > >> >>> #define LWIP_HAVE_LOOPIF0 > >> >>> #define LWIP_NETCONN0 > >> >>> #define LWIP_SOCKET 0 > >> >>> #define SO_REUSE0 > >> >>> #define LWIP_STATS 0 > >> >>> #define PPP_SUPPORT 0 > >> >>> > >> >>> Disabling loopback: > >> >>> #define LWIP_NETIF_LOOPBACK 0 > >> >>> can lower to 912288 bytes. > >> >>> > >> >>> And it's the same compilation option (optimization for size) as the > >> >>> main > >> >>> u-boot. I will do more experiments, but I think the goal is not to turn > >> >> off > >> >>> everything. > >> >>> > >> >>> > >> > - Was ipv6 supported? > >> > >> >>> > >> >>> No. I.e. when I
