Re: [U-Boot] [PATCH 24/30] riscv: save hart ID and device tree passed by prior boot stage

[Rick Chen]

> > >
> > > Store the hart ID and device tree passed by the prior boot stage (in
> > > a0 and a1) in registers s0 and s1. Replace one use of s1 in start.S to
> > > avoid overwriting it.
> > >
> > > The device tree is also stored in memory to make it available to
> > > u-boot
> >
> > nits: U-Boot
> >
> > > with the configuration CONFIG_OF_PRIOR_STAGE.
> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > >  arch/riscv/cpu/cpu.c   |  6 ++
> > >  arch/riscv/cpu/start.S | 12 ++--
> > >  2 files changed, 16 insertions(+), 2 deletions(-)
> > >
> >
> > Reviewed-by: Bin Meng 

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

Re: [U-Boot] [linux-sunxi] [PATCH 5/5] sunxi: doc: Add basic fastboot example

[Jonathan Liu]

Hi Priit,

On Wed, 24 Oct 2018 at 04:21, Priit Laes  wrote:
>
> From: Priit Laes 
>
> Signed-off-by: Priit Laes 
> ---
>  board/sunxi/README.fastboot | 98 ++-
>  1 file changed, 98 insertions(+)
>  create mode 100644 board/sunxi/README.fastboot
>
> diff --git a/board/sunxi/README.fastboot b/board/sunxi/README.fastboot
> new file mode 100644
> index 000..470fa6f
> --- /dev/null
> +++ b/board/sunxi/README.fastboot
> @@ -0,0 +1,98 @@
> +Using fastboot on sunxi devices
> +===
> +

> +Fastboot is a diagnostic protocol, primarily used to modify the
> +filesystems on the flash device via USB or UDP. It requires that
> +the device is started in a boot loader or Seconday Boot Loader mode.

"Seconday" -> "Secondary"

> +
> +This document currently walks through an installation with a device
> +with eMMC storage.
> +
> +Prerequisites
> +-
> +
> +* fastboot binaries installed on client machine
> +* sunxi-tools installed on client machine (optional)
> +* u-boot tools (mkimage)
> +* u-boot binaries for the target sunxi device
> +* filesystem images
> +  * root file system containing operating system
> +  * vfat file system
> +* Sunxi device connected to client via OTG port
> +
> +Getting your device into Fastboot mode
> +--
> +
> +To enter into fastboot mode, execute the `fastboot` command in
> +U-Boot:
> +
> +$ fastboot usb 0
> +
> +On the client machine, you can check whether the device is visible
> +using the `fastboot devices` command. And for fun, you can also
> +fetch the bootloader version using the fastboot protocol:
> +
> +$ fastboot devices
> +1234567890abcdef   fastboot
> +$ fastboot getvar bootloader-version
> +bootloader-version: U-Boot 2018.11-rc2-00033-ge3beca3a2f
> +finished. total time: 0.000s
> +
> +Preparing the device for flashing
> +-
> +
> +Now that the device is in the fastboot mode, we can continue with
> +creating the partitions on the device. By default, u-boot for sunxi
> +defines following partitions:
> +
> +* loader1 - partition for secondary program loader
> +* loader2 - partition for u-boot
> +* esp - EFI system partition, also used for u-boot to look up boot.scr
> +* system  - Root partition for system
> +
> +These partitions have also assigned GUID's according to Discoverable
> +Partitions Specification [1], to enable automatic discovery of partitions
> +and their mountpoints.
> +
> +You can start by formatting the internal storage by executing the
> +`fastboot oem format` command from client:
> +
> +$ fastboot oem format
> +
> +This equivalent to running the `gpt write mmc 1 $partitions` from u-boot.
> +
> +[1] 
> https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> +
> +Flashing the device
> +---
> +
> +Now that we have the partitions created, all that is left for us
> +is to flash the data.
> +

> +`loader1` is used for storing the Seconday Program Loader, in our
> +case, it is the `spl/sunxi-spl.bin` in the u-boot directory:

"Seconday" -> "Secondary"

> +
> +$ fastboot flash loader1 spl/sunxi-spl.bin
> +
> +`loader2` is for storing the u-boot binary. `u-boot.img` in the
> +u-boot source directory:
> +
> +$ fastboot flash loader2 u-boot.img
> +
> +`esp` partition (EFI System Partition) can be kept empty, although
> +if it is VFAT partition, u-boot automatically looks up the `boot.scr`
> +file for device-specific configuration. (You can create empty vfat
> +partition by `fallocate -l 32M esp.img && mkfs.vfat esp.img`)
> +
> +$ fastboot flash esp esp.img
> +
> +`system` partition is where the operating system resides. Creating
> +that is left as an exercise to the reader.
> +
> +$ fastboot flash system system.img
> +
> +Now, if everything has been properly set up (aka proper kernel
> +with machine-specific dtb installed on system.img, and boot.scr
> +on esp partition), you can reboot the machine:
> +
> +$ fastboot reboot
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [U-Boot] [PATCH 23/30] riscv: do not blindly modify the mstatus CSR

[Rick Chen]

> > >
> > > The mstatus CSR includes WPRI (writes preserve values, reads ignore
> > > values) fields and must therefore not be set to zero without
> > > preserving these fields. It is not apparent why mstatus is set to zero
> > > here since it is not required for u-boot to run. Remove it.
> >
> > nits: U-Boot
> >
> > >
> > > This instruction and others encode zero as an immediate.  RISC-V has
> > > the zero register for this purpose. Replace the immediates with the
> > > zero register.
> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > >  arch/riscv/cpu/start.S | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> >
> > Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S

[Rick Chen]

Rick Chen  於 2018年10月24日 週三 下午1:20寫道：
>
> Bin Meng  於 2018年10月24日 週三 上午11:34寫道：
> >
> > Hi Rich,
> >
> > On Wed, Oct 24, 2018 at 10:37 AM Rick Chen  wrote:
> > >
> > > > > > The labels nmi_vector, trap_vector and handle_reset in start.S are 
> > > > > > not
> > > > > > used for RISC-V. Remove them.
> > > > > >
> > >
> > > Hi Lukas
> > >
> > > Agree with the above part.
> > >
> > > > > > While we are here, also remove the code from the beginning of 
> > > > > > start.S,
> > > > > > which stores the contents of a2 to memory. Only registers a0 and a1
> > > > > > contain information from the previous boot stage. There is therefore
> > > > > > no reason for saving a2.
> > >
> > > NOT agree with this part.
> > > Saving a2 is trying to support dynamically dtb pass at runtime.
> > >
> >
> > Could you please describe in more details on what the use case is here?
> >
>
> Hi Bin and Lukas
>
> After I study [PATCH 24/30] riscv: save hart ID and device tree passed
> by prior boot stage.
> I found it is the same thing.
> I will accepted this patch.
> So this patch is
>
> Reviewed-by: Rick Chen 
>
> But I shall send a patch to fix ax25-ae350 to work as well later.
> And it will be as below :
>
> ax5-ae350.c
> void *board_fdt_blob_setup(void)
> {
> void **ptr = (void *)_stage_fdt_address;
> if (fdt_magic(*ptr) == FDT_MAGIC)
> return (void *)*ptr;
>
> return (void *)CONFIG_SYS_FDT_BASE;
> }
>

Sorry!

I shall send a fixed patch as below:
riscv: ax25-ae350: use device tree passed by prior boot stage

--- a/configs/ax25-ae350_defconfig
+++ b/configs/ax25-ae350_defconfig
@@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_BOOTP_PREFER_SERVERIP=y
 CONFIG_CMD_CACHE=y
-CONFIG_OF_BOARD=y
+CONFIG_OF_PRIOR_STAGE=y

+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -64,15 +64,6 @@ ulong board_flash_get_legacy(ulong base, int
banknum, flash_info_t *info)
return 0;
 }

-void *board_fdt_blob_setup(void)
-{
-   void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
-   if (fdt_magic(*ptr) == FDT_MAGIC)
-   return (void *)*ptr;
-
-   return (void *)CONFIG_SYS_FDT_BASE;
-}
-

Rick

>
> > > You can see it in the following commit :
> > >
> > > commit d58717e42559189a226ea800173147399c8edef9
> > > Author: Rick Chen 
> > > Date:   Thu Mar 29 10:08:33 2018 +0800
> > >
> > > riscv: ae250: Support DT provided by the board at runtime
> > >
> >
> > Regards,
> > Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S

[Rick Chen]

Bin Meng  於 2018年10月24日 週三 上午11:34寫道：
>
> Hi Rich,
>
> On Wed, Oct 24, 2018 at 10:37 AM Rick Chen  wrote:
> >
> > > > > The labels nmi_vector, trap_vector and handle_reset in start.S are not
> > > > > used for RISC-V. Remove them.
> > > > >
> >
> > Hi Lukas
> >
> > Agree with the above part.
> >
> > > > > While we are here, also remove the code from the beginning of start.S,
> > > > > which stores the contents of a2 to memory. Only registers a0 and a1
> > > > > contain information from the previous boot stage. There is therefore
> > > > > no reason for saving a2.
> >
> > NOT agree with this part.
> > Saving a2 is trying to support dynamically dtb pass at runtime.
> >
>
> Could you please describe in more details on what the use case is here?
>

Hi Bin and Lukas

After I study [PATCH 24/30] riscv: save hart ID and device tree passed
by prior boot stage.
I found it is the same thing.
I will accepted this patch.
So this patch is

Reviewed-by: Rick Chen 

But I shall send a patch to fix ax25-ae350 to work as well later.
And it will be as below :

ax5-ae350.c
void *board_fdt_blob_setup(void)
{
void **ptr = (void *)_stage_fdt_address;
if (fdt_magic(*ptr) == FDT_MAGIC)
return (void *)*ptr;

return (void *)CONFIG_SYS_FDT_BASE;
}


> > You can see it in the following commit :
> >
> > commit d58717e42559189a226ea800173147399c8edef9
> > Author: Rick Chen 
> > Date:   Thu Mar 29 10:08:33 2018 +0800
> >
> > riscv: ae250: Support DT provided by the board at runtime
> >
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] tools: imx8image: return SUCCESS when the required files not found

[Peng Fan]

When the required files to build a bootable imx8 image are not
found, return EXIT_SUCCESS to avoid build CI system.
And if the files are missing, give a error message during the build.

Signed-off-by: Peng Fan 
---
 tools/imx8image.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/imx8image.c b/tools/imx8image.c
index e6b0a146b6..35409646f5 100644
--- a/tools/imx8image.c
+++ b/tools/imx8image.c
@@ -279,9 +279,9 @@ static void check_file(struct stat *sbuf, char *filename)
int tmp_fd  = open(filename, O_RDONLY | O_BINARY);
 
