Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR

2022-01-25 Thread Bin Meng
On Tue, Jan 25, 2022 at 2:02 PM Anup Patel  wrote:
>
> On Tue, Jan 25, 2022 at 10:33 AM Bin Meng  wrote:
> >
> > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
> > >
> > > Currently, if MTD NOR is enabled then U-Boot tries to issue flash
> > > commands even when CFI flash DT node is not present. This causes
> > > access fault on RISC-V emulators or ISS which do not emulate CFI
> > > flash. To handle this issue, we implement is_flash_available() for
> > > qemu-riscv board which will return 1 only if CFI flash DT node is
> > > present.
> > >
> > > Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> > > Signed-off-by: Anup Patel 
> > > ---
> > >  board/emulation/qemu-riscv/qemu-riscv.c | 17 +
> > >  1 file changed, 17 insertions(+)
> > >
> > > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c 
> > > b/board/emulation/qemu-riscv/qemu-riscv.c
> > > index b0d9dd59b1..cd02dae1ab 100644
> > > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > > @@ -8,6 +8,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -16,6 +17,22 @@
> > >
> > >  DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
> > > +int is_flash_available(void)
> > > +{
> > > +   if (IS_ENABLED(CONFIG_OF_SEPARATE) || 
> > > IS_ENABLED(CONFIG_OF_BOARD)) {
> >
> > Why is this if statement needed?
> >
> > All QEMU riscv* defconfigs are using CONFIG_OF_BOARD, and there is no
> > OF_SEPARATE use case since QEMU DTBs are always consumed by U-Boot.
>
> I added the if statement for the case if someone disables CONFIG_OF_BOARD
> but I can remove it if you insist.
>

I see. But I if we give a dtb to QEMU without using CONFIG_OF_BOARD,
the dtb may still contain a node for flash so the logic you added is
still needed.

So I think you can just remove the if statement.

Also instead of using fdt_node_offset_by_compatible API please use
ofnode_device_is_compatible.

Regards,
Bin


Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver

2022-01-25 Thread Bin Meng
On Tue, Jan 25, 2022 at 2:00 PM Anup Patel  wrote:
>
> On Tue, Jan 25, 2022 at 10:22 AM Bin Meng  wrote:
> >
> > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
> > >
> > > Quite a few RISC-V emulators and ISS (including Spike) have host
> > > transfer interface (HTIF) based console. This patch adds HTIF
> > > based console driver for RISC-V platforms which depends totally
> > > on DT node for HTIF register base address.
> > >
> > > Signed-off-by: Anup Patel 
> > > Reviewed-by: Philipp Tomsich 
> > > ---
> > >  drivers/serial/Kconfig   |   8 ++
> > >  drivers/serial/Makefile  |   1 +
> > >  drivers/serial/serial_htif.c | 178 +++
> > >  3 files changed, 187 insertions(+)
> > >  create mode 100644 drivers/serial/serial_htif.c
> > >
> > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > > index 6c8fdda9a0..345d1881f5 100644
> > > --- a/drivers/serial/Kconfig
> > > +++ b/drivers/serial/Kconfig
> > > @@ -866,6 +866,14 @@ config PXA_SERIAL
> > >   If you have a machine based on a Marvell XScale PXA2xx CPU you
> > >   can enable its onboard serial ports by enabling this option.
> > >
> > > +config HTIF_CONSOLE
> > > +   bool "RISC-V HTIF console support"
> > > +   depends on DM_SERIAL && 64BIT
> >
> > Does this driver not work on 32-bit?
>
> Only putc() works but getc() does not work on 32-bit. Same issue
> is there with OpenSBI and BBL as well. That's why I have restricted
> this driver to 64-bit only.
>

I don't get it. Is this a QEMU riscv32 bug?

Regards,
Bin


Re: [PATCH 0/3] QEMU spike machine support for U-Boot

2022-01-24 Thread Bin Meng
On Tue, Jan 18, 2022 at 6:56 PM Anup Patel  wrote:
>
> On Tue, Jan 18, 2022 at 3:41 PM Bin Meng  wrote:
> >
> > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
> > >
> > > We can use same U-Boot binary compiled using qemu-riscv64_smode_defconfig
> > > on QEMU virt machine and QEMU spike machine. To achieve this, we need HTIF
> > > console support for U-Boot QEMU RISC-V board hence this series.
> > >
> > > To test this series with latest OpenSBI, we can use the following command:
> > > qemu-system-riscv64 -M spike -m 256M -display none -serial stdio \
> > > -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel \
> >
> > I think you forgot to mention this needs an updated QEMU too, due to
> > plain binary is now used for spike?
>
> Ahh, yes. I should have provided the link to the QEMU spike machine patch.
>
> QEMU patch link:
> https://lore.kernel.org/all/20220114160457.70134-1-apa...@ventanamicro.com/
>

Please also include a patch to update the QEMU riscv board doc, with
the updated instructions on QEMU for Spike machine.

Regards,
Bin


Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR

2022-01-24 Thread Bin Meng
On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
>
> Currently, if MTD NOR is enabled then U-Boot tries to issue flash
> commands even when CFI flash DT node is not present. This causes
> access fault on RISC-V emulators or ISS which do not emulate CFI
> flash. To handle this issue, we implement is_flash_available() for
> qemu-riscv board which will return 1 only if CFI flash DT node is
> present.
>
> Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> Signed-off-by: Anup Patel 
> ---
>  board/emulation/qemu-riscv/qemu-riscv.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c 
> b/board/emulation/qemu-riscv/qemu-riscv.c
> index b0d9dd59b1..cd02dae1ab 100644
> --- a/board/emulation/qemu-riscv/qemu-riscv.c
> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -16,6 +17,22 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
> +int is_flash_available(void)
> +{
> +   if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {

Why is this if statement needed?

All QEMU riscv* defconfigs are using CONFIG_OF_BOARD, and there is no
OF_SEPARATE use case since QEMU DTBs are always consumed by U-Boot.

> +   const void *fdt =
> +   (const void *)(uintptr_t)gd->arch.firmware_fdt_addr;
> +   int rc = fdt_node_offset_by_compatible(fdt, -1, "cfi-flash");
> +
> +   if (rc >= 0)
> +   return 1;
> +   }
> +
> +   return 0;
> +}
> +#endif
> +
>  int board_init(void)
>  {
> /*

Regards,
Bin


Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver

2022-01-24 Thread Bin Meng
On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
>
> Quite a few RISC-V emulators and ISS (including Spike) have host
> transfer interface (HTIF) based console. This patch adds HTIF
> based console driver for RISC-V platforms which depends totally
> on DT node for HTIF register base address.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Philipp Tomsich 
> ---
>  drivers/serial/Kconfig   |   8 ++
>  drivers/serial/Makefile  |   1 +
>  drivers/serial/serial_htif.c | 178 +++
>  3 files changed, 187 insertions(+)
>  create mode 100644 drivers/serial/serial_htif.c
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 6c8fdda9a0..345d1881f5 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -866,6 +866,14 @@ config PXA_SERIAL
>   If you have a machine based on a Marvell XScale PXA2xx CPU you
>   can enable its onboard serial ports by enabling this option.
>
> +config HTIF_CONSOLE
> +   bool "RISC-V HTIF console support"
> +   depends on DM_SERIAL && 64BIT

Does this driver not work on 32-bit?

> +   help
> + Select this to enable host transfer interface (HTIF) based serial
> + console. The HTIF device is quite common in RISC-V emulators and
> + RISC-V ISS so this driver allows using U-Boot on such platforms.
> +
>  config SIFIVE_SERIAL
> bool "SiFive UART support"
> depends on DM_SERIAL

Regards,
Bin


Re: [PATCH 0/3] QEMU spike machine support for U-Boot

2022-01-18 Thread Bin Meng
On Sat, Jan 15, 2022 at 12:20 AM Anup Patel  wrote:
>
> We can use same U-Boot binary compiled using qemu-riscv64_smode_defconfig
> on QEMU virt machine and QEMU spike machine. To achieve this, we need HTIF
> console support for U-Boot QEMU RISC-V board hence this series.
>
> To test this series with latest OpenSBI, we can use the following command:
> qemu-system-riscv64 -M spike -m 256M -display none -serial stdio \
> -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel \

I think you forgot to mention this needs an updated QEMU too, due to
plain binary is now used for spike?

> ./u-boot/u-boot.bin
>
> These patch can be found in qemu_riscv_htif_v1 branch at:
> https://github.com/avpatel/u-boot.git
>
> Anup Patel (3):
>   serial: Add RISC-V HTIF console driver
>   riscv: qemu: Enable HTIF console support
>   riscv: qemu: Implement is_flash_available() for MTD NOR
>
>  board/emulation/qemu-riscv/Kconfig  |   1 +
>  board/emulation/qemu-riscv/qemu-riscv.c |  17 +++
>  drivers/serial/Kconfig  |   8 ++
>  drivers/serial/Makefile |   1 +
>  drivers/serial/serial_htif.c| 178 
>  5 files changed, 205 insertions(+)
>  create mode 100644 drivers/serial/serial_htif.c
>

Regards,
Bin


Re: [PATCH] riscv: sifive: Fix OF_BOARD boot failure

2022-01-05 Thread Bin Meng
Hi Tom,

On Wed, Jan 5, 2022 at 9:08 AM Bin Meng  wrote:
>
> When using QEMU to have a quick test of booting U-Boot S-mode payload
> directly without the needs of preparing the SPI flash or SD card images
> for SiFive Unleashed board, as per the instructions [1], it currently
> does not boot any more.
>
> This was caused by the OF_PRIOR_STAGE removal, as gd->fdt_blob no longer
> points to a valid DTB. OF_BOARD is supposed to replace OF_PRIOR_STAGE,
> hence we need to add the OF_BOARD logic in board_fdt_blob_setup().
>
> [1] 
> https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
>
> Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
> Fixes: d6f8ab30a2af ("treewide: Remove OF_PRIOR_STAGE")
> Signed-off-by: Bin Meng 
> ---
>
>  board/sifive/unleashed/unleashed.c | 2 +-
>  board/sifive/unmatched/unmatched.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Would you pick up this patch directly for v2022.01?

Regards,
Bin


Re: [PATCH] usb: xhci: reset endpoint on USB stall

2022-01-04 Thread Bin Meng
Hi Stefan,

On Wed, Jan 5, 2022 at 3:48 AM Stefan Agner  wrote:
>
> Bin Meng,
>
> On 2021-09-27 17:14, Marek Vasut wrote:
> > On 9/27/21 2:42 PM, Stefan Agner wrote:
> >> There are devices which cause a USB stall when trying to read strings.
> >> Specifically Arduino Mega R3 stalls when trying to read the product
> >> string.
> >>
> >> The stall currently remains unhandled, and subsequent retries submit new
> >> transfers on a stopped endpoint which ultimately cause a crash in
> >> abort_td():
> >> WARN halted endpoint, queueing URB anyway.
> >> XHCI control transfer timed out, aborting...
> >> Unexpected XHCI event TRB, skipping... (3affe040  1300 
> >> 02008401)
> >> BUG at drivers/usb/host/xhci-ring.c:505/abort_td()!
> >> BUG!
> >> resetting ...
> >>
> >> Linux seems to be able to recover from the stall by issuing a
> >> TRB_RESET_EP command.
> >>
> >> Introduce reset_ep() which issues a TRB_RESET_EP followed by setting the
> >> transfer ring dequeue pointer via TRB_SET_DEQ. This allows to properly
> >> recover from a USB stall error and continue communicating with the USB
> >> device.
> >>
> >> Signed-off-by: Stefan Agner 
> >
> > I hope to get AB/RB from Bin here, then it can go into this release I think.
>
> Any chance you could have a look at this to get it into this release :)
>

Sorry I missed this. I suspect it's too late for 2022.01 to include
such big changes :(

Regards,
Bin


[PATCH] riscv: sifive: Fix OF_BOARD boot failure

2022-01-04 Thread Bin Meng
When using QEMU to have a quick test of booting U-Boot S-mode payload
directly without the needs of preparing the SPI flash or SD card images
for SiFive Unleashed board, as per the instructions [1], it currently
does not boot any more.

This was caused by the OF_PRIOR_STAGE removal, as gd->fdt_blob no longer
points to a valid DTB. OF_BOARD is supposed to replace OF_PRIOR_STAGE,
hence we need to add the OF_BOARD logic in board_fdt_blob_setup().

[1] 
https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot

Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
Fixes: d6f8ab30a2af ("treewide: Remove OF_PRIOR_STAGE")
Signed-off-by: Bin Meng 
---

 board/sifive/unleashed/unleashed.c | 2 +-
 board/sifive/unmatched/unmatched.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/sifive/unleashed/unleashed.c 
b/board/sifive/unleashed/unleashed.c
index 3c3e0e1d0d..f8aad862c6 100644
--- a/board/sifive/unleashed/unleashed.c
+++ b/board/sifive/unleashed/unleashed.c
@@ -117,7 +117,7 @@ int misc_init_r(void)
 void *board_fdt_blob_setup(int *err)
 {
*err = 0;
-   if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
+   if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
if (gd->arch.firmware_fdt_addr)
return (ulong *)(uintptr_t)gd->arch.firmware_fdt_addr;
}
diff --git a/board/sifive/unmatched/unmatched.c 
b/board/sifive/unmatched/unmatched.c
index 4895909f8d..6295deeae2 100644
--- a/board/sifive/unmatched/unmatched.c
+++ b/board/sifive/unmatched/unmatched.c
@@ -14,7 +14,7 @@
 void *board_fdt_blob_setup(int *err)
 {
*err = 0;
-   if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
+   if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
if (gd->arch.firmware_fdt_addr)
return (ulong *)(uintptr_t)gd->arch.firmware_fdt_addr;
}
-- 
2.25.1



Re: [PATCH v3 1/2] nvme: Enable FUA

2021-11-18 Thread Bin Meng
Hi Tom,

On Fri, Nov 19, 2021 at 3:14 AM Tom Rini  wrote:
>
> On Tue, Oct 19, 2021 at 10:40:53AM +0800, Jon Lin wrote:
>
> > Most NVME devcies maintain data in internal cache for an uncertain
> > times, and u-boot has no method to force NVME to flush cache.
> > So this patch adds FUA to avoid data loss caused by power off after data
> > programming.
> >
> > Signed-off-by: Jon Lin 
> > Reviewed-by: Stefan Agner 
>
> Applied to u-boot/next, thanks!

I don't see my review comment being addressed. Please drop the patch
until all things are clear.

Regards,
Bin


Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-11 Thread Bin Meng
On Thu, Nov 11, 2021 at 9:17 PM  wrote:
>
> > I agree with Bin here. You shouldn't introduce a new compatible just for
> > u-boot. If you need one, please to it first in linux and get an ACK there.
> > Or at least there should be patches for it pending in linux and it should
> > be likely, that they will be accepted.
> >
> > Please work towards having one binding for u-boot and linux.
> >
> > -michael
>
> I think both Michael and Bin are right, but that maybe this has gone circular.
>
> IIRC, Linux *doesn't need* any extra bindings because its driver already
> supports 64-bit DMA.
>
> Padmarao's original patch added equivalent 64-bit functionality to the
> driver in U-Boot, but this was rejected.
>

I am not sure why it was rejected. Is that because it breaks some
other platforms?

> Instead I think the suggestion was to add a device-tree binding to choose 32 
> or
> 64-bit DMA...  however, there is no reasonably way of upstreaming this into
> the Linux device-tree, as Linux doesn't need it... so he is left in a 
> Catch-22.
>
> A way forward may be to go back to his original approach and get the U-Boot
> driver functionality updated so that it works similarly to the Linux driver
> (and thus can use the same device-tree stanza)?

Let's go back to the original approach and see what happens.

Regards,
Bin


Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-11 Thread Bin Meng
Hi Padmarao,

On Thu, Nov 11, 2021 at 2:11 PM  wrote:
>
> Hi Bin,
>
>
>
> Do we need to upstream Linux kernel bindings for Microchip MACB compatible if 
> there is no change in Linux MACB driver?
>
> Are the Linux maintainers can approve this? Because the changes only in 
> U-Boot not Linux.
>

If Linux driver does not need to be updated to support MPFS macb using
existing compatible string but U-Boot driver has to, something is
wrong on the U-Boot macb driver side.

Would you please reconsider the whole changes?

Regards,
Bin


Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-02 Thread Bin Meng
Hi Padmarao,

On Tue, Nov 2, 2021 at 7:03 PM Padmarao Begari  wrote:
>
> Hi Bin,
>
> On Mon, Nov 1, 2021 at 2:15 PM Bin Meng  wrote:
>>
>> On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
>>  wrote:
>> >
>> > Update compatible as per Microchip PolarFire SoC ethernet
>> > device node.
>> >
>> > Signed-off-by: Padmarao Begari 
>> > ---
>> >  drivers/net/macb.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> > index 8c6461e717..1b867bd5c2 100644
>> > --- a/drivers/net/macb.c
>> > +++ b/drivers/net/macb.c
>> > @@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
>> > { .compatible = "cdns,zynq-gem" },
>> > { .compatible = "sifive,fu540-c000-gem",
>> >   .data = (ulong)_config },
>> > -   { .compatible = "microchip,mpfs-mss-gem",
>> > +   { .compatible = "microchip,mpfs-gem",
>>
>> Could you please provide the upstream Linux kernel binding reference?
>> I can't find such string in the Linux kernel.
>>
>
> We are not upstreamed Linux bindings yet, soon we will do.
>
> The compatible "cdns,macb" is used in Linux for 32-bit and 64-bit DMA 
> transfer and U-Boot for 32-bit DMA transfer.
> We added this string to support 64-bit DMA transfer of the GEM.
>

I suggest we upstream the new compatible string binding first, then
update U-Boot. Otherwise U-Boot might be updated again if the
compatible string is changed during the upstream review process.

Regards,
Bin


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-11-01 Thread Bin Meng
Hi Rick,

On Mon, Oct 25, 2021 at 10:24 AM Rick Chen  wrote:
>
> Hi, Bin
>
> > Hi Rick,
> >
> > On Mon, Oct 25, 2021 at 9:49 AM Rick Chen  wrote:
> > >
> > > Hi Bin,
> > >
> > > > From: Bin Meng 
> > > > Sent: Tuesday, October 19, 2021 4:55 PM
> > > > To: Alexandre Ghiti 
> > > > Cc: Heinrich Schuchardt ; Tom Rini 
> > > > ; Leo Yu-Chi Liang(梁育齊) ; 
> > > > Rick Jian-Zhi Chen(陳建志) ; Pragnesh Patel 
> > > > ; Dimitri John Ledkov 
> > > > ; Zong Li ; Green Wan 
> > > > ; U-Boot Mailing List 
> > > > Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge 
> > > > CONFIG_SYS_SPL_MALLOC_SIZE
> > > >
> > > > On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti 
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng  wrote:
> > > > > >
> > > > > > Hi Heinrich,
> > > > > >
> > > > > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
> > > > > >  wrote:
> > > > > > >
> > > > > > > Avoid an error like
> > > > > > >
> > > > > > > Could not get FIT buffer of 1725952 bytes
> > > > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > > > > No device tree specified in SPL image
> > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > >
> > > > > > > Signed-off-by: Heinrich Schuchardt
> > > > > > > 
> > > > > > > ---
> > > > > > >  include/configs/sifive-unmatched.h | 2 +-
> > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/include/configs/sifive-unmatched.h
> > > > > > > b/include/configs/sifive-unmatched.h
> > > > > > > index f8ad2cce1f..8d3deabdd3 100644
> > > > > > > --- a/include/configs/sifive-unmatched.h
> > > > > > > +++ b/include/configs/sifive-unmatched.h
> > > > > > > @@ -18,7 +18,7 @@
> > > > > > >  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
> > > > > > >  #define CONFIG_SYS_SPL_MALLOC_START
> > > > > > > (CONFIG_SPL_BSS_START_ADDR + \
> > > > > > >  CONFIG_SPL_BSS_MAX_SIZE)
> > > > > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> > > > > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020
> > > > > > >
> > > > > > >  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
> > > > > > >  GENERATED_GBL_DATA_SIZE)
> > > > > >
> > > > > > What caused this?
> > > > > >
> > > > > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN
> > > > > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error
> > > > > > messages point to
> > > > > >
> > > > > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html
> > > > > >
> > > > >
> > > > > I fell into the same issue this morning and increasing
> > > > > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even
> > > > > more than Heinrich.
> > > >
> > > > Is this default build that caused Unmatched boot failure?
> > > >
> > > > @Rick Chen  can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was 
> > > > needed on AE350?
> > >
> > > It is needed for limited memory cases on AE350 platforms.
> >
> > But the error message indicates that CONFIG_SYS_SPL_MALLOC_SIZE should
> > be increased, which is what this patch doing.
> >
> > Why is CONFIG_SYS_SPL_MALLOC_SIZE not working on AE350?
>
> I review why I increase SPL_SYS_MALLOC_F_LEN and recall that it will
> report memory size problem in spl_get_fit_load_buffer() of spl_fit.c.
> But Increase CONFIG_SYS_SPL_MALLOC_SIZE is helpful for boards with
> CONFIG_SYS_SPL_MALLOC_SIZE definition,
> On Ae350 it is not define SYS_SPL_MALLOC_SIZE, so I increase
> SPL_SYS_MALLOC_F_LEN instead.
>

Thanks. So this suggests we should fix the message in
spl_get_fit_load_buffer() to provide different hints for different
configurations?

Regards,
Bin


Re: [PATCH v1 5/5] doc: board: Update Microchip MPFS Icicle Kit doc

2021-11-01 Thread Bin Meng
On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
 wrote:
>
> UART1 uses for U-BOOT and Linux console instead of UART0 and

nits: s/U-BOOT/U-Boot

> UART0 is reserved for Hart Software Services(HSS).
>
> Signed-off-by: Padmarao Begari 
> ---
>  doc/board/microchip/mpfs_icicle.rst | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/doc/board/microchip/mpfs_icicle.rst 
> b/doc/board/microchip/mpfs_icicle.rst
> index c71c2f3cab..d7af542c0e 100644
> --- a/doc/board/microchip/mpfs_icicle.rst
> +++ b/doc/board/microchip/mpfs_icicle.rst
> @@ -18,8 +18,9 @@ The support for following drivers are already enabled:
>
>  1. NS16550 UART Driver.
>  2. Microchip Clock Driver.
> -3. Cadence MACB ethernet driver for networking support.
> -4. Cadence MMC Driver for eMMC/SD support.
> +3. Microchip I2C Driver.

nits: can we just insert this after the existing entries?

> +4. Cadence MACB ethernet driver for networking support.
> +5. Cadence MMC Driver for eMMC/SD support.
>
>  Booting from eMMC using HSS
>  ---
> @@ -214,7 +215,8 @@ GPT partition.
>  Booting
>  ~~~
>
> -You should see the U-Boot prompt on UART0.
> +You should see the U-Boot prompt on UART1.
> +(Note: UART0 is reserved for HSS)
>
>  Sample boot log from MPFS Icicle Kit
>  
> @@ -451,7 +453,8 @@ copied payload and Linux image.
>
>  sudo dd if= of=/dev/sdX2 bs=512
>
> -You should see the U-Boot prompt on UART0.
> +You should see the U-Boot prompt on UART1.
> +(Note: UART0 is reserved for HSS)
>
>  GUID type
>  ~

Otherwise,
Reviewed-by: Bin Meng 

Regards,
Bin


Re: [PATCH v1 4/5] net: macb: Compatible as per device tree

2021-11-01 Thread Bin Meng
On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
 wrote:
>
> Update compatible as per Microchip PolarFire SoC ethernet
> device node.
>
> Signed-off-by: Padmarao Begari 
> ---
>  drivers/net/macb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 8c6461e717..1b867bd5c2 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
> { .compatible = "cdns,zynq-gem" },
> { .compatible = "sifive,fu540-c000-gem",
>   .data = (ulong)_config },
> -   { .compatible = "microchip,mpfs-mss-gem",
> +   { .compatible = "microchip,mpfs-gem",

Could you please provide the upstream Linux kernel binding reference?
I can't find such string in the Linux kernel.

>   .data = (ulong)_config },
> { }
>  };

Regards,
Bin


Re: [PATCH v1 2/5] riscv: Update Microchip MPFS Icicle Kit support

2021-11-01 Thread Bin Meng
On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
 wrote:
>
> This patch updates Microchip MPFS Icicle Kit support. For now,
> add Microchip I2C driver, set environment variables for
> mac addesses and default build for SBI_V02.
>
> Signed-off-by: Padmarao Begari 
> ---
>  board/microchip/mpfs_icicle/Kconfig   |  5 +
>  board/microchip/mpfs_icicle/mpfs_icicle.c | 17 -
>  configs/microchip_mpfs_icicle_defconfig   |  1 -
>  3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/board/microchip/mpfs_icicle/Kconfig 
> b/board/microchip/mpfs_icicle/Kconfig
> index 4678462378..092e411215 100644
> --- a/board/microchip/mpfs_icicle/Kconfig
> +++ b/board/microchip/mpfs_icicle/Kconfig
> @@ -45,5 +45,10 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply MMC_WRITE
> imply MMC_SDHCI
> imply MMC_SDHCI_CADENCE
> +   imply MMC_SDHCI_ADMA
> +   imply MMC_HS200_SUPPORT
> +   imply CMD_I2C
> +   imply DM_I2C
> +   imply SYS_I2C_MICROCHIP
>
>  endif
> diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c 
> b/board/microchip/mpfs_icicle/mpfs_icicle.c
> index afef719dff..e74c9fb03c 100644
> --- a/board/microchip/mpfs_icicle/mpfs_icicle.c
> +++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
> @@ -119,7 +119,22 @@ int board_late_init(void)
> if (icicle_mac_addr[idx] == ':')
> icicle_mac_addr[idx] = ' ';
> }
> -   env_set("icicle_mac_addr", icicle_mac_addr);
> +   env_set("icicle_mac_addr0", icicle_mac_addr);

What's this environment for? Shouldn't the U-Boot standard environment
variable "ethaddr" be set here?

> +
> +   mac_addr[5] = device_serial_number[0] + 1;
> +
> +   icicle_mac_addr[0] = '[';
> +
> +   sprintf(_mac_addr[1], "%pM", mac_addr);

"eth1addr"?

> +
> +   icicle_mac_addr[18] = ']';
> +   icicle_mac_addr[19] = '\0';
> +
> +   for (idx = 0; idx < 20; idx++) {
> +   if (icicle_mac_addr[idx] == ':')
> +   icicle_mac_addr[idx] = ' ';
> +   }
> +   env_set("icicle_mac_addr1", icicle_mac_addr);
>
> return 0;
>  }
> diff --git a/configs/microchip_mpfs_icicle_defconfig 
> b/configs/microchip_mpfs_icicle_defconfig
> index 90ae76cc12..b3c7e6db8f 100644
> --- a/configs/microchip_mpfs_icicle_defconfig
> +++ b/configs/microchip_mpfs_icicle_defconfig
> @@ -6,7 +6,6 @@ CONFIG_DEFAULT_DEVICE_TREE="microchip-mpfs-icicle-kit"
>  CONFIG_TARGET_MICROCHIP_ICICLE=y
>  CONFIG_ARCH_RV64I=y
>  CONFIG_RISCV_SMODE=y
> -CONFIG_SBI_V01=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_SYS_LOAD_ADDR=0x8020
>  CONFIG_FIT=y
> --

Regards,
Bin


Re: [PATCH v1 1/5] riscv: dts: Split Microchip device tree

2021-11-01 Thread Bin Meng
Hi Padmarao,

On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
 wrote:
>
> The device tree split into .dtsi and .dts files, common
> device node for eMMC/SD, enable I2C1, UART1 for console
> instead of UART0, enable the DDR 2GB memory and in
> that 288MB memory is reserved for fabric buffer.
>
> Signed-off-by: Padmarao Begari 
> ---
>  arch/riscv/dts/microchip-mpfs-icicle-kit.dts  | 518 
>  arch/riscv/dts/microchip-mpfs.dtsi| 571 ++
>  .../microchip-mpfs-plic.h | 195 ++
>  .../interrupt-controller/riscv-hart.h |  18 +
>  4 files changed, 913 insertions(+), 389 deletions(-)
>  create mode 100644 arch/riscv/dts/microchip-mpfs.dtsi
>  create mode 100644 
> include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h
>  create mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h

Are these files sync'ed from upstream Linux kernel?

>

[snip]

Regards,
Bin


Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED

2021-11-01 Thread Bin Meng
Hi Leo,

On Mon, Nov 1, 2021 at 3:49 PM Leo Liang  wrote:
>
> Hi Bin,
> On Mon, Nov 01, 2021 at 02:04:48PM +0800, Bin Meng wrote:
> > Hi Leo,
> >
> > On Wed, Oct 27, 2021 at 4:59 PM Leo Yu-Chi Liang  
> > wrote:
> > >
> > > According to ./include/linux/kconfig.h,
> > > CONFIG_IS_ENABLED(OF_BOARD) expands to 0
> > > when CONFIG_SPL_BUILD is defined because
> > > there is no CONFIG_SPL_OF_BOARD.
> >
> > Why is the change?
> >
>
> The original code was
>
> void *board_fdt_blob_setup(void)
> {
> #if CONFIG_IS_ENABLED(OF_BOARD)
> return (void *)(ulong)gd->arch.firmware_fdt_addr;
> #elif CONFIG_IS_ENABLED(OF_SEPARATE)
> return (void *)CONFIG_SYS_FDT_BASE;
> #else
> return NULL;
> }
>
> But the "return (void *)(ulong)gd->arch.firmware_fdt_addr;" does not get
> compiled even if OF_BOARD is selected when building
> ae350_*_spl_*_defconfig, thus this patch.
>
> The reason is because ./include/linux/kconfig.h states
> "CONFIG_IS_ENABLED(FOO) expands to 1 if CONFIG_SPL_BUILD is defined
> and CONFIG_SPL_FOO is set to 'y'".
> However, we don't have CONFIG_SPL_OF_BOARD, so
> CONFIG_IS_ENABLED(OF_BOARD) only expands to 0.
>

Thanks!

Please add:

Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
Reviewed-by: Bin Meng 

Regards,
Bin


[PATCH v2 3/3] net: tsec: Make redundant_init() static

2021-11-01 Thread Bin Meng
redundant_init() is only called in the tsec driver. Make it static.

Signed-off-by: Bin Meng 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Ramon Fried 

---

(no changes since v1)

 drivers/net/tsec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 4354753cab..3dd00a4a40 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -443,7 +443,7 @@ static void tsec_halt(struct udevice *dev)
  * of the eTSEC port initialization sequence,
  * the eTSEC Rx logic may not be properly initialized.
  */
-void redundant_init(struct tsec_private *priv)
+static void redundant_init(struct tsec_private *priv)
 {
struct tsec __iomem *regs = priv->regs;
uint t, count = 0;
-- 
2.25.1



[PATCH v2 2/3] net: fec_mxc: Declare 'promisc' as bool

2021-11-01 Thread Bin Meng
priv->promisc is used as the parameter of the set_promisc() call
which accepts a bool type instead of char.

Signed-off-by: Bin Meng 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Ramon Fried 
---

(no changes since v1)

 drivers/net/fec_mxc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 1c0d0e5b8f..48faa33d66 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -272,7 +272,7 @@ struct fec_priv {
struct clk clk_ref;
struct clk clk_ptp;
u32 clk_rate;
-   char promisc;
+   bool promisc;
 };
 
 /**
-- 
2.25.1



[PATCH v2 1/3] net: dsa: Use true instead of 1 in the set_promisc() call

2021-11-01 Thread Bin Meng
set_promisc() call accepts the parameter of a bool type. Make it
clear by using true instead of 1.

Signed-off-by: Bin Meng 
Reviewed-by: Vladimir Oltean 
Reviewed-by: Ramon Fried 

---

Changes in v2:
- rebase on u-boot-net/next

 net/dsa-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 7a465b1099..606b1539a7 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -270,7 +270,7 @@ static void dsa_port_set_hwaddr(struct udevice *pdev, 
struct udevice *master)
struct eth_ops *eth_ops = eth_get_ops(master);
 
if (eth_ops->set_promisc)
-   eth_ops->set_promisc(master, 1);
+   eth_ops->set_promisc(master, true);
 
return;
}
-- 
2.25.1



Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED

2021-11-01 Thread Bin Meng
Hi Leo,

On Wed, Oct 27, 2021 at 4:59 PM Leo Yu-Chi Liang  wrote:
>
> According to ./include/linux/kconfig.h,
> CONFIG_IS_ENABLED(OF_BOARD) expands to 0
> when CONFIG_SPL_BUILD is defined because
> there is no CONFIG_SPL_OF_BOARD.

Why is the change?

>
> Use #if defined instead.
>
> Signed-off-by: Leo Yu-Chi Liang 
> ---
>  board/AndesTech/ax25-ae350/ax25-ae350.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Regards,
Bin


Please pull u-boot-x86

2021-10-31 Thread Bin Meng
Hi Tom,

This PR includes the following x86 changes for v2022.01:

- Fixes for x86 build with Clang/LLVM compiler
- Tangier ACPI changes
- Edison SD card detect pin fix
- EFI on x86 doc update with latest instructions
- PXE utility fixes to align with latest x86 zboot implementation

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=462=results

The following changes since commit 360e392274e3bfeda3b7226d2cac7514774d0da1:

  Merge tag 'dm-pull-boo21' of
https://source.denx.de/u-boot/custodians/u-boot-dm (2021-10-31
15:48:43 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to 5270bee9b27cf63251696916e4b5a5d4412d3a2d:

  x86: tangier: pinmux: Move error message to the caller (2021-11-01
10:19:05 +0800)


Alistair Delva (2):
  x86: chromebook_coral: fix C block comment
  x86: Fix i8254 ifdef include guard

Andy Shevchenko (5):
  x86: tangier: Replace Method() by Name() for _STA object
  x86: tangier: Enable support for SD/SDIO family in the pinmux driver
  x86: edison: Don't take SD card detect pin into consideration
  x86: tangier: pinmux: Move is_protected assignment closer to its user
  x86: tangier: pinmux: Move error message to the caller

Bin Meng (1):
  docs: uefi: Update stale U-Boot on EFI doc

Zhaofeng Li (2):
  pxe_utils: Fix arguments to x86 zboot
  pxe_utils: Clean up {bootm,zboot}_argv generation

 arch/x86/cpu/tangier/pinmux.c   | 48

 arch/x86/dts/chromebook_coral.dts   |  1 +
 arch/x86/dts/edison.dts | 17 +
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 81
+
 arch/x86/include/asm/i8254.h|  4 ++--
 cmd/pxe_utils.c | 45
-
 doc/develop/uefi/u-boot_on_efi.rst  | 12 +++-
 7 files changed, 112 insertions(+), 96 deletions(-)

Regards,
Bin


Re: [PATCH] Azure: Move to windows-2019

2021-10-31 Thread Bin Meng
On Mon, Nov 1, 2021 at 1:25 AM Tom Rini  wrote:
>
> As per https://github.com/actions/virtual-environments/issues/4312 the
> Windows-2016 environments are scheduled for deprecation and removal in
> early 2022.  Move to windows-2019 now to avoid this (Visual Studio 2019
> is included here, hence the tag naming scheme change).
>
> Signed-off-by: Tom Rini 
> ---
>  .azure-pipelines.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 2/2] x86: tangier: pinmux: Move error message to the caller

2021-10-31 Thread Bin Meng
On Mon, Nov 1, 2021 at 10:18 AM Bin Meng  wrote:
>
> On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
>  wrote:
> >
> > Move error message to the caller of mrfld_pinconfig*() in order
> > to unify them in the future.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/pinmux.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 2/2] x86: tangier: pinmux: Move error message to the caller

2021-10-31 Thread Bin Meng
On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
 wrote:
>
> Move error message to the caller of mrfld_pinconfig*() in order
> to unify them in the future.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/pinmux.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 1/2] x86: tangier: pinmux: Move is_protected assignment closer to its user

2021-10-31 Thread Bin Meng
On Mon, Nov 1, 2021 at 10:05 AM Bin Meng  wrote:
>
> On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
>  wrote:
> >
> > Move is_protected assignment closer to its user.
> > This increases readability and makes maintenance easier.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/pinmux.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 1/2] x86: tangier: pinmux: Move is_protected assignment closer to its user

2021-10-31 Thread Bin Meng
On Wed, Oct 27, 2021 at 10:23 PM Andy Shevchenko
 wrote:
>
> Move is_protected assignment closer to its user.
> This increases readability and makes maintenance easier.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/pinmux.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call

2021-10-30 Thread Bin Meng
Hi Ramon,

On Sat, Oct 30, 2021 at 9:31 PM Ramon Fried  wrote:
>
> On Thu, Oct 28, 2021 at 10:29 PM Vladimir Oltean
>  wrote:
> >
> > On Thu, Oct 28, 2021 at 09:41:02PM +0300, Ramon Fried wrote:
> > > Bin, patches don't apply cleanly.  can you rebase ?
> > >
> > > On Thu, Oct 28, 2021 at 7:53 AM Ramon Fried  wrote:
> > > >
> > > > On Wed, Oct 27, 2021 at 5:19 AM Bin Meng  wrote:
> > > > >
> > > > > On Sun, Oct 17, 2021 at 2:26 AM Ramon Fried  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Sep 29, 2021 at 4:32 PM Vladimir Oltean 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Wed, Sep 29, 2021 at 01:50:44PM +0800, Bin Meng wrote:
> > > > > > > > set_promisc() call accepts the parameter of a bool type. Make it
> > > > > > > > clear by using true instead of 1.
> > > > > > > >
> > > > > > > > Signed-off-by: Bin Meng 
> > > > > > > > ---
> > > > > > > >
> > > > > > > >  net/dsa-uclass.c | 2 +-
> > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> > > > > > > > index 694664d81b..dcefec03f4 100644
> > > > > > > > --- a/net/dsa-uclass.c
> > > > > > > > +++ b/net/dsa-uclass.c
> > > > > > > > @@ -282,7 +282,7 @@ static int dsa_port_probe(struct udevice 
> > > > > > > > *pdev)
> > > > > > > >   struct eth_ops *eth_ops = eth_get_ops(master);
> > > > > > > >
> > > > > > > >   if (eth_ops->set_promisc)
> > > > > > > > - eth_ops->set_promisc(master, 1);
> > > > > > > > + eth_ops->set_promisc(master, true);
> > > > > > > >
> > > > > > > >   return 0;
> > > > > > > >   }
> > > > > > > > --
> > > > > > > > 2.25.1
> > > > > > > >
> > > > > > >
> > > > > > > Reviewed-by: Vladimir Oltean 
> > > > > > Reviewed-by: Ramon Fried 
> > > > >
> > > > > Ping for apply?
> > > > I'll get to the patches today.
> > > > thanks for waking me up :)
> >
> > Why don't you apply patches immediately after reviewing them?
> It wouldn't make a difference. you were all working on the same file
> in code, If I would have applied bin's patches before yours, then you
> would need to rebase.
> simple as that. Also the time when I'm applying and when I'm reviewing
> is also meaningless because this problem would occur anyway.

Please let me know which branch I should rebase on, so that I can send v2.

Regards,
Bin


Re: an off-by-one error in dm_test_rtc_set_get()?

2021-10-27 Thread Bin Meng
On Wed, Oct 27, 2021 at 9:22 PM Tom Rini  wrote:
>
> On Wed, Oct 27, 2021 at 12:43:38PM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > gitlab reported the following test error below:
> >
> > === FAILURES 
> > ===
> > __ test_ut[ut_dm_rtc_set_get] 
> > __
> > test/py/tests/test_ut.py:43: in test_ut
> > assert output.endswith('Failures: 0')
> > E AssertionError: assert False
> > E + where False =  > 0x7f3bb792dcb0>('Failures: 0')
> > E + where  =
> > 'Test: dm_test_rtc_set_get: rtc.c\r\r\nexpected: 27/10/2021
> > 03:38:15\r\r\nactual: 27/10/2021 03:38:14\r\r\ntest/dm/rtc...w, ,
> > 1): Expected 0x0 (0), got 0xffea (-22)\r\r\nTest:
> > dm_test_rtc_set_get: rtc.c (flat tree)\r\r\nFailures: 1'.endswith
> > - Captured stdout call 
> > -
> > =>
> >
> > See https://source.denx.de/u-boot/custodians/u-boot-x86/-/jobs/341905
> >
> > But the same branch same commit, azure test results passed:
> > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=460=results
> >
> > It looks like the error is an off-by-one where actual time is 1 second
> > behind the expected time?
> >
> > expected: 27/10/2021 03:38:15
> > actual: 27/10/2021 03:38:14
> >
> > Is this a known issue?
>
> Yes, which is why the test checks for a certain amount of "fuzz" around
> the return value.  I've wondered about if we need to increase that value
> slightly sometimes, or just live with hitting the re-run failed jobs
> button on whatever CI system was a bit too slow sometimes.
>

Thanks Tom. So it is a known issue. It's just my first time seeing
this failure in CI :)

Regards,
Bin


Re: [PATCH] Fix syntax error

2021-10-27 Thread Bin Meng
On Wed, Oct 27, 2021 at 5:01 PM Leo Yu-Chi Liang  wrote:
>
> This statement has an unmatched parentheses, fix it.
>
> Signed-off-by: Leo Yu-Chi Liang 
> ---
>  common/image-board.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v3 1/2] nvme: Enable FUA

2021-10-27 Thread Bin Meng
Hi Jon,

On Tue, Oct 19, 2021 at 10:41 AM Jon Lin  wrote:
>
> Most NVME devcies maintain data in internal cache for an uncertain
> times, and u-boot has no method to force NVME to flush cache.
> So this patch adds FUA to avoid data loss caused by power off after data
> programming.
>
> Signed-off-by: Jon Lin 
> Reviewed-by: Stefan Agner 
> ---
>
> Changes in v3:
>   Only enable FUA when vwc is enabled
>
>  drivers/nvme/nvme.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 3c529a2fce..9623c896a1 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -762,6 +762,10 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t 
> blknr,
> c.rw.appmask = 0;
> c.rw.metadata = 0;
>
> +   /* Enable FUA for data integrity if vwc is enabled */
> +   if (dev->vwc)

Still this does not look correct to me.

The dev->vwc field only indicates the presence of the Volatile Write
Cache, but not the enable status of it.

> +   c.rw.control |= NVME_RW_FUA;
> +
> while (total_lbas) {
> if (total_lbas < lbas) {
> lbas = (u16)total_lbas;

Regards,
Bin


Re: [PATCH v2 2/2] x86: edison: Don't take SD card detect pin into consideration

2021-10-27 Thread Bin Meng
On Wed, Oct 27, 2021 at 7:28 PM Andy Shevchenko
 wrote:
>
> There are two PCB designs in the wild which use the opposite
> signaling for SD card detection. This makes U-Boot working
> in one case and failing in the other. Quirk this out by
> disconnecting SD card detection pin from the PCB by switching
> it to mode 3. In the disconnected state the read value is always
> the same and inverted to what we are expecting in the code.
>
> BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Bin Meng 
> ---
> v2: added tag, updated commit message and comments in DTS (Bin)
>  arch/x86/dts/edison.dts | 17 +
>  1 file changed, 17 insertions(+)
>

applied to u-boot-x86, thanks!


Re: [PATCH v2 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver

2021-10-27 Thread Bin Meng
On Wed, Oct 27, 2021 at 7:28 PM Andy Shevchenko
 wrote:
>
> We would need to quirk out the Card Detect case and for that we allow
> configuring the SD/SDIO family of pins.
>
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Bin Meng 
> ---
> v2: added tag, promised to deduplicate the code in the future (Bin)
>  arch/x86/cpu/tangier/pinmux.c | 39 ++-
>  1 file changed, 34 insertions(+), 5 deletions(-)
>

applied to u-boot-x86, thanks!


Re: [PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver

2021-10-27 Thread Bin Meng
On Wed, Oct 27, 2021 at 4:54 PM Andy Shevchenko
 wrote:
>
> On Wed, Oct 27, 2021 at 5:49 AM Bin Meng  wrote:
> > On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
> >  wrote:
> > >
> > > We would need to quirk out Card Detect case and for that we allow
> > > configuring SD/SDIO family of pins.
>
> ...
>
> > > +static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
> > > +{
>
> > This function can be consolidated with mrfld_pinconfig_protected(),
> > ie: updating mrfld_pinconfig_protected() to call mrfld_pinconfig().
>
> Can it be done in a separate patch? This is a fix related and tested,
> it will take time to retest this by all parties.
>

Sure please send a follow-up patch when you are free.

Reviewed-by: Bin Meng 

Regards,
Bin


Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration

2021-10-27 Thread Bin Meng
On Wed, Oct 27, 2021 at 4:52 PM Andy Shevchenko
 wrote:
>
> On Wed, Oct 27, 2021 at 5:57 AM Bin Meng  wrote:
> > On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
> >  wrote:
> > >
> > > There are two PCB designs in the wild which use the opposite
> > > signaling for SD card detect. This makes U-Boot working in one case
> > > and failing in the other. Quirk this out by disconnecting SD card
> > > detect pin from the PCB by switching to mode 3.
> > >
> > > BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
>
> ...
>
> > > sdcard: mmc@ff3fa000 {
> > > compatible = "intel,sdhci-tangier";
> > > reg = <0xff3fa000 0x1000>;
> > > +   cd-inverted;
> >
> > So I wonder how sd card ever worked without the "cd-inverted" property?
>
> TL;DR: it worked on one PCB design and did not work on the other. When
> we disconnect the pin the read value is always the same and inverted
> to what we expected in the code.

Great. That explains. Although I read the below comments a couple of
times, it just did not come to my head that "when we disconnect the
pin the read value is always the same and inverted to what we expected
in the code."

>
> Have you read the commit message and the comment below? Have you read
> the bug report?

Yes, but it's not crystal clear hence the ask. So maybe we can update
the comments to make such clearer?

>
> > > +   /*
> > > +* Disconnect SD card detect, so it won't affect the 
> > > reality
> > > +* on two different PCB designs where it's using the 
> > > opposite
> > > +* signaling: Edison/Arduino uses Active Low, while 
> > > SparkFun
> > > +* went with Active High.
> > > +*/

FWIW,
Reviewed-by: Bin Meng 

Regards,
Bin


an off-by-one error in dm_test_rtc_set_get()?

2021-10-26 Thread Bin Meng
Hi Simon,

gitlab reported the following test error below:

=== FAILURES ===
__ test_ut[ut_dm_rtc_set_get] __
test/py/tests/test_ut.py:43: in test_ut
assert output.endswith('Failures: 0')
E AssertionError: assert False
E + where False = ('Failures: 0')
E + where  =
'Test: dm_test_rtc_set_get: rtc.c\r\r\nexpected: 27/10/2021
03:38:15\r\r\nactual: 27/10/2021 03:38:14\r\r\ntest/dm/rtc...w, ,
1): Expected 0x0 (0), got 0xffea (-22)\r\r\nTest:
dm_test_rtc_set_get: rtc.c (flat tree)\r\r\nFailures: 1'.endswith
- Captured stdout call -
=>

See https://source.denx.de/u-boot/custodians/u-boot-x86/-/jobs/341905

But the same branch same commit, azure test results passed:
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=460=results

It looks like the error is an off-by-one where actual time is 1 second
behind the expected time?

expected: 27/10/2021 03:38:15
actual: 27/10/2021 03:38:14

Is this a known issue?

Regards,
Bin


Re: [PATCH v2] usb: xhci-brcm: Include header file needed for dev_err

2021-10-26 Thread Bin Meng
On Wed, Oct 6, 2021 at 8:05 PM Stefan Agner  wrote:
>
> dev_err seems to be moved to different header file. Include
> dm/device_compat.h file to compile properly.
>
> Fixes: 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
> Signed-off-by: Stefan Agner 
> ---
>
> Changes in v2:
> - Correctly place include
>

Reviewed-by: Bin Meng 


Re: [PATCH] x86: Fix i8254 ifdef include guard

2021-10-26 Thread Bin Meng
On Wed, Oct 27, 2021 at 11:08 AM Bin Meng  wrote:
>
> On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva  wrote:
> >
> > When building U-Boot with clang, it notices that the i8254.h include
> > guard does not work correctly due to a typo. Fix it.
> >
> > Signed-off-by: Alistair Delva 
> > Cc: Simon Glass 
> > Cc: Bin Meng 
> > ---
> >  arch/x86/include/asm/i8254.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h
> > index d769daf85d..bb8930338b 100644
> > --- a/arch/x86/include/asm/i8254.h
> > +++ b/arch/x86/include/asm/i8254.h
> > @@ -7,7 +7,7 @@
> >  /* i8254.h Intel 8254 PIT registers */
> >
> >  #ifndef _ASMI386_I8254_H_
> > -#define _ASMI386_I8954_H_
> > +#define _ASMI386_I8254_H_
>
> There is another I8954 at the end of this file. I can fix it when applying.
>
> >
> >  #define PIT_T0 0x00/* PIT channel 0 count/status */
> >  #define PIT_T1 0x01/* PIT channel 1 count/status */
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH] x86: chromebook_coral: fix C block comment

2021-10-26 Thread Bin Meng
On Wed, Oct 27, 2021 at 11:07 AM Bin Meng  wrote:
>
> On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva  wrote:
> >
> > Fix a warning seen when compiling this dts file.
> >
> > Signed-off-by: Alistair Delva 
> > Cc: Simon Glass 
> > Cc: Bin Meng 
> > ---
> >  arch/x86/dts/chromebook_coral.dts | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1 1/1] x86: tangier: Replace Method() by Name() for _STA object

2021-10-26 Thread Bin Meng
On Wed, Oct 27, 2021 at 11:05 AM Bin Meng  wrote:
>
> On Wed, Oct 20, 2021 at 8:51 PM Andy Shevchenko
>  wrote:
> >
> > There is no point to use Method() for the constant.
> > Replace it with Name() defined object. For the _STA
> > case it saves 3 bytes per each entry.
> >
> > Before: 2881
> > After: 2833
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  .../asm/arch-tangier/acpi/southcluster.asl| 81 ---
> >  1 file changed, 17 insertions(+), 64 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v2 0/2] pxe_utils: Fix arguments to x86 zboot

2021-10-26 Thread Bin Meng
On Wed, Oct 20, 2021 at 3:18 PM Zhaofeng Li  wrote:
>
> Hi Simon,
>
> Thanks for your review! I have added a second patch to perform the
> cleanup that you mentioned in the review, so the actual "fix" patch
> stays minimal and easy to review.
>
> I agree that calling the bootm and zboot code directly is the real
> solution to go. The current method is inherently error-prone, and
> I wonder how many cases of "kinda works but not really" [1] like
> this are there in U-Boot.
>
> Thanks,
> Zhaofeng Li
>
> [1] Without the patch, the kernel would boot with the U-Boot log
> showing initrd being loaded. However, the kernel wouldn't
> actually get the initrd.
>
> ---
>
> This patch series fixes the issue that incorrect arguments are
> passed to x86 zboot in pxe_utils (pxe/extlinux-like config). See
> the commit message of the first patch for details.
>
> Changes since v1:
> - Added patch to clean up argv generation
>
> Zhaofeng Li (2):
>   pxe_utils: Fix arguments to x86 zboot
>   pxe_utils: Clean up {bootm,zboot}_argv generation
>
>  cmd/pxe_utils.c | 45 -
>  1 file changed, 32 insertions(+), 13 deletions(-)
>

series applied to u-boot-x86, thanks!


Re: [PATCH] x86: Fix i8254 ifdef include guard

2021-10-26 Thread Bin Meng
On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva  wrote:
>
> When building U-Boot with clang, it notices that the i8254.h include
> guard does not work correctly due to a typo. Fix it.
>
> Signed-off-by: Alistair Delva 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  arch/x86/include/asm/i8254.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h
> index d769daf85d..bb8930338b 100644
> --- a/arch/x86/include/asm/i8254.h
> +++ b/arch/x86/include/asm/i8254.h
> @@ -7,7 +7,7 @@
>  /* i8254.h Intel 8254 PIT registers */
>
>  #ifndef _ASMI386_I8254_H_
> -#define _ASMI386_I8954_H_
> +#define _ASMI386_I8254_H_

There is another I8954 at the end of this file. I can fix it when applying.

>
>  #define PIT_T0 0x00/* PIT channel 0 count/status */
>  #define PIT_T1 0x01/* PIT channel 1 count/status */

Reviewed-by: Bin Meng 


Re: [PATCH] x86: chromebook_coral: fix C block comment

2021-10-26 Thread Bin Meng
On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva  wrote:
>
> Fix a warning seen when compiling this dts file.
>
> Signed-off-by: Alistair Delva 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  arch/x86/dts/chromebook_coral.dts | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 1/1] x86: tangier: Replace Method() by Name() for _STA object

2021-10-26 Thread Bin Meng
On Wed, Oct 20, 2021 at 8:51 PM Andy Shevchenko
 wrote:
>
> There is no point to use Method() for the constant.
> Replace it with Name() defined object. For the _STA
> case it saves 3 bytes per each entry.
>
> Before: 2881
> After: 2833
>
> Signed-off-by: Andy Shevchenko 
> ---
>  .../asm/arch-tangier/acpi/southcluster.asl| 81 ---
>  1 file changed, 17 insertions(+), 64 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration

2021-10-26 Thread Bin Meng
Hi Andy,

On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
 wrote:
>
> There are two PCB designs in the wild which use the opposite
> signaling for SD card detect. This makes U-Boot working in one case
> and failing in the other. Quirk this out by disconnecting SD card
> detect pin from the PCB by switching to mode 3.
>
> BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/dts/edison.dts | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
> index 2c8cf6c07102..04e8a4e457c8 100644
> --- a/arch/x86/dts/edison.dts
> +++ b/arch/x86/dts/edison.dts
> @@ -94,6 +94,7 @@
> sdcard: mmc@ff3fa000 {
> compatible = "intel,sdhci-tangier";
> reg = <0xff3fa000 0x1000>;
> +   cd-inverted;

So I wonder how sd card ever worked without the "cd-inverted" property?

> };
>
> pmu: power@ff00b000 {
> @@ -131,6 +132,17 @@
> compatible = "intel,pinctrl-tangier";
> reg = <0xff0c 0x8000>;
>
> +   /*
> +* Disconnect SD card detect, so it won't affect the reality
> +* on two different PCB designs where it's using the opposite
> +* signaling: Edison/Arduino uses Active Low, while SparkFun
> +* went with Active High.
> +*/
> +   sd_cd@0 {
> +   pad-offset = <37>;
> +   mode-func = <3>;
> +   };
> +
> /*
>  * Initial configuration came from the firmware.
>  * Which quite likely has been used in the phones, where I2C 
> #8,
> --

Regards,
Bin


Re: [PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver

2021-10-26 Thread Bin Meng
Hi Andy,

On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
 wrote:
>
> We would need to quirk out Card Detect case and for that we allow
> configuring SD/SDIO family of pins.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/pinmux.c | 39 ++-
>  1 file changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c
> index acf97e3af51d..8385167b2b6b 100644
> --- a/arch/x86/cpu/tangier/pinmux.c
> +++ b/arch/x86/cpu/tangier/pinmux.c
> @@ -37,8 +37,9 @@ struct mrfld_family {
> .npins = (e) - (s) + 1, \
> }
>
> -/* Now we only support I2C family of pins */
> +/* Now we only support SD/SDIO and I2C families of pins */
>  static struct mrfld_family mrfld_families[] = {
> +   MRFLD_FAMILY(3, 37, 56),
> MRFLD_FAMILY(7, 101, 114),
>  };
>
> @@ -125,6 +126,34 @@ static int mrfld_pinconfig_protected(unsigned int pin, 
> u32 mask, u32 bits)
> return ret;
>  }
>
> +static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
> +{
> +   struct mrfld_pinctrl *pinctrl;
> +   struct udevice *dev;
> +   void __iomem *bufcfg;
> +   u32 v, value;
> +   int ret;
> +
> +   ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
> +   if (ret)
> +   return ret;
> +
> +   pinctrl = dev_get_priv(dev);
> +
> +   bufcfg = mrfld_get_bufcfg(pinctrl, pin);
> +   if (!bufcfg)
> +   return -EINVAL;
> +
> +   value = readl(bufcfg);
> +   v = (value & ~mask) | (bits & mask);
> +   writel(v, bufcfg);
> +
> +   debug("v: 0x%x p: 0x%x bits: %d, mask: %d bufcfg: 0x%p\n",
> + v, (u32)bufcfg, bits, mask, bufcfg);
> +
> +   return 0;

This function can be consolidated with mrfld_pinconfig_protected(),
ie: updating mrfld_pinconfig_protected() to call mrfld_pinconfig().

> +}
> +
>  static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
>  {
> bool is_protected;
> @@ -133,10 +162,7 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
> u32 mask;
> int ret;
>
> -   /* For now we only support just protected Family of pins */
> is_protected = ofnode_read_bool(pin_node, "protected");
> -   if (!is_protected)
> -   return -ENOTSUPP;
>
> pad_offset = ofnode_read_s32_default(pin_node, "pad-offset", -1);
> if (pad_offset == -1)
> @@ -152,7 +178,10 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
> if (mode & ~mask)
> return -ENOTSUPP;
>
> -   ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
> +   if (is_protected)
> +   ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
> +   else
> +   ret = mrfld_pinconfig(pad_offset, mask, mode);
>
> return ret;
>  }

Regards,
Bin


Re: [PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call

2021-10-26 Thread Bin Meng
On Sun, Oct 17, 2021 at 2:26 AM Ramon Fried  wrote:
>
> On Wed, Sep 29, 2021 at 4:32 PM Vladimir Oltean  
> wrote:
> >
> > On Wed, Sep 29, 2021 at 01:50:44PM +0800, Bin Meng wrote:
> > > set_promisc() call accepts the parameter of a bool type. Make it
> > > clear by using true instead of 1.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  net/dsa-uclass.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> > > index 694664d81b..dcefec03f4 100644
> > > --- a/net/dsa-uclass.c
> > > +++ b/net/dsa-uclass.c
> > > @@ -282,7 +282,7 @@ static int dsa_port_probe(struct udevice *pdev)
> > >   struct eth_ops *eth_ops = eth_get_ops(master);
> > >
> > >   if (eth_ops->set_promisc)
> > > - eth_ops->set_promisc(master, 1);
> > > + eth_ops->set_promisc(master, true);
> > >
> > >   return 0;
> > >   }
> > > --
> > > 2.25.1
> > >
> >
> > Reviewed-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 

Ping for apply?


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-10-24 Thread Bin Meng
Hi Rick,

On Mon, Oct 25, 2021 at 9:49 AM Rick Chen  wrote:
>
> Hi Bin,
>
> > From: Bin Meng 
> > Sent: Tuesday, October 19, 2021 4:55 PM
> > To: Alexandre Ghiti 
> > Cc: Heinrich Schuchardt ; Tom Rini 
> > ; Leo Yu-Chi Liang(梁育齊) ; Rick 
> > Jian-Zhi Chen(陳建志) ; Pragnesh Patel 
> > ; Dimitri John Ledkov 
> > ; Zong Li ; Green Wan 
> > ; U-Boot Mailing List 
> > Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge 
> > CONFIG_SYS_SPL_MALLOC_SIZE
> >
> > On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti 
> >  wrote:
> > >
> > > Hi,
> > >
> > > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng  wrote:
> > > >
> > > > Hi Heinrich,
> > > >
> > > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
> > > >  wrote:
> > > > >
> > > > > Avoid an error like
> > > > >
> > > > > Could not get FIT buffer of 1725952 bytes
> > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > > No device tree specified in SPL image
> > > > > ### ERROR ### Please RESET the board ###
> > > > >
> > > > > Signed-off-by: Heinrich Schuchardt
> > > > > 
> > > > > ---
> > > > >  include/configs/sifive-unmatched.h | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/include/configs/sifive-unmatched.h
> > > > > b/include/configs/sifive-unmatched.h
> > > > > index f8ad2cce1f..8d3deabdd3 100644
> > > > > --- a/include/configs/sifive-unmatched.h
> > > > > +++ b/include/configs/sifive-unmatched.h
> > > > > @@ -18,7 +18,7 @@
> > > > >  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
> > > > >  #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR + \
> > > > >  CONFIG_SPL_BSS_MAX_SIZE)
> > > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> > > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020
> > > > >
> > > > >  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
> > > > >  GENERATED_GBL_DATA_SIZE)
> > > >
> > > > What caused this?
> > > >
> > > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN
> > > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error
> > > > messages point to
> > > >
> > > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html
> > > >
> > >
> > > I fell into the same issue this morning and increasing
> > > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even
> > > more than Heinrich.
> >
> > Is this default build that caused Unmatched boot failure?
> >
> > @Rick Chen  can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was needed 
> > on AE350?
>
> It is needed for limited memory cases on AE350 platforms.

But the error message indicates that CONFIG_SYS_SPL_MALLOC_SIZE should
be increased, which is what this patch doing.

Why is CONFIG_SYS_SPL_MALLOC_SIZE not working on AE350?

Regards,
Bin


Re: [PATCH] riscv: Avoid io read/write cause wrong result

2021-10-19 Thread Bin Meng
On Mon, Oct 18, 2021 at 7:31 PM Nick Hu  wrote:
>
> io read/write may cause wrong result because they may read/write data
> from/to register instead of memory. Add 'volatile' to avoid it.
>
> Signed-off-by: Nick Hu 
> ---
>  arch/riscv/include/asm/io.h | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-10-19 Thread Bin Meng
On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti
 wrote:
>
> Hi,
>
> On Fri, Oct 1, 2021 at 5:35 PM Bin Meng  wrote:
> >
> > Hi Heinrich,
> >
> > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
> >  wrote:
> > >
> > > Avoid an error like
> > >
> > > Could not get FIT buffer of 1725952 bytes
> > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > No device tree specified in SPL image
> > > ### ERROR ### Please RESET the board ###
> > >
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > >  include/configs/sifive-unmatched.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/configs/sifive-unmatched.h 
> > > b/include/configs/sifive-unmatched.h
> > > index f8ad2cce1f..8d3deabdd3 100644
> > > --- a/include/configs/sifive-unmatched.h
> > > +++ b/include/configs/sifive-unmatched.h
> > > @@ -18,7 +18,7 @@
> > >  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
> > >  #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR + \
> > >  CONFIG_SPL_BSS_MAX_SIZE)
> > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020
> > >
> > >  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
> > >  GENERATED_GBL_DATA_SIZE)
> >
> > What caused this?
> >
> > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN was
> > increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error
> > messages point to
> >
> > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html
> >
>
> I fell into the same issue this morning and increasing
> CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even
> more than Heinrich.

Is this default build that caused Unmatched boot failure?

@Rick Chen  can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was
needed on AE350?

Regards,
Bin


Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option

2021-10-12 Thread Bin Meng
Hi Simon,

On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
>
> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> there are only three ways to obtain a devicetree:
>
>- OF_SEPARATE - the normal way, where the devicetree is built and
>   appended to U-Boot
>- OF_EMBED - for development purposes, the devicetree is embedded in
>   the ELF file (also used for EFI)
>- OF_BOARD - the board figures it out on its own
>
> The last one is currently set up so that no devicetree is needed at all
> in the U-Boot tree. Most boards do provide one, but some don't. Some
> don't even provide instructions on how to boot on the board.
>
> The problems with this approach are documented at [1].
>
> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> can obtain its devicetree at runtime, even it is has a devicetree built
> in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> caller may have a better idea about the hardware available in the machine.
> This is the case with a few QEMU boards, for example.
>
> So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> option, available with either OF_SEPARATE or OF_EMBED.
>
> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.

Adding device trees that are never used sounds like a hack to me.

For QEMU, device tree is dynamically generated on the fly based on
command line parameters, and the device tree you put in this series
has various hardcoded  values which normally do not show up
in hand-written dts files.

I am not sure I understand the whole point of this.

>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
>

Regards,
Bin


Re: [PATCH] tools: Stop re-defining -std= when building tools

2021-10-10 Thread Bin Meng
On Mon, Oct 11, 2021 at 3:23 AM Tom Rini  wrote:
>
> While we intentionally set -std=gnu11 for building host tools, and have
> for quite some time, we never dropped -std=gnu99 from tools/Makefile.
> This resulted in passing -std=gnu11 ... -std=gnu99 when building, and
> gnu99 would win.  This in turn would result now in warnings such as:
> tools/mkeficapsule.c:25:15: warning: redefinition of typedef 'u32' is a C11 
> feature [-Wtypedef-redefinition]
> typedef __u32 u32;
>   ^
>
> Signed-off-by: Tom Rini 
> ---
>  tools/Makefile | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 999fd4653166..b45219e2c30c 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -295,8 +295,7 @@ HOST_EXTRACFLAGS += -include 
> $(srctree)/include/compiler.h \
> -I$(srctree)/tools \
> -DUSE_HOSTCC \
> -D__KERNEL_STRICT_NAMES \
> -   -D_GNU_SOURCE \
> -   -std=gnu99
> +   -D_GNU_SOURCE

It looks like std=gnu11 is only added for Linux host.

KBUILD_HOSTCFLAGS += $(CSTD_FLAG)

Should we still keep it for other hosts?

Regards,
Bin


Re: [PATCH 1/9] cache: sifive: Fix -Wint-to-pointer-cast warning

2021-10-10 Thread Bin Meng
On Wed, Sep 15, 2021 at 11:40 AM Leo Liang  wrote:
>
> On Sun, Sep 12, 2021 at 11:15:08AM +0800, Bin Meng wrote:
> > The following warning is seen in cache-sifive-ccache.c in a 32-bit build:
> >
> >   warning: cast to pointer from integer of different size 
> > [-Wint-to-pointer-cast]
> >
> > Fix by casting it with uintptr_t.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  drivers/cache/cache-sifive-ccache.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Leo Yu-Chi Liang 

Ping for apply?


Re: [PATCH v2] board: sifive: Fix a potential build warning in board_fdt_blob_setup()

2021-10-10 Thread Bin Meng
On Fri, Sep 17, 2021 at 2:52 PM Rick Chen  wrote:
>
> > From: Bin Meng 
> > Sent: Saturday, September 11, 2021 10:31 PM
> > To: Zong Li ; Leo Yu-Chi Liang(梁育齊) 
> > ; Rick Jian-Zhi Chen(陳建志) ; 
> > u-boot@lists.denx.de
> > Subject: [PATCH v2] board: sifive: Fix a potential build warning in 
> > board_fdt_blob_setup()
> >
> > Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in 
> > u-boot proper") added a board-specific implementation of 
> > board_fdt_blob_setup() which takes a pointer as the return value, but it 
> > does not return anything if CONFIG_OF_SEPARATE is not enabled. This will 
> > cause a build warning seen when testing booting S-mode U-Boot directly from 
> > QEMU, per the instructions in [1]:
> >
> >   board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
> >   board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
> > non-void function [-Wreturn-type]
> >
> > Return &_end as the default case.
> >
> > [1] 
> > https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> > Changes in v2:
> > - Correct the commit title
> >
> >  board/sifive/unleashed/unleashed.c | 4 ++--  
> > board/sifive/unmatched/unmatched.c | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
>
> Reviewed-by: Rick Chen 

Ping for apply?


Re: [PATCH] mtd: Add SPI Nor Flash chip GD25LQ256D ID

2021-10-08 Thread Bin Meng
HI Jagan,

On Fri, Oct 8, 2021 at 8:58 PM Jagan Teki  wrote:
>
> On Thu, Sep 30, 2021 at 4:24 PM  wrote:
> >
> > From: "yanhong.wang" 
> >
> > Signed-off-by: yanhong.wang 
> > ---
>
> Applied to u-boot-spi/master

Did you address my comments when applying?

Regards,
Bin


Re: [PATCH 2/2] riscv: Enable SYS_CLK_FREQ config

2021-10-02 Thread Bin Meng
On Thu, Sep 30, 2021 at 8:07 PM  wrote:
>
> From: TekkamanV 
>
> Signed-off-by: TekkamanV 
> ---
>  common/Kconfig.boot | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/Kconfig.boot b/common/Kconfig.boot
> index 902a5b8fbe..4f29cc2d56 100644
> --- a/common/Kconfig.boot
> +++ b/common/Kconfig.boot
> @@ -343,7 +343,7 @@ config SYS_TEXT_BASE
>   The address in memory that U-Boot will be running from, initially.
>
>  config SYS_CLK_FREQ
> -   depends on ARC || ARCH_SUNXI || MPC83xx
> +   depends on ARC || ARCH_SUNXI || MPC83xx || RISCV
> int "CPU clock frequency"
> help
>   TODO: Move CONFIG_SYS_CLK_FREQ for all the architecture
> --

Why do we need this change? It seems nothing related to RISC-V.

Regards,
Bin


Re: [PATCH 1/2] riscv: Enable SYS_MALLOC_LEN config

2021-10-02 Thread Bin Meng
On Thu, Sep 30, 2021 at 8:07 PM  wrote:
>
> From: TekkamanV 
>

Please add a commit message.

> Signed-off-by: TekkamanV 
> ---
>  Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Kconfig b/Kconfig
> index a6c42b902f..7f63929c60 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -249,7 +249,7 @@ config SYS_MALLOC_F_LEN
>
>  config SYS_MALLOC_LEN
> hex "Define memory for Dynamic allocation"
> -   depends on ARCH_ZYNQ || ARCH_VERSAL || ARCH_STM32MP || ARCH_ROCKCHIP
> +   depends on ARCH_ZYNQ || ARCH_VERSAL || ARCH_STM32MP || ARCH_ROCKCHIP 
> || RISCV

You need to also migrate existing RISC-V boards to Kconfig, by
removing CONFIG_SYS_MALLOC_LEN from their config.h files.

> default 0x200 if ARCH_ROCKCHIP
> help
>   This defines memory to be allocated for Dynamic allocation

Regards,
Bin


Re: [PATCH] mtd: Add SPI Nor Flash chip GD25LQ256D ID

2021-10-02 Thread Bin Meng
On Thu, Sep 30, 2021 at 6:55 PM  wrote:
>
> From: "yanhong.wang" 
>

Please add a brief commit message for this, like providing a datasheet
for reference:

https://www.gigadevice.com/datasheet/gd25lq256d/

> Signed-off-by: yanhong.wang 

I believe the name should be spelled as "Yanhong Wang"

> ---
>  drivers/mtd/spi/spi-nor-ids.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 4aef1ddd6e..35fa347c44 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -122,6 +122,11 @@ const struct flash_info spi_nor_ids[] = {
> SECT_4K | SPI_NOR_DUAL_READ |
> SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> },
> +   {
> +   INFO("gd25lq256d", 0xc86019, 0, 64 * 1024, 512,
> +   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> +   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> +   },
>  #endif
>  #ifdef CONFIG_SPI_FLASH_ISSI   /* ISSI */
> /* ISSI */

Otherwise LGTM:
Reviewed-by: Bin Meng 


Re: [PATCH] riscv: add #define in asm/io.h for some device drivers

2021-10-02 Thread Bin Meng
Hi Wei,

On Thu, Sep 30, 2021 at 7:52 PM  wrote:
>
> From: TekkamanV 
>
> This patch add memcpy_fromio and memcpy_toio definitions for some device

%s/add/adds

> drivers which has these definitions, like cadence_qspi_apb.c

%s/has/have

>
> Signed-off-by: TekkamanV 

Please use real name for the contribution, i.e.: following kernel
submitting-patches.rst

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n409

> ---
>  arch/riscv/include/asm/io.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
> index acf5a96449..b693fd8cd6 100644
> --- a/arch/riscv/include/asm/io.h
> +++ b/arch/riscv/include/asm/io.h
> @@ -64,6 +64,10 @@ static inline phys_addr_t map_to_sysmem(const void *ptr)
>  #define __raw_readl(a) __arch_getl(a)
>  #define __raw_readq(a) __arch_getq(a)
>
> +/* adding for some drivers, like cadence_qspi_apb.c */
> +#define memcpy_fromio(a, c, l) memcpy((a), (c), (l))
> +#define memcpy_toio(c, a, l)   memcpy((c), (a), (l))
> +
>  #define dmb()  mb()
>  #define __iormb()      rmb()
>  #define __iowmb()  wmb()

Otherwise, LGTM:
Reviewed-by: Bin Meng 

Regards,
Bin


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-10-01 Thread Bin Meng
Hi Heinrich,

On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
 wrote:
>
> Avoid an error like
>
> Could not get FIT buffer of 1725952 bytes
> check CONFIG_SYS_SPL_MALLOC_SIZE
> No device tree specified in SPL image
> ### ERROR ### Please RESET the board ###
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/configs/sifive-unmatched.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/configs/sifive-unmatched.h 
> b/include/configs/sifive-unmatched.h
> index f8ad2cce1f..8d3deabdd3 100644
> --- a/include/configs/sifive-unmatched.h
> +++ b/include/configs/sifive-unmatched.h
> @@ -18,7 +18,7 @@
>  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
>  #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR + \
>  CONFIG_SPL_BSS_MAX_SIZE)
> -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020
>
>  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
>  GENERATED_GBL_DATA_SIZE)

