[U-Boot] [PATCH 4/4 v2] Makefile: Correct logic for DM_SCSI + unconverted drivers check

[Stefan Roese]

When checking for boards that are enabling a SATA driver that isn't
converted to DM yet we need to be sure to not also trip over boards that
do set CONFIG_AHCI & CONFIG_BLK by itself, as that is not a bug.

This was detected when converting the Armada XP SATA driver sata_mv.c
to DM with AHCI & BLK support. This warning is still printed without
this patch applied here.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Tom Rini 
---
v2:
- Rework checks as suggested by Tom

 Makefile | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 26db4e7b59..4f73d426af 100644
--- a/Makefile
+++ b/Makefile
@@ -938,11 +938,22 @@ ifneq 
($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy)
@echo >&2 ""
 endif
 endif
-ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y)
-ifneq ($(CONFIG_DM_SCSI),y)
+ifeq ($(CONFIG_MVSATA_IDE),y)
@echo >&2 "= WARNING =="
-   @echo >&2 "This board does not use CONFIG_DM_SCSI. Please update"
-   @echo >&2 "the storage controller to use CONFIG_DM_SCSI before the 
v2019.07 release."
+   @echo >&2 "This board does use CONFIG_MVSATA_IDE which is not"
+   @echo >&2 "ported to driver-model (DM) yet. Please update the storage"
+   @echo >&2 "controller driver to use CONFIG_AHCI before the v2019.07"
+   @echo >&2 "release."
+   @echo >&2 "Failure to update by the deadline may result in board 
removal."
+   @echo >&2 "See doc/driver-model/MIGRATION.txt for more info."
+   @echo >&2 ""
+endif
+ifeq ($(CONFIG_LIBATA),y)
+ifneq ($(CONFIG_AHCI),y)
+   @echo >&2 "= WARNING =="
+   @echo >&2 "This board does use CONFIG_LIBATA but has CONFIG_AHCI not"
+   @echo >&2 "enabled. Please update the storage controller driver to use"
+   @echo >&2 "CONFIG_AHCI before the v2019.07 release."
@echo >&2 "Failure to update by the deadline may result in board 
removal."
@echo >&2 "See doc/driver-model/MIGRATION.txt for more info."
@echo >&2 ""
-- 
2.21.0

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

Re: [U-Boot] [PATCH 4/4] Makefile: Correct logic for DM_SCSI + unconverted drivers check

[Stefan Roese]

On 11.03.19 15:09, Tom Rini wrote:

On Mon, Mar 11, 2019 at 01:29:23PM +0100, Stefan Roese wrote:


When checking for boards that are enabling a SATA driver that isn't
converted to DM yet we need to be sure to not also trip over boards that
do set CONFIG_AHCI & CONFIG_BLK by itself, as that is not a bug.

This was detected when converting the Armada XP SATA driver sata_mv.c
to DM with AHCI & BLK support. This warning is still printed without
this patch applied here.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Tom Rini 
---
  Makefile | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 26db4e7b59..896e0c3350 100644
--- a/Makefile
+++ b/Makefile
@@ -940,6 +940,7 @@ endif
  endif
  ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y)
  ifneq ($(CONFIG_DM_SCSI),y)
+ifneq ($(CONFIG_BLK)$(CONFIG_AHCI),yy)
@echo >&2 "= WARNING =="
@echo >&2 "This board does not use CONFIG_DM_SCSI. Please update"
@echo >&2 "the storage controller to use CONFIG_DM_SCSI before the v2019.07 
release."


OK, I think we need to properly clarify the logic, and perhaps I was
being too clever trying to catch all of the cases under drivers/ata that
aren't converted yet.  We have, after your patches, afaict:
- MVSATA_IDE
- DWC_AHSATA
- FSL_SATA
- SATA_SIL
- SATA_SIL3114

Of these, MVSATA_IDE has no further deps.  Everything else depends on
LIBATA.  Before SATA_MV was converted, everything that was converted
depends on DM_SCSI and AHCI.  So I made my messages / logic like the
above.  But perhaps the right answer really is:
1) MVSATA_IDE alone.
2) LIBATA && !AHCI

So... we can just re-work the second part of the check logic to be what
you added, as all converted drivers under drivers/ata will be both
BLK&&AHCI enabled.


I'll work on a v2 of this patch shortly.
 

And also as you note, it's not quite AHCI as the controller in question
here isn't AHCI-compatible, but is SATA, so a fixup / rename of some
CONFIG checks in code / Kconfig is in order, somewhere, but perhaps
after conversion?


I agree.


 Also, probably some re-organization of drivers/block,
drivers/ide, drivers/ata, drivers/nvme (and common/usb_storage.c) too,
to be more consistent.


Yes, that could also be helpful.

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

[U-Boot] [PATCH v3] board/fsl/lx2160a: Fix MC firmware loading during SD boot

[Pankaj Bansal]

during SD boot, following error comes:
  MMC read: dev # 0, block # 20480, count 2048 ... 2048 blocks read: OK

  MMC read: dev # 0, block # 28672, count 2048 ... 2048 blocks read: OK
  fsl-mc: ERR: Bad firmware image (bad FIT header)
  Hit any key to stop autoboot:  0

it's occurring because mc 10.14.3 file size is 1064880, which means 0x820
SD blocks which is more than 0x800 blocks (1MB). This results in DPC
loading address 0x8010 overlapping with MC loading address 0x8000.

so, update the MC and dpc address as per their addresses in XSPI flash.
i.e. in xspi flash MC address is 0x20a0 so corresponding address in
dram when loading MC firmware from mmc is 0x80a0. similarly dpc is @
0x20e0 in xspi flash and 0x80e0 in dram when loaded from mmc.

This same approach is being followed in other cases also in same file,
e.g. esbc_validate 0x8074 <=> esbc_validate 0x2074

On same lines modify the address of dpl to 0x80d0.

Signed-off-by: Pankaj Bansal 
---

Notes:
V3:
- modify the commit message.
- remove issue/cause/fix from message.
V2:
- reduce the mc firmware size blocks from 0x1800 to 0x1200, to save on
  boot time
- Fix the commit message to indicate that the patch is for LX2160A boards
  only and for SD boot only

 include/configs/lx2160a_common.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h
index 17cfd7bfd7..98af24a45d 100644
--- a/include/configs/lx2160a_common.h
+++ b/include/configs/lx2160a_common.h
@@ -217,14 +217,14 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
"fsl_mc start mc 0x20a0 0x20e0\0"
 
 #define SD_MC_INIT_CMD \
-   "mmc read 0x8000 0x5000 0x800;" \
-   "mmc read 0x8010 0x7000 0x800;" \
+   "mmc read 0x80a0 0x5000 0x1200;"\
+   "mmc read 0x80e0 0x7000 0x800;" \
"env exists secureboot && " \
"mmc read 0x8070 0x3800 0x10 && "   \
"mmc read 0x8074 0x3A00 0x10 && "   \
"esbc_validate 0x8070 && "  \
"esbc_validate 0x8074 ;"\
-   "fsl_mc start mc 0x8000 0x8010\0"
+   "fsl_mc start mc 0x80a0 0x80e0\0"
 
 #define EXTRA_ENV_SETTINGS \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
@@ -289,11 +289,11 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
 
 #define SD_BOOTCOMMAND \
"env exists mcinitcmd && mmcinfo; " \
-   "mmc read 0x80001000 0x6800 0x800; "\
+   "mmc read 0x80d0 0x6800 0x800; "\
"env exists mcinitcmd && env exists secureboot "\
" && mmc read 0x8078 0x3C00 0x10 "  \
"&& esbc_validate 0x8078;env exists mcinitcmd " \
-   "&& fsl_mc lazyapply dpl 0x80001000;"   \
+   "&& fsl_mc lazyapply dpl 0x80d0;"   \
"run distro_bootcmd;run sd_bootcmd;"\
"env exists secureboot && esbc_halt;"
 
-- 
2.17.1

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

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now【请注意，邮件由u-boot-boun...@lists.denx.de代发】【请注意，邮件由s...@google.com代发】

[Andy Yan]

Hi Simon:

On 2019/3/11 上午10:30, Simon Glass wrote:

Hi Andy,

On Wed, 6 Mar 2019 at 03:52, Andy Yan  wrote:

Hi Simon:

On 2019/2/12 下午11:31, Simon Glass wrote:

HI Andy,

On Tue, 12 Feb 2019 at 04:05, Andy Yan  wrote:

Hi Philipp:

   Sorry for the late reply, we just come back from the Chinese Spring
Festival.

On 2019/2/1 下午6:26, Philipp Tomsich wrote:

Kever,

Independent of whether we revert this for the current cycle (and also
independent of
if I ever find the other patch you had been referring to — I couldn’t
find it in my local
mailing list archive) and then deprecate it for the next release
(unless converted to
DM), we still have a number of architectural issues that need to be
addressed:

I still doubt  is this a right  work-flow for patch apply. Before we
apply  a patch  which will break many other boards , should we  make
sure there is a solution patch applied for these boars first?



1.This really should be a driver under DTS control.
2.We need to not get away from configuring SOM-specific addresses via
Kconfig

Both these issues are technical debt that we’ve accumulated over the
last 18 months
and need to address for the sake of future maintainability.
E.g. ‘setting an address to 0x0 via Kconfig to disable a
driver/feature’ really isn’t in line
with the architectural direction of U-Boot.


For technical side, I think CONFIG_ROCKCHIP_BOOT_MODE_REG is necessary
here, we will read this register from save_boot_params when we get out
from bootrom,  the dtb is not available at this point.

Yes this is happening very early, but I wonder why this is necessary?
Can it be moved to later?

The call to check_back_to_brom_dnl_flag() happens much later so there
should be no problem to convert that.


On the other hand, almost rockchip based products use a recovery key to
enter download(upgrade)mode, this is a muti-funtion key, most of them
reuse with vol+- key,  we would like the u-boot share

dtb with linux kernel. To keep the linux kernel dts as clean as possible
,we don't want to add another dts property to describe this key either.
This is why I implement function rockchip_dnl_key_pressed as __weak.


OK, but given that it is called later, it seems to me that it could
use a driver.



We can't let it called later. See the discuss here :
http://patchwork.ozlabs.org/patch/812228/

Yes I read that, and took a look myself, and certainly it does not
look very easy and I take your point about potential bugs being
introduced.

It seems like you have tried quite hard, so I'm not going to object if
you can't find a way. My main objection was that it broke other
boards.



I took the code many times,  what this code done is : call 
adc_channel_single_shot to check if a download key is pressed, so it is 
very strange it broke the display on minnie. Would you please show the 
boot log when the display broke.




Is there any way the check could be delayed enough to actually be able
to read the device tree? It could call spl_early_init() quite early
and then do that.


Actually,  the interrupt overwrite happens in start.s,  so this don't do 
help.




Regards,
Simon






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

Re: [U-Boot] [PATCH 1/6] spl: add Kconfig option to clear bss early

[Stefan Roese]

Hi Simon,

On 11.03.19 22:35, Simon Goldschmidt wrote:

This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears
the bss before calling board_init_f() instead of clearing it before calling
board_init_r().

This also ensures that variables placed in BSS can be shared between
board_init_f() and board_init_r() in SPL.

Signed-off-by: Simon Goldschmidt 
---

  common/spl/Kconfig | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 206c24076d..5da8697994 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -156,6 +156,17 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN
  to give board_init_r() a larger heap then the initial heap in
  SRAM which is limited to SYS_MALLOC_F_LEN bytes.
  
+config SPL_CLEAR_BSS_F

+   bool "Clear BSS section before calling board_init_f"
+   help
+ The BSS section is initialized to zero. In SPL, this is normally done
+ before calling board_init_r().
+ For platforms using BSS in board_init_f() already, enable this to
+ clear the BSS section before calling board_init_f() instead of
+ clearing it before calling board_init_r(). This also ensures that
+ variables placed in BSS can be shared between board_init_f() and
+ board_init_r().
+


You should probably depend this option on "ARM", as your implementation
is currently only for this arch. Otherwise users might expect this to
work on other platforms as well.

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

[U-Boot] [PATCH v2] MC : Report extra reserved memory to Linux

[Meenakshi Aggarwal]

For MC, 512 MB DDR is reserved because of MC's alignment
requirement.
But for MC binaries needing 128MB or 256MB DDR memory, rest
of the memory is a waste. So reporting this extra memory to
Linux through dtb memory fixup.

Signed-off-by: Meenakshi Aggarwal 
---
 board/freescale/lx2160a/lx2160a.c | 28 +++-
 drivers/net/fsl-mc/mc.c   | 13 +
 include/fsl-mc/fsl_mc.h   |  1 +
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index ad72eed..b763f6d 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -532,8 +532,15 @@ void board_quiesce_devices(void)
 int ft_board_setup(void *blob, bd_t *bd)
 {
int i;
+   bool mc_memory_bank = false;
+
+#ifdef CONFIG_FSL_MC_ENET
+   u64 base[CONFIG_NR_DRAM_BANKS + 1];
+   u64 size[CONFIG_NR_DRAM_BANKS + 1];
+#else
u64 base[CONFIG_NR_DRAM_BANKS];
u64 size[CONFIG_NR_DRAM_BANKS];
+#endif
 
ft_cpu_setup(blob, bd);
 
@@ -556,7 +563,26 @@ int ft_board_setup(void *blob, bd_t *bd)
size[2] = gd->arch.resv_ram - base[2];
 #endif
 
-   fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
+#ifdef CONFIG_FSL_MC_ENET
+   fdt_fixup_mc_ddr(&base[3], &size[3]);
+
+   if (base[3] != 0) {
+   for (i = 0; i <= CONFIG_NR_DRAM_BANKS; i++) {
+   if (base[i] == 0 && size[i] == 0) {
+   base[i] = base[3];
+   size[i] = size[3];
+   break;
+   }
+   }
+   if (i == CONFIG_NR_DRAM_BANKS)
+   mc_memory_bank = true;
+   }
+#endif
+   if (mc_memory_bank)
+   fdt_fixup_memory_banks(
+blob, base, size, CONFIG_NR_DRAM_BANKS + 1);
+   else
+   fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
 
 #ifdef CONFIG_USB
fsl_fdt_fixup_dr_usb(blob, bd);
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index dddc9cc..d7a2e8f 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -285,6 +285,19 @@ static int mc_fixup_dpl_mac_addr(void *blob, int dpmac_id,
 MC_FIXUP_DPL);
 }
 
+void fdt_fixup_mc_ddr(u64 *base, u64 *size)
+{
+   u64 mc_size = mc_get_dram_block_size();
+
+   if (mc_size < MC_DRAM_BLOCK_DEFAULT_SIZE) {
+   *base = mc_get_dram_addr() + mc_size;
+   *size = MC_DRAM_BLOCK_DEFAULT_SIZE - mc_size;
+   } else {
+   *base = 0;
+   *size = 0;
+   }
+}
+
 void fdt_fsl_mc_fixup_iommu_map_entry(void *blob)
 {
u32 *prop;
diff --git a/include/fsl-mc/fsl_mc.h b/include/fsl-mc/fsl_mc.h
index aef40d3..492a714 100644
--- a/include/fsl-mc/fsl_mc.h
+++ b/include/fsl-mc/fsl_mc.h
@@ -54,6 +54,7 @@ struct mc_ccsr_registers {
 void fdt_fsl_mc_fixup_iommu_map_entry(void *blob);
 int get_mc_boot_status(void);
 int get_dpl_apply_status(void);
+void fdt_fixup_mc_ddr(u64 *base, u64 *size);
 #ifdef CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET
 int get_aiop_apply_status(void);
 #endif
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2] board/fsl/lx2160a: Fix MC firmware loading during SD boot

[Meenakshi Aggarwal]

+1

> -Original Message-
> From: Pankaj Bansal
> Sent: Tuesday, March 12, 2019 10:27 AM
> To: Meenakshi Aggarwal ; Priyanka Jain
> ; Prabhakar Kushwaha
> 
> Cc: u-boot@lists.denx.de; Pankaj Bansal 
> Subject: [PATCH v2] board/fsl/lx2160a: Fix MC firmware loading during SD boot
> 
> Issue: during SD boot, following error comes:
>   MMC read: dev # 0, block # 20480, count 2048 ... 2048 blocks read: OK
> 
>   MMC read: dev # 0, block # 28672, count 2048 ... 2048 blocks read: OK
>   fsl-mc: ERR: Bad firmware image (bad FIT header)
>   Hit any key to stop autoboot:  0
> 
> Cause: mc 10.14.3 file size is 1064880, the value is 0x820 blocks which is 
> more
> than 0x800. The default DPC loading address 0x8010 has overlap with MC
> loading address 0x8000, since the size of MC is over 1MB.
> 
> Fix: update the MC and dpc address as per their addresses in XSPI flash.
> i.e. in xspi flash MC address is 0x20a0 so corresponding address in dram
> when loading MC firmware from mmc is 0x80a0. similarly dpc is @
> 0x20e0 in xspi flash and 0x80e0 in dram when loaded from mmc.
> 
> This same approach is being followed in other cases also in same file, e.g.
> esbc_validate 0x8074 <=> esbc_validate 0x2074
> 
> On same lines modify the address of dpl to 0x80d0
> 
> Signed-off-by: Pankaj Bansal 
> ---
> 
> Notes:
> V2:
> - reduce the mc firmware size blocks from 0x1800 to 0x1200, to save on
>   boot time
> - Fix the commit message to indicate that the patch is for LX2160A boards
>   only and for SD boot only
> 
>  include/configs/lx2160a_common.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/lx2160a_common.h
> b/include/configs/lx2160a_common.h
> index 17cfd7bfd7..98af24a45d 100644
> --- a/include/configs/lx2160a_common.h
> +++ b/include/configs/lx2160a_common.h
> @@ -217,14 +217,14 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
>   "fsl_mc start mc 0x20a0 0x20e0\0"
> 
>  #define SD_MC_INIT_CMD   \
> - "mmc read 0x8000 0x5000 0x800;" \
> - "mmc read 0x8010 0x7000 0x800;" \
> + "mmc read 0x80a0 0x5000 0x1200;"\
> + "mmc read 0x80e0 0x7000 0x800;" \
>   "env exists secureboot && " \
>   "mmc read 0x8070 0x3800 0x10 && "   \
>   "mmc read 0x8074 0x3A00 0x10 && "   \
>   "esbc_validate 0x8070 && "  \
>   "esbc_validate 0x8074 ;"\
> - "fsl_mc start mc 0x8000 0x8010\0"
> + "fsl_mc start mc 0x80a0 0x80e0\0"
> 
>  #define EXTRA_ENV_SETTINGS   \
>   "hwconfig=fsl_ddr:bank_intlv=auto\0"\
> @@ -289,11 +289,11 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
> 
>  #define SD_BOOTCOMMAND   \
>   "env exists mcinitcmd && mmcinfo; " \
> - "mmc read 0x80001000 0x6800 0x800; "\
> + "mmc read 0x80d0 0x6800 0x800; "\
>   "env exists mcinitcmd && env exists secureboot "\
>   " && mmc read 0x8078 0x3C00 0x10 "  \
>   "&& esbc_validate 0x8078;env exists mcinitcmd " \
> - "&& fsl_mc lazyapply dpl 0x80001000;"   \
> + "&& fsl_mc lazyapply dpl 0x80d0;"   \
>   "run distro_bootcmd;run sd_bootcmd;"\
>   "env exists secureboot && esbc_halt;"
> 
> --
> 2.17.1

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

[U-Boot] [PATCH v2] board/fsl/lx2160a: Fix MC firmware loading during SD boot

[Pankaj Bansal]

Issue: during SD boot, following error comes:
  MMC read: dev # 0, block # 20480, count 2048 ... 2048 blocks read: OK

  MMC read: dev # 0, block # 28672, count 2048 ... 2048 blocks read: OK
  fsl-mc: ERR: Bad firmware image (bad FIT header)
  Hit any key to stop autoboot:  0

Cause: mc 10.14.3 file size is 1064880, the value is 0x820 blocks which
is more than 0x800. The default DPC loading address 0x8010 has overlap
with MC loading address 0x8000, since the size of MC is over 1MB.

Fix: update the MC and dpc address as per their addresses in XSPI flash.
i.e. in xspi flash MC address is 0x20a0 so corresponding address in
dram when loading MC firmware from mmc is 0x80a0. similarly dpc is @
0x20e0 in xspi flash and 0x80e0 in dram when loaded from mmc.

This same approach is being followed in other cases also in same file,
e.g. esbc_validate 0x8074 <=> esbc_validate 0x2074

On same lines modify the address of dpl to 0x80d0

Signed-off-by: Pankaj Bansal 
---

Notes:
V2:
- reduce the mc firmware size blocks from 0x1800 to 0x1200, to save on
  boot time
- Fix the commit message to indicate that the patch is for LX2160A boards
  only and for SD boot only

 include/configs/lx2160a_common.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h
index 17cfd7bfd7..98af24a45d 100644
--- a/include/configs/lx2160a_common.h
+++ b/include/configs/lx2160a_common.h
@@ -217,14 +217,14 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
"fsl_mc start mc 0x20a0 0x20e0\0"
 
 #define SD_MC_INIT_CMD \
-   "mmc read 0x8000 0x5000 0x800;" \
-   "mmc read 0x8010 0x7000 0x800;" \
+   "mmc read 0x80a0 0x5000 0x1200;"\
+   "mmc read 0x80e0 0x7000 0x800;" \
"env exists secureboot && " \
"mmc read 0x8070 0x3800 0x10 && "   \
"mmc read 0x8074 0x3A00 0x10 && "   \
"esbc_validate 0x8070 && "  \
"esbc_validate 0x8074 ;"\
-   "fsl_mc start mc 0x8000 0x8010\0"
+   "fsl_mc start mc 0x80a0 0x80e0\0"
 
 #define EXTRA_ENV_SETTINGS \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
@@ -289,11 +289,11 @@ int select_i2c_ch_pca9547_sec(unsigned char ch);
 
 #define SD_BOOTCOMMAND \
"env exists mcinitcmd && mmcinfo; " \
-   "mmc read 0x80001000 0x6800 0x800; "\
+   "mmc read 0x80d0 0x6800 0x800; "\
"env exists mcinitcmd && env exists secureboot "\
" && mmc read 0x8078 0x3C00 0x10 "  \
"&& esbc_validate 0x8078;env exists mcinitcmd " \
-   "&& fsl_mc lazyapply dpl 0x80001000;"   \
+   "&& fsl_mc lazyapply dpl 0x80d0;"   \
"run distro_bootcmd;run sd_bootcmd;"\
"env exists secureboot && esbc_halt;"
 
-- 
2.17.1

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

[U-Boot] [PATCH 2/2] spl: ymodem: Move GZ handling out of YModem session

[Marek Vasut]

In case the gunzip() call fails, it will print an error message.
If that happens within the YModem session, the error message will
not be displayed and would be useless. Move the gunzip() call out
of the YModem session to make those possible error messages visible.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 common/spl/spl_ymodem.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 8058fd6a7c..25226e9a33 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -75,7 +75,7 @@ static int spl_ymodem_load_image(struct spl_image_info 
*spl_image,
int ret;
connection_info_t info;
char buf[BUF_SIZE];
-   struct image_header *ih;
+   struct image_header *ih = NULL;
ulong addr = 0;
 
info.mode = xyzModem_ymodem;
@@ -128,18 +128,6 @@ static int spl_ymodem_load_image(struct spl_image_info 
*spl_image,
size += res;
addr += res;
}
-
-#ifdef CONFIG_SPL_GZIP
-   if (ih->ih_comp == IH_COMP_GZIP) {
-   if (gunzip((void *)(spl_image->load_addr + sizeof(*ih)),
-  CONFIG_SYS_BOOTM_LEN,
-  (void *)(CONFIG_SYS_LOAD_ADDR + sizeof(*ih)),
-  &size)) {
-   puts("Uncompressing error\n");
-   return -EIO;
-   }
-   }
-#endif
}
 
 end_stream:
@@ -148,6 +136,20 @@ end_stream:
 
printf("Loaded %lu bytes\n", size);
 
+#ifdef CONFIG_SPL_GZIP
+   if (!(IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+ image_get_magic((struct image_header *)buf) == FDT_MAGIC) &&
+   (ih->ih_comp == IH_COMP_GZIP)) {
+   if (gunzip((void *)(spl_image->load_addr + sizeof(*ih)),
+  CONFIG_SYS_BOOTM_LEN,
+  (void *)(CONFIG_SYS_LOAD_ADDR + sizeof(*ih)),
+  &size)) {
+   puts("Uncompressing error\n");
+   return -EIO;
+   }
+   }
+#endif
+
return ret;
 }
 SPL_LOAD_IMAGE_METHOD("UART", 0, BOOT_DEVICE_UART, spl_ymodem_load_image);
-- 
2.20.1

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

[U-Boot] [PATCH 1/2] spl: ymodem: Terminate YModem session on error

[Marek Vasut]

In case spl_parse_image_header() errors out, terminate the YModem
session, otherwise we won't get any further output.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 common/spl/spl_ymodem.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 577fdc69af..8058fd6a7c 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -111,7 +111,7 @@ static int spl_ymodem_load_image(struct spl_image_info 
*spl_image,
ih = (struct image_header *)buf;
ret = spl_parse_image_header(spl_image, ih);
if (ret)
-   return ret;
+   goto end_stream;
 #ifdef CONFIG_SPL_GZIP
