Re: [RESEND v9 1/9] efi_loader: move udevice pointer into struct efi_object

[Takahiro Akashi]

On Sun, Jul 17, 2022 at 01:23:41PM +0200, Heinrich Schuchardt wrote:
> On 7/17/22 10:09, Heinrich Schuchardt wrote:
> > On 7/15/22 16:47, Masahisa Kojima wrote:
> > > This is a preparation patch to provide the unified method
> > > to access udevice pointer associated with the block io device.
> > > The EFI handles of both EFI block io driver implemented in
> > > lib/efi_loader/efi_disk.c and EFI block io driver implemented
> > > as EFI payload can posess the udevice pointer in the struct efi_object.
> > > 
> > > We can use this udevice pointer to get the U-Boot friendly
> > > block device name(e.g. mmc 0:1, nvme 0:1) through efi_handle_t.
> > > 
> > > Signed-off-by: Masahisa Kojima 
> > > ---
> > > Newly created in v9
> > > 
> > >   include/efi_loader.h  |  8 
> > >   lib/efi_loader/efi_disk.c | 20 +---
> > >   2 files changed, 21 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > index 3a63a1f75f..bba5ffd482 100644
> > > --- a/include/efi_loader.h
> > > +++ b/include/efi_loader.h
> > > @@ -226,6 +226,12 @@ const char *__efi_nesting_dec(void);
> > >   #define EFI_CACHELINE_SIZE 128
> > >   #endif
> > > 
> > > +/**
> > > + * efi_handle_to_udev - accessor to the DM device associated to the
> > > EFI handle
> > > + * @handle:    pointer to the EFI handle
> > > + */
> > > +#define efi_handle_to_udev(handle) (((struct efi_object *)handle)->dev)
> > 
> > This conversion will hide errors if handle is not of type efi_handle_t.
> > We should avoid the conversion and see build time errors instead.
> > Please, remove the macro.
> > 
> > For every handle of type efi_handle_t you can access the field
> > handle->dev directly.
> > 
> > For struct efi_disk_obj we can use disk->header.dev.
> > 
> > > +
> > >   /* Key identifying current memory map */
> > >   extern efi_uintn_t efi_memory_map_key;
> > > 
> > > @@ -375,6 +381,7 @@ enum efi_object_type {
> > >    * @protocols:    linked list with the protocol interfaces installed
> > > on this
> > >    *    handle
> > >    * @type:    image type if the handle relates to an image
> > > + * @dev:    pointer to the DM device which is associated with this
> > > EFI handle
> > >    *
> > >    * UEFI offers a flexible and expandable object model. The objects
> > > in the UEFI
> > >    * API are devices, drivers, and loaded images. struct efi_object is
> > > our storage
> > > @@ -392,6 +399,7 @@ struct efi_object {
> > >   /* The list of protocols */
> > >   struct list_head protocols;
> > >   enum efi_object_type type;
> > > +    struct udevice *dev;
> > >   };
> > > 
> > >   enum efi_image_auth_status {
> > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > > index 1d700b2a6b..a8e8521e3e 100644
> > > --- a/lib/efi_loader/efi_disk.c
> > > +++ b/lib/efi_loader/efi_disk.c
> > > @@ -46,7 +46,6 @@ struct efi_disk_obj {
> > >   struct efi_device_path *dp;
> > >   unsigned int part;
> > >   struct efi_simple_file_system_protocol *volume;
> > > -    struct udevice *dev; /* TODO: move it to efi_object */
> > 
> > ok
> > 
> > >   };
> > > 
> > >   /**
> > > @@ -124,16 +123,16 @@ static efi_status_t efi_disk_rw_blocks(struct
> > > efi_block_io *this,
> > >   return EFI_BAD_BUFFER_SIZE;
> > > 
> > >   if (CONFIG_IS_ENABLED(PARTITIONS) &&
> > > -    device_get_uclass_id(diskobj->dev) == UCLASS_PARTITION) {
> > > +    device_get_uclass_id(efi_handle_to_udev(diskobj)) ==
> > > UCLASS_PARTITION) {
> > 
> > device_get_uclass_id(diskobj->header.hdev)) == UCLASS_PARTITION) {
> > 
> > >   if (direction == EFI_DISK_READ)
> > > -    n = dev_read(diskobj->dev, lba, blocks, buffer);
> > > +    n = dev_read(efi_handle_to_udev(diskobj), lba, blocks,
> > > buffer);
> > 
> > dev_read(diskobj->header.hdev)
> > 
> > >   else
> > > -    n = dev_write(diskobj->dev, lba, blocks, buffer);
> > > +    n = dev_write(efi_handle_to_udev(diskobj), lba, blocks,
> > > buffer);
> > 
> > dev_write(diskobj->header.hdev)
> > 
> > >   } else {
> > >   /* dev is a block device (UCLASS_BLK) */
> > >   struct blk_desc *desc;
> > > 
> > > -    desc = dev_get_uclass_plat(diskobj->dev);
> > > +    desc = dev_get_uclass_plat(efi_handle_to_udev(diskobj));
> > 
> > dev_get_uclass(diskobj->header.hdev)
> > 
> > 
> > >   if (direction == EFI_DISK_READ)
> > >   n = blk_dread(desc, lba, blocks, buffer);
> > >   else
> > > @@ -552,7 +551,7 @@ static int efi_disk_create_raw(struct udevice *dev)
> > > 
> > >   return -1;
> > >   }
> > > -    disk->dev = dev;
> > > +    efi_handle_to_udev(disk) = dev;
> > >   if (dev_tag_set_ptr(dev, DM_TAG_EFI, >header)) {
> > >   efi_free_pool(disk->dp);
> > >   efi_delete_handle(>header);
> > > @@ -609,7 +608,7 @@ static int efi_disk_create_part(struct udevice *dev)
> > >   log_err("Adding partition for %s 

Re: [PATCH 2/2] ubifs: Use U-Boot assert() from in UBI/UBIFS code

[Heiko Schocher]

Hello Pali,

On 10.07.22 13:38, Pali Rohár wrote:
> U-Boot already provides assert function, so it use also in ubi and ubifs code.
> 
> Signed-off-by: Pali Rohár 
> ---
>  drivers/mtd/ubi/debug.h | 9 ++---
>  fs/ubifs/debug.h| 9 ++---
>  2 files changed, 4 insertions(+), 14 deletions(-)

Applied to u-boot-ubi.git master

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH 1/2] ubifs: Fix ubifs_assert_cmt_locked()

[Heiko Schocher]

Hello Pali,

On 10.07.22 13:38, Pali Rohár wrote:
> U-Boot does not implement down_write_trylock() and its stub always returns
> true that lock was acquired. Therefore ubifs_assert_cmt_locked() assert
> currently always fails.
> 
> Fix this issue by redefining ubifs_assert_cmt_locked() to just empty stub
> as there is nothing to assert.
> 
> Signed-off-by: Pali Rohár 
> ---
>  fs/ubifs/debug.h | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)

Applied to u-boot-ubi.git master

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v5 20/23] FWU: synquacer: Generate dfu_alt_info from devicetree partition

[Jassi Brar]

On Tue, 19 Jul 2022 at 20:13, Takahiro Akashi
 wrote:
>
> On Mon, Jul 18, 2022 at 09:49:56AM -0500, Jassi Brar wrote:
> > On Fri, 17 Jun 2022 at 09:02, Michal Simek  wrote:
> > > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > > From: Masami Hiramatsu 
> > .
> >
> > > >
> > > > @@ -188,6 +178,9 @@ int board_late_init(void)
> > > >   {
> > > >   int ret;
> > > >
> > > > + /* Make mmc available for EFI */
> > > > + run_command("mmc dev 0", 0);
> > > > +
> > >
> > > What is this for?
> > >
> > > And I can't see any single note about in commit message.
> > >
> > For some reason, we get "No EFI system partition" during bootup and
> > the mmc does not show up in 'efidebug devices' unless we manually run
> > this (or mmc part) command.
>
> As far as UEFI is concerned, any U-Boot block device will be
> recognized as a UEFI disk(block_io) object *only* after device_probe()
> is called.
>
OK, thanks for the clarification.  And I shouldn't feel too bad about
the hack then :)

thanks.

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

[Tom Rini]

On Tue, Jul 19, 2022 at 10:23:08AM -0500, Jassi Brar wrote:
> On Mon, Jul 18, 2022 at 4:00 PM Tom Rini  wrote:
> > On Mon, Jul 18, 2022 at 10:31:56AM -0500, Jassi Brar wrote:
> 
> > > > > > > > > +
> > > > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > > > +
> > > > > > > > > +struct __packed devbox_metadata {
> > > > > > > > > + u32 boot_index;
> > > > > > > > > + u32 boot_count;
> > > > > > > >
> > > > > > > > There is the whole bootcount infrastructure for this. I think 
> > > > > > > > it would be much
> > > > > > > > better to use that framework instead of creating parallel one.
> > > > > > > >
> > > > > > > Yes, this goes too.
> > > > > >
> > > > > > Is bootcount really suited for this case?
> > > > > > AFAIK bootcount either requires device specific registers (which 
> > > > > > won't
> > > > > > reset on reboots), or an environment you can write data to.
> > > > > > But what if a user wants to disable writing the env variables and 
> > > > > > the
> > > > > > device doesn't have a set of registers we can use?
> > > > > >
> > > > > Maybe it should be moved in 'struct fwu_mdata' ?
> > > >
> > > > I was mostly thinking on moving this count as another 'bootcount'
> > > > method.  So in case the user has disabled writing evn variables but he
> > > > is booting with EFI he can use that.
> > >
> > > Sorry, not sure I understand IIUIC there has to be some persistent 
> > > storage.
> >
> > No, there just has to be "somewhere" to do the counting.  We've got a
> > DDR backed driver, for example.  So yes, I think we should try and use
> > the bootcount framework here.
> >
> OK, for platforms that can preserve ram across reboot, using
> non-persistent storage can work.
> My platform neither preserves ram, nor has any warmreset-proof
> registers. So I have to choose between saving the bootcount in efi-env
> or in vendor specific structure next to the metadata. I prefer
> metadata because it is common to all stages of boot. Any corrections
> to this approach?

What I'm trying to say is that we have an abstraction for counting the
number of times the system has booted since something reset the counter
to zero, to signal the system is up and functional.  I'll leave the
details of how it's used here, and how / what backend is used or created
for it up to everyone else on the thread.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v5 20/23] FWU: synquacer: Generate dfu_alt_info from devicetree partition

[Takahiro Akashi]

