Re: Passing boot logs to Linux?

[Daniel Golle]

On Thu, Dec 21, 2023 at 12:55:20AM +0100, Dragan Simic wrote:
> On 2023-12-21 00:27, Csókás Bence wrote:
> > Not every system has eMMC/uSD, and as you said, these arguments don't
> > hold for a 4 MB SPI NAND, for example, one you might find in an OpenWrt
> > router for example. Whereas RAM is quite cheap nowadays.
> 
> I see, but I also wonder how many such OpenWrt routers are still used these
> days, and, even more importantly, how many of them are regularly updated and
> can be expected to actually use this new feature?

Avoid flash writes is a very important matter, even on systems with
128 MiB of SPI-NAND flash which is by far the most common setup you
find on off-the-shelf plastic routers and access points nowadays.

Especially also as those devices often come without a local console,
having U-Boot's output prepended to dmesg on boot would be a very big
win.

> 
> Please, don't get me wrong, I still support having both options available,
> but I'm also wondering about the target demographic.
> 
> > > > Plus, I don't want the console subsystem to depend on any file/disk
> > > > operations/drivers.
> > > 
> > > Well, the console would still work as usual even if logging to disk
> > > would fail for any reason, which is similar to the serial console
> > > still
> > > working if the graphical console fails.  Moreover, if the disk fails,
> > > the system isn't be able to boot, so any RAM-based console logs
> > > would be
> > > lost in that case.  All this makes the RAM-based logging no more
> > > resilient to disk failures.
> > 
> > Correction: if disk *reads* fail, as well as writes, then the system
> > will not boot. However, typical failure of Flash media is that it
> > becomes read-only.
> 
> That's a good point, but having a read-only root filesystem usually also
> means having a non-operational system that can only have its stored data
> salvaged.  Unless the system is specifically crafted to survive such
> scenarios, of course.

... which holds true for any decent embedded OS, which at least allows
limited remote access and some kind of recovery even in this situation.

> 
> > > I still think that using disk-based pstore is a better option.  Just
> > > as
> > > you don't want to wear out your flash disks with 30-40 KB of data, I
> > > also don't want to waste 30-40 KB of RAM.
> > 
> > As I said, you could just unload the log after you're done processing
> > it. 40 KB RAM is less, than what `sshd` uses, for instance (860k on my
> > laptop, but it can probably be less, maybe even 10x less, so 80-90k?),
> > so you could, in your init, process the in-RAM log, then unload it, then
> > start your other services, thereby reclaiming that RAM.
> 
> Using pstore should have that unloading already covered, and the already
> existing systemd service is there to perform the archiving to the primary
> filesystem, if desired so.  It would all need to be tested in detail, of
> course.

pstore/ramoops uses a statically assigned reserved memory region, so in
the moment you want to use that feature you loose that amount of RAM (a
few kB, so it doesn't really matter on modern systems).
As in: there is *no* dynamic allocation.

Imho using pstore/ramoops (which is a more or less Linux-specific
debugging feature, meant to store one or more timestamped logs of
crashes) might not be the most suitable choice. I understand the
advantages of using existing infrastructure, but on the other hand
we don't need most of the complexity of pstore for the task.

What I'd like to see is having a couple of log lines from U-Boot
prepended to Linux' dmesg buffer, and for that we anyway will have to
come up with a way to hand over that buffer. Another reserved-memory
region would be one way, embedding the buffer as a blob into the
/chosen/ section of the device tree would be another way.

Re: Passing boot logs to Linux?

[Daniel Golle]

Hi Bence,

On Tue, Dec 19, 2023 at 08:08:48PM +, Csókás Bence wrote:
> Hi!
> 
> Is passing the U-Boot boot log to Linux supported yet? We are working 
> with a third-party solution, which works, but is a bit hacky, so I was 
> wondering if an official solution has been merged yet.
> 
> I saw that there was an option CONFIG_CONSOLE_RECORD that saves 
> everything to a membuff, but I don't know if that can be exported to 
> Linux yet. And if not in the tree yet, would such a patch be welcome?

To me this sounds very useful and definitely something we'd like to
have in OpenWrt. So I'd volunteer to review and test your patches once
they are ready.

What comes to mind is that CONFIG_CONSOLE_RECORD also captures ANSI
sequences during menu or count-down before boot, so we'd have to either
introduce a dedicated log_printf() call and use that when ever we want
the output to also become part of the log buffer or we could somehow
filter the recorded console, eliminating all terminal control sequences.


Cheers


Daniel

[PATCH] configs: set CONFIG_LMB_MAX_REGIONS=64 for MT7988 boards

[Daniel Golle]

Similar to MT7981 and MT7986 also MT7988 can have a high number of
reserved-memory regions used by the various hardware offloading
subsystems.

Raise CONFIG_LMB_MAX_REGIONS to 64 to avoid errors when trying to boot
Linux with more then 6 reserved regions:

ERROR: reserving fdt memory region failed (addr=4f70 size=24 flags=4)
ERROR: reserving fdt memory region failed (addr=15194000 size=1000 flags=4)
ERROR: reserving fdt memory region failed (addr=15294000 size=1000 flags=4)
ERROR: reserving fdt memory region failed (addr=15394000 size=1000 flags=4)
ERROR: Failed to allocate 0xb161 bytes below 0x8000.
device tree - allocation error

Fixes: bc4adc97cfb ("board: mediatek: add MT7988 reference boards")
Reported-by: Lorenzo Bianconi 
Signed-off-by: Daniel Golle 
---
 configs/mt7988_rfb_defconfig| 1 +
 configs/mt7988_sd_rfb_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/mt7988_rfb_defconfig b/configs/mt7988_rfb_defconfig
index dc97bb36ea..ced52edecf 100644
--- a/configs/mt7988_rfb_defconfig
+++ b/configs/mt7988_rfb_defconfig
@@ -81,3 +81,4 @@ CONFIG_MTK_SPIM=y
 CONFIG_LZO=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7988_sd_rfb_defconfig b/configs/mt7988_sd_rfb_defconfig
index 421999da86..670f5eae18 100644
--- a/configs/mt7988_sd_rfb_defconfig
+++ b/configs/mt7988_sd_rfb_defconfig
@@ -69,3 +69,4 @@ CONFIG_MTK_SPIM=y
 CONFIG_LZO=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
-- 
2.41.0

Re: [PATCH] arm: dts: medaitek: convert gmac link mode to 2500base-x for mt7986a-bpi-r3-sd

[Daniel Golle]

On Fri, Aug 04, 2023 at 09:01:55AM +0800, Weijie Gao wrote:
> The mt7531 of bpi-r3 is connected to mt7986 with 2.5Gbps HSGMII, not the
> regular 1Gbps SGMII.
> 
> Signed-off-by: Weijie Gao 

Reviewed-by: Daniel Golle 

> ---
> This is a supplement to commit:
> aef54ea1 (arm: dts: medaitek: convert gmac link mode to 2500base-x)
> ---
>  arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts 
> b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> index 15256302b8..c156a81363 100644
> --- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> +++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> @@ -76,12 +76,12 @@
>   {
>   status = "okay";
>   mediatek,gmac-id = <0>;
> - phy-mode = "sgmii";
> + phy-mode = "2500base-x";
>   mediatek,switch = "mt7531";
>   reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
>  
>   fixed-link {
> - speed = <1000>;
> + speed = <2500>;
>   full-duplex;
>   };
>  };
> -- 
> 2.17.1
> 

[PATCH] ram: mediatek: mt7629: include

[Daniel Golle]

Something between U-Boot 2023.04 and 2023.07.02 resulted in no longer
implicitely including  in the DDR3 RAM driver for the
MT7929 SoC. The result is a build failure:
drivers/ram/mediatek/ddr3-mt7629.c: In function 'mtk_ddr3_get_info':
drivers/ram/mediatek/ddr3-mt7629.c:734:30: error: 'SZ_128M' undeclared (first 
use in this function)
  734 | info->size = SZ_128M;
  |  ^~~
drivers/ram/mediatek/ddr3-mt7629.c:734:30: note: each undeclared identifier is 
reported only once for each function it appears in
drivers/ram/mediatek/ddr3-mt7629.c:737:30: error: 'SZ_256M' undeclared (first 
use in this function)
  737 | info->size = SZ_256M;
  |  ^~~
drivers/ram/mediatek/ddr3-mt7629.c:740:30: error: 'SZ_512M' undeclared (first 
use in this function)
  740 | info->size = SZ_512M;
  |  ^~~
drivers/ram/mediatek/ddr3-mt7629.c:743:30: error: 'SZ_1G' undeclared (first use 
in this function)
  743 | info->size = SZ_1G;
  |  ^

Include  so SZ_* is defined.

Reported-by: Tianling Shen 
Signed-off-by: Daniel Golle 
---
 drivers/ram/mediatek/ddr3-mt7629.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ram/mediatek/ddr3-mt7629.c 
b/drivers/ram/mediatek/ddr3-mt7629.c
index 1737fdac970..f65fcf179cf 100644
--- a/drivers/ram/mediatek/ddr3-mt7629.c
+++ b/drivers/ram/mediatek/ddr3-mt7629.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* EMI */
 #define EMI_CONA   0x000
-- 
2.41.0

[PATCH] pinctrl: mediatek: set R1/R0 in case pullen/pullsel succeeded

[Daniel Golle]

Commit dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and
related functions") changed the logic deciding to set R0 and R1
registers for V1 devices.

Before:
/* Also set PUPD/R0/R1 if the pin has them */
err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup);
if (err != -EINVAL) {
mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0);
mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1);
}

After:
/* try pupd_r1_r0 if pullen_pullsel return error */
err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup,
  val);
if (err)
return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable,
   pullup, val);

Tracing mtk_pinconf_bias_set_pullen_pullsel shows that the function
always either returns 0 in case of success or -EINVAL in case any error
has occurred. Hence the logic responsible of the decision to program R0
and R1 has been inverted.

This leads to problems on BananaPi R2 (MT7623N) when booting from
SDMMC, it turns out accessing eMMC no longer works since
U-Boot 2022.07:

MT7623> mmc dev 0
Card did not respond to voltage select! : -110

The problem wasn't detected for a long time as both eMMC and SDMMC work
fine if they are used to boot from, and hence R0 and R1 were already
setup by the bootrom and/or preloader.

Fix the logic to restore the originally intended and correct behavior
and also change the descriptive comment accordingly.

Fixes: dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related 
functions")
Signed-off-by: Daniel Golle 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 4ae328699e2..23d759aa2d8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -319,10 +319,10 @@ int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin, 
bool disable,
 {
int err;
 
-   /* try pupd_r1_r0 if pullen_pullsel return error */
+   /* set pupd_r1_r0 if pullen_pullsel succeeded */
err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup,
  val);
-   if (err)
+   if (!err)
return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable,
   pullup, val);
 
-- 
2.40.0

Re: [PATCH v3 08/25] menu: Make use of CLI character processing

[Daniel Golle]

On Fri, Jan 06, 2023 at 08:52:26AM -0600, Simon Glass wrote:
> Avoid duplicating some of the escape-sequence processing here and use the
> CLI function instead.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> [...]
> diff --git a/common/menu.c b/common/menu.c
> index 7db98942a61..45f36ae3ede 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -15,6 +15,8 @@
>  
>  #include "menu.h"
>  
> +#define ansi 0

Now that I'm using U-Boot 2023.04 I noticed that this introduces a (cosmetic)
regression: The autoboot countdown in bootmenu is now longer re-written, but
instead the last menu item line is continously appended like:

U-Boot consoleHit any key to stop autoboot: 3 Hit any key to stop autoboot: 2

To regain the previous behavior one should change the line to
#define ansi 1

To me this looks a bit unfinished, as if there was some sort of
probing of the terminal capabilities supposed to happen but then
this has never been implemeneted...

[PATCH] configs: set CONFIG_LMB_MAX_REGIONS=64 for all mt798[16] boards

[Daniel Golle]

With recently added wireless offloading features in Linux [1] the
number of reserved memory regions with MediaTek SoCs supporting
offloading wireless-to-Ethernet traffic grew beyond the default (8)
which breaks booting Linux:
ERROR: Failed to allocate 0xa6ac bytes below 0xc000.
device tree - allocation error
FDT creation failed!
resetting ...

Raise CONFIG_LMB_MAX_REGIONS to 64 like it is already done for other
SoCs which require a larger number of reserved memory regions, eg.
exynos78x0 based a3y17lte, a5y17lte and a7y17lte or dragonboard845c.

[1]: 
https://lore.kernel.org/netdev/e3489a697b404bd47447190cd2e5adf090ae61c2.1667687249.git.lore...@kernel.org/
 
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=eed4f1ddad8c5ad7596b229caec8bd7b477b81ee

Signed-off-by: Daniel Golle 
---
 configs/mt7981_emmc_rfb_defconfig| 1 +
 configs/mt7981_rfb_defconfig | 1 +
 configs/mt7981_sd_rfb_defconfig  | 1 +
 configs/mt7986_rfb_defconfig | 1 +
 configs/mt7986a_bpir3_emmc_defconfig | 1 +
 configs/mt7986a_bpir3_sd_defconfig   | 1 +
 6 files changed, 6 insertions(+)

diff --git a/configs/mt7981_emmc_rfb_defconfig 
b/configs/mt7981_emmc_rfb_defconfig
index 4832a22643..b3b37b6e5e 100644
--- a/configs/mt7981_emmc_rfb_defconfig
+++ b/configs/mt7981_emmc_rfb_defconfig
@@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7981_rfb_defconfig b/configs/mt7981_rfb_defconfig
index c397527887..b7ffb4dfa7 100644
--- a/configs/mt7981_rfb_defconfig
+++ b/configs/mt7981_rfb_defconfig
@@ -64,3 +64,4 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MTK_SPIM=y
 CONFIG_HEXDUMP=y
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7981_sd_rfb_defconfig b/configs/mt7981_sd_rfb_defconfig
index 17592dc22b..85be9bbc50 100644
--- a/configs/mt7981_sd_rfb_defconfig
+++ b/configs/mt7981_sd_rfb_defconfig
@@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7986_rfb_defconfig b/configs/mt7986_rfb_defconfig
index 1363f9dc6d..ac91c93efb 100644
--- a/configs/mt7986_rfb_defconfig
+++ b/configs/mt7986_rfb_defconfig
@@ -64,3 +64,4 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_MTK_SPIM=y
 CONFIG_HEXDUMP=y
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7986a_bpir3_emmc_defconfig 
b/configs/mt7986a_bpir3_emmc_defconfig
index 354159df9b..2d4876f299 100644
--- a/configs/mt7986a_bpir3_emmc_defconfig
+++ b/configs/mt7986a_bpir3_emmc_defconfig
@@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7986a_bpir3_sd_defconfig 
b/configs/mt7986a_bpir3_sd_defconfig
index db7ef98d80..08edfe7ac4 100644
--- a/configs/mt7986a_bpir3_sd_defconfig
+++ b/configs/mt7986a_bpir3_sd_defconfig
@@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y
 CONFIG_FAT_WRITE=y
 CONFIG_HEXDUMP=y
 # CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
-- 
2.38.1

Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case

[Daniel Golle]

On Sun, Sep 04, 2022 at 12:28:24PM -0700, Tony Dinh wrote:
> Hi Pali,
> 
> On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár  wrote:
> >
> > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár  wrote:
> > > >
> > > > Do various small fixup/cleanups and extend test script to boot kernel
> > > > image from UBI volume. This test verifies that U-Boot UBI implementation
> > > > is working and U-Boot can read volume with bootable kernel code
> > > > correctly. And therefore CI prevents UBI breakage.
> > > >
> > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and
> > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to
> > > > debug this issue but I have no idea why it is failing.
> > >
> > > I've recently implemented UBI distro boot on a pair of Kirkwood boards
> > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and
> > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the
> > > u-boot distro boot scan the UBI partition to find the boot script
> > > boot.scr. And also mount it manually to look at the file system.
> >
> > Hello! I think you mean UBIFS on UBI, right?
> 
> Yes. UBIFS on UBI.
> 
> >
> > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is
> > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume
> > > allowed me to mount it in the u-boot command line. I think squashfs is
> > > incomplete in u-boot, at the moment.
> >
> > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works
> > only on UBI. I guess you could have squashfs on UBI, but on linux this
> > requires mtdblock, hence it is squashfs on mtdblock on UBI.
> 
> I meant that (the rootfs) is a squashfs inside an UBIFS volume. And
> the system running with another UBIFS volume overlaid on top of that.

Just to clarify: OpenWrt uses squashfs in UBI volumes for the compressed
rootfs. In Linux, ubiblock is used to mount them.

We also usually don't store the kernel in a filesystem but just use a
bare UBI volume to directly store the uImage.FIT to be booted, for both
simplicity and robustness reasons.
On devices with recent enough U-Boot we can use a 'filesystem'-type
sub-image of a uImage.FIT for squashfs and mount that in Linux.

> 
> Best,
> Tony
> 
> >
> > > Best,
> > > Tony
> > >
> > >
> > > >  Function
> > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and
> > > > valid because Linux kernel can successfully mount it. And to make it
> > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc
> > > > platform. So UBIFS issue is probably endian or arch specific.
> > > > (This is UBIFS related, not UBI related.)
> > > >
> > > > Pali Rohár (9):
> > > >   Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S
> > > >   Nokia RX-51: Do not clear unknown memory in lowlevel_init.S
> > > >   Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000
> > > >   Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script
> > > >   Nokia RX-51: Call bootm in test script only when image is valid
> > > >   Nokia RX-51: Fix documentation how to enable UBI support
> > > >   Nokia RX-51: Do not set useless ARCH= in test script
> > > >   Nokia RX-51: Add comment describing kernel image type into test script
> > > >   Nokia RX-51: Add booting from UBI into test script
> > > >
> > > >  board/nokia/rx51/lowlevel_init.S |  7 +--
> > > >  configs/nokia_rx51_defconfig |  2 +-
> > > >  doc/board/nokia/rx51.rst |  3 +-
> > > >  test/nokia_rx51_test.sh  | 97 +---
> > > >  4 files changed, 82 insertions(+), 27 deletions(-)
> > > >
> > > > --
> > > > 2.20.1
> > > >

Re: [PATCH v2 31/32] tools: mtk_image: add support for nand headers used by newer chips

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:26PM +0800, Weijie Gao wrote:
> This patch adds more nand headers in two new types:
> 1. HSM header, used for spi-nand thru SNFI interface
> 2. SPIM header, used for spi-nand thru spi-mem interface
> 
> The original nand header is renamed to AP header.

Tested ARM Trusted Firmware-A bl2 images generated for
Bananapi R64 (MT7622; eMMC, SDMMC, SPI-NAND),
UniFi 6 LR (MT7622; SPI-NOR) and
Bananapi BPi-R3 (MT7986A; eMMC, SDMMC, SPI-NAND, SPI-NOR).
Also tested MT7621 images still work fine on ZBT-WG3526 (MT7621; SPI-NOR).

Tested-by: Daniel Golle 

