Re: [PATCH v3] Provide more details of exactly how configuration signatures are calculated

2022-08-03 Thread Michael Nazzareno Trimarchi
Hi

On Thu, Aug 4, 2022 at 8:29 AM Martin Bonner  wrote:
>
> > Signed-off-by: Martin Bonner 
>
> Does it matter that v3 is signed off by martingreybe...@gmail.com but emailed 
> by martin.bon...@entrust.com?
>
> *I* know that they are the same person, but you only have my word for that.  
> (OTOH, you can compare this patch to v2 and see they are the same.)
>

Can you just git commit --amend --author="Martin Bonner
" --sighoff="Martin Bonner
"? and then use
git send-email?

[sendemail]
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpencryption = tls
smtpuser = Martin Bonner 
smtppass = 
suppresscc = self

What is your scope? using gmail to send and confirm the corporate work?

Michael
> --
> Martin Bonner
>
>
> -Original Message-
> From: U-Boot  On Behalf Of Martin Bonner
> Sent: 03 August 2022 17:32
> To: u-boot@lists.denx.de
> Subject: [EXTERNAL] [PATCH v3] Provide more details of exactly how 
> configuration signatures are calculated
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the 
> content is safe.
>
> __
> The only changes from [PATCH v2] are
> 1. It is (I think) a valid patch file
> 2. It has come from my corporate email address (which surprisingly forces 
> less mangling than gmail).
> 3. I have extended the commit message slightly
>
> Apologies for the irrelevant email footer - it is automatically added by 
> corporate IT.
>
> Please apply with:
> git am --scissors file.eml
>
> -- >8 --
>
> Describe exactly which bytes are hashed and in what order so that external 
> tools can calculate a valid signature.
>
> Signed-off-by: Martin Bonner 
> ---
>  doc/uImage.FIT/signature.txt | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt 
> index 61a72db3c7..c71280b63b 100644
> --- a/doc/uImage.FIT/signature.txt
> +++ b/doc/uImage.FIT/signature.txt
> @@ -382,6 +382,32 @@ verified later even if the FIT has been signed with 
> other keys in the  meantime.
>
>
> +Details
> +---
> +The signature node contains a property ('hashed-nodes') which lists all
> +the nodes that the signature was made over.  The image is walked in
> +order and each tag processed as follows:
> +- DTB_BEGIN_NODE: The tag and the following name are included in the
> +signature
> +  if the node or its parent are present in 'hashed-nodes'
> +- DTB_END_NODE: The tag is included in the signature if the node or its
> +parent
> +  are present in 'hashed-nodes'
> +- DTB_PROPERTY: The tag, the length word, the offset in the string
> +table, and
> +  the data are all included if the current node is present in 'hashed-nodes'
> +  and the property name is not 'data'.
> +- DTB_END: The tag is always included in the signature.
> +- DTB_NOP: The tag is included in the signature if the current node is
> +present
> +  in 'hashed-nodes'
> +
> +In addition, the signature contains a property 'hashed-strings' which
> +contains the offset and length in the string table of the strings that
> +are to be included in the signature (this is done last).
> +
> +IMPORTANT:  To verify the signature outside u-boot, it is vital to not
> +only calculate the hash of the image and verify the signature with
> +that, but also to calculate the hashes of the kernel, fdt, and ramdisk
> +images and check those match the hash values in the corresponding 'hash*' 
> subnodes.
> +
> +
>  Verification
>  
>  FITs are verified when loaded. After the configuration is selected a list
> --
> Martin Bonner
> martin.bon...@entrust.com
>
> Any email and files/attachments transmitted with it are confidential and are 
> intended solely for the use of the individual or entity to whom they are 
> addressed. If this message has been sent to you in error, you must not copy, 
> distribute or disclose of the information it contains. Please notify Entrust 
> immediately and delete the message from your system.



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


RE: [PATCH v3] Provide more details of exactly how configuration signatures are calculated

2022-08-03 Thread Martin Bonner
> Signed-off-by: Martin Bonner 

Does it matter that v3 is signed off by martingreybe...@gmail.com but emailed 
by martin.bon...@entrust.com?

*I* know that they are the same person, but you only have my word for that.  
(OTOH, you can compare this patch to v2 and see they are the same.)

-- 
Martin Bonner


-Original Message-
From: U-Boot  On Behalf Of Martin Bonner
Sent: 03 August 2022 17:32
To: u-boot@lists.denx.de
Subject: [EXTERNAL] [PATCH v3] Provide more details of exactly how 
configuration signatures are calculated

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the 
content is safe.

__
The only changes from [PATCH v2] are
1. It is (I think) a valid patch file
2. It has come from my corporate email address (which surprisingly forces less 
mangling than gmail).
3. I have extended the commit message slightly

Apologies for the irrelevant email footer - it is automatically added by 
corporate IT.

Please apply with:
git am --scissors file.eml

-- >8 --

Describe exactly which bytes are hashed and in what order so that external 
tools can calculate a valid signature.

Signed-off-by: Martin Bonner 
---
 doc/uImage.FIT/signature.txt | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index 
61a72db3c7..c71280b63b 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -382,6 +382,32 @@ verified later even if the FIT has been signed with other 
keys in the  meantime.


+Details
+---
+The signature node contains a property ('hashed-nodes') which lists all 
+the nodes that the signature was made over.  The image is walked in 
+order and each tag processed as follows:
+- DTB_BEGIN_NODE: The tag and the following name are included in the 
+signature
+  if the node or its parent are present in 'hashed-nodes'
+- DTB_END_NODE: The tag is included in the signature if the node or its 
+parent
+  are present in 'hashed-nodes'
+- DTB_PROPERTY: The tag, the length word, the offset in the string 
+table, and
+  the data are all included if the current node is present in 'hashed-nodes'
+  and the property name is not 'data'.
+- DTB_END: The tag is always included in the signature.
+- DTB_NOP: The tag is included in the signature if the current node is 
+present
+  in 'hashed-nodes'
+
+In addition, the signature contains a property 'hashed-strings' which 
+contains the offset and length in the string table of the strings that 
+are to be included in the signature (this is done last).
+
+IMPORTANT:  To verify the signature outside u-boot, it is vital to not 
+only calculate the hash of the image and verify the signature with 
+that, but also to calculate the hashes of the kernel, fdt, and ramdisk 
+images and check those match the hash values in the corresponding 'hash*' 
subnodes.
+
+
 Verification
 
 FITs are verified when loaded. After the configuration is selected a list
--
Martin Bonner
martin.bon...@entrust.com

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system.


Re: Submitting patches

2022-08-03 Thread Martin Bonner
On Wed, 3 Aug 2022 at 19:14, Simon Glass  wrote:

> Hi Martin,
>
> On Wed, 3 Aug 2022 at 04:05, Martin Bonner 
> wrote:
> >
> > I and my colleagues have a number of patches we would like to
> > contribute back to the community, however for various reasons
> > (principally operating inside corporate firewalls), it isn't possible
> > to use `git send-email`, and I haven't been able to create a plain
> > text email which is acceptable to `git am`.
>
> The workaround here is perhaps to create a gmail address for
> submissions. I think quite a few people do that.

Interesting.  I am using gmail (because I assumed that the corporate email
would mangle stuff), but I can't get it to work.

Surprisingly, I think that Office365 email is actually _more_ compliant
with the way the u-boot process works.

But a firewall that
> blocks 'git send-email' is not really compatible with open source
> collaboration, so I'd encourage you to get the problem resolved.
>

That's completely impossible.  Corporate IT will let us push patches
upstream if we like, but they absolutely are not going to change their
policies and infrastructure to let that happen.

Be aware that plain text email is no longer something that it is safe to
assume everyone has access to.  Obviously everyone actively involved in the
development of u-boot has, but there are a number of potential developers
who don't, and my sense is that that number is growing.  It won't put off
people who are going to become core developers, but it will put off people
who want to suggest a small improvement here, or fix an obscure bug there.

>
> >
> > Is it possible to fork u-boot on Git[HL][au]b or similar hosting site,
> > and then send an email to the list pointing at the commit?
>
> Regards,
> Simon
>


Re: [PATCH 1/1] block: fix blk_get_devnum_by_typename()

2022-08-03 Thread Heinrich Schuchardt




On 8/3/22 20:14, Simon Glass wrote:

Hi Heinrich,

On Tue, 2 Aug 2022 at 10:22, Heinrich Schuchardt
 wrote:




On 8/2/22 14:41, Simon Glass wrote:

Hi Heinrich,

On Tue, 2 Aug 2022 at 03:50, Heinrich Schuchardt
 wrote:


Both the 'host' and the 'efiloader' block devices use the same parent
uclass root. Thus the parent uclass is not an indicator the interface type.

Currently the following fails:

  setenv efi_selftest block device
  bootefi selftest
  part list efiloader 0

Struct blk_desc contains the interface type. So we can check it directly
without caring about the parent uclass.

Signed-off-by: Heinrich Schuchardt 
---
   drivers/block/blk-uclass.c | 10 +++---
   1 file changed, 3 insertions(+), 7 deletions(-)


We've had this discussion before, but this patch will make it


Yes, you blocked the obvious solution.


Yes, I explained the problem with that at the time.




difficult to migrate away from IF_TYPE.


My patch does not have any impact on the migration as function
blk_get_devnum_by_typename() will simply vanish together with IF_TYPE.

Migrating away from IF_TYPE could follow the following path if you
wanted to keep struct blk_desc:

Just replace devnum by the udevice in struct blk_desc and add the GUI
representation of the device type (e.g. "mmc") as field to struct blk_ops.

The field devnum only made sense in the world of legacy drivers.
By the way why do I still find CONFIG_IS_ENABLED(BLK) in block drivers?

A better solution would be to completely do away with struct blk_desc
and instead always use the udevice.



Instead we should fix EFI. Having the root as a parent of a block
device seems wrong to me. What is the actual device that provides the
block device?


There is no actual parent device. In
lib/efi_selftest/efi_selftest_block_device.c the block device is a RAM
disk. This is the same situation as with the sandbox host device where
you have chosen root as the dummy parent for good reason.


Is it a RAM disk on disk, or an in-memory one?


With the patch it is just an memory area embedded the U-Boot binary. But 
in future you might also use it to declare a memory area in the rest of 
RAM as backing a RAM disk.






In
"[1/1] drivers: add memory disk support"
https://patchwork.ozlabs.org/project/uboot/patch/20220419211641.316935-1-heinrich.schucha...@canonical.com/
I have proposed a further block device type that has no actual parent.

The idea of using a parent device to match a block device was always a
dead end. Let's bury it now.


Possibly, but it is how we can drop the IF_TYPE stuff. Let me spend a
bit of time looking at this and see what can be done.


To me the device driver of the actual device would be the most natural 
indicator of the device type. Looking forward to your suggestion.


Best regards

Heinrich



[..]

Regards,
Simon


Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method

2022-08-03 Thread Tony Dinh
Hi Pali,

On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár  wrote:
>
> On Tuesday 02 August 2022 15:13:13 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár  wrote:
> > >
> > > Hello! We have tested that A385 BootROM on Turris Omnia board is much
> > > slower when reading proper U-Boot from SPI NOR than native SPL SPI
> > > driver.
> > >
> > > If you have different test results on A385, could you check SPI speed
> > > used by U-Boot? I think that CONFIG_SF_DEFAULT_SPEED should define it.
> > > For Omnia we use CONFIG_SF_DEFAULT_SPEED=4000. Also check value of
> > > DT property spi-max-frequency. We have: spi-max-frequency = <4000>;
> >
> > It seems the spi-max-frequency = <5000> in the DTS took precedence here?
>
> I'm not sure. It is possible that config option has higher priority. Try
> to set both values to same speed.

That's exactly what has caused the SPL SPI driver to slow down. Once I
set the configurations for the default and the max to the same speed,
SPL SPI driver boots instantly (no observable delay).

CONFIG_ENV_SPI_MAX_HZ=5000
CONFIG_SF_DEFAULT_SPEED=5000
(and spi-max-frequency = <5000> in the DTS)

It is noticeably faster than BootROM loading the u-boot image, which
takes an observable fraction of a second.

So somewhere in the SPL SPL driver, the logic needs some improvement.
Setting default speed and max speed to the same value apparently has
short-circuit that logic.

Thanks,
Tony





>
> > #grep CONFIG_SF_DEFAULT_SPEED .config
> > CONFIG_SF_DEFAULT_SPEED=100
> >
> > #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
> > spi-max-frequency = <5000>;
> >
> > Thanks,
> > Tony
> >
> >
> > > On Tuesday 02 August 2022 14:50:32 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > It works great!
> > > >
> > > > An observation: BootROM boot method is a lot faster than SPL SPI
> > > > driver method on this Armada 385 board. The BootROM took a fraction of
> > > > a second to load the u-boot image. SPL SPI driver took a few seconds
> > > > to load. Perhaps the SPI flash speed vs some probing code in SPL SPI
> > > > driver? I also include the boot log after signature.
> > > >
> > > > Tested-by: Tony Dinh 
> > > >
> > > > Thanks,
> > > > Tony
> > > >
> > > > 
> > > >
> > > > BootROM - 1.73
> > > > Booting from SPI flash
> > > >
> > > > U-Boot SPL 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 
> > > > -0700)
> > > > High speed PHY - Version: 2.0
> > > > Detected Device ID 6820
> > > > board SerDes lanes topology details:
> > > >  | Lane # | Speed |  Type   |
> > > >  
> > > >  |   0|   0   | SGMII0 |
> > > >  |   1|   6   | SATA0 |
> > > >  |   4|   5   | USB3 HOST0 |
> > > >  |   5|   5   | USB3 HOST1 |
> > > >  
> > > > High speed PHY - Ended Successfully
> > > > mv_ddr: 14.0.0
> > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > > > mv_ddr: completed successfully
> > > > Trying to boot from SPI
> > > > Invalid bus 0 (err=-19)
> > > > SPI probe failed.
> > > > Trying to boot from BOOTROM
> > > > Returning to BootROM (return address 0x05c4)...
> > > > BootROM: Image checksum verification PASSED
> > > >
> > > >
> > > > U-Boot 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 
> > > > -0700)
> > > > Synology DS116
> > > >
> > > > SoC:   MV88F6820-A0 at 1866 MHz
> > > > DRAM:  1 GiB (933 MHz, 32-bit, ECC not enabled)
> > > > Core:  41 devices, 18 uclasses, devicetree: separate
> > > > MMC:
> > > > Loading Environment from SPIFlash... SF: Detected mx25l6405d with page
> > > > size 256 Bytes, erase size 4 KiB, total 8 MiB
> > > > OK
> > > > Model: Synology DS116
> > > > Board: Synology DS116
> > > > Net:   eth0: ethernet@7
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > 
> > > >
> > > >
> > > > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár  wrote:
> > > > >
> > > > > BootROM boot method should always work so always add it as fallback 
> > > > > method
> > > > > to spl_boot_list. In case U-Boot SPI driver fails it is better to try 
> > > > > using
> > > > > BootROM than hanging as by default only one boot method is specified.
> > > > >
> > > > > Signed-off-by: Pali Rohár 
> > > > > ---
> > > > >  arch/arm/mach-mvebu/spl.c | 7 +++
> > > > >  1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> > > > > index 13c99913c380..bfcba2e73bab 100644
> > > > > --- a/arch/arm/mach-mvebu/spl.c
> > > > > +++ b/arch/arm/mach-mvebu/spl.c
> > > > > @@ -271,6 +271,13 @@ u32 spl_boot_device(void)
> > > > > }
> > > > >  }
> > > > >
> > > > > +void board_boot_order(u32 *spl_boot_list)
> > > > > +{
> > > > > +   spl_boot_list[0] = spl_boot_device();
> > > > > +   if (spl_boot_list[0] != BOOT_DEVICE_BOOTROM)
> > > > > +   spl_boot_list[1] = BOOT_DEVICE_BOOTROM;
> > > > > +}
> > > > > +
> > > > >  #else
> > > > >
> > > > 

Re: EFI CI failure

2022-08-03 Thread Heinrich Schuchardt




On 8/3/22 20:13, Simon Glass wrote:

Hi Heinrich,

I am seeing this:

https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/477636


The EFI sub-system recorded successful execution of the test.

Rebooting the system (u_boot_console.restart_uboot()) did not reach the
console prompt. Here is the last output as recorded in
https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/477636/raw :

U-Boot 2022.10-rc1-00202-g1be8ed24df (Aug 03 2022 - 08:55:14 +)

CPU:   QEMU Virtual CPU version 2.5+
DRAM:  128 MiB
Core:  16 devices, 14 uclasses, devicetree: separate
Loading Environment from nowhere... OK

I don't know why qemu-x86 is too slow here. It would be helpful if you
could change the exception class Timeout to provide the timeout value as
argument.

Please, replace
raise Timeout()
bye
raise Timeout(self.timeout)
in test/py/u_boot_spawn.py to let us know if the timeout value is less
then 3 ms (two code positions).

Best regards

Heinrich



_ test_efi_selftest_text_input _
test/py/tests/test_efi_selftest.py:116: in test_efi_selftest_text_input
 u_boot_console.restart_uboot()
test/py/u_boot_console_base.py:459: in restart_uboot
 self.ensure_spawned(expect_reset)
test/py/u_boot_console_base.py:423: in ensure_spawned
 self.wait_for_boot_prompt(loop_num = loop_num)
test/py/u_boot_console_base.py:180: in wait_for_boot_prompt
 m = self.p.expect([self.prompt_compiled,
test/py/u_boot_spawn.py:193: in expect
 raise Timeout()
E   u_boot_spawn.Timeout
- Captured stdout call -

Do you have any ideas what causes it?

Regards,
Simon


Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Chris Packham
On Thu, Aug 4, 2022 at 5:44 AM Tom Rini  wrote:
>
> On Wed, Aug 03, 2022 at 07:27:50PM +0200, Heinrich Schuchardt wrote:
> > On 8/3/22 18:26, Quentin Schulz wrote:
> > > Hi Tom,
> > >
> > > On 8/3/22 18:08, Tom Rini wrote:
> > > > On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:
> > > >
> > > > > Only five boards are left that need to be migrated to DM_GPIO. Set a
> > > > > 2023.04 deadline.
> > > > >
> > > > > * edminiv2_defconfig
> > > > > * mx28evk_auart_console_defconfig
> > > > > * mx28evk_nand_defconfig
> > > > > * mx28evk_spi_defconfig
> > > > > * warp_defconfig
> > > > >
> > > > > Signed-off-by: Heinrich Schuchardt 
> > > >
> > > > I see you've now ack'd Fabio's patch to remove those mx28 configs.
> > > > Here's my patch to remove edminiv2:
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/
> > > >
> > > > That leaves just "warp", which is missing a ton of conversions, so let
> > > > me just post a removal patch instead and see where it goes.
> > > >
> > >
> > > I guess this would also mean the removal of GPIO drivers that haven't
> > > moved to DM?
> > >
> > > # git grep -L UCLASS drivers/gpio/*.c
> > > drivers/gpio/adi_gpio2.c
> > > drivers/gpio/kona_gpio.c
> > > drivers/gpio/kw_gpio.c
> > > drivers/gpio/mpc83xx_gpio.c
> > > drivers/gpio/mvgpio.c
> > > drivers/gpio/pca953x.c
> > > drivers/gpio/pca9698.c
> > > drivers/gpio/sh_pfc.c
> > > drivers/gpio/tca642x.c
> >
> > I tried to remove the drivers but that leads to errors in
> > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13021
>
> I did a similar test, but on top of my DM_ETH branch so some platforms
> got removed already.  The fatal platform list is:
> SBx81LIFKW lschlv2 lsxhl dns325 km_kirkwood km_kirkwood_128m16
> km_kirkwood_pci kmcoge5un kmnusa kmsuse2 d2net_v2 net2big_v2
> inetspace_v2 netspace_lite_v2 netspace_max_v2 netspace_mini_v2
> netspace_v2 omap5_uevm
>
> and I've cc'd the maintainers.  Folks, are you able to pick up and
> convert the GPIO driver that your platform relies on to DM_GPIO soon, or
> should we just disable the GPIO driver?  Or drop the platform?  Thanks!
>
(sorry for the odd threading, failed reply-all+gmail so the content
below only went to Tom)

The current users of kw_gpio.c should be able to switch to
mvebu_gpio.c with some minor changes (the equivalent linux driver
supports the kirkwood Soc). I'll try and take a look and convert my
boards over. I could do a blind conversion of the other boards if
no-one with actual hardware pipes up.

I notice that mvgpio is on your list but I think the last user of
CONFIG_MARVELL_GPIO was removed in commit dee08b1999e2 ("arm: Remove
gplugd board"). If no-one else has sent one already I can whip up a
quick patch to remove the dead code.

Update: Patch sent
https://lore.kernel.org/u-boot/20220803234357.21457-1-judge.pack...@gmail.com/

Also as it turns out MVEBU_GPIO is default y and depends on DM_GPIO &&
(ARCH_MVEBU || ARCH_KIRKWOOD) so the Kirkwood boards that are using
DM_GPIO already have it. Disabling KIRKWOOD_GPIO and eventually
removing the driver should be all that is needed.

> --
> Tom


[PATCH 31/31] MAINTAINERS: update maintainer for MediaTek ARM platform

2022-08-03 Thread Weijie Gao
Add new filed for MediaTek ARM platform

Signed-off-by: Weijie Gao 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4d1930f76e..515047db05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -355,20 +355,25 @@ F:doc/device-tree-bindings/phy/phy-mtk-*
 F: doc/device-tree-bindings/usb/mediatek,*
 F: doc/README.mediatek
 F: drivers/clk/mediatek/
+F: drivers/i2c/mtk_i2c.c
 F: drivers/mmc/mtk-sd.c
 F: drivers/phy/phy-mtk-*
 F: drivers/pinctrl/mediatek/
 F: drivers/power/domain/mtk-power-domain.c
 F: drivers/ram/mediatek/
 F: drivers/spi/mtk_snfi_spi.c
+F: drivers/spi/mtk_spim.c
 F: drivers/timer/mtk_timer.c
 F: drivers/usb/host/xhci-mtk.c
 F: drivers/usb/mtu3/
 F: drivers/watchdog/mtk_wdt.c
 F: drivers/net/mtk_eth.c
+F: drivers/net/mtk_eth.h
 F: drivers/reset/reset-mediatek.c
 F: tools/mtk_image.c
 F: tools/mtk_image.h
+F: tools/mtk_nand_headers.c
+F: tools/mtk_nand_headers.h
 N: mediatek
 
 ARM METHODE SUPPORT
-- 
2.17.1



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

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 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 3701d1564a..ac39334994 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 */
@@ -365,20 +368,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 = {
+   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, 0x80, 0x00, 0x00, 0x00,
+   0x40, 0x00, 0x00, 0x00, 0x00, 0x04, 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, 0x71, 0x7f, 0x71, 0xAC,
+   0x42, 0xD0, 0x5B, 0xD2, 0x12, 0x81, 0x15, 0x0A,
+   0x0C, 

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

2022-08-03 Thread Weijie Gao
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, 0xCF, 0x8F,
-   0x37, 0xBD, 0x17, 0xB6, 0xC7, 0xFE, 0x00, 0x00
-   }
-};
-
-/* NAND header for Parallel NAND 1Gb with 2KB page + 64B spare */
-static const union nand_boot_header na

[PATCH 28/31] tools: mtk_image: split gfh header verification into a new function

2022-08-03 Thread Weijie Gao
The verification code of gfh header for NAND and non-NAND are identical.
It's better to define a individual function to reduce redundancy.

Signed-off-by: Weijie Gao 
---
 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



[PATCH 27/31] clk: mediatek: add clock driver support for MediaTek MT7981 SoC

2022-08-03 Thread Weijie Gao
This patch adds clock driver support for MediaTek MT7981 SoC

Signed-off-by: Weijie Gao 
---
 drivers/clk/mediatek/Makefile  |   1 +
 drivers/clk/mediatek/clk-mt7981.c  | 682 +
 include/dt-bindings/clock/mt7981-clk.h | 267 ++
 3 files changed, 950 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt7981.c
 create mode 100644 include/dt-bindings/clock/mt7981-clk.h

diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 1aa38215bf..1decf31a77 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -8,6 +8,7 @@ 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_MT7981) += clk-mt7981.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-mt7981.c
 b/drivers/clk/mediatek/clk-mt7981.c
new file mode 100644
index 00..53d09250e6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7981.c
@@ -0,0 +1,682 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT7981 SoC
+ *
+ * Copyright (C) 2022 MediaTek Inc.
+ * Author: Sam Shih 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+
+#define MT7981_CLK_PDN 0x250
+#define MT7981_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, 13),
+   FIXED_CLK(CK_APMIXED_NET2PLL, CLK_XTAL, 8),
+   FIXED_CLK(CK_APMIXED_MMPLL, CLK_XTAL, 72000),
+   FIXED_CLK(CK_APMIXED_SGMPLL, CLK_XTAL, 32500),
+   FIXED_CLK(CK_APMIXED_WEDMCUPLL, CLK_XTAL, 20800),
+   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_D3, "cb_m_d3", CK_APMIXED_MPLL, 1, 3),
+   PLL_FACTOR(CK_TOP_M_D3_D2, "m_d3_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_CB_MM_720M, "cb_mm_720m", CK_APMIXED_MMPLL, 1, 1),
+   PLL_FACTOR(CK_TOP_CB_MM_D2, "cb_mm_d2", CK_APMIXED_MMPLL, 1, 2),
+   PLL_FACTOR(CK_TOP_CB_MM_D3, "cb_mm_d3", CK_APMIXED_MMPLL, 1, 3),
+   PLL_FACTOR(CK_TOP_CB_MM_D3_D5, "cb_mm_d3_d5", CK_APMIXED_MMPLL, 1, 15),
+   PLL_FACTOR(CK_TOP_CB_MM_D4, "cb_mm_d4", CK_APMIXED_MMPLL, 1, 4),
+   PLL_FACTOR(CK_TOP_CB_MM_D6, "cb_mm_d6", CK_APMIXED_MMPLL, 1, 6),
+   PLL_FACTOR(CK_TOP_MM_D6_D2, "mm_d6_d2", CK_APMIXED_MMPLL, 1, 12),
+   PLL_FACTOR(CK_TOP_CB_MM_D8, "cb_mm_d8", CK_APMIXED_MMPLL, 1, 8),
+   PLL_FACTOR(CK_TOP_CB_APLL2_196M, "cb_apll2_196m", CK_APMIXED_APLL2, 1,
+  1),
+   PLL_FACTOR(CK_TOP_APLL2_D2, "apll2_d2", CK_APMIXED_APLL2, 1, 2),
+   PLL_FACTOR(CK_TOP_APLL2_D4, "apll2_d4", CK_APMIXED_APLL2, 1, 4),
+   PLL_FACTOR(CK_TOP_NET1_2500M, "net1_2500m", CK_APMIXED_NET1PLL, 1, 1),
+   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_CB_NET1_D8, "cb_net1_d8", CK_APMIXED_NET1PLL, 1, 8),
+   PLL_FACTOR(CK_TOP_NET1_D8_D2, "net1_d8_d2", CK_APMIXED_NET1PLL, 1, 16),
+   PLL_FACTOR(CK_TOP_NET1_D8_D4, "net1_d8_d4", CK_APMIXED_NET1PLL, 1, 32),
+   PLL_FACTOR(CK_TOP_CB_NET2_800M, "cb_net2_800m", CK_APMIXED_NET2PLL, 1,
+  1),
+   PLL_FACTOR(CK_TOP_CB_NET2_D2, "cb_net2_d2", CK_APMIXED_NET2PLL, 1, 2),
+   PLL_FACTOR(CK_TOP_CB_NET2_D4, "cb_net2_d4", CK_APMIXED_NET2PLL, 1, 4),
+   PLL_FACTOR(CK_TOP_NET2_D4

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

2022-08-03 Thread Weijie Gao
This patch adds clock driver support for MediaTek MT7986 SoC

Signed-off-by: Weijie Gao 
---
 drivers/clk/mediatek/Makefile  |   1 +
 drivers/clk/mediatek/clk-mt7986.c  | 671 +
 include/dt-bindings/clock/mt7986-clk.h | 249 +
 3 files changed, 921 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..11c489cd50
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7986.c
@@ -0,0 +1,671 @@
+// 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_D8_D2, "net1_d8_d2", CK_APMIXED_NET1PLL, 1, 16),
+   PLL_FACTOR(CK_TOP_NET1_D8_D4, "net1_d8_d4", CK_APMIXED_NET1PLL, 1, 32),
+   PLL_FACTOR(CK_TOP_CB_NET2_800M, "cb_net2_800m", CK_APMIXED_NET2PLL, 1,
+  1),
+   PLL_FACTOR(CK_TOP_CB_NET2_D4, "cb_net2_d4", CK_APMIXED_NET2PLL, 1, 4),
+   PLL_FACTOR(CK_TOP_NET2_D4_D2, "net2_d4_d2", CK_APMIXED_NET2PLL, 1, 8),
+   PLL_FACTOR(CK_TOP_NET2_D3_D2, "net2_d3_d2", CK_APMIXED_NET2PLL, 1, 2),
+   PLL_FACTOR(CK_TOP_CB_WEDMCU_760M, "cb_wedmcu_760m",
+  CK_APMIXED_WEDMCUPLL, 1, 1),
+   PLL_FACTOR(CK_TOP_WEDMCU_D5_D2, "wedmcu_d5_d2", CK_APMIXED_WEDMCUPLL, 1,
+  10),
+   PLL_FACTOR(CK_TOP_CB_SGM_325M, "cb_sgm_325m", CK_APMIXED_SGMPLL, 1, 1),
+   TOP_FACTOR(CK_TOP_CB_CKSQ_40M_D2, "cb_cksq_40m_d2", CK_TOP_CB_CKSQ_40M,
+  1, 2),
+   TOP_

[PATCH 25/31] clk: mediatek: add CLK_XTAL support for clock driver

2022-08-03 Thread Weijie Gao
This add CLK_XTAL macro and flag to mediatek clock driver common part,
to make thi SoC that has clock directlly connect to XTAL working.

Signed-off-by: Weijie Gao 
---
 drivers/clk/mediatek/clk-mtk.c | 3 +++
 drivers/clk/mediatek/clk-mtk.h | 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index be3846c85b..5a4650d137 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,8 @@ 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;
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 8536275671..211356697b 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -26,7 +26,8 @@
 #define CLK_PARENT_APMIXED BIT(4)
 #define CLK_PARENT_TOPCKGENBIT(5)
 #define CLK_PARENT_INFRASYSBIT(6)
-#define CLK_PARENT_MASKGENMASK(6, 4)
+#define CLK_PARENT_XTALBIT(7)
+#define CLK_PARENT_MASKGENMASK(7, 4)
 
 #define ETHSYS_HIFSYS_RST_CTRL_OFS 0x34
 
-- 
2.17.1



[PATCH 24/31] clk: mediatek: add infrasys clock mux support

2022-08-03 Thread Weijie Gao
This patch adds infrasys clock mux support for mediatek clock drivers.

Signed-off-by: Weijie Gao 
---
 drivers/clk/mediatek/clk-mtk.c | 72 ++
 drivers/clk/mediatek/clk-mtk.h |  4 +-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 908ed2b4ba..be3846c85b 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 = &priv->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);
