Re: [U-Boot] [PATCH] cmd: fat: fatload: pass device path for efi payload

[Heinrich Schuchardt]

On 5/31/19 4:03 PM, Mian Yousaf Kaukab wrote:

fatload command can be used to load the EFI payload since EFI system
partition is always a FAT partition. Call into EFI code from
do_fat_fsload() to set the device path from which the last binary was
loaded. An EFI application like grub2 can’t find its configuration
file without the device path set.

load command (do_load_wrapper()) already calls efi_set_bootdev().
There is no need to move the call to do_load() as EFI system partition
is always a FAT partition.


Thanks for reporting the issue.

U-Boot has no restriction to EFI/FAT partitions when starting EFI
applications though of cause EFI/FAT is the normal way to do it.



Signed-off-by: Mian Yousaf Kaukab 
---
  cmd/fat.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/cmd/fat.c b/cmd/fat.c
index 4b9a7eaab0..04e2055275 100644
--- a/cmd/fat.c
+++ b/cmd/fat.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 

  int do_fat_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
  {
@@ -33,6 +34,10 @@ U_BOOT_CMD(

  int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
  {
+#ifdef CONFIG_CMD_BOOTEFI
+   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
+   (argc > 4) ? argv[4] : "");
+#endif


We have the same already in cmd/fs.c for the 'load' command. I think we
should move it from cmd/fs.c to do_load(). Then we cover all file systems.

Could you, please, update the patch accordingly and resend it to me.

Best regards

Heinrich


return do_load(cmdtp, flag, argc, argv, FS_TYPE_FAT);
  }




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] u-boot-sh/master

[Marek Vasut]

More SH removal :-(

The following changes since commit c2ea87883ef309570c8903e6de4b8b78685d73d0:

  Merge tag 'efi-2019-07-rc5' of git://git.denx.de/u-boot-efi
(2019-06-12 07:15:38 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-sh.git master

for you to fetch changes up to a7e3dacbcb418a80bd8f28a0b463e924b7085cd3:

  sh: r0p7734: Remove the board (2019-06-14 12:42:06 +0200)


Marek Vasut (6):
  sh: espt_giga: Remove the board
  sh: ms7722: Remove the board
  sh: ms7750se: Remove the board
  sh: ap_sh4a_4a: Remove the board
  sh: ap325rxa: Remove the board
  sh: r0p7734: Remove the board

 arch/sh/Kconfig   |  30 
 board/alphaproject/ap_sh4a_4a/Kconfig |  12 ---
 board/alphaproject/ap_sh4a_4a/MAINTAINERS |   7 --
 board/alphaproject/ap_sh4a_4a/Makefile|   7 --
 board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c| 161
---
 board/alphaproject/ap_sh4a_4a/lowlevel_init.S | 448
---
 board/espt/Kconfig|   9 ---
 board/espt/MAINTAINERS|   6 --
 board/espt/Makefile   |   9 ---
 board/espt/espt.c |  26 ---
 board/espt/lowlevel_init.S| 317

 board/ms7722se/Kconfig|   9 ---
 board/ms7722se/MAINTAINERS|   7 --
 board/ms7722se/Makefile   |  13 
 board/ms7722se/lowlevel_init.S| 224
--
 board/ms7722se/ms7722se.c |  47 
 board/ms7750se/Kconfig|   9 ---
 board/ms7750se/MAINTAINERS|   7 --
 board/ms7750se/Makefile   |   7 --
 board/ms7750se/lowlevel_init.S| 141
--
 board/ms7750se/ms7750se.c |  24 --
 board/renesas/ap325rxa/Kconfig|  12 ---
 board/renesas/ap325rxa/MAINTAINERS|   7 --
 board/renesas/ap325rxa/Makefile   |  10 ---
 board/renesas/ap325rxa/ap325rxa.c | 148

 board/renesas/ap325rxa/cpld-ap325rxa.c| 204
-
 board/renesas/ap325rxa/lowlevel_init.S| 170
-
 board/renesas/r0p7734/Kconfig |  12 ---
 board/renesas/r0p7734/MAINTAINERS |   7 --
 board/renesas/r0p7734/Makefile|   7 --
 board/renesas/r0p7734/lowlevel_init.S | 591
-
 board/renesas/r0p7734/r0p7734.c   |  58 --
 configs/ap325rxa_defconfig|  37 -
 configs/ap_sh4a_4a_defconfig  |  34 -
 configs/espt_defconfig|  34 -
 configs/ms7722se_defconfig|  33 
 configs/ms7750se_defconfig|  32 
 configs/r0p7734_defconfig |  34 -
 include/configs/ap325rxa.h| 114

 include/configs/ap_sh4a_4a.h  | 102
-
 include/configs/espt.h|  78 ---
 include/configs/ms7722se.h|  83 
 include/configs/ms7750se.h|  65 
 include/configs/r0p7734.h | 100

 44 files changed, 3492 deletions(-)
 delete mode 100644 board/alphaproject/ap_sh4a_4a/Kconfig
 delete mode 100644 board/alphaproject/ap_sh4a_4a/MAINTAINERS
 delete mode 100644 board/alphaproject/ap_sh4a_4a/Makefile
 delete mode 100644 board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c
 delete mode 100644 board/alphaproject/ap_sh4a_4a/lowlevel_init.S
 delete mode 100644 board/espt/Kconfig
 delete mode 100644 board/espt/MAINTAINERS
 delete mode 100644 board/espt/Makefile
 delete mode 100644 board/espt/espt.c
 delete mode 100644 board/espt/lowlevel_init.S
 delete mode 100644 board/ms7722se/Kconfig
 delete mode 100644 board/ms7722se/MAINTAINERS
 delete mode 100644 board/ms7722se/Makefile
 delete mode 100644 board/ms7722se/lowlevel_init.S
 delete mode 100644 board/ms7722se/ms7722se.c
 delete mode 100644 board/ms7750se/Kconfig
 delete mode 100644 board/ms7750se/MAINTAINERS
 delete mode 100644 board/ms7750se/Makefile
 delete mode 100644 board/ms7750se/lowlevel_init.S
 delete mode 100644 board/ms7750se/ms7750se.c
 delete mode 100644 board/renesas/ap325rxa

[U-Boot] [PULL] u-boot-usb/master

[Marek Vasut]

Assorted gadget fixes.

The following changes since commit c2ea87883ef309570c8903e6de4b8b78685d73d0:

  Merge tag 'efi-2019-07-rc5' of git://git.denx.de/u-boot-efi
(2019-06-12 07:15:38 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 220f655176de8e6aa4aaea91bb2182260d26c4a4:

  fastboot: Check if partition really exist in getvar_has_slot()
(2019-06-14 12:39:54 +0200)


Igor Opaniuk (1):
  fastboot: Check if partition really exist in getvar_has_slot()

Marek Vasut (1):
  spl: dfu: Fix printed variable name

Sam Protsenko (3):
  fastboot: Fix slot names reported by getvar
  fastboot: Use const qualifier for char *part_name
  fastboot: getvar: Refactor fastboot_*_get_part_info() usage

Sjoerd Simons (1):
  usb: gadget: error out if g_dnl registration fails

 cmd/usb_gadget_sdp.c |  11 ---
 common/spl/spl_dfu.c |   2 +-
 common/spl/spl_sdp.c |   6 +-
 drivers/fastboot/fb_getvar.c | 103
+++
 drivers/fastboot/fb_mmc.c|   3 ++-
 drivers/fastboot/fb_nand.c   |   4 ++--
 include/fb_mmc.h |   3 ++-
 include/fb_nand.h|   4 ++--
 8 files changed, 101 insertions(+), 35 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] u-boot-socfpga/master

[Marek Vasut]

SPL size check for Gen5, i2c enablement for S10

The following changes since commit c2ea87883ef309570c8903e6de4b8b78685d73d0:

  Merge tag 'efi-2019-07-rc5' of git://git.denx.de/u-boot-efi
(2019-06-12 07:15:38 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-socfpga.git master

for you to fetch changes up to d6d383ca27c8121f19cb5fe1b047de330833ce6f:

  arm: socfpga: provide default SPL_SIZE_LIMIT for gen5 (2019-06-14
12:41:26 +0200)


Ley Foon Tan (1):
  arm: dts: Stratix10: Enable i2c

Simon Goldschmidt (1):
  arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

 arch/arm/dts/socfpga_stratix10_socdk.dts | 5 +
 arch/arm/mach-socfpga/Kconfig| 8 
 2 files changed, 13 insertions(+)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Marek Vasut]

On 6/14/19 8:57 AM, Simon Goldschmidt wrote:
> 
> 
> Marek Vasut mailto:ma...@denx.de>> schrieb am Do., 13.
> Juni 2019, 23:08:
> 
> On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut mailto:ma...@denx.de>
> >> schrieb am Do., 13.
> > Juni 2019, 22:56:
> >
> >     On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> >     >
> >     >
> >     > Marek Vasut mailto:ma...@denx.de>
> >
> >     
>  >     > Juni 2019, 22:40:
> >     >
> >     >     On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >     >     >
> >     >     >
> >     >     > On 13.06.19 22:14, Marek Vasut wrote:
> >     >     >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >     >     >>> This provides an SPL_SIZE_LIMIT that makes the build
> check
> >     that
> >     >     the SPL
> >     >     >>> binary loaded from flash fits into the SRAM (64 KiB) and
> >     leaves
> >     >     enough
> >     >     >>> room for global data, heap  and stack (512 bytes
> assumed stack
> >     >     usage).
> >     >     >>>
> >     >     >>> Signed-off-by: Simon Goldschmidt
> >     >      
> >      >
> >     >      
> >       >     >     >>> ---
> >     >     >>>
> >     >     >>>   arch/arm/mach-socfpga/Kconfig | 8 
> >     >     >>>   1 file changed, 8 insertions(+)
> >     >     >>>
> >     >     >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >     >     >>> b/arch/arm/mach-socfpga/Kconfig
> >     >     >>> index 48f02f08d4..1d914648e3 100644
> >     >     >>> --- a/arch/arm/mach-socfpga/Kconfig
> >     >     >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >     >     >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >     >     >>>   config NR_DRAM_BANKS
> >     >     >>>   default 1
> >     >     >>>   +config SPL_SIZE_LIMIT
> >     >     >>> +    default 65536 if TARGET_SOCFPGA_GEN5
> >     >     >>> +
> >     >     >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >     >     >>> +    default 0x200 if TARGET_SOCFPGA_GEN5
> >     >     >>> +
> >     >     >>>   config SPL_STACK_R_ADDR
> >     >     >>>   default 0x0080 if TARGET_SOCFPGA_GEN5
> >     >     >>>   @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >     >     >>>   bool
> >     >     >>>   select SPL_ALTERA_SDRAM
> >     >     >>>   imply FPGA_SOCFPGA
> >     >     >>> +    imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >     >     >>> +    imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >     >     >>>   imply SPL_STACK_R
> >     >     >>>   imply SPL_SYS_MALLOC_SIMPLE
> >     >     >>>   imply USE_TINY_PRINTF
> >     >     >>>
> >     >     >> 512 bytes for stack looks like it's too little. I
> think the SPL
> >     >     started
> >     >     >> misbehaving when it overgrew 50 kiB, no ?
> >     >     >
> >     >     > To 1: Well, I tested the stack usage once, booting from
> >     eMMC, and was
> >     >     > somewhere below that range. But yes, it's a problem
> for the
> >     >     future: once
> >     >     > we get a more stack-consuming function, we might be lost.
> >     Which size
> >     >     > would you suggest?
> >     >
> >     >     Hmmm, now that I think about it, the stack gets relocated to
> >     DRAM quite
> >     >     early too, right ? So maybe we really don't need that much
> >     space for
> >     >     stack.
> >     >
> >     >
> >     > Exactly. The only stack-consuming things before relocation
> are dts
> >     > parsing and maybe the ddr driver. I implemented a stack
> usage check by
> >     > filling the memory with 0xaa and checking it afterwards and if I
> >     > remember correctly it resulted in about 400 bytes. It's even
> more or
> >     > less independent of the boot type since the ski/mmc drivers
> are probed
> >     > only after DDR is up. Same goes for file systems.
> >     >
> >     > Nevertheless, stack usage can increase in the future. That's why
> >     I'm not
> >     > too happy about this constant. Otoh, DM_CLK makes me need every
> >     byte and
> >     > right now I don't see how I can enable secure boot (fit
> signature
> >     check)
> >     > due to this size limit...
> >
> >     Maybe before w

Re: [U-Boot] Pull request: u-boot-dfu (14.06.2019) - fixes v2019.07

[Marek Vasut]

On 6/14/19 9:09 AM, Lukasz Majewski wrote:
> Dear Marek,
> 
> Repo:  git://git.denx.de/u-boot-dfu.git
> Branch: master

Pulled , thanks.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] And what about fitImages and ram disks?

[Patrick Doyle]

I just created my initramfs and inserted it into my fit-image.its
file.  When I booted, I saw the following:

   Trying 'ramdisk' ramdisk subimage
 Description:  Bootstrap ramdisk
 Type: RAMDisk Image
 Compression:  gzip compressed
 Data Start:   0x811ae9f0
 Data Size:2613908 Bytes = 2.5 MiB
 Architecture: MIPS
 OS:   Linux
 Load Address: 0x
 Entry Point:  0x
 Hash algo:sha256
 Hash value:
0faa7c3e4927b685cd5a050112ea6b90ad4dec4e4ea8627b4f589bfc60082eba
   Verifying Hash Integrity ... sha256+ OK
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 83ad9000, end 83d57294 ... OK
   Loading Ramdisk to 8385a000, end 83ad8294 ... OK
[0.00] Linux version 4.14.115-yocto-standard-custom
(oe-user@oe-host) (gcc version 8.3.0 (GCC)) #1 Fri Jun 14 19:49:57 UTC
2019
[0.00] Board has DDR2
[0.00] Analog PMU set to hw control
[0.00] Digital PMU set to hw control
[0.00] SoC Type: MediaTek MT7688 ver:1 eco:2
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019655 (MIPS 24KEc)
[0.00] MIPS: machine is MediaTek LinkIt Smart 7688
[0.00] Determined physical RAM map:
[0.00]  memory: 0400 @  (usable)
[0.00] Initrd not found or empty - disabling initrd

Does anybody have any hints as to why the Ramdisk would be relocated twice?
Does anybody have any hints as to why the kernel didn't notice the ramdisk?

As you may notice, I am building these images with Yocto.  The Yocto
documentation advvices to bundle the initramfs with the kernel image,
which I can do.  But I am presented with two options here: bundle it
with the kernel (which has been around since forwver), or bundle it in
the FIT Image.  I decided to assume that the Yocto documentation was a
bit out of date and started by bundling it with my FIT image.

I will try doing what the documentation said to do next, but in the
mean time, I thought I would ask what others have experienced with
booting FIT Images with RAM disks.  (For my particular application, I
only ever need one configuration, with one kernel, one fdt, and one
ramdisk, all of which could be bundled into the one kernel... so
arguably, I don't need the flexibility of bundling it in the FIT
image).

Thanks for any tips.

--wpd
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB

[Heinrich Schuchardt]

There is no good reason to limit the trace buffer to 2GiB on a 64bit
system. Adjust the types of the relevant parameters.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/trace.c  | 10 --
 include/trace.h  |  6 +++---
 lib/trace.c  | 14 +++---
 tools/proftool.c |  4 ++--
 4 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/cmd/trace.c b/cmd/trace.c
