Re: Please pull u-boot-watchdog/next
On Fri, Sep 16, 2022 at 09:46:49PM +0200, Stefan Roese wrote: > Hi Tom, > > On 16.09.22 21:22, Tom Rini wrote: > > On Fri, Sep 16, 2022 at 09:12:54PM +0200, Stefan Roese wrote: > > > Hi Tom, > > > > > > On 16.09.22 16:37, Stefan Roese wrote: > > > > Hi Tom, > > > > > > > > On 16.09.22 16:21, Tom Rini wrote: > > > > > On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote: > > > > > > On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > please pull the following watchdog related patches: > > > > > > > > > > > > > > > > > > > > > - Migrate watchdog reset to cyclic infrastructure (Stefan) > > > > > > > > > > > > > > > > > > > > > Here the Azure build, without any issues: > > > > > > > > > > > > > > https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Stefan > > > > > > > > > > > > > > The following changes since commit > > > > > > > 6ec7207ab3c4dad098967fef5df75e25240fd852: > > > > > > > > > > > > > > Merge branch '2022-09-15-TI-platform-updates' into next > > > > > > > (2022-09-15 > > > > > > > 17:02:52 -0400) > > > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > > > g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next > > > > > > > > > > > > > > for you to fetch changes up to > > > > > > > 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: > > > > > > > > > > > > > > watchdog: Further cleanup (2022-09-16 07:09:05 +0200) > > > > > > > > > > > > > > > > > > > > > Stefan Roese (6): > > > > > > > watchdog: Integrate watchdog triggering into the > > > > > > > cyclic framework > > > > > > > cyclic: Introduce schedule() function > > > > > > > cyclic: Use schedule() instead of WATCHDOG_RESET() > > > > > > > watchdog: Get rid of ASSEMBLY hacks > > > > > > > watchdog: Remove WATCHDOG_RESET macro > > > > > > > watchdog: Further cleanup > > > > > > > > > > > > Good bad news, I've got your first hardware failure report. One of > > > > > > these three: > > > > > > cyclic: Use schedule() instead of WATCHDOG_RESET() > > > > > > cyclic: Introduce schedule() function > > > > > > watchdog: Integrate watchdog triggering into the cyclic framework > > > > > > > > > > > > Causes am335x_evm to have no output in SPL and just hang. It, along > > > > > > with > > > > > > all of the other TI AM335x platforms have watchdog enabled in SPL. > > > > > > I can > > > > > > also observe that the system watchdog is not triggering, so maybe > > > > > > we're > > > > > > stuck in some loop where that's being serviced still? > > > > > > > > > > > > I suspect all the am335x boards are broken, so if you don't have > > > > > > something there you can test on let me know off-list and I'll get > > > > > > you > > > > > > access to my lab. > > > > > > > > > > > > > > > > I'll note that pine64_plus_defconfig is now also failing, but > > > > > interestingly dra7xx_evm_defconfig is passing. > > > > > > > > Thanks for all your testing Tom. I'll check, if I still have an AM355x > > > > here. I just now found an Cubieboard2, which also seems to have SPL > > > > watchdog enabled. Let me check, if I can get this board running and > > > > tested. > > > > > > Cubieboard2 does not really use the watchdog in U-Boot and especially > > > not very early (SPL). So no help here. But I figured out a potential > > > problem that might explain you system hang. Could you please give the > > > attached patch a try and let me know, if this changes the situation > > > a bit? > > > > > > Thanks, > > > Stefan > > > > > From 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 > > > From: Stefan Roese > > > Date: Fri, 16 Sep 2022 21:08:51 +0200 > > > Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's > > > ready > > > > > > schedule() might get called very early in the boot process (SPL etc), > > > when the cyclic IF is not initialized. Let's make sure, that we only > > > call into cyclic_run() when it's ready. > > > > > > Signed-off-by: Stefan Roese > > > --- > > > common/cyclic.c | 7 ++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/common/cyclic.c b/common/cyclic.c > > > index 594f9cd92592..9cdbed4ecc92 100644 > > > --- a/common/cyclic.c > > > +++ b/common/cyclic.c > > > @@ -104,7 +104,12 @@ void schedule(void) > > > if (IS_ENABLED(CONFIG_HW_WATCHDOG)) > > > hw_watchdog_reset(); > > > - cyclic_run(); > > > + /* > > > + * schedule() might get called very early before the cyclic IF is > > > + * ready. Make sure to only call cyclic_run() when it's initalized. > > > + */ > > > + if
Re: [PATCH 1/2] smbios: Simplify reporting of unknown values
Hi Simon,
[...]
> > Signed-off-by: Ilias Apalodimas
> > ---
> > lib/smbios.c | 17 +++--
> > 1 file changed, 3 insertions(+), 14 deletions(-)
>
> Perhaps a better fix is to drop the smbios info?
Unfortunately there's a ton of userspace tools still using it. So I think
we still need it
>
> What upstream projects use this information to show things to the
> user? You showed a screenshot of some sort of system-info app. We
> could teach it about falling back to the device tree. That way we are
> not adding fake information to SMBIOS.
>
What's fake here? The model and compatible are taken directly from the DT
and that should be accurate. I'd rather fix the DT if that's problematic.
What would make sense for me to change is take the first token of the
compatible node instead of the entire string as it's format is expected to
be anyway.
> Also, SMBIOS is a legacy thing and a PITA to work with. How about we
> use the device tree binding for the same info:
>
> smbios {
> compatible = "u-boot,sysinfo-smbios";
>
> smbios {
> system {
> manufacturer = "pine64";
> product = "rock64_rk3328";
> };
>
> baseboard {
> manufacturer = "pine64";
> product = "rock64_rk3328";
> };
>
> chassis {
> manufacturer = "pine64";
> product = "rock64_rk3328";
> };
> };
> };
>
> This is easy to parse and gets us away from all this legacy junk that
> we don't need.
That's the exact opposite of the patch description. Most of these info are
already included in the DT in it's standard properties. So if U-Boot ends
up with a DT without these we get a usable smbios table. For example a DT
handed over by the previous stage bootloader would not include these nodes.
As far as sysinfo-smbios node is concerned, it's only present in 13
boards, so it's not like it's used by the majority of boards. Yes we
could fix them, but imho we are better off re-using what's already there
and defined on the DT spec at least for the simplistic values.
Thanks
/Ilias
>
> Regards,
> Simon
Re: [PATCH 1/2] dm: blk: assign media ID to block devices
Hi Heinrich, On Fri, 16 Sept 2022 at 00:41, Heinrich Schuchardt wrote: > > > > On 9/16/22 03:30, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 15 Sept 2022 at 14:02, Heinrich Schuchardt > > wrote: > >> > >> Currently block devices are only identified by uclass_id and device number. > >> When dealing with removable media this is not enough to uniquely identify > >> the medium. > >> > >> E.g. after host unbind, host bind we can have the same device number but a > >> different backing file. > >> > >> The EFI specification uses a 32bit number media ID to identify media. Add a > >> matching field to the block device descriptor. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> drivers/block/blk-uclass.c | 16 +++- > >> include/blk.h | 11 +++ > >> 2 files changed, 26 insertions(+), 1 deletion(-) > > > > Shouldn't this be handled by connecting the EFI data to its udevice. > > I think Takahiro has been looking at this? > > > > NAK to any EFI fields in blk_desc, in any case > > The information that a medium has changed can only come from the DM > layer. If for instance the SD-card is swapped, this is indicated by the > card detector switch. USB also has a signal for media changes. > > What are your ideas how the DM layer shall indicate media changes? It should send an event, e.g. EVT_MEDIA and subscribers can then do what is needed. Regards, Simon
Re: [PATCH v4] tee: optee: rework TA bus scanning code
Hi Simon,
> > > > > >
> > > > > > Late versions of OP-TEE support a pseudo bus. TAs that behave as
> > > > > > hardware blocks (e.g TPM, RNG etc) present themselves on a bus
> > > > > > which we can
> > > > > > scan. Unfortunately U-Boot doesn't support that yet. It's worth
> > > > > > noting
> > > > > > that we already have a workaround for RNG. The details are in
> > > > > > commit 70812bb83da6 ("tee: optee: bind rng optee driver")
> > > > > >
> > > > > > So let's add a list of devices based on U-Boot Kconfig options that
> > > > > > we will
> > > > > > scan until we properly implement the tee-bus functionality.
> > > > > >
> > > > > > While at it change the behaviour of the tee core itself wrt to
> > > > > > device
> > > > > > binding. If some device binding fails, print a warning instead of
> > > > > > disabling OP-TEE.
> > > > > >
> > > > > > Signed-off-by: Ilias Apalodimas
> > > > > > Reviewed-by: Jens Wiklander
> > > > > > Reviewed-by: Etienne Carriere
> > > > > > ---
> > > > > > Changes since v3:
> > > > > > - Use NULL instead of a child ptr on device_bind_driver(), since
> > > > > > it's not
> > > > > > really needed
> > > > > > - Changed the style of the optee_bus_probe[] definition to
> > > > > > {.drv_name = xxx, .dev_name = yyy }
> > > > > >
> > > > > > Changes since v2:
> > > > > > - Fixed typo on driver name ftpm-tee -> ftpm_tee
> > > > > >
> > > > > > Changes since v1:
> > > > > > - remove a macro and use ARRAY_SIZE directly
> > > > > > drivers/tee/optee/core.c | 24 +++-
> > > > > > 1 file changed, 19 insertions(+), 5 deletions(-)
> > > > > >
[...]
> >
> > Some things *are* working without a DT entry. You had similar
> > concerns on FF-A (where you requested a DT node again) and people gave
> > the exact same response. As long as a bus is scanable in any way,
> > it's preferable to than adding a DT entry. Moreover this code does
> > not prevent anyone from adding a DT entry.
> >
> > To make things even worse if the TA is compiled as 'scanable' and has
> > a DT entry, it might cause issues down the road when being probed by
> > the kernel. So really this is just a patch that makes u-boot behave
> > and plug in properly to the rest of the ecosystem
>
> Calling device_bind() is supposed to be used in extremis. I don't see
> any scanning of an OP-TEE bus here. I just see it binding two child
> devices which are hard-coded in U-Boot. What am I missing?
The commit description describes the current state of U-Boot
>
> This appears to be a Linaro binding, so you should be able to update
> it easily enough.
Linaro binding? The DT is governed by a spec, we commit everything
upstream there. OTOH I still don't see what we need to put in there.
As we discussed this is a bus that can be used to scan devices.
Thanks
/Ilias
>
> Regards,
> Simon
Re: Please pull u-boot-watchdog/next
Hi Tom, On 16.09.22 21:22, Tom Rini wrote: On Fri, Sep 16, 2022 at 09:12:54PM +0200, Stefan Roese wrote: Hi Tom, On 16.09.22 16:37, Stefan Roese wrote: Hi Tom, On 16.09.22 16:21, Tom Rini wrote: On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote: On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: Hi Tom, please pull the following watchdog related patches: - Migrate watchdog reset to cyclic infrastructure (Stefan) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results Thanks, Stefan The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852: Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: watchdog: Further cleanup (2022-09-16 07:09:05 +0200) Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still? I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab. I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing. Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested. Cubieboard2 does not really use the watchdog in U-Boot and especially not very early (SPL). So no help here. But I figured out a potential problem that might explain you system hang. Could you please give the attached patch a try and let me know, if this changes the situation a bit? Thanks, Stefan From 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 From: Stefan Roese Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's ready schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready. Signed-off-by: Stefan Roese --- common/cyclic.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..9cdbed4ecc92 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset(); - cyclic_run(); + /* +* schedule() might get called very early before the cyclic IF is +* ready. Make sure to only call cyclic_run() when it's initalized. +*/ + if (gd->cyclic->cyclic_ready) + cyclic_run(); } int cyclic_uninit(void) No change. Thanks for testing. I do have one last experiment for tonight. Please give the attached v2 a try. Thanks, StefanFrom 2f61bc2cf011190eedbc0be34b4d61f342e7e5a5 Mon Sep 17 00:00:00 2001 From: Stefan Roese Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH v2] cyclic: Only call cyclic_run() from schedule() when it's ready schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready. Signed-off-by: Stefan Roese --- common/cyclic.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..b3c180bd1a62 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset(); - cyclic_run(); + /* + * schedule() might get called very early before the cyclic IF is + * ready. Make sure to only call cyclic_run() when it's initalized. + */ + if (gd && gd->cyclic && gd->cyclic->cyclic_ready) + cyclic_run(); } int cyclic_uninit(void) --
Re: [PATCH v2 01/24] disk: Correct help for TPL_PARTITIONS
On Thu, Aug 11, 2022 at 07:34:40PM -0600, Simon Glass wrote: > Fix a few typos in this help text. Fix a typo in SPL_PARTITIONS while > we are here. > > Signed-off-by: Simon Glass For patches 1 through 22, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-watchdog/next
On Fri, Sep 16, 2022 at 09:12:54PM +0200, Stefan Roese wrote: > Hi Tom, > > On 16.09.22 16:37, Stefan Roese wrote: > > Hi Tom, > > > > On 16.09.22 16:21, Tom Rini wrote: > > > On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote: > > > > On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > please pull the following watchdog related patches: > > > > > > > > > > > > > > > - Migrate watchdog reset to cyclic infrastructure (Stefan) > > > > > > > > > > > > > > > Here the Azure build, without any issues: > > > > > > > > > > https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results > > > > > > > > > > > > > > > Thanks, > > > > > Stefan > > > > > > > > > > The following changes since commit > > > > > 6ec7207ab3c4dad098967fef5df75e25240fd852: > > > > > > > > > > Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 > > > > > 17:02:52 -0400) > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next > > > > > > > > > > for you to fetch changes up to > > > > > 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: > > > > > > > > > > watchdog: Further cleanup (2022-09-16 07:09:05 +0200) > > > > > > > > > > > > > > > Stefan Roese (6): > > > > > watchdog: Integrate watchdog triggering into the > > > > > cyclic framework > > > > > cyclic: Introduce schedule() function > > > > > cyclic: Use schedule() instead of WATCHDOG_RESET() > > > > > watchdog: Get rid of ASSEMBLY hacks > > > > > watchdog: Remove WATCHDOG_RESET macro > > > > > watchdog: Further cleanup > > > > > > > > Good bad news, I've got your first hardware failure report. One of > > > > these three: > > > > cyclic: Use schedule() instead of WATCHDOG_RESET() > > > > cyclic: Introduce schedule() function > > > > watchdog: Integrate watchdog triggering into the cyclic framework > > > > > > > > Causes am335x_evm to have no output in SPL and just hang. It, along with > > > > all of the other TI AM335x platforms have watchdog enabled in SPL. I can > > > > also observe that the system watchdog is not triggering, so maybe we're > > > > stuck in some loop where that's being serviced still? > > > > > > > > I suspect all the am335x boards are broken, so if you don't have > > > > something there you can test on let me know off-list and I'll get you > > > > access to my lab. > > > > > > > > > > I'll note that pine64_plus_defconfig is now also failing, but > > > interestingly dra7xx_evm_defconfig is passing. > > > > Thanks for all your testing Tom. I'll check, if I still have an AM355x > > here. I just now found an Cubieboard2, which also seems to have SPL > > watchdog enabled. Let me check, if I can get this board running and > > tested. > > Cubieboard2 does not really use the watchdog in U-Boot and especially > not very early (SPL). So no help here. But I figured out a potential > problem that might explain you system hang. Could you please give the > attached patch a try and let me know, if this changes the situation > a bit? > > Thanks, > Stefan > From 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 > From: Stefan Roese > Date: Fri, 16 Sep 2022 21:08:51 +0200 > Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's > ready > > schedule() might get called very early in the boot process (SPL etc), > when the cyclic IF is not initialized. Let's make sure, that we only > call into cyclic_run() when it's ready. > > Signed-off-by: Stefan Roese > --- > common/cyclic.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/common/cyclic.c b/common/cyclic.c > index 594f9cd92592..9cdbed4ecc92 100644 > --- a/common/cyclic.c > +++ b/common/cyclic.c > @@ -104,7 +104,12 @@ void schedule(void) > if (IS_ENABLED(CONFIG_HW_WATCHDOG)) > hw_watchdog_reset(); > > - cyclic_run(); > + /* > + * schedule() might get called very early before the cyclic IF is > + * ready. Make sure to only call cyclic_run() when it's initalized. > + */ > + if (gd->cyclic->cyclic_ready) > + cyclic_run(); > } > > int cyclic_uninit(void) No change. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-watchdog/next
Hi Tom, On 16.09.22 16:37, Stefan Roese wrote: Hi Tom, On 16.09.22 16:21, Tom Rini wrote: On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote: On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: Hi Tom, please pull the following watchdog related patches: - Migrate watchdog reset to cyclic infrastructure (Stefan) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results Thanks, Stefan The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852: Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: watchdog: Further cleanup (2022-09-16 07:09:05 +0200) Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still? I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab. I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing. Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested. Cubieboard2 does not really use the watchdog in U-Boot and especially not very early (SPL). So no help here. But I figured out a potential problem that might explain you system hang. Could you please give the attached patch a try and let me know, if this changes the situation a bit? Thanks, StefanFrom 3788aadff5d697e3e150a9e520915007f7a26def Mon Sep 17 00:00:00 2001 From: Stefan Roese Date: Fri, 16 Sep 2022 21:08:51 +0200 Subject: [PATCH] cyclic: Only call cyclic_run() from schedule() when it's ready schedule() might get called very early in the boot process (SPL etc), when the cyclic IF is not initialized. Let's make sure, that we only call into cyclic_run() when it's ready. Signed-off-by: Stefan Roese --- common/cyclic.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/common/cyclic.c b/common/cyclic.c index 594f9cd92592..9cdbed4ecc92 100644 --- a/common/cyclic.c +++ b/common/cyclic.c @@ -104,7 +104,12 @@ void schedule(void) if (IS_ENABLED(CONFIG_HW_WATCHDOG)) hw_watchdog_reset(); - cyclic_run(); + /* + * schedule() might get called very early before the cyclic IF is + * ready. Make sure to only call cyclic_run() when it's initalized. + */ + if (gd->cyclic->cyclic_ready) + cyclic_run(); } int cyclic_uninit(void) -- 2.37.3
U-Boot support for IMX8MP dual-role
Greetings, I'm wondering if anyone has done any work to get dual-role USB working for the IMX8MP (or any other dwc3 host based board) and how they went about it if so. The imx8mp-venice-gw74xx has dual-role support through a USB Type-C connector with a TPS25821 (driverless) that monitors the CC signals and manages VBUS, as well as asserts gpio's: FAULT# - pinmuxed to OC pin SINK# - used as GPIO for role POL# - used for SS mux to connector For linux this is managed with a usb-role-switch dt prop and a connector node with compatible of gpio-usb-b-connector and id-gpios [1]. I did not see anything like that in use in U-Boot for dwc3 hosts but perhaps I was looking in the wrong place. For U-Boot I can get this type-C connector to work in host mode only by changing dr_mode="otg" to dr_mode="host". With the default dt prop dr_mode=otg dwc3-generic-peripheral is bound instead of dwc3-generic-host thus no host controller is found. It seems to me that dwc3_glue_bind needs support added to be able to check id-gpios or vbus-gpios if usb-role-switch and something like gpio-usb-b-connector or linux,extcon-usb-gpio are used. Does this sound like the correct implementation? I notice that drivers/usb/host/xhci-dwc3.c which is a driver for the dwc3 core (compatible snps,dwc3) and this does look at usb-role-swich however this driver as a subnode of fsl,imx8mp-dwc3 (glue) does not bind and perhaps that is an issue. In that driver usb-role-switch causes the driver to use role-switch-default-mode for the default mode which still does not look at an id/vbus pin so that would not be feature complete either. Best Regards, TIm 1 https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=c8a4192d238e9258ab0bc916b3c138a4722af215
Re: [PATCH] armv8: cache_v8: Fix pgtables setup when MMU is already enabled
On Wed, 14 Sep 2022 13:37:46 +0200 Pali Rohár wrote: > When MMU is already enabled then dcache_enable() does not call mmu_setup() > and so setup_all_pgtables() is also never called. > > In this situation when some driver calls mmu_set_region_dcache_behaviour() > function then U-Boot crashes with error message: > > Emergency page table not setup. > > Fix this issue by explicitly calling setup_all_pgtables() in dcache_enable() > function near condition for mmu_setup(). > > This change fixes chainloading U-Boot from U-Boot on Turris Mox board which > uses mvneta ethernet driver which calls mmu_set_region_dcache_behaviour(). > > Signed-off-by: Pali Rohár Reviewed-by: Marek Behún
Re: [PATCH] Makefile: Add missing CONFIG_BOARD_SIZE_LIMIT check for u-boot-spl.kwb
On Wed, 14 Sep 2022 15:06:14 +0200 Pali Rohár wrote: > Currently CONFIG_BOARD_SIZE_LIMIT check is ignored for u-boot-spl.kwb > target. Fix it by adding missing $(BOARD_SIZE_CHECK) macro. > > Signed-off-by: Pali Rohár > --- > Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Makefile b/Makefile > index 65aca6e3e79b..3818107b2cbb 100644 > --- a/Makefile > +++ b/Makefile > @@ -1472,6 +1472,7 @@ endif > > u-boot-spl.kwb: u-boot.bin spl/u-boot-spl.bin FORCE > $(call if_changed,mkimage) > + $(BOARD_SIZE_CHECK) > > u-boot.sha1: u-boot.bin > tools/ubsha1 u-boot.bin Reviewed-by: Marek Behún
Re: [PATCH] arm: mvebu: turris_omnia: Add CONFIG_BOARD_SIZE_LIMIT
On Wed, 14 Sep 2022 15:06:46 +0200 Pali Rohár wrote: > Maximal size of u-boot kwb image binary is $CONFIG_ENV_OFFSET which is > 0xF = 983040 bytes. So add missing CONFIG_BOARD_SIZE_LIMIT definition > to ensure that u-boot binary does not overflow to the u-boot env storage. > > Signed-off-by: Pali Rohár > --- > configs/turris_omnia_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig > index ba635feb44b2..6698f2313550 100644 > --- a/configs/turris_omnia_defconfig > +++ b/configs/turris_omnia_defconfig > @@ -28,6 +28,8 @@ CONFIG_SYS_MEMTEST_END=0x00ff > CONFIG_DISTRO_DEFAULTS=y > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > +CONFIG_HAS_BOARD_SIZE_LIMIT=y > +CONFIG_BOARD_SIZE_LIMIT=983040 > CONFIG_FIT=y > CONFIG_FIT_VERBOSE=y > CONFIG_OF_BOARD_SETUP=y Reviewed-by: Marek Behún
Re: [PATCH] arm: mvebu: Add default SPL_SIZE_LIMIT for 32-bit SoCs
On Wed, 14 Sep 2022 18:48:16 +0200 Pali Rohár wrote: > 32-bit Marvell Armada BootROMs limit maximal size of SPL image to 192 kB. > So define 192 kB (= 0x3) limit as default value for SPL_SIZE_LIMIT. > > Signed-off-by: Pali Rohár Reviewed-by: Marek Behún
Re: [GIT PULL] please pull fsl-qoriq-2022-9-7
On Mon, 12 Sep 2022 15:37:25 +0800 Peng Fan wrote: > On 9/12/2022 3:33 PM, Peng Fan wrote: > > > > > > On 9/9/2022 12:29 AM, Marek Behún wrote: > >> On Thu, 8 Sep 2022 17:05:53 +0200 > >> Pali Rohár wrote: > >> > >>> On Thursday 08 September 2022 07:21:03 Peng Fan wrote: > On 9/8/2022 1:55 AM, Tom Rini wrote: > > On Wed, Sep 07, 2022 at 12:38:10PM +, Peng Fan wrote: > >> Hi Tom, > >> > >> Please pull fsl-qoriq-2022-9-7 > >> > >> Sorry for the quick rush just after fsl-qoriq-2022-9-6: > >> Pali's patch not in my patchwork, got missed. > >> Sean's patch pending for sometime, I just fix conflict when > >> apply Sean's patch, so pick up. > >> > >> --- > >> p1_p2_rdb_pc board update > >> net: fm: Verify Fman microcode > >> --- > >> > >> CI: > >> https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/13377 > >> > >> Thanks, > >> Peng. > >> > >> The following changes since commit > >> 59c51fa4abbca41d2a4d60c0fe4d8f05fc83fb46: > >> > >> Merge https://source.denx.de/u-boot/custodians/u-boot-riscv > >> (2022-09-06 09:01:39 -0400) > >> > >> are available in the Git repository at: > >> > >> https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git > >> tags/fsl-qoriq-2022-9-7 > >> > >> for you to fetch changes up to > >> 857e313a3d44618e09fc64816fd5e561e2189ab7: > >> > >> net: fm: Add support for FIT firmware (2022-09-07 13:44:55 +0800) > >> > >> > >> Pali Rohár (3): > >> board: freescale: p1_p2_rdb_pc: Add env commands > >> norlowerboot, norupperboot, sd2boot and defboot > >> board: freescale: p1_p2_rdb_pc: Delete watchdog max6370 > >> node in load_default mode > >> board: freescale: p1_p2_rdb_pc: Calculate offsets for > >> eSDHC boot sector > >> > >> Sean Anderson (6): > >> ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME > >> image: fit: Add some helpers for getting data > >> ARMv8/sec_firmware: Convert to use fit_get_data_conf_prop > >> cmd: fpga: Convert to use fit_get_data_node > >> net: Convert fit verification to use fit_get_data_* > >> net: fm: Add support for FIT firmware > > > > First, I've applied this now to u-boot/master. > > > > But second, the reason Pali's patches were assigned to someone else, > > Marek, was because of the total lack of response these last several > > months. Marek was added for the subset of PowerPC platforms that he > > and > > Pali have an interest in, which is all around the Turris 1.x router > > platform. > > > > So, what do you think about how to proceed here moving forward? A > > large > > number of Pali's changes have been waiting to be picked up / reviewed > > for a very long time, is why we've added Marek, to cover the Turris > > platform. > > If the delay was caused by me, sorry for that. I could ramp up more > time in maintainer work. > > Pali, > > I am ok if Turris patches go through Marek's tree. or you wanna me to > pick up those patches, please help assign those patches. If bug fix, > I could prepare PR to master branch, if new feature, we could > consider PR > for next branch. > > Thanks, > Peng. > >>> > >>> Here is the list of currently waiting patches which are not in master > >>> branch yet: > >>> > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220801154220.20068-1-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220801154220.20068-2-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220803112049.4287-1-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220805200941.22101-1-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220805200941.22101-2-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220805200941.22101-3-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220803215655.2361-1-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220803112442.4735-1-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220819092001.15045-1-p...@kernel.org/ > >>> https://patchwork.ozlabs.org/project/uboot/patch/20220815080140.4048-1-p...@kernel.org/ > >>> > >> > >> I am working on this, will give more info soon. > > > > Sorry, I not follow, you mean new version patches or else? > > Just see the patches were delegated to you. > > I suppose you will handle the patches Pali listed above. Sorry for not replying earlier, but I got stuck on rebasing Pali's
Re: [PATCH mpc85xx] powerpc: mpc85xx: Fix check for CONFIG_SDCARD
On Friday 16 September 2022 17:32:04 Marek Behún wrote:
> Commit d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig") converted
> SYS_EXTRA_OPTIONS=SDCARD or SPIFLASH to config options CONFIG_SDCARD and
> CONFIG_SPIFLASH, but left one occurance unchanged.
>
> Fix this.
>
> Fixes: d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig")
> Signed-off-by: Marek Behún
Reviewed-by: Pali Rohár
> ---
> arch/powerpc/cpu/mpc85xx/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig
> b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 085ddd8439..27f069a1fb 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -15,7 +15,7 @@ config CMD_ERRATA
> config FSL_PREPBL_ESDHC_BOOT_SECTOR
> bool "Generate QorIQ pre-PBL eSDHC boot sector"
> depends on MPC85xx
> - depends on SYS_EXTRA_OPTIONS = SDCARD
> + depends on SDCARD
> help
> With this option final image would have prepended QorIQ pre-PBL eSDHC
> boot sector suitable for SD card images. This boot sector instruct
> --
> 2.35.1
>
[PATCH mpc85xx] powerpc: mpc85xx: Fix check for CONFIG_SDCARD
Commit d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig") converted
SYS_EXTRA_OPTIONS=SDCARD or SPIFLASH to config options CONFIG_SDCARD and
CONFIG_SPIFLASH, but left one occurance unchanged.
Fix this.
Fixes: d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig")
Signed-off-by: Marek Behún
---
arch/powerpc/cpu/mpc85xx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 085ddd8439..27f069a1fb 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -15,7 +15,7 @@ config CMD_ERRATA
config FSL_PREPBL_ESDHC_BOOT_SECTOR
bool "Generate QorIQ pre-PBL eSDHC boot sector"
depends on MPC85xx
- depends on SYS_EXTRA_OPTIONS = SDCARD
+ depends on SDCARD
help
With this option final image would have prepended QorIQ pre-PBL eSDHC
boot sector suitable for SD card images. This boot sector instruct
--
2.35.1
[PATCH] rpi: Set FDT for RPi CM4 to the IO Board one
For the RPi CM4 (Compute Module 4), we currently try to load the dtb
file bcm2711-rpi-cm4.dtb, which is not built by the upstream kernel.
Instead, the only CM4 dtb file provided by linux upstream is the
bcm2711-rpi-cm4-io.dtb, so let's use that.
Signed-off-by: Ariel D'Alessandro
---
board/raspberrypi/rpi/rpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 17b8108cc8..b88f80ce05 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -168,8 +168,8 @@ static const struct rpi_model rpi_models_new_scheme[] = {
true,
},
[0x14] = {
- "Compute Module 4",
- DTB_DIR "bcm2711-rpi-cm4.dtb",
+ "Compute Module 4 IO Board",
+ DTB_DIR "bcm2711-rpi-cm4-io.dtb",
true,
},
};
--
2.37.2
[PATCH] configs: stm32mp1: cleanup config file
Remove the unnecessary comment after the CONFIG_SYS_BOOTM_LEN
migration to Kconfig.
Fixes: c45568cc4e51 ("Convert CONFIG_SYS_BOOTM_LEN to Kconfig")
Signed-off-by: Patrick Delaunay
---
include/configs/stm32mp13_common.h | 2 --
include/configs/stm32mp15_common.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/configs/stm32mp13_common.h
b/include/configs/stm32mp13_common.h
index 3ca65ea2a37..78089b965ae 100644
--- a/include/configs/stm32mp13_common.h
+++ b/include/configs/stm32mp13_common.h
@@ -21,8 +21,6 @@
*/
#define CONFIG_SYS_BOOTMAPSZ SZ_256M
-/* Extend size of kernel image for uncompression */
-
/*MMC SD*/
#define CONFIG_SYS_MMC_MAX_DEVICE 2
diff --git a/include/configs/stm32mp15_common.h
b/include/configs/stm32mp15_common.h
index c5412ffeb31..bd8e16bc1b9 100644
--- a/include/configs/stm32mp15_common.h
+++ b/include/configs/stm32mp15_common.h
@@ -21,8 +21,6 @@
*/
#define CONFIG_SYS_BOOTMAPSZ SZ_256M
-/* Extend size of kernel image for uncompression */
-
/*MMC SD*/
#define CONFIG_SYS_MMC_MAX_DEVICE 3
--
2.25.1
[PATCH] arm: socfpga: soc64: Use UCLASS_MTD instead of UCLASS_MISC
From: Ley Foon Tan
Commit 407b01b3b3f5 ("mtd: rawnand: denali_dt: use UCLASS_MTD instead of
UCLASS_MISC") change to use UCLASS_MTD instead of UCLASS_MISC. Update
spl_boot_device() to use UCLASS_MTD.
Signed-off-by: Ley Foon Tan
Signed-off-by: Jit Loon Lim
---
arch/arm/mach-socfpga/spl_soc64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/spl_soc64.c
b/arch/arm/mach-socfpga/spl_soc64.c
index ea1acaf309..38f69aa957 100644
--- a/arch/arm/mach-socfpga/spl_soc64.c
+++ b/arch/arm/mach-socfpga/spl_soc64.c
@@ -62,7 +62,7 @@ u32 spl_boot_device(void)
switch (device_get_uclass_id(dev)) {
case UCLASS_SPI_FLASH:
return BOOT_DEVICE_SPI;
- case UCLASS_MISC:
+ case UCLASS_MTD:
return BOOT_DEVICE_NAND;
case UCLASS_MMC:
return BOOT_DEVICE_MMC1;
--
2.26.2
Re: Please pull u-boot-watchdog/next
Hi Tom, On 16.09.22 16:21, Tom Rini wrote: On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote: On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: Hi Tom, please pull the following watchdog related patches: - Migrate watchdog reset to cyclic infrastructure (Stefan) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results Thanks, Stefan The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852: Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: watchdog: Further cleanup (2022-09-16 07:09:05 +0200) Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still? I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab. I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing. Thanks for all your testing Tom. I'll check, if I still have an AM355x here. I just now found an Cubieboard2, which also seems to have SPL watchdog enabled. Let me check, if I can get this board running and tested. If all fails, I'll get back to you with the offer to access your HW. Thanks, Stefan
Re: [PATCH v2 0/3] Add riscv semihosting support in u-boot
On Fri, Sep 16, 2022 at 09:11:11AM -0400, Sean Anderson wrote: > Hi Pali, > > On 9/16/22 05:12, Pali Rohár wrote: > > That is strange because I'm not aware of the fact that I'm riscv maintainer. > > get_maintainer will pick up anyone who has touched a file recently, even in > unrelated areas. A quick git log shows that the following commits have > overlapping files with this series: > > 948da7773e arm: Add new config option ARCH_VERY_EARLY_INIT > 1a47e6d47c crc16: Move standard CRC-16 implementation from ubifs to lib > bb3d71b7ef crc16-ccitt: Rename file with CRC-16-CCITT implementation to > crc16-ccitt.c > 372779abc3 arm: Introduce new CONFIG_SPL_SYS_NO_VECTOR_TABLE option > > I'm not a fan of this behavior, so I edit the output of get_maintainers > before using it. Does --no-git provide the behavior you're both looking for? We should likely tweak the .get_maintainers.conf file. -- Tom signature.asc Description: PGP signature
[PATCH 2/2] arm: spl: create a common spl for Stratix10 and Agilex
From: "Ooi, Joyce"
Since Stratix10 and Agilex are using ARM64, there are some common codes
in the SPL. Hence, spl_soc64.c is created to place the common codes.
Signed-off-by: Ooi, Joyce
Signed-off-by: Jit Loon Lim
---
arch/arm/mach-socfpga/spl_s10.c | 63 ---
arch/arm/mach-socfpga/spl_soc64.c | 71 +--
2 files changed, 67 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
index c4b82ebf14..fb807acf27 100644
--- a/arch/arm/mach-socfpga/spl_s10.c
+++ b/arch/arm/mach-socfpga/spl_s10.c
@@ -29,69 +29,6 @@
DECLARE_GLOBAL_DATA_PTR;
-u32 spl_boot_device(void)
-{
- int ret, size;
- ofnode node;
- const fdt32_t *phandle_p;
- u32 phandle;
- struct udevice *dev;
-
- node = ofnode_path("/chosen");
- if (!ofnode_valid(node)) {
- debug("%s: /chosen node was not found.\n", __func__);
- goto fallback;
- }
-
- phandle_p = ofnode_get_property(node, "u-boot,boot0", );
- if (!phandle_p) {
- debug("%s: u-boot,boot0 property was not found.\n",
-__func__);
- goto fallback;
- }
-
- phandle = fdt32_to_cpu(*phandle_p);
-
- node = ofnode_get_by_phandle(phandle);
-
- ret = device_get_global_by_ofnode(node, );
- if (ret) {
- debug("%s: Boot device at not found, error: %d\n", __func__,
- ret);
- goto fallback;
- }
-
- debug("%s: Found boot device %s\n", __func__, dev->name);
-
- switch (device_get_uclass_id(dev)) {
- case UCLASS_SPI_FLASH:
- return BOOT_DEVICE_SPI;
- case UCLASS_MISC:
- return BOOT_DEVICE_NAND;
- case UCLASS_MMC:
- return BOOT_DEVICE_MMC1;
- default:
- debug("%s: Booting from device uclass '%s' is not "
- "supported\n", __func__,
- dev_get_uclass_name(dev));
- }
-
-fallback:
- /* Return default boot device */
- return BOOT_DEVICE_MMC1;
-}
-
-#ifdef CONFIG_SPL_MMC_SUPPORT
-u32 spl_mmc_boot_mode(const u32 boot_device)
-{
-#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
- return MMCSD_MODE_FS;
-#else
- return MMCSD_MODE_RAW;
-#endif
-}
-#endif
-
void board_init_f(ulong dummy)
{
const struct cm_config *cm_default_cfg = cm_get_default_config();
diff --git a/arch/arm/mach-socfpga/spl_soc64.c
b/arch/arm/mach-socfpga/spl_soc64.c
index ba6efc1d86..ea1acaf309 100644
--- a/arch/arm/mach-socfpga/spl_soc64.c
+++ b/arch/arm/mach-socfpga/spl_soc64.c
@@ -4,22 +4,85 @@
*
*/
+#include
+#include
+#include
#include
+#include
+#include
+#include
+#include
+#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
u32 spl_boot_device(void)
{
+ int ret, size;
+ ofnode node;
+ const fdt32_t *phandle_p;
+ u32 phandle;
+ struct udevice *dev;
+
+ node = ofnode_path("/chosen");
+ if (!ofnode_valid(node)) {
+ debug("%s: /chosen node was not found.\n", __func__);
+ goto fallback;
+ }
+
+ phandle_p = ofnode_get_property(node, "u-boot,boot0", );
+ if (!phandle_p) {
+ debug("%s: u-boot,boot0 property was not found.\n",
+ __func__);
+ goto fallback;
+ }
+
+ phandle = fdt32_to_cpu(*phandle_p);
+
+ node = ofnode_get_by_phandle(phandle);
+
+ ret = device_get_global_by_ofnode(node, );
+ if (ret) {
+ debug("%s: Boot device at not found, error: %d\n", __func__,
+ ret);
+ goto fallback;
+ }
+
+ debug("%s: Found boot device %s\n", __func__, dev->name);
+
+ switch (device_get_uclass_id(dev)) {
+ case UCLASS_SPI_FLASH:
+ return BOOT_DEVICE_SPI;
+ case UCLASS_MISC:
+ return BOOT_DEVICE_NAND;
+ case UCLASS_MMC:
+ return BOOT_DEVICE_MMC1;
+ default:
+ debug("%s: Booting from device uclass '%s' is not supported\n",
+ __func__, dev_get_uclass_name(dev));
+ }
+
+fallback:
+ /* Return default boot device */
return BOOT_DEVICE_MMC1;
}
#if IS_ENABLED(CONFIG_SPL_MMC)
u32 spl_boot_mode(const u32 boot_device)
{
- if (IS_ENABLED(CONFIG_SPL_FS_FAT) || IS_ENABLED(CONFIG_SPL_FS_EXT4))
- return MMCSD_MODE_FS;
- else
- return MMCSD_MODE_RAW;
+#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
+ return MMCSD_MODE_FS;
+#else
+ return MMCSD_MODE_RAW;
+#endif
}
#endif
--
2.26.2
[PATCH 1/2] spl: socfpga: Getting SPL boot device from DT
From: Tien Fong Chee
Current SPL boot device is harcoded with MMC1, this implementation
would inhibit the support of other boot device. So, this patch is
created to get the boot device from DT, user should define the boot
device in property "u-boot,boot0". Default MMC1 would be boot device if
no boot device is defined in DT.
Signed-off-by: Tien Fong Chee
Signed-off-by: Jit Loon Lim
---
arch/arm/dts/socfpga_stratix10_socdk.dts | 1 +
arch/arm/mach-socfpga/spl_s10.c | 65
2 files changed, 66 insertions(+)
diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index 8aa55a60ab..c8e9261f48 100755
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -16,6 +16,7 @@
chosen {
stdout-path = "serial0:115200n8";
+ u-boot,boot0 = <>;
};
leds {
diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
index dad2ac5d0d..c4b82ebf14 100644
--- a/arch/arm/mach-socfpga/spl_s10.c
+++ b/arch/arm/mach-socfpga/spl_s10.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -27,6 +29,69 @@
DECLARE_GLOBAL_DATA_PTR;
+u32 spl_boot_device(void)
+{
+ int ret, size;
+ ofnode node;
+ const fdt32_t *phandle_p;
+ u32 phandle;
+ struct udevice *dev;
+
+ node = ofnode_path("/chosen");
+ if (!ofnode_valid(node)) {
+ debug("%s: /chosen node was not found.\n", __func__);
+ goto fallback;
+ }
+
+ phandle_p = ofnode_get_property(node, "u-boot,boot0", );
+ if (!phandle_p) {
+ debug("%s: u-boot,boot0 property was not found.\n",
+__func__);
+ goto fallback;
+ }
+
+ phandle = fdt32_to_cpu(*phandle_p);
+
+ node = ofnode_get_by_phandle(phandle);
+
+ ret = device_get_global_by_ofnode(node, );
+ if (ret) {
+ debug("%s: Boot device at not found, error: %d\n", __func__,
+ ret);
+ goto fallback;
+ }
+
+ debug("%s: Found boot device %s\n", __func__, dev->name);
+
+ switch (device_get_uclass_id(dev)) {
+ case UCLASS_SPI_FLASH:
+ return BOOT_DEVICE_SPI;
+ case UCLASS_MISC:
+ return BOOT_DEVICE_NAND;
+ case UCLASS_MMC:
+ return BOOT_DEVICE_MMC1;
+ default:
+ debug("%s: Booting from device uclass '%s' is not "
+ "supported\n", __func__,
+ dev_get_uclass_name(dev));
+ }
+
+fallback:
+ /* Return default boot device */
+ return BOOT_DEVICE_MMC1;
+}
+
+#ifdef CONFIG_SPL_MMC_SUPPORT
+u32 spl_mmc_boot_mode(const u32 boot_device)
+{
+#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
+ return MMCSD_MODE_FS;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+}
+#endif
+
void board_init_f(ulong dummy)
{
const struct cm_config *cm_default_cfg = cm_get_default_config();
--
2.26.2
Re: Please pull u-boot-watchdog/next
On Fri, Sep 16, 2022 at 10:08:51AM -0400, Tom Rini wrote: > On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: > > > Hi Tom, > > > > please pull the following watchdog related patches: > > > > > > - Migrate watchdog reset to cyclic infrastructure (Stefan) > > > > > > Here the Azure build, without any issues: > > > > https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results > > > > Thanks, > > Stefan > > > > The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852: > > > > Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 > > 17:02:52 -0400) > > > > are available in the Git repository at: > > > > g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next > > > > for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: > > > > watchdog: Further cleanup (2022-09-16 07:09:05 +0200) > > > > > > Stefan Roese (6): > > watchdog: Integrate watchdog triggering into the cyclic framework > > cyclic: Introduce schedule() function > > cyclic: Use schedule() instead of WATCHDOG_RESET() > > watchdog: Get rid of ASSEMBLY hacks > > watchdog: Remove WATCHDOG_RESET macro > > watchdog: Further cleanup > > Good bad news, I've got your first hardware failure report. One of > these three: > cyclic: Use schedule() instead of WATCHDOG_RESET() > cyclic: Introduce schedule() function > watchdog: Integrate watchdog triggering into the cyclic framework > > Causes am335x_evm to have no output in SPL and just hang. It, along with > all of the other TI AM335x platforms have watchdog enabled in SPL. I can > also observe that the system watchdog is not triggering, so maybe we're > stuck in some loop where that's being serviced still? > > I suspect all the am335x boards are broken, so if you don't have > something there you can test on let me know off-list and I'll get you > access to my lab. > I'll note that pine64_plus_defconfig is now also failing, but interestingly dra7xx_evm_defconfig is passing. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-watchdog/next
On Fri, Sep 16, 2022 at 09:22:16AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following watchdog related patches: > > > - Migrate watchdog reset to cyclic infrastructure (Stefan) > > > Here the Azure build, without any issues: > > https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results > > Thanks, > Stefan > > The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852: > > Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 > 17:02:52 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next > > for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: > > watchdog: Further cleanup (2022-09-16 07:09:05 +0200) > > > Stefan Roese (6): > watchdog: Integrate watchdog triggering into the cyclic framework > cyclic: Introduce schedule() function > cyclic: Use schedule() instead of WATCHDOG_RESET() > watchdog: Get rid of ASSEMBLY hacks > watchdog: Remove WATCHDOG_RESET macro > watchdog: Further cleanup Good bad news, I've got your first hardware failure report. One of these three: cyclic: Use schedule() instead of WATCHDOG_RESET() cyclic: Introduce schedule() function watchdog: Integrate watchdog triggering into the cyclic framework Causes am335x_evm to have no output in SPL and just hang. It, along with all of the other TI AM335x platforms have watchdog enabled in SPL. I can also observe that the system watchdog is not triggering, so maybe we're stuck in some loop where that's being serviced still? I suspect all the am335x boards are broken, so if you don't have something there you can test on let me know off-list and I'll get you access to my lab. -- Tom signature.asc Description: PGP signature
[PATCH] ddr: socfpga: Disable the useeccasdata when ECC is enabled
From: Tien Fong Chee
This field allows the FPGA ports to directly access the extra data bits
that are normally used to hold the ECC code, so this field must be clear
when it's used for ECC data.
Signed-off-by: Tien Fong Chee
Signed-off-by: Teik Heng Chong
---
drivers/ddr/altera/sdram_gen5.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c
index 9d69f009e9..085d146179 100644
--- a/drivers/ddr/altera/sdram_gen5.c
+++ b/drivers/ddr/altera/sdram_gen5.c
@@ -659,6 +659,9 @@ static int altera_gen5_sdram_probe(struct udevice *dev)
debug("SDRAM: %ld MiB\n", sdram_size >> 20);
if (sdram_is_ecc_enabled(sdr_ctrl)) {
+ /* Must set USEECCASDATA to 0 if ECC is enabled */
+ clrbits_le32(_ctrl->static_cfg,
+SDR_CTRLGRP_STATICCFG_USEECCASDATA_MASK);
sdram_init_ecc_bits(sdram_size);
}
--
2.26.2
Re: [PATCH v2 0/3] Add riscv semihosting support in u-boot
Hi Pali, On 9/16/22 05:12, Pali Rohár wrote: That is strange because I'm not aware of the fact that I'm riscv maintainer. get_maintainer will pick up anyone who has touched a file recently, even in unrelated areas. A quick git log shows that the following commits have overlapping files with this series: 948da7773e arm: Add new config option ARCH_VERY_EARLY_INIT 1a47e6d47c crc16: Move standard CRC-16 implementation from ubifs to lib bb3d71b7ef crc16-ccitt: Rename file with CRC-16-CCITT implementation to crc16-ccitt.c 372779abc3 arm: Introduce new CONFIG_SPL_SYS_NO_VECTOR_TABLE option I'm not a fan of this behavior, so I edit the output of get_maintainers before using it. --Sean On Friday 16 September 2022 14:40:46 Kautuk Consul wrote: Sorry about that! I ran get_maintainer.pl on my patchset and got your name along with several others so I also sent to you. On Fri, Sep 16, 2022 at 2:38 PM Pali Rohár wrote: Hello! I'm not riscv maintainer and therefore I'm not going to review this patch series. Please do not spam me with unrelated emails and patches as I would loose track of patches and emails which are import and which I should review. Thanks. On Friday 16 September 2022 13:42:30 Kautuk Consul wrote: Semihosting is a mechanism that enables code running on a target to communicate and use the Input/Output facilities on a host computer that is running a debugger. This patchset adds support for semihosting in u-boot for RISCV64 targets. CHANGES since v1: - Moved the identical smh_* and semihosting_enabled/disable_semihosting code of ARM and RISC-V to lib/semihosting.c - Extend the handle_trap() functionality to call disable_semihosting() if the cause is a breakpoint (i.e. ebreak instruction) - Change our implementation of semihosting_enabled to be exactly the same as the way ARM implemented it - Additionally enable the CONFIG_SPL_FS_EXT4 and CONFIG_SPL_FS_FAT configs for qemu defconfigs so that CONFIG_SPL_FS_LOAD_PAYLOAD_NAME gets automatically enabled instead of us #defining it in include/configs/qemu-riscv.h Compilation and test commands for SPL and S-mode configurations = U-Boot S-mode on QEMU virt // Compilation of S-mode u-boot ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_smode_defconfig make // Run riscv 64-bit u-boot with opensbi on qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ u-boot/u-boot.bin U-Boot SPL on QEMU virt // Compilation of u-boot-spl ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_spl_defconfig make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin // Run 64-bit u-boot-spl in qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ u-boot/spl/u-boot-spl.bin -device\ loader,file=u-boot/u-boot.itb,addr=0x8020 Kautuk Consul (3): lib: Add common semihosting library arch/riscv: add semihosting support for RISC-V board: qemu-riscv: enable semihosting arch/arm/Kconfig | 2 + arch/arm/lib/semihosting.c | 179 +- arch/riscv/Kconfig | 47 +++ arch/riscv/include/asm/semihosting.h | 11 ++ arch/riscv/include/asm/spl.h | 1 + arch/riscv/lib/Makefile | 2 + arch/riscv/lib/interrupts.c | 11 ++ arch/riscv/lib/semihosting.c | 24 configs/qemu-riscv32_defconfig | 4 + configs/qemu-riscv32_smode_defconfig | 4 + configs/qemu-riscv32_spl_defconfig | 7 + configs/qemu-riscv64_defconfig | 4 + configs/qemu-riscv64_smode_defconfig | 4 + configs/qemu-riscv64_spl_defconfig | 7 + include/semihosting.h| 11 ++ lib/Kconfig | 3 + lib/Makefile | 2 + lib/semihosting.c| 186 +++ 18 files changed, 331 insertions(+), 178 deletions(-) create mode 100644 arch/riscv/include/asm/semihosting.h create mode 100644 arch/riscv/lib/semihosting.c create mode 100644 lib/semihosting.c -- 2.34.1
Re: [PATCH V4] bsh: imx6ulz_smm_m2: Add imx6ulz BSH SMM M2 boards
Hi Stefano I have more patches on m2 and I need to know if you are going to request the merge to Tom soon or later. Alternative you can drop this one and keep the new one Michael On Fri, Jul 29, 2022 at 12:10 PM wrote: > > > Introduce BSH SystemMaster (SMM) M2 board family, which consists of: > > imx6ulz SMM M2 and imx6ulz SMM M2 PRO boards. > > Add support for imx6ulz BSH SMM M2 board: > > - 128 MiB DDR3 RAM > > - 256MiB Nand > > - USBOTG1 peripheral - fastboot. > > Signed-off-by: Michael Trimarchi > Applied to u-boot-imx, master, thanks ! > > Best regards, > Stefano Babic > > -- > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
On Friday 16 September 2022 22:34:52 Chris Packham wrote: > I do wonder if the boot seqence and xmodem stuff could be abstracted out to > something that could be reused by other tools. In the past I was thinking about it... but I come to the conclusion that it is easier to write specific tools which implements communication with just one BootROM. Trying to write one universal thing just opens a lot of issues and at the end it would do same thing like if you implement N independent applications and then additional "launcher" application which starts the correct one. It looks like that most Marvell SoCs use xmodem protocol. Except 3720 which uses WTPTP. But as I figured out, every SoC use slightly modified protocol based on xmodem. So well, in theory "sx" would work. But if you want to have other features (like progress bar or bootrom output or speed change) then all this is bootrom specific and has to be implemented directly into xmodem state machine. So either you provide N xmodem implementations or try to create something "hookable" and since beginning I have feeling that "hooks" would just introduce new bugs and make it harder to debug. kwboot is currently in the state that it supports kwbimage v0 and kwbimage v1 formats, which IIRC covers all 32-bit widely used SoCs from kirkwood, dove, armada and switches which integrates those CPUs, and probably also avanta. At lot of stages it expects valid kwbimage and that is why there is validation at the beginning. It injects 32-bit ARM binary code for changing UART speed and requires above SoC (as it touches internal registers, which are same on all those mentioned). It also contains workarounds for bugs in Armada 385 BootROMs. I really think that kwboot is now in state when it is not easily possible to extend it for different platform without lot of energy and extra testing that it does not break something existing.
Re: [PATCH v2 0/3] Add riscv semihosting support in u-boot
Sorry about that! I ran get_maintainer.pl on my patchset and got your name along with several others so I also sent to you. On Fri, Sep 16, 2022 at 2:38 PM Pali Rohár wrote: > > Hello! I'm not riscv maintainer and therefore I'm not going to review > this patch series. Please do not spam me with unrelated emails and > patches as I would loose track of patches and emails which are import > and which I should review. Thanks. > > On Friday 16 September 2022 13:42:30 Kautuk Consul wrote: > > Semihosting is a mechanism that enables code running on > > a target to communicate and use the Input/Output > > facilities on a host computer that is running a debugger. > > This patchset adds support for semihosting in u-boot > > for RISCV64 targets. > > > > CHANGES since v1: > > - Moved the identical smh_* and semihosting_enabled/disable_semihosting > > code of ARM and RISC-V to lib/semihosting.c > > - Extend the handle_trap() functionality to call disable_semihosting() > > if the cause is a breakpoint (i.e. ebreak instruction) > > - Change our implementation of semihosting_enabled to be exactly the > > same as the way ARM implemented it > > - Additionally enable the CONFIG_SPL_FS_EXT4 and CONFIG_SPL_FS_FAT > > configs for qemu defconfigs so that CONFIG_SPL_FS_LOAD_PAYLOAD_NAME > > gets automatically enabled instead of us #defining it in > > include/configs/qemu-riscv.h > > > > Compilation and test commands for SPL and S-mode configurations > > = > > > > U-Boot S-mode on QEMU virt > > > > // Compilation of S-mode u-boot > > ARCH=riscv > > CROSS_COMPILE=riscv64-unknown-linux-gnu- > > make qemu-riscv64_smode_defconfig > > make > > // Run riscv 64-bit u-boot with opensbi on qemu > > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > > opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ > > u-boot/u-boot.bin > > > > U-Boot SPL on QEMU virt > > > > // Compilation of u-boot-spl > > ARCH=riscv > > CROSS_COMPILE=riscv64-unknown-linux-gnu- > > make qemu-riscv64_spl_defconfig > > make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin > > // Run 64-bit u-boot-spl in qemu > > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > > u-boot/spl/u-boot-spl.bin -device\ > > loader,file=u-boot/u-boot.itb,addr=0x8020 > > > > Kautuk Consul (3): > > lib: Add common semihosting library > > arch/riscv: add semihosting support for RISC-V > > board: qemu-riscv: enable semihosting > > > > arch/arm/Kconfig | 2 + > > arch/arm/lib/semihosting.c | 179 +- > > arch/riscv/Kconfig | 47 +++ > > arch/riscv/include/asm/semihosting.h | 11 ++ > > arch/riscv/include/asm/spl.h | 1 + > > arch/riscv/lib/Makefile | 2 + > > arch/riscv/lib/interrupts.c | 11 ++ > > arch/riscv/lib/semihosting.c | 24 > > configs/qemu-riscv32_defconfig | 4 + > > configs/qemu-riscv32_smode_defconfig | 4 + > > configs/qemu-riscv32_spl_defconfig | 7 + > > configs/qemu-riscv64_defconfig | 4 + > > configs/qemu-riscv64_smode_defconfig | 4 + > > configs/qemu-riscv64_spl_defconfig | 7 + > > include/semihosting.h| 11 ++ > > lib/Kconfig | 3 + > > lib/Makefile | 2 + > > lib/semihosting.c| 186 +++ > > 18 files changed, 331 insertions(+), 178 deletions(-) > > create mode 100644 arch/riscv/include/asm/semihosting.h > > create mode 100644 arch/riscv/lib/semihosting.c > > create mode 100644 lib/semihosting.c > > > > -- > > 2.34.1 > >
[PATCH v2 0/3] Add riscv semihosting support in u-boot
Semihosting is a mechanism that enables code running on a target to communicate and use the Input/Output facilities on a host computer that is running a debugger. This patchset adds support for semihosting in u-boot for RISCV64 targets. CHANGES since v1: - Moved the identical smh_* and semihosting_enabled/disable_semihosting code of ARM and RISC-V to lib/semihosting.c - Extend the handle_trap() functionality to call disable_semihosting() if the cause is a breakpoint (i.e. ebreak instruction) - Change our implementation of semihosting_enabled to be exactly the same as the way ARM implemented it - Additionally enable the CONFIG_SPL_FS_EXT4 and CONFIG_SPL_FS_FAT configs for qemu defconfigs so that CONFIG_SPL_FS_LOAD_PAYLOAD_NAME gets automatically enabled instead of us #defining it in include/configs/qemu-riscv.h Compilation and test commands for SPL and S-mode configurations = U-Boot S-mode on QEMU virt // Compilation of S-mode u-boot ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_smode_defconfig make // Run riscv 64-bit u-boot with opensbi on qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ u-boot/u-boot.bin U-Boot SPL on QEMU virt // Compilation of u-boot-spl ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_spl_defconfig make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin // Run 64-bit u-boot-spl in qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ u-boot/spl/u-boot-spl.bin -device\ loader,file=u-boot/u-boot.itb,addr=0x8020 Kautuk Consul (3): lib: Add common semihosting library arch/riscv: add semihosting support for RISC-V board: qemu-riscv: enable semihosting arch/arm/Kconfig | 2 + arch/arm/lib/semihosting.c | 179 +- arch/riscv/Kconfig | 47 +++ arch/riscv/include/asm/semihosting.h | 11 ++ arch/riscv/include/asm/spl.h | 1 + arch/riscv/lib/Makefile | 2 + arch/riscv/lib/interrupts.c | 11 ++ arch/riscv/lib/semihosting.c | 24 configs/qemu-riscv32_defconfig | 4 + configs/qemu-riscv32_smode_defconfig | 4 + configs/qemu-riscv32_spl_defconfig | 7 + configs/qemu-riscv64_defconfig | 4 + configs/qemu-riscv64_smode_defconfig | 4 + configs/qemu-riscv64_spl_defconfig | 7 + include/semihosting.h| 11 ++ lib/Kconfig | 3 + lib/Makefile | 2 + lib/semihosting.c| 186 +++ 18 files changed, 331 insertions(+), 178 deletions(-) create mode 100644 arch/riscv/include/asm/semihosting.h create mode 100644 arch/riscv/lib/semihosting.c create mode 100644 lib/semihosting.c -- 2.34.1
[PATCH v2 3/3] board: qemu-riscv: enable semihosting
To enable semihosting we also need to enable the following configs in defconfigs: CONFIG_SEMIHOSTING CONFIG_SPL_SEMIHOSTING CONFIG_SEMIHOSTING_SERIAL CONFIG_SERIAL_PROBE_ALL CONFIG_SPL_FS_EXT4 CONFIG_SPL_FS_FAT Signed-off-by: Kautuk Consul --- configs/qemu-riscv32_defconfig | 4 configs/qemu-riscv32_smode_defconfig | 4 configs/qemu-riscv32_spl_defconfig | 7 +++ configs/qemu-riscv64_defconfig | 4 configs/qemu-riscv64_smode_defconfig | 4 configs/qemu-riscv64_spl_defconfig | 7 +++ 6 files changed, 30 insertions(+) diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig index 9634d7f77f..4961652548 100644 --- a/configs/qemu-riscv32_defconfig +++ b/configs/qemu-riscv32_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -20,3 +21,6 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig index 1c5a0617aa..91e4ffebc2 100644 --- a/configs/qemu-riscv32_smode_defconfig +++ b/configs/qemu-riscv32_smode_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -21,4 +22,7 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index 2421c9a371..5fd28fc58c 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -1,9 +1,12 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y +CONFIG_SPL_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_SPL=y +CONFIG_SPL_FS_FAT=y CONFIG_SYS_LOAD_ADDR=0x8020 CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y @@ -18,6 +21,7 @@ CONFIG_DISPLAY_BOARDINFO=y CONFIG_SPL_MAX_SIZE=0x10 CONFIG_SPL_BSS_START_ADDR=0x8400 CONFIG_SYS_SPL_MALLOC=y +CONFIG_SPL_FS_EXT4=y CONFIG_SYS_CBSIZE=256 CONFIG_SYS_PBSIZE=276 CONFIG_SYS_BOOTM_LEN=0x400 @@ -25,5 +29,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y # CONFIG_BINMAN_FDT is not set diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig index d5eae95c80..87478f4481 100644 --- a/configs/qemu-riscv64_defconfig +++ b/configs/qemu-riscv64_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -21,3 +22,6 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig index 2861d07f97..5e9d6af3be 100644 --- a/configs/qemu-riscv64_smode_defconfig +++ b/configs/qemu-riscv64_smode_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -24,4 +25,7 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index 1ecfa27ce2..e5d817b783 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -1,9 +1,12 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y +CONFIG_SPL_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64" CONFIG_SPL=y +CONFIG_SPL_FS_FAT=y CONFIG_SYS_LOAD_ADDR=0x8020 CONFIG_TARGET_QEMU_VIRT=y CONFIG_ARCH_RV64I=y @@ -18,6 +21,7 @@ CONFIG_DISPLAY_BOARDINFO=y CONFIG_SPL_MAX_SIZE=0x10 CONFIG_SPL_BSS_START_ADDR=0x8400 CONFIG_SYS_SPL_MALLOC=y +CONFIG_SPL_FS_EXT4=y CONFIG_SYS_CBSIZE=256 CONFIG_SYS_PBSIZE=276 CONFIG_SYS_BOOTM_LEN=0x400 @@ -25,5 +29,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y # CONFIG_BINMAN_FDT is not set -- 2.34.1
[PATCH v2 2/3] arch/riscv: add semihosting support for RISC-V
We add RISC-V semihosting based serial console for JTAG based early
debugging.
The RISC-V semihosting specification is available at:
https://github.com/riscv/riscv-semihosting-spec/blob/main/riscv-semihosting-spec.adoc
Signed-off-by: Anup Patel
Signed-off-by: Kautuk Consul
---
arch/riscv/Kconfig | 47
arch/riscv/include/asm/semihosting.h | 11 +++
arch/riscv/include/asm/spl.h | 1 +
arch/riscv/lib/Makefile | 2 ++
arch/riscv/lib/interrupts.c | 11 +++
arch/riscv/lib/semihosting.c | 24 ++
6 files changed, 96 insertions(+)
create mode 100644 arch/riscv/include/asm/semihosting.h
create mode 100644 arch/riscv/lib/semihosting.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 78e964db12..b15d9028bd 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -371,4 +371,51 @@ config TPL_USE_ARCH_MEMSET
endmenu
+config SEMIHOSTING
+ bool "Support RISCV semihosting"
+ select LIB_SEMIHOSTING
+ help
+ Semihosting is a method for a target to communicate with a host
+ debugger. It uses special instructions which the debugger will trap
+ on and interpret. This allows U-Boot to read/write files, print to
+ the console, and execute arbitrary commands on the host system.
+
+ Enabling this option will add support for reading and writing files
+ on the host system. If you don't have a debugger attached then trying
+ to do this will likely cause U-Boot to hang. Say 'n' if you are
unsure.
+
+config SEMIHOSTING_FALLBACK
+ bool "Recover gracefully when semihosting fails"
+ depends on SEMIHOSTING && RISCV
+ default y
+ help
+ Normally, if U-Boot makes a semihosting call and no debugger is
+ attached, then it will panic due to a synchronous abort
+ exception. This config adds an exception handler which will allow
+ U-Boot to recover. Say 'y' if unsure.
+
+config SPL_SEMIHOSTING
+ bool "Support RISCV semihosting in SPL"
+ depends on SPL
+ select LIB_SEMIHOSTING
+ help
+ Semihosting is a method for a target to communicate with a host
+ debugger. It uses special instructions which the debugger will trap
+ on and interpret. This allows U-Boot to read/write files, print to
+ the console, and execute arbitrary commands on the host system.
+
+ Enabling this option will add support for reading and writing files
+ on the host system. If you don't have a debugger attached then trying
+ to do this will likely cause U-Boot to hang. Say 'n' if you are
unsure.
+
+config SPL_SEMIHOSTING_FALLBACK
+ bool "Recover gracefully when semihosting fails in SPL"
+ depends on SPL_SEMIHOSTING && RISCV
+ default y
+ help
+ Normally, if U-Boot makes a semihosting call and no debugger is
+ attached, then it will panic due to a synchronous abort
+ exception. This config adds an exception handler which will allow
+ U-Boot to recover. Say 'y' if unsure.
+
endmenu
diff --git a/arch/riscv/include/asm/semihosting.h
b/arch/riscv/include/asm/semihosting.h
new file mode 100644
index 00..7042821e00
--- /dev/null
+++ b/arch/riscv/include/asm/semihosting.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2022 Ventana Micro Systems Inc.
+ */
+
+#ifndef __ASM_RISCV_SEMIHOSTING_H
+#define __ASM_RISCV_SEMIHOSTING_H
+
+long smh_trap(int sysnum, void *addr);
+
+#endif /* __ASM_RISCV_SEMIHOSTING_H */
diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h
index e8a94fcb1f..2898a770ee 100644
--- a/arch/riscv/include/asm/spl.h
+++ b/arch/riscv/include/asm/spl.h
@@ -25,6 +25,7 @@ enum {
BOOT_DEVICE_DFU,
BOOT_DEVICE_XIP,
BOOT_DEVICE_BOOTROM,
+ BOOT_DEVICE_SMH,
BOOT_DEVICE_NONE
};
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 06020fcc2a..64e29804c1 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -42,3 +42,5 @@ extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMMOVE) += memmove.o
obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
+
+obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += semihosting.o
diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 100be2e966..bd7cd772b8 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -149,6 +150,16 @@ ulong handle_trap(ulong cause, ulong epc, ulong tval,
struct pt_regs *regs)
/* An UEFI application may have changed gd. Restore U-Boot's gd. */
efi_restore_gd();
+ if (cause == CAUSE_BREAKPOINT &&
+ CONFIG_IS_ENABLED(SEMIHOSTING_FALLBACK)) {
+ /*
[PATCH v2 1/3] lib: Add common semihosting library
We factor out the arch-independent parts of the ARM semihosting
implementation as a common library so that it can be shared
with RISC-V.
Signed-off-by: Kautuk Consul
---
arch/arm/Kconfig | 2 +
arch/arm/lib/semihosting.c | 179 +--
include/semihosting.h | 11 +++
lib/Kconfig| 3 +
lib/Makefile | 2 +
lib/semihosting.c | 186 +
6 files changed, 205 insertions(+), 178 deletions(-)
create mode 100644 lib/semihosting.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82cd456f51..81440ff7ea 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -415,6 +415,7 @@ config ARM_SMCCC
config SEMIHOSTING
bool "Support ARM semihosting"
+ select LIB_SEMIHOSTING
help
Semihosting is a method for a target to communicate with a host
debugger. It uses special instructions which the debugger will trap
@@ -437,6 +438,7 @@ config SEMIHOSTING_FALLBACK
config SPL_SEMIHOSTING
bool "Support ARM semihosting in SPL"
+ select LIB_SEMIHOSTING
depends on SPL
help
Semihosting is a method for a target to communicate with a host
diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index 01d652a6b8..41bc5cd62b 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -13,22 +13,10 @@
#include
#include
-#define SYSOPEN0x01
-#define SYSCLOSE 0x02
-#define SYSWRITEC 0x03
-#define SYSWRITE0 0x04
-#define SYSWRITE 0x05
-#define SYSREAD0x06
-#define SYSREADC 0x07
-#define SYSISERROR 0x08
-#define SYSSEEK0x0A
-#define SYSFLEN0x0C
-#define SYSERRNO 0x13
-
/*
* Call the handler
*/
-static noinline long smh_trap(unsigned int sysnum, void *addr)
+long smh_trap(unsigned int sysnum, void *addr)
{
register long result asm("r0");
#if defined(CONFIG_ARM64)
@@ -41,168 +29,3 @@ static noinline long smh_trap(unsigned int sysnum, void
*addr)
#endif
return result;
}
-
-#if CONFIG_IS_ENABLED(SEMIHOSTING_FALLBACK)
-static bool _semihosting_enabled = true;
-static bool try_semihosting = true;
-
-bool semihosting_enabled(void)
-{
- if (try_semihosting) {
- smh_trap(SYSERRNO, NULL);
- try_semihosting = false;
- }
-
- return _semihosting_enabled;
-}
-
-void disable_semihosting(void)
-{
- _semihosting_enabled = false;
-}
-#endif
-
-/**
- * smh_errno() - Read the host's errno
- *
- * This gets the value of the host's errno and negates it. The host's errno may
- * or may not be set, so only call this function if a previous semihosting call
- * has failed.
- *
- * Return: a negative error value
- */
-static int smh_errno(void)
-{
- long ret = smh_trap(SYSERRNO, NULL);
-
- if (ret > 0 && ret < INT_MAX)
- return -ret;
- return -EIO;
-}
-
-long smh_open(const char *fname, enum smh_open_mode mode)
-{
- long fd;
- struct smh_open_s {
- const char *fname;
- unsigned long mode;
- size_t len;
- } open;
-
- debug("%s: file \'%s\', mode \'%u\'\n", __func__, fname, mode);
-
- open.fname = fname;
- open.len = strlen(fname);
- open.mode = mode;
-
- /* Open the file on the host */
- fd = smh_trap(SYSOPEN, );
- if (fd == -1)
- return smh_errno();
- return fd;
-}
-
-/**
- * struct smg_rdwr_s - Arguments for read and write
- * @fd: A file descriptor returned from smh_open()
- * @memp: Pointer to a buffer of memory of at least @len bytes
- * @len: The number of bytes to read or write
- */
-struct smh_rdwr_s {
- long fd;
- void *memp;
- size_t len;
-};
-
-long smh_read(long fd, void *memp, size_t len)
-{
- long ret;
- struct smh_rdwr_s read;
-
- debug("%s: fd %ld, memp %p, len %zu\n", __func__, fd, memp, len);
-
- read.fd = fd;
- read.memp = memp;
- read.len = len;
-
- ret = smh_trap(SYSREAD, );
- if (ret < 0)
- return smh_errno();
- return len - ret;
-}
-
-long smh_write(long fd, const void *memp, size_t len, ulong *written)
-{
- long ret;
- struct smh_rdwr_s write;
-
- debug("%s: fd %ld, memp %p, len %zu\n", __func__, fd, memp, len);
-
- write.fd = fd;
- write.memp = (void *)memp;
- write.len = len;
-
- ret = smh_trap(SYSWRITE, );
- *written = len - ret;
- if (ret)
- return smh_errno();
- return 0;
-}
-
-long smh_close(long fd)
-{
- long ret;
-
- debug("%s: fd %ld\n", __func__, fd);
-
- ret = smh_trap(SYSCLOSE, );
- if (ret == -1)
- return smh_errno();
- return 0;
-}
-
-long smh_flen(long fd)
-{
- long ret;
-
- debug("%s: fd %ld\n", __func__, fd);
-
- ret = smh_trap(SYSFLEN, );
[PATCH v2 0/3] Add riscv semihosting support in u-boot
Semihosting is a mechanism that enables code running on a target to communicate and use the Input/Output facilities on a host computer that is running a debugger. This patchset adds support for semihosting in u-boot for RISCV64 targets. CHANGES since v1: - Moved the identical smh_* and semihosting_enabled/disable_semihosting code of ARM and RISC-V to lib/semihosting.c - Extend the handle_trap() functionality to call disable_semihosting() if the cause is a breakpoint (i.e. ebreak instruction) - Change our implementation of semihosting_enabled to be exactly the same as the way ARM implemented it - Additionally enable the CONFIG_SPL_FS_EXT4 and CONFIG_SPL_FS_FAT configs for qemu defconfigs so that CONFIG_SPL_FS_LOAD_PAYLOAD_NAME gets automatically enabled instead of us #defining it in include/configs/qemu-riscv.h Compilation and test commands for SPL and S-mode configurations = U-Boot S-mode on QEMU virt // Compilation of S-mode u-boot ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_smode_defconfig make // Run riscv 64-bit u-boot with opensbi on qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ u-boot/u-boot.bin U-Boot SPL on QEMU virt // Compilation of u-boot-spl ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_spl_defconfig make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin // Run 64-bit u-boot-spl in qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ u-boot/spl/u-boot-spl.bin -device\ loader,file=u-boot/u-boot.itb,addr=0x8020 Kautuk Consul (3): lib: Add common semihosting library arch/riscv: add semihosting support for RISC-V board: qemu-riscv: enable semihosting arch/arm/Kconfig | 2 + arch/arm/lib/semihosting.c | 179 +- arch/riscv/Kconfig | 47 +++ arch/riscv/include/asm/semihosting.h | 11 ++ arch/riscv/include/asm/spl.h | 1 + arch/riscv/lib/Makefile | 2 + arch/riscv/lib/interrupts.c | 11 ++ arch/riscv/lib/semihosting.c | 24 configs/qemu-riscv32_defconfig | 4 + configs/qemu-riscv32_smode_defconfig | 4 + configs/qemu-riscv32_spl_defconfig | 7 + configs/qemu-riscv64_defconfig | 4 + configs/qemu-riscv64_smode_defconfig | 4 + configs/qemu-riscv64_spl_defconfig | 7 + include/semihosting.h| 11 ++ lib/Kconfig | 3 + lib/Makefile | 2 + lib/semihosting.c| 186 +++ 18 files changed, 331 insertions(+), 178 deletions(-) create mode 100644 arch/riscv/include/asm/semihosting.h create mode 100644 arch/riscv/lib/semihosting.c create mode 100644 lib/semihosting.c -- 2.34.1
Re: [PATCH 0/2] Add riscv semihosting support in u-boot
Hi Sean, Will address your comment in v2 by moving the ARM and RISCV code to generic lib/semihosting.c. On Thu, Sep 15, 2022 at 8:55 PM Sean Anderson wrote: > > Hi Kautuk, > > On 9/15/22 8:45 AM, Kautuk Consul wrote: > > [You don't often get email from kcon...@ventanamicro.com. Learn why this is > > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > Semihosting is a mechanism that enables code running on > > a target to communicate and use the Input/Output > > facilities on a host computer that is running a debugger. > > This patchset adds support for semihosting in u-boot > > for RISCV64 targets. > > > > Compilation and test commands for SPL and S-mode configurations > > = > > > > U-Boot S-mode on QEMU virt > > > > // Compilation of S-mode u-boot > > ARCH=riscv > > CROSS_COMPILE=riscv64-unknown-linux-gnu- > > make qemu-riscv64_smode_defconfig > > make > > // Run riscv 64-bit u-boot with opensbi on qemu > > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > > opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ > > u-boot/u-boot.bin > > > > U-Boot SPL on QEMU virt > > > > // Compilation of u-boot-spl > > ARCH=riscv > > CROSS_COMPILE=riscv64-unknown-linux-gnu- > > make qemu-riscv64_spl_defconfig > > make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin > > // Run 64-bit u-boot-spl in qemu > > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > > u-boot/spl/u-boot-spl.bin -device\ > > loader,file=u-boot/u-boot.itb,addr=0x8020 > > > > Kautuk Consul (2): > > arch/riscv: add semihosting support for RISC-V > > board: qemu-riscv: enable semihosting > > > > arch/riscv/Kconfig | 45 > > arch/riscv/include/asm/semihosting.h | 11 ++ > > arch/riscv/include/asm/spl.h | 1 + > > arch/riscv/lib/Makefile | 7 ++ > > arch/riscv/lib/semihosting.c | 166 +++ > > arch/riscv/lib/semihosting_mmode.c | 77 + > > arch/riscv/lib/semihosting_smode.c | 77 + > > I don't think this is the right approach. The semihosting ABI is > effectively identical on Arm and RISC-V, with the exception of the > actual trap instruction. I think we should add support for RISC-V by > moving the semihosting code (and Kconfig options) to e.g. lib/, and > reduce the arch-specific code to just smh_trap (and any exception > handlers). > > Does that seem reasonable to you? > > --Sean > > > configs/qemu-riscv32_defconfig | 4 + > > configs/qemu-riscv32_smode_defconfig | 4 + > > configs/qemu-riscv32_spl_defconfig | 5 + > > configs/qemu-riscv64_defconfig | 4 + > > configs/qemu-riscv64_smode_defconfig | 4 + > > configs/qemu-riscv64_spl_defconfig | 5 + > > include/configs/qemu-riscv.h | 2 + > > 14 files changed, 412 insertions(+) > > create mode 100644 arch/riscv/include/asm/semihosting.h > > create mode 100644 arch/riscv/lib/semihosting.c > > create mode 100644 arch/riscv/lib/semihosting_mmode.c > > create mode 100644 arch/riscv/lib/semihosting_smode.c > > > > -- > > 2.34.1 > >
Re: [PATCH 1/2] arch/riscv: add semihosting support for RISC-V
Hi Sean,
Don't know about the DCSR.EBREAK option but it will be better for
us to extend the existing trap vector functionality as you mentioned.
Will handle this in v2. This also removes the need for us to implement
our semihosting_enabled() in inline assembly as it will become a
generic lib/semihosting.c function.
On Thu, Sep 15, 2022 at 9:32 PM Sean Anderson wrote:
>
> Hi Kautuk,
>
> I've already noted my general remarks on this approach in response to
> your cover letter. This just has my comments on the RISC-V-specific
> parts.
>
> On 9/15/22 8:45 AM, Kautuk Consul wrote:
> > We add RISC-V semihosting based serial console for JTAG based early
> > debugging.
> >
> > The RISC-V semihosting specification is available at:
> > https://github.com/riscv/riscv-semihosting-spec/blob/main/riscv-semihosting-spec.adoc
> >
> > Signed-off-by: Anup Patel
> > Signed-off-by: Kautuk Consul
> > ---
> > arch/riscv/Kconfig | 45
> > arch/riscv/include/asm/semihosting.h | 11 ++
> > arch/riscv/include/asm/spl.h | 1 +
> > arch/riscv/lib/Makefile | 7 ++
> > arch/riscv/lib/semihosting.c | 166 +++
> > arch/riscv/lib/semihosting_mmode.c | 77 +
> > arch/riscv/lib/semihosting_smode.c | 77 +
> > 7 files changed, 384 insertions(+)
> > create mode 100644 arch/riscv/include/asm/semihosting.h
> > create mode 100644 arch/riscv/lib/semihosting.c
> > create mode 100644 arch/riscv/lib/semihosting_mmode.c
> > create mode 100644 arch/riscv/lib/semihosting_smode.c
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 78e964db12..1b23d1c6c1 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -371,4 +371,49 @@ config TPL_USE_ARCH_MEMSET
> >
> > endmenu
> >
> > +config SEMIHOSTING
> > + bool "Support RISCV semihosting"
> > + help
> > + Semihosting is a method for a target to communicate with a host
> > + debugger. It uses special instructions which the debugger will
> > trap
> > + on and interpret. This allows U-Boot to read/write files, print to
> > + the console, and execute arbitrary commands on the host system.
> > +
> > + Enabling this option will add support for reading and writing
> > files
> > + on the host system. If you don't have a debugger attached then
> > trying
> > + to do this will likely cause U-Boot to hang. Say 'n' if you are
> > unsure.
> > +
> > +config SEMIHOSTING_FALLBACK
> > + bool "Recover gracefully when semihosting fails"
> > + depends on SEMIHOSTING && RISCV
> > + default y
> > + help
> > + Normally, if U-Boot makes a semihosting call and no debugger is
> > + attached, then it will panic due to a synchronous abort
> > + exception. This config adds an exception handler which will allow
> > + U-Boot to recover. Say 'y' if unsure.
> > +
> > +config SPL_SEMIHOSTING
> > + bool "Support RISCV semihosting in SPL"
> > + depends on SPL
> > + help
> > + Semihosting is a method for a target to communicate with a host
> > + debugger. It uses special instructions which the debugger will
> > trap
> > + on and interpret. This allows U-Boot to read/write files, print to
> > + the console, and execute arbitrary commands on the host system.
> > +
> > + Enabling this option will add support for reading and writing
> > files
> > + on the host system. If you don't have a debugger attached then
> > trying
> > + to do this will likely cause U-Boot to hang. Say 'n' if you are
> > unsure.
> > +
> > +config SPL_SEMIHOSTING_FALLBACK
> > + bool "Recover gracefully when semihosting fails in SPL"
> > + depends on SPL_SEMIHOSTING && RISCV
> > + default y
> > + help
> > + Normally, if U-Boot makes a semihosting call and no debugger is
> > + attached, then it will panic due to a synchronous abort
> > + exception. This config adds an exception handler which will allow
> > + U-Boot to recover. Say 'y' if unsure.
> > +
> > endmenu
> > diff --git a/arch/riscv/include/asm/semihosting.h
> > b/arch/riscv/include/asm/semihosting.h
> > new file mode 100644
> > index 00..7042821e00
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/semihosting.h
> > @@ -0,0 +1,11 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2022 Ventana Micro Systems Inc.
> > + */
> > +
> > +#ifndef __ASM_RISCV_SEMIHOSTING_H
> > +#define __ASM_RISCV_SEMIHOSTING_H
> > +
> > +long smh_trap(int sysnum, void *addr);
> > +
> > +#endif /* __ASM_RISCV_SEMIHOSTING_H */
> > diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h
> > index e8a94fcb1f..2898a770ee 100644
> > --- a/arch/riscv/include/asm/spl.h
> > +++ b/arch/riscv/include/asm/spl.h
> > @@ -25,6 +25,7 @@ enum {
> > BOOT_DEVICE_DFU,
> >
Re: [PATCH 2/2] board: qemu-riscv: enable semihosting
Hi Sean, Thanks for the comments. Will address them in v2. On Thu, Sep 15, 2022 at 9:35 PM Sean Anderson wrote: > > > > On 9/15/22 8:45 AM, Kautuk Consul wrote: > > [You don't often get email from kcon...@ventanamicro.com. Learn why this is > > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > To use semihosting on qemu RISCV virt machine, we need the > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME define in qemu-riscv.h. > > > > We also need to enable the following configs in defconfigs: > > CONFIG_SEMIHOSTING > > CONFIG_SPL_SEMIHOSTING > > CONFIG_SEMIHOSTING_SERIAL > > CONFIG_SERIAL_PROBE_ALL > > > > Signed-off-by: Kautuk Consul > > --- > > configs/qemu-riscv32_defconfig | 4 > > configs/qemu-riscv32_smode_defconfig | 4 > > configs/qemu-riscv32_spl_defconfig | 5 + > > configs/qemu-riscv64_defconfig | 4 > > configs/qemu-riscv64_smode_defconfig | 4 > > configs/qemu-riscv64_spl_defconfig | 5 + > > include/configs/qemu-riscv.h | 2 ++ > > 7 files changed, 28 insertions(+) > > > > diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig > > index 9634d7f77f..4961652548 100644 > > --- a/configs/qemu-riscv32_defconfig > > +++ b/configs/qemu-riscv32_defconfig > > @@ -1,4 +1,5 @@ > > CONFIG_RISCV=y > > +CONFIG_SEMIHOSTING=y > > CONFIG_SYS_MALLOC_LEN=0x80 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_ENV_SIZE=0x2 > > @@ -20,3 +21,6 @@ CONFIG_CMD_NVEDIT_EFI=y > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_DM_MTD=y > > CONFIG_SYS_MAX_FLASH_BANKS=2 > > +# CONFIG_SERIAL_PUTS is not set > > Does this have any affect on performance? It does for hardware, > but for software the overhead should be much smaller. > > > +CONFIG_SERIAL_PROBE_ALL=y > > +CONFIG_SEMIHOSTING_SERIAL=y > > diff --git a/configs/qemu-riscv32_smode_defconfig > > b/configs/qemu-riscv32_smode_defconfig > > index 1c5a0617aa..91e4ffebc2 100644 > > --- a/configs/qemu-riscv32_smode_defconfig > > +++ b/configs/qemu-riscv32_smode_defconfig > > @@ -1,4 +1,5 @@ > > CONFIG_RISCV=y > > +CONFIG_SEMIHOSTING=y > > CONFIG_SYS_MALLOC_LEN=0x80 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_ENV_SIZE=0x2 > > @@ -21,4 +22,7 @@ CONFIG_CMD_NVEDIT_EFI=y > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_DM_MTD=y > > CONFIG_SYS_MAX_FLASH_BANKS=2 > > +# CONFIG_SERIAL_PUTS is not set > > +CONFIG_SERIAL_PROBE_ALL=y > > +CONFIG_SEMIHOSTING_SERIAL=y > > CONFIG_SYSRESET_SBI=y > > diff --git a/configs/qemu-riscv32_spl_defconfig > > b/configs/qemu-riscv32_spl_defconfig > > index 2421c9a371..90dbc329e0 100644 > > --- a/configs/qemu-riscv32_spl_defconfig > > +++ b/configs/qemu-riscv32_spl_defconfig > > @@ -1,4 +1,6 @@ > > CONFIG_RISCV=y > > +CONFIG_SEMIHOSTING=y > > +CONFIG_SPL_SEMIHOSTING=y > > CONFIG_SYS_MALLOC_LEN=0x80 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_ENV_SIZE=0x2 > > @@ -25,5 +27,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_DM_MTD=y > > CONFIG_SYS_MAX_FLASH_BANKS=2 > > +# CONFIG_SERIAL_PUTS is not set > > +CONFIG_SERIAL_PROBE_ALL=y > > +CONFIG_SEMIHOSTING_SERIAL=y > > CONFIG_SYSRESET_SBI=y > > # CONFIG_BINMAN_FDT is not set > > diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig > > index d5eae95c80..87478f4481 100644 > > --- a/configs/qemu-riscv64_defconfig > > +++ b/configs/qemu-riscv64_defconfig > > @@ -1,4 +1,5 @@ > > CONFIG_RISCV=y > > +CONFIG_SEMIHOSTING=y > > CONFIG_SYS_MALLOC_LEN=0x80 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_ENV_SIZE=0x2 > > @@ -21,3 +22,6 @@ CONFIG_CMD_NVEDIT_EFI=y > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_DM_MTD=y > > CONFIG_SYS_MAX_FLASH_BANKS=2 > > +# CONFIG_SERIAL_PUTS is not set > > +CONFIG_SERIAL_PROBE_ALL=y > > +CONFIG_SEMIHOSTING_SERIAL=y > > diff --git a/configs/qemu-riscv64_smode_defconfig > > b/configs/qemu-riscv64_smode_defconfig > > index 2861d07f97..5e9d6af3be 100644 > > --- a/configs/qemu-riscv64_smode_defconfig > > +++ b/configs/qemu-riscv64_smode_defconfig > > @@ -1,4 +1,5 @@ > > CONFIG_RISCV=y > > +CONFIG_SEMIHOSTING=y > > CONFIG_SYS_MALLOC_LEN=0x80 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_ENV_SIZE=0x2 > > @@ -24,4 +25,7 @@ CONFIG_CMD_NVEDIT_EFI=y > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_DM_MTD=y > > CONFIG_SYS_MAX_FLASH_BANKS=2 > > +# CONFIG_SERIAL_PUTS is not set > > +CONFIG_SERIAL_PROBE_ALL=y > > +CONFIG_SEMIHOSTING_SERIAL=y > > CONFIG_SYSRESET_SBI=y > > diff --git a/configs/qemu-riscv64_spl_defconfig > > b/configs/qemu-riscv64_spl_defconfig > > index 1ecfa27ce2..fb951293dd 100644 > > --- a/configs/qemu-riscv64_spl_defconfig > > +++ b/configs/qemu-riscv64_spl_defconfig > > @@ -1,4 +1,6 @@ > > CONFIG_RISCV=y > > +CONFIG_SEMIHOSTING=y > > +CONFIG_SPL_SEMIHOSTING=y > > CONFIG_SYS_MALLOC_LEN=0x80 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_ENV_SIZE=0x2 > > @@ -25,5 +27,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_DM_MTD=y > > CONFIG_SYS_MAX_FLASH_BANKS=2 > > +#
[PATCH 0/7] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Chris Packham (7): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support misc: mvebu: Add sample at reset driver arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board tools: kwboot: Add knowledge of Marvell's TIM arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 292 + arch/arm/dts/ac5-98dx35xx-rd.dts | 155 +++ arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 14 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 9 + arch/arm/mach-mvebu/alleycat5/clock.c | 49 arch/arm/mach-mvebu/alleycat5/cpu.c| 129 + arch/arm/mach-mvebu/alleycat5/soc.c| 229 arch/arm/mach-mvebu/arm64-common.c | 15 ++ arch/arm/mach-mvebu/include/mach/clock.h | 11 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + arch/arm/mach-mvebu/include/mach/soc.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 35 +++ configs/mvebu_ac5_rd_defconfig | 89 +++ drivers/misc/Kconfig | 6 + drivers/misc/Makefile | 1 + drivers/misc/mvebu_sar/Makefile| 4 + drivers/misc/mvebu_sar/ac5_sar.c | 119 + drivers/misc/mvebu_sar/sar-uclass.c| 146 +++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 66 - drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 92 +++ include/dm/uclass-id.h | 1 + include/fdtdec.h | 4 + include/mvebu/mvebu_chip_sar.h | 73 ++ include/mvebu/sar.h| 57 include/mvebu/var.h| 28 ++ include/sar-uclass.h | 23 ++ lib/fdtdec.c | 6 +- tools/kwbimage.h | 29 ++ tools/kwboot.c | 3 + 38 files changed, 1767 insertions(+), 18 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 drivers/misc/mvebu_sar/Makefile create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c create mode 100644 include/configs/mvebu_alleycat-5.h create mode 100644 include/mvebu/mvebu_chip_sar.h create mode 100644 include/mvebu/sar.h create mode 100644 include/mvebu/var.h create mode 100644 include/sar-uclass.h -- 2.37.3
Re: [PATCH 1/3] binman: add sign option for binman
On Wed, 2022-09-07 at 15:10 -0600, Simon Glass wrote:
> Hi Ivan,
>
> Section data comes from the BuildSectionData() method, so you could
> try calling that.
>
> See also collect_contents_to_file()
>
> Regards,
> Simon
Simon, I've tried both these ways and they both don't work to me. What
I've got:
def SignEntries(image_fname, input_fname, privatekey_fname, algo,
entry_paths):
image_fname = os.path.abspath(image_fname)
image = Image.FromFile(image_fname)
state.PrepareFromLoadedData(image)
image.LoadData()
1. BuildSectionData
for entry_path in entry_paths:
entry = image.FindEntryPath(entry_path)
try:
entry.BuildSectionData(True)
except Exception as e:
logging.error(traceback.format_exc())
ERROR:root:AttributeError: 'NoneType' object has no attribute 'run'
2. collect_contents_to_file
for entry_path in entry_paths:
entry = image.FindEntryPath(entry_path)
try:
entry.collect_contents_to_file([entry.name], "prefix",
1024)
except Exception as e:
logging.error(traceback.format_exc())
ERROR:root:AttributeError: 'str' object has no attribute
'ObtainContents'
3. GetData
for entry_path in entry_paths:
entry = image.FindEntryPath(entry_path)
print("--- DATA ---")
data = entry.GetData(True)
print(data)
print("~~~ DATA ~~~")
--- DATA ---
Node '/fit/images/u-boot-1/u-boot': GetData: size 0x4
Node '/fit/images/u-boot-1': GetPaddedDataForEntry: size None
Node '/fit/images/u-boot-1': GetData: 1 entries, total size 0x4
Node '/fit/images/fdt-1/u-boot-spl-dtb': GetData: size 0x4f7
Node '/fit/images/fdt-1': GetPaddedDataForEntry: size None
Node '/fit/images/fdt-1': GetData: 1 entries, total size 0x4f7
Deleted temporary directory '/tmp/binman.z81eqcfz'
binman: 'NoneType' object has no attribute 'run'
There is no problem with getting data from GetData around start of the
year. Maybe some regression?
All this ran with this:
binman -v5 sign -i image.bin -k test_key.key -a sha256,rsa4096 fit
`fit` in entry_paths and image contains FIT section with name `fit`.
binman ls -i image.bin
Name Image-pos Size Entry-type Offset
Uncomp-size
---
main-section 0 10 section 0
fit 1 c0a fit 1
u-boot-1 101044 section104
u-boot 101044 u-boot 0
fdt-1 101c8 4f7 section1c8
u-boot-spl-dtb 101c8 4f7 u-boot-spl-dtb 0
fdtmap 10c0a 4f5 fdtmap 10c0a
Seems something went wrong, any ideas? Or did I misuse?
Thanks.
[PATCH 1/2] arch/riscv: add semihosting support for RISC-V
We add RISC-V semihosting based serial console for JTAG based early
debugging.
The RISC-V semihosting specification is available at:
https://github.com/riscv/riscv-semihosting-spec/blob/main/riscv-semihosting-spec.adoc
Signed-off-by: Anup Patel
Signed-off-by: Kautuk Consul
---
arch/riscv/Kconfig | 45
arch/riscv/include/asm/semihosting.h | 11 ++
arch/riscv/include/asm/spl.h | 1 +
arch/riscv/lib/Makefile | 7 ++
arch/riscv/lib/semihosting.c | 166 +++
arch/riscv/lib/semihosting_mmode.c | 77 +
arch/riscv/lib/semihosting_smode.c | 77 +
7 files changed, 384 insertions(+)
create mode 100644 arch/riscv/include/asm/semihosting.h
create mode 100644 arch/riscv/lib/semihosting.c
create mode 100644 arch/riscv/lib/semihosting_mmode.c
create mode 100644 arch/riscv/lib/semihosting_smode.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 78e964db12..1b23d1c6c1 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -371,4 +371,49 @@ config TPL_USE_ARCH_MEMSET
endmenu
+config SEMIHOSTING
+ bool "Support RISCV semihosting"
+ help
+ Semihosting is a method for a target to communicate with a host
+ debugger. It uses special instructions which the debugger will trap
+ on and interpret. This allows U-Boot to read/write files, print to
+ the console, and execute arbitrary commands on the host system.
+
+ Enabling this option will add support for reading and writing files
+ on the host system. If you don't have a debugger attached then trying
+ to do this will likely cause U-Boot to hang. Say 'n' if you are
unsure.
+
+config SEMIHOSTING_FALLBACK
+ bool "Recover gracefully when semihosting fails"
+ depends on SEMIHOSTING && RISCV
+ default y
+ help
+ Normally, if U-Boot makes a semihosting call and no debugger is
+ attached, then it will panic due to a synchronous abort
+ exception. This config adds an exception handler which will allow
+ U-Boot to recover. Say 'y' if unsure.
+
+config SPL_SEMIHOSTING
+ bool "Support RISCV semihosting in SPL"
+ depends on SPL
+ help
+ Semihosting is a method for a target to communicate with a host
+ debugger. It uses special instructions which the debugger will trap
+ on and interpret. This allows U-Boot to read/write files, print to
+ the console, and execute arbitrary commands on the host system.
+
+ Enabling this option will add support for reading and writing files
+ on the host system. If you don't have a debugger attached then trying
+ to do this will likely cause U-Boot to hang. Say 'n' if you are
unsure.
+
+config SPL_SEMIHOSTING_FALLBACK
+ bool "Recover gracefully when semihosting fails in SPL"
+ depends on SPL_SEMIHOSTING && RISCV
+ default y
+ help
+ Normally, if U-Boot makes a semihosting call and no debugger is
+ attached, then it will panic due to a synchronous abort
+ exception. This config adds an exception handler which will allow
+ U-Boot to recover. Say 'y' if unsure.
+
endmenu
diff --git a/arch/riscv/include/asm/semihosting.h
b/arch/riscv/include/asm/semihosting.h
new file mode 100644
index 00..7042821e00
--- /dev/null
+++ b/arch/riscv/include/asm/semihosting.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2022 Ventana Micro Systems Inc.
+ */
+
+#ifndef __ASM_RISCV_SEMIHOSTING_H
+#define __ASM_RISCV_SEMIHOSTING_H
+
+long smh_trap(int sysnum, void *addr);
+
+#endif /* __ASM_RISCV_SEMIHOSTING_H */
diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h
index e8a94fcb1f..2898a770ee 100644
--- a/arch/riscv/include/asm/spl.h
+++ b/arch/riscv/include/asm/spl.h
@@ -25,6 +25,7 @@ enum {
BOOT_DEVICE_DFU,
BOOT_DEVICE_XIP,
BOOT_DEVICE_BOOTROM,
+ BOOT_DEVICE_SMH,
BOOT_DEVICE_NONE
};
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 06020fcc2a..2c89c3a2fa 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -42,3 +42,10 @@ extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMMOVE) += memmove.o
obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
+
+obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += semihosting.o
+ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
+obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += semihosting_mmode.o
+else
+obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += semihosting_smode.o
+endif
diff --git a/arch/riscv/lib/semihosting.c b/arch/riscv/lib/semihosting.c
new file mode 100644
index 00..504c9a1ddc
--- /dev/null
+++ b/arch/riscv/lib/semihosting.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Ventana Micro Systems Inc.
+ */
+
+#include
[PATCH 2/2] board: qemu-riscv: enable semihosting
To use semihosting on qemu RISCV virt machine, we need the CONFIG_SPL_FS_LOAD_PAYLOAD_NAME define in qemu-riscv.h. We also need to enable the following configs in defconfigs: CONFIG_SEMIHOSTING CONFIG_SPL_SEMIHOSTING CONFIG_SEMIHOSTING_SERIAL CONFIG_SERIAL_PROBE_ALL Signed-off-by: Kautuk Consul --- configs/qemu-riscv32_defconfig | 4 configs/qemu-riscv32_smode_defconfig | 4 configs/qemu-riscv32_spl_defconfig | 5 + configs/qemu-riscv64_defconfig | 4 configs/qemu-riscv64_smode_defconfig | 4 configs/qemu-riscv64_spl_defconfig | 5 + include/configs/qemu-riscv.h | 2 ++ 7 files changed, 28 insertions(+) diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig index 9634d7f77f..4961652548 100644 --- a/configs/qemu-riscv32_defconfig +++ b/configs/qemu-riscv32_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -20,3 +21,6 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig index 1c5a0617aa..91e4ffebc2 100644 --- a/configs/qemu-riscv32_smode_defconfig +++ b/configs/qemu-riscv32_smode_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -21,4 +22,7 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index 2421c9a371..90dbc329e0 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -1,4 +1,6 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y +CONFIG_SPL_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -25,5 +27,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y # CONFIG_BINMAN_FDT is not set diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig index d5eae95c80..87478f4481 100644 --- a/configs/qemu-riscv64_defconfig +++ b/configs/qemu-riscv64_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -21,3 +22,6 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig index 2861d07f97..5e9d6af3be 100644 --- a/configs/qemu-riscv64_smode_defconfig +++ b/configs/qemu-riscv64_smode_defconfig @@ -1,4 +1,5 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -24,4 +25,7 @@ CONFIG_CMD_NVEDIT_EFI=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index 1ecfa27ce2..fb951293dd 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -1,4 +1,6 @@ CONFIG_RISCV=y +CONFIG_SEMIHOSTING=y +CONFIG_SPL_SEMIHOSTING=y CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2 @@ -25,5 +27,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYS_MAX_FLASH_BANKS=2 +# CONFIG_SERIAL_PUTS is not set +CONFIG_SERIAL_PROBE_ALL=y +CONFIG_SEMIHOSTING_SERIAL=y CONFIG_SYSRESET_SBI=y # CONFIG_BINMAN_FDT is not set diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h index d81e5d6c86..257d9c5d93 100644 --- a/include/configs/qemu-riscv.h +++ b/include/configs/qemu-riscv.h @@ -48,4 +48,6 @@ "ramdisk_addr_r=0x8c30\0" \ BOOTENV +# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.itb" + #endif /* __CONFIG_H */ -- 2.34.1
[PATCH 0/2] Add riscv semihosting support in u-boot
Semihosting is a mechanism that enables code running on a target to communicate and use the Input/Output facilities on a host computer that is running a debugger. This patchset adds support for semihosting in u-boot for RISCV64 targets. Compilation and test commands for SPL and S-mode configurations = U-Boot S-mode on QEMU virt // Compilation of S-mode u-boot ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_smode_defconfig make // Run riscv 64-bit u-boot with opensbi on qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ u-boot/u-boot.bin U-Boot SPL on QEMU virt // Compilation of u-boot-spl ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- make qemu-riscv64_spl_defconfig make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin // Run 64-bit u-boot-spl in qemu qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ u-boot/spl/u-boot-spl.bin -device\ loader,file=u-boot/u-boot.itb,addr=0x8020 Kautuk Consul (2): arch/riscv: add semihosting support for RISC-V board: qemu-riscv: enable semihosting arch/riscv/Kconfig | 45 arch/riscv/include/asm/semihosting.h | 11 ++ arch/riscv/include/asm/spl.h | 1 + arch/riscv/lib/Makefile | 7 ++ arch/riscv/lib/semihosting.c | 166 +++ arch/riscv/lib/semihosting_mmode.c | 77 + arch/riscv/lib/semihosting_smode.c | 77 + configs/qemu-riscv32_defconfig | 4 + configs/qemu-riscv32_smode_defconfig | 4 + configs/qemu-riscv32_spl_defconfig | 5 + configs/qemu-riscv64_defconfig | 4 + configs/qemu-riscv64_smode_defconfig | 4 + configs/qemu-riscv64_spl_defconfig | 5 + include/configs/qemu-riscv.h | 2 + 14 files changed, 412 insertions(+) create mode 100644 arch/riscv/include/asm/semihosting.h create mode 100644 arch/riscv/lib/semihosting.c create mode 100644 arch/riscv/lib/semihosting_mmode.c create mode 100644 arch/riscv/lib/semihosting_smode.c -- 2.34.1
[U-Boot][bug report] clearfog: EMMC boot broken on clearfog pro
Hi, I am using a clearfog pro with emmc as router. while upgrading from openwrt 21.02.3 to 22.03.0 I discovered, that the provided u-boot binary gets rejected by the BootROM: -> BootROM - 1.73 -> Booting from MMC -> BootROM: Bad header at offset -> BootROM: Bad header at offset 0020 -> Switching BootPartitions. -> BootROM: Invalid HDR source addr While comparing the different u-boot-spl.kwb between openwrt 21.02.3 (u-boot 2021.01) and openwrt 22.03.0 (u-boot 2022.07) I saw that the image has changed from a gpimage to the kwbimage v1. After reading some code, my gut feeling told me, that maybe the BootROM does not like the HDR source addr because it does not expect it to be in sectors but in Bytes. After binary patching the the srcaddr (srcaddr = srcaddr * 512) in the kwbimage v1 header, I got the BootROM to execute the SPL again. -> Booting from MMC -> U-Boot SPL 2022.07-OpenWrt-r19685-512e76967f (Sep 03 2022 - 02:55:34 +) -> High speed PHY - Version: 2.0 -> EEPROM TLV detection failed: Using static config for Clearfog Pro. -> Detected Device ID 6828 -> board SerDes lanes topology details: -> | Lane # | Speed | Type | -> -> | 0| 3 | SATA0 | -> | 1| 0 | SGMII1 | -> | 2| 5 | PCIe1 | -> | 3| 5 | USB3 HOST1 | -> | 4| 5 | PCIe2 | -> | 5| 0 | SGMII2 | -> -> High speed PHY - Ended Successfully -> mv_ddr: 14.0.0 -> DDR3 Training Sequence - Switching XBAR Window to FastPath Window -> mv_ddr: completed successfully -> Trying to boot from MMC1 -> ERROR: Invalid kwbimage v1 -> ERROR: Invalid data checksum in kwbimage -> SPL: failed to boot from all boot devices -> ### ERROR ### Please RESET the board ### I think I do understand the problem here, but I am not quite sure whats the best way to move forward. Unfortunately I am not that familiar with the u-boot sourcecode... Could you give me some pointers, where to start for an integrate-able solution? Thanks!
Re: [PATCH 6/7] arm: mvebu: Add RD-AC5X board
On Friday 16 September 2022 16:54:22 Chris Packham wrote:
> + {
> + status = "okay";
> +
> + spiflash0: flash@0 {
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <5000>;
> + spi-tx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */
> + spi-rx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */
> + reg = <0>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "spi_flash_part0";
I guess such label is useless. There is something stored, so it would be
a wise idea to put there correct label. I do not know how it is on this
platform, but on A3720 at offset 0 is "firmware", which consist of CM3
part, A53 part and U-Boot. It is not even U-Boot itself.
> + reg = <0x0 0x80>;
> + };
> +
> + parition@1 {
> + label = "spi_flash_part1";
> + reg = <0x80 0x70>;
> + };
> +
> + parition@2 {
> + label = "spi_flash_part2";
> + reg = <0xF0 0x10>;
> + };
> + };
> +};
...
> +/* Default Env vars */
> +#define CONFIG_IPADDR 0.0.0.0 /* In order to cause an error */
> +#define CONFIG_SERVERIP 0.0.0.0 /* In order to cause an error */
> +#define CONFIG_NETMASK 255.255.255.0
> +#define CONFIG_GATEWAYIP0.0.0.0
> +#define CONFIG_ETHPRIME "eth0"
> +#define CONFIG_ROOTPATH "/srv/nfs/" /* Default Dir for NFS */
> +#define CONFIG_ENV_OVERWRITE/* ethaddr can be reprogrammed */
> +#define CONFIG_EXTRA_ENV_SETTINGS "bootcmd=run get_images; " \
> + "run set_bootargs; " \
> + "booti $kernel_addr_r " \
> + "$ramdisk_addr_r " \
> + "$fdt_addr_r\0" \
> + "extra_params=pci=pcie_bus_safe\0" \
> + "kernel_addr_r=0x20200\0" \
> + "initrd_addr=0x20600\0"\
> + "initrd_size=0x200\0" \
> + "fdt_addr_r=0x20100\0"\
> + "loadaddr=0x20200\0" \
> + "hostname=marvell\0"\
> + "ramdisk_addr_r=0x20600\0"\
> + "ramfs_name=-\0"\
> + "cpuidle=cpuidle.off=1\0" \
> + "fdt_name=fdt.dtb\0"\
> + "netdev=eth0\0" \
> + "ethaddr=00:51:82:11:22:00\0" \
> + "eth1addr=00:51:82:11:22:01\0" \
> + "image_name=Image\0"\
> + "get_ramfs=if test \"${ramfs_name}\"" \
> + " != \"-\"; then setenv " \
> + "ramdisk_addr_r 0x800; " \
> + "tftpboot $ramdisk_addr_r " \
> + "$ramfs_name; else setenv " \
> + "ramdisk_addr_r -;fi\0" \
> + "get_images=tftpboot $kernel_addr_r " \
> + "$image_name; tftpboot " \
> + "$fdt_addr_r $fdt_name; " \
> + "run get_ramfs\0" \
> + "console=" "console=ttyS0,115200 "\
> + "earlycon=uart8250,mmio32,0xf0512000\0"\
> + "root=root=/dev/nfs rw\0" \
> + "set_bootargs=setenv bootargs $console"\
> + " $root ip=$ipaddr:$serverip:" \
> + "$gatewayip:$netmask:$hostname"\
> + ":$netdev:none nfsroot="\
> + "$serverip:$rootpath,tcp,v3 " \
> + "$extra_params " \
> + "$cpuidle"
This is hard to read, where is the variable name, where there is its
value, etc...
And it would be better to use distroboot instead of manually written
boot script.
Re: [PATCH v10 10/15] FWU: Add support for the FWU Multi Bank Update feature
hi Takahiro,
On Fri, 16 Sept 2022 at 12:20, Takahiro Akashi
wrote:
>
> On Fri, Sep 16, 2022 at 10:52:11AM +0530, Sughosh Ganu wrote:
> > () hi Takahiro,
> >
> > On Fri, 16 Sept 2022 at 07:17, Takahiro Akashi
> > wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Thu, Sep 15, 2022 at 01:44:46PM +0530, Sughosh Ganu wrote:
> > > > The FWU Multi Bank Update feature supports updation of firmware images
> > > > to one of multiple sets(also called banks) of images. The firmware
> > > > images are clubbed together in banks, with the system booting images
> > > > from the active bank. Information on the images such as which bank
> > > > they belong to is stored as part of the metadata structure, which is
> > > > stored on the same storage media as the firmware images on a dedicated
> > > > partition.
> > > >
> > > > At the time of update, the metadata is read to identify the bank to
> > > > which the images need to be flashed(update bank). On a successful
> > > > update, the metadata is modified to set the updated bank as active
> > > > bank to subsequently boot from.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V9:
> > > > * Move the global variables into local variables as suggested by
> > > > Ilias.
> > > > * Change fwu_get_image_alt_num() name to fwu_get_image_image_index()
> > >
> > > -> typo? fwu_get_image_index()?
> > >
> > > > as suggested by Takahiro.
> > > > * Allow capsule updates to be called from efi_init_obj_list() with the
> > > > FWU feature enabled, as suggested by Takahiro.
> > > > * Enable EFI_CAPSULE_ON_DISK_EARLY as an imply with the FWU feature
> > > > enabled.
> > > > * Define the FWU feature related functions as __maybe_unused to allow
> > > > for compilation with the FWU feature disabled.
> > > >
> > > > drivers/Kconfig | 2 +
> > > > drivers/Makefile | 1 +
> > > > include/fwu.h| 30 +
> > > > lib/Kconfig | 6 +
> > > > lib/Makefile | 1 +
> > > > lib/efi_loader/efi_capsule.c | 243 ++-
> > > > lib/fwu_updates/Kconfig | 33 +
> > > > lib/fwu_updates/Makefile | 7 +
> > > > lib/fwu_updates/fwu.c| 23
> > > > 9 files changed, 340 insertions(+), 6 deletions(-)
> > > > create mode 100644 lib/fwu_updates/Kconfig
> > > > create mode 100644 lib/fwu_updates/Makefile
> > > >
> > > >
> > > > /**
> > > > * efi_capsule_update_firmware - update firmware from capsule
> > > > @@ -410,7 +544,35 @@ static efi_status_t efi_capsule_update_firmware(
> > > > int item;
> > > > struct efi_firmware_management_protocol *fmp;
> > > > u16 *abort_reason;
> > > > + efi_guid_t image_type_id;
> > > > efi_status_t ret = EFI_SUCCESS;
> > > > + int status;
> > > > + u8 image_index;
> > > > + u32 update_index;
> > > > + bool fw_accept_os, image_index_check;
> > > > +
> > > > + if (IS_ENABLED(CONFIG_FWU_MULTI_BANK_UPDATE)) {
> > > > + if (!fwu_empty_capsule(capsule_data) &&
> > > > + !fwu_update_checks_pass()) {
> > > > + log_err("FWU checks failed. Cannot start
> > > > update\n");
> > > > + return EFI_INVALID_PARAMETER;
> > > > + }
> > > > +
> > > > + if (fwu_empty_capsule(capsule_data))
> > > > + return fwu_empty_capsule_process(capsule_data);
> > > > +
> > > > + /* Obtain the update_index from the platform */
> > > > + status = fwu_plat_get_update_index(_index);
> > > > + if (status < 0) {
> > > > + log_err("Failed to get the FWU update_index
> > > > value\n");
> > > > + return EFI_DEVICE_ERROR;
> > > > + }
> > > > +
> > > > + image_index_check = false;
> > > > + fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 :
> > > > 0x0;
> > > > + } else {
> > > > + image_index_check = true;
> > > > + }
> > > >
> > > > /* sanity check */
> > > > if (capsule_data->header_size < sizeof(*capsule) ||
> > > > @@ -455,7 +617,8 @@ static efi_status_t efi_capsule_update_firmware(
> > > > fmp = efi_fmp_find(>update_image_type_id,
> > > > image->update_image_index,
> > > > image->update_hardware_instance,
> > > > -handles, no_handles);
> > > > +handles, no_handles,
> > > > +image_index_check);
> > > > if (!fmp) {
> > > > log_err("FMP driver not found for firmware type
> > > > %pUs, hardware instance %lld\n",
> > > > >update_image_type_id,
> > > > @@ -485,8 +648,30 @@ static efi_status_t efi_capsule_update_firmware(
> > > > goto out;
> > > > }
> > > >
> > >
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
On Friday 16 September 2022 22:34:52 Chris Packham wrote:
> On Fri, 16 Sep 2022, 8:12 PM Pali Rohár, wrote:
>
> > Hello! I think it does not make sense to hack kwboot to skip validation
> > of kwbimage format when ad-hoc TIM header is detected. kwboot has now
> > lot of features which requires and expects valid kwbimage format and is
> > now written to work specially with 32-bit mvebu ARM BootROMs.
> >
> > TIM and kwbimage are totally different formats and it really does not
> > make sense to starting rewriting kwboot to support also other format.
> > Instead it would be better to write other dedicated tool for it.
> >
> > For example, there is already tool mox-imager [1], which despite its
> > name supports all A3720 BootROMS and mvebu64boot [2] which supports
> > A70x0, A80x0 and CN9130 BootROMS.
> >
> > [1] - https://gitlab.nic.cz/turris/mox-imager
> > [2] - https://github.com/pali/mvebu64boot
>
>
> Yeah I tend to agree.
>
> Mvebu64boot would fit better since this is a 64 bit Marveel SoC but again
> I'd have to teach it about TIM.
mox-imager already implements generating and parsing TIM images as this
is used on A3720. But for UART booting is used custom WTPTP protocol,
not variant of xmodem.
> One reason I went with kwboot (aside from
> not knowing anything else existed) was that the hand off between the uart
> boot sequence and the xmodem was awkward with the "official" methods (2
> different transfer with 2 different protocols).
>
> I do wonder if the boot seqence and xmodem stuff could be abstracted out to
> something that could be reused by other tools.
>
> I the short term at least I'll drop this out of the series.
>
>
> >
> > On Friday 16 September 2022 16:54:23 Chris Packham wrote:
> > > Marvell's proprietary TIM (trusted image) is used on the Armada-3700 and
> > > AlledCat5/5X (and possibly others). It has a whole host of features that
> > > work to implement a version of secure boot.
> > >
> > > Kwboot's interest in this format is simply to detect that the image is
> > > one of these and not attempt to patch it (the images will work over UART
> > > boot as-is). This is done by checking for a specific magic value
> > > ("TIMH") in the first 32bits of the image.
> > >
> > > Signed-off-by: Chris Packham
> > > ---
> > > It might be possible to make the check more robust by validating more of
> > > the image. There is a checksum field that might be useful for this
> > > purpose. I haven't done this as I couldn't figure out Marvell's
> > > validation of this field.
> > >
> > > tools/kwbimage.h | 29 +
> > > tools/kwboot.c | 3 +++
> > > 2 files changed, 32 insertions(+)
> > >
> > > diff --git a/tools/kwbimage.h b/tools/kwbimage.h
> > > index 505522332b..8aab26952a 100644
> > > --- a/tools/kwbimage.h
> > > +++ b/tools/kwbimage.h
> > > @@ -224,6 +224,28 @@ struct register_set_hdr_v1 {
> > > #define OPT_HDR_V1_BINARY_TYPE 0x2
> > > #define OPT_HDR_V1_REGISTER_TYPE 0x3
> > >
> > > +/* TIM (trusted image), Armada 3700, AlleyCat5 */
> > > +struct tim_block_hdr {
> > > + uint32_t signature_id;
> > > + uint16_t opcode;
> > > + uint16_t blocksize;
> > > +} __packed;
> > > +
> > > +struct tim_hdr {
> > > + struct tim_block_hdr hdr;
> > > + uint32_t trusted;
> > > + uint32_t signed_tim_size;
> > > + uint32_t unsigned_tim_size;
> > > + uint32_t unique_id;
> > > + uint64_t loadaddr;
> > > + uint32_t flags;
> > > + uint32_t software_prot_version;
> > > + uint32_t num_blocks;
> > > + uint32_t checksum;
> > > +} __packed;
> > > +
> > > +#define TIM_HDR_SIGNATURE0x54494d48 /* "TIMH" */
> > > +
> > > /*
> > > * Byte 8 of the image header contains the version number. In the v0
> > > * header, byte 8 was reserved, and always set to 0. In the v1 header,
> > > @@ -270,6 +292,13 @@ static inline size_t kwbheader_size_for_csum(const
> > void *header)
> > > return kwbheader_size(header);
> > > }
> > >
> > > +static inline bool kwbimage_is_tim(void *img)
> > > +{
> > > + const struct tim_hdr *hdr = img;
> > > +
> > > + return le32_to_cpu(hdr->hdr.signature_id) == TIM_HDR_SIGNATURE;
> > > +}
> > > +
> > > static inline struct ext_hdr_v0 *ext_hdr_v0_first(void *img)
> > > {
> > > struct main_hdr_v0 *mhdr;
> > > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > > index da4fe32da2..a9b3d0fd04 100644
> > > --- a/tools/kwboot.c
> > > +++ b/tools/kwboot.c
> > > @@ -1869,6 +1869,9 @@ kwboot_img_patch(void *img, size_t *size, int
> > baudrate)
> > > if (*size < sizeof(struct main_hdr_v1))
> > > goto err;
> > >
> > > + if (kwbimage_is_tim(img))
> > > + return 0;
> > > +
> > > image_ver = kwbimage_version(img);
> > > if (image_ver != 0 && image_ver != 1) {
> > > fprintf(stderr, "Invalid image header version\n");
> > > --
> > > 2.37.3
> > >
> >
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
On Fri, 16 Sep 2022, 8:12 PM Pali Rohár, wrote:
> Hello! I think it does not make sense to hack kwboot to skip validation
> of kwbimage format when ad-hoc TIM header is detected. kwboot has now
> lot of features which requires and expects valid kwbimage format and is
> now written to work specially with 32-bit mvebu ARM BootROMs.
>
> TIM and kwbimage are totally different formats and it really does not
> make sense to starting rewriting kwboot to support also other format.
> Instead it would be better to write other dedicated tool for it.
>
> For example, there is already tool mox-imager [1], which despite its
> name supports all A3720 BootROMS and mvebu64boot [2] which supports
> A70x0, A80x0 and CN9130 BootROMS.
>
> [1] - https://gitlab.nic.cz/turris/mox-imager
> [2] - https://github.com/pali/mvebu64boot
Yeah I tend to agree.
Mvebu64boot would fit better since this is a 64 bit Marveel SoC but again
I'd have to teach it about TIM. One reason I went with kwboot (aside from
not knowing anything else existed) was that the hand off between the uart
boot sequence and the xmodem was awkward with the "official" methods (2
different transfer with 2 different protocols).
I do wonder if the boot seqence and xmodem stuff could be abstracted out to
something that could be reused by other tools.
I the short term at least I'll drop this out of the series.
>
> On Friday 16 September 2022 16:54:23 Chris Packham wrote:
> > Marvell's proprietary TIM (trusted image) is used on the Armada-3700 and
> > AlledCat5/5X (and possibly others). It has a whole host of features that
> > work to implement a version of secure boot.
> >
> > Kwboot's interest in this format is simply to detect that the image is
> > one of these and not attempt to patch it (the images will work over UART
> > boot as-is). This is done by checking for a specific magic value
> > ("TIMH") in the first 32bits of the image.
> >
> > Signed-off-by: Chris Packham
> > ---
> > It might be possible to make the check more robust by validating more of
> > the image. There is a checksum field that might be useful for this
> > purpose. I haven't done this as I couldn't figure out Marvell's
> > validation of this field.
> >
> > tools/kwbimage.h | 29 +
> > tools/kwboot.c | 3 +++
> > 2 files changed, 32 insertions(+)
> >
> > diff --git a/tools/kwbimage.h b/tools/kwbimage.h
> > index 505522332b..8aab26952a 100644
> > --- a/tools/kwbimage.h
> > +++ b/tools/kwbimage.h
> > @@ -224,6 +224,28 @@ struct register_set_hdr_v1 {
> > #define OPT_HDR_V1_BINARY_TYPE 0x2
> > #define OPT_HDR_V1_REGISTER_TYPE 0x3
> >
> > +/* TIM (trusted image), Armada 3700, AlleyCat5 */
> > +struct tim_block_hdr {
> > + uint32_t signature_id;
> > + uint16_t opcode;
> > + uint16_t blocksize;
> > +} __packed;
> > +
> > +struct tim_hdr {
> > + struct tim_block_hdr hdr;
> > + uint32_t trusted;
> > + uint32_t signed_tim_size;
> > + uint32_t unsigned_tim_size;
> > + uint32_t unique_id;
> > + uint64_t loadaddr;
> > + uint32_t flags;
> > + uint32_t software_prot_version;
> > + uint32_t num_blocks;
> > + uint32_t checksum;
> > +} __packed;
> > +
> > +#define TIM_HDR_SIGNATURE0x54494d48 /* "TIMH" */
> > +
> > /*
> > * Byte 8 of the image header contains the version number. In the v0
> > * header, byte 8 was reserved, and always set to 0. In the v1 header,
> > @@ -270,6 +292,13 @@ static inline size_t kwbheader_size_for_csum(const
> void *header)
> > return kwbheader_size(header);
> > }
> >
> > +static inline bool kwbimage_is_tim(void *img)
> > +{
> > + const struct tim_hdr *hdr = img;
> > +
> > + return le32_to_cpu(hdr->hdr.signature_id) == TIM_HDR_SIGNATURE;
> > +}
> > +
> > static inline struct ext_hdr_v0 *ext_hdr_v0_first(void *img)
> > {
> > struct main_hdr_v0 *mhdr;
> > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > index da4fe32da2..a9b3d0fd04 100644
> > --- a/tools/kwboot.c
> > +++ b/tools/kwboot.c
> > @@ -1869,6 +1869,9 @@ kwboot_img_patch(void *img, size_t *size, int
> baudrate)
> > if (*size < sizeof(struct main_hdr_v1))
> > goto err;
> >
> > + if (kwbimage_is_tim(img))
> > + return 0;
> > +
> > image_ver = kwbimage_version(img);
> > if (image_ver != 0 && image_ver != 1) {
> > fprintf(stderr, "Invalid image header version\n");
> > --
> > 2.37.3
> >
>
[PATCH v3 5/5] arm: imx8mp: Initial MSC SM2S iMX8MP support
From: Martyn Welch
Add support for the MSC SM2S-IMX8PLUS SMARC Module. Tested in conjunction
with the MSC SM2-MB-EP1 Mini-ITX Carrier Board.
Signed-off-by: Martyn Welch
---
Changes in v2:
- Renamed FDT to closer match kernel
- Sync with kernel FDT
- Update for changes made in U-Boot
Changes in v3:
- Use imx8mp-u-boot.dtsi
- Switch to use of DM PMIC support in SPL
arch/arm/dts/Makefile |1 +
arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi | 65 +
arch/arm/dts/imx8mp-msc-sm2s.dts | 820
arch/arm/mach-imx/imx8m/Kconfig |8 +
board/msc/sm2s_imx8mp/Kconfig | 15 +
board/msc/sm2s_imx8mp/Makefile| 12 +
board/msc/sm2s_imx8mp/imximage-8mp-lpddr4.cfg |8 +
board/msc/sm2s_imx8mp/lpddr4_timing.c | 1842 +
board/msc/sm2s_imx8mp/sm2s_imx8mp.c | 60 +
board/msc/sm2s_imx8mp/spl.c | 273 +++
configs/msc_sm2s_imx8mp_defconfig | 91 +
include/configs/msc_sm2s_imx8mp.h | 96 +
12 files changed, 3291 insertions(+)
create mode 100644 arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mp-msc-sm2s.dts
create mode 100644 board/msc/sm2s_imx8mp/Kconfig
create mode 100644 board/msc/sm2s_imx8mp/Makefile
create mode 100644 board/msc/sm2s_imx8mp/imximage-8mp-lpddr4.cfg
create mode 100644 board/msc/sm2s_imx8mp/lpddr4_timing.c
create mode 100644 board/msc/sm2s_imx8mp/sm2s_imx8mp.c
create mode 100644 board/msc/sm2s_imx8mp/spl.c
create mode 100644 configs/msc_sm2s_imx8mp_defconfig
create mode 100644 include/configs/msc_sm2s_imx8mp.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 48cb1f52b7..233f4d1740 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -966,6 +966,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-phanbell.dtb \
imx8mp-dhcom-pdk2.dtb \
imx8mp-evk.dtb \
+ imx8mp-msc-sm2s.dtb \
imx8mp-phyboard-pollux-rdk.dtb \
imx8mp-venice.dtb \
imx8mp-venice-gw74xx.dtb \
diff --git a/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
b/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
new file mode 100644
index 00..cf591adf5a
--- /dev/null
+++ b/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+#include "
"
+
+/ {
+ model = "MSC SM2S-IMX8MPLUS";
+ compatible = "avnet,sm2s-imx8mp", "fsl,imx8mp";
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ u-boot,dm-spl;
+ };
+};
+
+_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_i2c6 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mp-msc-sm2s.dts b/arch/arm/dts/imx8mp-msc-sm2s.dts
new file mode 100644
index 00..5dbec71747
--- /dev/null
+++ b/arch/arm/dts/imx8mp-msc-sm2s.dts
@@ -0,0 +1,820 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Avnet Embedded GmbH
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+#include
+
+/ {
+ aliases {
+ rtc0 = _rtc;
+ rtc1 = _rtc;
+ };
+
+ chosen {
+ stdout-path =
+ };
+
+ reg_usb0_host_vbus: regulator-usb0-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb0_host_vbus";
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb0_vbus>;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb1_host_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1_host_vbus";
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb1_vbus>;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+
+ reg_flexcan1_xceiver: regulator-flexcan1 {
+
[PATCH v3 2/5] ARM: imx: imx8mp: Enable support for i2c5 and i2c6 on i.MX8MP
From: Martyn Welch
The i.MX8MP SoC contains 2 more i2c buses. Add support for the
configuration of these buses.
Signed-off-by: Martyn Welch
---
Changes in v2:
- None
Changes in v3:
- None
arch/arm/include/asm/arch-imx8m/imx-regs.h | 4
arch/arm/mach-imx/i2c-mxv7.c | 6 ++
arch/arm/mach-imx/imx8m/clock_imx8mm.c | 12 +---
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index d8952342e0..9d3d959cbc 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -43,6 +43,10 @@
#define I2C3_BASE_ADDR 0x30A4
#define I2C4_BASE_ADDR 0x30A5
#define UART4_BASE_ADDR0x30A6
+#ifdef CONFIG_IMX8MP
+#define I2C5_BASE_ADDR 0x30AD
+#define I2C6_BASE_ADDR 0x30AE
+#endif
#define USDHC1_BASE_ADDR 0x30B4
#define USDHC2_BASE_ADDR 0x30B5
#define QSPI0_AMBA_BASE 0x0800
diff --git a/arch/arm/mach-imx/i2c-mxv7.c b/arch/arm/mach-imx/i2c-mxv7.c
index d36347d8e8..d3b4f6c9a8 100644
--- a/arch/arm/mach-imx/i2c-mxv7.c
+++ b/arch/arm/mach-imx/i2c-mxv7.c
@@ -70,6 +70,12 @@ static void * const i2c_bases[] = {
#ifdef I2C4_BASE_ADDR
(void *)I2C4_BASE_ADDR,
#endif
+#ifdef I2C5_BASE_ADDR
+ (void *)I2C5_BASE_ADDR,
+#endif
+#ifdef I2C6_BASE_ADDR
+ (void *)I2C6_BASE_ADDR,
+#endif
};
/* i2c_index can be from 0 - 3 */
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
index 4db55f8608..64ad57e9b3 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
@@ -36,11 +36,17 @@ void enable_ocotp_clk(unsigned char enable)
int enable_i2c_clk(unsigned char enable, unsigned i2c_num)
{
- /* 0 - 3 is valid i2c num */
- if (i2c_num > 3)
+ u8 i2c_ccgr[6] = {
+ CCGR_I2C1, CCGR_I2C2, CCGR_I2C3, CCGR_I2C4,
+#if (IS_ENABLED(CONFIG_IMX8MP))
+ CCGR_I2C5_8MP, CCGR_I2C6_8MP
+#endif
+ };
+
+ if (i2c_num > ARRAY_SIZE(i2c_ccgr))
return -EINVAL;
- clock_enable(CCGR_I2C1 + i2c_num, !!enable);
+ clock_enable(i2c_ccgr[i2c_num], !!enable);
return 0;
}
--
2.35.1
[PATCH v3 3/5] drivers: power: pmic: Add support for rn5t568 PMIC
From: Martyn Welch
Add support for the rn5t568 PMIC to the rn5t567 driver.
Signed-off-by: Martyn Welch
---
Changes in v2:
- None
Changes in v3:
- None
drivers/power/pmic/rn5t567.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/pmic/rn5t567.c b/drivers/power/pmic/rn5t567.c
index d9a8298ebb..9d103dd840 100644
--- a/drivers/power/pmic/rn5t567.c
+++ b/drivers/power/pmic/rn5t567.c
@@ -53,6 +53,7 @@ static struct dm_pmic_ops rn5t567_ops = {
static const struct udevice_id rn5t567_ids[] = {
{ .compatible = "ricoh,rn5t567" },
+ { .compatible = "ricoh,rn5t568" },
{ }
};
--
2.35.1
[PATCH v3 4/5] drivers: power: pmic: Enable use of rn5t567 PMIC in SPL
The support added later in this series tweaks the PMIC voltages in the SPL. Enable support for the rn5t567 in SPL builds to allow this to be done cleanly. Signed-off-by: Martyn Welch --- Changes in v3: - New patch (replaces addition of legacy support for rn5t567) drivers/power/pmic/Kconfig | 8 drivers/power/pmic/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig index 66b16b06e0..8e10ecae2e 100644 --- a/drivers/power/pmic/Kconfig +++ b/drivers/power/pmic/Kconfig @@ -300,6 +300,14 @@ config PMIC_RN5T567 regulators Real-Time Clock and 4 GPIOs. This driver provides register access only. +config SPL_PMIC_RN5T567 + bool "Enable driver for Ricoh RN5T567 PMIC in SPL" + depends on SPL_DM_PMIC + ---help--- + The RN5T567 is a PMIC with 4 step-down DC/DC converters, 5 LDO + regulators Real-Time Clock and 4 GPIOs. This driver provides + register access only. + config PMIC_TPS65090 bool "Enable driver for Texas Instruments TPS65090 PMIC" ---help--- diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile index f73b326255..ae34e6b33e 100644 --- a/drivers/power/pmic/Makefile +++ b/drivers/power/pmic/Makefile @@ -22,7 +22,7 @@ obj-$(CONFIG_$(SPL_)PMIC_AXP) += axp.o obj-$(CONFIG_PMIC_MAX8997) += max8997.o obj-$(CONFIG_PMIC_PM8916) += pm8916.o obj-$(CONFIG_$(SPL_TPL_)PMIC_RK8XX) += rk8xx.o -obj-$(CONFIG_PMIC_RN5T567) += rn5t567.o +obj-$(CONFIG_$(SPL_)PMIC_RN5T567) += rn5t567.o obj-$(CONFIG_PMIC_TPS65090) += tps65090.o obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o obj-$(CONFIG_DM_PMIC_TPS65910) += pmic_tps65910_dm.o -- 2.35.1
[PATCH v3 1/5] imx8m: USDHC3 base address definition for i.MX8MP
From: Martyn Welch The i.MX8MP also has USDHC3, allow access to the relvant base address definition. Signed-off-by: Martyn Welch --- Changes in v2: - None Changes in v3: - None arch/arm/include/asm/arch-imx8m/imx-regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 6969cde26c..d8952342e0 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -46,7 +46,7 @@ #define USDHC1_BASE_ADDR 0x30B4 #define USDHC2_BASE_ADDR 0x30B5 #define QSPI0_AMBA_BASE 0x0800 -#ifdef CONFIG_IMX8MM +#if defined(CONFIG_IMX8MM) || defined(CONFIG_IMX8MP) #define USDHC3_BASE_ADDR 0x30B6 #endif #define UART_BASE_ADDR(n) ( \ -- 2.35.1
Re: [PATCH] nvmem: u-boot-env: find Device Tree nodes for NVMEM cells
On 15/09/2022 21:06, Rafał Miłecki wrote: From: Rafał Miłecki DT binding allows specifying NVMEM cells as NVMEM device (provider) subnodes. Looks for such subnodes when building NVMEM cells. This allows NVMEM consumers to use U-Boot environment variables. Signed-off-by: Rafał Miłecki Applied thanks, --srini --- drivers/nvmem/u-boot-env.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c index 9b9abfb8f187..d17a164ae705 100644 --- a/drivers/nvmem/u-boot-env.c +++ b/drivers/nvmem/u-boot-env.c @@ -92,6 +92,7 @@ static int u_boot_env_add_cells(struct u_boot_env *priv, uint8_t *buf, return -ENOMEM; priv->cells[idx].offset = data_offset + value - data; priv->cells[idx].bytes = strlen(value); + priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name); } if (WARN_ON(idx != priv->ncells))
Re: [PATCH v2 0/3] Add riscv semihosting support in u-boot
That is strange because I'm not aware of the fact that I'm riscv maintainer. On Friday 16 September 2022 14:40:46 Kautuk Consul wrote: > Sorry about that! > I ran get_maintainer.pl on my patchset and got your name > along with several others so I also sent to you. > > On Fri, Sep 16, 2022 at 2:38 PM Pali Rohár wrote: > > > > Hello! I'm not riscv maintainer and therefore I'm not going to review > > this patch series. Please do not spam me with unrelated emails and > > patches as I would loose track of patches and emails which are import > > and which I should review. Thanks. > > > > On Friday 16 September 2022 13:42:30 Kautuk Consul wrote: > > > Semihosting is a mechanism that enables code running on > > > a target to communicate and use the Input/Output > > > facilities on a host computer that is running a debugger. > > > This patchset adds support for semihosting in u-boot > > > for RISCV64 targets. > > > > > > CHANGES since v1: > > > - Moved the identical smh_* and semihosting_enabled/disable_semihosting > > > code of ARM and RISC-V to lib/semihosting.c > > > - Extend the handle_trap() functionality to call disable_semihosting() > > > if the cause is a breakpoint (i.e. ebreak instruction) > > > - Change our implementation of semihosting_enabled to be exactly the > > > same as the way ARM implemented it > > > - Additionally enable the CONFIG_SPL_FS_EXT4 and CONFIG_SPL_FS_FAT > > > configs for qemu defconfigs so that CONFIG_SPL_FS_LOAD_PAYLOAD_NAME > > > gets automatically enabled instead of us #defining it in > > > include/configs/qemu-riscv.h > > > > > > Compilation and test commands for SPL and S-mode configurations > > > = > > > > > > U-Boot S-mode on QEMU virt > > > > > > // Compilation of S-mode u-boot > > > ARCH=riscv > > > CROSS_COMPILE=riscv64-unknown-linux-gnu- > > > make qemu-riscv64_smode_defconfig > > > make > > > // Run riscv 64-bit u-boot with opensbi on qemu > > > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > > > opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ > > > u-boot/u-boot.bin > > > > > > U-Boot SPL on QEMU virt > > > > > > // Compilation of u-boot-spl > > > ARCH=riscv > > > CROSS_COMPILE=riscv64-unknown-linux-gnu- > > > make qemu-riscv64_spl_defconfig > > > make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin > > > // Run 64-bit u-boot-spl in qemu > > > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > > > u-boot/spl/u-boot-spl.bin -device\ > > > loader,file=u-boot/u-boot.itb,addr=0x8020 > > > > > > Kautuk Consul (3): > > > lib: Add common semihosting library > > > arch/riscv: add semihosting support for RISC-V > > > board: qemu-riscv: enable semihosting > > > > > > arch/arm/Kconfig | 2 + > > > arch/arm/lib/semihosting.c | 179 +- > > > arch/riscv/Kconfig | 47 +++ > > > arch/riscv/include/asm/semihosting.h | 11 ++ > > > arch/riscv/include/asm/spl.h | 1 + > > > arch/riscv/lib/Makefile | 2 + > > > arch/riscv/lib/interrupts.c | 11 ++ > > > arch/riscv/lib/semihosting.c | 24 > > > configs/qemu-riscv32_defconfig | 4 + > > > configs/qemu-riscv32_smode_defconfig | 4 + > > > configs/qemu-riscv32_spl_defconfig | 7 + > > > configs/qemu-riscv64_defconfig | 4 + > > > configs/qemu-riscv64_smode_defconfig | 4 + > > > configs/qemu-riscv64_spl_defconfig | 7 + > > > include/semihosting.h| 11 ++ > > > lib/Kconfig | 3 + > > > lib/Makefile | 2 + > > > lib/semihosting.c| 186 +++ > > > 18 files changed, 331 insertions(+), 178 deletions(-) > > > create mode 100644 arch/riscv/include/asm/semihosting.h > > > create mode 100644 arch/riscv/lib/semihosting.c > > > create mode 100644 lib/semihosting.c > > > > > > -- > > > 2.34.1 > > >
Re: [PATCH v2 0/3] Add riscv semihosting support in u-boot
Hello! I'm not riscv maintainer and therefore I'm not going to review this patch series. Please do not spam me with unrelated emails and patches as I would loose track of patches and emails which are import and which I should review. Thanks. On Friday 16 September 2022 13:42:30 Kautuk Consul wrote: > Semihosting is a mechanism that enables code running on > a target to communicate and use the Input/Output > facilities on a host computer that is running a debugger. > This patchset adds support for semihosting in u-boot > for RISCV64 targets. > > CHANGES since v1: > - Moved the identical smh_* and semihosting_enabled/disable_semihosting > code of ARM and RISC-V to lib/semihosting.c > - Extend the handle_trap() functionality to call disable_semihosting() > if the cause is a breakpoint (i.e. ebreak instruction) > - Change our implementation of semihosting_enabled to be exactly the > same as the way ARM implemented it > - Additionally enable the CONFIG_SPL_FS_EXT4 and CONFIG_SPL_FS_FAT > configs for qemu defconfigs so that CONFIG_SPL_FS_LOAD_PAYLOAD_NAME > gets automatically enabled instead of us #defining it in > include/configs/qemu-riscv.h > > Compilation and test commands for SPL and S-mode configurations > = > > U-Boot S-mode on QEMU virt > > // Compilation of S-mode u-boot > ARCH=riscv > CROSS_COMPILE=riscv64-unknown-linux-gnu- > make qemu-riscv64_smode_defconfig > make > // Run riscv 64-bit u-boot with opensbi on qemu > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > opensbi/build/platform/generic/firmware/fw_jump.bin -kernel\ > u-boot/u-boot.bin > > U-Boot SPL on QEMU virt > > // Compilation of u-boot-spl > ARCH=riscv > CROSS_COMPILE=riscv64-unknown-linux-gnu- > make qemu-riscv64_spl_defconfig > make OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin > // Run 64-bit u-boot-spl in qemu > qemu-system-riscv64 -M virt -m 256M -display none -serial stdio -bios\ > u-boot/spl/u-boot-spl.bin -device\ > loader,file=u-boot/u-boot.itb,addr=0x8020 > > Kautuk Consul (3): > lib: Add common semihosting library > arch/riscv: add semihosting support for RISC-V > board: qemu-riscv: enable semihosting > > arch/arm/Kconfig | 2 + > arch/arm/lib/semihosting.c | 179 +- > arch/riscv/Kconfig | 47 +++ > arch/riscv/include/asm/semihosting.h | 11 ++ > arch/riscv/include/asm/spl.h | 1 + > arch/riscv/lib/Makefile | 2 + > arch/riscv/lib/interrupts.c | 11 ++ > arch/riscv/lib/semihosting.c | 24 > configs/qemu-riscv32_defconfig | 4 + > configs/qemu-riscv32_smode_defconfig | 4 + > configs/qemu-riscv32_spl_defconfig | 7 + > configs/qemu-riscv64_defconfig | 4 + > configs/qemu-riscv64_smode_defconfig | 4 + > configs/qemu-riscv64_spl_defconfig | 7 + > include/semihosting.h| 11 ++ > lib/Kconfig | 3 + > lib/Makefile | 2 + > lib/semihosting.c| 186 +++ > 18 files changed, 331 insertions(+), 178 deletions(-) > create mode 100644 arch/riscv/include/asm/semihosting.h > create mode 100644 arch/riscv/lib/semihosting.c > create mode 100644 lib/semihosting.c > > -- > 2.34.1 >
Re: [PATCH 0/9] xilinx: versal-net: Add support for new Versal NET SoC
Hello! I'm not maintainer of xilinx and I'm getting tons of emails. So please do not send and spam me with unrelated emails/patches as I would not have time to process those emails/patches which are important and which I should review. Thanks. On Friday 16 September 2022 10:53:11 Michal Simek wrote: > Hi, > > I am sending support for new Xilinx/AMD SoC called Versal NET. > Versal NET is very similar to origin Versal SOC. There is different > register layout, some IPs have been upgraded like i3c and some other > changes in different location. > > Thanks, > Michal > > > Jay Buddhabhatti (4): > clk: versal: Enable clock driver for Versal NET > firmware: zynqmp: Add Versal NET compatible string > mailbox: zynqmp: Enable ipi mailbox driver for Versal NET > reset: zynqmp: Enable reset driver for Versal NET > > Michal Simek (5): > arm64: versal-net: Add support for Versal NET platform > spi: cadence_qspi: Add support for Versal NET platform > spi: zynqmp_gqspi: Add support for Versal NET > arm64: versal-net: Add defconfig for Versal NET > arm64: versal-net: Add support for mini configuration > > Kconfig | 2 +- > MAINTAINERS | 7 + > arch/arm/Kconfig | 14 ++ > arch/arm/Makefile | 1 + > arch/arm/dts/Makefile | 3 + > arch/arm/dts/versal-net-mini.dts | 67 +++ > arch/arm/dts/xilinx-versal-net-virt.dts | 11 ++ > arch/arm/mach-versal-net/Kconfig | 43 + > arch/arm/mach-versal-net/Makefile | 10 ++ > arch/arm/mach-versal-net/clk.c| 35 > arch/arm/mach-versal-net/cpu.c| 89 + > .../mach-versal-net/include/mach/hardware.h | 31 > .../mach-versal-net/include/mach/sys_proto.h | 16 ++ > board/xilinx/Kconfig | 6 +- > board/xilinx/versal-net/Kconfig | 9 + > board/xilinx/versal-net/MAINTAINERS | 8 + > board/xilinx/versal-net/Makefile | 9 + > board/xilinx/versal-net/board.c | 170 ++ > configs/xilinx_versal_net_mini_defconfig | 70 > configs/xilinx_versal_net_virt_defconfig | 118 > drivers/clk/Kconfig | 2 +- > drivers/clk/clk_versal.c | 1 + > drivers/firmware/firmware-zynqmp.c| 1 + > drivers/mailbox/Kconfig | 2 +- > drivers/reset/reset-zynqmp.c | 1 + > drivers/spi/Kconfig | 2 +- > drivers/spi/cadence_ospi_versal.c | 3 +- > drivers/spi/zynqmp_gqspi.c| 3 +- > env/Kconfig | 6 +- > include/configs/xilinx_versal_net.h | 156 > include/configs/xilinx_versal_net_mini.h | 28 +++ > 31 files changed, 912 insertions(+), 12 deletions(-) > create mode 100644 arch/arm/dts/versal-net-mini.dts > create mode 100644 arch/arm/dts/xilinx-versal-net-virt.dts > create mode 100644 arch/arm/mach-versal-net/Kconfig > create mode 100644 arch/arm/mach-versal-net/Makefile > create mode 100644 arch/arm/mach-versal-net/clk.c > create mode 100644 arch/arm/mach-versal-net/cpu.c > create mode 100644 arch/arm/mach-versal-net/include/mach/hardware.h > create mode 100644 arch/arm/mach-versal-net/include/mach/sys_proto.h > create mode 100644 board/xilinx/versal-net/Kconfig > create mode 100644 board/xilinx/versal-net/MAINTAINERS > create mode 100644 board/xilinx/versal-net/Makefile > create mode 100644 board/xilinx/versal-net/board.c > create mode 100644 configs/xilinx_versal_net_mini_defconfig > create mode 100644 configs/xilinx_versal_net_virt_defconfig > create mode 100644 include/configs/xilinx_versal_net.h > create mode 100644 include/configs/xilinx_versal_net_mini.h > > -- > 2.36.1 >
[PATCH 9/9] arm64: versal-net: Add support for mini configuration
Versal NET mini configuration is designed for running memory test. Current
output is on DCC but changing serial0 alias to pl011 will move console to
serial port.
Signed-off-by: Michal Simek
---
arch/arm/dts/Makefile| 1 +
arch/arm/dts/versal-net-mini.dts | 67 +++
configs/xilinx_versal_net_mini_defconfig | 70
include/configs/xilinx_versal_net_mini.h | 28 ++
4 files changed, 166 insertions(+)
create mode 100644 arch/arm/dts/versal-net-mini.dts
create mode 100644 configs/xilinx_versal_net_mini_defconfig
create mode 100644 include/configs/xilinx_versal_net_mini.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a141d0de0c20..4ad526d565c9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -380,6 +380,7 @@ dtb-$(CONFIG_ARCH_VERSAL) += \
versal-mini-emmc1.dtb \
xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_VERSAL_NET) += \
+ versal-net-mini.dtb \
xilinx-versal-net-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
zynqmp-r5.dtb
diff --git a/arch/arm/dts/versal-net-mini.dts b/arch/arm/dts/versal-net-mini.dts
new file mode 100644
index ..8c29a6ed6bfe
--- /dev/null
+++ b/arch/arm/dts/versal-net-mini.dts
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx Versal NET
+ *
+ * Copyright (C) 2021 - 2022, Xilinx, Inc.
+ * Copyright (C) 2022, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ */
+
+/dts-v1/;
+
+#include
+
+/ {
+ compatible = "xlnx,versal-net-mini";
+ model = "Xilinx Versal NET MINI";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ memory: memory@0 {
+ reg = <0 0xBBF0 0 0x10>, <0 0 0 0x8000>;
+ device_type = "memory";
+ };
+
+ aliases {
+ /* serial0 = */
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200";
+ };
+
+ clk1: clk1 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100>;
+ };
+
+ dcc: dcc {
+ compatible = "arm,dcc";
+ status = "okay";
+ u-boot,dm-pre-reloc;
+ };
+
+ amba: axi {
+ compatible = "simple-bus";
+ u-boot,dm-pre-reloc;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ serial0: serial@f192 {
+ u-boot,dm-pre-reloc;
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0 0xf192 0 0x1000>;
+ reg-io-width = <4>;
+ clock-names = "uartclk", "apb_pclk";
+ clocks = <>, <>;
+ clock = <100>;
+ current-speed = <115200>;
+ skip-init;
+ };
+ };
+};
diff --git a/configs/xilinx_versal_net_mini_defconfig
b/configs/xilinx_versal_net_mini_defconfig
new file mode 100644
index ..eff560dfdf88
--- /dev/null
+++ b/configs/xilinx_versal_net_mini_defconfig
@@ -0,0 +1,70 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_net_mini"
+CONFIG_SYS_ICACHE_OFF=y
+# CONFIG_ARM64_CRC32 is not set
+# CONFIG_ARM64_SUPPORT_AARCH32 is not set
+CONFIG_ARCH_VERSAL_NET=y
+CONFIG_SYS_TEXT_BASE=0xBBF1
+CONFIG_SYS_MALLOC_LEN=0x2
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_NR_DRAM_BANKS=3
+CONFIG_ENV_SIZE=0x80
+CONFIG_DEFAULT_DEVICE_TREE="versal-net-mini"
+CONFIG_SYS_PROMPT="Versal NET> "
+CONFIG_SYS_MEM_RSVD_FOR_MMU=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_SYS_LOAD_ADDR=0x800
+CONFIG_SYS_MEMTEST_START=0x
+CONFIG_SYS_MEMTEST_END=0x1000
+# CONFIG_EXPERT is not set
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
+# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+# CONFIG_AUTOBOOT is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_BOARD_EARLY_INIT_R=y
+# CONFIG_BOARD_LATE_INIT is not set
+# CONFIG_CMDLINE_EDITING is not set
+# CONFIG_AUTO_COMPLETE is not set
+# CONFIG_SYS_LONGHELP is not set
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_BOOTI is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_FDT is not set
+# CONFIG_CMD_GO is not set
+# CONFIG_CMD_RUN is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+# CONFIG_CMD_CRC32 is not set
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MX_CYCLIC=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_SYS_ALT_MEMTEST=y
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_ECHO is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SOURCE is not set
+#
[PATCH 8/9] arm64: versal-net: Add defconfig for Versal NET
Use one defconfig for supporting multiple different platforms. DTB reselection is enabled to choose DT based on SOC detection. Signed-off-by: Michal Simek --- configs/xilinx_versal_net_virt_defconfig | 118 +++ 1 file changed, 118 insertions(+) create mode 100644 configs/xilinx_versal_net_virt_defconfig diff --git a/configs/xilinx_versal_net_virt_defconfig b/configs/xilinx_versal_net_virt_defconfig new file mode 100644 index ..b918b2f128b0 --- /dev/null +++ b/configs/xilinx_versal_net_virt_defconfig @@ -0,0 +1,118 @@ +CONFIG_ARM=y +CONFIG_POSITION_INDEPENDENT=y +CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864 +CONFIG_ARCH_VERSAL_NET=y +CONFIG_SYS_TEXT_BASE=0x800 +CONFIG_SYS_MALLOC_F_LEN=0x10 +CONFIG_DEFAULT_DEVICE_TREE="xilinx-versal-net-virt" +CONFIG_SYS_PROMPT="Versal NET> " +CONFIG_CMD_FRU=y +CONFIG_SYS_LOAD_ADDR=0x800 +CONFIG_SYS_MEMTEST_START=0x +CONFIG_SYS_MEMTEST_END=0x1000 +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set +CONFIG_BOOTDELAY=5 +CONFIG_USE_PREBOOT=y +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_CMD_BOOTMENU=y +CONFIG_CMD_NVEDIT_EFI=y +CONFIG_CMD_MEMTEST=y +CONFIG_SYS_ALT_MEMTEST=y +CONFIG_CMD_CLK=y +CONFIG_CMD_DFU=y +CONFIG_CMD_DM=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_MTD=y +CONFIG_CMD_SF_TEST=y +CONFIG_CMD_USB=y +CONFIG_CMD_TFTPPUT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_EFIDEBUG=y +CONFIG_CMD_TIME=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +CONFIG_PARTITION_TYPE_GUID=y +CONFIG_OF_BOARD=y +CONFIG_DTB_RESELECT=y +CONFIG_MULTI_DTB_FIT=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_NETCONSOLE=y +CONFIG_IP_DEFRAG=y +CONFIG_TFTP_BLOCKSIZE=4096 +CONFIG_CLK_VERSAL=y +CONFIG_DFU_RAM=y +CONFIG_ZYNQ_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_CADENCE=y +CONFIG_DM_MAILBOX=y +CONFIG_ZYNQMP_IPI=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x0 +CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_ZYNQ=y +CONFIG_ZYNQ_SDHCI_MIN_FREQ=10 +CONFIG_MTD=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_ISSI=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y +CONFIG_SPI_FLASH_WINBOND=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_SPI_FLASH_MTD=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI_DP83867=y +CONFIG_PHY_VITESSE=y +CONFIG_PHY_FIXED=y +CONFIG_PHY_GIGE=y +CONFIG_XILINX_AXIEMAC=y +CONFIG_ZYNQ_GEM=y +CONFIG_POWER_DOMAIN=y +CONFIG_ZYNQMP_POWER_DOMAIN=y +CONFIG_DM_RESET=y +CONFIG_RESET_ZYNQMP=y +CONFIG_ARM_DCC=y +CONFIG_PL01X_SERIAL=y +CONFIG_XILINX_UARTLITE=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_CADENCE_QSPI=y +CONFIG_CADENCE_OSPI_VERSAL=y +CONFIG_ZYNQ_SPI=y +CONFIG_ZYNQMP_GQSPI=y +CONFIG_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_ULPI_VIEWPORT=y +CONFIG_USB_ULPI=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="Xilinx" +CONFIG_USB_GADGET_VENDOR_NUM=0x03FD +CONFIG_USB_GADGET_PRODUCT_NUM=0x0300 +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_FUNCTION_THOR=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.36.1
[PATCH 7/9] reset: zynqmp: Enable reset driver for Versal NET
From: Jay Buddhabhatti
Enable zynqmp reset driver for Versal NET.
Signed-off-by: Jay Buddhabhatti
Signed-off-by: Michal Simek
---
drivers/reset/reset-zynqmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
index 52c08c4722da..87b4df5bf81a 100644
--- a/drivers/reset/reset-zynqmp.c
+++ b/drivers/reset/reset-zynqmp.c
@@ -80,6 +80,7 @@ const struct reset_ops zynqmp_reset_ops = {
static const struct udevice_id zynqmp_reset_ids[] = {
{ .compatible = "xlnx,zynqmp-reset" },
{ .compatible = "xlnx,versal-reset" },
+ { .compatible = "xlnx,versal-net-reset" },
{ }
};
--
2.36.1
[PATCH 6/9] mailbox: zynqmp: Enable ipi mailbox driver for Versal NET
From: Jay Buddhabhatti Enable mailbox configs for Versal NET. Signed-off-by: Jay Buddhabhatti Signed-off-by: Michal Simek --- drivers/mailbox/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index acbdce11b7c7..47f24e0a02e0 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -54,7 +54,7 @@ config K3_SEC_PROXY config ZYNQMP_IPI bool "Xilinx ZynqMP IPI controller support" - depends on DM_MAILBOX && (ARCH_ZYNQMP || ARCH_VERSAL) + depends on DM_MAILBOX && (ARCH_ZYNQMP || ARCH_VERSAL || ARCH_VERSAL_NET) help This enables support for the Xilinx ZynqMP Inter Processor Interrupt communication controller. -- 2.36.1
[PATCH 5/9] firmware: zynqmp: Add Versal NET compatible string
From: Jay Buddhabhatti
Add compatible string for Versal NET.
Signed-off-by: Jay Buddhabhatti
Signed-off-by: Michal Simek
---
drivers/firmware/firmware-zynqmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 76ddc6b4f404..d8e0d79c5744 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -370,6 +370,7 @@ int __maybe_unused xilinx_pm_request(u32 api_id, u32 arg0,
u32 arg1, u32 arg2,
static const struct udevice_id zynqmp_firmware_ids[] = {
{ .compatible = "xlnx,zynqmp-firmware" },
{ .compatible = "xlnx,versal-firmware"},
+ { .compatible = "xlnx,versal-net-firmware"},
{ }
};
--
2.36.1
[PATCH 4/9] clk: versal: Enable clock driver for Versal NET
From: Jay Buddhabhatti
Add support for Versal NET compatible string in clock driver.
Signed-off-by: Jay Buddhabhatti
Signed-off-by: Michal Simek
---
drivers/clk/Kconfig | 2 +-
drivers/clk/clk_versal.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index fd9e1a80c6aa..09aa97ee8c0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -184,7 +184,7 @@ config CLK_VERSACLOCK
config CLK_VERSAL
bool "Enable clock driver support for Versal"
- depends on ARCH_VERSAL
+ depends on (ARCH_VERSAL || ARCH_VERSAL_NET)
select ZYNQMP_FIRMWARE
help
This clock driver adds support for clock realted settings for
diff --git a/drivers/clk/clk_versal.c b/drivers/clk/clk_versal.c
index a9dd57b098fe..b2f62061cea2 100644
--- a/drivers/clk/clk_versal.c
+++ b/drivers/clk/clk_versal.c
@@ -739,6 +739,7 @@ static struct clk_ops versal_clk_ops = {
static const struct udevice_id versal_clk_ids[] = {
{ .compatible = "xlnx,versal-clk" },
+ { .compatible = "xlnx,versal-net-clk" },
{ }
};
--
2.36.1
[PATCH 3/9] spi: zynqmp_gqspi: Add support for Versal NET
Add support for Versal NET platform.
Signed-off-by: Michal Simek
---
drivers/spi/zynqmp_gqspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index 4e718c545c64..d3cc8554b8fb 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -308,7 +308,8 @@ void zynqmp_qspi_set_tapdelay(struct udevice *bus, u32
baudrateval)
debug("%s, req_hz:%d, clk_rate:%d, baudrateval:%d\n",
__func__, reqhz, clk_rate, baudrateval);
- if (!IS_ENABLED(CONFIG_ARCH_VERSAL)) {
+ if (!(IS_ENABLED(CONFIG_ARCH_VERSAL) ||
+ IS_ENABLED(CONFIG_ARCH_VERSAL_NET))) {
if (reqhz <= GQSPI_FREQ_40MHZ) {
tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
--
2.36.1
[PATCH 2/9] spi: cadence_qspi: Add support for Versal NET platform
Trivial changes to support cadence ospi driver for Versal NET platform.
Also avoid ospi flash reset for now.
Signed-off-by: Michal Simek
---
arch/arm/mach-versal-net/include/mach/hardware.h | 4
drivers/spi/Kconfig | 2 +-
drivers/spi/cadence_ospi_versal.c| 3 ++-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 2eb549849825..808ce48fd148 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -25,3 +25,7 @@ enum versal_net_platform {
VERSAL_NET_EMU = 2,
VERSAL_NET_QEMU = 3,
};
+
+#define VERSAL_SLCR_BASEADDR 0xF106
+#define VERSAL_AXI_MUX_SEL (VERSAL_SLCR_BASEADDR + 0x504)
+#define VERSAL_OSPI_LINEAR_MODEBIT(1)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ac91d8225821..240ff212a39f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -148,7 +148,7 @@ config CQSPI_REF_CLK
config CADENCE_OSPI_VERSAL
bool "Configure Versal OSPI"
- depends on ARCH_VERSAL && CADENCE_QSPI
+ depends on (ARCH_VERSAL || ARCH_VERSAL_NET) && CADENCE_QSPI
imply DM_GPIO
help
This option is used to enable Versal OSPI DMA operations which
diff --git a/drivers/spi/cadence_ospi_versal.c
b/drivers/spi/cadence_ospi_versal.c
index a25c50bc5081..a9547a820031 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -130,6 +130,7 @@ int cadence_qspi_apb_wait_for_dma_cmplt(struct
cadence_spi_priv *priv)
#if defined(CONFIG_DM_GPIO)
int cadence_qspi_versal_flash_reset(struct udevice *dev)
{
+#ifndef CONFIG_ARCH_VERSAL_NET
struct gpio_desc gpio;
u32 reset_gpio;
int ret;
@@ -165,7 +166,7 @@ int cadence_qspi_versal_flash_reset(struct udevice *dev)
/* Set value 1 to pin */
dm_gpio_set_value(, 1);
udelay(1);
-
+#endif
return 0;
}
#else
--
2.36.1
[PATCH 1/9] arm64: versal-net: Add support for Versal NET platform
Versal NET platform is based on Versal chip which is reusing a lot of IPs. For more information about new IPs please take a look at DT which describe currently supported devices. The patch is adding architecture and board support with soc detection algorithm. Generic setting should be very similar to Versal but it will likely diverge in longer run. Signed-off-by: Michal Simek --- Kconfig | 2 +- MAINTAINERS | 7 + arch/arm/Kconfig | 14 ++ arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/xilinx-versal-net-virt.dts | 11 ++ arch/arm/mach-versal-net/Kconfig | 43 + arch/arm/mach-versal-net/Makefile | 10 ++ arch/arm/mach-versal-net/clk.c| 35 arch/arm/mach-versal-net/cpu.c| 89 + .../mach-versal-net/include/mach/hardware.h | 27 +++ .../mach-versal-net/include/mach/sys_proto.h | 16 ++ board/xilinx/Kconfig | 6 +- board/xilinx/versal-net/Kconfig | 9 + board/xilinx/versal-net/MAINTAINERS | 8 + board/xilinx/versal-net/Makefile | 9 + board/xilinx/versal-net/board.c | 170 ++ env/Kconfig | 6 +- include/configs/xilinx_versal_net.h | 156 19 files changed, 614 insertions(+), 7 deletions(-) create mode 100644 arch/arm/dts/xilinx-versal-net-virt.dts create mode 100644 arch/arm/mach-versal-net/Kconfig create mode 100644 arch/arm/mach-versal-net/Makefile create mode 100644 arch/arm/mach-versal-net/clk.c create mode 100644 arch/arm/mach-versal-net/cpu.c create mode 100644 arch/arm/mach-versal-net/include/mach/hardware.h create mode 100644 arch/arm/mach-versal-net/include/mach/sys_proto.h create mode 100644 board/xilinx/versal-net/Kconfig create mode 100644 board/xilinx/versal-net/MAINTAINERS create mode 100644 board/xilinx/versal-net/Makefile create mode 100644 board/xilinx/versal-net/board.c create mode 100644 include/configs/xilinx_versal_net.h diff --git a/Kconfig b/Kconfig index 991b260182e8..4542ed7333d1 100644 --- a/Kconfig +++ b/Kconfig @@ -539,7 +539,7 @@ config PLATFORM_ELFENTRY config STACK_SIZE hex "Define max stack size that can be used by U-Boot" - default 0x400 if ARCH_VERSAL || ARCH_ZYNQMP + default 0x400 if ARCH_VERSAL_NET || ARCH_VERSAL || ARCH_ZYNQMP default 0x20 if MICROBLAZE default 0x100 help diff --git a/MAINTAINERS b/MAINTAINERS index 1a7a56335f6f..82b5e9edc29c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -628,6 +628,13 @@ F: arch/arm/mach-uniphier/ F: configs/uniphier_*_defconfig N: uniphier +ARM VERSAL NET +M: Michal Simek +S: Maintained +T: git https://source.denx.de/u-boot/custodians/u-boot-microblaze.git +F: arch/arm/mach-versal-net/ +N: (? S: Maintained diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3649222470ea..cf2ccb4a7306 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1248,6 +1248,18 @@ config ARCH_VERSAL imply BOARD_LATE_INIT imply ENV_VARS_UBOOT_RUNTIME_CONFIG +config ARCH_VERSAL_NET + bool "Support Xilinx Keystone Platform" + select ARM64 + select CLK + select DM + select DM_ETH if NET + select DM_MMC if MMC + select DM_SERIAL + select OF_CONTROL + imply BOARD_LATE_INIT + imply ENV_VARS_UBOOT_RUNTIME_CONFIG + config ARCH_VF610 bool "Freescale Vybrid" select CPU_V7A @@ -2297,6 +2309,8 @@ source "arch/arm/mach-zynqmp/Kconfig" source "arch/arm/mach-versal/Kconfig" +source "arch/arm/mach-versal-net/Kconfig" + source "arch/arm/mach-zynqmp-r5/Kconfig" source "arch/arm/cpu/armv7/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 1f4a1d57883b..ac602aed9c9a 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -88,6 +88,7 @@ machine-$(CONFIG_ARCH_OCTEONTX) += octeontx machine-$(CONFIG_ARCH_OCTEONTX2) += octeontx2 machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier machine-$(CONFIG_ARCH_VERSAL) += versal +machine-$(CONFIG_ARCH_VERSAL_NET) += versal-net machine-$(CONFIG_ARCH_ZYNQ)+= zynq machine-$(CONFIG_ARCH_ZYNQMP) += zynqmp machine-$(CONFIG_ARCH_ZYNQMP_R5) += zynqmp-r5 diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 5bff2e65b76f..a141d0de0c20 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -379,6 +379,8 @@ dtb-$(CONFIG_ARCH_VERSAL) += \ versal-mini-emmc0.dtb \ versal-mini-emmc1.dtb \ xilinx-versal-virt.dtb +dtb-$(CONFIG_ARCH_VERSAL_NET) += \ + xilinx-versal-net-virt.dtb dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \ zynqmp-r5.dtb dtb-$(CONFIG_AM33XX) += \ diff --git
[PATCH 0/9] xilinx: versal-net: Add support for new Versal NET SoC
Hi, I am sending support for new Xilinx/AMD SoC called Versal NET. Versal NET is very similar to origin Versal SOC. There is different register layout, some IPs have been upgraded like i3c and some other changes in different location. Thanks, Michal Jay Buddhabhatti (4): clk: versal: Enable clock driver for Versal NET firmware: zynqmp: Add Versal NET compatible string mailbox: zynqmp: Enable ipi mailbox driver for Versal NET reset: zynqmp: Enable reset driver for Versal NET Michal Simek (5): arm64: versal-net: Add support for Versal NET platform spi: cadence_qspi: Add support for Versal NET platform spi: zynqmp_gqspi: Add support for Versal NET arm64: versal-net: Add defconfig for Versal NET arm64: versal-net: Add support for mini configuration Kconfig | 2 +- MAINTAINERS | 7 + arch/arm/Kconfig | 14 ++ arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 3 + arch/arm/dts/versal-net-mini.dts | 67 +++ arch/arm/dts/xilinx-versal-net-virt.dts | 11 ++ arch/arm/mach-versal-net/Kconfig | 43 + arch/arm/mach-versal-net/Makefile | 10 ++ arch/arm/mach-versal-net/clk.c| 35 arch/arm/mach-versal-net/cpu.c| 89 + .../mach-versal-net/include/mach/hardware.h | 31 .../mach-versal-net/include/mach/sys_proto.h | 16 ++ board/xilinx/Kconfig | 6 +- board/xilinx/versal-net/Kconfig | 9 + board/xilinx/versal-net/MAINTAINERS | 8 + board/xilinx/versal-net/Makefile | 9 + board/xilinx/versal-net/board.c | 170 ++ configs/xilinx_versal_net_mini_defconfig | 70 configs/xilinx_versal_net_virt_defconfig | 118 drivers/clk/Kconfig | 2 +- drivers/clk/clk_versal.c | 1 + drivers/firmware/firmware-zynqmp.c| 1 + drivers/mailbox/Kconfig | 2 +- drivers/reset/reset-zynqmp.c | 1 + drivers/spi/Kconfig | 2 +- drivers/spi/cadence_ospi_versal.c | 3 +- drivers/spi/zynqmp_gqspi.c| 3 +- env/Kconfig | 6 +- include/configs/xilinx_versal_net.h | 156 include/configs/xilinx_versal_net_mini.h | 28 +++ 31 files changed, 912 insertions(+), 12 deletions(-) create mode 100644 arch/arm/dts/versal-net-mini.dts create mode 100644 arch/arm/dts/xilinx-versal-net-virt.dts create mode 100644 arch/arm/mach-versal-net/Kconfig create mode 100644 arch/arm/mach-versal-net/Makefile create mode 100644 arch/arm/mach-versal-net/clk.c create mode 100644 arch/arm/mach-versal-net/cpu.c create mode 100644 arch/arm/mach-versal-net/include/mach/hardware.h create mode 100644 arch/arm/mach-versal-net/include/mach/sys_proto.h create mode 100644 board/xilinx/versal-net/Kconfig create mode 100644 board/xilinx/versal-net/MAINTAINERS create mode 100644 board/xilinx/versal-net/Makefile create mode 100644 board/xilinx/versal-net/board.c create mode 100644 configs/xilinx_versal_net_mini_defconfig create mode 100644 configs/xilinx_versal_net_virt_defconfig create mode 100644 include/configs/xilinx_versal_net.h create mode 100644 include/configs/xilinx_versal_net_mini.h -- 2.36.1
Re: [PATCH] mmc: dwmmc: only clear handled interrupts
On 9/15/22 19:56, John Keeping wrote:
> Unconditionally clearing DTO when RXDR is set leads to spurious timeouts
> in FIFO mode transfers if events occur in the following order:
>
> mask = dwmci_readl(host, DWMCI_RINTSTS);
>
> // Hardware asserts DWMCI_INTMSK_DTO here
>
> dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_DTO);
>
> if (mask & DWMCI_INTMSK_DTO) {
> // Unreachable as DTO is cleared without being handled!
> return 0;
> }
>
> Only clear interrupts that we have seen and are handling so that DTO is
> not missed.
>
> Signed-off-by: John Keeping
> ---
> drivers/mmc/dw_mmc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 4232c5eb8c..5085a3b491 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -168,7 +168,8 @@ static int dwmci_data_transfer(struct dwmci_host *host,
> struct mmc_data *data)
> if (data->flags == MMC_DATA_READ &&
> (mask & (DWMCI_INTMSK_RXDR | DWMCI_INTMSK_DTO))) {
> dwmci_writel(host, DWMCI_RINTSTS,
> - DWMCI_INTMSK_RXDR |
> DWMCI_INTMSK_DTO);
> + mask & (DWMCI_INTMSK_RXDR |
> + DWMCI_INTMSK_DTO));
> while (size) {
> ret = dwmci_fifo_ready(host,
> DWMCI_FIFO_EMPTY,
Tested-by: Jerome Forissier (Rock PI 4B)
Boot logs:
- 2022.04 without this patch:
[...]
U-Boot SPL 2022.04 (Apr 04 2022 - 14:31:32 +)
Trying to boot from MMC1
## Checking hash(es) for config config_1 ... sha1,rsa2048:dev+ OK
## Checking hash(es) for Image atf_1 ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image uboot ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image fdt_1 ... sha1+ sha1,rsa2048:dev+ OK
spl_load_simple_fit: can't load image loadables index 1 (ret = -5)
mmc_load_image_raw_sector: mmc block read error
[...]
- 2022.04 with this patch:
[...]
U-Boot SPL 2022.04 (Apr 04 2022 - 14:31:32 +)
Trying to boot from MMC1
## Checking hash(es) for config config_1 ... sha1,rsa2048:dev+ OK
## Checking hash(es) for Image atf_1 ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image uboot ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image fdt_1 ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image atf_2 ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image atf_3 ... sha1+ sha1,rsa2048:dev+ OK
## Checking hash(es) for Image atf_4 ... sha1+ sha1,rsa2048:dev+ OK
NOTICE: BL31: v2.6(debug):v2.6-879-gc3bdd3d3cf-dirty
[...]
Thanks,
--
Jerome
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
Hello! I think it does not make sense to hack kwboot to skip validation
of kwbimage format when ad-hoc TIM header is detected. kwboot has now
lot of features which requires and expects valid kwbimage format and is
now written to work specially with 32-bit mvebu ARM BootROMs.
TIM and kwbimage are totally different formats and it really does not
make sense to starting rewriting kwboot to support also other format.
Instead it would be better to write other dedicated tool for it.
For example, there is already tool mox-imager [1], which despite its
name supports all A3720 BootROMS and mvebu64boot [2] which supports
A70x0, A80x0 and CN9130 BootROMS.
[1] - https://gitlab.nic.cz/turris/mox-imager
[2] - https://github.com/pali/mvebu64boot
On Friday 16 September 2022 16:54:23 Chris Packham wrote:
> Marvell's proprietary TIM (trusted image) is used on the Armada-3700 and
> AlledCat5/5X (and possibly others). It has a whole host of features that
> work to implement a version of secure boot.
>
> Kwboot's interest in this format is simply to detect that the image is
> one of these and not attempt to patch it (the images will work over UART
> boot as-is). This is done by checking for a specific magic value
> ("TIMH") in the first 32bits of the image.
>
> Signed-off-by: Chris Packham
> ---
> It might be possible to make the check more robust by validating more of
> the image. There is a checksum field that might be useful for this
> purpose. I haven't done this as I couldn't figure out Marvell's
> validation of this field.
>
> tools/kwbimage.h | 29 +
> tools/kwboot.c | 3 +++
> 2 files changed, 32 insertions(+)
>
> diff --git a/tools/kwbimage.h b/tools/kwbimage.h
> index 505522332b..8aab26952a 100644
> --- a/tools/kwbimage.h
> +++ b/tools/kwbimage.h
> @@ -224,6 +224,28 @@ struct register_set_hdr_v1 {
> #define OPT_HDR_V1_BINARY_TYPE 0x2
> #define OPT_HDR_V1_REGISTER_TYPE 0x3
>
> +/* TIM (trusted image), Armada 3700, AlleyCat5 */
> +struct tim_block_hdr {
> + uint32_t signature_id;
> + uint16_t opcode;
> + uint16_t blocksize;
> +} __packed;
> +
> +struct tim_hdr {
> + struct tim_block_hdr hdr;
> + uint32_t trusted;
> + uint32_t signed_tim_size;
> + uint32_t unsigned_tim_size;
> + uint32_t unique_id;
> + uint64_t loadaddr;
> + uint32_t flags;
> + uint32_t software_prot_version;
> + uint32_t num_blocks;
> + uint32_t checksum;
> +} __packed;
> +
> +#define TIM_HDR_SIGNATURE0x54494d48 /* "TIMH" */
> +
> /*
> * Byte 8 of the image header contains the version number. In the v0
> * header, byte 8 was reserved, and always set to 0. In the v1 header,
> @@ -270,6 +292,13 @@ static inline size_t kwbheader_size_for_csum(const void
> *header)
> return kwbheader_size(header);
> }
>
> +static inline bool kwbimage_is_tim(void *img)
> +{
> + const struct tim_hdr *hdr = img;
> +
> + return le32_to_cpu(hdr->hdr.signature_id) == TIM_HDR_SIGNATURE;
> +}
> +
> static inline struct ext_hdr_v0 *ext_hdr_v0_first(void *img)
> {
> struct main_hdr_v0 *mhdr;
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index da4fe32da2..a9b3d0fd04 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -1869,6 +1869,9 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
> if (*size < sizeof(struct main_hdr_v1))
> goto err;
>
> + if (kwbimage_is_tim(img))
> + return 0;
> +
> image_ver = kwbimage_version(img);
> if (image_ver != 0 && image_ver != 1) {
> fprintf(stderr, "Invalid image header version\n");
> --
> 2.37.3
>
Please pull u-boot-watchdog/next
Hi Tom, please pull the following watchdog related patches: - Migrate watchdog reset to cyclic infrastructure (Stefan) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=260=results Thanks, Stefan The following changes since commit 6ec7207ab3c4dad098967fef5df75e25240fd852: Merge branch '2022-09-15-TI-platform-updates' into next (2022-09-15 17:02:52 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git next for you to fetch changes up to 4bd01be23a9d0c2dbfaac0c196ead6a89824cbf8: watchdog: Further cleanup (2022-09-16 07:09:05 +0200) Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup arch/arm/mach-at91/phy.c | 2 +- arch/arm/mach-imx/i2c-mxv7.c | 2 +- arch/arm/mach-socfpga/spl_a10.c| 8 +-- .../mach-stm32mp/cmd_stm32prog/stm32prog_serial.c | 6 +- arch/m68k/lib/time.c | 2 +- arch/powerpc/cpu/mpc8xx/cpu_init.c | 2 +- arch/powerpc/lib/bootm.c | 6 +- arch/powerpc/lib/cache.c | 2 +- arch/powerpc/lib/interrupts.c | 2 +- arch/powerpc/lib/ticks.S | 5 +- board/astro/mcf5373l/fpga.c| 4 +- board/dhelectronics/dh_stm32mp1/board.c| 2 +- board/liebherr/display5/spl.c | 2 +- board/nokia/rx51/rx51.c| 2 +- board/st/stm32mp1/stm32mp1.c | 2 +- boot/bootretry.c | 2 +- boot/image-board.c | 2 +- cmd/fastboot.c | 2 +- cmd/mem.c | 16 ++--- cmd/usb_mass_storage.c | 2 +- cmd/ximg.c | 2 +- common/board_f.c | 4 +- common/board_r.c | 2 +- common/cli_readline.c | 4 +- common/console.c | 2 +- common/cyclic.c| 11 common/dfu.c | 2 +- common/lcd.c | 10 +-- common/menu.c | 6 +- common/usb_kbd.c | 2 +- common/xyzModem.c | 2 +- drivers/block/ide.c| 8 +-- drivers/crypto/aspeed/aspeed_hace.c| 2 +- drivers/crypto/hash/hash_sw.c | 2 +- drivers/ddr/altera/sdram_arria10.c | 4 +- drivers/ddr/altera/sdram_n5x.c | 4 +- drivers/ddr/altera/sdram_soc64.c | 2 +- drivers/fpga/intel_sdm_mb.c| 8 +-- drivers/fpga/socfpga_arria10.c | 8 +-- drivers/i2c/mxc_i2c.c | 4 +- drivers/mmc/octeontx_hsmmc.c | 12 ++-- drivers/mmc/sh_mmcif.c | 6 +- drivers/mmc/stm32_sdmmc2.c | 2 +- drivers/mtd/cfi_flash.c| 4 +- drivers/mtd/nand/core.c| 2 +- drivers/mtd/nand/raw/atmel_nand.c | 6 +- drivers/mtd/nand/raw/nand_base.c | 10 +-- drivers/mtd/nand/raw/nand_util.c | 6 +- drivers/mtd/nand/spi/core.c| 4 +- drivers/mtd/onenand/onenand_base.c | 4 +- drivers/mtd/spi/spi-nor-core.c | 4 +- drivers/net/octeontx2/nix.c| 2 +- drivers/net/octeontx2/nix_af.c | 32 +- drivers/ram/stm32mp1/stm32mp1_tests.c | 2 +- drivers/serial/atmel_usart.c | 2 +- drivers/serial/ns16550.c | 6 +- drivers/serial/serial-uclass.c | 2 +- drivers/serial/serial_bcm283x_mu.c | 2 +- drivers/serial/serial_lpuart.c | 8 +-- drivers/serial/serial_mpc8xx.c | 4 +- drivers/serial/serial_mt7620.c | 2 +- drivers/serial/serial_mtk.c| 4 +- drivers/serial/serial_mxc.c| 6 +-
Re: [PATCH v1 0/6] Migrate watchdog reset to cyclic infrastructure
On 02.09.22 14:10, Stefan Roese wrote: This patchset migrates the watchdog triggering (WATCHDOG_RESET calls) to the newly introduced cyclic execution framework. For this, the watchdog driver now registers a cyclic execution function for each WDT device that needs to get serviced. Additionally the cyclic IF is a bit extended to also support the CONFIG_HW_WATCHDOG users. It might make sense to deprecate this HW_WATCHDOG usage at some point. Please note that this migration work is based on the cyclic execution infrastructure, which I posted in the last few weeks. So these cyclic patches need to be applied for this migration to work. Some further cleanup and improvements are possible after this patch. E.g. Heinrich mentioned that the WATCHDOG_RESET call locations need to get improved / changed in some places. I've pushed a working branch here for anyone who wants to do some testing with this patchset: https://source.denx.de/u-boot/custodians/u-boot-watchdog/-/commits/cyclic-v5-watchdog-migration-to-cyclic-v1-2022-09-02 Here the log from octeon_ebb7304 compiled on this branch: U-Boot 2022.10-rc3-00063-g1050cb3e6d8e (Aug 29 2022 - 07:57:07 +0200) SoC: Octeon CN73xx (16 cores) Model: cavium,ebb7304 DRAM: 256 MiB (16 GiB total) Core: 31 devices, 24 uclasses, devicetree: separate WDT: Started interrupt-controller@10100 with servicing all 1000ms (60s timeout) Flash: 8 MiB MMC: octeontx-mmc0: 0, octeontx-mmc1: 1 Loading Environment from Flash... OK QLM 0: PCIe gen3 root complex, x4 lanes QLM 2: SGMII QLM 3: XLAUI QLM 5: SGMII Net: eth0: ethernet-mac-nexus@11800e000 => cyclic list function: interrupt-controller@10100, cpu-time: 4 us, frequency: 1.11 times/s => wdt list interrupt-controller@10100 (wdt_octeontx) Any comments and suggestions are welcome. Thanks, Stefan Stefan Roese (6): watchdog: Integrate watchdog triggering into the cyclic framework cyclic: Introduce schedule() function cyclic: Use schedule() instead of WATCHDOG_RESET() watchdog: Get rid of ASSEMBLY hacks watchdog: Remove WATCHDOG_RESET macro watchdog: Further cleanup arch/arm/mach-at91/phy.c | 2 +- arch/arm/mach-imx/i2c-mxv7.c | 2 +- arch/arm/mach-socfpga/spl_a10.c | 8 +- .../cmd_stm32prog/stm32prog_serial.c | 6 +- arch/m68k/lib/time.c | 2 +- arch/powerpc/cpu/mpc8xx/cpu_init.c| 2 +- arch/powerpc/lib/bootm.c | 6 +- arch/powerpc/lib/cache.c | 2 +- arch/powerpc/lib/interrupts.c | 2 +- arch/powerpc/lib/ticks.S | 5 +- board/astro/mcf5373l/fpga.c | 4 +- board/dhelectronics/dh_stm32mp1/board.c | 2 +- board/liebherr/display5/spl.c | 2 +- board/nokia/rx51/rx51.c | 2 +- board/st/stm32mp1/stm32mp1.c | 2 +- boot/bootretry.c | 2 +- boot/image-board.c| 2 +- cmd/fastboot.c| 2 +- cmd/mem.c | 16 ++-- cmd/usb_mass_storage.c| 2 +- cmd/ximg.c| 2 +- common/board_f.c | 4 +- common/board_r.c | 2 +- common/cli_readline.c | 4 +- common/console.c | 2 +- common/cyclic.c | 11 +++ common/dfu.c | 2 +- common/lcd.c | 10 +-- common/menu.c | 6 +- common/usb_kbd.c | 2 +- common/xyzModem.c | 2 +- drivers/block/ide.c | 8 +- drivers/crypto/aspeed/aspeed_hace.c | 2 +- drivers/crypto/hash/hash_sw.c | 2 +- drivers/ddr/altera/sdram_arria10.c| 4 +- drivers/ddr/altera/sdram_n5x.c| 4 +- drivers/ddr/altera/sdram_soc64.c | 2 +- drivers/fpga/intel_sdm_mb.c | 8 +- drivers/fpga/socfpga_arria10.c| 8 +- drivers/i2c/mxc_i2c.c | 4 +- drivers/mmc/octeontx_hsmmc.c | 12 +-- drivers/mmc/sh_mmcif.c| 6 +- drivers/mmc/stm32_sdmmc2.c| 2 +- drivers/mtd/cfi_flash.c | 4 +- drivers/mtd/nand/core.c | 2 +- drivers/mtd/nand/raw/atmel_nand.c | 6 +- drivers/mtd/nand/raw/nand_base.c | 10 +-- drivers/mtd/nand/raw/nand_util.c | 6 +- drivers/mtd/nand/spi/core.c | 4 +- drivers/mtd/onenand/onenand_base.c| 4 +- drivers/mtd/spi/spi-nor-core.c| 4 +-
Re: [PATCH v10 10/15] FWU: Add support for the FWU Multi Bank Update feature
On Fri, Sep 16, 2022 at 10:52:11AM +0530, Sughosh Ganu wrote:
> () hi Takahiro,
>
> On Fri, 16 Sept 2022 at 07:17, Takahiro Akashi
> wrote:
> >
> > Hi Sughosh,
> >
> > On Thu, Sep 15, 2022 at 01:44:46PM +0530, Sughosh Ganu wrote:
> > > The FWU Multi Bank Update feature supports updation of firmware images
> > > to one of multiple sets(also called banks) of images. The firmware
> > > images are clubbed together in banks, with the system booting images
> > > from the active bank. Information on the images such as which bank
> > > they belong to is stored as part of the metadata structure, which is
> > > stored on the same storage media as the firmware images on a dedicated
> > > partition.
> > >
> > > At the time of update, the metadata is read to identify the bank to
> > > which the images need to be flashed(update bank). On a successful
> > > update, the metadata is modified to set the updated bank as active
> > > bank to subsequently boot from.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > Changes since V9:
> > > * Move the global variables into local variables as suggested by
> > > Ilias.
> > > * Change fwu_get_image_alt_num() name to fwu_get_image_image_index()
> >
> > -> typo? fwu_get_image_index()?
> >
> > > as suggested by Takahiro.
> > > * Allow capsule updates to be called from efi_init_obj_list() with the
> > > FWU feature enabled, as suggested by Takahiro.
> > > * Enable EFI_CAPSULE_ON_DISK_EARLY as an imply with the FWU feature
> > > enabled.
> > > * Define the FWU feature related functions as __maybe_unused to allow
> > > for compilation with the FWU feature disabled.
> > >
> > > drivers/Kconfig | 2 +
> > > drivers/Makefile | 1 +
> > > include/fwu.h| 30 +
> > > lib/Kconfig | 6 +
> > > lib/Makefile | 1 +
> > > lib/efi_loader/efi_capsule.c | 243 ++-
> > > lib/fwu_updates/Kconfig | 33 +
> > > lib/fwu_updates/Makefile | 7 +
> > > lib/fwu_updates/fwu.c| 23
> > > 9 files changed, 340 insertions(+), 6 deletions(-)
> > > create mode 100644 lib/fwu_updates/Kconfig
> > > create mode 100644 lib/fwu_updates/Makefile
> > >
> > > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > > index 8b6fead351..75ac149d31 100644
> > > --- a/drivers/Kconfig
> > > +++ b/drivers/Kconfig
> > > @@ -44,6 +44,8 @@ source "drivers/fuzz/Kconfig"
> > >
> > > source "drivers/fpga/Kconfig"
> > >
> > > +source "drivers/fwu-mdata/Kconfig"
> > > +
> > > source "drivers/gpio/Kconfig"
> > >
> > > source "drivers/hwspinlock/Kconfig"
> > > diff --git a/drivers/Makefile b/drivers/Makefile
> > > index eba9940231..af7ed7bdf3 100644
> > > --- a/drivers/Makefile
> > > +++ b/drivers/Makefile
> > > @@ -84,6 +84,7 @@ obj-y += cache/
> > > obj-$(CONFIG_CPU) += cpu/
> > > obj-y += crypto/
> > > obj-$(CONFIG_FASTBOOT) += fastboot/
> > > +obj-$(CONFIG_FWU_MDATA) += fwu-mdata/
> > > obj-y += misc/
> > > obj-$(CONFIG_MMC) += mmc/
> > > obj-$(CONFIG_NVME) += nvme/
> > > diff --git a/include/fwu.h b/include/fwu.h
> > > index d5f77ce83c..1d15ac98da 100644
> > > --- a/include/fwu.h
> > > +++ b/include/fwu.h
> > > @@ -60,6 +60,7 @@ struct fwu_mdata_ops {
> > > };
> > >
> > > #define FWU_MDATA_VERSION0x1
> > > +#define FWU_IMAGE_ACCEPTED 0x1
> > >
> > > /*
> > > * GUID value defined in the FWU specification for identification
> > > @@ -69,6 +70,24 @@ struct fwu_mdata_ops {
> > > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > >
> > > +/*
> > > +* GUID value defined in the Dependable Boot specification for
> > > +* identification of the revert capsule, used for reverting
> > > +* any image in the updated bank.
> > > +*/
> > > +#define FWU_OS_REQUEST_FW_REVERT_GUID \
> > > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \
> > > + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0)
> > > +
> > > +/*
> > > +* GUID value defined in the Dependable Boot specification for
> > > +* identification of the accept capsule, used for accepting
> > > +* an image in the updated bank.
> > > +*/
> > > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \
> > > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
> > > + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
> > > +
> > > /**
> > > * fwu_get_mdata() - Get a FWU metadata copy
> > > * @dev: FWU metadata device
> > > @@ -269,4 +288,15 @@ void fwu_plat_get_bootidx(uint *boot_idx);
> > > */
> > > u8 fwu_update_checks_pass(void);
> > >
> > > +/**
> > > + * fwu_trial_state_ctr_start() - Start the Trial State counter
> > > + *
> > > + * Start the counter to identify the platform booting in the
> > > + * Trial State. The counter is implemented as an EFI variable.
> > > + *
> > > + * Return: 0 if OK, -ve on error
> > > + *
> > > + */
> > > +int fwu_trial_state_ctr_start(void);
> > > +
> > > #endif /* _FWU_H_ */
> > > diff --git a/lib/Kconfig
Re: [PATCH 1/2] dm: blk: assign media ID to block devices
On 9/16/22 03:30, Simon Glass wrote: Hi Heinrich, On Thu, 15 Sept 2022 at 14:02, Heinrich Schuchardt wrote: Currently block devices are only identified by uclass_id and device number. When dealing with removable media this is not enough to uniquely identify the medium. E.g. after host unbind, host bind we can have the same device number but a different backing file. The EFI specification uses a 32bit number media ID to identify media. Add a matching field to the block device descriptor. Signed-off-by: Heinrich Schuchardt --- drivers/block/blk-uclass.c | 16 +++- include/blk.h | 11 +++ 2 files changed, 26 insertions(+), 1 deletion(-) Shouldn't this be handled by connecting the EFI data to its udevice. I think Takahiro has been looking at this? NAK to any EFI fields in blk_desc, in any case The information that a medium has changed can only come from the DM layer. If for instance the SD-card is swapped, this is indicated by the card detector switch. USB also has a signal for media changes. What are your ideas how the DM layer shall indicate media changes? Best regards Heinrich
