[U-Boot] [RFC ATF] Add SMCCC_RENESAS_MEMCONF SMC call

[Ulrich Hecht]

Returns the memory configuration for Renesas R8A7795 (R-Car H3) SoCs,
revision 3.0 and up.

Signed-off-by: Ulrich Hecht 
---
See "[RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer"
for an explanation of this.

CU
Uli


 include/services/arm_arch_svc.h|  1 +
 services/arm_arch_svc/arm_arch_svc_setup.c | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/include/services/arm_arch_svc.h b/include/services/arm_arch_svc.h
index 2961601..9132336 100644
--- a/include/services/arm_arch_svc.h
+++ b/include/services/arm_arch_svc.h
@@ -10,5 +10,6 @@
 #define SMCCC_VERSION  U(0x8000)
 #define SMCCC_ARCH_FEATURESU(0x8001)
 #define SMCCC_ARCH_WORKAROUND_1U(0x80008000)
+#define SMCCC_RENESAS_MEMCONF  U(0x8200)
 
 #endif /* __ARM_ARCH_SVC_H__ */
diff --git a/services/arm_arch_svc/arm_arch_svc_setup.c 
b/services/arm_arch_svc/arm_arch_svc_setup.c
index eedac86..f836ae8 100644
--- a/services/arm_arch_svc/arm_arch_svc_setup.c
+++ b/services/arm_arch_svc/arm_arch_svc_setup.c
@@ -56,6 +56,20 @@ uintptr_t arm_arch_svc_smc_handler(uint32_t smc_fid,
 */
SMC_RET0(handle);
 #endif
+   case SMCCC_RENESAS_MEMCONF:
+#if (RCAR_DRAM_LPDDR4_MEMCONF == 0)
+   /* 4GB(1GBx4) */
+   SMC_RET1(handle, 1);
+#elif (RCAR_DRAM_LPDDR4_MEMCONF == 1) && (RCAR_DRAM_CHANNEL == 5) && \
+   (RCAR_DRAM_SPLIT == 2)
+   /* 4GB(2GBx2 2ch split) */
+   SMC_RET1(handle, 2);
+#elif (RCAR_DRAM_LPDDR4_MEMCONF == 1) && (RCAR_DRAM_CHANNEL == 15)
+   /* 8GB(2GBx4: default) */
+   SMC_RET1(handle, 3);
+#else
+   SMC_RET1(handle, 0);
+#endif /* RCAR_DRAM_LPDDR4_MEMCONF == 0 */
default:
WARN("Unimplemented Arm Architecture Service Call: 0x%x \n",
smc_fid);
-- 
2.7.4

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

Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Laurent Pinchart]

Hi Marek,