if (ih->ih_comp == IH_COMP_GZIP)
addr = CONFIG_SYS_LOAD_ADDR;
@@ -147,6 +147,7 @@ end_stream:
xyzModem_stream_terminate(false, &getcymodem);
 
printf("Loaded %lu bytes\n", size);
-   return 0;
+
+   return ret;
 }
 SPL_LOAD_IMAGE_METHOD("UART", 0, BOOT_DEVICE_UART, spl_ymodem_load_image);
-- 
2.20.1

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

Re: [U-Boot] [PATCH] armv7R: K3: am654: Trigger panic on DDR init failures

[Lokesh Vutla]

On 12/03/19 1:45 AM, Andreas Dannenberg wrote:
> When initializing DDR from R5 SPL trigger U-Boot's panic facility
> rather than simply returning from the board init function as there
> is little point continuing code execution. Further, as panic implies
> a board reset, so using it might potentially allow to recover from
> this error in certain cases such as when the init failure was caused
> by a temporary glitch of some sorts.
> 
> Signed-off-by: Andreas Dannenberg 

Reviewed-by: Lokesh Vutla 

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

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now

[Kever Yang]

On 03/11/2019 09:04 PM, Philipp Tomsich wrote:
> Note that the minimum improvement that I’d expect to get this fully
> enabled again would be a clean-up of the Kconfig options, so it is
> easy and (from the documentation) predictable for boards to turn
> this off.
>
> I still want this to be turned back on in the current cycle.

Great maintainer

You objection for other patch is that it break other boards(which is non
exist actually),
and you merge this patch(break more than 10 boards very clearly) with
objection comment.
And then you require for all the Kconfig options update before the
feature back.

ＷoW!!!

Thanks,
- Kever


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

[U-Boot] [RESEND] [PATCH] cmd: image_info: Add checking of default FIT config

[Bryan O'Donoghue]

This patch adds a check for the default FIT config to iminfo. Once applied
any signing of the config will show a pass fail similar to rsa+/rsa-.

Output looks like this:

   Hash(es) for Image 0 (kernel@1): sha1+
   Hash(es) for Image 1 (f...@imx7s-warp.dtb): sha1+
   Hash(es) for Image 2 (ramdisk@1): sha1+
   Hash(es) for Image 3 (bootscr): sha1+
   Hash for default configuration: sha1,rsa2048:mbl-fit-rot-key+

Signed-off-by: Bryan O'Donoghue 
Cc: Jun Nie 
Cc: Simon Glass 
Cc: Tom Rini 
Reviewed-by: Simon Glass 
---
 cmd/bootm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/cmd/bootm.c b/cmd/bootm.c
index c3a063474a..b3bd236165 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -244,6 +244,9 @@ static int do_iminfo(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
 static int image_info(ulong addr)
 {
+#if defined(CONFIG_FIT)
+   int cfg_noffset;
+#endif
void *hdr = (void *)addr;
 
printf("\n## Checking Image at %08lx ...\n", addr);
@@ -294,6 +297,20 @@ static int image_info(ulong addr)
return 1;
}
 
+   cfg_noffset = fit_conf_get_node(hdr, NULL);
+   if (!cfg_noffset) {
+   printf("Could not find configuration node: %s\n",
+  fdt_strerror(cfg_noffset));
+   return 1;
+   }
+
+   puts("   Hash for default configuration: ");
+   if (fit_config_verify(hdr, cfg_noffset)) {
+   puts("Unable to verify default fit config\n");
+   return 1;
+   }
+   puts("\n");
+
return 0;
 #endif
default:
-- 
2.20.1

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

Re: [U-Boot] [PATCH 5/7] riscv: add support for multi-hart systems

[Rick Chen]

Hi Lukas

Auer, Lukas  於 2019年3月11日 週一 上午2:12寫道：
>
> On Sun, 2019-03-10 at 20:24 +0530, Anup Patel wrote:
> > On Sun, Mar 10, 2019 at 7:28 PM Auer, Lukas
> >  wrote:
> > > Hi Rick,
> > >
> > > On Thu, 2019-03-07 at 17:30 +0800, Rick Chen wrote:
> > > > Hi Lukas
> > > >
> > > > > > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > > > > > Sent: Tuesday, February 12, 2019 6:14 AM
> > > > > > To: u-boot@lists.denx.de
> > > > > > Cc: Atish Patra; Anup Patel; Bin Meng; Andreas Schwab; Palmer
> > > > > > Dabbelt;
> > > > > > Alexander Graf; Lukas Auer; Anup Patel; Rick Jian-Zhi
> > > > > > Chen(陳建志);
> > > > > > Baruch Siach;
> > > > > > Stefan Roese
> > > > > > Subject: [PATCH 5/7] riscv: add support for multi-hart
> > > > > > systems
> > > > > >
> > > > > > On RISC-V, all harts boot independently. To be able to run on
> > > > > > a
> > > > > > multi-hart system,
> > > > > > U-Boot must be extended with the functionality to manage all
> > > > > > harts in the
> > > > > > system. A new config option, CONFIG_MAIN_HART, is used to
> > > > > > select
> > > > > > the hart
> > > > > > U-Boot runs on. All other harts are halted.
> > > > > > U-Boot can delegate functions to them using
> > > > > > smp_call_function().
> > > > > >
> > > > > > Every hart has a valid pointer to the global data structure
> > > > > > and a
> > > > > > 8KiB stack by
> > > > > > default. The stack size is set with CONFIG_STACK_SIZE_SHIFT.
> > > > > >
> > > > > > Signed-off-by: Lukas Auer 
> > > > > > ---
> > > > > >
> > > > > >  arch/riscv/Kconfig   |  12 +
> > > > > >  arch/riscv/cpu/start.S   | 102
> > > > > > ++-
> > > > > >  arch/riscv/include/asm/csr.h |   1 +
> > > > > >  3 files changed, 114 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > > > > > 3a51339c4d..af8d0f8d67
> > > > > > 100644
> > > > > > --- a/arch/riscv/Kconfig
> > > > > > +++ b/arch/riscv/Kconfig
> > > > > > @@ -140,4 +140,16 @@ config SBI_IPI
> > > > > >   default y if RISCV_SMODE
> > > > > >   depends on SMP
> > > > > >
> > > > > > +config MAIN_HART
> > > > > > + int "Main hart in system"
> > > > > > + default 0
> > > > > > + help
> > > > > > +   Some SoCs include harts of various sizes, some of
> > > > > > which
> > > > > > might not
> > > > > > +   be suitable for running U-Boot. CONFIG_MAIN_HART is
> > > > > > used
> > > > > > to select
> > > > > > +   the hart U-Boot runs on.
> > > > > > +
> > > > > > +config STACK_SIZE_SHIFT
> > > > > > + int
> > > > > > + default 13
> > > > > > +
> > > > > >  endmenu
> > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > > > > index
> > > > > > a30f6f7194..ce7230df37 100644
> > > > > > --- a/arch/riscv/cpu/start.S
> > > > > > +++ b/arch/riscv/cpu/start.S
> > > > > > @@ -13,6 +13,7 @@
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > > +#include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > >
> > > > > > @@ -45,6 +46,23 @@ _start:
> > > > > >   /* mask all interrupts */
> > > > > >   csrwMODE_PREFIX(ie), zero
> > > > > >
> > > > > > +#ifdef CONFIG_SMP
> > > > > > + /* check if hart is within range */
> > > > > > + /* s0: hart id */
> > > > > > + li  t0, CONFIG_NR_CPUS
> > > > > > + bge s0, t0, hart_out_of_bounds_loop
> > > > > > +#endif
> > > > > > +
> > > > > > +#ifdef CONFIG_SMP
> > > > > > + /* set xSIE bit to receive IPIs */
> > > > > > +#ifdef CONFIG_RISCV_MMODE
> > > > > > + li  t0, MIE_MSIE
> > > > > > +#else
> > > > > > + li  t0, SIE_SSIE
> > > > > > +#endif
> > > > > > + csrsMODE_PREFIX(ie), t0
> > > > > > +#endif
> > > > > > +
> > > > > >  /*
> > > > > >   * Set stackpointer in internal/ex RAM to call board_init_f
> > > > > >   */
> > > > > > @@ -56,7 +74,25 @@ call_board_init_f:
> > > > > >  call_board_init_f_0:
> > > > > >   mv  a0, sp
> > > > > >   jal board_init_f_alloc_reserve
> > > > > > +
> > > > > > + /*
> > > > > > +  * Set global data pointer here for all harts,
> > > > > > uninitialized at this
> > > > > > +  * point.
> > > > > > +  */
> > > > > > + mv  gp, a0
> > > > > > +
> > > > > > + /* setup stack */
> > > > > > +#ifdef CONFIG_SMP
> > > > > > + /* s0: hart id */
> > > > > > + sllit0, s0, CONFIG_STACK_SIZE_SHIFT
> > > > > > + sub sp, a0, t0
> > > > > > +#else
> > > > > >   mv  sp, a0
> > > > > > +#endif
> > > > > > +
> > > > > > + /* Continue on main hart, others branch to
> > > > > > secondary_hart_loop */
> > > > > > + li  t0, CONFIG_MAIN_HART
> > > > > > + bne s0, t0, secondary_hart_loop
> > > > > >
> > > > > >   la  t0, prior_stage_fdt_address
> > > > > >   SREGs1, 0(t0)
> > > > > > @@ -95,7 +131,14 @@ relocate_code:
> > > > > >   *Set up the stack
> > > > > >   */
> > > > > >  stack_setup:
> > > > > > +#ifde

Re: [U-Boot] [PATCH v5 0/9] arm: exynos: Fix reboot on Odroid HC1

[Minkyu Kang]

On 07/03/2019 03:37, Krzysztof Kozlowski wrote:
> Hi,
> 
> Changes since v4
> 
> 1. Patch 3: Fix build of trats/trats2 and other by hiding new call
>behind check for CONFIG_BOARD_TYPES.
> 
> Changes since v3
> 
> 1. Add accumulated review and test tags.
> 2. Patch 6: Add "ramp" keyword to new function (as discussed with
>Torsten Duwe).
> 3. Rebased on v2019.04-rc3.
> 
> 
> Changes since v2
> 
> 1. Add Lukasz review tags.
> 2. Patch 7: Return on error, as suggested by Simon.
> 2. Patch 3: Use IS_ENABLED() to run revision detection only
>once - either during late display board or misc_init_r.
> 
> Changes since v1
> 
> 1. Move fixes to beginning of patchset.
> 2. Patch 3: Rework the idea - split revision detection to be executed later.
> 3. Patch 4: New patch.
> 4. Patch 6: Apply Simon's comments.
> 5. Patch 6: Do not delay when changing voltage if regulator is disabled.
> 6. Patch 6: Do not delay when disabling the regulator.
> 
> 
> Description
> ===
> Odroid HC1 does not reboot properly (at least from SD card but
> I do not expect difference on eMMC), if LDO4/VDD_ADC was turned
> off by Linux kernel.  This condition happens so far always, because
> Linux kernel did not enable ADC on Odroid HC1, therefore the
> VDD_ADC regulator was turned off as unused.
> 
> The issue is in detection of revision which later is used to load
> proper DTB.
> 
> The revision is obtained by ADC read of a voltage depending on VDD_ADC.
> Therefore:
> 1. VDD_ADC has to be turned on (but board detection happens before
>power is initialized),
> 2. Turning VDD_ADC should wait with ramp delay,
> 3. Reading the value from ADC should wait for it to stabilize.
> 
> Tested on Odroid XU3-Lite and Odroid HC1.
> 
> Comments and testing are welcomed.
> 
> Best regards,
> Krzysztof
> 
> 
> Krzysztof Kozlowski (9):
>   adc: exynos-adc: Fix wrong bit operation used to stop the ADC
>   power: regulator: s2mps11: Fix step for LDO27 and LDO35
>   arm: exynos: Detect revision later, when all resources are ready
>   arm: exynos: odroid-xu3: Display info late to have proper type
>   arm: exynos: Wait till ADC stabilizes before checking Odroid HC1
> revision
>   regulator: Add support for ramp delay
>   power: regulator: s2mps11: Add enable delay
>   arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
>   arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid
> XU3 family
> 
>  arch/arm/dts/exynos5422-odroidxu3.dts | 20 +++
>  board/samsung/common/board.c  | 25 -
>  board/samsung/common/exynos5-dt-types.c   | 54 +--
>  board/samsung/odroid/odroid.c |  8 +++
>  configs/odroid-xu3_defconfig  |  2 +
>  .../regulator/regulator.txt   |  2 +
>  drivers/adc/exynos-adc.c  |  2 +-
>  drivers/power/regulator/regulator-uclass.c| 47 +++-
>  drivers/power/regulator/s2mps11_regulator.c   | 15 +-
>  include/power/regulator.h |  2 +
>  include/samsung/misc.h|  1 +
>  11 files changed, 168 insertions(+), 10 deletions(-)
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH] espresso7420: remove duplicated config

[Minkyu Kang]

On 07/03/2019 17:03, Minkyu Kang wrote:
> Signed-off-by: Minkyu Kang 
> ---
>  include/configs/espresso7420.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/configs/espresso7420.h b/include/configs/espresso7420.h
> index 4e3b26c..5aeb009 100644
> --- a/include/configs/espresso7420.h
> +++ b/include/configs/espresso7420.h
> @@ -21,8 +21,6 @@
>  /* select serial console configuration */
>  #define CONFIG_DEFAULT_CONSOLE   "console=ttySAC1,115200n8\0"
>  
> -#define CONFIG_DEFAULT_CONSOLE   "console=ttySAC1,115200n8\0"
> -
>  /* DRAM Memory Banks */
>  #define SDRAM_BANK_SIZE  (256UL << 20UL) /* 256 MB */
>  
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH 2/4] configs: odroid_xu3: Use consistent syntax for #include

[Minkyu Kang]

On 23/02/2019 03:36, Krzysztof Kozlowski wrote:
> When including other header from configs, use consistent <> syntax.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  include/configs/odroid_xu3.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h
> index f178549a7223..7f4cff186151 100644
> --- a/include/configs/odroid_xu3.h
> +++ b/include/configs/odroid_xu3.h
> @@ -7,7 +7,7 @@
>  #ifndef __CONFIG_ODROID_XU3_H
>  #define __CONFIG_ODROID_XU3_H
>  
> -#include "exynos5420-common.h"
> +#include 
>  #include 
>  
>  #define CONFIG_BOARD_COMMON
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH 1/4] arm: exynos: arndale: Replace Chander Kashyap inactive maintainer

[Minkyu Kang]

On 23/02/2019 03:36, Krzysztof Kozlowski wrote:
> Last activity from Arndale (Exynos5250) board maintainer Chander Kashyap
> was in January 2014 (Signed-off).  Recently his samsung.com email
> bounces with 550 (5.1.1 Recipient address rejected: User unknown).
> 
> Add Krzysztof Kozlowski as odd fixer for this board.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Although I do not have this particular board, but still I can try to
> take care about odd fixes.  Instead I have few other boards based on
> Exynos4412 (Odroids) and 542x (Arndale Octa, Odroids).  I also run
> automated Linux kernel boot tests for my boards and I maintain the
> Samsung SoCs in Linux kernel.
> ---
>  board/samsung/arndale/MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/board/samsung/arndale/MAINTAINERS 
> b/board/samsung/arndale/MAINTAINERS
> index 7dc17854d1b3..98ccaa42a86e 100644
> --- a/board/samsung/arndale/MAINTAINERS
> +++ b/board/samsung/arndale/MAINTAINERS
> @@ -1,6 +1,6 @@
>  ARNDALE BOARD
> -M:   Chander Kashyap 
> -S:   Maintained
> +M:   Krzysztof Kozlowski 
> +S:   Odd Fixes
>  F:   board/samsung/arndale/
>  F:   include/configs/arndale.h
>  F:   configs/arndale_defconfig
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH 3/4] configs: odroid_xu3: Unify indentation

[Minkyu Kang]

On 23/02/2019 03:36, Krzysztof Kozlowski wrote:
> File mixed space and tab indentation.  Unify it.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  include/configs/odroid_xu3.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h
> index 7f4cff186151..5e765a2b2b02 100644
> --- a/include/configs/odroid_xu3.h
> +++ b/include/configs/odroid_xu3.h
> @@ -18,7 +18,7 @@
>  
>  #define TZPC_BASE_OFFSET 0x1
>  
> -#define SDRAM_BANK_SIZE  (256UL << 20UL) /* 256 MB */
> +#define SDRAM_BANK_SIZE  (256UL << 20UL) /* 256 MB */
>  /* Reserve the last 22 MiB for the secure firmware */
>  #define CONFIG_SYS_MEM_TOP_HIDE  (22UL << 20UL)
>  #define CONFIG_TZSW_RESERVED_DRAM_SIZE   CONFIG_SYS_MEM_TOP_HIDE
> @@ -28,7 +28,7 @@
>  #define CONFIG_ENV_SIZE  (SZ_1K * 16)
>  #define CONFIG_ENV_OFFSET(SZ_1K * 3136) /* ~3 MiB offset */
>  
> -#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
> +#define CONFIG_SYS_INIT_SP_ADDR  (CONFIG_SYS_LOAD_ADDR - 
> 0x100)
>  
>  #define CONFIG_DEFAULT_CONSOLE   "console=ttySAC2,115200n8\0"
>  
> @@ -38,7 +38,7 @@
>  /* DFU */
>  #define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_32M
>  #define DFU_DEFAULT_POLL_TIMEOUT 300
> -#define DFU_MANIFEST_POLL_TIMEOUT   25000
> +#define DFU_MANIFEST_POLL_TIMEOUT25000
>  
>  /* THOR */
>  #define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_USB_GADGET_VENDOR_NUM
> @@ -85,11 +85,11 @@
>  #define CONFIG_SET_DFU_ALT_BUF_LEN   (SZ_1K)
>  
>  /* Set soc_rev, soc_id, board_rev, boardname, fdtfile */
> -#define CONFIG_ODROID_REV_AIN9
> +#define CONFIG_ODROID_REV_AIN9
>  #define CONFIG_REVISION_TAG
>  
>  #undef CONFIG_SYS_BOARD
> -#define CONFIG_SYS_BOARD "odroid"
> +#define CONFIG_SYS_BOARD "odroid"
>  
>  /* Define new extra env settings, including DFU settings */
>  #undef CONFIG_EXTRA_ENV_SETTINGS
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH] arm: dts: exynos: Adjust whitespace around status property

[Minkyu Kang]

On 22/02/2019 01:32, Krzysztof Kozlowski wrote:
> Just add spaces around '=' sign for clarity.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/dts/exynos5422-odroidxu3.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
> b/arch/arm/dts/exynos5422-odroidxu3.dts
> index e859dd1b981a..e0ad927dbf18 100644
> --- a/arch/arm/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/dts/exynos5422-odroidxu3.dts
> @@ -256,7 +256,7 @@
>   };
>  
>   serial@12C2 {
> - status="okay";
> + status = "okay";
>   };
>  
>   mmc@1220 {
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH] arm: exynos: odroid: Fix build if BOARD_TYPES are not set

[Minkyu Kang]