index 26bf0960d4..7d328f88be 100644
--- a/cmd/trace.c
+++ b/cmd/trace.c
@@ -30,8 +30,7 @@ static int get_args(int argc, char * const argv[], char 
**buff,

 static int create_func_list(int argc, char * const argv[])
 {
-   size_t buff_size, avail, buff_ptr, used;
-   unsigned int needed;
+   size_t buff_size, avail, buff_ptr, needed, used;
char *buff;
int err;

@@ -41,7 +40,7 @@ static int create_func_list(int argc, char * const argv[])
avail = buff_size - buff_ptr;
err = trace_list_functions(buff + buff_ptr, avail, &needed);
if (err)
-   printf("Error: truncated (%#x bytes needed)\n", needed);
+   printf("Error: truncated (%#zx bytes needed)\n", needed);
used = min(avail, (size_t)needed);
printf("Function trace dumped to %08lx, size %#zx\n",
   (ulong)map_to_sysmem(buff + buff_ptr), used);
@@ -54,8 +53,7 @@ static int create_func_list(int argc, char * const argv[])

 static int create_call_list(int argc, char * const argv[])
 {
-   size_t buff_size, avail, buff_ptr, used;
-   unsigned int needed;
+   size_t buff_size, avail, buff_ptr, needed, used;
char *buff;
int err;

@@ -65,7 +63,7 @@ static int create_call_list(int argc, char * const argv[])
avail = buff_size - buff_ptr;
err = trace_list_calls(buff + buff_ptr, avail, &needed);
if (err)
-   printf("Error: truncated (%#x bytes needed)\n", needed);
+   printf("Error: truncated (%#zx bytes needed)\n", needed);
used = min(avail, (size_t)needed);
printf("Call list dumped to %08lx, size %#zx\n",
   (ulong)map_to_sysmem(buff + buff_ptr), used);
diff --git a/include/trace.h b/include/trace.h
index 99f34f72bc..606dba9768 100644
--- a/include/trace.h
+++ b/include/trace.h
@@ -39,7 +39,7 @@ struct trace_output_func {
 /* A header at the start of the trace output buffer */
 struct trace_output_hdr {
enum trace_chunk_type type; /* Record type */
-   uint32_t rec_count; /* Number of records */
+   size_t rec_count;   /* Number of records */
 };

 /* Print statistics about traced function calls */
@@ -57,7 +57,7 @@ void trace_print_stats(void);
  * @param needed   Returns number of bytes used / needed
  * @return 0 if ok, -1 on error (buffer exhausted)
  */
-int trace_list_functions(void *buff, int buff_size, unsigned *needed);
+int trace_list_functions(void *buff, size_t buff_size, size_t *needed);

 /* Flags for ftrace_record */
 enum ftrace_flags {
@@ -77,7 +77,7 @@ struct trace_call {
uint32_t flags; /* Flags and timestamp */
 };

-int trace_list_calls(void *buff, int buff_size, unsigned int *needed);
+int trace_list_calls(void *buff, size_t buff_size, size_t *needed);

 /**
  * Turn function tracing on and off
diff --git a/lib/trace.c b/lib/trace.c
index 04780f59d3..f2402b9359 100644
--- a/lib/trace.c
+++ b/lib/trace.c
@@ -190,12 +190,12 @@ void __attribute__((no_instrument_function)) 
__cyg_profile_func_exit(
  * greater than buff_size if we ran out of space.
  * @return 0 if ok, -1 if space was exhausted
  */
-int trace_list_functions(void *buff, int buff_size, unsigned int *needed)
+int trace_list_functions(void *buff, size_t buff_size, size_t *needed)
 {
struct trace_output_hdr *output_hdr = NULL;
void *end, *ptr = buff;
-   int func;
-   int upto;
+   size_t func;
+   size_t upto;

end = buff ? buff + buff_size : NULL;

@@ -206,7 +206,7 @@ int trace_list_functions(void *buff, int buff_size, 
unsigned int *needed)

/* Add information about each function */
for (func = upto = 0; func < hdr->func_count; func++) {
-   int calls = hdr->call_accum[func];
+   size_t calls = hdr->call_accum[func];

if (!calls)
continue;
@@ -235,12 +235,12 @@ int trace_list_functions(void *buff, int buff_size, 
unsigned int *needed)
return 0;
 }

-int trace_list_calls(void *buff, int buff_size, unsigned *needed)
+int trace_list_calls(void *buff, size_t buff_size, size_t *needed)
 {
struct trace_output_hdr *output_hdr = NULL;
void *end, *ptr = buff;
-   int rec, upto;
-   int count;
+   size_t rec, upto;
+   size_t count;

end = buff ? buff + buff_size : NULL;

diff --git a/tools/proftool.c b/tools/proftool.c
index c1803fa78a..fecb9d6e99 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -205,12 +205,12 @@ static struct func_info *find_caller_by_offs

[U-Boot] [PATCH 1/1] trace: trace buffer may exceed 2GiB

[Heinrich Schuchardt]

Correct the debug output for the trace buffer size to accommodate trace
buffers exceeding 2GiB.

Signed-off-by: Heinrich Schuchardt 
---
 common/board_f.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 0fc938dc87..4760d728f3 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -442,8 +442,8 @@ static int reserve_trace(void)
 #ifdef CONFIG_TRACE
gd->relocaddr -= CONFIG_TRACE_BUFFER_SIZE;
gd->trace_buff = map_sysmem(gd->relocaddr, CONFIG_TRACE_BUFFER_SIZE);
-   debug("Reserving %dk for trace data at: %08lx\n",
- CONFIG_TRACE_BUFFER_SIZE >> 10, gd->relocaddr);
+   debug("Reserving %luk for trace data at: %08lx\n",
+ (unsigned long)CONFIG_TRACE_BUFFER_SIZE >> 10, gd->relocaddr);
 #endif

return 0;
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: [PATCH 1/2 v3] net: introduce MDIO DM class for MDIO devices

[Alex Marginean]

Hi Nevo,

On 6/14/2019 7:55 PM, Nevo Hed wrote:

Hi Alex

In another thread (https://lists.denx.de/pipermail/u-boot/2019-June/371933.html)
I asked Ken (before learning of their cut-backs) if I should take a
stab at re-integrating his work
where Joe also pointed out the impending acceptance of your work.

I'm not sure where we left off here in this thread and wondering if
you are working on that or not.  Ive been staring at this for a bit
and ready to take a stab at it if you are not.


I am planning to add helpers to MDIO uclass, along the lines Ken sent
initially, on top of the current patch.  It looks like the helpers would
fit just fine.  I didn't get to do it yet though.

One difference between the two DM MDIO implementations is the way MDIO
ops work, the patch I sent abstracts away the legacy mii_bus from DM
MDIO driver.  I would keep that as it, which means a bit more rework on
the marvell driver.  I didn't look into this in detail yet.
I think I can send a version of the helpers in [1] in about a week,
maybe more, right now I'm trying to get MDIO MUX DM support out for
review plus some updates for the NXP platform I'm working on.  I can
take a stab at porting the marvell driver too, but I can't test it.
If you want to put some time into this right now feel free to do it :)



if easier - i'm `nhed73` on the #u-boot irc channel

Thanks
   ---Nevo


I can join if you want to discuss details, let me know.

Thanks!
Alex




On Tue, Jun 11, 2019 at 8:04 AM Alexandru Marginean
 wrote:


Hi Ken,

On 6/11/2019 12:44 PM, Ken Ma wrote:

Hi Alex

Thanks a lot for your information!

I think our patches have no essential difference.
The 2 patches have only small implementation difference:
In my patch, mii bus ops functions(read/write/reset...) need to be
implemented while in your patch mdio bus functions need to be
implemented and then mii bus ops functions will call mdio bus ops
functions. > I had planned to reuse those existed mii ops functions such as
smc911x_miiphy_read/ smc911x_miiphy_write/ sun8i_mdio_read/
sun8i_mdio_write... then it is easy for turning old mdio driver to
DM. >
Now I am not working on u-boot, so I am sorry that I will not do the pulling 
work.

Yours,
Ken


OK, I think I get what you wanted to do.  Either way it's not too
difficult to convert existing MDIOs to DM, but they have to start using
struct udevice.  That's similar to what was done on DM_ETH and others.

The helpers mapping eth/phy/mdio make sense and could be useful, that's
something I'll try to look into.

Thank you!
Alex




-Original Message-
From: Alex Marginean 
Sent: Tuesday, June 11, 2019 9:18 AM
To: joe.hershber...@ni.com; Ken Ma 
Cc: u-boot ; Joseph Hershberger 

Subject: [EXT] Re: [U-Boot] [PATCH 1/2 v3] net: introduce MDIO DM class for 
MDIO devices

External Email

--
+Ken,

Hi Joe,

On 6/10/2019 11:25 PM, Joe Hershberger wrote:

On Mon, Jun 3, 2019 at 11:11 AM Alex Marginean  wrote:


Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
stand-alone devices.  Useful in particular for systems that support
DM_ETH and have a stand-alone MDIO hardware block shared by multiple
Ethernet interfaces.

Signed-off-by: Alex Marginean 
---

Changes in v2:
   - fixed several comments using wrong API names
   - dropped dm_ from names of internal functions that don't use 
udevice *
   - fixed UCLASS driver name
   - added missing mdio_unregister in dm_mdio_pre_remove
   - added a comment on why spaces in names aren't ok
   - added a comment on how static mdio_read/_write/_reset functions
   are used
Changes in v3:
   - none



Not sure if you already noticed this [1] or not, but there may be
something there that you want to incorporate or maybe not.

Cheers,
-Joe

[1] - https://patchwork.ozlabs.org/patch/939726/



I didn't notice it, thanks for pointing it out!
Apart from the obvious overlap of adding UCLASS_MDIO and code like _post_probe 
they seem to deal with different needs.

Ken, can you please take a look at the patch I sent?  It has a wrapper over 
phy_connect, but provides no helpers on how the caller would get the PHY ADDR.  
Do you want to try pulling the API you add on top of the patch I sent, or do 
you want me to try?  It looks like it would work with minimal effort.

Thank you!
Alex



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] net: Convert CONFIG_IP_DEFRAG to Kconfig

[Joe Hershberger]

On Mon, Jun 10, 2019 at 9:52 PM Marek Vasut  wrote:
>
> Convert CONFIG_IP_DEFRAG to Kconfig, update defconfigs, headers
> and whitelist. This patch is a follow-up on a patch by Christian
> Gmeiner with the added config/header/whitelist updates.
>
> Signed-off-by: Marek Vasut 
> Reported-by: Christian Gmeiner 
> Cc: Joe Hershberger 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] net: Convert CONFIG_TFTP_BLOCKSIZE to Kconfig

[Joe Hershberger]

On Mon, Jun 10, 2019 at 9:53 PM Marek Vasut  wrote:
>
> Convert CONFIG_TFTP_BLOCKSIZE to Kconfig, update defconfigs,
> headers and whitelist.
>
> Signed-off-by: Marek Vasut 
> Cc: Christian Gmeiner 
> Cc: Joe Hershberger 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Jetson TX2 hangs during dhcp boot

[Andreas Färber]

Am 14.06.19 um 19:26 schrieb Varun Wadekar:
>>> ERROR:   ARI request timed out: req 89 on CPU 4
>>> ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries 
>>> != 0U
> 
> This time out means that TEGRA_ARI_ROC_FLUSH_CACHE_TRBITS ARI call timed out. 
> Looks like the firmware responsible for handling this ARI call is stuck or 
> overloaded and not servicing any calls.

Does this ARI firmware sit in the Arm cores' DRAM? If so, can you share
which memory region it needs?

Same question for BL31 - is that TZDRAM_BASE? If so, where to find the
size? The TF-A docs are not so telling of those layout details.
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/nvidia-tegra.rst

U-Boot only reserves any memrsv entries of the FDT, not other memory
nodes such as within your sysram@3000. Those may need C code in
U-Boot to reserve them from usage by UEFI apps such as GRUB and Linux.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/nvidia/tegra186.dtsi

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rsa: reject images with unknown padding

[Patrick Doyle]

Previously we would store NULL in info->padding and jump to an illegal
instruction if an unknown value for "padding" was specified in the
device tree.

Signed-off-by: Patrick Doyle 
---
 common/image-sig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/image-sig.c b/common/image-sig.c
index 4f6b4ec..004fbc5 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -211,7 +211,7 @@ static int fit_image_setup_verify(struct
image_sign_info *info,
 info->required_keynode = required_keynode;
 printf("%s:%s", algo_name, info->keyname);

-if (!info->checksum || !info->crypto) {
+if (!info->checksum || !info->crypto || !info->padding) {
 *err_msgp = "Unknown signature algorithm";
 return -1;
 }
-- 
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Jetson TX2 hangs during dhcp boot

[Stephen Warren]

On 6/14/19 11:09 AM, Andreas Färber wrote:

Am 14.06.19 um 18:41 schrieb Stephen Warren:

On 6/14/19 11:09 AM, Mian Yousaf Kaukab wrote:

Hi,
I am seeing a hang with dhcp boot on Jetson TX2. Its running firmware
from
L4T 32.1 with U-Boot from master branch (c2ea87883e) with [1] applied.

I use following command sequence at u-boot prompt to boot:

Tegra186 (P2771--500) # setenv ftdfile tegra186-p2771-.dtb
Tegra186 (P2771--500) # setenv boot_targets dhcp
Tegra186 (P2771--500) # boot

Last thing I see is the following error from TF-A and the board hangs:


What is TF-A?


The artist formerly known as Arm Trusted Firmware.


Ah OK. I had only ever heard that called ATF before.


U-Boot 2019.07-rc4-00137-g6fefd9c475 (Jun 14 2019 - 16:27:34 +0200)

...

TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx
Filename 'aarch64/grub.efi'.
Load address: 0x8028

...

MMC: no card present
Scanning disk sd...@340.blk...
Disk sd...@340.blk not ready
Scanning disk sd...@346.blk...
Found 32 disks
copying carveout for
/host1x@13e0/display-hub@1520/display@1520...
copying carveout for
/host1x@13e0/display-hub@1520/display@1521...
copying carveout for
/host1x@13e0/display-hub@1520/display@1522...
ERROR:   ARI request timed out: req 89 on CPU 4
ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries
!= 0U


That file doesn't exist in U-Boot; I guess it's part of grub.efi?


Looks rather like a TF-A path to me, CC'ing Varun.


Ah yes, I do see that path in our ATF code.


As Yousaf says above, it's the TF-A you guys ship with latest R32.1.0.

Maybe the tftpboot operation is overwriting memory used by your TF-A, or


That's pretty unlikely since ATF code/data is in a protected memory 
region that non-secure software can't access.



differing memory usage is uncovering a missing U-Boot EFI reservation?


Perhaps. I know almost nothing about U-Boot EFI though.


(I recently wondered whether TX1 may be missing some, as I needed
multiple tries to boot the kernel successfully there - TF-A 2.1 didn't
work there, so some more investigations TBD. R28.3.0 still wasn't
booting U-Boot ~2019.04, I needed R24.2.2 still as you once suggested.)


Hmm. Are you building your own copy of ATF (you mentioned 2.1; I can't 
recall what version we ship)?


FWIW, my usptream U-Boot test system uses L4T r28.1 to test Jetson TX1 
and TX2. It does test DHCP/TFTP, but not EFI or booting a kernel.


Can you provide complete instructions on how to reproduce this issue 
(e.g. which components in L4T you replaced, how to build those 
replacements, how to get/build/use EFI, any config/script/... files you 
used from U-Boot/EFI to trigger the issue above)?


Your best bet is likely to post all this information to the NVIDIA 
Jetson forum so our support people can track the process. I don't expect 
to have much time personally to look at EFI stuff on TX2 right now. Sorry.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Jetson TX2 hangs during dhcp boot

[Varun Wadekar]

>> ERROR:   ARI request timed out: req 89 on CPU 4
>> ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries 
>> != 0U

This time out means that TEGRA_ARI_ROC_FLUSH_CACHE_TRBITS ARI call timed out. 
Looks like the firmware responsible for handling this ARI call is stuck or 
overloaded and not servicing any calls.

-Original Message-
From: Andreas Färber  
Sent: Friday, June 14, 2019 10:10 AM
To: Stephen Warren ; Mian Yousaf Kaukab 
Cc: u-boot@lists.denx.de; Stephen Warren ; Tom Warren 
; Varun Wadekar 
Subject: Re: [U-Boot] Jetson TX2 hangs during dhcp boot

Am 14.06.19 um 18:41 schrieb Stephen Warren:
> On 6/14/19 11:09 AM, Mian Yousaf Kaukab wrote:
>> Hi,
>> I am seeing a hang with dhcp boot on Jetson TX2. Its running firmware 
>> from L4T 32.1 with U-Boot from master branch (c2ea87883e) with [1] 
>> applied.
>>
>> I use following command sequence at u-boot prompt to boot:
>>
>> Tegra186 (P2771--500) # setenv ftdfile tegra186-p2771-.dtb
>> Tegra186 (P2771--500) # setenv boot_targets dhcp
>> Tegra186 (P2771--500) # boot
>>
>> Last thing I see is the following error from TF-A and the board hangs:
> 
> What is TF-A?

The artist formerly known as Arm Trusted Firmware.

>> U-Boot 2019.07-rc4-00137-g6fefd9c475 (Jun 14 2019 - 16:27:34 +0200)
> ...
>> TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx Filename 
>> 'aarch64/grub.efi'.
>> Load address: 0x8028
> ...
>> MMC: no card present
>> Scanning disk sd...@340.blk...
>> Disk sd...@340.blk not ready
>> Scanning disk sd...@346.blk...
>> Found 32 disks
>> copying carveout for
>> /host1x@13e0/display-hub@1520/display@1520...
>> copying carveout for
>> /host1x@13e0/display-hub@1520/display@1521...
>> copying carveout for
>> /host1x@13e0/display-hub@1520/display@1522...
>> ERROR:   ARI request timed out: req 89 on CPU 4
>> ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries 
>> != 0U
> 
> That file doesn't exist in U-Boot; I guess it's part of grub.efi?

Looks rather like a TF-A path to me, CC'ing Varun.

As Yousaf says above, it's the TF-A you guys ship with latest R32.1.0.

Maybe the tftpboot operation is overwriting memory used by your TF-A, or 
differing memory usage is uncovering a missing U-Boot EFI reservation?

(I recently wondered whether TX1 may be missing some, as I needed multiple 
tries to boot the kernel successfully there - TF-A 2.1 didn't work there, so 
some more investigations TBD. R28.3.0 still wasn't booting U-Boot ~2019.04, I 
needed R24.2.2 still as you once suggested.)

Regards,
Andreas

--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Jetson TX2 hangs during dhcp boot

[Andreas Färber]

Am 14.06.19 um 18:41 schrieb Stephen Warren:
> On 6/14/19 11:09 AM, Mian Yousaf Kaukab wrote:
>> Hi,
>> I am seeing a hang with dhcp boot on Jetson TX2. Its running firmware
>> from
>> L4T 32.1 with U-Boot from master branch (c2ea87883e) with [1] applied.
>>
>> I use following command sequence at u-boot prompt to boot:
>>
>> Tegra186 (P2771--500) # setenv ftdfile tegra186-p2771-.dtb
>> Tegra186 (P2771--500) # setenv boot_targets dhcp
>> Tegra186 (P2771--500) # boot
>>
>> Last thing I see is the following error from TF-A and the board hangs:
> 
> What is TF-A?

The artist formerly known as Arm Trusted Firmware.

>> U-Boot 2019.07-rc4-00137-g6fefd9c475 (Jun 14 2019 - 16:27:34 +0200)
> ...
>> TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx
>> Filename 'aarch64/grub.efi'.
>> Load address: 0x8028
> ...
>> MMC: no card present
>> Scanning disk sd...@340.blk...
>> Disk sd...@340.blk not ready
>> Scanning disk sd...@346.blk...
>> Found 32 disks
>> copying carveout for
>> /host1x@13e0/display-hub@1520/display@1520...
>> copying carveout for
>> /host1x@13e0/display-hub@1520/display@1521...
>> copying carveout for
>> /host1x@13e0/display-hub@1520/display@1522...
>> ERROR:   ARI request timed out: req 89 on CPU 4
>> ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries
>> != 0U
> 
> That file doesn't exist in U-Boot; I guess it's part of grub.efi?

Looks rather like a TF-A path to me, CC'ing Varun.

As Yousaf says above, it's the TF-A you guys ship with latest R32.1.0.

Maybe the tftpboot operation is overwriting memory used by your TF-A, or
differing memory usage is uncovering a missing U-Boot EFI reservation?

(I recently wondered whether TX1 may be missing some, as I needed
multiple tries to boot the kernel successfully there - TF-A 2.1 didn't
work there, so some more investigations TBD. R28.3.0 still wasn't
booting U-Boot ~2019.04, I needed R24.2.2 still as you once suggested.)

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: [PATCH 1/2 v3] net: introduce MDIO DM class for MDIO devices

[Nevo Hed]

Hi Alex

In another thread (https://lists.denx.de/pipermail/u-boot/2019-June/371933.html)
I asked Ken (before learning of their cut-backs) if I should take a
stab at re-integrating his work
where Joe also pointed out the impending acceptance of your work.

I'm not sure where we left off here in this thread and wondering if
you are working on that or not.  Ive been staring at this for a bit
and ready to take a stab at it if you are not.

if easier - i'm `nhed73` on the #u-boot irc channel

Thanks
  ---Nevo

On Tue, Jun 11, 2019 at 8:04 AM Alexandru Marginean
 wrote:
>
> Hi Ken,
>
> On 6/11/2019 12:44 PM, Ken Ma wrote:
> > Hi Alex
> >
> > Thanks a lot for your information!
> >
> > I think our patches have no essential difference.
> > The 2 patches have only small implementation difference:
> > In my patch, mii bus ops functions(read/write/reset...) need to be
> > implemented while in your patch mdio bus functions need to be
> > implemented and then mii bus ops functions will call mdio bus ops
> > functions. > I had planned to reuse those existed mii ops functions such as
> > smc911x_miiphy_read/ smc911x_miiphy_write/ sun8i_mdio_read/
> > sun8i_mdio_write... then it is easy for turning old mdio driver to
> > DM. >
> > Now I am not working on u-boot, so I am sorry that I will not do the 
> > pulling work.
> >
> > Yours,
> > Ken
>
> OK, I think I get what you wanted to do.  Either way it's not too
> difficult to convert existing MDIOs to DM, but they have to start using
> struct udevice.  That's similar to what was done on DM_ETH and others.
>
> The helpers mapping eth/phy/mdio make sense and could be useful, that's
> something I'll try to look into.
>
> Thank you!
> Alex
>
>
> >
> > -Original Message-
> > From: Alex Marginean 
> > Sent: Tuesday, June 11, 2019 9:18 AM
> > To: joe.hershber...@ni.com; Ken Ma 
> > Cc: u-boot ; Joseph Hershberger 
> > 
> > Subject: [EXT] Re: [U-Boot] [PATCH 1/2 v3] net: introduce MDIO DM class for 
> > MDIO devices
> >
> > External Email
> >
> > --
> > +Ken,
> >
> > Hi Joe,
> >
> > On 6/10/2019 11:25 PM, Joe Hershberger wrote:
> >> On Mon, Jun 3, 2019 at 11:11 AM Alex Marginean  
> >> wrote:
> >>>
> >>> Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
> >>> stand-alone devices.  Useful in particular for systems that support
> >>> DM_ETH and have a stand-alone MDIO hardware block shared by multiple
> >>> Ethernet interfaces.
> >>>
> >>> Signed-off-by: Alex Marginean 
> >>> ---
> >>>
> >>> Changes in v2:
> >>>   - fixed several comments using wrong API names
> >>>   - dropped dm_ from names of internal functions that don't use 
> >>> udevice *
> >>>   - fixed UCLASS driver name
> >>>   - added missing mdio_unregister in dm_mdio_pre_remove
> >>>   - added a comment on why spaces in names aren't ok
> >>>   - added a comment on how static mdio_read/_write/_reset 
> >>> functions
> >>>   are used
> >>> Changes in v3:
> >>>   - none
> >>
> >>
> >> Not sure if you already noticed this [1] or not, but there may be
> >> something there that you want to incorporate or maybe not.
> >>
> >> Cheers,
> >> -Joe
> >>
> >> [1] - https://patchwork.ozlabs.org/patch/939726/
> >>
> >
> > I didn't notice it, thanks for pointing it out!
> > Apart from the obvious overlap of adding UCLASS_MDIO and code like 
> > _post_probe they seem to deal with different needs.
> >
> > Ken, can you please take a look at the patch I sent?  It has a wrapper over 
> > phy_connect, but provides no helpers on how the caller would get the PHY 
> > ADDR.  Do you want to try pulling the API you add on top of the patch I 
> > sent, or do you want me to try?  It looks like it would work with minimal 
> > effort.
> >
> > Thank you!
> > Alex
> >
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 1/1] efi_loader: add RuntimeServicesSupported variable

[Heinrich Schuchardt]

From: AKASHI Takahiro 

This variable is defined in UEFI specification 2.8, section 8.1.
Its value should be updated whenever we add any usable runtime services
function.

Currently we only support SetVirtualAddress() for all systems and
ResetSystem() for some.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt 
---
v4
CONFIG_IS_ENABLED() wants Kconfig variables without CONFIG_ prefix.
v3
Ensure that efi_runtime_services_supported is initialized.
v2
Currently we only support SetVirtualAddress() for all systems and
ResetSystem() for some.
---
 include/efi_api.h| 15 +++
 include/efi_loader.h |  3 +++
 lib/efi_loader/efi_runtime.c | 24 
 lib/efi_loader/efi_setup.c   |  5 +
 4 files changed, 47 insertions(+)

diff --git a/include/efi_api.h b/include/efi_api.h
index 65584dd2d8..d7d95edd4d 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -213,6 +213,21 @@ struct efi_capsule_header {
u32 capsule_image_size;
 };

+#define EFI_RT_SUPPORTED_GET_TIME  0x0001
+#define EFI_RT_SUPPORTED_SET_TIME  0x0002
+#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME   0x0004
+#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME   0x0008
+#define EFI_RT_SUPPORTED_GET_VARIABLE  0x0010
+#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME0x0020
+#define EFI_RT_SUPPORTED_SET_VARIABLE  0x0040
+#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP   0x0080
+#define EFI_RT_SUPPORTED_CONVERT_POINTER   0x0100
+#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT 0x0200
+#define EFI_RT_SUPPORTED_RESET_SYSTEM  0x0400
+#define EFI_RT_SUPPORTED_UPDATE_CAPSULE0x0800
+#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES0x1000
+#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO   0x2000
+
 struct efi_runtime_services {
struct efi_table_hdr hdr;
efi_status_t (EFIAPI *get_time)(struct efi_time *time,
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f0e1313f93..b07155cecb 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const 
efi_guid_t *g2)
 #define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
 #define __efi_runtime __attribute__ ((section (".text.efi_runtime")))

+/* Indicate supported runtime services */
+efi_status_t efi_init_runtime_supported(void);
+
 /* Update CRC32 in table header */
 void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr *table);

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 432551d0c8..0c57d0abd7 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -89,6 +89,30 @@ struct elf_rela {
  * handle a good number of runtime callbacks
  */

+efi_status_t efi_init_runtime_supported(void)
+{
+   u16 efi_runtime_services_supported = 0;
+
+   /*
+* This value must be synced with efi_runtime_detach_list
+* as well as efi_runtime_services.
+*/
+#if CONFIG_IS_ENABLED(ARCH_BCM283X) || \
+CONFIG_IS_ENABLED(FSL_LAYERSCAPE) || \
+CONFIG_IS_ENABLED(SYSRESET_X86) || \
+CONFIG_IS_ENABLED(PSCI_RESET)
+   efi_runtime_services_supported |= EFI_RT_SUPPORTED_RESET_SYSTEM;
+#endif
+   efi_runtime_services_supported |=
+   EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
+   return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
+&efi_global_variable_guid,
+EFI_VARIABLE_BOOTSERVICE_ACCESS |
+EFI_VARIABLE_RUNTIME_ACCESS,
+sizeof(efi_runtime_services_supported),
+&efi_runtime_services_supported));
+}
+
 /**
  * efi_update_table_header_crc32() - Update crc32 in table header
  *
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 8691d686d2..bfb57836fa 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -117,6 +117,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;

+   /* Indicate supported runtime services */
+   ret = efi_init_runtime_supported();
+   if (ret != EFI_SUCCESS)
+   goto out;
+
/* Initialize system table */
ret = efi_initialize_system_table();
if (ret != EFI_SUCCESS)
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Jetson TX2 hangs during dhcp boot

[Stephen Warren]

On 6/14/19 11:09 AM, Mian Yousaf Kaukab wrote:

Hi,
I am seeing a hang with dhcp boot on Jetson TX2. Its running firmware from
L4T 32.1 with U-Boot from master branch (c2ea87883e) with [1] applied.

I use following command sequence at u-boot prompt to boot:

Tegra186 (P2771--500) # setenv ftdfile tegra186-p2771-.dtb
Tegra186 (P2771--500) # setenv boot_targets dhcp
Tegra186 (P2771--500) # boot

Last thing I see is the following error from TF-A and the board hangs:


What is TF-A?


U-Boot 2019.07-rc4-00137-g6fefd9c475 (Jun 14 2019 - 16:27:34 +0200)

...

TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx
Filename 'aarch64/grub.efi'.
Load address: 0x8028

...

MMC: no card present
Scanning disk sd...@340.blk...
Disk sd...@340.blk not ready
Scanning disk sd...@346.blk...
Found 32 disks
copying carveout for /host1x@13e0/display-hub@1520/display@1520...
copying carveout for /host1x@13e0/display-hub@1520/display@1521...
copying carveout for /host1x@13e0/display-hub@1520/display@1522...
ERROR:   ARI request timed out: req 89 on CPU 4
ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries != 0U


That file doesn't exist in U-Boot; I guess it's part of grub.efi? So, 
this isn't a hang in U-Boot at all. You'd have to get support for that 
from the authors of Grub I guess.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] efi_loader: fix SetMode()

[Heinrich Schuchardt]

Correct the check of the mode number in SetMode() service of the simple
text output protocol.

Clear the screen in SetMode().

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_console.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 2fc25e118f..fef0b2e1e2 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -316,23 +316,6 @@ static efi_status_t EFIAPI efi_cout_query_mode(
return EFI_EXIT(EFI_SUCCESS);
 }

-static efi_status_t EFIAPI efi_cout_set_mode(
-   struct efi_simple_text_output_protocol *this,
-   unsigned long mode_number)
-{
-   EFI_ENTRY("%p, %ld", this, mode_number);
-
-
-   if (mode_number > efi_con_mode.max_mode)
-   return EFI_EXIT(EFI_UNSUPPORTED);
-
-   efi_con_mode.mode = mode_number;
-   efi_con_mode.cursor_column = 0;
-   efi_con_mode.cursor_row = 0;
-
-   return EFI_EXIT(EFI_SUCCESS);
-}
-
 static const struct {
unsigned int fg;
unsigned int bg;
@@ -378,6 +361,20 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
return EFI_EXIT(EFI_SUCCESS);
 }

+static efi_status_t EFIAPI efi_cout_set_mode(
+   struct efi_simple_text_output_protocol *this,
+   unsigned long mode_number)
+{
+   EFI_ENTRY("%p, %ld", this, mode_number);
+
+   if (mode_number >= efi_con_mode.max_mode)
+   return EFI_EXIT(EFI_UNSUPPORTED);
+   efi_con_mode.mode = mode_number;
+   EFI_CALL(efi_cout_clear_screen(this));
+
+   return EFI_EXIT(EFI_SUCCESS);
+}
+
 static efi_status_t EFIAPI efi_cout_reset(
struct efi_simple_text_output_protocol *this,
char extended_verification)
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] efi_loader: fix SetAttribute()

[Heinrich Schuchardt]

The SetAttribute() service and the Reset() service of the simple text
output protocol must update the attribute value in the mode information.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_console.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index fef0b2e1e2..706e6ad31e 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -341,6 +341,7 @@ static efi_status_t EFIAPI efi_cout_set_attribute(

EFI_ENTRY("%p, %lx", this, attribute);

+   efi_con_mode.attribute = attribute;
if (attribute)
printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg);
else
@@ -384,6 +385,7 @@ static efi_status_t EFIAPI efi_cout_reset(
/* Clear screen */
EFI_CALL(efi_cout_clear_screen(this));
/* Set default colors */
+   efi_con_mode.attribute = 0x07;
printf(ESC "[0;37;40m");

return EFI_EXIT(EFI_SUCCESS);
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fastboot: Fix slot names reported by getvar

[Sam Protsenko]

Please drop this patch in favor of:

[PATCH v2 0/2] fastboot: Support new A/B slot format

Thanks!

On Fri, Jun 14, 2019 at 5:37 PM Sam Protsenko
 wrote:
>
> Hi Eugeniu,
>
> On Thu, Jun 13, 2019 at 8:57 PM Eugeniu Rosca  wrote:
> >
> > Hi Sam,
> >
> > Thanks for the detailed answer. Some comments below.
> >
> > On Thu, Jun 13, 2019 at 04:59:40PM +0300, Sam Protsenko wrote:
> > > Hi Eugeniu,
> > >
> > > On Thu, Jun 13, 2019 at 12:31 PM Eugeniu Rosca  
> > > wrote:
> > > >
> > > > Hi Sam,
> > > >
> > > > On Thu, Jun 13, 2019 at 12:49:45AM +0300, Sam Protsenko wrote:
> > > > > In commit [1] fastboot tool was changed w.r.t. new A/B specification 
> > > > > [2],
> > > > > and now we should report slot names in "a" format instead of "_a".
> > > > > Latter is now considered legacy and we shouldn't rely on that anymore.
> > > >
> > > > This looks like a change which advantages the users who are always on
> > > > the tip/HEAD of all relevant components (fastboot and U-Boot), but that
> > > > rarely happens in the industry. Suppliers and hardening vendors often
> > > > deliver obsoleted versions because they can't keep up with upstream
> > > > development. Can you please document the behavior of 'fastboot flash'
> > > > (and anything else relying on
> > > > 'fastboot getvar (current-slot|slot-suffixes) in below scenarios:
> > > >
> > > > A. fastboot >= [1] && U-Boot + this patch
> > > > B. fastboot >= [1] && U-Boot - this patch
> > > > C. fastboot <  [1] && U-Boot + this patch
> > > > D. fastboot <  [1] && U-Boot - this patch
> > > >
> > > > Would it be possible to keep U-Boot backward-compatible, such that
> > > > regardless of the scenario enumerated above, 'fastboot flash' will
> > > > always succeed?
> > > >
> > >
> > > I'm afraid in this particular case we weren't given any choice, and we
> > > won't be able to provide backward-compatibility for older Android
> > > releases. After this commit:
> > >
> > > [3] 
> > > https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f
> >
> > Thumbs up for pointing out this specific commit.
> >
> > >
> > > they dropped support for "_a" format completely (in fastboot tool). So:
> > >   * if user runs new fastboot tool ( >= [3]), then the only way to
> > > make "fastboot flash" work is to return slot in "a" format from
> > > bootloader
> > >   * if user runs old fastboot tool (< [1]), then the only way to make
> > > "fastboot flash" work is to return slot in "_a" format from bootloader
> >
> > This interface change seems to carry no semantic value, so it's
> > unfortunate to see such kind of non-backward-compatible update
> > contributed by the maintainers of the user-space tool.
> >
>
> Yeah, I was pretty frustrated too :) Anyway, let's try to handle this
> in U-Boot as good as we can.
>
> > > Good news is that user can basically downgrade or upgrade fastboot
> > > tool, to be in sync with U-Boot version in use. Bad news, we need to
> > > decide which Android version to break in U-Boot/master.
> > >
> > > I suggest we track AOSP/master in U-Boot/master. Please let me know if
> > > you agree, or maybe there is some better way I'm missing.
> >
> > I can't come up with a better proposal.
> >
>
> Well, theoretically we *can* provide some config option like
> AB_NEW/AB_OLD, or check similar variable in U-Boot shell, to figure
> out which format to use ("_a" or "a"). But right now A/B is not
> implemented in upstream U-Boot anyway, so we probably don't have much
> users for that feature yet. So let's implement it for the latest
> AOSP/master, and if the need arises, we can handle old format support
> later. The crucial thing is, this patch fixes "fastboot flash" in
> AOSP/master, when user has slotted partitions.
>
> > Reflecting on fastboot in general, I think there are many more
> > questions which lack a straightforward answer:
> >  - How accurately the fastboot protocol [4] reflects the AOSP
> >user-space implementation (and viceversa)?
> >  - Some basic git grepping reveals that the fastboot protocol [4]
> >was once upgraded from v0.3 to v0.4, but that's pretty much it. It
> >definitely doesn't cover the evolution of fastboot usage/parameters.
> >For example, none of the AB/slot-related parameters (e.g.
> >"slot-suffixes", "current-slot") has ever been documented in [4].
> >  - Since the protocol and the actual development are out of sync,
> >staying aligned to AOSP means asserting about the fastboot
> >interface updates by reviewing the AOSP patches (which is time
> >consuming and cannot be easily automated).
> >  - OTOH, it is also not clear to which degree U-Boot/master is aligned
> >to AOSP/master even after integrating this patch. As example,
> >commit [3] mentioned by you dropped the support for 'slot-suffixes'
> >altogether while the option is still being processed in U-Boot.
> >
>
> Agree. Someone should check AOSP patches and provide corresponding
> support for the latest fast

[U-Boot] [PATCH v2 1/2] fastboot: Remove "slot-suffixes" variable

[Sam Protsenko]

"slot-suffixes" variable was dropped in fastboot tool (in [1]). Let's
track AOSP/master and drop this variable in U-Boot as well.

[1] 
https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f

Signed-off-by: Sam Protsenko 
---
Changes in v2:
  - add this patch to patch series
  - drop slot-suffix variable instead of returning "a,b"

 drivers/fastboot/fb_getvar.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index 584c7f0263..f89c7f62e6 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -19,7 +19,6 @@ static void getvar_version_baseband(char *var_parameter, char 
*response);
 static void getvar_product(char *var_parameter, char *response);
 static void getvar_platform(char *var_parameter, char *response);
 static void getvar_current_slot(char *var_parameter, char *response);
-static void getvar_slot_suffixes(char *var_parameter, char *response);
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
 static void getvar_has_slot(char *var_parameter, char *response);
 #endif
@@ -64,9 +63,6 @@ static const struct {
}, {
.variable = "current-slot",
.dispatch = getvar_current_slot
-   }, {
-   .variable = "slot-suffixes",
-   .dispatch = getvar_slot_suffixes
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
}, {
.variable = "has-slot",
@@ -182,11 +178,6 @@ static void getvar_current_slot(char *var_parameter, char 
*response)
fastboot_okay("_a", response);
 }
 
-static void getvar_slot_suffixes(char *var_parameter, char *response)
-{
-   fastboot_okay("_a,_b", response);
-}
-
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
 static void getvar_has_slot(char *part_name, char *response)
 {
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] fastboot: Fix slot names reported by getvar

[Sam Protsenko]

Fastboot tool recently underwent changes w.r.t. A/B slot format:
  1. In commit [1] the new slot format was introduced, according to new
 A/B specification [2]. New slot format is "a", and old format "_a"
 is now considered legacy.
  2. In commit [3] the legacy format "_a" was fixed and fastboot tool
 should support both "a" and "_a" slot formats now.
  3. Finally, commit [4] drops the legacy slot format ("_a") completely.
 That makes the latest fastboot tool incompatible with "_a" format.

Last change leads to next error, when running "fastboot flash" with
current U-Boot:

$ fastboot flash boot boot.img
Sending 'boot__a' (11301 KB)OKAY [  0.451s]
Writing 'boot__a'   FAILED (remote: 'cannot find partition')
fastboot: error: Command failed

To overcome this issue we should report slot names in "a" format instead
of "_a". Of course, this change breaks U-Boot compatibility with older
fastboot tools, but that shouldn't be a problem as A/B is not
implemented in U-Boot yet, and there are not users for slotted
partitions out there anyway. This fact can be checked like this:

$ grep -Ir \b'boot_a\b' *

Let's use new slot format in order to fix "fastboot flash" with slotted
partitions and to be in sync with AOSP master.

With this patch, U-Boot depends on most recent fastboot tool (patch [1]
or later), for working with slotted partitions.

[1] 
https://android.googlesource.com/platform/system/core/+/8091947847d5e5130b09d2ac0a4bdc900f3b77c5
[2] https://source.android.com/devices/tech/ota/ab/ab_implement#partitions
[3] 
https://android.googlesource.com/platform/system/core/+/04396f62da6150b94e02d50e5302fd980048833d
[4] 
https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f

Signed-off-by: Sam Protsenko 
---
Changes in v2:
  - don't change slot format in "slot-suffixes" variable (it's now
dropped in [PATCH 1/2])
  - improve commit message

 drivers/fastboot/fb_getvar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index f89c7f62e6..9ee5054485 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -174,8 +174,8 @@ static void getvar_platform(char *var_parameter, char 
*response)
 
 static void getvar_current_slot(char *var_parameter, char *response)
 {
-   /* A/B not implemented, for now always return _a */
-   fastboot_okay("_a", response);
+   /* A/B not implemented, for now always return "a" */
+   fastboot_okay("a", response);
 }
 
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 0/2] fastboot: Support new A/B slot format

[Sam Protsenko]

Android fastboot tool was changed recently:
  1. "slot-suffixes" variable was removed
  2. Now slot format is "a" instead of "_a"

That leads to issues with current U-Boot, e.g. "fastboot flash" to
slotted partitions ("boot_a", etc) is broken. This patch series fixes
that by getting U-Boot in sync with current AOSP/master w.r.t. fastboot
tool.

Sam Protsenko (2):
  fastboot: Remove "slot-suffixes" variable
  fastboot: Fix slot names reported by getvar

 drivers/fastboot/fb_getvar.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] cmd: mem: Add a command to fill the memory with random data

[Jean-Jacques Hiblot]

This command fills the memory with data produced by rand().

Signed-off-by: Jean-Jacques Hiblot 
---
 cmd/Kconfig |  3 ++-
 cmd/mem.c   | 48 
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index ea1a325eb3..ff96ac5d14 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -517,7 +517,7 @@ config CMD_MEMINFO
  Display memory information.
 
 config CMD_MEMORY
-   bool "md, mm, nm, mw, cp, cmp, base, loop"
+   bool "md, mm, nm, mw, cp, cmp, base, loop, random"
default y
help
  Memory commands.
@@ -529,6 +529,7 @@ config CMD_MEMORY
cmp - memory compare
base - print or set address offset
loop - initialize loop on address range
+   random - fill memory with random data
 
 config CMD_MEMTEST
bool "memtest"
diff --git a/cmd/mem.c b/cmd/mem.c
index 392ed1756b..54e65be347 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -1082,6 +1082,47 @@ static int do_mem_crc(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
 
 #endif
 
+int do_random(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   unsigned long addr, len;
+   unsigned long seed; // NOT INITIALIZED ON PURPOSE
+   unsigned int *buf, *start;
+   unsigned char *buf8;
+   unsigned int i;
+
+   if (argc < 3 || argc > 4) {
+   printf("usage: %s   []\n", argv[0]);
+   return 0;
+   }
+
+   len = simple_strtoul(argv[2], NULL, 16);
+   addr = simple_strtoul(argv[1], NULL, 16);
+
+   if (argc == 4) {
+   seed = simple_strtoul(argv[3], NULL, 16);
+   if (seed == 0) {
+   printf("The seed cannot be 0. Using 0xDEADBEEF.\n");
+   seed = 0xDEADBEEF;
+   }
+   } else {
+   seed = get_timer(0) ^ rand();
+   }
+
+   srand(seed);
+   start = map_sysmem(addr, len);
+   buf = start;
+   for (i = 0; i < (len / 4); i++)
+   *buf++ = rand();
+
+   buf8 = (unsigned char *)buf;
+   for (i = 0; i < (len % 4); i++)
+   *buf8++ = rand() & 0xFF;
+
+   unmap_sysmem(start);
+   printf("%lu bytes filled with random data\n", len);
+   return 1;
+}
+
 /**/
 U_BOOT_CMD(
md, 3,  1,  do_mem_md,
@@ -1250,3 +1291,10 @@ U_BOOT_CMD(
""
 );
 #endif
+
+U_BOOT_CMD(
+   random, 4,  0,  do_random,
+   "fill memory with random pattern",
+   "  []\n"
+   "   - Fill 'len' bytes of memory starting at 'addr' with random data\n"
+);
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot partitions

[Jean-Jacques Hiblot]

Marek, Faiz,

On 11/06/2019 17:59, Faiz Abbas wrote:

Hi Marek,

On 11/06/19 3:34 PM, Marek Vasut wrote:

On 6/11/19 10:12 AM, Faiz Abbas wrote:

Peng, Marek,

On 11/06/19 6:47 AM, Peng Fan wrote:

partitions

On 6/10/19 7:59 AM, Peng Fan wrote:

Subject: Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing
boot partitions

Hi Marek, Peng,

On 03/06/19 12:04 PM, Peng Fan wrote:

Subject: [PATCH] mmc: Avoid HS400 mode when accessing boot
partitions

According to JEDEC JESD84-B51.pdf section 6.3.3 Boot operation ,
HS200 & HS400 mode is not supported during boot operation. The
U-Boot code currently only applies this restriction to HS200 mode,
extend this to
HS400 mode as well.

The spec in section 6.3.3 (according to my understanding) is talking
about "boot operation" which is a way of getting data from the the
eMMC without going through the Device identification mode (Section
6.4.4) i.e. without sending any commands. All the host has to do is
hold the command line low in Pre-Idle mode to automatically receive
data at the preconfigured frequency and bus width.

When U-boot is accessing the partition, it has already gone through
the Device identification mode and is in data transfer mode (i.e. it
needs to send commands for read/write to happen). In this case, we
need to switch the partition in Extended CSD to access the boot
partition (Section 6.2.5). The spec doesn't say anything about HS200 and

HS400 not being supported here.

Yes, the spec does not mention this. It only mentions HS200/400 not
supported during boot operation.


Also, I don't see linux kernel switching down speed when trying to
access a boot partition (unless its being very sneaky about it). So
if you are seeing issues with accessing boot partitions at
HS200/HS400 then you should probably look at how linux code is working

instead.

There might be bug in U-Boot code.

So are we gonna leave this inconsistency in for current release or what's it
gonna be ? Like I said, we're in rc3, it's fine to do bigger changes in next
release, but we should at least fix this in current release.

I'll pick up your patch in this release.


The issue that Marek is facing is not a regression, is it? Are we really
going to merge something that we know to be wrong just so we are
consistently wrong?

First of all, you established this is "wrong" without any real backing
except for your interpretation of the specification. I would still like
to hear from Jean the real reason why he added this filtering in the
first place.

I think Peng agrees with my interpretation. The backing for it being
"right" is also JJ's and your interpretation of spec. The additional
justification that I am trying to give is that there is no code to
fallback in kernel and I have observed it working in kernel with no
issues. I needed your observations (with any HS200/HS400 supporting
platform) in kernel for additional data points.


That said, we're in rc4 , the release is just around the corner. I would
like to avoid big changes in the MMC subsystem , or any subsystem for
that matter. That's for next release , and if you have a patch for next,
please post it, I am happy to test it on the hardware I have available.

I am not saying we try to fix it before this release. All I am saying is
that we don't mask real errors (none of which are regressions) with this
"fix" that we are not even sure of.


Also note that this patch does not have any impact on general use case,
the regular bulk of the eMMC can be accessed at HS200/HS400, it's just
the boot partitions which are accessed in HS52 or lower.

Exceedingly, the general usecase is to put boot images in boot partition
and root filesystem in the user data area. In that case, the boot area
is all that will be accessed in SPL at HS52 even if
CONFIG_SPL_MMC_HS200/HS400 is enabled.


However, right now, the behavior is not consistent between HS200 and
HS400 modes, and I would very much like to have it consistent in the
upcoming release.

I don't think consistency is a big enough reason to make this change. If
my interpretation is correct, you would be masking real issues for
everyone with this change and any platforms which enable HS400/HS200
will be blissfully unaware that they are not accessing data at the
required speed. If things are failing for others, we can get their
datapoints in kernel as well.

Having said that, if the maintainer still wants to pull this fix as is,
I would at least change the commit message to reflect our uncertainty
here so people are not mislead by this patch.


Marek, I understand you do not want to debug this right now but this
patch will 1) Mislead people into thinking that we know what we are
doing (two patches went in with pretty confident patch descriptions) and
2) Mask issues for people who could take the time to help debug this.

Wrong, I want to debug this, I just don't want to do big changes in the
upcoming release this late in the release cycle. But if you propose a
patch for next, I am happy to test it 

[U-Boot] Jetson TX2 hangs during dhcp boot

[Mian Yousaf Kaukab]

Hi,
I am seeing a hang with dhcp boot on Jetson TX2. Its running firmware from
L4T 32.1 with U-Boot from master branch (c2ea87883e) with [1] applied.

I use following command sequence at u-boot prompt to boot:

Tegra186 (P2771--500) # setenv ftdfile tegra186-p2771-.dtb
Tegra186 (P2771--500) # setenv boot_targets dhcp
Tegra186 (P2771--500) # boot

Last thing I see is the following error from TF-A and the board hangs:

ERROR:   ARI request timed out: req 89 on CPU 4
ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries != 0U

Here is the complete log:

U-Boot 2019.07-rc4-00137-g6fefd9c475 (Jun 14 2019 - 16:27:34 +0200)

TEGRA186
Model: NVIDIA P2771--500
Board: NVIDIA P2771-
DRAM:  7.8 GiB
MMC:   sdhci@340: 1, sdhci@346: 0
Loading Environment from MMC... OK
In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@249
Hit any key to stop autoboot:  0 
Tegra186 (P2771--500) # setenv boot_targets dhcp
Tegra186 (P2771--500) # boot
starting USB...
No working controllers found
maximum number of regions parsed, aborting
ethernet@249 Waiting for PHY auto negotiation to complete.. done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address xx.xx.xx.xx (1259 ms)
Using ethernet@249 device
TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx
Filename 'boot.scr.uimg'.
Load address: 0x8260
Loading: *
TFTP error: 'File not found' (1)
Not retrying...
ethernet@249 Waiting for PHY auto negotiation to complete done
BOOTP broadcast 1
DHCP client bound to address xx.xx.xx.xx (5 ms)
Using ethernet@249 device
TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx
Filename 'aarch64/grub.efi'.
Load address: 0x8028
Loading: T ###T ##
 #
 ##
 181.6 KiB/s
done
Bytes transferred = 1936896 (1d8e00 hex)
ethernet@249 Waiting for PHY auto negotiation to complete done
Using ethernet@249 device
TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx
Filename 'dtb/tegra186-p2771-.dtb'.
Load address: 0x8240
Loading: ###
 2.6 MiB/s
done
Bytes transferred = 30196 (75f4 hex)
MMC: no card present
Scanning disk sd...@340.blk...
Disk sd...@340.blk not ready
Scanning disk sd...@346.blk...
Found 32 disks
copying carveout for /host1x@13e0/display-hub@1520/display@1520...
copying carveout for /host1x@13e0/display-hub@1520/display@1521...
copying carveout for /host1x@13e0/display-hub@1520/display@1522...
ERROR:   ARI request timed out: req 89 on CPU 4
ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries != 0U

It turned out that the last call to TF-A was from __asm_invalidate_l3_icache().
Following is the call trace: 

efi_load_image()
efi_load_pe()
invalidate_icache_all()
__asm_invalidate_l3_icache() 
 
__asm_invalidate_l3_icache() has been called a couple of times before this point
without any issues.

If I boot the same EFI binary manually with bootefi it works fine. I can see 
that
__asm_invalidate_l3_icache() returns without the hang. Following is the working
command sequence:

Tegra186 (P2771--500) # dhcp
Tegra186 (P2771--500) # tftpboot $fdt_addr_r dtb/tegra186-p2771-.dtb
Tegra186 (P2771--500) # tftpboot $kernel_addr_r aarch64/grub.efi
Tegra186 (P2771--500) # bootefi $kernel_addr_r $fdt_addr_r

This issue is 100% reproducible. 

Any thoughts on what could be wrong or how to debug it further?

Thanks,
Yousaf

[1]: https://patchwork.ozlabs.org/patch/1115052/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: missing request op in common pinctrl driver resulting kernel boot failure

[Mark Kettenis]

> From: Levin Du 
> Date: Fri, 14 Jun 2019 17:09:43 +0800
> 
> Hi all,
> 
> I try U-Boot v2019.04 on the Firefly-RK3399 board and the kernel failed during
> loading. After doing some `git bisect`, I find the commit
> e7ae4cf27a6d5837cb5e868712cdaa61d3ceb5e0 (which is adding common rockchip
> pinctrl driver) is where the problem starts to emerge.
> 
> After some trial and error, it seems that the new pinctrl driver has got rid
> of the request op. But in board/rockchip/evb_rk3399/evb-rk3399.c:
> 
> 
>/* Enable pwm0 for panel backlight */  
> 
>ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0);
> 
>if (ret) { 
> 
>debug("%s PWM0 pinctrl init fail! (ret=%d)\n", __func__, ret); 
> 
>goto out;  
> 
>}  
> 
>  
> > 
> The pinctrl_request_noflags call will fail and end, skiping the regulator
> operations in normal flow.
> 
> Adding a dummy request function (return 0) to rockchip_pinctrl_ops solves the
> kernel hang: 
> 
> +static int rockchip_pinctrl_request(struct udevice *dev, int func, int flags)
> +{
> +   struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
> +
> +   debug("%s: func=%x, flags=%x\n", __func__, func, flags);
> +   return 0;
> +}
> +
>  const struct pinctrl_ops rockchip_pinctrl_ops = {
> +.request  = rockchip_pinctrl_request,
> .set_state  = rockchip_pinctrl_set_state,
> .get_gpio_mux   = rockchip_pinctrl_get_gpio_mux,
>  };
> 
> But I wonder why no other RK3399 boards experience the same problem. If I'd
> like to write a patch to address this, a dummy request function is not proper
> IMO. I'm seeking your advice. Thanks in advance.

Thanks for tracking this down!  I had noticed that something broke but
I didn't find the time to track this down yet.

I suspect that since CONFIG_PINCTRL_FULL is enabled all the
pinctrl_request() and pinctrl_request_noflags() calls are no longer
necessary and should probably be removed.  Hopefully somebody who is
more knowledgeable in this area can confirm?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fastboot: Fix slot names reported by getvar

[Sam Protsenko]

Hi Eugeniu,

On Thu, Jun 13, 2019 at 8:57 PM Eugeniu Rosca  wrote:
>
> Hi Sam,
>
> Thanks for the detailed answer. Some comments below.
>
> On Thu, Jun 13, 2019 at 04:59:40PM +0300, Sam Protsenko wrote:
> > Hi Eugeniu,
> >
> > On Thu, Jun 13, 2019 at 12:31 PM Eugeniu Rosca  
> > wrote:
> > >
> > > Hi Sam,
> > >
> > > On Thu, Jun 13, 2019 at 12:49:45AM +0300, Sam Protsenko wrote:
> > > > In commit [1] fastboot tool was changed w.r.t. new A/B specification 
> > > > [2],
> > > > and now we should report slot names in "a" format instead of "_a".
> > > > Latter is now considered legacy and we shouldn't rely on that anymore.
> > >
> > > This looks like a change which advantages the users who are always on
> > > the tip/HEAD of all relevant components (fastboot and U-Boot), but that
> > > rarely happens in the industry. Suppliers and hardening vendors often
> > > deliver obsoleted versions because they can't keep up with upstream
> > > development. Can you please document the behavior of 'fastboot flash'
> > > (and anything else relying on
> > > 'fastboot getvar (current-slot|slot-suffixes) in below scenarios:
> > >
> > > A. fastboot >= [1] && U-Boot + this patch
> > > B. fastboot >= [1] && U-Boot - this patch
> > > C. fastboot <  [1] && U-Boot + this patch
> > > D. fastboot <  [1] && U-Boot - this patch
> > >
> > > Would it be possible to keep U-Boot backward-compatible, such that
> > > regardless of the scenario enumerated above, 'fastboot flash' will
> > > always succeed?
> > >
> >
> > I'm afraid in this particular case we weren't given any choice, and we
> > won't be able to provide backward-compatibility for older Android
> > releases. After this commit:
> >
> > [3] 
> > https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f
>
> Thumbs up for pointing out this specific commit.
>
> >
> > they dropped support for "_a" format completely (in fastboot tool). So:
> >   * if user runs new fastboot tool ( >= [3]), then the only way to
> > make "fastboot flash" work is to return slot in "a" format from
> > bootloader
> >   * if user runs old fastboot tool (< [1]), then the only way to make
> > "fastboot flash" work is to return slot in "_a" format from bootloader
>
> This interface change seems to carry no semantic value, so it's
> unfortunate to see such kind of non-backward-compatible update
> contributed by the maintainers of the user-space tool.
>

Yeah, I was pretty frustrated too :) Anyway, let's try to handle this
in U-Boot as good as we can.

> > Good news is that user can basically downgrade or upgrade fastboot
> > tool, to be in sync with U-Boot version in use. Bad news, we need to
> > decide which Android version to break in U-Boot/master.
> >
> > I suggest we track AOSP/master in U-Boot/master. Please let me know if
> > you agree, or maybe there is some better way I'm missing.
>
> I can't come up with a better proposal.
>

Well, theoretically we *can* provide some config option like
AB_NEW/AB_OLD, or check similar variable in U-Boot shell, to figure
out which format to use ("_a" or "a"). But right now A/B is not
implemented in upstream U-Boot anyway, so we probably don't have much
users for that feature yet. So let's implement it for the latest
AOSP/master, and if the need arises, we can handle old format support
later. The crucial thing is, this patch fixes "fastboot flash" in
AOSP/master, when user has slotted partitions.

> Reflecting on fastboot in general, I think there are many more
> questions which lack a straightforward answer:
>  - How accurately the fastboot protocol [4] reflects the AOSP
>user-space implementation (and viceversa)?
>  - Some basic git grepping reveals that the fastboot protocol [4]
>was once upgraded from v0.3 to v0.4, but that's pretty much it. It
>definitely doesn't cover the evolution of fastboot usage/parameters.
>For example, none of the AB/slot-related parameters (e.g.
>"slot-suffixes", "current-slot") has ever been documented in [4].
>  - Since the protocol and the actual development are out of sync,
>staying aligned to AOSP means asserting about the fastboot
>interface updates by reviewing the AOSP patches (which is time
>consuming and cannot be easily automated).
>  - OTOH, it is also not clear to which degree U-Boot/master is aligned
>to AOSP/master even after integrating this patch. As example,
>commit [3] mentioned by you dropped the support for 'slot-suffixes'
>altogether while the option is still being processed in U-Boot.
>

Agree. Someone should check AOSP patches and provide corresponding
support for the latest fastboot tool feature. I will probably look
into that later, as we want this for our platforms to be implemented.

I'm gonna send v2 soon, addressing your comments (will remove
slot-suffixes variable and improve commit message). Thanks for your
input!