What caused this?

Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN was
increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error
messages point to

https://lists.denx.de/pipermail/u-boot/2021-May/449447.html

Regards,
Bin


Re: Driver model at UEFI runtime

2021-09-30 Thread Bin Meng
On Thu, Sep 30, 2021 at 2:23 PM François Ozog 
wrote:

>
>
> Le jeu. 30 sept. 2021 à 07:12, Bin Meng  a écrit :
>
>> Hi Heinrich,
>>
>> On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt 
>> wrote:
>> >
>> > Hello Simon,
>> >
>> > The EBBR specification requires that the UEFI SystemReset() runtime
>> > service is available to the operating system.
>> >
>> > Up to now this has been implemented by overriding function
>> > efi_reset_system() which is marked as __efi_runtime.
>> >
>> > Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM
>> > and the System Reset Extension for SBI on RISC-V. This has kept the
>> > number of implementations low. The only exceptions are:
>> >
>> > * arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>> > * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs
>> > * arch/sandbox/cpu/start.c
>> >
>> > Bin has suggested in
>> > https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to
>> use
>> > reset drivers based on the driver model.
>> >
>> > Currently after ExitBootServices() the driver model does not exist
>> anymore.
>> >
>> > When evaluating Bin's suggestion one has to keep in mind that after
>> > invoking ExitBootServices() most operating systems call
>> > SetVirtualAddressMap(). Due to the change of the address map all
>> > pointers used by U-Boot afterwards must be updated to match the new
>> > memory map.
>> >
>>
>> Yeah, this was discussed 3 years ago:
>>
>> https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken
>>
>> > The impression that Ilias and I have is that keeping the driver model
>> > alive after SetVirtualAddressMap() would incur:
>> >
>> > * a high development effort
>> > * a significant code size increase
>> > * an enlarged attack surface
>> >
>> > For RISC-V it has been clarified in the platform specification that the
>> > SBI must implement the system reset extension. For ARMv8 using TF-A and
>> > PSCI is what ARM suggests.
>> >
>> > So for these architectures we do not expect a growth in the number of
>> > drivers needed.
>> >
>> > Ilias and my favorite would be keeping the design as is.
>> >
>> > What is your view on this?
>>
>> Is U-Boot's UEFI loader implementation supposed to be the recommended
>> UEFI firmware on ARM and RISC-V on a production / deployment system?
>
> For Arm: yes, that is SystemReady spec.
>

