Re: [U-Boot] [PATCH 28/41] net: fec_mxc: Add the init_clk_fec function

[Peng Fan]

Hi Joe, Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: 2018年6月13日 9:26
> To: Joe Hershberger 
> Cc: Peng Fan ; Stefano Babic ; Fabio
> Estevam ; u-boot 
> Subject: Re: [U-Boot] [PATCH 28/41] net: fec_mxc: Add the init_clk_fec 
> function
> 
> Hi,
> 
> On 12 June 2018 at 12:27, Joe Hershberger  wrote:
> >
> > Hi Peng,
> >
> > On Mon, May 28, 2018 at 7:25 AM, Peng Fan  wrote:
> > > From: Ye Li 
> > >
> > > When the power domain driver is enabled, we need to enable clocks
> > > after power domain on. So the clock settings can't set in
> > > board_init, needs to set them when the device is probed. Add this
> > > weak function in driver, that SoC codes can implement the clock settings.
> >
> > Can you not use clock infrastructure in DM to handle this. We don't
> > really want these direct calls out of drivers like this. Simon?
> >
> 
> Yes that is definitely bad.
> 
> Probably the easiest option is to add a clock driver.

I'll give a try to add a clock DM driver.

Thanks,
Peng.

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

Re: [U-Boot] [PATCH 00/41] imx: add i.MX8QXP support

[Peng Fan]

Hi Fabio

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年6月12日 22:08
> To: Peng Fan 
> Cc: sba...@denx.de; Fabio Estevam ;
> u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 00/41] imx: add i.MX8QXP support
> 
> Hi Peng,
> 
> On Tue, Jun 12, 2018 at 6:43 AM, Peng Fan  wrote:
> > Hi Stefano, Fabio,
> >
> > Sorry for the bother in patch 1, that patch is big. So ask here.
> > Do you have any comments on the patchset?
> 
> It would be better if you could split this 41 patch series into smaller 
> pieces.
> 
> For example: you could send driver related patches to each subsystem
> maintainer separately instead of being part of this the huge series.

Ok. I'll split them into small patchset in next version.

> 
> I will try to provide some feedback during this week.

Thanks.

Thanks,
Peng.
> 
> Thanks for working on this.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/3] net: Sanitize DHCP variable override

[Rick Chen]

> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, June 14, 2018 6:04 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); Joe Hershberger; Greentime Ying-Han Hu(胡英
> 漢); Simon Glass
> Subject: [PATCH v2 0/3] net: Sanitize DHCP variable override
>
> While trying to boot from network on a RISC-V AX25 platform, I saw that the
> DHCP IP address did not get populated from the DHCP server IP address. The
> reason for that was simple: CONFIG_BOOTP_SERVERIP was set.
>
> I don't know the history of that option, but it seems to decrease intuitivity 
> levels
> of the dhcp command rather than improve it.
>
> What I usually would expect is that explicitly set values populate through all
> layers. So if I set a TFTP file name, it populates. If I set a target IP 
> address, it
> populates. If I don't set anything, the values get filled in automatically.
>
> This patch set is trying to move us into that direction without breaking 
> people
> that rely on the existing behavior. With this patch set applied, boards have 
> the
> option to prefer the 'serverip'
> environment variable (ax25-ae350 gets moved to it) over the DHCP given address
> and any value explicitly set on the command line is always preferred.
>
> This hopefully makes the command line a bit more intuitive.
>
> v1 -> v2:
>
>   - new patch: net: Prefer command line arguments
>   - remove README entry
>   - improve Kconfig help texts
>
>
> Alexander Graf (3):
>   net: Prefer command line arguments
>   net: Add option to prefer bootp/dhcp serverip
>   ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP
>
>  cmd/Kconfig  | 11 +++
>  cmd/net.c| 10 --
>  configs/ax25-ae350_defconfig |  1 +
>  include/configs/ax25-ae350.h |  1 -
>  include/net.h|  2 ++
>  net/bootp.c  | 10 --
>  net/net.c|  2 ++
>  7 files changed, 32 insertions(+), 5 deletions(-)
>
> --
> 2.12.3

Hi Alex

The V2 is ok about the dhcp verification.

Message as below:

U-Boot 2018.07-rc1-00075-g3411a40 (Jun 15 2018 - 14:05:21 +0800)

DRAM:  1 GiB
No arch specific invalidate_icache_all available!
Flash: 64 MiB
MMC:   mmc@f0e0: 0
Loading Environment from SPI Flash... SF: Detected mx25u1635e with
page size 256 Bytes, erase size 4 KiB, total 2 MiB
OK
In:serial@f030
Out:   serial@f030
Err:   serial@f030
Net:   no alias for ethernet0

Warning: mac@e010 (eth0) using random MAC address - 7e:c1:32:b2:20:cf
eth0: mac@e010
Hit any key to stop autoboot:  0
RISC-V #
RISC-V # env print
baudrate=38400
bootcmd=fatload mmc 0:1 0x2000 ae350_64.dtb;fatload mmc 0:1 0x0
bbl-ae350.bin;go 0x0
bootdelay=3
bootfile=10.0.4.97:boomimage-310y-ag101p.bin
ethact=mac@e010
fdtcontroladdr=3fede290
fileaddr=60
filesize=1bb7d34
stderr=serial@f030
stdin=serial@f030
stdout=serial@f030

Environment size: 329/8188 bytes
RISC-V # dhcp 0x60 10.0.4.97:boomimage-310y-ag101p.bin
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 10.0.4.124 (4596 ms)
Using mac@e010 device
TFTP from server 10.0.4.97; our IP address is 10.0.4.124
Filename 'boomimage-310y-ag101p.bin'.
Load address: 0x60
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 
 174.8 KiB/s
done
Bytes transferred = 13938796 (d4b06c hex)
RISC-V #

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

Re: [U-Boot] [PATCH 4/5] serial: zynq: Check priv pointer get via dev_get_priv()

[Michal Simek]

Hi Simon,

On 14.6.2018 16:16, Simon Glass wrote:
> Hi Michal,
> 
> On 14 June 2018 at 07:05, Michal Simek  wrote:
>> On 14.6.2018 14:58, Simon Glass wrote:
>>> Hi,
>>>
>>> On 14 June 2018 at 03:32, Michal Simek  wrote:
 Make sure that functions are working with proper strcture.

 Signed-off-by: Michal Simek 
 ---

 Reported by: Coverity (local)

 ---
  drivers/serial/serial_zynq.c | 27 ---
  1 file changed, 24 insertions(+), 3 deletions(-)
>>>
>>> But priv cannot be NULL if the device has been probed. So this check
>>> is confusing at best.
>>>
>>> If this is from coverity, perhaps you can find a way to mask it?
>>
>> Let me talk to local guy how to do it.
>>
>> Also can you please look at that driver and tell me if we using private
>> structure is used properly?
>> Because I think we should be using platdata instead.
>> What was that rule for using platdate versus private data?
> 
> Private data is created when the device is probed and freed when the
> device is removed.
> 
> Platform data is created when the device is bound, and survives
> probe/remove cycles.
> 
> Strictly speaking, platform data should be used to hold the decoded
> device tree properties. Private data should be used for run-time
> things the device needs to keep track of.

ok. It means we need to fix at least this driver.

Thanks,
Michal

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

[U-Boot] sandbox: Net: No ethernet found.

[Heinrich Schuchardt]

Hello Simon,

when I run sandbox_defconfig I always get
Net:   No ethernet found.

The dm command shows no driver attached to uclass 21: eth. Why are the
sandbox and sandbox-raw drivers not loaded?

device_bind_common is not called for these drivers.

arch/sandbox/dts/sandbox.dts makes assumptions about the naming of
interfaces:

host-raw-interface = "eth0"

With systemd eth0 tends not to exist. The interfaces on my Debian Buster
system the interfaces are called lo, enp0s25, and wlp12s0.

Shouldn't we use if_nameindex() to enumerate the interfaces?

Best regards

Heinrich



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

[U-Boot] [PATCH] net: fastboot: Fix build when FASTBOOT_FLASH is disabled

[Alex Kiernan]

When building without FASTBOOT_FLASH we don't include the intermediate
update callback to keep the client alive, so ensure we don't try setting
it here.

Signed-off-by: Alex Kiernan 
---

 net/fastboot.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/fastboot.c b/net/fastboot.c
index a9f7c0743d..8afc5529cd 100644
--- a/net/fastboot.c
+++ b/net/fastboot.c
@@ -309,7 +309,9 @@ void fastboot_start_server(void)
 
fastboot_our_port = WELL_KNOWN_PORT;
 
+#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
fastboot_set_progress_callback(fastboot_timed_send_info);
+#endif
net_set_udp_handler(fastboot_handler);
 
/* zero out server ether in case the server ip has changed */
-- 
2.17.0

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

[U-Boot] [PATCH 1/1] common: print \n in initr_scsi()

[Heinrich Schuchardt]

Typically init_scsi() does not output anything. So initr_scsi() should
provide a \n or we may see borked output like

SCSI:  Net:   No ethernet found.

as observed with sandbox_defconfig.

Signed-off-by: Heinrich Schuchardt 
---
 common/board_r.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/board_r.c b/common/board_r.c
index 6b297068bd..23b5d2c21b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -553,6 +553,7 @@ static int initr_scsi(void)
 {
puts("SCSI:  ");
scsi_init();
+   puts("\n");
 
return 0;
 }
-- 
2.17.1

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

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

[Marek Vasut]

On 06/14/2018 11:42 PM, Tom Rini wrote:
> On Thu, Jun 14, 2018 at 10:58:22PM +0200, Marek Vasut wrote:
>> On 06/14/2018 03:07 PM, Tom Rini wrote:
>>> On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote:
 On 06/14/2018 01:19 PM, Tom Rini wrote:
> On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote:
>
>> The following changes since commit 
>> 813d1fb56dc0af9567feb86cd71c49f14662044b:
>>
>>   Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08
>> 10:08:20 -0400)
>>
>> are available in the Git repository at:
>>
>>   git://git.denx.de/u-boot-sh.git master
>>
>> for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9:
>>
>>   ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43
>> +0200)
>>
>
> NAK.  First, there are a lot of should be fix style errors in
> the new files in drivers/pinctrl/renesas/.  Second, you have build
> failures:
> https://travis-ci.org/trini/u-boot/jobs/391819805
> https://travis-ci.org/trini/u-boot/jobs/391819826

 Great, thanks!

 If the travis didn't vomit constant false positives recently, I'd trust
 it. With what it does now, I cannot trust it anymore.
>>>
>>> Can you elaborate?
>>
>> Don't you see the constant random timeouts during builds for some
>> targets? I cannot get a successful build on the first try almost never
>> these days, I have to keep restarting until I see that different targets
>> failed during each build with a timeout and then extrapolate that the
>> build is actually fine from that. It's annoying.
> 
> I see maybe 2-5 of those per day when I'm busy, which is annoying, but
> I've never had it fail a second time in a row.

Good for you.

>> And then there is the other category of boards which indicate "red"
>> failure marker due to ie. DT problems, which if you pull DTs from Linux
>> is something you cannot really fix on the U-Boot side right away, but
>> rather fix in Linux and then resync.
> 
> Yes, there are DT warnings that should be fixed.  But they aren't travis
> errors, only actual fail to builds (like in the above, which indeed are
> confusingly DT related, but not a travis problem at all, I see them
> locally too) and new C warnings.

I'd prefer to see only errors which are relevant in the logs. Oh well.

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

[U-Boot] [PATCH V2 1/2] pinctrl: renesas: Sync Gen2 PFC tables with Linux v4.17

[Marek Vasut]

Sync the PFC tables with Linux v4.17.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
V2: Fix build errors

 drivers/pinctrl/renesas/pfc-r8a7790.c |   8 +-
 drivers/pinctrl/renesas/pfc-r8a7791.c |  84 -
 drivers/pinctrl/renesas/pfc-r8a7794.c | 473 ++
 3 files changed, 559 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/renesas/pfc-r8a7790.c 