> 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  tools/mtk_image.c|  23 ++-
>  tools/mtk_nand_headers.c | 422 +--
>  tools/mtk_nand_headers.h | 110 +-
>  3 files changed, 525 insertions(+), 30 deletions(-)
> 
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index 1f7396aa69..9b3136afa3 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -33,6 +33,9 @@ static const struct brom_img_type {
>   }, {
>   .name = "snand",
>   .type = BRLYT_TYPE_SNAND
> + }, {
> + .name = "spim-nand",
> + .type = BRLYT_TYPE_SNAND
>   }
>  };
>  
> @@ -54,7 +57,7 @@ static char lk_name[32] = "U-Boot";
>  static uint32_t crc32tbl[256];
>  
>  /* NAND header selected by user */
> -static const union nand_boot_header *hdr_nand;
> +static const struct nand_header_type *hdr_nand;
>  static uint32_t hdr_nand_size;
>  
>  /* GFH header + 2 * 4KB pages of NAND */
> @@ -366,20 +369,26 @@ static int mtk_image_verify_nand_header(const uint8_t 
> *ptr, int print)
>   if (ret < 0)
>   return ret;
>  
> - bh = (struct brom_layout_header *)(ptr + info.page_size);
> + if (!ret) {
> + bh = (struct brom_layout_header *)(ptr + info.page_size);
>  
> - if (strcmp(bh->name, BRLYT_NAME))
> - return -1;
> + if (strcmp(bh->name, BRLYT_NAME))
> + return -1;
> +
> + if (le32_to_cpu(bh->magic) != BRLYT_MAGIC)
> + return -1;
>  
> - if (le32_to_cpu(bh->magic) != BRLYT_MAGIC) {
> - return -1;
> - } else {
>   if (le32_to_cpu(bh->type) == BRLYT_TYPE_NAND)
>   bootmedia = "Parallel NAND";
>   else if (le32_to_cpu(bh->type) == BRLYT_TYPE_SNAND)
>   bootmedia = "Serial NAND (SNFI/AP)";
>   else
>   return -1;
> + } else {
> + if (info.snfi)
> + bootmedia = "Serial NAND (SNFI/HSM)";
> + else
> + bootmedia = "Serial NAND (SPIM)";
>   }
>  
>   if (print) {
> diff --git a/tools/mtk_nand_headers.c b/tools/mtk_nand_headers.c
> index 12f827c39f..2fa91e7af0 100644
> --- a/tools/mtk_nand_headers.c
> +++ b/tools/mtk_nand_headers.c
> @@ -188,55 +188,346 @@ static const union nand_boot_header 
> nand_hdr_4gb_2k_128_data = {
>   }
>  };
>  
> -static const struct nand_header_type {
> +/* HSM BROM NAND header for SPI NAND with 2KB page + 64B spare */
> +static const union hsm_nand_boot_header hsm_nand_hdr_2k_64_data = {
> + .data = {
> + 0x4E, 0x41, 0x4E, 0x44, 0x43, 0x46, 0x47, 0x21,
> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x04, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x08, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00,
> + 0x40, 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00,
> + 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
> + 0xFF, 0x00, 0x00, 0x00, 0x21, 0xD2, 0xEE, 0xF6,
> + 0xAE, 0xDD, 0x5E, 0xC2, 0x82, 0x8E, 0x9A, 0x62,
> + 0x09, 0x8E, 0x80, 0xE2, 0x37, 0x0D, 0xC9, 0xFA,
> + 0xA9, 0xDD, 0xFC, 0x92, 0x34, 0x2A, 0xED, 0x51,
> + 0xA4, 0x1B, 0xF7, 0x63, 0xCC, 0x5A, 0xC7, 0xFB,
> + 0xED, 0x21, 0x02, 0x23, 0x51, 0x31
> + }
> +};
> +
> +/* HSM BROM NAND header for SPI NAND with 2KB page + 128B spare */
> +static const union hsm_nand_boot_header hsm_nand_hdr_2k_128_data = {
> + .data = {
> +  

Re: [PATCH v2 30/32] tools: mtk_image: split the code of generating NAND header into a new file

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:24PM +0800, Weijie Gao wrote:
> The predefined NAND headers take too much spaces in the mtk_image.c.
> Moving them into a new file can significantly improve the readability of
> both mtk_image.c and the new mtk_nand_headers.c.
> 
> This is a preparation for adding more NAND headers.

Tested ARM Trusted Firmware-A bl2 images generated for
Bananapi R64 (MT7622; eMMC, SDMMC, SPI-NAND),
UniFi 6 LR (MT7622; SPI-NOR) and
Bananapi BPi-R3 (MT7986A; eMMC, SDMMC, SPI-NAND, SPI-NOR).
Also tested MT7621 images still work fine on ZBT-WG3526 (MT7621; SPI-NOR).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Add comments
>   Call mtk_nand_header_size only for NAND/SNAND to avoid NULL pointer access
> ---
>  tools/Makefile   |   1 +
>  tools/mtk_image.c| 305 ++-
>  tools/mtk_image.h|  25 
>  tools/mtk_nand_headers.c | 286 
>  tools/mtk_nand_headers.h |  61 
>  5 files changed, 389 insertions(+), 289 deletions(-)
>  create mode 100644 tools/mtk_nand_headers.c
>  create mode 100644 tools/mtk_nand_headers.h
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 3626919633..34a1aa7a8b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -147,6 +147,7 @@ dumpimage-mkimage-objs := aisimage.o \
>   gpimage.o \
>   gpimage-common.o \
>   mtk_image.o \
> + mtk_nand_headers.o \
>   $(ECDSA_OBJS-y) \
>   $(RSA_OBJS-y) \
>   $(AES_OBJS-y)
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index dcd6525f32..1f7396aa69 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -12,216 +12,7 @@
>  #include 
>  #include "imagetool.h"
>  #include "mtk_image.h"
> -
> -/* NAND header for SPI-NAND with 2KB page + 64B spare */
> -static const union nand_boot_header snand_hdr_2k_64_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x03, 0x00, 0x40, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x7B, 0xC4, 0x17, 0x9D,
> - 0xCA, 0x42, 0x90, 0xD0, 0x98, 0xD0, 0xE0, 0xF7,
> - 0xDB, 0xCD, 0x16, 0xF6, 0x03, 0x73, 0xD2, 0xB8,
> - 0x93, 0xB2, 0x56, 0x5A, 0x84, 0x6E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 2KB page + 120B/128B spare */
> -static const union nand_boot_header snand_hdr_2k_128_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x05, 0x00, 0x70, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x90, 0x28, 0xED, 0x13,
> - 0x7F, 0x12, 0x22, 0xCD, 0x3D, 0x06, 0xF1, 0xB3,
> - 0x6F, 0x2E, 0xD9, 0xA0, 0x9D, 0x7A, 0xBD, 0xD7,
> - 0xB3, 0x28, 0x3C, 0x13, 0xDB, 0x4E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 4KB page + 256B spare */
> -static const union nand_boot_header snand_hdr_4k_256_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x10, 0x05, 0x00, 0xE0, 0x00

Re: [PATCH v2 29/32] tools: mtk_image: split gfh header verification into a new function

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:22PM +0800, Weijie Gao wrote:
> The verification code of gfh header for NAND and non-NAND are identical.
> It's better to define a individual function to reduce redundancy.

Tested ARM Trusted Firmware-A bl2 images generated for
Bananapi R64 (MT7622; eMMC, SDMMC, SPI-NAND),
UniFi 6 LR (MT7622; SPI-NOR) and
Bananapi BPi-R3 (MT7986A; eMMC, SDMMC, SPI-NAND, SPI-NOR).
Also tested MT7621 images still work fine on ZBT-WG3526 (MT7621; SPI-NOR).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  tools/mtk_image.c | 51 +++
>  1 file changed, 21 insertions(+), 30 deletions(-)
> 
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index de5ce4d964..dcd6525f32 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -480,6 +480,25 @@ static int mtk_image_vrec_header(struct 
> image_tool_params *params,
>   return SHA256_SUM_LEN;
>  }
>  
> +static int mtk_image_verify_gfh(struct gfh_header *gfh, uint32_t type, int 
> print)
> +{
> + if (strcmp(gfh->file_info.name, GFH_FILE_INFO_NAME))
> + return -1;
> +
> + if (le32_to_cpu(gfh->file_info.flash_type) != type)
> + return -1;
> +
> + if (print)
> + printf("Load Address: %08x\n",
> +le32_to_cpu(gfh->file_info.load_addr) +
> +le32_to_cpu(gfh->file_info.jump_offset));
> +
> + if (print)
> + printf("Architecture: %s\n", is_arm64_image ? "ARM64" : "ARM");
> +
> + return 0;
> +}
> +
>  static int mtk_image_verify_gen_header(const uint8_t *ptr, int print)
>  {
>   union gen_boot_header *gbh = (union gen_boot_header *)ptr;
> @@ -542,21 +561,7 @@ static int mtk_image_verify_gen_header(const uint8_t 
> *ptr, int print)
>  
>   gfh = (struct gfh_header *)(ptr + gfh_offset);
>  
> - if (strcmp(gfh->file_info.name, GFH_FILE_INFO_NAME))
> - return -1;
> -
> - if (le32_to_cpu(gfh->file_info.flash_type) != GFH_FLASH_TYPE_GEN)
> - return -1;
> -
> - if (print)
> - printf("Load Address: %08x\n",
> -le32_to_cpu(gfh->file_info.load_addr) +
> -le32_to_cpu(gfh->file_info.jump_offset));
> -
> - if (print)
> - printf("Architecture: %s\n", is_arm64_image ? "ARM64" : "ARM");
> -
> - return 0;
> + return mtk_image_verify_gfh(gfh, GFH_FLASH_TYPE_GEN, print);
>  }
>  
>  static int mtk_image_verify_nand_header(const uint8_t *ptr, int print)
> @@ -610,21 +615,7 @@ static int mtk_image_verify_nand_header(const uint8_t 
> *ptr, int print)
>  
>   gfh = (struct gfh_header *)(ptr + 2 * le16_to_cpu(nh->pagesize));
>  
> - if (strcmp(gfh->file_info.name, GFH_FILE_INFO_NAME))
> - return -1;
> -
> - if (le32_to_cpu(gfh->file_info.flash_type) != GFH_FLASH_TYPE_NAND)
> - return -1;
> -
> - if (print)
> - printf("Load Address: %08x\n",
> -le32_to_cpu(gfh->file_info.load_addr) +
> -le32_to_cpu(gfh->file_info.jump_offset));
> -
> - if (print)
> - printf("Architecture: %s\n", is_arm64_image ? "ARM64" : "ARM");
> -
> - return 0;
> + return mtk_image_verify_gfh(gfh, GFH_FLASH_TYPE_NAND, print);
>  }
>  
>  static uint32_t crc32be_cal(const void *data, size_t length)
> -- 
> 2.17.1
> 

Re: [PATCH v2 28/32] cpu: add basic cpu driver for MediaTek ARM chips

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:20PM +0800, Weijie Gao wrote:
> Add basic CPU driver used to retrieve CPU model information.
> 

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> Signed-off-by: Weijie Gao 
> ---
>   v2 changes: new
> ---
>  drivers/cpu/Makefile  |   1 +
>  drivers/cpu/mtk_cpu.c | 106 ++
>  2 files changed, 107 insertions(+)
>  create mode 100644 drivers/cpu/mtk_cpu.c
> 
> diff --git a/drivers/cpu/Makefile b/drivers/cpu/Makefile
> index 20884b1795..3b38ba9c58 100644
> --- a/drivers/cpu/Makefile
> +++ b/drivers/cpu/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_CPU) += cpu-uclass.o
>  obj-$(CONFIG_ARCH_BMIPS) += bmips_cpu.o
>  obj-$(CONFIG_ARCH_IMX8) += imx8_cpu.o
>  obj-$(CONFIG_ARCH_AT91) += at91_cpu.o
> +obj-$(CONFIG_ARCH_MEDIATEK) += mtk_cpu.o
>  obj-$(CONFIG_CPU_MPC83XX) += mpc83xx_cpu.o
>  obj-$(CONFIG_CPU_RISCV) += riscv_cpu.o
>  obj-$(CONFIG_CPU_MICROBLAZE) += microblaze_cpu.o
> diff --git a/drivers/cpu/mtk_cpu.c b/drivers/cpu/mtk_cpu.c
> new file mode 100644
> index 00..d00b4c669e
> --- /dev/null
> +++ b/drivers/cpu/mtk_cpu.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 MediaTek Inc. All rights reserved.
> + *
> + * Author: Weijie Gao 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct mtk_cpu_plat {
> + void __iomem *hwver_base;
> +};
> +
> +static int mtk_cpu_get_desc(const struct udevice *dev, char *buf, int size)
> +{
> + struct mtk_cpu_plat *plat = dev_get_plat(dev);
> +
> + snprintf(buf, size, "MediaTek MT%04X", readl(plat->hwver_base));
> +
> + return 0;
> +}
> +
> +static int mtk_cpu_get_count(const struct udevice *dev)
> +{
> + return 1;
> +}
> +
> +static int mtk_cpu_get_vendor(const struct udevice *dev, char *buf, int size)
> +{
> + snprintf(buf, size, "MediaTek");
> +
> + return 0;
> +}
> +
> +static int mtk_cpu_probe(struct udevice *dev)
> +{
> + struct mtk_cpu_plat *plat = dev_get_plat(dev);
> + const void *fdt = gd->fdt_blob, *reg;
> + int offset, parent, len, na, ns;
> + u64 addr;
> +
> + if (!fdt)
> + return -ENODEV;
> +
> + offset = fdt_path_offset(fdt, "/hwver");
> + if (offset < 0)
> + return -ENODEV;
> +
> + parent = fdt_parent_offset(fdt, offset);
> + if (parent < 0)
> + return -ENODEV;
> +
> + na = fdt_address_cells(fdt, parent);
> + if (na < 1)
> + return -ENODEV;
> +
> + ns = fdt_size_cells(gd->fdt_blob, parent);
> + if (ns < 0)
> + return -ENODEV;
> +
> + reg = fdt_getprop(gd->fdt_blob, offset, "reg", );
> + if (!reg)
> + return -ENODEV;
> +
> + if (ns)
> + addr = fdt_translate_address(fdt, offset, reg);
> + else
> + addr = fdt_read_number(reg, na);
> +
> + plat->hwver_base = map_sysmem(addr, 0);
> + if (!plat->hwver_base)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static const struct cpu_ops mtk_cpu_ops = {
> + .get_desc   = mtk_cpu_get_desc,
> + .get_count  = mtk_cpu_get_count,
> + .get_vendor = mtk_cpu_get_vendor,
> +};
> +
> +static const struct udevice_id mtk_cpu_ids[] = {
> + { .compatible = "arm,cortex-a7" },
> + { .compatible = "arm,cortex-a53" },
> + { .compatible = "arm,cortex-a73" },
> + { /* sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(cpu_mtk) = {
> + .name   = "mtk-cpu",
> + .id = UCLASS_CPU,
> + .of_match   = mtk_cpu_ids,
> + .ops= _cpu_ops,
> + .probe  = mtk_cpu_probe,
> + .plat_auto  = sizeof(struct mtk_cpu_plat),
> + .flags  = DM_FLAG_PRE_RELOC,
> +};
> -- 
> 2.17.1
> 

Re: [PATCH v2 26/32] clk: mediatek: add clock driver support for MediaTek MT7986 SoC

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:13PM +0800, Weijie Gao wrote:
> This patch adds clock driver support for MediaTek MT7986 SoC

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Sean Anderson 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Fix coding style
> ---
>  drivers/clk/mediatek/Makefile  |   1 +
>  drivers/clk/mediatek/clk-mt7986.c  | 672 +
>  include/dt-bindings/clock/mt7986-clk.h | 249 +
>  3 files changed, 922 insertions(+)
>  create mode 100644 drivers/clk/mediatek/clk-mt7986.c
>  create mode 100644 include/dt-bindings/clock/mt7986-clk.h
> 
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 522e724221..1aa38215bf 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_MT8512) += clk-mt8512.o
>  obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
>  obj-$(CONFIG_TARGET_MT7622) += clk-mt7622.o
>  obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
> +obj-$(CONFIG_TARGET_MT7986) += clk-mt7986.o
>  obj-$(CONFIG_TARGET_MT8183) += clk-mt8183.o
>  obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
>  obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
> diff --git a/drivers/clk/mediatek/clk-mt7986.c 
> b/drivers/clk/mediatek/clk-mt7986.c
> new file mode 100644
> index 00..b3fa63fc0a
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7986.c
> @@ -0,0 +1,672 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek clock driver for MT7986 SoC
> + *
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clk-mtk.h"
> +
> +#define MT7986_CLK_PDN 0x250
> +#define MT7986_CLK_PDN_EN_WRITE BIT(31)
> +
> +#define PLL_FACTOR(_id, _name, _parent, _mult, _div) 
>   \
> + FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
> +
> +#define TOP_FACTOR(_id, _name, _parent, _mult, _div) 
>   \
> + FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
> +
> +#define INFRA_FACTOR(_id, _name, _parent, _mult, _div)   
>   \
> + FACTOR(_id, _parent, _mult, _div, CLK_PARENT_INFRASYS)
> +
> +/* FIXED PLLS */
> +static const struct mtk_fixed_clk fixed_pll_clks[] = {
> + FIXED_CLK(CK_APMIXED_ARMPLL, CLK_XTAL, 20),
> + FIXED_CLK(CK_APMIXED_NET2PLL, CLK_XTAL, 8),
> + FIXED_CLK(CK_APMIXED_MMPLL, CLK_XTAL, 144000),
> + FIXED_CLK(CK_APMIXED_SGMPLL, CLK_XTAL, 32500),
> + FIXED_CLK(CK_APMIXED_WEDMCUPLL, CLK_XTAL, 76000),
> + FIXED_CLK(CK_APMIXED_NET1PLL, CLK_XTAL, 25),
> + FIXED_CLK(CK_APMIXED_MPLL, CLK_XTAL, 41600),
> + FIXED_CLK(CK_APMIXED_APLL2, CLK_XTAL, 196608000),
> +};
> +
> +/* TOPCKGEN FIXED CLK */
> +static const struct mtk_fixed_clk top_fixed_clks[] = {
> + FIXED_CLK(CK_TOP_CB_CKSQ_40M, CLK_XTAL, 4000),
> +};
> +
> +/* TOPCKGEN FIXED DIV */
> +static const struct mtk_fixed_factor top_fixed_divs[] = {
> + PLL_FACTOR(CK_TOP_CB_M_416M, "cb_m_416m", CK_APMIXED_MPLL, 1, 1),
> + PLL_FACTOR(CK_TOP_CB_M_D2, "cb_m_d2", CK_APMIXED_MPLL, 1, 2),
> + PLL_FACTOR(CK_TOP_CB_M_D4, "cb_m_d4", CK_APMIXED_MPLL, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_M_D8, "cb_m_d8", CK_APMIXED_MPLL, 1, 8),
> + PLL_FACTOR(CK_TOP_M_D8_D2, "m_d8_d2", CK_APMIXED_MPLL, 1, 16),
> + PLL_FACTOR(CK_TOP_M_D3_D2, "m_d3_d2", CK_APMIXED_MPLL, 1, 2),
> + PLL_FACTOR(CK_TOP_CB_MM_D2, "cb_mm_d2", CK_APMIXED_MMPLL, 1, 2),
> + PLL_FACTOR(CK_TOP_CB_MM_D4, "cb_mm_d4", CK_APMIXED_MMPLL, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_MM_D8, "cb_mm_d8", CK_APMIXED_MMPLL, 1, 8),
> + PLL_FACTOR(CK_TOP_MM_D8_D2, "mm_d8_d2", CK_APMIXED_MMPLL, 1, 16),
> + PLL_FACTOR(CK_TOP_MM_D3_D8, "mm_d3_d8", CK_APMIXED_MMPLL, 1, 8),
> + PLL_FACTOR(CK_TOP_CB_U2_PHYD_CK, "cb_u2_phyd", CK_APMIXED_MMPLL, 1, 30),
> + PLL_FACTOR(CK_TOP_CB_APLL2_196M, "cb_apll2_196m", CK_APMIXED_APLL2, 1,
> +1),
> + PLL_FACTOR(CK_TOP_APLL2_D4, "apll2_d4", CK_APMIXED_APLL2, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_NET1_D4, "cb_net1_d4", CK_APMIXED_NET1PLL, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_NET1_D5, "cb_net1_d5", CK_APMIXED_NET1PLL, 1, 5),
> + PLL_FACTOR(CK_TOP_NET1_D5_D2, "net1_d5_d2", CK_APMIXED_NET1PLL, 1, 10),
> + PLL_FACTOR(CK_TOP_NET1_D5_D4, "net1_d5_d4", CK_APMIXED_NET1PLL, 1, 20),
> + PLL_FACTOR(CK_TOP_NET1_

Re: [PATCH v2 25/32] clk: mediatek: add CLK_XTAL support for clock driver

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:11PM +0800, Weijie Gao wrote:
> This adds the CLK_XTAL macro/flag to allow modeling clocks which are
> directly connected to the xtal clock.

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Fix incorrect fallback in mtk_infrasys_get_factor_rate
>   Fix commit description
> ---
>  drivers/clk/mediatek/clk-mtk.c | 4 
>  drivers/clk/mediatek/clk-mtk.h | 3 ++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 207a4c6b11..4303300d3a 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -296,6 +296,7 @@ static ulong mtk_topckgen_get_factor_rate(struct clk 
> *clk, u32 off)
>   rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
>   break;
>  
> + case CLK_PARENT_XTAL:
>   default:
>   rate = priv->tree->xtal_rate;
>   }
> @@ -314,6 +315,9 @@ static ulong mtk_infrasys_get_factor_rate(struct clk 
> *clk, u32 off)
>   rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
>   priv->parent);
>   break;
> + case CLK_PARENT_XTAL:
> + rate = priv->tree->xtal_rate;
> + break;
>   default:
>   rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
>   }
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index e7c61ae483..48ce16484e 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -29,7 +29,8 @@
>  #define CLK_PARENT_APMIXED   BIT(4)
>  #define CLK_PARENT_TOPCKGEN  BIT(5)
>  #define CLK_PARENT_INFRASYS  BIT(6)
> -#define CLK_PARENT_MASK  GENMASK(6, 4)
> +#define CLK_PARENT_XTAL  BIT(7)
> +#define CLK_PARENT_MASK  GENMASK(7, 4)
>  
>  #define ETHSYS_HIFSYS_RST_CTRL_OFS   0x34
>  
> -- 
> 2.17.1
> 

Re: [PATCH v2 24/32] clk: mediatek: add infrasys clock mux support

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:09PM +0800, Weijie Gao wrote:
> This patch adds infrasys clock mux support for mediatek clock drivers.

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Fix the if condition of CLK_BYPASS_XTAL
> ---
>  drivers/clk/mediatek/clk-mtk.c | 71 ++
>  drivers/clk/mediatek/clk-mtk.h |  4 +-
>  2 files changed, 74 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index a537ff259f..207a4c6b11 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -303,6 +303,24 @@ static ulong mtk_topckgen_get_factor_rate(struct clk 
> *clk, u32 off)
>   return mtk_factor_recalc_rate(fdiv, rate);
>  }
>  
> +static ulong mtk_infrasys_get_factor_rate(struct clk *clk, u32 off)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> + const struct mtk_fixed_factor *fdiv = >tree->fdivs[off];
> + ulong rate;
> +
> + switch (fdiv->flags & CLK_PARENT_MASK) {
> + case CLK_PARENT_TOPCKGEN:
> + rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
> + priv->parent);
> + break;
> + default:
> + rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
> + }
> +
> + return mtk_factor_recalc_rate(fdiv, rate);
> +}
> +
>  static ulong mtk_topckgen_get_mux_rate(struct clk *clk, u32 off)
>  {
>   struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> @@ -331,6 +349,33 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk, 
> u32 off)
>   return priv->tree->xtal_rate;
>  }
>  
> +static ulong mtk_infrasys_get_mux_rate(struct clk *clk, u32 off)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> + const struct mtk_composite *mux = >tree->muxes[off];
> + u32 index;
> +
> + index = readl(priv->base + mux->mux_reg);
> + index &= mux->mux_mask << mux->mux_shift;
> + index = index >> mux->mux_shift;
> +
> + if (mux->parent[index] > 0 ||
> + (mux->parent[index] == CLK_XTAL &&
> +  priv->tree->flags & CLK_BYPASS_XTAL)) {
> + switch (mux->flags & CLK_PARENT_MASK) {
> + case CLK_PARENT_TOPCKGEN:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + priv->parent);
> + break;
> + default:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + NULL);
> + break;
> + }
> + }
> + return 0;
> +}
> +
>  static ulong mtk_topckgen_get_rate(struct clk *clk)
>  {
>   struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> @@ -345,6 +390,25 @@ static ulong mtk_topckgen_get_rate(struct clk *clk)
>priv->tree->muxes_offs);
>  }
>  
> +static ulong mtk_infrasys_get_rate(struct clk *clk)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> +
> + ulong rate;
> +
> + if (clk->id < priv->tree->fdivs_offs) {
> + rate = priv->tree->fclks[clk->id].rate;
> + } else if (clk->id < priv->tree->muxes_offs) {
> + rate = mtk_infrasys_get_factor_rate(clk, clk->id -
> + priv->tree->fdivs_offs);
> + } else {
> + rate = mtk_infrasys_get_mux_rate(clk, clk->id -
> +  priv->tree->muxes_offs);
> + }
> +
> + return rate;
> +}
> +
>  static int mtk_clk_mux_enable(struct clk *clk)
>  {
>   struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> @@ -493,6 +557,13 @@ const struct clk_ops mtk_clk_topckgen_ops = {
>   .set_parent = mtk_common_clk_set_parent,
>  };
>  
> +const struct clk_ops mtk_clk_infrasys_ops = {
> + .enable = mtk_clk_mux_enable,
> + .disable = mtk_clk_mux_disable,
> + .get_rate = mtk_infrasys_get_rate,
> + .set_parent = mtk_common_clk_set_parent,
> +};
> +
>  const struct clk_ops mtk_clk_gate_ops = {
>   .enable = mtk_clk_gate_enable,
>   .disable = mtk_clk_gate_disable,
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 41854879c6..e7c61ae483 100644
> --- a/drivers/clk/mediatek/c

Re: [PATCH v2 23/32] clk: mediatek: add support to configure clock driver parent

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:05:06PM +0800, Weijie Gao wrote:
> This patch adds support for a clock node to configure its parent clock
> where possible.

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  drivers/clk/mediatek/clk-mtk.c | 79 --
>  drivers/clk/mediatek/clk-mtk.h |  2 +
>  2 files changed, 48 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 7d145f4975..a537ff259f 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -42,20 +42,14 @@
>   * the accurate frequency.
>   */
>  static ulong mtk_clk_find_parent_rate(struct clk *clk, int id,
> -   const struct driver *drv)
> +   struct udevice *pdev)
>  {
>   struct clk parent = { .id = id, };
>  
> - if (drv) {
> - struct udevice *dev;
> -
> - if (uclass_get_device_by_driver(UCLASS_CLK, drv, ))
> - return -ENODEV;
> -
> - parent.dev = dev;
> - } else {
> + if (pdev)
> + parent.dev = pdev;
> + else
>   parent.dev = clk->dev;
> - }
>  
>   return clk_get_rate();
>  }
> @@ -296,7 +290,7 @@ static ulong mtk_topckgen_get_factor_rate(struct clk 
> *clk, u32 off)
>   switch (fdiv->flags & CLK_PARENT_MASK) {
>   case CLK_PARENT_APMIXED:
>   rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
> - DM_DRIVER_GET(mtk_clk_apmixedsys));
> + priv->parent);
>   break;
>   case CLK_PARENT_TOPCKGEN:
>   rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
> @@ -321,9 +315,18 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk, 
> u32 off)
>  
>   if (mux->parent[index] > 0 ||
>   (mux->parent[index] == CLK_XTAL &&
> -  priv->tree->flags & CLK_BYPASS_XTAL))
> - return mtk_clk_find_parent_rate(clk, mux->parent[index],
> - NULL);
> +  priv->tree->flags & CLK_BYPASS_XTAL)) {
> + switch (mux->flags & CLK_PARENT_MASK) {
> + case CLK_PARENT_APMIXED:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + priv->parent);
> + break;
> + default:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + NULL);
> + break;
> + }
> + }
>  
>   return priv->tree->xtal_rate;
>  }
> @@ -342,7 +345,7 @@ static ulong mtk_topckgen_get_rate(struct clk *clk)
>priv->tree->muxes_offs);
>  }
>  
> -static int mtk_topckgen_enable(struct clk *clk)
> +static int mtk_clk_mux_enable(struct clk *clk)
>  {
>   struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
>   const struct mtk_composite *mux;
> @@ -375,7 +378,7 @@ static int mtk_topckgen_enable(struct clk *clk)
>   return 0;
>  }
>  
> -static int mtk_topckgen_disable(struct clk *clk)
> +static int mtk_clk_mux_disable(struct clk *clk)
>  {
>   struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
>   const struct mtk_composite *mux;
> @@ -401,7 +404,7 @@ static int mtk_topckgen_disable(struct clk *clk)
>   return 0;
>  }
>  
> -static int mtk_topckgen_set_parent(struct clk *clk, struct clk *parent)
> +static int mtk_common_clk_set_parent(struct clk *clk, struct clk *parent)
>  {
>   struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
>  
> @@ -473,19 +476,7 @@ static ulong mtk_clk_gate_get_rate(struct clk *clk)
>   struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
>   const struct mtk_gate *gate = >gates[clk->id];
>  
> - switch (gate->flags & CLK_PARENT_MASK) {
> - case CLK_PARENT_APMIXED:
> - return mtk_clk_find_parent_rate(clk, gate->parent,
> - DM_DRIVER_GET(mtk_clk_apmixedsys));
> - break;
> - case CLK_PARENT_TOPCKGEN:
> - return mtk_clk_find_parent_rate(clk, gate->parent,
> - DM_DRIVER_GET(mtk_clk_topckgen));
> - break;
> -
> - default:
> - return priv->tree->xtal_rate;
> - }
> + 

Re: [PATCH v2 22/32] clk: mediatek: add CLK_BYPASS_XTAL flag to allow bypassing searching clock parent of xtal clock

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:59PM +0800, Weijie Gao wrote:
> The mtk clock framework in u-boot uses array index for searching clock
> parent (kernel uses strings for search), so we need to specify a special
> clock with ID=0 for CLK_XTAL in u-boot.
> 
> In the mt7622/mt7629 clock tree, the clocks with ID=0 never call
> mtk_topckgen_get_mux_rate, adn return xtal clock directly. This what we
> expected.
> 
> However for newer chips, they may have some clocks with ID=0 not
> representing the xtal clock and still needs mtk_topckgen_get_mux_rate be
> called. Current logic will make entire clock driver not working.
> 
> This patch adds a flag to indicate that whether a clock driver needs clocks
> with ID=0 to call mtk_topckgen_get_mux_rate.

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Add comment for flags
>   Fix the if condition of CLK_BYPASS_XTAL
> ---
>  drivers/clk/mediatek/clk-mtk.c | 4 +++-
>  drivers/clk/mediatek/clk-mtk.h | 6 ++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index d43b8a0648..7d145f4975 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -319,7 +319,9 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk, 
> u32 off)
>   index &= mux->mux_mask << mux->mux_shift;
>   index = index >> mux->mux_shift;
>  
> - if (mux->parent[index])
> + if (mux->parent[index] > 0 ||
> + (mux->parent[index] == CLK_XTAL &&
> +  priv->tree->flags & CLK_BYPASS_XTAL))
>   return mtk_clk_find_parent_rate(clk, mux->parent[index],
>   NULL);
>  
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 95a23d14a8..e0c5550c80 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -11,6 +11,11 @@
>  #define CLK_XTAL 0
>  #define MHZ  (1000 * 1000)
>  
> +/* flags in struct mtk_clk_tree */
> +
> +/* clk id == 0 doesn't mean it's xtal clk */
> +#define CLK_BYPASS_XTAL  BIT(0)
> +
>  #define HAVE_RST_BAR BIT(0)
>  #define CLK_DOMAIN_SCPSYSBIT(0)
>  #define CLK_MUX_SETCLR_UPD   BIT(1)
> @@ -197,6 +202,7 @@ struct mtk_clk_tree {
>   const struct mtk_fixed_clk *fclks;
>   const struct mtk_fixed_factor *fdivs;
>   const struct mtk_composite *muxes;
> + u32 flags;
>  };
>  
>  struct mtk_clk_priv {
> -- 
> 2.17.1
> 

Re: [PATCH v2 21/32] pinctrl: mediatek: add pinctrl driver for MT7986 SoC

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:57PM +0800, Weijie Gao wrote:
> This patch adds pinctrl and gpio support for MT7986 SoC
> 

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  drivers/pinctrl/mediatek/Kconfig  |   4 +
>  drivers/pinctrl/mediatek/Makefile |   1 +
>  drivers/pinctrl/mediatek/pinctrl-mt7986.c | 775 ++
>  3 files changed, 780 insertions(+)
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7986.c
> 
> diff --git a/drivers/pinctrl/mediatek/Kconfig 
> b/drivers/pinctrl/mediatek/Kconfig
> index aceec9277d..27e8998e59 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -20,6 +20,10 @@ config PINCTRL_MT7981
>   bool "MT7981 SoC pinctrl driver"
>   select PINCTRL_MTK
>  
> +config PINCTRL_MT7986
> + bool "MT7986 SoC pinctrl driver"
> + select PINCTRL_MTK
> +
>  config PINCTRL_MT8512
>   bool "MT8512 SoC pinctrl driver"
>   select PINCTRL_MTK
> diff --git a/drivers/pinctrl/mediatek/Makefile 
> b/drivers/pinctrl/mediatek/Makefile
> index 1879d7ae2a..6e733759f5 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
>  obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
>  obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
>  obj-$(CONFIG_PINCTRL_MT7981) += pinctrl-mt7981.o
> +obj-$(CONFIG_PINCTRL_MT7986) += pinctrl-mt7986.o
>  obj-$(CONFIG_PINCTRL_MT8512) += pinctrl-mt8512.o
>  obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
>  obj-$(CONFIG_PINCTRL_MT8518) += pinctrl-mt8518.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7986.c 
> b/drivers/pinctrl/mediatek/pinctrl-mt7986.c
> new file mode 100644
> index 00..449e5adcd9
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt7986.c
> @@ -0,0 +1,775 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * The MT7986 driver based on Linux generic pinctrl binding.
> + *
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> +#include 
> +#include "pinctrl-mtk-common.h"
> +
> +#define MT7986_TYPE0_PIN(_number, _name) \
> + MTK_TYPED_PIN(_number, _name, DRV_GRP4, IO_TYPE_GRP0)
> +
> +#define MT7986_TYPE1_PIN(_number, _name) \
> + MTK_TYPED_PIN(_number, _name, DRV_GRP4, IO_TYPE_GRP1)
> +
> +#define PIN_FIELD_GPIO(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits)   
> \
> + PIN_FIELD_BASE_CALC(_s_pin, _e_pin, GPIO_BASE, _s_addr, _x_addrs,   
> \
> + _s_bit, _x_bits, 32, 0)
> +
> +#define PIN_FIELD_BASE(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,   
> \
> +_x_bits) 
> \
> + PIN_FIELD_BASE_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit, 
> \
> + _x_bits, 32, 0)
> +
> +/**
> + * enum - Locking variants of the iocfg bases
> + *
> + * MT7986 have multiple bases to program pin configuration listed as the 
> below:
> + * iocfg_rt:0x11c3, iocfg_rb:0x11c4, iocfg_lt:0x11e2,
> + * iocfg_lb:0x11e3, iocfg_tr:0x11f0, iocfg_tl:0x11f1,
> + * _i_based could be used to indicate what base the pin should be mapped 
> into.
> + *
> + * Each iocfg register base control different group of pads on the SoC
> + *
> + *
> + *  chip carrier
> + *
> + *  A  B  C  D  E  F  G  H
> + *++
> + *  8 | o  o  o  o  o  o  o  o |
> + *  7 | o  o  o  o  o  o  o  o |
> + *  6 | o  o  o  o  o  o  o  o |
> + *  5 | o  o  o  o  o  o  o  o |
> + *  4 | o  o  o  o  o  o  o  o |
> + *  3 | o  o  o  o  o  o  o  o |
> + *  2 | o  o  o  o  o  o  o  o |
> + *  1 | o  o  o  o  o  o  o  o |
> + *++
> + *
> + *  inside Chip carrier
> + *
> + *  A  B  C  D  E  F  G  H
> + *++
> + *  8 ||
> + *  7 |TL  TR  |
> + *  6 |  +-+   |
> + *  5 |   LT | | RT|
> + *  4 |  | |   |
> + *  3 |   LB | | RB|
> + *  2 |  +-+   |
> + *  1 ||
> + *++
> + *
> + */
> +
> +enum {
> + GPIO_BASE,
> + IOCFG_RT_BASE,
> + IOCFG_RB_BASE,
> + IOCFG_LT_BASE,
> + IOCFG_LB_BASE,
> + IOCFG_TR_BASE,
> + IOCFG_TL_BASE,
> +};
> +
> +static const char *const mt7986_pinctrl_register_base_names[] = {
> + "gpio", "iocf

Re: [PATCH v2 16/32] spi: add support for MediaTek spi-mem controller

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:45PM +0800, Weijie Gao wrote:
> This patch adds support for spi-mem controller found on newer MediaTek SoCs
> This controller supports Single/Dual/Quad SPI mode.

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: SkyLake.Huang 
> ---
> v2 changes:
>   Remove unused code
>   Fix coding style
>   Add description for struct fields
> ---
>  drivers/spi/Kconfig|   8 +
>  drivers/spi/Makefile   |   1 +
>  drivers/spi/mtk_spim.c | 701 +
>  3 files changed, 710 insertions(+)
>  create mode 100644 drivers/spi/mtk_spim.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 75b794548b..7e72ab9c24 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -276,6 +276,14 @@ config MTK_SNFI_SPI
> used to access SPI memory devices like SPI-NOR or SPI-NAND on
> platforms embedding this IP core, like MT7622/M7629.
>  
> +config MTK_SPIM
> + bool "Mediatek SPI-MEM master controller driver"
> + depends on SPI_MEM
> + help
> +   Enable MediaTek SPI-MEM master controller driver. This driver mainly
> +   supports SPI flashes. You can use single, dual or quad mode
> +   transmission on this controller.
> +
>  config MVEBU_A3700_SPI
>   bool "Marvell Armada 3700 SPI driver"
>   select CLK_ARMADA_3720
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 4de77c260a..309f6b5328 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
>  obj-$(CONFIG_MTK_SNFI_SPI) += mtk_snfi_spi.o
>  obj-$(CONFIG_MTK_SNOR) += mtk_snor.o
> +obj-$(CONFIG_MTK_SPIM) += mtk_spim.o
>  obj-$(CONFIG_MT7620_SPI) += mt7620_spi.o
>  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
>  obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
> diff --git a/drivers/spi/mtk_spim.c b/drivers/spi/mtk_spim.c
> new file mode 100644
> index 00..b45ef529a5
> --- /dev/null
> +++ b/drivers/spi/mtk_spim.c
> @@ -0,0 +1,701 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 MediaTek Inc. All Rights Reserved.
> + *
> + * Author: SkyLake.Huang 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SPI_CFG0_REG 0x
> +#define SPI_CFG1_REG 0x0004
> +#define SPI_TX_SRC_REG   0x0008
> +#define SPI_RX_DST_REG   0x000c
> +#define SPI_TX_DATA_REG  0x0010
> +#define SPI_RX_DATA_REG  0x0014
> +#define SPI_CMD_REG  0x0018
> +#define SPI_IRQ_REG  0x001c
> +#define SPI_STATUS_REG   0x0020
> +#define SPI_PAD_SEL_REG  0x0024
> +#define SPI_CFG2_REG 0x0028
> +#define SPI_TX_SRC_REG_640x002c
> +#define SPI_RX_DST_REG_640x0030
> +#define SPI_CFG3_IPM_REG 0x0040
> +
> +#define SPI_CFG0_SCK_HIGH_OFFSET 0
> +#define SPI_CFG0_SCK_LOW_OFFSET  8
> +#define SPI_CFG0_CS_HOLD_OFFSET  16
> +#define SPI_CFG0_CS_SETUP_OFFSET 24
> +#define SPI_ADJUST_CFG0_CS_HOLD_OFFSET   0
> +#define SPI_ADJUST_CFG0_CS_SETUP_OFFSET  16
> +
> +#define SPI_CFG1_CS_IDLE_OFFSET  0
> +#define SPI_CFG1_PACKET_LOOP_OFFSET  8
> +#define SPI_CFG1_PACKET_LENGTH_OFFSET16
> +#define SPI_CFG1_GET_TICKDLY_OFFSET  29
> +
> +#define SPI_CFG1_GET_TICKDLY_MASKGENMASK(31, 29)
> +#define SPI_CFG1_CS_IDLE_MASK0xff
> +#define SPI_CFG1_PACKET_LOOP_MASK0xff00
> +#define SPI_CFG1_PACKET_LENGTH_MASK  0x3ff
> +#define SPI_CFG1_IPM_PACKET_LENGTH_MASK  GENMASK(31, 16)
> +#define SPI_CFG2_SCK_HIGH_OFFSET 0
> +#define SPI_CFG2_SCK_LOW_OFFSET  16
> +#define SPI_CFG2_SCK_HIGH_MASK   GENMASK(15, 0)
> +#define SPI_CFG2_SCK_LOW_MASKGENMASK(31, 16)
> +
> +#define SPI_CMD_ACT  BIT(0)
> +#define SPI_CMD_RESUME   BIT(1)
> +#define SPI_CMD_RST   

Re: [PATCH v2 15/32] watchdog: mediatek: add support for MediaTek MT7986 SoC

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:42PM +0800, Weijie Gao wrote:
> Add watchdog support for MediaTek MT7986 SoC

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  drivers/watchdog/mtk_wdt.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index b098b2e3cf..368b36849c 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -145,6 +145,7 @@ static const struct wdt_ops mtk_wdt_ops = {
>  static const struct udevice_id mtk_wdt_ids[] = {
>   { .compatible = "mediatek,wdt"},
>   { .compatible = "mediatek,mt6589-wdt"},
> + { .compatible = "mediatek,mt7986-wdt" },
>   {}
>  };
>  
> -- 
> 2.17.1
> 

Re: [PATCH v2 14/32] timer: mtk: add support for MediaTek MT7981/MT7986 SoCs

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:40PM +0800, Weijie Gao wrote:
> This patch add general-purpose timer support for MediaTek MT7981/MT7986.
> These two SoCs uses a newer version of timer with its register definition
> slightly changed.
> 

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  drivers/timer/mtk_timer.c | 59 ---
>  1 file changed, 37 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c
> index f6b97f868c..223e63f6c1 100644
> --- a/drivers/timer/mtk_timer.c
> +++ b/drivers/timer/mtk_timer.c
> @@ -13,24 +13,32 @@
>  #include 
>  #include 
>  
> -#define MTK_GPT4_CTRL0x40
> -#define MTK_GPT4_CLK 0x44
> -#define MTK_GPT4_CNT 0x48
> +#define MTK_GPT4_OFFSET_V1   0x40
> +#define MTK_GPT4_OFFSET_V2   0x80
>  
> -#define GPT4_ENABLE  BIT(0)
> -#define GPT4_CLEAR   BIT(1)
> -#define GPT4_FREERUN GENMASK(5, 4)
> -#define GPT4_CLK_SYS 0x0
> -#define GPT4_CLK_DIV10x0
> +#define MTK_GPT_CON  0x0
> +#define MTK_GPT_V1_CLK   0x4
> +#define MTK_GPT_CNT  0x8
> +
> +#define GPT_ENABLE   BIT(0)
> +#define GPT_CLEARBIT(1)
> +#define GPT_V1_FREERUN   GENMASK(5, 4)
> +#define GPT_V2_FREERUN   GENMASK(6, 5)
> +
> +enum mtk_gpt_ver {
> + MTK_GPT_V1,
> + MTK_GPT_V2
> +};
>  
>  struct mtk_timer_priv {
>   void __iomem *base;
> + unsigned int gpt4_offset;
>  };
>  
>  static u64 mtk_timer_get_count(struct udevice *dev)
>  {
>   struct mtk_timer_priv *priv = dev_get_priv(dev);
> - u32 val = readl(priv->base + MTK_GPT4_CNT);
> + u32 val = readl(priv->base + priv->gpt4_offset + MTK_GPT_CNT);
>  
>   return timer_conv_64(val);
>  }
> @@ -40,12 +48,27 @@ static int mtk_timer_probe(struct udevice *dev)
>   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
>   struct mtk_timer_priv *priv = dev_get_priv(dev);
>   struct clk clk, parent;
> - int ret;
> + int ret, gpt_ver;
>  
>   priv->base = dev_read_addr_ptr(dev);
> + gpt_ver = dev_get_driver_data(dev);
> +
>   if (!priv->base)
>   return -ENOENT;
>  
> + if (gpt_ver == MTK_GPT_V2) {
> + priv->gpt4_offset = MTK_GPT4_OFFSET_V2;
> +
> + writel(GPT_V2_FREERUN | GPT_CLEAR | GPT_ENABLE,
> +priv->base + priv->gpt4_offset + MTK_GPT_CON);
> + } else {
> + priv->gpt4_offset = MTK_GPT4_OFFSET_V1;
> +
> + writel(GPT_V1_FREERUN | GPT_CLEAR | GPT_ENABLE,
> +priv->base + priv->gpt4_offset + MTK_GPT_CON);
> + writel(0, priv->base + priv->gpt4_offset + MTK_GPT_V1_CLK);
> + }
> +
>   ret = clk_get_by_index(dev, 0, );
>   if (ret)
>   return ret;
> @@ -61,16 +84,6 @@ static int mtk_timer_probe(struct udevice *dev)
>   if (!uc_priv->clock_rate)
>   return -EINVAL;
>  
> - /*
> -  * Initialize the timer:
> -  * 1. set clock source to system clock with clock divider setting to 1
> -  * 2. set timer mode to free running
> -  * 3. reset timer counter to 0 then enable the timer
> -  */
> - writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK);
> - writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE,
> -priv->base + MTK_GPT4_CTRL);
> -
>   return 0;
>  }
>  
> @@ -79,8 +92,10 @@ static const struct timer_ops mtk_timer_ops = {
>  };
>  
>  static const struct udevice_id mtk_timer_ids[] = {
> - { .compatible = "mediatek,timer" },
> - { .compatible = "mediatek,mt6577-timer" },
> + { .compatible = "mediatek,timer", .data = MTK_GPT_V1 },
> + { .compatible = "mediatek,mt6577-timer", .data = MTK_GPT_V1 },
> + { .compatible = "mediatek,mt7981-timer", .data = MTK_GPT_V2 },
> + { .compatible = "mediatek,mt7986-timer", .data = MTK_GPT_V2 },
>   { }
>  };
>  
> -- 
> 2.17.1
> 

