RE: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable
Hello Tom Rini, > -Original Message- > From: Tom Rini > Sent: Wednesday, August 4, 2021 8:52 PM > To: Ashok Reddy Soma > Cc: u-boot@lists.denx.de; miquel.ray...@bootlin.com; git ; > T Karthik Reddy > Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable > > On Fri, Jul 23, 2021 at 06:18:26AM -0600, Ashok Reddy Soma wrote: > > > From: T Karthik Reddy > > > > Tpm test cases relies on tpm device setup. Provide an environment > > variable "env__tpm_device_test_skip = True" to skip the test case if > > tpm device is not present. > > Only needed will have to add variable to the py-test framework. > > Test runs successfully even this variable is absent. > > > > Signed-off-by: T Karthik Reddy > > Signed-off-by: Ashok Reddy Soma > > Why is this not using boardenv_* like other tests do to disable running? What I meant here was this test doesn't depend on configuration value from boardenv_*. But it uses env__tpm_device_test_skip variable from the configuration file. I referred test/py/tests/test_sleep.py for writing this test case, hence copied comments as well. Should I change this NOTE in comment section? Thanks T Karthik > > -- > Tom
Re: [PATCH 1/1] config: MPC8548CDS: eliminate symbol CONFIG_SYS_ID_EEPROM
On Thu, Jul 29, 2021 at 08:27:17PM +0200, Heinrich Schuchardt wrote: > Symbol CONFIG_SYS_ID_EEPROM is defined in include/configs/MPC8548CDS.h > but never used. Remove it here and from the whitelist. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cmd:Elaborate 'blkcache' cmd HELP statement
On Wed, Jun 30, 2021 at 11:57:45PM +0530, opensource@gmail.com wrote: > From: Adarsh Babu Kalepalli > > HELP description is provided for ‘configure’ sub-command > of ‘blkcache’. > > Signed-off-by: Adarsh Babu Kalepalli > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: Add basic information about running CI tests
On Tue, Jul 27, 2021 at 01:01:44PM -0400, Tom Rini wrote: > Start out by documenting general expectations on when CI is run, how > anyone can run Azure pipelines, and how GitLab CI pipelines can be run. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd:(cosmetic)Mentioned in 'chpart' command HELP text that it is for MTD devices
On Mon, May 24, 2021 at 01:35:39PM +0530, opensource@gmail.com wrote: > From: Adarsh Babu Kalepalli > > Modified the help text of 'chpart' command ,mentioning that it is > for MTD devices. > > Signed-off-by: Adarsh Babu Kalepalli > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs/squashfs: Fix some hardlinks reading the wrong inode
On Fri, Apr 30, 2021 at 04:45:46PM +1200, Campbell Suter wrote:
> In SquashFS, the contents of a directory is stored by
> squashfs_directory_entry structures which contain the file's name, inode
> and position within the filesystem.
>
> The inode number is not stored directly; instead each directory has one
> or more headers which set a base inode number, and files store the
> offset from that to the file's inode number.
>
> In mksquashfs, each inode is allocated a number in the same order as
> they are written to the directory table; thus the offset from the
> header's base inode number to the file's inode number is usually
> positive.
>
> Hardlinks are simply stored with two directory entries referencing the
> same file. This means the second entry will thus have an inode number
> much lower than the surrounding files. Since the header's base inode
> number comes from the first entry that uses the header, this delta will
> usually be negative.
>
> Previously, U-Boot's squashfs_directory_entry.inode_offset field was
> declared as an unsigned value. Thus when a negative value was found, it
> would either resolve to an invalid inode number or to that of an
> unrelated file.
>
> A squashfs image to test this can be created like so:
>
> echo hi > sqfs_test_files/001-root-file
> mkdir sqfs_test_files/002-subdir
> touch sqfs_test_files/002-subdir/003-file
> lnsqfs_test_files/{001-root-file,002-subdir/004-link}
> mksquashfs sqfs_test_files/ test.sqfs -noappend
>
> Note that squashfs sorts the files ASCIIbetacally, so we can use the
> names to control the order they appear in. The ordering is important -
> the first reference to the file must have a lower inode number than the
> directory in which the second reference resides, and the second
> reference cannot be the first file in the directory.
>
> Listing this sample image in U-Boot results in:
>
> => sqfsls virtio 2 002-subdir
> 0 003-file
> Inode not found.
> 0 004-link
>
> Signed-off-by: Campbell Suter
> Reviewed-by: Miquel Raynal
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] fit: Fix verification of images with external data
On Tue, Apr 20, 2021 at 07:19:44PM +0100, John Keeping wrote: > The "-E" option to mkimage generates a FIT with external data using the > data-size and data-offset properties which must both be ignored when > verifying a signature. > > Add "data-offset" to the list of excluded properties for signature > verification; since the line is now too long, re-format the list to > one-per-line and make it static since the data is constant. > > Signed-off-by: John Keeping > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: am335x_evm: failed to boot via USB
On Wed, Aug 04, 2021 at 11:38:02PM +0300, Matwey V. Kornilov wrote: > Hi, > > I am trying to boot an am335x based board (BeagleBone Black) from USB > using v2021.07. I see the following issue when trying to boot via USB > (USB based network): > > > U-Boot SPL 2021.07-00013-gd0f1ad9f23 (Aug 02 2021 - 21:29:57 +0300) > Trying to boot from USB eth > ## Error: flags type check failure for "ethaddr" <= "40309614M" (type: m) > ## Error inserting "ethaddr" variable, errno=1 > eth0: eth_cpsw## Error: flags type check failure for "eth1addr" <= > "81f01114M" (type: m) > ## Error inserting "eth1addr" variable, errno=1 > , eth1: usb_ether > eth_cpsw Waiting for PHY auto negotiation to complete. TIMEOUT ! > Problem booting with BOOTP > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > > I suppose that _env_flags_validate_type doesn't like this "M" suffix. > But I don't know where it came from. What does the environment look like here? -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wednesday 04 August 2021 18:15:55 Tom Rini wrote: > On Thu, Aug 05, 2021 at 12:14:29AM +0200, Pali Rohár wrote: > > On Wednesday 04 August 2021 18:09:14 Tom Rini wrote: > > > On Wed, Aug 04, 2021 at 05:43:41PM -0400, Sean Anderson wrote: > > > > > > > > > > > > On 8/2/21 3:21 PM, Simon Glass wrote: > > > > > Hi Pali, > > > > > > > > > > On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: > > > > > > > > > > > > Header file version.h does not use anything from timestamp.h. > > > > > > Including of > > > > > > timestamp.h has side effect which cause recompiling object file at > > > > > > every > > > > > > make run because timestamp.h changes at every run. > > > > > > > > > > > > So remove timestamp.h from version.h and include timestamp.h in > > > > > > files > > > > > > which needs it. > > > > > > > > > > > > This change reduce recompilation time of final U-Boot binary when > > > > > > U-Boot > > > > > > source files were not changed as less source files needs to be > > > > > > recompiled. > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > --- > > > > > > arch/arm/mach-rockchip/tpl.c | 4 > > > > > > board/work-microwave/work_92105/work_92105_display.c | 1 + > > > > > > cmd/version.c| 1 + > > > > > > common/spl/spl.c | 4 > > > > > > drivers/rtc/emul_rtc.c | 2 +- > > > > > > include/version.h| 2 -- > > > > > > 6 files changed, 11 insertions(+), 3 deletions(-) > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > I assume we do actually want to regenerate the timestamp when U-Boot > > > > > builds, even if nothing has changed. Is that right? > > > > > > > > I know this is the current behavior, but it would be nice if this was > > > > not the case. If one is building U-Boot as part of a larger project, one > > > > might want to have a makefile rule like > > > > > > > > u-boot/u-boot.bin: > > > > $(MAKE) -C u-boot $(@F) > > > > > > > > but u-boot/u-boot.bin will always be remade even if no changes have been > > > > done. This will cause make to remake all dependents of U-Boot as well > > > > (which can be rather time-consuming). > > > > > > > > At the moment, I just use U-Boot as an order-only dependency and remake > > > > it manually. But I would love it if U-Boot was only remade if > > > > dependencies had actually changed, since this would make it easier to > > > > integrate it with the rest of my build system. > > > > > > Note that with this series applied, if you made use of > > > SOURCE_DATE_EPOCH, nothing would be rebuilt. > > > > IIRC with SOURCE_DATE_EPOCH nothing would be rebuilt also without > > applying this my patch series. > > Correct, it does not. > > > > That may or may not make > > > sense however, in your case. This series does get us closer to being > > > able to do what the linux kernel does as there's now just one place > > > rather than a bunch of places that are rebuilt. > > > > Just small correction. Even with this patch series there would not be > > just one place. There are still more places but this patch series reduce > > number of these places. > > Ah, I only saw one place in my limited testing this morning. For my tested boards it is also just one place. But for some other boards with extended config options it may be more places (like emul_rtc or work display, ...). But if your testing discovered also only one place it could mean that it can be common case for more people...
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Thu, Aug 05, 2021 at 12:14:29AM +0200, Pali Rohár wrote: > On Wednesday 04 August 2021 18:09:14 Tom Rini wrote: > > On Wed, Aug 04, 2021 at 05:43:41PM -0400, Sean Anderson wrote: > > > > > > > > > On 8/2/21 3:21 PM, Simon Glass wrote: > > > > Hi Pali, > > > > > > > > On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: > > > > > > > > > > Header file version.h does not use anything from timestamp.h. > > > > > Including of > > > > > timestamp.h has side effect which cause recompiling object file at > > > > > every > > > > > make run because timestamp.h changes at every run. > > > > > > > > > > So remove timestamp.h from version.h and include timestamp.h in files > > > > > which needs it. > > > > > > > > > > This change reduce recompilation time of final U-Boot binary when > > > > > U-Boot > > > > > source files were not changed as less source files needs to be > > > > > recompiled. > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > --- > > > > > arch/arm/mach-rockchip/tpl.c | 4 > > > > > board/work-microwave/work_92105/work_92105_display.c | 1 + > > > > > cmd/version.c| 1 + > > > > > common/spl/spl.c | 4 > > > > > drivers/rtc/emul_rtc.c | 2 +- > > > > > include/version.h| 2 -- > > > > > 6 files changed, 11 insertions(+), 3 deletions(-) > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > I assume we do actually want to regenerate the timestamp when U-Boot > > > > builds, even if nothing has changed. Is that right? > > > > > > I know this is the current behavior, but it would be nice if this was > > > not the case. If one is building U-Boot as part of a larger project, one > > > might want to have a makefile rule like > > > > > > u-boot/u-boot.bin: > > > $(MAKE) -C u-boot $(@F) > > > > > > but u-boot/u-boot.bin will always be remade even if no changes have been > > > done. This will cause make to remake all dependents of U-Boot as well > > > (which can be rather time-consuming). > > > > > > At the moment, I just use U-Boot as an order-only dependency and remake > > > it manually. But I would love it if U-Boot was only remade if > > > dependencies had actually changed, since this would make it easier to > > > integrate it with the rest of my build system. > > > > Note that with this series applied, if you made use of > > SOURCE_DATE_EPOCH, nothing would be rebuilt. > > IIRC with SOURCE_DATE_EPOCH nothing would be rebuilt also without > applying this my patch series. Correct, it does not. > > That may or may not make > > sense however, in your case. This series does get us closer to being > > able to do what the linux kernel does as there's now just one place > > rather than a bunch of places that are rebuilt. > > Just small correction. Even with this patch series there would not be > just one place. There are still more places but this patch series reduce > number of these places. Ah, I only saw one place in my limited testing this morning. -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wednesday 04 August 2021 18:09:14 Tom Rini wrote: > On Wed, Aug 04, 2021 at 05:43:41PM -0400, Sean Anderson wrote: > > > > > > On 8/2/21 3:21 PM, Simon Glass wrote: > > > Hi Pali, > > > > > > On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: > > > > > > > > Header file version.h does not use anything from timestamp.h. Including > > > > of > > > > timestamp.h has side effect which cause recompiling object file at every > > > > make run because timestamp.h changes at every run. > > > > > > > > So remove timestamp.h from version.h and include timestamp.h in files > > > > which needs it. > > > > > > > > This change reduce recompilation time of final U-Boot binary when U-Boot > > > > source files were not changed as less source files needs to be > > > > recompiled. > > > > > > > > Signed-off-by: Pali Rohár > > > > --- > > > > arch/arm/mach-rockchip/tpl.c | 4 > > > > board/work-microwave/work_92105/work_92105_display.c | 1 + > > > > cmd/version.c| 1 + > > > > common/spl/spl.c | 4 > > > > drivers/rtc/emul_rtc.c | 2 +- > > > > include/version.h| 2 -- > > > > 6 files changed, 11 insertions(+), 3 deletions(-) > > > > > > Reviewed-by: Simon Glass > > > > > > I assume we do actually want to regenerate the timestamp when U-Boot > > > builds, even if nothing has changed. Is that right? > > > > I know this is the current behavior, but it would be nice if this was > > not the case. If one is building U-Boot as part of a larger project, one > > might want to have a makefile rule like > > > > u-boot/u-boot.bin: > > $(MAKE) -C u-boot $(@F) > > > > but u-boot/u-boot.bin will always be remade even if no changes have been > > done. This will cause make to remake all dependents of U-Boot as well > > (which can be rather time-consuming). > > > > At the moment, I just use U-Boot as an order-only dependency and remake > > it manually. But I would love it if U-Boot was only remade if > > dependencies had actually changed, since this would make it easier to > > integrate it with the rest of my build system. > > Note that with this series applied, if you made use of > SOURCE_DATE_EPOCH, nothing would be rebuilt. IIRC with SOURCE_DATE_EPOCH nothing would be rebuilt also without applying this my patch series. > That may or may not make > sense however, in your case. This series does get us closer to being > able to do what the linux kernel does as there's now just one place > rather than a bunch of places that are rebuilt. Just small correction. Even with this patch series there would not be just one place. There are still more places but this patch series reduce number of these places.
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wed, Aug 04, 2021 at 05:43:41PM -0400, Sean Anderson wrote: > > > On 8/2/21 3:21 PM, Simon Glass wrote: > > Hi Pali, > > > > On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: > > > > > > Header file version.h does not use anything from timestamp.h. Including of > > > timestamp.h has side effect which cause recompiling object file at every > > > make run because timestamp.h changes at every run. > > > > > > So remove timestamp.h from version.h and include timestamp.h in files > > > which needs it. > > > > > > This change reduce recompilation time of final U-Boot binary when U-Boot > > > source files were not changed as less source files needs to be recompiled. > > > > > > Signed-off-by: Pali Rohár > > > --- > > > arch/arm/mach-rockchip/tpl.c | 4 > > > board/work-microwave/work_92105/work_92105_display.c | 1 + > > > cmd/version.c| 1 + > > > common/spl/spl.c | 4 > > > drivers/rtc/emul_rtc.c | 2 +- > > > include/version.h| 2 -- > > > 6 files changed, 11 insertions(+), 3 deletions(-) > > > > Reviewed-by: Simon Glass > > > > I assume we do actually want to regenerate the timestamp when U-Boot > > builds, even if nothing has changed. Is that right? > > I know this is the current behavior, but it would be nice if this was > not the case. If one is building U-Boot as part of a larger project, one > might want to have a makefile rule like > > u-boot/u-boot.bin: > $(MAKE) -C u-boot $(@F) > > but u-boot/u-boot.bin will always be remade even if no changes have been > done. This will cause make to remake all dependents of U-Boot as well > (which can be rather time-consuming). > > At the moment, I just use U-Boot as an order-only dependency and remake > it manually. But I would love it if U-Boot was only remade if > dependencies had actually changed, since this would make it easier to > integrate it with the rest of my build system. Note that with this series applied, if you made use of SOURCE_DATE_EPOCH, nothing would be rebuilt. That may or may not make sense however, in your case. This series does get us closer to being able to do what the linux kernel does as there's now just one place rather than a bunch of places that are rebuilt. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Nokia RX-51: Convert documentation to rst format
On Monday 02 August 2021 11:43:59 Lokesh Vutla wrote:
> Hi Pali,
>
> On 01/08/21 4:18 pm, Pali Rohár wrote:
> > On Monday 26 July 2021 12:38:05 Lokesh Vutla wrote:
> >> On 22/07/21 2:55 am, Pali Rohár wrote:
> >>> Signed-off-by: Pali Rohár
> >>> ---
> >>> board/nokia/rx51/MAINTAINERS | 2 +-
> >>> doc/board/index.rst | 1 +
> >>> doc/board/nokia/index.rst | 7 +
> >>> .../nokia/rx51.rst} | 142 +-
> >>> 4 files changed, 83 insertions(+), 69 deletions(-)
> >>> create mode 100644 doc/board/nokia/index.rst
> >>> rename doc/{README.nokia_rx51 => board/nokia/rx51.rst} (32%)
> >>
> >> This doesn't apply cleanly on latest u-boot master. Can you rebase and
> >> repost?
> >
> > Because it depends on other N900 patches which were sent to ML prior this
> > one.
>
> How am I supposed to know what all patches it depends on and the current
> status
> of these patches?
>
> Please list all the patches and their current status. Or please ping me once
> all
> the dependent patches are merged.
Hello! Here is the list of dependent patches:
* https://lists.denx.de/pipermail/u-boot/2021-June/452410.html
* https://lists.denx.de/pipermail/u-boot/2021-June/452411.html
> Thanks and regards,
> Lokesh
>
> >
> >> Thanks and regards,
> >> Lokesh
> >>
> >>>
> >>> diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
> >>> index 58b16bf9a95c..25f8b3c5a9ad 100644
> >>> --- a/board/nokia/rx51/MAINTAINERS
> >>> +++ b/board/nokia/rx51/MAINTAINERS
> >>> @@ -4,5 +4,5 @@ S:Maintained
> >>> F: board/nokia/rx51/
> >>> F: include/configs/nokia_rx51.h
> >>> F: configs/nokia_rx51_defconfig
> >>> -F: doc/README.nokia_rx51
> >>> +F: doc/board/nokia/rx51.rst
> >>> F: test/nokia_rx51_test.sh
> >>> diff --git a/doc/board/index.rst b/doc/board/index.rst
> >>> index 747511f7ddd2..4c470abbac02 100644
> >>> --- a/doc/board/index.rst
> >>> +++ b/doc/board/index.rst
> >>> @@ -19,6 +19,7 @@ Board-specific doc
> >>> intel/index
> >>> kontron/index
> >>> microchip/index
> >>> + nokia/index
> >>> rockchip/index
> >>> sifive/index
> >>> sipeed/index
> >>> diff --git a/doc/board/nokia/index.rst b/doc/board/nokia/index.rst
> >>> new file mode 100644
> >>> index ..fb0db2f34244
> >>> --- /dev/null
> >>> +++ b/doc/board/nokia/index.rst
> >>> @@ -0,0 +1,7 @@
> >>> +Nokia
> >>> +=
> >>> +
> >>> +.. toctree::
> >>> + :maxdepth: 2
> >>> +
> >>> + rx51
> >>> diff --git a/doc/README.nokia_rx51 b/doc/board/nokia/rx51.rst
> >>> similarity index 32%
> >>> rename from doc/README.nokia_rx51
> >>> rename to doc/board/nokia/rx51.rst
> >>> index e739b02088ea..c84fdcddf166 100644
> >>> --- a/doc/README.nokia_rx51
> >>> +++ b/doc/board/nokia/rx51.rst
> >>> @@ -1,6 +1,7 @@
> >>> -Board: Nokia RX-51 aka N900
> >>> +Nokia RX-51 aka N900
> >>> +
> >>>
> >>> -This board definition results in a u-boot.bin which can be chainloaded
> >>> +This board definition results in a ``u-boot.bin`` which can be
> >>> chainloaded
> >>> from NOLO in qemu or on a real N900. It does very little hardware config
> >>> because NOLO has already configured the board. Only needed is enabling
> >>> internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
> >>> @@ -8,64 +9,64 @@ internal eMMC memory via twl4030 regulator which is not
> >>> enabled by NOLO.
> >>> NOLO is expecting a kernel image and will treat any image it finds in
> >>> onenand as such. This u-boot is intended to be flashed to the N900 like
> >>> a kernel. In order to transparently boot the original kernel, it will be
> >>> -appended to u-boot.bin at 0x4. NOLO will load the entire image into
> >>> +appended to ``u-boot.bin`` at 0x4. NOLO will load the entire image
> >>> into
> >>> (random) memory and execute u-boot, which saves hw revision, boot reason
> >>> and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to
> >>> load
> >>> -uImage, zImage or boot.scr from a fat or ext2/3/4 filesystem on external
> >>> -SD card or internal eMMC memory. If this fails or keyboard is closed then
> >>> -the appended kernel image will be booted using some generated and some
> >>> -stored ATAGs (see boot order).
> >>> +``uImage``, ``zImage`` or ``boot.scr`` file from a fat or ext2/3/4
> >>> filesystem
> >>> +on external SD card or internal eMMC memory. If this fails or keyboard is
> >>> +closed then the appended kernel image will be booted using some generated
> >>> +and some stored ATAGs (see boot order).
> >>>
> >>> For generating combined image of u-boot and kernel (either in uImage or
> >>> zImage
> >>> -format) there is a simple script called u-boot-gen-combined. It is
> >>> available in
> >>> -following repository:
> >>> +format) there is a simple script called ``u-boot-gen-combined``. It is
> >>> available
> >>> +in following repository:
> >>>
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wednesday 04 August 2021 17:43:41 Sean Anderson wrote: > On 8/2/21 3:21 PM, Simon Glass wrote: > > Hi Pali, > > > > On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: > > > > > > Header file version.h does not use anything from timestamp.h. Including of > > > timestamp.h has side effect which cause recompiling object file at every > > > make run because timestamp.h changes at every run. > > > > > > So remove timestamp.h from version.h and include timestamp.h in files > > > which needs it. > > > > > > This change reduce recompilation time of final U-Boot binary when U-Boot > > > source files were not changed as less source files needs to be recompiled. > > > > > > Signed-off-by: Pali Rohár > > > --- > > > arch/arm/mach-rockchip/tpl.c | 4 > > > board/work-microwave/work_92105/work_92105_display.c | 1 + > > > cmd/version.c| 1 + > > > common/spl/spl.c | 4 > > > drivers/rtc/emul_rtc.c | 2 +- > > > include/version.h| 2 -- > > > 6 files changed, 11 insertions(+), 3 deletions(-) > > > > Reviewed-by: Simon Glass > > > > I assume we do actually want to regenerate the timestamp when U-Boot > > builds, even if nothing has changed. Is that right? > > I know this is the current behavior, but it would be nice if this was > not the case. If one is building U-Boot as part of a larger project, one > might want to have a makefile rule like > > u-boot/u-boot.bin: > $(MAKE) -C u-boot $(@F) You are missing 'FORCE' prerequisite for u-boot/u-boot.bin target (but I understand what you mean; I'm using this stuff too). > but u-boot/u-boot.bin will always be remade even if no changes have been > done. This will cause make to remake all dependents of U-Boot as well > (which can be rather time-consuming). > > At the moment, I just use U-Boot as an order-only dependency and remake > it manually. But I would love it if U-Boot was only remade if > dependencies had actually changed, since this would make it easier to > integrate it with the rest of my build system. This behavior which you described is e.g. used by Linux kernel build system (also based on Makefile(s) and Kbuild as U-Boot). Maybe we can discuss if such change can or cannot be useful for U-Boot too. But to not make another confusion, it is not part and it is not related to this my patch series. So I would suggest to discuss about it in separate / new thread (fell free to CC me).
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wednesday 04 August 2021 10:40:42 Tom Rini wrote: > On Wed, Aug 04, 2021 at 08:36:27AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 4 Aug 2021 at 06:44, Tom Rini wrote: > > > > > > On Wed, Aug 04, 2021 at 07:59:21AM +0200, Wolfgang Denk wrote: > > > > > > > Dear Tom, > > > > > > > > In message <20210802213100.GG9379@bill-the-cat> you wrote: > > > > > > > > > > I think that if nothing changes the banner not changing is the right > > > > > behavior. > > > > > > > > Hm... is it? How about "external" changes like building with a > > > > different tool chain? Then at least the "version" command should > > > > produce a corresponding output, which means some parts _have_ to be > > > > recompiled, resulting in a new banner, too ? > > > > > > There's some misunderstanding about what this series does, and does not > > > do. First, with the series applied and you don't force > > > SOURCE_DATE_EPOCH, and you run make, and you re-run make, cmd/version.c > > > is rebuilt (but only that and not a bunch of other things anymore) and > > > the banner timestamp changes. Second, if you do set SOURCE_DATE_EPOCH > > > to a fixed value (so you're trying to reproduce a build with a specific > > > timestamp) AND re-run make, nothing changes, as it should. Third, if > > > you change gcc, everything gets rebuilt including cmd/version.c and a > > > new banner. > > > > Yes that's my understanding and it seems fine. > > To be clear, I did a quick test with the series (git pw is very handy) > for the above. Thanks for clarification! You are of course right.
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On 8/2/21 3:21 PM, Simon Glass wrote: Hi Pali, On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: Header file version.h does not use anything from timestamp.h. Including of timestamp.h has side effect which cause recompiling object file at every make run because timestamp.h changes at every run. So remove timestamp.h from version.h and include timestamp.h in files which needs it. This change reduce recompilation time of final U-Boot binary when U-Boot source files were not changed as less source files needs to be recompiled. Signed-off-by: Pali Rohár --- arch/arm/mach-rockchip/tpl.c | 4 board/work-microwave/work_92105/work_92105_display.c | 1 + cmd/version.c| 1 + common/spl/spl.c | 4 drivers/rtc/emul_rtc.c | 2 +- include/version.h| 2 -- 6 files changed, 11 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass I assume we do actually want to regenerate the timestamp when U-Boot builds, even if nothing has changed. Is that right? I know this is the current behavior, but it would be nice if this was not the case. If one is building U-Boot as part of a larger project, one might want to have a makefile rule like u-boot/u-boot.bin: $(MAKE) -C u-boot $(@F) but u-boot/u-boot.bin will always be remade even if no changes have been done. This will cause make to remake all dependents of U-Boot as well (which can be rather time-consuming). At the moment, I just use U-Boot as an order-only dependency and remake it manually. But I would love it if U-Boot was only remade if dependencies had actually changed, since this would make it easier to integrate it with the rest of my build system. --Sean
am335x_evm: failed to boot via USB
Hi, I am trying to boot an am335x based board (BeagleBone Black) from USB using v2021.07. I see the following issue when trying to boot via USB (USB based network): U-Boot SPL 2021.07-00013-gd0f1ad9f23 (Aug 02 2021 - 21:29:57 +0300) Trying to boot from USB eth ## Error: flags type check failure for "ethaddr" <= "40309614M" (type: m) ## Error inserting "ethaddr" variable, errno=1 eth0: eth_cpsw## Error: flags type check failure for "eth1addr" <= "81f01114M" (type: m) ## Error inserting "eth1addr" variable, errno=1 , eth1: usb_ether eth_cpsw Waiting for PHY auto negotiation to complete. TIMEOUT ! Problem booting with BOOTP SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I suppose that _env_flags_validate_type doesn't like this "M" suffix. But I don't know where it came from. -- With best regards, Matwey V. Kornilov
Re: [PATCH v3 2/3] arm: Add an __image_copy_start symbol for ARMv8
On Sun, 2021-08-01 at 14:59 -0600, Simon Glass wrote:
> This symbol is needed for binman to locate the start of the image. Add it.
>
> Note: the existing line to bring in the .__image_copy_start symbol does
> not appear to do anything.
>
> Signed-off-by: Simon Glass
> ---
> I have copied Scott Wood who originally added the line about the
> __image_copy_start in the hope that he can decide if we should remove it.
It's been a long time since I looked at this stuff, but __image_copy_start is
used for relocation and that code does not seem to be in the SPL, so the
*(.__image_copy_start) was probably just a copy-and-paste leftover from the
main SPL that can go away.
Of course, that doesn't resolve the binman issue. :-)
> diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-
> spl.lds
> index 9edb662b094..2827a07590d 100644
> --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> @@ -22,6 +22,7 @@ ENTRY(_start)
> SECTIONS
> {
> .text : {
> + __image_copy_start = .;
> . = ALIGN(8);
> *(.__image_copy_start)
> CPUDIR/start.o (.text*)
If for whatever reason you did need to define the symbol this way, shouldn't
it be after the alignment?
-Scott
Re: [PATCH] CI: Update to LLVM-12
On Thu, Jul 15, 2021 at 02:24:25PM -0400, Tom Rini wrote: > The current stable release of LLVM is 12, update to that. While at it, > fix that we had not correctly upgraded to LLVM 11 previously. > > Signed-off-by: Tom Rini Updated to latest "focal" snapshot and applied to u-boot/master. -- Tom signature.asc Description: PGP signature
Re: Proposal: U-Boot MTD (rewriting old story)
On Wed, Aug 04, 2021 at 10:09:55AM -0600, Simon Glass wrote: > Hi Jagan, > > On Tue, 3 Aug 2021 at 09:01, Jagan Teki wrote: > > > > Yes, this is the old discussion and triggered again now since we had a > > discussion on the last U-Boot contributor call. > > > > I will brief the main points here, as most of the details are > > mentioned in previous threads. > > > > Here are the couple of old and new implementations on the SPI-NOR side. > > > > http://u-boot.10912.n7.nabble.com/PATCH-v10-00-27-dm-Generic-MTD-Subsystem-with-SPI-NOR-interface-tt315694.html#none > > http://u-boot.10912.n7.nabble.com/PATCH-0-5-mtd-Implement-MTD-UCLASS-use-SPINOR-td419538.html#a419541 > > https://patchwork.ozlabs.org/project/uboot/cover/20200709111709.68904-1-ja...@amarulasolutions.com/ > > > > Idea is to > > 1. Create MTD_UCLASS, already present > > 2. Create DM MTD Operations, above patchset does. > > 3. Create Flash specific MTD UClass's like > > UCLASS_NAND > > UCLASS_SPI_NAND > > UCLASS_SPI_NOR > > UCLASS_NOR > > UCLASS_UBI > > and register to UCLASS_MTD as interface slaves like how MMC, SCSI are > > registered to UCLASS_BLK > > 4. Sync only respective flash specific code, and drop __UBOOT__ > > 5. Interface mtd, sf, and nand commands to UCLASS_MTD. > > This all seems good to me. > > > > > Hard points: > > 1. Hard to arrange Linux specific code and drop unneeded _UBOOT_ code, > > but possible. > > 2. Requires a lot of testing. > > Let's add simple emulators for NAND, SPI_NAND and UBI. We already have > one for SPI_NOR I believe. That will be a good long-term investment. What are our viable options here via QEMU? -- Tom signature.asc Description: PGP signature
[PATCH] board: ge: bx50v3: Add PCIe reset to DT
Add PCIe reset gpio to the Bx50v3 devicetree and get get rid of
CONFIG_PCIE_IMX_PERST_GPIO.
Signed-off-by: Sebastian Reichel
---
arch/arm/dts/imx6q-bx50v3-uboot.dtsi | 10 ++
include/configs/ge_bx50v3.h | 1 -
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6q-bx50v3-uboot.dtsi
b/arch/arm/dts/imx6q-bx50v3-uboot.dtsi
index b54e8e6ada74..0253d2fa6f5b 100644
--- a/arch/arm/dts/imx6q-bx50v3-uboot.dtsi
+++ b/arch/arm/dts/imx6q-bx50v3-uboot.dtsi
@@ -47,3 +47,13 @@
phy-reset-duration = <1>;
phy-reset-post-delay = <0>;
};
+
+/*
+ * PCIe reset is not done in the file shared with the kernel, since
+ * this GPIO also resets other peripherals (i.e. not just PCIe).
+ * These peripherals are being initialized by U-Boot and should not
+ * be reset by the kernel, so it may not reset PCIe via this GPIO.
+ */
+ {
+ reset-gpio = < 12 GPIO_ACTIVE_LOW>;
+};
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index 8764efa95bec..baf1a84bffe2 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -153,7 +153,6 @@
#define CONFIG_PCI_SCAN_SHOW
#define CONFIG_PCIE_IMX
-#define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(7, 12)
#define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(1, 5)
#endif /* __GE_BX50V3_CONFIG_H */
--
2.30.2
Re: Proposal: U-Boot MTD (rewriting old story)
Hi Jagan, On Tue, 3 Aug 2021 at 09:01, Jagan Teki wrote: > > Yes, this is the old discussion and triggered again now since we had a > discussion on the last U-Boot contributor call. > > I will brief the main points here, as most of the details are > mentioned in previous threads. > > Here are the couple of old and new implementations on the SPI-NOR side. > > http://u-boot.10912.n7.nabble.com/PATCH-v10-00-27-dm-Generic-MTD-Subsystem-with-SPI-NOR-interface-tt315694.html#none > http://u-boot.10912.n7.nabble.com/PATCH-0-5-mtd-Implement-MTD-UCLASS-use-SPINOR-td419538.html#a419541 > https://patchwork.ozlabs.org/project/uboot/cover/20200709111709.68904-1-ja...@amarulasolutions.com/ > > Idea is to > 1. Create MTD_UCLASS, already present > 2. Create DM MTD Operations, above patchset does. > 3. Create Flash specific MTD UClass's like > UCLASS_NAND > UCLASS_SPI_NAND > UCLASS_SPI_NOR > UCLASS_NOR > UCLASS_UBI > and register to UCLASS_MTD as interface slaves like how MMC, SCSI are > registered to UCLASS_BLK > 4. Sync only respective flash specific code, and drop __UBOOT__ > 5. Interface mtd, sf, and nand commands to UCLASS_MTD. This all seems good to me. > > Hard points: > 1. Hard to arrange Linux specific code and drop unneeded _UBOOT_ code, > but possible. > 2. Requires a lot of testing. Let's add simple emulators for NAND, SPI_NAND and UBI. We already have one for SPI_NOR I believe. That will be a good long-term investment. Regards, Simon
Re: [PATCH v2 2/3] Revert "mkeficapsule: Remove dtb related options"
Hi Takahiro,
On Mon, 2 Aug 2021 at 23:30, KASHI Takahiro wrote:
>
> Simon,
>
> On Mon, Aug 02, 2021 at 08:44:30AM -0600, Simon Glass wrote:
> > This reverts commit f86caab058ff062ce72b24cd1ab9ec1253cc1352.
>
> Whether we choose a devicetree approach or not, we don't have
> to revert this patch because we can do the same thing with
> standard commands (i.e. fdtoverlay).
>
> See my patches and discussions[1].
> (We all agreed to removing this feature from mkeficapsule.)
Well this just shows that I am not the right person to be sorting out
this mess. Can someone in the team working on come up with the right
fix?
Regards,
Simon
>
> [1] https://lists.denx.de/pipermail/u-boot/2021-May/449573.html
> https://lists.denx.de/pipermail/u-boot/2021-May/449574.html
>
> -Takahiro Akashi
>
>
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > tools/mkeficapsule.c | 229 +--
> > 1 file changed, 222 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > index 4995ba4e0c2..de0a6289888 100644
> > --- a/tools/mkeficapsule.c
> > +++ b/tools/mkeficapsule.c
> > @@ -4,17 +4,22 @@
> > * Author: AKASHI Takahiro
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > +#include
> > #include
> > #include
> >
> > +#include "fdt_host.h"
> > +
> > typedef __u8 u8;
> > typedef __u16 u16;
> > typedef __u32 u32;
> > @@ -24,6 +29,9 @@ typedef __s32 s32;
> >
> > #define aligned_u64 __aligned_u64
> >
> > +#define SIGNATURE_NODENAME "signature"
> > +#define OVERLAY_NODENAME "__overlay__"
> > +
> > #ifndef __packed
> > #define __packed __attribute__((packed))
> > #endif
> > @@ -44,6 +52,9 @@ static struct option options[] = {
> > {"raw", required_argument, NULL, 'r'},
> > {"index", required_argument, NULL, 'i'},
> > {"instance", required_argument, NULL, 'I'},
> > + {"dtb", required_argument, NULL, 'D'},
> > + {"public key", required_argument, NULL, 'K'},
> > + {"overlay", no_argument, NULL, 'O'},
> > {"help", no_argument, NULL, 'h'},
> > {NULL, 0, NULL, 0},
> > };
> > @@ -57,10 +68,187 @@ static void print_usage(void)
> > "\t-r, --rawnew raw image file\n"
> > "\t-i, --index update image index\n"
> > "\t-I, --instanceupdate hardware instance\n"
> > +"\t-K, --public-key public key esl file\n"
> > +"\t-D, --dtb dtb file\n"
> > +"\t-O, --overlay the dtb file is an overlay\n"
> > "\t-h, --help print a help message\n",
> > tool_name);
> > }
> >
> > +static int fdt_add_pub_key_data(void *sptr, void *dptr, size_t key_size,
> > + bool overlay)
> > +{
> > + int parent;
> > + int ov_node;
> > + int frag_node;
> > + int ret = 0;
> > +
> > + if (overlay) {
> > + /*
> > + * The signature would be stored in the
> > + * first fragment node of the overlay
> > + */
> > + frag_node = fdt_first_subnode(dptr, 0);
> > + if (frag_node == -FDT_ERR_NOTFOUND) {
> > + fprintf(stderr,
> > + "Couldn't find the fragment node: %s\n",
> > + fdt_strerror(frag_node));
> > + goto done;
> > + }
> > +
> > + ov_node = fdt_subnode_offset(dptr, frag_node,
> > OVERLAY_NODENAME);
> > + if (ov_node == -FDT_ERR_NOTFOUND) {
> > + fprintf(stderr,
> > + "Couldn't find the __overlay__ node: %s\n",
> > + fdt_strerror(ov_node));
> > + goto done;
> > + }
> > + } else {
> > + ov_node = 0;
> > + }
> > +
> > + parent = fdt_subnode_offset(dptr, ov_node, SIGNATURE_NODENAME);
> > + if (parent == -FDT_ERR_NOTFOUND) {
> > + parent = fdt_add_subnode(dptr, ov_node, SIGNATURE_NODENAME);
> > + if (parent < 0) {
> > + ret = parent;
> > + if (ret != -FDT_ERR_NOSPACE) {
> > + fprintf(stderr,
> > + "Couldn't create signature node:
> > %s\n",
> > + fdt_strerror(parent));
> > + }
> > + }
> > + }
> > + if (ret)
> > + goto done;
> > +
> > + /* Write the key to the FDT node */
> > + ret = fdt_setprop(dptr, parent, "capsule-key",
> > + sptr, key_size);
> > +
> > +done:
> > + if (ret)
> > + ret = ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
> > +
> > + return ret;
> > +}
> > +
> > +static int add_public_key(const char
Re: [PATCH] Revert "efi_capsule: Move signature from DTB to .rodata"
Hi Takahiro, On Mon, 2 Aug 2021 at 18:21, KASHI Takahiro wrote: > > On Mon, Aug 02, 2021 at 08:44:41AM -0600, Simon Glass wrote: > > Hi, > > > > On Mon, 2 Aug 2021 at 01:15, KASHI Takahiro > > wrote: > > > > > > On Sun, Aug 01, 2021 at 08:47:15PM -0600, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Sun, 1 Aug 2021 at 20:28, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Sun, Aug 01, 2021 at 07:46:21PM -0600, Simon Glass wrote: > > > > > > This was unfortunately applied despite much discussion about it > > > > > > being > > > > > > the wrong way to implement this feature. > > > > > > > > > > No this was applied *before* the discussion, not despite. > > > > > > > > Oh sorry...I didn't notice either way. Normally there is an email on > > > > the patch saying it was applied. Perhaps I missed it. > > > > > > > > > > > > > > > > > > > > > Revert it before too many other things are built on top of it. > > > > > > > > > > I don't really mind if this gets reverted but there's things that > > > > > haven't > > > > > been answered on that discussion [1] and my concern is what happens if > > > > > CONFIG_OF_EMBED is not selected. > > > > > > > > Can we start a new discussion perhaps? Or use one of the contributor > > > > calls to talk about it? > > > > > > > > We should not be using OF_EMBED except for testing. > > > > > > > > > > > > > > Also you need to revert the entire series, not just one of the > > > > > patches, > > > > > as it changes the QEMU documentation for enabling authenticated > > > > > capsule > > > > > updates, as well as the mkeficapsule app. > > > > > > > > Heinrich, do you have any thoughts on this? > > > > > > # I'm not Heinrich :) > > > > Perhaps you could impersonate him :-) I ask because he had been doing > > a lot of EFI work. > > I know. I was just kidding :) > > > > > > > As far as the authentication logic itself is concerned, > > > it is utterly generic except how and from where a public key is > > > retrieved. (It can potentially be platform-specific.) > > > Moreover, mkeficapsule really doesn't care where the key is. > > > > > > So I don't think we need revert all those changes. > > > > I agree. Having another look, I think perhaps three patches is enough. > > I will try again. > > > > > > > > For testing, we can run a test on sandbox by having sandbox-specific > > > efi_get_public_key_data() function, i.e. we may want to contain > > > the key in a file on ESP or just in a specific flash partition. > > > > > > Obviously, it's not safe, but it's just a test to verify that the logic > > > is sane. > > > > > > If the discussion goes on for an unexpected spell of time, > > > I would like to take this workaround for now. > > > > I think this effort should go back to before the change to putting > > things in rodata. That was when things went really off the rails. > > > > With things back in the DT, you should be able to write a test with > > the existing sandbox build without any special-case code. > > Well, that is the way I have adopted in my v1 patch[1]. > I hope that the discussion be settled first. Yes, that looks a lot better. I cannot see why it was not applied at the time. > > -Takahiro Akashi > > [1] https://lists.denx.de/pipermail/u-boot/2021-May/449575.html > > Regards, SImon
Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable
On Fri, Jul 23, 2021 at 06:18:26AM -0600, Ashok Reddy Soma wrote: > From: T Karthik Reddy > > Tpm test cases relies on tpm device setup. Provide an environment > variable "env__tpm_device_test_skip = True" to skip the test case > if tpm device is not present. > Only needed will have to add variable to the py-test framework. > Test runs successfully even this variable is absent. > > Signed-off-by: T Karthik Reddy > Signed-off-by: Ashok Reddy Soma Why is this not using boardenv_* like other tests do to disable running? -- Tom signature.asc Description: PGP signature
[PATCH] ARM: mach-at91: fix multiple cpu_reset definition when enabling SYSRESET
When SYSRESET is enabled, cpu_reset function is also defined in sysreset-uclass.c which lead to multiple definitions of this function since reset.c is build unconditionally. Add a check in Makefile to build this file only if SYSRESET isn't enabled. SYSRESET can be enabled when building SYSRESET_PSCI for instance on this platform. Signed-off-by: Clément Léger --- arch/arm/mach-at91/armv7/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-at91/armv7/Makefile b/arch/arm/mach-at91/armv7/Makefile index f5b2665957..246050b67b 100644 --- a/arch/arm/mach-at91/armv7/Makefile +++ b/arch/arm/mach-at91/armv7/Makefile @@ -11,7 +11,9 @@ obj-$(CONFIG_SAMA5D3) += sama5d3_devices.o clock.o obj-$(CONFIG_SAMA5D4) += sama5d4_devices.o clock.o obj-$(CONFIG_SAMA7G5) += sama7g5_devices.o obj-y += cpu.o -obj-y += reset.o +ifndef CONFIG_$(SPL_TPL_)SYSRESET +obj-y += reset.o +endif ifneq ($(CONFIG_ATMEL_PIT_TIMER),y) ifneq ($(CONFIG_MCHP_PIT64B_TIMER),y) # old non-DM timer driver -- 2.32.0
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wed, Aug 04, 2021 at 08:36:27AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 4 Aug 2021 at 06:44, Tom Rini wrote: > > > > On Wed, Aug 04, 2021 at 07:59:21AM +0200, Wolfgang Denk wrote: > > > > > Dear Tom, > > > > > > In message <20210802213100.GG9379@bill-the-cat> you wrote: > > > > > > > > I think that if nothing changes the banner not changing is the right > > > > behavior. > > > > > > Hm... is it? How about "external" changes like building with a > > > different tool chain? Then at least the "version" command should > > > produce a corresponding output, which means some parts _have_ to be > > > recompiled, resulting in a new banner, too ? > > > > There's some misunderstanding about what this series does, and does not > > do. First, with the series applied and you don't force > > SOURCE_DATE_EPOCH, and you run make, and you re-run make, cmd/version.c > > is rebuilt (but only that and not a bunch of other things anymore) and > > the banner timestamp changes. Second, if you do set SOURCE_DATE_EPOCH > > to a fixed value (so you're trying to reproduce a build with a specific > > timestamp) AND re-run make, nothing changes, as it should. Third, if > > you change gcc, everything gets rebuilt including cmd/version.c and a > > new banner. > > Yes that's my understanding and it seems fine. To be clear, I did a quick test with the series (git pw is very handy) for the above. -- Tom signature.asc Description: PGP signature
[PATCH v3] mmc: Add support for enumerating MMC card in a given mode using mmc command
Add support for enumerating MMC card in a given mode using mmc rescan and
mmc dev commands. The speed mode is provided as the last argument in these
commands and is indicated using the index from enum bus_mode in
include/mmc.h. A speed mode can be set only if it has already been enabled
in the device tree.
Signed-off-by: Aswath Govindraju
---
Changes since v2:
- made init_mmc_device as wrapper function around __init_mmc_device
- rebased on top of latest master
- used dectoul() instead of simple_strtoul() whereever possible
Changes since v1:
- Removed #ifdef around the definition of user_speed_mode field
- Replaced #if with if (IS_ENABLED())
- Removed repeated MMC_CAP(MMC_LEGACY)
- initialized user_speed_mode to MMC_MODES_SPEED in mmc_init_device
and mmc_dp_preinit
- corrected curr_device to dev and included part check, the case when
mode is provided in the argument
cmd/Kconfig | 10
cmd/mmc.c| 52 +---
doc/usage/mmc.rst| 49 +++--
drivers/mmc/mmc-uclass.c | 5 +++-
drivers/mmc/mmc.c| 22 -
include/mmc.h| 2 ++
6 files changed, 128 insertions(+), 12 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ffef3cc76ca4..3a857b3f6e2e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2389,4 +2389,14 @@ config CMD_UBIFS
help
UBIFS is a file system for flash devices which works on top of UBI.
+config MMC_SPEED_MODE_SET
+ bool "set speed mode using mmc command"
+ depends on CMD_MMC
+ default n
+ help
+ Enable setting speed mode using mmc rescan and mmc dev commands.
+ The speed mode is provided as the last argument in these commands
+ and is indicated using the index from enum bus_mode in
+ include/mmc.h. A speed mode can be set only if it has already
+ been enabled in the device tree.
endmenu
diff --git a/cmd/mmc.c b/cmd/mmc.c
index c67ad7624227..f1e30d0cf64b 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
}
}
}
-static struct mmc *init_mmc_device(int dev, bool force_init)
+
+static struct mmc *__init_mmc_device(int dev, bool force_init,
+enum bus_mode speed_mode)
{
struct mmc *mmc;
mmc = find_mmc_device(dev);
@@ -134,6 +136,10 @@ static struct mmc *init_mmc_device(int dev, bool
force_init)
if (force_init)
mmc->has_init = 0;
+
+ if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET))
+ mmc->user_speed_mode = speed_mode;
+
if (mmc_init(mmc))
return NULL;
@@ -145,6 +151,11 @@ static struct mmc *init_mmc_device(int dev, bool
force_init)
return mmc;
}
+static struct mmc *init_mmc_device(int dev, bool force_init)
+{
+ return __init_mmc_device(dev, force_init, MMC_MODES_END);
+}
+
static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
@@ -482,8 +493,17 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
struct mmc *mmc;
+ enum bus_mode speed_mode = MMC_MODES_END;
+
+ if (argc == 1) {
+ mmc = init_mmc_device(curr_device, true);
+ } else if (argc == 2) {
+ speed_mode = (int)dectoul(argv[1], NULL);
+ mmc = __init_mmc_device(curr_device, true, speed_mode);
+ } else {
+ return CMD_RET_USAGE;
+ }
- mmc = init_mmc_device(curr_device, true);
if (!mmc)
return CMD_RET_FAILURE;
@@ -515,11 +535,14 @@ static int do_mmc_dev(struct cmd_tbl *cmdtp, int flag,
{
int dev, part = 0, ret;
struct mmc *mmc;
+ enum bus_mode speed_mode = MMC_MODES_END;
if (argc == 1) {
dev = curr_device;
+ mmc = init_mmc_device(dev, true);
} else if (argc == 2) {
- dev = dectoul(argv[1], NULL);
+ dev = (int)dectoul(argv[1], NULL);
+ mmc = init_mmc_device(dev, true);
} else if (argc == 3) {
dev = (int)dectoul(argv[1], NULL);
part = (int)dectoul(argv[2], NULL);
@@ -528,11 +551,21 @@ static int do_mmc_dev(struct cmd_tbl *cmdtp, int flag,
PART_ACCESS_MASK);
return CMD_RET_FAILURE;
}
+ mmc = init_mmc_device(dev, true);
+ } else if (argc == 4) {
+ dev = (int)dectoul(argv[1], NULL);
+ part = (int)dectoul(argv[2], NULL);
+ if (part > PART_ACCESS_MASK) {
+ printf("#part_num shouldn't be larger than %d\n",
+ PART_ACCESS_MASK);
+ return CMD_RET_FAILURE;
+ }
+ speed_mode = (int)dectoul(argv[3],
Re: [PATCH 11/11] Remove including timestamp.h in version.h
Hi Tom, On Wed, 4 Aug 2021 at 06:44, Tom Rini wrote: > > On Wed, Aug 04, 2021 at 07:59:21AM +0200, Wolfgang Denk wrote: > > > Dear Tom, > > > > In message <20210802213100.GG9379@bill-the-cat> you wrote: > > > > > > I think that if nothing changes the banner not changing is the right > > > behavior. > > > > Hm... is it? How about "external" changes like building with a > > different tool chain? Then at least the "version" command should > > produce a corresponding output, which means some parts _have_ to be > > recompiled, resulting in a new banner, too ? > > There's some misunderstanding about what this series does, and does not > do. First, with the series applied and you don't force > SOURCE_DATE_EPOCH, and you run make, and you re-run make, cmd/version.c > is rebuilt (but only that and not a bunch of other things anymore) and > the banner timestamp changes. Second, if you do set SOURCE_DATE_EPOCH > to a fixed value (so you're trying to reproduce a build with a specific > timestamp) AND re-run make, nothing changes, as it should. Third, if > you change gcc, everything gets rebuilt including cmd/version.c and a > new banner. Yes that's my understanding and it seems fine. Regards, Simon
Re: [PATCH v3 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()
Hi Rasmus, On Tue, 3 Aug 2021 at 00:48, Rasmus Villemoes wrote: > > On 02/08/2021 21.20, Simon Glass wrote: > > Hi Rasmus, > > > >> But let me one last time repeat why I think the post_probe approach is > >> the cleanest and a natural fit for DM: post_probe is (AIUI) a place > >> where a uclass can do some action it wants done for every device > >> belonging to that uclass. When CONFIG_WATCHDOG_AUTOSTART is set, > >> wdt_uclass does have such an action. When it's not set, the post_probe > >> method is a no-op. > > > > I can certainly see you point. It definitely looks very natural for DM. > > > > But I still think the problem of a device possibly resetting the board > > when probed (despite the various watchdog-reset things sprinkled > > throughout the code) > > But that is the _very point_ of having the developer be able to opt in > [1] to starting the watchdog device ASAP (i.e. as soon as U-Boot is > capable of handling it). If some part of the boot process hangs or > U-Boot goes into an inf-loop without hitting a WATCHDOG_RESET in there, > one wants (or may want) the board to reset and hopefully follow some > other path the next time around. If the developer/project doesn't want > or need that, WATCHDOG_AUTOSTART can be disabled. And if the developer That requires a rebuild though. This is more of a driver-model thing than anything else and I know it seems like a minor point. But the way it is designed at present, probing a device should get it ready for use and not actually start it doing something. That is the way all(?) devices work and I think it makes sense to keep watchdogs consistent with that. > wants to make use of this, it makes sense to have the watchdog device > monitor as much of the boot process as possible. This is not an issue, since you enable all watchdogs immediately at present. > > [1] ok, for historical reasons it's default-y, so actually an opt-out > knob, but the developer does have a choice regardless. > Regards, Simon
Re: [PATCH v2] mmc: Add support for enumerating MMC card in a given mode using mmc command
Hi Jaehoon,
On 02/08/21 3:26 am, Jaehoon Chung wrote:
> Hi Aswath,
>
> On 7/30/21 9:26 PM, Aswath Govindraju wrote:
>> Add support for enumerating MMC card in a given mode using mmc rescan and
>> mmc dev commands. The speed mode is provided as the last argument in these
>> commands and is indicated using the index from enum bus_mode in
>> include/mmc.h. A speed mode can be set only if it has already been enabled
>> in the device tree.
>>
>> Signed-off-by: Aswath Govindraju
>> ---
>>
>> Changes since v1:
>> - Removed #ifdef around the definition of user_speed_mode field
>> - Replaced #if with if (IS_ENABLED())
>> - Removed repeated MMC_CAP(MMC_LEGACY)
>> - initialized user_speed_mode to MMC_MODES_SPEED in mmc_init_device
>> and mmc_dp_preinit
>> - corrected curr_device to dev and included part check, the case when
>> mode is provided in the argument
>>
>> cmd/Kconfig | 10 ++
>> cmd/mmc.c| 75 +---
>> doc/usage/mmc.rst| 49 --
>> drivers/mmc/mmc-uclass.c | 5 ++-
>> drivers/mmc/mmc.c| 22 +++-
>> include/mmc.h| 2 ++
>> 6 files changed, 138 insertions(+), 25 deletions(-)
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index ffef3cc76ca4..3a857b3f6e2e 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
>> help
>>UBIFS is a file system for flash devices which works on top of UBI.
>>
>> +config MMC_SPEED_MODE_SET
>> +bool "set speed mode using mmc command"
>> +depends on CMD_MMC
>> +default n
>> +help
>> + Enable setting speed mode using mmc rescan and mmc dev commands.
>> + The speed mode is provided as the last argument in these commands
>> + and is indicated using the index from enum bus_mode in
>> + include/mmc.h. A speed mode can be set only if it has already
>> + been enabled in the device tree.
>> endmenu
>> diff --git a/cmd/mmc.c b/cmd/mmc.c
>> index b942576b58ac..e256210a3705 100644
>> --- a/cmd/mmc.c
>> +++ b/cmd/mmc.c
>> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
>> }
>> }
>> }
>> -static struct mmc *init_mmc_device(int dev, bool force_init)
>> +
>> +static struct mmc *init_mmc_device(int dev, bool force_init,
>> + enum bus_mode speed_mode)
>
> how about using wrapper function?
>
> static struct mmc *__init_mmc_device(int dev, bool force_init,
> enum bus_mode spped_mode)
> {
> ...
> }
>
> static struct mmc *init_mmc_device(int dev, bool force_init)
> {
> return __init_mmc_device(dev, force_init, MMC_MODES_END);
> }
>
> Then it doesn't need to touch all init_mmc_device caller.
> Just my opinion :)
>
Yeah, I think that is good idea. Will post a respin after making this
change.
Also, may I know if you were able test this patch ?
Thanks,
Aswath
> Best Regards,
> Jaehoon Chung
>
>> {
>> struct mmc *mmc;
>> mmc = find_mmc_device(dev);
>> @@ -134,6 +136,10 @@ static struct mmc *init_mmc_device(int dev, bool
>> force_init)
>>
>> if (force_init)
>> mmc->has_init = 0;
>> +
>> +if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET))
>> +mmc->user_speed_mode = speed_mode;
>> +
>> if (mmc_init(mmc))
>> return NULL;
>>
>> @@ -159,7 +165,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag,
>> int argc,
>> }
>> }
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -293,7 +299,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
>> if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
>> return CMD_RET_SUCCESS;
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -338,7 +344,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
>> blk = simple_strtoul(argv[2], NULL, 16);
>> cnt = simple_strtoul(argv[3], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -387,7 +393,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp,
>> int flag,
>> return CMD_RET_FAILURE;
>> }
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -431,7 +437,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int flag,
>> blk = simple_strtoul(argv[2], NULL, 16);
>> cnt = simple_strtoul(argv[3], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc =
[PATCH 3/3] include: configs: am64x_evm: Add env variables for booting to kernel using USB MSC device
Add env variables for booting to kernel from USB MSC device. The second
partition in the USB MSC device needs to formatted as ext4 file system with
kernel and dtb images, present in the /boot folder.
Signed-off-by: Aswath Govindraju
---
include/configs/am64x_evm.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 7c520f4395b5..f3d46449011a 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -96,6 +96,34 @@
"${bootdir}/${name_fit}\0" \
"partitions=" PARTS_DEFAULT
+#define EXTRA_ENV_AM642_BOARD_SETTING_USBMSC \
+ "args_usb=run finduuid;setenv bootargs console=${console} " \
+ "${optargs} " \
+ "root=PARTUUID=${uuid} rw " \
+ "rootfstype=${mmcrootfstype}\0" \
+ "init_usb=run args_all args_usb\0" \
+ "get_fdt_usb=load usb ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
+ "get_overlay_usb=" \
+ "fdt address ${fdtaddr};" \
+ "fdt resize 0x10;" \
+ "for overlay in $name_overlays;"\
+ "do;" \
+ "load usb ${bootpart} ${dtboaddr} ${bootdir}/${overlay} && "
\
+ "fdt apply ${dtboaddr};"\
+ "done;\0" \
+ "get_kern_usb=load usb ${bootpart} ${loadaddr} "\
+ "${bootdir}/${name_kern}\0" \
+ "get_fit_usb=load usb ${bootpart} ${addr_fit} " \
+ "${bootdir}/${name_fit}\0" \
+ "usbboot=setenv boot usb;" \
+ "setenv bootpart 0:2;" \
+ "usb start;"\
+ "run findfdt;" \
+ "run init_usb;" \
+ "run get_kern_usb;" \
+ "run get_fdt_usb;" \
+ "run run_kern\0"
+
#define EXTRA_ENV_DFUARGS \
DFU_ALT_INFO_MMC \
DFU_ALT_INFO_EMMC \
@@ -108,7 +136,8 @@
DEFAULT_MMC_TI_ARGS \
EXTRA_ENV_AM642_BOARD_SETTINGS \
EXTRA_ENV_AM642_BOARD_SETTINGS_MMC \
- EXTRA_ENV_DFUARGS
+ EXTRA_ENV_DFUARGS \
+ EXTRA_ENV_AM642_BOARD_SETTING_USBMSC
/* Now for the remaining common defines */
#include
--
2.17.1
[PATCH 2/3] environment: ti: mmc.h: Make the finduuid generic for usage across different device types
Make finduuid generic by making it dependent on the boot variable. For
example, this can now be used for finding the uuid of partitions in usb
device too.
Signed-off-by: Aswath Govindraju
---
include/environment/ti/mmc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
index b86c8dc7a4f3..769ea9d5ef70 100644
--- a/include/environment/ti/mmc.h
+++ b/include/environment/ti/mmc.h
@@ -11,7 +11,7 @@
#define DEFAULT_MMC_TI_ARGS \
"mmcdev=0\0" \
"mmcrootfstype=ext4 rootwait\0" \
- "finduuid=part uuid mmc ${bootpart} uuid\0" \
+ "finduuid=part uuid ${boot} ${bootpart} uuid\0" \
"args_mmc=run finduuid;setenv bootargs console=${console} " \
"${optargs} " \
"root=PARTUUID=${uuid} rw " \
--
2.17.1
[PATCH 1/3] board: ti: am64x: Add support for fixing dr_mode while booting from USB
Fix the dr_mode in the U-Boot device tree blob, by reading the mode field
from the USB Boot Configuration fields. The dr_mode will only be fixed when
booting from USB.
Signed-off-by: Aswath Govindraju
---
board/ti/am64x/evm.c | 32
1 file changed, 32 insertions(+)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 21c58c76d67a..1a9f69c6cf1b 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -60,6 +61,37 @@ int board_fit_config_name_match(const char *name)
}
#endif
+#if defined(CONFIG_SPL_BUILD) && CONFIG_IS_ENABLED(USB_STORAGE)
+static int fixup_usb_boot(const void *fdt_blob)
+{
+ int ret = 0;
+
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_USB:
+ /*
+* If the boot mode is host, fixup the dr_mode to host
+* before cdns3 bind takes place
+*/
+ ret = fdt_find_and_setprop((void *)fdt_blob,
+
"/bus@f4000/cdns-usb@f90/usb@f40",
+ "dr_mode", "host", 5, 0);
+ if (ret)
+ printf("%s: fdt_find_and_setprop() failed:%d\n",
+ __func__, ret);
+ fallthrough;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
+void spl_perform_fixups(struct spl_image_info *spl_image)
+{
+ fixup_usb_boot(spl_image->fdt_addr);
+}
+#endif
+
#ifdef CONFIG_TI_I2C_BOARD_DETECT
int do_board_detect(void)
{
--
2.17.1
[PATCH 0/3] AM64: Add support for booting to kernel from USB MSC device
The following series of patches add support for booting to kernel using USB MSC device as the boot media, in AM64 Aswath Govindraju (3): board: ti: am64x: Add support for fixing dr_mode while booting from USB environment: ti: mmc.h: Make the finduuid generic for usage across different device types include: configs: am64x_evm: Add env variables for booting to kernel using USB MSC device board/ti/am64x/evm.c | 32 include/configs/am64x_evm.h | 31 ++- include/environment/ti/mmc.h | 2 +- 3 files changed, 63 insertions(+), 2 deletions(-) -- 2.17.1
Re: [PATCH] board: amlogic: odroid-n2: fix fdtfile suffix for n2-plus
On 04/08/2021 13:01, Christian Hewitt wrote:
> The N2+ dtb is meson-g12b-odroid-n2-plus.dtb, not n2_plus, so
> correct the suffix provided in the board file. Also align the
> board ident string shown during boot to match.
>
> Fixes: 8bc780106c13 ("board: amlogic: odroid: add runtime detection of the
> N2/N2+/C4/HC4 variants")
> Signed-off-by: Christian Hewitt
> ---
> board/amlogic/odroid-n2/odroid-n2.c | 2 +-
> configs/odroid-n2_defconfig | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/amlogic/odroid-n2/odroid-n2.c
> b/board/amlogic/odroid-n2/odroid-n2.c
> index 88a60f34fe..acfd107fc5 100644
> --- a/board/amlogic/odroid-n2/odroid-n2.c
> +++ b/board/amlogic/odroid-n2/odroid-n2.c
> @@ -48,7 +48,7 @@ static struct meson_odroid_boards {
> /* OdroidN2 rev 2019,2,7 */
> { MESON_SOC_ID_G12B, 330 * 4, 350 * 4, "n2" },
> /* OdroidN2plus rev 2019,11,20 */
> - { MESON_SOC_ID_G12B, 410 * 4, 430 * 4, "n2_plus" },
> + { MESON_SOC_ID_G12B, 410 * 4, 430 * 4, "n2-plus" },
> /* OdroidC4 rev 2020,01,29 */
> { MESON_SOC_ID_SM1, 80 * 4, 100 * 4, "c4" },
> /* OdroidHC4 rev 2019,12,10 */
> diff --git a/configs/odroid-n2_defconfig b/configs/odroid-n2_defconfig
> index bac44b61ab..1f718a3154 100644
> --- a/configs/odroid-n2_defconfig
> +++ b/configs/odroid-n2_defconfig
> @@ -9,7 +9,7 @@ CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-odroid-n2"
> CONFIG_MESON_G12A=y
> CONFIG_DEBUG_UART_BASE=0xff803000
> CONFIG_DEBUG_UART_CLOCK=2400
> -CONFIG_IDENT_STRING=" odroid-n2/n2_plus"
> +CONFIG_IDENT_STRING=" odroid-n2/n2-plus"
> CONFIG_DEBUG_UART=y
> CONFIG_OF_BOARD_SETUP=y
> # CONFIG_DISPLAY_CPUINFO is not set
>
Indeed, thx for the fix
Acked-by: Neil Armstrong
If nobody complains I'll push it at the end of the week !
Neil
Re: [PATCH 11/11] Remove including timestamp.h in version.h
On Wed, Aug 04, 2021 at 07:59:21AM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20210802213100.GG9379@bill-the-cat> you wrote: > > > > I think that if nothing changes the banner not changing is the right > > behavior. > > Hm... is it? How about "external" changes like building with a > different tool chain? Then at least the "version" command should > produce a corresponding output, which means some parts _have_ to be > recompiled, resulting in a new banner, too ? There's some misunderstanding about what this series does, and does not do. First, with the series applied and you don't force SOURCE_DATE_EPOCH, and you run make, and you re-run make, cmd/version.c is rebuilt (but only that and not a bunch of other things anymore) and the banner timestamp changes. Second, if you do set SOURCE_DATE_EPOCH to a fixed value (so you're trying to reproduce a build with a specific timestamp) AND re-run make, nothing changes, as it should. Third, if you change gcc, everything gets rebuilt including cmd/version.c and a new banner. -- Tom signature.asc Description: PGP signature
[PATCH] board: amlogic: odroid-n2: fix fdtfile suffix for n2-plus
The N2+ dtb is meson-g12b-odroid-n2-plus.dtb, not n2_plus, so
correct the suffix provided in the board file. Also align the
board ident string shown during boot to match.
Fixes: 8bc780106c13 ("board: amlogic: odroid: add runtime detection of the
N2/N2+/C4/HC4 variants")
Signed-off-by: Christian Hewitt
---
board/amlogic/odroid-n2/odroid-n2.c | 2 +-
configs/odroid-n2_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/amlogic/odroid-n2/odroid-n2.c
b/board/amlogic/odroid-n2/odroid-n2.c
index 88a60f34fe..acfd107fc5 100644
--- a/board/amlogic/odroid-n2/odroid-n2.c
+++ b/board/amlogic/odroid-n2/odroid-n2.c
@@ -48,7 +48,7 @@ static struct meson_odroid_boards {
/* OdroidN2 rev 2019,2,7 */
{ MESON_SOC_ID_G12B, 330 * 4, 350 * 4, "n2" },
/* OdroidN2plus rev 2019,11,20 */
- { MESON_SOC_ID_G12B, 410 * 4, 430 * 4, "n2_plus" },
+ { MESON_SOC_ID_G12B, 410 * 4, 430 * 4, "n2-plus" },
/* OdroidC4 rev 2020,01,29 */
{ MESON_SOC_ID_SM1, 80 * 4, 100 * 4, "c4" },
/* OdroidHC4 rev 2019,12,10 */
diff --git a/configs/odroid-n2_defconfig b/configs/odroid-n2_defconfig
index bac44b61ab..1f718a3154 100644
--- a/configs/odroid-n2_defconfig
+++ b/configs/odroid-n2_defconfig
@@ -9,7 +9,7 @@ CONFIG_DEFAULT_DEVICE_TREE="meson-g12b-odroid-n2"
CONFIG_MESON_G12A=y
CONFIG_DEBUG_UART_BASE=0xff803000
CONFIG_DEBUG_UART_CLOCK=2400
-CONFIG_IDENT_STRING=" odroid-n2/n2_plus"
+CONFIG_IDENT_STRING=" odroid-n2/n2-plus"
CONFIG_DEBUG_UART=y
CONFIG_OF_BOARD_SETUP=y
# CONFIG_DISPLAY_CPUINFO is not set
--
2.17.1
Re: [PATCH 6/7] xyz-modem: Show information about finished transfer
On 03.08.21 16:28, Pali Rohár wrote:
Show "## Start Addr" or "## Binary (...) download aborted" information like
in Kermit "loadb" command.
Signed-off-by: Pali Rohár
---
cmd/load.c | 16
1 file changed, 16 insertions(+)
diff --git a/cmd/load.c b/cmd/load.c
index 1ed05a9cd21e..573c44b912fd 100644
--- a/cmd/load.c
+++ b/cmd/load.c
@@ -474,6 +474,14 @@ static int do_load_serial_bin(struct cmd_tbl *cmdtp, int
flag, int argc,
addr = load_serial_ymodem(offset, xyzModem_ymodem);
+ if (addr == ~0) {
+ image_load_addr = 0;
+ printf("## Binary (ymodem) download aborted\n");
xyzModem_stream_terminate() already prints a message
" TRANSFER ABORT \n"
if the transfer is aborted.
+ rcode = 1;
+ } else {
+ printf("## Start Addr = 0x%08lX\n", addr);
In existing code '## ' is used to indicate errors. This message is not
for an error.
Please, avoid alternative language referring to the load address. Cf.
net/nfs.c:918:
printf("\nLoad address: 0x%lx\nLoading: *\b", image_load_addr);
net/tftp.c:851:
printf("Load address: 0x%lx\n", tftp_load_addr);
net/tftp.c:905:
printf("Load address: 0x%lx\n", tftp_load_addr)
Please, use log_err() and log_info() instead of printf().
Best regards
Heinrich
+ image_load_addr = addr;
+ }
} else if (strcmp(argv[0],"loadx")==0) {
printf("## Ready for binary (xmodem) download "
"to 0x%08lX at %d bps...\n",
@@ -482,6 +490,14 @@ static int do_load_serial_bin(struct cmd_tbl *cmdtp, int
flag, int argc,
addr = load_serial_ymodem(offset, xyzModem_xmodem);
+ if (addr == ~0) {
+ image_load_addr = 0;
+ printf("## Binary (xmodem) download aborted\n");
+ rcode = 1;
+ } else {
+ printf("## Start Addr = 0x%08lX\n", addr);
+ image_load_addr = addr;
+ }
} else {
printf("## Ready for binary (kermit) download "
Re: [PATCH 4/7] xyz-modem: Close stream after processing/sending terminate sequence
On 03.08.21 16:28, Pali Rohár wrote:
Obviously it is not possible to send terminate sequence over stream after
closing stream.
xyzModem_stream_close() does not close anything; it flushes the stream.
xyzModem_stream_terminate() sets xyz.at_eof = true and gives feedback to
the user.
So I think this change is incorrect.
What we lack is documentation of the xyzModem functions in
include/xyzModem.h.
Cf.
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation
Best regards
Heinrich
Signed-off-by: Pali Rohár
---
cmd/load.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/load.c b/cmd/load.c
index b7894d7db02a..fb8c191fb64f 100644
--- a/cmd/load.c
+++ b/cmd/load.c
@@ -1006,8 +1006,8 @@ static ulong load_serial_ymodem(ulong offset, int mode)
printf("%s\n", xyzModem_error(err));
}
- xyzModem_stream_close();
xyzModem_stream_terminate(false, );
+ xyzModem_stream_close();
flush_cache(offset, ALIGN(size, ARCH_DMA_MINALIGN));
Re: [PATCH 1/7] xyz-modem: Fix crash after cancelling transfer
On 03.08.21 16:28, Pali Rohár wrote:
Variable xyz.len is set to -1 on error. At the end xyzModem_stream_read()
function calls memcpy() with length from variable xyz.len. If this variable
is set to -1 then value passed to memcpy is casted to unsigned value, which
means to copy whole address space. Which then cause U-Boot crash. E.g. on
arm64 it cause CPU crash: "Synchronous Abort" handler, esr 0x9606
Fix this issue by checking that value stored in xyz.len is valid prior
trying to use it.
Signed-off-by: Pali Rohár
The changes below seem reasonable.
I would prefer if you could document the elements of struct xyz first.
Just add Sphinx style comments to the structure and indicate for element
len that a negative value signals an error.
Cf.
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation
Acked-by: Heinrich Schuchardt
---
common/xyzModem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/xyzModem.c b/common/xyzModem.c
index fc3459ebbafe..b1b72aae0baf 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -494,7 +494,7 @@ xyzModem_stream_read (char *buf, int size, int *err)
total = 0;
stat = xyzModem_cancel;
/* Try and get 'size' bytes into the buffer */
- while (!xyz.at_eof && (size > 0))
+ while (!xyz.at_eof && xyz.len >= 0 && (size > 0))
{
if (xyz.len == 0)
{
@@ -587,7 +587,7 @@ xyzModem_stream_read (char *buf, int size, int *err)
}
}
/* Don't "read" data from the EOF protocol package */
- if (!xyz.at_eof)
+ if (!xyz.at_eof && xyz.len > 0)
{
len = xyz.len;
if (size < len)
Re: EFI from usb HDD
Hi Michal Apologies for my late reply, I was on vacation! [...] > >> > >> When Abort happened I connected Xilinx debugger via jtag and look at cpu > >> backtrace. > > > > OK, but we are already in grub here and such a trace (in U-Boot) > > doesn't make sense. Right? > > Correct grub already started. But I expect it is still using U-Boot > drivers and all exception handlers are still in place from u-boot. Yes, U-Boot is still alive and GRUB is accessing some of the functionality via Boottime services. > > Maybe it is just sata/scsi related issue in EFI but weird is that when > disks are scan just before command everything is working fine. > > Should I try to initialize and populate EFI object list all the time? > (Remove this code for testing) > /* Initialize once only */ > if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) > return efi_obj_list_initialized; > > Or based on this thread to try your series pointed above? This smells like a different init sequence when a command is issued first. I'll try having a closer look. Let me know if you find anything else Cheers /Ilias > > Thanks, > Michal >
[PATCH 4/4] EFI: console: improve vidconsole unicode output
If EFI_CONSOLE_UTF_SAFE is enabled and vidconsole is active, unicode
characters will be replaced with "." for all console outputs.
Vidconsole does not support unicode output, and your console will suffer
display issues if EFI_CONSOLE_UTF_SAFE is disabled.
Signed-off-by: Artem Lapkin
---
lib/efi_loader/Kconfig | 9 +
lib/efi_loader/efi_console.c | 6 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 7d00d6cde5..886e0ce111 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -393,4 +393,13 @@ config EFI_CONSOLE_MAX_COLS
help
Set console max rows limit or set to zero to disable limit.
+config EFI_CONSOLE_UTF_SAFE
+ bool "If vidconsole is active, unicode characters will be replaced with
'.'"
+ default n
+ help
+ If EFI_CONSOLE_UTF_SAFE is enabled and vidconsole is active, unicode
+ characters will be replaced with "." for all console outputs.
+ Vidconsole does not support unicode output, and your console will
+ suffer display issues if EFI_CONSOLE_UTF_SAFE is disabled.
+
endif
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index b5d79d788f..bd1c14995d 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -19,6 +19,8 @@
#define EFI_COUT_MODE_2 2
#define EFI_MAX_COUT_MODE 3
+static int vidconsole_active;
+
struct cout_mode {
unsigned long columns;
unsigned long rows;
@@ -163,7 +165,8 @@ static efi_status_t EFIAPI efi_cout_output_string(
}
pos = buf;
utf16_utf8_strcpy(, string);
- fputs(stdout, buf);
+ fputs(stdout, IS_ENABLED(CONFIG_EFI_CONSOLE_UTF_SAFE) &&
+ strlen(buf) > 1 && vidconsole_active ? "." : buf);
free(buf);
/*
@@ -327,6 +330,7 @@ static int __maybe_unused query_vidconsole(int *rows, int
*cols)
return -ENODEV;
*rows = priv->rows;
*cols = priv->cols;
+ vidconsole_active = 1;
return 0;
}
--
2.25.1
[PATCH 3/4] EFI: console: max rows and cols user limit
Setup the max rows and columns limit for the EFI console output.
Signed-off-by: Artem Lapkin
---
lib/efi_loader/Kconfig | 12
lib/efi_loader/efi_console.c | 5 +
2 files changed, 17 insertions(+)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index dacc3b5881..7d00d6cde5 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -381,4 +381,16 @@ config EFI_ESRT
help
Enabling this option creates the ESRT UEFI system table.
+config EFI_CONSOLE_MAX_ROWS
+ int "setup console max rows"
+ default 0
+ help
+ Set console max rows limit or set to zero to disable limit.
+
+config EFI_CONSOLE_MAX_COLS
+ int "setup console max cols"
+ default 0
+ help
+ Set console max rows limit or set to zero to disable limit.
+
endif
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 847069212e..b5d79d788f 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -351,6 +351,11 @@ static void query_console_size(void)
} else if (query_console_serial(, ))
return;
+ if (CONFIG_EFI_CONSOLE_MAX_ROWS > 0)
+ rows = min(rows, CONFIG_EFI_CONSOLE_MAX_ROWS);
+ if (CONFIG_EFI_CONSOLE_MAX_COLS > 0)
+ cols = min(cols, CONFIG_EFI_CONSOLE_MAX_COLS);
+
/* Test if we can have Mode 1 */
if (cols >= 80 && rows >= 50) {
efi_cout_modes[1].present = 1;
--
2.25.1
[PATCH 2/4] EFI: console: query_console_size: multiplex adaptation
Multiplexed adaptation of the query_console_size() function;
automatically determine the minimal console area that will fit all
outputs properly.
Signed-off-by: Artem Lapkin
---
lib/efi_loader/efi_console.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3b012e1a66..ef5cf21bf7 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -340,14 +340,18 @@ static int __maybe_unused query_vidconsole(int *rows, int
*cols)
static void query_console_size(void)
{
int rows = 25, cols = 80;
- int ret = -ENODEV;
- if (IS_ENABLED(CONFIG_DM_VIDEO))
- ret = query_vidconsole(, );
- if (ret)
- ret = query_console_serial(, );
- if (ret)
+ if (IS_ENABLED(CONFIG_DM_VIDEO) &&
+ !query_vidconsole(, )) {
+ int rows_serial, cols_serial;
+
+ if (!query_console_serial(_serial, _serial)) {
+ rows = min(rows, rows_serial);
+ cols = min(cols, cols_serial);
+ }
+ } else if (query_console_serial(, )) {
return;
+ }
/* Test if we can have Mode 1 */
if (cols >= 80 && rows >= 50) {
--
2.25.1
[PATCH 1/4] EFI: console: query_vidconsole: multiplex adaptation
Fixed detection of vidconsole from within a multiplexed stdout string. As
you know, a user can use a comma-separated list of devices to set stdin,
stdout and stderr. For example, "setenv stdout serial,vidconsole" is a
multiplexed string.
Signed-off-by: Artem Lapkin
---
lib/efi_loader/efi_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3b012e1a66..2d03285f82 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -314,7 +314,7 @@ static int __maybe_unused query_vidconsole(int *rows, int
*cols)
struct udevice *dev;
struct vidconsole_priv *priv;
- if (!stdout_name || strncmp(stdout_name, "vidconsole", 10))
+ if (!stdout_name || !strstr(stdout_name, "vidconsole"))
return -ENODEV;
stdout_dev = stdio_get_by_name("vidconsole");
if (!stdout_dev)
--
2.25.1
[PATCH 0/4] EFI: console: improves
Problems with Linux Grub and U-Boot EFI console - multiplexed console output scrambled - slow refresh rate for big console sizes - vidconsole incompatible with unicode This patchset provides the following solutions: 1) Fixed detection of vidconsole from within a multiplexed stdout string. As you know, a user can use a comma-separated list of devices to set stdin, stdout and stderr. For example, "setenv stdout serial,vidconsole" is a multiplexed string. 2) Multiplexed adaptation of the query_console_size() function; automatically determine the minimal console area that will fit all outputs properly. 3) Setup the max rows and columns limit for the EFI console output. 4) If EFI_CONSOLE_UTF_SAFE is enabled and vidconsole is active, unicode characters will be replaced with "." for all console outputs. Vidconsole does not support unicode output, and your console will suffer display issues if EFI_CONSOLE_UTF_SAFE is disabled. Artem Lapkin (4): EFI: console: query_vidconsole: multiplex adaptation EFI: console: query_console_size: multiplex adaptation EFI: console: max rows and cols user limit EFI: console: improve vidconsole unicode output lib/efi_loader/Kconfig | 21 + lib/efi_loader/efi_console.c | 27 +++ 2 files changed, 40 insertions(+), 8 deletions(-) -- 2.25.1
Re: [PATCH 3/7] xyz-modem: Put xyzModem_stream_close debug diagnostic message into ZM_DEBUG()
On 03.08.21 16:28, Pali Rohár wrote:
This is how all other debug / diagnostic messages are handled.
This commit message is misleading. What you do is hide an output.
Signed-off-by: Pali Rohár
---
common/xyzModem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/xyzModem.c b/common/xyzModem.c
index 631c44e11adf..c200c9ff9177 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -608,10 +608,10 @@ xyzModem_stream_read (char *buf, int size, int *err)
void
xyzModem_stream_close (int *err)
{
- diag_printf
+ ZM_DEBUG (zm_dprintf
("xyzModem - %s mode, %d(SOH)/%d(STX)/%d(CAN) packets, %d retries\n",
xyz.crc_mode ? "CRC" : "Cksum", xyz.total_SOH, xyz.total_STX,
- xyz.total_CAN, xyz.total_retries);
+ xyz.total_CAN, xyz.total_retries));
ZM_DEBUG (zm_flush ());
zm_dprintf prints into the debug buffer which seems not to be overflow
protected.
diag_printf prints to the console.
Why do you want to hide this message?
Isn't the CRC what the user will want to check?
And if many retries occur doesn't this alert the user that the transfer
may be corrupted?
Best regards
Heinrich
}
[PATCH] engicam: Rename board dir, px30_core to px30
Engicam hardware design solutions are based on System On Modules(SoM)
with various SoCs like i.MX6, i.MX8 and PX30 etc.
The current directory structure uses the simplest way to understand
these designs by listing each of these SoC in board/engicam/SoC and
inside SoC directory has SoM file name as a board file name.
Right now all of the SoC's follow a similar approach except px30.
So rename px30_core to px30.
Signed-off-by: Jagan Teki
---
Note:
This patch is on top of
https://patchwork.ozlabs.org/project/uboot/cover/20210804090551.90819-1-ja...@amarulasolutions.com/
arch/arm/mach-rockchip/px30/Kconfig | 2 +-
board/engicam/{px30_core => px30}/Kconfig | 2 +-
board/engicam/{px30_core => px30}/MAINTAINERS | 0
board/engicam/{px30_core => px30}/Makefile| 0
board/engicam/{px30_core => px30}/px30_core.c | 0
5 files changed, 2 insertions(+), 2 deletions(-)
rename board/engicam/{px30_core => px30}/Kconfig (90%)
rename board/engicam/{px30_core => px30}/MAINTAINERS (100%)
rename board/engicam/{px30_core => px30}/Makefile (100%)
rename board/engicam/{px30_core => px30}/px30_core.c (100%)
diff --git a/arch/arm/mach-rockchip/px30/Kconfig
b/arch/arm/mach-rockchip/px30/Kconfig
index 98e09019a2..7b9b380dfa 100644
--- a/arch/arm/mach-rockchip/px30/Kconfig
+++ b/arch/arm/mach-rockchip/px30/Kconfig
@@ -68,7 +68,7 @@ config DEBUG_UART_CHANNEL
For using the UART for early debugging the route to use needs
to be declared (0 or 1).
-source "board/engicam/px30_core/Kconfig"
+source "board/engicam/px30/Kconfig"
source "board/hardkernel/odroid_go2/Kconfig"
source "board/rockchip/evb_px30/Kconfig"
diff --git a/board/engicam/px30_core/Kconfig b/board/engicam/px30/Kconfig
similarity index 90%
rename from board/engicam/px30_core/Kconfig
rename to board/engicam/px30/Kconfig
index a03be78369..10a7ec203f 100644
--- a/board/engicam/px30_core/Kconfig
+++ b/board/engicam/px30/Kconfig
@@ -1,7 +1,7 @@
if TARGET_PX30_CORE
config SYS_BOARD
- default "px30_core"
+ default "px30"
config SYS_VENDOR
default "engicam"
diff --git a/board/engicam/px30_core/MAINTAINERS
b/board/engicam/px30/MAINTAINERS
similarity index 100%
rename from board/engicam/px30_core/MAINTAINERS
rename to board/engicam/px30/MAINTAINERS
diff --git a/board/engicam/px30_core/Makefile b/board/engicam/px30/Makefile
similarity index 100%
rename from board/engicam/px30_core/Makefile
rename to board/engicam/px30/Makefile
diff --git a/board/engicam/px30_core/px30_core.c
b/board/engicam/px30/px30_core.c
similarity index 100%
rename from board/engicam/px30_core/px30_core.c
rename to board/engicam/px30/px30_core.c
--
2.25.1
[PATCH 4/4] engicam: px30: Add Engicam PX30.Core C.TOUCH 2.0 10.1" OF
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. C.TOUCH 2.0 is a general purpose carrier board with capacitive touch interface support. 10.1" OF is a capacitive touch 10.1" Open Frame panel solutions. PX30.Core needs to mount on top of C.TOUCH 2.0 carrier with pluged 10.1" OF for creating complete PX30.Core C.TOUCH 2.0 10.1" Open Frame. Add support for it. Signed-off-by: Jagan Teki --- arch/arm/dts/Makefile | 1 + arch/arm/mach-rockchip/px30/Kconfig | 8 ++ board/engicam/px30_core/MAINTAINERS | 6 + configs/px30-core-ctouch2-of10-px30_defconfig | 107 ++ 4 files changed, 122 insertions(+) create mode 100644 configs/px30-core-ctouch2-of10-px30_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 1d35411aa8..0c39cd1cf9 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -72,6 +72,7 @@ dtb-$(CONFIG_ROCKCHIP_PX30) += \ px30-evb.dtb \ px30-firefly.dtb \ px30-engicam-px30-core-ctouch2.dtb \ + px30-engicam-px30-core-ctouch2-of10.dtb \ px30-engicam-px30-core-edimm2.2.dtb \ rk3326-odroid-go2.dtb diff --git a/arch/arm/mach-rockchip/px30/Kconfig b/arch/arm/mach-rockchip/px30/Kconfig index 16090f5b08..98e09019a2 100644 --- a/arch/arm/mach-rockchip/px30/Kconfig +++ b/arch/arm/mach-rockchip/px30/Kconfig @@ -27,6 +27,14 @@ config TARGET_PX30_CORE * PX30.Core needs to mount on top of CTOUCH2.0 for creating complete PX30.Core C.TOUCH Carrier board. + PX30.Core CTOUCH2-OF10: + * PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. + * CTOUCH2.0 is a general purpose Carrier board with capacitive + touch interface support. + * 10.1" OF is a capacitive touch 10.1" Open Frame panel solutions. + * PX30.Core needs to mount on top of C.TOUCH 2.0 carrier with pluged +10.1" OF for creating complete PX30.Core C.TOUCH 2.0 10.1" Open Frame. + config ROCKCHIP_BOOT_MODE_REG default 0xff010200 diff --git a/board/engicam/px30_core/MAINTAINERS b/board/engicam/px30_core/MAINTAINERS index b87ca22207..77f0c2dba5 100644 --- a/board/engicam/px30_core/MAINTAINERS +++ b/board/engicam/px30_core/MAINTAINERS @@ -4,6 +4,12 @@ M: Suniel Mahesh S: Maintained F: configs/px30-core-ctouch2-px30_defconfig +PX30-Core-CTOUCH2.0-OF10 +M: Jagan Teki +M: Suniel Mahesh +S: Maintained +F: configs/px30-core-ctouch2-of10-px30_defconfig + PX30-Core-EDIMM2.2 M: Jagan Teki M: Suniel Mahesh diff --git a/configs/px30-core-ctouch2-of10-px30_defconfig b/configs/px30-core-ctouch2-of10-px30_defconfig new file mode 100644 index 00..b92e876556 --- /dev/null +++ b/configs/px30-core-ctouch2-of10-px30_defconfig @@ -0,0 +1,107 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_SPL_TEXT_BASE=0x +CONFIG_ROCKCHIP_PX30=y +CONFIG_TARGET_PX30_CORE=y +CONFIG_DEBUG_UART_CHANNEL=1 +CONFIG_TPL_LIBGENERIC_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_DEBUG_UART_BASE=0xFF16 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEFAULT_DEVICE_TREE="px30-engicam-px30-core-ctouch2-of10" +CONFIG_DEBUG_UART=y +CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 +# CONFIG_ANDROID_BOOT_IMAGE is not set +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_DEFAULT_FDT_FILE="rockchip/px30-engicam-px30-core-ctouch2-of10.dtb" +# CONFIG_CONSOLE_MUX is not set +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_MISC_INIT_R=y +CONFIG_SPL_BOOTROM_SUPPORT=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_STACK_R=y +# CONFIG_TPL_BANNER_PRINT is not set +CONFIG_SPL_CRC32_SUPPORT=y +CONFIG_SPL_ATF=y +# CONFIG_TPL_FRAMEWORK is not set +# CONFIG_CMD_BOOTD is not set +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +# CONFIG_CMD_LZMADEC is not set +# CONFIG_CMD_UNZIP is not set +CONFIG_CMD_GPT=y +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y +# CONFIG_CMD_ITEST is not set +# CONFIG_CMD_SETEXPR is not set +# CONFIG_SPL_DOS_PARTITION is not set +# CONFIG_ISO_PARTITION is not set +CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_REGMAP=y +CONFIG_SPL_REGMAP=y +CONFIG_SYSCON=y +CONFIG_SPL_SYSCON=y +CONFIG_CLK=y +CONFIG_SPL_CLK=y +CONFIG_FASTBOOT_BUF_ADDR=0x800800 +CONFIG_FASTBOOT_BUF_SIZE=0x0400 +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y +CONFIG_ROCKCHIP_OTP=y +CONFIG_MMC_DW=y
[PATCH 3/4] arm64: dts: rockchip: px30: Sync Linux-5.14-rc3 dts(i)
Sync the px30 devicetree files from Linux-5.14-rc3.
Signed-off-by: Jagan Teki
---
arch/arm/dts/px30-engicam-common.dtsi | 90 +
arch/arm/dts/px30-engicam-ctouch2.dtsi| 22 +++
arch/arm/dts/px30-engicam-edimm2.2.dtsi | 59 ++
.../px30-engicam-px30-core-ctouch2-of10.dts | 77
.../dts/px30-engicam-px30-core-edimm2.2.dts | 22 +++
arch/arm/dts/px30-evb.dts | 91 +++--
arch/arm/dts/px30.dtsi| 178 +++---
7 files changed, 457 insertions(+), 82 deletions(-)
create mode 100644 arch/arm/dts/px30-engicam-px30-core-ctouch2-of10.dts
diff --git a/arch/arm/dts/px30-engicam-common.dtsi
b/arch/arm/dts/px30-engicam-common.dtsi
index bd5bde989e..3429e124d9 100644
--- a/arch/arm/dts/px30-engicam-common.dtsi
+++ b/arch/arm/dts/px30-engicam-common.dtsi
@@ -6,6 +6,11 @@
*/
/ {
+ aliases {
+ mmc1 =
+ mmc2 =
+ };
+
vcc5v0_sys: vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_sys"; /* +5V */
@@ -14,6 +19,63 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <>;
+ clock-names = "ext_clock";
+ post-power-on-delay-ms = <80>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ };
+
+ vcc3v3_btreg: vcc3v3-btreg {
+ compatible = "regulator-gpio";
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ regulator-name = "btreg-gpio-supply";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ states = <330 0x0>;
+ };
+
+ vcc3v3_rf_aux_mod: vcc3v3-rf-aux-mod {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_rf_aux_mod";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+ xin32k: xin32k {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ clock-frequency = <5000>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <_pwrseq>;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ };
};
{
@@ -25,6 +87,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
cap-sd-highspeed;
card-detect-delay = <800>;
@@ -33,7 +99,31 @@
status = "okay";
};
+ {
+ status = "okay";
+
+ u2phy_host: host-port {
+ status = "okay";
+ };
+
+ u2phy_otg: otg-port {
+ status = "okay";
+ };
+};
+
{
pinctrl-0 = <_xfer>;
status = "okay";
};
+
+_otg {
+ status = "okay";
+};
+
+_host0_ehci {
+ status = "okay";
+};
+
+_host0_ohci {
+ status = "okay";
+};
diff --git a/arch/arm/dts/px30-engicam-ctouch2.dtsi
b/arch/arm/dts/px30-engicam-ctouch2.dtsi
index 58425b1e55..bf10a3d29f 100644
--- a/arch/arm/dts/px30-engicam-ctouch2.dtsi
+++ b/arch/arm/dts/px30-engicam-ctouch2.dtsi
@@ -6,3 +6,25 @@
*/
#include "px30-engicam-common.dtsi"
+
+ {
+ bt {
+ bt_enable_h: bt-enable-h {
+ rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+_pwrseq {
+ reset-gpios = < RK_PC2 GPIO_ACTIVE_LOW>;
+};
+
+_btreg {
+ enable-gpio = < RK_PC3 GPIO_ACTIVE_HIGH>;
+};
diff --git a/arch/arm/dts/px30-engicam-edimm2.2.dtsi
b/arch/arm/dts/px30-engicam-edimm2.2.dtsi
index cb00988953..449b8eb645 100644
--- a/arch/arm/dts/px30-engicam-edimm2.2.dtsi
+++ b/arch/arm/dts/px30-engicam-edimm2.2.dtsi
@@ -5,3 +5,62 @@
*/
#include "px30-engicam-common.dtsi"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 25000 0>;
+ };
+
+ panel {
+ compatible = "yes-optoelectronics,ytc700tlag-05-201c";
+ backlight = <>;
+ data-mapping = "vesa-24";
+ power-supply = <_lcd>;
+
+
[PATCH 2/4] arm64: dts: rockchip: px30: Move dmc into -u-boot.dtsi
dmc node is specific to U-Boot, it is always better practice
to maintain U-Boot specific nodes into -u-boot.dtsi files
in order to maintain Linux dts file sync compatibility.
Move the dmc into px30-u-boot.dtsi, also add dmc node
explicitly in rk3326-odroid-go2-u-boot.dtsi since it is
using px30.dts.
Signed-off-by: Jagan Teki
---
arch/arm/dts/px30-u-boot.dtsi | 10 ++
arch/arm/dts/px30.dtsi | 5 -
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 10 ++
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
index 029c8fbd8d..bbed7dcde5 100644
--- a/arch/arm/dts/px30-u-boot.dtsi
+++ b/arch/arm/dts/px30-u-boot.dtsi
@@ -13,6 +13,12 @@
u-boot,spl-boot-order = ,
};
+ dmc {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,px30-dmc", "syscon";
+ reg = <0x0 0xff2a 0x0 0x1000>;
+ };
+
rng: rng@ff0b {
compatible = "rockchip,cryptov2-rng";
reg = <0x0 0xff0b 0x0 0x4000>;
@@ -20,10 +26,6 @@
};
};
- {
- u-boot,dm-pre-reloc;
-};
-
{
clock-frequency = <2400>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
index b6c79e7ed3..e892d3b5a5 100644
--- a/arch/arm/dts/px30.dtsi
+++ b/arch/arm/dts/px30.dtsi
@@ -151,11 +151,6 @@
interrupt-affinity = <>, <>, <>, <>;
};
- dmc: dmc {
- compatible = "rockchip,px30-dmc", "syscon";
- reg = <0x0 0xff2a 0x0 0x1000>;
- };
-
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <_out>, <_out>;
diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
index 00767d2abd..93bc399087 100644
--- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
+++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
@@ -7,13 +7,15 @@
chosen {
u-boot,spl-boot-order =
};
-};
- {
- u-boot,dm-pre-reloc;
+ dmc {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,px30-dmc", "syscon";
+ reg = <0x0 0xff2a 0x0 0x1000>;
+ };
};
- {
+ {
u-boot,dm-pre-reloc;
};
--
2.25.1
[PATCH 1/4] arm64: dts: rockchip: px30: Sync Linux PX30.Core files
Engicam PX30.Core SoM and it's associated Carrier board device tree
files are different than the one it present in U-Boot.
Let's Sync the same from Linux-5.14-rc3 with removal of unneeded
nodes to satisfy the build.
Signed-off-by: Jagan Teki
---
arch/arm/dts/Makefile | 4 +-
...dts => px30-engicam-px30-core-ctouch2.dts} | 4 +-
...ts => px30-engicam-px30-core-edimm2.2.dts} | 4 +-
arch/arm/dts/px30-engicam-px30-core.dtsi | 241 ++
configs/px30-core-ctouch2-px30_defconfig | 4 +-
configs/px30-core-edimm2.2-px30_defconfig | 4 +-
6 files changed, 251 insertions(+), 10 deletions(-)
rename arch/arm/dts/{px30-px30-core-ctouch2.dts =>
px30-engicam-px30-core-ctouch2.dts} (80%)
rename arch/arm/dts/{px30-px30-core-edimm2.2.dts =>
px30-engicam-px30-core-edimm2.2.dts} (79%)
create mode 100644 arch/arm/dts/px30-engicam-px30-core.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 537c96bf5b..1d35411aa8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -71,8 +71,8 @@ dtb-$(CONFIG_MACH_S700) += \
dtb-$(CONFIG_ROCKCHIP_PX30) += \
px30-evb.dtb \
px30-firefly.dtb \
- px30-px30-core-ctouch2.dtb \
- px30-px30-core-edimm2.2.dtb \
+ px30-engicam-px30-core-ctouch2.dtb \
+ px30-engicam-px30-core-edimm2.2.dtb \
rk3326-odroid-go2.dtb
dtb-$(CONFIG_ROCKCHIP_RK3036) += \
diff --git a/arch/arm/dts/px30-px30-core-ctouch2.dts
b/arch/arm/dts/px30-engicam-px30-core-ctouch2.dts
similarity index 80%
rename from arch/arm/dts/px30-px30-core-ctouch2.dts
rename to arch/arm/dts/px30-engicam-px30-core-ctouch2.dts
index 2da0128188..5a0ecb8fae 100644
--- a/arch/arm/dts/px30-px30-core-ctouch2.dts
+++ b/arch/arm/dts/px30-engicam-px30-core-ctouch2.dts
@@ -9,11 +9,11 @@
/dts-v1/;
#include "px30.dtsi"
#include "px30-engicam-ctouch2.dtsi"
-#include "px30-px30-core.dtsi"
+#include "px30-engicam-px30-core.dtsi"
/ {
model = "Engicam PX30.Core C.TOUCH 2.0";
- compatible = "engicam,px30-core-ctouch2", "engicam,px30-px30-core",
+ compatible = "engicam,px30-core-ctouch2", "engicam,px30-core",
"rockchip,px30";
chosen {
diff --git a/arch/arm/dts/px30-px30-core-edimm2.2.dts
b/arch/arm/dts/px30-engicam-px30-core-edimm2.2.dts
similarity index 79%
rename from arch/arm/dts/px30-px30-core-edimm2.2.dts
rename to arch/arm/dts/px30-engicam-px30-core-edimm2.2.dts
index c36280ce7f..e54d1e480d 100644
--- a/arch/arm/dts/px30-px30-core-edimm2.2.dts
+++ b/arch/arm/dts/px30-engicam-px30-core-edimm2.2.dts
@@ -8,11 +8,11 @@
/dts-v1/;
#include "px30.dtsi"
#include "px30-engicam-edimm2.2.dtsi"
-#include "px30-px30-core.dtsi"
+#include "px30-engicam-px30-core.dtsi"
/ {
model = "Engicam PX30.Core EDIMM2.2 Starter Kit";
- compatible = "engicam,px30-core-edimm2.2", "engicam,px30-px30-core",
+ compatible = "engicam,px30-core-edimm2.2", "engicam,px30-core",
"rockchip,px30";
chosen {
diff --git a/arch/arm/dts/px30-engicam-px30-core.dtsi
b/arch/arm/dts/px30-engicam-px30-core.dtsi
new file mode 100644
index 00..7249871530
--- /dev/null
+++ b/arch/arm/dts/px30-engicam-px30-core.dtsi
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+#include
+#include
+
+/ {
+ compatible = "engicam,px30-core", "rockchip,px30";
+
+ aliases {
+ mmc0 =
+ };
+};
+
+ {
+ cpu-supply = <_arm>;
+};
+
+ {
+ cpu-supply = <_arm>;
+};
+
+ {
+ cpu-supply = <_arm>;
+};
+
+ {
+ cpu-supply = <_arm>;
+};
+
+ {
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <>;
+ interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <_int>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+
+ vcc1-supply = <_sys>;
+ vcc2-supply = <_sys>;
+ vcc3-supply = <_sys>;
+ vcc4-supply = <_sys>;
+ vcc5-supply = <_sys>;
+ vcc6-supply = <_sys>;
+ vcc7-supply = <_sys>;
+ vcc8-supply = <_sys>;
+ vcc9-supply = <_sys>;
+
+ regulators {
+ vdd_log: DCDC_REG1 {
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+
[PATCH 0/4] arm64: dts: rockchip: px30: Linux-5.14-rc3 Sync
Series sync Linux-5.14-rc3 devicetree files for px30 SoC.
Any inputs?
Jagan.
Jagan Teki (4):
arm64: dts: rockchip: px30: Sync Linux PX30.Core files
arm64: dts: rockchip: px30: Move dmc into -u-boot.dtsi
arm64: dts: rockchip: px30: Sync Linux-5.14-rc3 dts(i)
engicam: px30: Add Engicam PX30.Core C.TOUCH 2.0 10.1" OF
arch/arm/dts/Makefile | 5 +-
arch/arm/dts/px30-engicam-common.dtsi | 90 +++
arch/arm/dts/px30-engicam-ctouch2.dtsi| 22 ++
arch/arm/dts/px30-engicam-edimm2.2.dtsi | 59 +
.../px30-engicam-px30-core-ctouch2-of10.dts | 77 ++
...dts => px30-engicam-px30-core-ctouch2.dts} | 4 +-
.../dts/px30-engicam-px30-core-edimm2.2.dts | 43
arch/arm/dts/px30-engicam-px30-core.dtsi | 241 ++
arch/arm/dts/px30-evb.dts | 91 +--
arch/arm/dts/px30-px30-core-edimm2.2.dts | 21 --
arch/arm/dts/px30-u-boot.dtsi | 10 +-
arch/arm/dts/px30.dtsi| 183 -
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi| 10 +-
arch/arm/mach-rockchip/px30/Kconfig | 8 +
board/engicam/px30_core/MAINTAINERS | 6 +
configs/px30-core-ctouch2-of10-px30_defconfig | 107
configs/px30-core-ctouch2-px30_defconfig | 4 +-
configs/px30-core-edimm2.2-px30_defconfig | 4 +-
18 files changed, 861 insertions(+), 124 deletions(-)
create mode 100644 arch/arm/dts/px30-engicam-px30-core-ctouch2-of10.dts
rename arch/arm/dts/{px30-px30-core-ctouch2.dts =>
px30-engicam-px30-core-ctouch2.dts} (80%)
create mode 100644 arch/arm/dts/px30-engicam-px30-core-edimm2.2.dts
create mode 100644 arch/arm/dts/px30-engicam-px30-core.dtsi
delete mode 100644 arch/arm/dts/px30-px30-core-edimm2.2.dts
create mode 100644 configs/px30-core-ctouch2-of10-px30_defconfig
--
2.25.1