@@ -332,6 +350,34 @@ 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 = &priv->tree->muxes[off];
+   u32 index;
+   u32 flag;
+
+   index = readl(priv->base + mux->mux_reg);
+   index &= mux->mux_mask << mux->mux_shift;
+   index = index >> mux->mux_shift;
+
+   if (mux->parent[index] == CLK_XTAL && priv->tree->flags & 
CLK_BYPASS_XTAL)
+   flag = 1;
+   if (mux->parent[index] > 0 || flag == 1) {
+   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);
@@ -346,6 +392,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);
@@ -494,6 +559,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 7955d469db..8536275671 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -25,7 +25,8 @@
 
 #define CLK_PARENT_APMIXED BIT(4)
 #define CLK_PARENT_TOPCKGENBIT(5)
-#define CLK_PARENT_MASKGENMASK(5, 4)
+#define CLK_PARENT_INFRASYSBIT(6)
+#define CLK_PARENT_MASKGENMASK(6, 4)
 
 #define ETHSYS_HIFSYS_RST_CTRL_OFS 0x34
 
@@ -217,6 +218,7 @@ struct mtk_cg_priv {
 
 extern const struct clk_ops mtk_clk_apmixedsys_ops;
 extern const struct clk_ops mtk_clk_topckgen_ops;
+extern const struct clk_ops mtk_clk_infrasys_ops;
 extern const struct clk_ops mtk_clk_gate_ops;
 
 int mtk_common_clk_init(struct udevice *dev,
-- 
2.17.1



[PATCH 23/31] clk: mediatek: add support to configure clock driver parent

2022-08-03 Thread Weijie Gao
This patch adds support for a clock node to configure its parent clock
where possible.

Signed-off-by: Weijie Gao 
---
 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 d99ea55df0..908ed2b4ba 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, &dev))
-   return -ENODEV;
-
-   parent.dev = dev;
-   } else {
+   if (pdev)
+   parent.dev = pdev;
+   else
parent.dev = clk->dev;
-   }
 
return clk_get_rate(&parent);
 }
@@ -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);
@@ -322,9 +316,18 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
 u32 off)
 
if (mux->parent[index] == CLK_XTAL && priv->tree->flags & 
CLK_BYPASS_XTAL)
flag = 1;
-   if (mux->parent[index] > 0 || flag == 1)
-   return mtk_clk_find_parent_rate(clk, mux->parent[index],
-   NULL);
+   if (mux->parent[index] > 0 || flag == 1) {
+   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;
 }
@@ -343,7 +346,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;
@@ -376,7 +379,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;
@@ -402,7 +405,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);
 