> In a nutshell, I think we have no other choice but to apply this fix
> (still not clear if w/ or w/o keeping the

Re: [U-Boot] [PATCH v3 2/3] fastboot: getvar: Refactor fastboot_*_get_part_info() usage

[Eugeniu Rosca]

Hi Sam,

On Fri, Jun 14, 2019 at 03:41:17PM +0300, Sam Protsenko wrote:
[..]
> So I hope you don't mind if we leave this as is in this patch?

Fine. Thanks for the background.

-- 
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] cmd: part: Add 'number' sub-command

[Igor Opaniuk]

Hi Eugeniu,

On Fri, Jun 14, 2019 at 5:08 PM Eugeniu Rosca  wrote:
>
> Hi Igor,
>
> I believe it's common sense, best practice and it is generally polite
> to include in CC anybody who contributed with review comments during
> the previous patch iterations. Otherwise, it raises questions,
> mistrust and all kind of weird assumptions, which may hurt the
> community in the long run. I believe the beauty of community-driven
> development is being straight to each other and keeping things
> transparent. So, if you don't mind, please include me in CC if I've
> already commented on your patches.
>
> --
> Best regards,
> Eugeniu.

Sorry, it's just my inattention (Friday evening, you know :) ), I've
copied-pasted (yes,
I still can't force myself to use patman and somehow automate this process)
the list of people from CC headers from v3 patch [1], so please don't take
it personally.

Thanks for all your effort and reviews of my patches, I really appreciate it.

[1] https://patchwork.ozlabs.org/patch/1044151/

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] cmd: part: Add 'number' sub-command