How about EDK II? Is EDK II supposed to be used in the server environment
where UEFI + ACPI is the way to go? Does any board that ships EDK II with
UEFI + DTB? Can we safely assume that U-Boot's UEFI loader is the reference
implementation for UEFI + DTB on Arm?


>
>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we
>> expect to load grub.efi which chain-loads a kernel without
>> CONFIG_EFI_STUB?
>
> all paths should be possible , and the shim.efi is to be supported too.
> With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In
> other words I don’t see grub.efi booting a non config_efi_stub.
>
>> What do distributions normally do?
>
> At least Red Hat made it clear at multiple Linaro Connect that they want
> standards, and SystemReady is one that makes the life of embedded distros
> easy.
> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot.
>
>> What's our
>> position when compared to EDK II?
>
> the typical distro boot flow is not the most efficient and drags concept
> dating where the Microsoft certs had to be part of the picture. A direct
> U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path
> (grub), avoids convoluted platform cert management (shim) and just enhance
> security and boot time. Note: Since kernel 5.10, initrd can be measured
> (with TPM) when loaded by efi-stub.
>

Regards,
Bin


Re: Driver model at UEFI runtime

2021-09-29 Thread Bin Meng
Hi Heinrich,

On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt  wrote:
>
> Hello Simon,
>
> The EBBR specification requires that the UEFI SystemReset() runtime
> service is available to the operating system.
>
> Up to now this has been implemented by overriding function
> efi_reset_system() which is marked as __efi_runtime.
>
> Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM
> and the System Reset Extension for SBI on RISC-V. This has kept the
> number of implementations low. The only exceptions are:
>
> * arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs
> * arch/sandbox/cpu/start.c
>
> Bin has suggested in
> https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use
> reset drivers based on the driver model.
>
> Currently after ExitBootServices() the driver model does not exist anymore.
>
> When evaluating Bin's suggestion one has to keep in mind that after
> invoking ExitBootServices() most operating systems call
> SetVirtualAddressMap(). Due to the change of the address map all
> pointers used by U-Boot afterwards must be updated to match the new
> memory map.
>

