Re: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, (and happy new year ;-) On Thu, 6 Jan 2022 at 07:09, Sahil Malhotra (OSS) < sahil.malho...@oss.nxp.com> wrote: > Hi Michael, > > > -Original Message- > > From: Michael Walle > > Sent: Thursday, December 23, 2021 3:05 PM > > To: Sahil Malhotra (OSS) > > Cc: ZHIZHIKIN Andrey ; Clément > Faure > > ; Gaurav Jain ; Pankaj Gupta > > ; Priyanka Jain ; u- > > b...@lists.denx.de; Varun Sethi ; Ye Li > > Subject: Re: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay > feature > > > > Hi Sahil, > > > > Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS): > > >> -Original Message- > > >> From: U-Boot On Behalf Of Michael > > >> Walle > > >> Sent: Monday, December 20, 2021 6:23 PM > > >> To: Sahil Malhotra (OSS) > > >> Cc: ZHIZHIKIN Andrey ; Clément > > >> Faure ; Gaurav Jain ; > > >> Pankaj Gupta ; Priyanka Jain > > >> ; u-boot@lists.denx.de; Varun Sethi > > >> ; Ye Li > > >> Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay > > >> feature > > >> > > >> Caution: EXT Email > > >> > > >> Hi Sahil, > > >> > > >> Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): > > >> >> DT nodes can be statically disabled if we know that they are held > > >> >> by HAB and are not released to NS World. > > >> >> > > >> >> OP-TEE does set the status itself via dt_enable_secure_status(), > > >> >> which should present the properly configured FDT when U-Boot takes > > >> over. > > >> > Yes, OP-TEE set the status by dt_enable_secure_status() in DTB > > >> > overlay which gets merged with DTB provided for Linux bootup and > > >> > then Linux boots with merged DTB. > > >> > But u-boot uses the DTB embedded in its image. How can we modify > > >> > that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? > > >> > > >> But then u-boot has the "wrong" dtb. What is the reason, there is an > > >> overlay instead of a whole dtb? what if the overlay doesn't match the > > >> dtb? > > > "wrong" dtb means that uboot will not be aware of CAAM job ring which > > > is taken by OP-TEE and uboot on LS platforms currently use JR0, which > > > is not being used by any other entity in LS bootflow. > > > > I don't know I follow. u-boot and linux should have the same device tree; > > regardless if that device is used or not. So applying the overlay just > for linux isn't > > enough here. > Ok, I don't think that as of now, in all platforms uboot and linux have > same devie > tree. > But I will try to address your concern, but I don’t know how to apply > overlay to > dtb which is embedded in u-boot binary, Can you please point me to one > reference > which is doing this thing, I will take reference from there. > > > > We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE > > > reserves One Job Ring for its use and that is communicated to Kernel > > > using DTB overlay. > > > > > >> what if the overlay doesn't match the dtb? > > > I didn't get this point, can you please elaborate a little. > > > > You are merging a dtb fragment with an unknown dtb, right? Who says they > > match? you might have an old dtb where the supplied dtb fragment doesn't > > make any sense. > > > > I might be missing something here. Eg. where is the linux dtb supposed > to come > > from? This patchset is really missing an example and a description how > things > > should work. > If supplied DTB does not match with DTB overlay fragment. then overlay > will not get applied. > We don't have any control on where user picks the DTB, but we can only > make sure DTB > overlay feature must work with DTBs which are upstreamed > If user makes its own customized DTB, we cannot make sure that things will > work. > > Elaborating on a broader context: who is the user in U-Boot? In desktops/laptops context, I understand the user could be the desktop/laptop owner but based on my limited understanding of Chrome, users are quite constrained in what they can do (allowing the user to play with DT is a recipe for costly support). In the embedded case, is the user the one who makes a board based on the SoC ? the product maker that uses the board for a particular solution ? the integrator who places the board in a larger product ? the larger product maker ? the larger product owner ? the larger product maintenance guy? ultimately I think there is a need to empower a number of actors listed above who will take the responsibility based on consultation from the software value chain. All this to say I believe we lack vocabulary to identify actors in the firmware software value chain: has anyone already tried to formalize this? Regards, > Sahil Malhotra >
Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2022-01-06 07:09, schrieb Sahil Malhotra (OSS): I don't know I follow. u-boot and linux should have the same device tree; regardless if that device is used or not. So applying the overlay just for linux isn't enough here. Ok, I don't think that as of now, in all platforms uboot and linux have same devie tree. That doesn't mean it is ok to diverge again. I put a lot of effort in syncing uboot's LS1028A device tree with linux. But I will try to address your concern, but I don’t know how to apply overlay to dtb which is embedded in u-boot binary, Can you please point me to one reference which is doing this thing, I will take reference from there. Sorry I can't advise you with that. There is board_fix_fdt() maybe that will help. But I'm not conviced this is the correct approach, see below. > We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE > reserves One Job Ring for its use and that is communicated to Kernel > using DTB overlay. > >> what if the overlay doesn't match the dtb? > I didn't get this point, can you please elaborate a little. You are merging a dtb fragment with an unknown dtb, right? Who says they match? you might have an old dtb where the supplied dtb fragment doesn't make any sense. I might be missing something here. Eg. where is the linux dtb supposed to come from? This patchset is really missing an example and a description how things should work. If supplied DTB does not match with DTB overlay fragment. then overlay will not get applied. I don't think this is what happens here. fdt_overlay_apply() will mark the fdt as damaged and there will be no fdt at all. We don't have any control on where user picks the DTB, but we can only make sure DTB overlay feature must work with DTBs which are upstreamed If user makes its own customized DTB, we cannot make sure that things will work. Again. Is there any documentation on how this should all work together? Where does optee get its device tree from? Shouldn't it be the same device tree as u-boot and linux? Shouldn't optee modify the device tree in place before jumping back to u-boot? Andrey, do you know how this works on imx? -michael
Re: [RFC v2 15/20] efi_loader: disk: a helper function to create efi_disk objects from udevice
On Sun, Jan 02, 2022 at 10:18:18AM +0100, Heinrich Schuchardt wrote:
> On 12/10/21 07:49, AKASHI Takahiro wrote:
> > Add efi_disk_probe() function.
> > This function creates an efi_disk object for a raw disk device (UCLASS_BLK)
> > and additional objects for related partitions (UCLASS_PARTITION).
> >
> > So this function is expected to be called through driver model's "probe"
> > interface every time one raw disk device is detected and activated.
> > We assume that partition devices (UCLASS_PARTITION) have been created
> > when this function is invoked.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_loader.h | 4 +-
> > lib/efi_loader/Kconfig | 2 +
> > lib/efi_loader/efi_disk.c | 206 -
> > lib/efi_loader/efi_setup.c | 11 +-
> > 4 files changed, 142 insertions(+), 81 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index d52e399841ba..a51095930efa 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -519,8 +519,8 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t
> > debug_disposition,
> > void efi_carve_out_dt_rsv(void *fdt);
> > /* Called by bootefi to make console interface available */
> > efi_status_t efi_console_register(void);
> > -/* Called by bootefi to make all disk storage accessible as EFI objects */
> > -efi_status_t efi_disk_register(void);
> > +/* Called by efi_init_obj_list() to initialize efi_disks */
> > +efi_status_t efi_disk_init(void);
> > /* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */
> > efi_status_t efi_rng_register(void);
> > /* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 700dc838ddb9..108c00343fce 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -11,6 +11,7 @@ config EFI_LOADER
> > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
> > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
> > depends on BLK
> > + depends on EVENT
> > depends on DM_ETH || !NET
> > depends on !EFI_APP
> > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
> > @@ -41,6 +42,7 @@ config CMD_BOOTEFI_BOOTMGR
> >
> > config EFI_SETUP_EARLY
> > bool
> > + default y
> >
> > choice
> > prompt "Store for non-volatile UEFI variables"
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index 45127d176869..2941b0c3db47 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -10,6 +10,9 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > @@ -487,103 +490,158 @@ error:
> > return ret;
> > }
> >
> > -/**
> > - * efi_disk_create_partitions() - create handles and protocols for
> > partitions
> > +/*
> > + * Create a handle for a whole raw disk
> >*
> > - * Create handles and protocols for the partitions of a block device.
> > + * @devuclass device (UCLASS_BLK)
> >*
> > - * @parent:handle of the parent disk
> > - * @desc: block device
> > - * @if_typename: interface type
> > - * @diskid:device number
> > - * @pdevname: device name
> > - * Return: number of partitions created
> > + * Create an efi_disk object which is associated with @dev.
> > + * The type of @dev must be UCLASS_BLK.
> > + *
> > + * @return 0 on success, -1 otherwise
> >*/
> > -int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
> > - const char *if_typename, int diskid,
> > - const char *pdevname)
> > +static int efi_disk_create_raw(struct udevice *dev)
> > {
> > - int disks = 0;
> > - char devname[32] = { 0 }; /* dp->str is u16[32] long */
> > - int part;
> > - struct efi_device_path *dp = NULL;
> > + struct efi_disk_obj *disk;
> > + struct blk_desc *desc;
> > + const char *if_typename;
> > + int diskid;
> > efi_status_t ret;
> > - struct efi_handler *handler;
> >
> > - /* Get the device path of the parent */
> > - ret = efi_search_protocol(parent, _guid_device_path, );
> > - if (ret == EFI_SUCCESS)
> > - dp = handler->protocol_interface;
> > -
> > - /* Add devices for each partition */
> > - for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> > - struct disk_partition info;
> > -
> > - if (part_get_info(desc, part, ))
> > - continue;
> > - snprintf(devname, sizeof(devname), "%s:%x", pdevname,
> > -part);
> > - ret = efi_disk_add_dev(parent, dp, if_typename, desc, diskid,
> > - , part, NULL);
> > - if (ret != EFI_SUCCESS) {
> > - log_err("Adding partition %s failed\n", pdevname);
> > -
Re: [PATCH v2] rockchip: timer: add OF_PLATDATA support for dw-apb-timer
Hi Johan,
On Wed, 5 Jan 2022 at 09:40, Johan Jonker wrote:
>
> Hi Simon,
>
> Thanks you for your comments.
> Shown below are the objdump results of the full U-boot binary
> dw_apb_timer_of_to_plat() function.
> Same goes for the dw_apb_timer_probe() function.
> With if (IS_ENABLED(OF_REAL)) I don't get a useful timer result (boot
You need CONFIG_IS_ENABLED(OF_REAL)
(please could you avoid top posting?)
Regards,
Simon
> hangs after timer probe, because in full U-boot the reg value isn't
> correct defined. Part of the init probe is missing.
>
> Could you try it yourself?
> Please advise what options we have.
>
> Kind regards,
>
> Johan Jonker
>
> ==
> Patch version 1 with if (IS_ENABLED(OF_REAL)) {}:
>
> arm-linux-gnueabihf-objdump -d drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-v1.asm
>
>
> :
>0: 2000movsr0, #0
>2: 4770bx lr
>
> arm-linux-gnueabihf-objdump -d spl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-spl-v1.asm
> arm-linux-gnueabihf-objdump -d tpl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-tpl-v1.asm
> ==
> patch version 2 with #if CONFIG_IS_ENABLED(OF_REAL):
>
> arm-linux-gnueabihf-objdump -d drivers/timer/dw-apb-timer.o > ../dw-apb-
> timer-20220105-v2.asm
>
> :
>0: b538push{r3, r4, r5, lr}
>2: 4605mov r5, r0
>4: f7ff fffe bl 0
>8: 4604mov r4, r0
>a: 4628mov r0, r5
>c: f7ff fffe bl 0
> 10: 6020str r0, [r4, #0]
> 12: 2000 movs r0, #0
> 14: bd38pop {r3, r4, r5, pc}
>
> arm-linux-gnueabihf-objdump -d spl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-spl-v2.asm
> arm-linux-gnueabihf-objdump -d tpl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-tpl-v2.asm
>
> ===
>
> On 1/5/22 3:03 PM, Simon Glass wrote:
> > Hi Johan,
> >
> > On Tue, 4 Jan 2022 at 19:15, Johan Jonker wrote:
> >>
> >> The Rockchip rk3066 SoC has 3 dw-apb-timer nodes.
> >> U-boot is compiled with OF_PLATDATA TPL/SPL options,
> >> so add OF_PLATDATA support for the dw-apb-timer.
> >> Also change driver name to be able to compile with
> >> U-boot scripts. No reset OF_PLATDATA support was added,
> >> because the rk3066 nodes don't need/have them.
> >>
> >> Signed-off-by: Johan Jonker
> >> ---
> >>
> >> Changed V2:
> >> replace if (IS_ENABLED(OF_REAL)) by #if CONFIG_IS_ENABLED(OF_REAL)
> >> ---
> >> drivers/timer/dw-apb-timer.c | 30 +-
> >> 1 file changed, 25 insertions(+), 5 deletions(-)
> >>
> >
> > This seems OK but you have included unrelated changes (whitespace)
> > which should go in a separate patch.
>
> OK
> With whitespace did you mean this or something else?
>
> - .of_to_plat = dw_apb_timer_of_to_plat,
> + .of_to_plat = dw_apb_timer_of_to_plat,
>
> >
> > Can you use if() instead of #if for the CONFIG_IS_ENABLED(OF_REAL) ?
>
> See comments above.
> Currently not it seems.
>
> >
> > Regards,
> > Simon
> >
Re: [PATCH] Revert "clk: Detect failure to set defaults"
Hi,
On Wed, 5 Jan 2022 at 13:57, Tom Rini wrote:
>
> On Wed, Jan 05, 2022 at 08:56:50PM +0100, Marek Vasut wrote:
> > On 1/5/22 20:37, Tom Rini wrote:
> > > On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
> > > > On 1/1/22 22:41, Sean Anderson wrote:
> > > > > Hi Marek,
> > > >
> > > > Hi,
> > > >
> > > > > Please CC clock maintainers for future patches.
> > > >
> > > > btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646
> > > > has
> > > > zero reviews/acks from clock maintainers.
> > > >
> > > > > On 1/1/22 1:51 PM, Marek Vasut wrote:
> > > > > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> > > > > > The aforementioned patch causes massive breakage on all platforms
> > > > > > which
> > > > > > have 'assigned-clock' DT property in their DT which references any
> > > > > > clock
> > > > > > that are not supported by the platform clock driver. That can easily
> > > > > > happen either in SPL, or because the clock driver is reduced.
> > > > > > Currently
> > > > > > it seems all iMX8M are affected and fail to boot altogether.
> > > > > >
> > > > > > Signed-off-by: Marek Vasut
> > > > > > Cc: Peng Fan
> > > > > > Cc: Simon Glass
> > > > > > ---
> > > > > >drivers/clk/clk-uclass.c | 6 +-
> > > > > >1 file changed, 1 insertion(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > > > > index f2d26427543..094b1abf13c 100644
> > > > > > --- a/drivers/clk/clk-uclass.c
> > > > > > +++ b/drivers/clk/clk-uclass.c
> > > > > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
> > > > > > clk *clk)
> > > > > >int clk_uclass_post_probe(struct udevice *dev)
> > > > > >{
> > > > > > -int ret;
> > > > > > -
> > > > > >/*
> > > > > > * when a clock provider is probed. Call clk_set_defaults()
> > > > > > * also after the device is probed. This takes care of cases
> > > > > > * where the DT is used to setup default parents and rates
> > > > > > * using assigned-clocks
> > > > > > */
> > > > > > -ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > > > > -if (ret)
> > > > > > -return log_ret(ret);
> > > > > > +clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > > > >return 0;
> > > > > >}
> > > > > >
> > > > >
> > > > > See [1] for previous discussion. For more background,
> > > > >
> > > > > - Device trees for i.MX are sync'd with Linux.
> > > > > - General clock assignments may live in the clock-controller node,
> > > >
> > > > clock assignments can be anywhere, even in non-clock-controller nodes.
> > > >
> > > > > including those which U-Boot does not implement, but which Linux
> > > > > does.
> > > > > It's OK to not set up these clocks, but U-Boot doesn't know that
> > > > > and
> > > > > fails.
> > > > >
> > > > > We don't necessarily need to revert this commit, but we do need a way
> > > > > to
> > > > > say "it's OK not to set the defaults, since we can function without
> > > > > them". Tom suggested doing this in the clock driver last time. I
> > > > > think a
> > > > > Kconfig or a device tree property would work, perhaps something like
> > > > > 'u-boot,clock-defaults-optional'.
> > > >
> > > > We didn't need custom DT properties before, Linux doesn't need them
> > > > either,
> > > > so that approach seems wrong.
> > > >
> > > > If the clock driver could say "skip unimplemented clock, because I don't
> > > > implement them and that is OK", that sounds like the right approach.
> > > >
> > > > Unless the 2022.01 release should be completely broken for a lot of
> > > > platforms, I would propose we revert the clock uclass patch now and
> > > > re-add
> > > > it right after the release, so we would not roll out a completely broken
> > > > release and would have more time to fix this properly.
> > >
> > > It'll be no more broken than v2021.10 was for whatever platforms have
> > > problems here, yes? Since that's what has the problematic commit.
> >
> > So it seems. Does that mean we are OK with releasing such a broken release,
> > even though there is an easy way to improve the situation ?
>
> I will defer to the clock maintainer who I see agrees with your patch.
> I was just noting that we'd already shipped one release so a last minute
> revert is not something I'm happy about either.
I'll just note that we should not be ignoring errors. It makes things
very hard to debug. The root cause of this issue, IMO, is that the
clock subsystem started ignoring errors. People relied on that and
then it was hard to put the cat back in the bag.
But we should put the cat back in the bag and use a DT property to
indicate that the defaults are advisory only, for the case where the
U-Boot driver does not support a clock.
So long we we can undo this patch immediately after the release, you can add my:
Reviewed-by: Simon Glass
Regards,
Simon
Re: [RFC v2 19/20] efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI) devices
On Sun, Jan 02, 2022 at 10:19:21AM +0100, Heinrich Schuchardt wrote:
> On 12/10/21 07:49, AKASHI Takahiro wrote:
> > When we create an efi_disk device with an UEFI application using driver
> > binding protocol, the 'efi_driver' framework tries to create
> > a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to
>
> I assume this is IF_TYPE_EFI_LOADER now?
Yes in v2022.01-rc4 and later.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > calling a PROBE callback, efi_disk_probe().
> > In this case, however, we don't need to create another "efi_disk" device
> > as we already have this device instance.
> >
> > So we should avoid recursively invoke further processing in the callback
> > function.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > lib/efi_loader/efi_disk.c | 22 +-
> > 1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index 8e33af76711f..f37f8c1ab0f1 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -603,6 +603,7 @@ static int efi_disk_probe(void *ctx, struct event
> > *event)
> > {
> > struct udevice *dev;
> > enum uclass_id id;
> > + struct blk_desc *desc;
> > struct udevice *child;
> > int ret;
> >
> > @@ -616,9 +617,16 @@ static int efi_disk_probe(void *ctx, struct event
> > *event)
> > return 0;
> > }
> >
> > - ret = efi_disk_create_raw(dev);
> > - if (ret)
> > - return -1;
> > + /*
> > +* avoid creating duplicated objects now that efi_driver
> > +* has already created an efi_disk at this moment.
> > +*/
> > + desc = dev_get_uclass_plat(dev);
> > + if (desc->if_type != IF_TYPE_EFI) {
> > + ret = efi_disk_create_raw(dev);
> > + if (ret)
> > + return -1;
> > + }
> >
> > device_foreach_child(child, dev) {
> > ret = efi_disk_create_part(child);
> > @@ -642,13 +650,17 @@ static int efi_disk_probe(void *ctx, struct event
> > *event)
> > static int efi_disk_delete_raw(struct udevice *dev)
> > {
> > efi_handle_t handle;
> > + struct blk_desc *desc;
> > struct efi_disk_obj *diskobj;
> >
> > if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)))
> > return -1;
> >
> > - diskobj = container_of(handle, struct efi_disk_obj, header);
> > - efi_free_pool(diskobj->dp);
> > + desc = dev_get_uclass_plat(dev);
> > + if (desc->if_type != IF_TYPE_EFI) {
> > + diskobj = container_of(handle, struct efi_disk_obj, header);
> > + efi_free_pool(diskobj->dp);
> > + }
> >
> > efi_delete_handle(handle);
> > dev_tag_del(dev, DM_TAG_EFI);
>
RE:Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael, > -Original Message- > From: Michael Walle > Sent: Thursday, December 23, 2021 3:05 PM > To: Sahil Malhotra (OSS) > Cc: ZHIZHIKIN Andrey ; Clément Faure > ; Gaurav Jain ; Pankaj Gupta > ; Priyanka Jain ; u- > b...@lists.denx.de; Varun Sethi ; Ye Li > Subject: Re: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature > > Hi Sahil, > > Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS): > >> -Original Message- > >> From: U-Boot On Behalf Of Michael > >> Walle > >> Sent: Monday, December 20, 2021 6:23 PM > >> To: Sahil Malhotra (OSS) > >> Cc: ZHIZHIKIN Andrey ; Clément > >> Faure ; Gaurav Jain ; > >> Pankaj Gupta ; Priyanka Jain > >> ; u-boot@lists.denx.de; Varun Sethi > >> ; Ye Li > >> Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay > >> feature > >> > >> Caution: EXT Email > >> > >> Hi Sahil, > >> > >> Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): > >> >> DT nodes can be statically disabled if we know that they are held > >> >> by HAB and are not released to NS World. > >> >> > >> >> OP-TEE does set the status itself via dt_enable_secure_status(), > >> >> which should present the properly configured FDT when U-Boot takes > >> over. > >> > Yes, OP-TEE set the status by dt_enable_secure_status() in DTB > >> > overlay which gets merged with DTB provided for Linux bootup and > >> > then Linux boots with merged DTB. > >> > But u-boot uses the DTB embedded in its image. How can we modify > >> > that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? > >> > >> But then u-boot has the "wrong" dtb. What is the reason, there is an > >> overlay instead of a whole dtb? what if the overlay doesn't match the > >> dtb? > > "wrong" dtb means that uboot will not be aware of CAAM job ring which > > is taken by OP-TEE and uboot on LS platforms currently use JR0, which > > is not being used by any other entity in LS bootflow. > > I don't know I follow. u-boot and linux should have the same device tree; > regardless if that device is used or not. So applying the overlay just for > linux isn't > enough here. Ok, I don't think that as of now, in all platforms uboot and linux have same devie tree. But I will try to address your concern, but I don’t know how to apply overlay to dtb which is embedded in u-boot binary, Can you please point me to one reference which is doing this thing, I will take reference from there. > > We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE > > reserves One Job Ring for its use and that is communicated to Kernel > > using DTB overlay. > > > >> what if the overlay doesn't match the dtb? > > I didn't get this point, can you please elaborate a little. > > You are merging a dtb fragment with an unknown dtb, right? Who says they > match? you might have an old dtb where the supplied dtb fragment doesn't > make any sense. > > I might be missing something here. Eg. where is the linux dtb supposed to come > from? This patchset is really missing an example and a description how things > should work. If supplied DTB does not match with DTB overlay fragment. then overlay will not get applied. We don't have any control on where user picks the DTB, but we can only make sure DTB overlay feature must work with DTBs which are upstreamed If user makes its own customized DTB, we cannot make sure that things will work. Regards, Sahil Malhotra
Re: [PATCH] riscv: sifive: Fix OF_BOARD boot failure
Hi Tom,
On Wed, Jan 5, 2022 at 9:08 AM Bin Meng wrote:
>
> When using QEMU to have a quick test of booting U-Boot S-mode payload
> directly without the needs of preparing the SPI flash or SD card images
> for SiFive Unleashed board, as per the instructions [1], it currently
> does not boot any more.
>
> This was caused by the OF_PRIOR_STAGE removal, as gd->fdt_blob no longer
> points to a valid DTB. OF_BOARD is supposed to replace OF_PRIOR_STAGE,
> hence we need to add the OF_BOARD logic in board_fdt_blob_setup().
>
> [1]
> https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
>
> Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
> Fixes: d6f8ab30a2af ("treewide: Remove OF_PRIOR_STAGE")
> Signed-off-by: Bin Meng
> ---
>
> board/sifive/unleashed/unleashed.c | 2 +-
> board/sifive/unmatched/unmatched.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Would you pick up this patch directly for v2022.01?
Regards,
Bin
[PATCH 2/2] ARM: mvebu: x530: Add option for ECC
Some older x530 boards have layout issues that cause problems for DDR.
These are usually seen as training failures but can also cause problems
after training has completed. Add an option to enable ECC leaving the
default as N which will work with both old and new boards.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/Kconfig | 1 +
board/alliedtelesis/x530/Kconfig | 20
board/alliedtelesis/x530/x530.c | 8 +++-
3 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 board/alliedtelesis/x530/Kconfig
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d23cc0c760f1..7388ade98d52 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -341,5 +341,6 @@ config SECURED_MODE_CSK_INDEX
source "board/solidrun/clearfog/Kconfig"
source "board/kobol/helios4/Kconfig"
+source "board/alliedtelesis/x530/Kconfig"
endif
diff --git a/board/alliedtelesis/x530/Kconfig b/board/alliedtelesis/x530/Kconfig
new file mode 100644
index ..5c1ae36aebaa
--- /dev/null
+++ b/board/alliedtelesis/x530/Kconfig
@@ -0,0 +1,20 @@
+menu "x530 configuration"
+ depends on TARGET_X530
+
+config X530_ECC
+ bool "Enable DDR3 ECC"
+ help
+ Some of the older x530 board have layout issues which cause problems
+ for the DDR which usually exhibit as DDR training failures or
+ problems accessing DDR after training.
+
+ The known affected boards are:
+
+ * 844-001897-00 (x530-28GTXm, x530-28GPXm, GS980MX/28PSm)
+ * 844-001948-00 (GS980MX/28)
+ * 844-002008-00 (x530L-52GTX, x530L-52GPX)
+ * 844-001974-00 (x530-52GTXm, x530-52GPXm, GS980MX/52PSm)
+
+ If you have a newer board you can set Y here, otherwise say N.
+
+endmenu
diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index 866b6e68cc16..de20684f4353 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -45,6 +45,12 @@ int hws_board_topology_load(struct serdes_map
**serdes_map_array, u8 *count)
return 0;
}
+#if CONFIG_IS_ENABLED(X530_ECC)
+ #define BUS_MASK BUS_MASK_32BIT_ECC
+#else
+ #define BUS_MASK BUS_MASK_32BIT
+#endif
+
/*
* Define the DDR layout / topology here in the board file. This will
* be used by the DDR3 init code in the SPL U-Boot version to configure
@@ -66,7 +72,7 @@ static struct mv_ddr_topology_map board_topology_map = {
0, 0, /* cas_l cas_wl */
MV_DDR_TEMP_LOW,/* temperature */
MV_DDR_TIM_2T} }, /* timing */
- BUS_MASK_32BIT_ECC, /* subphys mask */
+ BUS_MASK, /* subphys mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
--
2.34.1
[PATCH 1/2] ARM: mvebu: x530: set MPP55 to gpio
MPP55 is used as a reset connected to the L3 switch chip. This doesn't matter for u-boot as it doesn't use the L3 switch but it is useful to be able to toggle the switch in/out of reset for the OS. Signed-off-by: Chris Packham --- board/alliedtelesis/x530/x530.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c index 8b31045a0743..866b6e68cc16 100644 --- a/board/alliedtelesis/x530/x530.c +++ b/board/alliedtelesis/x530/x530.c @@ -92,7 +92,7 @@ int board_early_init_f(void) writel(0x0550, MVEBU_MPP_BASE + 0x0c); writel(0x, MVEBU_MPP_BASE + 0x10); writel(0x00100565, MVEBU_MPP_BASE + 0x14); - writel(0x4000, MVEBU_MPP_BASE + 0x18); + writel(0x, MVEBU_MPP_BASE + 0x18); writel(0x, MVEBU_MPP_BASE + 0x1c); return 0; -- 2.34.1
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
On Thu, Jan 6, 2022 at 11:51 AM Chris Packham wrote: > > On Wed, Jan 5, 2022 at 10:10 PM Marek Behún wrote: > > > > On Wed, 5 Jan 2022 11:10:51 +1300 > > Chris Packham wrote: > > > > > Hi Marek, > > > > > > On Wed, Jan 5, 2022 at 9:28 AM Marek Behún wrote: > > > > > > > > From: Marek Behún > > > > > > > > Hello, > > > > > > > > continuing my last discussion with Chris [1] about this, could you > > > > please test this change? (For Chris, mainly on your x530, since last > > > > time you said it hanged your board in SPL.) > > > > > > I still get a hang after "Returning to BootROM (return address > > > 0x05c4)... " (after the DDR training). > > > > Hi Chris, > > > > would it be possible for me to connect to a computer to which the x530 > > is connected via UART so that I can debug it? Could you prepare such an > > environment? It would also need a mechanism to reset the board remotely > > somehow. I prepared a similar remote debugging environment for Marvell > > when they were solving some issues for us. > > > > If not, then I guess we will just have to send debugging code and > > results back and forth. > > > > Marek > > It might be possible. We can probably set something up to be internet > accessible and have remotely controllable PDUs. Unfortunately most of > the people who can set this up are still on holiday and by the time we > get that sorted I'll be on leave again. > > In terms of the actual problem the plot thickens. The board I had been > testing with was a production unit with MV88F6820-B0 at 1600 MHz (DDR > 800MHz). To debug the hang I wanted to attach a JTAG debugger so I > found an old prototype that had the JTAG header fitted, but the > problem didn't occur. The older prototype has MV88F6820-A0 at 1866 MHz > (DDR 933MHz) (as well as the usual collection of re-work wires that > prototypes often accumulate). I don't know if the A0 vs B0 differences > are significant or if the clock speed has some impact. > > I'll get the JTAG header fitted to my production unit and see where I get to. When I got the JTAG debugger attached to my production board I could see that with the "split change" after training was complete (just before the jump to u-boot proper) some of the DDR was inaccessible (random 4byte words throughout the memory). The lockup was a data abort trying to run the code out of RAM. Without the change the memory was "good". I think we might be running over some old issues that we've experienced with our internal u-boot fork. We first started to see these as we ramped production and started seeing DDR training failures on some boards (but not others using the same PCB and DDR). With the increased scrutiny on the DDR we did end up making some layout changes on the newer boards and have tried to work around the issues in SW for the existing boards. I actually thought the recent changes to the mvebu ddr code may have addressed some of these issues as the board I had on my desk had been working happily with upstream u-boot despite having a suspect board layout. The workaround for the older boards that we've been using in our u-boot fork is to disable ECC. This appears to do the trick with Marek's patch so I'm tempted to say let's just go with that (I'll post a patch for that shortly).
Re: efi bootmenu
On Wed, Dec 29, 2021 at 05:04:17PM +0100, Mark Kettenis wrote: > > From: François Ozog > > Date: Wed, 29 Dec 2021 14:39:36 +0100 > > > > HI Simon > > > > On Wed, 29 Dec 2021 at 14:36, Simon Glass wrote: > > > > > Hi François, > > > > > > On Tue, 28 Dec 2021 at 03:15, François Ozog > > > wrote: > > > > > > > > > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass a écrit : > > > >> > > > >> Hi Masahisa, > > > >> > > > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > > > >> wrote: > > > >> > > > > >> > Hi Takahiro, > > > >> > > > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > > >> > wrote: > > > >> > > > > > >> > > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote: > > > >> > > > Hi Heinrich, Ilias, Akashi-san, > > > >> > > > > > > >> > > > Ilias and I are now discussing to create efi bootmenu, almost > > > similar > > > >> > > > to UiApp in EDK2. > > > >> > > > > > >> > > Why not discuss this topic openly in ML? > > > >> > > > > >> > Yes, I included U-Boot ML.(Sorry, I should include from the the > > > beginning.) > > > >> > > > > >> > > > > > >> > > How is this feature related to Simon's bootmethod proposal? > > > >> > > > > >> > If I correctly understand Simon's bootmethod proposal, > > > >> > the difference is that efi bootmenu only targets to implement > > > >> > the menu based UI to select/edit/add/delete "Boot" and > > > "BootOrder". > > > >> > > > >> Yes, EFI would be one of the bootmethods. Others would be U-Boot > > > >> scripts, Chrome OS, Android, etc. plus people might add custom ones. > > > >> > > > >> Also I am thinking that (perhaps) the bootdev part of the standard > > > >> boot thing could be used to provide boot devices for EFI. > > > >> > > > >> If we do have a bootmenu, I wonder if it could be generic, instead of > > > >> tied to EFI? > > > > > > > > EFI Boot specify an array of device paths and boot options. A device > > > path is quite a unique construct despite its name. > > > > A device path is itself an array of elements, some elements can be a > > > file path , configuration information, or diverse metadata. An example of > > > configuration information element is UART baud,stop bits, parity along > > > with > > > terminal (vt100, ansi…). Another device path element can cover IP address, > > > transport information (tcp, UDP and port number). > > > > The traditional EFI boot menu is quite crude and does not expose the > > > full capabilities of Boot (lacks edit of boot options for instance!). > > > > > > > > In the long run we will need to leverage all the Boot capabilities > > > and those are EFI specific while being OS agnostic. > > > > The other U-Boot boot methods (Android , ChromeOS…) are OS specific. > > > > The goals are thus very different and making a generic approach seems > > > quite compromised. If there is a fully generic framework available in the > > > future, it may be possible to integrate the EFI boot menu. But at least > > > there is a need to solve, code first, the EFI complexities to fuel the > > > generic architecture discussion. > > > > > > Despite this, the goal of standard boot is to encompass all of this > > > within U-Boot. I believe that it will be successful, even if the path > > > at present is a bit unclear. > > > > > So I would suggest we work bottom up. Starting by making EFI menu work, > > then extend it more generic or integrated it in a framework. Starting top > > down would require a long architecture process based on not enough known > > problems to solve for each environment. > > > > Well, whatever you do, please build something that works well with a > serial console. EDK2 makes assumptions the terminal emulation on the > other side, insists on changing the colors to white on black and > relies on function keys that need escape sequences. And escape > sequences over serial are always iffy since they depend on timing for > their interpretation. You can do better for U-Boot. > > Also, keep in mind that BootOrder and Boot only really work if > there is runtime EFI variable support. So the boot menu should > include options to select a device to boot from and use the default > (removable media) bootloader from the ESP on that device. I think that this issue can/should be addressed in a separate patch although I have had no progress on my patch[1]. -Takahiro Akashi [1] https://lists.denx.de/pipermail/u-boot/2021-November/466583.html > And a way > to make this selection stick! Pretty much all x86 EFI implementations > provide functionality like that. I suppose this could be done by > populating the EFI variable store with appropriate Boot variables > and manipulating BootOrder. But that would make it hard to generalize > the boot menu to non-EFI boot flows.
Re: [PATCH v6 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Tudor
>
> Hi,
>
> On 12/29/21 7:56 AM, JaimeLiao wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
> > Macronix flash in Octal DTR mode.
> >
> > Enable Octal DTR mode with 20 dummy cycles to allow running at the
> > maximum supported frequency.
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 83 ++
> > include/linux/mtd/spi-nor.h| 12 -
> > 2 files changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index d5d905fa5a..0a6550984b 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
> > };
> > #endif /* CONFIG_SPI_FLASH_MT35XU */
> >
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > +/**
> > + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> > Configuration Register 2.
> > + * @nor: pointer to a 'struct spi_nor'
> > + *
> > + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> > + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> > OPI memories.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
>
> This method should be called just for the flashes that do not define the
> JESD216 "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" table.
> Or where SFDP is skipped intentionally.
I think Octal DTR enable method have been defined by manufacturers.
It would be better if the method could be parce from SFDP.
But I prefer to follow the existing rules for adding the flashes which
have been output but not be support in uboot.
>
> > +{
> > + struct spi_mem_op op;
> > + int ret;
> > + u8 buf;
> > +
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_DC_20;
> > + op = (struct spi_mem_op)
> > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
> > + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_DC, 1),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_DATA_OUT(1, , 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, );
> > + if (ret)
> > + return ret;
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + nor->read_dummy = MXIC_MAX_DC;
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> > + op = (struct spi_mem_op)
> > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
> > + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1),
> > + SPI_MEM_OP_NO_DUMMY,
> > + SPI_MEM_OP_DATA_OUT(1, , 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, );
> > + if (ret) {
> > + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> > + return ret;
> > + }
> > + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> > +
> > + return 0;
> > +}
> > +
> > +static void macronix_octal_default_init(struct spi_nor *nor)
>
> I think we should get rid of the default_init() hook, it messes how
> the params are initialized, there's a spaghetti right now, it's very hard to
> determine who initializes which params solely by reading the code. I would
> advise to follow linux and use a late_init() hook where explicit octal dtr
> enable method is required.
Sure it is a good idea.
I hope U-boot could have more similar architecture with Linux kernel.
>
>
> > +{
> > + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> > +}
> > +
> > +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
> > +struct spi_nor_flash_parameter
> > *params)
> > +{
> > + /*
> > +* Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
> > +* SPI_NOR_OCTAL_DTR_READ flag exists.
> > +*/
> > + if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
>
> This confirms the spaghetti theory. This is not SFDP related, why do you use
> the post_sfdp hook?
Because of SPI_NOR_OCTAL_DTR_PP is not existing in U-boot.
I will take other suitable method to enable it next patch.
>
> > +}
> > +
> > +static struct spi_nor_fixups macronix_octal_fixups = {
> > + .default_init = macronix_octal_default_init,
> > + .post_sfdp = macronix_octal_post_sfdp_fixup,
> > +};
> > +#endif /*
Re: [PATCH v6 1/4] mtd: spi-nor: macronix: add support for Macronix Octal
Hi Miquel
>
> Hi Jaime,
>
> You made a typo on Jagan's address, you might need to resend.
Yes your are right, I have re-send the cover letter to Jagan.
>
> The title does not look correct, maybe you miss a word after Octal. And
> is it something Macronix specific? I believe this is generic and you
> can drop "Macronix" (the second occurrence) from the title.
Ok got it.
>
> jaimeliao...@gmail.com wrote on Wed, 29 Dec 2021 13:56:17 +0800:
>
> > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding
>
> When pointing to an upstream commit I think even in U-Boot the style
> should be something like:
> <12-digit hash> ("title of the commit")
> which at least allows to know which commit we are talking about.
OK.
>
> > Macronix flash in Octal DTR mode.
>
> This first part of the commit log should be moved below.
>
> >
> > Enable Octal DTR mode with 20 dummy cycles to allow running at the
> > maximum supported frequency.
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-core.c | 83 ++
> > include/linux/mtd/spi-nor.h| 12 -
> > 2 files changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index d5d905fa5a..0a6550984b 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = {
> > };
> > #endif /* CONFIG_SPI_FLASH_MT35XU */
> >
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > +/**
> > + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in
> > Configuration Register 2.
>
> This is very specific to Macronix I believe? Please just use a generic
> description here.
Yes I will modify this part next patch.
>
> > + * @nor: pointer to a 'struct spi_nor'
> > + *
> > + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2.
> > + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like
> > OPI memories.
> > + *
> > + * Return: 0 on success, -errno otherwise.
> > + */
> > +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor)
> > +{
> > + struct spi_mem_op op;
> > + int ret;
> > + u8 buf;
> > +
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_DC_20;
> > + op = (struct spi_mem_op)
> > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
> > +SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_DC, 1),
> > +SPI_MEM_OP_NO_DUMMY,
> > +SPI_MEM_OP_DATA_OUT(1, , 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, );
> > + if (ret)
> > + return ret;
> > +
> > + ret = spi_nor_wait_till_ready(nor);
> > + if (ret)
> > + return ret;
> > +
> > + nor->read_dummy = MXIC_MAX_DC;
> > + ret = write_enable(nor);
> > + if (ret)
> > + return ret;
> > +
> > + buf = SPINOR_REG_MXIC_OPI_DTR_EN;
> > + op = (struct spi_mem_op)
> > + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1),
> > +SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1),
> > +SPI_MEM_OP_NO_DUMMY,
> > +SPI_MEM_OP_DATA_OUT(1, , 1));
> > +
> > + ret = spi_mem_exec_op(nor->spi, );
> > + if (ret) {
> > + dev_err(nor->dev, "Failed to enable octal DTR mode\n");
> > + return ret;
> > + }
> > + nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
> > +
> > + return 0;
> > +}
> > +
> > +static void macronix_octal_default_init(struct spi_nor *nor)
> > +{
> > + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable;
> > +}
> > +
> > +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor,
> > + struct spi_nor_flash_parameter
> > *params)
> > +{
> > + /*
> > + * Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when
> > + * SPI_NOR_OCTAL_DTR_READ flag exists.
> > + */
> > + if (params->hwcaps.mask & SNOR_HWCAPS_READ_8_8_8_DTR)
> > + params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> > +}
> > +
> > +static struct spi_nor_fixups macronix_octal_fixups = {
> > + .default_init = macronix_octal_default_init,
> > + .post_sfdp = macronix_octal_post_sfdp_fixup,
> > +};
> > +#endif /* CONFIG_SPI_FLASH_MACRONIX */
> > +
> > /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
> > * @nor: pointer to a 'struct spi_nor'
> > *
> > @@ -3655,6 +3734,10 @@ void spi_nor_set_fixups(struct spi_nor *nor)
> > if (!strcmp(nor->info->name, "mt35xu512aba"))
> > nor->fixups = _fixups;
> > #endif
> > +
> > +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX)
> > + nor->fixups = _octal_fixups;
> > +#endif /* SPI_FLASH_MACRONIX */
> > }
>
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
On Wed, Jan 5, 2022 at 10:10 PM Marek Behún wrote: > > On Wed, 5 Jan 2022 11:10:51 +1300 > Chris Packham wrote: > > > Hi Marek, > > > > On Wed, Jan 5, 2022 at 9:28 AM Marek Behún wrote: > > > > > > From: Marek Behún > > > > > > Hello, > > > > > > continuing my last discussion with Chris [1] about this, could you > > > please test this change? (For Chris, mainly on your x530, since last > > > time you said it hanged your board in SPL.) > > > > I still get a hang after "Returning to BootROM (return address > > 0x05c4)... " (after the DDR training). > > Hi Chris, > > would it be possible for me to connect to a computer to which the x530 > is connected via UART so that I can debug it? Could you prepare such an > environment? It would also need a mechanism to reset the board remotely > somehow. I prepared a similar remote debugging environment for Marvell > when they were solving some issues for us. > > If not, then I guess we will just have to send debugging code and > results back and forth. > > Marek It might be possible. We can probably set something up to be internet accessible and have remotely controllable PDUs. Unfortunately most of the people who can set this up are still on holiday and by the time we get that sorted I'll be on leave again. In terms of the actual problem the plot thickens. The board I had been testing with was a production unit with MV88F6820-B0 at 1600 MHz (DDR 800MHz). To debug the hang I wanted to attach a JTAG debugger so I found an old prototype that had the JTAG header fitted, but the problem didn't occur. The older prototype has MV88F6820-A0 at 1866 MHz (DDR 933MHz) (as well as the usual collection of re-work wires that prototypes often accumulate). I don't know if the A0 vs B0 differences are significant or if the clock speed has some impact. I'll get the JTAG header fitted to my production unit and see where I get to.
Re: mkimage_fit_atf.sh: not found
On Wed, Jan 05, 2022 at 11:07:03PM +0100, Marcel Ziswiler wrote:
> On Wed, 2022-01-05 at 17:04 -0500, Tom Rini wrote:
> > On Wed, Jan 05, 2022 at 10:51:23PM +0100, Marcel Ziswiler wrote:
> > > Hi Tim et al.
> > >
> > > On Wed, 2022-01-05 at 11:08 -0800, Tim Harvey wrote:
> > > > On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
> > > > wrote:
> > > > >
> > > > > Hello Tim,
> > > > >
> > > > > > -Original Message-
> > > > > > From: U-Boot On Behalf Of Tim Harvey
> > > > > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > > > > To: u-boot ; Stefano Babic ;
> > > > > > Fabio Estevam
> > > > > >
> > > > > > Cc: Schrempf Frieder ; Adam Ford
> > > > > > ; Marcel Ziswiler ; Jagan
> > > > > > Teki
> > > > > >
> > > > > > Subject: mkimage_fit_atf.sh: not found
> > > > > >
> > > > > > Stefano and Fabio,
> > > > > >
> > > > > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > > > > master due to mkimage_fit_atf.sh not found:
> > > > > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > > > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > > > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > > > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > > > > >
> > > > >
> > > > > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit
> > > > > generator script")
> > > >
> > > > So why was that merged when it breaks several boards that are not
> > > > switched to binman because of the CI issue?
> > >
> > > I have to admit that I did not closely follow that discussion lately. But
> > > it seems to me that this should
> > > be
> > > solvable, not?
> > >
> > > Anyway, at least in my local buildman use case just touching resp. binary
> > > blob file names helped me getting
> > > thought this:
> > >
> > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_imem.bin
> > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_dmem.bin
> > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_imem.bin
> > > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_dmem.bin
> > > ⬢[zim@toolbox u-boot.git]$ touch bl31.bin
> > >
> > > Couldn't that somehow also be done for CI?
> >
> > There's a whole thread on making binman be able to fake things out in
> > this case, so that it doesn't require too much special casing within CI
> > itself.
> >
> > > > > > As far as I can tell the other boards that are still using
> > > > > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > > > > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
> > > > >
> > > > > imx8mq_evk is already converted and I've sent a patch for it, see [1].
> > > > >
> > > > > >
> > > > > > What is the state of the binman conversion? I submitted a series to
> > > > > > convert my boards to binman and it has just been sitting without any
> > > > > > response for months now [1].
> > > > >
> > > > > I believe that the reason for your series sitting in the queue is the
> > > > > same as
> > > > > for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI
> > > > > builds.
> > > > >
> > > >
> > > > Right, so imx8mq_evk (and others) are completely broken for the
> > > > pending release correct?
> > > >
> > > > Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
> > > > generator script")
> > >
> > > I kind of agree. However, much smarter would be to finish that binman
> > > conversion which I also still have
> > > one in
> > > flight [1] plus the follow on patch series [2] (plus an unrelated i.MX 8M
> > > Plus board addition [3]) all
> > > still
> > > sitting there idle since October with acks resp. reviewed-bys in place!
> >
> > Yes, I am hopeful many outstanding things in this area will get picked
> > up after v2022.01 is released. Might it make sense to revert what Tim
> > suggested for now tho?
>
> Sure, fair enough.
>
> And what about them pending patch series?
Fabio noted elsewhere that Stefano is on vacation still right now, but
yes, I very much want to see these outstanding items picked up, and I'm
unsure what additional help Stefano would find useful.
--
Tom
signature.asc
Description: PGP signature
Re: mkimage_fit_atf.sh: not found
On Wed, 2022-01-05 at 17:04 -0500, Tom Rini wrote:
> On Wed, Jan 05, 2022 at 10:51:23PM +0100, Marcel Ziswiler wrote:
> > Hi Tim et al.
> >
> > On Wed, 2022-01-05 at 11:08 -0800, Tim Harvey wrote:
> > > On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
> > > wrote:
> > > >
> > > > Hello Tim,
> > > >
> > > > > -Original Message-
> > > > > From: U-Boot On Behalf Of Tim Harvey
> > > > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > > > To: u-boot ; Stefano Babic ;
> > > > > Fabio Estevam
> > > > >
> > > > > Cc: Schrempf Frieder ; Adam Ford
> > > > > ; Marcel Ziswiler ; Jagan
> > > > > Teki
> > > > >
> > > > > Subject: mkimage_fit_atf.sh: not found
> > > > >
> > > > > Stefano and Fabio,
> > > > >
> > > > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > > > master due to mkimage_fit_atf.sh not found:
> > > > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > > > >
> > > >
> > > > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit
> > > > generator script")
> > >
> > > So why was that merged when it breaks several boards that are not
> > > switched to binman because of the CI issue?
> >
> > I have to admit that I did not closely follow that discussion lately. But
> > it seems to me that this should
> > be
> > solvable, not?
> >
> > Anyway, at least in my local buildman use case just touching resp. binary
> > blob file names helped me getting
> > thought this:
> >
> > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_imem.bin
> > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_dmem.bin
> > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_imem.bin
> > ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_dmem.bin
> > ⬢[zim@toolbox u-boot.git]$ touch bl31.bin
> >
> > Couldn't that somehow also be done for CI?
>
> There's a whole thread on making binman be able to fake things out in
> this case, so that it doesn't require too much special casing within CI
> itself.
>
> > > > > As far as I can tell the other boards that are still using
> > > > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > > > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
> > > >
> > > > imx8mq_evk is already converted and I've sent a patch for it, see [1].
> > > >
> > > > >
> > > > > What is the state of the binman conversion? I submitted a series to
> > > > > convert my boards to binman and it has just been sitting without any
> > > > > response for months now [1].
> > > >
> > > > I believe that the reason for your series sitting in the queue is the
> > > > same as
> > > > for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI
> > > > builds.
> > > >
> > >
> > > Right, so imx8mq_evk (and others) are completely broken for the
> > > pending release correct?
> > >
> > > Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
> > > generator script")
> >
> > I kind of agree. However, much smarter would be to finish that binman
> > conversion which I also still have
> > one in
> > flight [1] plus the follow on patch series [2] (plus an unrelated i.MX 8M
> > Plus board addition [3]) all
> > still
> > sitting there idle since October with acks resp. reviewed-bys in place!
>
> Yes, I am hopeful many outstanding things in this area will get picked
> up after v2022.01 is released. Might it make sense to revert what Tim
> suggested for now tho?
Sure, fair enough.
And what about them pending patch series?
Re: mkimage_fit_atf.sh: not found
On Wed, Jan 05, 2022 at 10:51:23PM +0100, Marcel Ziswiler wrote:
> Hi Tim et al.
>
> On Wed, 2022-01-05 at 11:08 -0800, Tim Harvey wrote:
> > On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
> > wrote:
> > >
> > > Hello Tim,
> > >
> > > > -Original Message-
> > > > From: U-Boot On Behalf Of Tim Harvey
> > > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > > To: u-boot ; Stefano Babic ;
> > > > Fabio Estevam
> > > >
> > > > Cc: Schrempf Frieder ; Adam Ford
> > > > ; Marcel Ziswiler ; Jagan Teki
> > > >
> > > > Subject: mkimage_fit_atf.sh: not found
> > > >
> > > > Stefano and Fabio,
> > > >
> > > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > > master due to mkimage_fit_atf.sh not found:
> > > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > > >
> > >
> > > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator
> > > script")
> >
> > So why was that merged when it breaks several boards that are not
> > switched to binman because of the CI issue?
>
> I have to admit that I did not closely follow that discussion lately. But it
> seems to me that this should be
> solvable, not?
>
> Anyway, at least in my local buildman use case just touching resp. binary
> blob file names helped me getting
> thought this:
>
> ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_imem.bin
> ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_dmem.bin
> ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_imem.bin
> ⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_dmem.bin
> ⬢[zim@toolbox u-boot.git]$ touch bl31.bin
>
> Couldn't that somehow also be done for CI?
There's a whole thread on making binman be able to fake things out in
this case, so that it doesn't require too much special casing within CI
itself.
> > > > As far as I can tell the other boards that are still using
> > > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
> > >
> > > imx8mq_evk is already converted and I've sent a patch for it, see [1].
> > >
> > > >
> > > > What is the state of the binman conversion? I submitted a series to
> > > > convert my boards to binman and it has just been sitting without any
> > > > response for months now [1].
> > >
> > > I believe that the reason for your series sitting in the queue is the
> > > same as
> > > for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
> > >
> >
> > Right, so imx8mq_evk (and others) are completely broken for the
> > pending release correct?
> >
> > Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
> > generator script")
>
> I kind of agree. However, much smarter would be to finish that binman
> conversion which I also still have one in
> flight [1] plus the follow on patch series [2] (plus an unrelated i.MX 8M
> Plus board addition [3]) all still
> sitting there idle since October with acks resp. reviewed-bys in place!
Yes, I am hopeful many outstanding things in this area will get picked
up after v2022.01 is released. Might it make sense to revert what Tim
suggested for now tho?
--
Tom
signature.asc
Description: PGP signature
Re: mkimage_fit_atf.sh: not found
Hi Tim et al.
On Wed, 2022-01-05 at 11:08 -0800, Tim Harvey wrote:
> On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
> wrote:
> >
> > Hello Tim,
> >
> > > -Original Message-
> > > From: U-Boot On Behalf Of Tim Harvey
> > > Sent: Tuesday, January 4, 2022 11:48 PM
> > > To: u-boot ; Stefano Babic ; Fabio
> > > Estevam
> > >
> > > Cc: Schrempf Frieder ; Adam Ford
> > > ; Marcel Ziswiler ; Jagan Teki
> > >
> > > Subject: mkimage_fit_atf.sh: not found
> > >
> > > Stefano and Fabio,
> > >
> > > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > > master due to mkimage_fit_atf.sh not found:
> > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> > >
> >
> > This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator
> > script")
>
> So why was that merged when it breaks several boards that are not
> switched to binman because of the CI issue?
I have to admit that I did not closely follow that discussion lately. But it
seems to me that this should be
solvable, not?
Anyway, at least in my local buildman use case just touching resp. binary blob
file names helped me getting
thought this:
⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_imem.bin
⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_1d_dmem.bin
⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_imem.bin
⬢[zim@toolbox u-boot.git]$ touch lpddr4_pmu_train_2d_dmem.bin
⬢[zim@toolbox u-boot.git]$ touch bl31.bin
Couldn't that somehow also be done for CI?
> > > As far as I can tell the other boards that are still using
> > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
> >
> > imx8mq_evk is already converted and I've sent a patch for it, see [1].
> >
> > >
> > > What is the state of the binman conversion? I submitted a series to
> > > convert my boards to binman and it has just been sitting without any
> > > response for months now [1].
> >
> > I believe that the reason for your series sitting in the queue is the same
> > as
> > for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
> >
>
> Right, so imx8mq_evk (and others) are completely broken for the
> pending release correct?
>
> Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
> generator script")
I kind of agree. However, much smarter would be to finish that binman
conversion which I also still have one in
flight [1] plus the follow on patch series [2] (plus an unrelated i.MX 8M Plus
board addition [3]) all still
sitting there idle since October with acks resp. reviewed-bys in place!
Cheers
Marcel
> Tim
>
> > >
> > > I'm not sure when the above breakage occurred but the conversion to
> > > binman resolves it and other things.
> > >
> > > Please let me know what you expect me to do to resolve this as there
> > > is a release pending.
> > >
> > > Best regards,
> > >
> > > Tim
> > > [1]
> > > https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-
> > > thar...@gateworks.com/
> >
> > -- andrey
> >
> > Link: [1]:
> > http://patchwork.ozlabs.org/project/uboot/patch/20211203161802.12699-1-andrey.zhizhi...@leica-geosystems.com/
[1]
http://patchwork.ozlabs.org/project/uboot/patch/20211022214340.1214793-1-mar...@ziswiler.com/
[2] http://patchwork.ozlabs.org/project/uboot/list/?series=268510
[3]
http://patchwork.ozlabs.org/project/uboot/patch/20211022073104.1105628-1-mar...@ziswiler.com/
Re: [PATCH 2/2] udoo: neo: Do not print the Model information
On Wed, Jan 05, 2022 at 05:52:23PM -0300, Fabio Estevam wrote: > Hi Tommaso, > > On Wed, Jan 5, 2022 at 5:47 PM Tommaso Merciai wrote: > > > Hi Fabio, > > Thanks, I test your patch on basic and extended model. Below some logs > > seems all work properly. I hope I helped the cause :) > > Yes, thanks a lot! > > > - BASIC log: > > - > > U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100) > > > > CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz) > > CPU: Extended Commercial temperature grade (-20C to 105C) at 32C > > Reset cause: POR > > Model: UDOO Neo Basic > > I assume you have only applied 1/2 and not 2/2. > > With 2/2 applied the Model line should not be printed. > > Thanks Yes, Fabio. Sorry, I forgot. Below test with 2/2. U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 22:07:22 +0100) CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 45C Reset cause: POR Board: UDOO Neo BASIC I2C: ready DRAM: 512 MiB PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK In:serial Out: serial Err: serial Net: eth0: ethernet@2188000 Hit any key to stop autoboot: 0 U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 22:07:22 +0100) CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 35C Reset cause: POR Board: UDOO Neo EXTENDED I2C: ready DRAM: 1 GiB PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK In:serial Out: serial Err: serial Net: Error: ethernet@2188000 address not set. No ethernet found. Hit any key to stop autoboot: 0 Thanks, Tommaso
Re: [PATCH] Revert "clk: Detect failure to set defaults"
On Wed, Jan 05, 2022 at 08:56:50PM +0100, Marek Vasut wrote:
> On 1/5/22 20:37, Tom Rini wrote:
> > On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
> > > On 1/1/22 22:41, Sean Anderson wrote:
> > > > Hi Marek,
> > >
> > > Hi,
> > >
> > > > Please CC clock maintainers for future patches.
> > >
> > > btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
> > > zero reviews/acks from clock maintainers.
> > >
> > > > On 1/1/22 1:51 PM, Marek Vasut wrote:
> > > > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> > > > > The aforementioned patch causes massive breakage on all platforms
> > > > > which
> > > > > have 'assigned-clock' DT property in their DT which references any
> > > > > clock
> > > > > that are not supported by the platform clock driver. That can easily
> > > > > happen either in SPL, or because the clock driver is reduced.
> > > > > Currently
> > > > > it seems all iMX8M are affected and fail to boot altogether.
> > > > >
> > > > > Signed-off-by: Marek Vasut
> > > > > Cc: Peng Fan
> > > > > Cc: Simon Glass
> > > > > ---
> > > > > drivers/clk/clk-uclass.c | 6 +-
> > > > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > > > index f2d26427543..094b1abf13c 100644
> > > > > --- a/drivers/clk/clk-uclass.c
> > > > > +++ b/drivers/clk/clk-uclass.c
> > > > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
> > > > > clk *clk)
> > > > > int clk_uclass_post_probe(struct udevice *dev)
> > > > > {
> > > > > - int ret;
> > > > > -
> > > > > /*
> > > > > * when a clock provider is probed. Call clk_set_defaults()
> > > > > * also after the device is probed. This takes care of cases
> > > > > * where the DT is used to setup default parents and rates
> > > > > * using assigned-clocks
> > > > > */
> > > > > - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > > > - if (ret)
> > > > > - return log_ret(ret);
> > > > > + clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > > > return 0;
> > > > > }
> > > > >
> > > >
> > > > See [1] for previous discussion. For more background,
> > > >
> > > > - Device trees for i.MX are sync'd with Linux.
> > > > - General clock assignments may live in the clock-controller node,
> > >
> > > clock assignments can be anywhere, even in non-clock-controller nodes.
> > >
> > > > including those which U-Boot does not implement, but which Linux
> > > > does.
> > > > It's OK to not set up these clocks, but U-Boot doesn't know that and
> > > > fails.
> > > >
> > > > We don't necessarily need to revert this commit, but we do need a way to
> > > > say "it's OK not to set the defaults, since we can function without
> > > > them". Tom suggested doing this in the clock driver last time. I think a
> > > > Kconfig or a device tree property would work, perhaps something like
> > > > 'u-boot,clock-defaults-optional'.
> > >
> > > We didn't need custom DT properties before, Linux doesn't need them
> > > either,
> > > so that approach seems wrong.
> > >
> > > If the clock driver could say "skip unimplemented clock, because I don't
> > > implement them and that is OK", that sounds like the right approach.
> > >
> > > Unless the 2022.01 release should be completely broken for a lot of
> > > platforms, I would propose we revert the clock uclass patch now and re-add
> > > it right after the release, so we would not roll out a completely broken
> > > release and would have more time to fix this properly.
> >
> > It'll be no more broken than v2021.10 was for whatever platforms have
> > problems here, yes? Since that's what has the problematic commit.
>
> So it seems. Does that mean we are OK with releasing such a broken release,
> even though there is an easy way to improve the situation ?
I will defer to the clock maintainer who I see agrees with your patch.
I was just noting that we'd already shipped one release so a last minute
revert is not something I'm happy about either.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/2] udoo: neo: Do not print the Model information
Hi Tommaso, On Wed, Jan 5, 2022 at 5:47 PM Tommaso Merciai wrote: > Hi Fabio, > Thanks, I test your patch on basic and extended model. Below some logs > seems all work properly. I hope I helped the cause :) Yes, thanks a lot! > - BASIC log: > - > U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100) > > CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz) > CPU: Extended Commercial temperature grade (-20C to 105C) at 32C > Reset cause: POR > Model: UDOO Neo Basic I assume you have only applied 1/2 and not 2/2. With 2/2 applied the Model line should not be printed. Thanks
Re: [PATCH 2/2] udoo: neo: Do not print the Model information
On Mon, Jan 03, 2022 at 12:15:12PM -0300, Fabio Estevam wrote:
> By default the Model information from DT is printed:
>
> CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> CPU: Extended Commercial temperature grade (-20C to 105C) at 63C
> Reset cause: POR
> Model: UDOO Neo Basic
> Board: UDOO Neo FULL
> I2C: ready
>
> As the udoo basic DT is used, such output may be confusing.
>
> Improve it by only printing the Board model instead, which is
> read from the board identification GPIOs.
Hi Fabio,
Thanks, I test your patch on basic and extended model. Below some logs
seems all work properly. I hope I helped the cause :)
- BASIC log:
-
U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 32C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo BASIC
I2C: ready
DRAM: 512 MiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial
Out: serial
Err: serial
Net: eth0: ethernet@2188000 [PRIME]
Hit
--
- EXTENDED LOG:
--
U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 42C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo EXTENDED
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial
Out: serial
Err: serial
Net:
Error: ethernet@2188000 address not set.
No ethernet found.
Hit any key to stop autoboot: 0
Acked-by: Tommaso Merciai
Tested-by: Tommaso Merciai
Tommaso
>
> Signed-off-by: Fabio Estevam
> ---
> This applies on top of Peter's series:
> https://lore.kernel.org/all/20211221123249.455347-1-pbrobin...@gmail.com/T
>
> board/udoo/neo/neo.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
> index 0c0d3f615d18..da6a0b4e9247 100644
> --- a/board/udoo/neo/neo.c
> +++ b/board/udoo/neo/neo.c
> @@ -350,7 +350,8 @@ static char *board_string(int type)
> return "UNDEFINED";
> }
>
> -int checkboard(void)
> +/* Override the default implementation, DT model is not accurate */
> +int show_board_info(void)
> {
> int *board_type = (int *)OCRAM_START;
>
> --
> 2.25.1
>
Re: [PATCH] Revert "clk: Detect failure to set defaults"
Hi Marek, On Sat, Jan 1, 2022 at 3:51 PM Marek Vasut wrote: > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646. > The aforementioned patch causes massive breakage on all platforms which > have 'assigned-clock' DT property in their DT which references any clock > that are not supported by the platform clock driver. That can easily > happen either in SPL, or because the clock driver is reduced. Currently > it seems all iMX8M are affected and fail to boot altogether. > > Signed-off-by: Marek Vasut > Cc: Peng Fan > Cc: Simon Glass Reviewed-by: Fabio Estevam
Re: [PATCH v2] rockchip: timer: add OF_PLATDATA support for dw-apb-timer
Hi,
In addition of the previous message, when I compile with the opposite of
OF_REAL (= !OF_PLATDATA) it generates an error in SPL.
Like to know why OF_REAL doesn't work.
For these couple of extra lines to increase build coverage inside does
it matter a lot by adding another messy set of #if
Let me know if that's OK to leave it as it is for version 3 with extra
white space patch.
Kind regards,
Johan Jonker
static int dw_apb_timer_of_to_plat(struct udevice *dev)
{
if (!IS_ENABLED(OF_PLATDATA)) {
struct dw_apb_timer_priv *priv = dev_get_priv(dev);
priv->regs = dev_read_addr(dev);
}
return 0;
}
arm-linux-gnueabihf-ld.bfd: drivers/timer/dw-apb-timer.o: in function
`dw_apb_timer_of_to_plat':
/drivers/timer/dw-apb-timer.c:95: undefined reference to `dev_read_addr'
arm-linux-gnueabihf-ld.bfd: drivers/timer/dw-apb-timer.o: in function
`dw_apb_timer_probe':
/drivers/timer/dw-apb-timer.c:73: undefined reference to `clk_get_by_index'
make[1]: *** [scripts/Makefile.spl:509: spl/u-boot-spl] Error 1
make: *** [Makefile:2011: spl/u-boot-spl] Error 2
On 1/5/22 5:40 PM, Johan Jonker wrote:
> Hi Simon,
>
> Thanks you for your comments.
> Shown below are the objdump results of the full U-boot binary
> dw_apb_timer_of_to_plat() function.
> Same goes for the dw_apb_timer_probe() function.
> With if (IS_ENABLED(OF_REAL)) I don't get a useful timer result (boot
> hangs after timer probe, because in full U-boot the reg value isn't
> correct defined. Part of the init probe is missing.
>
> Could you try it yourself?
> Please advise what options we have.
>
> Kind regards,
>
> Johan Jonker
>
> ==
> Patch version 1 with if (IS_ENABLED(OF_REAL)) {}:
>
> arm-linux-gnueabihf-objdump -d drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-v1.asm
>
>
> :
>0: 2000movsr0, #0
>2: 4770bx lr
>
> arm-linux-gnueabihf-objdump -d spl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-spl-v1.asm
> arm-linux-gnueabihf-objdump -d tpl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-tpl-v1.asm
> ==
> patch version 2 with #if CONFIG_IS_ENABLED(OF_REAL):
>
> arm-linux-gnueabihf-objdump -d drivers/timer/dw-apb-timer.o > ../dw-apb-
> timer-20220105-v2.asm
>
> :
>0: b538push{r3, r4, r5, lr}
>2: 4605mov r5, r0
>4: f7ff fffe bl 0
>8: 4604mov r4, r0
>a: 4628mov r0, r5
>c: f7ff fffe bl 0
> 10: 6020str r0, [r4, #0]
> 12: 2000 movs r0, #0
> 14: bd38pop {r3, r4, r5, pc}
>
> arm-linux-gnueabihf-objdump -d spl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-spl-v2.asm
> arm-linux-gnueabihf-objdump -d tpl/drivers/timer/dw-apb-timer.o >
> ../dw-apb-timer-20220105-tpl-v2.asm
>
> ===
>
> On 1/5/22 3:03 PM, Simon Glass wrote:
>> Hi Johan,
>>
>> On Tue, 4 Jan 2022 at 19:15, Johan Jonker wrote:
>>>
>>> The Rockchip rk3066 SoC has 3 dw-apb-timer nodes.
>>> U-boot is compiled with OF_PLATDATA TPL/SPL options,
>>> so add OF_PLATDATA support for the dw-apb-timer.
>>> Also change driver name to be able to compile with
>>> U-boot scripts. No reset OF_PLATDATA support was added,
>>> because the rk3066 nodes don't need/have them.
>>>
>>> Signed-off-by: Johan Jonker
>>> ---
>>>
>>> Changed V2:
>>> replace if (IS_ENABLED(OF_REAL)) by #if CONFIG_IS_ENABLED(OF_REAL)
>>> ---
>>> drivers/timer/dw-apb-timer.c | 30 +-
>>> 1 file changed, 25 insertions(+), 5 deletions(-)
>>>
>>
>> This seems OK but you have included unrelated changes (whitespace)
>> which should go in a separate patch.
>
> OK
> With whitespace did you mean this or something else?
>
> - .of_to_plat = dw_apb_timer_of_to_plat,
> + .of_to_plat = dw_apb_timer_of_to_plat,
>
>>
>> Can you use if() instead of #if for the CONFIG_IS_ENABLED(OF_REAL) ?
>
> See comments above.
> Currently not it seems.
>
>>
>> Regards,
>> Simon
>>
Re: [PATCH] Revert "clk: Detect failure to set defaults"
On 1/5/22 2:37 PM, Tom Rini wrote:
On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
On 1/1/22 22:41, Sean Anderson wrote:
Hi Marek,
Hi,
Please CC clock maintainers for future patches.
btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
zero reviews/acks from clock maintainers.
At the time, I reviewed it. However, I was also not a clock maintainer
at that point, and my RB was not picked up when Simon sent v2.
Ultimately the original problem was that errors when assigning clocks
automatically were generally not reported. The only way to detect them
was to verify that the clocks were configured correctly after the fact.
My attempt to address this was [2].
[1]
https://lore.kernel.org/u-boot/e9eea30a-970b-7d70-267f-520071b48...@gmail.com/
[2] https://lore.kernel.org/u-boot/20210409021313.433558-2-sean...@gmail.com/
On 1/1/22 1:51 PM, Marek Vasut wrote:
This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
The aforementioned patch causes massive breakage on all platforms which
have 'assigned-clock' DT property in their DT which references any clock
that are not supported by the platform clock driver. That can easily
happen either in SPL, or because the clock driver is reduced. Currently
it seems all iMX8M are affected and fail to boot altogether.
Signed-off-by: Marek Vasut
Cc: Peng Fan
Cc: Simon Glass
---
drivers/clk/clk-uclass.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index f2d26427543..094b1abf13c 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
clk *clk)
int clk_uclass_post_probe(struct udevice *dev)
{
-int ret;
-
/*
* when a clock provider is probed. Call clk_set_defaults()
* also after the device is probed. This takes care of cases
* where the DT is used to setup default parents and rates
* using assigned-clocks
*/
-ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
-if (ret)
-return log_ret(ret);
+clk_set_defaults(dev, CLK_DEFAULTS_POST);
return 0;
}
See [1] for previous discussion. For more background,
- Device trees for i.MX are sync'd with Linux.
- General clock assignments may live in the clock-controller node,
clock assignments can be anywhere, even in non-clock-controller nodes.
Sure, but since those assignments are made only when the device is
probed, it is generally safe to assume that they are necessary for the
device to function. This is opposed to assignments in the clock node,
which may be OK to ignore (as long as the system functions properly).
including those which U-Boot does not implement, but which Linux does.
It's OK to not set up these clocks, but U-Boot doesn't know that and
fails.
We don't necessarily need to revert this commit, but we do need a way to
say "it's OK not to set the defaults, since we can function without
them". Tom suggested doing this in the clock driver last time. I think a
Kconfig or a device tree property would work, perhaps something like
'u-boot,clock-defaults-optional'.
We didn't need custom DT properties before, Linux doesn't need them either,
so that approach seems wrong.
If the clock driver could say "skip unimplemented clock, because I don't
implement them and that is OK", that sounds like the right approach.
Unless the 2022.01 release should be completely broken for a lot of
platforms, I would propose we revert the clock uclass patch now and re-add
it right after the release, so we would not roll out a completely broken
release and would have more time to fix this properly.
It'll be no more broken than v2021.10 was for whatever platforms have
problems here, yes? Since that's what has the problematic commit.
I agree with Marek here. We knew this broke boards before v2021.10 was
released, but it was not reverted for that release. We should not make
the same mistake again.
Reviewed-by: Sean Anderson
[3]
https://lore.kernel.org/u-boot/dbde2b83044ce9f3e8c360e9ddce0fa8db16f8ef.ca...@nedap.com/
Re: [PATCH] Revert "clk: Detect failure to set defaults"
On 1/5/22 20:37, Tom Rini wrote:
On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
On 1/1/22 22:41, Sean Anderson wrote:
Hi Marek,
Hi,
Please CC clock maintainers for future patches.
btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
zero reviews/acks from clock maintainers.
On 1/1/22 1:51 PM, Marek Vasut wrote:
This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
The aforementioned patch causes massive breakage on all platforms which
have 'assigned-clock' DT property in their DT which references any clock
that are not supported by the platform clock driver. That can easily
happen either in SPL, or because the clock driver is reduced. Currently
it seems all iMX8M are affected and fail to boot altogether.
Signed-off-by: Marek Vasut
Cc: Peng Fan
Cc: Simon Glass
---
drivers/clk/clk-uclass.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index f2d26427543..094b1abf13c 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
clk *clk)
int clk_uclass_post_probe(struct udevice *dev)
{
- int ret;
-
/*
* when a clock provider is probed. Call clk_set_defaults()
* also after the device is probed. This takes care of cases
* where the DT is used to setup default parents and rates
* using assigned-clocks
*/
- ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
- if (ret)
- return log_ret(ret);
+ clk_set_defaults(dev, CLK_DEFAULTS_POST);
return 0;
}
See [1] for previous discussion. For more background,
- Device trees for i.MX are sync'd with Linux.
- General clock assignments may live in the clock-controller node,
clock assignments can be anywhere, even in non-clock-controller nodes.
including those which U-Boot does not implement, but which Linux does.
It's OK to not set up these clocks, but U-Boot doesn't know that and
fails.
We don't necessarily need to revert this commit, but we do need a way to
say "it's OK not to set the defaults, since we can function without
them". Tom suggested doing this in the clock driver last time. I think a
Kconfig or a device tree property would work, perhaps something like
'u-boot,clock-defaults-optional'.
We didn't need custom DT properties before, Linux doesn't need them either,
so that approach seems wrong.
If the clock driver could say "skip unimplemented clock, because I don't
implement them and that is OK", that sounds like the right approach.
Unless the 2022.01 release should be completely broken for a lot of
platforms, I would propose we revert the clock uclass patch now and re-add
it right after the release, so we would not roll out a completely broken
release and would have more time to fix this properly.
It'll be no more broken than v2021.10 was for whatever platforms have
problems here, yes? Since that's what has the problematic commit.
So it seems. Does that mean we are OK with releasing such a broken
release, even though there is an easy way to improve the situation ?
Re: [PATCH] Revert "clk: Detect failure to set defaults"
On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
> On 1/1/22 22:41, Sean Anderson wrote:
> > Hi Marek,
>
> Hi,
>
> > Please CC clock maintainers for future patches.
>
> btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
> zero reviews/acks from clock maintainers.
>
> > On 1/1/22 1:51 PM, Marek Vasut wrote:
> > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> > > The aforementioned patch causes massive breakage on all platforms which
> > > have 'assigned-clock' DT property in their DT which references any clock
> > > that are not supported by the platform clock driver. That can easily
> > > happen either in SPL, or because the clock driver is reduced. Currently
> > > it seems all iMX8M are affected and fail to boot altogether.
> > >
> > > Signed-off-by: Marek Vasut
> > > Cc: Peng Fan
> > > Cc: Simon Glass
> > > ---
> > > drivers/clk/clk-uclass.c | 6 +-
> > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > index f2d26427543..094b1abf13c 100644
> > > --- a/drivers/clk/clk-uclass.c
> > > +++ b/drivers/clk/clk-uclass.c
> > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
> > > clk *clk)
> > > int clk_uclass_post_probe(struct udevice *dev)
> > > {
> > > - int ret;
> > > -
> > > /*
> > > * when a clock provider is probed. Call clk_set_defaults()
> > > * also after the device is probed. This takes care of cases
> > > * where the DT is used to setup default parents and rates
> > > * using assigned-clocks
> > > */
> > > - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > - if (ret)
> > > - return log_ret(ret);
> > > + clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > return 0;
> > > }
> > >
> >
> > See [1] for previous discussion. For more background,
> >
> > - Device trees for i.MX are sync'd with Linux.
> > - General clock assignments may live in the clock-controller node,
>
> clock assignments can be anywhere, even in non-clock-controller nodes.
>
> > including those which U-Boot does not implement, but which Linux does.
> > It's OK to not set up these clocks, but U-Boot doesn't know that and
> > fails.
> >
> > We don't necessarily need to revert this commit, but we do need a way to
> > say "it's OK not to set the defaults, since we can function without
> > them". Tom suggested doing this in the clock driver last time. I think a
> > Kconfig or a device tree property would work, perhaps something like
> > 'u-boot,clock-defaults-optional'.
>
> We didn't need custom DT properties before, Linux doesn't need them either,
> so that approach seems wrong.
>
> If the clock driver could say "skip unimplemented clock, because I don't
> implement them and that is OK", that sounds like the right approach.
>
> Unless the 2022.01 release should be completely broken for a lot of
> platforms, I would propose we revert the clock uclass patch now and re-add
> it right after the release, so we would not roll out a completely broken
> release and would have more time to fix this properly.
It'll be no more broken than v2021.10 was for whatever platforms have
problems here, yes? Since that's what has the problematic commit.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] Revert "clk: Detect failure to set defaults"
On 1/1/22 22:41, Sean Anderson wrote:
Hi Marek,
Hi,
Please CC clock maintainers for future patches.
btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646
has zero reviews/acks from clock maintainers.
On 1/1/22 1:51 PM, Marek Vasut wrote:
This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
The aforementioned patch causes massive breakage on all platforms which
have 'assigned-clock' DT property in their DT which references any clock
that are not supported by the platform clock driver. That can easily
happen either in SPL, or because the clock driver is reduced. Currently
it seems all iMX8M are affected and fail to boot altogether.
Signed-off-by: Marek Vasut
Cc: Peng Fan
Cc: Simon Glass
---
drivers/clk/clk-uclass.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index f2d26427543..094b1abf13c 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
clk *clk)
int clk_uclass_post_probe(struct udevice *dev)
{
- int ret;
-
/*
* when a clock provider is probed. Call clk_set_defaults()
* also after the device is probed. This takes care of cases
* where the DT is used to setup default parents and rates
* using assigned-clocks
*/
- ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
- if (ret)
- return log_ret(ret);
+ clk_set_defaults(dev, CLK_DEFAULTS_POST);
return 0;
}
See [1] for previous discussion. For more background,
- Device trees for i.MX are sync'd with Linux.
- General clock assignments may live in the clock-controller node,
clock assignments can be anywhere, even in non-clock-controller nodes.
including those which U-Boot does not implement, but which Linux does.
It's OK to not set up these clocks, but U-Boot doesn't know that and
fails.
We don't necessarily need to revert this commit, but we do need a way to
say "it's OK not to set the defaults, since we can function without
them". Tom suggested doing this in the clock driver last time. I think a
Kconfig or a device tree property would work, perhaps something like
'u-boot,clock-defaults-optional'.
We didn't need custom DT properties before, Linux doesn't need them
either, so that approach seems wrong.
If the clock driver could say "skip unimplemented clock, because I don't
implement them and that is OK", that sounds like the right approach.
Unless the 2022.01 release should be completely broken for a lot of
platforms, I would propose we revert the clock uclass patch now and
re-add it right after the release, so we would not roll out a completely
broken release and would have more time to fix this properly.
Re: Please pull u-boot-marvell/master
On Wed, Jan 05, 2022 at 06:27:38PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull this last minute kwbimage related fix: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: mkimage_fit_atf.sh: not found
On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
wrote:
>
> Hello Tim,
>
> > -Original Message-
> > From: U-Boot On Behalf Of Tim Harvey
> > Sent: Tuesday, January 4, 2022 11:48 PM
> > To: u-boot ; Stefano Babic ; Fabio
> > Estevam
> >
> > Cc: Schrempf Frieder ; Adam Ford
> > ; Marcel Ziswiler ; Jagan Teki
> >
> > Subject: mkimage_fit_atf.sh: not found
> >
> > Stefano and Fabio,
> >
> > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > master due to mkimage_fit_atf.sh not found:
> > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> >
>
> This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator
> script")
So why was that merged when it breaks several boards that are not
switched to binman because of the CI issue?
>
> > As far as I can tell the other boards that are still using
> > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
>
> imx8mq_evk is already converted and I've sent a patch for it, see [1].
>
> >
> > What is the state of the binman conversion? I submitted a series to
> > convert my boards to binman and it has just been sitting without any
> > response for months now [1].
>
> I believe that the reason for your series sitting in the queue is the same as
> for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
>
Right, so imx8mq_evk (and others) are completely broken for the
pending release correct?
Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
generator script")
Tim
> >
> > I'm not sure when the above breakage occurred but the conversion to
> > binman resolves it and other things.
> >
> > Please let me know what you expect me to do to resolve this as there
> > is a release pending.
> >
> > Best regards,
> >
> > Tim
> > [1] https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-
> > thar...@gateworks.com/
>
> -- andrey
>
> Link: [1]:
> http://patchwork.ozlabs.org/project/uboot/patch/20211203161802.12699-1-andrey.zhizhi...@leica-geosystems.com/
Re: [PATCH] board: ast2500/ast2600: initialize LEDs
On Tue, Nov 23, 2021 at 10:08:47PM +0300, Andrei Kartashev wrote: > Add option to initialize LEDs in board_init stage for aspeed-based > boards. > > Signed-off-by: Andrei Kartashev > --- > board/aspeed/evb_ast2500/evb_ast2500.c | 8 > board/aspeed/evb_ast2600/evb_ast2600.c | 8 > 2 files changed, 16 insertions(+) This does not currently build on current next, please rebase, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/6] ARM: dts: s700: add MMC/SD controller node
On Sun, Nov 28, 2021 at 05:02:23PM +0530, Amit Singh Tomar wrote: > From: Amit Singh Tomar > > This patch adds node for mmc/sd controller found on Action Semi OWL > S700 SoC. > > Since, upstream Linux binding has not been merged for S700 MMC/SD > controller, Changes are put in u-boot specific dtsi file. > > Signed-off-by: Amit Singh Tomar This leads to: arch/arm/dts/s700-cubieboard7.dtb: ERROR (phandle_references): /soc/mmc@e021 : Reference to non-existent node or label "dma" Please rebase on top of current next, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] fs/erofs: new filesystem
Hi Jianan, On Wed, Aug 25, 2021 at 06:40:42PM -0400, Tom Rini wrote: > On Mon, Aug 23, 2021 at 08:36:43PM +0800, Huang Jianan wrote: > > > From: Huang Jianan > > > > Add erofs filesystem support. > > > > The code is adapted from erofs-utils in order to reduce maintenance > > burden and keep with the latest feature. > > > > Changes since v1: > > - fix the inconsistency between From and SoB (Bin Meng); > > - add missing license header; > > > > Huang Jianan (3): > > fs/erofs: add erofs filesystem support > > fs/erofs: add lz4 1.8.3 decompressor > > fs/erofs: add lz4 decompression support > > Aside from what I've just now sent, can you please extend the existing > py/tests/ to cover basic functionality here, ensure they run on sandbox > and in CI? Thanks. Any further progress on this work? At least sync it up with erofs-utils 1.4? Thanks, Gao Xiang > > -- > Tom
Re: [PATCH v1 4/5] configs: Migrate CONFIG_SYS_MAX_FLASH_BANKS to Kconfig
On 1/4/22 14:24, Patrick Delaunay wrote: Use moveconfig.py script to convert define CONFIG_SYS_MAX_FLASH_BANKS and CONFIG_SYS_MAX_FLASH_BANKS_DETECT to Kconfig and move these entries to defconfigs. Signed-off-by: Patrick Delaunay Reviewed-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan --- README | 3 --- configs/3c120_defconfig | 1 + configs/M5253DEMO_defconfig | 1 + configs/MPC8548CDS_36BIT_defconfig | 1 + configs/MPC8548CDS_defconfig | 1 + configs/MPC8548CDS_legacy_defconfig | 1 + configs/P3041DS_NAND_defconfig | 1 + configs/P3041DS_SDCARD_defconfig | 1 + configs/P3041DS_SPIFLASH_defconfig | 1 + configs/P3041DS_defconfig| 1 + configs/P4080DS_SDCARD_defconfig | 1 + configs/P4080DS_SPIFLASH_defconfig | 1 + configs/P4080DS_defconfig| 1 + configs/P5040DS_NAND_defconfig | 1 + configs/P5040DS_SDCARD_defconfig | 1 + configs/P5040DS_SPIFLASH_defconfig | 1 + configs/P5040DS_defconfig| 1 + configs/T1042D4RDB_NAND_defconfig| 1 + configs/T1042D4RDB_SDCARD_defconfig | 1 + configs/T1042D4RDB_SPIFLASH_defconfig| 1 + configs/T1042D4RDB_defconfig | 1 + configs/T2080QDS_NAND_defconfig | 1 + configs/T2080QDS_SDCARD_defconfig| 1 + configs/T2080QDS_SECURE_BOOT_defconfig | 1 + configs/T2080QDS_SPIFLASH_defconfig | 1 + configs/T2080QDS_defconfig | 1 + configs/T4240RDB_SDCARD_defconfig| 1 + configs/T4240RDB_defconfig | 1 + configs/boston32r2_defconfig | 1 + configs/boston32r2el_defconfig | 1 + configs/boston32r6_defconfig | 1 + configs/boston32r6el_defconfig | 1 + configs/boston64r2_defconfig | 1 + configs/boston64r2el_defconfig | 1 + configs/boston64r6_defconfig | 1 + configs/boston64r6el_defconfig | 1 + configs/cobra5272_defconfig | 1 + configs/comtrend_ct5361_ram_defconfig| 1 + configs/comtrend_wap5813n_ram_defconfig | 1 + configs/ethernut5_defconfig | 1 + configs/huawei_hg556a_ram_defconfig | 1 + configs/j7200_evm_a72_defconfig | 1 + configs/j7200_evm_r5_defconfig | 1 + configs/j721e_evm_a72_defconfig | 1 + configs/j721e_hs_evm_a72_defconfig | 1 + configs/ls1021aqds_ddr4_nor_defconfig| 1 + configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 + configs/ls1021aqds_nand_defconfig| 1 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021aqds_nor_defconfig | 1 + configs/ls1021aqds_nor_lpuart_defconfig | 1 + configs/ls1021aqds_sdcard_ifc_defconfig | 1 + configs/ls1046aqds_SECURE_BOOT_defconfig | 1 + configs/ls1046aqds_defconfig | 1 + configs/ls1046aqds_lpuart_defconfig | 1 + configs/ls1046aqds_nand_defconfig| 1 + configs/ls1046aqds_sdcard_ifc_defconfig | 1 + configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1046aqds_tfa_defconfig | 1 + configs/ls1088aqds_defconfig | 1 + configs/ls1088aqds_sdcard_ifc_defconfig | 1 + configs/ls1088aqds_tfa_defconfig | 1 + configs/ls2080aqds_SECURE_BOOT_defconfig | 1 + configs/ls2080aqds_defconfig | 1 + configs/ls2088aqds_tfa_defconfig | 1 + configs/qemu_arm64_defconfig | 2 ++ configs/qemu_arm_defconfig | 2 ++ configs/r8a77990_ebisu_defconfig | 1 + configs/r8a77995_draak_defconfig | 1 + configs/rcar3_salvator-x_defconfig | 1 + configs/rcar3_ulcb_defconfig | 1 + configs/sfr_nb4-ser_ram_defconfig| 1 + configs/socrates_defconfig | 1 + drivers/mtd/Kconfig | 27 include/configs/10m50_devboard.h | 1 - include/configs/3c120_devboard.h | 2 -- include/configs/M5208EVBE.h | 1 - include/configs/M5235EVB.h | 1 - include/configs/M5249EVB.h | 1 - include/configs/M5253DEMO.h | 1 - include/configs/M5272C3.h| 1 - include/configs/M5275EVB.h | 1 - include/configs/M5282EVB.h | 1 - include/configs/M53017EVB.h | 1 - include/configs/M5329EVB.h | 1 - include/configs/M5373EVB.h | 1 -
Re: [PATCH V2 1/7] tools: imx8mimage: not abort when mmap fail
Re: [PATCH v2] arm: dts: Aspeed: add Bletchley dts
On Tue, Jan 04, 2022 at 06:03:17PM +0800, Potin Lai wrote: > Initial introduction of Bletchley equipped with > Aspeed 2600 BMC SoC. > > Signed-off-by: Potin Lai > > --- > > Change since v1: > - Disable mdio0, mdio1, mdio2 > - Remove mac0, mac1, mac3 (keep disabled) > - Enable mac2, and set to fixed-link > --- > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/ast2600-bletchley.dts | 285 + > 2 files changed, 287 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/ast2600-bletchley.dts > Reviewed-by: Patrick Williams -- Patrick Williams signature.asc Description: PGP signature
Please pull u-boot-marvell/master
Hi Tom, please pull this last minute kwbimage related fix: - kwbimage: Fix checksum calculation for v1 images (Pierre) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=143=results Thanks, Stefan The following changes since commit b3f84a939f514a266a5a3aa97cbe2787c2d73d89: Merge tag 'video-20211228' of https://source.denx.de/u-boot/custodians/u-boot-video (2021-12-28 11:19:26 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 9203c73895ab410f7a57f56ec26201253a1f008b: tools: kwbimage: Fix checksum calculation for v1 images (2022-01-05 16:31:58 +0100) Pierre Bourdon (1): tools: kwbimage: Fix checksum calculation for v1 images tools/kwbimage.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Re: [PATCH] tools: kwbimage: Fix checksum calculation for v1 images
On 1/5/22 16:30, Stefan Roese wrote:
On 12/25/21 20:50, Pierre Bourdon wrote:
Recent changes caused fields in the image main header to be modified
after the header checksum had already been computed. Move the checksum
computation to once again be the last operation performed on the header.
Fixes: 2b0980c24027 ("tools: kwbimage: Fill the real header size into
the main header")
Signed-off-by: Pierre Bourdon
Reviewed-by: Stefan Roese
Applied to u-boot-marvell/master
Thanks,
Stefan
Thanks,
Stefan
---
tools/kwbimage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 875f636c7a..0951d7861c 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1398,9 +1398,6 @@ static void *image_create_v1(size_t *imagesz,
struct image_tool_params *params,
headersz, image, secure_hdr))
return NULL;
- /* Calculate and set the header checksum */
- main_hdr->checksum = image_checksum8(main_hdr, headersz);
-
*imagesz = headersz;
/* Fill the real header size without padding into the main
header */
@@ -1410,6 +1407,9 @@ static void *image_create_v1(size_t *imagesz,
struct image_tool_params *params,
main_hdr->headersz_lsb = cpu_to_le16(headersz & 0x);
main_hdr->headersz_msb = (headersz & 0x) >> 16;
+ /* Calculate and set the header checksum */
+ main_hdr->checksum = image_checksum8(main_hdr, headersz);
+
return image;
}
Viele Grüße,
Stefan Roese
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-pci] pci: iproc: Set all 24 bits of PCI class code
On Wed, Jan 5, 2022 at 1:50 AM Pali Rohár wrote: > > Register 0x43c in its low 24 bits contains PCI class code. > > Update code to set all 24 bits of PCI class code and not only upper 16 bits > of PCI class code. > > Use standard U-Boot macro (PCI_CLASS_BRIDGE_PCI << 8) for constructing all > 24-bits of PCI class for PCI bridge Normal decode. > > Signed-off-by: Pali Rohár > > --- > Roman helped me with this change and confirmed that class code is stored > really in bits [23:0] of custom register 0x43c (normally class code is > stored in bits [31:8] of pci register 0x08). > --- > drivers/pci/pcie_iproc.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/pci/pcie_iproc.c b/drivers/pci/pcie_iproc.c > index be03dcbd97c0..fe68e417ae80 100644 > --- a/drivers/pci/pcie_iproc.c > +++ b/drivers/pci/pcie_iproc.c > @@ -1127,15 +1127,14 @@ static int iproc_pcie_check_link(struct iproc_pcie > *pcie) > u32 link_status, class; > > pcie->link_is_active = false; > - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */ > + /* force class to PCI bridge Normal decode (0x060400) */ > #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c > -#define PCI_CLASS_BRIDGE_MASK 0x00 > -#define PCI_CLASS_BRIDGE_SHIFT 8 > +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xff > iproc_pci_raw_config_read32(pcie, 0, > PCI_BRIDGE_CTRL_REG_OFFSET, > 4, ); > - class &= ~PCI_CLASS_BRIDGE_MASK; > - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT); > + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK; > + class |= (PCI_CLASS_BRIDGE_PCI << 8); > iproc_pci_raw_config_write32(pcie, 0, > PCI_BRIDGE_CTRL_REG_OFFSET, > 4, class); > -- > 2.20.1 > Acked-by: Roman Bacik -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: [RFC Patch v3] binman: add support for creating dummy files for external blobs
Hi Heiko, On Wed, 5 Jan 2022 at 09:06, Simon Glass wrote: > > Hi Heiko, > > On Wed, 5 Jan 2022 at 05:58, Heiko Thiery wrote: > > > > While converting to binman for an imx8mq board, it has been found that > > building in the u-boot CI fails. This is because an imx8mq requires an > > external binary (signed_hdmi_imx8m.bin). If this file cannot be found > > mkimage fails. > > To be able to build this board in the u-boot CI a binman option > > (--fake-ext-blobs) is introduced that can be switched on via the u-boot > > makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are > > created. > > > > Signed-off-by: Heiko Thiery > > --- > > v3: > > - add CheckFakedBlobs() and print a list of faked files at the end > > - add unittest > > > > v2: > > - pass allow_fake_blobs to ProcessImage() > > - set AllowAllowFakeBlob() to images/entries > > - create fake blob in Entry_blot.ObtainContents() when file is missing and > >creation is allowed > > > > still missing: > > - unittest > > - option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment > > variable. With that we could simply set this env variable in the CI > > (gitlab-ci.yml) with adding support to buildman. > > > > Makefile| 1 + > > tools/binman/cmdline.py | 2 ++ > > tools/binman/control.py | 26 +++--- > > tools/binman/entry.py | 23 +++ > > tools/binman/etype/blob.py | 18 ++ > > tools/binman/etype/blob_ext.py | 8 > > tools/binman/etype/mkimage.py | 20 > > tools/binman/etype/section.py | 20 > > tools/binman/ftest.py | 13 - > > tools/binman/test/203_fake_blob.dts | 14 ++ > > 10 files changed, 137 insertions(+), 8 deletions(-) > > create mode 100644 tools/binman/test/203_fake_blob.dts > > Please check that you keep to 80cols, except where it would split a string. > > This is missing a few holes in test coverage. Did you try 'binman test -T' ? > > If you are stuck I could fiddle with it a bit. BTW if you need the external tools you might try u-boot-dm/bin-working which has a command that might fetch them: binman tool --fetch missing It is WIP at present, so has an old version of your patch in there. Regards, Simon
Re: [PATCH v2] rockchip: timer: add OF_PLATDATA support for dw-apb-timer
Hi Simon,
Thanks you for your comments.
Shown below are the objdump results of the full U-boot binary
dw_apb_timer_of_to_plat() function.
Same goes for the dw_apb_timer_probe() function.
With if (IS_ENABLED(OF_REAL)) I don't get a useful timer result (boot
hangs after timer probe, because in full U-boot the reg value isn't
correct defined. Part of the init probe is missing.
Could you try it yourself?
Please advise what options we have.
Kind regards,
Johan Jonker
==
Patch version 1 with if (IS_ENABLED(OF_REAL)) {}:
arm-linux-gnueabihf-objdump -d drivers/timer/dw-apb-timer.o >
../dw-apb-timer-20220105-v1.asm
:
0: 2000movsr0, #0
2: 4770bx lr
arm-linux-gnueabihf-objdump -d spl/drivers/timer/dw-apb-timer.o >
../dw-apb-timer-20220105-spl-v1.asm
arm-linux-gnueabihf-objdump -d tpl/drivers/timer/dw-apb-timer.o >
../dw-apb-timer-20220105-tpl-v1.asm
==
patch version 2 with #if CONFIG_IS_ENABLED(OF_REAL):
arm-linux-gnueabihf-objdump -d drivers/timer/dw-apb-timer.o > ../dw-apb-
timer-20220105-v2.asm
:
0: b538push{r3, r4, r5, lr}
2: 4605mov r5, r0
4: f7ff fffe bl 0
8: 4604mov r4, r0
a: 4628mov r0, r5
c: f7ff fffe bl 0
10: 6020str r0, [r4, #0]
12: 2000movsr0, #0
14: bd38pop {r3, r4, r5, pc}
arm-linux-gnueabihf-objdump -d spl/drivers/timer/dw-apb-timer.o >
../dw-apb-timer-20220105-spl-v2.asm
arm-linux-gnueabihf-objdump -d tpl/drivers/timer/dw-apb-timer.o >
../dw-apb-timer-20220105-tpl-v2.asm
===
On 1/5/22 3:03 PM, Simon Glass wrote:
> Hi Johan,
>
> On Tue, 4 Jan 2022 at 19:15, Johan Jonker wrote:
>>
>> The Rockchip rk3066 SoC has 3 dw-apb-timer nodes.
>> U-boot is compiled with OF_PLATDATA TPL/SPL options,
>> so add OF_PLATDATA support for the dw-apb-timer.
>> Also change driver name to be able to compile with
>> U-boot scripts. No reset OF_PLATDATA support was added,
>> because the rk3066 nodes don't need/have them.
>>
>> Signed-off-by: Johan Jonker
>> ---
>>
>> Changed V2:
>> replace if (IS_ENABLED(OF_REAL)) by #if CONFIG_IS_ENABLED(OF_REAL)
>> ---
>> drivers/timer/dw-apb-timer.c | 30 +-
>> 1 file changed, 25 insertions(+), 5 deletions(-)
>>
>
> This seems OK but you have included unrelated changes (whitespace)
> which should go in a separate patch.
OK
With whitespace did you mean this or something else?
- .of_to_plat = dw_apb_timer_of_to_plat,
+ .of_to_plat = dw_apb_timer_of_to_plat,
>
> Can you use if() instead of #if for the CONFIG_IS_ENABLED(OF_REAL) ?
See comments above.
Currently not it seems.
>
> Regards,
> Simon
>
Re: [RFC Patch v3] binman: add support for creating dummy files for external blobs
Hi Heiko, On Wed, 5 Jan 2022 at 05:58, Heiko Thiery wrote: > > While converting to binman for an imx8mq board, it has been found that > building in the u-boot CI fails. This is because an imx8mq requires an > external binary (signed_hdmi_imx8m.bin). If this file cannot be found > mkimage fails. > To be able to build this board in the u-boot CI a binman option > (--fake-ext-blobs) is introduced that can be switched on via the u-boot > makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are > created. > > Signed-off-by: Heiko Thiery > --- > v3: > - add CheckFakedBlobs() and print a list of faked files at the end > - add unittest > > v2: > - pass allow_fake_blobs to ProcessImage() > - set AllowAllowFakeBlob() to images/entries > - create fake blob in Entry_blot.ObtainContents() when file is missing and >creation is allowed > > still missing: > - unittest > - option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment > variable. With that we could simply set this env variable in the CI > (gitlab-ci.yml) with adding support to buildman. > > Makefile| 1 + > tools/binman/cmdline.py | 2 ++ > tools/binman/control.py | 26 +++--- > tools/binman/entry.py | 23 +++ > tools/binman/etype/blob.py | 18 ++ > tools/binman/etype/blob_ext.py | 8 > tools/binman/etype/mkimage.py | 20 > tools/binman/etype/section.py | 20 > tools/binman/ftest.py | 13 - > tools/binman/test/203_fake_blob.dts | 14 ++ > 10 files changed, 137 insertions(+), 8 deletions(-) > create mode 100644 tools/binman/test/203_fake_blob.dts Please check that you keep to 80cols, except where it would split a string. This is missing a few holes in test coverage. Did you try 'binman test -T' ? If you are stuck I could fiddle with it a bit. Regards, Simon
Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
Hi All, On 05/01/22 13:54, Jesse Taube wrote: On 1/5/22 07:14, Andre Przywara wrote: On Wed, 05 Jan 2022 19:36:29 +0800 Icenowy Zheng wrote: Hi Jesse, 在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道： This patch set aims to add suport for the SUNIV and F1C100s. Suport has been in linux for a while now, but not in u-boot. This patchset contains: - CPU specific initialization code - SUNIV dram driver - SUNIV clock driver adaption - SUNIV gpio driver adaption - SUNIV uart driver adaption - F1C100s basic support I am hoping to get Icenowy's patches in as it seems she hasnt submitted in a while. The only edits I made to her code is rebasing it against ML and changing some formating. I also re-grouped her commits. I got too lazy to send it (because I think F1C100s is just too weak)... I am wondering if the dram driver should be moved into device drivers rather than in mach-sunxi. I am also wondering if it is okay to submit some one elses code, and if so how should I do so. As you are keeping my SoB and adding yours, it's totally okay. Thanks Icenowy for confirming! Jesse: yes, it's perfectly fine to send patches from someone else, as long as you keep the authorship, their SoB, and add your's. Typical reasons are lack of time or interest from the original author. But it's customary to ask the author first I did but it must have gotten lost in the cosmos. , and care should be taken when changing patches, as this might not be in the interest of the original author (and they are the ones who will get blamed for bugs). Also please mark the series either as a Resend or as a v2. So with Icenowy's confirmation above I consider this fine. But what was actually holding back this series was lack of review, testing and/or interest. Well the price of the SOC has gained it some popularity, aswell as a couple forum posts. Similar to Icenowy my personal interest in crufty old cores is somewhat limited, so this wasn't very high on my priority list. It is very slow but its a good challenge. Slow depending on application :-) Two of my customers would like to use it in Q2/Q3 for very low-end HMIs. And as I see, one of the last F1Cxxx is F1C800s released in 2017. Here the good thing they have is ram onboard. So given that there is apparently some interest now: Can you confirm that you have reviewed the series, or at least tested this? I have tested this yes. I would be interested to know if a second pair of eyes had a look, and to what extent. I'm Sending giulio.benetti@ some boards I made he will also test. I'm sure many other people will be willing to test aswell. Yes, I'll test on Jesse's board and on Lichee-pi-nano too when I have time, this way I'll be able to give a Tested-by: me. Best regards -- Giulio Benetti Benetti Engineering sas I don't have any hardware, so would need to rely on others to make sure this code is somewhat sane. I can send you one of my many boards :) And it basically looks like a v2 of Icenowy's series, so can you give a Changelog of the differences? I skimmed over her original series back then, so I would be interested in what makes this version special. It passes checkpatch on the latest. Cheers, Andre Thanks for cleaning up these patches! ;-) NP! I took https://github.com/Lichee-Pi/u-boot/tree/nano-v2018.01 re-based it against mainline and fixed formatting in a few files. I also removed the spi-flash driver as it was causing issues and we can boot from sdcard for now. there are some things I did to make the old code compatible with new code but mostly preprocessor and configs. For the dram driver I had to change a bit but none of the logic, i am worried that i may have to move it to /drivers. Do you want a more comprehensive list of changes?
Re: [PATCH] mtd: nand: pxa3xx: set mtd->dev
On 1/5/22 16:01, Robert Marko wrote:
Currently the pxa3xx driver does not set the udevice in the mtd_info
struct and this prevents the mtd from parsing the partitions via DTS
like for SPI-NOR.
So simply set the mtd->dev to the driver udevice.
Signed-off-by: Robert Marko
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 8ff58a7038..eb739bb3b9 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1913,6 +1913,7 @@ static int pxa3xx_nand_probe(struct udevice *dev)
* user's mtd partitions configuration would get broken.
*/
mtd->name = "pxa3xx_nand-0";
+ mtd->dev = dev;
info->cs = cs;
ret = pxa3xx_nand_scan(mtd);
if (ret) {
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] tools: kwbimage: Fix checksum calculation for v1 images
On 12/25/21 20:50, Pierre Bourdon wrote:
Recent changes caused fields in the image main header to be modified
after the header checksum had already been computed. Move the checksum
computation to once again be the last operation performed on the header.
Fixes: 2b0980c24027 ("tools: kwbimage: Fill the real header size into the main
header")
Signed-off-by: Pierre Bourdon
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwbimage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 875f636c7a..0951d7861c 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1398,9 +1398,6 @@ static void *image_create_v1(size_t *imagesz, struct
image_tool_params *params,
headersz, image, secure_hdr))
return NULL;
- /* Calculate and set the header checksum */
- main_hdr->checksum = image_checksum8(main_hdr, headersz);
-
*imagesz = headersz;
/* Fill the real header size without padding into the main header */
@@ -1410,6 +1407,9 @@ static void *image_create_v1(size_t *imagesz, struct
image_tool_params *params,
main_hdr->headersz_lsb = cpu_to_le16(headersz & 0x);
main_hdr->headersz_msb = (headersz & 0x) >> 16;
+ /* Calculate and set the header checksum */
+ main_hdr->checksum = image_checksum8(main_hdr, headersz);
+
return image;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH] mtd: nand: pxa3xx: set mtd->dev
Currently the pxa3xx driver does not set the udevice in the mtd_info
struct and this prevents the mtd from parsing the partitions via DTS
like for SPI-NOR.
So simply set the mtd->dev to the driver udevice.
Signed-off-by: Robert Marko
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 8ff58a7038..eb739bb3b9 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1913,6 +1913,7 @@ static int pxa3xx_nand_probe(struct udevice *dev)
* user's mtd partitions configuration would get broken.
*/
mtd->name = "pxa3xx_nand-0";
+ mtd->dev = dev;
info->cs = cs;
ret = pxa3xx_nand_scan(mtd);
if (ret) {
--
2.34.1
Re: [RFC Patch v2] binman: add support for creating dummy files for external blobs
Hi Simon, Am Mi., 5. Jan. 2022 um 15:05 Uhr schrieb Simon Glass : > > Hi Heiko, > > On Tue, 4 Jan 2022 at 07:22, Heiko Thiery wrote: > > > > Hi Simon, > > > > > > Am So., 2. Jan. 2022 um 18:15 Uhr schrieb Simon Glass : > > > > > > Hi Heiko, > > > > > > On Thu, 2 Dec 2021 at 19:53, Simon Glass wrote: > > > > > > > > Hi Heiko, > > > > > > > > On Mon, 29 Nov 2021 at 02:48, Heiko Thiery > > > > wrote: > > > > > > > > > > While converting to binman for an imx8mq board, it has been found that > > > > > building in the u-boot CI fails. This is because an imx8mq requires an > > > > > external binary (signed_hdmi_imx8m.bin). If this file cannot be found > > > > > mkimage fails. > > > > > To be able to build this board in the u-boot CI a binman option > > > > > (--fake-ext-blobs) is introduced that can be switched on via the > > > > > u-boot > > > > > makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy > > > > > files are > > > > > created. > > > > > > > > > > Signed-off-by: Heiko Thiery > > > > > --- > > > > > v2: > > > > > - pass allow_fake_blobs to ProcessImage() > > > > > - set AllowAllowFakeBlob() to images/entries > > > > > - create fake blob in Entry_blot.ObtainContents() when file is > > > > > missing and > > > > >creation is allowed > > > > > > > > > > still missing: > > > > > - unittest > > > > > - option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment > > > > > variable. With that we could simply set this env variable in > > > > > the CI > > > > > (gitlab-ci.yml) with adding support to buildman. > > > > > > > > > > Makefile | 1 + > > > > > tools/binman/cmdline.py| 2 ++ > > > > > tools/binman/control.py| 9 +++-- > > > > > tools/binman/entry.py | 11 +++ > > > > > tools/binman/etype/blob.py | 7 +++ > > > > > tools/binman/etype/blob_ext.py | 8 > > > > > tools/binman/etype/mkimage.py | 9 + > > > > > tools/binman/etype/section.py | 9 + > > > > > 8 files changed, 54 insertions(+), 2 deletions(-) > > > > > > > > This looks good to me! The only thing is that instead of the warning > > > > you should just print a single line at the end saying which blobs were > > > > faked. See missing_list in ProcessImage() for how that could work. You > > > > can set self.fake_blob in your blob.ObtainContents() and then have a > > > > similar thing to CheckMissing() to actually collect the list of > > > > entries which were faked. > > > > > > > > Also, for the real version can you please add a test (so 'binman test > > > > -T' stays at 100% test coverage) and some docs in binman.rst ? You can > > > > use testMissingBlob() as a template. > > > > > > Any word on this? I'd like to get this feature in and take a look at > > > missing vendor tools, too. > > > > I have a new version available with your comments included. But the > > tests are still missing. In the past days I had no motivation to work > > on that. I will try to do this in the next days. > > OK thanks. If you need help with the test-coverage part, let me know. I sent a new version about an hour ago with unittest included. -- Heiko
Re: [PATCH v2] rockchip: timer: add OF_PLATDATA support for dw-apb-timer
Hi Johan, On Tue, 4 Jan 2022 at 19:15, Johan Jonker wrote: > > The Rockchip rk3066 SoC has 3 dw-apb-timer nodes. > U-boot is compiled with OF_PLATDATA TPL/SPL options, > so add OF_PLATDATA support for the dw-apb-timer. > Also change driver name to be able to compile with > U-boot scripts. No reset OF_PLATDATA support was added, > because the rk3066 nodes don't need/have them. > > Signed-off-by: Johan Jonker > --- > > Changed V2: > replace if (IS_ENABLED(OF_REAL)) by #if CONFIG_IS_ENABLED(OF_REAL) > --- > drivers/timer/dw-apb-timer.c | 30 +- > 1 file changed, 25 insertions(+), 5 deletions(-) > This seems OK but you have included unrelated changes (whitespace) which should go in a separate patch. Can you use if() instead of #if for the CONFIG_IS_ENABLED(OF_REAL) ? Regards, Simon
Re: [RFC Patch v2] binman: add support for creating dummy files for external blobs
Hi Heiko, On Tue, 4 Jan 2022 at 07:22, Heiko Thiery wrote: > > Hi Simon, > > > Am So., 2. Jan. 2022 um 18:15 Uhr schrieb Simon Glass : > > > > Hi Heiko, > > > > On Thu, 2 Dec 2021 at 19:53, Simon Glass wrote: > > > > > > Hi Heiko, > > > > > > On Mon, 29 Nov 2021 at 02:48, Heiko Thiery wrote: > > > > > > > > While converting to binman for an imx8mq board, it has been found that > > > > building in the u-boot CI fails. This is because an imx8mq requires an > > > > external binary (signed_hdmi_imx8m.bin). If this file cannot be found > > > > mkimage fails. > > > > To be able to build this board in the u-boot CI a binman option > > > > (--fake-ext-blobs) is introduced that can be switched on via the u-boot > > > > makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files > > > > are > > > > created. > > > > > > > > Signed-off-by: Heiko Thiery > > > > --- > > > > v2: > > > > - pass allow_fake_blobs to ProcessImage() > > > > - set AllowAllowFakeBlob() to images/entries > > > > - create fake blob in Entry_blot.ObtainContents() when file is missing > > > > and > > > >creation is allowed > > > > > > > > still missing: > > > > - unittest > > > > - option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment > > > > variable. With that we could simply set this env variable in > > > > the CI > > > > (gitlab-ci.yml) with adding support to buildman. > > > > > > > > Makefile | 1 + > > > > tools/binman/cmdline.py| 2 ++ > > > > tools/binman/control.py| 9 +++-- > > > > tools/binman/entry.py | 11 +++ > > > > tools/binman/etype/blob.py | 7 +++ > > > > tools/binman/etype/blob_ext.py | 8 > > > > tools/binman/etype/mkimage.py | 9 + > > > > tools/binman/etype/section.py | 9 + > > > > 8 files changed, 54 insertions(+), 2 deletions(-) > > > > > > This looks good to me! The only thing is that instead of the warning > > > you should just print a single line at the end saying which blobs were > > > faked. See missing_list in ProcessImage() for how that could work. You > > > can set self.fake_blob in your blob.ObtainContents() and then have a > > > similar thing to CheckMissing() to actually collect the list of > > > entries which were faked. > > > > > > Also, for the real version can you please add a test (so 'binman test > > > -T' stays at 100% test coverage) and some docs in binman.rst ? You can > > > use testMissingBlob() as a template. > > > > Any word on this? I'd like to get this feature in and take a look at > > missing vendor tools, too. > > I have a new version available with your comments included. But the > tests are still missing. In the past days I had no motivation to work > on that. I will try to do this in the next days. OK thanks. If you need help with the test-coverage part, let me know. > > > Also I think your feature should be on by default. Regards, Simon
Re: [PATCH] lib: Kconfig: fix PHANDLE_CHECK_SEQ position outside of menu
On Tue, 4 Jan 2022 at 09:20, Eugen Hristev wrote:
>
> CONFIG_PHANDLE_CHECK_SEQ is outside of the menu 'Library routines'
> thus it's invisible in menuconfig and cannot be selected.
> Fix this by moving the 'endmenu' after the PHANDLE_CHECK_SEQ definition
>
> Fixes: c589132a1d ("fdt: Use phandle to distinguish DT nodes with same name")
> Signed-off-by: Eugen Hristev
> ---
> lib/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH] riscv: sifive: Fix OF_BOARD boot failure
On Tue, 4 Jan 2022 at 18:08, Bin Meng wrote:
>
> When using QEMU to have a quick test of booting U-Boot S-mode payload
> directly without the needs of preparing the SPI flash or SD card images
> for SiFive Unleashed board, as per the instructions [1], it currently
> does not boot any more.
>
> This was caused by the OF_PRIOR_STAGE removal, as gd->fdt_blob no longer
> points to a valid DTB. OF_BOARD is supposed to replace OF_PRIOR_STAGE,
> hence we need to add the OF_BOARD logic in board_fdt_blob_setup().
>
> [1]
> https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
>
> Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
> Fixes: d6f8ab30a2af ("treewide: Remove OF_PRIOR_STAGE")
> Signed-off-by: Bin Meng
> ---
>
> board/sifive/unleashed/unleashed.c | 2 +-
> board/sifive/unmatched/unmatched.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH] nitrogen6x: add missing pinctrl to fix mmc
Hi Gary, On Wed, Jan 5, 2022 at 10:18 AM Gary Bisson wrote: > > Since commit f7ac30b042d, the pin muxing for mmc was removed from the > board file to be managed by DM_MMC which requires PINCTRL to work. It > made the change for sabrelite but nitrogen configs were forgotten. > > Signed-off-by: Gary Bisson Reviewed-by: Fabio Estevam Since it is a bug fix, it would be nice to get included in the 2022.01 release.
[PATCH] nitrogen6x: add missing pinctrl to fix mmc
Since commit f7ac30b042d, the pin muxing for mmc was removed from the board file to be managed by DM_MMC which requires PINCTRL to work. It made the change for sabrelite but nitrogen configs were forgotten. Signed-off-by: Gary Bisson --- configs/nitrogen6dl2g_defconfig | 2 ++ configs/nitrogen6dl_defconfig | 2 ++ configs/nitrogen6q2g_defconfig | 2 ++ configs/nitrogen6q_defconfig| 2 ++ configs/nitrogen6s1g_defconfig | 2 ++ configs/nitrogen6s_defconfig| 2 ++ 6 files changed, 12 insertions(+) diff --git a/configs/nitrogen6dl2g_defconfig b/configs/nitrogen6dl2g_defconfig index 593a43e5e79..20c5d302577 100644 --- a/configs/nitrogen6dl2g_defconfig +++ b/configs/nitrogen6dl2g_defconfig @@ -68,6 +68,8 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/nitrogen6dl_defconfig b/configs/nitrogen6dl_defconfig index 4bcc6756801..796bd66bc23 100644 --- a/configs/nitrogen6dl_defconfig +++ b/configs/nitrogen6dl_defconfig @@ -68,6 +68,8 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/nitrogen6q2g_defconfig b/configs/nitrogen6q2g_defconfig index 76fc53d5154..b42220db064 100644 --- a/configs/nitrogen6q2g_defconfig +++ b/configs/nitrogen6q2g_defconfig @@ -70,6 +70,8 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/nitrogen6q_defconfig b/configs/nitrogen6q_defconfig index fca3e5f5311..cc085594967 100644 --- a/configs/nitrogen6q_defconfig +++ b/configs/nitrogen6q_defconfig @@ -70,6 +70,8 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/nitrogen6s1g_defconfig b/configs/nitrogen6s1g_defconfig index 8b720b0d600..17133c5cd60 100644 --- a/configs/nitrogen6s1g_defconfig +++ b/configs/nitrogen6s1g_defconfig @@ -68,6 +68,8 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y diff --git a/configs/nitrogen6s_defconfig b/configs/nitrogen6s_defconfig index a9d239e9be9..242580e3e9f 100644 --- a/configs/nitrogen6s_defconfig +++ b/configs/nitrogen6s_defconfig @@ -68,6 +68,8 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_FEC_MXC=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_MXC_UART=y CONFIG_SPI=y CONFIG_DM_SPI=y -- 2.34.1
Re: mkimage_fit_atf.sh: not found
On Tue, Jan 04, 2022 at 07:54:38PM -0300, Fabio Estevam wrote: > HI Tim, > > On Tue, Jan 4, 2022 at 7:48 PM Tim Harvey wrote: > > > > Stefano and Fabio, > > > > I'm seeing the imx8mm_venice_defconfig target failing to build on > > master due to mkimage_fit_atf.sh not found: > > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \ > > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb > > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb > > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb > > arch/arm/dts/imx8mm-venice-gw7901.dtb > > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its > > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found > > > > As far as I can tell the other boards that are still using > > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig, > > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc). > > > > What is the state of the binman conversion? I submitted a series to > > convert my boards to binman and it has just been sitting without any > > response for months now [1]. > > > > I'm not sure when the above breakage occurred but the conversion to > > binman resolves it and other things. > > > > Please let me know what you expect me to do to resolve this as there > > is a release pending. > > > > Best regards, > > > > Tim > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-thar...@gateworks.com/ > > Stefano is on vacation. Tom, would you mind picking Tim's series? Looking at the thread, there's a few pre-requisite patches? And is this also one of the "switch to binman" patches that then fails in CI? Thanks. -- Tom signature.asc Description: PGP signature
[RFC Patch v3] binman: add support for creating dummy files for external blobs
While converting to binman for an imx8mq board, it has been found that
building in the u-boot CI fails. This is because an imx8mq requires an
external binary (signed_hdmi_imx8m.bin). If this file cannot be found
mkimage fails.
To be able to build this board in the u-boot CI a binman option
(--fake-ext-blobs) is introduced that can be switched on via the u-boot
makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are
created.
Signed-off-by: Heiko Thiery
---
v3:
- add CheckFakedBlobs() and print a list of faked files at the end
- add unittest
v2:
- pass allow_fake_blobs to ProcessImage()
- set AllowAllowFakeBlob() to images/entries
- create fake blob in Entry_blot.ObtainContents() when file is missing and
creation is allowed
still missing:
- unittest
- option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment
variable. With that we could simply set this env variable in the CI
(gitlab-ci.yml) with adding support to buildman.
Makefile| 1 +
tools/binman/cmdline.py | 2 ++
tools/binman/control.py | 26 +++---
tools/binman/entry.py | 23 +++
tools/binman/etype/blob.py | 18 ++
tools/binman/etype/blob_ext.py | 8
tools/binman/etype/mkimage.py | 20
tools/binman/etype/section.py | 20
tools/binman/ftest.py | 13 -
tools/binman/test/203_fake_blob.dts | 14 ++
10 files changed, 137 insertions(+), 8 deletions(-)
create mode 100644 tools/binman/test/203_fake_blob.dts
diff --git a/Makefile b/Makefile
index ae9bfab91a..63d286a4c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1315,6 +1315,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
-a tpl-dtb=$(CONFIG_TPL_OF_REAL) \
+ $(if $(BINMAN_FAKE_EXT_BLOBS),--fake-ext-blobs) \
$(BINMAN_$(@F))
OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index e73ff78095..700e5a29a5 100644
--- a/tools/binman/cmdline.py
+++ b/tools/binman/cmdline.py
@@ -52,6 +52,8 @@ controlled by a description in the board device tree.'''
help='Configuration file (.dtb) to use')
build_parser.add_argument('--fake-dtb', action='store_true',
help='Use fake device tree contents (for testing only)')
+build_parser.add_argument('--fake-ext-blobs', action='store_true',
+help='Create fake ext blobs with dummy content (for testing only)')
build_parser.add_argument('-i', '--image', type=str, action='append',
help='Image filename to build (if not specified, build all)')
build_parser.add_argument('-I', '--indir', action='append',
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 304fc70f56..ec0905602e 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -479,7 +479,8 @@ def PrepareImagesAndDtbs(dtb_fname, select_images,
update_fdt, use_expanded):
def ProcessImage(image, update_fdt, write_map, get_contents=True,
- allow_resize=True, allow_missing=False):
+ allow_resize=True, allow_missing=False,
+ allow_fake_blobs=False):
"""Perform all steps for this image, including checking and # writing it.
This means that errors found with a later image will be reported after
@@ -495,12 +496,15 @@ def ProcessImage(image, update_fdt, write_map,
get_contents=True,
allow_resize: True to allow entries to change size (this does a re-pack
of the entries), False to raise an exception
allow_missing: Allow blob_ext objects to be missing
+allow_fake_blobs: Allow blob_ext objects to be faked with dummy files
Returns:
-True if one or more external blobs are missing, False if all are
present
+True if one or more external blobs are missing or faked,
+False if all are present
"""
if get_contents:
image.SetAllowMissing(allow_missing)
+image.SetAllowFakeBlob(allow_fake_blobs)
image.GetEntryContents()
image.GetEntryOffsets()
@@ -549,7 +553,13 @@ def ProcessImage(image, update_fdt, write_map,
get_contents=True,
tout.Warning("Image '%s' is missing external blobs and is
non-functional: %s" %
(image.name, ' '.join([e.name for e in missing_list])))
_ShowHelpForMissingBlobs(missing_list)
-return bool(missing_list)
+faked_blob_list = []
+image.CheckFakedBlobs(faked_blob_list)
+if faked_blob_list:
+tout.Warning("Image '%s:%s' has faked external blobs and is
non-functional: %s" %
+ (image.name, image.image_name,
+ '
Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
On 1/5/22 07:14, Andre Przywara wrote: On Wed, 05 Jan 2022 19:36:29 +0800 Icenowy Zheng wrote: Hi Jesse, 在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道： This patch set aims to add suport for the SUNIV and F1C100s. Suport has been in linux for a while now, but not in u-boot. This patchset contains: - CPU specific initialization code - SUNIV dram driver - SUNIV clock driver adaption - SUNIV gpio driver adaption - SUNIV uart driver adaption - F1C100s basic support I am hoping to get Icenowy's patches in as it seems she hasnt submitted in a while. The only edits I made to her code is rebasing it against ML and changing some formating. I also re-grouped her commits. I got too lazy to send it (because I think F1C100s is just too weak)... I am wondering if the dram driver should be moved into device drivers rather than in mach-sunxi. I am also wondering if it is okay to submit some one elses code, and if so how should I do so. As you are keeping my SoB and adding yours, it's totally okay. Thanks Icenowy for confirming! Jesse: yes, it's perfectly fine to send patches from someone else, as long as you keep the authorship, their SoB, and add your's. Typical reasons are lack of time or interest from the original author. But it's customary to ask the author first I did but it must have gotten lost in the cosmos. , and care should be taken when changing patches, as this might not be in the interest of the original author (and they are the ones who will get blamed for bugs). Also please mark the series either as a Resend or as a v2. So with Icenowy's confirmation above I consider this fine. But what was actually holding back this series was lack of review, testing and/or interest. Well the price of the SOC has gained it some popularity, aswell as a couple forum posts. Similar to Icenowy my personal interest in crufty old cores is somewhat limited, so this wasn't very high on my priority list. It is very slow but its a good challenge. So given that there is apparently some interest now: Can you confirm that you have reviewed the series, or at least tested this? I have tested this yes. I would be interested to know if a second pair of eyes had a look, and to what extent. I'm Sending giulio.benetti@ some boards I made he will also test. I'm sure many other people will be willing to test aswell. I don't have any hardware, so would need to rely on others to make sure this code is somewhat sane. I can send you one of my many boards :) And it basically looks like a v2 of Icenowy's series, so can you give a Changelog of the differences? I skimmed over her original series back then, so I would be interested in what makes this version special. It passes checkpatch on the latest. Cheers, Andre Thanks for cleaning up these patches! ;-) NP! I took https://github.com/Lichee-Pi/u-boot/tree/nano-v2018.01 re-based it against mainline and fixed formatting in a few files. I also removed the spi-flash driver as it was causing issues and we can boot from sdcard for now. there are some things I did to make the old code compatible with new code but mostly preprocessor and configs. For the dram driver I had to change a bit but none of the logic, i am worried that i may have to move it to /drivers. Do you want a more comprehensive list of changes?
Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
On Wed, 05 Jan 2022 19:36:29 +0800 Icenowy Zheng wrote: Hi Jesse, > 在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道： > > This patch set aims to add suport for the SUNIV and F1C100s. > > Suport has been in linux for a while now, but not in u-boot. > > > > This patchset contains: > > - CPU specific initialization code > > - SUNIV dram driver > > - SUNIV clock driver adaption > > - SUNIV gpio driver adaption > > - SUNIV uart driver adaption > > - F1C100s basic support > > > > I am hoping to get Icenowy's patches in as it seems she hasnt > > submitted > > in a while. The only edits I made to her code is rebasing it against > > ML > > and changing some formating. I also re-grouped her commits. > > I got too lazy to send it (because I think F1C100s is just too weak)... > > > > > I am wondering if the dram driver should be moved into device drivers > > rather than in mach-sunxi. > > I am also wondering if it is okay to submit some one elses code, > > and if so how should I do so. > > As you are keeping my SoB and adding yours, it's totally okay. Thanks Icenowy for confirming! Jesse: yes, it's perfectly fine to send patches from someone else, as long as you keep the authorship, their SoB, and add your's. Typical reasons are lack of time or interest from the original author. But it's customary to ask the author first, and care should be taken when changing patches, as this might not be in the interest of the original author (and they are the ones who will get blamed for bugs). Also please mark the series either as a Resend or as a v2. So with Icenowy's confirmation above I consider this fine. But what was actually holding back this series was lack of review, testing and/or interest. Similar to Icenowy my personal interest in crufty old cores is somewhat limited, so this wasn't very high on my priority list. So given that there is apparently some interest now: Can you confirm that you have reviewed the series, or at least tested this? I would be interested to know if a second pair of eyes had a look, and to what extent. I don't have any hardware, so would need to rely on others to make sure this code is somewhat sane. And it basically looks like a v2 of Icenowy's series, so can you give a Changelog of the differences? I skimmed over her original series back then, so I would be interested in what makes this version special. Cheers, Andre > Thanks for cleaning up these patches! ;-) > > > > > Icenowy Zheng (11): > > arm: arm926ej-s: start.S: port save_boot_params support from armv7 > > code > > arm: arm926ej-s: add sunxi code > > dt-bindings: clock: Add initial suniv headers > > dt-bindings: reset: Add initial suniv headers > > ARM: sunxi: Add support for F1C100s > > sunxi: Add F1C100s DRAM initial support > > sunxi: board: Add support for SUNIV > > configs: sunxi: Add common SUNIV header > > sunxi: Add support for SUNIV architecture > > ARM: dts: suniv: Add device tree files for F1C100s > > configs: sunxi: Add support for Lichee Pi Nano > > > > arch/arm/cpu/arm926ejs/Makefile | 1 + > > arch/arm/cpu/arm926ejs/start.S | 19 + > > arch/arm/cpu/arm926ejs/sunxi/Makefile | 15 + > > arch/arm/cpu/arm926ejs/sunxi/config.mk | 6 + > > arch/arm/cpu/arm926ejs/sunxi/fel_utils.S | 37 ++ > > arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S | 67 +++ > > arch/arm/cpu/arm926ejs/sunxi/start.c | 1 + > > arch/arm/cpu/arm926ejs/sunxi/timer.c | 114 + > > arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds | 62 +++ > > arch/arm/dts/Makefile | 2 + > > arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 64 +++ > > arch/arm/dts/suniv-f1c100s.dtsi | 6 + > > arch/arm/dts/suniv.dtsi | 224 ++ > > arch/arm/include/asm/arch-sunxi/clock.h | 2 +- > > arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 25 ++ > > arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 + > > arch/arm/include/asm/arch-sunxi/dram.h | 2 + > > arch/arm/include/asm/arch-sunxi/dram_suniv.h | 46 ++ > > arch/arm/include/asm/arch-sunxi/gpio.h | 1 + > > arch/arm/mach-sunxi/Kconfig | 16 +- > > arch/arm/mach-sunxi/Makefile | 2 + > > arch/arm/mach-sunxi/board.c | 31 +- > > arch/arm/mach-sunxi/clock.c | 3 +- > > arch/arm/mach-sunxi/clock_sun6i.c | 46 +- > > arch/arm/mach-sunxi/cpu_info.c | 2 + > > arch/arm/mach-sunxi/dram_helpers.c | 4 + > > arch/arm/mach-sunxi/dram_suniv.c | 420 > > ++ > > board/sunxi/board.c | 4 +- > > configs/licheepi_nano_defconfig | 13 + > > configs/licheepi_nano_spiflash_defconfig | 25 ++ > > include/configs/suniv.h | 14 + > > include/configs/sunxi-common.h | 67 ++- > >
Re: [PATCH v2 07/10] dts: dra7-ipu-common-early-boot.dtsi: Add all the ipu early boot related nodes
Hi Tom, On 11/10/2021 20:59, Tom Rini wrote: On Thu, Sep 30, 2021 at 06:21:08PM +0200, Amjad Ouled-Ameur wrote: From: Keerthy Add all the ipu early boot related nodes Signed-off-by: Keerthy Signed-off-by: Amjad Ouled-Ameur --- (no changes since v1) MAINTAINERS | 1 + arch/arm/dts/dra7-ipu-common-early-boot.dtsi | 113 +++ 2 files changed, 114 insertions(+) create mode 100644 arch/arm/dts/dra7-ipu-common-early-boot.dtsi This causes my J6 Eco board: CPU : DRA752-GP ES1.1 Model: TI DRA742 Board: DRA74x EVM REV G.0 to stop booting in SPL with no output. Thank you for reporting the issue. After debugging the j6eco board, I realized that board stops booting in SPL when new nodes with "u-boot,dm-spl;"property are added to the DTS. The issue seems to be unrelated to this patchset but rather to a SPL's DTS limitation on j6eco. I am currently looking into SPL's linker file and load addresses to understand better why SPL breaks. Regards, Amjad
Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道： > This patch set aims to add suport for the SUNIV and F1C100s. > Suport has been in linux for a while now, but not in u-boot. > > This patchset contains: > - CPU specific initialization code > - SUNIV dram driver > - SUNIV clock driver adaption > - SUNIV gpio driver adaption > - SUNIV uart driver adaption > - F1C100s basic support > > I am hoping to get Icenowy's patches in as it seems she hasnt > submitted > in a while. The only edits I made to her code is rebasing it against > ML > and changing some formating. I also re-grouped her commits. I got too lazy to send it (because I think F1C100s is just too weak)... > > I am wondering if the dram driver should be moved into device drivers > rather than in mach-sunxi. > I am also wondering if it is okay to submit some one elses code, > and if so how should I do so. As you are keeping my SoB and adding yours, it's totally okay. Thanks for cleaning up these patches! ;-) > > Icenowy Zheng (11): > arm: arm926ej-s: start.S: port save_boot_params support from armv7 > code > arm: arm926ej-s: add sunxi code > dt-bindings: clock: Add initial suniv headers > dt-bindings: reset: Add initial suniv headers > ARM: sunxi: Add support for F1C100s > sunxi: Add F1C100s DRAM initial support > sunxi: board: Add support for SUNIV > configs: sunxi: Add common SUNIV header > sunxi: Add support for SUNIV architecture > ARM: dts: suniv: Add device tree files for F1C100s > configs: sunxi: Add support for Lichee Pi Nano > > arch/arm/cpu/arm926ejs/Makefile | 1 + > arch/arm/cpu/arm926ejs/start.S | 19 + > arch/arm/cpu/arm926ejs/sunxi/Makefile | 15 + > arch/arm/cpu/arm926ejs/sunxi/config.mk | 6 + > arch/arm/cpu/arm926ejs/sunxi/fel_utils.S | 37 ++ > arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S | 67 +++ > arch/arm/cpu/arm926ejs/sunxi/start.c | 1 + > arch/arm/cpu/arm926ejs/sunxi/timer.c | 114 + > arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds | 62 +++ > arch/arm/dts/Makefile | 2 + > arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 64 +++ > arch/arm/dts/suniv-f1c100s.dtsi | 6 + > arch/arm/dts/suniv.dtsi | 224 ++ > arch/arm/include/asm/arch-sunxi/clock.h | 2 +- > arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 25 ++ > arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 + > arch/arm/include/asm/arch-sunxi/dram.h | 2 + > arch/arm/include/asm/arch-sunxi/dram_suniv.h | 46 ++ > arch/arm/include/asm/arch-sunxi/gpio.h | 1 + > arch/arm/mach-sunxi/Kconfig | 16 +- > arch/arm/mach-sunxi/Makefile | 2 + > arch/arm/mach-sunxi/board.c | 31 +- > arch/arm/mach-sunxi/clock.c | 3 +- > arch/arm/mach-sunxi/clock_sun6i.c | 46 +- > arch/arm/mach-sunxi/cpu_info.c | 2 + > arch/arm/mach-sunxi/dram_helpers.c | 4 + > arch/arm/mach-sunxi/dram_suniv.c | 420 > ++ > board/sunxi/board.c | 4 +- > configs/licheepi_nano_defconfig | 13 + > configs/licheepi_nano_spiflash_defconfig | 25 ++ > include/configs/suniv.h | 14 + > include/configs/sunxi-common.h | 67 ++- > include/dt-bindings/clock/suniv-ccu.h | 68 +++ > include/dt-bindings/reset/suniv-ccu.h | 36 ++ > 34 files changed, 1424 insertions(+), 29 deletions(-) > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/Makefile > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/config.mk > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/fel_utils.S > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/start.c > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/timer.c > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds > create mode 100644 arch/arm/dts/suniv-f1c100s-licheepi-nano.dts > create mode 100644 arch/arm/dts/suniv-f1c100s.dtsi > create mode 100644 arch/arm/dts/suniv.dtsi > create mode 100644 arch/arm/include/asm/arch-sunxi/dram_suniv.h > create mode 100644 arch/arm/mach-sunxi/dram_suniv.c > create mode 100644 configs/licheepi_nano_defconfig > create mode 100644 configs/licheepi_nano_spiflash_defconfig > create mode 100644 include/configs/suniv.h > create mode 100644 include/dt-bindings/clock/suniv-ccu.h > create mode 100644 include/dt-bindings/reset/suniv-ccu.h >
RE: mkimage_fit_atf.sh: not found
Hello Tim,
> -Original Message-
> From: U-Boot On Behalf Of Tim Harvey
> Sent: Tuesday, January 4, 2022 11:48 PM
> To: u-boot ; Stefano Babic ; Fabio
> Estevam
>
> Cc: Schrempf Frieder ; Adam Ford
> ; Marcel Ziswiler ; Jagan Teki
>
> Subject: mkimage_fit_atf.sh: not found
>
> Stefano and Fabio,
>
> I'm seeing the imx8mm_venice_defconfig target failing to build on
> master due to mkimage_fit_atf.sh not found:
> ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> arch/arm/dts/imx8mm-venice-gw7901.dtb
> arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
>
This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator
script")
> As far as I can tell the other boards that are still using
> SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
imx8mq_evk is already converted and I've sent a patch for it, see [1].
>
> What is the state of the binman conversion? I submitted a series to
> convert my boards to binman and it has just been sitting without any
> response for months now [1].
I believe that the reason for your series sitting in the queue is the same as
for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
>
> I'm not sure when the above breakage occurred but the conversion to
> binman resolves it and other things.
>
> Please let me know what you expect me to do to resolve this as there
> is a release pending.
>
> Best regards,
>
> Tim
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-
> thar...@gateworks.com/
-- andrey
Link: [1]:
http://patchwork.ozlabs.org/project/uboot/patch/20211203161802.12699-1-andrey.zhizhi...@leica-geosystems.com/
Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c
Am 2022-01-05 11:37, schrieb eugen.hris...@microchip.com:
On 1/5/22 12:04 PM, Michael Walle wrote:
Hi,
Add compatible and data platform struct for sama7g5 SoC.
Signed-off-by: Eugen Hristev
---
drivers/i2c/at91_i2c.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index 6b4c0e4804..400a3786ca 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -305,6 +305,11 @@ static const struct at91_i2c_pdata
sama5d2_config = {
.clk_offset = 3,
};
+static const struct at91_i2c_pdata sama7g5_config = {
+ .clk_max_div = 7,
+ .clk_offset = 3,
+};
+
static const struct udevice_id at91_i2c_ids[] = {
{ .compatible = "atmel,at91rm9200-i2c", .data =
(long)_config },
{ .compatible = "atmel,at91sam9260-i2c", .data =
(long)_config },
@@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
{ .compatible = "atmel,at91sam9x5-i2c", .data =
(long)_config },
{ .compatible = "atmel,sama5d4-i2c", .data = (long)_config
},
{ .compatible = "atmel,sama5d2-i2c", .data = (long)_config
},
+{ .compatible = "microchip,sama7g5-i2c", .data =
(long)_config },
I see that this compatible string is is also used in the linux
device tree, but there is no dt binding for it in linux. Could you
add it, so the binding is approved by Rob?
I can, for sure, but the current binding format is txt. I am not sure
if
we have to convert to yaml first, in which case it would be a little
more difficult than just adding a new compatible string.
The current DT node in Linux is also compatible with sam9x60, and this
string is already in the Linux binding file.
I could add the sam9x60 compatible instead, and it will still work, as
9x60 type of i2c is the same as in sama7g5.
You think this option would be better for now ?
It's at least better than adding an undocumented string. But TBH,
this looks like "what can I do to avoid converting the dt binding
to yaml". Which eventually has to be done anyway, so now might be
a good opportunity for that :)
But looking at sama7g5_config above again, will that also be the
correct values for the generic sam9x60?
-michael
Re: [PATCH] lib: Kconfig: fix PHANDLE_CHECK_SEQ position outside of menu
Hi Eugen,
On 04/01/22 9:50 pm, Eugen Hristev wrote:
> CONFIG_PHANDLE_CHECK_SEQ is outside of the menu 'Library routines'
> thus it's invisible in menuconfig and cannot be selected.
> Fix this by moving the 'endmenu' after the PHANDLE_CHECK_SEQ definition
>
> Fixes: c589132a1d ("fdt: Use phandle to distinguish DT nodes with same name")
> Signed-off-by: Eugen Hristev
Thank you for fixing this :)
Reviewed-by: Aswath Govindraju
Thanks,
Aswath
> ---
> lib/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 807a4c6ade..652a11a154 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -827,11 +827,11 @@ config LMB_RESERVED_REGIONS
> Define the number of supported reserved regions in the library logical
> memory blocks.
>
> -endmenu
> -
> config PHANDLE_CHECK_SEQ
> bool "Enable phandle check while getting sequence number"
> help
> When there are multiple device tree nodes with same name,
>enable this config option to distinguish them using
> phandles in fdtdec_get_alias_seq() function.
> +
> +endmenu
>
Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c
Hi,
> Add compatible and data platform struct for sama7g5 SoC.
>
> Signed-off-by: Eugen Hristev
> ---
> drivers/i2c/at91_i2c.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
> index 6b4c0e4804..400a3786ca 100644
> --- a/drivers/i2c/at91_i2c.c
> +++ b/drivers/i2c/at91_i2c.c
> @@ -305,6 +305,11 @@ static const struct at91_i2c_pdata sama5d2_config = {
> .clk_offset = 3,
> };
>
> +static const struct at91_i2c_pdata sama7g5_config = {
> + .clk_max_div = 7,
> + .clk_offset = 3,
> +};
> +
> static const struct udevice_id at91_i2c_ids[] = {
> { .compatible = "atmel,at91rm9200-i2c", .data = (long)_config },
> { .compatible = "atmel,at91sam9260-i2c", .data = (long)_config },
> @@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
> { .compatible = "atmel,at91sam9x5-i2c", .data = (long)_config },
> { .compatible = "atmel,sama5d4-i2c", .data = (long)_config },
> { .compatible = "atmel,sama5d2-i2c", .data = (long)_config },
> +{ .compatible = "microchip,sama7g5-i2c", .data = (long)_config },
I see that this compatible string is is also used in the linux
device tree, but there is no dt binding for it in linux. Could you
add it, so the binding is approved by Rob?
-michael
[PATCH u-boot-pci] pci: iproc: Set all 24 bits of PCI class code
Register 0x43c in its low 24 bits contains PCI class code. Update code to set all 24 bits of PCI class code and not only upper 16 bits of PCI class code. Use standard U-Boot macro (PCI_CLASS_BRIDGE_PCI << 8) for constructing all 24-bits of PCI class for PCI bridge Normal decode. Signed-off-by: Pali Rohár --- Roman helped me with this change and confirmed that class code is stored really in bits [23:0] of custom register 0x43c (normally class code is stored in bits [31:8] of pci register 0x08). --- drivers/pci/pcie_iproc.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/pci/pcie_iproc.c b/drivers/pci/pcie_iproc.c index be03dcbd97c0..fe68e417ae80 100644 --- a/drivers/pci/pcie_iproc.c +++ b/drivers/pci/pcie_iproc.c @@ -1127,15 +1127,14 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie) u32 link_status, class; pcie->link_is_active = false; - /* force class to PCI_CLASS_BRIDGE_PCI (0x0604) */ + /* force class to PCI bridge Normal decode (0x060400) */ #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c -#define PCI_CLASS_BRIDGE_MASK 0x00 -#define PCI_CLASS_BRIDGE_SHIFT 8 +#define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xff iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET, 4, ); - class &= ~PCI_CLASS_BRIDGE_MASK; - class |= (PCI_CLASS_BRIDGE_PCI << PCI_CLASS_BRIDGE_SHIFT); + class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK; + class |= (PCI_CLASS_BRIDGE_PCI << 8); iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET, 4, class); -- 2.20.1
Re: [PATCH] net: gem: Reduce timeout of mdio phy idle status check
čt 18. 11. 2021 v 13:05 odesílatel Michal Simek napsal: > > From: Ashok Reddy Soma > > Timeout for checking mdio phy idle status is 20seconds. In case of errors > this timeout will be too much. Reduce it to 100ms. > > Signed-off-by: Ashok Reddy Soma > Signed-off-by: Michal Simek > --- > > drivers/net/zynq_gem.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c > index c309c3c95499..033021f1cbfc 100644 > --- a/drivers/net/zynq_gem.c > +++ b/drivers/net/zynq_gem.c > @@ -110,6 +110,8 @@ > > #define ZYNQ_GEM_DCFG_DBG6_DMA_64B BIT(23) > > +#define MDIO_IDLE_TIMEOUT_MS 100 > + > /* Use MII register 1 (MII status register) to detect PHY */ > #define PHY_DETECT_REG 1 > > @@ -225,7 +227,7 @@ static int phy_setup_op(struct zynq_gem_priv *priv, u32 > phy_addr, u32 regnum, > int err; > > err = wait_for_bit_le32(>nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK, > - true, 2, false); > + true, MDIO_IDLE_TIMEOUT_MS, false); > if (err) > return err; > > @@ -238,7 +240,7 @@ static int phy_setup_op(struct zynq_gem_priv *priv, u32 > phy_addr, u32 regnum, > writel(mgtcr, >phymntnc); > > err = wait_for_bit_le32(>nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK, > - true, 2, false); > + true, MDIO_IDLE_TIMEOUT_MS, false); > if (err) > return err; > > -- > 2.33.1 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v3] net: zynq: Add support for PHY configuration in SGMII mode
st 15. 12. 2021 v 11:00 odesílatel Michal Simek
napsal:
>
> SGMII configuration depends on proper GT setting that's why when node has
> phys property call PSGTR driver to configure it properly.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v3:
> - Separate phy init from phy power on (IP reset has to be between)
>
> Changes in v2:
> - Handle also cases where phy reference doesn't exist which means
> that u-boot doesn't need to configure it (configured via psu_init for
> example)
> - Error out where reference exists but driver is not compiled in - reported
> by Sean
>
> drivers/net/zynq_gem.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 5cbe8d28304b..b751d28e611f 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -715,6 +716,19 @@ static int zynq_gem_probe(struct udevice *dev)
> void *bd_space;
> struct zynq_gem_priv *priv = dev_get_priv(dev);
> int ret;
> + struct phy phy;
> +
> + if (priv->interface == PHY_INTERFACE_MODE_SGMII) {
> + ret = generic_phy_get_by_index(dev, 0, );
> + if (!ret) {
> + ret = generic_phy_init();
> + if (ret)
> + return ret;
> + } else if (ret != -ENOENT) {
> + debug("could not get phy (err %d)\n", ret);
> + return ret;
> + }
> + }
>
> ret = zynq_gem_reset_init(dev);
> if (ret)
> @@ -771,6 +785,12 @@ static int zynq_gem_probe(struct udevice *dev)
> if (ret)
> goto err3;
>
> + if (priv->interface == PHY_INTERFACE_MODE_SGMII && phy.dev) {
> + ret = generic_phy_power_on();
> + if (ret)
> + return ret;
> + }
> +
> return ret;
>
> err3:
> --
> 2.34.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2] net: zynq: Add support for GEM reset
po 6. 12. 2021 v 16:25 odesílatel Michal Simek napsal:
>
> Perform reset before core initialization.
> Standard flow which close to 99% users are using getting all IPs out of
> reset that there is no need to reset IP again. This is because of all low
> level initialization is done in previous bootloader stage.
> In SOM case these IPs are not touched by previous bootloader stage that's
> why reset needs to be called before IP is accessed to make sure that it is
> in correct state.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Update commit message
>
> drivers/net/zynq_gem.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 91957757727d..5cbe8d28304b 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -217,6 +218,7 @@ struct zynq_gem_priv {
> bool int_pcs;
> bool dma_64bit;
> u32 clk_en_info;
> + struct reset_ctl_bulk resets;
> };
>
> static int phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum,
> @@ -688,12 +690,36 @@ static int zynq_gem_miiphy_write(struct mii_dev *bus,
> int addr, int devad,
> return phywrite(priv, addr, reg, value);
> }
>
> +static int zynq_gem_reset_init(struct udevice *dev)
> +{
> + struct zynq_gem_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = reset_get_bulk(dev, >resets);
> + if (ret == -ENOTSUPP || ret == -ENOENT)
> + return 0;
> + else if (ret)
> + return ret;
> +
> + ret = reset_deassert_bulk(>resets);
> + if (ret) {
> + reset_release_bulk(>resets);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int zynq_gem_probe(struct udevice *dev)
> {
> void *bd_space;
> struct zynq_gem_priv *priv = dev_get_priv(dev);
> int ret;
>
> + ret = zynq_gem_reset_init(dev);
> + if (ret)
> + return ret;
> +
> /* Align rxbuffers to ARCH_DMA_MINALIGN */
> priv->rxbuffers = memalign(ARCH_DMA_MINALIGN, RX_BUF * PKTSIZE_ALIGN);
> if (!priv->rxbuffers)
> --
> 2.33.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2] net: zynq: Add support for mdio bus address decoding
po 6. 12. 2021 v 14:53 odesílatel Michal Simek napsal:
>
> Xilinx DTS files are using two way how to describe ethernet phy.
>
> The first (already supported) has phy as subnode of gem node.
> eth {
> phy-handle = <>;
> phy0: ethernet-phy@21 {
> ...
> };
> };
>
> The second has mdio subnode (with mdio name) which has phy subnode. This
> structure allow hadling MDIO reset signal (based on Linux mdio.yaml)
> eth {
> phy-handle = <>;
> mdio {
> phy0: ethernet-phy@21 {
> ...
> };
> };
> };
>
> This patch adds support for the second case where mdio subnode
> is found driver will look at its parent to find out which gem is handling
> MDIO bus.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - update commit message
>
> drivers/net/zynq_gem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 3e227725022d..fece077066df 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -846,6 +846,9 @@ static int zynq_gem_of_to_plat(struct udevice *dev)
> SPEED_1000);
>
> parent = ofnode_get_parent(phandle_args.node);
> + if (ofnode_name_eq(parent, "mdio"))
> + parent = ofnode_get_parent(parent);
> +
> addr = ofnode_get_addr(parent);
> if (addr != FDT_ADDR_T_NONE) {
> debug("MDIO bus not found %s\n", dev->name);
> --
> 2.33.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] dt-bindings: versal: Add new PM_DEV_I2C_PMC macro
út 30. 11. 2021 v 13:57 odesílatel Michal Simek napsal: > > From: Sandeep Gundlupet Raju > > Add new macro for PMC I2C power domain. > > Signed-off-by: Sandeep Gundlupet Raju > Signed-off-by: Michal Simek > --- > > include/dt-bindings/power/xlnx-versal-power.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/dt-bindings/power/xlnx-versal-power.h > b/include/dt-bindings/power/xlnx-versal-power.h > index 1b75175edce5..4a727754ad02 100644 > --- a/include/dt-bindings/power/xlnx-versal-power.h > +++ b/include/dt-bindings/power/xlnx-versal-power.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > /* > - * Copyright (C) 2019 - 2020 Xilinx, Inc. > + * Copyright (C) 2019 - 2021 Xilinx, Inc. > */ > > #ifndef _DT_BINDINGS_VERSAL_POWER_H > @@ -26,6 +26,7 @@ > #define PM_DEV_OSPI(0x1822402aU) > #define PM_DEV_QSPI(0x1822402bU) > #define PM_DEV_GPIO_PMC(0x1822402cU) > +#define PM_DEV_I2C_PMC (0x1822402dU) > #define PM_DEV_SDIO_0 (0x1822402eU) > #define PM_DEV_SDIO_1 (0x1822402fU) > #define PM_DEV_RTC (0x18224034U) > -- > 2.33.1 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] versal: Return ENVL_NOWHERE instead of ENVL_UNKNOWN
st 24. 11. 2021 v 12:16 odesílatel Michal Simek
napsal:
>
> From: T Karthik Reddy
>
> The system fails to boot without any environment location, so return
> ENVL_NOWHERE when there's nowhere to store the environment instead
> of ENVL_UNKNOWN.
>
> The same change was also done by commit 50918d0df5cb ("xilinx: Return
> ENVL_NOWHERE instead of ENVL_UNKNOWN") for zynq and zynqmp.
>
> Signed-off-by: T Karthik Reddy
> Signed-off-by: Michal Simek
> ---
>
> board/xilinx/versal/board.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
> index 03604d730a0b..299e128f7b9d 100644
> --- a/board/xilinx/versal/board.c
> +++ b/board/xilinx/versal/board.c
> @@ -269,13 +269,13 @@ enum env_location env_get_location(enum env_operation
> op, int prio)
> return ENVL_FAT;
> if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
> return ENVL_EXT4;
> - return ENVL_UNKNOWN;
> + return ENVL_NOWHERE;
> case OSPI_MODE:
> case QSPI_MODE_24BIT:
> case QSPI_MODE_32BIT:
> if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
> return ENVL_SPI_FLASH;
> - return ENVL_UNKNOWN;
> + return ENVL_NOWHERE;
> case JTAG_MODE:
> default:
> return ENVL_NOWHERE;
> --
> 2.33.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
On Wed, 5 Jan 2022 11:10:51 +1300 Chris Packham wrote: > Hi Marek, > > On Wed, Jan 5, 2022 at 9:28 AM Marek Behún wrote: > > > > From: Marek Behún > > > > Hello, > > > > continuing my last discussion with Chris [1] about this, could you > > please test this change? (For Chris, mainly on your x530, since last > > time you said it hanged your board in SPL.) > > I still get a hang after "Returning to BootROM (return address > 0x05c4)... " (after the DDR training). Hi Chris, would it be possible for me to connect to a computer to which the x530 is connected via UART so that I can debug it? Could you prepare such an environment? It would also need a mechanism to reset the board remotely somehow. I prepared a similar remote debugging environment for Marvell when they were solving some issues for us. If not, then I guess we will just have to send debugging code and results back and forth. Marek
Re: efi bootmenu
On 12/29/21 17:04, Mark Kettenis wrote: From: François Ozog Date: Wed, 29 Dec 2021 14:39:36 +0100 HI Simon On Wed, 29 Dec 2021 at 14:36, Simon Glass wrote: Hi François, On Tue, 28 Dec 2021 at 03:15, François Ozog wrote: Le mar. 28 déc. 2021 à 09:32, Simon Glass a écrit : Hi Masahisa, On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima wrote: Hi Takahiro, On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi wrote: On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote: Hi Heinrich, Ilias, Akashi-san, Ilias and I are now discussing to create efi bootmenu, almost similar to UiApp in EDK2. Why not discuss this topic openly in ML? Yes, I included U-Boot ML.(Sorry, I should include from the the beginning.) How is this feature related to Simon's bootmethod proposal? If I correctly understand Simon's bootmethod proposal, the difference is that efi bootmenu only targets to implement the menu based UI to select/edit/add/delete "Boot" and "BootOrder". Yes, EFI would be one of the bootmethods. Others would be U-Boot scripts, Chrome OS, Android, etc. plus people might add custom ones. Also I am thinking that (perhaps) the bootdev part of the standard boot thing could be used to provide boot devices for EFI. If we do have a bootmenu, I wonder if it could be generic, instead of tied to EFI? EFI Boot specify an array of device paths and boot options. A device path is quite a unique construct despite its name. A device path is itself an array of elements, some elements can be a file path , configuration information, or diverse metadata. An example of configuration information element is UART baud,stop bits, parity along with terminal (vt100, ansi…). Another device path element can cover IP address, transport information (tcp, UDP and port number). The traditional EFI boot menu is quite crude and does not expose the full capabilities of Boot (lacks edit of boot options for instance!). In the long run we will need to leverage all the Boot capabilities and those are EFI specific while being OS agnostic. The other U-Boot boot methods (Android , ChromeOS…) are OS specific. The goals are thus very different and making a generic approach seems quite compromised. If there is a fully generic framework available in the future, it may be possible to integrate the EFI boot menu. But at least there is a need to solve, code first, the EFI complexities to fuel the generic architecture discussion. Despite this, the goal of standard boot is to encompass all of this within U-Boot. I believe that it will be successful, even if the path at present is a bit unclear. So I would suggest we work bottom up. Starting by making EFI menu work, then extend it more generic or integrated it in a framework. Starting top down would require a long architecture process based on not enough known problems to solve for each environment. Well, whatever you do, please build something that works well with a serial console. EDK2 makes assumptions the terminal emulation on the other side, insists on changing the colors to white on black and relies on function keys that need escape sequences. And escape sequences over serial are always iffy since they depend on timing for their interpretation. You can do better for U-Boot. We already use escape sequences for the U-Boot console and you can't avoid them for navigation keys. What operating system are you using that that does not provide a serial terminal emulation which understands ECMA-48? Also, keep in mind that BootOrder and Boot only really work if there is runtime EFI variable support. So the boot menu should include options to select a device to boot from and use the default (removable media) bootloader from the ESP on that device. And a way to make this selection stick! Pretty much all x86 EFI implementations provide functionality like that. I suppose this could be done by populating the EFI variable store with appropriate Boot variables and manipulating BootOrder. But that would make it hard to generalize the boot menu to non-EFI boot flows. We are talking here about an EFI boot menu. Why do you mention non-EFI? Best regards Heinrich
Re: [PATCH u-boot-marvell] board: gdsys: Drop Dirk Eibach from MAINTAINERS
On 1/4/22 16:14, Marek Behún wrote: From: Marek Behún I got an : host mxlb.ispgateway.de[80.67.18.126] said: 554 Sorry, no mailbox here by that name. (in reply to RCPT TO command) when sending e-mail to dirk.eib...@gdsys.cc. Drop Dirk Eibach from MAINTAINERS of board/gdsys/a38x and board/gdsys/mpc8308. The latter would be left maintainerless, add Mario Six (he is also maintainer of the former board). Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan --- board/gdsys/a38x/MAINTAINERS| 1 - board/gdsys/mpc8308/MAINTAINERS | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/board/gdsys/a38x/MAINTAINERS b/board/gdsys/a38x/MAINTAINERS index d31e675ddc..6492e79541 100644 --- a/board/gdsys/a38x/MAINTAINERS +++ b/board/gdsys/a38x/MAINTAINERS @@ -1,5 +1,4 @@ A38X BOARD -M: Dirk Eibach M:Mario Six S:Maintained F:board/gdsys/a38x/ diff --git a/board/gdsys/mpc8308/MAINTAINERS b/board/gdsys/mpc8308/MAINTAINERS index dc0b389f73..57faba4695 100644 --- a/board/gdsys/mpc8308/MAINTAINERS +++ b/board/gdsys/mpc8308/MAINTAINERS @@ -1,5 +1,5 @@ MPC8308 BOARD -M: Dirk Eibach +M: Mario Six S:Maintained F:board/gdsys/mpc8308/ F:include/configs/gazerbeam.h Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell] ddr: marvell: a38x: Fix Synchronous vs Asynchronous mode determination
On 1/4/22 15:57, Marek Behún wrote:
From: Marek Behún
Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
2 GHz and DDR at 933 MHz.
Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode") added support for Asynchornous Modes with frequencies other than
933 MHz (but at least 467 MHz), but the code it added to check for
whether Asynchornous Mode should be used is wrong: it checks whether the
frequency setting in board DDR topology map is set to value other than
MV_DDR_FREQ_SAR.
Thus boards which define a specific value, greater than 400 MHz, for DDR
frequency in their board topology (e.g. Turris Omnia defines
MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
commit.
The A38x Functional Specification, section 10.12 DRAM Clocking, says:
In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
in 1:2 or 1:3 CPU to DRAM frequency ratios.
Change the check for whether Asynchornous Mode should be used according
to this explanation in Functional Specification.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
A PR was also created for mv-ddr-marvell:
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/35
Please test this. It is possible this commit will fix DDR training
issues, since commit 4c289425752f in mv-ddr-marvell started using
Asynchronous Mode where Synchronous Mode was used previously.
---
drivers/ddr/marvell/a38x/mv_ddr_plat.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index faafc86ea2..7c7bce73a3 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
@@ -167,8 +167,6 @@ static u16 a38x_vco_freq_per_sar_ref_clk_40_mhz[] = {
};
-static u32 async_mode_at_tf;
-
static u32 dq_bit_map_2_phy_pin[] = {
1, 0, 2, 6, 9, 8, 3, 7, /* 0 */
8, 9, 1, 7, 2, 6, 3, 0, /* 1 */
@@ -734,7 +732,8 @@ static int ddr3_tip_a38x_set_divider(u8 dev_num, u32 if_id,
u32 divider = 0;
u32 sar_val, ref_clk_satr;
u32 async_val;
- u32 freq = mv_ddr_freq_get(frequency);
+ u32 cpu_freq;
+ u32 ddr_freq = mv_ddr_freq_get(frequency);
if (if_id != 0) {
DEBUG_TRAINING_ACCESS(DEBUG_LEVEL_ERROR,
@@ -751,11 +750,14 @@ static int ddr3_tip_a38x_set_divider(u8 dev_num, u32
if_id,
ref_clk_satr = reg_read(DEVICE_SAMPLE_AT_RESET2_REG);
if (((ref_clk_satr >> DEVICE_SAMPLE_AT_RESET2_REG_REFCLK_OFFSET) & 0x1)
==
DEVICE_SAMPLE_AT_RESET2_REG_REFCLK_25MHZ)
- divider = a38x_vco_freq_per_sar_ref_clk_25_mhz[sar_val] / freq;
+ cpu_freq = a38x_vco_freq_per_sar_ref_clk_25_mhz[sar_val];
else
- divider = a38x_vco_freq_per_sar_ref_clk_40_mhz[sar_val] / freq;
+ cpu_freq = a38x_vco_freq_per_sar_ref_clk_40_mhz[sar_val];
+
+ divider = cpu_freq / ddr_freq;
- if ((async_mode_at_tf == 1) && (freq > 400)) {
+ if (((cpu_freq % ddr_freq != 0) || (divider != 2 && divider != 3)) &&
+ (ddr_freq > 400)) {
/* Set async mode */
dunit_write(0x20220, 0x1000, 0x1000);
dunit_write(0xe42f4, 0x200, 0x200);
@@ -869,8 +871,6 @@ int ddr3_tip_ext_write(u32 dev_num, u32 if_id, u32 reg_addr,
int mv_ddr_early_init(void)
{
- struct mv_ddr_topology_map *tm = mv_ddr_topology_map_get();
-
/* FIXME: change this configuration per ddr type
* configure a380 and a390 to work with receiver odt timing
* the odt_config is defined:
@@ -882,9 +882,6 @@ int mv_ddr_early_init(void)
mv_ddr_sw_db_init(0, 0);
- if (tm->interface_params[0].memory_freq != MV_DDR_FREQ_SAR)
- async_mode_at_tf = 1;
-
return MV_OK;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v1 5/5] Convert CONFIG_AT91_EFLASH to Kconfig
On 1/4/22 14:24, Patrick Delaunay wrote: This converts the following to Kconfig: CONFIG_AT91_EFLASH Signed-off-by: Patrick Delaunay Reviewed-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan --- arch/arm/mach-at91/Kconfig | 8 configs/ethernut5_defconfig | 2 +- include/configs/ethernut5.h | 1 - scripts/config_whitelist.txt | 1 - 4 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 4448ca1592..00f31045d6 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -302,6 +302,14 @@ config ATMEL_SFR config SYS_SOC default "at91" +config AT91_EFLASH + bool "Support AT91 flash driver" + depends on AT91SAM9XE + select USE_SYS_MAX_FLASH_BANKS + help + Enable the driver for the embedded flash used in the Atmel + AT91SAM9XE devices. + source "board/atmel/at91sam9260ek/Kconfig" source "board/atmel/at91sam9261ek/Kconfig" source "board/atmel/at91sam9263ek/Kconfig" diff --git a/configs/ethernut5_defconfig b/configs/ethernut5_defconfig index 5d98318aab..7a701db0e1 100644 --- a/configs/ethernut5_defconfig +++ b/configs/ethernut5_defconfig @@ -4,6 +4,7 @@ CONFIG_ARCH_CPU_INIT=y CONFIG_ARCH_AT91=y CONFIG_SYS_TEXT_BASE=0x2700 CONFIG_SYS_MALLOC_LEN=0x121000 +CONFIG_AT91_EFLASH=y CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_ETHERNUT5=y CONFIG_NR_DRAM_BANKS=1 @@ -66,7 +67,6 @@ CONFIG_SYS_I2C_SOFT_SLAVE=0 CONFIG_GENERIC_ATMEL_MCI=y CONFIG_MTD=y CONFIG_MTD_NOR_FLASH=y -CONFIG_USE_SYS_MAX_FLASH_BANKS=y CONFIG_MTD_RAW_NAND=y # CONFIG_SYS_NAND_USE_FLASH_BBT is not set CONFIG_NAND_ATMEL=y diff --git a/include/configs/ethernut5.h b/include/configs/ethernut5.h index d72f704636..d88c14ac44 100644 --- a/include/configs/ethernut5.h +++ b/include/configs/ethernut5.h @@ -33,7 +33,6 @@ /* 512kB on-chip NOR flash */ # define CONFIG_SYS_FLASH_BASE0x0020 /* AT91SAM9XE_FLASH_BASE */ -# define CONFIG_AT91_EFLASH # define CONFIG_SYS_MAX_FLASH_SECT32 # define CONFIG_EFLASH_PROTSECTORS1 diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 7726243f22..3a923abf7e 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -18,7 +18,6 @@ CONFIG_AT91SAM9G20EK CONFIG_AT91SAM9G20EK_2MMC CONFIG_AT91SAM9G45_LCD_BASE CONFIG_AT91SAM9M10G45EK -CONFIG_AT91_EFLASH CONFIG_AT91_GPIO_PULLUP CONFIG_AT91_LED CONFIG_AT91_WANTS_COMMON_PHY Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v1 3/5] mtd: cfi: change CONFIG_SYS_MAX_FLASH_BANKS_DETECT as boolean
On 1/4/22 14:23, Patrick Delaunay wrote:
Prepare migration to Kconfig.
CONFIG_SYS_MAX_FLASH_BANKS_DETECT becomes boolean and
CONFIG_SYS_MAX_FLASH_BANKS define the MAX size, also used
for detection when CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
(CFI_MAX_FLASH_BANKS = CONFIG_SYS_MAX_FLASH_BANKS).
CONFIG_SYS_MAX_FLASH_BANKS become mandatory when
CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated.
Signed-off-by: Patrick Delaunay
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v1:
- solve issue in cfi_flash.h, with
CFI_FLASH_BANKS=CONFIG_SYS_MAX_FLASH_BANKS_DETECT
drivers/mtd/cfi_flash.c | 2 +-
include/configs/3c120_devboard.h | 3 ++-
include/configs/adp-ae3xx.h | 4 +---
include/configs/adp-ag101p.h | 2 --
include/configs/ax25-ae350.h | 4 +---
include/configs/bmips_bcm6338.h | 3 ++-
include/configs/bmips_bcm6348.h | 3 ++-
include/configs/bmips_bcm6358.h | 3 ++-
include/configs/bmips_bcm6368.h | 3 ++-
include/configs/boston.h | 4 +++-
include/configs/draak.h | 3 ++-
include/configs/ebisu.h | 3 ++-
include/configs/j721e_evm.h | 3 ++-
include/configs/mccmon6.h| 3 ++-
include/configs/qemu-arm.h | 3 ++-
include/configs/salvator-x.h | 3 ++-
include/configs/ulcb.h | 3 ++-
include/mtd/cfi_flash.h | 10 +-
18 files changed, 35 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 71cefc125f..aae3ea0d1b 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -96,7 +96,7 @@ static u16 cfi_flash_config_reg(int i)
}
#if defined(CONFIG_SYS_MAX_FLASH_BANKS_DETECT)
-int cfi_flash_num_flash_banks = CONFIG_SYS_MAX_FLASH_BANKS_DETECT;
+int cfi_flash_num_flash_banks = CFI_MAX_FLASH_BANKS;
#else
int cfi_flash_num_flash_banks;
#endif
diff --git a/include/configs/3c120_devboard.h b/include/configs/3c120_devboard.h
index f7ad7efb0d..e52fedcf39 100644
--- a/include/configs/3c120_devboard.h
+++ b/include/configs/3c120_devboard.h
@@ -20,7 +20,8 @@
* CFI Flash
*/
#define CONFIG_SYS_CFI_FLASH_STATUS_POLL /* fix amd flash issue */
-#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT 1
+#define CONFIG_SYS_MAX_FLASH_BANKS 1
+#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#define CONFIG_SYS_MAX_FLASH_SECT 512
/*
diff --git a/include/configs/adp-ae3xx.h b/include/configs/adp-ae3xx.h
index 58e8526048..11eff3852d 100644
--- a/include/configs/adp-ae3xx.h
+++ b/include/configs/adp-ae3xx.h
@@ -156,7 +156,7 @@
/* support JEDEC */
#ifdef CONFIG_CFI_FLASH
-#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT 1
+#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#endif
/* Do not use CONFIG_FLASH_CFI_LEGACY to detect on board flash */
@@ -173,9 +173,7 @@
* There are 4 banks supported for this Controller,
* but we have only 1 bank connected to flash on board
*/
-#ifndef CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#define CONFIG_SYS_MAX_FLASH_BANKS1
-#endif
#define CONFIG_SYS_FLASH_BANKS_SIZES {0x400}
/* max number of sectors on one chip */
diff --git a/include/configs/adp-ag101p.h b/include/configs/adp-ag101p.h
index 1022764985..31ef30adc6 100644
--- a/include/configs/adp-ag101p.h
+++ b/include/configs/adp-ag101p.h
@@ -286,9 +286,7 @@
* There are 4 banks supported for this Controller,
* but we have only 1 bank connected to flash on board
*/
-#ifndef CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#define CONFIG_SYS_MAX_FLASH_BANKS1
-#endif
#define CONFIG_SYS_FLASH_BANKS_SIZES {0x400}
/* max number of sectors on one chip */
diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
index 1c3f957d32..2ad0d1589c 100644
--- a/include/configs/ax25-ae350.h
+++ b/include/configs/ax25-ae350.h
@@ -80,7 +80,7 @@
/* support JEDEC */
#ifdef CONFIG_CFI_FLASH
-#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT 1
+#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#endif/* Do not use CONFIG_FLASH_CFI_LEGACY to detect on board flash */
#define PHYS_FLASH_1 0x8800 /* BANK 0 */
#define CONFIG_SYS_FLASH_BASE PHYS_FLASH_1
@@ -95,9 +95,7 @@
* There are 4 banks supported for this Controller,
* but we have only 1 bank connected to flash on board
*/
-#ifndef CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#define CONFIG_SYS_MAX_FLASH_BANKS1
-#endif
#define CONFIG_SYS_FLASH_BANKS_SIZES {0x400}
/* max number of sectors on one chip */
diff --git a/include/configs/bmips_bcm6338.h b/include/configs/bmips_bcm6338.h
index 6eaca1c31b..b7de3f4058 100644
--- a/include/configs/bmips_bcm6338.h
+++ b/include/configs/bmips_bcm6338.h
@@ -22,6 +22,7 @@
#define CONFIG_SYS_FLASH_BASE 0xbfc0
#define CONFIG_SYS_FLASH_EMPTY_INFO
-#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT 1
+#define CONFIG_SYS_MAX_FLASH_BANKS 1
+#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT
#endif /* __CONFIG_BMIPS_BCM6338_H */
diff --git
Re: [PATCH v1 2/5] mtd: cfi: introduce CFI_FLASH_BANKS
On 1/4/22 14:23, Patrick Delaunay wrote:
Replace CONFIG_SYS_MAX_FLASH_BANKS by CFI_FLASH_BANKS to prepare
Kconfig migration and avoid to redefine CONFIG_SYS_MAX_FLASH_BANKS
in cfi_flash.h.
After this patch CONFIG_SYS_MAX_FLASH_BANKS should be never used in
the cfi code: use CFI_MAX_FLASH_BANKS for struct size or CFI_FLASH_BANKS
for number of CFI banks which can be dynamic.
This patch modify all the files which include mtd/cfi_flash.h.
Signed-off-by: Patrick Delaunay
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v1:
- update drivers/mtd/spi/spi-nor-core.c for cfi_mtd_nb
needed after RFC rebase
cmd/bootm.c| 2 +-
cmd/flash.c| 34 +-
common/flash.c | 2 +-
common/update.c| 4 ++--
drivers/mtd/cfi_flash.c| 4 ++--
drivers/mtd/cfi_mtd.c | 4 ++--
drivers/mtd/spi/spi-nor-core.c | 5 ++---
include/mtd/cfi_flash.h| 9 ++---
8 files changed, 33 insertions(+), 31 deletions(-)
diff --git a/cmd/bootm.c b/cmd/bootm.c
index b82a872a86..e8b7066888 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -338,7 +338,7 @@ static int do_imls_nor(void)
void *hdr;
for (i = 0, info = _info[0];
- i < CONFIG_SYS_MAX_FLASH_BANKS; ++i, ++info) {
+ i < CFI_FLASH_BANKS; ++i, ++info) {
if (info->flash_id == FLASH_UNKNOWN)
goto next_bank;
diff --git a/cmd/flash.c b/cmd/flash.c
index 594e2caa59..db4bb2529c 100644
--- a/cmd/flash.c
+++ b/cmd/flash.c
@@ -60,7 +60,7 @@ abbrev_spec(char *str, flash_info_t **pinfo, int *psf, int
*psl)
bank = dectoul(str, );
if (ep == str || *ep != '\0' ||
- bank < 1 || bank > CONFIG_SYS_MAX_FLASH_BANKS)
+ bank < 1 || bank > CFI_FLASH_BANKS)
return -1;
fp = _info[bank - 1];
@@ -104,7 +104,7 @@ int flash_sect_roundb(ulong *addr)
/* find the end addr of the sector where the *addr is */
found = 0;
- for (bank = 0; bank < CONFIG_SYS_MAX_FLASH_BANKS && !found; ++bank) {
+ for (bank = 0; bank < CFI_FLASH_BANKS && !found; ++bank) {
info = _info[bank];
for (i = 0; i < info->sector_count && !found; ++i) {
/* get the end address of the sector */
@@ -201,13 +201,13 @@ flash_fill_sect_ranges(ulong addr_first, ulong addr_last,
*s_count = 0;
- for (bank = 0; bank < CONFIG_SYS_MAX_FLASH_BANKS; ++bank) {
+ for (bank = 0; bank < CFI_FLASH_BANKS; ++bank) {
s_first[bank] = -1; /* first sector to erase*/
s_last[bank] = -1; /* last sector to erase*/
}
for (bank = 0, info = _info[0];
-(bank < CONFIG_SYS_MAX_FLASH_BANKS) && (addr_first <= addr_last);
+(bank < CFI_FLASH_BANKS) && (addr_first <= addr_last);
++bank, ++info) {
ulong b_end;
int sect;
@@ -278,7 +278,7 @@ static int do_flinfo(struct cmd_tbl *cmdtp, int flag, int
argc,
#ifdef CONFIG_MTD_NOR_FLASH
if (argc == 1) {/* print info for all FLASH banks */
- for (bank = 0; bank < CONFIG_SYS_MAX_FLASH_BANKS; ++bank) {
+ for (bank = 0; bank < CFI_FLASH_BANKS; ++bank) {
printf("\nBank # %ld: ", bank + 1);
flash_print_info(_info[bank]);
@@ -287,9 +287,9 @@ static int do_flinfo(struct cmd_tbl *cmdtp, int flag, int
argc,
}
bank = hextoul(argv[1], NULL);
- if (bank < 1 || bank > CONFIG_SYS_MAX_FLASH_BANKS) {
+ if (bank < 1 || bank > CFI_FLASH_BANKS) {
printf("Only FLASH Banks # 1 ... # %d supported\n",
- CONFIG_SYS_MAX_FLASH_BANKS);
+ CFI_FLASH_BANKS);
return 1;
}
printf("\nBank # %ld: ", bank);
@@ -316,7 +316,7 @@ static int do_flerase(struct cmd_tbl *cmdtp, int flag, int
argc,
return CMD_RET_USAGE;
if (strcmp(argv[1], "all") == 0) {
- for (bank = 1; bank <= CONFIG_SYS_MAX_FLASH_BANKS; ++bank) {
+ for (bank = 1; bank <= CFI_FLASH_BANKS; ++bank) {
printf("Erase Flash Bank # %ld ", bank);
info = _info[bank - 1];
rcode = flash_erase(info, 0, info->sector_count - 1);
@@ -366,9 +366,9 @@ static int do_flerase(struct cmd_tbl *cmdtp, int flag, int
argc,
if (strcmp(argv[1], "bank") == 0) {
bank = hextoul(argv[2], NULL);
- if (bank < 1 || bank > CONFIG_SYS_MAX_FLASH_BANKS) {
+ if (bank < 1 || bank > CFI_FLASH_BANKS) {
printf("Only FLASH Banks # 1 ... # %d supported\n",
- CONFIG_SYS_MAX_FLASH_BANKS);
+ CFI_FLASH_BANKS);
return 1;
}
printf("Erase Flash Bank
Re: [PATCH v1 1/5] cmd: Fix up warnings in flash.c
On 1/4/22 14:23, Patrick Delaunay wrote:
Tidy up the warnings reported by checkpatch.pl to prepare next patches
Signed-off-by: Patrick Delaunay
Reviewed-by: Simon Glass
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
cmd/flash.c | 239 +---
1 file changed, 117 insertions(+), 122 deletions(-)
diff --git a/cmd/flash.c b/cmd/flash.c
index 819febc10e..594e2caa59 100644
--- a/cmd/flash.c
+++ b/cmd/flash.c
@@ -19,7 +19,7 @@
int mtdparts_init(void);
int mtd_id_parse(const char *id, const char **ret_id, u8 *dev_type, u8
*dev_num);
int find_dev_and_part(const char *id, struct mtd_device **dev,
- u8 *part_num, struct part_info **part);
+ u8 *part_num, struct part_info **part);
#endif
#ifdef CONFIG_MTD_NOR_FLASH
@@ -47,34 +47,39 @@ extern flash_info_t flash_info[]; /* info for FLASH chips
*/
* or an invalid flash bank.
*/
static int
-abbrev_spec (char *str, flash_info_t ** pinfo, int *psf, int *psl)
+abbrev_spec(char *str, flash_info_t **pinfo, int *psf, int *psl)
{
flash_info_t *fp;
int bank, first, last;
char *p, *ep;
- if ((p = strchr (str, ':')) == NULL)
+ p = strchr(str, ':');
+ if (!p)
return 0;
*p++ = '\0';
bank = dectoul(str, );
if (ep == str || *ep != '\0' ||
- bank < 1 || bank > CONFIG_SYS_MAX_FLASH_BANKS ||
- (fp = _info[bank - 1])->flash_id == FLASH_UNKNOWN)
+ bank < 1 || bank > CONFIG_SYS_MAX_FLASH_BANKS)
+ return -1;
+
+ fp = _info[bank - 1];
+ if (fp->flash_id == FLASH_UNKNOWN)
return -1;
str = p;
- if ((p = strchr (str, '-')) != NULL)
+ p = strchr(str, '-');
+ if (p)
*p++ = '\0';
first = dectoul(str, );
if (ep == str || *ep != '\0' || first >= fp->sector_count)
return -1;
- if (p != NULL) {
+ if (p) {
last = dectoul(p, );
if (ep == p || *ep != '\0' ||
- last < first || last >= fp->sector_count)
+ last < first || last >= fp->sector_count)
return -1;
} else {
last = first;
@@ -107,11 +112,10 @@ int flash_sect_roundb(ulong *addr)
sector_end_addr = info->start[0] +
info->size - 1;
} else {
- sector_end_addr = info->start[i+1] - 1;
+ sector_end_addr = info->start[i + 1] - 1;
}
- if (*addr <= sector_end_addr &&
- *addr >= info->start[i]) {
+ if (*addr <= sector_end_addr && *addr >=
info->start[i]) {
found = 1;
/* adjust *addr if necessary */
if (*addr < sector_end_addr)
@@ -144,7 +148,7 @@ int flash_sect_roundb(ulong *addr)
* Return:
*1: success
* -1: failure (bad format, bad address).
-*/
+ */
static int
addr_spec(char *arg1, char *arg2, ulong *addr_first, ulong *addr_last)
{
@@ -156,7 +160,7 @@ addr_spec(char *arg1, char *arg2, ulong *addr_first, ulong
*addr_last)
return -1;
len_used = 0;
- if (arg2 && *arg2 == '+'){
+ if (arg2 && *arg2 == '+') {
len_used = 1;
++arg2;
}
@@ -165,7 +169,7 @@ addr_spec(char *arg1, char *arg2, ulong *addr_first, ulong
*addr_last)
if (ep == arg2 || *ep != '\0')
return -1;
- if (len_used){
+ if (len_used) {
/*
* *addr_last has the length, compute correct *addr_last
* XXX watch out for the integer overflow! Right now it is
@@ -187,9 +191,9 @@ addr_spec(char *arg1, char *arg2, ulong *addr_first, ulong
*addr_last)
}
static int
-flash_fill_sect_ranges (ulong addr_first, ulong addr_last,
- int *s_first, int *s_last,
- int *s_count )
+flash_fill_sect_ranges(ulong addr_first, ulong addr_last,
+ int *s_first, int *s_last,
+ int *s_count)
{
flash_info_t *info;
ulong bank;
@@ -197,27 +201,25 @@ flash_fill_sect_ranges (ulong addr_first, ulong addr_last,
*s_count = 0;
- for (bank=0; bank < CONFIG_SYS_MAX_FLASH_BANKS; ++bank) {
+ for (bank = 0; bank < CONFIG_SYS_MAX_FLASH_BANKS; ++bank) {
s_first[bank] = -1; /* first sector to erase*/
- s_last [bank] = -1; /* last sector to erase*/
+ s_last[bank] = -1; /* last sector to erase*/
}
- for (bank=0,info = _info[0];
+ for (bank = 0, info = _info[0];
(bank <
Re: [PATCH v8 12/25] efi: Move exit_boot_services into a function
On 1/4/22 11:52, Simon Glass wrote:
Hi Heinrich,
On Thu, 30 Dec 2021 at 22:41, Heinrich Schuchardt wrote:
On 12/29/21 19:57, Simon Glass wrote:
At present this code is inline in the app and stub. But they do the same
thing. The difference is that the stub does it immediately and the app
doesn't want to do it until the end (when it boots a kernel) or not at
all, if returning to UEFI.
Move it into a function so it can be called as needed.
Also store the memory map so that it can be accessed within the app if
needed.
The memory map is *not* a static object. It may change with any API call
that you make. You must read the memory map immediately before calling
ExitBootServices(). The valid value of MapKey typically will change with
any change of the memory map. Calling ExitBootServices() with the wrong
value of MapKey will lead to a failure. Storing these values except for
immediate use makes no sense.
Signed-off-by: Simon Glass
---
(no changes since v6)
Changes in v6:
- Fix typo in function comment
Changes in v2:
- Add a sentence about what the patch does
include/efi.h | 32 ++
lib/efi/efi.c | 68 ++
lib/efi/efi_app.c | 3 ++
lib/efi/efi_stub.c | 66
4 files changed, 114 insertions(+), 55 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index d4785478585..2a84223d235 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -407,6 +407,12 @@ static inline struct efi_mem_desc *efi_get_next_mem_desc(
* @sys_table: Pointer to system table
* @boot: Pointer to boot-services table
* @run: Pointer to runtime-services table
+ * @memmap_key: Key returned from get_memory_map()
+ * @memmap_desc: List of memory-map records
+ * @memmap_alloc: Amount of memory allocated for memory map list
+ * @memmap_size Size of memory-map list in bytes
+ * @memmap_desc_size: Size of an individual memory-map record, in bytes
+ * @memmap_version: Memory-map version
*
* @use_pool_for_malloc: true if all allocation should go through the EFI
'pool'
* methods allocate_pool() and free_pool(); false to use 'pages' methods
@@ -424,6 +430,12 @@ struct efi_priv {
struct efi_system_table *sys_table;
struct efi_boot_services *boot;
struct efi_runtime_services *run;
+ efi_uintn_t memmap_key;
+ struct efi_mem_desc *memmap_desc;
+ efi_uintn_t memmap_alloc;
+ efi_uintn_t memmap_size;
+ efi_uintn_t memmap_desc_size;
+ u32 memmap_version;
/* app: */
bool use_pool_for_malloc;
@@ -574,4 +586,24 @@ void efi_putc(struct efi_priv *priv, const char ch);
*/
int efi_info_get(enum efi_entry_t type, void **datap, int *sizep);
+/**
+ * efi_store_memory_map() - Collect the memory-map info from EFI
+ *
+ * Collect the memory info and store it for later use, e.g. in calling
+ * exit_boot_services()
+ *
+ * @priv:Pointer to private EFI structure
+ * @return 0 if OK, non-zero on error
+ */
+int efi_store_memory_map(struct efi_priv *priv);
+
+/**
+ * efi_call_exit_boot_services() - Handle the exit-boot-service procedure
+ *
+ * Tell EFI we don't want their boot services anymore
+ *
+ * Return: 0 if OK, non-zero on error
+ */
+int efi_call_exit_boot_services(void);
+
#endif /* _LINUX_EFI_H */
diff --git a/lib/efi/efi.c b/lib/efi/efi.c
index cd6bf47b180..20da88c9151 100644
--- a/lib/efi/efi.c
+++ b/lib/efi/efi.c
@@ -135,3 +135,71 @@ void efi_free(struct efi_priv *priv, void *ptr)
boot->free_pool(ptr);
}
+
+int efi_store_memory_map(struct efi_priv *priv)
+{
+ struct efi_boot_services *boot = priv->sys_table->boottime;
+ efi_uintn_t size, desc_size;
+ efi_status_t ret;
+
+ /* Get the memory map so we can switch off EFI */
+ size = 0;
+ ret = boot->get_memory_map(, NULL, >memmap_key,
+>memmap_desc_size,
+>memmap_version);
+ if (ret != EFI_BUFFER_TOO_SMALL) {
+ printhex2(EFI_BITS_PER_LONG);
+ putc(' ');
+ printhex2(ret);
+ puts(" No memory map\n");
+ return ret;
+ }
+ /*
+ * Since doing a malloc() may change the memory map and also we want to
+ * be able to read the memory map in efi_call_exit_boot_services()
+ * below, after more changes have happened
+ */
+ priv->memmap_alloc = size + 1024;
GetMemoryMap() must be called immediately before calling ExitBootServices().
Yes that's right. I remember reading that in the spec.
If efi_malloc() invokes AllocatePages() or AllocatePohl(), you should
add DescriptorSize to MemoryMapSize and not some random value (e.g. 1024).
This is copying existing code. If you want to change this, we can do
it in a follow-on patch.
For that discussion, How do you know it will be increased by
sizeof(DescriptorSize) ? Is that in the spec somewhere?
In one run of the stub with qemu it returned 0x1170 for