if (tmp_fd < 0) {
-   fprintf(stderr, "%s: Can't open: %s\n",
+   fprintf(stderr, "*** %s: Can't open: %s ***\n",
filename, strerror(errno));
-   exit(EXIT_FAILURE);
+   exit(EXIT_SUCCESS);
}
 
if (fstat(tmp_fd, sbuf) < 0) {
@@ -311,9 +311,9 @@ static void copy_file_aligned(int ifd, const char 
*datafile, int offset,
 
dfd = open(datafile, O_RDONLY | O_BINARY);
if (dfd < 0) {
-   fprintf(stderr, "Can't open %s: %s\n",
+   fprintf(stderr, "*** Can't open %s: %s ***\n",
datafile, strerror(errno));
-   exit(EXIT_FAILURE);
+   exit(EXIT_SUCCESS);
}
 
if (fstat(dfd, ) < 0) {
@@ -365,9 +365,9 @@ static void copy_file (int ifd, const char *datafile, int 
pad, int offset)
 
dfd = open(datafile, O_RDONLY | O_BINARY);
if (dfd < 0) {
-   fprintf(stderr, "Can't open %s: %s\n",
+   fprintf(stderr, "*** Can't open %s: %s ***\n",
datafile, strerror(errno));
-   exit(EXIT_FAILURE);
+   exit(EXIT_SUCCESS);
}
 
if (fstat(dfd, ) < 0) {
@@ -648,8 +648,8 @@ static int get_container_image_start_pos(image_t 
*image_stack, uint32_t align)
if (img_sp->option == APPEND) {
fd = fopen(img_sp->filename, "r");
if (!fd) {
-   fprintf(stderr, "Fail open first container file 
%s\n", img_sp->filename);
-   exit(EXIT_FAILURE);
+   fprintf(stderr, "*** Fail open first container 
file %s ***\n", img_sp->filename);
+   exit(EXIT_SUCCESS);
}
 
ret = fread(, sizeof(header), 1, fd);
-- 
2.14.1

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

Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S

[Bin Meng]

Hi Rich,

On Wed, Oct 24, 2018 at 10:37 AM Rick Chen  wrote:
>
> > > > The labels nmi_vector, trap_vector and handle_reset in start.S are not
> > > > used for RISC-V. Remove them.
> > > >
>
> Hi Lukas
>
> Agree with the above part.
>
> > > > While we are here, also remove the code from the beginning of start.S,
> > > > which stores the contents of a2 to memory. Only registers a0 and a1
> > > > contain information from the previous boot stage. There is therefore
> > > > no reason for saving a2.
>
> NOT agree with this part.
> Saving a2 is trying to support dynamically dtb pass at runtime.
>

Could you please describe in more details on what the use case is here?

> You can see it in the following commit :
>
> commit d58717e42559189a226ea800173147399c8edef9
> Author: Rick Chen 
> Date:   Thu Mar 29 10:08:33 2018 +0800
>
> riscv: ae250: Support DT provided by the board at runtime
>

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

Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S

[Rick Chen]

> > > The labels nmi_vector, trap_vector and handle_reset in start.S are not
> > > used for RISC-V. Remove them.
> > >

Hi Lukas

Agree with the above part.

> > > While we are here, also remove the code from the beginning of start.S,
> > > which stores the contents of a2 to memory. Only registers a0 and a1
> > > contain information from the previous boot stage. There is therefore
> > > no reason for saving a2.

NOT agree with this part.
Saving a2 is trying to support dynamically dtb pass at runtime.

You can see it in the following commit :

commit d58717e42559189a226ea800173147399c8edef9
Author: Rick Chen 
Date:   Thu Mar 29 10:08:33 2018 +0800

riscv: ae250: Support DT provided by the board at runtime

B.R
Rick

> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > >  arch/riscv/cpu/start.S | 11 ---
> > >  1 file changed, 11 deletions(-)
> > >
> >
> > Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Regression: vf610twr build error

[Alison Wang]

Hi, Stefano,

I don't have vf610 boards now. I am afraid I could not verify it too.


Best Regards,
Alison Wang

>-Original Message-
>From: Stefano Babic 
>Sent: 2018年10月23日 0:05
>To: Alison Wang 
>Cc: U-Boot@lists.denx.de
>Subject: Regression: vf610twr build error
>
>Hi Alison,
>
>I get a build error when I try to build the vf610 boards. This is not due to 
>recent
>patches for the board, but it is implicitly done on the current tree after 
>other
>branches were merged, because the resulting binary becomes bigger.
>
>In fact, it exceeds the maximum size:
>
>arm:  +   vf610twr_nand
>+u-boot-nodtb.bin exceeds file size limit:
>+  limit:  520192 bytes
>+  actual: 521316 bytes
>+  excess: 1124 bytes
>+make[1]: *** [u-boot-nodtb.bin] Error 1
>+make: *** [sub-make] Error 2
>   arm:  +   vf610twr
>+u-boot-nodtb.bin exceeds file size limit:
>+  limit:  520192 bytes
>+  actual: 521492 bytes
>+  excess: 1300 bytes
>+make[1]: *** [u-boot-nodtb.bin] Error 1
>+make: *** [sub-make] Error 2
>
>Anyway, colibry_vf has already set CONFIG_SYS_THUMB_BUILD to optimize the
>footprint. I can confirm that setting this to vf610twr fixes the build - 
>anyway, I
>have no way to test.
>
>Can you take a look ? If it is ok, CONFIG_SYS_THUMB_BUILD should be added to
>both vf610twr_defconfig and vf610twr_nand_defconfig.
>
>Best regards,
>Stefano
>
>--
>=
>
>DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>=
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] please pull u-boot-samsung master

[Minkyu Kang]

Hi Tom,

The following changes since commit 3ae192c2a4d52a755031e93fa6cc3a31ba90f29f:

  binman: Add a test for Intel reference code (2018-10-22 13:57:12 -0400)

are available in the git repository at:

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

for you to fetch changes up to 9cd97c5b049a9a282dda0b1782cbb38d8cedb417:

  ARM: Samsung: Add Exynos5422-based Odroid HC2 support (2018-10-23 20:00:52 
+0900)


Dirk Meul (1):
  ARM: Samsung: Add Exynos5422-based Odroid HC2 support

 board/samsung/common/exynos5-dt-types.c | 16 +---
 board/samsung/common/exynos5-dt.c   |  4 ++--
 configs/odroid-xu3_defconfig|  2 +-
 include/samsung/exynos5-dt-types.h  |  2 ++
 4 files changed, 18 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v2] ARM: Samsung: Add Exynos5422-based Odroid HC2 support

[Minkyu Kang]

On 23/10/18 16:23, Dirk Meul wrote:
> From: Dirk Meul 
> Date: Sun, 14 Oct 2018 17:14:17 +0200
> 
> Odroid HC2 board is based on Odroid XU4 board, like the Odroid HC1.
> 
> The linux kernel does not provide a hc2 DTB so the hc1 DTB is also used
> for the Odroid HC2.
> 
> Resend because MUA changed whitespace.
> 
> Signed-off-by: Dirk Meul 
> Acked-by: Marek Szyprowski 
> Reviewed-by: Lukasz Majewski 
> ---
>  board/samsung/common/exynos5-dt-types.c | 16 +---
>  board/samsung/common/exynos5-dt.c   |  4 ++--
>  configs/odroid-xu3_defconfig|  2 +-
>  include/samsung/exynos5-dt-types.h  |  2 ++
>  4 files changed, 18 insertions(+), 6 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 1/1] x86: detect unsupported relocation types

[Heinrich Schuchardt]

On 10/23/2018 11:13 AM, Hannes Schmelzer wrote:
> 
> On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
>> Currently we support only relocations of type ELF64_R_TYPE or
>> ELF32_R_TYPE.
>> We should be warned if other relocation types appear in the relocation
>> sections.
>>
>> This type of message has helped to identify code overwriting a relocation
>> section before relocation and incorrect parsing of relocation tables.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>   arch/x86/lib/relocate.c | 18 ++
>>   1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
>> index ed10755d9c..01e619d20b 100644
>> --- a/arch/x86/lib/relocate.c
>> +++ b/arch/x86/lib/relocate.c
>> @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int
>> text_base, uintptr_t size,
>>   Elf64_Addr *offset_ptr_ram;
>>     do {
>> +    unsigned long long type = ELF64_R_TYPE(re_src->r_info);
>> +
>> +    if (type != R_X86_64_RELATIVE) {
>> +    printf("%s: unsupported relocation type 0x%llx "
>> +   "at %p, ",__func__, type, re_src);
>> +    printf("offset = 0x%llx\n", re_src->r_offset);
>> +    continue;
>> +    }
>> +
>>   /* Get the location from the relocation entry */
>>   offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
>>   @@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int
>> text_base, uintptr_t size,
>>   Elf32_Addr *offset_ptr_ram;
>>     do {
>> +    unsigned int type = ELF32_R_TYPE(re_src->r_info);
>> +
>> +    if (type != R_386_RELATIVE) {
>> +    printf("%s: unsupported relocation type 0x%x "
>> +   "at %p, ",__func__, type, re_src);
>> +    printf("offset = 0x%x\n", re_src->r_offset);
>> +    continue;
>> +    }
>> +
>>   /* Get the location from the relocation entry */
>>   offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
>>   
> Hi Heinrich,
> i just merged recent u-boot master into my devbranch and ran it on my
> board:
> 
> -- 
> U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
> 
> CPU: x86, vendor AMD, device 5a2h
> DRAM:  119.6 MiB
> do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0,
> offset = 0x287
> do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8,
> offset = 0x291
> Bus 0: OK
> ---
> 
> now i get such relocation warnings, can you help me in this how to deal
> with that?
> 
> I'm starting u-boot as a payload from coreboot.
> 
> thanks!
> 
> cheers,
> Hannes
> 
> 

Hello Hannes,

thanks for reporting the problem.

There are two possible reasons:

a) The build process introduces relocations of the reported type.
b) The relocation records are overwritten before relocation. This
happens if you update uninitialized globals.

To analyze your problem further, please, provide instructions for
building your version of U-Boot (repository, commit, config). That will
allow to check for a).

Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would
allow to analyze case b). Are you able to reproduce the problem with QEMU?

Best regards

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

Re: [U-Boot] [PATCH] w1: fix build without CONFIG_W1_EEPROM

[Lukasz Majewski]

Hi Martin, Eugen,

> On 23/10/18 10:40, eugen.hris...@microchip.com wrote:
> >
> > I tried as much as possible to decouple the W1 bus from the W1
> > EEPROM memories. It is possible that we will have a different
> > framework for EEPROMs that will include both 1wire and i2c eeproms,
> > and then the interfacing would be pretty easy to change to.
> >
> > That's why I am thinking that w1 bus read should not be much
> > affected if the 1w EEPROMs are unknown to U-boot
> >  
> Yes sure that's great.
> 
> Somewhat diverting this thread
> 
> I noticed that currently "w1 read" displays the data in hex with
> "%x", which means it prints just one character if in range 00-0f.
> And as there is no seperator the output isn't currently useful.
> 
> That's a trivial fix of course but it got me thinking about what do
> we want to "w1 read" to do?
> 
> A lot of other storage reading commands use "read" to mean "read to 
> memory" and take a destination RAM address parameter.
> Eg mmc read, sf read, ...
> 
> There are counter examples though like "mii read" or "pmic read"
> which just print the output but they don't read aribitary
> user defined data like an eeprom.
> 
> So I was wondering if it would be better to modify "w1 read" to mean 
> "read to memory" and add a new "w1 dump" command
> to do what "w1 read" currently does (as it is much more convenient
> for quickly checking the eeprom contents than
> having to use md).
> 
> The type of use case I'm thinking of for "read to memory" is if
> someone wants to put a device tree blob on an eeprom.
> 

If I may add my 2cents.

I also would like to see the w1 command to load read data to memory (to
be consistent with e.g. load), so we could use md.b, mw.b, etc.

> What do you think?
> 
> Regards,
> 
> Martin
> 
> 
> 
> >> Regards,
> >>
> >> Martin
> >>
> >>  
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot




Best regards,

Lukasz Majewski

--

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


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

Re: [U-Boot] [PATCH 4/5] sunxi: display: Mark sunxi_rgb2yuv_coef array as const

[Anatolij Gustschin]

On Tue, 23 Oct 2018 20:20:31 +0300
Priit Laes pl...@plaes.org wrote:

>sunxi_rgb2yuv_coef is readonly and never modified.
>
>Signed-off-by: Priit Laes 

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

[U-Boot] [PATCH 3/5] sunxi: docs: Mention CONFIG_NAND requirement

[Priit Laes]

Signed-off-by: Priit Laes 
---
 board/sunxi/README.nand | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/sunxi/README.nand b/board/sunxi/README.nand
index 77a8c7d..dac603c 100644
--- a/board/sunxi/README.nand
+++ b/board/sunxi/README.nand
@@ -20,9 +20,9 @@ pages.
 In order to accomodate that, we create a tool that will generate an
 SPL image that is ready to be programmed directly embedding the ECCs,
 randomized, and with the necessary bits needed to reduce the number of
-bitflips. The U-Boot build system, when configured for the NAND will
-also generate the image sunxi-spl-with-ecc.bin that will have been
-generated by that tool.
+bitflips. The U-Boot build system, when configured for the NAND (with
+CONFIG_NAND=y) will also generate the image sunxi-spl-with-ecc.bin
+that will have been generated by that tool.
 
 In order to flash your U-Boot image onto a board, assuming that the
 board is in FEL mode, you'll need the sunxi-tools that you can find at
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/5] sunxi: doc: Add basic fastboot example

[Priit Laes]

From: Priit Laes 

Signed-off-by: Priit Laes 
---
 board/sunxi/README.fastboot | 98 ++-
 1 file changed, 98 insertions(+)
 create mode 100644 board/sunxi/README.fastboot

diff --git a/board/sunxi/README.fastboot b/board/sunxi/README.fastboot
new file mode 100644
index 000..470fa6f
--- /dev/null
+++ b/board/sunxi/README.fastboot
@@ -0,0 +1,98 @@
+Using fastboot on sunxi devices
+===
+
+Fastboot is a diagnostic protocol, primarily used to modify the
+filesystems on the flash device via USB or UDP. It requires that
+the device is started in a boot loader or Seconday Boot Loader mode.
+
+This document currently walks through an installation with a device
+with eMMC storage.
+
+Prerequisites
+-
+
+* fastboot binaries installed on client machine
+* sunxi-tools installed on client machine (optional)
+* u-boot tools (mkimage)
+* u-boot binaries for the target sunxi device
+* filesystem images
+  * root file system containing operating system
+  * vfat file system 
+* Sunxi device connected to client via OTG port
+
+Getting your device into Fastboot mode
+--
+
+To enter into fastboot mode, execute the `fastboot` command in
+U-Boot:
+
+$ fastboot usb 0
+
+On the client machine, you can check whether the device is visible
+using the `fastboot devices` command. And for fun, you can also
+fetch the bootloader version using the fastboot protocol:
+
+$ fastboot devices 
+1234567890abcdef   fastboot
+$ fastboot getvar bootloader-version
+bootloader-version: U-Boot 2018.11-rc2-00033-ge3beca3a2f
+finished. total time: 0.000s
+
+Preparing the device for flashing
+-
+
+Now that the device is in the fastboot mode, we can continue with
+creating the partitions on the device. By default, u-boot for sunxi
+defines following partitions:
+
+* loader1 - partition for secondary program loader
+* loader2 - partition for u-boot
+* esp - EFI system partition, also used for u-boot to look up boot.scr
+* system  - Root partition for system
+
+These partitions have also assigned GUID's according to Discoverable
+Partitions Specification [1], to enable automatic discovery of partitions
+and their mountpoints.
+
+You can start by formatting the internal storage by executing the
+`fastboot oem format` command from client:
+
+$ fastboot oem format
+
+This equivalent to running the `gpt write mmc 1 $partitions` from u-boot.
+
+[1] https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
+
+Flashing the device
+---
+
+Now that we have the partitions created, all that is left for us
+is to flash the data.
+
+`loader1` is used for storing the Seconday Program Loader, in our
+case, it is the `spl/sunxi-spl.bin` in the u-boot directory:
+
+$ fastboot flash loader1 spl/sunxi-spl.bin
+
+`loader2` is for storing the u-boot binary. `u-boot.img` in the
+u-boot source directory:
+
+$ fastboot flash loader2 u-boot.img
+
+`esp` partition (EFI System Partition) can be kept empty, although
+if it is VFAT partition, u-boot automatically looks up the `boot.scr`
+file for device-specific configuration. (You can create empty vfat
+partition by `fallocate -l 32M esp.img && mkfs.vfat esp.img`)
+
+$ fastboot flash esp esp.img
+
+`system` partition is where the operating system resides. Creating
+that is left as an exercise to the reader.
+
+$ fastboot flash system system.img
+
+Now, if everything has been properly set up (aka proper kernel
+with machine-specific dtb installed on system.img, and boot.scr
+on esp partition), you can reboot the machine:
+
+$ fastboot reboot
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/5] sunxi: display: Mark sunxi_rgb2yuv_coef array as const

[Priit Laes]

sunxi_rgb2yuv_coef is readonly and never modified.

Signed-off-by: Priit Laes 
---
 drivers/video/sunxi/sunxi_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/sunxi/sunxi_display.c 
b/drivers/video/sunxi/sunxi_display.c
index 5c8f88c..6dd9bec 100644
--- a/drivers/video/sunxi/sunxi_display.c
+++ b/drivers/video/sunxi/sunxi_display.c
@@ -460,7 +460,7 @@ static void sunxi_composer_init(void)
setbits_le32(_be->mode, SUNXI_DE_BE_MODE_ENABLE);
 }
 
-static u32 sunxi_rgb2yuv_coef[12] = {
+static const u32 sunxi_rgb2yuv_coef[12] = {
0x0107, 0x0204, 0x0064, 0x0108,
0x3f69, 0x3ed6, 0x01c1, 0x0808,
0x01c1, 0x3e88, 0x3fb8, 0x0808
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/5] sunxi: Fix typos of spelling Allwinner

[Priit Laes]

Signed-off-by: Priit Laes 
---
 arch/arm/mach-sunxi/dram_sun4i.c | 2 +-
 arch/arm/mach-sunxi/p2wi.c   | 2 +-
 board/sunxi/README.sunxi64   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun4i.c b/arch/arm/mach-sunxi/dram_sun4i.c
index 8562302..396c042 100644
--- a/arch/arm/mach-sunxi/dram_sun4i.c
+++ b/arch/arm/mach-sunxi/dram_sun4i.c
@@ -5,7 +5,7 @@
  * (C) Copyright 2013 Luke Kenneth Casson Leighton 
  *
  * Based on sun4i Linux kernel sources mach-sunxi/pm/standby/dram*.c
- * and earlier U-Boot Allwiner A10 SPL work
+ * and earlier U-Boot Allwinner A10 SPL work
  *
  * (C) Copyright 2007-2012
  * Allwinner Technology Co., Ltd. 
diff --git a/arch/arm/mach-sunxi/p2wi.c b/arch/arm/mach-sunxi/p2wi.c
index 82ad254..e84e1d8 100644
--- a/arch/arm/mach-sunxi/p2wi.c
+++ b/arch/arm/mach-sunxi/p2wi.c
@@ -5,7 +5,7 @@
  * (C) Copyright 2013 Oliver Schinagl 
  * http://linux-sunxi.org
  *
- * Based on sun6i sources and earlier U-Boot Allwiner A10 SPL work
+ * Based on sun6i sources and earlier U-Boot Allwinner A10 SPL work
  *
  * (C) Copyright 2006-2013
  * Allwinner Technology Co., Ltd. 
diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
index df1dbc8..bba2e01 100644
--- a/board/sunxi/README.sunxi64
+++ b/board/sunxi/README.sunxi64
@@ -130,7 +130,7 @@ U-Boot prompt on the serial console.
 
 (Legacy) boot0 method
 -
-boot0 is Allwiner's secondary program loader and it can be used as some kind
+boot0 is Allwinner's secondary program loader and it can be used as some kind
 of SPL replacement to get U-Boot up and running from an microSD card.
 For some time using boot0 was the only option to get the Pine64 booted.
 With working DRAM init code in U-Boot's SPL this is no longer necessary,
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/5] sunxi: docs: Unify the formatting style and add some paragraph breaks

[Priit Laes]

Signed-off-by: Priit Laes 
---
 board/sunxi/README.nand| 18 +-
 board/sunxi/README.sunxi64 | 23 ---
 2 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/board/sunxi/README.nand b/board/sunxi/README.nand
index a5d4ff0..77a8c7d 100644
--- a/board/sunxi/README.nand
+++ b/board/sunxi/README.nand
@@ -29,26 +29,26 @@ board is in FEL mode, you'll need the sunxi-tools that you 
can find at
 this repository: https://github.com/linux-sunxi/sunxi-tools
 
 Then, you'll need to first load an SPL to initialise the RAM:
-sunxi-fel spl spl/sunxi-spl.bin
+$ sunxi-fel spl spl/sunxi-spl.bin
 
 Load the binaries we'll flash into RAM:
-sunxi-fel write 0x4a00 u-boot-dtb.bin
-sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
+$ sunxi-fel write 0x4a00 u-boot-dtb.bin
+$ sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
 
 And execute U-Boot
-sunxi-fel exe 0x4a00
+$ sunxi-fel exe 0x4a00
 
 On your board, you'll now have all the needed binaries into RAM, so
 you only need to erase the NAND...
 
-nand erase.chip
+$ nand erase.chip
 
 Then write the SPL and its backup:
 
-nand write.raw.noverify 0x4300 0 40
-nand write.raw.noverify 0x4300 0x40 40
+$ nand write.raw.noverify 0x4300 0 40
+$ nand write.raw.noverify 0x4300 0x40 40
 
 And finally write the U-Boot binary:
-nand write 0x4a00 0x80 0xc
+$ nand write 0x4a00 0x80 0xc
 
-You can now reboot and enjoy your NAND.
\ No newline at end of file
+You can now reboot and enjoy your NAND.
diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
index bba2e01..63cd8bb 100644
--- a/board/sunxi/README.sunxi64
+++ b/board/sunxi/README.sunxi64
@@ -32,9 +32,10 @@ to build it first.
 Checkout the "allwinner" branch from the github repository [1] and build it:
 $ export CROSS_COMPILE=aarch64-linux-gnu-
 $ make PLAT=sun50iw1p1 DEBUG=1 bl31
+
 The resulting binary is build/sun50iw1p1/debug/bl31.bin. Either put the
 location of this file into the BL31 environment variable or copy this to
-the root of your U-Boot build directory (or create a symbolic link).
+the root of your U-Boot build directory (or create a symbolic link):
 $ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin
   (adjust the actual path accordingly)
 
@@ -48,7 +49,8 @@ binaries in the firmware repository[3], purely for 
convenience reasons.
 
 Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
 enters the SPL still in AArch32 secure SVC mode, there is some shim code to
-enter AArch64 very early. The rest of the SPL runs in AArch64 EL3.
+enter AArch64 very early. The rest of the SPL runs in AArch64 EL3 mode.
+
 U-Boot proper runs in EL2 and can load any AArch64 code (using the "go"
 command), EFI applications (with "bootefi") or arm64 Linux kernel images
 (often named "Image"), using the "booti" command.
@@ -95,15 +97,15 @@ feature is disabled in the configuration at the moment.
 microSD card
 
 Transfer the SPL and the U-Boot FIT image directly to an uSD card:
-# dd if=spl/sunxi-spl.bin of=/dev/sdx bs=8k seek=1
-# dd if=u-boot.itb of=/dev/sdx bs=8k seek=5
-# sync
+$ dd if=spl/sunxi-spl.bin of=/dev/sdx bs=8k seek=1
+$ dd if=u-boot.itb of=/dev/sdx bs=8k seek=5
+$ sync
 (replace /dev/sdx with you SD card device file name, which could be
 /dev/mmcblk[x] as well).
 
 Alternatively you can use the SPL and the U-Boot FIT image combined into a
 single file and transfer that instead:
-# dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
+$ dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
 
 You can partition the microSD card, but leave the first MB unallocated (most
 partitioning tools will do this anyway).
@@ -118,13 +120,17 @@ Now connect either an "A to A" USB cable to the upper USB 
port on the Pine64
 or get an adaptor and use a regular A-microB cable connected to it. Other
 boards often have a proper micro-B USB socket connected to the USB OTB port.
 Remove a microSD card from the slot and power on the board.
+
 On your host computer download and build the sunxi-tools package[2], then
 use "sunxi-fel" to access the board:
 $ ./sunxi-fel ver -v -p
+
 This should give you an output starting with: AWUSBFEX soc=1689(A64) ...
+
 Now use the sunxi-fel tool to write to the NOR flash:
 $ ./sunxi-fel spiflash-write 0 spl/sunxi-spl.bin
 $ ./sunxi-fel spiflash-write 32768 u-boot.itb
+
 Now boot the board without an SD card inserted and you should see the
 U-Boot prompt on the serial console.
 
@@ -142,10 +148,11 @@ by this method.
 The boot0 binary is a 32 KByte blob and contained in the official Pine64 images
 distributed by Pine64 or Allwinner. It can be easily extracted from a micro
 SD card or an image file:
-# dd if=/dev/sd of=boot0.bin bs=8k skip=1 count=4
+$ dd if=/dev/sd of=boot0.bin bs=8k skip=1 count=4
 where /dev/sd is the device name of the uSD card or the name of the image
 file. Apparently Allwinner allows 

[U-Boot] [PATCH 0/5] sunxi: doc: Add fastboot example + misc cleanups

[Priit Laes]

While writing a sample fastboot usage tutorial for sunxi, I also
found bunch of discrepancies in the existing docs.

Series also includes one simple constification patch that has been
sitting in my tree for ages.

Priit Laes (5):
  sunxi: Fix typos of spelling Allwinner
  sunxi: docs: Unify the formatting style and add some paragraph breaks
  sunxi: docs: Mention CONFIG_NAND requirement
  sunxi: display: Mark sunxi_rgb2yuv_coef array as const
  sunxi: doc: Add basic fastboot example

 arch/arm/mach-sunxi/dram_sun4i.c|  2 +-
 arch/arm/mach-sunxi/p2wi.c  |  2 +-
 board/sunxi/README.fastboot | 98 ++-
 board/sunxi/README.nand | 24 +++
 board/sunxi/README.sunxi64  | 25 +---
 drivers/video/sunxi/sunxi_display.c |  2 +-
 6 files changed, 130 insertions(+), 23 deletions(-)
 create mode 100644 board/sunxi/README.fastboot

base-commit: 3ae192c2a4d52a755031e93fa6cc3a31ba90f29f
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[Stefan Roese]

Hi Rajat,

On 23.10.18 07:17, Rajat Srivastava wrote:

-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Monday, October 22, 2018 12:45 PM
To: Rajat Srivastava ; ja...@openedev.com;
simon.k.r.goldschm...@gmail.com
Cc: Ashish Kumar ; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs
standard 3-byte mode)

Hi Rajat,

On 17.10.18 13:52, Rajat Srivastava wrote:

Hi Stefan

Sorry for top-posting.

Why can't we read SFDP parameters from flash and auto-detect
3-byte/4-byte addressing mode?
Using address width information we can support both types of flash
i.e. flashes supporting 3-byte addressing mode as well as flashes
supporting 4-byte addressing mode.


Our flash supports 3- and 4-byte addressing mode. But this special
chip is factory strapped to only support 4-byte mode, even though
its device ID tells us that it should support also 3-byte mode.
This current pretty simple patch enables the use of this flash
with very limited code additions. It also helps others (Simon on
SoCFPGA) with their issues regarding 3-byte vs 4-byte mode -
especially in regard to the bootrom and its setup.


If you look into my patch, for the flashes that support both
3-byte and 4-byte addressing modes, the default addressing mode is set to
4-byte. In such case if the user wants to send a command in 3-byte mode
then he has to set a flag. So SFDP path will be able to handle the special
chip that is factory strapped to 4-byte addressing mode.

Code snippet from patch which handles 3-byte/4-byte/both addressing modes:
+ switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
+case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY: // flashes with 3-byte 
addressing
+flash->addr_width = 3;
+break;
+case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: // flashes with both 3 or 4 byte
+printf("SF: Flash defaults to 3-Byte mode; enters 4-Byte ");
+printf("mode on command\n");
+/*
+ * By default, 4-byte addressing mode is set.
+ * To enforce 3-byte addressing mode, set addrwd_3_in_use flag
+ * in struct spi_flash for every command.
+ */
+flash->addr_width = 4;
+break;
+ case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY: // flashes with 4-byte 
addressing
+flash->addr_width = 4;
+break;




I've floated a similar patch in U-boot that reads and parses SFDP
parameters from flash and auto-detects its addressing mode. It send
commands according to the address width it detects.
Please find the patch set at:


https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
work.ozlabs.org%2Fcover%2F985326%2Fdata=02%7C01%7Crajat.srivast
ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=M2aU
WUxSn9wmlBlYj336%2Bay5rwOddG%2Br7Qn5kH%2Bf1uw%3Dreserved=
0



https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
work.ozlabs.org%2Fpatch%2F985327%2Fdata=02%7C01%7Crajat.srivast
ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=IIzUJuI
9nL5Wn7K5uAqjig9edpW6YIIcSOExNJNB5qE%3Dreserved=0



https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
work.ozlabs.org%2Fpatch%2F985329%2Fdata=02%7C01%7Crajat.srivast
ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=N5qQJ
E1776Wb3siJApPDCkUyY4vn0ZVLjCebn4hi6bk%3Dreserved=0



https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
work.ozlabs.org%2Fpatch%2F985328%2Fdata=02%7C01%7Crajat.srivast
ava%40nxp.com%7C56b81d26a6954324bebd08d637ee0c35%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C636757892882342025sdata=tC%2F
%2FsGVwV%2FrHBPX1gJ5TNYmVnJOL13XpAjgP87w3%2Bx0%3Dreserved
=0

I've just applied your 3 patches and have added SFDP support for
our equipped SPI chip (with my patch not applied):

-   {"mx25l25635f",INFO(0xc22019, 0x0, 64 * 1024,   512, RD_FULL |
WR_QPP) },
+   {"mx25l25635f",INFO(0xc22019, 0x0, 64 * 1024,   512, RD_FULL |
WR_QPP | SPI_FLASH_USE_SFDP) },

This does not seem to work though:


Simply adding SPI_FLASH_USE_SFDP flag is not enough to make SFDP work. You'll
need to add the driver code corresponding to the mtd layer code (in spi_flash.c)
which will send the actual READ SFDP command to flash.

The patch-set I floated adds driver code in fsl_qspi.c (Freescale/NXP QSPI 
driver).
Please find the patch at https://patchwork.ozlabs.org/patch/985329.

After the mtd layer calls spi_flash_read_common() function to send any read
command to flash, it lands on driver which ultimately fires the command
(in this case 0x5A command to read SFDP) to flash.


So you say, that each SPI driver needs to get some changes to
support the SFDP reading? That does not sound like 

Re: [U-Boot] MT76XX-driver

[Stefan Roese]

Hi Weijie,

On 23.10.18 17:43, Weijie Gao wrote:

mt7622 is an ARMv8 soc and its ethernet is different from mt7622 anyway.
It's better to name it mt7628-eth or rt5350-eth because mt7628/mt7688
actually reuse the ethernet from rt5350.


Okay, I'll send another version shortly - probably using 7628, as
I don't want to introduce rt5350 now.
 

In fact arch/mips/mach-mt7620 should be named mach-mt7628 as mt7628
and mt7628 have so many differences in low level codes and drivers.


Yes, thanks. I'll probably follow-up with renaming the base MIPS
port to mt7628 soon.

This MediaTek SoC naming is very inconsistent and "foggy". At least
for me.
 

BTW, the offical mt7622 u-boot support will be submitted later by MTK.
mt7621 may also be submitted.


That's good to hear. Do you know if there is any interest from MTK
to work on the new mainline MT7628 / 7688 MIPS in mainline? I would
very much welcome this.

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

Re: [U-Boot] MT76XX-driver

[Weijie Gao]

Hi Stefan,

mt7622 is an ARMv8 soc and its ethernet is different from mt7622 anyway.
It's better to name it mt7628-eth or rt5350-eth because mt7628/mt7688
actually reuse the ethernet from rt5350.

In fact arch/mips/mach-mt7620 should be named mach-mt7628 as mt7628
and mt7628 have so many differences in low level codes and drivers.

BTW, the offical mt7622 u-boot support will be submitted later by MTK.
mt7621 may also be submitted.

Best Regards,

Weijie
Stefan Roese  于2018年10月23日周二 下午11:02写道：
>
> Hi Frank,
>
> On 23.10.18 16:38, Frank Wunderlich wrote:
> > can you please rename the driver (and the commit-message) to
> > mt7622 because this is a MIPS-driver and not compatible with
> > e.g. mt7623 (arm).
> >
> > https://patchwork.ozlabs.org/patch/988140/
>
> Okay, will do.
>
> Thanks,
> Stefan
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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

Re: [U-Boot] [PATCH] warp7: MAINTAINERS: Add an entry for warp7_bl33_defconfig

[Stefano Babic]

On 23/10/18 17:38, Fabio Estevam wrote:
> Add an entry for the warp7_bl33_defconfig target.
> 
> This fixes the following warnings:
> 
> WARNING: no status info for 'warp7_bl33'
> WARNING: no maintainers for 'warp7_bl33'
> 
> Reported-by: Tom Rini 
> Signed-off-by: Fabio Estevam 
> ---
>  board/warp7/MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
> index 1d3ee29..55f8c81 100644
> --- a/board/warp7/MAINTAINERS
> +++ b/board/warp7/MAINTAINERS
> @@ -4,3 +4,4 @@ S:Maintained
>  F:   board/warp7/
>  F:   include/configs/warp7.h
>  F:   configs/warp7_defconfig
> +F:   configs/warp7_bl33_defconfig
> 

Thanks, Fabio ! I'll merge it into u-boot-imx.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] warp7: MAINTAINERS: Add an entry for warp7_bl33_defconfig

[Fabio Estevam]

Add an entry for the warp7_bl33_defconfig target.

This fixes the following warnings:

WARNING: no status info for 'warp7_bl33'
WARNING: no maintainers for 'warp7_bl33'

Reported-by: Tom Rini 
Signed-off-by: Fabio Estevam 
---
 board/warp7/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/warp7/MAINTAINERS b/board/warp7/MAINTAINERS
index 1d3ee29..55f8c81 100644
--- a/board/warp7/MAINTAINERS
+++ b/board/warp7/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/warp7/
 F: include/configs/warp7.h
 F: configs/warp7_defconfig
+F: configs/warp7_bl33_defconfig
-- 
2.7.4

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

[U-Boot] [PATCH v4] net: Add MT7622 ethernet driver

[Stefan Roese]

This patch adds ethernet support for the MIPS based Mediatek MT76xx SoCs
(e.g. MT7688), including a minimum setup of the integrated switch. This
driver is loosly based on the driver version included in this MediaTek
github repository:

https://github.com/MediaTek-Labs/linkit-smart-uboot.git

Tested on the MT7688 LinkIt smart-gateway and on the
Gardena-smart-gateway.

Signed-off-by: Stefan Roese 
Reviewed-by: Daniel Schwierzeck 
Cc: Joe Hershberger 
Cc: Frank Wunderlich 
---
v4:
- Rename driver to avoid mix-up with the MT76xx ARM SoCs

v3:
- Add Reviewed-by from Daniel
- Address review comments from Joe:
  - Use more macros / defines instead of magic values, especially
in the MDIO functions
  - Use FIELD_xxx from include/linux/bitfield.h whereever possible
  - Remove some unreferenced defines
  - Remove some unnecessary casts
  - Spelling fixes
  - Add documentation in doc/device-tree-bindings/net/

v2:
- Use wait_for_bit_le32() in more places
- Use syscon / regmap to access the system-controller registers
  needed in this driver instead of finding and mapping this
  area

 .../net/mediatek,mt7622-eth.txt   |  17 +
 drivers/net/Kconfig   |   7 +
 drivers/net/Makefile  |   1 +
 drivers/net/mt7622-eth.c  | 635 ++
 4 files changed, 660 insertions(+)
 create mode 100644 doc/device-tree-bindings/net/mediatek,mt7622-eth.txt
 create mode 100644 drivers/net/mt7622-eth.c

diff --git a/doc/device-tree-bindings/net/mediatek,mt7622-eth.txt 
b/doc/device-tree-bindings/net/mediatek,mt7622-eth.txt
new file mode 100644
index 00..db035c99d4
--- /dev/null
+++ b/doc/device-tree-bindings/net/mediatek,mt7622-eth.txt
@@ -0,0 +1,17 @@
+* MediaTek Frame Engine Ethernet controller
+
+Required properties:
+- compatible: should be "mediatek,mt7622-eth"
+- reg: address and length of the register set for the frame
+   engine ethernet controller and the internal switch.
+- syscon: phandle to the system controller
+
+Example:
+
+eth@1010 {
+   compatible = "mediatek,mt7622-eth";
+   reg = <0x1010 0x1
+  0x1011 0x8000>;
+
+   syscon = <>;
+};
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f1f0e2d94e..f52f6ee29a 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -227,6 +227,13 @@ config MACB_ZYNQ
  The Cadence MACB ethernet interface was used on Zynq platform.
  Say Y to enable support for the MACB/GEM in Zynq chip.
 
+config MT7622_ETH
+   bool "MediaTek MT7622 Ethernet Interface"
+   depends on ARCH_MT7620
+   help
+ The MediaTek MT7622 ethernet interface is used on MT7688
+ based boards.
+
 config PCH_GBE
bool "Intel Platform Controller Hub EG20T GMAC driver"
depends on DM_ETH && DM_PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 48a2878071..f6a0890a73 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_LPC32XX_ETH) += lpc32xx_eth.o
 obj-$(CONFIG_MACB) += macb.o
 obj-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
 obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
+obj-$(CONFIG_MT7622_ETH) += mt7622-eth.o
 obj-$(CONFIG_MVGBE) += mvgbe.o
 obj-$(CONFIG_MVNETA) += mvneta.o
 obj-$(CONFIG_MVPP2) += mvpp2.o
diff --git a/drivers/net/mt7622-eth.c b/drivers/net/mt7622-eth.c
new file mode 100644
index 00..e6fa803d97
--- /dev/null
+++ b/drivers/net/mt7622-eth.c
@@ -0,0 +1,635 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * MediaTek ethernet IP driver for U-Boot
+ *
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * This code is mostly based on the code extracted from this MediaTek
+ * github repository:
+ *
+ * https://github.com/MediaTek-Labs/linkit-smart-uboot.git
+ *
+ * I was not able to find a specific license or other developers
+ * copyrights here, so I can't add them here.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* System controller register */
+#define MT76XX_RSTCTRL_REG 0x34
+#define RSTCTRL_EPHY_RST   BIT(24)
+
+#define MT76XX_AGPIO_CFG_REG   0x3c
+#define MT7628_EPHY_GPIO_AIO_ENGENMASK(20, 17)
+#define MT7628_EPHY_P0_DIS BIT(16)
+
+#define MT76XX_GPIO2_MODE_REG  0x64
+
+/* Ethernet frame engine register */
+#define PDMA_RELATED   0x0800
+
+#define TX_BASE_PTR0   (PDMA_RELATED + 0x000)
+#define TX_MAX_CNT0(PDMA_RELATED + 0x004)
+#define TX_CTX_IDX0(PDMA_RELATED + 0x008)
+#define TX_DTX_IDX0(PDMA_RELATED + 0x00c)
+
+#define RX_BASE_PTR0   (PDMA_RELATED + 0x100)
+#define RX_MAX_CNT0(PDMA_RELATED + 0x104)
+#define RX_CALC_IDX0   (PDMA_RELATED + 0x108)
+
+#define PDMA_GLO_CFG   (PDMA_RELATED + 0x204)
+#define PDMA_RST_IDX   (PDMA_RELATED + 0x208)
+#define DLY_INT_CFG(PDMA_RELATED + 0x20c)
+
+#define SDM_RELATED0x0c00
+
+#define 

Re: [U-Boot] MT76XX-driver

[Stefan Roese]

Hi Frank,

On 23.10.18 16:38, Frank Wunderlich wrote:

can you please rename the driver (and the commit-message) to
mt7622 because this is a MIPS-driver and not compatible with
e.g. mt7623 (arm).
  
https://patchwork.ozlabs.org/patch/988140/


Okay, will do.

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

[U-Boot] MT76XX-driver

[Frank Wunderlich]

Hi,
 
can you please rename the driver (and the commit-message) to mt7622 because 
this is a MIPS-driver and not compatible with e.g. mt7623 (arm).
 
https://patchwork.ozlabs.org/patch/988140/
 
regards Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Tom Rini]

On Tue, Oct 23, 2018 at 04:42:53PM +0200, Stefano Babic wrote:
> Hi Tom,
> 
> On 23/10/18 16:29, Tom Rini wrote:
> > On Tue, Oct 23, 2018 at 09:52:58AM +0200, Stefano Babic wrote:
> > 
> >> Hi Tom,
> >>
> >> please pull from u-boot-imx (tag: u-boot-imx-20181023) thanks !
> >>
> >> The tree contains fixes for i.MX6 and improvement in docs, but the most
> >> important part is the introduction of the i.MX8 architecture (thanks to
> >> Peng and Antolji for their work !). Build on Travis reported no error,
> >> but I get a build issue with the VF610 boards - this will be require a
> >> fix in next days. i.MX8 can be built following exactly the instruction
> >> of the README file (NXP firmware requires to acknowledge the EULA).
> > 
> > I know the i.MX8 stuff has been kicking around for a while so.. OK, yes,
> > I won't be too upset about pushing it so late in the cycle.  But, my
> > travis builds do see an error:
> > https://travis-ci.org/trini/u-boot/jobs/445069389#L1038 which is "Fail
> > open first container file ahab-container.img" for imx8qxp_mek and I also
> > see that locally.
> 
> I know: to build i.MX8, we need to download external firmware. In fact,
> we have to provide the files according to board/freescale/mx8mq_evk/README.
> 
> Near "imx-atf" (this is not a problem, loaded and built), we need two
> additional "closed" firmware, that is firmware-imx (currently, 7.6) and
> imx-sc-firmware. They can be downloaded but they underly the acknowledge
> of NXP's EULA. They are self extracting scripts and we could hack it to
> have an automatic build, but I *guess* this breaks the license. I do not
> know if we are allowed to do this, and both of these firmwares do not
> provide a way to "implicitely" skip the EULA as we do in OE by setting a
> variable in local.conf.
> 
> >  This feels like the same class of error that we have
> > to deal with on other AArch64 platforms, namely of throwing a user
> > visible error that what they just built will not boot due to lack of
> > other files.
> 
> I am unsure: mkimage packs all files together as part of the build, when
> they are available. User cannot even try to boot, because the build
> stops if these files are not available. The error at mkimage step is
> saying us that build is not complete due to missing files (atf,
> firmware-imx and imx-sc-firmware).

Yup, this is the same problem we have in other platforms.  Take a look
at board/sunxi/mksunxi_fit_atf.sh or tools/k3_fit_atf.sh for what we do
on some other platforms so that CI build completes but it's clear to the
end user that the binary will not work and what they need to do / read
to get a functional build.  There's also
arch/arm/mach-omap2/config_secure.mk as an example of all the fun we
have for building the secure TI platforms that more closely follow the
problem you have here, namely of needing EULA'd packages (and in those
cases, also NDA, iirc) installed to complete a functional build.  I
think you'll need to do something closer to the _fit_atf.sh scripts
in this case, to check for required blobs and if not found, not call
mkimage and echo something loud and visible to the user.

-- 
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] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

On 23/10/18 16:29, Tom Rini wrote:
> On Tue, Oct 23, 2018 at 09:52:58AM +0200, Stefano Babic wrote:
> 
>> Hi Tom,
>>
>> please pull from u-boot-imx (tag: u-boot-imx-20181023) thanks !
>>
>> The tree contains fixes for i.MX6 and improvement in docs, but the most
>> important part is the introduction of the i.MX8 architecture (thanks to
>> Peng and Antolji for their work !). Build on Travis reported no error,
>> but I get a build issue with the VF610 boards - this will be require a
>> fix in next days. i.MX8 can be built following exactly the instruction
>> of the README file (NXP firmware requires to acknowledge the EULA).
> 
> I know the i.MX8 stuff has been kicking around for a while so.. OK, yes,
> I won't be too upset about pushing it so late in the cycle.  But, my
> travis builds do see an error:
> https://travis-ci.org/trini/u-boot/jobs/445069389#L1038 which is "Fail
> open first container file ahab-container.img" for imx8qxp_mek and I also
> see that locally.