b/drivers/pinctrl/renesas/pfc-r8a7790.c
index 734df477d3..ad492b5366 100644
--- a/drivers/pinctrl/renesas/pfc-r8a7790.c
+++ b/drivers/pinctrl/renesas/pfc-r8a7790.c
@@ -1825,8 +1825,8 @@ static const unsigned int avb_mii_pins[] = {
RCAR_GP_PIN(2, 2),
 
RCAR_GP_PIN(2, 7), RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
-   RCAR_GP_PIN(2, 10), RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 10),
-   RCAR_GP_PIN(3, 12),
+   RCAR_GP_PIN(2, 10), RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 9),
+   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 12),
 };
 static const unsigned int avb_mii_mux[] = {
AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
@@ -1836,8 +1836,8 @@ static const unsigned int avb_mii_mux[] = {
AVB_RXD3_MARK,
 
AVB_RX_ER_MARK, AVB_RX_CLK_MARK, AVB_RX_DV_MARK,
-   AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_CLK_MARK,
-   AVB_COL_MARK,
+   AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_ER_MARK,
+   AVB_TX_CLK_MARK, AVB_COL_MARK,
 };
 static const unsigned int avb_gmii_pins[] = {
RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
diff --git a/drivers/pinctrl/renesas/pfc-r8a7791.c 
b/drivers/pinctrl/renesas/pfc-r8a7791.c
index 4305589697..0b6a1b0c1d 100644
--- a/drivers/pinctrl/renesas/pfc-r8a7791.c
+++ b/drivers/pinctrl/renesas/pfc-r8a7791.c
@@ -4146,6 +4146,32 @@ static const unsigned int ssi9_ctrl_b_mux[] = {
SSI_SCK9_B_MARK, SSI_WS9_B_MARK,
 };
 
+/* - TPU  
*/
+static const unsigned int tpu_to0_pins[] = {
+   RCAR_GP_PIN(6, 14),
+};
+static const unsigned int tpu_to0_mux[] = {
+   TPU_TO0_MARK,
+};
+static const unsigned int tpu_to1_pins[] = {
+   RCAR_GP_PIN(1, 17),
+};
+static const unsigned int tpu_to1_mux[] = {
+   TPU_TO1_MARK,
+};
+static const unsigned int tpu_to2_pins[] = {
+   RCAR_GP_PIN(1, 18),
+};
+static const unsigned int tpu_to2_mux[] = {
+   TPU_TO2_MARK,
+};
+static const unsigned int tpu_to3_pins[] = {
+   RCAR_GP_PIN(1, 24),
+};
+static const unsigned int tpu_to3_mux[] = {
+   TPU_TO3_MARK,
+};
+
 /* - USB0 --- 
*/
 static const unsigned int usb0_pins[] = {
RCAR_GP_PIN(7, 23), /* PWEN */
@@ -4432,7 +4458,7 @@ static const unsigned int vin2_clk_mux[] = {
 };
 
 static const struct {
-   struct sh_pfc_pin_group common[342];
+   struct sh_pfc_pin_group common[346];
struct sh_pfc_pin_group r8a779x[9];
 } pinmux_groups = {
.common = {
@@ -4744,6 +4770,10 @@ static const struct {
SH_PFC_PIN_GROUP(ssi9_data_b),
SH_PFC_PIN_GROUP(ssi9_ctrl),
SH_PFC_PIN_GROUP(ssi9_ctrl_b),
+   SH_PFC_PIN_GROUP(tpu_to0),
+   SH_PFC_PIN_GROUP(tpu_to1),
+   SH_PFC_PIN_GROUP(tpu_to2),
+   SH_PFC_PIN_GROUP(tpu_to3),
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
VIN_DATA_PIN_GROUP(vin0_data, 24),
@@ -4827,6 +4857,10 @@ static const char * const can0_groups[] = {
"can0_data_d",
"can0_data_e",
"can0_data_f",
+   /*
+* Retained for backwards compatibility, use can_clk_groups in new
+* designs.
+*/
"can_clk",
"can_clk_b",
"can_clk_c",
@@ -4838,6 +4872,21 @@ static const char * const can1_groups[] = {
"can1_data_b",
"can1_data_c",
"can1_data_d",
+   /*
+* Retained for backwards compatibility, use can_clk_groups in new
+* designs.
+*/
+   "can_clk",
+   "can_clk_b",
+   "can_clk_c",
+   "can_clk_d",
+};
+
+/*
+ * can_clk_groups allows for independent configuration, use can_clk function
+ * in new designs.
+ */
+static const char * const can_clk_groups[] = {
"can_clk",
"can_clk_b",
"can_clk_c",
@@ -5260,6 +5309,13 @@ static const char * const ssi_groups[] = {
"ssi9_ctrl_b",
 };
 
+static const char * const tpu_groups[] = {
+   "tpu_to0",
+   "tpu_to1",
+   "tpu_to2",
+   "tpu_to3",
+};
+
 static const char * const usb0_groups[] = {
"usb0",
 };
@@ -5309,7 +5365,7 @@ static const char * const vin2_groups[] = {
 };
 
 static const struct {
-   struct sh_pfc_function common[56];
+   struct sh_pfc_function common[58];
struct sh_pfc_function r8a779x[2];
 } pinmux_functions = {
.common = {
@@ -5317,6 +5373,7 @@ static const struct {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(can0),
SH_PFC_FUNCTION(can1),
+  

[U-Boot] [PATCH 1/1] efi_selftest: update .gitignore

[Heinrich Schuchardt]

The following generated files should be ignored by git:
efi_miniapp_file_image_exit.h
efi_miniapp_file_image_return.h

*.so files are normally deleted during the build but should be
ignored too.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/.gitignore | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/efi_selftest/.gitignore b/lib/efi_selftest/.gitignore
index c527e464e5..293a17b818 100644
--- a/lib/efi_selftest/.gitignore
+++ b/lib/efi_selftest/.gitignore
@@ -1,2 +1,4 @@
-efi_miniapp_file_image.h
+efi_miniapp_file_image_exit.h
+efi_miniapp_file_image_return.h
 *.efi
+*.so
-- 
2.17.1

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

Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Heinrich Schuchardt]

On 06/14/2018 10:50 PM, Mark Kettenis wrote:
>> From: Heinrich Schuchardt 
>> Date: Thu, 14 Jun 2018 19:55:51 +0200
>>
>> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
>>> This series makes it possible to run EFI applications in non-secure
>>> mode.  It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and
>>> Banana Pi boards using the PSCI implementation provided by U-Boot.
>>>
>>> The second version avoids using r3 to pass the original stack pointer.
>>> For some reason that register gets clobbered on the Banana Pi.  Instead
>>> this version just migrates SP_svc to SP_hyp.
>>>
>>> This third version avoids saving r3 on the stack and fixes an include
>>> guard as suggested by Alexander Graf.
>>>
>>> Mark Kettenis (3):
>>>   ARM: HYP/non-sec: migrate stack
>>>   efi_loader: ARM: run EFI payloads non-secure
>>>   Revert "efi_loader: no support for ARMV7_NONSEC=y"
>>>
>>>  arch/arm/cpu/armv7/nonsec_virt.S |  2 ++
>>>  cmd/bootefi.c| 32 
>>>  doc/README.uefi  |  2 --
>>>  lib/efi_loader/Kconfig   |  2 --
>>>  4 files changed, 34 insertions(+), 4 deletions(-)
>>>
>> Hello Mark,
>>
>> with this patch series running bootefi hello twice in sequence fails on
>> the BananaPi.
>>
>> => bootefi hello
>> Scanning disk m...@01c0f000.blk...
>> Found 3 disks
>> WARNING: booting without device tree
>> ## Starting EFI application at 4200 ...
>> WARNING: using memory device/image path, this may confuse some payloads!
>> Hello, world!
>> Running on UEFI 2.7
>> Have SMBIOS table
>> Load options: earlyprintk nosmp
>> ## Application terminated, r = 0
>> => bootefi hello
>> WARNING: booting without device tree
>> ## Starting EFI application at 4200 ...
>> WARNING: using memory device/image path, this may confuse some payloads!
>> 
> 
> Yeah.  Trying to enter non-secure mode when we're already in
> non-secure mode doesn't really work.  We should skip the switching
> code in that case.  Now checking whether we are in non-secure mode
> isn't really possible.  But I guess we can set a variable and check it
> before we go down the switching codepath.  With that in I can exit the
> OpenBSD bootloader and then reload and run it again.  I'll include
> that fix in the next respin.

Hello Mark,

you might move the call to switch to non-secure mode to efi_init_obj_list().

Best regards

Heinrich

> 
>> Please, keep in mind that we expect multiple EFI binaries to be executed
>> in sequence. E.g. the first binary installs a driver. The second is the
>> application using it.
>>
>> Running iPXE's snp.efi binary shows changed behavior on the console. New
>> characters are displayed in "slow motion" (3 characters per second).
>> Setting up the network interface fails in iPXE.
> 
> The same happens on my Banana Pi.  But not on the imx7 board.  
> 

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

[U-Boot] [RFC] sandbox: Enable 1:1 map

[Alexander Graf]

So far we've always had a split address space situation with
"U-Boot addresses" (a number space starting from 0) and "host
virtual addresses" (128MB mapped randomly in address space).

This meant that we had to make sure all code is properly aware that
addresses and pointers are not the same thing, so they must not cast
between the two.

However, most real boards do actually have a 1:1 map. So it's
much easier to just expose the same in sandbox.

So this patch maps sandbox RAM from 0x800-0x1000. This
address range fits just fine on both 32bit and 64bit systems.

---

The patch is on top of my "efi-sandbox-v3" tree. But I'm sure
it easily applies on vanilla too.

I also don't know if this really is the best path forward, but
at least it's one that gets rid of the one awkward target that
does not have a 1:1 map ;)
---
 arch/sandbox/cpu/cpu.c | 18 ++
 arch/sandbox/cpu/state.c   |  4 ++--
 arch/sandbox/cpu/u-boot.lds|  3 +++
 arch/sandbox/include/asm/io.h  | 17 +
 common/board_f.c   |  4 +++-
 configs/sandbox64_defconfig|  6 +++---
 configs/sandbox_defconfig  |  6 +++---
 configs/sandbox_flattree_defconfig |  4 ++--
 configs/sandbox_noblk_defconfig|  4 ++--
 configs/sandbox_spl_defconfig  |  4 ++--
 include/configs/sandbox.h  | 22 +++---
 11 files changed, 38 insertions(+), 54 deletions(-)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 23d8b70648..5f5d6c9158 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -58,16 +58,6 @@ int cleanup_before_linux_select(int flags)
return 0;
 }
 
-void *phys_to_virt(phys_addr_t paddr)
-{
-   return (void *)(gd->arch.ram_buf + paddr);
-}
-
-phys_addr_t virt_to_phys(void *vaddr)
-{
-   return (phys_addr_t)((uint8_t *)vaddr - gd->arch.ram_buf);
-}
-
 void *map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags)
 {
 #if defined(CONFIG_PCI) && !defined(CONFIG_SPL_BUILD)
@@ -103,11 +93,6 @@ void sandbox_set_enable_pci_map(int enable)
enable_pci_map = enable;
 }
 
-phys_addr_t map_to_sysmem(const void *ptr)
-{
-   return (u8 *)ptr - gd->arch.ram_buf;
-}
-
 void flush_dcache_range(unsigned long start, unsigned long stop)
 {
 }
@@ -187,7 +172,8 @@ void longjmp(jmp_buf jmp, int ret)
  */
 void efi_add_known_memory(void)
 {
-   u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
+   u64 ram_start = (uintptr_t)map_sysmem(CONFIG_SYS_SDRAM_BASE,
+ gd->ram_size);
u64 ram_size = gd->ram_size;
u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index cc50819ab9..75ad564274 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -12,6 +12,7 @@
 /* Main state record for the sandbox */
 static struct sandbox_state main_state;
 static struct sandbox_state *state;/* Pointer to current state record */
+static __attribute__ ((section (".ram"))) u8 
sandbox_ram[CONFIG_SYS_SDRAM_SIZE];
 
 static int state_ensure_space(int extra_size)
 {
@@ -366,8 +367,7 @@ int state_init(void)
state = &main_state;
 
state->ram_size = CONFIG_SYS_SDRAM_SIZE;
-   state->ram_buf = os_malloc(state->ram_size);
-   assert(state->ram_buf);
+   state->ram_buf = sandbox_ram;
 
state_reset_for_test(state);
/*
diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 3a6cf55eb9..8d0dfadfe0 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -47,6 +47,9 @@ SECTIONS
*(.__efi_runtime_rel_stop)
}
 
+   .ram 0x800 : {
+   *(.ram)
+   }
 }
 
 INSERT BEFORE .data;
diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index 81b7750628..fe792200a7 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -6,12 +6,6 @@
 #ifndef __SANDBOX_ASM_IO_H
 #define __SANDBOX_ASM_IO_H
 
-void *phys_to_virt(phys_addr_t paddr);
-#define phys_to_virt phys_to_virt
-
-phys_addr_t virt_to_phys(void *vaddr);
-#define virt_to_phys virt_to_phys
-
 void *map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags);
 #define map_physmem map_physmem
 
@@ -23,20 +17,19 @@ void unmap_physmem(const void *vaddr, unsigned long flags);
 
 #include 
 
-/* For sandbox, we want addresses to point into our RAM buffer */
 static inline void *map_sysmem(phys_addr_t paddr, unsigned long len)
 {
-   return map_physmem(paddr, len, MAP_WRBACK);
+   return (void *)(unsigned long)paddr;
 }
 
-/* Remove a previous mapping */
 static inline void unmap_sysmem(const void *vaddr)
 {
-   unmap_physmem(vaddr, MAP_WRBACK);
 }
 
-/* Map from a pointer to our RAM buffer */
-phys_addr_t map_to_sysmem(const void *ptr);
+static inline phys_addr_t map_to_s

Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()

[Alexander Graf]

On 14.06.18 23:35, Simon Glass wrote:
> Hi Alex,
> 
> On 14 June 2018 at 13:51, Alexander Graf  wrote:
>>
>>
>> On 14.06.18 21:01, Simon Glass wrote:
>>> On 14 June 2018 at 12:22, Alexander Graf  wrote:
 The fs_read() function wants to get an address rather than the
 pointer to a buffer.

 So let's convert the passed buffer from pointer back a the address
 to make efi_loader on sandbox happier.

 Signed-off-by: Alexander Graf 

 ---

 v1 -> v2:

   - Clarify address vs pointer
   - include mapmem.h
 ---
  lib/efi_loader/efi_file.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> Reviewed-by: Simon Glass 
>>>
>>
>> I actually think that this patch tackles the problem the wrong way
>> around. I've cooked up another one that converts fs_read() and
>> fs_write() to instead take a pointer - which really is what most users
>> of the API want in the first place:
>>
>>
>> https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f
> 
> Actually this is a pretty good exposition of why we don't want to use
> pointers everywhere. U-Boot uses addresses all over the place. Even a
> search for something as specific as "ulong addr" gets over 200
> matches. If we go down this path we will end up changing a pretty
> fundamental part of U-Boot, and I don't think it is a good idea to do
> that. Addresses are easy to understand, can be added/subtracted
> without pointer arithmetic, can be easily converted to pointers as
> needed, can be 32-bits long on sandbox, etc.

I tend to disagree with this. Most code in U-Boot actually consumes
pointers rather than addresses.

> So I think we should step back from the abyss here and stick with the
> way sandbox currently deals with addresses. It works well, is pretty
> easy to understand, allows debugging which is just as easy on sandbox
> as other archs (since they both uses addresses until basically the
> final access), the addresses are typically small values that start at
> 0 which much is easier to read than (e.g.) 7f1b58c8b008.
> 
> Here for example is the output from starting U-Boot with debugging in
> board_f.c (something I have turned on a lot when refactoring and
> debugging the init sequence):
> 
> U-Boot 2018.07-rc1-00142-g134ea86c7f-dirty (Jun 14 2018 - 15:04:04 -0600)
> 
> DRAM:  Monitor len: 00395AB0
> Ram size: 0800
> Ram top: 0800
> Reserving 3670k for U-Boot at: 07c6a000
> Reserving 32776k for malloc() at: 05c68000
> Reserving 120 Bytes for Board Info at: 05c67f88
> Reserving 472 Bytes for Global Data at: 05c67db0
> Reserving 4352 Bytes for FDT at: 05c66cb0
> Reserving 0x3c8 Bytes for bootstage at: 05c668e8
> 
> RAM Configuration:
> Bank #0: 0 128 MiB
> 
> DRAM:  128 MiB
> New Stack Pointer is: 05c668d0
> Copying bootstage from 7fdb0056e038 to 7fdb061c48f0, size 3c8
> Relocation Offset is: 07c6a000
> Relocating to 07c6a000, new gd at 05c67db0, sp at 05c668d0
> 
> 
> If we use pointers we get things like this:
> 
> Reserving 3670k for U-Boot at: 7f1b58c8b008
> 
> I just don't want to deal with 64-bit addresses when debugging things,
> and there really is no point. The map_sysmem() function provides a
> nice and easy way to cast an address to a pointer, and it works on all
> architectures.

Ok, circling back to square 1. The main issue we're facing here is that
most code in U-Boot does not really understand the difference between
virtual and physical addresses - it just simply assumes a 1:1 map.

With sandbox, we do not have a 1:1 map anymore - any address is
somewhere else than its pointer.

We have a few options:

  1) Deal with pointers at random addresses throughout the code

I can see why you don't want this. I find ASLR generated addresses quite
cumbersome to read as well.

  2) Explicitly map RAM at VA 0x1000, then do 1:1 map

This would be the best of all worlds still IMHO. That way we will have
easily readable addresses (that are identical in 32bit and 64bit), but
can still do a 1:1 map. The only thing we need to do is to introduce a
linker section at 0x1000.

  3) Keep converting addresses to pointers

I'm afraid if we follow this path, we will always have arguments on
where the correct boundaries are. If you start to enable debugging in
core dm code and print out pointers to your dm objects, you will get
pointer values today as well. Sooner or later we will always end up with
pointers.


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

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

[Tom Rini]

On Thu, Jun 14, 2018 at 10:58:22PM +0200, Marek Vasut wrote:
> On 06/14/2018 03:07 PM, Tom Rini wrote:
> > On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote:
> >> On 06/14/2018 01:19 PM, Tom Rini wrote:
> >>> On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote:
> >>>
>  The following changes since commit 
>  813d1fb56dc0af9567feb86cd71c49f14662044b:
> 
>    Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08
>  10:08:20 -0400)
> 
>  are available in the Git repository at:
> 
>    git://git.denx.de/u-boot-sh.git master
> 
>  for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9:
> 
>    ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43
>  +0200)
> 
> >>>
> >>> NAK.  First, there are a lot of should be fix style errors in
> >>> the new files in drivers/pinctrl/renesas/.  Second, you have build
> >>> failures:
> >>> https://travis-ci.org/trini/u-boot/jobs/391819805
> >>> https://travis-ci.org/trini/u-boot/jobs/391819826
> >>
> >> Great, thanks!
> >>
> >> If the travis didn't vomit constant false positives recently, I'd trust
> >> it. With what it does now, I cannot trust it anymore.
> > 
> > Can you elaborate?
> 
> Don't you see the constant random timeouts during builds for some
> targets? I cannot get a successful build on the first try almost never
> these days, I have to keep restarting until I see that different targets
> failed during each build with a timeout and then extrapolate that the
> build is actually fine from that. It's annoying.

I see maybe 2-5 of those per day when I'm busy, which is annoying, but
I've never had it fail a second time in a row.

> And then there is the other category of boards which indicate "red"
> failure marker due to ie. DT problems, which if you pull DTs from Linux
> is something you cannot really fix on the U-Boot side right away, but
> rather fix in Linux and then resync.

Yes, there are DT warnings that should be fixed.  But they aren't travis
errors, only actual fail to builds (like in the above, which indeed are
confusingly DT related, but not a travis problem at all, I see them
locally too) and new C warnings.

-- 
Tom


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

[U-Boot] [PATCH] ARC: HSDK: Add readme

[Alexey Brodkin]

Signed-off-by: Alexey Brodkin 
---
 board/synopsys/hsdk/README | 121 +
 1 file changed, 121 insertions(+)
 create mode 100644 board/synopsys/hsdk/README

diff --git a/board/synopsys/hsdk/README b/board/synopsys/hsdk/README
new file mode 100644
index ..e3793e48298f
--- /dev/null
+++ b/board/synopsys/hsdk/README
@@ -0,0 +1,121 @@
+
+Useful notes on bulding and using of U-Boot on ARC HS Development Kit (AKA 
HSDK)
+
+
+   BOARD OVERVIEW
+
+   The DesignWare ARC HS Development Kit is a ready-to-use platform for rapid
+   software development on the ARC HS3x family of processors.
+
+   For more information please visit:
+   https://www.synopsys.com/dw/ipdir.php?ds=arc-hs-development-kit
+
+   User guide is availalble here:
+   
https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/wiki/docs/ARC_HSDK_User_Guide.pdf
+
+   It has the following features useful for U-Boot:
+* On-board 2-channel FTDI TTL-to-USB converter
+  - The first channel is used for serial debug port (which makes it 
possible
+to use a serial connection on pretty much any host machine be it
+Windows, Linux or Mac).
+On Linux machine typucally FTDI serial port would be /dev/ttyUSB0.
+There's no HW flow-control and baud-rate is 115200.
+
+  - The second channel is used for built-in Digilent USB JTAG probe.
+That means no extra hardware is required to access ARC core from a
+debugger on development host. Both proprietary MetaWare debugger and
+open source OpenOCD + GDB client are supported.
+
+  - Also with help of this FTDI chip it is possible to reset entire
+board with help of a special `rff-ftdi-reset` utility, see:
+https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset
+
+* Micro SD-card slot
+  - U-Boot expects to see the very first partition on the card formatted as
+FAT file-system and uses it for keeping its environment in `uboot.env`
+file. Note uboot.env is not just a text file but it is auto-generated
+file created by U-Boot on invocation of `saveenv` command.
+It contains a checksum which makes this saved environment invalid in
+case of maual modification.
+
+  - There might be more useful files on that first FAT partition like
+Linux kernl image in form of uImage (with or without built-in
+initramfs), device tree blob (.dtb) etc.
+
+  - Except FAT partition there might be others following the first FAT one
+like Ext file-system with rootfs etc.
+
+* 1 Gb Ethernet socket
+  - U-Boot might get payload from TFTP server. This might be uImage, rootfs
+image and anything else.
+
+* 2 MiB of SPI-flash
+  - SPI-flahs is used as a storage for image of an application 
auto-executed
+by bootROM on power-on. Typically U-Boot gets programmed there but
+there might be other uses. But note bootROM expects to find a special
+header preceeding application image itself so before flashing anything
+make sure required image is prepended. In case of U-Boot this is done
+by invocation of `headerize-hsdk.py` with `make bsp-generate` command.
+
+
+   BUILDING U-BOOT
+
+   1. Configure U-Boot:
+  ->8--
+  make hsdk_defconfig
+  ->8--
+
+   2. To build Elf file (for example to be used with host debugger via JTAG
+  connection to the target board):
+  ->8--
+  make mdbtrick
+  ->8--
+
+  This will produce `u-boot` Elf file.
+
+   3. To build artifacts required for U-Boot update in n-board SPI-flash:
+  ->8--
+  make bsp-generate
+  ->8--
+
+  This will produce `u-boot.head` and `u-boot-update.scr` which should
+  be put on the first FAT partition of micro SD-card to be inserted in the
+  HSDK board.
+
+
+   EXECUTING U-BOOT
+
+   1. The HSDK board is supposed to auto-start U-Boot image stored in on-board
+  SPI-flash on power-on. For that make sure DIP-switches in the corner of
+  the board are in their default positions: BIM in 1:off, 2:on state
+  while both BMC and BCS should be in 1:on, 2:on state.
+
+   2. Though it is possible to load U-Boot as a simple Elf file via JTAG right
+  in DDR and start it from the debugger.
+
+  2.1. In case of proprietary MetaWare debugger run:
+  ->8--
+  mdb -digilent -run -cl u-boot
+  ->8--
+
+
+   UPDATION U-B

Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader

[Simon Glass]

Hi Alex,

On 14 June 2018 at 13:15, Alexander Graf  wrote:
>
>
> On 14.06.18 21:02, Simon Glass wrote:
>> Hi Alex,
>>
>> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>>> With efi_loader we do not control payload applications, so we can not
>>> teach them about the difference between virtual and physical addresses.
>>>
>>> Instead, let's just always map host virtual addresses in the efi memory
>>> map. That way we can be sure that all memory allocation functions always
>>> return consumable pointers.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v1 -> v2:
>>>
>>>   - only compile efi_add_known_memory if efi_loader is enabled
>>> ---
>>>  arch/sandbox/cpu/cpu.c | 20 
>>>  1 file changed, 20 insertions(+)
>>
>> NAK.
>>
>> You should not point sandbox pointers into the EFI tables. I know it
>> looks like a clever shortcut, but it is not correct. It will mess up
>> logging and debugging, since those pointers bear no easily accessible
>> relationship to U-Boot address.
>>
>> Please start from my v7 patch. I'm happy to help do this correctly.
>> But, again, I think it should come after we have basic sandbox EFI
>> support applied.
>
> I don't want to play ping pong with you here. NAK on your approach until
> I see it properly executing selftest.

I think you just did :-)

But if you are asking for me to pull together a patch that gets that
far, then OK. I can see that you are not convinced it would work, or
be easy to follow, and I have not proven that yet. I was just hoping
to take things in incremental steps since this has been outstanding
for so long.

>
> So either we drive this forward or we don't. Your choice.

I have long wanted EFI to fall into the sandbox testing framework, so
that e.g. 'make tests' will quickly run the EFI tests. I don't think
we are too far away. It doesn't have to happen immediately, but I
predict that when we get it working, we won't look back. It will be
much more convenient than running a separate app or testing on 'real
hardware' and you can set up quite complicated things with it.

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

[U-Boot] [RFC PATCH] spl: Add option SPL_PAYLOAD

[York Sun]

Some legacy boards use RAW image for SPL boot. Add Kconfig option
SPL_PAYLOAD to set alternative image.

Signed-off-by: York Sun 

---

 Makefile   |  4 ++--
 common/spl/Kconfig | 10 ++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 6a190e7..36459f1 100644
--- a/Makefile
+++ b/Makefile
@@ -1115,8 +1115,8 @@ u-boot.sha1:  u-boot.bin
 u-boot.dis:u-boot
$(OBJDUMP) -d $< > $@
 
-ifdef CONFIG_TPL
-SPL_PAYLOAD := tpl/u-boot-with-tpl.bin
+ifneq ($(CONFIG_SPL_PAYLOAD),)
+SPL_PAYLOAD := $(CONFIG_SPL_PAYLOAD:"%"=%)
 else
 SPL_PAYLOAD := u-boot.bin
 endif
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 1f14797..72b77d7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -552,6 +552,16 @@ config SYS_OS_BASE
 
 endif # SPL_OS_BOOT
 
+config SPL_PAYLOAD
+   string "SPL payload"
+   default "tpl/u-boot-with-tpl.bin" if TPL
+   default "u-boot.bin"
+   help
+ Payload for SPL boot. For backward compability, default to
+ u-boot.bin, i.e. RAW image without any header. In case of
+ TPL, tpl/u-boot-with-tpl.bin. For new boards, suggest to
+ use u-boot.img.
+
 config SPL_PCI_SUPPORT
bool "Support PCI drivers"
help
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader

[Simon Glass]

Hi Heinrich,

On 14 June 2018 at 13:21, Heinrich Schuchardt  wrote:
> On 06/14/2018 09:02 PM, Simon Glass wrote:
>> Hi Alex,
>>
>> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>>> With efi_loader we do not control payload applications, so we can not
>>> teach them about the difference between virtual and physical addresses.
>>>
>>> Instead, let's just always map host virtual addresses in the efi memory
>>> map. That way we can be sure that all memory allocation functions always
>>> return consumable pointers.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v1 -> v2:
>>>
>>>   - only compile efi_add_known_memory if efi_loader is enabled
>>> ---
>>>  arch/sandbox/cpu/cpu.c | 20 
>>>  1 file changed, 20 insertions(+)
>>
>> NAK.
>>
>> You should not point sandbox pointers into the EFI tables. I know it
>> looks like a clever shortcut, but it is not correct. It will mess up
>> logging and debugging, since those pointers bear no easily accessible
>> relationship to U-Boot address.
>
> Hello Simon,
>
> why do we need this Babylonic confusion of addresses which do not point
> to valid memory and pointers that are not valid addresses where
> everybody is getting lost?
>
> Simply use only addresses with there mmap'ed values and get rid of all
> conversions. Use your board file to adjust kernel_addr_r and the like to
> the address range that Linux offered you.

No one is getting lost. It has been working fine for a long time.
Sandbox was introduced almost 7 years ago. It has been a huge benefit
in terms of productivity and testing.

We are not necessarily running on Linux, but in any case, we get ugly
addresses which expose the underlying machine architecture, which is
not relevant for tests, and just introduces confusion. Sandbox is
intended to be pure U-Boot, just like you might boot up on a 32-bit
ARM or x86 machine.

The conversions existing in any case, since we must case between
addresses and pointers. This just makes it explicit in a convenient,
type-safe manner.

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

Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()

[Simon Glass]

Hi Alex,

On 14 June 2018 at 13:51, Alexander Graf  wrote:
>
>
> On 14.06.18 21:01, Simon Glass wrote:
>> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>>> The fs_read() function wants to get an address rather than the
>>> pointer to a buffer.
>>>
>>> So let's convert the passed buffer from pointer back a the address
>>> to make efi_loader on sandbox happier.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v1 -> v2:
>>>
>>>   - Clarify address vs pointer
>>>   - include mapmem.h
>>> ---
>>>  lib/efi_loader/efi_file.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> Reviewed-by: Simon Glass 
>>
>
> I actually think that this patch tackles the problem the wrong way
> around. I've cooked up another one that converts fs_read() and
> fs_write() to instead take a pointer - which really is what most users
> of the API want in the first place:
>
>
> https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f

Actually this is a pretty good exposition of why we don't want to use
pointers everywhere. U-Boot uses addresses all over the place. Even a
search for something as specific as "ulong addr" gets over 200
matches. If we go down this path we will end up changing a pretty
fundamental part of U-Boot, and I don't think it is a good idea to do
that. Addresses are easy to understand, can be added/subtracted
without pointer arithmetic, can be easily converted to pointers as
needed, can be 32-bits long on sandbox, etc.

So I think we should step back from the abyss here and stick with the
way sandbox currently deals with addresses. It works well, is pretty
easy to understand, allows debugging which is just as easy on sandbox
as other archs (since they both uses addresses until basically the
final access), the addresses are typically small values that start at
0 which much is easier to read than (e.g.) 7f1b58c8b008.

Here for example is the output from starting U-Boot with debugging in
board_f.c (something I have turned on a lot when refactoring and
debugging the init sequence):

U-Boot 2018.07-rc1-00142-g134ea86c7f-dirty (Jun 14 2018 - 15:04:04 -0600)

DRAM:  Monitor len: 00395AB0
Ram size: 0800
Ram top: 0800
Reserving 3670k for U-Boot at: 07c6a000
Reserving 32776k for malloc() at: 05c68000
Reserving 120 Bytes for Board Info at: 05c67f88
Reserving 472 Bytes for Global Data at: 05c67db0
Reserving 4352 Bytes for FDT at: 05c66cb0
Reserving 0x3c8 Bytes for bootstage at: 05c668e8

RAM Configuration:
Bank #0: 0 128 MiB

DRAM:  128 MiB
New Stack Pointer is: 05c668d0
Copying bootstage from 7fdb0056e038 to 7fdb061c48f0, size 3c8
Relocation Offset is: 07c6a000
Relocating to 07c6a000, new gd at 05c67db0, sp at 05c668d0


If we use pointers we get things like this:

Reserving 3670k for U-Boot at: 7f1b58c8b008

I just don't want to deal with 64-bit addresses when debugging things,
and there really is no point. The map_sysmem() function provides a
nice and easy way to cast an address to a pointer, and it works on all
architectures.

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

Re: [U-Boot] [PATCH v2] vboot: Do not use hashed-strings offset

[Simon Glass]

On 9 June 2018 at 09:45, Teddy Reed  wrote:
> The hashed-strings signature property includes two uint32_t values.
> The first is unneeded as there should never be a start offset into the
> strings region. The second, the size, is needed because the added
> signature node appends to this region.
>
> See tools/image-host.c, where a static 0 value is used for the offset.
>
> Signed-off-by: Teddy Reed 
> ---
>  common/image-sig.c | 7 +--
>  tools/image-host.c | 1 +
>  2 files changed, 6 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v3 5/9] clk: Add Actions Semi OWL clock support

[Simon Glass]

On 14 June 2018 at 12:08, Manivannan Sadhasivam
 wrote:
> This commit adds Actions Semi OWL family base clock and S900 SoC specific
> clock support. For S900 peripheral clock support, only UART clock has been
> added for now.
>
> Signed-off-by: Manivannan Sadhasivam 
> ---
>
> Changes in v3:
>
> * Moved the change log from cover letter
>
> Changes in v2:
>
> * Removed clk_owl.c and moved all clk code to clk_s900.c as per Simon's
>   review comments.
> * Moved arch/arm/mach-owl/Kconfig changes to board support patch.
>
>  arch/arm/include/asm/arch-owl/clk_s900.h  |  57 +
>  arch/arm/include/asm/arch-owl/regs_s900.h |  64 ++
>  drivers/clk/Kconfig   |   1 +
>  drivers/clk/Makefile  |   1 +
>  drivers/clk/owl/Kconfig   |  12 ++
>  drivers/clk/owl/Makefile  |   3 +
>  drivers/clk/owl/clk_s900.c| 138 ++
>  7 files changed, 276 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
>  create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
>  create mode 100644 drivers/clk/owl/Kconfig
>  create mode 100644 drivers/clk/owl/Makefile
>  create mode 100644 drivers/clk/owl/clk_s900.c

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

Re: [U-Boot] [PATCH v3 8/9] serial: Add Actions Semi OWL UART support

[Simon Glass]

On 14 June 2018 at 12:08, Manivannan Sadhasivam
 wrote:
> This commit adds Actions Semi OWL family UART support. This driver
> relies on baudrate configured by primary bootloaders.
>
> Signed-off-by: Manivannan Sadhasivam 
> ---
>
> Changes in v3:
>
> * Moved the change log from cover letter
>
> Changes in v2: None
>
>  drivers/serial/Kconfig  |   8 +++
>  drivers/serial/Makefile |   1 +
>  drivers/serial/serial_owl.c | 136 
>  3 files changed, 145 insertions(+)
>  create mode 100644 drivers/serial/serial_owl.c

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

Re: [U-Boot] [PATCH v3 3/9] dt-bindings: clock: Add S900 CMU register definitions

[Simon Glass]

On 14 June 2018 at 12:08, Manivannan Sadhasivam
 wrote:
> This commit adds Actions Semi S900 CMU register definitions to clock
> bindings.
>
> Signed-off-by: Manivannan Sadhasivam 
> ---
>
> Changes in v3:
>
> * Moved the change log from cover letter
>
> Changes in v2:
>
> * Added missing Signed-off-by tag
>
>  include/dt-bindings/clock/s900_cmu.h | 77 
>  1 file changed, 77 insertions(+)
>  create mode 100644 include/dt-bindings/clock/s900_cmu.h

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

[U-Boot] [PATCH] patman: Support using a particular SMTP server

[Simon Glass]

Some environments require providing the '--smtp-server' argument to
'git send-email'. Add support for this.

Signed-off-by: Simon Glass 
---

 tools/patman/README | 1 +
 tools/patman/gitutil.py | 6 +-
 tools/patman/patman.py  | 5 -
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/patman/README b/tools/patman/README
index 606780e2ed..7917fc8bdc 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -107,6 +107,7 @@ patman.py.  For reference, the useful ones (at the moment) 
shown below
 ignore_errors: True
 process_tags: False
 verbose: True
+smtp_server: /path/to/sendmail
 
 <<<
 
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 64ac0c8d3d..9905bb0bbd 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -332,7 +332,8 @@ def BuildEmailList(in_list, tag=None, alias=None, 
raise_on_error=True):
 return result
 
 def EmailPatches(series, cover_fname, args, dry_run, raise_on_error, cc_fname,
-self_only=False, alias=None, in_reply_to=None, thread=False):
+self_only=False, alias=None, in_reply_to=None, thread=False,
+smtp_server=None):
 """Email a patch series.
 
 Args:
@@ -348,6 +349,7 @@ def EmailPatches(series, cover_fname, args, dry_run, 
raise_on_error, cc_fname,
 Should be a message ID that this is in reply to.
 thread: True to add --thread to git send-email (make
 all patches reply to cover-letter or first patch in series)
+smtp_server: SMTP server to use to send patches
 
 Returns:
 Git command that was/would be run
@@ -405,6 +407,8 @@ def EmailPatches(series, cover_fname, args, dry_run, 
raise_on_error, cc_fname,
 to = BuildEmailList([os.getenv('USER')], '--to', alias, raise_on_error)
 cc = []
 cmd = ['git', 'send-email', '--annotate']
+if smtp_server:
+cmd.append('--smtp-server=%s' % smtp_server)
 if in_reply_to:
 if type(in_reply_to) != str:
 in_reply_to = in_reply_to.encode('utf-8')
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index 8d2c78235a..143d09e004 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -60,6 +60,8 @@ parser.add_option('--no-check', action='store_false', 
dest='check_patch',
   help="Don't check for patch compliance")
 parser.add_option('--no-tags', action='store_false', dest='process_tags',
   default=True, help="Don't process subject tags as aliaes")
+parser.add_option('--smtp-server', type='str',
+  help="Specify the SMTP server to 'get send-email'")
 parser.add_option('-T', '--thread', action='store_true', dest='thread',
   default=False, help='Create patches as a single thread')
 
@@ -165,7 +167,8 @@ else:
 if its_a_go:
 cmd = gitutil.EmailPatches(series, cover_fname, args,
 options.dry_run, not options.ignore_bad_tags, cc_file,
-in_reply_to=options.in_reply_to, thread=options.thread)
+in_reply_to=options.in_reply_to, thread=options.thread,
+smtp_server=options.smtp_server)
 else:
 print(col.Color(col.RED, "Not sending emails due to errors/warnings"))
 
-- 
2.18.0.rc1.244.gcf134e6275-goog

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

[U-Boot] [RFC PATCH 2/2] powerpc: mpc85xx: Drop u-boot-with-spl.bin on selected boards

[York Sun]

For SoCs with PBL, u-boot-with-spl-pbl.bin is the final image for
SPL boot. Drop unused u-boot-with-spl.bin.

Signed-off-by: York Sun 
CC: Ashish Kumar 
CC: Ruchika Gupta 
CC: Priyanka Jain 
CC: Shengzhou Liu 

---

 include/configs/B4860QDS.h | 1 -
 include/configs/T102xQDS.h | 1 -
 include/configs/T102xRDB.h | 1 -
 include/configs/T104xRDB.h | 1 -
 include/configs/T208xQDS.h | 1 -
 include/configs/T208xRDB.h | 1 -
 include/configs/T4240QDS.h | 1 -
 include/configs/T4240RDB.h | 1 -
 8 files changed, 8 deletions(-)

diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index 1c67153..eb7c964 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -17,7 +17,6 @@
 #define CONFIG_RESET_VECTOR_ADDRESS0xfffc
 #else
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index e457135..7b70ccf 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -30,7 +30,6 @@
 #ifdef CONFIG_RAMBOOT_PBL
 #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t102xqds/t1024_pbi.cfg
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h
index 07ba1cf..9130d3f 100644
--- a/include/configs/T102xRDB.h
+++ b/include/configs/T102xRDB.h
@@ -33,7 +33,6 @@
 #ifdef CONFIG_RAMBOOT_PBL
 #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t102xrdb/t1024_pbi.cfg
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index f34f518..5e77acf 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -21,7 +21,6 @@
 #endif
 
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index f5d454b..8539d06 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -37,7 +37,6 @@
 #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t208xqds/t208x_pbi.cfg
 
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h
index 934e6e4..eb746fe 100644
--- a/include/configs/T208xRDB.h
+++ b/include/configs/T208xRDB.h
@@ -31,7 +31,6 @@
 #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t208xrdb/t2080_pbi.cfg
 
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T4240QDS.h b/include/configs/T4240QDS.h
index 9714e44..804d41b 100644
--- a/include/configs/T4240QDS.h
+++ b/include/configs/T4240QDS.h
@@ -21,7 +21,6 @@
 #define CONFIG_RESET_VECTOR_ADDRESS 0xfffc
 #else
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h
index 43ae309..5df2d18 100644
--- a/include/configs/T4240RDB.h
+++ b/include/configs/T4240RDB.h
@@ -21,7 +21,6 @@
 #define CONFIG_RESET_VECTOR_ADDRESS 0xfffc
 #else
 #define CONFIG_SPL_FLUSH_IMAGE
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0xFFFD8000
 #define CONFIG_SPL_PAD_TO  0x4
 #define CONFIG_SPL_MAX_SIZE0x28000
-- 
2.7.4

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

[U-Boot] [RFC PATCH 1/2] armv8: layerscape: Drop u-boot-with-spl.bin for selected boards

[York Sun]

For SPL boot with PBL, u-boot-with-spl-pbl.bin is the final image.
Drop unused u-boot-with-spl.bin.

Signed-off-by: York Sun 
CC: Mingkai Hu 
CC: Ruchika Gupta 
CC: Prabhakar Kushwaha 
CC: Udit Agarwal 
CC: Sumit Garg 
CC: Priyanka Jain 
---

 include/configs/ls1043a_common.h | 2 --
 include/configs/ls1046a_common.h | 2 --
 include/configs/ls1088a_common.h | 1 -
 include/configs/ls2080a_common.h | 1 -
 4 files changed, 6 deletions(-)

diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 1faed4e..a5c 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -61,7 +61,6 @@
 
 /* SD boot SPL */
 #ifdef CONFIG_SD_BOOT
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 
 #define CONFIG_SPL_TEXT_BASE   0x1000
 #define CONFIG_SPL_MAX_SIZE0x17000
@@ -91,7 +90,6 @@
 /* NAND SPL */
 #ifdef CONFIG_NAND_BOOT
 #define CONFIG_SPL_PBL_PAD
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0x1000
 #define CONFIG_SPL_MAX_SIZE0x1a000
 #define CONFIG_SPL_STACK   0x1001d000
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index c687c9e..26eca18 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -59,7 +59,6 @@
 
 /* SD boot SPL */
 #ifdef CONFIG_SD_BOOT
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
 #define CONFIG_SPL_ENV_SUPPORT
@@ -96,7 +95,6 @@
 /* NAND SPL */
 #ifdef CONFIG_NAND_BOOT
 #define CONFIG_SPL_PBL_PAD
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
 #define CONFIG_SPL_ENV_SUPPORT
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index ea48421..588a2f9 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -226,7 +226,6 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv8/u-boot-spl.lds"
 #define CONFIG_SPL_MAX_SIZE0x16000
 #define CONFIG_SPL_STACK   (CONFIG_SYS_FSL_OCRAM_BASE + 0x9ff0)
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0x1800a000
 
 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index f1717ce..62df574 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -207,7 +207,6 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SPL_BSS_MAX_SIZE0x0010
 #define CONFIG_SPL_MAX_SIZE0x16000
 #define CONFIG_SPL_STACK   (CONFIG_SYS_FSL_OCRAM_BASE + 0x9ff0)
-#define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
 #define CONFIG_SPL_TEXT_BASE   0x1800a000
 
 #ifdef CONFIG_NAND_BOOT
-- 
2.7.4

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

[U-Boot] [PATCH] wip

[Simon Glass]

Signed-off-by: Simon Glass 
---

 tools/patman/gitutil.py  | 3 +++
 tools/patman/settings.py | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 64ac0c8d3d..c383af1cb3 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -405,6 +405,9 @@ def EmailPatches(series, cover_fname, args, dry_run, 
raise_on_error, cc_fname,
 to = BuildEmailList([os.getenv('USER')], '--to', alias, raise_on_error)
 cc = []
 cmd = ['git', 'send-email', '--annotate']
+smtp = settings.GetEmailSetting('smtp_server'):
+if smtp:
+cmd.append('--smtp-server=%s' % smtp)
 if in_reply_to:
 if type(in_reply_to) != str:
 in_reply_to = in_reply_to.encode('utf-8')
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 94ea5b5a1b..0af016d517 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -303,6 +303,9 @@ def GetItems(config, section):
 except:
 raise
 
+def GetEmailSetting(name):
+return email.get(name)
+
 def Setup(parser, project_name, config_fname=''):
 """Set up the settings module by reading config files.
 
@@ -331,11 +334,15 @@ def Setup(parser, project_name, config_fname=''):
 for name, value in GetItems(config, 'bounces'):
 bounces.add(value)
 
+for name, value in GetItems(config, 'email'):
+email[name] = value
+
 _UpdateDefaults(parser, config)
 
 # These are the aliases we understand, indexed by alias. Each member is a list.
 alias = {}
 bounces = set()
+email = {}
 
 if __name__ == "__main__":
 import doctest
-- 
2.18.0.rc1.244.gcf134e6275-goog

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

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

[Marek Vasut]

On 06/14/2018 03:07 PM, Tom Rini wrote:
> On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote:
>> On 06/14/2018 01:19 PM, Tom Rini wrote:
>>> On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote:
>>>
 The following changes since commit 
 813d1fb56dc0af9567feb86cd71c49f14662044b:

   Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08
 10:08:20 -0400)

 are available in the Git repository at:

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

 for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9:

   ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43
 +0200)

