Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
Hi Pali,
Follow up on the topic of slow/fast SPL SPI loading.
common/spl/spl_spi.c
/*
* Load U-Boot image from SPI flash into RAM
* In DM mode: defaults speed and mode will be
* taken from DT when available
*/
flash = spi_flash_probe(sf_bus, sf_cs,
CONFIG_SF_DEFAULT_SPEED,
CONFIG_SF_DEFAULT_MODE);
if (!flash) {
puts("SPI probe failed.\n");
return -ENODEV;
}
So that spi-max-frequency = <5000> in the DTS is not used in the probe.
Thanks,
Tony
On Wed, Aug 3, 2022 at 11:06 PM Tony Dinh wrote:
>
> 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
Re: [PATCH v3] Provide more details of exactly how configuration signatures are calculated
Hi Martin
On Wed, Aug 3, 2022 at 9:55 PM Martin Bonner wrote:
>
> 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
>
Can you just write the Changes note in the next section like:
Describe exactly which bytes are hashed and in what order so that external
tools can calculate a valid signature.
Signed-off-by: Martin Bonner
---
Changes V1->V2:
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).
---
doc/uImage.FIT/signature.txt | 26 ++
> -- >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: Submitting patches
On 8/4/22 09:24, Martin Bonner wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > 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. bypass the company network as well if you can. Try disconnecting the VPN if you're working from home, or use your phone as a personal hotspot. > > 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. If I got tired of fighting them, I would bypass the company's infrastructure.
Re: [PATCH 1/2] ARM: cache: Allow SPL to build cache-pl310.c
On Thu, 2022-08-04 at 11:02 +0200, Marek Vasut wrote: > On 8/4/22 10:15, Philip Oberfichtner wrote: > > Before this commit, the SPL could enable the PL310 L2 cache [1], > > but the > > cache maintenance functions from cache-pl310.c were only useable > > for > > non-SPL builds. > > > > After enabling the cache one must be able to flush it, too. Thus > > this > > commit allows cache-pl310.c to be included in the SPL build. > > > > [1] See for example arch/arm/mach-imx/cache.c: > > v7_outer_cache_enable() > > > > Signed-off-by: Philip Oberfichtner > > --- > > > > arch/arm/lib/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > > index c603fe61bc..ac1d4245bb 100644 > > --- a/arch/arm/lib/Makefile > > +++ b/arch/arm/lib/Makefile > > @@ -33,7 +33,6 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o > > obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o > > obj-$(CONFIG_CMD_BOOTM) += bootm.o > > obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o > > -obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o > > else > > obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o > > obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o > > @@ -46,6 +45,7 @@ else > > obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o > > obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o > > endif > > +obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o > > Doesn't this need SPL/TPL Kconfig symbols and > > obj-$(CONFIG_$(SPL_TPL_)SYS_L2_PL310) += cache-pl310.o > > ? CONFIG_SYS_L2_PL310 is not converted to Kconfig yet. And there is no CONFIG_SPL_ usage for it so far. So I'd say no. Please correct me if I'm wrong.
Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
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: [PATCH 1/1] block: fix blk_get_devnum_by_typename()
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 v10 00/10] enable menu-driven UEFI variable maintenance
Hi Ilias, Akashi-san,
On Wed, 27 Jul 2022 at 10:56, Takahiro Akashi
wrote:
>
> On Wed, Jul 27, 2022 at 10:08:00AM +0900, Takahiro Akashi wrote:
> > On Fri, Jul 22, 2022 at 11:45:49AM +0300, Ilias Apalodimas wrote:
> > > Hi Kojima-san,
> > >
> > > On Fri, 22 Jul 2022 at 05:36, Masahisa Kojima
> > > wrote:
> > > >
> > > > This series adds the menu-driven UEFI boot variable maintenance
> > > > through the "eficonfig" new command.
> > > > This series also adds the removable media support in bootmenu.
> > > >
> > > > Initrd file selection and python based unit test are added in v10.
> > > >
> > > > Source code can be cloned with:
> > > > $ git clone https://git.linaro.org/people/masahisa.kojima/u-boot.git -b
> > > > eficonfig_upstream_v10
> > > >
> > > > [Major Changes]
> > > > - rebased v2022.07
> > > > - add initrd file selection
> > >
> > > I tried to load an initrd, which on typical distros is not part of the
> > > ESP. While
> > > => ls virtio 0:2
> > >
> > > reads the filesystem contents fine, whenI try to navigate to that
> > > virtio (and ext4 filesystem) device through the menu I am getting:
> > > "Reading volume failed!"
> > >
> > > Any ideas?
> >
> > eficonfig_select_file()
> > efi_file_open_int()
> > file_open()
> > exists = fs_exists(fh->path);
> > ...
> >
> > It seems that fat and ext4 work in a different way against a *directory*
> > here.
> > For instance, try this both on fat and ext4
> > ("test -e" internally uses fs_exists().)
> > => test -e virtio X:Y /
> > => echo $?
> >
> > I think eficonfig_select_file() can be rewritten with
> > fs_opendir()/fs_readdir().
>
> Correction:
> Not all file systems support fs_opendir/fs_readdir interfaces, so this is not
> a viable solution in general.
> (Please note that UEFI spec says nothing about file systems other than fat,
> though.)
lib/efi_loader/efi_file.c calls fs_opendir()/fs_readdir() to access
the directory information,
and ext4 file system code does not support fs_opendir()/fs_readdir().
I could not find any generic method to read directory information for
the file system
that U-Boot supports. It seems that it requires much effort to support
creating the
file selection menu other than FAT file system.
Thanks,
Masahisa Kojima
>
> -Takahiro Akashi
>
> > (Or much more preferably, efi_open(), and essentially fs_exists(), should
> > be fixed.)
> >
> > -Takahiro Akashi
> >
> > > Regards
> > > /Ilias
> > > > - add python based unit test
> > > > - there is detailed changelog in each commit
> > > >
> > > > Masahisa Kojima (10):
> > > > efi_loader: move udevice pointer into struct efi_object
> > > > eficonfig: menu-driven addition of UEFI boot option
> > > > eficonfig: add "Edit Boot Option" menu entry
> > > > menu: add KEY_PLUS and KEY_MINUS handling
> > > > eficonfig: add "Change Boot Order" menu entry
> > > > eficonfig: add "Delete Boot Option" menu entry
> > > > bootmenu: add removable media entries
> > > > doc:bootmenu: add description for UEFI boot support
> > > > doc:eficonfig: add documentation for eficonfig command
> > > > test: unit test for eficonfig
> > > >
> > > > cmd/Kconfig |7 +
> > > > cmd/Makefile |1 +
> > > > cmd/bootmenu.c| 106 +-
> > > > cmd/eficonfig.c | 2103 +
> > > > common/menu.c |6 +
> > > > configs/sandbox_defconfig |1 +
> > > > doc/usage/cmd/bootmenu.rst| 74 +
> > > > doc/usage/cmd/eficonfig.rst | 63 +
> > > > doc/usage/index.rst |1 +
> > > > include/efi_config.h | 91 +
> > > > include/efi_loader.h | 67 +
> > > > include/menu.h|2 +
> > > > lib/efi_driver/efi_block_device.c |3 +-
> > > > lib/efi_loader/efi_bootmgr.c |7 +
> > > > lib/efi_loader/efi_boottime.c | 52 +-
> > > > lib/efi_loader/efi_console.c | 70 +
> > > > lib/efi_loader/efi_disk.c | 65 +-
> > > > lib/efi_loader/efi_file.c | 75 +-
> > > > lib/efi_loader/efi_helper.c | 13 +
> > > > test/py/tests/test_eficonfig/conftest.py | 40 +
> > > > .../py/tests/test_eficonfig/test_eficonfig.py | 325 +++
> > > > 21 files changed, 3109 insertions(+), 63 deletions(-)
> > > > create mode 100644 cmd/eficonfig.c
> > > > create mode 100644 doc/usage/cmd/eficonfig.rst
> > > > create mode 100644 include/efi_config.h
> > > > create mode 100644 test/py/tests/test_eficonfig/conftest.py
> > > > create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py
> > > >
> > > > --
> > > > 2.17.1
> > > >
[PATCH 0/6] SBx81LIFKW/SBx81LIFXCAT disable KIRKWOOD_GPIO
This series makes changes to use the DM gpio APIs so that KIRKWOOD_GPIO can be disabled on these boards. Chris Packham (6): ARM: kirkwood: SBx81LIFKW: remove direct access of GPIO registers ARM: kirkwood: SBx81LIFKW: update for DM_GPIO ARM: kirkwood: SBx81LIFKW: enable CMD_GPIO ARM: kirkwood: SBx81LIFKW: disable KIRKWOOD_GPIO ARM: kirkwood: SBx81LIFKW: enable CONFIG_NET_RANDOM_ETHADDR ARM: kirkwood: SBx81LIFXCAT: disable KIRKWOOD_GPIO arch/arm/dts/kirkwood-atl-sbx81lifkw.dts| 14 board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c | 71 - configs/SBx81LIFKW_defconfig| 5 +- configs/SBx81LIFXCAT_defconfig | 1 - 4 files changed, 45 insertions(+), 46 deletions(-) -- 2.37.1
[PATCH 4/6] ARM: kirkwood: SBx81LIFKW: disable KIRKWOOD_GPIO
DM_GPIO was already enabled so the MVEBU_GPIO was already available. Having updated the board code to use the DM_GPIO APIs the KIRKWOOD_GPIO driver became unnecessary. Disable it for SBx81LIFKW. Signed-off-by: Chris Packham --- configs/SBx81LIFKW_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig index ad7e2e976d2a..ec940bd30891 100644 --- a/configs/SBx81LIFKW_defconfig +++ b/configs/SBx81LIFKW_defconfig @@ -41,7 +41,6 @@ CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NETCONSOLE=y CONFIG_DM=y -CONFIG_KIRKWOOD_GPIO=y CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y -- 2.37.1
[PATCH 2/6] ARM: kirkwood: SBx81LIFKW: update for DM_GPIO
Update mv88e61xx_hw_reset() to use the DM_GPIO API to toggle the reset
line for the linkstreet switch.
Signed-off-by: Chris Packham
---
board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
b/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
index feb8b6b83f00..e0a7f3fa89f0 100644
--- a/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
+++ b/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
@@ -17,7 +17,8 @@
#include
#include
#include
-#include
+#include
+#include
/* Note: GPIO differences between specific boards
*
@@ -37,8 +38,6 @@
#define SBX81LIFKW_OE_VAL_LOW (BIT(31) | BIT(30) | BIT(28) | BIT(27))
#define SBX81LIFKW_OE_VAL_HIGH (BIT(0) | BIT(1))
-#define MV88E6097_RESET27
-
DECLARE_GLOBAL_DATA_PTR;
int board_early_init_f(void)
@@ -143,11 +142,23 @@ void reset_phy(void)
#ifdef CONFIG_MV88E61XX_SWITCH
int mv88e61xx_hw_reset(struct phy_device *phydev)
{
+ struct gpio_desc desc;
+ int ret;
+
+ ret = dm_gpio_lookup_name("mvebu0_27", );
+ if (ret)
+ return ret;
+
+ ret = dm_gpio_request(, "linkstreet_rst");
+ if (ret)
+ return ret;
+
/* Ensure the 88e6097 gets at least 10ms Reset
*/
- kw_gpio_set_value(MV88E6097_RESET, 0);
+ dm_gpio_set_dir_flags(, GPIOD_IS_OUT);
+ dm_gpio_set_value(, 0);
mdelay(20);
- kw_gpio_set_value(MV88E6097_RESET, 1);
+ dm_gpio_set_value(, 1);
mdelay(20);
phydev->advertising = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
--
2.37.1
[PATCH 1/6] ARM: kirkwood: SBx81LIFKW: remove direct access of GPIO registers
Replace code that accessed the GPIO registers directly with code that
makes use of the LED_GPIO driver.
Signed-off-by: Chris Packham
---
arch/arm/dts/kirkwood-atl-sbx81lifkw.dts| 14 ++
board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c | 50 +
configs/SBx81LIFKW_defconfig| 2 +
3 files changed, 27 insertions(+), 39 deletions(-)
diff --git a/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
b/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
index 4ae74f4316e5..3837c8f77fe2 100644
--- a/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
+++ b/arch/arm/dts/kirkwood-atl-sbx81lifkw.dts
@@ -70,6 +70,20 @@
};
};
};
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ ledn {
+ label = "status:ledn";
+ gpios = < 10 GPIO_ACTIVE_HIGH>;
+ };
+
+ ledp {
+ label = "status:ledp";
+ gpios = < 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
{
diff --git a/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
b/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
index d8b9fdfe356f..feb8b6b83f00 100644
--- a/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
+++ b/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c
@@ -13,7 +13,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -41,41 +41,6 @@
DECLARE_GLOBAL_DATA_PTR;
-struct led {
- u32 reg;
- u32 value;
- u32 mask;
-};
-
-struct led amber_solid = {
- MVEBU_GPIO0_BASE,
- BIT(10),
- BIT(18) | BIT(10)
-};
-
-struct led green_solid = {
- MVEBU_GPIO0_BASE,
- BIT(18) | BIT(10),
- BIT(18) | BIT(10)
-};
-
-struct led amber_flash = {
- MVEBU_GPIO0_BASE,
- 0,
- BIT(18) | BIT(10)
-};
-
-struct led green_flash = {
- MVEBU_GPIO0_BASE,
- BIT(18),
- BIT(18) | BIT(10)
-};
-
-static void status_led_set(struct led *led)
-{
- clrsetbits_le32(led->reg, led->mask, led->value);
-}
-
int board_early_init_f(void)
{
/*
@@ -165,8 +130,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
- status_led_set(_solid);
-
return 0;
}
@@ -196,7 +159,16 @@ int mv88e61xx_hw_reset(struct phy_device *phydev)
#ifdef CONFIG_MISC_INIT_R
int misc_init_r(void)
{
- status_led_set(_flash);
+ struct udevice *dev;
+ int ret;
+
+ ret = led_get_by_label("status:ledp", );
+ if (!ret)
+ led_set_state(dev, LEDST_ON);
+
+ ret = led_get_by_label("status:ledn", );
+ if (!ret)
+ led_set_state(dev, LEDST_OFF);
return 0;
}
diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig
index f186f247eb63..90800e2dd3ee 100644
--- a/configs/SBx81LIFKW_defconfig
+++ b/configs/SBx81LIFKW_defconfig
@@ -46,6 +46,8 @@ CONFIG_DM_I2C=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
# CONFIG_MMC is not set
CONFIG_MTD=y
CONFIG_DM_SPI_FLASH=y
--
2.37.1
[PATCH 3/6] ARM: kirkwood: SBx81LIFKW: enable CMD_GPIO
For debugging it is convenient to query/access GPIOs from the command line. Signed-off-by: Chris Packham --- configs/SBx81LIFKW_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig index 90800e2dd3ee..ad7e2e976d2a 100644 --- a/configs/SBx81LIFKW_defconfig +++ b/configs/SBx81LIFKW_defconfig @@ -26,6 +26,7 @@ CONFIG_SYS_CBSIZE=256 CONFIG_SYS_PBSIZE=276 CONFIG_CMD_DM=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_DHCP=y CONFIG_BOOTP_NTPSERVER=y -- 2.37.1
Re: Submitting patches
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] Migration: set deadline for move to DM_GPIO
Hi, 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'll give it a try on the lsxl board during next week. -michael
[PATCH 5/6] ARM: kirkwood: SBx81LIFKW: enable CONFIG_NET_RANDOM_ETHADDR
When booting a fresh board having a random Ethernet address enables using the network device to program the board. Signed-off-by: Chris Packham --- configs/SBx81LIFKW_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/SBx81LIFKW_defconfig b/configs/SBx81LIFKW_defconfig index ec940bd30891..a9f984239af9 100644 --- a/configs/SBx81LIFKW_defconfig +++ b/configs/SBx81LIFKW_defconfig @@ -39,6 +39,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_NETCONSOLE=y CONFIG_DM=y CONFIG_DM_PCA953X=y -- 2.37.1
[PATCH 6/6] ARM: kirkwood: SBx81LIFXCAT: disable KIRKWOOD_GPIO
DM_GPIO was already enabled so the MVEBU_GPIO was already available. Disable KIRKWOOD_GPIO as it was unnecessary. Signed-off-by: Chris Packham --- configs/SBx81LIFXCAT_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/SBx81LIFXCAT_defconfig b/configs/SBx81LIFXCAT_defconfig index 9d579091a82f..cb80b7876f38 100644 --- a/configs/SBx81LIFXCAT_defconfig +++ b/configs/SBx81LIFXCAT_defconfig @@ -42,7 +42,6 @@ CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NETCONSOLE=y CONFIG_DM=y -CONFIG_KIRKWOOD_GPIO=y CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y -- 2.37.1
RE: [PATCH v3] Provide more details of exactly how configuration signatures are calculated
> 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: [PATCH v3] Provide more details of exactly how configuration signatures are calculated
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 2/3] binman: Remove header from compressed data
Hi Simon,
Am 03.08.2022 um 20:14 schrieb 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.
Does this means the size is only needed for the creation of the fitImage
and not for decompression in u-boot?
Do you have a test for this use case?
There are various ones, e.g. testCompressDtb()
Thanks. Now I understand the problem and why you call it a
chicken-and-egg problem. It wasn't clear to me that the attributes are
inside the DTB.
But I wonder how the decompression of the DTB works if the fitImage
implementation doesn't support the header.
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.
Do we need the header outside of the DTB? Otherwise we could handle this
special or we could add a special compression type.
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.
Do we really need the header outside of the DTB entry?
Regards
Stefan
Re: [PATCH] gpio: Remove mvgpio driver
On Thursday 04 August 2022 11:43:57 Chris Packham wrote:
> The last user of this driver was removed in commit dee08b1999e2 ("arm:
> Remove gplugd board"). Remove the unused driver.
>
> Signed-off-by: Chris Packham
Acked-by: Pali Rohár
> ---
>
> 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_GPIO 128
> -#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), _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), _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(_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), _reg_bank->gpsr);
> - else
> - writel(GPIO_TO_BIT(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
Re: [PATCH 1/2] ARM: cache: Allow SPL to build cache-pl310.c
On 8/4/22 10:15, Philip Oberfichtner wrote: Before this commit, the SPL could enable the PL310 L2 cache [1], but the cache maintenance functions from cache-pl310.c were only useable for non-SPL builds. After enabling the cache one must be able to flush it, too. Thus this commit allows cache-pl310.c to be included in the SPL build. [1] See for example arch/arm/mach-imx/cache.c: v7_outer_cache_enable() Signed-off-by: Philip Oberfichtner --- arch/arm/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index c603fe61bc..ac1d4245bb 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -33,7 +33,6 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o -obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o else obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o @@ -46,6 +45,7 @@ else obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o endif +obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o Doesn't this need SPL/TPL Kconfig symbols and obj-$(CONFIG_$(SPL_TPL_)SYS_L2_PL310) += cache-pl310.o ?
[PATCH 1/2] ARM: cache: Allow SPL to build cache-pl310.c
Before this commit, the SPL could enable the PL310 L2 cache [1], but the cache maintenance functions from cache-pl310.c were only useable for non-SPL builds. After enabling the cache one must be able to flush it, too. Thus this commit allows cache-pl310.c to be included in the SPL build. [1] See for example arch/arm/mach-imx/cache.c: v7_outer_cache_enable() Signed-off-by: Philip Oberfichtner --- arch/arm/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index c603fe61bc..ac1d4245bb 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -33,7 +33,6 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o -obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o else obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o @@ -46,6 +45,7 @@ else obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o endif +obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += semihosting.o ifneq ($(filter y,$(CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR) $(CONFIG_SAVE_PREV_BL_FDT_ADDR)),) -- 2.37.1
[PATCH 2/2] ARM: imx6: dh-imx6: Enable d-cache early in SPL
From: Marek Vasut
Enable d-cache early in SPL right after DRAM is started up.
This reduces U-Boot proper load time by 650ms when loaded
from SPI NOR.
Signed-off-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index e49e97724a..2c0ddc527a 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,11 +15,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -610,6 +613,20 @@ static void dhcom_spl_dram_init(void)
}
}
+void dram_bank_mmu_setup(int bank)
+{
+ int i;
+
+ set_section_dcache(ROMCP_ARB_BASE_ADDR >> MMU_SECTION_SHIFT,
DCACHE_DEFAULT_OPTION);
+ set_section_dcache(IRAM_BASE_ADDR >> MMU_SECTION_SHIFT,
DCACHE_DEFAULT_OPTION);
+
+ for (i = MMDC0_ARB_BASE_ADDR >> MMU_SECTION_SHIFT;
+ i < ((MMDC0_ARB_BASE_ADDR >> MMU_SECTION_SHIFT) +
+ (SZ_1G >> MMU_SECTION_SHIFT));
+ i++)
+ set_section_dcache(i, DCACHE_DEFAULT_OPTION);
+}
+
void board_init_f(ulong dummy)
{
/* setup AIPS and disable watchdog */
@@ -636,9 +653,19 @@ void board_init_f(ulong dummy)
/* DDR3 initialization */
dhcom_spl_dram_init();
+ /* Set up early MMU tables at the beginning of DRAM and start d-cache */
+ gd->arch.tlb_addr = MMDC0_ARB_BASE_ADDR + SZ_32M;
+ gd->arch.tlb_size = PGTABLE_SIZE;
+ enable_caches();
+
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
+
+void spl_board_prepare_for_boot(void)
+{
+ dcache_disable();
+}
--
2.37.1
Re: [PATCH 01/31] arm: mediatek: add support for MediaTek MT7986 SoC
Hi Weijie,
happy to see this series posted!
Trying to apply it unfortunately fails due to errornous line-breaks,
supposedly inserted by your MUA, see below.
I didn't go beyond the first patch and it'd be nice if you report the
whole series without the wrong line-breaks.
Cheers
Daniel
On Thu, Aug 04, 2022 at 11:34:28AM +0800, Weijie Gao wrote:
> This patch adds basic support for MediaTek MT7986 SoC.
> This include the file that will initialize the SoC after boot and its
> device tree.
>
> Signed-off-by: Weijie Gao
> ---
> arch/arm/dts/mt7986-u-boot.dtsi | 33 ++
> arch/arm/dts/mt7986.dtsi | 341 ++
> arch/arm/mach-mediatek/Kconfig| 11 +
> arch/arm/mach-mediatek/Makefile | 1 +
> arch/arm/mach-mediatek/mt7986/Makefile| 4 +
> arch/arm/mach-mediatek/mt7986/init.c | 53 +++
> arch/arm/mach-mediatek/mt7986/lowlevel_init.S | 30 ++
> 7 files changed, 473 insertions(+)
> create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
> create mode 100644 arch/arm/dts/mt7986.dtsi
> create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
> create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
> create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
>
> diff --git a/arch/arm/dts/mt7986-u-boot.dtsi
> b/arch/arm/dts/mt7986-u-boot.dtsi
The above two lines should be a single line.
> new file mode 100644
> index 00..95671f8afa
> --- /dev/null
> +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> new file mode 100644
> index 00..f235bd8b8c
> --- /dev/null
> +++ b/arch/arm/dts/mt7986.dtsi
> @@ -0,0 +1,341 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + compatible = "mediatek,mt7986";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + config {
> + u-boot,mmc-env-partition = "u-boot-env";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + };
> +
> + dummy_clk: dummy12m {
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + #clock-cells = <0>;
> + /* must need this line, or uart uanable to get dummy_clk */
> + u-boot,dm-pre-reloc;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <>;
> + clock-frequency = <1300>;
> + interrupts = ,
> + ,
> + ,
> + ;
> + arm,cpu-registers-not-fw-configured;
> + };
> +
> + timer0: timer@10008000 {
> + compatible = "mediatek,mt7986-timer";
> + reg = <0x10008000 0x1000>;
> + interrupts = ;
> + clocks = < CK_INFRA_CK_F26M>;
> + clock-names = "gpt-clk";
> + u-boot,dm-pre-reloc;
> + };
> +
> + watchdog: watchdog@1001c000 {
> + compatible = "mediatek,mt7986-wdt";
> + reg = <0x1001c000 0x1000>;
> + interrupts = ;
> + #reset-cells = <1>;
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller@c00 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> + interrupt-controller;
> + reg = <0x0c00 0x4>, /* GICD */
> + <0x0c08 0x20>; /* GICR */
> +
> + interrupts = ;
> + };
> +
> +
Re: [PATCH 01/31] arm: mediatek: add support for MediaTek MT7986 SoC
Hi Daniel,
Thanks for the reminder.
I found more errornous line-breaks in other patches...
I'll find a way to fix that.
Best Regards,
Weijie
On Thu, 2022-08-04 at 10:37 +0200, Daniel Golle wrote:
> Hi Weijie,
>
> happy to see this series posted!
> Trying to apply it unfortunately fails due to errornous line-breaks,
> supposedly inserted by your MUA, see below.
>
> I didn't go beyond the first patch and it'd be nice if you report the
> whole series without the wrong line-breaks.
>
> Cheers
>
>
> Daniel
>
>
> On Thu, Aug 04, 2022 at 11:34:28AM +0800, Weijie Gao wrote:
> > This patch adds basic support for MediaTek MT7986 SoC.
> > This include the file that will initialize the SoC after boot and
> > its
> > device tree.
> >
> > Signed-off-by: Weijie Gao
> > ---
> > arch/arm/dts/mt7986-u-boot.dtsi | 33 ++
> > arch/arm/dts/mt7986.dtsi | 341
> > ++
> > arch/arm/mach-mediatek/Kconfig| 11 +
> > arch/arm/mach-mediatek/Makefile | 1 +
> > arch/arm/mach-mediatek/mt7986/Makefile| 4 +
> > arch/arm/mach-mediatek/mt7986/init.c | 53 +++
> > arch/arm/mach-mediatek/mt7986/lowlevel_init.S | 30 ++
> > 7 files changed, 473 insertions(+)
> > create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
> > create mode 100644 arch/arm/dts/mt7986.dtsi
> > create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
> > create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
> > create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
> >
> > diff --git a/arch/arm/dts/mt7986-u-boot.dtsi
> > b/arch/arm/dts/mt7986-u-boot.dtsi
>
> The above two lines should be a single line.
>
> > new file mode 100644
> > index 00..95671f8afa
> > --- /dev/null
> > +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> > @@ -0,0 +1,33 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2022 MediaTek Inc.
> > + * Author: Sam Shih
> > + */
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> > new file mode 100644
> > index 00..f235bd8b8c
> > --- /dev/null
> > +++ b/arch/arm/dts/mt7986.dtsi
> > @@ -0,0 +1,341 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2022 MediaTek Inc.
> > + * Author: Sam Shih
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/ {
> > + compatible = "mediatek,mt7986";
> > + interrupt-parent = <>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + config {
> > + u-boot,mmc-env-partition = "u-boot-env";
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cpu0: cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x0>;
> > + };
> > + cpu1: cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x1>;
> > + };
> > + cpu2: cpu@2 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x1>;
> > + };
> > + cpu3: cpu@3 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a53";
> > + reg = <0x1>;
> > + };
> > + };
> > +
> > + dummy_clk: dummy12m {
> > + compatible = "fixed-clock";
> > + clock-frequency = <1200>;
> > + #clock-cells = <0>;
> > + /* must need this line, or uart uanable to get
> > dummy_clk */
> > + u-boot,dm-pre-reloc;
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupt-parent = <>;
> > + clock-frequency = <1300>;
> > + interrupts = ,
> > +,
> > +,
> > +;
> > + arm,cpu-registers-not-fw-configured;
> > + };
> > +
> > + timer0: timer@10008000 {
> > + compatible = "mediatek,mt7986-timer";
> > + reg = <0x10008000 0x1000>;
> > + interrupts = ;
> > + clocks = < CK_INFRA_CK_F26M>;
> > + clock-names = "gpt-clk";
> > + u-boot,dm-pre-reloc;
> > + };
> > +
> > + watchdog: watchdog@1001c000 {
> > + compatible = "mediatek,mt7986-wdt";
> > + reg = <0x1001c000 0x1000>;
> > + interrupts = ;
> > + #reset-cells = <1>;
> > + status =
Re: [PATCH 2/2] ARM: imx6: dh-imx6: Enable d-cache early in SPL
On 8/4/22 10:15, Philip Oberfichtner wrote:
From: Marek Vasut
Enable d-cache early in SPL right after DRAM is started up.
This reduces U-Boot proper load time by 650ms when loaded
from SPI NOR.
Signed-off-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index e49e97724a..2c0ddc527a 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,11 +15,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -610,6 +613,20 @@ static void dhcom_spl_dram_init(void)
}
}
+void dram_bank_mmu_setup(int bank)
+{
+ int i;
+
+ set_section_dcache(ROMCP_ARB_BASE_ADDR >> MMU_SECTION_SHIFT,
DCACHE_DEFAULT_OPTION);
+ set_section_dcache(IRAM_BASE_ADDR >> MMU_SECTION_SHIFT,
DCACHE_DEFAULT_OPTION);
+
+ for (i = MMDC0_ARB_BASE_ADDR >> MMU_SECTION_SHIFT;
+ i < ((MMDC0_ARB_BASE_ADDR >> MMU_SECTION_SHIFT) +
+ (SZ_1G >> MMU_SECTION_SHIFT));
+ i++)
+ set_section_dcache(i, DCACHE_DEFAULT_OPTION);
+}
+
void board_init_f(ulong dummy)
{
/* setup AIPS and disable watchdog */
@@ -636,9 +653,19 @@ void board_init_f(ulong dummy)
/* DDR3 initialization */
dhcom_spl_dram_init();
+ /* Set up early MMU tables at the beginning of DRAM and start d-cache */
+ gd->arch.tlb_addr = MMDC0_ARB_BASE_ADDR + SZ_32M;
+ gd->arch.tlb_size = PGTABLE_SIZE;
+ enable_caches();
+
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
+
+void spl_board_prepare_for_boot(void)
+{
An explanation why this is needed in a comment would be good to have.
+ dcache_disable();
+}
[PATCH u-boot-marvell 1/3] arm64: a37xx: pinctrl: Fix definitions for MPP pins 20-22
All 3 MPP pins (20, 21 and 22) can be configured individually and also can
be configured to GPIO functions. Fix definitions for these MPP pins in
existing pin groups. After this change GPIO function can be enabled just
for one of these 3 pins.
Signed-off-by: Pali Rohár
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index bb7a76baed1f..a5407a16ee36 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -200,9 +200,11 @@ static struct armada_37xx_pin_group
armada_37xx_sb_groups[] = {
PIN_GRP_GPIO("pcie1", 3, 1, BIT(5), "pcie"), /* this actually controls
"pcie1_reset" */
PIN_GRP_GPIO("pcie1_clkreq", 4, 1, BIT(9), "pcie"),
PIN_GRP_GPIO("pcie1_wakeup", 5, 1, BIT(10), "pcie"),
- PIN_GRP_GPIO("ptp", 20, 3, BIT(11) | BIT(12) | BIT(13), "ptp"),
- PIN_GRP("ptp_clk", 21, 1, BIT(6), "ptp", "mii"),
- PIN_GRP("ptp_trig", 22, 1, BIT(7), "ptp", "mii"),
+ PIN_GRP_GPIO("ptp", 20, 1, BIT(11), "ptp"),
+ PIN_GRP_GPIO_3("ptp_clk", 21, 1, BIT(6) | BIT(12), 0, BIT(6), BIT(12),
+ "ptp", "mii"),
+ PIN_GRP_GPIO_3("ptp_trig", 22, 1, BIT(7) | BIT(13), 0, BIT(7), BIT(13),
+ "ptp", "mii"),
PIN_GRP_GPIO_3("mii_col", 23, 1, BIT(8) | BIT(14), 0, BIT(8), BIT(14),
"mii", "mii_err"),
};
--
2.20.1
[PATCH u-boot-marvell 3/3] arm64: a37xx: pinctrl: Improve description for pinmux command
In more cases group name consist of function name followed by function
number. So if function name is just prefix of group name, show group name.
So in 'pinmux status -a' command output would be visible also extended
function number, which is useful for debugging.
Signed-off-by: Pali Rohár
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 32b49f167c66..25fbe39abd19 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -406,7 +406,17 @@ static int armada_37xx_pmx_get_pin_muxing(struct udevice
*dev, unsigned int sele
for (f = 0; f < NB_FUNCS && grp->funcs[f]; f++) {
if (grp->val[f] == val) {
- strlcpy(buf, grp->funcs[f], size);
+ /*
+* In more cases group name consist of
+* function name followed by function
+* number. So if function name is just
+* prefix of group name, show group
name.
+*/
+ if (strncmp(grp->name, grp->funcs[f],
+ strlen(grp->funcs[f])) == 0)
+ strlcpy(buf, grp->name, size);
+ else
+ strlcpy(buf, grp->funcs[f],
size);
return 0;
}
}
--
2.20.1
[PATCH v2 1/2] ARM: cache: Allow SPL to build cache-pl310.c
Before this commit, the SPL could enable the PL310 L2 cache [1], but the cache maintenance functions from cache-pl310.c were only useable for non-SPL builds. After enabling the cache one must be able to flush it, too. Thus this commit allows cache-pl310.c to be included in the SPL build. [1] See for example arch/arm/mach-imx/cache.c: v7_outer_cache_enable() Signed-off-by: Philip Oberfichtner --- (no changes since v1) arch/arm/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index c603fe61bc..ac1d4245bb 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -33,7 +33,6 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o -obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o else obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o @@ -46,6 +45,7 @@ else obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o endif +obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += semihosting.o ifneq ($(filter y,$(CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR) $(CONFIG_SAVE_PREV_BL_FDT_ADDR)),) -- 2.37.1
[PATCH v2 2/2] ARM: imx6: dh-imx6: Enable d-cache early in SPL
From: Marek Vasut
Enable d-cache early in SPL right after DRAM is started up.
This reduces U-Boot proper load time by 650ms when loaded
from SPI NOR.
Signed-off-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
Changes in v2:
- Add comment to explain the relevance of dcache_disable()
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index e49e97724a..4b0e13493d 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,11 +15,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -610,6 +613,20 @@ static void dhcom_spl_dram_init(void)
}
}
+void dram_bank_mmu_setup(int bank)
+{
+ int i;
+
+ set_section_dcache(ROMCP_ARB_BASE_ADDR >> MMU_SECTION_SHIFT,
DCACHE_DEFAULT_OPTION);
+ set_section_dcache(IRAM_BASE_ADDR >> MMU_SECTION_SHIFT,
DCACHE_DEFAULT_OPTION);
+
+ for (i = MMDC0_ARB_BASE_ADDR >> MMU_SECTION_SHIFT;
+ i < ((MMDC0_ARB_BASE_ADDR >> MMU_SECTION_SHIFT) +
+ (SZ_1G >> MMU_SECTION_SHIFT));
+ i++)
+ set_section_dcache(i, DCACHE_DEFAULT_OPTION);
+}
+
void board_init_f(ulong dummy)
{
/* setup AIPS and disable watchdog */
@@ -636,9 +653,20 @@ void board_init_f(ulong dummy)
/* DDR3 initialization */
dhcom_spl_dram_init();
+ /* Set up early MMU tables at the beginning of DRAM and start d-cache */
+ gd->arch.tlb_addr = MMDC0_ARB_BASE_ADDR + SZ_32M;
+ gd->arch.tlb_size = PGTABLE_SIZE;
+ enable_caches();
+
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
+
+void spl_board_prepare_for_boot(void)
+{
+ /* Flush dcache. Without it U-Boot proper would hang at random
locations. */
+ dcache_disable();
+}
--
2.37.1
[PATCH] misc: atsha204a: Don't check for error when waking up the device
The device ignores any levels or transitions on the SCL pin when the device
is idle, asleep or during waking up.
Linux kernel driver for atsha204a (atmel-sha204a.ko) also ignores return
value from i2c wakeup send command, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/atmel-i2c.c?h=v5.19#n174
And also userspace Turris libatsha204 library ignores return value from
wakeup send command, see:
https://gitlab.nic.cz/turris/libatsha204/-/blob/v29.2/src/libatsha204/layer_ni2c.c#L75-76
U-Boot driver should do same thing.
Fixes waking up ATSHA204 on Turris 1.x boards.
Signed-off-by: Pali Rohár
---
drivers/misc/atsha204a-i2c.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/atsha204a-i2c.c b/drivers/misc/atsha204a-i2c.c
index 81ecb5b6177b..fa2d5948f128 100644
--- a/drivers/misc/atsha204a-i2c.c
+++ b/drivers/misc/atsha204a-i2c.c
@@ -103,12 +103,13 @@ int atsha204a_wakeup(struct udevice *dev)
for (try = 1; try <= 10; ++try) {
debug("Try %i... ", try);
+ /*
+* The device ignores any levels or transitions on the SCL pin
+* when the device is idle, asleep or during waking up.
+* Don't check for error when waking up the device.
+*/
memset(req, 0, 4);
- res = atsha204a_send(dev, req, 4);
- if (res) {
- debug("failed on I2C send, trying again\n");
- continue;
- }
+ atsha204a_send(dev, req, 4);
udelay(ATSHA204A_TWLO_US + ATSHA204A_TWHI_US);
--
2.20.1
Re: [PATCH] net: dwc_eth_qos: fix double resource leak in eqos_remove()
On 16/05/2022 02.26, Ramon Fried wrote: > On Wed, May 11, 2022 at 5:13 PM Rasmus Villemoes > wrote: >> >> Not only does eqos_remove() fail to free the buffers that have been >> allocated by eqos_probe_resources_core(), it repeats those allocations >> and thus drops twice as much memory on the floor. >> > Reviewed-by: Ramon Fried ping on this as well.
Re: [PATCH v2 1/2] ARM: cache: Allow SPL to build cache-pl310.c
On Thu, Aug 04, 2022 at 12:56:45PM +0200, Philip Oberfichtner wrote: > Before this commit, the SPL could enable the PL310 L2 cache [1], but the > cache maintenance functions from cache-pl310.c were only useable for > non-SPL builds. > > After enabling the cache one must be able to flush it, too. Thus this > commit allows cache-pl310.c to be included in the SPL build. > > [1] See for example arch/arm/mach-imx/cache.c: v7_outer_cache_enable() > > Signed-off-by: Philip Oberfichtner It should be rather direct to migrate this to Kconfig, please do that first, and introduce CONFIG_SPL_SYS_L2_PL310. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] ARM: cache: Allow SPL to build cache-pl310.c
On 8/4/22 11:19, Philip Oberfichtner wrote: [...] @@ -46,6 +45,7 @@ else obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o endif +obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o Doesn't this need SPL/TPL Kconfig symbols and obj-$(CONFIG_$(SPL_TPL_)SYS_L2_PL310) += cache-pl310.o ? CONFIG_SYS_L2_PL310 is not converted to Kconfig yet. And there is no CONFIG_SPL_ usage for it so far. So I'd say no. Please correct me if I'm wrong. I'm concerned whether applying this patch won't enable L2CC in SPL for boards where this could break things. There is a script to do the conversion to Kconfig easily, see doc/develop/moveconfig.rst . It might make sense to run it first, convert this symbol to Kconfig, and then add this patch second, and then enable SPL_...PL310 for this board only.
Re: [PATCH] net: dwc_eth_qos: lift parsing of max-speed DT property to common code
On 16/05/2022 02.27, Ramon Fried wrote: > On Wed, May 11, 2022 at 5:58 PM Rasmus Villemoes > wrote: >> >> I have an iMX8MP with a ti,dp83867 phy in front of the eqos >> interface. The phy is Gbit capable - however, the C and D differential >> pairs are not physically routed to the RJ45 connector. So I need to >> prevent the phy from advertising 1000Mbps. >> >> The necessary code is almost already there in the form of a >> phy_set_supported() call in eqos_start(), but the max-speed DT >> property is currently only parsed in >> eqos_probe_resources_stm32(). Lift that parsing to eqos_probe(). >> > Reviewed-by: Ramon Fried ping on this as well.
Re: [PATCH v2] gpio: aspeed: port Linux dt-bindings header file
Thanks. Reviewed-by: Billy Tsai On 2022/8/4, 9:02 AM, "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+ */ +/* + * 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
[PATCH v2 1/3] efi_loader: Add SPI I/O protocol support
This addition allows UEFI applications running under u-boot to access
peripherals on SPI busses. It is based on the UEFI Platform
Initialization (PI) Specification, Version 1.7 Errata A (April 2020).
Only the core functionality required to discover SPI peripherals and
communicate with them is currently implemented. Other functionality such
as the legacy SPI controller interface and the ability to update the SPI
peripheral object associated with a particular SPI I/O protocol object
is currently unimplemented.
Since there are no open source implementations of this protocol to use
as an example, educated guesses/hacks have been made in cases where the
UEFI PI specification is unclear and these are documented in comments.
This implementation has been tested on the SanCloud BBE Lite and allowed
a UEFI test application to successfully communicate with a Micron
Authenta flash device connected via the SPI bus. It has also been tested
with the sandbox target using the included efi_selftest case.
Signed-off-by: Paul Barker
---
MAINTAINERS | 7 +
arch/sandbox/dts/test.dts| 8 +
include/efi_loader.h | 4 +
include/efi_spi_protocol.h | 158 +
lib/efi_loader/Kconfig | 8 +
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_setup.c | 6 +
lib/efi_loader/efi_spi_protocol.c| 614 +++
lib/efi_selftest/Makefile| 1 +
lib/efi_selftest/efi_selftest_spi_protocol.c | 237 +++
10 files changed, 1044 insertions(+)
create mode 100644 include/efi_spi_protocol.h
create mode 100644 lib/efi_loader/efi_spi_protocol.c
create mode 100644 lib/efi_selftest/efi_selftest_spi_protocol.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4d1930f76e44..1b5d9c37576b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -856,6 +856,13 @@ F: tools/efivar.py
F: tools/file2include.c
F: tools/mkeficapsule.c
+EFI SPI SUPPORT
+M: Paul Barker
+S: Maintained
+F: include/efi_spi_protocol.h
+F: lib/efi_loader/efi_spi_protocol.c
+F: lib/efi_selftest/efi_selftest_spi_protocol.c
+
EFI VARIABLES VIA OP-TEE
M: Ilias Apalodimas
S: Maintained
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index d1a8cc7bfb7e..5ac59140b748 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1185,6 +1185,10 @@
compatible = "spansion,m25p16", "jedec,spi-nor";
spi-max-frequency = <4000>;
sandbox,filename = "spi.bin";
+
+ uefi-spi-vendor = "spansion";
+ uefi-spi-part-number = "mt25p16";
+ uefi-spi-io-guid = [5deb81b8 92ad 484a 8fdd
fa75a8e4c6b8];
};
spi.bin@1 {
reg = <1>;
@@ -1193,6 +1197,10 @@
sandbox,filename = "spi.bin";
spi-cpol;
spi-cpha;
+
+ uefi-spi-vendor = "spansion";
+ uefi-spi-part-number = "mt25p16";
+ uefi-spi-io-guid = [cd9eb3b6 1f2b 43a6 b8d7
3192d7cf7270];
};
};
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3a63a1f75fdf..2eb96b08205b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -537,6 +537,10 @@ efi_status_t efi_rng_register(void);
efi_status_t efi_tcg2_register(void);
/* Called by efi_init_obj_list() to install RISCV_EFI_BOOT_PROTOCOL */
efi_status_t efi_riscv_register(void);
+/* Called by efi_init_obj_list() to install EFI_SPI_CONFIGURATION_PROTOCOL &
+ * EFI_SPI_IO_PROTOCOL
+ */
+efi_status_t efi_spi_protocol_register(void);
/* Called by efi_init_obj_list() to do initial measurement */
efi_status_t efi_tcg2_do_initial_measurement(void);
/* measure the pe-coff image, extend PCR and add Event Log */
diff --git a/include/efi_spi_protocol.h b/include/efi_spi_protocol.h
new file mode 100644
index ..1a4456bd9349
--- /dev/null
+++ b/include/efi_spi_protocol.h
@@ -0,0 +1,158 @@
+/* SPDX-License-Identifier: BSD-2-Clause-Patent */
+/*
+ * Copyright (c) 2017, Intel Corporation. All rights reserved.
+ */
+
+#ifndef _EFI_SPI_PROTOCOL_H
+#define _EFI_SPI_PROTOCOL_H
+
+#include
+#include
+
+#define EFI_SPI_CONFIGURATION_GUID \
+ EFI_GUID(0x85a6d3e6, 0xb65b, 0x4afc, \
+0xb3, 0x8f, 0xc6, 0xd5, 0x4a, 0xf6, 0xdd, 0xc8)
+
+struct efi_spi_peripheral;
+
+struct efi_spi_part {
+ efi_string_t vendor;
+ efi_string_t part_number;
+ u32 min_clock_hz;
+ u32 max_clock_hz;
+ bool chip_select_polarity;
+};
+
+struct efi_spi_bus {
+ efi_string_t friendly_name;
+ struct efi_spi_peripheral *peripheral_list;
+ struct efi_device_path *controller_path;
+
+ efi_status_t
+ (EFIAPI * clock)(const struct
[PATCH v2 3/3] am335x_evm_defconfig: Enable Micron SPI flash support
Signed-off-by: Paul Barker --- configs/am335x_evm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index b500ed0fdd8d..4984d66dc1ce 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -92,6 +92,7 @@ CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y CONFIG_SYS_NAND_U_BOOT_OFFS=0xc CONFIG_DM_SPI_FLASH=y CONFIG_SF_DEFAULT_SPEED=2400 +CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_PHY_ATHEROS=y CONFIG_PHY_SMSC=y -- 2.25.1
[PATCH v2 0/3] Support UEFI SPI I/O protocol
These patches add support for the UEFI SPI I/O protocol defined in the UEFI Platform Initialization (PI) Specification, Version 1.7 Errata A (April 2020). This allows a UEFI application to interact with devices on the SPI bus. The code here is self-contained and easy to enable/disable at compile time. Compilation testing with am335x_evm_defconfig shows that the size of u-boot.img increases by less than 2kB when CONFIG_EFI_SPI_PROTOCOL is enabled. Changes since v1: * Do not enable CONFIG_EFI_SPI_PROTOCOL by default. * Add efi_seltest unit test. * Mark functions with EFIAPI where necessary. * Handle debug_transaction argument to efi_spi_io_transaction(). * Handle a value of zero for target->max_read_size & target->max_write_size. * Probe inactive SPI devices when initializing the EFI SPI protocol to ensure that dev_get_parent_priv() returns valid data and the exported devices are ready to use. * Skip emulated SPI peripherals. These appear as duplicates within the list of devices on the bus when using the sandbox SPI drivers. * Make most printf statements debug only. Paul Barker (3): efi_loader: Add SPI I/O protocol support arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export am335x_evm_defconfig: Enable Micron SPI flash support MAINTAINERS | 7 + arch/arm/dts/am335x-sancloud-bbe-lite.dts| 8 +- arch/sandbox/dts/test.dts| 8 + configs/am335x_evm_defconfig | 1 + include/efi_loader.h | 4 + include/efi_spi_protocol.h | 158 + lib/efi_loader/Kconfig | 8 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_setup.c | 6 + lib/efi_loader/efi_spi_protocol.c| 614 +++ lib/efi_selftest/Makefile| 1 + lib/efi_selftest/efi_selftest_spi_protocol.c | 237 +++ 12 files changed, 1051 insertions(+), 2 deletions(-) create mode 100644 include/efi_spi_protocol.h create mode 100644 lib/efi_loader/efi_spi_protocol.c create mode 100644 lib/efi_selftest/efi_selftest_spi_protocol.c base-commit: 707b17f64e71fad1615ea25082f2e928f712e366 -- 2.25.1
[PATCH v2 2/3] arm: dts: am335x-sancloud-bbe-lite: UEFI SPI export
Add properties to the Authenta SPI flash device node to enable access by
a UEFI application using a fixed GUID. Also specify that this device is
JEDEC compatible so that it is correctly initialized when running
`sf probe`.
Signed-off-by: Paul Barker
---
arch/arm/dts/am335x-sancloud-bbe-lite.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/am335x-sancloud-bbe-lite.dts
b/arch/arm/dts/am335x-sancloud-bbe-lite.dts
index d6ef19311a91..01866f3c3ff7 100644
--- a/arch/arm/dts/am335x-sancloud-bbe-lite.dts
+++ b/arch/arm/dts/am335x-sancloud-bbe-lite.dts
@@ -37,14 +37,18 @@
pinctrl-names = "default";
pinctrl-0 = <_spi0_pins>;
- channel@0 {
+ authenta-flash@0 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "micron,spi-authenta";
+ compatible = "micron,spi-authenta", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <1600>;
spi-cpha;
+
+ uefi-spi-vendor = "micron";
+ uefi-spi-part-number = "mt25ql128abb";
+ uefi-spi-io-guid = [30671277 caa4 8643 b341 881fe18e7f7d];
};
};
--
2.25.1
[PATCH u-boot-marvell 2/3] arm64: a37xx: pinctrl: Remove unused macro PIN_GRP()
Macro PIN_GRP() is not used, remove it.
Signed-off-by: Pali Rohár
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index a5407a16ee36..32b49f167c66 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -99,16 +99,6 @@ struct armada_37xx_pinctrl {
unsigned intnfuncs;
};
-#define PIN_GRP(_name, _start, _nr, _mask, _func1, _func2) \
- { \
- .name = _name, \
- .start_pin = _start,\
- .npins = _nr, \
- .reg_mask = _mask, \
- .val = {0, _mask}, \
- .funcs = {_func1, _func2} \
- }
-
#define PIN_GRP_GPIO_0(_name, _start, _nr) \
{ \
.name = _name, \
--
2.20.1
Re: [PATCH 0/3] dwc_eth_qos PHY dt node fixups
On 12/05/2022 09.33, Rasmus Villemoes wrote: > I need the dwc_eth_qos to gain a fix similar to what fec_mxc got in > 89b5bd54c1a4. > > The first patch provides a simplification around the logic for > fetching the phy's address, so there's one less case to worry about. > > The second introduces a little helper (it doesn't essentially add any > extra code since it just returns an extra piece of inforamtion that > eth_phy_get_node() already found). > > And the third hooks it up in the dwc_eth_qos driver. ping... any chance these could get picked up? 1 and 3 has an R-b from Ramon, and I don't think 2 should be controversial. Rasmus
[PATCH v3] gpio: aspeed: port Linux dt-bindings header file
Makes it easier to add readable GPIO definitions in DTS files for Aspeed SOC based boards. Ported with small edits to add IBM copyright statement and fix for checkpatch warning. Signed-off-by: Dhananjay Phadke Reviewed-by: Billy Tsai Acked-by: Chia-Wei Wang --- include/dt-bindings/gpio/aspeed-gpio.h | 51 ++ 1 file changed, 51 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..a49f5d5b5a --- /dev/null +++ b/include/dt-bindings/gpio/aspeed-gpio.h @@ -0,0 +1,51 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2022 IBM Corp. + * + * 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 v2] gpio: aspeed: port Linux dt-bindings header file
On 8/3/2022 7:35 PM, Joel Stanley wrote: 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. It would have been nicer to assert copyrights in kernel source itself, so that it would have been inherited instead of inserting here. For now, will send v3 with just that. Thanks, Dhananjay
Re: [PATCH 15/31] watchdog: mediatek: add support for MediaTek MT7986 SoC
On Wed, 3 Aug 2022 at 21:37, Weijie Gao wrote: > > 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(+) Reviewed-by: Simon Glass
Re: [PATCH 14/31] timer: mtk: add support for MediaTek MT7981/MT7986 SoCs
On Wed, 3 Aug 2022 at 21:37, Weijie Gao wrote: > > This patch add general-purpose timer support for MediaTek MT7981/MT7986. > These two SoCs uses a newer version of timer with its register definition > slightly changed. > > Signed-off-by: Weijie Gao > --- > drivers/timer/mtk_timer.c | 59 --- > 1 file changed, 37 insertions(+), 22 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards
On Wed, 3 Aug 2022 at 21:35, Weijie Gao wrote: > > This patch adds general board files based on MT7986 SoCs. > > The SD/eMMC controller on MT7986A and MT7986B have different pin > configurations so that four different reference board configs has to be > added. > > Signed-off-by: Weijie Gao > --- > 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 > Reviewed-by: Simon Glass
Re: [PATCH 02/31] arm: mediatek: add support for MediaTek MT7981 SoC
Hi Weijie,
On Wed, 3 Aug 2022 at 21:35, Weijie Gao wrote:
>
> 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/mach-mediatek/mt7981/init.c
> b/arch/arm/mach-mediatek/mt7981/init.c
> new file mode 100644
> index 00..f503bb804b
> --- /dev/null
> +++ b/arch/arm/mach-mediatek/mt7981/init.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +#include
Do you need that?
> +#include
> +#include
Move up one
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int print_cpuinfo(void)
Can you use the CPU uclass and DISPLAY_CPUINFO instead/
> +{
> + printf("CPU: MediaTek MT7981\n");
> + return 0;
> +}
> +
[..]
> diff --git a/arch/arm/mach-mediatek/mt7981/lowlevel_init.S
> b/arch/arm/mach-mediatek/mt7981/lowlevel_init.S
> new file mode 100644
> index 00..244d2c1385
> --- /dev/null
> +++ b/arch/arm/mach-mediatek/mt7981/lowlevel_init.S
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +/*
> + * Switch from AArch64 EL2 to AArch32 EL2
> + * @param inputs:
> + * x0: argument, zero
> + * x1: machine nr
> + * x2: fdt address
> + * x3: input argument
> + * x4: kernel entry point
> + * @param outputs for secure firmware:
> + * x0: function id
> + * x1: kernel entry point
> + * x2: machine nr
> + * x3: fdt address
> +*/
> +
> +.global armv8_el2_to_aarch32
> +armv8_el2_to_aarch32:
> + mov x3, x2
> + mov x2, x1
> + mov x1, x4
> + mov x4, #0
> + ldr x0, =0x82000200
Please comment or add a symbol for this
> + SMC #0
> + ret
> --
> 2.17.1
>
Regards,
Simon
Re: [PATCH 13/31] pwm: mtk: add support for MediaTek MT7981 SoC
On Wed, 3 Aug 2022 at 21:37, Weijie Gao wrote: > > 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(-) Reviewed-by: Simon Glass
Re: [PATCH 12/31] pwm: mtk: add support for MediaTek MT7986 SoC
On Wed, 3 Aug 2022 at 21:37, Weijie Gao wrote: > > 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(+) Reviewed-by: Simon Glass
Re: [PATCH 23/31] clk: mediatek: add support to configure clock driver parent
On Wed, 3 Aug 2022 at 21:39, Weijie Gao wrote: > > 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(-) > Reviewed-by: Simon Glass
Re: [PATCH 11/31] arm: dts: mt7622: force high-speed mode for uart
On Wed, 3 Aug 2022 at 21:37, Weijie Gao wrote: > > The input clock for uart is too slow (25MHz) which introduces frequent data > error on both receiving and transmitting even if the baudrate is 115200. > > Using high-speed can significantly solve this issue. > > Signed-off-by: Weijie Gao > --- > arch/arm/dts/mt7622.dtsi | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass
Re: [PATCH 25/31] clk: mediatek: add CLK_XTAL support for clock driver
Hi Weijie, On Wed, 3 Aug 2022 at 21:40, Weijie Gao wrote: > > 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; Please document the fall-through here, if it is not a bug. > 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 > REgards, Simon
Re: [PATCH 28/31] tools: mtk_image: split gfh header verification into a new function
On Wed, 3 Aug 2022 at 21:40, Weijie Gao wrote: > > The verification code of gfh header for NAND and non-NAND are identical. > It's better to define a individual function to reduce redundancy. > > Signed-off-by: Weijie Gao > --- > tools/mtk_image.c | 51 +++ > 1 file changed, 21 insertions(+), 30 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 21/31] pinctrl: mediatek: add pinctrl driver for MT7986 SoC
On Wed, 3 Aug 2022 at 21:39, Weijie Gao wrote: > > 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 Reviewed-by: Simon Glass
Re: [PATCH 20/31] pinctrl: mediatek: add pinctrl driver for MT7981 SoC
On Wed, 3 Aug 2022 at 21:39, Weijie Gao wrote: > > 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 Reviewed-by: Simon Glass
Re: Submitting patches
+Tom Rini Hi Martin, On Thu, 4 Aug 2022 at 00:22, Martin Bonner wrote: > > 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. That's good to hear! In my .gitconfig I have: [sendemail] smtpserver = smtp.gmail.com smtpserverport = 587 smtpencryption = tls smtpuser = s...@chromium.org smtppass = confirm = always where is the long 'application-specific password' generated here: https://myaccount.google.com/security (click on 'App passwords') > >> 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. Perhaps create an internal web page describing the problem and its workarounds. Make sure your boss and everyone else knows the problem and its impact on your work and ability to collaborate. Be specific about what is actually blocking you and see if there is a simple solution that doesn't affect security too much. Point people to your page when they want to do the same thing. > > 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. I wasn't aware of that. I do recall years ago an email system where you had to use MS Word to edit your emails though! >> >> >> > >> > 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? U-Boot is on github, but it is a mirror. I have thought about setting up gerrit service as I think it would be convenient for reviews, but so far as I know it doesn't support larger projects like U-Boot with multiple maintainers. I believe people have worked on email integration, but I'm not sure how well it works. How much time and effort are you willing to put into this? Regards, Simon
Re: [PATCH 31/31] MAINTAINERS: update maintainer for MediaTek ARM platform
On Wed, 3 Aug 2022 at 21:41, Weijie Gao wrote: > > Add new filed for MediaTek ARM platform files > > Signed-off-by: Weijie Gao > --- > MAINTAINERS | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH 05/31] mmc: mediatek: add support for MediaTek MT7891/MT7986 SoCs
Hi Weijie, On Wed, 3 Aug 2022 at 21:35, Weijie Gao wrote: > > This patch adds eMMC and SDXC support for MediaTek MT7981/MT7986 SoCs Add eMMC and SDXC support for MediaTek MT7981/MT7986 SoCs. (describe your changes in imperative mood) > > Signed-off-by: Weijie Gao > --- > drivers/mmc/mtk-sd.c | 68 ++-- > 1 file changed, 53 insertions(+), 15 deletions(-) > Reviewed-by: Simon Glass Regards, Simon
[PATCH 09/13] pmic: Convert pm8916 driver to a generic Qcom PMIC driver
Since both pm8916.c and pm8916_gpio.c are already supporting multiple
Qcom SoCs, it makes sense to rename these drivers to pmic_qcom.c and
qcom_pmic_gpio.c respectively. Also, these driver can be extended to
support additional functionality if required for other Qcom SoCs.
Along with this import latest DT binding: qcom,spmi-pmic.txt from Linux
kernel and thereby remove pm8916.txt.
Signed-off-by: Sumit Garg
---
configs/dragonboard410c_defconfig | 4 +-
configs/dragonboard820c_defconfig | 4 +-
configs/dragonboard845c_defconfig | 4 +-
configs/sandbox64_defconfig | 4 +-
configs/sandbox_defconfig | 4 +-
configs/sandbox_flattree_defconfig| 4 +-
configs/sandbox_noinst_defconfig | 4 +-
configs/sandbox_spl_defconfig | 4 +-
configs/sandbox_vpl_defconfig | 4 +-
configs/starqltechn_defconfig | 4 +-
doc/device-tree-bindings/pmic/pm8916.txt | 18 ---
.../pmic/qcom,spmi-pmic.txt | 94 +++
drivers/gpio/Kconfig | 10 +-
drivers/gpio/Makefile | 2 +-
.../gpio/{pm8916_gpio.c => qcom_pmic_gpio.c} | 108 +-
drivers/power/pmic/Kconfig| 8 +-
drivers/power/pmic/Makefile | 2 +-
drivers/power/pmic/{pm8916.c => pmic_qcom.c} | 42 +++
18 files changed, 200 insertions(+), 124 deletions(-)
delete mode 100644 doc/device-tree-bindings/pmic/pm8916.txt
create mode 100644 doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
rename drivers/gpio/{pm8916_gpio.c => qcom_pmic_gpio.c} (67%)
rename drivers/power/pmic/{pm8916.c => pmic_qcom.c} (52%)
diff --git a/configs/dragonboard410c_defconfig
b/configs/dragonboard410c_defconfig
index 2bf759d843..fa6476ed1a 100644
--- a/configs/dragonboard410c_defconfig
+++ b/configs/dragonboard410c_defconfig
@@ -43,7 +43,7 @@ CONFIG_FASTBOOT_BUF_ADDR=0x9100
CONFIG_FASTBOOT_FLASH=y
CONFIG_FASTBOOT_FLASH_MMC_DEV=0
CONFIG_MSM_GPIO=y
-CONFIG_PM8916_GPIO=y
+CONFIG_QCOM_PMIC_GPIO=y
CONFIG_LED=y
CONFIG_LED_GPIO=y
CONFIG_MMC_SDHCI=y
@@ -52,7 +52,7 @@ CONFIG_PHY=y
CONFIG_PINCTRL=y
CONFIG_PINCONF=y
CONFIG_DM_PMIC=y
-CONFIG_PMIC_PM8916=y
+CONFIG_PMIC_QCOM=y
CONFIG_MSM_SERIAL=y
CONFIG_SPMI_MSM=y
CONFIG_USB=y
diff --git a/configs/dragonboard820c_defconfig
b/configs/dragonboard820c_defconfig
index 2ede13fed1..6b4483bf69 100644
--- a/configs/dragonboard820c_defconfig
+++ b/configs/dragonboard820c_defconfig
@@ -36,12 +36,12 @@ CONFIG_ENV_EXT4_INTERFACE="mmc"
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_CLK=y
-CONFIG_PM8916_GPIO=y
+CONFIG_QCOM_PMIC_GPIO=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_MSM=y
CONFIG_PINCTRL=y
CONFIG_PINCONF=y
CONFIG_DM_PMIC=y
-CONFIG_PMIC_PM8916=y
+CONFIG_PMIC_QCOM=y
CONFIG_MSM_SERIAL=y
CONFIG_SPMI_MSM=y
diff --git a/configs/dragonboard845c_defconfig
b/configs/dragonboard845c_defconfig
index cf1a1d25cf..a69d82761a 100644
--- a/configs/dragonboard845c_defconfig
+++ b/configs/dragonboard845c_defconfig
@@ -20,10 +20,10 @@ CONFIG_CMD_GPIO=y
# CONFIG_NET is not set
CONFIG_CLK=y
CONFIG_MSM_GPIO=y
-CONFIG_PM8916_GPIO=y
+CONFIG_QCOM_PMIC_GPIO=y
CONFIG_PINCTRL=y
CONFIG_DM_PMIC=y
-CONFIG_PMIC_PM8916=y
+CONFIG_PMIC_QCOM=y
CONFIG_MSM_GENI_SERIAL=y
CONFIG_SPMI_MSM=y
CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 6553568e76..537495d159 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -127,7 +127,7 @@ CONFIG_FASTBOOT_FLASH=y
CONFIG_FASTBOOT_FLASH_MMC_DEV=0
CONFIG_GPIO_HOG=y
CONFIG_DM_GPIO_LOOKUP_LABEL=y
-CONFIG_PM8916_GPIO=y
+CONFIG_QCOM_PMIC_GPIO=y
CONFIG_SANDBOX_GPIO=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_I2C_CROS_EC_LDO=y
@@ -179,7 +179,7 @@ CONFIG_DM_PMIC=y
CONFIG_PMIC_ACT8846=y
CONFIG_DM_PMIC_PFUZE100=y
CONFIG_DM_PMIC_MAX77686=y
-CONFIG_PMIC_PM8916=y
+CONFIG_PMIC_QCOM=y
CONFIG_PMIC_RK8XX=y
CONFIG_PMIC_S2MPS11=y
CONFIG_DM_PMIC_SANDBOX=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 572cf8edd8..72a7b5bb76 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -169,7 +169,7 @@ CONFIG_FASTBOOT_FLASH=y
CONFIG_FASTBOOT_FLASH_MMC_DEV=0
CONFIG_GPIO_HOG=y
CONFIG_DM_GPIO_LOOKUP_LABEL=y
-CONFIG_PM8916_GPIO=y
+CONFIG_QCOM_PMIC_GPIO=y
CONFIG_SANDBOX_GPIO=y
CONFIG_DM_HWSPINLOCK=y
CONFIG_HWSPINLOCK_SANDBOX=y
@@ -230,7 +230,7 @@ CONFIG_PMIC_ACT8846=y
CONFIG_DM_PMIC_PFUZE100=y
CONFIG_DM_PMIC_MAX77686=y
CONFIG_DM_PMIC_MC34708=y
-CONFIG_PMIC_PM8916=y
+CONFIG_PMIC_QCOM=y
CONFIG_PMIC_RK8XX=y
CONFIG_PMIC_S2MPS11=y
CONFIG_DM_PMIC_SANDBOX=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index a71ce77c40..a8aeedc75c 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -99,7 +99,7 @@ CONFIG_DM_DEMO_SHAPE=y
[PATCH 11/13] dts: qcs404-evb: Add PMIC GPIO controller node
PMIC GPIOs are special GPIOs which are accessible through SPMI bus. So
add corresponding DT nodes.
Signed-off-by: Sumit Garg
---
arch/arm/dts/qcs404-evb.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 2e3a0c6958..0639af8fe3 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -168,6 +168,31 @@
maximum-speed = "high-speed";
};
};
+
+ spmi@200f000 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0x200f000 0x1000
+ 0x240 0x40
+ 0x2c0 0x40>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ pms405_0: pms405@0 {
+ compatible = "qcom,spmi-pmic";
+ reg = <0x0 0x1>;
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+
+ pms405_gpios: pms405_gpios@c000 {
+ compatible = "qcom,pms405-gpio";
+ reg = <0xc000 0x400>;
+ gpio-controller;
+ gpio-count = <12>;
+ #gpio-cells = <2>;
+ gpio-bank-name="pmic";
+ };
+ };
+ };
};
};
--
2.25.1
[PATCH 12/13] board: qcs404-evb: Enable USB3 specific PMIC GPIO
For USB3 host controller to detect devices on the bus it is required to
enable a PMIC GPIO: usb_vbus_boost_pin. So enable that during board
specific initialization.
And since this PMIC GPIO parsing is quite u-boot specific, so add a
DT override to qcs404-evb-uboot.dtsi to represent usb_vbus_boost_pin.
Signed-off-by: Sumit Garg
---
arch/arm/dts/qcs404-evb-uboot.dtsi | 6 ++
board/qualcomm/qcs404-evb/qcs404-evb.c | 29 ++
2 files changed, 35 insertions(+)
diff --git a/arch/arm/dts/qcs404-evb-uboot.dtsi
b/arch/arm/dts/qcs404-evb-uboot.dtsi
index c18080a483..c73d71e8c7 100644
--- a/arch/arm/dts/qcs404-evb-uboot.dtsi
+++ b/arch/arm/dts/qcs404-evb-uboot.dtsi
@@ -22,3 +22,9 @@
};
};
};
+
+_gpios {
+ usb_vbus_boost_pin {
+ gpios = <_gpios 2 0>;
+ };
+};
diff --git a/board/qualcomm/qcs404-evb/qcs404-evb.c
b/board/qualcomm/qcs404-evb/qcs404-evb.c
index f1e6e7f7eb..249dca7e72 100644
--- a/board/qualcomm/qcs404-evb/qcs404-evb.c
+++ b/board/qualcomm/qcs404-evb/qcs404-evb.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,34 @@ int dram_init(void)
int board_init(void)
{
+ struct udevice *pmic_gpio;
+ struct gpio_desc usb_vbus_boost_pin;
+ int ret, node;
+
+ ret = uclass_get_device_by_name(UCLASS_GPIO,
+ "pms405_gpios@c000",
+ _gpio);
+ if (ret < 0) {
+ printf("Failed to find pms405_gpios@c000 node.\n");
+ return ret;
+ }
+
+ node = fdt_subnode_offset(gd->fdt_blob, dev_of_offset(pmic_gpio),
+ "usb_vbus_boost_pin");
+ if (node < 0) {
+ printf("Failed to find usb_hub_reset_pm dt node.\n");
+ return node;
+ }
+ ret = gpio_request_by_name_nodev(offset_to_ofnode(node), "gpios", 0,
+_vbus_boost_pin, 0);
+ if (ret < 0) {
+ printf("Failed to request usb_hub_reset_pm gpio.\n");
+ return ret;
+ }
+
+ dm_gpio_set_dir_flags(_vbus_boost_pin,
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+
return 0;
}
--
2.25.1
[PATCH 10/13] gpio: qcom_pmic: Add support for GPIO LV/MV subtype
GPIO LV (low voltage)/MV (medium voltage) subtypes have different
features and register mappings than 4CH/8CH subtypes. Add support
for LV and MV subtypes.
With GPIO LV/MV subtype available, add "qcom,pms405-gpio" compatible
which requires support for GPIO MV subtype.
Signed-off-by: Sumit Garg
---
drivers/gpio/qcom_pmic_gpio.c | 96 +++
1 file changed, 76 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index e9232a007f..3be1be8692 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -23,6 +23,15 @@
#define REG_TYPE 0x4
#define REG_SUBTYPE0x5
+/* GPIO peripheral type and subtype out_values */
+#define REG_TYPE_VAL 0x10
+#define REG_SUBTYPE_GPIO_4CH 0x1
+#define REG_SUBTYPE_GPIOC_4CH 0x5
+#define REG_SUBTYPE_GPIO_8CH 0x9
+#define REG_SUBTYPE_GPIOC_8CH 0xd
+#define REG_SUBTYPE_GPIO_LV0x10
+#define REG_SUBTYPE_GPIO_MV0x11
+
#define REG_STATUS 0x08
#define REG_STATUS_VAL_MASK0x1
@@ -33,6 +42,10 @@
#define REG_CTL_MODE_INOUT 0x20
#define REG_CTL_MODE_OUTPUT 0x10
#define REG_CTL_OUTPUT_MASK 0x0F
+#define REG_CTL_LV_MV_MODE_MASK0x3
+#define REG_CTL_LV_MV_MODE_INPUT 0x0
+#define REG_CTL_LV_MV_MODE_INOUT 0x2
+#define REG_CTL_LV_MV_MODE_OUTPUT 0x1
#define REG_DIG_VIN_CTL0x41
#define REG_DIG_VIN_VIN0 0
@@ -40,6 +53,10 @@
#define REG_DIG_PULL_CTL 0x42
#define REG_DIG_PULL_NO_PU 0x5
+#define REG_LV_MV_OUTPUT_CTL 0x44
+#define REG_LV_MV_OUTPUT_CTL_MASK 0x80
+#define REG_LV_MV_OUTPUT_CTL_SHIFT 7
+
#define REG_DIG_OUT_CTL0x45
#define REG_DIG_OUT_CTL_CMOS (0x0 << 4)
#define REG_DIG_OUT_CTL_DRIVE_L 0x1
@@ -49,6 +66,7 @@
struct qcom_gpio_bank {
uint32_t pid; /* Peripheral ID on SPMI bus */
+ bool lv_mv_type; /* If subtype is GPIO_LV(0x10) or GPIO_MV(0x11) */
};
static int qcom_gpio_set_direction(struct udevice *dev, unsigned offset,
@@ -56,6 +74,7 @@ static int qcom_gpio_set_direction(struct udevice *dev,
unsigned offset,
{
struct qcom_gpio_bank *priv = dev_get_priv(dev);
uint32_t gpio_base = priv->pid + REG_OFFSET(offset);
+ uint32_t reg_ctl_val;
int ret;
/* Disable the GPIO */
@@ -64,16 +83,31 @@ static int qcom_gpio_set_direction(struct udevice *dev,
unsigned offset,
if (ret < 0)
return ret;
- /* Select the mode */
- if (input)
- ret = pmic_reg_write(dev->parent, gpio_base + REG_CTL,
-REG_CTL_MODE_INPUT);
- else
- ret = pmic_reg_write(dev->parent, gpio_base + REG_CTL,
-REG_CTL_MODE_INOUT | (value ? 1 : 0));
+ /* Select the mode and output */
+ if (priv->lv_mv_type) {
+ if (input)
+ reg_ctl_val = REG_CTL_LV_MV_MODE_INPUT;
+ else
+ reg_ctl_val = REG_CTL_LV_MV_MODE_INOUT;
+ } else {
+ if (input)
+ reg_ctl_val = REG_CTL_MODE_INPUT;
+ else
+ reg_ctl_val = REG_CTL_MODE_INOUT | !!value;
+ }
+
+ ret = pmic_reg_write(dev->parent, gpio_base + REG_CTL, reg_ctl_val);
if (ret < 0)
return ret;
+ if (priv->lv_mv_type && !input) {
+ ret = pmic_reg_write(dev->parent,
+gpio_base + REG_LV_MV_OUTPUT_CTL,
+!!value << REG_LV_MV_OUTPUT_CTL_SHIFT);
+ if (ret < 0)
+ return ret;
+ }
+
/* Set the right pull (no pull) */
ret = pmic_reg_write(dev->parent, gpio_base + REG_DIG_PULL_CTL,
REG_DIG_PULL_NO_PU);
@@ -118,19 +152,30 @@ static int qcom_gpio_get_function(struct udevice *dev,
unsigned offset)
uint32_t gpio_base = priv->pid + REG_OFFSET(offset);
int reg;
- /* Set the output value of the gpio */
reg = pmic_reg_read(dev->parent, gpio_base + REG_CTL);
if (reg < 0)
return reg;
- switch (reg & REG_CTL_MODE_MASK) {
- case REG_CTL_MODE_INPUT:
- return GPIOF_INPUT;
- case REG_CTL_MODE_INOUT: /* Fallthrough */
- case REG_CTL_MODE_OUTPUT:
- return GPIOF_OUTPUT;
- default:
- return GPIOF_UNKNOWN;
+ if (priv->lv_mv_type) {
+ switch (reg & REG_CTL_LV_MV_MODE_MASK) {
+ case REG_CTL_LV_MV_MODE_INPUT:
+ return GPIOF_INPUT;
+ case REG_CTL_LV_MV_MODE_INOUT: /* Fallthrough */
+ case REG_CTL_LV_MV_MODE_OUTPUT:
+ return GPIOF_OUTPUT;
+ default:
+ return GPIOF_UNKNOWN;
+ }
+ } else {
+
[PATCH 08/13] dts: qcs404-evb: Add USB controller and PHY nodes
QCS404 SoC provides support for two USB controllers: one USB3 and the
other one being USB2. The USB3 controller supports further 2 PHY: one high
speed PHY and the other super speed PHY. The USB2 controller supports a
single high speed PHY. So add corresponding DT nodes.
Signed-off-by: Sumit Garg
---
arch/arm/dts/qcs404-evb.dts | 87 +
1 file changed, 87 insertions(+)
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 1b280efff6..2e3a0c6958 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -52,6 +52,7 @@
reg = <0x180 0x8>;
#address-cells = <0x1>;
#size-cells = <0x0>;
+ #clock-cells = <1>;
};
reset: gcc-reset@180 {
@@ -81,6 +82,92 @@
mmc-ddr-1_8v;
mmc-hs400-1_8v;
};
+
+ usb3_phy: phy@78000 {
+ compatible = "qcom,usb-ss-28nm-phy";
+ #phy-cells = <0>;
+ reg = <0x78000 0x400>;
+ clocks = < GCC_USB_HS_PHY_CFG_AHB_CLK>,
+< GCC_USB3_PHY_PIPE_CLK>;
+ clock-names = "ahb", "pipe";
+ resets = < GCC_USB3_PHY_BCR>,
+< GCC_USB3PHY_PHY_BCR>;
+ reset-names = "com", "phy";
+ };
+
+ usb2_phy_prim: phy@7a000 {
+ compatible = "qcom,usb-hs-28nm-femtophy";
+ #phy-cells = <0>;
+ reg = <0x7a000 0x200>;
+ clocks = < GCC_USB_HS_PHY_CFG_AHB_CLK>,
+< GCC_USB2A_PHY_SLEEP_CLK>;
+ clock-names = "ahb", "sleep";
+ resets = < GCC_USB_HS_PHY_CFG_AHB_BCR>,
+< GCC_USB2A_PHY_BCR>;
+ reset-names = "phy", "por";
+ };
+
+ usb2_phy_sec: phy@7c000 {
+ compatible = "qcom,usb-hs-28nm-femtophy";
+ #phy-cells = <0>;
+ reg = <0x7c000 0x200>;
+ clocks = < GCC_USB_HS_PHY_CFG_AHB_CLK>,
+< GCC_USB2A_PHY_SLEEP_CLK>;
+ clock-names = "ahb", "sleep";
+ resets = < GCC_QUSB2_PHY_BCR>,
+< GCC_USB2_HS_PHY_ONLY_BCR>;
+ reset-names = "phy", "por";
+ };
+
+ usb3: usb@7678800 {
+ compatible = "qcom,dwc3";
+ reg = <0x7678800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clocks = < GCC_USB30_MASTER_CLK>,
+< GCC_SYS_NOC_USB3_CLK>,
+< GCC_USB30_SLEEP_CLK>,
+< GCC_USB30_MOCK_UTMI_CLK>;
+ clock-names = "core", "iface", "sleep", "mock_utmi";
+
+ dwc3@758 {
+ compatible = "snps,dwc3";
+ reg = <0x758 0xcd00>;
+ phys = <_phy_prim>, <_phy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ dr_mode = "host";
+ snps,has-lpm-erratum;
+ snps,hird-threshold = /bits/ 8 <0x10>;
+ snps,usb3_lpm_capable;
+ maximum-speed = "super-speed";
+ };
+ };
+
+ usb2: usb@79b8800 {
+ compatible = "qcom,dwc3";
+ reg = <0x79b8800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clocks = < GCC_USB_HS_SYSTEM_CLK>,
+< GCC_PCNOC_USB2_CLK>,
+< GCC_USB_HS_INACTIVITY_TIMERS_CLK>,
+< GCC_USB20_MOCK_UTMI_CLK>;
+ clock-names = "core", "iface", "sleep", "mock_utmi";
+
+ dwc3@78c {
+ compatible = "snps,dwc3";
+ reg = <0x78c 0xcc00>;
+ phys = <_phy_sec>;
+ phy-names = "usb2-phy";
+ dr_mode = "peripheral";
+ snps,has-lpm-erratum;
+ snps,hird-threshold = /bits/ 8 <0x10>;
+ snps,usb3_lpm_capable;
+ maximum-speed = "high-speed";
+
Re: [PATCH v2 0/2] Initial step for Linux DT sync on Qcom SoCs
Hi, On Wed, 27 Jul 2022 at 13:52, Sumit Garg wrote: > > This is an initial step towards achieving complete Linux DT sync on Qcom > SoCs/boards. It syncs up DT compatibles for pinctrl and GPIO drivers. > > Changes in v2: > - Separate patch for CONFIG_SDM845 check removal. > - Fix pinctrl DT compatibles for db410c and db820c. > Do we have any further comments on this? -Sumit > Sumit Garg (2): > pinctrl: sdm845: Remove redundant CONFIG_SDM845 check > arm: dts: qcom: Sync pinctrl DT nodes with Linux bindings > > arch/arm/dts/dragonboard410c-uboot.dtsi | 2 +- > arch/arm/dts/dragonboard410c.dts | 17 +++- > arch/arm/dts/dragonboard820c-uboot.dtsi | 2 +- > arch/arm/dts/dragonboard820c.dts | 4 +- > arch/arm/dts/qcom-ipq4019.dtsi| 18 +++-- > arch/arm/dts/qcs404-evb.dts | 2 +- > arch/arm/dts/sdm845.dtsi | 2 +- > arch/arm/mach-ipq40xx/pinctrl-snapdragon.c| 31 ++- > arch/arm/mach-snapdragon/Makefile | 2 +- > arch/arm/mach-snapdragon/pinctrl-snapdragon.c | 39 --- > drivers/gpio/msm_gpio.c | 10 + > 11 files changed, 83 insertions(+), 46 deletions(-) > > -- > 2.25.1 >
Re: [PATCH 29/31] tools: mtk_image: split the code of generating NAND header into a new file
Hi Weijie,
On Wed, 3 Aug 2022 at 21:37, Weijie Gao wrote:
>
> The predefined NAND headers take too much spaces in the mtk_image.c.
> Moving them into a new file can significantly improve the readability of
> both mtk_image.c and the new mtk_nand_headers.c.
>
> This is a preparation for adding more NAND headers.
>
> Signed-off-by: Weijie Gao
> ---
> tools/Makefile | 1 +
> tools/mtk_image.c| 304 ++-
> tools/mtk_image.h| 25
> tools/mtk_nand_headers.c | 286
> tools/mtk_nand_headers.h | 52 +++
> 5 files changed, 379 insertions(+), 289 deletions(-)
> create mode 100644 tools/mtk_nand_headers.c
> create mode 100644 tools/mtk_nand_headers.h
Reviewed-by: Simon Glass
[..]
> new file mode 100644
> index 00..691db85005
> --- /dev/null
> +++ b/tools/mtk_nand_headers.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * MediaTek BootROM NAND header definitions
> + *
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Weijie Gao
> + */
> +
> +#ifndef _MTK_NAND_HEADERS_H
> +#define _MTK_NAND_HEADERS_H
> +
> +#include
> +#include
> +
> +struct nand_header_info {
> + uint32_t page_size;
> + uint32_t spare_size;
> + uint32_t gfh_offset;
> +};
> +
> +/* AP BROM Header for NAND */
Where is this documented?
> +union nand_boot_header {
> + struct {
> + char name[12];
> + char version[4];
> + char id[8];
> + uint16_t ioif;
> + uint16_t pagesize;
> + uint16_t addrcycles;
> + uint16_t oobsize;
> + uint16_t pages_of_block;
> + uint16_t numblocks;
> + uint16_t writesize_shift;
> + uint16_t erasesize_shift;
> + uint8_t dummy[60];
> + uint8_t ecc_parity[28];
> + };
> +
> + uint8_t data[0x80];
> +};
> +
> +#define NAND_BOOT_NAME "BOOTLOADER!"
> +#define NAND_BOOT_VERSION "V006"
> +#define NAND_BOOT_ID "NFIINFO"
> +
> +const union nand_boot_header *mtk_nand_header_find(const char *name);
> +uint32_t mtk_nand_header_size(const union nand_boot_header *hdr_nand);
> +int mtk_nand_header_info(const void *ptr, struct nand_header_info *info);
> +bool is_mtk_nand_header(const void *ptr);
> +uint32_t mtk_nand_header_put(const union nand_boot_header *hdr_nand, void
> *ptr);
Please comment each of these.
> +
> +#endif /* _MTK_NAND_HEADERS_H */
> --
> 2.17.1
>
Regards,
SImon
Re: [PATCH 30/31] tools: mtk_image: add support for nand headers used by newer chips
Hi Weijie,
On Wed, 3 Aug 2022 at 21:41, Weijie Gao wrote:
>
> This patch adds more nand headers in two new types:
> 1. HSM header, used for spi-nand thru SNFI interface
> 2. SPIM header, used for spi-nand thru spi-mem interface
>
> The original nand header is renamed to AP header.
>
> 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(-)
Reviewed-by: Simon Glass
[..]
> diff --git a/tools/mtk_nand_headers.h b/tools/mtk_nand_headers.h
> index 691db85005..ce4a824e29 100644
> --- a/tools/mtk_nand_headers.h
> +++ b/tools/mtk_nand_headers.h
> @@ -16,6 +16,7 @@ struct nand_header_info {
> uint32_t page_size;
> uint32_t spare_size;
> uint32_t gfh_offset;
> + bool snfi;
> };
>
> /* AP BROM Header for NAND */
> @@ -39,14 +40,117 @@ union nand_boot_header {
> uint8_t data[0x80];
> };
>
> +/* HSM BROM Header for NAND */
> +union hsm_nand_boot_header {
> + struct {
> + char id[8];
> + uint32_t version;
> + uint32_t config;
> + uint32_t sector_size;
> + uint32_t fdm_size;
> + uint32_t fdm_ecc_size;
> + uint32_t lbs;
> + uint32_t page_size;
> + uint32_t spare_size;
> + uint32_t page_per_block;
> + uint32_t blocks;
> + uint32_t plane_sel_position;
> + uint32_t pll;
> + uint32_t acccon;
> + uint32_t strobe_sel;
> + uint32_t acccon1;
> + uint32_t dqs_mux;
> + uint32_t dqs_ctrl;
> + uint32_t delay_ctrl;
> + uint32_t latch_lat;
> + uint32_t sample_delay;
> + uint32_t driving;
> + uint32_t bl_start;
> + uint32_t bl_end;
> + uint8_t ecc_parity[42];
> + };
> +
> + uint8_t data[0x8E];
> +};
> +
> +/* HSM2.0 BROM Header for NAND */
> +union hsm20_nand_boot_header {
> + struct {
> + char id[8];
> + uint32_t version;
> + uint32_t config;
> + uint32_t sector_size;
> + uint32_t fdm_size;
> + uint32_t fdm_ecc_size;
> + uint32_t lbs;
> + uint32_t page_size;
> + uint32_t spare_size;
> + uint32_t page_per_block;
> + uint32_t blocks;
> + uint32_t plane_sel_position;
> + uint32_t pll;
> + uint32_t acccon;
> + uint32_t strobe_sel;
> + uint32_t acccon1;
> + uint32_t dqs_mux;
> + uint32_t dqs_ctrl;
> + uint32_t delay_ctrl;
> + uint32_t latch_lat;
> + uint32_t sample_delay;
> + uint32_t driving;
> + uint32_t reserved;
> + uint32_t bl0_start;
> + uint32_t bl0_end;
> + uint32_t bl0_type;
> + uint8_t bl_reserve[84];
> + uint8_t ecc_parity[42];
> + };
> +
> + uint8_t data[0xEA];
> +};
> +
> +/* SPIM BROM Header for NAND */
> +union spim_nand_boot_header {
> + struct {
> + char id[8];
> + uint32_t version;
> + uint32_t config;
> + uint32_t page_size;
> + uint32_t spare_size;
> + uint16_t page_per_block;
> + uint16_t plane_sel_position;
> + uint16_t reserve_reg;
> + uint16_t reserve_val;
> + uint16_t ecc_error;
> + uint16_t ecc_mask;
> + uint32_t bl_start;
> + uint32_t bl_end;
> + uint8_t ecc_parity[32];
> + uint32_t integrity_crc;
> + };
> +
> + uint8_t data[0x50];
> +};
> +
> +enum nand_boot_header_type {
> + NAND_BOOT_AP_HEADER,
> + NAND_BOOT_HSM_HEADER,
> + NAND_BOOT_HSM20_HEADER,
> + NAND_BOOT_SPIM_HEADER
> +};
> +
> #define NAND_BOOT_NAME "BOOTLOADER!"
> #define NAND_BOOT_VERSION "V006"
> #define NAND_BOOT_ID "NFIINFO"
>
> -const union nand_boot_header *mtk_nand_header_find(const char *name);
> -uint32_t mtk_nand_header_size(const union nand_boot_header *hdr_nand);
> +#define HSM_NAND_BOOT_NAME "NANDCFG!"
> +#define SPIM_NAND_BOOT_NAME"SPINAND!"
> +
> +const struct nand_header_type *mtk_nand_header_find(const char *name);
> +uint32_t mtk_nand_header_size(const struct nand_header_type *hdr_nand);
> int mtk_nand_header_info(const void *ptr, struct nand_header_info *info);
> bool is_mtk_nand_header(const void *ptr);
> -uint32_t mtk_nand_header_put(const union nand_boot_header *hdr_nand, void
> *ptr);
> +uint32_t mtk_nand_header_put(const struct nand_header_type
Re: [PATCH 26/31] clk: mediatek: add clock driver support for MediaTek MT7986 SoC
Hi Weijie,
On Wed, 3 Aug 2022 at 21:40, Weijie Gao wrote:
>
> 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
>
Reviewed-by: Simon Glass
[..]
> new file mode 100644
> index 00..11c489cd50
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7986.c
> @@ -0,0 +1,671 @@
[..]
> +static int mt7986_topckgen_probe(struct udevice *dev)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(dev);
> +
> + priv->base = dev_read_addr_ptr(dev);
> + writel(MT7986_CLK_PDN_EN_WRITE, priv->base + MT7986_CLK_PDN);
blank line here
> + return mtk_common_clk_init(dev, _topckgen_clk_tree);
> +}
> +
> +U_BOOT_DRIVER(mtk_clk_apmixedsys) = {
> + .name = "mt7986-clock-fixed-pll",
> + .id = UCLASS_CLK,
> + .of_match = mt7986_fixed_pll_compat,
> + .probe = mt7986_fixed_pll_probe,
> + .priv_auto = sizeof(struct mtk_clk_priv),
> + .ops = _clk_topckgen_ops,
> + .flags = DM_FLAG_PRE_RELOC,
> +};
> +
> +U_BOOT_DRIVER(mtk_clk_topckgen) = {
> + .name = "mt7986-clock-topckgen",
> + .id = UCLASS_CLK,
> + .of_match = mt7986_topckgen_compat,
> + .probe = mt7986_topckgen_probe,
> + .priv_auto = sizeof(struct mtk_clk_priv),
> + .ops = _clk_topckgen_ops,
> + .flags = DM_FLAG_PRE_RELOC,
> +};
> +
> +static const struct udevice_id mt7986_infracfg_compat[] = {
> + { .compatible = "mediatek,mt7986-infracfg" },
> + {}
> +};
> +
> +static const struct udevice_id mt7986_infracfg_ao_compat[] = {
> + { .compatible = "mediatek,mt7986-infracfg_ao" },
> + {}
> +};
> +
> +static int mt7986_infracfg_probe(struct udevice *dev)
> +{
> + return mtk_common_clk_init(dev, _infracfg_clk_tree);
> +}
> +
> +static int mt7986_infracfg_ao_probe(struct udevice *dev)
> +{
> + return mtk_common_clk_gate_init(dev, _infracfg_clk_tree,
> + infracfg_ao_gates);
> +}
> +
> +U_BOOT_DRIVER(mtk_clk_infracfg) = {
> + .name = "mt7986-clock-infracfg",
> + .id = UCLASS_CLK,
> + .of_match = mt7986_infracfg_compat,
> + .probe = mt7986_infracfg_probe,
> + .priv_auto = sizeof(struct mtk_clk_priv),
> + .ops = _clk_infrasys_ops,
> + .flags = DM_FLAG_PRE_RELOC,
> +};
> +
> +U_BOOT_DRIVER(mtk_clk_infracfg_ao) = {
> + .name = "mt7986-clock-infracfg-ao",
> + .id = UCLASS_CLK,
> + .of_match = mt7986_infracfg_ao_compat,
> + .probe = mt7986_infracfg_ao_probe,
> + .priv_auto = sizeof(struct mtk_cg_priv),
> + .ops = _clk_gate_ops,
> + .flags = DM_FLAG_PRE_RELOC,
> +};
> +
> +/* ethsys */
> +static const struct mtk_gate_regs eth_cg_regs = {
> + .sta_ofs = 0x30,
> +};
> +
> +#define GATE_ETH(_id, _name, _parent, _shift)
> \
> + {
> \
> + .id = _id, .parent = _parent, .regs = _cg_regs,
> \
> + .shift = _shift,
> \
> + .flags = CLK_GATE_NO_SETCLR_INV | CLK_PARENT_TOPCKGEN,
> \
> + }
> +
> +static const struct mtk_gate eth_cgs[] = {
> + GATE_ETH(CK_ETH_FE_EN, "eth_fe_en", CK_TOP_NETSYS_2X, 7),
> + GATE_ETH(CK_ETH_GP2_EN, "eth_gp2_en", CK_TOP_SGM_325M, 8),
> + GATE_ETH(CK_ETH_GP1_EN, "eth_gp1_en", CK_TOP_SGM_325M, 8),
> + GATE_ETH(CK_ETH_WOCPU1_EN, "eth_wocpu1_en", CK_TOP_NETSYS_WED_MCU,
> 14),
> + GATE_ETH(CK_ETH_WOCPU0_EN, "eth_wocpu0_en", CK_TOP_NETSYS_WED_MCU,
> 15),
> +};
> +
> +static int mt7986_ethsys_probe(struct udevice *dev)
> +{
> + return mtk_common_clk_gate_init(dev, _topckgen_clk_tree,
> + eth_cgs);
> +}
> +
> +static int mt7986_ethsys_bind(struct udevice *dev)
> +{
> + int ret = 0;
> +
> +#if CONFIG_IS_ENABLED(RESET_MEDIATEK)
if (CONFIG_IS_ENABLED()...
> + ret = mediatek_reset_bind(dev, ETHSYS_HIFSYS_RST_CTRL_OFS, 1);
> + if (ret)
> + debug("Warning: failed to bind reset controller\n");
> +#endif
> +
> + return ret;
> +}
> +
> +static const struct udevice_id mt7986_ethsys_compat[] = {
> + { .compatible = "mediatek,mt7986-ethsys" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(mtk_clk_ethsys) = {
> + .name = "mt7986-clock-ethsys",
> + .id = UCLASS_CLK,
> + .of_match = mt7986_ethsys_compat,
> + .probe = mt7986_ethsys_probe,
> + .bind = mt7986_ethsys_bind,
> + .priv_auto = sizeof(struct mtk_cg_priv),
> + .ops = _clk_gate_ops,
> +};
Regards,
Simon
Re: [PATCH 06/31] net: mediatek: use a struct to cover variations of all SoCs
Hi Weijie,
On Wed, 3 Aug 2022 at 21:36, Weijie Gao wrote:
>
> Using a single soc id to control different initialization and TX/RX flow
> for all SoCs is not extensible if more hardware variations are added in
> the future.
>
> This patch introduces a struct to replace the original mtk_soc to allow
> the driver be able handle newer hardwares.
>
> Signed-off-by: Weijie Gao
> ---
> drivers/net/mtk_eth.c | 50 +--
> drivers/net/mtk_eth.h | 25 +-
> 2 files changed, 58 insertions(+), 17 deletions(-)
Reviewed-by: Simon Glass
>
> 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;
please comment these
[..]
Regards,
Simon
[PATCH 01/13] phy: Move qcom SoCs specific phy drivers to qcom folder
Signed-off-by: Sumit Garg
---
drivers/phy/Kconfig | 15 +--
drivers/phy/Makefile | 3 +--
drivers/phy/qcom/Kconfig | 13 +
drivers/phy/qcom/Makefile | 2 ++
drivers/phy/{ => qcom}/msm8916-usbh-phy.c | 0
drivers/phy/{ => qcom}/phy-qcom-ipq4019-usb.c | 0
6 files changed, 17 insertions(+), 16 deletions(-)
create mode 100644 drivers/phy/qcom/Kconfig
create mode 100644 drivers/phy/qcom/Makefile
rename drivers/phy/{ => qcom}/msm8916-usbh-phy.c (100%)
rename drivers/phy/{ => qcom}/phy-qcom-ipq4019-usb.c (100%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c25b42c68f..cf4d5908d7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -143,12 +143,6 @@ config STI_USB_PHY
used by USB2 and USB3 Host controllers available on
STiH407 SoC families.
-config PHY_QCOM_IPQ4019_USB
- tristate "Qualcomm IPQ4019 USB PHY driver"
- depends on PHY && ARCH_IPQ40XX
- help
- Support for the USB PHY-s on Qualcomm IPQ40xx SoC-s.
-
config PHY_RCAR_GEN2
tristate "Renesas R-Car Gen2 USB PHY"
depends on PHY && RCAR_GEN2
@@ -220,14 +214,6 @@ config MESON_AXG_MIPI_PCIE_ANALOG_PHY
This is the generic phy driver for the Amlogic Meson AXG
MIPI PCIe Analog PHY.
-config MSM8916_USB_PHY
- bool "Qualcomm MSM8916 USB PHY support"
- depends on PHY
- help
- Support the USB PHY in msm8916
-
- This PHY is found on qualcomm dragonboard410c development board.
-
config OMAP_USB2_PHY
bool "Support OMAP's USB2 PHY"
depends on PHY
@@ -298,5 +284,6 @@ config PHY_XILINX_ZYNQMP
source "drivers/phy/rockchip/Kconfig"
source "drivers/phy/cadence/Kconfig"
source "drivers/phy/ti/Kconfig"
+source "drivers/phy/qcom/Kconfig"
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d95439c425..a3b9f3c5b1 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
obj-$(CONFIG_STI_USB_PHY) += sti_usb_phy.o
-obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
obj-$(CONFIG_PHY_RCAR_GEN2) += phy-rcar-gen2.o
obj-$(CONFIG_PHY_RCAR_GEN3) += phy-rcar-gen3.o
obj-$(CONFIG_PHY_STM32_USBPHYC) += phy-stm32-usbphyc.o
@@ -30,7 +29,6 @@ obj-$(CONFIG_MESON_GXL_USB_PHY) += meson-gxl-usb2.o
obj-$(CONFIG_MESON_G12A_USB_PHY) += meson-g12a-usb2.o meson-g12a-usb3-pcie.o
obj-$(CONFIG_MESON_AXG_MIPI_DPHY) += meson-axg-mipi-dphy.o
obj-$(CONFIG_MESON_AXG_MIPI_PCIE_ANALOG_PHY) += meson-axg-mipi-pcie-analog.o
-obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
obj-$(CONFIG_OMAP_USB2_PHY) += omap-usb2-phy.o
obj-$(CONFIG_KEYSTONE_USB_PHY) += keystone-usb-phy.o
obj-$(CONFIG_MT7620_USB_PHY) += mt7620-usb-phy.o
@@ -42,3 +40,4 @@ obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
obj-y += cadence/
obj-y += ti/
+obj-y += qcom/
diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
new file mode 100644
index 00..f685a6455e
--- /dev/null
+++ b/drivers/phy/qcom/Kconfig
@@ -0,0 +1,13 @@
+config MSM8916_USB_PHY
+ bool "Qualcomm MSM8916 USB PHY support"
+ depends on PHY
+ help
+ Support the USB PHY in msm8916
+
+ This PHY is found on qualcomm dragonboard410c development board.
+
+config PHY_QCOM_IPQ4019_USB
+ tristate "Qualcomm IPQ4019 USB PHY driver"
+ depends on PHY && ARCH_IPQ40XX
+ help
+ Support for the USB PHY-s on Qualcomm IPQ40xx SoC-s.
diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
new file mode 100644
index 00..4a340e33c8
--- /dev/null
+++ b/drivers/phy/qcom/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
+obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
diff --git a/drivers/phy/msm8916-usbh-phy.c
b/drivers/phy/qcom/msm8916-usbh-phy.c
similarity index 100%
rename from drivers/phy/msm8916-usbh-phy.c
rename to drivers/phy/qcom/msm8916-usbh-phy.c
diff --git a/drivers/phy/phy-qcom-ipq4019-usb.c
b/drivers/phy/qcom/phy-qcom-ipq4019-usb.c
similarity index 100%
rename from drivers/phy/phy-qcom-ipq4019-usb.c
rename to drivers/phy/qcom/phy-qcom-ipq4019-usb.c
--
2.25.1
[PATCH 02/13] phy: Add support for drivers to enable USB on QCS404 SoC
QCS404 SoC supports two types of PHY, one supports high speed mode or
USB2 PHY and the other supports super speed mode or USB3 PHY. So add
corresponding PHY drivers.
Signed-off-by: Sumit Garg
---
drivers/phy/qcom/Kconfig| 16 ++
drivers/phy/qcom/Makefile | 2 +
drivers/phy/qcom/phy-qcom-usb-hs-28nm.c | 250
drivers/phy/qcom/phy-qcom-usb-ss.c | 154 +++
4 files changed, 422 insertions(+)
create mode 100644 drivers/phy/qcom/phy-qcom-usb-hs-28nm.c
create mode 100644 drivers/phy/qcom/phy-qcom-usb-ss.c
diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
index f685a6455e..f4ca174805 100644
--- a/drivers/phy/qcom/Kconfig
+++ b/drivers/phy/qcom/Kconfig
@@ -11,3 +11,19 @@ config PHY_QCOM_IPQ4019_USB
depends on PHY && ARCH_IPQ40XX
help
Support for the USB PHY-s on Qualcomm IPQ40xx SoC-s.
+
+config PHY_QCOM_USB_HS_28NM
+ tristate "Qualcomm 28nm High-Speed PHY"
+ depends on PHY && ARCH_SNAPDRAGON
+ help
+ Enable this to support the Qualcomm Synopsys DesignWare Core 28nm
+ High-Speed PHY driver. This driver supports the Hi-Speed PHY which
+ is usually paired with either the ChipIdea or Synopsys DWC3 USB
+ IPs on MSM SOCs.
+
+config PHY_QCOM_USB_SS
+ tristate "Qualcomm USB Super-Speed PHY driver"
+ depends on PHY && ARCH_SNAPDRAGON
+ help
+ Enable this to support the Super-Speed USB transceiver on various
+ Qualcomm chipsets.
diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
index 4a340e33c8..2113f178c0 100644
--- a/drivers/phy/qcom/Makefile
+++ b/drivers/phy/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
+obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
+obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
diff --git a/drivers/phy/qcom/phy-qcom-usb-hs-28nm.c
b/drivers/phy/qcom/phy-qcom-usb-hs-28nm.c
new file mode 100644
index 00..14c3d8394d
--- /dev/null
+++ b/drivers/phy/qcom/phy-qcom-usb-hs-28nm.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Sumit Garg
+ *
+ * Based on Linux driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PHY register and bit definitions */
+#define PHY_CTRL_COMMON0 0x078
+#define SIDDQ BIT(2)
+
+struct hsphy_init_seq {
+ int offset;
+ int val;
+ int delay;
+};
+
+struct hsphy_data {
+ const struct hsphy_init_seq *init_seq;
+ unsigned int init_seq_num;
+};
+
+struct hsphy_priv {
+ void __iomem *base;
+ struct clk_bulk clks;
+ struct reset_ctl phy_rst;
+ struct reset_ctl por_rst;
+ const struct hsphy_data *data;
+};
+
+static int hsphy_power_on(struct phy *phy)
+{
+ struct hsphy_priv *priv = dev_get_priv(phy->dev);
+ u32 val;
+
+ val = readb(priv->base + PHY_CTRL_COMMON0);
+ val &= ~SIDDQ;
+ writeb(val, priv->base + PHY_CTRL_COMMON0);
+
+ return 0;
+}
+
+static int hsphy_power_off(struct phy *phy)
+{
+ struct hsphy_priv *priv = dev_get_priv(phy->dev);
+ u32 val;
+
+ val = readb(priv->base + PHY_CTRL_COMMON0);
+ val |= SIDDQ;
+ writeb(val, priv->base + PHY_CTRL_COMMON0);
+
+ return 0;
+}
+
+static int hsphy_reset(struct hsphy_priv *priv)
+{
+ int ret;
+
+ ret = reset_assert(>phy_rst);
+ if (ret)
+ return ret;
+
+ udelay(10);
+
+ ret = reset_deassert(>phy_rst);
+ if (ret)
+ return ret;
+
+ udelay(80);
+
+ return 0;
+}
+
+static void hsphy_init_sequence(struct hsphy_priv *priv)
+{
+ const struct hsphy_data *data = priv->data;
+ const struct hsphy_init_seq *seq;
+ int i;
+
+ /* Device match data is optional. */
+ if (!data)
+ return;
+
+ seq = data->init_seq;
+
+ for (i = 0; i < data->init_seq_num; i++, seq++) {
+ writeb(seq->val, priv->base + seq->offset);
+ if (seq->delay)
+ udelay(seq->delay);
+ }
+}
+
+static int hsphy_por_reset(struct hsphy_priv *priv)
+{
+ int ret;
+ u32 val;
+
+ ret = reset_assert(>por_rst);
+ if (ret)
+ return ret;
+
+ /*
+* The Femto PHY is POR reset in the following scenarios.
+*
+* 1. After overriding the parameter registers.
+* 2. Low power mode exit from PHY retention.
+*
+* Ensure that SIDDQ is cleared before bringing the PHY
+* out of reset.
+*/
+ val = readb(priv->base + PHY_CTRL_COMMON0);
+ val &= ~SIDDQ;
+ writeb(val, priv->base + PHY_CTRL_COMMON0);
+
+ /*
+* As per databook, 10 usec delay is required between
+* PHY POR assert and de-assert.
+*/
+
[PATCH 03/13] reset: Convert ipq4019 driver to a generic Qcom driver
Since the base functionality remains the same for a reset driver on Qcom
SoCs, so leverage that to convert ipq4019 specific reset driver to a
generic Qcom reset driver. With that one just need to provide SoC specific
reset table.
Signed-off-by: Sumit Garg
---
drivers/reset/Kconfig | 9 ++--
drivers/reset/Makefile| 2 +-
.../reset/{reset-ipq4019.c => reset-qcom.c} | 46 ++-
3 files changed, 30 insertions(+), 27 deletions(-)
rename drivers/reset/{reset-ipq4019.c => reset-qcom.c} (79%)
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 69a7b4ccba..4cb0ba0850 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -156,13 +156,12 @@ config RESET_IMX7
help
Support for reset controller on i.MX7/8 SoCs.
-config RESET_IPQ419
- bool "Reset driver for Qualcomm IPQ40xx SoCs"
- depends on DM_RESET && ARCH_IPQ40XX
+config RESET_QCOM
+ bool "Reset driver for Qualcomm SoCs"
+ depends on DM_RESET && (ARCH_SNAPDRAGON || ARCH_IPQ40XX)
default y
help
- Support for reset controller on Qualcomm
- IPQ40xx SoCs.
+ Support for reset controller on Qualcomm SoCs.
config RESET_SIFIVE
bool "Reset Driver for SiFive SoC's"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 97e3a782c0..0620b62809 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o
obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o
obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
-obj-$(CONFIG_RESET_IPQ419) += reset-ipq4019.o
+obj-$(CONFIG_RESET_QCOM) += reset-qcom.o
obj-$(CONFIG_RESET_SIFIVE) += reset-sifive.o
obj-$(CONFIG_RESET_SYSCON) += reset-syscon.o
obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
diff --git a/drivers/reset/reset-ipq4019.c b/drivers/reset/reset-qcom.c
similarity index 79%
rename from drivers/reset/reset-ipq4019.c
rename to drivers/reset/reset-qcom.c
index 7f0bd85ad6..40f436ede4 100644
--- a/drivers/reset/reset-ipq4019.c
+++ b/drivers/reset/reset-qcom.c
@@ -1,8 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2020 Sartura Ltd.
+ * Copyright (c) 2022 Linaro Ltd.
*
* Author: Robert Marko
+ * Sumit Garg
*
* Based on Linux driver
*/
@@ -10,12 +12,11 @@
#include
#include
#include
-#include
#include
#include
#include
-struct ipq4019_reset_priv {
+struct qcom_reset_priv {
phys_addr_t base;
};
@@ -24,7 +25,9 @@ struct qcom_reset_map {
u8 bit;
};
-static const struct qcom_reset_map gcc_ipq4019_resets[] = {
+#ifdef CONFIG_ARCH_IPQ40XX
+#include
+static const struct qcom_reset_map gcc_qcom_resets[] = {
[WIFI0_CPU_INIT_RESET] = { 0x1f008, 5 },
[WIFI0_RADIO_SRIF_RESET] = { 0x1f008, 4 },
[WIFI0_RADIO_WARM_RESET] = { 0x1f008, 3 },
@@ -97,11 +100,12 @@ static const struct qcom_reset_map gcc_ipq4019_resets[] = {
[GCC_MPM_BCR] = {0x24000, 0},
[GCC_SPDM_BCR] = {0x25000, 0},
};
+#endif
-static int ipq4019_reset_assert(struct reset_ctl *rst)
+static int qcom_reset_assert(struct reset_ctl *rst)
{
- struct ipq4019_reset_priv *priv = dev_get_priv(rst->dev);
- const struct qcom_reset_map *reset_map = gcc_ipq4019_resets;
+ struct qcom_reset_priv *priv = dev_get_priv(rst->dev);
+ const struct qcom_reset_map *reset_map = gcc_qcom_resets;
const struct qcom_reset_map *map;
u32 value;
@@ -114,10 +118,10 @@ static int ipq4019_reset_assert(struct reset_ctl *rst)
return 0;
}
-static int ipq4019_reset_deassert(struct reset_ctl *rst)
+static int qcom_reset_deassert(struct reset_ctl *rst)
{
- struct ipq4019_reset_priv *priv = dev_get_priv(rst->dev);
- const struct qcom_reset_map *reset_map = gcc_ipq4019_resets;
+ struct qcom_reset_priv *priv = dev_get_priv(rst->dev);
+ const struct qcom_reset_map *reset_map = gcc_qcom_resets;
const struct qcom_reset_map *map;
u32 value;
@@ -130,19 +134,19 @@ static int ipq4019_reset_deassert(struct reset_ctl *rst)
return 0;
}
-static const struct reset_ops ipq4019_reset_ops = {
- .rst_assert = ipq4019_reset_assert,
- .rst_deassert = ipq4019_reset_deassert,
+static const struct reset_ops qcom_reset_ops = {
+ .rst_assert = qcom_reset_assert,
+ .rst_deassert = qcom_reset_deassert,
};
-static const struct udevice_id ipq4019_reset_ids[] = {
+static const struct udevice_id qcom_reset_ids[] = {
{ .compatible = "qcom,gcc-reset-ipq4019" },
{ }
};
-static int ipq4019_reset_probe(struct udevice *dev)
+static int qcom_reset_probe(struct udevice *dev)
{
- struct ipq4019_reset_priv *priv = dev_get_priv(dev);
+ struct qcom_reset_priv *priv = dev_get_priv(dev);
priv->base = dev_read_addr(dev);
if (priv->base == FDT_ADDR_T_NONE)
@@ -151,11
[PATCH 00/13] USB support for QCS404 SoC
This series add support for USB on QCS404 SoC. USB support have
dependencies on PHY, reset and PMIC GPIO drivers, so corresponding
support has been added. There are also some renaming/reorganising
patches (#1, #3 and #9) which tries to generalize drivers support
for Qcom SoCs.
- Patch #1 moves all Qcom PHY drivers to drivers/phy/qcom/.
- Patch #3 coverts ipq4019 reset driver to a generic Qcom reset driver.
- Patch #9 Convert pm8916 driver to a generic Qcom PMIC driver.
Sumit Garg (13):
phy: Move qcom SoCs specific phy drivers to qcom folder
phy: Add support for drivers to enable USB on QCS404 SoC
reset: Convert ipq4019 driver to a generic Qcom driver
reset: qcom: Add support for QCS404 SoC reset table
dts: qcs404-evb: Add reset controller node
clocks: qcom: Add clock enable callback support
clocks: qcs404: Add support for USB clocks
dts: qcs404-evb: Add USB controller and PHY nodes
pmic: Convert pm8916 driver to a generic Qcom PMIC driver
gpio: qcom_pmic: Add support for GPIO LV/MV subtype
dts: qcs404-evb: Add PMIC GPIO controller node
board: qcs404-evb: Enable USB3 specific PMIC GPIO
qcs404evb_defconfig: Enable USB configs
arch/arm/dts/qcs404-evb-uboot.dtsi| 6 +
arch/arm/dts/qcs404-evb.dts | 118 ++
arch/arm/mach-snapdragon/clock-apq8016.c | 5 +
arch/arm/mach-snapdragon/clock-apq8096.c | 5 +
arch/arm/mach-snapdragon/clock-qcs404.c | 40 ++
arch/arm/mach-snapdragon/clock-sdm845.c | 5 +
arch/arm/mach-snapdragon/clock-snapdragon.c | 7 +
.../include/mach/sysmap-qcs404.h | 17 +
board/qualcomm/qcs404-evb/qcs404-evb.c| 29 ++
configs/dragonboard410c_defconfig | 4 +-
configs/dragonboard820c_defconfig | 4 +-
configs/dragonboard845c_defconfig | 4 +-
configs/qcs404evb_defconfig | 18 +
configs/sandbox64_defconfig | 4 +-
configs/sandbox_defconfig | 4 +-
configs/sandbox_flattree_defconfig| 4 +-
configs/sandbox_noinst_defconfig | 4 +-
configs/sandbox_spl_defconfig | 4 +-
configs/sandbox_vpl_defconfig | 4 +-
configs/starqltechn_defconfig | 4 +-
doc/device-tree-bindings/pmic/pm8916.txt | 18 -
.../pmic/qcom,spmi-pmic.txt | 94 +
drivers/gpio/Kconfig | 10 +-
drivers/gpio/Makefile | 2 +-
drivers/gpio/pm8916_gpio.c| 303 ---
drivers/gpio/qcom_pmic_gpio.c | 359 ++
drivers/phy/Kconfig | 15 +-
drivers/phy/Makefile | 3 +-
drivers/phy/qcom/Kconfig | 29 ++
drivers/phy/qcom/Makefile | 4 +
drivers/phy/{ => qcom}/msm8916-usbh-phy.c | 0
drivers/phy/{ => qcom}/phy-qcom-ipq4019-usb.c | 0
drivers/phy/qcom/phy-qcom-usb-hs-28nm.c | 250
drivers/phy/qcom/phy-qcom-usb-ss.c| 154
drivers/power/pmic/Kconfig| 8 +-
drivers/power/pmic/Makefile | 2 +-
drivers/power/pmic/{pm8916.c => pmic_qcom.c} | 42 +-
drivers/reset/Kconfig | 9 +-
drivers/reset/Makefile| 2 +-
.../reset/{reset-ipq4019.c => reset-qcom.c} | 76 +++-
40 files changed, 1254 insertions(+), 416 deletions(-)
delete mode 100644 doc/device-tree-bindings/pmic/pm8916.txt
create mode 100644 doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
delete mode 100644 drivers/gpio/pm8916_gpio.c
create mode 100644 drivers/gpio/qcom_pmic_gpio.c
create mode 100644 drivers/phy/qcom/Kconfig
create mode 100644 drivers/phy/qcom/Makefile
rename drivers/phy/{ => qcom}/msm8916-usbh-phy.c (100%)
rename drivers/phy/{ => qcom}/phy-qcom-ipq4019-usb.c (100%)
create mode 100644 drivers/phy/qcom/phy-qcom-usb-hs-28nm.c
create mode 100644 drivers/phy/qcom/phy-qcom-usb-ss.c
rename drivers/power/pmic/{pm8916.c => pmic_qcom.c} (52%)
rename drivers/reset/{reset-ipq4019.c => reset-qcom.c} (64%)
--
2.25.1
[PATCH] ARM: meson: fixup error on efuse commands return
All `sm efuseread/efusewrite` commands exit with an error, even if the fuse
have actually been dealt with correctly.
This is because the smc call return the size it actually processed but this
result is checked against 0.
Return failure in do_efuse_read/write if the return value of
meson_sm_read/write_efuse() is not the requested size.
Fixes: 52195ba5f579 ("ARM: amlogic: add sm efuse write support and cmd for
read/write efuse")
Signed-off-by: Jerome Brunet
---
arch/arm/mach-meson/sm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
index 6c28c0f5e445..d6eb910689f4 100644
--- a/arch/arm/mach-meson/sm.c
+++ b/arch/arm/mach-meson/sm.c
@@ -82,10 +82,7 @@ ssize_t meson_sm_write_efuse(uintptr_t offset, void *buffer,
size_t size)
smc_call();
- if (regs.regs[0] == 0)
- return -1;
-
- return 0;
+ return regs.regs[0];
}
#define SM_CHIP_ID_LENGTH 119
@@ -222,7 +219,7 @@ static int do_efuse_read(struct cmd_tbl *cmdtp, int flag,
int argc,
address = simple_strtoul(argv[3], NULL, 0);
ret = meson_sm_read_efuse(offset, (void *)address, size);
- if (ret)
+ if (ret != size)
return CMD_RET_FAILURE;
return CMD_RET_SUCCESS;
@@ -243,7 +240,7 @@ static int do_efuse_write(struct cmd_tbl *cmdtp, int flag,
int argc,
address = simple_strtoul(argv[3], NULL, 0);
ret = meson_sm_write_efuse(offset, (void *)address, size);
- if (ret)
+ if (ret != size)
return CMD_RET_FAILURE;
return CMD_RET_SUCCESS;
--
2.36.1
Re: [PATCH 4/5] arm: mvebu: armada-xp-theadorable.dts: Move u-boot,dm-pre-reloc to -u-boot.dtsi
On 03.08.22 13:00, Pali Rohár wrote:
Move U-Boot specific device tree property u-boot,dm-pre-reloc into U-Boot
specific device tree include file armada-xp-theadorable-u-boot.dtsi.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese
Thanks,
Stefan
---
arch/arm/dts/armada-xp-theadorable-u-boot.dtsi | 5 +
arch/arm/dts/armada-xp-theadorable.dts | 1 -
2 files changed, 5 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/armada-xp-theadorable-u-boot.dtsi
diff --git a/arch/arm/dts/armada-xp-theadorable-u-boot.dtsi
b/arch/arm/dts/armada-xp-theadorable-u-boot.dtsi
new file mode 100644
index ..c98bfa1e18da
--- /dev/null
+++ b/arch/arm/dts/armada-xp-theadorable-u-boot.dtsi
@@ -0,0 +1,5 @@
+ {
+ u-boot,dm-pre-reloc;
+};
+
+#include "mvebu-u-boot.dtsi"
diff --git a/arch/arm/dts/armada-xp-theadorable.dts
b/arch/arm/dts/armada-xp-theadorable.dts
index 2f6aa194cf0f..ba73386d4f0a 100644
--- a/arch/arm/dts/armada-xp-theadorable.dts
+++ b/arch/arm/dts/armada-xp-theadorable.dts
@@ -134,7 +134,6 @@
compatible = "marvell,armada-xp-lcd";
reg = <0xe 0x1>;
status = "okay";
- u-boot,dm-pre-reloc;
display-timings {
native-mode = <>;
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
Re: [PATCH 2/5] arm: mvebu: Introduce mvebu-u-boot.dtsi for 32-bit Armada SoCs
On 03.08.22 13:00, Pali Rohár wrote:
Set u-boot,dm-pre-reloc for /soc/, /soc/internal-regs/ and nodes as
it is required on every 32-bit Armada SoCs. And set also u-boot,dm-pre-reloc
for when going to boot from SPI because otherwise SPL SPI drivers do
not load.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese
Thanks,
Stefan
---
arch/arm/dts/mvebu-u-boot.dtsi | 24
1 file changed, 24 insertions(+)
create mode 100644 arch/arm/dts/mvebu-u-boot.dtsi
diff --git a/arch/arm/dts/mvebu-u-boot.dtsi b/arch/arm/dts/mvebu-u-boot.dtsi
new file mode 100644
index ..5538f95148de
--- /dev/null
+++ b/arch/arm/dts/mvebu-u-boot.dtsi
@@ -0,0 +1,24 @@
+#include
+
+#ifdef CONFIG_ARMADA_32BIT
+
+/ {
+ soc {
+ u-boot,dm-pre-reloc;
+ internal-regs {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+#ifdef CONFIG_SPL_SPI
+ {
+ u-boot,dm-pre-reloc;
+};
+#endif
+
+#endif
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
Re: [PATCH 04/31] board: mediatek: add MT7981 reference boards
Hi Weijie, On Wed, 3 Aug 2022 at 21:35, Weijie Gao wrote: > > This patch adds general board files based on MT7981 SoCs. "Add general board files..." - same for other patches. Are the dts files from a particular Linux version? > > 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 > Regards, Simon
Re: [PATCH 08/31] net: mediatek: add support for PDMA v2
On Wed, 3 Aug 2022 at 21:36, Weijie Gao wrote: > > This patch adds support for PDMA v2 hardware. The PDMA v2 has extended the > DMA descriptor to 8-words, and some of its fields have changed comparing > to the v1 hardware. > > Signed-off-by: Weijie Gao > --- > drivers/net/mtk_eth.c | 51 ++--- > drivers/net/mtk_eth.h | 53 --- > 2 files changed, 83 insertions(+), 21 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 10/31] serial: mtk: add support for using dynamic baud clock souce
Hi Weijie,
On Wed, 3 Aug 2022 at 21:36, Weijie Gao wrote:
>
> The baud clock on some platform may change due to assigned-clock-parent
> set in DT. In current flow the baud clock is only retrieved during probe
> stage. If the parent of the source clock changes after probe stage, the
> setbrg will set wrong baudrate.
>
> To get the right clock rate, this patch records the baud clk struct to the
> driver's priv, and changes the driver's flow to get the clock rate before
> calling _mtk_serial_setbrg().
>
> Signed-off-by: Weijie Gao
> ---
> drivers/serial/serial_mtk.c | 72 -
> 1 file changed, 39 insertions(+), 33 deletions(-)
Reviewed-by: Simon Glass
please see below
>
> 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 {
please add a full comment for this struct
> 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)
Why u32? Can you use uint? Generally it is better for parameters to
use natural types unless there is a good reason.
[..]
Regards,
Simon
Re: [PATCH 16/31] spi: add support for MediaTek spi-mem controller
Hi Weijie, On Wed, 3 Aug 2022 at 21:38, Weijie Gao wrote: > > 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 Reviewed-by: Simon Glass [..] > 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 Please check header order: https://u-boot.readthedocs.io/en/latest/develop/codingstyle.html#include-files > + > +#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_IPM_SPIM_LOOP BIT(21) > +#define SPI_CMD_IPM_GET_TICKDLY_OFFSET 22 > + > +#define SPI_CMD_IPM_GET_TICKDLY_MASK GENMASK(24, 22) > + > +#define PIN_MODE_CFG(x)((x) / 2) > + > +#define SPI_CFG3_IPM_PIN_MODE_OFFSET 0 > +#define SPI_CFG3_IPM_HALF_DUPLEX_DIR BIT(2) > +#define SPI_CFG3_IPM_HALF_DUPLEX_ENBIT(3) > +#define SPI_CFG3_IPM_XMODE_EN BIT(4) > +#define SPI_CFG3_IPM_NODATA_FLAG BIT(5) > +#define SPI_CFG3_IPM_CMD_BYTELEN_OFFSET8 > +#define SPI_CFG3_IPM_ADDR_BYTELEN_OFFSET 12 > +#define SPI_CFG3_IPM_DUMMY_BYTELEN_OFFSET 16 > + > +#define SPI_CFG3_IPM_CMD_PIN_MODE_MASK GENMASK(1, 0) > +#define SPI_CFG3_IPM_CMD_BYTELEN_MASK GENMASK(11, 8) > +#define
Re: [PATCH 07/31] net: mediatek: stop using bitfileds for DMA descriptors
On Wed, 3 Aug 2022 at 21:36, Weijie Gao wrote: > > This patch is a preparation for adding a new version of PDMA of which the > DMA descriptor fields has changed. Using bitfields will result in a complex > modification. Convert bitfields to u32 units can solve this problem easily. > > Signed-off-by: Weijie Gao > --- > drivers/net/mtk_eth.c | 144 ++ > drivers/net/mtk_eth.h | 32 ++ > 2 files changed, 80 insertions(+), 96 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 17/31] i2c: add support for MediaTek I2C interface
Hi Weijie,
On Wed, 3 Aug 2022 at 21:38, Weijie Gao wrote:
>
> 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
>
Reviewed-by: Simon Glass
[..]
> 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
> +
[..]
> +
> +U_BOOT_DRIVER(mtk_i2c) = {
> + .name = "mtk_i2c",
> + .id = UCLASS_I2C,
> + .of_match = mtk_i2c_ids,
> + .of_to_plat = mtk_i2c_ofdata_to_platdata,
mtk_i2c_of_to_plat (for consistency)
> + .probe = mtk_i2c_probe,
> + .priv_auto = sizeof(struct mtk_i2c_priv),
> + .ops= _i2c_ops,
> +};
> --
> 2.17.1
>
Regards,
Simon
Re: [PATCH 18/31] arm: dts: mt7622: add i2c support
On Wed, 3 Aug 2022 at 21:38, Weijie Gao wrote: > > 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(+) Reviewed-by: Simon Glass
Re: [PATCH 2/3] binman: Remove header from compressed data
Hi Stefan,
On Thu, 4 Aug 2022 at 01:50, Stefan Herbrechtsmeier
wrote:
>
> Hi Simon,
>
> Am 03.08.2022 um 20:14 schrieb 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.
>
> Does this means the size is only needed for the creation of the fitImage
> and not for decompression in u-boot?
Possibly, but of course we cannot do that. As you say, U-Boot mainline
does not expect or support the header, at present.
>
> >
> >>
> >> Do you have a test for this use case?
> >
> > There are various ones, e.g. testCompressDtb()
>
> Thanks. Now I understand the problem and why you call it a
> chicken-and-egg problem. It wasn't clear to me that the attributes are
> inside the DTB.
OK good.
>
> But I wonder how the decompression of the DTB works if the fitImage
> implementation doesn't support the header.
It doesn't. Something needs to change here for compression to work.
>
> >>> 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.
>
> Do we need the header outside of the DTB? Otherwise we could handle this
> special or we could add a special compression type.
>
> > 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.
>
> Do we really need the header outside of the DTB entry?
That's an interesting question. It is possible that we only need it if
DTB is present and is compressed. It should be possible to check this
by adjusting the tests and checking for failures.
But I am not sure it is a good idea, since it is wildly inconsistent.
I do prefer things to be deterministic - i.e. you specify what you
want and you get it. If binman starts adopting obscure conventions it
could be confusing.
Regards,
Simon
Re: [PATCH 19/31] dt-bindings: pinctrl: mediatek: add a header for common pinconf parameters
On Wed, 3 Aug 2022 at 21:38, Weijie Gao wrote: > > 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 Reviewed-by: Simon Glass
Re: [PATCH 22/31] clk: mediatek: add CLK_BYPASS_XTAL flag to allow bypassing searching clock parent of xtal clock
Hi Weijie,
On Wed, 3 Aug 2022 at 21:39, Weijie Gao wrote:
>
> The mtk clock framework in u-boot uses array index for searching clock
> parent (kernel uses strings for search), so we need to specify a special
> clock with ID=0 for CLK_XTAL in u-boot.
>
> In the mt7622/mt7629 clock tree, the clocks with ID=0 never call
> mtk_topckgen_get_mux_rate, adn return xtal clock directly. This what we
> expected.
>
> However for newer chips, they may have some clocks with ID=0 not
> representing the xtal clock and still needs mtk_topckgen_get_mux_rate be
> called. Current logic will make entire clock driver not working.
>
> This patch adds a flag to indicate that whether a clock driver needs clocks
> with ID=0 to call mtk_topckgen_get_mux_rate.
>
> 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(-)
Reviewed-by: Simon Glass
>
> 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 = >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;
This needs a comment as to what the flags mean
> };
>
> struct mtk_clk_priv {
> --
> 2.17.1
>
Regards,
Simon
Re: [PATCH 27/31] clk: mediatek: add clock driver support for MediaTek MT7981 SoC
Hi Weijie, On Wed, 3 Aug 2022 at 21:40, Weijie Gao wrote: > > 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 Reviewed-by: Simon Glass use if CONFIG_IS_ENABLED(RESET_MEDIATEK) Regards, Simon
Re: [PATCH 24/31] clk: mediatek: add infrasys clock mux support
On Wed, 3 Aug 2022 at 21:39, Weijie Gao wrote: > > 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(-) > Reviewed-by: Simon Glass
[PATCH 04/13] reset: qcom: Add support for QCS404 SoC reset table
Signed-off-by: Sumit Garg
---
drivers/reset/reset-qcom.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/reset/reset-qcom.c b/drivers/reset/reset-qcom.c
index 40f436ede4..94315e76d5 100644
--- a/drivers/reset/reset-qcom.c
+++ b/drivers/reset/reset-qcom.c
@@ -102,6 +102,35 @@ static const struct qcom_reset_map gcc_qcom_resets[] = {
};
#endif
+#ifdef CONFIG_TARGET_QCS404EVB
+#include
+static const struct qcom_reset_map gcc_qcom_resets[] = {
+ [GCC_GENI_IR_BCR] = { 0x0F000 },
+ [GCC_CDSP_RESTART] = { 0x18000 },
+ [GCC_USB_HS_BCR] = { 0x41000 },
+ [GCC_USB2_HS_PHY_ONLY_BCR] = { 0x41034 },
+ [GCC_QUSB2_PHY_BCR] = { 0x4103c },
+ [GCC_USB_HS_PHY_CFG_AHB_BCR] = { 0xc, 1 },
+ [GCC_USB2A_PHY_BCR] = { 0xc, 0 },
+ [GCC_USB3_PHY_BCR] = { 0x39004 },
+ [GCC_USB_30_BCR] = { 0x39000 },
+ [GCC_USB3PHY_PHY_BCR] = { 0x39008 },
+ [GCC_PCIE_0_BCR] = { 0x3e000 },
+ [GCC_PCIE_0_PHY_BCR] = { 0x3e004 },
+ [GCC_PCIE_0_LINK_DOWN_BCR] = { 0x3e038 },
+ [GCC_PCIEPHY_0_PHY_BCR] = { 0x3e03c },
+ [GCC_PCIE_0_AXI_MASTER_STICKY_ARES] = { 0x3e040, 6},
+ [GCC_PCIE_0_AHB_ARES] = { 0x3e040, 5 },
+ [GCC_PCIE_0_AXI_SLAVE_ARES] = { 0x3e040, 4 },
+ [GCC_PCIE_0_AXI_MASTER_ARES] = { 0x3e040, 3 },
+ [GCC_PCIE_0_CORE_STICKY_ARES] = { 0x3e040, 2 },
+ [GCC_PCIE_0_SLEEP_ARES] = { 0x3e040, 1 },
+ [GCC_PCIE_0_PIPE_ARES] = { 0x3e040, 0 },
+ [GCC_EMAC_BCR] = { 0x4e000 },
+ [GCC_WDSP_RESTART] = {0x19000},
+};
+#endif
+
static int qcom_reset_assert(struct reset_ctl *rst)
{
struct qcom_reset_priv *priv = dev_get_priv(rst->dev);
@@ -141,6 +170,7 @@ static const struct reset_ops qcom_reset_ops = {
static const struct udevice_id qcom_reset_ids[] = {
{ .compatible = "qcom,gcc-reset-ipq4019" },
+ { .compatible = "qcom,gcc-reset-qcs404" },
{ }
};
--
2.25.1
[PATCH 07/13] clocks: qcs404: Add support for USB clocks
Add support for USB controller and PHY clocks for QCS404 SoC.
Signed-off-by: Sumit Garg
---
arch/arm/mach-snapdragon/clock-qcs404.c | 35 +++
.../include/mach/sysmap-qcs404.h | 17 +
2 files changed, 52 insertions(+)
diff --git a/arch/arm/mach-snapdragon/clock-qcs404.c
b/arch/arm/mach-snapdragon/clock-qcs404.c
index 230d7779a7..6fe92afe8d 100644
--- a/arch/arm/mach-snapdragon/clock-qcs404.c
+++ b/arch/arm/mach-snapdragon/clock-qcs404.c
@@ -47,6 +47,14 @@ static struct pll_vote_clk gpll0_vote_clk = {
.vote_bit = BIT(0),
};
+static const struct bcr_regs usb30_master_regs = {
+ .cfg_rcgr = USB30_MASTER_CFG_RCGR,
+ .cmd_rcgr = USB30_MASTER_CMD_RCGR,
+ .M = USB30_MASTER_M,
+ .N = USB30_MASTER_N,
+ .D = USB30_MASTER_D,
+};
+
ulong msm_set_rate(struct clk *clk, ulong rate)
{
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
@@ -80,5 +88,32 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
int msm_enable(struct clk *clk)
{
+ struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+
+ switch (clk->id) {
+ case GCC_USB30_MASTER_CLK:
+ clk_enable_cbc(priv->base + USB30_MASTER_CBCR);
+ clk_rcg_set_rate_mnd(priv->base, _master_regs, 4, 0, 0,
+CFG_CLK_SRC_GPLL0);
+ break;
+ case GCC_SYS_NOC_USB3_CLK:
+ clk_enable_cbc(priv->base + SYS_NOC_USB3_CBCR);
+ break;
+ case GCC_USB30_SLEEP_CLK:
+ clk_enable_cbc(priv->base + USB30_SLEEP_CBCR);
+ break;
+ case GCC_USB30_MOCK_UTMI_CLK:
+ clk_enable_cbc(priv->base + USB30_MOCK_UTMI_CBCR);
+ break;
+ case GCC_USB_HS_PHY_CFG_AHB_CLK:
+ clk_enable_cbc(priv->base + USB_HS_PHY_CFG_AHB_CBCR);
+ break;
+ case GCC_USB2A_PHY_SLEEP_CLK:
+ clk_enable_cbc(priv->base + USB_HS_PHY_CFG_AHB_CBCR);
+ break;
+ default:
+ return 0;
+ }
+
return 0;
}
diff --git a/arch/arm/mach-snapdragon/include/mach/sysmap-qcs404.h
b/arch/arm/mach-snapdragon/include/mach/sysmap-qcs404.h
index 4dc96b9fbc..e448faad2d 100644
--- a/arch/arm/mach-snapdragon/include/mach/sysmap-qcs404.h
+++ b/arch/arm/mach-snapdragon/include/mach/sysmap-qcs404.h
@@ -37,4 +37,21 @@
#define SDCC_APPS_CBCR(n) (((n) * 0x1000) + 0x41018)
#define SDCC_AHB_CBCR(n) (((n) * 0x1000) + 0x4101C)
+/* USB-3.0 controller clock control registers */
+#define SYS_NOC_USB3_CBCR (0x26014)
+#define USB30_BCR (0x39000)
+#define USB3PHY_BCR(0x39008)
+#define USB30_MASTER_CBCR (0x3900C)
+#define USB30_SLEEP_CBCR (0x39010)
+#define USB30_MOCK_UTMI_CBCR (0x39014)
+#define USB30_MOCK_UTMI_CMD_RCGR (0x3901C)
+#define USB30_MOCK_UTMI_CFG_RCGR (0x39020)
+#define USB30_MASTER_CMD_RCGR (0x39028)
+#define USB30_MASTER_CFG_RCGR (0x3902C)
+#define USB30_MASTER_M (0x39030)
+#define USB30_MASTER_N (0x39034)
+#define USB30_MASTER_D (0x39038)
+#define USB2A_PHY_SLEEP_CBCR (0x4102C)
+#define USB_HS_PHY_CFG_AHB_CBCR(0x41030)
+
#endif
--
2.25.1
[PATCH 05/13] dts: qcs404-evb: Add reset controller node
Signed-off-by: Sumit Garg
---
arch/arm/dts/qcs404-evb.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 09687e1fd3..1b280efff6 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -54,6 +54,12 @@
#size-cells = <0x0>;
};
+ reset: gcc-reset@180 {
+ compatible = "qcom,gcc-reset-qcs404";
+ reg = <0x180 0x8>;
+ #reset-cells = <1>;
+ };
+
debug_uart: serial@78b1000 {
compatible = "qcom,msm-uartdm-v1.4";
reg = <0x78b1000 0x200>;
--
2.25.1
[PATCH 06/13] clocks: qcom: Add clock enable callback support
Drivers like USB, ethernet etc. uses ".enable" hook to enable clocks.
So add corresponding support for Qcom clock drivers.
Signed-off-by: Sumit Garg
---
arch/arm/mach-snapdragon/clock-apq8016.c| 5 +
arch/arm/mach-snapdragon/clock-apq8096.c| 5 +
arch/arm/mach-snapdragon/clock-qcs404.c | 5 +
arch/arm/mach-snapdragon/clock-sdm845.c | 5 +
arch/arm/mach-snapdragon/clock-snapdragon.c | 7 +++
5 files changed, 27 insertions(+)
diff --git a/arch/arm/mach-snapdragon/clock-apq8016.c
b/arch/arm/mach-snapdragon/clock-apq8016.c
index 6e4a0ccb90..23a37a1714 100644
--- a/arch/arm/mach-snapdragon/clock-apq8016.c
+++ b/arch/arm/mach-snapdragon/clock-apq8016.c
@@ -111,3 +111,8 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
return 0;
}
}
+
+int msm_enable(struct clk *clk)
+{
+ return 0;
+}
diff --git a/arch/arm/mach-snapdragon/clock-apq8096.c
b/arch/arm/mach-snapdragon/clock-apq8096.c
index e5011be8f2..66184596d5 100644
--- a/arch/arm/mach-snapdragon/clock-apq8096.c
+++ b/arch/arm/mach-snapdragon/clock-apq8096.c
@@ -93,3 +93,8 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
return 0;
}
}
+
+int msm_enable(struct clk *clk)
+{
+ return 0;
+}
diff --git a/arch/arm/mach-snapdragon/clock-qcs404.c
b/arch/arm/mach-snapdragon/clock-qcs404.c
index bb8a6fe067..230d7779a7 100644
--- a/arch/arm/mach-snapdragon/clock-qcs404.c
+++ b/arch/arm/mach-snapdragon/clock-qcs404.c
@@ -77,3 +77,8 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
return 0;
}
+
+int msm_enable(struct clk *clk)
+{
+ return 0;
+}
diff --git a/arch/arm/mach-snapdragon/clock-sdm845.c
b/arch/arm/mach-snapdragon/clock-sdm845.c
index f69be80898..d6df0365af 100644
--- a/arch/arm/mach-snapdragon/clock-sdm845.c
+++ b/arch/arm/mach-snapdragon/clock-sdm845.c
@@ -91,3 +91,8 @@ ulong msm_set_rate(struct clk *clk, ulong rate)
return 0;
}
}
+
+int msm_enable(struct clk *clk)
+{
+ return 0;
+}
diff --git a/arch/arm/mach-snapdragon/clock-snapdragon.c
b/arch/arm/mach-snapdragon/clock-snapdragon.c
index 5652d2fa36..fda7098274 100644
--- a/arch/arm/mach-snapdragon/clock-snapdragon.c
+++ b/arch/arm/mach-snapdragon/clock-snapdragon.c
@@ -20,6 +20,7 @@
#define CBCR_BRANCH_OFF_BIT BIT(31)
extern ulong msm_set_rate(struct clk *clk, ulong rate);
+extern int msm_enable(struct clk *clk);
/* Enable clock controlled by CBC soft macro */
void clk_enable_cbc(phys_addr_t cbcr)
@@ -126,8 +127,14 @@ static ulong msm_clk_set_rate(struct clk *clk, ulong rate)
return msm_set_rate(clk, rate);
}
+static int msm_clk_enable(struct clk *clk)
+{
+ return msm_enable(clk);
+}
+
static struct clk_ops msm_clk_ops = {
.set_rate = msm_clk_set_rate,
+ .enable = msm_clk_enable,
};
static const struct udevice_id msm_clk_ids[] = {
--
2.25.1
[PATCH 13/13] qcs404evb_defconfig: Enable USB configs
Enable USB config options along with its dependencies like PHY, RESET, PMIC GPIO etc. config options. Signed-off-by: Sumit Garg --- configs/qcs404evb_defconfig | 18 ++ 1 file changed, 18 insertions(+) diff --git a/configs/qcs404evb_defconfig b/configs/qcs404evb_defconfig index d45f6b2348..432d5d50c1 100644 --- a/configs/qcs404evb_defconfig +++ b/configs/qcs404evb_defconfig @@ -27,6 +27,7 @@ CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y +CONFIG_CMD_USB=y # CONFIG_NET is not set CONFIG_CLK=y CONFIG_MMC_HS400_SUPPORT=y @@ -35,4 +36,21 @@ CONFIG_MMC_SDHCI_ADMA=y CONFIG_MMC_SDHCI_MSM=y CONFIG_PINCTRL=y CONFIG_MSM_SERIAL=y +CONFIG_SPMI_MSM=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_QCOM=y +CONFIG_QCOM_PMIC_GPIO=y +CONFIG_MISC=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_STORAGE=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_DM_RESET=y +CONFIG_RESET_QCOM=y +CONFIG_PHY=y +CONFIG_PHY_QCOM_USB_HS_28NM=y +CONFIG_PHY_QCOM_USB_SS=y CONFIG_LMB_MAX_REGIONS=64 -- 2.25.1
Re: [PATCH 1/5] arm: mvebu: a7040/a8040/cn9130: Add spi0 dts reference
On 03.08.22 13:00, Pali Rohár wrote:
For future changes it is needed for have spi0 device tree reference in
every mvebu soc dts file even when it is unused.
Signed-off-by: Pali Rohár
---
arch/arm/dts/armada-7040.dtsi | 3 +++
arch/arm/dts/armada-8040.dtsi | 3 +++
arch/arm/dts/cn9130.dtsi | 3 +++
3 files changed, 9 insertions(+)
You're changing 64-bit Armada files here, but in the cover letter you
mention that this patchset only addresses 32-bit mvebu DT files. So
why are you making these changes here?
One more comment below...
diff --git a/arch/arm/dts/armada-7040.dtsi b/arch/arm/dts/armada-7040.dtsi
index 039d30c72a8c..1fb21c6bfde0 100644
--- a/arch/arm/dts/armada-7040.dtsi
+++ b/arch/arm/dts/armada-7040.dtsi
@@ -63,3 +63,6 @@
marvell,function = <3>;
};
};
+
+spi0: _spi1 {
+};
Why is spi0 aliased now to "cp0_spi1"? In the Kernel DT files I see
this:
spi0 =
spi1 = _spi0;
spi2 = _spi1;
...
spi0: spi@510600 {
Thanks,
Stefan
diff --git a/arch/arm/dts/armada-8040.dtsi b/arch/arm/dts/armada-8040.dtsi
index eec5fa277405..608ff0d97f95 100644
--- a/arch/arm/dts/armada-8040.dtsi
+++ b/arch/arm/dts/armada-8040.dtsi
@@ -87,3 +87,6 @@
marvell,function = <3>;
};
};
+
+spi0: _spi1 {
+};
diff --git a/arch/arm/dts/cn9130.dtsi b/arch/arm/dts/cn9130.dtsi
index 68b767a70639..a200276f7a2e 100644
--- a/arch/arm/dts/cn9130.dtsi
+++ b/arch/arm/dts/cn9130.dtsi
@@ -71,3 +71,6 @@
marvell,function = <3>;
};
};
+
+spi0: _spi1 {
+};
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
Re: [PATCH 5/5] arm: mvebu: armada-38x-controlcenterdc.dts: Move u-boot,dm-pre-reloc to -u-boot.dtsi
On 03.08.22 13:00, Pali Rohár wrote:
Move U-Boot specific device tree property u-boot,dm-pre-reloc into U-Boot
specific device tree include file armada-38x-controlcenterdc-u-boot.dtsi.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
.../armada-38x-controlcenterdc-u-boot.dtsi| 25 +++
arch/arm/dts/armada-38x-controlcenterdc.dts | 16
2 files changed, 25 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/dts/armada-38x-controlcenterdc-u-boot.dtsi
diff --git a/arch/arm/dts/armada-38x-controlcenterdc-u-boot.dtsi
b/arch/arm/dts/armada-38x-controlcenterdc-u-boot.dtsi
new file mode 100644
index ..0a94df923058
--- /dev/null
+++ b/arch/arm/dts/armada-38x-controlcenterdc-u-boot.dtsi
@@ -0,0 +1,25 @@
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+#include "mvebu-u-boot.dtsi"
diff --git a/arch/arm/dts/armada-38x-controlcenterdc.dts
b/arch/arm/dts/armada-38x-controlcenterdc.dts
index b5d76f8b22d6..79ea6f090958 100644
--- a/arch/arm/dts/armada-38x-controlcenterdc.dts
+++ b/arch/arm/dts/armada-38x-controlcenterdc.dts
@@ -16,18 +16,6 @@
#include "armada-388.dtsi"
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
/ {
model = "Controlcenter Digital Compact";
compatible = "marvell,a385-db", "marvell,armada388",
@@ -71,7 +59,6 @@
I2C0: i2c@11000 {
status = "okay";
clock-frequency = <100>;
- u-boot,dm-pre-reloc;
PCA21: pca9698@21 {
compatible = "nxp,pca9698";
reg = <0x21>;
@@ -80,7 +67,6 @@
};
PCA22: pca9698@22 {
compatible = "nxp,pca9698";
- u-boot,dm-pre-reloc;
reg = <0x22>;
#gpio-cells = <2>;
gpio-controller;
@@ -565,7 +551,6 @@
{
status = "okay";
- u-boot,dm-pre-reloc;
spi-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
@@ -579,6 +564,5 @@
compatible = "n25q128a11", "jedec,spi-nor";
reg = <1>; /* Chip select 1 */
spi-max-frequency = <10800>;
- u-boot,dm-pre-reloc;
};
};
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
Re: [PATCH 3/5] arm: mvebu: Remove redundant u-boot, dm-pre-reloc from all 32-bit Armada SoCs
On 03.08.22 13:00, Pali Rohár wrote:
Replace it by including of mvebu-u-boot.dtsi file. When board does not use
-u-boot.dtsi then mvebu-u-boot.dtsi is included automatically by makefile
scripts/Makefile.lib.
Signed-off-by: Pali Rohár
---
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 ++
arch/arm/dts/armada-38x-controlcenterdc.dts | 4
.../arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
arch/arm/dts/armada-38x.dtsi | 2 --
.../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 -
arch/arm/dts/armada-xp-theadorable.dts| 3 ---
arch/arm/dts/armada-xp.dtsi | 1 -
25 files changed, 8 insertions(+), 125 deletions(-)
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
Very nice diffstat. :)
Reviewed-by: Stefan Roese
Tested-by: Stefan Roese
Thanks,
Stefan
diff --git a/arch/arm/dts/armada-370-xp.dtsi b/arch/arm/dts/armada-370-xp.dtsi
index 4cd168c95784..310f159cd5dd 100644
--- a/arch/arm/dts/armada-370-xp.dtsi
+++ b/arch/arm/dts/armada-370-xp.dtsi
@@ -102,7 +102,6 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
- u-boot,dm-pre-reloc;
rtc: rtc@10300 {
compatible = "marvell,orion-rtc";
diff --git a/arch/arm/dts/armada-375-db.dts b/arch/arm/dts/armada-375-db.dts
index 343349b8fd6e..d77883900649 100644
--- a/arch/arm/dts/armada-375-db.dts
+++ b/arch/arm/dts/armada-375-db.dts
@@ -86,10 +86,8 @@
* by default.
*/
status = "okay";
- u-boot,dm-pre-reloc;
spi-flash@0 {
- u-boot,dm-pre-reloc;
#address-cells = <1>;
#size-cells = <1>;
compatible = "n25q128a13",
"jedec,spi-nor";
@@ -113,7 +111,6 @@
};
serial@12000 {
- u-boot,dm-pre-reloc;
status = "okay";
};
diff --git a/arch/arm/dts/armada-375.dtsi b/arch/arm/dts/armada-375.dtsi
index fcb9245fd496..20a8c352b2f1 100644
--- a/arch/arm/dts/armada-375.dtsi
+++ b/arch/arm/dts/armada-375.dtsi
@@ -103,7 +103,6 @@
soc {
compatible = "marvell,armada375-mbus", "simple-bus";
- u-boot,dm-pre-reloc;
#address-cells = <2>;
#size-cells = <1>;
controller = <>;
@@ -168,7 +167,6 @@
internal-regs {
compatible = "simple-bus";
- u-boot,dm-pre-reloc;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
index 79b694cb84bc..4a3fb2ce4083 100644
--- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
+++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
@@ -1,17 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
- {
- u-boot,dm-pre-reloc;
-
- spi-flash@0 {
- u-boot,dm-pre-reloc;
- };
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
{
u-boot,dm-pre-reloc;
};
+
+#include "mvebu-u-boot.dtsi"
diff --git a/arch/arm/dts/armada-385-db-88f6820-amc.dts
b/arch/arm/dts/armada-385-db-88f6820-amc.dts
index
Re: [PATCH 1/5] arm: mvebu: a7040/a8040/cn9130: Add spi0 dts reference
On Thursday 04 August 2022 16:51:47 Stefan Roese wrote:
> On 03.08.22 13:00, Pali Rohár wrote:
> > For future changes it is needed for have spi0 device tree reference in
> > every mvebu soc dts file even when it is unused.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > arch/arm/dts/armada-7040.dtsi | 3 +++
> > arch/arm/dts/armada-8040.dtsi | 3 +++
> > arch/arm/dts/cn9130.dtsi | 3 +++
> > 3 files changed, 9 insertions(+)
>
> You're changing 64-bit Armada files here, but in the cover letter you
> mention that this patchset only addresses 32-bit mvebu DT files. So
> why are you making these changes here?
The main issue is that 64-bit Armada DTS files are compiled also during
32-bit Armada builds. And 32-bit Armada DTS files needs spi0 reference
because it is used in 32-bit Armada section in mvebu-u-boot.dtsi file.
I know it is broken build system if during compilation of 32-bit SoC are
compiled also unrelated 64-bit Armada DTS files in 32-bit mode. But I do
not see currently easier solution than just define "harmless" reference.
During 64-bit Armada builds is content of mvebu-u-boot.dtsi skipped as
there is a 32-bit guard.
Proper way, of course, would be to fix build system, so none 64-bit file
is compiled (and let unused) during 32-bit build.
> One more comment below...
>
> > diff --git a/arch/arm/dts/armada-7040.dtsi b/arch/arm/dts/armada-7040.dtsi
> > index 039d30c72a8c..1fb21c6bfde0 100644
> > --- a/arch/arm/dts/armada-7040.dtsi
> > +++ b/arch/arm/dts/armada-7040.dtsi
> > @@ -63,3 +63,6 @@
> > marvell,function = <3>;
> > };
> > };
> > +
> > +spi0: _spi1 {
> > +};
>
> Why is spi0 aliased now to "cp0_spi1"?
Because cp0_spi1 is used in U-Boot 64-bit Armada DTS files as "spi0"
alias. Really.
> In the Kernel DT files I see
> this:
>
> spi0 =
> spi1 = _spi0;
> spi2 = _spi1;
> ...
> spi0: spi@510600 {
And you bring another issue :-) U-Boot DTS files for 64-bit Armada SoCs
(expects 3720) differs from kernel DTS files. They are incompatible and
nobody fixed this issue yet. I fixed it only for 64-bit Armada 3720 as
we are using and maintaining Armada 3720 boards.
So I just do not know what to do with remaining 64-bit
A7040/A8040/CN9030 SoCs. I just added simple harmless change which do
not change behavior nor output of those boards.
Either somebody has to start working on fixing U-Boot support and DTS
files for those boards to be compatible with Linux kernel. Or those SoCs
stays incompatible with Linux and their technical debt in U-Boot code
just grow. Or you as maintainer can decide that they are unmaintained
(and ready for removal?).
I'm just not going to do this big cleanup for A7040/A8040/CN9030 SoCs too.
> Thanks,
> Stefan
>
> > diff --git a/arch/arm/dts/armada-8040.dtsi b/arch/arm/dts/armada-8040.dtsi
> > index eec5fa277405..608ff0d97f95 100644
> > --- a/arch/arm/dts/armada-8040.dtsi
> > +++ b/arch/arm/dts/armada-8040.dtsi
> > @@ -87,3 +87,6 @@
> > marvell,function = <3>;
> > };
> > };
> > +
> > +spi0: _spi1 {
> > +};
> > diff --git a/arch/arm/dts/cn9130.dtsi b/arch/arm/dts/cn9130.dtsi
> > index 68b767a70639..a200276f7a2e 100644
> > --- a/arch/arm/dts/cn9130.dtsi
> > +++ b/arch/arm/dts/cn9130.dtsi
> > @@ -71,3 +71,6 @@
> > marvell,function = <3>;
> > };
> > };
> > +
> > +spi0: _spi1 {
> > +};
>
> 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
Re: [PATCH] doc: dm: clarify activation.
Hi Michal, On Thu, 4 Aug 2022 at 11:58, Michal Suchanek wrote: > > Explain when devices should get activated. > > Signed-off-by: Michal Suchanek > --- > doc/develop/driver-model/design.rst | 22 -- > 1 file changed, 20 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass Much appreciated! one note below > > diff --git a/doc/develop/driver-model/design.rst > b/doc/develop/driver-model/design.rst > index 5f33f9fbb3..c925d21b24 100644 > --- a/doc/develop/driver-model/design.rst > +++ b/doc/develop/driver-model/design.rst > @@ -794,8 +794,26 @@ fall afoul of this rule. > Activation/probe > > > -When a device needs to be used, U-Boot activates it, by first reading ofdata > -as above and then following these steps (see device_probe()): > +To save resources devices in U-Boot are probed lazily. U-Boot is a > bootloader, > +not an operating system. Many devices are never used during an U-Boot run, > and > +probing them takes time, requires memory, may add delays to the main loop, > etc. > + > +The device should be probed by the uclass code. Different uclasses are or the device code (e.g. device_get_child()) BTW probing a child probes all its parents automatically (that is said elsewhere I think). > +different but two common use cases can be seen: > + > + 1. The uclass is asked to look up a specific device, such as SPI bus 0, > + first chip select - in this case the returned device should be > + activated. > + > + 2. The uclass is asked to perform a specific function on any device that > + supports it, eg. reset the board using any sysreset that can be found - > + for this case the core uclass code provides iterators that activate > + each device before returning it, and the uclass typically implements a > + walk function that iterates over all devices of the uclass and tries > + to perform the requested function on each in turn until succesful. > + > +To activate a device U-Boot first reads ofdata as above and then follows > these > +steps (see device_probe()): > > 1. All parent devices are probed. It is not possible to activate a device > unless its predecessors (all the way up to the root device) are activated. > -- > 2.37.1 > Regards, Simon
Re: [PATCH] dm: core: Do not stop uclass iteration on error.
Hi Michal,
On Thu, 4 Aug 2022 at 11:59, Michal Suchanek wrote:
>
> When probing a device fails NULL pointer is returned, and other devices
> cannot be iterated. Skip to next device on error instead.
>
> Fixes: 6494d708bf ("dm: Add base driver model support")
> Signed-off-by: Michal Suchanek
> ---
> drivers/core/uclass.c | 30 +-
> 1 file changed, 21 insertions(+), 9 deletions(-)
Are you able to create a test for this, e.g. in test/dm/core.c or test-fdt.c ?
Some sandbox devices can be made to give an error, so the test can
check the logic.
Strangely enough, this is actually a very big change, so we need to be careful.
>
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index 08d9ed82de..ccf7d59141 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -574,16 +574,31 @@ int uclass_get_device_by_phandle(enum uclass_id id,
> struct udevice *parent,
> }
> #endif
>
> +/* Starting from the given device return first device in the uclass that
> probes successfully */
> +static int __uclass_next_device(struct udevice *dev, int ret, struct udevice
> **devp)
> +{
> + if (!dev) {
> + *devp = dev;
> + return 0;
> + }
> + while ((ret = uclass_get_device_tail(dev, ret, devp))) {
> + ret = uclass_find_next_device();
> + if (!dev) {
> + *devp = dev;
> + return 0;
> + }
> + }
> +
> + return ret;
> +}
> +
> int uclass_first_device(enum uclass_id id, struct udevice **devp)
> {
> - struct udevice *dev;
> + struct udevice *dev = NULL;
> int ret;
>
> - *devp = NULL;
> ret = uclass_find_first_device(id, );
> - if (!dev)
> - return 0;
> - return uclass_get_device_tail(dev, ret, devp);
> + return __uclass_next_device(dev, ret, devp);
> }
>
> int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
> @@ -604,11 +619,8 @@ int uclass_next_device(struct udevice **devp)
> struct udevice *dev = *devp;
> int ret;
>
> - *devp = NULL;
> ret = uclass_find_next_device();
> - if (!dev)
> - return 0;
> - return uclass_get_device_tail(dev, ret, devp);
> + return __uclass_next_device(dev, ret, devp);
> }
>
> int uclass_next_device_err(struct udevice **devp)
> --
> 2.37.1
>
Regards,
Simon
Re: EFI CI failure
Hi Heinrich, On Wed, 3 Aug 2022 at 23:53, Heinrich Schuchardt wrote: > > > > 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). Can I ask you to dig into this as it is EFI? Why do we need to restart? > > 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