On 06/03/2019 18:23, Krzysztof Kozlowski wrote:
> CONFIG_BOARD_TYPES is necessary for Odroid X/X2/U3 boards to detect
> proper revision.  However building should succeed even without it.
> While moving code around, document also the reference clock selection.
> 
> This fixes the build error without CONFIG_BOARD_TYPES:
> 
> board/samsung/odroid/odroid.c: In function 'board_usb_init':
> board/samsung/odroid/odroid.c:473:8: error: 'gd_t' {aka 'volatile struct 
> global_data'} has no member named 'board_type'
>   if (gd->board_type == ODROID_TYPE_U3)
> ^~
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  board/samsung/odroid/odroid.c | 27 +--
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
> index 552333fe869d..b11d99223346 100644
> --- a/board/samsung/odroid/odroid.c
> +++ b/board/samsung/odroid/odroid.c
> @@ -462,18 +462,33 @@ struct dwc2_plat_otg_data s5pc210_otg_data = {
>  
>  #if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
>  
> +static void set_usb3503_ref_clk(void)
> +{
> +#ifdef CONFIG_BOARD_TYPES
> + /*
> +  * gpx3-0 chooses primary (low) or secondary (high) reference clock
> +  * frequencies table.  The choice of clock is done through hard-wired
> +  * REF_SEL pins.
> +  * The Odroid Us have reference clock at 24 MHz (00 entry from secondary
> +  * table) and Odroid Xs have it at 26 MHz (01 entry from primary table).
> +  */
> + if (gd->board_type == ODROID_TYPE_U3)
> + gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
> + else
> + gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
> +#else
> + /* Choose Odroid Xs frequency without board types */
> + gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
> +#endif /* CONFIG_BOARD_TYPES */
> +}
> +
>  int board_usb_init(int index, enum usb_init_type init)
>  {
>  #ifdef CONFIG_CMD_USB
>   struct udevice *dev;
>   int ret;
>  
> - /* Set Ref freq 0 => 24MHz, 1 => 26MHz*/
> - /* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
> - if (gd->board_type == ODROID_TYPE_U3)
> - gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
> - else
> - gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
> + set_usb3503_ref_clk();
>  
>   /* Disconnect, Reset, Connect */
>   gpio_direction_output(EXYNOS4X12_GPIO_X34, 0);
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH 4/4] arm: exynos: Remove duplicated "boardname" env setting

[Minkyu Kang]

On 23/02/2019 03:36, Krzysztof Kozlowski wrote:
> Various places in the code set "boardname" env property.  It was used
> for booting from ITB images and choosing proper DTB file name.  Instead
> of duplicating it, use existing U-Boot wide - "board_name".
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Tested only on Odroid XU3.
> Tests on other boards appreciated.
> ---
>  board/samsung/common/bootscripts/autoboot.cmd | 10 +-
>  board/samsung/common/misc.c   |  2 +-
>  include/configs/odroid.h  |  2 +-
>  include/configs/odroid_xu3.h  |  8 ++--
>  4 files changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/board/samsung/common/bootscripts/autoboot.cmd 
> b/board/samsung/common/bootscripts/autoboot.cmd
> index 11c724c4e095..d66bcccf5d1c 100644
> --- a/board/samsung/common/bootscripts/autoboot.cmd
> +++ b/board/samsung/common/bootscripts/autoboot.cmd
> @@ -3,7 +3,7 @@
>  # ./tools/mkimage -c none -A arm -T script -d autoboot.cmd boot.scr
>  #
>  # It requires a list of environment variables to be defined before load:
> -# platform dependent: boardname, fdtfile, console
> +# platform dependent: board_name, fdtfile, console
>  # system dependent: mmcbootdev, mmcbootpart, mmcrootdev, mmcrootpart, 
> rootfstype
>  #
>  setenv fdtaddr "4080"
> @@ -35,17 +35,17 @@ else
>   setenv initrd_addr -;
>  fi;"
>  
> - Routine: boot_fit - check that env $boardname is set and boot proper 
> config of ITB image
> + Routine: boot_fit - check that env $board_name is set and boot proper 
> config of ITB image
>  setenv setboot_fit "
> -if test -e '${boardname}'; then
> +if test -e '${board_name}'; then
>   setenv fdt_addr ;
>   setenv initrd_addr ;
>   setenv kerneladdr  0x4200;
>   setenv kernelname  Image.itb;
> - setenv itbcfg  "\"#${boardname}\"";
> + setenv itbcfg  "\"#${board_name}\"";
>   setenv imgbootcmd  bootm;
>  else
> - echo Warning! Variable: \$boardname is undefined!;
> + echo Warning! Variable: \$board_name is undefined!;
>  fi"
>  
>   Routine: setboot_uimg - prepare env to boot uImage
> diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
> index 05243fc89659..53cd1b290703 100644
> --- a/board/samsung/common/misc.c
> +++ b/board/samsung/common/misc.c
> @@ -101,7 +101,7 @@ void set_board_info(void)
>   bdtype = "";
>  
>   sprintf(info, "%s%s", bdname, bdtype);
> - env_set("boardname", info);
> + env_set("board_name", info);
>  #endif
>   snprintf(info, ARRAY_SIZE(info),  "%s%x-%s%s.dtb",
>CONFIG_SYS_SOC, s5p_cpu_id, bdname, bdtype);
> diff --git a/include/configs/odroid.h b/include/configs/odroid.h
> index b8809c8dcc7c..9f2d43e3fa38 100644
> --- a/include/configs/odroid.h
> +++ b/include/configs/odroid.h
> @@ -132,7 +132,7 @@
>   "setenv kernelname Image.itb;" \
>   "run loadkernel;" \
>   "run kernel_args;" \
> - "bootm ${kernel_addr_r}#${boardname}\0" \
> + "bootm ${kernel_addr_r}#${board_name}\0" \
>   "boot_uimg=" \
>   "setenv kernelname uImage;" \
>   "run check_dtb;" \
> diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h
> index 5e765a2b2b02..af6004eaf511 100644
> --- a/include/configs/odroid_xu3.h
> +++ b/include/configs/odroid_xu3.h
> @@ -84,10 +84,14 @@
>  #define CONFIG_SET_DFU_ALT_INFO
>  #define CONFIG_SET_DFU_ALT_BUF_LEN   (SZ_1K)
>  
> -/* Set soc_rev, soc_id, board_rev, boardname, fdtfile */
> +/* Set soc_rev, soc_id, board_rev, board_name, fdtfile */
>  #define CONFIG_ODROID_REV_AIN9
>  #define CONFIG_REVISION_TAG
>  
> +/*
> + * Need to override existing one (smdk5420) with odroid so set_board_info 
> will
> + * use proper prefix when creating full board_name (SYS_BOARD + type)
> + */
>  #undef CONFIG_SYS_BOARD
>  #define CONFIG_SYS_BOARD "odroid"
>  
> @@ -101,7 +105,7 @@
>   "rootfstype=ext4\0" \
>   "console=" CONFIG_DEFAULT_CONSOLE \
>   "fdtfile=exynos5422-odroidxu3.dtb\0" \
> - "boardname=odroidxu3\0" \
> + "board_name=odroidxu3\0" \
>   "mmcbootdev=0\0" \
>   "mmcrootdev=0\0" \
>   "mmcbootpart=1\0" \
> 

applied to u-boot-samsung.

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

[U-Boot] [PATCH V2] Revert "pico-imx7d: Add LCD support"

[Joris Offouga]

This reverts commit 9e3c0174da842dd88f5feaffbf843ba332233897.

This commit breaks U-Boot when is load with imx-usb-loader.

Signed-off-by: Joris Offouga 
---
Changes for v2:
- Add missing signed-off 
---
 board/technexion/pico-imx7d/pico-imx7d.c | 55 
 configs/pico-hobbit-imx7d_defconfig  |  1 -
 configs/pico-imx7d_defconfig |  1 -
 configs/pico-pi-imx7d_defconfig  |  1 -
 include/configs/pico-imx7d.h | 12 ---
 5 files changed, 70 deletions(-)

diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index 767d13d..53e1469 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -39,16 +39,8 @@ DECLARE_GLOBAL_DATA_PTR;
 #define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
 
-
-#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
-PAD_CTL_DSE_3P3V_49OHM)
-
-#define LCD_SYNC_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
- PAD_CTL_DSE_3P3V_196OHM)
-
 #ifdef CONFIG_SYS_I2C_MXC
 #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-
 /* I2C4 for PMIC */
 static struct i2c_pads_info i2c_pad_info4 = {
.scl = {
@@ -254,58 +246,11 @@ int board_early_init_f(void)
return 0;
 }
 
-#ifdef CONFIG_VIDEO_MXS
-static iomux_v3_cfg_t const lcd_pads[] = {
-   MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_ENABLE__LCD_ENABLE | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
-   MX7D_PAD_LCD_HSYNC__LCD_HSYNC | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
-   MX7D_PAD_LCD_VSYNC__LCD_VSYNC | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
-   MX7D_PAD_LCD_DATA00__LCD_DATA0 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA01__LCD_DATA1 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA02__LCD_DATA2 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA03__LCD_DATA3 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA04__LCD_DATA4 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA05__LCD_DATA5 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA06__LCD_DATA6 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA07__LCD_DATA7 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA08__LCD_DATA8 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA09__LCD_DATA9 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA10__LCD_DATA10 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA11__LCD_DATA11 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA12__LCD_DATA12 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA13__LCD_DATA13 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA14__LCD_DATA14 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA15__LCD_DATA15 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA16__LCD_DATA16 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA17__LCD_DATA17 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA18__LCD_DATA18 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA19__LCD_DATA19 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA20__LCD_DATA20 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA21__LCD_DATA21 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA22__LCD_DATA22 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA23__LCD_DATA23 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_GPIO1_IO06__GPIO1_IO6  | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_GPIO1_IO11__GPIO1_IO11 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-void setup_lcd(void)
-{
-   imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
-   /* Set Brightness to high */
-   gpio_direction_output(IMX_GPIO_NR(1, 11) , 1);
-   /* Set LCD enable to high */
-   gpio_direction_output(IMX_GPIO_NR(1, 6) , 1);
-}
-#endif
-
 int board_init(void)
 {
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
 
-#ifdef CONFIG_VIDEO_MXS
-   setup_lcd();
-#endif
 #ifdef CONFIG_FEC_MXC
setup_fec();
 #endif
diff --git a/configs/pico-hobbit-imx7d_defconfig 
b/configs/pico-hobbit-imx7d_defconfig
index f58d517..cb4a6bf 100644
--- a/configs/pico-hobbit-imx7d_defconfig
+++ b/configs/pico-hobbit-imx7d_defconfig
@@ -57,5 +57,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
-CONFIG_VIDEO=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/pico-imx7d_defconfig b/configs/pico-imx7d_defconfig
index 7e13923..f90d757 100644
--- a/configs/pico-imx7d_defconfig
+++ b/configs/pico-imx7d_defconfig
@@ -57,5 +57,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
 CONFIG_CI_UDC=y
-CONFIG_VIDEO=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/pico-pi-imx7d_defconfig b/configs/pico-pi-imx7d_defconfig
index c8ac2ff..8e48ba7 100644
--- a/configs/pico-pi-imx7d_defconfig
+++ b/configs/pico-pi-imx7

[U-Boot] [PATCH 0/6] spl: full-featured heap cleanups

[Simon Goldschmidt]

Some platforms cannot use simple malloc even in very early stages, e.g.
when using FAT before DRAM is available. Such platforms currently often
use non-Kconfig defines to initialize full malloc and rely on simple heap
before that.

This series makes some adjustments to ensure SPL behaves the same with
simple or full malloc: when CONFIG_SPL_SYS_MALLOC_F_LEN is != 0, both heap
types can be used (by changing CONFIG_SPL_SYS_MALLOC_SIMPLE), without
manually supplying an address range for the full heap.


Simon Goldschmidt (6):
  spl: add Kconfig option to clear bss early
  spl: arm: implement SPL_CLEAR_BSS_F
  dlmalloc: fix malloc range at end of ram
  dlmalloc: be compatible to tiny printf
  spl: support using full malloc with SYS_MALLOC_F_LEN
  arm: socfpga: a10: move SPL stack size to Kconfig

 arch/arm/lib/crt0.S   | 22 ++
 common/dlmalloc.c |  6 +-
 common/spl/Kconfig| 11 +++
 common/spl/spl.c  |  5 +
 configs/socfpga_arria10_defconfig |  1 +
 include/configs/socfpga_common.h  | 14 --
 6 files changed, 44 insertions(+), 15 deletions(-)

-- 
2.17.1

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

[U-Boot] [PATCH 5/6] spl: support using full malloc with SYS_MALLOC_F_LEN

[Simon Goldschmidt]

Some platforms (like socfpga A10) need a big hep before SDRAM is available
(e.g. because FAT is used). For such platforms, simple_malloc is often not
a good option as it does not support freeing memory. These platforms often
use the non-Kconfig defines CONFIG_SYS_SPL_MALLOC_START (and its SIZE).

This patch allows enabling CONFIG_SPL_SYS_MALLOC_F_LEN while leaving
CONFIG_SPL_SYS_MALLOC_SIMPLE disabled. In this case, the full malloc heap
is made available as early as the simple_malloc heap would be normally.

This way, platforms can drop the non-Kconfig options to set up the full
heap and rely on the same automatically calculated heap allocation used
for simple heap.

Signed-off-by: Simon Goldschmidt 
---

 common/spl/spl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 88d4b8a9bf..b89340eb27 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -383,8 +383,13 @@ static int spl_common_init(bool setup_malloc)
 #ifdef CONFIG_MALLOC_F_ADDR
gd->malloc_base = CONFIG_MALLOC_F_ADDR;
 #endif
+#if CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE)
gd->malloc_limit = CONFIG_VAL(SYS_MALLOC_F_LEN);
gd->malloc_ptr = 0;
+#else
+   mem_malloc_init(gd->malloc_base, CONFIG_VAL(SYS_MALLOC_F_LEN));
+   gd->flags |= GD_FLG_FULL_MALLOC_INIT;
+#endif
}
 #endif
ret = bootstage_init(true);
-- 
2.17.1

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

[U-Boot] [PATCH 4/6] dlmalloc: be compatible to tiny printf

[Simon Goldschmidt]

Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny
printf used in SPL.

Signed-off-by: Simon Goldschmidt 
---

 common/dlmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 51d3bd671a..af6f43dcc9 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -608,7 +608,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end--;
}
 
-   debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
+   debug("using memory 0x%lx-0x%lx for malloc()\n", mem_malloc_start,
  mem_malloc_end);
 #ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
memset((void *)mem_malloc_start, 0x0, size);
-- 
2.17.1

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

[U-Boot] [PATCH 3/6] dlmalloc: fix malloc range at end of ram

[Simon Goldschmidt]

If the malloc range passed to mem_malloc_init() is at the end of address
range and 'start + size' overflows to 0, following allocations fail as
mem_malloc_end is zero (which looks like uninitialized).

Fix this by subtracting 1 of 'start + size' overflows to zero.

Signed-off-by: Simon Goldschmidt 
---

 common/dlmalloc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index edaad299bb..51d3bd671a 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -603,6 +603,10 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
+   if (start && size && !mem_malloc_end) {
+   /* overflow: malloc area is at end of address range */
+   mem_malloc_end--;
+   }
 
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
  mem_malloc_end);
-- 
2.17.1

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

[U-Boot] [PATCH 6/6] arm: socfpga: a10: move SPL stack size to Kconfig

[Simon Goldschmidt]

Instead of fixing the SPL stack to 64 KiB in the board config header via
CONFIG_SYS_SPL_MALLOC_SIZE, let's just use CONFIG_SPL_SYS_MALLOC_F_LEN
in the defconfig.

This also has the advandage that it removes sub-mach specific ifdefs in
socfpga_common.h.

Signed-off-by: Simon Goldschmidt 
---

This patch was part of an socfpga series before. It didn't work there and
was the reason for this series. It also serves as a demonstration of this
series.
---
 configs/socfpga_arria10_defconfig |  1 +
 include/configs/socfpga_common.h  | 14 --
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/configs/socfpga_arria10_defconfig 
b/configs/socfpga_arria10_defconfig
index f321a0ac3b..8d0479cc05 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
 CONFIG_SYS_TEXT_BASE=0x0140
 CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x1
 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y
 CONFIG_SPL=y
 CONFIG_IDENT_STRING="socfpga_arria10"
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 181af9b646..16c83900c3 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -251,16 +251,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #define CONFIG_SPL_TEXT_BASE   CONFIG_SYS_INIT_RAM_ADDR
 #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
 
-#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-/* SPL memory allocation configuration, this is for FAT implementation */
-#ifndef CONFIG_SYS_SPL_MALLOC_START
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
-#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \
-CONFIG_SYS_SPL_MALLOC_SIZE + \
-CONFIG_SYS_INIT_RAM_ADDR)
-#endif
-#endif
-
 /* SPL SDMMC boot support */
 #ifdef CONFIG_SPL_MMC_SUPPORT
 #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
@@ -294,11 +284,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 /*
  * Stack setup
  */
-#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
-#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-#define CONFIG_SPL_STACK   CONFIG_SYS_SPL_MALLOC_START
-#endif
 
 /* Extra Environment */
 #ifndef CONFIG_SPL_BUILD
-- 
2.17.1

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

[U-Boot] [PATCH 2/6] spl: arm: implement SPL_CLEAR_BSS_F

[Simon Goldschmidt]

This implements the new option to clear BSS early in SPL for standard arm
crt0.

BSS is cleared before calling board_init_f() and thus not cleared before
calling board_init_r() as it is not relocated in SPL.

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/lib/crt0.S | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index fe312db690..b06e54e144 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -80,6 +80,26 @@ ENTRY(_main)
mov r9, r0
bl  board_init_f_init_reserve
 
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_CLEAR_BSS_F)
+   ldr r0, =__bss_start
+
+#ifdef CONFIG_USE_ARCH_MEMSET
+   ldr r3, =__bss_end
+   mov r1, #0x /* prepare zero to clear BSS */
+
+   subsr2, r3, r0  /* r2 = memset len */
+   bl  memset
+#else
+   ldr r1, =__bss_end
+   mov r2, #0x /* prepare zero to clear BSS */
+
+clbss_l:cmpr0, r1  /* while not at end of BSS */
+   strlo   r2, [r0]/* clear 32-bit BSS word */
+   addlo   r0, r0, #4  /* move to next */
+   blo clbss_l
+#endif
+#endif
+
mov r0, #0
bl  board_init_f
 
@@ -124,6 +144,7 @@ here:
movne   sp, r0
movne   r9, r0
 # endif
+#if !defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL_CLEAR_BSS_F)
ldr r0, =__bss_start/* this is auto-relocated! */
 
 #ifdef CONFIG_USE_ARCH_MEMSET
@@ -141,6 +162,7 @@ clbss_l:cmp r0, r1  /* while not at end of 
BSS */
addlo   r0, r0, #4  /* move to next */
blo clbss_l
 #endif
+#endif
 
 #if ! defined(CONFIG_SPL_BUILD)
bl coloured_LED_init
-- 
2.17.1

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

[U-Boot] [PATCH 1/6] spl: add Kconfig option to clear bss early

[Simon Goldschmidt]

This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears
the bss before calling board_init_f() instead of clearing it before calling
board_init_r().

This also ensures that variables placed in BSS can be shared between
board_init_f() and board_init_r() in SPL.

Signed-off-by: Simon Goldschmidt 
---

 common/spl/Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 206c24076d..5da8697994 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -156,6 +156,17 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN
  to give board_init_r() a larger heap then the initial heap in
  SRAM which is limited to SYS_MALLOC_F_LEN bytes.
 
+config SPL_CLEAR_BSS_F
+   bool "Clear BSS section before calling board_init_f"
+   help
+ The BSS section is initialized to zero. In SPL, this is normally done
+ before calling board_init_r().
+ For platforms using BSS in board_init_f() already, enable this to
+ clear the BSS section before calling board_init_f() instead of
+ clearing it before calling board_init_r(). This also ensures that
+ variables placed in BSS can be shared between board_init_f() and
+ board_init_r().
+
 config SPL_SEPARATE_BSS
bool "BSS section is in a different memory region from text"
help
-- 
2.17.1

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

[U-Boot] Fwd: Resend: Pull request for UEFI system for v2019.04-rc4 (2)

[Heinrich Schuchardt]

 Forwarded Message 
Subject: Resend: Pull request for UEFI system for v2019.04-rc4 (2)
Date: Mon, 11 Mar 2019 19:30:46 +0100
From: Heinrich Schuchardt 
To: Tom Rini , Alexander Graf ,
Takahiro Akashi , Simon Glass
, Bin Meng , Matthias Brugger


(Now with the correct sender address)

The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993:

  Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500)

are available in the Git repository at:

  https://github.com/xypron2/u-boot.git tag tag efi-2019-04-rc4-2

for you to fetch changes up to 3eeb09b4c06fd6eb5c724b21cd2ac538fc015a31:

  x86: Add efi runtime reset (2019-03-11 00:44:42 +0100)

Primary key fingerprint:
6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4

Fix an error with the serial communication on boards with a very small
UART buffer which leads to a stalled system.

Provide an X86 reset driver for the UEFI runtime.

Travis CI:
https://travis-ci.org/xypron2/u-boot/builds/504644624


Alexander Graf (1):
  x86: Add efi runtime reset

Matthias Brugger (1):
  efi_loader: Fix serial console size detection

 drivers/sysreset/sysreset_x86.c | 23 ++-
 lib/efi_loader/efi_console.c| 62
+++---
 2 files changed, 57 insertions(+), 28 deletions(-)

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

[U-Boot] [PATCH] armv7R: K3: am654: Trigger panic on DDR init failures

[Andreas Dannenberg]

When initializing DDR from R5 SPL trigger U-Boot's panic facility
rather than simply returning from the board init function as there
is little point continuing code execution. Further, as panic implies
a board reset, so using it might potentially allow to recover from
this error in certain cases such as when the init failure was caused
by a temporary glitch of some sorts.

Signed-off-by: Andreas Dannenberg 
---
 arch/arm/mach-k3/am6_init.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index a5553190b4..77cd15f388 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -83,10 +83,8 @@ void board_init_f(ulong dummy)
 
 #ifdef CONFIG_K3_AM654_DDRSS
ret = uclass_get_device(UCLASS_RAM, 0, &dev);
-   if (ret) {
-   printf("DRAM init failed: %d\n", ret);
-   return;
-   }
+   if (ret)
+   panic("DRAM init failed: %d\n", ret);
 #endif
 }
 
-- 
2.17.1

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

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Joris Offouga]

Le 11/03/2019 à 20:04, Fabio Estevam a écrit :

Hi Joris,

On Mon, Mar 11, 2019 at 3:27 PM Joris Offouga  wrote:


I agree with you, but I have not managed to find the bug, Fabio also
searched and did not find. If I can get help of course I will look for
more, being a junior I wait for advice and help if possible.

I haven't had a chance to debug this issue yet. Since this affects
only when using serial download mode, let's keep this commit and we
can debug it.

Let's focus on the conversion of this board to DM for now.


Okay thanks, the last error to be able to send the serie of the dm,

it is the SPL which does not find the U-Boot in emmc



Thanks

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

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Tom Rini]

On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> > wrote:
> > 
> > > 
> > > From: "Ang, Chee Hong" 
> > > 
> > > Currently u-boot only support standard PSCI functions for power
> > > management
> > > and lack of convenient method to allow the users to extend the PSCI
> > > functions
> > > to support platform specific services. Most of the u-boot users
> > > still rely
> > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > management and
> > > platform specific PSCI services.
> > > The purpose of this patchsets is to allow u-boot users to support
> > > their
> > > own platform specific secure SMC/PSCI services without making any
> > > SMC calls to ATF. This will benefit the users who need to use u-
> > > boot as the
> > > only bootloader and secure service provider without relying on ATF.
> > > 
> > > Below is a simple code example for adding your own PSCI functions:
> > > 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > 
> > > #define PSCI_SMC64_FUNC_ID1   0xC201
> > > #define PSCI_SMC64_FUNC_ID2   0xC202
> > > 
> > > static void __secure psci_plat_specific_func1(unsigned long
> > > function_id)
> > > {
> > >   /* Your code for handling the SMC/PSCI platform specific
> > > service 1 */
> > > }
> > > 
> > > static void __secure psci_plat_specific_func2(unsigned long
> > > function_id)
> > > {
> > >   /* Your code for handling the SMC/PSCI platform specific
> > > service 2 */
> > > }
> > > 
> > > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > >      psci_plat_specific_func1);
> > > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > >      psci_plat_specific_func2);
> > > 
> > > Ang, Chee Hong (1):
> > >   ARMv8: Disable fwcall when PSCI is enabled
> > > 
> > > Chee Hong Ang (1):
> > >   ARMv8: Allow SiP service extensions on top of PSCI code
> > Conceptually, I suppose this is a logical step.  In specifics, would
> > we
> > want to make this functionality opt-in, or no, that doesn't make
> > sense?
> > 
> Allowing user to add platform specific service is part of SMC/PSCI
> specification as specifed in ARM document (Table 2-1):
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_
> SMC_Calling_Convention.pdf
> 
> So I think this functionality should be part of the standard PSCI/SMC
> implementation. Currently u-boot only support standard PSCI call which
> is:
> --
> | 0x8400-0x841F  | PSCI 32-bit calls |
> | 0xC400-0xC41F  | PSCI 64-bit calls |
> --
> 
> My implementation do not affect or alter the behavior of any existing
> standard PSCI calls.
> 
> Users can simply add their own platform specific services by using the
> service call range as below:
> 
> | 0xC200-0xC200 | SMC64: SiP Service Calls |
> | 0xC300-0xC300 | SMC64: OEM Service Calls |
> 
> 
> For complete service call ranges please refer to Table 6-2 in the ARM
> document.

OK, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Mon, Mar 11, 2019 at 11:05:48PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This includes the following changes for v2019.04:
> 
> - ACPI changes and fixes to Intel Tangier/Edison
> - i8254 beeper fixes
> 
> The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993:
> 
>   Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 3592965aff313a379f6f10faa05c997391c5dd82:
> 
>   x86: crownbay: Enable the beeper sound driver (2019-03-11 22:55:01 +0800)
> 

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

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

[Tom Rini]

On Sun, Mar 10, 2019 at 02:26:04PM +0100, Marek Vasut wrote:

> More gen2/gen3 fixes.
> 
> The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993:
> 
>   Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 3a4511ce4ad9d0955066d47ef3d227fe97208f81:
> 
>   ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N (2019-03-09
> 17:57:04 +0100)
> 

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

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

[Tom Rini]

On Sun, Mar 10, 2019 at 02:27:31PM +0100, Marek Vasut wrote:

> Arria10 DRAM fixes and Gen5 cache fixes.
> 
> The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993:
> 
>   Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to 88c3bb49e1bf2b808cbad1fbdeda09480ae580a7:
> 
>   ddr: socfpga: Clean up ddr_setup() (2019-03-09 23:25:19 +0100)
> 

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

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Otavio Salvador]

On Mon, Mar 11, 2019 at 4:05 PM Fabio Estevam  wrote:

> On Mon, Mar 11, 2019 at 3:27 PM Joris Offouga 
> wrote:
>
> > I agree with you, but I have not managed to find the bug, Fabio also
> > searched and did not find. If I can get help of course I will look for
> > more, being a junior I wait for advice and help if possible.
>
> I haven't had a chance to debug this issue yet. Since this affects
> only when using serial download mode, let's keep this commit and we
> can debug it.
>
> Let's focus on the conversion of this board to DM for now.
>

I agreed, reverting it for now and finish the convertion so we can look at
it later.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Fabio Estevam]

Hi Joris,

On Mon, Mar 11, 2019 at 3:27 PM Joris Offouga  wrote:

> I agree with you, but I have not managed to find the bug, Fabio also
> searched and did not find. If I can get help of course I will look for
> more, being a junior I wait for advice and help if possible.

I haven't had a chance to debug this issue yet. Since this affects
only when using serial download mode, let's keep this commit and we
can debug it.

Let's focus on the conversion of this board to DM for now.

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

Re: [U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

[Eugeniu Rosca]

On Mon, Mar 11, 2019 at 07:37:53PM +0100, Marek Vasut wrote:
> On 3/11/19 4:01 PM, Eugeniu Rosca wrote:
> > On Sat, Mar 09, 2019 at 05:58:03PM +0100, Marek Vasut wrote:
> > [..]
> > 
> >> Applied, thanks.
> >>
> >> -- 
> >> Best regards,
> >> Marek Vasut
> > 
> > JFTR, apparently on a parallel track, Renesas pushed same changes to
> > rcar-3.9.3.rc2 via:
> >  - https://github.com/renesas-rcar/u-boot/commit/6013d5005e5b ("ARM:
> >dts: rmobile: Fix duplicate definition SDHI on M3N")
> >  - https://github.com/renesas-rcar/u-boot/commit/fcb60eaeca09 ("ARM:
> >dts: rmobile: Fix duplicate definition USB on M3N")
> 
> Thanks for the heads up. I think all should be in order with your patch,
> right ?

The mentioned rcar-3.9.3.rc2 commits are equal (if squashed) to this
patch, which means Renesas went through the same problems internally and
fixed them the same way.

No, I don't have any concerns about my patch.

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

Re: [U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

[Marek Vasut]

On 3/11/19 4:01 PM, Eugeniu Rosca wrote:
> On Sat, Mar 09, 2019 at 05:58:03PM +0100, Marek Vasut wrote:
> [..]
> 
>> Applied, thanks.
>>
>> -- 
>> Best regards,
>> Marek Vasut
> 
> JFTR, apparently on a parallel track, Renesas pushed same changes to
> rcar-3.9.3.rc2 via:
>  - https://github.com/renesas-rcar/u-boot/commit/6013d5005e5b ("ARM:
>dts: rmobile: Fix duplicate definition SDHI on M3N")
>  - https://github.com/renesas-rcar/u-boot/commit/fcb60eaeca09 ("ARM:
>dts: rmobile: Fix duplicate definition USB on M3N")

Thanks for the heads up. I think all should be in order with your patch,
right ?

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

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Joris Offouga]

Le 11/03/2019 à 17:52, Stefano Babic a écrit :

Hi Joris,


Hi Stephano,



On 10/03/19 19:52, Joris Offouga wrote:

This reverts commit 9e3c0174da842dd88f5feaffbf843ba332233897.
This commit causes the crash of U-Boot when loaded with imx-usb-loader
---
  board/technexion/pico-imx7d/pico-imx7d.c | 55 
  configs/pico-hobbit-imx7d_defconfig  |  1 -
  configs/pico-imx7d_defconfig |  1 -
  configs/pico-pi-imx7d_defconfig  |  1 -
  include/configs/pico-imx7d.h | 12 ---
  5 files changed, 70 deletions(-)


This appears to me too simplistic - if something is not working, drop
it. Is there any known reason why it crashes when loaded from
imx-usb-loader ? It sounds like that not the whole u-boot.img is loaded
and reducing the size does not crash, but it is not a solution.

Anyway, Vanessa / Otavio are the Maintainer for these sets of boards. If
they decide this must be revert, I won't fight against.

Best regards,
Stefano Babic


I agree with you, but I have not managed to find the bug, Fabio also 
searched and did not find. If I can get help of course I will look for 
more, being a junior I wait for advice and help if possible.


Best Regards,

Joris Offouga




diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
b/board/technexion/pico-imx7d/pico-imx7d.c
index 767d13d..53e1469 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -39,16 +39,8 @@ DECLARE_GLOBAL_DATA_PTR;
  #define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
  
-

-#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
-PAD_CTL_DSE_3P3V_49OHM)
-
-#define LCD_SYNC_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
- PAD_CTL_DSE_3P3V_196OHM)
-
  #ifdef CONFIG_SYS_I2C_MXC
  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