>>>
>>> NAK.  First, there are a lot of should be fix style errors in
>>> the new files in drivers/pinctrl/renesas/.  Second, you have build
>>> failures:
>>> https://travis-ci.org/trini/u-boot/jobs/391819805
>>> https://travis-ci.org/trini/u-boot/jobs/391819826
>>
>> Great, thanks!
>>
>> If the travis didn't vomit constant false positives recently, I'd trust
>> it. With what it does now, I cannot trust it anymore.
> 
> Can you elaborate?

Don't you see the constant random timeouts during builds for some
targets? I cannot get a successful build on the first try almost never
these days, I have to keep restarting until I see that different targets
failed during each build with a timeout and then extrapolate that the
build is actually fine from that. It's annoying.

And then there is the other category of boards which indicate "red"
failure marker due to ie. DT problems, which if you pull DTs from Linux
is something you cannot really fix on the U-Boot side right away, but
rather fix in Linux and then resync.

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

Re: [U-Boot] [PATCH v3 2/3] efi_loader: ARM: run EFI payloads non-secure

[Mark Kettenis]

> From: Marc Zyngier 
> Date: Thu, 14 Jun 2018 12:54:53 +0100
> 
> On 13/06/18 23:41, Mark Kettenis wrote:
> > If desired (and possible) switch into HYP mode or non-secure SVC mode
> > before calling the entry point of an EFI application.  This allows
> > U-Boot to provide a usable PSCI implementation and makes it possible
> > to boot kernels into hypervisor mode using an EFI bootloader.
> > 
> > Based on diffs from Heinrich Schuchardt and Alexander Graf.
> > 
> > Signed-off-by: Mark Kettenis 
> > ---
> >  cmd/bootefi.c | 32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 707d159bac..12a6b84ce6 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -20,6 +20,11 @@
> >  #include 
> >  #include 
> >  
> > +#ifdef CONFIG_ARMV7_NONSEC
> > +#include 
> > +#include 
> > +#endif
> > +
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> >  #define OBJ_LIST_NOT_INITIALIZED 1
> > @@ -189,6 +194,18 @@ static efi_status_t efi_run_in_el2(EFIAPI efi_status_t 
> > (*entry)(
> >  }
> >  #endif
> >  
> > +#ifdef CONFIG_ARMV7_NONSEC
> > +static efi_status_t efi_run_in_hyp(EFIAPI efi_status_t (*entry)(
> > +   efi_handle_t image_handle, struct efi_system_table *st),
> > +   efi_handle_t image_handle, struct efi_system_table *st)
> > +{
> > +   /* Enable caches again */
> > +   dcache_enable();
> > +
> > +   return efi_do_enter(image_handle, st, entry);
> > +}
> > +#endif
> > +
> >  /* Carve out DT reserved memory ranges */
> >  static efi_status_t efi_carve_out_dt_rsv(void *fdt)
> >  {
> > @@ -338,6 +355,21 @@ static efi_status_t do_bootefi_exec(void *efi,
> > }
> >  #endif
> >  
> > +#ifdef CONFIG_ARMV7_NONSEC
> > +   if (armv7_boot_nonsec()) {
> > +   dcache_disable();   /* flush cache before switch to HYP */
> > +
> 
> What is the rational for disabling/enabling caches across the transition
> to HYP? I'm sure there is a good reason, but I'd rather see it explained
> here.

Can't say I fully understan why.  But the AArch64 code does this as
well and if I don't flush the cache here the contents of efi_gd (which
gets initialized before the switch) sometimes gets lost.

> > +   armv7_init_nonsec();
> > +   secure_ram_addr(_do_nonsec_entry)(efi_run_in_hyp,
> > +   (uintptr_t)entry,
> > +   (uintptr_t)loaded_image_info_obj.handle,
> > +   (uintptr_t)&systab);
> > +
> > +   /* Should never reach here, efi exits with longjmp */
> > +   while (1) { }
> > +   }
> > +#endif
> > +
> > ret = efi_do_enter(loaded_image_info_obj.handle, &systab, entry);
> >  
> >  exit:
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Thu, 14 Jun 2018 19:55:51 +0200
> 
> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
> > This series makes it possible to run EFI applications in non-secure
> > mode.  It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and
> > Banana Pi boards using the PSCI implementation provided by U-Boot.
> > 
> > The second version avoids using r3 to pass the original stack pointer.
> > For some reason that register gets clobbered on the Banana Pi.  Instead
> > this version just migrates SP_svc to SP_hyp.
> > 
> > This third version avoids saving r3 on the stack and fixes an include
> > guard as suggested by Alexander Graf.
> > 
> > Mark Kettenis (3):
> >   ARM: HYP/non-sec: migrate stack
> >   efi_loader: ARM: run EFI payloads non-secure
> >   Revert "efi_loader: no support for ARMV7_NONSEC=y"
> > 
> >  arch/arm/cpu/armv7/nonsec_virt.S |  2 ++
> >  cmd/bootefi.c| 32 
> >  doc/README.uefi  |  2 --
> >  lib/efi_loader/Kconfig   |  2 --
> >  4 files changed, 34 insertions(+), 4 deletions(-)
> > 
> Hello Mark,
> 
> with this patch series running bootefi hello twice in sequence fails on
> the BananaPi.
> 
> => bootefi hello
> Scanning disk m...@01c0f000.blk...
> Found 3 disks
> WARNING: booting without device tree
> ## Starting EFI application at 4200 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> Hello, world!
> Running on UEFI 2.7
> Have SMBIOS table
> Load options: earlyprintk nosmp
> ## Application terminated, r = 0
> => bootefi hello
> WARNING: booting without device tree
> ## Starting EFI application at 4200 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> 

Yeah.  Trying to enter non-secure mode when we're already in
non-secure mode doesn't really work.  We should skip the switching
code in that case.  Now checking whether we are in non-secure mode
isn't really possible.  But I guess we can set a variable and check it
before we go down the switching codepath.  With that in I can exit the
OpenBSD bootloader and then reload and run it again.  I'll include
that fix in the next respin.

> Please, keep in mind that we expect multiple EFI binaries to be executed
> in sequence. E.g. the first binary installs a driver. The second is the
> application using it.
> 
> Running iPXE's snp.efi binary shows changed behavior on the console. New
> characters are displayed in "slow motion" (3 characters per second).
> Setting up the network interface fails in iPXE.

The same happens on my Banana Pi.  But not on the imx7 board.  
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] distro: add more efi dtb prefixes

[Guillaume GARDET]

As used on some distro, such as openSUSE.
Signed-off-by: Guillaume GARDET 

Cc: Tom Rini 
---
 include/config_distro_bootcmd.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8ebe6..ad4c7a78f1 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -141,7 +141,8 @@
"load ${devtype} ${devnum}:${distro_bootpart} "   \
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
\
-   "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+   "efi_dtb_prefixes=/ /dtb/ /dtb/current/ " \
+   "/boot/ /boot/dtb/ /boot/dtb/current/\0"  \
"scan_dev_for_efi="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
-- 
2.17.1

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

[U-Boot] [PATCH] snow: set fdtfile

[Guillaume GARDET]

Needed to boot with EFI distro boot.

Signed-off-by: Guillaume GARDET 

Cc: Akshay Saraswat 
Cc: Tom Rini 
---
 include/configs/snow.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/snow.h b/include/configs/snow.h
index 3b0db32ece..c546a5a6d0 100644
--- a/include/configs/snow.h
+++ b/include/configs/snow.h
@@ -8,6 +8,9 @@
 #ifndef __CONFIG_SNOW_H
 #define __CONFIG_SNOW_H
 
+#define EXYNOS_FDTFILE_SETTING \
+   "fdtfile=exynos5250-snow.dtb\0"
+
 #include 
 #include 
 #include 
-- 
2.17.1

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

Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()

[Alexander Graf]

On 14.06.18 21:01, Simon Glass wrote:
> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>> The fs_read() function wants to get an address rather than the
>> pointer to a buffer.
>>
>> So let's convert the passed buffer from pointer back a the address
>> to make efi_loader on sandbox happier.
>>
>> Signed-off-by: Alexander Graf 
>>
>> ---
>>
>> v1 -> v2:
>>
>>   - Clarify address vs pointer
>>   - include mapmem.h
>> ---
>>  lib/efi_loader/efi_file.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 

I actually think that this patch tackles the problem the wrong way
around. I've cooked up another one that converts fs_read() and
fs_write() to instead take a pointer - which really is what most users
of the API want in the first place:


https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f


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

Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem

[Alexander Graf]

On 14.06.18 21:26, Heinrich Schuchardt wrote:
> On 06/14/2018 09:13 PM, Alexander Graf wrote:
>>
>>
>> On 14.06.18 21:01, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 12:22, Alexander Graf  wrote:
 We try hard to make sure that SMBIOS tables live in the lower 32bit.
 However, when we can not find any space at all there, we should not
 error out but instead just fall back to map them in the full address
 space instead.

 Signed-off-by: Alexander Graf 
 ---
  lib/efi_loader/efi_smbios.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> Does that actually work? I thought the addresses in the table were
>>> always 32-bit?
>>
>>
>> There is only a single table reference which indeed is 32bit:
>> se->struct_table_address.
>>
>> That address however is unused in the EFI case usually, because the
>> SMBIOS information is already encapsulated in a table, so there's no
>> need to search through address space for a _DMI_ entry:
>>
>>   https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122
>>
>>
>> Alex
>>
> We still have an open issue with E820 memory reservations not observed
> by Linux because they are not mirrored in the memory map. Could the same
> happen with smbios?

The SMBIOS tables get allocated from the EFI pool in
lib/efi_loader/efi_smbios.c.

So the e820 patch fell through the cracks?


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

Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox

[Alexander Graf]

On 14.06.18 21:02, Simon Glass wrote:
> Hi Alex,
> 
> On 14 June 2018 at 12:05, Alexander Graf  wrote:
>>
>>
>>
>> On 14.06.18 19:15, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 11:08, Alexander Graf  wrote:

 On 06/14/2018 06:55 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 10:42, Alexander Graf  wrote:
>>
>> On 06/14/2018 06:33 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 10:26, Alexander Graf  wrote:

 On 06/14/2018 06:13 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 10:07, Alexander Graf  wrote:
>>
>> On 06/14/2018 05:53 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 09:47, Alexander Graf  wrote:


