[PATCH v3 3/5] board: sl28: enable EFI UpdateCapsule support
Enable support for update over EFI UpdateCapsule mechanism. This board
doesn't support setting EFI variables after ExitBootservices().
Therefore, we are also enabling EFI_IGNORE_OSINDICATIONS.
Signed-off-by: Michael Walle
---
changes since v2:
- use CONFIG_EFI_CAPSULE_FIRMWARE_FIT instead of
CONFIG_EFI_CAPSULE_FIRMWARE_RAW
changes since v1:
- new patch
configs/kontron_sl28_defconfig | 6 ++
include/configs/kontron_sl28.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
index ae729efdfe..9dbdd5277c 100644
--- a/configs/kontron_sl28_defconfig
+++ b/configs/kontron_sl28_defconfig
@@ -60,6 +60,8 @@ CONFIG_SCSI_AHCI=y
CONFIG_SATA_CEVA=y
CONFIG_FSL_CAAM=y
CONFIG_SYS_FSL_DDR3=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_SF=y
CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
CONFIG_I2C_DEFAULT_BUS_NUMBER=0
CONFIG_I2C_MUX=y
@@ -92,3 +94,7 @@ CONFIG_USB_XHCI_DWC3=y
CONFIG_OF_LIBFDT_ASSUME_MASK=0x0
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_EFI_SET_TIME=y
+CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_IGNORE_OSINDICATIONS=y
+CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
diff --git a/include/configs/kontron_sl28.h b/include/configs/kontron_sl28.h
index bfb4e67c8f..a02b8ce2b1 100644
--- a/include/configs/kontron_sl28.h
+++ b/include/configs/kontron_sl28.h
@@ -96,6 +96,8 @@
"envload=env import -d -b ${env_addr}\0" \
"install_rcw=source 2020\0" \
"fdtfile=freescale/fsl-ls1028a-kontron-sl28.dtb\0" \
+ "dfu_alt_info=sf 0:0=u-boot-bin raw 0x21 0x1d;" \
+ "u-boot-env raw 0x3e 0x2\0" \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV
--
2.30.2
[PATCH v3 5/5] board: sl28: add update image documentation
Document the update image and how to use the EFI UpdateCapsule. Signed-off-by: Michael Walle --- changes since v2: - none changes since v1: - new patch doc/board/kontron/sl28.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst index 07431986d8..c7b18bed10 100644 --- a/doc/board/kontron/sl28.rst +++ b/doc/board/kontron/sl28.rst @@ -52,6 +52,21 @@ Disable the builtin watchdog - power-cycle the board +Update image + + +After the build finished, there will be an update image called +u-boot.update. This can either be used in the DFU mode (which isn't +supported yet) or encapsulated in an EFI UpdateCapsule. + +To build the capsule use the following command + + $ tools/mkeficapsule -f u-boot.update -i 1 UpdateUboot + +Afterward you can copy this file to your ESP into the /EFI/UpdateCapsule/ +folder. On the next EFI boot this will automatically update your +bootloader. + Useful I2C tricks - -- 2.30.2
Re: Driver model at UEFI runtime
Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: On 9/30/21 8:23 AM, François Ozog wrote: [..] Is U-Boot's UEFI loader implementation supposed to be the recommended UEFI firmware on ARM and RISC-V on a production / deployment system? For Arm: yes, that is SystemReady spec. For RISC-V it is required by the RISC-V platform specification. Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we expect to load grub.efi which chain-loads a kernel without CONFIG_EFI_STUB? all paths should be possible , and the shim.efi is to be supported too. With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In other words I don’t see grub.efi booting a non config_efi_stub. What do distributions normally do? At least Red Hat made it clear at multiple Linaro Connect that they want standards, and SystemReady is one that makes the life of embedded distros easy. Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot. For Fedora see https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description SUSE started the UEFI implementation to boot on all architectures in the same way. The current ARM and RISC-V images uses UEFI. Debian and Ubuntu install for booting via GRUB if the installer is invoked via UEFI. A fallback solution using the legacy Linux entry point exists. For BSD the only way to boot on ARM is via UEFI. What's our position when compared to EDK II? U-Boot implements only a subset of UEFI defined in the EBBR specification. For servers you need a larger scope which is offered by EDK II. This is required both by the RISC-V platform specification as well as the ARM SystemReady ServerReady profile. The number of boards supported by upstream EDK II is very low. But proprietary firmware based on EDK II exists. the typical distro boot flow is not the most efficient and drags concept dating where the Microsoft certs had to be part of the picture. A direct U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path (grub), avoids convoluted platform cert management (shim) and just This is why U-Boot supports UEFI boot options specifying both a binary as well as an initial RAM disk. I might be late to this, but where does the devicetree come from? As far as I understand it right now, for most (all) the SytemReady IR certified boards, the compiled-in one from u-boot is passed to linux. This won't work in the long run, because the devicetrees keep getting incompatible changes. So while it work for one kernel version it might not work on the next version. -michael
Re: Driver model at UEFI runtime
Am 2021-09-30 12:50, schrieb Heinrich Schuchardt: Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle : Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: On 9/30/21 8:23 AM, François Ozog wrote: [..] Is U-Boot's UEFI loader implementation supposed to be the recommended UEFI firmware on ARM and RISC-V on a production / deployment system? For Arm: yes, that is SystemReady spec. For RISC-V it is required by the RISC-V platform specification. Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we expect to load grub.efi which chain-loads a kernel without CONFIG_EFI_STUB? all paths should be possible , and the shim.efi is to be supported too. With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In other words I don’t see grub.efi booting a non config_efi_stub. What do distributions normally do? At least Red Hat made it clear at multiple Linaro Connect that they want standards, and SystemReady is one that makes the life of embedded distros easy. Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot. For Fedora see https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description SUSE started the UEFI implementation to boot on all architectures in the same way. The current ARM and RISC-V images uses UEFI. Debian and Ubuntu install for booting via GRUB if the installer is invoked via UEFI. A fallback solution using the legacy Linux entry point exists. For BSD the only way to boot on ARM is via UEFI. What's our position when compared to EDK II? U-Boot implements only a subset of UEFI defined in the EBBR specification. For servers you need a larger scope which is offered by EDK II. This is required both by the RISC-V platform specification as well as the ARM SystemReady ServerReady profile. The number of boards supported by upstream EDK II is very low. But proprietary firmware based on EDK II exists. the typical distro boot flow is not the most efficient and drags concept dating where the Microsoft certs had to be part of the picture. A direct U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path (grub), avoids convoluted platform cert management (shim) and just This is why U-Boot supports UEFI boot options specifying both a binary as well as an initial RAM disk. I might be late to this, but where does the devicetree come from? As far as I understand it right now, for most (all) the SytemReady IR certified boards, the compiled-in one from u-boot is passed to linux. This won't work in the long run, because the devicetrees keep getting incompatible changes. So while it work for one kernel version it might not work on the next version. It would make sense to add the fdt devicepath to the bootoption like we did it for the initrd. I haven't followed the much of the recent development, are there any commits/files I can look at? And I'm not just talking about the use case where the EFI stub of linux is booted directy, but also when there is grub in between. The distribution would supply a bunch of devicetrees along with the kernel (and initrd). Possibly also different versions of these. In grub you would choose the desired kernel/initrd/devicetree combination. But this means grub would need to (1) know the filename of the devicetree, or (2) it is hardcoded in the grub config which is generated by the distribution. For (1) you'd need to convey the information from u-boot to grub. (2) would mean the distribution will have to figure out the suitable devicetree. To make things worse, there are boards which have several different devicetrees or there might even be overlays. Eg. my board has different devicetrees which are expected to be chosen by the user by setting the fdtfile variable. -michael
Re: Driver model at UEFI runtime
[adding Vladimir, because he showed interest in this, too] Am 2021-09-30 15:56, schrieb François Ozog: On Thu, 30 Sept 2021 at 14:07, Michael Walle wrote: Am 2021-09-30 12:50, schrieb Heinrich Schuchardt: Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle : Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: On 9/30/21 8:23 AM, François Ozog wrote: [..] Is U-Boot's UEFI loader implementation supposed to be the recommended UEFI firmware on ARM and RISC-V on a production / deployment system? For Arm: yes, that is SystemReady spec. For RISC-V it is required by the RISC-V platform specification. Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we expect to load grub.efi which chain-loads a kernel without CONFIG_EFI_STUB? all paths should be possible , and the shim.efi is to be supported too. With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In other words I don’t see grub.efi booting a non config_efi_stub. What do distributions normally do? At least Red Hat made it clear at multiple Linaro Connect that they want standards, and SystemReady is one that makes the life of embedded distros easy. Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot. For Fedora see https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description SUSE started the UEFI implementation to boot on all architectures in the same way. The current ARM and RISC-V images uses UEFI. Debian and Ubuntu install for booting via GRUB if the installer is invoked via UEFI. A fallback solution using the legacy Linux entry point exists. For BSD the only way to boot on ARM is via UEFI. What's our position when compared to EDK II? U-Boot implements only a subset of UEFI defined in the EBBR specification. For servers you need a larger scope which is offered by EDK II. This is required both by the RISC-V platform specification as well as the ARM SystemReady ServerReady profile. The number of boards supported by upstream EDK II is very low. But proprietary firmware based on EDK II exists. the typical distro boot flow is not the most efficient and drags concept dating where the Microsoft certs had to be part of the picture. A direct U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path (grub), avoids convoluted platform cert management (shim) and just This is why U-Boot supports UEFI boot options specifying both a binary as well as an initial RAM disk. I might be late to this, but where does the devicetree come from? As far as I understand it right now, for most (all) the SytemReady IR certified boards, the compiled-in one from u-boot is passed to linux. This won't work in the long run, because the devicetrees keep getting incompatible changes. So while it work for one kernel version it might not work on the next version. It would make sense to add the fdt devicepath to the bootoption like we did it for the initrd. I haven't followed the much of the recent development, are there any commits/files I can look at? And I'm not just talking about the use case where the EFI stub of linux is booted directy, but also when there is grub in between. The distribution would supply a bunch of devicetrees along with the kernel (and initrd). Possibly also different versions of these. In grub you would choose the desired kernel/initrd/devicetree combination. With SystemReady, DT from distros are ignored. Err? Is this really true, I know about some incompatible changes to the device tree which prevents you from using usb (or even a kernel panic) with the imx8mm and I know that on the ls1028a flexspi wont work if the devicetree doesn't match the kernel. I.e. if you have a device tree from kernel 5.14 you cannot use it on 5.10. If you have one from 5.10 you cannot use it on a later kernel. So, IMHO this is alreay a non-starter for SystemReady if it should work beyond having a serial console and some storage :( With SecureBoot on, dtb= on the command line is disabled. UEFI can have multiple boot options. Each boot option comes with: - a list of "device paths" --> dp[n] - a command line The "device paths" are not your typical file path in operating system. They can include configuration information (line speed for a UART along with terminal emulation parameters). Each dp can be given a specific class. An initrd "vendor media" class was created. At present, dp[0] is loaded as the UEFI command and dp[1..n] are ignored. Linux kernel EFI_STUB can ask "load the "initrd vendor media here"; the EFI subsystem with browse through dp[1-n] for that element and load it. If measured boot is on, the initrd will be measured by the UEFI subsystem. So by having multiple BootXXX variables, one can achieve multiple kernel selections. But this means grub would need to (1) know the filename of the devicetree, or (2) it is hardcoded in the grub config which is ge
Re: Driver model at UEFI runtime
Am 2021-09-30 17:47, schrieb François Ozog: On Thu, 30 Sept 2021 at 17:12, Michael Walle wrote: [adding Vladimir, because he showed interest in this, too] Am 2021-09-30 15:56, schrieb François Ozog: On Thu, 30 Sept 2021 at 14:07, Michael Walle wrote: Am 2021-09-30 12:50, schrieb Heinrich Schuchardt: Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle : Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: On 9/30/21 8:23 AM, François Ozog wrote: [..] Is U-Boot's UEFI loader implementation supposed to be the recommended UEFI firmware on ARM and RISC-V on a production / deployment system? For Arm: yes, that is SystemReady spec. For RISC-V it is required by the RISC-V platform specification. Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we expect to load grub.efi which chain-loads a kernel without CONFIG_EFI_STUB? all paths should be possible , and the shim.efi is to be supported too. With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In other words I don’t see grub.efi booting a non config_efi_stub. What do distributions normally do? At least Red Hat made it clear at multiple Linaro Connect that they want standards, and SystemReady is one that makes the life of embedded distros easy. Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot. For Fedora see https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description SUSE started the UEFI implementation to boot on all architectures in the same way. The current ARM and RISC-V images uses UEFI. Debian and Ubuntu install for booting via GRUB if the installer is invoked via UEFI. A fallback solution using the legacy Linux entry point exists. For BSD the only way to boot on ARM is via UEFI. What's our position when compared to EDK II? U-Boot implements only a subset of UEFI defined in the EBBR specification. For servers you need a larger scope which is offered by EDK II. This is required both by the RISC-V platform specification as well as the ARM SystemReady ServerReady profile. The number of boards supported by upstream EDK II is very low. But proprietary firmware based on EDK II exists. the typical distro boot flow is not the most efficient and drags concept dating where the Microsoft certs had to be part of the picture. A direct U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path (grub), avoids convoluted platform cert management (shim) and just This is why U-Boot supports UEFI boot options specifying both a binary as well as an initial RAM disk. I might be late to this, but where does the devicetree come from? As far as I understand it right now, for most (all) the SytemReady IR certified boards, the compiled-in one from u-boot is passed to linux. This won't work in the long run, because the devicetrees keep getting incompatible changes. So while it work for one kernel version it might not work on the next version. It would make sense to add the fdt devicepath to the bootoption like we did it for the initrd. I haven't followed the much of the recent development, are there any commits/files I can look at? And I'm not just talking about the use case where the EFI stub of linux is booted directy, but also when there is grub in between. The distribution would supply a bunch of devicetrees along with the kernel (and initrd). Possibly also different versions of these. In grub you would choose the desired kernel/initrd/devicetree combination. With SystemReady, DT from distros are ignored. Err? Is this really true, I know about some incompatible changes to the device tree which prevents you from using usb (or even a kernel panic) with the imx8mm and I know that on the ls1028a flexspi wont work if the devicetree doesn't match the kernel. I.e. if you have a device tree from kernel 5.14 you cannot use it on 5.10. If you have one from 5.10 you cannot use it on a later kernel. What you describe is the situation we want to avoid and that comes from years of tinkering. how is that tinkering? That means once you have a device tree, it is set in stone. which isn't reality, sorry. Consider the ls1028a and the flexspi "bug". For the 5.10 kernel/dtb there was a wrong clock connected to the flexspi device. There wasn't even a driver for the correct clock. Thus, I introduced a new clock driver and wired it correctly in the device tree. Which was introduced in 5.11 (or 5.12 I don't know anymore). u-boot is now providing a devicetree from the 5.14 kernel. Thus, it has the clock input connected to the new clock driver. But debian, for example, has kernel 5.10. Which doesn't have the clock driver, oops. The flexspi tries to enable the clock which fails and the whole probe will fail. Regarding the imx8mm usb error, apparently the node was renamed. If you're using older kernels with newer dtbs, the kernel oopes. If you're using a newer kernel with older
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
Am 2021-09-30 18:19, schrieb Frieder Schrempf: In order to support unaligned updates, we simply read the first full block and check only the requested part of the block for changes. If necessary, the block is erased, the first (unchanged) part of the block is written back together with the second part of the block (updated data). I'm not sure what I should think of this. You might loose that unchanged part if there is an power loss in the middle, even worse, you likely don't have this part anymore because it isn't part of the data you want to write to the flash. Maybe add an parameter for allow (unsafe) unaligned updates? Now you might argue, that with "sf erase, sf write" you can do the same harm, to which i reply: but then it is intentional ;) Because "sf erase" just works on sector boundaries (which isn't really checked in the command, i just realized, but at least my driver returns EINVAL) and then the user has to include the "unchanged part" for the arguments on the commandline. -michael
Re: Driver model at UEFI runtime
With SystemReady, DT from distros are ignored. Err? Is this really true, I know about some incompatible changes to the device tree which prevents you from using usb (or even a kernel panic) with the imx8mm and I know that on the ls1028a flexspi wont work if the devicetree doesn't match the kernel. I.e. if you have a device tree from kernel 5.14 you cannot use it on 5.10. If you have one from 5.10 you cannot use it on a later kernel. What you describe is the situation we want to avoid and that comes from years of tinkering. how is that tinkering? That means once you have a device tree, it is set in stone. which isn't reality, sorry. Consider the ls1028a and the flexspi "bug". For the 5.10 kernel/dtb there was a wrong clock connected to the flexspi device. There wasn't even a driver for the correct clock. The clock could have been described even though there was no Linux driver. DT is there to describe HW, not the capacity of a particular OS or boot firmware to deal with it. You're missing my point. It's not about what would be the perfect scenario. But what actually happens in reality. And unfortunately, it happens, so you have to deal with devicetree incompatibilies. Just ignoring this and keeping just one devicetree in the firmware is doomed to fail sooner or later. [..] Regarding the imx8mm usb error, apparently the node was renamed. If you're using older kernels with newer dtbs, the kernel oopes. If you're using a newer kernel with older dtbs, USB doesn't get probed. (Although I was told that there is a "fix" for this, that is, both node names are tried.) I keep seeing those issues about node renames or compatible string changes. That's the tinkering I am talking about. There is no in-kernel ABI but Linus bang heads if anyone touches userland-kernel ABI inappropriately. As DT is mostly handled in-kernel, people treat DT as no-ABI. But it is part of firmware-kernel ABI. Until we properly organize this firmware-kernel ABI, the problem you describe and more will continue. Sure, but until you reaches that point (I predict it wont happen soon or at all) you'll have to deal with per kernel devicetrees. Just saying, we are just providing one devicetree supplied by the firmware just doesn't work with the current situation. So IMHO if SystemReady is really "it just works", then you have to consider this. And so far, it seems all SystemReady certified boards just throw the u-boot devicetree at linux and hope for the best. Now the DT lifecycle before the firmware-kernel ABI also needs to be specified so that we properly handle hats, capes, SoMs, carrier boards... https://developer.arm.com/architectures/system-architectures/arm-systemready/ir lists a number of certified boards and the list is going to grow significantly. And the sl28 board will likely be there soon, too. On those boards, you will be able to boot any kernel. Actually I don't think so, because you might hit the imx8mm bug, too. May just be lucky by the devicetree/kernel combination. The image I have in mind with OS provided DT is: as a French driver, my DT says that the steering wheel is on the left hand side of the car. Shall I whine about the cars in England that do not comply to my DT? or accept to use the car provided DT? The situation is comfortable for tinkerers, but not sustainable. It is a matter of organization and not technology to solve the problems you describe. Mh, I'm not sure I understand what you're trying to tell me. The distribution also provides you the kernel, why shouldn't it provide devicetree which exactly matches this kernel and was also tested against. Because the kernel has no clue which hats, capes has been added for instance. And the same might be true for the firmware as pointed out before. The kernel provided DTB works fine when the firmware builder and OS builders are the same. Ehh? It is just the other way around. The distro supplies the kernel and thus it also have the corresponding devicetrees for this particular kernel. The firmware can remain the same. Now Mark might disagree here, because OpenBSD doesn't provide devicetrees (I really don't know). I agree, that in a perfect world, there would be just one (or a set of) stable devicetree(s) which can be used by any OS/Distribution/Kernel. But this simply isn't the case. This traditional model is evolving and the team that deals with OS may not even be in the same company as the one providing the firmware. Ask the Fedora IoT architect what he thinks about the distro provided DTs ;-) I don't even know who "the fedora iot architect" is, nor what her/his arguments are. There is a need to deal with DT bugs. OS provided DT is a bad solution to a real problem. U-Boot patches look a possibility for those bugs. And then you always have to update the firmware and duplicate the "code". I.e. theres an incompatible change, the devicetree is update in linux and you have to replicate just this as a fixup in u-boot.
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
Am 2021-09-30 19:17, schrieb Frieder Schrempf: On 30.09.21 18:35, Michael Walle wrote: Am 2021-09-30 18:19, schrieb Frieder Schrempf: In order to support unaligned updates, we simply read the first full block and check only the requested part of the block for changes. If necessary, the block is erased, the first (unchanged) part of the block is written back together with the second part of the block (updated data). I'm not sure what I should think of this. You might loose that unchanged part if there is an power loss in the middle, even worse, you likely don't have this part anymore because it isn't part of the data you want to write to the flash. Maybe add an parameter for allow (unsafe) unaligned updates? Now you might argue, that with "sf erase, sf write" you can do the same harm, to which i reply: but then it is intentional ;) Because "sf erase" just works on sector boundaries (which isn't really checked in the command, i just realized, but at least my driver returns EINVAL) and then the user has to include the "unchanged part" for the arguments on the commandline. True, but "sf update" already is "unsafe" even without supporting unaligned start offsets. The code already handles partial sector writes for the last sector in the same way (read, erase, write), which is also prone to data loss in case of power loss. Ah, I missed that. Yes, in this case, we don't loose anything. Agreed. So this patch in fact just adds support for partial sector updates for the first sector. It is slightly more probable to loose data, but it doesn't introduce new "unsafe" behavior. Maybe we could cover this by adding a warning to the documentation, or even printing a warning? Heh, although I was using "sf update" all the time, I wasn't aware of the read - "partly modify" - write cycle. Maybe it's just me being over cautious. Printing a warning might scare users, though. I'd prefer to fix the online help, where only "erase and write" is mentioned. -michael
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
Am 2021-09-30 18:19, schrieb Frieder Schrempf:
From: Frieder Schrempf
Currently 'sf update' supports only offsets that are aligned to the
erase block size of the serial flash. Unaligned offsets result in
something like:
=> sf update ${kernel_addr_r} 0x400 ${filesize}
device 0 offset 0x400, size 0x11f758
SPI flash failed in erase step
In order to support unaligned updates, we simply read the first full
block and check only the requested part of the block for changes. If
necessary, the block is erased, the first (unchanged) part of the block
is written back together with the second part of the block (updated
data).
Signed-off-by: Frieder Schrempf
---
cmd/sf.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/cmd/sf.c b/cmd/sf.c
index eac27ed2d7..c54b4b10bb 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -171,30 +171,32 @@ static int do_spi_flash_probe(int argc, char
*const argv[])
static const char *spi_flash_update_block(struct spi_flash *flash, u32
offset,
size_t len, const char *buf, char *cmp_buf, size_t *skipped)
{
+ u32 offset_aligned = ALIGN_DOWN(offset, flash->sector_size);
+ u32 sector_offset = offset - offset_aligned;
char *ptr = (char *)buf;
debug("offset=%#x, sector_size=%#x, len=%#zx\n",
offset, flash->sector_size, len);
/* Read the entire sector so to allow for rewriting */
- if (spi_flash_read(flash, offset, flash->sector_size, cmp_buf))
+ if (spi_flash_read(flash, offset_aligned, flash->sector_size,
cmp_buf))
return "read";
/* Compare only what is meaningful (len) */
- if (memcmp(cmp_buf, buf, len) == 0) {
+ if (memcmp(cmp_buf + sector_offset, buf, len) == 0) {
debug("Skip region %x size %zx: no change\n",
offset, len);
*skipped += len;
return NULL;
}
/* Erase the entire sector */
- if (spi_flash_erase(flash, offset, flash->sector_size))
+ if (spi_flash_erase(flash, offset_aligned, flash->sector_size))
return "erase";
/* If it's a partial sector, copy the data into the temp-buffer */
if (len != flash->sector_size) {
- memcpy(cmp_buf, buf, len);
+ memcpy(cmp_buf + sector_offset, buf, len);
ptr = cmp_buf;
}
/* Write one complete sector */
- if (spi_flash_write(flash, offset, flash->sector_size, ptr))
+ if (spi_flash_write(flash, offset_aligned, flash->sector_size, ptr))
return "write";
return NULL;
@@ -230,7 +232,10 @@ static int spi_flash_update(struct spi_flash
*flash, u32 offset,
ulong last_update = get_timer(0);
for (; buf < end && !err_oper; buf += todo, offset += todo) {
- todo = min_t(size_t, end - buf, flash->sector_size);
+ if (offset % flash->sector_size)
do_div() to avoid linking errors on some archs, I guess.
+ todo = flash->sector_size - (offset %
flash->sector_size);
This is missing the end-buf calculation, no? I.e. if you update just one
sector at an offset and the data you write is smaller than "sector_size
- offset".
+ else
+ todo = min_t(size_t, end - buf,
flash->sector_size);
if (get_timer(last_update) > 100) {
printf(" \rUpdating, %zu%% %lu B/s",
100 - (end - buf) / scale,
-michael
Re: Driver model at UEFI runtime
Am 2021-10-01 00:20, schrieb François Ozog: Le ven. 1 oct. 2021 à 00:00, Michael Walle a écrit : With SystemReady, DT from distros are ignored. Err? Is this really true, I know about some incompatible changes to the device tree which prevents you from using usb (or even a kernel panic) with the imx8mm and I know that on the ls1028a flexspi wont work if the devicetree doesn't match the kernel. I.e. if you have a device tree from kernel 5.14 you cannot use it on 5.10. If you have one from 5.10 you cannot use it on a later kernel. What you describe is the situation we want to avoid and that comes from years of tinkering. how is that tinkering? That means once you have a device tree, it is set in stone. which isn't reality, sorry. Consider the ls1028a and the flexspi "bug". For the 5.10 kernel/dtb there was a wrong clock connected to the flexspi device. There wasn't even a driver for the correct clock. The clock could have been described even though there was no Linux driver. DT is there to describe HW, not the capacity of a particular OS or boot firmware to deal with it. You're missing my point. It's not about what would be the perfect scenario. But what actually happens in reality. And unfortunately, it happens, so you have to deal with devicetree incompatibilies. Just ignoring this and keeping just one devicetree in the firmware is doomed to fail sooner or later. We have an example of firmware provided hardware description that works well (Ok: 99% of the time): ACPI. Mh, I can't really comment on this as I am not familiar with ACPI. But judging by all the linux acpi fixups and bios incompatiblies, my gut tells me that it doesn't work _that_ well ;) We also are 100% sure that the current situation is messy, hairy, buggy but familiar. [..] Regarding the imx8mm usb error, apparently the node was renamed. If you're using older kernels with newer dtbs, the kernel oopes. If you're using a newer kernel with older dtbs, USB doesn't get probed. (Although I was told that there is a "fix" for this, that is, both node names are tried.) I keep seeing those issues about node renames or compatible string changes. That's the tinkering I am talking about. There is no in-kernel ABI but Linus bang heads if anyone touches userland-kernel ABI inappropriately. As DT is mostly handled in-kernel, people treat DT as no-ABI. But it is part of firmware-kernel ABI. Until we properly organize this firmware-kernel ABI, the problem you describe and more will continue. Sure, but until you reaches that point (I predict it wont happen soon or at all) you'll have to deal with per kernel devicetrees. Just saying, we are just providing one devicetree supplied by the firmware just doesn't work with the current situation. So IMHO if SystemReady is really "it just works", then you have to consider this. And so far, it seems all SystemReady certified boards just throw the u-boot devicetree at linux and hope for the best. SystemReady is not meant to be all boards, starting now and mandatory. It is a selected of boards for which everyone in the value chain is willing to spend the energy to solve the problem as if we were living in a perfect world. And here I am, trying to find a solution to a real problem I'm facing with my board and the systemready cerification. But all I'm hearing is that it should work the way linaro/ARM have in mind, but it clearly doesn't. Now the DT lifecycle before the firmware-kernel ABI also needs to be specified so that we properly handle hats, capes, SoMs, carrier boards... https://developer.arm.com/architectures/system-architectures/arm-systemready/ir lists a number of certified boards and the list is going to grow significantly. And the sl28 board will likely be there soon, too. On those boards, you will be able to boot any kernel. Actually I don't think so, because you might hit the imx8mm bug, too. May just be lucky by the devicetree/kernel combination. The image I have in mind with OS provided DT is: as a French driver, my DT says that the steering wheel is on the left hand side of the car. Shall I whine about the cars in England that do not comply to my DT? or accept to use the car provided DT? The situation is comfortable for tinkerers, but not sustainable. It is a matter of organization and not technology to solve the problems you describe. Mh, I'm not sure I understand what you're trying to tell me. The distribution also provides you the kernel, why shouldn't it provide devicetree which exactly matches this kernel and was also tested against. Because the kernel has no clue which hats, capes has been added for instance. And the same might be true for the firmware as pointed out before. The kernel provided DTB works fine when the firmware builder and OS builders are the same. Ehh? It is just the other way around. The distro supplies the kernel and thus it also have the corresponding devicetr
Re: [PATCH v2 6/6] arm: dts: ls1088a: change dwc3 compatible to match dwc3-generic driver
> Benefit is, besides host mode, now user can choose device mode with
> setting of dr_mode = ?peripheral?;
>
> Signed-off-by: Ran Wang
> ---
> Change in v2:
> - Remove property 'snps,dis_rxdet_inp3_quirk' due to its side effect to Linux
>kernel (USB device no detected)
>
> arch/arm/dts/fsl-ls1088a.dtsi | 38 --
> 1 file changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
> index 6653794..9d4f40c 100644
> --- a/arch/arm/dts/fsl-ls1088a.dtsi
> +++ b/arch/arm/dts/fsl-ls1088a.dtsi
> @@ -121,18 +121,36 @@
> interrupts = <0 21 0x4>; /* Level high type */
> };
>
> - usb0: usb3 at 310 {
> - compatible = "fsl,layerscape-dwc3";
> - reg = <0x0 0x310 0x0 0x1>;
> - interrupts = <0 80 0x4>; /* Level high type */
> - dr_mode = "host";
> + usb0: usb at 310 {
> + compatible = "nxp,layerscape-dwc3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + dwc3 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = <0 80 0x4>; /* Level high type */
> + dr_mode = "host";
> + maximum-speed = "super-speed";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> + };
NAK. This is not the official device tree binding for this controller.
Please use the same binding as specified in linux.
NB. I'm working on this.
-michael
Re: [PATCH] cmd: sf: Support unaligned flash updates with 'sf update'
Am 2021-10-04 12:31, schrieb Frieder Schrempf: On 30.09.21 23:08, Michael Walle wrote: Printing a warning might scare users, though. I'd prefer to fix the online help, where only "erase and write" is mentioned. Which document are you referring to? I don't really see the "sf" command documented anywhere. the "sf update" online help: "sf update addr offset|partition len- erase and write `len' bytes from memory\n" " at `addr' to flash at `offset'\n" " or to start of mtd `partition'\n" -michael
[PATCH v4 17/29] watchdog: sp805_wdt: use correct compatible string
According to the linux device tree specification the compatible string
is:
compatible = "arm,sp805", "arm,primecell";
Fix all users in u-boot.
Signed-off-by: Michael Walle
---
arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
arch/arm/dts/hi3660.dtsi | 4 ++--
drivers/watchdog/sp805_wdt.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index e5b5a0dc9f..cbdddccaea 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -382,7 +382,7 @@
};
cluster1_core0_watchdog: wdt@c00 {
- compatible = "arm,sp805-wdt";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc00 0x0 0x1000>;
};
diff --git a/arch/arm/dts/hi3660.dtsi b/arch/arm/dts/hi3660.dtsi
index 65a45b0e80..028f4db60d 100644
--- a/arch/arm/dts/hi3660.dtsi
+++ b/arch/arm/dts/hi3660.dtsi
@@ -1087,7 +1087,7 @@
};
watchdog0: watchdog@e8a06000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a06000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI3660_OSC32K>;
@@ -1095,7 +1095,7 @@
};
watchdog1: watchdog@e8a07000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a07000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI3660_OSC32K>;
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index bec8827ceb..0d6fb12065 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -134,7 +134,7 @@ static const struct wdt_ops sp805_wdt_ops = {
};
static const struct udevice_id sp805_wdt_ids[] = {
- { .compatible = "arm,sp805-wdt" },
+ { .compatible = "arm,sp805" },
{}
};
--
2.30.2
[PATCH v4 15/29] arm: dts: ls1028a: move the iRC node and its devices into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
While at it fix the indentation.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 202 +-
1 file changed, 103 insertions(+), 99 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index c289009ca1..ca593c7218 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -43,105 +43,6 @@
IRQ_TYPE_LEVEL_LOW)>;
};
- pcie@1f000 {
- compatible = "pci-host-ecam-generic";
- /* ECAM bus 0, HW has more space reserved but not populated */
- bus-range = <0x0 0x0>;
- reg = <0x01 0xf000 0x0 0x10>;
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges= <0x8200 0x0 0x 0x1 0xf800 0x0 0x16>;
- enetc0: pci@0,0 {
- reg = <0x00 0 0 0 0>;
- status = "disabled";
- };
- enetc1: pci@0,1 {
- reg = <0x000100 0 0 0 0>;
- status = "disabled";
- };
- enetc2: pci@0,2 {
- reg = <0x000200 0 0 0 0>;
- status = "disabled";
- phy-mode = "internal";
-
- fixed-link {
- speed = <2500>;
- full-duplex;
- };
- };
- mdio0: pci@0,3 {
- #address-cells=<0>;
- #size-cells=<1>;
- reg = <0x000300 0 0 0 0>;
- status = "disabled";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- mscc_felix: pci@0,5 {
- reg = <0x000500 0 0 0 0>;
- status = "disabled";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- mscc_felix_port0: port@0 {
- reg = <0>;
- status = "disabled";
- };
-
- mscc_felix_port1: port@1 {
- reg = <1>;
- status = "disabled";
- };
-
- mscc_felix_port2: port@2 {
- reg = <2>;
- status = "disabled";
- };
-
- mscc_felix_port3: port@3 {
- reg = <3>;
- status = "disabled";
- };
-
- mscc_felix_port4: port@4 {
- reg = <4>;
- phy-mode = "internal";
- status = "disabled";
-
- fixed-link {
- speed = <2500>;
- full-duplex;
- };
- };
-
- mscc_felix_port5: port@5 {
- reg = <5>;
- phy-mode = "internal";
- status = "disabled";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
-
- };
- };
- };
-
- enetc6: pci@0,6 {
- reg = <0x000600 0 0 0 0>;
- status = "disabled";
- phy-mode = "internal";
- };
- };
-
soc: soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -484,5 +385,108 @@
compatible = "arm,sp
[PATCH v4 11/29] arm: dts: ls1028a: move the GPIO controller nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 66 +--
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 349c4bf862..9f466554e9 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -190,39 +190,6 @@
status = "disabled";
};
- gpio0: gpio@230 {
- compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
- reg = <0x0 0x230 0x0 0x1>;
- interrupts = ;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- little-endian;
- };
-
- gpio1: gpio@231 {
- compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
- reg = <0x0 0x231 0x0 0x1>;
- interrupts = ;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- little-endian;
- };
-
- gpio2: gpio@232 {
- compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
- reg = <0x0 0x232 0x0 0x1>;
- interrupts = ;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- little-endian;
- };
-
sata: sata@320 {
compatible = "fsl,ls1028a-ahci";
reg = <0x0 0x320 0x0 0x1/* ccsr sata base */
@@ -484,5 +451,38 @@
little-endian;
status = "disabled";
};
+
+ gpio0: gpio@230 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x230 0x0 0x1>;
+ interrupts = ;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+ };
+
+ gpio1: gpio@231 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x231 0x0 0x1>;
+ interrupts = ;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+ };
+
+ gpio2: gpio@232 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x232 0x0 0x1>;
+ interrupts = ;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+ };
};
};
--
2.30.2
[PATCH v4 18/29] spi: fsl_dspi: add new compatible fsl, ls1021a-v1.0-dspi
The official ls1028a binding of the driver uses the following as
compatibles:
compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
Add the missing compatible to the driver and update the device tree.
We can use the fallback "fsl,ls1021a-v1.0-dspi", because the endianness
is determined by the little-endian property and not by the compatible
string itself. Further, we won't need and specific details on the DMA
configuration (which is different on the LS1021A). If it's ever needed,
we can later add the more specific "fsl,ls1028a-dspi" compatible to the
driver.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 6 +++---
drivers/spi/fsl_dspi.c| 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index cbdddccaea..6158a1362a 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -158,7 +158,7 @@
};
dspi0: dspi@210 {
- compatible = "fsl,vf610-dspi";
+ compatible = "fsl,ls1028a-dspi",
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x210 0x0 0x1>;
@@ -171,7 +171,7 @@
};
dspi1: dspi@211 {
- compatible = "fsl,vf610-dspi";
+ compatible = "fsl,ls1028a-dspi",
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x211 0x0 0x1>;
@@ -184,7 +184,7 @@
};
dspi2: dspi@212 {
- compatible = "fsl,vf610-dspi";
+ compatible = "fsl,ls1028a-dspi",
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x212 0x0 0x1>;
diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
index 8fe3508c64..23d812f476 100644
--- a/drivers/spi/fsl_dspi.c
+++ b/drivers/spi/fsl_dspi.c
@@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
static const struct udevice_id fsl_dspi_ids[] = {
{ .compatible = "fsl,vf610-dspi" },
+ { .compatible = "fsl,ls1021a-v1.0-dspi" },
{ }
};
--
2.30.2
[PATCH v4 05/29] arm: dts: ls1028a: move the clockgen node into /soc
Populate the /soc node with the first device node.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 1f562cfdad..54f97014be 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -21,13 +21,6 @@
clock-output-names = "sysclk";
};
- clockgen: clocking@130 {
- compatible = "fsl,ls1028a-clockgen";
- reg = <0x0 0x130 0x0 0xa>;
- #clock-cells = <2>;
- clocks = <>;
- };
-
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
@@ -484,5 +477,12 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+
+ clockgen: clocking@130 {
+ compatible = "fsl,ls1028a-clockgen";
+ reg = <0x0 0x130 0x0 0xa>;
+ #clock-cells = <2>;
+ clocks = <>;
+ };
};
};
--
2.30.2
[PATCH v4 06/29] arm: dts: ls1028a: move I2C controller nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
.../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds--sch-30841.dtsi | 8 +-
.../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 4 +-
.../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 2 +-
.../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 8 +-
.../dts/fsl-ls1028a-qds--sch-24801.dtsi | 8 +-
.../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 8 +-
.../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 8 +-
.../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 2 +-
arch/arm/dts/fsl-ls1028a.dtsi | 176 +-
12 files changed, 115 insertions(+), 115 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index 4063d9a114..1f13cf80e6 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -16,5 +16,5 @@
{
status = "okay";
phy-mode = "usxgmii";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
index 548ab2ba65..10375b2751 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
@@ -15,5 +15,5 @@
{
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
index 3991fb793f..f18cb39f21 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
@@ -31,25 +31,25 @@
_felix_port0 {
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
};
_felix_port1 {
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@01}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@01}>;
};
_felix_port2 {
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
_felix_port3 {
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
};
_felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
index d68c8c2be0..f6561a89eb 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
@@ -20,13 +20,13 @@
_felix_port0 {
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
_felix_port3 {
status = "okay";
phy-mode = "2500base-x";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
};
_felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
index 94b5081d61..d9ccd8353b 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
@@ -15,5 +15,5 @@
{
status = "okay";
phy-mode = "sgmii";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
index 3b850268e6..0630f12069 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-248
[PATCH v4 08/29] arm: dts: ls1028a: move the SPI and eSDHC controller nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 116 +-
1 file changed, 58 insertions(+), 58 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 6d80b32816..ecafa67d08 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -266,64 +266,6 @@
status = "disabled";
};
- dspi0: dspi@210 {
- compatible = "fsl,vf610-dspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0 0x210 0x0 0x1>;
- interrupts = ;
- clock-names = "dspi";
- clocks = < 4 0>;
- num-cs = <5>;
- litte-endian;
- status = "disabled";
- };
-
- dspi1: dspi@211 {
- compatible = "fsl,vf610-dspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0 0x211 0x0 0x1>;
- interrupts = ;
- clock-names = "dspi";
- clocks = < 4 0>;
- num-cs = <5>;
- little-endian;
- status = "disabled";
- };
-
- dspi2: dspi@212 {
- compatible = "fsl,vf610-dspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0 0x212 0x0 0x1>;
- interrupts = ;
- clock-names = "dspi";
- clocks = < 4 0>;
- num-cs = <5>;
- little-endian;
- status = "disabled";
- };
-
- esdhc0: esdhc@214 {
- compatible = "fsl,esdhc";
- reg = <0x0 0x214 0x0 0x1>;
- interrupts = ;
- big-endian;
- bus-width = <4>;
- status = "disabled";
- };
-
- esdhc1: esdhc@215 {
- compatible = "fsl,esdhc";
- reg = <0x0 0x215 0x0 0x1>;
- interrupts = ;
- big-endian;
- non-removable;
- bus-width = <4>;
- status = "disabled";
- };
-
gpio0: gpio@230 {
compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
reg = <0x0 0x230 0x0 0x1>;
@@ -484,5 +426,63 @@
interrupts = ;
status = "disabled";
};
+
+ dspi0: dspi@210 {
+ compatible = "fsl,vf610-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x210 0x0 0x1>;
+ interrupts = ;
+ clock-names = "dspi";
+ clocks = < 4 0>;
+ num-cs = <5>;
+ litte-endian;
+ status = "disabled";
+ };
+
+ dspi1: dspi@211 {
+ compatible = "fsl,vf610-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x211 0x0 0x1>;
+ interrupts = ;
+ clock-names = "dspi";
+ clocks = < 4 0>;
+ num-cs = <5>;
+ little-endian;
+ status = "disabled";
+ };
+
+ dspi2: dspi@212 {
+ compatible = "fsl,vf610-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x212 0x0 0x1>;
+ interrupts = ;
+ clock-names = "dspi";
+ clocks = < 4 0>;
+ num-cs = <5>;
+ little-endian;
+ status = "disabled";
+ };
+
+ esdhc0: esdhc@214 {
+ compatible = "fsl,esdhc";
+ reg = <0x0 0x214 0x0 0x1>;
+ interrupts = ;
+ big-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ esdhc1: esdhc@215 {
+ compatible = "fsl,esdhc";
+ reg = <0x0 0x215 0x0 0x1>;
+ interrupts = ;
+ big-endian;
+ non-removable;
+ bus-width = <4>;
+ status = "disabled";
+ };
};
};
--
2.30.2
[PATCH v4 12/29] arm: dts: ls1028a: move SATA and USB controller nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 9f466554e9..7d18085615 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -174,31 +174,6 @@
};
};
- usb1: usb3@310 {
- compatible = "fsl,layerscape-dwc3";
- reg = <0x0 0x310 0x0 0x1>;
- interrupts = ;
- dr_mode = "host";
- status = "disabled";
- };
-
- usb2: usb3@311 {
- compatible = "fsl,layerscape-dwc3";
- reg = <0x0 0x311 0x0 0x1>;
- interrupts = ;
- dr_mode = "host";
- status = "disabled";
- };
-
- sata: sata@320 {
- compatible = "fsl,ls1028a-ahci";
- reg = <0x0 0x320 0x0 0x1/* ccsr sata base */
- 0x7 0x100520 0x0 0x4>; /* ecc sata addr*/
- reg-names = "sata-base", "ecc-addr";
- interrupts = ;
- status = "disabled";
- };
-
cluster1_core0_watchdog: wdt@c00 {
compatible = "arm,sp805-wdt";
reg = <0x0 0xc00 0x0 0x1000>;
@@ -484,5 +459,30 @@
#interrupt-cells = <2>;
little-endian;
};
+
+ usb1: usb3@310 {
+ compatible = "fsl,layerscape-dwc3";
+ reg = <0x0 0x310 0x0 0x1>;
+ interrupts = ;
+ dr_mode = "host";
+ status = "disabled";
+ };
+
+ usb2: usb3@311 {
+ compatible = "fsl,layerscape-dwc3";
+ reg = <0x0 0x311 0x0 0x1>;
+ interrupts = ;
+ dr_mode = "host";
+ status = "disabled";
+ };
+
+ sata: sata@320 {
+ compatible = "fsl,ls1028a-ahci";
+ reg = <0x0 0x320 0x0 0x1/* ccsr sata
base */
+ 0x7 0x100520 0x0 0x4>; /* ecc sata
addr*/
+ reg-names = "sata-base", "ecc-addr";
+ interrupts = ;
+ status = "disabled";
+ };
};
};
--
2.30.2
[PATCH v4 07/29] arm: dts: ls1028a: move the FlexSPI controller node
While inserting it into the new location, keep it sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index de85fdd045..6d80b32816 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -43,19 +43,6 @@
IRQ_TYPE_LEVEL_LOW)>;
};
- fspi: flexspi@20c {
- compatible = "nxp,lx2160a-fspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0 0x20c 0x0 0x1>,
- <0x0 0x2000 0x0 0x1000>;
- reg-names = "fspi_base", "fspi_mmap";
- clocks = < 4 3>, < 4 3>;
- clock-names = "fspi_en", "fspi";
- interrupts = ;
- status = "disabled";
- };
-
serial0: serial@21c0500 {
device_type = "serial";
compatible = "fsl,ns16550", "ns16550a";
@@ -484,5 +471,18 @@
clocks = < 4 0>;
status = "disabled";
};
+
+ fspi: flexspi@20c {
+ compatible = "nxp,lx2160a-fspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+ reg-names = "fspi_base", "fspi_mmap";
+ clocks = < 4 3>, < 4 3>;
+ clock-names = "fspi_en", "fspi";
+ interrupts = ;
+ status = "disabled";
+ };
};
};
--
2.30.2
[PATCH v4 09/29] arm: dts: ls1028a: move the UART controller nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index ecafa67d08..07aeb380ef 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -43,22 +43,6 @@
IRQ_TYPE_LEVEL_LOW)>;
};
- serial0: serial@21c0500 {
- device_type = "serial";
- compatible = "fsl,ns16550", "ns16550a";
- reg = <0x0 0x21c0500 0x0 0x100>;
- interrupts = ;
- status = "disabled";
- };
-
- serial1: serial@21c0600 {
- device_type = "serial";
- compatible = "fsl,ns16550", "ns16550a";
- reg = <0x0 0x21c0600 0x0 0x100>;
- interrupts = ;
- status = "disabled";
- };
-
pcie1: pcie@340 {
compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
reg = <0x00 0x0340 0x0 0x8
@@ -484,5 +468,21 @@
bus-width = <4>;
status = "disabled";
};
+
+ serial0: serial@21c0500 {
+ device_type = "serial";
+ compatible = "fsl,ns16550", "ns16550a";
+ reg = <0x0 0x21c0500 0x0 0x100>;
+ interrupts = ;
+ status = "disabled";
+ };
+
+ serial1: serial@21c0600 {
+ device_type = "serial";
+ compatible = "fsl,ns16550", "ns16550a";
+ reg = <0x0 0x21c0600 0x0 0x100>;
+ interrupts = ;
+ status = "disabled";
+ };
};
};
--
2.30.2
[PATCH v4 24/29] arm: dts: ls1028a: remove num-lanes in the PCIe controller nodes
This property is unused in the layerscape PCIe controller driver and not present in the linux device tree. Remove it to be similarly. Signed-off-by: Michael Walle Reviewed-by: Vladimir Oltean --- arch/arm/dts/fsl-ls1028a.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi index 435b965d00..3ef710bb3d 100644 --- a/arch/arm/dts/fsl-ls1028a.dtsi +++ b/arch/arm/dts/fsl-ls1028a.dtsi @@ -351,7 +351,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x80 0x0002 0x0 0x0001 /* downstream I/O */ 0x8200 0x0 0x4000 0x80 0x4000 0x0 0x4000>; /* non-prefetchable memory */ @@ -365,7 +364,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x88 0x0002 0x0 0x0001 /* downstream I/O */ 0x8200 0x0 0x4000 0x88 0x4000 0x0 0x4000>; /* non-prefetchable memory */ -- 2.30.2
Re: [PATCH v3 27/29] arm: dts: ls1028a: drop non-removable property from esdhc controller node
Am 2021-09-15 12:36, schrieb Vladimir Oltean: On Wed, Sep 15, 2021 at 10:09:45AM +0200, Michael Walle wrote: I was thinking of putting it into the -u-boot.dtsi, but as there is no breakage, I didn't. Ok, but we should still put "non-removable" in the Linux dtsi soon then. Just for the reference: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=8b94aa318aa746fbbc668d6b9b3ad812c835230c -michael
[PATCH v4 04/29] arm: dts: ls1028a: add an empty /soc
To keep the device tree similar to the linux kernel one, we need to move
all CCSR related devices into the /soc node. To keep the patches easy to
review, we initially add an empty /soc node and populate it piece by
piece.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 4
arch/arm/dts/fsl-ls1028a.dtsi | 7 +++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index b3861ed98c..fa4c05212a 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -266,6 +266,10 @@
u-boot,dm-pre-reloc;
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 48f70c10d9..1f562cfdad 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -478,4 +478,11 @@
compatible = "arm,sp805-wdt";
reg = <0x0 0xc00 0x0 0x1000>;
};
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ };
};
--
2.30.2
[PATCH v4 02/29] arm: dts: ls1028a: remove /memory node
This node is some hodgepodge between the ddr controller node at SoC
offset 0x108 and some static memory size of 2GiB. Remove this bogus
node because it doesn't seem to be used at all.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 53b052ed32..48f70c10d9 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -28,12 +28,6 @@
clocks = <>;
};
- memory@0108 {
- device_type = "memory";
- reg = <0x 0x0108 0 0x8000>;
- /* DRAM space - 1, size : 2 GB DRAM */
- };
-
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
--
2.30.2
[PATCH v4 03/29] arm: dts: ls1028a-{rdb, qds}: remove dm-pre-reloc property
Nowadays, both boards boot using the TF-A BL1/BL2 and SPL isn't used at
all. The property is not needed, remove it.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-qds.dtsi | 1 -
arch/arm/dts/fsl-ls1028a-rdb.dts | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi
b/arch/arm/dts/fsl-ls1028a-qds.dtsi
index 69632fa796..335d7b1e4c 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
@@ -130,7 +130,6 @@
{
status = "okay";
- u-boot,dm-pre-reloc;
fpga@66 {
#address-cells = <1>;
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 82a8c0a0cd..708182f65c 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -61,7 +61,6 @@
{
status = "okay";
- u-boot,dm-pre-reloc;
i2c-mux@77 {
--
2.30.2
[PATCH v4 19/29] spi: fsl_dspi: rename num-cs to spi-num-chipselects
The official devicetree bindings specifies spi-num-chipselects as the
name. Use it.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1012a.dtsi | 2 +-
arch/arm/dts/fsl-ls1028a.dtsi | 6 +++---
arch/arm/dts/fsl-ls1043a.dtsi | 4 ++--
arch/arm/dts/fsl-ls1046a.dtsi | 4 ++--
arch/arm/dts/fsl-ls1088a.dtsi | 2 +-
arch/arm/dts/fsl-ls2080a.dtsi | 2 +-
arch/arm/dts/fsl-lx2160a.dtsi | 6 +++---
arch/arm/dts/ls1021a.dtsi | 4 ++--
arch/arm/dts/vf.dtsi | 4 ++--
drivers/spi/fsl_dspi.c| 5 +++--
10 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 2894842cf2..dcdcd444b3 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -49,7 +49,7 @@
interrupts = <0 64 0x4>;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <6>;
+ spi-num-chipselects = <6>;
big-endian;
status = "disabled";
};
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 6158a1362a..7da32561a4 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -165,7 +165,7 @@
interrupts = ;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <5>;
+ spi-num-chipselects = <5>;
litte-endian;
status = "disabled";
};
@@ -178,7 +178,7 @@
interrupts = ;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <5>;
+ spi-num-chipselects = <5>;
little-endian;
status = "disabled";
};
@@ -191,7 +191,7 @@
interrupts = ;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <5>;
+ spi-num-chipselects = <5>;
little-endian;
status = "disabled";
};
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index d8171bd03b..3aaec8b6af 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -53,7 +53,7 @@
interrupts = <0 64 0x4>;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <6>;
+ spi-num-chipselects = <6>;
big-endian;
status = "disabled";
};
@@ -66,7 +66,7 @@
interrupts = <0 65 0x4>;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <6>;
+ spi-num-chipselects = <6>;
big-endian;
status = "disabled";
};
diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
index 9df419a87d..6a205cd3df 100644
--- a/arch/arm/dts/fsl-ls1046a.dtsi
+++ b/arch/arm/dts/fsl-ls1046a.dtsi
@@ -52,7 +52,7 @@
interrupts = <0 64 0x4>;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <6>;
+ spi-num-chipselects = <6>;
big-endian;
status = "disabled";
};
@@ -65,7 +65,7 @@
interrupts = <0 65 0x4>;
clock-names = "dspi";
clocks = < 4 0>;
- num-cs = <6>;
+ spi-num-chipselects = <6>;
big-endian;
status = "disabled";
};
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 3a5a50fb83..9e48a3ab94 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -89,7 +89,7 @@
#size-cells = <0>;
reg = <0x0 0x210 0x0 0x1>;
interrupts = <0 26 0x4>; /* Level high type */
- num-cs = <6>;
+ spi-num-chipselects = <6>;
};
qspi: quadspi@155 {
diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
index 278daeeb6e..72ba5259
[PATCH v4 16/29] arm: dts: ls1028a: update the labels
Update the labels of the nodes to match the kernel ones.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
---
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 10 +++
.../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi | 2 +-
.../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 6 ++---
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 8 +++---
.../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi | 2 +-
.../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi | 4 +--
.../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 4 +--
arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 22
.../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds--sch-30841.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 2 +-
.../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4 +--
.../dts/fsl-ls1028a-qds--sch-24801.dtsi | 4 +--
arch/arm/dts/fsl-ls1028a-qds-duart.dts| 2 +-
.../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4 +--
.../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 4 +--
arch/arm/dts/fsl-ls1028a-qds.dtsi | 16 ++--
arch/arm/dts/fsl-ls1028a-rdb.dts | 22
arch/arm/dts/fsl-ls1028a.dtsi | 26 +--
23 files changed, 81 insertions(+), 81 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index fa4c05212a..42bd3138b2 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -5,13 +5,13 @@
/ {
aliases {
mmc0 =
- mmc1 =
+ mmc1 =
i2c0 =
i2c1 =
i2c2 =
rtc0 =
- ethernet2 =
- ethernet3 =
+ ethernet2 = _port2;
+ ethernet3 = _port3;
};
binman: binman {
@@ -250,7 +250,7 @@
u-boot,dm-pre-reloc;
};
- {
+ {
u-boot,dm-pre-reloc;
};
@@ -262,7 +262,7 @@
u-boot,dm-pre-reloc;
};
- {
+ {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
index 98e8939369..a46e07dc6b 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
@@ -3,6 +3,6 @@
/ {
aliases {
- ethernet0 =
+ ethernet0 = _port1;
};
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
index 33d85ed83a..ba2e4de96d 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
@@ -21,19 +21,19 @@
compatible = "kontron,sl28-var1", "kontron,sl28", "fsl,ls1028a";
};
- {
+_port0 {
status = "disabled";
/delete-property/ phy-handle;
};
- {
+_port1 {
phy-handle = <>;
phy-mode = "rgmii-id";
status = "okay";
};
/delete-node/
- {
+_mdio_pf3 {
phy0: ethernet-phy@4 {
reg = <0x4>;
eee-broken-1000t;
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index 7a3aa21408..db80874f4e 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -17,12 +17,12 @@
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
};
- {
+_port0 {
status = "disabled";
/delete-property/ phy-handle;
};
- {
+_port2 {
status = "okay";
};
@@ -45,12 +45,12 @@
};
_felix_port4 {
- ethernet = <>;
+ ethernet = <_port2>;
status = "okay";
};
/delete-node/
- {
+_mdio_pf3 {
phy0: ethernet-phy@5 {
reg = <0x5>;
eee-broken-1000t;
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
index 879a76415b..3d6bf5a0bd 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
@@ -3,6 +3,6 @@
/ {
aliases {
- ethernet0 =
+ ethernet0 = _port0;
};
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
index fce4694682..5d82973bba 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
+++ b/
[PATCH v4 21/29] scsi: ceva: rename the resource name to match the linux kernel one
The driver will look for a named resource "ecc-addr", but this isn't the
official binding. In fact, the official device tree binding
documentation doesn't mention any resource names at all. But it is safe
to assume that it's the linux ones we have to use if we want to be
compatible with the linux device tree. Thus rename "ecc-addr" to
"sata-ecc" and convert all the users in u-boot.
While at it, also rename "sata-base" to "ahci" although its not used at
all.
This change doesn't affect the SATA controller on the ZynqMP.
Cc: Michal Simek
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1012a.dtsi | 2 +-
arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
arch/arm/dts/fsl-ls1043a.dtsi | 2 +-
arch/arm/dts/fsl-ls1046a.dtsi | 2 +-
arch/arm/dts/fsl-ls1088a.dtsi | 2 +-
arch/arm/dts/ls1021a.dtsi | 2 +-
drivers/ata/sata_ceva.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index dcdcd444b3..0ea899c7d7 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -157,7 +157,7 @@
compatible = "fsl,ls1012a-ahci";
reg = <0x0 0x320 0x0 0x1 /* ccsr sata base */
0x0 0x20140520 0x0 0x4>; /* ecc sata addr */
- reg-names = "sata-base", "ecc-addr";
+ reg-names = "ahci", "sata-ecc";
interrupts = <0 69 4>;
clocks = < 4 0>;
status = "disabled";
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index cf381a0856..34aad526fe 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -338,7 +338,7 @@
compatible = "fsl,ls1028a-ahci";
reg = <0x0 0x320 0x0 0x1/* ccsr sata
base */
0x7 0x100520 0x0 0x4>; /* ecc sata
addr*/
- reg-names = "sata-base", "ecc-addr";
+ reg-names = "ahci", "sata-ecc";
interrupts = ;
status = "disabled";
};
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index 3aaec8b6af..52dc5a9638 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -331,7 +331,7 @@
compatible = "fsl,ls1043a-ahci";
reg = <0x0 0x320 0x0 0x1 /* ccsr sata base */
0x0 0x20140520 0x0 0x4>; /* ecc sata addr*/
- reg-names = "sata-base", "ecc-addr";
+ reg-names = "ahci", "sata-ecc";
interrupts = <0 69 4>;
clocks = < 4 0>;
status = "disabled";
diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
index 6a205cd3df..a60cbf11fc 100644
--- a/arch/arm/dts/fsl-ls1046a.dtsi
+++ b/arch/arm/dts/fsl-ls1046a.dtsi
@@ -367,7 +367,7 @@
compatible = "fsl,ls1046a-ahci";
reg = <0x0 0x320 0x0 0x1 /* ccsr sata base */
0x0 0x20140520 0x0 0x4>; /* ecc sata addr*/
- reg-names = "sata-base", "ecc-addr";
+ reg-names = "ahci", "sata-ecc";
interrupts = <0 69 4>;
clocks = < 4 1>;
status = "disabled";
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 9e48a3ab94..ee0e3b367d 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -226,7 +226,7 @@
compatible = "fsl,ls1088a-ahci";
reg = <0x0 0x320 0x0 0x1 /* ccsr sata base */
0x7 0x100520 0x0 0x4>; /* ecc sata addr*/
- reg-names = "sata-base", "ecc-addr";
+ reg-names = "ahci", "sata-ecc";
interrupts = <0 133 4>;
status = "disabled";
};
diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 8aefc82f87..86192cbb7f 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -469,7 +469,7 @@
sata: sata@320 {
compatible = "fsl,ls1021a-ahci";
reg = <0x320 0x1 0x20220520 0x4>;
- reg-names = "sata-base", "
[PATCH v4 20/29] serial: lpuart: add new compatible fsl, ls1028a-lpuart
The official ls1028a binding of the driver uses the following as
compatibles:
compatible = "fsl,ls1028a-lpuart";
Add the missing compatible to the driver and update the device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 18 ++
drivers/serial/serial_lpuart.c | 2 ++
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 7da32561a4..cf381a0856 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -232,62 +232,56 @@
};
lpuart0: serial@226 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x226 0x0 0x1000>;
interrupts = <0 232 0x4>;
clocks = <>;
clock-names = "ipg";
- little-endian;
status = "disabled";
};
lpuart1: serial@227 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x227 0x0 0x1000>;
interrupts = <0 233 0x4>;
clocks = <>;
clock-names = "ipg";
- little-endian;
status = "disabled";
};
lpuart2: serial@228 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x228 0x0 0x1000>;
interrupts = <0 234 0x4>;
clocks = <>;
clock-names = "ipg";
- little-endian;
status = "disabled";
};
lpuart3: serial@229 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x229 0x0 0x1000>;
interrupts = <0 235 0x4>;
clocks = <>;
clock-names = "ipg";
- little-endian;
status = "disabled";
};
lpuart4: serial@22a {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x22a 0x0 0x1000>;
interrupts = <0 236 0x4>;
clocks = <>;
clock-names = "ipg";
- little-endian;
status = "disabled";
};
lpuart5: serial@22b {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x22b 0x0 0x1000>;
interrupts = <0 237 0x4>;
clocks = <>;
clock-names = "ipg";
- little-endian;
status = "disabled";
};
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index 2b473d70f6..3c9a69598a 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -553,6 +553,8 @@ static const struct dm_serial_ops lpuart_serial_ops = {
static const struct udevice_id lpuart_serial_ids[] = {
{ .compatible = "fsl,ls1021a-lpuart", .data =
LPUART_FLAG_REGMAP_32BIT_REG | LPUART_FLAG_REGMAP_ENDIAN_BIG },
+ { .compatible = "fsl,ls1028a-lpuart",
+ .data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,imx7ulp-lpuart",
.data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,vf610-lpuart"},
--
2.30.2
[PATCH v4 22/29] usb: xhci: fsl: add new compatible fsl,ls1028a-dwc3
The official ls1028a binding of the driver uses the following as
compatibles:
compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
Change the ls1028a device tree and add this new compatible to the fsl
specific xhci driver, otherwise the generic dwc3 driver will be used
with the compatibles above.
Cc: Bin Meng
Cc: Marek Vasut
Signed-off-by: Michael Walle
Reviewed-by: Bin Meng
---
arch/arm/dts/fsl-ls1028a.dtsi | 4 ++--
drivers/usb/host/xhci-fsl.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 34aad526fe..cc055e65e5 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -319,7 +319,7 @@
};
usb0: usb3@310 {
- compatible = "fsl,layerscape-dwc3";
+ compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
reg = <0x0 0x310 0x0 0x1>;
interrupts = ;
dr_mode = "host";
@@ -327,7 +327,7 @@
};
usb1: usb3@311 {
- compatible = "fsl,layerscape-dwc3";
+ compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
reg = <0x0 0x311 0x0 0x1>;
interrupts = ;
dr_mode = "host";
diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
index f062f12ade..80871908dc 100644
--- a/drivers/usb/host/xhci-fsl.c
+++ b/drivers/usb/host/xhci-fsl.c
@@ -159,6 +159,7 @@ static int xhci_fsl_remove(struct udevice *dev)
static const struct udevice_id xhci_usb_ids[] = {
{ .compatible = "fsl,layerscape-dwc3", },
+ { .compatible = "fsl,ls1028a-dwc3", },
{ }
};
--
2.30.2
[PATCH v4 23/29] pci: layerscape: add official ls1028a binding support
The official bindind of the PCIe controller of the ls1028a has the
following compatible string:
compatible = "fsl,ls1028a-pcie";
Additionally, the resource names and count are different. Update the
driver to support this binding and change the entry in the ls1028a
device tree.
Cc: Hou Zhiqiang
Signed-off-by: Michael Walle
---
arch/arm/dts/fsl-ls1028a.dtsi| 20 +--
drivers/pci/pcie_layerscape_rc.c | 61 +++-
2 files changed, 53 insertions(+), 28 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index cc055e65e5..435b965d00 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -344,12 +344,10 @@
};
pcie1: pcie@340 {
- compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
"snps,dw-pcie";
- reg = <0x00 0x0340 0x0 0x8
- 0x00 0x0348 0x0 0x4 /* lut registers */
- 0x00 0x034c 0x0 0x4 /* pf controls
registers */
- 0x80 0x 0x0 0x2>; /* configuration
space */
- reg-names = "dbi", "lut", "ctrl", "config";
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010>, /* controller
registers */
+ <0x80 0x 0x0 0x2000>; /*
configuration space */
+ reg-names = "regs", "config";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -360,12 +358,10 @@
};
pcie2: pcie@350 {
- compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
"snps,dw-pcie";
- reg = <0x00 0x0350 0x0 0x8
- 0x00 0x0358 0x0 0x4 /* lut registers */
- 0x00 0x035c 0x0 0x4 /* pf controls
registers */
- 0x88 0x 0x0 0x2>; /* configuration
space */
- reg-names = "dbi", "lut", "ctrl", "config";
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x0350 0x0 0x0010>, /* controller
registers */
+ <0x88 0x 0x0 0x2000>; /*
configuration space */
+ reg-names = "regs", "config";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
diff --git a/drivers/pci/pcie_layerscape_rc.c b/drivers/pci/pcie_layerscape_rc.c
index f50d6ef653..217b420076 100644
--- a/drivers/pci/pcie_layerscape_rc.c
+++ b/drivers/pci/pcie_layerscape_rc.c
@@ -21,6 +21,12 @@
DECLARE_GLOBAL_DATA_PTR;
+struct ls_pcie_drvdata {
+ u32 lut_offset;
+ u32 ctrl_offset;
+ bool big_endian;
+};
+
static void ls_pcie_cfg0_set_busdev(struct ls_pcie_rc *pcie_rc, u32 busdev)
{
struct ls_pcie *pcie = pcie_rc->pcie;
@@ -243,6 +249,7 @@ static void ls_pcie_setup_ctrl(struct ls_pcie_rc *pcie_rc)
static int ls_pcie_probe(struct udevice *dev)
{
+ const struct ls_pcie_drvdata *drvdata = (void
*)dev_get_driver_data(dev);
struct ls_pcie_rc *pcie_rc = dev_get_priv(dev);
const void *fdt = gd->fdt_blob;
int node = dev_of_offset(dev);
@@ -260,8 +267,12 @@ static int ls_pcie_probe(struct udevice *dev)
pcie_rc->pcie = pcie;
+ /* try resource name of the official binding first */
ret = fdt_get_named_resource(fdt, node, "reg", "reg-names",
-"dbi", _rc->dbi_res);
+"regs", _rc->dbi_res);
+ if (ret)
+ ret = fdt_get_named_resource(fdt, node, "reg", "reg-names",
+"dbi", _rc->dbi_res);
if (ret) {
printf("ls-pcie: resource \"dbi\" not found\n");
return ret;
@@ -287,21 +298,29 @@ static int ls_pcie_probe(struct udevice *dev)
if (pcie->mode == PCI_HEADER_TYPE_NORMAL)
return 0;
- ret = fdt_get_named_resource(fdt, node, "reg", "reg-names",
-"lut", _rc->lut_res);
- if (!ret)
- pcie->lut = map_physmem(pcie_rc->lut_res.start,
- fdt_resource_size(_rc->lut_res),
-
[PATCH v4 29/29] arm: dts: sl28: sync dtbs
Copy the board device tree files from linux v5.14. On top of the v5.14
dtbs the changes of these two patches are included here which are needed
for u-boot:
https://lore.kernel.org/linux-devicetree/20210831134013.1625527-7-mich...@walle.cc/
https://lore.kernel.org/linux-devicetree/20210831134013.1625527-8-mich...@walle.cc/
At the time of this writing the patches are still pending but already
have Reviewed-by tags.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 12 +-
.../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 31 +--
.../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi | 8 +
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 40 +--
.../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 16 +-
arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 250 +++---
6 files changed, 265 insertions(+), 92 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 25aa274765..8538ce7984 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -4,12 +4,9 @@
/ {
aliases {
- mmc0 =
- mmc1 =
i2c0 =
i2c1 =
i2c2 =
- rtc0 =
ethernet2 = _port2;
ethernet3 = _port3;
};
@@ -234,11 +231,6 @@
};
#endif
- {
- rtc: rtc@32 {
- };
-};
-
{
u-boot,dm-pre-reloc;
flash@0 {
@@ -279,6 +271,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
index ba2e4de96d..7cd29ab970 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
@@ -8,7 +8,7 @@
* None of the four SerDes lanes are used by the module, instead they are
* all led out to the carrier for customer use.
*
- * Copyright (C) 2020 Michael Walle
+ * Copyright (C) 2021 Michael Walle
*
*/
@@ -21,28 +21,17 @@
compatible = "kontron,sl28-var1", "kontron,sl28", "fsl,ls1028a";
};
-_port0 {
- status = "disabled";
- /delete-property/ phy-handle;
-};
-
-_port1 {
- phy-handle = <>;
- phy-mode = "rgmii-id";
- status = "okay";
-};
-
-/delete-node/
_mdio_pf3 {
+ /* Delete unused phy node */
+ /delete-node/ ethernet-phy@5;
+
phy0: ethernet-phy@4 {
reg = <0x4>;
eee-broken-1000t;
eee-broken-100tx;
-
qca,clk-out-frequency = <12500>;
qca,clk-out-strength = ;
qca,keep-pll-enabled;
-
vddio-supply = <>;
vddio: vddio-regulator {
@@ -56,3 +45,15 @@
};
};
};
+
+_port0 {
+ status = "disabled";
+ /* Delete the phy-handle to the old phy0 label */
+ /delete-property/ phy-handle;
+};
+
+_port1 {
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
index 4e0ce3f77d..c010ea0dc7 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
@@ -7,3 +7,11 @@
ethernet1 = _felix_port1;
};
};
+
+_felix_port0 {
+ label = "gbe0";
+};
+
+_felix_port1 {
+ label = "gbe1";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index db80874f4e..330e34f933 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -2,10 +2,10 @@
/*
* Device Tree file for the Kontron SMARC-sAL28 board.
*
- * This is for the network variant 2 which has no ethernet support in the
- * bootloader.
+ * This is for the network variant 2 which has two ethernet ports. These
+ * ports are connected to the internal switch.
*
- * Copyright (C) 2020 Michael Walle
+ * Copyright (C) 2021 Michael Walle
*
*/
@@ -17,8 +17,21 @@
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
};
+_mdio_pf3 {
+ phy1: ethernet-phy@4 {
+ reg = <0x4>;
+ eee-broken-1000t;
+ eee-broken-100tx;
+ };
+};
+
_port0 {
status = "disabled";
+ /*
+* In the base device tree the PHY at address 5 was assigned for
+* this port. On this module this PHY is connected to a switch
+* port instead. Therefore, delete the phy-handle property
[PATCH v4 27/29] arm: dts: ls1028a: drop non-removable property from esdhc controller node
The linux device tree hasn't set this property. To be similar we remove it from the u-boot device tree, too. The second controller of the LS1028A has indeed no card detect pin because it only supports eMMC devices. The present state register of the second controller will always report the card as present. Thus, there should be no functional change otherwise than one more register access to read the present state. The property should still be introduced in the linux device tree. Signed-off-by: Michael Walle --- arch/arm/dts/fsl-ls1028a.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi index d2f558d208..af6dabe847 100644 --- a/arch/arm/dts/fsl-ls1028a.dtsi +++ b/arch/arm/dts/fsl-ls1028a.dtsi @@ -210,7 +210,6 @@ reg = <0x0 0x215 0x0 0x1>; interrupts = ; big-endian; - non-removable; bus-width = <4>; status = "disabled"; }; -- 2.30.2
[PATCH v4 00/29] arm: dts: ls1028a: sync device tree with linux
This series sync the device tree of the LS1028A SoC with the linux one.
To ease future debugging and reviewing, we first clean up the existing one,
removing bogus nodes, moving all CCSR related nodes in /soc and update the
drivers to accept the offical compatible strings.
This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the
LS1028A-RDB and -QDS. It would be nice if someone could actually test it on
such a board.
I didn't sync the device trees for the NXP boards because u-boot related
things aren't split into its own -u-boot.dtsi file. So I'll leave that task
to NXP :)
The following patch is a prerequisite for this series:
https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/
changes since v3:
- rebase to latest master
- don't support fsl,ls1028a-gpu anymore, use the upstream compatible
string
changes since v2:
- move the device tree nodes piece by piece and sort them to ease
reviewing
- fix PCI driver (bindings)
- fix SATA driver (bindings)
- fix USB driver (bindings)
- split most changes which are caused by the sync of the linux
device tree to own patches, eg. pcie io window, spi chip selects
The final diff for the sync is much nicer now ;)
changes since v1:
- remove u-boot,dm-pre-reloc from rdb and qds boards
- fix enetc0 and enetc2 labels
Michael Walle (29):
armv8: ls1028a: use the official compatible string for the GPU
arm: dts: ls1028a: remove /memory node
arm: dts: ls1028a-{rdb,qds}: remove dm-pre-reloc property
arm: dts: ls1028a: add an empty /soc
arm: dts: ls1028a: move the clockgen node into /soc
arm: dts: ls1028a: move I2C controller nodes into /soc
arm: dts: ls1028a: move the FlexSPI controller node
arm: dts: ls1028a: move the SPI and eSDHC controller nodes into /soc
arm: dts: ls1028a: move the UART controller nodes into /soc
arm: dts: ls1028a: move the low-power UART nodes into /soc
arm: dts: ls1028a: move the GPIO controller nodes into /soc
arm: dts: ls1028a: move SATA and USB controller nodes into /soc
arm: dts: ls1028a: move the PCIe controller nodes into /soc
arm: dts: ls1028a: move the watchdog node into /soc
arm: dts: ls1028a: move the iRC node and its devices into /soc
arm: dts: ls1028a: update the labels
watchdog: sp805_wdt: use correct compatible string
spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi
spi: fsl_dspi: rename num-cs to spi-num-chipselects
serial: lpuart: add new compatible fsl,ls1028a-lpuart
scsi: ceva: rename the resource name to match the linux kernel one
usb: xhci: fsl: add new compatible fsl,ls1028a-dwc3
pci: layerscape: add official ls1028a binding support
arm: dts: ls1028a: remove num-lanes in the PCIe controller nodes
arm: dts: ls1028a: move the PCI I/O window to match
arm: dts: ls1028a: disable the PCIe controller by default
arm: dts: ls1028a: drop non-removable property from esdhc controller
node
arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
arm: dts: sl28: sync dtbs
arch/arm/cpu/armv8/fsl-layerscape/fdt.c |2 +-
.../arm/cpu/armv8/fsl-layerscape/ls1028_ids.c |2 +-
arch/arm/dts/fsl-ls1012a.dtsi |4 +-
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 37 +-
.../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi |2 +-
.../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 31 +-
.../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi |8 +
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46 +-
.../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi |2 +-
.../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi |4 +-
.../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 18 +-
arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 256 ++-
.../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi |4 +-
.../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi |4 +-
.../dts/fsl-ls1028a-qds--sch-30841.dtsi | 12 +-
.../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi |8 +-
.../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi |4 +-
.../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 12 +-
.../dts/fsl-ls1028a-qds--sch-24801.dtsi | 12 +-
arch/arm/dts/fsl-ls1028a-qds-duart.dts|2 +-
.../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 12 +-
.../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 12 +-
.../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi |6 +-
.../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi |6 +-
arch/arm/dts/fsl-ls1028a-qds.dtsi | 25 +-
arch/arm/dts/fsl-ls1028a-rdb.dts | 31 +-
arch/arm/dts/fsl-ls1028a.dtsi | 1443 -
arch/arm/dts/fsl-ls1043a.dtsi |6 +-
arch/arm/dts/fsl-ls1046a.dtsi |6 +-
arch/arm/dts/fsl-ls1088a.dtsi |4 +-
arch/arm/dts/fsl-ls2080a.dtsi |2 +-
arch/arm/dts/fsl-lx2160a.dtsi |6 +-
arch/arm/dts/hi3660.dtsi |4 +-
arch/arm/dts/ls1021a.dtsi |6 +-
arch/arm/dts
[PATCH v4 01/29] armv8: ls1028a: use the official compatible string for the GPU
There is no "fsl,ls1028a-gpu" compatible string. It is solely for the
proprietary driver which will never be open source. Lately, linux gained
support for the open source etnaviv driver for the GPU (although there
is still support for the DisplayPort PHY missing to get actual graphics
output). Thus, instead of supporting some proprietary driver, switch
over to the open source one, which also have an official device tree
binding.
Cc: Andy Tang
Signed-off-by: Michael Walle
---
For reference:
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=55ca18c0d906a88e874fdc70dd6ff4ed009c88a2
arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 2 +-
arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 6eb7f9c214..4ec0dbf516 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -427,7 +427,7 @@ static void fdt_disable_multimedia(void *blob, unsigned int
svr)
fdt_status_disabled(blob, off);
/* Disable GPU node */
- off = fdt_node_offset_by_compatible(blob, -1, "fsl,ls1028a-gpu");
+ off = fdt_node_offset_by_compatible(blob, -1, "vivante,gc");
if (off != -FDT_ERR_NOTFOUND)
fdt_status_disabled(blob, off);
}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
index 49df8b3790..86a49b152e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
@@ -18,7 +18,7 @@ struct icid_id_table icid_tbl[] = {
SET_SATA_ICID(1, "fsl,ls1028a-ahci", FSL_SATA1_STREAM_ID),
SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
SET_QDMA_ICID("fsl,ls1028a-qdma", FSL_DMA_STREAM_ID),
- SET_GPU_ICID("fsl,ls1028a-gpu", FSL_GPU_STREAM_ID),
+ SET_GPU_ICID("vivante,gc", FSL_GPU_STREAM_ID),
SET_DISPLAY_ICID(FSL_DISPLAY_STREAM_ID),
#ifdef CONFIG_FSL_CAAM
SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_JR1_STREAM_ID),
--
2.30.2
[PATCH v4 10/29] arm: dts: ls1028a: move the low-power UART nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 120 +-
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 07aeb380ef..349c4bf862 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -174,66 +174,6 @@
};
};
- lpuart0: serial@226 {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x226 0x0 0x1000>;
- interrupts = <0 232 0x4>;
- clocks = <>;
- clock-names = "ipg";
- little-endian;
- status = "disabled";
- };
-
- lpuart1: serial@227 {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x227 0x0 0x1000>;
- interrupts = <0 233 0x4>;
- clocks = <>;
- clock-names = "ipg";
- little-endian;
- status = "disabled";
- };
-
- lpuart2: serial@228 {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x228 0x0 0x1000>;
- interrupts = <0 234 0x4>;
- clocks = <>;
- clock-names = "ipg";
- little-endian;
- status = "disabled";
- };
-
- lpuart3: serial@229 {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x229 0x0 0x1000>;
- interrupts = <0 235 0x4>;
- clocks = <>;
- clock-names = "ipg";
- little-endian;
- status = "disabled";
- };
-
- lpuart4: serial@22a {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x22a 0x0 0x1000>;
- interrupts = <0 236 0x4>;
- clocks = <>;
- clock-names = "ipg";
- little-endian;
- status = "disabled";
- };
-
- lpuart5: serial@22b {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x22b 0x0 0x1000>;
- interrupts = <0 237 0x4>;
- clocks = <>;
- clock-names = "ipg";
- little-endian;
- status = "disabled";
- };
-
usb1: usb3@310 {
compatible = "fsl,layerscape-dwc3";
reg = <0x0 0x310 0x0 0x1>;
@@ -484,5 +424,65 @@
interrupts = ;
status = "disabled";
};
+
+ lpuart0: serial@226 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x226 0x0 0x1000>;
+ interrupts = <0 232 0x4>;
+ clocks = <>;
+ clock-names = "ipg";
+ little-endian;
+ status = "disabled";
+ };
+
+ lpuart1: serial@227 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x227 0x0 0x1000>;
+ interrupts = <0 233 0x4>;
+ clocks = <>;
+ clock-names = "ipg";
+ little-endian;
+ status = "disabled";
+ };
+
+ lpuart2: serial@228 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x228 0x0 0x1000>;
+ interrupts = <0 234 0x4>;
+ clocks = <>;
+ clock-names = "ipg";
+ little-endian;
+ status = "disabled";
+ };
+
+ lpuart3: serial@229 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x229 0x0 0x1000>;
+ interrupts = <0 235 0x4>;
+ clocks = <>;
+ clock-names = "ipg";
+ little-endian;
+ status = "disabled";
+ };
+
+ lpuart4: serial@22a {
+ compatible = "fsl,ls1021a-lpuart";
+
[PATCH v4 13/29] arm: dts: ls1028a: move the PCIe controller nodes into /soc
While inserting them into the new location, keep them sorted by the
register base offset just like in the linux kernel device tree.
While at it fix the indentation.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 64 +--
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 7d18085615..d0f90941b9 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -43,38 +43,6 @@
IRQ_TYPE_LEVEL_LOW)>;
};
- pcie1: pcie@340 {
- compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
- reg = <0x00 0x0340 0x0 0x8
- 0x00 0x0348 0x0 0x4 /* lut registers */
- 0x00 0x034c 0x0 0x4 /* pf controls registers */
- 0x80 0x 0x0 0x2>; /* configuration space */
- reg-names = "dbi", "lut", "ctrl", "config";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- num-lanes = <4>;
- bus-range = <0x0 0xff>;
- ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
0x0001 /* downstream I/O */
- 0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
- };
-
- pcie2: pcie@350 {
- compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
- reg = <0x00 0x0350 0x0 0x8
- 0x00 0x0358 0x0 0x4 /* lut registers */
- 0x00 0x035c 0x0 0x4 /* pf controls registers */
- 0x88 0x 0x0 0x2>; /* configuration space */
- reg-names = "dbi", "lut", "ctrl", "config";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- num-lanes = <4>;
- bus-range = <0x0 0xff>;
- ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
0x0001 /* downstream I/O */
- 0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
- };
-
pcie@1f000 {
compatible = "pci-host-ecam-generic";
/* ECAM bus 0, HW has more space reserved but not populated */
@@ -484,5 +452,37 @@
interrupts = ;
status = "disabled";
};
+
+ pcie1: pcie@340 {
+ compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
"snps,dw-pcie";
+ reg = <0x00 0x0340 0x0 0x8
+ 0x00 0x0348 0x0 0x4 /* lut registers */
+ 0x00 0x034c 0x0 0x4 /* pf controls
registers */
+ 0x80 0x 0x0 0x2>; /* configuration
space */
+ reg-names = "dbi", "lut", "ctrl", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ };
+
+ pcie2: pcie@350 {
+ compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
"snps,dw-pcie";
+ reg = <0x00 0x0350 0x0 0x8
+ 0x00 0x0358 0x0 0x4 /* lut registers */
+ 0x00 0x035c 0x0 0x4 /* pf controls
registers */
+ 0x88 0x 0x0 0x2>; /* configuration
space */
+ reg-names = "dbi", "lut", "ctrl", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <4>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ };
};
};
--
2.30.2
[PATCH v4 14/29] arm: dts: ls1028a: move the watchdog node into /soc
While inserting it into the new location, keep it sorted by the
register base offset just like in the linux kernel device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index d0f90941b9..c289009ca1 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -142,11 +142,6 @@
};
};
- cluster1_core0_watchdog: wdt@c00 {
- compatible = "arm,sp805-wdt";
- reg = <0x0 0xc00 0x0 0x1000>;
- };
-
soc: soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -484,5 +479,10 @@
ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
0x0001 /* downstream I/O */
0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
+
+ cluster1_core0_watchdog: wdt@c00 {
+ compatible = "arm,sp805-wdt";
+ reg = <0x0 0xc00 0x0 0x1000>;
+ };
};
};
--
2.30.2
[PATCH v4 26/29] arm: dts: ls1028a: disable the PCIe controller by default
Disable the PCIe controllers by default, just like in the linux device
tree. But there is one catch, for linux they are enabled in-place by the
bootloader. Obviously, this doesn't work for the bootloader. Thus we
explicitly enable the controllers in the -u-boot.dtsi files.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 13 +
arch/arm/dts/fsl-ls1028a-qds.dtsi | 8
arch/arm/dts/fsl-ls1028a-rdb.dts | 8
arch/arm/dts/fsl-ls1028a.dtsi | 2 ++
4 files changed, 31 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 42bd3138b2..25aa274765 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -266,6 +266,19 @@
u-boot,dm-pre-reloc;
};
+/*
+ * u-boot will enable the device in the linux device tree in place. Because
+ * we are using the linux device tree, we have to enable the PCI controller
+ * ourselves.
+ */
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi
b/arch/arm/dts/fsl-ls1028a-qds.dtsi
index babd8445ee..0da0a7bc5d 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
@@ -240,6 +240,14 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 18ee363d75..537ebbc697 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -122,6 +122,14 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index f11e75032b..d2f558d208 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -354,6 +354,7 @@
bus-range = <0x0 0xff>;
ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
0x0001 /* downstream I/O */
0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ status = "disabled";
};
pcie2: pcie@350 {
@@ -367,6 +368,7 @@
bus-range = <0x0 0xff>;
ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
0x0001 /* downstream I/O */
0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ status = "disabled";
};
cluster1_core0_watchdog: wdt@c00 {
--
2.30.2
[PATCH v4 25/29] arm: dts: ls1028a: move the PCI I/O window to match
To make the synchronization of the u-boot device tree with the one from linux easier, move the I/O window to the one which is specified in the linux device tree. The actual value shouldn't matter as long as it mapped to the corresponding memory window of the PCIe controller which is a 32GiB window at 80__h (first controller) or 88__h (second controller). Signed-off-by: Michael Walle Reviewed-by: Hou Zhiqiang --- arch/arm/dts/fsl-ls1028a.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi index 3ef710bb3d..f11e75032b 100644 --- a/arch/arm/dts/fsl-ls1028a.dtsi +++ b/arch/arm/dts/fsl-ls1028a.dtsi @@ -352,7 +352,7 @@ #size-cells = <2>; device_type = "pci"; bus-range = <0x0 0xff>; - ranges = <0x8100 0x0 0x 0x80 0x0002 0x0 0x0001 /* downstream I/O */ + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0 0x0001 /* downstream I/O */ 0x8200 0x0 0x4000 0x80 0x4000 0x0 0x4000>; /* non-prefetchable memory */ }; @@ -365,7 +365,7 @@ #size-cells = <2>; device_type = "pci"; bus-range = <0x0 0xff>; - ranges = <0x8100 0x0 0x 0x88 0x0002 0x0 0x0001 /* downstream I/O */ + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0 0x0001 /* downstream I/O */ 0x8200 0x0 0x4000 0x88 0x4000 0x0 0x4000>; /* non-prefetchable memory */ }; -- 2.30.2
[PATCH v4 28/29] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Now that everything is prepared, copy the fsl-ls1028a.dtsi from the
linux kernel v5.14.
Notable changes:
- second watchdog added
- the number of chip selects of the SPI controller is now correct and
reflects what the hardware offers
- the LPUARTs have the correct clock parent
- USB controllers are enabled by default, which was already the case
before this sync because all board enabled all the USB controller
nodes. A linux patch to fix this is pending.
- the eSDHC controller changes from big-endian to little-endian, but
that property seems to be not used at all.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a.dtsi | 861 --
.../dt-bindings/clock/fsl,qoriq-clockgen.h| 15 +
2 files changed, 786 insertions(+), 90 deletions(-)
create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index af6dabe847..343ecf0e89 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -1,12 +1,16 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * NXP ls1028a SOC common device tree source
+ * Device Tree Include file for NXP Layerscape-1028A family SoC.
*
- * Copyright 2019-2020 NXP
+ * Copyright 2018-2020 NXP
+ *
+ * Harninder Rai
*
*/
+#include
#include
+#include
/ {
compatible = "fsl,ls1028a";
@@ -14,6 +18,54 @@
#address-cells = <2>;
#size-cells = <2>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x0>;
+ enable-method = "psci";
+ clocks = < QORIQ_CLK_CMUX 0>;
+ next-level-cache = <>;
+ cpu-idle-states = <_PW20>;
+ #cooling-cells = <2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x1>;
+ enable-method = "psci";
+ clocks = < QORIQ_CLK_CMUX 0>;
+ next-level-cache = <>;
+ cpu-idle-states = <_PW20>;
+ #cooling-cells = <2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ idle-states {
+ /*
+* PSCI node is not added default, U-boot will add missing
+* parts if it determines to use PSCI.
+*/
+ entry-method = "psci";
+
+ CPU_PW20: cpu-pw20 {
+ compatible = "arm,idle-state";
+ idle-state-name = "PW20";
+ arm,psci-suspend-param = <0x0>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
+
sysclk: sysclk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -21,14 +73,33 @@
clock-output-names = "sysclk";
};
- gic: interrupt-controller@600 {
- compatible = "arm,gic-v3";
- reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
- <0x0 0x0604 0 0x4>;
- #interrupt-cells = <3>;
- interrupt-controller;
- interrupts = ;
+ osc_27m: clock-osc-27m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2700>;
+ clock-output-names = "phy_27m";
+ };
+
+ dpclk: clock-controller@f1f {
+ compatible = "fsl,ls1028a-plldig";
+ reg = <0x0 0xf1f 0x0 0x>;
+ #clock-cells = <0>;
+ clocks = <_27m>;
+ };
+
+ firmware {
+ optee: optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ status = "disabled";
+ };
+ };
+
+ reboot {
+ compatible ="syscon-reboot";
+ regmap = <>;
+ offset = <0>;
+ mask = <0x02>;
};
timer {
Re: [PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset
>On Mon, Sep 13, 2021 at 01:22:10PM +0530, Rayagonda Kokatanur wrote: >> On Mon, Sep 13, 2021 at 11:29 AM Priyanka Jain (OSS) >> wrote: .. >> > Tom, >> > >> > I agree that bindings patch is essential for device-tree changes. >> > But merging this patch will break Layerscape Platforms. >> > We have requested Rayagonda to submit Binding patch to upstream for review. >> > >> > If first patch of binding gets submitted timely, can we defer this patch. >> > >> > Regards >> > Priyanka >> > >> ++Bharat, Roman and Henrik. > > Yes, please keep me in the loop on this binding being reviewed upstream. > Also, please check the tree for other bindings that haven't been > submitted, but also haven't been noticed yet. There is not supposed to > be anything outside of the -u-boot.dtsi files that can't be replaced by > dropping in a newer set of upstream dts files. And the -u-boot.dtsi > files are for u-boot specific bindings (that we're working on > upstreaming) or actively in-review bindings upstream. Are there any news on this topic? Was there a submission to linux for the binding in the meantime? Unfortunately, I wasn't in the loop here (albeit being the Reported-by: one). Until now, this patch is a prerequisite for my ls1028a device tree sync series [1]. -michael [1] https://lore.kernel.org/u-boot/20211013161427.612033-1-mich...@walle.cc/
Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS): Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS): Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY. I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP. Ok. What will the overlay do? Could you give an example? This overlay will be disabling the crypto nodes which will be used by optee in secure world, so that linux should not use it. Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too? Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting. If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no? Yes, I got your point now, and is very valid, but as of now for u-boot we are just using the first available node for communicating with CAAM leaving other job rings as it is. So we need not to apply overlay to DTB used by uboot. But we should do the correct thing, so that u-boot and linux doesn't see a different version of the device tree. Also what do you mean with "the first available node"? There is already a new CAAM driver for u-boot pending, see https://lore.kernel.org/u-boot/2025070014.17586-1-gaurav.j...@nxp.com/ -michael
RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Am 17. Dezember 2021 11:19:42 GMT+05:00 schrieb "Sahil Malhotra (OSS)" : >Hi Michael/Andrey > >Gentle reminder for comment on this patch series. > >Regards, >Sahil Malhotra > >> -Original Message- >> From: Sahil Malhotra (OSS) >> Sent: Friday, December 10, 2021 12:03 PM >> To: ZHIZHIKIN Andrey ; Sahil >> Malhotra (OSS) ; Michael Walle >> >> Cc: Clément Faure ; Gaurav Jain >> ; Pankaj Gupta ; Priyanka >> Jain ; u-boot@lists.denx.de; Varun Sethi >> ; Ye Li >> Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature >> >> Hi Andrey, >> >> > -Original Message----- >> > From: ZHIZHIKIN Andrey >> > Sent: Wednesday, December 8, 2021 3:43 PM >> > To: Sahil Malhotra (OSS) ; Michael Walle >> > >> > Cc: Clément Faure ; Gaurav Jain >> > ; Pankaj Gupta ; >> Priyanka >> > Jain ; u-boot@lists.denx.de; Varun Sethi >> > ; Ye Li >> > Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature >> > >> > Hello Sahil, >> > >> > > -Original Message- >> > > From: Sahil Malhotra (OSS) >> > > Sent: Wednesday, December 8, 2021 7:12 AM >> > > To: Michael Walle ; Sahil Malhotra (OSS) >> > > >> > > Cc: Clément Faure ; Gaurav Jain >> > > ; Pankaj Gupta ; >> > Priyanka >> > > Jain ; u- b...@lists.denx.de; Varun Sethi >> > > ; Ye Li ; ZHIZHIKIN Andrey >> > > >> > > Subject: RE: [PATCH 1/2] fsl-layerscape: add dtb overlay feature >> > > >> > > >> > > Hi Michael, >> > > >> > > -Original Message- >> > > From: Michael Walle >> > > Sent: Monday, November 29, 2021 11:17 PM >> > > To: Sahil Malhotra (OSS) >> > > Cc: Clément Faure ; Gaurav Jain >> > > ; Pankaj Gupta ; >> > Priyanka >> > > Jain ; u- b...@lists.denx.de; Varun Sethi >> > > ; Ye Li ; ZHIZHIKIN Andrey >> > > >> > > Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature >> > > >> > > Hi Sahil, >> > > >> > > Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS): >> > > > Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS): >> > > >>> Could you please add some description what this is doing and for >> > > >>> what this is intended? To have a "DTB overlay feature", it is >> > > >>> enough to just enable CONFIG_OF_LIBFDT_OVERLAY. >> > > >> I will add some description, and yes for DTB overlay feature, it >> > > >> is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do >> > > >> this step before booting the kernel that's why also have to >> > > >> enable CONFIG_OF_SYSTEM_SETUP. >> > > > >> > > >> Ok. What will the overlay do? Could you give an example? >> > > > This overlay will be disabling the crypto nodes which will be used >> > > > by optee in secure world, so that linux should not use it. >> > > > >> > > > >> > > >>> Apparently you're adding an overlay passed by optee. Doesn't >> > > >>> this have to be applied to u-boot's control dtb too? >> > > >> Yes, we will be applying the overlay passed by optee, yes it will >> > > >> be applied to dtb which will be passed to uboot for kernel booting. >> > > > >> > > >> If I read this patch correctly, you're modifying the DT before >> > > >> you jump to linux. But I was asking whether you also have to >> > > >> modify the DT which is used by u-boot. Eg. if you disable some >> > > >> kind of crypto nodes (because optee will use them in secure >> > > >> world), this also have to communicated to u-boot, not only linux, no? >> > > > Yes, I got your point now, and is very valid, but as of now for >> > > > u-boot we are just using the first available node for >> > > > communicating with CAAM leaving other job rings as it is. >> > > > So we need not to apply overlay to DTB used by uboot. >> > > >> > > > But we should do the correct thing, so that u-boot and linux >> > > > doesn't see a >> > > different version of the device tree. >> > > >> > > > Also what do you mean with "the first available node"? >> >
Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World. OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over. Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb? -michael
Re: [PATCH v2 14/16] arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi
Am 2021-12-07 21:20, schrieb Vladimir Oltean: diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts index 10070eab6e61..70fcf71dbd0e 100644 --- a/arch/arm/dts/fsl-ls1028a-rdb.dts +++ b/arch/arm/dts/fsl-ls1028a-rdb.dts @@ -9,6 +9,7 @@ /dts-v1/; #include "fsl-ls1028a.dtsi" +#include "fsl-ls1028a-rdb-u-boot.dtsi" This shouldn't be needed, as as the -u-boot.dtsi is automagically included (at least at board level dtbs). -michael
Re: [PATCH v3 04/16] arm: dts: ls1088a-rdb: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LS1088A-RDB to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 07/16] arm: dts: ls1028a-rdb: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During this board's sync with Linux device trees, it was observed that it doesn't use the same compatible string for the RTC node as in U-Boot. This change makes the RTC compatible strings match, for a smoother sync. Signed-off-by: Vladimir Oltean Reviewed-by: Michael Walle
Re: [PATCH v3 08/16] arm: dts: lx2160a-rdb: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LX2160A-RDB to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 09/16] rtc: pcf2127: remove U-Boot specific compatible string
Am 2022-01-03 13:47, schrieb Vladimir Oltean: Now that all in-tree boards have been converted to the compatible strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one. Cc: Simon Glass Signed-off-by: Vladimir Oltean Reviewed-by: Simon Glass Reviewed-by: Michael Walle
Re: [PATCH v3 15/16] arm: dts: ls1028a-rdb: sync device tree with Linux
Am 2022-01-03 13:47, schrieb Vladimir Oltean:
Allow device trees to be reused between Linux and U-Boot.
The source for these device trees is linux-next as of commit
bd8a9cd624c6 ("arm64: dts: ls1028a-rdb: update copyright"), which was
chosen because some changes needed to be done to the Linux DTs too,
before they could be shared:
https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395
There are two more commits on the RDB device tree which haven't been
picked up yet, because they have dependencies on the SoC device tree:
dd3d936a1b17 ("arm64: dts: ls1028a: add ftm_alarm1 node to be used as
wakeup source")
b2e2d3e02fb6 ("arm64: dts: ls1028a-rdb: enable pwm0")
These will be picked up on the next resync.
Signed-off-by: Vladimir Oltean
Reviewed-by: Priyanka Jain
Reviewed-by: Michael Walle
Re: [PATCH v3 01/16] i2c: muxes: pca954x: add PCA9847 variant
Am 2022-01-03 13:47, schrieb Vladimir Oltean: This seems to be very similar to the already existing PCA9547, save for the fact that it supports 0.8V and doesn't support 5V. In fact, it is so similar to the PCA9547 that the NXP LS1028A-RDB board has been driving this chip using a "nxp,pca9547" compatible string. Create a new compatible for the PCA9847 (which is the same as in Linux) and define the same operating parameters for it as for PCA9547. Cc: Heiko Schocher Signed-off-by: Vladimir Oltean Reviewed-by: Heiko Schocher Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 03/16] arm: dts: ls1088a-qds: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LS1088A-QDS to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 02/16] rtc: pcf2127: sync with Linux compatible strings
Am 2022-01-03 13:47, schrieb Vladimir Oltean: Allow this driver to be used by boards which inherit their device trees from Linux. Compatibility is temporarily retained with the old compatible string which is U-Boot specific, and will be removed after a few changes. Cc: Simon Glass Signed-off-by: Vladimir Oltean Reviewed-by: Simon Glass Reviewed-by: Michael Walle
Re: [PATCH v3 06/16] arm: dts: ls1028a-qds: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: The LS1028A-QDS board won't be synced with the Linux device trees right now, since those are currently still in progress (Ethernet is missing). However, while we're at converting the RDB, it can be observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the QDS to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 05/16] arm: dts: lx2160a-qds: use Linux compatible string for RTC
Am 2022-01-03 13:47, schrieb Vladimir Oltean: During the LS1028A-RDB sync with Linux device trees, it was observed that the same RTC is present on the two boards, and the wrong compatible string is used in both places. This change updates the RTC from the LX2160A-QDS to use the compatible string that was established in Linux. Signed-off-by: Vladimir Oltean Reviewed-by: Priyanka Jain Reviewed-by: Michael Walle
Re: [PATCH v3 14/16] arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi
Am 2022-01-03 13:47, schrieb Vladimir Oltean:
Reuse the scheme implemented by the Kontron SL28 boards in commit
d08011d7f9b4 ("arm: dts: ls1028a: disable the PCIe controller by
default") and move the 'status = "okay"' lines for the PCIe controllers
inside a separate U-Boot dtsi for the LS1028A-RDB board. This way, the
existing Linux device tree can simply be dropped in.
Signed-off-by: Vladimir Oltean
Reviewed-by: Michael Walle
Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c
Hi,
> Add compatible and data platform struct for sama7g5 SoC.
>
> Signed-off-by: Eugen Hristev
> ---
> drivers/i2c/at91_i2c.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
> index 6b4c0e4804..400a3786ca 100644
> --- a/drivers/i2c/at91_i2c.c
> +++ b/drivers/i2c/at91_i2c.c
> @@ -305,6 +305,11 @@ static const struct at91_i2c_pdata sama5d2_config = {
> .clk_offset = 3,
> };
>
> +static const struct at91_i2c_pdata sama7g5_config = {
> + .clk_max_div = 7,
> + .clk_offset = 3,
> +};
> +
> static const struct udevice_id at91_i2c_ids[] = {
> { .compatible = "atmel,at91rm9200-i2c", .data = (long)_config },
> { .compatible = "atmel,at91sam9260-i2c", .data = (long)_config },
> @@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
> { .compatible = "atmel,at91sam9x5-i2c", .data = (long)_config },
> { .compatible = "atmel,sama5d4-i2c", .data = (long)_config },
> { .compatible = "atmel,sama5d2-i2c", .data = (long)_config },
> +{ .compatible = "microchip,sama7g5-i2c", .data = (long)_config },
I see that this compatible string is is also used in the linux
device tree, but there is no dt binding for it in linux. Could you
add it, so the binding is approved by Rob?
-michael
Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c
Am 2022-01-05 11:37, schrieb eugen.hris...@microchip.com:
On 1/5/22 12:04 PM, Michael Walle wrote:
Hi,
Add compatible and data platform struct for sama7g5 SoC.
Signed-off-by: Eugen Hristev
---
drivers/i2c/at91_i2c.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index 6b4c0e4804..400a3786ca 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -305,6 +305,11 @@ static const struct at91_i2c_pdata
sama5d2_config = {
.clk_offset = 3,
};
+static const struct at91_i2c_pdata sama7g5_config = {
+ .clk_max_div = 7,
+ .clk_offset = 3,
+};
+
static const struct udevice_id at91_i2c_ids[] = {
{ .compatible = "atmel,at91rm9200-i2c", .data =
(long)_config },
{ .compatible = "atmel,at91sam9260-i2c", .data =
(long)_config },
@@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
{ .compatible = "atmel,at91sam9x5-i2c", .data =
(long)_config },
{ .compatible = "atmel,sama5d4-i2c", .data = (long)_config
},
{ .compatible = "atmel,sama5d2-i2c", .data = (long)_config
},
+{ .compatible = "microchip,sama7g5-i2c", .data =
(long)_config },
I see that this compatible string is is also used in the linux
device tree, but there is no dt binding for it in linux. Could you
add it, so the binding is approved by Rob?
I can, for sure, but the current binding format is txt. I am not sure
if
we have to convert to yaml first, in which case it would be a little
more difficult than just adding a new compatible string.
The current DT node in Linux is also compatible with sam9x60, and this
string is already in the Linux binding file.
I could add the sam9x60 compatible instead, and it will still work, as
9x60 type of i2c is the same as in sama7g5.
You think this option would be better for now ?
It's at least better than adding an undocumented string. But TBH,
this looks like "what can I do to avoid converting the dt binding
to yaml". Which eventually has to be done anyway, so now might be
a good opportunity for that :)
But looking at sama7g5_config above again, will that also be the
correct values for the generic sam9x60?
-michael
Re: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS): -Original Message- From: U-Boot On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) Cc: ZHIZHIKIN Andrey ; Clément Faure ; Gaurav Jain ; Pankaj Gupta ; Priyanka Jain ; u-boot@lists.denx.de; Varun Sethi ; Ye Li Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature Caution: EXT Email Hi Sahil, Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): >> DT nodes can be statically disabled if we know that they are held by >> HAB and are not released to NS World. >> >> OP-TEE does set the status itself via dt_enable_secure_status(), >> which should present the properly configured FDT when U-Boot takes over. > Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay > which gets merged with DTB provided for Linux bootup and then Linux > boots with merged DTB. > But u-boot uses the DTB embedded in its image. How can we modify that > DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb? "wrong" dtb means that uboot will not be aware of CAAM job ring which is taken by OP-TEE and uboot on LS platforms currently use JR0, which is not being used by any other entity in LS bootflow. I don't know I follow. u-boot and linux should have the same device tree; regardless if that device is used or not. So applying the overlay just for linux isn't enough here. We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE reserves One Job Ring for its use and that is communicated to Kernel using DTB overlay. what if the overlay doesn't match the dtb? I didn't get this point, can you please elaborate a little. You are merging a dtb fragment with an unknown dtb, right? Who says they match? you might have an old dtb where the supplied dtb fragment doesn't make any sense. I might be missing something here. Eg. where is the linux dtb supposed to come from? This patchset is really missing an example and a description how things should work. -michael
Re: [PATCH v2 00/16] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
Am 2021-12-23 13:44, schrieb Vladimir Oltean: On Thu, Dec 23, 2021 at 06:34:13AM +, Priyanka Jain wrote: >The Linux side of device tree patches were merged today, and I see you've >reviewed the U-Boot side of changes too. Could you please pick them up? Yes, I will pick the series as part of next pull-request for 2022.04 Thanks. Could you also delete the '#include "fsl-ls1028a-rdb-u-boot.dtsi"' line from patch 14/16 like Michael suggested, or should I resend for that? Patch 15/16 is also affected? I guess you took the linux dts and added that include line afterwards? that shouldn't be necessary. -michael
Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn
Hi,
> The imx8mm and imx8mn appear compatible with imx7d-usb
> flags in the OTG driver. If the dr_mode is defined as
> host or peripheral, the device appears to operate correctly,
> however the auto host/peripheral detection results in an error.
>
> The solution isn't just adding checks for imx8mm and imx8mn to
> the check for imx7, because the USB clock needs to be running
> to read from the USBNC_PHY_STATUS_OFFSET register or it will hang.
>
> The init_type in both priv and plat data are the same, so it doesn't
> make sense to configure the data in the plat data and copy the
> data to priv when priv can be configured directly. Instead, rename
> ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the
> probe functions after the clocks are enabled, but before the data
> is required.
>
> With that added, the additional checks for imx8mm and imx8mn will
> allow reading the register to automatically determine the state
> (host or device) of the OTG controller.
>
> Signed-off-by: Adam Ford
> ---
> V2: Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it
> from the probe after the clocks are enabled, but before
> the data is needed.
>
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 1bd6147c76..f2a34b7f06 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
..
> @@ -639,10 +639,8 @@ static int mx6_parse_dt_addrs(struct udevice *dev)
>
> static int ehci_usb_probe(struct udevice *dev)
> {
> - struct usb_plat *plat = dev_get_plat(dev);
> struct usb_ehci *ehci = dev_read_addr_ptr(dev);
> struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
> - enum usb_init_type type = plat->init_type;
> struct ehci_hccr *hccr;
> struct ehci_hcor *hcor;
> int ret;
> @@ -660,8 +658,6 @@ static int ehci_usb_probe(struct udevice *dev)
> return ret;
>
> priv->ehci = ehci;
> - priv->init_type = type;
I'm not sure this is correct. There is also this:
https://elixir.bootlin.com/u-boot/v2022.01-rc4/source/drivers/usb/host/usb-uclass.c#L407
Which won't work anymore. usb_setup_ehci_gadget() is called from
usb_gadget_register_driver() in ci_udc.c. The latter is the one used
on the imx, right? But I might be wrong. I'm still trying to figure
out how this all works together, because I also try to get OTG
running on the dwc3 driver. It looks like the ci_udc.c is special
here, and I wonder how a transition to UCLASS_USB_GADGET_GENERIC
might look like for this driver.
-michael
Re: [PATCH RFC] cmd: fix net list command
Am 2021-11-15 16:12, schrieb Tom Rini: On Mon, Nov 15, 2021 at 03:52:51PM +0100, Michael Walle wrote: Hi, Am 2021-11-15 15:31, schrieb Wolfgang Denk: > In message you wrote: > > > > And again you're masking the error and possible fixes by linux itself. > > Seems like this isn't an argument. > > Respecting the explicit will of the user (i. e using what he > configured in U-Boot and passed to the kernel) is not an error. it > is intended and documented behaviour. What is the will of the user in this case? It is the will of the developer to make the board more robust. That is, if there is for whatever reason no valid ethernet address found, then there will be one generated. That is the sole purpose of the config option in question (or maybe I used it completely wrong). So from a user perspective, this shouldn't even happen and I doubt he is even aware that there will be a random one. (I saw Tom's mail and I'm not talking about the USB adapters where this might be the normal case.) I might come from a different perspective, but users ususally don't look at the serial output. Instead they look at the kernel log. And there will be not the slightest error, because u-boot will happily fix the missing MAC address with a random one. So one thing I don't know is what's the situation on (I assume) the kontron boards? I see both NXP reference platforms for layerscape and imx8 enabling NET_RANDOM_ETHADDR but I don't know what the expectation is for on-device MAC addresses, and I recall other threads talking about how complex the layerscape physical layout can get. Thanks! Kontron boards are fine, well at least if I disable the random mac address config option, usually there is a serial console. board/buffalo/lsxl.c needs it definetly (and was actually the first user). -michael
Re: [PATCH RFC] cmd: fix net list command
Hi, Am 2021-11-15 16:15, schrieb Wolfgang Denk: | And if you don't want to use this feature just don't enable it via | CONFIG_NET_RANDOM_ETHADDR. This say all, no patches needed. Yes, I'm giving up. I'll just deactivate that option then and open code it in my board. -michael
Re: [PATCH RFC] cmd: fix net list command
Am 2021-11-15 14:57, schrieb Tom Rini: On Mon, Nov 15, 2021 at 01:24:34PM +0100, Michael Walle wrote: Am 2021-11-15 13:15, schrieb Marek Vasut: > On 11/15/21 1:11 PM, Michael Walle wrote: > > Don't get the MAC address by the environment, but by the platform data > > of the udevice. This will fix "net list" if the MAC address is > > randomly > > generated and won't change behavior when linux is booted. > > > > Signed-off-by: Michael Walle > > --- > > > > Hi, > > > > this is a proposal to fix the "net list" in a way that linux still > > can have > > its own fallback mechanism of MAC addresses even if the bootloader has > > CONFIG_NET_RANDOM_ETHADDR enabled. > > > > The intention is to replace [1], where if I understood correctly, the > > intention was to fix "net list". > > > > [1] https://lore.kernel.org/u-boot/3996ba2ee4e6ac136c0802dc0df4ef9b1750157c.1635506067.git.michal.si...@xilinx.com/ > > Does that mean U-Boot and Linux will possibly each have different MAC > address on the same device ? That is clearly wrong and not how it is > supposed to work, U-Boot passes its ethaddr/ethNaddr settings to Linux > so that they would have the same MAC address on the same device. Yes they have different ones, but having a random mac address is wrong in the first place. So IMHO it is more useful to dectect that in linux, (and there was a good point that usually a user will look at dmesg and not some u-boot output) than having two different random MAC addresses, one for u-boot and one for linux. Initially that random MAC address thing was supposed to get networking running in u-boot if there is no ethaddr at all, eg. for network console. Now we are passing this made up network address to linux, too. Why? Just because it is wrong to have two different mac addresses? Some drivers doesn't even probe without one. And we are just masking away this error. You get this "two different mac addresses" between reboots. Which is also wrong. This actually strenghten my opinion that this "feature" should be an u-boot only thing. Do you have some link explaining this use case more clearly, ie why U-Boot is using a random MAC being wrong? We have a number of long standing use cases today where U-Boot generates and uses the random MAC and passes it to Linux and Linux would generate another random MAC, so we avoid that mismatch by making sure Linux does get the random MAC we generate. The BeagleBoard xM is the first one that pops to mind for me, but I believe it's typical on some classes of USB ethernet adapters. Please see my previous response to Wolfgang. -michael
Re: [PATCH RFC] cmd: fix net list command
Hi, Am 2021-11-15 15:31, schrieb Wolfgang Denk: In message you wrote: And again you're masking the error and possible fixes by linux itself. Seems like this isn't an argument. Respecting the explicit will of the user (i. e using what he configured in U-Boot and passed to the kernel) is not an error. it is intended and documented behaviour. What is the will of the user in this case? It is the will of the developer to make the board more robust. That is, if there is for whatever reason no valid ethernet address found, then there will be one generated. That is the sole purpose of the config option in question (or maybe I used it completely wrong). So from a user perspective, this shouldn't even happen and I doubt he is even aware that there will be a random one. (I saw Tom's mail and I'm not talking about the USB adapters where this might be the normal case.) I might come from a different perspective, but users ususally don't look at the serial output. Instead they look at the kernel log. And there will be not the slightest error, because u-boot will happily fix the missing MAC address with a random one. Sorry, if the original intention was to make "net list" work correctly, then why is there now such a huge fuzz around that CONFIG_NET_RANDOM_ETHADDR config option and why can't we just fix the error with "net list" and leave the behavior like it was for years. Maybe you explain what exactly the ``error with "net list"'' is, Michal mentioned it here [1]. considering the fact that it is U-Boot which determins the "correct" MAC address and passes it to Linux. And if the user configures U-Boot such that a random MAC address is used, then this _is_ the correct MAC address, as normally (*) U-Boot is just a tool that does what the user requests. Only that the user doesn't do it but the board developer/OEM. I.e. there is no valid MAC address to pass to linux. It is really just for having netconsole running (or maybe you'll need networking for to rescue your failed EEPROM or whatever). I think, we have to distiguish between two use cases here: (1) make networking in u-boot work "somehow", to have a last resort recovery, esp. required for netconsole where the user cannot set the mac address by hand. (2) normal use case, where drivers simply doesn't have any other source for the mac address and need to fall back to a random one. I agree, for (2) the mac address should be passed to linux. But for (1) it shouldn't because it will just mask the error and any fall back mechanisms in linux. -michael [1] https://lore.kernel.org/u-boot/07b688d8-f05f-d11e-5e3e-e5454e1c9...@xilinx.com/
Re: [EXT] RE: [PATCH v5 11/16] crypto/fsl: Fix kick_trng
Hi Gaurav, Am 2021-11-23 11:44, schrieb Gaurav Jain: > fix hwrng performance issue in kernel. This patch is missing some context information, specifically which performance issue does exist in the Kernel (with some quantification), and how is it addressed here. This function introduced with this patch already exist in the Kernel [1], and the implementation does differ from Kernel one. Specifically, this patch lowers the number of test samples that are run to decide whether the entropy generated by TRNG is sufficiently random: it reduces the monobit count range, poker test limits, and number or runs for consecutive 0's and 1's. Considering the fact that after TRNG is initialized - JDKEK, TDKEK and TDSK are preloaded from the RNG and are locked until the next PoR, Kernel will not re- initialize the TRNG (in fact, there is a check that is done in the Kernel not to touch RNG if it is already initialized [2]), and this would leave the Crypto facilities running in the Kernel to use entropy model that is defined here. In this case, at least a justification of this change should be made clear - e.g. significant speed improvement over reduced entropy (with quantifiable numbers). In addition, with those new parameter set, would the RNG pass FIPS 140-2 test? TRNG is configured to pass FIPS certification, but will double check and confirm you. You are correct if RNG is instantiated in Uboot then kernel will not reinitialize. 77% performance drop was observed on IMX6/7/8 platforms (0.3 kB/s) compared to 1.3kB/s. With this change hwrng performance improved to 1.3 kB/s. Did you test on other platforms like layerscape, too? Can we be sure there will no impact with this change on other platforms which uses the CAAM TRNG? I have to agree with Andrey, there is little information *why* this is done in exactly this way. I'd love to see a proper commit description and comments here. I just see a bunch of magic numbers in the code. -michael
Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS): Could you please add some description what this is doing and for what this is intended? To have a "DTB overlay feature", it is enough to just enable CONFIG_OF_LIBFDT_OVERLAY. I will add some description, and yes for DTB overlay feature, it is enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step before booting the kernel that's why also have to enable CONFIG_OF_SYSTEM_SETUP. Ok. What will the overlay do? Could you give an example? Apparently you're adding an overlay passed by optee. Doesn't this have to be applied to u-boot's control dtb too? Yes, we will be applying the overlay passed by optee, yes it will be applied to dtb which will be passed to uboot for kernel booting. If I read this patch correctly, you're modifying the DT before you jump to linux. But I was asking whether you also have to modify the DT which is used by u-boot. Eg. if you disable some kind of crypto nodes (because optee will use them in secure world), this also have to communicated to u-boot, not only linux, no? But until you've explained what this is about, this is only guesswork. -michael
Re: [PATCH 10/10] board: sl28: disable random MAC address generation
Am 2021-11-16 22:14, schrieb Tom Rini: On Mon, Nov 15, 2021 at 11:45:51PM +0100, Michael Walle wrote: Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set enetaddr to a random value if not set and then pass the randomly generated MAC address to linux. First, for clarity I'm not nak'ing this. I kind of would like to see a slight reword as I think some things aren't 100% correct, even if the "save random MAC to ethaddr environment variable" change goes in. For example, it's quite long standing that (dev|pdata)->enetaddr populates "mac-address" and "local-mac-address" and it seems in some older cases we only set the "local-mac-address" property. fdt_fixup_memory() in common/fdt_support.c does a env_get(mac). I'm not even sure, if there is a connection between what is fixed up in the kernel DT and the corresponding device in u-boot if CONFIG_DM_SEQ_ALIAS is not set. This is bad for the following reasons: (1) it makes it impossible for linux to detect this error (2) linux won't trigger any fallback mechanism for the case where it didn't find any valid MAC address This feels in some ways to be a limitation of the binding: https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet-controller.yaml Agreed. But it doesn't render my argument invalid ;) And it reads like we really must be populating "mac-address" with that random one and while providing a blank "local-mac-address" would be a way to say we don't know the true device one, it seems that wouldn't be used / noticed? I guess it will just use the one populated in mac-address, i.e. the random one. Btw, the binding says "last used" what if u-boot never actually used that ethernet controller, should it then be empty or populated with the random mac address. (3) a saveenv will store this randomly generated MAC address in the environment Probably, the user will also be unaware that something is wrong. He will just get different MAC addresses on each reboot, asking himself why this is the case. As this board usually have a serial port, the user can just fix this by setting the MAC address manually in the environment. Also disable the netconsole just in case, because it cannot be guaranteed that it will work in any case. After all, this was just a convenience option, because the bootloader - right now - doesn't have the ability to read the MAC address, which is stored in the OTP. But it is far more important to have a clear view of whats wrong with a board and that means we can no longer use this Kconfig option. Signed-off-by: Michael Walle --- configs/kontron_sl28_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index af907175f1..7fb6bdbe82 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -59,8 +59,6 @@ CONFIG_OF_LIST="" CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_NETCONSOLE=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SCSI_AHCI=y CONFIG_SATA_CEVA=y Now, an alternate solution here would be to enable these two options still and write an ft_board_setup() with: ... if ethaddr is in the locally administered pool then fdt_delprop(... "mac-address"); fdt_delprop(... "local-mac-address"); Which would also trigger if a user sets a "locally administered" mac himself. Even if unlikely, I'm opposed to such magic and unexpected behavior. Sooner or later it will bite you. And that should cause the kernel to fall through the cases to find out where to get the real MAC from. I'm not super happy with this at first, but I also don't see anything clever in the binding we can do. If I'll need this one again, then I'll just add the random mac generation in board_eth_init(), I think. -michael
Re: [RFC 0/2] Do not stop with an error when mkimage fails
Am 2021-11-10 02:37, schrieb Tom Rini: On Wed, Nov 10, 2021 at 01:26:12AM +0100, Rasmus Villemoes wrote: On 10/11/2021 01.18, Rasmus Villemoes wrote: > On 09/11/2021 20.42, Tom Rini wrote: >> On Tue, Nov 09, 2021 at 08:21:07PM +0100, Heiko Thiery wrote: >>> Hi Wolfgang, >>> > >>> I know this is not a perfect solution but I don't know how to get my >>> board merged without doing this kind of workaround for the U-Boot CI. >> >> Unfortunately in these days of needing multiple inputs to create a >> functional image and also needing to have CI be able to be at all >> useful, what we do in many many many cases is yell loudly to the user >> that the resulting file here will NOT work and why. So yes, some "yell >> it won't work but not return non-zero exit status" is the norm. >> >> I would be very much open however to some way to handle this >> differently. Some environment variable our tools check for and then >> yell-but-succeed? Some other idea? I'm just thinking out loud here. > > Yes, I believe the build system must be taught some env var (or other > means) for opting in to this behavior. Oh, and it should of course only paper over missing binary blobs, not arbitrary errors from mkimage or other tools. The easiest way to do that is probably to create some dummy blob(s) [only when CREATE_BROKEN_IMAGES is set of course] before calling the tool that will consume the blobs. Some patches along those lines would be most welcome :) If I understand Simon correctly, then it is possible to fill in missing blobs later with binman (or an fit image in general?). Which is quite useful in a build system, because you don't have a chain of dependent packages, but you can assemble all the binaries in a final step. But this also means, that "missing binary blobs" are not an error but may even be expected. Unfortunately, this all falls apart if the binary is inside an image produced by mkimage (like the hdmi phy firmware in for the imx8). Though the finaly image is generated by binman, you cannot replace/insert the hdmi phy firmware later on [except you'd unpack the imx image, replace the firmware, pack it again and then replace it again in the outer image]. IMHO quite a drawback if we're saying binman isn't replacing mkimage. -michael
Re: [PATCH v5 28/28] arm: dts: sl28: sync dtbs
Am 2021-10-13 18:14, schrieb Michael Walle: Copy the board device tree files from linux v5.14. On top of the v5.14 dtbs the changes of these two patches are included here which are needed for u-boot: https://lore.kernel.org/linux-devicetree/20210831134013.1625527-7-mich...@walle.cc/ https://lore.kernel.org/linux-devicetree/20210831134013.1625527-8-mich...@walle.cc/ At the time of this writing the patches were accepted and will be included in 5.15. Signed-off-by: Michael Walle Reviewed-by: Vladimir Oltean Ping. I have some more patches which depends on this. TBH this is really frustrating if you have to wait serveral months until you can continue development. -michael
[PATCH 02/10] watchdog: add sl28cpld watchdog driver
The watchdog timer is part of the sl28cpld management controller. The watchdog timer usually supervises the bootloader boot-up and if it bites the failsafe bootloader will be activated. Apart from that it supports the usual board level reset and one SMARC speciality: driving the WDT_TIMEOUT# signal. Signed-off-by: Michael Walle --- MAINTAINERS | 1 + doc/board/kontron/sl28.rst | 53 +++- drivers/watchdog/Kconfig| 7 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/sl28cpld-wdt.c | 109 5 files changed, 154 insertions(+), 17 deletions(-) create mode 100644 drivers/watchdog/sl28cpld-wdt.c diff --git a/MAINTAINERS b/MAINTAINERS index e9d0bd0818..d7f09e1c81 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1104,6 +1104,7 @@ SL28CLPD M: Michael Walle S: Maintained F: drivers/misc/sl28cpld.c +F: drivers/watchdog/sl28cpld-wdt.c SPI M: Jagan Teki diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst index c7b18bed10..c2cdc5e424 100644 --- a/doc/board/kontron/sl28.rst +++ b/doc/board/kontron/sl28.rst @@ -35,23 +35,6 @@ The board is fully failsafe, you can't break anything. But because you've disabled the builtin watchdog you might have to manually enter failsafe mode by asserting the ``FORCE_RECOV#`` line during board reset. -Disable the builtin watchdog - - -- boot into the failsafe bootloader, either by asserting the - ``FORCE_RECOV#`` line or if you still have the original bootloader - installed you can use the command:: - - > wdt dev cpld_watchdog@4a; wdt expire 1 - -- in the failsafe bootloader use the "sl28 nvm" command to disable - the automatic start of the builtin watchdog:: - - > sl28 nvm 0008 - -- power-cycle the board - - Update image @@ -82,6 +65,42 @@ u-boot (yet). But you can use the i2c command to access it. > i2c md 4a 3.1 1 +Builtin watchdog + + +The builtin watchdog will supervise the bootloader startup. If anything +goes wrong it will reset the board and boot into the failsafe bootloader. + +Once the bootloader is started successfully, it will disable the watchdog +timer. + +wdt command flags +^ + +The `wdt start` as well as the `wdt expire` command take a flags argument. +The supported bitmask is as follows. + +| Bit | Description | +| --- | - | +| 0 | Enable failsafe mode | +| 1 | Lock the control register | +| 2 | Disable board reset | +| 3 | Enable WDT_TIME_OUT# line | + +For example, you can use `wdt expire 1` to issue a reset and boot into the +failsafe bootloader. + +Disable the builtin watchdog + + +If for some reason, this isn't a desired behavior, the watchdog can also +be configured to not be enabled on board reset. It's configuration is saved +in the non-volatile board configuration bits. To change these you can use +the `sl28 nvm` command. + +For more information on the non-volatile board configuration bits, see the +following section. + Non-volatile Board Configuration Bits - diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 1177f17fd8..a232b595ba 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -257,6 +257,13 @@ config WDT_SBSA In the single stage mode, when the timeout is reached, your system will be reset by WS1. The first signal (WS0) is ignored. +config WDT_SL28CPLD + bool "sl28cpld watchdog timer support" + depends on WDT && SL28CPLD + help + Enable support for the watchdog timer in the Kontron sl28cpld + management controller. + config WDT_SP805 bool "SP805 watchdog timer support" depends on WDT diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index fa7ce583ce..8c6e5326c0 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_WDT_OCTEONTX) += octeontx_wdt.o obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o +obj-$(CONFIG_WDT_SL28CPLD) += sl28cpld-wdt.o obj-$(CONFIG_WDT_SP805) += sp805_wdt.o obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o obj-$(CONFIG_WDT_SUNXI) += sunxi_wdt.o diff --git a/drivers/watchdog/sl28cpld-wdt.c b/drivers/watchdog/sl28cpld-wdt.c new file mode 100644 index 00..af5a6b1a28 --- /dev/null +++ b/drivers/watchdog/sl28cpld-wdt.c @@ -0,0 +1,109 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Watchdog driver for the sl28cpld + * + * Copyright (c) 2021 Michael Walle + */ + +#include +#include +#include +#include +#include + +#define SL28CPLD_WDT_CTRL 0x00 +#define WDT_CTRL_EN0 BIT(0) +#define WDT_CTRL_EN1 BIT(1) +#define WDT_C
[PATCH 00/10] board: sl28: add sl28cpld support and board cleanups
Add support for the sl28cpld management controller found on this board. This is especially useful, because of the integrated watchdog in this controller. It is used to supervise the bootup of the bootloader and will automatically switch to the failsafe bootloader if u-boot didn't start. Up until now, we had to disable this feature, leaving a gap in the failsafe boot concept of this board. Now, with this driver in place, this watchdog can be enabled at reset and u-boot will disable it late during its startup. Additionally, add support for the GPIOs which are connected to this controller. Besides this support, there are various cleanups, like DRAM output fix, printing the version of the management controller and disabling the random MAC address generation. Implementationwise, the MFD driver is implemented as UCLASS_NOP which provides basic access functions and will enumerate its child nodes. The device tree binding is the same as already acked by the linux kernel. Michael Walle (10): misc: add sl28cpld base driver watchdog: add sl28cpld watchdog driver gpio: add sl28cpld driver board: sl28: fix DRAM pretty print board: sl28: print CPLD version on bootup board: sl28: enable sl28cpld support board: sl28: enable SoC watchdog support board: sl28: disable recovery watchdog board: sl28: remove "Useful I2C tricks" section from docs board: sl28: disable random MAC address generation MAINTAINERS | 7 ++ board/kontron/sl28/sl28.c | 59 +++- configs/kontron_sl28_defconfig | 11 ++- doc/board/kontron/sl28.rst | 66 +++-- drivers/gpio/Kconfig| 6 ++ drivers/gpio/Makefile | 1 + drivers/gpio/sl28cpld-gpio.c| 165 drivers/misc/Kconfig| 8 ++ drivers/misc/Makefile | 1 + drivers/misc/sl28cpld.c | 105 drivers/watchdog/Kconfig| 7 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/sl28cpld-wdt.c | 109 + include/sl28cpld.h | 17 14 files changed, 528 insertions(+), 35 deletions(-) create mode 100644 drivers/gpio/sl28cpld-gpio.c create mode 100644 drivers/misc/sl28cpld.c create mode 100644 drivers/watchdog/sl28cpld-wdt.c create mode 100644 include/sl28cpld.h -- 2.30.2
[PATCH 07/10] board: sl28: enable SoC watchdog support
The SoC provides two additional watchdogs integrated in the SoC. Enable support for these. Signed-off-by: Michael Walle --- configs/kontron_sl28_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 48cf3cf5e6..af907175f1 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -109,6 +109,7 @@ CONFIG_USB_GADGET_DOWNLOAD=y # CONFIG_WATCHDOG_AUTOSTART is not set CONFIG_WDT=y CONFIG_WDT_SL28CPLD=y +CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_ASSUME_MASK=0x0 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_SET_TIME=y -- 2.30.2
[PATCH 10/10] board: sl28: disable random MAC address generation
Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set enetaddr to a random value if not set and then pass the randomly generated MAC address to linux. This is bad for the following reasons: (1) it makes it impossible for linux to detect this error (2) linux won't trigger any fallback mechanism for the case where it didn't find any valid MAC address (3) a saveenv will store this randomly generated MAC address in the environment Probably, the user will also be unaware that something is wrong. He will just get different MAC addresses on each reboot, asking himself why this is the case. As this board usually have a serial port, the user can just fix this by setting the MAC address manually in the environment. Also disable the netconsole just in case, because it cannot be guaranteed that it will work in any case. After all, this was just a convenience option, because the bootloader - right now - doesn't have the ability to read the MAC address, which is stored in the OTP. But it is far more important to have a clear view of whats wrong with a board and that means we can no longer use this Kconfig option. Signed-off-by: Michael Walle --- configs/kontron_sl28_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index af907175f1..7fb6bdbe82 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -59,8 +59,6 @@ CONFIG_OF_LIST="" CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_NETCONSOLE=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SCSI_AHCI=y CONFIG_SATA_CEVA=y -- 2.30.2
[PATCH 09/10] board: sl28: remove "Useful I2C tricks" section from docs
They are no longer needed, because we now have proper driver support for the sl28cpld management controller. Signed-off-by: Michael Walle --- doc/board/kontron/sl28.rst | 15 --- 1 file changed, 15 deletions(-) diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst index 04483e1e57..44435d90c6 100644 --- a/doc/board/kontron/sl28.rst +++ b/doc/board/kontron/sl28.rst @@ -50,21 +50,6 @@ Afterward you can copy this file to your ESP into the /EFI/UpdateCapsule/ folder. On the next EFI boot this will automatically update your bootloader. -Useful I2C tricks -- - -The board has a board management controller which is not supported in -u-boot (yet). But you can use the i2c command to access it. - -- reset into failsafe bootloader:: - - > i2c mw 4a 5.1 0; i2c mw 4a 6.1 6b; i2c mw 4a 4.1 42 - -- read board management controller version:: - - > i2c md 4a 3.1 1 - - Builtin watchdog -- 2.30.2
[PATCH 03/10] gpio: add sl28cpld driver
The gpio block is part of the sl28cpld sl28cpld management controller.
There are three different flavors: the usual input and output where the
direction is configurable, but also input only and output only variants.
Signed-off-by: Michael Walle
---
MAINTAINERS | 1 +
drivers/gpio/Kconfig | 6 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/sl28cpld-gpio.c | 165 +++
4 files changed, 173 insertions(+)
create mode 100644 drivers/gpio/sl28cpld-gpio.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d7f09e1c81..f2dd8d067a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1103,6 +1103,7 @@ F:arch/sh/
SL28CLPD
M: Michael Walle
S: Maintained
+F: drivers/gpio/sl28cpld-gpio.c
F: drivers/misc/sl28cpld.c
F: drivers/watchdog/sl28cpld-wdt.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 40abc33772..bb89babc0b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -523,4 +523,10 @@ config NOMADIK_GPIO
into a number of banks each with 32 GPIOs. The GPIOs for a device are
defined in the device tree with one node for each bank.
+config SL28CPLD_GPIO
+ bool "Kontron sl28cpld GPIO driver"
+ depends on DM_GPIO && SL28CPLD
+ help
+ Support GPIO access on Kontron sl28cpld board management controllers.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 3c851b38c7..e9dab62745 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_NX_GPIO) += nx_gpio.o
obj-$(CONFIG_SIFIVE_GPIO) += sifive-gpio.o
obj-$(CONFIG_NOMADIK_GPIO) += nmk_gpio.o
obj-$(CONFIG_MAX7320_GPIO) += max7320_gpio.o
+obj-$(CONFIG_SL28CPLD_GPIO)+= sl28cpld-gpio.o
diff --git a/drivers/gpio/sl28cpld-gpio.c b/drivers/gpio/sl28cpld-gpio.c
new file mode 100644
index 00..700fc3df29
--- /dev/null
+++ b/drivers/gpio/sl28cpld-gpio.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * GPIO driver for the sl28cpld
+ *
+ * Copyright (c) 2021 Michael Walle
+ */
+
+#include
+#include
+#include
+#include
+
+/* GPIO flavor */
+#define SL28CPLD_GPIO_DIR 0x00
+#define SL28CPLD_GPIO_OUT 0x01
+#define SL28CPLD_GPIO_IN 0x02
+
+/* input-only flavor */
+#define SL28CPLD_GPI_IN0x00
+
+/* output-only flavor */
+#define SL28CPLD_GPO_OUT 0x00
+
+enum {
+ SL28CPLD_GPIO,
+ SL28CPLD_GPI,
+ SL28CPLD_GPO,
+};
+
+static int sl28cpld_gpio_get_value(struct udevice *dev, unsigned int gpio)
+{
+ ulong type = dev_get_driver_data(dev);
+ int val, reg;
+
+ switch (type) {
+ case SL28CPLD_GPIO:
+ reg = SL28CPLD_GPIO_IN;
+ break;
+ case SL28CPLD_GPI:
+ reg = SL28CPLD_GPI_IN;
+ break;
+ case SL28CPLD_GPO:
+ /* we are output only, thus just return the output value */
+ reg = SL28CPLD_GPO_OUT;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ val = sl28cpld_read(dev, reg);
+
+ return val < 0 ? val : !!(val & BIT(gpio));
+}
+
+static int sl28cpld_gpio_set_value(struct udevice *dev, unsigned int gpio,
+ int value)
+{
+ ulong type = dev_get_driver_data(dev);
+ uint reg;
+
+ switch (type) {
+ case SL28CPLD_GPIO:
+ reg = SL28CPLD_GPIO_OUT;
+ break;
+ case SL28CPLD_GPO:
+ reg = SL28CPLD_GPO_OUT;
+ break;
+ case SL28CPLD_GPI:
+ default:
+ return -EINVAL;
+ }
+
+ if (value)
+ return sl28cpld_update(dev, reg, 0, BIT(gpio));
+ else
+ return sl28cpld_update(dev, reg, BIT(gpio), 0);
+}
+
+static int sl28cpld_gpio_direction_input(struct udevice *dev, unsigned int
gpio)
+{
+ ulong type = dev_get_driver_data(dev);
+
+ switch (type) {
+ case SL28CPLD_GPI:
+ return 0;
+ case SL28CPLD_GPIO:
+ return sl28cpld_update(dev, SL28CPLD_GPIO_DIR, BIT(gpio), 0);
+ case SL28CPLD_GPO:
+ default:
+ return -EINVAL;
+ }
+}
+
+static int sl28cpld_gpio_direction_output(struct udevice *dev,
+ unsigned int gpio, int value)
+{
+ ulong type = dev_get_driver_data(dev);
+ int ret;
+
+ /* set_value() will report an error if we are input-only */
+ ret = sl28cpld_gpio_set_value(dev, gpio, value);
+ if (ret)
+ return ret;
+
+ if (type == SL28CPLD_GPIO)
+ return sl28cpld_update(dev, SL28CPLD_GPIO_DIR, 0, BIT(gpio));
+
+ return 0;
+}
+
+static int sl28cpld_gpio_get_function(struct udevice *dev, unsigned int gpio)
+{
+ ulong type = dev_get_driver_data(dev);
+ int val;
+
+ switch (type) {
+ case SL28CPLD_GPIO:
+
[PATCH 05/10] board: sl28: print CPLD version on bootup
Most of the time it is very useful to have the version of the board
management controller. Now that we have a driver, print it during
startup.
Signed-off-by: Michael Walle
---
board/kontron/sl28/sl28.c | 28
include/sl28cpld.h| 2 ++
2 files changed, 30 insertions(+)
diff --git a/board/kontron/sl28/sl28.c b/board/kontron/sl28/sl28.c
index 4701eaad8d..e5c9f90c7a 100644
--- a/board/kontron/sl28/sl28.c
+++ b/board/kontron/sl28/sl28.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
#include
+#include
#include
#include
#include
@@ -15,6 +16,7 @@
#include
#include
+#include
#include
#include
@@ -39,9 +41,35 @@ int board_eth_init(struct bd_info *bis)
return pci_eth_init(bis);
}
+static int __sl28cpld_read(uint reg)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_NOP,
+ DM_DRIVER_GET(sl28cpld), );
+ if (ret)
+ return ret;
+
+ return sl28cpld_read(dev, reg);
+}
+
+static void print_cpld_version(void)
+{
+ int version = __sl28cpld_read(SL28CPLD_VERSION);
+
+ if (version < 0)
+ printf("CPLD: error reading version (%d)\n", version);
+ else
+ printf("CPLD: v%d\n", version);
+}
+
int checkboard(void)
{
printf("EL:%d\n", current_el());
+ if (CONFIG_IS_ENABLED(SL28CPLD))
+ print_cpld_version();
+
return 0;
}
diff --git a/include/sl28cpld.h b/include/sl28cpld.h
index d116607cfb..9a7c6de31f 100644
--- a/include/sl28cpld.h
+++ b/include/sl28cpld.h
@@ -6,6 +6,8 @@
#ifndef __SL28CPLD_H
#define __SL28CPLD_H
+#define SL28CPLD_VERSION 0x03
+
int sl28cpld_read(struct udevice *dev, uint offset);
int sl28cpld_write(struct udevice *dev, uint offset, uint8_t value);
int sl28cpld_update(struct udevice *dev, uint offset, uint8_t clear,
--
2.30.2
[PATCH 01/10] misc: add sl28cpld base driver
Add a multi-function device driver which will probe its children and
provides methods to access the device.
Signed-off-by: Michael Walle
---
MAINTAINERS | 5 ++
drivers/misc/Kconfig| 8 +++
drivers/misc/Makefile | 1 +
drivers/misc/sl28cpld.c | 105
include/sl28cpld.h | 14 ++
5 files changed, 133 insertions(+)
create mode 100644 drivers/misc/sl28cpld.c
create mode 100644 include/sl28cpld.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6db5354322..e9d0bd0818 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1100,6 +1100,11 @@ S: Maintained
T: git https://source.denx.de/u-boot/custodians/u-boot-sh.git
F: arch/sh/
+SL28CLPD
+M: Michael Walle
+S: Maintained
+F: drivers/misc/sl28cpld.c
+
SPI
M: Jagan Teki
S: Maintained
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 3bae072005..b2cc4fc920 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -500,4 +500,12 @@ config ESM_PMIC
Support ESM (Error Signal Monitor) on PMIC devices. ESM is used
typically to reboot the board in error condition.
+config SL28CPLD
+ bool "Enable Kontron sl28cpld multi-function driver"
+ depends on DM_I2C
+ help
+ Support for the Kontron sl28cpld management controller. This is
+ the base driver which provides common access methods for the
+ sub-drivers.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f9826d2462..cfb4cbff79 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -82,3 +82,4 @@ obj-$(CONFIG_MICROCHIP_FLEXCOM) += microchip_flexcom.o
obj-$(CONFIG_K3_AVS0) += k3_avs.o
obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
+obj-$(CONFIG_SL28CPLD) += sl28cpld.o
diff --git a/drivers/misc/sl28cpld.c b/drivers/misc/sl28cpld.c
new file mode 100644
index 00..01ef1c6178
--- /dev/null
+++ b/drivers/misc/sl28cpld.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 Michael Walle
+ */
+
+#include
+#include
+#include
+
+struct sl28cpld_child_plat {
+ uint offset;
+};
+
+/*
+ * The access methods works either with the first argument being a child
+ * device or with the MFD device itself.
+ */
+static int sl28cpld_read_child(struct udevice *dev, uint offset)
+{
+ struct sl28cpld_child_plat *plat = dev_get_parent_plat(dev);
+ struct udevice *mfd = dev_get_parent(dev);
+
+ return dm_i2c_reg_read(mfd, offset + plat->offset);
+}
+
+int sl28cpld_read(struct udevice *dev, uint offset)
+{
+ if (dev->driver == DM_DRIVER_GET(sl28cpld))
+ return dm_i2c_reg_read(dev, offset);
+ else
+ return sl28cpld_read_child(dev, offset);
+}
+
+static int sl28cpld_write_child(struct udevice *dev, uint offset,
+ uint8_t value)
+{
+ struct sl28cpld_child_plat *plat = dev_get_parent_plat(dev);
+ struct udevice *mfd = dev_get_parent(dev);
+
+ return dm_i2c_reg_write(mfd, offset + plat->offset, value);
+}
+
+int sl28cpld_write(struct udevice *dev, uint offset, uint8_t value)
+{
+ if (dev->driver == DM_DRIVER_GET(sl28cpld))
+ return dm_i2c_reg_write(dev, offset, value);
+ else
+ return sl28cpld_write_child(dev, offset, value);
+}
+
+int sl28cpld_update(struct udevice *dev, uint offset, uint8_t clear,
+ uint8_t set)
+{
+ int val;
+
+ val = sl28cpld_read(dev, offset);
+ if (val < 0)
+ return val;
+
+ val &= ~clear;
+ val |= set;
+
+ return sl28cpld_write(dev, offset, val);
+}
+
+static int sl28cpld_probe(struct udevice *dev)
+{
+ i2c_set_chip_flags(dev, DM_I2C_CHIP_RD_ADDRESS |
+ DM_I2C_CHIP_WR_ADDRESS);
+
+ return 0;
+}
+
+static int sl28cpld_child_post_bind(struct udevice *dev)
+{
+ struct sl28cpld_child_plat *plat = dev_get_parent_plat(dev);
+ int offset;
+
+ if (!dev_has_ofnode(dev))
+ return 0;
+
+ offset = dev_read_u32_default(dev, "reg", -1);
+ if (offset == -1)
+ return -EINVAL;
+
+ plat->offset = offset;
+
+ return 0;
+}
+
+static const struct udevice_id sl28cpld_ids[] = {
+ { .compatible = "kontron,sl28cpld" },
+ {}
+};
+
+U_BOOT_DRIVER(sl28cpld) = {
+ .name = "sl28cpld",
+ .id = UCLASS_NOP,
+ .of_match = sl28cpld_ids,
+ .probe = sl28cpld_probe,
+ .bind = dm_scan_fdt_dev,
+ .flags = DM_FLAG_PRE_RELOC,
+ .per_child_plat_auto = sizeof(struct sl28cpld_child_plat),
+ .child_post_bind = sl28cpld_child_post_bind,
+};
diff --git a/include/sl28cpld.h b/include/sl28cpld.h
new file mode 100644
index 00..d116607cfb
--- /dev/null
+++ b/include/sl28cpld.h
@@ -0,0 +1,14
[PATCH 04/10] board: sl28: fix DRAM pretty print
The current console output is:
DRAM: 4 GiB
DDR4 GiB (DDR3, 32-bit, CL=11, ECC on)
The size is printed twice and we can save one line of console output if
we join both lines. The new output is as follows:
DRAM: 4 GiB (DDR3, 32-bit, CL=11, ECC on)
Signed-off-by: Michael Walle
---
board/kontron/sl28/sl28.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/board/kontron/sl28/sl28.c b/board/kontron/sl28/sl28.c
index c8ed7ac81a..4701eaad8d 100644
--- a/board/kontron/sl28/sl28.c
+++ b/board/kontron/sl28/sl28.c
@@ -47,8 +47,6 @@ int checkboard(void)
void detail_board_ddr_info(void)
{
- puts("\nDDR");
- print_size(gd->bd->bi_dram[0].size + gd->bd->bi_dram[1].size, "");
print_ddr_info(0);
}
--
2.30.2
[PATCH 08/10] board: sl28: disable recovery watchdog
This board has an internal watchdog which supervises the board startup.
Although, the initial state of the watchdog is configurable, it is
enabled by default. In board_late_init(), which means almost everything
worked as expected, disable the watchdog.
Signed-off-by: Michael Walle
---
board/kontron/sl28/sl28.c | 29 +
doc/board/kontron/sl28.rst | 12 ++--
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/board/kontron/sl28/sl28.c b/board/kontron/sl28/sl28.c
index e5c9f90c7a..9572502499 100644
--- a/board/kontron/sl28/sl28.c
+++ b/board/kontron/sl28/sl28.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -73,6 +74,34 @@ int checkboard(void)
return 0;
}
+static void stop_recovery_watchdog(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_WDT,
+ DM_DRIVER_GET(sl28cpld_wdt), );
+ if (!ret)
+ wdt_stop(dev);
+}
+
+int fsl_board_late_init(void)
+{
+ /*
+* Usually, the after a board reset, the watchdog is enabled by
+* default. This is to supervise the bootloader boot-up. Therefore,
+* to prevent a watchdog reset if we don't actively kick it, we have
+* to disable it.
+*
+* If the watchdog isn't enabled at reset (which is a configuration
+* option) disabling it doesn't hurt either.
+*/
+ if (!CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART))
+ stop_recovery_watchdog();
+
+ return 0;
+}
+
void detail_board_ddr_info(void)
{
print_ddr_info(0);
diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst
index c2cdc5e424..04483e1e57 100644
--- a/doc/board/kontron/sl28.rst
+++ b/doc/board/kontron/sl28.rst
@@ -23,17 +23,17 @@ Copy u-boot.rom to a TFTP server.
Install the bootloader on the board
^^^
-Please note, this bootloader doesn't support the builtin watchdog (yet),
-therefore you have to disable it, see below. Otherwise you'll end up in
-the failsafe bootloader on every reset::
+To install the bootloader binary use the following command::
> tftp path/to/u-boot.rom
> sf probe 0
> sf update $fileaddr 0x21 $filesize
-The board is fully failsafe, you can't break anything. But because you've
-disabled the builtin watchdog you might have to manually enter failsafe
-mode by asserting the ``FORCE_RECOV#`` line during board reset.
+The board is fully failsafe, you can't break anything. If builtin watchdog
+is enabled, you'll automatically end up in the failsafe bootloader if
+something goes wrong. If the watchdog is disabled, you have to manually
+enter failsafe mode by asserting the ``FORCE_RECOV#`` line during board
+reset.
Update image
--
2.30.2
[PATCH 06/10] board: sl28: enable sl28cpld support
Enable the GPIO and watchdog driver. Don't start the watchdog automatically, though. Signed-off-by: Michael Walle --- configs/kontron_sl28_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 31a1083b0a..48cf3cf5e6 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -41,12 +41,14 @@ CONFIG_CMD_GREPENV=y CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_DFU=y CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_WDT=y CONFIG_CMD_CACHE=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_RNG=y @@ -68,8 +70,10 @@ CONFIG_DDR_ECC=y CONFIG_ECC_INIT_VIA_DDRCONTROLLER=y CONFIG_DFU_MMC=y CONFIG_DFU_SF=y +CONFIG_SL28CPLD_GPIO=y CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_I2C_MUX=y +CONFIG_SL28CPLD=y CONFIG_MMC_HS400_SUPPORT=y CONFIG_FSL_ESDHC=y CONFIG_FSL_ESDHC_SUPPORT_ADMA2=y @@ -101,6 +105,10 @@ CONFIG_USB_DWC3=y CONFIG_USB_DWC3_LAYERSCAPE=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DOWNLOAD=y +# CONFIG_WATCHDOG is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_SL28CPLD=y CONFIG_OF_LIBFDT_ASSUME_MASK=0x0 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_SET_TIME=y -- 2.30.2
Re: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation
Am 2021-11-16 12:57, schrieb Gaurav Jain: >> > +int hwrng_generate(u8 *dst, u32 len) >> >> likewise. >> But more important what is the difference to drivers/crypto/fsl/rng.c? >> Why >> do you need a new function here? This one. Why can't you reuse the code which is already there? I might have missed to update this. dm_rng_read() can be used. Will remove hwrng_generate(). Nice, thanks. Slightly lesser code :) -michael
Re: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation
Hi,
Am 2021-11-16 12:09, schrieb Gaurav Jain:
> --- a/drivers/crypto/fsl/fsl_blob.c
> +++ b/drivers/crypto/fsl/fsl_blob.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2021 NXP
> *
> */
>
> @@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst,
u32 len)
> return ret;
> }
>
> +int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)
where is this function actually used? looks like dead code to me.
I was thinking to add the command for this function later.
But will remove this patch from this series and send this later with
derive blob kek cmd implementation.
ok, but you've missed the question below.
> +{
> + int ret, size;
> + u32 *desc;
> +
> + if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
> + !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
> + puts("Error: derive_bkek: Address arguments are not
aligned!\n");
> + return -EINVAL;
> + }
> +
> + printf("\nBlob key encryption key(bkek)\n");
> + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> + if (!desc) {
> + printf("Not enough memory for descriptor allocation\n");
> + return -ENOMEM;
> + }
> +
> + size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)key_mod, (unsigned
> + long)key_mod + size);
> +
> + /* construct blob key encryption key(bkek) derive descriptor */
> + inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod,
> + key_sz);
> +
> + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE,
ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> + size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> +
> + /* run descriptor */
> + ret = run_descriptor_jr(desc);
> + if (ret < 0) {
> + printf("Error: %s failed 0x%x\n", __func__, ret);
> + } else {
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> + puts("derive bkek successful.\n");
> + }
> +
> + free(desc);
> + return ret;
> +}
> +
> +int hwrng_generate(u8 *dst, u32 len)
likewise.
But more important what is the difference to drivers/crypto/fsl/rng.c?
Why
do you need a new function here?
This one. Why can't you reuse the code which is already there?
-michael
Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation
Hi,
> --- a/drivers/crypto/fsl/fsl_blob.c
> +++ b/drivers/crypto/fsl/fsl_blob.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2021 NXP
> *
> */
>
> @@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
> return ret;
> }
>
> +int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)
where is this function actually used? looks like dead code to me.
> +{
> + int ret, size;
> + u32 *desc;
> +
> + if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
> + !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
> + puts("Error: derive_bkek: Address arguments are not
> aligned!\n");
> + return -EINVAL;
> + }
> +
> + printf("\nBlob key encryption key(bkek)\n");
> + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> + if (!desc) {
> + printf("Not enough memory for descriptor allocation\n");
> + return -ENOMEM;
> + }
> +
> + size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)key_mod, (unsigned long)key_mod +
> size);
> +
> + /* construct blob key encryption key(bkek) derive descriptor */
> + inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod, key_sz);
> +
> + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> + size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> +
> + /* run descriptor */
> + ret = run_descriptor_jr(desc);
> + if (ret < 0) {
> + printf("Error: %s failed 0x%x\n", __func__, ret);
> + } else {
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> + puts("derive bkek successful.\n");
> + }
> +
> + free(desc);
> + return ret;
> +}
> +
> +int hwrng_generate(u8 *dst, u32 len)
likewise.
But more important what is the difference to drivers/crypto/fsl/rng.c? Why
do you need a new function here?
> +{
> + int ret, size;
> + u32 *desc;
> +
> + if (!IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
> + puts("Error: caam_hwrng_test: Address arguments are not
> aligned!\n");
> + return -EINVAL;
> + }
> +
> + printf("\nRNG generate\n");
> + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> + if (!desc) {
> + printf("Not enough memory for descriptor allocation\n");
> + return -ENOMEM;
> + }
> +
> + inline_cnstr_jobdesc_rng(desc, dst, len);
> +
> + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> + size = ALIGN(len, ARCH_DMA_MINALIGN);
> + invalidate_dcache_range((unsigned long)dst, (unsigned long)dst + size);
> +
> + ret = run_descriptor_jr(desc);
> + if (ret < 0) {
> + printf("Error: RNG generate failed 0x%x\n", ret);
> + } else {
> + invalidate_dcache_range((unsigned long)dst,
> + (unsigned long)dst + size);
> + puts("RNG generation successful.\n");
> + }
> +
> + free(desc);
> + return ret;
> +}
> +
> #ifdef CONFIG_CMD_DEKBLOB
> int blob_dek(const u8 *src, u8 *dst, u8 len)
> {
-michael
Re: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model
> diff --git a/cmd/Kconfig b/cmd/Kconfig > index 5b30b13e43..2b24672505 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -2009,6 +2009,7 @@ config CMD_AES > > config CMD_BLOB > bool "Enable the 'blob' command" > + select FSL_BLOB this looks wrong, because CMD_BLOB sounds like a generic command but it will automatically select FSL_BLOB which in turn sounds freescale specific. Looking at the help text, this command is (at least at the moment) freescale specific, but the code seems to be generic and the blob_encap() and blob_decap() are weak functions, thus they could be implemented in a different way and not just by fsl_blob.c. I don't think this should automatically select FSL_BLOB. Also, shouldn't this be an uclass with encap and decap ops? > depends on !MX6ULL && !MX6SLL && !MX6SL > select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M > help > diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig > index 94ff540111..ab59d516f8 100644 > --- a/drivers/crypto/fsl/Kconfig > +++ b/drivers/crypto/fsl/Kconfig > @@ -66,4 +66,11 @@ config FSL_CAAM_RNG > using the prediction resistance flag which means the DRGB is > reseeded from the TRNG every time random data is generated. > > +config FSL_BLOB > +bool "Enable Blob Encap/Decap, Blob KEK support" wrong indendation? > + help > + Enable support for the hardware based crytographic blob encap/decap > + module of the CAAM. blobs can be safely placed into non-volatile > + storage. blobs can only be decapsulated by the SoC that created it. > + Enable support for blob key encryption key generation. > endif
Re: [PATCH v5 13/16] Layerscape: Enable Job ring driver model in U-Boot.
> LS(1021/1012/1028/1043/1046/1088/2088), LX2160, LX2162
> platforms are enabled with JR driver model.
>
> removed sec_init() call from board files.
> removed CONFIG_FSL_CAAM from defconfig files.
> sec is initialized based on job ring information processed
> from device tree.
>
> Signed-off-by: Gaurav Jain
> Reviewed-by: Priyanka Jain
> ---
> arch/arm/cpu/armv7/ls102xa/Kconfig| 4 +++
> arch/arm/cpu/armv7/ls102xa/cpu.c | 16 +++
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 27 +++
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 10 ++-
> board/freescale/ls1012afrdm/ls1012afrdm.c | 7 +
> board/freescale/ls1012aqds/ls1012aqds.c | 6 +
> board/freescale/ls1012ardb/ls1012ardb.c | 6 +
> board/freescale/ls1021aiot/ls1021aiot.c | 6 ++---
> board/freescale/ls1021aqds/ls1021aqds.c | 6 +
> board/freescale/ls1021atsn/ls1021atsn.c | 7 ++---
> board/freescale/ls1021atwr/ls1021atwr.c | 8 ++
> board/freescale/ls1028a/ls1028a.c | 6 +
> board/freescale/ls1043ardb/ls1043ardb.c | 6 +
> board/freescale/ls1046afrwy/ls1046afrwy.c | 7 +
> board/freescale/ls1046aqds/ls1046aqds.c | 7 +
> board/freescale/ls1046ardb/ls1046ardb.c | 6 +
> board/freescale/ls1088a/ls1088a.c | 6 +
> board/freescale/ls2080aqds/ls2080aqds.c | 6 +
> board/freescale/ls2080ardb/ls2080ardb.c | 9 +--
> board/freescale/lx2160a/lx2160a.c | 5
> configs/ls1021aiot_qspi_defconfig | 1 -
> configs/ls1021aqds_nor_defconfig | 1 -
> configs/ls1021aqds_qspi_defconfig | 1 -
> configs/ls1021atsn_qspi_defconfig | 1 -
> configs/ls1021atwr_nor_defconfig | 1 -
> ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 +
> configs/ls1028ardb_tfa_defconfig | 1 -
> configs/ls1043ardb_tfa_defconfig | 1 -
> configs/ls1046afrwy_tfa_defconfig | 1 -
> configs/ls1046aqds_tfa_defconfig | 1 -
> configs/ls1046ardb_tfa_defconfig | 1 -
> configs/ls2088aqds_tfa_defconfig | 1 -
> configs/ls2088ardb_tfa_defconfig | 1 -
> configs/lx2160aqds_tfa_defconfig | 1 -
> configs/lx2160ardb_tfa_defconfig | 1 -
> configs/lx2162aqds_tfa_defconfig | 1 -
> 36 files changed, 75 insertions(+), 102 deletions(-)
board/kontron/sl28/sl28.c fixes are missing here. With this patch
applied I'll get the following error during boot:
U-Boot 2022.01-rc2-00026-gf82ded5126-dirty (Nov 16 2021 - 11:16:40 +0100)
SoC: LS1028A Rev1.0 (0x870b0110)
Clock Configuration:
CPU0(A72):1300 MHz CPU1(A72):1300 MHz
Bus: 400 MHz DDR: 1600 MT/s
Reset Configuration Word (RCW):
: 34004010 0030
0010: 008f 0030c000
0020: 0620 2580 00019016
0030: 0048
0040:
0050:
0060: 0304 000e7000
0070: bb58 0002
Model: Kontron SMARC-sAL28 (Dual PHY)
EL:3
CPLD: v64
DRAM: 4 GiB (DDR3, 32-bit, CL=11, ECC on)
caam_jr: caam not found
^^ this error.
please add the following hunk to this patch:
diff --git a/board/kontron/sl28/sl28.c b/board/kontron/sl28/sl28.c
index 9572502499..555e831f2a 100644
--- a/board/kontron/sl28/sl28.c
+++ b/board/kontron/sl28/sl28.c
@@ -31,9 +31,6 @@ int board_early_init_f(void)
int board_init(void)
{
- if (CONFIG_IS_ENABLED(FSL_CAAM))
- sec_init();
-
return 0;
}
> config ARCH_LS1028A
> @@ -53,6 +57,9 @@ config ARCH_LS1028A
> select SYS_FSL_ERRATUM_A011334
> select SYS_FSL_ESDHC_UNRELIABLE_PULSE_DETECTION_WORKAROUND
> select RESV_RAM if GIC_V3_ITS
> + select FSL_CAAM
> + select FSL_BLOB
> + select MISC
There are boards like the sl28 which also have ARCH_LS1028A set and
doesn't depend on neither FSL_CAAM nor FSL_BLOB. Please don't set
this per architecture. Both should be set by the individual boards
instead as they are optional and having this here will just increase
binary size.
Of course this is like to be true for all ARCH_LSxxx Kconfig options.
> imply PANIC_HANG
-michael
[PATCH 4/5] armv8: psci: add ARMV8_PSCI_RELOCATE Kconfig option
There is an user-selectable SYS_HAS_ARMV8_SECURE_BASE, which has the same meaning but is just for the ls1043ardb board. As no in-tree config uses this, drop it and replace it with something more sophiticated: ARMV8_PSCI_RELOCATE. This option will then enable the ARMV8_SECURE_BASE option which is used as the base to relocate the PSCI code (or any code in the secure region, but that is only PSCI). A SoC (or board) can now opt-in into having such a secure region by enabling SYS_HAS_ARMV8_SECURE_BASE. Enable it for the LS1043A SoC, where it was possible to relocate the PSCI code before as well as on the LS1028A SoC where there will be PSCI support soon. Additionally, make ARMV8_PSCI and SEC_FIRMWARE_ARMV8_PSCI exclusive. Signed-off-by: Michael Walle --- arch/arm/cpu/armv8/Kconfig| 30 ++- arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 2 ++ board/freescale/ls1043ardb/Kconfig| 8 -- 3 files changed, 21 insertions(+), 19 deletions(-) diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index 0a3fdfa471..9289526230 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -84,6 +84,7 @@ config SPL_RECOVER_DATA_SECTION config SEC_FIRMWARE_ARMV8_PSCI bool "PSCI implementation in secure monitor firmware" depends on ARMV8_SEC_FIRMWARE_SUPPORT || SPL_ARMV8_SEC_FIRMWARE_SUPPORT + depends on ARMV8_PSCI=n help This config enables the ARMv8 PSCI implementation in secure monitor firmware. This is a private PSCI implementation and different from @@ -125,6 +126,9 @@ config PSCI_RESET Select Y here to make use of PSCI calls for system reset +config SYS_HAS_ARMV8_SECURE_BASE + bool + config ARMV8_PSCI bool "Enable PSCI support" if EXPERT help @@ -152,23 +156,27 @@ config ARMV8_PSCI_CPUS_PER_CLUSTER A value 0 or no definition of it works for single cluster system. System with multi-cluster should difine their own exact value. -config ARMV8_EA_EL3_FIRST - bool "External aborts and SError interrupt exception are taken in EL3" +config ARMV8_PSCI_RELOCATE + bool "Relocate PSCI code" + depends on ARMV8_PSCI + depends on SYS_HAS_ARMV8_SECURE_BASE help - Exception handling at all exception levels for External Abort and - SError interrupt exception are taken in EL3. - -if SYS_HAS_ARMV8_SECURE_BASE + Relocate PSCI code, for example to a secure memory on the SoC. If not + set, the PSCI sections are placed together with the u-boot and the + regions will be marked as reserved before linux is started. config ARMV8_SECURE_BASE hex "Secure address for PSCI image" - depends on ARMV8_PSCI + depends on ARMV8_PSCI_RELOCATE + default 0x1800 if ARCH_LS1028A help Address for placing the PSCI text, data and stack sections. - If not defined, the PSCI sections are placed together with the u-boot - but platform can choose to place PSCI code image separately in other - places such as some secure RAM built-in SOC etc. -endif + +config ARMV8_EA_EL3_FIRST + bool "External aborts and SError interrupt exception are taken in EL3" + help + Exception handling at all exception levels for External Abort and + SError interrupt exception are taken in EL3. endif diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index 14ef07e74f..8b1728862d 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -53,6 +53,7 @@ config ARCH_LS1028A select SYS_FSL_ERRATUM_A011334 select SYS_FSL_ESDHC_UNRELIABLE_PULSE_DETECTION_WORKAROUND select RESV_RAM if GIC_V3_ITS + select SYS_HAS_ARMV8_SECURE_BASE imply PANIC_HANG config ARCH_LS1043A @@ -88,6 +89,7 @@ config ARCH_LS1043A select SYS_I2C_MXC_I2C2 if !DM_I2C select SYS_I2C_MXC_I2C3 if !DM_I2C select SYS_I2C_MXC_I2C4 if !DM_I2C + select SYS_HAS_ARMV8_SECURE_BASE imply CMD_PCI imply ID_EEPROM diff --git a/board/freescale/ls1043ardb/Kconfig b/board/freescale/ls1043ardb/Kconfig index 778b8d8d5a..d66c7804b1 100644 --- a/board/freescale/ls1043ardb/Kconfig +++ b/board/freescale/ls1043ardb/Kconfig @@ -13,14 +13,6 @@ config SYS_SOC config SYS_CONFIG_NAME default "ls1043ardb" -config SYS_HAS_ARMV8_SECURE_BASE - bool "Enable secure address for PSCI image" - depends on ARMV8_PSCI - help - PSCI image can be re-located to secure RAM. - If enabled, please also define the value for ARMV8_SECURE_BASE, - for LS1043ARDB, it could be some address in OCRAM. - if FSL_LS_PPA config SYS_LS_PPA_FW_ADDR hex "PPA Firmware Addr" -- 2.30.2
[PATCH 2/5] armv8: layerscape: get rid of smc_call()
There are two different implementations to do a secure monitor call:
smc_call() and arm_smccc_smc(). The former is defined in fwcall.c and
seems to be an ad-hoc implementation. The latter is imported from linux.
smc_call() is also only available if CONFIG_ARMV8_PSCI is not defined.
This makes it impossible to have both PSCI calls and PSCI implementation
in one u-boot build. The layerscape SoC code decide at runtime via
check_psci() if there is a PSCI support. Therefore, this is a
prerequisite patch to add PSCI implementation support for the layerscape
SoCs.
Note, for the TFA part, this is only compile time tested with
(ls1028ardb_tfa_defconfig).
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 1 +
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 49 +--
arch/arm/cpu/armv8/fsl-layerscape/mp.c| 11 ++---
arch/arm/cpu/armv8/sec_firmware.c | 19 -
4 files changed, 31 insertions(+), 49 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 1a057f7059..14ef07e74f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -321,6 +321,7 @@ menu "Layerscape architecture"
config FSL_LAYERSCAPE
bool
+ select ARM_SMCCC
config HAS_FEATURE_GIC64K_ALIGN
bool
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 1a359d060e..38bef4432d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -766,7 +767,7 @@ enum boot_src __get_boot_src(u32 porsr1)
enum boot_src get_boot_src(void)
{
- struct pt_regs regs;
+ struct arm_smccc_res res;
u32 porsr1 = 0;
#if defined(CONFIG_FSL_LSCH3)
@@ -776,11 +777,9 @@ enum boot_src get_boot_src(void)
#endif
if (current_el() == 2) {
- regs.regs[0] = SIP_SVC_RCW;
-
- smc_call();
- if (!regs.regs[0])
- porsr1 = regs.regs[1];
+ arm_smccc_smc(SIP_SVC_RCW, 0, 0, 0, 0, 0, 0, 0, );
+ if (!res.a0)
+ porsr1 = res.a1;
}
if (current_el() == 3 || !porsr1) {
@@ -1079,9 +1078,9 @@ static void config_core_prefetch(void)
char *buf = NULL;
char buffer[HWCONFIG_BUFFER_SIZE];
const char *prefetch_arg = NULL;
+ struct arm_smccc_res res;
size_t arglen;
unsigned int mask;
- struct pt_regs regs;
if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
buf = buffer;
@@ -1099,11 +1098,10 @@ static void config_core_prefetch(void)
}
#define SIP_PREFETCH_DISABLE_64 0xC200FF13
- regs.regs[0] = SIP_PREFETCH_DISABLE_64;
- regs.regs[1] = mask;
- smc_call();
+ arm_smccc_smc(SIP_PREFETCH_DISABLE_64, mask, 0, 0, 0, 0, 0, 0,
+ );
- if (regs.regs[0])
+ if (res.a0)
printf("Prefetch disable config failed for mask ");
else
printf("Prefetch disable config passed for mask ");
@@ -1343,25 +1341,20 @@ phys_size_t get_effective_memsize(void)
#ifdef CONFIG_TFABOOT
phys_size_t tfa_get_dram_size(void)
{
- struct pt_regs regs;
- phys_size_t dram_size = 0;
-
- regs.regs[0] = SMC_DRAM_BANK_INFO;
- regs.regs[1] = -1;
+ struct arm_smccc_res res;
- smc_call();
- if (regs.regs[0])
+ arm_smccc_smc(SMC_DRAM_BANK_INFO, -1, 0, 0, 0, 0, 0, 0, );
+ if (res.a0)
return 0;
- dram_size = regs.regs[1];
- return dram_size;
+ return res.a1;
}
static int tfa_dram_init_banksize(void)
{
int i = 0, ret = 0;
- struct pt_regs regs;
phys_size_t dram_size = tfa_get_dram_size();
+ struct arm_smccc_res res;
debug("dram_size %llx\n", dram_size);
@@ -1369,19 +1362,15 @@ static int tfa_dram_init_banksize(void)
return -EINVAL;
do {
- regs.regs[0] = SMC_DRAM_BANK_INFO;
- regs.regs[1] = i;
-
- smc_call();
- if (regs.regs[0]) {
+ arm_smccc_smc(SMC_DRAM_BANK_INFO, i, 0, 0, 0, 0, 0, 0, );
+ if (res.a0) {
ret = -EINVAL;
break;
}
- debug("bank[%d]: start %lx, size %lx\n", i, regs.regs[1],
- regs.regs[2]);
- gd->bd->bi_dram[i].start = regs.regs[1];
- gd->bd->bi_dram[i].size = regs.regs[2];
+ debug("bank[%d]: start %lx, size %lx\n", i, res.a1, res.a2);
+
[PATCH 5/5] board: sl28: add basic PSCI implementation
For now, this only provides reset and poweroff functions.
Signed-off-by: Michael Walle
---
board/kontron/sl28/Makefile| 2 ++
board/kontron/sl28/psci.c | 42 ++
configs/kontron_sl28_defconfig | 2 ++
3 files changed, 46 insertions(+)
create mode 100644 board/kontron/sl28/psci.c
diff --git a/board/kontron/sl28/Makefile b/board/kontron/sl28/Makefile
index 5d220f0744..084c11da37 100644
--- a/board/kontron/sl28/Makefile
+++ b/board/kontron/sl28/Makefile
@@ -6,6 +6,8 @@ endif
obj-y += common.o ddr.o
+obj-$(CONFIG_ARMV8_PSCI) += psci.o
+
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
obj-$(CONFIG_SPL_ATF) += spl_atf.o
diff --git a/board/kontron/sl28/psci.c b/board/kontron/sl28/psci.c
new file mode 100644
index 00..19f0ef3b6d
--- /dev/null
+++ b/board/kontron/sl28/psci.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO2_GPDIR0x231
+#define GPIO2_GPDAT0x2310008
+#define RSTCR 0x1e6
+#define RESET_REQ BIT(1)
+
+u32 __secure psci_version(void)
+{
+ return ARM_PSCI_VER_0_2;
+}
+
+void __secure psci_system_reset(void)
+{
+ writel(RESET_REQ, RSTCR);
+
+ while (1)
+ wfi();
+}
+
+void __secure psci_system_off(void)
+{
+ int i;
+
+ writel(0x0200, GPIO2_GPDIR);
+ writel(0, GPIO2_GPDAT);
+
+ /* make sure the management controller has sampled the input */
+ for (i = 0; i < (1 << 11); i++)
+ asm("nop");
+
+ writel(RESET_REQ, RSTCR);
+
+ while (1)
+ wfi();
+}
diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
index 7fb6bdbe82..c9d6767055 100644
--- a/configs/kontron_sl28_defconfig
+++ b/configs/kontron_sl28_defconfig
@@ -19,6 +19,8 @@ CONFIG_ENV_OFFSET_REDUND=0x3f
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI=y
# CONFIG_PSCI_RESET is not set
+CONFIG_ARMV8_PSCI=y
+CONFIG_ARMV8_PSCI_RELOCATE=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x8200
--
2.30.2
[PATCH 0/5] board: sl28: add basic PSCI implementation
Add PSCI support to reset and power-off the board. Because this board can be used without TF-A, supply a (mandatory) PSCI implementation. The armv8 u-boot part already contains most bits for the implementation, it is just, that it isn't compatible with the layerscape parts. Thus, we first need to clean that up and then we can add our three little functions for the PSCI support. Michael Walle (5): armv8: include psci_update_dt() unconditionally armv8: layerscape: get rid of smc_call() armv8: psci: skip setup code if we are not EL3 armv8: psci: add ARMV8_PSCI_RELOCATE Kconfig option board: sl28: add basic PSCI implementation arch/arm/cpu/armv8/Kconfig| 30 +- arch/arm/cpu/armv8/cpu-dt.c | 7 ++-- arch/arm/cpu/armv8/cpu.c | 3 ++ arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 ++ arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 49 +-- arch/arm/cpu/armv8/fsl-layerscape/mp.c| 11 ++--- arch/arm/cpu/armv8/sec_firmware.c | 19 - board/freescale/ls1043ardb/Kconfig| 8 board/kontron/sl28/Makefile | 2 + board/kontron/sl28/psci.c | 42 +++ 10 files changed, 103 insertions(+), 71 deletions(-) create mode 100644 board/kontron/sl28/psci.c -- 2.30.2
[PATCH 1/5] armv8: include psci_update_dt() unconditionally
psci_update_dt() is also required if CONFIG_ARMV8_PSCI is set, that is,
if u-boot is the PSCI provider.
Guard the check which is intended to call into the PSCI implementation
in the secure firmware, by the proper macro SEC_FIRMWARE_ARMV8_PSCI.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/cpu-dt.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c
index 61c38b17cb..1bf8fbaae3 100644
--- a/arch/arm/cpu/armv8/cpu-dt.c
+++ b/arch/arm/cpu/armv8/cpu-dt.c
@@ -8,8 +8,8 @@
#include
#include
#include
+#include
-#if CONFIG_IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)
int psci_update_dt(void *fdt)
{
/*
@@ -18,8 +18,10 @@ int psci_update_dt(void *fdt)
* number to support detecting PSCI dynamically and then switching
* the SMP boot method between PSCI and spin-table.
*/
- if (sec_firmware_support_psci_version() == PSCI_INVALID_VER)
+ if (CONFIG_IS_ENABLED(SEC_FIRMWARE_ARMV8_PSCI) &&
+ sec_firmware_support_psci_version() == PSCI_INVALID_VER)
return 0;
+
fdt_psci(fdt);
#if defined(CONFIG_ARMV8_PSCI) && !defined(CONFIG_ARMV8_SECURE_BASE)
@@ -30,4 +32,3 @@ int psci_update_dt(void *fdt)
return 0;
}
-#endif
--
2.30.2
[PATCH 3/5] armv8: psci: skip setup code if we are not EL3
If we are running in EL2 skip PSCI implementation setup. This avoids an
exception if CONFIG_ARMV8_PSCI is set, but u-boot is started by TF-A.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/cpu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/cpu/armv8/cpu.c b/arch/arm/cpu/armv8/cpu.c
index ea40c55dd2..db5d460eb4 100644
--- a/arch/arm/cpu/armv8/cpu.c
+++ b/arch/arm/cpu/armv8/cpu.c
@@ -79,6 +79,9 @@ static void relocate_secure_section(void)
void armv8_setup_psci(void)
{
+ if (current_el() != 3)
+ return;
+
relocate_secure_section();
secure_ram_addr(psci_setup_vectors)();
secure_ram_addr(psci_arch_init)();
--
2.30.2
[PATCH] armv8: sec_firmware: drop unneeded ARMV8_SEC_FIRMWARE_SUPPORT check
This module will only be compiled if this symbol is set. Remove the
useless check. While at it, invert the return code, to return 0 if the
function succeeds. The only user of this function in
arch/arm/cpu/armv8/fsl-layerscape/fdt.c doesn't check the return code
anyway, so its safe change it.
Signed-off-by: Michael Walle
---
arch/arm/cpu/armv8/sec_firmware.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv8/sec_firmware.c
b/arch/arm/cpu/armv8/sec_firmware.c
index 267894fbcb..e62e9dc380 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -458,47 +458,45 @@ int sec_firmware_init(const void *sec_firmware_img,
/*
* fdt_fix_kaslr - Add kalsr-seed node in Device tree
* @fdt: Device tree
- * @eret: 0 in case of error, 1 for success
+ *
+ * Returns 0 on success and 1 in case of an error.
*/
int fdt_fixup_kaslr(void *fdt)
{
int nodeoffset;
- int err, ret = 0;
+ int err;
u8 rand[8];
-#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT)
/* Check if random seed generation is supported */
if (sec_firmware_support_hwrng() == false) {
printf("WARNING: SEC firmware not running, no kaslr-seed\n");
- return 0;
+ return 1;
}
ret = sec_firmware_get_random(rand, 8);
if (ret < 0) {
printf("WARNING: No random number to set kaslr-seed\n");
- return 0;
+ return 1;
}
err = fdt_check_header(fdt);
if (err < 0) {
printf("fdt_chosen: %s\n", fdt_strerror(err));
- return 0;
+ return 1;
}
/* find or create "/chosen" node. */
nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
if (nodeoffset < 0)
- return 0;
+ return 1;
err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", rand,
sizeof(rand));
if (err < 0) {
printf("WARNING: can't set kaslr-seed %s.\n",
fdt_strerror(err));
- return 0;
+ return 1;
}
- ret = 1;
-#endif
- return ret;
+ return 0;
}
--
2.30.2
[PATCH RFC] cmd: fix net list command
Don't get the MAC address by the environment, but by the platform data
of the udevice. This will fix "net list" if the MAC address is randomly
generated and won't change behavior when linux is booted.
Signed-off-by: Michael Walle
---
Hi,
this is a proposal to fix the "net list" in a way that linux still can have
its own fallback mechanism of MAC addresses even if the bootloader has
CONFIG_NET_RANDOM_ETHADDR enabled.
The intention is to replace [1], where if I understood correctly, the
intention was to fix "net list".
[1]
https://lore.kernel.org/u-boot/3996ba2ee4e6ac136c0802dc0df4ef9b1750157c.1635506067.git.michal.si...@xilinx.com/
cmd/net.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cmd/net.c b/cmd/net.c
index 651c1411f4..1df0f4eb99 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -486,14 +486,14 @@ U_BOOT_CMD(
static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
{
const struct udevice *current = eth_get_dev();
- unsigned char env_enetaddr[ARP_HLEN];
const struct udevice *dev;
+ struct eth_pdata *pdata;
struct uclass *uc;
uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
- eth_env_get_enetaddr_by_index("eth", dev_seq(dev),
env_enetaddr);
- printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name,
env_enetaddr,
- current == dev ? "active" : "");
+ pdata = dev_get_plat(dev);
+ printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name,
+ pdata->enetaddr, current == dev ? "active" : "");
}
return CMD_RET_SUCCESS;
}
--
2.30.2
Re: [PATCH RFC] cmd: fix net list command
Am 2021-11-15 13:15, schrieb Marek Vasut: On 11/15/21 1:11 PM, Michael Walle wrote: Don't get the MAC address by the environment, but by the platform data of the udevice. This will fix "net list" if the MAC address is randomly generated and won't change behavior when linux is booted. Signed-off-by: Michael Walle --- Hi, this is a proposal to fix the "net list" in a way that linux still can have its own fallback mechanism of MAC addresses even if the bootloader has CONFIG_NET_RANDOM_ETHADDR enabled. The intention is to replace [1], where if I understood correctly, the intention was to fix "net list". [1] https://lore.kernel.org/u-boot/3996ba2ee4e6ac136c0802dc0df4ef9b1750157c.1635506067.git.michal.si...@xilinx.com/ Does that mean U-Boot and Linux will possibly each have different MAC address on the same device ? That is clearly wrong and not how it is supposed to work, U-Boot passes its ethaddr/ethNaddr settings to Linux so that they would have the same MAC address on the same device. Yes they have different ones, but having a random mac address is wrong in the first place. So IMHO it is more useful to dectect that in linux, (and there was a good point that usually a user will look at dmesg and not some u-boot output) than having two different random MAC addresses, one for u-boot and one for linux. Initially that random MAC address thing was supposed to get networking running in u-boot if there is no ethaddr at all, eg. for network console. Now we are passing this made up network address to linux, too. Why? Just because it is wrong to have two different mac addresses? Some drivers doesn't even probe without one. And we are just masking away this error. You get this "two different mac addresses" between reboots. Which is also wrong. This actually strenghten my opinion that this "feature" should be an u-boot only thing. -michael
Re: [PATCH] net: uclass: Save ethernet MAC address when generated
Hi Ramon, Am 2021-11-09 14:55, schrieb Michael Walle: Am 2021-11-04 22:00, schrieb Ramon Fried: What's the verdict ? We're keeping this patch ? There was a good point from Grygorii: linux might deal in its own way with missing ethernet addresses (and warn the user about it because its usually an error). And IMHO that net list can be fixed in a different way. If this patch is accepted, it should be clearly documented in the Kconfig help text. And as I said, it changes behavior. So this patch now in your pull request. Why are you even asking then? -michael
