Re: Trying to boot custom kernel on Wink Hub (i.MX28)
I tried to follow your suggestion, but so far I have been unsuccessful.
I cloned Linus' latest source code, and then did:
make ARCH=arm mxs_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
cat arch/arm/boot/zImage ./arch/arm/boot/dts/imx28-evk.dtb >
arch/arm/boot/zImage_with_dtb
cd arch/arm/boot
mkimage -T kernel -A arm -O linux -a 0x40008000 -e 0x40008000 -C none -d
./zImage_with_dtb uImage_with_dtb
then copied onto the Wink hub and did:
flash_erase /dev/mtd4 0 0
nandwrite -p -m /dev/mtd4 uImage_with_dtb
reboot
I then interrupted u-boot, and had to update the number of bytes read from
the mtd4 partition (was 0x0040, now 0x0060), as the new kernel was
about 4 times larger than the vendor kernel, and I was getting checksum
errors due to only partial read of the image.
setenv app_boot 'run appboot_args && nand read ${loadaddr} app-kernel
0x0060 && bootm ${loadaddr}'
run app_boot
NAND read: device 0 offset 0x2b0, size 0x60
6291456 bytes read: OK
## Booting kernel from Legacy Image at 4200 ...
Image Name:
Created: 2023-06-22 21:37:11 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:6279041 Bytes = 6 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
And it stopped there after dumping some garbage to the screen.
I did note that the mxs_defconfig did not define the appended DTB config,
so I updated my .config as follows:
$ grep DTB .config
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
And rebuilt as above, with no change.
Am I doing something obviously wrong?
Thanks
Rogan
On Sat, 17 Jun 2023 at 16:28, Rogan Dawes wrote:
> Thank you so much for the response! It is much appreciated!
>
> I do hope to get JTAG working on the Hub v1, and then will be able to try
> to build a modern U-Boot which I can flash.
>
> Regards,
>
> Rogan
>
>
> On Thu, 15 Jun 2023 at 22:01, Fabio Estevam wrote:
>
>> Hi Rogan,
>>
>> On Thu, Jun 15, 2023 at 9:00 AM Rogan Dawes wrote:
>> >
>> > Hi folks,
>> >
>> > I am trying to boot a custom kernel on a Wink Hub v1, which has an
>> i.MX28
>> > CPU, and is running U-Boot (U-Boot 2014.01-14400-gda781c6-dirty (Apr 30
>> > 2014 - 22:35:38)).
>> >
>> > I have tried compiling my own modern kernel and putting it in place of
>> the
>> > vendor (Linux version 2.6.35.3-flex-dvt) kernel on the flash chip, but
>> when
>> > loading, I simply get the expected U-Boot loading messages, but then
>> > nothing at all from the serial port after that.
>> >
>> > I'm trying to figure out where my problem is most likely to be. As far
>> as I
>> > am aware from long-ago poking at U-Boot, the way that U-Boot passes
>> > arguments to the kernel has changed recently? Previously it was ATAGS,
>> and
>> > now it expects a Device Tree Blob? Might this explain the failure to
>> boot
>> > that I am seeing? And yes, I understand that given that
>>
>> Yes, to boot a modern kernel, you need to generate a devicetree for
>> the Wink Hubv1 board.
>>
>> Then you build it and generate a .dtb file.
>>
>> To boot zImage + dtb using an old bootloader that does not support
>> booting dtb,
>> you would need to select the following options in the kernel:
>>
>> CONFIG_ARM_APPENDED_DTB=y
>> CONFIG_ARM_ATAG_DTB_COMPAT=y
>>
>> And then:
>>
>> cat arch/arm/boot/zImage arch/arm/boot/dts/imx28-wink-hub-v1.dtb >
>> zImage_with_dtb
>>
>> And then boot zImage_with_dtb as you do with 2.6.35.
>>
>> Ideally, you should also port a modern U-Boot version, which supports
>> dtb by default and then you don't need the
>> steps above.
>>
>> Take a look at board/freescale/mx28eevk support for a reference.
>>
>> Regards,
>>
>> Fabio Estevam
>>
>
Re: Trying to boot custom kernel on Wink Hub (i.MX28)
Hi Rogan, On Thu, Jun 22, 2023 at 10:03 PM Fabio Estevam wrote: > > Hi Rogan, > > On Thu, Jun 22, 2023 at 7:43 PM Fabio Estevam wrote: > > > You should also pass the kernel command line: console=ttyAMA0,115200n8 > > > > As far as I recall, the 2.6.35 kernel used a different console device. > > Yes, 2.6.35 uses ttyAM0. Mainline uses ttyAMA0 (note the extra A). > > Please adjust it accordingly. Also, I validated booting a uImage on a imx28-evk using the same procedure. I used kernel 6.1.34. $ grep DTB .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set => setenv bootargs 'console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait' => print loadaddr loadaddr=0x4200 => load mmc 0:2 $loadaddr uImage_with_dtb 5916489 bytes read in 1778 ms (3.2 MiB/s) => bootm ## Booting kernel from Legacy Image at 4200 ... Image Name: Created: 2023-06-23 1:17:21 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:5916425 Bytes = 5.6 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 6.1.34-00030-ga03745a375fa-dirty (fabio@fabio-Precision-3551) (arm-linux-gnueabihf-gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #31 Thu Jun 22 22:12:44 -03 2023 [0.00] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] OF: fdt: Machine model: Freescale i.MX28 Evaluation Kit ... Most likely the ttyAMA0 change should allow you to boot. Cheers
Re: Trying to boot custom kernel on Wink Hub (i.MX28)
Hi Rogan, On Thu, Jun 22, 2023 at 7:43 PM Fabio Estevam wrote: > You should also pass the kernel command line: console=ttyAMA0,115200n8 > > As far as I recall, the 2.6.35 kernel used a different console device. Yes, 2.6.35 uses ttyAM0. Mainline uses ttyAMA0 (note the extra A). Please adjust it accordingly.
Re: Trying to boot custom kernel on Wink Hub (i.MX28)
Hi Rogan,
On Thu, Jun 22, 2023 at 7:09 PM Rogan Dawes wrote:
>
> I tried to follow your suggestion, but so far I have been unsuccessful.
>
> I cloned Linus' latest source code, and then did:
>
> make ARCH=arm mxs_defconfig
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> cat arch/arm/boot/zImage ./arch/arm/boot/dts/imx28-evk.dtb >
> arch/arm/boot/zImage_with_dtb
Do you have access to the Wink Hub v1 board schematics? What about the
original U-Boot and kernel source?
You are using imx28-evk.dtb here, but not sure if the console pins are
the same for the two boards.
It is better to create a minimal devicetree specific for Wink Hub v1.
To start with, you can only describe the duart node there.
> cd arch/arm/boot
> mkimage -T kernel -A arm -O linux -a 0x40008000 -e 0x40008000 -C none -d
> ./zImage_with_dtb uImage_with_dtb
>
> then copied onto the Wink hub and did:
>
> flash_erase /dev/mtd4 0 0
> nandwrite -p -m /dev/mtd4 uImage_with_dtb
> reboot
>
> I then interrupted u-boot, and had to update the number of bytes read from
> the mtd4 partition (was 0x0040, now 0x0060), as the new kernel was
> about 4 times larger than the vendor kernel, and I was getting checksum
> errors due to only partial read of the image.
>
> setenv app_boot 'run appboot_args && nand read ${loadaddr} app-kernel
> 0x0060 && bootm ${loadaddr}'
> run app_boot
>
> NAND read: device 0 offset 0x2b0, size 0x60
> 6291456 bytes read: OK
> ## Booting kernel from Legacy Image at 4200 ...
>Image Name:
>Created: 2023-06-22 21:37:11 UTC
>Image Type: ARM Linux Kernel Image (uncompressed)
>Data Size:6279041 Bytes = 6 MiB
>Load Address: 40008000
>Entry Point: 40008000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
>
> Starting kernel ...
>
> And it stopped there after dumping some garbage to the screen.
You should also pass the kernel command line: console=ttyAMA0,115200n8
As far as I recall, the 2.6.35 kernel used a different console device.
Can you share the U-Boot log of the board booting the 2.6.35 kernel?
> I did note that the mxs_defconfig did not define the appended DTB config, so
> I updated my .config as follows:
>
> $ grep DTB .config
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
> # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
One thing you could also try is to load U-Boot via USB using this tool:
https://source.denx.de/denx/mxsldr
To build U-Boot for mx28, please check:
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/imx/common/mxs.txt
[PATCH 6/9] doc: Bring in FIT signature files
Bring these files into the documentation.
Fix 'wtih' and 'it' typos and repeated 'could' while we are here.
Signed-off-by: Simon Glass
---
doc/uImage.FIT/beaglebone_vboot.txt | 607 --
doc/uImage.FIT/signature.txt | 707
doc/usage/cmd/source.rst | 2 +-
doc/usage/fit/beaglebone_vboot.rst| 607 ++
doc/usage/fit/index.rst | 3 +
doc/usage/fit/signature.rst | 760 ++
.../fit/verified-boot.rst}| 83 +-
7 files changed, 1414 insertions(+), 1355 deletions(-)
delete mode 100644 doc/uImage.FIT/beaglebone_vboot.txt
delete mode 100644 doc/uImage.FIT/signature.txt
create mode 100644 doc/usage/fit/beaglebone_vboot.rst
create mode 100644 doc/usage/fit/signature.rst
rename doc/{uImage.FIT/verified-boot.txt => usage/fit/verified-boot.rst} (54%)
diff --git a/doc/uImage.FIT/beaglebone_vboot.txt
b/doc/uImage.FIT/beaglebone_vboot.txt
deleted file mode 100644
index ebd2068ed38d..
--- a/doc/uImage.FIT/beaglebone_vboot.txt
+++ /dev/null
@@ -1,607 +0,0 @@
-Verified Boot on the Beaglebone Black
-=
-
-Introduction
-
-
-Before reading this, please read verified-boot.txt and signature.txt. These
-instructions are for mainline U-Boot from v2014.07 onwards.
-
-There is quite a bit of documentation in this directory describing how
-verified boot works in U-Boot. There is also a test which runs through the
-entire process of signing an image and running U-Boot (sandbox) to check it.
-However, it might be useful to also have an example on a real board.
-
-Beaglebone Black is a fairly common board so seems to be a reasonable choice
-for an example of how to enable verified boot using U-Boot.
-
-First a note that may to help avoid confusion. U-Boot and Linux both use
-device tree. They may use the same device tree source, but it is seldom useful
-for them to use the exact same binary from the same place. More typically,
-U-Boot has its device tree packaged wtih it, and the kernel's device tree is
-packaged with the kernel. In particular this is important with verified boot,
-since U-Boot's device tree must be immutable. If it can be changed then the
-public keys can be changed and verified boot is useless. An attacker can
-simply generate a new key and put his public key into U-Boot so that
-everything verifies. On the other hand the kernel's device tree typically
-changes when the kernel changes, so it is useful to package an updated device
-tree with the kernel binary. U-Boot supports the latter with its flexible FIT
-format (Flat Image Tree).
-
-
-Overview
-
-
-The steps are roughly as follows:
-
-1. Build U-Boot for the board, with the verified boot options enabled.
-
-2. Obtain a suitable Linux kernel
-
-3. Create a Image Tree Source file (ITS) file describing how you want the
-kernel to be packaged, compressed and signed.
-
-4. Create a key pair
-
-5. Sign the kernel
-
-6. Put the public key into U-Boot's image
-
-7. Put U-Boot and the kernel onto the board
-
-8. Try it
-
-
-Step 1: Build U-Boot
-
-
-a. Set up the environment variable to point to your toolchain. You will need
-this for U-Boot and also for the kernel if you build it. For example if you
-installed a Linaro version manually it might be something like:
-
- export
CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-
-
-or if you just installed gcc-arm-linux-gnueabi then it might be
-
- export CROSS_COMPILE=arm-linux-gnueabi-
-
-b. Configure and build U-Boot with verified boot enabled:
-
- export UBOOT=/path/to/u-boot
- cd $UBOOT
- # You can add -j10 if you have 10 CPUs to make it faster
- make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all
- export UOUT=$UBOOT/b/am335x_boneblack_vboot
-
-c. You will now have a U-Boot image:
-
- file b/am335x_boneblack_vboot/u-boot-dtb.img
-b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage, U-Boot
2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image (Not compressed),
395375 bytes, Sat May 31 16:19:04 2014, Load Address: 0x8080, Entry Point:
0x, Header CRC: 0x0ABD6ACA, Data CRC: 0x36DEF7E4
-
-
-Step 2: Build Linux
-
-
-a. Find the kernel image ('Image') and device tree (.dtb) file you plan to
-use. In our case it is am335x-boneblack.dtb and it is built with the kernel.
-At the time of writing an SD Boot image can be obtained from here:
-
-
http://www.elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD
-
-You can write this to an SD card and then mount it to extract the kernel and
-device tree files.
-
-You can also build a kernel. Instructions for this are are here:
-
- http://elinux.org/Building_BBB_Kernel
-
-or you can use your favourite search engine. Following these instructions
-produces a kernel Image
[PATCH 9/9] doc: Bring in the command-syntax extensions
Bring this file into the documentation.
Signed-off-by: Simon Glass
---
.../fit/command_syntax_extensions.rst}| 166 ++
doc/usage/fit/index.rst | 1 +
2 files changed, 97 insertions(+), 70 deletions(-)
rename doc/{uImage.FIT/command_syntax_extensions.txt =>
usage/fit/command_syntax_extensions.rst} (57%)
diff --git a/doc/uImage.FIT/command_syntax_extensions.txt
b/doc/usage/fit/command_syntax_extensions.rst
similarity index 57%
rename from doc/uImage.FIT/command_syntax_extensions.txt
rename to doc/usage/fit/command_syntax_extensions.rst
index 6a99089ab557..65b7891c8a69 100644
--- a/doc/uImage.FIT/command_syntax_extensions.txt
+++ b/doc/usage/fit/command_syntax_extensions.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
Command syntax extensions for the new uImage format
===
@@ -20,100 +22,117 @@ of supported bootm usages.
Note: U-Boot supports two methods of booting a PowerPC Linux kernel: old way,
i.e., without passing the Flattened Device Tree (FDT), and new way, where the
kernel is passed a pointer to the FDT. The boot method is indicated for each
-scenario.
+scenario::
+1. bootmboot image at the current address, equivalent to 2,3,8
-1. bootm boot image at the current address, equivalent to 2,3,8
+Old uImage::
-Old uImage:
-2. bootm /* single image at */
-3. bootm /* multi-image at */
-4. bootm -/* multi-image at */
-5. bootm/* single image at */
-6. bootm /* single image at */
-7. bootm - /* single image at */
+2. bootm /* single image at */
+3. bootm /* multi-image at */
+4. bootm -/* multi-image at */
+5. bootm /* single image at */
+6. bootm /* single image at */
+7. bootm - /* single image at */
-New uImage:
-8. bootm
-9. bootm []:
-10. bootm []#[#]: []:
-12. bootm []: []: []:
-13. bootm []: []:
-14. bootm []: - []:
-15. bootm []: -
+New uImage::
+8. bootm
+9. bootm []:
+10. bootm []#[#]: []:
+12. bootm []: []: []:
+13. bootm []: []:
+14. bootm []: - []:
+15. bootm []: -
Ad. 1. This is equivalent to cases 2,3,8, depending on the type of image at
the current image address.
+
- boot method: see cases 2,3,8
Ad. 2. Boot kernel image located at .
+
- boot method: non-FDT
Ad. 3. First and second components of the image at are assumed to be a
kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
with the ramdisk from the image.
+
- boot method: depends on the number of components at , and on whether
- U-Boot is compiled with OF support:
+ U-Boot is compiled with OF support::
- | 2 components | 3 components |
- | (kernel, initrd) | (kernel, initrd, fdt) |
--
-#ifdef CONFIG_OF_* | non-FDT | FDT |
-#ifndef CONFIG_OF_* | non-FDT | non-FDT |
+==
+| 2 components | 3 components|
+| (kernel, initrd) | (kernel, initrd, fdt) |
+==
+#ifdef CONFIG_OF_* |non-FDT | FDT |
+#ifndef CONFIG_OF_* |non-FDT | non-FDT |
+==
Ad. 4. Similar to case 3, but the kernel is booted without initrd. Second
component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
+
- boot method: see case 3
Ad. 5. Boot kernel image located at with initrd loaded with ramdisk
from the image at .
+
- boot method: non-FDT
Ad. 6. is the address of a kernel image, is the address of a
ramdisk image, and is the address of a FDT binary blob. Kernel is
booted with initrd loaded with ramdisk from the image at .
+
- boot method: FDT
Ad. 7. is the address of a kernel image and is the address of
a FDT binary blob. Kernel is booted without initrd.
+
- boot method: FDT
Ad. 8. Image at is assumed to contain a default configuration, which
is booted.
+
- boot method: FDT or non-FDT, depending on whether the default configuration
defines FDT
Ad. 9. Similar to case 2: boot kernel stored in from the image at
address .
+
- boot method: non-FDT
Ad. 10. Boot configuration from the image at .
+
- boot method: FDT or non-FDT, depending on whether the configuration given
defines FDT
Ad. 11. Equivalent to case 5: boot kernel stored in from the image
at with initrd loaded
[PATCH 8/9] doc: Bring in the FIT overlay information
Bring this file into the documentation.
Signed-off-by: Simon Glass
---
doc/uImage.FIT/overlay-fdt-boot.txt | 225 ---
doc/usage/fit/index.rst | 1 +
doc/usage/fit/overlay-fdt-boot.rst | 227
3 files changed, 228 insertions(+), 225 deletions(-)
delete mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt
create mode 100644 doc/usage/fit/overlay-fdt-boot.rst
diff --git a/doc/uImage.FIT/overlay-fdt-boot.txt
b/doc/uImage.FIT/overlay-fdt-boot.txt
deleted file mode 100644
index dddc4db1a67d..
--- a/doc/uImage.FIT/overlay-fdt-boot.txt
+++ /dev/null
@@ -1,225 +0,0 @@
-U-Boot FDT Overlay FIT usage
-
-
-Introduction
-
-In many cases it is desirable to have a single FIT image support a multitude
-of similar boards and their expansion options. The same kernel on DT enabled
-platforms can support this easily enough by providing a DT blob upon boot
-that matches the desired configuration.
-
-This document focuses on specifically using overlays as part of a FIT image.
-General information regarding overlays including its syntax and building it
-can be found in doc/README.fdt-overlays
-
-Configuration without overlays
---
-
-Take a hypothetical board named 'foo' where there are different supported
-revisions, reva and revb. Assume that both board revisions can use add a bar
-add-on board, while only the revb board can use a baz add-on board.
-
-Without using overlays the configuration would be as follows for every case.
-
- /dts-v1/;
- / {
- images {
- kernel {
- data = /incbin/("./zImage");
- type = "kernel";
- arch = "arm";
- os = "linux";
- load = <0x8200>;
- entry = <0x8200>;
- };
- fdt-1 {
- data = /incbin/("./foo-reva.dtb");
- type = "flat_dt";
- arch = "arm";
- };
- fdt-2 {
- data = /incbin/("./foo-revb.dtb");
- type = "flat_dt";
- arch = "arm";
- };
- fdt-3 {
- data = /incbin/("./foo-reva-bar.dtb");
- type = "flat_dt";
- arch = "arm";
- };
- fdt-4 {
- data = /incbin/("./foo-revb-bar.dtb");
- type = "flat_dt";
- arch = "arm";
- };
- fdt-5 {
- data = /incbin/("./foo-revb-baz.dtb");
- type = "flat_dt";
- arch = "arm";
- };
- fdt-6 {
- data = /incbin/("./foo-revb-bar-baz.dtb");
- type = "flat_dt";
- arch = "arm";
- };
- };
-
- configurations {
- default = "foo-reva.dtb;
- foo-reva.dtb {
- kernel = "kernel";
- fdt = "fdt-1";
- };
- foo-revb.dtb {
- kernel = "kernel";
- fdt = "fdt-2";
- };
- foo-reva-bar.dtb {
- kernel = "kernel";
- fdt = "fdt-3";
- };
- foo-revb-bar.dtb {
- kernel = "kernel";
- fdt = "fdt-4";
- };
- foo-revb-baz.dtb {
- kernel = "kernel";
- fdt = "fdt-5";
- };
- foo-revb-bar-baz.dtb {
- kernel = "kernel";
- fdt = "fdt-6";
- };
- };
- };
-
-Note the blob needs to be compiled for each case and the combinatorial
explosion of
-configurations. A typical device tree blob is in the low hunderds of kbytes so
a
-multitude of configuration grows the image quite a bit.
-
-Booting this image is done by using
-
- # bootm #
-
-Where config is one of:
- foo-reva.dtb, foo-revb.dtb, foo-reva-bar.dtb, foo-revb-bar.dtb,
- foo-revb-baz.dtb, foo-revb-bar-baz.dtb
-
-This selects the DTB to use when booting.
-
-Configuration using
[PATCH 7/9] doc: Bring in the FIT howto
Bring this file into the documentation.
Signed-off-by: Simon Glass
---
doc/uImage.FIT/howto.txt | 411 --
doc/usage/fit/howto.rst | 419 +++
doc/usage/fit/index.rst | 1 +
3 files changed, 420 insertions(+), 411 deletions(-)
delete mode 100644 doc/uImage.FIT/howto.txt
create mode 100644 doc/usage/fit/howto.rst
diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt
deleted file mode 100644
index 6dbd17dc8ca0..
--- a/doc/uImage.FIT/howto.txt
+++ /dev/null
@@ -1,411 +0,0 @@
-How to use images in the new image format
-=
-
-Author: Bartlomiej Sieka
-
-
-Overview
-
-
-The new uImage format allows more flexibility in handling images of various
-types (kernel, ramdisk, etc.), it also enhances integrity protection of images
-with sha1 and md5 checksums.
-
-Two auxiliary tools are needed on the development host system in order to
-create an uImage in the new format: mkimage and dtc, although only one
-(mkimage) is invoked directly. dtc is called from within mkimage and operates
-behind the scenes, but needs to be present in the $PATH nevertheless. It is
-important that the dtc used has support for binary includes -- refer to
-
- git://git.kernel.org/pub/scm/utils/dtc/dtc.git
-
-for its latest version. mkimage (together with dtc) takes as input
-an image source file, which describes the contents of the image and defines
-its various properties used during booting. By convention, image source file
-has the ".its" extension, also, the details of its format are given in
-doc/uImage.FIT/source_file_format.txt. The actual data that is to be included
in
-the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
-form of paths to appropriate data files. The outcome of the image creation
-process is a binary file (by convention with the ".itb" extension) that
-contains all the referenced data (kernel, ramdisk, etc.) and other information
-needed by U-Boot to handle the uImage properly. The uImage file is then
-transferred to the target (e.g., via tftp) and booted using the bootm command.
-
-To summarize the prerequisites needed for new uImage creation:
-- mkimage
-- dtc (with support for binary includes)
-- image source file (*.its)
-- image data file(s)
-
-
-Here's a graphical overview of the image creation and booting process:
-
-image source file mkimage + dtc transfer to target
- +---> image file > bootm
-image data file(s)
-
-SPL usage
--
-
-The SPL can make use of the new image format as well, this traditionally
-is used to ship multiple device tree files within one image. Code in the SPL
-will choose the one matching the current board and append this to the
-U-Boot proper binary to be automatically used up by it.
-Aside from U-Boot proper and one device tree blob the SPL can load multiple,
-arbitrary image files as well. These binaries should be specified in their
-own subnode under the /images node, which should then be referenced from one or
-multiple /configurations subnodes. The required images must be enumerated in
-the "loadables" property as a list of strings.
-
-If a platform specific image source file (.its) is shipped with the U-Boot
-source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol.
-In this case it will be automatically used by U-Boot's Makefile to generate
-the image.
-If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR
-can point to a script which generates this image source file during
-the build process. It gets passed a list of device tree files (taken from the
-CONFIG_OF_LIST symbol).
-
-The SPL also records to a DT all additional images (called loadables) which are
-loaded. The information about loadables locations is passed via the DT node
with
-fit-images name.
-
-Finally, if there are multiple xPL phases (e.g. SPL, VPL), images can be marked
-as intended for a particular phase using the 'phase' property. For example, if
-fit_image_load() is called with image_ph(IH_PHASE_SPL, IH_TYPE_FIRMWARE), then
-only the image listed into the "firmware" property where phase is set to "spl"
-will be loaded.
-
-Loadables Example
--
-Consider the following case for an ARM64 platform where U-Boot runs in EL2
-started by ATF where SPL is loading U-Boot (as loadables) and ATF (as
firmware).
-
-/dts-v1/;
-
-/ {
- description = "Configuration to load ATF before U-Boot";
-
- images {
- uboot {
- description = "U-Boot (64-bit)";
- data = /incbin/("u-boot-nodtb.bin");
- type = "firmware";
- os = "u-boot";
- arch = "arm64";
- compression = "none";
- load = <0x8 0x800>;
- entry = <0x8 0x800>;
-
[PATCH 5/9] doc: Bring in FIT x86 boot
Bring this file into the documentation. Signed-off-by: Simon Glass --- doc/uImage.FIT/x86-fit-boot.txt | 272 doc/usage/fit/index.rst | 1 + doc/usage/fit/x86-fit-boot.rst | 269 +++ 3 files changed, 270 insertions(+), 272 deletions(-) delete mode 100644 doc/uImage.FIT/x86-fit-boot.txt create mode 100644 doc/usage/fit/x86-fit-boot.rst diff --git a/doc/uImage.FIT/x86-fit-boot.txt b/doc/uImage.FIT/x86-fit-boot.txt deleted file mode 100644 index 88d3460a83eb.. --- a/doc/uImage.FIT/x86-fit-boot.txt +++ /dev/null @@ -1,272 +0,0 @@ -Booting Linux on x86 with FIT -= - -Background --- - -(corrections to the text below are welcome) - -Generally Linux x86 uses its own very complex booting method. There is a setup -binary which contains all sorts of parameters and a compressed self-extracting -binary for the kernel itself, often with a small built-in serial driver to -display decompression progress. - -The x86 CPU has various processor modes. I am no expert on these, but my -understanding is that an x86 CPU (even a really new one) starts up in a 16-bit -'real' mode where only 1MB of memory is visible, moves to 32-bit 'protected' -mode where 4GB is visible (or more with special memory access techniques) and -then to 64-bit 'long' mode if 64-bit execution is required. - -Partly the self-extracting nature of Linux was introduced to cope with boot -loaders that were barely capable of loading anything. Even changing to 32-bit -mode was something of a challenge, so putting this logic in the kernel seemed -to make sense. - -Bit by bit more and more logic has been added to this post-boot pre-Linux -wrapper: - -- Changing to 32-bit mode -- Decompression -- Serial output (with drivers for various chips) -- Load address randomisation -- Elf loader complete with relocation (for the above) -- Random number generator via 3 methods (again for the above) -- Some sort of EFI mini-loader (1000+ glorious lines of code) -- Locating and tacking on a device tree and ramdisk - -To my mind, if you sit back and look at things from first principles, this -doesn't make a huge amount of sense. Any boot loader worth its salts already -has most of the above features and more besides. The boot loader already knows -the layout of memory, has a serial driver, can decompress things, includes an -ELF loader and supports device tree and ramdisks. The decision to duplicate -all these features in a Linux wrapper caters for the lowest common -denominator: a boot loader which consists of a BIOS call to load something off -disk, followed by a jmp instruction. - -(Aside: On ARM systems, we worry that the boot loader won't know where to load -the kernel. It might be easier to just provide that information in the image, -or in the boot loader rather than adding a self-relocator to put it in the -right place. Or just use ELF? - -As a result, the x86 kernel boot process is needlessly complex. The file -format is also complex, and obfuscates the contents to a degree that it is -quite a challenge to extract anything from it. This bzImage format has become -so prevalent that is actually isn't possible to produce the 'raw' kernel build -outputs with the standard Makefile (as it is on ARM for example, at least at -the time of writing). - -This document describes an alternative boot process which uses simple raw -images which are loaded into the right place by the boot loader and then -executed. - - -Build the kernel - - -Note: these instructions assume a 32-bit kernel. U-Boot also supports directly -booting a 64-bit kernel by jumping into 64-bit mode first (see below). - -You can build the kernel as normal with 'make'. This will create a file called -'vmlinux'. This is a standard ELF file and you can look at it if you like: - -$ objdump -h vmlinux - -vmlinux: file format elf32-i386 - -Sections: -Idx Name Size VMA LMA File off Algn - 0 .text 00416850 8100 0100 1000 2**5 - CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE - 1 .notes0024 81416850 01416850 00417850 2**2 - CONTENTS, ALLOC, LOAD, READONLY, CODE - 2 __ex_table0c50 81416880 01416880 00417880 2**3 - CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA - 3 .rodata 00154b9e 81418000 01418000 00419000 2**5 - CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA - 4 __bug_table 597c 8156cba0 0156cba0 0056dba0 2**0 - CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA - 5 .pci_fixup1b80 8157251c 0157251c 0057351c 2**2 - CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA - 6 .tracedata0024 8157409c 0157409c 0057509c 2**0 - CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA - 7 __ksymtab 7ec0 815740c0 015740c0 005750c0 2**2 - CONTENTS,
[PATCH 4/9] doc: Bring in the FIT examples
Convert these to rST format and add them to the index.
Signed-off-by: Simon Glass
---
doc/uImage.FIT/kernel.its | 91 ---
doc/uImage.FIT/kernel_fdt.its | 51
doc/uImage.FIT/kernel_fdts_compressed.its | 73
doc/uImage.FIT/multi-with-fpga.its| 68 ---
doc/uImage.FIT/multi-with-loadables.its | 89 --
doc/uImage.FIT/multi.its | 133 -
doc/uImage.FIT/multi_spl.its | 96 ---
doc/uImage.FIT/sec_firmware_ppa.its | 49
doc/uImage.FIT/sign-configs.its | 45 ---
doc/uImage.FIT/sign-images.its| 42 ---
doc/uImage.FIT/uefi.its | 67 ---
doc/uImage.FIT/update3.its| 44 ---
doc/uImage.FIT/update_uboot.its | 24
doc/usage/fit/kernel.rst | 93 +++
doc/usage/fit/kernel_fdt.rst | 54 +
doc/usage/fit/kernel_fdts_compressed.rst | 77
doc/usage/fit/multi-with-fpga.rst | 70 +++
doc/usage/fit/multi-with-loadables.rst| 91 +++
doc/usage/fit/multi.rst | 136 ++
doc/usage/fit/multi_spl.rst | 101
doc/usage/fit/sec_firmware_ppa.rst| 54 +
doc/usage/fit/sign-configs.rst| 52 +
doc/usage/fit/sign-images.rst | 49
doc/usage/fit/source_file_format.rst | 31 -
doc/usage/fit/uefi.rst| 72
doc/usage/fit/update3.rst | 47
doc/usage/fit/update_uboot.rst| 28 +
27 files changed, 950 insertions(+), 877 deletions(-)
delete mode 100644 doc/uImage.FIT/kernel.its
delete mode 100644 doc/uImage.FIT/kernel_fdt.its
delete mode 100644 doc/uImage.FIT/kernel_fdts_compressed.its
delete mode 100644 doc/uImage.FIT/multi-with-fpga.its
delete mode 100644 doc/uImage.FIT/multi-with-loadables.its
delete mode 100644 doc/uImage.FIT/multi.its
delete mode 100644 doc/uImage.FIT/multi_spl.its
delete mode 100644 doc/uImage.FIT/sec_firmware_ppa.its
delete mode 100644 doc/uImage.FIT/sign-configs.its
delete mode 100644 doc/uImage.FIT/sign-images.its
delete mode 100644 doc/uImage.FIT/uefi.its
delete mode 100644 doc/uImage.FIT/update3.its
delete mode 100644 doc/uImage.FIT/update_uboot.its
create mode 100644 doc/usage/fit/kernel.rst
create mode 100644 doc/usage/fit/kernel_fdt.rst
create mode 100644 doc/usage/fit/kernel_fdts_compressed.rst
create mode 100644 doc/usage/fit/multi-with-fpga.rst
create mode 100644 doc/usage/fit/multi-with-loadables.rst
create mode 100644 doc/usage/fit/multi.rst
create mode 100644 doc/usage/fit/multi_spl.rst
create mode 100644 doc/usage/fit/sec_firmware_ppa.rst
create mode 100644 doc/usage/fit/sign-configs.rst
create mode 100644 doc/usage/fit/sign-images.rst
create mode 100644 doc/usage/fit/uefi.rst
create mode 100644 doc/usage/fit/update3.rst
create mode 100644 doc/usage/fit/update_uboot.rst
diff --git a/doc/uImage.FIT/kernel.its b/doc/uImage.FIT/kernel.its
deleted file mode 100644
index 77ddf622deb8..
--- a/doc/uImage.FIT/kernel.its
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * Simple U-Boot uImage source file containing a single kernel
- */
-
-/dts-v1/;
-
-/ {
- description = "Simple image with single Linux kernel";
- #address-cells = <1>;
-
- images {
- kernel {
- description = "Vanilla Linux kernel";
- data = /incbin/("./vmlinux.bin.gz");
- type = "kernel";
- arch = "ppc";
- os = "linux";
- compression = "gzip";
- load = <>;
- entry = <>;
- hash-1 {
- algo = "crc32";
- };
- hash-2 {
- algo = "sha1";
- };
- };
- };
-
- configurations {
- default = "config-1";
- config-1 {
- description = "Boot Linux kernel";
- kernel = "kernel";
- };
- };
-};
-
-
-
-For x86 a setup node is also required: see x86-fit-boot.txt.
-
-/dts-v1/;
-
-/ {
- description = "Simple image with single Linux kernel on x86";
- #address-cells = <1>;
-
- images {
- kernel {
- description = "Vanilla Linux kernel";
- data = /incbin/("./image.bin.lzo");
- type = "kernel";
- arch = "x86";
- os = "linux";
- compression = "lzo";
- load = <0x0100>;
- entry = <0x>;
-
[PATCH 3/9] doc: Reformat the FIT documentation to make it nicer
Fix up headings and tables to read better. Signed-off-by: Simon Glass --- doc/usage/fit/source_file_format.rst | 255 ++- 1 file changed, 172 insertions(+), 83 deletions(-) diff --git a/doc/usage/fit/source_file_format.rst b/doc/usage/fit/source_file_format.rst index 9f4688db2a15..4d2ea0a7b158 100644 --- a/doc/usage/fit/source_file_format.rst +++ b/doc/usage/fit/source_file_format.rst @@ -1,11 +1,8 @@ U-Boot new uImage source file format (bindings definition) == -Author: Marian Balakowicz -External data additions, 25/1/16 Simon Glass - -1) Introduction +Introduction + Evolution of the 2.6 Linux kernel for embedded PowerPC systems introduced new booting method which requires that hardware description is available to the @@ -30,16 +27,18 @@ All those factors combined clearly show that there is a need for new, more flexible, multi component uImage format. -2) New uImage format assumptions - +New uImage format assumptions +- -a) Implementation +Implementation +~~ Libfdt has been selected for the new uImage format implementation as (1) it provides needed functionality, (2) is actively maintained and developed and (3) increases code reuse as it is already part of the U-Boot source tree. -b) Terminology +Terminology +~~~ This document defines new uImage structure by providing FDT bindings for new uImage internals. Bindings are defined from U-Boot perspective, i.e. describe @@ -50,15 +49,20 @@ hashes) will need to be filled in automatically by the U-Boot mkimage tool. To avoid confusion with the kernel FDT the following naming convention is proposed for the new uImage format related terms: -FIT- Flattened uImage Tree +FIT +Flattened uImage Tree FIT is formally a flattened device tree (in the libfdt meaning), which conforms to bindings defined in this document. -.its - image tree source -.itb - flattened image tree blob +.its +image tree source + +.itb +flattened image tree blob -c) Image building procedure +Image building procedure + The following picture shows how the new uImage is prepared. Input consists of image source file (.its) and a set of data files. Image is created with the @@ -74,14 +78,20 @@ actual binary of a new uImage:: ... | 'new uImage' - - create .its file, automatically filled-in properties are omitted - - call mkimage tool on a .its file - - mkimage calls dtc to create .itb image and assures that - missing properties are added - - .itb (new uImage) is uploaded onto the target and used therein +Steps: + +#. Create .its file, automatically filled-in properties are omitted + +#. Call mkimage tool on a .its file + +#. mkimage calls dtc to create .itb image and assures that + missing properties are added + +#. .itb (new uImage) is uploaded onto the target and used therein -d) Unique identifiers +Unique identifiers +~~ To identify FIT sub-nodes representing images, hashes, configurations (which are defined in the following sections), the "unit name" of the given sub-node @@ -89,8 +99,8 @@ is used as it's identifier as it assures uniqueness without additional checking required. -3) Root node properties +Root node properties + Root node of the uImage Tree should have the following layout:: @@ -113,28 +123,42 @@ Root node of the uImage Tree should have the following layout:: ... - Optional property: - - description : Textual description of the uImage +Optional property +~ - Mandatory property: - - timestamp : Last image modification time being counted in seconds since +description +Textual description of the uImage + +Mandatory property +~~ + +timestamp +Last image modification time being counted in seconds since 1970-01-01 00:00:00 - to be automatically calculated by mkimage tool. - Conditionally mandatory property: - - #address-cells : Number of 32bit cells required to represent entry and +Conditionally mandatory property + + +#address-cells +Number of 32bit cells required to represent entry and load addresses supplied within sub-image nodes. May be omitted when no entry or load addresses are used. - Mandatory nodes: - - images : This node contains a set of sub-nodes, each of them representing +Mandatory nodes +~~~ + +images +This node contains a set of sub-nodes, each of them representing single component sub-image (like kernel, ramdisk, etc.). At least one sub-image is required. - - configurations : Contains a set of available configuration nodes and + +configurations +Contains a
[PATCH 2/9] doc: Convert FIT source-file format to rST
Move this document and convert it to rST. Make minimal changes, enough
for it to build successfully.
Signed-off-by: Simon Glass
---
doc/usage/fit/index.rst | 1 +
.../fit/source_file_format.rst} | 125 +-
2 files changed, 64 insertions(+), 62 deletions(-)
rename doc/{uImage.FIT/source_file_format.txt =>
usage/fit/source_file_format.rst} (84%)
diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index 68641a6704ff..93a962319035 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -10,3 +10,4 @@ doc/uImage.FIT
.. toctree::
:maxdepth: 1
+source_file_format
diff --git a/doc/uImage.FIT/source_file_format.txt
b/doc/usage/fit/source_file_format.rst
similarity index 84%
rename from doc/uImage.FIT/source_file_format.txt
rename to doc/usage/fit/source_file_format.rst
index 269e1fa0b580..9f4688db2a15 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/usage/fit/source_file_format.rst
@@ -64,16 +64,15 @@ The following picture shows how the new uImage is prepared.
Input consists of
image source file (.its) and a set of data files. Image is created with the
help of standard U-Boot mkimage tool which in turn uses dtc (device tree
compiler) to produce image tree blob (.itb). Resulting .itb file is the
-actual binary of a new uImage.
+actual binary of a new uImage::
-
-tqm5200.its
-+
-vmlinux.bin.gzmkimage + dtc xfer to target
-eldk-4.2-ramdisk --> tqm5200.itb --> bootm
-tqm5200.dtb /|\
-... |
-'new uImage'
+tqm5200.its
++
+vmlinux.bin.gzmkimage + dtc xfer to target
+eldk-4.2-ramdisk --> tqm5200.itb --> bootm
+tqm5200.dtb /|\
+... |
+'new uImage'
- create .its file, automatically filled-in properties are omitted
- call mkimage tool on a .its file
@@ -93,25 +92,25 @@ checking required.
3) Root node properties
---
-Root node of the uImage Tree should have the following layout:
-
-/ o image-tree
-|- description = "image description"
-|- timestamp = <12399321>
-|- #address-cells = <1>
-|
-o images
-| |
-| o image-1 {...}
-| o image-2 {...}
-| ...
-|
-o configurations
- |- default = "conf-1"
- |
- o conf-1 {...}
- o conf-2 {...}
- ...
+Root node of the uImage Tree should have the following layout::
+
+/ o image-tree
+|- description = "image description"
+|- timestamp = <12399321>
+|- #address-cells = <1>
+|
+o images
+| |
+| o image-1 {...}
+| o image-2 {...}
+| ...
+|
+o configurations
+|- default = "conf-1"
+|
+o conf-1 {...}
+o conf-2 {...}
+...
Optional property:
@@ -138,21 +137,21 @@ Root node of the uImage Tree should have the following
layout:
-
This node is a container node for component sub-image nodes. Each sub-node of
-the '/images' node should have the following layout:
-
- o image-1
- |- description = "component sub-image description"
- |- data = /incbin/("path/to/data/file.bin")
- |- type = "sub-image type name"
- |- arch = "ARCH name"
- |- os = "OS name"
- |- compression = "compression name"
- |- load = <>
- |- entry = <>
- |
- o hash-1 {...}
- o hash-2 {...}
- ...
+the '/images' node should have the following layout::
+
+o image-1
+|- description = "component sub-image description"
+|- data = /incbin/("path/to/data/file.bin")
+|- type = "sub-image type name"
+|- arch = "ARCH name"
+|- os = "OS name"
+|- compression = "compression name"
+|- load = <>
+|- entry = <>
+|
+o hash-1 {...}
+o hash-2 {...}
+...
Mandatory properties:
- description : Textual description of the component sub-image
@@ -202,9 +201,11 @@ the '/images' node should have the following layout:
5) Hash nodes
-
-o hash-1
- |- algo = "hash or checksum algorithm name"
- |- value = [hash or checksum value]
+::
+
+o hash-1
+|- algo = "hash or checksum algorithm name"
+|- value = [hash or checksum value]
Mandatory properties:
- algo : Algorithm name, supported are "crc32", "md5" and "sha1".
@@ -218,14 +219,14 @@ o hash-1
The 'configurations' node creates convenient, labeled boot configurations,
which combine together kernel images with their ramdisks and fdt blobs.
-The 'configurations' node has has the following structure:
+The 'configurations' node has has the following structure::
-o configurations
- |- default = "default configuration sub-node unit name"
-
[PATCH 1/9] doc: Move FIT into its own directory
Create a new usage/fit directory which will house information about FIT.
Signed-off-by: Simon Glass
---
doc/usage/{fit.rst => fit/index.rst} | 4
doc/usage/index.rst | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
rename doc/usage/{fit.rst => fit/index.rst} (88%)
diff --git a/doc/usage/fit.rst b/doc/usage/fit/index.rst
similarity index 88%
rename from doc/usage/fit.rst
rename to doc/usage/fit/index.rst
index 70374340577e..68641a6704ff 100644
--- a/doc/usage/fit.rst
+++ b/doc/usage/fit/index.rst
@@ -6,3 +6,7 @@ Flat Image Tree (FIT)
U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
images that it it reads and boots. Documentation about FIT is available at
doc/uImage.FIT
+
+.. toctree::
+:maxdepth: 1
+
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 84ef8a9a427d..e1fe284b38c1 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -8,7 +8,7 @@ Use U-Boot
dfu
environment
fdt_overlays
- fit
+ fit/index
netconsole
partitions
cmdline
--
2.41.0.162.gfafddb0af9-goog
Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa
On Thu, 22 Jun 2023 11:59:32 PDT (-0700), Conor Dooley wrote: On Thu, Jun 22, 2023 at 11:25:35AM -0700, Palmer Dabbelt wrote: Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt I'm not wed to any particular encoding for the properties, IMO that's more of a decision for the DT folks. IMO the important bit is to just get away from ISA strings and move towards some tightly-specified properties that indicate how the HW actually behaves. I'm going to resubmit with Rob's list of strings. I'll keep your tags, since the spirit of the patch will be the same, with enforced meanings for each extension. Works for me, thanks. Cheers, Conor.
Re: [PATCH] arm: dts: imx8m: move CAAM nodes into common u-boot.dtsi
On Thu, Jun 22, 2023 at 3:52 PM Tim Harvey wrote: > > Move the crypto and sec_jr* nodes from board-specific > u-boot.dtsi files into the common files. Additionally protect the > nodes with ifdef FSL_CAAM as they don't serve any purpose if that is > not enabled. > > Signed-off-by: Tim Harvey Reviewed-by: Fabio Estevam
Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa
On Thu, Jun 22, 2023 at 11:25:35AM -0700, Palmer Dabbelt wrote: > Reviewed-by: Palmer Dabbelt > Acked-by: Palmer Dabbelt > > I'm not wed to any particular encoding for the properties, IMO that's more > of a decision for the DT folks. IMO the important bit is to just get away > from ISA strings and move towards some tightly-specified properties that > indicate how the HW actually behaves. I'm going to resubmit with Rob's list of strings. I'll keep your tags, since the spirit of the patch will be the same, with enforced meanings for each extension. Cheers, Conor. signature.asc Description: PGP signature
[PATCH] arm: dts: imx8m: move CAAM nodes into common u-boot.dtsi
Move the crypto and sec_jr* nodes from board-specific
u-boot.dtsi files into the common files. Additionally protect the
nodes with ifdef FSL_CAAM as they don't serve any purpose if that is
not enabled.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 16 ---
.../dts/imx8mm-kontron-bl-common-u-boot.dtsi | 16 ---
arch/arm/dts/imx8mm-u-boot.dtsi | 20 +++
arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 16 ---
arch/arm/dts/imx8mn-u-boot.dtsi | 20 +++
arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi| 16 ---
arch/arm/dts/imx8mp-evk-u-boot.dtsi | 16 ---
.../imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi | 16 ---
arch/arm/dts/imx8mp-u-boot.dtsi | 20 +++
.../dts/imx8mp-verdin-wifi-dev-u-boot.dtsi| 16 ---
10 files changed, 60 insertions(+), 112 deletions(-)
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index 155670da18d1..9a5b0795133b 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -65,22 +65,6 @@
bootph-pre-ram;
};
- {
- bootph-pre-ram;
-};
-
-_jr0 {
- bootph-pre-ram;
-};
-
-_jr1 {
- bootph-pre-ram;
-};
-
-_jr2 {
- bootph-pre-ram;
-};
-
{
bootph-pre-ram;
};
diff --git a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
index 1ad9d49a1118..ae542fdcffad 100644
--- a/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-bl-common-u-boot.dtsi
@@ -18,22 +18,6 @@
};
};
- {
- bootph-pre-ram;
-};
-
-_jr0 {
- bootph-pre-ram;
-};
-
-_jr1 {
- bootph-pre-ram;
-};
-
-_jr2 {
- bootph-pre-ram;
-};
-
{
bootph-pre-ram;
bootph-all;
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 61f907a4743b..303a43e63527 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -18,6 +18,12 @@
#endif
};
+#ifdef FSL_CAAM
+ {
+ bootph-pre-ram;
+};
+#endif
+
{
bootph-all;
bootph-pre-ram;
@@ -235,6 +241,20 @@
bootph-pre-ram;
};
+#ifdef FSL_CAAM
+_jr0 {
+ bootph-pre-ram;
+};
+
+_jr1 {
+ bootph-pre-ram;
+};
+
+_jr2 {
+ bootph-pre-ram;
+};
+#endif
+
{
bootph-all;
bootph-pre-ram;
diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
index 315714f39848..c31f3dec3de4 100644
--- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
@@ -57,22 +57,6 @@
bootph-pre-ram;
};
- {
- bootph-pre-ram;
-};
-
-_jr0 {
- bootph-pre-ram;
-};
-
-_jr1 {
- bootph-pre-ram;
-};
-
-_jr2 {
- bootph-pre-ram;
-};
-
{
bootph-pre-ram;
};
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 15cec4ffab44..77b3097d5f52 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -54,6 +54,12 @@
/delete-property/ assigned-clock-rates;
};
+#ifdef FSL_CAAM
+ {
+ bootph-pre-ram;
+};
+#endif
+
{
bootph-pre-ram;
};
@@ -63,6 +69,20 @@
bootph-all;
};
+#ifdef FSL_CAMM
+_jr0 {
+ bootph-pre-ram;
+};
+
+_jr1 {
+ bootph-pre-ram;
+};
+
+_jr2 {
+ bootph-pre-ram;
+};
+#endif
+
{
bootph-pre-ram;
};
diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
index bb0f9bd0c8d3..82e90d743d08 100644
--- a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
@@ -21,10 +21,6 @@
bootph-pre-ram;
};
- {
- bootph-pre-ram;
-};
-
{
/delete-property/ assigned-clocks;
/delete-property/ assigned-clock-parents;
@@ -131,18 +127,6 @@
u-boot,off-on-delay-us = <2>;
};
-_jr0 {
- bootph-pre-ram;
-};
-
-_jr1 {
- bootph-pre-ram;
-};
-
-_jr2 {
- bootph-pre-ram;
-};
-
{
compatible = "tcg,tpm_tis-spi";
};
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index 17965c58ba10..6d9b229989ac 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -65,22 +65,6 @@
bootph-pre-ram;
};
- {
- bootph-pre-ram;
-};
-
-_jr0 {
- bootph-pre-ram;
-};
-
-_jr1 {
- bootph-pre-ram;
-};
-
-_jr2 {
- bootph-pre-ram;
-};
-
{
bootph-pre-ram;
};
diff --git a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
index fe20938af536..cf2a87a9b903 100644
--- a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
@@ -62,22 +62,6 @@
bootph-pre-ram;
};
- {
- bootph-pre-ram;
-};
-
-_jr0 {
-
Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa
On Thu, 08 Jun 2023 09:54:05 PDT (-0700), Conor Dooley wrote: From: Conor Dooley intro = When the RISC-V dt-bindings were accepted upstream in Linux, the base ISA etc had yet to be ratified. By the ratification of the base ISA, incompatible changes had snuck into the specifications - for example the Zicsr and Zifencei extensions were spun out of the base ISA. Fast forward to today, and the reason for this patch. Currently the riscv,isa dt property permits only a specific subset of the ISA string - in particular it excludes version numbering. With the current constraints, it is not possible to discern whether "rv64i" means that the hart supports the fence.i instruction, for example. Future systems may choose to implement their own instruction fencing, perhaps using a vendor extension, or they may not implement the optional counter extensions. Software needs a way to determine this. versioning schemes == "Use the extension versions that are described in the ISA manual" you may say, and it's not like this has not been considered. Firstly, software that parses the riscv,isa property at runtime will need to contain a lookup table of some sort that maps arbitrary versions to versions it understands. There is not a consistent application of version number applied to extensions, with a higgledy-piggledy collection of tags, "bare" and version documents awaiting the reader on the "recently ratified extensions" page: https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions As an aside, this is reflected in the patch too, since many extensions have yet to appear in a release of the ISA specs, and are defined by commits in their respective "working draft" repositories. Secondly, there is an issue of backwards compatibility, whereby allowing numbers in the ISA string, some parsers may be broken. This would require an additional property to be created to even use the versions in this manner. boolean properties == If a new property is needed, the whole approach may as well be looked at from the bottom up. A string with limited character choices etc is hardly the best approach for communicating extension information to software. Switching to using boolean properties, one per extension, allows us to define explicit meanings for the DT representation of each extension - rather than the current situation where different operating systems or other bits of software may impart different meanings to characters in the string. Clearly the best source of meanings is the specifications themselves, this just provides us the ability to choose at what point in time the meaning is set. If an extension changes incompatibility in the future, a new property will be required. Off-list, some of the RVI folks have committed to shoring up the wording in either the ISA specifications, the riscv-isa-manual or so that in the future, modifications to and additions or removals of features will require a new extension. Codifying that assertion somewhere would make it quite unlikely that compatibility would be broken, but we have the tools required to deal with it, if & when it crops up. It is in our collective interest, as consumers of extension meanings, to define a scheme that enforces compatibility. The use of boolean properties, rather than elements in a string, will also permit validation that the strings have a meaning, as well as potentially reject mutually exclusive combinations, or enforce dependencies between instructions. That would not be possible with the current dt-schema infrastructure for arbitrary strings, as we would need to add a riscv,isa parser to dt-validate! That's not implemented in this patch, but rather left as future work (for the brave, or the foolish). acpi The current ACPI ECR is based on having a string unfortunately, but ideally ACPI will move to another method, perhaps GUIDs, that give explicit meaning to extensions. parser simplicity = Many systems that parse DT at runtime already implement an function that can check for the presence of boolean properties, rather than having to implement - although unfortunately for backwards compatibility with old dtbs, existing parsers may not be removable - which may greatly simplify dt parsing code. For example, in Linux, checking for an extension becomes as simple as: of_property_present(extension_node, "zicbom") vendor extensions = Compared to riscv,isa, this proposed scheme promotes vendor extensions, oft touted as the strength of RISC-V, to first-class citizens. At present, extensions are defined as meaning what the RISC-V ISA specifications say they do. There is no realistic way of using that interface to provide cross-platform definitions for what vendor extensions mean. Vendor extensions may also have even less consistency than RVI do in terms of versioning, or no care about backwards compatibility. A boolean property allows us to
[PATCH] arm: dts: imx8m: add OPTEE_LOAD_ADDRESS config and tee.bin
Add a Kconfig for OPTEE_LOAD_ADDRESS which adds tee.bin to the
imx8m{m,n,p} FIT image.
Prior to using binman for image creation the presense of tee.bin in the
directory would cause mkimage_fit_atf.sh to add the tee.bin node
to the FIT image. Once boards moved away from using
CONFIG_SPL_FIT_GENERATOR this was lost. This patch restores that
functionality. A Kconfig option is added due to binman not being
able to utilize env variables.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-u-boot.dtsi | 19 +++
arch/arm/dts/imx8mn-u-boot.dtsi | 19 +++
arch/arm/dts/imx8mp-u-boot.dtsi | 19 +++
drivers/tee/optee/Kconfig | 7 +++
4 files changed, 64 insertions(+)
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index a843bb851eaf..61f907a4743b 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -124,6 +124,21 @@
type = "atf-bl31";
};
};
+
+#ifdef CONFIG_OPTEE_LOAD_ADDRESS
+ tee {
+ description = "TEE firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+ entry = ;
+
+ tee_blob: blob-ext {
+ filename = "tee.bin";
+ };
+ };
+#endif
#endif
binman_fip: fip {
@@ -154,7 +169,11 @@
fdt = "fdt-SEQ";
firmware = "uboot";
#ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE_LOAD_ADDRESS
+ loadables = "atf", "tee";
+#else
loadables = "atf";
+#endif
#endif
};
};
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 86c9a6cd67f0..15cec4ffab44 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -181,6 +181,21 @@
type = "atf-bl31";
};
};
+
+#ifdef CONFIG_OPTEE_LOAD_ADDRESS
+ tee {
+ description = "TEE firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+ entry = ;
+
+ tee_blob: blob-ext {
+ filename = "tee.bin";
+ };
+ };
+#endif
#endif
binman_fip: fip {
@@ -211,7 +226,11 @@
fdt = "fdt-SEQ";
firmware = "uboot";
#ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE_LOAD_ADDRESS
+ loadables = "atf", "tee";
+#else
loadables = "atf";
+#endif
#endif
};
};
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index 8c9d6412ccb5..b46fc7eeed0d 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -145,6 +145,21 @@
type = "atf-bl31";
};
};
+
+#ifdef CONFIG_OPTEE_LOAD_ADDRESS
+ tee {
+ description = "TEE firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+ entry = ;
+
+ tee_blob: blob-ext {
+ filename = "tee.bin";
+ };
+ };
+#endif
#endif
@fdt-SEQ {
@@ -166,7 +181,11 @@
fdt = "fdt-SEQ";
firmware = "uboot";
#ifndef CONFIG_ARMV8_PSCI
+#ifdef CONFIG_OPTEE_LOAD_ADDRESS
+ loadables = "atf", "tee";
+#else
Re: [PATCH v1 1/2] meson-a1: dts: add hw rng node
On 21/06/2023 15:29, Alexey Romanov wrote:
Add support for hardware random number generator
of Amlogic Meson SoCs.
Signed-off-by: Alexey Romanov
---
arch/arm/dts/meson-a1.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/meson-a1.dtsi b/arch/arm/dts/meson-a1.dtsi
index f3560cbc3a4..1f57c137384 100644
--- a/arch/arm/dts/meson-a1.dtsi
+++ b/arch/arm/dts/meson-a1.dtsi
@@ -140,6 +140,11 @@
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
+
+ hwrng: rng@5118 {
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0x5118 0x0 0x4>;
+ };
};
gic: interrupt-controller@ff901000 {
Weird, you introduced amlogic,meson-rng-s4 previously but you don't use it here
?
Anyway please add those to Linux first, them sync the DT to u-boot afterwards,
Thanks,
Neil
Re: [PATCH v1] drivers: rng: add check status bit feature
Hi,
On 21/06/2023 12:24, Alexey Romanov wrote:
For some Amlogic SOC's, the mechanism for obtain a random number
has been changed. For example, S4 now uses a status bit wait algo.
Thanks for the change, but could you add this first in Linux with the
associated bindings update and DT changes then port it to U-boot ?
Thanks,
Neil
Signed-off-by: Alexey Romanov
---
drivers/rng/meson-rng.c | 73 +
1 file changed, 67 insertions(+), 6 deletions(-)
diff --git a/drivers/rng/meson-rng.c b/drivers/rng/meson-rng.c
index e0a1e8c7e04..3bf2eb9cf87 100644
--- a/drivers/rng/meson-rng.c
+++ b/drivers/rng/meson-rng.c
@@ -11,36 +11,82 @@
#include
#include
+struct meson_rng_data {
+ bool check_status_bit;
+};
+
struct meson_rng_plat {
fdt_addr_t base;
struct clk clk;
+ struct meson_rng_data *data;
};
+#define RETRY_CNT 100
+#define RNG_OUT_OFFSET 0x08
+
+#define SEED_READY_STS_BIT 0
+#define RUN_BIT 31
+
+static int meson_rng_wait_status(struct meson_rng_plat *pdata, int bit)
+{
+ u32 status;
+ u32 cnt = 0;
+
+ pr_debug("Poll status of bit: %d\n", bit);
+
+ do {
+ status = readl(pdata->base) & BIT(bit);
+ } while (status && (cnt++ < RETRY_CNT));
+
+ if (cnt == RETRY_CNT) {
+ pr_err("Can't get random number, try again");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
/**
* meson_rng_read() - fill buffer with random bytes
*
* @buffer: buffer to receive data
* @size: size of buffer
*
- * Return: 0
+ * Return: 0 on success or -errno in failure
*/
static int meson_rng_read(struct udevice *dev, void *data, size_t len)
{
struct meson_rng_plat *pdata = dev_get_plat(dev);
+ struct meson_rng_data *rng_data = pdata->data;
char *buffer = (char *)data;
+ int err;
while (len) {
- u32 rand = readl(pdata->base);
+ u32 rand;
size_t step;
- if (len >= 4)
- step = 4;
- else
- step = len;
+ if (rng_data->check_status_bit) {
+ writel(readl(pdata->base) | BIT(SEED_READY_STS_BIT),
pdata->base);
+
+ err = meson_rng_wait_status(pdata, SEED_READY_STS_BIT);
+ if (err)
+ return err;
+
+ err = meson_rng_wait_status(pdata, RUN_BIT);
+ if (err)
+ return err;
+
+ rand = readl(pdata->base + RNG_OUT_OFFSET);
+ } else {
+ rand = readl(pdata->base);
+ }
+
+ step = min_t(u32, len, 4);
memcpy(buffer, , step);
buffer += step;
len -= step;
}
+
return 0;
}
@@ -90,6 +136,8 @@ static int meson_rng_of_to_plat(struct udevice *dev)
if (!pdata->base)
return -ENODEV;
+ pdata->data = (struct meson_rng_data *)dev_get_driver_data(dev);
+
/* Get optional "core" clock */
err = clk_get_by_name_optional(dev, "core", >clk);
if (err)
@@ -102,9 +150,22 @@ static const struct dm_rng_ops meson_rng_ops = {
.read = meson_rng_read,
};
+static const struct meson_rng_data meson_rng_data = {
+ .check_status_bit = false,
+};
+
+static const struct meson_rng_data meson_rng_data_s4 = {
+ .check_status_bit = true,
+};
+
static const struct udevice_id meson_rng_match[] = {
{
.compatible = "amlogic,meson-rng",
+ .data = (ulong)_rng_data,
+ },
+ {
+ .compatible = "amlogic,meson-rng-s4",
+ .data = (ulong)_rng_data_s4,
},
{},
};
Re: [PATCH v2 0/2] Fix 'no USB device found' error.
On Thu, Jun 22, 2023 at 04:34:34PM +0200, Julien Panis wrote: > This series fixes usb0 dr_mode for am335x-icev2 > and am335x-evmsk. It must be set to 'peripheral' > in order to avoid 'no USB device found' error, > in usb_ether_init() function. > > Signed-off-by: Julien Panis > --- > Changes in v2: > - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c > - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' > and 'am335x-evmsk-u-boot.dtsi' device trees. > - Link to v1: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com > > --- > Julien Panis (2): > arm: dts: am335x-icev2-u-boot: Configure peripheral mode for usb0 > arm: dts: am335x-evmsk-u-boot: Configure peripheral mode for usb0 > > arch/arm/dts/am335x-evmsk-u-boot.dtsi | 4 > arch/arm/dts/am335x-icev2-u-boot.dtsi | 4 > 2 files changed, 8 insertions(+) I'll ask the first question that Nishanth might also ask, which is why don't these belong in the kernel dts files? Thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/1] doc: bind man-page
provide a man-page for the bind command
Signed-off-by: Heinrich Schuchardt
---
doc/usage/cmd/bind.rst | 103 +
doc/usage/index.rst| 1 +
2 files changed, 104 insertions(+)
create mode 100644 doc/usage/cmd/bind.rst
diff --git a/doc/usage/cmd/bind.rst b/doc/usage/cmd/bind.rst
new file mode 100644
index 00..1a5cffcb72
--- /dev/null
+++ b/doc/usage/cmd/bind.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+bind command
+
+
+Synopsis
+
+
+::
+
+bind
+bind
+
+Description
+---
+
+The bind command is used to bind a device to a driver. This makes the
+device available in U-Boot.
+
+While binding to a *node path* typically provides a working device
+binding by parent node and driver may lead to a device that is only
+partially initialized.
+
+node path
+path of the device's device-tree node
+
+class
+device class name
+
+index
+index of the parent device in the device class
+
+driver
+device driver name
+
+Example
+---
+
+Given a system with a real time clock device with device path */pl031@901*
+and using driver rtc-pl031 unbinding and binding of the device is demonstrated
+using the two alternative bind syntaxes.
+
+.. code-block::
+
+=> dm tree
+ Class Index Probed DriverName
+---
+ root 0 [ + ] root_driver root_driver
+...
+ rtc 0 [ ] rtc-pl031 |-- pl031@901
+...
+=> fdt addr $fdtcontroladdr
+Working FDT set to 7ed7fdb0
+=> fdt print
+/ {
+interrupt-parent = <0x8003>;
+model = "linux,dummy-virt";
+#size-cells = <0x0002>;
+#address-cells = <0x0002>;
+compatible = "linux,dummy-virt";
+...
+pl031@901 {
+clock-names = "apb_pclk";
+clocks = <0x8000>;
+interrupts = <0x 0x0002 0x0004>;
+reg = <0x 0x0901 0x 0x1000>;
+compatible = "arm,pl031", "arm,primecell";
+};
+...
+}
+=> unbind /pl031@901
+=> date
+Cannot find RTC: err=-19
+=> dm tree
+ Class Index Probed DriverName
+---
+ root 0 [ + ] root_driver root_driver
+...
+=> bind /pl031@901 rtc-pl031
+=> dm tree
+ Class Index Probed DriverName
+---
+ root 0 [ + ] root_driver root_driver
+...
+ rtc 0 [ ] rtc-pl031 |-- pl031@901
+=> date
+Date: 2023-06-22 (Thursday)Time: 15:14:51
+=> unbind rtc 0 rtc-pl031
+=> bind root 0 rtc-pl031
+=> date
+Date: 1980-08-19 (Tuesday)Time: 14:45:30
+
+Obviously the device is not initialized correctly by the last bind command.
+
+Configuration
+-
+
+The bind command is only available if CONFIG_CMD_BIND=y.
+
+Return code
+---
+
+The return code $? is 0 (true) on success and 1 (false) on failure.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 95532782e0..a11c5756f0 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -25,6 +25,7 @@ Shell commands
cmd/askenv
cmd/base
cmd/bdinfo
+ cmd/bind
cmd/blkcache
cmd/bootd
cmd/bootdev
--
2.40.1
Re: [PATCH v4 3/3] usb: ohci-at91: Add USB PHY functionality
On 6/22/23 15:07, Eugen Hristev wrote:
From: Sergiu Moga
Add the ability to enable/disable whatever USB PHY's are
passed to the AT91 OHCI driver through DT.
Signed-off-by: Sergiu Moga
Tested-by: Mihai Sain
Reviewed-by: Marek Vasut
[eugen.hris...@collabora.com: disable PHYs in at91_start_clock if
clk_enable_bulk fails]
Signed-off-by: Eugen Hristev
---
v1 -> v2:
- use *_bulk API's
v2 -> v3:
- use if (CONFIG_IS_ENABLED(...))
v3 -> v4
[eugen.hris...@collabora.com: disable PHYs in at91_start_clock if
clk_enable_bulk fails]
drivers/usb/host/ohci-at91.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 92d0ab7184c4..3d4f31d240aa 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -73,6 +73,7 @@ int usb_cpu_init_fail(void)
#include
#include
#include "ohci.h"
+#include
#define AT91_MAX_USBH_PORTS3
@@ -90,15 +91,36 @@ struct at91_usbh_data {
struct ohci_at91_priv {
ohci_t ohci;
struct clk_bulk clks;
+ struct phy_bulk phys;
};
static int at91_start_clock(struct ohci_at91_priv *ohci_at91)
{
- return clk_enable_bulk(_at91->clks);
+ int ret;
+
+ if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+ ret = generic_phy_power_on_bulk(_at91->phys);
+ if (ret)
+ return ret;
+ }
+
+ ret = clk_enable_bulk(_at91->clks);
+ if (ret)
+ generic_phy_power_off_bulk(_at91->phys);
A fail path (goto err;) would be nicer here.
+ return ret;
}
static int at91_stop_clock(struct ohci_at91_priv *ohci_at91)
{
+ if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+ int ret;
+
+ ret = generic_phy_power_off_bulk(_at91->phys);
+ if (ret)
+ return ret;
Shouldn't this one ignore the return value and instead proceed to
disable clock below ?
+ }
+
return clk_disable_bulk(_at91->clks);
}
Re: [PATCH v4 1/3] phy: at91: Add support for the USB 2.0 PHY's of SAMA7
On 6/22/23 15:06, Eugen Hristev wrote: From: Sergiu Moga In order to have USB functionality, drivers for SAMA7's USB 2.0 PHY's have been added. There is one driver for UTMI clock's SFR and RESET required functionalities and one for its three possible subclocks of the phy's themselves. In order for this layout to properly work in conjunction with CCF and DT, the former driver will also act as a clock provider for the three phy's with the help of a custom hook into the driver's of_xlate method. Signed-off-by: Sergiu Moga Tested-by: Mihai Sain Reviewed-by: Marek Vasut
Re: [PATCH v4 2/3] usb: ohci-at91: Enable OHCI functionality and register into DM
On 6/22/23 15:07, Eugen Hristev wrote: From: Sergiu Moga Register the OHCI driver into DM by properly initializing the required clocks and pins required by the DT node of OHCI. In order for the VBUS to stay enabled, a `child_pre_probe` method has been added to overcome the DM core disabling it in `usb_scan_device`: when the generic `device_probe` method is called, the pinctrl is processed once again, undoing whatever changes have been made in our driver's probe method. Furthermore, enable CONFIG_DM_GPIO whenever this driver and CONFIG_DM_USB are selected. Signed-off-by: Sergiu Moga Reviewed-by: Marek Vasut
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/22/23 15:33, Michal Simek wrote:
On 6/20/23 22:41, Tom Rini wrote:
On Tue, Jun 20, 2023 at 08:36:11AM +0200, Michal Simek wrote:
On 6/19/23 19:04, Eugen Hristev wrote:
On 6/19/23 19:07, Marek Vasut wrote:
On 6/19/23 15:26, Eugen Hristev wrote:
On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note
that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop
executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to
detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/core.c | 50
+++--
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc,
u32 mode)
static int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
+ int retries = 1000;
- /* Before Resetting PHY, put Core in Reset */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg |= DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
- /* Assert USB3 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
- reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
- /* Assert USB2 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
- mdelay(100);
-
- /* Clear USB3 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
- reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
- /* Clear USB2 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ /*
+ * We're resetting only the device side because, if we're in
host mode,
+ * XHCI driver will reset the host block. If dwc3 was
configured for
+ * host-only mode, then we can return early.
+ */
+ if (dwc->dr_mode == USB_DR_MODE_HOST)
+ return 0;
- mdelay(100);
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
- /* After PHYs are stable we can take Core out of reset state */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg &= ~DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ return 0;
+ udelay(1);
+ } while (--retries);
- return 0;
+ return -ETIMEDOUT;
}
/*
Hello Venkatesh, Michal,
I randomly found this patch while testing the Dwc3 on rockchip
RK3588 , I noticed that you removed the code that resets the
PHYs in this patch hence DWC3 is no longer starting in my case.
Was this intentional with this patch ?
All of these patches are NAK until the DWC3 is synchronized with
Linux. Picking random DWC3 patches and ignoring other fixes will
turn the whole driver into an unmaintainable mess and make the sync
that much harder in the future. I spent enormous amount of my spare
time trying to explain to Xilinx how to do that mostly
automatically, but that was all ignored or countered with reason
after reason why this cannot be done, but as far as I can tell,
nobody in Xilinx actually tried the proposal.
Hence, NAK
Hence, no need to worry these patches will be applied in their
current state.
Hi Marek,
that's fine. No argument from my side.
What I wanted to actually tell/ask , is the fact that this patch
actually helps in my case, just that it breaks something else, and I
wanted to get more info from the patch authors.
I am experiencing some situations where dwc3 does not correctly start
unless I add some manual delays here and there, and I am trying to see
why.
It is not just about dwc3. There are other parts which are ported
from Linux
kernel and are out of sync from Linux kernel for quite a long time.
Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.
Yes, various parts of the stack could use some re-syncing with upstream.
And I forget if
[PATCH v2 2/2] arm: dts: am335x-evmsk-u-boot: Configure peripheral mode for usb0
This patch configures usb0 dr_mode as peripheral
on am335x-evmsk board.
Signed-off-by: Julien Panis
---
arch/arm/dts/am335x-evmsk-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-evmsk-u-boot.dtsi
b/arch/arm/dts/am335x-evmsk-u-boot.dtsi
index 669cb6bf1655..010005c45091 100644
--- a/arch/arm/dts/am335x-evmsk-u-boot.dtsi
+++ b/arch/arm/dts/am335x-evmsk-u-boot.dtsi
@@ -20,3 +20,7 @@
};
};
};
+
+ {
+ dr_mode = "peripheral";
+};
--
2.37.3
[PATCH v2 0/2] Fix 'no USB device found' error.
This series fixes usb0 dr_mode for am335x-icev2 and am335x-evmsk. It must be set to 'peripheral' in order to avoid 'no USB device found' error, in usb_ether_init() function. Signed-off-by: Julien Panis --- Changes in v2: - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' and 'am335x-evmsk-u-boot.dtsi' device trees. - Link to v1: https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com --- Julien Panis (2): arm: dts: am335x-icev2-u-boot: Configure peripheral mode for usb0 arm: dts: am335x-evmsk-u-boot: Configure peripheral mode for usb0 arch/arm/dts/am335x-evmsk-u-boot.dtsi | 4 arch/arm/dts/am335x-icev2-u-boot.dtsi | 4 2 files changed, 8 insertions(+) --- base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f change-id: 20230621-fix_usb_ether_init-4bf4f1135113 Best regards, -- Julien Panis
[PATCH v2 1/2] arm: dts: am335x-icev2-u-boot: Configure peripheral mode for usb0
This patch configures usb0 dr_mode as peripheral
on am335x-icev2 board.
Signed-off-by: Julien Panis
---
arch/arm/dts/am335x-icev2-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/am335x-icev2-u-boot.dtsi
b/arch/arm/dts/am335x-icev2-u-boot.dtsi
index 67bfac916eee..7dcd5ec00605 100644
--- a/arch/arm/dts/am335x-icev2-u-boot.dtsi
+++ b/arch/arm/dts/am335x-icev2-u-boot.dtsi
@@ -22,3 +22,7 @@
xtal-load-pf = <0>;
};
};
+
+ {
+ dr_mode = "peripheral";
+};
--
2.37.3
RE: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state
> -Original Message- > From: Marek Vasut > Sent: Thursday, 22 June, 2023 5:35 PM > To: Lim, Jit Loon ; u-boot@lists.denx.de > Cc: Jagan Teki ; Simon > ; Chee, Tien Fong > ; Hea, Kok Kiang ; > Lokanathan, Raaj ; Maniyam, Dinesh > ; Ng, Boon Khai ; > Yuslaimi, Alif Zakuan ; Chong, Teik Heng > ; Zamri, Muhammad Hazim Izzat > ; Tang, Sieu Mun > ; Bin Meng ; Michal Simek > ; Tom Rini ; Eugen Hristev > > Subject: Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 > controller register access in reset state > > On 6/22/23 04:48, Lim, Jit Loon wrote: > >> -Original Message- > >> From: Marek Vasut > >> Sent: Wednesday, 21 June, 2023 10:19 PM > >> To: Lim, Jit Loon ; u-boot@lists.denx.de > >> Cc: Jagan Teki ; Simon > >> ; Chee, Tien Fong > >> ; Hea, Kok Kiang ; > >> Lokanathan, Raaj ; Maniyam, Dinesh > >> ; Ng, Boon Khai ; > >> Yuslaimi, Alif Zakuan ; Chong, Teik > >> Heng ; Zamri, Muhammad Hazim Izzat > >> ; Tang, Sieu Mun > >> ; Bin Meng > >> Subject: Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 > >> controller register access in reset state > >> > >> On 6/21/23 16:11, Jit Loon Lim wrote: > >>> From: Teik Heng Chong > >>> > >>> The controller registers should not be accessed while the > >>> controller's vcc_reset_n is asserted. > >>> > >>> Signed-off-by: Teik Heng Chong > >> > >> Is this patch ported from Linux or is this custom development ? > >> > >> Is there a matching patch/fix in Linux already ? > > > > In xhci_dwc3_probe(), the program sequence is vcc reset -> clk init -> > > phy setup -> xhci_register therefore, when xhci_dwc3_remove is called, > > the proper usb stop sequence should be xhci_register _> phy setup -> > > clk init -> vcc reset > > > > if we look at linux driver > > https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-o > > f-simple.c#L33 > > > > dwc3_of_simple_probe: The sequence is reset -> clock > > __dwc3_of_simple_teardown: Then, clock -> reset > > > > So based on the above, we have made changes and the uboot fix is now > aligned with linux driver. > > Instead of adding random patches to the U-Boot dwc3 driver, please just > synchronize the driver with Linux. You should be able to add the missing > patches to the DWC3 driver from Linux since the last synchronization point, > the > process should be largely mechanical. Make sure to include commit ID of each > Linux commit in the new matching U-Boot patch. > > It shouldn't be difficult, one approach I can think of is roughly this: > - figure out the original merge base from which the DWC3 driver was imported > to U-Boot > - in U-Boot, revert all dwc3 patches on top of that import patch > - pick all Linux kernel dwc3 patches from that merge base and apply on top of > this U-Boot with reverts > - Run rebase and drop the reverts, let git drop duplicate patches We believed the previous reply from us is a bit confusing. There is no exact same function/file for U-Boot to use in Linux. What we are doing is, we are referring to Linux sequence. Linux: (dwc3_of_simple_probe) https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-of-simple.c#L33 U-Boot: (xhci_dwc3_probe) https://elixir.bootlin.com/u-boot/latest/source/drivers/usb/host/xhci-dwc3.c#L159 Linux: (__dwc3_of_simple_teardown) https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-of-simple.c#L98 U-Boot: (xhci_dwc3_remove) https://elixir.bootlin.com/u-boot/latest/source/drivers/usb/host/xhci-dwc3.c#L227 So we believed that we can't directly pickup all Linux kernel dwc3 patches and merge to U-Boot.
Re: [PATCH v2 0/2] common/memsize.c: Fix get_ram_size() when cache is enabled
On Tue, 30 May 2023 15:33:25 +0200, Francesco Dolcini wrote: > From: Francesco Dolcini > > Ensure that every write is flushed to memory and afterward reads are > from memory. > Since the algorithm rely on the fact that accessing to not existent > memory lead to write at addr / 2 without this modification accesses > to aliased (not physically present) addresses are cached and > wrong size is returned. > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH v1] mtd: nand: raw: rockchip_nfc: copy hwecc PA data to oob_poi buffer
Rockchip boot blocks are written per 4 x 512 byte sectors per page.
Each page must have a page address (PA) pointer in OOB to the next page.
Pages are written in a pattern depending on the NAND chip ID.
This logic used to build a page pattern table is not fully disclosed and
is not easy to fit in the MTD framework.
The formula in rk_nfc_write_page_hwecc() function is not correct.
Make hwecc and raw behavior identical.
Generate boot block page address and pattern for hwecc in user space
and copy PA data to/from the already reserved last 4 bytes before EEC
in the chip->oob_poi data layout.
Signed-off-by: Johan Jonker
---
drivers/mtd/nand/raw/rockchip_nfc.c | 34 ++---
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/rockchip_nfc.c
b/drivers/mtd/nand/raw/rockchip_nfc.c
index 5fcf6a6b..274489ec 100644
--- a/drivers/mtd/nand/raw/rockchip_nfc.c
+++ b/drivers/mtd/nand/raw/rockchip_nfc.c
@@ -525,7 +525,7 @@ static int rk_nfc_write_page_hwecc(struct mtd_info *mtd,
int pages_per_blk = mtd->erasesize / mtd->writesize;
int ret = 0, i, boot_rom_mode = 0;
dma_addr_t dma_data, dma_oob;
- u32 reg;
+ u32 tmp;
u8 *oob;
nand_prog_page_begin_op(chip, page, 0, NULL, 0);
@@ -552,6 +552,13 @@ static int rk_nfc_write_page_hwecc(struct mtd_info *mtd,
*
* 0xFF 0xFF 0xFF 0xFF | BBM OOB1 OOB2 OOB3 | ...
*
+* The code here just swaps the first 4 bytes with the last
+* 4 bytes without losing any data.
+*
+* The chip->oob_poi data layout:
+*
+*BBM OOB1 OOB2 OOB3 |..| PA0 PA1 PA2 PA3
+*
* Configure the ECC algorithm supported by the boot ROM.
*/
if (page < (pages_per_blk * rknand->boot_blks)) {
@@ -561,21 +568,17 @@ static int rk_nfc_write_page_hwecc(struct mtd_info *mtd,
}
for (i = 0; i < ecc->steps; i++) {
- if (!i) {
- reg = 0x;
- } else {
+ if (!i)
+ oob = chip->oob_poi + (ecc->steps - 1) *
NFC_SYS_DATA_SIZE;
+ else
oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE;
- reg = oob[0] | oob[1] << 8 | oob[2] << 16 |
- oob[3] << 24;
- }
- if (!i && boot_rom_mode)
- reg = (page & (pages_per_blk - 1)) * 4;
+ tmp = oob[0] | oob[1] << 8 | oob[2] << 16 | oob[3] << 24;
if (nfc->cfg->type == NFC_V9)
- nfc->oob_buf[i] = reg;
+ nfc->oob_buf[i] = tmp;
else
- nfc->oob_buf[i * (oob_step / 4)] = reg;
+ nfc->oob_buf[i * (oob_step / 4)] = tmp;
}
dma_data = dma_map_single((void *)nfc->page_buf,
@@ -720,12 +723,17 @@ static int rk_nfc_read_page_hwecc(struct mtd_info *mtd,
goto timeout_err;
}
- for (i = 1; i < ecc->steps; i++) {
- oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE;
+ for (i = 0; i < ecc->steps; i++) {
+ if (!i)
+ oob = chip->oob_poi + (ecc->steps - 1) *
NFC_SYS_DATA_SIZE;
+ else
+ oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE;
+
if (nfc->cfg->type == NFC_V9)
tmp = nfc->oob_buf[i];
else
tmp = nfc->oob_buf[i * (oob_step / 4)];
+
*oob++ = (u8)tmp;
*oob++ = (u8)(tmp >> 8);
*oob++ = (u8)(tmp >> 16);
--
2.30.2
Re: [UBOOT PATCH 1/3] usb: dwc3: core: improve reset sequence
On 6/20/23 22:41, Tom Rini wrote:
On Tue, Jun 20, 2023 at 08:36:11AM +0200, Michal Simek wrote:
On 6/19/23 19:04, Eugen Hristev wrote:
On 6/19/23 19:07, Marek Vasut wrote:
On 6/19/23 15:26, Eugen Hristev wrote:
On 5/8/23 06:00, Venkatesh Yadav Abbarapu wrote:
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/core.c | 50 +++--
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 49f6a1900b..8702a54efa 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,42 +60,28 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
static int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
+ int retries = 1000;
- /* Before Resetting PHY, put Core in Reset */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg |= DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
- /* Assert USB3 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
- reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
- /* Assert USB2 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
- mdelay(100);
-
- /* Clear USB3 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
- reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
- /* Clear USB2 PHY reset */
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+ /*
+ * We're resetting only the device side because, if we're in host mode,
+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode, then we can return early.
+ */
+ if (dwc->dr_mode == USB_DR_MODE_HOST)
+ return 0;
- mdelay(100);
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
- /* After PHYs are stable we can take Core out of reset state */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg &= ~DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ return 0;
+ udelay(1);
+ } while (--retries);
- return 0;
+ return -ETIMEDOUT;
}
/*
Hello Venkatesh, Michal,
I randomly found this patch while testing the Dwc3 on rockchip
RK3588 , I noticed that you removed the code that resets the
PHYs in this patch hence DWC3 is no longer starting in my case.
Was this intentional with this patch ?
All of these patches are NAK until the DWC3 is synchronized with
Linux. Picking random DWC3 patches and ignoring other fixes will
turn the whole driver into an unmaintainable mess and make the sync
that much harder in the future. I spent enormous amount of my spare
time trying to explain to Xilinx how to do that mostly
automatically, but that was all ignored or countered with reason
after reason why this cannot be done, but as far as I can tell,
nobody in Xilinx actually tried the proposal.
Hence, NAK
Hence, no need to worry these patches will be applied in their current state.
Hi Marek,
that's fine. No argument from my side.
What I wanted to actually tell/ask , is the fact that this patch
actually helps in my case, just that it breaks something else, and I
wanted to get more info from the patch authors.
I am experiencing some situations where dwc3 does not correctly start
unless I add some manual delays here and there, and I am trying to see
why.
It is not just about dwc3. There are other parts which are ported from Linux
kernel and are out of sync from Linux kernel for quite a long time.
Another example is xhci - kernel 3.4.
I am little bit worried that the whole usb stack is out of sync.
Yes, various parts of the stack could use some re-syncing with upstream.
And I forget if xhci is one of the parts that's done in such a way that
[PATCH v4 2/3] usb: ohci-at91: Enable OHCI functionality and register into DM
From: Sergiu Moga
Register the OHCI driver into DM by properly initializing the required
clocks and pins required by the DT node of OHCI. In order for the VBUS
to stay enabled, a `child_pre_probe` method has been added to overcome
the DM core disabling it in `usb_scan_device`: when the generic
`device_probe` method is called, the pinctrl is processed once again,
undoing whatever changes have been made in our driver's probe method.
Furthermore, enable CONFIG_DM_GPIO whenever this driver and CONFIG_DM_USB
are selected.
Signed-off-by: Sergiu Moga
---
v1 -> v2:
- squashed 3/4 into this patch
- removed bool clocked
- use *_blk API's
- select DM_GPIO in Kconfig if DM_USB enabled
- use dev_read_u32_default
v2 -> v3:
- check value of dev_read_addr
- clk_disable in case of failure after at91_start_hc
v3->v4:
none
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ohci-at91.c | 159 +++
2 files changed, 160 insertions(+)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1a883babf4c2..e9551a74bb23 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -437,6 +437,7 @@ config USB_ATMEL
depends on ARCH_AT91
select SYS_USB_OHCI_CPU_INIT
select USB_OHCI_NEW
+ select DM_GPIO if DM_USB
choice
prompt "Clock for OHCI"
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9b955c1bd678..92d0ab7184c4 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -5,6 +5,9 @@
*/
#include
+
+#if !(CONFIG_IS_ENABLED(DM_USB))
+
#include
int usb_cpu_init(void)
@@ -62,3 +65,159 @@ int usb_cpu_init_fail(void)
{
return usb_cpu_stop();
}
+
+#else
+
+#include
+#include
+#include
+#include
+#include "ohci.h"
+
+#define AT91_MAX_USBH_PORTS3
+
+#define at91_for_each_port(index, ports)
\
+ for ((index) = 0;
\
+(index) < min_t(u32, AT91_MAX_USBH_PORTS, (ports));
\
+(index)++)
+
+struct at91_usbh_data {
+ enum usb_init_type init_type;
+ struct gpio_desc vbus_pin[AT91_MAX_USBH_PORTS];
+ u32 ports; /* number of ports on root hub
*/
+};
+
+struct ohci_at91_priv {
+ ohci_t ohci;
+ struct clk_bulk clks;
+};
+
+static int at91_start_clock(struct ohci_at91_priv *ohci_at91)
+{
+ return clk_enable_bulk(_at91->clks);
+}
+
+static int at91_stop_clock(struct ohci_at91_priv *ohci_at91)
+{
+ return clk_disable_bulk(_at91->clks);
+}
+
+static void ohci_at91_set_power(struct at91_usbh_data *pdata, int port,
+ bool enable)
+{
+ if (!dm_gpio_is_valid(>vbus_pin[port]))
+ return;
+
+ if (enable)
+ dm_gpio_set_dir_flags(>vbus_pin[port],
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+ else
+ dm_gpio_set_dir_flags(>vbus_pin[port], 0);
+}
+
+static int at91_start_hc(struct udevice *dev)
+{
+ struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+
+ return at91_start_clock(ohci_at91);
+}
+
+static int at91_stop_hc(struct udevice *dev)
+{
+ struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+
+ return at91_stop_clock(ohci_at91);
+}
+
+static int ohci_atmel_deregister(struct udevice *dev)
+{
+ struct at91_usbh_data *pdata = dev_get_plat(dev);
+ int ret, i;
+
+ ret = at91_stop_hc(dev);
+ if (ret)
+ return ret;
+
+ at91_for_each_port(i, pdata->ports)
+ ohci_at91_set_power(pdata, i, false);
+
+ return ohci_deregister(dev);
+}
+
+static int ohci_atmel_child_pre_probe(struct udevice *dev)
+{
+ struct udevice *ohci_controller = dev_get_parent(dev);
+ struct at91_usbh_data *pdata = dev_get_plat(ohci_controller);
+ int i;
+
+ at91_for_each_port(i, pdata->ports)
+ ohci_at91_set_power(pdata, i, true);
+
+ return 0;
+}
+
+static int ohci_atmel_probe(struct udevice *dev)
+{
+ struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+ struct at91_usbh_data *pdata = dev_get_plat(dev);
+ struct ohci_regs *regs;
+ int ret;
+ u32 i;
+
+ regs = (struct ohci_regs *)dev_read_addr(dev);
+ if (IS_ERR(regs)) {
+ ret = PTR_ERR(regs);
+ goto fail;
+ }
+
+ pdata->ports = dev_read_u32_default(dev, "num-ports", 3);
+
+ at91_for_each_port(i, pdata->ports)
+ gpio_request_by_name(dev, "atmel,vbus-gpio", i,
+>vbus_pin[i], GPIOD_IS_OUT |
+GPIOD_IS_OUT_ACTIVE);
+
+ ret = clk_get_bulk(dev, _at91->clks);
+ if (ret)
+ goto fail;
+
+ ret = clk_enable_bulk(_at91->clks);
+ if (ret)
+ goto fail;
+
+ ret =
[PATCH v4 3/3] usb: ohci-at91: Add USB PHY functionality
From: Sergiu Moga
Add the ability to enable/disable whatever USB PHY's are
passed to the AT91 OHCI driver through DT.
Signed-off-by: Sergiu Moga
Tested-by: Mihai Sain
Reviewed-by: Marek Vasut
[eugen.hris...@collabora.com: disable PHYs in at91_start_clock if
clk_enable_bulk fails]
Signed-off-by: Eugen Hristev
---
v1 -> v2:
- use *_bulk API's
v2 -> v3:
- use if (CONFIG_IS_ENABLED(...))
v3 -> v4
[eugen.hris...@collabora.com: disable PHYs in at91_start_clock if
clk_enable_bulk fails]
drivers/usb/host/ohci-at91.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 92d0ab7184c4..3d4f31d240aa 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -73,6 +73,7 @@ int usb_cpu_init_fail(void)
#include
#include
#include "ohci.h"
+#include
#define AT91_MAX_USBH_PORTS3
@@ -90,15 +91,36 @@ struct at91_usbh_data {
struct ohci_at91_priv {
ohci_t ohci;
struct clk_bulk clks;
+ struct phy_bulk phys;
};
static int at91_start_clock(struct ohci_at91_priv *ohci_at91)
{
- return clk_enable_bulk(_at91->clks);
+ int ret;
+
+ if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+ ret = generic_phy_power_on_bulk(_at91->phys);
+ if (ret)
+ return ret;
+ }
+
+ ret = clk_enable_bulk(_at91->clks);
+ if (ret)
+ generic_phy_power_off_bulk(_at91->phys);
+
+ return ret;
}
static int at91_stop_clock(struct ohci_at91_priv *ohci_at91)
{
+ if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+ int ret;
+
+ ret = generic_phy_power_off_bulk(_at91->phys);
+ if (ret)
+ return ret;
+ }
+
return clk_disable_bulk(_at91->clks);
}
@@ -185,6 +207,16 @@ static int ohci_atmel_probe(struct udevice *dev)
if (ret)
goto fail;
+ if (CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)) {
+ ret = generic_phy_get_bulk(dev, _at91->phys);
+ if (ret)
+ goto fail;
+
+ ret = generic_phy_init_bulk(_at91->phys);
+ if (ret)
+ goto fail;
+ }
+
ret = at91_start_hc(dev);
if (ret)
goto fail;
--
2.34.1
[PATCH v4 1/3] phy: at91: Add support for the USB 2.0 PHY's of SAMA7
From: Sergiu Moga
In order to have USB functionality, drivers for SAMA7's
USB 2.0 PHY's have been added. There is one driver
for UTMI clock's SFR and RESET required functionalities and
one for its three possible subclocks of the phy's themselves.
In order for this layout to properly work in conjunction with
CCF and DT, the former driver will also act as a clock provider
for the three phy's with the help of a custom hook into the
driver's of_xlate method.
Signed-off-by: Sergiu Moga
Tested-by: Mihai Sain
---
v1 -> v2:
- use *_bulk API's
v2 -> v3:
- use if (CONFIG_IS_ENABLED(...))
v3->v4:
- none
drivers/phy/Kconfig | 10 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-sama7-usb.c | 90 +
drivers/phy/phy-sama7-utmi-clk.c | 216 +++
4 files changed, 317 insertions(+)
create mode 100644 drivers/phy/phy-sama7-usb.c
create mode 100644 drivers/phy/phy-sama7-utmi-clk.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7a2d54f71d21..999f9793fa3f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -281,6 +281,16 @@ config PHY_XILINX_ZYNQMP
Enable this to support ZynqMP High Speed Gigabit Transceiver
that is part of ZynqMP SoC.
+config PHY_MICROCHIP_SAMA7_USB
+ tristate "Microchip SAMA7 USB 2.0 PHY"
+ depends on PHY && ARCH_AT91
+ help
+Enable this to support SAMA7 USB 2.0 PHY.
+
+The USB 2.0 PHY integrates high-speed, full-speed and low-speed
+termination and signal switching. With a single resistor, it
+requires minimal external components.
+
source "drivers/phy/rockchip/Kconfig"
source "drivers/phy/cadence/Kconfig"
source "drivers/phy/ti/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aca365d219c4..0b609768774a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
obj-$(CONFIG_PHY_NPCM_USB) += phy-npcm-usb.o
obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
+obj-$(CONFIG_PHY_MICROCHIP_SAMA7_USB) += phy-sama7-utmi-clk.o phy-sama7-usb.o
obj-y += cadence/
obj-y += ti/
obj-y += qcom/
diff --git a/drivers/phy/phy-sama7-usb.c b/drivers/phy/phy-sama7-usb.c
new file mode 100644
index ..200324d81281
--- /dev/null
+++ b/drivers/phy/phy-sama7-usb.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for Atmel/Microchip USB PHY's.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Sergiu Moga
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sama7_usb_phy {
+ struct clk *uclk;
+ struct regmap *sfr;
+ int port;
+};
+
+static int sama7_usb_phy_init(struct phy *phy)
+{
+ struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+ int port = sama7_phy->port;
+
+ regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
+ SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X,
+ SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X);
+
+ regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
+ SAMA7_SFR_UTMI_RX_VBUS,
+ SAMA7_SFR_UTMI_RX_VBUS);
+
+ return 0;
+}
+
+static int sama7_phy_power_on(struct phy *phy)
+{
+ struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+
+ clk_prepare_enable(sama7_phy->uclk);
+
+ return 0;
+}
+
+static int sama7_phy_power_off(struct phy *phy)
+{
+ struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+
+ clk_disable_unprepare(sama7_phy->uclk);
+
+ return 0;
+}
+
+static int sama7_usb_phy_probe(struct udevice *dev)
+{
+ struct sama7_usb_phy *sama7_phy = dev_get_priv(dev);
+
+ sama7_phy->uclk = devm_clk_get(dev, "utmi_clk");
+ if (IS_ERR(sama7_phy->uclk))
+ return PTR_ERR(sama7_phy->uclk);
+
+ sama7_phy->sfr = syscon_regmap_lookup_by_phandle(dev, "sfr-phandle");
+ if (IS_ERR(sama7_phy->sfr))
+ return PTR_ERR(sama7_phy->sfr);
+
+ return dev_read_u32(dev, "reg", _phy->port);
+}
+
+static const struct phy_ops sama7_usb_phy_ops = {
+ .init = sama7_usb_phy_init,
+ .power_on = sama7_phy_power_on,
+ .power_off = sama7_phy_power_off,
+};
+
+static const struct udevice_id sama7_usb_phy_of_match[] = {
+ { .compatible = "microchip,sama7g5-usb-phy", },
+ { },
+};
+
+U_BOOT_DRIVER(sama7_usb_phy_driver) = {
+ .name = "sama7-usb-phy",
+ .id = UCLASS_PHY,
+ .of_match = sama7_usb_phy_of_match,
+ .ops = _usb_phy_ops,
+ .probe = sama7_usb_phy_probe,
+ .priv_auto = sizeof(struct sama7_usb_phy),
+};
diff --git a/drivers/phy/phy-sama7-utmi-clk.c b/drivers/phy/phy-sama7-utmi-clk.c
new file mode 100644
index ..2371b4341cd5
--- /dev/null
+++ b/drivers/phy/phy-sama7-utmi-clk.c
@@ -0,0 +1,216 @@
+//
Re: [PATCH] arm: mach-omap2: am33xx: musb: Fix condition for USB device definition
On 6/21/23 19:32, Tom Rini wrote:
On Wed, Jun 21, 2023 at 05:56:56PM +0200, Julien Panis wrote:
This patch fixes a bad condition for USB device definition.
This prevents from getting a "No USB device found" error.
Fixes: 6815a66ad7430 ("am33xx: musb: Remove unused configuration logic")
Signed-off-by: Julien Panis
---
This patch fixes a bad condition which leads to
'no USB device found' error, in usb_ether_init()
function for instance.
---
arch/arm/mach-omap2/am33xx/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/am33xx/board.c
b/arch/arm/mach-omap2/am33xx/board.c
index ecc0a592e993..000c0d7712f9 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -208,7 +208,7 @@ int cpu_mmc_init(struct bd_info *bis)
/* AM33XX has two MUSB controllers which can be host or gadget */
#if (defined(CONFIG_AM335X_USB0) || defined(CONFIG_AM335X_USB1)) && \
- defined(CONFIG_SPL_BUILD)
+ !defined(CONFIG_SPL_BUILD)
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
Well, that's just going to break USB networking in SPL, which is
supposed to be the only case for this code. It's been a while since I
poked at this particular part of the code and board, is the gadget port
one with a "normal" mini port, or do we need one of the USB A <-> USB A
cables for it? My general recollection of when I did 6815a66ad7430 was
that the device tree should control the ports in U-Boot itself.
That's a "normal" mini port, I am working on am335x-icev2.
I missed the logic of 6815a66ad7430. I understand now, so my
patch was not suitable to fix the bug I encountered.
Additional investigations revealed that usb0 'dr_mode' property
is not overlayed to 'peripheral' in 'am335x-icev2-u-boot.dtsi'.
That's why I saw this USB error. I'm going to fix that and send
a new patch.
[PATCH 2/2] buildman: Provide an argument to the -R option
Allow writing the file to a selected location, since otherwise this is
controlled by the buildman configuration, so cannot be determined by the
caller.
Fixes: https://source.denx.de/u-boot/u-boot/-/issues/17
Signed-off-by: Simon Glass
---
.azure-pipelines.yml| 2 +-
.gitlab-ci.yml | 2 +-
tools/buildman/buildman.rst | 7 ---
tools/buildman/cmdline.py | 2 +-
tools/buildman/control.py | 2 ++
tools/buildman/func_test.py | 24 ++--
6 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 3c1846a5bc3d..4d3c588ee020 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -123,7 +123,7 @@ stages:
options: $(container_option)
steps:
- script: |
- ./tools/buildman/buildman -R
+ ./tools/buildman/buildman -R -
- job: tools_only
displayName: 'Ensure host tools build'
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e6c6ab3586e1..336db7a7448f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -184,7 +184,7 @@ sloccount:
Check for configs without MAINTAINERS entry:
stage: testsuites
script:
-- ./tools/buildman/buildman -R
+- ./tools/buildman/buildman -R -
# Ensure host tools build
Build tools-only:
diff --git a/tools/buildman/buildman.rst b/tools/buildman/buildman.rst
index c8b0db3d8b9c..b28aea477dfe 100644
--- a/tools/buildman/buildman.rst
+++ b/tools/buildman/buildman.rst
@@ -1307,9 +1307,10 @@ Using boards.cfg
This file is no-longer needed by buildman but it is still generated in the
working directory. This helps avoid a delay on every build, since scanning all
-the Kconfig files takes a few seconds. Use the -R flag to force regeneration
-of the file - in that case buildman exits after writing the file. with exit
code
-2 if there was an error in the maintainer files.
+the Kconfig files takes a few seconds. Use the `-R ` flag to force
+regeneration of the file - in that case buildman exits after writing the file
+with exit code 2 if there was an error in the maintainer files. To use the
+default filename, use a hyphen, i.e. `-R -`.
You should use 'buildman -nv ' instead of greoing the boards.cfg
file,
since it may be dropped altogether in future.
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index a9cda2495727..ea43685e394d 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -104,7 +104,7 @@ def ParseArgs():
default=False, help="Use an O= (output) directory per board rather
than per thread")
parser.add_option('-r', '--reproducible-builds', action='store_true',
help='Set SOURCE_DATE_EPOCH=0 to suuport a reproducible build')
-parser.add_option('-R', '--regen-board-list', action='store_true',
+parser.add_option('-R', '--regen-board-list', type='string',
help='Force regeneration of the list of boards, like the old
boards.cfg file')
parser.add_option('-s', '--summary', action='store_true',
default=False, help='Show a build summary')
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 09a11f25b3f3..b8286e185411 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -207,6 +207,8 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, brds=None,
if not os.path.exists(options.output_dir):
os.makedirs(options.output_dir)
board_file = os.path.join(options.output_dir, 'boards.cfg')
+if options.regen_board_list and options.regen_board_list != '-':
+board_file = options.regen_board_list
brds = boards.Boards()
ok = brds.ensure_board_list(board_file,
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index ebd78f225e1a..08b2714b7be2 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -225,29 +225,33 @@ class TestFunctional(unittest.TestCase):
return command.run_pipe([[self._buildman_pathname] + list(args)],
capture=True, capture_stderr=True)
-def _RunControl(self, *args, brds=None, clean_dir=False,
-test_thread_exceptions=False):
+def _RunControl(self, *args, brds=False, clean_dir=False,
+test_thread_exceptions=False, get_builder=True):
"""Run buildman
Args:
args: List of arguments to pass
-brds: Boards object
+brds: Boards object, or False to pass self._boards, or None to pass
+None
clean_dir: Used for tests only, indicates that the existing
output_dir
should be removed before starting the build
test_thread_exceptions: Uses for tests only, True to make the
threads
raise an exception instead of reporting their result. This
simulates
a failure in the code somewhere
+get_builder (bool): Set self._builder to the resulting
[PATCH 1/2] buildman: Fix verboose typo and add comment
Fix the typo in the RunTests() function, adding comments while we are here. Signed-off-by: Simon Glass --- tools/buildman/main.py | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/tools/buildman/main.py b/tools/buildman/main.py index 5e1f68d82358..a2ffbc9073e7 100755 --- a/tools/buildman/main.py +++ b/tools/buildman/main.py @@ -28,7 +28,14 @@ from patman import gitutil from u_boot_pylib import terminal from u_boot_pylib import test_util -def RunTests(skip_net_tests, verboose, args): +def RunTests(skip_net_tests, verbose, args): +"""Run the buildman tests + +Args: +skip_net_tests (bool): True to skip tests which need the network +verbosity (int): Verbosity level to use (0-4) +args (list of str): List of tests to run, empty to run all +""" from buildman import func_test from buildman import test import doctest @@ -40,7 +47,7 @@ def RunTests(skip_net_tests, verboose, args): # Run the entry tests first ,since these need to be the first to import the # 'entry' module. result = test_util.run_test_suites( -'buildman', False, verboose, False, None, test_name, [], +'buildman', False, verbose, False, None, test_name, [], [test.TestBuild, func_test.TestFunctional, 'buildman.toolchain', 'patman.gitutil']) -- 2.41.0.162.gfafddb0af9-goog
[PATCH] rockchip: rk3568: Add support for Lubancat2 board from EmbedFire
LubanCat 2 is a rk3568 based SBC from EmbedFire.
Specification:
- Rockchip rk3568
- LPDDR4/4X 1/2/4/8 GB
- TF scard slot
- eMMC 8/32/64/128 GB
- Gigabit ethernet x 2
- HDMI out
- USB 2.0 Host x 1
- USB 2.0 Type-C OTG x 1
- USB 3.0 Host x 1
- Mini PCIE interface for WIFI/BT module
- M.2 key for 2280 NVME
- 40 pin header
The dts file is sync from linux mainline.
Signed-off-by: Andy Yan
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 87 +++
arch/arm/dts/rk3568-lubancat-2.dts | 734 +
configs/lubancat-2-rk3568_defconfig| 96 +++
4 files changed, 919 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-lubancat-2.dts
create mode 100644 configs/lubancat-2-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..b177c0c4f9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,7 +169,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb \
- rk3568-rock-3a.dtb
+ rk3568-rock-3a.dtb \
+ rk3568-lubancat-2.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi
b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi
new file mode 100644
index 00..42072dd0bd
--- /dev/null
+++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2023 Andy Yan
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ };
+};
+
+_bus8 {
+ bootph-all;
+};
+
+_clk {
+ bootph-all;
+};
+
+_cmd {
+ bootph-all;
+};
+
+_datastrobe {
+ bootph-all;
+};
+
+ {
+ bootph-all;
+};
+
+_pull_none {
+ bootph-all;
+};
+
+_pull_up_drv_level_2 {
+ bootph-all;
+};
+
+_pull_up {
+ bootph-all;
+};
+
+_bus4 {
+ bootph-all;
+};
+
+_clk {
+ bootph-all;
+};
+
+_cmd {
+ bootph-all;
+};
+
+_det {
+ bootph-all;
+};
+
+ {
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+_xfer {
+ bootph-all;
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-all;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-lubancat-2.dts
b/arch/arm/dts/rk3568-lubancat-2.dts
new file mode 100644
index 00..da257b0591
--- /dev/null
+++ b/arch/arm/dts/rk3568-lubancat-2.dts
@@ -0,0 +1,734 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2023 EmbedFire
+ * Copyright (c) 2023 Andy Yan
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "EmbedFire LubanCat 2";
+ compatible = "embedfire,lubancat-2", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ user_led: user-led {
+ label = "user_led";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ gpios = < RK_PC7 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin>;
+ };
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
+ dc_5v: dc-5v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_sys>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+
Re: [PATCH 02/10] usb: dwc3: core: improve reset sequence
On 6/22/23 12:00, Eugen Hristev wrote:
On 6/22/23 12:58, Eugen Hristev wrote:
From: Venkatesh Yadav Abbarapu
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
[eugen.hris...@collabora.com: keep the PHY resets code]
Signed-off-by: Eugen Hristev
---
Just resending for consistency with my series. I readded the PHY resets
code because it breaks my PHYs if it's being removed
Marek, I know you NAKed this, that's fine, I am simply adding this patch
(and the others here) for consistency
>>>
>>> Please sync the DWC3 patchset with Linux first, else this is a NAK.
>>>
>>> Please do not make the DWC3 driver an unmaintainable mess.
>>>
>>> I already explained this to AMD/Xilinx, multiple times, they
ignored all my requests without even trying, so my NAK still stands.
>>>
>>> The sync should be easy and mechanical.
>>>
>>> Please do not try to sneak those patches in as part of another series.
>>
>> Hi Marek,
>>
>> I know, I saw the discussion. I am adding the patch in case someone
wants to use it. Definitely I am not trying to sneak anything. Read the
cover letter as well if you have doubts.
>
> I tried asking intel just now to fix what AMD couldn't, so let's see.
I will try to do it myself, if I have some spare time in the following
months, if nobody does it.
^^
I am resending the conversation above as I forgot to CC the mailing list
on the initial thread
I appreciate it. It really should be easy to do.
Re: [PATCH 02/10] usb: dwc3: core: improve reset sequence
On 6/22/23 12:58, Eugen Hristev wrote:
From: Venkatesh Yadav Abbarapu
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
[eugen.hris...@collabora.com: keep the PHY resets code]
Signed-off-by: Eugen Hristev
---
Just resending for consistency with my series. I readded the PHY resets
code because it breaks my PHYs if it's being removed
Marek, I know you NAKed this, that's fine, I am simply adding this patch
(and the others here) for consistency
>>>
>>> Please sync the DWC3 patchset with Linux first, else this is a NAK.
>>>
>>> Please do not make the DWC3 driver an unmaintainable mess.
>>>
>>> I already explained this to AMD/Xilinx, multiple times, they
ignored all my requests without even trying, so my NAK still stands.
>>>
>>> The sync should be easy and mechanical.
>>>
>>> Please do not try to sneak those patches in as part of another series.
>>
>> Hi Marek,
>>
>> I know, I saw the discussion. I am adding the patch in case someone
wants to use it. Definitely I am not trying to sneak anything. Read the
cover letter as well if you have doubts.
>
> I tried asking intel just now to fix what AMD couldn't, so let's see.
I will try to do it myself, if I have some spare time in the following
months, if nobody does it.
^^
I am resending the conversation above as I forgot to CC the mailing list
on the initial thread
[PATCH 10/10] configs: rockchip: rock5b-rk3588: enable DFU and related configs
Enable DFU and related configs, expand stack and buffers to hold downloaded image. Signed-off-by: Eugen Hristev --- configs/rock5b-rk3588_defconfig | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index 3f28a68f0c94..2ad61b4873cc 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -4,6 +4,7 @@ CONFIG_SYS_HAS_NONCACHED_MEMORY=y CONFIG_COUNTER_FREQUENCY=2400 CONFIG_ARCH_ROCKCHIP=y CONFIG_TEXT_BASE=0x00a0 +CONFIG_SYS_MALLOC_F_LEN=0x50 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 @@ -16,9 +17,9 @@ CONFIG_ROCKCHIP_RK3588=y CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y CONFIG_ROCKCHIP_SPI_IMAGE=y CONFIG_SPL_SERIAL=y -CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_SPL_STACK_R_ADDR=0x100 CONFIG_TARGET_ROCK5B_RK3588=y -CONFIG_SPL_STACK=0x40 +CONFIG_SPL_STACK=0x100 CONFIG_DEBUG_UART_BASE=0xFEB5 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_SPI_FLASH_SUPPORT=y @@ -30,6 +31,7 @@ CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_SPL_FIT_SIGNATURE=y CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_LOAD_FIT_ADDRESS=0x5000 CONFIG_OF_BOARD_SETUP=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb" # CONFIG_DISPLAY_CPUINFO is not set @@ -42,9 +44,15 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x30 +CONFIG_SPL_ENV_SUPPORT=y +CONFIG_SPL_RAM_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 +CONFIG_SPL_USB_GADGET=y +CONFIG_SPL_DFU=y CONFIG_SPL_ATF=y +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y @@ -57,10 +65,12 @@ CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIVE=y -CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y CONFIG_SPL_CLK=y +CONFIG_DFU_RAM=y +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x20 # CONFIG_USB_FUNCTION_FASTBOOT is not set CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y @@ -91,6 +101,7 @@ CONFIG_ROCKCHIP_SFC=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_DM_USB_GADGET=y +CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y # CONFIG_USB_XHCI_DWC3_OF_SIMPLE is not set CONFIG_USB_EHCI_HCD=y -- 2.34.1
[PATCH 08/10] ARM: mach-rockchip: rk3588: add gadget device to the boot order
In case SPL was booted from USB, add the gadget as the boot device
for the 'same-as-spl' boot order next device.
Signed-off-by: Eugen Hristev
---
arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index b1f535fad505..c95268e18801 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -42,6 +42,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
[BROM_BOOTSOURCE_SPINOR_RK3588] = "/spi@fe2b/flash@0",
+ [BROM_BOOTSOURCE_USB] = "/usbdrd3_0/usb@fc00",
};
static struct mm_region rk3588_mem_map[] = {
--
2.34.1
[PATCH 09/10] rockchip: rk3588: prepare env for DFU
Prepare env variables for DFU Signed-off-by: Eugen Hristev --- include/configs/rk3588_common.h | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/configs/rk3588_common.h b/include/configs/rk3588_common.h index 46389d087d29..48414fe946a0 100644 --- a/include/configs/rk3588_common.h +++ b/include/configs/rk3588_common.h @@ -7,6 +7,7 @@ #ifndef __CONFIG_RK3588_COMMON_H #define __CONFIG_RK3588_COMMON_H +#include #include "rockchip-common.h" #define CFG_IRAM_BASE 0xff00 @@ -31,6 +32,12 @@ "partitions=" PARTS_DEFAULT \ ENV_MEM_LAYOUT_SETTINGS \ ROCKCHIP_DEVICE_SETTINGS \ - "boot_targets=" BOOT_TARGETS "\0" + "boot_targets=" BOOT_TARGETS "\0" \ + "dfu_alt_info=ram ram0=ram ram " \ + __stringify(CONFIG_SPL_LOAD_FIT_ADDRESS) " " \ + __stringify(CONFIG_SYS_DFU_DATA_BUF_SIZE) "\0" \ + "dfu_alt_info_ram=u-boot.itb ram " \ + __stringify(CONFIG_SPL_LOAD_FIT_ADDRESS) " " \ + __stringify(CONFIG_SYS_DFU_DATA_BUF_SIZE) #endif /* __CONFIG_RK3588_COMMON_H */ -- 2.34.1
[PATCH 07/10] ARM: mach-rockchip: spl-boot-order: add possibility to DFU
Add DFU as a possible SPL boot media if the boot device is a
gadget device.
Signed-off-by: Eugen Hristev
---
arch/arm/mach-rockchip/spl-boot-order.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rockchip/spl-boot-order.c
b/arch/arm/mach-rockchip/spl-boot-order.c
index 93b8e7de4d0d..89bbe449e86c 100644
--- a/arch/arm/mach-rockchip/spl-boot-order.c
+++ b/arch/arm/mach-rockchip/spl-boot-order.c
@@ -66,6 +66,9 @@ static int spl_node_to_boot_device(int node)
} else if (!uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node,
)) {
return BOOT_DEVICE_SPI;
+ } else if (!uclass_get_device_by_of_offset(UCLASS_USB_GADGET_GENERIC,
+ node, )) {
+ return BOOT_DEVICE_DFU;
}
/*
--
2.34.1
[PATCH 05/10] usb: dwc3: Increase DWC3 controller halt timeout
Since EP0 transactions need to be completed before the controller halt
sequence is finished, this may take some time depending on the host and the
enabled functions. Increase the controller halt timeout, so that we give
the controller sufficient time to handle EP0 transfers.
Signed-off-by: Wesley Cheng
Link: https://lore.kernel.org/r/20220901193625.8727-4-quic_wch...@quicinc.com
Cherry-picked from Linux: 461ee467507c ("usb: dwc3: Increase DWC3 controller
halt timeout")
Signed-off-by: Eugen Hristev
---
Sent for consistency, I know Marek does not accept any patches to DWC3
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 24a2c455b0a4..a86680719108 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1356,7 +1356,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget
*g,
static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
{
u32 reg;
- u32 timeout = 500;
+ u32 timeout = 2000;
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
if (is_on) {
@@ -1385,6 +1385,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
dwc3_gadget_dctl_write_safe(dwc, reg);
do {
+ mdelay(2);
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
if (is_on) {
if (!(reg & DWC3_DSTS_DEVCTRLHLT))
@@ -1396,7 +1397,6 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
timeout--;
if (!timeout)
return -ETIMEDOUT;
- udelay(1);
} while (1);
dev_vdbg(dwc->dev, "gadget %s data soft-%s\n",
--
2.34.1
[PATCH 06/10] ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes
Add bootph-all to gadget nodes to have the gadget available in SPL.
Signed-off-by: Eugen Hristev
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 5a3292699640..f453aeeaf526 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -221,10 +221,12 @@
};
{
+ bootph-all;
status = "okay";
};
_otg {
+ bootph-all;
rockchip,typec-vbus-det;
status = "okay";
};
@@ -271,6 +273,7 @@
};
_phy0 {
+ bootph-all;
orientation-switch;
svid = <0xff01>;
sbu1-dc-gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
@@ -293,14 +296,17 @@
};
_phy0_u3 {
+ bootph-all;
status = "okay";
};
_0 {
+ bootph-all;
status = "okay";
};
_dwc3_0 {
+ bootph-all;
dr_mode = "otg";
usb-role-switch;
--
2.34.1
[PATCH 04/10] usb: dwc3: core: Only handle soft-reset in DCTL
From: Venkatesh Yadav Abbarapu
[ Nguyen/Greg: Ported from Linux kernel commit
f4fd84ae0765a ("usb: dwc3: core: Only handle soft-reset in DCTL") ]
Make sure not to set run_stop bit or link state change request while
initiating soft-reset. Register read-modify-write operation may
unintentionally start the controller before the initialization completes
with its previous DCTL value, which can cause initialization failure.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index bdfe51c3df96..06ca3fc96842 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -72,7 +72,8 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg |= DWC3_DCTL_CSFTRST;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ reg &= ~DWC3_DCTL_RUN_STOP;
+ dwc3_gadget_dctl_write_safe(dwc, reg);
/* Assert USB3 PHY reset */
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
--
2.34.1
[PATCH 02/10] usb: dwc3: core: improve reset sequence
From: Venkatesh Yadav Abbarapu
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
[eugen.hris...@collabora.com: keep the PHY resets code]
Signed-off-by: Eugen Hristev
---
Just resending for consistency with my series. I readded the PHY resets
code because it breaks my PHYs if it's being removed
Marek, I know you NAKed this, that's fine, I am simply adding this patch
(and the others here) for consistency
drivers/usb/dwc3/core.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5a8c29424578..bdfe51c3df96 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,17 +60,24 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
static int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
+ int retries = 1000;
- /* Before Resetting PHY, put Core in Reset */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg |= DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ /*
+* We're resetting only the device side because, if we're in host mode,
+* XHCI driver will reset the host block. If dwc3 was configured for
+* host-only mode, then we can return early.
+*/
+ if (dwc->dr_mode == USB_DR_MODE_HOST)
+ return 0;
+
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
/* Assert USB3 PHY reset */
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
/* Assert USB2 PHY reset */
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
@@ -88,14 +95,14 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
- mdelay(100);
-
- /* After PHYs are stable we can take Core out of reset state */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg &= ~DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ return 0;
+ udelay(1);
+ } while (--retries);
- return 0;
+ return -ETIMEDOUT;
}
/*
--
2.34.1
[PATCH 03/10] usb: dwc3: gadget: Don't send unintended link state change
From: Venkatesh Yadav Abbarapu
[ Nguyen/Felipe/Greg: Ported from Linux kernel commit
5b738211fb59 ("usb: dwc3: gadget: Don't send
unintended link state change") ]
DCTL.ULSTCHNGREQ is a write-only field. When doing a read-modify-write
to DCTL, the driver must make sure that there's no unintended link state
change request from whatever is read from DCTL.ULSTCHNGREQ. Set link
state change to no-action when the driver writes to DCTL.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/usb/dwc3/gadget.c | 16 +++-
drivers/usb/dwc3/gadget.h | 14 ++
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index eb416b832aad..24a2c455b0a4 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -62,7 +62,7 @@ int dwc3_gadget_set_test_mode(struct dwc3 *dwc, int mode)
return -EINVAL;
}
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
return 0;
}
@@ -1382,7 +1382,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
dwc->pullups_connected = false;
}
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
do {
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
@@ -2047,10 +2047,8 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3
*dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_INITU1ENA;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-
reg &= ~DWC3_DCTL_INITU2ENA;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
dwc3_disconnect_gadget(dwc);
dwc->start_config_issued = false;
@@ -2099,7 +2097,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
dwc->test_mode = false;
dwc3_stop_active_transfers(dwc);
@@ -2215,11 +2213,11 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3
*dwc)
if (dwc->has_lpm_erratum && dwc->revision >= DWC3_REVISION_240A)
reg |= DWC3_DCTL_LPM_ERRATA(dwc->lpm_nyet_threshold);
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
} else {
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_HIRD_THRES_MASK;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
}
dep = dwc->eps[0];
@@ -2327,7 +2325,7 @@ static void dwc3_gadget_linksts_change_interrupt(struct
dwc3 *dwc,
reg &= ~u1u2;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
break;
default:
/* do nothing */
diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index 7806ce59a27f..b48ec6b2372f 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -104,4 +104,18 @@ static inline u32 dwc3_gadget_ep_get_transfer_index(struct
dwc3 *dwc, u8 number)
return DWC3_DEPCMD_GET_RSC_IDX(res_id);
}
+/**
+ * dwc3_gadget_dctl_write_safe - write to DCTL safe from link state change
+ * @dwc: pointer to our context structure
+ * @value: value to write to DCTL
+ *
+ * Use this function when doing read-modify-write to DCTL. It will not
+ * send link state change request.
+ */
+static inline void dwc3_gadget_dctl_write_safe(struct dwc3 *dwc, u32 value)
+{
+ value &= ~DWC3_DCTL_ULSTCHNGREQ_MASK;
+ dwc3_writel(dwc->regs, DWC3_DCTL, value);
+}
+
#endif /* __DRIVERS_USB_DWC3_GADGET_H */
--
2.34.1
[PATCH 01/10] rockchip: allow env defines for SPL build
For environment in SPL, all these defines are required, otherwise
build fails:
[...]
include/env_default.h:120:9: note: in expansion of macro
‘CFG_EXTRA_ENV_SETTINGS’
120 | CFG_EXTRA_ENV_SETTINGS
| ^~
In file included from env/common.c:32:
[...]
Environment in SPL is needed e.g. for DFU, as dfu_alt is kept as
env variable.
Signed-off-by: Eugen Hristev
---
include/configs/rockchip-common.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/configs/rockchip-common.h
b/include/configs/rockchip-common.h
index 9121bba37384..be20b135066e 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,8 +11,6 @@
#define CFG_CPUID_OFFSET 0x7
#endif
-#ifndef CONFIG_SPL_BUILD
-
#define BOOT_TARGETS "mmc1 mmc0 nvme scsi usb pxe dhcp spi"
#ifdef CONFIG_ARM64
@@ -28,6 +26,4 @@
"name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};" \
"name=rootfs,size=-,uuid="ROOT_UUID
-#endif
-
#endif /* _ROCKCHIP_COMMON_H_ */
--
2.34.1
[PATCH 00/10] rockchip: rk3588: add support for DFU in SPL
This series adds support for DFU in SPL for rockchip rk3588 on rock5b board. Namely, when SPL is loaded via rockusb (thus via USB), having the `same-as-spl` boot order item, after having detected that it was loaded from USB, it will lookup the gadget USB node in DT and boot via DFU. Some changes were required namely: - DFU needs environment, hence adding environment variables into DFU - added bootph-all to nodes such that they are available in SPL - insert gadget into boot order I had to port one patch for DWC3 from Linux, and include in this series the patches that are floating from Venkatesh that fixup the DWC3 (https://marc.info/?l=u-boot=168351919807081=2 ) I know that Marek NAKed them and I am fine with it, also this patch `usb: dwc3: Increase DWC3 controller halt timeout` is in the same bucket so Marek you can NAK this one as well, no problem, I am just sending out all the series so maybe the rockchip part for the gadget can be picked up and if people want to use the DFU SPL gadget can also manually pick the DWC3 patches. The branch with all the patches is available here : https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot The series also depends on my previous usb3 series: https://marc.info/?l=u-boot=168535453215908=2 Thanks! I am resending because I forgot to CC the list. Eugen Hristev (7): rockchip: allow env defines for SPL build usb: dwc3: Increase DWC3 controller halt timeout ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes ARM: mach-rockchip: spl-boot-order: add possibility to DFU ARM: mach-rockchip: rk3588: add gadget device to the boot order rockchip: rk3588: prepare env for DFU configs: rockchip: rock5b-rk3588: enable DFU and related configs Venkatesh Yadav Abbarapu (3): usb: dwc3: core: improve reset sequence usb: dwc3: gadget: Don't send unintended link state change usb: dwc3: core: Only handle soft-reset in DCTL arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 + arch/arm/mach-rockchip/rk3588/rk3588.c | 1 + arch/arm/mach-rockchip/spl-boot-order.c | 3 +++ configs/rock5b-rk3588_defconfig | 17 ++--- drivers/usb/dwc3/core.c | 32 +++-- drivers/usb/dwc3/gadget.c | 20 +++- drivers/usb/dwc3/gadget.h | 14 +++ include/configs/rk3588_common.h | 9 ++- include/configs/rockchip-common.h | 4 9 files changed, 75 insertions(+), 31 deletions(-) -- 2.34.1
Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state
On 6/22/23 04:48, Lim, Jit Loon wrote: -Original Message- From: Marek Vasut Sent: Wednesday, 21 June, 2023 10:19 PM To: Lim, Jit Loon ; u-boot@lists.denx.de Cc: Jagan Teki ; Simon ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Chong, Teik Heng ; Zamri, Muhammad Hazim Izzat ; Tang, Sieu Mun ; Bin Meng Subject: Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state On 6/21/23 16:11, Jit Loon Lim wrote: From: Teik Heng Chong The controller registers should not be accessed while the controller's vcc_reset_n is asserted. Signed-off-by: Teik Heng Chong Is this patch ported from Linux or is this custom development ? Is there a matching patch/fix in Linux already ? In xhci_dwc3_probe(), the program sequence is vcc reset -> clk init -> phy setup -> xhci_register therefore, when xhci_dwc3_remove is called, the proper usb stop sequence should be xhci_register _> phy setup -> clk init -> vcc reset if we look at linux driver https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-of-simple.c#L33 dwc3_of_simple_probe: The sequence is reset -> clock __dwc3_of_simple_teardown: Then, clock -> reset So based on the above, we have made changes and the uboot fix is now aligned with linux driver. Instead of adding random patches to the U-Boot dwc3 driver, please just synchronize the driver with Linux. You should be able to add the missing patches to the DWC3 driver from Linux since the last synchronization point, the process should be largely mechanical. Make sure to include commit ID of each Linux commit in the new matching U-Boot patch. It shouldn't be difficult, one approach I can think of is roughly this: - figure out the original merge base from which the DWC3 driver was imported to U-Boot - in U-Boot, revert all dwc3 patches on top of that import patch - pick all Linux kernel dwc3 patches from that merge base and apply on top of this U-Boot with reverts - Run rebase and drop the reverts, let git drop duplicate patches
Re: Rockchip DWC2 issue
On Wed, Jun 21, 2023 at 9:38 PM Marek Vasut wrote: > > On 6/20/23 16:37, Jagan Teki wrote: > > Hi, > > > > Has anyone tried to use dwc2 and echi port together with USB disk? > > look like this is not working with this combination on any Rockchip > > SoC's > > > > Here are the issues that I've reproduced in RK3328 where the disk > > connected in EHCI port is detecting but DWC2 is not. Any clue? > > I generally avoid using DWC2 as host. RPi 1/2/3 does use it as host, but > I think there is a hub between. The B models of the 1-3 have a hub. > Also, RPi zero (?) might have raw host port on it, without hub . Correct, the Zeros, Model As, Compute Modules (inc the CM4) in some configurations and the RPi4 via the USB-C (albeit I suspect rarely used as such) all have dwc2 directly connected.
[PATCH v1] LFU-544: Kconfig.nxp: Fixed secure boot on LS-CH2 platforms
pimg64 image pointer is dependent on ESBC_ADDR_64BIT config, which is getting disabled, due to dependency on ESBC_HDR_LS. ESBC_HDR_LS is required for LS-CH3 platforms. So, removing the dependency on ESBC_HDR_LS. Signed-off-by: Kshitiz Varshney --- arch/Kconfig.nxp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/Kconfig.nxp b/arch/Kconfig.nxp index 6e1c44b7ea..fa9060a4db 100644 --- a/arch/Kconfig.nxp +++ b/arch/Kconfig.nxp @@ -45,7 +45,7 @@ config ESBC_HDR_LS config ESBC_ADDR_64BIT def_bool y - depends on ESBC_HDR_LS && FSL_LAYERSCAPE + depends on FSL_LAYERSCAPE help For Layerscape based platforms, ESBC image Address in Header is 64bit. -- 2.25.1
Re: Rockchip DWC2 issue
On Thu, Jun 22, 2023 at 2:08 AM Marek Vasut wrote: > > On 6/20/23 16:37, Jagan Teki wrote: > > Hi, > > > > Has anyone tried to use dwc2 and echi port together with USB disk? > > look like this is not working with this combination on any Rockchip > > SoC's > > > > Here are the issues that I've reproduced in RK3328 where the disk > > connected in EHCI port is detecting but DWC2 is not. Any clue? > > I generally avoid using DWC2 as host. RPi 1/2/3 does use it as host, but > I think there is a hub between. Looks this is the same case even for the Rockchip SoC side as well. > > Does the stick work if you plug a hub between the board and stick ? I have observed the same behavior as before It detects very rarely. > > Also, RPi zero (?) might have raw host port on it, without hub . Worth to try, will check it. Thanks, Jagan
Re: [PATCH v2] doc: uefi: enhance anti-rollback documentation
Hi Kojima-san On Thu, 22 Jun 2023 at 08:51, Masahisa Kojima wrote: > > To enforce anti-rollback to any older version, dtb must be > always update manually. This should be described in the > documentation. > > This commit also adds the recommendation that secure system should not > enable the fdt command because lowest-supported-version > property in device tree can be changed by fdt command. > > Signed-off-by: Masahisa Kojima > --- > doc/develop/uefi/uefi.rst | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > index ffd13cebe9..7407f178f5 100644 > --- a/doc/develop/uefi/uefi.rst > +++ b/doc/develop/uefi/uefi.rst > @@ -552,6 +552,13 @@ update using a capsule file with --fw-version of 5, the > update will fail. > When the --fw-version in the capsule file is updated, > lowest-supported-version > in the dtb might be updated accordingly. > > +If user needs to enroce anti-rollback to any older version, enforce* > +the lowest-supported-version property in dtb must be always updated manually. > + > +Note that the lowest-supported-version property specified in U-Boot's control > +device tree can be changed by U-Boot fdt command. > +Secure systems should not enable this command. > + Other than than Reviewed-by: Ilias Apalodimas > To insert the lowest supported version into a dtb > > .. code-block:: console > -- > 2.34.1 >
[PATCH v3] doc: uefi: enhance anti-rollback documentation
To enforce anti-rollback to any older version, dtb must be always update manually. This should be described in the documentation. This commit also adds the recommendation that secure system should not enable the fdt command because lowest-supported-version property in device tree can be changed by fdt command. Reviewed-by: Ilias Apalodimas Signed-off-by: Masahisa Kojima --- changes in v3: - fix typo changes in v2: - add recommendation not to enable fdt command doc/develop/uefi/uefi.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index ffd13cebe9..9b7c9f19a9 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -552,6 +552,13 @@ update using a capsule file with --fw-version of 5, the update will fail. When the --fw-version in the capsule file is updated, lowest-supported-version in the dtb might be updated accordingly. +If user needs to enforce anti-rollback to any older version, +the lowest-supported-version property in dtb must be always updated manually. + +Note that the lowest-supported-version property specified in U-Boot's control +device tree can be changed by U-Boot fdt command. +Secure systems should not enable this command. + To insert the lowest supported version into a dtb .. code-block:: console -- 2.34.1
Re: [PATCH v2] doc: uefi: enhance anti-rollback documentation
On Thu, 22 Jun 2023 at 16:21, Ilias Apalodimas wrote: > > Hi Kojima-san > > On Thu, 22 Jun 2023 at 08:51, Masahisa Kojima > wrote: > > > > To enforce anti-rollback to any older version, dtb must be > > always update manually. This should be described in the > > documentation. > > > > This commit also adds the recommendation that secure system should not > > enable the fdt command because lowest-supported-version > > property in device tree can be changed by fdt command. > > > > Signed-off-by: Masahisa Kojima > > --- > > doc/develop/uefi/uefi.rst | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > index ffd13cebe9..7407f178f5 100644 > > --- a/doc/develop/uefi/uefi.rst > > +++ b/doc/develop/uefi/uefi.rst > > @@ -552,6 +552,13 @@ update using a capsule file with --fw-version of 5, > > the update will fail. > > When the --fw-version in the capsule file is updated, > > lowest-supported-version > > in the dtb might be updated accordingly. > > > > +If user needs to enroce anti-rollback to any older version, > > enforce* > > > +the lowest-supported-version property in dtb must be always updated > > manually. > > + > > +Note that the lowest-supported-version property specified in U-Boot's > > control > > +device tree can be changed by U-Boot fdt command. > > +Secure systems should not enable this command. > > + > > Other than than > Reviewed-by: Ilias Apalodimas Thank you for pointing out the typo. I will fix and send v3 soon. Thanks, Masahisa Kojima > > > To insert the lowest supported version into a dtb > > > > .. code-block:: console > > -- > > 2.34.1 > >