> Am 14.06.2018 um 17:43 schrieb Simon Glass :
>
> Hi Alex,
>
>> On 14 June 2018 at 08:22, Alexander Graf  wrote:
>>
>>
>>
>>> Am 14.06.2018 um 16:12 schrieb Simon Glass :
>>>
>>> Hi Alex,
>>>
> On 14 June 2018 at 07:41, Alexander Graf  
> wrote:
> On 06/14/2018 02:58 PM, Simon Glass wrote:
>
> Hi Alex,
>
>>> On 14 June 2018 at 04:12, Alexander Graf 
>>> wrote:
>>>
>>> On 06/13/2018 04:37 AM, Simon Glass wrote:
>>>
>>> With sandbox the U-Boot code is not mapped into the sandbox
>>> memory
>>> range
>>> so does not need to be excluded when allocating EFI memory.
>>> Update
>>> the
>>> EFI
>>> memory init code to take account of that.
>>>
>>> Also use mapmem instead of a cast to convert a memory 
>>> address
>>> to
>>> a
>>> pointer.
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>> Changes in v6: None
>>> Changes in v5: None
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2:
>>> - Update to use mapmem instead of a cast
>>>
>>>  lib/efi_loader/efi_memory.c | 31
>>> ++-
>>>  1 file changed, 18 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_memory.c
>>> b/lib/efi_loader/efi_memory.c
>>> index ec66af98ea..210e49ee8b 100644
>>> --- a/lib/efi_loader/efi_memory.c
>>> +++ b/lib/efi_loader/efi_memory.c
>>> @@ -9,6 +9,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
>>> pool_type,
>>> efi_uintn_t size, void **buffer)
>>>   &t);
>>>if (r == EFI_SUCCESS) {
>>> -   struct efi_pool_allocation *alloc = (void
>>> *)(uintptr_t)t;
>>> +   struct efi_pool_allocation *alloc =
>>> map_sysmem(t,
>>> size);
>>
>>
>> This is still the wrong spot. We don't want the conversion to
>> happen when
>> going from an EFI internal address to an allocation, but when
>> determining
>> which addresses are usable in the first place.
>
> There seem to be two ways to do this:
>
> 1. Record addresses (ulong) in the EFI tables and use
> map_sysmem()
> before returning an address in the allocator
> 2. Store pointers in the EFI tables using map_sysmem(), then 
> do
> no
> mapping in the allocator
>
> I've gone with option 1 since:
>
> - the EFI addresses are not pointers
> - it makes sandbox consistent with other architectures which 
> use
> an
> address rather than a pointer in EFI tables
> - we don't normally do pointer arithmetic on the results of
> map_sysmem()
> - we normall

Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem

[Heinrich Schuchardt]

On 06/14/2018 09:13 PM, Alexander Graf wrote:
> 
> 
> On 14.06.18 21:01, Simon Glass wrote:
>> Hi Alex,
>>
>> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>>> We try hard to make sure that SMBIOS tables live in the lower 32bit.
>>> However, when we can not find any space at all there, we should not
>>> error out but instead just fall back to map them in the full address
>>> space instead.
>>>
>>> Signed-off-by: Alexander Graf 
>>> ---
>>>  lib/efi_loader/efi_smbios.c | 11 +--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> Does that actually work? I thought the addresses in the table were
>> always 32-bit?
> 
> 
> There is only a single table reference which indeed is 32bit:
> se->struct_table_address.
> 
> That address however is unused in the EFI case usually, because the
> SMBIOS information is already encapsulated in a table, so there's no
> need to search through address space for a _DMI_ entry:
> 
>   https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122
> 
> 
> Alex
> 
We still have an open issue with E820 memory reservations not observed
by Linux because they are not mirrored in the memory map. Could the same
happen with smbios?

Regards

Heinrich

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

Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible

[Baruch Siach]

Hi Dennis,

On Thu, Jun 14, 2018 at 02:10:31PM -0500, Dennis Gilmore wrote:
> running sf probe on one of my clearfogs with this set of patches
> applied I got 
> 
> SF: unrecognized JEDEC id bytes: ff, ff, ff
> Failed to initialize SPI flash at 1:0 (error -2)

Do you use the clearfog_defconfig?

Does current U-Boot master work for you?

For the record, on my Clearfog Base 'sf probe' shows:

SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB

This works with or without these patches.

baruch

> Dennis
> 
> On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> > Add the "spi-flash" compatible string so that the generic sf_probe
> > driver can probe the SPI flash on the SolidRun SOM.
> > 
> > Signed-off-by: Baruch Siach 
> > ---
> >  arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > index a2627223ce3b..74f58de85c43 100644
> > --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > @@ -86,7 +86,7 @@
> > w25q32: spi-flash@0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   compatible = "w25q32", "jedec,spi-nor";
> > +   compatible = "w25q32", "jedec,spi-nor", "spi-flash";
> > reg = <0>; /* Chip select 0 */
> > spi-max-frequency = <300>;
> > status = "disabled";

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader

[Heinrich Schuchardt]

On 06/14/2018 09:02 PM, Simon Glass wrote:
> Hi Alex,
> 
> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>> With efi_loader we do not control payload applications, so we can not
>> teach them about the difference between virtual and physical addresses.
>>
>> Instead, let's just always map host virtual addresses in the efi memory
>> map. That way we can be sure that all memory allocation functions always
>> return consumable pointers.
>>
>> Signed-off-by: Alexander Graf 
>>
>> ---
>>
>> v1 -> v2:
>>
>>   - only compile efi_add_known_memory if efi_loader is enabled
>> ---
>>  arch/sandbox/cpu/cpu.c | 20 
>>  1 file changed, 20 insertions(+)
> 
> NAK.
> 
> You should not point sandbox pointers into the EFI tables. I know it
> looks like a clever shortcut, but it is not correct. It will mess up
> logging and debugging, since those pointers bear no easily accessible
> relationship to U-Boot address.

Hello Simon,

why do we need this Babylonic confusion of addresses which do not point
to valid memory and pointers that are not valid addresses where
everybody is getting lost?

Simply use only addresses with there mmap'ed values and get rid of all
conversions. Use your board file to adjust kernel_addr_r and the like to
the address range that Linux offered you.

Best regards

Heinrich

> 
> Please start from my v7 patch. I'm happy to help do this correctly.
> But, again, I think it should come after we have basic sandbox EFI
> support applied.
> 
> Regards,
> Simon
> 

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

Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader

[Alexander Graf]

On 14.06.18 21:02, Simon Glass wrote:
> Hi Alex,
> 
> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>> With efi_loader we do not control payload applications, so we can not
>> teach them about the difference between virtual and physical addresses.
>>
>> Instead, let's just always map host virtual addresses in the efi memory
>> map. That way we can be sure that all memory allocation functions always
>> return consumable pointers.
>>
>> Signed-off-by: Alexander Graf 
>>
>> ---
>>
>> v1 -> v2:
>>
>>   - only compile efi_add_known_memory if efi_loader is enabled
>> ---
>>  arch/sandbox/cpu/cpu.c | 20 
>>  1 file changed, 20 insertions(+)
> 
> NAK.
> 
> You should not point sandbox pointers into the EFI tables. I know it
> looks like a clever shortcut, but it is not correct. It will mess up
> logging and debugging, since those pointers bear no easily accessible
> relationship to U-Boot address.
> 
> Please start from my v7 patch. I'm happy to help do this correctly.
> But, again, I think it should come after we have basic sandbox EFI
> support applied.

I don't want to play ping pong with you here. NAK on your approach until
I see it properly executing selftest.

So either we drive this forward or we don't. Your choice.


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

Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem

[Alexander Graf]

On 14.06.18 21:01, Simon Glass wrote:
> Hi Alex,
> 
> On 14 June 2018 at 12:22, Alexander Graf  wrote:
>> We try hard to make sure that SMBIOS tables live in the lower 32bit.
>> However, when we can not find any space at all there, we should not
>> error out but instead just fall back to map them in the full address
>> space instead.
>>
>> Signed-off-by: Alexander Graf 
>> ---
>>  lib/efi_loader/efi_smbios.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> Does that actually work? I thought the addresses in the table were
> always 32-bit?


There is only a single table reference which indeed is 32bit:
se->struct_table_address.

That address however is unused in the EFI case usually, because the
SMBIOS information is already encapsulated in a table, so there's no
need to search through address space for a _DMI_ entry:

  https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122


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

Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible

[Dennis Gilmore]

running sf probe on one of my clearfogs with this set of patches
applied I got 

SF: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)


Dennis