[Sam Protsenko]

Hi Igor,

Once again:

Reviewed-by: Sam Protsenko 

Thanks!

On Fri, Jun 14, 2019 at 5:01 PM Igor Opaniuk  wrote:
>
> From: Ruslan Trofymenko 
>
> This sub-command serves for getting the partition index from
> partition name. Also it can be used to test the existence of specified
> partition.
>
> Use case:
> For example, in most CI environments this U-Boot command for automatic
> testing of Linux rootfs is used:
>
> => setenv bootpart 1:f
>
> where 0xf is "userdata" partition. But the number of "userdata"
> partition can be changed any time, when partition table is changed.
>
> So it would be nice to get rid of that 0xf magic number and use
> partition name instead, like this:
>
> => part number mmc 1 userdata part_num
> => setenv bootpart 1:${part_num}
>
> Signed-off-by: Ruslan Trofymenko 
> Signed-off-by: Igor Opaniuk 
> Reviewed-by: Alistair Strachan 
> Reviewed-by: Sam Protsenko 
> Reviewed-by: Simon Glass 
> ---
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  cmd/part.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/part.c b/cmd/part.c
> index bfb6488b0f..653e13ced1 100644
> --- a/cmd/part.c
> +++ b/cmd/part.c
> @@ -24,6 +24,7 @@
>  enum cmd_part_info {
> CMD_PART_INFO_START = 0,
> CMD_PART_INFO_SIZE,
> +   CMD_PART_INFO_NUMBER
>  };
>
>  static int do_part_uuid(int argc, char * const argv[])
> @@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[], 
> enum cmd_part_info param)
> case CMD_PART_INFO_SIZE:
> snprintf(buf, sizeof(buf), LBAF, info.size);
> break;
> +   case CMD_PART_INFO_NUMBER:
> +   snprintf(buf, sizeof(buf), "%d", part);
> +   break;
> default:
> printf("** Unknown cmd_part_info value: %d\n", param);
> return 1;
> @@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
> return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
>  }
>
> +static int do_part_number(int argc, char * const argv[])
> +{
> +   return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
> +}
> +
>  static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>  {
> if (argc < 2)
> @@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> return do_part_start(argc - 2, argv + 2);
> else if (!strcmp(argv[1], "size"))
> return do_part_size(argc - 2, argv + 2);
> +   else if (!strcmp(argv[1], "number"))
> +   return do_part_number(argc - 2, argv + 2);
>
> return CMD_RET_USAGE;
>  }
> @@ -206,5 +217,8 @@ U_BOOT_CMD(
> "  part can be either partition number or partition name\n"
> "part size\n"
> "- set environment variable to the size of the partition (in 
> blocks)\n"
> -   "  part can be either partition number or partition name"
> +   "  part can be either partition number or partition name\n"
> +   "part number\n"
> +   "- set environment variable to the partition number using the 
> partition name\n"
> +   "  part must be specified as partition name"
>  );
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] cmd: part: Add 'number' sub-command

[Eugeniu Rosca]

Hi Igor,

I believe it's common sense, best practice and it is generally polite
to include in CC anybody who contributed with review comments during
the previous patch iterations. Otherwise, it raises questions,
mistrust and all kind of weird assumptions, which may hurt the
community in the long run. I believe the beauty of community-driven
development is being straight to each other and keeping things
transparent. So, if you don't mind, please include me in CC if I've
already commented on your patches.

-- 
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: am3517-evm: Enable DM_PMIC and DM_REGULATOR functions

[Adam Ford]

The PBIAS regulator is available on OMAP3's, and it's shared on
the AM35, so this patch enables that in U-Boot along with GPIO
based regulators.

Signed-off-by: Adam Ford 

diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index b9f59f3291..f61a86b115 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -17,6 +17,7 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 # CONFIG_SPL_FS_EXT4 is not set
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
+# CONFIG_SPL_POWER_SUPPORT is not set
 CONFIG_SYS_PROMPT="AM3517_EVM # "
 # CONFIG_CMD_IMI is not set
 CONFIG_CMD_SPL=y
@@ -48,6 +49,11 @@ CONFIG_MII=y
 CONFIG_DRIVER_TI_EMAC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
+CONFIG_DM_PMIC=y
+# CONFIG_SPL_PMIC_CHILDREN is not set
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
 # CONFIG_TWL4030_POWER is not set
 CONFIG_CONS_INDEX=3
 CONFIG_SPI=y
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190612

[Tom Rini]

On Wed, Jun 12, 2019 at 04:59:32PM +0200, Neil Armstrong wrote:

> Hi Tom,
> 
> This PR is only for pinctrl, fixing HDMI support for GXBB fixing badly
> defined pins for GXL & GXBB, adds support for getting pinmux status and
> finally adds drive-strength-microamp support for G12A, fixing external
> ethernet PHY support.
> 
> Thanks,
> Neil
> 
> The following changes since commit 68b90e57bc034e237923b02acb633dc4e91d44cb:
> 
>   configs: tinker-rk3288 disable CONFIG_SPL_I2C_SUPPORT (2019-06-11 08:13:05 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20190612
> 
> for you to fetch changes up to 63860dbfdfdda97a8af7fd16c184d45648db3506:
> 
>   pinctrl: meson-gxbb: add hdmi related pins (2019-06-12 11:50:02 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v5 1/1] cmd: part: Add 'number' sub-command

[Igor Opaniuk]

From: Ruslan Trofymenko 

This sub-command serves for getting the partition index from
partition name. Also it can be used to test the existence of specified
partition.

Use case:
For example, in most CI environments this U-Boot command for automatic
testing of Linux rootfs is used:

=> setenv bootpart 1:f

where 0xf is "userdata" partition. But the number of "userdata"
partition can be changed any time, when partition table is changed.

So it would be nice to get rid of that 0xf magic number and use
partition name instead, like this:

=> part number mmc 1 userdata part_num
=> setenv bootpart 1:${part_num}

Signed-off-by: Ruslan Trofymenko 
Signed-off-by: Igor Opaniuk 
Reviewed-by: Alistair Strachan 
Reviewed-by: Sam Protsenko 
Reviewed-by: Simon Glass 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 cmd/part.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/cmd/part.c b/cmd/part.c
index bfb6488b0f..653e13ced1 100644
--- a/cmd/part.c
+++ b/cmd/part.c
@@ -24,6 +24,7 @@
 enum cmd_part_info {
CMD_PART_INFO_START = 0,
CMD_PART_INFO_SIZE,
+   CMD_PART_INFO_NUMBER
 };
 
 static int do_part_uuid(int argc, char * const argv[])
@@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[], enum 
cmd_part_info param)
case CMD_PART_INFO_SIZE:
snprintf(buf, sizeof(buf), LBAF, info.size);
break;
+   case CMD_PART_INFO_NUMBER:
+   snprintf(buf, sizeof(buf), "%d", part);
+   break;
default:
printf("** Unknown cmd_part_info value: %d\n", param);
return 1;
@@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
 }
 
+static int do_part_number(int argc, char * const argv[])
+{
+   return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
+}
+
 static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
if (argc < 2)
@@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return do_part_start(argc - 2, argv + 2);
else if (!strcmp(argv[1], "size"))
return do_part_size(argc - 2, argv + 2);
+   else if (!strcmp(argv[1], "number"))
+   return do_part_number(argc - 2, argv + 2);
 
return CMD_RET_USAGE;
 }
@@ -206,5 +217,8 @@ U_BOOT_CMD(
"  part can be either partition number or partition name\n"
"part size\n"
"- set environment variable to the size of the partition (in 
blocks)\n"
-   "  part can be either partition number or partition name"
+   "  part can be either partition number or partition name\n"
+   "part number\n"
+   "- set environment variable to the partition number using the 
partition name\n"
+   "  part must be specified as partition name"
 );
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/2] cmd: part: Add 'number' sub-command

[Eugeniu Rosca]

Hi Roman,

On Fri, Jun 14, 2019 at 3:26 PM Roman Stratiienko
 wrote:
>
> On Fri, Jun 14, 2019 at 4:04 PM Igor Opaniuk  wrote:
> > From: Ruslan Trofymenko 
[..]
> > This sub-command serves for getting the partition index from
[..]
> > +   CMD_PART_INFO_NUMBER
[..]
> > +   "part number\n"
[..]
> Hello Igor,
>
> It would be nice if you would address Eugeniy Rosca comment (
> https://patchwork.ozlabs.org/patch/1044151/ ),
> and rename 'number' to 'index'

I believe the author and reviewers lean towards "partition number"
instead of "partition index" (even if the two are used intermixed in
the patch). I won't argue against that. Thanks for your comment.

-- 
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/2] Extend 'part' cmd and C API to get part info

[Igor Opaniuk]

Please ignore this patch-set,
"disk: part: Extend API to get partition info" won't be used and was
sent by by confusion.
I'll re-send a single "cmd: part: Add 'number' sub-command" as v5.

On Fri, Jun 14, 2019 at 4:04 PM Igor Opaniuk  wrote:
>
> This patch-series extends `part` cmd and disk/part C API for getting
> partition info by it's name:
>
> 1. part "number" sub-command serves for getting the partition index from
> partition name. Also it can be used to test the existence of specified
> partition.
>
> 2. Introduces part_get_info_by_dev_and_name_or_num() function which
> allows us to get partition info from its number or name. Partition of
> interest is specified by string like "device_num:partition_number" or
> "device_num#partition_name".
>
> Initially these patches were a part of
> "android: implement A/B boot process" [1] patch-series, but then
> due to multiple requests decided to send it separately, while the
> work on A/B series is still in progress.
>
>
> Use case:
>
> For example, in Linaro Lab this U-Boot command for automatic testing
> of Linux rootfs is used:
>
> => setenv bootpart 1:f
>
> where 0xf is "userdata" partition. But the number of "userdata"
> partition can be changed any time, when partition table is changed.
>
> So it would be nice to get rid of that 0xf magic number and use
> partition name instead, like this:
>
> => part number mmc 1 userdata part_num
> => setenv bootpart 1:${part_num}
>
>
> [1] https://patchwork.ozlabs.org/cover/1044152/
>
> Ruslan Trofymenko (2):
>   cmd: part: Add 'number' sub-command
>   disk: part: Extend API to get partition info
>
>  cmd/part.c | 16 +++-
>  disk/part.c| 68 ++
>  include/part.h | 21 
>  3 files changed, 104 insertions(+), 1 deletion(-)
>
> --
> 2.17.1
>


