Re: [PATCH RESEND v2 2/2] usb: udc: Try to clarify an error message
Hi Miquel, Il giorno lun 2 ott 2023 alle ore 15:46 Miquel Raynal ha scritto: > > At some point when trying to use USB gadgets, two situations may arise [...cut...] > Signed-off-by: Miquel Raynal > --- > While doing this I really wanted to add "much more" error comments but I > faced another reality: often the messages are there but use > pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so > I consider this unnecessary, as decreasing the loglevel will make these > messages appear. I would have expected errors to be displayed, but I > understand it makes the binaries even bigger. This is how it works for pr_err but not for log_err: if you are not using CONFIG_LOG, all log_xxx with level less than or equal to INFO are in the binary. On the other hand, if you have CONFIG_LOG=y, log_xxx are left out based on LOG_MAX_LEVEL value, while pr_xxx are left out based on both LOGLEVEL and LOG_MAX_LEVEL too (due to the fact that pr_xxx relies on log_xxx). This is quite confusing IMO. I'm working on a proposal for a simpler and clearer unified way to log in U-Boot. Regards, Massimo > Resend: no change. > [...cut...]
[PATCH v2] configs: rockchip: add DOS_PARTITION to RK3308 boards defconfig
Without DOS_PARTITION support U-Boot is not able to boot an OS stored into an SD card with MBR partitions table. This is still a quite common case so add DOS_PARTITION (only for U-Boot proper build) to Rockchip RK3308 EVB, Radxa ROCK Pi S and Firefly roc-rk3308-cc boards: they are the only RK boards missing of DOS_PARTITION. Reported-by: Jayantajit Gogoi Signed-off-by: Massimo Pegorer --- configs/evb-rk3308_defconfig | 2 +- configs/roc-cc-rk3308_defconfig| 2 +- configs/rock-pi-s-rk3308_defconfig | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig index a13a809c1e..c6472a2c9c 100644 --- a/configs/evb-rk3308_defconfig +++ b/configs/evb-rk3308_defconfig @@ -47,7 +47,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_SLEEP is not set -# CONFIG_DOS_PARTITION is not set +# CONFIG_SPL_DOS_PARTITION is not set # CONFIG_ISO_PARTITION is not set CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 CONFIG_SPL_OF_CONTROL=y diff --git a/configs/roc-cc-rk3308_defconfig b/configs/roc-cc-rk3308_defconfig index 9a789b212f..ca92b8f744 100644 --- a/configs/roc-cc-rk3308_defconfig +++ b/configs/roc-cc-rk3308_defconfig @@ -47,7 +47,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_SLEEP is not set -# CONFIG_DOS_PARTITION is not set +# CONFIG_SPL_DOS_PARTITION is not set # CONFIG_ISO_PARTITION is not set CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 CONFIG_SPL_OF_CONTROL=y diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig index cc3274a98b..1c1fdc6611 100644 --- a/configs/rock-pi-s-rk3308_defconfig +++ b/configs/rock-pi-s-rk3308_defconfig @@ -48,7 +48,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_SLEEP is not set -# CONFIG_DOS_PARTITION is not set +# CONFIG_SPL_DOS_PARTITION is not set # CONFIG_ISO_PARTITION is not set CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 CONFIG_SPL_OF_CONTROL=y -- 2.34.1
Re: [PATCH 2/2] configs: rockchip: add DOS_PARTITION to RK3308 boards defconfig
Hi Kever, Il giorno mer 27 set 2023 alle ore 05:10 Kever Yang ha scritto: > > Hi Massimo, > > This patch is fine to me, but you can merge these two patch into > one, because they > > are all rk3308 boards. OK, I will merge them in a single v2 patch. Thanks. I had split them because I had chance to test it only on rock-pi-s, so I was not sure everybody would have agreed to change also evb and firefly boards defconfigs. Regards, Massimo > > And if you have more than one patch, it'd better to use > --in-reply-to for follow up patches > > so that the mail system know this is a patch set and grab them together. > > > Thanks, > > - Kever > > On 2023/9/3 01:15, Massimo Pegorer wrote: > > Without DOS_PARTITION support U-Boot is not able to boot an OS stored > > into an SD card with MBR partitions table. This is still a quite common > > case, so add DOS_PARTITION (only for U-Boot proper build) to Rockchip > > RK3308 EVB and Firefly roc-rk3308-cc board: they are the only RK boards > > missing of DOS_PARTITION. > > > > Signed-off-by: Massimo Pegorer > > --- > > configs/evb-rk3308_defconfig| 2 +- > > configs/roc-cc-rk3308_defconfig | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig > > index a13a809c1e..c6472a2c9c 100644 > > --- a/configs/evb-rk3308_defconfig > > +++ b/configs/evb-rk3308_defconfig > > @@ -47,7 +47,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y > > # CONFIG_CMD_ITEST is not set > > # CONFIG_CMD_SETEXPR is not set > > # CONFIG_CMD_SLEEP is not set > > -# CONFIG_DOS_PARTITION is not set > > +# CONFIG_SPL_DOS_PARTITION is not set > > # CONFIG_ISO_PARTITION is not set > > CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 > > CONFIG_SPL_OF_CONTROL=y > > diff --git a/configs/roc-cc-rk3308_defconfig > > b/configs/roc-cc-rk3308_defconfig > > index 9a789b212f..ca92b8f744 100644 > > --- a/configs/roc-cc-rk3308_defconfig > > +++ b/configs/roc-cc-rk3308_defconfig > > @@ -47,7 +47,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y > > # CONFIG_CMD_ITEST is not set > > # CONFIG_CMD_SETEXPR is not set > > # CONFIG_CMD_SLEEP is not set > > -# CONFIG_DOS_PARTITION is not set > > +# CONFIG_SPL_DOS_PARTITION is not set > > # CONFIG_ISO_PARTITION is not set > > CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 > > CONFIG_SPL_OF_CONTROL=y
Re: [PATCH v2] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation : regression
Il giorno ven 29 set 2023 alle ore 13:23 Roger Quadros
ha scritto:
>
>
>
> On 28/09/2023 22:18, Jonas Karlman wrote:
> > Hi Roger,
> >
> > On 2023-09-28 14:59, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 21/08/2023 01:03, Jonas Karlman wrote:
> >>> Nodes with bootph-pre-sram/ram props are bound in multiple phases:
> >>> 1. At TPL (bootph-pre-sram) or SPL (bootph-pre-ram) phase
> >>> 2. At U-Boot proper pre-relocation phase
> >>> 3. At U-Boot proper normal phase
> >>>
> >>> However the binding and U-Boot Driver Model documentation indicate that
> >>> only nodes marked with bootph-all or bootph-some-ram should be bound in
> >>> the U-Boot proper pre-relocation phase.
> >>>
> >>> Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
> >>> with a pre-reloc status only after U-Boot proper pre-relocation phase.
> >>> Also update the ofnode_pre_reloc documentation to closer reflect the
> >>> binding and driver model documentation.
> >>>
> >>> This changes behavior of what nodes are bound in the U-Boot proper
> >>> pre-relocation phase. Change to bootph-all or add bootph-some-ram prop
> >>> to restore prior behavior.
> >>>
> >>> Signed-off-by: Jonas Karlman
> >>> Reviewed-by: Simon Glass
> >>> ---
> >>> Changes in v2:
> >>> - Drop use of !! to convert into bool
> >>> - Update documentation for ofnode_pre_reloc
> >>> - Rewrite commit message
> >>> - Collect r-b tag
> >>
> >> This patch breaks boot on AM642-EVM. Boot log at the end.
> >
> > From what I can tell your board use a lot of bootph-pre-ram.
> > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> >
> > What happens if you change to bootph-all or add bootph-some-ram next to
> > bootph-pre-ram on devices that is also needed in U-Boot proper
> > pre-relocation phase in addition to SPL phase?
>
> Then it works.
>
> BTW, AM62-SK is broken as well and I suppose most K3 TI boards would be
> broken.
>
> Nishanth / Tom,
>
> What approach to take here?
> Replacing bootph-pre-ram to bootph-all in *-u-boot.dtsi would be a quick fix.
An exact quick fix is to add bootph-some-ram next to bootph-pre-ram:
this will have the same effects of bootph-pre-ram before the patch.
Instead, replacing bootph-pre-ram with bootph-all will affect also
other boot phases (e.g. TPL) if any.
Regards,
Massimo
> Then we need to mark nodes required only for SPL as bootph-pre-ram.
>
> Meanwhile I will suggest to revert the $subject patch till this is sorted out
> and gets a Ack from board maintainers.
>
> cheers,
> -roger
>
> >
> > Regards,
> > Jonas
> >
> >>
> >>>
> >>> drivers/core/ofnode.c | 2 +-
> >>> include/dm/ofnode.h | 8
> >>> 2 files changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> >>> index 8df16e56af5c..b1e94b2d60df 100644
> >>> --- a/drivers/core/ofnode.c
> >>> +++ b/drivers/core/ofnode.c
> >>> @@ -1353,7 +1353,7 @@ bool ofnode_pre_reloc(ofnode node)
> >>> */
> >>> if (ofnode_read_bool(node, "bootph-pre-ram") ||
> >>> ofnode_read_bool(node, "bootph-pre-sram"))
> >>> - return true;
> >>> + return gd->flags & GD_FLG_RELOC;
> >>>
> >>> if (IS_ENABLED(CONFIG_OF_TAG_MIGRATE)) {
> >>> /* detect and handle old tags */
> >>> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
> >>> index 0f38b3e736de..13700f8266d7 100644
> >>> --- a/include/dm/ofnode.h
> >>> +++ b/include/dm/ofnode.h
> >>> @@ -1198,15 +1198,15 @@ int ofnode_read_simple_size_cells(ofnode node);
> >>> * determine if a node was bound in one of SPL/TPL stages.
> >>> *
> >>> * There are 4 settings currently in use
> >>> - * - bootph-some-ram: U-Boot proper pre-relocation only
> >>> + * - bootph-some-ram: U-Boot proper pre-relocation phase
> >>> * - bootph-all: all phases
> >>> * Existing platforms only use it to indicate nodes needed in
> >>> * SPL. Should probably be replaced by bootph-pre-ram for new platforms.
> >>> - * - bootph-pre-ram: SPL and U-Boot pre-relocation
> >>> - * - bootph-pre-sram: TPL and U-Boot pre-relocation
> >>> + * - bootph-pre-ram: SPL phase
> >>> + * - bootph-pre-sram: TPL phase
> >>> *
> >>> * @node: node to check
> >>> - * Return: true if node is needed in SPL/TL, false otherwise
> >>> + * Return: true if node should be or was bound, false otherwise
> >>> */
> >>> bool ofnode_pre_reloc(ofnode node);
> >>>
> >>
> >> ---boot log---
> >>
> >> U-Boot SPL 2023.10-rc4-00480-g9e644284ab (Sep 28 2023 - 15:53:09 +0300)
> >> Resetting on cold boot to workaround ErrataID:i2331
> >> Please resend tiboot3.bin in case of UART/DFU boot
> >> resetting ...
> >>
> >> U-Boot SPL 2023.10-rc4-00480-g9e644284ab (Sep 28 2023 - 15:53:09 +0300)
> >> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
> >> SPL initial stack usage: 13408 bytes
> >> Trying to boot from MMC2
> >> Warning: Detected image signing certificate on GP device. Skipping
> >> certificate to prevent boot failure. This will fail
Re: [PATCH] pinctrl: Check pinconfig nodes pre-reloc status recursively
Hi Simon,
Il giorno ven 11 ago 2023 alle ore 02:29 Simon Glass
ha scritto:
>
> Hi Jonas,
>
> On Sat, 5 Aug 2023 at 08:29, Jonas Karlman wrote:
> >
> > Hi Massimo,
> >
> > On 2023-08-05 16:06, Massimo Pegorer wrote:
> > > Hi Jonas,
> > >
> > > Il giorno sab 5 ago 2023 alle ore 13:11 Jonas Karlman ha
> > > scritto:
> > >
> > >> Pinconfig nodes normally bind recursively with PINCTRL_FULL and
> > >> PINCONF_RECURSIVE enabled. However, during U-Boot proper pre-relocation
> > >> any node marked with e.g. bootph-all will not bind unless its parent is
> > >> also marked for pre-reloc.
> > >>
> > >> group1 {
> > >> pinconf1 {
> > >> bootph-all;
> > >> };
> > >> };
> > >>
> > >> This cause the following warning message to be shown during U-Boot
> > >> proper pre-reloc stage on Rockchip RK3568 devices.
> > >>
> > >> ns16550_serial serial@fe66: pinctrl_select_state_full:
> > >> uclass_get_device_by_phandle_id: err=-19
> > >>
> > >> Check pinconfig nodes pre-reloc status recursively to fix this and to
> > >> make pinconfig_post_bind work same at both U-Boot proper pre-reloc and
> > >> at TPL/SPL stage.
> > >>
> > >> Signed-off-by: Jonas Karlman
> > >> ---
> > >> drivers/pinctrl/pinctrl-uclass.c | 18 +-
> > >> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> This is actually something we want to change about fdtgrep. I believe
> we should try to adjust that tool rather than loading this ontoU-Boot,
> not least because it controls what properties are visible in SPL.
So IIUC your idea is that fdtgrep tool will automatically add
bootph-xxx property to any ancestor of a node with that property? Or
to log a warning, or exit with an error, during build?
BTW, fdtgrep is applied to DT only for xPL builds, not for U-Boot
proper build. Therefore, Jonas approach could be used at least during
U-Boot proper pre-relocation phase to manage "bootph-some-ram" and
"bootph-all".
Side note: I've noticed that quiet_cmd_fdtgrep in Makefile.lib does
not strip bootph-some-sram. I think it should, doesn't it?
>
> Regards,
> Simon
Re: [PATCH 1/1] binman: doc: Remove incomplete sentence
Il giorno mer 20 set 2023 alle ore 04:59 Simon Glass
ha scritto:
>
> Hi Heinrich,
>
>
> On Tue, 19 Sept 2023 at 04:02, Heinrich Schuchardt
> wrote:
> >
> > This is the difference between version 1 and 2 of Massimo's patch:
> >
> > binman: doc: fix reference tag placement for Logging section
> > v2:
> > https://lore.kernel.org/u-boot/20230913161633.999542-1-massimo.pegorer+...@gmail.com/
> > v1:
> > https://lore.kernel.org/u-boot/20230909135235.21242-1-massimo.pegorer+...@gmail.com/
> >
> > Fixes: 0f40e23fd22 ("binman: add documentation for binman sign option")
> > Signed-off-by: Massimo Pegorer
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > tools/binman/binman.rst | 2 --
> > 1 file changed, 2 deletions(-)
>
> Reviewed-by: Simon Glass
Acked-by: Massimo Pegorer
Thanks.
Massimo
>
> I don't mind which patch is applied.
>
>
> >
> > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> > index 8945b19446..020988d955 100644
> > --- a/tools/binman/binman.rst
> > +++ b/tools/binman/binman.rst
> > @@ -1480,8 +1480,6 @@ as set in stone, so Binman will ensure it doesn't
> > change. Without this feature,
> > repacking an entry might cause it to disobey the original constraints
> > provided
> > when it was created.
> >
> > - Repacking an image involves
> > -
> >
> > Signing FIT container with private key in an image
> > --
> > --
> > 2.40.1
> >
Re: Pull request doc-2023-10-rc5-2
Hi Heinrich, Il giorno lun 18 set 2023 alle ore 16:12 Tom Rini ha scritto: > > On Sun, Sep 17, 2023 at 02:14:03AM +0200, Heinrich Schuchardt wrote: > > > Dear Tom, > > > > The following changes since commit 252592214f79d8206c3cf0056a8827a0010214e0: > > > > Merge tag 'doc-2023-10-rc5' of > > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-09-09 09:33:02 > > -0400) > > > > are available in the Git repository at: > > > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > > tags/doc-2023-10-rc5-2 > > > > for you to fetch changes up to 8bd7d08407f986fe3c69f3e198f6f7152e12dea8: > > > > binman: doc: fix reference tag placement for Logging section > > (2023-09-16 18:17:25 +0200) > > > > Gitlab CI showed no issues: > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17746 > > > > Applied to u-boot/master, thanks! > > -- > Tom This merge includes the first version [1] of the patch "binman: doc: fix reference tag placement for Logging section", not the last one [2]. Let me know if I did something wrong in sending the v2 that causes this issue. Thanks. Regards, Massimo [1] https://patchwork.ozlabs.org/project/uboot/patch/20230909135235.21242-1-massimo.pegorer+...@gmail.com/ [2] https://patchwork.ozlabs.org/project/uboot/patch/20230913161633.999542-1-massimo.pegorer+...@gmail.com/
Re: [PATCH v2 2/2] riscv: dts: starfive: generate u-boot-spl.bin.normal.out
Il giorno dom 17 set 2023 alle ore 09:14 Massimo Pegorer
ha scritto:
>
> Il giorno dom 17 set 2023 alle ore 02:01 Heinrich Schuchardt
> ha scritto:
> >
> >
> >
> > On 9/17/23 00:19, Jonas Karlman wrote:
> > > On 2023-09-06 14:00, Heinrich Schuchardt wrote:
> > >> The StarFive VisionFive 2 board cannot load spl/u-boot-spl.bin but needs
> > >> a
> > >> prefixed header. We have referring to a vendor tool (spl_tool) for this
> > >> task. 'mkimage -T sfspl' can generate the prefixed file.
> > >>
> > >> Use binman to invoke mkimage for the generation of file
> > >> spl/u-boot-spl.bin.normal.out.
> > >>
> > >> Update the documentation.
> > >>
> > >> Signed-off-by: Heinrich Schuchardt
> > >> Tested-by: Chanho Park
> > >> ---
> > >> v2:
> > >> Fix a typo in a comment in tools/sfspl.c
> > >> Add Tested-by credit
> > >> ---
> > >> .../dts/jh7110-starfive-visionfive-2-u-boot.dtsi | 10 ++
> > >> doc/board/starfive/visionfive2.rst | 14 ++
> > >> 2 files changed, 12 insertions(+), 12 deletions(-)
> > >>
> > >> diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> > >> b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> > >> index 13f69da31e..defe2b605f 100644
> > >> --- a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> > >> +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> > >> @@ -103,4 +103,14 @@
> > >> };
> > >> };
> > >> };
> > >> +u-boot-spl {
> > >> +filename = "spl/u-boot-spl.bin.normal.out";
> > >> +
> > >> +mkimage {
> > >> +args = "-T sfspl";
> > >> +blob {
> > >> +filename = "spl/u-boot-spl.bin";
> > >> +};
> > >> +};
> > >> +};
> > >
> > > This should probably be:
> > >
> > > mkimage {
> > > filename = "spl/u-boot-spl.bin.normal.out";
> > > args = "-T sfspl";
> > >
> > > u-boot-spl {
> > > };
> > > };
> >
> > @Jonas
> > If I replace the node u-boot-spl by the suggested mkimage node, I get a
> > file spl/u-boot-spl.bin.normal.out which is identical to
> > spl/u-boot-spl.bin. It lacks the header that mkimage should create.
Images and entries are different things for binman. It expects an
image at first level, while mkimage is an entry. If you wrap Jonas'
suggestion in an image declaration, you will get what you need.
Something like:
anyname {
mkimage {
filename = "spl/u-boot-spl.bin.normal.out";
args = "-T sfspl";
u-boot-spl {
};
};
};
My personal and questionable suggestions:
- Do not make binman/mkimage working in spl subfolder.
- Do not use a generic term like "normal" in filename.
- Do not use .out filename extension instead of .bin
Thus I would suggest something like:
u-boot-spl.starfive {
mkimage {
filename = "u-boot-spl.starfive.bin";
args = "-T sfspl";
u-boot-spl {
};
};
};
Regards,
Massimo
> >
> > Replacing the blob node by a u-boot-spl node is possible. Whether it is
> > better readable is a matter of taste.
>
> It is also a matter of default/standard assumptions and conventions,
> and thus opportunities. If SPL binary filename will change in the
> future for any reason, a single fix to binman would be enough for
> everybody using u-boot-spl node, while blob node users should fix each
> one of the -u-boot.dtsi files.
>
> >
> > @Simon:
> > Could you, please, have a look at doc/develop/package/entries.rst. It
> > seems not to fully describe how binman is controlled via the device-tree.
> >
> > * A blob sub-node for the mkimage node is not described.
> > * A mkimage node which is not a direct subnode of binman is not mentioned.
> > * Why the target filename must be outside of the mkimage node in my case
> > is not evident.
> >
> > Maybe a more formal description of the schema in a yaml file would help.
> >
> > Best regards
> >
> > Heinrich
> >
> > >
> > > Regards,
> > > Jonas
> > >
> > >> };
>
Re: [PATCH v2 2/2] riscv: dts: starfive: generate u-boot-spl.bin.normal.out
Il giorno dom 17 set 2023 alle ore 02:01 Heinrich Schuchardt
ha scritto:
>
>
>
> On 9/17/23 00:19, Jonas Karlman wrote:
> > On 2023-09-06 14:00, Heinrich Schuchardt wrote:
> >> The StarFive VisionFive 2 board cannot load spl/u-boot-spl.bin but needs a
> >> prefixed header. We have referring to a vendor tool (spl_tool) for this
> >> task. 'mkimage -T sfspl' can generate the prefixed file.
> >>
> >> Use binman to invoke mkimage for the generation of file
> >> spl/u-boot-spl.bin.normal.out.
> >>
> >> Update the documentation.
> >>
> >> Signed-off-by: Heinrich Schuchardt
> >> Tested-by: Chanho Park
> >> ---
> >> v2:
> >> Fix a typo in a comment in tools/sfspl.c
> >> Add Tested-by credit
> >> ---
> >> .../dts/jh7110-starfive-visionfive-2-u-boot.dtsi | 10 ++
> >> doc/board/starfive/visionfive2.rst | 14 ++
> >> 2 files changed, 12 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> >> b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> >> index 13f69da31e..defe2b605f 100644
> >> --- a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> >> +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> >> @@ -103,4 +103,14 @@
> >> };
> >> };
> >> };
> >> +u-boot-spl {
> >> +filename = "spl/u-boot-spl.bin.normal.out";
> >> +
> >> +mkimage {
> >> +args = "-T sfspl";
> >> +blob {
> >> +filename = "spl/u-boot-spl.bin";
> >> +};
> >> +};
> >> +};
> >
> > This should probably be:
> >
> > mkimage {
> > filename = "spl/u-boot-spl.bin.normal.out";
> > args = "-T sfspl";
> >
> > u-boot-spl {
> > };
> > };
>
> @Jonas
> If I replace the node u-boot-spl by the suggested mkimage node, I get a
> file spl/u-boot-spl.bin.normal.out which is identical to
> spl/u-boot-spl.bin. It lacks the header that mkimage should create.
>
> Replacing the blob node by a u-boot-spl node is possible. Whether it is
> better readable is a matter of taste.
It is also a matter of default/standard assumptions and conventions,
and thus opportunities. If SPL binary filename will change in the
future for any reason, a single fix to binman would be enough for
everybody using u-boot-spl node, while blob node users should fix each
one of the -u-boot.dtsi files.
>
> @Simon:
> Could you, please, have a look at doc/develop/package/entries.rst. It
> seems not to fully describe how binman is controlled via the device-tree.
>
> * A blob sub-node for the mkimage node is not described.
> * A mkimage node which is not a direct subnode of binman is not mentioned.
> * Why the target filename must be outside of the mkimage node in my case
> is not evident.
>
> Maybe a more formal description of the schema in a yaml file would help.
>
> Best regards
>
> Heinrich
>
> >
> > Regards,
> > Jonas
> >
> >> };
> >> diff --git a/doc/board/starfive/visionfive2.rst
> >> b/doc/board/starfive/visionfive2.rst
> >> index 941899a0a4..f5575ab68b 100644
> >> --- a/doc/board/starfive/visionfive2.rst
> >> +++ b/doc/board/starfive/visionfive2.rst
> >> @@ -65,18 +65,8 @@ Now build the U-Boot SPL and U-Boot proper
> >> make starfive_visionfive2_defconfig
> >> make
> >> OPENSBI=$(opensbi_dir)/opensbi/build/platform/generic/firmware/fw_dynamic.bin
> >>
> >> -This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb)
> >> -
> >> -u-boot-spl.bin cannot be used directly on StarFive VisionFive2,we need
> >> -to convert the u-boot-spl.bin to u-boot-spl.bin.normal.out with
> >> -the below command:
> >> -
> >> -./spl_tool -c -f $(Uboot_PATH)/spl/u-boot-spl.bin
> >> -
> >> -More detailed description of spl_tool,please refer spl_tool documenation.
> >> -(Note: spl_tool git repo is at
> >> https://github.com/starfive-tech/Tools/tree/master/spl_tool)
> >> -
> >> -This will generate u-boot-spl.bin.normal.out file.
> >> +This will generate the U-Boot SPL image (spl/u-boot-spl.bin.normal.out)
> >> as well
> >> +as the FIT image (u-boot.itb) with OpenSBI and U-Boot.
> >>
> >> Flashing
> >>
> >
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Hi Jonas,
Il giorno mer 6 set 2023 alle ore 09:11 Jonas Karlman
ha scritto:
>
> Hi Massimo,
>
> On 2023-09-06 07:15, Massimo Pegorer wrote:
> > Hi Jonas,
> >
> > Il giorno lun 4 set 2023 alle ore 18:52 Jonas Karlman
> > ha scritto:
> >>
> >> Hi Massimo,
> >>
> >> On 2023-09-04 17:05, Massimo Pegorer wrote:
> >>> Hi,
> >>>
> >>> Is there any way for binman to package FIT with U-Boot TF-A and
> >>> OP-TEE, using bl32 binary provided by Rockchip as TEE?
> >>>
> >>> I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but
> >>> binman failed.
> >>>
> >>> In my poor understanding of Python code, it seems binman accepts only
> >>> ELF format or a binary format starting with optee_v1_header, but
> >>> binaries provided by Rockchip in rkbin repository do not have this
> >>> header.
> >>
> >> One way that I have used/tested before was to create a tee.elf version
> >> using something like:
> >>
> >> $ aarch64-linux-gnu-objcopy -B aarch64 -I binary -O elf64-littleaarch64
> >> xxx_bl32_vX.YZ.bin bl32.o
> >> $ aarch64-linux-gnu-ld bl32.o -T tee.ld -o tee.elf
> >>
> >> tee.ld:
> >>
> >> ENTRY(_binary_bl32_bin_start);
> >>
> >> SECTIONS
> >> {
> >> . = 0x0840;
> >> .data : {
> >> *(.data)
> >> }
> >> }
> >>
> >
> > Thank you so much! I've been able to load and execute
> > rk3308_bl32_v2.05.bin using 0x0020 as load address instead of
> > 0x0840 in the tee.ld. This is the value I found in
> > rkbin/RKTRUST/RK3308TRUST.ini.
> >
> > Everything then goes smooth till kernel panic, but this can depends on
> > kernel build options I suspect (it is just a "random" kernel image I
> > had). I need to investigate more.
> >
> > DDR V2.07 6ede97a868 wesley.yao 22/11/29-19:27:02
> > 08
> > REG2C: 0x0034, 0x0034
> > In
> > 589MHz
> > DDR3
> > Col=10 Bank=3 Row=15 Size=512MB
> > OUT: sdram_init finish.
> >
> > U-Boot SPL 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
> > Trying to boot from MMC1
> > INFO:Preloader serial: 0
> > NOTICE: BL31: v1.3(release):0252d5c8f
> > NOTICE: BL31: Built : 07:51:11, Sep 28 2022
> > INFO:Lastlog: last=0x10, realtime=0x102000, size=0x2000
> > INFO:ARM GICv2 driver initialized
> > INFO:Using opteed sec cpu_context!
> > INFO:boot cpu mask: 1
> > INFO:plat_rockchip_pmu_init: pd status 0xe b
> > INFO:BL31: Initializing runtime services
> > INFO:BL31: Initializing BL32
> > I/TC:
> > I/TC: OP-TEE version: 3.13.0-651-gd84087907 #hisping.lin (gcc version
> > 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
> > 10.2-2020.11 (arm-10.16))) #8 Fri Sep 16 16:15:04 CST 2022 aarch64
> > I/TC: Primary CPU initializing
> > I/TC: Primary CPU switching to normal world boot
> > INFO:BL31: Preparing for EL3 exit to normal world
> > INFO:Entry point address = 0x60
> > INFO:SPSR = 0x3c9
> >
> >
> > U-Boot 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
> >
> > Model: Radxa ROCK Pi S
> > DRAM: 512 MiB (effective 510 MiB)
> > Core: 284 devices, 21 uclasses, devicetree: separate
> > MMC: mmc@ff48: 1, mmc@ff49: 0, mmc@ff4a: 2
> > Loading Environment from nowhere... OK
> > rockchip_dnl_key_pressed read board id failed
> > Net:
> > Error: ethernet@ff4e address not set.
> > No ethernet found.
> >
> > Hit any key to stop autoboot: 0
> > ** Booting bootflow 'mmc@ff48.bootdev.part_1' with script
> > 4414108 bytes read in 189 ms (22.3 MiB/s)
> > ## Loading kernel from FIT Image at 0068 ...
> >Using 'config-1' configuration
> >Trying 'kernel-1' kernel subimage
> > Description: ARM64 OpenWrt Linux-6.1.46
> > Type: Kernel Image
> > Compression: lzma compressed
> > Data Start: 0x006800e8
> > Data Size:4379870 Bytes = 4.2 MiB
> > Architecture: AArch64
> > OS: Linux
> > Load Address: 0x0320
> > Entry Point: 0x0320
> > Hash algo:crc32
> > Hash value: a99f6703
> > Hash algo:sha1
> > Hash value: 642b4e5d4bdab91260c07510ff9d1b13ada03add
> >Verifying Hash Integrity ... crc32+ sha1+ OK
&g
[PATCH 4/4] spl: atf: Reduce SPL code size
Previous fix commit increases code size of a few bytes. This minor
rework finally reduces SPL size of about 64-72 bytes (tested with
buildman on several aarch64 boards).
Signed-off-by: Massimo Pegorer
---
common/spl/spl_atf.c | 42 +++---
1 file changed, 19 insertions(+), 23 deletions(-)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 0d8db2d14e..fa79f73be2 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -209,7 +209,19 @@ static void spl_enter_atf(uintptr_t bl31_entry, uintptr_t
bl32_entry,
atf_entry(bl31_params, (void *)fdt_addr);
}
-static int spl_fit_images_find(void *blob, int os)
+static void spl_fit_images_get_entry(void *blob, int node, uintptr_t *entry_p)
+{
+ ulong val;
+
+ if (fit_image_get_entry(blob, node, ))
+ if (fit_image_get_load(blob, node, ))
+ return;
+
+ debug("%s: entry point 0x%lx\n", __func__, val);
+ *entry_p = val;
+}
+
+static int spl_fit_images_get_os_entry(void *blob, int os, uintptr_t *entry_p)
{
int parent, node, ndepth = 0;
const void *data;
@@ -231,41 +243,28 @@ static int spl_fit_images_find(void *blob, int os)
if (!data)
continue;
- if (genimg_get_os_id(data) == os)
- return node;
+ if (genimg_get_os_id(data) == os) {
+ spl_fit_images_get_entry(blob, node, entry_p);
+ return 0;
+ }
};
return -FDT_ERR_NOTFOUND;
}
-void spl_fit_images_get_entry(void *blob, int node, uintptr_t *entry_p)
-{
- ulong val;
-
- if (fit_image_get_entry(blob, node, ))
- if (fit_image_get_load(blob, node, ))
- return;
-
- debug("%s: entry point 0x%lx\n", __func__, val);
- *entry_p = val;
-}
-
void spl_invoke_atf(struct spl_image_info *spl_image)
{
uintptr_t bl32_entry = 0;
uintptr_t bl33_entry = CONFIG_TEXT_BASE;
void *blob = spl_image->fdt_addr;
uintptr_t platform_param = (uintptr_t)blob;
- int node;
/*
* Find (in /fit-images) the TEE binary entry point address
* (or load address if entry point is missing) and pass it as
* the BL3-2 entry point. This is optional.
*/
- node = spl_fit_images_find(blob, IH_OS_TEE);
- if (node >= 0)
- spl_fit_images_get_entry(blob, node, _entry);
+ spl_fit_images_get_os_entry(blob, IH_OS_TEE, _entry);
/*
* Find (in /fit-images) the U-Boot binary entry point address
@@ -273,10 +272,7 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
* the BL3-3 entry point.
* This will need to be extended to support Falcon mode.
*/
-
- node = spl_fit_images_find(blob, IH_OS_U_BOOT);
- if (node >= 0)
- spl_fit_images_get_entry(blob, node, _entry);
+ spl_fit_images_get_os_entry(blob, IH_OS_U_BOOT, _entry);
/*
* If ATF_NO_PLATFORM_PARAM is set, we override the platform
--
2.34.1
[PATCH 3/4] spl: atf: Fix potential but not occurring bug
Bug: function spl_fit_images_get_entry returns uninitialized variable
val if both fit_image_get_entry() and fit_image_get_load() fail (note
that both of them do not set val on failure). Fix: use val only if
entry or load address has been retrieved successfully.
Note: in real world a failure of fit_image_get_load() will make current
SPL flow to break on loading images, see spl_load_fit_image(), before
entering spl_invoke_atf().
Signed-off-by: Massimo Pegorer
---
common/spl/spl_atf.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 3d022ed4e7..0d8db2d14e 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -238,17 +238,16 @@ static int spl_fit_images_find(void *blob, int os)
return -FDT_ERR_NOTFOUND;
}
-uintptr_t spl_fit_images_get_entry(void *blob, int node)
+void spl_fit_images_get_entry(void *blob, int node, uintptr_t *entry_p)
{
ulong val;
- int ret;
- ret = fit_image_get_entry(blob, node, );
- if (ret)
- ret = fit_image_get_load(blob, node, );
+ if (fit_image_get_entry(blob, node, ))
+ if (fit_image_get_load(blob, node, ))
+ return;
debug("%s: entry point 0x%lx\n", __func__, val);
- return val;
+ *entry_p = val;
}
void spl_invoke_atf(struct spl_image_info *spl_image)
@@ -266,7 +265,7 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
*/
node = spl_fit_images_find(blob, IH_OS_TEE);
if (node >= 0)
- bl32_entry = spl_fit_images_get_entry(blob, node);
+ spl_fit_images_get_entry(blob, node, _entry);
/*
* Find (in /fit-images) the U-Boot binary entry point address
@@ -277,7 +276,7 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
node = spl_fit_images_find(blob, IH_OS_U_BOOT);
if (node >= 0)
- bl33_entry = spl_fit_images_get_entry(blob, node);
+ spl_fit_images_get_entry(blob, node, _entry);
/*
* If ATF_NO_PLATFORM_PARAM is set, we override the platform
--
2.34.1
[PATCH 2/4] image: fit: Improve functions description comments
Load and entry addresses are returned in ulong variables, which are 32 or 64 bit depending on architecture. Specify that on failure these functions do not set memory pointed by load / entry argument: this detail is relavant for correct functions usage. Signed-off-by: Massimo Pegorer --- boot/image-fit.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/boot/image-fit.c b/boot/image-fit.c index 3cc556b727..7e87a513e7 100644 --- a/boot/image-fit.c +++ b/boot/image-fit.c @@ -869,10 +869,11 @@ static int fit_image_get_address(const void *fit, int noffset, char *name, * fit_image_get_load() - get load addr property for given component image node * @fit: pointer to the FIT format image header * @noffset: component image node offset - * @load: pointer to the uint32_t, will hold load address + * @load: pointer to ulong, will hold load address * * fit_image_get_load() finds load address property in a given component * image node. If the property is found, its value is returned to the caller. + * Otherwise, on failure, *load will be left untouched. * * returns: * 0, on success @@ -887,14 +888,11 @@ int fit_image_get_load(const void *fit, int noffset, ulong *load) * fit_image_get_entry() - get entry point address property * @fit: pointer to the FIT format image header * @noffset: component image node offset - * @entry: pointer to the uint32_t, will hold entry point address - * - * This gets the entry point address property for a given component image - * node. + * @entry: pointer to ulong, will hold entry point address * * fit_image_get_entry() finds entry point address property in a given - * component image node. If the property is found, its value is returned - * to the caller. + * component image node. If the property is found, its value is returned + * to the caller. Otherwise, on failure, *entry will be left untouched. * * returns: * 0, on success -- 2.34.1
[PATCH 1/4] spl: atf: Improve comments and code readability
Rename bl31_entry static function to avoid name clash with its first
argument. Fix spaces misuse. Describe code accurately: load address
is used if getting entry point address fails, and not if addresses
differ. Remove not up-to-date comment about BL3-2 usage.
Signed-off-by: Massimo Pegorer
---
common/spl/spl_atf.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 2c10252834..3d022ed4e7 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -189,10 +189,10 @@ static inline void raw_write_daif(unsigned int daif)
typedef void (*atf_entry_t)(struct bl31_params *params, void *plat_params);
-static void bl31_entry(uintptr_t bl31_entry, uintptr_t bl32_entry,
- uintptr_t bl33_entry, uintptr_t fdt_addr)
+static void spl_enter_atf(uintptr_t bl31_entry, uintptr_t bl32_entry,
+ uintptr_t bl33_entry, uintptr_t fdt_addr)
{
- atf_entry_t atf_entry = (atf_entry_t)bl31_entry;
+ atf_entry_t atf_entry = (atf_entry_t)bl31_entry;
void *bl31_params;
if (CONFIG_IS_ENABLED(ATF_LOAD_IMAGE_V2))
@@ -240,7 +240,7 @@ static int spl_fit_images_find(void *blob, int os)
uintptr_t spl_fit_images_get_entry(void *blob, int node)
{
- ulong val;
+ ulong val;
int ret;
ret = fit_image_get_entry(blob, node, );
@@ -253,25 +253,25 @@ uintptr_t spl_fit_images_get_entry(void *blob, int node)
void spl_invoke_atf(struct spl_image_info *spl_image)
{
- uintptr_t bl32_entry = 0;
- uintptr_t bl33_entry = CONFIG_TEXT_BASE;
+ uintptr_t bl32_entry = 0;
+ uintptr_t bl33_entry = CONFIG_TEXT_BASE;
void *blob = spl_image->fdt_addr;
uintptr_t platform_param = (uintptr_t)blob;
int node;
/*
-* Find the OP-TEE binary (in /fit-images) load address or
-* entry point (if different) and pass it as the BL3-2 entry
-* point, this is optional.
+* Find (in /fit-images) the TEE binary entry point address
+* (or load address if entry point is missing) and pass it as
+* the BL3-2 entry point. This is optional.
*/
node = spl_fit_images_find(blob, IH_OS_TEE);
if (node >= 0)
bl32_entry = spl_fit_images_get_entry(blob, node);
/*
-* Find the U-Boot binary (in /fit-images) load addreess or
-* entry point (if different) and pass it as the BL3-3 entry
-* point.
+* Find (in /fit-images) the U-Boot binary entry point address
+* (or load address if entry point is missing) and pass it as
+* the BL3-3 entry point.
* This will need to be extended to support Falcon mode.
*/
@@ -281,17 +281,13 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
/*
* If ATF_NO_PLATFORM_PARAM is set, we override the platform
-* parameter and always pass 0. This is a workaround for
+* parameter and always pass 0. This is a workaround for
* older ATF versions that have insufficiently robust (or
* overzealous) argument validation.
*/
if (CONFIG_IS_ENABLED(ATF_NO_PLATFORM_PARAM))
platform_param = 0;
- /*
-* We don't provide a BL3-2 entry yet, but this will be possible
-* using similar logic.
-*/
- bl31_entry(spl_image->entry_point, bl32_entry,
- bl33_entry, platform_param);
+ spl_enter_atf(spl_image->entry_point, bl32_entry,
+ bl33_entry, platform_param);
}
--
2.34.1
[PATCH 0/4] spl: atf: Fix potential bug on getting FIT data
If both fit_image_get_entry() and fit_image_get_load() calls fail, an uninitialized variable value is passed to TF-A as BL3-2 and/or BL3-3 entry point in spl_invoke_atf(). In real world of current SPL flow this is not expected to occur because a fit_image_get_load() failure should break boot during images loading phase, and thus before entering spl_invoke_atf(). Update improve and fix comments. A minor rework slightly reduces SPL code size up to 72 bytes. Note: I am not enough confident about uintptr_t and ulong sizes matching within all architectures, otherwise straightforward pass of bl3x_entry reference to fit_image_get_xxx would be fine. Massimo Pegorer (4): spl: atf: Improve comments and code readability image: fit: Improve functions description comments spl: atf: Fix potential but not occurring bug spl: atf: Reduce SPL code size boot/image-fit.c | 12 +++ common/spl/spl_atf.c | 75 +++- 2 files changed, 38 insertions(+), 49 deletions(-) -- 2.34.1
[PATCH v2] binman: doc: fix reference tag placement for Logging section
Move BinmanLogging reference tag after section "Signing FIT container
with private key in an image" and just before section "Logging".
Remove meaningless line with incomplete sentence.
Fixes: 0f40e23fd22 ("binman: add documentation for binman sign option")
Signed-off-by: Massimo Pegorer
Reviewed-by: Heinrich Schuchardt
---
Changes in v2:
- Removed incomplete sentence (confirmed by Simon)
tools/binman/binman.rst | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index aeea33fddb..020988d955 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -1480,9 +1480,6 @@ as set in stone, so Binman will ensure it doesn't change.
Without this feature,
repacking an entry might cause it to disobey the original constraints provided
when it was created.
- Repacking an image involves
-
-.. _`BinmanLogging`:
Signing FIT container with private key in an image
--
@@ -1501,6 +1498,7 @@ If you want to sign and replace FIT container in place::
which will sign FIT container with private key and replace it immediately
inside your image.
+.. _`BinmanLogging`:
Logging
---
--
2.34.1
Re: [PATCH] binman: doc: fix reference tag placement for Logging section
Hi Simon, Heinrich,
Il giorno sab 9 set 2023 alle ore 15:52 Massimo Pegorer
ha scritto:
>
> Move BinmanLogging reference tag after section "Signing FIT container
> with private key in an image" and just before section "Logging".
>
> Fixes: 0f40e23fd22 ("binman: add documentation for binman sign option")
> Signed-off-by: Massimo Pegorer
>
> ---
> Note that at the end of section "Replacing files in an image" and just
> before section "Signing FIT container with private key in an image"
> there is a line which seems a typo or an incomplete sentence:
>
> Repacking an image involves
Any comment about this note? Should I remove this line in a v2?
Regards,
Massimo
> ---
> tools/binman/binman.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> index aeea33fddb..8945b19446 100644
> --- a/tools/binman/binman.rst
> +++ b/tools/binman/binman.rst
> @@ -1482,7 +1482,6 @@ when it was created.
>
> Repacking an image involves
>
> -.. _`BinmanLogging`:
>
> Signing FIT container with private key in an image
> --
> @@ -1501,6 +1500,7 @@ If you want to sign and replace FIT container in place::
> which will sign FIT container with private key and replace it immediately
> inside your image.
>
> +.. _`BinmanLogging`:
>
> Logging
> ---
> --
> 2.34.1
>
[PATCH] binman: doc: fix reference tag placement for Logging section
Move BinmanLogging reference tag after section "Signing FIT container
with private key in an image" and just before section "Logging".
Fixes: 0f40e23fd22 ("binman: add documentation for binman sign option")
Signed-off-by: Massimo Pegorer
---
Note that at the end of section "Replacing files in an image" and just
before section "Signing FIT container with private key in an image"
there is a line which seems a typo or an incomplete sentence:
Repacking an image involves
---
tools/binman/binman.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index aeea33fddb..8945b19446 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -1482,7 +1482,6 @@ when it was created.
Repacking an image involves
-.. _`BinmanLogging`:
Signing FIT container with private key in an image
--
@@ -1501,6 +1500,7 @@ If you want to sign and replace FIT container in place::
which will sign FIT container with private key and replace it immediately
inside your image.
+.. _`BinmanLogging`:
Logging
---
--
2.34.1
[PATCH] expo: Fix documentation reference
Fix typo: doc/develop/expo.rst instead of doc/developer/expo.rst Signed-off-by: Massimo Pegorer --- boot/expo_build.c | 6 +++--- include/expo.h| 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/boot/expo_build.c b/boot/expo_build.c index 22f62eb54b..702bf49890 100644 --- a/boot/expo_build.c +++ b/boot/expo_build.c @@ -209,7 +209,7 @@ static void list_strings(struct build_info *info) /** * menu_build() - Build a menu and add it to a scene * - * See doc/developer/expo.rst for a description of the format + * See doc/develop/expo.rst for a description of the format * * @info: Build information * @node: Node containing the menu description @@ -282,7 +282,7 @@ static int menu_build(struct build_info *info, ofnode node, struct scene *scn) /** * menu_build() - Build an expo object and add it to a scene * - * See doc/developer/expo.rst for a description of the format + * See doc/develop/expo.rst for a description of the format * * @info: Build information * @node: Node containing the object description @@ -318,7 +318,7 @@ static int obj_build(struct build_info *info, ofnode node, struct scene *scn) /** * scene_build() - Build a scene and all its objects * - * See doc/developer/expo.rst for a description of the format + * See doc/develop/expo.rst for a description of the format * * @info: Build information * @node: Node containing the scene description diff --git a/include/expo.h b/include/expo.h index 0b1d944a16..e8f7d7d6ff 100644 --- a/include/expo.h +++ b/include/expo.h @@ -667,7 +667,7 @@ int expo_apply_theme(struct expo *exp, ofnode node); * * Build a complete expo from a description in the provided devicetree. * - * See doc/developer/expo.rst for a description of the format + * See doc/develop/expo.rst for a description of the format * * @root: Root node for expo description * @expp: Returns the new expo -- 2.34.1
[PATCH v2 2/2] doc: rockchip: Update and improve info on rk3308, TPL and TF-A
Update and improve documentation about build steps for SoCs that require using TF-A and TPL binaries provided by Rockchip, such as rk3308. Add rk3308 boards case to rST document. Add ROCK Pi S in the list of supported boards. Minor page format improvements. Signed-off-by: Massimo Pegorer --- doc/README.rockchip | 10 +--- doc/board/rockchip/rockchip.rst | 43 +++-- 2 files changed, 36 insertions(+), 17 deletions(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index 52b5140eca..84caff8a24 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -38,16 +38,8 @@ Building (or you can use another cross compiler if you prefer) 2. To build RK3308 board: - - Get the rkbin - => git clone https://github.com/rockchip-linux/rkbin.git - - Compile U-Boot - => cd /path/to/u-boot - => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf - => make roc-cc-rk3308_defconfig - => make CROSS_COMPILE=aarch64-linux-gnu- all - => ./tools/mkimage -n rk3308 -T rksd -d /path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img - => cat spl/u-boot-spl.bin >> idbloader.img + See doc/board/rockchip/rockchip.rst 3. To build RK3399 board: diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index de9fe8e642..d0fa7a9c8f 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -53,6 +53,7 @@ List of mainline supported Rockchip boards: - Google Speedy (chromebook_speedy) - Amarula Vyasa-RK3288 (vyasa-rk3288) * rk3308 + - Radxa ROCK Pi S (rock-pi-s-rk3308) - Rockchip Evb-RK3308 (evb-rk3308) - Roc-cc-RK3308 (roc-cc-rk3308) * rk3326 @@ -142,6 +143,19 @@ To build TF-A: Specify the PLAT= with desired Rockchip platform to build TF-A for. +For SoCs whose TF-A code is not available as open source, use BL31 binary provided by Rockchip: + +.. code-block:: bash + +git clone --depth 1 https://github.com/rockchip-linux/rkbin + +TPL +^^^ + +For some SoCs U-Boot sources lack of support to inizialize DRAM. +In these cases, to get a fully functional image following :ref:`PackageWithTPLandSPL`, use DDR binary provided by Rockchip rkbin repository as ROCKCHIP_TPL when building U-Boot. +Otherwise, follow :ref:`PackageWithRockchipMiniloader`. + U-Boot ^^ @@ -172,6 +186,15 @@ To build rk3288 boards: make evb-rk3288_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- +To build rk3308 boards: + +.. code-block:: bash + +export BL31=../rkbin/bin/rk33/rk3308_bl31_v2.26.elf +export ROCKCHIP_TPL=../rkbin/bin/rk33/rk3308_ddr_589MHz_uartX_mY_v2.07.bin +make evb-rk3308_defconfig +make CROSS_COMPILE=aarch64-linux-gnu- + To build rk3328 boards: .. code-block:: bash @@ -218,11 +241,13 @@ To build rk3588 boards: Flashing +.. _`PackageWithTPLandSPL`: + 1. Package the image with U-Boot TPL/SPL -- + SD Card -^^^ +""""""" All Rockchip platforms (except rk3128 which doesn't use SPL) are now supporting a single boot image using binman. @@ -235,7 +260,7 @@ To write an image that boots from a SD card (assumed to be /dev/sda): sync eMMC - +"""" eMMC flash would probe on mmc0 in most of the Rockchip platforms. @@ -274,7 +299,7 @@ For Rockchip 32-bit platforms the U-Boot proper image is u-boot-dtb.img SPI -^^^ +""" Write u-boot-rockchip-spi.bin to offset 0 of SPI flash. @@ -286,8 +311,10 @@ Copy u-boot-rockchip-spi.bin into SD card and boot from SD: load mmc 1:1 $kernel_addr_r u-boot-rockchip-spi.bin sf update $fileaddr 0 $filesize +.. _`PackageWithRockchipMiniloader`: + 2. Package the image with Rockchip miniloader -- +^ Image package with Rockchip miniloader requires rkbin [1]. @@ -327,14 +354,14 @@ Note: 2. 0x20 is a load address and is an option for some platforms. 3. Package the RK3066 image with U-Boot TPL/SPL on NAND +^^^ Unlike later SoC models the rk3066 BootROM doesn't have SDMMC support. If all other boot options fail then it enters into a BootROM mode on the USB OTG port. This method loads TPL/SPL on NAND with U-Boot and kernel on SD card. SD Card -^^^ +""""""" U-Boot expects a GPT partition map and a boot directory structure with files on the SD card. @@ -369,7 +396,7 @@ To write a U-Boot image to the SD card (assumed to be /dev/sda): sync NAND - +"""" Bring device in BootROM mode: -- 2.34.1
[PATCH v2 1/2] rockchip: Kconfig: Enable external TPL binary for rk3308
There is no support to initialize DRAM on rk3308 SoC using U-Boot TPL or SPL, and therefore an external TPL binary must be used to package a bootable u-boot-rockchip.bin image. Default ROCKCHIP_EXTERNAL_TPL to yes if ROCKCHIP_RK3308. Remove useless TPL_SERIAL. Signed-off-by: Massimo Pegorer --- arch/arm/mach-rockchip/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index a279582f4f..3b044269bd 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -166,7 +166,6 @@ config ROCKCHIP_RK3308 imply SPL_SYSCON imply SPL_RAM imply SPL_SERIAL - imply TPL_SERIAL imply SPL_SEPARATE_BSS help The Rockchip RK3308 is a ARM-based Soc which embedded with quad @@ -436,7 +435,7 @@ config TPL_ROCKCHIP_COMMON_BOARD config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" - default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 + default y if ROCKCHIP_RK3308 || ROCKCHIP_RK3568 || ROCKCHIP_RK3588 help Some Rockchip SoCs require an external TPL to initialize DRAM. Enable this option and build with ROCKCHIP_TPL=/path/to/ddr.bin to -- 2.34.1
[PATCH v2 0/2] rockchip: Use an external TPL binary on RK3308
There is no support to initialize DRAM on rk3308 SoC using U-Boot TPL or SPL, and therefore an external TPL binary must be used to package a bootable u-boot-rockchip.bin image. Default ROCKCHIP_EXTERNAL_TPL to yes if ROCKCHIP_RK3308. Remove useless TPL_SERIAL. Doc add ROCK Pi S in the list of supported boards. Doc add info about usage of TF-A and TPL binaries provided by Rockchip. Doc add build steps for rk3308. Changes in v2: - Replace imply with default yes if ROCKCHIP_RK3308 - Redirect outdated README.rockchip to rockchip.rst for rk3308 info - Improve rockchip.rst document about usage of TF-A and TPL binaries Massimo Pegorer (2): rockchip: Kconfig: Enable external TPL binary for rk3308 doc: rockchip: Update and improve info on rk3308, TPL and TF-A arch/arm/mach-rockchip/Kconfig | 3 +-- doc/README.rockchip | 10 +--- doc/board/rockchip/rockchip.rst | 43 +++-- 3 files changed, 37 insertions(+), 19 deletions(-) -- 2.34.1
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Il giorno mar 5 set 2023 alle ore 20:16 Simon Glass
ha scritto:
>
> Hi Jonas,
>
> On Mon, 4 Sept 2023 at 10:52, Jonas Karlman wrote:
> >
> > Hi Massimo,
> >
> > On 2023-09-04 17:05, Massimo Pegorer wrote:
> > > Hi,
> > >
> > > Is there any way for binman to package FIT with U-Boot TF-A and
> > > OP-TEE, using bl32 binary provided by Rockchip as TEE?
> > >
> > > I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but
> > > binman failed.
> > >
> > > In my poor understanding of Python code, it seems binman accepts only
> > > ELF format or a binary format starting with optee_v1_header, but
> > > binaries provided by Rockchip in rkbin repository do not have this
> > > header.
> >
> > One way that I have used/tested before was to create a tee.elf version
> > using something like:
> >
> > $ aarch64-linux-gnu-objcopy -B aarch64 -I binary -O elf64-littleaarch64
> > xxx_bl32_vX.YZ.bin bl32.o
> > $ aarch64-linux-gnu-ld bl32.o -T tee.ld -o tee.elf
> >
> > tee.ld:
> >
> > ENTRY(_binary_bl32_bin_start);
> >
> > SECTIONS
> > {
> > . = 0x0840;
> > .data : {
> > *(.data)
> > }
> > }
> >
> >
> > And then make with TEE=tee.elf, however keep in mind that U-Boot may not
> > treat the memory region used by OP-TEE properly for aarch64.
> >
> > Regards,
> > Jonas
> >
> > >
> > > Thanks in advance for any hints!
>
> Should we do something to support a 'flat' binary in the tee-os entry type?
> For example, we could allow it if so long as a fixed load address is
> provided? It might be a bit of a hack though.
I do not know how much fixed is the load address and how much it
depends on SoC and OP-TEE build, instead.
I think it would be preferable if Rokchip will provide also the
tee-header_v2.bin, so that binman could extract load address info as
it does when parsing tee.bin.
Regards,
Massimo
> Regards,
> Simon
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Hi Jonas,
Il giorno lun 4 set 2023 alle ore 18:52 Jonas Karlman
ha scritto:
>
> Hi Massimo,
>
> On 2023-09-04 17:05, Massimo Pegorer wrote:
> > Hi,
> >
> > Is there any way for binman to package FIT with U-Boot TF-A and
> > OP-TEE, using bl32 binary provided by Rockchip as TEE?
> >
> > I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but
> > binman failed.
> >
> > In my poor understanding of Python code, it seems binman accepts only
> > ELF format or a binary format starting with optee_v1_header, but
> > binaries provided by Rockchip in rkbin repository do not have this
> > header.
>
> One way that I have used/tested before was to create a tee.elf version
> using something like:
>
> $ aarch64-linux-gnu-objcopy -B aarch64 -I binary -O elf64-littleaarch64
> xxx_bl32_vX.YZ.bin bl32.o
> $ aarch64-linux-gnu-ld bl32.o -T tee.ld -o tee.elf
>
> tee.ld:
>
> ENTRY(_binary_bl32_bin_start);
>
> SECTIONS
> {
> . = 0x0840;
> .data : {
> *(.data)
> }
> }
>
Thank you so much! I've been able to load and execute
rk3308_bl32_v2.05.bin using 0x0020 as load address instead of
0x0840 in the tee.ld. This is the value I found in
rkbin/RKTRUST/RK3308TRUST.ini.
Everything then goes smooth till kernel panic, but this can depends on
kernel build options I suspect (it is just a "random" kernel image I
had). I need to investigate more.
DDR V2.07 6ede97a868 wesley.yao 22/11/29-19:27:02
08
REG2C: 0x0034, 0x0034
In
589MHz
DDR3
Col=10 Bank=3 Row=15 Size=512MB
OUT: sdram_init finish.
U-Boot SPL 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
Trying to boot from MMC1
INFO:Preloader serial: 0
NOTICE: BL31: v1.3(release):0252d5c8f
NOTICE: BL31: Built : 07:51:11, Sep 28 2022
INFO:Lastlog: last=0x10, realtime=0x102000, size=0x2000
INFO:ARM GICv2 driver initialized
INFO:Using opteed sec cpu_context!
INFO:boot cpu mask: 1
INFO:plat_rockchip_pmu_init: pd status 0xe b
INFO:BL31: Initializing runtime services
INFO:BL31: Initializing BL32
I/TC:
I/TC: OP-TEE version: 3.13.0-651-gd84087907 #hisping.lin (gcc version
10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
10.2-2020.11 (arm-10.16))) #8 Fri Sep 16 16:15:04 CST 2022 aarch64
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x60
INFO:SPSR = 0x3c9
U-Boot 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
Model: Radxa ROCK Pi S
DRAM: 512 MiB (effective 510 MiB)
Core: 284 devices, 21 uclasses, devicetree: separate
MMC: mmc@ff48: 1, mmc@ff49: 0, mmc@ff4a: 2
Loading Environment from nowhere... OK
rockchip_dnl_key_pressed read board id failed
Net:
Error: ethernet@ff4e address not set.
No ethernet found.
Hit any key to stop autoboot: 0
** Booting bootflow 'mmc@ff48.bootdev.part_1' with script
4414108 bytes read in 189 ms (22.3 MiB/s)
## Loading kernel from FIT Image at 0068 ...
Using 'config-1' configuration
Trying 'kernel-1' kernel subimage
Description: ARM64 OpenWrt Linux-6.1.46
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x006800e8
Data Size:4379870 Bytes = 4.2 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x0320
Entry Point: 0x0320
Hash algo:crc32
Hash value: a99f6703
Hash algo:sha1
Hash value: 642b4e5d4bdab91260c07510ff9d1b13ada03add
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 0068 ...
Using 'config-1' configuration
Trying 'fdt-1' fdt subimage
Description: ARM64 OpenWrt radxa_rock-pi-s device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x00aad708
Data Size:32335 Bytes = 31.6 KiB
Architecture: AArch64
Hash algo:crc32
Hash value: 3d67cbee
Hash algo:sha1
Hash value: 82c778864784d98ae4150916adac497000e34c6a
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0xaad708
Working FDT set to aad708
Uncompressing Kernel Image
Loading Device Tree to 1df25000, end 1df2fe4e ... OK
Working FDT set to 1df25000
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd042]
[0.00] Linux version 6.1.46 (ubuntu@buildhost)
(aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23781-426752b38a)
12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP PREEMPT Fri Aug 25
20:22:05 2023
[0.00] Machine model: Radxa ROCK Pi S
[0.00] earlycon: uart8250 at MMIO32 0xff0a (options '')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] Zone ranges:
[0.00
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Il giorno lun 4 set 2023 alle ore 18:49 Simon Glass ha scritto: > > Hi Massimo, > > On Mon, 4 Sept 2023 at 09:05, Massimo Pegorer > wrote: > > > > Hi, > > > > Is there any way for binman to package FIT with U-Boot TF-A and > > OP-TEE, using bl32 binary provided by Rockchip as TEE? > > > > I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but > > binman failed. > > > > In my poor understanding of Python code, it seems binman accepts only > > ELF format or a binary format starting with optee_v1_header, but > > binaries provided by Rockchip in rkbin repository do not have this > > header. > > Yes that is correct. How would U-Boot know the load address of the TEE > fille? Hmm it seems to be a fixed address. Perhaps you could change > the rockchip-u-boot.dtsi file to make the 'tee-os' node a 'blobext' > node instead, then add a filename property in there with the name of > your file? Yes, I agree, it can not. But I was not complaining about binman, just wondering what I was missing, or why Rockchip binaries are lacking of optee_v1_header. It seems these binaries are in the format of tee-pager_v2.bin. I suspect the load address is the value of the ADDR field in the [BL32_OPTION] of rkbin/RKTRUST/RK33xxTRUST.ini file. That is 0x0840 except for RK3308 which has 0x0020. I will give it a try. Thanks. Regards, Massimo > > > > > Thanks in advance for any hints! > > Regards, > Simon
Binman how to build using Rockchip BL32 binary as OP-TEE
Hi, Is there any way for binman to package FIT with U-Boot TF-A and OP-TEE, using bl32 binary provided by Rockchip as TEE? I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but binman failed. In my poor understanding of Python code, it seems binman accepts only ELF format or a binary format starting with optee_v1_header, but binaries provided by Rockchip in rkbin repository do not have this header. Thanks in advance for any hints! Massimo
Re: [PATCH 1/2] rockchip: Use an external TPL binary on RK3308
Il giorno sab 2 set 2023 alle ore 18:32 Massimo Pegorer ha scritto: > > There is no support to initialize DRAM on RK3308 SoC using U-Boot > TPL and therefore an external TPL binary must be used to generate > a bootable u-boot-rockchip.bin image. > > Imply ROCKCHIP_EXTERNAL_TPL by default for RK3308 builds. Remove > useless TPL_SERIAL. > > Signed-off-by: Massimo Pegorer > --- > arch/arm/mach-rockchip/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index a279582f4f..e8584de258 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -159,6 +159,7 @@ config ROCKCHIP_RK3308 > select SPL_ATF > select SPL_ATF_NO_PLATFORM_PARAM > select SPL_LOAD_FIT > + imply ROCKCHIP_EXTERNAL_TPL > imply ROCKCHIP_COMMON_BOARD > imply SPL_ROCKCHIP_COMMON_BOARD > imply SPL_CLK > @@ -166,7 +167,6 @@ config ROCKCHIP_RK3308 > imply SPL_SYSCON > imply SPL_RAM > imply SPL_SERIAL > - imply TPL_SERIAL > imply SPL_SEPARATE_BSS > help > The Rockchip RK3308 is a ARM-based Soc which embedded with quad > -- > 2.34.1 > I've just noticed that Jonas followed a different approach for RK3568 and RK3588: config ROCKCHIP_EXTERNAL_TPL bool "Use external TPL binary" default y if ROCKCHIP_RK3568 || ROCKCHIP_RK3588 Is any one preferred? I slightly prefer the one I've done, as it gives a terse picture of what a SoC select/imply in a single place. Of course I can change it in a V2, if Jonas way is preferred, and to have a single congruent way to do things. Thanks. Regards, Massimo
Re: [PATCH 2/2] doc: rockchip: Update and complete info about RK3308
Hi Johan, Il giorno dom 3 set 2023 alle ore 10:36 Johan Jonker ha scritto: > > > > On 9/2/23 18:32, Massimo Pegorer wrote: > > Update documentation about build steps for RK3308, using an external > > TPL. Add RK3308 case to rST document. Add ROCK Pi S in the list of > > supported boards. > > > > Signed-off-by: Massimo Pegorer > > --- > > doc/README.rockchip | 4 ++-- > > doc/board/rockchip/rockchip.rst | 10 ++ > > 2 files changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/doc/README.rockchip b/doc/README.rockchip > > index 52b5140eca..cfbd858c3b 100644 > > --- a/doc/README.rockchip > > +++ b/doc/README.rockchip > > @@ -38,16 +38,16 @@ Building > > (or you can use another cross compiler if you prefer) > > > > > 2. To build RK3308 board: > > + > > - Get the rkbin > > => git clone https://github.com/rockchip-linux/rkbin.git > > > > - Compile U-Boot > > => cd /path/to/u-boot > > => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf > > + => export > > ROCKCHIP_TPL=/path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin > > => make roc-cc-rk3308_defconfig > > => make CROSS_COMPILE=aarch64-linux-gnu- all > > - => ./tools/mkimage -n rk3308 -T rksd -d > > /path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img > > - => cat spl/u-boot-spl.bin >> idbloader.img > > > > Hi Massimo, > > The text in this document should moved to doc/board/rockchip. > This paragraph above is therefor redundant, so it can be removed I think. > > Johan OK, thanks, I agree on redundant. But I do not know if everything here - other than RK3308 info - has already been moved to doc/board/rockchip.rst, so to remove it. On the other hand, leaving as it is (i.e. not updated) would be misleading. If everybody agree I can remove it in a V2, or otherwise just delete the RK3308 section. Massimo > > 3. To build RK3399 board: > > > > diff --git a/doc/board/rockchip/rockchip.rst > > b/doc/board/rockchip/rockchip.rst > > index de9fe8e642..b38c3d3136 100644 > > --- a/doc/board/rockchip/rockchip.rst > > +++ b/doc/board/rockchip/rockchip.rst > > @@ -53,6 +53,7 @@ List of mainline supported Rockchip boards: > > - Google Speedy (chromebook_speedy) > > - Amarula Vyasa-RK3288 (vyasa-rk3288) > > * rk3308 > > + - Radxa ROCK Pi S (rock-pi-s-rk3308) > > - Rockchip Evb-RK3308 (evb-rk3308) > > - Roc-cc-RK3308 (roc-cc-rk3308) > > * rk3326 > > @@ -172,6 +173,15 @@ To build rk3288 boards: > > make evb-rk3288_defconfig > > make CROSS_COMPILE=arm-linux-gnueabihf- > > > > +To build rk3308 boards: > > + > > +.. code-block:: bash > > + > > +export BL31=../rkbin/bin/rk33/rk3308_bl31_vX.YZ.elf > > +export > > ROCKCHIP_TPL=../rkbin/bin/rk33/rk3308_ddr_589MHz_uart0_m0_vX.YZ.bin > > +make evb-rk3308_defconfig > > +make CROSS_COMPILE=aarch64-linux-gnu- > > + > > To build rk3328 boards: > > > > .. code-block:: bash
[PATCH 2/2] configs: rockchip: add DOS_PARTITION to RK3308 boards defconfig
Without DOS_PARTITION support U-Boot is not able to boot an OS stored into an SD card with MBR partitions table. This is still a quite common case, so add DOS_PARTITION (only for U-Boot proper build) to Rockchip RK3308 EVB and Firefly roc-rk3308-cc board: they are the only RK boards missing of DOS_PARTITION. Signed-off-by: Massimo Pegorer --- configs/evb-rk3308_defconfig| 2 +- configs/roc-cc-rk3308_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig index a13a809c1e..c6472a2c9c 100644 --- a/configs/evb-rk3308_defconfig +++ b/configs/evb-rk3308_defconfig @@ -47,7 +47,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_SLEEP is not set -# CONFIG_DOS_PARTITION is not set +# CONFIG_SPL_DOS_PARTITION is not set # CONFIG_ISO_PARTITION is not set CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 CONFIG_SPL_OF_CONTROL=y diff --git a/configs/roc-cc-rk3308_defconfig b/configs/roc-cc-rk3308_defconfig index 9a789b212f..ca92b8f744 100644 --- a/configs/roc-cc-rk3308_defconfig +++ b/configs/roc-cc-rk3308_defconfig @@ -47,7 +47,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_SLEEP is not set -# CONFIG_DOS_PARTITION is not set +# CONFIG_SPL_DOS_PARTITION is not set # CONFIG_ISO_PARTITION is not set CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 CONFIG_SPL_OF_CONTROL=y -- 2.34.1
[PATCH 1/2] configs: rockchip: add DOS_PARTITION to rock-pi-s defconfig
Without DOS_PARTITION support U-Boot is not able to boot an OS stored into an SD card with MBR partitions table. This is still a quite common case so add DOS_PARTITION (only for U-Boot proper build) to ROCK Pi S defconfig. Reported-by: Jayantajit Gogoi Signed-off-by: Massimo Pegorer --- configs/rock-pi-s-rk3308_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig index cc3274a98b..1c1fdc6611 100644 --- a/configs/rock-pi-s-rk3308_defconfig +++ b/configs/rock-pi-s-rk3308_defconfig @@ -48,7 +48,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_SLEEP is not set -# CONFIG_DOS_PARTITION is not set +# CONFIG_SPL_DOS_PARTITION is not set # CONFIG_ISO_PARTITION is not set CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 CONFIG_SPL_OF_CONTROL=y -- 2.34.1
[PATCH 2/2] doc: rockchip: Update and complete info about RK3308
Update documentation about build steps for RK3308, using an external TPL. Add RK3308 case to rST document. Add ROCK Pi S in the list of supported boards. Signed-off-by: Massimo Pegorer --- doc/README.rockchip | 4 ++-- doc/board/rockchip/rockchip.rst | 10 ++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index 52b5140eca..cfbd858c3b 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -38,16 +38,16 @@ Building (or you can use another cross compiler if you prefer) 2. To build RK3308 board: + - Get the rkbin => git clone https://github.com/rockchip-linux/rkbin.git - Compile U-Boot => cd /path/to/u-boot => export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf + => export ROCKCHIP_TPL=/path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin => make roc-cc-rk3308_defconfig => make CROSS_COMPILE=aarch64-linux-gnu- all - => ./tools/mkimage -n rk3308 -T rksd -d /path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img - => cat spl/u-boot-spl.bin >> idbloader.img 3. To build RK3399 board: diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index de9fe8e642..b38c3d3136 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -53,6 +53,7 @@ List of mainline supported Rockchip boards: - Google Speedy (chromebook_speedy) - Amarula Vyasa-RK3288 (vyasa-rk3288) * rk3308 + - Radxa ROCK Pi S (rock-pi-s-rk3308) - Rockchip Evb-RK3308 (evb-rk3308) - Roc-cc-RK3308 (roc-cc-rk3308) * rk3326 @@ -172,6 +173,15 @@ To build rk3288 boards: make evb-rk3288_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- +To build rk3308 boards: + +.. code-block:: bash + +export BL31=../rkbin/bin/rk33/rk3308_bl31_vX.YZ.elf +export ROCKCHIP_TPL=../rkbin/bin/rk33/rk3308_ddr_589MHz_uart0_m0_vX.YZ.bin +make evb-rk3308_defconfig +make CROSS_COMPILE=aarch64-linux-gnu- + To build rk3328 boards: .. code-block:: bash -- 2.34.1
[PATCH 1/2] rockchip: Use an external TPL binary on RK3308
There is no support to initialize DRAM on RK3308 SoC using U-Boot TPL and therefore an external TPL binary must be used to generate a bootable u-boot-rockchip.bin image. Imply ROCKCHIP_EXTERNAL_TPL by default for RK3308 builds. Remove useless TPL_SERIAL. Signed-off-by: Massimo Pegorer --- arch/arm/mach-rockchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index a279582f4f..e8584de258 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -159,6 +159,7 @@ config ROCKCHIP_RK3308 select SPL_ATF select SPL_ATF_NO_PLATFORM_PARAM select SPL_LOAD_FIT + imply ROCKCHIP_EXTERNAL_TPL imply ROCKCHIP_COMMON_BOARD imply SPL_ROCKCHIP_COMMON_BOARD imply SPL_CLK @@ -166,7 +167,6 @@ config ROCKCHIP_RK3308 imply SPL_SYSCON imply SPL_RAM imply SPL_SERIAL - imply TPL_SERIAL imply SPL_SEPARATE_BSS help The Rockchip RK3308 is a ARM-based Soc which embedded with quad -- 2.34.1
[PATCH 0/2] rockchip: Use an external TPL binary on RK3308
There is no support to initialize DRAM on RK3308 SoC using U-Boot TPL and therefore an external TPL binary must be used to generate a bootable u-boot-rockchip.bin image. Imply ROCKCHIP_EXTERNAL_TPL by default for RK3308. Remove useless TPL_SERIAL for RK3308. Update documentation about build steps for RK3308. Add ROCK Pi S in the list of supported boards. Massimo Pegorer (2): rockchip: Use an external TPL binary on RK3308 doc: rockchip: Update and complete info about RK3308 arch/arm/mach-rockchip/Kconfig | 2 +- doc/README.rockchip | 4 ++-- doc/board/rockchip/rockchip.rst | 10 ++ 3 files changed, 13 insertions(+), 3 deletions(-) -- 2.34.1
U-Boot logging
Hi I had a trip into U-Boot logging and I am quite confused. I read the documentation at doc/develop/logging.rst and had a look at source code in log.h log.c printk.h Kconfig and other files, but the picture is still quite foggy and, let's say, 'complicated'. The documentation does not mention at all CONFIG_LOGLEVEL, but pr_xxx macros rely on its value (and then on log_xxx macros). While log_xxx definitions, instead, depends on CONFIG_LOG and other CONFIG_LOG_XXX values. It is not clear when/if pr_xxx and/or log/log_xxx should be used. Is any preferred and why? Is there a specific reason to keep both? Neither the constrains and relations between Kconfig variables are clear. CONFIG_LOGLEVEL and CONFIG_LOG are in different section of menuconfig: Console and Logging. The semantic is also a little bit different: for LOGLEVEL, values smaller than the console loglevel will be compiled in; for LOG_MAX_LEVEL, instead, any value higher than this will be ignored. The doc states that 'If CONFIG_LOG is not set, then no logging will be available'. But a few lines below 'If logging is disabled, the default behaviour is to output any message at level LOGL_INFO and below'. This sounds inconsistent to me. I see a lot of To Do tasks listed in logging.rst, like converting some other logging statements like debug() and error(). I wonder if something can be improved, and in case how: I could commit some of my spare time. Thanks. Regards. Massimo
Re: Problem upon startup with halted USB device on RaspberryPi 4
Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit <
harry.waschk...@conplement.de> ha scritto:
> Am 13.08.23 um 19:37 schrieb Michal Suchánek:
> > Hello,
>
> Hi again,
>
> thanks for your answers!
>
> > On Sat, Aug 12, 2023 at 08:31:56PM +0200, Massimo Pegorer wrote:
> >> Hi Harry,
> >>
> >> Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit <
> >> harry.waschk...@conplement.de> ha scritto:
> >>
> >>> Hi,
> >>>
> >>> I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE
> >>> module (EM7455) is attached via an PCIe-to-USB adapter.
> >>> The boot image I use gets built by Yocto with the help of poky
> >>> (kirkstone) and meta-raspberry (beside a few other layers) which
> >>> incorporates U-Boot 22.01.
> >>>
> >>> When I apply power to the board it will come up until scanning USB
> >>> devices (for potential boot devices), but then throw a BUG end reset
> the
> >>> board.
> >>
> >>
> >> Do you need USB boot devices? If not, I would build U-Boot without USB
> >> support.
>
> Yeah, I am aware of that possibility, thanks for your hint anyway, but ...
>
> >
> > That would be great workaround, However, enabling a device should not
> > break the board. If that's the case the driver is clearly broken.
>
Of course, mine is just a workaround, nothing more. To make hardware combo
working, and just for specific use case (if I properly understood). Not for
typical
usage of rPi. About the driver: can be broken, or the root cause can be the
PCIe-to-USB bridge misbehaving, or both.
> Also rPi typically uses USB keyboard for boot-time input which makes the
> > workaround not so great.
For U-Boot booting phase, or later on for Linux or other OS boot phase? I do
not know too much about this specific board.
> ... but as Michal pointed out, the rpi - at least rpi 400 - should be
> considered to regularly use USB devices for normal operation, so
> completely disabling USB is not really an option here.
>
Disabling USB support in U-Boot (via defconfig) would not affect Linux (or
other OS) USB functions in any way, if this is what you are concerning about
with "completely disabling USB".
My USB knowledge is too little to point the finger on the problem but my
> guess still is that U-Boot is only using a part of Linux's USB driver
> for bringing up devices, thereby omitting some of the error handling
> which would be done in the Linux kernel in some (maybe concurrent) way.
>
I suggest to address this email also directly to maintainers:
./scripts/get_maintainer.pl drivers/usb/host/xhci-ring.c
Bin Meng (maintainer:USB xHCI)
Marek Vasut (maintainer:USB)
u-boot@lists.denx.de (open list)
Regards,
Massimo
And given the bunch of boot messages "WARN halted endpoint." with the
> patch I mentioned, chances are that the patch is either not the right
> one or at least incomplete.
> But the general approach to ignore halted endpoints appears completely
> reasonable to me when it avoids a hanging of boot looping system.
> I cannot tell whether there should instead be some cleverer treatment to
> get such a device running ("Reset Endpoint" from what I read), though.
>
> Regards,
> Harry
>
> > Thanks
> >
> > Michal
> >
> >>
> >> Massimo
> >>
> >>> This continues as long as the modem is unplugged.
> >>> The exact error message is:
> >>>
> >>> scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB
> >>> anyway.
> >>> Unexpected XHCI event TRB, skipping... (3af519b0 0004 1300
> >>> 02008401)
> >>> BUG at drivers/usb/host/xhci-ring.c:503/abort_td()!
> >>> BUG!
> >>> resetting ...
> >>>
> >>> Some internet research brought up a patch (1) for
> >>> drivers/usb/host/xhci-ring.c where halted devices simply get ignored
> >>> during enumeration:
> >>>
> >>> diff --git a/drivers/usb/host/xhci-ring.c
> b/drivers/usb/host/xhci-ring.c
> >>> index acf437104a..6d995f446e 100644
> >>> --- a/drivers/usb/host/xhci-ring.c
> >>> +++ b/drivers/usb/host/xhci-ring.c
> >>> @@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl,
> >>> struct xhci_ring *ep_ring,
> >>> puts("WARN waiting for error on ep to be cleared\n");
> >>> return -EINVAL;
> >>> case EP_STATE_HALTED:
> >>> - puts("WARN halted endpoint, queueing URB anyway.\n");
> >>> + put
Re: Problem upon startup with halted USB device on RaspberryPi 4
Hi Harry,
Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit <
harry.waschk...@conplement.de> ha scritto:
> Hi,
>
> I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE
> module (EM7455) is attached via an PCIe-to-USB adapter.
> The boot image I use gets built by Yocto with the help of poky
> (kirkstone) and meta-raspberry (beside a few other layers) which
> incorporates U-Boot 22.01.
>
> When I apply power to the board it will come up until scanning USB
> devices (for potential boot devices), but then throw a BUG end reset the
> board.
Do you need USB boot devices? If not, I would build U-Boot without USB
support.
Massimo
> This continues as long as the modem is unplugged.
> The exact error message is:
>
> scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB
> anyway.
> Unexpected XHCI event TRB, skipping... (3af519b0 0004 1300
> 02008401)
> BUG at drivers/usb/host/xhci-ring.c:503/abort_td()!
> BUG!
> resetting ...
>
> Some internet research brought up a patch (1) for
> drivers/usb/host/xhci-ring.c where halted devices simply get ignored
> during enumeration:
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index acf437104a..6d995f446e 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl,
> struct xhci_ring *ep_ring,
> puts("WARN waiting for error on ep to be cleared\n");
> return -EINVAL;
> case EP_STATE_HALTED:
> - puts("WARN halted endpoint, queueing URB anyway.\n");
> + puts("WARN halted endpoint.\n");
> + return -EPIPE;
> case EP_STATE_STOPPED:
> case EP_STATE_RUNNING:
> debug("EP STATE RUNNING.\n");
>
> The driver file itself stems from the Linux sources, so I'm pretty sure
> that it is correct in that context.
> Even though I'm not really into USB stuff and therefore I cannot not
> really follow the discussion for the proposed change, in my eyes the
> patch could be reasonable for U-Boot nevertheless given that a) in my
> experience driver code is often used in a simplified way in U-Boot
> compared to Linux kernel, and b) it's all about board start-up only and
> not about full OS use with all bells, whistles and full error handling.
>
> Of course, I might be wrong while missing some important other use or
> corner cases, so I wanted to check here :-)
>
> At least, what I can say: with this patch I see a bunch of these warning
> messages but the board comes up and is usable in the end by Linux.
>
> fwiw: my internet search also showed another patch labelled in the first
> place "[PATCH] pi4: fix crash when issuing usb reset" (2) that didn't
> make it into the particular U-Boot 22.01 but was integrated right after
> that version in commit "Prepare v2022.04" with hash
> e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 (3).
> As I first hoped I could address my problem by just adding this patch I
> got promptly disappointed. The only thing I gained was to now get
> endless error messages followed by retries until I power-cycled the
> board (causing to start all over):
>
> USB XHCI 1.00
> scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB
> anyway.
> Unexpected XHCI event TRB, skipping... (3afd6b30 0004 1300
> 02008401)
> XHCI abort timeout
> WARN halted endpoint, queueing URB anyway.
> Unexpected XHCI event TRB, skipping... (3afd6b40 0004 1300
> 02008401)
> XHCI abort timeout
> WARN halted endpoint, queueing URB anyway.
> Unexpected XHCI event TRB, skipping... (3afd6b50 0004 1300
> 02008401)
> XHCI abort timeout
> WARN halted endpoint, queueing URB anyway.
> [...]
>
> To me it means that this specific PCIe-to-USB bridge might misbehave
> somehow,
> but the final question is: what are the odds to get that patch into
> official U-boot, or any other fix/quirk to make my hardware combo working?
>
> And also interesting: if I cannot hope for an upstream change, what
> potential risks I would have to accept when keeping my patch?
>
> Regards,
> Harry
>
> (1)
>
> https://linux-usb.vger.kernel.narkive.com/VW4VTVDU/patch-usb-host-xhci-fix-halted-endpoint-handling
> (2)
> https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51...@denx.de/T/
> (3)
>
> https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2
>
> --
> i.A. Harry Waschkeit
> Senior Embedded Engineer
> conplement AG
> Südwestpark 92
> 90449 Nürnberg
>
> Handelsregister: HRB 22863
> Registergericht: Nürnberg
> Vertreten durch: Britta Waligora und Thomas Wahle
> Vorsitzender des Aufsichtsrates: Lorenz von Schröder
>
>
Re: [PATCH 1/1] lmb: description lmb_is_reserved, lmb_is_reserved_flags
Hi, Il giorno sab 12 ago 2023 alle ore 19:49 Heinrich Schuchardt < heinrich.schucha...@canonical.com> ha scritto: > * provide a description for function lmb_is_reserved() > * improve the description of funciton lmb_is_reserved_flags() > > Signed-off-by: Heinrich Schuchardt > --- > include/lmb.h | 22 +++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/include/lmb.h b/include/lmb.h > index 07bf22144e..0365c9ef1f 100644 > --- a/include/lmb.h > +++ b/include/lmb.h > @@ -116,16 +116,32 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, > phys_size_t size, ulong align, > phys_addr_t max_addr); > phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t > size); > phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t addr); > + > +/** > + * lmb_is_reserved_flags() - test if address is in reserved region > lmb_is_reserved() > + * > + * The function checks if a reserved region comprising @addr exists. > + * flag bits set that are set in @flags. > line to be removed (cut and paste from lmb_is_reserved_flags() description) > + * > + * @lmb: the logical memory block struct > + * @addr: address to be tested > + * Return: 1 if reservation exists, 0 otherwise > + */ > int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr); > + > /** > - * lmb_is_reserved_flags - test if tha address is in reserved region with > a bitfield flag > + * lmb_is_reserved_flags() - test if address is in reserved region with > flag bits set > + * > + * The function checks if a reserved region comprising @addr exists which > has > + * all flag bits set which are set in @flags. > * > * @lmb: the logical memory block struct > * @addr: address to be tested > - * @flags: flags bitfied to be tested > - * Return: if not reserved or reserved without the requested flag > else 1 > + * @flags: bitmap with bits to be tested > + * Return: 1 if matching reservation exists, 0 otherwise > */ > int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t addr, int flags); > + > long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size); > > void lmb_dump_all(struct lmb *lmb); > -- > 2.40.1 > >
Re: [PATCH] pinctrl: Check pinconfig nodes pre-reloc status recursively
Hi Jonas,
Il giorno sab 5 ago 2023 alle ore 13:11 Jonas Karlman ha
scritto:
> Pinconfig nodes normally bind recursively with PINCTRL_FULL and
> PINCONF_RECURSIVE enabled. However, during U-Boot proper pre-relocation
> any node marked with e.g. bootph-all will not bind unless its parent is
> also marked for pre-reloc.
>
> group1 {
> pinconf1 {
> bootph-all;
> };
> };
>
> This cause the following warning message to be shown during U-Boot
> proper pre-reloc stage on Rockchip RK3568 devices.
>
> ns16550_serial serial@fe66: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
>
> Check pinconfig nodes pre-reloc status recursively to fix this and to
> make pinconfig_post_bind work same at both U-Boot proper pre-reloc and
> at TPL/SPL stage.
>
> Signed-off-by: Jonas Karlman
> ---
> drivers/pinctrl/pinctrl-uclass.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-uclass.c
> b/drivers/pinctrl/pinctrl-uclass.c
> index 73dd7b1038bb..fe2ba5021a78 100644
> --- a/drivers/pinctrl/pinctrl-uclass.c
> +++ b/drivers/pinctrl/pinctrl-uclass.c
> @@ -100,6 +100,22 @@ static int pinctrl_select_state_full(struct udevice
> *dev, const char *statename)
> return 0;
> }
>
> +static bool ofnode_pre_reloc_recursive(ofnode parent)
> +{
> + ofnode child;
> +
> + if (ofnode_pre_reloc(parent))
> + return true;
> +
> + if (CONFIG_IS_ENABLED(PINCONF_RECURSIVE)) {
> + ofnode_for_each_subnode(child, parent)
> + if (ofnode_pre_reloc_recursive(child))
> + return true;
> + }
> +
> + return false;
> +}
> +
> /**
> * pinconfig_post_bind() - post binding for PINCONFIG uclass
> * Recursively bind its children as pinconfig devices.
> @@ -119,7 +135,7 @@ static int pinconfig_post_bind(struct udevice *dev)
>
> dev_for_each_subnode(node, dev) {
> if (pre_reloc_only &&
> - !ofnode_pre_reloc(node))
> + !ofnode_pre_reloc_recursive(node))
> continue;
> /*
> * If this node has "compatible" property, this is not
> --
> 2.41.0
>
I've fixed the same issue for Rockchip RK3308 a couple of days ago with
patch [1]
as part of the series [2], adding required nodes with 'bootph-some-ram'
property
into *-u-boot.dtsi.
With your solution, is there any risk not to warn about any pin that should
be configured
but is not due to any ancestor missing in device tree (in pre-reloc boot
phase, I mean)?
Thanks.
Massimo
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230803110813.175956-4-massimo.pegorer+...@gmail.com/
[2]
https://patchwork.ozlabs.org/project/uboot/cover/20230803110813.175956-1-massimo.pegorer+...@gmail.com/
[PATCH 3/3] dts: rockchip: rk3308: Avoid warning for serial probe on prereloc
Make device tree complete and consistent for pre relocation phase. Some
nodes are missing, causing warnings to be issued on serial port probing
during pre relocation phase (uclass_get_device_by_phandle_id fails when
called by pinctrl_select_state_full: none of these failures is fatal
nor causing issues). Add to *-u-boot.dtsi all required nodes with the
'bootph-some-ram' attribute.
Signed-off-by: Massimo Pegorer
---
arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
index 61415559b7..d88dee8057 100644
--- a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
@@ -13,3 +13,30 @@
{
bootph-all;
};
+
+ {
+ bootph-some-ram;
+
+ uart0 {
+ bootph-some-ram;
+ };
+ rtc {
+ bootph-some-ram;
+ };
+};
+
+_xfer {
+ bootph-some-ram;
+};
+
+_cts {
+ bootph-some-ram;
+};
+
+_rts {
+ bootph-some-ram;
+};
+
+_32k {
+ bootph-some-ram;
+};
--
2.34.1
[PATCH 2/3] clk: rockchip: rk3308: Support reading UART rate and clock registers
Add support to read RK3308 registers used to configure UART clocks, and
thus to get UART rate and baudrate. This fixes clock_get_rate returning
error on serial device probing. Moreover, there is no need anymore to
use 'clock-frequency' property for UART nodes in *-u-boot.dtsi files
for all cases where UART is not inited by U-Boot proper or by SPL o by
TPL code but by a preliminary external boot phase (for Rock PI S, UART
is inited by external TPL).
Signed-off-by: Massimo Pegorer
---
arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 2 -
arch/arm/include/asm/arch-rk3308/cru_rk3308.h | 15 +
drivers/clk/rockchip/clk_rk3308.c | 59 +++
3 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
index 09694b41e5..61415559b7 100644
--- a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
@@ -12,6 +12,4 @@
{
bootph-all;
- clock-frequency = <2400>;
- status = "okay";
};
diff --git a/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
b/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
index 86c906bb0e..84b63e4d56 100644
--- a/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
+++ b/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
@@ -189,6 +189,21 @@ enum {
DCLK_VOP_DIV_SHIFT = 0,
DCLK_VOP_DIV_MASK = 0xff,
+ /* CRU_CLKSEL_CON10 */
+ /* CRU_CLKSEL_CON13 */
+ /* CRU_CLKSEL_CON16 */
+ /* CRU_CLKSEL_CON19 */
+ /* CRU_CLKSEL_CON22 */
+ CLK_UART_PLL_SEL_SHIFT = 13,
+ CLK_UART_PLL_SEL_MASK = 0x7 << CLK_UART_PLL_SEL_SHIFT,
+ CLK_UART_PLL_SEL_DPLL = 0,
+ CLK_UART_PLL_SEL_VPLL0,
+ CLK_UART_PLL_SEL_VPLL1,
+ CLK_UART_PLL_SEL_480M,
+ CLK_UART_PLL_SEL_24M,
+ CLK_UART_DIV_CON_SHIFT = 0,
+ CLK_UART_DIV_CON_MASK = 0x1f << CLK_UART_DIV_CON_SHIFT,
+
/* CRU_CLK_SEL25_CON */
/* CRU_CLK_SEL26_CON */
/* CRU_CLK_SEL27_CON */
diff --git a/drivers/clk/rockchip/clk_rk3308.c
b/drivers/clk/rockchip/clk_rk3308.c
index d27673c454..d0a3f65446 100644
--- a/drivers/clk/rockchip/clk_rk3308.c
+++ b/drivers/clk/rockchip/clk_rk3308.c
@@ -451,6 +451,58 @@ static ulong rk3308_pwm_set_clk(struct clk *clk, uint hz)
return rk3308_pwm_get_clk(clk);
}
+static ulong rk3308_uart_get_clk(struct clk *clk)
+{
+ struct rk3308_clk_priv *priv = dev_get_priv(clk->dev);
+ struct rk3308_cru *cru = priv->cru;
+ u32 div, pll_sel, con, con_id, parent;
+
+ switch (clk->id) {
+ case SCLK_UART0:
+ con_id = 10;
+ break;
+ case SCLK_UART1:
+ con_id = 13;
+ break;
+ case SCLK_UART2:
+ con_id = 16;
+ break;
+ case SCLK_UART3:
+ con_id = 19;
+ break;
+ case SCLK_UART4:
+ con_id = 22;
+ break;
+ default:
+ printf("do not support this uart interface\n");
+ return -EINVAL;
+ }
+
+ con = readl(>clksel_con[con_id]);
+ pll_sel = (con & CLK_UART_PLL_SEL_MASK) >> CLK_UART_PLL_SEL_SHIFT;
+ div = (con & CLK_UART_DIV_CON_MASK) >> CLK_UART_DIV_CON_SHIFT;
+
+ switch (pll_sel) {
+ case CLK_UART_PLL_SEL_DPLL:
+ parent = priv->dpll_hz;
+ break;
+ case CLK_UART_PLL_SEL_VPLL0:
+ parent = priv->vpll0_hz;
+ break;
+ case CLK_UART_PLL_SEL_VPLL1:
+ parent = priv->vpll0_hz;
+ break;
+ case CLK_UART_PLL_SEL_24M:
+ parent = OSC_HZ;
+ break;
+ default:
+ printf("do not support this uart pll sel\n");
+ return -EINVAL;
+ }
+
+ return DIV_TO_RATE(parent, div);
+}
+
static ulong rk3308_vop_get_clk(struct clk *clk)
{
struct rk3308_clk_priv *priv = dev_get_priv(clk->dev);
@@ -813,6 +865,13 @@ static ulong rk3308_clk_get_rate(struct clk *clk)
case SCLK_EMMC_SAMPLE:
rate = rk3308_mmc_get_clk(clk);
break;
+ case SCLK_UART0:
+ case SCLK_UART1:
+ case SCLK_UART2:
+ case SCLK_UART3:
+ case SCLK_UART4:
+ rate = rk3308_uart_get_clk(clk);
+ break;
case SCLK_I2C0:
case SCLK_I2C1:
case SCLK_I2C2:
--
2.34.1
[PATCH 1/3] clk: rockchip: rk3308: Fix ordering between masking and shifting
As per definitions of masks and shift offsets in cru_rk3308.h, values read from registers must be first masked and then shifted. By the way, this fix is binary invariant, because in all of fixed cases the shift offset is zero. Signed-off-by: Massimo Pegorer --- drivers/clk/rockchip/clk_rk3308.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/clk/rockchip/clk_rk3308.c b/drivers/clk/rockchip/clk_rk3308.c index 64f33587e2..d27673c454 100644 --- a/drivers/clk/rockchip/clk_rk3308.c +++ b/drivers/clk/rockchip/clk_rk3308.c @@ -150,7 +150,7 @@ static ulong rk3308_i2c_get_clk(struct clk *clk) } con = readl(>clksel_con[con_id]); - div = con >> CLK_I2C_DIV_CON_SHIFT & CLK_I2C_DIV_CON_MASK; + div = (con & CLK_I2C_DIV_CON_MASK) >> CLK_I2C_DIV_CON_SHIFT; return DIV_TO_RATE(priv->dpll_hz, div); } @@ -314,7 +314,7 @@ static ulong rk3308_saradc_get_clk(struct clk *clk) u32 div, con; con = readl(>clksel_con[34]); - div = con >> CLK_SARADC_DIV_CON_SHIFT & CLK_SARADC_DIV_CON_MASK; + div = (con & CLK_SARADC_DIV_CON_MASK) >> CLK_SARADC_DIV_CON_SHIFT; return DIV_TO_RATE(OSC_HZ, div); } @@ -342,7 +342,7 @@ static ulong rk3308_tsadc_get_clk(struct clk *clk) u32 div, con; con = readl(>clksel_con[33]); - div = con >> CLK_SARADC_DIV_CON_SHIFT & CLK_SARADC_DIV_CON_MASK; + div = (con & CLK_SARADC_DIV_CON_MASK) >> CLK_SARADC_DIV_CON_SHIFT; return DIV_TO_RATE(OSC_HZ, div); } @@ -385,7 +385,7 @@ static ulong rk3308_spi_get_clk(struct clk *clk) } con = readl(>clksel_con[con_id]); - div = con >> CLK_SPI_DIV_CON_SHIFT & CLK_SPI_DIV_CON_MASK; + div = (con & CLK_SPI_DIV_CON_MASK) >> CLK_SPI_DIV_CON_SHIFT; return DIV_TO_RATE(priv->dpll_hz, div); } @@ -429,7 +429,7 @@ static ulong rk3308_pwm_get_clk(struct clk *clk) u32 div, con; con = readl(>clksel_con[29]); - div = con >> CLK_PWM_DIV_CON_SHIFT & CLK_PWM_DIV_CON_MASK; + div = (con & CLK_PWM_DIV_CON_MASK) >> CLK_PWM_DIV_CON_SHIFT; return DIV_TO_RATE(priv->dpll_hz, div); } -- 2.34.1
[PATCH 0/3] rockchip: rk3308: Fix two minor UART warnings
Two minor issues arise as warning during boot phases once log features and CONFIG_LOG_ERROR_RETURN are enabled: - clk_get_rate() return err (SPL, pre relocation and U-Boot proper phases) - uclass_get_device_by_phandle_id() return err (pre relocation phase only) Both issues are not fatal and do not cause any functional problem, anyway they are fixed with these patches. Moreover, the support added in RK3308 clock driver to get UARTs rate makes 'clock-frequency' property useless in RK3308 based boards *-u-boot.dtsi files: due to the fact that UART is inited by an external TPL, in other boot phases (SPL, U-Boot proper) there is no need to know UART clock from DT but get it just reading how external TPL has configured SoC registers. s() returning err=-2 U-Boot SPL 2023.07-00560-gf2090b144c (Jul 27 2023 - 16:27:11 +0200) Trying to boot from MMC1 INFO:Preloader serial: 0 NOTICE: BL31: v1.3(release):30f1405 NOTICE: BL31: Built : 17:08:28, Sep 23 2019 INFO:Lastlog: last=0x10, realtime=0x102000, size=0x2000 INFO:ARM GICv2 driver initialized INFO:Using opteed sec cpu_context! INFO:boot cpu mask: 1 INFO:plat_rockchip_pmu_init: pd status 0xe b INFO:BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x60 INFO:SPSR = 0x3c9 clk_get_rate() returning err=-2 pinctrl_select_state_full() ns16550_serial serial@ff0a: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full() ns16550_serial serial@ff0a: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full() ns16550_serial serial@ff0a: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2023.07-00560-gf2090b144c (Jul 27 2023 - 16:27:11 +0200) Model: Radxa ROCK Pi S DRAM: 512 MiB (effective 510 MiB) clk_get_rate() returning err=-2 Core: 287 devices, 23 uclasses, devicetree: separate MMC: mmc@ff48: 1, mmc@ff49: 0, mmc@ff4a: 2 Massimo Pegorer (3): clk: rockchip: rk3308: Fix ordering between masking and shifting clk: rockchip: rk3308: Support reading UART rate and clock registers dts: rockchip: rk3308: Avoid warning for serial probe on prereloc arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 29 +++- arch/arm/include/asm/arch-rk3308/cru_rk3308.h | 15 drivers/clk/rockchip/clk_rk3308.c | 69 +-- 3 files changed, 106 insertions(+), 7 deletions(-) -- 2.34.1
[PATCH 2/2] rockchip: spl: Drop out of scope debug message related to uart init
Debug uart is no more inited in board_init_f function: remove this
debug message from board_init_f. If an earliest-as-possible message
after debug uart initialization is needed, enable DEBUG_UART_ANNOUNCE
Kconfig option, instead.
Signed-off-by: Massimo Pegorer
---
arch/arm/mach-rockchip/spl.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index a6396b3c42..87280e2ba7 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -112,17 +112,6 @@ void board_init_f(ulong dummy)
{
int ret;
-#ifdef CONFIG_DEBUG_UART
- /*
-* Debug UART can be used from here if required:
-*
-* printch('a');
-* printhex8(0x1234);
-* printascii("string");
-*/
- debug("\nspl:debug uart enabled in %s\n", __func__);
-#endif
-
board_early_init_f();
ret = spl_early_init();
--
2.34.1
[PATCH 1/2] rockchip: spl: Drop useless call to debug_uart_init
Since commit 0dba45864b2a ("arm: Init the debug UART") function
debug_uart_init is called in crt files _main before calling
board_init_f. Therefore, there is no need to call it again
inside board_init_f implementation in arm/mach-rockchip/spl.c.
Signed-off-by: Massimo Pegorer
---
arch/arm/mach-rockchip/spl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 30be640425..a6396b3c42 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -116,12 +116,10 @@ void board_init_f(ulong dummy)
/*
* Debug UART can be used from here if required:
*
-* debug_uart_init();
* printch('a');
* printhex8(0x1234);
* printascii("string");
*/
- debug_uart_init();
debug("\nspl:debug uart enabled in %s\n", __func__);
#endif
--
2.34.1
[PATCH 0/2] Drop useless call to debug_uart_init
Since commit 0dba45864b2a ("arm: Init the debug UART") function
debug_uart_init is called in crt files _main before calling
board_init_f.
Therefore, there is no need to call it again inside board_init_f
implementation as was done in arch/arm/mach-rockchip/spl.c.
Remove also debug message related to debug uart initializazion
in board_init_f. If an earliest-as-possible message after debug
uart initialization is needed, enable DEBUG_UART_ANNOUNCE Kconfig
option, instead.
Massimo Pegorer (2):
rockchip: spl: Drop useless call to debug_uart_init
rockchip: spl: Drop out of scope debug message related to uart init
arch/arm/mach-rockchip/spl.c | 13 -
1 file changed, 13 deletions(-)
--
2.34.1
[PATCH] mkimage: fit: Support signed configurations in 'auto' FITs
Extend support for signing in auto-generated (-f auto) FIT. Previously, it was possible to get signed 'images' subnodes in the FIT using options -g and -o together with -f auto. This patch allows signing 'configurations' subnodes instead of 'images' ones (which are hashed), using option -f auto-conf instead of -f auto. Adding also -K and -r options, will add public key to file with required = "conf" property. Summary: -f auto => FIT with crc32 images -f auto -g ... -o ... => FIT with signed images -f auto-conf -g ... -o ... => FIT with sha1 images and signed confs Example: FIT with kernel, two device tree files, and signed configurations; public key (needed to verify signatures) is added to u-boot.dtb with required = "conf" property. mkimage -f auto-conf -A arm -O linux -T kernel -C none -a 43e0 \ -e 0 -d vmlinuz -b /path/to/first.dtb -b /path/to/second.dtb \ -k /folder/with/key-files -g keyname -o sha256,rsa4096 \ -K u-boot.dtb -r kernel.itb Example: Add public key with required = "conf" property to u-boot.dtb without needing to sign anything. This will also create a useless FIT named unused.itb. mkimage -f auto-conf -d /dev/null -k /folder/with/key-files \ -g keyname -o sha256,rsa4096 -K u-boot.dtb -r unused.itb Signed-off-by: Massimo Pegorer --- The commit includes: patch for adding the new feature to mkimage tool; updated man page, with description of the new feature and examples, plus fixes to wrong/misleading information; test for all of the three flavours of auto-FIT (crc32 images, signed images, sha1 hashed images and signed configurations). doc/mkimage.1 | 119 +++- test/py/tests/test_fit_auto_signed.py | 195 ++ tools/fit_image.c | 75 ++ tools/imagetool.h | 10 +- tools/mkimage.c | 21 ++- 5 files changed, 353 insertions(+), 67 deletions(-) create mode 100644 test/py/tests/test_fit_auto_signed.py diff --git a/doc/mkimage.1 b/doc/mkimage.1 index 353ea8b2f7..d8727ec73c 100644 --- a/doc/mkimage.1 +++ b/doc/mkimage.1 @@ -22,7 +22,8 @@ mkimage \- generate images for U-Boot .SY mkimage .RI [ option\~ .\|.\|.\&] .BI \-f\~ image-tree-source-file\c -.RB | auto +.RB | auto\c +.RB | auto-conf .I image-file-name .YS . @@ -296,9 +297,9 @@ FIT. See for details on using external data. . .TP -\fB\-f \fIimage-tree-source-file\fR | \fBauto +\fB\-f \fIimage-tree-source-file\fR | \fBauto\fR | \fBauto-conf .TQ -\fB\-\-fit \fIimage-tree-source-file\fR | \fBauto +\fB\-\-fit \fIimage-tree-source-file\fR | \fBauto\fR | \fBauto-conf Image tree source file that describes the structure and contents of the FIT image. .IP @@ -317,7 +318,25 @@ and options may be used to specify the image to include in the FIT and its attributes. No .I image-tree-source-file -is required. +is required. The +.BR \-g , +.BR \-o , +and +.B \-k +or +.B \-G +options may be used to get \(oqimages\(cq signed subnodes in the generated +auto FIT. Instead, to get \(oqconfigurations\(cq signed subnodes and +\(oqimages\(cq hashed subnodes, pass +.BR "\-f auto-conf". +In this case +.BR \-g , +.BR \-o , +and +.B \-k +or +.B \-G +are mandatory options. . .TP .B \-F @@ -348,16 +367,16 @@ for use with signing, and a certificate necessary when embedding it into another device tree using .BR \-K . .I name -defaults to the value of the signature node's \(oqkey-name-hint\(cq property, -but may be overridden using -.BR \-g . +is the value of the signature node's \(oqkey-name-hint\(cq property. . .TP .BI \-G " key-file" .TQ .BI \-\-key\-file " key-file" Specifies the private key file to use when signing. This option may be used -instead of \-k. +instead of \-k. Useful when the private key file basename does not match +\(oqkey-name-hint\(cq value. But note that it may lead to unexpected results +when used together with -K and/or -k options. . .TP .BI \-K " key-destination" @@ -373,49 +392,50 @@ CONFIG_OF_CONTROL in U-Boot. .BI \-g " key-name-hint" .TQ .BI \-\-key\-name\-hint " key-name-hint" -Overrides the signature node's \(oqkey-name-hint\(cq property. This is -especially useful when signing an image with -.BR "\-f auto" . -This is the -.I name -part of the key. The directory part is set by -.BR \-k . -This option also indicates that the images included in the FIT should be signed. -If this option is specified, then +Specifies the value of signature node \(oqkey-name-hint\(cq property for +an automatically generated FIT image. It makes sense only when used with +.B "\-f auto" +or +.BR "\-f auto-conf". +This option also indicates that the images or configurations included in +the FIT should be signed. If this option is specified, then .B \-o must be specified as well. . .TP -.BI \-o " crypto&quo