Yeah, this was discussed 3 years ago:
https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken

> The impression that Ilias and I have is that keeping the driver model
> alive after SetVirtualAddressMap() would incur:
>
> * a high development effort
> * a significant code size increase
> * an enlarged attack surface
>
> For RISC-V it has been clarified in the platform specification that the
> SBI must implement the system reset extension. For ARMv8 using TF-A and
> PSCI is what ARM suggests.
>
> So for these architectures we do not expect a growth in the number of
> drivers needed.
>
> Ilias and my favorite would be keeping the design as is.
>
> What is your view on this?

Is U-Boot's UEFI loader implementation supposed to be the recommended
UEFI firmware on ARM and RISC-V on a production / deployment system?
Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we
expect to load grub.efi which chain-loads a kernel without
CONFIG_EFI_STUB? What do distributions normally do? What's our
position when compared to EDK II?

Regards,
Bin


Re: [PATCH v2 04/10] net: introduce a helper to determine whether to use in-band autoneg

2021-09-29 Thread Bin Meng
On Wed, Sep 29, 2021 at 11:05 PM Vladimir Oltean
 wrote:
>
> Certain serial SERDES protocols like 1000base-x, 2500base-x, SGMII,
> USXGMII can operate either in a mode where the PHY (be it on-board or
> inside an SFP module) passes the link parameters (speed, duplex, pause)
> to the MAC through in-band through control words standardized by IEEE
> 802.3 clause 37, or in a mode where the MAC must configure (force) its
> link parameters based on information obtained out-of-band (MDIO reads,
> guesswork etc).
>
> In Linux, the OF node property named "managed" is parsed by the phylink
> framework, and the convention is that if a driver uses phylink, then the
> presence of this property means that in-band autoneg should be enabled,
> otherwise it shouldn't.
>
> To be compatible with the OF node bindings of drivers that use phylink
> in Linux, introduce parsing support for this property in U-Boot too.
>
> Signed-off-by: Vladimir Oltean 
> Reviewed-by: Ramon Fried 
> ---
> v1->v2: none
>
>  drivers/core/of_extra.c | 12 
>  include/dm/of_extra.h   | 14 ++
>  2 files changed, 26 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v2] board: sifive: Fix a potential build warning in board_fdt_blob_setup()