-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/2] cmd: part: Add 'number' sub-command

[Igor Opaniuk]

Hi Roman,

On Fri, Jun 14, 2019 at 4:26 PM Roman Stratiienko
 wrote:
>
> On Fri, Jun 14, 2019 at 4:04 PM Igor Opaniuk  wrote:
> >
> > From: Ruslan Trofymenko 
> >
> > This sub-command serves for getting the partition index from
> > partition name. Also it can be used to test the existence of specified
> > partition.
> >
> > Signed-off-by: Ruslan Trofymenko 
> > Signed-off-by: Igor Opaniuk 
> > Reviewed-by: Alistair Strachan 
> > Reviewed-by: Sam Protsenko 
> > Reviewed-by: Simon Glass 
> > ---
> >
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> >  cmd/part.c | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/part.c b/cmd/part.c
> > index bfb6488b0f..653e13ced1 100644
> > --- a/cmd/part.c
> > +++ b/cmd/part.c
> > @@ -24,6 +24,7 @@
> >  enum cmd_part_info {
> > CMD_PART_INFO_START = 0,
> > CMD_PART_INFO_SIZE,
> > +   CMD_PART_INFO_NUMBER
> >  };
> >
> >  static int do_part_uuid(int argc, char * const argv[])
> > @@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[], 
> > enum cmd_part_info param)
> > case CMD_PART_INFO_SIZE:
> > snprintf(buf, sizeof(buf), LBAF, info.size);
> > break;
> > +   case CMD_PART_INFO_NUMBER:
> > +   snprintf(buf, sizeof(buf), "%d", part);
> > +   break;
> > default:
> > printf("** Unknown cmd_part_info value: %d\n", param);
> > return 1;
> > @@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
> > return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
> >  }
> >
> > +static int do_part_number(int argc, char * const argv[])
> > +{
> > +   return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
> > +}
> > +
> >  static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> >  {
> > if (argc < 2)
> > @@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char * const argv[])
> > return do_part_start(argc - 2, argv + 2);
> > else if (!strcmp(argv[1], "size"))
> > return do_part_size(argc - 2, argv + 2);
> > +   else if (!strcmp(argv[1], "number"))
> > +   return do_part_number(argc - 2, argv + 2);
> >
> > return CMD_RET_USAGE;
> >  }
> > @@ -206,5 +217,8 @@ U_BOOT_CMD(
> > "  part can be either partition number or partition name\n"
> > "part size\n"
> > "- set environment variable to the size of the partition (in 
> > blocks)\n"
> > -   "  part can be either partition number or partition name"
> > +   "  part can be either partition number or partition name\n"
> > +   "part number\n"
> > +   "- set environment variable to the partition number using the 
> > partition name\n"
> > +   "  part must be specified as partition name"
> >  );
> > --
> > 2.17.1
> >
>
> Hello Igor,
>
> It would be nice if you would address Eugeniy Rosca comment (
> https://patchwork.ozlabs.org/patch/1044151/ ),
> and rename 'number' to 'index'
>
> Anyway, thank you for the update,
>
> --
> Best regards,
> Roman Stratiienko


There is already pending discussion about re-naming "number" to "index" [1]
The main point is that it's already a long-established expression, which is used
everywhere within cmd/part.c and disk/part.c, so before introducing new
term "index", previous instances of "number" should be replaces with "index".
So renaming "number" to "index" within this patch-set will just create
more confusion,
IMHO.

[1] https://patchwork.ozlabs.org/patch/1115517/

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Issue enabling TPM 2.0 on RPI

[Elena Unix]

Hello,

I am trying to enable the TPM 2.0 SLB9670 in U-Boot for a Raspberry Pi 3 B+. 
More precisely, the TPM is on an add-on board, the IRIDIUM SLB9670.
The communication between the RPI and the TPM is ensured by SPI so I enabled 
the software spi driver (spi-gpio) in U-Boot because the bcm28x spi driver is 
not available in U-Boot.

CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_SOFT_SPI=y

Then, I enabled the TPM support in U-Boot.

CONFIG_CMD_TPM_V2=y
CONFIG_CMD_TPM=y
CONFIG_TPM_V2=y
CONFIG_TPM2_TIS_SPI=y
CONFIG_TPM=y

Finally, I updated my Device Tree.
/dts-v1/
/ {
...
   aliases {
   spi0 = &soft_spi;
   };

   soft_spi: soft-spi {
   compatible = "spi-gpio";
   pinctrl-names = "default";
   pinctrl-0 = <&spi0_gpio7>;
   status = "okay";
   gpio-sck = <&gpio 11 0>;
   gpio-mosi = <&gpio 10 0>;
   gpio-miso = <&gpio 9 0>;
   cs-gpios = <&gpio 7 1>;
   #address-cells = <1>;
   #size-cells = <0>;

   slb9670: slb9670@0 {
   compatible = "tis,tpm2-spi";
   reg = <1>;
   #address-cells = <1>;
   #size-cells = <0>;
   spi-max-frequency = <3200>;
   status = "okay";
   };
   };

   spio0_gpio7: spio0_gpio7 {
   brcm,pins = <7 8 9 10 11>;
   brcm,function = <4>;
   };
...
};

But, when I try to execute the following command : 
U-Boot> tpm2 init

I have the following response :

tpm_tis_spi_probe : missing reset GPIO
tpm_tis_spi_request_locality : Timeout getting locality : -2
tpm_tis_spi_probe : could not request locality 0
Could not find TPM (ret=-2)

The Iridium board contains a reset circuit on board, which pulls the reset line 
of the TPM to GND after VCC becomes available, so the reset GPIO is not needed 
I think.

I don’t see what is wrong with my setup, a little help would be very 
appreciated.

Thank you in advance, 
Elena
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/2] cmd: part: Add 'number' sub-command

[Roman Stratiienko]

On Fri, Jun 14, 2019 at 4:04 PM Igor Opaniuk  wrote:
>
> From: Ruslan Trofymenko 
>
> This sub-command serves for getting the partition index from
> partition name. Also it can be used to test the existence of specified
> partition.
>
> Signed-off-by: Ruslan Trofymenko 
> Signed-off-by: Igor Opaniuk 
> Reviewed-by: Alistair Strachan 
> Reviewed-by: Sam Protsenko 
> Reviewed-by: Simon Glass 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  cmd/part.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/part.c b/cmd/part.c
> index bfb6488b0f..653e13ced1 100644
> --- a/cmd/part.c
> +++ b/cmd/part.c
> @@ -24,6 +24,7 @@
>  enum cmd_part_info {
> CMD_PART_INFO_START = 0,
> CMD_PART_INFO_SIZE,
> +   CMD_PART_INFO_NUMBER
>  };
>
>  static int do_part_uuid(int argc, char * const argv[])
> @@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[], 
> enum cmd_part_info param)
> case CMD_PART_INFO_SIZE:
> snprintf(buf, sizeof(buf), LBAF, info.size);
> break;
> +   case CMD_PART_INFO_NUMBER:
> +   snprintf(buf, sizeof(buf), "%d", part);
> +   break;
> default:
> printf("** Unknown cmd_part_info value: %d\n", param);
> return 1;
> @@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
> return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
>  }
>
> +static int do_part_number(int argc, char * const argv[])
> +{
> +   return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
> +}
> +
>  static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>  {
> if (argc < 2)
> @@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> return do_part_start(argc - 2, argv + 2);
> else if (!strcmp(argv[1], "size"))
> return do_part_size(argc - 2, argv + 2);
> +   else if (!strcmp(argv[1], "number"))
> +   return do_part_number(argc - 2, argv + 2);
>
> return CMD_RET_USAGE;
>  }
> @@ -206,5 +217,8 @@ U_BOOT_CMD(
> "  part can be either partition number or partition name\n"
> "part size\n"
> "- set environment variable to the size of the partition (in 
> blocks)\n"
> -   "  part can be either partition number or partition name"
> +   "  part can be either partition number or partition name\n"
> +   "part number\n"
> +   "- set environment variable to the partition number using the 
> partition name\n"
> +   "  part must be specified as partition name"
>  );
> --
> 2.17.1
>

Hello Igor,

It would be nice if you would address Eugeniy Rosca comment (
https://patchwork.ozlabs.org/patch/1044151/ ),
and rename 'number' to 'index'

Anyway, thank you for the update,

-- 
Best regards,
Roman Stratiienko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] rockchip: missing request op in common pinctrl driver resulting kernel boot failure

[Levin Du]

Hi all,

I try U-Boot v2019.04 on the Firefly-RK3399 board and the kernel failed during
loading. After doing some `git bisect`, I find the commit
e7ae4cf27a6d5837cb5e868712cdaa61d3ceb5e0 (which is adding common rockchip
pinctrl driver) is where the problem starts to emerge.

After some trial and error, it seems that the new pinctrl driver has got rid
of the request op. But in board/rockchip/evb_rk3399/evb-rk3399.c:


   /* Enable pwm0 for panel backlight */
  
   ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0);  
  
   if (ret) {   
  
   debug("%s PWM0 pinctrl init fail! (ret=%d)\n", __func__, ret);   
  
   goto out;
  
   }
  

  

The pinctrl_request_noflags call will fail and end, skiping the regulator
operations in normal flow.

Adding a dummy request function (return 0) to rockchip_pinctrl_ops solves the
kernel hang: 

+static int rockchip_pinctrl_request(struct udevice *dev, int func, int flags)
+{
+   struct rockchip_pinctrl_priv *priv = dev_get_priv(dev);
+
+   debug("%s: func=%x, flags=%x\n", __func__, func, flags);
+   return 0;
+}
+
 const struct pinctrl_ops rockchip_pinctrl_ops = {
+.request  = rockchip_pinctrl_request,
.set_state  = rockchip_pinctrl_set_state,
.get_gpio_mux   = rockchip_pinctrl_get_gpio_mux,
 };

But I wonder why no other RK3399 boards experience the same problem. If I'd
like to write a patch to address this, a dummy request function is not proper
IMO. I'm seeking your advice. Thanks in advance.

Best Regards,
-- 
Levin Du


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 2/2] disk: part: Extend API to get partition info

[Igor Opaniuk]

From: Ruslan Trofymenko 

This patch adds part_get_info_by_dev_and_name_or_num() function which
allows us to get partition info from its number or name. Partition of
interest is specified by string like "device_num:partition_number" or
"device_num#partition_name".

The patch was extracted from [1].

[1] 
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2

Signed-off-by: Ruslan Trofymenko 
Signed-off-by: Igor Opaniuk 
Reviewed-by: Alistair Strachan 
Reviewed-by: Sam Protsenko 
Reviewed-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
  * Error codes are changed to -EINVAL instead of -1

 disk/part.c| 68 ++
 include/part.h | 21 
 2 files changed, 89 insertions(+)

diff --git a/disk/part.c b/disk/part.c
index 98cc54db20..580604c2bb 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -675,6 +675,74 @@ int part_get_info_by_name(struct blk_desc *dev_desc, const 
char *name,
return part_get_info_by_name_type(dev_desc, name, info, PART_TYPE_ALL);
 }
 
+/**
+ * Get partition info from device number and partition name.
+ *
+ * Parse a device number and partition name string in the form of
+ * "device_num#partition_name", for example "0#misc". If the partition
+ * is found, sets dev_desc and part_info accordingly with the information
+ * of the partition with the given partition_name.
+ *
+ * @param[in] dev_iface Device interface
+ * @param[in] dev_part_str Input string argument, like "0#misc"
+ * @param[out] dev_desc Place to store the device description pointer
+ * @param[out] part_info Place to store the partition information
+ * @return 0 on success, or a negative on error
+ */
+static int part_get_info_by_dev_and_name(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+   char *ep;
+   const char *part_str;
+   int dev_num;
+
+   part_str = strchr(dev_part_str, '#');
+   if (!part_str || part_str == dev_part_str)
+   return -EINVAL;
+
+   dev_num = simple_strtoul(dev_part_str, &ep, 16);
+   if (ep != part_str) {
+   /* Not all the first part before the # was parsed. */
+   return -EINVAL;
+   }
+   part_str++;
+
+   *dev_desc = blk_get_dev(dev_iface, dev_num);
+   if (!*dev_desc) {
+   printf("Could not find %s %d\n", dev_iface, dev_num);
+   return -EINVAL;
+   }
+   if (part_get_info_by_name(*dev_desc, part_str, part_info) < 0) {
+   printf("Could not find \"%s\" partition\n", part_str);
+   return -EINVAL;
+   }
+   return 0;
+}
+
+int part_get_info_by_dev_and_name_or_num(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+   /* Split the part_name if passed as "$dev_num#part_name". */
+   if (!part_get_info_by_dev_and_name(dev_iface, dev_part_str,
+  dev_desc, part_info))
+   return 0;
+   /*
+* Couldn't lookup by name, try looking up the partition description
+* directly.
+*/
+   if (blk_get_device_part_str(dev_iface, dev_part_str,
+   dev_desc, part_info, 1) < 0) {
+   printf("Couldn't find partition %s %s\n",
+  dev_iface, dev_part_str);
+   return -EINVAL;
+   }
+   return 0;
+}
+
 void part_set_generic_name(const struct blk_desc *dev_desc,
int part_num, char *name)
 {
diff --git a/include/part.h b/include/part.h
index ebca546db5..0b5cf3d5e8 100644
--- a/include/part.h
+++ b/include/part.h
@@ -201,6 +201,27 @@ int part_get_info_by_name_type(struct blk_desc *dev_desc, 
const char *name,
 int part_get_info_by_name(struct blk_desc *dev_desc,
  const char *name, disk_partition_t *info);
 
+/**
+ * Get partition info from dev number + part name, or dev number + part number.
+ *
+ * Parse a device number and partition description (either name or number)
+ * in the form of device number plus partition name separated by a "#"
+ * (like "device_num#partition_name") or a device number plus a partition 
number
+ * separated by a ":". For example both "0#misc" and "0:1" can be valid
+ * partition descriptions for a given interface. If the partition is found, 
sets
+ * dev_desc and part_info accordingly with the information of the partition.
+ *
+ * @param[in] dev_ifaceDevice interface
+ * @param[in] dev_part_str Input partition description, like "0#misc" or "0:1"
+ * @param[out] dev_descPlace to store the device description pointer
+ * @param[out] part_info Place to store t

[U-Boot] [PATCH v4 1/2] cmd: part: Add 'number' sub-command

[Igor Opaniuk]

From: Ruslan Trofymenko 

This sub-command serves for getting the partition index from
partition name. Also it can be used to test the existence of specified
partition.

Signed-off-by: Ruslan Trofymenko 
Signed-off-by: Igor Opaniuk 
Reviewed-by: Alistair Strachan 
Reviewed-by: Sam Protsenko 
Reviewed-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 cmd/part.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/cmd/part.c b/cmd/part.c
index bfb6488b0f..653e13ced1 100644
--- a/cmd/part.c
+++ b/cmd/part.c
@@ -24,6 +24,7 @@
 enum cmd_part_info {
CMD_PART_INFO_START = 0,
CMD_PART_INFO_SIZE,
+   CMD_PART_INFO_NUMBER
 };
 
 static int do_part_uuid(int argc, char * const argv[])
@@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[], enum 
cmd_part_info param)
case CMD_PART_INFO_SIZE:
snprintf(buf, sizeof(buf), LBAF, info.size);
break;
+   case CMD_PART_INFO_NUMBER:
+   snprintf(buf, sizeof(buf), "%d", part);
+   break;
default:
printf("** Unknown cmd_part_info value: %d\n", param);
return 1;
@@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
 }
 
+static int do_part_number(int argc, char * const argv[])
+{
+   return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
+}
+
 static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
if (argc < 2)
@@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return do_part_start(argc - 2, argv + 2);
else if (!strcmp(argv[1], "size"))
return do_part_size(argc - 2, argv + 2);
+   else if (!strcmp(argv[1], "number"))
+   return do_part_number(argc - 2, argv + 2);
 
return CMD_RET_USAGE;
 }
@@ -206,5 +217,8 @@ U_BOOT_CMD(
"  part can be either partition number or partition name\n"
"part size\n"
"- set environment variable to the size of the partition (in 
blocks)\n"
-   "  part can be either partition number or partition name"
+   "  part can be either partition number or partition name\n"
+   "part number\n"
+   "- set environment variable to the partition number using the 
partition name\n"
+   "  part must be specified as partition name"
 );
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 0/2] Extend 'part' cmd and C API to get part info

[Igor Opaniuk]

This patch-series extends `part` cmd and disk/part C API for getting
partition info by it's name:

1. part "number" sub-command serves for getting the partition index from
partition name. Also it can be used to test the existence of specified
partition.

2. Introduces part_get_info_by_dev_and_name_or_num() function which
allows us to get partition info from its number or name. Partition of
interest is specified by string like "device_num:partition_number" or
"device_num#partition_name".

Initially these patches were a part of
"android: implement A/B boot process" [1] patch-series, but then
due to multiple requests decided to send it separately, while the
work on A/B series is still in progress.


Use case:

For example, in Linaro Lab this U-Boot command for automatic testing
of Linux rootfs is used:

=> setenv bootpart 1:f

where 0xf is "userdata" partition. But the number of "userdata"
partition can be changed any time, when partition table is changed.

So it would be nice to get rid of that 0xf magic number and use
partition name instead, like this:

=> part number mmc 1 userdata part_num
=> setenv bootpart 1:${part_num}


[1] https://patchwork.ozlabs.org/cover/1044152/

Ruslan Trofymenko (2):
  cmd: part: Add 'number' sub-command
  disk: part: Extend API to get partition info

 cmd/part.c | 16 +++-
 disk/part.c| 68 ++
 include/part.h | 21 
 3 files changed, 104 insertions(+), 1 deletion(-)

--
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] board: mediatek: Add pumpkin board support

[Ryder Lee]

On Fri, 2019-06-14 at 14:16 +0200, Fabien Parent wrote:
> +u-boot@lists.denx.de
> 
> On Fri, Jun 14, 2019 at 2:14 PM Fabien Parent  wrote:
> >
> > The pumpkin board is made by Gossamer Engineering and is using
> > a MediaTek SoC. The board currently comes in two available version:
> > MT8516 SoC and MT8167 SoC.
> > The board provides the following IOs: eMMC, NAND, SD card, USB type-A,
> > Ethernet, Wi-Fi, Bluetooth, Audio (jack out, 2 PDM port, 1 analog in),
> > serial over USB, and an expansion header.
> >
> > Additionally there is a HDMI port, DSI port, and camera port only
> > on the MT8167 version of the board.
> >
> > The board can be powered by battery and/or via a USB Type-C port and
> > is using a PMIC MT6392.
> >
> > The eMMC and NAND are sharing pins and cannot be used together.
> >
> > This commit is adding the basic boot support for the Pumpkin MT8516
> > board on the eMMC.
> >
> > Signed-off-by: Fabien Parent 
> > ---
> >
> > V2:
> > * Set MTK_BROM_HEADER_INFO to 'emmc' since we only support eMMC 
> > right now.
> >
> > ---
> >  arch/arm/dts/Makefile  |   3 +-
> >  arch/arm/dts/mt8516-pumpkin.dts| 110 +
> >  arch/arm/mach-mediatek/Kconfig |   1 +
> >  board/mediatek/pumpkin/Kconfig |  13 
> >  board/mediatek/pumpkin/MAINTAINERS |   6 ++
> >  board/mediatek/pumpkin/Makefile|   3 +
> >  board/mediatek/pumpkin/pumpkin.c   |  14 
> >  configs/pumpkin_defconfig  |  64 +
> >  include/configs/pumpkin.h  |  58 +++
> >  9 files changed, 271 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/mt8516-pumpkin.dts
> >  create mode 100644 board/mediatek/pumpkin/Kconfig
> >  create mode 100644 board/mediatek/pumpkin/MAINTAINERS
> >  create mode 100644 board/mediatek/pumpkin/Makefile
> >  create mode 100644 board/mediatek/pumpkin/pumpkin.c
> >  create mode 100644 configs/pumpkin_defconfig
> >  create mode 100644 include/configs/pumpkin.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 528fb909d5..1f66172530 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -766,7 +766,8 @@ dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb 
> > k3-am654-r5-base-board.dtb
> >
> >  dtb-$(CONFIG_ARCH_MEDIATEK) += \
> > mt7623n-bananapi-bpi-r2.dtb \
> > -   mt7629-rfb.dtb
> > +   mt7629-rfb.dtb \
> > +   mt8516-pumpkin.dtb
> >
> >  dtb-$(CONFIG_TARGET_GE_BX50V3) += imx6q-bx50v3.dtb
> >  dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
> > diff --git a/arch/arm/dts/mt8516-pumpkin.dts 
> > b/arch/arm/dts/mt8516-pumpkin.dts
> > new file mode 100644
> > index 00..cd43c1f5e3
> > --- /dev/null
> > +++ b/arch/arm/dts/mt8516-pumpkin.dts
> > @@ -0,0 +1,110 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > +/*
> > + * Copyright (C) 2019 BayLibre SAS.
> > + * Author: Fabien Parent 
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include 
> > +#include "mt8516.dtsi"
> > +
> > +/ {
> > +   model = "Pumpkin MT8516";
> > +
> > +   chosen {
> > +   stdout-path = &uart0;
> > +   };
> > +
> > +   memory@4000 {
> > +   device_type = "memory";
> > +   reg = <0x4000 0x2000>;
> > +   };
> > +
> > +   reserved-memory {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   /* 128 KiB reserved for ARM Trusted Firmware (BL31) */
> > +   bl31_secmon_reserved: secmon@4300 {
> > +   no-map;
> > +   reg = <0 0x4300 0 0x2>;
> > +   };
> > +   };
> > +
> > +   reg_1p8v: regulator-1p8v {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "fixed-1.8V";
> > +   regulator-min-microvolt = <180>;
> > +   regulator-max-microvolt = <180>;
> > +   regulator-boot-on;
> > +   regulator-always-on;
> > +   };
> > +
> > +   reg_3p3v: regulator-3p3v {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "fixed-3.3V";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-boot-on;
> > +   regulator-always-on;
> > +   };
> > +};
> > +
> > +&mmc0 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&mmc0_pins_default>;
> > +   bus-width = <4>;
> > +   max-frequency = <2>;
> > +   cap-mmc-highspeed;
> > +   mmc-hs200-1_8v;
> > +   cap-mmc-hw-reset;
> > +   vmmc-supply = <®_3p3v>;
> > +   vqmmc-supply = <®_1p8v>;
> > +   non-removable;
> > +   status = "okay";
> > +};
> > +
> > +&pinctrl {
> > +   mmc0_pins_default: mmc0default {
> > +   mux {
> > +   function = "msdc";
> > +   groups =  "msdc0";
> > +   };

Re: [U-Boot] [PATCH v3 2/3] fastboot: getvar: Refactor fastboot_*_get_part_info() usage

[Sam Protsenko]

Hi Eugeniu,

On Fri, Jun 14, 2019 at 11:42 AM Eugeniu Rosca  wrote:
>
> On Thu, Jun 13, 2019 at 09:11:08PM +0300, Sam Protsenko wrote:
> [..]
> > + * Get partition number and size for any storage type.
> [..]
> > + * @return Partition number or negative value on error
> [..]
>
> I think the word 'number' should be blacklisted in the vocabulary
> of software development. It can be aliased with 'count' or 'index'
> depending on context.
>

Although I understand the possible confusion between "index"/"count"
meaning for "number" term, in this particular case I don't agree that
this should be changed to "index" (in this patch at least). Yes, we
shouldn't abuse this term (as any other term, for that matter), but I
guess "partition number" is established expression, which means
"partition index", and everybody understands that:

$ grep -Ir 'partition number' | wc -l
46

$ grep -Ir 'partition index' | wc -l
2

Similar result can be achieved when grepping in Linux kernel source
tree. Also you can see this expression used in other places, like:

$ man fdisk | grep 'partition number'
   The partition is a device name followed by a partition number.

All that said, I agree with comment on [1], where "number" can be
really confusing.

So I hope you don't mind if we leave this as is in this patch?

Thanks!

> [1] https://marc.info/?l=linux-kernel&m=132388598809954&w=2
> [2] https://patchwork.ozlabs.org/patch/1044151/#2108815
>
> --
> Best Regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] wandboard: Add mmc0 alias

[Fabio Estevam]

Hi Peter,

On Wed, Jun 12, 2019 at 12:42 PM Peter Robinson  wrote:
>
> On Wed, Jun 12, 2019 at 4:38 PM Fabio Estevam  wrote:
> >
> > Add a mmc0 alias so that U-Boot proper can associate mmc0
> > with the boot SD card.
>
> Shouldn't this go in a -u-boot.dtsi if it's diverging from the linux dtsi?

I have also originally thought about doing this, but then decided to
put it in the main dtsi as I plan to submit a patch adding the mmc
alias for the upstream dtsi in the kernel.

Thanks for the feedback.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] board: mediatek: Add pumpkin board support