-
  /* I2C4 for PMIC */
  static struct i2c_pads_info i2c_pad_info4 = {
.scl = {
@@ -254,58 +246,11 @@ int board_early_init_f(void)
return 0;
  }
  
-#ifdef CONFIG_VIDEO_MXS

-static iomux_v3_cfg_t const lcd_pads[] = {
-   MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_ENABLE__LCD_ENABLE | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
-   MX7D_PAD_LCD_HSYNC__LCD_HSYNC | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
-   MX7D_PAD_LCD_VSYNC__LCD_VSYNC | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
-   MX7D_PAD_LCD_DATA00__LCD_DATA0 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA01__LCD_DATA1 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA02__LCD_DATA2 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA03__LCD_DATA3 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA04__LCD_DATA4 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA05__LCD_DATA5 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA06__LCD_DATA6 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA07__LCD_DATA7 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA08__LCD_DATA8 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA09__LCD_DATA9 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA10__LCD_DATA10 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA11__LCD_DATA11 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA12__LCD_DATA12 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA13__LCD_DATA13 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA14__LCD_DATA14 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA15__LCD_DATA15 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA16__LCD_DATA16 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA17__LCD_DATA17 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA18__LCD_DATA18 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA19__LCD_DATA19 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA20__LCD_DATA20 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA21__LCD_DATA21 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA22__LCD_DATA22 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_LCD_DATA23__LCD_DATA23 | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_GPIO1_IO06__GPIO1_IO6  | MUX_PAD_CTRL(LCD_PAD_CTRL),
-   MX7D_PAD_GPIO1_IO11__GPIO1_IO11 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-void setup_lcd(void)
-{
-   imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
-   /* Set Brightness to high */
-   gpio_direction_output(IMX_GPIO_NR(1, 11) , 1);
-   /* Set LCD enable to high */
-   gpio_direction_output(IMX_GPIO_NR(1, 6) , 1);
-}
-#endif
-
  int board_init(void)
  {
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
  
-#ifdef CONFIG_VIDEO_MXS

-   setup_lcd();
-#endif
  #ifdef CONFIG_FEC_MXC
setup_fec();
  #endif
diff --git a/configs/pico-hobbit-imx7d_defconfig 
b/configs/pico-hobbit-imx7d_defconfig
index f58d517..cb4a6bf 100644
--- a/configs/pico-hobbit-imx7d_defconfig
+++ b/config

Re: [U-Boot] Revert "Ensure device tree DTS is compiled"

[Masahiro Yamada]

Hi Simon,


On Mon, Mar 11, 2019 at 6:59 AM Simon Glass  wrote:
>
> Hi Tom, Masahiro,
>
> On Sat, 9 Mar 2019 at 10:42, Tom Rini  wrote:
> >
> > On Sun, Mar 10, 2019 at 01:07:48AM +0900, Masahiro Yamada wrote:
> > > Hi Tom,
> > >
> > >
> > > On Sat, Mar 9, 2019 at 8:04 AM Tom Rini  wrote:
> > > >
> > > > On Thu, Mar 07, 2019 at 11:13:52PM +0900, Masahiro Yamada wrote:
> > > >
> > > > > This reverts commit 27cb7300ffda7a3f1581f0f5a2d3bfe59b97ad67.
> > > > >
> > > > > I am not sure if I correctly understood the log of commit 27cb7300ffda
> > > > > ("Ensure device tree DTS is compiled"), but the code-diff looks like
> > > > > it was trying to solve the missed re-compilation when .dts was 
> > > > > modified.
> > > > >
> > > > > Recently, commit 2737dfe096b6 ("kbuild: make arch-dtbs target PHONY")
> > > > > fixed the issue in a more correct and more complete way.
> > > > >
> > > > > Anyway, since the former commit, we see a clumsy log like this:
> > > > >
> > > > >   make[2]: 'arch/sandbox/dts/sandbox.dtb' is up to date
> > > > >
> > > > > So, let's revert it.
> > > > >
> > > > > Signed-off-by: Masahiro Yamada 
> > > >
> > > > This causes tons of breakage like:
> > > >arm:  +   rpi_0_w
> > > > +(rpi_0_w)
> > > > +(rpi_0_w) Device Tree Source is not correctly specified.
> > > > +(rpi_0_w) Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> > > > +(rpi_0_w) or build with 'DEVICE_TREE=' argument
> > > > +(rpi_0_w) make[2]: *** [arch/arm/dts/bcm2835-rpi-zero-w.dtb] Error 1
> > > > +(rpi_0_w) make[1]: *** [dts] Error 2
> > > > +(rpi_0_w) make: *** [sub-make] Error 2
> > > >
> > >
> > >
> > > This is because arch/arm/dts/Makefile
> > > has no entry for bcm2835-rpi-zero-w.dtb.
> > >
> > >
> > >
> > >
> > > The following patch should fix the error
> > >
> > >
> > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > index 2a040b2..5540f1b 100644
> > > --- a/arch/arm/dts/Makefile
> > > +++ b/arch/arm/dts/Makefile
> > > @@ -582,6 +582,7 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > > bcm2835-rpi-b-plus.dtb \
> > > bcm2835-rpi-b-rev2.dtb \
> > > bcm2835-rpi-b.dtb \
> > > +   bcm2835-rpi-zero-w.dtb \
> > > bcm2836-rpi-2-b.dtb \
> > > bcm2837-rpi-3-b.dtb
> > >
> > >
> > >
> > >
> > >
> > > The reverted commit was hiding the issue.
> > >
> > > I believe DTB files should be explicitly associated
> > > with CONFIG option in Makefile.
> > > U-Boot used to work that way, and so does Linux.
> > >
> > >
> > > I do not know how may boards are broken now, but
> > > the right thing to do is to add dtb entries to Makefile,
> > > the revert the bad commit.
> >
> > OK, that sounds good.  But it's a non-trivial number of boards to fix,
> > so it's a real series to be put on the TODO list then.  Thanks for
> > explaining!
>
> If you are suggesting that we should have a separate CONFIG option for
> every DT, I don't agree:

I do not mean that.

See my patch.


> > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > index 2a040b2..5540f1b 100644
> > > --- a/arch/arm/dts/Makefile
> > > +++ b/arch/arm/dts/Makefile
> > > @@ -582,6 +582,7 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > > bcm2835-rpi-b-plus.dtb \
> > > bcm2835-rpi-b-rev2.dtb \
> > > bcm2835-rpi-b.dtb \
> > > +   bcm2835-rpi-zero-w.dtb \
> > > bcm2836-rpi-2-b.dtb \
> > > bcm2837-rpi-3-b.dtb


I am suggesting to add a missing DTB to the existing CONFIG.

CONFIG_ARCH_BCM283X is a platform CONFIG, not per-board CONFIG.


Each platform should have a platform or SoC CONFIG option.




> 1. It adds more CONFIGs for no other purpose, or makes use of TARGET
> configs which we try to avoid using
> 2. It reduces the testing of DT files for related builds. E.g. you can
> change something in a common .dtsi file which works fine for one board
> but breaks another, and you only find out when you build all the
> boards.
>
> Sorry if I have the wrong end of the stick.
>
> Regards,
> Simon
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot


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

Re: [U-Boot] [PATCH v2] imx8mq_evk_defconfig: Enable pinctrl driver

[Chris Spencer]

On Sat, 2 Mar 2019 at 06:27, Peng Fan  wrote:
> > On Mon, 4 Feb 2019 at 10:05, Chris Spencer  wrote:
> > > From: Chris Spencer 
> > >
> > > The Ethernet controller is not able to initialise correctly without
> > > the pinctrl driver.
> > >
> > > This config setting was enabled in the initial version of this file,
> > > but was removed by a savedefconfig resync because the parameter did
> > > not actually exist at that point.
> > >
> > > Fixes: 1bac199e8c87 ("configs: Resync with savedefconfig")
> > > Signed-off-by: Chris Spencer 
> > > Reviewed-by: Fabio Estevam 
> > > ---
> > > Depends on this patch:
> > >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> > >
> > chwork.ozlabs.org%2Fpatch%2F1031817%2F&data=02%7C01%7Cpeng.f
> > an%40n
> > >
> > xp.com%7Cffae7c0ab2494a20159008d69e40ed2d%7C686ea1d3bc2b4c6fa92
> > cd99c5c
> > >
> > 301635%7C0%7C0%7C636870399030578148&sdata=0tJenqE8zP4dFhLs
> > HJJ5WO3n
> > > Tmiyz%2FAZWeclKFp8wso%3D&reserved=0
> > >
> > > Changes in v2:
> > > - Added Fabio's Reviewed-by.
> > > - Corrected From address.
> >
> > Since there hasn't been any activity on the i.MX8MM patch series for a 
> > while,
> > I wonder if the pinctrl driver [1] could be committed in isolation? This 
> > patch
> > could then be applied so we can get the Ethernet working on the i.MX8MQ.
> >
>
> The blocking issue for i.MX8MM is clock part, for the pinctrl that
> could be reused by i.MX8MQ, I think it could be committed, but need Stefano
> to decide.
>
> Regards,
> Peng.

Any thoughts on this, Stefano? Would be good to get the pinctrl driver
+ defconfig change into 2019.04 if we can.

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

Re: [U-Boot] [PATCH v4 07/12] drivers: spi: cf_spi: convert to driver model

[Jagan Teki]

On Sun, Mar 10, 2019 at 9:47 PM Angelo Dureghello  wrote:
>
> Hi Jagan,
>
> thanks for your comments,
>
> On Fri, Mar 08, 2019 at 11:30:56AM +0530, Jagan Teki wrote:
> > On Mon, Dec 17, 2018 at 1:06 AM Angelo Dureghello  wrote:
> > >
> > > Converting to driver model and removes non-dm code.
> > >
> > > Reviewed-by: Simon Glass 
> > > Signed-off-by: Angelo Dureghello 
> > > ---
> > > Changes for v2:
> > > - removed non DM code part
> > > - add default setup of CTAR registers
> > > - add DT CTAR register setup support
> > > Changes for v3:
> > > - changed commit head
> > > - removed spi_slave reference
> > > - add #ifdefs for the case OF_PLATDATA is used
> > > Changes for v4:
> > > - remove all internal static functions that are no more needed including
> > >   their code in the standard driver methods
> > > - add helper macro for ctrl setup
> > > - fix wrong fifo level check on spi tx
> > > - move code inside same #if (avoid multiple #if on same option)
> > > - removed externals and moved bus control code here
> > > ---
> > >  drivers/spi/cf_spi.c| 539 
> > >  include/dm/platform_data/spi_coldfire.h |  29 ++
> > >  2 files changed, 401 insertions(+), 167 deletions(-)
> > >  create mode 100644 include/dm/platform_data/spi_coldfire.h
> > >
> > > diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
> > > index 522631cbbf..3d02c87637 100644
> > > --- a/drivers/spi/cf_spi.c
> > > +++ b/drivers/spi/cf_spi.c
> > > @@ -6,23 +6,31 @@
> > >   *
> > >   * Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
> > >   * TsiChung Liew (tsi-chung.l...@freescale.com)
> > > + *
> > > + * Support for DM and DT, non-DM code removed.
> > > + * Copyright (C) 2018 Angelo Dureghello 
> > > + *
> > > + * TODO: fsl_dspi.c should work as a driver for the DSPI module.
> > >   */
> > >
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > >
> > > -struct cf_spi_slave {
> > > -   struct spi_slave slave;
> > > +struct coldfire_spi_priv {
> > > +   struct dspi *regs;
> > > +   struct gpio *gpio_regs;
> > > uint baudrate;
> > > +   int mode;
> > > int charbit;
> > >  };
> > >
> > > -extern void cfspi_port_conf(void);
> > > -extern int cfspi_claim_bus(uint bus, uint cs);
> > > -extern void cfspi_release_bus(uint bus, uint cs);
> > > -
> > >  DECLARE_GLOBAL_DATA_PTR;
> > >
> > >  #ifndef CONFIG_SPI_IDLE_VAL
> > > @@ -33,149 +41,267 @@ DECLARE_GLOBAL_DATA_PTR;
> > >  #endif
> > >  #endif
> > >
> > > -#if defined(CONFIG_CF_DSPI)
> > >  /* DSPI specific mode */
> > >  #define SPI_MODE_MOD   0x0020
> > >  #define SPI_DBLRATE0x0010
> > >
> > > -static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave 
> > > *slave)
> > > +#define MCF_DSPI_MAX_CTAR_REGS 8
> > > +
> > > +/* Default values */
> > > +#define MCF_DSPI_DEFAULT_SCK_FREQ  1000
> > > +#define MCF_DSPI_DEFAULT_MAX_CS4
> > > +#define MCF_DSPI_DEFAULT_MODE  0
> > > +
> > > +#define MCF_DSPI_DEFAULT_CTAR  (DSPI_CTAR_TRSZ(7) | \
> > > +   DSPI_CTAR_PCSSCK_1CLK | \
> > > +   DSPI_CTAR_PASC(0) | \
> > > +   DSPI_CTAR_PDT(0) | \
> > > +   DSPI_CTAR_CSSCK(0) | \
> > > +   DSPI_CTAR_ASC(0) | \
> > > +   DSPI_CTAR_DT(1) | \
> > > +   DSPI_CTAR_BR(6))
> > > +
> > > +#define setup_ctrl(ctrl, cs)   ((ctrl & 0xFF00) | ((1 << cs) << 16))
> > > +
> > > +static inline void cfspi_tx(struct coldfire_spi_priv *cfspi,
> > > +   u32 ctrl, u16 data)
> > >  {
> > > -   return container_of(slave, struct cf_spi_slave, slave);
> > > +   /*
> > > +* Need to check fifo level here
> > > +*/
> > > +   while ((readl(&cfspi->regs->sr) & 0xF000) >= 0x4000)
> > > +   ;
> > > +
> > > +   writel(ctrl | data, &cfspi->regs->tfr);
> > >  }
> > >
> > > -static void cfspi_init(void)
> > > +static inline u16 cfspi_rx(struct coldfire_spi_priv *cfspi)
> > >  {
> > > -   volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
> > > -
> > > -   cfspi_port_conf();  /* port configuration */
> > > +   while ((readl(&cfspi->regs->sr) & 0x00F0) == 0)
> > > +   ;
> > >
> > > -   dspi->mcr = DSPI_MCR_MSTR | DSPI_MCR_CSIS7 | DSPI_MCR_CSIS6 |
> > > -   DSPI_MCR_CSIS5 | DSPI_MCR_CSIS4 | DSPI_MCR_CSIS3 |
> > > -   DSPI_MCR_CSIS2 | DSPI_MCR_CSIS1 | DSPI_MCR_CSIS0 |
> > > -   DSPI_MCR_CRXF | DSPI_MCR_CTXF;
> > > +   return readw(&cfspi->regs->rfr);
> > > +}
> >
> > Look like you include wait header and forgot to implement
> > wait_for_bit_* logic which I commented before.
> >
>
> I tried to use it, this is why i forgot the 

[U-Boot] Pull request: u-boot-sunxi/master

[Jagan Teki]

Hi Tom, 

Please pull this PR.

Summary:
- axp818 fix
- fix warnings for ethernet clock code

The following changes since commit f18b7b2798cc37b613b5d3dda2e1461857a913b8:

  Merge branch 'master' of git://git.denx.de/u-boot-spi (2019-03-06 20:25:09 
-0500)

are available in the Git repository at:

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

for you to fetch changes up to aefc0b7a60b9147b79b7a735c045e28daba712f1:

  clk: sunxi: h3: Implement EPHY CLK and RESET (2019-03-09 13:16:35 +0530)


Jagan Teki (3):
  clk: sunxi: Implement A10 EMAC clocks
  clk: sunxi: Implement EMAC, GMAC clocks, resets
  clk: sunxi: h3: Implement EPHY CLK and RESET

Ondrej Jirman (1):
  power: axp818: Fix typo in axp_set_dldo

 drivers/clk/sunxi/clk_a10.c  | 1 +
 drivers/clk/sunxi/clk_a10s.c | 1 +
 drivers/clk/sunxi/clk_a31.c  | 2 ++
 drivers/clk/sunxi/clk_a64.c  | 2 ++
 drivers/clk/sunxi/clk_a83t.c | 2 ++
 drivers/clk/sunxi/clk_h3.c   | 6 ++
 drivers/clk/sunxi/clk_h6.c   | 4 
 drivers/clk/sunxi/clk_r40.c  | 3 +++
 drivers/power/axp818.c   | 2 +-
 9 files changed, 22 insertions(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/7] common: Implement A/B metadata

[Eugeniu Rosca]

FWIW, below are some dangling struct name references due to:
 - s/bootloader_message/andr_bl_msg/
 - s/bootloader_message_ab/andr_bl_msg_ab/
 - s/bootloader_control/andr_bl_control/

On Mon, Feb 18, 2019 at 5:25 PM Igor Opaniuk  wrote:
[..]
> + * uncrypt. Move it into struct bootloader_message_ab to avoid the
[..]
> +* 1184-byte so that the entire bootloader_message struct rounds up
[..]
> + * stays after struct bootloader_message, which should be managed by
[..]
> + * not mandatory, to use 'struct bootloader_control' described below.
[..]
> + * be put in the 'slot_suffix' field of the 'bootloader_message'
[..]
> + * 'bootloader_control' structure to store the A/B metadata, but not

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

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Stefano Babic]

Hi Joris,

On 10/03/19 19:52, Joris Offouga wrote:
> This reverts commit 9e3c0174da842dd88f5feaffbf843ba332233897.
> This commit causes the crash of U-Boot when loaded with imx-usb-loader
> ---
>  board/technexion/pico-imx7d/pico-imx7d.c | 55 
> 
>  configs/pico-hobbit-imx7d_defconfig  |  1 -
>  configs/pico-imx7d_defconfig |  1 -
>  configs/pico-pi-imx7d_defconfig  |  1 -
>  include/configs/pico-imx7d.h | 12 ---
>  5 files changed, 70 deletions(-)
> 

This appears to me too simplistic - if something is not working, drop
it. Is there any known reason why it crashes when loaded from
imx-usb-loader ? It sounds like that not the whole u-boot.img is loaded
and reducing the size does not crash, but it is not a solution.

Anyway, Vanessa / Otavio are the Maintainer for these sets of boards. If
they decide this must be revert, I won't fight against.

Best regards,
Stefano Babic

> diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
> b/board/technexion/pico-imx7d/pico-imx7d.c
> index 767d13d..53e1469 100644
> --- a/board/technexion/pico-imx7d/pico-imx7d.c
> +++ b/board/technexion/pico-imx7d/pico-imx7d.c
> @@ -39,16 +39,8 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
>   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
>  
> -
> -#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
> -  PAD_CTL_DSE_3P3V_49OHM)
> -
> -#define LCD_SYNC_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
> -   PAD_CTL_DSE_3P3V_196OHM)
> -
>  #ifdef CONFIG_SYS_I2C_MXC
>  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> -
>  /* I2C4 for PMIC */
>  static struct i2c_pads_info i2c_pad_info4 = {
>   .scl = {
> @@ -254,58 +246,11 @@ int board_early_init_f(void)
>   return 0;
>  }
>  
> -#ifdef CONFIG_VIDEO_MXS
> -static iomux_v3_cfg_t const lcd_pads[] = {
> - MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_ENABLE__LCD_ENABLE | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
> - MX7D_PAD_LCD_HSYNC__LCD_HSYNC | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
> - MX7D_PAD_LCD_VSYNC__LCD_VSYNC | MUX_PAD_CTRL(LCD_SYNC_PAD_CTRL),
> - MX7D_PAD_LCD_DATA00__LCD_DATA0 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA01__LCD_DATA1 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA02__LCD_DATA2 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA03__LCD_DATA3 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA04__LCD_DATA4 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA05__LCD_DATA5 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA06__LCD_DATA6 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA07__LCD_DATA7 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA08__LCD_DATA8 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA09__LCD_DATA9 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA10__LCD_DATA10 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA11__LCD_DATA11 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA12__LCD_DATA12 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA13__LCD_DATA13 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA14__LCD_DATA14 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA15__LCD_DATA15 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA16__LCD_DATA16 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA17__LCD_DATA17 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA18__LCD_DATA18 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA19__LCD_DATA19 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA20__LCD_DATA20 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA21__LCD_DATA21 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA22__LCD_DATA22 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_LCD_DATA23__LCD_DATA23 | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_GPIO1_IO06__GPIO1_IO6  | MUX_PAD_CTRL(LCD_PAD_CTRL),
> - MX7D_PAD_GPIO1_IO11__GPIO1_IO11 | MUX_PAD_CTRL(NO_PAD_CTRL),
> -};
> -
> -void setup_lcd(void)
> -{
> - imx_iomux_v3_setup_multiple_pads(lcd_pads, ARRAY_SIZE(lcd_pads));
> - /* Set Brightness to high */
> - gpio_direction_output(IMX_GPIO_NR(1, 11) , 1);
> - /* Set LCD enable to high */
> - gpio_direction_output(IMX_GPIO_NR(1, 6) , 1);
> -}
> -#endif
> -
>  int board_init(void)
>  {
>   /* address of boot parameters */
>   gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
>  
> -#ifdef CONFIG_VIDEO_MXS
> - setup_lcd();
> -#endif
>  #ifdef CONFIG_FEC_MXC
>   setup_fec();
>  #endif
> diff --git a/configs/pico-hobbit-imx7d_defconfig 
> b/configs/pico-hobbit-imx7d_defconfig
> index f58d517..cb4a6bf 100644
> --- a/configs/pico-hobbit-imx7d_defconfig
> +++ b/configs/pico-hobbit-imx7d_defconfig
> @@ -57,5 +57,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL"
>  CONFIG_USB_GADGET_VENDOR_NUM=0x0525
>  CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
>  CONFIG_CI_UDC=y
> -CONFIG_VIDEO=y
>  CONFIG_OF_LIBFDT

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Offouga Joris]

> Le 11 mars 2019 à 14:42, Fabio Estevam  a écrit :
> 
> Hi Joris,
> 
>> On Sun, Mar 10, 2019 at 3:52 PM Joris Offouga  wrote:
>> 
>> This reverts commit 9e3c0174da842dd88f5feaffbf843ba332233897.
>> This commit causes the crash of U-Boot when loaded with imx-usb-loader
> 
> Your Signed-off-by line is missing.
Hi Fabio, 

i add for v2 

Thanks 


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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

> -Original Message-
> From: Palmer Dabbelt 
> Sent: Monday, March 11, 2019 5:26 PM
> To: Anup Patel 
> Cc: sch...@suse.de; Atish Patra ;
> a...@brainfault.org; lukas.a...@aisec.fraunhofer.de; Paul Walmsley
> ; ag...@suse.de; u-boot@lists.denx.de;
> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com;
> r...@andestech.com; s...@denx.de
> Subject: RE: [PATCH v2 0/9] SMP support for RISC-V
> 
> On Thu, 07 Mar 2019 19:37:30 PST (-0800), Anup Patel wrote:
> >
> >
> >> -Original Message-
> >> From: Andreas Schwab 
> >> Sent: Thursday, March 7, 2019 2:50 PM
> >> To: Anup Patel 
> >> Cc: Atish Patra ; Anup Patel
> >> ; Auer, Lukas ;
> >> paul.walms...@sifive.com; ag...@suse.de; u-boot@lists.denx.de;
> >> bar...@tkos.co.il; daniel.schwierz...@gmail.com;
> bmeng...@gmail.com;
> >> r...@andestech.com; s...@denx.de; pal...@sifive.com
> >> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> >>
> >> On Mär 07 2019, Anup Patel  wrote:
> >>
> >> > Like I mentioned, there is no functional issue with this series.
> >> > The warm-boot issues were fixed in OpenSBI.
> >> >
> >> > @Andreas, please try at your end.
> >>
> >> As long as issue#65 isn't fixed opensbi is mostly a no-go for me.  At
> >> least it gives me more reasons to press the reset button. :-)
> >
> > The reset button works fine for me an Atish. I am sure it works fine
> > for lot of other folks too.
> >
> > BTW, as-per discussion with SiFive folks the reset button on Unleashed
> > Board is not much tested and it can misbehave on certain boards. It is
> > quite possible that you might have a "flaky" board.
> 
> I don't think the reset button differs between boards.  As far as I know, the
> issues are really just that it doesn't reset everything -- specifically some 
> of
> the IP on the chip (clock, power, JTAG) isn't reset and nothing on the board
> (SD, ethernet, PCIe, etc) is reset.  This frequently results in flakiness when
> debugging drivers, but the cores and memory system should all be OK.
> 
> Is that issue 65 on github.com/opensbi?  If so it clearly says this isn't a 
> reset
> button issue.

The issue#65 on githuh.com/opensbi is not a clearly defined and it went in
various directions. We tried various things suggested by Andreas and we were
only able to replicate issue with reset-button press. This fixed now and
reset-button press works perfectly fine with OpenSBI.

Apart from reset-button thingy, we tried all other things reported by Andreas
but we were not able to reproduce issue at our end.

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

Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Ang, Chee Hong]

