Re: [PATCH] cmd: pxe: add alias devicetree-overlay for fdtoverlays
On Tue, Sep 20, 2022 at 7:30 PM Edoardo Tomelleri wrote: > > Hello Neil, > > > Concerning the alias name, can you specify in the patch the link to the > > Boot Loader Specification ? And probably update the PXE doc but reusing > > the same wording. > I'm not sure I understand what you mean about the PXE doc, is it better if the grep ^fdt doc/README.pxe fdtoverlays [...] - if this label is chosen, use tftp to retrieve the DT fdt - if this label is chosen, use tftp to retrieve the fdt blob fdtdir - if this label is chosen, use tftp to retrieve a fdt blob > devicetree and devicetree-overlay keywords have the same description as > fdt and fdtoverlays instead of just a reference, or you are you referring to > the > what I've added to distro.rst, like examples? The PXE doc already mentions > required environment variables, so there is not much left to add. > Thanks, > Edoardo
Re: [PATCH] rockchip: rk3399: boot_devices: fix eMMC node name
On Mon, Jul 18, 2022 at 5:19 PM Quentin Schulz
wrote:
>
> On 7/11/22 20:22, Xavier Drudis Ferran wrote:
> > El Mon, Jul 11, 2022 at 04:15:33PM +0200, Quentin Schulz deia:
> >> From: Quentin Schulz
> >>
> >> When idbloader.img is flashed on the eMMC, the SPL still tries to load
> >> from SPI-NOR first.
> >>
> >> This is due to an incorrect look-up in the Device Tree. Since commit
> >> 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
> >> node name (but not label) changed from sdhci@fe33 to mmc@fe33
> >> meaning U-Boot SPL is not looking for the correct node name anymore and
> >> fails to find the "same-as-spl" node when eMMC is the medium from which
> >> the SPL booted.
> >>
> >
> > Yes, I also saw that. I changed and tested it at some time, but since there
> > were other changes, I hesitate to send a Tested by for your patch. FWIW:
> >
> > Reviewed-by: Xavier Drudis Ferran
> >
> >
> >> Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
> >> Cc: Quentin Schulz
> >> Signed-off-by: Quentin Schulz
> >> ---
> >>
> >> Sorry for resend, was not yet subscribed.
> >>
> >> arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> >> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> >> index 01a05599cd..de11a3fa30 100644
> >> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> >> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> >> @@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >> #define GRF_BASE 0xff77
> >>
> >> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> >> -[BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> >> +[BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
> >> [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
> >> [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
> >> };
> >> @@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
> >> const char *ofpath;
> >> } spl_boot_devices_tbl[] = {
> >> { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> >> -{ BOOT_DEVICE_MMC2, "/sdhci@fe33" },
> >> +{ BOOT_DEVICE_MMC2, "/mmc@fe33" },
> >> { BOOT_DEVICE_SPI, "/spi@ff1d" },
> >
> > Not related to this patch, but I also changed "/spi@ff1d" ->
> > "/spi@ff1d/flash@0".
> > Not sure whether it needs to be different in both arrays in some case for
> > some reason.
> >
>
please apply this
Tested-by: Lapkin Artem
> Thanks for the heads up, it seems that our board was the only (upstream)
> one impacted by this oversight because it's the only one reading
> u-boot,spl-boot-device DT property that is set using this table.
>
> See patch here:
> https://lore.kernel.org/u-boot/20220715151552.953654-2-foss+ub...@0leil.net/
>
> You can add your Suggested-by: I forgot to add it before sending.
>
please apply this too, i have send same patch for right spi flash node
name before
Suggested-by: Lapkin Artem
Tested-by: Lapkin Artem
> Thanks!
> Quentin
Re: [PATCH] rockchip: rk3399: boot_devices: fix eMMC node name
Yes ! need to apply this patch
dts was changed
grep @fe33 arch/arm/dts/*.dtsi
arch/arm/dts/rk3399.dtsi:sdhci: mmc@fe33 {
same need to change boot_devices in rk3399.c to /mmc@fe32
Reviewed-by: Artem Lapkin
Tested-by: Artem Lapkin
On Tue, Jul 12, 2022 at 2:22 AM Xavier Drudis Ferran wrote:
>
> El Mon, Jul 11, 2022 at 04:15:33PM +0200, Quentin Schulz deia:
> > From: Quentin Schulz
> >
> > When idbloader.img is flashed on the eMMC, the SPL still tries to load
> > from SPI-NOR first.
> >
> > This is due to an incorrect look-up in the Device Tree. Since commit
> > 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
> > node name (but not label) changed from sdhci@fe33 to mmc@fe33
> > meaning U-Boot SPL is not looking for the correct node name anymore and
> > fails to find the "same-as-spl" node when eMMC is the medium from which
> > the SPL booted.
> >
>
> Yes, I also saw that. I changed and tested it at some time, but since there
> were other changes, I hesitate to send a Tested by for your patch. FWIW:
>
> Reviewed-by: Xavier Drudis Ferran
>
>
> > Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
> > Cc: Quentin Schulz
> > Signed-off-by: Quentin Schulz
> > ---
> >
> > Sorry for resend, was not yet subscribed.
> >
> > arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> > b/arch/arm/mach-rockchip/rk3399/rk3399.c
> > index 01a05599cd..de11a3fa30 100644
> > --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> > +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> > @@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define GRF_BASE 0xff77
> >
> > const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > - [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> > + [BROM_BOOTSOURCE_EMMC] = "/mmc@fe33",
> > [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
> > [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
> > };
> > @@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device)
> > const char *ofpath;
> > } spl_boot_devices_tbl[] = {
> > { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> > - { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
> > + { BOOT_DEVICE_MMC2, "/mmc@fe33" },
> > { BOOT_DEVICE_SPI, "/spi@ff1d" },
>
> Not related to this patch, but I also changed "/spi@ff1d" ->
> "/spi@ff1d/flash@0".
> Not sure whether it needs to be different in both arrays in some case for
> some reason.
>
> > };
> >
> > --
> > 2.36.1
> >
Re: [PATCH v2] image-board: fix wrong implementation ram disk address setup from cmdline
On Tue, Jan 18, 2022 at 3:47 AM Tom Rini wrote:
>
> On Thu, Nov 25, 2021 at 11:08:59AM +0800, Artem Lapkin wrote:
>
> > Problem
> >
> > Wrong implementation logic: ramdisk cmdline image address always ignored!
> > Next block { rd_addr = hextoul(select, NULL) } unusable for raw initrd.
> >
> > We have unbootable raw initrd images because, select_ramdisk for raw
> > initrd images ignore submited select addr and setup rd_datap value to 0
> >
> > Signed-off-by: Artem Lapkin
> > Reviewed-by: Simon Glass
> > ---
> > V2 changes
> > _ rebase to master
> > _ from
> > https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
> > ---
> > boot/image-board.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/boot/image-board.c b/boot/image-board.c
> > index bf8817165c..87a8f07432 100644
> > --- a/boot/image-board.c
> > +++ b/boot/image-board.c
> > @@ -334,7 +334,7 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> >
> > if (select) {
> > ulong default_addr;
> > - bool done = true;
> > + bool done = false;
> >
> > if (CONFIG_IS_ENABLED(FIT)) {
> > /*
> > @@ -352,13 +352,13 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> > _uname_config)) {
> > debug("* ramdisk: config '%s' from image at
> > 0x%08lx\n",
> > fit_uname_config, rd_addr);
> > + done = true;
> > } else if (fit_parse_subimage(select, default_addr,
> > _addr,
> > _uname_ramdisk)) {
> > debug("* ramdisk: subimage '%s' from image
> > at 0x%08lx\n",
> > fit_uname_ramdisk, rd_addr);
> > - } else {
> > - done = false;
> > + done = true;
> > }
> > }
> > if (!done) {
>
> I think we still need this? Can you please confirm and if so rebase to
> master again, sorry, thanks!
i have check master which have new commit
621158d106fe53fbb2d786d9d19dff44ad1baf91
no need for this state !!
Author: Tom Rini
Date: Mon Dec 20 09:36:32 2021 -0500
Revert "image: Remove #ifdefs from select_ramdisk()"
This reverts commit f33a2c1bd0fb371511a485cac1f182ba50db51be.
This causes a crash on some platforms as seen here:
https://lore.kernel.org/r/f153017b-c41a-0d32-67b9-f288e695f...@baylibre.com/
Reported-by: Neil Armstrong
Signed-off-by: Tom Rini
PS: about crash problem maybe its same reason may be need try apply my
patch and no need reverts commit
f33a2c1bd0fb371511a485cac1f182ba50db51be.
>
> --
> Tom
Re: [PATCH v5 25/29] image: Remove #ifdefs from select_ramdisk()
hi Neil > Revert "image: Remove #ifdefs from select_ramdisk()" > This reverts commit f33a2c1bd0fb371511a485cac1f182ba50db51be. > > This causes a crash on some platforms as seen here: > https://lore.kernel.org/r/f153017b-c41a-0d32-67b9-f288e695f...@baylibre.com/ Maybe the next patch was the solution for your problem ? https://patchwork.ozlabs.org/project/uboot/patch/20211125030859.2896352-1-...@khadas.com/
Re: [PATCH v2] image-board: fix wrong implementation ram disk address setup from cmdline
On Tue, Jan 18, 2022 at 3:47 AM Tom Rini wrote:
>
> On Thu, Nov 25, 2021 at 11:08:59AM +0800, Artem Lapkin wrote:
>
> > Problem
> >
> > Wrong implementation logic: ramdisk cmdline image address always ignored!
> > Next block { rd_addr = hextoul(select, NULL) } unusable for raw initrd.
> >
> > We have unbootable raw initrd images because, select_ramdisk for raw
> > initrd images ignore submited select addr and setup rd_datap value to 0
> >
> > Signed-off-by: Artem Lapkin
> > Reviewed-by: Simon Glass
> > ---
> > V2 changes
> > _ rebase to master
> > _ from
> > https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
> > ---
> > boot/image-board.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/boot/image-board.c b/boot/image-board.c
> > index bf8817165c..87a8f07432 100644
> > --- a/boot/image-board.c
> > +++ b/boot/image-board.c
> > @@ -334,7 +334,7 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> >
> > if (select) {
> > ulong default_addr;
> > - bool done = true;
> > + bool done = false;
> >
> > if (CONFIG_IS_ENABLED(FIT)) {
> > /*
> > @@ -352,13 +352,13 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> > _uname_config)) {
> > debug("* ramdisk: config '%s' from image at
> > 0x%08lx\n",
> > fit_uname_config, rd_addr);
> > + done = true;
> > } else if (fit_parse_subimage(select, default_addr,
> > _addr,
> > _uname_ramdisk)) {
> > debug("* ramdisk: subimage '%s' from image
> > at 0x%08lx\n",
> > fit_uname_ramdisk, rd_addr);
> > - } else {
> > - done = false;
> > + done = true;
> > }
> > }
> > if (!done) {
>
> I think we still need this? Can you please confirm and if so rebase to
> master again, sorry, thanks!
i need to check master and test it again - i'll replay soon tnx
>
> --
> Tom
Re: [PATCH v2] cmd: pxe_utils: sysboot: add label override support
On Sat, Nov 13, 2021 at 9:09 PM Amjad Ouled-Ameur wrote: > > This will allow consumers to choose a pxe label at runtime instead of > having to prompt the user. One good use-case for this, is choosing > whether or not to apply a dtbo depending on the hardware configuration. > e.g: for TI's AM335x EVM, it would be convenient to apply a particular > dtbo only when the J9 jumper is on PRUSS mode. To achieve this, the > pxe menu should have 2 labels, one with the dtbo and the other without, > then the "pxe_label_override" env variable should point to the label with > the dtbo at runtime only when the jumper is on PRUSS mode. > > This change can be used for different use-cases and bring more > flexibilty to consumers who use sysboot/pxe_utils. > > if "pxe_label_override" is set but does not exist in the pxe menu, > the code should fallback to the default label if given, and no failure > is returned but rather a warning message. > > > Signed-off-by: Amjad Ouled-Ameur Reviewed-by: Artem Lapkin Good and useful idea! why still not accepted ?! Regards, Art
Re: [PATCH v2 0/2] env: setenv add resolve value option
On Mon, Nov 22, 2021 at 4:52 PM Wolfgang Denk wrote:
>
> Dear Artem,
>
> In message
> you
> wrote:
> > > >
> > > > next examples just demonstrate how its works for already defined env
> > > > variables which contain other variables (like storred env variables)
> > >
> > > Which next examples?
> >
> > Usage examples (from commit message):
> >
> > => setenv a hello; setenv b world; setenv c '${a} ${b}'
> > => setenv -r d '${c}! ${a}...'
> > => printenv d
> > d=hello world! hello...
>
> This is a very simple example, and I showed you how you can solve
> this one by just omitting the apostrophes:
>
> => setenv a hello; setenv b world; setenv c ${a} ${b}
> => setenv d ${c}! ${a}...
> => printenv d
> d=hello world! hello...
>
sure i know it and its easy, but we still have some misunderstanding,
and i will try explain again our problem
our problem (TASK)
we have:
some env variables which already defined and we totally dont know
about content ( for example its was improved by `env import` or loaded
from env storage and "setenv a hello; setenv b world; setenv c '${a}
${b}'; setenv d '${c}! ${a}...' ;" just example how emulate this env
state )
we need:
setup/resolve env variable for example from d (and need resolve all
sub included vars)
=> setenv -r e $d
=> printenv e
=> e=hello world! hello...
please explain how we can get it without -r (deep resolve option) via
standard way ?
>
> I _think_ what you actually have in mind is something like this:
>
> => setenv a hello
> => setenv b world
> => setenv c '${a} ${b}'
> => setenv a goodbye
> => setenv b sunshine
>
> something to set d to: '${c}! ${a}...'
>
> => printenv d
>
> Here my simple approach does not show what you want to have:
>
> => setenv a hello
> => setenv b world
> => setenv c ${a} ${b}
> => setenv a goodbye
> => setenv b sunshine
> => setenv d ${c}! ${a}...
> => printenv d
> d=hello world! goodbye...
>
> That's because here evaluation takes place at assignment, but you
> want it when used - but being recursive here is neither a good idea
> nor standard.
>
> How would you do it in a standard posix shell? You would have to
> use "eval", like that:
>
> $ a=hello
> $ b=world
> $ c='${a} ${b}'
> $ a=goodbye
> $ b=sunshine
> $ d=$(eval echo $c)
> $ echo $d
> goodbye sunshine
>
> But please note that "eval" is _not_ recursive!!
>
> $ a='$b'
> $ eval echo $c
> $b sunshine
>
> And this is why I object against this patch.
>
> Oh, and in U-Boot you could write this as:
>
> => setenv a hello
> => setenv b world
> => setenv c '${a} ${b}'
> => setenv a goodbye
> => setenv b sunshine
> => setenv foo "setenv d ${c}! ${a}..."
> => run foo
> => printenv d
> d=goodbye sunshine! goodbye...
>
> And yes, here you have to be careful about using ' or " as there is
> no recursion like you might expect.
>
> So yes, it would be nice if we had "eval" (which will ocme with the
> hush update), and no, "eval" does not recurse either.
>
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Real computer scientists despise the idea of actual hardware. Hard-
> ware has limitations, software doesn't. It's a real shame that Turing
> machines are so poor at I/O.
Re: [PATCH v2 0/2] env: setenv add resolve value option
On Sat, Nov 20, 2021 at 8:36 PM Wolfgang Denk wrote:
>
> Dear Artem,
>
> In message
> you
> wrote:
> >
> > next examples just demonstrate how its works for already defined env
> > variables which contain other variables (like storred env variables)
>
> Which next examples?
>
> > sure I know about this ! see my prev message please .
>
> Which exact message are you referring to here?
>
> > Why not have this new opportunity ?
>
> I think the suggested code is adding more problems than it solves.
>
> > > have in mind, as you speak of "deep resolve". But then, I'm first
> > > missing an explanation (and documentation) of what "deep resolve"
> >
> > recurrent resolving for variables
>
> Your implementation of recursion has an arbiotrary and undocumented
> depth limit.
we can improve it if it will be really necessary
> Also, I cannot see a way to prevent resolving in case I
> want to keep something like "$foo" in the result.
>
`setenv -r` resolve only bracked vars like ${VAR} if u need keen some
$VAR just use it without brackets
or just use same setenv without -r option - whats a problem ?
> But that's to be expected from such a non-standard way.
>
we can use setenv with -r or without this option (default standard way)
again didn't see problems (setenv -r is special option especially for
non standard way )
> Why don't you stick with what "eval" in a standard shell does?
>
show me please how can i do it via standard way maybe i miss something ?
> > > actually means in this context, i. e. how many levels down you
> > > evaluat. Oh... the code has "int max_loop = 32;" - this is a
> >
> > i think its will be enough
>
> It is a reallybad habt to implement code with arbitrary limits, as
> it will blow into your face (or more likely that of an innocent
> user) rather sooner than later. It's even worse that this limit is
> nowhere documented.
>
> > 1) this option did not broke any exist compatibilities
> > 2) there we talk not only about uboot shell, same time will be useful
> > to have env_resolve for internal c usage, because env_set dont have
> > this feature
>
> I did not say that an "eval" like construct would not be useful.
> But uncontrolled recursion with an undocumented depth limit is
> a problem.
>
> > yes i'm informed about this plans (and think its happens not so
> > soon - but i provide some simple elegant solution already)
> > but again we dont have env_resolve for internal c usage which must be
> > very useful
>
> On the CLI, we use the "run" command to get the desired effect. Yes,
> this is neither perfect nor elegant. But you can use that in C code
> as well.
>
> > will be easy get useful features via simple solution ( deep resolve
> > all vars by one line )
>
> I understand what you want, but this is not a good way to solve the
> problem. I'd really rather see such efforts invested in helping
> Francis with the hush update - which will make such code unnecessary.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Success in marriage is not so much finding the right person as it is
> being the right person.
Re: [PATCH v2 0/2] env: setenv add resolve value option
On Sat, Nov 20, 2021 at 8:36 PM Wolfgang Denk wrote:
>
> Dear Artem,
>
> In message
> you
> wrote:
> >
> > next examples just demonstrate how its works for already defined env
> > variables which contain other variables (like storred env variables)
>
> Which next examples?
Usage examples (from commit message):
=> setenv a hello; setenv b world; setenv c '${a} ${b}'
=> setenv -r d '${c}! ${a}...'
=> printenv d
d=hello world! hello...
>
> > sure I know about this ! see my prev message please .
>
> Which exact message are you referring to here?
>
> > Why not have this new opportunity ?
>
> I think the suggested code is adding more problems than it solves.
>
> > > have in mind, as you speak of "deep resolve". But then, I'm first
> > > missing an explanation (and documentation) of what "deep resolve"
> >
> > recurrent resolving for variables
>
> Your implementation of recursion has an arbiotrary and undocumented
> depth limit. Also, I cannot see a way to prevent resolving in case I
> want to keep something like "$foo" in the result.
>
> But that's to be expected from such a non-standard way.
>
> Why don't you stick with what "eval" in a standard shell does?
>
> > > actually means in this context, i. e. how many levels down you
> > > evaluat. Oh... the code has "int max_loop = 32;" - this is a
> >
> > i think its will be enough
>
> It is a reallybad habt to implement code with arbitrary limits, as
> it will blow into your face (or more likely that of an innocent
> user) rather sooner than later. It's even worse that this limit is
> nowhere documented.
>
> > 1) this option did not broke any exist compatibilities
> > 2) there we talk not only about uboot shell, same time will be useful
> > to have env_resolve for internal c usage, because env_set dont have
> > this feature
>
> I did not say that an "eval" like construct would not be useful.
> But uncontrolled recursion with an undocumented depth limit is
> a problem.
>
> > yes i'm informed about this plans (and think its happens not so
> > soon - but i provide some simple elegant solution already)
> > but again we dont have env_resolve for internal c usage which must be
> > very useful
>
> On the CLI, we use the "run" command to get the desired effect. Yes,
> this is neither perfect nor elegant. But you can use that in C code
> as well.
>
> > will be easy get useful features via simple solution ( deep resolve
> > all vars by one line )
>
> I understand what you want, but this is not a good way to solve the
> problem. I'd really rather see such efforts invested in helping
> Francis with the hush update - which will make such code unnecessary.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Success in marriage is not so much finding the right person as it is
> being the right person.
Re: [PATCH v2 0/2] env: setenv add resolve value option
hi Wolfgang
tnx for your comments
On Fri, Nov 19, 2021 at 3:49 PM Wolfgang Denk wrote:
>
> Dear Artem,
>
> In message <2029043647.1251416-1-...@khadas.com> you wrote:
> > Add possibility setup env variable with additional resolving vars inside
> > value.
>
> Hm... if you want to evaluate variables, you should not prevent the
> shell to do that by enclosing them in apostrophes?
>
next examples just demonstrate how its works for already defined env
variables which contain other variables (like storred env variables)
> > Usage examples:
> >
> > => setenv a hello; setenv b world; setenv c '${a} ${b}'
> > => setenv -r d '${c}! ${a}...'
> > => printenv d
> > d=hello world! hello...
>
> Without any new code added:
>
sure I know about this ! see my prev message please .
> => setenv a hello; setenv b world; setenv c ${a} ${b}
> => setenv d ${c}! ${a}...
> => printenv d
> d=hello world! hello...
>
>
> I know very well that this does not cover all use cases you might
Why not have this new opportunity ?
> have in mind, as you speak of "deep resolve". But then, I'm first
> missing an explanation (and documentation) of what "deep resolve"
recurrent resolving for variables
> actually means in this context, i. e. how many levels down you
> evaluat. Oh... the code has "int max_loop = 32;" - this is a
i think its will be enough
> limitation mentioned nowhere. And are you really sure this is a
> clever idea? I am not convinced. If we do something like this, we
> should not invent a new non-standard way. We should implement
I believe it's a good idea ;-)
> standard shell behaviour instead (i. e. for example something like
> the eval command).
1) this option did not broke any exist compatibilities
2) there we talk not only about uboot shell, same time will be useful
to have env_resolve for internal c usage, because env_set dont have
this feature
>
> > Artem Lapkin (2):
> > env: setenv add resolve value option
> > test: env: deep resolve value testing
>
> This is one more of the patches that actually try to fix existing
> problems with our ancient verion of the hush shell. As far as I
> understand, Francis (added to Cc:) has started working on an update
> of hush to a current version. We should rather help him with that
> instead of implementing non-standard workarounds.
yes i'm informed about this plans (and think its happens not so
soon - but i provide some simple elegant solution already)
but again we dont have env_resolve for internal c usage which must be
very useful
for example: pxe_utils.c: and some other places
env_set("bootargs", finalbootargs);
can be replaced by env_resolve("bootargs", . )
will be easy get useful features via simple solution ( deep resolve
all vars by one line )
>
> Best regards,
>
Big tnx again ! and waiting any other ideas about this
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> When choosing between two evils, I always like to take the one I've
> never tried before. -- Mae West, "Klondike Annie"
Re: [PATCH 1/1] pxe: simplify label_boot()
On Tue, Nov 16, 2021 at 2:26 AM Heinrich Schuchardt
wrote:
>
> Coverity CID 131256 indicates a possible buffer overflow in label_boot().
> This would only occur if the size of the downloaded file would exceed 4
> GiB. But anyway we can simplify the code by using snprintf() and checking
> the return value.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> boot/pxe_utils.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> index a7a84f26c1..5841561bdf 100644
> --- a/boot/pxe_utils.c
> +++ b/boot/pxe_utils.c
> @@ -465,11 +465,10 @@ static int label_boot(struct pxe_context *ctx, struct
> pxe_label *label)
> }
>
> initrd_addr_str = env_get("ramdisk_addr_r");
> - strcpy(initrd_filesize, simple_xtoa(size));
> -
> - strncpy(initrd_str, initrd_addr_str, 18);
> - strcat(initrd_str, ":");
> - strncat(initrd_str, initrd_filesize, 9);
> + size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
> + initrd_addr_str, size);
> + if (size >= sizeof(initrd_str))
> + return 1;
> }
>
> if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
> --
> 2.32.0
>
Reviewed-by: Artem Lapkin
Re: [PATCH v1] env: setenv add resolve value option
> The high level problem I have with this patch is that we keep going back
> to "we really need to update to a modern hush (or other shell) rather
> than patching new features in to our ancient fork".
Yes it will be fine ! Does anybody have information about these plans ?
but in any case my patch didn't broke compatibility like next patch
> See also this old patch:
> https://patchwork.ozlabs.org/project/uboot/patch/1449255744-25787-1-git-send-email...@ti.com/
> Can you please add to the env tests?
> please add function comment
> ...
tnx for suggestions ...
i can make v2 variant for my patch , if no one is against this idea
On Wed, Nov 3, 2021 at 12:44 AM Tom Rini wrote:
>
> On Tue, Nov 02, 2021 at 03:19:14PM +0800, Artem Lapkin wrote:
>
> > Add possibility setup env variable with additional resolving vars inside
> > value.
> >
> > Usage examples
> >
> > => setenv a hello
> > => setenv b world
> > => setenv c '${a} ${b}'
> > => setenv -r d '${c}! ${a}...'
> > => printenv d
> > d=hello world! hello...
> >
> > /* internal usage example */
> > env_resolve("d", "${c}! ${a}...");
> > /* d="hello world! hello..." */
> >
> > Notes
> >
> > Resolving works only for ${var} "bracket" and didn't workd for
> > "unbracket" $var
> >
> > => setenv -r d '$c! $a...'
> > => printenv d
> > d=$c! $a...
> >
> > Signed-off-by: Artem Lapkin
>
> The high level problem I have with this patch is that we keep going back
> to "we really need to update to a modern hush (or other shell) rather
> than patching new features in to our ancient fork".
>
> --
> Tom
Re: [PATCH] image: fix select_ramdisk for raw initrd
Hi Simon, Tom , and ...
> Do we need this patch as well as the other one? If so, can you combine them?
> Also, is it possible to drop the assignment to rd_addr at the top of
the function?
this patch must be replaced by another one
https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
( last patch will be enough alone)
On Mon, Nov 1, 2021 at 7:47 AM Simon Glass wrote:
>
> Hi Artem,
>
> On Fri, 15 Oct 2021 at 04:15, Artem Lapkin wrote:
> >
> > Problem
> >
> > We have unbootable raw initrd images because, select_ramdisk for raw
> > initrd images ignore submited select addr and setup rd_datap value to 0
> >
> > Solution: setup rd_datap value from select
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > common/image-board.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Do we need this patch as well as the other one? If so, can you combine them?
>
> Also, is it possible to drop the assignment to rd_addr at the top of
> the function?
>
> >
> > diff --git a/common/image-board.c b/common/image-board.c
> > index e7660352e9..e3c6ea806a 100644
> > --- a/common/image-board.c
> > +++ b/common/image-board.c
> > @@ -439,7 +439,7 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> > end = strchr(select, ':');
> > if (end) {
> > *rd_lenp = hextoul(++end, NULL);
> > - *rd_datap = rd_addr;
> > + *rd_datap = hextoul(select, NULL);
> > processed = true;
> > }
> > }
> > --
> > 2.25.1
> >
>
> Regards,
> Simon
Re: [PATCH] image-board: fix wrong implementation ram disk address setup from cmdline
hi Simon
> Fixes: f33a2c1bd0f ("image: Remove #ifdefs from select_ramdisk()")
> (I believe, can you confirm?)
confirm f33a2c1bd0f has wrong implementation logic for raw ramdisk image
sure i have tested it ...
On Mon, Nov 1, 2021 at 7:47 AM Simon Glass wrote:
>
> Hi Artem,
>
> On Fri, 15 Oct 2021 at 23:19, Artem Lapkin wrote:
> >
> > Problem
> >
> > Wrong implementation logic: ramdisk cmdline image address always ignored!
> > Next block { rd_addr = hextoul(select, NULL) } unusable for raw initrd.
> >
> > We have unbootable raw initrd images because, select_ramdisk for raw
> > initrd images ignore submited select addr and setup rd_datap value to 0
> >
> > Come-from:
> > https://patchwork.ozlabs.org/project/uboot/patch/20211015101501.4091141-1-...@khadas.com/
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > common/image-board.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Fixes: f33a2c1bd0f ("image: Remove #ifdefs from select_ramdisk()")
>
> (I believe, can you confirm?)
>
> Reviewed-by: Simon Glass
>
>
> >
> > diff --git a/common/image-board.c b/common/image-board.c
> > index e7660352e9..e7063016ef 100644
> > --- a/common/image-board.c
> > +++ b/common/image-board.c
> > @@ -333,7 +333,7 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> >
> > if (select) {
> > ulong default_addr;
> > - bool done = true;
> > + bool done = false;
> >
> > if (CONFIG_IS_ENABLED(FIT)) {
> > /*
> > @@ -351,13 +351,13 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> >_uname_config)) {
> > debug("* ramdisk: config '%s' from image
> > at 0x%08lx\n",
> > fit_uname_config, rd_addr);
> > + done = true;
> > } else if (fit_parse_subimage(select, default_addr,
> > _addr,
> > _uname_ramdisk)) {
> > debug("* ramdisk: subimage '%s' from image
> > at 0x%08lx\n",
> > fit_uname_ramdisk, rd_addr);
> > - } else {
> > - done = false;
> > + done = true;
> > }
> > }
> > if (!done) {
> > --
> > 2.25.1
> >
Re: [PATCH v3 18/18] pxe: Allow calling the pxe_get logic directly
OK nice its will be usefull Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 17/18] doc: Move distro boot doc to rST
OK Reviewed on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin
Re: [PATCH v3 16/18] pxe: Refactor sysboot to have one helper
OK is clear Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 15/18] pxe: Return the file size from the getfile() function
OK will be usefull Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 14/18] lib: Add a function to convert a string to a hex value
OK will be usefull Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 12/18] pxe: Drop get_bootfile_path()
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 11/18] pxe: Clean up the use of bootfile
OK its really needed! Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 10/18] pxe: Move common parsing coding into pxe_util
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 09/18] pxe: Tidy up code style a little in pxe_utils
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 08/18] pxe: Tidy up some comments in pxe_utils
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 07/18] pxe: Move pxe_utils files
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 06/18] pxe: Tidy up the is_pxe global
OK nice Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 05/18] pxe: Add a userdata field to the context
OK nice Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 04/18] pxe: Move do_getfile() into the context
OK nice Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 03/18] pxe: Use a context pointer
OK nice Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 02/18] pxe: Move API comments to the header files
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 01/18] Create a new boot/ directory
OK Reviewed and Tested on -master Mon 18 Oct 2021 04:40:29 PM CST Reviewed-by: Artem Lapkin Tested-by: Artem Lapkin
Re: [PATCH v3 13/18] lib: Add tests for simple_itoa()
Reviewed-by: Artem Lapkin
Re: [PATCH v3 01/18] Create a new boot/ directory
> rename {common => boot}/image-board.c (100%)
Before accepting this series we need to fix common/image-board.c which
have mistakes!
patch there >
https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
On Fri, Oct 15, 2021 at 2:48 AM Simon Glass wrote:
>
> Quite a lot of the code in common/relates to booting and images. Before
> adding more it seems like a good time to move the code into its own
> directory.
>
> Most files with 'boot' or 'image' in them are moved, except:
>
> - autoboot.c which relates to U-Boot automatically running a script
> - bootstage.c which relates to U-Boot timing
>
> Drop the removal of boot* files from the output directory, since this
> interfers with the symlinks created by tools and there does not appear
> to be any such file from my brief testing.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> Kconfig | 2 ++
> Makefile| 3 ++-
> README | 1 +
> common/Kconfig.boot => boot/Kconfig | 0
> boot/Makefile | 34 +
> {common => boot}/android_ab.c | 0
> {common => boot}/boot_fit.c | 0
> {common => boot}/bootm.c| 0
> {common => boot}/bootm_os.c | 0
> {common => boot}/bootretry.c| 0
> {common => boot}/common_fit.c | 0
> {common => boot}/fdt_region.c | 0
> {common => boot}/image-android-dt.c | 0
> {common => boot}/image-android.c| 0
> {common => boot}/image-board.c | 0
> {common => boot}/image-cipher.c | 0
> {common => boot}/image-fdt.c| 0
> {common => boot}/image-fit-sig.c| 0
> {common => boot}/image-fit.c| 0
> {common => boot}/image-host.c | 0
> {common => boot}/image-sig.c| 0
> {common => boot}/image.c| 0
> common/Kconfig | 2 --
> common/Makefile | 22 ---
> doc/android/boot-image.rst | 2 +-
> scripts/Makefile.spl| 4 ++--
> tools/Makefile | 18 +++
> 27 files changed, 51 insertions(+), 37 deletions(-)
> rename common/Kconfig.boot => boot/Kconfig (100%)
> create mode 100644 boot/Makefile
> rename {common => boot}/android_ab.c (100%)
> rename {common => boot}/boot_fit.c (100%)
> rename {common => boot}/bootm.c (100%)
> rename {common => boot}/bootm_os.c (100%)
> rename {common => boot}/bootretry.c (100%)
> rename {common => boot}/common_fit.c (100%)
> rename {common => boot}/fdt_region.c (100%)
> rename {common => boot}/image-android-dt.c (100%)
> rename {common => boot}/image-android.c (100%)
> rename {common => boot}/image-board.c (100%)
> rename {common => boot}/image-cipher.c (100%)
> rename {common => boot}/image-fdt.c (100%)
> rename {common => boot}/image-fit-sig.c (100%)
> rename {common => boot}/image-fit.c (100%)
> rename {common => boot}/image-host.c (100%)
> rename {common => boot}/image-sig.c (100%)
> rename {common => boot}/image.c (100%)
>
> diff --git a/Kconfig b/Kconfig
> index 931a22806e4..c46f4fce862 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -466,6 +466,8 @@ endmenu # General setup
>
> source "api/Kconfig"
>
> +source "boot/Kconfig"
> +
> source "common/Kconfig"
>
> source "cmd/Kconfig"
> diff --git a/Makefile b/Makefile
> index f911f703443..4e064acdcff 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -804,6 +804,7 @@ HAVE_VENDOR_COMMON_LIB = $(if $(wildcard
> $(srctree)/board/$(VENDOR)/common/Makef
>
> libs-$(CONFIG_API) += api/
> libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
> +libs-y += boot/
> libs-y += cmd/
> libs-y += common/
> libs-$(CONFIG_OF_EMBED) += dts/
> @@ -2076,7 +2077,7 @@ CLEAN_DIRS += $(MODVERDIR) \
> $(filter-out include, $(shell ls -1 $d 2>/dev/null
>
> CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h tools/version.h \
> - boot* u-boot* MLO* SPL System.map fit-dtb.blob* \
> + u-boot* MLO* SPL System.map fit-dtb.blob* \
>u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \
>lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
>idbloader.img flash.bin flash.log defconfig keep-syms-lto.c
> diff --git a/README b/README
> index 840b192aae5..49c79ca6a2d 100644
> --- a/README
> +++ b/README
> @@ -144,6 +144,7 @@ Directory Hierarchy:
>/xtensa Files generic to Xtensa architecture
> /api Machine/arch-independent API for external apps
> /board Board-dependent files
> +/boot Support for images and booting
> /cmd U-Boot commands functions
> /commonMisc architecture-independent functions
> /configs Board default configuration files
> diff --git a/common/Kconfig.boot b/boot/Kconfig
> similarity
Re: [PATCH] image: fix select_ramdisk for raw initrd
Hi Simon
plz ignore this patch
proper solution problem there >
https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
On Fri, Oct 15, 2021 at 6:15 PM Artem Lapkin wrote:
>
> Problem
>
> We have unbootable raw initrd images because, select_ramdisk for raw
> initrd images ignore submited select addr and setup rd_datap value to 0
>
> Solution: setup rd_datap value from select
>
> Signed-off-by: Artem Lapkin
> ---
> common/image-board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/image-board.c b/common/image-board.c
> index e7660352e9..e3c6ea806a 100644
> --- a/common/image-board.c
> +++ b/common/image-board.c
> @@ -439,7 +439,7 @@ static int select_ramdisk(bootm_headers_t *images, const
> char *select, u8 arch,
> end = strchr(select, ':');
> if (end) {
> *rd_lenp = hextoul(++end, NULL);
> - *rd_datap = rd_addr;
> + *rd_datap = hextoul(select, NULL);
> processed = true;
> }
> }
> --
> 2.25.1
>
Re: [PATCH v3 00/18] pxe: Refactoring to tidy up and prepare for bootflow
hi Simon
I am still testing this patchset for master branch! need more time
(but looks like works)
BTW: i have get some problems from prev your commits for example
unbootable raw initrd images
https://patchwork.ozlabs.org/project/uboot/patch/20211015101501.4091141-1-...@khadas.com/
i have send this patch maybe your can identificate problem more
properly (to much changes from v2021.07 - v2021.10
boot process for v2021.07 works well )
Tnx for your work
On Fri, Oct 15, 2021 at 2:48 AM Simon Glass wrote:
>
> This collects together the patches previously sent relating to PXE.
>
> Firstly, it moves the boot code out of common/ and into a new boot/
> directory. This helps to collect these related files in one place, as
> common/ is quite large.
>
> Secondly, it provides patache so clean up the PXE code and refactor it
> into something closer to a module that can be called, teasing apart its
> reliance on the command-line interpreter to access filesystems and the
> like. Also it now uses function arguments and its own context struct
> internally rather than environment variables, which is very hard to
> follow. No core functional change is intended.
>
> Changes in v3:
> - Rebase to -master
>
> Changes in v2:
> - Rebase to -next
> - Split out from the bootmethod patches
>
> Simon Glass (18):
> Create a new boot/ directory
> pxe: Move API comments to the header files
> pxe: Use a context pointer
> pxe: Move do_getfile() into the context
> pxe: Add a userdata field to the context
> pxe: Tidy up the is_pxe global
> pxe: Move pxe_utils files
> pxe: Tidy up some comments in pxe_utils
> pxe: Tidy up code style a little in pxe_utils
> pxe: Move common parsing coding into pxe_util
> pxe: Clean up the use of bootfile
> pxe: Drop get_bootfile_path()
> lib: Add tests for simple_itoa()
> lib: Add a function to convert a string to a hex value
> pxe: Return the file size from the getfile() function
> pxe: Refactor sysboot to have one helper
> doc: Move distro boot doc to rST
> pxe: Allow calling the pxe_get logic directly
>
> Kconfig | 2 +
> Makefile | 3 +-
> README| 1 +
> common/Kconfig.boot => boot/Kconfig | 0
> boot/Makefile | 37 ++
> {common => boot}/android_ab.c | 0
> {common => boot}/boot_fit.c | 0
> {common => boot}/bootm.c | 0
> {common => boot}/bootm_os.c | 0
> {common => boot}/bootretry.c | 0
> {common => boot}/common_fit.c | 0
> {common => boot}/fdt_region.c | 0
> {common => boot}/image-android-dt.c | 0
> {common => boot}/image-android.c | 0
> {common => boot}/image-board.c| 0
> {common => boot}/image-cipher.c | 0
> {common => boot}/image-fdt.c | 0
> {common => boot}/image-fit-sig.c | 0
> {common => boot}/image-fit.c | 0
> {common => boot}/image-host.c | 0
> {common => boot}/image-sig.c | 0
> {common => boot}/image.c | 0
> {cmd => boot}/pxe_utils.c | 512 +++---
> cmd/Makefile | 4 +-
> cmd/pxe.c | 136 +++---
> cmd/pxe_utils.h | 91
> cmd/sysboot.c | 114 +++--
> common/Kconfig| 2 -
> common/Makefile | 22 -
> doc/android/boot-image.rst| 2 +-
> doc/{README.distro => develop/distro.rst} | 177
> doc/develop/index.rst | 1 +
> include/pxe_utils.h | 253 +++
> include/vsprintf.h| 25 +-
> lib/vsprintf.c| 20 +-
> scripts/Makefile.spl | 4 +-
> test/print_ut.c | 41 ++
> tools/Makefile| 18 +-
> 38 files changed, 874 insertions(+), 591 deletions(-)
> rename common/Kconfig.boot => boot/Kconfig (100%)
> create mode 100644 boot/Makefile
> rename {common => boot}/android_ab.c (100%)
> rename {common => boot}/boot_fit.c (100%)
> rename {common => boot}/bootm.c (100%)
> rename {common => boot}/bootm_os.c (100%)
> rename {common => boot}/bootretry.c (100%)
> rename {common => boot}/common_fit.c (100%)
> rename {common => boot}/fdt_region.c (100%)
> rename {common => boot}/image-android-dt.c (100%)
> rename {common => boot}/image-android.c (100%)
> rename {common => boot}/image-board.c (100%)
> rename {common => boot}/image-cipher.c (100%)
> rename {common => boot}/image-fdt.c (100%)
> rename {common => boot}/image-fit-sig.c (100%)
> rename {common => boot}/image-fit.c (100%)
> rename {common => boot}/image-host.c (100%)
> rename {common =>
Re: [PATCH] cmd: sysboot: dont overwrite bootfile env
> Please also see this refactor which conflicts with this patch:
>
> http://patchwork.ozlabs.org/project/uboot/list/?series=264265
>
> I think that series should be reviewed/applied first since it was sent
in August.
yes ! i think need update your series because cant apply it for
current uboot state
On Thu, Oct 14, 2021 at 12:58 AM Simon Glass wrote:
>
> Hi,
>
> On Tue, 12 Oct 2021 at 21:39, Artem Lapkin wrote:
> >
> > Problem
> >
> > PXE cannot boot normally after Sysboot changed the bootfile env (called
> > from boot_extlinux) from the default "boot.scr.uimg" to
> > "/boot/extlinux/extlinux.conf".
> >
> > In addition, an unbootable extlinux configuration will also make the PXE
> > boot unbootable, because it will use the incorrect path "/boot/extlinux/"
> > from the bootfile env.
> >
> > Solution
> >
> > sysboot must care about bootfile and restore default value after usage.
> >
> > Come from:
> > https://patchwork.ozlabs.org/project/uboot/patch/20211012085544.3206394-1-...@khadas.com/
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > cmd/sysboot.c | 30 --
> > 1 file changed, 20 insertions(+), 10 deletions(-)
>
> Please also see this refactor which conflicts with this patch:
>
> http://patchwork.ozlabs.org/project/uboot/list/?series=264265
>
> I think that series should be reviewed/applied first since it was sent
> in August.
>
> >
> > diff --git a/cmd/sysboot.c b/cmd/sysboot.c
> > index af6a2f1b7f..99b11cc127 100644
> > --- a/cmd/sysboot.c
> > +++ b/cmd/sysboot.c
> > @@ -2,6 +2,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include "pxe_utils.h"
> > @@ -61,8 +62,9 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag,
> > int argc,
> > unsigned long pxefile_addr_r;
> > struct pxe_menu *cfg;
> > char *pxefile_addr_str;
> > - char *filename;
> > + char *filename, *filename_bak;
>
> Can we see filename_bak to NULL so we can simply the free() below?
>
> > int prompt = 0;
> > + int ret = 0;
> >
> > is_pxe = false;
> >
> > @@ -83,9 +85,10 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag,
> > int argc,
> > pxefile_addr_str = argv[4];
> > }
> >
> > - if (argc < 6) {
> > - filename = env_get("bootfile");
> > - } else {
> > + filename = env_get("bootfile");
> > + if (argc > 5) {
> > + filename_bak = malloc(strlen(filename) + 1);
> > + strcpy(filename_bak, filename);
> > filename = argv[5];
> > env_set("bootfile", filename);
> > }
> > @@ -98,26 +101,26 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag,
> > int argc,
> > do_getfile = do_get_any;
> > } else {
> > printf("Invalid filesystem: %s\n", argv[3]);
> > - return 1;
> > + goto err;
> > }
> > fs_argv[1] = argv[1];
> > fs_argv[2] = argv[2];
> >
> > if (strict_strtoul(pxefile_addr_str, 16, _addr_r) < 0) {
> > printf("Invalid pxefile address: %s\n", pxefile_addr_str);
> > - return 1;
> > + goto err;
> > }
> >
> > if (get_pxe_file(cmdtp, filename, pxefile_addr_r) < 0) {
> > printf("Error reading config file\n");
> > - return 1;
> > + goto err;
> > }
> >
> > cfg = parse_pxefile(cmdtp, pxefile_addr_r);
> >
> > if (!cfg) {
> > printf("Error parsing config file\n");
> > - return 1;
> > + goto err;
> > }
> >
> > if (prompt)
> > @@ -126,8 +129,15 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag,
> > int argc,
> > handle_pxe_menu(cmdtp, cfg);
> >
> > destroy_pxe_menu(cfg);
> > -
> > - return 0;
> > + goto ret;
>
> This is a bit ugly. Could we set 'ret' to 1 in the error cases above,
> or set it to 1 at the top ad 0 here, or pull the parsing code into a
> function...?
>
> > + err:
> > + ret = 1;
> > + ret:
> > + if (filename_bak) {
> > + env_set("bootfile", filename_bak);
> > + free(filename_bak);
> > + }
> > + return ret;
> > }
> >
> > U_BOOT_CMD(sysboot, 7, 1, do_sysboot,
> > --
> > 2.25.1
> >
>
> Regards,
> Simon
Re: [PATCH] distro_boot: Fix bootfile env after calling boot_extlinux
> could you check out my syslinux refactor
> series? It could use some review.
>
> http://patchwork.ozlabs.org/project/uboot/list/?series=264265
Yes ! But I already can't apply this series for actual uboot code
(need to change)
maybe u can make v3 patches for actual uboot state.
I checked it quickly. This series has many useful improvements!
> Here's the patch where (I believe) this problem was addressed:
> http://patchwork.ozlabs.org/project/uboot/patch/20210927092350.v2.11.I6a01e73ef114448e39cb6899c21f6c169e4da216@changeid/
look like yes and if your series will be applied my patch already no need.
On Thu, Oct 14, 2021 at 12:58 AM Simon Glass wrote:
>
> Hi Art,
>
> On Tue, 12 Oct 2021 at 21:45, Art Nikpal wrote:
> >
> > Yes changes inside include/config_distro_bootcmd.h not the best solution
> > for this issue.
> > I think it is better to change sysboot cmd and i have prepared another
> > solution already!
> > https://patchwork.ozlabs.org/project/uboot/patch/20211013033912.3297227-1-...@khadas.com/
> > how about this ?
>
> Seem reasonable to me, but could you check out my syslinux refactor
> series? It could use some review.
>
> http://patchwork.ozlabs.org/project/uboot/list/?series=264265
>
>
> - Simon
>
> >
> > On Wed, Oct 13, 2021 at 5:07 AM Tom Rini wrote:
> >>
> >> On Tue, Oct 12, 2021 at 02:31:18PM -0600, Simon Glass wrote:
> >> > Hi Tom,
> >> >
> >> > On Tue, 12 Oct 2021 at 13:44, Tom Rini wrote:
> >> > >
> >> > > On Tue, Oct 12, 2021 at 04:55:44PM +0800, Artem Lapkin wrote:
> >> > >
> >> > > > Problem
> >> > > >
> >> > > > PXE cannot boot normally after Sysboot changed the bootfile env
> >> > > > (called
> >> > > > from boot_extlinux) from the default "boot.scr.uimg" to
> >> > > > "/boot/extlinux/extlinux.conf".
> >> > > >
> >> > > > In addition, an unbootable extlinux configuration will also make the
> >> > > > PXE
> >> > > > boot unbootable, because it will use the incorrect path
> >> > > > "/boot/extlinux/"
> >> > > > from the bootfile env.
> >> > > >
> >> > > > Solution
> >> > > >
> >> > > > Save and restore default bootfile env value when boot_extlinux is
> >> > > > used.
> >> > > >
> >> > > > Example
> >> > > >
> >> > > > Hit SPACE in 2 seconds to stop autoboot
> >> > > > ... is now current device
> >> > > > Found /boot/extlinux/extlinux.conf
> >> > > > Retrieving file: /boot/extlinux/extlinux.conf
> >> > > > 413 bytes read in 2 ms (201.2 KiB/s)
> >> > > > Skipping Krescue for failure retrieving kernel
> >> > > > SCRIPT FAILED: continuing...
> >> > > > ...
> >> > > > Speed: 1000, full duplex
> >> > > > BOOTP broadcast 1
> >> > > > DHCP client bound to address 192.168.11.151 (8 ms)
> >> > > > Using ethernet@ff3f device
> >> > > > TFTP from server 192.168.11.1; our IP address is 192.168.11.151
> >> > > > Filename '/boot/extlinux/pxelinux.cfg/default'.
> >> > > > Not retrying...
> >> > > >
> >> > > >
> >> > > > Signed-off-by: Artem Lapkin
> >> > > > ---
> >> > > > include/config_distro_bootcmd.h | 2 ++
> >> > > > 1 file changed, 2 insertions(+)
> >> > > >
> >> > > > diff --git a/include/config_distro_bootcmd.h
> >> > > > b/include/config_distro_bootcmd.h
> >> > > > index 3f724aa10f..db3d1b2362 100644
> >> > > > --- a/include/config_distro_bootcmd.h
> >> > > > +++ b/include/config_distro_bootcmd.h
> >> > > > @@ -445,7 +445,9 @@
> >> > > > "${devnum}:${distro_bootpart} "
> >> > > >\
> >> > > > "${prefix}${boot_syslinux_conf}; then
> >> > > > " \
> >> > > > "echo Found ${prefix}${boot_syslinux_conf}; "
> >> > > >\
> >
Re: [PATCH] distro_boot: Fix bootfile env after calling boot_extlinux
Yes changes inside include/config_distro_bootcmd.h not the best solution
for this issue.
I think it is better to change sysboot cmd and i have prepared another
solution already!
https://patchwork.ozlabs.org/project/uboot/patch/20211013033912.3297227-1-...@khadas.com/
how about this ?
On Wed, Oct 13, 2021 at 5:07 AM Tom Rini wrote:
> On Tue, Oct 12, 2021 at 02:31:18PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 12 Oct 2021 at 13:44, Tom Rini wrote:
> > >
> > > On Tue, Oct 12, 2021 at 04:55:44PM +0800, Artem Lapkin wrote:
> > >
> > > > Problem
> > > >
> > > > PXE cannot boot normally after Sysboot changed the bootfile env
> (called
> > > > from boot_extlinux) from the default "boot.scr.uimg" to
> > > > "/boot/extlinux/extlinux.conf".
> > > >
> > > > In addition, an unbootable extlinux configuration will also make the
> PXE
> > > > boot unbootable, because it will use the incorrect path
> "/boot/extlinux/"
> > > > from the bootfile env.
> > > >
> > > > Solution
> > > >
> > > > Save and restore default bootfile env value when boot_extlinux is
> used.
> > > >
> > > > Example
> > > >
> > > > Hit SPACE in 2 seconds to stop autoboot
> > > > ... is now current device
> > > > Found /boot/extlinux/extlinux.conf
> > > > Retrieving file: /boot/extlinux/extlinux.conf
> > > > 413 bytes read in 2 ms (201.2 KiB/s)
> > > > Skipping Krescue for failure retrieving kernel
> > > > SCRIPT FAILED: continuing...
> > > > ...
> > > > Speed: 1000, full duplex
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 192.168.11.151 (8 ms)
> > > > Using ethernet@ff3f device
> > > > TFTP from server 192.168.11.1; our IP address is 192.168.11.151
> > > > Filename '/boot/extlinux/pxelinux.cfg/default'.
> > > > Not retrying...
> > > >
> > > >
> > > > Signed-off-by: Artem Lapkin
> > > > ---
> > > > include/config_distro_bootcmd.h | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/include/config_distro_bootcmd.h
> b/include/config_distro_bootcmd.h
> > > > index 3f724aa10f..db3d1b2362 100644
> > > > --- a/include/config_distro_bootcmd.h
> > > > +++ b/include/config_distro_bootcmd.h
> > > > @@ -445,7 +445,9 @@
> > > > "${devnum}:${distro_bootpart} "
>\
> > > > "${prefix}${boot_syslinux_conf}; then
> " \
> > > > "echo Found ${prefix}${boot_syslinux_conf}; "
>\
> > > > + "bootfile_bak=${bootfile}; "
> \
> > > > "run boot_extlinux; "
>\
> > > > + "setenv bootfile ${bootfile_bak}; "
>\
> > > > "echo SCRIPT FAILED: continuing...; "
>\
> > > > "fi\0"
> \
> > > > \
> > >
> > > We've had this kind of problem before, and the answer is that variables
> > > should be local, not global in scope. In this case, I see that the way
> > > the pxe/sysboot code works is that we have to env_set("..") in one
> place
> > > to env_get("..") in another, so I don't see a way around this.
> > >
> > > Reviewed-by: Tom Rini
> >
> > IMO a better approach will be the bootflow implementation. I hope to
> > get v2 out early next week.
>
> I'm not sure if the bootflow way of going here would or would not have
> the same problem, or perhaps a slightly different problem. At heart
> here, "sysboot" calls env_set(...) and then calls in to the pxe code
> which does env_get(...). So now I wonder how this would be fixed in
> bootflow, since we aren't dealing with the environment directly.
>
> --
> Tom
>
Re: [PATCH 3/4] EFI: console: max rows and cols user limit
> Why should a user set this up?
only if user need it! by default is 0 no limit
EFI console not usable for some cases: big screen sizes + mux with
serial console
for example
EFI console - fullscreen (1080P) vidconsole - SLUGGISH FRAMERATES AND NOT USABLE
CONFIG_CONSOLE_MUX=y
CONFIG_CONSOLE_NORMAL=y
CONFIG_EFI_CONSOLE_MAX_ROWS=0
CONFIG_EFI_CONSOLE_MAX_COLS=0
https://dl.khadas.com/test/uboot_efi_examples/media/07-EFI_console_example_normal_vidconsole_and_serial_multiplex_adaptation_utf_safe_SLOW_NOT_USABLE.mp4
EFI console - vidconsole with row and column limits - USABLE FRAMERATES
CONFIG_CONSOLE_MUX=y
CONFIG_CONSOLE_NORMAL=y
CONFIG_EFI_CONSOLE_MAX_ROWS=90
CONFIG_EFI_CONSOLE_MAX_COLS=25
https://dl.khadas.com/test/uboot_efi_examples/media/06-EFI_console_example_normal_vidconsole_and_serial_multiplex_adaptation_utf_safe_and_max_cols_90_limit_USABLE.mp4
Please check more information and examples about this
+ https://dl.khadas.com/test/uboot_efi_examples/#readme
On Thu, Aug 5, 2021 at 7:59 PM Heinrich Schuchardt wrote:
>
> On 8/4/21 12:22 PM, Artem Lapkin wrote:
> > Setup the max rows and columns limit for the EFI console output.
>
> Why should a user set this up?
>
> The size of serial console depends on the remote computers console
> windows size.
>
> The size of a video console depends on the attached monitor.
>
> So we have to detect the size dynamically. Hardcoding it does not make
> any sense.
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > lib/efi_loader/Kconfig | 12
> > lib/efi_loader/efi_console.c | 5 +
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index dacc3b5881..7d00d6cde5 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -381,4 +381,16 @@ config EFI_ESRT
> > help
> > Enabling this option creates the ESRT UEFI system table.
> >
> > +config EFI_CONSOLE_MAX_ROWS
> > + int "setup console max rows"
> > + default 0
> > + help
> > + Set console max rows limit or set to zero to disable limit.
> > +
> > +config EFI_CONSOLE_MAX_COLS
> > + int "setup console max cols"
> > + default 0
> > + help
> > + Set console max rows limit or set to zero to disable limit.
> > +
> > endif
> > diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> > index 847069212e..b5d79d788f 100644
> > --- a/lib/efi_loader/efi_console.c
> > +++ b/lib/efi_loader/efi_console.c
> > @@ -351,6 +351,11 @@ static void query_console_size(void)
> > } else if (query_console_serial(, ))
> > return;
> >
> > + if (CONFIG_EFI_CONSOLE_MAX_ROWS > 0)
> > + rows = min(rows, CONFIG_EFI_CONSOLE_MAX_ROWS);
> > + if (CONFIG_EFI_CONSOLE_MAX_COLS > 0)
> > + cols = min(cols, CONFIG_EFI_CONSOLE_MAX_COLS);
> > +
> > /* Test if we can have Mode 1 */
> > if (cols >= 80 && rows >= 50) {
> > efi_cout_modes[1].present = 1;
> >
>
Re: [PATCH 4/4] EFI: console: improve vidconsole unicode output
> The TrueType console is meant to support Unicode including the special
characters used by GRUB like left and right triangle.
Yes is meant but not works (on my side) ...
uboot TrueType vidconsole does not work properly as a unicode console
in my case and have other problems
CONFIG_CONSOLE_MUX=y
CONFIG_CONSOLE_NORMAL=y
CONFIG_CONSOLE_TRUETYPE=y
CONFIG_CONSOLE_TRUETYPE_SIZE=18
CONFIG_CONSOLE_TRUETYPE_NIMBUS=y
please check more information and examples about this
+ https://dl.khadas.com/test/uboot_efi_examples/#readme
+
https://dl.khadas.com/test/uboot_efi_examples/media/02-EFI_console_example_true_type_vidconsole_and_serial_as_is_NOT_USABLE.mp4
+
https://dl.khadas.com/test/uboot_efi_examples/media/02-EFI_console_example_true_type_vidconsole_and_serial_as_is_NOT_USABLE.png
+
https://dl.khadas.com/test/uboot_efi_examples/media/02-EFI_console_example_true_type_vidconsole_and_serial_as_is_NOT_USABLE_2.png
On Thu, Aug 5, 2021 at 8:01 PM Heinrich Schuchardt wrote:
>
> On 8/4/21 12:22 PM, Artem Lapkin wrote:
> > If EFI_CONSOLE_UTF_SAFE is enabled and vidconsole is active, unicode
> > characters will be replaced with "." for all console outputs.
>
> The TrueType console is meant to support Unicode including the special
> characters used by GRUB like left and right triangle.
>
> So this patch is based on a wrong assumption.
>
> Best regards
>
> Heinrich
>
> >
> > Vidconsole does not support unicode output, and your console will suffer
> > display issues if EFI_CONSOLE_UTF_SAFE is disabled.
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > lib/efi_loader/Kconfig | 9 +
> > lib/efi_loader/efi_console.c | 6 +-
> > 2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 7d00d6cde5..886e0ce111 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -393,4 +393,13 @@ config EFI_CONSOLE_MAX_COLS
> > help
> > Set console max rows limit or set to zero to disable limit.
> >
> > +config EFI_CONSOLE_UTF_SAFE
> > + bool "If vidconsole is active, unicode characters will be replaced
> > with '.'"
> > + default n
> > + help
> > + If EFI_CONSOLE_UTF_SAFE is enabled and vidconsole is active, unicode
> > + characters will be replaced with "." for all console outputs.
> > + Vidconsole does not support unicode output, and your console will
> > + suffer display issues if EFI_CONSOLE_UTF_SAFE is disabled.
> > +
> > endif
> > diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> > index b5d79d788f..bd1c14995d 100644
> > --- a/lib/efi_loader/efi_console.c
> > +++ b/lib/efi_loader/efi_console.c
> > @@ -19,6 +19,8 @@
> > #define EFI_COUT_MODE_2 2
> > #define EFI_MAX_COUT_MODE 3
> >
> > +static int vidconsole_active;
> > +
> > struct cout_mode {
> > unsigned long columns;
> > unsigned long rows;
> > @@ -163,7 +165,8 @@ static efi_status_t EFIAPI efi_cout_output_string(
> > }
> > pos = buf;
> > utf16_utf8_strcpy(, string);
> > - fputs(stdout, buf);
> > + fputs(stdout, IS_ENABLED(CONFIG_EFI_CONSOLE_UTF_SAFE) &&
> > + strlen(buf) > 1 && vidconsole_active ? "." : buf);
> > free(buf);
> >
> > /*
> > @@ -327,6 +330,7 @@ static int __maybe_unused query_vidconsole(int *rows,
> > int *cols)
> > return -ENODEV;
> > *rows = priv->rows;
> > *cols = priv->cols;
> > + vidconsole_active = 1;
> > return 0;
> > }
> >
> >
>
Re: [PATCH 1/4] EFI: console: query_vidconsole: multiplex adaptation
> So this change seems wrong.
please check 3rd patch before
https://patchwork.ozlabs.org/project/uboot/patch/20210804102217.2419510-3-...@khadas.com/
i think its must be clarify problem with multiplex output configuration
CONFIG_CONSOLE_MUX=y
CONFIG_CONSOLE_NORMAL=y
please check more information and examples about this
+ https://dl.khadas.com/test/uboot_efi_examples/#readme
+
https://dl.khadas.com/test/uboot_efi_examples/media/01-EFI_console_example_normal_vidconsole_and_serial_as_is_without_changes_NOT_USABLE.png
+
https://dl.khadas.com/test/uboot_efi_examples/media/02-EFI_console_example_true_type_vidconsole_and_serial_as_is_NOT_USABLE.mp4
+
https://dl.khadas.com/test/uboot_efi_examples/media/02-EFI_console_example_true_type_vidconsole_and_serial_as_is_NOT_USABLE.png
On Thu, Aug 5, 2021 at 7:55 PM Heinrich Schuchardt wrote:
>
> On 8/4/21 12:22 PM, Artem Lapkin wrote:
> > Fixed detection of vidconsole from within a multiplexed stdout string. As
> > you know, a user can use a comma-separated list of devices to set stdin,
> > stdout and stderr. For example, "setenv stdout serial,vidconsole" is a
> > multiplexed string.
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > lib/efi_loader/efi_console.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> > index 3b012e1a66..2d03285f82 100644
> > --- a/lib/efi_loader/efi_console.c
> > +++ b/lib/efi_loader/efi_console.c
> > @@ -314,7 +314,7 @@ static int __maybe_unused query_vidconsole(int *rows,
> > int *cols)
> > struct udevice *dev;
> > struct vidconsole_priv *priv;
> >
> > - if (!stdout_name || strncmp(stdout_name, "vidconsole", 10))
> > + if (!stdout_name || !strstr(stdout_name, "vidconsole"))
>
> If stdout == "serial,vidconsole", serial is the primary output and we
> want to determine the size of the console window from serial and not
> from vidconsole.
>
> So this change seems wrong.
>
> Best regards
>
> Heinrich
>
> > return -ENODEV;
> > stdout_dev = stdio_get_by_name("vidconsole");
> > if (!stdout_dev)
> >
>
Re: [PATCH] configs: khadas-vim*: Enable SMBIOS
Got it, thanks! patches already resend with new subject On Mon, Jul 26, 2021 at 3:37 PM Neil Armstrong wrote: > > Hi, > > Subject should be: "[PATCH] configs: Enable SMBIOS for Khadas VIM boards" > > with that: > Reviewed-by: Neil Armstrong > > On 15/07/2021 07:00, Artem Lapkin wrote: > > Enable configs to support SMBIOS for all Khadas vim* boards > > > > Signed-off-by: Artem Lapkin > > --- > > configs/khadas-vim2_defconfig | 2 ++ > > configs/khadas-vim3_defconfig | 2 ++ > > configs/khadas-vim3l_defconfig | 2 ++ > > configs/khadas-vim_defconfig | 2 ++ > > 4 files changed, 8 insertions(+) > > > > diff --git a/configs/khadas-vim2_defconfig b/configs/khadas-vim2_defconfig > > index 32513998..5d673463 100644 > > --- a/configs/khadas-vim2_defconfig > > +++ b/configs/khadas-vim2_defconfig > > @@ -50,6 +50,8 @@ CONFIG_DM_RESET=y > > CONFIG_DEBUG_UART_ANNOUNCE=y > > CONFIG_DEBUG_UART_SKIP_INIT=y > > CONFIG_MESON_SERIAL=y > > +CONFIG_SYSINFO=y > > +CONFIG_SYSINFO_SMBIOS=y > > CONFIG_SPI=y > > CONFIG_DM_SPI=y > > CONFIG_MESON_SPIFC=y > > diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig > > index c4b24fc3..5a7a9006 100644 > > --- a/configs/khadas-vim3_defconfig > > +++ b/configs/khadas-vim3_defconfig > > @@ -61,6 +61,8 @@ CONFIG_DM_RESET=y > > CONFIG_DEBUG_UART_ANNOUNCE=y > > CONFIG_DEBUG_UART_SKIP_INIT=y > > CONFIG_MESON_SERIAL=y > > +CONFIG_SYSINFO=y > > +CONFIG_SYSINFO_SMBIOS=y > > CONFIG_SPI=y > > CONFIG_DM_SPI=y > > CONFIG_MESON_SPIFC=y > > diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig > > index 0c731d4c..d719511f 100644 > > --- a/configs/khadas-vim3l_defconfig > > +++ b/configs/khadas-vim3l_defconfig > > @@ -61,6 +61,8 @@ CONFIG_DM_RESET=y > > CONFIG_DEBUG_UART_ANNOUNCE=y > > CONFIG_DEBUG_UART_SKIP_INIT=y > > CONFIG_MESON_SERIAL=y > > +CONFIG_SYSINFO=y > > +CONFIG_SYSINFO_SMBIOS=y > > CONFIG_SPI=y > > CONFIG_DM_SPI=y > > CONFIG_MESON_SPIFC=y > > diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig > > index 2df00d54..dc6365fc 100644 > > --- a/configs/khadas-vim_defconfig > > +++ b/configs/khadas-vim_defconfig > > @@ -44,6 +44,8 @@ CONFIG_DM_RESET=y > > CONFIG_DEBUG_UART_ANNOUNCE=y > > CONFIG_DEBUG_UART_SKIP_INIT=y > > CONFIG_MESON_SERIAL=y > > +CONFIG_SYSINFO=y > > +CONFIG_SYSINFO_SMBIOS=y > > CONFIG_USB=y > > CONFIG_DM_USB=y > > CONFIG_USB_XHCI_HCD=y > > >
Re: [PATCH] dts: khadas vim series: Use devicetree for SMBIOS settings
Got it, thanks! patches already resend with new subject
On Mon, Jul 26, 2021 at 3:37 PM Neil Armstrong wrote:
>
> Hi,
>
> Subject should be: "[PATCH] ARM: dts: meson: Use devicetree for SMBIOS
> settings for Khadas VIM boards"
>
> with that:
> Reviewed-by: Neil Armstrong
>
> On 15/07/2021 07:00, Artem Lapkin wrote:
> > Khadas vim series: Use devicetree for SMBIOS settings
> > Add settings and enable the default sysinfo driver so that these can come
> > from the device tree.
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > .../meson-g12b-a311d-khadas-vim3-u-boot.dtsi | 23 +++
> > .../meson-gxl-s905x-khadas-vim-u-boot.dtsi| 23 +++
> > .../arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi | 21 +
> > .../dts/meson-sm1-khadas-vim3l-u-boot.dtsi| 23 +++
> > 4 files changed, 90 insertions(+)
> >
> > diff --git a/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
> > b/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
> > index 489efa15..fcd6f053 100644
> > --- a/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
> > +++ b/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
> > @@ -6,3 +6,26 @@
> >
> > #include "meson-g12-common-u-boot.dtsi"
> > #include "meson-khadas-vim3-u-boot.dtsi"
> > +
> > +/ {
> > + smbios {
> > + compatible = "u-boot,sysinfo-smbios";
> > +
> > + smbios {
> > + system {
> > + manufacturer = "khadas";
> > + product = "VIM3";
> > + };
> > +
> > + baseboard {
> > + manufacturer = "khadas";
> > + product = "VIM3";
> > + };
> > +
> > + chassis {
> > + manufacturer = "khadas";
> > + product = "VIM3";
> > + };
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/dts/meson-gxl-s905x-khadas-vim-u-boot.dtsi
> > b/arch/arm/dts/meson-gxl-s905x-khadas-vim-u-boot.dtsi
> > index 39270ea7..20e36d1b 100644
> > --- a/arch/arm/dts/meson-gxl-s905x-khadas-vim-u-boot.dtsi
> > +++ b/arch/arm/dts/meson-gxl-s905x-khadas-vim-u-boot.dtsi
> > @@ -5,3 +5,26 @@
> > */
> >
> > #include "meson-gxl-u-boot.dtsi"
> > +
> > +/ {
> > + smbios {
> > + compatible = "u-boot,sysinfo-smbios";
> > +
> > + smbios {
> > + system {
> > + manufacturer = "khadas";
> > + product = "VIM";
> > + };
> > +
> > + baseboard {
> > + manufacturer = "khadas";
> > + product = "VIM";
> > + };
> > +
> > + chassis {
> > + manufacturer = "khadas";
> > + product = "VIM";
> > + };
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> > b/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> > index c1763336..41480c9a 100644
> > --- a/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> > +++ b/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> > @@ -10,6 +10,27 @@
> > aliases {
> > spi0 =
> > };
> > +
> > + smbios {
> > + compatible = "u-boot,sysinfo-smbios";
> > +
> > + smbios {
> > + system {
> > + manufacturer = "khadas";
> > + product = "VIM2";
> > + };
> > +
> > + baseboard {
> > + manufacturer = "khadas";
> > + product = "VIM2";
> > + };
> > +
> > + chassis {
> > + manufacturer = "khadas";
> > + product = "VIM2";
> > + };
> > + };
> > + };
> > };
> >
> > _emmc_c {
> > diff --git a/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
> > b/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
> > index a591c0c9..06b81f23 100644
> > --- a/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
> > +++ b/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
> > @@ -6,3 +6,26 @@
> >
> > #include "meson-sm1-u-boot.dtsi"
> > #include "meson-khadas-vim3-u-boot.dtsi"
> > +
> > +/ {
> > + smbios {
> > + compatible = "u-boot,sysinfo-smbios";
> > +
> > + smbios {
> > + system {
> > + manufacturer = "khadas";
> > + product = "VIM3L";
> > + };
> > +
> > + baseboard {
> > + manufacturer = "khadas";
> > + product = "VIM3L";
> > + };
> > +
> > +
Re: [PATCH] evb_rk3399: add usb ohci definations
workable example for CONFIG_USB_OHCI_HCD and CONFIG_USB_OHCI_GENERIC (usb kbd on usb2.0 port) kedge# usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (12 Mb/s, 0mA) | U-Boot Root Hub | +-2 Human Interface (1.5 Mb/s, 100mA) Dell KB216 Wired Keyboard 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (12 Mb/s, 0mA) U-Boot Root Hub 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller and for usbkbd connected to usb3 port kedge# usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (12 Mb/s, 0mA) U-Boot Root Hub 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (12 Mb/s, 0mA) U-Boot Root Hub 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Human Interface (1.5 Mb/s, 100mA) Dell KB216 Wired Keyboard PS: usb2.0 port cant recognize any usb1.1 devices without OHCI On Wed, Jun 2, 2021 at 10:33 AM Art Nikpal wrote: > > > But , evb_rk3399 board does not enable CONFIG_USB_OHCI_HCD and > > CONFIG_USB_OHCI_GENERIC. > > yes i know it ! > > for example some other rk3399 boards have it because (usb 1.1 didnt > work without ohci on usb2.0 port and not possible to use usb kbd for > this port ) > > grep CONFIG_USB_OHCI_GENERIC configs/*3399* > configs/pinebook-pro-rk3399_defconfig:CONFIG_USB_OHCI_GENERIC=y > configs/rock960-rk3399_defconfig:CONFIG_USB_OHCI_GENERIC=y > configs/rockpro64-rk3399_defconfig:CONFIG_USB_OHCI_GENERIC=y > > many other boards which used TARGET_EVB_RK3399=y must have same > problem (with usb1.1) > > and i think other boards must have possibilities to use > CONFIG_USB_OHCI_HCD and CONFIG_USB_OHCI_GENERIC. > > grep EVB configs/*3399* > > configs/evb-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/firefly-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/khadas-edge-captain-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/khadas-edge-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/khadas-edge-v-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/leez-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/nanopc-t4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/nanopi-m4-2gb-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/nanopi-m4b-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/nanopi-m4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/nanopi-neo4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/nanopi-r4s-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/orangepi-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/rock-pi-4c-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/rock-pi-4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y > configs/rock-pi-n10-rk3399pro_defconfig:CONFIG_TARGET_EVB_RK3399=y > > On Tue, Jun 1, 2021 at 8:15 PM Kever Yang wrote: > > > > Hi Artem, > > > > On 2021/5/26 下午5:33, Artem Lapkin wrote: > > > Problem: not possible to use CONFIG_USB_OHCI_HCD=y and > > > CONFIG_USB_OHCI_GENERIC=y options without CONFIG_USB_OHCI_NEW and > > > CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS definations > > > > > > Add missed definations. > > > > But , evb_rk3399 board does not enable CONFIG_USB_OHCI_HCD and > > CONFIG_USB_OHCI_GENERIC. > > > > > > Thanks, > > > > - Kever > > > > > > > > Signed-off-by: Artem Lapkin > > > --- > > > include/configs/evb_rk3399.h | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h > > > index b7e85037..492b7b4d 100644 > > > --- a/include/configs/evb_rk3399.h > > > +++ b/include/configs/evb_rk3399.h > > > @@ -15,4 +15,7 @@ > > > > > > #define SDRAM_BANK_SIZE (2UL << 30) > > > > > > +#define CONFIG_USB_OHCI_NEW > > > +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 > > > + > > > #endif > > > >
Re: [PATCH] evb_rk3399: add usb ohci definations
> But , evb_rk3399 board does not enable CONFIG_USB_OHCI_HCD and > CONFIG_USB_OHCI_GENERIC. yes i know it ! for example some other rk3399 boards have it because (usb 1.1 didnt work without ohci on usb2.0 port and not possible to use usb kbd for this port ) grep CONFIG_USB_OHCI_GENERIC configs/*3399* configs/pinebook-pro-rk3399_defconfig:CONFIG_USB_OHCI_GENERIC=y configs/rock960-rk3399_defconfig:CONFIG_USB_OHCI_GENERIC=y configs/rockpro64-rk3399_defconfig:CONFIG_USB_OHCI_GENERIC=y many other boards which used TARGET_EVB_RK3399=y must have same problem (with usb1.1) and i think other boards must have possibilities to use CONFIG_USB_OHCI_HCD and CONFIG_USB_OHCI_GENERIC. grep EVB configs/*3399* configs/evb-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/firefly-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/khadas-edge-captain-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/khadas-edge-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/khadas-edge-v-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/leez-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/nanopc-t4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/nanopi-m4-2gb-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/nanopi-m4b-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/nanopi-m4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/nanopi-neo4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/nanopi-r4s-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/orangepi-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/rock-pi-4c-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/rock-pi-4-rk3399_defconfig:CONFIG_TARGET_EVB_RK3399=y configs/rock-pi-n10-rk3399pro_defconfig:CONFIG_TARGET_EVB_RK3399=y On Tue, Jun 1, 2021 at 8:15 PM Kever Yang wrote: > > Hi Artem, > > On 2021/5/26 下午5:33, Artem Lapkin wrote: > > Problem: not possible to use CONFIG_USB_OHCI_HCD=y and > > CONFIG_USB_OHCI_GENERIC=y options without CONFIG_USB_OHCI_NEW and > > CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS definations > > > > Add missed definations. > > But , evb_rk3399 board does not enable CONFIG_USB_OHCI_HCD and > CONFIG_USB_OHCI_GENERIC. > > > Thanks, > > - Kever > > > > > Signed-off-by: Artem Lapkin > > --- > > include/configs/evb_rk3399.h | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h > > index b7e85037..492b7b4d 100644 > > --- a/include/configs/evb_rk3399.h > > +++ b/include/configs/evb_rk3399.h > > @@ -15,4 +15,7 @@ > > > > #define SDRAM_BANK_SIZE (2UL << 30) > > > > +#define CONFIG_USB_OHCI_NEW > > +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 > > + > > #endif > >
Re: [PATCH] rk3399: boot_devices fix spinor node name
hi
> why "/spi@ff1d" is not work, this drivers should be work for other boards
> before.
i`m sure now is not work (maybe nobody test it ) i have test it and
can see its doesn't works properly
because /spi@ff1d just spi bus node - its not SPINOR-Flash node as
was written before
if we check u-boot,spl-boot-order for rk3399 boards is must be
bootable devices list (for example | _flash |
is alias for /spi@ff1d/flash@0 )
grep same-as-spl arch/arm/dts/*rk3399* | grep flash
arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi:
u-boot,spl-boot-order = "same-as-spl", , ,
arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi:"same-as-spl",
, ,
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi:
u-boot,spl-boot-order = "same-as-spl", _flash, ,
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi:u-boot,spl-boot-order =
"same-as-spl", _flash, ,
"same-as-spl" same must be translated to same devices ( _flash,
, )
grep "same device the SPL was" -A22 arch/arm/mach-rockchip/spl-boot-order.c
/* Handle the case of 'same device the SPL was loaded from' */
if (strncmp(conf, "same-as-spl", 11) == 0) {
conf = board_spl_was_booted_from();
if (!conf)
continue;
}
/* First check if the list element is an alias */
alias = fdt_get_alias(blob, conf);
if (alias)
conf = alias;
/* Try to resolve the config item (or alias) as a path */
node = fdt_path_offset(blob, conf);
if (node < 0) {
debug("%s: could not find %s in FDT\n", __func__, conf);
continue;
}
/* Try to map this back onto SPL boot devices */
boot_device = spl_node_to_boot_device(node);
if (boot_device < 0) {
debug("%s: could not map node @%x to a boot-device\n",
grep "UCLASS_SPI_FLASH" arch/arm/mach-rockchip/spl-boot-order.c
} else if (!uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node,
if (!uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node, ))
grep SPINOR arch/arm/mach-rockchip/rk3399/rk3399.c
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d",
but its not SPI_FLASH and spl_node_to_boot_device(/spi@ff1d)
return always -1 and
u-boot,spl-boot-order = "same-as-spl" never works properly for spinorflash
PS: i have test spi@ff1d/flash@0 works properly as expected
On Tue, Jun 1, 2021 at 8:09 PM Kever Yang wrote:
>
> Hi Artem,
>
> On 2021/5/26 下午5:32, Artem Lapkin wrote:
> > Problem: board_spl_was_booted_from return wrong boot_devices[3] value
> > /spi@ff1d and same-as-spl dont work properly for SPINOR flash
> > because arch/arm/mach-rockchip/spl-boot-order.c spl_node_to_boot_device
> > need parse SPINOR flash node as UCLASS_SPI_FLASH
> >
> > spl-boot-order: same-as-spl > *** BOOT_SOURCE_ID 3 (2:emmc 3:spi 5:sd ...
> > /spi@ff1d > board_boot_order: could not map node @618 to a boot-device
> > /sdhci@fe33 > /mmc@fe32
> >
> > Solution: just change it to /spi@ff1d/flash@0
>
> I don't understand why the solution is add "/flash@0" and why
> "/spi@ff1d " is not work, this drivers should be work for other
> boards before.
>
>
> Thanks,
>
> - Kever
>
> >
> > spl-boot-order: same-as-spl > *** BOOT_SOURCE_ID 3 (2:emmc 3:spi 5:sd ...
> > /spi@ff1d/flash@0 > /sdhci@fe33 > /mmc@fe32
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> > b/arch/arm/mach-rockchip/rk3399/rk3399.c
> > index 869d2159..69e0c8c2 100644
> > --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> > +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> > @@ -28,7 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> > const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> > - [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d",
> > + [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
> > [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
> > };
> >
>
>
Re: [PATCH] DTS: khadas-vim2 spi-flash change spi-max-frequency v2
just ignore - this patch - it was wrong - sorry ;-)
On Thu, May 27, 2021 at 4:37 PM Artem Lapkin wrote:
>
> change max freq to 104Mhz for SPI-NOR flash
>
> Signed-off-by: Artem Lapkin
> ---
> arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> b/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> index c1763336cf..247817adea 100644
> --- a/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> +++ b/arch/arm/dts/meson-gxm-khadas-vim2-u-boot.dtsi
> @@ -18,5 +18,6 @@
> };
>
> {
> + spi-max-frequency = <10400>;
> status = "okay";
> };
> --
> 2.25.1
>
Re: [PATCH 2/2] arm64: dts: meson: fix meson-khadas-vim3-u-boot.dtsi
> It's not necessary since already included in: Yes u right ! Sorry ! On Fri, Jan 15, 2021 at 4:15 PM Neil Armstrong wrote: > Hi, > > > On 15/01/2021 06:15, Artem Lapkin wrote: > > Add missed include meson-g12-common-u-boot.dtsi > > > > PROBLEM: missed hdmi video setup for VIM3 and VIM3L boards > > > > Signed-off-by: Artem Lapkin > > --- > > arch/arm/dts/meson-khadas-vim3-u-boot.dtsi | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi > b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi > > index 81fd5be378..5d6444cbac 100644 > > --- a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi > > +++ b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi > > @@ -10,6 +10,8 @@ > > }; > > }; > > > > +#include "meson-g12-common-u-boot.dtsi" > > + > > It's not necessary since already included in: > arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi:#include > "meson-g12-common-u-boot.dtsi" > and > arch/arm/dts/meson-sm1-u-boot.dtsi:#include "meson-g12-common-u-boot.dtsi" > > What u-boot version are you using ? > Please check u-boot-master and my u-boot-amlogic and u-boot-amlogic-next > branches on https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic > before posting ! > > Thanks, > Neil >
Re: [PATCH] board: amlogic: vim3: setup ethernet mac from efuse
> So the patch from Marek (
https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/)
doesn't work ?
yes doesnt works properly im sure if we read as raw 6 bytes from efuse we
have
if (is_valid_ethaddr(mac_addr)) # is always not valid
eth_env_set_enetaddr("ethaddr", mac_addr);
else# and always
generated from serial meson_generate_serial_ethaddr();
> Are you sure the MAC is stored in ASCII like Odroid-N2 ?
yes im check two times on my vim3 vim3l boards and our amlogic vendor uboot
have same method
On Mon, Jan 11, 2021 at 9:59 PM Neil Armstrong
wrote:
> Hi Artem,
>
> On 11/01/2021 12:19, Artem Lapkin wrote:
> > Add the board specific code for reading built-in ethernet MAC address
> from efuse
> >
> > NOTE: MAC is stored in ASCII format, 1bytes = 2characters by 0 offset
> >
> > if mac from efuse not valid we use meson_generate_serial_ethaddr
> >
> > NOTE: remake odroid-n2.c variant from Neil Armstrong <
> narmstr...@baylibre.com>
>
> So the patch from Marek (
> https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/)
> doesn't work ?
> Are you sure the MAC is stored in ASCII like Odroid-N2 ?
>
> Please look at my u-boot-amlogic-next tree I will push this week for the
> next u-boot release:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/-/tree/u-boot-amlogic-next
>
> Neil
>
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > board/amlogic/vim3/vim3.c | 35 +++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
> > index 09ef39ff30..c5d19cc17b 100644
> > --- a/board/amlogic/vim3/vim3.c
> > +++ b/board/amlogic/vim3/vim3.c
> > @@ -11,9 +11,14 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include "khadas-mcu.h"
> >
> > +#define EFUSE_MAC_OFFSET 0
> > +#define EFUSE_MAC_SIZE 12
> > +#define MAC_ADDR_LEN 6
> > +
> > /*
> > * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> > * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> > @@ -131,7 +136,37 @@ int meson_ft_board_setup(void *blob, struct bd_info
> *bd)
> >
> > int misc_init_r(void)
> > {
> > + u8 mac_addr[MAC_ADDR_LEN];
> > + char efuse_mac_addr[EFUSE_MAC_SIZE], tmp[3];
> > + ssize_t len;
> > +
> > meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
> >
> > + if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
> > +
> > + len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
> efuse_mac_addr, EFUSE_MAC_SIZE);
> > + if (len != EFUSE_MAC_SIZE)
> > + return 0;
> > +
> > + /* MAC is stored in ASCII format, 1bytes = 2characters */
> > + for (int i = 0; i < 6; i++) {
> > + tmp[0] = efuse_mac_addr[i * 2];
> > + tmp[1] = efuse_mac_addr[i * 2 + 1];
> > + tmp[2] = '\0';
> > + mac_addr[i] = simple_strtoul(tmp, NULL, 16);
> > + }
> > +
> > + if (is_valid_ethaddr(mac_addr))
> > + eth_env_set_enetaddr("ethaddr", mac_addr);
> > + else
> > + meson_generate_serial_ethaddr();
> > +
> > + eth_env_get_enetaddr("ethaddr", mac_addr);
> > + printf("[i] setup onboard mac
> %02X:%02X:%02X:%02X:%02X:%02X\n",
> > + mac_addr[0],mac_addr[1],mac_addr[2],
> > + mac_addr[3],mac_addr[4],mac_addr[5]);
> > +
> > + }
> > +
> > return 0;
> > }
> >
>
>
Re: [PATCH] board: amlogic: vim3: ethernet mac fixed from serial
plz ignore my prev emails
> AFAIK, it's fixed with Marek's patch
>
https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/
look like yes ! u right
Best regards Art
On Mon, Jan 11, 2021 at 9:27 AM Art Nikpal wrote:
> > AFAIK, it's fixed with Marek's patch
> >
> https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/
>
> not solve !
> because mac which must stored in mcu is empty by default
> and by default we have random mac every time
>
> i think i will make new complex patch from both patches
>
> On Mon, Jan 11, 2021 at 6:46 AM Jaehoon Chung
> wrote:
>
>> Hi,
>>
>> On 1/8/21 2:43 PM, Artem Lapkin wrote:
>> > Fixed randomly generated ethernet mac address!
>> >
>> > Used meson_generate_serial_ethaddr for generate mac address from
>> > board serial number, if ethaddr variable not defined.
>>
>> AFAIK, it's fixed with Marek's patch
>>
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/
>>
>> Best Regards,
>> Jaehoon CHung
>>
>> >
>> > Signed-off-by: Artem Lapkin
>> > ---
>> > board/amlogic/vim3/vim3.c | 9 +
>> > 1 file changed, 9 insertions(+)
>> >
>> > diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
>> > index 09ef39ff30..0315eaf569 100644
>> > --- a/board/amlogic/vim3/vim3.c
>> > +++ b/board/amlogic/vim3/vim3.c
>> > @@ -133,5 +133,14 @@ int misc_init_r(void)
>> > {
>> > meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
>> >
>> > + u8 mac_addr[6];
>> > + if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
>> > + meson_generate_serial_ethaddr();
>> > + eth_env_get_enetaddr("ethaddr", mac_addr);
>> > + printf("[i] serial eth mac
>> %02X:%02X:%02X:%02X:%02X:%02X\n",
>> > + mac_addr[0],mac_addr[1],mac_addr[2],
>> > + mac_addr[3],mac_addr[4],mac_addr[5]);
>> > + }
>> > +
>> > return 0;
>> > }
>> >
>>
>>
Re: [PATCH] board: amlogic: vim3: ethernet mac fixed from serial
> AFAIK, it's fixed with Marek's patch
>
https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/
not solve !
because mac which must stored in mcu is empty by default
and by default we have random mac every time
i think i will make new complex patch from both patches
On Mon, Jan 11, 2021 at 6:46 AM Jaehoon Chung
wrote:
> Hi,
>
> On 1/8/21 2:43 PM, Artem Lapkin wrote:
> > Fixed randomly generated ethernet mac address!
> >
> > Used meson_generate_serial_ethaddr for generate mac address from
> > board serial number, if ethaddr variable not defined.
>
> AFAIK, it's fixed with Marek's patch
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20201217072642.1319-1-m.szyprow...@samsung.com/
>
> Best Regards,
> Jaehoon CHung
>
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > board/amlogic/vim3/vim3.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
> > index 09ef39ff30..0315eaf569 100644
> > --- a/board/amlogic/vim3/vim3.c
> > +++ b/board/amlogic/vim3/vim3.c
> > @@ -133,5 +133,14 @@ int misc_init_r(void)
> > {
> > meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
> >
> > + u8 mac_addr[6];
> > + if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
> > + meson_generate_serial_ethaddr();
> > + eth_env_get_enetaddr("ethaddr", mac_addr);
> > + printf("[i] serial eth mac
> %02X:%02X:%02X:%02X:%02X:%02X\n",
> > + mac_addr[0],mac_addr[1],mac_addr[2],
> > + mac_addr[3],mac_addr[4],mac_addr[5]);
> > + }
> > +
> > return 0;
> > }
> >
>
>
[U-Boot] (no subject)
Hi there We're pleased to inform that your organisation has been invited to participate in the exclusive monthly Art of England Magazine September 2011 edition, and beyond. Now seven years old, the Art of England Magazine offers you an excellent monthly targeted distribution throughout the UK and abroad, providing a highly successful reach to the art and luxury market sectors (full distribution details available at link below). Participants range from art galleries, dealers, auctioneers and associated professions, through to those who wish to contact this financially capable demographic for their products and services, reaping the appropriate business development from this high net worth audience. The editorial content too, as you might imagine, is 'top drawer' and commensurate with the subject matter (example edition available via link below). Regarding your potential participation, we're pleased to tell you that the Special Introductory Rate for booking for the coming September 2011 Edition is now open and we would like to offer you the extended reduced 'welcome' rate of just £950.00 total for a full A4 page advertisement (usual premium position list price £1350.00), a double page spread at £1650.00, or a half page at £500.00. This will enable you to try out the response from this financially capable fine art audience at limited risk to yourselves (usual rate card and media kit links also below). We look forward to hearing your thoughts when you have a moment! Kind regards Deni Parkes for ART OF ENGLAND MAGAZINE T: +44 (0)203 286 8737 ddi F: +44 (0)207 183 4752 or via accounts team +44 (0) 207 607 0717 W: www.artofengland.uk.com Downloads: Rate Card - http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_RateCard.pdf Media Kit - http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_MediaPack.pdf Distribution - http://artofengland.uk.com/advertise Example edition - http://www.pmbmedia.co.uk/ezine/aoedec10/fullpage.html Contracted exclusively by: SKS/Enhanced Media Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK Bringing the top drawer to you! ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Art of England Magazine - July 2011 edition+ - your invitation to advertise
Hi there We hope that you're a little familiar by now with the exclusive monthly Art of England Magazine. Many similar organisations to yours have used the magazine recently as a marketing 'channel' to reach its financially capable readership for their products and services (example edition available via link below), and to great effect. If it's ok with you, we'd like to offer you the opportunity to try this established channel for new business and corporate branding for yourselves at limited financial risk. You might be interested to learn that the Special Introductory Rate for booking for the July 2011 Edition is still just available, and until 15th May 2011 (copy/images deadline) we would like to offer you the extended reduced 'trial' rate of just £950.00 total for a full A4 page advertisement (list price for premium position usually £1350.00, media pack links below), £1750.00 for a double page spread, or £475.00 for a half page, all of which will enable to to capture the attention of Art of England's wealthy audience. (Covers too are sometimes available). To book for this attractive introductory rate offer, simply reply to this email with the phrase '[your chosen ad size] - Yes please' no later than 14th May 2011 to begin developing your business in this exclusive demographic. We hope you will elect to try this 'niche' approach, and look forward to the prospect of welcoming you aboard! Kind regards Deni Parkes for ART OF ENGLAND MAGAZINE T: +44 (0)845 428 9350 F: +44 (0)207 183 4752 W: www.artofengland.uk.com Downloads: Media Kit : http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_MediaPack.pdf Rate Card : http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_RateCard.pdf Distribution : http://artofengland.uk.com/advertise Example edition : http://www.pmbmedia.co.uk/ezine/aoedec10/fullpage.html Contracted exclusively by: SKS/Enhanced Media Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK Bringing the top drawer to you! ** You were subscribed to this special offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Art of England Magazine - April 2011 edition - your invitation, deadline 3 days
Hi there How are you doing over there?! 2011 off to a good start?! We're pleased to inform you that your organisation has been invited to participate in the exclusive Art of England Magazine, April 2011 edition, copy deadline for which is almost here. Now seven years old, the Art of England Magazine offers you an effective monthly targeted distribution throughout the UK and abroad, providing you with reach to the wealthy art and luxury market sectors (full distribution details available through links below). Participants range from art galleries, dealers, auctioneers, investors and associated professions, through to those who wish to contact this financially capable demographic for their products and services, enjoying the appropriate business development from the sought-after readership. The editorial content too, as you might imagine, is suitably exclusive, and commensurate with the subject matter (current edition available via links below). Regarding your organisation and your potential participation, we're pleased to tell you that the Special Introductory Rate for booking for the April 2011 Edition is now on offer, and until 14th Feb (copy/images deadline) we would like to offer you the extended reduced 'trial' rate of just £925.00 total for a full A4 page advertisement (list price for premium position usually £1350.00), or £475.00 for an eye-catching half page, and just £265.00 for a quarter page. Once you have seen the effectiveness of this sales and PR channel, we would, of course, hope that you might elect to appear regularly later in subsequent editions, and other more extensive premium spots are available by request for your 2011-12 media schedule (e.g. covers, editorials). However, to book for this attractive trial rate offer for the April 2011 Edition, simply reply to this email with the phrase '[your chosen ad size] - Yes please' no later than 14th Feb 2011 to begin reaching this high net worth audience now available to your organisation. We look forward to hearing from you. Kind regards Deni Parkes for ART OF ENGLAND MAGAZINE T: +44 (0)845 428 9350 F: +44 (0)207 183 4752 W: www.artofengland.uk.com Usual Media Kit: http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_MediaPack.pdf Rate Card: http://www.sksassociates.co.uk/aofe/ArtOfEnglandMagazine_RateCard.pdf Distribution: http://www.artofengland.uk.com/advertise.php Example edition: http://www.pmbmedia.co.uk/ezine/aoedec10/fullpage.html Contracted exclusively by: SKS/Enhanced Media Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK Bringing the top drawer to you! ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Art of England Magazine - April 2011 edition - your invitation, deadline 3 days
Hi there How are you doing over there?! 2011 off to a good start?! We're pleased to inform you that your organisation has been invited to participate in the exclusive Art of England Magazine, April 2011 edition, copy deadline for which is almost here. Now seven years old, the Art of England Magazine offers you an effective monthly targeted distribution throughout the UK and abroad, providing you with reach to the wealthy art and luxury market sectors (full distribution details available through links below). Participants range from art galleries, dealers, auctioneers, investors and associated professions, through to those who wish to contact this financially capable demographic for their products and services, enjoying the appropriate business development from the sought-after readership. The editorial content too, as you might imagine, is suitably exclusive, and commensurate with the subject matter (current edition available via links below). Regarding your organisation and your potential participation, we're pleased to tell you that the Special Introductory Rate for booking for the April 2011 Edition is now on offer, and until 12th Feb (copy/images deadline) we would like to offer you the extended reduced 'trial' rate of just £925.00 total for a full A4 page advertisement (list price for premium position usually £1350.00), or £475.00 for an eye-catching half page, and just £265.00 for a quarter page. Once you have seen the effectiveness of this sales and PR channel, we would, of course, hope that you might elect to appear regularly later in subsequent editions, and other more extensive premium spots are available by request for your 2011-12 media schedule (e.g. covers, editorials). However, to book for this attractive trial rate offer for the April 2011 Edition, simply reply to this email with the phrase '[your chosen ad size] - Yes please' no later than 12th Feb 2011 to begin reaching this high net worth audience now available to your organisation. We look forward to hearing from you. Kind regards Deni Parkes for ART OF ENGLAND MAGAZINE T: +44 (0)845 428 9350 F: +44 (0)207 183 4752 W: www.artofengland.uk.com Usual Media Kit: http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_MediaPack.pdf Rate Card: http://www.sksassociates.co.uk/aofe/ArtOfEnglandMagazine_RateCard.pdf Distribution: http://www.artofengland.uk.com/advertise.php Example edition: http://www.pmbmedia.co.uk/ezine/aoedec10/fullpage.html Contracted exclusively by: SKS/Enhanced Media Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK Bringing the top drawer to you! ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Art of England Magazine - March 2011 edition - Introduction AdRate Offer until 15th Jan
Hi there Happy New year from all of us over here! We're pleased to inform you that your organisation has been invited to participate in the exclusive Art of England Magazine, March 2011 edition, deadline for which is now just 4 days away. Now seven years old, the Art of England Magazine offers you an effective monthly targeted distribution throughout the UK and abroad, providing you with a lucrative reach to the elusive art and luxury market sectors (full distribution details available here). Participants range from art galleries, dealers, auctioneers, investors and associated professions, through to those who wish to contact this financially capable demographic for their products and services, enjoying the appropriate business development from our sought-after readership. The editorial content too, as you might imagine, is suitably exclusive, and commensurate with the subject matter (current edition available via website below). Regarding your organisation and your potential participation, we're pleased to tell you that the Special Introductory Rate for booking for the coming March 2011 Edition has just been extended slightly, and until 15th January 2011 we would like to offer you the extended reduced 'trial' rate of just £950.00 total for a full A4 page advertisement (list price £1250.00, usual rate card available on request), or £500.00 for a half page, or just £275.00 for a quarter! Once you have seen the effectiveness of this sales and PR channel, we would, of course, hope that you might elect to appear regularly later in subsequent editions. To book for this attractive trial rate offer for the March 2011 Edition, simply reply to this email with your preferred ad size no later than 15th January 2011 to begin reaching this high net worth audience now available to your organisation. Thanks for your time, and we hope to be welcoming you aboard very shortly! Kind regards Deni Parkes for Art of England Magazine T: +44 (0)845 80 55 173 F: +44 (0)207 183 4752 W: www.artofengland.uk.com Media Kit available on request Contracted exclusively by: SKS/Enhanced Media Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