I know: to build i.MX8, we need to download external firmware. In fact,
we have to provide the files according to board/freescale/mx8mq_evk/README.

Near "imx-atf" (this is not a problem, loaded and built), we need two
additional "closed" firmware, that is firmware-imx (currently, 7.6) and
imx-sc-firmware. They can be downloaded but they underly the acknowledge
of NXP's EULA. They are self extracting scripts and we could hack it to
have an automatic build, but I *guess* this breaks the license. I do not
know if we are allowed to do this, and both of these firmwares do not
provide a way to "implicitely" skip the EULA as we do in OE by setting a
variable in local.conf.

>  This feels like the same class of error that we have
> to deal with on other AArch64 platforms, namely of throwing a user
> visible error that what they just built will not boot due to lack of
> other files.

I am unsure: mkimage packs all files together as part of the build, when
they are available. User cannot even try to boot, because the build
stops if these files are not available. The error at mkimage step is
saying us that build is not complete due to missing files (atf,
firmware-imx and imx-sc-firmware).

> 
> Also:
> $ ./tools/genboardscfg.py -o /dev/null
> WARNING: no status info for 'warp7_bl33'
> WARNING: no maintainers for 'warp7_bl33'

I have not seen, thanks, this must be fixed.

> 
> which I would have just fixed-up, but since we need to address that
> imx8qxp_mek problem, please update the appropriate MAINTAINERS file too
> for warp7_bl33.  Thanks!

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Tom Rini]

On Tue, Oct 23, 2018 at 09:52:58AM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx (tag: u-boot-imx-20181023) thanks !
> 
> The tree contains fixes for i.MX6 and improvement in docs, but the most
> important part is the introduction of the i.MX8 architecture (thanks to
> Peng and Antolji for their work !). Build on Travis reported no error,
> but I get a build issue with the VF610 boards - this will be require a
> fix in next days. i.MX8 can be built following exactly the instruction
> of the README file (NXP firmware requires to acknowledge the EULA).

I know the i.MX8 stuff has been kicking around for a while so.. OK, yes,
I won't be too upset about pushing it so late in the cycle.  But, my
travis builds do see an error:
https://travis-ci.org/trini/u-boot/jobs/445069389#L1038 which is "Fail
open first container file ahab-container.img" for imx8qxp_mek and I also
see that locally.  This feels like the same class of error that we have
to deal with on other AArch64 platforms, namely of throwing a user
visible error that what they just built will not boot due to lack of
other files.

Also:
$ ./tools/genboardscfg.py -o /dev/null
WARNING: no status info for 'warp7_bl33'
WARNING: no maintainers for 'warp7_bl33'

which I would have just fixed-up, but since we need to address that
imx8qxp_mek problem, please update the appropriate MAINTAINERS file too
for warp7_bl33.  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] w1: fix build without CONFIG_W1_EEPROM

[Martin Fuzzey]

On 23/10/18 10:40, eugen.hris...@microchip.com wrote:


I tried as much as possible to decouple the W1 bus from the W1 EEPROM
memories. It is possible that we will have a different framework for
EEPROMs that will include both 1wire and i2c eeproms, and then the
interfacing would be pretty easy to change to.

That's why I am thinking that w1 bus read should not be much affected if
the 1w EEPROMs are unknown to U-boot


Yes sure that's great.

Somewhat diverting this thread

I noticed that currently "w1 read" displays the data in hex with "%x", 
which means it prints just one character if in range 00-0f.

And as there is no seperator the output isn't currently useful.

That's a trivial fix of course but it got me thinking about what do we 
want to "w1 read" to do?


A lot of other storage reading commands use "read" to mean "read to 
memory" and take a destination RAM address parameter.

Eg mmc read, sf read, ...

There are counter examples though like "mii read" or "pmic read" which 
just print the output but they don't read aribitary

user defined data like an eeprom.

So I was wondering if it would be better to modify "w1 read" to mean 
"read to memory" and add a new "w1 dump" command
to do what "w1 read" currently does (as it is much more convenient for 
quickly checking the eeprom contents than

having to use md).

The type of use case I'm thinking of for "read to memory" is if someone 
wants to put a device tree blob on an eeprom.


What do you think?

Regards,

Martin




Regards,

Martin




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

Re: [U-Boot] [PATCH 2/5] ARM: rpi_3_32b_defconfig: Add FS_UUID command

[Otavio Salvador]

On Tue, Oct 23, 2018 at 4:33 AM Alexander Graf  wrote:
> On 23.10.18 07:38, Otavio Salvador wrote:
> > From: Fabio Berton 
>
> Thanks a lot for the patch :). However, as it is it will be confusing
> for people who read the git log to figure out why this patch is in the
> tree and what its net effect is.
>
> So could you please provide a proper patch description that explains:

v2 sent.

-- 
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

[U-Boot] [PATCH v2 6/6] rv1108: Add support for default distro_bootcmd

[Otavio Salvador]

This allow easier integration of RV1108 based boards on generic
distributions and build systems.

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- new patch

 include/configs/rv1108_common.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/configs/rv1108_common.h b/include/configs/rv1108_common.h
index cc0384e2f4..99aa56ab35 100644
--- a/include/configs/rv1108_common.h
+++ b/include/configs/rv1108_common.h
@@ -28,3 +28,17 @@
 #define CONFIG_USB_OHCI_NEW
 #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1
 #endif
+
+#ifndef CONFIG_SPL_BUILD
+#define ENV_MEM_LAYOUT_SETTINGS \
+   "scriptaddr=0x6000\0" \
+   "fdt_addr_r=0x61f0\0" \
+   "kernel_addr_r=0x6200\0" \
+   "ramdisk_addr_r=0x6400\0"
+
+#include 
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   ENV_MEM_LAYOUT_SETTINGS \
+   "partitions=" PARTS_DEFAULT \
+   BOOTENV
+#endif
-- 
2.19.1

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

[U-Boot] [PATCH v2 4/6] rv1108: Enable eMMC support

[Otavio Salvador]

In order to be able to build the Rockchip eMMC driver
on rv1108, the CONFIG_BOUNCE_BUFFER option needs to be
selected.

Select it like it is done on the other Rockchip SoC common files.

This also adds the pinctrl handles to enable the use of eMMC on custom
boards (as minievk) and makes it easier for later addition.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 arch/arm/dts/rv1108.dtsi| 29 +
 include/configs/rv1108_common.h |  3 +++
 2 files changed, 32 insertions(+)

diff --git a/arch/arm/dts/rv1108.dtsi b/arch/arm/dts/rv1108.dtsi
index acfd97e18d..23a44bfaca 100644
--- a/arch/arm/dts/rv1108.dtsi
+++ b/arch/arm/dts/rv1108.dtsi
@@ -427,6 +427,35 @@
};
};
 
+   emmc {
+   emmc_clk: emmc-clk {
+   rockchip,pins = <2 RK_PB6 RK_FUNC_1 
_pull_none_drv_8ma>;
+   };
+
+   emmc_cmd: emmc-cmd {
+   rockchip,pins = <2 RK_PB4 RK_FUNC_2 
_pull_up_drv_8ma>;
+   };
+
+   emmc_pwren: emmc-pwren {
+   rockchip,pins = <2 RK_PC2 RK_FUNC_2 
_pull_none>;
+   };
+
+   emmc_bus1: emmc-bus1 {
+   rockchip,pins = <2 RK_PA0 RK_FUNC_2 
_pull_up_drv_8ma>;
+   };
+
+   emmc_bus8: emmc-bus8 {
+   rockchip,pins = <2 RK_PA0 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA1 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA2 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA3 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA4 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA5 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA6 RK_FUNC_2 
_pull_up_drv_8ma>,
+   <2 RK_PA7 RK_FUNC_2 
_pull_up_drv_8ma>;
+   };
+   };
+
sdmmc {
sdmmc_clk: sdmmc-clk {
rockchip,pins = <3 RK_PC4 RK_FUNC_1 
_pull_none_drv_4ma>;
diff --git a/include/configs/rv1108_common.h b/include/configs/rv1108_common.h
index 2ab3b85e0c..cc0384e2f4 100644
--- a/include/configs/rv1108_common.h
+++ b/include/configs/rv1108_common.h
@@ -17,6 +17,9 @@
 #define CONFIG_SYS_TIMER_BASE  0x10350020
 #define CONFIG_SYS_TIMER_COUNTER   (CONFIG_SYS_TIMER_BASE + 8)
 
+/* MMC/SD IP block */
+#define CONFIG_BOUNCE_BUFFER
+
 #define CONFIG_SYS_SDRAM_BASE  0x6000
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE + 
0x10)
 #define CONFIG_SYS_LOAD_ADDR   (CONFIG_SYS_SDRAM_BASE + 0x200)
-- 
2.19.1

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

[U-Boot] [PATCH v2 5/6] rv1108: Make USB OTG functional

[Otavio Salvador]

Like it is done for other Rockchip SoCs, introduce a board_usb_init()
function so that USB OTG can be functional on rv1108 too.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 arch/arm/dts/rv1108.dtsi  | 45 ++-
 arch/arm/mach-rockchip/Makefile   |  1 +
 arch/arm/mach-rockchip/rv1108-board.c | 81 +++
 3 files changed, 124 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/rv1108-board.c

diff --git a/arch/arm/dts/rv1108.dtsi b/arch/arm/dts/rv1108.dtsi
index 23a44bfaca..215d885225 100644
--- a/arch/arm/dts/rv1108.dtsi
+++ b/arch/arm/dts/rv1108.dtsi
@@ -121,8 +121,35 @@
};
 