On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> wrote:
> 
> > 
> > From: "Ang, Chee Hong" 
> > 
> > Currently u-boot only support standard PSCI functions for power
> > management
> > and lack of convenient method to allow the users to extend the PSCI
> > functions
> > to support platform specific services. Most of the u-boot users
> > still rely
> > on ATF (ARM Trusted Firmware) to handle the standard power
> > management and
> > platform specific PSCI services.
> > The purpose of this patchsets is to allow u-boot users to support
> > their
> > own platform specific secure SMC/PSCI services without making any
> > SMC calls to ATF. This will benefit the users who need to use u-
> > boot as the
> > only bootloader and secure service provider without relying on ATF.
> > 
> > Below is a simple code example for adding your own PSCI functions:
> > 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > #define PSCI_SMC64_FUNC_ID1 0xC201
> > #define PSCI_SMC64_FUNC_ID2 0xC202
> > 
> > static void __secure psci_plat_specific_func1(unsigned long
> > function_id)
> > {
> > /* Your code for handling the SMC/PSCI platform specific
> > service 1 */
> > }
> > 
> > static void __secure psci_plat_specific_func2(unsigned long
> > function_id)
> > {
> > /* Your code for handling the SMC/PSCI platform specific
> > service 2 */
> > }
> > 
> > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> >    psci_plat_specific_func1);
> > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> >    psci_plat_specific_func2);
> > 
> > Ang, Chee Hong (1):
> >   ARMv8: Disable fwcall when PSCI is enabled
> > 
> > Chee Hong Ang (1):
> >   ARMv8: Allow SiP service extensions on top of PSCI code
> Conceptually, I suppose this is a logical step.  In specifics, would
> we
> want to make this functionality opt-in, or no, that doesn't make
> sense?
> 
Allowing user to add platform specific service is part of SMC/PSCI
specification as specifed in ARM document (Table 2-1):
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_
SMC_Calling_Convention.pdf

So I think this functionality should be part of the standard PSCI/SMC
implementation. Currently u-boot only support standard PSCI call which
is:
--
| 0x8400-0x841F  | PSCI 32-bit calls |
| 0xC400-0xC41F  | PSCI 64-bit calls |
--

My implementation do not affect or alter the behavior of any existing
standard PSCI calls.

Users can simply add their own platform specific services by using the
service call range as below:

| 0xC200-0xC200 | SMC64: SiP Service Calls |
| 0xC300-0xC300 | SMC64: OEM Service Calls |


For complete service call ranges please refer to Table 6-2 in the ARM
document.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-x86

[Bin Meng]

Hi Tom,

This includes the following changes for v2019.04:

- ACPI changes and fixes to Intel Tangier/Edison
- i8254 beeper fixes

The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993:

  Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500)

are available in the git repository at:

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

for you to fetch changes up to 3592965aff313a379f6f10faa05c997391c5dd82:

  x86: crownbay: Enable the beeper sound driver (2019-03-11 22:55:01 +0800)


Andy Shevchenko (5):
  x86: acpi: Add DMA descriptors for SPI5 on Intel Tangier
  x86: acpi: Add DMA descriptors for I2C1 on Intel Tangier
  x86: acpi: Not every platform has serial console a first device
  x86: edison: Use proper number of serial interface
  x86: edison: Add the rest of UARTs present on board

Bin Meng (4):
  x86: Make sure i8254 is setup correctly before generating beeps
  x86: Add a dtsi file for the pc speaker
  x86: coreboot: Add the missing pc speaker node in the device tree
  x86: crownbay: Enable the beeper sound driver

 arch/x86/dts/coreboot.dts   |  1 +
 arch/x86/dts/crownbay.dts   |  1 +
 arch/x86/dts/edison.dts | 22
--
 arch/x86/dts/pcspkr.dtsi|  5 +
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 14 ++
 arch/x86/lib/acpi_table.c   |  6 +++---
 arch/x86/lib/i8254.c|  4 
 configs/crownbay_defconfig  |  3 +++
 8 files changed, 51 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/dts/pcspkr.dtsi

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

Re: [U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

[Eugeniu Rosca]

On Sat, Mar 09, 2019 at 05:58:03PM +0100, Marek Vasut wrote:
[..]

> Applied, thanks.
> 
> -- 
> Best regards,
> Marek Vasut

JFTR, apparently on a parallel track, Renesas pushed same changes to
rcar-3.9.3.rc2 via:
 - https://github.com/renesas-rcar/u-boot/commit/6013d5005e5b ("ARM:
   dts: rmobile: Fix duplicate definition SDHI on M3N")
 - https://github.com/renesas-rcar/u-boot/commit/fcb60eaeca09 ("ARM:
   dts: rmobile: Fix duplicate definition USB on M3N")

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

Re: [U-Boot] [PATCH 3/4] x86: coreboot: Add the missing pc speaker node in the device tree

[Bin Meng]

On Mon, Mar 11, 2019 at 5:51 AM Simon Glass  wrote:
>
> On Tue, 26 Feb 2019 at 02:47, Bin Meng  wrote:
> >
> > This is currently missing and without it the i8254 beeper driver
> > won't work.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/dts/coreboot.dts | 1 +
> >  1 file changed, 1 insertion(+)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] x86: crownbay: Enable the beeper sound driver

[Bin Meng]

On Mon, Mar 11, 2019 at 5:51 AM Simon Glass  wrote:
>
> On Tue, 26 Feb 2019 at 02:47, Bin Meng  wrote:
> >
> > Use the i8254 sound driver to support creating simple beeps.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/dts/crownbay.dts  | 1 +
> >  configs/crownbay_defconfig | 3 +++
> >  2 files changed, 4 insertions(+)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] x86: Add a dtsi file for the pc speaker

[Bin Meng]

On Mon, Mar 11, 2019 at 5:51 AM Simon Glass  wrote:
>
> On Tue, 26 Feb 2019 at 02:47, Bin Meng  wrote:
> >
> > The pc speaker driven by the i8254 is generic enough to deserve
> > a single dtsi file to be included by boards that use it.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/dts/pcspkr.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> >  create mode 100644 arch/x86/dts/pcspkr.dtsi
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] x86: Make sure i8254 is setup correctly before generating beeps

[Bin Meng]

On Mon, Mar 11, 2019 at 5:51 AM Simon Glass  wrote:
>
> On Tue, 26 Feb 2019 at 02:47, Bin Meng  wrote:
> >
> > The i8254 timer control IO port (0x43) should be setup correctly
> > by using PIT counter 2 to generate beeps, however in U-Boot other
> > codes like TSC driver utilizes PIT for TSC frequency calibration
> > and configures the counter 2 to a different mode that does not
> > beep. Fix this by always ensuring the PIT counter 2 is correctly
> > initialized so that the i8254 beeper driver works as expected.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/lib/i8254.c | 4 
> >  1 file changed, 4 insertions(+)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq

[Bin Meng]

Hi Andy,

On Wed, Mar 6, 2019 at 7:09 PM Andy Shevchenko
 wrote:
>
> On Thu, Feb 28, 2019 at 11:29:50AM +0800, Bin Meng wrote:
> > On Thu, May 24, 2018 at 12:00 PM Bin Meng  wrote:
> > > On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeiner
> > >  wrote:
>
> > So to me this seems to match my understanding about EIST. If this is
> > true, then I can't explain why Christian's patch is needed since the
> > EIST is disabled on TunnelCreek by default and the processor should
> > already run at the highest performance.
>
> The some internal documents I found suggesting that first what one needs to do
> is to be sure that EIST is enabled / disabled by reading a bit from CPUID.
>

Correct. This is documented in the public Intel SDM too.

> (There is no mention of the exact bit, I'm guessing it might be 
> X86_FEATURE_EST)
>
> It also refers to IA32_MISC_ENABLE MSR, i.e. bit 20
> (MSR_IA32_MISC_ENABLE_SPEEDSTEP_LOCK_BIT) and bit 16
> (MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP_BIT), that firmware can set up
> accordingly.
>
> Hope this helps.
>

Thanks for the help. But I was looking for clarification on what
frequency the CPU is running at if EIST is disabled (the default
power-up state). Especially I suspect the Intel CPU is running at the
highest frequency when ESIT is disabled hence the highest performance.
Such details are not documented in the public Intel SDM. :(

> P.S. All names are implying Linux kernel source code.

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

Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support

[Bin Meng]

On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman  wrote:
>
> Kevin Hilman  writes:
>
> > Hi Anup,
> >
> > Anup Patel  writes:
> >
> >> This patchset adds SiFive Freedom Unleashed (FU540) support
> >> to RISC-V U-Boot.
> >>
> >> The patches are based upon latest U-Boot source tree
> >> (git://git.denx.de/u-boot.git) at commit id
> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >>
> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >> MACB Ethernet work fine on actual SiFive Unleashed board and
> >> QEMU sifive_u machine.
> >
> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> > and it worked fine.  Then, I moved it to a lab with a 100Mb switch,
> > and DHCP doesn't work anymore.
>
> And to be clear, neither does TFTP if setting static
> ipaddr/netmask/gatewayip etc.

Sound to me a bug of the GEM driver on SiFive FU540 board.

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

Re: [U-Boot] [PATCH 1/2] common: spl_fit: Default to IH_OS_U_BOOT if FIT_IMAGE_TINY enabled

[Marek Vasut]

On 3/11/19 9:08 AM, Abel Vesa wrote:
> If FIT_IMAGE_TINY is enabled, spl_fit_image_get_os returns -ENOTSUPP.
> In this case, we should default to IH_OS_U_BOOT not to IH_OS_INVALID.
> 
> Signed-off-by: Abel Vesa 
> ---
>  common/spl/spl_fit.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index db43626..b190612 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -491,6 +491,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>  
>   if (!spl_fit_image_get_os(fit, node, &os_type))
>   debug("Loadable is %s\n", genimg_get_os_name(os_type));
> + else
> + os_type = IH_OS_U_BOOT;

Don't you need if CONFIG_IS_ENABLED(FIT_IMAGE_TINY) around this new code ?

>   if (os_type == IH_OS_U_BOOT) {
>   spl_fit_append_fdt(&image_info, info, sector,
> 


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

Re: [U-Boot] [PATCH 4/4] Makefile: Correct logic for DM_SCSI + unconverted drivers check

[Tom Rini]

On Mon, Mar 11, 2019 at 01:29:23PM +0100, Stefan Roese wrote:

> When checking for boards that are enabling a SATA driver that isn't
> converted to DM yet we need to be sure to not also trip over boards that
> do set CONFIG_AHCI & CONFIG_BLK by itself, as that is not a bug.
> 
> This was detected when converting the Armada XP SATA driver sata_mv.c
> to DM with AHCI & BLK support. This warning is still printed without
> this patch applied here.
> 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Tom Rini 
> ---
>  Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index 26db4e7b59..896e0c3350 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -940,6 +940,7 @@ endif
>  endif
>  ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y)
>  ifneq ($(CONFIG_DM_SCSI),y)
> +ifneq ($(CONFIG_BLK)$(CONFIG_AHCI),yy)
>   @echo >&2 "= WARNING =="
>   @echo >&2 "This board does not use CONFIG_DM_SCSI. Please update"
>   @echo >&2 "the storage controller to use CONFIG_DM_SCSI before the 
> v2019.07 release."

OK, I think we need to properly clarify the logic, and perhaps I was
being too clever trying to catch all of the cases under drivers/ata that
aren't converted yet.  We have, after your patches, afaict:
- MVSATA_IDE
- DWC_AHSATA
- FSL_SATA
- SATA_SIL
- SATA_SIL3114

Of these, MVSATA_IDE has no further deps.  Everything else depends on
LIBATA.  Before SATA_MV was converted, everything that was converted
depends on DM_SCSI and AHCI.  So I made my messages / logic like the
above.  But perhaps the right answer really is:
1) MVSATA_IDE alone.
2) LIBATA && !AHCI

So... we can just re-work the second part of the check logic to be what
you added, as all converted drivers under drivers/ata will be both
BLK&&AHCI enabled.

And also as you note, it's not quite AHCI as the controller in question
here isn't AHCI-compatible, but is SATA, so a fixup / rename of some
CONFIG checks in code / Kconfig is in order, somewhere, but perhaps
after conversion?  Also, probably some re-organization of drivers/block,
drivers/ide, drivers/ata, drivers/nvme (and common/usb_storage.c) too,
to be more consistent.

-- 
Tom


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 v1 18/22] config: colibri_vf: enable mtd partitions via dt

[Igor Opaniuk]

Off-topic: I'm just wondering, why no one introduced a proper Kconfig symbol for
FDT_FIXUP_PARTITIONS. Currently there is no any description of this
option through
the code and what it's actually used for. But, anyway, it doesn't
directly relate to this particular patch-set,
it can be addressed in a separate patch.

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:27, Marcel Ziswiler  wrote:
>
> From: Stefan Agner 
>
> Use device tree to set MTD partitions of the NAND chip.
>
> Signed-off-by: Stefan Agner 
> Acked-by: Marcel Ziswiler 
>
> ---
>
>  configs/colibri_vf_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
> index 344fe77234..8f6cceca7f 100644
> --- a/configs/colibri_vf_defconfig
> +++ b/configs/colibri_vf_defconfig
> @@ -91,4 +91,5 @@ CONFIG_VIDEO_FSL_DCU_FB=y
>  CONFIG_VIDEO=y
>  CONFIG_SYS_CONSOLE_FG_COL=0x00
>  CONFIG_OF_LIBFDT_OVERLAY=y
> +CONFIG_FDT_FIXUP_PARTITIONS=y
>  # CONFIG_EFI_UNICODE_CAPITALIZATION is not set
> --
> 2.20.1
>
> ___
> 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 v1 16/22] colibri_vf: enable user debug by default

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:26, Marcel Ziswiler  wrote:
>
> From: Stefan Agner 
>
> Let the kernel print some debug messages when a user program
> crashes due to an exception.
>
> Signed-off-by: Stefan Agner 
> Acked-by: Marcel Ziswiler 
>
> ---
>
>  include/configs/colibri_vf.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index 0bbeeb902e..030281bb67 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -106,7 +106,7 @@
> SD_BOOTCMD \
> UBI_BOOTCMD \
> "console=ttyLP0\0" \
> -   "defargs=\0" \
> +   "defargs=user_debug=31\0" \
> "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
> "fdt_board=eval-v3\0" \
> "fdt_fixup=;\0" \
> --
> 2.20.1
>
> ___
> 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 v1 17/22] colibri_vf: disable undefined instruction events in user debug

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:25, Marcel Ziswiler  wrote:
>
> From: Stefan Agner 
>
> It turns out that OpenSSL calls undefined instructions to detect
> ARM capabilities at runtime (via SIGILL handler). This leads to
> stack traces e.g. when logging in using SSH:
>   [  877.464442] sshd (613): undefined instruction: pc=76ee2da8
>   ...
>
> Disable undefined instruction events since it is used as an
> autodetecion mechanism.
>
> Signed-off-by: Stefan Agner 
> Acked-by: Marcel Ziswiler 
>
> ---
>
>  include/configs/colibri_vf.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index 030281bb67..b2f27c1977 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -106,7 +106,7 @@
> SD_BOOTCMD \
> UBI_BOOTCMD \
> "console=ttyLP0\0" \
> -   "defargs=user_debug=31\0" \
> +   "defargs=user_debug=30\0" \
> "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
> "fdt_board=eval-v3\0" \
> "fdt_fixup=;\0" \
> --
> 2.20.1
>
> ___
> 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 v1 05/22] configs: colibri_vf: remove obsolete mmc/sd card environment

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:22, Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> Remove obsolete MMC/SD card environment configuration dating back to
> un-fused samples times.
>
> While at it also remove meanwhile spurious "USB Storage" comment.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  include/configs/colibri_vf.h | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index 2fe7f217fa..7b974d9e97 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -145,13 +145,6 @@
> (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
>
>  /* Environment organization */
> -
> -#ifdef CONFIG_ENV_IS_IN_MMC
> -#define CONFIG_SYS_MMC_ENV_DEV 0
> -#define CONFIG_ENV_OFFSET  (12 * 64 * 1024)
> -#define CONFIG_ENV_SIZE(8 * 1024)
> -#endif
> -
>  #ifdef CONFIG_ENV_IS_IN_NAND
>  #define CONFIG_ENV_SIZE(64 * 2048)
>  #define CONFIG_ENV_RANGE   (4 * 64 * 2048)
> @@ -165,6 +158,4 @@
>  /* USB DFU */
>  #define CONFIG_SYS_DFU_DATA_BUF_SIZE (1024 * 1024)
>
> -/* USB Storage */
> -
>  #endif /* __CONFIG_H */
> --
> 2.20.1
>
> ___
> 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 v1 02/22] vf610: ddrmc: add missing include

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:22, Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> The DDR memory controller include file for the Vybrid uses
> iomux_v3_cfg_t without actually including iomux-vf610.h.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h 
> b/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
> index c7da2b8a5e..03e3cecb95 100644
> --- a/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
> +++ b/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
> @@ -10,6 +10,8 @@
>  #ifndef __ASM_ARCH_VF610_DDRMC_H
>  #define __ASM_ARCH_VF610_DDRMC_H
>
> +#include 
> +
>  struct ddr3_jedec_timings {
> u8 tinit;
> u32 trst_pwron;
> --
> 2.20.1
>
> ___
> 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] U-Boot doesn't detect Pine64-LTS MMC

[AndroidT Tester]

Hello

I followed the instructions here:
https://openbsdmailbox.blogspot.com/2018/04/re-pine64-lts-cant-detect-disk_41.html

Here's all I did:

dd if=miniroot65.fs of=/dev/rsd0c bs=1m
mount /dev/sd0i /mnt
cd /mnt
cp /usr/local/share/dtb/arm64/allwinner/sun50i-a64-sopine-baseboard.dtb .
mkdir allwinner
cp sun50i-a64-sopine-baseboard.dtb allwinner/sun50i-a64-pine64-plus.dtb
cd ~
umount /mnt
dd if=/usr/local/share/u-boot/sopine_baseboard/sunxi-spl.bin of=/dev/sd0c
bs=1024 seek=8


I still can't get it to work.
This is what I get:

Device 0: device type unknown
... is now current device
ethernet@1c3 Waiting for PHY auto negotiation to complete... done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-02-ba-06-5b-d4-59
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
*** ERROR: `serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
*** ERROR: `serverip' not set
Config file not found
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
=> load mmc 0:1 ${fdt_addr_r} allwinner/sun50i-a64-pine64-plus.dtb
MMC: no card present
MMC: no card present


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

Re: [U-Boot] [PATCH] Revert "pico-imx7d: Add LCD support"

[Fabio Estevam]

Hi Joris,

On Sun, Mar 10, 2019 at 3:52 PM Joris Offouga  wrote:
>
> This reverts commit 9e3c0174da842dd88f5feaffbf843ba332233897.
> This commit causes the crash of U-Boot when loaded with imx-usb-loader

Your Signed-off-by line is missing.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now【请注意，邮件由u-boot-boun...@lists.denx.de代发】【请注意，邮件由s...@google.com代发】

[Philipp Tomsich]

> On 11.03.2019, at 03:30, Simon Glass  wrote:
> 
> Hi Andy,
> 
> On Wed, 6 Mar 2019 at 03:52, Andy Yan  wrote:
>> 
>> Hi Simon:
>> 
>> On 2019/2/12 下午11:31, Simon Glass wrote:
>>> HI Andy,
>>> 
>>> On Tue, 12 Feb 2019 at 04:05, Andy Yan  wrote:
 Hi Philipp:
 
  Sorry for the late reply, we just come back from the Chinese Spring
 Festival.
 
 On 2019/2/1 下午6:26, Philipp Tomsich wrote:
> Kever,
> 
> Independent of whether we revert this for the current cycle (and also
> independent of
> if I ever find the other patch you had been referring to — I couldn’t
> find it in my local
> mailing list archive) and then deprecate it for the next release
> (unless converted to
> DM), we still have a number of architectural issues that need to be
> addressed:
 I still doubt  is this a right  work-flow for patch apply. Before we
 apply  a patch  which will break many other boards , should we  make
 sure there is a solution patch applied for these boars first?
 
 
> 1.This really should be a driver under DTS control.
> 2.We need to not get away from configuring SOM-specific addresses via
> Kconfig
> 
> Both these issues are technical debt that we’ve accumulated over the
> last 18 months
> and need to address for the sake of future maintainability.
> E.g. ‘setting an address to 0x0 via Kconfig to disable a
> driver/feature’ really isn’t in line
> with the architectural direction of U-Boot.
> 
 For technical side, I think CONFIG_ROCKCHIP_BOOT_MODE_REG is necessary
 here, we will read this register from save_boot_params when we get out
 from bootrom,  the dtb is not available at this point.
>>> Yes this is happening very early, but I wonder why this is necessary?
>>> Can it be moved to later?
>>> 
>>> The call to check_back_to_brom_dnl_flag() happens much later so there
>>> should be no problem to convert that.
>>> 
 On the other hand, almost rockchip based products use a recovery key to
 enter download(upgrade)mode, this is a muti-funtion key, most of them
 reuse with vol+- key,  we would like the u-boot share
 
 dtb with linux kernel. To keep the linux kernel dts as clean as possible
 ,we don't want to add another dts property to describe this key either.
 This is why I implement function rockchip_dnl_key_pressed as __weak.
 
>>> OK, but given that it is called later, it seems to me that it could
>>> use a driver.
>> 
>> 
>> 
>> We can't let it called later. See the discuss here :
>> http://patchwork.ozlabs.org/patch/812228/
> 
> Yes I read that, and took a look myself, and certainly it does not
> look very easy and I take your point about potential bugs being
> introduced.
> 
> It seems like you have tried quite hard, so I'm not going to object if
> you can't find a way. My main objection was that it broke other
> boards.
> 
> Is there any way the check could be delayed enough to actually be able
> to read the device tree? It could call spl_early_init() quite early
> and then do that.

Note that the minimum improvement that I’d expect to get this fully
enabled again would be a clean-up of the Kconfig options, so it is
easy and (from the documentation) predictable for boards to turn
this off.

I still want this to be turned back on in the current cycle.

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

[U-Boot] [PATCH v2] arm: mvebu: theadorable: Add test for ctrl-c in PCIe PEX switch test

[Stefan Roese]

The check for the missing PEX switch can lead to an infinite loop, when
the PCIe device is not found. It is helpful to enable the user to break
out of this boot-loop, to enable booting to the prompt for test cases.
This patch adds a 3 second delay in the error case before rebooting.
The user can press Ctrl-C in this time to abort the boot-loop.

This patch also calls bootcount_inc() before rebooting in the error
case. This is needed to increment the bootcounter, since this function
is called earlier than the main bootcounter increment. Otherwise the
bootcounter will not be incremented in the error case at all.

Signed-off-by: Stefan Roese 
---
v2:
- Rebase on current master

 board/theadorable/theadorable.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/board/theadorable/theadorable.c b/board/theadorable/theadorable.c
index acd46b0026..65e90381e1 100644
--- a/board/theadorable/theadorable.c
+++ b/board/theadorable/theadorable.c
@@ -1,11 +1,15 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2015-2016 Stefan Roese 
+ * Copyright (C) 2015-2019 Stefan Roese 
  */
 
 #include 
+#include 
 #include 
 #include 
+#if !defined(CONFIG_SPL_BUILD)
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -42,6 +46,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define STM_I2C_BUS1
 #define STM_I2C_ADDR   0x27
 #define REBOOT_DELAY   1000/* reboot-delay in ms */
+#define ABORT_TIMEOUT  3000/* 3 seconds reboot abort timeout */
 
 /* DDR3 static configuration */
 static MV_DRAM_MC_INIT ddr3_theadorable[MV_MAX_DDR3_STATIC_SIZE] = {
@@ -222,7 +227,7 @@ int board_eth_init(bd_t *bis)
 }
 #endif
 