[Fabien Parent]

+u-boot@lists.denx.de

On Fri, Jun 14, 2019 at 2:14 PM Fabien Parent  wrote:
>
> The pumpkin board is made by Gossamer Engineering and is using
> a MediaTek SoC. The board currently comes in two available version:
> MT8516 SoC and MT8167 SoC.
> The board provides the following IOs: eMMC, NAND, SD card, USB type-A,
> Ethernet, Wi-Fi, Bluetooth, Audio (jack out, 2 PDM port, 1 analog in),
> serial over USB, and an expansion header.
>
> Additionally there is a HDMI port, DSI port, and camera port only
> on the MT8167 version of the board.
>
> The board can be powered by battery and/or via a USB Type-C port and
> is using a PMIC MT6392.
>
> The eMMC and NAND are sharing pins and cannot be used together.
>
> This commit is adding the basic boot support for the Pumpkin MT8516
> board on the eMMC.
>
> Signed-off-by: Fabien Parent 
> ---
>
> V2:
> * Set MTK_BROM_HEADER_INFO to 'emmc' since we only support eMMC right 
> now.
>
> ---
>  arch/arm/dts/Makefile  |   3 +-
>  arch/arm/dts/mt8516-pumpkin.dts| 110 +
>  arch/arm/mach-mediatek/Kconfig |   1 +
>  board/mediatek/pumpkin/Kconfig |  13 
>  board/mediatek/pumpkin/MAINTAINERS |   6 ++
>  board/mediatek/pumpkin/Makefile|   3 +
>  board/mediatek/pumpkin/pumpkin.c   |  14 
>  configs/pumpkin_defconfig  |  64 +
>  include/configs/pumpkin.h  |  58 +++
>  9 files changed, 271 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/mt8516-pumpkin.dts
>  create mode 100644 board/mediatek/pumpkin/Kconfig
>  create mode 100644 board/mediatek/pumpkin/MAINTAINERS
>  create mode 100644 board/mediatek/pumpkin/Makefile
>  create mode 100644 board/mediatek/pumpkin/pumpkin.c
>  create mode 100644 configs/pumpkin_defconfig
>  create mode 100644 include/configs/pumpkin.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 528fb909d5..1f66172530 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -766,7 +766,8 @@ dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb 
> k3-am654-r5-base-board.dtb
>
>  dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt7623n-bananapi-bpi-r2.dtb \
> -   mt7629-rfb.dtb
> +   mt7629-rfb.dtb \
> +   mt8516-pumpkin.dtb
>
>  dtb-$(CONFIG_TARGET_GE_BX50V3) += imx6q-bx50v3.dtb
>  dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
> diff --git a/arch/arm/dts/mt8516-pumpkin.dts b/arch/arm/dts/mt8516-pumpkin.dts
> new file mode 100644
> index 00..cd43c1f5e3
> --- /dev/null
> +++ b/arch/arm/dts/mt8516-pumpkin.dts
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2019 BayLibre SAS.
> + * Author: Fabien Parent 
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include "mt8516.dtsi"
> +
> +/ {
> +   model = "Pumpkin MT8516";
> +
> +   chosen {
> +   stdout-path = &uart0;
> +   };
> +
> +   memory@4000 {
> +   device_type = "memory";
> +   reg = <0x4000 0x2000>;
> +   };
> +
> +   reserved-memory {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   /* 128 KiB reserved for ARM Trusted Firmware (BL31) */
> +   bl31_secmon_reserved: secmon@4300 {
> +   no-map;
> +   reg = <0 0x4300 0 0x2>;
> +   };
> +   };
> +
> +   reg_1p8v: regulator-1p8v {
> +   compatible = "regulator-fixed";
> +   regulator-name = "fixed-1.8V";
> +   regulator-min-microvolt = <180>;
> +   regulator-max-microvolt = <180>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +
> +   reg_3p3v: regulator-3p3v {
> +   compatible = "regulator-fixed";
> +   regulator-name = "fixed-3.3V";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-boot-on;
> +   regulator-always-on;
> +   };
> +};
> +
> +&mmc0 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&mmc0_pins_default>;
> +   bus-width = <4>;
> +   max-frequency = <2>;
> +   cap-mmc-highspeed;
> +   mmc-hs200-1_8v;
> +   cap-mmc-hw-reset;
> +   vmmc-supply = <®_3p3v>;
> +   vqmmc-supply = <®_1p8v>;
> +   non-removable;
> +   status = "okay";
> +};
> +
> +&pinctrl {
> +   mmc0_pins_default: mmc0default {
> +   mux {
> +   function = "msdc";
> +   groups =  "msdc0";
> +   };
> +
> +   conf-cmd-data {
> +   pins = "MSDC0_CMD", "MSDC0_DAT0", "MSDC0_DAT1",
> +  "MSDC0_DAT2", "MSDC0_DAT3", "MSDC0_DAT4",
> +  "MSDC0_DAT5", "MSDC0_DAT6", "MSDC0_DAT7";
> +   input-enable;
> +   bias-pull-up;
> 

Re: [U-Boot] [PATCH v2 1/5] DTS: imx28: Copy imx28 device tree related files from Linux kernel (v5.1.2)

[Lukasz Majewski]

On Fri, 14 Jun 2019 12:49:10 +0200
Marek Vasut  wrote:

> On 6/14/19 12:41 PM, Lukasz Majewski wrote:
> > Hi Marek,
> >   
> >> On 6/14/19 8:49 AM, Lukasz Majewski wrote:  
> >>> This commit copies from the Linux kernel (tag v5.1.2) i.MX28
> >>> related device tree files.
> >>> 
> >>
> >> Linux 5.1.9 is already out,   
> > 
> > I will check if there are any differences and update.
> >   
> >> commit hash is missing.
> >> Shouldn't the tags be something like "ARM: dts: imx" ? Fix the tags
> >> globally.  
> > 
> > With those tags it is indeed interesting.
> > 
> > As fair as I know those are used by patman to indicate automatically
> > the receiver(s).
> > 
> > One can see them defined in ./doc/git-mailrc
> > 
> > And we now have "dts" - which is not defined there, but shows the
> > "purpose/target" subsystem.
> > 
> > The "arm" causes sending mail to u-boot, Tom and Albert.
> > The "imx" to uboot and Stefano.
> > 
> > This might be important if I did not used Series-cc: and Series-to:
> > from patman (which I did).
> > 
> > 
> > I would appreciate if there were any guidelines to use those tags
> > (there aren't any for Linux though, just there is an Maintainer's
> > "convention").
> > 
> > By "convention" I mean a sorting rule in Maintainer's mail program
> > set arbitrarily to filter out not eligible patches :-)  
> 
> The general agreement was to stick with the linux tags, and that's
> what git log --oneline arch/arm/dts would indicate as well. Maybe
> patman needs to be fixed to stop inventing weird tags.
> 

Simon, do you have any thoughts regarding patman's tag policy (after
the time that we do use patman) ?


Best regards,

Lukasz Majewski

--

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


pgpj4R36d96dB.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] usb: dwc2: correctly handle binding for g-tx-fifo-size

[Patrick Delaunay]

Manage g-tx-fifo-size as a array as specify in the binding.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |  4 
 drivers/usb/gadget/dwc2_udc_otg.c| 17 -
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
index 5b19e44..994092a 100644
--- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
@@ -56,10 +56,6 @@
};
 };
 
-&usbotg_hs {
-   g-tx-fifo-size = <576>;
-};
-
 &v3v3 {
regulator-always-on;
 };
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index 494ab53..7e6b5fc 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -1039,6 +1039,8 @@ static int dwc2_udc_otg_ofdata_to_platdata(struct udevice 
*dev)
int node = dev_of_offset(dev);
ulong drvdata;
void (*set_params)(struct dwc2_plat_otg_data *data);
+   u32 tx_fifo_sz_array[DWC2_MAX_HW_ENDPOINTS];
+   int ret, i;
 
if (usb_get_dr_mode(node) != USB_DR_MODE_PERIPHERAL) {
dev_dbg(dev, "Invalid mode\n");
@@ -1050,7 +1052,20 @@ static int dwc2_udc_otg_ofdata_to_platdata(struct 
udevice *dev)
platdata->rx_fifo_sz = dev_read_u32_default(dev, "g-rx-fifo-size", 0);
platdata->np_tx_fifo_sz = dev_read_u32_default(dev,
   "g-np-tx-fifo-size", 0);
-   platdata->tx_fifo_sz = dev_read_u32_default(dev, "g-tx-fifo-size", 0);
+
+   platdata->tx_fifo_sz_nb =
+   dev_read_size(dev, "g-tx-fifo-size") / sizeof(u32);
+   if (platdata->tx_fifo_sz_nb > DWC2_MAX_HW_ENDPOINTS)
+   platdata->tx_fifo_sz_nb = DWC2_MAX_HW_ENDPOINTS;
+   if (platdata->tx_fifo_sz_nb) {
+   ret = dev_read_u32_array(dev, "g-tx-fifo-size",
+tx_fifo_sz_array,
+platdata->tx_fifo_sz_nb);
+   if (ret)
+   return ret;
+   for (i = 0; i < platdata->tx_fifo_sz_nb; i++)
+   platdata->tx_fifo_sz_array[i] = tx_fifo_sz_array[i];
+   }
 
platdata->force_b_session_valid =
dev_read_bool(dev, "u-boot,force-b-session-valid");
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] usb: dwc2: allow peripheral mode for OTG configuration

[Patrick Delaunay]

Allow device mode in DWC2 driver when device tree select the dr_mode
"peripheral" or "otg".

The device mode is not allowed when dr_mode = "host" in device tree.

Signed-off-by: Patrick Delaunay 
---

 drivers/usb/gadget/dwc2_udc_otg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index 7e6b5fc..895f8c9 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -1042,7 +1042,8 @@ static int dwc2_udc_otg_ofdata_to_platdata(struct udevice 
*dev)
u32 tx_fifo_sz_array[DWC2_MAX_HW_ENDPOINTS];
int ret, i;
 
-   if (usb_get_dr_mode(node) != USB_DR_MODE_PERIPHERAL) {
+   if (usb_get_dr_mode(node) != USB_DR_MODE_PERIPHERAL &&
+   usb_get_dr_mode(node) != USB_DR_MODE_OTG) {
dev_dbg(dev, "Invalid mode\n");
return -ENODEV;
}
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] env: Move CONFIG_ENV_UBI_VOLUME_REDUND in Kconfig

[Patrick Delaunay]

Add support of CONFIG_ENV_UBI_VOLUME_REDUND in Kconfig
as it is already done for CONFIG_ENV_UBI_VOLUME.

As this string is optional, the patch introduces the new boolean
option CONFIG_USE_ENV_UBI_VOLUME_REDUND to activate the feature.

Only the stm32mp1 board is impacted.

Signed-off-by: Patrick Delaunay 
---

 configs/stm32mp15_basic_defconfig   |  2 ++
 configs/stm32mp15_trusted_defconfig |  2 ++
 env/Kconfig | 11 +++
 include/configs/stm32mp1.h  |  4 
 4 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index 4aa184f..f4b42eb 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -52,6 +52,8 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto"
 CONFIG_ENV_EXT4_FILE="/uboot.env"
 CONFIG_ENV_UBI_PART="UBI"
 CONFIG_ENV_UBI_VOLUME="uboot_config"
+CONFIG_USE_ENV_UBI_VOLUME_REDUND=y
+CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
 CONFIG_STM32_ADC=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0xC000
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 66361c8..91b450c 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -44,6 +44,8 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:auto"
 CONFIG_ENV_EXT4_FILE="/uboot.env"
 CONFIG_ENV_UBI_PART="UBI"
 CONFIG_ENV_UBI_VOLUME="uboot_config"
+CONFIG_USE_ENV_UBI_VOLUME_REDUND=y
+CONFIG_ENV_UBI_VOLUME_REDUND="uboot_config_r"
 CONFIG_STM32_ADC=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0xC000
diff --git a/env/Kconfig b/env/Kconfig
index 5651685..676d6eb 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -507,6 +507,17 @@ config ENV_UBI_VOLUME
help
  Name of the volume that you want to store the environment in.
 
+config USE_ENV_UBI_VOLUME_REDUND
+   bool "Enable redunbant UBI volume"
+   depends on ENV_IS_IN_UBI
+
+config ENV_UBI_VOLUME_REDUND
+   string "UBI volume name, second copy"
+   depends on USE_ENV_UBI_VOLUME_REDUND
+   help
+ Name of the second volume that you want to store the redundant
+ environment in.
+
 endif
 
 config USE_DEFAULT_ENV_FILE
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 1d385e0..0ce2fcb 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -38,10 +38,6 @@
  */
 #define CONFIG_SYS_LOAD_ADDR   STM32_DDR_BASE
 
-#if defined(CONFIG_ENV_IS_IN_UBI)
-#define CONFIG_ENV_UBI_VOLUME_REDUND   "uboot_config_r"
-#endif
-
 #if defined(CONFIG_ENV_IS_IN_SPI_FLASH)
 #defineCONFIG_ENV_SECT_SIZESZ_256K
 #defineCONFIG_ENV_OFFSET   0x0028
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/2] stm32mp1: move CONFIG_ENV in Kconfig

[Patrick Delaunay]

Hi,

This serie moves the remaining CONFIG_ENV_ flags
for the the stm32m1 arch or board in Kconfig.

No impact for other target, checked by
tools/buildman/buildman -D  rockchip sunxi zynq versal arc stm32mp



Patrick Delaunay (2):
  env: Move CONFIG_ENV_UBI_VOLUME_REDUND in Kconfig
  stm32mp1: move CONFIG_ENV in Kconfig

 board/st/stm32mp1/Kconfig   |  6 ++
 configs/stm32mp15_basic_defconfig   |  2 ++
 configs/stm32mp15_trusted_defconfig |  2 ++
 env/Kconfig | 16 +---
 include/configs/stm32mp1.h  |  9 -
 5 files changed, 23 insertions(+), 12 deletions(-)

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] stm32mp1: move CONFIG_ENV in Kconfig

[Patrick Delaunay]

Move 2 ENV configuration flags in board Kconfig
- CONFIG_ENV_SECT_SIZE
- CONFIG_ENV_OFFSET

Signed-off-by: Patrick Delaunay 
---

 board/st/stm32mp1/Kconfig  | 6 ++
 env/Kconfig| 5 ++---
 include/configs/stm32mp1.h | 5 -
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/st/stm32mp1/Kconfig b/board/st/stm32mp1/Kconfig
index 5ab9415..5f81f94 100644
--- a/board/st/stm32mp1/Kconfig
+++ b/board/st/stm32mp1/Kconfig
@@ -9,4 +9,10 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "stm32mp1"
 
+config ENV_SECT_SIZE
+   default 0x4 if ENV_IS_IN_SPI_FLASH
+
+config ENV_OFFSET
+   default 0x28 if ENV_IS_IN_SPI_FLASH
+
 endif
diff --git a/env/Kconfig b/env/Kconfig
index 676d6eb..e03ec32 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -468,8 +468,7 @@ if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP 
|| ARCH_VERSAL || ARC
 
 config ENV_OFFSET
hex "Environment Offset"
-   depends on !ENV_IS_IN_UBI
-   depends on !ENV_IS_NOWHERE
+   depends on (!ENV_IS_IN_UBI && !ENV_IS_NOWHERE) || ARCH_STM32MP
default 0x3f8000 if ARCH_ROCKCHIP
default 0x88000 if ARCH_SUNXI
default 0xE if ARCH_ZYNQ
@@ -489,7 +488,7 @@ config ENV_SIZE
 
 config ENV_SECT_SIZE
hex "Environment Sector-Size"
-   depends on !ENV_IS_NOWHERE && (ARCH_ZYNQ || ARCH_ZYNQMP)
+   depends on (!ENV_IS_NOWHERE && (ARCH_ZYNQ || ARCH_ZYNQMP)) || 
ARCH_STM32MP
default 0x4 if ARCH_ZYNQMP
default 0x2 if ARCH_ZYNQ
help
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 0ce2fcb..637f9bf 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -38,11 +38,6 @@
  */
 #define CONFIG_SYS_LOAD_ADDR   STM32_DDR_BASE
 
-#if defined(CONFIG_ENV_IS_IN_SPI_FLASH)
-#defineCONFIG_ENV_SECT_SIZESZ_256K
-#defineCONFIG_ENV_OFFSET   0x0028
-#endif
-
 /* ATAGs */
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] DTS: imx28: Copy imx28 device tree related files from Linux kernel (v5.1.2)

[Marek Vasut]

On 6/14/19 12:41 PM, Lukasz Majewski wrote:
> Hi Marek,
> 
>> On 6/14/19 8:49 AM, Lukasz Majewski wrote:
>>> This commit copies from the Linux kernel (tag v5.1.2) i.MX28
>>> related device tree files.
>>>   
>>
>> Linux 5.1.9 is already out, 
> 
> I will check if there are any differences and update.
> 
>> commit hash is missing.
>> Shouldn't the tags be something like "ARM: dts: imx" ? Fix the tags
>> globally.
> 
> With those tags it is indeed interesting.
> 
> As fair as I know those are used by patman to indicate automatically
> the receiver(s).
> 
> One can see them defined in ./doc/git-mailrc
> 
> And we now have "dts" - which is not defined there, but shows the
> "purpose/target" subsystem.
> 
> The "arm" causes sending mail to u-boot, Tom and Albert.
> The "imx" to uboot and Stefano.
> 
> This might be important if I did not used Series-cc: and Series-to:
> from patman (which I did).
> 
> 
> I would appreciate if there were any guidelines to use those tags
> (there aren't any for Linux though, just there is an Maintainer's
> "convention").
> 
> By "convention" I mean a sorting rule in Maintainer's mail program set
> arbitrarily to filter out not eligible patches :-)

The general agreement was to stick with the linux tags, and that's what
git log --oneline arch/arm/dts would indicate as well. Maybe patman
needs to be fixed to stop inventing weird tags.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] DTS: imx28: Copy imx28 device tree related files from Linux kernel (v5.1.2)

[Lukasz Majewski]

Hi Marek,