On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> Add the "spi-flash" compatible string so that the generic sf_probe
> driver can probe the SPI flash on the SolidRun SOM.
> 
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> index a2627223ce3b..74f58de85c43 100644
> --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> @@ -86,7 +86,7 @@
>   w25q32: spi-flash@0 {
>   #address-cells = <1>;
>   #size-cells = <1>;
> - compatible = "w25q32", "jedec,spi-nor";
> + compatible = "w25q32", "jedec,spi-nor", "spi-flash";
>   reg = <0>; /* Chip select 0 */
>   spi-max-frequency = <300>;
>   status = "disabled";
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: mvebu: clearfog: use the microsom .dtsi

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> Use hardware description from the recently introduced microsom .dtsi
> file to reduce duplication.
> 
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-388-clearfog.dts | 63 +++---
> --
>  1 file changed, 6 insertions(+), 57 deletions(-)
> 
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index a0b566a5ae0e..1403600e5b02 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -50,6 +50,7 @@
>  #include 
>  #include 
>  #include "armada-388.dtsi"
> +#include "armada-38x-solidrun-microsom.dtsi"
>  
>  / {
>   model = "SolidRun Clearfog A1";
> @@ -70,11 +71,6 @@
>   stdout-path = "serial0:115200n8";
>   };
>  
> - memory {
> - device_type = "memory";
> - reg = <0x 0x1000>; /* 256 MB */
> - };
> -
>   reg_3p3v: regulator-3p3v {
>   compatible = "regulator-fixed";
>   regulator-name = "3P3V";
> @@ -84,11 +80,6 @@
>   };
>  
>   soc {
> - ranges =  -   MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> -   MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> -
>   internal-regs {
>   ethernet@3 {
>   mac-address = [00 50 43 02 02 02];
> @@ -108,15 +99,6 @@
>   status = "okay";
>   };
>  
> - ethernet@7 {
> - mac-address = [00 50 43 02 02 01];
> - pinctrl-0 = <&ge0_rgmii_pins>;
> - pinctrl-names = "default";
> - phy = <&phy_dedicated>;
> - phy-mode = "rgmii-id";
> - status = "okay";
> - };
> -
>   i2c@11000 {
>   /* Is there anything on this? */
>   clock-frequency = <10>;
> @@ -226,22 +208,6 @@
>   status = "okay";
>   };
>  
> - mdio@72004 {
> - pinctrl-0 = <&mdio_pins>;
> - pinctrl-names = "default";
> -
> - phy_dedicated: ethernet-phy@0 {
> - /*
> -  * Annoyingly, the marvell
> phy driver
> -  * configures the LED
> register, rather
> -  * than preserving reset-
> loaded setting.
> -  * We undo that rubbish
> here.
> -  */
> - marvell,reg-init = <3 16 0
> 0x101e>;
> - reg = <0>;
> - };
> - };
> -
>   pinctrl@18000 {
>   clearfog_dsa0_clk_pins: clearfog-
> dsa0-clk-pins {
>   marvell,pins = "mpp46";
> @@ -260,12 +226,6 @@
>   marvell,pins = "mpp20";
>   marvell,function = "gpio";
>   };
> - clearfog_sdhci_pins: clearfog-sdhci-
> pins {
> - marvell,pins = "mpp21",
> "mpp28",
> -"mpp37",
> "mpp38",
> -"mpp39",
> "mpp40";
> - marvell,function = "sd0";
> - };
>   clearfog_spi1_cs_pins: spi1-cs-pins
> {
>   marvell,pins = "mpp55";
>   marvell,function = "spi1";
> @@ -311,7 +271,7 @@
>   bus-width = <4>;
>   cd-gpios = <&gpio0 20
> GPIO_ACTIVE_LOW>;
>   no-1-8-v;
> - pinctrl-0 = <&clearfog_sdhci_pins
> + pinctrl-0 = <µsom_sdhci_pins
>&clearfog_sdhci_cd_pins
> >;
>   pinctrl-names = "default";
>   status = "okay";
> @@ -319,13 +279,6 @@
>   wp-inverted;
>   };
>  
> - serial@12000 {
> - pinctrl-0 = <&uart0_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> - u-boot,dm-pre-reloc;
> - 

Re: [U-Boot] [PATCH 3/4] arm: mvebu: Better align Clearfog dts file with Linux kernel

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> From: Jon Nettleton 
> 
> This makes changes so the u-boot dts file is structured more
> similar to the mainline linux dtsi file.  It provides a minimal
> common dts that can work for most boards based on the ClearFog
> platform.  Ethernet support is only supported for eth0 however
> all devices are left enabled so u-boot can generate and
> provide mac addresses for all of the network interfaces.
> 
> Signed-off-by: Jon Nettleton 
> [baruch: rebase on recent changes]
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-388-clearfog.dts | 386 +++
> 
>  1 file changed, 151 insertions(+), 235 deletions(-)
> 
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index 1403600e5b02..16a47d59e667 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -81,174 +81,6 @@
>  
>   soc {
>   internal-regs {
> - ethernet@3 {
> - mac-address = [00 50 43 02 02 02];
> - phy-mode = "sgmii";
> - status = "okay";
> -
> - fixed-link {
> - speed = <1000>;
> - full-duplex;
> - };
> - };
> -
> - ethernet@34000 {
> - mac-address = [00 50 43 02 02 03];
> - managed = "in-band-status";
> - phy-mode = "sgmii";
> - status = "okay";
> - };
> -
> - i2c@11000 {
> - /* Is there anything on this? */
> - clock-frequency = <10>;
> - pinctrl-0 = <&i2c0_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - /*
> -  * PCA9655 GPIO expander, up to 1MHz
> clock.
> -  *  0-CON3 CLKREQ#
> -  *  1-CON3 PERST#
> -  *  2-CON2 PERST#
> -  *  3-CON3 W_DISABLE
> -  *  4-CON2 CLKREQ#
> -  *  5-USB3 overcurrent
> -  *  6-USB3 power
> -  *  7-CON2 W_DISABLE
> -  *  8-JP4 P1
> -  *  9-JP4 P4
> -  * 10-JP4 P5
> -  * 11-m.2 DEVSLP
> -  * 12-SFP_LOS
> -  * 13-SFP_TX_FAULT
> -  * 14-SFP_TX_DISABLE
> -  * 15-SFP_MOD_DEF0
> -  */
> - expander0: gpio-expander@20 {
> - /*
> -  * This is how it should be:
> -  * compatible =
> "onnn,pca9655",
> -  *   "nxp,pca9555";
> -  * but you can't do this
> because of
> -  * the way I2C works.
> -  */
> - compatible = "nxp,pca9555";
> - gpio-controller;
> - #gpio-cells = <2>;
> - reg = <0x20>;
> -
> - pcie1_0_clkreq {
> - gpio-hog;
> - gpios = <0
> GPIO_ACTIVE_LOW>;
> - input;
> - line-name =
> "pcie1.0-clkreq";
> - };
> - pcie1_0_w_disable {
> - gpio-hog;
> - gpios = <3
> GPIO_ACTIVE_LOW>;
> - output-low;
> - line-name =
> "pcie1.0-w-disable";
> - };
> - pcie2_0_clkreq {
> - gpio-hog;
> - gpios = <4
> GPIO_ACTIVE_LOW>;
> - input;
> - line-name =
> "pcie2.0-clkreq";
> - };
> - pcie2_0_w_disable {
> -  

Re: [U-Boot] [PATCH 4/4] arm: mvebu: helios4: remove duplicate sdhci pins node

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> The same pinctrl node appears in the solidrun-microsom dtsi. Use that
> instead.
> 
> Cc: Dennis Gilmore 
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-388-helios4.dts | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/arch/arm/dts/armada-388-helios4.dts
> b/arch/arm/dts/armada-388-helios4.dts
> index 049d32296475..a154e0f4f477 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -248,7 +248,7 @@
>   bus-width = <4>;
>   cd-gpios = <&gpio0 20
> GPIO_ACTIVE_LOW>;
>   no-1-8-v;
> - pinctrl-0 = <&helios_sdhci_pins
> + pinctrl-0 = <µsom_sdhci_pins
>&helios_sdhci_cd_pins>;
>   pinctrl-names = "default";
>   status = "okay";
> @@ -286,12 +286,6 @@
>   marvell,pins = "mpp20";
>   marvell,function = "gpio";
>   };
> - helios_sdhci_pins: helios-sdhci-pins 
> {
> - marvell,pins = "mpp21",
> "mpp28",
> -"mpp37",
> "mpp38",
> -"mpp39",
> "mpp40";
> - marvell,function = "sd0";
> - };
>   helios_led_pins: helios-led-pins {
>   marvell,pins = "mpp24",
> "mpp25",
>  "mpp49",
> "mpp50",
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox

[Simon Glass]

Hi Alex,

On 14 June 2018 at 12:05, Alexander Graf  wrote:
>
>
>
> On 14.06.18 19:15, Simon Glass wrote:
> > Hi Alex,
> >
> > On 14 June 2018 at 11:08, Alexander Graf  wrote:
> >>
> >> On 06/14/2018 06:55 PM, Simon Glass wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> On 14 June 2018 at 10:42, Alexander Graf  wrote:
> 
>  On 06/14/2018 06:33 PM, Simon Glass wrote:
> >
> > Hi Alex,
> >
> > On 14 June 2018 at 10:26, Alexander Graf  wrote:
> >>
> >> On 06/14/2018 06:13 PM, Simon Glass wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> On 14 June 2018 at 10:07, Alexander Graf  wrote:
> 
>  On 06/14/2018 05:53 PM, Simon Glass wrote:
> >
> > Hi Alex,
> >
> > On 14 June 2018 at 09:47, Alexander Graf  wrote:
> >>
> >>
> >>> Am 14.06.2018 um 17:43 schrieb Simon Glass :
> >>>
> >>> Hi Alex,
> >>>
>  On 14 June 2018 at 08:22, Alexander Graf  wrote:
> 
> 
> 
> > Am 14.06.2018 um 16:12 schrieb Simon Glass :
> >
> > Hi Alex,
> >
> >>> On 14 June 2018 at 07:41, Alexander Graf  
> >>> wrote:
> >>> On 06/14/2018 02:58 PM, Simon Glass wrote:
> >>>
> >>> Hi Alex,
> >>>
> > On 14 June 2018 at 04:12, Alexander Graf 
> > wrote:
> >
> > On 06/13/2018 04:37 AM, Simon Glass wrote:
> >
> > With sandbox the U-Boot code is not mapped into the sandbox
> > memory
> > range
> > so does not need to be excluded when allocating EFI memory.
> > Update
> > the
> > EFI
> > memory init code to take account of that.
> >
> > Also use mapmem instead of a cast to convert a memory 
> > address
> > to
> > a
> > pointer.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2:
> > - Update to use mapmem instead of a cast
> >
> >  lib/efi_loader/efi_memory.c | 31
> > ++-
> >  1 file changed, 18 insertions(+), 13 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_memory.c
> > b/lib/efi_loader/efi_memory.c
> > index ec66af98ea..210e49ee8b 100644
> > --- a/lib/efi_loader/efi_memory.c
> > +++ b/lib/efi_loader/efi_memory.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
> > pool_type,
> > efi_uintn_t size, void **buffer)
> >   &t);
> >if (r == EFI_SUCCESS) {
> > -   struct efi_pool_allocation *alloc = (void
> > *)(uintptr_t)t;
> > +   struct efi_pool_allocation *alloc =
> > map_sysmem(t,
> > size);
> 
> 
>  This is still the wrong spot. We don't want the conversion to
>  happen when
>  going from an EFI internal address to an allocation, but when
>  determining
>  which addresses are usable in the first place.
> >>>
> >>> There seem to be two ways to do this:
> >>>
> >>> 1. Record addresses (ulong) in the EFI tables and use
> >>> map_sysmem()
> >>> before returning an address in the allocator
> >>> 2. Store pointers in the EFI tables using map_sysmem(), then 
> >>> do
> >>> no
> >>> mapping in the allocator
> >>>
> >>> I've gone with option 1 since:
> >>>
> >>> - the EFI addresses are not pointers
> >>> - it makes sandbox consistent with other architectures which 
> >>> use
> >>> an
> >>> address rather than a pointer in EFI tables
> >>> - we don't normally do pointer arithmetic on the results of
> >>> map_sysmem()
> >>> - we normally map the memory when it is used rather than when 

Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader

[Simon Glass]

Hi Alex,

On 14 June 2018 at 12:22, Alexander Graf  wrote:
> With efi_loader we do not control payload applications, so we can not
> teach them about the difference between virtual and physical addresses.
>
> Instead, let's just always map host virtual addresses in the efi memory
> map. That way we can be sure that all memory allocation functions always
> return consumable pointers.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> v1 -> v2:
>
>   - only compile efi_add_known_memory if efi_loader is enabled
> ---
>  arch/sandbox/cpu/cpu.c | 20 
>  1 file changed, 20 insertions(+)

NAK.

You should not point sandbox pointers into the EFI tables. I know it
looks like a clever shortcut, but it is not correct. It will mess up
logging and debugging, since those pointers bear no easily accessible
relationship to U-Boot address.

Please start from my v7 patch. I'm happy to help do this correctly.
But, again, I think it should come after we have basic sandbox EFI
support applied.

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

Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()

[Simon Glass]

On 14 June 2018 at 12:22, Alexander Graf  wrote:
> The fs_read() function wants to get an address rather than the
> pointer to a buffer.
>
> So let's convert the passed buffer from pointer back a the address
> to make efi_loader on sandbox happier.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> v1 -> v2:
>
>   - Clarify address vs pointer
>   - include mapmem.h
> ---
>  lib/efi_loader/efi_file.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem

[Simon Glass]

Hi Alex,

On 14 June 2018 at 12:22, Alexander Graf  wrote:
> We try hard to make sure that SMBIOS tables live in the lower 32bit.
> However, when we can not find any space at all there, we should not
> error out but instead just fall back to map them in the full address
> space instead.
>
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_loader/efi_smbios.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)

Does that actually work? I thought the addresses in the table were
always 32-bit?

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

Re: [U-Boot] [PATCH v2 03/11] efi_loader: Use compiler constants for image loader

[Simon Glass]

Hi Alex,

On 14 June 2018 at 12:22, Alexander Graf  wrote:
> The EFI image loader tries to determine which target architecture we're
> working with to only load PE binaries that match.
>
> So far this has worked based on CONFIG defines, because the target CPU
> was always indicated by a config define. With sandbox however, this is
> not longer true as all sandbox targets only encompass a single CONFIG
> option and so we need to use compiler defines to determine the CPU
> architecture.
>
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_loader/efi_image_loader.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>

NAK to this for now until we figure out a response to my concerns
previously expressed.

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

Re: [U-Boot] [PATCH v2 09/11] efi_loader: Disable miniapps on sandbox

[Simon Glass]

On 14 June 2018 at 12:22, Alexander Graf  wrote:
> In the sandbox environment we can not easily build efi stub binaries
> right now, so let's disable the respective test cases for the efi
> selftest suite.
>
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_selftest/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 04/11] efi_loader: Use map_sysmem() in bootefi command

[Simon Glass]

On 14 June 2018 at 12:22, Alexander Graf  wrote:
> The bootefi command gets a few addresses as values passed in. In sandbox,
> these values are in U-Boot address space, so we need to make sure we
> explicitly call map_sysmem() on them to be able to access them.
>
> Signed-off-by: Alexander Graf 
> ---
>  cmd/bootefi.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

Looks right to me. You might consider doing the map lower down in
efi_load_pe() but since you don't ever log the address, I suppose it
is OK.

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

[U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader

[Alexander Graf]

With efi_loader we do not control payload applications, so we can not
teach them about the difference between virtual and physical addresses.

Instead, let's just always map host virtual addresses in the efi memory
map. That way we can be sure that all memory allocation functions always
return consumable pointers.

Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - only compile efi_add_known_memory if efi_loader is enabled
---
 arch/sandbox/cpu/cpu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index cde0b055a6..23d8b70648 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,6 +5,7 @@
 #define DEBUG
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -177,3 +178,22 @@ void longjmp(jmp_buf jmp, int ret)
while (1)
;
 }
+
+#ifdef CONFIG_EFI_LOADER
+
+/*
+ * In sandbox, we don't have a 1:1 map, so we need to expose
+ * process addresses instead of U-Boot addresses
+ */
+void efi_add_known_memory(void)
+{
+   u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
+   u64 ram_size = gd->ram_size;
+   u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+   u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+
+   efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
+  false);
+}
+
+#endif
-- 
2.12.3

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

Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

[Joe Hershberger]

On Thu, Jun 14, 2018 at 1:12 PM, Dr. Philipp Tomsich
 wrote:
>
>> On 14 Jun 2018, at 19:39, Joe Hershberger  wrote:
>>
>> On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  
>> wrote:
>>> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
>>> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
>>> to enable the RX delay.
>>> The MASK was used in a wrong way.
>>>
>>> Signed-off-by: Janine Hagemann 
>>
>> Acked-by: Joe Hershberger 
>
> Reviewed-by: Philipp Tomsich 

I assume I should take this series? Or would you prefer to?

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

[U-Boot] [PATCH v2 03/11] efi_loader: Use compiler constants for image loader

[Alexander Graf]

The EFI image loader tries to determine which target architecture we're
working with to only load PE binaries that match.

So far this has worked based on CONFIG defines, because the target CPU
was always indicated by a config define. With sandbox however, this is
not longer true as all sandbox targets only encompass a single CONFIG
option and so we need to use compiler defines to determine the CPU
architecture.

Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_image_loader.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index ecdb77e5b6..fdf40a62c8 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -19,25 +19,25 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
 const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
 
 static int machines[] = {
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
IMAGE_FILE_MACHINE_ARM64,
-#elif defined(CONFIG_ARM)
+#elif defined(__arm__)
IMAGE_FILE_MACHINE_ARM,
IMAGE_FILE_MACHINE_THUMB,
IMAGE_FILE_MACHINE_ARMNT,
 #endif
 
-#if defined(CONFIG_X86_64)
+#if defined(__x86_64__)
IMAGE_FILE_MACHINE_AMD64,
-#elif defined(CONFIG_X86)
+#elif defined(__i386__)
IMAGE_FILE_MACHINE_I386,
 #endif
 
-#if defined(CONFIG_CPU_RISCV_32)
+#if defined(__riscv) && (__riscv_xlen == 32)
IMAGE_FILE_MACHINE_RISCV32,
 #endif
 
-#if defined(CONFIG_CPU_RISCV_64)
+#if defined(__riscv) && (__riscv_xlen == 64)
IMAGE_FILE_MACHINE_RISCV64,
 #endif
0 };
-- 
2.12.3

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

[U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()

[Alexander Graf]

The fs_read() function wants to get an address rather than the
pointer to a buffer.

So let's convert the passed buffer from pointer back a the address
to make efi_loader on sandbox happier.

Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - Clarify address vs pointer
  - include mapmem.h
---
 lib/efi_loader/efi_file.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index e6a15bcb52..2107730ba5 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* GUID for file system information */
@@ -232,8 +233,10 @@ static efi_status_t file_read(struct file_handle *fh, u64 
*buffer_size,
void *buffer)
 {
loff_t actread;
+   /* fs_read expects buffer address, not pointer */
+   uintptr_t buffer_addr = (uintptr_t)map_to_sysmem(buffer);
 
-   if (fs_read(fh->path, (ulong)buffer, fh->offset,
+   if (fs_read(fh->path, buffer_addr, fh->offset,
*buffer_size, &actread))
return EFI_DEVICE_ERROR;
 
-- 
2.12.3

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

[U-Boot] [PATCH v2 02/11] efi: sandbox: Add relocation constants

[Alexander Graf]

From: Simon Glass 

Add these so that we can build the EFI loader for sandbox. The values are
for x86_64 so potentially bogus. But we don't support relocation within
sandbox anyway.

Signed-off-by: Simon Glass 
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_runtime.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 4874eb602f..388dfb9840 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -62,6 +62,18 @@ struct dyn_sym {
 #define R_ABSOLUTE R_RISCV_64
 #define SYM_INDEX  32
 #endif
+
+/* For sandbox we only support 64-bit x86 at present */
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(s...@chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+#  warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+#define R_RELATIVE 8
+#define R_MASK 0xULL
 #else
 #error Need to add relocation awareness
 #endif
-- 
2.12.3

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

[U-Boot] [PATCH v2 00/11] sandbox: efi_loader support

[Alexander Graf]

This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but follows a different memory allocation scheme.

Instead of keeping U-Boot (physical) addresses in the EFI memory
map, this patch set makes the EFI memory map contain host virtual
(virtual) addresses. That way most logic "just works" and all EFI
interfaces automatically gain sandbox awareness.

With this patch set in place, I can run a good chunk of the selftest
suite as well as efi binaries compiled using gnu-efi.

Alex

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=49832

v1 -> v2:

  - only compile efi_add_known_memory if efi_loader is enabled
  - clarify address vs pointer in fs_read patch
  - include mapmem.h

Alexander Graf (7):
  efi_loader: Use compiler constants for image loader
  efi_loader: Use map_sysmem() in bootefi command
  efi.h: Do not use config options
  efi_loader: Allow SMBIOS tables in highmem
  sandbox: Map host memory for efi_loader
  efi_loader: Disable miniapps on sandbox
  efi_loader: Pass address to fs_read()

Heinrich Schuchardt (1):
  efi_loader: efi_allocate_pages is too restrictive

Simon Glass (3):
  efi: sandbox: Add distroboot support
  efi: sandbox: Add relocation constants
  efi: sandbox: Enable EFI loader for sandbox

 arch/sandbox/cpu/cpu.c| 20 
 cmd/bootefi.c | 13 -
 include/config_distro_bootcmd.h   | 13 +
 include/efi.h | 17 -
 lib/efi/Makefile  |  4 ++--
 lib/efi_loader/Kconfig|  2 +-
 lib/efi_loader/efi_file.c |  5 -
 lib/efi_loader/efi_image_loader.c | 12 ++--
 lib/efi_loader/efi_memory.c   |  2 +-
 lib/efi_loader/efi_runtime.c  | 12 
 lib/efi_loader/efi_smbios.c   | 11 +--
 lib/efi_selftest/Makefile |  2 +-
 12 files changed, 81 insertions(+), 32 deletions(-)

-- 
2.12.3

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

[U-Boot] [PATCH v2 01/11] efi: sandbox: Add distroboot support

[Alexander Graf]

From: Simon Glass 

With sandbox these values depend on the host system. Let's assume that it
is x86_64 for now.

Signed-off-by: Simon Glass 
Signed-off-by: Alexander Graf 
---
 include/config_distro_bootcmd.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8ebe6..1bd79ae3b8 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -251,6 +251,8 @@
 #elif defined(CONFIG_ARM)
 #define BOOTENV_EFI_PXE_ARCH "0xa"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000"
+
+/* For sandbox we only support 64-bit x86 at present */
 #elif defined(CONFIG_X86)
 /* Always assume we're running 64bit */
 #define BOOTENV_EFI_PXE_ARCH "0x7"
@@ -261,6 +263,17 @@
 #elif defined(CONFIG_CPU_RISCV_64)
 #define BOOTENV_EFI_PXE_ARCH "0x1b"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000"
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(s...@chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+#  warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+/* To support other *host* architectures this should be changed */
+#define BOOTENV_EFI_PXE_ARCH "0x7"
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000"
 #else
 #error Please specify an EFI client identifier
 #endif
-- 
2.12.3

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

[U-Boot] [PATCH v2 11/11] efi: sandbox: Enable EFI loader for sandbox

[Alexander Graf]

From: Simon Glass 

This allows this feature to build within sandbox. This is for testing
purposes only since it is not possible for sandbox to load native code.

Signed-off-by: Simon Glass 
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index df58e633d1..d471e6f4a4 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,6 @@
 config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
-   depends on (ARM || X86 || RISCV) && OF_LIBFDT
+   depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT
# We do not support bootefi booting ARMv7 in non-secure mode
depends on !ARMV7_NONSEC
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
-- 
2.12.3

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

[U-Boot] [PATCH v2 04/11] efi_loader: Use map_sysmem() in bootefi command

[Alexander Graf]

The bootefi command gets a few addresses as values passed in. In sandbox,
these values are in U-Boot address space, so we need to make sure we
explicitly call map_sysmem() on them to be able to access them.

Signed-off-by: Alexander Graf 
---
 cmd/bootefi.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f55a40dc84..a86a2bd4a9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -389,7 +390,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
unsigned long addr;
char *saddr;
efi_status_t r;
-   void *fdt_addr;
+   unsigned long fdt_addr;
+   void *fdt;
 
/* Allow unaligned memory access */
allow_unaligned();
@@ -406,11 +408,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return CMD_RET_USAGE;
 
if (argc > 2) {
-   fdt_addr = (void *)simple_strtoul(argv[2], NULL, 16);
+   fdt_addr = simple_strtoul(argv[2], NULL, 16);
if (!fdt_addr && *argv[2] != '0')
return CMD_RET_USAGE;
/* Install device tree */
-   r = efi_install_fdt(fdt_addr);
+   fdt = map_sysmem(fdt_addr, 0);
+   r = efi_install_fdt(fdt);
if (r != EFI_SUCCESS) {
printf("ERROR: failed to install device tree\n");
return CMD_RET_FAILURE;
@@ -429,7 +432,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
addr = simple_strtoul(saddr, NULL, 16);
else
addr = CONFIG_SYS_LOAD_ADDR;
-   memcpy((char *)addr, __efi_helloworld_begin, size);
+   memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
} else
 #endif
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
@@ -475,7 +478,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 
printf("## Starting EFI application at %08lx ...\n", addr);
-   r = do_bootefi_exec((void *)addr, bootefi_device_path,
+   r = do_bootefi_exec(map_sysmem(addr, 0), bootefi_device_path,
bootefi_image_path);
printf("## Application terminated, r = %lu\n",
   r & ~EFI_ERROR_MASK);
-- 
2.12.3

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

[U-Boot] [PATCH v2 08/11] efi_loader: efi_allocate_pages is too restrictive

[Alexander Graf]

From: Heinrich Schuchardt 

When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.

There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.

Signed-off-by: Heinrich Schuchardt 
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ec66af98ea..ce29bcc6a3 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -295,7 +295,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
-   addr = efi_find_free_memory(len, gd->start_addr_sp);
+   addr = efi_find_free_memory(len, -1ULL);
if (!addr) {
r = EFI_NOT_FOUND;
break;
-- 
2.12.3

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

[U-Boot] [PATCH v2 09/11] efi_loader: Disable miniapps on sandbox

[Alexander Graf]

In the sandbox environment we can not easily build efi stub binaries
right now, so let's disable the respective test cases for the efi
selftest suite.

Signed-off-by: Alexander Graf 
---
 lib/efi_selftest/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 4fe404d88d..bf5c8199cb 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -41,7 +41,7 @@ endif
 
 # TODO: As of v2018.01 the relocation code for the EFI application cannot
 # be built on x86_64.
-ifeq ($(CONFIG_X86_64),)
+ifeq ($(CONFIG_X86_64)$(CONFIG_SANDBOX),)
 
 ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST),)
 
-- 
2.12.3

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

[U-Boot] [PATCH v2 05/11] efi.h: Do not use config options

[Alexander Graf]

Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.

This patch changes the conditionals to use compiler provided defines
instead. That way we always adhere to the build environment we're in
and the definitions adjust automatically.

Signed-off-by: Alexander Graf 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Signed-off-by: Bin Meng 
---
 include/efi.h| 17 -
 lib/efi/Makefile |  4 ++--
 2 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/include/efi.h b/include/efi.h
index e30a3c51c6..826d484977 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -19,12 +19,12 @@
 #include 
 #include 
 
-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__))
-/* EFI uses the Microsoft ABI which is not the default for GCC */
+/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
+#ifdef __x86_64__
 #define EFIAPI __attribute__((ms_abi))
 #else
 #define EFIAPI asmlinkage
-#endif
+#endif /* __x86_64__ */
 
 struct efi_device_path;
 
@@ -32,16 +32,7 @@ typedef struct {
u8 b[16];
 } efi_guid_t;
 
-#define EFI_BITS_PER_LONG  BITS_PER_LONG
-
-/*
- * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
- * in lib/efi/Makefile, when building the stub.
- */
-#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
-#undef EFI_BITS_PER_LONG
-#define EFI_BITS_PER_LONG  64
-#endif
+#define EFI_BITS_PER_LONG  (sizeof(long) * 8)
 
 /* Bit mask for EFI status code with error */
 #define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))
diff --git a/lib/efi/Makefile b/lib/efi/Makefile
index 18d081ac46..ece7907227 100644
--- a/lib/efi/Makefile
+++ b/lib/efi/Makefile
@@ -7,9 +7,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
 
 CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi_stub.o := -fpic -fshort-wchar
 CFLAGS_REMOVE_efi.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi.o := -fpic -fshort-wchar
 
 extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
-- 
2.12.3

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

[U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem

[Alexander Graf]

We try hard to make sure that SMBIOS tables live in the lower 32bit.
However, when we can not find any space at all there, we should not
error out but instead just fall back to map them in the full address
space instead.

Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_smbios.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 7c3fc8af0b..932f7582ec 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -26,8 +26,15 @@ efi_status_t efi_smbios_register(void)
/* Reserve 4kiB page for SMBIOS */
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
 EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
-   if (ret != EFI_SUCCESS)
-   return ret;
+
+   if (ret != EFI_SUCCESS) {
+   /* Could not find space in lowmem, use highmem instead */
+   ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
+
+   if (ret != EFI_SUCCESS)
+   return ret;
+   }
 
/*
 * Generate SMBIOS tables - we know that efi_allocate_pages() returns
-- 
2.12.3

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

Re: [U-Boot] make Menuconfig Error

[Joe Hershberger]

Hi Duncan,

On Thu, Jun 14, 2018 at 1:03 PM,   wrote:
> Cloned most recent u-boot 2018.06.14
> make clean works
> make menuconfig fails:
>
> /bin/sh: 1: bison: not found
> scripts/kconfig/Makefile:229: recipe for target
> 'scripts/kconfig/dochecklxdialog' failed make[1]: ***
> [scripts/kconfig/dochecklxdialog] Error 1 Makefile:491: recipe for
> target 'menuconfig' failed make: *** [menuconfig] Error 2
>
> I've checked for bison, visually and with apt-cache search but I have
> found none.

This was introduced with commit
e91610da7c8a9fe42f3e5a75f06c3d1a0cb5f815 (kconfig: re-sync with Linux
4.17-rc4)

It seems that they made bison an external dependency instead of
keeping the pre-compiled scripts/kconfig/zconf.tab.c_shipped and
friends.

> Will try rebuild based on u-boot from 2018.05.14 on SPDX errors, That
> version did build.
> ___
> 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 v3 7/9] arm: dts: bubblegum_96: Enable UART5 for serial console

[Manivannan Sadhasivam]

This commit enables UART5 found in S900 SoC for serial console support.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2: None

 arch/arm/dts/bubblegum_96.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/dts/bubblegum_96.dts b/arch/arm/dts/bubblegum_96.dts
index 4e34ebaa49..5b58d15594 100644
--- a/arch/arm/dts/bubblegum_96.dts
+++ b/arch/arm/dts/bubblegum_96.dts
@@ -12,8 +12,20 @@
model = "Bubblegum-96";
compatible = "ucrobotics,bubblegum-96", "actions,s900";
 
+   aliases {
+   serial5 = &uart5;
+   };
+
+   chosen {
+   stdout-path = "serial5:115200n8";
+   };
+
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>;
};
 };
+
+&uart5 {
+   status = "okay";
+};
-- 
2.17.1

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

[U-Boot] [PATCH v3 5/9] clk: Add Actions Semi OWL clock support

[Manivannan Sadhasivam]

This commit adds Actions Semi OWL family base clock and S900 SoC specific
clock support. For S900 peripheral clock support, only UART clock has been
added for now.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2:

* Removed clk_owl.c and moved all clk code to clk_s900.c as per Simon's
  review comments.
* Moved arch/arm/mach-owl/Kconfig changes to board support patch.

 arch/arm/include/asm/arch-owl/clk_s900.h  |  57 +
 arch/arm/include/asm/arch-owl/regs_s900.h |  64 ++
 drivers/clk/Kconfig   |   1 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/owl/Kconfig   |  12 ++
 drivers/clk/owl/Makefile  |   3 +
 drivers/clk/owl/clk_s900.c| 138 ++
 7 files changed, 276 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
 create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
 create mode 100644 drivers/clk/owl/Kconfig
 create mode 100644 drivers/clk/owl/Makefile
 create mode 100644 drivers/clk/owl/clk_s900.c

diff --git a/arch/arm/include/asm/arch-owl/clk_s900.h 
b/arch/arm/include/asm/arch-owl/clk_s900.h
new file mode 100644
index 00..88e88f77f8
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/clk_s900.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Clock Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ *
+ */
+
+#ifndef _OWL_CLK_S900_H_
+#define _OWL_CLK_S900_H_
+
+#include 
+
+struct owl_clk_priv {
+   phys_addr_t base;
+};
+
+/* BUSCLK register definitions */
+#define CMU_PDBGDIV_8  7
+#define CMU_PDBGDIV_SHIFT  26
+#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
+#define CMU_PERDIV_8   7
+#define CMU_PERDIV_SHIFT   20
+#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
+#define CMU_NOCDIV_2   1
+#define CMU_NOCDIV_SHIFT   19
+#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
+#define CMU_DMMCLK_SRC_APLL2
+#define CMU_DMMCLK_SRC_SHIFT   10
+#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
+#define CMU_APBCLK_DIV BIT(8)
+#define CMU_NOCCLK_SRC BIT(7)
+#define CMU_AHBCLK_DIV BIT(4)
+#define CMU_CORECLK_MASK   3
+#define CMU_CORECLK_CPLL   BIT(1)
+#define CMU_CORECLK_HOSC   BIT(0)
+
+/* COREPLL register definitions */
+#define CMU_COREPLL_EN BIT(9)
+#define CMU_COREPLL_HOSC_ENBIT(8)
+#define CMU_COREPLL_OUT(1104 / 24)
+
+/* DEVPLL register definitions */
+#define CMU_DEVPLL_CLK BIT(12)
+#define CMU_DEVPLL_EN  BIT(8)
+#define CMU_DEVPLL_OUT (660 / 6)
+
+/* UARTCLK register definitions */
+#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
+
+/* DEVCLKEN1 register definitions */
+#define CMU_DEVCLKEN1_UART5BIT(21)
+
+#define PLL_STABILITY_WAIT_US  50
+
+#endif
diff --git a/arch/arm/include/asm/arch-owl/regs_s900.h 
b/arch/arm/include/asm/arch-owl/regs_s900.h
new file mode 100644
index 00..9e9106ddaa
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/regs_s900.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Register Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ *
+ */
+
+#ifndef _OWL_REGS_S900_H_
+#define _OWL_REGS_S900_H_
+
+/* CMU registers */
+#define CMU_COREPLL(0x)
+#define CMU_DEVPLL (0x0004)
+#define CMU_DDRPLL (0x0008)
+#define CMU_NANDPLL(0x000C)
+#define CMU_DISPLAYPLL (0x0010)
+#define CMU_AUDIOPLL   (0x0014)
+#define CMU_TVOUTPLL   (0x0018)
+#define CMU_BUSCLK (0x001C)
+#define CMU_SENSORCLK  (0x0020)
+#define CMU_LCDCLK (0x0024)
+#define CMU_DSICLK (0x0028)
+#define CMU_CSICLK (0x002C)
+#define CMU_DECLK  (0x0030)
+#define CMU_BISPCLK(0x0034)
+#define CMU_IMXCLK (0x0038)
+#define CMU_HDECLK (0x003C)
+#define CMU_VDECLK (0x0040)
+#define CMU_VCECLK (0x0044)
+#define CMU_NANDCCLK   (0x004C)
+#define CMU_SD0CLK (0x0050)
+#define CMU_SD1CLK (0x0054)
+#define CMU_SD2CLK (0x0058)
+#define CMU_UART0CLK   (0x005C)
+#define CMU_UART1CLK   (0x0060)
+#define CMU_UART2CLK   (0x0064)
+#define CMU_PWM0CLK 

Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

[Dr. Philipp Tomsich]

> On 14 Jun 2018, at 19:39, Joe Hershberger  wrote:
> 
> On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
>> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
>> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
>> to enable the RX delay.
>> The MASK was used in a wrong way.
>> 
>> Signed-off-by: Janine Hagemann 
> 
> Acked-by: Joe Hershberger 

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

[U-Boot] [PATCH v3 6/9] arm: dts: s900: Add UART node

[Manivannan Sadhasivam]

This commit adds UART node for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2: None

 arch/arm/dts/s900.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index e9d47b1ff1..2bbb30a5a8 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -32,6 +32,14 @@
#size-cells = <0x2>;
ranges;
 
+   uart5: serial@e012a000 {
+   u-boot,dm-pre-reloc;
+   compatible = "actions,s900-serial";
+   reg = <0x0 0xe012a000 0x0 0x1000>;
+   clocks = <&cmu CLOCK_UART5>;
+   status = "disabled";
+   };
+
cmu: clock-controller@e016 {
u-boot,dm-pre-reloc;
compatible = "actions,s900-cmu";
-- 
2.17.1

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

[U-Boot] [PATCH v3 9/9] MAINTAINERS: Add entries for Actions Semi OWL family

[Manivannan Sadhasivam]

Add myself as the Maintainer for Actions Semi OWL family and its
relevant board, drivers.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2: None

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 642c448093..0f70cb04fe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -145,6 +145,15 @@ T: git git://git.denx.de/u-boot-pxa.git
 F: arch/arm/cpu/pxa/
 F: arch/arm/include/asm/arch-pxa/
 
+ARM OWL
+M: Manivannan Sadhasivam 
+S: Maintained
+F: arch/arm/include/asm/arch-owl/
+F: arch/arm/mach-owl/
+F: board/ucRobotics/
+F: drivers/clk/owl/
+F: drivers/serial/serial_owl.c
+
 ARM RENESAS RMOBILE/R-CAR
 M: Nobuhiro Iwamatsu 
 M: Marek Vasut 
-- 
2.17.1

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

[U-Boot] [PATCH v3 8/9] serial: Add Actions Semi OWL UART support

[Manivannan Sadhasivam]

This commit adds Actions Semi OWL family UART support. This driver
relies on baudrate configured by primary bootloaders.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2: None

 drivers/serial/Kconfig  |   8 +++
 drivers/serial/Makefile |   1 +
 drivers/serial/serial_owl.c | 136 
 3 files changed, 145 insertions(+)
 create mode 100644 drivers/serial/serial_owl.c

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 2940bd05dc..766e5ced03 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -625,6 +625,14 @@ config MSM_SERIAL
  for example APQ8016 and MSM8916.
  Single baudrate is supported in current implementation (115200).
 
+config OWL_SERIAL
+   bool "Actions Semi OWL UART"
+   depends on DM_SERIAL && ARCH_OWL
+   help
+ If you have a Actions Semi OWL based board and want to use the on-chip
+ serial port, say Y to this option. If unsure, say N.
+ Single baudrate is supported in current implementation (115200).
+
 config PXA_SERIAL
bool "PXA serial port support"
help
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index e66899489e..9fa81d855d 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
 obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o
 obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
 obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
+obj-$(CONFIG_OWL_SERIAL) += serial_owl.o
 
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
new file mode 100644
index 00..6fd97e2502
--- /dev/null
+++ b/drivers/serial/serial_owl.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi OWL SoCs UART driver
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* UART Registers */
+#defineOWL_UART_CTL(0x)
+#defineOWL_UART_RXDAT  (0x0004)
+#defineOWL_UART_TXDAT  (0x0008)
+#defineOWL_UART_STAT   (0x000C)
+
+/* UART_CTL Register Definitions */
+#defineOWL_UART_CTL_PRS_NONE   GENMASK(6, 4)
+#defineOWL_UART_CTL_STPS   BIT(2)
+#defineOWL_UART_CTL_DWLS   3
+
+/* UART_STAT Register Definitions */
+#defineOWL_UART_STAT_TFES  BIT(10) /* TX FIFO Empty Status 
*/
+#defineOWL_UART_STAT_RFFS  BIT(9)  /* RX FIFO full Status 
*/
+#defineOWL_UART_STAT_TFFU  BIT(6)  /* TX FIFO full Status 
*/
+#defineOWL_UART_STAT_RFEM  BIT(5)  /* RX FIFO Empty Status 
*/
+
+struct owl_serial_priv {
+   phys_addr_t base;
+};
+
+int owl_serial_setbrg(struct udevice *dev, int baudrate)
+{
+   /* Driver supports only fixed baudrate */
+   return 0;
+}
+
+static int owl_serial_getc(struct udevice *dev)
+{
+   struct owl_serial_priv *priv = dev_get_priv(dev);
+
+   if (readl(priv->base + OWL_UART_STAT) & OWL_UART_STAT_RFEM)
+   return -EAGAIN;
+
+   return (int)(readl(priv->base + OWL_UART_RXDAT));
+}
+
+static int owl_serial_putc(struct udevice *dev,const char ch)
+{
+   struct owl_serial_priv *priv = dev_get_priv(dev);
+
+   if (readl(priv->base + OWL_UART_STAT) & OWL_UART_STAT_TFFU)
+   return -EAGAIN;
+
+   writel(ch, priv->base + OWL_UART_TXDAT);
+
+   return 0;
+}
+
+static int owl_serial_pending(struct udevice *dev, boolinput)
+{
+   struct owl_serial_priv *priv = dev_get_priv(dev);
+   unsigned int stat = readl(priv->base + OWL_UART_STAT);
+
+   if (input)
+   return !(stat & OWL_UART_STAT_RFEM);
+   else
+   return !(stat & OWL_UART_STAT_TFES);
+}
+
+static int owl_serial_probe(struct udevice *dev)
+{
+   struct owl_serial_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   u32 uart_ctl;
+   int ret;
+
+   /* Set data, parity and stop bits */
+   uart_ctl = readl(priv->base + OWL_UART_CTL);
+   uart_ctl &= ~(OWL_UART_CTL_PRS_NONE);
+   uart_ctl &= ~(OWL_UART_CTL_STPS);
+   uart_ctl |= OWL_UART_CTL_DWLS;
+   writel(uart_ctl, priv->base + OWL_UART_CTL);
+
+   /* Enable UART clock */
+   ret = clk_get_by_index(dev, 0, &clk);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable(&clk);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int owl_serial_ofdata_to_platdata(structudevice *dev)
+{
+   struct owl_serial_priv *priv = dev_get_priv(dev);
+
+   priv->base = dev_read_addr(dev);
+   if (priv->base == FDT_ADDR_T_NONE)
+

[U-Boot] [PATCH v3 2/9] board: Add uCRobotics Bubblegum-96 board support

[Manivannan Sadhasivam]

This commit adds uCRobotics Bubblegum-96 board support. This board is
one of the 96Boards Consumer Edition platform based on Actions Semi
S900 SoC.

Features:
- Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
- 2GiB RAM
- 8GiB eMMC, uSD slot
- WiFi, Bluetooth and GPS module
- 2x Host, 1x Device USB port
- HDMI
- 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons

U-Boot will be loaded by ATF at EL2 execution level. Relevant driver
support will be added in further commits.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2:

* Moved arch/arm/mach-owl/Kconfig changes from clk support patch

 arch/arm/Kconfig |  1 +
 arch/arm/dts/bubblegum_96.dts| 19 +++
 arch/arm/mach-owl/Kconfig| 21 
 board/ucRobotics/bubblegum_96/Kconfig| 15 ++
 board/ucRobotics/bubblegum_96/MAINTAINERS|  6 +++
 board/ucRobotics/bubblegum_96/Makefile   |  3 ++
 board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 
 configs/bubblegum_96_defconfig   | 22 
 include/configs/bubblegum_96.h   | 43 +++
 9 files changed, 186 insertions(+)
 create mode 100644 arch/arm/dts/bubblegum_96.dts
 create mode 100644 board/ucRobotics/bubblegum_96/Kconfig
 create mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
 create mode 100644 board/ucRobotics/bubblegum_96/Makefile
 create mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
 create mode 100644 configs/bubblegum_96_defconfig
 create mode 100644 include/configs/bubblegum_96.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec0bb5a42b..6e203f96aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1431,6 +1431,7 @@ source "board/spear/spear600/Kconfig"
 source "board/spear/x600/Kconfig"
 source "board/st/stv0991/Kconfig"
 source "board/tcl/sl50/Kconfig"
+source "board/ucRobotics/bubblegum_96/Kconfig"
 source "board/birdland/bav335x/Kconfig"
 source "board/timll/devkit3250/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
diff --git a/arch/arm/dts/bubblegum_96.dts b/arch/arm/dts/bubblegum_96.dts
new file mode 100644
index 00..4e34ebaa49
--- /dev/null
+++ b/arch/arm/dts/bubblegum_96.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Device Tree Source for Bubblegum-96
+//
+// Copyright (C) 2015 Actions Semi Co., Ltd.
+// Copyright (C) 2018 Manivannan Sadhasivam 
+
+/dts-v1/;
+#include "s900.dtsi"
+
+/ {
+   model = "Bubblegum-96";
+   compatible = "ucrobotics,bubblegum-96", "actions,s900";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+};
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
index f695c16d1e..199e772988 100644
--- a/arch/arm/mach-owl/Kconfig
+++ b/arch/arm/mach-owl/Kconfig
@@ -3,4 +3,25 @@ if ARCH_OWL
 config SYS_SOC
default "owl"
 
+choice
+prompt "Actions Semi OWL SoCs board select"
+optional
+
+config TARGET_BUBBLEGUM_96
+   bool "96Boards Bubblegum-96"
+   help
+ Support for 96Boards Bubblegum-96. This board complies with
+ 96Board Consumer Edition Specification. Features:
+ - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
+ - 2GiB RAM
+ - 8GiB eMMC, uSD slot
+ - WiFi, Bluetooth and GPS module
+ - 2x Host, 1x Device USB port
+ - HDMI
+ - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
+
+endchoice
+
+source "board/ucRobotics/bubblegum_96/Kconfig"
+
 endif
diff --git a/board/ucRobotics/bubblegum_96/Kconfig 
b/board/ucRobotics/bubblegum_96/Kconfig
new file mode 100644
index 00..2dd40d9b6a
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_BUBBLEGUM_96
+
+config SYS_BOARD
+   default "bubblegum_96"
+
+config SYS_VENDOR
+   default "ucRobotics"
+
+config SYS_SOC
+   default "s900"
+
+config SYS_CONFIG_NAME
+   default "bubblegum_96"
+
+endif
diff --git a/board/ucRobotics/bubblegum_96/MAINTAINERS 
b/board/ucRobotics/bubblegum_96/MAINTAINERS
new file mode 100644
index 00..d0cb7278c6
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/MAINTAINERS
@@ -0,0 +1,6 @@
+BUBBLEGUM_96 BOARD
+M: Manivannan Sadhasivam 
+S: Maintained
+F: board/ucRobotics/bubblegum_96/
+F: include/configs/bubblegum_96.h
+F: configs/bubblegum_96_defconfig
diff --git a/board/ucRobotics/bubblegum_96/Makefile 
b/board/ucRobotics/bubblegum_96/Makefile
new file mode 100644
index 00..c4b524def2
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y   := bubblegum_96.o
diff --git a/board/ucRobotics/bubblegum_96/bubblegum_96.c 
b/board/ucRobotics/bubblegum_96/bubblegum_96.c
new file mode 100644
index 00..a4c202da19
--- /dev/null
+++ b/board/ucRobo

[U-Boot] [PATCH v3 3/9] dt-bindings: clock: Add S900 CMU register definitions

[Manivannan Sadhasivam]

This commit adds Actions Semi S900 CMU register definitions to clock
bindings.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2:

* Added missing Signed-off-by tag

 include/dt-bindings/clock/s900_cmu.h | 77 
 1 file changed, 77 insertions(+)
 create mode 100644 include/dt-bindings/clock/s900_cmu.h

diff --git a/include/dt-bindings/clock/s900_cmu.h 
b/include/dt-bindings/clock/s900_cmu.h
new file mode 100644
index 00..2685a6df4a
--- /dev/null
+++ b/include/dt-bindings/clock/s900_cmu.h
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ *
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_S900_CMU_H_
+#define _DT_BINDINGS_CLOCK_S900_CMU_H_
+
+/* Module Clock ID */
+#define CLOCK_DDRCH1   0
+#define CLOCK_DMAC 1
+#define CLOCK_DDRCH0   2
+#define CLOCK_BROM 3
+#define CLOCK_NANDC0   4
+#define CLOCK_SD0  5
+#define CLOCK_SD1  6
+#define CLOCK_SD2  7
+#define CLOCK_DE   8
+#define CLOCK_LVDS 9
+#define CLOCK_EDP  10
+#define CLOCK_NANDC1   11
+#define CLOCK_DSI  12
+#define CLOCK_CSI0 13
+#define CLOCK_BISP 14
+#define CLOCK_CSI1 15
+#define CLOCK_SD3  16
+#define CLOCK_I2C4 17
+#define CLOCK_GPIO 18
+#define CLOCK_DMM  19
+#define CLOCK_I2STX20
+#define CLOCK_I2SRX21
+#define CLOCK_HDMIA22
+#define CLOCK_SPDIF23
+#define CLOCK_PCM0 24
+#define CLOCK_VDE  25
+#define CLOCK_VCE  26
+#define CLOCK_HDE  27
+#define CLOCK_SHARESRAM28
+#define CLOCK_CMU_DDR1 29
+#define CLOCK_GPU3D30
+#define CLOCK_CMUDDR0  31
+#define CLOCK_SPEED32
+#define CLOCK_I2C5 33
+#define CLOCK_THERMAL  34
+#define CLOCK_HDMI 35
+#define CLOCK_PWM4 36
+#define CLOCK_PWM5 37
+#define CLOCK_UART038
+#define CLOCK_UART139
+#define CLOCK_UART240
+#define CLOCK_IRC  41
+#define CLOCK_SPI0 42
+#define CLOCK_SPI1 43
+#define CLOCK_SPI2 44
+#define CLOCK_SPI3 45
+#define CLOCK_I2C0 46
+#define CLOCK_I2C1 47
+#define CLOCK_PCM1 48
+#define CLOCK_IMX  49
+#define CLOCK_UART650
+#define CLOCK_UART351
+#define CLOCK_UART452
+#define CLOCK_UART553
+#define CLOCK_ETHERNET 54
+#define CLOCK_PWM0 55
+#define CLOCK_PWM1 56
+#define CLOCK_PWM2 57
+#define CLOCK_PWM3 58
+#define CLOCK_TIMER59
+#define CLOCK_SE   60
+#define CLOCK_HDCP2TX  61
+#define CLOCK_I2C2 62
+#define CLOCK_I2C3 63
+
+#endif
-- 
2.17.1

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

[U-Boot] [PATCH v3 4/9] arm: dts: s900: Add Clock Management Unit (CMU) nodes

[Manivannan Sadhasivam]

This commit adds Clock Management Unit (CMU) nodes for Actions Semi
S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2: None

 arch/arm/dts/s900.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index 3bd14b82d4..e9d47b1ff1 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -6,18 +6,40 @@
 // Copyright (C) 2018 Manivannan Sadhasivam 
 
 /dts-v1/;
+#include 
 
 / {
compatible = "actions,s900";
#address-cells = <0x2>;
#size-cells = <0x2>;
 
+   losc: losc {
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   #clock-cells = <0>;
+   };
+
+   diff24M: diff24M {
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   #clock-cells = <0>;
+   };
+
soc {
u-boot,dm-pre-reloc;
compatible = "simple-bus";
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
+
+   cmu: clock-controller@e016 {
+   u-boot,dm-pre-reloc;
+   compatible = "actions,s900-cmu";
+   reg = <0x0 0xe016 0x0 0x1000>;
+   clocks = <&losc>, <&diff24M>;
+   clock-names = "losc", "diff24M";
+   #clock-cells = <1>;
+   };
};
 };
 
-- 
2.17.1

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

[U-Boot] [PATCH v3 1/9] arm: Add support for Actions Semi OWL SoC family

[Manivannan Sadhasivam]

This commit adds Actions Semi OWL SoC family support with S900 as the
first target SoC.

Signed-off-by: Manivannan Sadhasivam 
---

Changes in v3:

* Moved the change log from cover letter

Changes in v2: None

 arch/arm/Kconfig|  9 +
 arch/arm/Makefile   |  1 +
 arch/arm/dts/s900.dtsi  | 23 +++
 arch/arm/mach-owl/Kconfig   |  6 ++
 arch/arm/mach-owl/Makefile  |  3 +++
 arch/arm/mach-owl/sysmap-s900.c | 32 
 6 files changed, 74 insertions(+)
 create mode 100644 arch/arm/dts/s900.dtsi
 create mode 100644 arch/arm/mach-owl/Kconfig
 create mode 100644 arch/arm/mach-owl/Makefile
 create mode 100644 arch/arm/mach-owl/sysmap-s900.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d..ec0bb5a42b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,6 +699,13 @@ config ARCH_MX5
select BOARD_EARLY_INIT_F
imply MXC_GPIO
 
+config ARCH_OWL
+   bool "Actions Semi OWL SoCs"
+   select ARM64
+   select DM
+   select DM_SERIAL
+   select OF_CONTROL
+
 config ARCH_QEMU
bool "QEMU Virtual Platform"
select DM
@@ -1335,6 +1342,8 @@ source "arch/arm/cpu/armv8/fsl-layerscape/Kconfig"
 
 source "arch/arm/mach-orion5x/Kconfig"
 
+source "arch/arm/mach-owl/Kconfig"
+
 source "arch/arm/mach-rmobile/Kconfig"
 
 source "arch/arm/mach-meson/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 680c6e8516..f15b2287df 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -66,6 +66,7 @@ machine-$(CONFIG_ARCH_MVEBU)  += mvebu
 # TODO: rename CONFIG_ORION5X -> CONFIG_ARCH_ORION5X
 machine-$(CONFIG_ORION5X)  += orion5x
 machine-$(CONFIG_ARCH_OMAP2PLUS)   += omap2
+machine-$(CONFIG_ARCH_OWL) += owl
 machine-$(CONFIG_ARCH_S5PC1XX) += s5pc1xx
 machine-$(CONFIG_ARCH_SUNXI)   += sunxi
 machine-$(CONFIG_ARCH_SNAPDRAGON)  += snapdragon
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
new file mode 100644
index 00..3bd14b82d4
--- /dev/null
+++ b/arch/arm/dts/s900.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Device Tree Source for Actions Semi S900 SoC
+//
+// Copyright (C) 2015 Actions Semi Co., Ltd.
+// Copyright (C) 2018 Manivannan Sadhasivam 
+
+/dts-v1/;
+
+/ {
+   compatible = "actions,s900";
+   #address-cells = <0x2>;
+   #size-cells = <0x2>;
+
+   soc {
+   u-boot,dm-pre-reloc;
+   compatible = "simple-bus";
+   #address-cells = <0x2>;
+   #size-cells = <0x2>;
+   ranges;
+   };
+};
+
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
new file mode 100644
index 00..f695c16d1e
--- /dev/null
+++ b/arch/arm/mach-owl/Kconfig
@@ -0,0 +1,6 @@
+if ARCH_OWL
+
+config SYS_SOC
+   default "owl"
+
+endif
diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
new file mode 100644
index 00..1b43dc2921
--- /dev/null
+++ b/arch/arm/mach-owl/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += sysmap-s900.o
diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
new file mode 100644
index 00..f78b639740
--- /dev/null
+++ b/arch/arm/mach-owl/sysmap-s900.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi S900 Memory map
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ */
+
+#include 
+#include 
+
+static struct mm_region s900_mem_map[] = {
+   {
+   .virt = 0x0UL, /* DDR */
+   .phys = 0x0UL, /* DDR */
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0xE000UL, /* Peripheral block */
+   .phys = 0xE000UL, /* Peripheral block */
+   .size = 0x0800UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = s900_mem_map;
-- 
2.17.1

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

[U-Boot] [PATCH v3 0/9] Add SoC and Board support for Bubblegum-96

[Manivannan Sadhasivam]

This patchset adds SoC support for Actions Semi S900 SoC and ucRobotics
Bubblegum-96 board along with UART and Clock drivers.

S900 SoC consists of 4 ARM Cortex-A53 cores up to 1.8GHz with
Imagination Power VR G6230 GPU. More information on this SoC can be
found in Actions Semi product page:
http://www.actions-semi.com/en/productview.aspx?id=204

Bubblegum-96 board is one of the 96Boards Consumer Edition platform
based on S900 SoC. This board has 2GB LPDDR3 operating at 533 MHz and
8GB eMMC along with other peripherals required by 96Boards Consumer
Edition Specification. More information on this board can be found in
96Boards product page.
https://www.96boards.org/product/bubblegum-96/

Most of the code is based on Actions tree found here:
https://github.com/96boards-bubblegum/u-boot/

With this patchset, Bubblegum-96 board can boot into U-Boot shell.

Thanks,
Mani

Manivannan Sadhasivam (9):
  arm: Add support for Actions Semi OWL SoC family
  board: Add uCRobotics Bubblegum-96 board support
  dt-bindings: clock: Add S900 CMU register definitions
  arm: dts: s900: Add Clock Management Unit (CMU) nodes
  clk: Add Actions Semi OWL clock support
  arm: dts: s900: Add UART node
  arm: dts: bubblegum_96: Enable UART5 for serial console
  serial: Add Actions Semi OWL UART support
  MAINTAINERS: Add entries for Actions Semi OWL family

 MAINTAINERS  |   9 ++
 arch/arm/Kconfig |  10 ++
 arch/arm/Makefile|   1 +
 arch/arm/dts/bubblegum_96.dts|  31 +
 arch/arm/dts/s900.dtsi   |  53 +++
 arch/arm/include/asm/arch-owl/clk_s900.h |  57 
 arch/arm/include/asm/arch-owl/regs_s900.h|  64 +
 arch/arm/mach-owl/Kconfig|  27 
 arch/arm/mach-owl/Makefile   |   3 +
 arch/arm/mach-owl/sysmap-s900.c  |  32 +
 board/ucRobotics/bubblegum_96/Kconfig|  15 ++
 board/ucRobotics/bubblegum_96/MAINTAINERS|   6 +
 board/ucRobotics/bubblegum_96/Makefile   |   3 +
 board/ucRobotics/bubblegum_96/bubblegum_96.c |  56 
 configs/bubblegum_96_defconfig   |  22 +++
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   1 +
 drivers/clk/owl/Kconfig  |  12 ++
 drivers/clk/owl/Makefile |   3 +
 drivers/clk/owl/clk_s900.c   | 138 +++
 drivers/serial/Kconfig   |   8 ++
 drivers/serial/Makefile  |   1 +
 drivers/serial/serial_owl.c  | 136 ++
 include/configs/bubblegum_96.h   |  43 ++
 include/dt-bindings/clock/s900_cmu.h |  77 +++
 25 files changed, 809 insertions(+)
 create mode 100644 arch/arm/dts/bubblegum_96.dts
 create mode 100644 arch/arm/dts/s900.dtsi
 create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
 create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
 create mode 100644 arch/arm/mach-owl/Kconfig
 create mode 100644 arch/arm/mach-owl/Makefile
 create mode 100644 arch/arm/mach-owl/sysmap-s900.c
 create mode 100644 board/ucRobotics/bubblegum_96/Kconfig
 create mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
 create mode 100644 board/ucRobotics/bubblegum_96/Makefile
 create mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
 create mode 100644 configs/bubblegum_96_defconfig
 create mode 100644 drivers/clk/owl/Kconfig
 create mode 100644 drivers/clk/owl/Makefile
 create mode 100644 drivers/clk/owl/clk_s900.c
 create mode 100644 drivers/serial/serial_owl.c
 create mode 100644 include/configs/bubblegum_96.h
 create mode 100644 include/dt-bindings/clock/s900_cmu.h

-- 
2.17.1

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

Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox

[Alexander Graf]

On 14.06.18 19:15, Simon Glass wrote:
> Hi Alex,
> 
> On 14 June 2018 at 11:08, Alexander Graf  wrote:
>>
>> On 06/14/2018 06:55 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 10:42, Alexander Graf  wrote:

 On 06/14/2018 06:33 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 10:26, Alexander Graf  wrote:
>>
>> On 06/14/2018 06:13 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 10:07, Alexander Graf  wrote:

 On 06/14/2018 05:53 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 09:47, Alexander Graf  wrote:
>>
>>
>>> Am 14.06.2018 um 17:43 schrieb Simon Glass :
>>>
>>> Hi Alex,
>>>
 On 14 June 2018 at 08:22, Alexander Graf  wrote:



> Am 14.06.2018 um 16:12 schrieb Simon Glass :
>
> Hi Alex,
>
>>> On 14 June 2018 at 07:41, Alexander Graf  wrote:
>>> On 06/14/2018 02:58 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
> On 14 June 2018 at 04:12, Alexander Graf 
> wrote:
>
> On 06/13/2018 04:37 AM, Simon Glass wrote:
>
> With sandbox the U-Boot code is not mapped into the sandbox
> memory
> range
> so does not need to be excluded when allocating EFI memory.
> Update
> the
> EFI
> memory init code to take account of that.
>
> Also use mapmem instead of a cast to convert a memory address
> to
> a
> pointer.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Update to use mapmem instead of a cast
>
>  lib/efi_loader/efi_memory.c | 31
> ++-
>  1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/lib/efi_loader/efi_memory.c
> b/lib/efi_loader/efi_memory.c
> index ec66af98ea..210e49ee8b 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
> pool_type,
> efi_uintn_t size, void **buffer)
>   &t);
>if (r == EFI_SUCCESS) {
> -   struct efi_pool_allocation *alloc = (void
> *)(uintptr_t)t;
> +   struct efi_pool_allocation *alloc =
> map_sysmem(t,
> size);


 This is still the wrong spot. We don't want the conversion to
 happen when
 going from an EFI internal address to an allocation, but when
 determining
 which addresses are usable in the first place.
>>>
>>> There seem to be two ways to do this:
>>>
>>> 1. Record addresses (ulong) in the EFI tables and use
>>> map_sysmem()
>>> before returning an address in the allocator
>>> 2. Store pointers in the EFI tables using map_sysmem(), then do
>>> no
>>> mapping in the allocator
>>>
>>> I've gone with option 1 since:
>>>
>>> - the EFI addresses are not pointers
>>> - it makes sandbox consistent with other architectures which use
>>> an
>>> address rather than a pointer in EFI tables
>>> - we don't normally do pointer arithmetic on the results of
>>> map_sysmem()
>>> - we normally map the memory when it is used rather than when it
>>> is
>>> set up
>>>
>>> I think you are asking for option 2. I think that would get very
>>> confusing. The addresses where things actually end up in sandbox
>>> are
>>> best kept to sandbox.
>>>
>>> Overall I feel that you are either missing the point of sandbox
>>> add

[U-Boot] make Menuconfig Error

[DH]

Cloned most recent u-boot 2018.06.14
make clean works
make menuconfig fails:

/bin/sh: 1: bison: not found
scripts/kconfig/Makefile:229: recipe for target
'scripts/kconfig/dochecklxdialog' failed make[1]: ***
[scripts/kconfig/dochecklxdialog] Error 1 Makefile:491: recipe for
target 'menuconfig' failed make: *** [menuconfig] Error 2

I've checked for bison, visually and with apt-cache search but I have
found none.

Will try rebuild based on u-boot from 2018.05.14 on SPDX errors, That
version did build.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/12] net: phy: ti: Add binding for the CLK_OUT pin muxing

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> The DP83867 has a muxing option for the CLK_OUT pin. It is possible
> to set CLK_OUT for different channels.
> Create a binding to select a specific clock for CLK_OUT pin.
>
> Based on commit '9708fb630d19ee51ae3aeb3a533e3010da0e8570' mainline
> linux kernel.

Same here...

> Signed-off-by: Janine Hagemann 
> ---
>  drivers/net/phy/ti.c | 24 
>  include/dt-bindings/net/ti-dp83867.h | 15 +++

Please also add to doc/device-tree-bindings/net/ti,dp83867.txt

>  2 files changed, 39 insertions(+)
>
> diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
> index cc04789..9044b0f 100644
> --- a/drivers/net/phy/ti.c
> +++ b/drivers/net/phy/ti.c
> @@ -96,6 +96,8 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
>  #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
> +#define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK  (0x1f << 8)
> +#define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT 8

Reverse order of these defines and use the shift to make the mask.

Also, use GENMASK(13, DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT)

>
>  /* CFG4 bits */
>  #define DP83867_CFG4_PORT_MIRROR_ENBIT(0)
> @@ -113,6 +115,7 @@ struct dp83867_private {
> int io_impedance;
> int port_mirroring;
> bool rxctrl_strap_quirk;
> +   int clk_output_sel;
>  };
>
>  /**
> @@ -213,6 +216,16 @@ static int dp83867_of_init(struct phy_device *phydev)
> struct udevice *dev = phydev->dev;
> int node = dev_of_offset(dev);
> const void *fdt = gd->fdt_blob;
> +   u16 val;
> +
> +   /* Optional configuration */
> +
> +   /* Keep the default value if ti,clk-output-sel is not set

Please use standard mutli-line comment format "/*" gets its own line.

> +* or to high
> +*/
> +
> +   dp83867->clk_output_sel = fdtdec_get_uint(fdt, node,
> + "ti,clk-output-sel", 
> DP83867_CLK_O_SEL_REF_CLK);
>
> if (fdtdec_get_bool(fdt, node, "ti,max-output-impedance"))
> dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> @@ -239,6 +252,17 @@ static int dp83867_of_init(struct phy_device *phydev)
> dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob, 
> dev_of_offset(dev),
>  "ti,fifo-depth", -1);
>
> +   /* Clock output selection if muxing property is set */
> +   if (dp83867->clk_output_sel != DP83867_CLK_O_SEL_REF_CLK) {
> +   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> +   DP83867_DEVADDR, phydev->addr);
> +   val &= ~DP83867_IO_MUX_CFG_CLK_O_SEL_MASK;
> +   val |= (dp83867->clk_output_sel <<
> +   DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT);
> +   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> +   DP83867_DEVADDR, phydev->addr, val);
> +   }
> +
> return 0;
>  }
>  #else
> diff --git a/include/dt-bindings/net/ti-dp83867.h 
> b/include/dt-bindings/net/ti-dp83867.h
> index b8e5df6..85d08f6 100644
> --- a/include/dt-bindings/net/ti-dp83867.h
> +++ b/include/dt-bindings/net/ti-dp83867.h
> @@ -31,4 +31,19 @@
>  #define DP83867_RGMIIDCTL_3_75_NS  0xe
>  #define DP83867_RGMIIDCTL_4_00_NS  0xf
>
> +/* IO_MUX_CFG - Clock output selection */
> +#define DP83867_CLK_O_SEL_CHN_A_RCLK   0x0
> +#define DP83867_CLK_O_SEL_CHN_B_RCLK   0x1
> +#define DP83867_CLK_O_SEL_CHN_C_RCLK   0x2
> +#define DP83867_CLK_O_SEL_CHN_D_RCLK   0x3
> +#define DP83867_CLK_O_SEL_CHN_A_RCLK_DIV5  0x4
> +#define DP83867_CLK_O_SEL_CHN_B_RCLK_DIV5  0x5
> +#define DP83867_CLK_O_SEL_CHN_C_RCLK_DIV5  0x6
> +#define DP83867_CLK_O_SEL_CHN_D_RCLK_DIV5  0x7
> +#define DP83867_CLK_O_SEL_CHN_A_TCLK   0x8
> +#define DP83867_CLK_O_SEL_CHN_B_TCLK   0x9
> +#define DP83867_CLK_O_SEL_CHN_C_TCLK   0xA
> +#define DP83867_CLK_O_SEL_CHN_D_TCLK   0xB
> +#define DP83867_CLK_O_SEL_REF_CLK  0xC
> +
>  #endif
> --
> 2.7.4
>
> ___
> 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 v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Alexander Graf]

On 14.06.18 19:55, Heinrich Schuchardt wrote:
> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
>> This series makes it possible to run EFI applications in non-secure
>> mode.  It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and
>> Banana Pi boards using the PSCI implementation provided by U-Boot.
>>
>> The second version avoids using r3 to pass the original stack pointer.
>> For some reason that register gets clobbered on the Banana Pi.  Instead
>> this version just migrates SP_svc to SP_hyp.
>>
>> This third version avoids saving r3 on the stack and fixes an include
>> guard as suggested by Alexander Graf.
>>
>> Mark Kettenis (3):
>>   ARM: HYP/non-sec: migrate stack
>>   efi_loader: ARM: run EFI payloads non-secure
>>   Revert "efi_loader: no support for ARMV7_NONSEC=y"
>>
>>  arch/arm/cpu/armv7/nonsec_virt.S |  2 ++
>>  cmd/bootefi.c| 32 
>>  doc/README.uefi  |  2 --
>>  lib/efi_loader/Kconfig   |  2 --
>>  4 files changed, 34 insertions(+), 4 deletions(-)
>>
> Hello Mark,
> 
> with this patch series running bootefi hello twice in sequence fails on
> the BananaPi.
> 
> => bootefi hello
> Scanning disk m...@01c0f000.blk...
> Found 3 disks
> WARNING: booting without device tree
> ## Starting EFI application at 4200 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> Hello, world!
> Running on UEFI 2.7
> Have SMBIOS table
> Load options: earlyprintk nosmp
> ## Application terminated, r = 0
> => bootefi hello
> WARNING: booting without device tree
> ## Starting EFI application at 4200 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> 
> 
> Please, keep in mind that we expect multiple EFI binaries to be executed
> in sequence. E.g. the first binary installs a driver. The second is the
> application using it.
> 
> Running iPXE's snp.efi binary shows changed behavior on the console. New
> characters are displayed in "slow motion" (3 characters per second).

Cache disabled maybe?

Alex

> Setting up the network interface fails in iPXE.
> 
> Best regards
> 
> Heinrich
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Heinrich Schuchardt]

On 06/14/2018 12:41 AM, Mark Kettenis wrote:
> This series makes it possible to run EFI applications in non-secure
> mode.  It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and
> Banana Pi boards using the PSCI implementation provided by U-Boot.
> 
> The second version avoids using r3 to pass the original stack pointer.
> For some reason that register gets clobbered on the Banana Pi.  Instead
> this version just migrates SP_svc to SP_hyp.
> 
> This third version avoids saving r3 on the stack and fixes an include
> guard as suggested by Alexander Graf.
> 
> Mark Kettenis (3):
>   ARM: HYP/non-sec: migrate stack
>   efi_loader: ARM: run EFI payloads non-secure
>   Revert "efi_loader: no support for ARMV7_NONSEC=y"
> 
>  arch/arm/cpu/armv7/nonsec_virt.S |  2 ++
>  cmd/bootefi.c| 32 
>  doc/README.uefi  |  2 --
>  lib/efi_loader/Kconfig   |  2 --
>  4 files changed, 34 insertions(+), 4 deletions(-)
> 
Hello Mark,

with this patch series running bootefi hello twice in sequence fails on
the BananaPi.

=> bootefi hello
Scanning disk m...@01c0f000.blk...
Found 3 disks
WARNING: booting without device tree
## Starting EFI application at 4200 ...
WARNING: using memory device/image path, this may confuse some payloads!
Hello, world!
Running on UEFI 2.7
Have SMBIOS table
Load options: earlyprintk nosmp
## Application terminated, r = 0
=> bootefi hello
WARNING: booting without device tree
## Starting EFI application at 4200 ...
WARNING: using memory device/image path, this may confuse some payloads!


Please, keep in mind that we expect multiple EFI binaries to be executed
in sequence. E.g. the first binary installs a driver. The second is the
application using it.

Running iPXE's snp.efi binary shows changed behavior on the console. New
characters are displayed in "slow motion" (3 characters per second).
Setting up the network interface fails in iPXE.

Best regards

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

Re: [U-Boot] [PATCH 09/12] drivers: net: designware: Add reading of DT phy-handle node

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> Add the ability to read the phy-handle node of the
> gmac.  Upon reading this handle the phy-id
> can be stored based on the reg node in the DT.
>
> The phy-handle also needs to be stored and passed
> to the phy to access any phy data that is available.
>
> Signed-off-by: Janine Hagemann 

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

Re: [U-Boot] [PATCH 08/12] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> Using PHY internal delays in combination with the phy-mode
> rgmii-id/rxid/txid was not possible. Only rgmii was supported.
>
> Now we can disable rockchip's gmac delay lines and also use
> rgmii-id/rxid/txid.
>
> Based on commit 'eaf70ad14cbbb99d46b78b1307628a16a3f6075d' from
> mainline linux kernel.

Same here...

> Signed-off-by: Janine Hagemann 

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

Re: [U-Boot] [PATCH 07/12] net: phy: ti: add workaround for incorrect RX_CTRL pin strap

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> The data manual for DP83867IR/CR, SNLS484E[1], revised march 2017,
> advises that strapping RX_DV/RX_CTRL pin in mode 1 and 2 is not
> supported (see note below Table 5 (4-Level Strap Pins)).
>
> There are some boards which have the pin strapped this way and need
> software workaround suggested by the data manual. Bit[7] of
> Configuration Register 4 (address 0x0031) must be cleared to 0. This
> ensures proper operation of the PHY.
>
> Implement driver support for device-tree property meant to advertise
> the wrong strapping.
>
> [1] http://www.ti.com/lit/ds/snls484e/snls484e.pdf
>
> Based on commit '371444764b9882d754d1e67dd212c932359a2293' of mainline
> linux kernel.

And here...

> Signed-off-by: Janine Hagemann 

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

Re: [U-Boot] [PATCH v2] x86: Add 64-bit setjmp/longjmp implementation

[Alexander Graf]

> Am 14.06.2018 um 19:15 schrieb Ivan Gorinov :
> 
> On Wed, Jun 13, 2018 at 05:36:26PM -0700, Ivan Gorinov wrote:
> 
>>> But bootefi selftest with your patch leads to an immediate reset of the
>>> qemu-x86_64 board.
>> 
>> Reproduced the qemu-x86_64 reset.
>> The "info registers" command shows CR0.MP = 0.
>> Setting it in 64-bit startup code did not help.
>> I will try to fix that.
>> 
>> On a 64-bit Minnowboard configuration, bootefi works without reset.
> 
> The "bootefi selftest" command works on qemu-x86_64 when $loadaddr is changed:
>  => env set loadaddr 0x1000
> 
> Another patch "x86: use EFI calling convention for efi_main on x86_64"
> also needs to be applied.
> 
> The self test starts but crashes on 'manage protocols':
> 
>  Tearing down 'graphical output'
>  Tearing down 'graphical output' succeeded
> 
>  Setting up 'manage protocols'
> 
> 
> Same effect with a 64-bit build for Minnowboard.

I see the same with the sandbox patch set I just sent. IIUC sonething goes 
wrong in varargs handling.

Alex


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

Re: [U-Boot] [PATCH 06/12] net: phy: ti: Recover from "port mirroring" N/A MODE4

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> The DP83867 when not properly bootstrapped - especially with LED_0 pin -
> can enter N/A MODE4 for "port mirroring" feature.
>
> To provide normal operation of the PHY, one needs not only to explicitly
> disable the port mirroring feature, but as well stop some IC internal
> testing (which disables RGMII communication).
>
> To do that the STRAP_STS1 (0x006E) register must be read and RESERVED bit
> 11 examined. When it is set, the another RESERVED bit (11) at PHYCR
> (0x0010) register must be clear to disable testing mode and enable RGMII
> communication.
>
> Thorough explanation of the problem can be found at following e2e thread:
> "DP83867IR: Problem with RESERVED bits in PHY Control Register (PHYCR) -
> Linux driver"
>
> https://e2e.ti.com/support/interface/ethernet/f/903/p/571313/2096954#2096954
>
> Based on commit 'ac6e058b75be71208e98a5808453aae9a17be480' of mainline linux
> kernel.

Same comment about commit reference format.

>
> Signed-off-by: Janine Hagemann 

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

Re: [U-Boot] [PATCH v2 5/9] clk: Add Actions Semi OWL clock support

[Simon Glass]

Hi,

On 14 June 2018 at 11:25, Manivannan Sadhasivam
 wrote:
> Hi Simon,
>
> On Thu, Jun 14, 2018 at 08:16:53AM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 14 June 2018 at 07:13, Manivannan Sadhasivam
>>  wrote:
>> > Hi Simon,
>> >
>> > On Thu, Jun 14, 2018 at 06:58:40AM -0600, Simon Glass wrote:
>> >> Hi,
>> >>
>> >> On 12 June 2018 at 22:15, Manivannan Sadhasivam
>> >>  wrote:
>> >> > This commit adds Actions Semi OWL family base clock and S900 SoC 
>> >> > specific
>> >> > clock support. For S900 peripheral clock support, only UART clock has 
>> >> > been
>> >> > added for now.
>> >> >
>> >> > Signed-off-by: Manivannan Sadhasivam 
>> >> > ---
>> >> >  arch/arm/include/asm/arch-owl/clk_s900.h  |  57 +
>> >> >  arch/arm/include/asm/arch-owl/regs_s900.h |  64 ++
>> >> >  drivers/clk/Kconfig   |   1 +
>> >> >  drivers/clk/Makefile  |   1 +
>> >> >  drivers/clk/owl/Kconfig   |  12 ++
>> >> >  drivers/clk/owl/Makefile  |   3 +
>> >> >  drivers/clk/owl/clk_s900.c| 138 ++
>> >> >  7 files changed, 276 insertions(+)
>> >> >  create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
>> >> >  create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
>> >> >  create mode 100644 drivers/clk/owl/Kconfig
>> >> >  create mode 100644 drivers/clk/owl/Makefile
>> >> >  create mode 100644 drivers/clk/owl/clk_s900.c
>> >>
>> >> This says v2 but I don't see a change log. Have you tried using
>> >> patman? It does this for you easily.
>> >>
>> >
>> > Sorry, I have added the changelog in coverletter of the patchseries! Is it 
>> > a
>> > bad practice in U-Boot?
>>
>> I'm not sure about bad practice, but without it, it's hard to know
>> what you've changed in this patch.
>>
>
> Okay. Should I send another version adding changelog in commit?

That would make me happy :-)

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

Re: [U-Boot] [PATCH 05/12] net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> This patch adds support for enabling or disabling the lane swapping
> (called "port mirroring" in PHY's CFG4 register) feature of the DP83867
> TI's PHY device.
>
> One use case is when bootstrap configuration enables this feature (because
> of e.g. LED_0 wrong wiring) so then one needs to disable it in software
> (at u-boot/Linux).
>
> Based on commit 'fc6d39c39581f3c12c95f166ce95ef8beb2047e8' of mainline
> linux kernel

I think you are always supposed to include the summary text when
referencing a commit as well. Does checkpatch not complain about this?

>
> Signed-off-by: Janine Hagemann 

Otherwise,
Acked-by: Joe Hershberger 

> ---
>  drivers/net/phy/ti.c | 40 
>  1 file changed, 40 insertions(+)
>
> diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
> index d7ae881..086ea4a 100644
> --- a/drivers/net/phy/ti.c
> +++ b/drivers/net/phy/ti.c
> @@ -24,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define DP83867_CTRL   0x1f
>
>  /* Extended Registers */
> +#define DP83867_CFG4   0x0031
>  #define DP83867_RGMIICTL   0x0032
>  #define DP83867_RGMIIDCTL  0x0086
>  #define DP83867_IO_MUX_CFG 0x0170
> @@ -92,11 +93,21 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
>  #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
>
> +/* CFG4 bits */
> +#define DP83867_CFG4_PORT_MIRROR_ENBIT(0)
> +
> +enum {
> +   DP83867_PORT_MIRRORING_KEEP,
> +   DP83867_PORT_MIRRORING_EN,
> +   DP83867_PORT_MIRRORING_DIS,
> +};
> +
>  struct dp83867_private {
> int rx_id_delay;
> int tx_id_delay;
> int fifo_depth;
> int io_impedance;
> +   int port_mirroring;
>  };
>
>  /**
> @@ -165,6 +176,26 @@ void phy_write_mmd_indirect(struct phy_device *phydev, 
> int prtad,
> phy_write(phydev, addr, MII_MMD_DATA, data);
>  }
>
> +static int dp83867_config_port_mirroring(struct phy_device *phydev)
> +{
> +   struct dp83867_private *dp83867 =
> +   (struct dp83867_private *)phydev->priv;
> +   u16 val;
> +
> +   val = phy_read_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
> +phydev->addr);
> +
> +   if (dp83867->port_mirroring == DP83867_PORT_MIRRORING_EN)
> +   val |= DP83867_CFG4_PORT_MIRROR_EN;
> +   else
> +   val &= ~DP83867_CFG4_PORT_MIRROR_EN;
> +
> +   phy_write_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
> +   phydev->addr, val);
> +
> +   return 0;
> +}
> +
>  #if defined(CONFIG_DM_ETH)
>  /**
>   * dp83867_data_init - Convenience function for setting PHY specific data
> @@ -191,6 +222,12 @@ static int dp83867_of_init(struct phy_device *phydev)
> dp83867->tx_id_delay = fdtdec_get_uint(gd->fdt_blob, 
> dev_of_offset(dev),
>  "ti,tx-internal-delay", -1);
>
> +   if (fdtdec_get_bool(fdt, node, "enet-phy-lane-swap"))
> +   dp83867->port_mirroring = DP83867_PORT_MIRRORING_EN;
> +
> +   if (fdtdec_get_bool(fdt, node, "enet-phy-lane-no-swap"))
> +   dp83867->port_mirroring = DP83867_PORT_MIRRORING_DIS;
> +
> dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob, 
> dev_of_offset(dev),
>  "ti,fifo-depth", -1);
>
> @@ -307,6 +344,9 @@ static int dp83867_config(struct phy_device *phydev)
> }
> }
>
> +   if (dp83867->port_mirroring != DP83867_PORT_MIRRORING_KEEP)
> +   dp83867_config_port_mirroring(phydev);
> +
> genphy_config_aneg(phydev);
> return 0;
>
> --
> 2.7.4
>
> ___
> 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 04/12] Net: phy: ti: Fix fifo_depth register write

[Joe Hershberger]

On Thu, Jun 14, 2018 at 12:09 PM, Trent Piepho  wrote:
> On Thu, 2018-06-14 at 10:53 +, u-boot-requ...@lists.denx.de wrote:
>> Message: 52
>> Date: Thu, 14 Jun 2018 11:48:48 +0200
>> From: Janine Hagemann 
>> To: albert.u.b...@aribaud.net, s...@chromium.org,
>>   philipp.toms...@theobroma-systems.com, w.ego...@phytec.de,
>>   joe.hershber...@ni.com, u-boot@lists.denx.de
>> Subject: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register
>>   write
>> Message-ID: <1528969736-44037-4-git-send-email-j.hagem...@phytec.de>
>>
>> The register was not read before the writing, so the
>> previous value was overwritten.

Was this changed because of some problem? Please include more details
in the change log.

>> @@ -233,9 +235,14 @@ static int dp83867_config(struct phy_device *phydev)
>> val | DP83867_SW_RESTART);
>>
>>   if (phy_interface_is_rgmii(phydev)) {
>> + val = phy_read(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL);
>> + if (val < 0)
>> + return val;
>> + val &= ~DP83867_PHYCR_FIFO_DEPTH_MASK;
>> + val |= (dp83867->fifo_depth << DP83867_PHYCR_FIFO_DEPTH_SHIFT);
>>   ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
>> - (DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
>> - (dp83867->fifo_depth << 
>> DP83867_PHYCR_FIFO_DEPTH_SHIFT));
>> + val);
>> +
>>   if (ret)
>>   goto err_out;
>>   } else if (phy_interface_is_sgmii(phydev)) {
>
> If any of the bits that prevent the phy from working are set, like
> DEEP_POWER_DOWN_EN, POWER_SAVE_MODE, and so on, they won't be reset
> anymore.  I.e., put phy in power save mode, reboot, phy doesn't work
> anymore.  I think the code here is suppose to be configuring the phy,
> rather than changing a configuration that was done elsewhere.
> ___
> 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 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

[Joe Hershberger]

On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann  wrote:
> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
> to enable the RX delay.
> The MASK was used in a wrong way.
>
> Signed-off-by: Janine Hagemann 

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

Re: [U-Boot] [PATCH] net: zynq_gem: Initialize val variable in zynq_gem_miiphy_read()

[Joe Hershberger]

On Thu, Jun 14, 2018 at 2:08 AM, Michal Simek  wrote:
> phyread can timeout and val will contain random value. Initialize it to
> zero not to report random value in case of error.
>
> Signed-off-by: Michal Simek 

Acked-by: Joe Hershberger 

> ---
>
> Reported by: Coverity (local)
>
> ---
>  drivers/net/zynq_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index a817f2e5d69b..d1138fe0903d 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -609,7 +609,7 @@ static int zynq_gem_miiphy_read(struct mii_dev *bus, int 
> addr,
>  {
> struct zynq_gem_priv *priv = bus->priv;
> int ret;
> -   u16 val;
> +   u16 val = 0;
>
> ret = phyread(priv, addr, reg, &val);
> debug("%s 0x%x, 0x%x, 0x%x, 0x%x\n", __func__, addr, reg, val, ret);
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/9] clk: Add Actions Semi OWL clock support

[Manivannan Sadhasivam]

Hi Simon,

On Thu, Jun 14, 2018 at 08:16:53AM -0600, Simon Glass wrote:
> Hi,
> 
> On 14 June 2018 at 07:13, Manivannan Sadhasivam
>  wrote:
> > Hi Simon,
> >
> > On Thu, Jun 14, 2018 at 06:58:40AM -0600, Simon Glass wrote:
> >> Hi,
> >>
> >> On 12 June 2018 at 22:15, Manivannan Sadhasivam
> >>  wrote:
> >> > This commit adds Actions Semi OWL family base clock and S900 SoC specific
> >> > clock support. For S900 peripheral clock support, only UART clock has 
> >> > been
> >> > added for now.
> >> >
> >> > Signed-off-by: Manivannan Sadhasivam 
> >> > ---
> >> >  arch/arm/include/asm/arch-owl/clk_s900.h  |  57 +
> >> >  arch/arm/include/asm/arch-owl/regs_s900.h |  64 ++
> >> >  drivers/clk/Kconfig   |   1 +
> >> >  drivers/clk/Makefile  |   1 +
> >> >  drivers/clk/owl/Kconfig   |  12 ++
> >> >  drivers/clk/owl/Makefile  |   3 +
> >> >  drivers/clk/owl/clk_s900.c| 138 ++
> >> >  7 files changed, 276 insertions(+)
> >> >  create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
> >> >  create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
> >> >  create mode 100644 drivers/clk/owl/Kconfig
> >> >  create mode 100644 drivers/clk/owl/Makefile
> >> >  create mode 100644 drivers/clk/owl/clk_s900.c
> >>
> >> This says v2 but I don't see a change log. Have you tried using
> >> patman? It does this for you easily.
> >>
> >
> > Sorry, I have added the changelog in coverletter of the patchseries! Is it a
> > bad practice in U-Boot?
> 
> I'm not sure about bad practice, but without it, it's hard to know
> what you've changed in this patch.
>

Okay. Should I send another version adding changelog in commit?

Thanks,
Mani

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

Re: [U-Boot] [PATCH v2] x86: Add 64-bit setjmp/longjmp implementation

[Ivan Gorinov]

On Wed, Jun 13, 2018 at 05:36:26PM -0700, Ivan Gorinov wrote:

> > But bootefi selftest with your patch leads to an immediate reset of the
> > qemu-x86_64 board.
> 
> Reproduced the qemu-x86_64 reset.
> The "info registers" command shows CR0.MP = 0.
> Setting it in 64-bit startup code did not help.
> I will try to fix that.
> 
> On a 64-bit Minnowboard configuration, bootefi works without reset.

The "bootefi selftest" command works on qemu-x86_64 when $loadaddr is changed:
  => env set loadaddr 0x1000

Another patch "x86: use EFI calling convention for efi_main on x86_64"
also needs to be applied.

The self test starts but crashes on 'manage protocols':

  Tearing down 'graphical output'
  Tearing down 'graphical output' succeeded

  Setting up 'manage protocols'


Same effect with a 64-bit build for Minnowboard.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox

[Simon Glass]

Hi Alex,

On 14 June 2018 at 11:08, Alexander Graf  wrote:
>
> On 06/14/2018 06:55 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 June 2018 at 10:42, Alexander Graf  wrote:
>>>
>>> On 06/14/2018 06:33 PM, Simon Glass wrote:

 Hi Alex,

 On 14 June 2018 at 10:26, Alexander Graf  wrote:
>
> On 06/14/2018 06:13 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 June 2018 at 10:07, Alexander Graf  wrote:
>>>
>>> On 06/14/2018 05:53 PM, Simon Glass wrote:

 Hi Alex,

 On 14 June 2018 at 09:47, Alexander Graf  wrote:
>
>
>> Am 14.06.2018 um 17:43 schrieb Simon Glass :
>>
>> Hi Alex,
>>
>>> On 14 June 2018 at 08:22, Alexander Graf  wrote:
>>>
>>>
>>>
 Am 14.06.2018 um 16:12 schrieb Simon Glass :

 Hi Alex,

>> On 14 June 2018 at 07:41, Alexander Graf  wrote:
>> On 06/14/2018 02:58 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
 On 14 June 2018 at 04:12, Alexander Graf 
 wrote:

 On 06/13/2018 04:37 AM, Simon Glass wrote:

 With sandbox the U-Boot code is not mapped into the sandbox
 memory
 range
 so does not need to be excluded when allocating EFI memory.
 Update
 the
 EFI
 memory init code to take account of that.

 Also use mapmem instead of a cast to convert a memory address
 to
 a
 pointer.

 Signed-off-by: Simon Glass 
 ---

 Changes in v6: None
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2:
 - Update to use mapmem instead of a cast

  lib/efi_loader/efi_memory.c | 31
 ++-
  1 file changed, 18 insertions(+), 13 deletions(-)

 diff --git a/lib/efi_loader/efi_memory.c
 b/lib/efi_loader/efi_memory.c
 index ec66af98ea..210e49ee8b 100644
 --- a/lib/efi_loader/efi_memory.c
 +++ b/lib/efi_loader/efi_memory.c
 @@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
 pool_type,
 efi_uintn_t size, void **buffer)
   &t);
if (r == EFI_SUCCESS) {
 -   struct efi_pool_allocation *alloc = (void
 *)(uintptr_t)t;
 +   struct efi_pool_allocation *alloc =
 map_sysmem(t,
 size);
>>>
>>>
>>> This is still the wrong spot. We don't want the conversion to
>>> happen when
>>> going from an EFI internal address to an allocation, but when
>>> determining
>>> which addresses are usable in the first place.
>>
>> There seem to be two ways to do this:
>>
>> 1. Record addresses (ulong) in the EFI tables and use
>> map_sysmem()
>> before returning an address in the allocator
>> 2. Store pointers in the EFI tables using map_sysmem(), then do
>> no
>> mapping in the allocator
>>
>> I've gone with option 1 since:
>>
>> - the EFI addresses are not pointers
>> - it makes sandbox consistent with other architectures which use
>> an
>> address rather than a pointer in EFI tables
>> - we don't normally do pointer arithmetic on the results of
>> map_sysmem()
>> - we normally map the memory when it is used rather than when it
>> is
>> set up
>>
>> I think you are asking for option 2. I think that would get very
>> confusing. The addresses where things actually end up in sandbox
>> are
>> best kept to sandbox.
>>
>> Overall I feel that you are either missing the point of sandbox
>> addressing, or don't agree with how it is done. But it does work
>> pretty well and we don't get a lot of confusion with sandbox
>> pointers
>> sin

Re: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register write

[Trent Piepho]

On Thu, 2018-06-14 at 10:53 +, u-boot-requ...@lists.denx.de wrote:
> Message: 52
> Date: Thu, 14 Jun 2018 11:48:48 +0200
> From: Janine Hagemann 
> To: albert.u.b...@aribaud.net, s...@chromium.org,
>   philipp.toms...@theobroma-systems.com, w.ego...@phytec.de,
>   joe.hershber...@ni.com, u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register
>   write
> Message-ID: <1528969736-44037-4-git-send-email-j.hagem...@phytec.de>
> 
> The register was not read before the writing, so the
> previous value was overwritten.
> 
> @@ -233,9 +235,14 @@ static int dp83867_config(struct phy_device *phydev)
> val | DP83867_SW_RESTART);
>  
>   if (phy_interface_is_rgmii(phydev)) {
> + val = phy_read(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL);
> + if (val < 0)
> + return val;
> + val &= ~DP83867_PHYCR_FIFO_DEPTH_MASK;
> + val |= (dp83867->fifo_depth << DP83867_PHYCR_FIFO_DEPTH_SHIFT);
>   ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
> - (DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
> - (dp83867->fifo_depth << 
> DP83867_PHYCR_FIFO_DEPTH_SHIFT));
> + val);
> +
>   if (ret)
>   goto err_out;
>   } else if (phy_interface_is_sgmii(phydev)) {

If any of the bits that prevent the phy from working are set, like
DEEP_POWER_DOWN_EN, POWER_SAVE_MODE, and so on, they won't be reset
anymore.  I.e., put phy in power save mode, reboot, phy doesn't work
anymore.  I think the code here is suppose to be configuring the phy,
rather than changing a configuration that was done elsewhere.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/11] sandbox: efi_loader support

[Alexander Graf]

On 06/14/2018 06:55 PM, Simon Glass wrote:

Hi,

On 14 June 2018 at 10:33, Alexander Graf  wrote:

This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but follows a different memory allocation scheme.

Instead of keeping U-Boot (physical) addresses in the EFI memory
map, this patch set makes the EFI memory map contain host virtual
(virtual) addresses. That way most logic "just works" and all EFI
interfaces automatically gain sandbox awareness.

With this patch set in place, I can run a good chunk of the selftest
suite as well as efi binaries compiled using gnu-efi.

Can you rebase this on top of my series? You seem to have picked up
only a few patches from my series. Ideally I'd like to get those
applied so that sandbox works, and then do future work on top of that.


I did that on purpose, yes. I omitted patches that we either don't need 
(like the smbios one, because we already call the helpers with pointers) 
or that I think move us into the wrong direction (like the one that 
calls map_sysmem() in the allocation path or the new bootefi test target 
where I would rather like to see the selftest target extended.



Alex

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

Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox

[Alexander Graf]

On 06/14/2018 06:55 PM, Simon Glass wrote:

Hi Alex,

On 14 June 2018 at 10:42, Alexander Graf  wrote:

On 06/14/2018 06:33 PM, Simon Glass wrote:

Hi Alex,

On 14 June 2018 at 10:26, Alexander Graf  wrote:

On 06/14/2018 06:13 PM, Simon Glass wrote:

Hi Alex,

On 14 June 2018 at 10:07, Alexander Graf  wrote:

On 06/14/2018 05:53 PM, Simon Glass wrote:

Hi Alex,

On 14 June 2018 at 09:47, Alexander Graf  wrote:



Am 14.06.2018 um 17:43 schrieb Simon Glass :

Hi Alex,


On 14 June 2018 at 08:22, Alexander Graf  wrote:




Am 14.06.2018 um 16:12 schrieb Simon Glass :

Hi Alex,


On 14 June 2018 at 07:41, Alexander Graf  wrote:
On 06/14/2018 02:58 PM, Simon Glass wrote:

Hi Alex,


On 14 June 2018 at 04:12, Alexander Graf 
wrote:

On 06/13/2018 04:37 AM, Simon Glass wrote:

With sandbox the U-Boot code is not mapped into the sandbox
memory
range
so does not need to be excluded when allocating EFI memory.
Update
the
EFI
memory init code to take account of that.

Also use mapmem instead of a cast to convert a memory address
to
a
pointer.

Signed-off-by: Simon Glass 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Update to use mapmem instead of a cast

 lib/efi_loader/efi_memory.c | 31
++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c
b/lib/efi_loader/efi_memory.c
index ec66af98ea..210e49ee8b 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
pool_type,
efi_uintn_t size, void **buffer)
  &t);
   if (r == EFI_SUCCESS) {
-   struct efi_pool_allocation *alloc = (void
*)(uintptr_t)t;
+   struct efi_pool_allocation *alloc =
map_sysmem(t,
size);


This is still the wrong spot. We don't want the conversion to
happen when
going from an EFI internal address to an allocation, but when
determining
which addresses are usable in the first place.

There seem to be two ways to do this:

1. Record addresses (ulong) in the EFI tables and use
map_sysmem()
before returning an address in the allocator
2. Store pointers in the EFI tables using map_sysmem(), then do
no
mapping in the allocator

I've gone with option 1 since:

- the EFI addresses are not pointers
- it makes sandbox consistent with other architectures which use
an
address rather than a pointer in EFI tables
- we don't normally do pointer arithmetic on the results of
map_sysmem()
- we normally map the memory when it is used rather than when it
is
set up

I think you are asking for option 2. I think that would get very
confusing. The addresses where things actually end up in sandbox
are
best kept to sandbox.

Overall I feel that you are either missing the point of sandbox
addressing, or don't agree with how it is done. But it does work
pretty well and we don't get a lot of confusion with sandbox
pointers
since we typically use the address until the last moment.


I've assembled a quick tree for version 2. With that I'm able to
run
a
simple hello world efi application. Grub refuses to start because
it
wants
memory in the low 32bit and also emits random PIO accessing
functions, which
obviously don't work work from user space.

But overall, I think this is the right path to tackle this:

https://github.com/agraf/u-boot/tree/efi-sandbox

What do you mean by version 2?

Option 2 is what you called it. It's the only option we have to
make
efi binaries work.


It looks like you've added one patch,
so will you send that to the list?

It's more than 1 patch. And yes, I'll send them.


Anyway, I hope I can convince you of the above, the way sandbox
memory
works.

I still dislike option 1 :)

The reason is simple: The efi memory map is available to efi
payloads.
It's perfectly legal for them to do a static allocation at a
particular
address. We also share a lot of (host) pointers for callbacks and
structs
already with efi applications, so there is no real point to have a
split
brain situation between u-boot and host pointers.

OK so you mean they don't have to allocate memory before using it?
How
then do you make sure that there is no conflict? I thought EFI was
an
API?

You allocate it, but payloads expect that the address you pass in as
address you allocate at is the pointer/address that gets returned.


Can you please point me to that? Are you referring to this call?

static efi_status_t EFIAPI efi_get_memory_map_ext(
efi_uintn_t *memory_map_size,
struct efi_mem_desc *memory_map,
efi_uintn_t *map_key,
efi_uintn_t *descriptor_size,
uint32_t *descriptor_version)

If so, we can still support that.


In a nutshell, what you're proposing is that the efi quivalent of
mmap(addr, MAP_FIXED) returns something != addr. That will break
things.

I s

Re: [U-Boot] [PATCH v2 2/3] net: Add option to prefer bootp/dhcp serverip

[Joe Hershberger]

On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf  wrote:
> Currently we can choose between 2 different types of behavior for the
> serverip variable:
>
>   1) Always overwrite it with the DHCP server IP address (default)
>   2) Ignore what the DHCP server says (CONFIG_BOOTP_SERVERIP)
>
> This patch adds a 3rd option:
>
>   3) Use serverip from DHCP if no serverip is given
>  (CONFIG_BOOTP_PREFER_SERVERIP)
>
> With this new option, we can have the default case that a boot file gets
> loaded from the DHCP provided TFTP server work while allowing users to
> specify their own serverip variable to explicitly use a different tftp
> server.
>
> Signed-off-by: Alexander Graf 

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

[U-Boot] [PULL] efi patch queue 2018-06-14

[Alexander Graf]

Hi Tom,

This is my current patch queue for efi.  Please pull.

Alex


The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7:

  ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400)

are available in the git repository at:

  git://github.com/agraf/u-boot.git tags/signed-efi-next

for you to fetch changes up to 58bc69d20aaf2e32e93e977d708fe6a1af0ad6d1:

  efi_loader: Allocate memory handle for mem dp (2018-06-14 10:53:37 +0200)


Patch queue for efi - 2018-06-14

A few minor fixes for the release:

  - Compile fixes
  - HI20 relocations for RISC-V
  - Fix bootefi without load path
  - Fix Runtime Services with certain compilers


Alexander Graf (3):
  riscv: Add support for HI20 PE relocations
  efi_loader: Convert runtime reset from switch to if statements
  efi_loader: Allocate memory handle for mem dp

Heinrich Schuchardt (2):
  efi_loader: avoid initializer element is not constant
  efi_loader: avoid make race condition

Simon Glass (1):
  efi: Add a comment about duplicated ELF constants

 arch/arm/cpu/armv8/fwcall.c   | 11 ---
 arch/arm/mach-bcm283x/reset.c | 11 ---
 cmd/bootefi.c |  9 +
 disk/part_efi.c   |  9 +++--
 include/efi.h |  3 +--
 include/pe.h  |  3 +++
 lib/efi_loader/efi_image_loader.c | 14 ++
 lib/efi_loader/efi_runtime.c  |  4 
 scripts/Makefile.lib  | 10 --
 9 files changed, 54 insertions(+), 20 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v7 09/10] efi: Create a function to set up for running EFI code

[Simon Glass]

Add a new bootefi_run_prepare() function which holds common code used to
set up U-Boot to run EFI code. Make use of this from the existing
bootefi_test_prepare() function, as well as do_bootefi_exec().

Also shorten a few variable names.

Signed-off-by: Simon Glass 
---

Changes in v7: None
Changes in v6: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
- Introduce load_options_path to specifyc U-Boot env var for load_options_path

Changes in v4:
- Rebase to master

Changes in v3:
- Add patch to create a function to set up for running EFI code

Changes in v2: None

 cmd/bootefi.c | 79 ---
 1 file changed, 43 insertions(+), 36 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ac80074bc4..b9eb04531b 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -253,6 +253,26 @@ static efi_status_t efi_install_fdt(void *fdt)
return ret;
 }
 
+static efi_status_t bootefi_run_prepare(struct efi_loaded_image *image,
+   struct efi_object *obj,
+   const char *load_options_path,
+   struct efi_device_path *device_path,
+   struct efi_device_path *image_path)
+{
+   efi_setup_loaded_image(image, obj, device_path, image_path);
+
+   /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+   efi_save_gd();
+
+   /* Transfer environment variable as load options */
+   set_load_options(image, load_options_path);
+
+   return 0;
+}
+
 /*
  * Load an EFI payload into a newly allocated piece of memory, register all
  * EFI objects it would want to access and jump to it.
@@ -261,8 +281,8 @@ static efi_status_t do_bootefi_exec(void *efi,
struct efi_device_path *device_path,
struct efi_device_path *image_path)
 {
-   struct efi_loaded_image loaded_image_info = {};
-   struct efi_object loaded_image_info_obj = {};
+   struct efi_loaded_image image;
+   struct efi_object obj;
struct efi_device_path *memdp = NULL;
efi_status_t ret;
 
@@ -283,19 +303,13 @@ static efi_status_t do_bootefi_exec(void *efi,
assert(device_path && image_path);
}
 
-   efi_setup_loaded_image(&loaded_image_info, &loaded_image_info_obj,
-  device_path, image_path);
+   ret = bootefi_run_prepare(&image, &obj, "bootargs", device_path,
+ image_path);
+   if (ret)
+   return ret;
 
-   /*
-* gd lives in a fixed register which may get clobbered while we execute
-* the payload. So save it here and restore it on every callback entry
-*/
-   efi_save_gd();
-
-   /* Transfer environment variable bootargs as load options */
-   set_load_options(&loaded_image_info, "bootargs");
/* Load the EFI payload */
-   entry = efi_load_pe(efi, &loaded_image_info);
+   entry = efi_load_pe(efi, &image);
if (!entry) {
ret = EFI_LOAD_ERROR;
goto exit;
@@ -303,10 +317,10 @@ static efi_status_t do_bootefi_exec(void *efi,
 
if (memdp) {
struct efi_device_path_memory *mdp = (void *)memdp;
-   mdp->memory_type = loaded_image_info.image_code_type;
-   mdp->start_address = (uintptr_t)loaded_image_info.image_base;
+   mdp->memory_type = image.image_code_type;
+   mdp->start_address = (uintptr_t)image.image_base;
mdp->end_address = mdp->start_address +
-   loaded_image_info.image_size;
+   image.image_size;
}
 
/* we don't support much: */
@@ -316,8 +330,8 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
 
-   if (setjmp(&loaded_image_info.exit_jmp)) {
-   ret = loaded_image_info.exit_status;
+   if (setjmp(&image.exit_jmp)) {
+   ret = image.exit_status;
goto exit;
}
 
@@ -329,7 +343,7 @@ static efi_status_t do_bootefi_exec(void *efi,
 
/* Move into EL2 and keep running there */
armv8_switch_to_el2((ulong)entry,
-   (ulong)&loaded_image_info_obj.handle,
+   (ulong)&obj.handle,
(ulong)&systab, 0, (ulong)efi_run_in_el2,
ES_TO_AARCH64);
 
@@ -338,11 +352,11 @@ static efi_status_t do_bootefi_exec(void *efi,
}
 #endif
 
-   ret = efi_do_enter(loaded_image_info_obj.handle, &systab, entry);
+   ret = efi_do_enter(ob