-#ifdef CONFIG_BOARD_LATE_INIT
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_BOARD_LATE_INIT)
 int board_late_init(void)
 {
pci_dev_t bdf;
@@ -236,6 +241,7 @@ int board_late_init(void)
 */
bdf = pci_find_device(PCI_VENDOR_ID_PLX, 0x8619, 0);
if (bdf == -1) {
+   unsigned long start_time = get_timer(0);
u8 i2c_buf[8];
int ret;
 
@@ -243,6 +249,28 @@ int board_late_init(void)
bootcount = bootcount_load();
printf("Failed to find PLX PEX-switch (bootcount=%ld)\n",
   bootcount);
+
+   /*
+* The user can exit this boot-loop in the error case by
+* hitting Ctrl-C. So wait some time for this key here.
+*/
+   printf("Continue booting with Ctrl-C, otherwise rebooting\n");
+   do {
+   /* Handle control-c and timeouts */
+   if (ctrlc()) {
+   printf("PEX error boot-loop aborted!\n");
+   return 0;
+   }
+   } while (get_timer(start_time) < ABORT_TIMEOUT);
+
+
+   /*
+* At this stage the bootcounter has not been incremented
+* yet. We need to do this manually here to get an actually
+* working bootcounter in this error case.
+*/
+   bootcount_inc();
+
if (bootcount > PEX_SWITCH_NOT_FOUNT_LIMIT) {
printf("Issuing power-switch via uC!\n");
 
-- 
2.21.0

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

[U-Boot] [PATCH 4/4] Makefile: Correct logic for DM_SCSI + unconverted drivers check

[Stefan Roese]

When checking for boards that are enabling a SATA driver that isn't
converted to DM yet we need to be sure to not also trip over boards that
do set CONFIG_AHCI & CONFIG_BLK by itself, as that is not a bug.

This was detected when converting the Armada XP SATA driver sata_mv.c
to DM with AHCI & BLK support. This warning is still printed without
this patch applied here.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Tom Rini 
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 26db4e7b59..896e0c3350 100644
--- a/Makefile
+++ b/Makefile
@@ -940,6 +940,7 @@ endif
 endif
 ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y)
 ifneq ($(CONFIG_DM_SCSI),y)
+ifneq ($(CONFIG_BLK)$(CONFIG_AHCI),yy)
@echo >&2 "= WARNING =="
@echo >&2 "This board does not use CONFIG_DM_SCSI. Please update"
@echo >&2 "the storage controller to use CONFIG_DM_SCSI before the 
v2019.07 release."
@@ -948,6 +949,7 @@ ifneq ($(CONFIG_DM_SCSI),y)
@echo >&2 ""
 endif
 endif
+endif
 ifeq ($(CONFIG_PCI),y)
 ifneq ($(CONFIG_DM_PCI),y)
@echo >&2 "= WARNING =="
-- 
2.21.0

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

[U-Boot] [PATCH 3/4] arm: mvebu: db-mv784mp-gp_defconfig: Enable CONFIG_BLK

[Stefan Roese]

This patch enables CONFIG_BLK as this is now possible with the recent
DM conversion of the Armada XP SATA driver.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Tom Rini 
---
 configs/db-mv784mp-gp_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/db-mv784mp-gp_defconfig b/configs/db-mv784mp-gp_defconfig
index b6c61c3a48..feea5d9f42 100644
--- a/configs/db-mv784mp-gp_defconfig
+++ b/configs/db-mv784mp-gp_defconfig
@@ -44,6 +44,7 @@ CONFIG_EFI_PARTITION=y
 CONFIG_DEFAULT_DEVICE_TREE="armada-xp-gp"
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_SATA_MV=y
+CONFIG_BLK=y
 # CONFIG_MMC is not set
 CONFIG_NAND=y
 CONFIG_NAND_PXA3XX=y
-- 
2.21.0

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

[U-Boot] [PATCH 1/4] sata: sata_mv: Add DM support to enable CONFIG_BLK usage

[Stefan Roese]

This patch adds DM support to the Armada XP SATA driver. This is needed
to enable CONFIG_BLK on this platform. It adds the SATA controller as
AHCI device, which is strictly speaking not correct, as the controller
is not AHCI compatible. But the U-Boot AHCI uclass interface enables
the usage of this DM driver and the creation of the corresponding BLK
devices.

This conversion is done to get rid of the compile warning:
= WARNING ==
This board does not use CONFIG_DM_SCSI. Please update
the storage controller to use CONFIG_DM_SCSI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.


Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Tom Rini 
---
 drivers/ata/Kconfig   |   2 +
 drivers/ata/sata_mv.c | 344 --
 2 files changed, 197 insertions(+), 149 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 49a056e941..7ebee75c0a 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -81,7 +81,9 @@ config MVSATA_IDE
 
 config SATA_MV
bool "Enable Marvell SATA controller driver support"
+   select AHCI
select LIBATA
+   depends on BLK
help
  Enable this driver to support the SATA controller found in
  some Marvell SoCs.
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index a168196fd4..d13695d79e 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -3,7 +3,7 @@
  * Copyright (C) Excito Elektronik i Skåne AB, 2010.
  * Author: Tor Krill 
  *
- * Copyright (C) 2015 Stefan Roese 
+ * Copyright (C) 2015, 2019 Stefan Roese 
  */
 
 /*
@@ -32,6 +32,10 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -256,6 +260,7 @@ struct mv_priv {
u16 pio;
u16 mwdma;
u16 udma;
+   int dev_nr;
 
void *crqb_alloc;
struct crqb *request;
@@ -278,9 +283,9 @@ static int ata_wait_register(u32 *addr, u32 mask, u32 val, 
u32 timeout_msec)
 }
 
 /* Cut from sata_mv in linux kernel */
-static int mv_stop_edma_engine(int port)
+static int mv_stop_edma_engine(struct udevice *dev, int port)
 {
-   struct mv_priv *priv = (struct mv_priv *)sata_dev_desc[port].priv;
+   struct mv_priv *priv = dev_get_platdata(dev);
int i;
 
/* Disable eDMA. The disable bit auto clears. */
@@ -299,9 +304,9 @@ static int mv_stop_edma_engine(int port)
return -1;
 }
 
-static int mv_start_edma_engine(int port)
+static int mv_start_edma_engine(struct udevice *dev, int port)
 {
-   struct mv_priv *priv = (struct mv_priv *)sata_dev_desc[port].priv;
+   struct mv_priv *priv = dev_get_platdata(dev);
u32 tmp;
 
/* Check preconditions */
@@ -351,12 +356,12 @@ static int mv_start_edma_engine(int port)
return 0;
 }
 
-static int mv_reset_channel(int port)
+static int mv_reset_channel(struct udevice *dev, int port)
 {
-   struct mv_priv *priv = (struct mv_priv *)sata_dev_desc[port].priv;
+   struct mv_priv *priv = dev_get_platdata(dev);
 
/* Make sure edma is stopped  */
-   mv_stop_edma_engine(port);
+   mv_stop_edma_engine(dev, port);
 
out_le32(priv->regbase + EDMA_CMD, EDMA_CMD_ATARST);
udelay(25); /* allow reset propagation */
@@ -366,11 +371,11 @@ static int mv_reset_channel(int port)
return 0;
 }
 
-static void mv_reset_port(int port)
+static void mv_reset_port(struct udevice *dev, int port)
 {
-   struct mv_priv *priv = (struct mv_priv *)sata_dev_desc[port].priv;
+   struct mv_priv *priv = dev_get_platdata(dev);
 
-   mv_reset_channel(port);
+   mv_reset_channel(dev, port);
 
out_le32(priv->regbase + EDMA_CMD, 0x0);
out_le32(priv->regbase + EDMA_CFG, 0x101f);
@@ -392,9 +397,9 @@ static void mv_reset_one_hc(void)
out_le32(SATAHC_BASE + SATAHC_ICR, 0x00);
 }
 
-static int probe_port(int port)
+static int probe_port(struct udevice *dev, int port)
 {
-   struct mv_priv *priv = (struct mv_priv *)sata_dev_desc[port].priv;
+   struct mv_priv *priv = dev_get_platdata(dev);
int tries, tries2, set15 = 0;
u32 tmp;
 
@@ -446,7 +451,7 @@ static int probe_port(int port)
tmp &= ~SIR_CFG_GEN2EN;
out_le32(priv->regbase + SIR_ICFG, tmp);
 
-   mv_reset_channel(port);
+   mv_reset_channel(dev, port);
}
}
 
@@ -455,9 +460,9 @@ static int probe_port(int port)
 }
 
 /* Get request queue in pointer */
-static int get_reqip(int port)
+static int get_reqip(struct udevice *dev, int port)
 {
-   struct mv_priv *priv = (struct mv_priv *)sata_dev_desc[port].priv;
+   struct mv_priv *priv = dev_get_platdata(dev);
u32 tmp;
 
tmp = in_le32(priv->regbase + EDMA_RQIPR) & EDMA_RQIPR_I

[U-Boot] [PATCH 2/4] arm: mvebu: theadorable_debug_defconfig: Enable CONFIG_BLK

[Stefan Roese]

This patch enables CONFIG_BLK as this is now possible with the recent
DM conversion of the Armada XP SATA driver.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Tom Rini 
---
 configs/theadorable_debug_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/theadorable_debug_defconfig 
b/configs/theadorable_debug_defconfig
index a7d02e957a..1573b5f544 100644
--- a/configs/theadorable_debug_defconfig
+++ b/configs/theadorable_debug_defconfig
@@ -49,6 +49,7 @@ CONFIG_DEFAULT_DEVICE_TREE="armada-xp-theadorable"
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_SATA_MV=y
+CONFIG_BLK=y
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_BOOTCOUNT_RAM=y
 CONFIG_FPGA_ALTERA=y
-- 
2.21.0

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

[U-Boot] [PATCH 2/2] board: pm9263: Convert to CONFIG_DM_USB and CONFIG_DM_VIDEO

[Ilko Iliev]

Convert the board to support the USB and video driver model and remove
the unnecessary code.
---
 board/ronetix/pm9263/pm9263.c | 93 ---
 configs/pm9263_defconfig  |  3 ++
 2 files changed, 3 insertions(+), 93 deletions(-)

diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c
index 692288d52e..2da39c4acd 100644
--- a/board/ronetix/pm9263/pm9263.c
+++ b/board/ronetix/pm9263/pm9263.c
@@ -17,8 +17,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
 #include 
 #endif
@@ -109,32 +107,6 @@ static void pm9263_macb_hw_init(void)
 #endif
 
 #ifdef CONFIG_LCD
-vidinfo_t panel_info = {
-   .vl_col =   240,
-   .vl_row =   320,
-   .vl_clk =   4965000,
-   .vl_sync =  ATMEL_LCDC_INVLINE_INVERTED |
-   ATMEL_LCDC_INVFRAME_INVERTED,
-   .vl_bpix =  3,
-   .vl_tft =   1,
-   .vl_hsync_len = 5,
-   .vl_left_margin =   1,
-   .vl_right_margin =  33,
-   .vl_vsync_len = 1,
-   .vl_upper_margin =  1,
-   .vl_lower_margin =  0,
-   .mmio = ATMEL_BASE_LCDC,
-};
-
-void lcd_enable(void)
-{
-   at91_set_pio_value(AT91_PIO_PORTA, 22, 1); /* power up */
-}
-
-void lcd_disable(void)
-{
-   at91_set_pio_value(AT91_PIO_PORTA, 22, 0); /* power down */
-}
 
 #ifdef CONFIG_LCD_IN_PSRAM
 
@@ -226,32 +198,6 @@ static int pm9263_lcd_hw_psram_init(void)
 
 static void pm9263_lcd_hw_init(void)
 {
-   at91_set_a_periph(AT91_PIO_PORTC, 0, 0);/* LCDVSYNC */
-   at91_set_a_periph(AT91_PIO_PORTC, 1, 0);/* LCDHSYNC */
-   at91_set_a_periph(AT91_PIO_PORTC, 2, 0);/* LCDDOTCK */
-   at91_set_a_periph(AT91_PIO_PORTC, 3, 0);/* LCDDEN */
-   at91_set_b_periph(AT91_PIO_PORTB, 9, 0);/* LCDCC */
-   at91_set_a_periph(AT91_PIO_PORTC, 6, 0);/* LCDD2 */
-   at91_set_a_periph(AT91_PIO_PORTC, 7, 0);/* LCDD3 */
-   at91_set_a_periph(AT91_PIO_PORTC, 8, 0);/* LCDD4 */
-   at91_set_a_periph(AT91_PIO_PORTC, 9, 0);/* LCDD5 */
-   at91_set_a_periph(AT91_PIO_PORTC, 10, 0);   /* LCDD6 */
-   at91_set_a_periph(AT91_PIO_PORTC, 11, 0);   /* LCDD7 */
-   at91_set_a_periph(AT91_PIO_PORTC, 14, 0);   /* LCDD10 */
-   at91_set_a_periph(AT91_PIO_PORTC, 15, 0);   /* LCDD11 */
-   at91_set_a_periph(AT91_PIO_PORTC, 16, 0);   /* LCDD12 */
-   at91_set_b_periph(AT91_PIO_PORTC, 12, 0);   /* LCDD13 */
-   at91_set_a_periph(AT91_PIO_PORTC, 18, 0);   /* LCDD14 */
-   at91_set_a_periph(AT91_PIO_PORTC, 19, 0);   /* LCDD15 */
-   at91_set_a_periph(AT91_PIO_PORTC, 22, 0);   /* LCDD18 */
-   at91_set_a_periph(AT91_PIO_PORTC, 23, 0);   /* LCDD19 */
-   at91_set_a_periph(AT91_PIO_PORTC, 24, 0);   /* LCDD20 */
-   at91_set_b_periph(AT91_PIO_PORTC, 17, 0);   /* LCDD21 */
-   at91_set_a_periph(AT91_PIO_PORTC, 26, 0);   /* LCDD22 */
-   at91_set_a_periph(AT91_PIO_PORTC, 27, 0);   /* LCDD23 */
-
-   at91_periph_clk_enable(ATMEL_ID_LCDC);
-
/* Power Control */
at91_set_pio_output(AT91_PIO_PORTA, 22, 1);
at91_set_pio_value(AT91_PIO_PORTA, 22, 0);  /* power down */
@@ -267,45 +213,6 @@ static void pm9263_lcd_hw_init(void)
 
 }
 
-#ifdef CONFIG_LCD_INFO
-#include 
-#include 
-
-extern flash_info_t flash_info[];
-
-void lcd_show_board_info(void)
-{
-   ulong dram_size, nand_size, flash_size;
-   int i;
-   char temp[32];
-
-   lcd_printf ("%s\n", U_BOOT_VERSION);
-   lcd_printf ("(C) 2009 Ronetix GmbH\n");
-   lcd_printf ("supp...@ronetix.at\n");
-   lcd_printf ("%s CPU at %s MHz",
-   CONFIG_SYS_AT91_CPU_NAME,
-   strmhz(temp, get_cpu_clk_rate()));
-
-   dram_size = 0;
-   for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++)
-   dram_size += gd->bd->bi_dram[i].size;
-
-   nand_size = 0;
-   for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++)
-   nand_size += get_nand_dev_by_index(i)->size;
-
-   flash_size = 0;
-   for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; i++)
-   flash_size += flash_info[i].size;
-
-   lcd_printf ("%ld MB SDRAM, %ld MB NAND\n%ld MB NOR Flash\n"
-   "4 MB PSRAM\n",
-   dram_size >> 20,
-   nand_size >> 20,
-   flash_size >> 20);
-}
-#endif /* CONFIG_LCD_INFO */
-
 #endif /* CONFIG_LCD */
 
 int board_early_init_f(void)
diff --git a/configs/pm9263_defconfig b/configs/pm9263_defconfig
index ceb7efe503..29352f3377 100644
--- a/configs/pm9263_defconfig
+++ b/configs/pm9263_defconfig
@@ -30,6 +30,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="at91sam9263ek"
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_DM=y
+CONFIG_BLK=y
 CONFIG_CLK=y
 CONFIG_CLK_AT91=y
 CO

[U-Boot] [PATCH 1/2] board: pm9261: Convert to CONFIG_DM_USB and CONFIG_DM_VIDEO

[Ilko Iliev]

Convert the board to support the USB and video driver model and remove
the unnecessary code.
---
 board/ronetix/pm9261/pm9261.c | 105 --
 configs/pm9261_defconfig  |   3 +
 2 files changed, 3 insertions(+), 105 deletions(-)

diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c
index 0c7b4ee415..f1e7aab629 100644
--- a/board/ronetix/pm9261/pm9261.c
+++ b/board/ronetix/pm9261/pm9261.c
@@ -17,9 +17,6 @@
 #include 
 #include 
 #include 
-
-#include 
-#include 
 #if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_DRIVER_DM9000)
 #include 
 #endif
@@ -110,105 +107,6 @@ static void pm9261_dm9000_hw_init(void)
 }
 #endif
 
-#ifdef CONFIG_LCD
-vidinfo_t panel_info = {
-   .vl_col =   240,
-   .vl_row =   320,
-   .vl_clk =   4965000,
-   .vl_sync =  ATMEL_LCDC_INVLINE_INVERTED |
-   ATMEL_LCDC_INVFRAME_INVERTED,
-   .vl_bpix =  3,
-   .vl_tft =   1,
-   .vl_hsync_len = 5,
-   .vl_left_margin =   1,
-   .vl_right_margin =  33,
-   .vl_vsync_len = 1,
-   .vl_upper_margin =  1,
-   .vl_lower_margin =  0,
-   .mmio = ATMEL_BASE_LCDC,
-};
-
-void lcd_enable(void)
-{
-   at91_set_pio_value(AT91_PIO_PORTA, 22, 0);  /* power up */
-}
-
-void lcd_disable(void)
-{
-   at91_set_pio_value(AT91_PIO_PORTA, 22, 1);  /* power down */
-}
-
-static void pm9261_lcd_hw_init(void)
-{
-   at91_set_a_periph(AT91_PIO_PORTB, 1, 0);/* LCDHSYNC */
-   at91_set_a_periph(AT91_PIO_PORTB, 2, 0);/* LCDDOTCK */
-   at91_set_a_periph(AT91_PIO_PORTB, 3, 0);/* LCDDEN */
-   at91_set_a_periph(AT91_PIO_PORTB, 4, 0);/* LCDCC */
-   at91_set_a_periph(AT91_PIO_PORTB, 7, 0);/* LCDD2 */
-   at91_set_a_periph(AT91_PIO_PORTB, 8, 0);/* LCDD3 */
-   at91_set_a_periph(AT91_PIO_PORTB, 9, 0);/* LCDD4 */
-   at91_set_a_periph(AT91_PIO_PORTB, 10, 0);   /* LCDD5 */
-   at91_set_a_periph(AT91_PIO_PORTB, 11, 0);   /* LCDD6 */
-   at91_set_a_periph(AT91_PIO_PORTB, 12, 0);   /* LCDD7 */
-   at91_set_a_periph(AT91_PIO_PORTB, 15, 0);   /* LCDD10 */
-   at91_set_a_periph(AT91_PIO_PORTB, 16, 0);   /* LCDD11 */
-   at91_set_a_periph(AT91_PIO_PORTB, 17, 0);   /* LCDD12 */
-   at91_set_a_periph(AT91_PIO_PORTB, 18, 0);   /* LCDD13 */
-   at91_set_a_periph(AT91_PIO_PORTB, 19, 0);   /* LCDD14 */
-   at91_set_a_periph(AT91_PIO_PORTB, 20, 0);   /* LCDD15 */
-   at91_set_b_periph(AT91_PIO_PORTB, 23, 0);   /* LCDD18 */
-   at91_set_b_periph(AT91_PIO_PORTB, 24, 0);   /* LCDD19 */
-   at91_set_b_periph(AT91_PIO_PORTB, 25, 0);   /* LCDD20 */
-   at91_set_b_periph(AT91_PIO_PORTB, 26, 0);   /* LCDD21 */
-   at91_set_b_periph(AT91_PIO_PORTB, 27, 0);   /* LCDD22 */
-   at91_set_b_periph(AT91_PIO_PORTB, 28, 0);   /* LCDD23 */
-
-   at91_system_clk_enable(AT91_PMC_HCK1);
-
-   gd->fb_base = ATMEL_BASE_SRAM;
-}
-
-#ifdef CONFIG_LCD_INFO
-#include 
-#include 
-
-extern flash_info_t flash_info[];
-
-void lcd_show_board_info(void)
-{
-   ulong dram_size, nand_size, flash_size;
-   int i;
-   char temp[32];
-
-   lcd_printf ("%s\n", U_BOOT_VERSION);
-   lcd_printf ("(C) 2009 Ronetix GmbH\n");
-   lcd_printf ("supp...@ronetix.at\n");
-   lcd_printf ("%s CPU at %s MHz",
-   CONFIG_SYS_AT91_CPU_NAME,
-   strmhz(temp, get_cpu_clk_rate()));
-
-   dram_size = 0;
-   for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++)
-   dram_size += gd->bd->bi_dram[i].size;
-
-   nand_size = 0;
-   for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++)
-   nand_size += get_nand_dev_by_index(i)->size;
-
-   flash_size = 0;
-   for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; i++)
-   flash_size += flash_info[i].size;
-
-   lcd_printf ("%ld MB SDRAM, %ld MB NAND\n%ld MB NOR Flash\n"
-   "%ld MB DataFlash\n",
-   dram_size >> 20,
-   nand_size >> 20,
-   flash_size >> 20);
-}
-#endif /* CONFIG_LCD_INFO */
-
-#endif /* CONFIG_LCD */
-
 int board_early_init_f(void)
 {
return 0;
@@ -227,9 +125,6 @@ int board_init(void)
 #endif
 #ifdef CONFIG_DRIVER_DM9000
pm9261_dm9000_hw_init();
-#endif
-#ifdef CONFIG_LCD
-   pm9261_lcd_hw_init();
 #endif
return 0;
 }
diff --git a/configs/pm9261_defconfig b/configs/pm9261_defconfig
index d2c4c25672..34e05f0395 100644
--- a/configs/pm9261_defconfig
+++ b/configs/pm9261_defconfig
@@ -30,6 +30,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="at91sam9261ek"
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_DM=y
+CONFIG_BLK=y
 CONFIG_CLK=y
 CONFIG_CLK_AT91=y
 CONFIG_DM_GPIO=y
@@ -51,5 +52,7 @@ CONFIG_ATMEL_USART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
+CONF

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Palmer Dabbelt]

On Thu, 07 Mar 2019 19:37:30 PST (-0800), Anup Patel wrote:




-Original Message-
From: Andreas Schwab 
Sent: Thursday, March 7, 2019 2:50 PM
To: Anup Patel 
Cc: Atish Patra ; Anup Patel ;
Auer, Lukas ; paul.walms...@sifive.com;
ag...@suse.de; u-boot@lists.denx.de; bar...@tkos.co.il;
daniel.schwierz...@gmail.com; bmeng...@gmail.com;
r...@andestech.com; s...@denx.de; pal...@sifive.com
Subject: Re: [PATCH v2 0/9] SMP support for RISC-V

On Mär 07 2019, Anup Patel  wrote:

> Like I mentioned, there is no functional issue with this series. The
> warm-boot issues were fixed in OpenSBI.
>
> @Andreas, please try at your end.

As long as issue#65 isn't fixed opensbi is mostly a no-go for me.  At least it
gives me more reasons to press the reset button. :-)


The reset button works fine for me an Atish. I am sure it works fine for lot of
other folks too.

BTW, as-per discussion with SiFive folks the reset button on Unleashed
Board is not much tested and it can misbehave on certain boards. It is quite
possible that you might have a "flaky" board.


I don't think the reset button differs between boards.  As far as I know, the 
issues are really just that it doesn't reset everything -- specifically some of 
the IP on the chip (clock, power, JTAG) isn't reset and nothing on the board 
(SD, ethernet, PCIe, etc) is reset.  This frequently results in flakiness when 
debugging drivers, but the cores and memory system should all be OK.


Is that issue 65 on github.com/opensbi?  If so it clearly says this isn't a 
reset button issue.

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

Re: [U-Boot] [PATCH v4 1/1] efi_loader: Patch non-runtime code out at ExitBootServices already

[Heinrich Schuchardt]

On 3/11/19 9:03 AM, Ard Biesheuvel wrote:
> On Mon, 11 Mar 2019 at 01:16, Heinrich Schuchardt  wrote:
>>
>> From: Alexander Graf 
>>
>> While discussing something compeltely different, Ard pointed out
>> that it might be legal to omit calling SetVirtualAddressMap altogether.
>>
>> There is even a patch on the Linux Kernel Mailing List that implements
>> such behavior by now:
>>
>>   https://patchwork.kernel.org/patch/10782393/
>>
>> While that sounds great, we currently rely on the SetVirtualAddressMap
>> call to remove all references to code that would not work outside of
>> boot services.
>>
>> So let's patch out those bits already on the call to ExitBootServices,
>> so that we can successfully run even when an OS chooses to omit
>> any call to SetVirtualAddressMap.
>>
>> Reported-by: Ard Biesheuvel 
>> Signed-off-by: Alexander Graf 
>>
>> OpenBSD is not calling SetVirtualAddressMap on ARM 32 bit.
>>
> 
> I take it this means that OpenBSD does not support runtime services at
> all on 32-bit ARM?

References to runtime services exist, e.g.:

sys/arch/armv7/stand/efiboot/efiboot.c:666:
EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);

But from what I see at first glance it seems to be for the interactive
console before booting the kernel.

Best regards

Heinrich

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

Re: [U-Boot] rk3399 sdram data training read gate is looping forever

[Jagan Teki]

On Tue, Jan 8, 2019 at 6:08 AM Simon Glass  wrote:
>
> Hi Jagan,
>
> On Sat, 5 Jan 2019 at 12:58, Jagan Teki  wrote:
> >
> > Hi,
> >
> > I'm trying to bring-up rk3399 SBC with 1GB DDR3 933MHZ capable, and
> > observed an sdram_init issue where data_training_rg transfer is
> > looping forever. The denali_pi[80], and denali_pi[74] seems to be
> > proper values while setting up the particular ranks.
> >
> > Can anyone encounter similar issue? let me know for any inputs.
> >
> > Log:
>
> I have not seen this so far.

In fact I have reused existing rk3399-sdram-ddr3-1866.dtsi (which
seems to be 2GB) since this SBC using similar frequency. The only
difference between other supported sdram dtsi's from Mainline would be
that it is single channel and 1GB size.

For single channel I have updated the num_channel as
index c46c1996be..85e99d81c2 100644
--- a/arch/arm/dts/rk3399-sdram-ddr3-1866.dtsi
+++ b/arch/arm/dts/rk3399-sdram-ddr3-1866.dtsi
@@ -37,7 +37,7 @@
0x
933
3
-   2
+   1
9
1
0x0600

But not clear for any changes wrt to 1GB vs 2GB? Any help where to
debug please let me know.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/4] board: stm32mp1: Force pinctrl driver probe in board_init()

[Patrice Chotard]

In order to insure that hog GPIOs are configured early during
the boot process, force all pinctrl driver probing in board_init().

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
Reviewed-by: CITOOLS 
---