@@ -474,19 +477,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 = &priv->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;
-   }
+   return mtk_clk_find_parent_rate(clk, gate->parent, priv->parent);
 }
 
 const struct clk_ops mtk_clk_apmixedsys_ops = {
@@ -497,10 +488,10 @@ const struct clk_ops mtk_clk_apmixedsys_ops = {
 };
 
 const struct clk_ops mtk_clk_topckgen_ops = {
-   .enable = mtk_topckgen_enable,
-   .disable = mtk_topckgen_disable,
+   .enable = mtk_clk_mux_enable,
+   .disable = mtk_clk_mux_disable,
.get_rate = mtk_topckgen_get_rate,
-   .set_parent = mtk_topckgen_set_parent,
+   .set_parent = mtk_common_clk_set_parent,
 };
 
 const struct clk_ops mtk_clk_gate_ops = {
@@ -513,11 +504,22 @@ int mtk_common_clk_init(struct udevice *dev,
const struct mtk_clk_tree *tree)
 {
  

[PATCH 21/31] pinctrl: mediatek: add pinctrl driver for MT7986 SoC

2022-08-03 Thread Weijie Gao
This patch adds pinctrl and gpio support for MT7986 SoC

Signed-off-by: Weijie Gao 
---
 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", "iocfg_rt", "iocfg_rb", "iocfg_lt", "iocfg_lb", "iocfg_tr",
+   "iocfg_tl",
+};
+
+static const struct mtk_pin_field_calc mt7986_pin_mode_range[] = {
+   PIN_FIELD_GPIO(0, 100, 0x300, 0x10, 0, 4),
+};
+
+static const struct mtk_pin_field_calc mt7986_pin_dir_range[] = {
+   PIN_FIELD_GPIO(0, 100, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7986_pin_di_range[] = {
+   PIN_FIELD_GPIO(0, 100, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7986_pin_do_range[] = {
+   PIN_FIELD_GPIO(0, 100, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7986_pin_ies_range[] = {
+   PIN_FIELD_BASE(0, 0, IOCFG_RB_BASE, 0x40, 0x10, 17, 1),
+   PIN_FIELD_BASE(1, 2, IOCFG_LT_BASE, 0x20, 0x10, 10, 1),
+   PIN_FIELD_BASE(3, 4, IOCFG_LB_BASE, 0x20, 0x10, 0, 1),
+   PIN_FIEL

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

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 drivers/clk/mediatek/clk-mtk.c | 5 -
 drivers/clk/mediatek/clk-mtk.h | 3 +++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index d43b8a0648..d99ea55df0 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -314,12 +314,15 @@ static ulong mtk_topckgen_get_mux_rate(struct clk
 *clk, u32 off)
struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
const struct mtk_composite *mux = &priv->tree->muxes[off];
u32 index;
+   u32 flag = 0;
 
index = readl(priv->base + mux->mux_reg);
index &= mux->mux_mask << mux->mux_shift;
index = index >> mux->mux_shift;
 
-   if (mux->parent[index])
+   if (mux->parent[index] == CLK_XTAL && priv->tree->flags & 
CLK_BYPASS_XTAL)
+   flag = 1;
+   if (mux->parent[index] > 0 || flag == 1)
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..0ab6912bf0 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -11,6 +11,8 @@
 #define CLK_XTAL   0
 #define MHZ(1000 * 1000)
 
+#define CLK_BYPASS_XTALBIT(0)
+
 #define HAVE_RST_BAR   BIT(0)
 #define CLK_DOMAIN_SCPSYS  BIT(0)
 #define CLK_MUX_SETCLR_UPD BIT(1)
@@ -197,6 +199,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



[PATCH 20/31] pinctrl: mediatek: add pinctrl driver for MT7981 SoC

2022-08-03 Thread Weijie Gao
This patch adds pinctrl and gpio support for MT7981 SoC

Signed-off-by: Weijie Gao 
---
 drivers/pinctrl/mediatek/Kconfig  |4 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1049 +
 3 files changed, 1054 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7981.c

diff --git a/drivers/pinctrl/mediatek/Kconfig
 b/drivers/pinctrl/mediatek/Kconfig
index 58df508d7e..aceec9277d 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -16,6 +16,10 @@ config PINCTRL_MT7629
bool "MT7629 SoC pinctrl driver"
select PINCTRL_MTK
 
+config PINCTRL_MT7981
+   bool "MT7981 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 d7e8cf1727..1879d7ae2a 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
 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_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-mt7981.c
 b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
new file mode 100644
index 00..d8875241cb
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7981.c
@@ -0,0 +1,1049 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The MT7981 driver based on Linux generic pinctrl binding.
+ *
+ * Copyright (C) 2022 MediaTek Inc.
+ * Author: Sam Shih 
+ */
+
+#include 
+#include "pinctrl-mtk-common.h"
+
+#define MT7981_TYPE0_PIN(_number, _name)   \
+   MTK_TYPED_PIN(_number, _name, DRV_GRP4, IO_TYPE_GRP0)
+
+#define MT7981_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
+ *
+ * MT7981 have multiple bases to program pin configuration listed as the
 below:
+ * iocfg_rt:0x11c0, iocfg_rm:0x11c1, iocfg_rb:0x11d2,
+ * iocfg_lb:0x11e0, iocfg_bl:0x11e2, iocfg_tm: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 TM|
+ *  6 |  +-+   |
+ *  5 |  | | RT|
+ *  4 |  | | RM|
+ *  3 |   LB | | RB|
+ *  2 |  +-+   |
+ *  1 |BL  |
+ *++
+ *
+ */
+
+enum {
+   GPIO_BASE,
+   IOCFG_RT_BASE,
+   IOCFG_RM_BASE,
+   IOCFG_RB_BASE,
+   IOCFG_LB_BASE,
+   IOCFG_BL_BASE,
+   IOCFG_TM_BASE,
+   IOCFG_TL_BASE,
+};
+
+static const struct mtk_pin_field_calc mt7981_pin_mode_range[] = {
+   PIN_FIELD_GPIO(0, 56, 0x300, 0x10, 0, 4),
+};
+
+static const struct mtk_pin_field_calc mt7981_pin_dir_range[] = {
+   PIN_FIELD_GPIO(0, 56, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7981_pin_di_range[] = {
+   PIN_FIELD_GPIO(0, 56, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7981_pin_do_range[] = {
+   PIN_FIELD_GPIO(0, 56, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7981_pin_ies_range[] = {
+   PIN_FIELD_BASE(0, 0, 1, 0x10, 0x10, 1, 1),
+   PIN_FIELD_BASE(1, 1, 1, 0x10, 0x10, 0, 1),
+   PIN_FIELD_BASE(2, 2, 5, 0x20, 0x10, 6, 1),
+   PIN_FIELD_BASE(3, 3, 4, 0x20, 0x10, 6, 1),
+   PIN_FIELD_BASE(4, 4, 4, 0x20, 0x10, 2, 1),
+   PIN_FIELD_BASE(5, 5, 4, 0x20, 0x10, 1, 1),
+   PIN_FIELD_BAS

[PATCH 19/31] dt-bindings: pinctrl: mediatek: add a header for common pinconf parameters

2022-08-03 Thread Weijie Gao
This patch adds a pinctrl header for common pinconf parameters such as
pull-up/pull-down resistors and drive strengths.

Signed-off-by: Weijie Gao 
---
 include/dt-bindings/pinctrl/mt65xx.h | 41 
 1 file changed, 41 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/mt65xx.h

diff --git a/include/dt-bindings/pinctrl/mt65xx.h
 b/include/dt-bindings/pinctrl/mt65xx.h
new file mode 100644
index 00..fbea8d35bc
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt65xx.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Hongzhou.Yang 
+ */
+
+#ifndef _DT_BINDINGS_PINCTRL_MT65XX_H
+#define _DT_BINDINGS_PINCTRL_MT65XX_H
+
+#define MTK_PIN_NO(x)  ((x) << 8)
+#define MTK_GET_PIN_NO(x)  ((x) >> 8)
+#define MTK_GET_PIN_FUNC(x)((x) & 0xf)
+
+#define MTK_PUPD_SET_R1R0_00   100
+#define MTK_PUPD_SET_R1R0_01   101
+#define MTK_PUPD_SET_R1R0_10   102
+#define MTK_PUPD_SET_R1R0_11   103
+
+#define MTK_PULL_SET_RSEL_000  200
+#define MTK_PULL_SET_RSEL_001  201
+#define MTK_PULL_SET_RSEL_010  202
+#define MTK_PULL_SET_RSEL_011  203
+#define MTK_PULL_SET_RSEL_100  204
+#define MTK_PULL_SET_RSEL_101  205
+#define MTK_PULL_SET_RSEL_110  206
+#define MTK_PULL_SET_RSEL_111  207
+
+#define MTK_DRIVE_2mA  2
+#define MTK_DRIVE_4mA  4
+#define MTK_DRIVE_6mA  6
+#define MTK_DRIVE_8mA  8
+#define MTK_DRIVE_10mA 10
+#define MTK_DRIVE_12mA 12
+#define MTK_DRIVE_14mA 14
+#define MTK_DRIVE_16mA 16
+#define MTK_DRIVE_20mA 20
+#define MTK_DRIVE_24mA 24
+#define MTK_DRIVE_28mA 28
+#define MTK_DRIVE_32mA 32
+
+#endif /* _DT_BINDINGS_PINCTRL_MT65XX_H */
-- 
2.17.1



[PATCH 17/31] i2c: add support for MediaTek I2C interface

2022-08-03 Thread Weijie Gao
This patch adds support for MediaTek I2C interface

Signed-off-by: Weijie Gao 
---
 drivers/i2c/Kconfig   |   9 +
 drivers/i2c/Makefile  |   1 +
 drivers/i2c/mtk_i2c.c | 822 ++
 3 files changed, 832 insertions(+)
 create mode 100644 drivers/i2c/mtk_i2c.c

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index be4724bf8e..08b6c7bdcc 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -261,6 +261,15 @@ config SYS_I2C_MESON
  internal buffer holding up to 8 bytes for transfers and supports
  both 7-bit and 10-bit addresses.
 
+config SYS_I2C_MTK
+   bool "MediaTek I2C driver"
+   help
+ This selects the MediaTek Integrated Inter Circuit bus driver.
+ The I2C bus adapter is the base for some other I2C client,
+ eg: touch, sensors.
+ If you want to use MediaTek I2C interface, say Y here.
+ If unsure, say N.
+
 config SYS_I2C_MICROCHIP
bool "Microchip I2C driver"
help
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 7e046f809a..920aafb91c 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_SYS_I2C_MICROCHIP) += i2c-microchip.o
 obj-$(CONFIG_SYS_I2C_MV) += mv_i2c.o
 obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
 obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
+obj-$(CONFIG_SYS_I2C_MTK) += mtk_i2c.o
 obj-$(CONFIG_SYS_I2C_NEXELL) += nx_i2c.o
 obj-$(CONFIG_SYS_I2C_NPCM) += npcm_i2c.o
 obj-$(CONFIG_SYS_I2C_OCORES) += ocores_i2c.o
diff --git a/drivers/i2c/mtk_i2c.c b/drivers/i2c/mtk_i2c.c
new file mode 100644
index 00..1d4a93f8c9
--- /dev/null
+++ b/drivers/i2c/mtk_i2c.c
@@ -0,0 +1,822 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 MediaTek Inc. All Rights Reserved.
+ *
+ * Author: Mingming Lee 
+ *
+ * MediaTek I2C Interface driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I2C_RS_TRANSFERBIT(4)
+#define I2C_HS_NACKERR BIT(2)
+#define I2C_ACKERR BIT(1)
+#define I2C_TRANSAC_COMP   BIT(0)
+#define I2C_TRANSAC_START  BIT(0)
+#define I2C_RS_MUL_CNFGBIT(15)
+#define I2C_RS_MUL_TRIGBIT(14)
+#define I2C_DCM_DISABLE0x
+#define I2C_IO_CONFIG_OPEN_DRAIN   0x0003
+#define I2C_IO_CONFIG_PUSH_PULL0x
+#define I2C_SOFT_RST   0x0001
+#define I2C_FIFO_ADDR_CLR  0x0001
+#define I2C_DELAY_LEN  0x0002
+#define I2C_ST_START_CON   0x8001
+#define I2C_FS_START_CON   0x1800
+#define I2C_TIME_CLR_VALUE 0x
+#define I2C_TIME_DEFAULT_VALUE 0x0003
+#define I2C_WRRD_TRANAC_VALUE  0x0002
+#define I2C_RD_TRANAC_VALUE0x0001
+
+#define I2C_DMA_CON_TX 0x
+#define I2C_DMA_CON_RX 0x0001
+#define I2C_DMA_START_EN   0x0001
+#define I2C_DMA_INT_FLAG_NONE  0x
+#define I2C_DMA_CLR_FLAG   0x
+#define I2C_DMA_TX_RX  0x
+#define I2C_DMA_HARD_RST   0x0002
+
+#define MAX_ST_MODE_SPEED  10
+#define MAX_FS_MODE_SPEED  40
+#define MAX_HS_MODE_SPEED  340
+#define MAX_SAMPLE_CNT_DIV 8
+#define MAX_STEP_CNT_DIV   64
+#define MAX_HS_STEP_CNT_DIV8
+#define I2C_DEFAULT_CLK_DIV4
+
+#define MAX_I2C_ADDR   0x7f
+#define MAX_I2C_LEN0xff
+#define TRANS_ADDR_ONLYBIT(8)
+#define TRANSFER_TIMEOUT   5  /* us */
+#define I2C_FIFO_STAT1_MASK0x001f
+#define TIMING_SAMPLE_OFFSET   8
+#define HS_SAMPLE_OFFSET   12
+#define HS_STEP_OFFSET 8
+
+#define I2C_CONTROL_WRAPPERBIT(0)
+#define I2C_CONTROL_RS BIT(1)
+#define I2C_CONTROL_DMA_EN BIT(2)
+#define I2C_CONTROL_CLK_EXT_EN BIT(3)
+#define I2C_CONTROL_DIR_CHANGE BIT(4)
+#define I2C_CONTROL_ACKERR_DET_EN  BIT(5)
+#define I2C_CONTROL_TRANSFER_LEN_CHANGE BIT(6)
+#define I2C_CONTROL_DMAACK BIT(8)
+#define I2C_CONTROL_ASYNC  BIT(9)
+
+enum I2C_REGS_OFFSET {
+   REG_PORT,
+   REG_SLAVE_ADDR,
+   REG_INTR_MASK,
+   REG_INTR_STAT,
+   REG_CONTROL,
+   REG_TRANSFER_LEN,
+   REG_TRANSAC_LEN,
+   REG_DELAY_LEN,
+   REG_TIMING,
+   REG_START,
+   REG_EXT_CONF,
+   REG_FIFO_STAT1,
+   REG_LTIMING,
+   REG_FIFO_STAT,
+   REG_FIFO_THRESH,
+   REG_FIFO_ADDR_CLR,
+   REG_IO_CONFIG,
+   REG_RSV_DEBUG,
+   REG_HS,
+   REG_SOFTRESET,
+   REG_DCM_EN,
+   REG_PATH_DIR,
+   REG_DEBUGSTAT,
+   REG_DEBUGCTRL,
+   REG_TRANSFER_LEN_AUX,
+   REG_CLOCK_DIV,
+   REG_SCL_HL_RATIO,
+   REG_S

[PATCH 18/31] arm: dts: mt7622: add i2c support

2022-08-03 Thread Weijie Gao
Add both hardware and software i2c support for mt7622.

Signed-off-by: Weijie Gao 
---
 arch/arm/dts/mt7622-rfb.dts | 18 ++
 arch/arm/dts/mt7622.dtsi| 24 
 2 files changed, 42 insertions(+)

diff --git a/arch/arm/dts/mt7622-rfb.dts b/arch/arm/dts/mt7622-rfb.dts
index 30a9137407..b44f19f05a 100644
--- a/arch/arm/dts/mt7622-rfb.dts
+++ b/arch/arm/dts/mt7622-rfb.dts
@@ -159,6 +159,14 @@
};
 
};
+
+   i2c1_pins_default: i2c1-default {
+   mux {
+   function = "i2c";
+   groups = "i2c1_0";
+   };
+   };
+
 };
 
 &snfi {
@@ -242,3 +250,13 @@
 &u3phy {
status = "okay";
 };
+
+&soft_i2c {
+   status = "disabled";
+};
+
+&i2c1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins_default>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/mt7622.dtsi b/arch/arm/dts/mt7622.dtsi
index fb6c1b7154..2d89fa08b4 100644
--- a/arch/arm/dts/mt7622.dtsi
+++ b/arch/arm/dts/mt7622.dtsi
@@ -424,4 +424,28 @@
status = "disabled";
};
 
+   soft_i2c: soft_i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "i2c-gpio";
+   gpios = <&gpio 56 GPIO_ACTIVE_HIGH>, /* SDA */
+   <&gpio 55 GPIO_ACTIVE_HIGH>; /* CLK */
+   i2c-gpio,delay-us = <5>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@11008000 {
+   compatible = "mediatek,mt7622-i2c";
+   reg = <0x11008000 0x90>,
+ <0x11000180 0x80>;
+   interrupts = ;
+   clock-div = <16>;
+   clocks = <&pericfg CLK_PERI_I2C1_PD>,
+<&pericfg CLK_PERI_AP_DMA_PD>;
+   clock-names = "main", "dma";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
 };
-- 
2.17.1



[PATCH 16/31] spi: add support for MediaTek spi-mem controller

2022-08-03 Thread Weijie Gao
This patch adds support for spi-mem controller found on newer MediaTek SoCs
This controller supports Single/Dual/Quad SPI mode.

Signed-off-by: SkyLake.Huang 
---
 drivers/spi/Kconfig|   8 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/mtk_spim.c | 705 +
 3 files changed, 714 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..b0f63c3c3f
--- /dev/null
+++ b/drivers/spi/mtk_spim.c
@@ -0,0 +1,705 @@
+// 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_REG0x0010
+#define SPI_RX_DATA_REG0x0014
+#define SPI_CMD_REG0x0018
+#define SPI_IRQ_REG0x001c
+#define SPI_STATUS_REG 0x0020
+#define SPI_PAD_SEL_REG0x0024
+#define SPI_CFG2_REG   0x0028
+#define SPI_TX_SRC_REG_64  0x002c
+#define SPI_RX_DST_REG_64  0x0030
+#define SPI_CFG3_IPM_REG   0x0040
+
+#define SPI_CFG0_SCK_HIGH_OFFSET   0
+#define SPI_CFG0_SCK_LOW_OFFSET8
+#define SPI_CFG0_CS_HOLD_OFFSET16
+#define SPI_CFG0_CS_SETUP_OFFSET   24
+#define SPI_ADJUST_CFG0_CS_HOLD_OFFSET 0
+#define SPI_ADJUST_CFG0_CS_SETUP_OFFSET16
+
+#define SPI_CFG1_CS_IDLE_OFFSET0
+#define SPI_CFG1_PACKET_LOOP_OFFSET8
+#define SPI_CFG1_PACKET_LENGTH_OFFSET  16
+#define SPI_CFG1_GET_TICKDLY_OFFSET29
+
+#define SPI_CFG1_GET_TICKDLY_MASK  GENMASK(31, 29)
+#define SPI_CFG1_CS_IDLE_MASK  0xff
+#define SPI_CFG1_PACKET_LOOP_MASK  0xff00
+#define SPI_CFG1_PACKET_LENGTH_MASK0x3ff
+#define SPI_CFG1_IPM_PACKET_LENGTH_MASKGENMASK(31, 16)
+#define SPI_CFG2_SCK_HIGH_OFFSET   0
+#define SPI_CFG2_SCK_LOW_OFFSET16
+#define SPI_CFG2_SCK_HIGH_MASK GENMASK(15, 0)
+#define SPI_CFG2_SCK_LOW_MASK  GENMASK(31, 16)
+
+#define SPI_CMD_ACTBIT(0)
+#define SPI_CMD_RESUME BIT(1)
+#define SPI_CMD_RSTBIT(2)
+#define SPI_CMD_PAUSE_EN   BIT(4)
+#define SPI_CMD_DEASSERT   BIT(5)
+#define SPI_CMD_SAMPLE_SEL BIT(6)
+#define SPI_CMD_CS_POL BIT(7)
+#define SPI_CMD_CPHA   BIT(8)
+#define SPI_CMD_CPOL   BIT(9)
+#define SPI_CMD_RX_DMA BIT(10)
+#define SPI_CMD_TX_DMA BIT(11)
+#define SPI_CMD_TXMSBF BIT(12)
+#define SPI_CMD_RXMSBF BIT(13)
+#define SPI_CMD_RX_ENDIAN  BIT(14)
+#define SPI_CMD_TX_ENDIAN  BIT(15)
+#define SPI_CMD_FINISH_IE  BIT(16)
+#define SPI_CMD_PAUSE_IE   BIT(17)
+#define SPI_CMD_IPM_NONIDLE_MODE   BIT(19)
+#define SPI_CMD

[PATCH 15/31] watchdog: mediatek: add support for MediaTek MT7986 SoC

2022-08-03 Thread Weijie Gao
This patch adds watchdog support for MediaTek MT7986 SoC

Signed-off-by: Weijie Gao 
---
 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



[PATCH 14/31] timer: mtk: add support for MediaTek MT7981/MT7986 SoCs

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 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_CTRL  0x40
-#define MTK_GPT4_CLK   0x44
-#define MTK_GPT4_CNT   0x48
+#define MTK_GPT4_OFFSET_V1 0x40
+#define MTK_GPT4_OFFSET_V2 0x80
 
-#define GPT4_ENABLEBIT(0)
-#define GPT4_CLEAR BIT(1)
-#define GPT4_FREERUN   GENMASK(5, 4)
-#define GPT4_CLK_SYS   0x0
-#define GPT4_CLK_DIV1  0x0
+#define MTK_GPT_CON0x0
+#define MTK_GPT_V1_CLK 0x4
+#define MTK_GPT_CNT0x8
+
+#define GPT_ENABLE BIT(0)
+#define GPT_CLEAR  BIT(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, &clk);
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



[PATCH 13/31] pwm: mtk: add support for MediaTek MT7981 SoC

2022-08-03 Thread Weijie Gao
This patch adds PWM support for MediaTek MT7981 SoC.
MT7981 uses a different register offset so we have to add a version field
to indicate the IP core version.

Signed-off-by: Weijie Gao 
---
 drivers/pwm/pwm-mtk.c | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-mtk.c b/drivers/pwm/pwm-mtk.c
index 3100b5caaf..605142eab0 100644
--- a/drivers/pwm/pwm-mtk.c
+++ b/drivers/pwm/pwm-mtk.c
@@ -29,13 +29,23 @@
 
 #define NSEC_PER_SEC 10L
 
-static const unsigned int mtk_pwm_reg_offset[] = {
+enum mtk_pwm_reg_ver {
+   PWM_REG_V1,
+   PWM_REG_V2,
+};
+
+static const unsigned int mtk_pwm_reg_offset_v1[] = {
0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
 };
 
+static const unsigned int mtk_pwm_reg_offset_v2[] = {
+   0x0080, 0x00c0, 0x0100, 0x0140, 0x0180, 0x01c0, 0x0200, 0x0240
+};
+
 struct mtk_pwm_soc {
unsigned int num_pwms;
bool pwm45_fixup;
+   enum mtk_pwm_reg_ver reg_ver;
 };
 
 struct mtk_pwm_priv {
@@ -49,7 +59,16 @@ struct mtk_pwm_priv {
 static void mtk_pwm_w32(struct udevice *dev, uint channel, uint reg, uint
 val)
 {
struct mtk_pwm_priv *priv = dev_get_priv(dev);
-   u32 offset = mtk_pwm_reg_offset[channel];
+   u32 offset;
+
+   switch (priv->soc->reg_ver) {
+   case PWM_REG_V2:
+   offset = mtk_pwm_reg_offset_v2[channel];
+   break;
+
+   default:
+   offset = mtk_pwm_reg_offset_v1[channel];
+   }
 
writel(val, priv->base + offset + reg);
 }
@@ -159,27 +178,38 @@ static const struct pwm_ops mtk_pwm_ops = {
 static const struct mtk_pwm_soc mt7622_data = {
.num_pwms = 6,
.pwm45_fixup = false,
+   .reg_ver = PWM_REG_V1,
 };
 
 static const struct mtk_pwm_soc mt7623_data = {
.num_pwms = 5,
.pwm45_fixup = true,
+   .reg_ver = PWM_REG_V1,
 };
 
 static const struct mtk_pwm_soc mt7629_data = {
.num_pwms = 1,
.pwm45_fixup = false,
+   .reg_ver = PWM_REG_V1,
+};
+
+static const struct mtk_pwm_soc mt7981_data = {
+   .num_pwms = 2,
+   .pwm45_fixup = false,
+   .reg_ver = PWM_REG_V2,
 };
 
 static const struct mtk_pwm_soc mt7986_data = {
.num_pwms = 2,
.pwm45_fixup = false,
+   .reg_ver = PWM_REG_V1,
 };
 
 static const struct udevice_id mtk_pwm_ids[] = {
{ .compatible = "mediatek,mt7622-pwm", .data = (ulong)&mt7622_data },
{ .compatible = "mediatek,mt7623-pwm", .data = (ulong)&mt7623_data },
{ .compatible = "mediatek,mt7629-pwm", .data = (ulong)&mt7629_data },
+   { .compatible = "mediatek,mt7981-pwm", .data = (ulong)&mt7981_data },
{ .compatible = "mediatek,mt7986-pwm", .data = (ulong)&mt7986_data },
{ }
 };
-- 
2.17.1



[PATCH 12/31] pwm: mtk: add support for MediaTek MT7986 SoC

2022-08-03 Thread Weijie Gao
This patch adds PWM support for MediaTek MT7986 SoC.

Signed-off-by: Weijie Gao 
---
 drivers/pwm/pwm-mtk.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pwm/pwm-mtk.c b/drivers/pwm/pwm-mtk.c
index aee1d825a0..3100b5caaf 100644
--- a/drivers/pwm/pwm-mtk.c
+++ b/drivers/pwm/pwm-mtk.c
@@ -171,10 +171,16 @@ static const struct mtk_pwm_soc mt7629_data = {
.pwm45_fixup = false,
 };
 
+static const struct mtk_pwm_soc mt7986_data = {
+   .num_pwms = 2,
+   .pwm45_fixup = false,
+};
+
 static const struct udevice_id mtk_pwm_ids[] = {
{ .compatible = "mediatek,mt7622-pwm", .data = (ulong)&mt7622_data },
{ .compatible = "mediatek,mt7623-pwm", .data = (ulong)&mt7623_data },
{ .compatible = "mediatek,mt7629-pwm", .data = (ulong)&mt7629_data },
+   { .compatible = "mediatek,mt7986-pwm", .data = (ulong)&mt7986_data },
{ }
 };
 
-- 
2.17.1



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

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 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 = <&topckgen CLK_TOP_AXI_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_SYSPLL1_D2>;
+   mediatek,force-highspeed;
};
 
mmc0: mmc@1123 {
-- 
2.17.1



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

2022-08-03 Thread Weijie Gao
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().

Signed-off-by: Weijie Gao 
---
 drivers/serial/serial_mtk.c | 72 -
 1 file changed, 39 insertions(+), 33 deletions(-)

diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
index a84f39b3fa..99cf62b8d9 100644
--- a/drivers/serial/serial_mtk.c
+++ b/drivers/serial/serial_mtk.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,25 +73,27 @@ struct mtk_serial_regs {
 
 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,
+  u32 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, &priv->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 +107,7 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv
 *priv, int baud)
 
if (baud <= 115200) {
writel(0, &priv->regs->highspeed);
-   quot = DIV_ROUND_CLOSEST(priv->clock, 16 * baud);
+   quot = DIV_ROUND_CLOSEST(clk_rate, 16 * baud);
} else if (baud <= 576000) {
writel(2, &priv->regs->highspeed);
 
@@ -112,13 +115,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, &priv->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 +170,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(&priv->clk);
+   if (IS_ERR_VALUE(clk_rate) || clk_rate == 0)
+   clk_rate = priv->fixed_clk_rate;
 
-   _mtk_serial_setbrg(priv, baudrate);
+   _mtk_serial_setbrg(priv, baudrate, clk_rate);
 
return 0;
 }
@@ -211,7 +219,6 @@ static int mtk_serial_of_to_plat(struct udevice *dev)
 {
struct mtk_serial_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
-   struct clk clk;
int err;
 
addr = dev_read_addr(dev);
@@ -220,22 +227,19 @@ static int mtk_serial_of_to_plat(struct udevice *dev)
 
priv->regs = map_physmem(addr, 0, MAP_NOCACHE);
 
-   err = clk_get_by_index(dev, 0, &clk);
-   if (!err) {
-   err = clk_get_rate(&clk);
-   if (!IS_ERR_VALUE(err))
-   priv->clock = err;
-   } else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS) {
-   debug("mtk_serial: failed to get clock\n");
-   return err;
-   }
-
-   if (!priv->clock)
-   priv->clock = dev_read_u32_default(dev, "clock-frequency", 0);
-
-   if (!priv->clock) {
-   debug("mtk_serial: clock not defined\n");
-   return -EINVAL;
+   err = clk_get_by_index(dev, 0, &priv->clk);
+   if (err) {
+   err = dev_read_u32(dev, "clock-frequency", 
&priv->fixed_clk_rate);
+   if (err) {
+   dev_err(dev, "baud clock not defined\n");
+  

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

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 drivers/net/mtk_eth.c | 51 ++---
 drivers/net/mtk_eth.h | 53 ---
 2 files changed, 83 insertions(+), 21 deletions(-)

diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index bfa049cf79..47a4e698c0 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -74,6 +74,7 @@ enum mtk_switch {
 struct mtk_soc_data {
u32 caps;
u32 ana_rgc3;
+   u32 pdma_base;
u32 txd_size;
u32 rxd_size;
 };
@@ -124,13 +125,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,
@@ -1127,8 +1128,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);
@@ -1149,7 +1150,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;
}
@@ -1158,7 +1163,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;
}
@@ -1187,6 +1196,9 @@ static int mtk_eth_start(struct udevice *dev)
reset_deassert(&priv->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);
 
@@ -1221,7 +1233,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);
 }
 
@@ -1246,7 +1258,7 @@ static int mtk_eth_send(struct udevice *dev, void
 *packet, int length)
 {
struct mtk_eth_priv *priv = dev_get_priv(dev);
u32 idx = priv->tx_cpu_owner_idx0;
-   struct mtk_tx_dma *txd;
+   struct mtk_tx_dma_v2 *txd;
void *pkt_base;
 
txd = priv->tx_ring_noc + idx * priv->soc->txd_size;
@@ -1261,7 +1273,10 @@ static int mtk_eth_send(struct udevice *dev, void
 *packet, int length)
flush_dcache_range((ulong)pkt_base, (ulong)pkt_base +
   roundup(length, ARCH_DMA_MINALIGN));
 
-   txd->txd2 = PDMA_TXD2_LS0 | PDMA_TXD2_SDL0_SET(length);
+   if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
+   txd->txd2 = PDMA_TXD2_LS0 | PDMA_V2_TXD2_SDL0_SET(length);
+   else
+   txd->txd2 = PDMA_TXD2_LS0 | PDMA_V1_TXD2_SDL0_SET(length);
 
priv->tx_cpu_owner_idx0 = (priv->tx_cpu_owner_idx0 + 1) % NUM_TX_DESC;
mtk_pdma_write(priv, TX_CTX_IDX_REG(0), priv->tx_cpu_owner_idx0);
@@ -1273,7 +1288,7 @@ static int mtk_eth_recv(struct udevice *dev, int
 flags, uchar **packetp)
 {
struct mtk_eth_priv *priv = dev_get_priv(dev);
u32 idx = priv->rx_dma_owner_idx0;
-   struct mtk_rx_dma *rxd;
+   struct mtk_rx_dma_v2 *rxd;
uchar *pkt_base;
u32 length;
 
@@ -1284,7 +1299,10 @@ static int mtk_eth_recv(struct udevice *dev, int
 flags, uchar **packetp)
  

[PATCH 09/31] net: mediatek: add support for MediaTek MT7981/MT7986

2022-08-03 Thread Weijie Gao
This patch adds support for MediaTek MT7981 and MT7986. Both chips uses
PDMA v2.

Signed-off-by: Weijie Gao 
---
 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 47a4e698c0..7bff0b5b04 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -106,6 +106,7 @@ struct mtk_eth_priv {
int force_mode;
int speed;
int duplex;
+   bool pn_swap;
 
struct phy_device *phydev;
int phy_interface;
@@ -1048,6 +1049,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);
@@ -1461,6 +1468,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 */
@@ -1511,6 +1520,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,
@@ -1540,6 +1565,8 @@ static const struct mtk_soc_data mt7621_data = {
 };
 
 static const struct udevice_id mtk_eth_ids[] = {
+   { .compatible = "mediatek,mt7986-eth", .data = (ulong)&mt7986_data },
+   { .compatible = "mediatek,mt7981-eth", .data = (ulong)&mt7981_data },
{ .compatible = "mediatek,mt7629-eth", .data = (ulong)&mt7629_data },
{ .compatible = "mediatek,mt7623-eth", .data = (ulong)&mt7623_data },
{ .compatible = "mediatek,mt7622-eth", .data = (ulong)&mt7622_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_CTRL  0xec
+#define SGMII_PN_SWAP_TX_RX0x03
+
 #define SGMSYS_GEN2_SPEED  0x2028
 #define SGMSYS_GEN2_SPEED_V2   0x128
 #define SGMSYS_SPEED_2500  BIT(2)
-- 
2.17.1



[PATCH 07/31] net: mediatek: stop using bitfileds for DMA descriptors

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 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 92d2ea4f2a..bfa049cf79 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,
@@ -145,13 +74,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;
@@ -1196,14 +1127,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));
@@ -1212,17 +1145,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);
pkt_base += PKTSIZE_ALIGN;
}
 
for (i = 0; i < NUM_RX_DESC; i++) {
-   priv->rx_ring_noc[i].rxd_info2.PLEN0 = PKTSIZE_ALIGN;
-   priv->rx_ring_noc[i].rxd_info1.PDP0 = virt_to_phys(pkt_base);
+   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);
+
pkt_base += PKTSIZE_ALIGN;
}
 
@@ -1309,20 +1246,22 @@ static int mtk_eth_send(struct udevice *dev, void
 *packet, int length)
 {
struct mtk_eth_priv *priv = dev_get_priv(dev);
u32 idx = priv->tx_cpu_owner_idx0;
+   struct mtk_tx_dma *txd;
void *pkt_base;
 
-   if (!priv->tx_ring_noc[idx].txd_info2.DDONE) {
+   txd = priv->tx_ring_noc + idx * priv->soc->txd_size;
+
+   if (!(txd->txd2 & PDMA_TXD2_DDONE)) {

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

2022-08-03 Thread Weijie Gao
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.

Signed-off-by: Weijie Gao 
---
 drivers/net/mtk_eth.c | 50 +--
 drivers/net/mtk_eth.h | 25 +-
 2 files changed, 58 insertions(+), 17 deletions(-)

diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
index 4fe7ee0d36..92d2ea4f2a 100644
--- a/drivers/net/mtk_eth.c
+++ b/drivers/net/mtk_eth.c
@@ -142,11 +142,9 @@ enum mtk_switch {
SW_MT7531
 };
 
-enum mtk_soc {
-   SOC_MT7623,
-   SOC_MT7629,
-   SOC_MT7622,
-   SOC_MT7621
+struct mtk_soc_data {
+   u32 caps;
+   u32 ana_rgc3;
 };
 
 struct mtk_eth_priv {
@@ -171,7 +169,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 +677,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 +1106,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 +1179,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 +1429,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 +1546,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", .data = SOC_MT7621 },
+   { .compatible = "mediatek,mt7629-eth", .data = (ulong)&mt7629_data },
+   { .compatible = "mediatek,mt7623-eth", .data = (ulong)&mt7623_data },
+   { .compatible = "mediatek,mt7622-eth", .data = (ulong)&mt7622_data },
+   { .compatible = "mediatek,mt7621-eth", .data = (ulong)&mt7621_data },
{}
 };
 
diff --git a/drivers/net/mtk_eth.h b/drivers/net/mtk_eth.h
index 057ecfaabf..15c2030617 100644
--- a/drivers/net/mtk_eth.h
+++ b/drivers/net/mtk_eth.h
@@ -9,8 +9,31 @@
 #ifndef _MTK_ETH_H_
 #define _MTK_ETH_H_
 
-/* Frame Engine Register Bases */
 #include 
+
+enum mkt_eth_capabilities {
+   MTK_TRGMII_BIT,
+   MTK_TRGMII_MT7621_CLK_BIT,
+
+   /* PATH BITS */
+   MTK_ETH_PATH_GMAC1_TRGMII_BIT,
+};
+
+#define MTK_TRGMII BIT(MTK_TRGMII_BIT)
+#define MTK_TRGMII_MT7621_CLK  BIT(MTK_TRGMII_MT7621_CLK_BIT)
+
+/* Supported path present on SoCs */
+#define MTK_ETH_PATH_GMAC1_TRGMII  BIT(MTK_ETH_PATH_GMAC1_TRGMII_BIT)
+
+#define MTK_GMAC1_TRGMII   (MTK_ETH_PATH_GMAC1_TRGMII | MTK_TRGMII)
+
+#define MTK_HAS_CAPS(caps, _x) (((caps) & (_x)) == (_x))
+
+#define MT7621_CAPS  (MT

[PATCH 05/31] mmc: mediatek: add support for MediaTek MT7891/MT7986 SoCs

2022-08-03 Thread Weijie Gao
This patch adds eMMC and SDXC support for MediaTek MT7981/MT7986 SoCs

Signed-off-by: Weijie Gao 
---
 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, &host->base->msdc_inten);
 
-   writel(0, tune_reg);
+   if (host->top_base) {
+   writel(0, &host->top_base->emmc_top_control);
+   writel(0, &host->top_base->emmc_top_cmd);
+   } else {
+   writel(0, tune_reg);
+   }
writel(0, &host->base->msdc_iocon);
 
if (host->r_smpl)
@@ -1507,9 +1512,14 @@ static void msdc_init_hw(struct msdc_host *host)
writel(0x403c0046, &host->base->patch_bit0);
writel(0x4089, &host->base->patch_bit1);
 
-   if (host->dev_comp->stop_clk_fix)
+   if (host->dev_comp->stop_clk_fix) {
clrsetbits_le32(&host->base->patch_bit1, MSDC_PB1_STOP_DLY_M,
3 << MSDC_PB1_STOP_DLY_S);
+   clrbits_le32(&host->base->sdc_fifo_cfg,
+SDC_FIFO_CFG_WRVALIDSEL);
+   clrbits_le32(&host->base->sdc_fifo_cfg,
+SDC_FIFO_CFG_RDVALIDSEL);
+   }
 
if (host->dev_comp->busy_check)
clrbits_le32(&host->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(&host->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(&host->top_base->emmc_top_control,
+PAD_DAT_RD_RXDLY_SEL);
+   clrbits_le32(&host->top_base->emmc_top_control,
+DATA_K_VALUE_SEL);
+   setbits_le32(&host->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(&host->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(&host->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(&host->base->sdc_cfg, SDC_CFG_DTOC_M,
3 << SDC_CFG_DTOC_S);
 
-   if (host->dev_comp->stop_clk_fix) {
-   clrbits_le32(&host->base->sdc_fifo_cfg,
-SDC_FIFO_CFG_WRVALIDSEL);
-   clrbits_le32(&host->base->sdc_fifo_cfg,
-SDC_FIFO_CFG_RDVALIDSEL);
-   }
 
host->def_tune_para.iocon = readl(&host->base->msdc_iocon);
host->def_tune_para.pad_tune = readl(&host->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,
+   .data_tune = true,
+   .busy_check = true,
+   .stop_clk_fix = true,
+   .enhance_rx = true,
+};
+
+static const struct msdc_compatible mt7981_compat = {
+   .clk_div_bits = 12,
+   .pad_tune0 = true,
+   .async_fifo = true,
+   .data_tune = true,
+   .busy_check = true,
+   .stop_clk_fix = true,
+};
+
 static const struct msdc_compatible mt8512_compat = {
.clk_div_bits = 12,
.pad_tune0 = true,
@@ -1824,6 +1860,8 @@ static const struct udevice_id msdc_ids[] = {
{ .compatible = "mediatek,mt7621-mmc", .data = (ulong)&mt7621_compat },
{ .compatible = "mediatek,mt7622-mmc", .data = (ulong)&mt7622_compat },
{ .compatible = "mediatek,mt7623-mmc", .data = (ulong)&mt7623_compat }

[PATCH 04/31] board: mediatek: add MT7981 reference boards

2022-08-03 Thread Weijie Gao
This patch adds general board files based on MT7981 SoCs.

Signed-off-by: Weijie Gao 
---
 arch/arm/dts/Makefile  |   5 +
 arch/arm/dts/mt7981-emmc-rfb.dts   | 139 +
 arch/arm/dts/mt7981-rfb.dts| 133 +++
 arch/arm/dts/mt7981-sd-rfb.dts | 139 +
 arch/arm/dts/mt7981-spim-nand-rfb.dts  | 138 
 arch/arm/dts/mt7981-spim-nor-rfb.dts   | 133 +++
 board/mediatek/mt7981/MAINTAINERS  |  10 ++
 board/mediatek/mt7981/Makefile |   3 +
 board/mediatek/mt7981/mt7981_rfb.c |  10 ++
 configs/mt7981_emmc_rfb_defconfig  |  64 
 configs/mt7981_rfb_defconfig   |  65 
 configs/mt7981_sd_rfb_defconfig|  64 
 configs/mt7981_spim_nand_rfb_defconfig |  59 +++
 configs/mt7981_spim_nor_rfb_defconfig  |  70 +
 include/configs/mt7981.h   |  26 +
 15 files changed, 1058 insertions(+)
 create mode 100644 arch/arm/dts/mt7981-emmc-rfb.dts
 create mode 100644 arch/arm/dts/mt7981-rfb.dts
 create mode 100644 arch/arm/dts/mt7981-sd-rfb.dts
 create mode 100644 arch/arm/dts/mt7981-spim-nand-rfb.dts
 create mode 100644 arch/arm/dts/mt7981-spim-nor-rfb.dts
 create mode 100644 board/mediatek/mt7981/MAINTAINERS
 create mode 100644 board/mediatek/mt7981/Makefile
 create mode 100644 board/mediatek/mt7981/mt7981_rfb.c
 create mode 100644 configs/mt7981_emmc_rfb_defconfig
 create mode 100644 configs/mt7981_rfb_defconfig
 create mode 100644 configs/mt7981_sd_rfb_defconfig
 create mode 100644 configs/mt7981_spim_nand_rfb_defconfig
 create mode 100644 configs/mt7981_spim_nor_rfb_defconfig
 create mode 100644 include/configs/mt7981.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eeb08116c0..3529e3e88a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1226,6 +1226,11 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7622-bananapi-bpi-r64.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
+   mt7981-rfb.dtb \
+   mt7981-spim-nand-rfb.dtb \
+   mt7981-spim-nor-rfb.dtb \
+   mt7981-emmc-rfb.dtb \
+   mt7981-sd-rfb.dtb \
mt7986a-rfb.dtb \
mt7986b-rfb.dtb \
mt7986a-sd-rfb.dtb \
diff --git a/arch/arm/dts/mt7981-emmc-rfb.dts
 b/arch/arm/dts/mt7981-emmc-rfb.dts
new file mode 100644
index 00..2b7eae99ce
--- /dev/null
+++ b/arch/arm/dts/mt7981-emmc-rfb.dts
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Sam Shih 
+ */
+
+/dts-v1/;
+#include "mt7981.dtsi"
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   model = "mt7981-rfb";
+   compatible = "mediatek,mt7981", "mediatek,mt7981-rfb";
+   chosen {
+   stdout-path = &uart0;
+   tick-timer = &timer0;
+   };
+
+   reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart1_pins>;
+   status = "disabled";
+};
+
+ð {
+   status = "okay";
+   mediatek,gmac-id = <0>;
+   phy-mode = "sgmii";
+   mediatek,switch = "mt7531";
+   reset-gpios = <&gpio 39 GPIO_ACTIVE_HIGH>;
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+};
+
+&pinctrl {
+   spic_pins: spi1-pins-func-1 {
+   mux {
+   function = "spi";
+   groups = "spi1_1";
+   };
+   };
+
+   uart1_pins: spi1-pins-func-3 {
+   mux {
+   function = "uart";
+   groups = "uart1_2";
+   };
+   };
+
+   /* pin15 as pwm0 */
+   one_pwm_pins: one-pwm-pins {
+   mux {
+   function = "pwm";
+   groups = "pwm0_1";
+   };
+   };
+
+   /* pin15 as pwm0 and pin14 as pwm1 */
+   two_pwm_pins: two-pwm-pins {
+   mux {
+   function = "pwm";
+   groups = "pwm0_1", "pwm1_0";
+   };
+   };
+
+   /* pin15 as pwm0, pin14 as pwm1, pin7 as pwm2 */
+   three_pwm_pins: three-pwm-pins {
+   mux {
+   function = "pwm";
+   groups = "pwm0_1", "pwm1_0", "pwm2";
+   };
+   };
+
+   mmc0_pins_default: mmc0default {
+   mux {
+   function = "flash";
+   groups =  "emmc_45";
+   };
+   conf-cmd-dat {
+   pins = "SPI0_

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

2022-08-03 Thread Weijie Gao
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 
---
 arch/arm/dts/Makefile  |   4 +
 arch/arm/dts/mt7986a-rfb.dts   | 218 +
 arch/arm/dts/mt7986a-sd-rfb.dts| 177 +++
 arch/arm/dts/mt7986b-rfb.dts   | 204 +++
 arch/arm/dts/mt7986b-sd-rfb.dts| 173 +++
 board/mediatek/mt7986/MAINTAINERS  |  10 ++
 board/mediatek/mt7986/Makefile |   3 +
 board/mediatek/mt7986/mt7986_rfb.c |  10 ++
 configs/mt7986_rfb_defconfig   |  66 +
 configs/mt7986a_emmc_rfb_defconfig |  64 +
 configs/mt7986a_sd_rfb_defconfig   |  64 +
 configs/mt7986b_emmc_rfb_defconfig |  64 +
 configs/mt7986b_sd_rfb_defconfig   |  64 +
 include/configs/mt7986.h   |  26 
 14 files changed, 1147 insertions(+)
 create mode 100644 arch/arm/dts/mt7986a-rfb.dts
 create mode 100644 arch/arm/dts/mt7986a-sd-rfb.dts
 create mode 100644 arch/arm/dts/mt7986b-rfb.dts
 create mode 100644 arch/arm/dts/mt7986b-sd-rfb.dts
 create mode 100644 board/mediatek/mt7986/MAINTAINERS
 create mode 100644 board/mediatek/mt7986/Makefile
 create mode 100644 board/mediatek/mt7986/mt7986_rfb.c
 create mode 100644 configs/mt7986_rfb_defconfig
 create mode 100644 configs/mt7986a_emmc_rfb_defconfig
 create mode 100644 configs/mt7986a_sd_rfb_defconfig
 create mode 100644 configs/mt7986b_emmc_rfb_defconfig
 create mode 100644 configs/mt7986b_sd_rfb_defconfig
 create mode 100644 include/configs/mt7986.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ceaa39e4b4..eeb08116c0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1226,6 +1226,10 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7622-bananapi-bpi-r64.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
+   mt7986a-rfb.dtb \
+   mt7986b-rfb.dtb \
+   mt7986a-sd-rfb.dtb \
+   mt7986b-sd-rfb.dtb \
mt8183-pumpkin.dtb \
mt8512-bm1-emmc.dtb \
mt8516-pumpkin.dtb \
diff --git a/arch/arm/dts/mt7986a-rfb.dts b/arch/arm/dts/mt7986a-rfb.dts
new file mode 100644
index 00..80def57e1a
--- /dev/null
+++ b/arch/arm/dts/mt7986a-rfb.dts
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Sam Shih 
+ */
+
+/dts-v1/;
+#include "mt7986.dtsi"
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   model = "mt7986-rfb";
+   compatible = "mediatek,mt7986", "mediatek,mt7986-rfb";
+   chosen {
+   stdout-path = &uart0;
+   tick-timer = &timer0;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator-3p3v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart1_pins>;
+   status = "disabled";
+};
+
+ð {
+   status = "okay";
+   mediatek,gmac-id = <0>;
+   phy-mode = "sgmii";
+   mediatek,switch = "mt7531";
+   reset-gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
+
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+};
+
+&pinctrl {
+   spi_flash_pins: spi0-pins-func-1 {
+   mux {
+   function = "flash";
+   groups = "spi0", "spi0_wp_hold";
+   };
+
+   conf-pu {
+   pins = "SPI2_CS", "SPI2_HOLD", "SPI2_WP";
+   drive-strength = ;
+   bias-pull-up = ;
+   };
+
+   conf-pd {
+   pins = "SPI2_CLK", "SPI2_MOSI", "SPI2_MISO";
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+   };
+
+   snfi_pins: snfi-pins-func-1 {
+   mux {
+   function = "flash";
+   groups = "snfi";
+   };
+
+   clk {
+   pins = "SPI0_CLK";
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+
+   conf-pu {
+   pins = "SPI0_CS", "SPI0_HOLD", "SPI0_WP";
+   drive-strength = ;
+

[PATCH 02/31] arm: mediatek: add support for MediaTek MT7981 SoC

2022-08-03 Thread Weijie Gao
This patch adds basic support for MediaTek MT7981 SoC.
This include the file that will initialize the SoC after boot and its
device tree.

Signed-off-by: Weijie Gao 
---
 arch/arm/dts/mt7981.dtsi  | 288 ++
 arch/arm/mach-mediatek/Kconfig|  12 +-
 arch/arm/mach-mediatek/Makefile   |   1 +
 arch/arm/mach-mediatek/mt7981/Makefile|   4 +
 arch/arm/mach-mediatek/mt7981/init.c  |  52 
 arch/arm/mach-mediatek/mt7981/lowlevel_init.S |  30 ++
 6 files changed, 386 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/mt7981.dtsi
 create mode 100644 arch/arm/mach-mediatek/mt7981/Makefile
 create mode 100644 arch/arm/mach-mediatek/mt7981/init.c
 create mode 100644 arch/arm/mach-mediatek/mt7981/lowlevel_init.S

diff --git a/arch/arm/dts/mt7981.dtsi b/arch/arm/dts/mt7981.dtsi
new file mode 100644
index 00..11609dc484
--- /dev/null
+++ b/arch/arm/dts/mt7981.dtsi
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ * Author: Sam Shih 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt7981";
+   interrupt-parent = <&gic>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   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>;
+   };
+   };
+
+   gpt_clk: gpt_dummy20m {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   u-boot,dm-pre-reloc;
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupt-parent = <&gic>;
+   clock-frequency = <1300>;
+   interrupts = ,
+,
+,
+;
+   arm,cpu-registers-not-fw-configured;
+   };
+
+   timer0: timer@10008000 {
+   compatible = "mediatek,mt7986-timer";
+   reg = <0x10008000 0x1000>;
+   interrupts = ;
+   clocks = <&gpt_clk>;
+   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 = <&gic>;
+   interrupt-controller;
+   reg = <0x0c00 0x4>,  /* GICD */
+ <0x0c08 0x20>; /* GICR */
+
+   interrupts = ;
+   };
+
+   fixed_plls: apmixedsys@1001e000 {
+   compatible = "mediatek,mt7981-fixed-plls";
+   reg = <0x1001e000 0x1000>;
+   #clock-cells = <1>;
+   u-boot,dm-pre-reloc;
+   };
+
+   topckgen: topckgen@1001b000 {
+   compatible = "mediatek,mt7981-topckgen";
+   reg = <0x1001b000 0x1000>;
+   clock-parent = <&fixed_plls>;
+   #clock-cells = <1>;
+   u-boot,dm-pre-reloc;
+   };
+
+   infracfg_ao: infracfg_ao@10001000 {
+   compatible = "mediatek,mt7981-infracfg_ao";
+   reg = <0x10001000 0x80>;
+   clock-parent = <&infracfg>;
+   #clock-cells = <1>;
+   u-boot,dm-pre-reloc;
+   };
+
+   infracfg: infracfg@10001000 {
+   compatible = "mediatek,mt7981-infracfg";
+   reg = <0x10001000 0x30>;
+   clock-parent = <&topckgen>;
+   #clock-cells = <1>;
+   u-boot,dm-pre-reloc;
+   };
+
+   pinctrl: pinctrl@11d0 {
+   compatible = "mediatek,mt7981-pinctrl";
+   reg = <0x11d0 0x1000>,
+ <0x11c0 0x1000>,
+ <0x11c1 0x1000>,
+ <0x11d2 0x1000>,
+ <0x11e0 0x1000>,
+ <0x11e2 0x1000>,
+ <0x11f0 0x1000>,
+ <0x11f1 0x1000>,
+ <0x1000b000 0x1000>;
+   reg-names = "gpio_base", "iocfg_rt_base", "iocfg_rm_base",
+   "iocfg_rb_base", "iocfg_lb_base", "iocfg_bl_base",
+   "iocfg_tm_base", "iocfg_tl_base", "eint";
+   gpio: gpio-controller {
+ 

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

2022-08-03 Thread Weijie Gao
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
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 
+ */
+
+&topckgen {
+   u-boot,dm-pre-reloc;
+};
+
+&pericfg {
+   u-boot,dm-pre-reloc;
+};
+
+&apmixedsys {
+   u-boot,dm-pre-reloc;
+};
+
+&timer0 {
+   u-boot,dm-pre-reloc;
+};
+
+&uart0 {
+   u-boot,dm-pre-reloc;
+};
+
+&snand {
+   u-boot,dm-pre-reloc;
+};
+
+&pinctrl {
+   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 = <&gic>;
+   #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 = <&gic>;
+   clock-frequency = <1300>;
+   interrupts = ,
+,
+,
+;
+   arm,cpu-registers-not-fw-configured;
+   };
+
+   timer0: timer@10008000 {
+   compatible = "mediatek,mt7986-timer";
+   reg = <0x10008000 0x1000>;
+   interrupts = ;
+   clocks = <&infracfg 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 = <&gic>;
+   interrupt-controller;
+   reg = <0x0c00 0x4>,  /* GICD */
+ <0x0c08 0x20>; /* GICR */
+
+   interrupts = ;
+   };
+
+   fixed_plls: apmixedsys@1001E000 {
+   compatible = "mediatek,mt7986-fixed-plls";
+   reg = <0x1001E000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   topckgen: topckgen@1001B000 {
+   compatible = "mediatek,mt7986-topckgen";
+   reg = <0x1001B000 0x1000>;
+   clock-parent = <&fixed_plls>;
+   #clock-cells = <1>;
+   };
+
+   infracfg_ao: infracfg_ao@10001000 {
+   compatible = "med

[PATCH 00/31] Add support for MediaTek MT7981/MT7986 SoCs

2022-08-03 Thread Weijie Gao
This patch series add support for MediaTek MT7981/MT7986 SoCs with their
reference boards and related drivers.

This patch series add basic boot support on eMMC/SD/SPI-NOR/SPI-NAND for
 these
boards. The clock, pinctrl drivers and the SoC initializaton code are also
included.

Product spec for MT7986:
https://www.mediatek.com/products/home-networking/mediatek-filogic-830

Weijie Gao (31):
  arm: mediatek: add support for MediaTek MT7986 SoC
  arm: mediatek: add support for MediaTek MT7981 SoC
  board: mediatek: add MT7986 reference boards
  board: mediatek: add MT7981 reference boards
  mmc: mediatek: add support for MediaTek MT7891/MT7986 SoCs
  net: mediatek: use a struct to cover variations of all SoCs
  net: mediatek: stop using bitfileds for DMA descriptors
  net: mediatek: add support for PDMA v2
  net: mediatek: add support for MediaTek MT7981/MT7986
  serial: mtk: add support for using dynamic baud clock souce
  arm: dts: mt7622: force high-speed mode for uart
  pwm: mtk: add support for MediaTek MT7986 SoC
  pwm: mtk: add support for MediaTek MT7981 SoC
  timer: mtk: add support for MediaTek MT7981/MT7986 SoCs
  watchdog: mediatek: add support for MediaTek MT7986 SoC
  spi: add support for MediaTek spi-mem controller
  i2c: add support for MediaTek I2C interface
  arm: dts: mt7622: add i2c support
  dt-bindings: pinctrl: mediatek: add a header for common pinconf
parameters
  pinctrl: mediatek: add pinctrl driver for MT7981 SoC
  pinctrl: mediatek: add pinctrl driver for MT7986 SoC
  clk: mediatek: add CLK_BYPASS_XTAL flag to allow bypassing searching
clock parent of xtal clock
  clk: mediatek: add support to configure clock driver parent
  clk: mediatek: add infrasys clock mux support
  clk: mediatek: add CLK_XTAL support for clock driver
  clk: mediatek: add clock driver support for MediaTek MT7986 SoC
  clk: mediatek: add clock driver support for MediaTek MT7981 SoC
  tools: mtk_image: split gfh header verification into a new function
  tools: mtk_image: split the code of generating NAND header into a new
file
  tools: mtk_image: add support for nand headers used by newer chips
  MAINTAINERS: update maintainer for MediaTek ARM platform

 MAINTAINERS   |5 +
 arch/arm/dts/Makefile |9 +
 arch/arm/dts/mt7622-rfb.dts   |   18 +
 arch/arm/dts/mt7622.dtsi  |   25 +
 arch/arm/dts/mt7981-emmc-rfb.dts  |  139 +++
 arch/arm/dts/mt7981-rfb.dts   |  133 +++
 arch/arm/dts/mt7981-sd-rfb.dts|  139 +++
 arch/arm/dts/mt7981-spim-nand-rfb.dts |  138 +++
 arch/arm/dts/mt7981-spim-nor-rfb.dts  |  133 +++
 arch/arm/dts/mt7981.dtsi  |  288 +
 arch/arm/dts/mt7986-u-boot.dtsi   |   33 +
 arch/arm/dts/mt7986.dtsi  |  341 ++
 arch/arm/dts/mt7986a-rfb.dts  |  218 
 arch/arm/dts/mt7986a-sd-rfb.dts   |  177 +++
 arch/arm/dts/mt7986b-rfb.dts  |  204 
 arch/arm/dts/mt7986b-sd-rfb.dts   |  173 +++
 arch/arm/mach-mediatek/Kconfig|   21 +
 arch/arm/mach-mediatek/Makefile   |2 +
 arch/arm/mach-mediatek/mt7981/Makefile|4 +
 arch/arm/mach-mediatek/mt7981/init.c  |   52 +
 arch/arm/mach-mediatek/mt7981/lowlevel_init.S |   30 +
 arch/arm/mach-mediatek/mt7986/Makefile|4 +
 arch/arm/mach-mediatek/mt7986/init.c  |   53 +
 arch/arm/mach-mediatek/mt7986/lowlevel_init.S |   30 +
 board/mediatek/mt7981/MAINTAINERS |   10 +
 board/mediatek/mt7981/Makefile|3 +
 board/mediatek/mt7981/mt7981_rfb.c|   10 +
 board/mediatek/mt7986/MAINTAINERS |   10 +
 board/mediatek/mt7986/Makefile|3 +
 board/mediatek/mt7986/mt7986_rfb.c|   10 +
 configs/mt7981_emmc_rfb_defconfig |   64 +
 configs/mt7981_rfb_defconfig  |   65 +
 configs/mt7981_sd_rfb_defconfig   |   64 +
 configs/mt7981_spim_nand_rfb_defconfig|   59 +
 configs/mt7981_spim_nor_rfb_defconfig |   70 ++
 configs/mt7986_rfb_defconfig  |   66 ++
 configs/mt7986a_emmc_rfb_defconfig|   64 +
 configs/mt7986a_sd_rfb_defconfig  |   64 +
 configs/mt7986b_emmc_rfb_defconfig|   64 +
 configs/mt7986b_sd_rfb_defconfig  |   64 +
 drivers/clk/mediatek/Makefile |2 +
 drivers/clk/mediatek/clk-mt7981.c |  682 +++
 drivers/clk/mediatek/clk-mt7986.c |  671 +++
 drivers/clk/mediatek/clk-mtk.c|  157 ++-
 drivers/clk/mediatek/clk-mtk.h|   10 +-
 drivers/i2c/Kconfig   |9 +
 drivers/i2c/Makefile  |1 +
 drivers/i2c/mtk_i2c.c |  822 +
 drivers/mmc/mtk-sd.c  

Re: [PATCH] arm: bcmbca: add bcm63138 SoC support

2022-08-03 Thread Florian Fainelli




On 8/1/2022 3:18 PM, William Zhang wrote:

BCM63138 is an ARM A9 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory, peripheral timer and
Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

This patch applies on top of the my previous patch [1] and depends
on the timer support from patch [2].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/490597.html
[2] https://lists.denx.de/pipermail/u-boot/2022-August/490570.html

Signed-off-by: William Zhang 


FWIW:

Reviewed-by: Florian Fainelli 
--
Florian


Re: [PATCH] timer: bcmbca: Add Broadcom BCMBCA timer support

2022-08-03 Thread Florian Fainelli




On 8/2/2022 5:07 PM, William Zhang wrote:

Hi Rafal,

On 08/01/2022 10:26 PM, Rafał Miłecki wrote:

On 2.08.2022 00:03, William Zhang wrote:

This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.
Signed-off-by: William Zhang 

(...)

+static const struct udevice_id bcmbca_timer_ids[] = {
+    { .compatible = "brcm,bcm-timers" },
+    { }
+};
+
+U_BOOT_DRIVER(bcmbca_timer) = {
+    .name = "bcmbca_timer",
+    .id = UCLASS_TIMER,
+    .of_match = bcmbca_timer_ids,
+    .priv_auto = sizeof(struct bcmbca_timer_priv),
+    .probe = bcmbca_timer_probe,
+    .ops = &bcmbca_timer_ops,
+    .flags = DM_FLAG_PRE_RELOC,
+};


That "brcm,bcm-timers" seems like a really wide bidding. Is that exact
timer block guaranteed to be present on all Broadcom devices? Does it
exist e.g. on Northstar SoCs? Or old MIPS SoCs like BCM4706?


Agree I will make change to use brcm,bcmbca-timers.


Why not change to use a compatible string that uses the first chip in 
which this timer block was introduced, was that 6345 or later?





It seems that even across BCMBCA devices this block may differ and may
need different bindings. Most SoCs have 4 CTL and 4 CNT registers but
some have only 3 + 3 (BCM6838 BCM60333 BCM63268).
This timer driver is intended for the clock source for u-boot only so 
only need the first channel. Although it could work for the old mips 
based dsl chip, BCMBCA chip family support is only for the new ARM based 
  chips which is stated in the BCMBA introduction patch.




Finally could we have that binding actually documented?
I don't see u-boot has binding document.  I believe it generally use 
linux binding document.  I have no plan to upstream this driver to 
linux. But I can put the binding info in the driver if that is the right 
way to do in u-boot.


Out of curiosity, why does u-boot require this timer as opposed to using 
the Cortex-A9 architected timers? Is it necessary to boot strap the A9 
timers?

--
Florian


[PATCH] binman: Example for csf signing

2022-08-03 Thread Simon Glass
This is a starting point for running a csf tool to sign some sections of
the image and add the signature in.

It is missing the test in ftest.py

Signed-off-by: Simon Glass 
---

 arch/arm/dts/imx8mm-u-boot.dtsi  | 96 +---
 tools/binman/btool/csf.py| 87 +
 tools/binman/etype/imx8mm_csf.py | 81 +++
 3 files changed, 230 insertions(+), 34 deletions(-)
 create mode 100644 tools/binman/btool/csf.py
 create mode 100644 tools/binman/etype/imx8mm_csf.py

diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index f792b421e89..8188d4b8db2 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -28,54 +28,82 @@
 };
 
 &binman {
-   u-boot-spl-ddr {
-   align = <4>;
-   align-size = <4>;
-   filename = "u-boot-spl-ddr.bin";
-   pad-byte = <0xff>;
-
-   u-boot-spl {
-   align-end = <4>;
-   filename = "u-boot-spl.bin";
+   secure-boot {
+   filename = "secure-boot.bin";
+   type = "section";
+   /* Image Vector Table - not sure what goes in here */
+   vector_table: vector-table {
+   type = "fill";
+   size = <0x20>;
};
 
-   ddr-1d-imem-fw {
-   filename = "lpddr4_pmu_train_1d_imem.bin";
-   align-end = <4>;
-   type = "blob-ext";
+   /* Something in here? Fixed size? */
+   boot_data: boot-data {
+   type = "fill";
+   size = <0x20>;
};
 
-   ddr-1d-dmem-fw {
-   filename = "lpddr4_pmu_train_1d_dmem.bin";
-   align-end = <4>;
-   type = "blob-ext";
-   };
+   /* Starts at 0x40 - *entry */
+   ddr: u-boot-spl-ddr {
+   type = "section";
+   align = <4>;
+   align-size = <4>;
+   filename = "u-boot-spl-ddr.bin";
+   pad-byte = <0xff>;
+
+   u-boot-spl {
+   align-end = <4>;
+   filename = "u-boot-spl.bin";
+   };
 
-   ddr-2d-imem-fw {
-   filename = "lpddr4_pmu_train_2d_imem.bin";
-   align-end = <4>;
-   type = "blob-ext";
-   };
+   ddr-1d-imem-fw {
+   filename = "lpddr4_pmu_train_1d_imem.bin";
+   align-end = <4>;
+   type = "blob-ext";
+   };
 
-   ddr-2d-dmem-fw {
-   filename = "lpddr4_pmu_train_2d_dmem.bin";
-   align-end = <4>;
-   type = "blob-ext";
+   ddr-1d-dmem-fw {
+   filename = "lpddr4_pmu_train_1d_dmem.bin";
+   align-end = <4>;
+   type = "blob-ext";
+   };
+
+   ddr-2d-imem-fw {
+   filename = "lpddr4_pmu_train_2d_imem.bin";
+   align-end = <4>;
+   type = "blob-ext";
+   };
+
+   ddr-2d-dmem-fw {
+   filename = "lpddr4_pmu_train_2d_dmem.bin";
+   align-end = <4>;
+   type = "blob-ext";
+   };
};
-   };
 
-   spl {
-   filename = "spl.bin";
+   spl: spl {
+   type = "section";
+   filename = "spl.bin";
+
+   /* need padding after this entry */
+   align-end = <0x1>;
 
-   mkimage {
-   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
0x7e1000";
+   mkimage {
+   args = "-n spl/u-boot-spl.cfgout -T imx8mimage 
-e 0x7e1000";
 
-   blob {
-   filename = "u-boot-spl-ddr.bin";
+   blob {
+   filename = "u-boot-spl-ddr.bin";
+   };
};
};
+
+   imx8mm-csf {
+   content = <&vector_table &boot_data &ddr &spl>;
+align-end = <0x1000>;   /* padding? */
+   };
};
 
+
itb {
filename = "u-boot.itb";
 
diff --git a/tools/binman/btool/csf.py b/tools/binman/btool/csf.py
new file mode 100644
ind

Re: [PATCH v2] gpio: aspeed: port Linux dt-bindings header file

2022-08-03 Thread Joel Stanley
On Thu, 4 Aug 2022 at 01:02, Dhananjay Phadke
 wrote:
>
> Ported as is, makes it easier to add readable GPIO definitions
> in DTS files.
>
> Signed-off-by: Dhananjay Phadke 
> ---
>  include/dt-bindings/gpio/aspeed-gpio.h | 49 ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
>
> diff --git a/include/dt-bindings/gpio/aspeed-gpio.h 
> b/include/dt-bindings/gpio/aspeed-gpio.h
> new file mode 100644
> index 00..adab2f56c2
> --- /dev/null
> +++ b/include/dt-bindings/gpio/aspeed-gpio.h
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */

As you mention this is from the kernel, but you forgot to add the
copyright information for the file you copied. I suggest you add:

Copyright 2022 IBM Corp.

Cheers,

Joel

> +/*
> + * This header provides constants for binding aspeed,*-gpio.
> + *
> + * The first cell in Aspeed's GPIO specifier is the GPIO ID. The macros below
> + * provide names for this.
> + *
> + * The second cell contains standard flag values specified in gpio.h.
> + */
> +
> +#ifndef _DT_BINDINGS_GPIO_ASPEED_GPIO_H
> +#define _DT_BINDINGS_GPIO_ASPEED_GPIO_H
> +
> +#include 
> +
> +#define ASPEED_GPIO_PORT_A 0
> +#define ASPEED_GPIO_PORT_B 1
> +#define ASPEED_GPIO_PORT_C 2
> +#define ASPEED_GPIO_PORT_D 3
> +#define ASPEED_GPIO_PORT_E 4
> +#define ASPEED_GPIO_PORT_F 5
> +#define ASPEED_GPIO_PORT_G 6
> +#define ASPEED_GPIO_PORT_H 7
> +#define ASPEED_GPIO_PORT_I 8
> +#define ASPEED_GPIO_PORT_J 9
> +#define ASPEED_GPIO_PORT_K 10
> +#define ASPEED_GPIO_PORT_L 11
> +#define ASPEED_GPIO_PORT_M 12
> +#define ASPEED_GPIO_PORT_N 13
> +#define ASPEED_GPIO_PORT_O 14
> +#define ASPEED_GPIO_PORT_P 15
> +#define ASPEED_GPIO_PORT_Q 16
> +#define ASPEED_GPIO_PORT_R 17
> +#define ASPEED_GPIO_PORT_S 18
> +#define ASPEED_GPIO_PORT_T 19
> +#define ASPEED_GPIO_PORT_U 20
> +#define ASPEED_GPIO_PORT_V 21
> +#define ASPEED_GPIO_PORT_W 22
> +#define ASPEED_GPIO_PORT_X 23
> +#define ASPEED_GPIO_PORT_Y 24
> +#define ASPEED_GPIO_PORT_Z 25
> +#define ASPEED_GPIO_PORT_AA 26
> +#define ASPEED_GPIO_PORT_AB 27
> +#define ASPEED_GPIO_PORT_AC 28
> +
> +#define ASPEED_GPIO(port, offset) \
> +   ((ASPEED_GPIO_PORT_##port * 8) + (offset))
> +
> +#endif
> --
> 2.25.1
>


Re: [PATCH 0/5] arm: mvebu: Cleanup u-boot,dm-pre-reloc code

2022-08-03 Thread Tony Dinh
Hi Pali,

I ran 3 tests: UART booting, SPI NOR booting from SPL, and SPI NOR
booting from BootROM (CONFIG_SPL_SPI is not set). All tests work
great!

Synology DS116 (Armada 385).
Tested-by: Tony Dinh 

Thanks,
Tony

On Wed, Aug 3, 2022 at 4:01 AM Pali Rohár  wrote:
>
> This patch series cleanup u-boot,dm-pre-reloc code in 32-bit mvebu
> device tree files. All repeated code patterns are moved into the new
> mvebu-u-boot.dtsi file which is automatically included by U-Boot build
> process into all mvebu boards. In file mvebu-u-boot.dtsi is also enabled
> u-boot,dm-pre-reloc for SPI node when SPL is compiled with SPI driver
> for loading proper U-Boot. This avoids manually defining
>   &spi0 { u-boot,dm-pre-reloc; };
> in every armada soc which store U-Boot in SPI NOR.
>
> I tested this patch series only on Armada 385 Turris Omnia board (both
> UART and SPI-NOR booting). Please test it on other Armada boards.
>
> CI tests were running at:
> https://github.com/u-boot/u-boot/pull/203
> But some x86 test failed, which must be irrelevant as this patch series
> did not touch code outside of arch/arm/.
>
> Pali Rohár (5):
>   arm: mvebu: a7040/a8040/cn9130: Add spi0 dts reference
>   arm: mvebu: Introduce mvebu-u-boot.dtsi for 32-bit Armada SoCs
>   arm: mvebu: Remove redundant u-boot,dm-pre-reloc from all 32-bit
> Armada SoCs
>   arm: mvebu: armada-xp-theadorable.dts: Move u-boot,dm-pre-reloc to
> -u-boot.dtsi
>   arm: mvebu: armada-38x-controlcenterdc.dts: Move u-boot,dm-pre-reloc
> to -u-boot.dtsi
>
>  arch/arm/dts/armada-370-xp.dtsi   |  1 -
>  arch/arm/dts/armada-375-db.dts|  3 ---
>  arch/arm/dts/armada-375.dtsi  |  2 --
>  arch/arm/dts/armada-385-atl-x530-u-boot.dtsi  | 14 ++-
>  arch/arm/dts/armada-385-db-88f6820-amc.dts|  3 ---
>  .../dts/armada-385-turris-omnia-u-boot.dtsi   |  8 +-
>  arch/arm/dts/armada-388-clearfog-u-boot.dtsi  |  2 ++
>  arch/arm/dts/armada-388-gp.dts|  3 ---
>  arch/arm/dts/armada-388-helios4-u-boot.dtsi   |  2 ++
>  .../armada-38x-controlcenterdc-u-boot.dtsi| 25 +++
>  arch/arm/dts/armada-38x-controlcenterdc.dts   | 20 ---
>  .../arm/dts/armada-38x-solidrun-microsom.dtsi |  1 -
>  arch/arm/dts/armada-38x.dtsi  |  2 --
>  arch/arm/dts/armada-7040.dtsi |  3 +++
>  arch/arm/dts/armada-8040.dtsi |  3 +++
>  .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi| 13 --
>  arch/arm/dts/armada-xp-crs305-1g-4s.dtsi  |  1 -
>  .../dts/armada-xp-crs326-24g-2s-u-boot.dtsi   | 13 --
>  arch/arm/dts/armada-xp-crs326-24g-2s.dtsi |  1 -
>  .../armada-xp-crs328-4c-20s-4s-u-boot.dtsi| 13 --
>  arch/arm/dts/armada-xp-crs328-4c-20s-4s.dtsi  |  1 -
>  .../dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi   | 12 +
>  arch/arm/dts/armada-xp-gp-u-boot.dtsi | 19 --
>  arch/arm/dts/armada-xp-maxbcm.dts |  1 -
>  .../dts/armada-xp-synology-ds414-u-boot.dtsi  |  9 ---
>  arch/arm/dts/armada-xp-synology-ds414.dts |  1 -
>  .../arm/dts/armada-xp-theadorable-u-boot.dtsi |  5 
>  arch/arm/dts/armada-xp-theadorable.dts|  4 ---
>  arch/arm/dts/armada-xp.dtsi   |  1 -
>  arch/arm/dts/cn9130.dtsi  |  3 +++
>  arch/arm/dts/mvebu-u-boot.dtsi| 24 ++
>  31 files changed, 71 insertions(+), 142 deletions(-)
>  create mode 100644 arch/arm/dts/armada-38x-controlcenterdc-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/armada-xp-crs326-24g-2s-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/armada-xp-crs328-4c-20s-4s-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/armada-xp-gp-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/armada-xp-synology-ds414-u-boot.dtsi
>  create mode 100644 arch/arm/dts/armada-xp-theadorable-u-boot.dtsi
>  create mode 100644 arch/arm/dts/mvebu-u-boot.dtsi
>
> --
> 2.20.1
>


[PATCH v2] gpio: aspeed: port Linux dt-bindings header file

2022-08-03 Thread Dhananjay Phadke
Ported as is, makes it easier to add readable GPIO definitions
in DTS files.

Signed-off-by: Dhananjay Phadke 
---
 include/dt-bindings/gpio/aspeed-gpio.h | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h

diff --git a/include/dt-bindings/gpio/aspeed-gpio.h 
b/include/dt-bindings/gpio/aspeed-gpio.h
new file mode 100644
index 00..adab2f56c2
--- /dev/null
+++ b/include/dt-bindings/gpio/aspeed-gpio.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * This header provides constants for binding aspeed,*-gpio.
+ *
+ * The first cell in Aspeed's GPIO specifier is the GPIO ID. The macros below
+ * provide names for this.
+ *
+ * The second cell contains standard flag values specified in gpio.h.
+ */
+
+#ifndef _DT_BINDINGS_GPIO_ASPEED_GPIO_H
+#define _DT_BINDINGS_GPIO_ASPEED_GPIO_H
+
+#include 
+
+#define ASPEED_GPIO_PORT_A 0
+#define ASPEED_GPIO_PORT_B 1
+#define ASPEED_GPIO_PORT_C 2
+#define ASPEED_GPIO_PORT_D 3
+#define ASPEED_GPIO_PORT_E 4
+#define ASPEED_GPIO_PORT_F 5
+#define ASPEED_GPIO_PORT_G 6
+#define ASPEED_GPIO_PORT_H 7
+#define ASPEED_GPIO_PORT_I 8
+#define ASPEED_GPIO_PORT_J 9
+#define ASPEED_GPIO_PORT_K 10
+#define ASPEED_GPIO_PORT_L 11
+#define ASPEED_GPIO_PORT_M 12
+#define ASPEED_GPIO_PORT_N 13
+#define ASPEED_GPIO_PORT_O 14
+#define ASPEED_GPIO_PORT_P 15
+#define ASPEED_GPIO_PORT_Q 16
+#define ASPEED_GPIO_PORT_R 17
+#define ASPEED_GPIO_PORT_S 18
+#define ASPEED_GPIO_PORT_T 19
+#define ASPEED_GPIO_PORT_U 20
+#define ASPEED_GPIO_PORT_V 21
+#define ASPEED_GPIO_PORT_W 22
+#define ASPEED_GPIO_PORT_X 23
+#define ASPEED_GPIO_PORT_Y 24
+#define ASPEED_GPIO_PORT_Z 25
+#define ASPEED_GPIO_PORT_AA 26
+#define ASPEED_GPIO_PORT_AB 27
+#define ASPEED_GPIO_PORT_AC 28
+
+#define ASPEED_GPIO(port, offset) \
+   ((ASPEED_GPIO_PORT_##port * 8) + (offset))
+
+#endif
-- 
2.25.1



Re: [PATCH] gpio: aspeed: port Linux dt-bindings header file

2022-08-03 Thread Dhananjay Phadke

On 8/2/2022 10:34 PM, Billy Tsai wrote:

Hello,

On 2022/8/3, 10:10 AM, "Billy Tsai"  wrote:

 Reviewed-by: Billy Tsai 

 On 2022/8/3, 9:46 AM, "ChiaWei Wang"  wrote:

 Acked-by: Chia-Wei Wang 

 > > From: Dhananjay Phadke 
 > > Sent: Wednesday, August 3, 2022 4:55 AM
 > >
 > > Ported as is, makes it easier to add readable GPIO definitions in 
DTS files.
 > >
 > > Signed-off-by: Dhananjay Phadke 
 > > ---
 > >  include/dt-bindings/gpio/aspeed-gpio.h | 49 
++
 > >  1 file changed, 49 insertions(+)
 > >  create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h

[...]

 > > +
 > > +#define ASPEED_GPIO(port, offset) \
 > > +((ASPEED_GPIO_PORT_##port * 8) + offset)
Please help to fix the check patch warning.
"Macro argument 'offset' may be better as '(offset)' to avoid precedence issues"
((ASPEED_GPIO_PORT_##port * 8) + (offset))
 > > +


Yes, I noticed this, but it would mean this will diverge from
kernel. I can send v2 here and then sync to kernel later.

Regards,
Dhananjay



[PATCH] gpio: Remove mvgpio driver

2022-08-03 Thread Chris Packham
The last user of this driver was removed in commit dee08b1999e2 ("arm:
Remove gplugd board"). Remove the unused driver.

Signed-off-by: Chris Packham 
---

 drivers/gpio/Makefile |  1 -
 drivers/gpio/mvgpio.c | 97 ---
 drivers/gpio/mvgpio.h | 53 ---
 3 files changed, 151 deletions(-)
 delete mode 100644 drivers/gpio/mvgpio.c
 delete mode 100644 drivers/gpio/mvgpio.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 219f37e0e434..39762fa06ce9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -24,7 +24,6 @@ obj-$(CONFIG_INTEL_BROADWELL_GPIO)+= 
intel_broadwell_gpio.o
 obj-$(CONFIG_IPROC_GPIO)   += iproc_gpio.o
 obj-$(CONFIG_KIRKWOOD_GPIO)+= kw_gpio.o
 obj-$(CONFIG_KONA_GPIO)+= kona_gpio.o
-obj-$(CONFIG_MARVELL_GPIO) += mvgpio.o
 obj-$(CONFIG_MCP230XX_GPIO)+= mcp230xx_gpio.o
 obj-$(CONFIG_MXC_GPIO) += mxc_gpio.o
 obj-$(CONFIG_MXS_GPIO) += mxs_gpio.o
diff --git a/drivers/gpio/mvgpio.c b/drivers/gpio/mvgpio.c
deleted file mode 100644
index 12e7197daf7b..
--- a/drivers/gpio/mvgpio.c
+++ /dev/null
@@ -1,97 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2011
- * eInfochips Ltd. 
- * Written-by: Ajay Bhargav 
- *
- * (C) Copyright 2010
- * Marvell Semiconductor 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include "mvgpio.h"
-#include 
-
-#ifndef MV_MAX_GPIO
-#define MV_MAX_GPIO128
-#endif
-
-int gpio_request(unsigned gpio, const char *label)
-{
-   if (gpio >= MV_MAX_GPIO) {
-   printf("%s: Invalid GPIO requested %d\n", __func__, gpio);
-   return -1;
-   }
-   return 0;
-}
-
-int gpio_free(unsigned gpio)
-{
-   return 0;
-}
-
-int gpio_direction_input(unsigned gpio)
-{
-   struct gpio_reg *gpio_reg_bank;
-
-   if (gpio >= MV_MAX_GPIO) {
-   printf("%s: Invalid GPIO %d\n", __func__, gpio);
-   return -1;
-   }
-
-   gpio_reg_bank = get_gpio_base(GPIO_TO_REG(gpio));
-   writel(GPIO_TO_BIT(gpio), &gpio_reg_bank->gcdr);
-   return 0;
-}
-
-int gpio_direction_output(unsigned gpio, int value)
-{
-   struct gpio_reg *gpio_reg_bank;
-
-   if (gpio >= MV_MAX_GPIO) {
-   printf("%s: Invalid GPIO %d\n", __func__, gpio);
-   return -1;
-   }
-
-   gpio_reg_bank = get_gpio_base(GPIO_TO_REG(gpio));
-   writel(GPIO_TO_BIT(gpio), &gpio_reg_bank->gsdr);
-   gpio_set_value(gpio, value);
-   return 0;
-}
-
-int gpio_get_value(unsigned gpio)
-{
-   struct gpio_reg *gpio_reg_bank;
-   u32 gpio_val;
-
-   if (gpio >= MV_MAX_GPIO) {
-   printf("%s: Invalid GPIO %d\n", __func__, gpio);
-   return -1;
-   }
-
-   gpio_reg_bank = get_gpio_base(GPIO_TO_REG(gpio));
-   gpio_val = readl(&gpio_reg_bank->gplr);
-
-   return GPIO_VAL(gpio, gpio_val);
-}
-
-int gpio_set_value(unsigned gpio, int value)
-{
-   struct gpio_reg *gpio_reg_bank;
-
-   if (gpio >= MV_MAX_GPIO) {
-   printf("%s: Invalid GPIO %d\n", __func__, gpio);
-   return -1;
-   }
-
-   gpio_reg_bank = get_gpio_base(GPIO_TO_REG(gpio));
-   if (value)
-   writel(GPIO_TO_BIT(gpio), &gpio_reg_bank->gpsr);
-   else
-   writel(GPIO_TO_BIT(gpio), &gpio_reg_bank->gpcr);
-
-   return 0;
-}
diff --git a/drivers/gpio/mvgpio.h b/drivers/gpio/mvgpio.h
deleted file mode 100644
index d68c48e63737..
--- a/drivers/gpio/mvgpio.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2011
- * eInfochips Ltd. 
- * Written-by: Ajay Bhargav 
- *
- * (C) Copyright 2010
- * Marvell Semiconductor 
- */
-
-#ifndef __MVGPIO_H__
-#define __MVGPIO_H__
-
-#include 
-
-/*
- * GPIO Register map for Marvell SOCs
- */
-struct gpio_reg {
-   u32 gplr;   /* Pin Level Register - 0x */
-   u32 pad0[2];
-   u32 gpdr;   /* Pin Direction Register - 0x000C */
-   u32 pad1[2];
-   u32 gpsr;   /* Pin Output Set Register - 0x0018 */
-   u32 pad2[2];
-   u32 gpcr;   /* Pin Output Clear Register - 0x0024 */
-   u32 pad3[2];
-   u32 grer;   /* Rising-Edge Detect Enable Register - 0x0030 */
-   u32 pad4[2];
-   u32 gfer;   /* Falling-Edge Detect Enable Register - 0x003C */
-   u32 pad5[2];
-   u32 gedr;   /* Edge Detect Status Register - 0x0048 */
-   u32 pad6[2];
-   u32 gsdr;   /* Bitwise Set of GPIO Direction Register - 0x0054 */
-   u32 pad7[2];
-   u32 gcdr;   /* Bitwise Clear of GPIO Direction Register - 0x0060 */
-   u32 pad8[2];
-   u32 gsrer;  /* Bitwise Set of Rising-Edge Detect Enable
-  Register - 0x006C */
-   u32 pad9[2];
-   u32 gcrer;  /* Bitwise Clear of Rising-Edge Detect Enable
-  Register - 0x0078 */
-   u32 pad10[2];
-   u32 gsfer;  /* Bitwise S

[PATCH] Makefile: Unify condition for mpc85xx reset vector

2022-08-03 Thread Pali Rohár
Use 'CONFIG_MPC85XX_HAVE_RESET_VECTOR && CONFIG_OF_SEPARATE' pattern
instead of 'CONFIG_MPC85XX_HAVE_RESET_VECTOR && !CONFIG_OF_EMBED' also in
OBJCOPYFLAGS_u-boot-nodtb.bin as this pattern is used in rest of Makefile.

Signed-off-by: Pali Rohár 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index d659c8118cba..23bf0c8b1e62 100644
--- a/Makefile
+++ b/Makefile
@@ -1267,7 +1267,7 @@ spl/u-boot-spl.srec: spl/u-boot-spl FORCE
 
 OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
$(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
-   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),$(if 
$(CONFIG_OF_EMBED),,-R .bootpg -R .resetvec))
+   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),$(if 
$(CONFIG_OF_SEPARATE),-R .bootpg -R .resetvec))
 
 binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
-- 
2.20.1



[PATCH v3] Provide more details of exactly how configuration signatures are calculated

2022-08-03 Thread Martin Bonner
The only changes from [PATCH v2] are
1. It is (I think) a valid patch file
2. It has come from my corporate email address (which surprisingly forces less 
mangling than gmail).
3. I have extended the commit message slightly

Apologies for the irrelevant email footer - it is automatically added by 
corporate IT.

Please apply with:
git am --scissors file.eml

-- >8 --

Describe exactly which bytes are hashed and in what order so that external
tools can calculate a valid signature.

Signed-off-by: Martin Bonner 
---
 doc/uImage.FIT/signature.txt | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index 61a72db3c7..c71280b63b 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -382,6 +382,32 @@ verified later even if the FIT has been signed with other 
keys in the
 meantime.


+Details
+---
+The signature node contains a property ('hashed-nodes') which lists all the
+nodes that the signature was made over.  The image is walked in order and each
+tag processed as follows:
+- DTB_BEGIN_NODE: The tag and the following name are included in the signature
+  if the node or its parent are present in 'hashed-nodes'
+- DTB_END_NODE: The tag is included in the signature if the node or its parent
+  are present in 'hashed-nodes'
+- DTB_PROPERTY: The tag, the length word, the offset in the string table, and
+  the data are all included if the current node is present in 'hashed-nodes'
+  and the property name is not 'data'.
+- DTB_END: The tag is always included in the signature.
+- DTB_NOP: The tag is included in the signature if the current node is present
+  in 'hashed-nodes'
+
+In addition, the signature contains a property 'hashed-strings' which contains
+the offset and length in the string table of the strings that are to be
+included in the signature (this is done last).
+
+IMPORTANT:  To verify the signature outside u-boot, it is vital to not only
+calculate the hash of the image and verify the signature with that, but also to
+calculate the hashes of the kernel, fdt, and ramdisk images and check those
+match the hash values in the corresponding 'hash*' subnodes.
+
+
 Verification
 
 FITs are verified when loaded. After the configuration is selected a list
--
Martin Bonner
martin.bon...@entrust.com

Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system.


Re: [PATCH v4 8/8] rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash

2022-08-03 Thread Simon Glass
On Wed, 3 Aug 2022 at 06:19, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> This new image is similar to u-boot-rockchip.bin except that it's
> destined to be flashed on SPI-NOR flashes.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>
> v3:
>  - added filename property so that idblaoder-spi.img binary is generated
>  by binman, as per community request,
>  - added new temporary files to the list of files to clean up on `make
>  clean`,
>
>  Makefile  |  3 ++-
>  arch/arm/dts/rockchip-u-boot.dtsi | 30 ++
>  2 files changed, 32 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] block: fix blk_get_devnum_by_typename()

2022-08-03 Thread Simon Glass
Hi Heinrich,

On Tue, 2 Aug 2022 at 10:22, Heinrich Schuchardt
 wrote:
>
>
>
> On 8/2/22 14:41, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 2 Aug 2022 at 03:50, Heinrich Schuchardt
> >  wrote:
> >>
> >> Both the 'host' and the 'efiloader' block devices use the same parent
> >> uclass root. Thus the parent uclass is not an indicator the interface type.
> >>
> >> Currently the following fails:
> >>
> >>  setenv efi_selftest block device
> >>  bootefi selftest
> >>  part list efiloader 0
> >>
> >> Struct blk_desc contains the interface type. So we can check it directly
> >> without caring about the parent uclass.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >>   drivers/block/blk-uclass.c | 10 +++---
> >>   1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > We've had this discussion before, but this patch will make it
>
> Yes, you blocked the obvious solution.

Yes, I explained the problem with that at the time.

>
> > difficult to migrate away from IF_TYPE.
>
> My patch does not have any impact on the migration as function
> blk_get_devnum_by_typename() will simply vanish together with IF_TYPE.
>
> Migrating away from IF_TYPE could follow the following path if you
> wanted to keep struct blk_desc:
>
> Just replace devnum by the udevice in struct blk_desc and add the GUI
> representation of the device type (e.g. "mmc") as field to struct blk_ops.
>
> The field devnum only made sense in the world of legacy drivers.
> By the way why do I still find CONFIG_IS_ENABLED(BLK) in block drivers?
>
> A better solution would be to completely do away with struct blk_desc
> and instead always use the udevice.
>
> >
> > Instead we should fix EFI. Having the root as a parent of a block
> > device seems wrong to me. What is the actual device that provides the
> > block device?
>
> There is no actual parent device. In
> lib/efi_selftest/efi_selftest_block_device.c the block device is a RAM
> disk. This is the same situation as with the sandbox host device where
> you have chosen root as the dummy parent for good reason.

Is it a RAM disk on disk, or an in-memory one?

>
> In
> "[1/1] drivers: add memory disk support"
> https://patchwork.ozlabs.org/project/uboot/patch/20220419211641.316935-1-heinrich.schucha...@canonical.com/
> I have proposed a further block device type that has no actual parent.
>
> The idea of using a parent device to match a block device was always a
> dead end. Let's bury it now.

Possibly, but it is how we can drop the IF_TYPE stuff. Let me spend a
bit of time looking at this and see what can be done.

[..]

Regards,
Simon


Re: [PATCH 2/3] binman: Remove header from compressed data

2022-08-03 Thread Simon Glass
Hi Stefan,

On Tue, 2 Aug 2022 at 07:45, Stefan Herbrechtsmeier
 wrote:
>
> Hi Simon,
>
> Am 02.08.2022 um 14:41 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 2 Aug 2022 at 06:29, Stefan Herbrechtsmeier
> >  wrote:
> >>
> >> From: Stefan Herbrechtsmeier 
> >>
> >> Remove header from compressed data because this is uncommon, not
> >> supported by U-Boot and incompatible with external compressed artifacts.
> >>
> >> The header was introduced as part of commit eb0f4a4cb402 ("binman:
> >> Support replacing data in a cbfs") to allow device tree entries to be
> >> larger that the compressed contents. Regarding the commit "this is
> >> necessary to cope with a compressed device tree being updated in such a
> >> way that it shrinks after the entry size is already set (an obscure
> >> case)". This case need to be fixed without influence the compressed data
> >> by itself.
> >
> > I was not able to find a way around this due to the chicken-and egg
> > problem. Compressed data has an unpredictable size and adding an extra
> > uncompressed byte may increase or decrease the compressed size.
>
> Is it possible to use the `pad-after` attribute to record the unused
> space. In this case it is possible to calculate the size of the
> compressed data.

Well if you update that attribute it can change the size of the DTB
which is the chicken-and-egg problem again. As far as I know, if
people set the size of the region to something a bit larger than
needed, the problem is avoided. But the image generation does need to
be deterministic.

>
> Do you have a test for this use case?

There are various ones, e.g. testCompressDtb()

>
> > So my solution was to add the header.
>
> Is the header used outside of binman? I don't spot it in the decompress
> fitImage implementation.

It is used in the Chromium OS verified boot implementation, but not elsewhere.

>
>
> > It is optional though, so can we perhaps have a property in the
> > description to enable it?
>
> Is this header needed and supported outside of binman?
>
> At the moment the header is incompatible and not well documented. It
> took me some time to find out why my gzip compression via binman doesn't
> work as expected because I assume a compatibility between binman
> compress and fitImage decompress.

Yes I understand that, however you can pass a parameter to not include
the size value.

It would also be possible to add a property to the image (top-level
section) that indicates whether this field is present, such property
to apply to the whole image. We could have it default to off, if you
like.

Regards,
Simon


Re: [PATCH v4 7/8] rockchip: allow to build SPI images even without HAS_ROM option

2022-08-03 Thread Simon Glass
On Wed, 3 Aug 2022 at 06:19, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> This prepares for the creation of a u-boot-rockchip-spi.bin image
> similar to u-boot-rockchip.bin to the exception it's destined for
> SPI-NOR flashes instead of MMC storage medium.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/dts/rk3288-u-boot.dtsi | 2 +-
>  arch/arm/dts/rk3399-u-boot.dtsi | 2 +-
>  arch/arm/mach-rockchip/Kconfig  | 6 ++
>  3 files changed, 4 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v4 2/8] binman: allow user-defined filenames for mkimage entry

2022-08-03 Thread Simon Glass
On Wed, 3 Aug 2022 at 06:19, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> mkimage entry currently creates a file whose name is derived from the
> section name containing said entry.
>
> Let's allow the user to define a filename for the mkimage-generated
> binary by using the 'filename' DT property.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>
> v4:
>  - added binman test,
>  - fixed >80 chars-long line,
>
> added in v3
>
>  tools/binman/etype/mkimage.py  |  9 ++--
>  tools/binman/ftest.py  |  6 ++
>  tools/binman/test/235_mkimage_filename.dts | 24 ++
>  3 files changed, 37 insertions(+), 2 deletions(-)
>  create mode 100644 tools/binman/test/235_mkimage_filename.dts

Reviewed-by: Simon Glass 


Re: [PATCH v4 6/8] rockchip: simplify binman image dependencies addition to INPUTS

2022-08-03 Thread Simon Glass
On Wed, 3 Aug 2022 at 06:19, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> By factoring SPL check in the first condition, this makes the checks a
> bit less convoluted and more readable.
>
> Cc: Quentin Schulz 
> Signed-off-by: Quentin Schulz 
> ---
>
> v4:
>  - fixed wrong place for endif for ARM32 boards,
>
>  Makefile | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v4 3/8] rockchip: remove binman temporary files when cleaning

2022-08-03 Thread Simon Glass
On Wed, 3 Aug 2022 at 06:19, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Binman mkimage entry generates temporary files so let's remove them
> when calling `make clean`.
>
> Fixes: 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on jerry")
> Cc: Quentin Schulz 
> Reported-by: Johan Jonker 
> Signed-off-by: Quentin Schulz 
> ---
>
> added in v3
>
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

This is a stop gap. Really we need a way for binman to print out a
list of files it would generate, so we can use that for 'rm'.


Re: GPIO and PINCTRL drivers question

2022-08-03 Thread Simon Glass
Hi Oleh,

On Wed, 3 Aug 2022 at 05:11, Oleh Kravchenko  wrote:
>
> Hi all,
> I'm looking for advice on properly implementing GPIO and PINCTRL drivers.
> My SoC provides the possibility to enable a pull-up/down resistor for 
> specific GPIO.
> And drive strength for GPIO can have four possible states.
>
> The question is, where should I implement this functionality?
>
> I'm confused by dt-bindings/gpio/gpio.h because it has a few macros
> - GPIO_PULL_UP
> - GPIO_PULL_DOWN
>
> Should I keep everything in the pinctrl driver?
> Or should I implement pull-up/down in GPIO driver to support these macros and 
> Drive Strength in pinctrl driver?

IMO the pinctrl should happen in the pinctrl driver. For pull-up/down
you can make your GPIO driver call into the pinctrl driver to make the
change. There are various approaches used in the tree, though.

Regards,
Simon


EFI CI failure

2022-08-03 Thread Simon Glass
Hi Heinrich,

I am seeing this:

https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/477636

_ test_efi_selftest_text_input _
test/py/tests/test_efi_selftest.py:116: in test_efi_selftest_text_input
u_boot_console.restart_uboot()
test/py/u_boot_console_base.py:459: in restart_uboot
self.ensure_spawned(expect_reset)
test/py/u_boot_console_base.py:423: in ensure_spawned
self.wait_for_boot_prompt(loop_num = loop_num)
test/py/u_boot_console_base.py:180: in wait_for_boot_prompt
m = self.p.expect([self.prompt_compiled,
test/py/u_boot_spawn.py:193: in expect
raise Timeout()
E   u_boot_spawn.Timeout
- Captured stdout call -

Do you have any ideas what causes it?

Regards,
Simon


Re: Submitting patches

2022-08-03 Thread Simon Glass
Hi Martin,

On Wed, 3 Aug 2022 at 04:05, Martin Bonner  wrote:
>
> I and my colleagues have a number of patches we would like to
> contribute back to the community, however for various reasons
> (principally operating inside corporate firewalls), it isn't possible
> to use `git send-email`, and I haven't been able to create a plain
> text email which is acceptable to `git am`.

The workaround here is perhaps to create a gmail address for
submissions. I think quite a few people do that. But a firewall that
blocks 'git send-email' is not really compatible with open source
collaboration, so I'd encourage you to get the problem resolved.

>
> Is it possible to fork u-boot on Git[HL][au]b or similar hosting site,
> and then send an email to the list pointing at the commit?

Regards,
Simon


[PATCH v3 2/2] ci: Add a test for a non-LTO build

2022-08-03 Thread Simon Glass
Check that sandbox builds and runs tests OK with LTO disabled.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 .azure-pipelines.yml | 4 
 .gitlab-ci.yml   | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index bc2b437bd99..e542a45dfe0 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -243,6 +243,9 @@ stages:
 sandbox_clang:
   TEST_PY_BD: "sandbox"
   OVERRIDE: "-O clang-13"
+sandbox_nolto:
+  TEST_PY_BD: "sandbox"
+  BUILD_ENV: "NO_LTO=1"
 sandbox_spl:
   TEST_PY_BD: "sandbox_spl"
   TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or test_spl"
@@ -354,6 +357,7 @@ stages:
   export TEST_PY_ID="${TEST_PY_ID}"
   export TEST_PY_TEST_SPEC="${TEST_PY_TEST_SPEC}"
   export OVERRIDE="${OVERRIDE}"
+  export BUILD_ENV="${BUILD_ENV}"
   EOF
   cat << "EOF" >> test.sh
   # the below corresponds to .gitlab-ci.yml "before_script"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f9cd4175079..80b5d29f953 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -33,6 +33,7 @@ stages:
   script:
 # If we've been asked to use clang only do one configuration.
 - export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD}
+- echo BUILD_ENV ${BUILD_ENV}
 - tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W -e
 --board ${TEST_PY_BD} ${OVERRIDE}
 - cp ~/grub_x86.efi $UBOOT_TRAVIS_BUILD_DIR/
@@ -248,6 +249,12 @@ sandbox with clang test.py:
 OVERRIDE: "-O clang-13"
   <<: *buildman_and_testpy_dfn
 
+sandbox without LTO test.py:
+  variables:
+TEST_PY_BD: "sandbox"
+BUILD_ENV: "NO_LTO=1"
+  <<: *buildman_and_testpy_dfn
+
 sandbox_spl test.py:
   variables:
 TEST_PY_BD: "sandbox_spl"
-- 
2.37.1.455.g008518b4e5-goog



[PATCH v3 1/2] Makefile: Allow LTO to be disabled for a build

2022-08-03 Thread Simon Glass
LTO (Link-Time Optimisation) is an very useful feature which can
significantly reduce the size of U-Boot binaries. So far it has been
made available for selected ARM boards and sandbox.

However, incremental builds are much slower when LTO is used. For example,
an incremental build of sandbox takes 2.1 seconds on my machine, but 6.7
seconds with LTO enabled.

Add a NO_LTO parameter to the build, similar to NO_SDL, so it can be
disabled during development if needed, for faster builds.

Add some documentation about LTO while we are here.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Rework to operate like the NO_SDL flag

 Makefile   | 17 -
 arch/arm/config.mk |  4 ++--
 arch/arm/include/asm/global_data.h |  2 +-
 doc/build/gcc.rst  | 17 +
 scripts/Makefile.spl   |  2 +-
 5 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index ff25f929748..348e2130c47 100644
--- a/Makefile
+++ b/Makefile
@@ -643,6 +643,13 @@ export CFLAGS_EFI  # Compiler flags to add when building 
EFI app
 export CFLAGS_NON_EFI  # Compiler flags to remove when building EFI app
 export EFI_TARGET  # binutils target if EFI is natively supported
 
+export LTO_ENABLE
+
+# This is y if LTO is enabled for this build. See NO_LTO=1 to disable LTO
+ifeq ($(NO_LTO),)
+LTO_ENABLE=$(if $(CONFIG_LTO),y)
+endif
+
 # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use
 # that (or fail if absent).  Otherwise, search for a linker script in a
 # standard location.
@@ -702,16 +709,16 @@ endif
 LTO_CFLAGS :=
 LTO_FINAL_LDFLAGS :=
 export LTO_CFLAGS LTO_FINAL_LDFLAGS
-ifdef CONFIG_LTO
+ifeq ($(LTO_ENABLE),y)
ifeq ($(cc-name),clang)
-   LTO_CFLAGS  += -flto
+   LTO_CFLAGS  += -DLTO_ENABLE -flto
LTO_FINAL_LDFLAGS   += -flto
 
AR  = $(shell $(CC) 
-print-prog-name=llvm-ar)
NM  = $(shell $(CC) 
-print-prog-name=llvm-nm)
else
NPROC   := $(shell nproc 2>/dev/null || echo 1)
-   LTO_CFLAGS  += -flto=$(NPROC)
+   LTO_CFLAGS  += -DLTO_ENABLE -flto=$(NPROC)
LTO_FINAL_LDFLAGS   += -fuse-linker-plugin -flto=$(NPROC)
 
# use plugin aware tools
@@ -1760,7 +1767,7 @@ ARCH_POSTLINK := $(wildcard 
$(srctree)/arch/$(ARCH)/Makefile.postlink)
 
 # Generate linker list symbols references to force compiler to not optimize
 # them away when compiling with LTO
-ifdef CONFIG_LTO
+ifeq ($(LTO_ENABLE),y)
 u-boot-keep-syms-lto := keep-syms-lto.o
 u-boot-keep-syms-lto_c := $(patsubst %.o,%.c,$(u-boot-keep-syms-lto))
 
@@ -1782,7 +1789,7 @@ endif
 
 # Rule to link u-boot
 # May be overridden by arch/$(ARCH)/config.mk
-ifdef CONFIG_LTO
+ifeq ($(LTO_ENABLE),y)
 quiet_cmd_u-boot__ ?= LTO $@
   cmd_u-boot__ ?=  
\
$(CC) -nostdlib -nostartfiles   
\
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index b3548ce2439..2065438d053 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -15,11 +15,11 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections 
-fdata-sections \
  -fstack-protector-strong
 CFLAGS_EFI := -fpic -fshort-wchar
 
-ifneq ($(CONFIG_LTO)$(CONFIG_USE_PRIVATE_LIBGCC),yy)
+ifneq ($(LTO_ENABLE)$(CONFIG_USE_PRIVATE_LIBGCC),yy)
 LDFLAGS_FINAL += --gc-sections
 endif
 
-ifndef CONFIG_LTO
+ifneq ($(LTO_ENABLE),y)
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
 endif
 
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 6ee2a767615..cd6112dfcda 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -101,7 +101,7 @@ struct arch_global_data {
 
 #include 
 
-#if defined(__clang__) || defined(CONFIG_LTO)
+#if defined(__clang__) || defined(LTO_ENABLE)
 
 #define DECLARE_GLOBAL_DATA_PTR
 #define gd get_gd()
diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst
index ee544ad87ee..a71f860a487 100644
--- a/doc/build/gcc.rst
+++ b/doc/build/gcc.rst
@@ -152,6 +152,23 @@ of dtc is new enough. It also makes sure that pylibfdt is 
present, if needed
 Note that the :doc:`tools` are always built with the included version of libfdt
 so it is not possible to build U-Boot tools with a system libfdt, at present.
 
+Link-time optimisation (LTO)
+
+
+U-Boot supports link-time optimisation which can reduce the size of the final
+U-Boot binaries, particularly with SPL.
+
+At present this can be enabled by ARM boards by adding `CONFIG_LTO=y` into the
+defconfig file. Other architectures are not supported. LTO is enabled by 
default
+for sandbox.
+
+This does incur a link-time penalty of several seconds. For faster incremental
+buil

[PATCH] Makefile: Correct the rule removing old of-platdata files

2022-08-03 Thread Simon Glass
This makes use of makefile variables that don't exist anymore. Fix it and
also remove the object files in that directory.

Also add FORCE as a dependency as required by the if_changed macro.

Fixes 354d2324635 ("Makefile: Remove old of-platdata files before regenerating")
Reported-by: Heinrich Schuchardt 
Signed-off-by: Simon Glass 
---

 scripts/Makefile.spl | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 1cfb8115e31..3bafeb4fe98 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -358,13 +358,14 @@ $(obj)/dts/dt-%.o: $(obj)/dts/dt-%.c $(platdata-hdr)
$(call if_changed,plat)
 
 # Don't use dts_dir here, since it forces running this expensive rule every 
time
-$(platdata-hdr) $(u-boot-spl-platdata_c) &: $(obj)/$(SPL_BIN).dtb
+$(platdata-hdr) $(u-boot-spl-platdata_c) &: $(obj)/$(SPL_BIN).dtb FORCE
@[ -d $(obj)/dts ] || mkdir -p $(obj)/dts
@# Remove old files since which ones we generate depends on the setting
@# of OF_PLATDATA_INST and this might change between builds. Leaving old
@# ones around is confusing and it is possible that switching the
@# setting again will use the old one instead of regenerating it.
-   @rm -f $(u-boot-spl-all-platdata_c) $(u-boot-spl-all-platdata)
+   @rm -f $(u-boot-spl-old-platdata_c) $(u-boot-spl-platdata_c) \
+   $(u-boot-spl-old-platdata)
$(call if_changed,dtoc)
 
 ifneq ($(CONFIG_ARCH_EXYNOS)$(CONFIG_ARCH_S5PC1XX),)
-- 
2.37.1.455.g008518b4e5-goog



Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Tom Rini
On Wed, Aug 03, 2022 at 07:27:50PM +0200, Heinrich Schuchardt wrote:
> On 8/3/22 18:26, Quentin Schulz wrote:
> > Hi Tom,
> > 
> > On 8/3/22 18:08, Tom Rini wrote:
> > > On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:
> > > 
> > > > Only five boards are left that need to be migrated to DM_GPIO. Set a
> > > > 2023.04 deadline.
> > > > 
> > > > * edminiv2_defconfig
> > > > * mx28evk_auart_console_defconfig
> > > > * mx28evk_nand_defconfig
> > > > * mx28evk_spi_defconfig
> > > > * warp_defconfig
> > > > 
> > > > Signed-off-by: Heinrich Schuchardt 
> > > 
> > > I see you've now ack'd Fabio's patch to remove those mx28 configs.
> > > Here's my patch to remove edminiv2:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/
> > > 
> > > That leaves just "warp", which is missing a ton of conversions, so let
> > > me just post a removal patch instead and see where it goes.
> > > 
> > 
> > I guess this would also mean the removal of GPIO drivers that haven't
> > moved to DM?
> > 
> > # git grep -L UCLASS drivers/gpio/*.c
> > drivers/gpio/adi_gpio2.c
> > drivers/gpio/kona_gpio.c
> > drivers/gpio/kw_gpio.c
> > drivers/gpio/mpc83xx_gpio.c
> > drivers/gpio/mvgpio.c
> > drivers/gpio/pca953x.c
> > drivers/gpio/pca9698.c
> > drivers/gpio/sh_pfc.c
> > drivers/gpio/tca642x.c
> 
> I tried to remove the drivers but that leads to errors in
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13021
> 
> Here are some examples:
> 
> mx6sabreauto
> +make[3]: *** No rule to make target 'drivers/gpio/pca953x.o

This is a slightly trickier case as there's pca953x_gpio.c that is
DM_GPIO, so the question is if we have cases where SPL_DM is off (SPL_DM
is not required) and so the platform cannot switch over to the DM
driver there, but needs to for full U-Boot.  Maybe we need a new symbol,
CONFIG_SPL_PCA953X that depends on !SPL_DM_GPIO.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Tom Rini
On Wed, Aug 03, 2022 at 07:27:50PM +0200, Heinrich Schuchardt wrote:
> On 8/3/22 18:26, Quentin Schulz wrote:
> > Hi Tom,
> > 
> > On 8/3/22 18:08, Tom Rini wrote:
> > > On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:
> > > 
> > > > Only five boards are left that need to be migrated to DM_GPIO. Set a
> > > > 2023.04 deadline.
> > > > 
> > > > * edminiv2_defconfig
> > > > * mx28evk_auart_console_defconfig
> > > > * mx28evk_nand_defconfig
> > > > * mx28evk_spi_defconfig
> > > > * warp_defconfig
> > > > 
> > > > Signed-off-by: Heinrich Schuchardt 
> > > 
> > > I see you've now ack'd Fabio's patch to remove those mx28 configs.
> > > Here's my patch to remove edminiv2:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/
> > > 
> > > That leaves just "warp", which is missing a ton of conversions, so let
> > > me just post a removal patch instead and see where it goes.
> > > 
> > 
> > I guess this would also mean the removal of GPIO drivers that haven't
> > moved to DM?
> > 
> > # git grep -L UCLASS drivers/gpio/*.c
> > drivers/gpio/adi_gpio2.c
> > drivers/gpio/kona_gpio.c
> > drivers/gpio/kw_gpio.c
> > drivers/gpio/mpc83xx_gpio.c
> > drivers/gpio/mvgpio.c
> > drivers/gpio/pca953x.c
> > drivers/gpio/pca9698.c
> > drivers/gpio/sh_pfc.c
> > drivers/gpio/tca642x.c
> 
> I tried to remove the drivers but that leads to errors in
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13021

I did a similar test, but on top of my DM_ETH branch so some platforms
got removed already.  The fatal platform list is:
SBx81LIFKW lschlv2 lsxhl dns325 km_kirkwood km_kirkwood_128m16
km_kirkwood_pci kmcoge5un kmnusa kmsuse2 d2net_v2 net2big_v2
inetspace_v2 netspace_lite_v2 netspace_max_v2 netspace_mini_v2
netspace_v2 omap5_uevm

and I've cc'd the maintainers.  Folks, are you able to pick up and
convert the GPIO driver that your platform relies on to DM_GPIO soon, or
should we just disable the GPIO driver?  Or drop the platform?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Heinrich Schuchardt

On 8/3/22 18:26, Quentin Schulz wrote:

Hi Tom,

On 8/3/22 18:08, Tom Rini wrote:

On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:


Only five boards are left that need to be migrated to DM_GPIO. Set a
2023.04 deadline.

* edminiv2_defconfig
* mx28evk_auart_console_defconfig
* mx28evk_nand_defconfig
* mx28evk_spi_defconfig
* warp_defconfig

Signed-off-by: Heinrich Schuchardt 


I see you've now ack'd Fabio's patch to remove those mx28 configs.
Here's my patch to remove edminiv2:
https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/

That leaves just "warp", which is missing a ton of conversions, so let
me just post a removal patch instead and see where it goes.



I guess this would also mean the removal of GPIO drivers that haven't 
moved to DM?


# git grep -L UCLASS drivers/gpio/*.c
drivers/gpio/adi_gpio2.c
drivers/gpio/kona_gpio.c
drivers/gpio/kw_gpio.c
drivers/gpio/mpc83xx_gpio.c
drivers/gpio/mvgpio.c
drivers/gpio/pca953x.c
drivers/gpio/pca9698.c
drivers/gpio/sh_pfc.c
drivers/gpio/tca642x.c


I tried to remove the drivers but that leads to errors in
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13021

Here are some examples:

mx6sabreauto
+make[3]: *** No rule to make target 'drivers/gpio/pca953x.o

cl-som-imx7
+make[3]: *** No rule to make target 'drivers/gpio/pca953x.o

omap5_uevm
+make[3]: *** No rule to make target 'drivers/gpio/tca642x.o

armadillo-800eva
+make[3]: *** No rule to make target 'drivers/gpio/sh_pfc.o

kzm9g
+make[3]: *** No rule to make target 'drivers/gpio/sh_pfc.o

Dozens of boards have enabled DM_GPIO but the drivers that they use 
still have to be converted. When converting be aware that DM_GPIO does 
not imply SPL_DM_GPIO so these drivers could actually do real work in SPL.


Best regards

Heinrich


?

Cheers,
Quentin




Re: Submitting patches

2022-08-03 Thread Ralph Siemsen
Hi Martin,

On Wed, Aug 3, 2022 at 6:05 AM Martin Bonner  wrote:
>
> I and my colleagues have a number of patches we would like to
> contribute back to the community, however for various reasons
> (principally operating inside corporate firewalls), it isn't possible
> to use `git send-email`, and I haven't been able to create a plain
> text email which is acceptable to `git am`.

It is very common for port 25 to be blocked, however in many cases it
is possible to communicate over port 465 (SSL) or 587 (TLS).

You can do a quick test using netcat or telnet:
$ nc smtp.gmail.com 587
If you are able to connect, then setting up git-send-email is
straightforward; see the example at the end of
https://git-scm.com/docs/git-send-email.

> Is it possible to fork u-boot on Git[HL][au]b or similar hosting site,
> and then send an email to the list pointing at the commit?

I have not used it myself, but git.sr.ht offers such functionality:
https://man.sr.ht/git.sr.ht/#sending-patches-upstream
https://spacepub.space/w/ad258d23-0ac6-488c-83fc-2bacf578de3a

Regards,
Ralph


Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Tom Rini
On Wed, Aug 03, 2022 at 06:26:19PM +0200, Quentin Schulz wrote:
> Hi Tom,
> 
> On 8/3/22 18:08, Tom Rini wrote:
> > On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:
> > 
> > > Only five boards are left that need to be migrated to DM_GPIO. Set a
> > > 2023.04 deadline.
> > > 
> > > * edminiv2_defconfig
> > > * mx28evk_auart_console_defconfig
> > > * mx28evk_nand_defconfig
> > > * mx28evk_spi_defconfig
> > > * warp_defconfig
> > > 
> > > Signed-off-by: Heinrich Schuchardt 
> > 
> > I see you've now ack'd Fabio's patch to remove those mx28 configs.
> > Here's my patch to remove edminiv2:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/
> > 
> > That leaves just "warp", which is missing a ton of conversions, so let
> > me just post a removal patch instead and see where it goes.
> > 
> 
> I guess this would also mean the removal of GPIO drivers that haven't moved
> to DM?
> 
> # git grep -L UCLASS drivers/gpio/*.c
> drivers/gpio/adi_gpio2.c
> drivers/gpio/kona_gpio.c
> drivers/gpio/kw_gpio.c
> drivers/gpio/mpc83xx_gpio.c
> drivers/gpio/mvgpio.c
> drivers/gpio/pca953x.c
> drivers/gpio/pca9698.c
> drivers/gpio/sh_pfc.c
> drivers/gpio/tca642x.c

Probably?  Let me run a one-off in CI to see what all breaks with those
removed.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Quentin Schulz

Hi Tom,

On 8/3/22 18:08, Tom Rini wrote:

On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:


Only five boards are left that need to be migrated to DM_GPIO. Set a
2023.04 deadline.

* edminiv2_defconfig
* mx28evk_auart_console_defconfig
* mx28evk_nand_defconfig
* mx28evk_spi_defconfig
* warp_defconfig

Signed-off-by: Heinrich Schuchardt 


I see you've now ack'd Fabio's patch to remove those mx28 configs.
Here's my patch to remove edminiv2:
https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/

That leaves just "warp", which is missing a ton of conversions, so let
me just post a removal patch instead and see where it goes.



I guess this would also mean the removal of GPIO drivers that haven't 
moved to DM?


# git grep -L UCLASS drivers/gpio/*.c
drivers/gpio/adi_gpio2.c
drivers/gpio/kona_gpio.c
drivers/gpio/kw_gpio.c
drivers/gpio/mpc83xx_gpio.c
drivers/gpio/mvgpio.c
drivers/gpio/pca953x.c
drivers/gpio/pca9698.c
drivers/gpio/sh_pfc.c
drivers/gpio/tca642x.c
?

Cheers,
Quentin


Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

2022-08-03 Thread Tom Rini
On Wed, Aug 03, 2022 at 06:00:13PM +0200, Pali Rohár wrote:
> On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> > On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> > 
> > > Hello Tom!
> > > 
> > > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> > 
> > I thought I had managed to mirror the TPL/SPL/full usage that was there
> > prior, but apparently some got missed.
> 
> Yea, conversion to Kconfig seems that was incorrect.

As the config files were just unclear, but you seem to understand what
it's supposed to be, a patch to clean it up would be most appreciated,
thanks.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] arm: Remove warp board

2022-08-03 Thread Tom Rini
This board is missing migration to CONFIG_DM, which had a deadline of
v2020.01, which is now more than 2 years passed due.  Remove it.

Cc: Otavio Salvador 
Signed-off-by: Tom Rini 
---
 arch/arm/mach-imx/mx6/Kconfig |   6 -
 board/warp/Kconfig|  12 --
 board/warp/MAINTAINERS|   6 -
 board/warp/Makefile   |   6 -
 board/warp/README |  56 
 board/warp/imximage.cfg   | 122 --
 board/warp/warp.c | 236 --
 configs/warp_defconfig|  52 
 include/configs/warp.h| 112 
 9 files changed, 608 deletions(-)
 delete mode 100644 board/warp/Kconfig
 delete mode 100644 board/warp/MAINTAINERS
 delete mode 100644 board/warp/Makefile
 delete mode 100644 board/warp/README
 delete mode 100644 board/warp/imximage.cfg
 delete mode 100644 board/warp/warp.c
 delete mode 100644 configs/warp_defconfig
 delete mode 100644 include/configs/warp.h

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index eceb730856f2..ec560fe25703 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -640,11 +640,6 @@ config TARGET_WANDBOARD
select BOARD_LATE_INIT
select SUPPORT_SPL
 
-config TARGET_WARP
-   bool "WaRP"
-   depends on MX6SL
-   select BOARD_LATE_INIT
-
 config TARGET_BRPPT2
bool "brppt2"
depends on MX6QDL
@@ -724,7 +719,6 @@ source "board/k+p/kp_imx6q_tpc/Kconfig"
 source "board/udoo/Kconfig"
 source "board/udoo/neo/Kconfig"
 source "board/wandboard/Kconfig"
-source "board/warp/Kconfig"
 source "board/BuR/brppt2/Kconfig"
 source "board/out4/o4-imx6ull-nano/Kconfig"
 
diff --git a/board/warp/Kconfig b/board/warp/Kconfig
deleted file mode 100644
index 9c2fc9df67ee..
--- a/board/warp/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_WARP
-
-config SYS_BOARD
-   default "warp"
-
-config SYS_CONFIG_NAME
-   default "warp"
-
-config IMX_CONFIG
-   default "board/warp/imximage.cfg"
-
-endif
diff --git a/board/warp/MAINTAINERS b/board/warp/MAINTAINERS
deleted file mode 100644
index ee2114d08235..
--- a/board/warp/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-WaRP BOARD
-M: Otavio Salvador 
-S: Maintained
-F: board/warp/
-F: include/configs/warp.h
-F: configs/warp_defconfig
diff --git a/board/warp/Makefile b/board/warp/Makefile
deleted file mode 100644
index 3a2373d7bf5b..
--- a/board/warp/Makefile
+++ /dev/null
@@ -1,6 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-# Copyright (C) 2014 O.S. Systems Software LTDA.
-# Copyright (C) 2014 Kynetics LLC.
-# Copyright (C) 2014 Revolution Robotics, Inc.
-
-obj-y  := warp.o
diff --git a/board/warp/README b/board/warp/README
deleted file mode 100644
index 3cfd22ec761d..
--- a/board/warp/README
+++ /dev/null
@@ -1,56 +0,0 @@
-How to Update U-Boot on Warp board
---
-
-Required software on the host PC:
-
-- imx_usb_loader: https://github.com/boundarydevices/imx_usb_loader
-
-- dfu-util: http://dfu-util.sourceforge.net/releases/
-
-Build U-Boot for Warp:
-
-$ make mrproper
-$ make warp_config
-$ make
-
-This will generate the U-Boot binary called u-boot.imx.
-
-Put warp board in USB download mode
-
-Connect a USB to serial adapter between the host PC and warp
-
-Connect a USB cable between the OTG warp port and the host PC
-
-Open a terminal program such as minicom
-
-Copy u-boot.imx to the imx_usb_loader folder.
-
-Load u-boot.imx via USB:
-
-$ sudo ./imx_usb u-boot.imx
-
-Then U-Boot should start and its messages will appear in the console program.
-
-Use the default environment variables:
-
-=> env default -f -a
-=> saveenv
-
-Run the DFU command:
-=> dfu 0 mmc 0
-
-Transfer u-boot.imx that will be flashed into the eMMC:
-
-$ sudo dfu-util -D u-boot.imx -a boot
-
-Then on the U-Boot prompt the following message should be seen after a
-successful upgrade:
-
-#DOWNLOAD ... OK
-Ctrl+C to exit ...
-
-Remove power from the warp board.
-
-Put warp board into normal boot mode
-
-Power up the board and the new updated U-Boot should boot from eMMC
diff --git a/board/warp/imximage.cfg b/board/warp/imximage.cfg
deleted file mode 100644
index f6bc604c8b22..
--- a/board/warp/imximage.cfg
+++ /dev/null
@@ -1,122 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- * Refer doc/imx/mkimage/imximage.txt for more details about how-to configure
- * and create imximage boot image
- *
- * The syntax is taken as close as possible with the kwbimage
- */
-#include 
-
-/* image version */
-
-IMAGE_VERSION 2
-
-/*
- * Boot Device : one of
- * spi, sd (the board has no nand neither onenand)
- */
-
-BOOT_FROM  sd
-
-/*
- * Secure boot support
- */
-#ifdef CONFIG_IMX_HAB
-CSF CONFIG_CSF_SIZE
-#endif
-
-/*
- * Device Configuration Data (DCD)
- *
- * Each entry must have the format:
- * Addr-type   Address

Re: [PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Tom Rini
On Wed, Aug 03, 2022 at 04:39:52PM +0200, Heinrich Schuchardt wrote:

> Only five boards are left that need to be migrated to DM_GPIO. Set a
> 2023.04 deadline.
> 
> * edminiv2_defconfig
> * mx28evk_auart_console_defconfig
> * mx28evk_nand_defconfig
> * mx28evk_spi_defconfig
> * warp_defconfig
> 
> Signed-off-by: Heinrich Schuchardt 

I see you've now ack'd Fabio's patch to remove those mx28 configs.
Here's my patch to remove edminiv2:
https://patchwork.ozlabs.org/project/uboot/patch/20220802113424.2988464-6-tr...@konsulko.com/

That leaves just "warp", which is missing a ton of conversions, so let
me just post a removal patch instead and see where it goes.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] mx28evk: Remove AUART/NAND/SPI variants

2022-08-03 Thread Heinrich Schuchardt

On 8/3/22 04:04, Fabio Estevam wrote:

From: Fabio Estevam 

To ease maintenance, let's keep only the main mx28evk_defconfig
and remove the other variants that have not been migrated to DM.

Signed-off-by: Fabio Estevam 
---
  board/freescale/mx28evk/MAINTAINERS |  3 --
  configs/mx28evk_auart_console_defconfig | 59 ---
  configs/mx28evk_nand_defconfig  | 62 -
  configs/mx28evk_spi_defconfig   | 57 ---
  4 files changed, 181 deletions(-)
  delete mode 100644 configs/mx28evk_auart_console_defconfig
  delete mode 100644 configs/mx28evk_nand_defconfig >   delete mode 100644 
configs/mx28evk_spi_defconfig


Acked-by: Heinrich Schuchardt 



Re: Broken commit de47ff536363289f92f85ed1e4901724d238432d

2022-08-03 Thread Pali Rohár
On Tuesday 02 August 2022 06:58:26 Tom Rini wrote:
> On Tue, Aug 02, 2022 at 11:13:38AM +0200, Pali Rohár wrote:
> 
> > Hello Tom!
> > 
> > Your commit de47ff536363289f92f85ed1e4901724d238432d ("Convert
> > CONFIG_SYS_MPC85XX_NO_RESETVEC to Kconfig") seems to be broken.
> 
> I thought I had managed to mirror the TPL/SPL/full usage that was there
> prior, but apparently some got missed.
> 
> -- 
> Tom

Yea, conversion to Kconfig seems that was incorrect.


Re: [PATCH 1/1] doc: man-page for gpio command

2022-08-03 Thread Fabio Estevam
Hi Heinrich,

On Wed, Aug 3, 2022 at 11:31 AM Heinrich Schuchardt
 wrote:

> Fabio Estevam
> * mx28evk_nand_defconfig
> * mx28evk_auart_console_defconfig
> * mx28evk_spi_defconfig

I have sent a patch removing these defconfigs:
https://lore.kernel.org/u-boot/20220803020404.4156197-1-feste...@gmail.com/T/#u

Thanks


Re: [PATCH] gpio: aspeed: port Linux dt-bindings header file

2022-08-03 Thread Billy Tsai
Hello,

On 2022/8/3, 10:10 AM, "Billy Tsai"  wrote:

Reviewed-by: Billy Tsai 

On 2022/8/3, 9:46 AM, "ChiaWei Wang"  wrote:

Acked-by: Chia-Wei Wang 

> > From: Dhananjay Phadke 
> > Sent: Wednesday, August 3, 2022 4:55 AM
> > 
> > Ported as is, makes it easier to add readable GPIO definitions in 
DTS files.
> > 
> > Signed-off-by: Dhananjay Phadke 
> > ---
> >  include/dt-bindings/gpio/aspeed-gpio.h | 49 
++
> >  1 file changed, 49 insertions(+)
> >  create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
> > 
> > diff --git a/include/dt-bindings/gpio/aspeed-gpio.h
> > b/include/dt-bindings/gpio/aspeed-gpio.h
> > new file mode 100644
> > index 00..56fc4889b2
> > --- /dev/null
> > +++ b/include/dt-bindings/gpio/aspeed-gpio.h
> > @@ -0,0 +1,49 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * This header provides constants for binding aspeed,*-gpio.
> > + *
> > + * The first cell in Aspeed's GPIO specifier is the GPIO ID. The 
macros
> > +below
> > + * provide names for this.
> > + *
> > + * The second cell contains standard flag values specified in 
gpio.h.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_GPIO_ASPEED_GPIO_H #define
> > +_DT_BINDINGS_GPIO_ASPEED_GPIO_H
> > +
> > +#include 
> > +
> > +#define ASPEED_GPIO_PORT_A 0
> > +#define ASPEED_GPIO_PORT_B 1
> > +#define ASPEED_GPIO_PORT_C 2
> > +#define ASPEED_GPIO_PORT_D 3
> > +#define ASPEED_GPIO_PORT_E 4
> > +#define ASPEED_GPIO_PORT_F 5
> > +#define ASPEED_GPIO_PORT_G 6
> > +#define ASPEED_GPIO_PORT_H 7
> > +#define ASPEED_GPIO_PORT_I 8
> > +#define ASPEED_GPIO_PORT_J 9
> > +#define ASPEED_GPIO_PORT_K 10
> > +#define ASPEED_GPIO_PORT_L 11
> > +#define ASPEED_GPIO_PORT_M 12
> > +#define ASPEED_GPIO_PORT_N 13
> > +#define ASPEED_GPIO_PORT_O 14
> > +#define ASPEED_GPIO_PORT_P 15
> > +#define ASPEED_GPIO_PORT_Q 16
> > +#define ASPEED_GPIO_PORT_R 17
> > +#define ASPEED_GPIO_PORT_S 18
> > +#define ASPEED_GPIO_PORT_T 19
> > +#define ASPEED_GPIO_PORT_U 20
> > +#define ASPEED_GPIO_PORT_V 21
> > +#define ASPEED_GPIO_PORT_W 22
> > +#define ASPEED_GPIO_PORT_X 23
> > +#define ASPEED_GPIO_PORT_Y 24
> > +#define ASPEED_GPIO_PORT_Z 25
> > +#define ASPEED_GPIO_PORT_AA 26
> > +#define ASPEED_GPIO_PORT_AB 27
> > +#define ASPEED_GPIO_PORT_AC 28
> > +
> > +#define ASPEED_GPIO(port, offset) \
> > +   ((ASPEED_GPIO_PORT_##port * 8) + offset)
Please help to fix the check patch warning.
"Macro argument 'offset' may be better as '(offset)' to avoid precedence issues"
((ASPEED_GPIO_PORT_##port * 8) + (offset))
> > +
> > +#endif
> > --
> > 2.25.1



[PATCH 1/1] Migration: set deadline for move to DM_GPIO

2022-08-03 Thread Heinrich Schuchardt
Only five boards are left that need to be migrated to DM_GPIO. Set a
2023.04 deadline.

* edminiv2_defconfig
* mx28evk_auart_console_defconfig
* mx28evk_nand_defconfig
* mx28evk_spi_defconfig
* warp_defconfig

Signed-off-by: Heinrich Schuchardt 
---
 Makefile   | 1 +
 doc/develop/driver-model/migration.rst | 8 
 2 files changed, 9 insertions(+)

diff --git a/Makefile b/Makefile
index d76ec69b52..f17c0c9bd3 100644
--- a/Makefile
+++ b/Makefile
@@ -1146,6 +1146,7 @@ endif
$(call deprecated,CONFIG_WDT,DM watchdog,v2019.10,\
$(CONFIG_WATCHDOG)$(CONFIG_HW_WATCHDOG))
$(call deprecated,CONFIG_DM_ETH,Ethernet drivers,v2020.07,$(CONFIG_NET))
+   $(call deprecated,CONFIG_DM_GPIO,GPIO drivers,v2023.04,$(CONFIG_GPIO))
$(call deprecated,CONFIG_DM_I2C,I2C 
drivers,v2022.04,$(CONFIG_SYS_I2C_LEGACY))
$(call deprecated,CONFIG_DM_KEYBOARD,Keyboard 
drivers,v2022.10,$(CONFIG_KEYBOARD))
@# CONFIG_SYS_TIMER_RATE has brackets in it for some boards which
diff --git a/doc/develop/driver-model/migration.rst 
b/doc/develop/driver-model/migration.rst
index 5a60436925..0c0cb3cec0 100644
--- a/doc/develop/driver-model/migration.rst
+++ b/doc/develop/driver-model/migration.rst
@@ -126,3 +126,11 @@ Deadline: 2023.04
 The serial subsystem has supported the driver model since late 2014.
 Maintainers should submit patches switching over to using CONFIG_DM_SERIAL and
 other base driver model options in time for inclusion in the 2022.10 release.
+
+CONFIG_DM_GPIO
+--
+* Deadline: 2023.04
+
+The subsystem itself has been converted and maintainers should submit patches
+switching over to using CONFIG_DM_GPIO and other base driver model options in
+time for inclusion in the 2023.04 rerelease.
-- 
2.36.1



Re: [PATCH 1/1] doc: man-page for gpio command

2022-08-03 Thread Heinrich Schuchardt

On 8/3/22 13:56, Quentin Schulz wrote:

Hi Heinrich,

On 8/3/22 13:21, Heinrich Schuchardt wrote:

On 8/3/22 11:59, Quentin Schulz wrote:

Hi Heinrich,

On 8/2/22 14:28, Heinrich Schuchardt wrote:

Provide a man-page for the gpio command.

Signed-off-by: Heinrich Schuchardt 
---
  doc/usage/cmd/gpio.rst | 90 
++

  doc/usage/index.rst    |  1 +
  2 files changed, 91 insertions(+)
  create mode 100644 doc/usage/cmd/gpio.rst

diff --git a/doc/usage/cmd/gpio.rst b/doc/usage/cmd/gpio.rst
new file mode 100644
index 00..f6a5668388
--- /dev/null
+++ b/doc/usage/cmd/gpio.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+gpio command
+
+
+Synopsis
+
+
+::
+
+    gpio  
+    gpio read  
+    gpio status [-a] [|]
+
+The gpio command is used to access General Purpose Inputs/Outputs.
+
+gpio input
+--
+
+Switch the GPIO *pin* to input mode.
+
+gpio set
+
+
+Switch the GPIO *pin* to output mode and set the signal to 1.
+


I think this is supposed to follow the 
GPIOD_ACTIVE_LOW/GPIOD_ACTIVE_HIGH flag. So I think it's better to 
say "set the state to active"? Maybe add a few words on this active 
high/low thing to explicit that using gpio set does not necessarily 
mean that the GPIO output will have some voltage.


There is no string GPIOD_ACTIVE_HIGH in U-Boot.

include/asm-generic/gpio.h:124:
#define GPIOD_ACTIVE_LOW BIT(3)
/* GPIO is active when value is low */

The gpio command lacks the capability to set active high or active 
low. It is not even displayed.


The function description of dm_gpio_get_value() documents the return 
value as 0 for inactive, 1 for active.


The function description of gpio_get_value() documents its return 
value as 0 for low or 1 for high.


The uclass implements gpio_get_value() by calling dm_gpio_get_value() 
without inverting the value.


One of both functions is incorrectly documented!

dm_gpio_get_value() calls _gpio_get_value() which calls the driver's 
get_value() function and inverts the value if GPIOD_ACTIVE_LOW is set.


The structure struct dm_gpio_ops lacks any documentation of the 
meaning of the return value.




Considering that _gpio_get_value does the inversion if the 
GPIOD_ACTIVE_LOW flag is set, the expected return value of 
dm_gpio_ops->get_value should be the raw value of the pin as returned by 
the SoC. Not documented, yes, but the meaning is clear to me.



To sum it up:

The function documentation is a mess and leaves it unclear what a value
of 0 or 1 in the gpio command means.



It is clear for DM, not for non-DM.

The first thing to do is to get the documentation of struct 
dm_gpio_ops updated. Next ensure that all drivers implement it this way.




Agreed.

We still ave the issue with values returned by non-DM drivers, but 
should we care? The drivers should be moved to DM_GPIO?


Once the yet to find maintainer of GPIO has done this we can revisit 
the documentation.




Indeed.

I thought DM-only GPIO subsystem was on the map, like all subsystems, 
but I cannot find it on 
https://u-boot.readthedocs.io/en/latest/develop/driver-model/migration.html. Otherwise, the move to DM-only for GPIO should also help us in having a properly defined expectation of what the gpio command should return, since the DM version of gpio commands is handling active state. I'd have been inclined to say we shouldn't care too much about non-DM GPIO drivers since they'll disappear some day, are deprecated (as per documentation in header file) and if they get updated they should follow the yet-to-be-written in-file documentation, but I'm not too sure since DM_GPIO is not on the map of driver model migration at the moment?





+gpio clear
+--
+
+Switch the GPIO *pin* to output mode and set the signal to 0.
+


Ditto.


+gpio toggle
+---
+
+Switch the GPIO *pin* to output mode and reverse the signal state.
+
+gpio read
+-
+
+Read the signal state of the GPIO *pin* and save it in environment 
variable

+*name*.
+
+gpio status
+---
+
+Display the status of one or multiple GPIOs. By default only 
claimed GPIOs

+are displayed.
+
+-a
+    Display GPIOs irrespective of being claimed.
+
+bank
+    Name of a bank of GPIOs to be displayed.
+
+pin
+    Name of a single GPIO to be displayed or manipulated.
+
+Examples
+
+
+Switch the status of a GPIO::
+
+    => gpio set a5
+    gpio: pin a5 (gpio 133) value is 1


and I guess we should maybe patch the gpio cmd to say here "high" 
instead of "1"?


For an active low GPIO value 1 might mean low.

It would be helpful to provide a way to display if a GPIO is active 
high or active low. But this patch is about documenting the existing 
functionality.




Agreed, it was a suggestion on how to improve the gpio command output 
(in another patch obviously).


Though, this thread sadly highlighted that the gpio command returns 
something that cannot be trusted by the user without digging into the 
driver/datasheet (at 

Re: [PATCH 20/21] smdkc100: Remove legacy non-DM_ETH code

2022-08-03 Thread Minkyu Kang
Hi,

On Tue, 2 Aug 2022 at 20:39, Tom Rini  wrote:

> Now that we are about to enable DM_ETH by default, remove legacy code.
>
> Cc: Minkyu Kang 
> Signed-off-by: Tom Rini 
> ---
>  board/samsung/smdkc100/smdkc100.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/board/samsung/smdkc100/smdkc100.c
> b/board/samsung/smdkc100/smdkc100.c
> index 69ed715403fb..b944e44c1ac4 100644
> --- a/board/samsung/smdkc100/smdkc100.c
> +++ b/board/samsung/smdkc100/smdkc100.c
> @@ -69,12 +69,3 @@ int checkboard(void)
> return 0;
>  }
>  #endif
> -
> -int board_eth_init(struct bd_info *bis)
> -{
> -   int rc = 0;
> -#ifdef CONFIG_SMC911X
> -   rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
> -#endif
> -   return rc;
> -}
> --
> 2.25.1
>
>
Reviewed-by: Minkyu Kang 

-- 
Thanks,
Minkyu Kang.


Re: imx8mn eMMC boot partition

2022-08-03 Thread Heiko Thiery
HI Michael,

Am Mi., 3. Aug. 2022 um 15:02 Uhr schrieb Michael Nazzareno Trimarchi
:
>
> Hi Heiko
>
> On Wed, Aug 3, 2022 at 2:51 PM Heiko Thiery  wrote:
> >
> > Hi Michael,
> >
> > Am Mi., 3. Aug. 2022 um 14:40 Uhr schrieb Michael Nazzareno Trimarchi
> > :
> > >
> > > Hi
> > >
> > > On Wed, Aug 3, 2022 at 2:19 PM Heiko Thiery  
> > > wrote:
> > > >
> > > > Hi,What is not clear to be if 0x40 can be used as
> > > >
> > > > Does anyone have an idea where to find the definition of the offset
> > > > used when booting from eMMCs boot partition?
> > > >
> > > > I tried to write the flash.bin image to offset 32k (page 0x40) into
> > > > the boot partition of the eMMC and seledted the bootpartition with
> > > > "mmc partconfig 2 0 1 0". The board did not start. After writing the
> > > > flash.bin to offset 0 the board starts.
> > > >
> > > > When writing to microSD the offset 32k is ok.
> > > >
> > > > I' using an NXP imx8mn evk board.
> > > >
> > >
> > > Yes I'm flashing bootpartion 0 and boot partition 1 at offset 0x00
> >
> > Thanks for the confirmation. I was pretty sure it was different on an
> > imx8mq board. I thought I used the same offset there as on the
> > microSD.
> >
> > --
> > Heiko
>
> 6.1.6.3 Primary image offset and IVT offset
>
> emmc: 0, if the image is in boot partition and 32K if it is in user
> partition

Thanks a lot!

>
> Michael


Re: [PATCH v1 08/26] imx6ul/imx6ull: synchronise device trees with linux

2022-08-03 Thread Frieder Schrempf
Hi Marcel, hi Stefano,

Am 03.08.22 um 15:02 schrieb Stefano Babic:
> On 03.08.22 14:58, Marcel Ziswiler wrote:
>> Hi Frieder
>>
>> On Mon, 2022-08-01 at 10:08 +0200, Frieder Schrempf wrote:
>>> Hi Marcel,
>>>
>>> Am 21.07.22 um 15:27 schrieb Marcel Ziswiler:
 From: Marcel Ziswiler 

 Synchronise device trees with linux v5.19-rc5.

 Signed-off-by: Marcel Ziswiler 
>>>
>>> Thanks for the sync patches!
>>>
>>> Unfortunately this will break the Kontron SL/BL i.MX6UL/ULL boards
>>> (N6x1x). The reason is that the U-Boot devicetrees received some
>>> simplification and renaming that haven't been upstreamed to the kernel,
>>> yet. I will add updating the kernel DTs to my to-do list and would
>>> recommend to drop the Kontron DT changes from this patch for now.
>>
>> Sorry about that. I did not expect Stefano to apply all of this that
>> quickly. On the other hand we can be very
>> grateful that he reacted that promptly this time around (;-p).
>>
> 
> :-D
> 
>> Anyway, please let me know if I can be of service to correct any of
>> this. Like I wrote in [1] I plan to re-sync
>> again and fix a few review comments once 6.0-rc1 is out. I guess I
>> could also include a fix (or revert) by that
>> time.
> 
> I think it is a good plan.

As for the Kontron SL/BL i.MX6UL/ULL boards the U-Boot DTs are more
up-to-date than the kernel ones, it would be good if you, Marcel, could
just revert the changes in the next round of patches and exclude the
boards from your sync with 6.0-rc1 as any changes to the kernel DTs I
will eventually come up with will land in 6.1 at the earliest.

Thanks
Frieder


Re: [PATCH 1/3] gpio: Allow to print pin's label even for pin with GPIOF_FUNC function

2022-08-03 Thread Patrice CHOTARD
Hi Simon

On 8/2/22 14:41, Simon Glass wrote:
> On Tue, 2 Aug 2022 at 03:09, Patrice Chotard
>  wrote:
>>
>> Currently, if pin's function is GPIOF_FUNC, only "func" if displayed
>> without any other information. It would be interesting, if information is
>> available, to indicate which pinmuxing's name is used.
>>
>> For example, for STM32 SoC's based platform, "gpio status" command
>> output :
>>
>>before
>> Bank GPIOZ:
>>   GPIOZ0: unused : 0 [ ]
>>   GPIOZ1: unused : 0 [ ]
>>   GPIOZ2: unused : 0 [ ]
>>   GPIOZ3: unused : 0 [ ]
>>   GPIOZ4: func
>>   GPIOZ5: func
>>   GPIOZ6: unused : 0 [ ]
>>   GPIOZ7: unused : 0 [ ]
>>   GPIOZ8: unknown
>>   GPIOZ9: unknown
>>   GPIOZ10: unknown
>>   GPIOZ11: unknown
>>   GPIOZ12: unknown
>>   GPIOZ13: unknown
>>   GPIOZ14: unknown
>>   GPIOZ15: unknown
>>
>>After
>> Bank GPIOZ:
>>   GPIOZ0: unused : 0 [ ]
>>   GPIOZ1: unused : 0 [ ]
>>   GPIOZ2: unused : 0 [ ]
>>   GPIOZ3: unused : 0 [ ]
>>   GPIOZ4: func i2c4-0
>>   GPIOZ5: func i2c4-0
>>   GPIOZ6: unused : 0 [ ]
>>   GPIOZ7: unused : 0 [ ]
>>   GPIOZ8: unknown
>>   GPIOZ9: unknown
>>   GPIOZ10: unknown
>>   GPIOZ11: unknown
>>   GPIOZ12: unknown
>>   GPIOZ13: unknown
>>   GPIOZ14: unknown
>>   GPIOZ15: unknown
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>>  drivers/gpio/gpio-uclass.c | 16 +++-
>>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> Do you think you could create a basic test for the gpio command? See
> test/dm/acpi.c for an example.

OK i will send a v2 with a test

Thanks
Patrice

> 
> Regards,
> Simon


Re: [PATCH 0/3] gpio: update gpio_get_status()

2022-08-03 Thread Patrice CHOTARD
Hi Heinrich

On 8/2/22 16:56, Heinrich Schuchardt wrote:
> On 8/2/22 11:09, Patrice Chotard wrote:
>>
>> Currently, if pin's function is GPIOF_FUNC, only "func" if displayed
>> without any other information. It would be interesting, if information is
>> available, to indicate which pinmuxing's name is used.
> 
> Maybe you can add on top of my gpio man-page patch a description of the
> output fields of gpio status.
> 
> [PATCH 1/1] doc: man-page for gpio command
> https://lists.denx.de/pipermail/u-boot/2022-August/490666.html

Yes for sure, thanks for the link

Patrice

> 
> Best regards
> 
> Heinrich
> 
>>
>>
>> Patrice Chotard (3):
>>    gpio: Allow to print pin's label even for pin with GPIOF_FUNC function
>>    gpio: Fix pin's status display for pin with GPIOF_UNUSED function
>>    pinctrl: pinctrl_stm32: Populate uc_priv->name[] with pinmux node's
>>  name
>>
>>   drivers/gpio/gpio-uclass.c  | 18 --
>>   drivers/pinctrl/pinctrl_stm32.c |  8 ++--
>>   2 files changed, 18 insertions(+), 8 deletions(-)
>>
> 


Re: imx8mn eMMC boot partition

2022-08-03 Thread Michael Nazzareno Trimarchi
Hi Heiko

On Wed, Aug 3, 2022 at 2:51 PM Heiko Thiery  wrote:
>
> Hi Michael,
>
> Am Mi., 3. Aug. 2022 um 14:40 Uhr schrieb Michael Nazzareno Trimarchi
> :
> >
> > Hi
> >
> > On Wed, Aug 3, 2022 at 2:19 PM Heiko Thiery  wrote:
> > >
> > > Hi,What is not clear to be if 0x40 can be used as
> > >
> > > Does anyone have an idea where to find the definition of the offset
> > > used when booting from eMMCs boot partition?
> > >
> > > I tried to write the flash.bin image to offset 32k (page 0x40) into
> > > the boot partition of the eMMC and seledted the bootpartition with
> > > "mmc partconfig 2 0 1 0". The board did not start. After writing the
> > > flash.bin to offset 0 the board starts.
> > >
> > > When writing to microSD the offset 32k is ok.
> > >
> > > I' using an NXP imx8mn evk board.
> > >
> >
> > Yes I'm flashing bootpartion 0 and boot partition 1 at offset 0x00
>
> Thanks for the confirmation. I was pretty sure it was different on an
> imx8mq board. I thought I used the same offset there as on the
> microSD.
>
> --
> Heiko

6.1.6.3 Primary image offset and IVT offset

emmc: 0, if the image is in boot partition and 32K if it is in user
partition

Michael


Re: [PATCH v1 08/26] imx6ul/imx6ull: synchronise device trees with linux

2022-08-03 Thread Stefano Babic

On 03.08.22 14:58, Marcel Ziswiler wrote:

Hi Frieder

On Mon, 2022-08-01 at 10:08 +0200, Frieder Schrempf wrote:

Hi Marcel,

Am 21.07.22 um 15:27 schrieb Marcel Ziswiler:

From: Marcel Ziswiler 

Synchronise device trees with linux v5.19-rc5.

Signed-off-by: Marcel Ziswiler 


Thanks for the sync patches!

Unfortunately this will break the Kontron SL/BL i.MX6UL/ULL boards
(N6x1x). The reason is that the U-Boot devicetrees received some
simplification and renaming that haven't been upstreamed to the kernel,
yet. I will add updating the kernel DTs to my to-do list and would
recommend to drop the Kontron DT changes from this patch for now.


Sorry about that. I did not expect Stefano to apply all of this that quickly. 
On the other hand we can be very
grateful that he reacted that promptly this time around (;-p).



:-D


Anyway, please let me know if I can be of service to correct any of this. Like 
I wrote in [1] I plan to re-sync
again and fix a few review comments once 6.0-rc1 is out. I guess I could also 
include a fix (or revert) by that
time.


I think it is a good plan.


Stefano



[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20220721132748.1052244-4-mar...@ziswiler.com/#2943543


Thanks
Frieder


Cheers

Marcel



--
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


Re: imx8mn eMMC boot partition

2022-08-03 Thread Heiko Thiery
Hi Michael,

Am Mi., 3. Aug. 2022 um 14:40 Uhr schrieb Michael Nazzareno Trimarchi
:
>
> Hi
>
> On Wed, Aug 3, 2022 at 2:19 PM Heiko Thiery  wrote:
> >
> > Hi,
> >
> > Does anyone have an idea where to find the definition of the offset
> > used when booting from eMMCs boot partition?
> >
> > I tried to write the flash.bin image to offset 32k (page 0x40) into
> > the boot partition of the eMMC and seledted the bootpartition with
> > "mmc partconfig 2 0 1 0". The board did not start. After writing the
> > flash.bin to offset 0 the board starts.
> >
> > When writing to microSD the offset 32k is ok.
> >
> > I' using an NXP imx8mn evk board.
> >
>
> Yes I'm flashing bootpartion 0 and boot partition 1 at offset 0x00

Thanks for the confirmation. I was pretty sure it was different on an
imx8mq board. I thought I used the same offset there as on the
microSD.

--
Heiko


Re: imx8mn eMMC boot partition

2022-08-03 Thread Michael Nazzareno Trimarchi
Hi

On Wed, Aug 3, 2022 at 2:19 PM Heiko Thiery  wrote:
>
> Hi,
>
> Does anyone have an idea where to find the definition of the offset
> used when booting from eMMCs boot partition?
>
> I tried to write the flash.bin image to offset 32k (page 0x40) into
> the boot partition of the eMMC and seledted the bootpartition with
> "mmc partconfig 2 0 1 0". The board did not start. After writing the
> flash.bin to offset 0 the board starts.
>
> When writing to microSD the offset 32k is ok.
>
> I' using an NXP imx8mn evk board.
>

Yes I'm flashing bootpartion 0 and boot partition 1 at offset 0x00

Michael


> --
> Heiko



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


[PATCH v4 8/8] rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

This new image is similar to u-boot-rockchip.bin except that it's
destined to be flashed on SPI-NOR flashes.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

v3:
 - added filename property so that idblaoder-spi.img binary is generated
 by binman, as per community request,
 - added new temporary files to the list of files to clean up on `make
 clean`,

 Makefile  |  3 ++-
 arch/arm/dts/rockchip-u-boot.dtsi | 30 ++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 5fb470b0d8..eb8006ec18 100644
--- a/Makefile
+++ b/Makefile
@@ -2192,7 +2192,8 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h 
\
   idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
   mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
   itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
-  mkimage.rom.mkimage rom.map simple-bin.map
+  mkimage.rom.mkimage rom.map simple-bin.map simple-bin-spi.map \
+  idbloader-spi.img
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl \
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index f90a8bf085..584f21eb5b 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -39,5 +39,35 @@
offset = ;
};
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+   simple-bin-spi {
+   filename = "u-boot-rockchip-spi.bin";
+   pad-byte = <0xff>;
+
+   mkimage {
+   filename = "idbloader-spi.img";
+   args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
+#ifdef CONFIG_TPL
+   multiple-data-files;
+
+   u-boot-tpl {
+   };
+#endif
+   u-boot-spl {
+   };
+   };
+
+#ifdef CONFIG_ARM64
+   blob {
+   filename = "u-boot.itb";
+#else
+   u-boot-img {
+#endif
+   /* Sync with u-boot,spl-payload-offset if present */
+   offset = ;
+   };
+   };
+#endif
 };
 #endif
-- 
2.37.1



[PATCH v4 7/8] rockchip: allow to build SPI images even without HAS_ROM option

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

This prepares for the creation of a u-boot-rockchip-spi.bin image
similar to u-boot-rockchip.bin to the exception it's destined for
SPI-NOR flashes instead of MMC storage medium.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 arch/arm/dts/rk3288-u-boot.dtsi | 2 +-
 arch/arm/dts/rk3399-u-boot.dtsi | 2 +-
 arch/arm/mach-rockchip/Kconfig  | 6 ++
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 9eb696b141..e411445ed6 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -56,7 +56,7 @@
};
 };
 
-#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
 &binman {
rom {
filename = "u-boot.rom";
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 716b9a433a..3c1a15fe51 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -60,7 +60,7 @@
 
 };
 
-#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
 &binman {
rom {
filename = "u-boot.rom";
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index c561a77e6a..b46cea2f91 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -425,12 +425,10 @@ config SPL_MMC
 
 config ROCKCHIP_SPI_IMAGE
bool "Build a SPI image for rockchip"
-   depends on HAS_ROM
help
  Some Rockchip SoCs support booting from SPI flash. Enable this
- option to produce a 4MB SPI-flash image (called u-boot.rom)
- containing U-Boot. The image is built by binman. U-Boot sits near
- the start of the image.
+ option to produce a SPI-flash image containing U-Boot. The image
+ is built by binman. U-Boot sits near the start of the image.
 
 config LNX_KRNL_IMG_TEXT_OFFSET_BASE
default SYS_TEXT_BASE
-- 
2.37.1



[PATCH v4 6/8] rockchip: simplify binman image dependencies addition to INPUTS

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

By factoring SPL check in the first condition, this makes the checks a
bit less convoluted and more readable.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

v4:
 - fixed wrong place for endif for ARM32 boards,

 Makefile | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index f8e919e136..5fb470b0d8 100644
--- a/Makefile
+++ b/Makefile
@@ -995,19 +995,14 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
 INPUTS-y += u-boot-with-dtb.bin
 endif
 
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-# On ARM64 this target is produced by binman so we don't need this dep
+ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
+# Binman image dependencies
 ifeq ($(CONFIG_ARM64),y)
-ifeq ($(CONFIG_SPL),y)
 INPUTS-y += u-boot.itb
-endif
 else
-ifeq ($(CONFIG_SPL),y)
-# Generate these inputs for binman which will create the output files
 INPUTS-y += u-boot.img
 endif
 endif
-endif
 
 INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
-- 
2.37.1



[PATCH v4 5/8] rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

This allows to build u-boot-rockchip.bin binary with binman for Rockchip
ARM64 boards instead of the legacy Makefile way.

Cc: Quentin Schulz 
Reviewed-by: Simon Glass 
Signed-off-by: Quentin Schulz 
---

v4:
 - added Reviewed-by,

 Makefile  | 26 +-
 arch/arm/Kconfig  |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi |  5 +
 3 files changed, 7 insertions(+), 26 deletions(-)

diff --git a/Makefile b/Makefile
index ceb5b5e0d9..f8e919e136 100644
--- a/Makefile
+++ b/Makefile
@@ -999,8 +999,7 @@ ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
 # On ARM64 this target is produced by binman so we don't need this dep
 ifeq ($(CONFIG_ARM64),y)
 ifeq ($(CONFIG_SPL),y)
-# TODO: Get binman to generate this too
-INPUTS-y += u-boot-rockchip.bin
+INPUTS-y += u-boot.itb
 endif
 else
 ifeq ($(CONFIG_SPL),y)
@@ -1493,29 +1492,6 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \
 u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE
$(call if_changed,pad_cat)
 
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-
-# TPL + SPL
-ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy)
-MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd
-tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE
-   $(call if_changed,mkimage)
-idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE
-   $(call if_changed,cat)
-else
-MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd
-idbloader.img: spl/u-boot-spl.bin FORCE
-   $(call if_changed,mkimage)
-endif
-
-ifeq ($(CONFIG_ARM64),y)
-OBJCOPYFLAGS_u-boot-rockchip.bin = -I binary -O binary \
-   --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
-u-boot-rockchip.bin: idbloader.img u-boot.itb FORCE
-   $(call if_changed,pad_cat)
-endif # CONFIG_ARM64
-
-endif # CONFIG_ARCH_ROCKCHIP
 
 ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy)
 MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 949ebb46ba..c973146f8d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1974,7 +1974,7 @@ config ARCH_STM32MP
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select BLK
-   select BINMAN if SPL_OPTEE || (SPL && !ARM64)
+   select BINMAN if SPL_OPTEE || SPL
select DM
select DM_GPIO
select DM_I2C
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index ad72ca9700..f90a8bf085 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -30,7 +30,12 @@
};
};
 
+#ifdef CONFIG_ARM64
+   blob {
+   filename = "u-boot.itb";
+#else
u-boot-img {
+#endif
offset = ;
};
};
-- 
2.37.1



[PATCH v4 4/8] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

idbloader.img content - currently created by way of Makefile - can be
created by binman directly.

So let's do that for Rockchip ARM platforms.

Cc: Quentin Schulz 
Reviewed-by: Simon Glass 
Signed-off-by: Quentin Schulz 
---
v4:
 - added Reviewed-by,

v3:
 - moved spl back into mkimage section,
 - added filename property so that the idbloader.img binary is still
 generated,

 Makefile  |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi | 11 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index bbb2a4c088..ceb5b5e0d9 100644
--- a/Makefile
+++ b/Makefile
@@ -1005,7 +1005,7 @@ endif
 else
 ifeq ($(CONFIG_SPL),y)
 # Generate these inputs for binman which will create the output files
-INPUTS-y += idbloader.img u-boot.img
+INPUTS-y += u-boot.img
 endif
 endif
 endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
index eae3ee715d..ad72ca9700 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -17,8 +17,17 @@
filename = "u-boot-rockchip.bin";
pad-byte = <0xff>;
 
-   blob {
+   mkimage {
filename = "idbloader.img";
+   args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+#ifdef CONFIG_TPL
+   multiple-data-files;
+
+   u-boot-tpl {
+   };
+#endif
+   u-boot-spl {
+   };
};
 
u-boot-img {
-- 
2.37.1



[PATCH v4 3/8] rockchip: remove binman temporary files when cleaning

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

Binman mkimage entry generates temporary files so let's remove them
when calling `make clean`.

Fixes: 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on jerry")
Cc: Quentin Schulz 
Reported-by: Johan Jonker 
Signed-off-by: Quentin Schulz 
---

added in v3

 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index ff25f92974..bbb2a4c088 100644
--- a/Makefile
+++ b/Makefile
@@ -2220,7 +2220,8 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h 
\
   lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
   idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
   mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
-  itb.fit.fit itb.fit.itb itb.map spl.map
+  itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
+  mkimage.rom.mkimage rom.map simple-bin.map
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl \
-- 
2.37.1



[PATCH v4 2/8] binman: allow user-defined filenames for mkimage entry

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

mkimage entry currently creates a file whose name is derived from the
section name containing said entry.

Let's allow the user to define a filename for the mkimage-generated
binary by using the 'filename' DT property.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

v4:
 - added binman test,
 - fixed >80 chars-long line,

added in v3

 tools/binman/etype/mkimage.py  |  9 ++--
 tools/binman/ftest.py  |  6 ++
 tools/binman/test/235_mkimage_filename.dts | 24 ++
 3 files changed, 37 insertions(+), 2 deletions(-)
 create mode 100644 tools/binman/test/235_mkimage_filename.dts

diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 52297c23ea..009b26f10a 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -20,11 +20,13 @@ class Entry_mkimage(Entry):
   datafiles to mkimage instead of creating a temporary file the result
   of datafiles concatenation
 - args: Other arguments to pass
+- filename: filename of output binary generated by mkimage
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
 e.g.::
 
 mkimage {
+filename = "imximage.bin";
 args = "-n test -T imximage";
 
 u-boot-spl {
@@ -33,7 +35,7 @@ class Entry_mkimage(Entry):
 
 This calls mkimage to create an imximage with u-boot-spl.bin as the input
 file. The output from mkimage then becomes part of the image produced by
-binman.
+binman but also is written into imximage.bin file.
 
To pass all datafiles untouched to mkimage::
 
@@ -70,6 +72,7 @@ class Entry_mkimage(Entry):
 self._args = fdt_util.GetArgs(self._node, 'args')
 self._multiple_data_files = fdt_util.GetBool(self._node, 
'multiple-data-files')
 self._mkimage_entries = OrderedDict()
+self._filename = fdt_util.GetString(self._node, 'filename')
 self.align_default = None
 self.ReadEntries()
 
@@ -89,7 +92,9 @@ class Entry_mkimage(Entry):
 self._mkimage_entries.values(), 'mkimage', fake_size)
 if data is None:
 return False
-output_fname = tools.get_output_filename('mkimage-out.%s' % uniq)
+
+outfile = self._filename if self._filename else 'mkimage-out.%s' % uniq
+output_fname = tools.get_output_filename(outfile)
 if self.mkimage.run_cmd('-d', input_fname, *self._args,
 output_fname) is not None:
 self.SetContents(tools.read_file(output_fname))
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index fa1f421c05..9820d50c3c 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -5703,6 +5703,12 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 dts='234_replace_section_simple.dts')
 self.assertEqual(new_data, data)
 
+def testMkimageFilename(self):
+"""Test using mkimage to build a binary with a filename"""
+retcode = self._DoTestFile('235_mkimage_filename.dts')
+self.assertEqual(0, retcode)
+fname = tools.get_output_filename('mkimage-test.bin')
+self.assertTrue(os.path.exists(fname))
 
 if __name__ == "__main__":
 unittest.main()
diff --git a/tools/binman/test/235_mkimage_filename.dts 
b/tools/binman/test/235_mkimage_filename.dts
new file mode 100644
index 00..b6f28eb9ab
--- /dev/null
+++ b/tools/binman/test/235_mkimage_filename.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   size = <0x80>;
+
+   mkimage {
+   filename = "mkimage-test.bin";
+   args = "-n test -T script";
+
+   u-boot-spl {
+   };
+
+   _testing {
+   return-contents-later;
+   };
+   };
+   };
+};
-- 
2.37.1



[PATCH v4 1/8] binman: add support for skipping file concatenation for mkimage

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

Some image types handled by mkimage require the datafiles to be passed
independently (-d data1:data2) for specific handling of each. A
concatenation of datafiles prior to passing them to mkimage wouldn't
work.

That is the case for rkspi for example which requires page alignment
and only writing 2KB every 4KB.

This adds the ability to tell binman to pass the datafiles without
prior concatenation to mkimage, by adding the multiple-data-files
boolean property to the mkimage node.

Cc: Quentin Schulz 
Reviewed-by: Simon Glass 
Signed-off-by: Quentin Schulz 
---
 tools/binman/entries.rst  | 22 +++
 tools/binman/etype/mkimage.py | 41 +++
 2 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index ae4305c99e..60c89aec59 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1101,6 +1101,9 @@ Entry: mkimage: Binary produced by mkimage
 
 Properties / Entry arguments:
 - datafile: Filename for -d argument
+- multiple-data-files: boolean to tell binman to pass all files as
+  datafiles to mkimage instead of creating a temporary file the result
+  of datafiles concatenation
 - args: Other arguments to pass
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
@@ -1117,6 +1120,25 @@ This calls mkimage to create an imximage with 
u-boot-spl.bin as the input
 file. The output from mkimage then becomes part of the image produced by
 binman.
 
+To pass all datafiles untouched to mkimage::
+
+mkimage {
+args = "-n rk3399 -T rkspi";
+multiple-data-files;
+
+u-boot-tpl {
+};
+
+u-boot-spl {
+};
+};
+
+This calls mkimage to create a Rockchip RK3399-specific first stage
+bootloader, made of TPL+SPL. Since this first stage bootloader requires to
+align the TPL and SPL but also some weird hacks that is handled by mkimage
+directly, binman is told to not perform the concatenation of datafiles prior
+to passing the data to mkimage.
+
 To use CONFIG options in the arguments, use a string list instead, as in
 this example which also produces four arguments::
 
diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 5f6def2287..52297c23ea 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -16,6 +16,9 @@ class Entry_mkimage(Entry):
 
 Properties / Entry arguments:
 - datafile: Filename for -d argument
+- multiple-data-files: boolean to tell binman to pass all files as
+  datafiles to mkimage instead of creating a temporary file the result
+  of datafiles concatenation
 - args: Other arguments to pass
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
@@ -32,6 +35,25 @@ class Entry_mkimage(Entry):
 file. The output from mkimage then becomes part of the image produced by
 binman.
 
+   To pass all datafiles untouched to mkimage::
+
+   mkimage {
+   args = "-n rk3399 -T rkspi";
+   multiple-data-files;
+
+   u-boot-tpl {
+   };
+
+   u-boot-spl {
+   };
+   };
+
+   This calls mkimage to create a Rockchip RK3399-specific first stage
+   bootloader, made of TPL+SPL. Since this first stage bootloader requires 
to
+   align the TPL and SPL but also some weird hacks that is handled by 
mkimage
+   directly, binman is told to not perform the concatenation of datafiles 
prior
+   to passing the data to mkimage.
+
 To use CONFIG options in the arguments, use a string list instead, as in
 this example which also produces four arguments::
 
@@ -46,16 +68,27 @@ class Entry_mkimage(Entry):
 def __init__(self, section, etype, node):
 super().__init__(section, etype, node)
 self._args = fdt_util.GetArgs(self._node, 'args')
+self._multiple_data_files = fdt_util.GetBool(self._node, 
'multiple-data-files')
 self._mkimage_entries = OrderedDict()
 self.align_default = None
 self.ReadEntries()
 
 def ObtainContents(self):
 # Use a non-zero size for any fake files to keep mkimage happy
-data, input_fname, uniq = self.collect_contents_to_file(
-self._mkimage_entries.values(), 'mkimage', 1024)
-if data is None:
-return False
+fake_size = 1024
+if self._multiple_data_files:
+fnames = []
+uniq = self.GetUniqueName()
+for entry in self._mkimage_entries.values():
+if not entry.ObtainContents(fake_size=fake_size):
+return False
+fnames.append(entry.GetDefaultFilename())
+input_fname = ":".join(fnames)
+else:
+data, input_fname, uniq = self.collect_contents_to_file(

[PATCH v4 0/8] migrate u-boot-rockchip.bin to binman and generate an image for SPI

2022-08-03 Thread Quentin Schulz
From: Quentin Schulz 

This migrates the generation of u-boot-rockchip.bin from Makefile to binman
completely.

This also adds support for generating the same kind of image than
u-boot-rockchip.bin but for SPI flashes (specifically, a different image
type generated by mkimage is necessary, in addition to a different
offset in the storage medium).

This has been tested on Puma RK3399 with patch series from 
https://lore.kernel.org/u-boot/20220722160655.3904213-1-foss+ub...@0leil.net/#b 
(plus 
https://lore.kernel.org/u-boot/20220722113505.3875669-4-foss+ub...@0leil.net/).

Cheers,
Quentin

v4:
 - added binman test for mkimage filename,
 - fixed >80 chars line in patch 2/8 binman: allow user-defined filenames for
 mkimage entry,
 - fixed wrong location for endif in patch 6/8 simplify binman image
 dependencies addition to INPUTS,


v3:
 - removed
 https://lore.kernel.org/u-boot/20220722113505.3875669-4-foss+ub...@0leil.net/,
 it'll be added later on in a separate patch series,
 - added "binman: allow user-defined filenames for mkimage entry,"
 - kept idbloader.img binary creation even with binman as requested by
 community,
 - generate idbloader-spi.img binary with binman,
 - added "rockchip: remove binman temporary files when cleaning"

v2:
 - removed patch 4/8 rockchip: pad u-boot-rockchip.bin correctly because
 it would break partitions table,
 - rebased on top of master, changes to patch 3/7 rockchip: remove
 unneeded CONFIG_SPL_PAD_TO compared to the RFC 3/8 rockchip: remove
 unneeded CONFIG_SPL_PAD_TO,

Quentin Schulz (8):
  binman: add support for skipping file concatenation for mkimage
  binman: allow user-defined filenames for mkimage entry
  rockchip: remove binman temporary files when cleaning
  rockchip: generate idbloader.img content for u-boot-rockchip.bin with
binman for ARM
  rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards
  rockchip: simplify binman image dependencies addition to INPUTS
  rockchip: allow to build SPI images even without HAS_ROM option
  rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR
flash

 Makefile   | 41 --
 arch/arm/Kconfig   |  2 +-
 arch/arm/dts/rk3288-u-boot.dtsi|  2 +-
 arch/arm/dts/rk3399-u-boot.dtsi|  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi  | 46 -
 arch/arm/mach-rockchip/Kconfig |  6 +--
 tools/binman/entries.rst   | 22 ++
 tools/binman/etype/mkimage.py  | 48 +++---
 tools/binman/ftest.py  |  6 +++
 tools/binman/test/235_mkimage_filename.dts | 24 +++
 10 files changed, 151 insertions(+), 48 deletions(-)
 create mode 100644 tools/binman/test/235_mkimage_filename.dts

-- 
2.37.1



imx8mn eMMC boot partition

2022-08-03 Thread Heiko Thiery
Hi,

Does anyone have an idea where to find the definition of the offset
used when booting from eMMCs boot partition?

I tried to write the flash.bin image to offset 32k (page 0x40) into
the boot partition of the eMMC and seledted the bootpartition with
"mmc partconfig 2 0 1 0". The board did not start. After writing the
flash.bin to offset 0 the board starts.

When writing to microSD the offset 32k is ok.

I' using an NXP imx8mn evk board.

-- 
Heiko


Re: [PATCH 1/1] doc: man-page for gpio command

2022-08-03 Thread Quentin Schulz

Hi Heinrich,

On 8/3/22 13:21, Heinrich Schuchardt wrote:

On 8/3/22 11:59, Quentin Schulz wrote:

Hi Heinrich,

On 8/2/22 14:28, Heinrich Schuchardt wrote:

Provide a man-page for the gpio command.

Signed-off-by: Heinrich Schuchardt 
---
  doc/usage/cmd/gpio.rst | 90 ++
  doc/usage/index.rst    |  1 +
  2 files changed, 91 insertions(+)
  create mode 100644 doc/usage/cmd/gpio.rst

diff --git a/doc/usage/cmd/gpio.rst b/doc/usage/cmd/gpio.rst
new file mode 100644
index 00..f6a5668388
--- /dev/null
+++ b/doc/usage/cmd/gpio.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+gpio command
+
+
+Synopsis
+
+
+::
+
+    gpio  
+    gpio read  
+    gpio status [-a] [|]
+
+The gpio command is used to access General Purpose Inputs/Outputs.
+
+gpio input
+--
+
+Switch the GPIO *pin* to input mode.
+
+gpio set
+
+
+Switch the GPIO *pin* to output mode and set the signal to 1.
+


I think this is supposed to follow the 
GPIOD_ACTIVE_LOW/GPIOD_ACTIVE_HIGH flag. So I think it's better to say 
"set the state to active"? Maybe add a few words on this active 
high/low thing to explicit that using gpio set does not necessarily 
mean that the GPIO output will have some voltage.


There is no string GPIOD_ACTIVE_HIGH in U-Boot.

include/asm-generic/gpio.h:124:
#define GPIOD_ACTIVE_LOW BIT(3)
/* GPIO is active when value is low */

The gpio command lacks the capability to set active high or active low. 
It is not even displayed.


The function description of dm_gpio_get_value() documents the return 
value as 0 for inactive, 1 for active.


The function description of gpio_get_value() documents its return value 
as 0 for low or 1 for high.


The uclass implements gpio_get_value() by calling dm_gpio_get_value() 
without inverting the value.


One of both functions is incorrectly documented!

dm_gpio_get_value() calls _gpio_get_value() which calls the driver's 
get_value() function and inverts the value if GPIOD_ACTIVE_LOW is set.


The structure struct dm_gpio_ops lacks any documentation of the meaning 
of the return value.




Considering that _gpio_get_value does the inversion if the 
GPIOD_ACTIVE_LOW flag is set, the expected return value of 
dm_gpio_ops->get_value should be the raw value of the pin as returned by 
the SoC. Not documented, yes, but the meaning is clear to me.



To sum it up:

The function documentation is a mess and leaves it unclear what a value
of 0 or 1 in the gpio command means.



It is clear for DM, not for non-DM.

The first thing to do is to get the documentation of struct dm_gpio_ops 
updated. Next ensure that all drivers implement it this way.




Agreed.

We still ave the issue with values returned by non-DM drivers, but 
should we care? The drivers should be moved to DM_GPIO?


Once the yet to find maintainer of GPIO has done this we can revisit the 
documentation.




Indeed.

I thought DM-only GPIO subsystem was on the map, like all subsystems, 
but I cannot find it on 
https://u-boot.readthedocs.io/en/latest/develop/driver-model/migration.html. 
Otherwise, the move to DM-only for GPIO should also help us in having a 
properly defined expectation of what the gpio command should return, 
since the DM version of gpio commands is handling active state. I'd have 
been inclined to say we shouldn't care too much about non-DM GPIO 
drivers since they'll disappear some day, are deprecated (as per 
documentation in header file) and if they get updated they should follow 
the yet-to-be-written in-file documentation, but I'm not too sure since 
DM_GPIO is not on the map of driver model migration at the moment?





+gpio clear
+--
+
+Switch the GPIO *pin* to output mode and set the signal to 0.
+


Ditto.


+gpio toggle
+---
+
+Switch the GPIO *pin* to output mode and reverse the signal state.
+
+gpio read
+-
+
+Read the signal state of the GPIO *pin* and save it in environment 
variable

+*name*.
+
+gpio status
+---
+
+Display the status of one or multiple GPIOs. By default only claimed 
GPIOs

+are displayed.
+
+-a
+    Display GPIOs irrespective of being claimed.
+
+bank
+    Name of a bank of GPIOs to be displayed.
+
+pin
+    Name of a single GPIO to be displayed or manipulated.
+
+Examples
+
+
+Switch the status of a GPIO::
+
+    => gpio set a5
+    gpio: pin a5 (gpio 133) value is 1


and I guess we should maybe patch the gpio cmd to say here "high" 
instead of "1"?


For an active low GPIO value 1 might mean low.

It would be helpful to provide a way to display if a GPIO is active high 
or active low. But this patch is about documenting the existing 
functionality.




Agreed, it was a suggestion on how to improve the gpio command output 
(in another patch obviously).


Though, this thread sadly highlighted that the gpio command returns 
something that cannot be trusted by the user without digging into the 
driver/datasheet (at least until we get DM-only GPIO su

Re: [PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

2022-08-03 Thread Pali Rohár
On Monday 01 August 2022 19:15:46 Tom Rini wrote:
> On Mon, Aug 01, 2022 at 09:39:00PM +0200, Pali Rohár wrote:
> > On Monday 01 August 2022 13:13:22 Simon Glass wrote:
> > > Hi Pali,
> > > 
> > > On Mon, 1 Aug 2022 at 09:43, Pali Rohár  wrote:
> > > >
> > > > Currently Makefile produces final mpc85xx image when SPL is not used in
> > > > custom file u-boot-with-dtb.bin. It is quite confusing name as build
> > > > process produce also intermediate file standard file u-boot-dtb.bin 
> > > > (which
> > > > is just intermediate and not bootable). Other platforms use u-boot.bin
> > > > (UBOOT_BIN) as standard name for final bootable raw image.
> > > >
> > > > So change Makefile rules and binman to produce final bootable file for
> > > > mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
> > > > define default rule for u-boot.bin then instruct binman (via DTS file) 
> > > > to
> > > > store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
> > > > finally rename target u-boot-with-dtb.bin to u-boot.bin.
> > > >
> > > > With this change are also removed custom Makefile hacks for mpc85xx 
> > > > that it
> > > > produced non-standard output file. And also updated documentation.
> > > >
> > > > Signed-off-by: Pali Rohár 
> > > > ---
> > > >  Makefile | 19 +--
> > > >  arch/powerpc/dts/kmcent2-u-boot.dtsi |  2 +-
> > > >  arch/powerpc/dts/u-boot.dtsi |  2 +-
> > > >  board/freescale/p1_p2_rdb_pc/README  |  2 +-
> > > >  board/freescale/p2041rdb/README  |  3 ---
> > > >  board/freescale/t102xrdb/README  |  2 +-
> > > >  board/freescale/t104xrdb/README  |  2 +-
> > > >  board/freescale/t208xqds/README  |  2 +-
> > > >  board/freescale/t208xrdb/README  |  2 +-
> > > >  9 files changed, 12 insertions(+), 24 deletions(-)
> > > 
> > > At present u-boot.bin has a very standard meaning - it is U-Boot with the 
> > > DT.
> > > 
> > > Boards which need something more than that can/should use binman to
> > > create a separate file.
> > > 
> > > I certainly agree that u-boot-with-dtb.bin is a terrible name, though.
> > > Something more descriptive would be better.
> > > 
> > > But is it possible to drop these SoC-specific rules in the Makefile
> > > and just build everything needed in the standard binman rule in the
> > > Makefile?
> > > 
> > > Regards,
> > > Simon
> > 
> > I do not know what is binman doing and how to use it. I just do not see
> > reason why it is needed to use such additional tool for building final
> > binary for powerpc/mpc85xx as other arm boards do not use it at all.
> > 
> > Ad your comment "At present u-boot.bin has a very standard meaning - it
> > is U-Boot with the DT." - This is exactly what binman for mpc85xx
> > produces.
> > 
> > So I see there could be improvements, but as a first step this my patch
> > should be enough?
> 
> So, one of the issues with PowerPC stuff is that much of it is so far
> behind the rest of U-Boot in terms of frameworks.  So yes, let us start
> by fixing the functional problem you're describing here and then see
> what appetite exists for further work here.
> 
> -- 
> Tom

Ok, so these two patches in this patch series is a starting point.

Now I send another patch which does another cleanup in this area:
https://patchwork.ozlabs.org/project/uboot/patch/20220803112442.4735-1-p...@kernel.org/


Re: [PATCH u-boot-marvell] arm: mvebu: turris_omnia: Add Winbond SPI flash support

2022-08-03 Thread Stefan Roese

On 03.08.22 10:53, Marek Behún wrote:

Some new Omnia boards will come with Winbond SPI flash. Add to
defconfig.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/turris_omnia_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index da94ca74ac..a7f4b4153c 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -81,6 +81,7 @@ CONFIG_DM_MTD=y
  CONFIG_SF_DEFAULT_SPEED=4000
  CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_WINBOND=y
  CONFIG_SPI_FLASH_MTD=y
  CONFIG_PHY_MARVELL=y
  CONFIG_PHY_FIXED=y


Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


[PATCH] Makefile: Reduce usage of custom mpc85xx u-boot.bin target

2022-08-03 Thread Pali Rohár
Building of final u-boot.bin binary for mpc85xx via binman is needed only
when inserting DTB binary in the middle of the u-boot ELF binary (before
.bootpg and .resetvec ELF sections).

These requirements are met when CONFIG_MPC85XX_HAVE_RESET_VECTOR is enabled
(= generating .bootpg/.resetvec sections) and CONFIG_OF_SEPARATE is enabled
(= inserting DTB binary).

So in all other cases use standard build procedure instead of custom
mpc85xx u-boot.bin Makefile target via binman.

Signed-off-by: Pali Rohár 
---
This patch depends on patch series:
https://patchwork.ozlabs.org/project/uboot/list/?series=312130
---
 Makefile | 11 ---
 arch/powerpc/Kconfig |  2 +-
 arch/powerpc/dts/u-boot.dtsi |  8 
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/Makefile b/Makefile
index b1b08695cc47..d659c8118cba 100644
--- a/Makefile
+++ b/Makefile
@@ -1214,12 +1214,12 @@ else ifeq 
($(CONFIG_OF_SEPARATE).$(CONFIG_OF_OMIT_DTB),y.)
 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
$(call if_changed,cat)
 
-ifneq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
+ifneq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
 u-boot.bin: u-boot-dtb.bin FORCE
$(call if_changed,copy)
 endif
 
-else ifneq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
+else ifneq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
 u-boot.bin: u-boot-nodtb.bin FORCE
$(call if_changed,copy)
 endif
@@ -1622,17 +1622,14 @@ u-boot-with-nand-spl.sfp: u-boot-spl-padx4.sfp 
u-boot.img FORCE
 
 endif
 
-ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-u-boot.bin: u-boot-nodtb.bin u-boot.dtb \
-   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR), u-boot-br.bin) FORCE
+ifeq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR)$(CONFIG_OF_SEPARATE),yy)
+u-boot.bin: u-boot-nodtb.bin u-boot.dtb u-boot-br.bin FORCE
$(call if_changed,binman)
 
-ifeq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR),y)
 OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec
 u-boot-br.bin: u-boot FORCE
$(call if_changed,objcopy)
 endif
-endif
 
 quiet_cmd_ldr = LD  $@
 cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 737bdd8edb41..e0e2662f4c84 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -20,7 +20,7 @@ config MPC85xx
select CREATE_ARCH_SYMLINK
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
-   select BINMAN if OF_SEPARATE
+   select BINMAN if MPC85XX_HAVE_RESET_VECTOR && OF_SEPARATE
imply CMD_HASH
imply CMD_IRQ
imply USB_EHCI_HCD if USB
diff --git a/arch/powerpc/dts/u-boot.dtsi b/arch/powerpc/dts/u-boot.dtsi
index 0251afddca82..6588bb7fa5e2 100644
--- a/arch/powerpc/dts/u-boot.dtsi
+++ b/arch/powerpc/dts/u-boot.dtsi
@@ -5,6 +5,8 @@
 
 #include 
 
+#if defined(CONFIG_MPC85XX_HAVE_RESET_VECTOR) && defined(CONFIG_OF_SEPARATE)
+
 / {
binman {
filename = "u-boot.bin";
@@ -19,17 +21,15 @@
};
 
u-boot-dtb-with-ucode {
-#ifdef CONFIG_MPC85xx
align = <4>;
-#endif
};
-#ifdef CONFIG_MPC85XX_HAVE_RESET_VECTOR
 #ifndef CONFIG_RESET_VECTOR_ADDRESS
 #define CONFIG_RESET_VECTOR_ADDRESS 0xfffc
 #endif
powerpc-mpc85xx-bootpg-resetvec {
offset = <(CONFIG_RESET_VECTOR_ADDRESS - 0xffc)>;
};
-#endif
};
 };
+
+#endif
-- 
2.20.1



  1   2   >