2021-09-29 Thread Bin Meng
Hi Ilias,

On Wed, Sep 29, 2021 at 9:07 PM Ilias Apalodimas
 wrote:
>
> Hi Bin
>
> There's a similar discussion in a cleanup series I've sent [1]
> On Sat, Sep 11, 2021 at 10:31:23PM +0800, Bin Meng wrote:
> > Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in 
> > u-boot proper")
> > added a board-specific implementation of board_fdt_blob_setup() which
> > takes a pointer as the return value, but it does not return anything
> > if CONFIG_OF_SEPARATE is not enabled. This will cause a build warning
> > seen when testing booting S-mode U-Boot directly from QEMU, per the
> > instructions in [1]:
>
> It's not only a build warning, you don't even have a DTB to begin with.
>
> >
> >   board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
> >   board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
> > non-void function [-Wreturn-type]
> >
> > Return &_end as the default case.
> >
> > [1] 
> > https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> > Changes in v2:
> > - Correct the commit title
> >
> >  board/sifive/unleashed/unleashed.c | 4 ++--
> >  board/sifive/unmatched/unmatched.c | 4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/board/sifive/unleashed/unleashed.c 
> > b/board/sifive/unleashed/unleashed.c
> > index 8cd514df30..33baeda986 100644
> > --- a/board/sifive/unleashed/unleashed.c
> > +++ b/board/sifive/unleashed/unleashed.c
> > @@ -119,9 +119,9 @@ void *board_fdt_blob_setup(void)
> >   if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
> >   if (gd->arch.firmware_fdt_addr)
> >   return (ulong *)gd->arch.firmware_fdt_addr;
> > - else
> > - return (ulong *)&_end;
> >   }
> > +
> > + return (ulong *)&_end;
> >  }
> >
> >  int board_init(void)
> > diff --git a/board/sifive/unmatched/unmatched.c 
> > b/board/sifive/unmatched/unmatched.c
> > index d90b252bae..8773b660fa 100644
> > --- a/board/sifive/unmatched/unmatched.c
> > +++ b/board/sifive/unmatched/unmatched.c
> > @@ -16,9 +16,9 @@ void *board_fdt_blob_setup(void)
> >   if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
> >   if (gd->arch.firmware_fdt_addr)
> >   return (ulong *)gd->arch.firmware_fdt_addr;
> > - else
> > - return (ulong *)&_end;
> >   }
> > +
> > + return (ulong *)&_end;
>
> is _end correct here? Doesn't the placement depend on CONFIG_SPL_BUILD and
> CONFIG_SPL_SEPARATE_BSS?
>