Changes in v2: None

 board/st/stm32mp1/stm32mp1.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index ff7790e310d7..24d299ac33bd 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -543,9 +543,18 @@ static void sysconf_init(void)
 /* board dependent setup after realloc */
 int board_init(void)
 {
+   struct udevice *dev;
+
/* address of boot parameters */
gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100;
 
+   /* probe all PINCTRL for hog */
+   for (uclass_first_device(UCLASS_PINCTRL, &dev);
+dev;
+uclass_next_device(&dev)) {
+   pr_debug("probe pincontrol = %s\n", dev->name);
+   }
+
board_key_check();
 
sysconf_init();
-- 
1.9.1

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

[U-Boot] [PATCH v2 2/4] config: stm32mp15: Enable STMFX support

[Patrice Chotard]

From: Patrick Delaunay 

Activate PINCTRL_STMFX and needed part for generic pincontrol
PINCTRL_FULL, PINCONF. Increase pre-reloc memory for MALLOC
(needed for each DM pinconfig node).

Signed-off-by: Patrick Delaunay 
Reviewed-by: CITOOLS 
Signed-off-by: Patrice Chotard 
---

Changes in v2: None

 configs/stm32mp15_basic_defconfig   | 5 +++--
 configs/stm32mp15_trusted_defconfig | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index ac52155699b3..6781adb81e73 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_STM32MP=y
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x3000
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL=y
 CONFIG_TARGET_STM32MP1=y
@@ -55,8 +55,9 @@ CONFIG_DM_MMC=y
 CONFIG_STM32_SDMMC2=y
 CONFIG_PHY=y
 CONFIG_PHY_STM32_USBPHYC=y
-# CONFIG_PINCTRL_FULL is not set
+CONFIG_PINCONF=y
 # CONFIG_SPL_PINCTRL_FULL is not set
+CONFIG_PINCTRL_STMFX=y
 CONFIG_DM_PMIC=y
 # CONFIG_SPL_PMIC_CHILDREN is not set
 CONFIG_PMIC_STPMIC1=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 0ffea5bfb32c..a050cee6918e 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_STM32MP=y
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x3000
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
@@ -48,7 +48,8 @@ CONFIG_DM_MMC=y
 CONFIG_STM32_SDMMC2=y
 CONFIG_PHY=y
 CONFIG_PHY_STM32_USBPHYC=y
-# CONFIG_PINCTRL_FULL is not set
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_STMFX=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_STPMIC1=y
 CONFIG_DM_REGULATOR_FIXED=y
-- 
1.9.1

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

[U-Boot] [PATCH v2 4/4] ARM: dts: Add STMFX gpio expander support for stm32mp157c-ev1

[Patrice Chotard]

Adds alias to set the pincontrol seq id.
For STMFX gpio expander, force sequence number after
the last bank (GPIOZ) to avoid conflict between STM32MP and STMFX
gpio bank sequence number.


Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 



---

Changes in v2:
  _ Add missing pinctrl2 alias in stm32mp157c-ev1-u-boot.dtsi
  _ Move pinctrl0 and pinctrl1 aliases in stm32mp157c-u-boot.dtsi
  _ Set stmfx_pinctrl status to "okay"

 arch/arm/dts/stm32mp157-u-boot.dtsi  |  2 ++
 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |  2 ++
 arch/arm/dts/stm32mp157c-ev1.dts | 18 ++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-u-boot.dtsi 
b/arch/arm/dts/stm32mp157-u-boot.dtsi
index 2594702c926f..ab6f673ea24c 100644
--- a/arch/arm/dts/stm32mp157-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157-u-boot.dtsi
@@ -17,6 +17,8 @@
gpio9 = &gpioj;
gpio10 = &gpiok;
gpio25 = &gpioz;
+   pinctrl0 = &pinctrl;
+   pinctrl1 = &pinctrl_z;
};
 
config {
diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
index be3b1526288f..6a18d032ae54 100644
--- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
@@ -7,8 +7,10 @@
 
 / {
aliases {
+   gpio26 = &stmfx_pinctrl;
i2c1 = &i2c2;
i2c4 = &i2c5;
+   pinctrl2 = &stmfx_pinctrl;
spi0 = &qspi;
};
 };
diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index e114c9b628b8..3c85909c42bd 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -98,6 +98,24 @@
i2c-scl-rising-time-ns = <185>;
i2c-scl-falling-time-ns = <20>;
status = "okay";
+
+   stmfx: stmfx@42 {
+   compatible = "st,stmfx-0300";
+   reg = <0x42>;
+   interrupts = <8 IRQ_TYPE_EDGE_RISING>;
+   interrupt-parent = <&gpioi>;
+   vdd-supply = <&v3v3>;
+
+   stmfx_pinctrl: stmfx-pin-controller {
+   compatible = "st,stmfx-0300-pinctrl";
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-ranges = <&stmfx_pinctrl 0 0 24>;
+   status = "okay";
+   };
+   };
 };
 
 &i2c5 {
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/4] Add STMFX gpio expander support for stm32mp157c-ev1 board

[Patrice Chotard]

This series adds:
  - STMFX pinctrl driver
  - update STM32MP15 basic and trusted config
  - Add stmfx node in stm32mp157c-ev1 DT
  - Update stm32mp1 board to probe pinctrl drivers early to be
able to hog pins.

There are dependencies with :
  - http://patchwork.ozlabs.org/project/uboot/list/?series=92268
  - http://patchwork.ozlabs.org/project/uboot/list/?series=91422
which must be merged first.


Changes in v2:
  _ Add missing pinctrl2 alias in stm32mp157c-ev1-u-boot.dtsi
  _ Move pinctrl0 and pinctrl1 aliases in stm32mp157c-u-boot.dtsi
  _ Set stmfx_pinctrl status to "okay"

Patrice Chotard (2):
  board: stm32mp1: Force pinctrl driver probe in board_init()
  ARM: dts: Add STMFX gpio expander support for stm32mp157c-ev1

Patrick Delaunay (2):
  pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver
  config: stm32mp15: Enable STMFX support

 arch/arm/dts/stm32mp157-u-boot.dtsi  |   2 +
 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |   2 +
 arch/arm/dts/stm32mp157c-ev1.dts |  18 ++
 board/st/stm32mp1/stm32mp1.c |   9 +
 configs/stm32mp15_basic_defconfig|   5 +-
 configs/stm32mp15_trusted_defconfig  |   5 +-
 drivers/pinctrl/Kconfig  |  19 ++
 drivers/pinctrl/Makefile |   1 +
 drivers/pinctrl/pinctrl-stmfx.c  | 431 +++
 9 files changed, 488 insertions(+), 4 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-stmfx.c

-- 
1.9.1

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

[U-Boot] [PATCH v2 1/4] pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver

[Patrice Chotard]

From: Patrick Delaunay 

This patch adds pinctrl/GPIO driver for STMicroelectronics
Multi-Function eXpander (STMFX) GPIO expander.
STMFX is an I2C slave controller, offering up to 24 GPIOs.
The driver relies on UCLASS_PINCTRL and UCLASS_GPIO.

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
Reviewed-by: CITOOLS 
Reviewed-by: CIBUILD 
---

Changes in v2: None

 drivers/pinctrl/Kconfig |  19 ++
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/pinctrl-stmfx.c | 431 
 3 files changed, 451 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-stmfx.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index be709f73d7df..a0ac167d145a 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -209,6 +209,25 @@ config PINCTRL_STM32
  the GPIO definitions and pin control functions for each available
  multiplex function.
 
+config PINCTRL_STMFX
+   bool "STMicroelectronics STMFX I2C GPIO expander pinctrl driver"
+   depends on DM && PINCTRL_FULL
+   help
+ I2C driver for STMicroelectronics Multi-Function eXpander (STMFX)
+ GPIO expander.
+ Supports pin multiplexing control on stm32 SoCs.
+
+ The driver is controlled by a device tree node which contains both
+ the GPIO definitions and pin control functions for each available
+ multiplex function.
+
+config SPL_PINCTRL_STMFX
+   bool "STMicroelectronics STMFX I2C GPIO expander pinctrl driver in SPL"
+   depends on SPL_PINCTRL_FULL
+   help
+ This option is an SPL-variant of the SPL_PINCTRL_STMFX option.
+ See the help of PINCTRL_STMFX for details.
+
 config ASPEED_AST2500_PINCTRL
   bool "Aspeed AST2500 pin control driver"
   depends on DM && PINCTRL_GENERIC && ASPEED_AST2500
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index e2c2b159d8c8..4b080b74dcd1 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_ARCH_MVEBU)  += mvebu/
 obj-$(CONFIG_PINCTRL_SINGLE)   += pinctrl-single.o
 obj-$(CONFIG_PINCTRL_STI)  += pinctrl-sti.o
 obj-$(CONFIG_PINCTRL_STM32)+= pinctrl_stm32.o
+obj-$(CONFIG_$(SPL_)PINCTRL_STMFX) += pinctrl-stmfx.o
 obj-y  += broadcom/
diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinctrl/pinctrl-stmfx.c
new file mode 100644
index ..5431df9813a1
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-stmfx.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * Driver for STMicroelectronics Multi-Function eXpander (STMFX) GPIO expander
+ * based on Linux driver : pinctrl/pinctrl-stmfx.c
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STMFX pins = GPIO[15:0] + aGPIO[7:0] */
+#define STMFX_MAX_GPIO 16
+#define STMFX_MAX_AGPIO8
+
+/* General */
+#define STMFX_REG_CHIP_ID  0x00 /* R */
+#define STMFX_REG_FW_VERSION_MSB   0x01 /* R */
+#define STMFX_REG_FW_VERSION_LSB   0x02 /* R */
+#define STMFX_REG_SYS_CTRL 0x40 /* RW */
+
+/* MFX boot time is around 10ms, so after reset, we have to wait this delay */
+#define STMFX_BOOT_TIME_MS 10
+
+/* GPIOs expander */
+/* GPIO_STATE1 0x10, GPIO_STATE2 0x11, GPIO_STATE3 0x12 */
+#define STMFX_REG_GPIO_STATE   0x10 /* R */
+/* GPIO_DIR1 0x60, GPIO_DIR2 0x61, GPIO_DIR3 0x63 */
+#define STMFX_REG_GPIO_DIR 0x60 /* RW */
+/* GPIO_TYPE1 0x64, GPIO_TYPE2 0x65, GPIO_TYPE3 0x66 */
+#define STMFX_REG_GPIO_TYPE0x64 /* RW */
+/* GPIO_PUPD1 0x68, GPIO_PUPD2 0x69, GPIO_PUPD3 0x6A */
+#define STMFX_REG_GPIO_PUPD0x68 /* RW */
+/* GPO_SET1 0x6C, GPO_SET2 0x6D, GPO_SET3 0x6E */
+#define STMFX_REG_GPO_SET  0x6C /* RW */
+/* GPO_CLR1 0x70, GPO_CLR2 0x71, GPO_CLR3 0x72 */
+#define STMFX_REG_GPO_CLR  0x70 /* RW */
+
+/* STMFX_REG_CHIP_ID bitfields */
+#define STMFX_REG_CHIP_ID_MASK GENMASK(7, 0)
+
+/* STMFX_REG_SYS_CTRL bitfields */
+#define STMFX_REG_SYS_CTRL_GPIO_EN BIT(0)
+#define STMFX_REG_SYS_CTRL_ALTGPIO_EN  BIT(3)
+#define STMFX_REG_SYS_CTRL_SWRST   BIT(7)
+
+#define NR_GPIO_REGS   3
+#define NR_GPIOS_PER_REG   8
+#define get_reg(offset)((offset) / NR_GPIOS_PER_REG)
+#define get_shift(offset)  ((offset) % NR_GPIOS_PER_REG)
+#define get_mask(offset)   (BIT(get_shift(offset)))
+
+struct stmfx_pinctrl {
+   struct udevice *gpio;
+};
+
+static int stmfx_read(struct udevice *dev, uint offset)
+{
+   return  dm_i2c_reg_read(dev_get_parent(dev), offset);
+}
+
+static int stmfx_write(struct udevice *dev, uint offset, unsigned int val)
+{
+   return dm_i2c_reg_write(dev_get_parent(dev), offset, val);
+}
+
+static int stmfx_gpio_get(struct udevic

Re: [U-Boot] [PATCH 4/6] fdtdec: Implement fdtdec_add_reserved_memory()

[Thierry Reding]

On Sun, Mar 10, 2019 at 03:51:42PM -0600, Simon Glass wrote:
> On Fri, 8 Mar 2019 at 13:11, Thierry Reding  wrote:
> >
> > From: Thierry Reding 
> >
> > This function can be used to add subnodes in the /reserved-memory node.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  include/fdtdec.h |  17 +
> >  lib/fdtdec.c | 158 +++
> >  2 files changed, 175 insertions(+)
> >
> 
> I think an example would be useful, or perhaps a pointer to some docs
> (perhaps DT spec?) showing how this function is used?

Yeah, I can add a pointer to the DT bindings. Do you want me to add a
copy of the DT bindings to the U-Boot source tree, or is it sufficient
to refer to the docs in Linux?

As for an example, patches 5 and 6 show how this should be used. Do you
want an additional example in the comment, or what did you have in mind?

Thierry

> Reviewed-by: Simon Glass 
> 
> 
> 
> > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > index 997103a87cdf..5c9108ced571 100644
> > --- a/include/fdtdec.h
> > +++ b/include/fdtdec.h
> > @@ -979,6 +979,23 @@ int fdtdec_get_max_phandle(const void *blob, uint32_t 
> > *maxp);
> >   */
> >  int fdtdec_set_phandle(void *blob, int node, uint32_t phandle);
> >
> > +/**
> > + * fdtdec_add_reserved_memory() - add or find a reserved-memory node
> > + *
> > + * If a reserved-memory node already exists for the given carveout, a 
> > phandle
> > + * for that node will be returned. Otherwise a new node will be created 
> > and a
> > + * phandle corresponding to it will be returned.
> > + *
> > + * @param blob FDT blob
> > + * @param basename base name of the node to create
> > + * @param carveout information about the carveout region
> > + * @param phandlep return location for the phandle of the carveout 
> > region
> > + * @return 0 on success or a negative error code on failure
> > + */
> > +int fdtdec_add_reserved_memory(void *blob, const char *basename,
> > +  const struct fdt_memory *carveout,
> > +  uint32_t *phandlep);
> > +
> >  /**
> >   * Set up the device tree ready for use
> >   */
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index 9195a05d1129..a8b35c144ae0 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -1287,6 +1287,164 @@ int fdtdec_set_phandle(void *blob, int node, 
> > uint32_t phandle)
> > return 0;
> >  }
> >
> > +static int fdtdec_init_reserved_memory(void *blob)
> > +{
> > +   int na, ns, node, err;
> > +   fdt32_t value;
> > +
> > +   /* inherit #address-cells and #size-cells from the root node */
> > +   na = fdt_address_cells(blob, 0);
> > +   ns = fdt_size_cells(blob, 0);
> > +
> > +   node = fdt_add_subnode(blob, 0, "reserved-memory");
> > +   if (node < 0)
> > +   return node;
> > +
> > +   err = fdt_setprop(blob, node, "ranges", NULL, 0);
> > +   if (err < 0)
> > +   return err;
> > +
> > +   value = cpu_to_fdt32(na);
> > +
> > +   err = fdt_setprop(blob, node, "#address-cells", &value, 
> > sizeof(value));
> > +   if (err < 0)
> > +   return err;
> > +
> > +   value = cpu_to_fdt32(ns);
> > +
> > +   err = fdt_setprop(blob, node, "#size-cells", &value, sizeof(value));
> > +   if (err < 0)
> > +   return err;
> > +
> > +   return node;
> > +}
> > +
> > +static void fdt_addr_unpack(fdt_addr_t addr, fdt32_t *upper, fdt32_t 
> > *lower)
> > +{
> > +#ifdef CONFIG_PHYS_64BIT
> > +   *upper = addr >> 32;
> > +#else
> > +   *upper = 0;
> > +#endif
> > +
> > +   *lower = addr;
> > +}
> > +
> > +static void fdt_size_unpack(fdt_size_t size, fdt32_t *upper, fdt32_t 
> > *lower)
> > +{
> > +#ifdef CONFIG_PHYS_64BIT
> > +   *upper = size >> 32;
> > +#else
> > +   *upper = 0;
> > +#endif
> > +
> > +   *lower = size;
> > +}
> > +
> > +int fdtdec_add_reserved_memory(void *blob, const char *basename,
> > +  const struct fdt_memory *carveout,
> > +  uint32_t *phandlep)
> > +{
> > +   fdt32_t cells[4] = {}, *ptr = cells;
> > +   uint32_t upper, lower, phandle;
> > +   int parent, node, na, ns, err;
> > +   char name[64];
> > +
> > +   /* create an empty /reserved-memory node if one doesn't exist */
> > +   parent = fdt_path_offset(blob, "/reserved-memory");
> > +   if (parent < 0) {
> > +   parent = fdtdec_init_reserved_memory(blob);
> > +   if (parent < 0)
> > +   return parent;
> > +   }
> > +
> > +   /* only 1 or 2 #address-cells and #size-cells are supported */
> > +   na = fdt_address_cells(blob, parent);
> > +   if (na < 1 || na > 2)
> > +   return -FDT_ERR_BADNCELLS;
> > +
> > +   ns = fdt_address_cells(blob, parent);
> > +   if (ns < 1 || ns > 2)
> > +   return -FDT_ERR_BADNCELLS;
> > +
> > +   /* find a matching node an

Re: [U-Boot] [PATCH 3/6] fdtdec: Implement fdtdec_set_phandle()

[Thierry Reding]

On Sun, Mar 10, 2019 at 03:51:40PM -0600, Simon Glass wrote:
> Hi Thierry,
> 
> On Fri, 8 Mar 2019 at 13:11, Thierry Reding  wrote:
> >
> > From: Thierry Reding 
> >
> > This function can be used to set a phandle for a given node.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  include/fdtdec.h | 11 +++
> >  lib/fdtdec.c | 16 
> >  2 files changed, 27 insertions(+)
> 
> This seems OK, although I think it should have a test.

I'll add something to test this to the test_fdtdec command. I'm not sure
how much sense it makes to test this individually, because the test is
fairly elaborate (needs to create one node to reference and another to
reference it from), so perhaps I can just add a complete test that will
at the same time validate that the reserved-memory and carveout stuff
works?

> But what about livetree? I think it would make more sense to add a
> high-level API which can deal with livetree/flattree.

I'm not sure it really makes sense to add this kind of information to a
livetree. The only use-case for this that I have is to convey
information about carveouts to the kernel, so by this information is
added to a DTB that is loaded from external storage along with the
kernel and then modified right before the DTB is passed to the kernel on
boot.

The only case where I think such functionality would be useful in a live
tree is if we construct the live tree in U-Boot, update it and then pass
it to the kernel upon boot. That's not something that works today, and I
can't test any of that, so I'm not sure it makes much sense to implement
it now.

> > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > index 5eb3c0c237a9..997103a87cdf 100644
> > --- a/include/fdtdec.h
> > +++ b/include/fdtdec.h
> > @@ -968,6 +968,17 @@ int fdtdec_setup_memory_banksize(void);
> >   */
> >  int fdtdec_get_max_phandle(const void *blob, uint32_t *maxp);
> >
> > +/**
> > + * fdtdec_set_phandle() - sets the phandle of a given node
> > + *
> > + * @param blob FDT blob
> > + * @param node offset in the FDT blob of the node whose phandle is 
> > to
> > + * be set
> > + * @param phandle  phandle to set for the given node
> > + * @return 0 on success or a negative error code on failure
> > + */
> > +int fdtdec_set_phandle(void *blob, int node, uint32_t phandle);
> > +
> >  /**
> >   * Set up the device tree ready for use
> >   */
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index f2af947c106e..9195a05d1129 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -1271,6 +1271,22 @@ int fdtdec_get_max_phandle(const void *blob, 
> > uint32_t *maxp)
> > return 0;
> >  }
> >
> > +int fdtdec_set_phandle(void *blob, int node, uint32_t phandle)
> > +{
> > +   fdt32_t value = cpu_to_fdt32(phandle);
> > +   int err;
> > +
> > +   err = fdt_setprop(blob, node, "linux,phandle", &value, 
> > sizeof(value));
> > +   if (err < 0)
> > +   return err;
> 
> Why set both properties?

I was trying to mimic the output of DTC, but looking again it seems like
it doesn't even produce linux,phandle properties. Doing some research it
was changed to only produce "phandle" properties in v1.4.5 and the
commit message says:

commit 0016f8c2aa32423f680ec6e94a00f1095b81b5fc
Author: Rob Herring 
Date:   Wed Jul 12 17:20:30 2017 -0500

dtc: change default phandles to ePAPR style instead of both

Currently, both legacy (linux,phandle) and ePAPR (phandle) 
properties
are inserted into dtbs by default. The newer ePAPR style has been
supported in dtc and Linux kernel for 7 years. That should be a long
enough transition period. We can save a little space by not putting 
both
into the dtb.

Signed-off-by: Rob Herring 
Signed-off-by: David Gibson 

So perhaps we no longer need to generate this from U-Boot either. I'll
remove the linux,phandle code.

Thierry


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

[U-Boot] [PATCH] MC : Report extra reserved memory to Linux

[Meenakshi Aggarwal]

For MC, 512 MB DDR is reserved because of MC's alignment
requirement.
But for MC binaries needing 128MB or 256MB DDR memory, rest
of the memory is a waste. So reporting this extra memory to
Linux through dtb memory fixup.

Signed-off-by: Meenakshi Aggarwal 
---
 board/freescale/lx2160a/lx2160a.c | 27 ++-
 drivers/net/fsl-mc/mc.c   | 13 +
 include/fsl-mc/fsl_mc.h   |  1 +
 3 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index ad72eed..3cbb7d1 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -532,8 +532,15 @@ void board_quiesce_devices(void)
 int ft_board_setup(void *blob, bd_t *bd)
 {
int i;
+   bool mc_memory_bank = false;
+
+#ifdef CONFIG_FSL_MC_ENET
+   u64 base[CONFIG_NR_DRAM_BANKS + 1];
+   u64 size[CONFIG_NR_DRAM_BANKS + 1];
+#else
u64 base[CONFIG_NR_DRAM_BANKS];
u64 size[CONFIG_NR_DRAM_BANKS];
+#endif
 
ft_cpu_setup(blob, bd);
 
@@ -556,7 +563,25 @@ int ft_board_setup(void *blob, bd_t *bd)
size[2] = gd->arch.resv_ram - base[2];
 #endif
 
-   fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
+#ifdef CONFIG_FSL_MC_ENET
+   fdt_fixup_mc_ddr(&base[3], &size[3]);
+
+   if (base[3] != 0) {
+   for (i = 0; i <= CONFIG_NR_DRAM_BANKS; i++) {
+   if (base[i] == 0 && size[i] == 0) {
+   base[i] = base[3];
+   size[i] = size[3];
+   break;
+   }
+   }
+   if (i == CONFIG_NR_DRAM_BANKS)
+   mc_memory_bank = true;
+   }
+#endif
+   if (mc_memory_bank)
+   fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS + 
1);
+   else
+   fdt_fixup_memory_banks(blob, base, size, CONFIG_NR_DRAM_BANKS);
 
 #ifdef CONFIG_USB
fsl_fdt_fixup_dr_usb(blob, bd);
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index dddc9cc..79a38d6 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -285,6 +285,19 @@ static int mc_fixup_dpl_mac_addr(void *blob, int dpmac_id,
 MC_FIXUP_DPL);
 }
 
