[U-Boot] [PATCH] ARM: DTS: Resync am3517-evm.dts with Linux 4.19
Some minor changes have been made to the AM3517-evm and the underlying
am3517.dtsi files. This patch re-sync's the DTS and DTSI files with
Linux.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
index 98aadb0f81..1d158cfda1 100644
--- a/arch/arm/dts/am3517-evm.dts
+++ b/arch/arm/dts/am3517-evm.dts
@@ -127,6 +127,7 @@
status = "okay";
pinctrl-names = "default";
enable-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;/* gpio176, lcd
INI */
+ vcc-supply = <&vdd_io_reg>;
port {
lcd_in: endpoint {
@@ -154,6 +155,7 @@
bl: backlight {
compatible = "pwm-backlight";
pinctrl-names = "default";
+ power-supply = <&vdd_io_reg>;
pinctrl-0 = <&backlight_pins>;
pwms = <&pwm11 0 500 0>;
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
@@ -168,6 +170,13 @@
ti,timers = <&timer11>;
#pwm-cells = <3>;
};
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ reset-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; /* gpio_57 */
+ #phy-cells = <0>;
+ };
};
&davinci_emac {
@@ -203,6 +212,7 @@
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
+ vcc-supply = <&vdd_io_reg>;
};
};
@@ -220,15 +230,21 @@
cd-gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>; /* gpio_127 */
};
-&mmc2 {
+&mmc3 {
status = "disabled";
};
-&mmc3 {
- status = "disabled";
+&usbhshost {
+ port1-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <&hsusb1_phy>;
};
&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsusb1_rst_pins>;
leds_pins: pinmux_leds_pins {
pinctrl-single,pins = <
@@ -287,4 +303,32 @@
OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)
/* dss_data15.dss_data15 */
>;
};
+
+ hsusb1_rst_pins: pinmux_hsusb1_rst_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20ba, PIN_OUTPUT | MUX_MODE4)
/* gpmc_ncs6.gpio_57 */
+ >;
+ };
+};
+
+&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsusb1_pins>;
+
+ hsusb1_pins: pinmux_hsusb1_pins {
+ pinctrl-single,pins = <
+ OMAP3430_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE3)
/* etk_clk.hsusb1_stp */
+ OMAP3430_CORE2_IOPAD(0x25da, PIN_OUTPUT | MUX_MODE3)
/* etk_ctl.hsusb1_clk */
+ OMAP3430_CORE2_IOPAD(0x25ec, PIN_INPUT | MUX_MODE3)
/* etk_d8.hsusb1_dir */
+ OMAP3430_CORE2_IOPAD(0x25ee, PIN_INPUT | MUX_MODE3)
/* etk_d9.hsusb1_nxt */
+ OMAP3430_CORE2_IOPAD(0x25dc, PIN_INPUT | MUX_MODE3)
/* etk_d0.hsusb1_data0 */
+ OMAP3430_CORE2_IOPAD(0x25de, PIN_INPUT | MUX_MODE3)
/* etk_d1.hsusb1_data1 */
+ OMAP3430_CORE2_IOPAD(0x25e0, PIN_INPUT | MUX_MODE3)
/* etk_d2.hsusb1_data2 */
+ OMAP3430_CORE2_IOPAD(0x25ea, PIN_INPUT | MUX_MODE3)
/* etk_d7.hsusb1_data3 */
+ OMAP3430_CORE2_IOPAD(0x25e4, PIN_INPUT | MUX_MODE3)
/* etk_d4.hsusb1_data4 */
+ OMAP3430_CORE2_IOPAD(0x25e6, PIN_INPUT | MUX_MODE3)
/* etk_d5.hsusb1_data5 */
+ OMAP3430_CORE2_IOPAD(0x25e8, PIN_INPUT | MUX_MODE3)
/* etk_d6.hsusb1_data6 */
+ OMAP3430_CORE2_IOPAD(0x25e2, PIN_INPUT | MUX_MODE3)
/* etk_d3.hsusb1_data7 */
+ >;
+ };
};
diff --git a/arch/arm/dts/am3517-som.dtsi b/arch/arm/dts/am3517-som.dtsi
index a6d5ff73c1..dae6e458e5 100644
--- a/arch/arm/dts/am3517-som.dtsi
+++ b/arch/arm/dts/am3517-som.dtsi
@@ -14,6 +14,32 @@
cpu0-supply = <&vdd_core_reg>;
};
};
+
+ wl12xx_buffer: wl12xx_buf {
+ compatible = "regulator-fixed";
+ regulator-name = "wl1271_buf";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wl12xx_buffer_pins>;
+ gpio = <&gpio5 1 GPIO_ACTIVE_LOW>; /* gpio 129 */
+ regulator-always-on;
+ vin-supply = <&vdd_1v8_reg>;
+ };
+
+ wl12xx_vmmc2: wl12xx_vmmc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vwl1271";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wl12xx_wkup_pins>;
+ gpio
[U-Boot] [PATCH] configs: am3517_evm: Use default OMAP3 memory settings
The AM3517 is mostly am omap3, so this partch removes the custom memory configurations and just uses the default common entries for omap3 and armv7. Signed-off-by: Adam Ford diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 0463e42048..4e7e5209d4 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -12,16 +12,6 @@ #ifndef __CONFIG_H #define __CONFIG_H -/* - * 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM - * 64 bytes before this address should be set aside for u-boot.img's - * header. That is 0x800FFFC0--0x8010 should not be used for any - * other needs. - */ - -#define CONFIG_SYS_SPL_MALLOC_START0x80208000 -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10 - #include #undef CONFIG_DM_I2C_COMPAT @@ -176,8 +166,6 @@ /* Physical Memory Map */ #define CONFIG_SYS_CS0_SIZE(256 * 1024 * 1024) -#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 -#define CONFIG_SYS_INIT_RAM_SIZE 0x800 /* FLASH and environment organization */ @@ -203,10 +191,6 @@ #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x4020 -#undef CONFIG_SPL_BSS_START_ADDR -#define CONFIG_SPL_BSS_START_ADDR 0x8000 -#define CONFIG_SPL_BSS_MAX_SIZE0x8 /* 512 KB */ - #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: am3517_evm: Build for Thumb
In an effort to free up more resources in SPL and U-Boot, building for Thumb shrinks the code side. Before: text data bss dec hex filename 685588 25808 275724 987120 f0ff0 u-boot text data bss dec hex filename 55324 417 67460 123201 1e141 spl/u-boot-spl After: textdata bss dec hex filename 515502 25808 275708 817018 c777a u-boot textdata bss dec hex filename 42910 417 67460 110787 1b0c3 spl/u-boot-spl Signed-off-by: Adam Ford diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig index e334030e51..8e522f95da 100644 --- a/configs/am3517_evm_defconfig +++ b/configs/am3517_evm_defconfig @@ -1,5 +1,4 @@ CONFIG_ARM=y -# CONFIG_SYS_THUMB_BUILD is not set CONFIG_ARCH_OMAP2PLUS=y CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: omap3_logic: Make CONFIG_SYS_TEXT_BASE match README.omap3
README.omap3 has two options. For option 1, CONFIG_SYS_TEXT_BASE is set to 0x8010. Option 2 lists 0x80008000. The existing value is neither of these, so this patch makes it equivalent to Option 1. Signed-off-by: Adam Ford diff --git a/configs/omap35_logic_defconfig b/configs/omap35_logic_defconfig index 54c40d8c42..fa7bde4e32 100644 --- a/configs/omap35_logic_defconfig +++ b/configs/omap35_logic_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y +CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y # CONFIG_SPL_GPIO_SUPPORT is not set CONFIG_SYS_MALLOC_F_LEN=0x2000 diff --git a/configs/omap35_logic_somlv_defconfig b/configs/omap35_logic_somlv_defconfig index 4521aedb2a..33c2716639 100644 --- a/configs/omap35_logic_somlv_defconfig +++ b/configs/omap35_logic_somlv_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y +CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y # CONFIG_SPL_GPIO_SUPPORT is not set CONFIG_SYS_MALLOC_F_LEN=0x2000 diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig index 9b50a300a0..490d4d186c 100644 --- a/configs/omap3_logic_defconfig +++ b/configs/omap3_logic_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y +CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y # CONFIG_SPL_GPIO_SUPPORT is not set CONFIG_SYS_MALLOC_F_LEN=0x2000 diff --git a/configs/omap3_logic_somlv_defconfig b/configs/omap3_logic_somlv_defconfig index d29621d8ce..ad3d913b3e 100644 --- a/configs/omap3_logic_somlv_defconfig +++ b/configs/omap3_logic_somlv_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y +CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y # CONFIG_SPL_GPIO_SUPPORT is not set CONFIG_SYS_MALLOC_F_LEN=0x2000 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC PATCH 0/3] sunxi: extend SPL header to propagate DRAM size
在 2018-05-17四的 09:16 +0100，Andre Przywara写道： > This series tries to solve three issues we currently have on > Allwinner boards: > - The DRAM sizing routine can only cope with power-of-two sized DRAM. > - The DRAM sizing routine steps through all DRAM, possibly hitting > secure > memory. > - The SPL header versioning is quite strict and tends to break every > time > we need to update it. > > So I thought about introducing something along the lines of semantic > versioning[1], where we can add backwards-compatible changes to the > SPL > header without breaking every tool. This is introduced in the first > patch. > The second patch does some refactoring, so that the third patch can > use > the newly gained freedom to store the DRAM size. The SPL knows the > DRAM > size very well, so we store this in the SPL header, so that U-Boot > proper > can pick it up from there. This saves the call to get_ram_size() with > its deficiencies. > More information in the respective commit messages. > > I understand that this versioning solution is not fully future-proof, > but > we have only one byte for the version, and I just wanted to start > discussion on this. > There is a corresponding patch for sunxi-tools as well I am posting > shortly. > > [1] https://semver.org Could I do some small reworks on this patchset and resend it? We're now facing 3GiB Pine H64 releasing very soon. > > Cheers, > Andre. > > Andre Przywara (3): > sunxi: Extend SPL header versioning > sunxi: board.c: refactor SPL header checks > sunxi: store DRAM size in SPL header > > arch/arm/include/asm/arch-sunxi/spl.h | 22 > board/sunxi/board.c | 66 > --- > 2 files changed, 70 insertions(+), 18 deletions(-) > > -- > 2.14.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/4] pci: Update documentation to make 'compatible' string optional
On Wed, Oct 10, 2018 at 09:27:07PM +0200, Marek Vasut wrote: > Reword the documentation to make it clear the compatible string is now > optional, yet still matching on it takes precedence over PCI IDs and > PCI classes. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/4] pci: Support parsing PCI controller DT subnodes
On Wed, Oct 10, 2018 at 09:27:06PM +0200, Marek Vasut wrote: > The PCI controller can have DT subnodes describing extra properties > of particular PCI devices, ie. a PHY attached to an EHCI controller > on a PCI bus. This patch parses those DT subnodes and assigns a node > to the PCI device instance, so that the driver can extract details > from that node and ie. configure the PHY using the PHY subsystem. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/4] test: Add test for PCI device without compat string and with DT node
On Wed, Oct 10, 2018 at 09:27:09PM +0200, Marek Vasut wrote: > Add test which checks if a PCI device described in DT with an > entry and reg = <...> property, but without compatible string > results in a valid U-Boot PCI udevice with the udevice.node > populated with reference to this DT node. Also check if the > other PCI device without a DT node does not contain any bogus > udevice.node. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/4] test: Add PCI device entry without compat string and with DT node
On Wed, Oct 10, 2018 at 09:27:08PM +0200, Marek Vasut wrote: > Add PCI entry without compatible string and with a DT node only with > reg = <...> property into the DT. This is needed for the tests to > verify whether such a setup creates an U-Boot PCI device with the > DT node associated with it in udevice.node. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: [PATCH 18/30] riscv: invalidate the instruction cache before jumping to Linux
> From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> Sent: Saturday, October 20, 2018 6:08 AM
> To: u-boot@lists.denx.de
> Cc: Bin Meng; Lukas Auer; Greentime Hu; Alexander Graf; Rick Jian-Zhi
> Chen(陳建志)
> Subject: [PATCH 18/30] riscv: invalidate the instruction cache before jumping
> to Linux
>
> Signed-off-by: Lukas Auer
> ---
>
> arch/riscv/lib/bootm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c index
> a7a9fb921b..bc1d4b2864 100644
> --- a/arch/riscv/lib/bootm.c
> +++ b/arch/riscv/lib/bootm.c
> @@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char *argv[],
> bootm_headers_t *images)
> return 1;
>
> kernel = (void (*)(ulong, void *))images->ep;
> + invalidate_icache_all();
Hi Likas
I wull use cleanup_before_linux() which is in cpu.c as below
int cleanup_before_linux(void)
{
disable_interrupts();
/* turn off I/D-cache */
cache_flush();
icache_disable();
dcache_disable();
return 0;
}
and cache_flush() in cache.c as below
void cache_flush(void)
{
invalidate_icache_all();
flush_dcache_all();
}
Rick
>
> bootstage_mark(BOOTSTAGE_ID_RUN_OS);
>
> --
> 2.17.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc: t1040: Correct RCW MAC2_GMII_SEL value
On Mon, Oct 15, 2018 at 1:21 PM Bin Meng wrote: > > On Mon, Oct 8, 2018 at 11:07 PM York Sun wrote: > > > > On 10/08/2018 06:51 AM, Bin Meng wrote: > > > Per T1040RM (Rev. 1, 08/2015), the value of > > > FSL_CORENET_RCWSR13_MAC2_GMII_SEL_ENET_PORT is wrong > > > and should be 0x0080 (bit 440 in the RCW). > > > > > > Signed-off-by: Bin Meng > > > --- > > > > > > Poonam, > > > > Please review and confirm on T1040. Thanks. > > > > Ping ? Ping ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] scsi: ceva: add ls1088a soc support
Add ahci compatible support for ls1088a soc.
Signed-off-by: Peng Ma
---
depend on:
- https://patchwork.ozlabs.org/patch/982386/
drivers/ata/sata_ceva.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_ceva.c b/drivers/ata/sata_ceva.c
index a2d21d9..fa86797 100644
--- a/drivers/ata/sata_ceva.c
+++ b/drivers/ata/sata_ceva.c
@@ -82,15 +82,19 @@
#define CEVA_AXICC_CFG 0x3fff
/* for ls1021a */
-#define LS1021_AHCI_VEND_AXICC 0xC0
+#define LS1021_AHCI_VEND_AXICC 0xC0
#define LS1021_CEVA_PHY2_CFG 0x28183414
#define LS1021_CEVA_PHY3_CFG 0x0e080e06
#define LS1021_CEVA_PHY4_CFG 0x064a080b
#define LS1021_CEVA_PHY5_CFG 0x2aa86470
+/* for ls1088a */
+#define LS1088_ECC_DIS_ADDR_CH20x100520
+#define LS1088_ECC_DIS_VAL_CH2 0x4000
+
/* ecc addr-val pair */
-#define ECC_DIS_ADDR_CH2 0x8000
-#define ECC_DIS_VAL_CH20x20140520
+#define ECC_DIS_ADDR_CH2 0x20140520
+#define ECC_DIS_VAL_CH20x8000
#define SATA_ECC_REG_ADDR 0x20220520
#define SATA_ECC_DISABLE 0x0002
@@ -100,6 +104,7 @@ enum ceva_soc {
CEVA_LS1021A,
CEVA_LS1043A,
CEVA_LS1046A,
+ CEVA_LS1088A,
};
struct ceva_sata_priv {
@@ -140,7 +145,15 @@ static int ceva_init_sata(struct ceva_sata_priv *priv)
case CEVA_LS1012A:
case CEVA_LS1043A:
case CEVA_LS1046A:
- writel(ECC_DIS_ADDR_CH2, ECC_DIS_VAL_CH2);
+ writel(ECC_DIS_VAL_CH2, ECC_DIS_ADDR_CH2);
+ writel(CEVA_PHY1_CFG, base + AHCI_VEND_PPCFG);
+ writel(CEVA_TRANS_CFG, base + AHCI_VEND_PTC);
+ if (priv->flag & FLAG_COHERENT)
+ writel(CEVA_AXICC_CFG, base + AHCI_VEND_AXICC);
+ break;
+
+ case CEVA_LS1088A:
+ writel(LS1088_ECC_DIS_VAL_CH2, LS1088_ECC_DIS_ADDR_CH2);
writel(CEVA_PHY1_CFG, base + AHCI_VEND_PPCFG);
writel(CEVA_TRANS_CFG, base + AHCI_VEND_PTC);
if (priv->flag & FLAG_COHERENT)
@@ -173,6 +186,7 @@ static const struct udevice_id sata_ceva_ids[] = {
{ .compatible = "fsl,ls1021a-ahci", .data = CEVA_LS1021A },
{ .compatible = "fsl,ls1043a-ahci", .data = CEVA_LS1043A },
{ .compatible = "fsl,ls1046a-ahci", .data = CEVA_LS1046A },
+ { .compatible = "fsl,ls1088a-ahci", .data = CEVA_LS1088A },
{ }
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] armv8: dts: fsl-ls1088a: add sata node support
One ls1088a, there is one SATA 3.0 advanced host controller interface
which is a high-performance SATA solution that delivers comprehensive
and fully-compliant generation 3 (1.5 Gb/s - 6.0 Gb/s) serial ATA
capabilities, in accordance with the serial ATA revision 3.0 of Serial
ATA International Organization.
Add sata node to support this feature.
Signed-off-by: Peng Ma
---
arch/arm/dts/fsl-ls1088a-qds.dts |4
arch/arm/dts/fsl-ls1088a-rdb.dts |4
arch/arm/dts/fsl-ls1088a.dtsi|8
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1088a-qds.dts b/arch/arm/dts/fsl-ls1088a-qds.dts
index 36116f7..4ea451c 100644
--- a/arch/arm/dts/fsl-ls1088a-qds.dts
+++ b/arch/arm/dts/fsl-ls1088a-qds.dts
@@ -104,3 +104,7 @@
reg = <1>;
};
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1088a-rdb.dts b/arch/arm/dts/fsl-ls1088a-rdb.dts
index 0be3f8d..f30bbb7 100644
--- a/arch/arm/dts/fsl-ls1088a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1088a-rdb.dts
@@ -37,3 +37,7 @@
reg = <1>;
};
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 72d755a..9455e03 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -150,4 +150,12 @@
ranges = <0x8100 0x0 0x 0x30 0x0002 0x0
0x0001 /* downstream I/O */
0x8200 0x0 0x4000 0x30 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
+
+ sata: sata@320 {
+ compatible = "fsl,ls1088a-ahci";
+ reg = <0x0 0x320 0x0 0x1>;
+ interrupts = <0 133 4>;
+ status = "disabled";
+ };
+
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm64: ls1088a: enable DM support for sata
Enable related configs to support sata DM feature. Signed-off-by: Peng Ma --- configs/ls1088aqds_defconfig |5 + configs/ls1088ardb_qspi_defconfig |5 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/configs/ls1088aqds_defconfig b/configs/ls1088aqds_defconfig index 64677f0..3010f24 100644 --- a/configs/ls1088aqds_defconfig +++ b/configs/ls1088aqds_defconfig @@ -49,3 +49,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_BLK=y CONFIG_DM_MMC=y +CONFIG_DM_SCSI=y +CONFIG_SATA_CEVA=y +CONFIG_SCSI_AHCI=y +CONFIG_SCSI=y +CONFIG_AHCI=y diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index 1feaded..9959703 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -55,3 +55,8 @@ CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_BLK=y CONFIG_DM_MMC=y +CONFIG_DM_SCSI=y +CONFIG_SATA_CEVA=y +CONFIG_SCSI_AHCI=y +CONFIG_SCSI=y +CONFIG_AHCI=y -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] scsi: ceva: add ls2080a soc support
Add ahci compatible support for ls2080a soc.
Signed-off-by: Peng Ma
---
depend on:
- https://patchwork.ozlabs.org/patch/987497/
drivers/ata/sata_ceva.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/sata_ceva.c b/drivers/ata/sata_ceva.c
index fa86797..7d4c3ce 100644
--- a/drivers/ata/sata_ceva.c
+++ b/drivers/ata/sata_ceva.c
@@ -105,6 +105,7 @@ enum ceva_soc {
CEVA_LS1043A,
CEVA_LS1046A,
CEVA_LS1088A,
+ CEVA_LS2080A,
};
struct ceva_sata_priv {
@@ -146,6 +147,7 @@ static int ceva_init_sata(struct ceva_sata_priv *priv)
case CEVA_LS1043A:
case CEVA_LS1046A:
writel(ECC_DIS_VAL_CH2, ECC_DIS_ADDR_CH2);
+ case CEVA_LS2080A:
writel(CEVA_PHY1_CFG, base + AHCI_VEND_PPCFG);
writel(CEVA_TRANS_CFG, base + AHCI_VEND_PTC);
if (priv->flag & FLAG_COHERENT)
@@ -187,6 +189,7 @@ static const struct udevice_id sata_ceva_ids[] = {
{ .compatible = "fsl,ls1043a-ahci", .data = CEVA_LS1043A },
{ .compatible = "fsl,ls1046a-ahci", .data = CEVA_LS1046A },
{ .compatible = "fsl,ls1088a-ahci", .data = CEVA_LS1088A },
+ { .compatible = "fsl,ls2080a-ahci", .data = CEVA_LS2080A },
{ }
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] armv8: dts: fsl-ls2080a: add sata node support
One ls2080a, there is one SATA 3.0 advanced host controller interface
which is a high-performance SATA solution that delivers comprehensive
and fully-compliant generation 3 (1.5 Gb/s - 6.0 Gb/s) serial ATA
capabilities, in accordance with the serial ATA revision 3.0 of Serial
ATA International Organization.
Add sata node to support this feature.
Signed-off-by: Peng Ma
---
arch/arm/dts/fsl-ls2080a-qds.dts |4
arch/arm/dts/fsl-ls2080a-rdb.dts |4
arch/arm/dts/fsl-ls2080a.dtsi|8
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/fsl-ls2080a-qds.dts b/arch/arm/dts/fsl-ls2080a-qds.dts
index fbd6c78..39fbc1b 100644
--- a/arch/arm/dts/fsl-ls2080a-qds.dts
+++ b/arch/arm/dts/fsl-ls2080a-qds.dts
@@ -64,3 +64,7 @@
reg = <0>;
};
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls2080a-rdb.dts b/arch/arm/dts/fsl-ls2080a-rdb.dts
index 541bcd3..e7567cf 100644
--- a/arch/arm/dts/fsl-ls2080a-rdb.dts
+++ b/arch/arm/dts/fsl-ls2080a-rdb.dts
@@ -32,3 +32,7 @@
reg = <0>;
};
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
index 2d537ae..5c0769b 100644
--- a/arch/arm/dts/fsl-ls2080a.dtsi
+++ b/arch/arm/dts/fsl-ls2080a.dtsi
@@ -156,4 +156,12 @@
ranges = <0x8100 0x0 0x 0x16 0x0002 0x0
0x0001 /* downstream I/O */
0x8200 0x0 0x4000 0x16 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
+
+ sata: sata@320 {
+ compatible = "fsl,ls2080a-ahci";
+ reg = <0x0 0x320 0x0 0x1>;
+ interrupts = <0 133 0x4>; /* Level high type */
+ status = "disabled";
+ };
+
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm64: ls2080a: enable DM support for sata
Enable related configs to support sata DM feature. Signed-off-by: Peng Ma --- configs/ls2080aqds_defconfig |5 + configs/ls2080ardb_defconfig |5 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig index 3026351..62d24da 100644 --- a/configs/ls2080aqds_defconfig +++ b/configs/ls2080aqds_defconfig @@ -55,3 +55,8 @@ CONFIG_USB_STORAGE=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_BLK=y CONFIG_DM_MMC=y +CONFIG_DM_SCSI=y +CONFIG_SATA_CEVA=y +CONFIG_SCSI_AHCI=y +CONFIG_SCSI=y +CONFIG_AHCI=y diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig index f3ff02c..bb185b1 100644 --- a/configs/ls2080ardb_defconfig +++ b/configs/ls2080ardb_defconfig @@ -56,3 +56,8 @@ CONFIG_USB_STORAGE=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_BLK=y CONFIG_DM_MMC=y +CONFIG_DM_SCSI=y +CONFIG_SATA_CEVA=y +CONFIG_SCSI_AHCI=y +CONFIG_SCSI=y +CONFIG_AHCI=y -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc: t1040: Correct RCW MAC2_GMII_SEL value
> -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Monday, October 22, 2018 7:41 AM > To: York Sun > Cc: Poonam Aggrwal ; U-Boot Mailing List b...@lists.denx.de> > Subject: Re: [PATCH 1/2] powerpc: t1040: Correct RCW MAC2_GMII_SEL value > > On Mon, Oct 15, 2018 at 1:21 PM Bin Meng wrote: > > > > On Mon, Oct 8, 2018 at 11:07 PM York Sun wrote: > > > > > > On 10/08/2018 06:51 AM, Bin Meng wrote: > > > > Per T1040RM (Rev. 1, 08/2015), the value of > > > > FSL_CORENET_RCWSR13_MAC2_GMII_SEL_ENET_PORT is wrong and > should be > > > > 0x0080 (bit 440 in the RCW). > > > > > > > > Signed-off-by: Bin Meng > > > > --- > > > > > > > > > Poonam, > > > > > > Please review and confirm on T1040. Thanks. > > > > > > > Ping ? > > Ping ? Apologies Bin, York for such late response The patch looks correct, the value of FSL_CORENET_RCWSR13_MAC2_GMII_SEL_ENET_PORT should be 0x80 indeed, I would suggest that I test it once that DTSEC2 RGMII works with this change, because I see more changes which could be required in drivers/fm/t1040.c...seems a goof up there as well. Kind Regards Poonam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc: t1040: Correct RCW MAC2_GMII_SEL value
Hi Poonam, On Mon, Oct 22, 2018 at 11:43 AM Poonam Aggrwal wrote: > > > > > -Original Message- > > From: Bin Meng [mailto:bmeng...@gmail.com] > > Sent: Monday, October 22, 2018 7:41 AM > > To: York Sun > > Cc: Poonam Aggrwal ; U-Boot Mailing List > b...@lists.denx.de> > > Subject: Re: [PATCH 1/2] powerpc: t1040: Correct RCW MAC2_GMII_SEL value > > > > On Mon, Oct 15, 2018 at 1:21 PM Bin Meng wrote: > > > > > > On Mon, Oct 8, 2018 at 11:07 PM York Sun wrote: > > > > > > > > On 10/08/2018 06:51 AM, Bin Meng wrote: > > > > > Per T1040RM (Rev. 1, 08/2015), the value of > > > > > FSL_CORENET_RCWSR13_MAC2_GMII_SEL_ENET_PORT is wrong and > > should be > > > > > 0x0080 (bit 440 in the RCW). > > > > > > > > > > Signed-off-by: Bin Meng > > > > > --- > > > > > > > > > > > > Poonam, > > > > > > > > Please review and confirm on T1040. Thanks. > > > > > > > > > > Ping ? > > > > Ping ? > Apologies Bin, York for such late response > The patch looks correct, the value of > FSL_CORENET_RCWSR13_MAC2_GMII_SEL_ENET_PORT should be 0x80 indeed, > I would suggest that I test it once that DTSEC2 RGMII works with this change, > because I see more changes which could be required in > drivers/fm/t1040.c...seems a goof up there as well. > t1040.c changes is patch [2/2], see https://lists.denx.de/pipermail/u-boot/2018-October/343499.html Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: qemu: rework Kconfig
On Fri, Oct 19, 2018 at 06:16:30PM +0800, Bin Meng wrote: > Hi, > > On Fri, Oct 19, 2018 at 4:55 PM AKASHI Takahiro > wrote: > > > > Define a missing CONFIG_SYS_SOC and move some CONFIG_SYS_* to a more > > canonical place (i.e. under board). > > > > Signed-off-by: AKASHI Takahiro > > --- > > arch/arm/Kconfig | 1 + > > arch/arm/mach-qemu/Kconfig | 18 ++ > > board/emulation/qemu-arm/Kconfig | 9 + > > 3 files changed, 20 insertions(+), 8 deletions(-) > > create mode 100644 board/emulation/qemu-arm/Kconfig > > > > Please rebase your changes on top of http://patchwork.ozlabs.org/patch/984021/ OK, but has this patch already acked? Anyway, I will include this patch in my patch set of "efi_loader: improve boot sequence in distro_bootcmd." Thanks, -Takahiro Akashi > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] efi_loader: improve boot sequence in distro_bootcmd
The current distro_bootcmd has several issues regarding efi boot. (See the patch#1 for details.) Patch#1: fix distro's issues and make its intent clear Patch#2,#3: address related issues on qemu-arm Please note that patch#2 is now rebased on Bin's patch[1]. [1] https://lists.denx.de/pipermail/u-boot/2018-October/344421.html Changes in v2 (Oct 22, 2018): * rewrite my previous changes after Alex's comments, including - boot bootmgr only once before searching for boot binary - dtb must be loaded from the same device with boot binary's * add patch#2 as part of this patch set, in particular adding CONFIG_SYS Thanks, -Takahio Akashi AKASHI Takahiro (3): efi_loader: rework fdt handling in distro boot script ARM: qemu-arm: rework Kconfig ARM: qemu-arm: define fdt_addr_r arch/arm/mach-qemu/Kconfig | 18 --- board/emulation/qemu-arm/Kconfig | 6 + include/config_distro_bootcmd.h | 38 +--- include/configs/qemu-arm.h | 1 + 4 files changed, 37 insertions(+), 26 deletions(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] efi_loader: rework fdt handling in distro boot script
The current scenario for default UEFI booting, scan_dev_for_efi, has
several issues:
* load dtb dynamically even if its loacation (device) is not the same
as BOOTEFI_NAME binary's, (reported by Alex)
* invoke 'bootmgr' only if BOOTEFI_NAME binary does exit even though
'bootmgr' can and should work independently whether or not the binary
exist,
* in addition, invoke 'bootmgr' with dynamically-loaded dtb.
This behavior is not expected. (reported by Alex)
* always assume that a 'fdtfile' variable is defined,
("test -e ${devtype} ${devnum}:${distro_bootpart} "${prefix}${efi_fdtfile}"
always returns true even if fdtfile is NULL with prefix=="/".)
* redundantly check for 'fdt_addr_r' in boot_efi_binary
In this patch, all the issues above are sorted out.
Please note that the default behavior can be customized with:
fdtfile: a dtb file name
efi_dtb_prefixes: a list of paths for searching for a dtb file
(this feature does work even without this patch.)
Signed-off-by: AKASHI Takahiro
---
include/config_distro_bootcmd.h | 38 +
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 373fee78a999..256698309eb9 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -115,7 +115,7 @@
*/
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK \
"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then " \
- "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; " \
+ "efi_fdtfile=${soc}-${board}${boardver}.dtb; " \
"fi; "
#else
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
@@ -124,26 +124,20 @@
#define BOOTENV_SHARED_EFI\
"boot_efi_binary="\
- "if fdt addr ${fdt_addr_r}; then "\
- "bootefi bootmgr ${fdt_addr_r};" \
- "else " \
- "bootefi bootmgr ${fdtcontroladdr};" \
- "fi;" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
- "if fdt addr ${fdt_addr_r}; then "\
- "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
- "else " \
- "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
- "fi\0"\
+ "bootefi ${kernel_addr_r} ${efi_fdt_addr};\0" \
\
"load_efi_dtb=" \
- "load ${devtype} ${devnum}:${distro_bootpart} " \
- "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
+ "load ${devtype} ${devnum}:${distro_bootpart} " \
+ "${fdt_addr_r} ${prefix}${efi_fdtfile}; " \
+ "if fdt addr ${fdt_addr_r}; then "\
+ "efi_fdt_addr=${fdt_addr_r}; "\
+ "fi;\0" \
\
"efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
- "scan_dev_for_efi=" \
- "setenv efi_fdtfile ${fdtfile}; " \
+ "set_efi_fdt_addr=" \
+ "efi_fdtfile=${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
"for prefix in ${efi_dtb_prefixes}; do " \
"if test -e ${devtype} " \
@@ -151,19 +145,26 @@
"${prefix}${efi_fdtfile}; then " \
"run load_efi_dtb; " \
"fi;" \
- "done;" \
+ "done;\0" \
+ \
+ "scan_dev_for_efi=" \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
"efi/boot/"BOOTEFI_NAME"; " \
+ "efi_fdt_addr=${fdtcontroladdr}; "\
+
[U-Boot] [PATCH v2 3/3] ARM: qemu-arm: define fdt_addr_r
This variable, fdt_addr_t, is missing in the current qemu-arm.h while it seems to be mandatory, at least, to run distro_bootcmd as expected. So just add its definition. A size of 1MB would be enough. Signed-off-by: AKASHI Takahiro --- include/configs/qemu-arm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index 91fb8d47edf8..0e66f946dde5 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -55,6 +55,7 @@ "fdt_high=0x\0" \ "initrd_high=0x\0" \ "fdt_addr=0x4000\0" \ + "fdt_addr_r=0x4010\0" \ "scriptaddr=0x4020\0" \ "pxefile_addr_r=0x4030\0" \ "kernel_addr_r=0x4040\0" \ -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] ARM: qemu-arm: rework Kconfig
Define a missing CONFIG_SYS_SOC and move some CONFIG_SYS_* to a more canonical place (i.e. under board). Signed-off-by: AKASHI Takahiro --- arch/arm/mach-qemu/Kconfig | 18 ++ board/emulation/qemu-arm/Kconfig | 6 ++ 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig index a2e4b98b8887..d75a95183a75 100644 --- a/arch/arm/mach-qemu/Kconfig +++ b/arch/arm/mach-qemu/Kconfig @@ -3,22 +3,24 @@ if ARCH_QEMU config SYS_VENDOR default "emulation" -config SYS_BOARD - default "qemu-arm" +config SYS_SOC + default "qemu" -config SYS_CONFIG_NAME - default "qemu-arm" - -endif +choice + prompt "QEMU cpu type" config TARGET_QEMU_ARM_32BIT - bool "Support qemu_arm" + bool "Arm" depends on ARCH_QEMU select ARCH_SUPPORT_PSCI select CPU_V7A select SYS_ARCH_TIMER config TARGET_QEMU_ARM_64BIT - bool "Support qemu_arm64" + bool "AArch64" depends on ARCH_QEMU select ARM64 + +endchoice + +endif diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig index d1c08c2f6a80..ef49e4e85f04 100644 --- a/board/emulation/qemu-arm/Kconfig +++ b/board/emulation/qemu-arm/Kconfig @@ -1,5 +1,11 @@ if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT +config SYS_BOARD + default "qemu-arm" + +config SYS_CONFIG_NAME + default "qemu-arm" + config SYS_TEXT_BASE default 0x -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: qemu: rework Kconfig
Hi Takahiro, On Mon, Oct 22, 2018 at 12:35 PM AKASHI Takahiro wrote: > > On Fri, Oct 19, 2018 at 06:16:30PM +0800, Bin Meng wrote: > > Hi, > > > > On Fri, Oct 19, 2018 at 4:55 PM AKASHI Takahiro > > wrote: > > > > > > Define a missing CONFIG_SYS_SOC and move some CONFIG_SYS_* to a more > > > canonical place (i.e. under board). > > > > > > Signed-off-by: AKASHI Takahiro > > > --- > > > arch/arm/Kconfig | 1 + > > > arch/arm/mach-qemu/Kconfig | 18 ++ > > > board/emulation/qemu-arm/Kconfig | 9 + > > > 3 files changed, 20 insertions(+), 8 deletions(-) > > > create mode 100644 board/emulation/qemu-arm/Kconfig > > > > > > > Please rebase your changes on top of > > http://patchwork.ozlabs.org/patch/984021/ > > OK, but has this patch already acked? Yes, it's in Simon's DM tree (guess it targets to next release) > Anyway, I will include this patch in my patch set of "efi_loader: improve > boot sequence in distro_bootcmd." > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] efi_loader: bootmgr: run an EFI application of a given load option
On Thu, Oct 18, 2018 at 10:46:36AM +0200, Alexander Graf wrote: > > > On 18.10.18 07:48, AKASHI Takahiro wrote: > > On Wed, Oct 17, 2018 at 10:43:22AM +0200, Alexander Graf wrote: > >> > >> > >> On 17.10.18 09:32, AKASHI Takahiro wrote: > >>> With this patch applied, we will be able to selectively execute > >>> an EFI application by specifying a load option, say "-1" for Boot0001, > >>> "-2" for Boot0002 and so on. > >>> > >>> => bootefi bootmgr -1 > >> > >> I don't think -1 is very good user experience :). How about > >> => bootefi bootmgr Boot0001 > > > > It looks like u-boot's run command with six more characters! > > How about this: > > > > => bootefi bootmgr #1 > > So what is the problem with making it Boot0001? That way at least the > variable name is consistent across the board ;). More typing! > > or allowing "-" as empty fdt, > > > > => bootefi bootmgr - 1 (Please notice that this is NOT "-1.") I also like this one as it maintains upward-compatibility: bootefi bootmgr [ []] > > Otherwise, a new sub command? > > > > => bootefi run 1, or > > => efi(shell) run 1 Well, if you stick to "setenv -e"-like syntax, how about => run -e Boot0001 Given that "run" takes an environment variable, this syntax is perfectly fit to U-boot, isn't it? > > # Discussing UI is a fun or mess. # I hope that this is not fruitless discussion. > Yeah :(. What we really need would be that "bootefi bootmgr" becomes > "efiboot". But that would be even more confusing ;). So I think that we should not add anything more to "bootefi bootmgr" to extend functionality. > So the whole rationale of why "bootefi" is the way it is today is that > it's trying to lean on the existing "bootm", "booti", "bootz" etc syntax > as much as it can. In other words, it's trying to fit into the U-Boot > ecosystem much rather than the existing edk2 one. IMO, "boot*" variants are already a mess. > I would like to keep following that path going forward. Whenever there > is an option between "U-Boot like" and "edk2 like" I would always opt > for the "U-Boot like" user experience, because if they want edk2 they > may as well use edk2 ;). Well, Boot is quite UEFI-specific and people who are not familiar with UEFI need to consult UEFI specification anyway and this means, to me, that UEFI shell's similarity would be favorable. (See "setvar" syntax, not mine but UEFI shell's, which can be quite different and complicated.) Does anybody else have any opinions? Thanks, -Takahiro Akashi > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: imx_lpi2c: fix typo and register base address format
Hello Anatolij, Am 18.10.2018 um 16:36 schrieb Anatolij Gustschin: Output the register base address in hex notation. Signed-off-by: Anatolij Gustschin --- drivers/i2c/imx_lpi2c.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) builds fine on travis: https://travis-ci.org/hsdenx/u-boot-i2c/builds/443610845 but I do not find this patch anymore on my Patchwork ToDo list ... Ah, assigned to Stefano ... Hmm.. why is this patch assigned to Stefano now? Acked-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] efi_loader: bootmgr: add load option helper functions
On Thu, Oct 18, 2018 at 10:39:30AM +0200, Alexander Graf wrote:
>
>
> On 18.10.18 09:57, AKASHI Takahiro wrote:
> > On Wed, Oct 17, 2018 at 10:40:26AM +0200, Alexander Graf wrote:
> >>
> >>
> >> On 17.10.18 09:32, AKASHI Takahiro wrote:
> >>> In this patch, helper functions for an load option variable (Boot)
> >>> are added:
> >>> * efi_parse_load_option(): parse a string into load_option data
> >>> (renamed from parse_load_option and exported)
> >>> * efi_marshel_load_option(): convert load_option data into a string
> >>>
> >>> Those functions will be used to implement efishell command.
> >>>
> >>> Signed-off-by: AKASHI Takahiro
> >>> ---
> >>> include/efi_loader.h | 25 +
> >>> lib/efi_loader/efi_bootmgr.c | 68
> >>> 2 files changed, 70 insertions(+), 23 deletions(-)
> >>>
> >>> diff --git a/include/efi_loader.h b/include/efi_loader.h
> >>> index b73fbb6de23f..1cabb1680d20 100644
> >>> --- a/include/efi_loader.h
> >>> +++ b/include/efi_loader.h
> >>> @@ -502,6 +502,31 @@ efi_status_t EFIAPI efi_set_variable(u16
> >>> *variable_name, efi_guid_t *vendor,
> >>>u32 attributes, efi_uintn_t data_size,
> >>>void *data);
> >>>
> >>> +/*
> >>> + * See section 3.1.3 in the v2.7 UEFI spec for more details on
> >>> + * the layout of EFI_LOAD_OPTION. In short it is:
> >>> + *
> >>> + *typedef struct _EFI_LOAD_OPTION {
> >>> + *UINT32 Attributes;
> >>> + *UINT16 FilePathListLength;
> >>> + *// CHAR16 Description[]; <-- variable length, NULL terminated
> >>> + *// EFI_DEVICE_PATH_PROTOCOL FilePathList[];
> >>> + *<-- FilePathListLength
> >>> bytes
> >>> + *// UINT8 OptionalData[];
> >>> + *} EFI_LOAD_OPTION;
> >>> + */
> >>> +struct load_option {
> >>> + u32 attributes;
> >>> + u16 file_path_length;
> >>> + u16 *label;
> >>> + struct efi_device_path *file_path;
> >>> + u8 *optional_data;
> >>> +};
> >>
> >> If this is part of the spec, shouldn't it rather be in efi_api.h?
> >
> > While uefi spec mentions this structure, I don't have good confidence
> > that I can say that it is part of spec or API because there is no interface
> > (or function) that handles this structure.
>
> Good point, it's internal only. Then efi_loader.h is probably a good fit.
OK.
> >
> >> It
> >> probably also wants an efi_ prefix then :).
> >
> > OK.
> >
> >>> +
> >>> +void efi_parse_load_option(struct load_option *lo, void *ptr);
> >>> +unsigned long efi_marshal_load_option(u32 attr, u16 *label,
> >>> + struct efi_device_path *file_path,
> >>> + char *option, void **data);
> >>> void *efi_bootmgr_load(struct efi_device_path **device_path,
> >>> struct efi_device_path **file_path);
> >>>
> >>> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> >>> index 0c5764db127b..c2d29f956065 100644
> >>> --- a/lib/efi_loader/efi_bootmgr.c
> >>> +++ b/lib/efi_loader/efi_bootmgr.c
> >>> @@ -30,28 +30,8 @@ static const struct efi_runtime_services *rs;
> >>> */
> >>>
> >>>
> >>> -/*
> >>> - * See section 3.1.3 in the v2.7 UEFI spec for more details on
> >>> - * the layout of EFI_LOAD_OPTION. In short it is:
> >>> - *
> >>> - *typedef struct _EFI_LOAD_OPTION {
> >>> - *UINT32 Attributes;
> >>> - *UINT16 FilePathListLength;
> >>> - *// CHAR16 Description[]; <-- variable length, NULL terminated
> >>> - *// EFI_DEVICE_PATH_PROTOCOL FilePathList[]; <--
> >>> FilePathListLength bytes
> >>> - *// UINT8 OptionalData[];
> >>> - *} EFI_LOAD_OPTION;
> >>> - */
> >>> -struct load_option {
> >>> - u32 attributes;
> >>> - u16 file_path_length;
> >>> - u16 *label;
> >>> - struct efi_device_path *file_path;
> >>> - u8 *optional_data;
> >>> -};
> >>> -
> >>> /* parse an EFI_LOAD_OPTION, as described above */
> >>> -static void parse_load_option(struct load_option *lo, void *ptr)
> >>> +void efi_parse_load_option(struct load_option *lo, void *ptr)
> >>
> >> I think you want to rename this to "deserialize" to better align with ...
> >>
> >>> {
> >>> lo->attributes = *(u32 *)ptr;
> >>> ptr += sizeof(u32);
> >>> @@ -60,7 +40,7 @@ static void parse_load_option(struct load_option *lo,
> >>> void *ptr)
> >>> ptr += sizeof(u16);
> >>>
> >>> lo->label = ptr;
> >>> - ptr += (u16_strlen(lo->label) + 1) * 2;
> >>> + ptr += (u16_strlen(lo->label) + 1) * sizeof(u16);
> >>>
> >>> lo->file_path = ptr;
> >>> ptr += lo->file_path_length;
> >>> @@ -68,6 +48,48 @@ static void parse_load_option(struct load_option *lo,
> >>> void *ptr)
> >>> lo->optional_data = ptr;
> >>> }
> >>>
> >>> +unsigned long efi_marshal_load_option(u32 attr, u16 *label,
> >>
> >> ... this function which really should be called "serialize" rather than
> >> "marshal". "Marshalling" is
Re: [U-Boot] [PATCH 02/30] riscv: ignore device tree binaries
Hi Lukas, On Sat, Oct 20, 2018 at 6:08 AM Lukas Auer wrote: > > Ignore all device tree binaries in arch/riscv/dts. I don't think this patch is necessary. > > Signed-off-by: Lukas Auer > --- > > arch/riscv/dts/.gitignore | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 arch/riscv/dts/.gitignore > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/30] dts: riscv: update makefile to also clean the RISC-V dts directory
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer wrote: > > Signed-off-by: Lukas Auer > --- > > dts/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/30] tools: .gitignore: add prelink-riscv
On Sat, Oct 20, 2018 at 6:08 AM Lukas Auer wrote: > > Ignore tools/prelink-riscv. > > Signed-off-by: Lukas Auer > --- > > tools/.gitignore | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/30] riscv: select CONFIG_PHYS_64BIT on RV64I systems
On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer wrote: > > CONFIG_PHYS_64BIT should be enabled on RV64I systems. Select it. > > Signed-off-by: Lukas Auer > --- > > arch/riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/30] riscv: rename CPU_RISCV_32/64 to match architecture names ARCH_RV32I/64I
Hi Lukas, On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer wrote: > > RISC-V defines the base integer instruction sets as RV32I and RV64I. > Rename CPU_RISCV_32 and CPU_RISCV_64 to ARCH_RV32I and ARCH_64I to match ARCH_RV64I > this convention. > > Signed-off-by: Lukas Auer > --- > > arch/riscv/Kconfig | 16 > arch/riscv/lib/setjmp.S | 2 +- > configs/ax25-ae350_defconfig| 2 +- > configs/qemu-riscv64_defconfig | 2 +- > include/config_distro_bootcmd.h | 8 > 5 files changed, 15 insertions(+), 15 deletions(-) > Reviewed-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] efi_loader: bootmgr: run an EFI application of a given load option
On 22.10.18 06:37, AKASHI Takahiro wrote: > On Thu, Oct 18, 2018 at 10:46:36AM +0200, Alexander Graf wrote: >> >> >> On 18.10.18 07:48, AKASHI Takahiro wrote: >>> On Wed, Oct 17, 2018 at 10:43:22AM +0200, Alexander Graf wrote: On 17.10.18 09:32, AKASHI Takahiro wrote: > With this patch applied, we will be able to selectively execute > an EFI application by specifying a load option, say "-1" for Boot0001, > "-2" for Boot0002 and so on. > > => bootefi bootmgr -1 I don't think -1 is very good user experience :). How about => bootefi bootmgr Boot0001 >>> >>> It looks like u-boot's run command with six more characters! >>> How about this: >>> >>> => bootefi bootmgr #1 >> >> So what is the problem with making it Boot0001? That way at least the >> variable name is consistent across the board ;). > > More typing! > >>> or allowing "-" as empty fdt, >>> >>> => bootefi bootmgr - 1 > > (Please notice that this is NOT "-1.") > I also like this one as it maintains upward-compatibility: > bootefi bootmgr [ []] > >>> Otherwise, a new sub command? >>> >>> => bootefi run 1, or >>> => efi(shell) run 1 > > Well, if you stick to "setenv -e"-like syntax, how about > => run -e Boot0001 > > Given that "run" takes an environment variable, this syntax > is perfectly fit to U-boot, isn't it? Ooooh, that is an amazing suggestion! And "run -e" without an explicit target could just invoke efibootmgr directly, looping through the BootOrder. > >>> # Discussing UI is a fun or mess. > > # I hope that this is not fruitless discussion. > >> Yeah :(. What we really need would be that "bootefi bootmgr" becomes >> "efiboot". But that would be even more confusing ;). > > So I think that we should not add anything more to "bootefi bootmgr" > to extend functionality. > >> So the whole rationale of why "bootefi" is the way it is today is that >> it's trying to lean on the existing "bootm", "booti", "bootz" etc syntax >> as much as it can. In other words, it's trying to fit into the U-Boot >> ecosystem much rather than the existing edk2 one. > > IMO, "boot*" variants are already a mess. > >> I would like to keep following that path going forward. Whenever there >> is an option between "U-Boot like" and "edk2 like" I would always opt >> for the "U-Boot like" user experience, because if they want edk2 they >> may as well use edk2 ;). > > Well, Boot is quite UEFI-specific and people who are not familiar > with UEFI need to consult UEFI specification anyway and this means, to me, > that UEFI shell's similarity would be favorable. > (See "setvar" syntax, not mine but UEFI shell's, which can be > quite different and complicated.) Well my thinking there is that if someone likes the UEFI Shell, they may as well just run it :). Alex > > Does anybody else have any opinions? > > Thanks, > -Takahiro Akashi > >> >> Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
