[U-Boot] [PATCH] net: fastboot: Fix build when FASTBOOT_FLASH is disabled
When building without FASTBOOT_FLASH we don't include the intermediate update callback to keep the client alive, so ensure we don't try setting it here. Signed-off-by: Alex Kiernan --- net/fastboot.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/fastboot.c b/net/fastboot.c index a9f7c0743d..8afc5529cd 100644 --- a/net/fastboot.c +++ b/net/fastboot.c @@ -309,7 +309,9 @@ void fastboot_start_server(void) fastboot_our_port = WELL_KNOWN_PORT; +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH) fastboot_set_progress_callback(fastboot_timed_send_info); +#endif net_set_udp_handler(fastboot_handler); /* zero out server ether in case the server ip has changed */ -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] common: print \n in initr_scsi()
Typically init_scsi() does not output anything. So initr_scsi() should
provide a \n or we may see borked output like
SCSI: Net: No ethernet found.
as observed with sandbox_defconfig.
Signed-off-by: Heinrich Schuchardt
---
common/board_r.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/board_r.c b/common/board_r.c
index 6b297068bd..23b5d2c21b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -553,6 +553,7 @@ static int initr_scsi(void)
{
puts("SCSI: ");
scsi_init();
+ puts("\n");
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On 06/14/2018 11:42 PM, Tom Rini wrote: > On Thu, Jun 14, 2018 at 10:58:22PM +0200, Marek Vasut wrote: >> On 06/14/2018 03:07 PM, Tom Rini wrote: >>> On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote: On 06/14/2018 01:19 PM, Tom Rini wrote: > On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote: > >> The following changes since commit >> 813d1fb56dc0af9567feb86cd71c49f14662044b: >> >> Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08 >> 10:08:20 -0400) >> >> are available in the Git repository at: >> >> git://git.denx.de/u-boot-sh.git master >> >> for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9: >> >> ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43 >> +0200) >> > > NAK. First, there are a lot of should be fix style errors in > the new files in drivers/pinctrl/renesas/. Second, you have build > failures: > https://travis-ci.org/trini/u-boot/jobs/391819805 > https://travis-ci.org/trini/u-boot/jobs/391819826 Great, thanks! If the travis didn't vomit constant false positives recently, I'd trust it. With what it does now, I cannot trust it anymore. >>> >>> Can you elaborate? >> >> Don't you see the constant random timeouts during builds for some >> targets? I cannot get a successful build on the first try almost never >> these days, I have to keep restarting until I see that different targets >> failed during each build with a timeout and then extrapolate that the >> build is actually fine from that. It's annoying. > > I see maybe 2-5 of those per day when I'm busy, which is annoying, but > I've never had it fail a second time in a row. Good for you. >> And then there is the other category of boards which indicate "red" >> failure marker due to ie. DT problems, which if you pull DTs from Linux >> is something you cannot really fix on the U-Boot side right away, but >> rather fix in Linux and then resync. > > Yes, there are DT warnings that should be fixed. But they aren't travis > errors, only actual fail to builds (like in the above, which indeed are > confusingly DT related, but not a travis problem at all, I see them > locally too) and new C warnings. I'd prefer to see only errors which are relevant in the logs. Oh well. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] pinctrl: renesas: Sync Gen2 PFC tables with Linux v4.17
Sync the PFC tables with Linux v4.17.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
V2: Fix build errors
drivers/pinctrl/renesas/pfc-r8a7790.c | 8 +-
drivers/pinctrl/renesas/pfc-r8a7791.c | 84 -
drivers/pinctrl/renesas/pfc-r8a7794.c | 473 ++
3 files changed, 559 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/renesas/pfc-r8a7790.c
b/drivers/pinctrl/renesas/pfc-r8a7790.c
index 734df477d3..ad492b5366 100644
--- a/drivers/pinctrl/renesas/pfc-r8a7790.c
+++ b/drivers/pinctrl/renesas/pfc-r8a7790.c
@@ -1825,8 +1825,8 @@ static const unsigned int avb_mii_pins[] = {
RCAR_GP_PIN(2, 2),
RCAR_GP_PIN(2, 7), RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
- RCAR_GP_PIN(2, 10), RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 10),
- RCAR_GP_PIN(3, 12),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(3, 8), RCAR_GP_PIN(3, 9),
+ RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 12),
};
static const unsigned int avb_mii_mux[] = {
AVB_TXD0_MARK, AVB_TXD1_MARK, AVB_TXD2_MARK,
@@ -1836,8 +1836,8 @@ static const unsigned int avb_mii_mux[] = {
AVB_RXD3_MARK,
AVB_RX_ER_MARK, AVB_RX_CLK_MARK, AVB_RX_DV_MARK,
- AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_CLK_MARK,
- AVB_COL_MARK,
+ AVB_CRS_MARK, AVB_TX_EN_MARK, AVB_TX_ER_MARK,
+ AVB_TX_CLK_MARK, AVB_COL_MARK,
};
static const unsigned int avb_gmii_pins[] = {
RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
diff --git a/drivers/pinctrl/renesas/pfc-r8a7791.c
b/drivers/pinctrl/renesas/pfc-r8a7791.c
index 4305589697..0b6a1b0c1d 100644
--- a/drivers/pinctrl/renesas/pfc-r8a7791.c
+++ b/drivers/pinctrl/renesas/pfc-r8a7791.c
@@ -4146,6 +4146,32 @@ static const unsigned int ssi9_ctrl_b_mux[] = {
SSI_SCK9_B_MARK, SSI_WS9_B_MARK,
};
+/* - TPU
*/
+static const unsigned int tpu_to0_pins[] = {
+ RCAR_GP_PIN(6, 14),
+};
+static const unsigned int tpu_to0_mux[] = {
+ TPU_TO0_MARK,
+};
+static const unsigned int tpu_to1_pins[] = {
+ RCAR_GP_PIN(1, 17),
+};
+static const unsigned int tpu_to1_mux[] = {
+ TPU_TO1_MARK,
+};
+static const unsigned int tpu_to2_pins[] = {
+ RCAR_GP_PIN(1, 18),
+};
+static const unsigned int tpu_to2_mux[] = {
+ TPU_TO2_MARK,
+};
+static const unsigned int tpu_to3_pins[] = {
+ RCAR_GP_PIN(1, 24),
+};
+static const unsigned int tpu_to3_mux[] = {
+ TPU_TO3_MARK,
+};
+
/* - USB0 ---
*/
static const unsigned int usb0_pins[] = {
RCAR_GP_PIN(7, 23), /* PWEN */
@@ -4432,7 +4458,7 @@ static const unsigned int vin2_clk_mux[] = {
};
static const struct {
- struct sh_pfc_pin_group common[342];
+ struct sh_pfc_pin_group common[346];
struct sh_pfc_pin_group r8a779x[9];
} pinmux_groups = {
.common = {
@@ -4744,6 +4770,10 @@ static const struct {
SH_PFC_PIN_GROUP(ssi9_data_b),
SH_PFC_PIN_GROUP(ssi9_ctrl),
SH_PFC_PIN_GROUP(ssi9_ctrl_b),
+ SH_PFC_PIN_GROUP(tpu_to0),
+ SH_PFC_PIN_GROUP(tpu_to1),
+ SH_PFC_PIN_GROUP(tpu_to2),
+ SH_PFC_PIN_GROUP(tpu_to3),
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
VIN_DATA_PIN_GROUP(vin0_data, 24),
@@ -4827,6 +4857,10 @@ static const char * const can0_groups[] = {
"can0_data_d",
"can0_data_e",
"can0_data_f",
+ /*
+* Retained for backwards compatibility, use can_clk_groups in new
+* designs.
+*/
"can_clk",
"can_clk_b",
"can_clk_c",
@@ -4838,6 +4872,21 @@ static const char * const can1_groups[] = {
"can1_data_b",
"can1_data_c",
"can1_data_d",
+ /*
+* Retained for backwards compatibility, use can_clk_groups in new
+* designs.
+*/
+ "can_clk",
+ "can_clk_b",
+ "can_clk_c",
+ "can_clk_d",
+};
+
+/*
+ * can_clk_groups allows for independent configuration, use can_clk function
+ * in new designs.
+ */
+static const char * const can_clk_groups[] = {
"can_clk",
"can_clk_b",
"can_clk_c",
@@ -5260,6 +5309,13 @@ static const char * const ssi_groups[] = {
"ssi9_ctrl_b",
};
+static const char * const tpu_groups[] = {
+ "tpu_to0",
+ "tpu_to1",
+ "tpu_to2",
+ "tpu_to3",
+};
+
static const char * const usb0_groups[] = {
"usb0",
};
@@ -5309,7 +5365,7 @@ static const char * const vin2_groups[] = {
};
static const struct {
- struct sh_pfc_function common[56];
+ struct sh_pfc_function common[58];
struct sh_pfc_function r8a779x[2];
} pinmux_functions = {
.common = {
@@ -5317,6 +5373,7 @@ static const struct {
SH_PFC_FUNCTION(avb),
SH_PFC_FUNCTION(can0),
SH_PFC_FUNCTION(can1),
+
[U-Boot] [PATCH 1/1] efi_selftest: update .gitignore
The following generated files should be ignored by git: efi_miniapp_file_image_exit.h efi_miniapp_file_image_return.h *.so files are normally deleted during the build but should be ignored too. Signed-off-by: Heinrich Schuchardt --- lib/efi_selftest/.gitignore | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_selftest/.gitignore b/lib/efi_selftest/.gitignore index c527e464e5..293a17b818 100644 --- a/lib/efi_selftest/.gitignore +++ b/lib/efi_selftest/.gitignore @@ -1,2 +1,4 @@ -efi_miniapp_file_image.h +efi_miniapp_file_image_exit.h +efi_miniapp_file_image_return.h *.efi +*.so -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y
On 06/14/2018 10:50 PM, Mark Kettenis wrote: >> From: Heinrich Schuchardt >> Date: Thu, 14 Jun 2018 19:55:51 +0200 >> >> On 06/14/2018 12:41 AM, Mark Kettenis wrote: >>> This series makes it possible to run EFI applications in non-secure >>> mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and >>> Banana Pi boards using the PSCI implementation provided by U-Boot. >>> >>> The second version avoids using r3 to pass the original stack pointer. >>> For some reason that register gets clobbered on the Banana Pi. Instead >>> this version just migrates SP_svc to SP_hyp. >>> >>> This third version avoids saving r3 on the stack and fixes an include >>> guard as suggested by Alexander Graf. >>> >>> Mark Kettenis (3): >>> ARM: HYP/non-sec: migrate stack >>> efi_loader: ARM: run EFI payloads non-secure >>> Revert "efi_loader: no support for ARMV7_NONSEC=y" >>> >>> arch/arm/cpu/armv7/nonsec_virt.S | 2 ++ >>> cmd/bootefi.c| 32 >>> doc/README.uefi | 2 -- >>> lib/efi_loader/Kconfig | 2 -- >>> 4 files changed, 34 insertions(+), 4 deletions(-) >>> >> Hello Mark, >> >> with this patch series running bootefi hello twice in sequence fails on >> the BananaPi. >> >> => bootefi hello >> Scanning disk m...@01c0f000.blk... >> Found 3 disks >> WARNING: booting without device tree >> ## Starting EFI application at 4200 ... >> WARNING: using memory device/image path, this may confuse some payloads! >> Hello, world! >> Running on UEFI 2.7 >> Have SMBIOS table >> Load options: earlyprintk nosmp >> ## Application terminated, r = 0 >> => bootefi hello >> WARNING: booting without device tree >> ## Starting EFI application at 4200 ... >> WARNING: using memory device/image path, this may confuse some payloads! >> > > Yeah. Trying to enter non-secure mode when we're already in > non-secure mode doesn't really work. We should skip the switching > code in that case. Now checking whether we are in non-secure mode > isn't really possible. But I guess we can set a variable and check it > before we go down the switching codepath. With that in I can exit the > OpenBSD bootloader and then reload and run it again. I'll include > that fix in the next respin. Hello Mark, you might move the call to switch to non-secure mode to efi_init_obj_list(). Best regards Heinrich > >> Please, keep in mind that we expect multiple EFI binaries to be executed >> in sequence. E.g. the first binary installs a driver. The second is the >> application using it. >> >> Running iPXE's snp.efi binary shows changed behavior on the console. New >> characters are displayed in "slow motion" (3 characters per second). >> Setting up the network interface fails in iPXE. > > The same happens on my Banana Pi. But not on the imx7 board. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC] sandbox: Enable 1:1 map
So far we've always had a split address space situation with
"U-Boot addresses" (a number space starting from 0) and "host
virtual addresses" (128MB mapped randomly in address space).
This meant that we had to make sure all code is properly aware that
addresses and pointers are not the same thing, so they must not cast
between the two.
However, most real boards do actually have a 1:1 map. So it's
much easier to just expose the same in sandbox.
So this patch maps sandbox RAM from 0x800-0x1000. This
address range fits just fine on both 32bit and 64bit systems.
---
The patch is on top of my "efi-sandbox-v3" tree. But I'm sure
it easily applies on vanilla too.
I also don't know if this really is the best path forward, but
at least it's one that gets rid of the one awkward target that
does not have a 1:1 map ;)
---
arch/sandbox/cpu/cpu.c | 18 ++
arch/sandbox/cpu/state.c | 4 ++--
arch/sandbox/cpu/u-boot.lds| 3 +++
arch/sandbox/include/asm/io.h | 17 +
common/board_f.c | 4 +++-
configs/sandbox64_defconfig| 6 +++---
configs/sandbox_defconfig | 6 +++---
configs/sandbox_flattree_defconfig | 4 ++--
configs/sandbox_noblk_defconfig| 4 ++--
configs/sandbox_spl_defconfig | 4 ++--
include/configs/sandbox.h | 22 +++---
11 files changed, 38 insertions(+), 54 deletions(-)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 23d8b70648..5f5d6c9158 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -58,16 +58,6 @@ int cleanup_before_linux_select(int flags)
return 0;
}
-void *phys_to_virt(phys_addr_t paddr)
-{
- return (void *)(gd->arch.ram_buf + paddr);
-}
-
-phys_addr_t virt_to_phys(void *vaddr)
-{
- return (phys_addr_t)((uint8_t *)vaddr - gd->arch.ram_buf);
-}
-
void *map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags)
{
#if defined(CONFIG_PCI) && !defined(CONFIG_SPL_BUILD)
@@ -103,11 +93,6 @@ void sandbox_set_enable_pci_map(int enable)
enable_pci_map = enable;
}
-phys_addr_t map_to_sysmem(const void *ptr)
-{
- return (u8 *)ptr - gd->arch.ram_buf;
-}
-
void flush_dcache_range(unsigned long start, unsigned long stop)
{
}
@@ -187,7 +172,8 @@ void longjmp(jmp_buf jmp, int ret)
*/
void efi_add_known_memory(void)
{
- u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
+ u64 ram_start = (uintptr_t)map_sysmem(CONFIG_SYS_SDRAM_BASE,
+ gd->ram_size);
u64 ram_size = gd->ram_size;
u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index cc50819ab9..75ad564274 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -12,6 +12,7 @@
/* Main state record for the sandbox */
static struct sandbox_state main_state;
static struct sandbox_state *state;/* Pointer to current state record */
+static __attribute__ ((section (".ram"))) u8
sandbox_ram[CONFIG_SYS_SDRAM_SIZE];
static int state_ensure_space(int extra_size)
{
@@ -366,8 +367,7 @@ int state_init(void)
state = _state;
state->ram_size = CONFIG_SYS_SDRAM_SIZE;
- state->ram_buf = os_malloc(state->ram_size);
- assert(state->ram_buf);
+ state->ram_buf = sandbox_ram;
state_reset_for_test(state);
/*
diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 3a6cf55eb9..8d0dfadfe0 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -47,6 +47,9 @@ SECTIONS
*(.__efi_runtime_rel_stop)
}
+ .ram 0x800 : {
+ *(.ram)
+ }
}
INSERT BEFORE .data;
diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index 81b7750628..fe792200a7 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -6,12 +6,6 @@
#ifndef __SANDBOX_ASM_IO_H
#define __SANDBOX_ASM_IO_H
-void *phys_to_virt(phys_addr_t paddr);
-#define phys_to_virt phys_to_virt
-
-phys_addr_t virt_to_phys(void *vaddr);
-#define virt_to_phys virt_to_phys
-
void *map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags);
#define map_physmem map_physmem
@@ -23,20 +17,19 @@ void unmap_physmem(const void *vaddr, unsigned long flags);
#include
-/* For sandbox, we want addresses to point into our RAM buffer */
static inline void *map_sysmem(phys_addr_t paddr, unsigned long len)
{
- return map_physmem(paddr, len, MAP_WRBACK);
+ return (void *)(unsigned long)paddr;
}
-/* Remove a previous mapping */
static inline void unmap_sysmem(const void *vaddr)
{
- unmap_physmem(vaddr, MAP_WRBACK);
}
-/* Map from a pointer to our RAM buffer */
-phys_addr_t map_to_sysmem(const void *ptr);
+static inline phys_addr_t
Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()
On 14.06.18 23:35, Simon Glass wrote: > Hi Alex, > > On 14 June 2018 at 13:51, Alexander Graf wrote: >> >> >> On 14.06.18 21:01, Simon Glass wrote: >>> On 14 June 2018 at 12:22, Alexander Graf wrote: The fs_read() function wants to get an address rather than the pointer to a buffer. So let's convert the passed buffer from pointer back a the address to make efi_loader on sandbox happier. Signed-off-by: Alexander Graf --- v1 -> v2: - Clarify address vs pointer - include mapmem.h --- lib/efi_loader/efi_file.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> Reviewed-by: Simon Glass >>> >> >> I actually think that this patch tackles the problem the wrong way >> around. I've cooked up another one that converts fs_read() and >> fs_write() to instead take a pointer - which really is what most users >> of the API want in the first place: >> >> >> https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f > > Actually this is a pretty good exposition of why we don't want to use > pointers everywhere. U-Boot uses addresses all over the place. Even a > search for something as specific as "ulong addr" gets over 200 > matches. If we go down this path we will end up changing a pretty > fundamental part of U-Boot, and I don't think it is a good idea to do > that. Addresses are easy to understand, can be added/subtracted > without pointer arithmetic, can be easily converted to pointers as > needed, can be 32-bits long on sandbox, etc. I tend to disagree with this. Most code in U-Boot actually consumes pointers rather than addresses. > So I think we should step back from the abyss here and stick with the > way sandbox currently deals with addresses. It works well, is pretty > easy to understand, allows debugging which is just as easy on sandbox > as other archs (since they both uses addresses until basically the > final access), the addresses are typically small values that start at > 0 which much is easier to read than (e.g.) 7f1b58c8b008. > > Here for example is the output from starting U-Boot with debugging in > board_f.c (something I have turned on a lot when refactoring and > debugging the init sequence): > > U-Boot 2018.07-rc1-00142-g134ea86c7f-dirty (Jun 14 2018 - 15:04:04 -0600) > > DRAM: Monitor len: 00395AB0 > Ram size: 0800 > Ram top: 0800 > Reserving 3670k for U-Boot at: 07c6a000 > Reserving 32776k for malloc() at: 05c68000 > Reserving 120 Bytes for Board Info at: 05c67f88 > Reserving 472 Bytes for Global Data at: 05c67db0 > Reserving 4352 Bytes for FDT at: 05c66cb0 > Reserving 0x3c8 Bytes for bootstage at: 05c668e8 > > RAM Configuration: > Bank #0: 0 128 MiB > > DRAM: 128 MiB > New Stack Pointer is: 05c668d0 > Copying bootstage from 7fdb0056e038 to 7fdb061c48f0, size 3c8 > Relocation Offset is: 07c6a000 > Relocating to 07c6a000, new gd at 05c67db0, sp at 05c668d0 > > > If we use pointers we get things like this: > > Reserving 3670k for U-Boot at: 7f1b58c8b008 > > I just don't want to deal with 64-bit addresses when debugging things, > and there really is no point. The map_sysmem() function provides a > nice and easy way to cast an address to a pointer, and it works on all > architectures. Ok, circling back to square 1. The main issue we're facing here is that most code in U-Boot does not really understand the difference between virtual and physical addresses - it just simply assumes a 1:1 map. With sandbox, we do not have a 1:1 map anymore - any address is somewhere else than its pointer. We have a few options: 1) Deal with pointers at random addresses throughout the code I can see why you don't want this. I find ASLR generated addresses quite cumbersome to read as well. 2) Explicitly map RAM at VA 0x1000, then do 1:1 map This would be the best of all worlds still IMHO. That way we will have easily readable addresses (that are identical in 32bit and 64bit), but can still do a 1:1 map. The only thing we need to do is to introduce a linker section at 0x1000. 3) Keep converting addresses to pointers I'm afraid if we follow this path, we will always have arguments on where the correct boundaries are. If you start to enable debugging in core dm code and print out pointers to your dm objects, you will get pointer values today as well. Sooner or later we will always end up with pointers. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Thu, Jun 14, 2018 at 10:58:22PM +0200, Marek Vasut wrote: > On 06/14/2018 03:07 PM, Tom Rini wrote: > > On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote: > >> On 06/14/2018 01:19 PM, Tom Rini wrote: > >>> On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote: > >>> > The following changes since commit > 813d1fb56dc0af9567feb86cd71c49f14662044b: > > Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08 > 10:08:20 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9: > > ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43 > +0200) > > >>> > >>> NAK. First, there are a lot of should be fix style errors in > >>> the new files in drivers/pinctrl/renesas/. Second, you have build > >>> failures: > >>> https://travis-ci.org/trini/u-boot/jobs/391819805 > >>> https://travis-ci.org/trini/u-boot/jobs/391819826 > >> > >> Great, thanks! > >> > >> If the travis didn't vomit constant false positives recently, I'd trust > >> it. With what it does now, I cannot trust it anymore. > > > > Can you elaborate? > > Don't you see the constant random timeouts during builds for some > targets? I cannot get a successful build on the first try almost never > these days, I have to keep restarting until I see that different targets > failed during each build with a timeout and then extrapolate that the > build is actually fine from that. It's annoying. I see maybe 2-5 of those per day when I'm busy, which is annoying, but I've never had it fail a second time in a row. > And then there is the other category of boards which indicate "red" > failure marker due to ie. DT problems, which if you pull DTs from Linux > is something you cannot really fix on the U-Boot side right away, but > rather fix in Linux and then resync. Yes, there are DT warnings that should be fixed. But they aren't travis errors, only actual fail to builds (like in the above, which indeed are confusingly DT related, but not a travis problem at all, I see them locally too) and new C warnings. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARC: HSDK: Add readme
Signed-off-by: Alexey Brodkin --- board/synopsys/hsdk/README | 121 + 1 file changed, 121 insertions(+) create mode 100644 board/synopsys/hsdk/README diff --git a/board/synopsys/hsdk/README b/board/synopsys/hsdk/README new file mode 100644 index ..e3793e48298f --- /dev/null +++ b/board/synopsys/hsdk/README @@ -0,0 +1,121 @@ + +Useful notes on bulding and using of U-Boot on ARC HS Development Kit (AKA HSDK) + + + BOARD OVERVIEW + + The DesignWare ARC HS Development Kit is a ready-to-use platform for rapid + software development on the ARC HS3x family of processors. + + For more information please visit: + https://www.synopsys.com/dw/ipdir.php?ds=arc-hs-development-kit + + User guide is availalble here: + https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/wiki/docs/ARC_HSDK_User_Guide.pdf + + It has the following features useful for U-Boot: +* On-board 2-channel FTDI TTL-to-USB converter + - The first channel is used for serial debug port (which makes it possible +to use a serial connection on pretty much any host machine be it +Windows, Linux or Mac). +On Linux machine typucally FTDI serial port would be /dev/ttyUSB0. +There's no HW flow-control and baud-rate is 115200. + + - The second channel is used for built-in Digilent USB JTAG probe. +That means no extra hardware is required to access ARC core from a +debugger on development host. Both proprietary MetaWare debugger and +open source OpenOCD + GDB client are supported. + + - Also with help of this FTDI chip it is possible to reset entire +board with help of a special `rff-ftdi-reset` utility, see: +https://github.com/foss-for-synopsys-dwc-arc-processors/rff-ftdi-reset + +* Micro SD-card slot + - U-Boot expects to see the very first partition on the card formatted as +FAT file-system and uses it for keeping its environment in `uboot.env` +file. Note uboot.env is not just a text file but it is auto-generated +file created by U-Boot on invocation of `saveenv` command. +It contains a checksum which makes this saved environment invalid in +case of maual modification. + + - There might be more useful files on that first FAT partition like +Linux kernl image in form of uImage (with or without built-in +initramfs), device tree blob (.dtb) etc. + + - Except FAT partition there might be others following the first FAT one +like Ext file-system with rootfs etc. + +* 1 Gb Ethernet socket + - U-Boot might get payload from TFTP server. This might be uImage, rootfs +image and anything else. + +* 2 MiB of SPI-flash + - SPI-flahs is used as a storage for image of an application auto-executed +by bootROM on power-on. Typically U-Boot gets programmed there but +there might be other uses. But note bootROM expects to find a special +header preceeding application image itself so before flashing anything +make sure required image is prepended. In case of U-Boot this is done +by invocation of `headerize-hsdk.py` with `make bsp-generate` command. + + + BUILDING U-BOOT + + 1. Configure U-Boot: + ->8-- + make hsdk_defconfig + ->8-- + + 2. To build Elf file (for example to be used with host debugger via JTAG + connection to the target board): + ->8-- + make mdbtrick + ->8-- + + This will produce `u-boot` Elf file. + + 3. To build artifacts required for U-Boot update in n-board SPI-flash: + ->8-- + make bsp-generate + ->8-- + + This will produce `u-boot.head` and `u-boot-update.scr` which should + be put on the first FAT partition of micro SD-card to be inserted in the + HSDK board. + + + EXECUTING U-BOOT + + 1. The HSDK board is supposed to auto-start U-Boot image stored in on-board + SPI-flash on power-on. For that make sure DIP-switches in the corner of + the board are in their default positions: BIM in 1:off, 2:on state + while both BMC and BCS should be in 1:on, 2:on state. + + 2. Though it is possible to load U-Boot as a simple Elf file via JTAG right + in DDR and start it from the debugger. + + 2.1. In case of proprietary MetaWare debugger run: + ->8-- + mdb -digilent -run -cl u-boot + ->8-- + + + UPDATION
Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader
Hi Alex, On 14 June 2018 at 13:15, Alexander Graf wrote: > > > On 14.06.18 21:02, Simon Glass wrote: >> Hi Alex, >> >> On 14 June 2018 at 12:22, Alexander Graf wrote: >>> With efi_loader we do not control payload applications, so we can not >>> teach them about the difference between virtual and physical addresses. >>> >>> Instead, let's just always map host virtual addresses in the efi memory >>> map. That way we can be sure that all memory allocation functions always >>> return consumable pointers. >>> >>> Signed-off-by: Alexander Graf >>> >>> --- >>> >>> v1 -> v2: >>> >>> - only compile efi_add_known_memory if efi_loader is enabled >>> --- >>> arch/sandbox/cpu/cpu.c | 20 >>> 1 file changed, 20 insertions(+) >> >> NAK. >> >> You should not point sandbox pointers into the EFI tables. I know it >> looks like a clever shortcut, but it is not correct. It will mess up >> logging and debugging, since those pointers bear no easily accessible >> relationship to U-Boot address. >> >> Please start from my v7 patch. I'm happy to help do this correctly. >> But, again, I think it should come after we have basic sandbox EFI >> support applied. > > I don't want to play ping pong with you here. NAK on your approach until > I see it properly executing selftest. I think you just did :-) But if you are asking for me to pull together a patch that gets that far, then OK. I can see that you are not convinced it would work, or be easy to follow, and I have not proven that yet. I was just hoping to take things in incremental steps since this has been outstanding for so long. > > So either we drive this forward or we don't. Your choice. I have long wanted EFI to fall into the sandbox testing framework, so that e.g. 'make tests' will quickly run the EFI tests. I don't think we are too far away. It doesn't have to happen immediately, but I predict that when we get it working, we won't look back. It will be much more convenient than running a separate app or testing on 'real hardware' and you can set up quite complicated things with it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] spl: Add option SPL_PAYLOAD
Some legacy boards use RAW image for SPL boot. Add Kconfig option SPL_PAYLOAD to set alternative image. Signed-off-by: York Sun --- Makefile | 4 ++-- common/spl/Kconfig | 10 ++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 6a190e7..36459f1 100644 --- a/Makefile +++ b/Makefile @@ -1115,8 +1115,8 @@ u-boot.sha1: u-boot.bin u-boot.dis:u-boot $(OBJDUMP) -d $< > $@ -ifdef CONFIG_TPL -SPL_PAYLOAD := tpl/u-boot-with-tpl.bin +ifneq ($(CONFIG_SPL_PAYLOAD),) +SPL_PAYLOAD := $(CONFIG_SPL_PAYLOAD:"%"=%) else SPL_PAYLOAD := u-boot.bin endif diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 1f14797..72b77d7 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -552,6 +552,16 @@ config SYS_OS_BASE endif # SPL_OS_BOOT +config SPL_PAYLOAD + string "SPL payload" + default "tpl/u-boot-with-tpl.bin" if TPL + default "u-boot.bin" + help + Payload for SPL boot. For backward compability, default to + u-boot.bin, i.e. RAW image without any header. In case of + TPL, tpl/u-boot-with-tpl.bin. For new boards, suggest to + use u-boot.img. + config SPL_PCI_SUPPORT bool "Support PCI drivers" help -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader
Hi Heinrich, On 14 June 2018 at 13:21, Heinrich Schuchardt wrote: > On 06/14/2018 09:02 PM, Simon Glass wrote: >> Hi Alex, >> >> On 14 June 2018 at 12:22, Alexander Graf wrote: >>> With efi_loader we do not control payload applications, so we can not >>> teach them about the difference between virtual and physical addresses. >>> >>> Instead, let's just always map host virtual addresses in the efi memory >>> map. That way we can be sure that all memory allocation functions always >>> return consumable pointers. >>> >>> Signed-off-by: Alexander Graf >>> >>> --- >>> >>> v1 -> v2: >>> >>> - only compile efi_add_known_memory if efi_loader is enabled >>> --- >>> arch/sandbox/cpu/cpu.c | 20 >>> 1 file changed, 20 insertions(+) >> >> NAK. >> >> You should not point sandbox pointers into the EFI tables. I know it >> looks like a clever shortcut, but it is not correct. It will mess up >> logging and debugging, since those pointers bear no easily accessible >> relationship to U-Boot address. > > Hello Simon, > > why do we need this Babylonic confusion of addresses which do not point > to valid memory and pointers that are not valid addresses where > everybody is getting lost? > > Simply use only addresses with there mmap'ed values and get rid of all > conversions. Use your board file to adjust kernel_addr_r and the like to > the address range that Linux offered you. No one is getting lost. It has been working fine for a long time. Sandbox was introduced almost 7 years ago. It has been a huge benefit in terms of productivity and testing. We are not necessarily running on Linux, but in any case, we get ugly addresses which expose the underlying machine architecture, which is not relevant for tests, and just introduces confusion. Sandbox is intended to be pure U-Boot, just like you might boot up on a 32-bit ARM or x86 machine. The conversions existing in any case, since we must case between addresses and pointers. This just makes it explicit in a convenient, type-safe manner. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()
Hi Alex, On 14 June 2018 at 13:51, Alexander Graf wrote: > > > On 14.06.18 21:01, Simon Glass wrote: >> On 14 June 2018 at 12:22, Alexander Graf wrote: >>> The fs_read() function wants to get an address rather than the >>> pointer to a buffer. >>> >>> So let's convert the passed buffer from pointer back a the address >>> to make efi_loader on sandbox happier. >>> >>> Signed-off-by: Alexander Graf >>> >>> --- >>> >>> v1 -> v2: >>> >>> - Clarify address vs pointer >>> - include mapmem.h >>> --- >>> lib/efi_loader/efi_file.c | 5 - >>> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> Reviewed-by: Simon Glass >> > > I actually think that this patch tackles the problem the wrong way > around. I've cooked up another one that converts fs_read() and > fs_write() to instead take a pointer - which really is what most users > of the API want in the first place: > > > https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f Actually this is a pretty good exposition of why we don't want to use pointers everywhere. U-Boot uses addresses all over the place. Even a search for something as specific as "ulong addr" gets over 200 matches. If we go down this path we will end up changing a pretty fundamental part of U-Boot, and I don't think it is a good idea to do that. Addresses are easy to understand, can be added/subtracted without pointer arithmetic, can be easily converted to pointers as needed, can be 32-bits long on sandbox, etc. So I think we should step back from the abyss here and stick with the way sandbox currently deals with addresses. It works well, is pretty easy to understand, allows debugging which is just as easy on sandbox as other archs (since they both uses addresses until basically the final access), the addresses are typically small values that start at 0 which much is easier to read than (e.g.) 7f1b58c8b008. Here for example is the output from starting U-Boot with debugging in board_f.c (something I have turned on a lot when refactoring and debugging the init sequence): U-Boot 2018.07-rc1-00142-g134ea86c7f-dirty (Jun 14 2018 - 15:04:04 -0600) DRAM: Monitor len: 00395AB0 Ram size: 0800 Ram top: 0800 Reserving 3670k for U-Boot at: 07c6a000 Reserving 32776k for malloc() at: 05c68000 Reserving 120 Bytes for Board Info at: 05c67f88 Reserving 472 Bytes for Global Data at: 05c67db0 Reserving 4352 Bytes for FDT at: 05c66cb0 Reserving 0x3c8 Bytes for bootstage at: 05c668e8 RAM Configuration: Bank #0: 0 128 MiB DRAM: 128 MiB New Stack Pointer is: 05c668d0 Copying bootstage from 7fdb0056e038 to 7fdb061c48f0, size 3c8 Relocation Offset is: 07c6a000 Relocating to 07c6a000, new gd at 05c67db0, sp at 05c668d0 If we use pointers we get things like this: Reserving 3670k for U-Boot at: 7f1b58c8b008 I just don't want to deal with 64-bit addresses when debugging things, and there really is no point. The map_sysmem() function provides a nice and easy way to cast an address to a pointer, and it works on all architectures. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] vboot: Do not use hashed-strings offset
On 9 June 2018 at 09:45, Teddy Reed wrote: > The hashed-strings signature property includes two uint32_t values. > The first is unneeded as there should never be a start offset into the > strings region. The second, the size, is needed because the added > signature node appends to this region. > > See tools/image-host.c, where a static 0 value is used for the offset. > > Signed-off-by: Teddy Reed > --- > common/image-sig.c | 7 +-- > tools/image-host.c | 1 + > 2 files changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/9] clk: Add Actions Semi OWL clock support
On 14 June 2018 at 12:08, Manivannan Sadhasivam wrote: > This commit adds Actions Semi OWL family base clock and S900 SoC specific > clock support. For S900 peripheral clock support, only UART clock has been > added for now. > > Signed-off-by: Manivannan Sadhasivam > --- > > Changes in v3: > > * Moved the change log from cover letter > > Changes in v2: > > * Removed clk_owl.c and moved all clk code to clk_s900.c as per Simon's > review comments. > * Moved arch/arm/mach-owl/Kconfig changes to board support patch. > > arch/arm/include/asm/arch-owl/clk_s900.h | 57 + > arch/arm/include/asm/arch-owl/regs_s900.h | 64 ++ > drivers/clk/Kconfig | 1 + > drivers/clk/Makefile | 1 + > drivers/clk/owl/Kconfig | 12 ++ > drivers/clk/owl/Makefile | 3 + > drivers/clk/owl/clk_s900.c| 138 ++ > 7 files changed, 276 insertions(+) > create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h > create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h > create mode 100644 drivers/clk/owl/Kconfig > create mode 100644 drivers/clk/owl/Makefile > create mode 100644 drivers/clk/owl/clk_s900.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] serial: Add Actions Semi OWL UART support
On 14 June 2018 at 12:08, Manivannan Sadhasivam wrote: > This commit adds Actions Semi OWL family UART support. This driver > relies on baudrate configured by primary bootloaders. > > Signed-off-by: Manivannan Sadhasivam > --- > > Changes in v3: > > * Moved the change log from cover letter > > Changes in v2: None > > drivers/serial/Kconfig | 8 +++ > drivers/serial/Makefile | 1 + > drivers/serial/serial_owl.c | 136 > 3 files changed, 145 insertions(+) > create mode 100644 drivers/serial/serial_owl.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/9] dt-bindings: clock: Add S900 CMU register definitions
On 14 June 2018 at 12:08, Manivannan Sadhasivam wrote: > This commit adds Actions Semi S900 CMU register definitions to clock > bindings. > > Signed-off-by: Manivannan Sadhasivam > --- > > Changes in v3: > > * Moved the change log from cover letter > > Changes in v2: > > * Added missing Signed-off-by tag > > include/dt-bindings/clock/s900_cmu.h | 77 > 1 file changed, 77 insertions(+) > create mode 100644 include/dt-bindings/clock/s900_cmu.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] patman: Support using a particular SMTP server
Some environments require providing the '--smtp-server' argument to
'git send-email'. Add support for this.
Signed-off-by: Simon Glass
---
tools/patman/README | 1 +
tools/patman/gitutil.py | 6 +-
tools/patman/patman.py | 5 -
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/patman/README b/tools/patman/README
index 606780e2ed..7917fc8bdc 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -107,6 +107,7 @@ patman.py. For reference, the useful ones (at the moment)
shown below
ignore_errors: True
process_tags: False
verbose: True
+smtp_server: /path/to/sendmail
<<<
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 64ac0c8d3d..9905bb0bbd 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -332,7 +332,8 @@ def BuildEmailList(in_list, tag=None, alias=None,
raise_on_error=True):
return result
def EmailPatches(series, cover_fname, args, dry_run, raise_on_error, cc_fname,
-self_only=False, alias=None, in_reply_to=None, thread=False):
+self_only=False, alias=None, in_reply_to=None, thread=False,
+smtp_server=None):
"""Email a patch series.
Args:
@@ -348,6 +349,7 @@ def EmailPatches(series, cover_fname, args, dry_run,
raise_on_error, cc_fname,
Should be a message ID that this is in reply to.
thread: True to add --thread to git send-email (make
all patches reply to cover-letter or first patch in series)
+smtp_server: SMTP server to use to send patches
Returns:
Git command that was/would be run
@@ -405,6 +407,8 @@ def EmailPatches(series, cover_fname, args, dry_run,
raise_on_error, cc_fname,
to = BuildEmailList([os.getenv('USER')], '--to', alias, raise_on_error)
cc = []
cmd = ['git', 'send-email', '--annotate']
+if smtp_server:
+cmd.append('--smtp-server=%s' % smtp_server)
if in_reply_to:
if type(in_reply_to) != str:
in_reply_to = in_reply_to.encode('utf-8')
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index 8d2c78235a..143d09e004 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -60,6 +60,8 @@ parser.add_option('--no-check', action='store_false',
dest='check_patch',
help="Don't check for patch compliance")
parser.add_option('--no-tags', action='store_false', dest='process_tags',
default=True, help="Don't process subject tags as aliaes")
+parser.add_option('--smtp-server', type='str',
+ help="Specify the SMTP server to 'get send-email'")
parser.add_option('-T', '--thread', action='store_true', dest='thread',
default=False, help='Create patches as a single thread')
@@ -165,7 +167,8 @@ else:
if its_a_go:
cmd = gitutil.EmailPatches(series, cover_fname, args,
options.dry_run, not options.ignore_bad_tags, cc_file,
-in_reply_to=options.in_reply_to, thread=options.thread)
+in_reply_to=options.in_reply_to, thread=options.thread,
+smtp_server=options.smtp_server)
else:
print(col.Color(col.RED, "Not sending emails due to errors/warnings"))
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 2/2] powerpc: mpc85xx: Drop u-boot-with-spl.bin on selected boards
For SoCs with PBL, u-boot-with-spl-pbl.bin is the final image for SPL boot. Drop unused u-boot-with-spl.bin. Signed-off-by: York Sun CC: Ashish Kumar CC: Ruchika Gupta CC: Priyanka Jain CC: Shengzhou Liu --- include/configs/B4860QDS.h | 1 - include/configs/T102xQDS.h | 1 - include/configs/T102xRDB.h | 1 - include/configs/T104xRDB.h | 1 - include/configs/T208xQDS.h | 1 - include/configs/T208xRDB.h | 1 - include/configs/T4240QDS.h | 1 - include/configs/T4240RDB.h | 1 - 8 files changed, 8 deletions(-) diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index 1c67153..eb7c964 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -17,7 +17,6 @@ #define CONFIG_RESET_VECTOR_ADDRESS0xfffc #else #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h index e457135..7b70ccf 100644 --- a/include/configs/T102xQDS.h +++ b/include/configs/T102xQDS.h @@ -30,7 +30,6 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t102xqds/t1024_pbi.cfg #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h index 07ba1cf..9130d3f 100644 --- a/include/configs/T102xRDB.h +++ b/include/configs/T102xRDB.h @@ -33,7 +33,6 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t102xrdb/t1024_pbi.cfg #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index f34f518..5e77acf 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -21,7 +21,6 @@ #endif #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index f5d454b..8539d06 100644 --- a/include/configs/T208xQDS.h +++ b/include/configs/T208xQDS.h @@ -37,7 +37,6 @@ #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t208xqds/t208x_pbi.cfg #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h index 934e6e4..eb746fe 100644 --- a/include/configs/T208xRDB.h +++ b/include/configs/T208xRDB.h @@ -31,7 +31,6 @@ #define CONFIG_SYS_FSL_PBL_PBI board/freescale/t208xrdb/t2080_pbi.cfg #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T4240QDS.h b/include/configs/T4240QDS.h index 9714e44..804d41b 100644 --- a/include/configs/T4240QDS.h +++ b/include/configs/T4240QDS.h @@ -21,7 +21,6 @@ #define CONFIG_RESET_VECTOR_ADDRESS 0xfffc #else #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h index 43ae309..5df2d18 100644 --- a/include/configs/T4240RDB.h +++ b/include/configs/T4240RDB.h @@ -21,7 +21,6 @@ #define CONFIG_RESET_VECTOR_ADDRESS 0xfffc #else #define CONFIG_SPL_FLUSH_IMAGE -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0xFFFD8000 #define CONFIG_SPL_PAD_TO 0x4 #define CONFIG_SPL_MAX_SIZE0x28000 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] armv8: layerscape: Drop u-boot-with-spl.bin for selected boards
For SPL boot with PBL, u-boot-with-spl-pbl.bin is the final image. Drop unused u-boot-with-spl.bin. Signed-off-by: York Sun CC: Mingkai Hu CC: Ruchika Gupta CC: Prabhakar Kushwaha CC: Udit Agarwal CC: Sumit Garg CC: Priyanka Jain --- include/configs/ls1043a_common.h | 2 -- include/configs/ls1046a_common.h | 2 -- include/configs/ls1088a_common.h | 1 - include/configs/ls2080a_common.h | 1 - 4 files changed, 6 deletions(-) diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h index 1faed4e..a5c 100644 --- a/include/configs/ls1043a_common.h +++ b/include/configs/ls1043a_common.h @@ -61,7 +61,6 @@ /* SD boot SPL */ #ifdef CONFIG_SD_BOOT -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0x1000 #define CONFIG_SPL_MAX_SIZE0x17000 @@ -91,7 +90,6 @@ /* NAND SPL */ #ifdef CONFIG_NAND_BOOT #define CONFIG_SPL_PBL_PAD -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0x1000 #define CONFIG_SPL_MAX_SIZE0x1a000 #define CONFIG_SPL_STACK 0x1001d000 diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h index c687c9e..26eca18 100644 --- a/include/configs/ls1046a_common.h +++ b/include/configs/ls1046a_common.h @@ -59,7 +59,6 @@ /* SD boot SPL */ #ifdef CONFIG_SD_BOOT -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT #define CONFIG_SPL_ENV_SUPPORT @@ -96,7 +95,6 @@ /* NAND SPL */ #ifdef CONFIG_NAND_BOOT #define CONFIG_SPL_PBL_PAD -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBGENERIC_SUPPORT #define CONFIG_SPL_ENV_SUPPORT diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h index ea48421..588a2f9 100644 --- a/include/configs/ls1088a_common.h +++ b/include/configs/ls1088a_common.h @@ -226,7 +226,6 @@ unsigned long long get_qixis_addr(void); #define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv8/u-boot-spl.lds" #define CONFIG_SPL_MAX_SIZE0x16000 #define CONFIG_SPL_STACK (CONFIG_SYS_FSL_OCRAM_BASE + 0x9ff0) -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0x1800a000 #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010 diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h index f1717ce..62df574 100644 --- a/include/configs/ls2080a_common.h +++ b/include/configs/ls2080a_common.h @@ -207,7 +207,6 @@ unsigned long long get_qixis_addr(void); #define CONFIG_SPL_BSS_MAX_SIZE0x0010 #define CONFIG_SPL_MAX_SIZE0x16000 #define CONFIG_SPL_STACK (CONFIG_SYS_FSL_OCRAM_BASE + 0x9ff0) -#define CONFIG_SPL_TARGET "u-boot-with-spl.bin" #define CONFIG_SPL_TEXT_BASE 0x1800a000 #ifdef CONFIG_NAND_BOOT -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] wip
Signed-off-by: Simon Glass
---
tools/patman/gitutil.py | 3 +++
tools/patman/settings.py | 7 +++
2 files changed, 10 insertions(+)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 64ac0c8d3d..c383af1cb3 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -405,6 +405,9 @@ def EmailPatches(series, cover_fname, args, dry_run,
raise_on_error, cc_fname,
to = BuildEmailList([os.getenv('USER')], '--to', alias, raise_on_error)
cc = []
cmd = ['git', 'send-email', '--annotate']
+smtp = settings.GetEmailSetting('smtp_server'):
+if smtp:
+cmd.append('--smtp-server=%s' % smtp)
if in_reply_to:
if type(in_reply_to) != str:
in_reply_to = in_reply_to.encode('utf-8')
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 94ea5b5a1b..0af016d517 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -303,6 +303,9 @@ def GetItems(config, section):
except:
raise
+def GetEmailSetting(name):
+return email.get(name)
+
def Setup(parser, project_name, config_fname=''):
"""Set up the settings module by reading config files.
@@ -331,11 +334,15 @@ def Setup(parser, project_name, config_fname=''):
for name, value in GetItems(config, 'bounces'):
bounces.add(value)
+for name, value in GetItems(config, 'email'):
+email[name] = value
+
_UpdateDefaults(parser, config)
# These are the aliases we understand, indexed by alias. Each member is a list.
alias = {}
bounces = set()
+email = {}
if __name__ == "__main__":
import doctest
--
2.18.0.rc1.244.gcf134e6275-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On 06/14/2018 03:07 PM, Tom Rini wrote: > On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote: >> On 06/14/2018 01:19 PM, Tom Rini wrote: >>> On Wed, Jun 13, 2018 at 06:05:08AM +0200, Marek Vasut wrote: >>> The following changes since commit 813d1fb56dc0af9567feb86cd71c49f14662044b: Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08 10:08:20 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to 0a52b00627c4fb6b100745c97910b75c99f3f4a9: ARM: rmobile: Fix environment placement on Draak (2018-06-10 16:34:43 +0200) >>> >>> NAK. First, there are a lot of should be fix style errors in >>> the new files in drivers/pinctrl/renesas/. Second, you have build >>> failures: >>> https://travis-ci.org/trini/u-boot/jobs/391819805 >>> https://travis-ci.org/trini/u-boot/jobs/391819826 >> >> Great, thanks! >> >> If the travis didn't vomit constant false positives recently, I'd trust >> it. With what it does now, I cannot trust it anymore. > > Can you elaborate? Don't you see the constant random timeouts during builds for some targets? I cannot get a successful build on the first try almost never these days, I have to keep restarting until I see that different targets failed during each build with a timeout and then extrapolate that the build is actually fine from that. It's annoying. And then there is the other category of boards which indicate "red" failure marker due to ie. DT problems, which if you pull DTs from Linux is something you cannot really fix on the U-Boot side right away, but rather fix in Linux and then resync. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] efi_loader: ARM: run EFI payloads non-secure
> From: Marc Zyngier
> Date: Thu, 14 Jun 2018 12:54:53 +0100
>
> On 13/06/18 23:41, Mark Kettenis wrote:
> > If desired (and possible) switch into HYP mode or non-secure SVC mode
> > before calling the entry point of an EFI application. This allows
> > U-Boot to provide a usable PSCI implementation and makes it possible
> > to boot kernels into hypervisor mode using an EFI bootloader.
> >
> > Based on diffs from Heinrich Schuchardt and Alexander Graf.
> >
> > Signed-off-by: Mark Kettenis
> > ---
> > cmd/bootefi.c | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 707d159bac..12a6b84ce6 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -20,6 +20,11 @@
> > #include
> > #include
> >
> > +#ifdef CONFIG_ARMV7_NONSEC
> > +#include
> > +#include
> > +#endif
> > +
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > #define OBJ_LIST_NOT_INITIALIZED 1
> > @@ -189,6 +194,18 @@ static efi_status_t efi_run_in_el2(EFIAPI efi_status_t
> > (*entry)(
> > }
> > #endif
> >
> > +#ifdef CONFIG_ARMV7_NONSEC
> > +static efi_status_t efi_run_in_hyp(EFIAPI efi_status_t (*entry)(
> > + efi_handle_t image_handle, struct efi_system_table *st),
> > + efi_handle_t image_handle, struct efi_system_table *st)
> > +{
> > + /* Enable caches again */
> > + dcache_enable();
> > +
> > + return efi_do_enter(image_handle, st, entry);
> > +}
> > +#endif
> > +
> > /* Carve out DT reserved memory ranges */
> > static efi_status_t efi_carve_out_dt_rsv(void *fdt)
> > {
> > @@ -338,6 +355,21 @@ static efi_status_t do_bootefi_exec(void *efi,
> > }
> > #endif
> >
> > +#ifdef CONFIG_ARMV7_NONSEC
> > + if (armv7_boot_nonsec()) {
> > + dcache_disable(); /* flush cache before switch to HYP */
> > +
>
> What is the rational for disabling/enabling caches across the transition
> to HYP? I'm sure there is a good reason, but I'd rather see it explained
> here.
Can't say I fully understan why. But the AArch64 code does this as
well and if I don't flush the cache here the contents of efi_gd (which
gets initialized before the switch) sometimes gets lost.
> > + armv7_init_nonsec();
> > + secure_ram_addr(_do_nonsec_entry)(efi_run_in_hyp,
> > + (uintptr_t)entry,
> > + (uintptr_t)loaded_image_info_obj.handle,
> > + (uintptr_t));
> > +
> > + /* Should never reach here, efi exits with longjmp */
> > + while (1) { }
> > + }
> > +#endif
> > +
> > ret = efi_do_enter(loaded_image_info_obj.handle, , entry);
> >
> > exit:
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y
> From: Heinrich Schuchardt > Date: Thu, 14 Jun 2018 19:55:51 +0200 > > On 06/14/2018 12:41 AM, Mark Kettenis wrote: > > This series makes it possible to run EFI applications in non-secure > > mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and > > Banana Pi boards using the PSCI implementation provided by U-Boot. > > > > The second version avoids using r3 to pass the original stack pointer. > > For some reason that register gets clobbered on the Banana Pi. Instead > > this version just migrates SP_svc to SP_hyp. > > > > This third version avoids saving r3 on the stack and fixes an include > > guard as suggested by Alexander Graf. > > > > Mark Kettenis (3): > > ARM: HYP/non-sec: migrate stack > > efi_loader: ARM: run EFI payloads non-secure > > Revert "efi_loader: no support for ARMV7_NONSEC=y" > > > > arch/arm/cpu/armv7/nonsec_virt.S | 2 ++ > > cmd/bootefi.c| 32 > > doc/README.uefi | 2 -- > > lib/efi_loader/Kconfig | 2 -- > > 4 files changed, 34 insertions(+), 4 deletions(-) > > > Hello Mark, > > with this patch series running bootefi hello twice in sequence fails on > the BananaPi. > > => bootefi hello > Scanning disk m...@01c0f000.blk... > Found 3 disks > WARNING: booting without device tree > ## Starting EFI application at 4200 ... > WARNING: using memory device/image path, this may confuse some payloads! > Hello, world! > Running on UEFI 2.7 > Have SMBIOS table > Load options: earlyprintk nosmp > ## Application terminated, r = 0 > => bootefi hello > WARNING: booting without device tree > ## Starting EFI application at 4200 ... > WARNING: using memory device/image path, this may confuse some payloads! > Yeah. Trying to enter non-secure mode when we're already in non-secure mode doesn't really work. We should skip the switching code in that case. Now checking whether we are in non-secure mode isn't really possible. But I guess we can set a variable and check it before we go down the switching codepath. With that in I can exit the OpenBSD bootloader and then reload and run it again. I'll include that fix in the next respin. > Please, keep in mind that we expect multiple EFI binaries to be executed > in sequence. E.g. the first binary installs a driver. The second is the > application using it. > > Running iPXE's snp.efi binary shows changed behavior on the console. New > characters are displayed in "slow motion" (3 characters per second). > Setting up the network interface fails in iPXE. The same happens on my Banana Pi. But not on the imx7 board. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] distro: add more efi dtb prefixes
As used on some distro, such as openSUSE.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
---
include/config_distro_bootcmd.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8ebe6..ad4c7a78f1 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -141,7 +141,8 @@
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
\
- "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
+ "efi_dtb_prefixes=/ /dtb/ /dtb/current/ " \
+ "/boot/ /boot/dtb/ /boot/dtb/current/\0" \
"scan_dev_for_efi=" \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] snow: set fdtfile
Needed to boot with EFI distro boot. Signed-off-by: Guillaume GARDET Cc: Akshay Saraswat Cc: Tom Rini --- include/configs/snow.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/snow.h b/include/configs/snow.h index 3b0db32ece..c546a5a6d0 100644 --- a/include/configs/snow.h +++ b/include/configs/snow.h @@ -8,6 +8,9 @@ #ifndef __CONFIG_SNOW_H #define __CONFIG_SNOW_H +#define EXYNOS_FDTFILE_SETTING \ + "fdtfile=exynos5250-snow.dtb\0" + #include #include #include -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()
On 14.06.18 21:01, Simon Glass wrote: > On 14 June 2018 at 12:22, Alexander Graf wrote: >> The fs_read() function wants to get an address rather than the >> pointer to a buffer. >> >> So let's convert the passed buffer from pointer back a the address >> to make efi_loader on sandbox happier. >> >> Signed-off-by: Alexander Graf >> >> --- >> >> v1 -> v2: >> >> - Clarify address vs pointer >> - include mapmem.h >> --- >> lib/efi_loader/efi_file.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) > > Reviewed-by: Simon Glass > I actually think that this patch tackles the problem the wrong way around. I've cooked up another one that converts fs_read() and fs_write() to instead take a pointer - which really is what most users of the API want in the first place: https://github.com/agraf/u-boot/commit/eb89f036a42cea8d7aaa6d83b8ecd9d202814b0f Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem
On 14.06.18 21:26, Heinrich Schuchardt wrote: > On 06/14/2018 09:13 PM, Alexander Graf wrote: >> >> >> On 14.06.18 21:01, Simon Glass wrote: >>> Hi Alex, >>> >>> On 14 June 2018 at 12:22, Alexander Graf wrote: We try hard to make sure that SMBIOS tables live in the lower 32bit. However, when we can not find any space at all there, we should not error out but instead just fall back to map them in the full address space instead. Signed-off-by: Alexander Graf --- lib/efi_loader/efi_smbios.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> Does that actually work? I thought the addresses in the table were >>> always 32-bit? >> >> >> There is only a single table reference which indeed is 32bit: >> se->struct_table_address. >> >> That address however is unused in the EFI case usually, because the >> SMBIOS information is already encapsulated in a table, so there's no >> need to search through address space for a _DMI_ entry: >> >> https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 >> >> >> Alex >> > We still have an open issue with E820 memory reservations not observed > by Linux because they are not mirrored in the memory map. Could the same > happen with smbios? The SMBIOS tables get allocated from the EFI pool in lib/efi_loader/efi_smbios.c. So the e820 patch fell through the cracks? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
On 14.06.18 21:02, Simon Glass wrote:
> Hi Alex,
>
> On 14 June 2018 at 12:05, Alexander Graf wrote:
>>
>>
>>
>> On 14.06.18 19:15, Simon Glass wrote:
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 11:08, Alexander Graf wrote:
On 06/14/2018 06:55 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 10:42, Alexander Graf wrote:
>>
>> On 06/14/2018 06:33 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 10:26, Alexander Graf wrote:
On 06/14/2018 06:13 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 10:07, Alexander Graf wrote:
>>
>> On 06/14/2018 05:53 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 09:47, Alexander Graf wrote:
> Am 14.06.2018 um 17:43 schrieb Simon Glass :
>
> Hi Alex,
>
>> On 14 June 2018 at 08:22, Alexander Graf wrote:
>>
>>
>>
>>> Am 14.06.2018 um 16:12 schrieb Simon Glass :
>>>
>>> Hi Alex,
>>>
> On 14 June 2018 at 07:41, Alexander Graf
> wrote:
> On 06/14/2018 02:58 PM, Simon Glass wrote:
>
> Hi Alex,
>
>>> On 14 June 2018 at 04:12, Alexander Graf
>>> wrote:
>>>
>>> On 06/13/2018 04:37 AM, Simon Glass wrote:
>>>
>>> With sandbox the U-Boot code is not mapped into the sandbox
>>> memory
>>> range
>>> so does not need to be excluded when allocating EFI memory.
>>> Update
>>> the
>>> EFI
>>> memory init code to take account of that.
>>>
>>> Also use mapmem instead of a cast to convert a memory
>>> address
>>> to
>>> a
>>> pointer.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> Changes in v6: None
>>> Changes in v5: None
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2:
>>> - Update to use mapmem instead of a cast
>>>
>>> lib/efi_loader/efi_memory.c | 31
>>> ++-
>>> 1 file changed, 18 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_memory.c
>>> b/lib/efi_loader/efi_memory.c
>>> index ec66af98ea..210e49ee8b 100644
>>> --- a/lib/efi_loader/efi_memory.c
>>> +++ b/lib/efi_loader/efi_memory.c
>>> @@ -9,6 +9,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
>>> pool_type,
>>> efi_uintn_t size, void **buffer)
>>> );
>>>if (r == EFI_SUCCESS) {
>>> - struct efi_pool_allocation *alloc = (void
>>> *)(uintptr_t)t;
>>> + struct efi_pool_allocation *alloc =
>>> map_sysmem(t,
>>> size);
>>
>>
>> This is still the wrong spot. We don't want the conversion to
>> happen when
>> going from an EFI internal address to an allocation, but when
>> determining
>> which addresses are usable in the first place.
>
> There seem to be two ways to do this:
>
> 1. Record addresses (ulong) in the EFI tables and use
> map_sysmem()
> before returning an address in the allocator
> 2. Store pointers in the EFI tables using map_sysmem(), then
> do
> no
> mapping in the allocator
>
> I've gone with option 1 since:
>
> - the EFI addresses are not pointers
> - it makes sandbox consistent with other architectures which
> use
> an
> address rather than a pointer in EFI tables
> - we don't normally do pointer arithmetic on the results of
> map_sysmem()
> - we normally
Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem
On 06/14/2018 09:13 PM, Alexander Graf wrote: > > > On 14.06.18 21:01, Simon Glass wrote: >> Hi Alex, >> >> On 14 June 2018 at 12:22, Alexander Graf wrote: >>> We try hard to make sure that SMBIOS tables live in the lower 32bit. >>> However, when we can not find any space at all there, we should not >>> error out but instead just fall back to map them in the full address >>> space instead. >>> >>> Signed-off-by: Alexander Graf >>> --- >>> lib/efi_loader/efi_smbios.c | 11 +-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> Does that actually work? I thought the addresses in the table were >> always 32-bit? > > > There is only a single table reference which indeed is 32bit: > se->struct_table_address. > > That address however is unused in the EFI case usually, because the > SMBIOS information is already encapsulated in a table, so there's no > need to search through address space for a _DMI_ entry: > > https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 > > > Alex > We still have an open issue with E820 memory reservations not observed by Linux because they are not mirrored in the memory map. Could the same happen with smbios? Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible
Hi Dennis,
On Thu, Jun 14, 2018 at 02:10:31PM -0500, Dennis Gilmore wrote:
> running sf probe on one of my clearfogs with this set of patches
> applied I got
>
> SF: unrecognized JEDEC id bytes: ff, ff, ff
> Failed to initialize SPI flash at 1:0 (error -2)
Do you use the clearfog_defconfig?
Does current U-Boot master work for you?
For the record, on my Clearfog Base 'sf probe' shows:
SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB
This works with or without these patches.
baruch
> Dennis
>
> On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> > Add the "spi-flash" compatible string so that the generic sf_probe
> > driver can probe the SPI flash on the SolidRun SOM.
> >
> > Signed-off-by: Baruch Siach
> > ---
> > arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > index a2627223ce3b..74f58de85c43 100644
> > --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > @@ -86,7 +86,7 @@
> > w25q32: spi-flash@0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > - compatible = "w25q32", "jedec,spi-nor";
> > + compatible = "w25q32", "jedec,spi-nor", "spi-flash";
> > reg = <0>; /* Chip select 0 */
> > spi-max-frequency = <300>;
> > status = "disabled";
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader
On 06/14/2018 09:02 PM, Simon Glass wrote: > Hi Alex, > > On 14 June 2018 at 12:22, Alexander Graf wrote: >> With efi_loader we do not control payload applications, so we can not >> teach them about the difference between virtual and physical addresses. >> >> Instead, let's just always map host virtual addresses in the efi memory >> map. That way we can be sure that all memory allocation functions always >> return consumable pointers. >> >> Signed-off-by: Alexander Graf >> >> --- >> >> v1 -> v2: >> >> - only compile efi_add_known_memory if efi_loader is enabled >> --- >> arch/sandbox/cpu/cpu.c | 20 >> 1 file changed, 20 insertions(+) > > NAK. > > You should not point sandbox pointers into the EFI tables. I know it > looks like a clever shortcut, but it is not correct. It will mess up > logging and debugging, since those pointers bear no easily accessible > relationship to U-Boot address. Hello Simon, why do we need this Babylonic confusion of addresses which do not point to valid memory and pointers that are not valid addresses where everybody is getting lost? Simply use only addresses with there mmap'ed values and get rid of all conversions. Use your board file to adjust kernel_addr_r and the like to the address range that Linux offered you. Best regards Heinrich > > Please start from my v7 patch. I'm happy to help do this correctly. > But, again, I think it should come after we have basic sandbox EFI > support applied. > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader
On 14.06.18 21:02, Simon Glass wrote: > Hi Alex, > > On 14 June 2018 at 12:22, Alexander Graf wrote: >> With efi_loader we do not control payload applications, so we can not >> teach them about the difference between virtual and physical addresses. >> >> Instead, let's just always map host virtual addresses in the efi memory >> map. That way we can be sure that all memory allocation functions always >> return consumable pointers. >> >> Signed-off-by: Alexander Graf >> >> --- >> >> v1 -> v2: >> >> - only compile efi_add_known_memory if efi_loader is enabled >> --- >> arch/sandbox/cpu/cpu.c | 20 >> 1 file changed, 20 insertions(+) > > NAK. > > You should not point sandbox pointers into the EFI tables. I know it > looks like a clever shortcut, but it is not correct. It will mess up > logging and debugging, since those pointers bear no easily accessible > relationship to U-Boot address. > > Please start from my v7 patch. I'm happy to help do this correctly. > But, again, I think it should come after we have basic sandbox EFI > support applied. I don't want to play ping pong with you here. NAK on your approach until I see it properly executing selftest. So either we drive this forward or we don't. Your choice. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem
On 14.06.18 21:01, Simon Glass wrote: > Hi Alex, > > On 14 June 2018 at 12:22, Alexander Graf wrote: >> We try hard to make sure that SMBIOS tables live in the lower 32bit. >> However, when we can not find any space at all there, we should not >> error out but instead just fall back to map them in the full address >> space instead. >> >> Signed-off-by: Alexander Graf >> --- >> lib/efi_loader/efi_smbios.c | 11 +-- >> 1 file changed, 9 insertions(+), 2 deletions(-) > > Does that actually work? I thought the addresses in the table were > always 32-bit? There is only a single table reference which indeed is 32bit: se->struct_table_address. That address however is unused in the EFI case usually, because the SMBIOS information is already encapsulated in a table, so there's no need to search through address space for a _DMI_ entry: https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible
running sf probe on one of my clearfogs with this set of patches
applied I got
SF: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Dennis
On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> Add the "spi-flash" compatible string so that the generic sf_probe
> driver can probe the SPI flash on the SolidRun SOM.
>
> Signed-off-by: Baruch Siach
> ---
> arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> index a2627223ce3b..74f58de85c43 100644
> --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> @@ -86,7 +86,7 @@
> w25q32: spi-flash@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> - compatible = "w25q32", "jedec,spi-nor";
> + compatible = "w25q32", "jedec,spi-nor", "spi-flash";
> reg = <0>; /* Chip select 0 */
> spi-max-frequency = <300>;
> status = "disabled";
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm: mvebu: clearfog: use the microsom .dtsi
Reviewed-by: Dennis Gilmore
Tested-by: Dennis Gilmore
On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> Use hardware description from the recently introduced microsom .dtsi
> file to reduce duplication.
>
> Signed-off-by: Baruch Siach
> ---
> arch/arm/dts/armada-388-clearfog.dts | 63 +++---
> --
> 1 file changed, 6 insertions(+), 57 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index a0b566a5ae0e..1403600e5b02 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -50,6 +50,7 @@
> #include
> #include
> #include "armada-388.dtsi"
> +#include "armada-38x-solidrun-microsom.dtsi"
>
> / {
> model = "SolidRun Clearfog A1";
> @@ -70,11 +71,6 @@
> stdout-path = "serial0:115200n8";
> };
>
> - memory {
> - device_type = "memory";
> - reg = <0x 0x1000>; /* 256 MB */
> - };
> -
> reg_3p3v: regulator-3p3v {
> compatible = "regulator-fixed";
> regulator-name = "3P3V";
> @@ -84,11 +80,6 @@
> };
>
> soc {
> - ranges = - MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> - MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> - MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> -
> internal-regs {
> ethernet@3 {
> mac-address = [00 50 43 02 02 02];
> @@ -108,15 +99,6 @@
> status = "okay";
> };
>
> - ethernet@7 {
> - mac-address = [00 50 43 02 02 01];
> - pinctrl-0 = <_rgmii_pins>;
> - pinctrl-names = "default";
> - phy = <_dedicated>;
> - phy-mode = "rgmii-id";
> - status = "okay";
> - };
> -
> i2c@11000 {
> /* Is there anything on this? */
> clock-frequency = <10>;
> @@ -226,22 +208,6 @@
> status = "okay";
> };
>
> - mdio@72004 {
> - pinctrl-0 = <_pins>;
> - pinctrl-names = "default";
> -
> - phy_dedicated: ethernet-phy@0 {
> - /*
> - * Annoyingly, the marvell
> phy driver
> - * configures the LED
> register, rather
> - * than preserving reset-
> loaded setting.
> - * We undo that rubbish
> here.
> - */
> - marvell,reg-init = <3 16 0
> 0x101e>;
> - reg = <0>;
> - };
> - };
> -
> pinctrl@18000 {
> clearfog_dsa0_clk_pins: clearfog-
> dsa0-clk-pins {
> marvell,pins = "mpp46";
> @@ -260,12 +226,6 @@
> marvell,pins = "mpp20";
> marvell,function = "gpio";
> };
> - clearfog_sdhci_pins: clearfog-sdhci-
> pins {
> - marvell,pins = "mpp21",
> "mpp28",
> -"mpp37",
> "mpp38",
> -"mpp39",
> "mpp40";
> - marvell,function = "sd0";
> - };
> clearfog_spi1_cs_pins: spi1-cs-pins
> {
> marvell,pins = "mpp55";
> marvell,function = "spi1";
> @@ -311,7 +271,7 @@
> bus-width = <4>;
> cd-gpios = < 20
> GPIO_ACTIVE_LOW>;
> no-1-8-v;
> - pinctrl-0 = <_sdhci_pins
> + pinctrl-0 = <_sdhci_pins
>_sdhci_cd_pins
> >;
> pinctrl-names = "default";
> status = "okay";
> @@ -319,13 +279,6 @@
> wp-inverted;
> };
>
> - serial@12000 {
> - pinctrl-0 = <_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> - u-boot,dm-pre-reloc;
> - };
> -
>
Re: [U-Boot] [PATCH 3/4] arm: mvebu: Better align Clearfog dts file with Linux kernel
Reviewed-by: Dennis Gilmore
Tested-by: Dennis Gilmore
On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> From: Jon Nettleton
>
> This makes changes so the u-boot dts file is structured more
> similar to the mainline linux dtsi file. It provides a minimal
> common dts that can work for most boards based on the ClearFog
> platform. Ethernet support is only supported for eth0 however
> all devices are left enabled so u-boot can generate and
> provide mac addresses for all of the network interfaces.
>
> Signed-off-by: Jon Nettleton
> [baruch: rebase on recent changes]
> Signed-off-by: Baruch Siach
> ---
> arch/arm/dts/armada-388-clearfog.dts | 386 +++
>
> 1 file changed, 151 insertions(+), 235 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index 1403600e5b02..16a47d59e667 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -81,174 +81,6 @@
>
> soc {
> internal-regs {
> - ethernet@3 {
> - mac-address = [00 50 43 02 02 02];
> - phy-mode = "sgmii";
> - status = "okay";
> -
> - fixed-link {
> - speed = <1000>;
> - full-duplex;
> - };
> - };
> -
> - ethernet@34000 {
> - mac-address = [00 50 43 02 02 03];
> - managed = "in-band-status";
> - phy-mode = "sgmii";
> - status = "okay";
> - };
> -
> - i2c@11000 {
> - /* Is there anything on this? */
> - clock-frequency = <10>;
> - pinctrl-0 = <_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - /*
> - * PCA9655 GPIO expander, up to 1MHz
> clock.
> - * 0-CON3 CLKREQ#
> - * 1-CON3 PERST#
> - * 2-CON2 PERST#
> - * 3-CON3 W_DISABLE
> - * 4-CON2 CLKREQ#
> - * 5-USB3 overcurrent
> - * 6-USB3 power
> - * 7-CON2 W_DISABLE
> - * 8-JP4 P1
> - * 9-JP4 P4
> - * 10-JP4 P5
> - * 11-m.2 DEVSLP
> - * 12-SFP_LOS
> - * 13-SFP_TX_FAULT
> - * 14-SFP_TX_DISABLE
> - * 15-SFP_MOD_DEF0
> - */
> - expander0: gpio-expander@20 {
> - /*
> - * This is how it should be:
> - * compatible =
> "onnn,pca9655",
> - * "nxp,pca9555";
> - * but you can't do this
> because of
> - * the way I2C works.
> - */
> - compatible = "nxp,pca9555";
> - gpio-controller;
> - #gpio-cells = <2>;
> - reg = <0x20>;
> -
> - pcie1_0_clkreq {
> - gpio-hog;
> - gpios = <0
> GPIO_ACTIVE_LOW>;
> - input;
> - line-name =
> "pcie1.0-clkreq";
> - };
> - pcie1_0_w_disable {
> - gpio-hog;
> - gpios = <3
> GPIO_ACTIVE_LOW>;
> - output-low;
> - line-name =
> "pcie1.0-w-disable";
> - };
> - pcie2_0_clkreq {
> - gpio-hog;
> - gpios = <4
> GPIO_ACTIVE_LOW>;
> - input;
> - line-name =
> "pcie2.0-clkreq";
> - };
> - pcie2_0_w_disable {
> -
Re: [U-Boot] [PATCH 4/4] arm: mvebu: helios4: remove duplicate sdhci pins node
Reviewed-by: Dennis Gilmore
Tested-by: Dennis Gilmore
On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> The same pinctrl node appears in the solidrun-microsom dtsi. Use that
> instead.
>
> Cc: Dennis Gilmore
> Signed-off-by: Baruch Siach
> ---
> arch/arm/dts/armada-388-helios4.dts | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-helios4.dts
> b/arch/arm/dts/armada-388-helios4.dts
> index 049d32296475..a154e0f4f477 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -248,7 +248,7 @@
> bus-width = <4>;
> cd-gpios = < 20
> GPIO_ACTIVE_LOW>;
> no-1-8-v;
> - pinctrl-0 = <_sdhci_pins
> + pinctrl-0 = <_sdhci_pins
>_sdhci_cd_pins>;
> pinctrl-names = "default";
> status = "okay";
> @@ -286,12 +286,6 @@
> marvell,pins = "mpp20";
> marvell,function = "gpio";
> };
> - helios_sdhci_pins: helios-sdhci-pins
> {
> - marvell,pins = "mpp21",
> "mpp28",
> -"mpp37",
> "mpp38",
> -"mpp39",
> "mpp40";
> - marvell,function = "sd0";
> - };
> helios_led_pins: helios-led-pins {
> marvell,pins = "mpp24",
> "mpp25",
> "mpp49",
> "mpp50",
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
Hi Alex,
On 14 June 2018 at 12:05, Alexander Graf wrote:
>
>
>
> On 14.06.18 19:15, Simon Glass wrote:
> > Hi Alex,
> >
> > On 14 June 2018 at 11:08, Alexander Graf wrote:
> >>
> >> On 06/14/2018 06:55 PM, Simon Glass wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> On 14 June 2018 at 10:42, Alexander Graf wrote:
>
> On 06/14/2018 06:33 PM, Simon Glass wrote:
> >
> > Hi Alex,
> >
> > On 14 June 2018 at 10:26, Alexander Graf wrote:
> >>
> >> On 06/14/2018 06:13 PM, Simon Glass wrote:
> >>>
> >>> Hi Alex,
> >>>
> >>> On 14 June 2018 at 10:07, Alexander Graf wrote:
>
> On 06/14/2018 05:53 PM, Simon Glass wrote:
> >
> > Hi Alex,
> >
> > On 14 June 2018 at 09:47, Alexander Graf wrote:
> >>
> >>
> >>> Am 14.06.2018 um 17:43 schrieb Simon Glass :
> >>>
> >>> Hi Alex,
> >>>
> On 14 June 2018 at 08:22, Alexander Graf wrote:
>
>
>
> > Am 14.06.2018 um 16:12 schrieb Simon Glass :
> >
> > Hi Alex,
> >
> >>> On 14 June 2018 at 07:41, Alexander Graf
> >>> wrote:
> >>> On 06/14/2018 02:58 PM, Simon Glass wrote:
> >>>
> >>> Hi Alex,
> >>>
> > On 14 June 2018 at 04:12, Alexander Graf
> > wrote:
> >
> > On 06/13/2018 04:37 AM, Simon Glass wrote:
> >
> > With sandbox the U-Boot code is not mapped into the sandbox
> > memory
> > range
> > so does not need to be excluded when allocating EFI memory.
> > Update
> > the
> > EFI
> > memory init code to take account of that.
> >
> > Also use mapmem instead of a cast to convert a memory
> > address
> > to
> > a
> > pointer.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2:
> > - Update to use mapmem instead of a cast
> >
> > lib/efi_loader/efi_memory.c | 31
> > ++-
> > 1 file changed, 18 insertions(+), 13 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_memory.c
> > b/lib/efi_loader/efi_memory.c
> > index ec66af98ea..210e49ee8b 100644
> > --- a/lib/efi_loader/efi_memory.c
> > +++ b/lib/efi_loader/efi_memory.c
> > @@ -9,6 +9,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
> > pool_type,
> > efi_uintn_t size, void **buffer)
> > );
> >if (r == EFI_SUCCESS) {
> > - struct efi_pool_allocation *alloc = (void
> > *)(uintptr_t)t;
> > + struct efi_pool_allocation *alloc =
> > map_sysmem(t,
> > size);
>
>
> This is still the wrong spot. We don't want the conversion to
> happen when
> going from an EFI internal address to an allocation, but when
> determining
> which addresses are usable in the first place.
> >>>
> >>> There seem to be two ways to do this:
> >>>
> >>> 1. Record addresses (ulong) in the EFI tables and use
> >>> map_sysmem()
> >>> before returning an address in the allocator
> >>> 2. Store pointers in the EFI tables using map_sysmem(), then
> >>> do
> >>> no
> >>> mapping in the allocator
> >>>
> >>> I've gone with option 1 since:
> >>>
> >>> - the EFI addresses are not pointers
> >>> - it makes sandbox consistent with other architectures which
> >>> use
> >>> an
> >>> address rather than a pointer in EFI tables
> >>> - we don't normally do pointer arithmetic on the results of
> >>> map_sysmem()
> >>> - we normally map the memory when it is used rather than when
Re: [U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader
Hi Alex, On 14 June 2018 at 12:22, Alexander Graf wrote: > With efi_loader we do not control payload applications, so we can not > teach them about the difference between virtual and physical addresses. > > Instead, let's just always map host virtual addresses in the efi memory > map. That way we can be sure that all memory allocation functions always > return consumable pointers. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - only compile efi_add_known_memory if efi_loader is enabled > --- > arch/sandbox/cpu/cpu.c | 20 > 1 file changed, 20 insertions(+) NAK. You should not point sandbox pointers into the EFI tables. I know it looks like a clever shortcut, but it is not correct. It will mess up logging and debugging, since those pointers bear no easily accessible relationship to U-Boot address. Please start from my v7 patch. I'm happy to help do this correctly. But, again, I think it should come after we have basic sandbox EFI support applied. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()
On 14 June 2018 at 12:22, Alexander Graf wrote: > The fs_read() function wants to get an address rather than the > pointer to a buffer. > > So let's convert the passed buffer from pointer back a the address > to make efi_loader on sandbox happier. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - Clarify address vs pointer > - include mapmem.h > --- > lib/efi_loader/efi_file.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem
Hi Alex, On 14 June 2018 at 12:22, Alexander Graf wrote: > We try hard to make sure that SMBIOS tables live in the lower 32bit. > However, when we can not find any space at all there, we should not > error out but instead just fall back to map them in the full address > space instead. > > Signed-off-by: Alexander Graf > --- > lib/efi_loader/efi_smbios.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) Does that actually work? I thought the addresses in the table were always 32-bit? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/11] efi_loader: Use compiler constants for image loader
Hi Alex, On 14 June 2018 at 12:22, Alexander Graf wrote: > The EFI image loader tries to determine which target architecture we're > working with to only load PE binaries that match. > > So far this has worked based on CONFIG defines, because the target CPU > was always indicated by a config define. With sandbox however, this is > not longer true as all sandbox targets only encompass a single CONFIG > option and so we need to use compiler defines to determine the CPU > architecture. > > Signed-off-by: Alexander Graf > --- > lib/efi_loader/efi_image_loader.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > NAK to this for now until we figure out a response to my concerns previously expressed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] efi_loader: Disable miniapps on sandbox
On 14 June 2018 at 12:22, Alexander Graf wrote: > In the sandbox environment we can not easily build efi stub binaries > right now, so let's disable the respective test cases for the efi > selftest suite. > > Signed-off-by: Alexander Graf > --- > lib/efi_selftest/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] efi_loader: Use map_sysmem() in bootefi command
On 14 June 2018 at 12:22, Alexander Graf wrote: > The bootefi command gets a few addresses as values passed in. In sandbox, > these values are in U-Boot address space, so we need to make sure we > explicitly call map_sysmem() on them to be able to access them. > > Signed-off-by: Alexander Graf > --- > cmd/bootefi.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) Looks right to me. You might consider doing the map lower down in efi_load_pe() but since you don't ever log the address, I suppose it is OK. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 07/11] sandbox: Map host memory for efi_loader
With efi_loader we do not control payload applications, so we can not
teach them about the difference between virtual and physical addresses.
Instead, let's just always map host virtual addresses in the efi memory
map. That way we can be sure that all memory allocation functions always
return consumable pointers.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- only compile efi_add_known_memory if efi_loader is enabled
---
arch/sandbox/cpu/cpu.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index cde0b055a6..23d8b70648 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,6 +5,7 @@
#define DEBUG
#include
#include
+#include
#include
#include
#include
@@ -177,3 +178,22 @@ void longjmp(jmp_buf jmp, int ret)
while (1)
;
}
+
+#ifdef CONFIG_EFI_LOADER
+
+/*
+ * In sandbox, we don't have a 1:1 map, so we need to expose
+ * process addresses instead of U-Boot addresses
+ */
+void efi_add_known_memory(void)
+{
+ u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
+ u64 ram_size = gd->ram_size;
+ u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+ u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+
+ efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
+ false);
+}
+
+#endif
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii
On Thu, Jun 14, 2018 at 1:12 PM, Dr. Philipp Tomsich wrote: > >> On 14 Jun 2018, at 19:39, Joe Hershberger wrote: >> >> On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann >> wrote: >>> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of >>> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii() >>> to enable the RX delay. >>> The MASK was used in a wrong way. >>> >>> Signed-off-by: Janine Hagemann >> >> Acked-by: Joe Hershberger > > Reviewed-by: Philipp Tomsich I assume I should take this series? Or would you prefer to? -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/11] efi_loader: Use compiler constants for image loader
The EFI image loader tries to determine which target architecture we're
working with to only load PE binaries that match.
So far this has worked based on CONFIG defines, because the target CPU
was always indicated by a config define. With sandbox however, this is
not longer true as all sandbox targets only encompass a single CONFIG
option and so we need to use compiler defines to determine the CPU
architecture.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_image_loader.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index ecdb77e5b6..fdf40a62c8 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -19,25 +19,25 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
static int machines[] = {
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
IMAGE_FILE_MACHINE_ARM64,
-#elif defined(CONFIG_ARM)
+#elif defined(__arm__)
IMAGE_FILE_MACHINE_ARM,
IMAGE_FILE_MACHINE_THUMB,
IMAGE_FILE_MACHINE_ARMNT,
#endif
-#if defined(CONFIG_X86_64)
+#if defined(__x86_64__)
IMAGE_FILE_MACHINE_AMD64,
-#elif defined(CONFIG_X86)
+#elif defined(__i386__)
IMAGE_FILE_MACHINE_I386,
#endif
-#if defined(CONFIG_CPU_RISCV_32)
+#if defined(__riscv) && (__riscv_xlen == 32)
IMAGE_FILE_MACHINE_RISCV32,
#endif
-#if defined(CONFIG_CPU_RISCV_64)
+#if defined(__riscv) && (__riscv_xlen == 64)
IMAGE_FILE_MACHINE_RISCV64,
#endif
0 };
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/11] efi_loader: Pass address to fs_read()
The fs_read() function wants to get an address rather than the
pointer to a buffer.
So let's convert the passed buffer from pointer back a the address
to make efi_loader on sandbox happier.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Clarify address vs pointer
- include mapmem.h
---
lib/efi_loader/efi_file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index e6a15bcb52..2107730ba5 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
/* GUID for file system information */
@@ -232,8 +233,10 @@ static efi_status_t file_read(struct file_handle *fh, u64
*buffer_size,
void *buffer)
{
loff_t actread;
+ /* fs_read expects buffer address, not pointer */
+ uintptr_t buffer_addr = (uintptr_t)map_to_sysmem(buffer);
- if (fs_read(fh->path, (ulong)buffer, fh->offset,
+ if (fs_read(fh->path, buffer_addr, fh->offset,
*buffer_size, ))
return EFI_DEVICE_ERROR;
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/11] efi: sandbox: Add relocation constants
From: Simon Glass
Add these so that we can build the EFI loader for sandbox. The values are
for x86_64 so potentially bogus. But we don't support relocation within
sandbox anyway.
Signed-off-by: Simon Glass
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_runtime.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 4874eb602f..388dfb9840 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -62,6 +62,18 @@ struct dyn_sym {
#define R_ABSOLUTE R_RISCV_64
#define SYM_INDEX 32
#endif
+
+/* For sandbox we only support 64-bit x86 at present */
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(s...@chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+# warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+#define R_RELATIVE 8
+#define R_MASK 0xULL
#else
#error Need to add relocation awareness
#endif
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/11] sandbox: efi_loader support
This patch set augments Simon's patch set for efi_loader support in sandbox[1], but follows a different memory allocation scheme. Instead of keeping U-Boot (physical) addresses in the EFI memory map, this patch set makes the EFI memory map contain host virtual (virtual) addresses. That way most logic "just works" and all EFI interfaces automatically gain sandbox awareness. With this patch set in place, I can run a good chunk of the selftest suite as well as efi binaries compiled using gnu-efi. Alex [1] https://patchwork.ozlabs.org/project/uboot/list/?series=49832 v1 -> v2: - only compile efi_add_known_memory if efi_loader is enabled - clarify address vs pointer in fs_read patch - include mapmem.h Alexander Graf (7): efi_loader: Use compiler constants for image loader efi_loader: Use map_sysmem() in bootefi command efi.h: Do not use config options efi_loader: Allow SMBIOS tables in highmem sandbox: Map host memory for efi_loader efi_loader: Disable miniapps on sandbox efi_loader: Pass address to fs_read() Heinrich Schuchardt (1): efi_loader: efi_allocate_pages is too restrictive Simon Glass (3): efi: sandbox: Add distroboot support efi: sandbox: Add relocation constants efi: sandbox: Enable EFI loader for sandbox arch/sandbox/cpu/cpu.c| 20 cmd/bootefi.c | 13 - include/config_distro_bootcmd.h | 13 + include/efi.h | 17 - lib/efi/Makefile | 4 ++-- lib/efi_loader/Kconfig| 2 +- lib/efi_loader/efi_file.c | 5 - lib/efi_loader/efi_image_loader.c | 12 ++-- lib/efi_loader/efi_memory.c | 2 +- lib/efi_loader/efi_runtime.c | 12 lib/efi_loader/efi_smbios.c | 11 +-- lib/efi_selftest/Makefile | 2 +- 12 files changed, 81 insertions(+), 32 deletions(-) -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 01/11] efi: sandbox: Add distroboot support
From: Simon Glass With sandbox these values depend on the host system. Let's assume that it is x86_64 for now. Signed-off-by: Simon Glass Signed-off-by: Alexander Graf --- include/config_distro_bootcmd.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index d672e8ebe6..1bd79ae3b8 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -251,6 +251,8 @@ #elif defined(CONFIG_ARM) #define BOOTENV_EFI_PXE_ARCH "0xa" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000" + +/* For sandbox we only support 64-bit x86 at present */ #elif defined(CONFIG_X86) /* Always assume we're running 64bit */ #define BOOTENV_EFI_PXE_ARCH "0x7" @@ -261,6 +263,17 @@ #elif defined(CONFIG_CPU_RISCV_64) #define BOOTENV_EFI_PXE_ARCH "0x1b" #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000" +#elif defined(CONFIG_SANDBOX) +/* + * TODO(s...@chromium.org): Consider providing a way to enable sandbox features + * based on the host architecture + */ +# ifndef __x86_64__ +# warning "sandbox EFI support is only tested on 64-bit x86" +# endif +/* To support other *host* architectures this should be changed */ +#define BOOTENV_EFI_PXE_ARCH "0x7" +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:7:UNDI:003000" #else #error Please specify an EFI client identifier #endif -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 11/11] efi: sandbox: Enable EFI loader for sandbox
From: Simon Glass This allows this feature to build within sandbox. This is for testing purposes only since it is not possible for sandbox to load native code. Signed-off-by: Simon Glass Signed-off-by: Alexander Graf --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index df58e633d1..d471e6f4a4 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86 || RISCV) && OF_LIBFDT + depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT # We do not support bootefi booting ARMv7 in non-secure mode depends on !ARMV7_NONSEC # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/11] efi_loader: efi_allocate_pages is too restrictive
From: Heinrich Schuchardt
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.
There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.
Signed-off-by: Heinrich Schuchardt
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ec66af98ea..ce29bcc6a3 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -295,7 +295,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
- addr = efi_find_free_memory(len, gd->start_addr_sp);
+ addr = efi_find_free_memory(len, -1ULL);
if (!addr) {
r = EFI_NOT_FOUND;
break;
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/11] efi_loader: Use map_sysmem() in bootefi command
The bootefi command gets a few addresses as values passed in. In sandbox,
these values are in U-Boot address space, so we need to make sure we
explicitly call map_sysmem() on them to be able to access them.
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f55a40dc84..a86a2bd4a9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -389,7 +390,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
unsigned long addr;
char *saddr;
efi_status_t r;
- void *fdt_addr;
+ unsigned long fdt_addr;
+ void *fdt;
/* Allow unaligned memory access */
allow_unaligned();
@@ -406,11 +408,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
return CMD_RET_USAGE;
if (argc > 2) {
- fdt_addr = (void *)simple_strtoul(argv[2], NULL, 16);
+ fdt_addr = simple_strtoul(argv[2], NULL, 16);
if (!fdt_addr && *argv[2] != '0')
return CMD_RET_USAGE;
/* Install device tree */
- r = efi_install_fdt(fdt_addr);
+ fdt = map_sysmem(fdt_addr, 0);
+ r = efi_install_fdt(fdt);
if (r != EFI_SUCCESS) {
printf("ERROR: failed to install device tree\n");
return CMD_RET_FAILURE;
@@ -429,7 +432,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
addr = simple_strtoul(saddr, NULL, 16);
else
addr = CONFIG_SYS_LOAD_ADDR;
- memcpy((char *)addr, __efi_helloworld_begin, size);
+ memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
} else
#endif
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
@@ -475,7 +478,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
printf("## Starting EFI application at %08lx ...\n", addr);
- r = do_bootefi_exec((void *)addr, bootefi_device_path,
+ r = do_bootefi_exec(map_sysmem(addr, 0), bootefi_device_path,
bootefi_image_path);
printf("## Application terminated, r = %lu\n",
r & ~EFI_ERROR_MASK);
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/11] efi_loader: Disable miniapps on sandbox
In the sandbox environment we can not easily build efi stub binaries right now, so let's disable the respective test cases for the efi selftest suite. Signed-off-by: Alexander Graf --- lib/efi_selftest/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile index 4fe404d88d..bf5c8199cb 100644 --- a/lib/efi_selftest/Makefile +++ b/lib/efi_selftest/Makefile @@ -41,7 +41,7 @@ endif # TODO: As of v2018.01 the relocation code for the EFI application cannot # be built on x86_64. -ifeq ($(CONFIG_X86_64),) +ifeq ($(CONFIG_X86_64)$(CONFIG_SANDBOX),) ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST),) -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/11] efi.h: Do not use config options
Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines
instead. That way we always adhere to the build environment we're in
and the definitions adjust automatically.
Signed-off-by: Alexander Graf
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Signed-off-by: Bin Meng
---
include/efi.h| 17 -
lib/efi/Makefile | 4 ++--
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index e30a3c51c6..826d484977 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -19,12 +19,12 @@
#include
#include
-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__))
-/* EFI uses the Microsoft ABI which is not the default for GCC */
+/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
+#ifdef __x86_64__
#define EFIAPI __attribute__((ms_abi))
#else
#define EFIAPI asmlinkage
-#endif
+#endif /* __x86_64__ */
struct efi_device_path;
@@ -32,16 +32,7 @@ typedef struct {
u8 b[16];
} efi_guid_t;
-#define EFI_BITS_PER_LONG BITS_PER_LONG
-
-/*
- * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
- * in lib/efi/Makefile, when building the stub.
- */
-#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
-#undef EFI_BITS_PER_LONG
-#define EFI_BITS_PER_LONG 64
-#endif
+#define EFI_BITS_PER_LONG (sizeof(long) * 8)
/* Bit mask for EFI status code with error */
#define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))
diff --git a/lib/efi/Makefile b/lib/efi/Makefile
index 18d081ac46..ece7907227 100644
--- a/lib/efi/Makefile
+++ b/lib/efi/Makefile
@@ -7,9 +7,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi_stub.o := -fpic -fshort-wchar
CFLAGS_REMOVE_efi.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi.o := -fpic -fshort-wchar
extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/11] efi_loader: Allow SMBIOS tables in highmem
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
Re: [U-Boot] make Menuconfig Error
Hi Duncan, On Thu, Jun 14, 2018 at 1:03 PM, wrote: > Cloned most recent u-boot 2018.06.14 > make clean works > make menuconfig fails: > > /bin/sh: 1: bison: not found > scripts/kconfig/Makefile:229: recipe for target > 'scripts/kconfig/dochecklxdialog' failed make[1]: *** > [scripts/kconfig/dochecklxdialog] Error 1 Makefile:491: recipe for > target 'menuconfig' failed make: *** [menuconfig] Error 2 > > I've checked for bison, visually and with apt-cache search but I have > found none. This was introduced with commit e91610da7c8a9fe42f3e5a75f06c3d1a0cb5f815 (kconfig: re-sync with Linux 4.17-rc4) It seems that they made bison an external dependency instead of keeping the pre-compiled scripts/kconfig/zconf.tab.c_shipped and friends. > Will try rebuild based on u-boot from 2018.05.14 on SPDX errors, That > version did build. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 7/9] arm: dts: bubblegum_96: Enable UART5 for serial console
This commit enables UART5 found in S900 SoC for serial console support.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2: None
arch/arm/dts/bubblegum_96.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/bubblegum_96.dts b/arch/arm/dts/bubblegum_96.dts
index 4e34ebaa49..5b58d15594 100644
--- a/arch/arm/dts/bubblegum_96.dts
+++ b/arch/arm/dts/bubblegum_96.dts
@@ -12,8 +12,20 @@
model = "Bubblegum-96";
compatible = "ucrobotics,bubblegum-96", "actions,s900";
+ aliases {
+ serial5 =
+ };
+
+ chosen {
+ stdout-path = "serial5:115200n8";
+ };
+
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>;
};
};
+
+ {
+ status = "okay";
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 5/9] clk: Add Actions Semi OWL clock support
This commit adds Actions Semi OWL family base clock and S900 SoC specific
clock support. For S900 peripheral clock support, only UART clock has been
added for now.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2:
* Removed clk_owl.c and moved all clk code to clk_s900.c as per Simon's
review comments.
* Moved arch/arm/mach-owl/Kconfig changes to board support patch.
arch/arm/include/asm/arch-owl/clk_s900.h | 57 +
arch/arm/include/asm/arch-owl/regs_s900.h | 64 ++
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/owl/Kconfig | 12 ++
drivers/clk/owl/Makefile | 3 +
drivers/clk/owl/clk_s900.c| 138 ++
7 files changed, 276 insertions(+)
create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h
create mode 100644 drivers/clk/owl/Kconfig
create mode 100644 drivers/clk/owl/Makefile
create mode 100644 drivers/clk/owl/clk_s900.c
diff --git a/arch/arm/include/asm/arch-owl/clk_s900.h
b/arch/arm/include/asm/arch-owl/clk_s900.h
new file mode 100644
index 00..88e88f77f8
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/clk_s900.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Clock Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ *
+ */
+
+#ifndef _OWL_CLK_S900_H_
+#define _OWL_CLK_S900_H_
+
+#include
+
+struct owl_clk_priv {
+ phys_addr_t base;
+};
+
+/* BUSCLK register definitions */
+#define CMU_PDBGDIV_8 7
+#define CMU_PDBGDIV_SHIFT 26
+#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
+#define CMU_PERDIV_8 7
+#define CMU_PERDIV_SHIFT 20
+#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
+#define CMU_NOCDIV_2 1
+#define CMU_NOCDIV_SHIFT 19
+#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
+#define CMU_DMMCLK_SRC_APLL2
+#define CMU_DMMCLK_SRC_SHIFT 10
+#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
+#define CMU_APBCLK_DIV BIT(8)
+#define CMU_NOCCLK_SRC BIT(7)
+#define CMU_AHBCLK_DIV BIT(4)
+#define CMU_CORECLK_MASK 3
+#define CMU_CORECLK_CPLL BIT(1)
+#define CMU_CORECLK_HOSC BIT(0)
+
+/* COREPLL register definitions */
+#define CMU_COREPLL_EN BIT(9)
+#define CMU_COREPLL_HOSC_ENBIT(8)
+#define CMU_COREPLL_OUT(1104 / 24)
+
+/* DEVPLL register definitions */
+#define CMU_DEVPLL_CLK BIT(12)
+#define CMU_DEVPLL_EN BIT(8)
+#define CMU_DEVPLL_OUT (660 / 6)
+
+/* UARTCLK register definitions */
+#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
+
+/* DEVCLKEN1 register definitions */
+#define CMU_DEVCLKEN1_UART5BIT(21)
+
+#define PLL_STABILITY_WAIT_US 50
+
+#endif
diff --git a/arch/arm/include/asm/arch-owl/regs_s900.h
b/arch/arm/include/asm/arch-owl/regs_s900.h
new file mode 100644
index 00..9e9106ddaa
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/regs_s900.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Register Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ *
+ */
+
+#ifndef _OWL_REGS_S900_H_
+#define _OWL_REGS_S900_H_
+
+/* CMU registers */
+#define CMU_COREPLL(0x)
+#define CMU_DEVPLL (0x0004)
+#define CMU_DDRPLL (0x0008)
+#define CMU_NANDPLL(0x000C)
+#define CMU_DISPLAYPLL (0x0010)
+#define CMU_AUDIOPLL (0x0014)
+#define CMU_TVOUTPLL (0x0018)
+#define CMU_BUSCLK (0x001C)
+#define CMU_SENSORCLK (0x0020)
+#define CMU_LCDCLK (0x0024)
+#define CMU_DSICLK (0x0028)
+#define CMU_CSICLK (0x002C)
+#define CMU_DECLK (0x0030)
+#define CMU_BISPCLK(0x0034)
+#define CMU_IMXCLK (0x0038)
+#define CMU_HDECLK (0x003C)
+#define CMU_VDECLK (0x0040)
+#define CMU_VCECLK (0x0044)
+#define CMU_NANDCCLK (0x004C)
+#define CMU_SD0CLK (0x0050)
+#define CMU_SD1CLK (0x0054)
+#define CMU_SD2CLK (0x0058)
+#define CMU_UART0CLK (0x005C)
+#define CMU_UART1CLK (0x0060)
+#define CMU_UART2CLK (0x0064)
+#define CMU_PWM0CLK
Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii
> On 14 Jun 2018, at 19:39, Joe Hershberger wrote: > > On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote: >> We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of >> RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii() >> to enable the RX delay. >> The MASK was used in a wrong way. >> >> Signed-off-by: Janine Hagemann > > Acked-by: Joe Hershberger Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/9] arm: dts: s900: Add UART node
This commit adds UART node for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2: None
arch/arm/dts/s900.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index e9d47b1ff1..2bbb30a5a8 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -32,6 +32,14 @@
#size-cells = <0x2>;
ranges;
+ uart5: serial@e012a000 {
+ u-boot,dm-pre-reloc;
+ compatible = "actions,s900-serial";
+ reg = <0x0 0xe012a000 0x0 0x1000>;
+ clocks = < CLOCK_UART5>;
+ status = "disabled";
+ };
+
cmu: clock-controller@e016 {
u-boot,dm-pre-reloc;
compatible = "actions,s900-cmu";
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 9/9] MAINTAINERS: Add entries for Actions Semi OWL family
Add myself as the Maintainer for Actions Semi OWL family and its relevant board, drivers. Signed-off-by: Manivannan Sadhasivam --- Changes in v3: * Moved the change log from cover letter Changes in v2: None MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 642c448093..0f70cb04fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -145,6 +145,15 @@ T: git git://git.denx.de/u-boot-pxa.git F: arch/arm/cpu/pxa/ F: arch/arm/include/asm/arch-pxa/ +ARM OWL +M: Manivannan Sadhasivam +S: Maintained +F: arch/arm/include/asm/arch-owl/ +F: arch/arm/mach-owl/ +F: board/ucRobotics/ +F: drivers/clk/owl/ +F: drivers/serial/serial_owl.c + ARM RENESAS RMOBILE/R-CAR M: Nobuhiro Iwamatsu M: Marek Vasut -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 8/9] serial: Add Actions Semi OWL UART support
This commit adds Actions Semi OWL family UART support. This driver
relies on baudrate configured by primary bootloaders.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2: None
drivers/serial/Kconfig | 8 +++
drivers/serial/Makefile | 1 +
drivers/serial/serial_owl.c | 136
3 files changed, 145 insertions(+)
create mode 100644 drivers/serial/serial_owl.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 2940bd05dc..766e5ced03 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -625,6 +625,14 @@ config MSM_SERIAL
for example APQ8016 and MSM8916.
Single baudrate is supported in current implementation (115200).
+config OWL_SERIAL
+ bool "Actions Semi OWL UART"
+ depends on DM_SERIAL && ARCH_OWL
+ help
+ If you have a Actions Semi OWL based board and want to use the on-chip
+ serial port, say Y to this option. If unsure, say N.
+ Single baudrate is supported in current implementation (115200).
+
config PXA_SERIAL
bool "PXA serial port support"
help
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index e66899489e..9fa81d855d 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
obj-$(CONFIG_MVEBU_A3700_UART) += serial_mvebu_a3700.o
obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
+obj-$(CONFIG_OWL_SERIAL) += serial_owl.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
new file mode 100644
index 00..6fd97e2502
--- /dev/null
+++ b/drivers/serial/serial_owl.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi OWL SoCs UART driver
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* UART Registers */
+#defineOWL_UART_CTL(0x)
+#defineOWL_UART_RXDAT (0x0004)
+#defineOWL_UART_TXDAT (0x0008)
+#defineOWL_UART_STAT (0x000C)
+
+/* UART_CTL Register Definitions */
+#defineOWL_UART_CTL_PRS_NONE GENMASK(6, 4)
+#defineOWL_UART_CTL_STPS BIT(2)
+#defineOWL_UART_CTL_DWLS 3
+
+/* UART_STAT Register Definitions */
+#defineOWL_UART_STAT_TFES BIT(10) /* TX FIFO Empty Status
*/
+#defineOWL_UART_STAT_RFFS BIT(9) /* RX FIFO full Status
*/
+#defineOWL_UART_STAT_TFFU BIT(6) /* TX FIFO full Status
*/
+#defineOWL_UART_STAT_RFEM BIT(5) /* RX FIFO Empty Status
*/
+
+struct owl_serial_priv {
+ phys_addr_t base;
+};
+
+int owl_serial_setbrg(struct udevice *dev, int baudrate)
+{
+ /* Driver supports only fixed baudrate */
+ return 0;
+}
+
+static int owl_serial_getc(struct udevice *dev)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+
+ if (readl(priv->base + OWL_UART_STAT) & OWL_UART_STAT_RFEM)
+ return -EAGAIN;
+
+ return (int)(readl(priv->base + OWL_UART_RXDAT));
+}
+
+static int owl_serial_putc(struct udevice *dev,const char ch)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+
+ if (readl(priv->base + OWL_UART_STAT) & OWL_UART_STAT_TFFU)
+ return -EAGAIN;
+
+ writel(ch, priv->base + OWL_UART_TXDAT);
+
+ return 0;
+}
+
+static int owl_serial_pending(struct udevice *dev, boolinput)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+ unsigned int stat = readl(priv->base + OWL_UART_STAT);
+
+ if (input)
+ return !(stat & OWL_UART_STAT_RFEM);
+ else
+ return !(stat & OWL_UART_STAT_TFES);
+}
+
+static int owl_serial_probe(struct udevice *dev)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+ struct clk clk;
+ u32 uart_ctl;
+ int ret;
+
+ /* Set data, parity and stop bits */
+ uart_ctl = readl(priv->base + OWL_UART_CTL);
+ uart_ctl &= ~(OWL_UART_CTL_PRS_NONE);
+ uart_ctl &= ~(OWL_UART_CTL_STPS);
+ uart_ctl |= OWL_UART_CTL_DWLS;
+ writel(uart_ctl, priv->base + OWL_UART_CTL);
+
+ /* Enable UART clock */
+ ret = clk_get_by_index(dev, 0, );
+ if (ret < 0)
+ return ret;
+
+ ret = clk_enable();
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int owl_serial_ofdata_to_platdata(structudevice *dev)
+{
+ struct owl_serial_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr(dev);
+ if (priv->base == FDT_ADDR_T_NONE)
+
[U-Boot] [PATCH v3 2/9] board: Add uCRobotics Bubblegum-96 board support
This commit adds uCRobotics Bubblegum-96 board support. This board is
one of the 96Boards Consumer Edition platform based on Actions Semi
S900 SoC.
Features:
- Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
- 2GiB RAM
- 8GiB eMMC, uSD slot
- WiFi, Bluetooth and GPS module
- 2x Host, 1x Device USB port
- HDMI
- 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
U-Boot will be loaded by ATF at EL2 execution level. Relevant driver
support will be added in further commits.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2:
* Moved arch/arm/mach-owl/Kconfig changes from clk support patch
arch/arm/Kconfig | 1 +
arch/arm/dts/bubblegum_96.dts| 19 +++
arch/arm/mach-owl/Kconfig| 21
board/ucRobotics/bubblegum_96/Kconfig| 15 ++
board/ucRobotics/bubblegum_96/MAINTAINERS| 6 +++
board/ucRobotics/bubblegum_96/Makefile | 3 ++
board/ucRobotics/bubblegum_96/bubblegum_96.c | 56
configs/bubblegum_96_defconfig | 22
include/configs/bubblegum_96.h | 43 +++
9 files changed, 186 insertions(+)
create mode 100644 arch/arm/dts/bubblegum_96.dts
create mode 100644 board/ucRobotics/bubblegum_96/Kconfig
create mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
create mode 100644 board/ucRobotics/bubblegum_96/Makefile
create mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
create mode 100644 configs/bubblegum_96_defconfig
create mode 100644 include/configs/bubblegum_96.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec0bb5a42b..6e203f96aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1431,6 +1431,7 @@ source "board/spear/spear600/Kconfig"
source "board/spear/x600/Kconfig"
source "board/st/stv0991/Kconfig"
source "board/tcl/sl50/Kconfig"
+source "board/ucRobotics/bubblegum_96/Kconfig"
source "board/birdland/bav335x/Kconfig"
source "board/timll/devkit3250/Kconfig"
source "board/toradex/colibri_pxa270/Kconfig"
diff --git a/arch/arm/dts/bubblegum_96.dts b/arch/arm/dts/bubblegum_96.dts
new file mode 100644
index 00..4e34ebaa49
--- /dev/null
+++ b/arch/arm/dts/bubblegum_96.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Device Tree Source for Bubblegum-96
+//
+// Copyright (C) 2015 Actions Semi Co., Ltd.
+// Copyright (C) 2018 Manivannan Sadhasivam
+
+/dts-v1/;
+#include "s900.dtsi"
+
+/ {
+ model = "Bubblegum-96";
+ compatible = "ucrobotics,bubblegum-96", "actions,s900";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+};
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
index f695c16d1e..199e772988 100644
--- a/arch/arm/mach-owl/Kconfig
+++ b/arch/arm/mach-owl/Kconfig
@@ -3,4 +3,25 @@ if ARCH_OWL
config SYS_SOC
default "owl"
+choice
+prompt "Actions Semi OWL SoCs board select"
+optional
+
+config TARGET_BUBBLEGUM_96
+ bool "96Boards Bubblegum-96"
+ help
+ Support for 96Boards Bubblegum-96. This board complies with
+ 96Board Consumer Edition Specification. Features:
+ - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
+ - 2GiB RAM
+ - 8GiB eMMC, uSD slot
+ - WiFi, Bluetooth and GPS module
+ - 2x Host, 1x Device USB port
+ - HDMI
+ - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
+
+endchoice
+
+source "board/ucRobotics/bubblegum_96/Kconfig"
+
endif
diff --git a/board/ucRobotics/bubblegum_96/Kconfig
b/board/ucRobotics/bubblegum_96/Kconfig
new file mode 100644
index 00..2dd40d9b6a
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_BUBBLEGUM_96
+
+config SYS_BOARD
+ default "bubblegum_96"
+
+config SYS_VENDOR
+ default "ucRobotics"
+
+config SYS_SOC
+ default "s900"
+
+config SYS_CONFIG_NAME
+ default "bubblegum_96"
+
+endif
diff --git a/board/ucRobotics/bubblegum_96/MAINTAINERS
b/board/ucRobotics/bubblegum_96/MAINTAINERS
new file mode 100644
index 00..d0cb7278c6
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/MAINTAINERS
@@ -0,0 +1,6 @@
+BUBBLEGUM_96 BOARD
+M: Manivannan Sadhasivam
+S: Maintained
+F: board/ucRobotics/bubblegum_96/
+F: include/configs/bubblegum_96.h
+F: configs/bubblegum_96_defconfig
diff --git a/board/ucRobotics/bubblegum_96/Makefile
b/board/ucRobotics/bubblegum_96/Makefile
new file mode 100644
index 00..c4b524def2
--- /dev/null
+++ b/board/ucRobotics/bubblegum_96/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y := bubblegum_96.o
diff --git a/board/ucRobotics/bubblegum_96/bubblegum_96.c
b/board/ucRobotics/bubblegum_96/bubblegum_96.c
new file mode 100644
index 00..a4c202da19
--- /dev/null
+++
[U-Boot] [PATCH v3 3/9] dt-bindings: clock: Add S900 CMU register definitions
This commit adds Actions Semi S900 CMU register definitions to clock bindings. Signed-off-by: Manivannan Sadhasivam --- Changes in v3: * Moved the change log from cover letter Changes in v2: * Added missing Signed-off-by tag include/dt-bindings/clock/s900_cmu.h | 77 1 file changed, 77 insertions(+) create mode 100644 include/dt-bindings/clock/s900_cmu.h diff --git a/include/dt-bindings/clock/s900_cmu.h b/include/dt-bindings/clock/s900_cmu.h new file mode 100644 index 00..2685a6df4a --- /dev/null +++ b/include/dt-bindings/clock/s900_cmu.h @@ -0,0 +1,77 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2015 Actions Semi Co., Ltd. + * Copyright (C) 2018 Manivannan Sadhasivam + * + */ + +#ifndef _DT_BINDINGS_CLOCK_S900_CMU_H_ +#define _DT_BINDINGS_CLOCK_S900_CMU_H_ + +/* Module Clock ID */ +#define CLOCK_DDRCH1 0 +#define CLOCK_DMAC 1 +#define CLOCK_DDRCH0 2 +#define CLOCK_BROM 3 +#define CLOCK_NANDC0 4 +#define CLOCK_SD0 5 +#define CLOCK_SD1 6 +#define CLOCK_SD2 7 +#define CLOCK_DE 8 +#define CLOCK_LVDS 9 +#define CLOCK_EDP 10 +#define CLOCK_NANDC1 11 +#define CLOCK_DSI 12 +#define CLOCK_CSI0 13 +#define CLOCK_BISP 14 +#define CLOCK_CSI1 15 +#define CLOCK_SD3 16 +#define CLOCK_I2C4 17 +#define CLOCK_GPIO 18 +#define CLOCK_DMM 19 +#define CLOCK_I2STX20 +#define CLOCK_I2SRX21 +#define CLOCK_HDMIA22 +#define CLOCK_SPDIF23 +#define CLOCK_PCM0 24 +#define CLOCK_VDE 25 +#define CLOCK_VCE 26 +#define CLOCK_HDE 27 +#define CLOCK_SHARESRAM28 +#define CLOCK_CMU_DDR1 29 +#define CLOCK_GPU3D30 +#define CLOCK_CMUDDR0 31 +#define CLOCK_SPEED32 +#define CLOCK_I2C5 33 +#define CLOCK_THERMAL 34 +#define CLOCK_HDMI 35 +#define CLOCK_PWM4 36 +#define CLOCK_PWM5 37 +#define CLOCK_UART038 +#define CLOCK_UART139 +#define CLOCK_UART240 +#define CLOCK_IRC 41 +#define CLOCK_SPI0 42 +#define CLOCK_SPI1 43 +#define CLOCK_SPI2 44 +#define CLOCK_SPI3 45 +#define CLOCK_I2C0 46 +#define CLOCK_I2C1 47 +#define CLOCK_PCM1 48 +#define CLOCK_IMX 49 +#define CLOCK_UART650 +#define CLOCK_UART351 +#define CLOCK_UART452 +#define CLOCK_UART553 +#define CLOCK_ETHERNET 54 +#define CLOCK_PWM0 55 +#define CLOCK_PWM1 56 +#define CLOCK_PWM2 57 +#define CLOCK_PWM3 58 +#define CLOCK_TIMER59 +#define CLOCK_SE 60 +#define CLOCK_HDCP2TX 61 +#define CLOCK_I2C2 62 +#define CLOCK_I2C3 63 + +#endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/9] arm: dts: s900: Add Clock Management Unit (CMU) nodes
This commit adds Clock Management Unit (CMU) nodes for Actions Semi
S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2: None
arch/arm/dts/s900.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index 3bd14b82d4..e9d47b1ff1 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -6,18 +6,40 @@
// Copyright (C) 2018 Manivannan Sadhasivam
/dts-v1/;
+#include
/ {
compatible = "actions,s900";
#address-cells = <0x2>;
#size-cells = <0x2>;
+ losc: losc {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ diff24M: diff24M {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
+
soc {
u-boot,dm-pre-reloc;
compatible = "simple-bus";
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
+
+ cmu: clock-controller@e016 {
+ u-boot,dm-pre-reloc;
+ compatible = "actions,s900-cmu";
+ reg = <0x0 0xe016 0x0 0x1000>;
+ clocks = <>, <>;
+ clock-names = "losc", "diff24M";
+ #clock-cells = <1>;
+ };
};
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/9] arm: Add support for Actions Semi OWL SoC family
This commit adds Actions Semi OWL SoC family support with S900 as the
first target SoC.
Signed-off-by: Manivannan Sadhasivam
---
Changes in v3:
* Moved the change log from cover letter
Changes in v2: None
arch/arm/Kconfig| 9 +
arch/arm/Makefile | 1 +
arch/arm/dts/s900.dtsi | 23 +++
arch/arm/mach-owl/Kconfig | 6 ++
arch/arm/mach-owl/Makefile | 3 +++
arch/arm/mach-owl/sysmap-s900.c | 32
6 files changed, 74 insertions(+)
create mode 100644 arch/arm/dts/s900.dtsi
create mode 100644 arch/arm/mach-owl/Kconfig
create mode 100644 arch/arm/mach-owl/Makefile
create mode 100644 arch/arm/mach-owl/sysmap-s900.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d..ec0bb5a42b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,6 +699,13 @@ config ARCH_MX5
select BOARD_EARLY_INIT_F
imply MXC_GPIO
+config ARCH_OWL
+ bool "Actions Semi OWL SoCs"
+ select ARM64
+ select DM
+ select DM_SERIAL
+ select OF_CONTROL
+
config ARCH_QEMU
bool "QEMU Virtual Platform"
select DM
@@ -1335,6 +1342,8 @@ source "arch/arm/cpu/armv8/fsl-layerscape/Kconfig"
source "arch/arm/mach-orion5x/Kconfig"
+source "arch/arm/mach-owl/Kconfig"
+
source "arch/arm/mach-rmobile/Kconfig"
source "arch/arm/mach-meson/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 680c6e8516..f15b2287df 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -66,6 +66,7 @@ machine-$(CONFIG_ARCH_MVEBU) += mvebu
# TODO: rename CONFIG_ORION5X -> CONFIG_ARCH_ORION5X
machine-$(CONFIG_ORION5X) += orion5x
machine-$(CONFIG_ARCH_OMAP2PLUS) += omap2
+machine-$(CONFIG_ARCH_OWL) += owl
machine-$(CONFIG_ARCH_S5PC1XX) += s5pc1xx
machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_SNAPDRAGON) += snapdragon
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
new file mode 100644
index 00..3bd14b82d4
--- /dev/null
+++ b/arch/arm/dts/s900.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Device Tree Source for Actions Semi S900 SoC
+//
+// Copyright (C) 2015 Actions Semi Co., Ltd.
+// Copyright (C) 2018 Manivannan Sadhasivam
+
+/dts-v1/;
+
+/ {
+ compatible = "actions,s900";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+
+ soc {
+ u-boot,dm-pre-reloc;
+ compatible = "simple-bus";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+ ranges;
+ };
+};
+
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
new file mode 100644
index 00..f695c16d1e
--- /dev/null
+++ b/arch/arm/mach-owl/Kconfig
@@ -0,0 +1,6 @@
+if ARCH_OWL
+
+config SYS_SOC
+ default "owl"
+
+endif
diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
new file mode 100644
index 00..1b43dc2921
--- /dev/null
+++ b/arch/arm/mach-owl/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += sysmap-s900.o
diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
new file mode 100644
index 00..f78b639740
--- /dev/null
+++ b/arch/arm/mach-owl/sysmap-s900.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi S900 Memory map
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+#include
+#include
+
+static struct mm_region s900_mem_map[] = {
+ {
+ .virt = 0x0UL, /* DDR */
+ .phys = 0x0UL, /* DDR */
+ .size = 0x8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xE000UL, /* Peripheral block */
+ .phys = 0xE000UL, /* Peripheral block */
+ .size = 0x0800UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = s900_mem_map;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/9] Add SoC and Board support for Bubblegum-96
This patchset adds SoC support for Actions Semi S900 SoC and ucRobotics Bubblegum-96 board along with UART and Clock drivers. S900 SoC consists of 4 ARM Cortex-A53 cores up to 1.8GHz with Imagination Power VR G6230 GPU. More information on this SoC can be found in Actions Semi product page: http://www.actions-semi.com/en/productview.aspx?id=204 Bubblegum-96 board is one of the 96Boards Consumer Edition platform based on S900 SoC. This board has 2GB LPDDR3 operating at 533 MHz and 8GB eMMC along with other peripherals required by 96Boards Consumer Edition Specification. More information on this board can be found in 96Boards product page. https://www.96boards.org/product/bubblegum-96/ Most of the code is based on Actions tree found here: https://github.com/96boards-bubblegum/u-boot/ With this patchset, Bubblegum-96 board can boot into U-Boot shell. Thanks, Mani Manivannan Sadhasivam (9): arm: Add support for Actions Semi OWL SoC family board: Add uCRobotics Bubblegum-96 board support dt-bindings: clock: Add S900 CMU register definitions arm: dts: s900: Add Clock Management Unit (CMU) nodes clk: Add Actions Semi OWL clock support arm: dts: s900: Add UART node arm: dts: bubblegum_96: Enable UART5 for serial console serial: Add Actions Semi OWL UART support MAINTAINERS: Add entries for Actions Semi OWL family MAINTAINERS | 9 ++ arch/arm/Kconfig | 10 ++ arch/arm/Makefile| 1 + arch/arm/dts/bubblegum_96.dts| 31 + arch/arm/dts/s900.dtsi | 53 +++ arch/arm/include/asm/arch-owl/clk_s900.h | 57 arch/arm/include/asm/arch-owl/regs_s900.h| 64 + arch/arm/mach-owl/Kconfig| 27 arch/arm/mach-owl/Makefile | 3 + arch/arm/mach-owl/sysmap-s900.c | 32 + board/ucRobotics/bubblegum_96/Kconfig| 15 ++ board/ucRobotics/bubblegum_96/MAINTAINERS| 6 + board/ucRobotics/bubblegum_96/Makefile | 3 + board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 configs/bubblegum_96_defconfig | 22 +++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/owl/Kconfig | 12 ++ drivers/clk/owl/Makefile | 3 + drivers/clk/owl/clk_s900.c | 138 +++ drivers/serial/Kconfig | 8 ++ drivers/serial/Makefile | 1 + drivers/serial/serial_owl.c | 136 ++ include/configs/bubblegum_96.h | 43 ++ include/dt-bindings/clock/s900_cmu.h | 77 +++ 25 files changed, 809 insertions(+) create mode 100644 arch/arm/dts/bubblegum_96.dts create mode 100644 arch/arm/dts/s900.dtsi create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h create mode 100644 arch/arm/mach-owl/Kconfig create mode 100644 arch/arm/mach-owl/Makefile create mode 100644 arch/arm/mach-owl/sysmap-s900.c create mode 100644 board/ucRobotics/bubblegum_96/Kconfig create mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS create mode 100644 board/ucRobotics/bubblegum_96/Makefile create mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c create mode 100644 configs/bubblegum_96_defconfig create mode 100644 drivers/clk/owl/Kconfig create mode 100644 drivers/clk/owl/Makefile create mode 100644 drivers/clk/owl/clk_s900.c create mode 100644 drivers/serial/serial_owl.c create mode 100644 include/configs/bubblegum_96.h create mode 100644 include/dt-bindings/clock/s900_cmu.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
On 14.06.18 19:15, Simon Glass wrote:
> Hi Alex,
>
> On 14 June 2018 at 11:08, Alexander Graf wrote:
>>
>> On 06/14/2018 06:55 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 10:42, Alexander Graf wrote:
On 06/14/2018 06:33 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 10:26, Alexander Graf wrote:
>>
>> On 06/14/2018 06:13 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 14 June 2018 at 10:07, Alexander Graf wrote:
On 06/14/2018 05:53 PM, Simon Glass wrote:
>
> Hi Alex,
>
> On 14 June 2018 at 09:47, Alexander Graf wrote:
>>
>>
>>> Am 14.06.2018 um 17:43 schrieb Simon Glass :
>>>
>>> Hi Alex,
>>>
On 14 June 2018 at 08:22, Alexander Graf wrote:
> Am 14.06.2018 um 16:12 schrieb Simon Glass :
>
> Hi Alex,
>
>>> On 14 June 2018 at 07:41, Alexander Graf wrote:
>>> On 06/14/2018 02:58 PM, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
> On 14 June 2018 at 04:12, Alexander Graf
> wrote:
>
> On 06/13/2018 04:37 AM, Simon Glass wrote:
>
> With sandbox the U-Boot code is not mapped into the sandbox
> memory
> range
> so does not need to be excluded when allocating EFI memory.
> Update
> the
> EFI
> memory init code to take account of that.
>
> Also use mapmem instead of a cast to convert a memory address
> to
> a
> pointer.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Update to use mapmem instead of a cast
>
> lib/efi_loader/efi_memory.c | 31
> ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/lib/efi_loader/efi_memory.c
> b/lib/efi_loader/efi_memory.c
> index ec66af98ea..210e49ee8b 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
> pool_type,
> efi_uintn_t size, void **buffer)
> );
>if (r == EFI_SUCCESS) {
> - struct efi_pool_allocation *alloc = (void
> *)(uintptr_t)t;
> + struct efi_pool_allocation *alloc =
> map_sysmem(t,
> size);
This is still the wrong spot. We don't want the conversion to
happen when
going from an EFI internal address to an allocation, but when
determining
which addresses are usable in the first place.
>>>
>>> There seem to be two ways to do this:
>>>
>>> 1. Record addresses (ulong) in the EFI tables and use
>>> map_sysmem()
>>> before returning an address in the allocator
>>> 2. Store pointers in the EFI tables using map_sysmem(), then do
>>> no
>>> mapping in the allocator
>>>
>>> I've gone with option 1 since:
>>>
>>> - the EFI addresses are not pointers
>>> - it makes sandbox consistent with other architectures which use
>>> an
>>> address rather than a pointer in EFI tables
>>> - we don't normally do pointer arithmetic on the results of
>>> map_sysmem()
>>> - we normally map the memory when it is used rather than when it
>>> is
>>> set up
>>>
>>> I think you are asking for option 2. I think that would get very
>>> confusing. The addresses where things actually end up in sandbox
>>> are
>>> best kept to sandbox.
>>>
>>> Overall I feel that you are either missing the point of sandbox
>>>
[U-Boot] make Menuconfig Error
Cloned most recent u-boot 2018.06.14 make clean works make menuconfig fails: /bin/sh: 1: bison: not found scripts/kconfig/Makefile:229: recipe for target 'scripts/kconfig/dochecklxdialog' failed make[1]: *** [scripts/kconfig/dochecklxdialog] Error 1 Makefile:491: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 2 I've checked for bison, visually and with apt-cache search but I have found none. Will try rebuild based on u-boot from 2018.05.14 on SPDX errors, That version did build. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/12] net: phy: ti: Add binding for the CLK_OUT pin muxing
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote:
> The DP83867 has a muxing option for the CLK_OUT pin. It is possible
> to set CLK_OUT for different channels.
> Create a binding to select a specific clock for CLK_OUT pin.
>
> Based on commit '9708fb630d19ee51ae3aeb3a533e3010da0e8570' mainline
> linux kernel.
Same here...
> Signed-off-by: Janine Hagemann
> ---
> drivers/net/phy/ti.c | 24
> include/dt-bindings/net/ti-dp83867.h | 15 +++
Please also add to doc/device-tree-bindings/net/ti,dp83867.txt
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
> index cc04789..9044b0f 100644
> --- a/drivers/net/phy/ti.c
> +++ b/drivers/net/phy/ti.c
> @@ -96,6 +96,8 @@ DECLARE_GLOBAL_DATA_PTR;
>
> #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
> #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
> +#define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK (0x1f << 8)
> +#define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT 8
Reverse order of these defines and use the shift to make the mask.
Also, use GENMASK(13, DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT)
>
> /* CFG4 bits */
> #define DP83867_CFG4_PORT_MIRROR_ENBIT(0)
> @@ -113,6 +115,7 @@ struct dp83867_private {
> int io_impedance;
> int port_mirroring;
> bool rxctrl_strap_quirk;
> + int clk_output_sel;
> };
>
> /**
> @@ -213,6 +216,16 @@ static int dp83867_of_init(struct phy_device *phydev)
> struct udevice *dev = phydev->dev;
> int node = dev_of_offset(dev);
> const void *fdt = gd->fdt_blob;
> + u16 val;
> +
> + /* Optional configuration */
> +
> + /* Keep the default value if ti,clk-output-sel is not set
Please use standard mutli-line comment format "/*" gets its own line.
> +* or to high
> +*/
> +
> + dp83867->clk_output_sel = fdtdec_get_uint(fdt, node,
> + "ti,clk-output-sel",
> DP83867_CLK_O_SEL_REF_CLK);
>
> if (fdtdec_get_bool(fdt, node, "ti,max-output-impedance"))
> dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> @@ -239,6 +252,17 @@ static int dp83867_of_init(struct phy_device *phydev)
> dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob,
> dev_of_offset(dev),
> "ti,fifo-depth", -1);
>
> + /* Clock output selection if muxing property is set */
> + if (dp83867->clk_output_sel != DP83867_CLK_O_SEL_REF_CLK) {
> + val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR, phydev->addr);
> + val &= ~DP83867_IO_MUX_CFG_CLK_O_SEL_MASK;
> + val |= (dp83867->clk_output_sel <<
> + DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT);
> + phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR, phydev->addr, val);
> + }
> +
> return 0;
> }
> #else
> diff --git a/include/dt-bindings/net/ti-dp83867.h
> b/include/dt-bindings/net/ti-dp83867.h
> index b8e5df6..85d08f6 100644
> --- a/include/dt-bindings/net/ti-dp83867.h
> +++ b/include/dt-bindings/net/ti-dp83867.h
> @@ -31,4 +31,19 @@
> #define DP83867_RGMIIDCTL_3_75_NS 0xe
> #define DP83867_RGMIIDCTL_4_00_NS 0xf
>
> +/* IO_MUX_CFG - Clock output selection */
> +#define DP83867_CLK_O_SEL_CHN_A_RCLK 0x0
> +#define DP83867_CLK_O_SEL_CHN_B_RCLK 0x1
> +#define DP83867_CLK_O_SEL_CHN_C_RCLK 0x2
> +#define DP83867_CLK_O_SEL_CHN_D_RCLK 0x3
> +#define DP83867_CLK_O_SEL_CHN_A_RCLK_DIV5 0x4
> +#define DP83867_CLK_O_SEL_CHN_B_RCLK_DIV5 0x5
> +#define DP83867_CLK_O_SEL_CHN_C_RCLK_DIV5 0x6
> +#define DP83867_CLK_O_SEL_CHN_D_RCLK_DIV5 0x7
> +#define DP83867_CLK_O_SEL_CHN_A_TCLK 0x8
> +#define DP83867_CLK_O_SEL_CHN_B_TCLK 0x9
> +#define DP83867_CLK_O_SEL_CHN_C_TCLK 0xA
> +#define DP83867_CLK_O_SEL_CHN_D_TCLK 0xB
> +#define DP83867_CLK_O_SEL_REF_CLK 0xC
> +
> #endif
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y
On 14.06.18 19:55, Heinrich Schuchardt wrote: > On 06/14/2018 12:41 AM, Mark Kettenis wrote: >> This series makes it possible to run EFI applications in non-secure >> mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and >> Banana Pi boards using the PSCI implementation provided by U-Boot. >> >> The second version avoids using r3 to pass the original stack pointer. >> For some reason that register gets clobbered on the Banana Pi. Instead >> this version just migrates SP_svc to SP_hyp. >> >> This third version avoids saving r3 on the stack and fixes an include >> guard as suggested by Alexander Graf. >> >> Mark Kettenis (3): >> ARM: HYP/non-sec: migrate stack >> efi_loader: ARM: run EFI payloads non-secure >> Revert "efi_loader: no support for ARMV7_NONSEC=y" >> >> arch/arm/cpu/armv7/nonsec_virt.S | 2 ++ >> cmd/bootefi.c| 32 >> doc/README.uefi | 2 -- >> lib/efi_loader/Kconfig | 2 -- >> 4 files changed, 34 insertions(+), 4 deletions(-) >> > Hello Mark, > > with this patch series running bootefi hello twice in sequence fails on > the BananaPi. > > => bootefi hello > Scanning disk m...@01c0f000.blk... > Found 3 disks > WARNING: booting without device tree > ## Starting EFI application at 4200 ... > WARNING: using memory device/image path, this may confuse some payloads! > Hello, world! > Running on UEFI 2.7 > Have SMBIOS table > Load options: earlyprintk nosmp > ## Application terminated, r = 0 > => bootefi hello > WARNING: booting without device tree > ## Starting EFI application at 4200 ... > WARNING: using memory device/image path, this may confuse some payloads! > > > Please, keep in mind that we expect multiple EFI binaries to be executed > in sequence. E.g. the first binary installs a driver. The second is the > application using it. > > Running iPXE's snp.efi binary shows changed behavior on the console. New > characters are displayed in "slow motion" (3 characters per second). Cache disabled maybe? Alex > Setting up the network interface fails in iPXE. > > Best regards > > Heinrich > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y
On 06/14/2018 12:41 AM, Mark Kettenis wrote: > This series makes it possible to run EFI applications in non-secure > mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and > Banana Pi boards using the PSCI implementation provided by U-Boot. > > The second version avoids using r3 to pass the original stack pointer. > For some reason that register gets clobbered on the Banana Pi. Instead > this version just migrates SP_svc to SP_hyp. > > This third version avoids saving r3 on the stack and fixes an include > guard as suggested by Alexander Graf. > > Mark Kettenis (3): > ARM: HYP/non-sec: migrate stack > efi_loader: ARM: run EFI payloads non-secure > Revert "efi_loader: no support for ARMV7_NONSEC=y" > > arch/arm/cpu/armv7/nonsec_virt.S | 2 ++ > cmd/bootefi.c| 32 > doc/README.uefi | 2 -- > lib/efi_loader/Kconfig | 2 -- > 4 files changed, 34 insertions(+), 4 deletions(-) > Hello Mark, with this patch series running bootefi hello twice in sequence fails on the BananaPi. => bootefi hello Scanning disk m...@01c0f000.blk... Found 3 disks WARNING: booting without device tree ## Starting EFI application at 4200 ... WARNING: using memory device/image path, this may confuse some payloads! Hello, world! Running on UEFI 2.7 Have SMBIOS table Load options: earlyprintk nosmp ## Application terminated, r = 0 => bootefi hello WARNING: booting without device tree ## Starting EFI application at 4200 ... WARNING: using memory device/image path, this may confuse some payloads! Please, keep in mind that we expect multiple EFI binaries to be executed in sequence. E.g. the first binary installs a driver. The second is the application using it. Running iPXE's snp.efi binary shows changed behavior on the console. New characters are displayed in "slow motion" (3 characters per second). Setting up the network interface fails in iPXE. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/12] drivers: net: designware: Add reading of DT phy-handle node
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote: > Add the ability to read the phy-handle node of the > gmac. Upon reading this handle the phy-id > can be stored based on the reg node in the DT. > > The phy-handle also needs to be stored and passed > to the phy to access any phy data that is available. > > Signed-off-by: Janine Hagemann Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote: > Using PHY internal delays in combination with the phy-mode > rgmii-id/rxid/txid was not possible. Only rgmii was supported. > > Now we can disable rockchip's gmac delay lines and also use > rgmii-id/rxid/txid. > > Based on commit 'eaf70ad14cbbb99d46b78b1307628a16a3f6075d' from > mainline linux kernel. Same here... > Signed-off-by: Janine Hagemann Otherwise, Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12] net: phy: ti: add workaround for incorrect RX_CTRL pin strap
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote: > The data manual for DP83867IR/CR, SNLS484E[1], revised march 2017, > advises that strapping RX_DV/RX_CTRL pin in mode 1 and 2 is not > supported (see note below Table 5 (4-Level Strap Pins)). > > There are some boards which have the pin strapped this way and need > software workaround suggested by the data manual. Bit[7] of > Configuration Register 4 (address 0x0031) must be cleared to 0. This > ensures proper operation of the PHY. > > Implement driver support for device-tree property meant to advertise > the wrong strapping. > > [1] http://www.ti.com/lit/ds/snls484e/snls484e.pdf > > Based on commit '371444764b9882d754d1e67dd212c932359a2293' of mainline > linux kernel. And here... > Signed-off-by: Janine Hagemann Otherwise, Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: Add 64-bit setjmp/longjmp implementation
> Am 14.06.2018 um 19:15 schrieb Ivan Gorinov : > > On Wed, Jun 13, 2018 at 05:36:26PM -0700, Ivan Gorinov wrote: > >>> But bootefi selftest with your patch leads to an immediate reset of the >>> qemu-x86_64 board. >> >> Reproduced the qemu-x86_64 reset. >> The "info registers" command shows CR0.MP = 0. >> Setting it in 64-bit startup code did not help. >> I will try to fix that. >> >> On a 64-bit Minnowboard configuration, bootefi works without reset. > > The "bootefi selftest" command works on qemu-x86_64 when $loadaddr is changed: > => env set loadaddr 0x1000 > > Another patch "x86: use EFI calling convention for efi_main on x86_64" > also needs to be applied. > > The self test starts but crashes on 'manage protocols': > > Tearing down 'graphical output' > Tearing down 'graphical output' succeeded > > Setting up 'manage protocols' > > > Same effect with a 64-bit build for Minnowboard. I see the same with the sandbox patch set I just sent. IIUC sonething goes wrong in varargs handling. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/12] net: phy: ti: Recover from "port mirroring" N/A MODE4
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote: > The DP83867 when not properly bootstrapped - especially with LED_0 pin - > can enter N/A MODE4 for "port mirroring" feature. > > To provide normal operation of the PHY, one needs not only to explicitly > disable the port mirroring feature, but as well stop some IC internal > testing (which disables RGMII communication). > > To do that the STRAP_STS1 (0x006E) register must be read and RESERVED bit > 11 examined. When it is set, the another RESERVED bit (11) at PHYCR > (0x0010) register must be clear to disable testing mode and enable RGMII > communication. > > Thorough explanation of the problem can be found at following e2e thread: > "DP83867IR: Problem with RESERVED bits in PHY Control Register (PHYCR) - > Linux driver" > > https://e2e.ti.com/support/interface/ethernet/f/903/p/571313/2096954#2096954 > > Based on commit 'ac6e058b75be71208e98a5808453aae9a17be480' of mainline linux > kernel. Same comment about commit reference format. > > Signed-off-by: Janine Hagemann Otherwise, Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] clk: Add Actions Semi OWL clock support
Hi, On 14 June 2018 at 11:25, Manivannan Sadhasivam wrote: > Hi Simon, > > On Thu, Jun 14, 2018 at 08:16:53AM -0600, Simon Glass wrote: >> Hi, >> >> On 14 June 2018 at 07:13, Manivannan Sadhasivam >> wrote: >> > Hi Simon, >> > >> > On Thu, Jun 14, 2018 at 06:58:40AM -0600, Simon Glass wrote: >> >> Hi, >> >> >> >> On 12 June 2018 at 22:15, Manivannan Sadhasivam >> >> wrote: >> >> > This commit adds Actions Semi OWL family base clock and S900 SoC >> >> > specific >> >> > clock support. For S900 peripheral clock support, only UART clock has >> >> > been >> >> > added for now. >> >> > >> >> > Signed-off-by: Manivannan Sadhasivam >> >> > --- >> >> > arch/arm/include/asm/arch-owl/clk_s900.h | 57 + >> >> > arch/arm/include/asm/arch-owl/regs_s900.h | 64 ++ >> >> > drivers/clk/Kconfig | 1 + >> >> > drivers/clk/Makefile | 1 + >> >> > drivers/clk/owl/Kconfig | 12 ++ >> >> > drivers/clk/owl/Makefile | 3 + >> >> > drivers/clk/owl/clk_s900.c| 138 ++ >> >> > 7 files changed, 276 insertions(+) >> >> > create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h >> >> > create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h >> >> > create mode 100644 drivers/clk/owl/Kconfig >> >> > create mode 100644 drivers/clk/owl/Makefile >> >> > create mode 100644 drivers/clk/owl/clk_s900.c >> >> >> >> This says v2 but I don't see a change log. Have you tried using >> >> patman? It does this for you easily. >> >> >> > >> > Sorry, I have added the changelog in coverletter of the patchseries! Is it >> > a >> > bad practice in U-Boot? >> >> I'm not sure about bad practice, but without it, it's hard to know >> what you've changed in this patch. >> > > Okay. Should I send another version adding changelog in commit? That would make me happy :-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote:
> This patch adds support for enabling or disabling the lane swapping
> (called "port mirroring" in PHY's CFG4 register) feature of the DP83867
> TI's PHY device.
>
> One use case is when bootstrap configuration enables this feature (because
> of e.g. LED_0 wrong wiring) so then one needs to disable it in software
> (at u-boot/Linux).
>
> Based on commit 'fc6d39c39581f3c12c95f166ce95ef8beb2047e8' of mainline
> linux kernel
I think you are always supposed to include the summary text when
referencing a commit as well. Does checkpatch not complain about this?
>
> Signed-off-by: Janine Hagemann
Otherwise,
Acked-by: Joe Hershberger
> ---
> drivers/net/phy/ti.c | 40
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
> index d7ae881..086ea4a 100644
> --- a/drivers/net/phy/ti.c
> +++ b/drivers/net/phy/ti.c
> @@ -24,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
> #define DP83867_CTRL 0x1f
>
> /* Extended Registers */
> +#define DP83867_CFG4 0x0031
> #define DP83867_RGMIICTL 0x0032
> #define DP83867_RGMIIDCTL 0x0086
> #define DP83867_IO_MUX_CFG 0x0170
> @@ -92,11 +93,21 @@ DECLARE_GLOBAL_DATA_PTR;
> #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
> #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
>
> +/* CFG4 bits */
> +#define DP83867_CFG4_PORT_MIRROR_ENBIT(0)
> +
> +enum {
> + DP83867_PORT_MIRRORING_KEEP,
> + DP83867_PORT_MIRRORING_EN,
> + DP83867_PORT_MIRRORING_DIS,
> +};
> +
> struct dp83867_private {
> int rx_id_delay;
> int tx_id_delay;
> int fifo_depth;
> int io_impedance;
> + int port_mirroring;
> };
>
> /**
> @@ -165,6 +176,26 @@ void phy_write_mmd_indirect(struct phy_device *phydev,
> int prtad,
> phy_write(phydev, addr, MII_MMD_DATA, data);
> }
>
> +static int dp83867_config_port_mirroring(struct phy_device *phydev)
> +{
> + struct dp83867_private *dp83867 =
> + (struct dp83867_private *)phydev->priv;
> + u16 val;
> +
> + val = phy_read_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
> +phydev->addr);
> +
> + if (dp83867->port_mirroring == DP83867_PORT_MIRRORING_EN)
> + val |= DP83867_CFG4_PORT_MIRROR_EN;
> + else
> + val &= ~DP83867_CFG4_PORT_MIRROR_EN;
> +
> + phy_write_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
> + phydev->addr, val);
> +
> + return 0;
> +}
> +
> #if defined(CONFIG_DM_ETH)
> /**
> * dp83867_data_init - Convenience function for setting PHY specific data
> @@ -191,6 +222,12 @@ static int dp83867_of_init(struct phy_device *phydev)
> dp83867->tx_id_delay = fdtdec_get_uint(gd->fdt_blob,
> dev_of_offset(dev),
> "ti,tx-internal-delay", -1);
>
> + if (fdtdec_get_bool(fdt, node, "enet-phy-lane-swap"))
> + dp83867->port_mirroring = DP83867_PORT_MIRRORING_EN;
> +
> + if (fdtdec_get_bool(fdt, node, "enet-phy-lane-no-swap"))
> + dp83867->port_mirroring = DP83867_PORT_MIRRORING_DIS;
> +
> dp83867->fifo_depth = fdtdec_get_uint(gd->fdt_blob,
> dev_of_offset(dev),
> "ti,fifo-depth", -1);
>
> @@ -307,6 +344,9 @@ static int dp83867_config(struct phy_device *phydev)
> }
> }
>
> + if (dp83867->port_mirroring != DP83867_PORT_MIRRORING_KEEP)
> + dp83867_config_port_mirroring(phydev);
> +
> genphy_config_aneg(phydev);
> return 0;
>
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register write
On Thu, Jun 14, 2018 at 12:09 PM, Trent Piepho wrote:
> On Thu, 2018-06-14 at 10:53 +, u-boot-requ...@lists.denx.de wrote:
>> Message: 52
>> Date: Thu, 14 Jun 2018 11:48:48 +0200
>> From: Janine Hagemann
>> To: albert.u.b...@aribaud.net, s...@chromium.org,
>> philipp.toms...@theobroma-systems.com, w.ego...@phytec.de,
>> joe.hershber...@ni.com, u-boot@lists.denx.de
>> Subject: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register
>> write
>> Message-ID: <1528969736-44037-4-git-send-email-j.hagem...@phytec.de>
>>
>> The register was not read before the writing, so the
>> previous value was overwritten.
Was this changed because of some problem? Please include more details
in the change log.
>> @@ -233,9 +235,14 @@ static int dp83867_config(struct phy_device *phydev)
>> val | DP83867_SW_RESTART);
>>
>> if (phy_interface_is_rgmii(phydev)) {
>> + val = phy_read(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL);
>> + if (val < 0)
>> + return val;
>> + val &= ~DP83867_PHYCR_FIFO_DEPTH_MASK;
>> + val |= (dp83867->fifo_depth << DP83867_PHYCR_FIFO_DEPTH_SHIFT);
>> ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
>> - (DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
>> - (dp83867->fifo_depth <<
>> DP83867_PHYCR_FIFO_DEPTH_SHIFT));
>> + val);
>> +
>> if (ret)
>> goto err_out;
>> } else if (phy_interface_is_sgmii(phydev)) {
>
> If any of the bits that prevent the phy from working are set, like
> DEEP_POWER_DOWN_EN, POWER_SAVE_MODE, and so on, they won't be reset
> anymore. I.e., put phy in power save mode, reboot, phy doesn't work
> anymore. I think the code here is suppose to be configuring the phy,
> rather than changing a configuration that was done elsewhere.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii
On Thu, Jun 14, 2018 at 4:48 AM, Janine Hagemann wrote: > We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of > RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii() > to enable the RX delay. > The MASK was used in a wrong way. > > Signed-off-by: Janine Hagemann Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: zynq_gem: Initialize val variable in zynq_gem_miiphy_read()
On Thu, Jun 14, 2018 at 2:08 AM, Michal Simek wrote:
> phyread can timeout and val will contain random value. Initialize it to
> zero not to report random value in case of error.
>
> Signed-off-by: Michal Simek
Acked-by: Joe Hershberger
> ---
>
> Reported by: Coverity (local)
>
> ---
> drivers/net/zynq_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index a817f2e5d69b..d1138fe0903d 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -609,7 +609,7 @@ static int zynq_gem_miiphy_read(struct mii_dev *bus, int
> addr,
> {
> struct zynq_gem_priv *priv = bus->priv;
> int ret;
> - u16 val;
> + u16 val = 0;
>
> ret = phyread(priv, addr, reg, );
> debug("%s 0x%x, 0x%x, 0x%x, 0x%x\n", __func__, addr, reg, val, ret);
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] clk: Add Actions Semi OWL clock support
Hi Simon, On Thu, Jun 14, 2018 at 08:16:53AM -0600, Simon Glass wrote: > Hi, > > On 14 June 2018 at 07:13, Manivannan Sadhasivam > wrote: > > Hi Simon, > > > > On Thu, Jun 14, 2018 at 06:58:40AM -0600, Simon Glass wrote: > >> Hi, > >> > >> On 12 June 2018 at 22:15, Manivannan Sadhasivam > >> wrote: > >> > This commit adds Actions Semi OWL family base clock and S900 SoC specific > >> > clock support. For S900 peripheral clock support, only UART clock has > >> > been > >> > added for now. > >> > > >> > Signed-off-by: Manivannan Sadhasivam > >> > --- > >> > arch/arm/include/asm/arch-owl/clk_s900.h | 57 + > >> > arch/arm/include/asm/arch-owl/regs_s900.h | 64 ++ > >> > drivers/clk/Kconfig | 1 + > >> > drivers/clk/Makefile | 1 + > >> > drivers/clk/owl/Kconfig | 12 ++ > >> > drivers/clk/owl/Makefile | 3 + > >> > drivers/clk/owl/clk_s900.c| 138 ++ > >> > 7 files changed, 276 insertions(+) > >> > create mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h > >> > create mode 100644 arch/arm/include/asm/arch-owl/regs_s900.h > >> > create mode 100644 drivers/clk/owl/Kconfig > >> > create mode 100644 drivers/clk/owl/Makefile > >> > create mode 100644 drivers/clk/owl/clk_s900.c > >> > >> This says v2 but I don't see a change log. Have you tried using > >> patman? It does this for you easily. > >> > > > > Sorry, I have added the changelog in coverletter of the patchseries! Is it a > > bad practice in U-Boot? > > I'm not sure about bad practice, but without it, it's hard to know > what you've changed in this patch. > Okay. Should I send another version adding changelog in commit? Thanks, Mani > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: Add 64-bit setjmp/longjmp implementation
On Wed, Jun 13, 2018 at 05:36:26PM -0700, Ivan Gorinov wrote: > > But bootefi selftest with your patch leads to an immediate reset of the > > qemu-x86_64 board. > > Reproduced the qemu-x86_64 reset. > The "info registers" command shows CR0.MP = 0. > Setting it in 64-bit startup code did not help. > I will try to fix that. > > On a 64-bit Minnowboard configuration, bootefi works without reset. The "bootefi selftest" command works on qemu-x86_64 when $loadaddr is changed: => env set loadaddr 0x1000 Another patch "x86: use EFI calling convention for efi_main on x86_64" also needs to be applied. The self test starts but crashes on 'manage protocols': Tearing down 'graphical output' Tearing down 'graphical output' succeeded Setting up 'manage protocols' Same effect with a 64-bit build for Minnowboard. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
Hi Alex,
On 14 June 2018 at 11:08, Alexander Graf wrote:
>
> On 06/14/2018 06:55 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 June 2018 at 10:42, Alexander Graf wrote:
>>>
>>> On 06/14/2018 06:33 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 10:26, Alexander Graf wrote:
>
> On 06/14/2018 06:13 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 June 2018 at 10:07, Alexander Graf wrote:
>>>
>>> On 06/14/2018 05:53 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 09:47, Alexander Graf wrote:
>
>
>> Am 14.06.2018 um 17:43 schrieb Simon Glass :
>>
>> Hi Alex,
>>
>>> On 14 June 2018 at 08:22, Alexander Graf wrote:
>>>
>>>
>>>
Am 14.06.2018 um 16:12 schrieb Simon Glass :
Hi Alex,
>> On 14 June 2018 at 07:41, Alexander Graf wrote:
>> On 06/14/2018 02:58 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
On 14 June 2018 at 04:12, Alexander Graf
wrote:
On 06/13/2018 04:37 AM, Simon Glass wrote:
With sandbox the U-Boot code is not mapped into the sandbox
memory
range
so does not need to be excluded when allocating EFI memory.
Update
the
EFI
memory init code to take account of that.
Also use mapmem instead of a cast to convert a memory address
to
a
pointer.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Update to use mapmem instead of a cast
lib/efi_loader/efi_memory.c | 31
++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c
b/lib/efi_loader/efi_memory.c
index ec66af98ea..210e49ee8b 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
pool_type,
efi_uintn_t size, void **buffer)
);
if (r == EFI_SUCCESS) {
- struct efi_pool_allocation *alloc = (void
*)(uintptr_t)t;
+ struct efi_pool_allocation *alloc =
map_sysmem(t,
size);
>>>
>>>
>>> This is still the wrong spot. We don't want the conversion to
>>> happen when
>>> going from an EFI internal address to an allocation, but when
>>> determining
>>> which addresses are usable in the first place.
>>
>> There seem to be two ways to do this:
>>
>> 1. Record addresses (ulong) in the EFI tables and use
>> map_sysmem()
>> before returning an address in the allocator
>> 2. Store pointers in the EFI tables using map_sysmem(), then do
>> no
>> mapping in the allocator
>>
>> I've gone with option 1 since:
>>
>> - the EFI addresses are not pointers
>> - it makes sandbox consistent with other architectures which use
>> an
>> address rather than a pointer in EFI tables
>> - we don't normally do pointer arithmetic on the results of
>> map_sysmem()
>> - we normally map the memory when it is used rather than when it
>> is
>> set up
>>
>> I think you are asking for option 2. I think that would get very
>> confusing. The addresses where things actually end up in sandbox
>> are
>> best kept to sandbox.
>>
>> Overall I feel that you are either missing the point of sandbox
>> addressing, or don't agree with how it is done. But it does work
>> pretty well and we don't get a lot of confusion with sandbox
>> pointers
>>
Re: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register write
On Thu, 2018-06-14 at 10:53 +, u-boot-requ...@lists.denx.de wrote:
> Message: 52
> Date: Thu, 14 Jun 2018 11:48:48 +0200
> From: Janine Hagemann
> To: albert.u.b...@aribaud.net, s...@chromium.org,
> philipp.toms...@theobroma-systems.com, w.ego...@phytec.de,
> joe.hershber...@ni.com, u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register
> write
> Message-ID: <1528969736-44037-4-git-send-email-j.hagem...@phytec.de>
>
> The register was not read before the writing, so the
> previous value was overwritten.
>
> @@ -233,9 +235,14 @@ static int dp83867_config(struct phy_device *phydev)
> val | DP83867_SW_RESTART);
>
> if (phy_interface_is_rgmii(phydev)) {
> + val = phy_read(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL);
> + if (val < 0)
> + return val;
> + val &= ~DP83867_PHYCR_FIFO_DEPTH_MASK;
> + val |= (dp83867->fifo_depth << DP83867_PHYCR_FIFO_DEPTH_SHIFT);
> ret = phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL,
> - (DP83867_MDI_CROSSOVER_AUTO << DP83867_MDI_CROSSOVER) |
> - (dp83867->fifo_depth <<
> DP83867_PHYCR_FIFO_DEPTH_SHIFT));
> + val);
> +
> if (ret)
> goto err_out;
> } else if (phy_interface_is_sgmii(phydev)) {
If any of the bits that prevent the phy from working are set, like
DEEP_POWER_DOWN_EN, POWER_SAVE_MODE, and so on, they won't be reset
anymore. I.e., put phy in power save mode, reboot, phy doesn't work
anymore. I think the code here is suppose to be configuring the phy,
rather than changing a configuration that was done elsewhere.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] sandbox: efi_loader support
On 06/14/2018 06:55 PM, Simon Glass wrote: Hi, On 14 June 2018 at 10:33, Alexander Graf wrote: This patch set augments Simon's patch set for efi_loader support in sandbox[1], but follows a different memory allocation scheme. Instead of keeping U-Boot (physical) addresses in the EFI memory map, this patch set makes the EFI memory map contain host virtual (virtual) addresses. That way most logic "just works" and all EFI interfaces automatically gain sandbox awareness. With this patch set in place, I can run a good chunk of the selftest suite as well as efi binaries compiled using gnu-efi. Can you rebase this on top of my series? You seem to have picked up only a few patches from my series. Ideally I'd like to get those applied so that sandbox works, and then do future work on top of that. I did that on purpose, yes. I omitted patches that we either don't need (like the smbios one, because we already call the helpers with pointers) or that I think move us into the wrong direction (like the one that calls map_sysmem() in the allocation path or the new bootefi test target where I would rather like to see the selftest target extended. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
On 06/14/2018 06:55 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 10:42, Alexander Graf wrote:
On 06/14/2018 06:33 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 10:26, Alexander Graf wrote:
On 06/14/2018 06:13 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 10:07, Alexander Graf wrote:
On 06/14/2018 05:53 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 09:47, Alexander Graf wrote:
Am 14.06.2018 um 17:43 schrieb Simon Glass :
Hi Alex,
On 14 June 2018 at 08:22, Alexander Graf wrote:
Am 14.06.2018 um 16:12 schrieb Simon Glass :
Hi Alex,
On 14 June 2018 at 07:41, Alexander Graf wrote:
On 06/14/2018 02:58 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 04:12, Alexander Graf
wrote:
On 06/13/2018 04:37 AM, Simon Glass wrote:
With sandbox the U-Boot code is not mapped into the sandbox
memory
range
so does not need to be excluded when allocating EFI memory.
Update
the
EFI
memory init code to take account of that.
Also use mapmem instead of a cast to convert a memory address
to
a
pointer.
Signed-off-by: Simon Glass
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Update to use mapmem instead of a cast
lib/efi_loader/efi_memory.c | 31
++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c
b/lib/efi_loader/efi_memory.c
index ec66af98ea..210e49ee8b 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
pool_type,
efi_uintn_t size, void **buffer)
);
if (r == EFI_SUCCESS) {
- struct efi_pool_allocation *alloc = (void
*)(uintptr_t)t;
+ struct efi_pool_allocation *alloc =
map_sysmem(t,
size);
This is still the wrong spot. We don't want the conversion to
happen when
going from an EFI internal address to an allocation, but when
determining
which addresses are usable in the first place.
There seem to be two ways to do this:
1. Record addresses (ulong) in the EFI tables and use
map_sysmem()
before returning an address in the allocator
2. Store pointers in the EFI tables using map_sysmem(), then do
no
mapping in the allocator
I've gone with option 1 since:
- the EFI addresses are not pointers
- it makes sandbox consistent with other architectures which use
an
address rather than a pointer in EFI tables
- we don't normally do pointer arithmetic on the results of
map_sysmem()
- we normally map the memory when it is used rather than when it
is
set up
I think you are asking for option 2. I think that would get very
confusing. The addresses where things actually end up in sandbox
are
best kept to sandbox.
Overall I feel that you are either missing the point of sandbox
addressing, or don't agree with how it is done. But it does work
pretty well and we don't get a lot of confusion with sandbox
pointers
since we typically use the address until the last moment.
I've assembled a quick tree for version 2. With that I'm able to
run
a
simple hello world efi application. Grub refuses to start because
it
wants
memory in the low 32bit and also emits random PIO accessing
functions, which
obviously don't work work from user space.
But overall, I think this is the right path to tackle this:
https://github.com/agraf/u-boot/tree/efi-sandbox
What do you mean by version 2?
Option 2 is what you called it. It's the only option we have to
make
efi binaries work.
It looks like you've added one patch,
so will you send that to the list?
It's more than 1 patch. And yes, I'll send them.
Anyway, I hope I can convince you of the above, the way sandbox
memory
works.
I still dislike option 1 :)
The reason is simple: The efi memory map is available to efi
payloads.
It's perfectly legal for them to do a static allocation at a
particular
address. We also share a lot of (host) pointers for callbacks and
structs
already with efi applications, so there is no real point to have a
split
brain situation between u-boot and host pointers.
OK so you mean they don't have to allocate memory before using it?
How
then do you make sure that there is no conflict? I thought EFI was
an
API?
You allocate it, but payloads expect that the address you pass in as
address you allocate at is the pointer/address that gets returned.
Can you please point me to that? Are you referring to this call?
static efi_status_t EFIAPI efi_get_memory_map_ext(
efi_uintn_t *memory_map_size,
struct efi_mem_desc *memory_map,
efi_uintn_t *map_key,
efi_uintn_t *descriptor_size,
uint32_t *descriptor_version)
If so, we can still support that.
In a nutshell, what you're proposing is that the efi quivalent of
mmap(addr, MAP_FIXED) returns something != addr. That will break
things.
I
Re: [U-Boot] [PATCH v2 2/3] net: Add option to prefer bootp/dhcp serverip
On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf wrote: > Currently we can choose between 2 different types of behavior for the > serverip variable: > > 1) Always overwrite it with the DHCP server IP address (default) > 2) Ignore what the DHCP server says (CONFIG_BOOTP_SERVERIP) > > This patch adds a 3rd option: > > 3) Use serverip from DHCP if no serverip is given > (CONFIG_BOOTP_PREFER_SERVERIP) > > With this new option, we can have the default case that a boot file gets > loaded from the DHCP provided TFTP server work while allowing users to > specify their own serverip variable to explicitly use a different tftp > server. > > Signed-off-by: Alexander Graf Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] efi patch queue 2018-06-14
Hi Tom, This is my current patch queue for efi. Please pull. Alex The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7: ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400) are available in the git repository at: git://github.com/agraf/u-boot.git tags/signed-efi-next for you to fetch changes up to 58bc69d20aaf2e32e93e977d708fe6a1af0ad6d1: efi_loader: Allocate memory handle for mem dp (2018-06-14 10:53:37 +0200) Patch queue for efi - 2018-06-14 A few minor fixes for the release: - Compile fixes - HI20 relocations for RISC-V - Fix bootefi without load path - Fix Runtime Services with certain compilers Alexander Graf (3): riscv: Add support for HI20 PE relocations efi_loader: Convert runtime reset from switch to if statements efi_loader: Allocate memory handle for mem dp Heinrich Schuchardt (2): efi_loader: avoid initializer element is not constant efi_loader: avoid make race condition Simon Glass (1): efi: Add a comment about duplicated ELF constants arch/arm/cpu/armv8/fwcall.c | 11 --- arch/arm/mach-bcm283x/reset.c | 11 --- cmd/bootefi.c | 9 + disk/part_efi.c | 9 +++-- include/efi.h | 3 +-- include/pe.h | 3 +++ lib/efi_loader/efi_image_loader.c | 14 ++ lib/efi_loader/efi_runtime.c | 4 scripts/Makefile.lib | 10 -- 9 files changed, 54 insertions(+), 20 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v7 09/10] efi: Create a function to set up for running EFI code
Add a new bootefi_run_prepare() function which holds common code used to
set up U-Boot to run EFI code. Make use of this from the existing
bootefi_test_prepare() function, as well as do_bootefi_exec().
Also shorten a few variable names.
Signed-off-by: Simon Glass
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
- Introduce load_options_path to specifyc U-Boot env var for load_options_path
Changes in v4:
- Rebase to master
Changes in v3:
- Add patch to create a function to set up for running EFI code
Changes in v2: None
cmd/bootefi.c | 79 ---
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ac80074bc4..b9eb04531b 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -253,6 +253,26 @@ static efi_status_t efi_install_fdt(void *fdt)
return ret;
}
+static efi_status_t bootefi_run_prepare(struct efi_loaded_image *image,
+ struct efi_object *obj,
+ const char *load_options_path,
+ struct efi_device_path *device_path,
+ struct efi_device_path *image_path)
+{
+ efi_setup_loaded_image(image, obj, device_path, image_path);
+
+ /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+ efi_save_gd();
+
+ /* Transfer environment variable as load options */
+ set_load_options(image, load_options_path);
+
+ return 0;
+}
+
/*
* Load an EFI payload into a newly allocated piece of memory, register all
* EFI objects it would want to access and jump to it.
@@ -261,8 +281,8 @@ static efi_status_t do_bootefi_exec(void *efi,
struct efi_device_path *device_path,
struct efi_device_path *image_path)
{
- struct efi_loaded_image loaded_image_info = {};
- struct efi_object loaded_image_info_obj = {};
+ struct efi_loaded_image image;
+ struct efi_object obj;
struct efi_device_path *memdp = NULL;
efi_status_t ret;
@@ -283,19 +303,13 @@ static efi_status_t do_bootefi_exec(void *efi,
assert(device_path && image_path);
}
- efi_setup_loaded_image(_image_info, _image_info_obj,
- device_path, image_path);
+ ret = bootefi_run_prepare(, , "bootargs", device_path,
+ image_path);
+ if (ret)
+ return ret;
- /*
-* gd lives in a fixed register which may get clobbered while we execute
-* the payload. So save it here and restore it on every callback entry
-*/
- efi_save_gd();
-
- /* Transfer environment variable bootargs as load options */
- set_load_options(_image_info, "bootargs");
/* Load the EFI payload */
- entry = efi_load_pe(efi, _image_info);
+ entry = efi_load_pe(efi, );
if (!entry) {
ret = EFI_LOAD_ERROR;
goto exit;
@@ -303,10 +317,10 @@ static efi_status_t do_bootefi_exec(void *efi,
if (memdp) {
struct efi_device_path_memory *mdp = (void *)memdp;
- mdp->memory_type = loaded_image_info.image_code_type;
- mdp->start_address = (uintptr_t)loaded_image_info.image_base;
+ mdp->memory_type = image.image_code_type;
+ mdp->start_address = (uintptr_t)image.image_base;
mdp->end_address = mdp->start_address +
- loaded_image_info.image_size;
+ image.image_size;
}
/* we don't support much: */
@@ -316,8 +330,8 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
- if (setjmp(_image_info.exit_jmp)) {
- ret = loaded_image_info.exit_status;
+ if (setjmp(_jmp)) {
+ ret = image.exit_status;
goto exit;
}
@@ -329,7 +343,7 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Move into EL2 and keep running there */
armv8_switch_to_el2((ulong)entry,
- (ulong)_image_info_obj.handle,
+ (ulong),
(ulong), 0, (ulong)efi_run_in_el2,
ES_TO_AARCH64);
@@ -338,11 +352,11 @@ static efi_status_t do_bootefi_exec(void *efi,
}
#endif
- ret = efi_do_enter(loaded_image_info_obj.handle, , entry);
+ ret = efi_do_enter(obj.handle, , entry);
exit:
/* image has returned, loaded-image obj goes *poof*: */
Re: [U-Boot] [PATCH v6 03/13] efi: sandbox: Adjust memory usage for sandbox
Hi Alex,
On 14 June 2018 at 10:42, Alexander Graf wrote:
> On 06/14/2018 06:33 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 June 2018 at 10:26, Alexander Graf wrote:
>>>
>>> On 06/14/2018 06:13 PM, Simon Glass wrote:
Hi Alex,
On 14 June 2018 at 10:07, Alexander Graf wrote:
>
> On 06/14/2018 05:53 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 14 June 2018 at 09:47, Alexander Graf wrote:
>>>
>>>
Am 14.06.2018 um 17:43 schrieb Simon Glass :
Hi Alex,
> On 14 June 2018 at 08:22, Alexander Graf wrote:
>
>
>
>> Am 14.06.2018 um 16:12 schrieb Simon Glass :
>>
>> Hi Alex,
>>
On 14 June 2018 at 07:41, Alexander Graf wrote:
On 06/14/2018 02:58 PM, Simon Glass wrote:
Hi Alex,
>> On 14 June 2018 at 04:12, Alexander Graf
>> wrote:
>>
>> On 06/13/2018 04:37 AM, Simon Glass wrote:
>>
>> With sandbox the U-Boot code is not mapped into the sandbox
>> memory
>> range
>> so does not need to be excluded when allocating EFI memory.
>> Update
>> the
>> EFI
>> memory init code to take account of that.
>>
>> Also use mapmem instead of a cast to convert a memory address
>> to
>> a
>> pointer.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v6: None
>> Changes in v5: None
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2:
>> - Update to use mapmem instead of a cast
>>
>> lib/efi_loader/efi_memory.c | 31
>> ++-
>> 1 file changed, 18 insertions(+), 13 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_memory.c
>> b/lib/efi_loader/efi_memory.c
>> index ec66af98ea..210e49ee8b 100644
>> --- a/lib/efi_loader/efi_memory.c
>> +++ b/lib/efi_loader/efi_memory.c
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> @@ -393,7 +394,7 @@ efi_status_t efi_allocate_pool(int
>> pool_type,
>> efi_uintn_t size, void **buffer)
>> );
>> if (r == EFI_SUCCESS) {
>> - struct efi_pool_allocation *alloc = (void
>> *)(uintptr_t)t;
>> + struct efi_pool_allocation *alloc =
>> map_sysmem(t,
>> size);
>
>
> This is still the wrong spot. We don't want the conversion to
> happen when
> going from an EFI internal address to an allocation, but when
> determining
> which addresses are usable in the first place.
There seem to be two ways to do this:
1. Record addresses (ulong) in the EFI tables and use
map_sysmem()
before returning an address in the allocator
2. Store pointers in the EFI tables using map_sysmem(), then do
no
mapping in the allocator
I've gone with option 1 since:
- the EFI addresses are not pointers
- it makes sandbox consistent with other architectures which use
an
address rather than a pointer in EFI tables
- we don't normally do pointer arithmetic on the results of
map_sysmem()
- we normally map the memory when it is used rather than when it
is
set up
I think you are asking for option 2. I think that would get very
confusing. The addresses where things actually end up in sandbox
are
best kept to sandbox.
Overall I feel that you are either missing the point of sandbox
addressing, or don't agree with how it is done. But it does work
pretty well and we don't get a lot of confusion with sandbox
pointers
since we typically use the address until the last moment.
>>>
>>>
>>> I've assembled a quick tree for version 2. With that I'm able to
>>> run
>>> a
>>> simple hello world efi application. Grub refuses to start because
>>> it
>>> wants
>>> memory in the low 32bit and also emits random PIO accessing
>>> functions,
Re: [U-Boot] [PATCH v2 3/3] ax25: Switch to CONFIG_BOOTP_PREFER_SERVERIP
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? > > /* > * Miscellaneous configurable options > -- > 2.12.3 > > ___ > 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 10/11] efi_loader: Pass virtual address to fs_read()
Hi Alex, On 14 June 2018 at 10:33, Alexander Graf wrote: > The fs_read() function wants to get a virtual (u-boot address space > in sandbox) address rather than a physical (host address space in > sandbox) one. > The terminology is wrong here. It is not about virtual and physical addresses - that's an MMU concept. It's about sandbox using a special memory buffer to emulate U-Boot memory access. The code is correct but the comment and commit message will cause great confusion, so please fix. It is document in a few READMEs, but perhaps I should add some comments to mapmem.h ? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v7 07/10] efi: Split out test init/uninit into functions
We plan to run more than one EFI test. In order to avoid duplicating code,
create functions which handle preparing for running the test and cleaning
up afterwards.
Also shorten the awfully long variable names here.
Signed-off-by: Simon Glass
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
Changes in v4: None
Changes in v3:
- Add new patch to split out test init/uninit into functions
Changes in v2: None
cmd/bootefi.c | 87 +--
1 file changed, 63 insertions(+), 24 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 707d159bac..a9ebde0c75 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -347,6 +347,60 @@ exit:
return ret;
}
+#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
+/**
+ * bootefi_test_prepare() - prepare to run an EFI test
+ *
+ * This sets things up so we can call EFI functions. This involves preparing
+ * the 'gd' pointer and setting up the load ed image data structures.
+ *
+ * @image: Pointer to a struct which will hold the loaded image info
+ * @obj: Pointer to a struct which will hold the loaded image object
+ * @path: File path to the test being run (often just the test name with a
+ *backslash before it
+ * @test_func: Address of the test function that is being run
+ * @return 0 if OK, -ve on error
+ */
+static efi_status_t bootefi_test_prepare(struct efi_loaded_image *image,
+struct efi_object *obj,
+const char *path, ulong test_func)
+{
+ memset(image, '\0', sizeof(*image));
+ memset(obj, '\0', sizeof(*obj));
+ /* Construct a dummy device path */
+ bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
+ (uintptr_t)test_func,
+ (uintptr_t)test_func);
+ bootefi_image_path = efi_dp_from_file(NULL, 0, path);
+ efi_setup_loaded_image(image, obj, bootefi_device_path,
+ bootefi_image_path);
+ /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+ efi_save_gd();
+
+ /* Transfer environment variable efi_selftest as load options */
+ set_load_options(image, "efi_selftest");
+
+ return 0;
+}
+
+/**
+ * bootefi_test_finish() - finish up after running an EFI test
+ *
+ * @image: Pointer to a struct which holds the loaded image info
+ * @obj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_test_finish(struct efi_loaded_image *image,
+ struct efi_object *obj)
+{
+ efi_restore_gd();
+ free(image->load_options);
+ list_del(>link);
+}
+#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
+
static int do_bootefi_bootmgr_exec(void)
{
struct efi_device_path *device_path, *file_path;
@@ -425,31 +479,16 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
#endif
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
- struct efi_loaded_image loaded_image_info = {};
- struct efi_object loaded_image_info_obj = {};
-
- /* Construct a dummy device path. */
- bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
- (uintptr_t)_selftest,
- (uintptr_t)_selftest);
- bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
-
- efi_setup_loaded_image(_image_info,
- _image_info_obj,
- bootefi_device_path, bootefi_image_path);
- /*
-* gd lives in a fixed register which may get clobbered while we
-* execute the payload. So save it here and restore it on every
-* callback entry
-*/
- efi_save_gd();
- /* Transfer environment variable efi_selftest as load options */
- set_load_options(_image_info, "efi_selftest");
+ struct efi_loaded_image image;
+ struct efi_object obj;
+
+ if (bootefi_test_prepare(, , "\\selftest",
+(uintptr_t)_selftest))
+ return CMD_RET_FAILURE;
+
/* Execute the test */
- r = efi_selftest(loaded_image_info_obj.handle, );
- efi_restore_gd();
- free(loaded_image_info.load_options);
- list_del(_image_info_obj.link);
+ r = efi_selftest(obj.handle, );
+ bootefi_test_finish(, );
return r != EFI_SUCCESS;
} else
#endif
--
[U-Boot] [PATCH v7 08/10] efi: sandbox: Add a simple 'bootefi test' command
This jumps to test code which can call directly into the EFI support. It
does not need a separate image so it is easy to write tests with it.
This test can be executed without causing problems to the run-time
environemnt (e.g. U-Boot does not need to reboot afterwards).
For now the test just outputs a message. To try it:
./sandbox/u-boot -c "bootefi test"
U-Boot 2017.09-00204-g696c9855fe (Sep 17 2017 - 16:43:53 -0600)
DRAM: 128 MiB
MMC:
Using default environment
In:serial
Out: serial
Err: serial
SCSI: Net: No ethernet found.
IDE: Bus 0: not available
Found 0 disks
WARNING: booting without device tree
Hello, world!
Test passed
Signed-off-by: Simon Glass
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Rebase to master
- Update SPDX tags
Changes in v3:
- Rebase to master
Changes in v2:
- Rebase to master
cmd/bootefi.c | 26 --
include/efi_loader.h | 3 +++
lib/efi_loader/Kconfig| 10 ++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_test.c | 16
5 files changed, 50 insertions(+), 6 deletions(-)
create mode 100644 lib/efi_loader/efi_test.c
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index a9ebde0c75..ac80074bc4 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -347,7 +347,6 @@ exit:
return ret;
}
-#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
/**
* bootefi_test_prepare() - prepare to run an EFI test
*
@@ -399,7 +398,6 @@ static void bootefi_test_finish(struct efi_loaded_image
*image,
free(image->load_options);
list_del(>link);
}
-#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
static int do_bootefi_bootmgr_exec(void)
{
@@ -431,8 +429,10 @@ static int do_bootefi_bootmgr_exec(void)
/* Interpreter command to boot an arbitrary EFI image from memory */
static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
- unsigned long addr;
+ struct efi_loaded_image image;
+ struct efi_object obj;
char *saddr;
+ unsigned long addr;
efi_status_t r;
void *fdt_addr;
@@ -477,11 +477,25 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
memcpy((char *)addr, __efi_helloworld_begin, size);
} else
#endif
+ if (IS_ENABLED(CONFIG_BOOTEFI_TEST) && !strcmp(argv[1], "test")) {
+ int ret;
+
+ if (bootefi_test_prepare(, , "\\test",
+(ulong)_test))
+ return CMD_RET_FAILURE;
+
+ ret = efi_test(, );
+ bootefi_test_finish(, );
+ if (ret) {
+ printf("Test failed: err=%d\n", ret);
+ return CMD_RET_FAILURE;
+ }
+ printf("Test passed\n");
+
+ return 0;
+ }
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
- struct efi_loaded_image image;
- struct efi_object obj;
-
if (bootefi_test_prepare(, , "\\selftest",
(uintptr_t)_selftest))
return CMD_RET_FAILURE;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c66252a7dd..0615cfac85 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -442,6 +442,9 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
efi_guid_t *vendor,
void *efi_bootmgr_load(struct efi_device_path **device_path,
struct efi_device_path **file_path);
+/* Perform EFI tests */
+int efi_test(efi_handle_t image_handle, struct efi_system_table *systab);
+
#else /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index d471e6f4a4..110dcb23c9 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -25,3 +25,13 @@ config EFI_LOADER_BOUNCE_BUFFER
Some hardware does not support DMA to full 64bit addresses. For this
hardware we can create a bounce buffer so that payloads don't have to
worry about platform details.
+
+config BOOTEFI_TEST
+ bool "Provide a test for the EFI loader"
+ depends on EFI_LOADER && SANDBOX
+ default y
+ help
+ Provides a test of the EFI loader functionality accessed via the
+ command line ('bootefi test'). This runs within U-Boot so does not
+ need a separate EFI application to work. It aims to include coverage
+ of all EFI code which can be accessed within sandbox.
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c6046e36d2..2da28f9c90 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_DM_VIDEO) += efi_gop.o
obj-$(CONFIG_PARTITIONS) += efi_disk.o
obj-$(CONFIG_NET) += efi_net.o