On Mon, Jul 18, 2022 at 09:49:56AM -0500, Jassi Brar wrote:
> On Fri, 17 Jun 2022 at 09:02, Michal Simek  wrote:
> > On 6/9/22 14:30, Sughosh Ganu wrote:
> > > From: Masami Hiramatsu 
> .
> 
> > >
> > > @@ -188,6 +178,9 @@ int board_late_init(void)
> > >   {
> > >   int ret;
> > >
> > > + /* Make mmc available for EFI */
> > > + run_command("mmc dev 0", 0);
> > > +
> >
> > What is this for?
> >
> > And I can't see any single note about in commit message.
> >
> For some reason, we get "No EFI system partition" during bootup and
> the mmc does not show up in 'efidebug devices' unless we manually run
> this (or mmc part) command.

As far as UEFI is concerned, any U-Boot block device will be
recognized as a UEFI disk(block_io) object *only* after device_probe()
is called.

-Takahiro Akashi


> Though not elegant, I found similar being done by some other
> platforms  grep run_command -rw board/*
> I am happy to learn the proper way of doing it.
> 
> Thanks.

Re: [RESEND v9 1/9] efi_loader: move udevice pointer into struct efi_object

[Takahiro Akashi]

On Sun, Jul 17, 2022 at 10:09:42AM +0200, Heinrich Schuchardt wrote:
> On 7/15/22 16:47, Masahisa Kojima wrote:
> > This is a preparation patch to provide the unified method
> > to access udevice pointer associated with the block io device.
> > The EFI handles of both EFI block io driver implemented in
> > lib/efi_loader/efi_disk.c and EFI block io driver implemented
> > as EFI payload can posess the udevice pointer in the struct efi_object.
> > 
> > We can use this udevice pointer to get the U-Boot friendly
> > block device name(e.g. mmc 0:1, nvme 0:1) through efi_handle_t.
> > 
> > Signed-off-by: Masahisa Kojima 
> > ---
> > Newly created in v9
> > 
> >   include/efi_loader.h  |  8 
> >   lib/efi_loader/efi_disk.c | 20 +---
> >   2 files changed, 21 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 3a63a1f75f..bba5ffd482 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -226,6 +226,12 @@ const char *__efi_nesting_dec(void);
> >   #define EFI_CACHELINE_SIZE 128
> >   #endif
> > 
> > +/**
> > + * efi_handle_to_udev - accessor to the DM device associated to the EFI 
> > handle
> > + * @handle:pointer to the EFI handle
> > + */
> > +#define efi_handle_to_udev(handle) (((struct efi_object *)handle)->dev)
> 
> This conversion will hide errors if handle is not of type efi_handle_t.
> We should avoid the conversion and see build time errors instead.
> Please, remove the macro.

I don't think we should remove the macro itself, but only the type casting.

I think it is a good practice to hide an implementation how the relationship
between udev and efi_object is maintained *behind* accessor macros.

> For every handle of type efi_handle_t you can access the field
> handle->dev directly.
> 
> For struct efi_disk_obj we can use disk->header.dev.

This is a good example for hiding the implementation from the rest of code.

> > +
> >   /* Key identifying current memory map */
> >   extern efi_uintn_t efi_memory_map_key;
> > 
> > @@ -375,6 +381,7 @@ enum efi_object_type {
> >* @protocols:linked list with the protocol interfaces installed on 
> > this
> >*handle
> >* @type: image type if the handle relates to an image
> > + * @dev:   pointer to the DM device which is associated with this EFI 
> > handle
> >*
> >* UEFI offers a flexible and expandable object model. The objects in the 
> > UEFI
> >* API are devices, drivers, and loaded images. struct efi_object is our 
> > storage
> > @@ -392,6 +399,7 @@ struct efi_object {
> > /* The list of protocols */
> > struct list_head protocols;
> > enum efi_object_type type;
> > +   struct udevice *dev;
> >   };
> > 
> >   enum efi_image_auth_status {
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index 1d700b2a6b..a8e8521e3e 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -46,7 +46,6 @@ struct efi_disk_obj {
> > struct efi_device_path *dp;
> > unsigned int part;
> > struct efi_simple_file_system_protocol *volume;
> > -   struct udevice *dev; /* TODO: move it to efi_object */
> 
> ok
> 
> >   };
> > 
> >   /**
> > @@ -124,16 +123,16 @@ static efi_status_t efi_disk_rw_blocks(struct 
> > efi_block_io *this,
> > return EFI_BAD_BUFFER_SIZE;
> > 
> > if (CONFIG_IS_ENABLED(PARTITIONS) &&
> > -   device_get_uclass_id(diskobj->dev) == UCLASS_PARTITION) {
> > +   device_get_uclass_id(efi_handle_to_udev(diskobj)) == 
> > UCLASS_PARTITION) {
> 
> device_get_uclass_id(diskobj->header.hdev)) == UCLASS_PARTITION) {
> 
> > if (direction == EFI_DISK_READ)
> > -   n = dev_read(diskobj->dev, lba, blocks, buffer);
> > +   n = dev_read(efi_handle_to_udev(diskobj), lba, blocks, 
> > buffer);
> 
> dev_read(diskobj->header.hdev)
> 
> > else
> > -   n = dev_write(diskobj->dev, lba, blocks, buffer);
> > +   n = dev_write(efi_handle_to_udev(diskobj), lba, blocks, 
> > buffer);
> 
> dev_write(diskobj->header.hdev)
> 
> > } else {
> > /* dev is a block device (UCLASS_BLK) */
> > struct blk_desc *desc;
> > 
> > -   desc = dev_get_uclass_plat(diskobj->dev);
> > +   desc = dev_get_uclass_plat(efi_handle_to_udev(diskobj));
> 
> dev_get_uclass(diskobj->header.hdev)
> 
> 
> > if (direction == EFI_DISK_READ)
> > n = blk_dread(desc, lba, blocks, buffer);
> > else
> > @@ -552,7 +551,7 @@ static int efi_disk_create_raw(struct udevice *dev)
> > 
> > return -1;
> > }
> > -   disk->dev = dev;
> > +   efi_handle_to_udev(disk) = dev;
> > if (dev_tag_set_ptr(dev, DM_TAG_EFI, >header)) {
> > efi_free_pool(disk->dp);
> > efi_delete_handle(>header);
> > @@ -609,7 +608,7 @@ static int efi_disk_create_part(struct udevice *dev)
> >

[PATCH v4] patman: By default don't pass "--no-tree" to checkpatch for linux

[Douglas Anderson]

When you pass "--no-tree" to checkpatch it disables some extra checks
that are important for Linux. Specifically I want checks like:

  warning: DT compatible string "boogie,woogie" appears un-documented
  check ./Documentation/devicetree/bindings/

Let's make the default for Linux to _not_ pass --no-tree. We'll have a
config option and command line flag to override.

Signed-off-by: Douglas Anderson 
---
Without BooleanOptionalAction (python 3.9), it's a little odd to make
the help text understandable while having the help text account for
the project settings when printing the default (which it can only
print as "True" or "False". It feels like no matter how you swing it
you've got to use a double-negative or use weird syntax like I did.

I removed previous review/testing tags since at least parts of this
patch changed in non-trivial ways.

This patch is now a singleton since the other patches in the series
landed or became irrelevant.

Changes in v4:
- Don't use BooleanOptionalAction

 tools/patman/checkpatch.py | 11 +++
 tools/patman/control.py|  7 ---
 tools/patman/main.py   |  6 ++
 tools/patman/settings.py   |  3 ++-
 4 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
index 70ba561c2686..d1b902dd9627 100644
--- a/tools/patman/checkpatch.py
+++ b/tools/patman/checkpatch.py
@@ -186,7 +186,7 @@ def check_patch_parse(checkpatch_output, verbose=False):
 return result
 
 
-def check_patch(fname, verbose=False, show_types=False):
+def check_patch(fname, verbose=False, show_types=False, use_tree=False):
 """Run checkpatch.pl on a file and parse the results.
 
 Args:
@@ -194,6 +194,7 @@ def check_patch(fname, verbose=False, show_types=False):
 verbose: True to print out every line of the checkpatch output as it is
 parsed
 show_types: Tell checkpatch to show the type (number) of each message
+use_tree (bool): If False we'll pass '--no-tree' to checkpatch.
 
 Returns:
 namedtuple containing:
@@ -210,7 +211,9 @@ def check_patch(fname, verbose=False, show_types=False):
 stdout: Full output of checkpatch
 """
 chk = find_check_patch()
-args = [chk, '--no-tree']
+args = [chk]
+if not use_tree:
+args.append('--no-tree')
 if show_types:
 args.append('--show-types')
 output = command.output(*args, fname, raise_on_error=False)
@@ -236,13 +239,13 @@ def get_warning_msg(col, msg_type, fname, line, msg):
 line_str = '' if line is None else '%d' % line
 return '%s:%s: %s: %s\n' % (fname, line_str, msg_type, msg)
 
-def check_patches(verbose, args):
+def check_patches(verbose, args, use_tree):
 '''Run the checkpatch.pl script on each patch'''
 error_count, warning_count, check_count = 0, 0, 0
 col = terminal.Color()
 
 for fname in args:
-result = check_patch(fname, verbose)
+result = check_patch(fname, verbose, use_tree=use_tree)
 if not result.ok:
 error_count += result.errors
 warning_count += result.warnings
diff --git a/tools/patman/control.py b/tools/patman/control.py
index b40382388e07..bf426cf7bcf4 100644
--- a/tools/patman/control.py
+++ b/tools/patman/control.py
@@ -64,7 +64,7 @@ def prepare_patches(col, branch, count, start, end, 
ignore_binary, signoff):
 patchstream.insert_cover_letter(cover_fname, series, to_do)
 return series, cover_fname, patch_files
 
-def check_patches(series, patch_files, run_checkpatch, verbose):
+def check_patches(series, patch_files, run_checkpatch, verbose, use_tree):
 """Run some checks on a set of patches
 
 This santiy-checks the patman tags like Series-version and runs the patches
@@ -77,6 +77,7 @@ def check_patches(series, patch_files, run_checkpatch, 
verbose):
 run_checkpatch (bool): True to run checkpatch.pl
 verbose (bool): True to print out every line of the checkpatch output 
as
 it is parsed
+use_tree (bool): If False we'll pass '--no-tree' to checkpatch.
 
 Returns:
 bool: True if the patches had no errors, False if they did
@@ -86,7 +87,7 @@ def check_patches(series, patch_files, run_checkpatch, 
verbose):
 
 # Check the patches, and run them through 'git am' just to be sure
 if run_checkpatch:
-ok = checkpatch.check_patches(verbose, patch_files)
+ok = checkpatch.check_patches(verbose, patch_files, use_tree)
 else:
 ok = True
 return ok
@@ -165,7 +166,7 @@ def send(args):
 col, args.branch, args.count, args.start, args.end,
 args.ignore_binary, args.add_signoff)
 ok = check_patches(series, patch_files, args.check_patch,
-   args.verbose)
+   args.verbose, args.check_patch_use_tree)
 
 ok = ok and gitutil.check_suppress_cc_config()
 
diff --git a/tools/patman/main.py b/tools/patman/main.py
index d0c1a16b2b91..5fb78dc428ca 

[PATCH V2 13/13] mtd: decommission the NAND museum

[Michael Trimarchi]

Upstream linux commit f7025a43a9

The MTD subsystem has its own small museum of ancient NANDs in a form of the
CONFIG_MTD_NAND_MUSEUM_IDS configuration option. The museum contains stone age
NANDs with 256 bytes pages, as well as iron age NANDs with 512 bytes per page
and up to 8MiB page size.

It is with great sorrow that I inform you that the museum is being
decommissioned. The MTD subsystem is out of budget for Kconfig options and
already has too many of them, and there is a general kernel trend to simplify
the configuration menu.

We remove the stone age exhibits along with closing the museum

REMARK Don't apply this part from upstream:

Some of the iron age ones are transferred to the regular NAND depot. Namely, 
only those
which have unique device IDs are transferred, and the ones which have
conflicting device IDs are removed.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- remove part of the patch because they will be removed anyway
  later in linux
---
 drivers/mtd/nand/raw/nand_ids.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index 7602dd30f1..4dece1b206 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -24,16 +24,6 @@
  * extended chip ID.
  */
 struct nand_flash_dev nand_flash_ids[] = {
-#ifdef CONFIG_MTD_NAND_MUSEUM_IDS
-   LEGACY_ID_NAND("NAND 1MiB 5V 8-bit",0x6e, 1, SZ_4K, SP_OPTIONS),
-   LEGACY_ID_NAND("NAND 2MiB 5V 8-bit",0x64, 2, SZ_4K, SP_OPTIONS),
-   LEGACY_ID_NAND("NAND 1MiB 3,3V 8-bit",  0xe8, 1, SZ_4K, SP_OPTIONS),
-   LEGACY_ID_NAND("NAND 1MiB 3,3V 8-bit",  0xec, 1, SZ_4K, SP_OPTIONS),
-   LEGACY_ID_NAND("NAND 2MiB 3,3V 8-bit",  0xea, 2, SZ_4K, SP_OPTIONS),
-   LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit",  0xd5, 4, SZ_8K, SP_OPTIONS),
-
-   LEGACY_ID_NAND("NAND 8MiB 3,3V 8-bit",  0xe6, 8, SZ_8K, SP_OPTIONS),
-#endif
/*
 * Some incompatible NAND chips share device ID's and so must be
 * listed by full ID. We list them first so that we can easily identify
-- 
2.34.1

[PATCH V2 12/13] mtd: nand: toshiba: Retrieve ECC requirements from extended ID

[Michael Trimarchi]

Upstream linux commit fb3bff5b40

This patch enables support to read the ECC strength and size from the
NAND flash using Toshiba Memory SLC NAND extended-ID. This patch is
based on the information of the 6th ID byte of the Toshiba Memory SLC
NAND.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
---
 drivers/mtd/nand/raw/nand_toshiba.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_toshiba.c 
b/drivers/mtd/nand/raw/nand_toshiba.c
index 4328e566b0..1adce3ebbd 100644
--- a/drivers/mtd/nand/raw/nand_toshiba.c
+++ b/drivers/mtd/nand/raw/nand_toshiba.c
@@ -36,6 +36,32 @@ static void toshiba_nand_decode_id(struct nand_chip *chip)
(chip->id.data[5] & 0x7) == 0x6 /* 24nm */ &&
!(chip->id.data[4] & 0x80) /* !BENAND */)
mtd->oobsize = 32 * mtd->writesize >> 9;
+
+   /*
+* Extract ECC requirements from 6th id byte.
+* For Toshiba SLC, ecc requrements are as follows:
+*  - 43nm: 1 bit ECC for each 512Byte is required.
+*  - 32nm: 4 bit ECC for each 512Byte is required.
+*  - 24nm: 8 bit ECC for each 512Byte is required.
+*/
+   if (chip->id.len >= 6 && nand_is_slc(chip)) {
+   chip->ecc_step_ds = 512;
+   switch (chip->id.data[5] & 0x7) {
+   case 0x4:
+   chip->ecc_strength_ds = 1;
+   break;
+   case 0x5:
+   chip->ecc_strength_ds = 4;
+   break;
+   case 0x6:
+   chip->ecc_strength_ds = 8;
+   break;
+   default:
+   WARN(1, "Could not get ECC info");
+   chip->ecc_step_ds = 0;
+   break;
+   }
+   }
 }
 
 static int toshiba_nand_init(struct nand_chip *chip)
-- 
2.34.1

[PATCH V2 11/13] mtd: nand: Move Macronix specific initialization in nand_macronix.c

[Michael Trimarchi]

Upstream linux commit 3b5206f4be

Move Macronix specific initialization logic into nand_macronix.c. This
is part of the "separate vendor specific code from core" cleanup
process.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- adjust the include file in nand_macronix
---
 drivers/mtd/nand/raw/Makefile|  4 +++-
 drivers/mtd/nand/raw/nand_base.c | 11 --
 drivers/mtd/nand/raw/nand_ids.c  |  2 +-
 drivers/mtd/nand/raw/nand_macronix.c | 30 
 include/linux/mtd/rawnand.h  |  1 +
 5 files changed, 35 insertions(+), 13 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_macronix.c

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index e1d511c12c..c8317a1078 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -14,7 +14,8 @@ obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
 obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
 obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
 obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
-obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_amd.o nand_hynix.o 
nand_micron.o \
+obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_amd.o nand_hynix.o \
+   nand_macronix.o nand_micron.o \
nand_samsung.o nand_toshiba.o
 obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
 obj-$(CONFIG_TPL_NAND_INIT) += nand.o
@@ -34,6 +35,7 @@ obj-y += nand_ecc.o
 obj-y += nand_base.o
 obj-y += nand_amd.o
 obj-y += nand_hynix.o
+obj-y += nand_macronix.o
 obj-y += nand_micron.o
 obj-y += nand_samsung.o
 obj-y += nand_toshiba.o
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index f79e57b9fb..a38cc4d135 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4218,22 +4218,11 @@ static void nand_decode_id(struct nand_chip *chip,
 static void nand_decode_bbm_options(struct mtd_info *mtd,
struct nand_chip *chip)
 {
-   int maf_id = chip->id.data[0];
-
/* Set the bad block position */
if (mtd->writesize > 512 || (chip->options & NAND_BUSWIDTH_16))
chip->badblockpos = NAND_LARGE_BADBLOCK_POS;
else
chip->badblockpos = NAND_SMALL_BADBLOCK_POS;
-
-   /*
-* Bad block marker is stored in the last page of each block on Samsung
-* and Hynix MLC devices; stored in first two pages of each block on
-* Micron devices with 2KiB pages and on SLC Samsung, Hynix, Toshiba,
-* AMD/Spansion, and Macronix.  All others scan only the first page.
-*/
-   if (nand_is_slc(chip) && maf_id == NAND_MFR_MACRONIX)
-   chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
 }
 
 static inline bool is_full_id_nand(struct nand_flash_dev *type)
diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index c78f2e0880..7602dd30f1 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -197,7 +197,7 @@ struct nand_manufacturers nand_manuf_ids[] = {
{NAND_MFR_HYNIX, "Hynix", _nand_manuf_ops},
{NAND_MFR_MICRON, "Micron", _nand_manuf_ops},
{NAND_MFR_AMD, "AMD/Spansion", _nand_manuf_ops},
-   {NAND_MFR_MACRONIX, "Macronix"},
+   {NAND_MFR_MACRONIX, "Macronix", _nand_manuf_ops},
{NAND_MFR_EON, "Eon"},
{NAND_MFR_SANDISK, "SanDisk"},
{NAND_MFR_INTEL, "Intel"},
diff --git a/drivers/mtd/nand/raw/nand_macronix.c 
b/drivers/mtd/nand/raw/nand_macronix.c
new file mode 100644
index 00..d290ff2a6d
--- /dev/null
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Copyright (C) 2017 NextThing Co
+ *
+ * Author: Boris Brezillon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+static int macronix_nand_init(struct nand_chip *chip)
+{
+   if (nand_is_slc(chip))
+   chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
+
+   return 0;
+}
+
+const struct nand_manufacturer_ops macronix_nand_manuf_ops = {
+   .init = macronix_nand_init,
+};
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index bb1a359a9c..aa45558b3d 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1143,6 +1143,7 @@ extern const struct nand_manufacturer_ops 
samsung_nand_manuf_ops;
 

[PATCH V2 10/13] mtd: nand: Move AMD/Spansion specific init/detection logic in nand_amd.c

[Michael Trimarchi]

Upstream linux commit 229204da53

Move AMD/Spansion specific initialization/detection logic into
nand_amd.c. This is part of the "separate vendor specific code from
core" cleanup process.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- adjust the include file in nand_amd
---
 drivers/mtd/nand/raw/Makefile|  4 ++-
 drivers/mtd/nand/raw/nand_amd.c  | 51 
 drivers/mtd/nand/raw/nand_base.c | 17 +--
 drivers/mtd/nand/raw/nand_ids.c  |  2 +-
 include/linux/mtd/rawnand.h  |  1 +
 5 files changed, 57 insertions(+), 18 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_amd.c

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index e8fb451076..e1d511c12c 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -14,7 +14,8 @@ obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
 obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
 obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
 obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
-obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_hynix.o nand_micron.o 
nand_samsung.o nand_toshiba.o
+obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_amd.o nand_hynix.o 
nand_micron.o \
+   nand_samsung.o nand_toshiba.o
 obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
 obj-$(CONFIG_TPL_NAND_INIT) += nand.o
 ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
@@ -31,6 +32,7 @@ obj-y += nand_ids.o
 obj-y += nand_util.o
 obj-y += nand_ecc.o
 obj-y += nand_base.o
+obj-y += nand_amd.o
 obj-y += nand_hynix.o
 obj-y += nand_micron.o
 obj-y += nand_samsung.o
diff --git a/drivers/mtd/nand/raw/nand_amd.c b/drivers/mtd/nand/raw/nand_amd.c
new file mode 100644
index 00..22f060f381
--- /dev/null
+++ b/drivers/mtd/nand/raw/nand_amd.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Copyright (C) 2017 NextThing Co
+ *
+ * Author: Boris Brezillon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+static void amd_nand_decode_id(struct nand_chip *chip)
+{
+   struct mtd_info *mtd = nand_to_mtd(chip);
+
+   nand_decode_ext_id(chip);
+
+   /*
+* Check for Spansion/AMD ID + repeating 5th, 6th byte since
+* some Spansion chips have erasesize that conflicts with size
+* listed in nand_ids table.
+* Data sheet (5 byte ID): Spansion S30ML-P ORNAND (p.39)
+*/
+   if (chip->id.data[4] != 0x00 && chip->id.data[5] == 0x00 &&
+   chip->id.data[6] == 0x00 && chip->id.data[7] == 0x00 &&
+   mtd->writesize == 512) {
+   mtd->erasesize = 128 * 1024;
+   mtd->erasesize <<= ((chip->id.data[3] & 0x03) << 1);
+   }
+}
+
+static int amd_nand_init(struct nand_chip *chip)
+{
+   if (nand_is_slc(chip))
+   chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
+
+   return 0;
+}
+
+const struct nand_manufacturer_ops amd_nand_manuf_ops = {
+   .detect = amd_nand_decode_id,
+   .init = amd_nand_init,
+};
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index d2079c73fb..f79e57b9fb 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4201,7 +4201,6 @@ static void nand_decode_id(struct nand_chip *chip,
struct nand_flash_dev *type)
 {
struct mtd_info *mtd = >mtd;
-   int maf_id = chip->id.data[0];
 
mtd->erasesize = type->erasesize;
mtd->writesize = type->pagesize;
@@ -4209,19 +4208,6 @@ static void nand_decode_id(struct nand_chip *chip,
 
/* All legacy ID NAND are small-page, SLC */
chip->bits_per_cell = 1;
-
-   /*
-* Check for Spansion/AMD ID + repeating 5th, 6th byte since
-* some Spansion chips have erasesize that conflicts with size
-* listed in nand_ids table.
-* Data sheet (5 byte ID): Spansion S30ML-P ORNAND (p.39)
-*/
-   if (maf_id == NAND_MFR_AMD && chip->id.data[4] != 0x00 && 
chip->id.data[5] == 0x00
-   && chip->id.data[6] == 0x00 && chip->id.data[7] == 0x00
-   && mtd->writesize == 512) {
-   mtd->erasesize = 128 * 1024;
-   mtd->erasesize <<= ((chip->id.data[3] & 0x03) << 1);
-   }
 }
 
 /*
@@ -4246,8 +4232,7 @@ static void nand_decode_bbm_options(struct mtd_info *mtd,
 * Micron devices with 2KiB pages 

[PATCH V2 09/13] mtd: nand: Move Micron specific init logic in nand_micron.c

[Michael Trimarchi]

Upstream linux commit 10d4e75c36

Move Micron specific initialization logic into nand_micron.c. This is
part of the "separate vendor specific code from core" cleanup process.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- adjust the include file in nand_micron
---
 drivers/mtd/nand/raw/Makefile  |  3 +-
 drivers/mtd/nand/raw/nand_base.c   | 33 +---
 drivers/mtd/nand/raw/nand_ids.c|  2 +-
 drivers/mtd/nand/raw/nand_micron.c | 86 ++
 include/linux/mtd/rawnand.h| 21 +---
 5 files changed, 92 insertions(+), 53 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_micron.c

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index db608a2830..e8fb451076 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
 obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
 obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
 obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
-obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_hynix.o nand_samsung.o 
nand_toshiba.o
+obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_hynix.o nand_micron.o 
nand_samsung.o nand_toshiba.o
 obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
 obj-$(CONFIG_TPL_NAND_INIT) += nand.o
 ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
@@ -32,6 +32,7 @@ obj-y += nand_util.o
 obj-y += nand_ecc.o
 obj-y += nand_base.o
 obj-y += nand_hynix.o
+obj-y += nand_micron.o
 obj-y += nand_samsung.o
 obj-y += nand_toshiba.o
 obj-y += nand_timings.o
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 8c06b1c530..d2079c73fb 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -3871,30 +3871,6 @@ ext_out:
return ret;
 }
 
-static int nand_setup_read_retry_micron(struct mtd_info *mtd, int retry_mode)
-{
-   struct nand_chip *chip = mtd_to_nand(mtd);
-   uint8_t feature[ONFI_SUBFEATURE_PARAM_LEN] = {retry_mode};
-
-   return chip->onfi_set_features(mtd, chip, ONFI_FEATURE_ADDR_READ_RETRY,
-   feature);
-}
-
-/*
- * Configure chip properties from Micron vendor-specific ONFI table
- */
-static void nand_onfi_detect_micron(struct nand_chip *chip,
-   struct nand_onfi_params *p)
-{
-   struct nand_onfi_vendor_micron *micron = (void *)p->vendor;
-
-   if (le16_to_cpu(p->vendor_revision) < 1)
-   return;
-
-   chip->read_retries = micron->read_retry_options;
-   chip->setup_read_retry = nand_setup_read_retry_micron;
-}
-
 /*
  * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
  */
@@ -3994,9 +3970,6 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip)
pr_warn("Could not retrieve ONFI ECC requirements\n");
}
 
-   if (p->jedec_id == NAND_MFR_MICRON)
-   nand_onfi_detect_micron(chip, p);
-
return 1;
 }
 #else
@@ -4273,10 +4246,8 @@ static void nand_decode_bbm_options(struct mtd_info *mtd,
 * Micron devices with 2KiB pages and on SLC Samsung, Hynix, Toshiba,
 * AMD/Spansion, and Macronix.  All others scan only the first page.
 */
-   if ((nand_is_slc(chip) &&
-(maf_id == NAND_MFR_AMD ||
- maf_id == NAND_MFR_MACRONIX)) ||
-   (mtd->writesize == 2048 && maf_id == NAND_MFR_MICRON))
+   if (nand_is_slc(chip) &&
+   (maf_id == NAND_MFR_AMD || maf_id == NAND_MFR_MACRONIX))
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
 }
 
diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index 509652c8e2..bb5ac8337f 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -195,7 +195,7 @@ struct nand_manufacturers nand_manuf_ids[] = {
{NAND_MFR_RENESAS, "Renesas"},
{NAND_MFR_STMICRO, "ST Micro"},
{NAND_MFR_HYNIX, "Hynix", _nand_manuf_ops},
-   {NAND_MFR_MICRON, "Micron"},
+   {NAND_MFR_MICRON, "Micron", _nand_manuf_ops},
{NAND_MFR_AMD, "AMD/Spansion"},
{NAND_MFR_MACRONIX, "Macronix"},
{NAND_MFR_EON, "Eon"},
diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
new file mode 100644
index 00..50426983ba
--- /dev/null
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Copyright (C) 2017 NextThing Co
+ *
+ * Author: Boris Brezillon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; 

[PATCH V2 08/13] mtd: nand: Move Toshiba specific init/detection logic in nand_toshiba.c

[Michael Trimarchi]

Upstream linux commit 9b2d61f80b

Move Toshiba specific initialization and detection logic into
nand_toshiba.c. This is part of the "separate vendor specific code from
core" cleanup process.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- adjust the include file in nand_toshiba
---
 drivers/mtd/nand/raw/Makefile   |  3 +-
 drivers/mtd/nand/raw/nand_base.c| 21 ++--
 drivers/mtd/nand/raw/nand_ids.c |  2 +-
 drivers/mtd/nand/raw/nand_toshiba.c | 52 +
 include/linux/mtd/rawnand.h |  1 +
 5 files changed, 58 insertions(+), 21 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_toshiba.c

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 294d131264..db608a2830 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
 obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
 obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
 obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
-obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_hynix.o nand_samsung.o
+obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_hynix.o nand_samsung.o 
nand_toshiba.o
 obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
 obj-$(CONFIG_TPL_NAND_INIT) += nand.o
 ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
@@ -33,6 +33,7 @@ obj-y += nand_ecc.o
 obj-y += nand_base.o
 obj-y += nand_hynix.o
 obj-y += nand_samsung.o
+obj-y += nand_toshiba.o
 obj-y += nand_timings.o
 
 endif # not spl
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 6ff1a2cb29..8c06b1c530 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4163,12 +4163,11 @@ static int nand_get_bits_per_cell(u8 cellinfo)
 void nand_decode_ext_id(struct nand_chip *chip)
 {
struct mtd_info *mtd = >mtd;
-   int extid, id_len;
+   int extid;
/* The 3rd id byte holds MLC / multichip data */
chip->bits_per_cell = nand_get_bits_per_cell(chip->id.data[2]);
/* The 4th id byte is the important one */
extid = chip->id.data[3];
-   id_len = chip->id.len;
 
/* Calc pagesize */
mtd->writesize = 1024 << (extid & 0x03);
@@ -4184,21 +4183,6 @@ void nand_decode_ext_id(struct nand_chip *chip)
/* Get buswidth information */
if (extid & 0x1)
chip->options |= NAND_BUSWIDTH_16;
-
-   /*
-* Toshiba 24nm raw SLC (i.e., not BENAND) have 32B OOB per
-* 512B page. For Toshiba SLC, we decode the 5th/6th byte as
-* follows:
-* - ID byte 6, bits[2:0]: 100b -> 43nm, 101b -> 32nm,
-* 110b -> 24nm
-* - ID byte 5, bit[7]:1 -> BENAND, 0 -> raw SLC
-*/
-   if (id_len >= 6 && chip->id.data[0] == NAND_MFR_TOSHIBA &&
-   nand_is_slc(chip) &&
-   (chip->id.data[5] & 0x7) == 0x6 /* 24nm */ &&
-   !(chip->id.data[4] & 0x80) /* !BENAND */) {
-   mtd->oobsize = 32 * mtd->writesize >> 9;
-   }
 }
 EXPORT_SYMBOL_GPL(nand_decode_ext_id);
 
@@ -4290,8 +4274,7 @@ static void nand_decode_bbm_options(struct mtd_info *mtd,
 * AMD/Spansion, and Macronix.  All others scan only the first page.
 */
if ((nand_is_slc(chip) &&
-(maf_id == NAND_MFR_TOSHIBA ||
- maf_id == NAND_MFR_AMD ||
+(maf_id == NAND_MFR_AMD ||
  maf_id == NAND_MFR_MACRONIX)) ||
(mtd->writesize == 2048 && maf_id == NAND_MFR_MICRON))
chip->bbt_options |= NAND_BBT_SCAN2NDPAGE;
diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
index ec263a4327..509652c8e2 100644
--- a/drivers/mtd/nand/raw/nand_ids.c
+++ b/drivers/mtd/nand/raw/nand_ids.c
@@ -188,7 +188,7 @@ struct nand_flash_dev nand_flash_ids[] = {
 
 /* Manufacturer IDs */
 struct nand_manufacturers nand_manuf_ids[] = {
-   {NAND_MFR_TOSHIBA, "Toshiba"},
+   {NAND_MFR_TOSHIBA, "Toshiba", _nand_manuf_ops},
{NAND_MFR_SAMSUNG, "Samsung", _nand_manuf_ops},
{NAND_MFR_FUJITSU, "Fujitsu"},
{NAND_MFR_NATIONAL, "National"},
diff --git a/drivers/mtd/nand/raw/nand_toshiba.c 
b/drivers/mtd/nand/raw/nand_toshiba.c
new file mode 100644
index 00..4328e566b0
--- /dev/null
+++ b/drivers/mtd/nand/raw/nand_toshiba.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Copyright (C) 2017 NextThing Co
+ *
+ * Author: Boris Brezillon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * 

[PATCH V2 07/13] mtd: nand: Move Hynix specific init/detection logic in nand_hynix.c

[Michael Trimarchi]

Upstream linux commit 01389b6bd2

Move Hynix specific initialization and detection logic into
nand_hynix.c. This is part of the "separate vendor specific code from
core" cleanup process.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- adjust the include file in nand_hynix
---
 drivers/mtd/nand/raw/Makefile |   3 +-
 drivers/mtd/nand/raw/nand_base.c  | 117 --
 drivers/mtd/nand/raw/nand_hynix.c |  84 +
 drivers/mtd/nand/raw/nand_ids.c   |   2 +-
 include/linux/mtd/rawnand.h   |   1 +
 5 files changed, 119 insertions(+), 88 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_hynix.c

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 0e3f017bf6..294d131264 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
 obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
 obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
 obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
-obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_samsung.o
+obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_hynix.o nand_samsung.o
 obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
 obj-$(CONFIG_TPL_NAND_INIT) += nand.o
 ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
@@ -31,6 +31,7 @@ obj-y += nand_ids.o
 obj-y += nand_util.o
 obj-y += nand_ecc.o
 obj-y += nand_base.o
+obj-y += nand_hynix.o
 obj-y += nand_samsung.o
 obj-y += nand_timings.o
 
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 7f41395afe..6ff1a2cb29 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4170,85 +4170,34 @@ void nand_decode_ext_id(struct nand_chip *chip)
extid = chip->id.data[3];
id_len = chip->id.len;
 
+   /* Calc pagesize */
+   mtd->writesize = 1024 << (extid & 0x03);
+   extid >>= 2;
+   /* Calc oobsize */
+   mtd->oobsize = (8 << (extid & 0x01)) *
+   (mtd->writesize >> 9);
+   extid >>= 2;
+   /* Calc blocksize. Blocksize is multiples of 64KiB */
+   mtd->erasesize = (64 * 1024) << (extid & 0x03);
+   extid >>= 2;
+   /* Get buswidth information */
+   /* Get buswidth information */
+   if (extid & 0x1)
+   chip->options |= NAND_BUSWIDTH_16;
+
/*
-* Field definitions are in the following datasheets:
-* Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
-* Hynix MLC   (6 byte ID): Hynix H27UBG8T2B (p.22)
-*
-* Check for ID length, non-zero 6th byte, cell type, and Hynix/Samsung
-* ID to decide what to do.
+* Toshiba 24nm raw SLC (i.e., not BENAND) have 32B OOB per
+* 512B page. For Toshiba SLC, we decode the 5th/6th byte as
+* follows:
+* - ID byte 6, bits[2:0]: 100b -> 43nm, 101b -> 32nm,
+* 110b -> 24nm
+* - ID byte 5, bit[7]:1 -> BENAND, 0 -> raw SLC
 */
-   if (id_len == 6 && chip->id.data[0] == NAND_MFR_HYNIX &&
-   !nand_is_slc(chip)) {
-   unsigned int tmp;
-
-   /* Calc pagesize */
-   mtd->writesize = 2048 << (extid & 0x03);
-   extid >>= 2;
-   /* Calc oobsize */
-   switch (((extid >> 2) & 0x04) | (extid & 0x03)) {
-   case 0:
-   mtd->oobsize = 128;
-   break;
-   case 1:
-   mtd->oobsize = 224;
-   break;
-   case 2:
-   mtd->oobsize = 448;
-   break;
-   case 3:
-   mtd->oobsize = 64;
-   break;
-   case 4:
-   mtd->oobsize = 32;
-   break;
-   case 5:
-   mtd->oobsize = 16;
-   break;
-   default:
-   mtd->oobsize = 640;
-   break;
-   }
-   extid >>= 2;
-   /* Calc blocksize */
-   tmp = ((extid >> 1) & 0x04) | (extid & 0x03);
-   if (tmp < 0x03)
-   mtd->erasesize = (128 * 1024) << tmp;
-   else if (tmp == 0x03)
-   mtd->erasesize = 768 * 1024;
-   else
-   mtd->erasesize = (64 * 1024) << tmp;
-   } else {
-   /* Calc pagesize */
-   mtd->writesize = 1024 << (extid & 0x03);
-   extid >>= 2;
-   /* Calc oobsize */
-   mtd->oobsize = (8 << (extid & 0x01)) *
-   (mtd->writesize >> 9);
-   extid >>= 2;
-   /* Calc blocksize. Blocksize is multiples of 64KiB */
- 

[PATCH V2 06/13] mtd: nand: Move Samsung specific init/detection logic in nand_samsung.c

[Michael Trimarchi]

Upstream linux commit c51d0ac59f

Move Samsung specific initialization and detection logic into
nand_samsung.c. This is part of the "separate vendor specific code from
core" cleanup process.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
- adjust the include file in nand_samsung
---
 drivers/mtd/nand/raw/Makefile   |  3 +-
 drivers/mtd/nand/raw/nand_base.c| 50 +---
 drivers/mtd/nand/raw/nand_ids.c |  4 +-
 drivers/mtd/nand/raw/nand_samsung.c | 89 +
 include/linux/mtd/rawnand.h |  2 +
 5 files changed, 98 insertions(+), 50 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_samsung.c

diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index e3f6b903f7..0e3f017bf6 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
 obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
 obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
 obj-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
-obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o
+obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_samsung.o
 obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
 obj-$(CONFIG_TPL_NAND_INIT) += nand.o
 ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
@@ -31,6 +31,7 @@ obj-y += nand_ids.o
 obj-y += nand_util.o
 obj-y += nand_ecc.o
 obj-y += nand_base.o
+obj-y += nand_samsung.o
 obj-y += nand_timings.o
 
 endif # not spl
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 4cb38378f4..7f41395afe 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4173,47 +4173,12 @@ void nand_decode_ext_id(struct nand_chip *chip)
/*
 * Field definitions are in the following datasheets:
 * Old style (4,5 byte ID): Samsung K9GAG08U0M (p.32)
-* New Samsung (6 byte ID): Samsung K9GAG08U0F (p.44)
 * Hynix MLC   (6 byte ID): Hynix H27UBG8T2B (p.22)
 *
 * Check for ID length, non-zero 6th byte, cell type, and Hynix/Samsung
 * ID to decide what to do.
 */
-   if (id_len == 6 && chip->id.data[0] == NAND_MFR_SAMSUNG &&
-   !nand_is_slc(chip) && chip->id.data[5] != 0x00) {
-   /* Calc pagesize */
-   mtd->writesize = 2048 << (extid & 0x03);
-   extid >>= 2;
-   /* Calc oobsize */
-   switch (((extid >> 2) & 0x04) | (extid & 0x03)) {
-   case 1:
-   mtd->oobsize = 128;
-   break;
-   case 2:
-   mtd->oobsize = 218;
-   break;
-   case 3:
-   mtd->oobsize = 400;
-   break;
-   case 4:
-   mtd->oobsize = 436;
-   break;
-   case 5:
-   mtd->oobsize = 512;
-   break;
-   case 6:
-   mtd->oobsize = 640;
-   break;
-   case 7:
-   default: /* Other cases are "reserved" (unknown) */
-   mtd->oobsize = 1024;
-   break;
-   }
-   extid >>= 2;
-   /* Calc blocksize */
-   mtd->erasesize = (128 * 1024) <<
-   (((extid >> 1) & 0x04) | (extid & 0x03));
-   } else if (id_len == 6 && chip->id.data[0] == NAND_MFR_HYNIX &&
+   if (id_len == 6 && chip->id.data[0] == NAND_MFR_HYNIX &&
!nand_is_slc(chip)) {
unsigned int tmp;
 
@@ -4375,13 +4340,10 @@ static void nand_decode_bbm_options(struct mtd_info 
*mtd,
 * Micron devices with 2KiB pages and on SLC Samsung, Hynix, Toshiba,
 * AMD/Spansion, and Macronix.  All others scan only the first page.
 */
-   if (!nand_is_slc(chip) &&
-   (maf_id == NAND_MFR_SAMSUNG ||
-maf_id == NAND_MFR_HYNIX))
+   if (!nand_is_slc(chip) && maf_id == NAND_MFR_HYNIX)
chip->bbt_options |= NAND_BBT_SCANLASTPAGE;
else if ((nand_is_slc(chip) &&
-   (maf_id == NAND_MFR_SAMSUNG ||
-maf_id == NAND_MFR_HYNIX ||
+   (maf_id == NAND_MFR_HYNIX ||
 maf_id == NAND_MFR_TOSHIBA ||
 maf_id == NAND_MFR_AMD ||
 maf_id == NAND_MFR_MACRONIX)) ||
@@ -4550,12 +4512,6 @@ struct nand_flash_dev *nand_get_flash_type(struct 
nand_chip *chip,
/* Get chip options */
chip->options |= type->options;
 
-   /*
-* Check if chip is not a Samsung device. Do not clear the
-* options for chips 

[PATCH V2 05/13] mtd: nand: Export symbol nand_decode_ext_id

[Michael Trimarchi]

In preparation of moving specific nand support that are not jedec
or onfi

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- no changes
---
 drivers/mtd/nand/raw/nand_base.c | 3 ++-
 include/linux/mtd/rawnand.h  | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 7d52372af5..4cb38378f4 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4160,7 +4160,7 @@ static int nand_get_bits_per_cell(u8 cellinfo)
  * chip. The rest of the parameters must be decoded according to generic or
  * manufacturer-specific "extended ID" decoding patterns.
  */
-static void nand_decode_ext_id(struct nand_chip *chip)
+void nand_decode_ext_id(struct nand_chip *chip)
 {
struct mtd_info *mtd = >mtd;
int extid, id_len;
@@ -4286,6 +4286,7 @@ static void nand_decode_ext_id(struct nand_chip *chip)
 
}
 }
+EXPORT_SYMBOL_GPL(nand_decode_ext_id);
 
 /*
  * Manufacturer detection. Only used when the NAND is not ONFI or JEDEC
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index d8141cb4d1..8fb2a43296 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1374,4 +1374,7 @@ int nand_read_data_op(struct nand_chip *chip, void *buf, 
unsigned int len,
 int nand_write_data_op(struct nand_chip *chip, const void *buf,
   unsigned int len, bool force_8bit);
 
+/* Default extended ID decoding function */
+void nand_decode_ext_id(struct nand_chip *chip);
+
 #endif /* __LINUX_MTD_RAWNAND_H */
-- 
2.34.1

[PATCH V2 04/13] mtd: nand: Get rid of mtd variable in function calls

[Michael Trimarchi]

chip points to mtd. Passing chip is enough to have a reference
to mtd when is necessary

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- no changes
---
 drivers/mtd/nand/raw/nand_base.c | 20 +++-
 include/linux/mtd/rawnand.h  |  3 +--
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 3b9c78cb24..7d52372af5 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4160,8 +4160,9 @@ static int nand_get_bits_per_cell(u8 cellinfo)
  * chip. The rest of the parameters must be decoded according to generic or
  * manufacturer-specific "extended ID" decoding patterns.
  */
-static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip)
+static void nand_decode_ext_id(struct nand_chip *chip)
 {
+   struct mtd_info *mtd = >mtd;
int extid, id_len;
/* The 3rd id byte holds MLC / multichip data */
chip->bits_per_cell = nand_get_bits_per_cell(chip->id.data[2]);
@@ -4291,7 +4292,7 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip)
  * compliant and does not have a full-id or legacy-id entry in the nand_ids
  * table.
  */
-static void nand_manufacturer_detect(struct mtd_info *mtd, struct nand_chip 
*chip)
+static void nand_manufacturer_detect(struct nand_chip *chip)
 {
/*
 * Try manufacturer detection if available and use
@@ -4301,7 +4302,7 @@ static void nand_manufacturer_detect(struct mtd_info 
*mtd, struct nand_chip *chi
chip->manufacturer.desc->ops->detect)
chip->manufacturer.desc->ops->detect(chip);
else
-   nand_decode_ext_id(mtd, chip);
+   nand_decode_ext_id(chip);
 }
 
 /*
@@ -4324,9 +4325,10 @@ static int nand_manufacturer_init(struct nand_chip *chip)
  * decodes a matching ID table entry and assigns the MTD size parameters for
  * the chip.
  */
-static void nand_decode_id(struct mtd_info *mtd, struct nand_chip *chip,
+static void nand_decode_id(struct nand_chip *chip,
struct nand_flash_dev *type)
 {
+   struct mtd_info *mtd = >mtd;
int maf_id = chip->id.data[0];
 
mtd->erasesize = type->erasesize;
@@ -4439,11 +4441,11 @@ static const struct nand_manufacturers 
*nand_get_manufacturer_desc(u8 id)
 /*
  * Get the flash and manufacturer id and lookup if the type is supported.
  */
-struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
- struct nand_chip *chip,
+struct nand_flash_dev *nand_get_flash_type(struct nand_chip *chip,
  int *maf_id, int *dev_id,
  struct nand_flash_dev *type)
 {
+   struct mtd_info *mtd = >mtd;
const struct nand_manufacturers *manufacturer_desc;
int busw, ret;
u8 *id_data = chip->id.data;
@@ -4539,9 +4541,9 @@ struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
chip->chipsize = (uint64_t)type->chipsize << 20;
 
if (!type->pagesize) {
-   nand_manufacturer_detect(mtd, chip);
+   nand_manufacturer_detect(chip);
} else {
-   nand_decode_id(mtd, chip, type);
+   nand_decode_id(chip, type);
}
 
/* Get chip options */
@@ -4731,7 +4733,7 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
 
/* Read the flash type */
-   type = nand_get_flash_type(mtd, chip, _maf_id,
+   type = nand_get_flash_type(chip, _maf_id,
   _dev_id, table);
 
if (IS_ERR(type)) {
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 57fe7fb47b..d8141cb4d1 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -29,8 +29,7 @@ struct nand_flash_dev;
 struct device_node;
 
 /* Get the flash and manufacturer id and lookup if the type is supported. */
-struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
-  struct nand_chip *chip,
+struct nand_flash_dev *nand_get_flash_type(struct nand_chip *chip,
   int *maf_id, int *dev_id,
   struct nand_flash_dev *type);
 
-- 
2.34.1

[PATCH V2 03/13] mtd: nand: Add manufacturer specific initialization/detection steps

[Michael Trimarchi]

Upstream linux commit abbe26d144

A lot of NANDs are implementing generic features in a non-generic way,
or are providing advanced auto-detection logic where the NAND ID bytes
meaning changes with the NAND generation.

Providing this vendor specific initialization step will allow us to get
rid of full-id entries in the nand_ids table or all the vendor specific
cases added over the time in the generic NAND ID decoding logic.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
---
 drivers/mtd/nand/raw/nand_base.c | 90 +---
 include/linux/mtd/rawnand.h  | 30 +++
 2 files changed, 102 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 4a78770a25..3b9c78cb24 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4286,6 +4286,39 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip)
}
 }
 
+/*
+ * Manufacturer detection. Only used when the NAND is not ONFI or JEDEC
+ * compliant and does not have a full-id or legacy-id entry in the nand_ids
+ * table.
+ */
+static void nand_manufacturer_detect(struct mtd_info *mtd, struct nand_chip 
*chip)
+{
+   /*
+* Try manufacturer detection if available and use
+* nand_decode_ext_id() otherwise.
+*/
+   if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
+   chip->manufacturer.desc->ops->detect)
+   chip->manufacturer.desc->ops->detect(chip);
+   else
+   nand_decode_ext_id(mtd, chip);
+}
+
+/*
+ * Manufacturer initialization. This function is called for all NANDs including
+ * ONFI and JEDEC compliant ones.
+ * Manufacturer drivers should put all their specific initialization code in
+ * their ->init() hook.
+ */
+static int nand_manufacturer_init(struct nand_chip *chip)
+{
+   if (!chip->manufacturer.desc || !chip->manufacturer.desc->ops ||
+   !chip->manufacturer.desc->ops->init)
+   return 0;
+
+   return chip->manufacturer.desc->ops->init(chip);
+}
+
 /*
  * Old devices have chip data hardcoded in the device ID table. nand_decode_id
  * decodes a matching ID table entry and assigns the MTD size parameters for
@@ -4383,6 +4416,26 @@ static bool find_full_id_nand(struct mtd_info *mtd, 
struct nand_chip *chip,
return false;
 }
 
+/**
+ * nand_get_manufacturer_desc - Get manufacturer information from the
+ *  manufacturer ID
+ * @id: manufacturer ID
+ *
+ * Returns a nand_manufacturer_desc object if the manufacturer is defined
+ * in the NAND manufacturers database, NULL otherwise.
+ */
+static const struct nand_manufacturers *nand_get_manufacturer_desc(u8 id)
+{
+   int i;
+
+   for (i = 0; nand_manuf_ids[i].id != 0x0; i++) {
+   if (nand_manuf_ids[i].id == id)
+   return _manuf_ids[i];
+   }
+
+   return NULL;
+}
+
 /*
  * Get the flash and manufacturer id and lookup if the type is supported.
  */
@@ -4391,8 +,8 @@ struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
  int *maf_id, int *dev_id,
  struct nand_flash_dev *type)
 {
+   const struct nand_manufacturers *manufacturer_desc;
int busw, ret;
-   int maf_idx;
u8 *id_data = chip->id.data;
 
/*
@@ -4433,6 +4486,12 @@ struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
return ERR_PTR(-ENODEV);
}
 
+   chip->id.len = nand_id_len(id_data, ARRAY_SIZE(chip->id.data));
+
+   /* Try to identify manufacturer */
+   manufacturer_desc = nand_get_manufacturer_desc(*maf_id);
+   chip->manufacturer.desc = manufacturer_desc;
+
if (!type)
type = nand_flash_ids;
 
@@ -4451,8 +4510,6 @@ struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
 */
chip->options &= ~NAND_BUSWIDTH_16;
 
-   chip->id.len = nand_id_len(id_data, ARRAY_SIZE(chip->id.data));
-
for (; type->name != NULL; type++) {
if (is_full_id_nand(type)) {
if (find_full_id_nand(mtd, chip, type))
@@ -4482,8 +4539,7 @@ struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
chip->chipsize = (uint64_t)type->chipsize << 20;
 
if (!type->pagesize) {
-   /* Decode parameters from extended ID */
-   nand_decode_ext_id(mtd, chip);
+   nand_manufacturer_detect(mtd, chip);
} else {
nand_decode_id(mtd, chip, type);
}
@@ -4499,12 +4555,6 @@ struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
chip->options &= ~NAND_SAMSUNG_LP_OPTIONS;
 ident_done:
 
-   /* Try to identify 

[PATCH V2 02/13] mtd: nand: Store nand ID in struct nand_chip

[Michael Trimarchi]

Upstream linux commit 7f501f0a72

Store the NAND ID in struct nand_chip to avoid passing id_data and id_len
as function parameters.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
---
 drivers/mtd/nand/raw/nand_base.c | 54 
 include/linux/mtd/rawnand.h  | 15 +
 2 files changed, 42 insertions(+), 27 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 9a2194ebd3..4a78770a25 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4160,16 +4160,14 @@ static int nand_get_bits_per_cell(u8 cellinfo)
  * chip. The rest of the parameters must be decoded according to generic or
  * manufacturer-specific "extended ID" decoding patterns.
  */
-static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip,
-   u8 id_data[8])
+static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip)
 {
int extid, id_len;
/* The 3rd id byte holds MLC / multichip data */
-   chip->bits_per_cell = nand_get_bits_per_cell(id_data[2]);
+   chip->bits_per_cell = nand_get_bits_per_cell(chip->id.data[2]);
/* The 4th id byte is the important one */
-   extid = id_data[3];
-
-   id_len = nand_id_len(id_data, 8);
+   extid = chip->id.data[3];
+   id_len = chip->id.len;
 
/*
 * Field definitions are in the following datasheets:
@@ -4180,8 +4178,8 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
 * Check for ID length, non-zero 6th byte, cell type, and Hynix/Samsung
 * ID to decide what to do.
 */
-   if (id_len == 6 && id_data[0] == NAND_MFR_SAMSUNG &&
-   !nand_is_slc(chip) && id_data[5] != 0x00) {
+   if (id_len == 6 && chip->id.data[0] == NAND_MFR_SAMSUNG &&
+   !nand_is_slc(chip) && chip->id.data[5] != 0x00) {
/* Calc pagesize */
mtd->writesize = 2048 << (extid & 0x03);
extid >>= 2;
@@ -4214,7 +4212,7 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
/* Calc blocksize */
mtd->erasesize = (128 * 1024) <<
(((extid >> 1) & 0x04) | (extid & 0x03));
-   } else if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX &&
+   } else if (id_len == 6 && chip->id.data[0] == NAND_MFR_HYNIX &&
!nand_is_slc(chip)) {
unsigned int tmp;
 
@@ -4278,10 +4276,10 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
 * 110b -> 24nm
 * - ID byte 5, bit[7]:1 -> BENAND, 0 -> raw SLC
 */
-   if (id_len >= 6 && id_data[0] == NAND_MFR_TOSHIBA &&
+   if (id_len >= 6 && chip->id.data[0] == NAND_MFR_TOSHIBA &&
nand_is_slc(chip) &&
-   (id_data[5] & 0x7) == 0x6 /* 24nm */ &&
-   !(id_data[4] & 0x80) /* !BENAND */) {
+   (chip->id.data[5] & 0x7) == 0x6 /* 24nm */ &&
+   !(chip->id.data[4] & 0x80) /* !BENAND */) {
mtd->oobsize = 32 * mtd->writesize >> 9;
}
 
@@ -4294,9 +4292,9 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
  * the chip.
  */
 static void nand_decode_id(struct mtd_info *mtd, struct nand_chip *chip,
-   struct nand_flash_dev *type, u8 id_data[8])
+   struct nand_flash_dev *type)
 {
-   int maf_id = id_data[0];
+   int maf_id = chip->id.data[0];
 
mtd->erasesize = type->erasesize;
mtd->writesize = type->pagesize;
@@ -4311,11 +4309,11 @@ static void nand_decode_id(struct mtd_info *mtd, struct 
nand_chip *chip,
 * listed in nand_ids table.
 * Data sheet (5 byte ID): Spansion S30ML-P ORNAND (p.39)
 */
-   if (maf_id == NAND_MFR_AMD && id_data[4] != 0x00 && id_data[5] == 0x00
-   && id_data[6] == 0x00 && id_data[7] == 0x00
+   if (maf_id == NAND_MFR_AMD && chip->id.data[4] != 0x00 && 
chip->id.data[5] == 0x00
+   && chip->id.data[6] == 0x00 && chip->id.data[7] == 0x00
&& mtd->writesize == 512) {
mtd->erasesize = 128 * 1024;
-   mtd->erasesize <<= ((id_data[3] & 0x03) << 1);
+   mtd->erasesize <<= ((chip->id.data[3] & 0x03) << 1);
}
 }
 
@@ -4325,9 +4323,9 @@ static void nand_decode_id(struct mtd_info *mtd, struct 
nand_chip *chip,
  * page size, cell-type information).
  */
 static void nand_decode_bbm_options(struct mtd_info *mtd,
- 

[PATCH V2 01/13] mtd: nand: Get rid of busw parameter

[Michael Trimarchi]

Upstream linux commit 29a198a159

Auto-detection functions are passed a busw parameter to retrieve the actual
NAND bus width and eventually set the correct value in chip->options.
Rework the nand_get_flash_type() function to get rid of this extra
parameter and let detection code directly set the NAND_BUSWIDTH_16 flag in
chip->options if needed.

Signed-off-by: Michael Trimarchi 
---
V1->V2:
- use short-commit form
- remove linux info. Uboot seems that backport without add this
  extra information
---
 drivers/mtd/nand/raw/nand_base.c | 59 +---
 1 file changed, 32 insertions(+), 27 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index e8ece0a4a0..9a2194ebd3 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -3898,8 +3898,7 @@ static void nand_onfi_detect_micron(struct nand_chip 
*chip,
 /*
  * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
  */
-static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
-   int *busw)
+static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip)
 {
struct nand_onfi_params *p = >onfi_params;
char id[4];
@@ -3971,9 +3970,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
chip->bits_per_cell = p->bits_per_cell;
 
if (onfi_feature(chip) & ONFI_FEATURE_16_BIT_BUS)
-   *busw = NAND_BUSWIDTH_16;
-   else
-   *busw = 0;
+   chip->options |= NAND_BUSWIDTH_16;
 
if (p->ecc_bits != 0xff) {
chip->ecc_strength_ds = p->ecc_bits;
@@ -4003,8 +4000,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
return 1;
 }
 #else
-static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
-   int *busw)
+static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip)
 {
return 0;
 }
@@ -4013,8 +4009,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, 
struct nand_chip *chip,
 /*
  * Check if the NAND chip is JEDEC compliant, returns 1 if it is, 0 otherwise.
  */
-static int nand_flash_detect_jedec(struct mtd_info *mtd, struct nand_chip 
*chip,
-   int *busw)
+static int nand_flash_detect_jedec(struct mtd_info *mtd, struct nand_chip 
*chip)
 {
struct nand_jedec_params *p = >jedec_params;
struct jedec_ecc_info *ecc;
@@ -4076,9 +4071,7 @@ static int nand_flash_detect_jedec(struct mtd_info *mtd, 
struct nand_chip *chip,
chip->bits_per_cell = p->bits_per_cell;
 
if (jedec_feature(chip) & JEDEC_FEATURE_16_BIT_BUS)
-   *busw = NAND_BUSWIDTH_16;
-   else
-   *busw = 0;
+   chip->options |= NAND_BUSWIDTH_16;
 
/* ECC info */
ecc = >ecc_info[0];
@@ -4168,7 +4161,7 @@ static int nand_get_bits_per_cell(u8 cellinfo)
  * manufacturer-specific "extended ID" decoding patterns.
  */
 static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip,
-   u8 id_data[8], int *busw)
+   u8 id_data[8])
 {
int extid, id_len;
/* The 3rd id byte holds MLC / multichip data */
@@ -4221,7 +4214,6 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
/* Calc blocksize */
mtd->erasesize = (128 * 1024) <<
(((extid >> 1) & 0x04) | (extid & 0x03));
-   *busw = 0;
} else if (id_len == 6 && id_data[0] == NAND_MFR_HYNIX &&
!nand_is_slc(chip)) {
unsigned int tmp;
@@ -4262,7 +4254,6 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
mtd->erasesize = 768 * 1024;
else
mtd->erasesize = (64 * 1024) << tmp;
-   *busw = 0;
} else {
/* Calc pagesize */
mtd->writesize = 1024 << (extid & 0x03);
@@ -4275,7 +4266,9 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
mtd->erasesize = (64 * 1024) << (extid & 0x03);
extid >>= 2;
/* Get buswidth information */
-   *busw = (extid & 0x01) ? NAND_BUSWIDTH_16 : 0;
+   /* Get buswidth information */
+   if (extid & 0x1)
+   chip->options |= NAND_BUSWIDTH_16;
 
/*
 * Toshiba 24nm raw SLC (i.e., not BENAND) have 32B OOB per
@@ -4301,15 +4294,13 @@ static void nand_decode_ext_id(struct mtd_info *mtd, 
struct nand_chip *chip,
  * the chip.
  */
 static void nand_decode_id(struct mtd_info *mtd, struct nand_chip *chip,
-   struct nand_flash_dev 

[PATCH V2 00/13] Port manufacturer specific initialization

[Michael Trimarchi]

In preparation of re-sync of mtd stack, we opt to move the current stack
slowly in order to have a more easy sync and test. We would like to
prepare uboot to support no-jedec and no-onfi compliant nand so we need
to clean up a bit the code we have now and upstream some of the support.
In this series we expect no functional change

Tested on:
- imx6ull Micron MT29F2G08ABAGAH4

Michael Trimarchi (13):
  mtd: nand: Get rid of busw parameter
  mtd: nand: Store nand ID in struct nand_chip
  mtd: nand: Add manufacturer specific initialization/detection steps
  mtd: nand: Get rid of mtd variable in function calls
  mtd: nand: Export symbol nand_decode_ext_id
  mtd: nand: Move Samsung specific init/detection logic in
nand_samsung.c
  mtd: nand: Move Hynix specific init/detection logic in nand_hynix.c
  mtd: nand: Move Toshiba specific init/detection logic in
nand_toshiba.c
  mtd: nand: Move Micron specific init logic in nand_micron.c
  mtd: nand: Move AMD/Spansion specific init/detection logic in
nand_amd.c
  mtd: nand: Move Macronix specific initialization in nand_macronix.c
  mtd: nand: toshiba: Retrieve ECC requirements from extended ID
  mtd: decommission the NAND museum

 drivers/mtd/nand/raw/Makefile|  10 +-
 drivers/mtd/nand/raw/nand_amd.c  |  51 
 drivers/mtd/nand/raw/nand_base.c | 359 ++-
 drivers/mtd/nand/raw/nand_hynix.c|  84 +++
 drivers/mtd/nand/raw/nand_ids.c  |  24 +-
 drivers/mtd/nand/raw/nand_macronix.c |  30 +++
 drivers/mtd/nand/raw/nand_micron.c   |  86 +++
 drivers/mtd/nand/raw/nand_samsung.c  |  89 +++
 drivers/mtd/nand/raw/nand_toshiba.c  |  78 ++
 include/linux/mtd/rawnand.h  |  78 --
 10 files changed, 615 insertions(+), 274 deletions(-)
 create mode 100644 drivers/mtd/nand/raw/nand_amd.c
 create mode 100644 drivers/mtd/nand/raw/nand_hynix.c
 create mode 100644 drivers/mtd/nand/raw/nand_macronix.c
 create mode 100644 drivers/mtd/nand/raw/nand_micron.c
 create mode 100644 drivers/mtd/nand/raw/nand_samsung.c
 create mode 100644 drivers/mtd/nand/raw/nand_toshiba.c

-- 
2.34.1

Re: Pull request: u-boot-sunxi/master for v2022.10

[Tom Rini]

On Tue, Jul 19, 2022 at 02:51:02PM +0100, Andre Przywara wrote:

> Hi Tom,
> 
> please pull the sunxi/master branch, containing the first part of the
> 2022.10 changes.
> 
> One prominent feature is the restructering of the clock driver, which
> allows to end up with one actual driver for all variants, although we
> still only compile in support for one SoC.
> Also contained are some initial SPI fixes, which should fix some
> problems, and enable SPI flash support for the F1C100s SoC. Those
> patches revealed more problems, I will queue fixes later on, but for
> now it should at least still work.
> Apart from some smaller fixes (for instance for NAND operation), there
> is also preparation for the upcoming Allwinner D1 support, in form of
> the USB PHY driver. There are more driver support patches to come.
> 
> The gitlab CI completed successfully, including the build test for all
> 160 sunxi boards. I also boot tested on a few boards, but didn't have
> time for more elaborate tests this time.
> 
> Thanks,
> Andre
> 
> ===
> The following changes since commit 26f6f7fb5c0651d65afdee6d8ed36063606179a8:
> 
>   Merge branch '2022-07-14-migrate-wiki-to-sphinx' (2022-07-14 18:43:51 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> 
> for you to fetch changes up to 25ba5be1c2b6324917254f0c22df1ad9d3d3c9e7:
> 
>   phy: sun4i-usb: Add D1 variant (2022-07-18 23:48:37 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[RFC PATCH] mtd: Fix building when CONFIG_DM is not enabled

[Michael Trimarchi]

I really don't find any consumer of those functions in uboot. 
You can only verify if you include nand.h it in no-dm build

include/linux/mtd/nand.h: In function 'nanddev_set_ofnode':
+include/linux/mtd/nand.h:426:9: error: implicit declaration of function 
'mtd_set_ofnode'; did you mean 'mtd_set_of_node'? 
[-Werror=implicit-function-declaration]
+  426 | mtd_set_ofnode(nand->mtd, node);
+  | ^~
+  | mtd_set_of_node
+cc1: all warnings being treated as errors

Cc: Simon Glass 
Signed-off-by: Michael Trimarchi 
---
 include/linux/mtd/mtd.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index ff635bd716..6c096ae665 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -343,14 +343,11 @@ static inline const ofnode mtd_get_ofnode(struct mtd_info 
*mtd)
return dev_ofnode(mtd->dev);
 }
 #else
-struct device_node;
-
-static inline void mtd_set_of_node(struct mtd_info *mtd,
-  const struct device_node *np)
+static inline void mtd_set_ofnode(struct mtd_info *mtd, ofnode node)
 {
 }
 
-static inline const struct device_node *mtd_get_of_node(struct mtd_info *mtd)
+static inline const ofnode *mtd_get_ofnode(struct mtd_info *mtd)
 {
return NULL;
 }
-- 
2.34.1

Re: [PATCH 2/2] tools: kwboot: use pkg-config to get -ltinfo

[Pali Rohár]

On Tuesday 19 July 2022 20:38:39 Heiko Thiery wrote:
> Instead of hardcoding -ltinfo as the flags needed to build
> kwboot, use pkg-config when available.
> 
> We gracefully fallback on the previous behavior of hardcoding -ltinfo
> if pkg-config is not available or fails with an error.
> 
> Signed-off-by: Heiko Thiery 

So... in current form this patch is OK.

Reviewed-by: Pali Rohár 

> ---
>  tools/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f6b282ad8..45195a8ce7 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -198,7 +198,9 @@ hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
>  HOSTCFLAGS_mkexynosspl.o := -pedantic
>  
>  HOSTCFLAGS_kwboot.o += -pthread
> -HOSTLDLIBS_kwboot += -pthread -ltinfo
> +HOSTLDLIBS_kwboot += -pthread
> +HOSTLDLIBS_kwboot += \
> + $(shell pkg-config --libs tinfo 2> /dev/null || echo "-ltinfo")
>  
>  ifdtool-objs := $(LIBFDT_OBJS) ifdtool.o
>  hostprogs-$(CONFIG_X86) += ifdtool
> -- 
> 2.30.2
> 

Re: [PATCH 2/2] tools: kwboot: use pkg-config to get -ltinfo

[Pali Rohár]

On Tuesday 19 July 2022 21:11:21 Heiko Thiery wrote:
> Hi,
> 
> Am Di., 19. Juli 2022 um 20:52 Uhr schrieb Pali Rohár :
> >
> > On Tuesday 19 July 2022 20:38:39 Heiko Thiery wrote:
> > > Instead of hardcoding -ltinfo as the flags needed to build
> > > kwboot, use pkg-config when available.
> >
> > Interesting, I did not know that there is pc file also for tinfo.
> > Anyway when using it, there should be also HOSTCFLAGS_kwboot definition
> > from pkg-config.
> 
> Just checked the cflags for tinfo.
> 
> # pkg-config --cflags tinfo
> -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600

I think these two flags are harmless...

> Can we also add that to kwboot?

... but now it reminds me that we have issues with tinfo header files
which are in direct conflict with linux uapi termbits header files.
And so kwboot.c does not include any tinfo header file.

Therefore tinfo cflags are not used at all.

So I would rather stick with not importing --cflags to prevent possible
future incompatibility (in case into tinfo cflags in future would be
added something which conflict with linux uapi header files). We do not
need them at all.

> >
> > > We gracefully fallback on the previous behavior of hardcoding -ltinfo
> > > if pkg-config is not available or fails with an error.
> > >
> > > Signed-off-by: Heiko Thiery 
> > > ---
> > >  tools/Makefile | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/Makefile b/tools/Makefile
> > > index 9f6b282ad8..45195a8ce7 100644
> > > --- a/tools/Makefile
> > > +++ b/tools/Makefile
> > > @@ -198,7 +198,9 @@ hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
> > >  HOSTCFLAGS_mkexynosspl.o := -pedantic
> > >
> > >  HOSTCFLAGS_kwboot.o += -pthread
> > > -HOSTLDLIBS_kwboot += -pthread -ltinfo
> > > +HOSTLDLIBS_kwboot += -pthread
> > > +HOSTLDLIBS_kwboot += \
> > > + $(shell pkg-config --libs tinfo 2> /dev/null || echo "-ltinfo")
> > >
> > >  ifdtool-objs := $(LIBFDT_OBJS) ifdtool.o
> > >  hostprogs-$(CONFIG_X86) += ifdtool
> > > --
> > > 2.30.2
> > >
> 
> --
> Heiko

[PATCH v2 2/2] tools: kwboot: use pkg-config to get -ltinfo

[Heiko Thiery]

Instead of hardcoding -ltinfo as the flags needed to build
kwboot, use pkg-config when available.

We gracefully fallback on the previous behavior of hardcoding -ltinfo
if pkg-config is not available or fails with an error.

Signed-off-by: Heiko Thiery 
---
v2:
 - also add cflags detection via pkg-config (Thanks Pali)

 tools/Makefile | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index aab06aec93..55d7ea7476 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -198,7 +198,11 @@ hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
 HOSTCFLAGS_mkexynosspl.o := -pedantic
 
 HOSTCFLAGS_kwboot.o += -pthread
-HOSTLDLIBS_kwboot += -pthread -ltinfo
+HOSTCFLAGS_kwboot.o += \
+   $(shell pkg-config --cflags tinfo 2> /dev/null || echo "")
+HOSTLDLIBS_kwboot += -pthread
+HOSTLDLIBS_kwboot += \
+   $(shell pkg-config --libs tinfo 2> /dev/null || echo "-ltinfo")
 
 ifdtool-objs := $(LIBFDT_OBJS) ifdtool.o
 hostprogs-$(CONFIG_X86) += ifdtool
-- 
2.30.2

[PATCH v2 1/2] tools: mkeficapsule: use pkg-config to get -luuid and -lgnutls

[Heiko Thiery]

Instead of hardcoding -luuid -lgnutls as the flags needed to build
mkeficapsule, use pkg-config when available.

We gracefully fallback on the previous behavior of hardcoding -luuid
-lgnutls if pkg-config is not available or fails with an error.

Signed-off-by: Heiko Thiery 
---
v2:
 - also add cflags detection via pkg-config (Thanks Pali)

 tools/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 9f2339666a..aab06aec93 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -242,7 +242,10 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
 hostprogs-$(CONFIG_ASN1_COMPILER)  += asn1_compiler
 HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
 
-HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
+HOSTCFLAGS_mkeficapsule.o += \
+   $(shell pkg-config --cflags gnutls uuid 2> /dev/null || echo "")
+HOSTLDLIBS_mkeficapsule += \
+   $(shell pkg-config --libs gnutls uuid 2> /dev/null || echo "-lgnutls 
-luuid")
 hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
 
 # We build some files with extra pedantic flags to try to minimize things
-- 
2.30.2

Re: [PATCH 1/2] tools: mkeficapsule: use pkg-config to get -luuid and -lgnutls

[Heiko Thiery]

Hi,

Am Di., 19. Juli 2022 um 20:51 Uhr schrieb Pali Rohár :
>
> On Tuesday 19 July 2022 20:38:37 Heiko Thiery wrote:
> > Instead of hardcoding -luuid -lgnutls as the flags needed to build
> > mkeficapsule, use pkg-config when available.
> >
> > We gracefully fallback on the previous behavior of hardcoding -luuid
> > -lgnutls if pkg-config is not available or fails with an error.
> >
> > Signed-off-by: Heiko Thiery 
> > ---
> >  tools/Makefile | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 9f2339666a..9f6b282ad8 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -242,7 +242,8 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
> >  hostprogs-$(CONFIG_ASN1_COMPILER)+= asn1_compiler
> >  HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
> >
> > -HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
> > +HOSTLDLIBS_mkeficapsule += \
> > + $(shell pkg-config --libs gnutls uuid 2> /dev/null || echo "-lgnutls 
> > -luuid")
>
> When using pkg-config then you should add also --cflags into HOSTCFLAGS_

Will add the cflags accordingly.

> >  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> >
> >  # We build some files with extra pedantic flags to try to minimize things
> > --
> > 2.30.2
> >

Re: [PATCH 2/2] tools: kwboot: use pkg-config to get -ltinfo

[Heiko Thiery]

Hi,

Am Di., 19. Juli 2022 um 20:52 Uhr schrieb Pali Rohár :
>
> On Tuesday 19 July 2022 20:38:39 Heiko Thiery wrote:
> > Instead of hardcoding -ltinfo as the flags needed to build
> > kwboot, use pkg-config when available.
>
> Interesting, I did not know that there is pc file also for tinfo.
> Anyway when using it, there should be also HOSTCFLAGS_kwboot definition
> from pkg-config.

Just checked the cflags for tinfo.

# pkg-config --cflags tinfo
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600

Can we also add that to kwboot?

>
> > We gracefully fallback on the previous behavior of hardcoding -ltinfo
> > if pkg-config is not available or fails with an error.
> >
> > Signed-off-by: Heiko Thiery 
> > ---
> >  tools/Makefile | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 9f6b282ad8..45195a8ce7 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -198,7 +198,9 @@ hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
> >  HOSTCFLAGS_mkexynosspl.o := -pedantic
> >
> >  HOSTCFLAGS_kwboot.o += -pthread
> > -HOSTLDLIBS_kwboot += -pthread -ltinfo
> > +HOSTLDLIBS_kwboot += -pthread
> > +HOSTLDLIBS_kwboot += \
> > + $(shell pkg-config --libs tinfo 2> /dev/null || echo "-ltinfo")
> >
> >  ifdtool-objs := $(LIBFDT_OBJS) ifdtool.o
> >  hostprogs-$(CONFIG_X86) += ifdtool
> > --
> > 2.30.2
> >

--
Heiko

Re: [PATCH 1/2] tools: mkeficapsule: use pkg-config to get -luuid and -lgnutls

[Heinrich Schuchardt]

On 7/19/22 20:38, Heiko Thiery wrote:

Instead of hardcoding -luuid -lgnutls as the flags needed to build
mkeficapsule, use pkg-config when available.

We gracefully fallback on the previous behavior of hardcoding -luuid
-lgnutls if pkg-config is not available or fails with an error.

Signed-off-by: Heiko Thiery 
---
  tools/Makefile | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 9f2339666a..9f6b282ad8 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -242,7 +242,8 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
  hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
  HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include

-HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
+HOSTLDLIBS_mkeficapsule += \
+   $(shell pkg-config --libs gnutls uuid 2> /dev/null || echo "-lgnutls 
-luuid")
  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule

  # We build some files with extra pedantic flags to try to minimize things


We already do the same for mkimage build flags.

Reviewed-by: Heinrich Schuchardt 

[PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit 26f6f7fb5c0651d65afdee6d8ed36063606179a8:

  Merge branch '2022-07-14-migrate-wiki-to-sphinx' (2022-07-14 18:43:51 
-0400)


are available in the Git repository at:

  git://source.denx.de/u-boot-usb.git master

for you to fetch changes up to 9674c09b7495d15017b68a3d462b17040c12ff70:

  musb: sunxi: Allow host-side USB with external VBUS (2022-07-15 
14:10:39 +0200)



Angus Ainslie (2):
  usb: dwc3: add a SPL_USB_DWC3_GENERIC option for the dwc3 driver
  configs: get rid of build warnings due to SPL_USB_DWC3_GENERIC

Samuel Holland (1):
  musb: sunxi: Allow host-side USB with external VBUS

 configs/am43xx_evm_defconfig  | 2 ++
 configs/am43xx_evm_usbhost_boot_defconfig | 2 ++
 configs/am43xx_hs_evm_defconfig   | 2 ++
 configs/am57xx_hs_evm_usb_defconfig   | 2 ++
 configs/am65x_evm_a53_defconfig   | 2 ++
 configs/am65x_evm_r5_usbdfu_defconfig | 2 ++
 configs/dra7xx_evm_defconfig  | 2 ++
 configs/dra7xx_hs_evm_defconfig   | 2 ++
 configs/dra7xx_hs_evm_usb_defconfig   | 2 ++
 drivers/usb/dwc3/Kconfig  | 7 +++
 drivers/usb/dwc3/Makefile | 2 +-
 drivers/usb/musb-new/sunxi.c  | 6 --
 12 files changed, 26 insertions(+), 7 deletions(-)

Re: [PATCH 2/2] tools: kwboot: use pkg-config to get -ltinfo

[Pali Rohár]

On Tuesday 19 July 2022 20:38:39 Heiko Thiery wrote:
> Instead of hardcoding -ltinfo as the flags needed to build
> kwboot, use pkg-config when available.

Interesting, I did not know that there is pc file also for tinfo.
Anyway when using it, there should be also HOSTCFLAGS_kwboot definition
from pkg-config.

> We gracefully fallback on the previous behavior of hardcoding -ltinfo
> if pkg-config is not available or fails with an error.
> 
> Signed-off-by: Heiko Thiery 
> ---
>  tools/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f6b282ad8..45195a8ce7 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -198,7 +198,9 @@ hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
>  HOSTCFLAGS_mkexynosspl.o := -pedantic
>  
>  HOSTCFLAGS_kwboot.o += -pthread
> -HOSTLDLIBS_kwboot += -pthread -ltinfo
> +HOSTLDLIBS_kwboot += -pthread
> +HOSTLDLIBS_kwboot += \
> + $(shell pkg-config --libs tinfo 2> /dev/null || echo "-ltinfo")
>  
>  ifdtool-objs := $(LIBFDT_OBJS) ifdtool.o
>  hostprogs-$(CONFIG_X86) += ifdtool
> -- 
> 2.30.2
> 

Re: [PATCH 1/2] tools: mkeficapsule: use pkg-config to get -luuid and -lgnutls

[Pali Rohár]

On Tuesday 19 July 2022 20:38:37 Heiko Thiery wrote:
> Instead of hardcoding -luuid -lgnutls as the flags needed to build
> mkeficapsule, use pkg-config when available.
> 
> We gracefully fallback on the previous behavior of hardcoding -luuid
> -lgnutls if pkg-config is not available or fails with an error.
> 
> Signed-off-by: Heiko Thiery 
> ---
>  tools/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f2339666a..9f6b282ad8 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -242,7 +242,8 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
>  hostprogs-$(CONFIG_ASN1_COMPILER)+= asn1_compiler
>  HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
>  
> -HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
> +HOSTLDLIBS_mkeficapsule += \
> + $(shell pkg-config --libs gnutls uuid 2> /dev/null || echo "-lgnutls 
> -luuid")

When using pkg-config then you should add also --cflags into HOSTCFLAGS_

>  hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
>  
>  # We build some files with extra pedantic flags to try to minimize things
> -- 
> 2.30.2
> 

[PATCH 2/2] tools: kwboot: use pkg-config to get -ltinfo

[Heiko Thiery]

Instead of hardcoding -ltinfo as the flags needed to build
kwboot, use pkg-config when available.

We gracefully fallback on the previous behavior of hardcoding -ltinfo
if pkg-config is not available or fails with an error.

Signed-off-by: Heiko Thiery 
---
 tools/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 9f6b282ad8..45195a8ce7 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -198,7 +198,9 @@ hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
 HOSTCFLAGS_mkexynosspl.o := -pedantic
 
 HOSTCFLAGS_kwboot.o += -pthread
-HOSTLDLIBS_kwboot += -pthread -ltinfo
+HOSTLDLIBS_kwboot += -pthread
+HOSTLDLIBS_kwboot += \
+   $(shell pkg-config --libs tinfo 2> /dev/null || echo "-ltinfo")
 
 ifdtool-objs := $(LIBFDT_OBJS) ifdtool.o
 hostprogs-$(CONFIG_X86) += ifdtool
-- 
2.30.2

[PATCH 1/2] tools: mkeficapsule: use pkg-config to get -luuid and -lgnutls

[Heiko Thiery]

Instead of hardcoding -luuid -lgnutls as the flags needed to build
mkeficapsule, use pkg-config when available.

We gracefully fallback on the previous behavior of hardcoding -luuid
-lgnutls if pkg-config is not available or fails with an error.

Signed-off-by: Heiko Thiery 
---
 tools/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 9f2339666a..9f6b282ad8 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -242,7 +242,8 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
 hostprogs-$(CONFIG_ASN1_COMPILER)  += asn1_compiler
 HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
 
-HOSTLDLIBS_mkeficapsule += -lgnutls -luuid
+HOSTLDLIBS_mkeficapsule += \
+   $(shell pkg-config --libs gnutls uuid 2> /dev/null || echo "-lgnutls 
-luuid")
 hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
 
 # We build some files with extra pedantic flags to try to minimize things
-- 
2.30.2

Re: u-boot and IPv6

[Dhananjay Phadke]

On Wed, 13 Jul 2022, Chris Packham wrote:

> On Tue, Jul 12, 2022 at 7:40 PM Chris Packham  wrote:
>>
>> Hi Sean and Dhananjay,
>>
>> Adding U-Boot ML to the Cc
>>

[...]

>>
>> IPv6 support is definitely something I want to get landed in upstream U-Boot.
>>
>> It seemed to be fairly well received last time I posted the series. The main 
>> thing lacking was tests. That's pretty much where things were at last time I 
>> touched it. As usual life and work commitments have stopped me from 
>> progressing it further.
>>
>> In the meantime U-Boot's testing infrastructure has improved a lot which 
>> should make adding the tests easier. I know there have been some more 
>> changes in net that will conflict but not badly.
>>
>> At $dayjob we have merged a newer u-boot version into our fork so I do have 
>> something that is effectively a post state for the merge conflict to refer 
>> to but it's not the broken out series that I'd like to submit.
>>
>> I think I should be able to get the series rebased against master (or the 
>> just released 2022.07 might be more useful as a base). I can probably get 
>> that up on github in the next couple of days.
>
> I've rebased my series against v2022.07 you can get the code from the
> ipv6 branch of https://github.com/cpackham/u-boot.git
>
> I've only lightly compile tested it so I've no idea if it's still functional

Hi Chris,

Thank you for refreshing the topic and rebasing. Are you planning to post a v4?
Besides tests, you had identified some gaps in previous series (DHCP, SLAAC, 
etc).
We are looking for having IPv6 in upstream, happy to fill in what will help it.

Regards,
Dhananjay

Re: [bug] boot failure on pinebook pro due to rk8xx changes in 2022.07

[Michal Suchánek]

Hello,

On Mon, Jul 18, 2022 at 05:37:18PM -0500, Chris Morgan wrote:
> On Mon, Jul 18, 2022 at 03:39:43PM +0200, Jan Palus wrote:
> > u-boot 2022.07 successfully finds and loads kernel (5.18.3) on my
> > Pinebook Pro however boot process fails when loading rk808 module:
> > 
> >   rk3x-i2c ff3c.i2c: timeout, ipd: 0x00, state: 1
> >   rk808 0-001b: failed to read the chip id at 0x17
> >   rk808: probe of 0-001b failed with error -110
> > 
> > git bisect indicates first commit to cause regression:
> > 
> >   commit ad607512f5757f4485968efd5bcf2c0245a8a235 (refs/bisect/bad)
> >   Author: Chris Morgan 
> >   Date:   Fri May 27 20:18:19 2022
> >   
> >   power: pmic: rk8xx: Support sysreset shutdown method
> >   
> >   Add support for sysreset shutdown for this PMIC. The values were 
> > pulled
> >   from the various datasheets, but for now it has only been tested on
> >   the rk817 (for an Odroid Go Advance).
> >   
> >   Signed-off-by: Chris Morgan 
> >   Reviewed-by: Jaehoon Chung 
> >   Reviewed-by: Kever Yang 
> > 
> > Reverting this commit fixes the issue and upon rk808 module load
> > following is logged:
> > 
> >   rk808 0-001b: chip id: 0x0
> 
> This is strange, as I've not encountered this bug. However, as this is
> the second report of a problem with the Pinebook Pro and this patch I
> wonder if it's prudent to roll this back (until such time that the
> functionality can be made board specific rather than generic to the
> PMIC).

Observed problems after the patch:

 - cannot reset board from u-boot
   - the sysreset walk function does not find any sysreset uclass device
 and halts
 - the pmic is no longer probed
   - the PMIC:  RK808 message (with a trailing space) is no longer
 printed during u-boot startup
 - linux locks up during boot
   - there is some complaint about fan53555 regulators which is no longer
 printed during boot

I tried to not error out when the sysreset bind fails, and not bind it
to DT node (device_bind_driver_to_node -> device_bind_driver) but it does
not make any difference.

I do not use the later part with staying off after plug-in which is not
needed on this board so I don't really understand what's the difference.

Thanks

Michal

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

[Jassi Brar]

On Mon, Jul 18, 2022 at 4:00 PM Tom Rini  wrote:
> On Mon, Jul 18, 2022 at 10:31:56AM -0500, Jassi Brar wrote:

> > > > > > > > +
> > > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > > +
> > > > > > > > +struct __packed devbox_metadata {
> > > > > > > > + u32 boot_index;
> > > > > > > > + u32 boot_count;
> > > > > > >
> > > > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > > > would be much
> > > > > > > better to use that framework instead of creating parallel one.
> > > > > > >
> > > > > > Yes, this goes too.
> > > > >
> > > > > Is bootcount really suited for this case?
> > > > > AFAIK bootcount either requires device specific registers (which won't
> > > > > reset on reboots), or an environment you can write data to.
> > > > > But what if a user wants to disable writing the env variables and the
> > > > > device doesn't have a set of registers we can use?
> > > > >
> > > > Maybe it should be moved in 'struct fwu_mdata' ?
> > >
> > > I was mostly thinking on moving this count as another 'bootcount'
> > > method.  So in case the user has disabled writing evn variables but he
> > > is booting with EFI he can use that.
> >
> > Sorry, not sure I understand IIUIC there has to be some persistent 
> > storage.
>
> No, there just has to be "somewhere" to do the counting.  We've got a
> DDR backed driver, for example.  So yes, I think we should try and use
> the bootcount framework here.
>
OK, for platforms that can preserve ram across reboot, using
non-persistent storage can work.
My platform neither preserves ram, nor has any warmreset-proof
registers. So I have to choose between saving the bootcount in efi-env
or in vendor specific structure next to the metadata. I prefer
metadata because it is common to all stages of boot. Any corrections
to this approach?

Thanks

[PATCH v2] drivers: xen: unmap Enlighten page before jumping to Linux

[Dmytro Firsov]

This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. Xen
did not prevent guest from this. So, it worked, but caused wierd
issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not unmaped by Xen (shared_info values was
not removed from there) and returned to allocator. During the Linux
boot, it uses shared_info page as regular RAM page, which leads to
hypervisor shared info corruption.

So, to fix this issue, as discussed on the xen-devel mailing list, the
code should:
   1) Unmap the page
   2) Populate the area with memory using XENMEM_populate_physmap

This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.

Signed-off-by: Dmytro Firsov 
---

Changes in v2:
- Reword commit message to be more clear with purpose of the patch
- Change BUG() helper to panic() and add error messages
- Add struct zeroing during initialization
- Fix typo in comment
---
 drivers/xen/hypervisor.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
index 2560894832..16c7c96c94 100644
--- a/drivers/xen/hypervisor.c
+++ b/drivers/xen/hypervisor.c
@@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
return HYPERVISOR_shared_info;
 }
 
+void unmap_shared_info(void)
+{
+   xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);
+   struct xen_remove_from_physmap xrfp = {0};
+   struct xen_memory_reservation reservation = {0};
+   xen_ulong_t nr_exts = 1;
+
+   xrfp.domid = DOMID_SELF;
+   xrfp.gpfn = shared_info_pfn;
+   if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
+   panic("Failed to unmap HYPERVISOR_shared_info\n");
+
+   /*
+* After removing from physmap there will be a hole in address space on
+* HYPERVISOR_shared_info address, so to free memory allocated with
+* memalign and prevent exceptions during access to this page we need to
+* fill this 4KB hole with XENMEM_populate_physmap before jumping to 
Linux.
+*/
+   reservation.domid = DOMID_SELF;
+   reservation.extent_order = 0;
+   reservation.address_bits = 0;
+   set_xen_guest_handle(reservation.extent_start, _info_pfn);
+   reservation.nr_extents = nr_exts;
+   if (HYPERVISOR_memory_op(XENMEM_populate_physmap, ) != 
nr_exts)
+   panic("Failed to populate memory on HYPERVISOR_shared_info 
addr\n");
+
+   /* Now we can return this to memory allocator */
+   free(HYPERVISOR_shared_info);
+}
+
 void do_hypervisor_callback(struct pt_regs *regs)
 {
unsigned long l1, l2, l1i, l2i;
@@ -251,4 +281,5 @@ void xen_fini(void)
fini_gnttab();
fini_xenbus();
fini_events();
+   unmap_shared_info();
 }
-- 
2.25.1

Re: [PATCH] drivers: xen: unmap Enlighten page before jumping to Linux

[Dmytro Firsov]

On 19.07.22 14:04, Julien Grall wrote:
> Hi,
>
> On 19/07/2022 11:45, Dmytro Firsov wrote:
>>
>> On 19.07.22 12:50, Julien Grall wrote:
>>> Hi Dmytro,
>>>
>>> On 19/07/2022 09:52, Dmytro Firsov wrote:
 This commit fixes issue with usage of Xen hypervisor shared info page.
 Previously U-boot did not unmap it at the end of OS boot process. It
 leads to repeated mapping during Enlighten initialization in Linux.
 Xen did not prevent guest from this, so it works but causes weird
 wierd issues - one memory page, that was returned by memalign in 
 U-boot
 for Enlighten mapping was not returned to allocator and contained
 shared info values during Linux run.
>>>
>>> I can't quite parse this. Do you mean the page will be marked as
>>> reserved for Linux and therefore it will never reach Linux's page
>>> allocator?
>>>
>> No, U-boot memory allocator uses real RAM pages and one of them will be
>> used for shared_info. Previously U-boot did not unmap it when jumped to
>> Linux. So, during Linux run, one of the pages that is marked as RAM in
>> device-tree will contain shared_info values. I don't know how it worked
>> previously, but it definitely will cause weird issue when Linux will try
>> to use it as regular RAM page.
>
> Ok. I would suggest to reword the commit message.
>
>>
>>
 Also Linux mapped it to another
 place in memory again. >
 Now code, that restricts repeated mapping of Enlighten page, is about
 to be merged to Xen:
 https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!2OWttkgakR7s6GUn6e60EweRQ44H-TyI-8wWzhX0vWzR33BJE_z-x_AZ0S5VBBnXwwQ73-eIQ-sNcGLf$
  

 [lore[.]kernel[.]org]

 So, without unmapping in U-boot, Linux will fail to start.
>>>
>>> Hmmm... From a discussion with Oleksandr, I was under the impression
>>> that this patch would also be necessary without the Xen patch merged.
>>> This was in order to prevent a corruption of the shared page [1].
>>>
>> Yes, definitely, but with new patches this problem becomes critical
>
> I would argue that it was more critical before because you would end 
> up with some random corruption of the shared page. At least, Oleksandr 
> patch bring up some certainty because now Linux can't boot.
>
>> and
>> it will block Linux boot. General problem is explained in previous
>> section. This patch is needed to U-boot even without new patches to Xen,
>> but problem became visible only after them.
> See above, I think the commit message should focus on the corruption 
> rather than Xen forbidding double map. So it is clear that this patch 
> is not to paper over a new issue in Xen (which would technically be a 
> regression) but fixing a *real* problem on any Xen version.

Okay, I argee. I will reword commit message with focus on corruption.


>
>>
>>
 As discussed
 on the xen-devel mailing list, to fix this issue the code should:
  1) Unmap the page
  2) Populate the area with memory using XENMEM_populate_physmap

 This patch adds page unmapping via XENMEM_remove_from_physmap, fills
 hole in address space where page was mapped via 
 XENMEM_populate_physmap
 and return this address to memory allocator for freeing.
>>>
>>> Is U-boot mapping other shared page from Xen (e.g. grant-table...)?
>>
>> Yes, but only shared_info is mapped with XENMEM_add_to_physmap, so other
>> drivers are not affected.
>
> H... A grep in u-boot source shows that XENMEM_add_to_physmap is 
> used to map grant-table frame. However, the driver seems to use the 
> unallocated address space provided by Xen. So you are fine there.

Yes, grant-tables are mapped outside of actual RAM, so there is no such 
problem.


>
>
>>>
 +    struct xen_remove_from_physmap xrfp;
 +    struct xen_memory_reservation reservation;
>>>
>>> AFAICT, there some paddings in the two structure. So I would suggest
>>> to zero the structure (including paddings).
>>
>> I did not see any padding in these structs definition in U-boot, so all
>> fields are initialized.
>
> There are no explicit padding but there are some implicit one. If you 
> use pahole, you will see:
>
> struct xen_remove_from_physmap {
>     domid_t    domid;    /* 0 2 */
>
>     /* XXX 6 bytes hole, try to pack */
>
>     xen_pfn_t  gpfn; /* 8 8 */
>
>     /* size: 16, cachelines: 1, members: 2 */
>     /* sum members: 10, holes: 1, sum holes: 6 */
>     /* last cacheline: 16 bytes */
> };
>
>
> struct xen_memory_reservation {
>     __guest_handle_64_xen_pfn_t extent_start;    /* 0 8 */
>     xen_ulong_t    nr_extents;   /* 8 8 */
>     unsigned int   extent_order; /* 16 4 */
>     unsigned int   mem_flags;    /* 20 4 */
>     domid_t    domid;  

Re: [PATCH] drivers: xen: unmap Enlighten page before jumping to Linux

[Dmytro Firsov]

On 19.07.22 12:50, Julien Grall wrote:
> Hi Dmytro,
>
> On 19/07/2022 09:52, Dmytro Firsov wrote:
>> This commit fixes issue with usage of Xen hypervisor shared info page.
>> Previously U-boot did not unmap it at the end of OS boot process. It
>> leads to repeated mapping during Enlighten initialization in Linux.
>> Xen did not prevent guest from this, so it works but causes weird
>> wierd issues - one memory page, that was returned by memalign in U-boot
>> for Enlighten mapping was not returned to allocator and contained
>> shared info values during Linux run.
>
> I can't quite parse this. Do you mean the page will be marked as 
> reserved for Linux and therefore it will never reach Linux's page 
> allocator?
>
No, U-boot memory allocator uses real RAM pages and one of them will be 
used for shared_info. Previously U-boot did not unmap it when jumped to 
Linux. So, during Linux run, one of the pages that is marked as RAM in 
device-tree will contain shared_info values. I don't know how it worked 
previously, but it definitely will cause weird issue when Linux will try 
to use it as regular RAM page.


>> Also Linux mapped it to another
>> place in memory again. >
>> Now code, that restricts repeated mapping of Enlighten page, is about
>> to be merged to Xen:
>> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!2OWttkgakR7s6GUn6e60EweRQ44H-TyI-8wWzhX0vWzR33BJE_z-x_AZ0S5VBBnXwwQ73-eIQ-sNcGLf$
>>  
>> [lore[.]kernel[.]org]
>>
>> So, without unmapping in U-boot, Linux will fail to start.
>
> Hmmm... From a discussion with Oleksandr, I was under the impression 
> that this patch would also be necessary without the Xen patch merged. 
> This was in order to prevent a corruption of the shared page [1].
>
Yes, definitely, but with new patches this problem becomes critical and 
it will block Linux boot. General problem is explained in previous 
section. This patch is needed to U-boot even without new patches to Xen, 
but problem became visible only after them.


>> As discussed
>> on the xen-devel mailing list, to fix this issue the code should:
>>     1) Unmap the page
>>     2) Populate the area with memory using XENMEM_populate_physmap
>>
>> This patch adds page unmapping via XENMEM_remove_from_physmap, fills
>> hole in address space where page was mapped via XENMEM_populate_physmap
>> and return this address to memory allocator for freeing.
>
> Is U-boot mapping other shared page from Xen (e.g. grant-table...)?

Yes, but only shared_info is mapped with XENMEM_add_to_physmap, so other 
drivers are not affected.


>
>>
>> Signed-off-by: Dmytro Firsov 
>> ---
>>   drivers/xen/hypervisor.c | 31 +++
>>   1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
>> index 2560894832..9ac377b618 100644
>> --- a/drivers/xen/hypervisor.c
>> +++ b/drivers/xen/hypervisor.c
>> @@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
>>   return HYPERVISOR_shared_info;
>>   }
>>   +void unmap_shared_info(void)
>> +{
>> +    xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);
>
> Somewhat unrelated to this patch. Can U-boot be compiled with 16K/64K 
> page granularity?

I am using it on Armv8 and U-boot have hardcoded PAGE_SHIFT==12, and 
PAGE_SIZE==(1<
>> +    struct xen_remove_from_physmap xrfp;
>> +    struct xen_memory_reservation reservation;
>
> AFAICT, there some paddings in the two structure. So I would suggest 
> to zero the structure (including paddings).

I did not see any padding in these structs definition in U-boot, so all 
fields are initialized. But I can add zeroing with memset in next 
version to be sure in this if structures will change.


>
>> +    xen_ulong_t nr_exts = 1;
>> +
>> +    xrfp.domid = DOMID_SELF;
>> +    xrfp.gpfn = shared_info_pfn;
>> +    if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
>> +    BUG();
>
> If I am not mistaken, U-boot provide a panic() helper. So I would 
> suggest to use it as this would be useful to print with the error 
> returned.

Agree, will be fixed in next version.


>
>> +
>> +    /*
>> + * After remove from physmap there will be a hole in address 
>> space on
>
> Typo: s/remove/removing/

Agree, will be fixed in next version.


>
>> + * HYPERVISOR_shared_info address, so to free memory allocated with
>> + * memalign and prevent exceptions during access to this page we 
>> need to
>> + * fill this 4KB hole with XENMEM_populate_physmap before 
>> jumping to Linux.
>> + */
>> +    reservation.domid = DOMID_SELF;
>> +    reservation.extent_order = 0;
>> +    reservation.address_bits = 0;
>> +    set_xen_guest_handle(reservation.extent_start, _info_pfn);
>> +    reservation.nr_extents = nr_exts;
>> +    if (HYPERVISOR_memory_op(XENMEM_populate_physmap, ) 
>> != nr_exts)
>> +    BUG();
>
> Same here regarding using panic() rather than BUG()

Agree, will be 

[PATCH] drivers: xen: unmap Enlighten page before jumping to Linux

[Dmytro Firsov]

This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. It
leads to repeated mapping during Enlighten initialization in Linux.
Xen did not prevent guest from this, so it works but causes weird
wierd issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not returned to allocator and contained
shared info values during Linux run. Also Linux mapped it to another
place in memory again.

Now code, that restricts repeated mapping of Enlighten page, is about
to be merged to Xen:
https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/

So, without unmapping in U-boot, Linux will fail to start. As discussed
on the xen-devel mailing list, to fix this issue the code should:
   1) Unmap the page
   2) Populate the area with memory using XENMEM_populate_physmap

This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.

Signed-off-by: Dmytro Firsov 
---
 drivers/xen/hypervisor.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
index 2560894832..9ac377b618 100644
--- a/drivers/xen/hypervisor.c
+++ b/drivers/xen/hypervisor.c
@@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
return HYPERVISOR_shared_info;
 }
 
+void unmap_shared_info(void)
+{
+   xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);
+   struct xen_remove_from_physmap xrfp;
+   struct xen_memory_reservation reservation;
+   xen_ulong_t nr_exts = 1;
+
+   xrfp.domid = DOMID_SELF;
+   xrfp.gpfn = shared_info_pfn;
+   if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
+   BUG();
+
+   /*
+* After remove from physmap there will be a hole in address space on
+* HYPERVISOR_shared_info address, so to free memory allocated with
+* memalign and prevent exceptions during access to this page we need to
+* fill this 4KB hole with XENMEM_populate_physmap before jumping to 
Linux.
+*/
+   reservation.domid = DOMID_SELF;
+   reservation.extent_order = 0;
+   reservation.address_bits = 0;
+   set_xen_guest_handle(reservation.extent_start, _info_pfn);
+   reservation.nr_extents = nr_exts;
+   if (HYPERVISOR_memory_op(XENMEM_populate_physmap, ) != 
nr_exts)
+   BUG();
+
+   /* Now we can return this to memory allocator */
+   free(HYPERVISOR_shared_info);
+}
+
 void do_hypervisor_callback(struct pt_regs *regs)
 {
unsigned long l1, l2, l1i, l2i;
@@ -251,4 +281,5 @@ void xen_fini(void)
fini_gnttab();
fini_xenbus();
fini_events();
+   unmap_shared_info();
 }
-- 
2.25.1

RE: [PATCH 2/5] firmware: zynqmp: Load config overlay for core0 to pmufw

[Soma, Ashok Reddy]

Hi Stefan,

>-Original Message-
>From: Stefan Herbrechtsmeier  
>Sent: Saturday, July 16, 2022 4:48 PM
>To: Simek, Michal ; Ashok Reddy Soma 
>; u-boot@lists.denx.de
>Cc: adrian.fiergol...@fastree3d.com; jh80.ch...@samsung.com; 
>s...@svenpeter.dev; kette...@openbsd.org; s...@chromium.org; g...@xilinx.com; 
>git (AMD-Xilinx) 
>Subject: Re: [PATCH 2/5] firmware: zynqmp: Load config overlay for core0 to 
>pmufw
>
>CAUTION: This message has originated from an External Source. Please use 
>proper judgment and caution when opening attachments, clicking links, or 
>responding to this email.
>
>
>Am 15.07.2022 um 18:34 schrieb Michal Simek:
>>
>>
>> On 7/15/22 18:13, Stefan Herbrechtsmeier wrote:
>>> Am 15.07.2022 um 11:39 schrieb Ashok Reddy Soma:
 Try loading pmufw config overlay for core0, if it doesn't return any 
 error it means pmufw is accepting nodes for other IP's. Otherwise 
 dont try to load config object for any other IP, just return from 
 zynqmp_pmufw_node function.

 Signed-off-by: Ashok Reddy Soma 
 ---

   drivers/firmware/firmware-zynqmp.c | 14 ++
   1 file changed, 14 insertions(+)

 diff --git a/drivers/firmware/firmware-zynqmp.c
 b/drivers/firmware/firmware-zynqmp.c
 index 34d9b47003..288151533e 100644
 --- a/drivers/firmware/firmware-zynqmp.c
 +++ b/drivers/firmware/firmware-zynqmp.c
 @@ -68,8 +68,13 @@ int zynqmp_pmufw_config_close(void)
   return 0;
   }
 +static bool config_enabled;
 +
>>>
>>> Please move the variable inside the function.
>>
>> How can this work? When you move it to zynqmp_pmufw_node() then won't 
>> be visible in zynqmp_power_probe() and vice-versa.

>If you reuse the zynqmp_pmufw_node function in zynqmp_power_probe function you 
>can check the id parameter to update the config_enabled variable in 
>zynqmp_pmufw_node.

are you suggesting to change like this ?  this works fine for me. Shall i send 
V2 with this.

--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -29,6 +29,7 @@ struct zynqmp_power {
 } zynqmp_power;
 
 #define NODE_ID_LOCATION   5
+#define APU0_IDNODE_APU_0
 
 static unsigned int xpm_configobject[] = {
/**/
@@ -68,18 +69,22 @@ int zynqmp_pmufw_config_close(void)
return 0;
 }
 
-static bool config_enabled;
 
 int zynqmp_pmufw_node(u32 id)
 {
-   if (!config_enabled)
+   static bool config_enabled;
+   int ret;
+
+   if (!config_enabled && id != APU0_ID)
return 0;
 
/* Record power domain id */
xpm_configobject[NODE_ID_LOCATION] = id;
 
-   zynqmp_pmufw_load_config_object(xpm_configobject,
-   sizeof(xpm_configobject));
+   ret = zynqmp_pmufw_load_config_object(xpm_configobject,
+ sizeof(xpm_configobject));
+   if(!ret && id == APU0_ID)
+   config_enabled = true;
 
return 0;
 }
@@ -272,14 +277,8 @@ static int zynqmp_power_probe(struct udevice *dev)
   ret >> ZYNQMP_PM_VERSION_MAJOR_SHIFT,
   ret & ZYNQMP_PM_VERSION_MINOR_MASK);
 
-   if (IS_ENABLED(CONFIG_ARCH_ZYNQMP)) {
-   xpm_configobject[NODE_ID_LOCATION] = NODE_APU_0;
-
-   ret = zynqmp_pmufw_load_config_object(xpm_configobject,
- sizeof(xpm_configobject));
-   if (!ret)
-   config_enabled = true;
-   }
+   if (IS_ENABLED(CONFIG_ARCH_ZYNQMP))
+   zynqmp_pmufw_node(APU0_ID);
 
return 0;

Thanks,
Ashok

[PATCH] net: emaclite: Avoid reading negative bytes

[Liao Junxuan]

As far as I know, an IP packet isn't necessarily shorter than an ARP
packet, and if length < first_read, xemaclite_alignedread() goes into
an infinite loop.
---
 drivers/net/xilinx_emaclite.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 43fc36dc..134973a5 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -526,7 +526,7 @@ try_again:
}
 
/* Read the rest of the packet which is longer then first read */
-   if (length != first_read)
+   if (length > first_read)
xemaclite_alignedread(addr + first_read,
  etherrxbuff + first_read,
  length - first_read);
-- 
2.37.1

Re: [bug] boot failure on pinebook pro due to rk8xx changes in 2022.07

[Chris Morgan]

On Mon, Jul 18, 2022 at 03:39:43PM +0200, Jan Palus wrote:
> u-boot 2022.07 successfully finds and loads kernel (5.18.3) on my
> Pinebook Pro however boot process fails when loading rk808 module:
> 
>   rk3x-i2c ff3c.i2c: timeout, ipd: 0x00, state: 1
>   rk808 0-001b: failed to read the chip id at 0x17
>   rk808: probe of 0-001b failed with error -110
> 
> git bisect indicates first commit to cause regression:
> 
>   commit ad607512f5757f4485968efd5bcf2c0245a8a235 (refs/bisect/bad)
>   Author: Chris Morgan 
>   Date:   Fri May 27 20:18:19 2022
>   
>   power: pmic: rk8xx: Support sysreset shutdown method
>   
>   Add support for sysreset shutdown for this PMIC. The values were pulled
>   from the various datasheets, but for now it has only been tested on
>   the rk817 (for an Odroid Go Advance).
>   
>   Signed-off-by: Chris Morgan 
>   Reviewed-by: Jaehoon Chung 
>   Reviewed-by: Kever Yang 
> 
> Reverting this commit fixes the issue and upon rk808 module load
> following is logged:
> 
>   rk808 0-001b: chip id: 0x0

This is strange, as I've not encountered this bug. However, as this is
the second report of a problem with the Pinebook Pro and this patch I
wonder if it's prudent to roll this back (until such time that the
functionality can be made board specific rather than generic to the
PMIC).

Thank you.

[bug] uboot 2022.07 hangs on rpi 2 with attached usb storage

[Jan Palus]

u-boot 2022.07 boots fine without any USB devices attached to
RaspberryPi 2 however it hangs early on if external USB drive is
connected, right after:

   Request Sense returned 02 04 01

git bisect indicates first commit to cause regression is:

  8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit
  commit 8c9812a5d557c4eacf164147d7380b3af1b222ec
  Author: AKASHI Takahiro 
  Date:   Tue Mar 8 20:36:40 2022 +0900
  
  usb: storage: call device_probe() after scanning
  
  Every time a usb bus/port is scanned and a new device is detected,
  we want to call device_probe() as it will give us a chance to run
  additional post-processings for some purposes.
  
  In particular, support for creating partitions on a device will be added.
  
  Signed-off-by: AKASHI Takahiro 
  Reviewed-by: Simon Glass 

Reverting this commit fixes the issue.

Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting.
Also note that without this change 0 storage devices are detected even
when drive is attached.

Re: [PATCH v5 19/23] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox

[Jassi Brar]

On Mon, 18 Jul 2022 at 16:00, Tom Rini  wrote:
> On Mon, Jul 18, 2022 at 10:31:56AM -0500, Jassi Brar wrote:

> > > > > >
> > > > > > > > +
> > > > > > > > +#define PLAT_METADATA_OFFSET 0x51
> > > > > > > > +#define PLAT_METADATA_SIZE   (sizeof(struct devbox_metadata))
> > > > > > > > +
> > > > > > > > +struct __packed devbox_metadata {
> > > > > > > > + u32 boot_index;
> > > > > > > > + u32 boot_count;
> > > > > > >
> > > > > > > There is the whole bootcount infrastructure for this. I think it 
> > > > > > > would be much
> > > > > > > better to use that framework instead of creating parallel one.
> > > > > > >
> > > > > > Yes, this goes too.
> > > > >
> > > > > Is bootcount really suited for this case?
> > > > > AFAIK bootcount either requires device specific registers (which won't
> > > > > reset on reboots), or an environment you can write data to.
> > > > > But what if a user wants to disable writing the env variables and the
> > > > > device doesn't have a set of registers we can use?
> > > > >
> > > > Maybe it should be moved in 'struct fwu_mdata' ?
> > >
> > > I was mostly thinking on moving this count as another 'bootcount'
> > > method.  So in case the user has disabled writing evn variables but he
> > > is booting with EFI he can use that.
> >
> > Sorry, not sure I understand IIUIC there has to be some persistent 
> > storage.
>
> No, there just has to be "somewhere" to do the counting.  We've got a
> DDR backed driver, for example.  So yes, I think we should try and use
> the bootcount framework here.
>
OK, for platforms that can preserve ram across reboot, using
non-persistent storage can work.
My platform neither preserves ram, nor has any warmreset-proof
registers. So I have to choose between saving the bootcount in efi-env
or in vendor specific structure next to the metadata. I prefer
metadata because it is common to all stages of boot. Any corrections
to this approach?

Thanks

Please pull u-boot-i2c

[Heiko Schocher]

Hello Tom,

please pull from:

The following changes since commit 26f6f7fb5c0651d65afdee6d8ed36063606179a8:

  Merge branch '2022-07-14-migrate-wiki-to-sphinx' (2022-07-14 18:43:51 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-i2c.git tags/for-v2022.10

for you to fetch changes up to 49f3a42edf097fbaca76aef9bfcd98d871b442cb:

  i2c: avoid dynamic stack use in dm_i2c_write (2022-07-19 13:46:28 +0200)


i2c changes for 2022.10

- new driver nuvoton, NPCM7xx from Jim Liu

Fixes:

- ast_i2c: Remove SCL direct drive mode
  from Eddie James

- avoid dynamic stack use in dm_i2c_write

bloat-o-meter drivers/i2c/i2c-uclass.o.{0,1}
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-144 (-144)
Function old new   delta
dm_i2c_write 552 408-144
Total: Before=3828, After=3684, chg -3.76%

  patch from Rasmus Villemoes


Eddie James (1):
  i2c: ast_i2c: Remove SCL direct drive mode

Jim Liu (1):
  i2c: nuvoton: Add NPCM7xx i2c driver

Rasmus Villemoes (1):
  i2c: avoid dynamic stack use in dm_i2c_write

 drivers/i2c/Kconfig  |   5 ++
 drivers/i2c/Makefile |   1 +
 drivers/i2c/ast_i2c.c|   2 +-
 drivers/i2c/i2c-uclass.c |  30 +++-
 drivers/i2c/npcm-i2c.c   | 630
+
 5 files changed, 649 insertions(+), 19 deletions(-)
 create mode 100644 drivers/i2c/npcm-i2c.c

Azure build is fine:

https://dev.azure.com/hs0298/hs/_build/results?buildId=82=results


bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: Pull request: u-boot-spi/master

[Tom Rini]

On Tue, Jul 19, 2022 at 01:05:15AM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> Summary:
> - add Macronix Octal flash (JaimeLiao)
> 
> CI:
> https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/12778
> 
> thanks,
> Jagan.
> 
> The following changes since commit 26f6f7fb5c0651d65afdee6d8ed36063606179a8:
> 
>   Merge branch '2022-07-14-migrate-wiki-to-sphinx' (2022-07-14 18:43:51 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-spi master
> 
> for you to fetch changes up to 47ed8b22fd561b65e8541919becc76ab3d86f7a3:
> 
>   mtd: spi-nor-ids: add winbond w25q512nw family support (2022-07-18 19:15:19 
> +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Pull request: u-boot-sunxi/master for v2022.10

[Andre Przywara]

Hi Tom,

please pull the sunxi/master branch, containing the first part of the
2022.10 changes.

One prominent feature is the restructering of the clock driver, which
allows to end up with one actual driver for all variants, although we
still only compile in support for one SoC.
Also contained are some initial SPI fixes, which should fix some
problems, and enable SPI flash support for the F1C100s SoC. Those
patches revealed more problems, I will queue fixes later on, but for
now it should at least still work.
Apart from some smaller fixes (for instance for NAND operation), there
is also preparation for the upcoming Allwinner D1 support, in form of
the USB PHY driver. There are more driver support patches to come.

The gitlab CI completed successfully, including the build test for all
160 sunxi boards. I also boot tested on a few boards, but didn't have
time for more elaborate tests this time.

Thanks,
Andre

===
The following changes since commit 26f6f7fb5c0651d65afdee6d8ed36063606179a8:

  Merge branch '2022-07-14-migrate-wiki-to-sphinx' (2022-07-14 18:43:51 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master

for you to fetch changes up to 25ba5be1c2b6324917254f0c22df1ad9d3d3c9e7:

  phy: sun4i-usb: Add D1 variant (2022-07-18 23:48:37 +0100)


Andre Przywara (6):
  sunxi: configs: streamline include/configs/sun*.h wrappers
  spi: sunxi: refactor SPI speed/mode programming
  spi: sunxi: improve SPI clock calculation
  spi: sunxi: Add support for F1C100s SPI controller
  sunxi: licheepi_nano: enable SPI flash
  phy: sun4i-usb: Rework HCI PHY (aka "pmu_unk1") handling

Icenowy Zheng (1):
  spi: sunxi: use XCH status to detect in-progress transfer

Markus Hoffrogge (1):
  sunxi-nand: fix the PIO instead of DMA implementation

Michal Suchanek (2):
  sunxi: lcd: Move range from kconfig description to definition.
  configs: sunxi: OrangePi Zero: enable Macronix flash support

Samuel Holland (12):
  clk: sunxi: Store the array sizes in the CCU descriptor
  clk: sunxi: Prevent out-of-bounds gate array access
  reset: sunxi: Get the reset count from the CCU descriptor
  clk: sunxi: Use a single driver for all variants
  clk: sunxi: Convert driver private data to platform data
  reset: sunxi: Convert driver private data to platform data
  reset: sunxi: Reuse the platform data from the clock driver
  net: sun8i-emac: Downgrade printf during probe to debug
  net: sun8i-emac: Drop use of arch-specific header
  sunxi: Move INITIAL_USB_SCAN_DELAY to driver Kconfig
  phy: sun4i-usb: Drop use of arch-specific headers
  phy: sun4i-usb: Add D1 variant

 arch/arm/mach-sunxi/Kconfig   |  12 +--
 configs/licheepi_nano_defconfig   |   3 +
 configs/orangepi_zero_defconfig   |   1 +
 drivers/clk/sunxi/clk_a10.c   |  27 +-
 drivers/clk/sunxi/clk_a10s.c  |  27 +-
 drivers/clk/sunxi/clk_a23.c   |  27 +-
 drivers/clk/sunxi/clk_a31.c   |  25 +
 drivers/clk/sunxi/clk_a31_r.c |  29 +-
 drivers/clk/sunxi/clk_a64.c   |  25 +
 drivers/clk/sunxi/clk_a80.c   |  36 ++-
 drivers/clk/sunxi/clk_a83t.c  |  25 +
 drivers/clk/sunxi/clk_f1c100s.c   |  25 +
 drivers/clk/sunxi/clk_h3.c|  27 +-
 drivers/clk/sunxi/clk_h6.c|  25 +
 drivers/clk/sunxi/clk_h616.c  |  25 +
 drivers/clk/sunxi/clk_h6_r.c  |  27 +-
 drivers/clk/sunxi/clk_r40.c   |  25 +
 drivers/clk/sunxi/clk_sunxi.c | 175 ++
 drivers/clk/sunxi/clk_v3s.c   |  27 +-
 drivers/mtd/nand/raw/sunxi_nand_spl.c |   2 +-
 drivers/net/sun8i_emac.c  |   3 +-
 drivers/phy/allwinner/Kconfig |  10 ++
 drivers/phy/allwinner/phy-sun4i-usb.c |  44 +
 drivers/reset/reset-sunxi.c   |  55 ++-
 drivers/spi/spi-sunxi.c   | 123 ++--
 include/clk/sunxi.h   |  21 +---
 include/configs/sun4i.h   |  10 +-
 include/configs/sun50i.h  |  19 +---
 include/configs/sun5i.h   |  10 +-
 include/configs/sun6i.h   |   7 +-
 include/configs/sun7i.h   |   6 +-
 include/configs/sun8i.h   |  13 +--
 include/configs/sun9i.h   |  11 +--
 include/configs/suniv.h   |   7 +-
 34 files changed, 345 insertions(+), 589 deletions(-)

Re: DWC3 host support

[Angus Ainslie]

On 2022-07-18 23:47, Michal Simek wrote:

Hi,

On 7/18/22 18:23, Angus Ainslie wrote:

Hi,

On 2022-07-18 01:13, Michal Simek wrote:

On 7/17/22 17:23, Marek Vasut wrote:

On 7/17/22 05:00, Angus Ainslie wrote:

On 2022-07-16 11:37, Marek Vasut wrote:

On 7/16/22 15:02, Angus Ainslie wrote:

Hi Michal,

I recently rebased my librem5 tree onto the latest u-boot-imx 
branch

and the dwc3 host mode stopped working.

I bisected it down to this commit:

142d50fbce7c364a74f5e8204dba491b9f066e6c usb: dwc3: Add support 
for

usb3-phy PHY configuration

Reverting that commit allows usb host mode to work on the librem5 
again.


Should this initialization go into an SOC specific glue_configure
function ?

Is the imx8mq.dtsi missing something that will keep usb host 
working

with this patch ?

Does this break usb host on other imx8mq devices ?


Wasn't this fixed by:
868d58f69c ("usb: dwc3: Fix non-usb3 configurations")
?


I've got that in my tree and it still fails to probe the USB2 hub 
and

USB 2 storage.


I assume you do have CONFIG_PHY_IMX8MQ_USB enabled ?

What does generic_phy_get_by_name() return for you in
drivers/usb/dwc3/dwc3-generic.c ?


As Marek said there was one patch which fixes origin patch which
didn't handle all the error cases properly. We need to know return
value from generic_phy_get_by_name(), also if you still have usb3-phy
in DT (as is in imx8mq.dtsi) with phy DT status enabled and enabled
phy driver (CONFIG_PHY_IMX8MQ_USB).



Removing the usb3 phy definition also "fixes" it

--- a/arch/arm/dts/imx8mq-librem5-r4.dts
+++ b/arch/arm/dts/imx8mq-librem5-r4.dts
@@ -33,3 +33,8 @@
   {
     proximity-near-level = <10>;
  };
+
+_dwc3_1 {
+   phys = <_phy1>;
+   phy-names = "usb2-phy";
+};


Log shows that phy initialization is called properly but it looks like
that initialization itself has issue which should be the issue with
phy driver.

DWC3 driver is calling just phy_init and phy_power_on which are quite
small 2 functions in phy-imx8mq-usb.c.

Did usb3 work before 142d50fbce7c364a74f5e8204dba491b9f066e6c?
I have no idea how imx is working but I have added to CC author of
this phy driver.



We don't use USB3 on that port so no idea. The only thing connected to 
that port is a USB 2 hub and then downstream devices from the hub. The 
USB 2 hub did work without 142d50fbce7c364a74f5e8204dba491b9f066e6c.



I see small differences between Linux and U-Boot drivers.

 99 value &= ~PHY_CTRL0_SSC_RANGE_MASK;
100 value |= PHY_CTRL0_SSC_RANGE_4003PPM;

And in power_on I see this in u-boot

129 /* Disable rx term override */
130 value = readl(imx_phy->base + PHY_CTRL6);
131 value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
132 writel(value, imx_phy->base + PHY_CTRL6);

And Linux driver is handling regulators. Do you use any regulator?


There isn't a regulator specifically for the PHY. There is one for the 
hub and it gets enabled before the phy_init functions.




If usb3.0 works in Linux I think it should be easier for you to track
this down but there are some small differences in the U-Boot driver
which can be the reason why it is failing on your board.


Thanks
Angus



Thanks,
Michal

Re: [RESEND v9 5/9] eficonfig: add "Change Boot Order" menu entry

[Ilias Apalodimas]

> On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima  
> wrote:

[...]

> --- a/cmd/eficonfig.c
> +++ b/cmd/eficonfig.c
> @@ -89,6 +89,21 @@ struct eficonfig_boot_selection_data {
> int *selected;
>  };
>
> +/**
> + * struct eficonfig_boot_order - structure to be used to update BootOrder 
> variable
> + *
> + * @num:   index in the menu entry
> + * @description:   pointer to the description string
> + * @prev_index:index in the BootOrder variable before 
> changing order
> + * @list:  list structure
> + */
> +struct eficonfig_boot_order {
> +   u32 num;
> +   u16 *description;
> +   u32 prev_index;
> +   struct list_head list;
> +};

[...]


>
> +/**
> + * eficonfig_display_change_boot_order() - display the BootOrder list
> + *
> + * @bo_list:   pointer to the list structure
> + * @efi_menu:  pointer to the efimenu structure
> + * Return: status code
> + */
> +/**
> + * eficonfig_choice_change_boot_order() - handle the BootOrder update
> + *
> + * @bo_list:   pointer to the list structure
> + * @efi_menu:  pointer to the efimenu structure
> + * Return: status code
> + */
> +static efi_status_t eficonfig_choice_change_boot_order(struct list_head 
> *bo_list,
> +  struct efimenu 
> *efi_menu)
> +{
> +   int esc = 0;
> +   struct list_head *pos, *n;
> +   struct eficonfig_boot_order *tmp;
> +   enum bootmenu_key key = KEY_NONE;
> +   struct eficonfig_boot_order *entry;
> +
> +   while (1) {
> +   bootmenu_loop(NULL, , );
> +
> +   switch (key) {
> +   case KEY_PLUS:
> +   if (efi_menu->active > 0) {
> +   list_for_each_safe(pos, n, bo_list) {
> +   entry = list_entry(pos, struct 
> eficonfig_boot_order, list);
> +   if (entry->num == efi_menu->active)
> +   break;
> +   }
> +   tmp = list_entry(pos->prev, struct 
> eficonfig_boot_order, list);
> +   entry->num--;
> +   tmp->num++;
> +   list_del(>list);
> +   list_add(>list, >list);
> +   }
> +   fallthrough;
> +   case KEY_UP:
> +   if (efi_menu->active > 0)
> +   --efi_menu->active;
> +   return EFI_NOT_READY;
> +   case KEY_MINUS:
> +   if (efi_menu->active < efi_menu->count - 3) {
> +   list_for_each_safe(pos, n, bo_list) {
> +   entry = list_entry(pos, struct 
> eficonfig_boot_order, list);
> +   if (entry->num == efi_menu->active)
> +   break;
> +   }
> +   tmp = list_entry(pos->next, struct 
> eficonfig_boot_order, list);
> +   entry->num++;
> +   tmp->num--;
> +   list_del(>list);
> +   list_add(>list, >list);
> +
> +   ++efi_menu->active;
> +   }
> +   return EFI_NOT_READY;
> +   case KEY_DOWN:
> +   if (efi_menu->active < efi_menu->count - 1)
> +   ++efi_menu->active;
> +   return EFI_NOT_READY;
> +   case KEY_SELECT:
> +   /* "Save" */
> +   if (efi_menu->active == efi_menu->count - 2)
> +   return EFI_SUCCESS;
> +
> +   /* "Quit" */
> +   if (efi_menu->active == efi_menu->count - 1)
> +   return EFI_ABORTED;
> +
> +   break;
> +   case KEY_QUIT:
> +   return EFI_ABORTED;
> +   default:

We need to return something here as well.


> +   break;
> +   }
> +   }
> +}
> +
> +/**
[...]

Thanks
/Ilias

Re: [RESEND v9 9/9] doc:eficonfig: add documentation for eficonfig command

[Ilias Apalodimas]

On Tue, 19 Jul 2022 at 13:15, Masahisa Kojima
 wrote:
>
> Hi Ilias,
>
> On Tue, 19 Jul 2022 at 17:03, Ilias Apalodimas
>  wrote:
> >
> > Hello Kojima-san
> >
> > On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
> >  wrote:
> > >
> > > Add documentation for eficonfig command.
> > >
> > > Signed-off-by: Masahisa Kojima 
> > > ---
> > > No change sinch v8
> > >
> > > Changes in v8:
> > > - command name is changed from "efimenu" to "eficonfig"
> > >
> > > Newly created in v7
> > >
> > >  doc/usage/cmd/eficonfig.rst | 49 +
> > >  doc/usage/index.rst |  1 +
> >
> > [...]
> >
> > > +
> > > +The "eficonfig" command is enabled by::
> > > +
> > > +CONFIG_CMD_EFICONFIG=y
> > > +
> > > +If CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not enter
> > > +U-Boot console. In this case, bootmenu can be used to invoke 
> > > "eficonfig"::
> > > +
> > > +CONFIG_USE_PREBOOT=y
> > > +CONFIG_PREBOOT="setenv bootmenu_0 UEFI Maintenance Menu=eficonfig"
> >
> > Can't we just set it as the default bootcmd? Does it have to be a
> > preboot command?
>
> "eficonfig" command is for updating UEFI variables(BOOT and
> BootOrder, etc.) only.
> User can not boot the system with "eficonfig" command, so I think it
> is not the desired
> option to set it as default bootcmd.

Ok then we should describe a bit what functionality it offers.
The user can now configure eficonfig as a preboot command and that
will pop up on each boot.  If the U-Boot timeout expires (which is
unaffected by the eficonfig) the board will boot with whatever
configuration it already has.  If the user starts editing options
though he has to hit the 'exit' button for the board to boot.

Thanks
/Ilias
>
> Thanks,
> Masahisa Kojima
>
> >
> > Thanks
> > /Ilias
> > > +
> > > +See also
> > > +
> > > +* :doc:`bootmenu` provides a simple mechanism for creating 
> > > menus with different boot items
> > > diff --git a/doc/usage/index.rst b/doc/usage/index.rst
> > > index 8b98629d6b..1afbb6bc5d 100644
> > > --- a/doc/usage/index.rst
> > > +++ b/doc/usage/index.rst
> > > @@ -35,6 +35,7 @@ Shell commands
> > > cmd/conitrace
> > > cmd/dm
> > > cmd/echo
> > > +   cmd/eficonfig
> > > cmd/env
> > > cmd/event
> > > cmd/exception
> > > --
> > > 2.17.1
> > >

Re: [PATCH] i2c: avoid dynamic stack use in dm_i2c_write

[Heiko Schocher]

Hello Rasmus,

On 07.07.22 15:12, Rasmus Villemoes wrote:
> The size of the dynamic stack allocation here is bounded by the if()
> statement. However, just allocating the maximum size up-front and
> doing malloc() if necessary avoids code duplication (the
> i2c_setup_offset() until the invocation of ->xfer), and generates much
> better (smaller) code:
> 
> bloat-o-meter drivers/i2c/i2c-uclass.o.{0,1}
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-144 (-144)
> Function old new   delta
> dm_i2c_write 552 408-144
> Total: Before=3828, After=3684, chg -3.76%
> 
> It also makes static analysis of maximum stack usage (using the .su
> files that are automatically generated during build) easier if there
> are no lines saying "dynamic".
> 
> [This is not entirely equivalent to the existing code; this now uses
> the stack for len <= 64 rather than len <= 63, but that seems like a
> more natural limit.]
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  drivers/i2c/i2c-uclass.c | 30 --
>  1 file changed, 12 insertions(+), 18 deletions(-)

Applied to u-boot-i2c master

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v4] i2c: nuvoton: Add NPCM7xx i2c driver

[Heiko Schocher]

Hello Jim,

On 23.06.22 07:31, Jim Liu wrote:
> Add Nuvoton BMC NPCM750 i2c driver
> 
> Signed-off-by: Jim Liu 
> ---
> changes for v4:
>- remove i2c doc
> changes for v3:
>- add i2c doc
> Changes for v2:
>- use debug output in reset function
>- use clr/setbits_8
> ---
>  drivers/i2c/Kconfig|   5 +
>  drivers/i2c/Makefile   |   1 +
>  drivers/i2c/npcm-i2c.c | 631 +
>  3 files changed, 637 insertions(+)
>  create mode 100644 drivers/i2c/npcm-i2c.c

Applied to u-boot-i2c master

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH] i2c: ast_i2c: Remove SCL direct drive mode

[Heiko Schocher]

Hello Eddie,

On 11.05.22 22:52, Eddie James wrote:
> SCL direct drive mode prevents communication with devices that
> do clock stretching, so disable. The Linux driver doesn't use
> this mode, and the engine can handle clock stretching.
> 
> Signed-off-by: Eddie James 
> ---
>  drivers/i2c/ast_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-i2c master

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v3 0/9] New boards support: db845c and qcs404-evb

[Sumit Garg]

On Tue, 19 Jul 2022 at 16:31, Tom Rini  wrote:
>
> On Tue, Jul 19, 2022 at 11:01:12AM +0530, Sumit Garg wrote:
> > Hi Tom, Ramon,
> >
> > On Tue, 12 Jul 2022 at 12:42, Sumit Garg  wrote:
> > >
> > > Add support for two new boards db845c and qcs404-evb:
> > > - db845c is a 96boards compliant platform aka RB3 based on Qualcomm
> > >   SDM845 SoC.
> > > - qcs404-evb is an evaluation board from Qualcomm based on QCS404 SoC.
> > >
> > > Both these platforms have one thing in common that u-boot is chain-loaded
> > > in 64-bit mode via Android Boot Loader (ABL) which is an EFI application.
> > > For further details on chain-loading refer to platform specific
> > > documentation:
> > > - doc/board/qualcomm/sdm845.rst
> > > - doc/board/qualcomm/qcs404.rst
> > >
> > > Changes in v3:
> > > - Add clocks re-initialization for UART and eMMC for qcs404-evb.
> > > - Pick up Ramon's review tag for patches 1-7.
> > >
> > > Changes in v2:
> > > - Added patch #1 to fix DT node overrides in starqltechn-uboot.dtsi.
> > > - Updated patch #2 commit description.
> > > - Fixed a typo (s/96Board/96Boards/) in patch #5.
> > >
> > > Sumit Garg (9):
> > >   board: starqltechn: Align DT node overrides with sdm845.dtsi
> > >   arm64: dts: sdm845: Remove redundant u-boot DT properties
> > >   clocks: sdm845: Import qcom,gcc-sdm845.h
> > >   uart: sdm845: Fix debug UART pinmux
> > >   board: qualcomm: Add support for dragonboard845c
> > >   mmc: msm_sdhci: Add SDCC version 5.0.0 support
> > >   pinctrl: qcom: Add pinctrl driver for QCS404 SoC
> > >   clocks: qcom: Add clock driver for QCS404 SoC
> > >   board: qualcomm: Add support for QCS404 EVB
> > >
> >
> > Do we have any further comments on this patch-set? If there aren't any
> > then can you help picking it up?
>
> If there's no further comments, I'll pick it up in a week or two (the
> usual time between last comments and applying non-regression / critical
> bugfix patches).

Sure, thanks.

-Sumit

>
> --
> Tom

Re: [PATCH] drivers: xen: unmap Enlighten page before jumping to Linux

[Julien Grall]

Hi,

On 19/07/2022 11:45, Dmytro Firsov wrote:


On 19.07.22 12:50, Julien Grall wrote:

Hi Dmytro,

On 19/07/2022 09:52, Dmytro Firsov wrote:

This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. It
leads to repeated mapping during Enlighten initialization in Linux.
Xen did not prevent guest from this, so it works but causes weird
wierd issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not returned to allocator and contained
shared info values during Linux run.


I can't quite parse this. Do you mean the page will be marked as
reserved for Linux and therefore it will never reach Linux's page
allocator?


No, U-boot memory allocator uses real RAM pages and one of them will be
used for shared_info. Previously U-boot did not unmap it when jumped to
Linux. So, during Linux run, one of the pages that is marked as RAM in
device-tree will contain shared_info values. I don't know how it worked
previously, but it definitely will cause weird issue when Linux will try
to use it as regular RAM page.


Ok. I would suggest to reword the commit message.





Also Linux mapped it to another
place in memory again. >
Now code, that restricts repeated mapping of Enlighten page, is about
to be merged to Xen:
https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/__;!!GF_29dbcQIUBPA!2OWttkgakR7s6GUn6e60EweRQ44H-TyI-8wWzhX0vWzR33BJE_z-x_AZ0S5VBBnXwwQ73-eIQ-sNcGLf$
[lore[.]kernel[.]org]

So, without unmapping in U-boot, Linux will fail to start.


Hmmm... From a discussion with Oleksandr, I was under the impression
that this patch would also be necessary without the Xen patch merged.
This was in order to prevent a corruption of the shared page [1].


Yes, definitely, but with new patches this problem becomes critical


I would argue that it was more critical before because you would end up 
with some random corruption of the shared page. At least, Oleksandr 
patch bring up some certainty because now Linux can't boot.



and
it will block Linux boot. General problem is explained in previous
section. This patch is needed to U-boot even without new patches to Xen,
but problem became visible only after them.
See above, I think the commit message should focus on the corruption 
rather than Xen forbidding double map. So it is clear that this patch is 
not to paper over a new issue in Xen (which would technically be a 
regression) but fixing a *real* problem on any Xen version.






As discussed
on the xen-devel mailing list, to fix this issue the code should:
     1) Unmap the page
     2) Populate the area with memory using XENMEM_populate_physmap

This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.


Is U-boot mapping other shared page from Xen (e.g. grant-table...)?


Yes, but only shared_info is mapped with XENMEM_add_to_physmap, so other
drivers are not affected.


H... A grep in u-boot source shows that XENMEM_add_to_physmap is 
used to map grant-table frame. However, the driver seems to use the 
unallocated address space provided by Xen. So you are fine there.









Signed-off-by: Dmytro Firsov 
---
   drivers/xen/hypervisor.c | 31 +++
   1 file changed, 31 insertions(+)

diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
index 2560894832..9ac377b618 100644
--- a/drivers/xen/hypervisor.c
+++ b/drivers/xen/hypervisor.c
@@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
   return HYPERVISOR_shared_info;
   }
   +void unmap_shared_info(void)
+{
+    xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);


Somewhat unrelated to this patch. Can U-boot be compiled with 16K/64K
page granularity?


I am using it on Armv8 and U-boot have hardcoded PAGE_SHIFT==12, and
PAGE_SIZE==(1<


+    struct xen_remove_from_physmap xrfp;
+    struct xen_memory_reservation reservation;


AFAICT, there some paddings in the two structure. So I would suggest
to zero the structure (including paddings).


I did not see any padding in these structs definition in U-boot, so all
fields are initialized.


There are no explicit padding but there are some implicit one. If you 
use pahole, you will see:


struct xen_remove_from_physmap {
domid_tdomid;/* 0 2 */

/* XXX 6 bytes hole, try to pack */

xen_pfn_t  gpfn; /* 8 8 */

/* size: 16, cachelines: 1, members: 2 */
/* sum members: 10, holes: 1, sum holes: 6 */
/* last cacheline: 16 bytes */
};


struct xen_memory_reservation {
__guest_handle_64_xen_pfn_t extent_start;/* 0 8 */
xen_ulong_tnr_extents;   /* 8 8 */

Re: [PATCH v3 0/9] New boards support: db845c and qcs404-evb

[Tom Rini]

On Tue, Jul 19, 2022 at 11:01:12AM +0530, Sumit Garg wrote:
> Hi Tom, Ramon,
> 
> On Tue, 12 Jul 2022 at 12:42, Sumit Garg  wrote:
> >
> > Add support for two new boards db845c and qcs404-evb:
> > - db845c is a 96boards compliant platform aka RB3 based on Qualcomm
> >   SDM845 SoC.
> > - qcs404-evb is an evaluation board from Qualcomm based on QCS404 SoC.
> >
> > Both these platforms have one thing in common that u-boot is chain-loaded
> > in 64-bit mode via Android Boot Loader (ABL) which is an EFI application.
> > For further details on chain-loading refer to platform specific
> > documentation:
> > - doc/board/qualcomm/sdm845.rst
> > - doc/board/qualcomm/qcs404.rst
> >
> > Changes in v3:
> > - Add clocks re-initialization for UART and eMMC for qcs404-evb.
> > - Pick up Ramon's review tag for patches 1-7.
> >
> > Changes in v2:
> > - Added patch #1 to fix DT node overrides in starqltechn-uboot.dtsi.
> > - Updated patch #2 commit description.
> > - Fixed a typo (s/96Board/96Boards/) in patch #5.
> >
> > Sumit Garg (9):
> >   board: starqltechn: Align DT node overrides with sdm845.dtsi
> >   arm64: dts: sdm845: Remove redundant u-boot DT properties
> >   clocks: sdm845: Import qcom,gcc-sdm845.h
> >   uart: sdm845: Fix debug UART pinmux
> >   board: qualcomm: Add support for dragonboard845c
> >   mmc: msm_sdhci: Add SDCC version 5.0.0 support
> >   pinctrl: qcom: Add pinctrl driver for QCS404 SoC
> >   clocks: qcom: Add clock driver for QCS404 SoC
> >   board: qualcomm: Add support for QCS404 EVB
> >
> 
> Do we have any further comments on this patch-set? If there aren't any
> then can you help picking it up?

If there's no further comments, I'll pick it up in a week or two (the
usual time between last comments and applying non-regression / critical
bugfix patches).

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 9/9] board: sam9x60ek: remove nand init from board file

[Balamanikandan Gunasundar]

Move this out of board file as this is done by the DM based NAND flash
driver. The EBI chip select configuration, iomux and timings are
handled by the driver

Signed-off-by: Balamanikandan Gunasundar 

---
 board/atmel/sam9x60ek/sam9x60ek.c | 59 ---
 1 file changed, 59 deletions(-)

diff --git a/board/atmel/sam9x60ek/sam9x60ek.c 
b/board/atmel/sam9x60ek/sam9x60ek.c
index 7035fab878..d8d2c3a18f 100644
--- a/board/atmel/sam9x60ek/sam9x60ek.c
+++ b/board/atmel/sam9x60ek/sam9x60ek.c
@@ -24,62 +24,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 void at91_prepare_cpu_var(void);
 
-#ifdef CONFIG_CMD_NAND
-static void sam9x60ek_nand_hw_init(void)
-{
-   struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
-   struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR;
-   unsigned int csa;
-
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 0, 1);   /* NAND OE */
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 1, 1);   /* NAND WE */
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 2, 0);   /* NAND ALE */
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 3, 0);   /* NAND CLE */
-   /* Enable NandFlash */
-   at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
-   /* Configure RDY/BSY */
-   at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 6, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 7, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 8, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 9, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 10, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 11, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 12, 1);
-   at91_pio3_set_a_periph(AT91_PIO_PORTD, 13, 1);
-
-   at91_periph_clk_enable(ATMEL_ID_PIOD);
-
-   /* Enable CS3 */
-   csa = readl(>ebicsa);
-   csa |= AT91_SFR_CCFG_EBI_CSA(3, 1) | AT91_SFR_CCFG_NFD0_ON_D16;
-
-   /* Configure IO drive */
-   csa &= ~AT91_SFR_CCFG_EBI_DRIVE_SAM9X60;
-
-   writel(csa, >ebicsa);
-
-   /* Configure SMC CS3 for NAND/SmartMedia */
-   writel(AT91_SMC_SETUP_NWE(4), >cs[3].setup);
-
-   writel(AT91_SMC_PULSE_NWE(10) | AT91_SMC_PULSE_NCS_WR(20) |
-  AT91_SMC_PULSE_NRD(10) | AT91_SMC_PULSE_NCS_RD(20),
-  >cs[3].pulse);
-
-   writel(AT91_SMC_CYCLE_NWE(20) | AT91_SMC_CYCLE_NRD(20),
-  >cs[3].cycle);
-
-   writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
-#ifdef CONFIG_SYS_NAND_DBW_16
-  AT91_SMC_MODE_DBW_16 |
-#else /* CONFIG_SYS_NAND_DBW_8 */
-  AT91_SMC_MODE_DBW_8 |
-#endif
-  AT91_SMC_MODE_TDF | AT91_SMC_MODE_TDF_CYCLE(15),
-  >cs[3].mode);
-}
-#endif
-
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
@@ -122,9 +66,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
 
-#ifdef CONFIG_CMD_NAND
-   sam9x60ek_nand_hw_init();
-#endif
return 0;
 }
 
-- 
2.25.1

[PATCH 8/9] ARM: dts: at91: sam9x60ek: Enable NAND support

[Balamanikandan Gunasundar]

Enable the EBI and NAND flash controller. Define the pinctrl and
partition table

Signed-off-by: Balamanikandan Gunasundar 

---
 arch/arm/dts/sam9x60ek.dts | 103 +
 1 file changed, 103 insertions(+)

diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
index 54c694bd78..6cb81dd90f 100644
--- a/arch/arm/dts/sam9x60ek.dts
+++ b/arch/arm/dts/sam9x60ek.dts
@@ -80,6 +80,44 @@
};
 
pinctrl {
+   nand {
+   pinctrl_nand_oe_we: 
nand-oe-we-0 {
+   atmel,pins =
+   ;
+   };
+
+   pinctrl_nand_rb: nand-rb-0 {
+   atmel,pins =
+   ;
+   };
+
+   pinctrl_nand_cs: nand-cs-0 {
+   atmel,pins =
+   ;
+   };
+   };
+
+   ebi {
+   pinctrl_ebi_data_0_7: 
ebi-data-lsb-0 {
+   atmel,pins =
+   ;
+   };
+
+   pinctrl_ebi_addr_nand: 
ebi-addr-0 {
+   atmel,pins =
+   ;
+   };
+   };
+
pinctrl_qspi: qspi {
atmel,pins =
;
+   status = "okay";
+
+   nand_controller: nand-controller {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_oe_we _nand_cs 
_nand_rb>;
+   status = "okay";
+
+   nand@3 {
+   reg = <0x3 0x0 0x80>;
+   rb-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   cs-gpios = < 4 GPIO_ACTIVE_HIGH>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <8>;
+   nand-ecc-step-size = <512>;
+   nand-on-flash-bbt;
+   label = "atmel_nand";
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   at91bootstrap@0 {
+   label = "at91bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   uboot@4 {
+   label = "u-boot";
+   reg = <0x4 0xc>;
+   };
+
+   ubootenvred@10 {
+   label = "U-Boot Env Redundant";
+   reg = <0x10 0x4>;
+   };
+
+   ubootenv@14 {
+   label = "U-Boot Env";
+   reg = <0x14 0x4>;
+   };
+
+   dtb@18 {
+   label = "device tree";
+   reg = <0x18 0x8>;
+   };
+
+   kernel@20 {
+   label = "kernel";
+   reg = <0x20 0x60>;
+   };
+
+   rootfs@80 {
+   label = "rootfs";
+   reg = <0x80 0x1f80>;
+   };
+   };
+   };
+   };
+};
+
  {
phy-mode = "rmii";
status = "okay";
-- 
2.25.1

[PATCH 7/9] ARM: dts: at91: sam9x60: Add nodes for EBI and NAND

[Balamanikandan Gunasundar]

Add new bindings for EBI and NAND controller

Signed-off-by: Balamanikandan Gunasundar 

---
 arch/arm/dts/sam9x60.dtsi | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/dts/sam9x60.dtsi b/arch/arm/dts/sam9x60.dtsi
index a5c429eb3a..17224ef771 100644
--- a/arch/arm/dts/sam9x60.dtsi
+++ b/arch/arm/dts/sam9x60.dtsi
@@ -69,6 +69,32 @@
#size-cells = <1>;
ranges;
 
+   ebi: ebi@1000 {
+   compatible = "microchip,sam9x60-ebi";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   atmel,smc = <>;
+   microchip,sfr = <>;
+   reg = <0x1000 0x6000>;
+   ranges = <0x0 0x0 0x1000 0x1000
+ 0x1 0x0 0x2000 0x1000
+ 0x2 0x0 0x3000 0x1000
+ 0x3 0x0 0x4000 0x1000
+ 0x4 0x0 0x5000 0x1000
+ 0x5 0x0 0x6000 0x1000>;
+   clocks = < PMC_TYPE_CORE 11>;
+   status = "disabled";
+
+   nand_controller: nand-controller {
+   compatible = 
"microchip,sam9x60-nand-controller";
+   ecc-engine = <>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges;
+   status = "disabled";
+   };
+   };
+
sdhci0: sdhci-host@8000 {
compatible = "microchip,sam9x60-sdhci";
reg = <0x8000 0x300>;
@@ -119,6 +145,11 @@
status = "disabled";
};
 
+   sfr: sfr@f805 {
+   compatible = "microchip,sam9x60-sfr", "syscon";
+   reg = <0xf805 0x100>;
+   };
+
dbgu: serial@f200 {
compatible = "atmel,at91sam9260-dbgu", 
"atmel,at91sam9260-usart";
reg = <0xf200 0x200>;
@@ -182,6 +213,17 @@
};
};
 
+   pmecc: ecc-engine@e000 {
+   compatible = "microchip,sam9x60-pmecc", 
"atmel,at91sam9g45-pmecc";
+   reg = <0xe000 0x300>,
+ <0xe600 0x100>;
+   };
+
+   smc: smc@ea00 {
+   compatible = "microchip,sam9x60-smc", 
"atmel,at91sam9260-smc", "syscon";
+   reg = <0xea00 0x100>;
+   };
+
pioA: gpio@f400 {
compatible = "atmel,at91sam9x5-gpio", 
"atmel,at91rm9200-gpio";
reg = <0xf400 0x200>;
-- 
2.25.1

[PATCH 6/9] configs: at91: sam9x60ek: Enable DM based nand driver

[Balamanikandan Gunasundar]

Enable Device model supported NAND driver and remove legacy Atmel NAND
driver

Signed-off-by: Balamanikandan Gunasundar 

---
 configs/sam9x60ek_mmc_defconfig   | 9 ++---
 configs/sam9x60ek_nandflash_defconfig | 9 ++---
 configs/sam9x60ek_qspiflash_defconfig | 8 +---
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/configs/sam9x60ek_mmc_defconfig b/configs/sam9x60ek_mmc_defconfig
index c50aa6b5c5..d989681eb6 100644
--- a/configs/sam9x60ek_mmc_defconfig
+++ b/configs/sam9x60ek_mmc_defconfig
@@ -53,6 +53,8 @@ CONFIG_ENV_IS_IN_FAT=y
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_CLK=y
 CONFIG_CLK_CCF=y
 CONFIG_CLK_AT91=y
@@ -62,15 +64,16 @@ CONFIG_CPU=y
 CONFIG_AT91_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_AT91=y
+CONFIG_ATMEL_EBI=y
+CONFIG_MFD_ATMEL_SMC=y
 CONFIG_I2C_EEPROM=y
 CONFIG_MICROCHIP_FLEXCOM=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ATMEL=y
 CONFIG_MTD=y
+CONFIG_DM_MTD=y
 CONFIG_MTD_RAW_NAND=y
-CONFIG_NAND_ATMEL=y
-CONFIG_ATMEL_NAND_HW_PMECC=y
-CONFIG_PMECC_CAP=8
+CONFIG_DM_NAND_ATMEL=y
 CONFIG_SYS_NAND_ONFI_DETECTION=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SF_DEFAULT_SPEED=5000
diff --git a/configs/sam9x60ek_nandflash_defconfig 
b/configs/sam9x60ek_nandflash_defconfig
index d8d2383fed..6bc78a73e2 100644
--- a/configs/sam9x60ek_nandflash_defconfig
+++ b/configs/sam9x60ek_nandflash_defconfig
@@ -55,6 +55,8 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_CLK=y
 CONFIG_CLK_CCF=y
 CONFIG_CLK_AT91=y
@@ -64,14 +66,15 @@ CONFIG_CPU=y
 CONFIG_AT91_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_AT91=y
+CONFIG_ATMEL_EBI=y
+CONFIG_MFD_ATMEL_SMC=y
 CONFIG_I2C_EEPROM=y
 CONFIG_MICROCHIP_FLEXCOM=y
 CONFIG_GENERIC_ATMEL_MCI=y
 CONFIG_MTD=y
+CONFIG_DM_MTD=y
 # CONFIG_SYS_NAND_USE_FLASH_BBT is not set
-CONFIG_NAND_ATMEL=y
-CONFIG_ATMEL_NAND_HW_PMECC=y
-CONFIG_PMECC_CAP=8
+CONFIG_DM_NAND_ATMEL=y
 CONFIG_SYS_NAND_ONFI_DETECTION=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SF_DEFAULT_SPEED=5000
diff --git a/configs/sam9x60ek_qspiflash_defconfig 
b/configs/sam9x60ek_qspiflash_defconfig
index fc4108cdc4..b466fc942f 100644
--- a/configs/sam9x60ek_qspiflash_defconfig
+++ b/configs/sam9x60ek_qspiflash_defconfig
@@ -71,9 +71,6 @@ CONFIG_MTD=y
 CONFIG_DM_MTD=y
 CONFIG_MTD_RAW_NAND=y
 # CONFIG_SYS_NAND_USE_FLASH_BBT is not set
-CONFIG_NAND_ATMEL=y
-CONFIG_ATMEL_NAND_HW_PMECC=y
-CONFIG_PMECC_CAP=8
 CONFIG_SYS_NAND_ONFI_DETECTION=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
@@ -101,3 +98,8 @@ CONFIG_W1_GPIO=y
 CONFIG_W1_EEPROM=y
 CONFIG_W1_EEPROM_DS24XXX=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_ATMEL_EBI=y
+CONFIG_MFD_ATMEL_SMC=y
+CONFIG_DM_NAND_ATMEL=y
-- 
2.25.1

[PATCH 5/9] mfd: syscon: atmel-smc: Add driver for atmel SMC

[Balamanikandan Gunasundar]

Add driver for atmel Static Memory Controller. Add helper functions to
configure SMC. This file is inherited from the work done by Boris
Brezillon for Linux

Signed-off-by: Balamanikandan Gunasundar 

---
 drivers/Kconfig  |   2 +
 drivers/Makefile |   1 +
 drivers/mfd/Kconfig  |   4 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/atmel-smc.c  | 364 +++
 include/linux/mfd/syscon/atmel-smc.h | 119 +
 6 files changed, 491 insertions(+)
 create mode 100644 drivers/mfd/Kconfig
 create mode 100644 drivers/mfd/Makefile
 create mode 100644 drivers/mfd/atmel-smc.c
 create mode 100644 include/linux/mfd/syscon/atmel-smc.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 8b6fead351..ffc06ed65e 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -60,6 +60,8 @@ source "drivers/mailbox/Kconfig"
 
 source "drivers/memory/Kconfig"
 
+source "drivers/mfd/Kconfig"
+
 source "drivers/misc/Kconfig"
 
 source "drivers/mmc/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index d63fd1c04d..2c62b8eb5d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_QE) += qe/
 obj-$(CONFIG_U_QE) += qe/
 obj-y += mailbox/
 obj-y += memory/
+obj-y += mfd/
 obj-y += mtd/
 obj-y += pwm/
 obj-y += reset/
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
new file mode 100644
index 00..ae53b02f27
--- /dev/null
+++ b/drivers/mfd/Kconfig
@@ -0,0 +1,4 @@
+config MFD_ATMEL_SMC
+   bool "Atmel Static Memory Controller driver"
+   help
+   Say yes here to support Atmel Static Memory Controller driver.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
new file mode 100644
index 00..4454815a98
--- /dev/null
+++ b/drivers/mfd/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MFD_ATMEL_SMC) += atmel-smc.o
diff --git a/drivers/mfd/atmel-smc.c b/drivers/mfd/atmel-smc.c
new file mode 100644
index 00..15296f71a1
--- /dev/null
+++ b/drivers/mfd/atmel-smc.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Atmel SMC (Static Memory Controller) helper functions.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc.
+ * Copyright (C) 2017 Free Electrons
+ *
+ * Author: Boris Brezillon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * atmel_smc_cs_conf_init - initialize a SMC CS conf
+ * @conf: the SMC CS conf to initialize
+ *
+ * Set all fields to 0 so that one can start defining a new config.
+ */
+void atmel_smc_cs_conf_init(struct atmel_smc_cs_conf *conf)
+{
+   memset(conf, 0, sizeof(*conf));
+}
+EXPORT_SYMBOL_GPL(atmel_smc_cs_conf_init);
+
+/**
+ * atmel_smc_cs_encode_ncycles - encode a number of MCK clk cycles in the
+ *  format expected by the SMC engine
+ * @ncycles: number of MCK clk cycles
+ * @msbpos: position of the MSB part of the timing field
+ * @msbwidth: width of the MSB part of the timing field
+ * @msbfactor: factor applied to the MSB
+ * @encodedval: param used to store the encoding result
+ *
+ * This function encodes the @ncycles value as described in the datasheet
+ * (section "SMC Setup/Pulse/Cycle/Timings Register"). This is a generic
+ * helper which called with different parameter depending on the encoding
+ * scheme.
+ *
+ * If the @ncycles value is too big to be encoded, -ERANGE is returned and
+ * the encodedval is contains the maximum val. Otherwise, 0 is returned.
+ */
+static int atmel_smc_cs_encode_ncycles(unsigned int ncycles,
+  unsigned int msbpos,
+  unsigned int msbwidth,
+  unsigned int msbfactor,
+  unsigned int *encodedval)
+{
+   unsigned int lsbmask = GENMASK(msbpos - 1, 0);
+   unsigned int msbmask = GENMASK(msbwidth - 1, 0);
+   unsigned int msb, lsb;
+   int ret = 0;
+
+   msb = ncycles / msbfactor;
+   lsb = ncycles % msbfactor;
+
+   if (lsb > lsbmask) {
+   lsb = 0;
+   msb++;
+   }
+
+   /*
+* Let's just put the maximum we can if the requested setting does
+* not fit in the register field.
+* We still return -ERANGE in case the caller cares.
+*/
+   if (msb > msbmask) {
+   msb = msbmask;
+   lsb = lsbmask;
+   ret = -ERANGE;
+   }
+
+   *encodedval = (msb << msbpos) | lsb;
+
+   return ret;
+}
+
+/**
+ * atmel_smc_cs_conf_set_timing - set the SMC CS conf Txx parameter to a
+ *   specific value
+ * @conf: SMC CS conf descriptor
+ * @shift: the position of the Txx field in the TIMINGS register
+ * @ncycles: value (expressed in MCK clk cycles) to assign to this Txx
+ *  parameter
+ *
+ * This function encodes the @ncycles value as described in the datasheet
+ * (section "SMC Timings Register"), and then stores the result in 

[PATCH 4/9] memory: atmel-ebi: add Atmel EBI (External Bus Interface) driver

[Balamanikandan Gunasundar]

The EBI is used to access peripherals like NAND, SRAM, NOR etc. Add
this driver to probe the nand flash controller. This is a dummy driver
and not yet a complete device driver for EBI.

Signed-off-by: Balamanikandan Gunasundar 

---
 MAINTAINERS|  1 +
 drivers/memory/Kconfig |  7 +++
 drivers/memory/Makefile|  1 +
 drivers/memory/atmel_ebi.c | 37 +
 4 files changed, 46 insertions(+)
 create mode 100644 drivers/memory/atmel_ebi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1baa038da7..cdf1774fa3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -385,6 +385,7 @@ T:  git 
https://source.denx.de/u-boot/custodians/u-boot-atmel.git
 F: arch/arm/mach-at91/
 F: board/atmel/
 F: drivers/cpu/at91_cpu.c
+F: drivers/memory/atmel-ebi.c
 F: drivers/misc/microchip_flexcom.c
 F: drivers/timer/atmel_tcb_timer.c
 F: include/dt-bindings/mfd/atmel-flexcom.h
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 7271892763..759151a452 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -24,4 +24,11 @@ config TI_AEMIF
  of 256M bytes of any of these memories can be accessed at a given
  time via four chip selects with 64M byte access per chip select.
 
+config ATMEL_EBI
+   bool "Support for Atmel EBI"
+   help
+ Driver for Atmel EBI controller. This is a dummy
+ driver. Doesn't provide an access to EBI controller. Select
+ this option to enable the NAND flash controller driver
+
 endmenu
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index fec52efb60..1d24009e86 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -1,3 +1,4 @@
 
 obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
+obj-$(CONFIG_ATMEL_EBI) += atmel_ebi.o
 obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
diff --git a/drivers/memory/atmel_ebi.c b/drivers/memory/atmel_ebi.c
new file mode 100644
index 00..4739eef1b7
--- /dev/null
+++ b/drivers/memory/atmel_ebi.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static int atmel_ebi_probe(struct udevice *dev)
+{
+   int ret;
+   struct udevice *ndev;
+
+   ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_DRIVER_GET(atmel_nand_controller),
+ );
+   if (ret)
+   printf("Failed to probe nand driver (err = %d)\n", ret);
+
+   return ret;
+}
+
+static const struct udevice_id atmel_ebi_match[] = {
+   {.compatible = "microchip,sam9x60-ebi"},
+   {.compatible = "atmel,sama5d3-ebi"},
+   { /* Sentinel */ }
+};
+
+U_BOOT_DRIVER(atmel_ebi) = {
+   .name = "atmel_ebi",
+   .id = UCLASS_NOP,
+   .of_match = atmel_ebi_match,
+   .probe = atmel_ebi_probe,
+   .bind = dm_scan_fdt_dev,
+};
-- 
2.25.1

[PATCH 3/9] mfd: syscon: Add atmel-matrix registers definition

[Balamanikandan Gunasundar]

This file is copied from Linux. AT91 SoCs have a memory range reserved
for internal bus configuration. Expose those registers so that drivers
can make use of the matrix syscon declared in at91 DTs.

Signed-off-by: Balamanikandan Gunasundar 

---
 include/linux/mfd/syscon/atmel-matrix.h | 112 
 1 file changed, 112 insertions(+)
 create mode 100644 include/linux/mfd/syscon/atmel-matrix.h

diff --git a/include/linux/mfd/syscon/atmel-matrix.h 
b/include/linux/mfd/syscon/atmel-matrix.h
new file mode 100644
index 00..dd228cab67
--- /dev/null
+++ b/include/linux/mfd/syscon/atmel-matrix.h
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ *  Copyright (C) 2014 Atmel Corporation.
+ *
+ * Memory Controllers (MATRIX, EBI) - System peripherals registers.
+ */
+
+#ifndef _LINUX_MFD_SYSCON_ATMEL_MATRIX_H
+#define _LINUX_MFD_SYSCON_ATMEL_MATRIX_H
+
+#define AT91SAM9260_MATRIX_MCFG0x00
+#define AT91SAM9260_MATRIX_SCFG0x40
+#define AT91SAM9260_MATRIX_PRS 0x80
+#define AT91SAM9260_MATRIX_MRCR0x100
+#define AT91SAM9260_MATRIX_EBICSA  0x11c
+
+#define AT91SAM9261_MATRIX_MRCR0x0
+#define AT91SAM9261_MATRIX_SCFG0x4
+#define AT91SAM9261_MATRIX_TCR 0x24
+#define AT91SAM9261_MATRIX_EBICSA  0x30
+#define AT91SAM9261_MATRIX_USBPUCR 0x34
+
+#define AT91SAM9263_MATRIX_MCFG0x00
+#define AT91SAM9263_MATRIX_SCFG0x40
+#define AT91SAM9263_MATRIX_PRS 0x80
+#define AT91SAM9263_MATRIX_MRCR0x100
+#define AT91SAM9263_MATRIX_TCR 0x114
+#define AT91SAM9263_MATRIX_EBI0CSA 0x120
+#define AT91SAM9263_MATRIX_EBI1CSA 0x124
+
+#define AT91SAM9RL_MATRIX_MCFG 0x00
+#define AT91SAM9RL_MATRIX_SCFG 0x40
+#define AT91SAM9RL_MATRIX_PRS  0x80
+#define AT91SAM9RL_MATRIX_MRCR 0x100
+#define AT91SAM9RL_MATRIX_TCR  0x114
+#define AT91SAM9RL_MATRIX_EBICSA   0x120
+
+#define AT91SAM9G45_MATRIX_MCFG0x00
+#define AT91SAM9G45_MATRIX_SCFG0x40
+#define AT91SAM9G45_MATRIX_PRS 0x80
+#define AT91SAM9G45_MATRIX_MRCR0x100
+#define AT91SAM9G45_MATRIX_TCR 0x110
+#define AT91SAM9G45_MATRIX_DDRMPR  0x118
+#define AT91SAM9G45_MATRIX_EBICSA  0x128
+
+#define AT91SAM9N12_MATRIX_MCFG0x00
+#define AT91SAM9N12_MATRIX_SCFG0x40
+#define AT91SAM9N12_MATRIX_PRS 0x80
+#define AT91SAM9N12_MATRIX_MRCR0x100
+#define AT91SAM9N12_MATRIX_EBICSA  0x118
+
+#define AT91SAM9X5_MATRIX_MCFG 0x00
+#define AT91SAM9X5_MATRIX_SCFG 0x40
+#define AT91SAM9X5_MATRIX_PRS  0x80
+#define AT91SAM9X5_MATRIX_MRCR 0x100
+#define AT91SAM9X5_MATRIX_EBICSA   0x120
+
+#define SAMA5D3_MATRIX_MCFG0x00
+#define SAMA5D3_MATRIX_SCFG0x40
+#define SAMA5D3_MATRIX_PRS 0x80
+#define SAMA5D3_MATRIX_MRCR0x100
+
+#define AT91_MATRIX_MCFG(o, x) ((o) + ((x) * 0x4))
+#define AT91_MATRIX_ULBT   GENMASK(2, 0)
+#define AT91_MATRIX_ULBT_INFINITE  (0 << 0)
+#define AT91_MATRIX_ULBT_SINGLE(1 << 0)
+#define AT91_MATRIX_ULBT_FOUR  (2 << 0)
+#define AT91_MATRIX_ULBT_EIGHT (3 << 0)
+#define AT91_MATRIX_ULBT_SIXTEEN   (4 << 0)
+
+#define AT91_MATRIX_SCFG(o, x) ((o) + ((x) * 0x4))
+#define AT91_MATRIX_SLOT_CYCLE GENMASK(7,  0)
+#define AT91_MATRIX_DEFMSTR_TYPE   GENMASK(17, 16)
+#define AT91_MATRIX_DEFMSTR_TYPE_NONE  (0 << 16)
+#define AT91_MATRIX_DEFMSTR_TYPE_LAST  (1 << 16)
+#define AT91_MATRIX_DEFMSTR_TYPE_FIXED (2 << 16)
+#define AT91_MATRIX_FIXED_DEFMSTR  GENMASK(20, 18)
+#define AT91_MATRIX_ARBT   GENMASK(25, 24)
+#define AT91_MATRIX_ARBT_ROUND_ROBIN   (0 << 24)
+#define AT91_MATRIX_ARBT_FIXED_PRIORITY(1 << 24)
+
+#define AT91_MATRIX_ITCM_SIZE  GENMASK(3, 0)
+#define AT91_MATRIX_ITCM_0 (0 << 0)
+#define AT91_MATRIX_ITCM_16(5 << 0)
+#define AT91_MATRIX_ITCM_32(6 << 0)
+#define AT91_MATRIX_ITCM_64(7 << 0)
+#defineAT91_MATRIX_DTCM_SIZE   GENMASK(7, 4)
+#defineAT91_MATRIX_DTCM_0  (0 << 4)
+#defineAT91_MATRIX_DTCM_16 (5 << 4)
+#define AT91_MATRIX_DTCM_32(6 << 4)
+#define AT91_MATRIX_DTCM_64

[PATCH 2/9] nand: atmel: Add pmecc driver

[Balamanikandan Gunasundar]

Add driver for atmel pmecc.

Signed-off-by: Balamanikandan Gunasundar 

---
 drivers/mtd/nand/raw/atmel/Makefile |   3 +-
 drivers/mtd/nand/raw/atmel/pmecc.c  | 969 
 drivers/mtd/nand/raw/atmel/pmecc.h  |  94 +++
 3 files changed, 1065 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/raw/atmel/pmecc.c
 create mode 100644 drivers/mtd/nand/raw/atmel/pmecc.h

diff --git a/drivers/mtd/nand/raw/atmel/Makefile 
b/drivers/mtd/nand/raw/atmel/Makefile
index 6708416983..e044ff55ba 100644
--- a/drivers/mtd/nand/raw/atmel/Makefile
+++ b/drivers/mtd/nand/raw/atmel/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_DM_NAND_ATMEL)+= atmel-nand-controller.o
+obj-$(CONFIG_DM_NAND_ATMEL)+= atmel-nand-controller.o atmel-pmecc.o
 
 atmel-nand-controller-objs := nand-controller.o
+atmel-pmecc-objs   := pmecc.o
diff --git a/drivers/mtd/nand/raw/atmel/pmecc.c 
b/drivers/mtd/nand/raw/atmel/pmecc.c
new file mode 100644
index 00..0a08674d11
--- /dev/null
+++ b/drivers/mtd/nand/raw/atmel/pmecc.c
@@ -0,0 +1,969 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2017 ATMEL
+ * Copyright 2017 Free Electrons
+ *
+ * Author: Boris Brezillon 
+ *
+ * Derived from the atmel_nand.c driver which contained the following
+ * copyrights:
+ *
+ *   Copyright 2003 Rick Bronson
+ *
+ *   Derived from drivers/mtd/nand/autcpu12.c (removed in v3.8)
+ * Copyright 2001 Thomas Gleixner (gleix...@autronix.de)
+ *
+ *   Derived from drivers/mtd/spia.c (removed in v3.8)
+ * Copyright 2000 Steven J. Hill (sjh...@cotw.com)
+ *
+ *   Add Hardware ECC support for AT91SAM9260 / AT91SAM9263
+ * Richard Genoud (richard.gen...@gmail.com), Adeneo Copyright 2007
+ *
+ *   Derived from Das U-Boot source code
+ * (u-boot-1.1.5/board/atmel/at91sam9263ek/nand.c)
+ *  Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas
+ *
+ *   Add Programmable Multibit ECC support for various AT91 SoC
+ * Copyright 2012 ATMEL, Hong Xu
+ *
+ *   Add Nand Flash Controller support for SAMA5 SoC
+ * Copyright 2013 ATMEL, Josh Wu (josh...@atmel.com)
+ *
+ * The PMECC is an hardware assisted BCH engine, which means part of the
+ * ECC algorithm is left to the software. The hardware/software repartition
+ * is explained in the "PMECC Controller Functional Description" chapter in
+ * Atmel datasheets, and some of the functions in this file are directly
+ * implementing the algorithms described in the "Software Implementation"
+ * sub-section.
+ *
+ * TODO: it seems that the software BCH implementation in lib/bch.c is already
+ * providing some of the logic we are implementing here. It would be smart
+ * to expose the needed lib/bch.c helpers/functions and re-use them here.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pmecc.h"
+#include 
+#include 
+#include 
+#include 
+
+/* Galois field dimension */
+#define PMECC_GF_DIMENSION_13  13
+#define PMECC_GF_DIMENSION_14  14
+
+/* Primitive Polynomial used by PMECC */
+#define PMECC_GF_13_PRIMITIVE_POLY 0x201b
+#define PMECC_GF_14_PRIMITIVE_POLY 0x4443
+
+#define PMECC_LOOKUP_TABLE_SIZE_5120x2000
+#define PMECC_LOOKUP_TABLE_SIZE_1024   0x4000
+
+/* Time out value for reading PMECC status register */
+#define PMECC_MAX_TIMEOUT_MS   100
+
+/* PMECC Register Definitions */
+#define ATMEL_PMECC_CFG0x0
+#define PMECC_CFG_BCH_STRENGTH(x)  (x)
+#define PMECC_CFG_BCH_STRENGTH_MASKGENMASK(2, 0)
+#define PMECC_CFG_SECTOR512(0 << 4)
+#define PMECC_CFG_SECTOR1024   BIT(4)
+#define PMECC_CFG_NSECTORS(x)  ((fls(x) - 1) << 8)
+#define PMECC_CFG_READ_OP  (0 << 12)
+#define PMECC_CFG_WRITE_OP BIT(12)
+#define PMECC_CFG_SPARE_ENABLE BIT(16)
+#define PMECC_CFG_AUTO_ENABLE  BIT(20)
+
+#define ATMEL_PMECC_SAREA  0x4
+#define ATMEL_PMECC_SADDR  0x8
+#define ATMEL_PMECC_EADDR  0xc
+
+#define ATMEL_PMECC_CLK0x10
+#define PMECC_CLK_133MHZ   (2 << 0)
+
+#define ATMEL_PMECC_CTRL   0x14
+#define PMECC_CTRL_RST BIT(0)
+#define PMECC_CTRL_DATABIT(1)
+#define PMECC_CTRL_USERBIT(2)
+#define PMECC_CTRL_ENABLE  BIT(4)
+#define PMECC_CTRL_DISABLE BIT(5)
+
+#define ATMEL_PMECC_SR 0x18
+#define PMECC_SR_BUSY  BIT(0)
+#define PMECC_SR_ENABLEBIT(4)
+
+#define ATMEL_PMECC_IER0x1c
+#define ATMEL_PMECC_IDR0x20
+#define ATMEL_PMECC_IMR 

[PATCH 1/9] nand: atmel: Add DM based NAND driver

[Balamanikandan Gunasundar]

This implementation is ported from the rework done by Boris Brezillon
in Linux. The driver is tested in sam9x60ek, sama5d3_xplained,
sam9x75eb and sama7g54-ddr3-eb.

Signed-off-by: Balamanikandan Gunasundar 

---
 drivers/mtd/nand/raw/Kconfig |8 +
 drivers/mtd/nand/raw/Makefile|1 +
 drivers/mtd/nand/raw/atmel/Makefile  |4 +
 drivers/mtd/nand/raw/atmel/nand-controller.c | 2300 ++
 4 files changed, 2313 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/atmel/Makefile
 create mode 100644 drivers/mtd/nand/raw/atmel/nand-controller.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 190300fc17..c795310c5d 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -37,6 +37,14 @@ config SYS_NAND_USE_FLASH_BBT
help
  Enable the BBT (Bad Block Table) usage.
 
+config DM_NAND_ATMEL
+   bool "Support Atmel NAND controller with DM support"
+   select SYS_NAND_SELF_INIT
+   imply SYS_NAND_USE_FLASH_BBT
+   help
+ Enable this driver for NAND flash platforms using an Atmel NAND
+ controller.
+
 config NAND_ATMEL
bool "Support Atmel NAND controller"
select SYS_NAND_SELF_INIT
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index e3f6b903f7..a3acf3cbb3 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -40,6 +40,7 @@ ifdef NORMAL_DRIVERS
 obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o
 
 obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o
+obj-$(CONFIG_DM_NAND_ATMEL) += atmel/
 obj-$(CONFIG_NAND_ARASAN) += arasan_nfc.o
 obj-$(CONFIG_NAND_BRCMNAND) += brcmnand/
 obj-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
diff --git a/drivers/mtd/nand/raw/atmel/Makefile 
b/drivers/mtd/nand/raw/atmel/Makefile
new file mode 100644
index 00..6708416983
--- /dev/null
+++ b/drivers/mtd/nand/raw/atmel/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DM_NAND_ATMEL)+= atmel-nand-controller.o
+
+atmel-nand-controller-objs := nand-controller.o
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c 
b/drivers/mtd/nand/raw/atmel/nand-controller.c
new file mode 100644
index 00..87166b005d
--- /dev/null
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -0,0 +1,2300 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2022 ATMEL
+ * Copyright 2017 Free Electrons
+ *
+ * Author: Boris Brezillon 
+ *
+ * Derived from the atmel_nand.c driver which contained the following
+ * copyrights:
+ *
+ *   Copyright 2003 Rick Bronson
+ *
+ *   Derived from drivers/mtd/nand/autcpu12.c (removed in v3.8)
+ * Copyright 2001 Thomas Gleixner (gleix...@autronix.de)
+ *
+ *   Derived from drivers/mtd/spia.c (removed in v3.8)
+ * Copyright 2000 Steven J. Hill (sjh...@cotw.com)
+ *
+ *
+ *   Add Hardware ECC support for AT91SAM9260 / AT91SAM9263
+ * Richard Genoud (richard.gen...@gmail.com), Adeneo Copyright 2007
+ *
+ *   Derived from Das U-Boot source code
+ * (u-boot-1.1.5/board/atmel/at91sam9263ek/nand.c)
+ * Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas
+ *
+ *   Add Programmable Multibit ECC support for various AT91 SoC
+ * Copyright 2012 ATMEL, Hong Xu
+ *
+ *   Add Nand Flash Controller support for SAMA5 SoC
+ * Copyright 2013 ATMEL, Josh Wu (josh...@atmel.com)
+ *
+ *   Port from Linux
+ * Balamanikandan Gunasundar(balamanikandan.gunasun...@microchip.com)
+ * Copyright (C) 2022 Microchip Technology Inc.
+ *
+ * A few words about the naming convention in this file. This convention
+ * applies to structure and function names.
+ *
+ * Prefixes:
+ *
+ * - atmel_nand_: all generic structures/functions
+ * - atmel_smc_nand_: all structures/functions specific to the SMC interface
+ *   (at91sam9 and avr32 SoCs)
+ * - atmel_hsmc_nand_: all structures/functions specific to the HSMC interface
+ *(sama5 SoCs and later)
+ * - atmel_nfc_: all structures/functions used to manipulate the NFC sub-block
+ *  that is available in the HSMC block
+ * - _nand_: all SoC specific structures/functions
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pmecc.h"
+
+#define NSEC_PER_SEC10L
+
+#define ATMEL_HSMC_NFC_CFG 0x0
+#define ATMEL_HSMC_NFC_CFG_SPARESIZE(x)(((x) / 4) << 24)
+#define ATMEL_HSMC_NFC_CFG_SPARESIZE_MASK  GENMASK(30, 24)
+#define ATMEL_HSMC_NFC_CFG_DTO(cyc, mul)   (((cyc) << 16) | ((mul) << 20))
+#define ATMEL_HSMC_NFC_CFG_DTO_MAX GENMASK(22, 16)
+#define ATMEL_HSMC_NFC_CFG_RBEDGE  BIT(13)
+#define ATMEL_HSMC_NFC_CFG_FALLING_EDGEBIT(12)
+#define ATMEL_HSMC_NFC_CFG_RSPARE  BIT(9)
+#define ATMEL_HSMC_NFC_CFG_WSPARE

[PATCH 0/9] Add DM support for atmel NAND driver

[Balamanikandan Gunasundar]

This patch series adds support for NAND flash. The series adds DM
support and replaces the existing NAND driver NAND_ATMEL. The drivers
are ported from Linux based on the work done by Boris brezillon

Balamanikandan Gunasundar (9):
  nand: atmel: Add DM based NAND driver
  nand: atmel: Add pmecc driver
  mfd: syscon: Add atmel-matrix registers definition
  memory: atmel-ebi: add Atmel EBI (External Bus Interface) driver
  mfd: syscon: atmel-smc: Add driver for atmel SMC
  configs: at91: sam9x60ek: Enable DM based nand driver
  ARM: dts: at91: sam9x60: Add nodes for EBI and NAND
  ARM: dts: at91: sam9x60ek: Enable NAND support
  board: sam9x60ek: remove nand init from board file

 MAINTAINERS  |1 +
 arch/arm/dts/sam9x60.dtsi|   42 +
 arch/arm/dts/sam9x60ek.dts   |  103 +
 board/atmel/sam9x60ek/sam9x60ek.c|   59 -
 configs/sam9x60ek_mmc_defconfig  |9 +-
 configs/sam9x60ek_nandflash_defconfig|9 +-
 configs/sam9x60ek_qspiflash_defconfig|8 +-
 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/memory/Kconfig   |7 +
 drivers/memory/Makefile  |1 +
 drivers/memory/atmel_ebi.c   |   37 +
 drivers/mfd/Kconfig  |4 +
 drivers/mfd/Makefile |1 +
 drivers/mfd/atmel-smc.c  |  364 +++
 drivers/mtd/nand/raw/Kconfig |8 +
 drivers/mtd/nand/raw/Makefile|1 +
 drivers/mtd/nand/raw/atmel/Makefile  |5 +
 drivers/mtd/nand/raw/atmel/nand-controller.c | 2300 ++
 drivers/mtd/nand/raw/atmel/pmecc.c   |  969 
 drivers/mtd/nand/raw/atmel/pmecc.h   |   94 +
 include/linux/mfd/syscon/atmel-matrix.h  |  112 +
 include/linux/mfd/syscon/atmel-smc.h |  119 +
 23 files changed, 4188 insertions(+), 68 deletions(-)
 create mode 100644 drivers/memory/atmel_ebi.c
 create mode 100644 drivers/mfd/Kconfig
 create mode 100644 drivers/mfd/Makefile
 create mode 100644 drivers/mfd/atmel-smc.c
 create mode 100644 drivers/mtd/nand/raw/atmel/Makefile
 create mode 100644 drivers/mtd/nand/raw/atmel/nand-controller.c
 create mode 100644 drivers/mtd/nand/raw/atmel/pmecc.c
 create mode 100644 drivers/mtd/nand/raw/atmel/pmecc.h
 create mode 100644 include/linux/mfd/syscon/atmel-matrix.h
 create mode 100644 include/linux/mfd/syscon/atmel-smc.h

-- 
2.25.1

Re: [RESEND v9 9/9] doc:eficonfig: add documentation for eficonfig command

[Masahisa Kojima]

Hi Ilias,

On Tue, 19 Jul 2022 at 17:03, Ilias Apalodimas
 wrote:
>
> Hello Kojima-san
>
> On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
>  wrote:
> >
> > Add documentation for eficonfig command.
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> > No change sinch v8
> >
> > Changes in v8:
> > - command name is changed from "efimenu" to "eficonfig"
> >
> > Newly created in v7
> >
> >  doc/usage/cmd/eficonfig.rst | 49 +
> >  doc/usage/index.rst |  1 +
>
> [...]
>
> > +
> > +The "eficonfig" command is enabled by::
> > +
> > +CONFIG_CMD_EFICONFIG=y
> > +
> > +If CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not enter
> > +U-Boot console. In this case, bootmenu can be used to invoke "eficonfig"::
> > +
> > +CONFIG_USE_PREBOOT=y
> > +CONFIG_PREBOOT="setenv bootmenu_0 UEFI Maintenance Menu=eficonfig"
>
> Can't we just set it as the default bootcmd? Does it have to be a
> preboot command?

"eficonfig" command is for updating UEFI variables(BOOT and
BootOrder, etc.) only.
User can not boot the system with "eficonfig" command, so I think it
is not the desired
option to set it as default bootcmd.

Thanks,
Masahisa Kojima

>
> Thanks
> /Ilias
> > +
> > +See also
> > +
> > +* :doc:`bootmenu` provides a simple mechanism for creating menus 
> > with different boot items
> > diff --git a/doc/usage/index.rst b/doc/usage/index.rst
> > index 8b98629d6b..1afbb6bc5d 100644
> > --- a/doc/usage/index.rst
> > +++ b/doc/usage/index.rst
> > @@ -35,6 +35,7 @@ Shell commands
> > cmd/conitrace
> > cmd/dm
> > cmd/echo
> > +   cmd/eficonfig
> > cmd/env
> > cmd/event
> > cmd/exception
> > --
> > 2.17.1
> >

Re: [RESEND v9 2/9] eficonfig: menu-driven addition of UEFI boot option

[Ilias Apalodimas]

Hello Kojima-san,

[...]

> +
> +/**
> + * eficonfig_process_common() - main handler for UEFI menu
> + *
> + * Construct the structures required to show the menu, then handle
> + * the user input interacting with u-boot menu functions.
> + *
> + * @items: pointer to the structure of each menu entry
> + * @count: the number of menu entry
> + * @menu_header:   pointer to the menu header string
> + * Return: status code
> + */
> +efi_status_t eficonfig_process_common(const struct eficonfig_item *items, 
> int count,
> + char *menu_header)
> +{
> +   u32 i;
> +   efi_status_t ret;
> +   struct menu *menu;
> +   void *choice = NULL;
> +   struct eficonfig_entry *entry;
> +   struct efimenu *efi_menu;
> +   struct eficonfig_entry *iter = NULL;
> +
> +   if (count > EFICONFIG_ENTRY_NUM_MAX)
> +   return EFI_OUT_OF_RESOURCES;
> +
> +   efi_menu = calloc(1, sizeof(struct efimenu));
> +   if (!efi_menu)
> +   return EFI_OUT_OF_RESOURCES;
> +
> +   efi_menu->delay = -1;
> +   efi_menu->active = 0;
> +   efi_menu->first = NULL;
> +
> +   if (menu_header) {
> +   efi_menu->menu_header = strdup(menu_header);
> +   if (!efi_menu->menu_header) {
> +   free(efi_menu);
> +   return EFI_OUT_OF_RESOURCES;
> +   }
> +   }
> +
> +   for (i = 0; i < count; i++) {
> +   entry = calloc(1, sizeof(struct eficonfig_entry));
> +   if (!entry) {
> +   ret = EFI_LOAD_ERROR;
> +   goto out;
> +   }
> +
> +   entry->num = i;
> +   entry->title = items->title;
> +   sprintf(entry->key, "%d", i);
> +   entry->efi_menu = efi_menu;
> +   entry->func = items->func;
> +   entry->data = items->data;
> +   entry->next = NULL;
> +
> +   if (!iter)
> +   efi_menu->first = entry;
> +   else
> +   iter->next = entry;

Is there a reason we aren't using list_add etc on this list?

> +
> +   iter = entry;
> +   items++;
> +   }
> +   efi_menu->count = count;
> +
> +   menu = menu_create(NULL, 0, 1, eficonfig_display_statusline,
> +  eficonfig_print_entry, eficonfig_choice_entry,
> +  efi_menu);
> +   if (!menu) {
> +   ret = EFI_INVALID_PARAMETER;
> +   goto out;
> +   }
> +
> +   for (entry = efi_menu->first; entry; entry = entry->next) {
> +   if (!menu_item_add(menu, entry->key, entry)) {
> +   ret = EFI_INVALID_PARAMETER;
> +   goto out;
> +   }
> +   }
> +

[...]

> +
> +/**
> + * eficonfig_boot_add_optional_data() - handle user input for optional data
> + *
> + * @data:  pinter to the internal boot option structure
> + * Return: status code
> + */
> +static efi_status_t eficonfig_boot_add_optional_data(void *data)
> +{
> +   u16 *tmp;
> +   efi_status_t ret;
> +   struct eficonfig_boot_option *bo = data;
> +
> +   printf(ANSI_CLEAR_CONSOLE
> +  ANSI_CURSOR_POSITION
> +  "\n  ** Edit Optional Data **\n"
> +  "\n"
> +  "  enter optional data:"
> +  ANSI_CURSOR_POSITION
> +  "  Press ENTER to complete, ESC/CTRL+C to quit",
> +  0, 1, 8, 1);
> +
> +   tmp = calloc(1, EFICONFIG_OPTIONAL_DATA_MAX * sizeof(u16));

if (!tmp)
etc

> +   ret = efi_console_get_u16_string(cin, tmp, 
> EFICONFIG_OPTIONAL_DATA_MAX, NULL, 4, 24);
> +
> +   if (ret == EFI_SUCCESS)
> +   u16_strcpy(bo->optional_data, tmp);
> +
> +   free(tmp);
> +
> +   /* to stay the parent menu */
> +   ret = (ret == EFI_ABORTED) ? EFI_NOT_READY : ret;
> +
> +   return ret;
> +}
> +
> +/**
> + * eficonfig_boot_edit_save() - handler to save the boot option
> + *
> + * @data:  pinter to the internal boot option structure

s/pinter/pointer/

[...]

> +
> +/**
> + * eficonfig_edit_boot_option() - prepare boot option structure for editing
> + *
> + * Construct the boot option structure and copy the existing value
> + *
> + * @varname:   pointer to the UEFI variable name
> + * @bo:pointer to the boot option
> + * @description:   pointer to the description
> + * @optional_data: pointer to the optional_data
> + * @optional_data_size:optional_data_size
> + * @dp:pointer to the device path
> + * @header_str:pointer to the header string
> + * Return  :   status code
> + */
> +static efi_status_t eficonfig_edit_boot_option(u16 *varname, struct 
> eficonfig_boot_option *bo,
> +  u16 

Re: [PATCH] drivers: xen: unmap Enlighten page before jumping to Linux

[Julien Grall]

Hi Dmytro,

On 19/07/2022 09:52, Dmytro Firsov wrote:

This commit fixes issue with usage of Xen hypervisor shared info page.
Previously U-boot did not unmap it at the end of OS boot process. It
leads to repeated mapping during Enlighten initialization in Linux.
Xen did not prevent guest from this, so it works but causes weird
wierd issues - one memory page, that was returned by memalign in U-boot
for Enlighten mapping was not returned to allocator and contained
shared info values during Linux run.


I can't quite parse this. Do you mean the page will be marked as 
reserved for Linux and therefore it will never reach Linux's page allocator?



Also Linux mapped it to another
place in memory again. >
Now code, that restricts repeated mapping of Enlighten page, is about
to be merged to Xen:
https://lore.kernel.org/xen-devel/20220716145658.4175730-2-olekst...@gmail.com/

So, without unmapping in U-boot, Linux will fail to start.


Hmmm... From a discussion with Oleksandr, I was under the impression 
that this patch would also be necessary without the Xen patch merged. 
This was in order to prevent a corruption of the shared page [1].



As discussed
on the xen-devel mailing list, to fix this issue the code should:
1) Unmap the page
2) Populate the area with memory using XENMEM_populate_physmap

This patch adds page unmapping via XENMEM_remove_from_physmap, fills
hole in address space where page was mapped via XENMEM_populate_physmap
and return this address to memory allocator for freeing.


Is U-boot mapping other shared page from Xen (e.g. grant-table...)?



Signed-off-by: Dmytro Firsov 
---
  drivers/xen/hypervisor.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/xen/hypervisor.c b/drivers/xen/hypervisor.c
index 2560894832..9ac377b618 100644
--- a/drivers/xen/hypervisor.c
+++ b/drivers/xen/hypervisor.c
@@ -144,6 +144,36 @@ struct shared_info *map_shared_info(void *p)
return HYPERVISOR_shared_info;
  }
  
+void unmap_shared_info(void)

+{
+   xen_pfn_t shared_info_pfn = virt_to_pfn(HYPERVISOR_shared_info);


Somewhat unrelated to this patch. Can U-boot be compiled with 16K/64K 
page granularity?



+   struct xen_remove_from_physmap xrfp;
+   struct xen_memory_reservation reservation;


AFAICT, there some paddings in the two structure. So I would suggest to 
zero the structure (including paddings).



+   xen_ulong_t nr_exts = 1;
+
+   xrfp.domid = DOMID_SELF;
+   xrfp.gpfn = shared_info_pfn;
+   if (HYPERVISOR_memory_op(XENMEM_remove_from_physmap, ) != 0)
+   BUG();


If I am not mistaken, U-boot provide a panic() helper. So I would 
suggest to use it as this would be useful to print with the error returned.



+
+   /*
+* After remove from physmap there will be a hole in address space on


Typo: s/remove/removing/


+* HYPERVISOR_shared_info address, so to free memory allocated with
+* memalign and prevent exceptions during access to this page we need to
+* fill this 4KB hole with XENMEM_populate_physmap before jumping to 
Linux.
+*/
+   reservation.domid = DOMID_SELF;
+   reservation.extent_order = 0;
+   reservation.address_bits = 0;
+   set_xen_guest_handle(reservation.extent_start, _info_pfn);
+   reservation.nr_extents = nr_exts;
+   if (HYPERVISOR_memory_op(XENMEM_populate_physmap, ) != 
nr_exts)
+   BUG();


Same here regarding using panic() rather than BUG()


+
+   /* Now we can return this to memory allocator */
+   free(HYPERVISOR_shared_info);
+}
+
  void do_hypervisor_callback(struct pt_regs *regs)
  {
unsigned long l1, l2, l1i, l2i;
@@ -251,4 +281,5 @@ void xen_fini(void)
fini_gnttab();
fini_xenbus();
fini_events();
+   unmap_shared_info();
  }


[1] 
https://github.com/xen-troops/u-boot/commit/f759b151116af204a5ab02ace82c09300cd6233a#


--
Julien Grall

binman issue on ubuntu 20.04

[Belisko Marek]

Hi,

I'm trying to compile an older u-boot (2017.03) with Ubuntu 20.04.
Machine is sunxi. COmpilation went fine but when binman assembles
u-boot-sunxi-with-spl.bin it stuck somewhere. I've enabled python
traces and it loops in forever:

subprocess.py(1668): if errpipe_data:
cros_subprocess.py(94): if stdout_pty is not None:
cros_subprocess.py(96): if stderr_pty is not None:
cros_subprocess.py(100): if kwargs:
command.py(73): while pipeline:
command.py(95): if capture:
command.py(97): last_pipe.CommunicateFilter(None))
 --- modulename: cros_subprocess, funcname: CommunicateFilter
cros_subprocess.py(144): read_set = []
cros_subprocess.py(145): write_set = []
cros_subprocess.py(146): stdout = None # Return
cros_subprocess.py(147): stderr = None # Return
cros_subprocess.py(149): if self.stdin:
cros_subprocess.py(157): if self.stdout:
cros_subprocess.py(158): read_set.append(self.stdout)
cros_subprocess.py(159): stdout = []
cros_subprocess.py(160): if self.stderr and self.stderr != self.stdout:
cros_subprocess.py(163): combined = []
cros_subprocess.py(165): input_offset = 0
cros_subprocess.py(166): while read_set or write_set:
cros_subprocess.py(167): try:
cros_subprocess.py(168): rlist, wlist, _ =
select.select(read_set, write_set, [], 0.2)
cros_subprocess.py(174): if not stay_alive:
cros_subprocess.py(177): if self.stdin in wlist:
cros_subprocess.py(188): if self.stdout in rlist:
cros_subprocess.py(189): data = ""
cros_subprocess.py(191): try:
cros_subprocess.py(192): data =
os.read(self.stdout.fileno(), 1024)
cros_subprocess.py(195): if data == "":
cros_subprocess.py(199): stdout.append(data)
cros_subprocess.py(200): combined.append(data)
cros_subprocess.py(201): if output:
cros_subprocess.py(203): if self.stderr in rlist:


Any idea if there is some fix for that or idea where to look?

Thanks and BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: [PATCH 1/1] cmd: undefined return value of do_extension_apply()

[Köry Maincent]

Hello Heinrich,

On Mon, 11 Jul 2022 20:01:12 +0200
Heinrich Schuchardt  wrote:

> If 'extension apply all' is executed and no extension is found, the return
> value of do_extension_apply() is undefined. Return CMD_RET_FAILURE in this
> case.
> 
> Fixes: 2f84e9cf06d3 ("cmd: add support for a new "extension" command")
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Kory Maincent 

> ---
>  cmd/extension_board.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/cmd/extension_board.c b/cmd/extension_board.c
> index bbb4812ff8..f94abd612d 100644
> --- a/cmd/extension_board.c
> +++ b/cmd/extension_board.c
> @@ -111,6 +111,7 @@ static int do_extension_apply(struct cmd_tbl *cmdtp, int
> flag, return CMD_RET_USAGE;
>  
>   if (strcmp(argv[1], "all") == 0) {
> + ret = CMD_RET_FAILURE;
>   list_for_each_entry(extension, _list, list) {
>   ret = extension_apply(extension);
>   if (ret != CMD_RET_SUCCESS)

Thanks,
Köry

Re: [RESEND v9 9/9] doc:eficonfig: add documentation for eficonfig command

[Ilias Apalodimas]

Hello Kojima-san

On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
 wrote:
>
> Add documentation for eficonfig command.
>
> Signed-off-by: Masahisa Kojima 
> ---
> No change sinch v8
>
> Changes in v8:
> - command name is changed from "efimenu" to "eficonfig"
>
> Newly created in v7
>
>  doc/usage/cmd/eficonfig.rst | 49 +
>  doc/usage/index.rst |  1 +

[...]

> +
> +The "eficonfig" command is enabled by::
> +
> +CONFIG_CMD_EFICONFIG=y
> +
> +If CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not enter
> +U-Boot console. In this case, bootmenu can be used to invoke "eficonfig"::
> +
> +CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="setenv bootmenu_0 UEFI Maintenance Menu=eficonfig"

Can't we just set it as the default bootcmd? Does it have to be a
preboot command?

Thanks
/Ilias
> +
> +See also
> +
> +* :doc:`bootmenu` provides a simple mechanism for creating menus 
> with different boot items
> diff --git a/doc/usage/index.rst b/doc/usage/index.rst
> index 8b98629d6b..1afbb6bc5d 100644
> --- a/doc/usage/index.rst
> +++ b/doc/usage/index.rst
> @@ -35,6 +35,7 @@ Shell commands
> cmd/conitrace
> cmd/dm
> cmd/echo
> +   cmd/eficonfig
> cmd/env
> cmd/event
> cmd/exception
> --
> 2.17.1
>

Re: [RESEND v9 2/9] eficonfig: menu-driven addition of UEFI boot option

[Ilias Apalodimas]

On Tue, 19 Jul 2022 at 02:06, Masahisa Kojima
 wrote:
>
> Hi Ilias,
>
> On Mon, 18 Jul 2022 at 22:31, Ilias Apalodimas
>  wrote:
> >
> > Hi Kojima-san
> >
> >
> > On Fri, 15 Jul 2022 at 17:45, Masahisa Kojima
> >  wrote:
> > >
> > > This commit add the "eficonfig" command.
> > > The "eficonfig" command implements the menu-driven UEFI boot option
> > > maintenance feature. This commit implements the addition of
> > > new boot option. User can select the block device volume having
> > > efi_simple_file_system_protocol and select the file corresponding
> > > to the Boot variable. User can also enter the description and
> > > optional_data of the BOOT variable in utf8.
> > >
> > > This commit adds "include/efi_config.h", it contains the common
> > > definition to be used from other menus such as UEFI Secure Boot
> > > key management.
> > >
> > > Signed-off-by: Masahisa Kojima 
> > > ---
> > > Changes in v9:
> > > - move "efi_guid_bootmenu_auto_generated definition" into efi_bootmgr.c
> > >   to address build error when CMD_EFICONFIG is disabled
> > > - fix typos and comment
> > > - remove file system information from error message
> > > - remove unreachable code in eficonfig_choice_entry()
> > > - single printf() call as much as possible
> > > - call only getchar() in  eficonfig_print_msg()
> > > - filter out '.' entry from file selection
> > > - update the efi_disk_get_device_name() implementation
> > > - add function comment
> > >
> > > Changes in v8:
> > > - command name is change from "efimenu" to "eficonfig"
> > > - function and struct prefixes is changed to "eficonfig"
> > > - fix menu header string
> > >
> > > Changes in v7:
> > > - add "efimenu" command and uefi variable maintenance code
> > >   moved into cmd/efimenu.c
> > > - create include/efimenu.h to define the common definition for
> > >   the other menu such as UEFI Secure Boot key management
> > > - update boot option edit UI, user can select description, file,
> > >   and optional_data to edit in the same menu like following.
> > >
> > >   ** Edit Boot Option **
> > >
> > >  Description: debian
> > >  File: virtio 0:1/EFI\debian\grubaa64.efi
> > >  Optional Data: test
> > >  Save
> > >  Quit
> > >
> > [...]
> >
> > I'll have a look at the code as well, but something weird is happening
> > on QEMU.  I got an ESP partition and I can save EFI variables in a
> > ubootefi.var file.  However every time I start QEMU the options I add
> > via the menu are missing although the efi variables seem to be stored
> > properly.
> >
> > => printenv -e
> > [...]
> > Boot0001:
> > 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
> > NV|BS|RT, DataSize = 0x9d
> > : 01 00 00 00 8b 00 67 00 72 00 75 00 62 00 00 00  
> > ..g.r.u.b...
> > 0010: 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8  
> > .s.J
> > 0020: 28 f3 62 8b 01 04 15 00 92 37 29 63 f5 ad 25 93  
> > (.b..7)c..%.
> > 0030: b9 9f 4e 0e 45 5c 1b 1e 00 04 01 2a 00 01 00 00  
> > ..N.E\.*
> > 0040: 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00  
> > 
> > 0050: 00 10 56 ae bd 31 33 4d 4e 94 66 ac b5 ca f0 b4  
> > ..V..13MN.f.
> > 0060: a6 02 02 04 04 34 00 45 00 46 00 49 00 5c 00 64  
> > .4.E.F.I.\.d
> > 0070: 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 72  
> > .e.b.i.a.n.\.g.r
> > 0080: 00 75 00 62 00 61 00 61 00 36 00 34 00 2e 00 65  
> > .u.b.a.a.6.4...e
> > 0090: 00 66 00 69 00 00 00 7f ff 04 00 00 00   .f.i.
> > Boot0002:
> > 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
> > NV|BS|RT, DataSize = 0x9d
> > : 01 00 00 00 8b 00 67 00 72 00 75 00 62 00 00 00  
> > ..g.r.u.b...
> > 0010: 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8  
> > .s.J
> > 0020: 28 f3 62 8b 01 04 15 00 92 37 29 63 f5 ad 25 93  
> > (.b..7)c..%.
> > 0030: b9 9f 4e 0e 45 5c 1b 1e 00 04 01 2a 00 01 00 00  
> > ..N.E\.*
> > 0040: 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00  
> > 
> > 0050: 00 10 56 ae bd 31 33 4d 4e 94 66 ac b5 ca f0 b4  
> > ..V..13MN.f.
> > 0060: a6 02 02 04 04 34 00 45 00 46 00 49 00 5c 00 64  
> > .4.E.F.I.\.d
> > 0070: 00 65 00 62 00 69 00 61 00 6e 00 5c 00 67 00 72  
> > .e.b.i.a.n.\.g.r
> > 0080: 00 75 00 62 00 61 00 61 00 36 00 34 00 2e 00 65  
> > .u.b.a.a.6.4...e
> > 0090: 00 66 00 69 00 00 00 7f ff 04 00 00 00   .f.i.
> > Boot0003:
> > 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
> > NV|BS|RT, DataSize = 0x9d
> > : 01 00 00 00 8b 00 67 00 72 00 75 00 62 00 00 00  
> > ..g.r.u.b...
> > 0010: 01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8  
> > .s.J
> > 0020: 28 f3 62 8b 01 04 15 00 92 37 29 63 f5 ad 25 93  
> > (.b..7)c..%.
> > 0030: b9 9f 

Re: DWC3 host support

[Michal Simek]

Hi,

On 7/18/22 18:23, Angus Ainslie wrote:

Hi,

On 2022-07-18 01:13, Michal Simek wrote:

On 7/17/22 17:23, Marek Vasut wrote:

On 7/17/22 05:00, Angus Ainslie wrote:

On 2022-07-16 11:37, Marek Vasut wrote:

On 7/16/22 15:02, Angus Ainslie wrote:

Hi Michal,

I recently rebased my librem5 tree onto the latest u-boot-imx branch
and the dwc3 host mode stopped working.

I bisected it down to this commit:

142d50fbce7c364a74f5e8204dba491b9f066e6c usb: dwc3: Add support for
usb3-phy PHY configuration

Reverting that commit allows usb host mode to work on the librem5 again.

Should this initialization go into an SOC specific glue_configure
function ?

Is the imx8mq.dtsi missing something that will keep usb host working
with this patch ?

Does this break usb host on other imx8mq devices ?


Wasn't this fixed by:
868d58f69c ("usb: dwc3: Fix non-usb3 configurations")
?


I've got that in my tree and it still fails to probe the USB2 hub and
USB 2 storage.


I assume you do have CONFIG_PHY_IMX8MQ_USB enabled ?

What does generic_phy_get_by_name() return for you in
drivers/usb/dwc3/dwc3-generic.c ?


As Marek said there was one patch which fixes origin patch which
didn't handle all the error cases properly. We need to know return
value from generic_phy_get_by_name(), also if you still have usb3-phy
in DT (as is in imx8mq.dtsi) with phy DT status enabled and enabled
phy driver (CONFIG_PHY_IMX8MQ_USB).



Removing the usb3 phy definition also "fixes" it

--- a/arch/arm/dts/imx8mq-librem5-r4.dts
+++ b/arch/arm/dts/imx8mq-librem5-r4.dts
@@ -33,3 +33,8 @@
   {
     proximity-near-level = <10>;
  };
+
+_dwc3_1 {
+   phys = <_phy1>;
+   phy-names = "usb2-phy";
+};


Log shows that phy initialization is called properly but it looks like that 
initialization itself has issue which should be the issue with phy driver.


DWC3 driver is calling just phy_init and phy_power_on which are quite small 2 
functions in phy-imx8mq-usb.c.


Did usb3 work before 142d50fbce7c364a74f5e8204dba491b9f066e6c?
I have no idea how imx is working but I have added to CC author of this phy 
driver.

I see small differences between Linux and U-Boot drivers.

 99 value &= ~PHY_CTRL0_SSC_RANGE_MASK;
100 value |= PHY_CTRL0_SSC_RANGE_4003PPM;

And in power_on I see this in u-boot

129 /* Disable rx term override */
130 value = readl(imx_phy->base + PHY_CTRL6);
131 value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
132 writel(value, imx_phy->base + PHY_CTRL6);

And Linux driver is handling regulators. Do you use any regulator?

If usb3.0 works in Linux I think it should be easier for you to track this down 
but there are some small differences in the U-Boot driver which can be the 
reason why it is failing on your board.


Thanks,
Michal