+void fdt_fixup_mc_ddr(u64* base, u64* size)
+{
+   u64 mc_size = mc_get_dram_block_size();
+
+   if (mc_size < MC_DRAM_BLOCK_DEFAULT_SIZE) {
+   *base = mc_get_dram_addr() + mc_size;
+   *size = MC_DRAM_BLOCK_DEFAULT_SIZE - mc_size;
+   } else {
+   *base = 0;
+   *size = 0;
+   }
+}
+
 void fdt_fsl_mc_fixup_iommu_map_entry(void *blob)
 {
u32 *prop;
diff --git a/include/fsl-mc/fsl_mc.h b/include/fsl-mc/fsl_mc.h
index aef40d3..30f961b 100644
--- a/include/fsl-mc/fsl_mc.h
+++ b/include/fsl-mc/fsl_mc.h
@@ -54,6 +54,7 @@ struct mc_ccsr_registers {
 void fdt_fsl_mc_fixup_iommu_map_entry(void *blob);
 int get_mc_boot_status(void);
 int get_dpl_apply_status(void);
+void fdt_fixup_mc_ddr(u64 *base, u64* size);
 #ifdef CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET
 int get_aiop_apply_status(void);
 #endif
-- 
1.9.1

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

Re: [U-Boot] Custom SPL for im.X6UL

[Peng Fan]

Hi 

> -Original Message-
> From: Araya, Jose [mailto:j.ar...@sensopart.de]
> Sent: 2019年3月11日 16:50
> To: Peng Fan 
> Subject: AW: [U-Boot] Custom SPL for im.X6UL
> 
> Hi Peng,
> 
> thanks for answering! Just a follow up question:
> 
> Does the U-boot from NXP run in OCRAM or in DRAM?

For i.MX6UL, NXP released U-Boot runs from DRAM, no SPL.

> 
> I read that a multi-stage boot is faster and more efficient, that makes me
> think that if I use a single-stage boot it should run in OCRAM (which is 
> limited)
> and that's why the multi-stage (which uses DRAM) is actually faster. That's
> why my question arises.

You could use the upstream uboot for i.MX6UL, it supports SPL runs from OCRAM.

Regards,
Peng.

> 
> Source:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcom
> munity.nxp.com%2Fthread%2F438580&data=02%7C01%7Cpeng.fan%40
> nxp.com%7C96b71f4edfc34b0b0ef008d6a5fe9d99%7C686ea1d3bc2b4c6fa92
> cd99c5c301635%7C0%7C0%7C636878910318937272&sdata=yyE40Ut0
> no9nQHAWWusnk2reszG2WuEOI0Po7pr6ahI%3D&reserved=0
> 
> Thanks!
> 
> Moises
> 
> -Ursprüngliche Nachricht-
> Von: Peng Fan 
> Gesendet: Samstag, 9. März 2019 02:11
> An: Araya, Jose ; u-boot@lists.denx.de
> Betreff: RE: [U-Boot] Custom SPL for im.X6UL
> 
> 
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Araya,
> > Jose
> > Sent: 2019年3月9日 0:59
> > To: u-boot@lists.denx.de
> > Subject: [U-Boot] Custom SPL for im.X6UL
> >
> > Hello everyone,
> >
> > I would like to ask what would be a good starting point to have a
> > custom multi-stage booting for the NXP i.mx6UL processor?
> >
> > Basically I need to be able to configure an FPGA before the U-Boot is
> executed.
> > The reason for that is that the PGA must be configured so that the
> > im6UL can have a physical connection to the DRAM. To clarify:
> >
> >
> > -   In the circuit, the DRAM will be multiplexed by an FPGA. If the
> FPGA
> > is not configured, the imx6UL has no access to the DRAM.
> >
> > -   The imx6UL has a direct SPI connection to the flash and to the
> FPGA,
> > so all I need is to take the bitstream from a given location in the
> > FLASH and load it into the FPGA, then just wait for a flag (GPIO?)
> > saying that the FPGA was successfully configured and keep the booting
> > process in the processor as normal.
> >
> >
> > As I haven't done yet anything similar, just wanted to know if you
> > have any recommendations regarding where to start and some  hints to
> proceed.
> 
> SPL might help here, because it runs in OCRAM.
> 
> Regards,
> Peng.
> 
> >
> > Thanks in advance!
> >
> > Bests,
> >
> > Jose Moises
> >
> >
> >
> >
> > SensoPart Industriesensorik GmbH
> > Am Wiedenbach 1 | 79695 Wieden  Amtsgericht Freiburg HRB 660163
> > Gesch?ftsf?hrer: Dr. Theodor Wanner
> >
> [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> >
> w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_sensopart.png&data=
> >
> 02%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18
> >
> c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63687678551123
> >
> 6465&sdata=kdlCeiA68J03mVvsfo7LLum%2BJaK6n9Tj%2BzEDIsW3XhQ
> > %3D&reserved=0]
> >
>  >
> w.sensopart.com%2F&data=02%7C01%7CPeng.Fan%40nxp.com%7C642
> >
> 764588c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6fa92cd99c5c301635
> > %7C0%7C1%7C636876785511236465&sdata=5grDBEFPHFgII%2FwJx8
> N
> > qvbDCljp9ye%2F9R8T6AeCT12Q%3D&reserved=0>
> >
> [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> >
> w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_linkedin.png&data=0
> >
> 2%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c
> > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6368767855112
> 36
> >
> 465&sdata=DB4s4lvXipPogJ%2BWE61YNv9p7vbx4gThM6EjFkXCjuI%3D
> > &reserved=0]
> >
>  >
> ww.linkedin.com%2Fcompany%2Fsensopart%2F&data=02%7C01%7CPe
> >
> ng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C686ea1d3
> >
> bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636876785511236465&sda
> >
> ta=JsDOBDl5aedr8pz1zQtw55WDxdkZGiXEfrhF8GMYRAQ%3D&reserved
> > =0>
> >
> [https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> >
> w.sensopart.com%2F%2Fimages%2Foutlook%2Fsi_youtube.png&data=0
> >
> 2%7C01%7CPeng.Fan%40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c
> > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6368767855112
> 36
> >
> 465&sdata=xRbXYdLlBnsXaGA1sPjNfIcX%2B6KPR6l7eWdrLWRj00s%3D&
> > amp;reserved=0]
> >
>  >
> ww.youtube.com%2Fuser%2FSensoPart&data=02%7C01%7CPeng.Fan%
> >
> 40nxp.com%7C642764588c8048fdcb1b08d6a40fe18c%7C686ea1d3bc2b4c6f
> >
> a92cd99c5c301635%7C0%7C1%7C636876785511236465&sdata=bJ0Mk
> >
> iBcIQoumP38uQkP4nkdW%2F12VPaJ7I3Yy7Bv%2BFc%3D&reserved=0>
> >
> [https://emea01.safelinks.protection.outlook.com/?url=htt

Re: [U-Boot] [PATCH 2/6] fdtdec: Implement fdtdec_get_max_phandle()

[Thierry Reding]

On Sun, Mar 10, 2019 at 03:51:31PM -0600, Simon Glass wrote:
> Hi Thierry,
> 
> On Fri, 8 Mar 2019 at 13:11, Thierry Reding  wrote:
> >
> > From: Thierry Reding 
> >
> > This function allows looking up the highest phandle value stored in a
> > device tree, which is useful to determine the next best phandle value
> > for new nodes.
> >
> > Signed-off-by: Thierry Reding 
> > ---
> >  include/fdtdec.h | 12 
> >  lib/fdtdec.c | 28 
> >  2 files changed, 40 insertions(+)
> 
> Can we use fdt_get_max_phandle() instead? If not, could you please add
> a bit more detail to the commit message as we might consider changing
> the upstream function.

fdt_get_max_phandle() has a slightly awkward signature. It returns the
phandle via the return value, which means that it can distinguish
between error conditions and also uses 0 and -1 to signal no phandle
found and error conditions, respectively. Using the function requires
weird looking code like this:

uint32_t phandle;

phandle = fdt_get_max_phandle(fdt);
if (phandle == 0 || phandle == (uint32_t)-1)
/* process error */;

So the goal here was to add an alternative that would provide a more
standard interface where a regular error could be returned via the
return value and the phandle would be stored in an output parameter on
success.

I specifically didn't want to update the upstream function because it
was introduced about 2.5 years ago and will probably be used by some
number of users. I'm not sure if there's a stable API policy for libfdt,
but I would expect a lot of users to be annoyed if we just changed the
signature of fdt_get_max_phandle().

That said, perhaps another alternative would be to implement this as a
different function. If you look at the subsequent patches, the goal is
to generate a new phandle for newly added nodes, so perhaps something
like this could work:

int fdtdec_generate_phandle(const void *fdt, uint32_t *phandle);

That would be slightly more in line with the higher level of fdtdec
compared to libfdt.

Or perhaps you'd prefer fdt_generate_phandle() in libfdt?

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 v2 0/9] SMP support for RISC-V

[Andreas Schwab]

On Mär 08 2019, Anup Patel  wrote:

> The reset button works fine for me an Atish. I am sure it works fine for lot 
> of
> other folks too.

There is no issue with the reset button, only with openSBI.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] dts: force dtb recompilation

[Patrick DELAUNAY]

Hi Masahiro,

> From: Masahiro Yamada 
> Sent: samedi 9 mars 2019 16:57
> 
> Hi Patrick,
> 
> 
> On Wed, Mar 6, 2019 at 10:31 PM Patrick Delaunay 
> wrote:
> >
> > The dependency for .dtb = .dts is not enough in dts Makefile, as the
> > dts files are dts pre-proprocessed (include dtsi files, as specific
> > *-u-boot.dtsi).
> >
> > For arm architecture, the dependency is correctly managed in makefile
> > of arch/arm/dts with .cmd files, it is needed to execute make in this
> > directory.
> >
> > Signed-off-by: Patrick Delaunay 
> > ---
> > Issue see on stm32mp1 board
> >
> > stm32mp157c-ed1.dts is included in stm32mp157c-ev1.dts and dependency
> > is not correctly managed
> > (ev1 is not recompiled when ed1 is modified)
> 
> 
> Do you still see this issue?

In fact no: I don’t' see the issue anymore on v2019.04-rc3

I detect the issue on v2019.04-rc2... 
but I don't check it again when I push my patch on the master branch top.
 
> I do not see the problem any more
> because the following commit fixed it.
> 
> commit 2737dfe096b6c34654734a5a4dc5f4b4962c5617
> Author: Stephen Warren 
> Date:   Tue Feb 26 12:20:25 2019 -0700
> 
> kbuild: make arch-dtbs target PHONY
> 
> 
> Could you test it on the latest git version?
> 
 
Tested on 
- v2019.04-rc2 => reproduced
- v2019.04-rc3 => NOT reproduced
- v2019.04-rc2 + Stephen path => NOT reproduced

So you are right, the Stephen patch solve already my issue 
and my patch can be dropped.
 
> >
> >  dts/Makefile | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/dts/Makefile b/dts/Makefile index a7a6043..bcd611f 100644
> > --- a/dts/Makefile
> > +++ b/dts/Makefile
> > @@ -17,7 +17,6 @@ ifneq ($(EXT_DTB),)
> >  DTB := $(EXT_DTB)
> >  else
> >  DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb -dtb_depends +=
> > $(DTB:.dtb=.dts)  endif
> >
> >  $(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE @@ -28,7
> > +27,7 @@ $(obj)/dt.dtb: $(DTB) FORCE
> >
> >  targets += dt.dtb dt-spl.dtb
> >
> > -$(DTB): $(dtb_depends)
> > +$(DTB): $(dtb_depends) FORCE
> >  ifeq ($(EXT_DTB),)
> > $(Q)$(MAKE) $(build)=$(ARCH_PATH) $@  endif
> > --
> > 2.7.4
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> 
> 
> 
> --
> Best Regards
> Masahiro Yamada

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

[U-Boot] [PATCH 2/4] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

[Jagan Teki]

u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
which is U-Boot specific devicetrees binding.

Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
bindings will move it future based on the requirement.

This would help to sync the devicetrees from Linux whenever required
instead of adding specific nodes.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3399-evb.dts | 1 -
 arch/arm/dts/rk3399-firefly.dts | 1 -
 arch/arm/dts/rk3399-puma.dtsi   | 1 -
 arch/arm/dts/rk3399-u-boot.dtsi | 8 
 4 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index ce004d0d18..9162f3dd50 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -155,7 +155,6 @@
 };
 
 &sdmmc {
-   u-boot,dm-pre-reloc;
bus-width = <4>;
status = "okay";
 };
diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
index f90e7e88db..46f2ffaf8d 100644
--- a/arch/arm/dts/rk3399-firefly.dts
+++ b/arch/arm/dts/rk3399-firefly.dts
@@ -592,7 +592,6 @@
 };
 
 &sdmmc {
-   u-boot,dm-pre-reloc;
bus-width = <4>;
status = "okay";
 };
diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 8304f67192..9049694243 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -492,7 +492,6 @@
 };
 
 &sdmmc {
-   u-boot,dm-pre-reloc;
clock-frequency = <15000>;
max-frequency = <4000>;
supports-sd;
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
new file mode 100644
index 00..f533ed95eb
--- /dev/null
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki 
+ */
+
+&sdmmc {
+   u-boot,dm-pre-reloc;
+};
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH 4/4] doc: rockchip: Add global doc for rk3399 build/run

[Jagan Teki]

Since rockchip have an individual doc/README.rockchip, it would
be better to update the same instead of maintaining it separately
in board files.

So, add the documentation for rk3399
- procedure to build
- procedure to boot from SD

Signed-off-by: Jagan Teki 
---
 doc/README.rockchip | 69 +
 1 file changed, 69 insertions(+)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index ec10ebbc26..b8d693bbc9 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -88,8 +88,36 @@ One RV3188 baord is supported:
 
 For example:
 
+1. To build RK3288 board:
+
CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all
 
+2. To build RK3399 board:
+
+   (export cross compiler path for aarch64)
+
+   2.1 Compile ATF
+
+   $ git clone https://github.com/ARM-software/arm-trusted-firmware.git
+   $ cd arm-trusted-firmware
+
+   (export cross compiler path for Cortex-M0 MCU likely arm-none-eabi-)
+   $ make realclean
+   $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
+
+   (copy bl31.elf U-Boot root dir)
+   $ cp build/rk3399/release/bl31/bl31.elf /path/to/u-boot
+
+   2.2 Compile U-Boot
+
+   $ cd /path/to/u-boot
+   $ make orangepi-rk3399_defconfig
+   $ make
+   $ make u-boot.itb
+
+   (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get
+   spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL)
+
 (or you can use another cross compiler if you prefer)
 
 
@@ -225,6 +253,45 @@ tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out
 truncate -s %2048 u-boot.bin
 cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 
7C4E0304550509072D2C7B38170D1711' >> out
 
+Booting from an SD card on RK3399
+=
+
+To write an image that boots from an SD card (assumed to be /dev/sdc):
+
+1. Prefix rk3399 header to SPL image
+
+   $ cd /path/to/u-boot
+   $ ./tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl-dtb.bin out
+
+2. Write prefixed SPL at 64th sector
+
+   $ sudo dd if=out of=/dev/sdc seek=64
+
+3. Write U-Boot proper at 16384 sector
+
+   $ sudo dd if=u-boot.itb of=/dev/sdc seek=16384
+   $ sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+U-Boot SPL board init
+Trying to boot from MMC1
+
+
+U-Boot 2019.01-4-g14db5ee998 (Mar 11 2019 - 13:18:41 +0530)
+
+Model: Orange Pi RK3399 Board
+DRAM:  2 GiB
+MMC:   dwmmc@fe31: 2, dwmmc@fe32: 1, sdhci@fe33: 0
+Loading Environment from MMC... OK
+In:serial@ff1a
+Out:   serial@ff1a
+Err:   serial@ff1a
+Model: Orange Pi RK3399 Board
+Net:   eth0: ethernet@fe30
+Hit any key to stop autoboot:  0
+=>
 
 Using fastboot on rk3288
 
@@ -385,5 +452,7 @@ There are some documents about partitions in the links 
below.
 http://rockchip.wikidot.com/partitions
 
 --
+Jagan Teki 
+11 Mar 2019
 Simon Glass 
 24 June 2015
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH 3/4] rockchip: rk3399: Add Orangepi RK3399 support

[Jagan Teki]

Add initial support for Orangepi RK3399 board.

Specification
- Rockchip RK3399
- 2GB/4GB DDR3
- 16GB eMMC
- SD card slot
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- Mini PCIe
- Sensors, Keys etc
- DC12V-2A and DC5V-2A

Commit details about Linux DTS sync:
"arm64: dts: rockchip: Add support for the Orange Pi RK3399"
(sha1: d3e71487a790979057c0fdbf32f85033639c16e6)

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
 arch/arm/dts/rk3399-orangepi.dts | 771 +++
 board/rockchip/evb_rk3399/MAINTAINERS|   7 +
 configs/orangepi-rk3399_defconfig|  75 +++
 5 files changed, 861 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi.dts
 create mode 100644 configs/orangepi-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 876c032d11..9033586edc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -50,6 +50,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3368-px5-evb.dtb \
rk3399-evb.dtb \
rk3399-firefly.dtb \
+   rk3399-orangepi.dtb \
rk3399-puma-ddr1333.dtb \
rk3399-puma-ddr1600.dtb \
rk3399-puma-ddr1866.dtb \
diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi 
b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
new file mode 100644
index 00..236b61d78d
--- /dev/null
+++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki 
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-ddr3-1333.dtsi"
diff --git a/arch/arm/dts/rk3399-orangepi.dts b/arch/arm/dts/rk3399-orangepi.dts
new file mode 100644
index 00..cf37b96a6b
--- /dev/null
+++ b/arch/arm/dts/rk3399-orangepi.dts
@@ -0,0 +1,771 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "dt-bindings/pwm/pwm.h"
+#include "dt-bindings/input/input.h"
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+   model = "Orange Pi RK3399 Board";
+   compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   clkin_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "clkin_gmac";
+   #clock-cells = <0>;
+   };
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = <&saradc 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   button-up {
+   label = "Volume Up";
+   linux,code = ;
+   press-threshold-microvolt = <10>;
+   };
+
+   button-down {
+   label = "Volume Down";
+   linux,code = ;
+   press-threshold-microvolt = <30>;
+   };
+
+   back {
+   label = "Back";
+   linux,code = ;
+   press-threshold-microvolt = <985000>;
+   };
+
+   menu {
+   label = "Menu";
+   linux,code = ;
+   press-threshold-microvolt = <1314000>;
+   };
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   keys: gpio-keys {
+   compatible = "gpio-keys";
+   autorepeat;
+
+   power {
+   debounce-interval = <100>;
+   gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+   label = "GPIO Power";
+   linux,code = ;
+   linux,input-type = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwr_btn>;
+   wakeup-source;
+   };
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   clocks = <&rk808 1>;
+   clock-names = "ext_clock";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_reg_on_h>;
+   reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+   };
+
+   /* switched by pmic_sleep */
+   vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc1v8_s3";
+   regulator-always-

[U-Boot] [PATCH 1/4] rockchip: dts: rk3399: Sync rk3399-opp from Linux

[Jagan Teki]

Sync rk3399-opp.dtsi from Linux.

Linux commit details about the rk3399-opp.dtsi sync:
"arm64: dts: rockchip: use SPDX-License-Identifier"
(sha1: 4ee99cebd486238ac433da823b95cc5f8d8a6905)

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3399-opp.dtsi | 133 +++
 1 file changed, 133 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-opp.dtsi

diff --git a/arch/arm/dts/rk3399-opp.dtsi b/arch/arm/dts/rk3399-opp.dtsi
new file mode 100644
index 00..d6f1095abb
--- /dev/null
+++ b/arch/arm/dts/rk3399-opp.dtsi
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+/ {
+   cluster0_opp: opp-table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <80>;
+   clock-latency-ns = <4>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <85>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <925000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <100>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <141600>;
+   opp-microvolt = <1125000>;
+   };
+   };
+
+   cluster1_opp: opp-table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp00 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <80>;
+   clock-latency-ns = <4>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <95>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <141600>;
+   opp-microvolt = <1025000>;
+   };
+   opp06 {
+   opp-hz = /bits/ 64 <160800>;
+   opp-microvolt = <110>;
+   };
+   opp07 {
+   opp-hz = /bits/ 64 <18>;
+   opp-microvolt = <120>;
+   };
+   };
+
+   gpu_opp_table: opp-table2 {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <80>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <29700>;
+   opp-microvolt = <80>;
+   };
+   opp02 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+   opp03 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <875000>;
+   };
+   opp04 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <925000>;
+   };
+   opp05 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <110>;
+   };
+   };
+};
+
+&cpu_l0 {
+   operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l1 {
+   operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l2 {
+   operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l3 {
+   operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_b0 {
+   operating-points-v2 = <&cluster1_opp>;
+};
+
+&cpu_b1 {
+   operating-points-v2 = <&cluster1_opp>;
+};
+
+&gpu {
+   operating-points-v2 = <&gpu_opp_table>;
+};
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH 2/2] tools: fit_image: Add the loadable property to configs

[Abel Vesa]

When running mkimage with "-f auto", the loadable property
needs to be set in order to allow SPL FIT support to boot.

Signed-off-by: Abel Vesa 
---
 tools/fit_image.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/fit_image.c b/tools/fit_image.c
index 4b62635..3b867e0 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -298,6 +298,7 @@ static void fit_write_configs(struct image_tool_params 
*params, char *fdt)
typename = genimg_get_type_short_name(params->fit_image_type);
snprintf(str, sizeof(str), "%s-1", typename);
fdt_property_string(fdt, typename, str);
+   fdt_property_string(fdt, FIT_LOADABLE_PROP, str);
 
if (params->fit_ramdisk)
fdt_property_string(fdt, FIT_RAMDISK_PROP,
-- 
2.7.4

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

[U-Boot] [PATCH 1/2] common: spl_fit: Default to IH_OS_U_BOOT if FIT_IMAGE_TINY enabled

[Abel Vesa]

If FIT_IMAGE_TINY is enabled, spl_fit_image_get_os returns -ENOTSUPP.
In this case, we should default to IH_OS_U_BOOT not to IH_OS_INVALID.

Signed-off-by: Abel Vesa 
---
 common/spl/spl_fit.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index db43626..b190612 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -491,6 +491,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 
if (!spl_fit_image_get_os(fit, node, &os_type))
debug("Loadable is %s\n", genimg_get_os_name(os_type));
+   else
+   os_type = IH_OS_U_BOOT;
 
if (os_type == IH_OS_U_BOOT) {
spl_fit_append_fdt(&image_info, info, sector,
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 1/1] efi_loader: Patch non-runtime code out at ExitBootServices already

[Ard Biesheuvel]

On Mon, 11 Mar 2019 at 01:16, Heinrich Schuchardt  wrote:
>
> From: Alexander Graf 
>
> While discussing something compeltely different, Ard pointed out
> that it might be legal to omit calling SetVirtualAddressMap altogether.
>
> There is even a patch on the Linux Kernel Mailing List that implements
> such behavior by now:
>
>   https://patchwork.kernel.org/patch/10782393/
>
> While that sounds great, we currently rely on the SetVirtualAddressMap
> call to remove all references to code that would not work outside of
> boot services.
>
> So let's patch out those bits already on the call to ExitBootServices,
> so that we can successfully run even when an OS chooses to omit
> any call to SetVirtualAddressMap.
>
> Reported-by: Ard Biesheuvel 
> Signed-off-by: Alexander Graf 
>
> OpenBSD is not calling SetVirtualAddressMap on ARM 32 bit.
>

I take it this means that OpenBSD does not support runtime services at
all on 32-bit ARM?


> Adjust selftest: expect 'U-Boot' instead of 'resetting'.
>
> Reviewed-by: Heinrich Schuchardt 
> ---
> v4
> Adjust selftest: expect 'U-Boot' instead of 'resetting'.
> (by fault sent as v2)
> v3
> Add link to upstream Linux patch
> v2
> Add missing icache invalidation
> ---
>  include/efi_loader.h   |  2 ++
>  lib/efi_loader/efi_boottime.c  |  1 +
>  lib/efi_loader/efi_runtime.c   | 29 -
>  test/py/tests/test_efi_selftest.py |  4 ++--
>  4 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 512880ab8fb..82db7775c72 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -310,6 +310,8 @@ void efi_save_gd(void);
>  void efi_restore_gd(void);
>  /* Call this to relocate the runtime section to an address space */
>  void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
> +/* Call this when we start to live in a runtime only world */
> +void efi_runtime_detach(ulong offset);
>  /* Call this to set the current device name */
>  void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
>  /* Add a new object to the object list. */
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index bd8b8a17ae7..233bca78e0a 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1967,6 +1967,7 @@ static efi_status_t EFIAPI 
> efi_exit_boot_services(efi_handle_t image_handle,
> bootm_disable_interrupts();
>
> /* Disable boot time services */
> +   efi_runtime_detach((ulong)gd->relocaddr);
> systab.con_in_handle = NULL;
> systab.con_in = NULL;
> systab.con_out_handle = NULL;
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 636dfdab39d..17d22d429e2 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -276,15 +276,11 @@ struct efi_runtime_detach_list_struct {
> void *patchto;
>  };
>
> -static const struct efi_runtime_detach_list_struct efi_runtime_detach_list[] 
> = {
> +static struct efi_runtime_detach_list_struct efi_runtime_detach_list[] = {
> {
> /* do_reset is gone */
> .ptr = &efi_runtime_services.reset_system,
> .patchto = efi_reset_system,
> -   }, {
> -   /* invalidate_*cache_all are gone */
> -   .ptr = &efi_runtime_services.set_virtual_address_map,
> -   .patchto = &efi_unimplemented,
> }, {
> /* RTC accessors are gone */
> .ptr = &efi_runtime_services.get_time,
> @@ -328,7 +324,15 @@ static bool efi_runtime_tobedetached(void *p)
> return false;
>  }
>
> -static void efi_runtime_detach(ulong offset)
> +/**
> + * efi_runtime_detach() - Remove any dependency on non-runtime sections
> + *
> + * This function patches all remaining code to be self-sufficient inside
> + * runtime sections. Any calls to non-runtime will be removed after this.
> + *
> + * @offset:relocaddr for pre-set_v_a_space, offset to VA after
> + */
> +__efi_runtime void efi_runtime_detach(ulong offset)
>  {
> int i;
> ulong patchoff = offset - (ulong)gd->relocaddr;
> @@ -344,6 +348,8 @@ static void efi_runtime_detach(ulong offset)
>
> /* Update CRC32 */
> efi_update_table_header_crc32(&efi_runtime_services.hdr);
> +
> +invalidate_icache_all();
>  }
>
>  /* Relocate EFI runtime to uboot_reloc_base = offset */
> @@ -430,19 +436,25 @@ void efi_runtime_relocate(ulong offset, struct 
> efi_mem_desc *map)
>   * @virtmap:   virtual address mapping information
>   * Return: status code
>   */
> -static efi_status_t EFIAPI efi_set_virtual_address_map(
> +static __efi_runtime efi_status_t EFIAPI efi_set_virtual_address_map(
> unsigned long memory_map_size,
> unsigned long descriptor_size,
> ui