> On 6/14/19 8:49 AM, Lukasz Majewski wrote:
> > This commit copies from the Linux kernel (tag v5.1.2) i.MX28
> > related device tree files.
> >   
> 
> Linux 5.1.9 is already out, 

I will check if there are any differences and update.

> commit hash is missing.
> Shouldn't the tags be something like "ARM: dts: imx" ? Fix the tags
> globally.

With those tags it is indeed interesting.

As fair as I know those are used by patman to indicate automatically
the receiver(s).

One can see them defined in ./doc/git-mailrc

And we now have "dts" - which is not defined there, but shows the
"purpose/target" subsystem.

The "arm" causes sending mail to u-boot, Tom and Albert.
The "imx" to uboot and Stefano.

This might be important if I did not used Series-cc: and Series-to:
from patman (which I did).


I would appreciate if there were any guidelines to use those tags
(there aren't any for Linux though, just there is an Maintainer's
"convention").

By "convention" I mean a sorting rule in Maintainer's mail program set
arbitrarily to filter out not eligible patches :-)

> 




Best regards,

Lukasz Majewski

--

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


pgpTA_LPQEBT9.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/2] mmc: sdhci: Read sdhci card detect properties from DT

[Faiz Abbas]

Hi,

On 07/06/19 2:05 PM, Michal Simek wrote:
> From: T Karthik Reddy 
> 
> This patch reads card detect properties from device tree.
> 
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
> 
>  drivers/mmc/sdhci.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 67ca324c9320..a451ccbdf014 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -591,7 +591,22 @@ static int sdhci_set_ios(struct mmc *mmc)
>  static int sdhci_init(struct mmc *mmc)
>  {
>   struct sdhci_host *host = mmc->priv;
> +#if CONFIG_IS_ENABLED(DM_MMC)
> + struct udevice *dev = mmc->dev;
>  
> + if (dev_read_bool(dev, "non-removable")) {
> + host->host_caps |= MMC_CAP_NONREMOVABLE;
> + } else {
> + if (dev_read_bool(dev, "cd-inverted"))
> + host->host_caps |= MMC_CAP_CD_ACTIVE_HIGH;
> + if (dev_read_bool(dev, "broken-cd"))
> + host->host_caps |= MMC_CAP_NEEDS_POLL;
> +#if CONFIG_IS_ENABLED(DM_GPIO)
> + gpio_request_by_name(dev, "cd-gpio", 0,
> +  &host->cd_gpio, GPIOD_IS_IN);
> +#endif
> + }
> +#endif

All of the above properties are not related to SDHCI. They need to go in
generic mmc host code. Add them to mmc_of_parse()

Thanks,
Faiz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] DTS: imx28: Copy imx28 device tree related files from Linux kernel (v5.1.2)

[Marek Vasut]

On 6/14/19 8:49 AM, Lukasz Majewski wrote:
> This commit copies from the Linux kernel (tag v5.1.2) i.MX28 related device
> tree files.
> 

Linux 5.1.9 is already out, commit hash is missing.
Shouldn't the tags be something like "ARM: dts: imx" ? Fix the tags
globally.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rtl8169: use dm_pci_map_bar

[Thierry Reding]

On Fri, Jun 14, 2019 at 01:16:32AM +0200, Patrick Wildt wrote:
> On Thu, Jun 13, 2019 at 06:43:25PM +0200, Thierry Reding wrote:
> > On Thu, Jun 13, 2019 at 03:16:10PM +0800, Bin Meng wrote:
> > > Hi Stefan,
> > > 
> > > On Thu, Jun 13, 2019 at 1:40 PM Stefan Roese  wrote:
> > > >
> > > > Added Bin, Joe and Thierry to Cc
> > > >
> > > > On 11.06.19 13:15, Patrick Wildt wrote:
> > > > > Hi,
> > > > >
> > > > > I have an rtl8169 on a macchiatobin and that card has a 64-bit
> > > > > memory address.  The current code only reads a single word, which
> > > > > means it can only support a 32-bit address.  By using dm_pci_map_bar
> > > > > we don't need to manually parse the register, we can just have it do
> > > > > its job.
> > > > >
> > > > > I'm not sure though if this works for all devices since the previous
> > > > > version had an explicit check for the device.
> > > > >
> > > > > Patrick
> > > > >
> > > > > Signed-off-by: Patrick Wildt 
> > > > >
> > > > > diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
> > > > > index 521e5909a2..f1d2ade253 100644
> > > > > --- a/drivers/net/rtl8169.c
> > > > > +++ b/drivers/net/rtl8169.c
> > > > > @@ -1182,22 +1182,11 @@ static int rtl8169_eth_probe(struct udevice 
> > > > > *dev)
> > > > >   struct pci_child_platdata *pplat = dev_get_parent_platdata(dev);
> > > > >   struct rtl8169_private *priv = dev_get_priv(dev);
> > > > >   struct eth_pdata *plat = dev_get_platdata(dev);
> > > > > - u32 iobase;
> > > > > - int region;
> > > > >   int ret;
> > > > >
> > > > > - debug("rtl8169: REALTEK RTL8169 @0x%x\n", iobase);
> > > > > - switch (pplat->device) {
> > > > > - case 0x8168:
> > > > > - region = 2;
> > > > > - break;
> > > > > - default:
> > > > > - region = 1;
> > > > > - break;
> > > > > - }
> > > > > - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0 + region * 4, 
> > > > > &iobase);
> > > > > - iobase &= ~0xf;
> > > > > - priv->iobase = (int)dm_pci_mem_to_phys(dev, iobase);
> > > > > + priv->iobase = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_2,
> > > > > +   PCI_REGION_MEM);
> > > > > + printf("rtl8169: REALTEK RTL8169 @0x%x\n", priv->iobase);
> > > > >
> > > > >   ret = rtl_init(priv->iobase, dev->name, plat->enetaddr);
> > > > >   if (ret < 0) {
> > > >
> > > > Bin, Joe, Thierry,
> > > >
> > > > do you have any comments on this patch? Moving unconditionally to one
> > > > BAR instead of BAR1/2 depending on the chip version seems a bit
> > > > "brave".
> > > 
> > > Agreed that blinding setting one BAR for the iobase is not a good idea.
> > 
> > Agreed. I don't know whether it's actually required to differentiate
> > based on version, but I suppose the code is like that for a reason, so
> > better keep that.
> > 
> > Also, looking at dm_pci_map_bar() it doesn't look like that does
> > anything different than the existing code. It merely reads a single
> > 32-bit register, so it doesn't properly deal with 64-bit BARs either.
> > 
> > I suppose that could be fixed in dm_pci_map_bar(), and then the fix
> > would automatically propagate to all users of that, which is good. But I
> > don't think it currently works correctly.
> > 
> > Thierry
> 
> Oh, I'm very sorry to have wasted your time.  Yes, I agree, the
> differentiation must come back.
> 
> To be honest it was about half a year ago, so I think I forgot the
> actual issue.  Maybe dm_pci_mem_to_phys() returned 0 for whatever
> reason, but I don't remember.  The address is 32-bit, 0xf600,
> so it definitely wasn't the 64-bit think I rambled about.  Sorry.
> 
> I will try to find out what was wrong and report back.
> 
> By the way, the debug() line in the current code prints iobase which at
> that time isn't even initialized.

Yeah, that's definitely a bug. I think that warrants a separate patch.
Mind sending out a patch with just that change?

Thierry


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/3] i.MX6: nand: add nandbcb command for imx

[Igor Opaniuk]

Hi Shyam,

On Fri, Jun 14, 2019 at 10:37 AM Shyam Saini
 wrote:
>
> Writing/updating boot image in nand device is not
> straight forward in i.MX6 platform and it requires
> boot control block(BCB) to be configured.
>
> It becomes difficult to use uboot 'nand' command to
> write BCB since it requires platform specific attributes
> need to be taken care of.
>
> It is even difficult to use existing msx-nand.c driver by
> incorporating BCB attributes like mxs_dma_desc does
> because it requires change in mtd and nand command.
>
> So, cmd_nandbcb implemented in arch/arm/mach-imx
>
> BCB contains two data structures, Firmware Configuration Block(FCB)
> and Discovered Bad Block Table(DBBT). FCB has nand timings,
> DBBT search area, page address of firmware.
>
> On summary, nandbcb update will
> - erase the entire partition
> - create BCB by creating 2 FCB/DBBT block followed by
>   1 FW block based on partition size and erasesize.
> - fill FCB/DBBT structures
> - write FW/SPL on FW1
> - write FCB/DBBT in first 2 blocks
>
> for nand boot, up on reset bootrom look for FCB structure in
> first block's if FCB found the nand timings are loaded for
> further reads. once FCB read done, DTTB will load and finally
> firmware will be loaded which is boot image.
>
> Refer section "NAND Boot" from doc/imx/common/imx6.txt for more usage
> information.
>
> Reviewed-by: Stefano Babic 
> Signed-off-by: Jagan Teki 
> Signed-off-by: Sergey Kubushyn 
> Signed-off-by: Shyam Saini 
> ---
> Changes for v6:
> - Consolidate v5 patch 1 and patch 2 into one single patch
> - Make separate docs patch out of v5 patch 1
>
> Changes for v5:
> - Move mxs_nand.h file from drivers/mtd/nand/raw/ to include/ directory so
>   that it can be used by both drivers/ and arch/
> - Fix command steps output in docs
>
> Changes for v4:
> - Remove obselete apis and use bch_geometry structure for calculating
>   ecc level, bad block start bit and bad block byte
> - Write firmware only once
> - Shorten variable names
> - Update commit message
> - Update docs as per current patch
> - Fix checkpatch warnings
>
> Changes for v3:
> - Fixed multi-line comments
> - Better error handling for failed allocations
>
> Changes for v2:
> - Fixed commit message notes
> - Updated proper commit message
> - Update doc/README.imx6 with NAND boot details
> - Fixed long length variable names.
> - Fixed Gigantic variable name.
> - NULL checks for kzalloc
> - Move Kconfig option in separate patch
> - Fixed checkpatch warninigs
>
>  arch/arm/include/asm/mach-imx/imx-nandbcb.h  | 111 
>  arch/arm/mach-imx/Kconfig|  11 +
>  arch/arm/mach-imx/Makefile   |   1 +
>  arch/arm/mach-imx/cmd_nandbcb.c  | 369 
> +++
>  drivers/mtd/nand/raw/mxs_nand.c  |   2 +-
>  drivers/mtd/nand/raw/mxs_nand_dt.c   |   2 +-
>  drivers/mtd/nand/raw/mxs_nand_spl.c  |   2 +-
>  {drivers/mtd/nand/raw => include}/mxs_nand.h |   0
>  8 files changed, 495 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/include/asm/mach-imx/imx-nandbcb.h
>  create mode 100644 arch/arm/mach-imx/cmd_nandbcb.c
>  rename {drivers/mtd/nand/raw => include}/mxs_nand.h (100%)
>
> diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h 
> b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> new file mode 100644
> index 00..033659a038
> --- /dev/null
> +++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef _IMX_NAND_BCB_H_
> +#define _IMX_NAND_BCB_H_
> +
> +#define FCB_FINGERPRINT0x20424346  /* 'FCB' */
> +#define FCB_VERSION_1  0x0100
> +
> +#define DBBT_FINGERPRINT2  0x54424244  /* 'DBBT' */
> +#define DBBT_VERSION_1 0x0100
> +
> +struct dbbt_block {
> +   u32 checksum;   /* reserved on i.MX6 */
> +   u32 fingerprint;
> +   u32 version;
> +   u32 numberbb;   /* reserved on i.MX6 */
> +   u32 dbbtpages;
> +};
> +
> +struct fcb_block {
> +   u32 checksum;   /* First fingerprint in first byte */
> +   u32 fingerprint;/* 2nd fingerprint at byte 4 */
> +   u32 version;/* 3rd fingerprint at byte 8 */
> +   u8 datasetup;
> +   u8 datahold;
> +   u8 addr_setup;
> +   u8 dsample_time;
> +
> +   /* These are for application use only and not for ROM. */
> +   u8 nandtiming;
> +   u8 rea;
> +   u8 rloh;
> +   u8 rhoh;
> +   u32 pagesize;   /* 2048 for 2K pages, 4096 for 4K pages */
> +   u32 oob_pagesize;   /* 2112 for 2K pages, 4314 for 4K pages */
> +   u32 sectors;/* Number of 2K sections per block */
> +   u32 nr_nand;/* Total Number of NANDs - not used by ROM */
> +   u32 nr_die; /* Number of separate chips in this NAND */
> +   u32 celltype;   /* MLC or SLC */
> +   u32

Re: [U-Boot] [PATCH v3 2/3] fastboot: getvar: Refactor fastboot_*_get_part_info() usage

[Eugeniu Rosca]

On Thu, Jun 13, 2019 at 09:11:08PM +0300, Sam Protsenko wrote:
[..]
> + * Get partition number and size for any storage type.
[..]
> + * @return Partition number or negative value on error
[..]

I think the word 'number' should be blacklisted in the vocabulary
of software development. It can be aliased with 'count' or 'index'
depending on context.

[1] https://marc.info/?l=linux-kernel&m=132388598809954&w=2
[2] https://patchwork.ozlabs.org/patch/1044151/#2108815

-- 
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] doc: imx: Add documentation for nandbcb command

[Lukasz Majewski]

Hi Shyam,

> Signed-off-by: Shyam Saini 
> ---
>  doc/imx/common/imx6.txt | 74
> + 1 file changed, 74
> insertions(+)
> 
> diff --git a/doc/imx/common/imx6.txt b/doc/imx/common/imx6.txt
> index eab88353f6..0b5061128c 100644
> --- a/doc/imx/common/imx6.txt
> +++ b/doc/imx/common/imx6.txt
> @@ -88,3 +88,77 @@ Reading bank 4:
>  
>  Word 0x0002: 9f027772 0004
>  
> +NAND Boot on i.MX6 with SPL support
> +--
> +
> +Writing/updating boot image in nand device is not straight forward in
> +i.MX6 platform and it requires boot control block(BCB) to be
> configured. +
> +BCB contains two data structures, Firmware Configuration Block(FCB)
> and +Discovered Bad Block Table(DBBT). FCB has nand timings, DBBT
> search area, +and firmware. See IMX6DQRM Section 8.5.2.2
> +for more information.
> +
> +We can't use 'nand write' command to write SPL/firmware image
> directly +like other platforms does. So we need special setup to
> write BCB block +as per IMX6QDL reference manual 'nandbcb update'
> command do that job. +
> +for nand boot, up on reset bootrom look for FCB structure in
> +first block's if FCB found the nand timings are loaded for
> +further reads. once FCB read done, DTTB will be loaded and
> +finally firmware will be loaded which is boot image.
> +
> +cmd_nandbcb will create FCB these structures
> +by taking mtd partition as an example.

I think that the above sentence has a wrong order. Could you rewrite it?

> +- initial code will erase entire partition
> +- followed by FCB setup, like first 2 blocks for FCB/DBBT write,
> +  and next block for FW1/SPL
> +- write firmware at FW1 block and
> +- finally write fcb/dttb in first 2 block.
> +
> +Typical NAND BCB layout:
> +===
> +
> +   no.of blocks = partition size / erasesize
> +   no.of fcb/dbbt blocks = 2
> +   FW1 offset = no.of fcb/dbbt
> +
> +block  0  1  2
> +---
> +   |FCB/DBBT 0|FCB/DBBT 1|  FW 1  |
> +   
> +
> +On summary, nandbcb update will
> +- erase the entire partition
> +- create BCB by creating 2 FCB/BDDT block followed by
> +  1 FW blocks based on partition size and erasesize.
> +- fill FCB/DBBT structures
> +- write FW/SPL in FW1
> +- write FCB/DBBT in first 2 blocks
> +
> +step-1: write SPL
> +
> +icorem6qdl> ext4load mmc 0:1 $loadaddr SPL  
> +39936 bytes read in 10 ms (3.8 MiB/s)
> +
> +icorem6qdl> nandbcb update $loadaddr spl $filesize  
> +device 0 offset 0x0, size 0x9c00
> +Erasing at 0x1c -- 100% complete.
> +NAND fw write: 0x8 offset, 0xb000 bytes written: OK
> +
> +step-2: write u-boot-dtb.img
> +
> +icorem6qdl> nand erase.part uboot  
> +
> +NAND erase.part: device 0 offset 0x20, size 0x20
> +Erasing at 0x3c -- 100% complete.
> +OK
> +
> +icorem6qdl> ext4load mmc 0:1 $loadaddr u-boot-dtb.img  
> +589094 bytes read in 37 ms (15.2 MiB/s)
> +
> +icorem6qdl> nand write ${loadaddr} uboot ${filesize}  
> +
> +NAND write: device 0 offset 0x20, size 0x8fd26
> + 589094 bytes written: OK
> +icorem6qdl>  

Would it be possible to provide nandbcb show command (I guess that I
can dump it with plain nand read)?

It would present the FCB/DBBT structure. Do you think it is
needed/feasible ?

Best regards,

Lukasz Majewski

--

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


pgpJvAK0iNXHn.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 02/10] spi: Add Atmel QuadSPI driver

[Tudor.Ambarus]

Hi, Jagan,

On 06/12/2019 11:02 AM, Jagan Teki wrote:
> External E-Mail
> 
> 
> On Wed, May 15, 2019 at 12:33 PM  wrote:
>>
>> From: Tudor Ambarus 
>>
>> Backport the driver from linux v5.1-rc5 and adapt it for u-boot.
>> Tested on sama5d2_xplained Rev B with mx25l25635e spi-nor flash.
>>
>> Signed-off-by: Tudor Ambarus 
>> ---
>> v4: update Kconfig description
>> v3: no change
>> v2: no change
>>
>>  drivers/spi/Kconfig |   8 +
>>  drivers/spi/Makefile|   1 +
>>  drivers/spi/atmel-quadspi.c | 535 
>> 
>>  3 files changed, 544 insertions(+)
>>  create mode 100644 drivers/spi/atmel-quadspi.c
>>

cut

>> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
>> new file mode 100644
>> index ..c54fbe6bc6cf
>> --- /dev/null
>> +++ b/drivers/spi/atmel-quadspi.c
>> @@ -0,0 +1,535 @@

cut