I will have to leave this to Zong to comment as he introduced this via
commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in
u-boot proper").

I don't know what user case that Zong wanted to support on Unleased
and Unmatched.

> To sum up the other thread I think the overall approach here is not ideal.
> OF_SEPARATE is used in conjunction with SPL in these boards.  What happens
> (assuming I didn't miss anything),  is that SPL passes the DTB to OpenSBI,
> which in it turn copies to a1 before invoking U-Boot.
> But we are better of with stricter rules for DTB.
> - OF_SEPARATE means: I'll read the DTB from the U-Boot binary.
> - OF_BOARD: The board will somehow provide it.
>
> So II think the patch should look something along the lines of:
>
> if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
> #ifdef CONFIG_SPL_BUILD
> /* FDT is at end of BSS unless it is in a different memory region */
> if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
> fdt_blob = (void *)&_image_binary_end;
> else
> fdt_blob = (void *)&__bss_end;
> #else
> /* FDT is at end of image */
> fdt_blob = (void *)&_end;
>

Missing #endif here?

> }
>
> if (IS_ENABLED(CONFIG_OF_BOARD)) {
> fdt_blob = (void *)gd->arch.firmware_fdt_addr;
> }
>
> >  }
> >
> >  int board_init(void)
> > --

Regards,
Bin


[PATCH 3/3] net: tsec: Make redundant_init() static

2021-09-28 Thread Bin Meng
redundant_init() is only called in the tsec driver. Make it static.

Signed-off-by: Bin Meng 
---

 drivers/net/tsec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index ee820aae15..b433e411bd 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -432,7 +432,7 @@ static void tsec_halt(struct udevice *dev)
  * of the eTSEC port initialization sequence,
  * the eTSEC Rx logic may not be properly initialized.
  */
-void redundant_init(struct tsec_private *priv)
+static void redundant_init(struct tsec_private *priv)
 {
struct tsec __iomem *regs = priv->regs;
uint t, count = 0;
-- 
2.25.1



[PATCH 2/3] net: fec_mxc: Declare 'promisc' as bool

2021-09-28 Thread Bin Meng
priv->promisc is used as the parameter of the set_promisc() call
which accepts a bool type instead of char.

Signed-off-by: Bin Meng 
---

 drivers/net/fec_mxc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 62b55ef395..133f535917 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -272,7 +272,7 @@ struct fec_priv {
struct clk clk_ref;
struct clk clk_ptp;
u32 clk_rate;
-   char promisc;
+   bool promisc;
 };
 
 /**
-- 
2.25.1



[PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call

2021-09-28 Thread Bin Meng
set_promisc() call accepts the parameter of a bool type. Make it
clear by using true instead of 1.

Signed-off-by: Bin Meng 
---

 net/dsa-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 694664d81b..dcefec03f4 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -282,7 +282,7 @@ static int dsa_port_probe(struct udevice *pdev)
struct eth_ops *eth_ops = eth_get_ops(master);
 
if (eth_ops->set_promisc)
-   eth_ops->set_promisc(master, 1);
+   eth_ops->set_promisc(master, true);
 
return 0;
}
-- 
2.25.1



Re: [PATCH v2 1/2] nvme: Enable FUA

2021-09-28 Thread Bin Meng
On Mon, Sep 27, 2021 at 9:22 PM Jon Lin  wrote:
>
> Most NVME devcies maintain data in internal cache for an uncertain

typo: devices

> times, and u-boot has no method to force NVME to flush cache.
> So this patch adds FUA to avoid data loss caused by power off after data
> programming.
>
> Signed-off-by: Jon Lin 
> Reviewed-by: Stefan Agner 
> ---
>
> (no changes since v1)
>
>  drivers/nvme/nvme.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index f6465ea7f4..5d05cb6e9e 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -761,6 +761,9 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t 
> blknr,
> c.rw.appmask = 0;
> c.rw.metadata = 0;
>
> +   /* Always enable FUA for data integrity */
> +   c.rw.control |= NVME_RW_FUA;

I don't think we should blindly enable FUA, instead we should check
whether the Volatile Write Cache is enabled or not, and if enabled,
set FUA, or just completely disable Volatile Write Cache.

> +
> while (total_lbas) {
> if (total_lbas < lbas) {
> lbas = (u16)total_lbas;
> --

Regards,
Bin


Re: [PATCH 9/9] configs: ls1021a-tsn: enable the generation of random Ethernet MAC addresses

2021-09-28 Thread Bin Meng
On Tue, Sep 28, 2021 at 7:50 AM Vladimir Oltean  wrote:
>
> Don't fail when booting a board with an empty EEPROM for MAC addresses.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  configs/ls1021atsn_qspi_defconfig   | 1 +
>  configs/ls1021atsn_sdcard_defconfig | 1 +
>  2 files changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 8/9] configs: ls1021a-tsn: enable sja1105 switch driver

2021-09-28 Thread Bin Meng
On Tue, Sep 28, 2021 at 7:51 AM Vladimir Oltean  wrote:
>
> The sja1105 is a 5-port switch that uses a DM_DSA driver. Its 5th (CPU)
> port is connected internally to the eth2 port of the LS1021A SoC.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  configs/ls1021atsn_qspi_defconfig   | 2 ++
>  configs/ls1021atsn_sdcard_defconfig | 2 ++
>  2 files changed, 4 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 4/9] net: introduce a helper to determine whether to use in-band autoneg

2021-09-28 Thread Bin Meng
On Tue, Sep 28, 2021 at 7:50 AM Vladimir Oltean  wrote:
>
> Certain serial SERDES protocols like 1000base-x, 2500base-x, SGMII,
> USXGMII can operate either in a mode where the PHY (be it on-board or
> inside an SFP module) passes the link parameters (speed, duplex, pause)
> to the MAC through in-band through control words standardized by IEEE
> 802.3 clause 37, or in a mode where the MAC must configure (force) its
> link parameters based on information obtained out-of-band (MDIO reads,
> guesswork etc).
>
> In Linux, the OF node property named "managed" is parsed by the phylink
> framework, and the convention is that if a driver uses phylink, then the
> presence of this property means that in-band autoneg should be enabled,
> otherwise it shouldn't.
>
> To be compatible with the OF node bindings of drivers that use phylink
> in Linux, introduce parsing support for this property in U-Boot too.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/core/of_extra.c | 12 
>  include/dm/of_extra.h   | 14 ++++++
>  2 files changed, 26 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 2/9] include: import if_vlan.h from Linux