On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> On 06/15/2018 01:43 PM, Marek Vasut wrote:
> > On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> >> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut  
wrote:
>  + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>  +   0, 0, 0, 0, 0, 0, 0, );
> >>> 
> >>> Will this call work on platforms without patched ATF ?
> >>> (I think not, don't you need to handle return value?)
> >> 
> >> I have not actually tested that, but if I understand the ATF code
> >> correctly, unimplemented calls return
> >> SMC_UNK (0x), which should be handled by the default case (NOP)
> >> below.> 
> > Which means the board has a memory size of 0 and fails to boot ?
> > 
>  + switch (res.a0) {
>  + case 1:
>  + base[0] = 0x04800ULL;
>  + size[0] = 0x03800ULL;
>  + base[1] = 0x5ULL;
>  + size[1] = 0x04000ULL;
>  + base[2] = 0x6ULL;
>  + size[2] = 0x04000ULL;
>  + base[3] = 0x7ULL;
>  + size[3] = 0x04000ULL;
>  + fdt_fixup_memory_banks(blob, base, size, 4);
>  + break;
>  + case 2:
>  + base[0] = 0x04800ULL;
>  + size[0] = 0x07800ULL;
>  + base[1] = 0x5ULL;
>  + size[1] = 0x08000ULL;
>  + fdt_fixup_memory_banks(blob, base, size, 2);
>  + break;
>  + case 3:
>  + base[0] = 0x04800ULL;
>  + size[0] = 0x07800ULL;
>  + base[1] = 0x5ULL;
>  + size[1] = 0x08000ULL;
>  + base[2] = 0x6ULL;
>  + size[2] = 0x08000ULL;
>  + base[3] = 0x7ULL;
>  + size[3] = 0x08000ULL;
>  + fdt_fixup_memory_banks(blob, base, size, 4);
>  + break;
> >>> 
> >>> Obvious design question is -- since you're adding new SMC call anyway,
> >>> can't the call just return the memory layout table itself, so that it
> >>> won't be duplicated both in U-Boot and ATF ?
> >> 
> >> My gut feeling was to go with the smallest interface possible.
> > 
> > But this doesn't scale. The API here uses some ad-hoc constants to
> > identify memory layout tables which have to be encoded both in ATF and
> > U-Boot, both of which must be kept in sync.
> > 
> > The ATF already has those memory layout tables, it's only a matter of
> > passing them to U-Boot. If you do just that, the ad-hoc constants and
> > encoding of tables into U-Boot goes away and in fact simplifies the
> > design.
> > 
> > Yet, I have to wonder if ATF doesn't already contain some sort of
> > standard SMC call to get memory topology. It surprises me that it
> > wouldn't.
> 
> In fact, Laurent (CCed) was solving some similar issue with lossy decomp
> and I think this involved some passing of memory layout information from
> ATF to U-Boot too, or am I mistaken ?

That's correct, ATF stores information about the memory layout at a fixed 
address in system memory, and U-Boot can read it.

-- 
Regards,

Laurent Pinchart



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

[U-Boot] u-boot 2016.012 hangs periodically during ping/tftp

[Matthew Dahl]

Hello,
I am working on a custom board, that is based on the NXP T2080 processor.

We have been experiencing issues with our loading process which utilizes tftp 
to retrieve images for loading into NAND.
The vast majority of the attempts result in "Loading: *" or "Loading: #" with 
no further output, and u-boot does not respond to ctrl-c and appears to have 
hung someplace.

Using Wireshark I can confirm the following packet transfers are taking place:

ARP request for our external machine
ARP reply from external machine to u-boot with correct MAC 
address

TFTP read request from u-boot to external machine
TFTP Option ACK from external machine to u-boot
TFTP ACK block 0 (OACK) from u-boot to external
TFTP data packet 1 from external machine to u-boot
(and then the further retries of packet 1)

Thanks,
Matt

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

Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Ulrich Hecht]

On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut  wrote:
>> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>> +   0, 0, 0, 0, 0, 0, 0, );
>
> Will this call work on platforms without patched ATF ?
> (I think not, don't you need to handle return value?)

I have not actually tested that, but if I understand the ATF code
correctly, unimplemented calls return
SMC_UNK (0x), which should be handled by the default case (NOP) below.

>
>> + switch (res.a0) {
>> + case 1:
>> + base[0] = 0x04800ULL;
>> + size[0] = 0x03800ULL;
>> + base[1] = 0x5ULL;
>> + size[1] = 0x04000ULL;
>> + base[2] = 0x6ULL;
>> + size[2] = 0x04000ULL;
>> + base[3] = 0x7ULL;
>> + size[3] = 0x04000ULL;
>> + fdt_fixup_memory_banks(blob, base, size, 4);
>> + break;
>> + case 2:
>> + base[0] = 0x04800ULL;
>> + size[0] = 0x07800ULL;
>> + base[1] = 0x5ULL;
>> + size[1] = 0x08000ULL;
>> + fdt_fixup_memory_banks(blob, base, size, 2);
>> + break;
>> + case 3:
>> + base[0] = 0x04800ULL;
>> + size[0] = 0x07800ULL;
>> + base[1] = 0x5ULL;
>> + size[1] = 0x08000ULL;
>> + base[2] = 0x6ULL;
>> + size[2] = 0x08000ULL;
>> + base[3] = 0x7ULL;
>> + size[3] = 0x08000ULL;
>> + fdt_fixup_memory_banks(blob, base, size, 4);
>> + break;
>
> Obvious design question is -- since you're adding new SMC call anyway,
> can't the call just return the memory layout table itself, so that it
> won't be duplicated both in U-Boot and ATF ?

My gut feeling was to go with the smallest interface possible.

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

[U-Boot] tpm TIS TPMv2.0

[Hecht, Martin (Avnet Silica)]

Hi Miquel, Simon,

Is there any specific reason why the new tpm2_tis_spi_xfer doesn't support full 
duplex? It seems we did some work in parallel but you sent the patches earlier. 
Is that codes tested against an existing TPM v2? I have a working 
implementation what runs on SLB9670 including full duplex.
Regards,
Martin


Dipl. Inform. Martin Hecht


Senior Embedded Specialist /
Functional Safety Engineer
TA1130871952

Avnet SILICA



[http://digital.avnet.com/signature/images/silica/Avnet_silica_logo.png]



Englische Straße 27

10587 Berlin

martin.he...@avnet.eu
O +49 (0) 30 214 88 227

M +49 (0) 172 890 60 19

avnet-silica.com


[cid:image002.png@01D404BE.4B5BC5F0]

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

[U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Ulrich Hecht]

Uses an SMC call to the ATF to determine the memory configuration, then
creates appropriate DT memory nodes.

Signed-off-by: Ulrich Hecht 
---
This is an attempt to avoid having to have a ton of different device trees
for Renesas R8A7795 H3 SoCs from revision 3.0, which come in a number of
different memory configurations.

The specific configuration is statically baked into the ARM Trusted Firmware
binary, so this solution adds an SMC "SiP Service Call" to the ATF returning
the memory configuration, and then has u-boot build appropriate memory nodes.

This has not been tested in the flesh successfully, as I only have a revision
1.0 board. I'd like to get some feedback on whether this approach is sound,
though. Thanks.

Depends on "[RFC ATF] Add SMCCC_RENESAS_MEMCONF SMC call".

CU
Uli



 board/renesas/salvator-x/salvator-x.c | 51 +++
 configs/r8a7795_salvator-x_defconfig  |  2 ++
 2 files changed, 53 insertions(+)

diff --git a/board/renesas/salvator-x/salvator-x.c 
b/board/renesas/salvator-x/salvator-x.c
index 651877c..307cb64 100644
--- a/board/renesas/salvator-x/salvator-x.c
+++ b/board/renesas/salvator-x/salvator-x.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -136,3 +137,53 @@ void reset_cpu(ulong addr)
writel(RST_CODE, RST_CA57RESCNT);
 #endif
 }
+
+#define ARM_SMCCC_RENESAS_MEMCONF  0x8200UL
+int ft_board_setup(void *blob, bd_t *bd)
+{
+   if (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795 &&
+   rmobile_get_cpu_rev_integer() >= 3) {
+   u64 base[CONFIG_NR_DRAM_BANKS];
+   u64 size[CONFIG_NR_DRAM_BANKS];
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
+ 0, 0, 0, 0, 0, 0, 0, );
+
+   switch (res.a0) {
+   case 1:
+   base[0] = 0x04800ULL;
+   size[0] = 0x03800ULL;
+   base[1] = 0x5ULL;
+   size[1] = 0x04000ULL;
+   base[2] = 0x6ULL;
+   size[2] = 0x04000ULL;
+   base[3] = 0x7ULL;
+   size[3] = 0x04000ULL;
+   fdt_fixup_memory_banks(blob, base, size, 4);
+   break;
+   case 2:
+   base[0] = 0x04800ULL;
+   size[0] = 0x07800ULL;
+   base[1] = 0x5ULL;
+   size[1] = 0x08000ULL;
+   fdt_fixup_memory_banks(blob, base, size, 2);
+   break;
+   case 3:
+   base[0] = 0x04800ULL;
+   size[0] = 0x07800ULL;
+   base[1] = 0x5ULL;
+   size[1] = 0x08000ULL;
+   base[2] = 0x6ULL;
+   size[2] = 0x08000ULL;
+   base[3] = 0x7ULL;
+   size[3] = 0x08000ULL;
+   fdt_fixup_memory_banks(blob, base, size, 4);
+   break;
+   default:
+   break;
+   }
+   }
+
+   return 0;
+}
diff --git a/configs/r8a7795_salvator-x_defconfig 
b/configs/r8a7795_salvator-x_defconfig
index fdfa41c..cd2bb59 100644
--- a/configs/r8a7795_salvator-x_defconfig
+++ b/configs/r8a7795_salvator-x_defconfig
@@ -61,3 +61,5 @@ CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SMBIOS_MANUFACTURER=""
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_ARM_SMCCC=y
-- 
2.7.4

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

[U-Boot] U-Boot TFTP protection

[Stefan Johansson]

Hello,
We have been looking at protecting U-Boot from (malicious) TFTP overwrites.
We want to do this after our ARMv7 U-Boot has relocated.

The memory map looks like this (I hope):

---  Top of DRAM
| U-Boot (Protected)
| -- U_Boot_start
| Heap (Protected)
| -- Start_Heap = U_Boot_start - Heap_Size
| Stack (Protected)
| -- Start_Stack = Start_Heap - Stack_Size
| Buffers (Protected)
| -- ???
| Free DRAM (Not Protected)
---  Start of DRAM

I seem to get lost in the code trying to find possible buffers, can you please 
give a hint how I can find the address "???"

Best Regards,
Stefan

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

[U-Boot] Issue with fat16 format

[Vipul Kumar]

Hi,

After formatting SD card in fat16 format in windows, we are facing issue. I 
used git bisect and came to know that this issue is due to 
8eafae209c35932d9a6560809c55ee4641534236 commit.

When we use "gparted" utility for formatting SD card in fat16 in linux, it 
works fine.

Please give your comments on this issue and point out what's causing this issue.

Regards,
Vipul Kumar


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull ARC changes

[Tom Rini]

On Fri, Jun 15, 2018 at 01:14:08PM +, Alexey Brodkin wrote:

> Hi Tom,
> 
> The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-14 07:20:41 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-arc.git tags/arc-updates-for-2018.07-rc2
> 
> for you to fetch changes up to 3b4410dde3b82c8a743fa88280b9b0cdd21b1bf3:
> 
>   ARC: HSDK: Add readme (2018-06-15 15:54:43 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [GIT PULL] Xilinx changes for v2018.07-rc2

[Tom Rini]

On Fri, Jun 15, 2018 at 02:53:58PM +0200, Michal Simek wrote:

> Hi Tom,
> 
> please pull these changes to your tree.
> Buildman and travis looks good
> https://travis-ci.org/michalsimek/u-boot/builds/392586380
> 
> Thanks,
> Michal
> 
> The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-14
> 07:20:41 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.07-rc2
> 
> for you to fetch changes up to b729ed0d95415bd694a6b67c0761f03ef5a1e2bc:
> 
>   serial: zynq: Make zynq_serial_setbrg static (2018-06-15 08:54:05 +0200)
> 

Applied to u-boot/master, thanks!




-- 
Tom


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

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

[Tom Rini]

On Thu, Jun 14, 2018 at 07:01:18PM +0200, Alexander Graf wrote:

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

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] ARM: rmobile: Disable 4k SF sectors on V3M Eagle

[Marek Vasut]

The V3M Eagle uses flash with 128 kiB or 256 kiB sectors,
disable the 4k sector support.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 configs/r8a77970_eagle_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig
index f1e2ecaa0e..889fc6e83b 100644
--- a/configs/r8a77970_eagle_defconfig
+++ b/configs/r8a77970_eagle_defconfig
@@ -50,6 +50,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
+# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
-- 
2.17.1

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

[U-Boot] [PATCH 3/4] ARM: rmobile: Fix CPGW address on V3M Eagle

[Marek Vasut]

Fix the CPGWPR/CPGWPCR register address on V3M Eagle to unlock
access to the CPG clock control registers.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 board/renesas/eagle/eagle.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/board/renesas/eagle/eagle.c b/board/renesas/eagle/eagle.c
index 4bf0a202e0..7b89c10cc7 100644
--- a/board/renesas/eagle/eagle.c
+++ b/board/renesas/eagle/eagle.c
@@ -26,8 +26,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define CPGWPR  0xE6150900
 #define CPGWPCR0xE6150904
-#define CPGWPR  0xE615090C
 
 /* PLL */
 #define PLL0CR 0xE61500D8
@@ -54,8 +54,9 @@ void s_init(void)
 
 int board_early_init_f(void)
 {
-   writel(0xA5A5, CPGWPCR);
-   writel(0x5A5A, CPGWPR);
+   /* Unlock CPG access */
+   writel(0xA5A5, CPGWPR);
+   writel(0x5A5A, CPGWPCR);
 
/* TMU0 */
mstp_clrbits_le32(MSTPSR1, SMSTPCR1, TMU0_MSTP125);
-- 
2.17.1

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

[U-Boot] [PATCH 4/4] ARM: rmobile: Enable cache command on V3M Eagle

[Marek Vasut]

Turning the cache off can help when experimenting with bare metal
applications, enable the cache command on V3M Eagle to make that
easier.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 configs/r8a77970_eagle_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig
index 40801651d4..f1e2ecaa0e 100644
--- a/configs/r8a77970_eagle_defconfig
+++ b/configs/r8a77970_eagle_defconfig
@@ -25,6 +25,7 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-- 
2.17.1

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

[U-Boot] [PATCH 2/4] ARM: dts: rmobile: Add AVB PHY reset on V3M Eagle

[Marek Vasut]

Add EtherAVB PHY reset on V3M Eagle to let the AVB driver unreset the PHY.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/r8a77970-eagle.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/r8a77970-eagle.dts b/arch/arm/dts/r8a77970-eagle.dts
index 0c555b8dde..5b8b2f8704 100644
--- a/arch/arm/dts/r8a77970-eagle.dts
+++ b/arch/arm/dts/r8a77970-eagle.dts
@@ -8,6 +8,7 @@
 
 /dts-v1/;
 #include "r8a77970.dtsi"
+#include 
 
 / {
model = "Renesas Eagle board based on r8a77970";
@@ -38,6 +39,7 @@
phy-handle = <>;
phy-mode = "rgmii-id";
status = "okay";
+   reset-gpios = < 16 GPIO_ACTIVE_LOW>;
 
phy0: ethernet-phy@0 {
rxc-skew-ps = <1500>;
-- 
2.17.1

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

[U-Boot] [PATCH 1/4] ARM: dts: rmobile: Add AVB pinmux on V3M Eagle

[Marek Vasut]

Add EtherAVB pinmux node on V3M Eagle to set the pinmux configuration.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/dts/r8a77970-eagle.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/dts/r8a77970-eagle.dts b/arch/arm/dts/r8a77970-eagle.dts
index b75f38581c..0c555b8dde 100644
--- a/arch/arm/dts/r8a77970-eagle.dts
+++ b/arch/arm/dts/r8a77970-eagle.dts
@@ -32,6 +32,8 @@
 };
 
  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
renesas,no-ether-link;
phy-handle = <>;
phy-mode = "rgmii-id";
@@ -69,6 +71,13 @@
 };
 
  {
+   avb0_pins: avb {
+   mux {
+   groups = "avb0_link", "avb0_mdio", "avb0_rgmii", 
"avb0_txcrefclk";
+   function = "avb0";
+   };
+   };
+
i2c0_pins: i2c0 {
groups = "i2c0";
function = "i2c0";
-- 
2.17.1

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

Re: [U-Boot] [PATCH v2] usb: sunxi: access ahb_reset0_cfg in CCM using its offset

[Marek Vasut]

On 06/16/2018 01:45 AM, Vasily Khoruzhick wrote:
> On Wed, Jun 13, 2018 at 11:19 PM, Vasily Khoruzhick  
> wrote:
>> struct sunxi_ccm_reg doesn't have ahb_reset0_cfg on sun4i and sun5i,
>> thus compilation fails with:
>>
>> drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
>> no member named 'ahb_reset0_cfg'
>>
>> Access this reg using its offset to fix this issue.
>>
>> Fixes commit 1ed9c1118 ("usb: sunxi: ehci: get rid of ifdefs")
>> and commit 56830cee3 ("usb: sunxi: ohci: get rid of ifdefs")
>>
>> Signed-off-by: Vasily Khoruzhick 
> 
> Any feedback?

I'll just apply this.

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

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

[Marek Vasut]

The following changes since commit 7868909ed53ed41a945f7ed95ebb88aa252142ce:

  Merge git://git.denx.de/u-boot-fsl-qoriq (2018-06-12 13:25:24 -0400)

are available in the Git repository at:

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

for you to fetch changes up to b9f34757db5dcde9ccfa6ce35705b025bc4843fc:

  usb: sunxi: access ahb_reset0_cfg in CCM using its offset (2018-06-14
12:57:19 +0200)


Vasily Khoruzhick (5):
  sunxi: clock: Fix EHCI and OHCI clocks on A64
  usb: sunxi: ehci: get rid of ifdefs
  usb: sunxi: ohci: get rid of ifdefs
  usb: sunxi: sun50i: enable OHCI0 clock when OHCI1 is in use
  usb: sunxi: access ahb_reset0_cfg in CCM using its offset

 arch/arm/include/asm/arch-sunxi/clock_sun6i.h |   6 --
 drivers/usb/host/ehci-sunxi.c |  98
++
 drivers/usb/host/ohci-sunxi.c | 109
-
 3 files changed, 170 insertions(+), 43 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] usb: sunxi: access ahb_reset0_cfg in CCM using its offset

[Vasily Khoruzhick]

On Wed, Jun 13, 2018 at 11:19 PM, Vasily Khoruzhick  wrote:
> struct sunxi_ccm_reg doesn't have ahb_reset0_cfg on sun4i and sun5i,
> thus compilation fails with:
>
> drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
> no member named 'ahb_reset0_cfg'
>
> Access this reg using its offset to fix this issue.
>
> Fixes commit 1ed9c1118 ("usb: sunxi: ehci: get rid of ifdefs")
> and commit 56830cee3 ("usb: sunxi: ohci: get rid of ifdefs")
>
> Signed-off-by: Vasily Khoruzhick 

Any feedback?

> ---
>  drivers/usb/host/ehci-sunxi.c | 21 ++---
>  drivers/usb/host/ohci-sunxi.c | 22 +++---
>  2 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
> index 35fbe03331..97d06d5975 100644
> --- a/drivers/usb/host/ehci-sunxi.c
> +++ b/drivers/usb/host/ehci-sunxi.c
> @@ -22,14 +22,19 @@
>  #define AHB_CLK_DIST   1
>  #endif
>
> +#define SUN6I_AHB_RESET0_CFG_OFFSET 0x2c0
> +#define SUN9I_AHB_RESET0_CFG_OFFSET 0x5a0
> +
>  struct ehci_sunxi_cfg {
> bool has_reset;
> u32 extra_ahb_gate_mask;
> +   u32 reset0_cfg_offset;
>  };
>
>  struct ehci_sunxi_priv {
> struct ehci_ctrl ehci;
> struct sunxi_ccm_reg *ccm;
> +   u32 *reset0_cfg;
> int ahb_gate_mask; /* Mask of ahb_gate0 clk gate bits for this hcd */
> struct phy phy;
> const struct ehci_sunxi_cfg *cfg;
> @@ -49,6 +54,9 @@ static int ehci_usb_probe(struct udevice *dev)
> if (IS_ERR(priv->ccm))
> return PTR_ERR(priv->ccm);
>
> +   priv->reset0_cfg = (void *)priv->ccm +
> +  priv->cfg->reset0_cfg_offset;
> +
> phys = dev_count_phandle_with_args(dev, "phys", "#phy-cells");
> if (phys < 0) {
> phys = 0;
> @@ -86,7 +94,7 @@ no_phy:
> setbits_le32(>ccm->ahb_gate0,
>  priv->ahb_gate_mask | extra_ahb_gate_mask);
> if (priv->cfg->has_reset)
> -   setbits_le32(>ccm->ahb_reset0_cfg,
> +   setbits_le32(priv->reset0_cfg,
>  priv->ahb_gate_mask | extra_ahb_gate_mask);
>
> hcor = (struct ehci_hcor *)((uintptr_t)hccr +
> @@ -113,7 +121,7 @@ static int ehci_usb_remove(struct udevice *dev)
> return ret;
>
> if (priv->cfg->has_reset)
> -   clrbits_le32(>ccm->ahb_reset0_cfg, priv->ahb_gate_mask);
> +   clrbits_le32(priv->reset0_cfg, priv->ahb_gate_mask);
> clrbits_le32(>ccm->ahb_gate0, priv->ahb_gate_mask);
>
> return 0;
> @@ -125,11 +133,18 @@ static const struct ehci_sunxi_cfg sun4i_a10_cfg = {
>
>  static const struct ehci_sunxi_cfg sun6i_a31_cfg = {
> .has_reset = true,
> +   .reset0_cfg_offset = SUN6I_AHB_RESET0_CFG_OFFSET,
>  };
>
>  static const struct ehci_sunxi_cfg sun8i_h3_cfg = {
> .has_reset = true,
> .extra_ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_OHCI0,
> +   .reset0_cfg_offset = SUN6I_AHB_RESET0_CFG_OFFSET,
> +};
> +
> +static const struct ehci_sunxi_cfg sun9i_a80_cfg = {
> +   .has_reset = true,
> +   .reset0_cfg_offset = SUN9I_AHB_RESET0_CFG_OFFSET,
>  };
>
>  static const struct udevice_id ehci_usb_ids[] = {
> @@ -163,7 +178,7 @@ static const struct udevice_id ehci_usb_ids[] = {
> },
> {
> .compatible = "allwinner,sun9i-a80-ehci",
> -   .data = (ulong)_a31_cfg,
> +   .data = (ulong)_a80_cfg,
> },
> {
> .compatible = "allwinner,sun50i-a64-ehci",
> diff --git a/drivers/usb/host/ohci-sunxi.c b/drivers/usb/host/ohci-sunxi.c
> index 2b99169da6..e13f6ec9a4 100644
> --- a/drivers/usb/host/ohci-sunxi.c
> +++ b/drivers/usb/host/ohci-sunxi.c
> @@ -22,14 +22,19 @@
>  #define AHB_CLK_DIST   1
>  #endif
>
> +#define SUN6I_AHB_RESET0_CFG_OFFSET 0x2c0
> +#define SUN9I_AHB_RESET0_CFG_OFFSET 0x5a0
> +
>  struct ohci_sunxi_cfg {
> bool has_reset;
> u32 extra_ahb_gate_mask;
> u32 extra_usb_gate_mask;
> +   u32 reset0_cfg_offset;
>  };
>
>  struct ohci_sunxi_priv {
> struct sunxi_ccm_reg *ccm;
> +   u32 *reset0_cfg;
> ohci_t ohci;
> int ahb_gate_mask; /* Mask of ahb_gate0 clk gate bits for this hcd */
> int usb_gate_mask; /* Mask of usb_clk_cfg clk gate bits for this hcd 
> */
> @@ -50,6 +55,9 @@ static int ohci_usb_probe(struct udevice *dev)
> if (IS_ERR(priv->ccm))
> return PTR_ERR(priv->ccm);
>
> +   priv->reset0_cfg = (void *)priv->ccm +
> +  priv->cfg->reset0_cfg_offset;
> +
> phys = dev_count_phandle_with_args(dev, "phys", "#phy-cells");
> if (phys < 0) {
> phys = 0;
> @@ -93,7 +101,7 @@ no_phy:
> setbits_le32(>ccm->usb_clk_cfg,
>  priv->usb_gate_mask | priv->cfg->extra_usb_gate_mask);
> if (priv->cfg->has_reset)
> -   

Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Marek Vasut]

On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> Hi Marek,
> 
> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
>> On 06/15/2018 01:43 PM, Marek Vasut wrote:
>>> On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
 On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut  
> wrote:
>> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>> +   0, 0, 0, 0, 0, 0, 0, );
>
> Will this call work on platforms without patched ATF ?
> (I think not, don't you need to handle return value?)

 I have not actually tested that, but if I understand the ATF code
 correctly, unimplemented calls return
 SMC_UNK (0x), which should be handled by the default case (NOP)
 below.> 
>>> Which means the board has a memory size of 0 and fails to boot ?
>>>
>> + switch (res.a0) {
>> + case 1:
>> + base[0] = 0x04800ULL;
>> + size[0] = 0x03800ULL;
>> + base[1] = 0x5ULL;
>> + size[1] = 0x04000ULL;
>> + base[2] = 0x6ULL;
>> + size[2] = 0x04000ULL;
>> + base[3] = 0x7ULL;
>> + size[3] = 0x04000ULL;
>> + fdt_fixup_memory_banks(blob, base, size, 4);
>> + break;
>> + case 2:
>> + base[0] = 0x04800ULL;
>> + size[0] = 0x07800ULL;
>> + base[1] = 0x5ULL;
>> + size[1] = 0x08000ULL;
>> + fdt_fixup_memory_banks(blob, base, size, 2);
>> + break;
>> + case 3:
>> + base[0] = 0x04800ULL;
>> + size[0] = 0x07800ULL;
>> + base[1] = 0x5ULL;
>> + size[1] = 0x08000ULL;
>> + base[2] = 0x6ULL;
>> + size[2] = 0x08000ULL;
>> + base[3] = 0x7ULL;
>> + size[3] = 0x08000ULL;
>> + fdt_fixup_memory_banks(blob, base, size, 4);
>> + break;
>
> Obvious design question is -- since you're adding new SMC call anyway,
> can't the call just return the memory layout table itself, so that it
> won't be duplicated both in U-Boot and ATF ?

 My gut feeling was to go with the smallest interface possible.
>>>
>>> But this doesn't scale. The API here uses some ad-hoc constants to
>>> identify memory layout tables which have to be encoded both in ATF and
>>> U-Boot, both of which must be kept in sync.
>>>
>>> The ATF already has those memory layout tables, it's only a matter of
>>> passing them to U-Boot. If you do just that, the ad-hoc constants and
>>> encoding of tables into U-Boot goes away and in fact simplifies the
>>> design.
>>>
>>> Yet, I have to wonder if ATF doesn't already contain some sort of
>>> standard SMC call to get memory topology. It surprises me that it
>>> wouldn't.
>>
>> In fact, Laurent (CCed) was solving some similar issue with lossy decomp
>> and I think this involved some passing of memory layout information from
>> ATF to U-Boot too, or am I mistaken ?
> 
> That's correct, ATF stores information about the memory layout at a fixed 
> address in system memory, and U-Boot can read it.

Well, that sounds good ! Maybe we can avoid adding SMC call altogether
then? :)

-- 
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 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Fri, 15 Jun 2018 22:35:58 +0200
> 
> On 06/14/2018 10:50 PM, Mark Kettenis wrote:
> >> From: Heinrich Schuchardt 
> >> 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.  
> > 
> 
> Just for reference run the Banana Pi with only patch 3 (w/o patch 1 and
> 2) and you will see adequate speed in iPXE. And if you specify
> 
>setenv bootargs nosmp
> 
> you will be able to boot Linux via GRUB from your iSCSI drive. So this
> is not a deficiency of the board.

The update series I just posted makes things fast again. So far I
haven't been able to build an iPXE EFI binary so that remains
untested.  Would be great if you could do that for me.

But even if iPXE still doesn't work, I'd argue that efi_loader support
for armv7 that works in the most common case of booting an OS using an
EFI bootloader is better than having no efi_loader support at all...

Cheers,

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

[U-Boot] [PATCH v4 0/5] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Mark Kettenis]

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.

The third version avoids saving r3 on the stack and fixes an include
guard as suggested by Alexander Graf.

This fourth version enables ARMV7_LPAE if HYP mode is supported sych
that we enable the MMU and caches in HYP mode.  It also makes sure we
don't attempt to enter non-secure mode twice if we execute a 2nd EFI
payload.

Mark Kettenis (5):
  ARM: HYP/non-sec: migrate stack
  efi_loader: ARM: run EFI payloads non-secure
  efi_loader: ARM: don't attempt to enter non-secure mode twice
  ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supported
  Revert "efi_loader: no support for ARMV7_NONSEC=y"

 arch/arm/cpu/armv7/Kconfig   |  2 +-
 arch/arm/cpu/armv7/nonsec_virt.S |  2 ++
 cmd/bootefi.c| 36 
 doc/README.uefi  |  2 --
 lib/efi_loader/Kconfig   |  2 --
 5 files changed, 39 insertions(+), 5 deletions(-)

-- 
2.16.2

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

[U-Boot] [PATCH v4 5/5] Revert "efi_loader: no support for ARMV7_NONSEC=y"

[Mark Kettenis]

This reverts commit c524997acb3d322e1bbd36c06ad02ef589705e7c.

Booting ARMv7 in non-secure mode using bootefi works now.

Signed-off-by: Mark Kettenis 
---
 doc/README.uefi| 2 --
 lib/efi_loader/Kconfig | 2 --
 2 files changed, 4 deletions(-)

diff --git a/doc/README.uefi b/doc/README.uefi
index d4031ef8e8..6b9759cfed 100644
--- a/doc/README.uefi
+++ b/doc/README.uefi
@@ -329,8 +329,6 @@ This driver is only available if U-Boot is configured with
   * persistence
   * runtime support
 
-* support bootefi booting ARMv7 in non-secure mode (CONFIG_ARMV7_NONSEC=y)
-
 ## Links
 
 * [1](http://uefi.org/specifications)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index df58e633d1..ce6a09f0b4 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,8 +1,6 @@
 config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
depends on (ARM || X86 || RISCV) && 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
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
-- 
2.16.2

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

[U-Boot] [PATCH v4 4/5] ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supported

[Mark Kettenis]

ARMV7_LPAE is required in order to enable the MMU in HYP mode.
And we really want to enable the MMU in HYP mode such that we can
enable the the caches.  Otherwise U-Boot code (such as the EFI
implementation) that runs in HYP mode will run at a snils pace.

Signed-off-by: Mark Kettenis 
---
 arch/arm/cpu/armv7/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 37a0be932e..73d57a2aae 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -53,7 +53,7 @@ config ARMV7_PSCI_NR_CPUS
 config ARMV7_LPAE
bool "Use LPAE page table format" if EXPERT
depends on CPU_V7A
-   default n
+   default y if ARMV7_VIRT
---help---
Say Y here to use the long descriptor page table format. This is
required if U-Boot runs in HYP mode.
-- 
2.16.2

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

[U-Boot] [PATCH v4 2/5] efi_loader: ARM: run EFI payloads non-secure

[Mark Kettenis]

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 */
+
+   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));
+
+   /* Should never reach here, efi exits with longjmp */
+   while (1) { }
+   }
+#endif
+
ret = efi_do_enter(loaded_image_info_obj.handle, , entry);
 
 exit:
-- 
2.16.2

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

[U-Boot] [PATCH v4 3/5] efi_loader: ARM: don't attempt to enter non-secure mode twice

[Mark Kettenis]

Multiple EFI binaries may be executed in sequence.  So if we already
are in non-secure mode after running the first one we should skip
the switching code since it no longer works once we're non-secure.

Signed-off-by: Mark Kettenis 
---
 cmd/bootefi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 12a6b84ce6..12081cee46 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -195,6 +195,8 @@ static efi_status_t efi_run_in_el2(EFIAPI efi_status_t 
(*entry)(
 #endif
 
 #ifdef CONFIG_ARMV7_NONSEC
+static bool is_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)
@@ -202,6 +204,8 @@ static efi_status_t efi_run_in_hyp(EFIAPI efi_status_t 
(*entry)(
/* Enable caches again */
dcache_enable();
 
+   is_nonsec = true;
+
return efi_do_enter(image_handle, st, entry);
 }
 #endif
@@ -356,7 +360,7 @@ static efi_status_t do_bootefi_exec(void *efi,
 #endif
 
 #ifdef CONFIG_ARMV7_NONSEC
-   if (armv7_boot_nonsec()) {
+   if (armv7_boot_nonsec() && !is_nonsec) {
dcache_disable();   /* flush cache before switch to HYP */
 
armv7_init_nonsec();
-- 
2.16.2

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

[U-Boot] [PATCH v4 1/5] ARM: HYP/non-sec: migrate stack

[Mark Kettenis]

The current code that switches into HYP mode doesn't bother to set
up a stack for HYP mode.  This doesn't work for EFI applications
as they expect a usable stack.  Fix this by migrating the stack
pointer from SP_svc to SP_hyp while in Monitor mode.
This restores the stack pointer when we drop into HYP mode.

Signed-off-by: Mark Kettenis 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 56bdba1d38..1773fae205 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -80,6 +80,8 @@ _secure_monitor:
 #ifdef CONFIG_ARMV7_VIRT
orreq   r5, r5, #0x100  @ allow HVC instruction
moveq   r6, #HYP_MODE   @ Enter the kernel as HYP
+   mrseq   r3, sp_svc
+   msreq   sp_hyp, r3  @ migrate SP
 #endif
 
mcr p15, 0, r5, c1, c1, 0   @ write SCR (with NS bit set)
-- 
2.16.2

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

[U-Boot] [PATCH] configs: Lower Lamobo R1 DRAM clock rate to 384 MHz

[Paul Kocialkowski]

When running at 432 MHz, the Lamobo R1 DRAM tends to get corrupted under
stressing workloads. Reducing the clock rate to 384 MHz results in
significantly-improved stability.

One reliable way to trigger a corruption at 432 MHz is to run
I/O-intensive operations on an attached SATA disk. The same operations
when operating the DRAM at 384 MHz typically go fine.

For some unexplained reason, running at 408 MHz worsens the situation.

Signed-off-by: Paul Kocialkowski 
---
 configs/Lamobo_R1_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 92e682128c..cf60fdfaf4 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SYS_TEXT_BASE=0x4a00
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=432
+CONFIG_DRAM_CLK=384
 CONFIG_MACPWR="PH23"
 CONFIG_MMC0_CD_PIN="PH10"
 CONFIG_SATAPWR="PB3"
-- 
2.17.1

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

Re: [U-Boot] [PATCH v2 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Alexander Graf]

On 15.06.18 22:36, Joe Hershberger wrote:
> On Fri, Jun 15, 2018 at 3:33 PM, Alexander Graf  wrote:
>>
>>
>> On 15.06.18 22:08, Joe Hershberger wrote:
>>> On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf  wrote:


 On 14.06.18 18:58, Joe Hershberger wrote:
> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf  wrote:
>> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
>> ignore the DHCP provided TFTP ip address. This breaks every case where we
>> do now provide a serverip environment variable.
>>
>> Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall 
>> back
>> to the DHCP provided TFTP IP if no serverip environment variable is set.
>>
>> Signed-off-by: Alexander Graf 
>
> Reviewed-by: Joe Hershberger 
>
>> ---
>>  configs/ax25-ae350_defconfig | 1 +
>>  include/configs/ax25-ae350.h | 1 -
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
>> index fc04c87485..a328555af6 100644
>> --- a/configs/ax25-ae350_defconfig
>> +++ b/configs/ax25-ae350_defconfig
>> @@ -40,3 +40,4 @@ CONFIG_DM_SPI=y
>>  CONFIG_ATCSPI200_SPI=y
>>  CONFIG_TIMER=y
>>  CONFIG_ATCPIT100_TIMER=y
>> +CONFIG_BOOTP_PREFER_SERVERIP=y
>> diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
>> index b1ca5ac11a..b230896734 100644
>> --- a/include/configs/ax25-ae350.h
>> +++ b/include/configs/ax25-ae350.h
>> @@ -11,7 +11,6 @@
>>   * CPU and Board Configuration Options
>>   */
>>  #define CONFIG_BOOTP_SEND_HOSTNAME
>> -#define CONFIG_BOOTP_SERVERIP
>
> Feel like moving this to Kconfig?

 I would actually prefer to remove it altogether ;)
>>>
>>> I'm with you, actually... though I think the behavior should be to
>>> always ignore the DHCP server's settings when they are on the command
>>> line or in the environment. If you want the DHCP server's info, the
>>> user's script can remove the variables explicitly.
>>
>> Yeah, the only case I can think of where the current model could hurt us
>> is if you run "dhcp" and then call "saveenv". Because that saveenv will
>> contain all those glorious variables that may now override the next dhcp
>> request.
> 
> I think in that case you could explicitly clean up those variables...
> I've intended to implement ephemeral variables anyway... this is one
> of the reasons.

I'll be happy to pass this one on to you then :). I am already too deep
down into rabbit holes.

>> Btw, you wouldn't happen to work with Julia? ;)
> 
> Not directly, but yes. :)

Awesome, just met her last weekend ;)


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

Re: [U-Boot] [PATCH v2 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Joe Hershberger]

On Fri, Jun 15, 2018 at 3:33 PM, Alexander Graf  wrote:
>
>
> On 15.06.18 22:08, Joe Hershberger wrote:
>> On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf  wrote:
>>>
>>>
>>> On 14.06.18 18:58, Joe Hershberger wrote:
 On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf  wrote:
> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
> ignore the DHCP provided TFTP ip address. This breaks every case where we
> do now provide a serverip environment variable.
>
> Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
> to the DHCP provided TFTP IP if no serverip environment variable is set.
>
> Signed-off-by: Alexander Graf 

 Reviewed-by: Joe Hershberger 

> ---
>  configs/ax25-ae350_defconfig | 1 +
>  include/configs/ax25-ae350.h | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
> index fc04c87485..a328555af6 100644
> --- a/configs/ax25-ae350_defconfig
> +++ b/configs/ax25-ae350_defconfig
> @@ -40,3 +40,4 @@ CONFIG_DM_SPI=y
>  CONFIG_ATCSPI200_SPI=y
>  CONFIG_TIMER=y
>  CONFIG_ATCPIT100_TIMER=y
> +CONFIG_BOOTP_PREFER_SERVERIP=y
> diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
> index b1ca5ac11a..b230896734 100644
> --- a/include/configs/ax25-ae350.h
> +++ b/include/configs/ax25-ae350.h
> @@ -11,7 +11,6 @@
>   * CPU and Board Configuration Options
>   */
>  #define CONFIG_BOOTP_SEND_HOSTNAME
> -#define CONFIG_BOOTP_SERVERIP

 Feel like moving this to Kconfig?
>>>
>>> I would actually prefer to remove it altogether ;)
>>
>> I'm with you, actually... though I think the behavior should be to
>> always ignore the DHCP server's settings when they are on the command
>> line or in the environment. If you want the DHCP server's info, the
>> user's script can remove the variables explicitly.
>
> Yeah, the only case I can think of where the current model could hurt us
> is if you run "dhcp" and then call "saveenv". Because that saveenv will
> contain all those glorious variables that may now override the next dhcp
> request.

I think in that case you could explicitly clean up those variables...
I've intended to implement ephemeral variables anyway... this is one
of the reasons.

> Btw, you wouldn't happen to work with Julia? ;)

Not directly, but yes. :)

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

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

Just for reference run the Banana Pi with only patch 3 (w/o patch 1 and
2) and you will see adequate speed in iPXE. And if you specify

   setenv bootargs nosmp

you will be able to boot Linux via GRUB from your iSCSI drive. So this
is not a deficiency of the board.

Regards

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

Re: [U-Boot] [PATCH v2 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Alexander Graf]

On 15.06.18 22:08, Joe Hershberger wrote:
> On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf  wrote:
>>
>>
>> On 14.06.18 18:58, Joe Hershberger wrote:
>>> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf  wrote:
 The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
 ignore the DHCP provided TFTP ip address. This breaks every case where we
 do now provide a serverip environment variable.

 Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
 to the DHCP provided TFTP IP if no serverip environment variable is set.

 Signed-off-by: Alexander Graf 
>>>
>>> Reviewed-by: Joe Hershberger 
>>>
 ---
  configs/ax25-ae350_defconfig | 1 +
  include/configs/ax25-ae350.h | 1 -
  2 files changed, 1 insertion(+), 1 deletion(-)

 diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
 index fc04c87485..a328555af6 100644
 --- a/configs/ax25-ae350_defconfig
 +++ b/configs/ax25-ae350_defconfig
 @@ -40,3 +40,4 @@ CONFIG_DM_SPI=y
  CONFIG_ATCSPI200_SPI=y
  CONFIG_TIMER=y
  CONFIG_ATCPIT100_TIMER=y
 +CONFIG_BOOTP_PREFER_SERVERIP=y
 diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
 index b1ca5ac11a..b230896734 100644
 --- a/include/configs/ax25-ae350.h
 +++ b/include/configs/ax25-ae350.h
 @@ -11,7 +11,6 @@
   * CPU and Board Configuration Options
   */
  #define CONFIG_BOOTP_SEND_HOSTNAME
 -#define CONFIG_BOOTP_SERVERIP
>>>
>>> Feel like moving this to Kconfig?
>>
>> I would actually prefer to remove it altogether ;)
> 
> I'm with you, actually... though I think the behavior should be to
> always ignore the DHCP server's settings when they are on the command
> line or in the environment. If you want the DHCP server's info, the
> user's script can remove the variables explicitly.

Yeah, the only case I can think of where the current model could hurt us
is if you run "dhcp" and then call "saveenv". Because that saveenv will
contain all those glorious variables that may now override the next dhcp
request.

Btw, you wouldn't happen to work with Julia? ;)

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

Re: [U-Boot] [PATCH v3 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Joe Hershberger]

On Fri, Jun 15, 2018 at 3:29 AM, Alexander Graf  wrote:
> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
> ignore the DHCP provided TFTP ip address. This breaks every case where we
> do now provide a serverip environment variable.
>
> Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
> to the DHCP provided TFTP IP if no serverip environment variable is set.
>
> 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

Re: [U-Boot] [PATCH v3 1/3] net: Prefer command line arguments

[Joe Hershberger]

On Fri, Jun 15, 2018 at 3:29 AM, Alexander Graf  wrote:
> We can call commands like dhcp and bootp without arguments or with
> explicit command line arguments that really should tell the code where
> to look for files instead.
>
> Unfortunately, the current code simply overwrites command line arguments
> in the dhcp case with dhcp values.
>
> This patch allows the code to preserve the command line values if they
> were set on the command line. That way the semantics are slightly more
> intuitive.
>
> The reason this patch does that by introducing a new variable is that we
> can not rely on net_boot_file_name[0] being unset, as today it's
> completely legal to call "dhcp" and afterwards run "tftp" and expect the
> latter to repeat the same query as before. I would prefer not to break
> that behavior in case anyone relies on it.
>
> 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

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

[Joe Hershberger]

On Fri, Jun 15, 2018 at 3:29 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

Re: [U-Boot] [PATCH v2 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Joe Hershberger]

On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf  wrote:
>
>
> On 14.06.18 18:58, Joe Hershberger wrote:
>> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf  wrote:
>>> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
>>> ignore the DHCP provided TFTP ip address. This breaks every case where we
>>> do now provide a serverip environment variable.
>>>
>>> Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
>>> to the DHCP provided TFTP IP if no serverip environment variable is set.
>>>
>>> Signed-off-by: Alexander Graf 
>>
>> Reviewed-by: Joe Hershberger 
>>
>>> ---
>>>  configs/ax25-ae350_defconfig | 1 +
>>>  include/configs/ax25-ae350.h | 1 -
>>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
>>> index fc04c87485..a328555af6 100644
>>> --- a/configs/ax25-ae350_defconfig
>>> +++ b/configs/ax25-ae350_defconfig
>>> @@ -40,3 +40,4 @@ CONFIG_DM_SPI=y
>>>  CONFIG_ATCSPI200_SPI=y
>>>  CONFIG_TIMER=y
>>>  CONFIG_ATCPIT100_TIMER=y
>>> +CONFIG_BOOTP_PREFER_SERVERIP=y
>>> diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
>>> index b1ca5ac11a..b230896734 100644
>>> --- a/include/configs/ax25-ae350.h
>>> +++ b/include/configs/ax25-ae350.h
>>> @@ -11,7 +11,6 @@
>>>   * CPU and Board Configuration Options
>>>   */
>>>  #define CONFIG_BOOTP_SEND_HOSTNAME
>>> -#define CONFIG_BOOTP_SERVERIP
>>
>> Feel like moving this to Kconfig?
>
> I would actually prefer to remove it altogether ;)

I'm with you, actually... though I think the behavior should be to
always ignore the DHCP server's settings when they are on the command
line or in the environment. If you want the DHCP server's info, the
user's script can remove the variables explicitly.

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

[U-Boot] [PATCH v2 1/1] Sandbox: provide default dtb

[Heinrich Schuchardt]

Provide sandbox.dtb as default device tree for sandbox_defconfig.

We can use the dtb with

./u-boot -d u-boot.dtb

Signed-off-by: Heinrich Schuchardt 
---
v2
adjust commit message
---
 configs/sandbox_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 2fc84a16c9..3bdb97b7d3 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -19,6 +19,7 @@ CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_PRE_CON_BUF_ADDR=0x10
 CONFIG_LOG_MAX_LEVEL=6
 CONFIG_LOG_ERROR_RETURN=y
+CONFIG_DEFAULT_FDT_FILE="sandbox.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
-- 
2.17.1

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

[U-Boot] [PATCH 1/1] Sandbox: provide default config

[Heinrich Schuchardt]

Provide sandbox.dtb as default device tree for sandbox_defconfig.

We can use the dtb with

./u-boot -d u-boot.dtb

Signed-off-by: Heinrich Schuchardt 
---
 configs/sandbox_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 2fc84a16c9..3bdb97b7d3 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -19,6 +19,7 @@ CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_PRE_CON_BUF_ADDR=0x10
 CONFIG_LOG_MAX_LEVEL=6
 CONFIG_LOG_ERROR_RETURN=y
+CONFIG_DEFAULT_FDT_FILE="sandbox.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH v4 05/16] sandbox: Add a setjmp() implementation

[Alexander Graf]

> Am 15.06.2018 um 17:16 schrieb Simon Glass :
> 
> Hi Alex,
> 
>> On 15 June 2018 at 06:01, Alexander Graf  wrote:
>> 
>> 
>>> On 16.05.18 17:42, Simon Glass wrote:
>>> Add an implementation of setjmp() and longjmp() which rely on the
>>> underlying host C library. Since we cannot know how large the jump buffer
>>> needs to be, pick something that should be suitable and check it at
>>> runtime. At present we need access to the underlying struct as well.
>>> 
>>> Signed-off-by: Simon Glass 
>>> ---
>>> 
>>> Changes in v4:
>>> - Fix up the sizeof() operations on jmp_buf
>>> - Update SPDX tags
>>> 
>>> Changes in v3: None
>>> Changes in v2: None
>>> 
>>> arch/sandbox/cpu/cpu.c| 13 +
>>> arch/sandbox/cpu/os.c | 23 +++
>>> arch/sandbox/include/asm/setjmp.h | 30 ++
>>> include/os.h  | 21 +
>>> 4 files changed, 87 insertions(+)
>>> create mode 100644 arch/sandbox/include/asm/setjmp.h
>>> 
>>> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
>>> index d4ad020012e..cde0b055a67 100644
>>> --- a/arch/sandbox/cpu/cpu.c
>>> +++ b/arch/sandbox/cpu/cpu.c
>>> @@ -9,6 +9,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> 
>>> @@ -164,3 +165,15 @@ ulong timer_get_boot_us(void)
>>> 
>>>  return (count - base_count) / 1000;
>>> }
>>> +
>>> +int setjmp(jmp_buf jmp)
>>> +{
>>> + return os_setjmp((ulong *)jmp, sizeof(*jmp));
>> 
>> So, this doesn't work. Function returns increase the stack pointer which
>> means after setjmp() you are not allowed to return until the longjmp
>> occured. The documentation is quite clear about this:
>> 
>> 
>> DESCRIPTION
>>   setjmp() and longjmp(3) are useful for dealing with errors and
>> interrupts encountered in a low-level subroutine of a program.  setjmp()
>> saves the stack context/environment in env for later use by longjmp(3).
>> The stack context will be invalidated if the function which called
>> setjmp() returns.
>> 
>> 
>> So we need to find a way to call setjmp() directly from the code point
>> where we want to call it, rather than jump through helper functions, as
>> these break its functionality.
> 
> That sounds hard but perhaps we can do something with inline
> functions? It's hard because we want to call the C library in the
> sandbox case. Perhaps we should rename the U-Boot version of the
> function.
> 
> I wonder if in my test I just relied on hello world returning, rather
> than calling the exit() function? BTW we need to find a way for
> efi_selftest() to exit cleanly too. At the moment it resets.
> 
>> 
>> Also, os_longjmp() is broken. It calls longjmp() which however is not
>> the system longjmp, but the U-Boot internal one that again calls
>> os_longjmp. My quick fix was to make it call _longjmp() instead - that
>> at least makes that part work.
> 
> But it hangs after that?

It hangs in the return path of setjmp afterwards because of the clobbered 
stack. See my patch in the latest series for reference. With that patch it 
works (might be  glibc only though).

Alex


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

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

[Joe Hershberger]

On Fri, Jun 15, 2018 at 12:06 AM, Alex Kiernan  wrote:
> 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 

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

Re: [U-Boot] make config Error

[Joe Hershberger]

On Fri, Jun 15, 2018 at 10:56 AM,   wrote:
> installed bison++

I just "sudo apt-get install flex bison" and it worked great.

>
> Cloned most recent u-boot 2018.06.14
>
> make clean works
> make menuconfig fails:
> make rpi_3_32b_config fails:
>
> YACCscripts/kconfig/zconf.tab.c
> scripts/kconfig/zconf.y:44 parser name defined to default :"parse"
> "scripts/kconfig/zconf.y", line 97: junk after `%%' in definition
> section Segmentation fault
> scripts/Makefile.lib:228: recipe for target
> 'scripts/kconfig/zconf.tab.c' failed make[1]: ***
> [scripts/kconfig/zconf.tab.c] Error 139
>
>
> This works on the u-boot version from one month ago.
>
> Suggestions welcome.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] x86: Use microcode update from device tree for all processors

[Ivan Gorinov]

Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies
the microcode update data block encoded in Device Tree to the bootstrap
processor but not passed to the other CPUs when multiprocessing is enabled.

If the bootstrap processor successfully performs a microcode update
from Device Tree, use the same data block for the other processors.

Signed-off-by: Ivan Gorinov 
---
 arch/x86/cpu/i386/cpu.c   |  3 ++-
 arch/x86/cpu/intel_common/car.S   |  2 ++
 arch/x86/cpu/intel_common/microcode.c | 10 +++---
 arch/x86/include/asm/microcode.h  |  1 +
 arch/x86/lib/fsp/fsp_car.S|  4 +++-
 5 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index 208ef08..90e3e8b 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -585,7 +586,7 @@ int x86_mp_init(void)
mp_params.parallel_microcode_load = 0,
mp_params.flight_plan = _steps[0];
mp_params.num_records = ARRAY_SIZE(mp_steps);
-   mp_params.microcode_pointer = 0;
+   mp_params.microcode_pointer = (void *)ucode_base;
 
if (mp_init(_params)) {
printf("Warning: MP init failure\n");
diff --git a/arch/x86/cpu/intel_common/car.S b/arch/x86/cpu/intel_common/car.S
index fe8dfbc..52a77bb 100644
--- a/arch/x86/cpu/intel_common/car.S
+++ b/arch/x86/cpu/intel_common/car.S
@@ -239,4 +239,6 @@ _dt_ucode_base_size:
 .globl ucode_base
 ucode_base:/* Declared in microcode.h */
.long   0   /* microcode base */
+.globl ucode_size
+ucode_size:/* Declared in microcode.h */
.long   0   /* microcode size */
diff --git a/arch/x86/cpu/intel_common/microcode.c 
b/arch/x86/cpu/intel_common/microcode.c
index 11b1ec8..c7a539d 100644
--- a/arch/x86/cpu/intel_common/microcode.c
+++ b/arch/x86/cpu/intel_common/microcode.c
@@ -43,8 +43,6 @@ static int microcode_decode_node(const void *blob, int node,
update->data = fdt_getprop(blob, node, "data", >size);
if (!update->data)
return -ENOENT;
-   update->data += UCODE_HEADER_LEN;
-   update->size -= UCODE_HEADER_LEN;
 
update->header_version = fdtdec_get_int(blob, node,
"intel,header-version", 0);
@@ -124,6 +122,7 @@ static void microcode_read_cpu(struct microcode_update *cpu)
 int microcode_update_intel(void)
 {
struct microcode_update cpu, update;
+   ulong address;
const void *blob = gd->fdt_blob;
int skipped;
int count;
@@ -167,7 +166,8 @@ int microcode_update_intel(void)
skipped++;
continue;
}
-   wrmsr(MSR_IA32_UCODE_WRITE, (ulong)update.data, 0);
+   address = (ulong)update.data + UCODE_HEADER_LEN;
+   wrmsr(MSR_IA32_UCODE_WRITE, address, 0);
rev = microcode_read_rev();
debug("microcode: updated to revision 0x%x 
date=%04x-%02x-%02x\n",
  rev, update.date_code & 0x,
@@ -178,5 +178,9 @@ int microcode_update_intel(void)
return -EFAULT;
}
count++;
+   if (!ucode_base) {
+   ucode_base = (ulong)update.data;
+   ucode_size = update.size;
+   }
} while (1);
 }
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index f7b32a5..4ab7504 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -10,6 +10,7 @@
 
 /* This is a declaration for ucode_base in start.S */
 extern u32 ucode_base;
+extern u32 ucode_size;
 
 /**
  * microcode_update_intel() - Apply microcode updates
diff --git a/arch/x86/lib/fsp/fsp_car.S b/arch/x86/lib/fsp/fsp_car.S
index 549d863..48edc83 100644
--- a/arch/x86/lib/fsp/fsp_car.S
+++ b/arch/x86/lib/fsp/fsp_car.S
@@ -102,8 +102,10 @@ temp_ram_init_params:
 _dt_ucode_base_size:
/* These next two fields are filled in by ifdtool */
 .globl ucode_base
-ucode_base:/* Declared in micrcode.h */
+ucode_base:/* Declared in microcode.h */
.long   0   /* microcode base */
+.globl ucode_size
+ucode_size:/* Declared in microcode.h */
.long   0   /* microcode size */
.long   CONFIG_SYS_MONITOR_BASE /* code region base */
.long   CONFIG_SYS_MONITOR_LEN  /* code region size */
-- 
2.7.4

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

[U-Boot] [PATCH v2] x86: Use microcode update from device tree for all processors

[Ivan Gorinov]

Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies
the microcode update data block encoded in Device Tree to the bootstrap
processor but not passed to the other CPUs when multiprocessing is enabled.

If the bootstrap processor successfully performs a microcode update
from Device Tree, use the same data block for the other processors.

v2:
  Corrected the order of included header files

Ivan Gorinov (1):
  x86: Use microcode update from device tree for all processors

 arch/x86/cpu/i386/cpu.c   |  3 ++-
 arch/x86/cpu/intel_common/car.S   |  2 ++
 arch/x86/cpu/intel_common/microcode.c | 10 +++---
 arch/x86/include/asm/microcode.h  |  1 +
 arch/x86/lib/fsp/fsp_car.S|  4 +++-
 5 files changed, 15 insertions(+), 5 deletions(-)

-- 
2.7.4

___
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 Fri, Jun 15, 2018 at 10:40:20AM -0500, Dennis Gilmore wrote:
> On Thu, 2018-06-14 at 22:23 +0300, Baruch Siach wrote:
> > 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?
> 
> yes I did, I am testing on a clearfog pro
> 
> > Does current U-Boot master work for you?
> 2018.03 fails the same. I have another clearfog pro and a clearfog base
> I can test with, though I have the internal mmc on my base and now wish
> I had not done so.
> 
> > 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.
> mine does not work either way, so it is no worse off. I would like to
> put u-boot in SPI on them all 

Can you read/write the SPI flash from Linux?

baruch

> > > 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 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible

[Dennis Gilmore]

On Thu, 2018-06-14 at 22:23 +0300, Baruch Siach wrote:
> 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?

yes I did, I am testing on a clearfog pro

> 
> Does current U-Boot master work for you?
2018.03 fails the same. I have another clearfog pro and a clearfog base
I can test with, though I have the internal mmc on my base and now wish
I had not done so.


> 
> 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.
mine does not work either way, so it is no worse off. I would like to
put u-boot in SPI on them all 

Dennis

> 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";
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Simon Glass]

Hi Alex,

On 15 June 2018 at 06:42, 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 addresses in the EFI memory map, this
> patch set makes the EFI memory map contain host virtual addresses.
> That way most logic "just works" and all EFI interfaces automatically
> gain sandbox awareness.
>
> We also change the memory map of sandbox to hard code RAM to always
> live at address 0x8000. This patch is completely optional.
>
> With this patch set in place, I can successfully run the selftest suite
> as well as an aarch64 grub.efi binary. X86_64 grub.efi doesn't work
> because that one requires inl instructions to work.
>
> 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
>
> v2 -> v3:
>
>   - removed: efi_loader: Pass address to fs_read()
>   - new: fs: Convert fs_read/write to take buffer instead of address
>   - new: efi_loader: Introduce ms abi vararg helpers
>   - new: sandbox: Enable 1:1 map
>   - new: distro: Move to compiler based target architecture determination
>   - new: efi_loader: Move to compiler based target architecture determination
>   - new: sandbox: Allow to execute from RAM
>   - new: sandbox: Fix setjmp/longjmp
>
> Alexander Graf (13):
>   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
>   fs: Convert fs_read/write to take buffer instead of address
>   efi_loader: Introduce ms abi vararg helpers
>   sandbox: Enable 1:1 map
>   distro: Move to compiler based target architecture determination
>   efi_loader: Move to compiler based target architecture determination
>   sandbox: Allow to execute from RAM
>   sandbox: Fix setjmp/longjmp
>
> 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
>
>  Makefile  |  2 +-
>  arch/sandbox/cpu/cpu.c| 30 
>  arch/sandbox/cpu/os.c | 43 
> ---
>  arch/sandbox/cpu/state.c  |  4 ++--
>  arch/sandbox/cpu/u-boot.lds   |  9 
>  arch/sandbox/include/asm/io.h | 17 --
>  arch/sandbox/include/asm/setjmp.h |  4 +++-
>  board/BuR/common/common.c |  2 +-
>  board/gdsys/p1022/controlcenterd-id.c | 10 
>  cmd/bootefi.c | 13 +++
>  cmd/mvebu/bubt.c  |  4 ++--
>  common/board_f.c  |  4 +++-
>  common/splash_source.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 ++--
>  drivers/bootcount/bootcount_ext.c | 12 +-
>  drivers/fpga/zynqpl.c |  8 ---
>  fs/fs.c   | 20 
>  include/config_distro_bootcmd.h   | 14 +++-
>  include/configs/sandbox.h | 32 +-
>  include/efi.h | 25 ++--
>  include/fs.h  | 12 +-
>  include/os.h  | 19 
>  lib/efi/Makefile  |  4 ++--
>  lib/efi_loader/Kconfig|  2 +-
>  lib/efi_loader/efi_boottime.c | 36 ++---
>  lib/efi_loader/efi_file.c |  6 ++---
>  lib/efi_loader/efi_image_loader.c | 12 +-
>  lib/efi_loader/efi_memory.c   |  2 +-
>  lib/efi_loader/efi_runtime.c  | 14 +++-
>  lib/efi_loader/efi_smbios.c   | 11 +++--
>  lib/efi_selftest/Makefile |  2 +-
>  35 files changed, 219 insertions(+), 182 deletions(-)
>
> --
> 2.12.3
>

General comment on this series. I don't see the need to change how
sandbox works just to avoid a few map_sysmem() calls in the EFI code.
I don't think it is very hard to press on from 'sandbox runs hello
world' to 'sandbox runs grub', particularly as you have solved some of
the other problems. I'll take a look.

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

Re: [U-Boot] [PATCH v4 05/16] sandbox: Add a setjmp() implementation

[Simon Glass]

Hi Alex,

On 15 June 2018 at 06:01, Alexander Graf  wrote:
>
>
> On 16.05.18 17:42, Simon Glass wrote:
>> Add an implementation of setjmp() and longjmp() which rely on the
>> underlying host C library. Since we cannot know how large the jump buffer
>> needs to be, pick something that should be suitable and check it at
>> runtime. At present we need access to the underlying struct as well.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v4:
>> - Fix up the sizeof() operations on jmp_buf
>> - Update SPDX tags
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  arch/sandbox/cpu/cpu.c| 13 +
>>  arch/sandbox/cpu/os.c | 23 +++
>>  arch/sandbox/include/asm/setjmp.h | 30 ++
>>  include/os.h  | 21 +
>>  4 files changed, 87 insertions(+)
>>  create mode 100644 arch/sandbox/include/asm/setjmp.h
>>
>> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
>> index d4ad020012e..cde0b055a67 100644
>> --- a/arch/sandbox/cpu/cpu.c
>> +++ b/arch/sandbox/cpu/cpu.c
>> @@ -9,6 +9,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -164,3 +165,15 @@ ulong timer_get_boot_us(void)
>>
>>   return (count - base_count) / 1000;
>>  }
>> +
>> +int setjmp(jmp_buf jmp)
>> +{
>> + return os_setjmp((ulong *)jmp, sizeof(*jmp));
>
> So, this doesn't work. Function returns increase the stack pointer which
> means after setjmp() you are not allowed to return until the longjmp
> occured. The documentation is quite clear about this:
>
>
> DESCRIPTION
>setjmp() and longjmp(3) are useful for dealing with errors and
> interrupts encountered in a low-level subroutine of a program.  setjmp()
> saves the stack context/environment in env for later use by longjmp(3).
> The stack context will be invalidated if the function which called
> setjmp() returns.
>
>
> So we need to find a way to call setjmp() directly from the code point
> where we want to call it, rather than jump through helper functions, as
> these break its functionality.

That sounds hard but perhaps we can do something with inline
functions? It's hard because we want to call the C library in the
sandbox case. Perhaps we should rename the U-Boot version of the
function.

I wonder if in my test I just relied on hello world returning, rather
than calling the exit() function? BTW we need to find a way for
efi_selftest() to exit cleanly too. At the moment it resets.

>
> Also, os_longjmp() is broken. It calls longjmp() which however is not
> the system longjmp, but the U-Boot internal one that again calls
> os_longjmp. My quick fix was to make it call _longjmp() instead - that
> at least makes that part work.

But it hangs after that?

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

Re: [U-Boot] [PATCH v3 10/17] fs: Convert fs_read/write to take buffer instead of address

[Alexander Graf]

On 15.06.18 16:24, Simon Glass wrote:
> Hi Alex,
> 
> On 15 June 2018 at 06:42, Alexander Graf  wrote:
>> The fs_read() and fs_write() functions are internal interfaces that
>> naturally want to get pointers as arguments. Most users so far even
>> have pointers and explicitly cast them into integers just to be able
>> to pass them into the function.
>>
>> Convert them over to instead take a pointer argument for the buffer.
>> That way any sandbox mapping gets greatly simplified and users of
>> the API intuitively know what to do.
>>
>> Signed-off-by: Alexander Graf 
>> ---
>>  board/BuR/common/common.c |  2 +-
>>  board/gdsys/p1022/controlcenterd-id.c | 10 +-
>>  cmd/mvebu/bubt.c  |  4 ++--
>>  common/splash_source.c|  4 +++-
>>  drivers/bootcount/bootcount_ext.c | 12 ++--
>>  drivers/fpga/zynqpl.c |  8 +---
>>  fs/fs.c   | 20 ++--
>>  include/fs.h  | 12 ++--
>>  lib/efi_loader/efi_file.c |  6 ++
>>  9 files changed, 40 insertions(+), 38 deletions(-)
> 
> U-Boot uses addresses for loading and managing images. I don't see a
> good reason to change that. We expect all logging to emit an address
> rather than a pointer, for example. See for example all the FIT and
> legacy image stuff, bootm, all the commands, etc.

Yes, usually the point of transition from address is when you go from
command line to internal infrastructure.

If you for example take a look at struct fstype_info in fs.c, you can
see that the read and write callbacks already use pointers.

The block equivalent of fs_read() is blk_dread() which also takes a buffer.

fs_read()/fs_write() really are the odd ones out in the API. And if you
take a look at all users of the API, I'd say 90% of them already get it
"wrong" (read: they assume a 1:1 map and just randomly cast pointers to
addresses).

So IMHO this patch really is just streamlining the API to adjust it to
the rest of the U-Boot infrastructure.


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

Re: [U-Boot] [PATCH v3 10/17] fs: Convert fs_read/write to take buffer instead of address

[Simon Glass]

Hi Alex,

On 15 June 2018 at 06:42, Alexander Graf  wrote:
> The fs_read() and fs_write() functions are internal interfaces that
> naturally want to get pointers as arguments. Most users so far even
> have pointers and explicitly cast them into integers just to be able
> to pass them into the function.
>
> Convert them over to instead take a pointer argument for the buffer.
> That way any sandbox mapping gets greatly simplified and users of
> the API intuitively know what to do.
>
> Signed-off-by: Alexander Graf 
> ---
>  board/BuR/common/common.c |  2 +-
>  board/gdsys/p1022/controlcenterd-id.c | 10 +-
>  cmd/mvebu/bubt.c  |  4 ++--
>  common/splash_source.c|  4 +++-
>  drivers/bootcount/bootcount_ext.c | 12 ++--
>  drivers/fpga/zynqpl.c |  8 +---
>  fs/fs.c   | 20 ++--
>  include/fs.h  | 12 ++--
>  lib/efi_loader/efi_file.c |  6 ++
>  9 files changed, 40 insertions(+), 38 deletions(-)

U-Boot uses addresses for loading and managing images. I don't see a
good reason to change that. We expect all logging to emit an address
rather than a pointer, for example. See for example all the FIT and
legacy image stuff, bootm, all the commands, etc.

Regards,
Simon
___
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: Alexander Graf 
> Date: Fri, 15 Jun 2018 15:12:31 +0200
> 
> Am 15.06.2018 um 15:01 schrieb Mark Kettenis :
> 
> >> From: Alexander Graf 
> >> Date: Fri, 15 Jun 2018 12:49:48 +0200
> >> 
> >>> On 15.06.18 05:39, Heinrich Schuchardt wrote:
> >>> 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().
> >> 
> >> I would actually prefer to keep it where it is. That way we have the
> >> option to move the object initialization to a different stage later on.
> > 
> > Also I'd rather not touch the aarch64 code in this series and I think
> > it makes sense to keep the switching in the same place for aarch32 and
> > aarch64.
> > 
> >> The only thing missing is really a check which level we're on. The
> >> aarch64 code does this with a current_el() == 3 condition.
> > 
> > As I replied to Heinrich, checking whether we're secure or not isn't
> > simple as reading the SCR.NS bit will trap if we're in non-secure
> > mode.  But using a global variable to remember the state we're in,
> > works and isn't too ugly.
> 
> Can you figure out something else? Like whether you're in SVC?

Unfortunately not.  On hardware with security extensions, but without
virtualization extensions, we'll start out in secure SVC before
running the first EFI payload and in non-secure SVC afterwards.

> > I'm going to look into enabling the MMU for HYP over the weekend.
> > I'll do another respin once I've figured that issue out.
> 
> It might just be as simple as depending on LPAE in Kconfig when NS is set :)

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

[U-Boot] SquashFS patch

[Frank Hunleth]

I attempted to integrate SquashFS with U-boot based on the SquashFS support in 
Barebox. It works in that loads the Linux kernel and device tree files from a 
SquashFS-formatted root filesystem reliably. Unfortunately, it’s slow (much 
slower than Linux SquashFS even though they share most of the code), only zlib 
compression works, and the code needs to be cleaned up (this was my first time 
spending time in the U-boot codebase). 

It would be nice to push this the rest of the way so that it could be included 
in U-boot. It’s definitely not ready and I feel like I need help fixing the 
performance issue and getting it the rest of the way there. Is there any 
interest?

The patch can be found at https://github.com/fhunleth/u-boot-squashfs 
. If/when it gets into an 
upstream-able state, I’ll definitely submit properly to this list.

Thanks,
Frank
___
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

[Marc Zyngier]

On 15/06/18 13:51, Mark Kettenis wrote:
>> From: Marc Zyngier 
>> Date: Fri, 15 Jun 2018 08:59:59 +0100
>>
>> On 14/06/18 21:55, Mark Kettenis wrote:
 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.
>>
>> I guess the following can happen:
>>
>> - EL1 code (or SVC for AArch32) has its MMU enabled, and caches are on
>> - Writes from EL1 are nicely sitting in the dcache
>> - Enter EL2 (HYP) where the MMU is off, and thus the caches are too
>> - The uncached accesses do not hit in the cache, and sh*t happens
>>
>> dcache_disable also cleans to the PoC, making sure that everything is
>> visible even when the MMU and caches are off. I have the strong feeling
>> that dcache_enable is utterly useless as I don't think you install any
>> page table at HYP (that code was never designed to run anything other
>> than jumping into the kernel).
> 
> There actually is code in arch/arm/lib/cache-cp15.c to set up the page
> tables for HYP and enable the MMU.  And it would run as part of the
> dcache_enable() call if CONFIG_ARMV7_LPAE was defined.  But that isn't
> set on the boards I'm looking at.  I'll have a go at enabling that option.

Yeah, you most definitely want to have that one, and LPAE is the only
thing that makes sense if you have a virtualization-capable CPU.

> 
>> It would make a lot more sense if you installed id-mapped page tables at
>> HYP too in order to enable the caches, and geta  bit of performance back
>> (otherwise anything you run at HYP will negatively compare to the speed
>> of an anaemic snail stuck on sand).
> 
> On the Allwinner A20 it certainly does crawl; console output is really
> slow.  Didn't notice it on the NXP i.MX7D board though.  Anyway,
> thanks for the hint!

No worries.

M.
-- 
Jazz is not dead. It just smells funny...
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] omap3_logic: Change console from ttyO0 to ttyS0

[Peter Robinson]

On Fri, Jun 15, 2018 at 2:12 PM, Adam Ford  wrote:
> Newer kernels have moved from ttyO0 to ttyS0, and when booting
> it drops a notice:

This will break on older kernels or kernels that haven't made the move
from the omap-serial to the 8250_omap kernel.

>   WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
>   This ensures that you still see kernel messages. Please
>   update your kernel commandline.
>
> This patch updates the console to use ttyS0 and eliminate the
> chatter.
>
> Signed-off-by: Adam Ford 
>
> diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
> index cde61f2fd7..7b8f402e14 100644
> --- a/include/configs/omap3_logic.h
> +++ b/include/configs/omap3_logic.h
> @@ -92,7 +92,7 @@
> "fi; " \
> "else run defaultboot; fi\0" \
> "defaultboot=run mmcramboot\0" \
> -   "consoledevice=ttyO0\0" \
> +   "consoledevice=ttyS0\0" \
> "setconsole=setenv console ${consoledevice},${baudrate}n8\0" \
> "dump_bootargs=echo 'Bootargs: '; echo $bootargs\0" \
> "rotation=0\0" \
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull ARC changes

[Alexey Brodkin]

Hi Tom,

The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:

  Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-14 07:20:41 
-0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-arc.git tags/arc-updates-for-2018.07-rc2

for you to fetch changes up to 3b4410dde3b82c8a743fa88280b9b0cdd21b1bf3:

  ARC: HSDK: Add readme (2018-06-15 15:54:43 +0300)


Here we just add a tool for HSDK flashable images preparation
together with extensive documentation for HSDK board.

This will help real-life users to update U-Boot on the board.


Alexey Brodkin (1):
  ARC: HSDK: Add readme

Eugeniy Paltsev (1):
  ARC: HSDK: Add tool and make target to generate bsp

 board/synopsys/hsdk/README| 121 
+++
 board/synopsys/hsdk/config.mk |  11 +
 board/synopsys/hsdk/headerize-hsdk.py | 149

 include/configs/hsdk.h|   6 +
 4 files changed, 287 insertions(+)
 create mode 100644 board/synopsys/hsdk/README
 create mode 100644 board/synopsys/hsdk/config.mk
 create mode 100644 board/synopsys/hsdk/headerize-hsdk.py

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

Am 15.06.2018 um 15:01 schrieb Mark Kettenis :

>> From: Alexander Graf 
>> Date: Fri, 15 Jun 2018 12:49:48 +0200
>> 
>>> On 15.06.18 05:39, Heinrich Schuchardt wrote:
>>> 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().
>> 
>> I would actually prefer to keep it where it is. That way we have the
>> option to move the object initialization to a different stage later on.
> 
> Also I'd rather not touch the aarch64 code in this series and I think
> it makes sense to keep the switching in the same place for aarch32 and
> aarch64.
> 
>> The only thing missing is really a check which level we're on. The
>> aarch64 code does this with a current_el() == 3 condition.
> 
> As I replied to Heinrich, checking whether we're secure or not isn't
> simple as reading the SCR.NS bit will trap if we're in non-secure
> mode.  But using a global variable to remember the state we're in,
> works and isn't too ugly.

Can you figure out something else? Like whether you're in SVC?

> I'm going to look into enabling the MMU for HYP over the weekend.
> I'll do another respin once I've figured that issue out.

It might just be as simple as depending on LPAE in Kconfig when NS is set :)

Alex


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

[U-Boot] [PATCH] omap3_logic: Change console from ttyO0 to ttyS0

[Adam Ford]

Newer kernels have moved from ttyO0 to ttyS0, and when booting
it drops a notice:

  WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
  This ensures that you still see kernel messages. Please
  update your kernel commandline.

This patch updates the console to use ttyS0 and eliminate the
chatter.

Signed-off-by: Adam Ford 

diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
index cde61f2fd7..7b8f402e14 100644
--- a/include/configs/omap3_logic.h
+++ b/include/configs/omap3_logic.h
@@ -92,7 +92,7 @@
"fi; " \
"else run defaultboot; fi\0" \
"defaultboot=run mmcramboot\0" \
-   "consoledevice=ttyO0\0" \
+   "consoledevice=ttyS0\0" \
"setconsole=setenv console ${consoledevice},${baudrate}n8\0" \
"dump_bootargs=echo 'Bootargs: '; echo $bootargs\0" \
"rotation=0\0" \
-- 
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

[Mark Kettenis]

> From: Alexander Graf 
> Date: Fri, 15 Jun 2018 12:49:48 +0200
> 
> On 15.06.18 05:39, Heinrich Schuchardt wrote:
> > 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().
> 
> I would actually prefer to keep it where it is. That way we have the
> option to move the object initialization to a different stage later on.

Also I'd rather not touch the aarch64 code in this series and I think
it makes sense to keep the switching in the same place for aarch32 and
aarch64.

> The only thing missing is really a check which level we're on. The
> aarch64 code does this with a current_el() == 3 condition.

As I replied to Heinrich, checking whether we're secure or not isn't
simple as reading the SCR.NS bit will trap if we're in non-secure
mode.  But using a global variable to remember the state we're in,
works and isn't too ugly.

I'm going to look into enabling the MMU for HYP over the weekend.
I'll do another respin once I've figured that issue out.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [GIT PULL] Xilinx changes for v2018.07-rc2

[Michal Simek]

Hi Tom,

please pull these changes to your tree.
Buildman and travis looks good
https://travis-ci.org/michalsimek/u-boot/builds/392586380

Thanks,
Michal

The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:

  Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-14
07:20:41 -0400)

are available in the git repository at:


  git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.07-rc2

for you to fetch changes up to b729ed0d95415bd694a6b67c0761f03ef5a1e2bc:

  serial: zynq: Make zynq_serial_setbrg static (2018-06-15 08:54:05 +0200)


Xilinx fixes for v2018.07-rc2

Zynq:
- Fix missing watchdog header
- DT fixes

ZynqMP:
- emmc configuration split
- Enable SPD
- Fix PMUFW_INIT_FILE logic
- Coverity fixes in SoC code

timer
- Add timer_get_boot_us

mmc:
- Fix MMC HS200 tuning command

serial:
- Fix scrabled chars with OF_LIVE


Luca Ceresoli (1):
  arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE

Michal Simek (13):
  arm: zynq: Add missing watchdog header
  arm: zynq: Drop #address-cells and #size-cells from gpio-keys
  timer: cadence: Implement timer_get_boot_us
  arm64: zynqmp: Enable SPD ddr support for zcu102 targets
  gpio: zynq: Do not check unsigned type that is >= 0
  mmc: zynq: Fix tuning_loop_counter type in
arasan_sdhci_execute_tuning()
  arm64: zynqmp: Check return value from calloc
  arm64: zynqmp: Check return value in zynqmp_mmio_rawwrite()
  gpio: zynq_gpio: bank description should use unsigned type
  serial: zynq: Use BIT macros instead of shifts and full hex numbers
  serial: zynq: Write chars till output fifo is full
  serial: zynq: Initialize uart only before relocation
  serial: zynq: Make zynq_serial_setbrg static

Siva Durga Prasad Paladugu (2):
  arm64: zynqmp: Split emmc configuration into emmc0 and emmc1
  mmc: sdhci: Fix MMC HS200 tuning command failures

 arch/arm/cpu/armv8/zynqmp/cpu.c
  |  6 +-
 arch/arm/dts/Makefile
  |  3 ++-
 arch/arm/dts/zynq-zc702.dts
  |  2 --
 arch/arm/dts/zynq-zturn.dts
  |  2 --
 arch/arm/dts/{zynqmp-mini-emmc.dts => zynqmp-mini-emmc0.dts}
  | 20 ++--
 arch/arm/dts/zynqmp-mini-emmc1.dts
  | 67
+++
 arch/arm/dts/zynqmp-zcu100-revC.dts
  |  2 --
 arch/arm/dts/zynqmp-zcu102-revA.dts
  |  2 --
 arch/arm/dts/zynqmp-zcu106-revA.dts
  |  2 --
 arch/arm/dts/zynqmp-zcu111-revA.dts
  |  2 --
 board/xilinx/zynq/board.c
  |  1 +
 board/xilinx/zynqmp/zynqmp.c
  |  2 ++
 configs/{xilinx_zynqmp_mini_emmc_defconfig =>
xilinx_zynqmp_mini_emmc0_defconfig} |  3 ++-
 configs/xilinx_zynqmp_mini_emmc1_defconfig
  | 49 +
 configs/xilinx_zynqmp_r5_defconfig
  |  2 ++
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
  |  1 +
 configs/xilinx_zynqmp_zcu102_revA_defconfig
  |  1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig
  |  1 +
 drivers/gpio/zynq_gpio.c
  | 10 +-
 drivers/mmc/sdhci.c
  |  8 
 drivers/mmc/zynq_sdhci.c
  |  2 +-
 drivers/serial/serial_zynq.c
  | 24 +++-
 drivers/timer/cadence-ttc.c
  | 22 ++
 include/configs/xilinx_zynqmp_zcu102.h
  |  3 +++
 scripts/Makefile.spl
  |  8 +++-
 25 files changed, 196 insertions(+), 49 deletions(-)
 rename arch/arm/dts/{zynqmp-mini-emmc.dts => zynqmp-mini-emmc0.dts} (77%)
 create mode 100644 arch/arm/dts/zynqmp-mini-emmc1.dts
 rename configs/{xilinx_zynqmp_mini_emmc_defconfig =>
xilinx_zynqmp_mini_emmc0_defconfig} (94%)
 create mode 100644 configs/xilinx_zynqmp_mini_emmc1_defconfig


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




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

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

[Mark Kettenis]

> From: Marc Zyngier 
> Date: Fri, 15 Jun 2018 08:59:59 +0100
> 
> On 14/06/18 21:55, Mark Kettenis wrote:
> >> 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.
> 
> I guess the following can happen:
> 
> - EL1 code (or SVC for AArch32) has its MMU enabled, and caches are on
> - Writes from EL1 are nicely sitting in the dcache
> - Enter EL2 (HYP) where the MMU is off, and thus the caches are too
> - The uncached accesses do not hit in the cache, and sh*t happens
> 
> dcache_disable also cleans to the PoC, making sure that everything is
> visible even when the MMU and caches are off. I have the strong feeling
> that dcache_enable is utterly useless as I don't think you install any
> page table at HYP (that code was never designed to run anything other
> than jumping into the kernel).

There actually is code in arch/arm/lib/cache-cp15.c to set up the page
tables for HYP and enable the MMU.  And it would run as part of the
dcache_enable() call if CONFIG_ARMV7_LPAE was defined.  But that isn't
set on the boards I'm looking at.  I'll have a go at enabling that option.

> It would make a lot more sense if you installed id-mapped page tables at
> HYP too in order to enable the caches, and geta  bit of performance back
> (otherwise anything you run at HYP will negatively compare to the speed
> of an anaemic snail stuck on sand).

On the Allwinner A20 it certainly does crawl; console output is really
slow.  Didn't notice it on the NXP i.MX7D board though.  Anyway,
thanks for the hint!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 13/17] 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.

Signed-off-by: Alexander Graf 

---

I 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 ;)
---
 Makefile   |  2 +-
 arch/sandbox/cpu/cpu.c | 35 ---
 arch/sandbox/cpu/state.c   |  4 ++--
 arch/sandbox/cpu/u-boot.lds|  9 +
 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  | 32 
 12 files changed, 48 insertions(+), 79 deletions(-)

diff --git a/Makefile b/Makefile
index 6a190e7a89..705c5b632f 100644
--- a/Makefile
+++ b/Makefile
@@ -867,7 +867,7 @@ endif
 
 # Normally we fill empty space with 0xff
 quiet_cmd_objcopy = OBJCOPY $@
-cmd_objcopy = $(OBJCOPY) --gap-fill=0xff $(OBJCOPYFLAGS) \
+cmd_objcopy = $(OBJCOPY) --gap-fill=0xff -R .ram $(OBJCOPYFLAGS) \
$(OBJCOPYFLAGS_$(@F)) $< $@
 
 # Provide a version which does not do this, for use by EFI
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 23d8b70648..b20894b806 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,7 +5,6 @@
 #define DEBUG
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -58,16 +57,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 +92,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)
 {
 }
@@ -178,22 +162,3 @@ 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
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 = _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..dd649df1f8 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -50,3 +50,12 @@ SECTIONS
 }
 
 INSERT BEFORE .data;
+
+SECTIONS
+{
+   .ram 0x800 : {
+   *(.ram)
+   }
+}
+
+INSERT BEFORE .bss;
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 

[U-Boot] [PATCH v3 16/17] sandbox: Allow to execute from RAM

[Alexander Graf]

With efi_loader, we may want to execute payload from RAM. By default,
permissions on the RAM region don't allow us to execute from there though.

So whenever we get into the efi_loader case, let's mark RAM as executable.
That way we still protect normal cases, but allow for efi binaries to
directly get executed from within RAM.

For this, we hook into the already existing allow_unaligned() call which
also transitions the system over into semantics required by the UEFI
specification.

Signed-off-by: Alexander Graf 
---
 arch/sandbox/cpu/cpu.c | 10 ++
 arch/sandbox/cpu/os.c  | 23 +++
 include/os.h   | 19 +++
 3 files changed, 52 insertions(+)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index b20894b806..944f104899 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -162,3 +162,13 @@ void longjmp(jmp_buf jmp, int ret)
while (1)
;
 }
+
+void allow_unaligned(void)
+{
+   int r;
+
+   r = os_mprotect(gd->arch.ram_buf, gd->ram_size,
+   OS_PROT_READ | OS_PROT_WRITE | OS_PROT_EXEC);
+
+   assert(!r);
+}
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 5839932b00..81206ba0d2 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -183,6 +183,29 @@ void *os_realloc(void *ptr, size_t length)
return buf;
 }
 
+int os_mprotect(void *ptr, size_t length, int prot)
+{
+   struct os_mem_hdr *hdr = ptr;
+   int p = 0;
+
+   if ((uintptr_t)ptr & sizeof(*hdr)) {
+   /*
+* We got an unaligned pointer, probably a return value
+* from os_malloc()
+*/
+   ptr = [-1];
+   }
+
+   if (prot & OS_PROT_READ)
+   p |= PROT_READ;
+   if (prot & OS_PROT_WRITE)
+   p |= PROT_WRITE;
+   if (prot & OS_PROT_EXEC)
+   p |= PROT_EXEC;
+
+   return mprotect(ptr, length, p);
+}
+
 void os_usleep(unsigned long usec)
 {
usleep(usec);
diff --git a/include/os.h b/include/os.h
index c8e0f52d30..d451e12064 100644
--- a/include/os.h
+++ b/include/os.h
@@ -157,6 +157,25 @@ void os_free(void *ptr);
 void *os_realloc(void *ptr, size_t length);
 
 /**
+ * Modify protection of a memory region
+ *
+ * This function changes the memory protection scheme of a given memory
+ * region. Using it you can for example allow execution of memory that
+ * would otherwise prohibit it.
+ *
+ * \param ptr  Pointer to memory region to modify
+ * \param length   New length for memory block
+ * \param prot New protection scheme (ORed OS_PROT_ values)
+ * \return 0 on success, -1 otherwise.
+ */
+int os_mprotect(void *ptr, size_t length, int prot);
+
+/* Defines for "prot" in os_mprotect() */
+#define OS_PROT_READ   0x1
+#define OS_PROT_WRITE  0x2
+#define OS_PROT_EXEC   0x4
+
+/**
  * Access to the usleep function of the os
  *
  * \param usec Time to sleep in micro seconds
-- 
2.12.3

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

[U-Boot] [PATCH v3 17/17] sandbox: Fix setjmp/longjmp

[Alexander Graf]

In sandbox, longjmp returns to itself in an endless loop. Cut this through
by calling the real OS function.

Setjmp on the other hand must not return. So here we have to call the OS
setjmp function straight from the code where the setjmp call happens.

Signed-off-by: Alexander Graf 
---
 arch/sandbox/cpu/cpu.c|  5 -
 arch/sandbox/cpu/os.c | 20 ++--
 arch/sandbox/include/asm/setjmp.h |  4 +++-
 3 files changed, 5 insertions(+), 24 deletions(-)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 944f104899..1d9f10df98 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -151,11 +151,6 @@ ulong timer_get_boot_us(void)
return (count - base_count) / 1000;
 }
 
-int setjmp(jmp_buf jmp)
-{
-   return os_setjmp((ulong *)jmp, sizeof(*jmp));
-}
-
 void longjmp(jmp_buf jmp, int ret)
 {
os_longjmp((ulong *)jmp, ret);
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 81206ba0d2..4ef4040103 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -653,24 +653,8 @@ void os_localtime(struct rtc_time *rt)
rt->tm_isdst = tm->tm_isdst;
 }
 
-int os_setjmp(ulong *jmp, int size)
-{
-   jmp_buf dummy;
-
-   /*
-* We cannot rely on the struct name that jmp_buf uses, so use a
-* local variable here
-*/
-   if (size < sizeof(dummy)) {
-   printf("setjmp: jmpbuf is too small (%d bytes, need %d)\n",
-  size, sizeof(jmp_buf));
-   return -ENOSPC;
-   }
-
-   return setjmp((struct __jmp_buf_tag *)jmp);
-}
-
 void os_longjmp(ulong *jmp, int ret)
 {
-   longjmp((struct __jmp_buf_tag *)jmp, ret);
+   /* Call the OS longjmp function directly */
+   _longjmp((struct __jmp_buf_tag *)jmp, ret);
 }
diff --git a/arch/sandbox/include/asm/setjmp.h 
b/arch/sandbox/include/asm/setjmp.h
index 1fe37c91cc..e103d170e0 100644
--- a/arch/sandbox/include/asm/setjmp.h
+++ b/arch/sandbox/include/asm/setjmp.h
@@ -24,7 +24,9 @@ struct jmp_buf_data {
 
 typedef struct jmp_buf_data jmp_buf[1];
 
-int setjmp(jmp_buf jmp);
+/* Call the OS setjmp function directly, so that we don't introduce returns */
+#define setjmp _setjmp
+int _setjmp(jmp_buf jmp);
 __noreturn void longjmp(jmp_buf jmp, int ret);
 
 #endif /* _SETJMP_H_ */
-- 
2.12.3

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

[U-Boot] [PATCH v3 10/17] fs: Convert fs_read/write to take buffer instead of address

[Alexander Graf]

The fs_read() and fs_write() functions are internal interfaces that
naturally want to get pointers as arguments. Most users so far even
have pointers and explicitly cast them into integers just to be able
to pass them into the function.

Convert them over to instead take a pointer argument for the buffer.
That way any sandbox mapping gets greatly simplified and users of
the API intuitively know what to do.

Signed-off-by: Alexander Graf 
---
 board/BuR/common/common.c |  2 +-
 board/gdsys/p1022/controlcenterd-id.c | 10 +-
 cmd/mvebu/bubt.c  |  4 ++--
 common/splash_source.c|  4 +++-
 drivers/bootcount/bootcount_ext.c | 12 ++--
 drivers/fpga/zynqpl.c |  8 +---
 fs/fs.c   | 20 ++--
 include/fs.h  | 12 ++--
 lib/efi_loader/efi_file.c |  6 ++
 9 files changed, 40 insertions(+), 38 deletions(-)

diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index 9df19791c2..ab9d9c51cf 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -269,7 +269,7 @@ static int load_devicetree(void)
puts("load_devicetree: set_blk_dev failed.\n");
return -1;
}
-   rc = fs_read(dtbname, (u32)dtbaddr, 0, 0, );
+   rc = fs_read(dtbname, (u_char *)dtbaddr, 0, 0, );
 #endif
if (rc == 0) {
gd->fdt_blob = (void *)dtbaddr;
diff --git a/board/gdsys/p1022/controlcenterd-id.c 
b/board/gdsys/p1022/controlcenterd-id.c
index 7e082dff05..2f01f7b7eb 100644
--- a/board/gdsys/p1022/controlcenterd-id.c
+++ b/board/gdsys/p1022/controlcenterd-id.c
@@ -874,7 +874,7 @@ static struct key_program *load_key_chunk(const char 
*ifname,
 
if (fs_set_blk_dev(ifname, dev_part_str, fs_type))
goto failure;
-   if (fs_read(path, (ulong)buf, 0, 12, ) < 0)
+   if (fs_read(path, buf, 0, 12, ) < 0)
goto failure;
if (i < 12)
goto failure;
@@ -890,7 +890,7 @@ static struct key_program *load_key_chunk(const char 
*ifname,
goto failure;
if (fs_set_blk_dev(ifname, dev_part_str, fs_type))
goto failure;
-   if (fs_read(path, (ulong)result, 0,
+   if (fs_read(path, result, 0,
sizeof(struct key_program) + header.code_size, ) < 0)
goto failure;
if (i <= 0)
@@ -1019,7 +1019,7 @@ static int second_stage_init(void)
struct key_program *hmac_blob = NULL;
const char *image_path = "/ccdm.itb";
char *mac_path = NULL;
-   ulong image_addr;
+   u8 *image_addr;
loff_t image_size;
uint32_t err;
 
@@ -1059,7 +1059,7 @@ static int second_stage_init(void)
strcat(mac_path, mac_suffix);
 
/* read image from mmcdev (ccdm.itb) */
-   image_addr = (ulong)get_image_location();
+   image_addr = get_image_location();
if (fs_set_blk_dev("mmc", mmcdev, FS_TYPE_EXT))
goto failure;
if (fs_read(image_path, image_addr, 0, 0, _size) < 0)
@@ -1077,7 +1077,7 @@ static int second_stage_init(void)
puts("corrupted mac file\n");
goto failure;
}
-   if (check_hmac(hmac_blob, (u8 *)image_addr, image_size)) {
+   if (check_hmac(hmac_blob, image_addr, image_size)) {
puts("image integrity could not be verified\n");
goto failure;
}
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index b4d371f305..29fff898fa 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -209,7 +209,7 @@ static size_t mmc_read_file(const char *file_name)
}
 
/* Perfrom file read */
-   rc = fs_read(file_name, get_load_addr(), 0, 0, _read);
+   rc = fs_read(file_name, (void *)get_load_addr(), 0, 0, _read);
if (rc)
return 0;
 
@@ -392,7 +392,7 @@ static size_t usb_read_file(const char *file_name)
}
 
/* Perfrom file read */
-   rc = fs_read(file_name, get_load_addr(), 0, 0, _read);
+   rc = fs_read(file_name, (void *)get_load_addr(), 0, 0, _read);
if (rc)
return 0;
 
diff --git a/common/splash_source.c b/common/splash_source.c
index 62763b9ebd..79dbea12fc 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -252,7 +253,8 @@ static int splash_load_fs(struct splash_location *location, 
u32 bmp_load_addr)
}
 
splash_select_fs_dev(location);
-   res = fs_read(splash_file, bmp_load_addr, 0, 0, );
+   res = fs_read(splash_file, map_sysmem(bmp_load_addr, bmp_size),
+ 0, 0, );
 
 out:
if (location->ubivol != NULL)
diff --git a/drivers/bootcount/bootcount_ext.c 
b/drivers/bootcount/bootcount_ext.c
index 075e590896..4a46f17c15 100644
--- a/drivers/bootcount/bootcount_ext.c

[U-Boot] [PATCH v3 00/17] 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 addresses in the EFI memory map, this
patch set makes the EFI memory map contain host virtual addresses.
That way most logic "just works" and all EFI interfaces automatically
gain sandbox awareness.

We also change the memory map of sandbox to hard code RAM to always
live at address 0x8000. This patch is completely optional.

With this patch set in place, I can successfully run the selftest suite
as well as an aarch64 grub.efi binary. X86_64 grub.efi doesn't work
because that one requires inl instructions to work.

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

v2 -> v3:

  - removed: efi_loader: Pass address to fs_read()
  - new: fs: Convert fs_read/write to take buffer instead of address
  - new: efi_loader: Introduce ms abi vararg helpers
  - new: sandbox: Enable 1:1 map
  - new: distro: Move to compiler based target architecture determination
  - new: efi_loader: Move to compiler based target architecture determination
  - new: sandbox: Allow to execute from RAM
  - new: sandbox: Fix setjmp/longjmp

Alexander Graf (13):
  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
  fs: Convert fs_read/write to take buffer instead of address
  efi_loader: Introduce ms abi vararg helpers
  sandbox: Enable 1:1 map
  distro: Move to compiler based target architecture determination
  efi_loader: Move to compiler based target architecture determination
  sandbox: Allow to execute from RAM
  sandbox: Fix setjmp/longjmp

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

 Makefile  |  2 +-
 arch/sandbox/cpu/cpu.c| 30 
 arch/sandbox/cpu/os.c | 43 ---
 arch/sandbox/cpu/state.c  |  4 ++--
 arch/sandbox/cpu/u-boot.lds   |  9 
 arch/sandbox/include/asm/io.h | 17 --
 arch/sandbox/include/asm/setjmp.h |  4 +++-
 board/BuR/common/common.c |  2 +-
 board/gdsys/p1022/controlcenterd-id.c | 10 
 cmd/bootefi.c | 13 +++
 cmd/mvebu/bubt.c  |  4 ++--
 common/board_f.c  |  4 +++-
 common/splash_source.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 ++--
 drivers/bootcount/bootcount_ext.c | 12 +-
 drivers/fpga/zynqpl.c |  8 ---
 fs/fs.c   | 20 
 include/config_distro_bootcmd.h   | 14 +++-
 include/configs/sandbox.h | 32 +-
 include/efi.h | 25 ++--
 include/fs.h  | 12 +-
 include/os.h  | 19 
 lib/efi/Makefile  |  4 ++--
 lib/efi_loader/Kconfig|  2 +-
 lib/efi_loader/efi_boottime.c | 36 ++---
 lib/efi_loader/efi_file.c |  6 ++---
 lib/efi_loader/efi_image_loader.c | 12 +-
 lib/efi_loader/efi_memory.c   |  2 +-
 lib/efi_loader/efi_runtime.c  | 14 +++-
 lib/efi_loader/efi_smbios.c   | 11 +++--
 lib/efi_selftest/Makefile |  2 +-
 35 files changed, 219 insertions(+), 182 deletions(-)

-- 
2.12.3

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

[U-Boot] [PATCH v3 11/17] efi_loader: Introduce ms abi vararg helpers

[Alexander Graf]

Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms
abi though, so we also need to make sure we use x86_64 varargs helpers.

This patch introduces generic efi vararg helpers that adhere to the
respective EFI ABI. That way we can deal with them properly from efi
loader code and properly interpret variable arguments.

This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests
on x86_64 for me.

Signed-off-by: Alexander Graf 
---
 include/efi.h |  8 
 lib/efi_loader/efi_boottime.c | 36 ++--
 2 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/include/efi.h b/include/efi.h
index 826d484977..7be7798d8d 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -22,8 +22,16 @@
 /* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
 #ifdef __x86_64__
 #define EFIAPI __attribute__((ms_abi))
+#define efi_va_list __builtin_ms_va_list
+#define efi_va_start __builtin_ms_va_start
+#define efi_va_arg __builtin_va_arg
+#define efi_va_end __builtin_ms_va_end
 #else
 #define EFIAPI asmlinkage
+#define efi_va_list va_list
+#define efi_va_start va_start
+#define efi_va_arg va_arg
+#define efi_va_end va_end
 #endif /* __x86_64__ */
 
 struct efi_device_path;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 50d311548e..404743fe01 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2273,7 +2273,7 @@ static efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces(
 {
EFI_ENTRY("%p", handle);
 
-   va_list argptr;
+   efi_va_list argptr;
const efi_guid_t *protocol;
void *protocol_interface;
efi_status_t r = EFI_SUCCESS;
@@ -2282,12 +2282,12 @@ static efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces(
if (!handle)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (;;) {
-   protocol = va_arg(argptr, efi_guid_t*);
+   protocol = efi_va_arg(argptr, efi_guid_t*);
if (!protocol)
break;
-   protocol_interface = va_arg(argptr, void*);
+   protocol_interface = efi_va_arg(argptr, void*);
r = EFI_CALL(efi_install_protocol_interface(
handle, protocol,
EFI_NATIVE_INTERFACE,
@@ -2296,19 +2296,19 @@ static efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces(
break;
i++;
}
-   va_end(argptr);
+   efi_va_end(argptr);
if (r == EFI_SUCCESS)
return EFI_EXIT(r);
 
/* If an error occurred undo all changes. */
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (; i; --i) {
-   protocol = va_arg(argptr, efi_guid_t*);
-   protocol_interface = va_arg(argptr, void*);
+   protocol = efi_va_arg(argptr, efi_guid_t*);
+   protocol_interface = efi_va_arg(argptr, void*);
EFI_CALL(efi_uninstall_protocol_interface(handle, protocol,
  protocol_interface));
}
-   va_end(argptr);
+   efi_va_end(argptr);
 
return EFI_EXIT(r);
 }
@@ -2332,7 +2332,7 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
 {
EFI_ENTRY("%p", handle);
 
-   va_list argptr;
+   efi_va_list argptr;
const efi_guid_t *protocol;
void *protocol_interface;
efi_status_t r = EFI_SUCCESS;
@@ -2341,12 +2341,12 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
if (!handle)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (;;) {
-   protocol = va_arg(argptr, efi_guid_t*);
+   protocol = efi_va_arg(argptr, efi_guid_t*);
if (!protocol)
break;
-   protocol_interface = va_arg(argptr, void*);
+   protocol_interface = efi_va_arg(argptr, void*);
r = EFI_CALL(efi_uninstall_protocol_interface(
handle, protocol,
protocol_interface));
@@ -2354,20 +2354,20 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
break;
i++;
}
-   va_end(argptr);
+   efi_va_end(argptr);
if (r == EFI_SUCCESS)
return EFI_EXIT(r);
 
/* If an error occurred undo all changes. */
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (; i; --i) {
-   protocol = va_arg(argptr, efi_guid_t*);
-   

[U-Boot] [PATCH v3 06/17] 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, );
-   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, );
+
+   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

[U-Boot] [PATCH v3 15/17] efi_loader: Move to compiler based target architecture determination

[Alexander Graf]

Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us
what CPU architecture we're running on.

The compiler however does know that, so let's just move the ifdefs over
to compiler based defines rather than kconfig based options.

Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_runtime.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 388dfb9840..bc44e43745 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -32,18 +32,18 @@ static efi_status_t __efi_runtime EFIAPI 
efi_invalid_parameter(void);
  * TODO(s...@chromium.org): These defines and structs should come from the elf
  * header for each arch (or a generic header) rather than being repeated here.
  */
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
 #define R_RELATIVE 1027
 #define R_MASK 0xULL
 #define IS_RELA1
-#elif defined(CONFIG_ARM)
+#elif defined(__arm__)
 #define R_RELATIVE 23
 #define R_MASK 0xffULL
-#elif defined(CONFIG_X86)
+#elif defined(__x86_64__) || defined(__i386__)
 #include 
 #define R_RELATIVE R_386_RELATIVE
 #define R_MASK 0xffULL
-#elif defined(CONFIG_RISCV)
+#elif defined(__riscv)
 #include 
 #define R_RELATIVE R_RISCV_RELATIVE
 #define R_MASK 0xffULL
@@ -55,25 +55,15 @@ struct dyn_sym {
u32 foo2;
u32 foo3;
 };
-#ifdef CONFIG_CPU_RISCV_32
+#if (__riscv_xlen == 32)
 #define R_ABSOLUTE R_RISCV_32
 #define SYM_INDEX  8
-#else
+#elif (__riscv_xlen == 64)
 #define R_ABSOLUTE R_RISCV_64
 #define SYM_INDEX  32
+#else
+#error unknown riscv target
 #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 v3 12/17] 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 v3 14/17] distro: Move to compiler based target architecture determination

[Alexander Graf]

Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us
what CPU architecture we're running on.

The compiler however does know that, so let's just move the ifdefs over
to compiler based defines rather than kconfig based options.

Signed-off-by: Alexander Graf 
---
 include/config_distro_bootcmd.h | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 1bd79ae3b8..ca6c57edbf 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -245,35 +245,24 @@
 #if defined(CONFIG_CMD_DHCP)
 #if defined(CONFIG_EFI_LOADER)
 /* http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml */
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
 #define BOOTENV_EFI_PXE_ARCH "0xb"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00011:UNDI:003000"
-#elif defined(CONFIG_ARM)
+#elif defined(__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 */
+#elif defined(__x86_64__)
 #define BOOTENV_EFI_PXE_ARCH "0x7"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000"
-#elif defined(CONFIG_CPU_RISCV_32)
+#elif defined(__i386__)
+#define BOOTENV_EFI_PXE_ARCH "0x0"
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:0:UNDI:003000"
+#elif defined(__riscv) && (__riscv_xlen == 32)
 #define BOOTENV_EFI_PXE_ARCH "0x19"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00025:UNDI:003000"
-#elif defined(CONFIG_CPU_RISCV_64)
+#elif defined(__riscv) && (__riscv_xlen == 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 v3 02/17] 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 v3 09/17] 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 
Reviewed-by: Simon Glass 
---
 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 v3 01/17] 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 v3 05/17] 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 v3 07/17] 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

[U-Boot] [PATCH v3 03/17] 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 v3 04/17] 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 
Reviewed-by: Simon Glass 
---
 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 v3 08/17] 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

Re: [U-Boot] [PATCH v4 05/16] sandbox: Add a setjmp() implementation

[Alexander Graf]

On 16.05.18 17:42, Simon Glass wrote:
> Add an implementation of setjmp() and longjmp() which rely on the
> underlying host C library. Since we cannot know how large the jump buffer
> needs to be, pick something that should be suitable and check it at
> runtime. At present we need access to the underlying struct as well.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v4:
> - Fix up the sizeof() operations on jmp_buf
> - Update SPDX tags
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/sandbox/cpu/cpu.c| 13 +
>  arch/sandbox/cpu/os.c | 23 +++
>  arch/sandbox/include/asm/setjmp.h | 30 ++
>  include/os.h  | 21 +
>  4 files changed, 87 insertions(+)
>  create mode 100644 arch/sandbox/include/asm/setjmp.h
> 
> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
> index d4ad020012e..cde0b055a67 100644
> --- a/arch/sandbox/cpu/cpu.c
> +++ b/arch/sandbox/cpu/cpu.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -164,3 +165,15 @@ ulong timer_get_boot_us(void)
>  
>   return (count - base_count) / 1000;
>  }
> +
> +int setjmp(jmp_buf jmp)
> +{
> + return os_setjmp((ulong *)jmp, sizeof(*jmp));

So, this doesn't work. Function returns increase the stack pointer which
means after setjmp() you are not allowed to return until the longjmp
occured. The documentation is quite clear about this:


DESCRIPTION
   setjmp() and longjmp(3) are useful for dealing with errors and
interrupts encountered in a low-level subroutine of a program.  setjmp()
saves the stack context/environment in env for later use by longjmp(3).
The stack context will be invalidated if the function which called
setjmp() returns.


So we need to find a way to call setjmp() directly from the code point
where we want to call it, rather than jump through helper functions, as
these break its functionality.

Also, os_longjmp() is broken. It calls longjmp() which however is not
the system longjmp, but the U-Boot internal one that again calls
os_longjmp. My quick fix was to make it call _longjmp() instead - that
at least makes that part work.


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

Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Marek Vasut]

On 06/15/2018 01:43 PM, Marek Vasut wrote:
> On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
>> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut  wrote:
 + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
 +   0, 0, 0, 0, 0, 0, 0, );
>>>
>>> Will this call work on platforms without patched ATF ?
>>> (I think not, don't you need to handle return value?)
>>
>> I have not actually tested that, but if I understand the ATF code
>> correctly, unimplemented calls return
>> SMC_UNK (0x), which should be handled by the default case (NOP) 
>> below.
> 
> Which means the board has a memory size of 0 and fails to boot ?
> 
 + switch (res.a0) {
 + case 1:
 + base[0] = 0x04800ULL;
 + size[0] = 0x03800ULL;
 + base[1] = 0x5ULL;
 + size[1] = 0x04000ULL;
 + base[2] = 0x6ULL;
 + size[2] = 0x04000ULL;
 + base[3] = 0x7ULL;
 + size[3] = 0x04000ULL;
 + fdt_fixup_memory_banks(blob, base, size, 4);
 + break;
 + case 2:
 + base[0] = 0x04800ULL;
 + size[0] = 0x07800ULL;
 + base[1] = 0x5ULL;
 + size[1] = 0x08000ULL;
 + fdt_fixup_memory_banks(blob, base, size, 2);
 + break;
 + case 3:
 + base[0] = 0x04800ULL;
 + size[0] = 0x07800ULL;
 + base[1] = 0x5ULL;
 + size[1] = 0x08000ULL;
 + base[2] = 0x6ULL;
 + size[2] = 0x08000ULL;
 + base[3] = 0x7ULL;
 + size[3] = 0x08000ULL;
 + fdt_fixup_memory_banks(blob, base, size, 4);
 + break;
>>>
>>> Obvious design question is -- since you're adding new SMC call anyway,
>>> can't the call just return the memory layout table itself, so that it
>>> won't be duplicated both in U-Boot and ATF ?
>>
>> My gut feeling was to go with the smallest interface possible.
> 
> But this doesn't scale. The API here uses some ad-hoc constants to
> identify memory layout tables which have to be encoded both in ATF and
> U-Boot, both of which must be kept in sync.
> 
> The ATF already has those memory layout tables, it's only a matter of
> passing them to U-Boot. If you do just that, the ad-hoc constants and
> encoding of tables into U-Boot goes away and in fact simplifies the design.
> 
> Yet, I have to wonder if ATF doesn't already contain some sort of
> standard SMC call to get memory topology. It surprises me that it wouldn't.

In fact, Laurent (CCed) was solving some similar issue with lossy decomp
and I think this involved some passing of memory layout information from
ATF to U-Boot too, or am I mistaken ?

-- 
Best regards,
Marek Vasut
___
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 Fri, Jun 15, 2018 at 06:09:49AM +0200, Marek Vasut wrote:
> 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.

Then fix the kernel dts.  I swear when I looked into these last they're
just as visible there.

-- 
Tom


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

Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Marek Vasut]

On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut  wrote:
>>> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>>> +   0, 0, 0, 0, 0, 0, 0, );
>>
>> Will this call work on platforms without patched ATF ?
>> (I think not, don't you need to handle return value?)
> 
> I have not actually tested that, but if I understand the ATF code
> correctly, unimplemented calls return
> SMC_UNK (0x), which should be handled by the default case (NOP) below.

Which means the board has a memory size of 0 and fails to boot ?

>>> + switch (res.a0) {
>>> + case 1:
>>> + base[0] = 0x04800ULL;
>>> + size[0] = 0x03800ULL;
>>> + base[1] = 0x5ULL;
>>> + size[1] = 0x04000ULL;
>>> + base[2] = 0x6ULL;
>>> + size[2] = 0x04000ULL;
>>> + base[3] = 0x7ULL;
>>> + size[3] = 0x04000ULL;
>>> + fdt_fixup_memory_banks(blob, base, size, 4);
>>> + break;
>>> + case 2:
>>> + base[0] = 0x04800ULL;
>>> + size[0] = 0x07800ULL;
>>> + base[1] = 0x5ULL;
>>> + size[1] = 0x08000ULL;
>>> + fdt_fixup_memory_banks(blob, base, size, 2);
>>> + break;
>>> + case 3:
>>> + base[0] = 0x04800ULL;
>>> + size[0] = 0x07800ULL;
>>> + base[1] = 0x5ULL;
>>> + size[1] = 0x08000ULL;
>>> + base[2] = 0x6ULL;
>>> + size[2] = 0x08000ULL;
>>> + base[3] = 0x7ULL;
>>> + size[3] = 0x08000ULL;
>>> + fdt_fixup_memory_banks(blob, base, size, 4);
>>> + break;
>>
>> Obvious design question is -- since you're adding new SMC call anyway,
>> can't the call just return the memory layout table itself, so that it
>> won't be duplicated both in U-Boot and ATF ?
> 
> My gut feeling was to go with the smallest interface possible.

But this doesn't scale. The API here uses some ad-hoc constants to
identify memory layout tables which have to be encoded both in ATF and
U-Boot, both of which must be kept in sync.

The ATF already has those memory layout tables, it's only a matter of
passing them to U-Boot. If you do just that, the ad-hoc constants and
encoding of tables into U-Boot goes away and in fact simplifies the design.

Yet, I have to wonder if ATF doesn't already contain some sort of
standard SMC call to get memory topology. It surprises me that it wouldn't.

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

Re: [U-Boot] Duplicate description in Kconfig for SPL_LOAD_FIT/SPL_LOAD_FIT_FULL

[Marek Vasut]

On 06/15/2018 12:40 PM, Alex Kiernan wrote:
> We've got this in Kconfig:
> 
> config SPL_LOAD_FIT
> bool "Enable SPL loading U-Boot as a FIT"
> select SPL_FIT
> help
>   Normally with the SPL framework a legacy image is generated as part
>   of the build. This contains U-Boot along with information as to
>   where it should be loaded. This option instead enables generation
>   of a FIT (Flat Image Tree) which provides more flexibility. In
>   particular it can handle selecting from multiple device tree
>   and passing the correct one to U-Boot.
> 
> config SPL_LOAD_FIT_FULL
> bool "Enable SPL loading U-Boot as a FIT"
> select SPL_FIT
> help
>   Normally with the SPL framework a legacy image is generated as part
>   of the build. This contains U-Boot along with information as to
>   where it should be loaded. This option instead enables generation
>   of a FIT (Flat Image Tree) which provides more flexibility. In
>   particular it can handle selecting from multiple device tree
>   and passing the correct one to U-Boot.
> 
> As far as I can see they're completely identical descriptions,
> presumably one should say something different?

The later pulls in the entire fitImage code, the former only a reduced
version.

-- 
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 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Alexander Graf]

On 15.06.18 05:39, Heinrich Schuchardt wrote:
> 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().

I would actually prefer to keep it where it is. That way we have the
option to move the object initialization to a different stage later on.

The only thing missing is really a check which level we're on. The
aarch64 code does this with a current_el() == 3 condition.


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

[U-Boot] Duplicate description in Kconfig for SPL_LOAD_FIT/SPL_LOAD_FIT_FULL

[Alex Kiernan]

We've got this in Kconfig:

config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT"
select SPL_FIT
help
  Normally with the SPL framework a legacy image is generated as part
  of the build. This contains U-Boot along with information as to
  where it should be loaded. This option instead enables generation
  of a FIT (Flat Image Tree) which provides more flexibility. In
  particular it can handle selecting from multiple device tree
  and passing the correct one to U-Boot.

config SPL_LOAD_FIT_FULL
bool "Enable SPL loading U-Boot as a FIT"
select SPL_FIT
help
  Normally with the SPL framework a legacy image is generated as part
  of the build. This contains U-Boot along with information as to
  where it should be loaded. This option instead enables generation
  of a FIT (Flat Image Tree) which provides more flexibility. In
  particular it can handle selecting from multiple device tree
  and passing the correct one to U-Boot.

As far as I can see they're completely identical descriptions,
presumably one should say something different?

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

Re: [U-Boot] [PATCH v5] x86: use EFI calling convention for efi_main on x86_64

[Bin Meng]

On Fri, Jun 15, 2018 at 6:13 PM, Bin Meng  wrote:
> On Thu, Jun 14, 2018 at 8:27 AM, Ivan Gorinov  wrote:
>> UEFI specifies the calling convention used in Microsoft compilers;
>> first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
>>
>> All other compilers use System V ABI by default, passing first integer
>> arguments of a function in (%rdi, %rsi, %rdx, %rcx, %r8, %r9).
>>
>> These ABI also specify different sets of registers that must be preserved
>> across function calls (callee-saved).
>>
>> GCC allows using the Microsoft calling convention by adding the ms_abi
>> attribute to a function declaration.
>>
>> Current EFI implementation in U-Boot specifies EFIAPI for efi_main()
>> in the test apps but uses default calling convention in lib/efi.
>>
>> Save efi_main() arguments in the startup code on x86_64;
>> use EFI calling convention for _relocate() on x86_64;
>> consistently use EFI calling convention for efi_main() everywhere.
>>
>> Signed-off-by: Ivan Gorinov 
>> ---
>>  arch/x86/lib/crt0_x86_64_efi.S | 24 +---
>>  lib/efi/efi_app.c  |  3 ++-
>>  lib/efi/efi_stub.c |  3 ++-
>>  3 files changed, 17 insertions(+), 13 deletions(-)
>>
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

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

Re: [U-Boot] [PATCH v5] x86: use EFI calling convention for efi_main on x86_64

[Bin Meng]

On Thu, Jun 14, 2018 at 8:27 AM, Ivan Gorinov  wrote:
> UEFI specifies the calling convention used in Microsoft compilers;
> first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
>
> All other compilers use System V ABI by default, passing first integer
> arguments of a function in (%rdi, %rsi, %rdx, %rcx, %r8, %r9).
>
> These ABI also specify different sets of registers that must be preserved
> across function calls (callee-saved).
>
> GCC allows using the Microsoft calling convention by adding the ms_abi
> attribute to a function declaration.
>
> Current EFI implementation in U-Boot specifies EFIAPI for efi_main()
> in the test apps but uses default calling convention in lib/efi.
>
> Save efi_main() arguments in the startup code on x86_64;
> use EFI calling convention for _relocate() on x86_64;
> consistently use EFI calling convention for efi_main() everywhere.
>
> Signed-off-by: Ivan Gorinov 
> ---
>  arch/x86/lib/crt0_x86_64_efi.S | 24 +---
>  lib/efi/efi_app.c  |  3 ++-
>  lib/efi/efi_stub.c |  3 ++-
>  3 files changed, 17 insertions(+), 13 deletions(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Marek Vasut]

On 06/15/2018 11:40 AM, Ulrich Hecht wrote:
> Uses an SMC call to the ATF to determine the memory configuration, then
> creates appropriate DT memory nodes.
> 
> Signed-off-by: Ulrich Hecht 
> ---
> This is an attempt to avoid having to have a ton of different device trees
> for Renesas R8A7795 H3 SoCs from revision 3.0, which come in a number of
> different memory configurations.
> 
> The specific configuration is statically baked into the ARM Trusted Firmware
> binary, so this solution adds an SMC "SiP Service Call" to the ATF returning
> the memory configuration, and then has u-boot build appropriate memory nodes.
> 
> This has not been tested in the flesh successfully, as I only have a revision
> 1.0 board. I'd like to get some feedback on whether this approach is sound,
> though. Thanks.
> 
> Depends on "[RFC ATF] Add SMCCC_RENESAS_MEMCONF SMC call".
> 
> CU
> Uli
> 
> 
> 
>  board/renesas/salvator-x/salvator-x.c | 51 
> +++
>  configs/r8a7795_salvator-x_defconfig  |  2 ++
>  2 files changed, 53 insertions(+)
> 
> diff --git a/board/renesas/salvator-x/salvator-x.c 
> b/board/renesas/salvator-x/salvator-x.c
> index 651877c..307cb64 100644
> --- a/board/renesas/salvator-x/salvator-x.c
> +++ b/board/renesas/salvator-x/salvator-x.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -136,3 +137,53 @@ void reset_cpu(ulong addr)
>   writel(RST_CODE, RST_CA57RESCNT);
>  #endif
>  }
> +
> +#define ARM_SMCCC_RENESAS_MEMCONF0x8200UL
> +int ft_board_setup(void *blob, bd_t *bd)
> +{
> + if (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A7795 &&
> + rmobile_get_cpu_rev_integer() >= 3) {
> + u64 base[CONFIG_NR_DRAM_BANKS];
> + u64 size[CONFIG_NR_DRAM_BANKS];
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
> +   0, 0, 0, 0, 0, 0, 0, );

Will this call work on platforms without patched ATF ?
(I think not, don't you need to handle return value?)

> + switch (res.a0) {
> + case 1:
> + base[0] = 0x04800ULL;
> + size[0] = 0x03800ULL;
> + base[1] = 0x5ULL;
> + size[1] = 0x04000ULL;
> + base[2] = 0x6ULL;
> + size[2] = 0x04000ULL;
> + base[3] = 0x7ULL;
> + size[3] = 0x04000ULL;
> + fdt_fixup_memory_banks(blob, base, size, 4);
> + break;
> + case 2:
> + base[0] = 0x04800ULL;
> + size[0] = 0x07800ULL;
> + base[1] = 0x5ULL;
> + size[1] = 0x08000ULL;
> + fdt_fixup_memory_banks(blob, base, size, 2);
> + break;
> + case 3:
> + base[0] = 0x04800ULL;
> + size[0] = 0x07800ULL;
> + base[1] = 0x5ULL;
> + size[1] = 0x08000ULL;
> + base[2] = 0x6ULL;
> + size[2] = 0x08000ULL;
> + base[3] = 0x7ULL;
> + size[3] = 0x08000ULL;
> + fdt_fixup_memory_banks(blob, base, size, 4);
> + break;

Obvious design question is -- since you're adding new SMC call anyway,
can't the call just return the memory layout table itself, so that it
won't be duplicated both in U-Boot and ATF ?

> + default:
> + break;
> + }
> + }
> +
> + return 0;
> +}
> diff --git a/configs/r8a7795_salvator-x_defconfig 
> b/configs/r8a7795_salvator-x_defconfig
> index fdfa41c..cd2bb59 100644
> --- a/configs/r8a7795_salvator-x_defconfig
> +++ b/configs/r8a7795_salvator-x_defconfig
> @@ -61,3 +61,5 @@ CONFIG_USB_EHCI_GENERIC=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_OF_LIBFDT_OVERLAY=y
>  CONFIG_SMBIOS_MANUFACTURER=""
> +CONFIG_OF_BOARD_SETUP=y
> +CONFIG_ARM_SMCCC=y

Update the defconfig with make savedefconfig .

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

Re: [U-Boot] [PATCH] x86: cherryhill: Fix DTC warning

[Bin Meng]

On Thu, Jun 14, 2018 at 11:11 PM, Simon Glass  wrote:
> On 12 June 2018 at 21:01, Bin Meng  wrote:
>> Fix warning when compiling cherryhill.dts with latest DTC:
>>
>>   "Warning (avoid_unnecessary_addr_size): /pci/pch@1f,0: unnecessary
>>#address-cells/#size-cells without "ranges" or child "reg" property"
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/dts/cherryhill.dts | 2 --
>>  1 file changed, 2 deletions(-)
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options

[Bin Meng]

Hi Simon,

On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass  wrote:
> Hi Alex,
>
> On 13 June 2018 at 04:17, Alexander Graf  wrote:
>>
>>
>> On 13.06.18 03:29, Simon Glass wrote:
>>> Hi Bin, Alex,
>>>
>>> On 12 June 2018 at 09:36, Bin Meng  wrote:
 From: 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 
 ---

 Changes in v2: None

  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 98bddba..5e1e8ac 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__ */
>>>
>>> I made the same comment in another patch. This is becoming too ad-hoc
>>> where making EFI builds work is distributed and hidden in such a way
>>> that no one will be able to know whether a change causes problems or
>>> not.
>>>
>>> I feel that build config should be deterministic given the CONFIG
>>> options provided by the board. Any checks of compiler predefines
>>> should be done in one place (efi.h?) and bugs in that stuff should
>>> there all be in one place too, and easier to debug and fix.
>>
>> I actually think the opposite is true. We should get rid of any #ifdef
>> CONFIG_ARCH checks throughout the code base that are not meant to
>> actually check for the "target" (sandbox for example), but instead
>> really only want to know the architecture the code is building against.
>>
>> We can easily trust the compiler to emit correct defines for the target
>> architecture it's building against. That's what every other piece of C
>> code on earth depends on. Why be different?
>
> By this logic we would check for __x86_64__ everywhere instead of
> CONFIG_X86. I can't think of a better way to explain this without
> repeating myself.
>
> Bin, do you understand what I am getting at? Are my concerns unwarranted?

I got what you are concerned about. I guess you wanted to say "By this
logic we would check __x86_64__ everywhere instead of *CONFIG_X86_64*"
As when CONFIG_X86_64 is defined, the "-m64" flag is passed to
compiler, and __x86_64__ takes effect. But I think this can only be
applied in source codes. In makefiles, we still need CONFIG_X86_64.

For the bug we are trying to address here, I believe current patch to
test __x86_64__ is the simplest way compared to a bunch of config
options checks. In fact, __x86_64__ contains enough information to fix
the problem, and the config options checks look superfluous.

How about we add some comments to the changes above to explain some
more details? Does that look better?

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

[U-Boot] [PATCH v3 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Alexander Graf]

The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
ignore the DHCP provided TFTP ip address. This breaks every case where we
do now provide a serverip environment variable.

Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
to the DHCP provided TFTP IP if no serverip environment variable is set.

Signed-off-by: Alexander Graf 
---
 configs/ax25-ae350_defconfig | 1 +
 include/configs/ax25-ae350.h | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
index fc04c87485..a328555af6 100644
--- a/configs/ax25-ae350_defconfig
+++ b/configs/ax25-ae350_defconfig
@@ -40,3 +40,4 @@ CONFIG_DM_SPI=y
 CONFIG_ATCSPI200_SPI=y
 CONFIG_TIMER=y
 CONFIG_ATCPIT100_TIMER=y
+CONFIG_BOOTP_PREFER_SERVERIP=y
diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
index b1ca5ac11a..b230896734 100644
--- a/include/configs/ax25-ae350.h
+++ b/include/configs/ax25-ae350.h
@@ -11,7 +11,6 @@
  * CPU and Board Configuration Options
  */
 #define CONFIG_BOOTP_SEND_HOSTNAME
-#define CONFIG_BOOTP_SERVERIP
 
 /*
  * Miscellaneous configurable options
-- 
2.12.3

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

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

[Alexander Graf]

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

v2 -> v3:

  - also check for net_boot_file_name_explicit on option 67

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  | 21 +++--
 net/net.c|  2 ++
 7 files changed, 39 insertions(+), 9 deletions(-)

-- 
2.12.3

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

[U-Boot] [PATCH v3 1/3] net: Prefer command line arguments

[Alexander Graf]

We can call commands like dhcp and bootp without arguments or with
explicit command line arguments that really should tell the code where
to look for files instead.

Unfortunately, the current code simply overwrites command line arguments
in the dhcp case with dhcp values.

This patch allows the code to preserve the command line values if they
were set on the command line. That way the semantics are slightly more
intuitive.

The reason this patch does that by introducing a new variable is that we
can not rely on net_boot_file_name[0] being unset, as today it's
completely legal to call "dhcp" and afterwards run "tftp" and expect the
latter to repeat the same query as before. I would prefer not to break
that behavior in case anyone relies on it.

Signed-off-by: Alexander Graf 

---

v2 -> v3:

  - also check for net_boot_file_name_explicit on option 67
---
 cmd/net.c | 10 --
 include/net.h |  2 ++
 net/bootp.c   | 14 +-
 net/net.c |  2 ++
 4 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/cmd/net.c b/cmd/net.c
index f83839c35e..eca6dd8918 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -183,6 +183,8 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
*cmdtp, int argc,
int   size;
ulong addr;
 
+   net_boot_file_name_explicit = false;
+
/* pre-set load_addr */
s = env_get("loadaddr");
if (s != NULL)
@@ -199,15 +201,18 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
*cmdtp, int argc,
 * mis-interpreted as a valid number.
 */
addr = simple_strtoul(argv[1], , 16);
-   if (end == (argv[1] + strlen(argv[1])))
+   if (end == (argv[1] + strlen(argv[1]))) {
load_addr = addr;
-   else
+   } else {
+   net_boot_file_name_explicit = true;
copy_filename(net_boot_file_name, argv[1],
  sizeof(net_boot_file_name));
+   }
break;
 
case 3:
load_addr = simple_strtoul(argv[1], NULL, 16);
+   net_boot_file_name_explicit = true;
copy_filename(net_boot_file_name, argv[2],
  sizeof(net_boot_file_name));
 
@@ -220,6 +225,7 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t 
*cmdtp, int argc,
printf("Invalid address/size\n");
return CMD_RET_USAGE;
}
+   net_boot_file_name_explicit = true;
copy_filename(net_boot_file_name, argv[3],
  sizeof(net_boot_file_name));
break;
diff --git a/include/net.h b/include/net.h
index 5760685556..a259b7c530 100644
--- a/include/net.h
+++ b/include/net.h
@@ -539,6 +539,8 @@ enum proto_t {
 };
 
 extern charnet_boot_file_name[1024];/* Boot File name */
+/* Indicates whether the file name was specified on the command line */
+extern boolnet_boot_file_name_explicit;
 /* The actual transferred size of the bootfile (in bytes) */
 extern u32 net_boot_file_size;
 /* Boot file size in blocks as reported by the DHCP server */
diff --git a/net/bootp.c b/net/bootp.c
index 9d7cb5d30c..fdcb4374a0 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -157,7 +157,8 @@ static void store_net_params(struct bootp_hdr *bp)
 #if defined(CONFIG_CMD_DHCP)
!(dhcp_option_overload & OVERLOAD_FILE) &&
 #endif
-   (strlen(bp->bp_file) > 0)) {
+   (strlen(bp->bp_file) > 0) &&
+   !net_boot_file_name_explicit) {
copy_filename(net_boot_file_name, bp->bp_file,
  sizeof(net_boot_file_name));
}
@@ -889,10 +890,13 @@ static void dhcp_process_options(uchar *popt, uchar *end)
case 66:/* Ignore TFTP server name */
break;
case 67:/* Bootfile option */
-   size = truncate_sz("Bootfile",
-  sizeof(net_boot_file_name), oplen);
-   memcpy(_boot_file_name, popt + 2, size);
-   net_boot_file_name[size] = 0;
+   if (!net_boot_file_name_explicit) {
+   size = truncate_sz("Bootfile",
+  sizeof(net_boot_file_name),
+  oplen);
+   memcpy(_boot_file_name, popt + 2, size);
+   net_boot_file_name[size] = 0;
+   }
break;
default:
 #if defined(CONFIG_BOOTP_VENDOREX)
diff --git a/net/net.c b/net/net.c
index a4932f46d9..510d491271 100644
--- a/net/net.c
+++ b/net/net.c
@@ -165,6 +165,8 @@ ushort  net_native_vlan = 0x;
 
 /* Boot File name */
 char net_boot_file_name[1024];
+/* Indicates 

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

[Alexander Graf]

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 

---

v1 -> v2:

  - remove README entry
  - improve Kconfig help texts
---
 cmd/Kconfig | 11 +++
 net/bootp.c |  7 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index e283cb9a8a..80a5af8a0c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1121,6 +1121,17 @@ config BOOTP_HOSTNAME
help
  The name may or may not be qualified with the local domain name.
 
+config BOOTP_PREFER_SERVERIP
+   bool "Serverip variable takes precedent over DHCP server IP.
+   default n
+   depends on CMD_BOOTP
+   help
+ By default a BOOTP/DHCP reply will overwrite the 'serverip' variable.
+
+ With this option enabled, the 'serverip' variable in the environment
+ takes precedence over DHCP server IP and will only be set by the DHCP
+ server if not already set in the environment.
+
 config BOOTP_SUBNETMASK
bool "Request & store 'netmask' from BOOTP/DHCP server"
default y
diff --git a/net/bootp.c b/net/bootp.c
index fdcb4374a0..9a2b512e4a 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -147,9 +147,14 @@ static void store_net_params(struct bootp_hdr *bp)
 {
 #if !defined(CONFIG_BOOTP_SERVERIP)
struct in_addr tmp_ip;
+   bool overwrite_serverip = true;
+
+#if defined(CONFIG_BOOTP_PREFER_SERVERIP)
+   overwrite_serverip = false;
+#endif
 
net_copy_ip(_ip, >bp_siaddr);
-   if (tmp_ip.s_addr != 0)
+   if (tmp_ip.s_addr != 0 && (overwrite_serverip || !net_server_ip.s_addr))
net_copy_ip(_server_ip, >bp_siaddr);
memcpy(net_server_ethaddr,
   ((struct ethernet_hdr *)net_rx_packet)->et_src, 6);
-- 
2.12.3

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

Re: [U-Boot] [PATCH v2 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP

[Alexander Graf]

On 14.06.18 18:58, Joe Hershberger wrote:
> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf  wrote:
>> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
>> ignore the DHCP provided TFTP ip address. This breaks every case where we
>> do now provide a serverip environment variable.
>>
>> Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
>> to the DHCP provided TFTP IP if no serverip environment variable is set.
>>
>> Signed-off-by: Alexander Graf 
> 
> Reviewed-by: Joe Hershberger 
> 
>> ---
>>  configs/ax25-ae350_defconfig | 1 +
>>  include/configs/ax25-ae350.h | 1 -
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/ax25-ae350_defconfig b/configs/ax25-ae350_defconfig
>> index fc04c87485..a328555af6 100644
>> --- a/configs/ax25-ae350_defconfig
>> +++ b/configs/ax25-ae350_defconfig
>> @@ -40,3 +40,4 @@ CONFIG_DM_SPI=y
>>  CONFIG_ATCSPI200_SPI=y
>>  CONFIG_TIMER=y
>>  CONFIG_ATCPIT100_TIMER=y
>> +CONFIG_BOOTP_PREFER_SERVERIP=y
>> diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
>> index b1ca5ac11a..b230896734 100644
>> --- a/include/configs/ax25-ae350.h
>> +++ b/include/configs/ax25-ae350.h
>> @@ -11,7 +11,6 @@
>>   * CPU and Board Configuration Options
>>   */
>>  #define CONFIG_BOOTP_SEND_HOSTNAME
>> -#define CONFIG_BOOTP_SERVERIP
> 
> Feel like moving this to Kconfig?

I would actually prefer to remove it altogether ;)


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

[Marc Zyngier]

On 14/06/18 21:55, Mark Kettenis wrote:
>> 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.

I guess the following can happen:

- EL1 code (or SVC for AArch32) has its MMU enabled, and caches are on
- Writes from EL1 are nicely sitting in the dcache
- Enter EL2 (HYP) where the MMU is off, and thus the caches are too
- The uncached accesses do not hit in the cache, and sh*t happens

dcache_disable also cleans to the PoC, making sure that everything is
visible even when the MMU and caches are off. I have the strong feeling
that dcache_enable is utterly useless as I don't think you install any
page table at HYP (that code was never designed to run anything other
than jumping into the kernel).

It would make a lot more sense if you installed id-mapped page tables at
HYP too in order to enable the caches, and geta  bit of performance back
(otherwise anything you run at HYP will negatively compare to the speed
of an anaemic snail stuck on sand).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: Introduce ms abi vararg helpers

[Alexander Graf]

Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms
abi though, so we also need to make sure we use x86_64 varargs helpers.

This patch introduces generic efi vararg helpers that adhere to the
respective EFI ABI. That way we can deal with them properly from efi
loader code and properly interpret variable arguments.

This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests
on x86_64 for me.

Signed-off-by: Alexander Graf 
---
 include/efi.h |  8 
 lib/efi_loader/efi_boottime.c | 36 ++--
 2 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/include/efi.h b/include/efi.h
index e30a3c51c6..94f00466cd 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -22,8 +22,16 @@
 #if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__))
 /* EFI uses the Microsoft ABI which is not the default for GCC */
 #define EFIAPI __attribute__((ms_abi))
+#define efi_va_list __builtin_ms_va_list
+#define efi_va_start __builtin_ms_va_start
+#define efi_va_arg __builtin_va_arg
+#define efi_va_end __builtin_ms_va_end
 #else
 #define EFIAPI asmlinkage
+#define efi_va_list va_list
+#define efi_va_start va_start
+#define efi_va_arg va_arg
+#define efi_va_end va_end
 #endif
 
 struct efi_device_path;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 50d311548e..404743fe01 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2273,7 +2273,7 @@ static efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces(
 {
EFI_ENTRY("%p", handle);
 
-   va_list argptr;
+   efi_va_list argptr;
const efi_guid_t *protocol;
void *protocol_interface;
efi_status_t r = EFI_SUCCESS;
@@ -2282,12 +2282,12 @@ static efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces(
if (!handle)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (;;) {
-   protocol = va_arg(argptr, efi_guid_t*);
+   protocol = efi_va_arg(argptr, efi_guid_t*);
if (!protocol)
break;
-   protocol_interface = va_arg(argptr, void*);
+   protocol_interface = efi_va_arg(argptr, void*);
r = EFI_CALL(efi_install_protocol_interface(
handle, protocol,
EFI_NATIVE_INTERFACE,
@@ -2296,19 +2296,19 @@ static efi_status_t EFIAPI 
efi_install_multiple_protocol_interfaces(
break;
i++;
}
-   va_end(argptr);
+   efi_va_end(argptr);
if (r == EFI_SUCCESS)
return EFI_EXIT(r);
 
/* If an error occurred undo all changes. */
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (; i; --i) {
-   protocol = va_arg(argptr, efi_guid_t*);
-   protocol_interface = va_arg(argptr, void*);
+   protocol = efi_va_arg(argptr, efi_guid_t*);
+   protocol_interface = efi_va_arg(argptr, void*);
EFI_CALL(efi_uninstall_protocol_interface(handle, protocol,
  protocol_interface));
}
-   va_end(argptr);
+   efi_va_end(argptr);
 
return EFI_EXIT(r);
 }
@@ -2332,7 +2332,7 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
 {
EFI_ENTRY("%p", handle);
 
-   va_list argptr;
+   efi_va_list argptr;
const efi_guid_t *protocol;
void *protocol_interface;
efi_status_t r = EFI_SUCCESS;
@@ -2341,12 +2341,12 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
if (!handle)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (;;) {
-   protocol = va_arg(argptr, efi_guid_t*);
+   protocol = efi_va_arg(argptr, efi_guid_t*);
if (!protocol)
break;
-   protocol_interface = va_arg(argptr, void*);
+   protocol_interface = efi_va_arg(argptr, void*);
r = EFI_CALL(efi_uninstall_protocol_interface(
handle, protocol,
protocol_interface));
@@ -2354,20 +2354,20 @@ static efi_status_t EFIAPI 
efi_uninstall_multiple_protocol_interfaces(
break;
i++;
}
-   va_end(argptr);
+   efi_va_end(argptr);
if (r == EFI_SUCCESS)
return EFI_EXIT(r);
 
/* If an error occurred undo all changes. */
-   va_start(argptr, handle);
+   efi_va_start(argptr, handle);
for (; i; --i) {
-   protocol = va_arg(argptr, 

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

[Michal Simek]

On 14.6.2018 16:16, Simon Glass wrote:
> EXTERNAL EMAIL
> 
> 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.

wonderful. Here is the patch for serial and we will check other drivers.

https://lists.denx.de/pipermail/u-boot/2018-June/331932.html

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

[U-Boot] [PATCH] serial: zynq: Use platdata for storing static data instead of priv

[Michal Simek]

Explanation from Simon Glass
"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."

Based on description the driver needs to be switch to use platdata
instead of priv.

Signed-off-by: Michal Simek 
---

Apply on the top of latest zynq serial changes (soon in mainline).

---
 drivers/serial/serial_zynq.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index a191772ff040..f689015b4ae7 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -39,7 +39,7 @@ struct uart_zynq {
u32 baud_rate_divider; /* 0x34 - Baud Rate Divider [7:0] */
 };
 
-struct zynq_uart_priv {
+struct zynq_uart_platdata {
struct uart_zynq *regs;
 };
 
@@ -105,7 +105,7 @@ static int _uart_zynq_serial_putc(struct uart_zynq *regs, 
const char c)
 
 static int zynq_serial_setbrg(struct udevice *dev, int baudrate)
 {
-   struct zynq_uart_priv *priv = dev_get_priv(dev);
+   struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
unsigned long clock;
 
int ret;
@@ -130,28 +130,28 @@ static int zynq_serial_setbrg(struct udevice *dev, int 
baudrate)
return ret;
}
 
-   _uart_zynq_serial_setbrg(priv->regs, clock, baudrate);
+   _uart_zynq_serial_setbrg(platdata->regs, clock, baudrate);
 
return 0;
 }
 
 static int zynq_serial_probe(struct udevice *dev)
 {
-   struct zynq_uart_priv *priv = dev_get_priv(dev);
+   struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
 
/* No need to reinitialize the UART after relocation */
if (gd->flags & GD_FLG_RELOC)
return 0;
 
-   _uart_zynq_serial_init(priv->regs);
+   _uart_zynq_serial_init(platdata->regs);
 
return 0;
 }
 
 static int zynq_serial_getc(struct udevice *dev)
 {
-   struct zynq_uart_priv *priv = dev_get_priv(dev);
-   struct uart_zynq *regs = priv->regs;
+   struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
+   struct uart_zynq *regs = platdata->regs;
 
if (readl(>channel_sts) & ZYNQ_UART_SR_RXEMPTY)
return -EAGAIN;
@@ -161,15 +161,15 @@ static int zynq_serial_getc(struct udevice *dev)
 
 static int zynq_serial_putc(struct udevice *dev, const char ch)
 {
-   struct zynq_uart_priv *priv = dev_get_priv(dev);
+   struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
 
-   return _uart_zynq_serial_putc(priv->regs, ch);
+   return _uart_zynq_serial_putc(platdata->regs, ch);
 }
 
 static int zynq_serial_pending(struct udevice *dev, bool input)
 {
-   struct zynq_uart_priv *priv = dev_get_priv(dev);
-   struct uart_zynq *regs = priv->regs;
+   struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
+   struct uart_zynq *regs = platdata->regs;
 
if (input)
return !(readl(>channel_sts) & ZYNQ_UART_SR_RXEMPTY);
@@ -179,11 +179,11 @@ static int zynq_serial_pending(struct udevice *dev, bool 
input)
 
 static int zynq_serial_ofdata_to_platdata(struct udevice *dev)
 {
-   struct zynq_uart_priv *priv = dev_get_priv(dev);
+   struct zynq_uart_platdata *platdata = dev_get_platdata(dev);
 
-   priv->regs = (struct uart_zynq *)dev_read_addr(dev);
-   if (IS_ERR(priv->regs))
-   return PTR_ERR(priv->regs);
+   platdata->regs = (struct uart_zynq *)dev_read_addr(dev);
+   if (IS_ERR(platdata->regs))
+   return PTR_ERR(platdata->regs);
 
return 0;
 }
@@ -207,7 +207,7 @@ U_BOOT_DRIVER(serial_zynq) = {
.id = UCLASS_SERIAL,
.of_match = zynq_serial_ids,
.ofdata_to_platdata = zynq_serial_ofdata_to_platdata,
-   .priv_auto_alloc_size = sizeof(struct zynq_uart_priv),
+   .platdata_auto_alloc_size = sizeof(struct zynq_uart_platdata),
.probe = zynq_serial_probe,
.ops= _serial_ops,
.flags = DM_FLAG_PRE_RELOC,
-- 
1.9.1

___
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

[Lukasz Majewski]

Hi Janine,

> 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
> 
> Signed-off-by: Janine Hagemann 

Thanks for bringing it into u-boot.

Acked-by: Lukasz Majewski 

> ---
>  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_RGMIIDCTL0x0086
>  #define DP83867_IO_MUX_CFG   0x0170
> @@ -92,11 +93,21 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX  0x0
>  #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN  0x1f
>  
> +/* CFG4 bits */
> +#define DP83867_CFG4_PORT_MIRROR_EN  BIT(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;
>  




Best regards,

Lukasz Majewski

--

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


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

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

[Lukasz Majewski]

Hi Janine,

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

Thanks for bringing it into u-boot.

Acked-by: Lukasz Majewski 

> Signed-off-by: Janine Hagemann 
> ---
>  drivers/net/phy/ti.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
> index 086ea4a..16c8929 100644
> --- a/drivers/net/phy/ti.c
> +++ b/drivers/net/phy/ti.c
> @@ -26,6 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  /* Extended Registers */
>  #define DP83867_CFG4 0x0031
>  #define DP83867_RGMIICTL 0x0032
> +#define DP83867_STRAP_STS1   0x006E
>  #define DP83867_RGMIIDCTL0x0086
>  #define DP83867_IO_MUX_CFG   0x0170
>  
> @@ -50,6 +51,9 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define DP83867_RGMII_TX_CLK_DELAY_ENBIT(1)
>  #define DP83867_RGMII_RX_CLK_DELAY_ENBIT(0)
>  
> +/* STRAP_STS1 bits */
> +#define DP83867_STRAP_STS1_RESERVED  BIT(11)
> +
>  /* PHY CTRL bits */
>  #define DP83867_PHYCR_FIFO_DEPTH_SHIFT   14
>  #define DP83867_PHYCR_FIFO_DEPTH_MASK(3 << 14)
> @@ -251,7 +255,7 @@ static int dp83867_config(struct phy_device
> *phydev) {
>   struct dp83867_private *dp83867;
>   unsigned int val, delay, cfg2;
> - int ret;
> + int ret, bs;
>  
>   if (!phydev->priv) {
>   dp83867 = kzalloc(sizeof(*dp83867), GFP_KERNEL);
> @@ -282,6 +286,24 @@ static int dp83867_config(struct phy_device
> *phydev) 
>   if (ret)
>   goto err_out;
> +
> + /* The code below checks if "port mirroring" N/A
> MODE4 has been
> +  * enabled during power on bootstrap.
> +  *
> +  * Such N/A mode enabled by mistake can put PHY IC
> in some
> +  * internal testing mode and disable RGMII
> transmission.
> +  *
> +  * In this particular case one needs to check
> STRAP_STS1
> +  * register's bit 11 (marked as RESERVED).
> +  */
> +
> + bs = phy_read_mmd_indirect(phydev,
> DP83867_STRAP_STS1,
> + DP83867_DEVADDR,
> phydev->addr);
> + if (bs & DP83867_STRAP_STS1_RESERVED)
> + val &= ~DP83867_PHYCR_RESERVED_MASK;
> +
> + phy_write(phydev, MDIO_DEVAD_NONE,
> MII_DP83867_PHYCTRL, val); +
>   } else if (phy_interface_is_sgmii(phydev)) {
>   phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
> (BMCR_ANENABLE | BMCR_FULLDPLX |
> BMCR_SPEED1000));




Best regards,

Lukasz Majewski

--

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


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