grf: syscon@1030 {
-   compatible = "rockchip,rv1108-grf", "syscon";
+   compatible = "rockchip,rv1108-grf", "syscon", "simple-mfd";
reg = <0x1030 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   u2phy: usb2-phy@100 {
+   compatible = "rockchip,rv1108-usb2phy";
+   reg = <0x100 0x0c>;
+   clocks = < SCLK_USBPHY>;
+   clock-names = "phyclk";
+   #clock-cells = <0>;
+   clock-output-names = "usbphy";
+   rockchip,usbgrf = <>;
+   status = "disabled";
+
+   u2phy_otg: otg-port {
+   interrupts = ;
+   interrupt-names = "otg-mux";
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+
+   u2phy_host: host-port {
+   interrupts = ;
+   interrupt-names = "linestate";
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+   };
};
 
saradc: saradc@1038c000 {
@@ -141,6 +168,11 @@
reg = <0x2006 0x1000>;
};
 
+   usbgrf: syscon@202a {
+   compatible = "rockchip,rv1108-usbgrf", "syscon";
+   reg = <0x202a 0x1000>;
+   };
+
cru: clock-controller@2020 {
compatible = "rockchip,rv1108-cru";
reg = <0x2020 0x1000>;
@@ -200,12 +232,19 @@
};
 
usb20_otg: usb@3018 {
-   compatible = "rockchip,rv1108-usb", "rockchip,rk3288-usb",
+   compatible = "rockchip,rv1108-usb", "rockchip,rk3066-usb",
 "snps,dwc2";
reg = <0x3018 0x4>;
interrupts = ;
-   hnp-srp-disable;
+   clocks = < HCLK_OTG>;
+   clock-names = "otg";
dr_mode = "otg";
+   g-np-tx-fifo-size = <16>;
+   g-rx-fifo-size = <280>;
+   g-tx-fifo-size = <256 128 128 64 32 16>;
+   g-use-dma;
+   phys = <_otg>;
+   phy-names = "usb2-phy";
status = "disabled";
};
 
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 05706c472a..368302e1da 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board.o
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board.o
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board.o
 obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board.o
+obj-$(CONFIG_ROCKCHIP_RV1108) += rv1108-board.o
 endif
 
 obj-$(CONFIG_$(SPL_TPL_)RAM) += sdram_common.o
diff --git a/arch/arm/mach-rockchip/rv1108-board.c 
b/arch/arm/mach-rockchip/rv1108-board.c
new file mode 100644
index 00..3412f2c063
--- /dev/null
+++ b/arch/arm/mach-rockchip/rv1108-board.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2015 Google, Inc
+ */
+
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
+#include 
+#include 
+
+static struct dwc2_plat_otg_data rv1108_otg_data = {
+   .rx_fifo_sz = 512,
+   .np_tx_fifo_sz  = 16,
+   .tx_fifo_sz = 128,
+};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+   const void *blob = gd->fdt_blob;
+   bool matched = false;
+   int node, phy_node;
+   u32 grf_phy_offset;
+   const char *mode;
+
+   /* find the usb_otg node */
+   node = fdt_node_offset_by_compatible(blob, -1, "rockchip,rk3066-usb");
+   while (node > 0) {
+   mode = fdt_getprop(blob, node, "dr_mode", NULL);
+   if (mode && strcmp(mode, "otg") == 0) {
+   matched = true;
+   break;
+   }
+
+   node = fdt_node_offset_by_compatible(blob, node,
+"rockchip,rk3066-usb");
+   }
+
+   if 

[U-Boot] [PATCH v2 3/6] clk_rv1108: Sync with vendor tree

[Otavio Salvador]

Make adjustments to the rv1108 clock driver in order to align it
with the internal Rockchip version.

Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 .../include/asm/arch-rockchip/cru_rv1108.h| 143 +-
 drivers/clk/rockchip/clk_rv1108.c | 457 +-
 include/dt-bindings/clock/rv1108-cru.h| 154 --
 3 files changed, 706 insertions(+), 48 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rv1108.h 
b/arch/arm/include/asm/arch-rockchip/cru_rv1108.h
index 3cc2ed0187..4ce8caa40f 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rv1108.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rv1108.h
@@ -11,7 +11,11 @@
 #define OSC_HZ (24 * 1000 * 1000)
 
 #define APLL_HZ(600 * 100)
-#define GPLL_HZ(594 * 100)
+#define GPLL_HZ(1188 * 100)
+#define ACLK_PERI_HZ   (14850)
+#define HCLK_PERI_HZ   (14850)
+#define PCLK_PERI_HZ   (7425)
+#define ACLK_BUS_HZ(14850)
 
 struct rv1108_clk_priv {
struct rv1108_cru *cru;
@@ -80,6 +84,11 @@ enum {
WORK_MODE_NORMAL= 1,
DSMPD_SHIFT = 3,
DSMPD_MASK  = 1 << DSMPD_SHIFT,
+   INTEGER_MODE= 1,
+   GLOBAL_POWER_DOWN_SHIFT = 0,
+   GLOBAL_POWER_DOWN_MASK  = 1 << GLOBAL_POWER_DOWN_SHIFT,
+   GLOBAL_POWER_DOWN   = 1,
+   GLOBAL_POWER_UP = 0,
 
/* CLKSEL0_CON */
CORE_PLL_SEL_SHIFT  = 8,
@@ -90,11 +99,77 @@ enum {
CORE_CLK_DIV_SHIFT  = 0,
CORE_CLK_DIV_MASK   = 0x1f << CORE_CLK_DIV_SHIFT,
 
+   /* CLKSEL_CON1 */
+   PCLK_DBG_DIV_CON_SHIFT  = 4,
+   PCLK_DBG_DIV_CON_MASK   = 0xf << PCLK_DBG_DIV_CON_SHIFT,
+   ACLK_CORE_DIV_CON_SHIFT = 0,
+   ACLK_CORE_DIV_CON_MASK  = 7 << ACLK_CORE_DIV_CON_SHIFT,
+
+   /* CLKSEL_CON2 */
+   ACLK_BUS_PLL_SEL_SHIFT  = 8,
+   ACLK_BUS_PLL_SEL_MASK   = 3 << ACLK_BUS_PLL_SEL_SHIFT,
+   ACLK_BUS_PLL_SEL_GPLL   = 0,
+   ACLK_BUS_PLL_SEL_APLL   = 1,
+   ACLK_BUS_PLL_SEL_DPLL   = 2,
+   ACLK_BUS_DIV_CON_SHIFT  = 0,
+   ACLK_BUS_DIV_CON_MASK   = 0x1f << ACLK_BUS_DIV_CON_SHIFT,
+   ACLK_BUS_DIV_CON_WIDTH  = 5,
+
+   /* CLKSEL_CON3 */
+   PCLK_BUS_DIV_CON_SHIFT  = 8,
+   PCLK_BUS_DIV_CON_MASK   = 0x1f << PCLK_BUS_DIV_CON_SHIFT,
+   HCLK_BUS_DIV_CON_SHIFT  = 0,
+   HCLK_BUS_DIV_CON_MASK   = 0x1f,
+
+   /* CLKSEL_CON4 */
+   CLK_DDR_PLL_SEL_SHIFT   = 8,
+   CLK_DDR_PLL_SEL_MASK= 0x3 << CLK_DDR_PLL_SEL_SHIFT,
+   CLK_DDR_DIV_CON_SHIFT   = 0,
+   CLK_DDR_DIV_CON_MASK= 0x3 << CLK_DDR_DIV_CON_SHIFT,
+
+   /* CLKSEL_CON19 */
+   CLK_I2C1_PLL_SEL_SHIFT  = 15,
+   CLK_I2C1_PLL_SEL_MASK   = 1 << CLK_I2C1_PLL_SEL_SHIFT,
+   CLK_I2C1_PLL_SEL_DPLL   = 0,
+   CLK_I2C1_PLL_SEL_GPLL   = 1,
+   CLK_I2C1_DIV_CON_SHIFT  = 8,
+   CLK_I2C1_DIV_CON_MASK   = 0x7f << CLK_I2C1_DIV_CON_SHIFT,
+   CLK_I2C0_PLL_SEL_SHIFT  = 7,
+   CLK_I2C0_PLL_SEL_MASK   = 1 << CLK_I2C0_PLL_SEL_SHIFT,
+   CLK_I2C0_DIV_CON_SHIFT  = 0,
+   CLK_I2C0_DIV_CON_MASK   = 0x7f,
+   I2C_DIV_CON_WIDTH   = 7,
+
+   /* CLKSEL_CON20 */
+   CLK_I2C3_PLL_SEL_SHIFT  = 15,
+   CLK_I2C3_PLL_SEL_MASK   = 1 << CLK_I2C3_PLL_SEL_SHIFT,
+   CLK_I2C3_PLL_SEL_DPLL   = 0,
+   CLK_I2C3_PLL_SEL_GPLL   = 1,
+   CLK_I2C3_DIV_CON_SHIFT  = 8,
+   CLK_I2C3_DIV_CON_MASK   = 0x7f << CLK_I2C3_DIV_CON_SHIFT,
+   CLK_I2C2_PLL_SEL_SHIFT  = 7,
+   CLK_I2C2_PLL_SEL_MASK   = 1 << CLK_I2C2_PLL_SEL_SHIFT,
+   CLK_I2C2_DIV_CON_SHIFT  = 0,
+   CLK_I2C2_DIV_CON_MASK   = 0x7f,
+
/* CLKSEL_CON22 */
CLK_SARADC_DIV_CON_SHIFT= 0,
CLK_SARADC_DIV_CON_MASK = GENMASK(9, 0),
CLK_SARADC_DIV_CON_WIDTH= 10,
 
+   /* CLKSEL_CON23 */
+   ACLK_PERI_PLL_SEL_SHIFT = 15,
+   ACLK_PERI_PLL_SEL_MASK  = 1 << ACLK_PERI_PLL_SEL_SHIFT,
+   ACLK_PERI_PLL_SEL_GPLL  = 0,
+   ACLK_PERI_PLL_SEL_DPLL  = 1,
+   PCLK_PERI_DIV_CON_SHIFT = 10,
+   PCLK_PERI_DIV_CON_MASK  = 0x1f << PCLK_PERI_DIV_CON_SHIFT,
+   HCLK_PERI_DIV_CON_SHIFT = 5,
+   HCLK_PERI_DIV_CON_MASK  = 0x1f << HCLK_PERI_DIV_CON_SHIFT,
+   ACLK_PERI_DIV_CON_SHIFT = 0,
+   ACLK_PERI_DIV_CON_MASK  = 0x1f,
+   PERI_DIV_CON_WIDTH  = 5,
+
/* CLKSEL24_CON */
MAC_PLL_SEL_SHIFT   = 12,
MAC_PLL_SEL_MASK= 1 << MAC_PLL_SEL_SHIFT,
@@ -105,6 +180,16 @@ enum {
MAC_CLK_DIV_MASK   

[U-Boot] [PATCH v2 2/6] ARM: rpi_*_defconfig: Add support to find UUID for filesystem

[Otavio Salvador]

The most generic way of having a stable boot behavior is to rely on
UUID instead of device names for root partition, so the order of
probing does not cause issues with booting.

This enables the `CMD_FS_UUID` for following defconfig files:

 - rpi_0_w_defconfig
 - rpi_2_defconfig
 - rpi_3_32b_defconfig
 - rpi_3_defconfig
 - rpi_defconfig

Signed-off-by: Otavio Salvador 
Signed-off-by: Fabio Berton 
---

Changes in v2:
- rework commit

 configs/rpi_0_w_defconfig   | 1 +
 configs/rpi_2_defconfig | 1 +
 configs/rpi_3_32b_defconfig | 1 +
 configs/rpi_3_defconfig | 1 +
 configs/rpi_defconfig   | 1 +
 5 files changed, 5 insertions(+)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index d5bf01b76e..66b0de31b6 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_FS_UUID=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w"
 CONFIG_ENV_FAT_INTERFACE="mmc"
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index a50a815759..ba75e52dda 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_FS_UUID=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2836-rpi-2-b"
 CONFIG_ENV_FAT_INTERFACE="mmc"
diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
index d3d4596ba0..33c476bb4f 100644
--- a/configs/rpi_3_32b_defconfig
+++ b/configs/rpi_3_32b_defconfig
@@ -14,6 +14,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_FS_UUID=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
 CONFIG_ENV_FAT_INTERFACE="mmc"
diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
index ac99f2000a..54b6303c2d 100644
--- a/configs/rpi_3_defconfig
+++ b/configs/rpi_3_defconfig
@@ -14,6 +14,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_FS_UUID=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
 CONFIG_ENV_FAT_INTERFACE="mmc"
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
index db42ffd135..e7820cb147 100644
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_FS_UUID=y
 CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b"
 CONFIG_ENV_FAT_INTERFACE="mmc"
-- 
2.19.1

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

[U-Boot] [PATCH v2 1/6] ARM: vexpress-ca9x4_defconfig: Enable CMD_UBI support

[Otavio Salvador]

This allow for convenient use of QEMU machine to test loading of UBI
filesystem.

Acked-by: Linus Walleij 
Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 configs/vexpress_ca9x4_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/vexpress_ca9x4_defconfig b/configs/vexpress_ca9x4_defconfig
index d3c23dee17..9ca542b0f2 100644
--- a/configs/vexpress_ca9x4_defconfig
+++ b/configs/vexpress_ca9x4_defconfig
@@ -17,6 +17,7 @@ CONFIG_CMD_MMC=y
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NFS is not set
 # CONFIG_CMD_MISC is not set
+CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_BOOTCOUNT_ENV=y
-- 
2.19.1

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

[U-Boot] [PATCH] Mips: When using CONFIG_OF_SEPARATE, mips-relocs mess up _end symbol

[Lars Povlsen]

When converting some MIPS-based platforms from CONFIG_OF_EMBED to
CONFIG_OF_SEPARATE and CONFIG_MULTI_DTB_FIT, I had trouble with getting
to the right offset of the DTB blob.

It turns out that the mips-relocs utility chops off unused space in the
".rel" section, but in doing so it bring the "_end" symbol out of sync
with the actual end of the generated binary. When the DT blob is tacked
on, the "_end" symbol will not point to the start of the blob as
desired, but somewhere into the blob - causing the DT parse to fail.

This fix skips the ".rel" section shrinking to keep "_end" pointing to
the right place. Another possible solution would be to update "_end",
but that is beyond my current skills I'm afraid.

Signed-off-by: Lars Povlsen 
---
 tools/Makefile  | 1 +
 tools/mips-relocs.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/tools/Makefile b/tools/Makefile
index 0c3341e..aabb5b8 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -196,6 +196,7 @@ hostprogs-y += fdtgrep
 fdtgrep-objs += $(LIBFDT_OBJS) fdtgrep.o
 
 hostprogs-$(CONFIG_MIPS) += mips-relocs
+HOSTCFLAGS_mips-relocs.o := $(if $(CONFIG_OF_SEPARATE),-DCONFIG_OF_SEPARATE 
-Wno-unused-but-set-variable -Wno-unused-variable)
 
 # We build some files with extra pedantic flags to try to minimize things
 # that won't build on some weird host compiler -- though there are lots of
diff --git a/tools/mips-relocs.c b/tools/mips-relocs.c
index 442cc8f..9c5bf07 100644
--- a/tools/mips-relocs.c
+++ b/tools/mips-relocs.c
@@ -401,6 +401,8 @@ int main(int argc, char *argv[])
return -ENOMEM;
}
 
+// Shrinking the .rel section mess up the _end symbol when 
CONFIG_OF_SEPARATE used
+#if !defined(CONFIG_OF_SEPARATE)
/* Update the .rel section's size */
set_shdr_field(i_rel_shdr, sh_size, rel_actual_size);
 
@@ -414,6 +416,7 @@ int main(int argc, char *argv[])
set_phdr_field(i, p_filesz, load_sz);
break;
}
+#endif
 
/* Make sure data is written back to the file */
err = msync(elf, st.st_size, MS_SYNC);
-- 
2.7.4

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

[U-Boot] x86: board / CPU reset?

[Hannes Schmelzer]

Hi folks,

i'm actually porting u-boot / coreboot to some older machine. AMD Geode 
LX800.


I run into trouble while trying reset the board from console:

=>
=> reset
resetting ...
### ERROR ### Please RESET the board ###

my board uses the one and only existing 'sysreset_x86.c' reset driver.
This driver write some magic value to register 0xcf9 which causes no 
reaction on my machine.


I had last week also some trouble on resetting my apollo lake board, but 
not sure at this point if this is the same issue,

i will have access to the board tomorrow an will run a test.

But the question is, is this "generic" reset driver really as generic as 
it looks like?
The comment of the 0xcf9 register says for example, that is on atom 
E3800 so ...


A short look into the linux source code (arch/x86/kernel/reboot.c) 
showed, that there is a bunch of methods for resetting a x86 machine,

the 0xcf9 method also ...

Further they have there an instruction which also looks good on my platform:

outb(0xfe, 0x64); /* pulse reset low */


Do we have here anybody who has a bit more background than me and who 
could explain what is the right way here?


cheers,
Hannes

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

[U-Boot] [PATCH v2 07/10] arm: dts: k3: Sync dts from Linux

[Lokesh Vutla]

Sync the k3-am654 specific dts files from Linux next with tag
20181019. This changes are in queue for Linux v4.20-rc1

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-am65-main.dtsi   | 51 +--
 arch/arm/dts/k3-am65-mcu.dtsi| 18 
 arch/arm/dts/k3-am65-wakeup.dtsi | 46 ++
 arch/arm/dts/k3-am65.dtsi| 54 ++-
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 94 ++--
 5 files changed, 171 insertions(+), 92 deletions(-)
 create mode 100644 arch/arm/dts/k3-am65-mcu.dtsi
 create mode 100644 arch/arm/dts/k3-am65-wakeup.dtsi

diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index 2409344df4..adcd6341e4 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -8,13 +8,13 @@
 _main {
gic500: interrupt-controller@180 {
compatible = "arm,gic-v3";
-   #address-cells = <1>;
-   #size-cells = <1>;
+   #address-cells = <2>;
+   #size-cells = <2>;
ranges;
#interrupt-cells = <3>;
interrupt-controller;
-   reg = <0x0180 0x1>, /* GICD */
- <0x0188 0x9>; /* GICR */
+   reg = <0x00 0x0180 0x00 0x1>,   /* GICD */
+ <0x00 0x0188 0x00 0x9>;   /* GICR */
/*
 * vcpumntirq:
 * virtual CPU interface maintenance interrupt
@@ -23,9 +23,50 @@
 
gic_its: gic-its@1820 {
compatible = "arm,gic-v3-its";
-   reg = <0x0182 0x1>;
+   reg = <0x00 0x0182 0x00 0x1>;
msi-controller;
#msi-cells = <1>;
};
};
+
+   secure_proxy_main: mailbox@32c0 {
+   compatible = "ti,am654-secure-proxy";
+   #mbox-cells = <1>;
+   reg-names = "target_data", "rt", "scfg";
+   reg = <0x00 0x32c0 0x00 0x10>,
+ <0x00 0x3240 0x00 0x10>,
+ <0x00 0x3280 0x00 0x10>;
+   interrupt-names = "rx_011";
+   interrupts = ;
+   };
+
+   main_uart0: serial@280 {
+   compatible = "ti,am654-uart";
+   reg = <0x00 0x0280 0x00 0x100>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   interrupts = ;
+   clock-frequency = <4800>;
+   current-speed = <115200>;
+   };
+
+   main_uart1: serial@281 {
+   compatible = "ti,am654-uart";
+   reg = <0x00 0x0281 0x00 0x100>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   interrupts = ;
+   clock-frequency = <4800>;
+   current-speed = <115200>;
+   };
+
+   main_uart2: serial@282 {
+   compatible = "ti,am654-uart";
+   reg = <0x00 0x0282 0x00 0x100>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   interrupts = ;
+   clock-frequency = <4800>;
+   current-speed = <115200>;
+   };
 };
diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
new file mode 100644
index 00..8c611d16df
--- /dev/null
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family MCU Domain peripherals
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+_mcu {
+   mcu_uart0: serial@40a0 {
+   compatible = "ti,am654-uart";
+   reg = <0x00 0x40a0 0x00 0x100>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   interrupts = ;
+   clock-frequency = <9600>;
+   current-speed = <115200>;
+   };
+};
diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
new file mode 100644
index 00..8d7b47f9df
--- /dev/null
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family Wakeup Domain peripherals
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+_wakeup {
+   dmsc: dmsc {
+   compatible = "ti,k2g-sci";
+   ti,host-id = <12>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mbox-names = "rx", "tx";
+
+   mboxes= <_proxy_main 11>,
+   <_proxy_main 13>;
+
+   k3_pds: power-controller {
+   compatible = "ti,sci-pm-domain";
+   

[U-Boot] [PATCH v2 06/10] board: ti: am654: r5: Add initial support for am654

[Lokesh Vutla]

Add initial support for AM654 based EVM running on R5.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
---
 board/ti/am65x/Kconfig| 24 
 include/configs/am65x_evm.h   |  6 ++
 include/configs/ti_armv7_common.h |  2 ++
 3 files changed, 32 insertions(+)

diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
index 591600483e..d4b36dbb42 100644
--- a/board/ti/am65x/Kconfig
+++ b/board/ti/am65x/Kconfig
@@ -12,6 +12,14 @@ config TARGET_AM654_A53_EVM
select ARM64
select SOC_K3_AM6
 
+config TARGET_AM654_R5_EVM
+   bool "TI K3 based AM654 EVM running on R5"
+   select CPU_V7R
+   select SYS_THUMB_BUILD
+   select SOC_K3_AM6
+   select K3_AM654_DDRSS
+   imply SYS_K3_SPL_ATF
+
 endchoice
 
 if TARGET_AM654_A53_EVM
@@ -26,3 +34,19 @@ config SYS_CONFIG_NAME
default "am65x_evm"
 
 endif
+
+if TARGET_AM654_R5_EVM
+
+config SYS_BOARD
+   default "am65x"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "am65x_evm"
+
+config SPL_LDSCRIPT
+   default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+endif
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 65015df131..484c5ef2fe 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -21,6 +21,12 @@
 /* SPL Loader Configuration */
 #ifdef CONFIG_TARGET_AM654_A53_EVM
 #define CONFIG_SPL_TEXT_BASE   0x8008
+#else
+#define CONFIG_SPL_TEXT_BASE   0x41c0
+#endif
+
+#ifdef CONFIG_SYS_K3_SPL_ATF
+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"tispl.bin"
 #endif
 
 #define CONFIG_SKIP_LOWLEVEL_INIT
diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index 55b9b45eec..0f892e51d1 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -165,7 +165,9 @@
 
 /* FAT sd card locations. */
 #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
+#ifndef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"
+#endif
 
 #ifdef CONFIG_SPL_OS_BOOT
 /* FAT */
-- 
2.19.1

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

[U-Boot] [PATCH v2 08/10] armv7r: dts: am654: Add initial support

[Lokesh Vutla]

Add R5 specific dts for am654-evm.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
Signed-off-by: Keerthy 
---
 arch/arm/dts/Makefile |   2 +-
 .../dts/k3-am654-base-board-ddr4-1333MHz.dtsi | 195 ++
 arch/arm/dts/k3-am654-ddr.dtsi| 241 ++
 arch/arm/dts/k3-am654-r5-base-board.dts   | 139 ++
 4 files changed, 576 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-am654-base-board-ddr4-1333MHz.dtsi
 create mode 100644 arch/arm/dts/k3-am654-ddr.dtsi
 create mode 100644 arch/arm/dts/k3-am654-r5-base-board.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0de6234eec..821a3d79ea 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -554,7 +554,7 @@ dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
 
-dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb
+dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/arm/dts/k3-am654-base-board-ddr4-1333MHz.dtsi 
b/arch/arm/dts/k3-am654-base-board-ddr4-1333MHz.dtsi
new file mode 100644
index 00..c07e6519e5
--- /dev/null
+++ b/arch/arm/dts/k3-am654-base-board-ddr4-1333MHz.dtsi
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#define DDRCTL_DFIMISC 0x
+#define DDRCTL_DFITMG0 0x04878206
+#define DDRCTL_DFITMG1 0x00060606
+#define DDRCTL_DFITMG2 0x0504
+#define DDRCTL_INIT0   0x400100A3
+#define DDRCTL_INIT1   0x0042
+#define DDRCTL_INIT2   0x
+#define DDRCTL_INIT3   0x00100501
+#define DDRCTL_INIT4   0x0020
+#define DDRCTL_INIT5   0x0010
+#define DDRCTL_INIT6   0x0480
+#define DDRCTL_INIT7   0x0097
+#define DDRCTL_MSTR0x41040010
+#define DDRCTL_ODTCFG  0x06000608
+#define DDRCTL_ODTMAP  0x0001
+#define DDRCTL_RANKCTL 0x
+#define DDRCTL_RFSHCTL00x00210070
+#define DDRCTL_RFSHCTL30x
+#define DDRCTL_RFSHTMG 0x00510075
+#define DDRCTL_STAT0x
+#define DDRCTL_SWCTL   0x
+#define DDRCTL_SWSTAT  0x
+#define DDRCTL_ZQCTL0  0x2140
+#define DDRCTL_ZQCTL1  0x00027bc8
+#define DDRCTL_CRCPARCTL0  0x1A00
+#define DDRCTL_CRCPARCTL1  0x0048051E
+#define DDRCTL_ECCCFG0 0x
+#define DDRCTL_ADDRMAP00x001F1F1F
+#define DDRCTL_ADDRMAP10x003f0808
+#define DDRCTL_ADDRMAP20x
+#define DDRCTL_ADDRMAP30x
+#define DDRCTL_ADDRMAP40x1f1f
+#define DDRCTL_ADDRMAP50x08080808
+#define DDRCTL_ADDRMAP60x08080808
+#define DDRCTL_ADDRMAP70x0f0f
+#define DDRCTL_ADDRMAP80x0a0a
+#define DDRCTL_ADDRMAP90x000
+#define DDRCTL_ADDRMAP10   0x000
+#define DDRCTL_ADDRMAP11   0x001f1f00
+#define DDRCTL_DQMAP0  0x
+#define DDRCTL_DQMAP1  0x
+#define DDRCTL_DQMAP4  0x
+#define DDRCTL_DQMAP5  0x
+#define DDRCTL_PWRCTL  0x
+#define DDRCTL_DRAMTMG00x0b0a160b
+#define DDRCTL_DRAMTMG10x00020310
+#define DDRCTL_DRAMTMG20x0506040a
+#define DDRCTL_DRAMTMG30x400C
+#define DDRCTL_DRAMTMG40x05020205
+#define DDRCTL_DRAMTMG50x04040302
+#define DDRCTL_DRAMTMG60x000
+#define DDRCTL_DRAMTMG70x
+#define DDRCTL_DRAMTMG80x02020C04
+#define DDRCTL_DRAMTMG90x00020208
+#define DDRCTL_DRAMTMG11   0x1005010E
+#define DDRCTL_DRAMTMG12   0x0008
+#define DDRCTL_DRAMTMG13   0x
+#define DDRCTL_DRAMTMG14   0x
+#define DDRCTL_DRAMTMG15   0x0035
+#define DDRCTL_DRAMTMG17   0x
+#define DDRPHY_DCR 0x040C
+#define DDRPHY_DSGCR   0x02A0C129
+#define DDRPHY_DX0GCR0 0x
+#define DDRPHY_DX0GCR1 0x
+#define DDRPHY_DX0GCR2 0x
+#define DDRPHY_DX0GCR3 0x
+#define DDRPHY_DX0GCR4 0x0E00c93C
+#define DDRPHY_DX0GCR5 0x0049
+#define DDRPHY_DX0GSR0 0x
+#define DDRPHY_DX0GSR1 0x
+#define DDRPHY_DX0GSR2 0x
+#define DDRPHY_DX0GSR3 0x
+#define DDRPHY_DX0GSR4 0x
+#define DDRPHY_DX0GSR5 0x
+#define DDRPHY_DX0GSR6 0x
+#define DDRPHY_DX0GTR0 0x00020002
+#define DDRPHY_DX1GCR0 0x
+#define DDRPHY_DX1GCR1 0x
+#define 

[U-Boot] [PATCH v2 09/10] configs: am65x_evm_r5: Add initial support

[Lokesh Vutla]

Add initial defconfig support for AM65x
that runs on R5.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
Signed-off-by: Keerthy 
---
 board/ti/am65x/MAINTAINERS |  1 +
 configs/am65x_evm_r5_defconfig | 87 ++
 2 files changed, 88 insertions(+)
 create mode 100644 configs/am65x_evm_r5_defconfig

diff --git a/board/ti/am65x/MAINTAINERS b/board/ti/am65x/MAINTAINERS
index ca1ce58f72..7c52e7599e 100644
--- a/board/ti/am65x/MAINTAINERS
+++ b/board/ti/am65x/MAINTAINERS
@@ -4,3 +4,4 @@ S:  Maintained
 F: board/ti/am65x/
 F: include/configs/am65x_evm.h
 F: configs/am65x_evm_a53_defconfig
+F: configs/am65x_evm_r5_defconfig
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
new file mode 100644
index 00..548c7b4282
--- /dev/null
+++ b/configs/am65x_evm_r5_defconfig
@@ -0,0 +1,87 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_R5_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FAT_SUPPORT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_USE_BOOTCOMMAND=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-r5-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_GPIO=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_K3_ARASAN=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_RAM=y
+CONFIG_SPL_RAM=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_K3=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_TIMER=y
+CONFIG_SPL_TIMER=y
+CONFIG_OMAP_TIMER=y
-- 
2.19.1

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

[U-Boot] [PATCH v2 04/10] armv7R: K3: am654: Add support to start ATF from R5 SPL

[Lokesh Vutla]

Considering the boot time requirements, Cortex-A core
should be able to start immediately after SPL on R5.
Add support for the same.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/Kconfig  |  7 ++
 arch/arm/mach-k3/Makefile |  1 +
 arch/arm/mach-k3/common.c | 52 +++
 3 files changed, 60 insertions(+)
 create mode 100644 arch/arm/mach-k3/common.c

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 9f5e8e5ee4..e677a2e01b 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -58,5 +58,12 @@ config SYS_K3_BOOT_CORE_ID
int
default 16
 
+config SYS_K3_SPL_ATF
+   bool "Start Cortex-A from SPL"
+   depends on SPL && CPU_V7R
+   help
+ Enabling this will try to start Cortex-A (typically with ATF)
+ after SPL from R5.
+
 source "board/ti/am65x/Kconfig"
 endif
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 619733fb87..406dda3b02 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,3 +6,4 @@
 obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
 obj-$(CONFIG_ARM64) += arm64-mmu.o
 obj-$(CONFIG_CPU_V7R) += r5_mpu.o
+obj-y += common.o
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
new file mode 100644
index 00..cc89d4a296
--- /dev/null
+++ b/arch/arm/mach-k3/common.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: Common Architecture initialization
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include "common.h"
+#include 
+#include 
+
+#ifdef CONFIG_SYS_K3_SPL_ATF
+void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+{
+   int ret;
+
+   /*
+* It is assumed that remoteproc device 1 is the corresponding
+* cortex A core which runs ATF. Make sure DT reflects the same.
+*/
+   ret = rproc_dev_init(1);
+   if (ret) {
+   printf("%s: ATF failed to Initialize on rproc: ret= %d\n",
+  __func__, ret);
+   hang();
+   }
+
+   ret = rproc_load(1, spl_image->entry_point, 0x200);
+   if (ret) {
+   printf("%s: ATF failed to load on rproc: ret= %d\n",
+  __func__, ret);
+   hang();
+   }
+
+   /* Add an extra newline to differentiate the ATF logs from SPL*/
+   printf("Starting ATF on ARM64 core...\n\n");
+
+   ret = rproc_start(1);
+   if (ret) {
+   printf("%s: ATF failed to start on rproc: ret= %d\n",
+  __func__, ret);
+   hang();
+   }
+
+   debug("ATF started. Wait indefiniely\n");
+   while (1)
+   asm volatile("wfe");
+}
+#endif
-- 
2.19.1

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

[U-Boot] [PATCH v2 03/10] armv7R: K3: am654: Add support for generating build targets

[Lokesh Vutla]

Update Makefiles to generate:
- tiboot3.bin: Image format that can be processed by ROM.

Below is the tiboot3.bin image format that is required by ROM:

 ___
|X509   |
| Certificate   |
|   |
| |   | |
| | u-boot-spl.bin| |
| |   | |
| |___| |
|___|

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
---
 arch/arm/mach-k3/Kconfig   | 11 +++
 arch/arm/mach-k3/config.mk | 59 ++
 tools/k3_x509template.txt  | 48 +++
 3 files changed, 118 insertions(+)
 create mode 100644 tools/k3_x509template.txt

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 2df6197af7..9f5e8e5ee4 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -47,5 +47,16 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
  Address at which ROM stores the value which determines if SPL
  is booted up by primary boot media or secondary boot media.
 
+config SYS_K3_KEY
+   string "Key used to generate x509 certificate"
+   help
+ This option enables to provide a custom key that can be used for
+ generating x509 certificate for spl binary. If not needed leave
+ it blank so that a random key is generated and used.
+
+config SYS_K3_BOOT_CORE_ID
+   int
+   default 16
+
 source "board/ti/am65x/Kconfig"
 endif
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index 9b86ddc715..b2c5a33520 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -5,6 +5,65 @@
 
 ifdef CONFIG_SPL_BUILD
 
+# Openssl is required to generate x509 certificate.
+# Error out if openssl is not available.
+ifeq ($(shell which openssl),)
+$(error "No openssl in $(PATH), consider installing openssl")
+endif
+
+SHA_VALUE=  $(shell openssl dgst -sha512 -hex $(obj)/u-boot-spl.bin | sed -e 
"s/^.*= //g")
+IMAGE_SIZE= $(shell cat $(obj)/u-boot-spl.bin | wc -c)
+LOADADDR= $(shell echo $(CONFIG_SPL_TEXT_BASE) | sed -e "s/^0x//g")
+MAX_SIZE= $(shell printf "%d" $(CONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE))
+
+# Parameters to get populated into the x509 template
+SED_OPTS=  -e s/TEST_IMAGE_LENGTH/$(IMAGE_SIZE)/
+SED_OPTS+= -e s/TEST_IMAGE_SHA_VAL/$(SHA_VALUE)/
+SED_OPTS+= -e s/TEST_CERT_TYPE/1/  # CERT_TYPE_PRIMARY_IMAGE_BIN
+SED_OPTS+= -e s/TEST_BOOT_CORE/$(CONFIG_SYS_K3_BOOT_CORE_ID)/
+SED_OPTS+= -e s/TEST_BOOT_ARCH_WIDTH/32/
+SED_OPTS+= -e s/TEST_BOOT_ADDR/$(LOADADDR)/
+
+# Command to generate ecparam key
+quiet_cmd_genkey = OPENSSL $@
+cmd_genkey = openssl ecparam -out $@ -name prime256v1 -genkey
+
+# Command to generate x509 certificate
+quiet_cmd_gencert = OPENSSL $@
+cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | sed $(SED_OPTS) > 
u-boot-spl-x509.txt; \
+   openssl req -new -x509 -key $(KEY) -nodes -outform DER -out $@ -config 
u-boot-spl-x509.txt -sha512
+
+# If external key is not provided, generate key using openssl.
+ifeq ($(CONFIG_SYS_K3_KEY), "")
+KEY=u-boot-spl-eckey.pem
+else
+KEY=$(CONFIG_SYS_K3_KEY)
+endif
+
+u-boot-spl-eckey.pem: FORCE
+   $(call if_changed,genkey)
+
+# tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
+# So restrict tiboot3.bin creation for CPU_V7R.
+ifdef CONFIG_CPU_V7R
+u-boot-spl-cert.bin: u-boot-spl-eckey.pem $(obj)/u-boot-spl.bin image_check 
FORCE
+   $(call if_changed,gencert)
+
+image_check: $(obj)/u-boot-spl.bin FORCE
+   @if [ $(IMAGE_SIZE) -gt $(MAX_SIZE) ]; then \
+   echo "===" >&2; \
+   echo "ERROR: Final Image too big. " >&2;\
+   echo "$< size = $(IMAGE_SIZE), max size = $(MAX_SIZE)" >&2; \
+   echo "===" >&2; \
+   exit 1; \
+   fi
+
+tiboot3.bin: u-boot-spl-cert.bin $(obj)/u-boot-spl.bin FORCE
+   $(call if_changed,cat)
+
+ALL-y  += tiboot3.bin
+endif
+
 ifdef CONFIG_ARM64
 SPL_ITS := u-boot-spl-k3.its
 $(SPL_ITS): FORCE
diff --git a/tools/k3_x509template.txt b/tools/k3_x509template.txt
new file mode 100644
index 00..bd3a9ab056
--- /dev/null
+++ b/tools/k3_x509template.txt
@@ -0,0 +1,48 @@
+ [ req ]
+ distinguished_name = req_distinguished_name
+ x509_extensions= v3_ca
+ prompt = no
+ dirstring_type = nobmp
+
+ [ req_distinguished_name ]
+ C  = US
+ ST = TX
+ L  = Dallas
+ O  = Texas Instruments Incorporated
+ OU = Processors
+ CN = TI Support
+ emailAddress   = supp...@ti.com

[U-Boot] [PATCH v2 10/10] board: ti: am65x: Update README to add R5 build support

[Lokesh Vutla]

Update the README file to add r5 build support and system
firmware support.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
---
 board/ti/am65x/README | 114 ++
 1 file changed, 92 insertions(+), 22 deletions(-)

diff --git a/board/ti/am65x/README b/board/ti/am65x/README
index e7f4ff6578..0b82bd557b 100644
--- a/board/ti/am65x/README
+++ b/board/ti/am65x/README
@@ -37,13 +37,13 @@ instead use Flacon boot flow to reduce boot time.
 |++  |   |   |
 | :  |   |   |
 |++  |   +---+   |   |
-|| *rom*  |--|-->| Reset rls |   |   |
+|| *ROM*  |--|-->| Reset rls |   |   |
 |++  |   +---+   |   |
 |||  | : |   |
-||  rom   |  | : |   |
+||  ROM   |  | : |   |
 ||services|  | : |   |
 |||  |   +-+ |   |
-|||  |   |  *R5 rom*   | |   |
+|||  |   |  *R5 ROM*   | |   |
 |||  |   +-+ |   |
 |||<-|---|Load and auth| |   |
 |||  |   | tiboot3.bin | |   |
@@ -52,17 +52,25 @@ instead use Flacon boot flow to reduce boot time.
 |||  | : |   |
 |||  | : |   |
 |||  |   +-+ |   |
-|| Start  |  |   |  *R5 SPL*   | |   |
-|| System |  |   +-+ |   |
-||Firmware|<-|---|Load and auth| |   |
-|++  |   |  sysfw bin  | |   |
-|:   |   +-+ |   |
-|+-+ |   | DDR | |   |
-|| *SYSFW* | |   |config   | |   |
-|+-+ |   +-+ |   |
-|| |<|---|Load | |   |
-|| | |   |  tispl.bin  | |   |
+|||  |   |  *R5 SPL*   | |   |
+|||  |   +-+ |   |
+|||  |   |Load | |   |
+|||  |   |  sysfw.itb  | |   |
+|| Start  |  |   +-+ |   |
+|| System |<-|---|Start| |   |
+||Firmware|  |   |SYSFW| |   |
+|++  |   +-+ |   |
+|:   |   | | |   |
+|+-+ |   |   Load  | |   |
+|| *SYSFW* | |   |   system| |   |
+|+-+ |   | Config data | |   |
+|| |<|---| | |   |
+|| | |   +-+ |   |
+|| | |   | | |   |
+|| | |   |DDR  | |   |
+|| | |   |   config| |   |
 || | |   +-+ |   |
+|| | |   | | |   |
 || |<|---| Start A53   | |   |
 || | |   |  and Reset  | |   |
 || | |   +-+ |   |
@@ -82,7 +90,7 @@ instead use Flacon boot flow to reduce boot time.
 || | |   | +---+ |
 || | |   |  :|
 || | |   | +---+ |
-|| |<|---|>| *u-boot*  | |
+|| |<|---|>| *U-Boot*  | |
 || | |   | +---+ |
 || 

[U-Boot] [PATCH v2 05/10] armv7R: K3: am654: Add support for triggering ddr init from SPL

[Lokesh Vutla]

In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support
for triggering DDR initialization from board_init_f().

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/am6_init.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index fef0107505..e2fe00c422 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include "common.h"
+#include 
 
 #ifdef CONFIG_SPL_BUILD
 static void mmr_unlock(u32 base, u32 partition)
@@ -57,6 +58,10 @@ static void store_boot_index_from_rom(void)
 
 void board_init_f(ulong dummy)
 {
+#if defined(CONFIG_K3_AM654_DDRSS)
+   struct udevice *dev;
+   int ret;
+#endif
/*
 * Cannot delay this further as there is a chance that
 * K3_BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section.
@@ -75,6 +80,14 @@ void board_init_f(ulong dummy)
 
/* Prepare console output */
preloader_console_init();
+
+#ifdef CONFIG_K3_AM654_DDRSS
+   ret = uclass_get_device(UCLASS_RAM, 0, );
+   if (ret) {
+   printf("DRAM init failed: %d\n", ret);
+   return;
+   }
+#endif
 }
 
 u32 spl_boot_mode(const u32 boot_device)
-- 
2.19.1

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

[U-Boot] [PATCH v2 02/10] armv7R: K3: am654: Enable MPU regions

[Lokesh Vutla]

Enable MPU regions for AM654 evm:
- Region0: 0x - 0x: Device memory, not executable
- Region1: 0x41c0 - 0x4240: Normal, executable, WB, Write alloc
- Region2: 0x8000 - 0x: Normal, executable, WB, Write alloc
- region3-15: Disabled

With this dcache can be enabled either in SPL or U-Boot.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/Makefile   |  1 +
 arch/arm/mach-k3/am6_init.c |  5 
 arch/arm/mach-k3/common.h   | 11 +
 arch/arm/mach-k3/r5_mpu.c   | 47 +
 4 files changed, 64 insertions(+)
 create mode 100644 arch/arm/mach-k3/common.h
 create mode 100644 arch/arm/mach-k3/r5_mpu.c

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index e9b7ee5210..619733fb87 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
 obj-$(CONFIG_ARM64) += arm64-mmu.o
+obj-$(CONFIG_CPU_V7R) += r5_mpu.o
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 68f0b8c011..fef0107505 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include "common.h"
 
 #ifdef CONFIG_SPL_BUILD
 static void mmr_unlock(u32 base, u32 partition)
@@ -65,6 +66,10 @@ void board_init_f(ulong dummy)
/* Make all control module registers accessible */
ctrl_mmr_unlock();
 
+#ifdef CONFIG_CPU_V7R
+   setup_k3_mpu_regions();
+#endif
+
/* Init DM early in-order to invoke system controller */
spl_early_init();
 
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
new file mode 100644
index 00..ac7e80d9af
--- /dev/null
+++ b/arch/arm/mach-k3/common.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * K3: Architecture common definitions
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+
+void setup_k3_mpu_regions(void);
diff --git a/arch/arm/mach-k3/r5_mpu.c b/arch/arm/mach-k3/r5_mpu.c
new file mode 100644
index 00..ee076ed877
--- /dev/null
+++ b/arch/arm/mach-k3/r5_mpu.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: R5 MPU region definitions
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include "common.h"
+
+struct mpu_region_config k3_mpu_regions[16] = {
+   /*
+* Make all 4GB as Device Memory and not executable. We are overriding
+* it with next region for any requirement.
+*/
+   {0x, REGION_0, XN_EN, PRIV_RW_USR_RW, SHARED_WRITE_BUFFERED,
+REGION_4GB},
+
+   /* SPL code area marking it as WB and Write allocate. */
+   {CONFIG_SPL_TEXT_BASE, REGION_1, XN_DIS, PRIV_RW_USR_RW,
+O_I_WB_RD_WR_ALLOC, REGION_8MB},
+
+   /* U-Boot's code area marking it as WB and Write allocate */
+   {CONFIG_SYS_SDRAM_BASE, REGION_2, XN_DIS, PRIV_RW_USR_RW,
+O_I_WB_RD_WR_ALLOC, REGION_2GB},
+   {0x0, 3, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 4, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 5, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 6, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 7, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 8, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 9, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 10, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 11, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 12, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 13, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 14, 0x0, 0x0, 0x0, 0x0},
+   {0x0, 15, 0x0, 0x0, 0x0, 0x0},
+};
+
+void setup_k3_mpu_regions(void)
+{
+   setup_mpu_regions(k3_mpu_regions, ARRAY_SIZE(k3_mpu_regions));
+}
-- 
2.19.1

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

[U-Boot] [PATCH v2 01/10] ram: Introduce K3 AM654 DDR Sub System driver

[Lokesh Vutla]

K3 based AM654 devices has DDR memory subsystem that comprises
Synopys DDR controller, Synopsis DDR phy and wrapper logic to
intergrate these blocks into the device. This DDR subsystem
provides an interface to external SDRAM devices. Adding support
for the initialization of the external SDRAM devices by
configuring the DDRSS registers and using the buitin PHY
routines.

Reviewed-by: Tom Rini 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Andreas Dannenberg 
Signed-off-by: Keerthy 
---
 arch/arm/mach-k3/include/mach/sys_proto.h |   14 +
 .../ram/k3-am654-ddrss.txt|   46 +
 drivers/ram/Kconfig   |   11 +
 drivers/ram/Makefile  |2 +
 drivers/ram/k3-am654-ddrss.c  |  776 +++
 drivers/ram/k3-am654-ddrss.h  | 1227 +
 6 files changed, 2076 insertions(+)
 create mode 100644 arch/arm/mach-k3/include/mach/sys_proto.h
 create mode 100644 doc/device-tree-bindings/ram/k3-am654-ddrss.txt
 create mode 100644 drivers/ram/k3-am654-ddrss.c
 create mode 100644 drivers/ram/k3-am654-ddrss.h

diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h 
b/arch/arm/mach-k3/include/mach/sys_proto.h
new file mode 100644
index 00..0b2007981a
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andreas Dannenberg 
+ */
+
+#ifndef _SYS_PROTO_H_
+#define _SYS_PROTO_H_
+
+void sdelay(unsigned long loops);
+u32 wait_on_value(u32 read_bit_mask, u32 match_value, void *read_addr,
+ u32 bound);
+
+#endif
diff --git a/doc/device-tree-bindings/ram/k3-am654-ddrss.txt 
b/doc/device-tree-bindings/ram/k3-am654-ddrss.txt
new file mode 100644
index 00..1dde13b00e
--- /dev/null
+++ b/doc/device-tree-bindings/ram/k3-am654-ddrss.txt
@@ -0,0 +1,46 @@
+Texas Instruments' K3 AM654 DDRSS
+=
+
+K3 based AM654 devices has DDR memory subsystem that comprises
+Synopys DDR controller, Synopsis DDR phy and wrapper logic to
+integrate these blocks into the device. This DDR subsystem
+provides an interface to external SDRAM devices. This DDRSS driver
+adds support for the initialization of the external SDRAM devices by
+configuring the DDRSS registers and using the buitin PHY
+initialization routines.
+
+DDRSS device node:
+==
+Required properties:
+
+- compatible:  Shall be: "ti,am654-ddrss"
+- reg-namesss - Map the sub system wrapper logic region
+   ctl - Map the controller region
+   phy - Map the PHY region
+- reg: Contains the register map per reg-names.
+- power-domains:   Should contain a phandle to a PM domain provider node
+   and an args specifier containing the DDRSS device id
+   value. This property is as per the binding,
+   doc/device-tree-bindings/power/ti,sci-pm-domain.txt
+- clocks:  Must contain an entry for each entry in clock-names. 
Should
+   be defined as per the appropriate clock bindings 
consumer
+   usage in doc/device-tree-bindings/clock/ti,sci-clk.txt
+- clock-names: TBD. Do we need?
+
+Optional Properties:
+
+- clock-frequency: Frequency at which DDR pll should be locked.
+   If not provided, default frequency will be used.
+
+Example (AM65x):
+
+   memory-controller: memory-controller@298e000 {
+   compatible = "ti,am654-ddrss";
+   reg = <0x0298e000 0x200>,
+   <0x0298 0x4000>,
+   <0x02988000 0x2000>;
+   reg-names = "ss", "ctl", "phy";
+   clocks = <_clks 20 0>;
+   power-domains = <_pds 20>;
+   u-boot,dm-spl;
+   };
diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index 54bb4b419f..fbf7d7b20f 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -43,4 +43,15 @@ config MPC83XX_SDRAM
  the RAM through the use of SPD (Serial Presence Detect) is supported
  via device tree settings.
 
+config K3_AM654_DDRSS
+   bool "Enable AM654 DDRSS support"
+   depends on RAM && SOC_K3_AM6
+   help
+ K3 based AM654 devices has DDR memory subsystem that comprises
+ Synopys DDR controller, Synopsis DDR phy and wrapper logic to
+ intergrate these blocks into the device. This DDR subsystem
+ provides an interface to external SDRAM devices. Enabling this
+ config add support for the initialization of the external
+ SDRAM devices connected to DDR subsystem.
+
 source "drivers/ram/stm32mp1/Kconfig"
diff --git a/drivers/ram/Makefile 

[U-Boot] [PATCH v2 00/10] arm: am654: Add r5 support for am654-evm

[Lokesh Vutla]

This series adds r5 build support for booting am654 evm.

There is still 1 step(loading system firmware) missing to complete
the full boot. This will be posted as a separate series.

Changes since v1:
- Fixed SPDX headers in patch 1/10
- Updated Linux tag from which dts got synced.
- Updated Reviewed-by tags

Lokesh Vutla (10):
  ram: Introduce K3 AM654 DDR Sub System driver
  armv7R: K3: am654: Enable MPU regions
  armv7R: K3: am654: Add support for generating build targets
  armv7R: K3: am654: Add support to start ATF from R5 SPL
  armv7R: K3: am654: Add support for triggering ddr init from SPL
  board: ti: am654: r5: Add initial support for am654
  arm: dts: k3: Sync dts from Linux
  armv7r: dts: am654: Add initial support
  configs: am65x_evm_r5: Add initial support
  board: ti: am65x: Update README to add R5 build support

 arch/arm/dts/Makefile |2 +-
 arch/arm/dts/k3-am65-main.dtsi|   51 +-
 arch/arm/dts/k3-am65-mcu.dtsi |   18 +
 arch/arm/dts/k3-am65-wakeup.dtsi  |   46 +
 arch/arm/dts/k3-am65.dtsi |   54 +-
 .../dts/k3-am654-base-board-ddr4-1333MHz.dtsi |  195 +++
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |   94 +-
 arch/arm/dts/k3-am654-ddr.dtsi|  241 
 arch/arm/dts/k3-am654-r5-base-board.dts   |  139 ++
 arch/arm/mach-k3/Kconfig  |   18 +
 arch/arm/mach-k3/Makefile |2 +
 arch/arm/mach-k3/am6_init.c   |   18 +
 arch/arm/mach-k3/common.c |   52 +
 arch/arm/mach-k3/common.h |   11 +
 arch/arm/mach-k3/config.mk|   59 +
 arch/arm/mach-k3/include/mach/sys_proto.h |   14 +
 arch/arm/mach-k3/r5_mpu.c |   47 +
 board/ti/am65x/Kconfig|   24 +
 board/ti/am65x/MAINTAINERS|1 +
 board/ti/am65x/README |  114 +-
 configs/am65x_evm_r5_defconfig|   87 ++
 .../ram/k3-am654-ddrss.txt|   46 +
 drivers/ram/Kconfig   |   11 +
 drivers/ram/Makefile  |2 +
 drivers/ram/k3-am654-ddrss.c  |  776 +++
 drivers/ram/k3-am654-ddrss.h  | 1227 +
 include/configs/am65x_evm.h   |6 +
 include/configs/ti_armv7_common.h |2 +
 tools/k3_x509template.txt |   48 +
 29 files changed, 3290 insertions(+), 115 deletions(-)
 create mode 100644 arch/arm/dts/k3-am65-mcu.dtsi
 create mode 100644 arch/arm/dts/k3-am65-wakeup.dtsi
 create mode 100644 arch/arm/dts/k3-am654-base-board-ddr4-1333MHz.dtsi
 create mode 100644 arch/arm/dts/k3-am654-ddr.dtsi
 create mode 100644 arch/arm/dts/k3-am654-r5-base-board.dts
 create mode 100644 arch/arm/mach-k3/common.c
 create mode 100644 arch/arm/mach-k3/common.h
 create mode 100644 arch/arm/mach-k3/include/mach/sys_proto.h
 create mode 100644 arch/arm/mach-k3/r5_mpu.c
 create mode 100644 configs/am65x_evm_r5_defconfig
 create mode 100644 doc/device-tree-bindings/ram/k3-am654-ddrss.txt
 create mode 100644 drivers/ram/k3-am654-ddrss.c
 create mode 100644 drivers/ram/k3-am654-ddrss.h
 create mode 100644 tools/k3_x509template.txt

-- 
2.19.1

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

Re: [U-Boot] [PATCH v3 03/11] drivers: spi: cf_spi: convert to driver model

[Jagan Teki]

On Sun, Oct 14, 2018 at 1:00 PM Angelo Dureghello  wrote:
>
> Converting to driver model and removes non-dm code.
>
> 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
> ---
>  drivers/spi/cf_spi.c| 517 +++-
>  include/dm/platform_data/spi_coldfire.h |  29 ++
>  2 files changed, 352 insertions(+), 194 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..bc6a156df9 100644
> --- a/drivers/spi/cf_spi.c
> +++ b/drivers/spi/cf_spi.c
> @@ -6,16 +6,25 @@
>   *
>   * 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 
>
> -struct cf_spi_slave {
> -   struct spi_slave slave;
> +struct coldfire_spi_priv {
> +   struct dspi *regs;
> uint baudrate;
> +   int mode;
> int charbit;
>  };
>
> @@ -38,14 +47,30 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define SPI_MODE_MOD   0x0020
>  #define SPI_DBLRATE0x0010
>
> -static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave *slave)
> -{
> -   return container_of(slave, struct cf_spi_slave, slave);
> -}
> +#define MCF_DSPI_MAX_CTAR_REGS 8
>
> -static void cfspi_init(void)
> +/* 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))
> +
> +static void __spi_init(struct coldfire_spi_priv *cfspi)
>  {
> -   volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
> +   struct dspi *dspi = cfspi->regs;
> +   int i;
> +
> +   /* Default CTARs */
> +   for (i = 0; i < MCF_DSPI_MAX_CTAR_REGS; i++)
> +   writel(MCF_DSPI_DEFAULT_CTAR, >ctar[i]);
>
> cfspi_port_conf();  /* port configuration */
>
> @@ -53,128 +78,9 @@ static void cfspi_init(void)
> DSPI_MCR_CSIS5 | DSPI_MCR_CSIS4 | DSPI_MCR_CSIS3 |
> DSPI_MCR_CSIS2 | DSPI_MCR_CSIS1 | DSPI_MCR_CSIS0 |
> DSPI_MCR_CRXF | DSPI_MCR_CTXF;
> -
> -   /* Default setting in platform configuration */
> -#ifdef CONFIG_SYS_DSPI_CTAR0
> -   dspi->ctar[0] = CONFIG_SYS_DSPI_CTAR0;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR1
> -   dspi->ctar[1] = CONFIG_SYS_DSPI_CTAR1;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR2
> -   dspi->ctar[2] = CONFIG_SYS_DSPI_CTAR2;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR3
> -   dspi->ctar[3] = CONFIG_SYS_DSPI_CTAR3;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR4
> -   dspi->ctar[4] = CONFIG_SYS_DSPI_CTAR4;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR5
> -   dspi->ctar[5] = CONFIG_SYS_DSPI_CTAR5;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR6
> -   dspi->ctar[6] = CONFIG_SYS_DSPI_CTAR6;
> -#endif
> -#ifdef CONFIG_SYS_DSPI_CTAR7
> -   dspi->ctar[7] = CONFIG_SYS_DSPI_CTAR7;
> -#endif
> -}
> -
> -static void cfspi_tx(u32 ctrl, u16 data)
> -{
> -   volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
> -
> -   while ((dspi->sr & 0xF000) >= 4) ;
> -
> -   dspi->tfr = (ctrl | data);
>  }
>
> -static u16 cfspi_rx(void)
> -{
> -   volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
> -
> -   while ((dspi->sr & 0x00F0) == 0) ;
> -
> -   return (dspi->rfr & 0x);
> -}
> -
> -static int cfspi_xfer(struct spi_slave *slave, uint bitlen, const void *dout,
> - void *din, ulong flags)
> -{
> -   struct cf_spi_slave *cfslave = to_cf_spi_slave(slave);
> -   u16 *spi_rd16 = NULL, *spi_wr16 = NULL;
> -   u8 *spi_rd = NULL, *spi_wr = NULL;
> -   static u32 ctrl = 0;
> -   uint len = bitlen >> 3;
> -
> -   if (cfslave->charbit == 16) {
> -   bitlen >>= 1;
> -   spi_wr16 = (u16 *) dout;
> -   spi_rd16 = (u16 *) din;
> -   } else {
> -   spi_wr = (u8 *) dout;
> -   spi_rd = (u8 *) din;
> -   }
> -
> -   if ((flags & SPI_XFER_BEGIN) == SPI_XFER_BEGIN)
> -   ctrl 

Re: [U-Boot] latest kwboot

[Balanga Bar]

When trying to compile the current version of kwboot.c I get errors because
of missing headers such as 

On Tue, Oct 23, 2018 at 10:15 AM Chris Packham 
wrote:

>
>
> On Tue, 23 Oct 2018, 10:00 PM Balanga Bar,  wrote:
>
>> Thanks for the suggestion.
>>
>> I'm not very experienced with git
>>
>> How would I 'git checkout v2013.02 tools/kwboot.c' ?
>>
>
> Clone the u-boot repo with
>
> git clone git://git.denx.de/u-boot.git
>
> Go back to an older version with
>
> git checkout v2013.02
>
> (or any other tag you wish to have a look at)
>
> Have a look at git-scm.com for more info on using git.
>
> That all being said you haven't actually said what is stopping the current
> version of kwboot.c from working for you.
>
>
>> On Tue, Oct 23, 2018 at 2:18 AM Chris Packham 
>> wrote:
>>
>>>
>>>
>>> On Tue, 23 Oct 2018, 10:33 AM Balanga Bar, 
>>> wrote:
>>>
 I'm trying to build kwboot on FreeBSD but the latest source I found is
 not
 posix compliant, containing various Linuxisms... I did find an old
 version
 here
>>>
>>>
 https://github.com/LeMaker/u-boot/raw/master/tools/kwboot.c

 that I was able to compile. Is there anything newer?

>>>
>>> You can just obtain older versions from the u-boot source (e.g git
>>> checkout v2013.02 tools/kwboot.c).
>>>
>>>
 Alternatively is anyone aware of a binary which works on FreeBSD?

>>>
>>> What linuxisms are problematic for you. Perhaps they can be avoided.
>>>
 ___
 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] mtd: nand: let the raw NAND devices be compiled upon selection

[Jagan Teki]

On Thu, Oct 11, 2018 at 3:05 PM Miquel Raynal  wrote:
>
> Today way is to rely on CMD_NAND to be selected and from the root
> Makefile compile what is in drivers/mtd/nand/raw.
>
> While this will work most of the time with decent configurations, it
> is better to also compile this subsystem upon simple request in the
> configuration. Otherwise, a user not selecting CMD_NAND but selecting
> NAND and any of the controller drivers will not see their build. Fix
> this weird situation by adding a single line in the nand/ directory
> Kconfig file.
>
> Signed-off-by: Miquel Raynal 
> ---
>  drivers/mtd/nand/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index a358bc680e..2c33447995 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -2,4 +2,5 @@
>
>  nandcore-objs := core.o bbt.o
>  obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> +obj-$(CONFIG_NAND) += raw/

But we even source raw Kconfig path, isn't it? and also how about
remove this from root Makefile?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add raw read support and use it in pxa3xx NAND driver

[Jagan Teki]

On Thu, Oct 11, 2018 at 9:16 PM Miquel Raynal  wrote:
>
> When using 2kiB-pages NAND chips requesting an 8-bit strength ECC, the
> layout used is a bit particular and it happens that the ECC engine
> tries to correct uncorrectable errors on empty pages, producing
> bitflips.
>
> To avoid such situation, raw read support is added to the pxa3xx_nand
> driver, and then used to re-read the page (in raw mode) upon
> uncorrectable error detection to know if there is an actual ECC
> mismatch or if the page is empty. This way we avoid seeing the
> bitflips created by the hardware ECC engine.
>
> Once this done, we can revert the hack that was done in the driver to
> enlarge the last spare area for this layout to 64B instead of 32B,
> breaking U-Boot/Linux compatibility and preventing the BootROM to boot
> from NAND.
>
> Thanks,
> Miquèl
>
>
> Miquel Raynal (3):
>   mtd: nand: pxa3xx: add raw read support
>   mtd: nand: pxa3xx: re-read a page in raw mode on uncorrectable error
>   mtd: rawnand: pxa3xx: fix 2kiB pages with 8b strength chips layout

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

Re: [U-Boot] [PATCH] ARM: mvebu: dts: add Clearfog GT-8K

[Stefan Roese]

Hi Baruch,

On 22.10.18 21:59, Chris Packham wrote:



On Fri, 19 Oct 2018, 12:55 AM Baruch Siach, mailto:bar...@tkos.co.il>> wrote:

From: Rabeeh Khoury mailto:rab...@solid-run.com>>

The SolidRun Clearfog GT-8K is based on Armada 8040.

https://wiki.solid-run.com/doku.php?id=products:a8040:clearfoggt8k

Signed-off-by: Rabeeh Khoury mailto:rab...@solid-run.com>>
Signed-off-by: Baruch Siach mailto:bar...@tkos.co.il>>
---
  arch/arm/dts/Makefile                       |   1 +
  arch/arm/dts/armada-8040-clearfog-gt-8k.dts | 315 
  2 files changed, 316 insertions(+)
  create mode 100644 arch/arm/dts/armada-8040-clearfog-gt-8k.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 44ebc50bfab1..c9a23ea68450 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -99,6 +99,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=                   \
         armada-7040-db-nand.dtb                 \
         armada-8040-db.dtb                      \
         armada-8040-mcbin.dtb                   \
+       armada-8040-clearfog-gt-8k.dtb          \
         armada-xp-gp.dtb                        \
         armada-xp-maxbcm.dtb                    \
         armada-xp-synology-ds414.dtb            \
diff --git a/arch/arm/dts/armada-8040-clearfog-gt-8k.dts 
b/arch/arm/dts/armada-8040-clearfog-gt-8k.dts
new file mode 100644
index ..015ef35b0d81
--- /dev/null
+++ b/arch/arm/dts/armada-8040-clearfog-gt-8k.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 SolidRun ltd
+ */
+
+#include "armada-8040.dtsi"
+
+/ {
+       model = "ClearFog-GT-8K";
+       compatible = "solidrun,armada8040-cf-gt-8k",
+                    "marvell,armada8040";
+
+       chosen {
+               stdout-path = "serial0:115200n8";
+       };
+
+       aliases {
+               i2c0 = _i2c0;
+               i2c1 = _i2c1;
+               spi0 = _spi1;
+       };
+
+       memory@ {
+               device_type = "memory";
+               reg = <0x0 0x0 0x0 0x8000>;
+       };
+
+       simple-bus {
+               compatible = "simple-bus";
+
+               reg_usb3h0_vbus: usb3-vbus0 {
+                       compatible = "regulator-fixed";
+                       pinctrl-names = "default";
+                       pinctrl-0 = <_xhci_vbus_pins>;
+                       regulator-name = "reg-usb3h0-vbus";
+                       regulator-min-microvolt = <500>;
+                       regulator-max-microvolt = <500>;
+                       startup-delay-us = <30>;
+                       shutdown-delay-us = <50>;
+                       regulator-force-boot-off;
+                       gpio = <_gpio1 15 GPIO_ACTIVE_LOW>; /* GPIO[47] 
*/
+               };
+       };
+};
+
+ {
+       status = "okay";
+};
+
+_pinctl {
+       /*
+        * MPP Bus:
+        * eMMC [0-10]
+        * UART0 [11,19]
+        */
+                 /* 0 1 2 3 4 5 6 7 8 9 */
+       pin-func = < 1 1 1 1 1 1 1 1 1 1
+                    1 3 0 0 0 0 0 0 0 3 >;
+};
+
+/* on-board eMMC */
+_sdhci0 {
+       pinctrl-names = "default";
+       pinctrl-0 = <_emmc_pins>;
+       bus-width = <8>;
+       status = "okay";
+};
+
+_pinctl {
+       /*
+        * MPP Bus:
+        * [0-31] = 0xff: Keep default CP0_shared_pins:
+        * [11] CLKOUT_MPP_11 (out)
+        * [23] LINK_RD_IN_CP2CP (in)
+        * [25] CLKOUT_MPP_25 (out)
+        * [29] AVS_FB_IN_CP2CP (in)
+        * [32, 33, 34] pci0/1/2 reset
+        * [35-38] CP0 I2C1 and I2C0
+        * [39] GPIO reset button
+        * [40,41] LED0 and LED1
+        * [43] 1512 phy reset
+        * [47] USB VBUS EN (active low)
+        * [48] FAN PWM
+        * [49] SFP+ present signal
+        * [50] TPM interrupt
+        * [51] WLAN0 disable
+        * [52] WLAN1 disable
+        * [53] LTE disable
+        * [54] NFC reset
+        * [55] Micro SD card detect
+        * [56-61] Micro SD
+        */
+               /*   0    1    2    3    4    5    6    7    8    9 */
+       pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+                    0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+                    0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+                    0xff 0    0    0    0    2    2    2    2    0
+                    0    0    0    0    0    0    0    0    0    0
+                    0    0    0    0    0    0    0xe  0xe  0xe  0xe
+                    0xe  0xe  0 >;
+
+  

[U-Boot] [PATCH v3] net: Add MT76xx ethernet driver

[Stefan Roese]

This patch adds ethernet support for the Mediatek MT76xx SoC, including
a minimum setup of the integrated switch. This driver is loosly based on
the driver version included in this MediaTek github repository:

https://github.com/MediaTek-Labs/linkit-smart-uboot.git

Tested on the MT7688 LinkIt smart-gateway and on the
Gardena-smart-gateway.

Signed-off-by: Stefan Roese 
Reviewed-by: Daniel Schwierzeck 
Cc: Joe Hershberger 
---
v3:
- Add Reviewed-by from Daniel
- Address review comments from Joe:
  - Use more macros / defines instead of magic values, especially
in the MDIO functions
  - Use FIELD_xxx from include/linux/bitfield.h whereever possible
  - Remove some unreferenced defines
  - Remove some unnecessary casts
  - Spelling fixes
  - Add documentation in doc/device-tree-bindings/net/

v2:
- Use wait_for_bit_le32() in more places
- Use syscon / regmap to access the system-controller registers
  needed in this driver instead of finding and mapping this
  area
  
 .../net/mediatek,mt76xx-eth.txt   |  17 +
 drivers/net/Kconfig   |   7 +
 drivers/net/Makefile  |   1 +
 drivers/net/mt76xx-eth.c  | 635 ++
 4 files changed, 660 insertions(+)
 create mode 100644 doc/device-tree-bindings/net/mediatek,mt76xx-eth.txt
 create mode 100644 drivers/net/mt76xx-eth.c

diff --git a/doc/device-tree-bindings/net/mediatek,mt76xx-eth.txt 
b/doc/device-tree-bindings/net/mediatek,mt76xx-eth.txt
new file mode 100644
index 00..db035c99d4
--- /dev/null
+++ b/doc/device-tree-bindings/net/mediatek,mt76xx-eth.txt
@@ -0,0 +1,17 @@
+* MediaTek Frame Engine Ethernet controller
+
+Required properties:
+- compatible: should be "mediatek,mt7622-eth"
+- reg: address and length of the register set for the frame
+   engine ethernet controller and the internal switch.
+- syscon: phandle to the system controller
+
+Example:
+
+eth@1010 {
+   compatible = "mediatek,mt7622-eth";
+   reg = <0x1010 0x1
+  0x1011 0x8000>;
+
+   syscon = <>;
+};
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f1f0e2d94e..d3ed1c2857 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -227,6 +227,13 @@ config MACB_ZYNQ
  The Cadence MACB ethernet interface was used on Zynq platform.
  Say Y to enable support for the MACB/GEM in Zynq chip.
 
+config MT76XX_ETH
+   bool "MediaTek MT76xx Ethernet Interface"
+   depends on ARCH_MT7620
+   help
+ The MediaTek MT76xx ethernet interface is used on MT7688
+ based boards.
+
 config PCH_GBE
bool "Intel Platform Controller Hub EG20T GMAC driver"
depends on DM_ETH && DM_PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 48a2878071..05189514b7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_LPC32XX_ETH) += lpc32xx_eth.o
 obj-$(CONFIG_MACB) += macb.o
 obj-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
 obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
+obj-$(CONFIG_MT76XX_ETH) += mt76xx-eth.o
 obj-$(CONFIG_MVGBE) += mvgbe.o
 obj-$(CONFIG_MVNETA) += mvneta.o
 obj-$(CONFIG_MVPP2) += mvpp2.o
diff --git a/drivers/net/mt76xx-eth.c b/drivers/net/mt76xx-eth.c
new file mode 100644
index 00..e6fa803d97
--- /dev/null
+++ b/drivers/net/mt76xx-eth.c
@@ -0,0 +1,635 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * MediaTek ethernet IP driver for U-Boot
+ *
+ * Copyright (C) 2018 Stefan Roese 
+ *
+ * This code is mostly based on the code extracted from this MediaTek
+ * github repository:
+ *
+ * https://github.com/MediaTek-Labs/linkit-smart-uboot.git
+ *
+ * I was not able to find a specific license or other developers
+ * copyrights here, so I can't add them here.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* System controller register */
+#define MT76XX_RSTCTRL_REG 0x34
+#define RSTCTRL_EPHY_RST   BIT(24)
+
+#define MT76XX_AGPIO_CFG_REG   0x3c
+#define MT7628_EPHY_GPIO_AIO_ENGENMASK(20, 17)
+#define MT7628_EPHY_P0_DIS BIT(16)
+
+#define MT76XX_GPIO2_MODE_REG  0x64
+
+/* Ethernet frame engine register */
+#define PDMA_RELATED   0x0800
+
+#define TX_BASE_PTR0   (PDMA_RELATED + 0x000)
+#define TX_MAX_CNT0(PDMA_RELATED + 0x004)
+#define TX_CTX_IDX0(PDMA_RELATED + 0x008)
+#define TX_DTX_IDX0(PDMA_RELATED + 0x00c)
+
+#define RX_BASE_PTR0   (PDMA_RELATED + 0x100)
+#define RX_MAX_CNT0(PDMA_RELATED + 0x104)
+#define RX_CALC_IDX0   (PDMA_RELATED + 0x108)
+
+#define PDMA_GLO_CFG   (PDMA_RELATED + 0x204)
+#define PDMA_RST_IDX   (PDMA_RELATED + 0x208)
+#define DLY_INT_CFG(PDMA_RELATED + 0x20c)
+
+#define SDM_RELATED0x0c00
+
+#define SDM_MAC_ADRL   (SDM_RELATED + 0x0c)/* MAC address LSB */
+#define SDM_MAC_ADRH   (SDM_RELATED + 

Re: [U-Boot] [PATCH] configs: sama5d2_ptc_ek: read environment from FAT

[Eugen.Hristev]

On 23.10.2018 11:13, andrei.stefane...@microchip.com wrote:
> On our demo setup for SD card boot, the u-boot environment
> is in a FAT partition.
> 
> This patch changes the default configuration, specifing that
> the u-boot environment is in a FAT partition instead of raw MMC.
> 
> Signed-off-by: Andrei Stefanescu 
Acked-by: Eugen Hristev 

> ---
>   configs/sama5d2_ptc_ek_mmc_defconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/sama5d2_ptc_ek_mmc_defconfig 
> b/configs/sama5d2_ptc_ek_mmc_defconfig
> index c378465..83d3fb6 100644
> --- a/configs/sama5d2_ptc_ek_mmc_defconfig
> +++ b/configs/sama5d2_ptc_ek_mmc_defconfig
> @@ -30,7 +30,7 @@ CONFIG_CMD_PING=y
>   CONFIG_CMD_EXT4=y
>   CONFIG_CMD_FAT=y
>   CONFIG_OF_CONTROL=y
> -CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ENV_IS_IN_FAT=y
>   CONFIG_DM=y
>   CONFIG_SPL_DM_SEQ_ALIAS=y
>   CONFIG_CLK=y
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mvebu: Move PCI(e) MBUS window to end of RAM

[Владислав]

I checked this patch, and seems to work for me on clearfog base and silicon 
motion pcie video card



Stefan Roese  22 октября 2018 г. 15:21:20 написал:


With patch 49b23e035d96 (pci: mvebu: Increase size of PCIe default mapping)
the mapping size for each PCI(e) controller was increased from 32MiB to
128MiB. This leads to problems on boards with multiple PCIe slots / ports
which are unable to map all PCIe ports, e.g. the Armada-XP theadorable:

DRAM:  2 GiB (667 MHz, 64-bit, ECC not enabled)
SF: Detected m25p128 with page size 256 Bytes, erase size 256 KiB, total 16 MiB
Cannot add window '4:f8', conflicts with another window
PCIe unable to add mbus window for mem at f000+0800
Model: Marvell Armada XP theadorable

This patch moves the base address for the PCI(e) memory spaces from
0xe800 to the end of SDRAM (clipped to a max of 0xc000 right now).
This gives move room and flexibility for PCI(e) mappings.

Signed-off-by: Stefan Roese 
Cc: VlaoMao 
---
 arch/arm/mach-mvebu/dram.c | 8 +++-
 arch/arm/mach-mvebu/include/mach/cpu.h | 4 +++-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/dram.c b/arch/arm/mach-mvebu/dram.c
index 68383d06a2..b5671b8c20 100644
--- a/arch/arm/mach-mvebu/dram.c
+++ b/arch/arm/mach-mvebu/dram.c
@@ -33,8 +33,6 @@ struct sdram_addr_dec {
 #define REG_CPUCS_WIN_WIN0_CS(x)   (((x) & 0x3) << 2)
 #define REG_CPUCS_WIN_SIZE(x)  (((x) & 0xff) << 24)

-#define SDRAM_SIZE_MAX 0xc000
-
 #define SCRUB_MAGIC0xbeefdead

 #define SCRB_XOR_UNIT  0
@@ -275,8 +273,8 @@ int dram_init(void)
 * address space left for the internal registers etc.
 */
size += mvebu_sdram_bs(i);
-   if (size > SDRAM_SIZE_MAX)
-   size = SDRAM_SIZE_MAX;
+   if (size > MVEBU_SDRAM_SIZE_MAX)
+   size = MVEBU_SDRAM_SIZE_MAX;
}

for (; i < CONFIG_NR_DRAM_BANKS; i++) {
@@ -312,7 +310,7 @@ int dram_init_banksize(void)

/* Clip the banksize to 1GiB if it exceeds the max size */
size += gd->bd->bi_dram[i].size;
-   if (size > SDRAM_SIZE_MAX)
+   if (size > MVEBU_SDRAM_SIZE_MAX)
mvebu_sdram_bs_set(i, 0x4000);
}

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h

index d1042100a8..85d7dd1610 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -68,10 +68,12 @@ enum {
MVEBU_SOC_UNKNOWN,
 };

+#define MVEBU_SDRAM_SIZE_MAX   0xc000
+
 /*
  * Default Device Address MAP BAR values
  */
-#define MBUS_PCI_MEM_BASE  0xE800
+#define MBUS_PCI_MEM_BASE  MVEBU_SDRAM_SIZE_MAX
 #define MBUS_PCI_MEM_SIZE  (128 << 20)
 #define MBUS_PCI_IO_BASE   0xF110
 #define MBUS_PCI_IO_SIZE   (64 << 10)
--
2.19.1




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

[U-Boot] [PATCH v2 1/1] common: Compile error with CONFIG_MULTI_DTB_FIT and not SPL

[Lars Povlsen]

common/common_fit.c is including , but not actually using it. The
inclusion will cuase compile error on platforms using CONFIG_OF_SEPARATE
and not SPL.

Signed-off-by: Lars Povlsen 
---
 common/common_fit.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/common/common_fit.c b/common/common_fit.c
index 577b352..a35c7e9 100644
--- a/common/common_fit.c
+++ b/common/common_fit.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 
 ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
 {
-- 
2.7.4

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

Re: [U-Boot] Compile error with CONFIG_MULTI_DTB_FIT and not SPL

[Lars.Povlsen]

...
> I believe that spl.h is not needed at all here. It should be removed JJ

Thanks for the feedback, I have sent a new patch to that effect.

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

[U-Boot] [PATCH] configs: sama5d2_ptc_ek: read environment from FAT

[Andrei.Stefanescu]

On our demo setup for SD card boot, the u-boot environment
is in a FAT partition.

This patch changes the default configuration, specifing that
the u-boot environment is in a FAT partition instead of raw MMC.

Signed-off-by: Andrei Stefanescu 
---
 configs/sama5d2_ptc_ek_mmc_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/sama5d2_ptc_ek_mmc_defconfig 
b/configs/sama5d2_ptc_ek_mmc_defconfig
index c378465..83d3fb6 100644
--- a/configs/sama5d2_ptc_ek_mmc_defconfig
+++ b/configs/sama5d2_ptc_ek_mmc_defconfig
@@ -30,7 +30,7 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_IN_FAT=y
 CONFIG_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_CLK=y
-- 
2.7.4

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

[U-Boot] [PATCH v2] ARM: Samsung: Add Exynos5422-based Odroid HC2 support

[Dirk Meul]

From: Dirk Meul 
Date: Sun, 14 Oct 2018 17:14:17 +0200

Odroid HC2 board is based on Odroid XU4 board, like the Odroid HC1.

The linux kernel does not provide a hc2 DTB so the hc1 DTB is also used
for the Odroid HC2.

Resend because MUA changed whitespace.

Signed-off-by: Dirk Meul 
Acked-by: Marek Szyprowski 
Reviewed-by: Lukasz Majewski 
---
 board/samsung/common/exynos5-dt-types.c | 16 +---
 board/samsung/common/exynos5-dt.c   |  4 ++--
 configs/odroid-xu3_defconfig|  2 +-
 include/samsung/exynos5-dt-types.h  |  2 ++
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
index 4473968db6..7a86e91877 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -24,14 +24,15 @@ static const struct udevice_id board_ids[] = {
 };
 
 /**
- * Odroix XU3/XU4/HC1 board revisions (from HC1_MAIN_REV0.1_20170630.pdf):
+ * Odroix XU3/XU4/HC1/HC2 board revisions (from 
HC1+_HC2_MAIN_REV0.1_20171017.pdf):
  * Rev   ADCmax  Board
  * 0.1 0 XU3 0.1
  * 0.2   372 XU3 0.2 | XU3L - no DISPLAYPORT (probe I2C0:0x40 / INA231)
  * 0.3  1280 XU4 0.1
  * 0.4   739 XU4 0.2
  * 0.5  1016 XU4+Air0.1 (Passive cooling)
- * 0.6  1308 XU4S 0.1 (HC1)
+ * 0.6  1309 XU4-HC1 0.1
+ * 0.7  1470 XU4-HC1+ 0.1 (HC2)
  * Use +1% for ADC value tolerance in the array below, the code loops until
  * the measured ADC value is lower than then ADCmax from the array.
  */
@@ -39,7 +40,8 @@ struct odroid_rev_info odroid_info[] = {
{ EXYNOS5_BOARD_ODROID_XU3_REV01, 1, 10, "xu3" },
{ EXYNOS5_BOARD_ODROID_XU3_REV02, 2, 375, "xu3" },
{ EXYNOS5_BOARD_ODROID_XU4_REV01, 1, 1293, "xu4" },
-   { EXYNOS5_BOARD_ODROID_HC1_REV01, 1, 1321, "hc1" },
+   { EXYNOS5_BOARD_ODROID_HC1_REV01, 1, 1322, "hc1" },
+   { EXYNOS5_BOARD_ODROID_HC2_REV01, 1, 1484, "hc1" },
{ EXYNOS5_BOARD_ODROID_UNKNOWN, 0, 4095, "unknown" },
 };
 
@@ -144,6 +146,14 @@ bool board_is_odroidhc1(void)
return false;
 }
 
+bool board_is_odroidhc2(void)
+{
+   if (gd->board_type == EXYNOS5_BOARD_ODROID_HC2_REV01)
+   return true;
+
+   return false;
+}
+
 bool board_is_generic(void)
 {
if (gd->board_type == EXYNOS5_BOARD_GENERIC)
diff --git a/board/samsung/common/exynos5-dt.c 
b/board/samsung/common/exynos5-dt.c
index 8c3a9ea564..c183965b92 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -179,7 +179,7 @@ char *get_dfu_alt_system(char *interface, char *devstr)
 {
char *info = "Not supported!";
 
-   if (board_is_odroidxu4() || board_is_odroidhc1())
+   if (board_is_odroidxu4() || board_is_odroidhc1() || 
board_is_odroidhc2())
return info;
 
return env_get("dfu_alt_system");
@@ -192,7 +192,7 @@ char *get_dfu_alt_boot(char *interface, char *devstr)
char *alt_boot;
int dev_num;
 
-   if (board_is_odroidxu4() || board_is_odroidhc1())
+   if (board_is_odroidxu4() || board_is_odroidhc1() || 
board_is_odroidhc2())
return info;
 
dev_num = simple_strtoul(devstr, NULL, 10);
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index 258b9781cc..d5c7cc7129 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_SYS_TEXT_BASE=0x43E0
 CONFIG_ARCH_EXYNOS5=y
-CONFIG_IDENT_STRING=" for ODROID-XU3/XU4/HC1"
+CONFIG_IDENT_STRING=" for ODROID-XU3/XU4/HC1/HC2"
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=8
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/include/samsung/exynos5-dt-types.h 
b/include/samsung/exynos5-dt-types.h
index 8e11af30d1..8fe08fe211 100644
--- a/include/samsung/exynos5-dt-types.h
+++ b/include/samsung/exynos5-dt-types.h
@@ -9,6 +9,7 @@ enum {
EXYNOS5_BOARD_ODROID_XU3_REV02,
EXYNOS5_BOARD_ODROID_XU4_REV01,
EXYNOS5_BOARD_ODROID_HC1_REV01,
+   EXYNOS5_BOARD_ODROID_HC2_REV01,
EXYNOS5_BOARD_ODROID_UNKNOWN,
 
EXYNOS5_BOARD_COUNT,
@@ -25,5 +26,6 @@ bool board_is_generic(void);
 bool board_is_odroidxu3(void);
 bool board_is_odroidxu4(void);
 bool board_is_odroidhc1(void);
+bool board_is_odroidhc2(void);
 
 #endif
-- 
2.17.2

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

[U-Boot] [PATCH 2/2] arm: mvebu: armada-xp-theadorable.dts: Change CS# for 2nd FPGA

[Stefan Roese]

The new board version has the 2nd FPGA connected via CS# 0 instead of
2 on SPI bus 1. Change this setup in the DT accordingly. Please note
that this change does still work on the old board version because the
CS signal is not used on this board.

Signed-off-by: Stefan Roese 
---
 arch/arm/dts/armada-xp-theadorable.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/armada-xp-theadorable.dts 
b/arch/arm/dts/armada-xp-theadorable.dts
index 065e443417..965c38426c 100644
--- a/arch/arm/dts/armada-xp-theadorable.dts
+++ b/arch/arm/dts/armada-xp-theadorable.dts
@@ -151,11 +151,11 @@
spi1: spi@10680 {
status = "okay";
 
-   fpga@2 {
+   fpga@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spi-generic-device";
-   reg = <2>; /* Chip select 2 */
+   reg = <0>; /* Chip select 0 */
spi-max-frequency = <2777>;
};
};
-- 
2.19.1

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

[U-Boot] [PATCH 1/2] arm: mvebu: armada-xp-theadorable.dts: Add "spi-flash" compatible property

[Stefan Roese]

Add the "spi-flash" compatible string so that the generic sf_probe
driver can probe the SPI flash on the theadorable Armada-XP board.

Signed-off-by: Stefan Roese 
---
 arch/arm/dts/armada-xp-theadorable.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/armada-xp-theadorable.dts 
b/arch/arm/dts/armada-xp-theadorable.dts
index 7087ccfc2f..065e443417 100644
--- a/arch/arm/dts/armada-xp-theadorable.dts
+++ b/arch/arm/dts/armada-xp-theadorable.dts
@@ -134,7 +134,7 @@
u-boot,dm-pre-reloc;
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "n25q128a13", 
"jedec,spi-nor";
+   compatible = "n25q128a13", 
"jedec,spi-nor", "spi-flash";
reg = <0>; /* Chip select 0 */
spi-max-frequency = <2777>;
};
-- 
2.19.1

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

Re: [U-Boot] [PATCH] arm: mvebu: Move PCI(e) MBUS window to end of RAM

[Stefan Roese]

On 23.10.18 12:19, Владислав wrote:

I checked this patch, and seems to work for me on clearfog base and silicon
motion pcie video card


Thats good, thanks for checking. Could you please send a
proper git "Tested-by" tag then?

Thanks,
Stefan
 


Stefan Roese  22 октября 2018 г. 15:21:20 написал:


With patch 49b23e035d96 (pci: mvebu: Increase size of PCIe default mapping)
the mapping size for each PCI(e) controller was increased from 32MiB to
128MiB. This leads to problems on boards with multiple PCIe slots / ports
which are unable to map all PCIe ports, e.g. the Armada-XP theadorable:

DRAM:  2 GiB (667 MHz, 64-bit, ECC not enabled)
SF: Detected m25p128 with page size 256 Bytes, erase size 256 KiB, total 16 MiB
Cannot add window '4:f8', conflicts with another window
PCIe unable to add mbus window for mem at f000+0800
Model: Marvell Armada XP theadorable

This patch moves the base address for the PCI(e) memory spaces from
0xe800 to the end of SDRAM (clipped to a max of 0xc000 right now).
This gives move room and flexibility for PCI(e) mappings.

Signed-off-by: Stefan Roese 
Cc: VlaoMao 
---
  arch/arm/mach-mvebu/dram.c | 8 +++-
  arch/arm/mach-mvebu/include/mach/cpu.h | 4 +++-
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/dram.c b/arch/arm/mach-mvebu/dram.c
index 68383d06a2..b5671b8c20 100644
--- a/arch/arm/mach-mvebu/dram.c
+++ b/arch/arm/mach-mvebu/dram.c
@@ -33,8 +33,6 @@ struct sdram_addr_dec {
  #define REG_CPUCS_WIN_WIN0_CS(x)  (((x) & 0x3) << 2)
  #define REG_CPUCS_WIN_SIZE(x) (((x) & 0xff) << 24)

-#define SDRAM_SIZE_MAX 0xc000
-
  #define SCRUB_MAGIC   0xbeefdead

  #define SCRB_XOR_UNIT 0
@@ -275,8 +273,8 @@ int dram_init(void)
 * address space left for the internal registers etc.
 */
size += mvebu_sdram_bs(i);
-   if (size > SDRAM_SIZE_MAX)
-   size = SDRAM_SIZE_MAX;
+   if (size > MVEBU_SDRAM_SIZE_MAX)
+   size = MVEBU_SDRAM_SIZE_MAX;
}

for (; i < CONFIG_NR_DRAM_BANKS; i++) {
@@ -312,7 +310,7 @@ int dram_init_banksize(void)

/* Clip the banksize to 1GiB if it exceeds the max size */
size += gd->bd->bi_dram[i].size;
-   if (size > SDRAM_SIZE_MAX)
+   if (size > MVEBU_SDRAM_SIZE_MAX)
mvebu_sdram_bs_set(i, 0x4000);
}

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index d1042100a8..85d7dd1610 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -68,10 +68,12 @@ enum {
MVEBU_SOC_UNKNOWN,
  };

+#define MVEBU_SDRAM_SIZE_MAX   0xc000
+
  /*
   * Default Device Address MAP BAR values
   */
-#define MBUS_PCI_MEM_BASE  0xE800
+#define MBUS_PCI_MEM_BASE  MVEBU_SDRAM_SIZE_MAX
  #define MBUS_PCI_MEM_SIZE (128 << 20)
  #define MBUS_PCI_IO_BASE  0xF110
  #define MBUS_PCI_IO_SIZE  (64 << 10)
--
2.19.1






Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] socfpga cyclone5 dts

[Stefan Roese]

On 23.10.18 10:41, Marek Vasut wrote:

On 10/22/2018 10:48 PM, Simon Goldschmidt wrote:

On 18.10.2018 23:04, Marek Vasut wrote:

On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:


Marek Vasut mailto:marek.va...@gmail.com>>
schrieb am Do., 18. Okt. 2018, 22:15:

  On 10/18/2018 09:28 PM, Simon Goldschmidt wrote:
  > Hi Marek,

  Hi,

  > I was playing with updating the dts files for cyclone5 (and
  arria5) from
  > current kernel sources, but I found that the kernel as 4
boards that
  > U-Boot doesn't have and U-Boot has 6 boards that the kernel
  doesn't have.

  Thanks for doing this, really appreciated (even though it probably
  doesn't look that way most of the time).

  And yikes, which boards are where , can you list the problematic
ones?

  > How should I proceed here? Should I copy new boards from the
kernel?
  > Should I keep U-Boot-only boards and try to adjust them to
changes (if
  > any)?

  I'd say sync as much as possible with kernel and the rest,
update. I
  don't think there are any real board specific things which would
prevent
  the update in those DTs missing in the kernel.


Ok, I'll just try and prepare a patch that ports the existing boards and
mentions the boards not ported from current kernel sources. I don't want
to remove boards from U-Boot, so we'll just have to test those not in
Linux.

Sounds good!


After a short test run, I decided to first ask for the boards before
preparing a patch:

Boards in U-Boot but not in Linux (not updated):
- socfpga_cyclone5_dbm_soc1.dts


Hum, I should upstream that one.


- socfpga_cyclone5_de0_nano_soc.dts (is this
'socfpga_cyclone5_de0_sockit.dts'?)


There is no de0-sockit. There is de0-nano-soc and there is sockit ,
these are two different boards.


- socfpga_cyclone5_de1_soc.dts
- socfpga_cyclone5_de10_nano.dts


These should be upstream.


- socfpga_cyclone5_is1.dts
- socfpga_cyclone5_sr1500.dts


CCing Stefan.


Thanks. Simon, It would be great, if you could update those 2 dts
files.

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

Re: [U-Boot] [PATCH 20/30] riscv: align mtvec on a 4-byte boundary

[Bin Meng]

On Tue, Oct 23, 2018 at 5:17 PM Rick Chen  wrote:
>
>  於 2018年10月23日 週二 下午4:41寫道：
> >
> > > Hi Lukas,
> > >
> > > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer 
> > > 
> > > wrote:
> > > >
> > > > The machine trap-vector base address (mtvec) must be aligned on a
> > > > 4-byte boundary. Add the necessary align directive to trap_entry.
> > > >
> > >
> > > I don't think this explicit alignment is needed because the instructions 
> > > before
> > > trap_entry are already on 4-byte boundary.
> > >
>
> Hi, Lukas and Bin
>
> I think .aling 2 is necessary.
>
> trap_entry is 4 -byte aligned now.
> But if someone add some codes ahead of trap_entry.
> trap_entry may still have chance to become NOT 4 byte aligned.
> With this prevention will be more safety than without it.
>
> Linux Kernel have a patch to prevent from stvec not 4 byte aligned.
>

OK, then

Reviewed-by: Bin Meng 

> commit 94f592f0e5b9c17a7505119a2d6c0f1f529ae93d
> Author: Zong Li 
> Date:   Thu Aug 2 23:21:56 2018 +0800
>
> RISC-V: Add the directive for alignment of stvec's value
>
> The stvec's value must be 4 byte alignment by specification definition.
> These directives avoid to stvec be set the non-alignment value.
>
> Signed-off-by: Zong Li 
> Signed-off-by: Palmer Dabbelt 

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

Re: [U-Boot] [PATCH 20/30] riscv: align mtvec on a 4-byte boundary

[Rick Chen]

 於 2018年10月23日 週二 下午4:41寫道：
>
> > Hi Lukas,
> >
> > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer 
> > wrote:
> > >
> > > The machine trap-vector base address (mtvec) must be aligned on a
> > > 4-byte boundary. Add the necessary align directive to trap_entry.
> > >
> >
> > I don't think this explicit alignment is needed because the instructions 
> > before
> > trap_entry are already on 4-byte boundary.
> >

Hi, Lukas and Bin

I think .aling 2 is necessary.

trap_entry is 4 -byte aligned now.
But if someone add some codes ahead of trap_entry.
trap_entry may still have chance to become NOT 4 byte aligned.
With this prevention will be more safety than without it.

Linux Kernel have a patch to prevent from stvec not 4 byte aligned.

commit 94f592f0e5b9c17a7505119a2d6c0f1f529ae93d
Author: Zong Li 
Date:   Thu Aug 2 23:21:56 2018 +0800

RISC-V: Add the directive for alignment of stvec's value

The stvec's value must be 4 byte alignment by specification definition.
These directives avoid to stvec be set the non-alignment value.

Signed-off-by: Zong Li 
Signed-off-by: Palmer Dabbelt 


Rick

> > > This patch also removes the global directive for trap_entry, which is
> > > not required.
> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > >  arch/riscv/cpu/start.S | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> >
> > Regards,
> > Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] serial: ns16550: fix debug uart putc called before init

[Simon Goldschmidt]

On Tue, Oct 23, 2018 at 11:01 AM Marek Vasut  wrote:
>
> On 10/19/2018 05:25 AM, Simon Glass wrote:
> > On 9 August 2018 at 13:04, Simon Goldschmidt
> >  wrote:
> >> If _debug_uart_putc() is called before _debug_uart_init(), the
> >> ns16550 debug uart driver hangs in a tight loop waiting for the
> >> tx FIFO to get empty.
> >>
> >> As this can happen via a printf sneaking in before the port calls
> >> debug_uart_init(), let's rather ignore characters before the debug
> >> uart is initialized.
> >>
> >> This is done by reading the baudrate divisor and aborting if is zero.
> >>
> >> Tested on socfpga_cyclone5_socrates.
> >>
> >> Signed-off-by: Simon Goldschmidt 
> >> ---
> >> v2:
> >>  - this patch is new in v2 of the series. It replaces the printf/debug
> >>   change in reset_manager_gen5.c from v1
> >>
> >>  drivers/serial/ns16550.c | 18 --
> >>  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > We cannot use global_data before it is set up, so I think this is the
> > best solution.
> >
> > Acked-by: Simon Glass 
>
> So there's no GD available when using debug uart ? Hum.
>
> btw. Does the NS16550_read_baud_divisor() need to be called within the
> while loop ?

No. I just decided to put it there so that it is not executed unless
we wait in a tight loop anyway.
So if the transmit buffer is empty, code flow is unchanged by this
patch. Only if it is not empty, the baud divisor is read. But in this
case, we would cycle the while loop a few hundred times, anyway, I
guess...


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

Re: [U-Boot] latest kwboot

[Chris Packham]

On Tue, 23 Oct 2018, 10:00 PM Balanga Bar,  wrote:

> Thanks for the suggestion.
>
> I'm not very experienced with git
>
> How would I 'git checkout v2013.02 tools/kwboot.c' ?
>

Clone the u-boot repo with

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

Go back to an older version with

git checkout v2013.02

(or any other tag you wish to have a look at)

Have a look at git-scm.com for more info on using git.

That all being said you haven't actually said what is stopping the current
version of kwboot.c from working for you.


> On Tue, Oct 23, 2018 at 2:18 AM Chris Packham 
> wrote:
>
>>
>>
>> On Tue, 23 Oct 2018, 10:33 AM Balanga Bar,  wrote:
>>
>>> I'm trying to build kwboot on FreeBSD but the latest source I found is
>>> not
>>> posix compliant, containing various Linuxisms... I did find an old
>>> version
>>> here
>>
>>
>>> https://github.com/LeMaker/u-boot/raw/master/tools/kwboot.c
>>>
>>> that I was able to compile. Is there anything newer?
>>>
>>
>> You can just obtain older versions from the u-boot source (e.g git
>> checkout v2013.02 tools/kwboot.c).
>>
>>
>>> Alternatively is anyone aware of a binary which works on FreeBSD?
>>>
>>
>> What linuxisms are problematic for you. Perhaps they can be avoided.
>>
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>>
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types

[Hannes Schmelzer]

On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:

Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.

This type of message has helped to identify code overwriting a relocation
section before relocation and incorrect parsing of relocation tables.

Signed-off-by: Heinrich Schuchardt 
---
  arch/x86/lib/relocate.c | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index ed10755d9c..01e619d20b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base, 
uintptr_t size,
Elf64_Addr *offset_ptr_ram;
  
  	do {

+   unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+
+   if (type != R_X86_64_RELATIVE) {
+   printf("%s: unsupported relocation type 0x%llx "
+  "at %p, ",__func__, type, re_src);
+   printf("offset = 0x%llx\n", re_src->r_offset);
+   continue;
+   }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
  
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size,

Elf32_Addr *offset_ptr_ram;
  
  	do {

+   unsigned int type = ELF32_R_TYPE(re_src->r_info);
+
+   if (type != R_386_RELATIVE) {
+   printf("%s: unsupported relocation type 0x%x "
+  "at %p, ",__func__, type, re_src);
+   printf("offset = 0x%x\n", re_src->r_offset);
+   continue;
+   }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
  

Hi Heinrich,
i just merged recent u-boot master into my devbranch and ran it on my board:

--
U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)

CPU: x86, vendor AMD, device 5a2h
DRAM:  119.6 MiB
do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0, 
offset = 0x287
do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8, 
offset = 0x291

Bus 0: OK
---

now i get such relocation warnings, can you help me in this how to deal 
with that?


I'm starting u-boot as a payload from coreboot.

thanks!

cheers,
Hannes

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

Re: [U-Boot] [PATCH 5/6] serial: ns16550: fix debug uart putc called before init

[Marek Vasut]

On 10/19/2018 05:25 AM, Simon Glass wrote:
> On 9 August 2018 at 13:04, Simon Goldschmidt
>  wrote:
>> If _debug_uart_putc() is called before _debug_uart_init(), the
>> ns16550 debug uart driver hangs in a tight loop waiting for the
>> tx FIFO to get empty.
>>
>> As this can happen via a printf sneaking in before the port calls
>> debug_uart_init(), let's rather ignore characters before the debug
>> uart is initialized.
>>
>> This is done by reading the baudrate divisor and aborting if is zero.
>>
>> Tested on socfpga_cyclone5_socrates.
>>
>> Signed-off-by: Simon Goldschmidt 
>> ---
>> v2:
>>  - this patch is new in v2 of the series. It replaces the printf/debug
>>   change in reset_manager_gen5.c from v1
>>
>>  drivers/serial/ns16550.c | 18 --
>>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> We cannot use global_data before it is set up, so I think this is the
> best solution.
> 
> Acked-by: Simon Glass 

So there's no GD available when using debug uart ? Hum.

btw. Does the NS16550_read_baud_divisor() need to be called within the
while loop ?

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

Re: [U-Boot] socfpga cyclone5 dts

[Marek Vasut]

On 10/23/2018 10:52 AM, Simon Goldschmidt wrote:
[...]

>>> - socfpga_cyclone5_de1_soc.dts
>>> - socfpga_cyclone5_de10_nano.dts
>>
>> These should be upstream.
> 
> But they aren't? Or did you mean "these should be upstreamed"? By whom?

CCing Dinh :-)

[...]
>>> Also, Dinh has enabled the watchdog nearly 4 years ago in
>>> socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or
>>> disable it in the U-Boot specific dts files?
>>
>> Disable it in board files to keep the current behavior.
> 
> Do we enable such things in the "-u-boot.dtsi" "overlay" as well?
> Because when adding it to the dts, we end up having diffs again...

Sounds good!

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

Re: [U-Boot] socfpga cyclone5 dts

[Simon Goldschmidt]

On Tue, Oct 23, 2018 at 10:42 AM Marek Vasut  wrote:
>
> On 10/22/2018 10:48 PM, Simon Goldschmidt wrote:
> > On 18.10.2018 23:04, Marek Vasut wrote:
> >> On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
> >>>
> >>> Marek Vasut mailto:marek.va...@gmail.com>>
> >>> schrieb am Do., 18. Okt. 2018, 22:15:
> >>>
> >>>  On 10/18/2018 09:28 PM, Simon Goldschmidt wrote:
> >>>  > Hi Marek,
> >>>
> >>>  Hi,
> >>>
> >>>  > I was playing with updating the dts files for cyclone5 (and
> >>>  arria5) from
> >>>  > current kernel sources, but I found that the kernel as 4
> >>> boards that
> >>>  > U-Boot doesn't have and U-Boot has 6 boards that the kernel
> >>>  doesn't have.
> >>>
> >>>  Thanks for doing this, really appreciated (even though it probably
> >>>  doesn't look that way most of the time).
> >>>
> >>>  And yikes, which boards are where , can you list the problematic
> >>> ones?
> >>>
> >>>  > How should I proceed here? Should I copy new boards from the
> >>> kernel?
> >>>  > Should I keep U-Boot-only boards and try to adjust them to
> >>> changes (if
> >>>  > any)?
> >>>
> >>>  I'd say sync as much as possible with kernel and the rest,
> >>> update. I
> >>>  don't think there are any real board specific things which would
> >>> prevent
> >>>  the update in those DTs missing in the kernel.
> >>>
> >>>
> >>> Ok, I'll just try and prepare a patch that ports the existing boards and
> >>> mentions the boards not ported from current kernel sources. I don't want
> >>> to remove boards from U-Boot, so we'll just have to test those not in
> >>> Linux.
> >> Sounds good!
> >
> > After a short test run, I decided to first ask for the boards before
> > preparing a patch:
> >
> > Boards in U-Boot but not in Linux (not updated):
> > - socfpga_cyclone5_dbm_soc1.dts
>
> Hum, I should upstream that one.
>
> > - socfpga_cyclone5_de0_nano_soc.dts (is this
> > 'socfpga_cyclone5_de0_sockit.dts'?)
>
> There is no de0-sockit. There is de0-nano-soc and there is sockit ,
> these are two different boards.

Fixed in linux-next, I compared 4.19, see below.

>
> > - socfpga_cyclone5_de1_soc.dts
> > - socfpga_cyclone5_de10_nano.dts
>
> These should be upstream.

But they aren't? Or did you mean "these should be upstreamed"? By whom?

>
> > - socfpga_cyclone5_is1.dts
> > - socfpga_cyclone5_sr1500.dts
>
> CCing Stefan.
>
> > Boards in Linux but not in U-Boot:
> > - socfpga_cyclone5_de0_sockit.dts (is this
> > 'socfpga_cyclone5_de0_nano_soc.dts'?)
>
> Wasn't this removed to de0-nano-soc in next ?

Yes, sorry, I was comparing v4.19, not linux-next. You're right that
this is renamed in linux-next.

>
> > - socfpga_cyclone5_sodia.dts
> >
> > Also, Dinh has enabled the watchdog nearly 4 years ago in
> > socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or
> > disable it in the U-Boot specific dts files?
>
> Disable it in board files to keep the current behavior.

Do we enable such things in the "-u-boot.dtsi" "overlay" as well?
Because when adding it to the dts, we end up having diffs again...


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

Re: [U-Boot] socfpga cyclone5 dts

[Marek Vasut]

On 10/22/2018 09:55 PM, Simon Goldschmidt wrote:
> On 18.10.2018 23:04, Marek Vasut wrote:
>> On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
>>>
>>> Marek Vasut mailto:marek.va...@gmail.com>>
>>> schrieb am Do., 18. Okt. 2018, 22:15:
>>>
>>>  On 10/18/2018 09:28 PM, Simon Goldschmidt wrote:
>>>  > Hi Marek,
>>>
>>>  Hi,
>>>
>>>  > I was playing with updating the dts files for cyclone5 (and
>>>  arria5) from
>>>  > current kernel sources, but I found that the kernel as 4
>>> boards that
>>>  > U-Boot doesn't have and U-Boot has 6 boards that the kernel
>>>  doesn't have.
>>>
>>>  Thanks for doing this, really appreciated (even though it probably
>>>  doesn't look that way most of the time).
>>>
>>>  And yikes, which boards are where , can you list the problematic
>>> ones?
>>>
>>>  > How should I proceed here? Should I copy new boards from the
>>> kernel?
>>>  > Should I keep U-Boot-only boards and try to adjust them to
>>> changes (if
>>>  > any)?
>>>
>>>  I'd say sync as much as possible with kernel and the rest,
>>> update. I
>>>  don't think there are any real board specific things which would
>>> prevent
>>>  the update in those DTs missing in the kernel.
>>>
>>>
>>> Ok, I'll just try and prepare a patch that ports the existing boards and
>>> mentions the boards not ported from current kernel sources. I don't want
>>> to remove boards from U-Boot, so we'll just have to test those not in
>>> Linux.
>> Sounds good!
> 
> What about the license header? Should we keep the original header for
> sync'ed device trees or change it to SPDX?

SPDX please. Even better, fix it in the kernel too :)

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

Re: [U-Boot] socfpga cyclone5 dts

[Marek Vasut]

On 10/22/2018 10:48 PM, Simon Goldschmidt wrote:
> On 18.10.2018 23:04, Marek Vasut wrote:
>> On 10/18/2018 10:20 PM, Simon Goldschmidt wrote:
>>>
>>> Marek Vasut mailto:marek.va...@gmail.com>>
>>> schrieb am Do., 18. Okt. 2018, 22:15:
>>>
>>>  On 10/18/2018 09:28 PM, Simon Goldschmidt wrote:
>>>  > Hi Marek,
>>>
>>>  Hi,
>>>
>>>  > I was playing with updating the dts files for cyclone5 (and
>>>  arria5) from
>>>  > current kernel sources, but I found that the kernel as 4
>>> boards that
>>>  > U-Boot doesn't have and U-Boot has 6 boards that the kernel
>>>  doesn't have.
>>>
>>>  Thanks for doing this, really appreciated (even though it probably
>>>  doesn't look that way most of the time).
>>>
>>>  And yikes, which boards are where , can you list the problematic
>>> ones?
>>>
>>>  > How should I proceed here? Should I copy new boards from the
>>> kernel?
>>>  > Should I keep U-Boot-only boards and try to adjust them to
>>> changes (if
>>>  > any)?
>>>
>>>  I'd say sync as much as possible with kernel and the rest,
>>> update. I
>>>  don't think there are any real board specific things which would
>>> prevent
>>>  the update in those DTs missing in the kernel.
>>>
>>>
>>> Ok, I'll just try and prepare a patch that ports the existing boards and
>>> mentions the boards not ported from current kernel sources. I don't want
>>> to remove boards from U-Boot, so we'll just have to test those not in
>>> Linux.
>> Sounds good!
> 
> After a short test run, I decided to first ask for the boards before
> preparing a patch:
> 
> Boards in U-Boot but not in Linux (not updated):
> - socfpga_cyclone5_dbm_soc1.dts

Hum, I should upstream that one.

> - socfpga_cyclone5_de0_nano_soc.dts (is this
> 'socfpga_cyclone5_de0_sockit.dts'?)

There is no de0-sockit. There is de0-nano-soc and there is sockit ,
these are two different boards.

> - socfpga_cyclone5_de1_soc.dts
> - socfpga_cyclone5_de10_nano.dts

These should be upstream.

> - socfpga_cyclone5_is1.dts
> - socfpga_cyclone5_sr1500.dts

CCing Stefan.

> Boards in Linux but not in U-Boot:
> - socfpga_cyclone5_de0_sockit.dts (is this
> 'socfpga_cyclone5_de0_nano_soc.dts'?)

Wasn't this removed to de0-nano-soc in next ?

> - socfpga_cyclone5_sodia.dts
> 
> Also, Dinh has enabled the watchdog nearly 4 years ago in
> socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or
> disable it in the U-Boot specific dts files?

Disable it in board files to keep the current behavior.

> Thanks,
> Simon


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

Re: [U-Boot] [PATCH] w1: fix build without CONFIG_W1_EEPROM

[Eugen.Hristev]

On 23.10.2018 11:31, Martin Fuzzey wrote:
> On 23/10/18 09:07, eugen.hris...@microchip.com wrote:
>>
>> On 22.10.2018 19:51, Martin Fuzzey wrote:
>>> Building with CONFIG_W1 and CONFIG_CMD_W1 but without CONFIG_W1_EEPROM
>>> fails with
>>> drivers/w1/w1-uclass.c:104: undefined reference to 
>>> `w1_eeprom_register_new_device'
>>> cmd/w1.c:93: undefined reference to `w1_eeprom_read_buf'
>>>
>>> Fix this.
>> I would prefer if you let the w1 read command to be accessible
>> regardless if CONFIG_W1_EEPROM is defined or not. Hence have only the w1
>> eeprom reads under the ifdef...
>> The w1_read checks for devices anyway and for the bus, so it should
>> print invalid bus/device if nothing is present there.
>> Any opinion on this ?
> 
> I don't really have a strong opinion on this.
> 
> Completely removing non implemented commands seems to be a common thing 
> to do in u-boot (cmd/i2c.c for instance) presumably to keep the image 
> size as small as possible.
> But for the one wire case the code space saving is likely to be small 
> and, currently at least, there is little point buiding without 
> CONFIG_W1_EEPROM, not sure if that will change some day - of course 
> there are other types of one wire devices like various sensors but they 
> are probably of less interest in the context of a bootloader.
> 
> Let's wait a bit and see what Maxime or anyone else has to say about this.

I tried as much as possible to decouple the W1 bus from the W1 EEPROM 
memories. It is possible that we will have a different framework for 
EEPROMs that will include both 1wire and i2c eeproms, and then the 
interfacing would be pretty easy to change to.

That's why I am thinking that w1 bus read should not be much affected if 
the 1w EEPROMs are unknown to U-boot

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

Re: [U-Boot] [PATCH] w1: fix build without CONFIG_W1_EEPROM

[Martin Fuzzey]

On 23/10/18 09:07, eugen.hris...@microchip.com wrote:


On 22.10.2018 19:51, Martin Fuzzey wrote:

Building with CONFIG_W1 and CONFIG_CMD_W1 but without CONFIG_W1_EEPROM
fails with
drivers/w1/w1-uclass.c:104: undefined reference to 
`w1_eeprom_register_new_device'
cmd/w1.c:93: undefined reference to `w1_eeprom_read_buf'

Fix this.

I would prefer if you let the w1 read command to be accessible
regardless if CONFIG_W1_EEPROM is defined or not. Hence have only the w1
eeprom reads under the ifdef...
The w1_read checks for devices anyway and for the bus, so it should
print invalid bus/device if nothing is present there.
Any opinion on this ?


I don't really have a strong opinion on this.

Completely removing non implemented commands seems to be a common thing 
to do in u-boot (cmd/i2c.c for instance) presumably to keep the image 
size as small as possible.
But for the one wire case the code space saving is likely to be small 
and, currently at least, there is little point buiding without 
CONFIG_W1_EEPROM, not sure if that will change some day - of course 
there are other types of one wire devices like various sensors but they 
are probably of less interest in the context of a bootloader.


Let's wait a bit and see what Maxime or anyone else has to say about this.

Regards,

Martin

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

Re: [U-Boot] [PATCH] w1: fix data abort if no one wire bus master present

[Eugen.Hristev]

On 23.10.2018 11:17, Martin Fuzzey wrote:
> Hi Eugen,
> 
> On 23/10/18 09:05, eugen.hris...@microchip.com wrote:
>>
>> On 22.10.2018 19:31, Martin Fuzzey wrote:
>>> When the "w1 bus" command is used with no bus master present
>>> a data abort may occur.
>>>
>>> This is because uclass_first_device() returns zero, but sets the output
>>> struct udevice pointer to NULL in the no device found case.
>>>
>>> Fix w1_get_bus() to account for this and return an error code
>>> as is expected by the callers.
>>>
>>> Signed-off-by: Martin Fuzzey 
>>> ---
>>>    drivers/w1/w1-uclass.c | 14 --
>>>    1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
>>> index aecf7fe..cb41b68 100644
>>> --- a/drivers/w1/w1-uclass.c
>>> +++ b/drivers/w1/w1-uclass.c
>>> @@ -115,17 +115,19 @@ int w1_get_bus(int busnum, struct udevice **busp)
>>>    struct udevice *dev;
>>>    for (ret = uclass_first_device(UCLASS_W1, );
>>> - !ret;
>>> - uclass_next_device(), i++) {
>>> -    if (ret) {
>>> -    debug("Cannot find w1 bus %d\n", busnum);
>>> -    return ret;
>>> -    }
>>> + dev && !ret;
>>> + ret = uclass_next_device(), i++) {
>>>    if (i == busnum) {
>>>    *busp = dev;
>>>    return 0;
>>>    }
>>>    }
>>> +
>>> +    if (!ret) {
>> Hi Martin,
>>
>> Does this mean that if ret != 0 , we had errors, but we are not printing
>> this debug message ? Perhaps we should print out here the debug error
>> regardless of the ret value ? Since we exited with a return 0 if we did
>> find the proper bus.
>>
> 
> With the current code ret != 0 means that a probe error occurred, not 
> that the bus cannot be found,
> if no errors occurred but the requested bus did not exist (either 
> because there were no busses at all or
> the index requested was too big) ret from uclass_first|next_device() == 0
> 
> In the error case "Cannot find w1 bus %d" is probably not the correct 
> error message.
> I would have expected the failing driver to have printed a more explicit 
> error message.
> So that is why I only print the debug message if ret == 0 but the device 
> was not found.

Good for me.

In cmd/w1.c there is an error message printed regardless of the ret, so, 
return -ENODEV here if there is no dev is a good way of fixing it.

Reviewed-by: Eugen Hristev 

Thanks again for your fix

> 
>> May I also ask on which board setup you tested this ? And which 
>> defconfig.
> 
> Tested on an i.MX53 based custom board.
> I am working on the W1 host controller driver for i.MX53 and plan to 
> submit it soon.
> 
> I ran into this problem by accident when I forgot to add the DT entry 
> for my new driver.

Great news, hope that the w1 framework implemented here will help you 
get on track easily.

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

Re: [U-Boot] [PATCH] w1: fix data abort if no one wire bus master present

[Martin Fuzzey]

Hi Eugen,

On 23/10/18 09:05, eugen.hris...@microchip.com wrote:


On 22.10.2018 19:31, Martin Fuzzey wrote:

When the "w1 bus" command is used with no bus master present
a data abort may occur.

This is because uclass_first_device() returns zero, but sets the output
struct udevice pointer to NULL in the no device found case.

Fix w1_get_bus() to account for this and return an error code
as is expected by the callers.

Signed-off-by: Martin Fuzzey 
---
   drivers/w1/w1-uclass.c | 14 --
   1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
index aecf7fe..cb41b68 100644
--- a/drivers/w1/w1-uclass.c
+++ b/drivers/w1/w1-uclass.c
@@ -115,17 +115,19 @@ int w1_get_bus(int busnum, struct udevice **busp)
struct udevice *dev;
   
   	for (ret = uclass_first_device(UCLASS_W1, );

-!ret;
-uclass_next_device(), i++) {
-   if (ret) {
-   debug("Cannot find w1 bus %d\n", busnum);
-   return ret;
-   }
+dev && !ret;
+ret = uclass_next_device(), i++) {
if (i == busnum) {
*busp = dev;
return 0;
}
}
+
+   if (!ret) {

Hi Martin,

Does this mean that if ret != 0 , we had errors, but we are not printing
this debug message ? Perhaps we should print out here the debug error
regardless of the ret value ? Since we exited with a return 0 if we did
find the proper bus.



With the current code ret != 0 means that a probe error occurred, not 
that the bus cannot be found,
if no errors occurred but the requested bus did not exist (either 
because there were no busses at all or

the index requested was too big) ret from uclass_first|next_device() == 0

In the error case "Cannot find w1 bus %d" is probably not the correct 
error message.
I would have expected the failing driver to have printed a more explicit 
error message.
So that is why I only print the debug message if ret == 0 but the device 
was not found.



May I also ask on which board setup you tested this ? And which defconfig.


Tested on an i.MX53 based custom board.
I am working on the W1 host controller driver for i.MX53 and plan to 
submit it soon.


I ran into this problem by accident when I forgot to add the DT entry 
for my new driver.


Regards,

Martin

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

[U-Boot] [RFC][PATCH] ARM: at91: lds: add test SPL binary size and bbs size

[Eugen.Hristev]

From: Wenyou Yang 

Add the test for the SPL binary size and the bbs section size.

Signed-off-by: Wenyou Yang 
---

Hello,

This patch from our at91 tree will check for the SPL size and BSS size,
however, with this check, build will fail for some old platforms.
The solution would be to disable SPL for these failing platform, where
SPL cannot work anyway (too big for the SRAM where it's supposed to be loaded)
or work through the SPL to make it smaller (remove some support from it).
Which is the best approach we should pursue ?
The check would be good anyway to avoid oversizing the SPL.
Any thoughts?

Thanks,
Eugen

 arch/arm/mach-at91/arm926ejs/u-boot-spl.lds | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds 
b/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds
index eca78f8..82098dc 100644
--- a/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds
+++ b/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds
@@ -48,3 +48,13 @@ SECTIONS
__bss_end = .;
} >.sdram
 }
+
+#if defined(CONFIG_SPL_MAX_SIZE)
+ASSERT(__image_copy_end - __image_copy_start < (CONFIG_SPL_MAX_SIZE), \
+   "SPL image too big");
+#endif
+
+#if defined(CONFIG_SPL_BSS_MAX_SIZE)
+ASSERT(__bss_end - __bss_start < (CONFIG_SPL_BSS_MAX_SIZE), \
+   "SPL image BSS too big");
+#endif
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 1/3] efi_loader: rework fdt handling in distro boot script

[AKASHI Takahiro]

On Tue, Oct 23, 2018 at 08:36:58AM +0100, Alexander Graf wrote:
> 
> 
> On 23.10.18 03:08, AKASHI Takahiro wrote:
> > On Mon, Oct 22, 2018 at 08:42:32AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 22.10.18 08:22, AKASHI Takahiro wrote:
> >>> On Mon, Oct 22, 2018 at 01:40:05PM +0900, AKASHI Takahiro wrote:
>  The current scenario for default UEFI booting, scan_dev_for_efi, has
>  several issues:
>  * load dtb dynamically even if its loacation (device) is not the same
>    as BOOTEFI_NAME binary's, (reported by Alex)
>  * invoke 'bootmgr' only if BOOTEFI_NAME binary does exit even though
>    'bootmgr' can and should work independently whether or not the binary
>    exist,
>  * in addition, invoke 'bootmgr' with dynamically-loaded dtb.
>    This behavior is not expected. (reported by Alex)
>  * always assume that a 'fdtfile' variable is defined,
>    ("test -e ${devtype} ${devnum}:${distro_bootpart} 
>  "${prefix}${efi_fdtfile}"
>    always returns true even if fdtfile is NULL with prefix=="/".)
>  * redundantly check for 'fdt_addr_r' in boot_efi_binary
> 
>  In this patch, all the issues above are sorted out.
>  Please note that the default behavior can be customized with:
>   fdtfile: a dtb file name
>   efi_dtb_prefixes: a list of paths for searching for a dtb file
> 
>  (this feature does work even without this patch.)
> 
>  Signed-off-by: AKASHI Takahiro 
>  ---
>   include/config_distro_bootcmd.h | 38 +
>   1 file changed, 20 insertions(+), 18 deletions(-)
> 
>  diff --git a/include/config_distro_bootcmd.h 
>  b/include/config_distro_bootcmd.h
>  index 373fee78a999..256698309eb9 100644
>  --- a/include/config_distro_bootcmd.h
>  +++ b/include/config_distro_bootcmd.h
>  @@ -115,7 +115,7 @@
>    */
>   #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
>    \
>   "if test -z \"${fdtfile}\" -a -n \"${soc}\"; then " 
>    \
>  -  "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; " 
>    \
>  +  "efi_fdtfile=${soc}-${board}${boardver}.dtb; "   \
>   "fi; "
>   #else
>   #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
>  @@ -124,26 +124,20 @@
>   
>   #define BOOTENV_SHARED_EFI  
>    \
>   "boot_efi_binary="  
>    \
>  -"if fdt addr ${fdt_addr_r}; then "  
>    \
>  -"bootefi bootmgr ${fdt_addr_r};"
>    \
>  -"else " 
>    \
>  -"bootefi bootmgr ${fdtcontroladdr};"
>    \
>  -"fi;"   
>    \
>   "load ${devtype} ${devnum}:${distro_bootpart} " 
>    \
>   "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "
>    \
>  -"if fdt addr ${fdt_addr_r}; then "  
>    \
>  -"bootefi ${kernel_addr_r} ${fdt_addr_r};"   
>    \
>  -"else " 
>    \
>  -"bootefi ${kernel_addr_r} ${fdtcontroladdr};"   
>    \
>  -"fi\0"  
>    \
>  +"bootefi ${kernel_addr_r} ${efi_fdt_addr};\0"   
>    \
>   \
>   "load_efi_dtb=" 
>    \
>  -"load ${devtype} ${devnum}:${distro_bootpart} " 
>    \
>  -"${fdt_addr_r} ${prefix}${efi_fdtfile}\0"   
>    \
>  +"load ${devtype} ${devnum}:${distro_bootpart} " 
>    \
>  +"${fdt_addr_r} ${prefix}${efi_fdtfile}; "   
>    \
>  +"if fdt addr ${fdt_addr_r}; then "  
>    \
>  +"efi_fdt_addr=${fdt_addr_r}; "  
>    \
>  +"fi;\0" 
>    \
>   \
>   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"  
>    \
>  -"scan_dev_for_efi=" 
>    \
>  -"setenv efi_fdtfile ${fdtfile}; "   
>    \
>  +"set_efi_fdt_addr=" 
>    \
>  +"efi_fdtfile=${fdtfile}; " \
>   

[U-Boot] Re : [U-Boot,BUG] snow: mmc: SD card access broken: unable to select a mode

[Guillaume GARDET]

Hi,

- Paweł Jarosz  a écrit :
> Hi Guillaume,
> 
> 
> Could you test this patch:
> 
> https://patchwork.ozlabs.org/patch/986180/
> 
> and tell me how it goes?

Unfortunately, it does not solve the problem.
The only solution I found so far is to disable MMC_MODE_HS and 
MMC_MODE_HS_52MHz.
See: 
https://github.com/openSUSE/u-boot/commit/ab0f592165628a43d304106ce8892375543285d4

Cheers,
Guillaume



> 
> 
> Cheers
> 
> Paweł
> 
> 

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

[U-Boot] [PULL] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

please pull from u-boot-imx (tag: u-boot-imx-20181023) thanks !

The tree contains fixes for i.MX6 and improvement in docs, but the most
important part is the introduction of the i.MX8 architecture (thanks to
Peng and Antolji for their work !). Build on Travis reported no error,
but I get a build issue with the VF610 boards - this will be require a
fix in next days. i.MX8 can be built following exactly the instruction
of the README file (NXP firmware requires to acknowledge the EULA).

The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3:

  Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19
-0400)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20181023

for you to fetch changes up to 4684fa8bdd7bb38ef54cc4c60ec12c649536f288:

  serial: mxc: Add match string for i.mx6 quad/dual lite serial
(2018-10-22 18:56:17 +0200)


Merged imx8 architecture + fixes for mx6


Anatolij Gustschin (3):
  imx8: cpu: add function for reading FEC MAC from fuse
  imx8: cpu: add uclass based CPU driver
  i2c: imx_lpi2c: fix typo and register base address format

Bernhard Messerklinger (1):
  serial: mxc: Add match string for i.mx6 quad/dual lite serial

Breno Matheus Lima (7):
  doc: imx: reorganize i.MX documentation
  doc: imx: Move SPD related info to the appropriate doc
  doc: imx: mkimage: reorganize i.MX mkimage documentation
  doc: imx: Reorganize i.MX SoC common documentation
  doc: imx: hab: Reorganize High Assurance Boot documentation
  doc: imx: misc: Reorganize miscellaneous documentation
  doc: imx: Improve i.MX documentation naming

Dan Cimpoca (1):
  board: ge: bx50v3: fix initialization of i2c bus0

Fabien Lahoudere (1):
  board: ge: bx50v3: Change maintainer

Fabio Estevam (4):
  pico-imx7d: Make SPL binary fit into 64kB
  pico-imx7d: Add USB Host support
  colibri_imx7: prime get_ram_size() using imx_ddr_size()
  configs: mx7: Remove CONFIG_DBG_MONITOR

Ian Ray (2):
  board: ge: bx50v3: correct LDB clock
  board: ge: bx50v3: b{4,6}50v3 modeline

Marcel Ziswiler (1):
  imx: mx7: fix potential overflow in imx_ddr_size()

Marek Vasut (3):
  arm: imx: mx5: Make videoskip available on MX5
  arm: mx5: Add LDB clock config code
  arm: mx5: Add M53Menlo board

Otavio Salvador (2):
  pico-imx6ul, pico-imx7d: Use eMMC user partition by default
  pico-imx6ul, pico-imx7d: Enable USB and PXE boot support

Peng Fan (33):
  dt-bindings: pinctrl: add i.MX8QXP pads definition
  dt-bindings: clock: dt-bindings: pinctrl: add i.MX8QXP clocks
definition
  dt-bindings: soc: add i.MX8QXP pm and rsrc definition
  imx8: add scfw macro definition
  imx: add Kconfig entry for i.MX8QXP
  arm: build mach-imx for i.MX8
  arm: global_data: add scu_dev for i.MX8
  misc: add i.MX8 misc driver
  misc: imx8: add scfw api impementation
  imx: boot_mode: Add FLEXSPI boot entry
  imx8: add imx-regs header file
  imx8: pins: include i.MX8QXP pin header when CONFIG_IMX8QXP defined
  imx: add i.MX8 cpu type
  armv8: add cpu core helper functions
  imx8: add basic cpu support
  imx8: add boot device detection
  imx8: implement mmc_get_env_dev
  imx8: add mmu and dram related functions
  imx8: add arch_cpu_init arch_cpu_init_dm
  imx8: add iomux configuration api
  imx8: add dummy clock
  gpio: mxc_gpio: add support for i.MX8
  pinctrl: Add pinctrl driver for i.MX8
  power: Add power domain driver for i.MX8
  clk: imx: add clk driver for i.MX8QXP
  serial_lpuart: Update lpuart driver to support i.MX8
  serial: lpuart: support uclass clk api
  mmc: fsl_esdhc: add uclass clk support
  arm: dts: introduce dtsi for i.MX8QXP
  imx: add i.MX8QXP MEK board support
  tools: add i.MX8/8X image support
  arm: imx: include imx8image support
  imx: imx8qxp_mek: update to build image in U-Boot

Rui Miguel Silva (4):
  imx: mx7: avoid some initialization if low level is skipped
  optee: adjust dependencies and default values for dram
  warp7: include: configs: set skip low level init
  warp7: configs: add bl33 defconfig

Sébastien Szymanski (1):
  ARM: opos6ul: make the board boot again

Xiaoliang Yang (1):
  Kconfig: Convert CONFIG_IMX_WATCHDOG to Kconfig

Ye Li (2):
  serial: lpuart: Enable RX and TX FIFO
  fsl_esdhc: Update usdhc driver to support i.MX8

 arch/arm/Kconfig  |   8 +
 arch/arm/Makefile |   2 +-
 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/fsl-imx8-ca35.dtsi   |  66 +++
 arch/arm/dts/fsl-imx8dx.dtsi  | 499

[U-Boot] [PATCH] configs: at91: at91sam9x5ek: fix bootcmd for NAND flash

[Eugen.Hristev]

The default bootcommand needs to be accurate w.r.t the nand memory map
at 
http://www.at91.com/linux4sam/bin/view/Linux4SAM/AT91sam9x5ekMainPage#NAND_Flash_demo_Memory_map

Updated to load kernel + dtb at right offsets and boot the zImage.

Signed-off-by: Eugen Hristev 
---
 include/configs/at91sam9x5ek.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h
index d48b7d0..63305a7 100644
--- a/include/configs/at91sam9x5ek.h
+++ b/include/configs/at91sam9x5ek.h
@@ -85,8 +85,9 @@
 #define CONFIG_ENV_OFFSET_REDUND   0x10
 #define CONFIG_ENV_SIZE0x2 /* 1 sector = 128 kB */
 #define CONFIG_BOOTCOMMAND "nand read " \
-   "0x2200 0x20 0x30; " \
-   "bootm 0x2200"
+   "0x2200 0x20 0x60; " \
+   "nand read 0x2100 0x18 0x2; " \
+   "bootz 0x2200 - 0x2100"
 #elif defined(CONFIG_SPI_BOOT)
 /* bootstrap + u-boot + env + linux in spi flash */
 #define CONFIG_ENV_OFFSET  0x5000
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 1/3] efi_loader: rework fdt handling in distro boot script

[Alexander Graf]

On 23.10.18 03:08, AKASHI Takahiro wrote:
> On Mon, Oct 22, 2018 at 08:42:32AM +0100, Alexander Graf wrote:
>>
>>
>> On 22.10.18 08:22, AKASHI Takahiro wrote:
>>> On Mon, Oct 22, 2018 at 01:40:05PM +0900, AKASHI Takahiro wrote:
 The current scenario for default UEFI booting, scan_dev_for_efi, has
 several issues:
 * load dtb dynamically even if its loacation (device) is not the same
   as BOOTEFI_NAME binary's, (reported by Alex)
 * invoke 'bootmgr' only if BOOTEFI_NAME binary does exit even though
   'bootmgr' can and should work independently whether or not the binary
   exist,
 * in addition, invoke 'bootmgr' with dynamically-loaded dtb.
   This behavior is not expected. (reported by Alex)
 * always assume that a 'fdtfile' variable is defined,
   ("test -e ${devtype} ${devnum}:${distro_bootpart} 
 "${prefix}${efi_fdtfile}"
   always returns true even if fdtfile is NULL with prefix=="/".)
 * redundantly check for 'fdt_addr_r' in boot_efi_binary

 In this patch, all the issues above are sorted out.
 Please note that the default behavior can be customized with:
fdtfile: a dtb file name
efi_dtb_prefixes: a list of paths for searching for a dtb file

 (this feature does work even without this patch.)

 Signed-off-by: AKASHI Takahiro 
 ---
  include/config_distro_bootcmd.h | 38 +
  1 file changed, 20 insertions(+), 18 deletions(-)

 diff --git a/include/config_distro_bootcmd.h 
 b/include/config_distro_bootcmd.h
 index 373fee78a999..256698309eb9 100644
 --- a/include/config_distro_bootcmd.h
 +++ b/include/config_distro_bootcmd.h
 @@ -115,7 +115,7 @@
   */
  #define BOOTENV_EFI_SET_FDTFILE_FALLBACK  
 \
"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "   \
 -"setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "   \
 +"efi_fdtfile=${soc}-${board}${boardver}.dtb; "   \
"fi; "
  #else
  #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
 @@ -124,26 +124,20 @@
  
  #define BOOTENV_SHARED_EFI
 \
"boot_efi_binary="\
 -  "if fdt addr ${fdt_addr_r}; then "\
 -  "bootefi bootmgr ${fdt_addr_r};"  \
 -  "else "   \
 -  "bootefi bootmgr ${fdtcontroladdr};"  \
 -  "fi;" \
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; "  \
 -  "if fdt addr ${fdt_addr_r}; then "\
 -  "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
 -  "else "   \
 -  "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
 -  "fi\0"\
 +  "bootefi ${kernel_addr_r} ${efi_fdt_addr};\0" \
\
"load_efi_dtb="   \
 -  "load ${devtype} ${devnum}:${distro_bootpart} "   \
 -  "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
 +  "load ${devtype} ${devnum}:${distro_bootpart} "   \
 +  "${fdt_addr_r} ${prefix}${efi_fdtfile}; " \
 +  "if fdt addr ${fdt_addr_r}; then "\
 +  "efi_fdt_addr=${fdt_addr_r}; "\
 +  "fi;\0"   \
\
"efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
 -  "scan_dev_for_efi="   \
 -  "setenv efi_fdtfile ${fdtfile}; " \
 +  "set_efi_fdt_addr="   \
 +  "efi_fdtfile=${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
"for prefix in ${efi_dtb_prefixes}; do "  \
"if test -e ${devtype} "  \
 @@ -151,19 +145,26 @@
"${prefix}${efi_fdtfile}; then "  \
"run load_efi_dtb; "  \
"fi;" \
 -  "done;"   \
 +  "done;\0"   \
 +  \
 +  

Re: [U-Boot] [PATCH 2/5] ARM: rpi_3_32b_defconfig: Add FS_UUID command

[Alexander Graf]

On 23.10.18 07:38, Otavio Salvador wrote:
> From: Fabio Berton 

Thanks a lot for the patch :). However, as it is it will be confusing
for people who read the git log to figure out why this patch is in the
tree and what its net effect is.

So could you please provide a proper patch description that explains:

  1) Why do you need the config flag?
  2) Why isn't it set already?
  3) Why are you only touching the 32b defconfig?


Thanks,

Alex

> 
> Signed-off-by: Fabio Berton 
> Signed-off-by: Otavio Salvador 
> ---
> 
>  configs/rpi_3_32b_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
> index d3d4596ba0..33c476bb4f 100644
> --- a/configs/rpi_3_32b_defconfig
> +++ b/configs/rpi_3_32b_defconfig
> @@ -14,6 +14,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
>  CONFIG_CMD_USB=y
> +CONFIG_CMD_FS_UUID=y
>  CONFIG_OF_EMBED=y
>  CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
>  CONFIG_ENV_FAT_INTERFACE="mmc"
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] ARM: vexpress-ca9x4_defconfig: Enable CMD_UBI support

[Linus Walleij]

On Tue, Oct 23, 2018 at 8:38 AM Otavio Salvador  wrote:

> This allow for convenient use of QEMU machine to test loading of UBI
> filesystem.
>
> Signed-off-by: Otavio Salvador 

Looks helpful.
Acked-by: Linus Walleij 

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

[U-Boot] [U-Boot, BUG] snow: mmc: SD card access broken: unable to select a mode

[Paweł Jarosz]

Hi Guillaume,


Could you test this patch:

https://patchwork.ozlabs.org/patch/986180/

and tell me how it goes?


Cheers

Paweł


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

Re: [U-Boot] [PATCH v3 3/9] dm: uclass: Add uclass_foreach_dev_probe

[Patrice CHOTARD]

Hi Simon

On 10/19/18 5:27 AM, Simon Glass wrote:
> Hi Patrick,
> 
> On 15 October 2018 at 03:01, Patrice CHOTARD  wrote:
>> Hi Bin
>>
>> On 10/12/2018 12:13 PM, Bin Meng wrote:
>>> Hi Patrice,
>>>
>>> On Fri, Oct 12, 2018 at 3:51 PM Patrice CHOTARD  
>>> wrote:

 Hi Bin

 On 10/11/2018 11:06 AM, Bin Meng wrote:
> Hi Patrice,
>
> On Tue, Oct 9, 2018 at 9:41 PM Patrice Chotard  
> wrote:
>>
>> Add uclass_foreach_dev_probe() which iterates through
>> devices of a given uclass. Devices are probed if necessary
>> and are ready to use.
>>
>> Signed-off-by: Patrice Chotard 
>> Reviewed-by: Simon Glass 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  include/dm/uclass.h | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/include/dm/uclass.h b/include/dm/uclass.h
>> index 6e7c1cd3e8bc..10ccfdce951e 100644
>> --- a/include/dm/uclass.h
>> +++ b/include/dm/uclass.h
>> @@ -376,4 +376,20 @@ int uclass_resolve_seq(struct udevice *dev);
>>  #define uclass_foreach_dev_safe(pos, next, uc) \
>> list_for_each_entry_safe(pos, next, >dev_head, uclass_node)
>>
>> +/**
>> + * uclass_foreach_dev_probe() - Helper function to iteration through 
>> devices
>> + * of given uclass
>> + *
>> + * This creates a for() loop which works through the available devices 
>> in
>> + * a uclass in order from start to end. Devices are probed if necessary,
>> + * and ready for use.
>> + *
>> + * @id: Uclass ID
>> + * @dev: struct udevice * to hold the current device. Set to NULL when 
>> there
>> + * are no more devices.
>> + */
>> +#define uclass_foreach_dev_probe(id, dev)  \
>> +   for (uclass_first_device(id, ); dev; \
>> +uclass_next_device())
>
> Shouldn't we check the return value of uclass_first_device() and
> uclass_next_device()?

 It's not necessary to check the return value of uclass_first_device(id,
 ) because in any error case, dev is NULL, which is the loop output
 condition. This is only for the first iteration.

>>>
>>> Please see the comment of uclass_first_device().
>>>
>>>  * @devp: Returns pointer to the first device in that uclass if no error
>>>  * occurred, or NULL if there is no first device, or an error occurred with
>>>  * that device.
>>>  * @return 0 if OK (found or not found), other -ve on error
>>>
>>> So it can return error with a valid dev.
>>
>> I checked the uclass_first_device() implementation and the comment seems
>> not aligned with what is coded. When uclass_first_device() returns a
>> valid dev, return value is always 0. (see uclass_get_device_tail()
>> return value).
> 
> I actually don't like this function. Let's use
> uclass_first_device_err() when we care about errors. I am wondering if
> we should delete uclass_first_device().

Ok i will use uclass_first_device_err() instead

>>
>> In any case uclass_first_device() returns a valid dev with an error.
>>
>> Simon, Bin do you confirm ?
> 
> I don't see how, no.
>>
>>>
 For the other iteration, dev comes from uclass_next_device(),
 similarly to uclass_first_device(), in any error case dev is NULL.

>>>
>>> Similar please see the comment of uclass_next_device().
>>
>> I have the same remark regarding uclass_next_device().

I will add a new uclass_next_device_err()

Thanks

Patrice

> 
> 
> Reviewed-by: Simon Glass 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Hannes Schmelzer]

On 10/23/2018 05:24 AM, Bin Meng wrote:

Hi Hannes,

Hi Bing,
thanks for your response.


On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer  wrote:

This commit creates the freedom for boards to do nothing with the whole
IRQ stuff on x86 during u-boot.

This is especially important on older systems which have many legacy irq
and no ACPI support within BIOS, they get in trouble if, for example,
u-boot does mask all the interrupts on a PIC.


Can you elaborate more on what specific issues are here? x86 interrupt
was designed to keep backward compatible and I don't think current
codes will break anything.

I'm actually porting coreboot + u-boot as payload for a quite old board.
Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
I went into trouble during bringing up ATA (whis no pci device) within 
linux after u-boot did run on the machine, the driver didn't get any 
interrupts from the device.
The combination coreboot+seabios for example worked fine. So i've 
searched for differences.


The difference is, that seabios leaves the irq stuff untouched and 
u-boot not.


Further thinking about all this brought me to the point that the OS has 
no real chance to setup things correctly without an ACPI or MP Table 
from the boot-loader where the hardware may be described. PCI devices 
are working correctly, because the configuration space of the pci device 
describes the situation and OS can setup the things correctly. In my 
case coreboot doesn't provide none of these tables, instead it did setup 
the PIC and maybe many other things in the southbridge to a basically 
working state. So my idea was to instruct u-boot to leave the irq stuff 
untouched.
Further i think there is no need for manipulating the PIC during u-boot, 
unless we don't use any interrupt there.


But maybe i'm thinking here completely weird and another way would bring 
me faster to the goal of a working system. Please let me know.


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

Re: [U-Boot] [PATCH] w1: fix build without CONFIG_W1_EEPROM

[Eugen.Hristev]

On 22.10.2018 19:51, Martin Fuzzey wrote:
> Building with CONFIG_W1 and CONFIG_CMD_W1 but without CONFIG_W1_EEPROM
> fails with
>   drivers/w1/w1-uclass.c:104: undefined reference to 
> `w1_eeprom_register_new_device'
>   cmd/w1.c:93: undefined reference to `w1_eeprom_read_buf'
> 
> Fix this.

I would prefer if you let the w1 read command to be accessible 
regardless if CONFIG_W1_EEPROM is defined or not. Hence have only the w1 
eeprom reads under the ifdef...
The w1_read checks for devices anyway and for the bus, so it should 
print invalid bus/device if nothing is present there.
Any opinion on this ?

Thanks,
Eugen
> 
> Signed-off-by: Martin Fuzzey 
> ---
>   cmd/w1.c   | 9 -
>   drivers/w1/w1-uclass.c | 2 ++
>   2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/cmd/w1.c b/cmd/w1.c
> index 9c95fcf..9765bd6 100644
> --- a/cmd/w1.c
> +++ b/cmd/w1.c
> @@ -41,6 +41,7 @@ static int w1_bus(void)
>   return CMD_RET_SUCCESS;
>   }
>   
> +#ifdef CONFIG_W1_EEPROM
>   static int w1_read(int argc, char *const argv[])
>   {
>   int bus_n = 0, dev_n = 0, offset = 0, len = 512;
> @@ -102,6 +103,7 @@ static int w1_read(int argc, char *const argv[])
>   
>   return CMD_RET_SUCCESS;
>   }
> +#endif
>   
>   int do_w1(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
>   {
> @@ -111,8 +113,10 @@ int do_w1(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
>   if (!strcmp(argv[1], "bus"))
>   return w1_bus();
>   
> +#ifdef CONFIG_W1_EEPROM
>   if (!strcmp(argv[1], "read"))
>   return w1_read(argc, argv);
> +#endif
>   
>   return CMD_RET_SUCCESS;
>   }
> @@ -120,7 +124,10 @@ int do_w1(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
>   U_BOOT_CMD(w1, 6, 0, do_w1,
>  "onewire interface utility commands",
>  "bus - show onewire bus info (all)\n"
> +#ifdef CONFIG_W1_EEPROM
>  "w1 read [ [ [offset [length"
>  "- read from onewire device 'dev' on onewire bus 'bus'"
>  " starting from offset 'offset' and length 'length'\n"
> -"  defaults: bus 0, dev 0, offset 0, length 512 bytes.");
> +"  defaults: bus 0, dev 0, offset 0, length 512 bytes."
> +#endif
> +);
> diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
> index cb41b68..5544b19 100644
> --- a/drivers/w1/w1-uclass.c
> +++ b/drivers/w1/w1-uclass.c
> @@ -100,8 +100,10 @@ static int w1_enumerate(struct udevice *bus)
>   debug("%s: Detected new device 0x%llx (family 0x%x)\n",
> bus->name, rn, (u8)(rn & 0xff));
>   
> +#ifdef CONFIG_W1_EEPROM
>   /* attempt to register as w1-eeprom device */
>   w1_eeprom_register_new_device(rn);
> +#endif
>   }
>   }
>   
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] w1: fix data abort if no one wire bus master present

[Eugen.Hristev]

On 22.10.2018 19:31, Martin Fuzzey wrote:
> When the "w1 bus" command is used with no bus master present
> a data abort may occur.
> 
> This is because uclass_first_device() returns zero, but sets the output
> struct udevice pointer to NULL in the no device found case.
> 
> Fix w1_get_bus() to account for this and return an error code
> as is expected by the callers.
> 
> Signed-off-by: Martin Fuzzey 
> ---
>   drivers/w1/w1-uclass.c | 14 --
>   1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
> index aecf7fe..cb41b68 100644
> --- a/drivers/w1/w1-uclass.c
> +++ b/drivers/w1/w1-uclass.c
> @@ -115,17 +115,19 @@ int w1_get_bus(int busnum, struct udevice **busp)
>   struct udevice *dev;
>   
>   for (ret = uclass_first_device(UCLASS_W1, );
> -  !ret;
> -  uclass_next_device(), i++) {
> - if (ret) {
> - debug("Cannot find w1 bus %d\n", busnum);
> - return ret;
> - }
> +  dev && !ret;
> +  ret = uclass_next_device(), i++) {
>   if (i == busnum) {
>   *busp = dev;
>   return 0;
>   }
>   }
> +
> + if (!ret) {

Hi Martin,

Does this mean that if ret != 0 , we had errors, but we are not printing 
this debug message ? Perhaps we should print out here the debug error 
regardless of the ret value ? Since we exited with a return 0 if we did 
find the proper bus.


May I also ask on which board setup you tested this ? And which defconfig.

Thanks,
Eugen

> + debug("Cannot find w1 bus %d\n", busnum);
> + ret = -ENODEV;
> + }
> +
>   return ret;
>   }
>   
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 19/30] riscv: fix inconsistent use of spaces and tabs in start.S

[Rick Chen]

> > > Start.S uses both tabs and spaces after instructions. Fix this by only
> >
> > nits: start.S
> >
> > > using tabs after instructions.
> > >
> > > Signed-off-by: Lukas Auer 
> > > ---
> > >
> > >  arch/riscv/cpu/start.S | 322
> > > -
> > >  1 file changed, 161 insertions(+), 161 deletions(-)
> > >
> >
> > Reviewed-by: Bin Meng 

Reviewed-by: Rick Chen 

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

Re: [U-Boot] [PATCH] w1-eeprom: ds24xxx: fix data abort in ds24xxx_probe()

[Eugen.Hristev]

On 22.10.2018 19:31, Martin Fuzzey wrote:
> Data abort was occurring when using "w1 bus" with a DS24B33 present.
> 
> The abort occurred in the ds24xxx_probe() because the struct w1_device
> pointer was NULL. This is because that structure  is allocated by
> the parent device uclass (by .per_child_platdata_auto_alloc_size)
> and thus the correct accessor is dev_get_parent_platdata() not
> dev_get_platdata()
> 
> Signed-off-by: Martin Fuzzey 

Reviewed-by: Eugen Hristev 

Hi Martin,

At some point during development I switched from holding the data in 
platdata to parent platdata, and this slipped.

Thanks for the fix.
Eugen

> ---
>   drivers/w1-eeprom/ds24xxx.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/w1-eeprom/ds24xxx.c b/drivers/w1-eeprom/ds24xxx.c
> index 56186e5..0967acc 100644
> --- a/drivers/w1-eeprom/ds24xxx.c
> +++ b/drivers/w1-eeprom/ds24xxx.c
> @@ -31,7 +31,7 @@ static int ds24xxx_probe(struct udevice *dev)
>   {
>   struct w1_device *w1;
>   
> - w1 = dev_get_platdata(dev);
> + w1 = dev_get_parent_platdata(dev);
>   w1->id = 0;
>   return 0;
>   }
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/9] dm: pinctrl: Add get_pin_muxing() ops

[Patrice CHOTARD]

Hi Simon

On 10/19/18 5:28 AM, Simon Glass wrote:
> Hi Patrice,
> 
> On 9 October 2018 at 07:31, Patrice Chotard  wrote:
>> Add get_pin_muxing() which allows to display the muxing
>> of a given pin belonging to a pin-controller.
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>> Changes in v3:
>>  - Replace const char **buf parameter by char *buf, int size parameters
>>for pinctrl_get_pin_muxing()
>>
>> Changes in v2:
>>  - Replace pinmux_show ops which displayed the complete pin-controller
>>muxing by get_pin_muxing ops which displays the muxing of one pin
>>
>>  drivers/pinctrl/pinctrl-uclass.c | 13 +
>>  include/dm/pinctrl.h | 32 
>>  2 files changed, 45 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
> But please see below.
> 
>>
>> diff --git a/drivers/pinctrl/pinctrl-uclass.c 
>> b/drivers/pinctrl/pinctrl-uclass.c
>> index c38bb212ed74..cd2ca4e4950e 100644
>> --- a/drivers/pinctrl/pinctrl-uclass.c
>> +++ b/drivers/pinctrl/pinctrl-uclass.c
>> @@ -249,6 +249,19 @@ int pinctrl_get_gpio_mux(struct udevice *dev, int 
>> banknum, int index)
>> return ops->get_gpio_mux(dev, banknum, index);
>>  }
>>
>> +int pinctrl_get_pin_muxing(struct udevice *dev, int selector, char *buf,
>> +  int size)
>> +{
>> +   struct pinctrl_ops *ops = pinctrl_get_ops(dev);
>> +
>> +   if (!ops->get_pin_muxing)
>> +   return -ENOSYS;
>> +
>> +   snprintf(buf, size, ops->get_pin_muxing(dev, selector));
> 
> I wonder if it would be easy to return -ENOSPC if the string is too long?

Not so easy, for example in pinctrl_stm32.c, depending of the pin's
muxing mode, i not only copy but also, in some case, concatenate
additional information. It would complexify the pinctrl code.


Patrice

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

Re: [U-Boot] [PATCH v3 7/9] pinctrl: stm32: Add get_pin_muxing() ops

[Patrice CHOTARD]

Hi Simon

On 10/19/18 5:25 AM, Simon Glass wrote:
> Hi Patrice,
> 
> On 9 October 2018 at 07:31, Patrice Chotard  wrote:
>> Add get_pin_muxing() ops to obtain the pin muxing description
>> a given pin index.
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  drivers/pinctrl/pinctrl_stm32.c | 77 
>> +
>>  1 file changed, 77 insertions(+)
>>
>> diff --git a/drivers/pinctrl/pinctrl_stm32.c 
>> b/drivers/pinctrl/pinctrl_stm32.c
>> index e0bee4b97bd5..588efda8df4b 100644
>> --- a/drivers/pinctrl/pinctrl_stm32.c
>> +++ b/drivers/pinctrl/pinctrl_stm32.c
>> @@ -27,8 +27,34 @@ struct stm32_gpio_bank {
>>
>>  #define MAX_PIN_PER_BANK   16
>>
>> +#define MAX_PIN_MUX_LEN40
>> +static char pin_mux[MAX_PIN_MUX_LEN];
>> +
>>  #define MAX_PIN_NAME_LEN   12
>>  static char pin_name[MAX_PIN_NAME_LEN];
>> +#define PINMUX_MODE_COUNT  5
>> +static const char * const pinmux_mode[PINMUX_MODE_COUNT] = {
>> +   "gpio input",
>> +   "gpio output",
>> +   "analog",
>> +   "unknown",
>> +   "alt function",
>> +};
>> +
>> +static int stm32_pinctrl_get_af(struct udevice *dev, unsigned int offset)
>> +{
>> +   struct stm32_gpio_priv *priv = dev_get_priv(dev);
>> +   struct stm32_gpio_regs *regs = priv->regs;
>> +   u32 af;
>> +   u32 alt_shift = (offset % 8) * 4;
>> +   u32 alt_index =  offset / 8;
>> +
>> +   af = (readl(>afr[alt_index]) &
>> + GENMASK(alt_shift + 3, alt_shift)) >> alt_shift;
>> +
>> +   return af;
>> +}
>> +
>>  static int stm32_pinctrl_get_pins_count(struct udevice *dev)
>>  {
>> struct stm32_pinctrl_priv *priv = dev_get_priv(dev);
>> @@ -97,6 +123,56 @@ static const char *stm32_pinctrl_get_pin_name(struct 
>> udevice *dev,
>>
>> return pin_name;
>>  }
>> +
>> +static const char *stm32_pinctrl_get_pin_muxing(struct udevice *dev,
>> +   unsigned int selector)
> 
> Again I think this should be passed a buffer to write into.

Ok

Thanks

Patrice

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

Re: [U-Boot] [PATCH v3 9/9] pinctrl: sandbox: Add get_pin_muxing ops support

[Patrice CHOTARD]

Hi Simon

On 10/19/18 5:25 AM, Simon Glass wrote:
> On 9 October 2018 at 07:31, Patrice Chotard  wrote:
>> Add get_pin_mux ops support to display the pin muxing
>> description of the sandbox_pins[]
>>
>> Signed-off-by: Patrice Chotard 
>> ---
>>
>> Changes in v3:
>>  - Fix typo
>>
>> Changes in v2: None
>>
>>  drivers/pinctrl/pinctrl-sandbox.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/pinctrl/pinctrl-sandbox.c 
>> b/drivers/pinctrl/pinctrl-sandbox.c
>> index 755ac08bdf72..c09e0f2d0e37 100644
>> --- a/drivers/pinctrl/pinctrl-sandbox.c
>> +++ b/drivers/pinctrl/pinctrl-sandbox.c
>> @@ -17,6 +17,14 @@ static const char * const sandbox_pins[] = {
>> "W1"
>>  };
>>
>> +static const char * const sandbox_pins_muxing[] = {
>> +   "I2C SCL",
>> +   "I2C SDA",
>> +   "Uart TX",
>> +   "Uart RX",
>> +   "1-wire gpio",
>> +};
>> +
>>  static const char * const sandbox_groups[] = {
>> "i2c",
>> "serial_a",
>> @@ -56,6 +64,12 @@ static const char *sandbox_get_pin_name(struct udevice 
>> *dev, unsigned selector)
>> return sandbox_pins[selector];
>>  }
>>
>> +static const char *sandbox_get_pin_muxing(struct udevice *dev,
>> + unsigned int selector)
>> +{
>> +   return sandbox_pins_muxing[selector];
>> +}
>> +
>>  static int sandbox_get_groups_count(struct udevice *dev)
>>  {
>> return ARRAY_SIZE(sandbox_groups);
>> @@ -123,6 +137,7 @@ static int sandbox_pinconf_group_set(struct udevice *dev,
>>  const struct pinctrl_ops sandbox_pinctrl_ops = {
>> .get_pins_count = sandbox_get_pins_count,
>> .get_pin_name = sandbox_get_pin_name,
>> +   .get_pin_muxing = sandbox_get_pin_muxing,
>> .get_groups_count = sandbox_get_groups_count,
>> .get_group_name = sandbox_get_group_name,
>> .get_functions_count = sandbox_get_functions_count,
>> --
>> 1.9.1
>>
> 
> Reviewed-by: Simon Glass 
> 
> I suggest adding a test that executes this command on sandbox.
> 

Ok i will add a test for that.

Thanks

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