2021-09-28 Thread Bin Meng
On Tue, Sep 28, 2021 at 7:49 AM Vladimir Oltean  wrote:
>
> This is needed for the VLAN header structure.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  include/linux/if_vlan.h | 26 ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 include/linux/if_vlan.h
>

Reviewed-by: Bin Meng 


Re: [PATCH 1/9] net: tsec: add support for promiscuous mode

2021-09-28 Thread Bin Meng
On Tue, Sep 28, 2021 at 7:49 AM Vladimir Oltean  wrote:
>
> The Freescale TSEC can be a DSA master, and the ports of the attached
> DSA switch can have different MAC addresses compared to the TSEC.
> Nonetheless, the TSEC must receive the packets on behalf of those switch
> ports. Therefore, implement the promiscuous mode method to allow DSA to
> set this.
>
> Note that the init_registers() function called from eth_ops :: start
> overwrites this setting. There is no reason why the RCTRL register
> should be zero-initialized, so just stop clearing it so that the setting
> we applied in eth_ops :: set_promisc sticks.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/tsec.c | 20 
>  include/tsec.h |  2 ++
>  2 files changed, 18 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH] configs: ls1028a: ensure Ethernet is enabled

2021-09-28 Thread Bin Meng
On Tue, Sep 28, 2021 at 7:18 AM Vladimir Oltean  wrote:
>
> CONFIG_FSL_ENETC is not explicitly enabled in the NXP LS1028A config
> files, instead it is selected by CONFIG_MSCC_FELIX_SWITCH, a state of
> matters which is fragile.
>
> CONFIG_MSCC_FELIX_SWITCH depends on CONFIG_DM_DSA, which depends on
> CONFIG_PHY_FIXED.
>
> Not all LS1028A boards did enable CONFIG_PHY_FIXED, which resulted in
> all of Ethernet being compiled out.
>
> This patch makes sure that CONFIG_PHY_FIXED is enabled for all LS1028A
> boards, and CONFIG_FSL_ENETC as well - don't rely on that fragile
> selection done by the Felix switch config.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  configs/kontron_sl28_defconfig   | 1 +
>  configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 +
>  configs/ls1028aqds_tfa_defconfig | 1 +
>  configs/ls1028aqds_tfa_lpuart_defconfig  | 1 +
>  configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 +
>  configs/ls1028ardb_tfa_defconfig         | 1 +
>  6 files changed, 6 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v7 8/8] drivers: net: macb: add fu740 support

2021-09-27 Thread Bin Meng
Hi,

On Thu, Apr 22, 2021 at 5:14 PM Green Wan  wrote:
>
> From: David Abdurachmanov 
>
> Add fu740 support to macb ethernet driver
>
> There is a PLL HW quirk in FU740. The VSC8541XMV-02 specification
> requires 125 +/-0.0125 Mhz. But the most close value can be output
> by PLL is 125.125 MHz and out of VSC8541XMV-02 spec.
>
> Signed-off-by: David Abdurachmanov 
> Signed-off-by: Green Wan 
> Reviewed-by: Ramon Fried 
> Reviewed-by: Bin Meng 
> ---
>  drivers/net/macb.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>

It looks this patch was never applied. Both U-Boot and Linux drivers
do not have the "sifive,fu740-c000-gem" codes.

Not sure what the current upstream status of this?

Regards,
Bin


Re: [PATCH] Makelfile: clean target should remove itb*

2021-09-23 Thread Bin Meng
Hi Heinrich,

On Thu, Sep 23, 2021 at 6:12 PM Heinrich Schuchardt
 wrote:
>
> In the U-Boot directory files itb.fit.fit, itb.fit.itb, itb.map are
> created (e.g. for sifive_unmatched_defconfig). These should be removed by
> the clean target.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

See 
http://patchwork.ozlabs.org/project/uboot/patch/20210505141557.23901-8-bmeng...@gmail.com/

Simon suggested binman should be updated to output the generated files.

Regards,
Bin


Re: USB 3.1 support

2021-09-22 Thread Bin Meng
HI Aaron,

On Thu, Sep 23, 2021 at 9:24 AM Aaron Williams  wrote:
>
> Hi all,
>
> You can ignore my previous email. It looks like it's being added as I type
> this.
>
> Best Regards,
>
> -Aaron Williams
>
> On Wednesday, September 22, 2021 6:22:00 PM PDT Aaron Williams wrote:
> > Hi Bin, Stefan,
> >
> > Is the U-Boot USB support compatible with USB 3.1 or does this need to be
> > added? The SoC I'm working on (CN106XX) includes USB 3.1 support. I have not
> > yet tried U-Boot on this chip but will shortly. If not, are there any
> > branches with USB 3.1 changes or are no changes required?

USB 3.1 / 3.2 is backward compatible with 3.0 if you are only looking
at the super speed. There is definitely work to do for 10G/20G support
but I doubt that brings too much value to U-Boot.

Regards,
Bin


Re: [PATCH] MAINTAINERS: remove SPEAR entry

2021-09-22 Thread Bin Meng
On Wed, Sep 22, 2021 at 12:19 AM Patrick Delaunay
 wrote:
>
> As the lastest spear directories are removed, delete the associated entry
> in the MAINTAINERS file:
> - arch/arm/cpu/arm926ejs/spear/
> - arch/arm/include/asm/arch-spear/
>
> Fixes: 570c3dcfc153 ("arm: Remove spear600 boards and the rest of SPEAr 
> support")
> Signed-off-by: Patrick Delaunay 
> ---
>
>  MAINTAINERS | 7 ---
>  1 file changed, 7 deletions(-)
>

Reviewed-by: Bin Meng 


Please pull u-boot-x86

2021-09-22 Thread Bin Meng
Hi Tom,

This PR includes the following x86 changes for v2021.10 release:

- Small fixes to eMMC and SDHCI for Intel Edison

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=457=results

The following changes since commit cfb573d22dac1089b5c792bc8529dd76acfa68fc:

  Merge tag 'u-boot-stm32-20210921' of
https://source.denx.de/u-boot/custodians/u-boot-stm (2021-09-22
09:38:48 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to 57e2c0a86fe48194c9407d36d60f9ab033b4460e:

  x86: tangier: acpi: Add GPIO card detection to SDHCI #2 (2021-09-22
21:50:35 +0800)


Andy Shevchenko (2):
  x86: edison: Mark eMMC non-removable
  x86: tangier: acpi: Add GPIO card detection to SDHCI #2

 arch/x86/dts/edison.dts |  1 +
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 32

 2 files changed, 33 insertions(+)

Regards,
Bin


Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

2021-09-21 Thread Bin Meng
On Tue, Sep 21, 2021 at 8:42 PM Tom Rini  wrote:
>
> On Sun, Sep 19, 2021 at 10:33:25PM +0200, Mark Kettenis wrote:
> > > From: Bin Meng 
> > > Date: Sun, 19 Sep 2021 09:17:07 +0800
> > >
> > > Hi Mark,
> > >
> > > On Sun, Sep 19, 2021 at 9:04 AM Bin Meng  wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > > > > Macs.  This builds a basic U-Boot that can be used as a payload
> > > > > for the m1n1 boot loader being developed by the Asahi Linux
> > > > > project.
> > > > >
> > > > > Signed-off-by: Mark Kettenis 
> > > > > ---
> > > > >  arch/arm/Kconfig|  22 
> > > > >  arch/arm/Makefile   |   1 +
> > > > >  arch/arm/mach-apple/Kconfig |  18 
> > > > >  arch/arm/mach-apple/Makefile|   4 +
> > > > >  arch/arm/mach-apple/board.c | 158 
> > > > > 
> > > > >  arch/arm/mach-apple/lowlevel_init.S |  16 +++
> > > > >  configs/apple_m1_defconfig  |  14 +++
> > > > >  include/configs/apple.h |  38 +++
> > > > >  8 files changed, 271 insertions(+)
> > > > >  create mode 100644 arch/arm/mach-apple/Kconfig
> > > > >  create mode 100644 arch/arm/mach-apple/Makefile
> > > > >  create mode 100644 arch/arm/mach-apple/board.c
> > > > >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> > > > >  create mode 100644 configs/apple_m1_defconfig
> > > > >  create mode 100644 include/configs/apple.h
> > > > >
> > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > > index b5bd3284cd..7cdea1f615 100644
> > > > > --- a/arch/arm/Kconfig
> > > > > +++ b/arch/arm/Kconfig
> > > > > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > > > > select DM
> > > > > select GPIO_EXTRA_HEADER
> > > > >
> > > > > +config ARCH_APPLE
> > > > > +   bool "Apple SoCs"
> > > > > +   select ARM64
> > > > > +   select LINUX_KERNEL_IMAGE_HEADER
> > > > > +   select POSITION_INDEPENDENT
> > > > > +   select BLK
> > > > > +   select DM
> > > > > +   select DM_KEYBOARD
> > > > > +   select DM_SERIAL
> > > > > +   select DM_USB
> > > > > +   select DM_VIDEO
> > > > > +   select CMD_USB
> > > > > +   select MISC
> > > > > +   select OF_CONTROL
> > > > > +   select OF_BOARD
> > > > > +   select USB
> > > > > +   imply CMD_DM
> > > > > +   imply CMD_GPT
> > > > > +   imply DISTRO_DEFAULTS
> > > > > +
> > > > >  config ARCH_OWL
> > > > > bool "Actions Semi OWL SoCs"
> > > > > select DM
> > > > > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
> > > > >   image headers.
> > > > >  endif
> > > > >
> > > > > +source "arch/arm/mach-apple/Kconfig"
> > > > > +
> > > > >  source "arch/arm/mach-aspeed/Kconfig"
> > > > >
> > > > >  source "arch/arm/mach-at91/Kconfig"
> > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > > index c68e598a67..44178c204b 100644
> > > > > --- a/arch/arm/Makefile
> > > > > +++ b/arch/arm/Makefile
> > > > > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
> > > > >
> > > > >  # Machine directory name.  This list is sorted alphanumerically
> > > > >  # by CONFIG_* macro name.
> > > > > +machine-$(CONFIG_ARCH_APPLE)   += apple
> > > > >  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
> > > > >  machine-$(CONFIG_ARCH_AT91)+= at91
> > > > >  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> > > > > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconf

Re: [PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers

2021-09-20 Thread Bin Meng
On Mon, Sep 20, 2021 at 6:44 AM Marek Vasut  wrote:
>
> On 9/19/21 10:40 AM, Bin Meng wrote:
> > Hi Marek,
> >
> > On Thu, Sep 16, 2021 at 10:08 PM Bin Meng  wrote:
> >>
> >> On Thu, Sep 16, 2021 at 10:00 PM Mark Kettenis  
> >> wrote:
> >>>
> >>> This adds support for the DWC_sub31 controllers such as those
> >>> found on Apple's M1 SoC.  This version of the controller
> >>> seems to work fine with the existing driver.
> >>>
> >>> Signed-off-by: Mark Kettenis 
> >>> ---
> >>>   drivers/usb/host/xhci-dwc3.c | 3 ++-
> >>>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>
> >> Reviewed-by: Bin Meng 
> >
> > I see this is assigned to me on patchwork. Would you like this to go
> > via the x86 tree?
>
> Since it's just one patch, I suspect Tom can just pick it directly.

Thanks, I have re-assigned it to Tom on patchwork.

Regards,
Bin


Re: [PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers

2021-09-19 Thread Bin Meng
Hi Marek,

On Thu, Sep 16, 2021 at 10:08 PM Bin Meng  wrote:
>
> On Thu, Sep 16, 2021 at 10:00 PM Mark Kettenis  wrote:
> >
> > This adds support for the DWC_sub31 controllers such as those
> > found on Apple's M1 SoC.  This version of the controller
> > seems to work fine with the existing driver.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  drivers/usb/host/xhci-dwc3.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

I see this is assigned to me on patchwork. Would you like this to go
via the x86 tree?

Regards,
Bin


Re: [PATCH v3 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2

2021-09-19 Thread Bin Meng
On Sun, Sep 12, 2021 at 2:27 AM Andy Shevchenko
 wrote:
>
> On Intel Tangier the SDHCI #2 provides SD card connection.
> Add GPIO card detection for it.
>
> Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
> BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
> Signed-off-by: Andy Shevchenko 
> Acked-by: Bin Meng 
> ---
> v3: basically returned to the content of v2 (pull bias back to none)
> since there is nothing special about the signal which is supposed
> to be triggered by both edges
>
>  .../asm/arch-tangier/acpi/southcluster.asl| 32 +++
>  1 file changed, 32 insertions(+)
>

applied to u-boot-x86, thanks!


Re: [PATCH v1 1/1] x86: edison: Mark eMMC non-removable

2021-09-19 Thread Bin Meng
On Fri, Sep 10, 2021 at 7:35 PM Bin Meng  wrote:
>
> On Fri, Sep 10, 2021 at 3:59 PM Andy Shevchenko
>  wrote:
> >
> > eMMC is non-removable on Intel Edison board. Fix the DTS accordingly.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/dts/edison.dts | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH 2/2] net: tsec: read the phy-mode property as fallback to phy-connection-type

2021-09-19 Thread Bin Meng
On Sat, Sep 18, 2021 at 8:47 PM Vladimir Oltean  wrote:
>
> The two should be equivalent, but at the moment some platforms
> (ls1021a-tsn.dts) use phy-mode only, which is not parsed.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/tsec.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH 1/2] net: tsec: only call tsec_get_interface as fallback to DT-specified PHY mode

2021-09-19 Thread Bin Meng
On Sat, Sep 18, 2021 at 8:47 PM Vladimir Oltean  wrote:
>
> Currently the init_phy function may overwrite the priv->interface
> property, since it calls tsec_get_interface which tries to determine it
> dynamically based on default register values in ECNTRL.
>
> Let's do that only if phy-connection-type happens to not be defined in
> the device tree.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/tsec.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH 5/5] doc: board: apple: Add Apple M1 documentation

2021-09-18 Thread Bin Meng
On Sat, Sep 18, 2021 at 9:56 PM Mark Kettenis  wrote:
>
> Provide preliminary instructions on how to get U-Boot to run on
> Apple Silicon Macs.
>
> Signed-off-by: Mark Kettenis 
> ---
>  doc/board/apple/index.rst |  9 +++
>  doc/board/apple/m1.rst| 56 +++
>  doc/board/index.rst   |  1 +
>  3 files changed, 66 insertions(+)
>  create mode 100644 doc/board/apple/index.rst
>  create mode 100644 doc/board/apple/m1.rst
>

Reviewed-by: Bin Meng 


Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

2021-09-18 Thread Bin Meng
Hi Mark,

On Sun, Sep 19, 2021 at 9:04 AM Bin Meng  wrote:
>
> Hi Mark,
>
> On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  wrote:
> >
> > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > Macs.  This builds a basic U-Boot that can be used as a payload
> > for the m1n1 boot loader being developed by the Asahi Linux
> > project.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  arch/arm/Kconfig|  22 
> >  arch/arm/Makefile   |   1 +
> >  arch/arm/mach-apple/Kconfig |  18 
> >  arch/arm/mach-apple/Makefile|   4 +
> >  arch/arm/mach-apple/board.c | 158 
> >  arch/arm/mach-apple/lowlevel_init.S |  16 +++
> >  configs/apple_m1_defconfig  |  14 +++
> >  include/configs/apple.h |  38 +++
> >  8 files changed, 271 insertions(+)
> >  create mode 100644 arch/arm/mach-apple/Kconfig
> >  create mode 100644 arch/arm/mach-apple/Makefile
> >  create mode 100644 arch/arm/mach-apple/board.c
> >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> >  create mode 100644 configs/apple_m1_defconfig
> >  create mode 100644 include/configs/apple.h
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index b5bd3284cd..7cdea1f615 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > select DM
> > select GPIO_EXTRA_HEADER
> >
> > +config ARCH_APPLE
> > +   bool "Apple SoCs"
> > +   select ARM64
> > +   select LINUX_KERNEL_IMAGE_HEADER
> > +   select POSITION_INDEPENDENT
> > +   select BLK
> > +   select DM
> > +   select DM_KEYBOARD
> > +   select DM_SERIAL
> > +   select DM_USB
> > +   select DM_VIDEO
> > +   select CMD_USB
> > +   select MISC
> > +   select OF_CONTROL
> > +   select OF_BOARD
> > +   select USB
> > +   imply CMD_DM
> > +   imply CMD_GPT
> > +   imply DISTRO_DEFAULTS
> > +
> >  config ARCH_OWL
> > bool "Actions Semi OWL SoCs"
> > select DM
> > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
> >   image headers.
> >  endif
> >
> > +source "arch/arm/mach-apple/Kconfig"
> > +
> >  source "arch/arm/mach-aspeed/Kconfig"
> >
> >  source "arch/arm/mach-at91/Kconfig"
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index c68e598a67..44178c204b 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
> >
> >  # Machine directory name.  This list is sorted alphanumerically
> >  # by CONFIG_* macro name.
> > +machine-$(CONFIG_ARCH_APPLE)   += apple
> >  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
> >  machine-$(CONFIG_ARCH_AT91)+= at91
> >  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> > new file mode 100644
> > index 00..66cab91b2a
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/Kconfig
> > @@ -0,0 +1,18 @@
> > +if ARCH_APPLE
> > +
> > +config SYS_TEXT_BASE
> > +   default 0x
> > +
> > +config SYS_CONFIG_NAME
> > +   default "apple"
> > +
> > +config SYS_SOC
> > +   default "m1"
> > +
> > +config SYS_MALLOC_LEN
> > +   default 0x400
> > +
> > +config SYS_MALLOC_F_LEN
> > +   default 0x4000
> > +
> > +endif
> > diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> > new file mode 100644
> > index 00..e74a8c9df1
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +obj-y += board.o
> > +obj-y += lowlevel_init.o
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > new file mode 100644
> > index 00..0c8b35292e
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -0,0 +1,158 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2021 Mark Kettenis 
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOB

Re: [PATCH 2/5] serial: s5p: Add Apple M1 support

2021-09-18 Thread Bin Meng
Hi Mark,

On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  wrote:
>
> Apple M1 SoCs include an S5L UART which is a variant of the S5P
> UART.  Add support for this variant and enable it by default
> on Apple SoCs.
>
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/include/asm/arch-m1/clk.h  | 11 
>  arch/arm/include/asm/arch-m1/uart.h | 41 +
>  arch/arm/mach-apple/board.c |  5 
>  drivers/serial/Kconfig  |  2 +-
>  drivers/serial/serial_s5p.c | 22 
>  5 files changed, 80 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-m1/clk.h
>  create mode 100644 arch/arm/include/asm/arch-m1/uart.h
>
> diff --git a/arch/arm/include/asm/arch-m1/clk.h 
> b/arch/arm/include/asm/arch-m1/clk.h
> new file mode 100644
> index 00..f4326d0c0f
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-m1/clk.h
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 Mark Kettenis 
> + */
> +
> +#ifndef __ASM_ARM_ARCH_CLK_H_
> +#define __ASM_ARM_ARCH_CLK_H_
> +
> +unsigned long get_uart_clk(int dev_index);
> +
> +#endif
> diff --git a/arch/arm/include/asm/arch-m1/uart.h 
> b/arch/arm/include/asm/arch-m1/uart.h
> new file mode 100644
> index 00..d2a17a221e
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-m1/uart.h
> @@ -0,0 +1,41 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) Copyright 2009 Samsung Electronics
> + * Minkyu Kang 
> + * Heungjun Kim 
> + */
> +
> +#ifndef __ASM_ARCH_UART_H_
> +#define __ASM_ARCH_UART_H_
> +
> +#ifndef __ASSEMBLY__
> +/* baudrate rest value */
> +union br_rest {
> +   unsigned short  slot;   /* udivslot */
> +   unsigned char   value;  /* ufracval */
> +};
> +
> +struct s5p_uart {
> +   unsigned intulcon;
> +   unsigned intucon;
> +   unsigned intufcon;
> +   unsigned intumcon;
> +   unsigned intutrstat;
> +   unsigned intuerstat;
> +   unsigned intufstat;
> +   unsigned intumstat;
> +   unsigned intutxh;
> +   unsigned inturxh;
> +   unsigned intubrdiv;
> +   union br_rest   rest;
> +   unsigned char   res3[0x3fd0];
> +};

This does not look correct. This should be declared in the s5p UART
driver header instead of SoC's

> +
> +static inline int s5p_uart_divslot(void)
> +{
> +   return 0;
> +}
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index 0c8b35292e..8bc5c2f69e 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -156,3 +156,8 @@ ulong board_get_usable_ram_top(ulong total_size)
>  */
> return 0x98000;
>  }
> +
> +unsigned long get_uart_clk(int dev_index)
> +{
> +   return 2400;
> +}
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 93348c0929..c3ac773929 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -719,7 +719,7 @@ config ROCKCHIP_SERIAL
>
>  config S5P_SERIAL
> bool "Support for Samsung S5P UART"
> -   depends on ARCH_EXYNOS || ARCH_S5PC1XX
> +   depends on ARCH_APPLE || ARCH_EXYNOS || ARCH_S5PC1XX
> default y
> help
>   Select this to enable Samsung S5P UART support.
> diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
> index 6d09952a5d..eb770d9b62 100644
> --- a/drivers/serial/serial_s5p.c
> +++ b/drivers/serial/serial_s5p.c
> @@ -21,12 +21,21 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#ifdef CONFIG_ARCH_APPLE
> +#define RX_FIFO_COUNT_SHIFT0
> +#define RX_FIFO_COUNT_MASK (0xf << RX_FIFO_COUNT_SHIFT)
> +#define RX_FIFO_FULL   (1 << 8)
> +#define TX_FIFO_COUNT_SHIFT4
> +#define TX_FIFO_COUNT_MASK (0xf << TX_FIFO_COUNT_SHIFT)
> +#define TX_FIFO_FULL   (1 << 9)

So different bit positions for RX/TX FIFIO register but still it is
s5p compatible, strange ...

> +#else
>  #define RX_FIFO_COUNT_SHIFT0
>  #define RX_FIFO_COUNT_MASK (0xff << RX_FIFO_COUNT_SHIFT)
>  #define RX_FIFO_FULL   (1 << 8)
>  #define TX_FIFO_COUNT_SHIFT16
>  #define TX_FIFO_COUNT_MASK (0xff << TX_FIFO_COUNT_SHIFT)
>  #define TX_FIFO_FULL   (1 << 24)
> +#endif
>
>  /* Information about a serial port */
>  struct s5p_serial_plat {
> @@ -83,7 +92,11 @@ static void __maybe_unused s5p_serial_baud(struct s5p_uart 
> *uart, uint uclk,
> if (s5p_uart_divslot())
> writew(udivslot[val % 16], >rest.slot);
> else
> +#ifdef CONFIG_ARCH_APPLE
> +   writel(val % 16, >rest.value);

This looks like we should add a property in DT like "reg-width" to
control such behavior?

> +#else
> writeb(val % 16, >rest.value);
> +#endif
>  }
>
>  #ifndef CONFIG_SPL_BUILD
> @@ -148,7 +161,11 @@ static int s5p_serial_getc(struct udevice *dev)
> return -EAGAIN;
>
> serial_err_check(uart, 0);
> 

Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

2021-09-18 Thread Bin Meng
Hi Mark,

On Sat, Sep 18, 2021 at 9:55 PM Mark Kettenis  wrote:
>
> Add support for Apple's M1 SoC that is used in "Apple Silicon"
> Macs.  This builds a basic U-Boot that can be used as a payload
> for the m1n1 boot loader being developed by the Asahi Linux
> project.
>
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/Kconfig|  22 
>  arch/arm/Makefile   |   1 +
>  arch/arm/mach-apple/Kconfig |  18 
>  arch/arm/mach-apple/Makefile|   4 +
>  arch/arm/mach-apple/board.c | 158 
>  arch/arm/mach-apple/lowlevel_init.S |  16 +++
>  configs/apple_m1_defconfig  |  14 +++
>  include/configs/apple.h |  38 +++
>  8 files changed, 271 insertions(+)
>  create mode 100644 arch/arm/mach-apple/Kconfig
>  create mode 100644 arch/arm/mach-apple/Makefile
>  create mode 100644 arch/arm/mach-apple/board.c
>  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
>  create mode 100644 configs/apple_m1_defconfig
>  create mode 100644 include/configs/apple.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5bd3284cd..7cdea1f615 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -895,6 +895,26 @@ config ARCH_NEXELL
> select DM
> select GPIO_EXTRA_HEADER
>
> +config ARCH_APPLE
> +   bool "Apple SoCs"
> +   select ARM64
> +   select LINUX_KERNEL_IMAGE_HEADER
> +   select POSITION_INDEPENDENT
> +   select BLK
> +   select DM
> +   select DM_KEYBOARD
> +   select DM_SERIAL
> +   select DM_USB
> +   select DM_VIDEO
> +   select CMD_USB
> +   select MISC
> +   select OF_CONTROL
> +   select OF_BOARD
> +   select USB
> +   imply CMD_DM
> +   imply CMD_GPT
> +   imply DISTRO_DEFAULTS
> +
>  config ARCH_OWL
> bool "Actions Semi OWL SoCs"
> select DM
> @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
>   image headers.
>  endif
>
> +source "arch/arm/mach-apple/Kconfig"
> +
>  source "arch/arm/mach-aspeed/Kconfig"
>
>  source "arch/arm/mach-at91/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c68e598a67..44178c204b 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
>
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
> +machine-$(CONFIG_ARCH_APPLE)   += apple
>  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
>  machine-$(CONFIG_ARCH_AT91)+= at91
>  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> new file mode 100644
> index 00..66cab91b2a
> --- /dev/null
> +++ b/arch/arm/mach-apple/Kconfig
> @@ -0,0 +1,18 @@
> +if ARCH_APPLE
> +
> +config SYS_TEXT_BASE
> +   default 0x
> +
> +config SYS_CONFIG_NAME
> +   default "apple"
> +
> +config SYS_SOC
> +   default "m1"
> +
> +config SYS_MALLOC_LEN
> +   default 0x400
> +
> +config SYS_MALLOC_F_LEN
> +   default 0x4000
> +
> +endif
> diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> new file mode 100644
> index 00..e74a8c9df1
> --- /dev/null
> +++ b/arch/arm/mach-apple/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-y += board.o
> +obj-y += lowlevel_init.o
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> new file mode 100644
> index 00..0c8b35292e
> --- /dev/null
> +++ b/arch/arm/mach-apple/board.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2021 Mark Kettenis 
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static struct mm_region apple_mem_map[] = {
> +   {
> +   /* I/O */
> +   .virt = 0x2,
> +   .phys = 0x2,
> +   .size = 8UL * SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +PTE_BLOCK_NON_SHARE |
> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x5,
> +   .phys = 0x5,
> +   .size = 2UL * SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +PTE_BLOCK_NON_SHARE |
> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x68000,
> +   .phys = 0x68000,
> +   .size = SZ_512M,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +PTE_BLOCK_NON_SHARE |
> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* PCIE */
> +   .virt = 0x6a000,
> +   .phys = 0x6a000,
> +   .size = 

Re: [PATCH] net: phy: genphy_init can be static

2021-09-18 Thread Bin Meng
On Sat, Sep 18, 2021 at 7:55 PM Vladimir Oltean  wrote:
>
> To avoid a warning with W=1 about this function not having a previous
> prototype, declare it as static, because it is not used outside of this
> translation module.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/phy/phy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


[PATCH] fdt_support.h: Remove duplicated declarations

2021-09-18 Thread Bin Meng
There are two duplicated declarations for ft_cpu_setup() and
ft_pci_setup().

Signed-off-by: Bin Meng 
---

 include/fdt_support.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/fdt_support.h b/include/fdt_support.h
index f6f46bb8e9..72a5b90c97 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -203,8 +203,6 @@ char *board_fdt_chosen_bootargs(void);
  * called at the end of the image_setup_libfdt() is to do that convertion.
  */
 void ft_board_setup_ex(void *blob, struct bd_info *bd);
-void ft_cpu_setup(void *blob, struct bd_info *bd);
-void ft_pci_setup(void *blob, struct bd_info *bd);
 
 /**
  * Add system-specific data to the FDT before booting the OS.
-- 
2.25.1



Re: [PATCH 11/11] pci: pcie_layerscape_fixup_common: lx2_board_fix_fdt can be static

2021-09-18 Thread Bin Meng
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean  wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/pci/pcie_layerscape_fixup_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 10/11] pci: pcie_layerscape_fixup_common: include fdt_support.h for ft_pci_setup

2021-09-18 Thread Bin Meng
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean  wrote:
>
> The function prototype for ft_pci_setup is inside fdt_support.h, we need
> to include that header.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/pci/pcie_layerscape_fixup_common.c | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 09/11] pci: layerscape: ls_pcie_conf_address can be static

2021-09-18 Thread Bin Meng
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean  wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/pci/pcie_layerscape_rc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 08/11] pci: _dm_pci_phys_to_bus can be static

2021-09-18 Thread Bin Meng
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean  wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/pci/pci-uclass.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 07/11] pci: pci_read_config can be static

2021-09-18 Thread Bin Meng
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean  wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/pci/pci-uclass.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 06/11] pci: pci_write_config can be static

2021-09-18 Thread Bin Meng
On Fri, Sep 17, 2021 at 8:11 PM Vladimir Oltean  wrote:
>
> To avoid W=1 build warnings, declare this function as static, since it
> is not used outside of this translation module.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/pci/pci-uclass.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


  1   2   3   4   5   6   7   8   9   10   >