Re: [PATCH v2 11/32] arm: dts: mt7622: force high-speed mode for uart

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:34PM +0800, Weijie Gao wrote:
> The input clock for uart is too slow (25MHz) which introduces frequent data
> error on both receiving and transmitting even if the baudrate is 115200.
> 
> Using high-speed can significantly solve this issue.

Tested on Bananapi BPi-R64 (MT7622).
Fixes unstable console issues previously observed on MT7622 systems.

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  arch/arm/dts/mt7622.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/dts/mt7622.dtsi b/arch/arm/dts/mt7622.dtsi
> index 0127474c95..fb6c1b7154 100644
> --- a/arch/arm/dts/mt7622.dtsi
> +++ b/arch/arm/dts/mt7622.dtsi
> @@ -175,6 +175,7 @@
>   status = "disabled";
>   assigned-clocks = < CLK_TOP_AXI_SEL>;
>   assigned-clock-parents = < CLK_TOP_SYSPLL1_D2>;
> + mediatek,force-highspeed;
>   };
>  
>   mmc0: mmc@1123 {
> -- 
> 2.17.1
> 

Re: [PATCH v2 10/32] serial: mtk: add support for using dynamic baud clock souce

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:32PM +0800, Weijie Gao wrote:
> The baud clock on some platform may change due to assigned-clock-parent
> set in DT. In current flow the baud clock is only retrieved during probe
> stage. If the parent of the source clock changes after probe stage, the
> setbrg will set wrong baudrate.
> 
> To get the right clock rate, this patch records the baud clk struct to the
> driver's priv, and changes the driver's flow to get the clock rate before
> calling _mtk_serial_setbrg().

Tested on Bananapi BPi-R2 (MT7623), Bananapi BPi-R64 (MT7623) and
Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Add description for priv struct
>   Fix the type of clk_rate
> ---
>  drivers/serial/serial_mtk.c | 80 ++---
>  1 file changed, 47 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
> index a84f39b3fa..1d7cc9f7b6 100644
> --- a/drivers/serial/serial_mtk.c
> +++ b/drivers/serial/serial_mtk.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -70,27 +71,37 @@ struct mtk_serial_regs {
>  #define BAUD_ALLOW_MAX(baud) ((baud) + (baud) * 3 / 100)
>  #define BAUD_ALLOW_MIX(baud) ((baud) - (baud) * 3 / 100)
>  
> +/* struct mtk_serial_priv -  Structure holding all information used by the
> + *   driver
> + * @regs:Register base of the serial port
> + * @clk: The baud clock device
> + * @fixed_clk_rate:  Fallback fixed baud clock rate if baud clock
> + *   device is not specified
> + * @force_highspeed: Force using high-speed mode
> + */
>  struct mtk_serial_priv {
>   struct mtk_serial_regs __iomem *regs;
> - u32 clock;
> + struct clk clk;
> + u32 fixed_clk_rate;
>   bool force_highspeed;
>  };
>  
> -static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud)
> +static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud,
> +uint clk_rate)
>  {
>   u32 quot, realbaud, samplecount = 1;
>  
>   /* Special case for low baud clock */
> - if (baud <= 115200 && priv->clock <= 1200) {
> + if (baud <= 115200 && clk_rate == 1200) {
>   writel(3, >regs->highspeed);
>  
> - quot = DIV_ROUND_CLOSEST(priv->clock, 256 * baud);
> + quot = DIV_ROUND_CLOSEST(clk_rate, 256 * baud);
>   if (quot == 0)
>   quot = 1;
>  
> - samplecount = DIV_ROUND_CLOSEST(priv->clock, quot * baud);
> + samplecount = DIV_ROUND_CLOSEST(clk_rate, quot * baud);
>  
> - realbaud = priv->clock / samplecount / quot;
> + realbaud = clk_rate / samplecount / quot;
>   if (realbaud > BAUD_ALLOW_MAX(baud) ||
>   realbaud < BAUD_ALLOW_MIX(baud)) {
>   pr_info("baud %d can't be handled\n", baud);
> @@ -104,7 +115,7 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv 
> *priv, int baud)
>  
>   if (baud <= 115200) {
>   writel(0, >regs->highspeed);
> - quot = DIV_ROUND_CLOSEST(priv->clock, 16 * baud);
> + quot = DIV_ROUND_CLOSEST(clk_rate, 16 * baud);
>   } else if (baud <= 576000) {
>   writel(2, >regs->highspeed);
>  
> @@ -112,13 +123,13 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv 
> *priv, int baud)
>   if ((baud == 50) || (baud == 576000))
>   baud = 460800;
>  
> - quot = DIV_ROUND_UP(priv->clock, 4 * baud);
> + quot = DIV_ROUND_UP(clk_rate, 4 * baud);
>   } else {
>  use_hs3:
>   writel(3, >regs->highspeed);
>  
> - quot = DIV_ROUND_UP(priv->clock, 256 * baud);
> - samplecount = DIV_ROUND_CLOSEST(priv->clock, quot * baud);
> + quot = DIV_ROUND_UP(clk_rate, 256 * baud);
> + samplecount = DIV_ROUND_CLOSEST(clk_rate, quot * baud);
>   }
>  
>  set_baud:
> @@ -167,8 +178,13 @@ static int _mtk_serial_pending(struct mtk_serial_priv 
> *priv, bool input)
>  static int mtk_serial_setbrg(struct udevice *dev, int baudrate)
>  {
>   struct mtk_serial_priv *priv = dev_get_priv(dev);
> + u32 clk_rate;
> +
> + clk_rate = clk_get_rate(>clk);
> + if (IS_ERR_VALUE(clk_rate) || clk_rate == 0)
> + clk

Re: [PATCH v2 09/32] net: mediatek: add support for MediaTek MT7981/MT7986

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:29PM +0800, Weijie Gao wrote:
> This patch adds support for MediaTek MT7981 and MT7986. Both chips uses
> PDMA v2.
> 

Tested on Bananapi BPi-R2 (MT7623), Bananapi BPi-R64 (MT7623) and
Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 


> Reviewed-by: Ramon Fried 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  drivers/net/mtk_eth.c | 27 +++
>  drivers/net/mtk_eth.h |  5 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index fb72baae68..4c9fb266c7 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -115,6 +115,7 @@ struct mtk_eth_priv {
>   int force_mode;
>   int speed;
>   int duplex;
> + bool pn_swap;
>  
>   struct phy_device *phydev;
>   int phy_interface;
> @@ -1057,6 +1058,12 @@ static void mtk_sgmii_init(struct mtk_eth_priv *priv)
>   /* SGMII force mode setting */
>   writel(SGMII_FORCE_MODE, priv->sgmii_base + SGMSYS_SGMII_MODE);
>  
> + /* SGMII PN SWAP setting */
> + if (priv->pn_swap) {
> + setbits_le32(priv->sgmii_base + SGMSYS_QPHY_WRAP_CTRL,
> +  SGMII_PN_SWAP_TX_RX);
> + }
> +
>   /* Release PHYA power down state */
>   clrsetbits_le32(priv->sgmii_base + SGMSYS_QPHY_PWR_STATE_CTRL,
>   SGMII_PHYA_PWD, 0);
> @@ -1470,6 +1477,8 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
>   dev_err(dev, "Unable to find sgmii\n");
>   return -ENODEV;
>   }
> +
> + priv->pn_swap = ofnode_read_bool(args.node, "pn_swap");
>   }
>  
>   /* check for switch first, otherwise phy will be used */
> @@ -1520,6 +1529,22 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
>   return 0;
>  }
>  
> +static const struct mtk_soc_data mt7986_data = {
> + .caps = MT7986_CAPS,
> + .ana_rgc3 = 0x128,
> + .pdma_base = PDMA_V2_BASE,
> + .txd_size = sizeof(struct mtk_tx_dma_v2),
> + .rxd_size = sizeof(struct mtk_rx_dma_v2),
> +};
> +
> +static const struct mtk_soc_data mt7981_data = {
> + .caps = MT7986_CAPS,
> + .ana_rgc3 = 0x128,
> + .pdma_base = PDMA_V2_BASE,
> + .txd_size = sizeof(struct mtk_tx_dma_v2),
> + .rxd_size = sizeof(struct mtk_rx_dma_v2),
> +};
> +
>  static const struct mtk_soc_data mt7629_data = {
>   .ana_rgc3 = 0x128,
>   .pdma_base = PDMA_V1_BASE,
> @@ -1549,6 +1574,8 @@ static const struct mtk_soc_data mt7621_data = {
>  };
>  
>  static const struct udevice_id mtk_eth_ids[] = {
> + { .compatible = "mediatek,mt7986-eth", .data = (ulong)_data },
> + { .compatible = "mediatek,mt7981-eth", .data = (ulong)_data },
>   { .compatible = "mediatek,mt7629-eth", .data = (ulong)_data },
>   { .compatible = "mediatek,mt7623-eth", .data = (ulong)_data },
>   { .compatible = "mediatek,mt7622-eth", .data = (ulong)_data },
> diff --git a/drivers/net/mtk_eth.h b/drivers/net/mtk_eth.h
> index 236c498a1b..1382ccbeb2 100644
> --- a/drivers/net/mtk_eth.h
> +++ b/drivers/net/mtk_eth.h
> @@ -36,6 +36,8 @@ enum mkt_eth_capabilities {
>  
>  #define MT7623_CAPS  (MTK_GMAC1_TRGMII)
>  
> +#define MT7986_CAPS  (MTK_NETSYS_V2)
> +
>  /* Frame Engine Register Bases */
>  #define PDMA_V1_BASE 0x0800
>  #define PDMA_V2_BASE 0x6000
> @@ -72,6 +74,9 @@ enum mkt_eth_capabilities {
>  #define SGMSYS_QPHY_PWR_STATE_CTRL   0xe8
>  #define SGMII_PHYA_PWD   BIT(4)
>  
> +#define SGMSYS_QPHY_WRAP_CTRL0xec
> +#define SGMII_PN_SWAP_TX_RX  0x03
> +
>  #define SGMSYS_GEN2_SPEED0x2028
>  #define SGMSYS_GEN2_SPEED_V2 0x128
>  #define SGMSYS_SPEED_2500BIT(2)
> -- 
> 2.17.1
> 

Re: [PATCH v2 08/32] net: mediatek: add support for PDMA v2

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:27PM +0800, Weijie Gao wrote:
> This patch adds support for PDMA v2 hardware. The PDMA v2 has extended the
> DMA descriptor to 8-words, and some of its fields have changed comparing
> to the v1 hardware.

Tested on Bananapi BPi-R2 (MT7623), Bananapi BPi-R64 (MT7623) and
Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Ramon Fried 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Add description for new fields
> ---
>  drivers/net/mtk_eth.c | 54 ---
>  drivers/net/mtk_eth.h | 53 +++---
>  2 files changed, 86 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index e3738b9277..fb72baae68 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -76,10 +76,14 @@ enum mtk_switch {
>   * @caps Flags shown the extra capability for the SoC
>   * @ana_rgc3:The offset for register ANA_RGC3 
> related to
>   *   sgmiisys syscon
> + * @pdma_base:   Register base of PDMA block
> + * @txd_size:Tx DMA descriptor size.
> + * @rxd_size:Rx DMA descriptor size.
>   */
>  struct mtk_soc_data {
>   u32 caps;
>   u32 ana_rgc3;
> + u32 pdma_base;
>   u32 txd_size;
>   u32 rxd_size;
>  };
> @@ -130,13 +134,13 @@ struct mtk_eth_priv {
>  
>  static void mtk_pdma_write(struct mtk_eth_priv *priv, u32 reg, u32 val)
>  {
> - writel(val, priv->fe_base + PDMA_BASE + reg);
> + writel(val, priv->fe_base + priv->soc->pdma_base + reg);
>  }
>  
>  static void mtk_pdma_rmw(struct mtk_eth_priv *priv, u32 reg, u32 clr,
>u32 set)
>  {
> - clrsetbits_le32(priv->fe_base + PDMA_BASE + reg, clr, set);
> + clrsetbits_le32(priv->fe_base + priv->soc->pdma_base + reg, clr, set);
>  }
>  
>  static void mtk_gdma_write(struct mtk_eth_priv *priv, int no, u32 reg,
> @@ -1133,8 +1137,8 @@ static void mtk_mac_init(struct mtk_eth_priv *priv)
>  static void mtk_eth_fifo_init(struct mtk_eth_priv *priv)
>  {
>   char *pkt_base = priv->pkt_pool;
> - struct mtk_tx_dma *txd;
> - struct mtk_rx_dma *rxd;
> + struct mtk_tx_dma_v2 *txd;
> + struct mtk_rx_dma_v2 *rxd;
>   int i;
>  
>   mtk_pdma_rmw(priv, PDMA_GLO_CFG_REG, 0x, 0);
> @@ -1155,7 +1159,11 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv 
> *priv)
>  
>   txd->txd1 = virt_to_phys(pkt_base);
>   txd->txd2 = PDMA_TXD2_DDONE | PDMA_TXD2_LS0;
> - txd->txd4 = PDMA_TXD4_FPORT_SET(priv->gmac_id + 1);
> +
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
> + txd->txd5 = PDMA_V2_TXD5_FPORT_SET(priv->gmac_id + 1);
> + else
> + txd->txd4 = PDMA_V1_TXD4_FPORT_SET(priv->gmac_id + 1);
>  
>   pkt_base += PKTSIZE_ALIGN;
>   }
> @@ -1164,7 +1172,11 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv 
> *priv)
>   rxd = priv->rx_ring_noc + i * priv->soc->rxd_size;
>  
>   rxd->rxd1 = virt_to_phys(pkt_base);
> - rxd->rxd2 = PDMA_RXD2_PLEN0_SET(PKTSIZE_ALIGN);
> +
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
> + rxd->rxd2 = PDMA_V2_RXD2_PLEN0_SET(PKTSIZE_ALIGN);
> + else
> + rxd->rxd2 = PDMA_V1_RXD2_PLEN0_SET(PKTSIZE_ALIGN);
>  
>   pkt_base += PKTSIZE_ALIGN;
>   }
> @@ -1193,6 +1205,9 @@ static int mtk_eth_start(struct udevice *dev)
>   reset_deassert(>rst_fe);
>   mdelay(10);
>  
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
> + setbits_le32(priv->fe_base + FE_GLO_MISC_REG, PDMA_VER_V2);
> +
>   /* Packets forward to PDMA */
>   mtk_gdma_write(priv, priv->gmac_id, GDMA_IG_CTRL_REG, GDMA_FWD_TO_CPU);
>  
> @@ -1227,7 +1242,7 @@ static void mtk_eth_stop(struct udevice *dev)
>TX_WB_DDONE | RX_DMA_EN | TX_DMA_EN, 0);
>   udelay(500);
>  
> - wait_for_bit_le32(priv->fe_base + PDMA_BASE + PDMA_GLO_CFG_REG,
> + wait_for_bit_le32(priv->fe_base + priv->soc->pdma_base + 
> PDMA_GLO_CFG_REG,
> RX_DMA_BUSY | TX_DMA_BUSY, 0, 5000, 0);
>  }
>  
> @@ -1252,7 +1267,7 @@ static int mtk_eth_send(struct udevice *dev, void 
> *packet, int length)
>  {
>   struct mtk_eth_priv *priv = dev_get_priv(dev);
>

Re: [PATCH v2 07/32] net: mediatek: stop using bitfileds for DMA descriptors

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:23PM +0800, Weijie Gao wrote:
> This patch is a preparation for adding a new version of PDMA of which the
> DMA descriptor fields has changed. Using bitfields will result in a complex
> modification. Convert bitfields to u32 units can solve this problem easily.

Tested on Bananapi BPi-R64 (MT7622) and BPi-R2 (MT7623).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes:
>   Fix typo in commit message
> ---
>  drivers/net/mtk_eth.c | 144 ++
>  drivers/net/mtk_eth.h |  32 ++
>  2 files changed, 80 insertions(+), 96 deletions(-)
> 
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index ce4aa6e065..e3738b9277 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -65,77 +65,6 @@
>   (DP_DISCARD << MC_DP_S) | \
>   (DP_DISCARD << UN_DP_S))
>  
> -struct pdma_rxd_info1 {
> - u32 PDP0;
> -};
> -
> -struct pdma_rxd_info2 {
> - u32 PLEN1 : 14;
> - u32 LS1 : 1;
> - u32 UN_USED : 1;
> - u32 PLEN0 : 14;
> - u32 LS0 : 1;
> - u32 DDONE : 1;
> -};
> -
> -struct pdma_rxd_info3 {
> - u32 PDP1;
> -};
> -
> -struct pdma_rxd_info4 {
> - u32 FOE_ENTRY : 14;
> - u32 CRSN : 5;
> - u32 SP : 3;
> - u32 L4F : 1;
> - u32 L4VLD : 1;
> - u32 TACK : 1;
> - u32 IP4F : 1;
> - u32 IP4 : 1;
> - u32 IP6 : 1;
> - u32 UN_USED : 4;
> -};
> -
> -struct pdma_rxdesc {
> - struct pdma_rxd_info1 rxd_info1;
> - struct pdma_rxd_info2 rxd_info2;
> - struct pdma_rxd_info3 rxd_info3;
> - struct pdma_rxd_info4 rxd_info4;
> -};
> -
> -struct pdma_txd_info1 {
> - u32 SDP0;
> -};
> -
> -struct pdma_txd_info2 {
> - u32 SDL1 : 14;
> - u32 LS1 : 1;
> - u32 BURST : 1;
> - u32 SDL0 : 14;
> - u32 LS0 : 1;
> - u32 DDONE : 1;
> -};
> -
> -struct pdma_txd_info3 {
> - u32 SDP1;
> -};
> -
> -struct pdma_txd_info4 {
> - u32 VLAN_TAG : 16;
> - u32 INS : 1;
> - u32 RESV : 2;
> - u32 UDF : 6;
> - u32 FPORT : 3;
> - u32 TSO : 1;
> - u32 TUI_CO : 3;
> -};
> -
> -struct pdma_txdesc {
> - struct pdma_txd_info1 txd_info1;
> - struct pdma_txd_info2 txd_info2;
> - struct pdma_txd_info3 txd_info3;
> - struct pdma_txd_info4 txd_info4;
> -};
> -
>  enum mtk_switch {
>   SW_NONE,
>   SW_MT7530,
> @@ -151,13 +80,15 @@ enum mtk_switch {
>  struct mtk_soc_data {
>   u32 caps;
>   u32 ana_rgc3;
> + u32 txd_size;
> + u32 rxd_size;
>  };
>  
>  struct mtk_eth_priv {
>   char pkt_pool[TOTAL_PKT_BUF_SIZE] __aligned(ARCH_DMA_MINALIGN);
>  
> - struct pdma_txdesc *tx_ring_noc;
> - struct pdma_rxdesc *rx_ring_noc;
> + void *tx_ring_noc;
> + void *rx_ring_noc;
>  
>   int rx_dma_owner_idx0;
>   int tx_cpu_owner_idx0;
> @@ -1202,14 +1133,16 @@ static void mtk_mac_init(struct mtk_eth_priv *priv)
>  static void mtk_eth_fifo_init(struct mtk_eth_priv *priv)
>  {
>   char *pkt_base = priv->pkt_pool;
> + struct mtk_tx_dma *txd;
> + struct mtk_rx_dma *rxd;
>   int i;
>  
>   mtk_pdma_rmw(priv, PDMA_GLO_CFG_REG, 0x, 0);
>   udelay(500);
>  
> - memset(priv->tx_ring_noc, 0, NUM_TX_DESC * sizeof(struct pdma_txdesc));
> - memset(priv->rx_ring_noc, 0, NUM_RX_DESC * sizeof(struct pdma_rxdesc));
> - memset(priv->pkt_pool, 0, TOTAL_PKT_BUF_SIZE);
> + memset(priv->tx_ring_noc, 0, NUM_TX_DESC * priv->soc->txd_size);
> + memset(priv->rx_ring_noc, 0, NUM_RX_DESC * priv->soc->rxd_size);
> + memset(priv->pkt_pool, 0xff, TOTAL_PKT_BUF_SIZE);
>  
>   flush_dcache_range((ulong)pkt_base,
>  (ulong)(pkt_base + TOTAL_PKT_BUF_SIZE));
> @@ -1218,17 +1151,21 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv 
> *priv)
>   priv->tx_cpu_owner_idx0 = 0;
>  
>   for (i = 0; i < NUM_TX_DESC; i++) {
> - priv->tx_ring_noc[i].txd_info2.LS0 = 1;
> - priv->tx_ring_noc[i].txd_info2.DDONE = 1;
> - priv->tx_ring_noc[i].txd_info4.FPORT = priv->gmac_id + 1;
> + txd = priv->tx_ring_noc + i * priv->soc->txd_size;
> +
> + txd->txd1 = virt_to_phys(pkt_base);
> + txd->txd2 = PDMA_TXD2_DDONE | PDMA_TXD2_LS0;
> + txd->txd4 = PDMA_TXD4_FPORT_SET(priv->gmac_id + 1);
>  
> - priv->tx_ring_noc[i].txd_info1.SDP0 = virt_to_phys(pkt_base);
>   

Re: [PATCH v2 06/32] net: mediatek: use a struct to cover variations of all SoCs

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:19PM +0800, Weijie Gao wrote:
> Using a single soc id to control different initialization and TX/RX flow
> for all SoCs is not extensible if more hardware variations are added in
> the future.
> 
> This patch introduces a struct to replace the original mtk_soc to allow
> the driver be able handle newer hardwares.

Tested on Bananapi BPi-R64 (MT7622) and Bananapi BPi-R2 (MT7623).

Tested-by: Daniel Golle 

> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2c changes:
>   Add description for new struct
> ---
>  drivers/net/mtk_eth.c | 56 ++-
>  drivers/net/mtk_eth.h | 25 ++-
>  2 files changed, 64 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index 4fe7ee0d36..ce4aa6e065 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -142,11 +142,15 @@ enum mtk_switch {
>   SW_MT7531
>  };
>  
> -enum mtk_soc {
> - SOC_MT7623,
> - SOC_MT7629,
> - SOC_MT7622,
> - SOC_MT7621
> +/* struct mtk_soc_data - This is the structure holding all differences
> + *   among various plaforms
> + * @caps Flags shown the extra capability for the SoC
> + * @ana_rgc3:The offset for register ANA_RGC3 
> related to
> + *   sgmiisys syscon
> + */
> +struct mtk_soc_data {
> + u32 caps;
> + u32 ana_rgc3;
>  };
>  
>  struct mtk_eth_priv {
> @@ -171,7 +175,7 @@ struct mtk_eth_priv {
>   int (*mmd_write)(struct mtk_eth_priv *priv, u8 addr, u8 devad, u16 reg,
>u16 val);
>  
> - enum mtk_soc soc;
> + const struct mtk_soc_data *soc;
>   int gmac_id;
>   int force_mode;
>   int speed;
> @@ -679,7 +683,7 @@ static int mt7530_setup(struct mtk_eth_priv *priv)
>   u32 val, txdrv;
>   int i;
>  
> - if (priv->soc != SOC_MT7621) {
> + if (!MTK_HAS_CAPS(priv->soc->caps, MTK_TRGMII_MT7621_CLK)) {
>   /* Select 250MHz clk for RGMII mode */
>   mtk_ethsys_rmw(priv, ETHSYS_CLKCFG0_REG,
>  ETHSYS_TRGMII_CLK_SEL362_5, 0);
> @@ -1108,9 +1112,8 @@ static int mtk_phy_probe(struct udevice *dev)
>  static void mtk_sgmii_init(struct mtk_eth_priv *priv)
>  {
>   /* Set SGMII GEN2 speed(2.5G) */
> - clrsetbits_le32(priv->sgmii_base + ((priv->soc == SOC_MT7622) ?
> - SGMSYS_GEN2_SPEED : SGMSYS_GEN2_SPEED_V2),
> - SGMSYS_SPEED_2500, SGMSYS_SPEED_2500);
> + setbits_le32(priv->sgmii_base + priv->soc->ana_rgc3,
> +  SGMSYS_SPEED_2500);
>  
>   /* Disable SGMII AN */
>   clrsetbits_le32(priv->sgmii_base + SGMSYS_PCS_CONTROL_1,
> @@ -1182,7 +1185,8 @@ static void mtk_mac_init(struct mtk_eth_priv *priv)
>   mtk_gmac_write(priv, GMAC_PORT_MCR(priv->gmac_id), mcr);
>   }
>  
> - if (priv->soc == SOC_MT7623) {
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_GMAC1_TRGMII) &&
> + !MTK_HAS_CAPS(priv->soc->caps, MTK_TRGMII_MT7621_CLK)) {
>   /* Lower Tx Driving for TRGMII path */
>   for (i = 0 ; i < NUM_TRGMII_CTRL; i++)
>   mtk_gmac_write(priv, GMAC_TRGMII_TD_ODT(i),
> @@ -1431,7 +1435,11 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
>   ofnode subnode;
>   int ret;
>  
> - priv->soc = dev_get_driver_data(dev);
> + priv->soc = (const struct mtk_soc_data *)dev_get_driver_data(dev);
> + if (!priv->soc) {
> + dev_err(dev, "missing soc compatible data\n");
> + return -EINVAL;
> + }
>  
>   pdata->iobase = (phys_addr_t)dev_remap_addr(dev);
>  
> @@ -1544,11 +1552,27 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
>   return 0;
>  }
>  
> +static const struct mtk_soc_data mt7629_data = {
> + .ana_rgc3 = 0x128,
> +};
> +
> +static const struct mtk_soc_data mt7623_data = {
> + .caps = MT7623_CAPS,
> +};
> +
> +static const struct mtk_soc_data mt7622_data = {
> + .ana_rgc3 = 0x2028,
> +};
> +
> +static const struct mtk_soc_data mt7621_data = {
> + .caps = MT7621_CAPS,
> +};
> +
>  static const struct udevice_id mtk_eth_ids[] = {
> - { .compatible = "mediatek,mt7629-eth", .data = SOC_MT7629 },
> - { .compatible = "mediatek,mt7623-eth", .data = SOC_MT7623 },
> - { .compatible = "mediatek,mt7622-eth", .data = SOC_MT7622 },
> - { .compatible = "mediatek,mt7621-eth", .dat

Re: [PATCH v2 05/32] mmc: mediatek: add support for MediaTek MT7891/MT7986 SoCs

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:04:12PM +0800, Weijie Gao wrote:
> Add eMMC and SDXC support for MediaTek MT7981/MT7986 SoCs
> Both chips support SDXC and eMMC 4.5. MT7986A supports eMMC 5.1.
> 

Tested on Bananapi BPi-R3 (MT7986A) with both eMMC and SDMMC.

Tested-by: Daniel Golle 


> Reviewed-by: Jaehoon Chung 
> Reviewed-by: Simon Glass 
> Signed-off-by: Weijie Gao 
> ---
> v2 changes: none
> ---
>  drivers/mmc/mtk-sd.c | 68 ++--
>  1 file changed, 53 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
> index e61e8cf4b9..b206b0a085 100644
> --- a/drivers/mmc/mtk-sd.c
> +++ b/drivers/mmc/mtk-sd.c
> @@ -1496,7 +1496,12 @@ static void msdc_init_hw(struct msdc_host *host)
>   /* Enable data & cmd interrupts */
>   writel(DATA_INTS_MASK | CMD_INTS_MASK, >base->msdc_inten);
>  
> - writel(0, tune_reg);
> + if (host->top_base) {
> + writel(0, >top_base->emmc_top_control);
> + writel(0, >top_base->emmc_top_cmd);
> + } else {
> + writel(0, tune_reg);
> + }
>   writel(0, >base->msdc_iocon);
>  
>   if (host->r_smpl)
> @@ -1507,9 +1512,14 @@ static void msdc_init_hw(struct msdc_host *host)
>   writel(0x403c0046, >base->patch_bit0);
>   writel(0x4089, >base->patch_bit1);
>  
> - if (host->dev_comp->stop_clk_fix)
> + if (host->dev_comp->stop_clk_fix) {
>   clrsetbits_le32(>base->patch_bit1, MSDC_PB1_STOP_DLY_M,
>   3 << MSDC_PB1_STOP_DLY_S);
> + clrbits_le32(>base->sdc_fifo_cfg,
> +  SDC_FIFO_CFG_WRVALIDSEL);
> + clrbits_le32(>base->sdc_fifo_cfg,
> +  SDC_FIFO_CFG_RDVALIDSEL);
> + }
>  
>   if (host->dev_comp->busy_check)
>   clrbits_le32(>base->patch_bit1, (1 << 7));
> @@ -1544,15 +1554,28 @@ static void msdc_init_hw(struct msdc_host *host)
>   }
>  
>   if (host->dev_comp->data_tune) {
> - setbits_le32(tune_reg,
> -  MSDC_PAD_TUNE_RD_SEL | MSDC_PAD_TUNE_CMD_SEL);
> - clrsetbits_le32(>base->patch_bit0,
> - MSDC_INT_DAT_LATCH_CK_SEL_M,
> - host->latch_ck <<
> - MSDC_INT_DAT_LATCH_CK_SEL_S);
> + if (host->top_base) {
> + setbits_le32(>top_base->emmc_top_control,
> +  PAD_DAT_RD_RXDLY_SEL);
> + clrbits_le32(>top_base->emmc_top_control,
> +  DATA_K_VALUE_SEL);
> + setbits_le32(>top_base->emmc_top_cmd,
> +  PAD_CMD_RD_RXDLY_SEL);
> + } else {
> + setbits_le32(tune_reg,
> +  MSDC_PAD_TUNE_RD_SEL | 
> MSDC_PAD_TUNE_CMD_SEL);
> + clrsetbits_le32(>base->patch_bit0,
> + MSDC_INT_DAT_LATCH_CK_SEL_M,
> + host->latch_ck <<
> + MSDC_INT_DAT_LATCH_CK_SEL_S);
> + }
>   } else {
>   /* choose clock tune */
> - setbits_le32(tune_reg, MSDC_PAD_TUNE_RXDLYSEL);
> + if (host->top_base)
> + setbits_le32(>top_base->emmc_top_control,
> +  PAD_RXDLY_SEL);
> + else
> + setbits_le32(tune_reg, MSDC_PAD_TUNE_RXDLYSEL);
>   }
>  
>   if (host->dev_comp->builtin_pad_ctrl) {
> @@ -1604,12 +1627,6 @@ static void msdc_init_hw(struct msdc_host *host)
>   clrsetbits_le32(>base->sdc_cfg, SDC_CFG_DTOC_M,
>   3 << SDC_CFG_DTOC_S);
>  
> - if (host->dev_comp->stop_clk_fix) {
> - clrbits_le32(>base->sdc_fifo_cfg,
> -  SDC_FIFO_CFG_WRVALIDSEL);
> - clrbits_le32(>base->sdc_fifo_cfg,
> -  SDC_FIFO_CFG_RDVALIDSEL);
> - }
>  
>   host->def_tune_para.iocon = readl(>base->msdc_iocon);
>   host->def_tune_para.pad_tune = readl(>base->pad_tune);
> @@ -1792,6 +1809,25 @@ static const struct msdc_compatible mt7623_compat = {
>   .enhance_rx = false
>  };
>  
> +static const struct msdc_compatible mt7986_compat = {
> + .clk_div_bits = 12,
> + .pad_tune0 = true,
> + .async_fifo = true,
&

Re: [PATCH v2 01/32] arm: mediatek: add support for MediaTek MT7986 SoC

[Daniel Golle]

On Wed, Aug 31, 2022 at 07:00:17PM +0800, Weijie Gao wrote:
> This patch adds basic support for MediaTek MT7986 SoC.
> This include the file that will initialize the SoC after boot and its
> device tree.
> 
> Signed-off-by: Weijie Gao 

Tested on Bananapi BPi-R3 (MT7986A).

Tested-by: Daniel Golle 


> ---
> v2 changes:
>   Sort include lines
>   Add reference link for armv8_el2_to_aarch32 in lowlevel_init.S
>   Remove print_cpuinfo and use cpu driver instead
> ---
>  arch/arm/dts/mt7986-u-boot.dtsi   |  33 ++
>  arch/arm/dts/mt7986.dtsi  | 346 ++
>  arch/arm/mach-mediatek/Kconfig|  12 +
>  arch/arm/mach-mediatek/Makefile   |   1 +
>  arch/arm/mach-mediatek/mt7986/Makefile|   4 +
>  arch/arm/mach-mediatek/mt7986/init.c  |  45 +++
>  arch/arm/mach-mediatek/mt7986/lowlevel_init.S |  32 ++
>  7 files changed, 473 insertions(+)
>  create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
>  create mode 100644 arch/arm/dts/mt7986.dtsi
>  create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
>  create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
>  create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
> 
> diff --git a/arch/arm/dts/mt7986-u-boot.dtsi b/arch/arm/dts/mt7986-u-boot.dtsi
> new file mode 100644
> index 00..95671f8afa
> --- /dev/null
> +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> new file mode 100644
> index 00..25b81ab7e1
> --- /dev/null
> +++ b/arch/arm/dts/mt7986.dtsi
> @@ -0,0 +1,346 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + compatible = "mediatek,mt7986";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + config {
> + u-boot,mmc-env-partition = "u-boot-env";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + };
> +
> + dummy_clk: dummy12m {
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + #clock-cells = <0>;
> + /* must need this line, or uart uanable to get dummy_clk */
> + u-boot,dm-pre-reloc;
> + };
> +
> + hwver: hwver {
> + compatible = "mediatek,hwver";
> + reg = <0x800 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <>;
> + clock-frequency = <1300>;
> + interrupts = ,
> +  ,
> +  ,
> +  ;
> + arm,cpu-registers-not-fw-configured;
> + };
> +
> + timer0: timer@10008000 {
> + compatible = "mediatek,mt7986-timer";
> + reg = <0x10008000 0x1000>;
> + interrupts = ;
> + clocks = < CK_INFRA_CK_F26M>;
> +

Re: [PATCH v4 1/2] bootm: fix typo imape_comp -> image_comp

[Daniel Golle]

On Mon, Aug 29, 2022 at 08:30:14PM -0600, Simon Glass wrote:
> On Fri, 26 Aug 2022 at 21:15, Daniel Golle  wrote:
> >
> > Chage variable name 'imape_comp' to the supposedly intended name
> 
> Change

Can you fix that on-the-fly while comitting or should I repost with
that typo in the patch description fixed?

> 
> > 'image_comp'.
> >
> > Signed-off-by: Daniel Golle 
> > ---
> > v4: add missing name replacement
> >
> > boot/bootm.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> 
> Reviewed-by: Simon Glass 

[PATCH v4 2/2] image-fit: don't set compression if it can't be read

[Daniel Golle]

fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.

As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its 
file!
no longer shows if the compression node is actually absent.

Signed-off-by: Daniel Golle 
---
v2: fix typo 'imape_comp' vs. 'image_comp'
v3: rather fix the typo everywhere in an additional patch before
v4: rebase on updated patch fixing typo

boot/bootm.c | 6 ++
 boot/image-fit.c | 3 +--
 cmd/ximg.c   | 7 ++-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 63c79a9cfc..29c067fae7 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
return -EINVAL;
}
 
-   if (fit_image_get_comp(fit, noffset, _comp)) {
-   puts("Can't get image compression!\n");
-   return -EINVAL;
-   }
+   if (fit_image_get_comp(fit, noffset, _comp))
+   image_comp = IH_COMP_NONE;
 
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
 void fit_image_print(const void *fit, int image_noffset, const char *p)
 {
char *desc;
-   uint8_t type, arch, os, comp;
+   uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset, 
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
-   *comp = -1;
return -1;
}
 
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
return 1;
}
 
-   if (fit_image_get_comp(fit_hdr, noffset, )) {
-   puts("Could not find script subimage "
-   "compression type\n");
-   return 1;
-   }
+   if (fit_image_get_comp(fit_hdr, noffset, ))
+   comp = IH_COMP_NONE;
 
data = (ulong)fit_data;
len = (ulong)fit_len;
-- 
2.37.2

[PATCH v4 1/2] bootm: fix typo imape_comp -> image_comp

[Daniel Golle]

Chage variable name 'imape_comp' to the supposedly intended name
'image_comp'.

Signed-off-by: Daniel Golle 
---
v4: add missing name replacement

boot/bootm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..63c79a9cfc 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1006,7 +1006,7 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
int noffset;
ulong load_end, buf_size;
uint8_t image_type;
-   uint8_t imape_comp;
+   uint8_t image_comp;
void *load_buf;
int ret;
 
@@ -1024,7 +1024,7 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
return -EINVAL;
}
 
-   if (fit_image_get_comp(fit, noffset, _comp)) {
+   if (fit_image_get_comp(fit, noffset, _comp)) {
puts("Can't get image compression!\n");
return -EINVAL;
}
@@ -1032,12 +1032,12 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
load_buf = malloc(buf_size);
-   ret = image_decomp(imape_comp, 0, data, image_type, load_buf,
+   ret = image_decomp(image_comp, 0, data, image_type, load_buf,
   (void *)data, len, buf_size, _end);
free(load_buf);
 
if (ret) {
-   ret = handle_decomp_error(imape_comp, load_end - 0, buf_size, 
ret);
+   ret = handle_decomp_error(image_comp, load_end - 0, buf_size, 
ret);
if (ret != BOOTM_ERR_UNIMPLEMENTED)
return ret;
}
-- 
2.37.2

[PATCH v3 2/2] image-fit: don't set compression if it can't be read

[Daniel Golle]

fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.

As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its 
file!
no longer shows if the compression node is actually absent.

Signed-off-by: Daniel Golle 
---
 boot/bootm.c | 6 ++
 boot/image-fit.c | 3 +--
 cmd/ximg.c   | 7 ++-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 4de573e24e..29c067fae7 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
return -EINVAL;
}
 
-   if (fit_image_get_comp(fit, noffset, _comp)) {
-   puts("Can't get image compression!\n");
-   return -EINVAL;
-   }
+   if (fit_image_get_comp(fit, noffset, _comp))
+   image_comp = IH_COMP_NONE;
 
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
 void fit_image_print(const void *fit, int image_noffset, const char *p)
 {
char *desc;
-   uint8_t type, arch, os, comp;
+   uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset, 
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
-   *comp = -1;
return -1;
}
 
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
return 1;
}
 
-   if (fit_image_get_comp(fit_hdr, noffset, )) {
-   puts("Could not find script subimage "
-   "compression type\n");
-   return 1;
-   }
+   if (fit_image_get_comp(fit_hdr, noffset, ))
+   comp = IH_COMP_NONE;
 
data = (ulong)fit_data;
len = (ulong)fit_len;
-- 
2.37.2

[PATCH v3 1/2] bootm: fix typo imape_comp -> image_comp

[Daniel Golle]

Chage variable name 'imape_comp' to the supposedly intended name
'image_comp'.

Signed-off-by: Daniel Golle 
---
 boot/bootm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..4de573e24e 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1006,7 +1006,7 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
int noffset;
ulong load_end, buf_size;
uint8_t image_type;
-   uint8_t imape_comp;
+   uint8_t image_comp;
void *load_buf;
int ret;
 
@@ -1032,12 +1032,12 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
load_buf = malloc(buf_size);
-   ret = image_decomp(imape_comp, 0, data, image_type, load_buf,
+   ret = image_decomp(image_comp, 0, data, image_type, load_buf,
   (void *)data, len, buf_size, _end);
free(load_buf);
 
if (ret) {
-   ret = handle_decomp_error(imape_comp, load_end - 0, buf_size, 
ret);
+   ret = handle_decomp_error(image_comp, load_end - 0, buf_size, 
ret);
if (ret != BOOTM_ERR_UNIMPLEMENTED)
return ret;
}
-- 
2.37.2

[PATCH v2] image-fit: don't set compression if it can't be read

[Daniel Golle]

fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.

As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its 
file!
no longer shows if the compression node is actually absent.

Signed-off-by: Daniel Golle 
---
v2: fix typo 'imape_comp' vs. 'image_comp'
 boot/bootm.c | 6 ++
 boot/image-fit.c | 3 +--
 cmd/ximg.c   | 7 ++-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..fcdf23f19c 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
return -EINVAL;
}
 
-   if (fit_image_get_comp(fit, noffset, _comp)) {
-   puts("Can't get image compression!\n");
-   return -EINVAL;
-   }
+   if (fit_image_get_comp(fit, noffset, _comp))
+   imape_comp = IH_COMP_NONE;
 
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
 void fit_image_print(const void *fit, int image_noffset, const char *p)
 {
char *desc;
-   uint8_t type, arch, os, comp;
+   uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset, 
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
-   *comp = -1;
return -1;
}
 
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
return 1;
}
 
-   if (fit_image_get_comp(fit_hdr, noffset, )) {
-   puts("Could not find script subimage "
-   "compression type\n");
-   return 1;
-   }
+   if (fit_image_get_comp(fit_hdr, noffset, ))
+   comp = IH_COMP_NONE;
 
data = (ulong)fit_data;
len = (ulong)fit_len;
-- 
2.37.2

[PATCH] image-fit: don't set compression if it can't be read

[Daniel Golle]

fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.

As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its 
file!
no longer shows if the compression node is actually absent.

Signed-off-by: Daniel Golle 
---
 boot/bootm.c | 6 ++
 boot/image-fit.c | 3 +--
 cmd/ximg.c   | 7 ++-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..b659825305 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int 
req_image_type,
return -EINVAL;
}
 
-   if (fit_image_get_comp(fit, noffset, _comp)) {
-   puts("Can't get image compression!\n");
-   return -EINVAL;
-   }
+   if (fit_image_get_comp(fit, noffset, _comp))
+   image_comp = IH_COMP_NONE;
 
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
 void fit_image_print(const void *fit, int image_noffset, const char *p)
 {
char *desc;
-   uint8_t type, arch, os, comp;
+   uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset, 
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
-   *comp = -1;
return -1;
}
 
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
return 1;
}
 
-   if (fit_image_get_comp(fit_hdr, noffset, )) {
-   puts("Could not find script subimage "
-   "compression type\n");
-   return 1;
-   }
+   if (fit_image_get_comp(fit_hdr, noffset, ))
+   comp = IH_COMP_NONE;
 
data = (ulong)fit_data;
len = (ulong)fit_len;
-- 
2.37.1

Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards

[Daniel Golle]

On Fri, Aug 12, 2022 at 07:02:17PM +0800, Weijie Gao wrote:
> On Tue, 2022-08-09 at 11:10 +0200, Daniel Golle wrote:
> > Hi Weijie,
> > 
> > On Thu, Aug 04, 2022 at 11:35:03AM +0800, Weijie Gao wrote:
> > > This patch adds general board files based on MT7986 SoCs.
> > > 
> > > The SD/eMMC controller on MT7986A and MT7986B have different pin
> > > configurations so that four different reference board configs has
> > > to be
> > > added.
> > > 
> > > Signed-off-by: Weijie Gao 
> > > ---
> > > [...]
> > > diff --git a/include/configs/mt7986.h b/include/configs/mt7986.h
> > > new file mode 100644
> > > index 00..b28fc0f613
> > > --- /dev/null
> > > +++ b/include/configs/mt7986.h
> > > @@ -0,0 +1,26 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Configuration for MediaTek MT7986 SoC
> > > + *
> > > + * Copyright (C) 2022 MediaTek Inc.
> > > + * Author: Sam Shih 
> > > + */
> > > +
> > > +#ifndef __MT7986_H
> > > +#define __MT7986_H
> > > +
> > > +#include 
> > > +
> > 
> > In the SDK sources I found also
> > #define CONFIG_SYS_BOOTM_LEN   SZ_128M
> > here which is actually needed to boot any image with uncompressed
> > kernel larger than 8MiB. As for ARM64 this size is easily exceeded
> > and
> > we got plenty of RAM, I suggest to also include a more generous
> > CONFIG_SYS_BOOTM_LEN in your submission to upstream U-Boot.
> 
> CONFIG_SYS_BOOTM_LEN is now a Kconfig symbol. It will no be defined in
> this header.
> Instead, the default value of this symbol is 0x400 (64M) for ARM64
> which is enough for an ARM64 kernel.

Sorry, I missed c45568cc4e ("Convert CONFIG_SYS_BOOTM_LEN to Kconfig")
and was trying the series on top of U-Boot 2022.07 (for inclusion in
OpenWrt) locally.

I've tested the whole series with Bananapi BPi-R3 (MT7986A) board.

U-Boot itself works great with all 4 boot media options.
The only remaining problem is BootROM header generation using
mkimage/mtk_image for SPI-NOR:
TF-A and U-Boot ithemselves both work well with SPI-NOR when using
'bromutil' to generate the image. When using 'mkimage -T mtk_image'
instead of 'bromutil' the resulting bl2.img doesn't work:
F0: 102B 
FA:  
V0: 7027 6006 [0001]
00: 1017 
FA: 5100 
01: 102A 0001
02: 5100 
BP: 2000 00C0 [0001]
EC:   []
T0:  0213 [010F]
System halt!


Cheers


Daniel

Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards

[Daniel Golle]

Hi Weijie,

On Thu, Aug 04, 2022 at 11:35:03AM +0800, Weijie Gao wrote:
> This patch adds general board files based on MT7986 SoCs.
> 
> The SD/eMMC controller on MT7986A and MT7986B have different pin
> configurations so that four different reference board configs has to be
> added.
> 
> Signed-off-by: Weijie Gao 
> ---
> [...]
> diff --git a/include/configs/mt7986.h b/include/configs/mt7986.h
> new file mode 100644
> index 00..b28fc0f613
> --- /dev/null
> +++ b/include/configs/mt7986.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Configuration for MediaTek MT7986 SoC
> + *
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> +#ifndef __MT7986_H
> +#define __MT7986_H
> +
> +#include 
> +

In the SDK sources I found also
#define CONFIG_SYS_BOOTM_LEN   SZ_128M
here which is actually needed to boot any image with uncompressed
kernel larger than 8MiB. As for ARM64 this size is easily exceeded and
we got plenty of RAM, I suggest to also include a more generous
CONFIG_SYS_BOOTM_LEN in your submission to upstream U-Boot.



> +#define CONFIG_SYS_NONCACHED_MEMORY  SZ_1M
> +#define CONFIG_SYS_MMC_ENV_DEV   0
> +
> +/* Uboot definition */
> +#define CONFIG_SYS_UBOOT_BASECONFIG_SYS_TEXT_BASE
> +
> +/* SPL -> Uboot */
> +#define CONFIG_SYS_UBOOT_START   CONFIG_SYS_TEXT_BASE
> +
> +/* DRAM */
> +#define CONFIG_SYS_SDRAM_BASE0x4000
> +
> +#endif
> -- 
> 2.17.1
> 

Re: [PATCH 01/31] arm: mediatek: add support for MediaTek MT7986 SoC

[Daniel Golle]

> gateway.
> I'll send v2 later.
> 
> Best Regards,
> 
> Weijie
> 
> On Thu, 2022-08-04 at 16:50 +0800, Weijie Gao wrote:
> > Hi Daniel,
> > 
> > Thanks for the reminder.
> > I found more errornous line-breaks in other patches...
> > I'll find a way to fix that.
> > 
> > Best Regards,
> > Weijie
> > 
> > On Thu, 2022-08-04 at 10:37 +0200, Daniel Golle wrote:
> > > Hi Weijie,
> > > 
> > > happy to see this series posted!
> > > Trying to apply it unfortunately fails due to errornous line-
> > > breaks,
> > > supposedly inserted by your MUA, see below.
> > > 
> > > I didn't go beyond the first patch and it'd be nice if you report
> > > the
> > > whole series without the wrong line-breaks.
> > > 
> > > Cheers
> > > 
> > > 
> > > Daniel
> > > 
> > > 
> > > On Thu, Aug 04, 2022 at 11:34:28AM +0800, Weijie Gao wrote:
> > > > This patch adds basic support for MediaTek MT7986 SoC.
> > > > This include the file that will initialize the SoC after boot and
> > > > its
> > > > device tree.
> > > > 
> > > > Signed-off-by: Weijie Gao 
> > > > ---
> > > >  arch/arm/dts/mt7986-u-boot.dtsi   |  33 ++
> > > >  arch/arm/dts/mt7986.dtsi  | 341
> > > > ++
> > > >  arch/arm/mach-mediatek/Kconfig|  11 +
> > > >  arch/arm/mach-mediatek/Makefile   |   1 +
> > > >  arch/arm/mach-mediatek/mt7986/Makefile|   4 +
> > > >  arch/arm/mach-mediatek/mt7986/init.c  |  53 +++
> > > >  arch/arm/mach-mediatek/mt7986/lowlevel_init.S |  30 ++
> > > >  7 files changed, 473 insertions(+)
> > > >  create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
> > > >  create mode 100644 arch/arm/dts/mt7986.dtsi
> > > >  create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
> > > >  create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
> > > >  create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
> > > > 
> > > > diff --git a/arch/arm/dts/mt7986-u-boot.dtsi
> > > >  b/arch/arm/dts/mt7986-u-boot.dtsi
> > > 
> > > The above two lines should be a single line.
> > > 
> > > > new file mode 100644
> > > > index 00..95671f8afa
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> > > > @@ -0,0 +1,33 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (c) 2022 MediaTek Inc.
> > > > + * Author: Sam Shih 
> > > > + */
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > +   u-boot,dm-pre-reloc;
> > > > +};
> > > > diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> > > > new file mode 100644
> > > > index 00..f235bd8b8c
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/mt7986.dtsi
> > > > @@ -0,0 +1,341 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (c) 2022 MediaTek Inc.
> > > > + * Author: Sam Shih 
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +/ {
> > > > +   compatible = "mediatek,mt7986";
> > > > +   interrupt-parent = <>;
> > > > +   #address-cells = <1>;
> > > > +   #size-cells = <1>;
> > > > +
> > > > +   config {
> > > > +   u-boot,mmc-env-partition = "u-boot-env&quo

Re: [PATCH 29/31] tools: mtk_image: split the code of generating NAND header into a new file

[Daniel Golle]

Hi Weijie,

please see one comment in-line below:

On Thu, Aug 04, 2022 at 11:36:50AM +0800, Weijie Gao wrote:
> The predefined NAND headers take too much spaces in the mtk_image.c.
> Moving them into a new file can significantly improve the readability of
> both mtk_image.c and the new mtk_nand_headers.c.
> 
> This is a preparation for adding more NAND headers.
> 
> Signed-off-by: Weijie Gao 
> ---
>  tools/Makefile   |   1 +
>  tools/mtk_image.c| 304 ++-
>  tools/mtk_image.h|  25 
>  tools/mtk_nand_headers.c | 286 
>  tools/mtk_nand_headers.h |  52 +++
>  5 files changed, 379 insertions(+), 289 deletions(-)
>  create mode 100644 tools/mtk_nand_headers.c
>  create mode 100644 tools/mtk_nand_headers.h
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f2339666a..4f27ed1ab1 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -147,6 +147,7 @@ dumpimage-mkimage-objs := aisimage.o \
>   gpimage.o \
>   gpimage-common.o \
>   mtk_image.o \
> + mtk_nand_headers.o \
>   $(ECDSA_OBJS-y) \
>   $(RSA_OBJS-y) \
>   $(AES_OBJS-y)
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index dcd6525f32..3701d1564a 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -12,216 +12,7 @@
>  #include 
>  #include "imagetool.h"
>  #include "mtk_image.h"
> -
> -/* NAND header for SPI-NAND with 2KB page + 64B spare */
> -static const union nand_boot_header snand_hdr_2k_64_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x03, 0x00, 0x40, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x7B, 0xC4, 0x17, 0x9D,
> - 0xCA, 0x42, 0x90, 0xD0, 0x98, 0xD0, 0xE0, 0xF7,
> - 0xDB, 0xCD, 0x16, 0xF6, 0x03, 0x73, 0xD2, 0xB8,
> - 0x93, 0xB2, 0x56, 0x5A, 0x84, 0x6E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 2KB page + 120B/128B spare */
> -static const union nand_boot_header snand_hdr_2k_128_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x05, 0x00, 0x70, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x90, 0x28, 0xED, 0x13,
> - 0x7F, 0x12, 0x22, 0xCD, 0x3D, 0x06, 0xF1, 0xB3,
> - 0x6F, 0x2E, 0xD9, 0xA0, 0x9D, 0x7A, 0xBD, 0xD7,
> - 0xB3, 0x28, 0x3C, 0x13, 0xDB, 0x4E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 4KB page + 256B spare */
> -static const union nand_boot_header snand_hdr_4k_256_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x10, 0x05, 0x00, 0xE0, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x47, 0xED, 0x0E, 0xC3,
> - 0x83, 0xBF, 0x41, 0xD2, 0x85, 0x21, 0x97, 0x57,
> - 0xC4, 0x2E, 0x6B, 0x7A, 0x40, 0xE0, 

Re: [PATCH 01/31] arm: mediatek: add support for MediaTek MT7986 SoC

[Daniel Golle]

Hi Weijie,

happy to see this series posted!
Trying to apply it unfortunately fails due to errornous line-breaks,
supposedly inserted by your MUA, see below.

I didn't go beyond the first patch and it'd be nice if you report the
whole series without the wrong line-breaks.

Cheers


Daniel


On Thu, Aug 04, 2022 at 11:34:28AM +0800, Weijie Gao wrote:
> This patch adds basic support for MediaTek MT7986 SoC.
> This include the file that will initialize the SoC after boot and its
> device tree.
> 
> Signed-off-by: Weijie Gao 
> ---
>  arch/arm/dts/mt7986-u-boot.dtsi   |  33 ++
>  arch/arm/dts/mt7986.dtsi  | 341 ++
>  arch/arm/mach-mediatek/Kconfig|  11 +
>  arch/arm/mach-mediatek/Makefile   |   1 +
>  arch/arm/mach-mediatek/mt7986/Makefile|   4 +
>  arch/arm/mach-mediatek/mt7986/init.c  |  53 +++
>  arch/arm/mach-mediatek/mt7986/lowlevel_init.S |  30 ++
>  7 files changed, 473 insertions(+)
>  create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
>  create mode 100644 arch/arm/dts/mt7986.dtsi
>  create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
>  create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
>  create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
> 
> diff --git a/arch/arm/dts/mt7986-u-boot.dtsi
>  b/arch/arm/dts/mt7986-u-boot.dtsi

The above two lines should be a single line.

> new file mode 100644
> index 00..95671f8afa
> --- /dev/null
> +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> new file mode 100644
> index 00..f235bd8b8c
> --- /dev/null
> +++ b/arch/arm/dts/mt7986.dtsi
> @@ -0,0 +1,341 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + compatible = "mediatek,mt7986";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + config {
> + u-boot,mmc-env-partition = "u-boot-env";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + };
> +
> + dummy_clk: dummy12m {
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + #clock-cells = <0>;
> + /* must need this line, or uart uanable to get dummy_clk */
> + u-boot,dm-pre-reloc;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <>;
> + clock-frequency = <1300>;
> + interrupts = ,
> +  ,
> +  ,
> +  ;
> + arm,cpu-registers-not-fw-configured;
> + };
> +
> + timer0: timer@10008000 {
> + compatible = "mediatek,mt7986-timer";
> + reg = <0x10008000 0x1000>;
> + interrupts = ;
> + clocks = < CK_INFRA_CK_F26M>;
> + clock-names = "gpt-clk";
> + u-boot,dm-pre-reloc;
> + };
> +
> + watchdog: watchdog@1001c000 {
> + compatible = "mediatek,mt7986-wdt";
> + reg = <0x1001c000 0x1000>;
> + interrupts = ;
> + #reset-cells = <1>;
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller@c00 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> + interrupt-controller;
> + reg = <0x0c00 0x4>,  /* GICD */
> +   <0x0c08 0x20>; /* GICR */
> +
> + interrupts = ;
> + };
> +
> + 

Re: 回复: minor regression in U-Boot 2022.04

[Daniel Golle]

Hi Weijie,

On Tue, Apr 12, 2022 at 01:40:00AM +, Weijie Gao (高惟杰) wrote:
> Hi Daniel,
> 
> I've also noticed this error message.
> It seems that some struct variables containing all zero data of the pinctrl 
> driver are not set to const, which causes these variables to be put into .bss 
> section, instead of .rodata section.
> As you know the .bss section does not exist in board_init_f stage, and its 
> place is overlapped by dtb used by u-boot. This will result in incorrect data 
> used by the pinctrl driver.
> 
> I'll try to fix it later.

Any news about the gobbled serial output issue?
It would be nice to update uboot-mediatek in OpenWrt to v2022.04, so
MT798x patches will easily apply on top.

Cheers

Daniel


> 
> Best Regards
> 
> Weijie
> 
> -邮件原件-
> 发件人: Daniel Golle  
> 发送时间: 2022年4月12日 6:44
> 收件人: u-boot@lists.denx.de; Weijie Gao (高惟杰) 
> 主题: minor regression in U-Boot 2022.04
> 
> Hi!
> 
> I'm about to bump the U-Boot build for MediaTek MT7622 boards in OpenWrt to 
> U-Boot 2022.04. While practially everything seems to work fine, I've noticed 
> an error message early in the serial output which was not present in U-Boot 
> 2022.01. It is even followed by a bunch of random characters which are 
> different on every boot (hints to a read-out-of-bounds on uninitialzed memory 
> or the like):
> serial_mtk serial@11002000: pinctrl_select_state_full: 
> uclass_get_device_by_phandle_id: err=-19 CC 
> 
> At another boot:
> serial_mtk serial@11002000: pinctrl_select_state_full: 
> uclass_get_device_by_phandle_id: err=-19  H H UI  $ 
> 1.04-OpenWrt-r19423-c9c2b01b84 (Apr 11 2022 - 19:25:34 +)
> 
> This is probably related to recent changes in dm and pinctrl, as there 
> haven't been any changes to mtk_serial itself.
> 
> Log including ROM and ARM Trusted Firmware A serial output:
> 
> F0: 102B 
> F6:  
> V0:   [0001]
> 00:  
> BP: 0400 0041 []
> G0: 1190 
> T0:  02AD [000F]
> Jump to BL
> 
> NOTICE:  BL2: v2.4(release):OpenWrt v2021-05-08-d2c75b21-2 (mt7622-snand-2ddr)
> NOTICE:  BL2: Built : 12:03:10, Apr 11 2022
> NOTICE:  SPI-NAND: W25N01GV (128MB)
> NOTICE:  BL2: Booting BL31
> NOTICE:  BL31: v2.4(release):OpenWrt v2021-05-08-d2c75b21-2 
> (mt7622-snand-2ddr)
> NOTICE:  BL31: Built : 12:03:10, Apr 11 2022 serial_mtk serial@11002000: 
> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 CC  
> U-Boot 2022.04-OpenWrt-r19423-c9c2b01b84 (Apr 11 2022 - 19:25:34 +)
> 
> CPU:   MediaTek MT7622
> Model: mt7622-bpi-r64
> DRAM:  1 GiB
> Core:  55 devices, 18 uclasses, devicetree: separate
> MMC:   mmc@1123: 0, mmc@1124: 1
> Loading Environment from UBI... SPI-NAND: W25N01GV (128MB) ...
> 
> 
> I will most likely not investigate this any further, but thought it might be 
> good to let you know.
> 
> 
> Best regards
> 
> 
> Daniel

Re: spi-nand: how to store environment with badblock handling in qspi nand

[Daniel Golle]

On Sat, Jun 25, 2022 at 10:10:08AM +0200, Kegl Rohit wrote:
> Hello!
> 
> Is it possible to store the environment inside a mtd partition when
> using a single qspi nand chip as storage?
> CONFIG_MTD_SPI_NAND=y
> 
> The idea is to separate the NAND into two system A/B.
> [...]
> 
> CONFIG_ENV_IS_IN_UBI will do badblock handling, but it would be a huge
> overhead to create an extra ubifs mtd partition only for the
> environment.

Actually it's not. The overhead of allocating a UBI volume is minimal
and typical logical block sizes are small enough to not be complete
overkill for something like a U-Boot environment.

> 
> 
> Has anyone already created the A/B system approach with the mtd spi
> nand interface and can give me some input?

Maybe see here for inspiration:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/410-add-linksys-e8450.patch;h=fde679f3863ccf2e22a3e1fd299963b66041a0b9;hb=HEAD#l403

Re: [PATCH] dt-bindings: mtd: partitions: add UBI binding

[Daniel Golle]

On Thu, Feb 17, 2022 at 11:24:48AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> UBI is often used on embedded devices to store UBI volumes with device
> configuration / calibration data. Such volumes may need to be documented
> and referenced for proper boot & setup.
> 
> Some examples:
> 1. U-Boot environment variables
> 2. Device calibration data
> 3. Default setup (e.g. initial password)
> 
> Signed-off-by: Rafał Miłecki 

This is very useful and can replace the downstream hacks we are
currently using for this purpose in OpenWrt.

Reviewed-by: Daniel Golle 

> ---
>  .../bindings/mtd/partitions/ubi.yaml  | 67 +++
>  1 file changed, 67 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/partitions/ubi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mtd/partitions/ubi.yaml 
> b/Documentation/devicetree/bindings/mtd/partitions/ubi.yaml
> new file mode 100644
> index ..cd081f06d4cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/partitions/ubi.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/partitions/ubi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: UBI (Unsorted Block Images) device
> +
> +description: |
> +  UBI is a layer providing logical volumes (consisting of logical blocks) on 
> top
> +  of raw flash devices. It deals with low-level flash issues (bit-flips, bad
> +  physical eraseblocks, wearing) providing a reliable data storage.
> +
> +  UBI device is built and stored in a single flash partition.
> +
> +  Some (usually embedded) devices use UBI volumes of specific names or 
> indexes
> +  to store setup / configuration data. This binding allows describing such
> +  volumes so they can be identified and referenced by consumers.
> +
> +maintainers:
> +  - Rafał Miłecki 
> +
> +allOf:
> +  - $ref: partition.yaml#
> +
> +properties:
> +  compatible:
> +const: ubi
> +
> +patternProperties:
> +  "^volume-[0-9a-f]+$":
> +type: object
> +description: UBI volume
> +properties:
> +  volume-name:
> +$ref: /schemas/types.yaml#/definitions/string
> +  volume-id:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +anyOf:
> +  - required:
> +  - volume-name
> +  - required:
> +  - volume-id
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +partitions {
> +compatible = "fixed-partitions";
> +#address-cells = <1>;
> +#size-cells = <1>;
> +
> +partition@0 {
> +compatible = "ubi";
> +reg = <0x000 0x100>;
> +label = "filesystem";
> +
> +env: volume-0 {
> +volume-name = "u-boot-env";
> +};
> +
> +calibration: volume-1 {
> +volume-id = <99>;
> +};
> +};
> +};
> -- 
> 2.34.1
> 

Regression? [PATCH 1/2] mtd: call of_platform_populate() for MTD partitions

[Daniel Golle]

Hi Rafal,
Hi Miguel,


On Mon, Apr 11, 2022 at 11:00:32AM +0200, Miquel Raynal wrote:
> On Wed, 2022-04-06 at 14:32:24 UTC, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= wrote:
> > From: Rafał Miłecki 
> > 
> > Until this change MTD subsystem supported handling partitions only with
> > MTD partitions parsers. That's a specific / limited API designed around
> > partitions.
> > 
> > Some MTD partitions may however require different handling. They may
> > contain specific data that needs to be parsed and somehow extracted. For
> > that purpose MTD subsystem should allow binding of standard platform
> > drivers.
> > 
> > An example can be U-Boot (sub)partition with environment variables.
> > There exist a "u-boot,env" DT binding for MTD (sub)partition that
> > requires an NVMEM driver.
> > 
> > Ref: 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment variables 
> > binding")
> > Signed-off-by: Rafał Miłecki 
> 
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git 
> mtd/next, thanks.

I'm trying to use next-20220422 and noticed a few new oops'es.
Turns out it could be a problem with this commit according to

[daniel@box linux.git]$ git bisect good
68471517e883902cdff6ea399d043b17f803b1a8 is the first bad commit
commit 68471517e883902cdff6ea399d043b17f803b1a8
Author: Rafał Miłecki 
Date:   Wed Apr 6 16:32:24 2022 +0200

mtd: call of_platform_populate() for MTD partitions
[...]
---

So when ever there is at least one 'compatible' node for any of the
mtd partitions I get the oops messages below. It doesn't really matter
what the compatible string is, "nvmem-cells" as well as "denx,fit"
(used for OpenWrt mtdsplit not even present in linux-next, so just a
dead hint in DTS) make the kernel to oops.

Despite the messages being shown, both accessing MTD partitions and
also eth0 MAC address populated via NVMEM seem to work without
problems (at least looks like it on first sight).

Find the full device tree here:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/dts/mt7622-ubnt-unifi-6-lr-ubootmod.dts

---
[...]
[0.549448] mtk-spi-nor 11014000.spi: IRQ not available.
[0.556396] spi-nor spi0.0: w25q512jvq (65536 Kbytes)
[0.933381] Freeing initrd memory: 2124K
[0.941567] 7 fixed-partitions partitions found on MTD device spi0.0
[0.947966] OF: Bad cell count for /spi@11014000/flash@0/partitions
[0.954286] OF: Bad cell count for /spi@11014000/flash@0/partitions
[0.960583] [ cut here ]
[0.965192] kobject: '(null)' (97a89bbf): is not initialized, yet 
kobject_get() is being called.
[0.974688] WARNING: CPU: 0 PID: 1 at kobject_get+0x68/0x94
[0.980263] Modules linked in:
[0.983313] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S
5.18.0-rc1+ #0
[0.991049] Hardware name: Ubiquiti UniFi 6 LR (U-Boot mod) (DT)
[0.997046] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[1.004000] pc : kobject_get+0x68/0x94
[1.007743] lr : kobject_get+0x68/0x94
[1.011484] sp : ffc008bdb4a0
[1.014789] x29: ffc008bdb4a0 x28:  x27: ff8005c57810
[1.021920] x26: ff8005c74a20 x25:  x24: 0001
[1.029050] x23:  x22:  x21: 
[1.036182] x20: ff8005c74a20 x19: ff8005c74a20 x18: ffc008ab9630
[1.043312] x17: 6f6b20746579202c x16: 64657a696c616974 x15: 0074
[1.050443] x14: 015c x13: 0074 x12: ffea
[1.057574] x11: efff x10: efff x9 : ffc008b11630
[1.064705] x8 : 00017fe8 x7 : c000efff x6 : 00057fa8
[1.071835] x5 : 0fff x4 :  x3 : ffc008bdb1c0
[1.078966] x2 :  x1 : ffc008ab9580 x0 : 005c
[1.086097] Call trace:
[1.088534]  kobject_get+0x68/0x94
[1.091930]  device_add+0xa4/0x840
[1.095328]  of_device_add+0x4c/0x5c
[1.098898]  of_platform_device_create_pdata+0xb8/0xf0
[1.104029]  of_platform_bus_create+0x104/0x350
[1.108552]  of_platform_populate+0x54/0xe0
[1.112728]  parse_mtd_partitions+0x430/0x490
[1.117080]  mtd_device_parse_register+0x90/0x2b0
[1.121777]  spi_nor_probe+0x1f8/0x2b0
[1.125521]  spi_mem_probe+0x68/0xa0
[1.129092]  spi_probe+0x80/0xdc
[1.132314]  really_probe.part.0+0x98/0x280
[1.136490]  __driver_probe_device+0x94/0x140
[1.140839]  driver_probe_device+0x40/0x114
[1.145014]  __device_attach_driver+0xb0/0x10c
[1.149450]  bus_for_each_drv+0x64/0xa0
[1.153280]  __device_attach+0xa8/0x16c
[1.157108]  device_initial_probe+0x10/0x20
[1.161283]  bus_probe_device+0x94/0x9c
[1.165114]  device_add+0x35c/0x840
[1.168596]  __spi_add_device+0x70/0x114
[1.172510]  spi_add_device+0x5c/0x90
[1.176165]  of_register_spi_device+0x204/0x330
[1.180688]  spi_register_controller+0x3e8/0x6dc
[ 

Re: [PATCH v2] pstore: Support already existing reserved-memory node

[Daniel Golle]

Hi Detlev,

On Tue, Apr 19, 2022 at 09:58:00AM -0400, Detlev Casanova wrote:
> Hey Daniel,
> 
> I see that the node is called ramoops@0x42ff. We usually don't set the 0x 
> in device tree nodes, and that's why the fdt_add_subnode function doesn't see 
> it and add ramoops@42ff (it just compares the text). For Linux, both 
> nodes 
> are the same and it complains.
> 
> I think the best course of action here is to remove that '0x' in your dts, so 
> that u-boot sees it as the pstore node.

I tried the change you suggest and remove the '0x' prefix and indeed that
works, the lengthy kernel warning about duplicate nodes and sysfs
entries are gone and pstore works as expected.
I've hence committed that change to OpenWrt:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fc245338d6e02e61fa7ecbd1a828aed97cdbef88

However, now there is another error message in U-Boot output:
Add 'ramoops@42ff' node failed: FDT_ERR_EXISTS

I figured that this is not a problem as previously (ie. before your
patch) even the exitence of the 'reserved-memory' node would result in
the 'ramoops' node not being added while now it really just errors out
in case of exactly that 'ramoops' node already existing, which is fine.

Thank you again for resolving this issue!


Cheers


Daniel


> 
> Regards,
> 
> Detlev.
> 
> On Monday, April 18, 2022 7:50:36 P.M. EDT Daniel Golle wrote:
> > Hi Detlev,
> > 
> > On Mon, Apr 18, 2022 at 02:46:21PM -0400, Detlev Casanova wrote:
> > > Hi Daniel,
> > > 
> > > The patch only checks the existence of the reserved-memory node.
> > > 
> > > I guess that before, adding the reserved-memory node failed and so nothing
> > > else was happening. Now, the node is found and then, it adds the ramoops
> > > subnode to it, making it double because it is already there in your case.
> > > 
> > > But that should not happen, because the fdt_add_subnode() function should
> > > fail if the node is already present (like it was failing for
> > > reserved-memory).
> > > 
> > > I'm going to look into it. Can you send me the device tree taht you are
> > > using (or at least the reserved-memory part) and u-boot config ?
> > 
> > Thank you for your reply and for taking a look at what's going on.
> > 
> > reserved-memory bits in dts:
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-m
> > ediatek/patches/050-mt7622-enable-pstore.patch
> > 
> > u-boot config:
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-m
> > ediatek/patches/404-add-bananapi_bpi-r64_defconfigs.patch
> > 
> > 
> > Cheers
> > 
> > 
> > Daniel
> > 
> > > Detlev.
> > > 
> > > On Monday, April 11, 2022 7:00:20 P.M. EDT Daniel Golle wrote:
> > > > Hi Detlev,
> > > > 
> > > > I've recently tried to update U-Boot from 2022.01 to 2022.04 and
> > > > noticed a regression introduced by the commit below.
> > > > 
> > > > While the unwanted error message ("Add 'reserved-memory' node failed:
> > > > FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
> > > > trace in Linux instead:
> > > > ...
> > > > [0.008295] sysfs: cannot create duplicate filename
> > > > '/devices/platform/42ff.ramoops' [0.008303] CPU: 0 PID: 1 Comm:
> > > > swapper/0 Tainted: G S5.15.33 #0 [0.008312] Hardware
> > > > name: Bananapi BPI-R64 (DT)
> > > > [0.008318] Call trace:
> > > > [0.008322]  dump_backtrace+0x0/0x15c
> > > > [0.008337]  show_stack+0x14/0x30
> > > > [0.008345]  dump_stack_lvl+0x64/0x7c
> > > > [0.008355]  dump_stack+0x14/0x2c
> > > > [0.008362]  sysfs_warn_dup+0x5c/0x74
> > > > [0.008373]  sysfs_create_dir_ns+0xb0/0xc0
> > > > [0.008381]  kobject_add_internal+0xbc/0x330
> > > > [0.008392]  kobject_add+0x80/0xe0
> > > > [0.008400]  device_add+0xd4/0x82c
> > > > [0.008410]  of_device_add+0x4c/0x5c
> > > > [0.008420]  of_platform_device_create_pdata+0xb8/0xf0
> > > > [0.008428]  of_platform_default_populate_init+0x58/0xcc
> > > > [0.008437]  do_one_initcall+0x4c/0x1b0
> > > > [0.008444]  kernel_init_freeable+0x230/0x294
> > > > [0.008456]  kernel_init+0x20/0x120
> > > > [0.008463]  ret_from_fork+0x10/0x20
> > > > [0.008471] kobject_add_internal failed for 42ff.ramoops with
> > > > -EEXIS

Re: [PATCH v2] pstore: Support already existing reserved-memory node

[Daniel Golle]

Hi Detlev,

On Mon, Apr 18, 2022 at 02:46:21PM -0400, Detlev Casanova wrote:
> Hi Daniel,
> 
> The patch only checks the existence of the reserved-memory node.
> 
> I guess that before, adding the reserved-memory node failed and so nothing 
> else was happening. Now, the node is found and then, it adds the ramoops 
> subnode to it, making it double because it is already there in your case.
> 
> But that should not happen, because the fdt_add_subnode() function should 
> fail 
> if the node is already present (like it was failing for reserved-memory).
> 
> I'm going to look into it. Can you send me the device tree taht you are using 
>  
> (or at least the reserved-memory part) and u-boot config ?

Thank you for your reply and for taking a look at what's going on.

reserved-memory bits in dts:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/050-mt7622-enable-pstore.patch

u-boot config:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/404-add-bananapi_bpi-r64_defconfigs.patch


Cheers


Daniel

> 
> Detlev.
> 
> On Monday, April 11, 2022 7:00:20 P.M. EDT Daniel Golle wrote:
> > Hi Detlev,
> > 
> > I've recently tried to update U-Boot from 2022.01 to 2022.04 and
> > noticed a regression introduced by the commit below.
> > 
> > While the unwanted error message ("Add 'reserved-memory' node failed:
> > FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
> > trace in Linux instead:
> > ...
> > [0.008295] sysfs: cannot create duplicate filename
> > '/devices/platform/42ff.ramoops' [0.008303] CPU: 0 PID: 1 Comm:
> > swapper/0 Tainted: G S5.15.33 #0 [0.008312] Hardware
> > name: Bananapi BPI-R64 (DT)
> > [0.008318] Call trace:
> > [0.008322]  dump_backtrace+0x0/0x15c
> > [0.008337]  show_stack+0x14/0x30
> > [0.008345]  dump_stack_lvl+0x64/0x7c
> > [0.008355]  dump_stack+0x14/0x2c
> > [0.008362]  sysfs_warn_dup+0x5c/0x74
> > [0.008373]  sysfs_create_dir_ns+0xb0/0xc0
> > [0.008381]  kobject_add_internal+0xbc/0x330
> > [0.008392]  kobject_add+0x80/0xe0
> > [0.008400]  device_add+0xd4/0x82c
> > [0.008410]  of_device_add+0x4c/0x5c
> > [0.008420]  of_platform_device_create_pdata+0xb8/0xf0
> > [0.008428]  of_platform_default_populate_init+0x58/0xcc
> > [0.008437]  do_one_initcall+0x4c/0x1b0
> > [0.008444]  kernel_init_freeable+0x230/0x294
> > [0.008456]  kernel_init+0x20/0x120
> > [0.008463]  ret_from_fork+0x10/0x20
> > [0.008471] kobject_add_internal failed for 42ff.ramoops with
> > -EEXIST, don't try to register things with the same name in the same
> > directory. ...
> > 
> > I assume that fdt_find_or_add_subnode() doesn't behave as expected and
> > apparently adds a duplicate node having the same name.
> > The pstore/ramoops reserved-memory is already defined in the fdt
> > contained in the FIT image (for compatibility with older U-Boot which
> > didn't care about pstore), so it should be not added again.
> > 
> > On Mon, Feb 07, 2022 at 11:02:30AM -0500, Detlev Casanova wrote:
> > > The pstore command tries to create a reserved-memory node but fails if
> > > 
> > > it is already present with:
> > > Add 'reserved-memory' node failed: FDT_ERR_EXISTS
> > > 
> > > This patch creates the node only if it does not exist and adapts the reg
> > > values sizes depending on already present #address-cells and #size-cells
> > > values.
> > > 
> > > Signed-off-by: Detlev Casanova 
> > > ---
> > > 
> > > Changes in v2:
> > >  - Move declarations at beginning of function
> > >  - Use if instead of switch
> > >  - Reword Subject
> > >  
> > >  cmd/pstore.c | 39 ++-
> > >  1 file changed, 34 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/cmd/pstore.c b/cmd/pstore.c
> > > index 9fac8c7218..cd6f6feb2f 100644
> > > --- a/cmd/pstore.c
> > > +++ b/cmd/pstore.c
> > > @@ -11,6 +11,7 @@
> > > 
> > >  #include 
> > >  #include 
> > >  #include 
> > > 
> > > +#include 
> > > 
> > >  struct persistent_ram_buffer {
> > >  
> > >   u32sig;
> > > 
> > > @@ -485,6 +486,8 @@ void fdt_fixup_pstore(void *blob)
> > > 
> > >  {
> > >  
> > >   char node[32];
> > >   int  nodeoffset; 

[PATCH v2] image-fdt: save name of FIT configuration in '/chosen' node

[Daniel Golle]

It can be useful for the OS (Linux) to know which configuration has
been chosen by U-Boot when launching a FIT image.
Store the name of the FIT configuration node used in a new string
property called 'u-boot,bootconf' in the '/chosen' node in device tree.

Signed-off-by: Daniel Golle 
---
v2: change node name to 'u-boot,bootconf' instead of just 'bootconf'

Sibling PR to dt-schema: https://github.com/devicetree-org/dt-schema/pull/71

 boot/image-fdt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 692a9ad3e4..fdb69926a2 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -601,6 +601,12 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
goto err;
}
 
+   /* Store name of configuration node as u-boot,bootconf in /chosen node 
*/
+   if (images->fit_uname_cfg)
+   fdt_find_and_setprop(blob, "/chosen", "u-boot,bootconf",
+   images->fit_uname_cfg,
+   strlen(images->fit_uname_cfg) + 1, 1);
+
/* Update ethernet nodes */
fdt_fixup_ethernet(blob);
 #if CONFIG_IS_ENABLED(CMD_PSTORE)
-- 
2.35.1

Re: [PATCH v2] pstore: Support already existing reserved-memory node

[Daniel Golle]

Hi Detlev,

I've recently tried to update U-Boot from 2022.01 to 2022.04 and
noticed a regression introduced by the commit below.

While the unwanted error message ("Add 'reserved-memory' node failed:
FDT_ERR_EXISTS") no longer appears, I now see a lengthy kernel stack
trace in Linux instead:
...
[0.008295] sysfs: cannot create duplicate filename 
'/devices/platform/42ff.ramoops'
[0.008303] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S
5.15.33 #0
[0.008312] Hardware name: Bananapi BPI-R64 (DT)
[0.008318] Call trace:
[0.008322]  dump_backtrace+0x0/0x15c
[0.008337]  show_stack+0x14/0x30
[0.008345]  dump_stack_lvl+0x64/0x7c
[0.008355]  dump_stack+0x14/0x2c
[0.008362]  sysfs_warn_dup+0x5c/0x74
[0.008373]  sysfs_create_dir_ns+0xb0/0xc0
[0.008381]  kobject_add_internal+0xbc/0x330
[0.008392]  kobject_add+0x80/0xe0
[0.008400]  device_add+0xd4/0x82c
[0.008410]  of_device_add+0x4c/0x5c
[0.008420]  of_platform_device_create_pdata+0xb8/0xf0
[0.008428]  of_platform_default_populate_init+0x58/0xcc
[0.008437]  do_one_initcall+0x4c/0x1b0
[0.008444]  kernel_init_freeable+0x230/0x294
[0.008456]  kernel_init+0x20/0x120
[0.008463]  ret_from_fork+0x10/0x20
[0.008471] kobject_add_internal failed for 42ff.ramoops with -EEXIST, 
don't try to register things with the same name in the same directory.
...

I assume that fdt_find_or_add_subnode() doesn't behave as expected and
apparently adds a duplicate node having the same name.
The pstore/ramoops reserved-memory is already defined in the fdt
contained in the FIT image (for compatibility with older U-Boot which
didn't care about pstore), so it should be not added again.


On Mon, Feb 07, 2022 at 11:02:30AM -0500, Detlev Casanova wrote:
> The pstore command tries to create a reserved-memory node but fails if
> it is already present with:
> 
> Add 'reserved-memory' node failed: FDT_ERR_EXISTS
> 
> This patch creates the node only if it does not exist and adapts the reg
> values sizes depending on already present #address-cells and #size-cells
> values.
> 
> Signed-off-by: Detlev Casanova 
> ---
> 
> Changes in v2:
>  - Move declarations at beginning of function
>  - Use if instead of switch
>  - Reword Subject
> 
>  cmd/pstore.c | 39 ++-
>  1 file changed, 34 insertions(+), 5 deletions(-)
> 
> diff --git a/cmd/pstore.c b/cmd/pstore.c
> index 9fac8c7218..cd6f6feb2f 100644
> --- a/cmd/pstore.c
> +++ b/cmd/pstore.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct persistent_ram_buffer {
>   u32sig;
> @@ -485,6 +486,8 @@ void fdt_fixup_pstore(void *blob)
>  {
>   char node[32];
>   int  nodeoffset;/* node offset from libfdt */
> + u32 addr_cells;
> + u32 size_cells;
>  
>   nodeoffset = fdt_path_offset(blob, "/");
>   if (nodeoffset < 0) {
> @@ -493,14 +496,18 @@ void fdt_fixup_pstore(void *blob)
>   return;
>   }
>  
> - nodeoffset = fdt_add_subnode(blob, nodeoffset, "reserved-memory");
> + nodeoffset = fdt_find_or_add_subnode(blob, nodeoffset, 
> "reserved-memory");
>   if (nodeoffset < 0) {
>   log_err("Add 'reserved-memory' node failed: %s\n",
>   fdt_strerror(nodeoffset));
>   return;
>   }
> - fdt_setprop_u32(blob, nodeoffset, "#address-cells", 2);
> - fdt_setprop_u32(blob, nodeoffset, "#size-cells", 2);
> +
> + addr_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0, 
> "#address-cells", 2);
> + size_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0, 
> "#size-cells", 2);
> + fdt_setprop_u32(blob, nodeoffset, "#address-cells", addr_cells);
> + fdt_setprop_u32(blob, nodeoffset, "#size-cells", size_cells);
> +
>   fdt_setprop_empty(blob, nodeoffset, "ranges");
>  
>   sprintf(node, "ramoops@%llx", (unsigned long long)pstore_addr);
> @@ -509,14 +516,36 @@ void fdt_fixup_pstore(void *blob)
>   log_err("Add '%s' node failed: %s\n", node, 
> fdt_strerror(nodeoffset));
>   return;
>   }
> +
>   fdt_setprop_string(blob, nodeoffset, "compatible", "ramoops");
> - fdt_setprop_u64(blob, nodeoffset, "reg", pstore_addr);
> - fdt_appendprop_u64(blob, nodeoffset, "reg", pstore_length);
> +
> + if (addr_cells == 1) {
> + fdt_setprop_u32(blob, nodeoffset, "reg", pstore_addr);
> + } else if (addr_cells == 2) {
> + fdt_setprop_u64(blob, nodeoffset, "reg", pstore_addr);
> + } else {
> + log_err("Unsupported #address-cells: %u\n", addr_cells);
> + goto clean_ramoops;
> + }
> +
> + if (size_cells == 1) {
> + // Let's consider that the pstore_length fits in a 32 bits value
> + fdt_appendprop_u32(blob, nodeoffset, "reg", pstore_length);
> + } else if (size_cells == 2) {
> + fdt_appendprop_u64(blob, nodeoffset, 

minor regression in U-Boot 2022.04

[Daniel Golle]

Hi!

I'm about to bump the U-Boot build for MediaTek MT7622 boards in
OpenWrt to U-Boot 2022.04. While practially everything seems to work
fine, I've noticed an error message early in the serial output which
was not present in U-Boot 2022.01. It is even followed by a bunch of
random characters which are different on every boot (hints to a
read-out-of-bounds on uninitialzed memory or the like):
serial_mtk serial@11002000: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19�CC�

At another boot:
serial_mtk serial@11002000: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: 
err=-19��H�H�UI��$�1.04-OpenWrt-r19423-c9c2b01b84 (Apr 11 2022 - 19:25:34 
+)

This is probably related to recent changes in dm and pinctrl, as there
haven't been any changes to mtk_serial itself.

Log including ROM and ARM Trusted Firmware A serial output:

F0: 102B 
F6:  
V0:   [0001]
00:  
BP: 0400 0041 []
G0: 1190 
T0:  02AD [000F]
Jump to BL

NOTICE:  BL2: v2.4(release):OpenWrt v2021-05-08-d2c75b21-2 (mt7622-snand-2ddr)
NOTICE:  BL2: Built : 12:03:10, Apr 11 2022
NOTICE:  SPI-NAND: W25N01GV (128MB)
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.4(release):OpenWrt v2021-05-08-d2c75b21-2 (mt7622-snand-2ddr)
NOTICE:  BL31: Built : 12:03:10, Apr 11 2022
serial_mtk serial@11002000: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19�CC�
U-Boot 2022.04-OpenWrt-r19423-c9c2b01b84 (Apr 11 2022 - 19:25:34 +)

CPU:   MediaTek MT7622
Model: mt7622-bpi-r64
DRAM:  1 GiB
Core:  55 devices, 18 uclasses, devicetree: separate
MMC:   mmc@1123: 0, mmc@1124: 1
Loading Environment from UBI... SPI-NAND: W25N01GV (128MB)
...


I will most likely not investigate this any further, but thought it
might be good to let you know.


Best regards


Daniel

Re: [PATCH] image-fdt: save name of FIT configuration in '/chosen' node

[Daniel Golle]

On Tue, Mar 22, 2022 at 10:09:38PM +0100, Heinrich Schuchardt wrote:
> On 3/22/22 14:18, Daniel Golle wrote:
> > Hi Heinrich,
> > 
> > On Tue, Mar 22, 2022 at 09:29:54AM +0100, Heinrich Schuchardt wrote:
> > > On 3/22/22 00:22, Daniel Golle wrote:
> > > > It can be useful for the OS (Linux) to know which configuration has
> > > > been chosen by U-Boot when launching a FIT image.
> > > > Store the name of the FIT configuration node used in a new string
> > > > attribute called 'bootconf' in the '/chosen' node in device tree.
> > > 
> > > Please, point out where you want to use that information. I cannot see
> > > that the Linux kernel will make any use of it.
> > 
> > It can be useful when parsing FIT image in kernel, but can also be
> > useful in userspace (via /sys/firmware/devicetree/base/chosen/bootconf).
> > For OpenWrt I've written a uImage.FIT partition parser in order to
> > allow a single type of firmware image containing kernel, dtb and rootfs
> > to work accross all storage types (SPI-NOR/mtd, NAND/ubi, eMMC/block).
> > 
> > I haven't yet submitted it upstream, exactly because some edges like
> > selection of configuration would need to be discussed first.
> > 
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/block/partitions/fit.c;h=89b5fb3454f0b69cdcfe53958169fb2a6f9c48a9;hb=HEAD
> > 
> > However, it's doing the job for a bunch of OpenWrt boards already,
> > incl. some popular devices
> > 
> > https://openwrt.org/toh/linksys/e8450
> > (boots from SPI-NAND/ubi)
> > 
> > https://openwrt.org/toh/sinovoip/bananapi_bpi-r64_v1.1
> > (can boot from SD Card, eMMC or SPI-NAND/ubi)
> > 
> > Using uImage.FIT to store the squashfs besides kernel and dtb has
> > several obvious advantages which are hard to obtain in any other way:
> >   * single image accross NOR/mtd, NAND/ubi and MMC/block devices
> >   * dynamically sized sub-partitions for kernel and rootfs
> >   * hash also for rootfs checked by U-Boot before launching kernel
> >   * images may include additional filesystems e.g. for localization or
> > brandinge (hence the need to parse the boot configuration when
> > mapping the 'filesystem' subimages into block partitions).
> > 
> > > 
> > > > 
> > > > Signed-off-by: Daniel Golle 
> > > > ---
> > > >boot/image-fdt.c | 6 ++
> > > >1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> > > > index 692a9ad3e4..4017bc94a6 100644
> > > > --- a/boot/image-fdt.c
> > > > +++ b/boot/image-fdt.c
> > > > @@ -601,6 +601,12 @@ int image_setup_libfdt(bootm_headers_t *images, 
> > > > void *blob,
> > > > goto err;
> > > > }
> > > > 
> > > > +   /* Store name of configuration node as bootconf in /chosen node 
> > > > */
> > > > +   if (images->fit_uname_cfg)
> > > > +   fdt_find_and_setprop(blob, "/chosen", "bootconf",
> > > > +   images->fit_uname_cfg,
> > > > +   strlen(images->fit_uname_cfg) + 
> > > > 1, 1);
> > > > +
> > > 
> > > We should not inject arbitrary properties into the device-tree. Where is
> > > the property /chosen/bootconf defined in the Linux documentation or in
> > > the device-tree specification?
> > 
> > > From Linux Documenation (chosen.txt):
> > "The chosen node does not represent a real device, but serves as a place
> >   for passing data between firmware and the operating system, like boot
> >   arguments."
> > 
> > > From Device Tree specification (Release v0.3):
> > "The /chosen node does not represent a real device in the system but
> >   describes parameters chosen or specified by the system firmware at run
> >   time."
> > 
> > So to me it sounds like the right place for an additional attribute
> > serving the above purpose. It could as well become an additional kernel
> > cmdline argument in (ie. appended to 'bootargs' in '/chosen'), but that
> > seemed more complex and harder to deal with.
> > 
> > The name could be changed into something like 'denx,boot-configuration'
> > if 'bootconf' is perceived to be too generic.
> 
> Is this squashfs meant to be served from RAM?

No, it is part of the FIT image which 

Re: [PATCH] image-fdt: save name of FIT configuration in '/chosen' node

[Daniel Golle]

Hi Heinrich,

On Tue, Mar 22, 2022 at 09:29:54AM +0100, Heinrich Schuchardt wrote:
> On 3/22/22 00:22, Daniel Golle wrote:
> > It can be useful for the OS (Linux) to know which configuration has
> > been chosen by U-Boot when launching a FIT image.
> > Store the name of the FIT configuration node used in a new string
> > attribute called 'bootconf' in the '/chosen' node in device tree.
> 
> Please, point out where you want to use that information. I cannot see
> that the Linux kernel will make any use of it.

It can be useful when parsing FIT image in kernel, but can also be
useful in userspace (via /sys/firmware/devicetree/base/chosen/bootconf).
For OpenWrt I've written a uImage.FIT partition parser in order to
allow a single type of firmware image containing kernel, dtb and rootfs
to work accross all storage types (SPI-NOR/mtd, NAND/ubi, eMMC/block).

I haven't yet submitted it upstream, exactly because some edges like
selection of configuration would need to be discussed first.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/block/partitions/fit.c;h=89b5fb3454f0b69cdcfe53958169fb2a6f9c48a9;hb=HEAD

However, it's doing the job for a bunch of OpenWrt boards already,
incl. some popular devices

https://openwrt.org/toh/linksys/e8450
(boots from SPI-NAND/ubi)

https://openwrt.org/toh/sinovoip/bananapi_bpi-r64_v1.1
(can boot from SD Card, eMMC or SPI-NAND/ubi)

Using uImage.FIT to store the squashfs besides kernel and dtb has
several obvious advantages which are hard to obtain in any other way:
 * single image accross NOR/mtd, NAND/ubi and MMC/block devices
 * dynamically sized sub-partitions for kernel and rootfs
 * hash also for rootfs checked by U-Boot before launching kernel
 * images may include additional filesystems e.g. for localization or
   brandinge (hence the need to parse the boot configuration when
   mapping the 'filesystem' subimages into block partitions).

> 
> > 
> > Signed-off-by: Daniel Golle 
> > ---
> >   boot/image-fdt.c | 6 ++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> > index 692a9ad3e4..4017bc94a6 100644
> > --- a/boot/image-fdt.c
> > +++ b/boot/image-fdt.c
> > @@ -601,6 +601,12 @@ int image_setup_libfdt(bootm_headers_t *images, void 
> > *blob,
> > goto err;
> > }
> > 
> > +   /* Store name of configuration node as bootconf in /chosen node */
> > +   if (images->fit_uname_cfg)
> > +   fdt_find_and_setprop(blob, "/chosen", "bootconf",
> > +   images->fit_uname_cfg,
> > +   strlen(images->fit_uname_cfg) + 1, 1);
> > +
> 
> We should not inject arbitrary properties into the device-tree. Where is
> the property /chosen/bootconf defined in the Linux documentation or in
> the device-tree specification?

>From Linux Documenation (chosen.txt):
"The chosen node does not represent a real device, but serves as a place
 for passing data between firmware and the operating system, like boot
 arguments."

>From Device Tree specification (Release v0.3):
"The /chosen node does not represent a real device in the system but
 describes parameters chosen or specified by the system firmware at run
 time."

So to me it sounds like the right place for an additional attribute
serving the above purpose. It could as well become an additional kernel
cmdline argument in (ie. appended to 'bootargs' in '/chosen'), but that
seemed more complex and harder to deal with.

The name could be changed into something like 'denx,boot-configuration'
if 'bootconf' is perceived to be too generic.


Cheers


Daniel

[PATCH] image-fdt: save name of FIT configuration in '/chosen' node

[Daniel Golle]

It can be useful for the OS (Linux) to know which configuration has
been chosen by U-Boot when launching a FIT image.
Store the name of the FIT configuration node used in a new string
attribute called 'bootconf' in the '/chosen' node in device tree.

Signed-off-by: Daniel Golle 
---
 boot/image-fdt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 692a9ad3e4..4017bc94a6 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -601,6 +601,12 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
goto err;
}
 
+   /* Store name of configuration node as bootconf in /chosen node */
+   if (images->fit_uname_cfg)
+   fdt_find_and_setprop(blob, "/chosen", "bootconf",
+   images->fit_uname_cfg,
+   strlen(images->fit_uname_cfg) + 1, 1);
+
/* Update ethernet nodes */
fdt_fixup_ethernet(blob);
 #if CONFIG_IS_ENABLED(CMD_PSTORE)
-- 
2.35.1

Re: [PATCH v10 3/9] env: Allow U-Boot scripts to be placed in a .env file

[Daniel Golle]

On Thu, Oct 21, 2021 at 09:08:46PM -0600, Simon Glass wrote:
> At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we could just type the script into a
> text file and have it included by U-Boot.
> 
> Add a feature that brings in a .env file associated with the board
> config, if present. To use it, create a file in a board/
> directory, typically called .env and controlled by the
> CONFIG_ENV_SOURCE_FILE option.
> 
> The environment variables should be of the form "var=value". Values can
> extend to multiple lines. See the README under 'Environment Variables:'
> for more information and an example.
> 
> In many cases environment variables need access to the U-Boot CONFIG
> variables to select different options. Enable this so that the environment
> scripts can be as useful as the ones currently in the board config files.
> This uses the C preprocessor, means that comments can be included in the
> environment using /* ... */
> 
> Also support += to allow variables to be appended to. This is needed when
> using the preprocessor.

I hope to see this change moving forward!
It would be of great value for use in OpenWrt, as right now a per board
default environment is often included using CONFIG_ENV_SOURCE_FILE and
I was about to convert everything to C precompiler #defines to be more
flexible...
The suggested .env files made possible by this commit would provide an
ideal solution.


> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Marek Behún 
> Tested-by: Marek Behún 
> ---
> 
> Changes in v10:
> - Use backslash to allow assignment to a variable ending in +
> - Add rST file into the index
> - Minor tweaks to the script's pattern matching
> 
> Changes in v9:
> - Drop mention of other strange characters
> - Clarify that the + restriction is on the variable name not its value
> - Add some tests for the script
> - Deal with leading tabs
> - Squash indentation down to one space
> - Convert newlines within strings to spaces, which seems more consistent
> - Handle appending an empty string to an empty var
> 
> Changes in v8:
> - Update commit message to avoid mentioning the 'env' subdirectory
> - Update commit message to mention the + restriction, etc.
> - Overwrite the env file each time, to avoid incremental-build problems
> 
> Changes in v7:
> - Use 'env' basename instead of 'environment' for intermediate output files
> - Show a message indicating the source text file being used
> - Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined
> - Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name
> - Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty
> - Rewrite the documentation
> - Drop the use of common.env
> - Update awk script to output the whole CONFIG string, or just a comment
> 
> Changes in v6:
> - Combine the two env2string.awk patches into one
> 
> Changes in v5:
> - Explain how to include the common.env file
> - Explain why variables starting with _ , and / are not supported
> - Expand the definition of how to declare an environment variable
> - Explain what happens to empty variables
> - Update maintainer
> - Move use of += to this patch
> - Explain that environment variables may not end in +
> 
> Changes in v4:
> - Move this from being part of configuring U-Boot to part of building it
> - Don't put the environment in autoconf.mk as it is not needed
> - Add documentation in rST format instead of README
> - Drop mention of import/export
> - Update awk script to ignore blank lines, as generated by clang
> - Add documentation in rST format instead of README
> 
> Changes in v3:
> - Adjust Makefile to generate the .inc and .h files in separate fules
> - Add more detail in the README about the format of .env files
> - Improve the comment about " in the awk script
> - Correctly terminate environment files with \n
> - Define __UBOOT_CONFIG__ when collecting environment files
> 
> Changes in v2:
> - Move .env file from include/configs to board/
> - Use awk script to process environment since it is much easier on the brain
> - Add information and updated example script to README
> - Add dependency rule so that the environment is rebuilt when it changes
> - Add separate patch to enable C preprocessor for environment files
> - Enable var+=value form to simplify composing variables in multiple steps
> 
>  MAINTAINERS   |   7 +++
>  Makefile  |  66 ++-
>  config.mk |   2 +
>  doc/usage/environment.rst |  81 -
>  doc/usage/index.rst   |   1 +
>  env/Kconfig   |  18 +++
>  env/embedded.c|   1 +
>  include/env_default.h |  11 
>  scripts/env2string.awk|  80 
>  test/py/tests/test_env.py | 107 

Re: U-Boot loaded RAMDisk crashes Linux on MT7623

[Daniel Golle]

Hi again,

On Mon, Jul 19, 2021 at 06:34:38PM +0100, Daniel Golle wrote:
> ...
>Loading Ramdisk to ff4b9000, end ff9fab18 ... OK
>^^
>Using Device Tree in place at 889f9288, end 88a04534
> 
> Starting kernel ...
> ...
> [0.00] Zone ranges:
> [0.00]   Normal   [mem 0x8000-0xafff]
> [0.00]   HighMem  [mem 0xb000-0xefff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x8000-0xefff]
> [0.00] Initmem setup node 0 [mem 
> 0x8000-0xefff]
> [0.00] 8<--- cut here ---
> [0.00] Unable to handle kernel paging request at virtual address 
> 3f9fab0c
> 
> ^^
> ...

I've found the answer myself, thanks to another patch posted to this
list, solving the same problem for another board:
[RFC 1/1] board: sifive: unmatched: use zero copy for initrd

So just like there, setting initrd_high (in this case to 0xafff)
solved the problem.

Sorry for the noise :)

U-Boot loaded RAMDisk crashes Linux on MT7623

[Daniel Golle]

Hi,

I writing in the hope that someone has a good idea about why U-boot is
handing over a broken memory address for a loaded ramdisk which results
in Linux crashing very early on boot on MediaTek's MT7623N SoC (ARMv7).
If anyone has a good idea why this is happening, I'd be very glad, as
this currently prevents me from updating that target in OpenWrt.
Background:
OpenWrt used to have the initramdisk built-into the kernel itself.
Having it separate is nicer as then you won't need to recompile the
kernel or even have a compiler installed in order to modify the
ramdisk. This already works great on MT7622 and it'd be great to have
it the same way on MT7623 (and MT7629 in future).

So when loading a uImage.FIT with RAMDisk subimage to me it looks like
U-Boot is not translating the address of the ramdisk correctly, see
logs below:

U-Boot> tftpboot 0x8800 
openwrt-mediatek-mt7623-bpi_bananapi-r2-initramfs-recovery.itb
Using ethernet@1b10 device
TFTP from server 192.168.5.2; our IP address is 192.168.5.100
Filename 'openwrt-mediatek-mt7623-bpi_bananapi-r2-initramfs-recovery.itb'.
Load address: 0x8800
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 13 MiB/s
done
Bytes transferred = 10492520 (a01a68 hex)
U-Boot> bootm
## Loading kernel from FIT Image at 8800 ...
   Using 'config-1' configuration
   Trying 'kernel-1' kernel subimage
 Description:  ARM OpenWrt Linux-5.10.51
 Type: Kernel Image
 Compression:  gzip compressed
 Data Start:   0x88e4
 Data Size:4944975 Bytes = 4.7 MiB
 Architecture: ARM
 OS:   Linux
 Load Address: 0x80008000
 Entry Point:  0x80008000
 Hash algo:crc32
 Hash value:   9da8225f
 Hash algo:sha1
 Hash value:   ea4e69501bed0925ecdee0bb6b3a3b489fedc38c
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading ramdisk from FIT Image at 8800 ...
   Using 'config-1' configuration
   Trying 'initrd-1' ramdisk subimage
 Description:  ARM OpenWrt bpi_bananapi-r2 initrd
 Type: RAMDisk Image
 Compression:  Unknown Compression
 Data Start:   0x884b7668
 Data Size:5511960 Bytes = 5.3 MiB
 Architecture: ARM
 OS:   Linux
 Load Address: unavailable
 Entry Point:  unavailable
 Hash algo:crc32
 Hash value:   01e5fbf0
 Hash algo:sha1
 Hash value:   6ceb78df26920d97dee505ddeb0318e0c1522ba0
   Verifying Hash Integrity ... crc32+ sha1+ OK
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its 
file!
## Loading fdt from FIT Image at 8800 ...
   Using 'config-1' configuration
   Trying 'fdt-1' fdt subimage
 Description:  ARM OpenWrt bpi_bananapi-r2 device tree blob
 Type: Flat Device Tree
 Compression:  uncompressed
 Data Start:   0x889f9288
 Data Size:33453 Bytes = 32.7 KiB
 Architecture: ARM
 Hash algo:crc32
 Hash value:   a2599155
 Hash algo:sha1
 Hash value:   59c64737be8bda92b33417dfadca87e9c4662be2
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x889f9288
   Uncompressing Kernel Image
   Loading Ramdisk to ff4b9000, end ff9fab18 ... OK
   ^^
   Using Device Tree in place at 889f9288, end 88a04534

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.10.51 (daniel@box) 
(arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 8.4.0 r17073+11-8bb4437c01) 
8.4.0, GNU ld (GNU Binutils) 2.34) #0 SMP PREEMPT Mon Jul 19 12:26:15 2021
[0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: Bananapi BPI-R2
[0.00] earlycon: uart8250 at MMIO32 0x11004000 (options '')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x8000-0xafff]
[0.00]   HighMem  [mem 0xb000-0xefff]
[

[PATCH resend] mmc: mtk-sd: don't ignore max-frequency from device tree

[Daniel Golle]

commit e58e68d9 ("mmc: mtk-sd: assign plat->cfg.f_max with a correct value")
wrongly assumed that plat->cfg.f_max is always unset at the time
mscd_drv_probe() is run. This is not true in case max-frequency being
defined in device tree, as it is then already set by mmc_of_parse()
in msdc_of_to_plat().
Only set plat->cfg.f_max to the default maximum value in case it is
not already set to a sane value.

Fixes: e58e68d93e ("mmc: mtk-sd: assign plat->cfg.f_max with a correct value")
Cc: Stefan Roese 
Cc: Weijie Gao 
Signed-off-by: Daniel Golle 
---
 drivers/mmc/mtk-sd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index 3b9c12266a..48a764be82 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -1639,7 +1639,8 @@ static int msdc_drv_probe(struct udevice *dev)
else
cfg->f_min = host->src_clk_freq / (4 * 4095);
 
-   cfg->f_max = host->src_clk_freq;
+   if (cfg->f_max < cfg->f_min || cfg->f_max > host->src_clk_freq)
+   cfg->f_max = host->src_clk_freq;
 
cfg->b_max = 1024;
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
-- 
2.30.2



signature.asc
Description: PGP signature

Re: [U-Boot] [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2

[Daniel Golle]

Hi Richard,

On Thu, Aug 11, 2016 at 11:51:10AM +0200, Richard Weinberger wrote:
> Hi!
> 
> On Thu, Aug 11, 2016 at 4:26 AM, J Mo  wrote:
> > I tried re-flashing my UBI and tftpbooting my kernel before u-boot could
> > ever get a chance to mangle it, and now I get much further, though I'm still
> > not able to mount my rootfs for unknown reasons:
> >
> > [3.772502] ubi0: attaching mtd11
> > [3.826477] UBI: EOF marker found, PEBs from 40 will be erased
> 
> WTF is this?
> Reading the corresponding patch makes me very sad.

Understandable. However, we also need to experiment and figure out the
mess left behind by $vendor which often doesn't leave a lot of
reasonable options for 3rd-party firmware to be installed.
With regard to that specific hack, I never truly understood why it was
needed in first place -- I'm not using it on any UBI-enabled device and
believe it's some kind of work-around to allow ubinized images to be
written via nandwrite, initially in order to support the vendor/stock
sysupgrade-format of a specific device (NETGEAR WNDR4300). Please
correct me or add the missing bits needed to understand the use-case.
It was added to OpenWrt long ago in r38681...r38683 and by now needed
to be fixed several times in r42940, r43287, r44658, r44801 and r44881.
Later on it was re-used by a bunch of other devices, e.g.
bcm4708-netgear-r6250, bcm4708-netgear-r6300-v2,
bcm4708-buffalo-wzr-1750dhp, bcm47081-buffalo-wzr-600dhp2 and probably
some more.

Gabor and Rafal should know more about it and why exactly this is
needed and supposedly cannot be solved without this hack.


> 
> > [3.826638] ubi0: scanning is finished
> > [3.872936] ubi0: volume 2 ("rootfs_data") re-sized from 9 to 430
> > LEBs
> > [3.873734] ubi0: attached mtd11 (name "rootfs", size 64 MiB)
> > [3.878347] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976
> > bytes
> > [3.884234] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size
> > 2048
> > [3.890936] ubi0: VID header offset: 2048 (aligned 2048), data
> > offset: 4096
> > [3.897849] ubi0: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
> > [3.904627] ubi0: user volume: 3, internal volumes: 1, max. volumes
> > count: 128
> > [3.910815] ubi0: max/mean erase counter: 1/0, WL threshold: 4096,
> > image sequence number: 2142265782
> > [3.917902] ubi0: available PEBs: 0, total reserved PEBs: 512, PEBs
> > reserved for bad PEB handling: 40
> > [3.927275] ubi0: background thread "ubi_bgt0d" started, PID 54
> > [3.937007] block ubiblock0_1: created from ubi0:1(rootfs)

This line hints that the rootfs is non-UBIFS and thus a ubiblock device
has been created.

> > [3.942096] hctosys: unable to open rtc device (rtc0)
> > [3.956528] VFS: Cannot open root device "ubi0:rootfs" or
> > unknown-block(31,11): error -2

That lack of a line like
[3.937296] ubiblock: device ubiblock0_3 (rootfs) set to be root filesystem
indicates that ROOT_DEV is already set, e.g. via the kernel's cmdline
using the "rootfs=ubi0:rootfs" parameter. As the rootfs isn't UBIFS,
this won't work. Check your bootloader's environment or any other
sources for kernel cmdline fragments (various OpenWrt/LEDE specific
hacks but also the device-tree for things like
chosen { bootargs = "..." }
which try to hard-code the rootfs to ubi0:rootfs.


> > [3.956556] Please append a correct "root=" boot option; here are the
> > available partitions:


> >
> >
> >
> > Any advice on this? Any background information that I can read up on? My
> > google searches have not come up with much. Ram knew about this, but I don't
> > know if it's otherwise a known issue.

Right. Depending on whether U-Boot's UBI support or the kernel itself
first touches the freshly-written UBI device things go wrong, becase
only the hacked-up OpenWrt/LEDE kernel does the right magic on
firstboot...


Cheers


Daniel

> >
> > The process works fine on the OEM system, so I assume this is some ubinize
> > format change which is incompatible with the older u-boot. Or, the newer
> > kernel code doesn't know how to deal with the UBI once the older u-boot has
> > mangled/attached it.
> >
> > Seems like a backwards incompatibility issue.
> 
> Since OpenWRT/LEDE folks did more or less a hard fork of UBI I'm
> ignoring this issue.
> If you encounter something like that using vanilla UBI I'm all ears.
> 
> That said, I kind of understand that you, OpenWRT/LEDE, have a pile of
> patches for auto probing rootfs
> and other runtime stuff but touching the UBI on-flash format is beyond funny.
> Doing so opens a can of worms and is painful for all parties. There
> are customers which build their
> products using OpenWrt and when they change the kernel at some point
> it will get nasty.
> 
> This situation needs to be improved now. I invite you to discuss this
> changes here on linux-mtd.
> Especially the stuff where you change the 

Re: [U-Boot] [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2

[Daniel Golle]

Hi J,

On Thu, Aug 11, 2016 at 06:15:32AM -0700, J Mo wrote:
> 
> 
> On 08/11/2016 05:31 AM, Daniel Golle wrote:
> > That's what I told you in the previous mail, removing the rootfs=
> > parameter from the dts should do the trick, because you just cannot
> > mount a ubi device (which is a character device in Linux) with a
> > block-based filesystem (like squashfs). This cannot and won't ever
> > work and you could either leave it to OpenWrt/LEDE's auto-probing to
> > figure out what to do based on the rootfs type (non-ubifs vs. ubifs)
> > or append even more board- and filesystem-specific crap to your cmdline
> > such as ubiblock=... root=/dev/ubiblock0_1 (however, that then won't
> > work for ubifs, thus the auto-probing patches).
> 
> ... OH!
> 
> Well, I needed some extra intellectual clubbing to catch on.
> 
> NOW I remember reading the UBI docs, about glubi, the fact that volumes are
> char devices, and I even seem to remember some ALL CAPS red size-20+ text at
> the top of the page saying something about it.
> 
> Tomorrow I'll go read the docs again, because I know I remember reading that
> you could put a RO-squashfs in a UBI volume.  I just need to have it mounted
> the right way.

Exactly. However, this makes mounting a UBIFS volume entirely different
from mounting a volume with any other (read-only) filesystem which
needs a ubiblock device (gluebi has been deprecated in favour of
ubiblock) to be created and subsequently mounted.
The idea of the auto-probing patches [1] was to keep things filesystem-
agnostic, ie. allow for either a single read-write UBIFS rootfs or any
read-only filesystem (e.g. squashfs) which needs ubiblock and have a
UBIFS read-write overlay on top.
In this way, all you have to take care of is *not* to have any rootfs=
or ubi* parameters in your kernel cmdline and all the rest should
happen automagically.


Cheers


Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2

[Daniel Golle]

On Thu, Aug 11, 2016 at 02:22:58PM +0200, Richard Weinberger wrote:
> Did you intentional drop linux-mtd from the CC's after I offered you
> to discuss your patches on linux-mtd? ;-)

I replied twice, once including all the CC's with the intention to
contribute to the general debate. And once to lede-dev, you and J Mo
intending to support J Mo creating board-support and figuring out how
to work with UBI in OpenWrt/LEDE which I assumed would be considered
noise for most readers of the other lists involved.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2

[Daniel Golle]

Hi,

On Thu, Aug 11, 2016 at 05:18:08AM -0700, J Mo wrote:
> 
> 
> On 08/11/2016 04:28 AM, J Mo wrote:
> > 
> > Hm, I just found another example. I don't know why this didn't turn up
> > in my searches yesterday since it's a perfect match with the EXACT
> > error. This too was on a QSDK AP148:
> > 
> > https://patchwork.ozlabs.org/patch/509468/
> > 
> > I think I'll go rip that patch out here in a bit, recompile my image,
> > and see what happens.
> 
> 
> Yep, I just ripped out that patch, rebuilt, and the UBI is working
> correctly-ish now:
> 
> [3.781400] ubi0: attaching mtd11
> [4.475744] ubi0: scanning is finished
> [4.490924] ubi0 warning: print_rsvd_warning: cannot reserve enough PEBs
> for bad PEB handling, reserved 5, need 40
> [4.492040] ubi0: attached mtd11 (name "rootfs", size 64 MiB)
> [4.500155] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976
> bytes
> [4.506033] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
> [4.512808] ubi0: VID header offset: 2048 (aligned 2048), data offset:
> 4096
> [4.519603] ubi0: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
> [4.526430] ubi0: user volume: 3, internal volumes: 1, max. volumes
> count: 128
> [4.532680] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image
> sequence number: 1454555262
> [4.539660] ubi0: available PEBs: 0, total reserved PEBs: 512, PEBs
> reserved for bad PEB handling: 5
> [4.549141] ubi0: background thread "ubi_bgt0d" started, PID 54
> [4.558711] block ubiblock0_1: created from ubi0:1(rootfs)
> [4.563771] hctosys: unable to open rtc device (rtc0)
> [4.576690] VFS: Cannot open root device "ubi0:rootfs" or
> unknown-block(31,11): error -2
> [4.576718] Please append a correct "root=" boot option; here are the
> available partitions:
> [4.583956] 1f00 256 mtdblock0  (driver?)
> [4.596076] 1f011280 mtdblock1  (driver?)
> [4.601109] 1f021280 mtdblock2  (driver?)
> [4.606144] 1f032560 mtdblock3  (driver?)
> [4.611178] 1f041152 mtdblock4  (driver?)
> [4.616214] 1f051152 mtdblock5  (driver?)
> [4.621249] 1f062560 mtdblock6  (driver?)
> [4.626283] 1f072560 mtdblock7  (driver?)
> [4.631319] 1f085120 mtdblock8  (driver?)
> [4.636352] 1f09 512 mtdblock9  (driver?)
> [4.641387] 1f0a 512 mtdblock10  (driver?)
> [4.646423] 1f0b   65536 mtdblock11  (driver?)
> [4.651544] 1f0c 384 mtdblock12  (driver?)
> [4.65] 1f0d5120 mtdblock13  (driver?)
> [4.661786] 1f0e   65536 mtdblock14  (driver?)
> [4.666909] fe002728 ubiblock0_1  (driver?)
> [4.672103] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(31,11)
> 
> 
> My squashfs root isn't mounting but that's another patch/issue.

That's what I told you in the previous mail, removing the rootfs=
parameter from the dts should do the trick, because you just cannot
mount a ubi device (which is a character device in Linux) with a
block-based filesystem (like squashfs). This cannot and won't ever
work and you could either leave it to OpenWrt/LEDE's auto-probing to
figure out what to do based on the rootfs type (non-ubifs vs. ubifs)
or append even more board- and filesystem-specific crap to your cmdline
such as ubiblock=... root=/dev/ubiblock0_1 (however, that then won't
work for ubifs, thus the auto-probing patches).

> 
> So that 494-mtd-ubi-add-EOF-marker-support.patch has gotta go or get fixed.

I agree, however, once again, it depends on how you write the ubinized
image to the flash in first place.

> It's almost certainly been fking stuff up for a long time and just nobody
> noticed before now because almost nobody has a kernel in their UBI. It

Not true. As I said, I'm using KERNEL_IN_UBI on all oxnas based targets
and also got U-Boot 2014.10 with UBI support touching the flash before
the kernel would fixup anything. Have a look at
target/linux/oxnas/image/Makefile for a 100% working example.

> wasn't in OpenWRT AA/12.09, so it wasn't in the QSDK which my device is
> based on.


Please read my previous email (I hope you actually received it?) for
more details.



Cheers


Daniel

> 
> 
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] tools/env: add support for ubi volume chardev

[Daniel Golle]

Hi!

fw_printenv/fw_setenv in tools/env currently doesn't support
readring/writing directly from UBI volumes, which is supported in
U-Boot itself since commit 2b74433f365fa677a60431a80e524b5d8d04e995.

At that time gluebi mtd devices were widely used though never meant to
be more than a legacy-hack. Kconfig clearly states
Do not enable this unless you use legacy software.
Using gluebi with fw_printenv/fw_setenv is also quite dangerous, as
numbering (and thus device names) of gluebi-emulated mtd devices is
not consistent.

As of today, ubiblock provides a much more conveniant way to access
squashfs filesystems in UBI volumes and was included in linux.git
in commit 9d54c8a33eec78289b1b3f6e10874719c27ce0a7.
Most likely this is going to further reduce the use-cases where gluebi
is needed. ubiblock devices, however, are read-only and cannot be used
for fw_setenv.

In the attempt to build a legacy-free system without gluebi, I added
support for reading/writing the U-Boot environment directly from/to
a UBI volume character device using libubi from mtd-utils
http://git.infradead.org/mtd-utils.git/tree/HEAD:/ubi-utils
The library is currently used only internally by ubi-utils and thus
not installed or available for linking right now.
Can mtd-utils/ubi-utils be changed to install libubi.a and the
required headers so U-Boot's env-tool could link it?

If not, the remaining options are to either clone libubi (or the
needed parts of it) into the U-Boot sources or directly call that bunch
of ioctls in the tool without using libubi at all.
Which of these options would be preferable?

I'm also not clear about how to properly integrate that into U-Boot's
build system and currently use an additional make variable which
allows to select whether or not to build support for UBI volumes.
I tried to implement this in a way that makes it easy to verify that
the existing codepaths are not hurt in case UBI support is disabled.

Thank you for your advise!

Daniel
--


Signed-off-by: Daniel Golle dan...@makrotopia.org
---
 tools/env/Makefile |  5 
 tools/env/fw_env.c | 74 ++
 2 files changed, 69 insertions(+), 10 deletions(-)

diff --git a/tools/env/Makefile b/tools/env/Makefile
index f5368bc..d006a93 100644
--- a/tools/env/Makefile
+++ b/tools/env/Makefile
@@ -20,6 +20,11 @@ ifeq ($(MTD_VERSION),old)
 HOST_EXTRACFLAGS += -DMTD_OLD
 endif
 
+ifeq ($(UBI),y)
+HOST_EXTRACFLAGS += -DUBI
+HOST_LOADLIBES = -lubi
+endif
+
 always := fw_printenv
 hostprogs-y := fw_printenv_unstripped
 
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 30d5b03..5c0acd5 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -29,6 +29,9 @@
 # include mtd/mtd-user.h
 #endif
 
+#ifdef UBI
+# include libubi.h
+#endif
 #include fw_env.h
 
 #include aes.h
@@ -809,6 +812,11 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
off_t top_of_range; /* end of the last block we may use */
loff_t blockstart;  /* running start of the current block -
   MEMGETBADBLOCK needs 64 bits */
+#ifdef UBI
+   libubi_t *libubi = NULL;/* pointer to libubi struct */
+#else
+   void *libubi = NULL;
+#endif
int rc;
 
/*
@@ -914,7 +922,30 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
continue;
}
 
-   if (mtd_type != MTD_ABSENT) {
+#ifdef UBI
+   if (mtd_type == MTD_UBIVOLUME) {
+   struct ubi_vol_info volinfo;
+   libubi = libubi_open();
+   if (libubi)
+   rc = !ubi_get_vol_info(libubi,
+   DEVNAME(dev_current), volinfo);
+   if (libubi  !rc) {
+   erasesize = volinfo.leb_size;
+   int leb = blockstart / erasesize;
+   if (volinfo.type != UBI_STATIC_VOLUME)
+   rc = ubi_leb_change_start(libubi, fd,
+   leb, erasesize);
+   else
+   rc = ubi_update_start(libubi, fd,
+   erasesize);
+   }
+   if (libubi  rc) {
+   libubi_close(libubi);
+   libubi = NULL;
+   }
+   }
+#endif
+   if (!libubi  mtd_type != MTD_ABSENT) {
erase.start = blockstart;
ioctl(fd, MEMUNLOCK, erase);
/* These do not need an explicit erase cycle */
@@ -931,7 +962,8 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
fprintf (stderr,
 Seek error on %s: %s\n