>> +struct atmel_qspi {
>> +   void __iomem *regs;
>> +   void __iomem *mem;
>> +   struct platform_device *pdev;
> 
> Linux copy, please drop this.
> 

will do

>> +static int atmel_qspi_probe(struct udevice *dev)
>> +{
>> +   struct atmel_qspi *aq = dev_get_priv(dev);
>> +   struct resource res;
>> +   int ret;
>> +
>> +   aq->caps = (struct atmel_qspi_caps *)dev_get_driver_data(dev);
>> +   if (!aq->caps) {
>> +   dev_err(dev, "Could not retrieve QSPI caps\n");
>> +   return -EINVAL;
>> +   };
>> +
>> +   /* Map the registers */
>> +   ret = dev_read_resource_byname(dev, "qspi_base", &res);
>> +   if (ret) {
>> +   dev_err(dev, "missing registers\n");
>> +   return ret;
>> +   }
> 
> space

ok

> 
>> +   aq->regs = devm_ioremap(dev, res.start, resource_size(&res));
>> +   if (IS_ERR(aq->regs))
>> +   return PTR_ERR(aq->regs);
>> +
>> +   /* Map the AHB memory */
>> +   ret = dev_read_resource_byname(dev, "qspi_mmap", &res);
>> +   if (ret) {
>> +   dev_err(dev, "missing AHB memory\n");
>> +   return ret;
>> +   }
> 
> space

ok

> 
>> +   aq->mem = devm_ioremap(dev, res.start, resource_size(&res));
>> +   if (IS_ERR(aq->mem))
>> +   return PTR_ERR(aq->mem);
>> +
>> +   ret = atmel_qspi_enable_clk(dev);
>> +   if (ret)
>> +   return ret;
>> +
>> +   atmel_qspi_init(aq);
>> +
>> +   return 0;
>> +}
>> +
>> +static const struct spi_controller_mem_ops atmel_qspi_mem_ops = {
>> +   .supports_op = atmel_qspi_supports_op,
>> +   .exec_op = atmel_qspi_exec_op,
>> +};
>> +
>> +static const struct dm_spi_ops atmel_qspi_ops = {
>> +   .set_speed = atmel_qspi_set_speed,
>> +   .set_mode = atmel_qspi_set_mode,
>> +   .mem_ops = &atmel_qspi_mem_ops,
>> +};
>> +
>> +static const struct atmel_qspi_caps atmel_sama5d2_qspi_caps = {};
>> +
>> +static const struct atmel_qspi_caps atmel_sam9x60_qspi_caps = {
>> +   .has_qspick = true,
>> +   .has_ricr = true,
>> +};
>> +
>> +static const struct udevice_id atmel_qspi_ids[] = {
>> +   {
>> +   .compatible = "atmel,sama5d2-qspi",
>> +   .data = (ulong)&atmel_sama5d2_qspi_caps,
> 
> Better assign NULL

I deliberately added a zeroed caps instance to the sama5d2 entry to not allow
aq->caps to be NULL. This way I avoid redundant checks like:

+   if (aq->caps && aq->caps->has_qspick) {
and
+   if (aq->caps && aq->caps->has_ricr) {


Since this patch is just a backport from the linux driver and does not modify
the code logic, can we keep it as it is, and modify it later on if you have a
strong opinion on this?

Cheers,
ta
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] colibri/apalis tegra: drop DFU support

[Igor Opaniuk]

From: Igor Opaniuk 

We never really added a sensible DFU configuration for platforms
based on eMMC. Most of the things one might want to do can also be done
with UMS or fastboot, so drop the DFU configuration.

Signed-off-by: Igor Opaniuk 
---
 configs/apalis-tk1_defconfig  | 3 ---
 configs/apalis_t30_defconfig  | 3 ---
 configs/colibri_t20_defconfig | 3 ---
 configs/colibri_t30_defconfig | 3 ---
 4 files changed, 12 deletions(-)

diff --git a/configs/apalis-tk1_defconfig b/configs/apalis-tk1_defconfig
index 946858e48e..e62cef713a 100644
--- a/configs/apalis-tk1_defconfig
+++ b/configs/apalis-tk1_defconfig
@@ -17,7 +17,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_TEXT_BASE=0x80108000
 CONFIG_SYS_PROMPT="Apalis TK1 # "
 # CONFIG_CMD_IMI is not set
-CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -32,8 +31,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_OF_LIVE=y
 CONFIG_DEFAULT_DEVICE_TREE="tegra124-apalis"
 CONFIG_SPL_DM=y
-CONFIG_DFU_MMC=y
-CONFIG_DFU_RAM=y
 CONFIG_SYS_I2C_TEGRA=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK=y
diff --git a/configs/apalis_t30_defconfig b/configs/apalis_t30_defconfig
index d231ccdb49..a4af07cfc7 100644
--- a/configs/apalis_t30_defconfig
+++ b/configs/apalis_t30_defconfig
@@ -14,7 +14,6 @@ CONFIG_ARCH_MISC_INIT=y
 CONFIG_SPL_TEXT_BASE=0x80108000
 CONFIG_SYS_PROMPT="Apalis T30 # "
 # CONFIG_CMD_IMI is not set
-CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -29,8 +28,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_OF_LIVE=y
 CONFIG_DEFAULT_DEVICE_TREE="tegra30-apalis"
 CONFIG_SPL_DM=y
-CONFIG_DFU_MMC=y
-CONFIG_DFU_RAM=y
 CONFIG_SYS_I2C_TEGRA=y
 CONFIG_E1000=y
 CONFIG_PCI=y
diff --git a/configs/colibri_t20_defconfig b/configs/colibri_t20_defconfig
index e652ebc5a5..199241000c 100644
--- a/configs/colibri_t20_defconfig
+++ b/configs/colibri_t20_defconfig
@@ -13,7 +13,6 @@ CONFIG_ARCH_MISC_INIT=y
 CONFIG_SPL_TEXT_BASE=0x00108000
 CONFIG_SYS_PROMPT="Colibri T20 # "
 # CONFIG_CMD_IMI is not set
-CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -37,8 +36,6 @@ CONFIG_OF_LIVE=y
 CONFIG_DEFAULT_DEVICE_TREE="tegra20-colibri"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
-CONFIG_DFU_MMC=y
-CONFIG_DFU_RAM=y
 CONFIG_SYS_I2C_TEGRA=y
 CONFIG_MTD=y
 CONFIG_MTD_UBI_FASTMAP=y
diff --git a/configs/colibri_t30_defconfig b/configs/colibri_t30_defconfig
index 99be27823d..f9f337457d 100644
--- a/configs/colibri_t30_defconfig
+++ b/configs/colibri_t30_defconfig
@@ -14,7 +14,6 @@ CONFIG_ARCH_MISC_INIT=y
 CONFIG_SPL_TEXT_BASE=0x80108000
 CONFIG_SYS_PROMPT="Colibri T30 # "
 # CONFIG_CMD_IMI is not set
-CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -28,8 +27,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_OF_LIVE=y
 CONFIG_DEFAULT_DEVICE_TREE="tegra30-colibri"
 CONFIG_SPL_DM=y
-CONFIG_DFU_MMC=y
-CONFIG_DFU_RAM=y
 CONFIG_SYS_I2C_TEGRA=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] colibri/apalis imx: drop DFU support

[Igor Opaniuk]

From: Igor Opaniuk 

We never really added a sensible DFU configuration for platforms
based on eMMC. Most of the things one might want to do can also be done
with UMS or fastboot, so drop the DFU configuration.

Signed-off-by: Igor Opaniuk 
---
 configs/apalis_imx6_defconfig   | 2 --
 configs/colibri-imx6ull_defconfig   | 1 -
 configs/colibri_imx6_defconfig  | 2 --
 configs/colibri_imx7_emmc_defconfig | 2 --
 4 files changed, 7 deletions(-)

diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index bcf7444311..e9995583d3 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -38,7 +38,6 @@ CONFIG_CMD_ASKENV=y
 CONFIG_CRC32_VERIFY=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
-CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
@@ -55,7 +54,6 @@ CONFIG_DEFAULT_DEVICE_TREE="imx6-apalis"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DWC_AHSATA=y
-CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
diff --git a/configs/colibri-imx6ull_defconfig 
b/configs/colibri-imx6ull_defconfig
index 133df9e723..8f09f1b3d6 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -46,7 +46,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6ull-colibri"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-CONFIG_DFU_MMC=y
 CONFIG_DFU_NAND=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 59d4ab0a04..7dbbfe5d76 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -37,7 +37,6 @@ CONFIG_CMD_ASKENV=y
 CONFIG_CRC32_VERIFY=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
-CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
@@ -54,7 +53,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6-colibri"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
diff --git a/configs/colibri_imx7_emmc_defconfig 
b/configs/colibri_imx7_emmc_defconfig
index bb11524794..299c42789e 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -25,7 +25,6 @@ CONFIG_SYS_PROMPT="Colibri iMX7 # "
 CONFIG_CMD_ASKENV=y
 CONFIG_CRC32_VERIFY=y
 CONFIG_CMD_MEMTEST=y
-CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 # CONFIG_RANDOM_UUID is not set
@@ -42,7 +41,6 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-emmc"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_FSL_CAAM=y
-CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/2] colibri/apalis tegra/imx: drop DFU support

[Igor Opaniuk]

From: Igor Opaniuk 

We never really added a sensible DFU configuration for platforms
based on eMMC. Most of the things one might want to do can also be done
with UMS or fastboot, so drop the DFU configuration.

Igor Opaniuk (2):
  colibri/apalis tegra: drop DFU support
  colibri/apalis imx: drop DFU support

 configs/apalis-tk1_defconfig| 3 ---
 configs/apalis_imx6_defconfig   | 2 --
 configs/apalis_t30_defconfig| 3 ---
 configs/colibri-imx6ull_defconfig   | 1 -
 configs/colibri_imx6_defconfig  | 2 --
 configs/colibri_imx7_emmc_defconfig | 2 --
 configs/colibri_t20_defconfig   | 3 ---
 configs/colibri_t30_defconfig   | 3 ---
 8 files changed, 19 deletions(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/3] doc: imx: Add documentation for nandbcb command

[Shyam Saini]

Signed-off-by: Shyam Saini 
---
 doc/imx/common/imx6.txt | 74 +
 1 file changed, 74 insertions(+)

diff --git a/doc/imx/common/imx6.txt b/doc/imx/common/imx6.txt
index eab88353f6..0b5061128c 100644
--- a/doc/imx/common/imx6.txt
+++ b/doc/imx/common/imx6.txt
@@ -88,3 +88,77 @@ Reading bank 4:
 
 Word 0x0002: 9f027772 0004
 
+NAND Boot on i.MX6 with SPL support
+--
+
+Writing/updating boot image in nand device is not straight forward in
+i.MX6 platform and it requires boot control block(BCB) to be configured.
+
+BCB contains two data structures, Firmware Configuration Block(FCB) and
+Discovered Bad Block Table(DBBT). FCB has nand timings, DBBT search area,
+and firmware. See IMX6DQRM Section 8.5.2.2
+for more information.
+
+We can't use 'nand write' command to write SPL/firmware image directly
+like other platforms does. So we need special setup to write BCB block
+as per IMX6QDL reference manual 'nandbcb update' command do that job.
+
+for nand boot, up on reset bootrom look for FCB structure in
+first block's if FCB found the nand timings are loaded for
+further reads. once FCB read done, DTTB will be loaded and
+finally firmware will be loaded which is boot image.
+
+cmd_nandbcb will create FCB these structures
+by taking mtd partition as an example.
+- initial code will erase entire partition
+- followed by FCB setup, like first 2 blocks for FCB/DBBT write,
+  and next block for FW1/SPL
+- write firmware at FW1 block and
+- finally write fcb/dttb in first 2 block.
+
+Typical NAND BCB layout:
+===
+
+   no.of blocks = partition size / erasesize
+   no.of fcb/dbbt blocks = 2
+   FW1 offset = no.of fcb/dbbt
+
+block  0  1  2
+---
+   |FCB/DBBT 0|FCB/DBBT 1|  FW 1  |
+   
+
+On summary, nandbcb update will
+- erase the entire partition
+- create BCB by creating 2 FCB/BDDT block followed by
+  1 FW blocks based on partition size and erasesize.
+- fill FCB/DBBT structures
+- write FW/SPL in FW1
+- write FCB/DBBT in first 2 blocks
+
+step-1: write SPL
+
+icorem6qdl> ext4load mmc 0:1 $loadaddr SPL
+39936 bytes read in 10 ms (3.8 MiB/s)
+
+icorem6qdl> nandbcb update $loadaddr spl $filesize
+device 0 offset 0x0, size 0x9c00
+Erasing at 0x1c -- 100% complete.
+NAND fw write: 0x8 offset, 0xb000 bytes written: OK
+
+step-2: write u-boot-dtb.img
+
+icorem6qdl> nand erase.part uboot
+
+NAND erase.part: device 0 offset 0x20, size 0x20
+Erasing at 0x3c -- 100% complete.
+OK
+
+icorem6qdl> ext4load mmc 0:1 $loadaddr u-boot-dtb.img
+589094 bytes read in 37 ms (15.2 MiB/s)
+
+icorem6qdl> nand write ${loadaddr} uboot ${filesize}
+
+NAND write: device 0 offset 0x20, size 0x8fd26
+ 589094 bytes written: OK
+icorem6qdl>
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/3] configs: icorem6: Enable nandbcb command

[Shyam Saini]

This also enables mtd configs which are required by nandbcb command.

This command would be used to configure boot control block(BCB) while
writing spl image on nand device.

Signed-off-by: Shyam Saini 
---
 configs/imx6qdl_icore_mmc_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/imx6qdl_icore_mmc_defconfig 
b/configs/imx6qdl_icore_mmc_defconfig
index b65979967a..620d49f954 100644
--- a/configs/imx6qdl_icore_mmc_defconfig
+++ b/configs/imx6qdl_icore_mmc_defconfig
@@ -15,6 +15,7 @@ CONFIG_DEBUG_UART_BASE=0x021f
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_SPL_LIBDISK_SUPPORT=y
 # CONFIG_CMD_BMODE is not set
+CONFIG_CMD_NANDBCB=y
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
@@ -58,6 +59,9 @@ CONFIG_SYS_I2C_MXC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXS=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:2m(spl),2m(uboot),1m(env),8m(kernel),1m(dtb),-(rootfs)"
 CONFIG_PHYLIB=y
 CONFIG_PHY_SMSC=y
 CONFIG_FEC_MXC=y
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 1/3] i.MX6: nand: add nandbcb command for imx

[Shyam Saini]

Writing/updating boot image in nand device is not
straight forward in i.MX6 platform and it requires
boot control block(BCB) to be configured.

It becomes difficult to use uboot 'nand' command to
write BCB since it requires platform specific attributes
need to be taken care of.

It is even difficult to use existing msx-nand.c driver by
incorporating BCB attributes like mxs_dma_desc does
because it requires change in mtd and nand command.

So, cmd_nandbcb implemented in arch/arm/mach-imx

BCB contains two data structures, Firmware Configuration Block(FCB)
and Discovered Bad Block Table(DBBT). FCB has nand timings,
DBBT search area, page address of firmware.

On summary, nandbcb update will
- erase the entire partition
- create BCB by creating 2 FCB/DBBT block followed by
  1 FW block based on partition size and erasesize.
- fill FCB/DBBT structures
- write FW/SPL on FW1
- write FCB/DBBT in first 2 blocks

for nand boot, up on reset bootrom look for FCB structure in
first block's if FCB found the nand timings are loaded for
further reads. once FCB read done, DTTB will load and finally
firmware will be loaded which is boot image.

Refer section "NAND Boot" from doc/imx/common/imx6.txt for more usage
information.

Reviewed-by: Stefano Babic 
Signed-off-by: Jagan Teki 
Signed-off-by: Sergey Kubushyn 
Signed-off-by: Shyam Saini 
---
Changes for v6:
- Consolidate v5 patch 1 and patch 2 into one single patch
- Make separate docs patch out of v5 patch 1

Changes for v5:
- Move mxs_nand.h file from drivers/mtd/nand/raw/ to include/ directory so
  that it can be used by both drivers/ and arch/
- Fix command steps output in docs 

Changes for v4:
- Remove obselete apis and use bch_geometry structure for calculating
  ecc level, bad block start bit and bad block byte
- Write firmware only once
- Shorten variable names
- Update commit message
- Update docs as per current patch
- Fix checkpatch warnings

Changes for v3:
- Fixed multi-line comments
- Better error handling for failed allocations

Changes for v2:
- Fixed commit message notes
- Updated proper commit message
- Update doc/README.imx6 with NAND boot details
- Fixed long length variable names.
- Fixed Gigantic variable name.
- NULL checks for kzalloc
- Move Kconfig option in separate patch
- Fixed checkpatch warninigs

 arch/arm/include/asm/mach-imx/imx-nandbcb.h  | 111 
 arch/arm/mach-imx/Kconfig|  11 +
 arch/arm/mach-imx/Makefile   |   1 +
 arch/arm/mach-imx/cmd_nandbcb.c  | 369 +++
 drivers/mtd/nand/raw/mxs_nand.c  |   2 +-
 drivers/mtd/nand/raw/mxs_nand_dt.c   |   2 +-
 drivers/mtd/nand/raw/mxs_nand_spl.c  |   2 +-
 {drivers/mtd/nand/raw => include}/mxs_nand.h |   0
 8 files changed, 495 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/mach-imx/imx-nandbcb.h
 create mode 100644 arch/arm/mach-imx/cmd_nandbcb.c
 rename {drivers/mtd/nand/raw => include}/mxs_nand.h (100%)

diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h 
b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
new file mode 100644
index 00..033659a038
--- /dev/null
+++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _IMX_NAND_BCB_H_
+#define _IMX_NAND_BCB_H_
+
+#define FCB_FINGERPRINT0x20424346  /* 'FCB' */
+#define FCB_VERSION_1  0x0100
+
+#define DBBT_FINGERPRINT2  0x54424244  /* 'DBBT' */
+#define DBBT_VERSION_1 0x0100
+
+struct dbbt_block {
+   u32 checksum;   /* reserved on i.MX6 */
+   u32 fingerprint;
+   u32 version;
+   u32 numberbb;   /* reserved on i.MX6 */
+   u32 dbbtpages;
+};
+
+struct fcb_block {
+   u32 checksum;   /* First fingerprint in first byte */
+   u32 fingerprint;/* 2nd fingerprint at byte 4 */
+   u32 version;/* 3rd fingerprint at byte 8 */
+   u8 datasetup;
+   u8 datahold;
+   u8 addr_setup;
+   u8 dsample_time;
+
+   /* These are for application use only and not for ROM. */
+   u8 nandtiming;
+   u8 rea;
+   u8 rloh;
+   u8 rhoh;
+   u32 pagesize;   /* 2048 for 2K pages, 4096 for 4K pages */
+   u32 oob_pagesize;   /* 2112 for 2K pages, 4314 for 4K pages */
+   u32 sectors;/* Number of 2K sections per block */
+   u32 nr_nand;/* Total Number of NANDs - not used by ROM */
+   u32 nr_die; /* Number of separate chips in this NAND */
+   u32 celltype;   /* MLC or SLC */
+   u32 ecc_type;   /* Type of ECC, can be one of BCH-0-20 */
+   u32 ecc_nr; /* Number of bytes for Block0 - BCH */
+
+   /* Block size in bytes for all blocks other than Block0 - BCH */
+   u32 ecc_size;
+   u32 ecc_level;  /* Ecc level for Block 0 - BCH */
+   u32 meta_size; 

Re: [U-Boot] [PATCH] net: introduce packet capture support

[Ramon Fried]

On Fri, Jun 14, 2019 at 10:12 AM Bin Meng  wrote:

> Hi Ramon,
>
> On Fri, Jun 14, 2019 at 2:18 PM Ramon Fried  wrote:
> >
> > Add support for capturing ethernet packets and storing
> > them in memory in PCAP(2.4) format, later to be analyzed by
> > any PCAP viewer software (IE. Wireshark)
> >
> > This feature greatly assist debugging network issues such
> > as detecting dropped packets, packet corruption etc.
> >
> > Signed-off-by: Ramon Fried 
> > ---
> >
> >  include/net.h | 29 ++
> >  net/Kconfig   | 22 ++
> >  net/Makefile  |  1 +
> >  net/net.c | 11 +++
> >  net/pcap.c| 83 +++
> >  5 files changed, 146 insertions(+)
> >  create mode 100644 net/pcap.c
> >
>
> Nice to have such a feature. But how do we export the PCAP contents in
> RAM to a file and transfer it to host for analysis by WireShark?
> Should we support storing PCAP to a file on a file system in U-Boot?
>
Hi Bin.
When testing the feature under Qemu, I just dumped the memory from qemu.
This is just one option, if networking actually works, you could tftp send
it to the host, or perhaps even write it to block storage.
I only assume (didn't check) that there is a command that can dump memory
to file system.
Thanks,
Ramon.

>
> Regards,
> Bin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/2] mmc: sdhci: Implement SDHCI card detect

[Faiz Abbas]

Hi Michal,

On 07/06/19 2:05 PM, Michal Simek wrote:
> From: T Karthik Reddy 
> 
> Card detect function implemented for SDHCI framework.
> 
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
> 
>  drivers/mmc/sdhci.c | 32 
>  include/sdhci.h |  7 +++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index e2bb90abbdf3..67ca324c9320 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #if defined(CONFIG_FIXED_SDHCI_ALIGNED_BUFFER)
>  void *aligned_buffer = (void *)CONFIG_FIXED_SDHCI_ALIGNED_BUFFER;
> @@ -624,9 +625,40 @@ int sdhci_probe(struct udevice *dev)
>   return sdhci_init(mmc);
>  }
>  
> +int sdhci_get_cd(struct udevice *dev)
> +{
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
> + struct sdhci_host *host = mmc->priv;
> + int value;
> +
> + /* If nonremovable, assume that the card is always present. */
> + if (host->host_caps & MMC_CAP_NONREMOVABLE)
> + return 1;
> + /* If polling, assume that the card is always present. */
> + if (host->host_caps & MMC_CAP_NEEDS_POLL)
> + return 1;
> +
> +#if CONFIG_IS_ENABLED(DM_GPIO)
> + value = dm_gpio_get_value(&host->cd_gpio);
> + if (value >= 0) {
> + if (host->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
> + return !value;
> + else
> + return value;
> + }
> +#endif
> + value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> +SDHCI_CARD_DETECT_PIN_LEVEL);

I think you need to use CARD_PRESENT instead of this. According to the
spec, "This bit may be valid when Card State Stable is set to 1, but it
is not guaranteed because of propagation delay. Use of this bit is
limited to testing since it must be debounced by software."

Thanks,
Faiz


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: introduce packet capture support

[Bin Meng]

Hi Ramon,

On Fri, Jun 14, 2019 at 2:18 PM Ramon Fried  wrote:
>
> Add support for capturing ethernet packets and storing
> them in memory in PCAP(2.4) format, later to be analyzed by
> any PCAP viewer software (IE. Wireshark)
>
> This feature greatly assist debugging network issues such
> as detecting dropped packets, packet corruption etc.
>
> Signed-off-by: Ramon Fried 
> ---
>
>  include/net.h | 29 ++
>  net/Kconfig   | 22 ++
>  net/Makefile  |  1 +
>  net/net.c | 11 +++
>  net/pcap.c| 83 +++
>  5 files changed, 146 insertions(+)
>  create mode 100644 net/pcap.c
>

Nice to have such a feature. But how do we export the PCAP contents in
RAM to a file and transfer it to host for analysis by WireShark?
Should we support storing PCAP to a file on a file system in U-Boot?

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Pull request: u-boot-dfu (14.06.2019) - fixes v2019.07

[Lukasz Majewski]

Dear Marek,

Repo:  git://git.denx.de/u-boot-dfu.git
Branch: master

The following changes since commit
91810aa7fded782deda5de5320dae19876e4a558:

  usb: gadget: error out if g_dnl registration fails (2019-06-09
  17:13:07 +0200)

are available in the git repository at:

  git://git.denx.de/u-boot-dfu.git 

for you to fetch changes up to c8a34b7da03ca36311d35c9bf5ac7b4e8bd59ee0:

  fastboot: Check if partition really exist in getvar_has_slot()
  (2019-06-13 23:34:04 +0200)


Igor Opaniuk (1):
  fastboot: Check if partition really exist in getvar_has_slot()

Sam Protsenko (3):
  fastboot: Fix slot names reported by getvar
  fastboot: Use const qualifier for char *part_name
  fastboot: getvar: Refactor fastboot_*_get_part_info() usage

 drivers/fastboot/fb_getvar.c | 103
 
+++
 drivers/fastboot/fb_mmc.c|   3 ++- drivers/fastboot/fb_nand.c
 |   4 ++-- include/fb_mmc.h |   3 ++-
 include/fb_nand.h|   4 ++--
 5 files changed, 87 insertions(+), 30 deletions(-)





Best regards,

Lukasz Majewski

--

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


pgpqICR38RvYb.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot