[U-Boot] [PATCH v2 2/2] warp7 : run sec_init for CAAM RNG

[Bryan O'Donoghue]

This patch adds a sec_init call into board_init. Doing so in conjunction
with the patch "drivers/crypto/fsl: assign job-rings to non-TrustZone"
enables use of the CAAM in Linux when OPTEE/TrustZone is active.

u-boot will initialise the RNG and assign ownership of the job-ring
registers to a non-TrustZone context. Linux then simply has to detect or be
told to skip RNG initialisation.

This change is safe both for the OPTEE/TrustZone boot path and the regular
non-OPTEE/TrustZone boot path.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Marco Franchi 
Cc: Vanessa Maegima 
Cc: Stefano Babic 
---
 board/warp7/warp7.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 337e76b..219ab6f 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -225,6 +226,10 @@ int board_init(void)
setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
#endif
 
+   #ifdef CONFIG_FSL_CAAM
+   sec_init();
+   #endif
+
return 0;
 }
 
@@ -366,5 +371,4 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, 
const char *name)
 
return 0;
 }
-
 #endif /* ifdef CONFIG_USB_GADGET */
-- 
2.7.4

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

Re: [U-Boot] SquashFS and FIT images

[Chris Packham]

Hi Mark,

On 26/01/2018 10:12, "Mathew McBride"  wrote:

On 26/01/2018 8:01 AM, Bishop, Mark (STRT) wrote:

> Is it possible to specify squashFS images in an .its file?  If so, anyone
> have an example or a pointer to the docs I've been searching for?
> Hi Mark,
>
It is possible, here is an example I have used on an NXP LS1043 board:
/dts-v1/;


As Matthew's example shows it's totally doable. Furthermore it's not just
squashfs it could be any valid initrd. As long as your kernel is configured
to expect it u-boot will pass it along.

On that note last time i looked most if the general kernel defconfigs
didn't have squashfs enabled.

/ {
description = "ARM64 OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;

images {
kernel@1 {
description = "ARM64 OpenWrt Linux-4.4";
data = /incbin/("arch/arm64/boot/Image.gz");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x8008>;
entry = <0x8008>;
};


ramdisk@1 {
description = "ARM64 OpenWrt ramdisk";
data = /incbin/("root.squashfs");
type = "ramdisk";
arch = "arm64";
os = "linux";
compression = "gzip";
};


fdt@1 {
description = "ARM64 OpenWrt device tree blob";
data = /incbin/("arch/arm64/boot/dts/
freescale/fsl-ls1043a-rdb.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
load = <0x9000>;
};


};

configurations {
default = "config@1";
config@1 {
description = "OpenWrt";
kernel = "kernel@1";
fdt = "fdt@1";
ramdisk = "ramdisk@1";
};
};
};

Cheers,
Matt

Mark Bishop
> Sr. Firmware/Software Engineer - Microwave Subsystems
>
> [cid:image001.png@01D281ED.A45F0A90]
>
> 4726 Eisenhower Blvd.
> Tampa, FL 33634
> USA
>
>
> T  +1 813 901 7293
>
> mbis...@smithsinterconnectinc.com >
>
> smithsinterconnect.com
>
> TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!
>
>
>
>
>
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
>

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

[U-Boot] [PATCH v2 0/2] Fix CAAM for TrustZone enable for warp7

[Bryan O'Donoghue]

V2:
- Add an explicit assignment of JRMID when setting job-ring ownership
  Required on my reference part where the JRMID field is not set on the
  third job-ring

V1:
This series is the u-boot fix to a problem we encountered when enabling
OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is activated
the first page of CAAM registers becomes read-only, read-zero from the
perspective of Linux and other non TrustZone contexts.

Offlining the problem with Peng Fan[1] we eventually came to realise the
problem could be worked around by

1. Making Linux skip RNG initialisation - a set of patches should be
   hitting LKML to do just that.

2. Initialising the RNG either from u-boot or OPTEE. In this case u-boot is
   the right place to-do that because there's upstream code in u-boot that
   just works. Patch #2 does that for the WaRP7.

3. Ensuring the job-ring registers are assigned to the non TrustZone mode.
   On the i.MX7 after the BootROM runs the job-ring registers are assigned
   to TrustZone. Patch #1 does that for all CAAM hardware.

On point #3 this ordinarily isn't a problem because unless TrustZone is
activated the restrictions on the job-ring registers don't kick in, its
only after enabling TrustZone that Linux will loose access to the job-ring
registers.

Finally should OPTEE or another TEE want to do things with the job-ring
registers it will have sufficient privilege to assign whichever job-ring
registers it wants to OPTEE/TEE but will naturally then have to arbitrate
with Linux to inform the Kernel CAAM driver which job-ring registers it can
and cannot access.

That arbitration process is for a future putative OPTEE/TEE CAAM driver to
solve and is out of scope of this patchset.

[1] Thanks for all of your help BTW - Peng, there's no way this would be
working without you giving direction on how.

Bryan O'Donoghue (2):
  drivers/crypto/fsl: assign job-rings to non-TrustZone
  warp7 : run sec_init for CAAM RNG

 board/warp7/warp7.c | 6 +-
 drivers/crypto/fsl/jr.c | 9 +
 drivers/crypto/fsl/jr.h | 2 ++
 3 files changed, 16 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[U-Boot] [PATCH v2 1/2] drivers/crypto/fsl: assign job-rings to non-TrustZone

[Bryan O'Donoghue]

After enabling TrustZone various parts of the CAAM silicon become
inaccessible to non TrustZone contexts. The job-ring registers are designed
to allow non TrustZone contexts like Linux to still submit jobs to CAAM
even after TrustZone has been enabled.

The default job-ring permissions after the BootROM look like this for
job-ring zero.

ms=0x8001 ls=0x8001

The MS field is JRaMIDR_MS (job ring MID most significant).

Referring to "Security Reference Manual for i.MX 7Dual and 7Solo
Applications Processors, Rev. 0, 03/2017" section 8.10.4 we see that
JROWN_NS controls whether or not a job-ring is accessible from non
TrustZone.

Bit 15 (TrustZone) is the logical inverse of bit 3 hence the above value of
0x8001 shows that JROWN_NS=0 and TrustZone=1.

Clearly then as soon as TrustZone becomes active the job-ring registers are
no longer accessible from Linux, which is not what we want.

This patch explicitly sets all job-ring registers to JROWN_NS=1 (non
TrustZone) by default and to the Non-Secure MID 001. Both settings are
required to successfully assign a job-ring to non-secure mode. If a piece
of TrustZone firmware requires ownership of job-ring registers it can unset
the JROWN_NS bit itself.

This patch in conjunction with a modification of the Linux kernel to skip
HWRNG initialisation makes CAAM usable to Linux with TrustZone enabled.

Signed-off-by: Bryan O'Donoghue 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Alex Porosanu 
Cc: Ruchika Gupta 
Cc: Aneesh Bansal 
Link: https://github.com/OP-TEE/optee_os/issues/1408
Link: https://tinyurl.com/yam5gv9a
---
 drivers/crypto/fsl/jr.c | 9 +
 drivers/crypto/fsl/jr.h | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index a6dad01..34bd070 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -579,6 +579,8 @@ int sec_init_idx(uint8_t sec_idx)
 {
ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
uint32_t mcr = sec_in32(>mcfgr);
+   uint32_t jrown_ns;
+   int i;
int ret = 0;
 
 #ifdef CONFIG_FSL_CORENET
@@ -634,6 +636,13 @@ int sec_init_idx(uint8_t sec_idx)
 #endif
 #endif
 
+   /* Set ownership of job rings to non-TrustZone mode by default */
+   for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
+   jrown_ns = sec_in32(>jrliodnr[i].ms);
+   jrown_ns |= JROWN_NS | JRMID_NS;
+   sec_out32(>jrliodnr[i].ms, jrown_ns);
+   }
+
ret = jr_init(sec_idx);
if (ret < 0) {
printf("SEC initialization failed\n");
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index f546226..ef515e7 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -34,6 +34,8 @@
 #define JRNSLIODN_MASK 0x0fff
 #define JRSLIODN_SHIFT 0
 #define JRSLIODN_MASK  0x0fff
+#define JROWN_NS   0x0008
+#define JRMID_NS   0x0001
 
 #define JQ_DEQ_ERR -1
 #define JQ_DEQ_TO_ERR  -2
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/1] Broadwell-DE Implementation

[Bin Meng]

Hi Vincenzo,

On Fri, Jan 26, 2018 at 2:58 AM, vnktux  wrote:
> Hi all,
>
> This patch contain a working implementation of Broadwell-DE for U-Boot, and
> support memory down with external SPD binary file. However there is only one
> issue that I couldn't solve, the booting process takes 1 hour. When the FSP
> reach "DDRIO Initialization" it take a lot before the memory is initialized
> and you can reach the U-Boot shell. I would like a review of my
> implementation since I am out of options. I tried to Enable/Disable MRC
> Cache and ACPI Resume but the problem is still there.
>
> Best regards,
> Vincenzo Bove
>
> Signed-off-by: Vincenzo Bove 
> ---

Please make sure you follow https://www.denx.de/wiki/U-Boot/Patches to
send your patches. Thanks!

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

Re: [U-Boot] [PATCH v6 0/4] spi: cadence_spi: Adopt Linux DT bindings

[Jagan Teki]

On Wed, Jan 24, 2018 at 4:43 AM, Jason Rush  wrote:
> Adopt the Linux DT bindings. This also fixes an issue
> with the indaddrtrig register on the Cadence QSPI
> device being programmed with the wrong value for the
> socfpga arch.
>
> Tested on TI K2G platform:
> Tested-by: Vignesh R 
>
> Tested on a socfpga-cyclonev board:
> Tested-by: Simon Goldschmidt 
>
> Signed-off-by: Jason Rush 
> Reviewed-by: Jagan Teki 
> Acked-by: Simon Goldschmidt 
> Acked-by: Marek Vasut 
>
> Jason Rush (4):
>   spi: cadence_spi: Sync DT bindings with Linux
>   dts: cadence_spi: Sync DT bindings with Linux
>   config: cadence_spi: Remove defines read from DT
>   dts: cadence_spi: Update documentation for DT bindings

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

Re: [U-Boot] [BUG] 0001-mmc-fix-the-wrong-disabling-clock.patch

[Jaehoon Chung]

Hi Heinrich,

On 01/26/2018 12:28 PM, Jaehoon Chung wrote:
> Hi,
> 
> On 01/26/2018 04:37 AM, Heinrich Schuchardt wrote:
>> With git master HEAD the Odroid C2 hangs after the command line countdown.
>>
>> Bisecting teaches that this is the patch causing the problem:
>>
>> 9546eb92cb648a8bba0aa9d5930ac751e6e5b9a4
>> mmc: fix the wrong disabling clock
> 
> When you search for commit with bisecting, this commit might be occurred a 
> problem.
> So i have sent the patches a below patches.
> 
> I don't have odroid-c2 board. so it's difficult to find what happen to your 
> board.
> Could you share the log message?
> 
> Almost all boards are working fine. and those patches make sense.
> 
> If revert these patches, too many boards can't use MMC card.
> 
>>
>> Please, revert the patch.
> 
> Well, my opinion is first step that we try to find what is main problem about 
> odriod-c2 or others..
> Not only revert the patch. Also i will try to solve your issue.

I didn't have Odroid-C2 board, i can't test anything. Could you test with below 
code?

diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index 3cd934634d..c17efd25c6 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -35,6 +35,9 @@ static void meson_mmc_config_clock(struct mmc *mmc)
uint32_t meson_mmc_clk = 0;
unsigned int clk, clk_src, clk_div;
 
+   if (mmc->clock == 0)
+   return 0;
+
/* 1GHz / CLK_MAX_DIV = 15,9 MHz */
if (mmc->clock > 1600) {
clk = SD_EMMC_CLKSRC_DIV2;

Best Regards,
Jaehoon Chung

> 
> Best Regards,
> Jaehoon Chung
> 
>>
>> I could not find the patch in
>> https://lists.denx.de/pipermail/u-boot/2018-January/date.html
>>
>> http://patchwork.ozlabs.org/patch/864607/
>> seems to be related but does not solve the issue.
>>
>> Best regards
>>
>> Heinrich
>>
>>
>>
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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

[U-Boot] [PATCH] autoboot.c: Init SHA buffer size in passwd_abort

[Martin Etnestad]

The call to hash_block in passwd_abort fails with error ENOSPC on some
systems. The reason is that the variable which specifies the size of the
buffer to contain the computed hash does not get initialized.

This patch initializes the variable with the size of the buffer.

Signed-off-by: Martin Etnestad 
---
 common/autoboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/autoboot.c b/common/autoboot.c
index a011865028..2eef7a04cc 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -57,7 +57,7 @@ static int passwd_abort(uint64_t etime)
const char *algo_name = "sha256";
u_int presskey_len = 0;
int abort = 0;
-   int size;
+   int size = sizeof(sha);
int ret;
 
if (sha_env_str == NULL)
-- 
2.15.1

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

Re: [U-Boot] [PATCH 1/9] drivers: net: pfe_eth: LS1012A PFE driver introduction

[Calvin Johnson]

Hi Joe,

> -Original Message-
> From: Joe Hershberger [mailto:joe.hershber...@ni.com]
> Sent: Wednesday, December 06, 2017 1:44 AM
> To: Calvin Johnson 
> Cc: u-boot ; Joe Hershberger
> ; Anji Jagarlmudi 
> Subject: Re: [U-Boot] [PATCH 1/9] drivers: net: pfe_eth: LS1012A PFE driver
> introduction
> 
> On Mon, Oct 9, 2017 at 4:11 AM, Calvin Johnson 
> wrote:
> > This patch adds PFE driver into U-Boot.

[snip]

> > +   if (dev_id > 1) {
> > +   printf("Invalid port\n");
> > +   return -1;
> > +   }
> > +
> > +   dev = (struct eth_device *)malloc(sizeof(struct eth_device));
> 
> Please don't add a new driver that uses the legacy API. Make this a
> driver model driver.

PFE IP has two MACs.  
In the legacy driver model, we were registering two ethernet 
devices/interfaces, pfe_eth0 and pfe_eth1.

With the new driver model, I'm wondering whether we can do the same.
IIUC, U_BOOT_DEVICE corresponds to PFE IP on the LS1012A platform and  struct 
eth_pdata corresponds to
each MAC. Is this correct?

If yes, how can we register two interfaces, pfe_eth0 and pfe_eth1? Please 
advice.

Thanks
Calvin


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

Re: [U-Boot] [PATCH v8 2/2] DW SPI: Get clock value from Device Tree

[Jagan Teki]

On Thu, Jan 25, 2018 at 10:01 PM, Tom Rini  wrote:
> On Thu, Jan 25, 2018 at 06:37:20PM +0530, Jagan Teki wrote:
>> On Thu, Jan 25, 2018 at 6:15 PM, Alexey Brodkin
>>  wrote:
>> > Hi Jagan,
>> >
>> > On Fri, 2018-01-19 at 14:17 +0100, Eugeniy Paltsev wrote:
>> >> Hi Jagan,
>> >>
>> >> Could you please pull these patches to your tree?
>> >> It would be really nice to see this patch in the nearest release.
>> >>
>> >> Thanks.
>> >>
>> >> On Thu, 2017-12-28 at 15:09 +0300, Eugeniy Paltsev wrote:
>> >> > Add option to set spi controller clock frequency via device tree
>> >> > using standard clock bindings.
>> >> >
>> >> > Define dw_spi_get_clk function as 'weak' as some targets
>> >> > (like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
>> >> > and implement dw_spi_get_clk their own way in their clock manager.
>> >> >
>> >> > Get rid of clock_manager.h include as we don't use
>> >> > cm_get_spi_controller_clk_hz function anymore. (we use redefined
>> >> > dw_spi_get_clk in SOCFPGA clock managers instead)
>> >> >
>> >> > Reviewed-by: Marek Vasut 
>> >> > Signed-off-by: Eugeniy Paltsev 
>> >> > ---
>> >
>> > Any chance for this one to be applied sometime soon?
>> > Note this is a prerequisite for our further work and it's been floating
>> > and discussed on the mailing list for a couple of months now,
>> > that said we'd really like to get this as a part of U-Boot 2018.03.
>>
>> Since delegate has marked to 'marek' it wasn't showed with me, yes
>> will take this.
>
> As always, oops, my bad.  I think I saw Marek commenting at one point
> and kept delegating to him.  And I missed that it now has his
> Reviewed-by, so yes, please pick this up in patchwork, thanks!

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

[U-Boot] [PATCH 1/1] efi_loader: consistently use %pD to print device paths

[Heinrich Schuchardt]

Now that we have %pD support in vsprintf we should avoid separate
logic for printing device paths in other places.

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

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 857d88a879..c96b9d48c5 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -120,11 +120,9 @@ static void *try_load_entry(uint16_t n, struct 
efi_device_path **device_path,
 
if (lo.attributes & LOAD_OPTION_ACTIVE) {
efi_status_t ret;
-   u16 *str = NULL;
 
-   debug("%s: trying to load \"%ls\" from: %ls\n", __func__,
- lo.label, (str = efi_dp_str(lo.file_path)));
-   efi_free_pool(str);
+   debug("%s: trying to load \"%ls\" from %pD\n",
+ __func__, lo.label, lo.file_path);
 
ret = efi_load_image_from_path(lo.file_path, );
 
-- 
2.15.1

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

Re: [U-Boot] [PATCH v3 0/3] cadence-quadspi: Fix issues with non 32bit aligned accesses

[Jagan Teki]

On Wed, Jan 24, 2018 at 10:44 AM, Vignesh R  wrote:
> This series reverts use of bounce_buf.c for non-DMA related alignment
> restriction and replaces it with local bounce buffer to handle problems
> with non 32 bit aligned writes on TI platforms.
> Based on top of Jason's series:
> [PATCH v6 0/4] spi: cadence_spi: Adopt Linux DT bindings
>
> Tested on K2G EVM.
>
> v3:
> Rebased on top of latest u-boot-spi/master changes.
>
> Goldschmidt Simon (1):
>   Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction
> when possible"
>
> Vignesh R (2):
>   Revert "spi: cadence_qspi_apb: Use 32 bit indirect write transaction
> when possible"
>   spi: cadence_qspi_apb: Make flash writes 32 bit aligned

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

[U-Boot] [PATCH 1/1] vsprintf.c: correct printing of a NULL device path

[Heinrich Schuchardt]

When printing '%pD' with a value of NULL we want to output
''. But this requires copying to buf. Leave this
to string16.

A unit test is supplied which relies on EFI support in the sandbox.

The development for EFI support in the sandbox is currently in branch
u-boot-dm/efi-working. The branch lacks commit 6ea8b580f06b ("efi_loader:
correct DeviceNodeToText for media types"). Ater rebasing the aforementioned
branch on U-Boot v2018.01 and adding 256060e4257a2 and this patch the test
is executed successfully.

Fixes: 256060e4257a2 (vsprintf.c: add EFI device path printing)
Signed-off-by: Heinrich Schuchardt 
---
Alex, could you pick this up for the efi-next tree, please.
---
 lib/vsprintf.c| 3 ++-
 test/print_ut.c   | 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 226f4eb3e5..5f7a5f17dc 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -300,8 +300,9 @@ static char *device_path_string(char *buf, char *end, void 
*dp, int field_width,
 {
u16 *str;
 
+   /* If dp == NULL output the string '' */
if (!dp)
-   return "";
+   return string16(buf, end, dp, field_width, precision, flags);
 
str = efi_dp_str((struct efi_device_path *)dp);
if (!str)
diff --git a/test/print_ut.c b/test/print_ut.c
index 1aa68be7a9..d8e9da8fa8 100644
--- a/test/print_ut.c
+++ b/test/print_ut.c
@@ -44,6 +44,10 @@ static void efi_ut_print(void)
 
snprintf(str, sizeof(str), "_%pD_", buf);
assert(!strcmp("_/SD(3)_", str));
+
+   /* NULL device path */
+   snprintf(str, sizeof(str), "_%pD_", NULL);
+   assert(!strcmp("__", str));
 #endif
 }
 
-- 
2.15.1

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

Re: [U-Boot] [PATCH] crypto/fsl: instantiate all rng state handles

[Bryan O'Donoghue]

On 25/01/18 13:11, Lukas Auer wrote:

Extend the instantiate_rng() function and the corresponding CAAM job
descriptor to instantiate all RNG state handles. This moves the RNG
instantiation code in line with the CAAM kernel driver.

Previously, only the first state handle was instantiated. The second one
was instantiated by the CAAM kernel driver. This works if the kernel
runs in secure mode, but fails in non-secure mode since the kernel
driver uses DEC0 directly instead of over the job ring interface.
Instantiating all RNG state handles in u-boot removes the need for using
DEC0 in the kernel driver, making it possible to use the CAAM in
non-secure mode.

Signed-off-by: Lukas Auer 


So Lukas this patch along with my series for the job-ring ownership 
means we can drop detection of TrustZone in the Linux CAAM driver.


Tested-by: Bryan O'Donoghue 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Jagan Teki]

Hi Tom,

Please pull this PR.

Changes for v2:
- Fixed patches on wait_bit
- Collected new patches.

thanks!
Jagan.

The following changes since commit 98691a60abffb44303d7dae6e9e699d0daded930:

  Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51 -0500)

are available in the git repository at:

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

for you to fetch changes up to 58c125b9e2b232ce73ed7b24ba7b1ca5ff41c5bd:

  DW SPI: Get clock value from Device Tree (2018-01-26 11:26:16 +0530)


Chris Packham (1):
  spi: kirkwood_spi: implement workaround for FE-9144572

Eugeniy Paltsev (2):
  SOCFPGA: clock manager: implement dw_spi_get_clk function
  DW SPI: Get clock value from Device Tree

Goldschmidt Simon (1):
  Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when 
possible"

Jason Rush (4):
  spi: cadence_spi: Sync DT bindings with Linux
  dts: cadence_spi: Sync DT bindings with Linux
  config: cadence_spi: Remove defines read from DT
  dts: cadence_spi: Update documentation for DT bindings

Mario Six (8):
  spi: Fix style violation and improve code
  spi: Remove obsolete spi_base_setup_slave_fdt
  spi: Remove spi_flash_probe_fdt
  spi: Remove spi_setup_slave_fdt
  spi: Remove CONFIG_OF_SPI_FLASH
  spi: sf_probe: Fix style violations
  spi: spi-uclass: Fix style violations
  sf_probe: Merge spi_flash_probe_tail into spi_flash_probe

Miquel Raynal (1):
  doc: bindings: soft-spi: update documentation to match the code

Vignesh R (2):
  Revert "spi: cadence_qspi_apb: Use 32 bit indirect write transaction when 
possible"
  spi: cadence_qspi_apb: Make flash writes 32 bit aligned

Álvaro Fernández Rojas (16):
  wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
  wait_bit: use wait_for_bit_le32 and remove wait_for_bit
  drivers: spi: allow limiting reads
  drivers: spi: consider command bytes when sending transfers
  dm: spi: add BCM63xx SPI driver
  mips: bmips: add bcm63xx-spi driver support for BCM6338
  mips: bmips: add bcm63xx-spi driver support for BCM6348
  mips: bmips: add bcm63xx-spi driver support for BCM6358
  mips: bmips: add bcm63xx-spi driver support for BCM3380
  mips: bmips: add bcm63xx-spi driver support for BCM63268
  mips: bmips: enable the SPI flash on the Sagem F@ST1704
  mips: bmips: enable the SPI flash on the Netgear CG3100D
  dm: spi: add BCM63xx HSSPI driver
  mips: bmips: add bcm63xx-hsspi driver support for BCM6328
  mips: bmips: add bcm63xx-hsspi driver support for BCM63268
  mips: bmips: enable the SPI flash on the Comtrend AR-5387un

 arch/arm/dts/keystone-k2g-evm.dts |  75 +++--
 arch/arm/dts/keystone-k2g.dtsi|   5 +-
 arch/arm/dts/socfpga.dtsi |   5 +-
 arch/arm/dts/socfpga_arria10.dtsi |   4 +-
 arch/arm/dts/socfpga_arria5_socdk.dts |   9 +-
 arch/arm/dts/socfpga_cyclone5_is1.dts |   9 +-
 arch/arm/dts/socfpga_cyclone5_socdk.dts   |   9 +-
 arch/arm/dts/socfpga_cyclone5_sockit.dts  |   9 +-
 arch/arm/dts/socfpga_cyclone5_socrates.dts|   9 +-
 arch/arm/dts/socfpga_cyclone5_sr1500.dts  |   9 +-
 arch/arm/dts/socfpga_cyclone5_vining_fpga.dts |  18 +-
 arch/arm/dts/stv0991.dts  |  12 +-
 arch/arm/include/asm/arch-mvebu/spi.h |   6 +
 arch/arm/mach-imx/mx6/ddr.c   |  22 +-
 arch/arm/mach-socfpga/clock_manager.c |   4 +-
 arch/arm/mach-socfpga/clock_manager_arria10.c |   9 +
 arch/arm/mach-socfpga/clock_manager_gen5.c|  15 +-
 arch/arm/mach-socfpga/reset_manager_arria10.c |  36 +--
 arch/mips/dts/brcm,bcm3380.dtsi   |  17 +
 arch/mips/dts/brcm,bcm63268.dtsi  |  38 +++
 arch/mips/dts/brcm,bcm6328.dtsi   |  24 ++
 arch/mips/dts/brcm,bcm6338.dtsi   |  17 +
 arch/mips/dts/brcm,bcm6348.dtsi   |  17 +
 arch/mips/dts/brcm,bcm6358.dtsi   |  17 +
 arch/mips/dts/comtrend,ar-5387un.dts  |  12 +
 arch/mips/dts/netgear,cg3100d.dts |  12 +
 arch/mips/dts/sagem,f...@st1704.dts  |  12 +
 arch/mips/mach-ath79/ar934x/clk.c |   2 +-
 board/samtec/vining_2000/vining_2000.c|   4 +-
 configs/comtrend_ar5387un_ram_defconfig   |   8 +
 configs/netgear_cg3100d_ram_defconfig |   8 +
 configs/sagem_f@st1704_ram_defconfig  |   8 +
 doc/device-tree-bindings/spi/soft-spi.txt |  24 +-
 doc/device-tree-bindings/spi/spi-cadence.txt  |  13 +-
 drivers/clk/clk_pic32.c   |  12 +-
 drivers/clk/renesas/clk-rcar-gen3.c   |   4 +-
 drivers/ddr/microchip/ddr2.c  |   8 +-
 drivers/fpga/socfpga_arria10.c|  17 +-
 drivers/mmc/msm_sdhci.c   |   8 +-
 drivers/mtd/pic32_flash.c |   4 +-
 drivers/mtd/spi/sf_probe.c

Re: [U-Boot] [BUG] 0001-mmc-fix-the-wrong-disabling-clock.patch

[Jaehoon Chung]

Hi,

On 01/26/2018 04:37 AM, Heinrich Schuchardt wrote:
> With git master HEAD the Odroid C2 hangs after the command line countdown.
> 
> Bisecting teaches that this is the patch causing the problem:
> 
> 9546eb92cb648a8bba0aa9d5930ac751e6e5b9a4
> mmc: fix the wrong disabling clock

When you search for commit with bisecting, this commit might be occurred a 
problem.
So i have sent the patches a below patches.

I don't have odroid-c2 board. so it's difficult to find what happen to your 
board.
Could you share the log message?

Almost all boards are working fine. and those patches make sense.

If revert these patches, too many boards can't use MMC card.

> 
> Please, revert the patch.

Well, my opinion is first step that we try to find what is main problem about 
odriod-c2 or others..
Not only revert the patch. Also i will try to solve your issue.

Best Regards,
Jaehoon Chung

> 
> I could not find the patch in
> https://lists.denx.de/pipermail/u-boot/2018-January/date.html
> 
> http://patchwork.ozlabs.org/patch/864607/
> seems to be related but does not solve the issue.
> 
> Best regards
> 
> Heinrich
> 
> 
> 

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

Re: [U-Boot] [PATCH] efi_laoder: Call Exit() on return from payload in StartImage()

[Heinrich Schuchardt]

On 01/26/2018 12:53 AM, Alexander Graf wrote:

There is a typo in the subject "efi_laoder".


When a UEFI payload just returns instead of calling the Exit() callback,
we handle that in efi_do_enter() and call Exit on its behalf, so that
the loaded_image->exit_status value is correct.

We were missing that logic in StartImage(). Call it there too.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf 
---
  lib/efi_loader/efi_boottime.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f5dae40f06..4a36b62828 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1578,8 +1578,13 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
  
  	ret = EFI_CALL(entry(image_handle, ));
  
-	/* Should usually never get here */

-   return EFI_EXIT(ret);
+   /*
+* Usually UEFI applications call Exit() instead of returning.
+* But because the world doesn not consist of ponies and unicorns,
+* we're happy to emulate that behavior on behalf of a payload
+* that forgot.
+*/
+   return EFI_CALL(systab.boottime->exit(image_handle, ret, 0, NULL));
  }
  
  /*




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

Re: [U-Boot] [PATCH v10 00/12] mips: bmips: add SPI support

[Jagan Teki]

On Tue, Jan 23, 2018 at 9:44 PM, Álvaro Fernández Rojas
 wrote:
> BCM63xx SPI controller is a bit tricky since it doesn't allow keeping CS
> active between transfers, so I had to modify the spi_flash driver in order
> to allow limiting reads.
>
> v10: Introduce changes reported by Tom Rini & Daniel Schwierzeck:
> - Fix undefined BE read functions
> v9: Introduce changes suggested by Simon Glass:
> - Fix defconfig order.
> v8: Introduce changes suggested by Jagan Teki & Daniel Schwierzeck:
> - Squash wait_bit commits.
> - Remove register param castings.
> v7: Introduce changes suggested by Jagan Teki & Daniel Schwierzeck:
> - Use const void* reg for compatibility with 64 bit systems.
> - Remove prefix and use __func__ instead.
> - Remove wait_for_bit and update callers to wait_for_bit_le32.
> v6: Introduce changes suggested by Jagan Teki:
> - Use cmd instead of val to avoid confusions.
> - Switch to wait_for_bit instead of infinite loop.
> v5: Introduce changes suggested by Jagan Teki:
> - Use long structs for registers
> v4: Introduce changes suggested by Jagan Teki:
> - Add data for each HW controller instead of having two separate configs.
> v3: Fix bug introduced in v2: sizeof(cmd) vs len.
> Also rename BCM6338 SPI driver to BCM6348 SPI since BCM6338 is a stripped
> down version of the BCM6348.
> Switch to devfdt_get_addr_size_index().
> v2: Introduce changes requested by Simon Glass:
> - Always include command bytes when determining max write size.
> Also move SPI aliases from .dts to .dtsi files.
>
> Álvaro Fernández Rojas (12):
>   wait_bit: add 8/16/32 BE/LE versions of wait_for_bit
>   wait_bit: use wait_for_bit_le32 and remove wait_for_bit
>   drivers: spi: allow limiting reads
>   drivers: spi: consider command bytes when sending transfers
>   dm: spi: add BCM63xx SPI driver
>   mips: bmips: add bcm63xx-spi driver support for BCM6338
>   mips: bmips: add bcm63xx-spi driver support for BCM6348
>   mips: bmips: add bcm63xx-spi driver support for BCM6358
>   mips: bmips: add bcm63xx-spi driver support for BCM3380
>   mips: bmips: add bcm63xx-spi driver support for BCM63268
>   mips: bmips: enable the SPI flash on the Sagem F@ST1704
>   mips: bmips: enable the SPI flash on the Netgear CG3100D

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

Re: [U-Boot] [PATCH V3] imx: mx25: Remove SION bit in all pin-mux that are safe

[Michael Trimarchi]

Hi Benoit

On Thu, Jan 25, 2018 at 10:48:42PM +0100, Benoît Thébaudeau wrote:
> Hi Michael,
> 
> On Thu, Jan 25, 2018 at 2:06 PM, Michael Trimarchi
>  wrote:
> > SION bit should be used in the situation that we need
> > to read back the value of a pin and should not be set by
> > default macro.
> >
> > We get some malfunction as raised by following thread
> >
> > https://www.spinics.net/lists/linux-usb/msg162574.html
> >
> > As reported by this application note:
> > https://www.nxp.com/docs/en/application-note/AN5078.pdf
> >
> > The software input on (SION) bit is an option to force an input
> > path to be active regardless of the value driven by the
> > corresponding module. It is used when the nature direction
> > of a pin depending on selected alternative function is an output,
> > but it is needed to read the real logic value on a pin.
> >
> > The SION bit can be used in:
> > • Loopback: the module of a selected alternative function drives
> > the pad and also receives the pad value as an input
> > • GPIO capture: the module of a selected alternative function
> > drives the pin and the value is captured by the GPIO
> >
> > SION bit is not necessary when the pin is configured as a peripheral
> > apart specific silicon bug. If an application needs to have this
> > set, this should be done in board file or in dts file
> >
> > Signed-off-by: Michael Trimarchi 
> 
> [...]
> 
> I have now tested the following peripherals on i.MX25 without any SION
> bit set: AUDMUX/SSI, eSDHC, FEC (except PHY access for which MDIO
> might have an issue without SION; Ethernet works but I have not
> checked whether this is possible at least partially without access to
> the PHY registers), GPIO, I2C, SLCDC, UART, and USB. Everything worked
> fine except the lack of SION for eSDHC CMD, which is true for all
> eSDHC instances (and not only for eSDHC1, so Linux's
> arch/arm/boot/dts/imx25-pinfunc.h should be fixed). Therefore, SION is
> mandatory for all the eSDHC CMD functions in

I have checked and u-boot does not have this pin-muxing. I think that this
patch should go as it is and a separate patch like this one following should
be applied after that. What do you think?

> arch/arm/include/asm/arch-mx25/iomux-mx25.h, but it can be removed for
> everything else (I still have to carry out one more test to confirm
> this for FEC MDIO), and moved to the board files if necessary (but I
> don't think that any mainline board code is doing something fancy
> enough to need it).
> 
> If the bus-status detection example in the documentation of SION in
> the reference manual is useful, it means that SION is probably
> required for all the signals requiring simultaneous output and input
> (such as I²C for device clock stretching or multi-master bus
> arbitration, except if the IP toggles between input and output low at
> each clock edge rather than between open-drain output high and output
> low), because there are no automatic SION signals between the
> peripherals and the pads but only direction signals that can request a
> single direction at a time. For bidirectional signals that do not
> require simultaneous output and input because they work in turns (such
> as FEC MDIO), SION can be required or not depending on whether the IP
> toggles the direction signal for each turn or always expects an input
> feedback while driving an open-drain output high. Even if SION is
> required for the I²C example mentioned above (which is unlikely as
> basic I²C transfers work fine and clock stretching detection is
> automatic and would always need the input state), the need for these
> advanced I²C features can be considered board-specific, so SION would
> still not be required in iomux-mx25.h.
> 
> In the end, for this patch, apart from the pending test for FEC MDIO:
> Reviewed-by: Benoît Thébaudeau 
> 
> Best regards,
> Benoît

From d6b5bf4f1b6a0bcbcfd6ff2597fd2a7b3884cb3b Mon Sep 17 00:00:00 2001
From: Michael Trimarchi 
Date: Fri, 26 Jan 2018 08:42:54 +0100
Subject: [PATCH] imx: mx25: Add pinmux definition for ESDHC2

Add pin mux of second esdhc interface. Set SION bin on the CMD
muxing in order to avoid sdcard fail detection

Signed-off-by: Michael Trimarchi 
---
 arch/arm/include/asm/arch-mx25/iomux-mx25.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h 
b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
index 437f122..1b38d16 100644
--- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
+++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
@@ -225,15 +225,18 @@ enum {
 
MX25_PAD_LD8__LD8   = IOMUX_PAD(0x2e0, 0x0e8, 0x00, 
0, 0, PAD_CTL_SRE_FAST),
MX25_PAD_LD8__FEC_TX_ERR= IOMUX_PAD(0x2e0, 0x0e8, 0x05, 
0, 0, NO_PAD_CTRL),
+   MX25_PAD_LD8__SDHC2_CMD = IOMUX_PAD(0x2e0, 0x0e8, 0x06, 

Re: [U-Boot] [PATCH 2/7] sun50i: a64: Fix USB clock/reset properties

[Maxime Ripard]

On Wed, Jan 24, 2018 at 07:06:37AM -0600, Samuel Holland wrote:
> On 01/24/18 02:42, Maxime Ripard wrote:
> > On Tue, Jan 23, 2018 at 04:18:14PM -0600, Samuel Holland wrote:
> >> Move the CLK_USB_OHCI0/1 clocks to the OHCI nodes where they belong, and
> >> make the format consistent with the H3/H5 nodes. While here, also remove
> >> leading zeros from the USB nodes' unit addresses.
> >>
> >> Signed-off-by: Samuel Holland 
> > 
> > I guess you just took the linux DTS?
> 
> No, actually the Linux DTS has the same issue with the clocks (the
> unit addresses there have been fixed). Should I send a patch there
> first?

A patch fixing that has been merged in 4.15.

> > You can just mention that, along with which version of the kernel you
> > used for that synchronization.
> 
> And then once that's merged, send a patch for synchronization?

So you're only left with that :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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 3/3] sunxi: add I2C nodes present on Orange Pi >ero

[Maxime Ripard]

On Wed, Jan 24, 2018 at 12:03:26PM +0100, Nuno Gonçalves wrote:
> On Wed, Jan 24, 2018 at 11:58 AM, Maxime Ripard
>  wrote:
> > In particular, you should describe what these i2c buses are used for.
> 
> They are available on the pins exclusively. I could add the pinout for
> this board for sure. But maybe it doesn't make sense in this case to
> activate them, as without external hardware they have no use.

Indeed. It's still good to have that patch for reference though, even
if we won't merge it.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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 2/3] sunxi: add DM I2C support for H3/H5

[Maxime Ripard]

On Wed, Jan 24, 2018 at 12:00:58PM +0100, Nuno Gonçalves wrote:
> On Wed, Jan 24, 2018 at 11:57 AM, Maxime Ripard
>  wrote:
> > Why don't you just synchronize the DT with Linux?
> 
> Didn't know that was the usual approach. But in Linux the files have a
> different structure, for example there is sunxi-h3-h5.dtsi.

Yes, but nothing prevents us to have the same one here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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] crypto/fsl: instantiate all rng state handles

[Heinrich Schuchardt]

On 01/25/2018 04:53 PM, Bryan O'Donoghue wrote:
> 
> 
> On 25/01/18 13:11, Lukas Auer wrote:
>> Extend the instantiate_rng() function and the corresponding CAAM job
>> descriptor to instantiate all RNG state handles. This moves the RNG
>> instantiation code in line with the CAAM kernel driver.
>>
>> Previously, only the first state handle was instantiated. The second one
>> was instantiated by the CAAM kernel driver. This works if the kernel
>> runs in secure mode, but fails in non-secure mode since the kernel
>> driver uses DEC0 directly instead of over the job ring interface.
>> Instantiating all RNG state handles in u-boot removes the need for using
>> DEC0 in the kernel driver, making it possible to use the CAAM in
>> non-secure mode.
>>
>> Signed-off-by: Lukas Auer 
> 
> git apply < \[PATCH\]\ crypto_fsl\:\ instantiate\ all\ rng\ state\
> handles.eml
> :107: trailing whitespace.
> void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc, int handle)
> :130: trailing whitespace.
>     (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT);
> :131: trailing whitespace.
> 
> :132: trailing whitespace.
> /* For SH0, Secure Keys must be generated as well */
> :133: trailing whitespace.
> if (handle == 0) {
> error: patch failed: drivers/crypto/fsl/jobdesc.c:257
> error: drivers/crypto/fsl/jobdesc.c: patch does not apply
> error: patch failed: drivers/crypto/fsl/jobdesc.h:40
> error: drivers/crypto/fsl/jobdesc.h: patch does not apply
> error: patch failed: drivers/crypto/fsl/jr.c:444
> error: drivers/crypto/fsl/jr.c: patch does not apply
> error: patch failed: drivers/crypto/fsl/jr.h:40
> error: drivers/crypto/fsl/jr.h: patch does not apply
> error: patch failed: include/fsl_sec.h:67
> error: include/fsl_sec.h: patch does not apply

The patch provided by Lukas is applicable to git HEAD
(fb4413295c765aa8c013650984dc2d908964c81d).

File MAINTAINERS does not indicate another git repository for
drivers/crypto/fsl/jobdesc.c.

Pleae, rebase your local repository.

Best regards

Heinrich

> 
> git show HEAD
> commit c761a7e29d703d60208585bb7d8415e00aa22556
> Author: Tom Rini 
> Date:   Mon Jan 22 21:06:41 2018 -0500
> 
>     Revert "travis-ci: Add qemu-x86_64 target"
> 
> 

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

Re: [U-Boot] [PATCH] common/memsize.c: restore content of the base address

[Patrick DELAUNAY]

Hi Wolfgang,

> From: Wolfgang Denk [mailto:w...@denx.de]
> Subject: Re: [U-Boot] [PATCH] common/memsize.c: restore content of the base
> 
> Dear Patrick,
> 
> In message <94c2391ea4e943fb9f65e7b0943c9...@sfhdag6node3.st.com>
> you wrote:
> 
> > Ok, I will do it but only in background...
> > I will propose a V2 and I will crosscheck with previously broken board if 
> > it is still
> the case.
> 
> Thanks a lot.  Please ping me (if needed PM or on jabber) if I should not 
> react.

Sorry for the delay  (Christmas break and other project priority) but I have 
finally sent a V2 version of the patch.
I split the patchset in 2 to better understood the possible regression.

Don't hesitate to ask me if I need to ask some board maintainer to test these 2 
patches...

> Best regards,
> 
> Wolfgang Denk

Best regards

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

[U-Boot] [PATCH v2 1/2] common/memsize.c: prepare get_ram_size update

[Patrick Delaunay]

Save the content of the base address in a new variable
in stack (save_base) to prepare restore this content.

This patch don't modified code behavior and stack usage.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- Split patch in 2 part to more easily understood regression

 common/memsize.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/common/memsize.c b/common/memsize.c
index 0fb9ba5..6dc4bb2 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -27,7 +27,8 @@ DECLARE_GLOBAL_DATA_PTR;
 long get_ram_size(long *base, long maxsize)
 {
volatile long *addr;
-   long   save[32];
+   long   save[31];
+   long   save_base;
long   cnt;
long   val;
long   size;
@@ -43,7 +44,7 @@ long get_ram_size(long *base, long maxsize)
 
addr = base;
sync();
-   save[i] = *addr;
+   save_base = *addr;
sync();
*addr = 0;
 
@@ -51,7 +52,7 @@ long get_ram_size(long *base, long maxsize)
if ((val = *addr) != 0) {
/* Restore the original data before leaving the function. */
sync();
-   *addr = save[i];
+   *base = save_base;
for (cnt = 1; cnt < maxsize / sizeof(long); cnt <<= 1) {
addr  = base + cnt;
sync();
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/2] common/memsize.c: restore content of the base address

[Patrick Delaunay]

For the last return of function get_ram_size(),
when size=maxsize, restore the base address (*base)
content.

Add comment for the remaining case to avoid regression:
this case is already correctly handled.

Signed-off-by: Patrick Delaunay 
---

Changes in v2:
- Solve issue for overlap case: don't restore saved value (invalid)
  and add comment to avoid to have this issue again

 common/memsize.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/common/memsize.c b/common/memsize.c
index 6dc4bb2..c315275 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -77,9 +77,16 @@ long get_ram_size(long *base, long maxsize)
addr  = base + cnt;
*addr = save[--i];
}
+   /* warning: don't restore save_base in this case,
+* it is already done in the loop because
+* base and base+size share the same physical memory
+* and *base is saved after *(base+size) modification
+* in first loop
+*/
return (size);
}
}
+   *base = save_base;
 
return (maxsize);
 }
-- 
2.7.4

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

[U-Boot] [PATCH 0/4] Add support for treating compiler warnings as errors

[Daniel Schwierzeck]

To enforce a zero-warnings policy (e.g. in CI builds), all compiler
warnings have to be treated as errors.

Extend Kbuild and buildman with according options to achieve this.
Enable these new options in all Travis CI builds. All builds with
compiler warnings will now fail. Only DTC warnings are still being
ignored.

Example build which failed due to a compiler warning:
https://travis-ci.org/danielschwierzeck/u-boot/jobs/49371#L936


Daniel Schwierzeck (4):
  Kbuild: support W=[N,]err for passing '-Werror' to the compiler
  buildman: add option -E for treating compiler warnings as errors
  travis.yml: fix 'set +e' in build script
  travis.yml: run buildman with option -E

 .travis.yml | 5 ++---
 scripts/Makefile.extrawarn  | 3 +++
 tools/buildman/builder.py   | 5 -
 tools/buildman/builderthread.py | 2 ++
 tools/buildman/cmdline.py   | 2 ++
 tools/buildman/control.py   | 3 ++-
 6 files changed, 15 insertions(+), 5 deletions(-)

-- 
2.16.1

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

[U-Boot] [PATCH 1/4] Kbuild: support W=[N, ]err for passing '-Werror' to the compiler

[Daniel Schwierzeck]

Extend the Kbuild's W=N option with an optional 'err' value. This
will pass -Werror to the compiler to treat all warnings as errors.
This is useful to enforce a zero-warnings policy.

The 'err' value can also be combined with the numerical values
like this:

make W=1
make W=err
make W=1,err

Signed-off-by: Daniel Schwierzeck 
---

 scripts/Makefile.extrawarn | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 1d3a570594..d8d93b7fe1 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -48,9 +48,12 @@ warning-3 += -Wswitch-default
 warning-3 += $(call cc-option, -Wpacked-bitfield-compat)
 warning-3 += $(call cc-option, -Wvla)
 
+warning-err := -Werror
+
 warning := $(warning-$(findstring 1, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
 warning += $(warning-$(findstring 2, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
 warning += $(warning-$(findstring 3, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
+warning += $(warning-$(findstring err, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
 
 ifeq ("$(strip $(warning))","")
 $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown)
-- 
2.16.1

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

[U-Boot] [PATCH 3/4] travis.yml: fix 'set +e' in build script

[Daniel Schwierzeck]

The build script should not manipulate shell flags (especially '-e').
A non-zero exit value can also be catched with 'cmd || ret=$?'.

Signed-off-by: Daniel Schwierzeck 
---

 .travis.yml | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 2a98c4bb11..1e55e1b7f1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -101,9 +101,8 @@ script:
  #
  # Exit code 129 means warnings only.
  - if [[ "${BUILDMAN}" != "" ]]; then
- set +e;
- tools/buildman/buildman -P ${BUILDMAN};
- ret=$?;
+ ret=0;
+ tools/buildman/buildman -P ${BUILDMAN} || ret=$?;
  if [[ $ret -ne 0 && $ret -ne 129 ]]; then
tools/buildman/buildman -sdeP ${BUILDMAN};
exit $ret;
-- 
2.16.1

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

[U-Boot] [PATCH 2/4] buildman: add option -E for treating compiler warnings as errors

[Daniel Schwierzeck]

Add a new option '-E' for treating all compiler warnings as errors.
Eventually this will pass 'W=err' to Kbuild.

Signed-off-by: Daniel Schwierzeck 
---

 tools/buildman/builder.py   | 5 -
 tools/buildman/builderthread.py | 2 ++
 tools/buildman/cmdline.py   | 2 ++
 tools/buildman/control.py   | 3 ++-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index acb0810457..4e72b7d60d 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -212,7 +212,8 @@ class Builder:
  gnu_make='make', checkout=True, show_unknown=True, step=1,
  no_subdirs=False, full_path=False, verbose_build=False,
  incremental=False, per_board_out_dir=False,
- config_only=False, squash_config_y=False):
+ config_only=False, squash_config_y=False,
+ warnings_as_errors=False):
 """Create a new Builder object
 
 Args:
@@ -237,6 +238,7 @@ class Builder:
 board rather than a thread-specific directory
 config_only: Only configure each build, don't build it
 squash_config_y: Convert CONFIG options with the value 'y' to '1'
+warnings_as_errors: Treat all compiler warnings as errors
 """
 self.toolchains = toolchains
 self.base_dir = base_dir
@@ -270,6 +272,7 @@ class Builder:
 if not self.squash_config_y:
 self.config_filenames += EXTRA_CONFIG_FILENAMES
 
+self.warnings_as_errors = warnings_as_errors
 self.col = terminal.Color()
 
 self._re_function = re.compile('(.*): In function.*')
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 9e8ca80c5b..4ce3f48c66 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -216,6 +216,8 @@ class BuilderThread(threading.Thread):
 args.append('-s')
 if self.builder.num_jobs is not None:
 args.extend(['-j', str(self.builder.num_jobs)])
+if self.builder.warnings_as_errors:
+args.append('W=err')
 config_args = ['%s_defconfig' % brd.target]
 config_out = ''
 args.extend(self.builder.toolchains.GetMakeArguments(brd))
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 74247f0aff..6949d6bf2c 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -32,6 +32,8 @@ def ParseArgs():
   help="Don't build, just configure each commit")
 parser.add_option('-e', '--show_errors', action='store_true',
   default=False, help='Show errors and warnings')
+parser.add_option('-E', '--warnings-as-errors', action='store_true',
+  default=False, help='Treat all compiler warnings as errors')
 parser.add_option('-f', '--force-build', dest='force_build',
   action='store_true', default=False,
   help='Force build of boards even if already built')
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 73b1a14fb6..3cac9f7cf6 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -263,7 +263,8 @@ def DoBuildman(options, args, toolchains=None, 
make_func=None, boards=None,
 incremental=options.incremental,
 per_board_out_dir=options.per_board_out_dir,
 config_only=options.config_only,
-squash_config_y=not options.preserve_config_y)
+squash_config_y=not options.preserve_config_y,
+warnings_as_errors=options.warnings_as_errors)
 builder.force_config_on_failure = not options.quick
 if make_func:
 builder.do_make = make_func
-- 
2.16.1

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

[U-Boot] [PATCH 4/4] travis.yml: run buildman with option -E

[Daniel Schwierzeck]

This forces all compiler warnings to be treated as errors.

Signed-off-by: Daniel Schwierzeck 

---

 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 1e55e1b7f1..59d1dd99e8 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -102,7 +102,7 @@ script:
  # Exit code 129 means warnings only.
  - if [[ "${BUILDMAN}" != "" ]]; then
  ret=0;
- tools/buildman/buildman -P ${BUILDMAN} || ret=$?;
+ tools/buildman/buildman -P -E ${BUILDMAN} || ret=$?;
  if [[ $ret -ne 0 && $ret -ne 129 ]]; then
tools/buildman/buildman -sdeP ${BUILDMAN};
exit $ret;
-- 
2.16.1

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

[U-Boot] [PATCH] dm: serial: Initialize serial console only when it wasn't already configured

[Lukasz Majewski]

It may happen that the MXC serial IP block is performing some ongoing
transmission (started at e.g. board_init()) when the "initr_serial" is
called.

As a result the serial port IP block is reset, so transmitted data is
corrupted:

I2C:   ready
DRAM:  1 GiB
jSS('HH��SL_SDHC: 04 rev 0x0

This patch prevents from this situation, by avoiding re-initialization of
serial IP block (and execution of the same code twice).

I2C:   ready
DRAM:  1 GiB
ID:unit type 0x4 rev 0x0

This patch is a follow up of following discussions:
http://patchwork.ozlabs.org/patch/820824/
http://patchwork.ozlabs.org/patch/830957/


Signed-off-by: Lukasz Majewski 

---

 drivers/serial/serial-uclass.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 2e5116f7ce..c345578b36 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -129,6 +129,9 @@ static void serial_find_console_or_panic(void)
 /* Called prior to relocation */
 int serial_init(void)
 {
+   if (gd->flags & GD_FLG_SERIAL_READY)
+   return 0;
+
serial_find_console_or_panic();
gd->flags |= GD_FLG_SERIAL_READY;
 
-- 
2.11.0

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

Re: [U-Boot] [PATCH] Convert CONFIG_SYS_MAX_NAND_DEVICE to Kconfig and add CONFIG_NAND

[Christophe LEROY]

Le 24/01/2018 à 15:00, Adam Ford a écrit :

Many boards are setting NAND parameters if/when CMD_NAND is set
when in reality they should probably be doing it it CONFIG_NAND
is set.  Previuos attempts to make CMD_NAND select CONFIG_NAND
resulted in some recursive selections, so I think this should be
a better solution

Using the moveconfig tool, I searched for CONFIG_SYS_MAX_NAND_DEVICE
and then any suspicious defconfig files left behind, I added
CONFIG_NAND=y, then retested the migration against that list.

This should allows us to make the CONFIG_CMD_NAND now dependant on
CONFIG_NAND and enable a bunch of NAND parameters under the NAND
menu without appearing 'suspicious'

This converts the following to Kconfig:
CONFIG_SYS_MAX_NAND_DEVICE

Signed-off-by: Adam Ford 
---
  configs/MCR3000_defconfig  | 1 +
  include/configs/MCR3000.h  | 1 -


For the two above files:

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

[U-Boot] [PATCH 2/5] clk: refactor clk_get_by_index() into clk_get_by_indexed_prop()

[Philipp Tomsich]

The logic in clk_get_by_index() may be useful for other properties
than 'clocks': e.g. 'assigned-clocks' and 'assigned-clock-parents'
follows the same model.

This commit refactors clk_get_by_index() by introducing an internal
function clk_get_by_indexed_prop() that allows to specify the name
of the property to process.  The original clk_get_by_index() call
is simply directed through this helper function with the property
name fixed to "clocks".

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 
---

 drivers/clk/clk-uclass.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 20ee0c5..7fdf16d 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -53,7 +53,8 @@ static int clk_of_xlate_default(struct clk *clk,
return 0;
 }
 
-int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
+static int clk_get_by_indexed_prop(struct udevice *dev, const char *prop_name,
+  int index, struct clk *clk)
 {
int ret;
struct ofnode_phandle_args args;
@@ -65,7 +66,7 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk)
assert(clk);
clk->dev = NULL;
 
-   ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
+   ret = dev_read_phandle_with_args(dev, prop_name, "#clock-cells", 0,
 index, );
if (ret) {
debug("%s: fdtdec_parse_phandle_with_args failed: err=%d\n",
@@ -95,6 +96,11 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk)
 
return clk_request(dev_clk, clk);
 }
+
+int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
+{
+   return clk_get_by_indexed_prop(dev, "clocks", index, clk);
+}
 # endif /* OF_PLATDATA */
 
 int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
-- 
2.1.4

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

[U-Boot] [PATCH 1/5] clk: add clk_set_parent()

[Philipp Tomsich]

Clocks may support multiple parents: this change introduces an
optional operation on the clk-uclass to set a clock's parent.

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 
---

 drivers/clk/clk-uclass.c | 12 
 include/clk-uclass.h |  8 
 include/clk.h| 11 +++
 3 files changed, 31 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index fbea720..20ee0c5 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -188,6 +188,18 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
return ops->set_rate(clk, rate);
 }
 
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   const struct clk_ops *ops = clk_dev_ops(clk->dev);
+
+   debug("%s(clk=%p, parent=%p)\n", __func__, clk, parent);
+
+   if (!ops->set_parent)
+   return -ENOSYS;
+
+   return ops->set_parent(clk, parent);
+}
+
 int clk_enable(struct clk *clk)
 {
const struct clk_ops *ops = clk_dev_ops(clk->dev);
diff --git a/include/clk-uclass.h b/include/clk-uclass.h
index e7ea334..75933eb 100644
--- a/include/clk-uclass.h
+++ b/include/clk-uclass.h
@@ -78,6 +78,14 @@ struct clk_ops {
 */
ulong (*set_rate)(struct clk *clk, ulong rate);
/**
+* set_parent() - Set current clock parent
+*
+* @clk:The clock to manipulate.
+* @parent: New clock parent.
+* @return zero on success, or -ve error code.
+*/
+   int (*set_parent)(struct clk *clk, struct clk *parent);
+   /**
 * enable() - Enable a clock.
 *
 * @clk:The clock to manipulate.
diff --git a/include/clk.h b/include/clk.h
index e7ce3e8..e463d8e 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -178,6 +178,17 @@ ulong clk_get_rate(struct clk *clk);
 ulong clk_set_rate(struct clk *clk, ulong rate);
 
 /**
+ * clk_set_parent() - Set current clock parent.
+ *
+ * @clk:   A clock struct that was previously successfully requested by
+ * clk_request/get_by_*().
+ * @parent:A clock struct that was previously successfully requested by
+ * clk_request/get_by_*().
+ * @return new rate, or -ve error code.
+ */
+int clk_set_parent(struct clk *clk, struct clk *parent);
+
+/**
  * clk_enable() - Enable (turn on) a clock.
  *
  * @clk:   A clock struct that was previously successfully requested by
-- 
2.1.4

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

[U-Boot] [PATCH 0/5] clk: support assigned-clock, assigned-clock-parents, assigned-clock-rates

[Philipp Tomsich]

For various peripherals on Rockchip SoCs (e.g. for the Ethernet GMAC),
the parent-clock needs to be set via the DTS.  This adds the required
plumbing and implements the GMAC case for the RK3399.



Philipp Tomsich (5):
  clk: add clk_set_parent()
  clk: refactor clk_get_by_index() into clk_get_by_indexed_prop()
  rockchip: clk: rk3399: implement set_parent() operation
  clk: implement clk_set_defaults()
  rockchip: clk: rk3399: accept all assigned-clocks from the 'cru'-node

 drivers/clk/clk-uclass.c  | 140 +-
 drivers/clk/rockchip/clk_rk3399.c |  92 -
 drivers/core/device.c |   6 ++
 include/clk-uclass.h  |   8 +++
 include/clk.h |  28 
 5 files changed, 270 insertions(+), 4 deletions(-)

-- 
2.1.4

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

[U-Boot] [PATCH 4/5] clk: implement clk_set_defaults()

[Philipp Tomsich]

Linux uses the properties 'assigned-clocks', 'assigned-clock-parents'
and 'assigned-clock-rates' to configure the clock subsystem for use
with various peripheral nodes.

This implements clk_set_defaults() and hooks it up with the general
device probibin in drivers/core/device.c: when a new device is probed,
clk_set_defaults() will be called for it and will process the
properties mentioned above.

Note that this functionality is designed to fail gracefully (i.e. if a
clock-driver does not implement set_parent(), we simply accept this
and ignore the error) as not to break existing board-support.

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 

---

 drivers/clk/clk-uclass.c | 118 +++
 drivers/core/device.c|   6 +++
 include/clk.h|  17 +++
 3 files changed, 141 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 7fdf16d..ad76379 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -2,6 +2,7 @@
  * Copyright (C) 2015 Google, Inc
  * Written by Simon Glass 
  * Copyright (c) 2016, NVIDIA CORPORATION.
+ * Copyright (c) 2018, Theobroma Systems Design und Consulting GmbH
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -10,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -101,6 +103,122 @@ int clk_get_by_index(struct udevice *dev, int index, 
struct clk *clk)
 {
return clk_get_by_indexed_prop(dev, "clocks", index, clk);
 }
+
+static int clk_set_default_parents(struct udevice *dev)
+{
+   struct clk clk, parent_clk;
+   int index;
+   int num_parents;
+   int ret;
+
+   num_parents = dev_count_phandle_with_args(dev, "assigned-clock-parents",
+ "#clock-cells");
+   if (num_parents < 0) {
+   debug("%s: could not read assigned-clock-parents for %p\n",
+ __func__, dev);
+   return 0;
+   }
+
+   for (index = 0; index < num_parents; index++) {
+   ret = clk_get_by_indexed_prop(dev, "assigned-clock-parents",
+ index, _clk);
+   if (ret) {
+   debug("%s: could not get parent clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   return ret;
+   }
+
+   ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
+ index, );
+   if (ret) {
+   debug("%s: could not get assigned clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   return ret;
+   }
+
+   ret = clk_set_parent(, _clk);
+
+   /*
+* Not all drivers may support clock-reparenting (as of now).
+* Ignore errors due to this.
+*/
+   if (ret == -ENOSYS)
+   continue;
+
+   if (ret) {
+   debug("%s: failed to reparent clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static int clk_set_default_rates(struct udevice *dev)
+{
+   struct clk clk;
+   int index;
+   int num_rates;
+   int size;
+   int ret = 0;
+   u32 *rates = NULL;
+
+   size = dev_read_size(dev, "assigned-clock-rates");
+   if (size < 0)
+   return 0;
+
+   num_rates = size / sizeof(u32);
+   rates = calloc(num_rates, sizeof(u32));
+   if (!rates)
+   return -ENOMEM;
+
+   ret = dev_read_u32_array(dev, "assigned-clock-rates", rates, num_rates);
+   if (ret)
+   goto fail;
+
+   for (index = 0; index < num_rates; index++) {
+   ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
+ index, );
+   if (ret) {
+   debug("%s: could not get assigned clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   continue;
+   }
+
+   ret = clk_set_rate(, rates[index]);
+   if (ret < 0) {
+   debug("%s: failed to set rate on clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   break;
+   }
+   }
+
+fail:
+   free(rates);
+   return ret;
+}
+
+int clk_set_defaults(struct udevice *dev)
+{
+   int ret;
+
+   /* If this is running pre-reloc state, don't take any action. */
+   if (!(gd->flags & GD_FLG_RELOC))
+   return 0;
+
+   debug("%s(%s)\n", __func__, dev_read_name(dev));
+
+   

[U-Boot] [PATCH 3/5] rockchip: clk: rk3399: implement set_parent() operation

[Philipp Tomsich]

This implements the (newly added) set_parent() operation for the
RK3399 with a focus on allowing the RGMII clock parent to be
configured via the assigned-clock-parents property of the GMAC node.

This implementation supports only the GMAC (in fact only the RGMII
clock parent) and allows to set this clock's parent either to the
internal SCLK_GMAC or to an external clock input (identifiable by it
providing a 'clock-output-name' of "gmac_clkin").

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 
---

 drivers/clk/rockchip/clk_rk3399.c | 74 +--
 1 file changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 2f4c4e3..e791936 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -742,6 +742,30 @@ static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
return rk3399_mmc_get_clk(cru, clk_id);
 }
 
+static ulong rk3399_gmac_set_clk(struct rk3399_cru *cru, ulong rate)
+{
+   ulong ret;
+
+   /*
+* The RGMII CLK can be derived either from an external "clkin"
+* or can be generated from internally by a divider from SCLK_MAC.
+*/
+   if (readl(>clksel_con[19]) & BIT(4)) {
+   /* An external clock will always generate the right rate... */
+   ret = rate;
+   } else {
+   /*
+* No platform uses an internal clock to date.
+* Implement this once it becomes necessary and print an error
+* if someone tries to use it (while it remains unimplemented).
+*/
+   pr_err("%s: internal clock is UNIMPLEMENTED\n", __func__);
+   ret = 0;
+   }
+
+   return ret;
+}
+
 #define PMUSGRF_DDR_RGN_CON16 0xff330040
 static ulong rk3399_ddr_set_clk(struct rk3399_cru *cru,
ulong set_rate)
@@ -865,8 +889,7 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
ret = rk3399_mmc_set_clk(priv->cru, clk->id, rate);
break;
case SCLK_MAC:
-   /* nothing to do, as this is an external clock */
-   ret = rate;
+   ret = rk3399_gmac_set_clk(priv->cru, rate);
break;
case SCLK_I2C1:
case SCLK_I2C2:
@@ -902,6 +925,52 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
return ret;
 }
 
+static int rk3399_gmac_set_parent(struct clk *clk, struct clk *parent)
+{
+   struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
+   const char *clock_output_name;
+   int ret;
+
+   /*
+* If the requested parent is in the same clock-controller and
+* the id is SCLK_MAC ("clk_gmac"), switch to the internal clock.
+*/
+   if ((parent->dev == clk->dev) && (parent->id == SCLK_MAC)) {
+   debug("%s: switching RGMII to SCLK_MAC\n", __func__);
+   rk_clrreg(>cru->clksel_con[19], BIT(4));
+   return 0;
+   }
+
+   /*
+* Otherwise, we need to check the clock-output-names of the
+* requested parent to see if the requested id is "clkin_gmac".
+*/
+   ret = dev_read_string_index(parent->dev, "clock-output-names",
+   parent->id, _output_name);
+   if (ret < 0)
+   return -ENODATA;
+
+   /* If this is "clkin_gmac", switch to the external clock input */
+   if (!strcmp(clock_output_name, "clkin_gmac")) {
+   debug("%s: switching RGMII to CLKIN\n", __func__);
+   rk_setreg(>cru->clksel_con[19], BIT(4));
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
+static int rk3399_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   switch (clk->id) {
+   case SCLK_RMII_SRC:
+   return rk3399_gmac_set_parent(clk, parent);
+   }
+
+   debug("%s: unsupported clk %ld\n", __func__, clk->id);
+   return -ENOENT;
+}
+
 static int rk3399_clk_enable(struct clk *clk)
 {
switch (clk->id) {
@@ -919,6 +988,7 @@ static int rk3399_clk_enable(struct clk *clk)
 static struct clk_ops rk3399_clk_ops = {
.get_rate = rk3399_clk_get_rate,
.set_rate = rk3399_clk_set_rate,
+   .set_parent = rk3399_clk_set_parent,
.enable = rk3399_clk_enable,
 };
 
-- 
2.1.4

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

[U-Boot] [PATCH 5/5] rockchip: clk: rk3399: accept all assigned-clocks from the 'cru'-node

[Philipp Tomsich]

The RK3399 CRU-node assigns rates to a number of clocks that are not
implemented in the RK3399 clock-driver (but which have been
sufficiently initialised from rkclk_init()): for these clocks, we
simply ignore the set_rate() operation and return 0 to signal success.

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 
---

 drivers/clk/rockchip/clk_rk3399.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index e791936..e431ec8 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -883,6 +883,24 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
switch (clk->id) {
case 0 ... 63:
return 0;
+
+   case ACLK_PERIHP:
+   case HCLK_PERIHP:
+   case PCLK_PERIHP:
+   return 0;
+
+   case ACLK_PERILP0:
+   case HCLK_PERILP0:
+   case PCLK_PERILP0:
+   return 0;
+
+   case ACLK_CCI:
+   return 0;
+
+   case HCLK_PERILP1:
+   case PCLK_PERILP1:
+   return 0;
+
case HCLK_SDMMC:
case SCLK_SDMMC:
case SCLK_EMMC:
-- 
2.1.4

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

[U-Boot] [PATCH] spl: add option to disable SPL banner output

[Lukasz Majewski]

From: Anatolij Gustschin 

Selecting this option will reduce SPL boot time by approx. 6 ms
(e. g. with 70 bytes long banner string at 115200 baud).

Signed-off-by: Anatolij Gustschin 
Tested-by: Lukasz Majewski 
---

 common/spl/Kconfig | 7 +++
 common/spl/spl.c   | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index d686b1ecbd..d1f9cae6b7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -118,6 +118,13 @@ config SPL_SEPARATE_BSS
  location is used. Normally we put the device tree at the end of BSS
  but with this option enabled, it goes at _image_binary_end.
 
+config SPL_DISABLE_BANNER_PRINT
+   bool "Disable output of the SPL banner 'U-Boot SPL ...'"
+   help
+ If this option is enabled, SPL will not print the banner with version
+ info. Selecting this option could be useful to reduce SPL boot time
+ (e.g. approx. 6 ms slower, when output on i.MX6 with 1152000 baud).
+
 config SPL_DISPLAY_PRINT
bool "Display a board-specific message in SPL"
help
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963611..898c416a66 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -477,8 +477,10 @@ void preloader_console_init(void)
 
gd->have_console = 1;
 
+#ifndef CONFIG_SPL_DISABLE_BANNER_PRINT
puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
U_BOOT_TIME ")\n");
+#endif
 #ifdef CONFIG_SPL_DISPLAY_PRINT
spl_display_print();
 #endif
-- 
2.11.0

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

Re: [U-Boot] [PATCH] spl: add option to disable SPL banner output

[Dr. Philipp Tomsich]

> On 25 Jan 2018, at 18:37, Lukasz Majewski  wrote:
> 
> From: Anatolij Gustschin 
> 
> Selecting this option will reduce SPL boot time by approx. 6 ms
> (e. g. with 70 bytes long banner string at 115200 baud).
> 
> Signed-off-by: Anatolij Gustschin 
> Tested-by: Lukasz Majewski 

Reviewed-by: Philipp Tomsich 

See below for a nitpick.

> ---
> 
> common/spl/Kconfig | 7 +++
> common/spl/spl.c   | 2 ++
> 2 files changed, 9 insertions(+)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index d686b1ecbd..d1f9cae6b7 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -118,6 +118,13 @@ config SPL_SEPARATE_BSS
> location is used. Normally we put the device tree at the end of BSS
> but with this option enabled, it goes at _image_binary_end.
> 
> +config SPL_DISABLE_BANNER_PRINT
> + bool "Disable output of the SPL banner 'U-Boot SPL ...'"
> + help
> +   If this option is enabled, SPL will not print the banner with version
> +   info. Selecting this option could be useful to reduce SPL boot time
> +   (e.g. approx. 6 ms slower, when output on i.MX6 with 1152000 baud).

You seem to be off by “times 10” for the baud-rate.

> +
> config SPL_DISPLAY_PRINT
>   bool "Display a board-specific message in SPL"
>   help
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 76c1963611..898c416a66 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -477,8 +477,10 @@ void preloader_console_init(void)
> 
>   gd->have_console = 1;
> 
> +#ifndef CONFIG_SPL_DISABLE_BANNER_PRINT
>   puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
>   U_BOOT_TIME ")\n");
> +#endif
> #ifdef CONFIG_SPL_DISPLAY_PRINT
>   spl_display_print();
> #endif
> -- 
> 2.11.0
> 

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

[U-Boot] [PATCH v2] spl: add option to disable SPL banner output

[Lukasz Majewski]

From: Anatolij Gustschin 

Selecting this option will reduce SPL boot time by approx. 6 ms
(e. g. with 70 bytes long banner string at 115200 baud).

Signed-off-by: Anatolij Gustschin 
Tested-by: Lukasz Majewski 
Reviewed-by: Philipp Tomsich 
---

 common/spl/Kconfig | 7 +++
 common/spl/spl.c   | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index d686b1ecbd..d1f9cae6b7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -118,6 +118,13 @@ config SPL_SEPARATE_BSS
  location is used. Normally we put the device tree at the end of BSS
  but with this option enabled, it goes at _image_binary_end.
 
+config SPL_DISABLE_BANNER_PRINT
+   bool "Disable output of the SPL banner 'U-Boot SPL ...'"
+   help
+ If this option is enabled, SPL will not print the banner with version
+ info. Selecting this option could be useful to reduce SPL boot time
+ (e.g. approx. 6 ms slower, when output on i.MX6 with 115200 baud).
+
 config SPL_DISPLAY_PRINT
bool "Display a board-specific message in SPL"
help
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 76c1963611..898c416a66 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -477,8 +477,10 @@ void preloader_console_init(void)
 
gd->have_console = 1;
 
+#ifndef CONFIG_SPL_DISABLE_BANNER_PRINT
puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
U_BOOT_TIME ")\n");
+#endif
 #ifdef CONFIG_SPL_DISPLAY_PRINT
spl_display_print();
 #endif
-- 
2.11.0

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

Re: [U-Boot] [PATCH] spl: add option to disable SPL banner output

[Lukasz Majewski]

Hi Philipp,

> > On 25 Jan 2018, at 18:37, Lukasz Majewski  wrote:
> > 
> > From: Anatolij Gustschin 
> > 
> > Selecting this option will reduce SPL boot time by approx. 6 ms
> > (e. g. with 70 bytes long banner string at 115200 baud).
> > 
> > Signed-off-by: Anatolij Gustschin 
> > Tested-by: Lukasz Majewski   
> 
> Reviewed-by: Philipp Tomsich 
> 
> See below for a nitpick.
> 
> > ---
> > 
> > common/spl/Kconfig | 7 +++
> > common/spl/spl.c   | 2 ++
> > 2 files changed, 9 insertions(+)
> > 
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index d686b1ecbd..d1f9cae6b7 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -118,6 +118,13 @@ config SPL_SEPARATE_BSS
> >   location is used. Normally we put the device tree at the
> > end of BSS but with this option enabled, it goes at
> > _image_binary_end.
> > 
> > +config SPL_DISABLE_BANNER_PRINT
> > +   bool "Disable output of the SPL banner 'U-Boot SPL ...'"
> > +   help
> > + If this option is enabled, SPL will not print the banner
> > with version
> > + info. Selecting this option could be useful to reduce
> > SPL boot time
> > + (e.g. approx. 6 ms slower, when output on i.MX6 with
> > 1152000 baud).  
> 
> You seem to be off by “times 10” for the baud-rate.

Extra boost :-)

Fixed in v2. Thanks for spotting.

> 
> > +
> > config SPL_DISPLAY_PRINT
> > bool "Display a board-specific message in SPL"
> > help
> > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > index 76c1963611..898c416a66 100644
> > --- a/common/spl/spl.c
> > +++ b/common/spl/spl.c
> > @@ -477,8 +477,10 @@ void preloader_console_init(void)
> > 
> > gd->have_console = 1;
> > 
> > +#ifndef CONFIG_SPL_DISABLE_BANNER_PRINT
> > puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
> > U_BOOT_TIME ")\n");
> > +#endif
> > #ifdef CONFIG_SPL_DISPLAY_PRINT
> > spl_display_print();
> > #endif
> > -- 
> > 2.11.0
> >   
> 



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


pgpO0yrCuAdJs.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 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

[Alexander Graf]

On 01/22/2018 07:34 PM, Heinrich Schuchardt wrote:

The appended README explains how U-Boot and iPXE can be used
to boot a diskless system from an iSCSI SAN.

The maintainer for README.efi and README.iscsi is set.

Signed-off-by: Heinrich Schuchardt 
---
  MAINTAINERS  |   2 +
  doc/README.iscsi | 178 +++
  2 files changed, 180 insertions(+)
  create mode 100644 doc/README.iscsi

diff --git a/MAINTAINERS b/MAINTAINERS
index d459153503..6e94cee5d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -286,6 +286,8 @@ EFI PAYLOAD
  M:Alexander Graf 
  S:Maintained
  T:git git://github.com/agraf/u-boot.git
+F: doc/README.efi
+F: doc/README.iscsi
  F:include/efi*
  F:lib/efi*/
  F:test/py/tests/test_efi*
diff --git a/doc/README.iscsi b/doc/README.iscsi
new file mode 100644
index 00..f095ad1ddf
--- /dev/null
+++ b/doc/README.iscsi
@@ -0,0 +1,178 @@
+# iSCSI booting with U-Boot and iPXE
+
+## Motivation
+
+U-Boot has only a reduced set of supported network protocols. A major gap is
+the lack of a TCP stack.


This is only semi-true. There is work in progress to get TCP support 
into U-Boot. The protocols on top however are still missing and using 
iPXE here is definitely a very reasonable approach.



+
+For booting a diskless computer this leaves us with BOOTP or DHCP to get the
+address of a boot script. TFTP can be used to load the boot script and the
+operating system kernel and initial file system (initrd).
+
+These protocols are insecure. The client cannot validate the authenticity
+of the contacted servers. And the server cannot verify the identity of the
+client.
+
+Furthermore the services providing the operating system loader or kernel are
+not the ones that the operating system will use. Especially in a SAN 
environment
+this makes updating the operating system a hassle. After installing a new
+kernel version the boot files have to be copied to the TFTP server directory.
+
+The HTTPS protocol provides certificate based validation of servers. Sensitive
+data like passwords can be securely transmitted.
+
+The iSCSI protocol is used for connecting storage attached networks. It
+provides mutual authentication using the CHAP protocol. It typically runs on
+a TCP transport.
+
+Thus a better solution than DHCP/TFTP boot would be to load a boot script via
+HTTPS and to download any other files needed for booting via iSCSI.
+
+An alternative to implementing these protocols in U-Boot is to use an existing
+software that can run on top of U-Boot. iPXE is the "swiss army knife" of
+network booting. It supports both HTTPS and iSCSI. It has a script engine for
+fine grained control of the boot process and can provide a command shell.
+
+iPXE can be built as an EFI application (named snp.efi) which can be loaded and
+run by U-Boot.
+
+## Boot sequence
+
+U-Boot loads the EFI application iPXE snp.efi using the bootefi command. This
+application has network access via the simple network protocol offered by
+U-Boot.
+
+iPXE executes its internal script. This script may optionally chain load a
+secondary boot script via HTTPS or open a shell.
+
+For the further boot process iPXE connects to the iSCSI server. This includes
+the mutual authentication using the CHAP protocol. After the authentication 
iPXE
+has access to the iSCSI targets.
+
+For a selected iSCSI target iPXE sets up a handle with the block IO protocol. 
It
+uses the ConnectController boot service of U-Boot to request U-Boot to connect 
a
+file system driver. U-Boot reads from the iSCSI drive via the block IO protocol
+offered by iPXE. It creates the partition handles and install the simple file


installs


+protocol. Now iPXE can call the simple file protocol to load Grub. U-Boot uses
+the block IO protocol offered by iPXE to fulfill the request.
+
+Once Grub is started it uses the same simple file protocol to load Linux. Via


Are you sure grub uses the file system protocol? IIRC it uses block 
directly.



+the EFI stub Linux is called as an EFI application.
+
+```
+   ++  ++
+   || Runs ||
+   | U-Boot |=>| iPXE   |
+   | EFI|  | snp.efi|
+++ || DHCP ||
+||<||<=||
+| DHCP   | || Request  ||
+| Server | ||  ||
+||>||=>||
+++ || Response ||
+   ||  ||
+   ||  ||
+++ || HTTPS||
+||<||<=||
+| HTTPS  | || Request  ||
+| Server | ||  ||
+||>||=>||
+++ || Response ||
+   ||  

[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

[Alexey Brodkin]

In case of no relocation we'll just waste some paceat the very end
of usable memory area. If U-Boot is huge and we cannot use a lot of memory this
loss will be pretty inconvenient.

Signed-off-by: Alexey Brodkin 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Heiko Schocher 
Cc: York Sun 
Cc: Stefan Roese 
---
 common/board_f.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 92743089087e..d1662199a570 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -396,19 +396,21 @@ static int reserve_trace(void)
 
 static int reserve_uboot(void)
 {
-   /*
-* reserve memory for U-Boot code, data & bss
-* round down to next 4 kB limit
-*/
-   gd->relocaddr -= gd->mon_len;
-   gd->relocaddr &= ~(4096 - 1);
-#if defined(CONFIG_E500) || defined(CONFIG_MIPS)
-   /* round down to next 64 kB limit so that IVPR stays aligned */
-   gd->relocaddr &= ~(65536 - 1);
-#endif
-
-   debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10,
- gd->relocaddr);
+   if (!(gd->flags & GD_FLG_SKIP_RELOC)) {
+   /*
+* reserve memory for U-Boot code, data & bss
+* round down to next 4 kB limit
+*/
+   gd->relocaddr -= gd->mon_len;
+   gd->relocaddr &= ~(4096 - 1);
+   #if defined(CONFIG_E500) || defined(CONFIG_MIPS)
+   /* round down to next 64 kB limit so that IVPR stays aligned */
+   gd->relocaddr &= ~(65536 - 1);
+   #endif
+
+   debug("Reserving %ldk for U-Boot at: %08lx\n",
+ gd->mon_len >> 10, gd->relocaddr);
+   }
 
gd->start_addr_sp = gd->relocaddr;
 
-- 
2.14.3

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

[U-Boot] [PATCH] arc: Get rid of handwritten string routines

[Alexey Brodkin]

U-Boot is a bit special piese of software because it is being
only executed once on power-on as compared to operating system
for example. That's why we don't care much about performance
optimizations instead we're more concerned about size. And up-to-date
compilers might produce much smaller code compared to
performance-optimized routines copy-pasted from the Linux kernel.

Here's an example:
--->8--
--- size_asm_strings.txt
+++ size_c_strings.txt
@@ -1,2 +1,2 @@
text   data bss dec hex filename
- 121260   37843308  128352   1f560 u-boot
+ 120448   37843308  127540   1f234 u-boot
--->8--

See we were able to shave off ~800 bytes of .text section.

Also usage of string routines implemented in C gives us an ability
to support more HW flavors for free: generated instructions will match
our target as long as correct compiler option is used.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/include/asm/string.h |  26 
 arch/arc/lib/Makefile |   7 ---
 arch/arc/lib/memcmp.S | 123 
 arch/arc/lib/memcpy-700.S |  63 ---
 arch/arc/lib/memset.S |  62 ---
 arch/arc/lib/strchr-700.S | 141 --
 arch/arc/lib/strcmp.S |  97 -
 arch/arc/lib/strcpy-700.S |  67 
 arch/arc/lib/strlen.S |  80 
 9 files changed, 666 deletions(-)
 delete mode 100644 arch/arc/lib/memcmp.S
 delete mode 100644 arch/arc/lib/memcpy-700.S
 delete mode 100644 arch/arc/lib/memset.S
 delete mode 100644 arch/arc/lib/strchr-700.S
 delete mode 100644 arch/arc/lib/strcmp.S
 delete mode 100644 arch/arc/lib/strcpy-700.S
 delete mode 100644 arch/arc/lib/strlen.S

diff --git a/arch/arc/include/asm/string.h b/arch/arc/include/asm/string.h
index 909129c33318..8b137891791f 100644
--- a/arch/arc/include/asm/string.h
+++ b/arch/arc/include/asm/string.h
@@ -1,27 +1 @@
-/*
- * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. All rights reserved.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
 
-#ifndef __ASM_ARC_STRING_H
-#define __ASM_ARC_STRING_H
-
-#define __HAVE_ARCH_MEMSET
-#define __HAVE_ARCH_MEMCPY
-#define __HAVE_ARCH_MEMCMP
-#define __HAVE_ARCH_STRCHR
-#define __HAVE_ARCH_STRCPY
-#define __HAVE_ARCH_STRCMP
-#define __HAVE_ARCH_STRLEN
-
-extern void *memset(void *ptr, int, __kernel_size_t);
-extern void *memcpy(void *, const void *, __kernel_size_t);
-extern void memzero(void *ptr, __kernel_size_t n);
-extern int memcmp(const void *, const void *, __kernel_size_t);
-extern char *strchr(const char *s, int c);
-extern char *strcpy(char *dest, const char *src);
-extern int strcmp(const char *cs, const char *ct);
-extern __kernel_size_t strlen(const char *);
-
-#endif /* __ASM_ARC_STRING_H */
diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile
index 12097bf3bee7..6b7fb0fdff9c 100644
--- a/arch/arc/lib/Makefile
+++ b/arch/arc/lib/Makefile
@@ -10,13 +10,6 @@ obj-y += cache.o
 obj-y += cpu.o
 obj-y += interrupts.o
 obj-y += relocate.o
-obj-y += strchr-700.o
-obj-y += strcmp.o
-obj-y += strcpy-700.o
-obj-y += strlen.o
-obj-y += memcmp.o
-obj-y += memcpy-700.o
-obj-y += memset.o
 obj-y += reset.o
 obj-y += ints_low.o
 obj-y += init_helpers.o
diff --git a/arch/arc/lib/memcmp.S b/arch/arc/lib/memcmp.S
deleted file mode 100644
index 87bccab51d74..
--- a/arch/arc/lib/memcmp.S
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * Copyright (C) 2004, 2007-2010, 2011-2014 Synopsys, Inc. All rights reserved.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifdef __LITTLE_ENDIAN__
-#define WORD2 r2
-#define SHIFT r3
-#else /* __BIG_ENDIAN__ */
-#define WORD2 r3
-#define SHIFT r2
-#endif /* _ENDIAN__ */
-
-.global memcmp
-.align 4
-memcmp:
-   or  %r12, %r0, %r1
-   asl_s   %r12, %r12, 30
-   sub %r3, %r2, 1
-   brls%r2, %r12, .Lbytewise
-   ld  %r4, [%r0, 0]
-   ld  %r5, [%r1, 0]
-   lsr.f   %lp_count, %r3, 3
-   lpne.Loop_end
-   ld_sWORD2, [%r0, 4]
-   ld_s%r12, [%r1, 4]
-   brne%r4, %r5, .Leven
-   ld.a%r4, [%r0, 8]
-   ld.a%r5, [%r1, 8]
-   brneWORD2, %r12, .Lodd
-   nop
-.Loop_end:
-   asl_s   SHIFT, SHIFT, 3
-   bhs_s   .Last_cmp
-   brne%r4, %r5, .Leven
-   ld  %r4, [%r0, 4]
-   ld  %r5, [%r1, 4]
-#ifdef __LITTLE_ENDIAN__
-   nop_s
-   /* one more load latency cycle */
-.Last_cmp:
-   xor %r0, %r4, %r5
-   bset%r0, %r0, SHIFT
-   sub_s   %r1, %r0, 1
-   bic_s   %r1, %r1, %r0
-   norm%r1, %r1
-   b.d .Leven_cmp
-   and %r1, %r1, 24
-.Leven:
-   xor %r0, %r4, %r5
-   sub_s   %r1, %r0, 1
-   bic_s   %r1, %r1, %r0
-   norm%r1, %r1
-  

[U-Boot] [PATCH] arc: Don't halt slaves

[Alexey Brodkin]

This commit basically reverts two previous commits:
 1. cf628f772ef2 ("arc: arcv1: Disable master/slave check")
 2. 6cba327bd96f ("arcv2: Halt non-master cores")

With mentioned commits in-place we experience more trouble than
benefits. In case of SMP Linux kernel this is really required as
we have all the cores running from the very beginning and then we
need to allow master core to do some preparatory work while slaves
are not getting in the way.

In case of U-Boot we:
 a) Don't really run more than 1 core in parallel
 b) We may use whatever core for that

Signed-off-by: Alexey Brodkin 
---
 arch/arc/lib/start.S | 20 
 1 file changed, 20 deletions(-)

diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index 5098db9286fd..0d9c85741447 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -11,26 +11,6 @@
 #include 
 
 ENTRY(_start)
-; ARCompact devices are not supposed to be SMP so master/slave check
-; makes no sense.
-#ifdef CONFIG_ISA_ARCV2
-   ; Non-masters will be halted immediately, they might be kicked later
-   ; by platform code right before passing control to the Linux kernel
-   ; in bootm.c:boot_jump_linux().
-   lr  r5, [identity]
-   lsr r5, r5, 8
-   bmskr5, r5, 7
-   cmp r5, 0
-   mov.nz  r0, r5
-   bz  .Lmaster_proceed
-   flag1
-   nop
-   nop
-   nop
-
-.Lmaster_proceed:
-#endif
-
/* Setup interrupt vector base that matches "__text_start" */
sr  __ivt_start, [ARC_AUX_INTR_VEC_BASE]
 
-- 
2.14.3

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

[U-Boot] [PATCH] arc: Eliminate unused code and data with GCC's garbage collector

[Alexey Brodkin]

Finally GCC's garbage collector works on ARC so let's use it.
That's what I may see for HSDK:

Before:
   textdata bss dec hex filename
 290153   10068  222616  522837   7fa55 u-boot

After:
   textdata bss dec hex filename
 2619999460  222360  493819   788fb u-boot

Overall ~5% of memory footprint saved.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/config.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arc/config.mk b/arch/arc/config.mk
index 13676bd0c8e1..a19c188dbcfa 100644
--- a/arch/arc/config.mk
+++ b/arch/arc/config.mk
@@ -51,9 +51,10 @@ PLATFORM_CPPFLAGS += -mcpu=archs
 endif
 
 PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2
+PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
 
 # Needed for relocation
-LDFLAGS_FINAL += -pie
+LDFLAGS_FINAL += -pie --gc-sections
 
 # Load address for standalone apps
 CONFIG_STANDALONE_LOAD_ADDR ?= 0x8200
-- 
2.14.3

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

[U-Boot] [PATCH] arc: Introduce a possibility to not relocate U-boot

[Alexey Brodkin]

From: Alexey Brodkin 

Disabling relocation might be useful on ARC for 2 reasons:
 a) For advanced debugging with Synopsys proprietary MetaWare debugger
which is capable of accessing much more specific hardware resources
compared to gdb. For example it may show contents of L1 and L2 caches,
internal states of some hardware blocks etc.

But on the downside MetaWare debugger still cannot work with PIE.
Even though that limitation could be work-arounded with change of ELF's
header and stripping down all debug info but with it we won't have
debug info for source-level debugging which is quite inconvenient.

 b) Some platforms which might benefit from usage of U-Boot basically
don't have enough RAM to accommodate relocation of U-Boot so we
keep code in flash and use as much of RAM as possible for more
interesting things.

Signed-off-by: Alexey Brodkin 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Heiko Schocher 
Cc: York Sun 
Cc: Stefan Roese 
---
 arch/arc/lib/relocate.c | 6 ++
 arch/arc/lib/start.S| 8 +++-
 common/board_f.c| 3 ++-
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arc/lib/relocate.c b/arch/arc/lib/relocate.c
index 7802f4054594..96b4bd3d8fa6 100644
--- a/arch/arc/lib/relocate.c
+++ b/arch/arc/lib/relocate.c
@@ -17,6 +17,9 @@ int copy_uboot_to_ram(void)
 {
size_t len = (size_t)&__image_copy_end - (size_t)&__image_copy_start;
 
+   if (gd->flags & GD_FLG_SKIP_RELOC)
+   return 0;
+
memcpy((void *)gd->relocaddr, (void *)&__image_copy_start, len);
 
return 0;
@@ -40,6 +43,9 @@ int do_elf_reloc_fixups(void)
Elf32_Rela *re_src = (Elf32_Rela *)(&__rel_dyn_start);
Elf32_Rela *re_end = (Elf32_Rela *)(&__rel_dyn_end);
 
+   if (gd->flags & GD_FLG_SKIP_RELOC)
+   return 0;
+
debug("Section .rela.dyn is located at %08x-%08x\n",
  (unsigned int)re_src, (unsigned int)re_end);
 
diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index ac9944c4cf32..c78dd001d81d 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -78,7 +78,13 @@ ENTRY(_start)
 
/* Zero the one and only argument of "board_init_f" */
mov_s   %r0, 0
-   j   board_init_f
+   bl  board_init_f
+
+   /* We only get here if relocation is disabled by GD_FLG_SKIP_RELOC */
+   /* Make sure we don't lose GD overwritten by zero new GD */
+   mov %r0, %r25
+   mov %r1, 0
+   bl  board_init_r
 ENDPROC(_start)
 
 /*
diff --git a/common/board_f.c b/common/board_f.c
index 7bfc73e8bca0..48c98d1a71af 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -904,7 +904,8 @@ void board_init_f(ulong boot_flags)
hang();
 
 #if !defined(CONFIG_ARM) && !defined(CONFIG_SANDBOX) && \
-   !defined(CONFIG_EFI_APP) && !CONFIG_IS_ENABLED(X86_64)
+   !defined(CONFIG_EFI_APP) && !CONFIG_IS_ENABLED(X86_64) && \
+   !defined(CONFIG_ARC)
/* NOTREACHED - jump_to_copy() does not return */
hang();
 #endif
-- 
2.14.3

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

[U-Boot] [BUG] 0001-mmc-fix-the-wrong-disabling-clock.patch

[Heinrich Schuchardt]

With git master HEAD the Odroid C2 hangs after the command line countdown.

Bisecting teaches that this is the patch causing the problem:

9546eb92cb648a8bba0aa9d5930ac751e6e5b9a4
mmc: fix the wrong disabling clock

Please, revert the patch.

I could not find the patch in
https://lists.denx.de/pipermail/u-boot/2018-January/date.html

http://patchwork.ozlabs.org/patch/864607/
seems to be related but does not solve the issue.

Best regards

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

Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

[Duncan Hare]

> - Forwarded Message -
>  From: Alexander Graf 
>  To: Heinrich Schuchardt  

> > The appended README explains how U-Boot and iPXE can be used
> > to boot a diskless system from an iSCSI SAN.
> >
> > The maintainer for README.efi and README.iscsi is set.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> +U-Boot has only a reduced set of supported network protocols. A
> major gap is
> > major gap is +the lack of a TCP stack.  
> 
> This is only semi-true. There is work in progress to get TCP support 
> into U-Boot. The protocols on top however are still missing and using 
> iPXE here is definitely a very reasonable approach.

We are implementeinga limited TCP and a wget (http 1.0) app.
It is almost ready for an test release. Selective Acknowledgment (SACK)
is under test as a final piece of the TCP stack.

We have noticed that omitting the http 1.0 declaration in
downloading the kernel from an nginx web server that we remove the
overhead of an http header completely.

> 
> > +
> > +For booting a diskless computer this leaves us with BOOTP or DHCP
> > to get the +address of a boot script. TFTP can be used to load the
> > boot script and the +operating system kernel and initial file
> > system (initrd). 

We use DHCP or DNS. DHCP assumes one has control of the DHCP server and
are generally inside the firewall, and is complex to adminsited is
there are many (branch office) DHCP servers. With MS 2012 R2 server
configuring DHCP options is complex.

> > +These protocols are insecure. The client cannot validate the
> > authenticity +of the contacted servers. And the server cannot
> > verify the identity of the +client.

Yes and no. We (optionally) use the burnt in MAC address or serial
number to identify a client machine, and can prevent boot if it is not
authorized by denying the download of the *nix kernel. If inside 
the firewall and using DHCP security is probably completly under
the control of the enterprise admins. We use locally
administered DNS servers to control address resolution under DNS.

> > iPXE is the
> > "swiss army knife" of +network booting. It supports both HTTPS and
> > iSCSI. It has a script engine for +fine grained control of the boot
> > process and can provide a command shell. +

(1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex)
or
(2)u-boot (+ missing functions)->kernel?

> > +protocol. Now iPXE can call the simple file protocol to load Grub.

I seem to be missing the point. We use U-boot to load and run
the kernel with tcp+http 1.0. https would be a nice enhancement, as
would an encrypted connection for the *nix kernel to access the image,
but complete security requires more.

If you are going to do this we need to discuss accessing the *nix
image over a secure protocol. AFAIK the *nix kernel does not
use secure protocols with network *nix images.

In the netboot process we'd address the performance limitations of NFS, 
especially during boot, with either lookahead caching at the client or
use HTTPS for image access, both of which are outside u-boot's scope.



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

[U-Boot] [PATCH] usb: ehci: mxs: fix swapped argument in ehci_writel()

[Daniel Schwierzeck]

ehci_writel() swaps the arguments for address and value. One call
in ehci-mxs ignores that.

This fixes the warning:

drivers/usb/host/ehci-mxs.c: In function ?ehci_hcd_stop?:
drivers/usb/host/ehci-mxs.c:159:19: error: initialization makes integer from 
pointer without a cast [-Werror=int-conversion]
  ehci_writel(tmp, >or_usbcmd);
   ^
arch/arm/include/asm/io.h:117:34: note: in definition of macro ?writel?
 #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
  ^
drivers/usb/host/ehci-mxs.c:159:2: note: in expansion of macro ?ehci_writel?
  ^~~

Signed-off-by: Daniel Schwierzeck 

---

 drivers/usb/host/ehci-mxs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 6b8d969bb0..9872415562 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -156,7 +156,7 @@ int ehci_hcd_stop(int index)
 
tmp = ehci_readl(>or_usbcmd);
tmp &= ~CMD_RUN;
-   ehci_writel(tmp, >or_usbcmd);
+   ehci_writel(>or_usbcmd, tmp);
 
/* Disable the PHY */
tmp = USBPHY_PWD_RXPWDRX | USBPHY_PWD_RXPWDDIFF |
-- 
2.16.1

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

[U-Boot] [PATCH v2 1/5] clk: add clk_set_parent()

[Philipp Tomsich]

Clocks may support multiple parents: this change introduces an
optional operation on the clk-uclass to set a clock's parent.

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 

---

Changes in v2:
- Fixed David's email address.

 drivers/clk/clk-uclass.c | 12 
 include/clk-uclass.h |  8 
 include/clk.h| 11 +++
 3 files changed, 31 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index fbea720..20ee0c5 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -188,6 +188,18 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
return ops->set_rate(clk, rate);
 }
 
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   const struct clk_ops *ops = clk_dev_ops(clk->dev);
+
+   debug("%s(clk=%p, parent=%p)\n", __func__, clk, parent);
+
+   if (!ops->set_parent)
+   return -ENOSYS;
+
+   return ops->set_parent(clk, parent);
+}
+
 int clk_enable(struct clk *clk)
 {
const struct clk_ops *ops = clk_dev_ops(clk->dev);
diff --git a/include/clk-uclass.h b/include/clk-uclass.h
index e7ea334..75933eb 100644
--- a/include/clk-uclass.h
+++ b/include/clk-uclass.h
@@ -78,6 +78,14 @@ struct clk_ops {
 */
ulong (*set_rate)(struct clk *clk, ulong rate);
/**
+* set_parent() - Set current clock parent
+*
+* @clk:The clock to manipulate.
+* @parent: New clock parent.
+* @return zero on success, or -ve error code.
+*/
+   int (*set_parent)(struct clk *clk, struct clk *parent);
+   /**
 * enable() - Enable a clock.
 *
 * @clk:The clock to manipulate.
diff --git a/include/clk.h b/include/clk.h
index e7ce3e8..e463d8e 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -178,6 +178,17 @@ ulong clk_get_rate(struct clk *clk);
 ulong clk_set_rate(struct clk *clk, ulong rate);
 
 /**
+ * clk_set_parent() - Set current clock parent.
+ *
+ * @clk:   A clock struct that was previously successfully requested by
+ * clk_request/get_by_*().
+ * @parent:A clock struct that was previously successfully requested by
+ * clk_request/get_by_*().
+ * @return new rate, or -ve error code.
+ */
+int clk_set_parent(struct clk *clk, struct clk *parent);
+
+/**
  * clk_enable() - Enable (turn on) a clock.
  *
  * @clk:   A clock struct that was previously successfully requested by
-- 
2.1.4

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

[U-Boot] [PATCH v2 2/5] clk: refactor clk_get_by_index() into clk_get_by_indexed_prop()

[Philipp Tomsich]

The logic in clk_get_by_index() may be useful for other properties
than 'clocks': e.g. 'assigned-clocks' and 'assigned-clock-parents'
follows the same model.

This commit refactors clk_get_by_index() by introducing an internal
function clk_get_by_indexed_prop() that allows to specify the name
of the property to process.  The original clk_get_by_index() call
is simply directed through this helper function with the property
name fixed to "clocks".

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 

---

Changes in v2:
- Fixed David's email address.

 drivers/clk/clk-uclass.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 20ee0c5..7fdf16d 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -53,7 +53,8 @@ static int clk_of_xlate_default(struct clk *clk,
return 0;
 }
 
-int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
+static int clk_get_by_indexed_prop(struct udevice *dev, const char *prop_name,
+  int index, struct clk *clk)
 {
int ret;
struct ofnode_phandle_args args;
@@ -65,7 +66,7 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk)
assert(clk);
clk->dev = NULL;
 
-   ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
+   ret = dev_read_phandle_with_args(dev, prop_name, "#clock-cells", 0,
 index, );
if (ret) {
debug("%s: fdtdec_parse_phandle_with_args failed: err=%d\n",
@@ -95,6 +96,11 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk)
 
return clk_request(dev_clk, clk);
 }
+
+int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
+{
+   return clk_get_by_indexed_prop(dev, "clocks", index, clk);
+}
 # endif /* OF_PLATDATA */
 
 int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
-- 
2.1.4

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

[U-Boot] [PATCH v2 5/5] rockchip: clk: rk3399: accept all assigned-clocks from the 'cru'-node

[Philipp Tomsich]

The RK3399 CRU-node assigns rates to a number of clocks that are not
implemented in the RK3399 clock-driver (but which have been
sufficiently initialised from rkclk_init()): for these clocks, we
simply ignore the set_rate() operation and return 0 to signal success.

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 

---

Changes in v2:
- Fixed David's email address.

 drivers/clk/rockchip/clk_rk3399.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index e791936..e431ec8 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -883,6 +883,24 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
switch (clk->id) {
case 0 ... 63:
return 0;
+
+   case ACLK_PERIHP:
+   case HCLK_PERIHP:
+   case PCLK_PERIHP:
+   return 0;
+
+   case ACLK_PERILP0:
+   case HCLK_PERILP0:
+   case PCLK_PERILP0:
+   return 0;
+
+   case ACLK_CCI:
+   return 0;
+
+   case HCLK_PERILP1:
+   case PCLK_PERILP1:
+   return 0;
+
case HCLK_SDMMC:
case SCLK_SDMMC:
case SCLK_EMMC:
-- 
2.1.4

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

[U-Boot] [PATCH v2 4/5] clk: implement clk_set_defaults()

[Philipp Tomsich]

Linux uses the properties 'assigned-clocks', 'assigned-clock-parents'
and 'assigned-clock-rates' to configure the clock subsystem for use
with various peripheral nodes.

This implements clk_set_defaults() and hooks it up with the general
device probibin in drivers/core/device.c: when a new device is probed,
clk_set_defaults() will be called for it and will process the
properties mentioned above.

Note that this functionality is designed to fail gracefully (i.e. if a
clock-driver does not implement set_parent(), we simply accept this
and ignore the error) as not to break existing board-support.

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 

---

Changes in v2:
- Fixed David's email address.

 drivers/clk/clk-uclass.c | 118 +++
 drivers/core/device.c|   6 +++
 include/clk.h|  17 +++
 3 files changed, 141 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 7fdf16d..ad76379 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -2,6 +2,7 @@
  * Copyright (C) 2015 Google, Inc
  * Written by Simon Glass 
  * Copyright (c) 2016, NVIDIA CORPORATION.
+ * Copyright (c) 2018, Theobroma Systems Design und Consulting GmbH
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -10,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -101,6 +103,122 @@ int clk_get_by_index(struct udevice *dev, int index, 
struct clk *clk)
 {
return clk_get_by_indexed_prop(dev, "clocks", index, clk);
 }
+
+static int clk_set_default_parents(struct udevice *dev)
+{
+   struct clk clk, parent_clk;
+   int index;
+   int num_parents;
+   int ret;
+
+   num_parents = dev_count_phandle_with_args(dev, "assigned-clock-parents",
+ "#clock-cells");
+   if (num_parents < 0) {
+   debug("%s: could not read assigned-clock-parents for %p\n",
+ __func__, dev);
+   return 0;
+   }
+
+   for (index = 0; index < num_parents; index++) {
+   ret = clk_get_by_indexed_prop(dev, "assigned-clock-parents",
+ index, _clk);
+   if (ret) {
+   debug("%s: could not get parent clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   return ret;
+   }
+
+   ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
+ index, );
+   if (ret) {
+   debug("%s: could not get assigned clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   return ret;
+   }
+
+   ret = clk_set_parent(, _clk);
+
+   /*
+* Not all drivers may support clock-reparenting (as of now).
+* Ignore errors due to this.
+*/
+   if (ret == -ENOSYS)
+   continue;
+
+   if (ret) {
+   debug("%s: failed to reparent clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static int clk_set_default_rates(struct udevice *dev)
+{
+   struct clk clk;
+   int index;
+   int num_rates;
+   int size;
+   int ret = 0;
+   u32 *rates = NULL;
+
+   size = dev_read_size(dev, "assigned-clock-rates");
+   if (size < 0)
+   return 0;
+
+   num_rates = size / sizeof(u32);
+   rates = calloc(num_rates, sizeof(u32));
+   if (!rates)
+   return -ENOMEM;
+
+   ret = dev_read_u32_array(dev, "assigned-clock-rates", rates, num_rates);
+   if (ret)
+   goto fail;
+
+   for (index = 0; index < num_rates; index++) {
+   ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
+ index, );
+   if (ret) {
+   debug("%s: could not get assigned clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   continue;
+   }
+
+   ret = clk_set_rate(, rates[index]);
+   if (ret < 0) {
+   debug("%s: failed to set rate on clock %d for %s\n",
+ __func__, index, dev_read_name(dev));
+   break;
+   }
+   }
+
+fail:
+   free(rates);
+   return ret;
+}
+
+int clk_set_defaults(struct udevice *dev)
+{
+   int ret;
+
+   /* If this is running pre-reloc state, don't take any action. */
+   if (!(gd->flags & GD_FLG_RELOC))
+   return 0;
+
+   debug("%s(%s)\n", 

[U-Boot] [PATCH v2 3/5] rockchip: clk: rk3399: implement set_parent() operation

[Philipp Tomsich]

This implements the (newly added) set_parent() operation for the
RK3399 with a focus on allowing the RGMII clock parent to be
configured via the assigned-clock-parents property of the GMAC node.

This implementation supports only the GMAC (in fact only the RGMII
clock parent) and allows to set this clock's parent either to the
internal SCLK_GMAC or to an external clock input (identifiable by it
providing a 'clock-output-name' of "gmac_clkin").

Signed-off-by: Philipp Tomsich 
Tested-by: David Wu 

---

Changes in v2:
- Fixed David's email address.

 drivers/clk/rockchip/clk_rk3399.c | 74 +--
 1 file changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 2f4c4e3..e791936 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -742,6 +742,30 @@ static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
return rk3399_mmc_get_clk(cru, clk_id);
 }
 
+static ulong rk3399_gmac_set_clk(struct rk3399_cru *cru, ulong rate)
+{
+   ulong ret;
+
+   /*
+* The RGMII CLK can be derived either from an external "clkin"
+* or can be generated from internally by a divider from SCLK_MAC.
+*/
+   if (readl(>clksel_con[19]) & BIT(4)) {
+   /* An external clock will always generate the right rate... */
+   ret = rate;
+   } else {
+   /*
+* No platform uses an internal clock to date.
+* Implement this once it becomes necessary and print an error
+* if someone tries to use it (while it remains unimplemented).
+*/
+   pr_err("%s: internal clock is UNIMPLEMENTED\n", __func__);
+   ret = 0;
+   }
+
+   return ret;
+}
+
 #define PMUSGRF_DDR_RGN_CON16 0xff330040
 static ulong rk3399_ddr_set_clk(struct rk3399_cru *cru,
ulong set_rate)
@@ -865,8 +889,7 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
ret = rk3399_mmc_set_clk(priv->cru, clk->id, rate);
break;
case SCLK_MAC:
-   /* nothing to do, as this is an external clock */
-   ret = rate;
+   ret = rk3399_gmac_set_clk(priv->cru, rate);
break;
case SCLK_I2C1:
case SCLK_I2C2:
@@ -902,6 +925,52 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
return ret;
 }
 
+static int rk3399_gmac_set_parent(struct clk *clk, struct clk *parent)
+{
+   struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
+   const char *clock_output_name;
+   int ret;
+
+   /*
+* If the requested parent is in the same clock-controller and
+* the id is SCLK_MAC ("clk_gmac"), switch to the internal clock.
+*/
+   if ((parent->dev == clk->dev) && (parent->id == SCLK_MAC)) {
+   debug("%s: switching RGMII to SCLK_MAC\n", __func__);
+   rk_clrreg(>cru->clksel_con[19], BIT(4));
+   return 0;
+   }
+
+   /*
+* Otherwise, we need to check the clock-output-names of the
+* requested parent to see if the requested id is "clkin_gmac".
+*/
+   ret = dev_read_string_index(parent->dev, "clock-output-names",
+   parent->id, _output_name);
+   if (ret < 0)
+   return -ENODATA;
+
+   /* If this is "clkin_gmac", switch to the external clock input */
+   if (!strcmp(clock_output_name, "clkin_gmac")) {
+   debug("%s: switching RGMII to CLKIN\n", __func__);
+   rk_setreg(>cru->clksel_con[19], BIT(4));
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
+static int rk3399_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   switch (clk->id) {
+   case SCLK_RMII_SRC:
+   return rk3399_gmac_set_parent(clk, parent);
+   }
+
+   debug("%s: unsupported clk %ld\n", __func__, clk->id);
+   return -ENOENT;
+}
+
 static int rk3399_clk_enable(struct clk *clk)
 {
switch (clk->id) {
@@ -919,6 +988,7 @@ static int rk3399_clk_enable(struct clk *clk)
 static struct clk_ops rk3399_clk_ops = {
.get_rate = rk3399_clk_get_rate,
.set_rate = rk3399_clk_set_rate,
+   .set_parent = rk3399_clk_set_parent,
.enable = rk3399_clk_enable,
 };
 
-- 
2.1.4

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

[U-Boot] [PATCH v2 0/5] clk: support assigned-clock, assigned-clock-parents, assigned-clock-rates

[Philipp Tomsich]

For various peripherals on Rockchip SoCs (e.g. for the Ethernet GMAC),
the parent-clock needs to be set via the DTS.  This adds the required
plumbing and implements the GMAC case for the RK3399.

Changes in v2:
- Fixed David's email address.


Philipp Tomsich (5):
  clk: add clk_set_parent()
  clk: refactor clk_get_by_index() into clk_get_by_indexed_prop()
  rockchip: clk: rk3399: implement set_parent() operation
  clk: implement clk_set_defaults()
  rockchip: clk: rk3399: accept all assigned-clocks from the 'cru'-node

 drivers/clk/clk-uclass.c  | 140 +-
 drivers/clk/rockchip/clk_rk3399.c |  92 -
 drivers/core/device.c |   6 ++
 include/clk-uclass.h  |   8 +++
 include/clk.h |  28 
 5 files changed, 270 insertions(+), 4 deletions(-)

-- 
2.1.4

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

[U-Boot] [PATCH] omap3_logic: Clean up I2C pin muxing.

[Adam Ford]

The SOM has external pull-up resistors, so let's turn these off.
It was helping reduce some errors when running I2C1 @ 2.6MHz.

Signed-off-by: Adam Ford 

diff --git a/board/logicpd/omap3som/omap3logic.h 
b/board/logicpd/omap3som/omap3logic.h
index 22d7760..7376119 100644
--- a/board/logicpd/omap3som/omap3logic.h
+++ b/board/logicpd/omap3som/omap3logic.h
@@ -229,17 +229,17 @@ void set_muxconf_regs(void)
MUX_VAL(CP(HSUSB0_DATA6), (IEN  | PTD | DIS | M0)); /*HSUSB0_DATA6*/
MUX_VAL(CP(HSUSB0_DATA7), (IEN  | PTD | DIS | M0)); /*HSUSB0_DATA7*/
 
-   MUX_VAL(CP(I2C1_SCL), (IEN  | PTU | EN  | M0)); /*I2C1_SCL*/
-   MUX_VAL(CP(I2C1_SDA), (IEN  | PTU | EN  | M0)); /*I2C1_SDA*/
+   MUX_VAL(CP(I2C1_SCL), (IEN  | EN  | M0)); /*I2C1_SCL*/
+   MUX_VAL(CP(I2C1_SDA), (IEN  | EN  | M0)); /*I2C1_SDA*/
 
-   MUX_VAL(CP(I2C2_SCL), (IEN  | PTU | EN  | M0)); /*I2C2_SCL*/
-   MUX_VAL(CP(I2C2_SDA), (IEN  | PTU | EN  | M0)); /*I2C2_SDA*/
+   MUX_VAL(CP(I2C2_SCL), (IEN  | EN  | M0)); /*I2C2_SCL*/
+   MUX_VAL(CP(I2C2_SDA), (IEN  | EN  | M0)); /*I2C2_SDA*/
 
-   MUX_VAL(CP(I2C3_SCL), (IEN  | PTU | EN  | M0)); /*I2C3_SCL*/
-   MUX_VAL(CP(I2C3_SDA), (IEN  | PTU | EN  | M0)); /*I2C3_SDA*/
+   MUX_VAL(CP(I2C3_SCL), (IEN  | EN  | M0)); /*I2C3_SCL*/
+   MUX_VAL(CP(I2C3_SDA), (IEN  | EN  | M0)); /*I2C3_SDA*/
 
-   MUX_VAL(CP(I2C4_SCL), (IEN  | PTU | EN  | M0)); /*I2C4_SCL*/
-   MUX_VAL(CP(I2C4_SDA), (IEN  | PTU | EN  | M0)); /*I2C4_SDA*/
+   MUX_VAL(CP(I2C4_SCL), (IEN  | EN  | M0)); /*I2C4_SCL*/
+   MUX_VAL(CP(I2C4_SDA), (IEN  | EN  | M0)); /*I2C4_SDA*/
 
MUX_VAL(CP(HDQ_SIO), (IEN  | PTU | EN  | M0)); /*HDQ_SIO*/
 
-- 
2.7.4

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

[U-Boot] SquashFS and FIT images

[Bishop, Mark (STRT)]

Is it possible to specify squashFS images in an .its file?  If so, anyone have 
an example or a pointer to the docs I've been searching for?

Mark Bishop
Sr. Firmware/Software Engineer - Microwave Subsystems

[cid:image001.png@01D281ED.A45F0A90]

4726 Eisenhower Blvd.
Tampa, FL 33634
USA


T  +1 813 901 7293

mbis...@smithsinterconnectinc.com

smithsinterconnect.com

TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!





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

Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

[Heinrich Schuchardt]

On 01/25/2018 08:39 PM, Duncan Hare wrote:
>> - Forwarded Message -
>>  From: Alexander Graf 
>>  To: Heinrich Schuchardt  
> 
>>> The appended README explains how U-Boot and iPXE can be used
>>> to boot a diskless system from an iSCSI SAN.
>>>
>>> The maintainer for README.efi and README.iscsi is set.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>> +U-Boot has only a reduced set of supported network protocols. A
>> major gap is
>>> major gap is +the lack of a TCP stack.  
>>
>> This is only semi-true. There is work in progress to get TCP support 
>> into U-Boot. The protocols on top however are still missing and using 
>> iPXE here is definitely a very reasonable approach.
> 
> We are implementeinga limited TCP and a wget (http 1.0) app.
> It is almost ready for an test release. Selective Acknowledgment (SACK)
> is under test as a final piece of the TCP stack.
> 
> We have noticed that omitting the http 1.0 declaration in
> downloading the kernel from an nginx web server that we remove the
> overhead of an http header completely.
> 
>>
>>> +
>>> +For booting a diskless computer this leaves us with BOOTP or DHCP
>>> to get the +address of a boot script. TFTP can be used to load the
>>> boot script and the +operating system kernel and initial file
>>> system (initrd). 
> 
> We use DHCP or DNS. DHCP assumes one has control of the DHCP server and
> are generally inside the firewall, and is complex to adminsited is
> there are many (branch office) DHCP servers. With MS 2012 R2 server
> configuring DHCP options is complex.
> 
>>> +These protocols are insecure. The client cannot validate the
>>> authenticity +of the contacted servers. And the server cannot
>>> verify the identity of the +client.
> 
> Yes and no. We (optionally) use the burnt in MAC address or serial
> number to identify a client machine, and can prevent boot if it is not
> authorized by denying the download of the *nix kernel.

A MAC adress can easily be spoofed. So an unauthorized system can
download the initram file system to obtain secret data like /etc/shadow.

Without DNSsec the client cannot be sure to whom he is talking.

 If inside
> the firewall and using DHCP security is probably completly under
> the control of the enterprise admins. We use locally
> administered DNS servers to control address resolution under DNS.
> 
>>> iPXE is the
>>> "swiss army knife" of +network booting. It supports both HTTPS and
>>> iSCSI. It has a script engine for +fine grained control of the boot
>>> process and can provide a command shell. +
> 
> (1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex)
> or
> (2)u-boot (+ missing functions)->kernel?
> 
>>> +protocol. Now iPXE can call the simple file protocol to load Grub.
> 
> I seem to be missing the point. We use U-boot to load and run
> the kernel with tcp+http 1.0. https would be a nice enhancement, as
> would an encrypted connection for the *nix kernel to access the image,
> but complete security requires more.

With http the client cannot find out from where he is downloading.

iPXE offers to install an SSL certificate to verify that it is talking
to the right https server and can send user and password over the secure
channel so the server can verify that the client is authorized for the
requested resource. With iSCSI there is only the CHAP protocol for
mutual authentication.

For SSL you need good random numbers. For U-Boot the only viable source
of randomness is the network or a random seed updated by the operating
system. Some SOCs additionally offer an internal source of randomness.

> 
> If you are going to do this we need to discuss accessing the *nix
> image over a secure protocol. AFAIK the *nix kernel does not
> use secure protocols with network *nix images.

Once you have loaded the image and initrd over a secure channel like
https or ipsec the kernel can connect to a network drive using ipsec.

> 
> In the netboot process we'd address the performance limitations of NFS, 
> especially during boot, with either lookahead caching at the client or
> use HTTPS for image access, both of which are outside u-boot's scope.
> 

The limiting factors for all network protocols are the ping time for
IOps and the bandwidth for download speed. Only NVMe over TCP will bring
a real improvement for IOps.

Some small TCP stacks can only have one request in flight at the same
time which is further limiting.

With iPXE I have been downloading the kernel and intird at over 30 MB/s
which means less than 2 seconds out of 25 seconds for the full reboot on
an Odroid C2.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] efi_loader: add a README.iscsi describing booting via iSCSI

[Heinrich Schuchardt]

On 01/25/2018 06:47 PM, Alexander Graf wrote:
> On 01/22/2018 07:34 PM, Heinrich Schuchardt wrote:
>> The appended README explains how U-Boot and iPXE can be used
>> to boot a diskless system from an iSCSI SAN.
>>
>> The maintainer for README.efi and README.iscsi is set.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>   MAINTAINERS  |   2 +
>>   doc/README.iscsi | 178
>> +++
>>   2 files changed, 180 insertions(+)
>>   create mode 100644 doc/README.iscsi
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index d459153503..6e94cee5d3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -286,6 +286,8 @@ EFI PAYLOAD
>>   M:    Alexander Graf 
>>   S:    Maintained
>>   T:    git git://github.com/agraf/u-boot.git
>> +F:    doc/README.efi
>> +F:    doc/README.iscsi
>>   F:    include/efi*
>>   F:    lib/efi*/
>>   F:    test/py/tests/test_efi*
>> diff --git a/doc/README.iscsi b/doc/README.iscsi
>> new file mode 100644
>> index 00..f095ad1ddf
>> --- /dev/null
>> +++ b/doc/README.iscsi
>> @@ -0,0 +1,178 @@
>> +# iSCSI booting with U-Boot and iPXE
>> +
>> +## Motivation
>> +
>> +U-Boot has only a reduced set of supported network protocols. A major
>> gap is
>> +the lack of a TCP stack.
> 
> This is only semi-true. There is work in progress to get TCP support
> into U-Boot. The protocols on top however are still missing and using
> iPXE here is definitely a very reasonable approach.
> 

I can mention that this is work in progress.

>> +
>> +For booting a diskless computer this leaves us with BOOTP or DHCP to
>> get the
>> +address of a boot script. TFTP can be used to load the boot script
>> and the
>> +operating system kernel and initial file system (initrd).
>> +
>> +These protocols are insecure. The client cannot validate the
>> authenticity
>> +of the contacted servers. And the server cannot verify the identity
>> of the
>> +client.
>> +
>> +Furthermore the services providing the operating system loader or
>> kernel are
>> +not the ones that the operating system will use. Especially in a SAN
>> environment
>> +this makes updating the operating system a hassle. After installing a
>> new
>> +kernel version the boot files have to be copied to the TFTP server
>> directory.
>> +
>> +The HTTPS protocol provides certificate based validation of servers.
>> Sensitive
>> +data like passwords can be securely transmitted.
>> +
>> +The iSCSI protocol is used for connecting storage attached networks. It
>> +provides mutual authentication using the CHAP protocol. It typically
>> runs on
>> +a TCP transport.
>> +
>> +Thus a better solution than DHCP/TFTP boot would be to load a boot
>> script via
>> +HTTPS and to download any other files needed for booting via iSCSI.
>> +
>> +An alternative to implementing these protocols in U-Boot is to use an
>> existing
>> +software that can run on top of U-Boot. iPXE is the "swiss army
>> knife" of
>> +network booting. It supports both HTTPS and iSCSI. It has a script
>> engine for
>> +fine grained control of the boot process and can provide a command
>> shell.
>> +
>> +iPXE can be built as an EFI application (named snp.efi) which can be
>> loaded and
>> +run by U-Boot.
>> +
>> +## Boot sequence
>> +
>> +U-Boot loads the EFI application iPXE snp.efi using the bootefi
>> command. This
>> +application has network access via the simple network protocol
>> offered by
>> +U-Boot.
>> +
>> +iPXE executes its internal script. This script may optionally chain
>> load a
>> +secondary boot script via HTTPS or open a shell.
>> +
>> +For the further boot process iPXE connects to the iSCSI server. This
>> includes
>> +the mutual authentication using the CHAP protocol. After the
>> authentication iPXE
>> +has access to the iSCSI targets.
>> +
>> +For a selected iSCSI target iPXE sets up a handle with the block IO
>> protocol. It
>> +uses the ConnectController boot service of U-Boot to request U-Boot
>> to connect a
>> +file system driver. U-Boot reads from the iSCSI drive via the block
>> IO protocol
>> +offered by iPXE. It creates the partition handles and install the
>> simple file
> 
> installs
> 
>> +protocol. Now iPXE can call the simple file protocol to load Grub.
>> U-Boot uses
>> +the block IO protocol offered by iPXE to fulfill the request.
>> +
>> +Once Grub is started it uses the same simple file protocol to load
>> Linux. Via
> 
> Are you sure grub uses the file system protocol? IIRC it uses block
> directly.


> 
>> +the EFI stub Linux is called as an EFI application.
>> +
>> +```
>> +   ++  ++
>> +   |    | Runs |    |
>> +   | U-Boot |=>| iPXE   |
>> +   | EFI    |  | snp.efi|
>> +++ |    | DHCP |    |
>> +|    |<||<=|    |
>> +| DHCP   | |    | Request  |    |
>> +| Server | |    |  |    |
>> +|    

[U-Boot] [RFC PATCH 1/2] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715

[Nishanth Menon]

As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.

NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
   provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
   locations.

[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html

Cc: Marc Zyngier 
Cc: Russell King 
Cc: Tony Lindgren 
Cc: Robin Murphy 
Cc: Florian Fainelli 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Christoffer Dall 
Cc: Andre Przywara 
Cc: Ard Biesheuvel 
Cc: Tom Rini 
Cc: Michael Nazzareno Trimarchi 

Signed-off-by: Nishanth Menon 
---
 arch/arm/Kconfig   | 5 +
 arch/arm/cpu/armv7/start.S | 7 +--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f6d57f5505ff..c2ac0fef9d0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -86,6 +86,8 @@ config THUMB2_KERNEL
 # CONFIG_ARM_ERRATA_621766
 # CONFIG_ARM_ERRATA_798870
 # CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
 config ARM_ERRATA_430973
bool
 
@@ -155,6 +157,9 @@ config ARM_ERRATA_852423
 config ARM_ERRATA_855873
bool
 
+config ARM_CORTEX_A8_CVE_2017_5715
+   bool
+
 config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 7e2695761e98..64c5d7598dea 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -249,12 +249,15 @@ skip_errata_801819:
pop {r1-r5} @ Restore the cpu info - fall through
 #endif
 
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined 
(CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
mrc p15, 0, r0, c1, c0, 1   @ Read ACR
 
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+   orr r0, r0, #(0x1 << 6) @ Set IBE bit always to enable OS WA
+#else
cmp r2, #0x21   @ Only on < r2p1
orrlt   r0, r0, #(0x1 << 6) @ Set IBE bit
-
+#endif
push{r1-r5} @ Save the cpu info registers
bl  v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
-- 
2.15.1

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

[U-Boot] [RFC PATCH 2/2] ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715

[Nishanth Menon]

As recommended by Arm in [1], ACR needs to be set[2] to enable
invalidation of BTB. This has to be enabled unconditionally for
ICIALLU to be functional on Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.

NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
   provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
   right locations.

[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html

Cc: Marc Zyngier 
Cc: Russell King 
Cc: Tony Lindgren 
Cc: Robin Murphy 
Cc: Florian Fainelli 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Christoffer Dall 
Cc: Andre Przywara 
Cc: Ard Biesheuvel 
Cc: Tom Rini 
Cc: Michael Nazzareno Trimarchi 

Signed-off-by: Nishanth Menon 
---
 arch/arm/Kconfig   | 4 
 arch/arm/cpu/armv7/start.S | 8 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c2ac0fef9d0c..116cee559ca4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -87,6 +87,7 @@ config THUMB2_KERNEL
 # CONFIG_ARM_ERRATA_798870
 # CONFIG_ARM_ERRATA_801819
 # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
 
 config ARM_ERRATA_430973
bool
@@ -160,6 +161,9 @@ config ARM_ERRATA_855873
 config ARM_CORTEX_A8_CVE_2017_5715
bool
 
+config ARM_CORTEX_A15_CVE_2017_5715
+   bool
+
 config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 64c5d7598dea..4835316bb37e 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -238,6 +238,14 @@ skip_errata_798870:
 skip_errata_801819:
 #endif
 
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+   mrc p15, 0, r0, c1, c0, 1   @ read auxilary control register
+   orr r0, r0, #1 << 0 @ Enable invalidates of BTB
+   push{r1-r5} @ Save the cpu info registers
+   bl  v7_arch_cp15_set_acr
+   pop {r1-r5} @ Restore the cpu info - fall through
+#endif
+
 #ifdef CONFIG_ARM_ERRATA_454179
mrc p15, 0, r0, c1, c0, 1   @ Read ACR
 
-- 
2.15.1

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

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

Hi Folks,

This is a follow through on the discussion we have had in [1].
This itself is'nt a complete solution and is based on recommendation
This from Arm[2] for variant 2 CVE-2017-5715

The Linux kernel discussions are spread out in [3], ATF and OPTEE
status are available in [4].

This is just an RFC series (build tested at this point) to check if
the direction is fine and should follow the final solution once kernel
patches get to upstream, IMHO.

NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
Cortex-A9/12/17 do not need additional steps in u-boot to enable the
OS level workarounds.

Nishanth Menon (2):
  ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
CVE-2017-5715
  ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
CVE-2017-5715

 arch/arm/Kconfig   |  9 +
 arch/arm/cpu/armv7/start.S | 15 +--
 2 files changed, 22 insertions(+), 2 deletions(-)

[1] https://marc.info/?t=15163990652=1=2
[2] https://developer.arm.com/support/security-update
[3] https://marc.info/?t=15154379047=1=2 and the latest in 
https://marc.info/?l=linux-arm-kernel=151689379521082=2
[4] 
https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
 https://www.op-tee.org/security-advisories/ 
https://www.linaro.org/blog/meltdown-spectre/
-- 
2.15.1

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

Re: [U-Boot] [PATCH V3] imx: mx25: Remove SION bit in all pin-mux that are safe

[Benoît Thébaudeau]

Hi Michael,

On Thu, Jan 25, 2018 at 2:06 PM, Michael Trimarchi
 wrote:
> SION bit should be used in the situation that we need
> to read back the value of a pin and should not be set by
> default macro.
>
> We get some malfunction as raised by following thread
>
> https://www.spinics.net/lists/linux-usb/msg162574.html
>
> As reported by this application note:
> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>
> The software input on (SION) bit is an option to force an input
> path to be active regardless of the value driven by the
> corresponding module. It is used when the nature direction
> of a pin depending on selected alternative function is an output,
> but it is needed to read the real logic value on a pin.
>
> The SION bit can be used in:
> • Loopback: the module of a selected alternative function drives
> the pad and also receives the pad value as an input
> • GPIO capture: the module of a selected alternative function
> drives the pin and the value is captured by the GPIO
>
> SION bit is not necessary when the pin is configured as a peripheral
> apart specific silicon bug. If an application needs to have this
> set, this should be done in board file or in dts file
>
> Signed-off-by: Michael Trimarchi 

[...]

I have now tested the following peripherals on i.MX25 without any SION
bit set: AUDMUX/SSI, eSDHC, FEC (except PHY access for which MDIO
might have an issue without SION; Ethernet works but I have not
checked whether this is possible at least partially without access to
the PHY registers), GPIO, I2C, SLCDC, UART, and USB. Everything worked
fine except the lack of SION for eSDHC CMD, which is true for all
eSDHC instances (and not only for eSDHC1, so Linux's
arch/arm/boot/dts/imx25-pinfunc.h should be fixed). Therefore, SION is
mandatory for all the eSDHC CMD functions in
arch/arm/include/asm/arch-mx25/iomux-mx25.h, but it can be removed for
everything else (I still have to carry out one more test to confirm
this for FEC MDIO), and moved to the board files if necessary (but I
don't think that any mainline board code is doing something fancy
enough to need it).

If the bus-status detection example in the documentation of SION in
the reference manual is useful, it means that SION is probably
required for all the signals requiring simultaneous output and input
(such as I²C for device clock stretching or multi-master bus
arbitration, except if the IP toggles between input and output low at
each clock edge rather than between open-drain output high and output
low), because there are no automatic SION signals between the
peripherals and the pads but only direction signals that can request a
single direction at a time. For bidirectional signals that do not
require simultaneous output and input because they work in turns (such
as FEC MDIO), SION can be required or not depending on whether the IP
toggles the direction signal for each turn or always expects an input
feedback while driving an open-drain output high. Even if SION is
required for the I²C example mentioned above (which is unlikely as
basic I²C transfers work fine and clock stretching detection is
automatic and would always need the input state), the need for these
advanced I²C features can be considered board-specific, so SION would
still not be required in iomux-mx25.h.

In the end, for this patch, apart from the pending test for FEC MDIO:
Reviewed-by: Benoît Thébaudeau 

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

Re: [U-Boot] [PATCH V3] imx: mx25: Remove SION bit in all pin-mux that are safe

[Michael Nazzareno Trimarchi]

Hi

On Thu, Jan 25, 2018 at 10:48 PM, Benoît Thébaudeau
 wrote:
> Hi Michael,
>
> On Thu, Jan 25, 2018 at 2:06 PM, Michael Trimarchi
>  wrote:
>> SION bit should be used in the situation that we need
>> to read back the value of a pin and should not be set by
>> default macro.
>>
>> We get some malfunction as raised by following thread
>>
>> https://www.spinics.net/lists/linux-usb/msg162574.html
>>
>> As reported by this application note:
>> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>>
>> The software input on (SION) bit is an option to force an input
>> path to be active regardless of the value driven by the
>> corresponding module. It is used when the nature direction
>> of a pin depending on selected alternative function is an output,
>> but it is needed to read the real logic value on a pin.
>>
>> The SION bit can be used in:
>> • Loopback: the module of a selected alternative function drives
>> the pad and also receives the pad value as an input
>> • GPIO capture: the module of a selected alternative function
>> drives the pin and the value is captured by the GPIO
>>
>> SION bit is not necessary when the pin is configured as a peripheral
>> apart specific silicon bug. If an application needs to have this
>> set, this should be done in board file or in dts file
>>
>> Signed-off-by: Michael Trimarchi 
>
> [...]
>
> I have now tested the following peripherals on i.MX25 without any SION
> bit set: AUDMUX/SSI, eSDHC, FEC (except PHY access for which MDIO
> might have an issue without SION; Ethernet works but I have not
> checked whether this is possible at least partially without access to
> the PHY registers), GPIO, I2C, SLCDC, UART, and USB. Everything worked
> fine except the lack of SION for eSDHC CMD, which is true for all
> eSDHC instances (and not only for eSDHC1, so Linux's
> arch/arm/boot/dts/imx25-pinfunc.h should be fixed). Therefore, SION is
> mandatory for all the eSDHC CMD functions in
> arch/arm/include/asm/arch-mx25/iomux-mx25.h, but it can be removed for

I will repost. On my side I have tested already some of the
peripherals you mention
but I was not having the second slod for eSDHC.

We already run preliminary testing on the hardware and usb problem is right now
fixed.

Thank you for testing

Michael

> everything else (I still have to carry out one more test to confirm
> this for FEC MDIO), and moved to the board files if necessary (but I
> don't think that any mainline board code is doing something fancy
> enough to need it).
>
> If the bus-status detection example in the documentation of SION in
> the reference manual is useful, it means that SION is probably
> required for all the signals requiring simultaneous output and input
> (such as I²C for device clock stretching or multi-master bus
> arbitration, except if the IP toggles between input and output low at
> each clock edge rather than between open-drain output high and output
> low), because there are no automatic SION signals between the
> peripherals and the pads but only direction signals that can request a
> single direction at a time. For bidirectional signals that do not
> require simultaneous output and input because they work in turns (such
> as FEC MDIO), SION can be required or not depending on whether the IP
> toggles the direction signal for each turn or always expects an input
> feedback while driving an open-drain output high. Even if SION is
> required for the I²C example mentioned above (which is unlikely as
> basic I²C transfers work fine and clock stretching detection is
> automatic and would always need the input state), the need for these
> advanced I²C features can be considered board-specific, so SION would
> still not be required in iomux-mx25.h.
>
> In the end, for this patch, apart from the pending test for FEC MDIO:
> Reviewed-by: Benoît Thébaudeau 
>
> Best regards,
> Benoît



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SquashFS and FIT images

[Mathew McBride]

On 26/01/2018 8:01 AM, Bishop, Mark (STRT) wrote:

Is it possible to specify squashFS images in an .its file?  If so, anyone have 
an example or a pointer to the docs I've been searching for?
Hi Mark,

It is possible, here is an example I have used on an NXP LS1043 board:
/dts-v1/;

/ {
description = "ARM64 OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;

images {
kernel@1 {
description = "ARM64 OpenWrt Linux-4.4";
data = /incbin/("arch/arm64/boot/Image.gz");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x8008>;
entry = <0x8008>;
};


ramdisk@1 {
description = "ARM64 OpenWrt ramdisk";
data = /incbin/("root.squashfs");
type = "ramdisk";
arch = "arm64";
os = "linux";
compression = "gzip";
};


fdt@1 {
description = "ARM64 OpenWrt device tree blob";
data = 
/incbin/("arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dtb");

type = "flat_dt";
arch = "arm64";
compression = "none";
load = <0x9000>;
};


};

configurations {
default = "config@1";
config@1 {
description = "OpenWrt";
kernel = "kernel@1";
fdt = "fdt@1";
ramdisk = "ramdisk@1";
};
};
};

Cheers,
Matt


Mark Bishop
Sr. Firmware/Software Engineer - Microwave Subsystems

[cid:image001.png@01D281ED.A45F0A90]

4726 Eisenhower Blvd.
Tampa, FL 33634
USA


T  +1 813 901 7293

mbis...@smithsinterconnectinc.com

smithsinterconnect.com

TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!








___
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/7] sunxi: binman: Fix U-Boot binary size check

[Samuel Holland]

On 01/25/18 09:27, Maxime Ripard wrote:
> On Wed, Jan 24, 2018 at 07:13:54AM -0600, Samuel Holland wrote:
>> On 01/24/18 02:38, Maxime Ripard wrote:
>>> Hi!
>>>
>>> On Tue, Jan 23, 2018 at 04:18:13PM -0600, Samuel Holland wrote:
 If raw mode is disabled, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not
 defined, which breaks compiling the device trees. Only enable the size
 check when it actually matters--that is, when MMC raw mode is enabled.

 Signed-off-by: Samuel Holland 
 ---
  arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/dts/sunxi-u-boot.dtsi 
 b/arch/arm/dts/sunxi-u-boot.dtsi
 index 72e95afd78..996f391030 100644
 --- a/arch/arm/dts/sunxi-u-boot.dtsi
 +++ b/arch/arm/dts/sunxi-u-boot.dtsi
 @@ -17,7 +17,7 @@
filename = "spl/sunxi-spl.bin";
};
u-boot-img {
 -#ifdef CONFIG_MMC
 +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
>>>
>>> Why don't you change for ENV_IS_IN_MMC like your commit log would
>>> suggest?
>>
>> Because if the environment is in MMC but U-Boot isn't (e.g. it's in SPI), or
>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is in effect and the U-Boot 
>> image
>> is stored after the environment in MMC, then there's no chance of overlap and
>> the size doesn't matter.
> 
> Ah, right. Can you put that in your commit log?

Sure, I'll do that for v2.

> Thanks!
> Maxime

Thanks,
Samuel

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

Re: [U-Boot] [PATCH 1/7] sunxi: binman: Fix U-Boot binary size check

[Maxime Ripard]

On Wed, Jan 24, 2018 at 07:13:54AM -0600, Samuel Holland wrote:
> On 01/24/18 02:38, Maxime Ripard wrote:
> > Hi!
> > 
> > On Tue, Jan 23, 2018 at 04:18:13PM -0600, Samuel Holland wrote:
> >> If raw mode is disabled, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not
> >> defined, which breaks compiling the device trees. Only enable the size
> >> check when it actually matters--that is, when MMC raw mode is enabled.
> >>
> >> Signed-off-by: Samuel Holland 
> >> ---
> >>  arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi 
> >> b/arch/arm/dts/sunxi-u-boot.dtsi
> >> index 72e95afd78..996f391030 100644
> >> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> >> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> >> @@ -17,7 +17,7 @@
> >>filename = "spl/sunxi-spl.bin";
> >>};
> >>u-boot-img {
> >> -#ifdef CONFIG_MMC
> >> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> > 
> > Why don't you change for ENV_IS_IN_MMC like your commit log would
> > suggest?
> 
> Because if the environment is in MMC but U-Boot isn't (e.g. it's in SPI), or
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is in effect and the U-Boot 
> image
> is stored after the environment in MMC, then there's no chance of overlap and
> the size doesn't matter.

Ah, right. Can you put that in your commit log?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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] crypto/fsl: instantiate all rng state handles

[Bryan O'Donoghue]

On 25/01/18 13:11, Lukas Auer wrote:

Extend the instantiate_rng() function and the corresponding CAAM job
descriptor to instantiate all RNG state handles. This moves the RNG
instantiation code in line with the CAAM kernel driver.

Previously, only the first state handle was instantiated. The second one
was instantiated by the CAAM kernel driver. This works if the kernel
runs in secure mode, but fails in non-secure mode since the kernel
driver uses DEC0 directly instead of over the job ring interface.
Instantiating all RNG state handles in u-boot removes the need for using
DEC0 in the kernel driver, making it possible to use the CAAM in
non-secure mode.

Signed-off-by: Lukas Auer 


git apply < \[PATCH\]\ crypto_fsl\:\ instantiate\ all\ rng\ state\ 
handles.eml

:107: trailing whitespace.
void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc, int handle)
:130: trailing whitespace.
(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT);
:131: trailing whitespace.

:132: trailing whitespace.
/* For SH0, Secure Keys must be generated as well */
:133: trailing whitespace.
if (handle == 0) {
error: patch failed: drivers/crypto/fsl/jobdesc.c:257
error: drivers/crypto/fsl/jobdesc.c: patch does not apply
error: patch failed: drivers/crypto/fsl/jobdesc.h:40
error: drivers/crypto/fsl/jobdesc.h: patch does not apply
error: patch failed: drivers/crypto/fsl/jr.c:444
error: drivers/crypto/fsl/jr.c: patch does not apply
error: patch failed: drivers/crypto/fsl/jr.h:40
error: drivers/crypto/fsl/jr.h: patch does not apply
error: patch failed: include/fsl_sec.h:67
error: include/fsl_sec.h: patch does not apply

git show HEAD
commit c761a7e29d703d60208585bb7d8415e00aa22556
Author: Tom Rini 
Date:   Mon Jan 22 21:06:41 2018 -0500

Revert "travis-ci: Add qemu-x86_64 target"

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

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

[Álvaro Fernández Rojas]

Hi Jagan,

El 24/01/2018 a las 7:57, Jagan Teki escribió:

On Tue, Jan 23, 2018 at 3:58 PM, Daniel Schwierzeck
 wrote:


On 22.01.2018 21:55, Álvaro Fernández Rojas wrote:

Hi Daniel,


El 22/01/2018 a las 21:26, Daniel Schwierzeck escribió:

On 22.01.2018 18:14, Tom Rini wrote:

On Mon, Jan 22, 2018 at 05:49:39PM +0100, Daniel Schwierzeck wrote:

On 22.01.2018 13:58, Tom Rini wrote:

On Mon, Jan 22, 2018 at 11:20:56AM +0530, Jagan Teki wrote:


Hi Tom,

Please pull this PR.

thanks!
Jagan.

The following changes since commit
98691a60abffb44303d7dae6e9e699d0daded930:

Merge git://git.denx.de/u-boot-rockchip (2018-01-09 13:28:51
-0500)

are available in the git repository at:

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

for you to fetch changes up to
b23c685c6f295da3c01dd487f0e003b70299af91:

mips: bmips: enable the SPI flash on the Comtrend AR-5387un
(2018-01-22 10:39:13 +0530)


NAK:

commit 19e3a4856c1cba751a9ecb3931ff0d96a7f169be
Author: Álvaro Fernández Rojas 
Date:   Sat Jan 20 02:11:34 2018 +0100

  wait_bit: add 8/16/32 BE/LE versions of wait_for_bit

  Add 8/16/32 bits and BE/LE versions of wait_for_bit.
  This is needed for reading registers that are not aligned to
32 bits, and for
  Big Endian platforms.

  Signed-off-by: Álvaro Fernández Rojas 
  Reviewed-by: Daniel Schwierzeck 
  Reviewed-by: Jagan Teki 

Adds warnings on almost all platforms:
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function
?wait_for_bit_be16?:
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h:76:31:
warning: implicit declaration of function ?readw_be?
[-Wimplicit-function-declaration]
w+(ls1088ardb_qspi_SECURE_BOOT) ../include/wait_bit.h: In function
?wait_for_bit_be32?: w+(ls1088ardb_qspi_SECURE_BOOT)
../include/wait_bit.h:78:31: warning: implicit declaration of
function ?readl_be? [-Wimplicit-function-declaration]



Tom, would this change to the patch be acceptable?

--- a/include/wait_bit.h
+++ b/include/wait_bit.h
@@ -73,8 +73,12 @@ static inline int wait_for_bit_##sfx(const void
*reg,\

   BUILD_WAIT_FOR_BIT(8, u8, readb)
   BUILD_WAIT_FOR_BIT(le16, u16, readw)
+#ifdef readw_be
   BUILD_WAIT_FOR_BIT(be16, u16, readw_be)
+#endif
   BUILD_WAIT_FOR_BIT(le32, u32, readl)
+#ifdef readl_be
   BUILD_WAIT_FOR_BIT(be32, u32, readl_be)
+#endif

   #endif

This wouldn't define wait_bit_be*() on archs which doesn't implement
readw_be or readl_be.

A build with the updated patch is scheduled at
https://travis-ci.org/danielschwierzeck/u-boot/builds/331899381

That seems reasonable, thanks!


Álvaro, could you send a v10 where the patch "wait_bit: add 8/16/32
BE/LE versions of wait_for_bit" is fixed like above? Thanks.

Sure, but I think this alternative would be much cleaner:
https://gist.github.com/Noltari/3e6ed4648b87484c73ca22e2f533f9b0

What do you think?


I had a similar idea at first but a #ifdef within a #define is not possible and 
AFAIK not implemented in C standards.

Have you tried it? With nested #ifdef I'm getting:

$ ./tools/buildman/buildman -o /tmp/bm -b master..wait_for_bit aarch64
Building 1 commit for 111 boards (8 threads, 1 job per thread)
50   11   50 /111lion-rk3368

vs.

$ ./tools/buildman/buildman -o /tmp/bm -b master..wait_for_bit_2 aarch64
Building 1 commit for 111 boards (8 threads, 1 job per thread)
98   130 /1110:00:06  : ls1046ardb_emm

Also a Travis CI build already shows several broken builds:
https://travis-ci.org/danielschwierzeck/u-boot/builds/332205310

Maybe a yet better solution would be if each arch implements the same common 
set of I/O primitives like Linux is doing.

Recent patch from Alvaro, seems fine to built all [1]

[1] https://travis-ci.org/openedev/u-boot-spi/builds/332390626

I ended up adding the changes proposed by Daniel to avoid nested ifdefs.
So I guess it can be merged now :).

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

Re: [U-Boot] [PATCH] crypto/fsl: instantiate all rng state handles

[Bryan O'Donoghue]

On 25/01/18 15:53, Bryan O'Donoghue wrote:



On 25/01/18 13:11, Lukas Auer wrote:

Extend the instantiate_rng() function and the corresponding CAAM job
descriptor to instantiate all RNG state handles. This moves the RNG
instantiation code in line with the CAAM kernel driver.

Previously, only the first state handle was instantiated. The second one
was instantiated by the CAAM kernel driver. This works if the kernel
runs in secure mode, but fails in non-secure mode since the kernel
driver uses DEC0 directly instead of over the job ring interface.
Instantiating all RNG state handles in u-boot removes the need for using
DEC0 in the kernel driver, making it possible to use the CAAM in
non-secure mode.

Signed-off-by: Lukas Auer 


git apply < \[PATCH\]\ crypto_fsl\:\ instantiate\ all\ rng\ state\ 
handles.eml


doh

git am <

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

Re: [U-Boot] [PATCH] crypto/fsl: instantiate all rng state handles

[Auer, Lukas]

On Thu, 2018-01-25 at 15:53 +, Bryan O'Donoghue wrote:
> 
> On 25/01/18 13:11, Lukas Auer wrote:
> > Extend the instantiate_rng() function and the corresponding CAAM
> > job
> > descriptor to instantiate all RNG state handles. This moves the RNG
> > instantiation code in line with the CAAM kernel driver.
> > 
> > Previously, only the first state handle was instantiated. The
> > second one
> > was instantiated by the CAAM kernel driver. This works if the
> > kernel
> > runs in secure mode, but fails in non-secure mode since the kernel
> > driver uses DEC0 directly instead of over the job ring interface.
> > Instantiating all RNG state handles in u-boot removes the need for
> > using
> > DEC0 in the kernel driver, making it possible to use the CAAM in
> > non-secure mode.
> > 
> > Signed-off-by: Lukas Auer 
> 
> git apply < \[PATCH\]\ crypto_fsl\:\ instantiate\ all\ rng\ state\ 
> handles.eml
> :107: trailing whitespace.
> void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc, int
> handle)
> :130: trailing whitespace.
>   (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT);
> :131: trailing whitespace.
> 
> :132: trailing whitespace.
>   /* For SH0, Secure Keys must be generated as well */
> :133: trailing whitespace.
>   if (handle == 0) {
> error: patch failed: drivers/crypto/fsl/jobdesc.c:257
> error: drivers/crypto/fsl/jobdesc.c: patch does not apply
> error: patch failed: drivers/crypto/fsl/jobdesc.h:40
> error: drivers/crypto/fsl/jobdesc.h: patch does not apply
> error: patch failed: drivers/crypto/fsl/jr.c:444
> error: drivers/crypto/fsl/jr.c: patch does not apply
> error: patch failed: drivers/crypto/fsl/jr.h:40
> error: drivers/crypto/fsl/jr.h: patch does not apply
> error: patch failed: include/fsl_sec.h:67
> error: include/fsl_sec.h: patch does not apply
> 
> git show HEAD
> commit c761a7e29d703d60208585bb7d8415e00aa22556
> Author: Tom Rini 
> Date:   Mon Jan 22 21:06:41 2018 -0500
> 
>  Revert "travis-ci: Add qemu-x86_64 target"
> 

I'm still fairly new to working with patches over mailing list, so I'm
not sure what's going wrong.

Can you try using git am to apply the patch? It's working on my machine
this way.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 2/2] DW SPI: Get clock value from Device Tree

[Tom Rini]

On Thu, Jan 25, 2018 at 06:37:20PM +0530, Jagan Teki wrote:
> On Thu, Jan 25, 2018 at 6:15 PM, Alexey Brodkin
>  wrote:
> > Hi Jagan,
> >
> > On Fri, 2018-01-19 at 14:17 +0100, Eugeniy Paltsev wrote:
> >> Hi Jagan,
> >>
> >> Could you please pull these patches to your tree?
> >> It would be really nice to see this patch in the nearest release.
> >>
> >> Thanks.
> >>
> >> On Thu, 2017-12-28 at 15:09 +0300, Eugeniy Paltsev wrote:
> >> > Add option to set spi controller clock frequency via device tree
> >> > using standard clock bindings.
> >> >
> >> > Define dw_spi_get_clk function as 'weak' as some targets
> >> > (like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
> >> > and implement dw_spi_get_clk their own way in their clock manager.
> >> >
> >> > Get rid of clock_manager.h include as we don't use
> >> > cm_get_spi_controller_clk_hz function anymore. (we use redefined
> >> > dw_spi_get_clk in SOCFPGA clock managers instead)
> >> >
> >> > Reviewed-by: Marek Vasut 
> >> > Signed-off-by: Eugeniy Paltsev 
> >> > ---
> >
> > Any chance for this one to be applied sometime soon?
> > Note this is a prerequisite for our further work and it's been floating
> > and discussed on the mailing list for a couple of months now,
> > that said we'd really like to get this as a part of U-Boot 2018.03.
> 
> Since delegate has marked to 'marek' it wasn't showed with me, yes
> will take this.

As always, oops, my bad.  I think I saw Marek commenting at one point
and kept delegating to him.  And I missed that it now has his
Reviewed-by, so yes, please pick this up in patchwork, 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] fdt: Implement weak arch_fixup_fdt()

[Daniel Schwierzeck]

On 24.01.2018 18:47, Alexey Brodkin wrote:
> Only ARM and in some configs MIPS really implement arch_fixup_fdt().
> Others just use the same boilerplate which is not good by itself,
> but what's worse if we try to build with disabled CONFIG_CMD_BOOTM
> and enabled CONFIG_OF_LIBFDT we'll hit an unknown symbol which was
> apparently implemented in arch/xxx/lib/bootm.c.
> 
> Now with weak arch_fixup_fdt() right in image-fdt.c where it is
> used we get both items highlighted above fixed.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Schwierzeck 
> Cc: Simon Glass 
> Cc: York Sun 
> Cc: Stefan Roese 
> ---
>  arch/arc/lib/bootm.c| 5 -
>  arch/microblaze/lib/bootm.c | 5 -
>  arch/mips/lib/bootm.c   | 6 ++
>  arch/nds32/lib/bootm.c  | 6 --
>  arch/powerpc/lib/bootm.c| 5 -
>  arch/sandbox/lib/bootm.c| 5 -
>  arch/x86/lib/bootm.c| 5 -
>  common/image-fdt.c  | 5 +
>  8 files changed, 7 insertions(+), 35 deletions(-)
> 
Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel



signature.asc
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/8] spl: nand: sunxi: Enhancements and cleaning

[Miquel Raynal]

Hi Boris,

On Wed, 24 Jan 2018 09:06:38 +0100
Boris Brezillon  wrote:

> On Wed, 24 Jan 2018 01:44:50 +0100
> Miquel Raynal  wrote:
> 
> > Do some cleaning in sunxi NAND SPL driver like adding helpers and
> > clearing flags at the right spot
> > 
> > Signed-off-by: Miquel Raynal 
> > ---
> >  drivers/mtd/nand/sunxi_nand_spl.c | 64 
> > +--
> >  1 file changed, 41 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
> > b/drivers/mtd/nand/sunxi_nand_spl.c
> > index 06695fc15f..2488d5cb51 100644
> > --- a/drivers/mtd/nand/sunxi_nand_spl.c
> > +++ b/drivers/mtd/nand/sunxi_nand_spl.c
> > @@ -55,8 +55,8 @@
> >  
> >  
> >  #define NFC_ADDR_NUM_OFFSET16
> > -#define NFC_SEND_ADR   (1 << 19)
> >  #define NFC_ACCESS_DIR (1 << 20)
> > +#define NFC_SEND_ADDR  (1 << 19)  
> 
> This typo fix probably deserves a separate patch.

Indeed.

> 
> >  #define NFC_DATA_TRANS (1 << 21)
> >  #define NFC_SEND_CMD1  (1 << 22)
> >  #define NFC_WAIT_FLAG  (1 << 23)
> > @@ -155,6 +155,30 @@ static inline int check_value_negated(int offset, int 
> > unexpected_bits,
> > return check_value_inner(offset, unexpected_bits, timeout_us, 1);
> >  }
> >  
> > +static int nand_wait_cmd_fifo_empty(void)
> > +{
> > +   if (!check_value_negated(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_FIFO_STAT,
> > +DEFAULT_TIMEOUT_US)) {
> > +   printf("nand: timeout waiting for empty cmd FIFO\n");
> > +   return -ETIMEDOUT;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int nand_wait_int(void)
> > +{
> > +   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> > +DEFAULT_TIMEOUT_US)) {
> > +   printf("nand: timeout waiting for interruption\n");
> > +   return -ETIMEDOUT;
> > +   }
> > +
> > +   udelay(1);  
> 
> I'm pretty sure this udelay() is not required. Probably some leftover
> of your debug session ;-).

That is right -> removed.

> 
> > +
> > +   return 0;
> > +}
> > +
> >  void nand_init(void)
> >  {
> > uint32_t val;
> > @@ -172,22 +196,21 @@ void nand_init(void)
> > }
> >  
> > /* reset NAND */
> > +   nand_wait_cmd_fifo_empty();
> > +
> > writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> > writel(NFC_SEND_CMD1 | NFC_WAIT_FLAG | NAND_CMD_RESET,
> >SUNXI_NFC_BASE + NFC_CMD);
> >  
> > -   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> > -DEFAULT_TIMEOUT_US)) {
> > -   printf("Error timeout waiting for nand reset\n");
> > -   return;
> > -   }
> > -   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> > +   nand_wait_int();  
> 
> I would go even further and create an helper that takes care of the
> 'wait_fifo_empty+clear_int+write_cmd+wait_int' sequence:
> 
> static int nand_exec_cmd(u32 cmd)
> {
>   int ret;
> 
>   ret = nand_wait_cmd_fifo_empty();
>   if (ret)
>   return ret;
> 
>   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
>   writel(cmd, SUNXI_NFC_BASE + NFC_CMD);
> 
>   return nand_wait_int();
> }

It makes sense, I added another patch to introduce this helper.

> 
> >  }
> >  
> >  static void nand_apply_config(const struct nfc_config *conf)
> >  {
> > u32 val;
> >  
> > +   nand_wait_cmd_fifo_empty();
> > +
> > val = readl(SUNXI_NFC_BASE + NFC_CTL);
> > val &= ~NFC_CTL_PAGE_SIZE_MASK;
> > writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
> > @@ -200,6 +223,8 @@ static int nand_load_page(const struct nfc_config 
> > *conf, u32 offs)
> >  {
> > int page = offs / conf->page_size;
> >  
> > +   nand_wait_cmd_fifo_empty();
> > +
> > writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
> >(NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
> >(NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
> > @@ -208,38 +233,32 @@ static int nand_load_page(const struct nfc_config 
> > *conf, u32 offs)
> > writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
> > writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> > writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
> > -  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
> > +  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADDR,
> >SUNXI_NFC_BASE + NFC_CMD);
> >  
> > -   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> > -DEFAULT_TIMEOUT_US)) {
> > -   printf("Error while initializing dma interrupt\n");
> > -   return -EIO;
> > -   }
> > -
> > -   return 0;
> > +   return nand_wait_int();
> >  }
> >  
> >  static int nand_reset_column(void)
> >  {
> > +   nand_wait_cmd_fifo_empty();
> > +
> > 

Re: [U-Boot] [PATCH 5/8] spl: nand: sunxi: use PIO instead of DMA

[Miquel Raynal]

Hi Boris,

On Wed, 24 Jan 2018 09:16:19 +0100
Boris Brezillon  wrote:

> On Wed, 24 Jan 2018 01:44:51 +0100
> Miquel Raynal  wrote:
> 
> > Because using DMA implementation is not generic and was not developped
> > to work on SoCs like A33, migrate the SPL to use PIO.
> > 
> > Signed-off-by: Miquel Raynal 
> > ---
> >  board/sunxi/board.c   |   4 +-
> >  drivers/mtd/nand/sunxi_nand_spl.c | 167 
> > +-
> >  2 files changed, 79 insertions(+), 92 deletions(-)
> > 
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 70e01437c4..512e2c17a6 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -266,11 +266,13 @@ static void nand_clock_setup(void)
> > struct sunxi_ccm_reg *const ccm =
> > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> >  
> > -   setbits_le32(>ahb_gate0, (CLK_GATE_OPEN << AHB_GATE_OFFSET_NAND0));
> > +   setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_NAND0));
> > +   setbits_le32(>ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_NAND0));
> >  #ifdef CONFIG_MACH_SUN9I
> > setbits_le32(>ahb_gate1, (1 << AHB_GATE_OFFSET_DMA));
> >  #else
> > setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_DMA));
> > +   setbits_le32(>ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_DMA));
> >  #endif
> > setbits_le32(>nand0_clk_cfg, CCM_NAND_CTRL_ENABLE | AHB_DIV_1);
> >  }
> > diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
> > b/drivers/mtd/nand/sunxi_nand_spl.c
> > index 2488d5cb51..5de6825994 100644
> > --- a/drivers/mtd/nand/sunxi_nand_spl.c
> > +++ b/drivers/mtd/nand/sunxi_nand_spl.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  /* registers */
> >  #define NFC_CTL0x
> > @@ -45,32 +46,22 @@
> >  #define NFC_CTL_PAGE_SIZE_MASK (0xf << 8)
> >  #define NFC_CTL_PAGE_SIZE(a)   ((fls(a) - 11) << 8)
> >  
> > -
> >  #define NFC_ECC_EN (1 << 0)
> > -#define NFC_ECC_PIPELINE   (1 << 3)
> >  #define NFC_ECC_EXCEPTION  (1 << 4)
> >  #define NFC_ECC_BLOCK_SIZE (1 << 5)
> >  #define NFC_ECC_RANDOM_EN  (1 << 9)
> > -#define NFC_ECC_RANDOM_DIRECTION   (1 << 10)
> > -
> >  
> >  #define NFC_ADDR_NUM_OFFSET16
> > -#define NFC_ACCESS_DIR (1 << 20)
> >  #define NFC_SEND_ADDR  (1 << 19)
> >  #define NFC_DATA_TRANS (1 << 21)
> >  #define NFC_SEND_CMD1  (1 << 22)
> >  #define NFC_WAIT_FLAG  (1 << 23)
> >  #define NFC_SEND_CMD2  (1 << 24)
> > -#define NFC_SEQ(1 << 25)
> > -#define NFC_DATA_SWAP_METHOD   (1 << 26)
> > -#define NFC_ROW_AUTO_INC   (1 << 27)
> > -#define NFC_SEND_CMD3  (1 << 28)
> > -#define NFC_SEND_CMD4  (1 << 29)
> >  #define NFC_RAW_CMD(0 << 30)
> > -#define NFC_PAGE_CMD   (2 << 30)
> > +#define NFC_ECC_CMD(1 << 30)
> >  
> >  #define NFC_ST_CMD_INT_FLAG(1 << 1)
> > -#define NFC_ST_DMA_INT_FLAG(1 << 2)
> > +#define NFC_ST_CMD_FIFO_STAT   (1 << 3)
> >  
> >  #define NFC_READ_CMD_OFFSET 0
> >  #define NFC_RANDOM_READ_CMD0_OFFSET 8
> > @@ -80,22 +71,6 @@
> >  #define NFC_CMD_RNDOUT 0x05
> >  #define NFC_CMD_READSTART  0x30
> >  
> > -#define SUNXI_DMA_CFG_REG0  0x300
> > -#define SUNXI_DMA_SRC_START_ADDR_REG0   0x304
> > -#define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
> > -#define SUNXI_DMA_DDMA_BC_REG0  0x30C
> > -#define SUNXI_DMA_DDMA_PARA_REG00x318
> > -
> > -#define SUNXI_DMA_DDMA_CFG_REG_LOADING  (1 << 31)
> > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32 (2 << 25)
> > -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_DST_DRQ_TYPE_DRAM (1 << 16)
> > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_DATA_WIDTH_32 (2 << 9)
> > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_ADDR_MODE_IO (1 << 5)
> > -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_SRC_DRQ_TYPE_NFC (3 << 0)
> > -
> > -#define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
> > -#define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
> > -
> >  struct nfc_config {
> > int page_size;
> > int ecc_strength;
> > @@ -254,7 +229,23 @@ static int nand_reset_column(void)
> >SUNXI_NFC_BASE + NFC_CMD);
> >  
> > return nand_wait_int();
> > +}
> >  
> > +static int nand_change_column(u16 column)
> > +{
> > +   nand_wait_cmd_fifo_empty();
> > +
> > +   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
> > +  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
> > +  (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
> > +  SUNXI_NFC_BASE + NFC_RCMD_SET);
> > +   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> > +   writel(column, SUNXI_NFC_BASE + NFC_ADDR_LOW);
> > +   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
> > +  (1 << NFC_ADDR_NUM_OFFSET) | 

[U-Boot] [PATCH] efi_laoder: Call Exit() on return from payload in StartImage()

[Alexander Graf]

When a UEFI payload just returns instead of calling the Exit() callback,
we handle that in efi_do_enter() and call Exit on its behalf, so that
the loaded_image->exit_status value is correct.

We were missing that logic in StartImage(). Call it there too.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_boottime.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f5dae40f06..4a36b62828 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1578,8 +1578,13 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t 
image_handle,
 
ret = EFI_CALL(entry(image_handle, ));
 
-   /* Should usually never get here */
-   return EFI_EXIT(ret);
+   /*
+* Usually UEFI applications call Exit() instead of returning.
+* But because the world doesn not consist of ponies and unicorns,
+* we're happy to emulate that behavior on behalf of a payload
+* that forgot.
+*/
+   return EFI_CALL(systab.boottime->exit(image_handle, ret, 0, NULL));
 }
 
 /*
-- 
2.12.3

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

Re: [U-Boot] [PATCH 1/4] Kbuild: support W=[N, ]err for passing '-Werror' to the compiler

[Masahiro Yamada]

Hi Daniel,


2018-01-26 2:21 GMT+09:00 Daniel Schwierzeck :
> Extend the Kbuild's W=N option with an optional 'err' value. This
> will pass -Werror to the compiler to treat all warnings as errors.
> This is useful to enforce a zero-warnings policy.
>
> The 'err' value can also be combined with the numerical values
> like this:
>
> make W=1
> make W=err
> make W=1,err
>
> Signed-off-by: Daniel Schwierzeck 
> ---
>
>  scripts/Makefile.extrawarn | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index 1d3a570594..d8d93b7fe1 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -48,9 +48,12 @@ warning-3 += -Wswitch-default
>  warning-3 += $(call cc-option, -Wpacked-bitfield-compat)
>  warning-3 += $(call cc-option, -Wvla)
>
> +warning-err := -Werror
> +
>  warning := $(warning-$(findstring 1, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
>  warning += $(warning-$(findstring 2, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
>  warning += $(warning-$(findstring 3, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
> +warning += $(warning-$(findstring err, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)))
>
>  ifeq ("$(strip $(warning))","")
>  $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown)
> --
> 2.16.1


I saw a similar patch before in linux-kbuild ML.


Kbuild provides a way to specify user-specific options.
See the following lines in the top-level Makefile:


  # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
  KBUILD_CPPFLAGS += $(KCPPFLAGS)
  KBUILD_AFLAGS += $(KAFLAGS)
  KBUILD_CFLAGS += $(KCFLAGS)



"make W=err" is a shorthand of "make KCFLAGS=-Werror", right?

I tend to hesitate to add another way
to do the same thing...



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

Re: [U-Boot] [PATCH] mmc: uniphier-sd: Add compatible strings for RCar Gen2

[Marek Vasut]

On 01/25/2018 11:22 AM, Masahiro Yamada wrote:
> 2018-01-25 9:58 GMT+09:00 Jaehoon Chung :
>> On 01/25/2018 07:19 AM, Marek Vasut wrote:
>>> Add DT compatible strings for RCar Gen2 SoCs, so that this driver
>>> can bind with them. Unlike Gen3, which uses 64bit FIFO, the Gen2
>>> uses 16bit FIFO.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Jaehoon Chung 
>>> Cc: Masahiro Yamada 
>>
>> Reviewed-by: Jaehoon Chung 
>>
>>> ---
>>>  drivers/mmc/uniphier-sd.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
>>> index 741f9dfd9c..a080674c8a 100644
>>> --- a/drivers/mmc/uniphier-sd.c
>>> +++ b/drivers/mmc/uniphier-sd.c
>>> @@ -847,6 +847,11 @@ static int uniphier_sd_probe(struct udevice *dev)
>>>  }
>>>
>>>  static const struct udevice_id uniphier_sd_match[] = {
>>> + { .compatible = "renesas,sdhi-r8a7790", .data = 0 },
>>> + { .compatible = "renesas,sdhi-r8a7791", .data = 0 },
>>> + { .compatible = "renesas,sdhi-r8a7792", .data = 0 },
>>> + { .compatible = "renesas,sdhi-r8a7793", .data = 0 },
>>> + { .compatible = "renesas,sdhi-r8a7794", .data = 0 },
>>>   { .compatible = "renesas,sdhi-r8a7795", .data = UNIPHIER_SD_CAP_64BIT 
>>> },
>>>   { .compatible = "renesas,sdhi-r8a7796", .data = UNIPHIER_SD_CAP_64BIT 
>>> },
>>>   { .compatible = "renesas,sdhi-r8a77970", .data = 
>>> UNIPHIER_SD_CAP_64BIT },
>>>
>>
> 
> 
> Nit:
> You can omit ".data = 0 " if you want.
> 
> Otherwise,
> 
> Acked-by: Masahiro Yamada 

I don't want to remove the data = , because I'll be adding more of those
cap flags there in the next round . In particular, the Gen2 cannot use
that internal DMA controller while Gen3 can and a few other quirks. Oh,
and support for 16bit SD controller is coming too ;-)

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

[U-Boot] [PATCH v3 15/15] bcm2835_pinctrl: Probe pre-reloc

[Alexander Graf]

The serial drivers now depend on the pinctrl driver to determine whether
they are enabled. That means if a serial device wants to be used pre-reloc,
we also need the pinctrl device pre-reloc.

Adapt the pinctrl driver as well as dts overlay accordingly.

Signed-off-by: Alexander Graf 
---
 arch/arm/dts/bcm283x-uboot.dtsi| 4 
 drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/bcm283x-uboot.dtsi b/arch/arm/dts/bcm283x-uboot.dtsi
index 8e4231ae6c..21d038aebb 100644
--- a/arch/arm/dts/bcm283x-uboot.dtsi
+++ b/arch/arm/dts/bcm283x-uboot.dtsi
@@ -20,3 +20,7 @@
skip-init;
u-boot,dm-pre-reloc;
 };
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c 
b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
index 83dde2302e..6fbd6efbd2 100644
--- a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
+++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
@@ -148,5 +148,6 @@ U_BOOT_DRIVER(pinctrl_bcm283x) = {
.of_match   = of_match_ptr(bcm2835_pinctrl_id),
.priv_auto_alloc_size = sizeof(struct bcm283x_pinctrl_priv),
.ops= _pinctrl_ops,
-   .probe  = bcm283x_pinctl_probe
+   .probe  = bcm283x_pinctl_probe,
+   .flags  = DM_FLAG_PRE_RELOC,
 };
-- 
2.12.3

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

[U-Boot] [PATCH v3 03/15] serial: bcm283x_mu: Remove support for post-init disabling

[Alexander Graf]

We are switching to a model where a serial device doesn't even get probed when
it's not muxed properly, so we don't need device specific disabling
functionality anymore.

Signed-off-by: Alexander Graf 
---
 drivers/serial/serial_bcm283x_mu.c   | 18 +-
 include/dm/platform_data/serial_bcm283x_mu.h |  1 -
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/serial/serial_bcm283x_mu.c 
b/drivers/serial/serial_bcm283x_mu.c
index 41c26b3d93..7ce990b9b8 100644
--- a/drivers/serial/serial_bcm283x_mu.c
+++ b/drivers/serial/serial_bcm283x_mu.c
@@ -59,7 +59,7 @@ static int bcm283x_mu_serial_setbrg(struct udevice *dev, int 
baudrate)
struct bcm283x_mu_regs *regs = priv->regs;
u32 divider;
 
-   if (plat->disabled || plat->skip_init)
+   if (plat->skip_init)
return 0;
 
divider = plat->clock / (baudrate * 8);
@@ -75,9 +75,6 @@ static int bcm283x_mu_serial_probe(struct udevice *dev)
struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
 
-   if (plat->disabled)
-   return -ENODEV;
-
priv->regs = (struct bcm283x_mu_regs *)plat->base;
 
return 0;
@@ -85,14 +82,10 @@ static int bcm283x_mu_serial_probe(struct udevice *dev)
 
 static int bcm283x_mu_serial_getc(struct udevice *dev)
 {
-   struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
struct bcm283x_mu_regs *regs = priv->regs;
u32 data;
 
-   if (plat->disabled)
-   return -EAGAIN;
-
/* Wait until there is data in the FIFO */
if (!(readl(>lsr) & BCM283X_MU_LSR_RX_READY))
return -EAGAIN;
@@ -104,13 +97,9 @@ static int bcm283x_mu_serial_getc(struct udevice *dev)
 
 static int bcm283x_mu_serial_putc(struct udevice *dev, const char data)
 {
-   struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
struct bcm283x_mu_regs *regs = priv->regs;
 
-   if (plat->disabled)
-   return 0;
-
/* Wait until there is space in the FIFO */
if (!(readl(>lsr) & BCM283X_MU_LSR_TX_EMPTY))
return -EAGAIN;
@@ -123,14 +112,10 @@ static int bcm283x_mu_serial_putc(struct udevice *dev, 
const char data)
 
 static int bcm283x_mu_serial_pending(struct udevice *dev, bool input)
 {
-   struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
struct bcm283x_mu_regs *regs = priv->regs;
unsigned int lsr;
 
-   if (plat->disabled)
-   return 0;
-
lsr = readl(>lsr);
 
if (input) {
@@ -168,7 +153,6 @@ static int bcm283x_mu_serial_ofdata_to_platdata(struct 
udevice *dev)
 1);
plat->skip_init = fdtdec_get_bool(gd->fdt_blob, dev_of_offset(dev),
  "skip-init");
-   plat->disabled = false;
return 0;
 }
 #endif
diff --git a/include/dm/platform_data/serial_bcm283x_mu.h 
b/include/dm/platform_data/serial_bcm283x_mu.h
index c47d3c0e60..57ae6adc05 100644
--- a/include/dm/platform_data/serial_bcm283x_mu.h
+++ b/include/dm/platform_data/serial_bcm283x_mu.h
@@ -19,7 +19,6 @@ struct bcm283x_mu_serial_platdata {
unsigned long base;
unsigned int clock;
bool skip_init;
-   bool disabled;
 };
 
 #endif
-- 
2.12.3

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

[U-Boot] [PATCH v3 12/15] bcm2835_mu_serial: Convert to Kconfig

[Alexander Graf]

Setting config options using headers is deprecated. This patch converts
the BCM2835 Mini-UART to Kconfig.

Signed-off-by: Alexander Graf 
---
 drivers/serial/Kconfig   | 7 +++
 include/configs/rpi.h| 3 ---
 scripts/config_whitelist.txt | 1 -
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 4167683885..72281a7b64 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -388,6 +388,13 @@ config ATMEL_USART
  configured in the device tree, and input clock frequency can
  be got from the clk node.
 
+config BCM283X_MU_SERIAL
+   bool "Support for BCM283x Mini-UART"
+   depends on DM_SERIAL && ARCH_BCM283X
+   default y
+   help
+ Select this to enable Mini-UART support on BCM283X family of SoCs.
+
 config BCM6345_SERIAL
bool "Support for BCM6345 UART"
depends on DM_SERIAL && ARCH_BMIPS
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 5ffe98015f..f2d3646753 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -75,9 +75,6 @@
 #define CONFIG_MISC_INIT_R
 #endif
 
-/* Console UART, can be configured dynamically in config.txt */
-#define CONFIG_BCM283X_MU_SERIAL
-
 /* Console configuration */
 #define CONFIG_SYS_CBSIZE  1024
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 6e4e322986..5e02588066 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -121,7 +121,6 @@ CONFIG_BCH_CONST_M
 CONFIG_BCH_CONST_PARAMS
 CONFIG_BCH_CONST_T
 CONFIG_BCM2835_GPIO
-CONFIG_BCM283X_MU_SERIAL
 CONFIG_BIOSEMU
 CONFIG_BITBANGMII_MULTI
 CONFIG_BL1_OFFSET
-- 
2.12.3

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

Re: [U-Boot] [PATCH v2 00/24] omap_hsmmc: Add support for HS200 and UHS modes

[Jaehoon Chung]

Hi JJ,

On 01/25/2018 07:51 PM, Jean-Jacques Hiblot wrote:
> 
> This series adds the missing bits to enable the UHS and HS200 modes
> for the TI platforms.
> 
> Enabling support for high speed modes on omap5 requires implementing:
>  * io signal voltage selection
>  * tuning support
>  * pin configuration (IO delays)
> 
> The few last patches enable the high speed modes for the DRA7 platforms and
> also take care of disabling those modes in the dts for the platforms that
> cannot support either the UHS or the HS200 because the voltage regulators
> on board would not allow using those modes (not a SOC limitation).
> 
> With this in place we observe significant improvements in the performances:
> on a DRA72 evm:
> eMMC HS200: 124 MB/s
> eMMC DDR52: 78 MB/s
> sd   SDR104: 71 MB/s
> sd   SDR50: 44 MB/s
> For the record, the original performances were:
> SD High speed: 18 MB/s
> MMC High speed: 18 MB/s
> 
> This series has been tested on:
> * DRA71-evm
> * DRA72-evm
> * DRA7x-evm
> * DRA76-evm
> * AM57x-evm
> * Beaglebone Black (dt and non-dt)

Thanks for resending V2. Will check this patchset, ASAP.

Best Regards,
Jaehoon Chung

> 
> changes since v1:
>  - rebased on top of u-boot/master
>  - enable the H200 and UHS support in the defconfigs of the DRA7 platforms
> 
> 
> 
> Jean-Jacques Hiblot (9):
>   mmc: omap_hsmmc: Reduce the max timeout for reset controller fsm
>   mmc: omap_hsmmc: allow the simple HS modes to use the default pinctrl
>   mmc: omap_hsmmc: update mmc->clock with the actual bus speed
>   mmc: omap_hsmmc: implement send_init_stream callback
>   mmc: omap_hsmmc: add signal voltage selection support
>   ARM: dts: dra7: Add supported MMC/SD modes in MMC dt nodes
>   dts: am57xx-beagle-x15: disable UHS and HS200 support
>   dts: am57xx-idk: disable HS200 support
>   configs: dra7xx_evm/dra7xx_hs_evm: Enable MMC HS200 and SD UHS support
> 
> Kishon Vijay Abraham I (15):
>   mmc: omap_hsmmc: cleanup clock configuration
>   mmc: omap_hsmmc: cleanup omap_hsmmc_set_ios
>   mmc: omap_hsmmc: add support to set default io voltage
>   mmc: omap_hsmmc: set MMC mode in the UHSMS bit field
>   mmc: omap_hsmmc: Enable DDR mode support
>   mmc: omap_hsmmc: Add tuning support
>   mmc: omap_hsmmc: Workaround for errata id i802
>   mmc: omap_hsmmc: use mmc_of_parse to populate mmc_config
>   ARM: OMAP5/DRA7: Enable iodelay recalibration to be done from uboot
>   mmc: omap_hsmmc: Add support to set IODELAY values
>   mmc: omap_hsmmc: Add support to get pinctrl values and max frequency
> for different hw revisions
>   mmc: omap_hsmmc: allow mmc clock to be gated
>   ARM: OMAP5: set mmc clock frequency to 192MHz
>   ARM: dts: DRA7: use new dra7-specific compatible string
>   ARM: DRA7x/AM57x: Add MMC/SD fixups for rev1.0 and rev 1.1
> 
>  arch/arm/dts/am57xx-beagle-x15.dts   |   6 +
>  arch/arm/dts/am57xx-idk-common.dtsi  |   2 +
>  arch/arm/dts/dra7.dtsi   |  22 +-
>  arch/arm/include/asm/arch-omap5/clock.h  |   2 +-
>  arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |   3 +
>  arch/arm/include/asm/arch-omap5/sys_proto.h  |   7 +
>  arch/arm/include/asm/omap_mmc.h  |  59 +-
>  arch/arm/mach-omap2/omap5/dra7xx_iodelay.c   |  30 +
>  arch/arm/mach-omap2/omap5/hw_data.c  |  10 +-
>  board/ti/am57xx/board.c  |  30 +
>  board/ti/dra7xx/evm.c|  29 +
>  configs/dra7xx_evm_defconfig |   3 +
>  configs/dra7xx_hs_evm_defconfig  |   3 +
>  drivers/mmc/omap_hsmmc.c | 948 
> +--
>  include/configs/am57xx_evm.h |   2 -
>  include/configs/dra7xx_evm.h |   2 -
>  16 files changed, 1085 insertions(+), 73 deletions(-)
> 

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

Re: [U-Boot] [PATCH] doc: mxc_hab: Improve the config option list

[Breno Matheus Lima]

Hi Fabio,

2018-01-21 15:57 GMT-02:00 Fabio Estevam :
> From: Fabio Estevam 
>
> The original text is from the time that the config options were not
> converted to Kconfig.
>
> After the conversion to Kconfig only CONFIG_SECURE_BOOT and
> CONFIG_CMD_DEKBLOB need to be selected by the user.
>
> The other config options are automatically selected by the Kconfig
> logic.
>
> Signed-off-by: Fabio Estevam 

Reviewed-by: Breno Lima 

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

Re: [U-Boot] FW: u-boot v2016 vs v2013

[Fabio Estevam]

[Please do not top post in mailing lists]

On Thu, Jan 25, 2018 at 9:06 AM, Mehmet Ali İPİN
 wrote:
> Dear Fabio,
>
> I checked my PHY KSZ9021 schematic  (we used i.mx6 Dual Light) with boundary 
> devices sabre_light_revD(they used i.mx6 quad)  KSZ9021. We both use same 
> clock and data signals on both i.mx6 and PHY sides.
>
> I saw 6.25 MHz clock signal on RGMII_TXCLK pin of i.mx6dl which is connected 
> to the GTX_CLK input pin of PHY same as in sabre light. PHY is multiplying 
> this clock with 5 and generating 31.25 MHz, which is connected back to the 
> ENET_REF_CLK pin of i.mx6dl.
>
> I guess either my global ethernet clock or its pll clock registers or their 
> mask registers are not set correctly, to generate 25 MHz, instead of 6.25 MHz.
>
> May be you know, how may I correct them?

Maybe you need to call enable_fec_anatop_clock() to adjust the FEC clock.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [Patch] for drivers/net/phy/smsc.c to support SMSC LAN8741

[Arno Steffens]

Hello,
Be mild with me - my first patch to u-boot.

Signed-off-by: Arno Steffens 

diff -Nur u-boot-2017.11/drivers/net/phy/smsc.c 
u-boot-2017.11_patched/drivers/net/phy/smsc.c
--- u-boot-2017.11/drivers/net/phy/smsc.c 2017-11-14 02:08:06.0 +0100
+++ u-boot-2017.11_patched/drivers/net/phy/smsc.c 2018-01-24 12:17:39.326055469 
+0100
@@ -83,6 +83,16 @@
.shutdown = _shutdown,
};

+static struct phy_driver lan8741_driver = {
+ .name = "SMSC LAN8741",
+ .uid = 0x0007c120,
+ .mask = 0x0,
+ .features = PHY_BASIC_FEATURES,
+ .config = _config_aneg,
+ .startup = _startup,
+ .shutdown = _shutdown,
+};
+
static struct phy_driver lan8742_driver = {
.name = "SMSC LAN8742",
.uid = 0x0007c130,
@@ -99,6 +109,7 @@
phy_register(_driver);
phy_register(_driver);
phy_register(_driver);
+ phy_register(_driver);
phy_register(_driver);

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

[U-Boot] [PATCH v3 04/15] rpi: Determine PL011/Mini-UART availability at runtime

[Alexander Graf]

Firmware on the Raspberry Pi family of devices can dynamically configure either
the PL011, Mini-UART or no device at all to be routed to the user accessible
UART pins.

That means we need to always include both drivers, because we can never be sure
which of the two serial devices firmware actually chooses to use.

Signed-off-by: Alexander Graf 
---
 include/configs/rpi.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index cab8661779..2c84cf9a49 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -75,12 +75,9 @@
 #define CONFIG_MISC_INIT_R
 #endif
 
-/* Console UART */
-#if defined (CONFIG_BCM2837) || defined(CONFIG_TARGET_RPI_0_W)
+/* Console UART, can be configured dynamically in config.txt */
 #define CONFIG_BCM283X_MU_SERIAL
-#else
 #define CONFIG_PL01X_SERIAL
-#endif
 
 /* Console configuration */
 #define CONFIG_SYS_CBSIZE  1024
-- 
2.12.3

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

[U-Boot] [PATCH v3 09/15] pl010: Convert CONFIG_PL010_SERIAL to Kconfig

[Alexander Graf]

We want to use Kconfig logic to depend on whether pl01x devices
are built in, so let's convert their inclusion selection to Kconfig.

This round goes to pl010.

Signed-off-by: Alexander Graf 
---
 arch/arm/Kconfig | 1 +
 drivers/serial/Kconfig   | 6 ++
 include/configs/edb93xx.h| 1 -
 scripts/config_whitelist.txt | 1 -
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f6d57f5505..97b8249432 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -348,6 +348,7 @@ config ARCH_AT91
 config TARGET_EDB93XX
bool "Support edb93xx"
select CPU_ARM920T
+   select PL010_SERIAL
 
 config TARGET_ASPENITE
bool "Support aspenite"
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 7b20b47964..2816121dec 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -447,6 +447,12 @@ config INTEL_MID_SERIAL
  Select this to enable a UART for Intel MID platforms.
  This uses the ns16550 driver as a library.
 
+config PL010_SERIAL
+   bool "ARM PL010 driver"
+   depends on !DM_SERIAL
+   help
+ Select this to enable a UART for platforms using PL010.
+
 config ROCKCHIP_SERIAL
bool "Rockchip on-chip UART support"
depends on DM_SERIAL && SPL_OF_PLATDATA
diff --git a/include/configs/edb93xx.h b/include/configs/edb93xx.h
index 8fcc791ab4..fcad7c46dd 100644
--- a/include/configs/edb93xx.h
+++ b/include/configs/edb93xx.h
@@ -80,7 +80,6 @@
 #define CONFIG_SYS_CBSIZE  1024/* Console I/O buffer size */
 
 /* Serial port hardware configuration */
-#define CONFIG_PL010_SERIAL
 #define CONFIG_CONS_INDEX  0
 #define CONFIG_SYS_BAUDRATE_TABLE  {9600, 19200, 38400, 57600, \
 115200, 230400}
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index c98f262079..5ee6b07c6d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1626,7 +1626,6 @@ CONFIG_PIXIS_BRDCFG1_SSI_TDM_MASK
 CONFIG_PIXIS_BRDCFG1_SSI_TDM_SSI
 CONFIG_PIXIS_BRDCFG1_TDM
 CONFIG_PIXIS_SGMII_CMD
-CONFIG_PL010_SERIAL
 CONFIG_PL011_CLOCK
 CONFIG_PL011_SERIAL
 CONFIG_PL011_SERIAL_RLCR
-- 
2.12.3

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

[U-Boot] [PATCH v3 07/15] serial_bcm283x_mu: Fail loading if not muxed

[Alexander Graf]

The bcm283x mini-uart is only really usable as U-Boot serial output
when it is muxed to the UART pins of the RPi pin header.

So fail probing in case it is not muxed correctly, as in that case
firmware did not initialize it properly either.

Signed-off-by: Alexander Graf 
---
 drivers/serial/serial_bcm283x_mu.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/serial/serial_bcm283x_mu.c 
b/drivers/serial/serial_bcm283x_mu.c
index c6132b4463..40029fadbc 100644
--- a/drivers/serial/serial_bcm283x_mu.c
+++ b/drivers/serial/serial_bcm283x_mu.c
@@ -19,9 +19,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct bcm283x_mu_regs {
@@ -136,11 +138,37 @@ static const struct udevice_id bcm283x_mu_serial_id[] = {
{}
 };
 
+/*
+ * Check if this serial device is muxed
+ *
+ * The serial device will only work properly if it has been muxed to the serial
+ * pins by firmware. Check whether that happened here.
+ *
+ * @return true if serial device is muxed, false if not
+ */
+static bool bcm283x_is_serial_muxed(void)
+{
+   int serial_gpio = 15;
+   struct udevice *dev;
+
+   if (uclass_first_device(UCLASS_PINCTRL, ) || !dev)
+   return false;
+
+   if (pinctrl_get_gpio_mux(dev, 0, serial_gpio) != BCM2835_GPIO_ALT5)
+   return false;
+
+   return true;
+}
+
 static int bcm283x_mu_serial_ofdata_to_platdata(struct udevice *dev)
 {
struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
fdt_addr_t addr;
 
+   /* Don't spawn the device if it's not muxed */
+   if (!bcm283x_is_serial_muxed())
+   return -ENODEV;
+
addr = devfdt_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
-- 
2.12.3

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

Re: [U-Boot] [[PATCH v2] 1/8] sunxi: h3: Sync OTG and HCI nodes from Linux DT

[Jagan Teki]

On Fri, Jan 5, 2018 at 9:45 PM, Jun Nie  wrote:
> Allwinner H3 have a dual-routed USB PHY0 -- routed to either OHCI/EHCI
> or MUSB controller.
>
> Signed-off-by: Jun Nie 
> ---

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

Re: [U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7

[Auer, Lukas]

On Wed, 2018-01-24 at 19:41 +, Bryan O'Donoghue wrote:
> 
> On 24/01/18 17:41, Auer, Lukas wrote:
> > Thanks for adding me to the CC list.
> > I have experienced the same thing regarding the dec0 registers.
> > However, I don't understand why you want to detect secure mode in
> > the
> > kernel driver to skip RNG instantiation instead of instantiating
> > all
> > RNG state handles in the u-boot driver. 
> 
> That's what we are doing though.
> 
> This set instantiates everything in u-boot and then detects and skips
> in 
> the kernel if-and-only if
> 
> 1. Trust zone is detected
> 2. It looks to the Linux CAAM driver as if u-boot has initialised the
> h/w
> 
> For #2 I actually have to variants
> 
> 1. Which passes a DT parameter which indicates the kernel should
> skip 
> RNG init
> 
> 2. A module parameter which indicates the kernel should skip rng init
> 
> Could we discuss the kernel changes in the kernel thread ?
> 
> I believe we agree the u-boot side is right ?

Sorry, I haven't explained what I mean very well.

You are right in that sec_init() must be called to instantiate the RNG,
however the CAAM u-boot driver only partially does so. If you look at
function instantiate_rng() in both u-boot (drivers/crypto/fsl/jr.c) and
the kernel (drivers/crypto/caam/ctrl.c), you'll see that the kernel
loops over all available state handles whereas u-boot does not.

Fixing this in u-boot should mean that you can drop patch 5 and 6 from
your kernel series since the kernel should then skip over all state
handles.

I can send out a patch later today to fix this on the u-boot side.

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

Re: [U-Boot] [PATCH 2/3] power: pmic_max77686: remove the old pmic_max77686 file

[Lukasz Majewski]

On Thu, 25 Jan 2018 16:06:36 +0900
Jaehoon Chung  wrote:

> max77686 pmic is supporting with max77686.c under pmic/ and regulator/
> direnctroy. Remove pmic_max77686.c what didn't use anywhere.
> Instead, enable CONFIG_DM_REGULATOR_MAX77686 and
> CONFIG_DM_PMIC_MAX77686.
> 
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/power/pmic/Makefile|   1 -
>  drivers/power/pmic/pmic_max77686.c | 304
> - 2 files changed, 305
> deletions(-) delete mode 100644 drivers/power/pmic/pmic_max77686.c
> 
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 7d6c583d34..265b7cb2f6 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -29,7 +29,6 @@ obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
>  obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
>  obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
>  obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> -obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
>  obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
>  obj-$(CONFIG_POWER_PFUZE3000) += pmic_pfuze3000.o
>  obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> diff --git a/drivers/power/pmic/pmic_max77686.c
> b/drivers/power/pmic/pmic_max77686.c deleted file mode 100644
> index 8e653316d1..00
> --- a/drivers/power/pmic/pmic_max77686.c
> +++ /dev/null
> @@ -1,304 +0,0 @@
> -/*
> - *  Copyright (C) 2012 Samsung Electronics
> - *  Rajeshwari Shinde 
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -static const char max77686_buck_addr[] = {
> - 0xff, 0x10, 0x12, 0x1c, 0x26, 0x30, 0x32, 0x34, 0x36, 0x38
> -};
> -
> -static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV)
> -{
> - unsigned int hex = 0;
> -
> - switch (ldo) {
> - case 1:
> - case 2:
> - case 6:
> - case 7:
> - case 8:
> - case 15:
> - hex = (uV - 80) / 25000;
> - break;
> - default:
> - hex = (uV - 80) / 5;
> - }
> -
> - if (hex >= 0 && hex <= MAX77686_LDO_VOLT_MAX_HEX)
> - return hex;
> -
> - debug("%s: %ld is wrong voltage value for LDO%d\n",
> __func__, uV, ldo);
> - return 0;
> -}
> -
> -static int max77686_buck_volt2hex(int buck, ulong uV)
> -{
> - int hex = 0;
> -
> - if (buck < 5 || buck > 9) {
> - debug("%s: buck %d is not supported\n", __func__,
> buck);
> - return -EINVAL;
> - }
> -
> - hex = (uV - 75) / 5;
> -
> - if (hex >= 0 && hex <= MAX77686_BUCK_VOLT_MAX_HEX)
> - return hex;
> -
> - debug("%s: %ld is wrong voltage value for BUCK%d\n",
> -   __func__, uV, buck);
> - return -EINVAL;
> -}
> -
> -int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
> -{
> - unsigned int val, ret, hex, adr;
> -
> - if (ldo < 1 || ldo > 26) {
> - printf("%s: %d is wrong ldo number\n", __func__,
> ldo);
> - return -EINVAL;
> - }
> -
> - adr = MAX77686_REG_PMIC_LDO1CTRL1 + ldo - 1;
> - hex = max77686_ldo_volt2hex(ldo, uV);
> -
> - if (!hex)
> - return -EINVAL;
> -
> - ret = pmic_reg_read(p, adr, );
> - if (ret)
> - return ret;
> -
> - val &= ~MAX77686_LDO_VOLT_MASK;
> - val |= hex;
> - ret |= pmic_reg_write(p, adr, val);
> -
> - return ret;
> -}
> -
> -int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV)
> -{
> - unsigned int val, adr;
> - int hex, ret;
> -
> - if (buck < 5 || buck > 9) {
> - printf("%s: %d is an unsupported bucket number\n",
> -__func__, buck);
> - return -EINVAL;
> - }
> -
> - adr = max77686_buck_addr[buck] + 1;
> - hex = max77686_buck_volt2hex(buck, uV);
> -
> - if (hex < 0)
> - return hex;
> -
> - ret = pmic_reg_read(p, adr, );
> - if (ret)
> - return ret;
> -
> - val &= ~MAX77686_BUCK_VOLT_MASK;
> - ret |= pmic_reg_write(p, adr, val | hex);
> -
> - return ret;
> -}
> -
> -int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
> -{
> - unsigned int val, ret, adr, mode;
> -
> - if (ldo < 1 || 26 < ldo) {
> - printf("%s: %d is wrong ldo number\n", __func__,
> ldo);
> - return -EINVAL;
> - }
> -
> - adr = MAX77686_REG_PMIC_LDO1CTRL1 + ldo - 1;
> -
> - /* mode */
> - switch (opmode) {
> - case OPMODE_OFF:
> - mode = MAX77686_LDO_MODE_OFF;
> - break;
> - case OPMODE_STANDBY:
> - switch (ldo) {
> - case 2:
> - case 6:
> - case 7:
> - case 8:
> - case 10:
> - case 11:
> - case 12:
> - case 14:
> - case 15:
> - case 16:
> - 

Re: [U-Boot] [PATCH 1/3] configs: trats2: enable the max77686 regulator config

[Lukasz Majewski]

On Thu, 25 Jan 2018 16:06:35 +0900
Jaehoon Chung  wrote:

> Enable the CONFIG_DM_REGULATOR_MAX77686 for using regulator driver.
> 
> Signed-off-by: Jaehoon Chung 
> ---
>  configs/trats2_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/trats2_defconfig b/configs/trats2_defconfig
> index aaa25a9bc7..dab62530e7 100644
> --- a/configs/trats2_defconfig
> +++ b/configs/trats2_defconfig
> @@ -46,6 +46,8 @@ CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_S5P=y
>  CONFIG_DM_PMIC=y
>  CONFIG_DM_PMIC_MAX77686=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_MAX77686=y
>  CONFIG_USB=y
>  CONFIG_DM_USB=y
>  CONFIG_USB_GADGET=y

Reviewed-by: Lukasz Majewski 

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


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

Re: [U-Boot] FW: u-boot v2016 vs v2013

[Lukasz Majewski]

Hi,

> On Wed, Jan 24, 2018 at 10:26 AM, Mehmet Ali İPİN
>  wrote:
> > Dear Estevam,
> >
> > I am (in fact hardware engineer developed the PCB)  not an
> > experienced u-boot/linux developer, therefore sorry for my complex
> > questions. I will check the forum, and google for this message, but
> > you may help me to start the right path.
> >
> > May be, according to your experience you can advise me to check
> > some (phy/mac) register, pin status, clock values, Or give the name
> > of threads in u-boot or nxp imx6 forum which is about similar dhcp
> > events, if you remember.
> >
> > Since its a new PCB board, so we did not load/run the linux yet.  
> 
> Try looking at existing supported boards that use KSZ9021, such as
> board/boundary/nitrogen6x/nitrogen6x.c for example.

If I may add a remark here. If this is a new board - then look for
RGMII's internal delays, which are set in the ETH PHY chip. You may get
default values, which may not be correct in your new PCB design.

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


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

Re: [U-Boot] [U-Boot, v3, 16/20] net: gmac_rockchip: Add support for the RK3228 GMAC

[Philipp Tomsich]

> The GMAC in the RK3228 once again is identical to the incarnation in
> the RK3288 and the RK3399, except for where some of the configuration
> and control registers are located in the GRF.
> 
> This adds the RK3368-specific logic necessary to reuse this driver.
> 
> Signed-off-by: David Wu 
> ---
> 
> Changes in v3:
> - None
> 
> Changes in v2:
> - New patch
> 
>  drivers/net/gmac_rockchip.c | 85 
> +
>  1 file changed, 85 insertions(+)
> 

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

Re: [U-Boot] [U-Boot, v3, 15/20] clk: rockchip: Add rk322x gamc clock support

[Philipp Tomsich]

> Assuming mac_clk is fed by an external clock, set clk_rmii_src
> clock select control register from IO for rgmii interface.
> 
> Signed-off-by: David Wu 
> ---
> 
> Changes in v3:
> - Add "set parent" for gmac
> - Add internal mac clk div_sel for gmac
> 
> Changes in v2:
> - New patch
> 
>  drivers/clk/rockchip/clk_rk322x.c | 107 
> ++
>  1 file changed, 107 insertions(+)
> 

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

Re: [U-Boot] [U-Boot, v3, 08/20] clk: rockchip: Add rk3328 gamc clock support

[Philipp Tomsich]

> The rk3328 soc has two gmac controllers, one is gmac2io,
> the other is gmac2phy. We use the gmac2io rgmii interface
> for 1000M phy here.
> 
> Signed-off-by: David Wu 
> ---
> 
> Changes in v3:
> - Add "set parent" for gmac2io
> - Add internal mac clk div_sel for gmac2io
> 
> Changes in v2:
> - New patch
> 
>  drivers/clk/rockchip/clk_rk3328.c  | 178 
> +
>  include/dt-bindings/clock/rk3328-cru.h |   6 +-
>  2 files changed, 181 insertions(+), 3 deletions(-)
> 

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

Re: [U-Boot] [U-Boot, v3, 04/20] rockchip: pinctrl: rv1108: Move the iomux definitions into pinctrl-driver

[Philipp Tomsich]

> If we include both the rk3288_grf.h and rv1108_grf.h, it will cause the
> conflicts of redefinition. Clean the iomux definitions at grf_rv1108.h,
> and move them into pinctrl-driver.
> 
> Signed-off-by: David Wu 
> Reviewed-by: Philipp Tomsich 
> ---
> 
> Changes in v3:
> - Fix the wrong define for uart2M0
> 
> Changes in v2:
> - New patch
> 
>  arch/arm/include/asm/arch-rockchip/grf_rv1108.h | 399 
> 
>  board/rockchip/evb_rv1108/evb_rv1108.c  |  17 +
>  drivers/pinctrl/rockchip/pinctrl_rv1108.c   | 399 
> 
>  3 files changed, 416 insertions(+), 399 deletions(-)
> 

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