[U-Boot] [PATCH] ARM: uniphier: move CONFIG_NAND to defconfig
This imply was added when the option was moved by the moveconfig tool, but the intention is not clear. Move it to defconfig. Signed-off-by: Masahiro Yamada --- arch/arm/mach-uniphier/Kconfig | 1 - configs/uniphier_ld4_sld8_defconfig | 1 + configs/uniphier_pro4_defconfig | 1 + configs/uniphier_pxs2_ld6b_defconfig | 1 + 4 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig index 6a7e239e0d28..ee2211241235 100644 --- a/arch/arm/mach-uniphier/Kconfig +++ b/arch/arm/mach-uniphier/Kconfig @@ -9,7 +9,6 @@ config ARCH_UNIPHIER_32BIT select CPU_V7_HAS_NONSEC select ARMV7_NONSEC select ARCH_SUPPORT_PSCI - imply NAND choice prompt "UniPhier SoC select" diff --git a/configs/uniphier_ld4_sld8_defconfig b/configs/uniphier_ld4_sld8_defconfig index be0ae70f1a89..9c185e612b83 100644 --- a/configs/uniphier_ld4_sld8_defconfig +++ b/configs/uniphier_ld4_sld8_defconfig @@ -36,6 +36,7 @@ CONFIG_GPIO_UNIPHIER=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y CONFIG_MMC_UNIPHIER=y +CONFIG_NAND=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig index 5ba8879af6ae..cdc4809bed6a 100644 --- a/configs/uniphier_pro4_defconfig +++ b/configs/uniphier_pro4_defconfig @@ -35,6 +35,7 @@ CONFIG_GPIO_UNIPHIER=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y CONFIG_MMC_UNIPHIER=y +CONFIG_NAND=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/configs/uniphier_pxs2_ld6b_defconfig b/configs/uniphier_pxs2_ld6b_defconfig index 22c21548b6d7..b487b9dba49f 100644 --- a/configs/uniphier_pxs2_ld6b_defconfig +++ b/configs/uniphier_pxs2_ld6b_defconfig @@ -36,6 +36,7 @@ CONFIG_GPIO_UNIPHIER=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y CONFIG_MMC_UNIPHIER=y +CONFIG_NAND=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: bootefi hello should use loadaddr
On 08/29/2017 01:30 AM, Alexander Graf wrote:
>
>
> On 28.08.17 18:54, Heinrich Schuchardt wrote:
>> Command 'bootefi hello' currently uses CONFIG_SYS_LOAD_ADDR
>> as loading address.
>>
>> qemu machines have by default 128 MiB RAM.
>> CONFIG_SYS_LOAD_ADDR for x86 is 0x2000 (512 MiB).
>> This causes 'bootefi hello' to fail.
>>
>> We should use the environment variable loadaddr if available.
>> It defaults to 0x100 (16 MiB) on qemu_x86.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> cmd/bootefi.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 47771f87cc..a3768158a2 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -300,7 +300,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag,
>> int argc, char * const argv[])
>> if (!strcmp(argv[1], "hello")) {
>> ulong size = __efi_hello_world_end - __efi_hello_world_begin;
>> -addr = CONFIG_SYS_LOAD_ADDR;
>> +saddr = env_get("loadaddr");
>> +if (saddr)
>> +addr = simple_strtoul(saddr, NULL, 16);
>> +else
>> +addr = CONFIG_SYS_LOAD_ADDR;
>
> I'm not terribly happy about that logic. Ideally I would want to have it
> load to *one* explicit address, not multiple ones.
>
> Maybe we could just always memalign() a region?
>
> Alternatively if we can not use memalign, I would rather drop the
> CONFIG_SYS_LOAD_ADDR branch and *only* rely on loadaddr.
>
>
> Alex
>
A user might have deleted loadaddr from the environment.
If we do not fallback to CONFIG_SYS_LOAD_ADDR we would have to create an
error message saying that we cannot do without loadaddr.
Shall I adjust the patch in this way?
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] x86: baytrail: acpi: Add full reset bit to the reset register value in FADT
It was noticed a few times, that the reboot from Linux (reboot command) is different from the reboot (reset command) under U-Boot. The U-Boot version does seem to reset the board more deeply (PCI cards etc) than the Linux reboot. This is actually caused by missing full reset bit in the reset register value in the ACPI FADT table. Reported-by: Stefan Roese Signed-off-by: Bin Meng --- arch/x86/cpu/baytrail/acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c index cbefdf8..7aac634 100644 --- a/arch/x86/cpu/baytrail/acpi.c +++ b/arch/x86/cpu/baytrail/acpi.c @@ -73,7 +73,7 @@ void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs, fadt->reset_reg.access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS; fadt->reset_reg.addrl = IO_PORT_RESET; fadt->reset_reg.addrh = 0; - fadt->reset_value = SYS_RST | RST_CPU; + fadt->reset_value = SYS_RST | RST_CPU | FULL_RST; fadt->x_firmware_ctl_l = (u32)facs; fadt->x_firmware_ctl_h = 0; -- 2.9.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2017.09-rc3 released
On Mon, Aug 28, 2017 at 10:56:52PM -0400, Tom Rini wrote: > Hey all, > > It's release day and v2017.09-rc3 is out. I think there's still a few > outstanding important bugfixes that need to come in, and probably a few > more Kconfig migrations as well. The tag/changes not pushed to git yet? > > If anyone has critical fixes I've missed please speak up. I think I've > got an idea on what they are but never the less, better to speak up now > than assume i saw it. Ethernet is broken on Allwinner A20 without some variation of https://patchwork.ozlabs.org/patch/793903/ but the original submitter hasn't sent a revised diff. > > Things look on track for rc4 on the 4th of September and then a final > release on the 11th.. Thanks all! > > -- > Tom > ___ > 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] ACPI tables for Edison: advice needed
Hi Andy, On Tue, Aug 29, 2017 at 1:12 AM, Andy Shevchenko wrote: > Hi! > > I have a preliminary working ACPI tables for Intel Edison (to replace > ugly SFI provided by firmware). > What I would like to ask is how better from your point of view to proceed. > > I have apparently not all devices covered in the tables, though I have > almost stable code which brings ACPI support to Edison. > > I see few options here: > 0. Do nothing :-) > 1. Apply ACPI code, but leave no tables applied yet. > 2. Apply both and amend whenever problem occurs. > 3. Postpone until kernel will be ready for that (*) > 4. ...other option...? > I would vote for option 2. > *) LInux kernel (vanilla) is not ready for this change. It means in > all above cases there will be neither new config file (like > edison_acpi_defconfig) nor modification to the existing one (of > course!). The stuff is highly experimental now. Does Linux kernel need to do anything to support ACPI on Intel Edison? My understanding is that ACPI is a standard spec, and as long as our U-Boot implementation matches the spec, Linux kernel can support it out of the box. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Resync NAND framework with Linux?
Hi Heiko 2017-08-28 15:37 GMT+09:00 Heiko Schocher : > Hello Masahiro, > > Am 25.08.2017 um 13:19 schrieb Masahiro Yamada: >> >> Hi all. >> >> It is more than one year since the last re-sync. >> https://lists.denx.de/pipermail/u-boot/2016-May/256464.html >> >> >> Any plan for re-sync? >> >> >> >> My main motivation is to update denali.c >> >> Recently, I reworked the denali driver in Linux >> (thanks to Boris for the review!) >> >> The U-Boot variant driver does not work >> on some of my boards, so I need to fix it as well. >> >> I would be nice to import my efforts from Linux, >> but some hooks / helpers are missing in the framework. > > > I think a rebase with linux would be nice, but is it enough to > resync NAND only? ... or do you mean a MTD re-sync? My main interest is NAND, but the whole MTD resync would be nicer. > Also resync UBI/UBIFS with current linux version would be a nice > idea, but I have not found time for it, and nobody seems to need > it ... also I have no good testsetup yet handy for trying it fast. > > So, sorry, I have no plan for doing such a rebase ... > > Not an unsolvable job, but it needs time and particularly good testing. I do not have enough time either. If nobody does this, I will cherry pick some commits. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] omap3: am3517_evm: Enable TI_COMMON_CMD_OPTION
On Tue, Aug 22, 2017 at 10:50:02AM -0500, Adam Ford wrote: > Enable TI_COMMON_CMD_OPTIONS and remove similar options > from the defconfig. Updated with savedefconfig. > > Signed-off-by: Adam Ford Tested-by: Derald D. Woods > --- > board/logicpd/am3517evm/Kconfig | 2 ++ > configs/am3517_evm_defconfig| 23 --- > 2 files changed, 10 insertions(+), 15 deletions(-) > > diff --git a/board/logicpd/am3517evm/Kconfig b/board/logicpd/am3517evm/Kconfig > index 901f609..743e500 100644 > --- a/board/logicpd/am3517evm/Kconfig > +++ b/board/logicpd/am3517evm/Kconfig > @@ -9,4 +9,6 @@ config SYS_VENDOR > config SYS_CONFIG_NAME > default "am3517_evm" > > +source "board/ti/common/Kconfig" > + > endif > diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig > index e37d8cf..34043f8 100644 > --- a/configs/am3517_evm_defconfig > +++ b/configs/am3517_evm_defconfig > @@ -2,9 +2,9 @@ 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 > # CONFIG_SPL_GPIO_SUPPORT is not set > CONFIG_TARGET_AM3517_EVM=y > -CONFIG_ENV_IS_IN_NAND=y > CONFIG_BOOTDELAY=10 > CONFIG_VERSION_VARIABLE=y > CONFIG_SPL=y > @@ -12,33 +12,26 @@ CONFIG_SPL=y > CONFIG_SPL_MTD_SUPPORT=y > CONFIG_HUSH_PARSER=y > CONFIG_SYS_PROMPT="AM3517_EVM # " > -CONFIG_CMD_BOOTZ=y > # CONFIG_CMD_IMI is not set > # CONFIG_CMD_IMLS is not set > -CONFIG_CMD_ASKENV=y > +# CONFIG_CMD_EEPROM is not set > # CONFIG_CMD_FLASH is not set > # CONFIG_CMD_FPGA is not set > -CONFIG_CMD_GPIO=y > -CONFIG_CMD_I2C=y > -CONFIG_CMD_MMC=y > +# CONFIG_CMD_GPT is not set > CONFIG_CMD_NAND=y > -CONFIG_CMD_PART=y > -CONFIG_CMD_USB=y > +# CONFIG_CMD_SPI is not set > # CONFIG_CMD_SETEXPR is not set > -CONFIG_CMD_DHCP=y > -CONFIG_CMD_PING=y > +# CONFIG_CMD_MII is not set > CONFIG_CMD_CACHE=y > -CONFIG_CMD_EXT2=y > -CONFIG_CMD_EXT4=y > -CONFIG_CMD_EXT4_WRITE=y > -CONFIG_CMD_FAT=y > -CONFIG_CMD_FS_GENERIC=y > +# CONFIG_CMD_TIME is not set > CONFIG_CMD_UBI=y > CONFIG_SPL_PARTITION_UUIDS=y > +CONFIG_ENV_IS_IN_NAND=y > CONFIG_MMC_OMAP_HS=y > CONFIG_NAND=y > CONFIG_SYS_NS16550=y > CONFIG_USB=y > CONFIG_USB_MUSB_HOST=y > CONFIG_USB_STORAGE=y > +# CONFIG_FAT_WRITE is not set > CONFIG_OF_LIBFDT=y > -- > 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 1/2] ARM: OMAP3: am3517_evm: Move header to ti_omap3_common.h
On Tue, Aug 22, 2017 at 10:50:01AM -0500, Adam Ford wrote:
> Much of the AM3517 functions are copies of the standard definitions
> used in ti_omap3_common.h. Moving to include a common file
> reduces the amount of duplicative code and clutter. A few
> AM3517 specific functions (like EMIF4) are explictly defined
> and a few items are undefined or redefined, but overall the number
> of lines of code shink.
>
> Signed-off-by: Adam Ford
Tested-by: Derald D. Woods
> ---
> include/configs/am3517_evm.h | 48
> +---
> 1 file changed, 5 insertions(+), 43 deletions(-)
>
> diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
> index e957a28..9bf50e6 100644
> --- a/include/configs/am3517_evm.h
> +++ b/include/configs/am3517_evm.h
> @@ -14,7 +14,6 @@
> #define __CONFIG_H
>
> #define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */
> -
> #define CONFIG_EMIF4 /* The chip has EMIF4 controller */
>
> /*
> @@ -27,39 +26,26 @@
> #define CONFIG_SYS_SPL_MALLOC_START 0x80208000
> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x10
>
> -#include /* get chip and board defs */
> -#include
> +#include
> +#undef CONFIG_SDRC /* Disable SDRC since we have EMIF4 */
>
> #define CONFIG_MISC_INIT_R
> -#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
> -#define CONFIG_SETUP_MEMORY_TAGS
> -#define CONFIG_INITRD_TAG
> #define CONFIG_REVISION_TAG
>
> -/* Clock Defines */
> -#define V_OSCK 2600/* Clock output from T2
> */
> -#define V_SCLK (V_OSCK >> 1)
> -
> -/* Size of malloc() pool */
> -#define CONFIG_SYS_MALLOC_LEN(16 << 20)
> -
> /* Hardware drivers */
>
> /* NS16550 Configuration */
> -#define V_NS16550_CLK4800/* 48MHz
> (APLL96/2) */
> #define CONFIG_SYS_NS16550_SERIAL
> #define CONFIG_SYS_NS16550_REG_SIZE (-4)
> -#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
>
> /* select serial console configuration */
> #define CONFIG_CONS_INDEX3
> #define CONFIG_SYS_NS16550_COM3 OMAP34XX_UART3
> #define CONFIG_SERIAL3 3 /* UART3 on AM3517 EVM
> */
>
> +
> /* allow to overwrite serial and ethaddr */
> #define CONFIG_ENV_OVERWRITE
> -#define CONFIG_SYS_BAUDRATE_TABLE{4800, 9600, 19200, 38400, 57600,\
> - 115200}
>
> /*
> * USB configuration
> @@ -104,16 +90,10 @@
>
> /* Board NAND Info. */
> #ifdef CONFIG_NAND
> -#define CONFIG_NAND_OMAP_GPMC
> #define CONFIG_NAND_OMAP_GPMC_PREFETCH
> #define CONFIG_BCH
> #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */
> /* to access nand */
> -#define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
> - /* to access */
> - /* nand at CS0 */
> -#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */
> - /* NAND devices */
> #define CONFIG_SYS_NAND_BUSWIDTH_16BIT
> #define CONFIG_SYS_NAND_5_ADDR_CYCLE
> #define CONFIG_SYS_NAND_PAGE_COUNT 64
> @@ -233,8 +213,6 @@
> /* We set the max number of command args high to avoid HUSH bugs. */
> #define CONFIG_SYS_MAXARGS 64
>
> -/* Console I/O Buffer Size */
> -#define CONFIG_SYS_CBSIZE512
> /* Print Buffer Size */
> #define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE \
> + sizeof(CONFIG_SYS_PROMPT) + 16)
> @@ -246,27 +224,10 @@
> #define CONFIG_SYS_MEMTEST_END (OMAP34XX_SDRC_CS0 + \
> 0x01F0) /* 31MB */
>
> -#define CONFIG_SYS_LOAD_ADDR (OMAP34XX_SDRC_CS0) /* default load */
> - /* address */
> -
> -/*
> - * AM3517 has 12 GP timers, they can be driven by the system clock
> - * (12/13/16.8/19.2/38.4MHz) or by 32KHz clock. We use 13MHz (V_SCLK).
> - * This rate is divided by a local divisor.
> - */
> -#define CONFIG_SYS_TIMERBASE OMAP34XX_GPT2
> -#define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1)
> => 8 */
> -
> /* Physical Memory Map */
> -#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0
> -#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1
> #define CONFIG_SYS_CS0_SIZE (256 * 1024 * 1024)
> -#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1
> #define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800
> #define CONFIG_SYS_INIT_RAM_SIZE 0x800
> -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \
> - CONFIG_SYS_INIT_RAM_SIZE - \
> - GENERATED_GBL_DATA_SIZE)
>
> /* FLASH and environment
[U-Boot] [PATCH 2/4] reset: uniphier: add PXs3 support
Signed-off-by: Masahiro Yamada
---
drivers/reset/reset-uniphier.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 8a037cf735dd..b6bde70d6f6e 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -77,6 +77,17 @@ static const struct uniphier_reset_data
uniphier_ld20_sys_reset_data[] = {
UNIPHIER_RESET_END,
};
+static const struct uniphier_reset_data uniphier_pxs3_sys_reset_data[] = {
+ UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
+ UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
+ UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
+ UNIPHIER_RESETX(12, 0x200c, 5), /* GIO0 */
+ UNIPHIER_RESETX(13, 0x200c, 6), /* GIO1 */
+ UNIPHIER_RESETX(16, 0x200c, 16),/* USB30-PHY */
+ UNIPHIER_RESETX(20, 0x200c, 17),/* USB31-PHY */
+ UNIPHIER_RESET_END,
+};
+
/* Media I/O reset data */
#define UNIPHIER_MIO_RESET_SD(id, ch) \
UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
@@ -268,6 +279,10 @@ static const struct udevice_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-reset",
.data = (ulong)uniphier_ld20_sys_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-reset",
+ .data = (ulong)uniphier_pxs3_sys_reset_data,
+ },
/* Media I/O reset */
{
.compatible = "socionext,uniphier-ld4-mio-reset",
@@ -301,6 +316,10 @@ static const struct udevice_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-sd-reset",
.data = (ulong)uniphier_mio_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-sd-reset",
+ .data = (ulong)uniphier_mio_reset_data,
+ },
/* Peripheral reset */
{
.compatible = "socionext,uniphier-ld4-peri-reset",
@@ -330,6 +349,10 @@ static const struct udevice_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-ld20-peri-reset",
.data = (ulong)uniphier_pro4_peri_reset_data,
},
+ {
+ .compatible = "socionext,uniphier-pxs3-peri-reset",
+ .data = (ulong)uniphier_pro4_peri_reset_data,
+ },
{ /* sentinel */ }
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM: dts: uniphier: sync with Linux
Import updates queued up for Linux 4.14-rc1.
Signed-off-by: Masahiro Yamada
---
arch/arm/dts/uniphier-ld11-global.dts | 6 +-
arch/arm/dts/uniphier-ld11-ref.dts| 6 +++---
arch/arm/dts/uniphier-ld11.dtsi | 13 +
arch/arm/dts/uniphier-ld20-global.dts | 6 +-
arch/arm/dts/uniphier-ld20-ref.dts| 6 +++---
arch/arm/dts/uniphier-ld20.dtsi | 15 ++-
arch/arm/dts/uniphier-ld4-ref.dts | 6 +++---
arch/arm/dts/uniphier-ld4.dtsi| 11 ++-
arch/arm/dts/uniphier-ld6b-ref.dts| 6 +++---
arch/arm/dts/uniphier-ld6b.dtsi | 2 +-
arch/arm/dts/uniphier-pinctrl.dtsi| 5 +
arch/arm/dts/uniphier-pro4-ace.dts| 2 +-
arch/arm/dts/uniphier-pro4-ref.dts| 6 +++---
arch/arm/dts/uniphier-pro4-sanji.dts | 2 +-
arch/arm/dts/uniphier-pro4.dtsi | 9 +
arch/arm/dts/uniphier-pro5-4kbox.dts | 4 ++--
arch/arm/dts/uniphier-pro5.dtsi | 13 +++--
arch/arm/dts/uniphier-pxs2-gentil.dts | 2 +-
arch/arm/dts/uniphier-pxs2-vodka.dts | 2 +-
arch/arm/dts/uniphier-pxs2.dtsi | 13 +++--
arch/arm/dts/uniphier-sld8-ref.dts| 6 +++---
arch/arm/dts/uniphier-sld8.dtsi | 11 ++-
22 files changed, 90 insertions(+), 62 deletions(-)
diff --git a/arch/arm/dts/uniphier-ld11-global.dts
b/arch/arm/dts/uniphier-ld11-global.dts
index 7a650a02486a..5ffe7dedf723 100644
--- a/arch/arm/dts/uniphier-ld11-global.dts
+++ b/arch/arm/dts/uniphier-ld11-global.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ "uniphier-ld11.dtsi"
+#include "uniphier-ld11.dtsi"
/ {
model = "UniPhier LD11 Global Board (REF_LD11_GP)";
@@ -68,3 +68,7 @@
&usb2 {
status = "okay";
};
+
+&nand {
+ status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ld11-ref.dts
b/arch/arm/dts/uniphier-ld11-ref.dts
index cc8ebe34c27c..ffb473ad2e0f 100644
--- a/arch/arm/dts/uniphier-ld11-ref.dts
+++ b/arch/arm/dts/uniphier-ld11-ref.dts
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-/include/ "uniphier-ld11.dtsi"
-/include/ "uniphier-ref-daughter.dtsi"
-/include/ "uniphier-support-card.dtsi"
+#include "uniphier-ld11.dtsi"
+#include "uniphier-ref-daughter.dtsi"
+#include "uniphier-support-card.dtsi"
/ {
model = "UniPhier LD11 Reference Board";
diff --git a/arch/arm/dts/uniphier-ld11.dtsi b/arch/arm/dts/uniphier-ld11.dtsi
index 74f8f721a888..0f172c31db69 100644
--- a/arch/arm/dts/uniphier-ld11.dtsi
+++ b/arch/arm/dts/uniphier-ld11.dtsi
@@ -348,9 +348,11 @@
};
};
- aidet@5fc2 {
- compatible = "simple-mfd", "syscon";
+ aidet: aidet@5fc2 {
+ compatible = "socionext,uniphier-ld11-aidet";
reg = <0x5fc2 0x200>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
gic: interrupt-controller@5fe0 {
@@ -376,6 +378,10 @@
compatible = "socionext,uniphier-ld11-reset";
#reset-cells = <1>;
};
+
+ watchdog {
+ compatible = "socionext,uniphier-wdt";
+ };
};
nand: nand@6800 {
@@ -387,9 +393,8 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand>;
clocks = <&sys_clk 2>;
- nand-ecc-strength = <8>;
};
};
};
-/include/ "uniphier-pinctrl.dtsi"
+#include "uniphier-pinctrl.dtsi"
diff --git a/arch/arm/dts/uniphier-ld20-global.dts
b/arch/arm/dts/uniphier-ld20-global.dts
index 9f620d4101b5..fc2bc9d75d35 100644
--- a/arch/arm/dts/uniphier-ld20-global.dts
+++ b/arch/arm/dts/uniphier-ld20-global.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ "uniphier-ld20.dtsi"
+#include "uniphier-ld20.dtsi"
/ {
model = "UniPhier LD20 Global Board (REF_LD20_GP)";
@@ -50,3 +50,7 @@
&i2c0 {
status = "okay";
};
+
+&nand {
+ status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ld20-ref.dts
b/arch/arm/dts/uniphier-ld20-ref.dts
index 494166aee24c..1ca0c8620dc5 100644
--- a/arch/arm/dts/uniphier-ld20-ref.dts
+++ b/arch/arm/dts/uniphier-ld20-ref.dts
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-/include/ "uniphier-ld20.dtsi"
-/include/ "uniphier-ref-daughter.dtsi"
-/include/ "uniphier-support-card.dtsi"
+#include "uniphier-ld20.dtsi"
+#include "uniphier-ref-daughter.dtsi"
+#include "uniphier-support-card.dtsi"
/ {
model = "UniPhier LD20 Reference Board";
diff --git a/arch/arm/dts/uniphier-ld20.dtsi b/arch/arm/dts/uniphier-ld20.dtsi
index 44257aff35b9..a7fdaa74d155 100644
--- a/arch/arm/dts/uniphier-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ld20.dtsi
@@ -313,7 +313,7 @@
sdctrl@5981 {
compatible = "socionext,uniphier-ld20-sdctrl",
Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
Hi York,
> + if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> + ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
When the pcie slot have no device, the pcie controller access this register
return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to
avoid unnecessary delay, return directly.
Reference the spec, except L0 state, the L0s L1 L2state can consider the link
state, but these state regards the power management, our pcie driver have not
power management code in uboot, so just need to judge the L0 state.
Thanks
-Original Message-
From: York Sun
Sent: Tuesday, August 29, 2017 1:15 AM
To: Xiaowei Bao
Cc: Joakim Tjernlund ; u-boot@lists.denx.de
Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei
On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
>> On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
>>> FSL PCIe controller drivers before REV 3 has this test for link up:
>>> enabled = ltssm >= PCI_LTSSM_L0;
>>>
>>> We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance)
>>> when non ready for PCI transaktions. When FSL PCIe controller tries
>>> to access this device, it hangs forever.
>>>
>>> Is LTSSM=0x51 really a "legal" state for link up?
>>> If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
>>>
>>>Jocke
>>>
>>> BTW, the same test is valid in Linux too.
>>>
>>
>> Jocke,
>>
>> I am not an expert on PCIe. Please if this thread is helpful,
> Me neither .. :)
>>
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0.
>
> It mentions polling compliance but this driver already tests for:
> if (ltssm < LTSSM_PCIE_L0)
> return 0;
> return 1;
>
> It just adds some delay if the device is in Polling Compliance to see
> if that changes to L0.
> Since both layerscape and fsl >= rev 3 already require ltssm to be ==
> L0, I suspect the ltssm >= L0 is bogus.
>
Xiaowei, can you comment?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2017.09-rc3 released
Hey all, It's release day and v2017.09-rc3 is out. I think there's still a few outstanding important bugfixes that need to come in, and probably a few more Kconfig migrations as well. If anyone has critical fixes I've missed please speak up. I think I've got an idea on what they are but never the less, better to speak up now than assume i saw it. Things look on track for rc4 on the 4th of September and then a final release on the 11th.. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,05/14] nvme: Cache controller's capabilities
On Tue, Aug 22, 2017 at 08:15:10AM -0700, Bin Meng wrote: > Capabilities register is RO and accessed at various places in the > driver. Let's cache it in the controller driver's priv struct. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 08/14] nvme: Consolidate block read and write routines
On Tue, Aug 22, 2017 at 08:15:13AM -0700, Bin Meng wrote: > The NVMe block read and write routines are almost the same except > the command opcode. Let's consolidate them to avoid duplication. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] ARM: dts: uniphier: update PXs3 SoC/board DT
Support PXs3 SoC and its reference development board.
Signed-off-by: Masahiro Yamada
---
arch/arm/dts/uniphier-pxs3-ref.dts | 21 --
arch/arm/dts/uniphier-pxs3.dtsi| 127 -
2 files changed, 98 insertions(+), 50 deletions(-)
diff --git a/arch/arm/dts/uniphier-pxs3-ref.dts
b/arch/arm/dts/uniphier-pxs3-ref.dts
index cb1eef43c464..d65f746a3f9d 100644
--- a/arch/arm/dts/uniphier-pxs3-ref.dts
+++ b/arch/arm/dts/uniphier-pxs3-ref.dts
@@ -4,13 +4,12 @@
* Copyright (C) 2017 Socionext Inc.
* Author: Masahiro Yamada
*
- * SPDX-License-Identifier:GPL-2.0+X11
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
/dts-v1/;
-/include/ "uniphier-pxs3.dtsi"
-/include/ "uniphier-ref-daughter.dtsi"
-/include/ "uniphier-support-card.dtsi"
+#include "uniphier-pxs3.dtsi"
+#include "uniphier-support-card.dtsi"
/ {
model = "UniPhier PXs3 Reference Board";
@@ -39,7 +38,7 @@
};
ðsc {
- interrupts = <0 48 4>;
+ interrupts = <0 52 4>;
};
&serial0 {
@@ -49,3 +48,15 @@
&i2c0 {
status = "okay";
};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-pxs3.dtsi b/arch/arm/dts/uniphier-pxs3.dtsi
index cdf7f9005f73..8615ba0bc771 100644
--- a/arch/arm/dts/uniphier-pxs3.dtsi
+++ b/arch/arm/dts/uniphier-pxs3.dtsi
@@ -4,46 +4,10 @@
* Copyright (C) 2017 Socionext Inc.
* Author: Masahiro Yamada
*
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- * a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- * b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
-/memreserve/ 0x8000 0x0008;
+/memreserve/ 0x8000 0x0200;
/ {
compatible = "socionext,uniphier-pxs3";
@@ -76,28 +40,74 @@
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x000>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x001>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x002>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x003>;
+ clocks = <&sys_clk 33>;
enable-method
[U-Boot] [PATCH 1/4] reset: uniphier: fix compatible for SD reset node for LD11/LD20
LD20 has SD ctrl instead of MIO ctrl. LD11 has both of them.
Signed-off-by: Masahiro Yamada
---
drivers/reset/reset-uniphier.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index ebb2cae5eb33..8a037cf735dd 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -294,7 +294,11 @@ static const struct udevice_id uniphier_reset_match[] = {
.data = (ulong)uniphier_mio_reset_data,
},
{
- .compatible = "socionext,uniphier-ld20-mio-reset",
+ .compatible = "socionext,uniphier-ld11-sd-reset",
+ .data = (ulong)uniphier_mio_reset_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld20-sd-reset",
.data = (ulong)uniphier_mio_reset_data,
},
/* Peripheral reset */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 02/14] nvme: Fix getting PCI vendor id of the NVMe block device
On Tue, Aug 22, 2017 at 08:15:07AM -0700, Bin Meng wrote: > The codes currently try to read PCI vendor id of the NVMe block > device by dm_pci_read_config16() with its parameter set as its > root complex controller (ndev->pdev) instead of itself. This is > seriously wrong. We can read the vendor id by passing the correct > udevice parameter to the dm_pci_read_config16() API, however there > is a shortcut by reading the cached vendor id from the PCI device's > struct pci_child_platdata. > > While we are here fixing this bug, apparently the quirk stuff handle > codes in nvme_get_info_from_identify() never takes effect since its > logic has never been true at all. Remove these codes completely. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 11/14] nvme: Get rid of the global variable nvme_info
On Tue, Aug 22, 2017 at 08:15:16AM -0700, Bin Meng wrote: > At present the NVMe uclass driver uses a global variable nvme_info > to store global information like namespace id, and NVMe controller > driver's priv struct has a blk_dev_start that is used to calculate > the namespace id based on the global information from nvme_info. > > This is not a good design in the DM world and can be replaced with > the following changes: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3] bootvx_fdt: fix missing 'fdt_fixup_ethernet(...)' on vxWorks boot
On Fri, Aug 25, 2017 at 02:27:37PM +0200, Hannes Schmelzer wrote: > Before commit 26d6119 (fdt: Move fdt_fixup_ethernet to a common place) > the fdt_fixup_ethernet(...) was called during do_bootvx_fdt(...). > > Afterwards the only (common) place for this fixup is during > image_setup_libfdt(...) and this is only called, at least on ARM > platform, from image_setup_linux(...). > > All this ends up in the fact, that the fdt_fixup_ethernet(...) is only > called on booting a linux image and not on booting a vxWorks image. > > We fix this with adding the fdt_fixup_ethernet(...) call again to > do_bootvx_fdt(...) > > Signed-off-by: Hannes Schmelzer > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 14/14] sandbox: Enable NVMe driver for build testing
On Tue, Aug 22, 2017 at 08:15:19AM -0700, Bin Meng wrote: > This enables NVMe driver on sandbox for build testing. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,10/14] nvme: Use blk_create_devicef() API
On Tue, Aug 22, 2017 at 08:15:15AM -0700, Bin Meng wrote: > The codes in nvme_uclass_post_probe() can be replaced to call the > blk_create_devicef() API directly. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,07/14] nvme: Use macros to access NVMe queues
On Tue, Aug 22, 2017 at 08:15:12AM -0700, Bin Meng wrote: > NVMe driver only uses two queues. The first one is allocated to do > admin stuff, while the second one is for IO stuff. So far the driver > uses magic number (0/1) to access them. Change to use macros. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 09/14] nvme: Apply cache operations on the DMA buffers
On Tue, Aug 22, 2017 at 08:15:14AM -0700, Bin Meng wrote: > So far cache operations are only applied on the submission queue and > completion queue, but they are missing in other places like identify > and block read/write routines. > > In order to correctly operate on the caches, the DMA buffer passed > to identify routine must be allocated properly on the stack with the > existing macro ALLOC_CACHE_ALIGN_BUFFER(). > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 04/14] nvme: Fix endianness assignment to prp2 in nvme_identify()
On Tue, Aug 22, 2017 at 08:15:09AM -0700, Bin Meng wrote: > So far this is not causing any issue due to NVMe and x86 are using > the same endianness, but for correctness, it should be fixed. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] common: console: Fix duplicated CONFIG in silent env callback
On Fri, Aug 25, 2017 at 12:06:29AM -0700, Wilson Lee wrote: > The silent environment callback function does not update the silent > flag during silent env set or unset. That is because of duplicated > CONFIG keyword at preprocessor condition in silent environment > callback function and cause silent env callback unable to work. > > This patch is to remove the duplicated CONFIG keywork in silent > environment callback function. > > Signed-off-by: Wilson Lee > Cc: Keng Soon Cheah > Cc: Chen Yee Chew > Cc: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 13/14] sandbox: Add a dummy invalidate_dcache_range() function
On Tue, Aug 22, 2017 at 08:15:18AM -0700, Bin Meng wrote: > This adds invalidate_dcache_range() so that some drivers can build > without error on sandbox. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 06/14] nvme: Respect timeout when en/disabling the controller
On Tue, Aug 22, 2017 at 08:15:11AM -0700, Bin Meng wrote: > So far the driver unconditionally delays 10ms when en/disabling the > controller and still return 0 if 10ms times out. In fact, spec defines > a timeout value in the CAP register that is the worst case time that > host software shall wait for the controller to become ready. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 12/14] nvme: Adjust the 'nvme' command to use blk_common_cmd()
On Tue, Aug 22, 2017 at 08:15:17AM -0700, Bin Meng wrote: > Instead of having separate code in the 'nvme' command, adjust it to use > the common function. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,01/14] nvme: Remove useless defines
On Tue, Aug 22, 2017 at 08:15:06AM -0700, Bin Meng wrote: > These are leftover when the driver was ported from Linux and are not > used by the U-Boot driver. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,03/14] nvme: Fix ndev->queues allocation
On Tue, Aug 22, 2017 at 08:15:08AM -0700, Bin Meng wrote: > ndev->queues is a pointer to pointer, but the allocation wrongly > requests sizeof(struct nvme_queue). Fix it. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] omap3: evm: Fixes for CONFIG_NAND, SPL_OS_BOOT, USB, and environment
- Pass MTDPARTS kernel arguments to kernel
- Use Kconfig CONFIG_NAND instead of CONFIG_SYS_EXTRA_OPTIONS="NAND"
- Call 'usb_stop' on kernel start
- Update Falcon mode setup to match other OMAP3 boards
- Use "uEnv.txt" as boot script instead of "boot.scr"
---
board/ti/evm/evm.c | 20 +++-
configs/omap3_evm_defconfig | 2 +-
include/configs/omap3_evm.h | 30 --
3 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 6bf57f9269..1f0433dcc0 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -122,6 +122,17 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_SPL_OS_BOOT)
+int spl_start_uboot(void)
+{
+ /* break into full u-boot on 'c' */
+ if (serial_tstc() && serial_getc() == 'c')
+ return 1;
+
+ return 0;
+}
+#endif /* CONFIG_SPL_OS_BOOT */
+
#if defined(CONFIG_SPL_BUILD)
/*
* Routine: get_board_mem_timings
@@ -323,7 +334,14 @@ void board_mmc_power_init(void)
}
#endif /* CONFIG_MMC */
-#if defined(CONFIG_USB_EHCI_HCD)
+#if defined(CONFIG_USB_EHCI_HCD) && !defined(CONFIG_SPL_BUILD)
+/* Call usb_stop() before starting the kernel */
+void show_boot_progress(int val)
+{
+ if (val == BOOTSTAGE_ID_RUN_OS)
+ usb_stop();
+}
+
static struct omap_usbhs_board_data usbhs_bdata = {
.port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
diff --git a/configs/omap3_evm_defconfig b/configs/omap3_evm_defconfig
index a07ea0fd55..6316b797fd 100644
--- a/configs/omap3_evm_defconfig
+++ b/configs/omap3_evm_defconfig
@@ -7,7 +7,6 @@ CONFIG_SYS_MPUCLK=720
CONFIG_TARGET_OMAP3_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x8200
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_SYS_EXTRA_OPTIONS="NAND"
CONFIG_ENV_IS_IN_NAND=y
CONFIG_BOOTDELAY=3
CONFIG_SYS_CONSOLE_INFO_QUIET=y
@@ -44,6 +43,7 @@ CONFIG_DM=y
CONFIG_SPL_DM=y
CONFIG_DM_GPIO=y
CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
CONFIG_MTD=y
CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 9930483406..8972e96366 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -36,7 +36,6 @@
#define CONFIG_INITRD_TAG
#define CONFIG_REVISION_TAG
-
/* Override OMAP3 serial console configuration */
#undef CONFIG_CONS_INDEX
#define CONFIG_CONS_INDEX 1
@@ -76,11 +75,14 @@
#define CONFIG_SPL_OMAP3_ID_NAND
#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */
#define CONFIG_MTD_PARTITIONS /* required for UBI partition support
*/
+/* NAND: SPL falcon mode configs */
+#if defined(CONFIG_SPL_OS_BOOT)
+#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0x28
+#endif /* CONFIG_SPL_OS_BOOT */
#endif /* CONFIG_NAND */
-#define CONFIG_USB_OMAP3
-
/* MUSB */
+#define CONFIG_USB_OMAP3
#define CONFIG_USB_MUSB_OMAP2PLUS
#define CONFIG_USB_MUSB_PIO_ONLY
#define CONFIG_USB_ETHER
@@ -101,28 +103,32 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
- "mtdids=" CONFIG_MTDIDS_DEFAULT "\0"\
+ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "loadaddr=0x8200\0" \
- "usbtty=cdc_acm\0" \
+ "bootenv=uEnv.txt\0" \
+ "optargs=\0" \
"mmcdev=0\0" \
"console=ttyO0,115200n8\0" \
"mmcargs=setenv bootargs console=${console} " \
+ "${mtdparts} " \
"${optargs} " \
"root=/dev/mmcblk0p2 rw " \
"rootfstype=ext4 rootwait\0" \
"nandargs=setenv bootargs console=${console} " \
+ "${mtdparts} " \
"${optargs} " \
"root=ubi0:rootfs rw ubi.mtd=rootfs noinitrd " \
"rootfstype=ubifs rootwait\0" \
- "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t ${loadaddr} ${filesize}\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source ${loadaddr}\0" \
"loaduimage=setenv bootfile uImage; " \
"fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"loadzimage=setenv bootfile zImage; " \
"fatload mmc ${mmcdev} ${loadaddr} zImage\0" \
- "loaddtb=fatload mmc ${mmcdev} ${fdtaddr} omap3-evm.dtb\0" \
+ "loaddtb=fatload mmc ${mmcdev} ${fdtaddr} " CONFIG_DEFAULT_FDT_FILE
"\0" \
"mmcboot=echo Booting ${bootfile} from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr} - ${fdtaddr}\0" \
@@ -137,8 +143,12 @@
#define CONFIG_BOOTCOMMAND \
"mmc dev ${mmcdev}; if mmc rescan; then " \
- "if run loadbootscript; then " \
- "run bootscript; " \
+ "if run loadbootenv; then " \
+
Re: [U-Boot] [PATCH v2] serial: nulldev: Add nulldev serial driver
Hi Wilson, On Fri, Aug 25, 2017 at 11:29 AM, Wilson Lee wrote: > From: Keng Soon Cheah > > Some device the serial console's initialization cannot run early during > the boot process. Hence, nulldev serial device is helpful on that > situation. > > For example, if the serial module was implemented in FPGA. Serial > initialization is prohibited to run until the FPGA was programmed. > I still don't fully understand this. Shouldn't the FPGA serial driver has some sort of register bits that determine if it's ready? And if not ready, the FPGA serial driver can do nothing like your null serial driver does? > This commit is to adding nulldev serial driver. This will allows the > default console to be specified as a nulldev. > > Signed-off-by: Joe Hershberger > Signed-off-by: Keng Soon Cheah > Cc: Chen Yee Chew > --- > drivers/serial/Kconfig | 7 ++ > drivers/serial/Makefile | 1 + > drivers/serial/serial_nulldev.c | 48 > + > 3 files changed, 56 insertions(+) > create mode 100644 drivers/serial/serial_nulldev.c > [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] board: ti: am57xx: Add dt support for BeagleBoard-X15 revC
On Mon, Aug 28, 2017 at 6:19 AM, Tom Rini wrote: > On Wed, Aug 23, 2017 at 11:39:06AM +0530, Lokesh Vutla wrote: > >> Add support for selecting proper dtb for >> am57xx BeagleBoard X15 revC u-boot from FIT >> >> Signed-off-by: Lokesh Vutla >> Reviewed-by: Tom Rini >> --- >> arch/arm/dts/Makefile | 1 + >> board/ti/am57xx/board.c | 3 +++ >> configs/am57xx_evm_defconfig| 2 +- >> configs/am57xx_hs_evm_defconfig | 2 +- >> 4 files changed, 6 insertions(+), 2 deletions(-) > > am57xx-beagle-x15-revc.dts isn't included, what series brings that in? > Thanks! it's pretty small, so got buried in: "arm: dts: dra7: sync DT with latest Linux" https://patchwork.ozlabs.org/patch/803942/ Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: bootefi hello should use loadaddr
On 28.08.17 18:54, Heinrich Schuchardt wrote:
Command 'bootefi hello' currently uses CONFIG_SYS_LOAD_ADDR
as loading address.
qemu machines have by default 128 MiB RAM.
CONFIG_SYS_LOAD_ADDR for x86 is 0x2000 (512 MiB).
This causes 'bootefi hello' to fail.
We should use the environment variable loadaddr if available.
It defaults to 0x100 (16 MiB) on qemu_x86.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 47771f87cc..a3768158a2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -300,7 +300,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
if (!strcmp(argv[1], "hello")) {
ulong size = __efi_hello_world_end - __efi_hello_world_begin;
- addr = CONFIG_SYS_LOAD_ADDR;
+ saddr = env_get("loadaddr");
+ if (saddr)
+ addr = simple_strtoul(saddr, NULL, 16);
+ else
+ addr = CONFIG_SYS_LOAD_ADDR;
I'm not terribly happy about that logic. Ideally I would want to have it
load to *one* explicit address, not multiple ones.
Maybe we could just always memalign() a region?
Alternatively if we can not use memalign, I would rather drop the
CONFIG_SYS_LOAD_ADDR branch and *only* rely on loadaddr.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On 08/28/2017 11:33 PM, Łukasz Majewski wrote: > On 08/28/2017 10:32 PM, Marek Vasut wrote: >> On 08/28/2017 09:28 PM, Łukasz Majewski wrote: >>> Dear Marek, >>> >>> Those patches are preferably for -next merge widow. >>> >>> >>> >>> The following changes since commit >>> ae61b5353b48fa49c66376f273cc53cd3c06b656: >>> >>> usb: dwc3: fix Kconfig dependency to accept host driver in >>> drivers/usb/dwc3 (2017-08-25 11:23:27 +0200) >>> >>> are available in the git repository at: >>> >>> u-boot-denx-dfu/master >> >> Might be a good idea to put it into -next branch then. > > +1. > > I will create -next branch :-) Don't bother for this PR, I pulled it. Please do so in the future. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] undefined reference to `environment'
Hi Simon / Tom, It seems the SH4 build is failing with the current trunk. Or at least my test build is failing and the change seems to have nothing to do with the failure. https://travis-ci.org/jhershbe/u-boot/jobs/269330102 Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Reg UBoot ITB Image Support for Sunxi Cortex A53 Family SOCS
On 28/08/17 17:21, Chakra D wrote: Hi, > I'm trying to build ITB image for sunxi banana Pi M64 image in > Buildroot. I'm facing issues with ITB format Uboot build. > > As per the readme file "board/sunxi/README.sunxi64", we need to build > the bl31.bin image before uboot and pass the path of image as BL31 > variable to UBOOT. > > Is there any procedure or some kind of script that can be used to > combine uboot.bin and bl31.bin images and generate uboot.itb image ? Well, the U-Boot build system of course does this, it's just a bit hidden. An .itb file is essentially using a a .dtb (device tree blob). You can use the "dtc" tool (device-tree-compiler) to assemble and disassemble it. If you delete u-boot.itb after a successful build, then do "make V=1" afterwards you should be able to spot the commands: $ ./board/sunxi/mksunxi_fit_atf.sh \ arch/arm/dts/sun50i-a64-pine64.dtb \ arch/arm/dts/sun50i-a64-pine64-plus.dtb > u-boot.its $ ./tools/mkimage -f u-boot.its -E u-boot.itb The first command generates the source file which describes the various files to be combined (u-boot.bin, ATF and the device trees), the second command generates the final binary from this source file and the files referenced in it. If you are in dire need, you could hook in there and use that source file together with u-boot.bin, bl31.bin and the .dtb's to recompile the .itb at any time. Whether combining firmware and rootfs in such a way is the right way to go forward in the long run is another question, though. Ideally the firmware sits somewhere else - some newer boards have SPI flash or eMMC. Cheers, Andre > > Can we build uboot independently and post build combine with bl31.bin to > generate uboot.itb ? > > Regards. > Chakra > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] splash_source: Verify FIT magic
On Thu, 3 Aug 2017 09:53:24 +0300 Tomas Melin tomas.me...@vaisala.com wrote: > From: Niko Mauno > > Before reading entire FIT image, add sanity check by testing image > header against FDT_MAGIC. This should help avoid problems in situations > where FIT is not yet available from storage device, for example when > performing initial programming of device. > > Cc: Anatolij Gustschin > Acked-by: Tomas Melin > --- > common/splash_source.c | 5 + > 1 file changed, 5 insertions(+) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] video: simplefb
On Thu, 3 Aug 2017 12:47:00 -0400 Rob Clark robdcl...@gmail.com wrote: > Not really qcom specific, but for now qcom/lk is the one firmware that > is (afaiu) setting up the appropriate dt node for pre-configured > display. Uses the generic simple-framebuffer DT bindings so this should > be useful on other platforms. > > Signed-off-by: Rob Clark > --- > drivers/video/Kconfig| 10 +++ > drivers/video/Makefile | 2 +- > drivers/video/simplefb.c | 71 > > 3 files changed, 82 insertions(+), 1 deletion(-) > create mode 100644 drivers/video/simplefb.c Applied to u-boot-video/next, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] video: add config option to skip framebuffer clear
On Thu, 3 Aug 2017 12:47:01 -0400 Rob Clark robdcl...@gmail.com wrote: > The use-case is that the thing that loaded u-boot already put a splash > image on screen. And we want to preserve that until grub boot menu > takes over. > > Signed-off-by: Rob Clark > --- > drivers/video/Kconfig| 8 > drivers/video/cfb_console.c | 3 ++- > drivers/video/video-uclass.c | 4 +++- > 3 files changed, 13 insertions(+), 2 deletions(-) Applied to u-boot-video/next, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd/spl.c: Include for fdt_totalsize
On Sat, Aug 26, 2017 at 8:18 PM, Tom Rini wrote:
> In order to be able to reliably use fdt_totalsize, we must have
> included.
>
> Fixes: 767cb74a0028 ("cmd: spl: provide address and size of prepared FDT ...")
> Signed-off-by: Tom Rini
Reviewed-by: Joe Hershberger
Tested-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/3] video: add STM32 LTDC display controller
Hi Philippe, On Thu, 3 Aug 2017 12:36:05 +0200 Philippe CORNU philippe.co...@st.com wrote: > Version 1: > - Initial commit > > The purpose of this set of patches is to add the STM32 LTDC display > controller support. > In preamble, a configuration switch is added for pwm-based backlights > and a new gpio-based backlight driver is proposed. > > Patrick Delaunay (2): > dm: backlight: Add CONFIG_BACKLIGHT_PWM > dm: backlight: Add a driver for GPIO backlight > > Philippe CORNU (1): > video: add STM32 LTDC display controller > > drivers/video/Kconfig| 23 +++ > drivers/video/Makefile | 6 +- > drivers/video/backlight_gpio.c | 74 +++ > drivers/video/stm32/Kconfig | 44 + > drivers/video/stm32/Makefile | 10 + > drivers/video/stm32/stm32_ltdc.c | 406 > +++ > 6 files changed, 560 insertions(+), 3 deletions(-) > create mode 100644 drivers/video/backlight_gpio.c > create mode 100644 drivers/video/stm32/Kconfig > create mode 100644 drivers/video/stm32/Makefile > create mode 100644 drivers/video/stm32/stm32_ltdc.c > Series applied to u-boot-video/next. Thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On 08/28/2017 10:32 PM, Marek Vasut wrote: On 08/28/2017 09:28 PM, Łukasz Majewski wrote: Dear Marek, Those patches are preferably for -next merge widow. The following changes since commit ae61b5353b48fa49c66376f273cc53cd3c06b656: usb: dwc3: fix Kconfig dependency to accept host driver in drivers/usb/dwc3 (2017-08-25 11:23:27 +0200) are available in the git repository at: u-boot-denx-dfu/master Might be a good idea to put it into -next branch then. +1. I will create -next branch :-) BR, Łukasz Applied for you to fetch changes up to 6496bc35d93975f01551dc3960b88807eae9d6fb: rockchip: rk3288: enable rockusb support on rk3288 based device (2017-08-28 21:20:50 +0200) Eddie Cai (4): usb: rockchip: add the rockusb gadget usb: rockchip: add rockusb command rockchip:usb: add a simple readme for rockusb rockchip: rk3288: enable rockusb support on rk3288 based device arch/arm/include/asm/arch-rockchip/f_rockusb.h | 132 arch/arm/mach-rockchip/Kconfig | 2 + cmd/Kconfig| 9 ++ cmd/Makefile | 1 + cmd/rockusb.c | 74 configs/chromebit_mickey_defconfig | 9 ++ configs/chromebook_jerry_defconfig | 9 ++ configs/chromebook_minnie_defconfig| 9 ++ configs/evb-rk3288_defconfig | 10 ++ configs/fennec-rk3288_defconfig| 6 + configs/firefly-rk3288_defconfig | 6 + configs/miqi-rk3288_defconfig | 6 + configs/phycore-rk3288_defconfig | 7 ++ configs/popmetal-rk3288_defconfig | 6 + configs/rock2_defconfig| 10 ++ configs/tinker-rk3288_defconfig| 6 + doc/README.rockusb | 51 drivers/usb/gadget/Kconfig | 8 ++ drivers/usb/gadget/Makefile| 1 + drivers/usb/gadget/f_rockusb.c | 691 + include/configs/rk3288_common.h| 7 -- 21 files changed, 1053 insertions(+), 7 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/f_rockusb.h create mode 100644 cmd/rockusb.c create mode 100644 doc/README.rockusb create mode 100644 drivers/usb/gadget/f_rockusb.c Travis-CI output (all clean): https://travis-ci.org/lmajewski/u-boot-dfu/builds/269119055 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269118570 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269118344 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269117873 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269099287 -- Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] lcd: avoid possible NULL dereference - Please update MAINTAINERS
Hello Heinrich, On Sun, 20 Aug 2017 10:32:03 +0200 Heinrich Schuchardt xypron.g...@gmx.de wrote: ... > To clarify the responsibilities could you, please, update your entry in > MAINTAINERS to include > > common/lcd*.c > include/lcd*.h I've sent a patch. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] lcd: avoid possible NULL dereference - Please update MAINTAINERS
Hello Heinrich, On Sun, 20 Aug 2017 10:32:03 +0200 Heinrich Schuchardt xypron.g...@gmx.de wrote: ... > To clarify the responsibilities could you, please, update your entry in > MAINTAINERS to include > > common/lcd*.c > include/lcd*.h I've send a patch. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: add lcd files to video section
LCD drivers are video related, so add them to video section. Signed-off-by: Anatolij Gustschin --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f7e6abd..04acf2b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -449,6 +449,8 @@ M: Anatolij Gustschin S: Maintained T: git git://git.denx.de/u-boot-video.git F: drivers/video/ +F: common/lcd*.c +F: include/lcd*.h X86 M: Simon Glass -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 8b3cec7da18645eda7f7cd0b65ee9f2dac573409: mtdparts: Fix uninitialized scalar usage (2017-08-26 16:59:24 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 6ea247d1376138026fcb4b9d869ed0956e7c0f59: usb: dwc3: fix Kconfig dependency to accept host driver in drivers/usb/dwc3 (2017-08-28 22:32:34 +0200) Masahiro Yamada (1): usb: dwc3: fix Kconfig dependency to accept host driver in drivers/usb/dwc3 drivers/usb/dwc3/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On 08/28/2017 09:28 PM, Łukasz Majewski wrote: > Dear Marek, > > Those patches are preferably for -next merge widow. > > > > The following changes since commit > ae61b5353b48fa49c66376f273cc53cd3c06b656: > > usb: dwc3: fix Kconfig dependency to accept host driver in > drivers/usb/dwc3 (2017-08-25 11:23:27 +0200) > > are available in the git repository at: > > u-boot-denx-dfu/master Might be a good idea to put it into -next branch then. Applied > for you to fetch changes up to 6496bc35d93975f01551dc3960b88807eae9d6fb: > > rockchip: rk3288: enable rockusb support on rk3288 based device > (2017-08-28 21:20:50 +0200) > > > Eddie Cai (4): > usb: rockchip: add the rockusb gadget > usb: rockchip: add rockusb command > rockchip:usb: add a simple readme for rockusb > rockchip: rk3288: enable rockusb support on rk3288 based device > > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 132 > arch/arm/mach-rockchip/Kconfig | 2 + > cmd/Kconfig| 9 ++ > cmd/Makefile | 1 + > cmd/rockusb.c | 74 > configs/chromebit_mickey_defconfig | 9 ++ > configs/chromebook_jerry_defconfig | 9 ++ > configs/chromebook_minnie_defconfig| 9 ++ > configs/evb-rk3288_defconfig | 10 ++ > configs/fennec-rk3288_defconfig| 6 + > configs/firefly-rk3288_defconfig | 6 + > configs/miqi-rk3288_defconfig | 6 + > configs/phycore-rk3288_defconfig | 7 ++ > configs/popmetal-rk3288_defconfig | 6 + > configs/rock2_defconfig| 10 ++ > configs/tinker-rk3288_defconfig| 6 + > doc/README.rockusb | 51 > drivers/usb/gadget/Kconfig | 8 ++ > drivers/usb/gadget/Makefile| 1 + > drivers/usb/gadget/f_rockusb.c | 691 > + > > include/configs/rk3288_common.h| 7 -- > 21 files changed, 1053 insertions(+), 7 deletions(-) > create mode 100644 arch/arm/include/asm/arch-rockchip/f_rockusb.h > create mode 100644 cmd/rockusb.c > create mode 100644 doc/README.rockusb > create mode 100644 drivers/usb/gadget/f_rockusb.c > > > Travis-CI output (all clean): > > https://travis-ci.org/lmajewski/u-boot-dfu/builds/269119055 > https://travis-ci.org/lmajewski/u-boot-dfu/builds/269118570 > https://travis-ci.org/lmajewski/u-boot-dfu/builds/269118344 > https://travis-ci.org/lmajewski/u-boot-dfu/builds/269117873 > https://travis-ci.org/lmajewski/u-boot-dfu/builds/269099287 > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx6: disable clock command and print_cpuinfo code in SPL
We do not use print_cpuinfo and clock command code in SPL,
disable it when building SPL image.
Signed-off-by: Anatolij Gustschin
---
arch/arm/mach-imx/cpu.c | 4 ++--
arch/arm/mach-imx/mx6/clock.c | 30 --
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index 1017eb8..18205dc 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -25,7 +25,7 @@
#include
#endif
-#if defined(CONFIG_DISPLAY_CPUINFO)
+#if defined(CONFIG_DISPLAY_CPUINFO) && !defined(CONFIG_SPL_BUILD)
static u32 reset_cause = -1;
static char *get_reset_cause(void)
@@ -132,7 +132,7 @@ unsigned imx_ddr_size(void)
}
#endif
-#if defined(CONFIG_DISPLAY_CPUINFO)
+#if defined(CONFIG_DISPLAY_CPUINFO) && !defined(CONFIG_SPL_BUILD)
const char *get_imx_type(u32 imxtype)
{
diff --git a/arch/arm/mach-imx/mx6/clock.c b/arch/arm/mach-imx/mx6/clock.c
index 0e019c4..71a9e6b 100644
--- a/arch/arm/mach-imx/mx6/clock.c
+++ b/arch/arm/mach-imx/mx6/clock.c
@@ -1220,6 +1220,20 @@ void enable_thermal_clk(void)
enable_pll3();
}
+#ifdef CONFIG_MTD_NOR_FLASH
+void enable_eim_clk(unsigned char enable)
+{
+ u32 reg;
+
+ reg = __raw_readl(&imx_ccm->CCGR6);
+ if (enable)
+ reg |= MXC_CCM_CCGR6_EMI_SLOW_MASK;
+ else
+ reg &= ~MXC_CCM_CCGR6_EMI_SLOW_MASK;
+ __raw_writel(reg, &imx_ccm->CCGR6);
+}
+#endif
+
unsigned int mxc_get_clock(enum mxc_clock clk)
{
switch (clk) {
@@ -1262,6 +1276,7 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
/*
* Dump some core clockes.
*/
@@ -1463,20 +1478,6 @@ void select_ldb_di_clock_source(enum ldb_di_clock clk)
}
#endif
-#ifdef CONFIG_MTD_NOR_FLASH
-void enable_eim_clk(unsigned char enable)
-{
- u32 reg;
-
- reg = __raw_readl(&imx_ccm->CCGR6);
- if (enable)
- reg |= MXC_CCM_CCGR6_EMI_SLOW_MASK;
- else
- reg &= ~MXC_CCM_CCGR6_EMI_SLOW_MASK;
- __raw_writel(reg, &imx_ccm->CCGR6);
-}
-#endif
-
/***/
U_BOOT_CMD(
@@ -1484,3 +1485,4 @@ U_BOOT_CMD(
"display clocks",
""
);
+#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu
Dear Marek, Those patches are preferably for -next merge widow. The following changes since commit ae61b5353b48fa49c66376f273cc53cd3c06b656: usb: dwc3: fix Kconfig dependency to accept host driver in drivers/usb/dwc3 (2017-08-25 11:23:27 +0200) are available in the git repository at: u-boot-denx-dfu/master for you to fetch changes up to 6496bc35d93975f01551dc3960b88807eae9d6fb: rockchip: rk3288: enable rockusb support on rk3288 based device (2017-08-28 21:20:50 +0200) Eddie Cai (4): usb: rockchip: add the rockusb gadget usb: rockchip: add rockusb command rockchip:usb: add a simple readme for rockusb rockchip: rk3288: enable rockusb support on rk3288 based device arch/arm/include/asm/arch-rockchip/f_rockusb.h | 132 arch/arm/mach-rockchip/Kconfig | 2 + cmd/Kconfig| 9 ++ cmd/Makefile | 1 + cmd/rockusb.c | 74 configs/chromebit_mickey_defconfig | 9 ++ configs/chromebook_jerry_defconfig | 9 ++ configs/chromebook_minnie_defconfig| 9 ++ configs/evb-rk3288_defconfig | 10 ++ configs/fennec-rk3288_defconfig| 6 + configs/firefly-rk3288_defconfig | 6 + configs/miqi-rk3288_defconfig | 6 + configs/phycore-rk3288_defconfig | 7 ++ configs/popmetal-rk3288_defconfig | 6 + configs/rock2_defconfig| 10 ++ configs/tinker-rk3288_defconfig| 6 + doc/README.rockusb | 51 drivers/usb/gadget/Kconfig | 8 ++ drivers/usb/gadget/Makefile| 1 + drivers/usb/gadget/f_rockusb.c | 691 + include/configs/rk3288_common.h| 7 -- 21 files changed, 1053 insertions(+), 7 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/f_rockusb.h create mode 100644 cmd/rockusb.c create mode 100644 doc/README.rockusb create mode 100644 drivers/usb/gadget/f_rockusb.c Travis-CI output (all clean): https://travis-ci.org/lmajewski/u-boot-dfu/builds/269119055 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269118570 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269118344 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269117873 https://travis-ci.org/lmajewski/u-boot-dfu/builds/269099287 -- Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx6: drop duplicated bss memset and board_init_r() call
Hi Anatolij,
bss section is cleared in crt0.S. board_init_r() is also
entered from crt0 code.
Reviewed-by: Lukasz Majewski
Signed-off-by: Anatolij Gustschin
Cc: Christian Gmeiner
Cc: Nikita Kiryanov
Cc: Jagan Teki
Cc: Tim Harvey
Cc: Marek Vasut
Cc: Lukasz Majewski
Cc: Fabio Estevam
---
board/bachmann/ot1200/ot1200_spl.c | 6 --
board/compulab/cm_fx6/spl.c | 3 ---
board/engicam/common/spl.c | 6 --
board/gateworks/gw_ventana/gw_ventana_spl.c | 3 ---
board/kosagi/novena/novena_spl.c| 6 --
board/liebherr/mccmon6/spl.c| 6 --
board/udoo/udoo_spl.c | 6 --
board/wandboard/spl.c | 6 --
8 files changed, 42 deletions(-)
diff --git a/board/bachmann/ot1200/ot1200_spl.c
b/board/bachmann/ot1200/ot1200_spl.c
index 9d28da4..f3dff95 100644
--- a/board/bachmann/ot1200/ot1200_spl.c
+++ b/board/bachmann/ot1200/ot1200_spl.c
@@ -151,10 +151,4 @@ void board_init_f(ulong dummy)
/* configure MMDC for SDRAM width/size and per-model calibration */
ot1200_spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
diff --git a/board/compulab/cm_fx6/spl.c b/board/compulab/cm_fx6/spl.c
index bba977f..56aac60 100644
--- a/board/compulab/cm_fx6/spl.c
+++ b/board/compulab/cm_fx6/spl.c
@@ -336,9 +336,6 @@ void board_init_f(ulong dummy)
puts("!!!ERROR!!! DRAM detection failed!!!\n");
hang();
}
-
- memset(__bss_start, 0, __bss_end - __bss_start);
- board_init_r(NULL, 0);
}
void board_boot_order(u32 *spl_boot_list)
diff --git a/board/engicam/common/spl.c b/board/engicam/common/spl.c
index a8a7cf3..1f2826a 100644
--- a/board/engicam/common/spl.c
+++ b/board/engicam/common/spl.c
@@ -384,10 +384,4 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
diff --git a/board/gateworks/gw_ventana/gw_ventana_spl.c
b/board/gateworks/gw_ventana/gw_ventana_spl.c
index 9524da7..e107f15 100644
--- a/board/gateworks/gw_ventana/gw_ventana_spl.c
+++ b/board/gateworks/gw_ventana/gw_ventana_spl.c
@@ -637,9 +637,6 @@ void board_init_f(ulong dummy)
spl_dram_init(8 << ventana_info.sdram_width,
16 << ventana_info.sdram_size,
board_model);
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
}
void board_boot_order(u32 *spl_boot_list)
diff --git a/board/kosagi/novena/novena_spl.c b/board/kosagi/novena/novena_spl.c
index 3645b75..ffc99b8 100644
--- a/board/kosagi/novena/novena_spl.c
+++ b/board/kosagi/novena/novena_spl.c
@@ -607,10 +607,4 @@ void board_init_f(ulong dummy)
udelay(100);
mmdc_do_write_level_calibration(&novena_ddr_info);
mmdc_do_dqs_calibration(&novena_ddr_info);
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
diff --git a/board/liebherr/mccmon6/spl.c b/board/liebherr/mccmon6/spl.c
index 15844ef..56e7d3b 100644
--- a/board/liebherr/mccmon6/spl.c
+++ b/board/liebherr/mccmon6/spl.c
@@ -307,11 +307,5 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
#endif
diff --git a/board/udoo/udoo_spl.c b/board/udoo/udoo_spl.c
index e83e7c3..34ef413 100644
--- a/board/udoo/udoo_spl.c
+++ b/board/udoo/udoo_spl.c
@@ -263,11 +263,5 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
#endif
diff --git a/board/wandboard/spl.c b/board/wandboard/spl.c
index 47082a8..c3f5fff 100644
--- a/board/wandboard/spl.c
+++ b/board/wandboard/spl.c
@@ -311,11 +311,5 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
#endif
--
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http
[U-Boot] [PATCH] imx6: drop duplicated bss memset and board_init_r() call
bss section is cleared in crt0.S. board_init_r() is also
entered from crt0 code.
Signed-off-by: Anatolij Gustschin
Cc: Christian Gmeiner
Cc: Nikita Kiryanov
Cc: Jagan Teki
Cc: Tim Harvey
Cc: Marek Vasut
Cc: Lukasz Majewski
Cc: Fabio Estevam
---
board/bachmann/ot1200/ot1200_spl.c | 6 --
board/compulab/cm_fx6/spl.c | 3 ---
board/engicam/common/spl.c | 6 --
board/gateworks/gw_ventana/gw_ventana_spl.c | 3 ---
board/kosagi/novena/novena_spl.c| 6 --
board/liebherr/mccmon6/spl.c| 6 --
board/udoo/udoo_spl.c | 6 --
board/wandboard/spl.c | 6 --
8 files changed, 42 deletions(-)
diff --git a/board/bachmann/ot1200/ot1200_spl.c
b/board/bachmann/ot1200/ot1200_spl.c
index 9d28da4..f3dff95 100644
--- a/board/bachmann/ot1200/ot1200_spl.c
+++ b/board/bachmann/ot1200/ot1200_spl.c
@@ -151,10 +151,4 @@ void board_init_f(ulong dummy)
/* configure MMDC for SDRAM width/size and per-model calibration */
ot1200_spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
diff --git a/board/compulab/cm_fx6/spl.c b/board/compulab/cm_fx6/spl.c
index bba977f..56aac60 100644
--- a/board/compulab/cm_fx6/spl.c
+++ b/board/compulab/cm_fx6/spl.c
@@ -336,9 +336,6 @@ void board_init_f(ulong dummy)
puts("!!!ERROR!!! DRAM detection failed!!!\n");
hang();
}
-
- memset(__bss_start, 0, __bss_end - __bss_start);
- board_init_r(NULL, 0);
}
void board_boot_order(u32 *spl_boot_list)
diff --git a/board/engicam/common/spl.c b/board/engicam/common/spl.c
index a8a7cf3..1f2826a 100644
--- a/board/engicam/common/spl.c
+++ b/board/engicam/common/spl.c
@@ -384,10 +384,4 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
diff --git a/board/gateworks/gw_ventana/gw_ventana_spl.c
b/board/gateworks/gw_ventana/gw_ventana_spl.c
index 9524da7..e107f15 100644
--- a/board/gateworks/gw_ventana/gw_ventana_spl.c
+++ b/board/gateworks/gw_ventana/gw_ventana_spl.c
@@ -637,9 +637,6 @@ void board_init_f(ulong dummy)
spl_dram_init(8 << ventana_info.sdram_width,
16 << ventana_info.sdram_size,
board_model);
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
}
void board_boot_order(u32 *spl_boot_list)
diff --git a/board/kosagi/novena/novena_spl.c b/board/kosagi/novena/novena_spl.c
index 3645b75..ffc99b8 100644
--- a/board/kosagi/novena/novena_spl.c
+++ b/board/kosagi/novena/novena_spl.c
@@ -607,10 +607,4 @@ void board_init_f(ulong dummy)
udelay(100);
mmdc_do_write_level_calibration(&novena_ddr_info);
mmdc_do_dqs_calibration(&novena_ddr_info);
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
diff --git a/board/liebherr/mccmon6/spl.c b/board/liebherr/mccmon6/spl.c
index 15844ef..56e7d3b 100644
--- a/board/liebherr/mccmon6/spl.c
+++ b/board/liebherr/mccmon6/spl.c
@@ -307,11 +307,5 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
#endif
diff --git a/board/udoo/udoo_spl.c b/board/udoo/udoo_spl.c
index e83e7c3..34ef413 100644
--- a/board/udoo/udoo_spl.c
+++ b/board/udoo/udoo_spl.c
@@ -263,11 +263,5 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
#endif
diff --git a/board/wandboard/spl.c b/board/wandboard/spl.c
index 47082a8..c3f5fff 100644
--- a/board/wandboard/spl.c
+++ b/board/wandboard/spl.c
@@ -311,11 +311,5 @@ void board_init_f(ulong dummy)
/* DDR initialization */
spl_dram_init();
-
- /* Clear the BSS. */
- memset(__bss_start, 0, __bss_end - __bss_start);
-
- /* load/boot image from boot device */
- board_init_r(NULL, 0);
}
#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT] [PATCH] cmd: usb: ignore block devices under mass storage device
Hi,
Request for review on comments below.
Regards,
Suneel
On Mon, Aug 14, 2017 at 8:06 PM, Suneel Garapati wrote:
> Hi Simon,
>
>
> On Sun, Aug 13, 2017 at 2:37 PM, Simon Glass wrote:
>> Hi Suneel,
>>
>> On 10 August 2017 at 23:53, Suneel Garapati wrote:
>>> usb tree and info commands may cause crash otherwise
>>>
>>> Signed-off-by: Suneel Garapati
>>> ---
>>> cmd/usb.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>
>> Thank you for the patch - it certainly looks like a bug. Can you
>> please expand the commit message a little? E.g. you have
>> UCLASS_USB_EMUL below.
>
> I will change the description
>
>>
>>> diff --git a/cmd/usb.c b/cmd/usb.c
>>> index 992d414..81e1a7b 100644
>>> --- a/cmd/usb.c
>>> +++ b/cmd/usb.c
>>> @@ -415,7 +415,8 @@ static void usb_show_tree_graph(struct usb_device *dev,
>>> char *pre)
>>> udev = dev_get_parent_priv(child);
>>>
>>> /* Ignore emulators, we only want real devices */
>>> - if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
>>> + if (device_get_uclass_id(child) !=
>>> + (UCLASS_USB_EMUL | UCLASS_BLK)) {
>>
>> This seems odd to me. Do you mean to check that the child uclass is
>> neither USB_EMUL nor BLK?
>>
>> Would it be possible to check that the parent is UCLASS_USB? That
>> seems like a better condition to determine whether the child has USB
>> parent data.
>
> It is possible to check parent uclass but would that ever fail?
> I assume, block device under usb storage device will always have
> parent as usb class.
> Also, tree is called on only usb class devices. Maybe I am missing something.
>
> Regards,
> Suneel
>
>>
>>> usb_show_tree_graph(udev, pre);
>>> pre[index] = 0;
>>> }
>>> @@ -605,7 +606,8 @@ static void usb_show_info(struct usb_device *udev)
>>> for (device_find_first_child(udev->dev, &child);
>>> child;
>>> device_find_next_child(&child)) {
>>> - if (device_active(child)) {
>>> + if (device_active(child) &&
>>> + (device_get_uclass_id(child) != UCLASS_BLK)) {
>>> udev = dev_get_parent_priv(child);
>>> usb_show_info(udev);
>>> }
>>> --
>>> 2.7.4
>>>
>>
>> Regards,
>> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] patman: add support for omitting bouncing addresses
On Mon, 28 Aug 2017, Chris Packham wrote:
Add a --bounce-file option which can be used to omit addresses that are
known to bounce. The option specifies a file which lists addresses (one
per line) that are stripped from the Cc list.
Reviewed-by: Philipp Tomsich
Absolutely love this (in fact, I had something like this on my to-do list
as the number of bounces seemed to grow over time).
A few comments below.
Signed-off-by: Chris Packham
---
Here's a quick proof of concept. Right now the .bounces file has to
match exactly the addresses that are extracted by patman. This makes it
easy to do set(a) - set(b) to remove all the bounces in one hit.
tools/patman/patman.py | 6 +-
tools/patman/series.py | 5 -
tools/patman/tools.py | 8
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index 4b3bc787453e..567226a4d3ce 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -56,6 +56,9 @@ parser.add_option('-v', '--verbose', action='store_true',
dest='verbose',
default=False, help='Verbose output of errors and warnings')
parser.add_option('--cc-cmd', dest='cc_cmd', type='string', action='store',
default=None, help='Output cc list for patch file (used by git)')
+parser.add_option('--bounce-file', dest='bounce_fname', type='string',
+ default='.bounces',
The '.bounces' default doesn't really fit with how such settings are
handled throughout patman.
My gut feeling is that
(a) we want to have a project-wide bounces config (doc/git-bounces ???)
that complements doc/git-mailrc
(b) that any overrides/user-local additional settings should be picked up
via ~/.patman (either by referencing a local overrides file or by
having some additional overrides directly there)
(c) this entire mechanism needs to be tied into Setup(...) in settings.py
+ help='File containing addresses to skip [default: %default]')
parser.add_option('--no-check', action='store_false', dest='check_patch',
default=True,
help="Don't check for patch compliance")
@@ -158,7 +161,8 @@ else:
cc_file = series.MakeCcFile(options.process_tags, cover_fname,
not options.ignore_bad_tags,
-options.add_maintainers)
+options.add_maintainers,
+options.bounce_fname)
# Email the patches out (giving the user time to check / cancel)
cmd = ''
diff --git a/tools/patman/series.py b/tools/patman/series.py
index d3947a7c2ac5..b6533ab5ee58 100644
--- a/tools/patman/series.py
+++ b/tools/patman/series.py
@@ -11,6 +11,7 @@ import os
import get_maintainer
import gitutil
import terminal
+from tools import FindBounces
# Series-xxx tags that we understand
valid_series = ['to', 'cc', 'version', 'changes', 'prefix', 'notes', 'name',
@@ -202,7 +203,7 @@ class Series(dict):
print(col.Color(col.RED, str))
def MakeCcFile(self, process_tags, cover_fname, raise_on_error,
- add_maintainers):
+ add_maintainers, bounce_fname):
"""Make a cc file for us to use for per-commit Cc automation
Also stores in self._generated_cc to make ShowActions() faster.
@@ -222,6 +223,7 @@ class Series(dict):
fname = '/tmp/patman.%d' % os.getpid()
fd = open(fname, 'w')
all_ccs = []
+bounces = FindBounces(bounce_fname)
for commit in self.commits:
cc = []
if process_tags:
@@ -234,6 +236,7 @@ class Series(dict):
elif add_maintainers:
cc += get_maintainer.GetMaintainer(commit.patch)
cc = [m.encode('utf-8') if type(m) != str else m for m in cc]
+cc = set(cc) - set(bounces)
all_ccs += cc
print(commit.patch, ', '.join(set(cc)), file=fd)
self._generated_cc[commit.patch] = cc
diff --git a/tools/patman/tools.py b/tools/patman/tools.py
index ba2485303037..9d206a390b02 100644
--- a/tools/patman/tools.py
+++ b/tools/patman/tools.py
@@ -118,3 +118,11 @@ def Align(pos, align):
def NotPowerOfTwo(num):
return num and (num & (num - 1))
+
+def FindBounces(bounce_fname):
+"""generate a list of bouncing addresses from a file"""
+try:
+with open(bounce_fname) as fd:
+return [line.strip() for line in fd]
+except IOError:
+return []
Shouldn't this be merged into gitutil.BuildEmailList or into
gitutil.LookupEmail? It would also be nice if the bounces would be
handled in analogy to aliases and referenced via settings.alias
Regards,
Philipp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] video: ipuv3_fb: skip IPU shutdown if IPU was not enabled before
Hi Stefano, On Mon, 28 Aug 2017 18:54:39 +0200 Stefano Babic sba...@denx.de wrote: ... > > + /* > > +* Check if IPU clock was enabled before. Won't access > > +* IPU registers if clock is not enabled. > > +*/ > > + reg = readl(&mxc_ccm->CCGR3); > > + if ((reg & MXC_CCM_CCGR3_IPU1_IPU_MASK) == 0) > > + return; > > > > It looks to me quite weak to simply check if clock is gated. On some > board clock is gated even if IPU is not active. Do you have a way > reading inside IPU itself ? Then we can better decide if it was really > acrive. For example, checking if ipu_enable_channel() was called (and > DMA registers are set). we cannot access IPU registers when IPU clock is disabled (register access will hang the CPU). Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] video: ipuv3_fb: skip IPU shutdown if IPU was not enabled before
Hi Fabio, On Mon, 28 Aug 2017 13:22:19 -0300 Fabio Estevam feste...@gmail.com wrote: ... > > + /* > > +* Check if IPU clock was enabled before. Won't access > > +* IPU registers if clock is not enabled. > > +*/ > > + reg = readl(&mxc_ccm->CCGR3); > > + if ((reg & MXC_CCM_CCGR3_IPU1_IPU_MASK) == 0) > > + return; > > Maybe you could also check whether IPU2 has been enabled? currently IPU2 is not used, the driver never enables it. I checked it when preparing this patch. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: bpi-m3: Enable eMMC
On Mon, Aug 28, 2017 at 2:33 PM, Jagan Teki wrote: > From: Jagan Teki > > Add CONFIG_MMC_SUNXI_SLOT_EXTRA=2 to use eMMC on > BPI_M3 board. > > Cc: Chen-Yu Tsai > Cc: Maxime Ripard > Signed-off-by: Jagan Teki > Tested-by: Jagan Teki Since for eMMC fixes to test on A83T in Mainline, this patch need to enable eMMC on BPI-M3. So, Applied to u-boot-sunxi/master because thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: sunxi: fix legacy MMC initialisation
On Thu, Aug 24, 2017 at 12:20 PM, Jagan Teki wrote:
> On Thu, Aug 24, 2017 at 8:41 AM, Chen-Yu Tsai wrote:
>> On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard
>> wrote:
>>> The driver-model rework changed, among other things, the way the private
>>> data were moved around. It now uses the private field in the struct mmc.
>>>
>>> However, the mmc_create argument was changed in the process to always pass
>>> the array we used to have to store our private structures.
>>>
>>> The basically means that all the MMC driver instances will now have the
>>> private data of the first instance, which obviously doesn't work very well.
>>>
>>> Pass the proper pointer to mmc_create.
>>>
>>> Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly")
>>> Signed-off-by: Maxime Ripard
>>
>> Tested-by: Chen-Yu Tsai
>
> Tested-by: Jagan Teki
> Reviewed-by: Jagan Teki
Applied to u-boot-sunxi/master
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mmc: sunxi: Support new mode
On Sat, Aug 26, 2017 at 12:10 PM, Jagan Teki wrote: > On Wed, Aug 23, 2017 at 3:33 PM, Maxime Ripard > wrote: >> Almost all of the newer Allwinner SoCs have a new operating mode for the >> eMMC clocks that needs to be enabled in both the clock and the MMC >> controller. >> >> Details about that mode are sparse, and the name itself (new mode vs old >> mode) doesn't give much details, but it seems that the it changes the >> sampling of the MMC clock. One side effect is also that it divides the >> parent clock rate by 2. >> >> Add support for it through a Kconfig option. >> >> Signed-off-by: Maxime Ripard > > Reviewed-by: Jagan Teki Applied to u-boot-sunxi/master thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Enable MMC new mode for A83T
On Wed, Aug 23, 2017 at 3:33 PM, Maxime Ripard wrote: > The eMMC controller for the A83T uses the new operating mode. Enable it. > > Signed-off-by: Maxime Ripard > --- Applied to u-boot-sunxi/master thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
+Xiaowei On 08/28/2017 10:09 AM, Joakim Tjernlund wrote: > On Mon, 2017-08-28 at 16:55 +, York Sun wrote: >> On 08/28/2017 09:48 AM, Joakim Tjernlund wrote: >>> FSL PCIe controller drivers before REV 3 has this test for link up: >>> enabled = ltssm >= PCI_LTSSM_L0; >>> >>> We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non >>> ready >>> for PCI transaktions. When FSL PCIe controller tries to access this device, >>> it >>> hangs forever. >>> >>> Is LTSSM=0x51 really a "legal" state for link up? >>> If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ? >>> >>>Jocke >>> >>> BTW, the same test is valid in Linux too. >>> >> >> Jocke, >> >> I am not an expert on PCIe. Please if this thread is helpful, > Me neither .. :) >> >> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F&data=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D&reserved=0. > > It mentions polling compliance but this driver already tests for: > if (ltssm < LTSSM_PCIE_L0) > return 0; > return 1; > > It just adds some delay if the device is in Polling Compliance to see if that > changes to L0. > Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I > suspect > the ltssm >= L0 is bogus. > Xiaowei, can you comment? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] ACPI tables for Edison: advice needed
Hi! I have a preliminary working ACPI tables for Intel Edison (to replace ugly SFI provided by firmware). What I would like to ask is how better from your point of view to proceed. I have apparently not all devices covered in the tables, though I have almost stable code which brings ACPI support to Edison. I see few options here: 0. Do nothing :-) 1. Apply ACPI code, but leave no tables applied yet. 2. Apply both and amend whenever problem occurs. 3. Postpone until kernel will be ready for that (*) 4. ...other option...? *) LInux kernel (vanilla) is not ready for this change. It means in all above cases there will be neither new config file (like edison_acpi_defconfig) nor modification to the existing one (of course!). The stuff is highly experimental now. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On Mon, 2017-08-28 at 16:55 +, York Sun wrote: > On 08/28/2017 09:48 AM, Joakim Tjernlund wrote: > > FSL PCIe controller drivers before REV 3 has this test for link up: > >enabled = ltssm >= PCI_LTSSM_L0; > > > > We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non > > ready > > for PCI transaktions. When FSL PCIe controller tries to access this device, > > it > > hangs forever. > > > > Is LTSSM=0x51 really a "legal" state for link up? > > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ? > > > > Jocke > > > > BTW, the same test is valid in Linux too. > > > > Jocke, > > I am not an expert on PCIe. Please if this thread is helpful, Me neither .. :) > > http://patchwork.ozlabs.org/patch/801519/. It mentions polling compliance but this driver already tests for: if (ltssm < LTSSM_PCIE_L0) return 0; return 1; It just adds some delay if the device is in Polling Compliance to see if that changes to L0. Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I suspect the ltssm >= L0 is bogus. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] rk3288: spl: Add dram_init_banksize
From: Jagan Teki
Falcon mode, is updating DDR dt node configuration through
spl_fixup_fdt() so add appropriate DDR base and size through
dram_init_banksize.
Signed-off-by: Jagan Teki
---
arch/arm/mach-rockchip/rk3288-board-spl.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index febc1ef..9eee9c5 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -19,7 +19,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -329,3 +331,18 @@ err:
/* No way to report error here */
hang();
}
+
+#ifdef CONFIG_SPL_OS_BOOT
+
+#define PMU_BASE 0xff73
+int dram_init_banksize(void)
+{
+ struct rk3288_pmu *const pmu = (void *)PMU_BASE;
+ size_t size = rockchip_sdram_size((phys_addr_t)&pmu->sys_reg[2]);
+
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = size;
+
+ return 0;
+}
+#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] rk3288: vyasa: Add TPL support
From: Jagan Teki
Since the size of SPL can't be exceeded 0x8000 bytes in RK3288,
it is not possible add new SPL features like Falcon mode or etc.
So add TPL stage so-that adding new features to SPL is possible.
- TPL: DRAM init, clocks
- SPL: MMC, falcon, etc
Booting from SD with TPL:
U-Boot TPL 2017.09-rc2-13369-gfa72baf-dirty (Aug 26 2017 - 15:48:54)
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2017.09-rc2-13369-gfa72baf-dirty (Aug 26 2017 - 15:48:54)
Trying to boot from MMC1
U-Boot 2017.09-rc2-13369-gfa72baf-dirty (Aug 26 2017 - 15:48:54 +0530)
Model: Amarula Vyasa-RK3288
DRAM: 2 GiB
MMC: dwmmc@ff0c: 1
Using default environment
In:serial@ff69
Out: serial@ff69
Err: serial@ff69
Model: Amarula Vyasa-RK3288
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
=>
Signed-off-by: Jagan Teki
---
Note:
Right now TPL added in vyasa board, ie reason some clock code
is duplicate in SPL and TPL. Once all rk3288 agree the will remove
duplicates.
arch/arm/mach-rockchip/Makefile | 1 +
arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +
arch/arm/mach-rockchip/rk3288-board-tpl.c | 124 ++
arch/arm/mach-rockchip/rk3288/Kconfig | 15
configs/vyasa-rk3288_defconfig| 2 +
doc/README.rockchip | 18 +
include/configs/rk3288_common.h | 8 +-
7 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-rockchip/rk3288-board-tpl.c
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 79e9704..daafc8d 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -12,6 +12,7 @@ obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
save_boot_param.o
obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o save_boot_param.o
obj-tpl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-tpl.o
+obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o
obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 6b7bf85..febc1ef 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -243,12 +243,15 @@ void board_init_f(ulong dummy)
}
#endif
+#if !defined(CONFIG_SUPPORT_TPL)
debug("\nspl:init dram\n");
ret = uclass_get_device(UCLASS_RAM, 0, &dev);
if (ret) {
debug("DRAM init failed: %d\n", ret);
return;
}
+#endif
+
#if CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM) && !defined(CONFIG_SPL_BOARD_INIT)
back_to_bootrom();
#endif
diff --git a/arch/arm/mach-rockchip/rk3288-board-tpl.c
b/arch/arm/mach-rockchip/rk3288-board-tpl.c
new file mode 100644
index 000..7a7fd05
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3288-board-tpl.c
@@ -0,0 +1,124 @@
+/*
+ * (C) Copyright 2015 Google, Inc
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* read L2 control register (L2CTLR) */
+static inline uint32_t read_l2ctlr(void)
+{
+ uint32_t val = 0;
+
+ asm volatile ("mrc p15, 1, %0, c9, c0, 2" : "=r" (val));
+
+ return val;
+}
+
+/* write L2 control register (L2CTLR) */
+static inline void write_l2ctlr(uint32_t val)
+{
+ /*
+* Note: L2CTLR can only be written when the L2 memory system
+* is idle, ie before the MMU is enabled.
+*/
+ asm volatile("mcr p15, 1, %0, c9, c0, 2" : : "r" (val) : "memory");
+ isb();
+}
+
+static void configure_l2ctlr(void)
+{
+ uint32_t l2ctlr;
+
+ l2ctlr = read_l2ctlr();
+ l2ctlr &= 0xfffc; /* clear bit0~bit17 */
+
+ /*
+ * Data RAM write latency: 2 cycles
+ * Data RAM read latency: 2 cycles
+ * Data RAM setup latency: 1 cycle
+ * Tag RAM write latency: 1 cycle
+ * Tag RAM read latency: 1 cycle
+ * Tag RAM setup latency: 1 cycle
+ */
+ l2ctlr |= (1 << 3 | 1 << 0);
+ write_l2ctlr(l2ctlr);
+}
+
+
+void board_init_f(ulong dummy)
+{
+ struct udevice *dev;
+ int ret;
+
+ /* Example code showing how to enable the debug UART on RK3288 */
+#include
+ /* Enable early UART on the RK3288 */
+#define GRF_BASE 0xff77
+ struct rk3288_grf * const grf = (void *)GRF_BASE;
+
+ rk_clrsetreg(&grf->gpio7ch_iomux, GPIO7C7_MASK << GPIO7C7_SHIFT |
+GPIO7C6_MASK << GPIO7C6_SHIFT,
+GPIO7C7_UART2DBG_SOUT << GPIO7C7_SHIFT |
+GPIO7C6_UART2DBG_SIN << GPIO7C6_SHIFT);
+ /*
+* Debug UART can be used from here if required:
+*
+* debug_uart_init();
+* pri
[U-Boot] [PATCH 2/3] rk3288: vyasa: Add falcon mode support
From: Jagan Teki
Add Falcon mode support in vyasa rk3288 board.
Signed-off-by: Jagan Teki
---
board/amarula/vyasa-rk3288/vyasa-rk3288.c | 13 +
include/configs/vyasa-rk3288.h| 17 +
2 files changed, 30 insertions(+)
diff --git a/board/amarula/vyasa-rk3288/vyasa-rk3288.c
b/board/amarula/vyasa-rk3288/vyasa-rk3288.c
index ceee42c..7985671 100644
--- a/board/amarula/vyasa-rk3288/vyasa-rk3288.c
+++ b/board/amarula/vyasa-rk3288/vyasa-rk3288.c
@@ -5,3 +5,16 @@
*/
#include
+
+#ifndef CONFIG_TPL_BUILD
+#include
+
+int spl_start_uboot(void)
+{
+/* break into full u-boot on 'c' */
+if (serial_tstc() && serial_getc() == 'c')
+return 1;
+
+return 0;
+}
+#endif
diff --git a/include/configs/vyasa-rk3288.h b/include/configs/vyasa-rk3288.h
index 93ab7e7..4c250e8 100644
--- a/include/configs/vyasa-rk3288.h
+++ b/include/configs/vyasa-rk3288.h
@@ -20,4 +20,21 @@
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 1
+#ifndef CONFIG_TPL_BUILD
+
+#define CONFIG_SPL_OS_BOOT
+
+/* Falcon Mode */
+#define CONFIG_SPL_FS_LOAD_ARGS_NAME "args"
+#define CONFIG_SPL_FS_LOAD_KERNEL_NAME "uImage"
+#define CONFIG_CMD_SPL
+#define CONFIG_SYS_SPL_ARGS_ADDR 0x0ffe5000
+#define CONFIG_CMD_SPL_WRITE_SIZE (128 * SZ_1K)
+
+/* Falcon Mode - MMC support: args@1MB kernel@2MB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR 0x800 /* 1MB */
+#define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS (CONFIG_CMD_SPL_WRITE_SIZE /
512)
+#define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR0x1000 /* 2MB */
+#endif
+
#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] rk3288: Falcon mode support
From: Jagan Teki This series add falcon mode support on vyasa rk3288. Jagan Teki (3): rk3288: vyasa: Add TPL support rk3288: vyasa: Add falcon mode support rk3288: spl: Add dram_init_banksize arch/arm/mach-rockchip/Makefile | 1 + arch/arm/mach-rockchip/rk3288-board-spl.c | 20 + arch/arm/mach-rockchip/rk3288-board-tpl.c | 124 ++ arch/arm/mach-rockchip/rk3288/Kconfig | 15 board/amarula/vyasa-rk3288/vyasa-rk3288.c | 13 configs/vyasa-rk3288_defconfig| 2 + doc/README.rockchip | 18 + include/configs/rk3288_common.h | 8 +- include/configs/vyasa-rk3288.h| 17 9 files changed, 217 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-rockchip/rk3288-board-tpl.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] rk3288: Add Vyasa initial board support
From: Jagan Teki
This patch adds support for Vyasa RK3288 initial board
from Amarula.
Boot from SDMMC:
---
U-Boot SPL 2017.09-rc1-00111-g3656991-dirty (Aug 10 2017 - 11:40:45)
Trying to boot from MMC1
U-Boot 2017.09-rc1-00111-g3656991-dirty (Aug 10 2017 - 11:40:45 +0530)
Model: Amarula Vyasa-RK3288
DRAM: 2 GiB
MMC: dwmmc@ff0c: 1
*** Warning - bad CRC, using default environment
In:serial@ff69
Out: serial@ff69
Err: serial@ff69
Model: Amarula Vyasa-RK3288
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
=>
Reviewed-by: Simon Glass
Signed-off-by: Jagan Teki
---
Changes for v2:
- Fix commit message
- Move CONFIG_ENV_IS_IN_MMC to configs
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-vyasa.dts | 327 ++
arch/arm/mach-rockchip/rk3288/Kconfig | 11 +
board/amarula/vyasa-rk3288/Kconfig| 12 ++
board/amarula/vyasa-rk3288/MAINTAINERS| 6 +
board/amarula/vyasa-rk3288/Makefile | 7 +
board/amarula/vyasa-rk3288/vyasa-rk3288.c | 7 +
configs/vyasa-rk3288_defconfig| 63 ++
include/configs/vyasa-rk3288.h| 23 +++
9 files changed, 457 insertions(+)
create mode 100644 arch/arm/dts/rk3288-vyasa.dts
create mode 100644 board/amarula/vyasa-rk3288/Kconfig
create mode 100644 board/amarula/vyasa-rk3288/MAINTAINERS
create mode 100644 board/amarula/vyasa-rk3288/Makefile
create mode 100644 board/amarula/vyasa-rk3288/vyasa-rk3288.c
create mode 100644 configs/vyasa-rk3288_defconfig
create mode 100644 include/configs/vyasa-rk3288.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d07715f..371511b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
+ rk3288-vyasa.dtb \
rk3328-evb.dtb \
rk3368-lion.dtb \
rk3368-sheep.dtb \
diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
new file mode 100644
index 000..93a9c5e
--- /dev/null
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) 2017 Jagan Teki
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3288.dtsi"
+
+/ {
+ model = "Amarula Vyasa-RK3288";
+ compatible = "amarula,vyasa-rk3288", "rockchip,rk3288";
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000>;
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwr>;
+ regulator-name = "vcc_sd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ startup-delay-us = <10>;
+
[U-Boot] [PATCH] rk3288: Add Vyasa initial board support
From: Jagan Teki
This patch adds support for Vyasa RK3288 initial board
from Amarula.
Boot from SDMMC:
---
U-Boot SPL 2017.09-rc1-00111-g3656991-dirty (Aug 10 2017 - 11:40:45)
Trying to boot from MMC1
U-Boot 2017.09-rc1-00111-g3656991-dirty (Aug 10 2017 - 11:40:45 +0530)
Model: Amarula Vyasa-RK3288
DRAM: 2 GiB
MMC: dwmmc@ff0c: 1
*** Warning - bad CRC, using default environment
In:serial@ff69
Out: serial@ff69
Err: serial@ff69
Model: Amarula Vyasa-RK3288
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
=>
Reviewed-by: Simon Glass
Signed-off-by: Jagan Teki
---
Changes for v2:
- Fix commit message
- Move CONFIG_ENV_IS_IN_MMC to configs
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-vyasa.dts | 327 ++
arch/arm/mach-rockchip/rk3288/Kconfig | 11 +
board/amarula/vyasa-rk3288/Kconfig| 12 ++
board/amarula/vyasa-rk3288/MAINTAINERS| 6 +
board/amarula/vyasa-rk3288/Makefile | 7 +
board/amarula/vyasa-rk3288/vyasa-rk3288.c | 7 +
configs/vyasa-rk3288_defconfig| 63 ++
include/configs/vyasa-rk3288.h| 23 +++
9 files changed, 457 insertions(+)
create mode 100644 arch/arm/dts/rk3288-vyasa.dts
create mode 100644 board/amarula/vyasa-rk3288/Kconfig
create mode 100644 board/amarula/vyasa-rk3288/MAINTAINERS
create mode 100644 board/amarula/vyasa-rk3288/Makefile
create mode 100644 board/amarula/vyasa-rk3288/vyasa-rk3288.c
create mode 100644 configs/vyasa-rk3288_defconfig
create mode 100644 include/configs/vyasa-rk3288.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d07715f..371511b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
+ rk3288-vyasa.dtb \
rk3328-evb.dtb \
rk3368-lion.dtb \
rk3368-sheep.dtb \
diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
new file mode 100644
index 000..93a9c5e
--- /dev/null
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) 2017 Jagan Teki
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3288.dtsi"
+
+/ {
+ model = "Amarula Vyasa-RK3288";
+ compatible = "amarula,vyasa-rk3288", "rockchip,rk3288";
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000>;
+ };
+
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwr>;
+ regulator-name = "vcc_sd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ startup-delay-us = <10>;
+
Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
On 08/28/2017 09:48 AM, Joakim Tjernlund wrote: > FSL PCIe controller drivers before REV 3 has this test for link up: >enabled = ltssm >= PCI_LTSSM_L0; > > We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non > ready > for PCI transaktions. When FSL PCIe controller tries to access this device, it > hangs forever. > > Is LTSSM=0x51 really a "legal" state for link up? > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ? > > Jocke > > BTW, the same test is valid in Linux too. > Jocke, I am not an expert on PCIe. Please if this thread is helpful, http://patchwork.ozlabs.org/patch/801519/. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: bootefi hello should use loadaddr
Command 'bootefi hello' currently uses CONFIG_SYS_LOAD_ADDR
as loading address.
qemu machines have by default 128 MiB RAM.
CONFIG_SYS_LOAD_ADDR for x86 is 0x2000 (512 MiB).
This causes 'bootefi hello' to fail.
We should use the environment variable loadaddr if available.
It defaults to 0x100 (16 MiB) on qemu_x86.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 47771f87cc..a3768158a2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -300,7 +300,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
if (!strcmp(argv[1], "hello")) {
ulong size = __efi_hello_world_end - __efi_hello_world_begin;
- addr = CONFIG_SYS_LOAD_ADDR;
+ saddr = env_get("loadaddr");
+ if (saddr)
+ addr = simple_strtoul(saddr, NULL, 16);
+ else
+ addr = CONFIG_SYS_LOAD_ADDR;
memcpy((char *)addr, __efi_hello_world_begin, size);
} else
#endif
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] video: ipuv3_fb: skip IPU shutdown if IPU was not enabled before
Hi Anatolji,
On 25/08/2017 15:10, Anatolij Gustschin wrote:
> Boards can skip display interface init using board_video_skip().
> If display interface was not initialized (e.g. no ipuv3 framebuffer
> registered or IPU clock disabled), booting Linux stops due to the
> crash in IPU shutdown function, when accessing IPU registers.
> Check IPU clock and skip shutdown if clock is not enabled.
>
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/video/mxc_ipuv3_fb.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/mxc_ipuv3_fb.c b/drivers/video/mxc_ipuv3_fb.c
> index 0d0a0a9..8836229 100644
> --- a/drivers/video/mxc_ipuv3_fb.c
> +++ b/drivers/video/mxc_ipuv3_fb.c
> @@ -13,6 +13,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -568,8 +569,18 @@ err0:
>
> void ipuv3_fb_shutdown(void)
> {
> - int i;
> + struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> struct ipu_stat *stat = (struct ipu_stat *)IPU_STAT;
> + u32 reg;
> + int i;
> +
> + /*
> + * Check if IPU clock was enabled before. Won't access
> + * IPU registers if clock is not enabled.
> + */
> + reg = readl(&mxc_ccm->CCGR3);
> + if ((reg & MXC_CCM_CCGR3_IPU1_IPU_MASK) == 0)
> + return;
>
It looks to me quite weak to simply check if clock is gated. On some
board clock is gated even if IPU is not active. Do you have a way
reading inside IPU itself ? Then we can better decide if it was really
acrive. For example, checking if ipu_enable_channel() was called (and
DMA registers are set).
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
FSL PCIe controller drivers before REV 3 has this test for link up: enabled = ltssm >= PCI_LTSSM_L0; We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready for PCI transaktions. When FSL PCIe controller tries to access this device, it hangs forever. Is LTSSM=0x51 really a "legal" state for link up? If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ? Jocke BTW, the same test is valid in Linux too. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 5/5] boot: fdt: fixup the memory dt nodes falcon boot
On 08/26/2017 04:50 AM, Jagan Teki wrote: > On Thu, Aug 3, 2017 at 1:02 AM, Tom Rini wrote: >> On Wed, Aug 02, 2017 at 07:10:51PM +, York Sun wrote: >>> On 04/18/2017 04:57 AM, B, Ravi wrote: In single stage bootmode or falcon boot mode, the SPL shall update the memory dt nodes spl_fixup_fdt() based on DDR configuration for specific platform. Signed-off-by: Ravi Babu --- common/spl/spl.c | 40 1 file changed, 40 insertions(+) >>> >>> Clearly I am late for this thread. I only notice this change when I try >>> to merge my FIT improvement for falcon boot. >>> >>> Why do we need to fixup the device tree for falcon boot at all? The >>> device tree is static, saved as argument when exporting it, isn't it? As >>> far as the normal boot fixes up the device tree, the exported device >>> tree is correct. >> >> So, the further argument here is that if you have to edit the dts to >> include a valid amount of memory so that the dtb the kernel spits out is >> useful in falcon mode, it's not at all useful in development. > > Anyone noticed! this change is breaking falcon mode (tried in i.MX6 > and rk3288) even if we forcibly disable CONFIG_SPL_OF_LIBFDT the SPL > need to revert back to use SPL_OF_PLATDATA. > It broke falcon boot for ls1043ardb and ls1043ardb (and probably all my ARMv8 platforms) due to the way we reserve secure memory. I have added a patch (not upstreamed yet) to prevent dram_init_banksize() to run twice for my boards. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx7: Add support for USB boot mode
On 8/27/2017 3:04 PM, Eric Nelson wrote:
> This adds support for USB boot mode on the i.MX7D SoC, which
> is most useful when doing U-Boot development on this chip.
>
> i.e., it enables you to enter the ROM boot loader's serial
> download protocol using the command:
>
> => bmode usb
>
> Signed-off-by: Eric Nelson
> ---
> arch/arm/mach-imx/mx7/soc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
> index 87bf105..63ee59f 100644
> --- a/arch/arm/mach-imx/mx7/soc.c
> +++ b/arch/arm/mach-imx/mx7/soc.c
> @@ -372,6 +372,8 @@ void set_wdog_reset(struct wdog_regs *wdog)
> * to SBMR1, which will determine the boot device.
> */
> const struct boot_mode soc_boot_modes[] = {
You might want to add
+ {"normal", MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
while you're at it, to undo with "bmode normal"
> + {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
> +
> {"ecspi1:0",MAKE_CFGVAL(0x00, 0x60, 0x00, 0x00)},
> {"ecspi1:1",MAKE_CFGVAL(0x40, 0x62, 0x00, 0x00)},
> {"ecspi1:2",MAKE_CFGVAL(0x80, 0x64, 0x00, 0x00)},
>
Reviewed-by: Troy Kisky
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 10/12] board: freescale: common: add pfuze dm code
On 08/27/2017 11:30 PM, Peng Fan wrote: > Add pfuze dm code, this code does the same thing as pfuze.c, but > only effects when CONFIG_$(SPL_)DM_PMIC_PFUZE100 enabled. > > Signed-off-by: Peng Fan > Cc: York Sun > Cc: Jaehoon Chung > Cc: Stefano Babic > --- > > V2: none > > board/freescale/common/Makefile | 1 + > board/freescale/common/pfuze.h| 5 +++ > board/freescale/common/pfuze_dm.c | 89 > +++ > 3 files changed, 95 insertions(+) > create mode 100644 board/freescale/common/pfuze_dm.c > > diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile > index 1c53fb6..620dced 100644 > --- a/board/freescale/common/Makefile > +++ b/board/freescale/common/Makefile > @@ -61,6 +61,7 @@ obj-$(CONFIG_VSC_CROSSBAR)+= vsc3316_3308.o > obj-$(CONFIG_IDT8T49N222A) += idt8t49n222a_serdes_clk.o > obj-$(CONFIG_ZM7300)+= zm7300.o > obj-$(CONFIG_POWER_PFUZE100)+= pfuze.o > +obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze_dm.o > obj-$(CONFIG_POWER_MC34VR500) += mc34vr500.o > > obj-$(CONFIG_LS102XA_STREAM_ID) += ls102xa_stream_id.o > diff --git a/board/freescale/common/pfuze.h b/board/freescale/common/pfuze.h > index 53cfc99..9c4c92a 100644 > --- a/board/freescale/common/pfuze.h > +++ b/board/freescale/common/pfuze.h > @@ -7,7 +7,12 @@ > #ifndef __PFUZE_BOARD_HELPER__ > #define __PFUZE_BOARD_HELPER__ > > +#if CONFIG_IS_ENABLED(DM_PMIC_PFUZE100) Is this SPL safe? I guess you can have CONFIG_SPL_DM_PMIC_PFUZE100 according to you change to Makefile. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] video: ipuv3_fb: skip IPU shutdown if IPU was not enabled before
Hi Anatolij,
On Fri, Aug 25, 2017 at 10:10 AM, Anatolij Gustschin wrote:
> void ipuv3_fb_shutdown(void)
> {
> - int i;
> + struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> struct ipu_stat *stat = (struct ipu_stat *)IPU_STAT;
> + u32 reg;
> + int i;
> +
> + /*
> +* Check if IPU clock was enabled before. Won't access
> +* IPU registers if clock is not enabled.
> +*/
> + reg = readl(&mxc_ccm->CCGR3);
> + if ((reg & MXC_CCM_CCGR3_IPU1_IPU_MASK) == 0)
> + return;
Maybe you could also check whether IPU2 has been enabled?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Reg UBoot ITB Image Support for Sunxi Cortex A53 Family SOCS
Hi all, I'm trying to build ITB image for sunxi banana Pi M64 image in Buildroot. I'm facing issues with ITB format Uboot build. As per the readme file "board/sunxi/README.sunxi64", we need to build the bl31.bin image before uboot and pass the path of image as BL31 variable to UBOOT. Is there any procedure or some kind of script that can be used to combine uboot.bin and bl31.bin images and generate uboot.itb image ? Can we build uboot independently and post build combine with bl31.bin to generate uboot.itb ? Regards. Chakra ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: console: Fix duplicated CONFIG in silent env callback
On Fri, Aug 25, 2017 at 2:06 AM, Wilson Lee wrote: > The silent environment callback function does not update the silent > flag during silent env set or unset. That is because of duplicated > CONFIG keyword at preprocessor condition in silent environment > callback function and cause silent env callback unable to work. > > This patch is to remove the duplicated CONFIG keywork in silent > environment callback function. > > Signed-off-by: Wilson Lee > Cc: Keng Soon Cheah > Cc: Chen Yee Chew > Cc: Joe Hershberger Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Fix operation of 'make environ'
On Mon, Aug 28, 2017 at 6:13 AM, Tom Rini wrote: > On Mon, Aug 28, 2017 at 12:01:51PM +0100, Måns Rullgård wrote: >> Simon Glass writes: >> >> > This was broken by the recent environment refactoring. Specifically: >> > >> > $ make environ >> > scripts/Makefile.build:59: tools/environ/Makefile: No such file or >> > directory >> > make[1]: *** No rule to make target 'tools/environ/Makefile'. Stop. >> > make: *** [Makefile:1469: environ] Error 2 >> > >> > Fix this by updating the Makefile and adjusting the #include filesnames in >> > two C files. >> > >> > Fixes: ec74f5f (Makefile: Rename 'env' target to 'environ') >> > Reported-by: Måns Rullgård >> > Signed-off-by: Simon Glass >> >> This still breaks any build scripts using the old target (yes, there are >> many). That's probably acceptable, but a mention of it in some release >> note would be nice. >> >> Come to think of it, if we're anyway going to break things, how about >> giving that target a more descriptive name than environ? I suggest >> envtools. > > Too early, no coffee. Can't we do some make logic so that 'env' is > still a target and thus we don't break those scripts? Otherwise, yes, > I'll make sure to indicate in at least the v2017.09 release email that > we renamed 'env' to envtools or something. Thanks! It's really just building the fw_printenv tool (which uses a symlink for fw_setenv). It seems like a much clearer make target, and source dir for that matter, would be fw_printenv. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: timer: don't clear the GPT control register multiple times
On 28/08/2017 17:46, Anatolij Gustschin wrote: > There is no need to clear the control register 100 times in a > loop, a single zero write clears the register. I didn't find any > justification why clearing this register in a loop is needed > (no info in i.MX6 errata or GPT timer linux driver, linux driver > uses single write to clear this control register). > Agree, no idea why. > Signed-off-by: Anatolij Gustschin > --- > arch/arm/mach-imx/timer.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/arm/mach-imx/timer.c b/arch/arm/mach-imx/timer.c > index 9b01114..69dbf3c 100644 > --- a/arch/arm/mach-imx/timer.c > +++ b/arch/arm/mach-imx/timer.c > @@ -74,8 +74,7 @@ int timer_init(void) > __raw_writel(GPTCR_SWR, &cur_gpt->control); > > /* We have no udelay by now */ > - for (i = 0; i < 100; i++) > - __raw_writel(0, &cur_gpt->control); > + __raw_writel(0, &cur_gpt->control); > > i = __raw_readl(&cur_gpt->control); > i &= ~GPTCR_CLKSOURCE_MASK; > Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spl: do not repeat timer init on i.MX6
On 28/08/2017 17:46, Anatolij Gustschin wrote: > The GPT timer was already initialised in board_init_f() as > it is needed in dram init. Do not repeat timer init in > board_init_r(). > > Signed-off-by: Anatolij Gustschin > --- > common/spl/spl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index d245cfc..8b219ba 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -379,7 +379,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > if (spl_init()) > hang(); > } > -#ifndef CONFIG_PPC > +#if !defined(CONFIG_PPC) && !defined(CONFIG_ARCH_MX6) > /* >* timer_init() does not exist on PPC systems. The timer is initialized >* and enabled (decrementer) in interrupt_init() here. > Acked-by: Stefano Babic Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] clk: uniphier: add System clock support
Support system clocks for LD4, Pro4, sLD8, Pro5, PXs2/LD6b, LD11, LD20.
Signed-off-by: Masahiro Yamada
---
drivers/clk/uniphier/Makefile| 1 +
drivers/clk/uniphier/clk-uniphier-core.c | 30
drivers/clk/uniphier/clk-uniphier-sys.c | 34
drivers/clk/uniphier/clk-uniphier.h | 2 ++
4 files changed, 67 insertions(+)
create mode 100644 drivers/clk/uniphier/clk-uniphier-sys.c
diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
index ed623aa56f75..54c7e09bd606 100644
--- a/drivers/clk/uniphier/Makefile
+++ b/drivers/clk/uniphier/Makefile
@@ -1,2 +1,3 @@
obj-y += clk-uniphier-core.o
+obj-y += clk-uniphier-sys.o
obj-y += clk-uniphier-mio.o
diff --git a/drivers/clk/uniphier/clk-uniphier-core.c
b/drivers/clk/uniphier/clk-uniphier-core.c
index eed21b9a6871..722cd6b060c8 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -146,6 +146,36 @@ static int uniphier_clk_probe(struct udevice *dev)
}
static const struct udevice_id uniphier_clk_match[] = {
+ /* System clock */
+ {
+ .compatible = "socionext,uniphier-ld4-clock",
+ .data = (ulong)&uniphier_pxs2_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro4-clock",
+ .data = (ulong)&uniphier_pxs2_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-sld8-clock",
+ .data = (ulong)&uniphier_pxs2_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro5-clock",
+ .data = (ulong)&uniphier_pxs2_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pxs2-clock",
+ .data = (ulong)&uniphier_pxs2_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld11-clock",
+ .data = (ulong)&uniphier_ld20_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld20-clock",
+ .data = (ulong)&uniphier_ld20_sys_clk_data,
+ },
+ /* Media I/O clock */
{
.compatible = "socionext,uniphier-ld4-mio-clock",
.data = (ulong)&uniphier_mio_clk_data,
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c
b/drivers/clk/uniphier/clk-uniphier-sys.c
new file mode 100644
index ..709fa5081a42
--- /dev/null
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright (C) 2016-2017 Socionext Inc.
+ * Author: Masahiro Yamada
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include "clk-uniphier.h"
+
+const struct uniphier_clk_gate_data uniphier_pxs2_sys_clk_gate[] = {
+ UNIPHIER_CLK_GATE(8, 0x2104, 10), /* stdmac */
+ UNIPHIER_CLK_GATE(12, 0x2104, 6), /* gio (Pro4, Pro5) */
+ UNIPHIER_CLK_GATE(14, 0x2104, 16), /* usb30 (Pro4, Pro5, PXs2) */
+ UNIPHIER_CLK_GATE(15, 0x2104, 17), /* usb31 (Pro4, Pro5, PXs2) */
+ UNIPHIER_CLK_GATE(16, 0x2104, 19), /* usb30-phy (PXs2) */
+ UNIPHIER_CLK_GATE(20, 0x2104, 20), /* usb31-phy (PXs2) */
+ UNIPHIER_CLK_END
+};
+
+const struct uniphier_clk_data uniphier_pxs2_sys_clk_data = {
+ .gate = uniphier_pxs2_sys_clk_gate,
+};
+
+const struct uniphier_clk_gate_data uniphier_ld20_sys_clk_gate[] = {
+ UNIPHIER_CLK_GATE(8, 0x210c, 8),/* stdmac */
+ UNIPHIER_CLK_GATE(14, 0x210c, 14), /* usb30 (LD20) */
+ UNIPHIER_CLK_GATE(16, 0x210c, 12), /* usb30-phy0 (LD20) */
+ UNIPHIER_CLK_GATE(17, 0x210c, 13), /* usb30-phy1 (LD20) */
+ UNIPHIER_CLK_END
+};
+
+const struct uniphier_clk_data uniphier_ld20_sys_clk_data = {
+ .gate = uniphier_ld20_sys_clk_gate,
+};
diff --git a/drivers/clk/uniphier/clk-uniphier.h
b/drivers/clk/uniphier/clk-uniphier.h
index f9a560ee73d3..770a3225e1a3 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -50,6 +50,8 @@ struct uniphier_clk_data {
.rates = {(_reg),}, \
}
+extern const struct uniphier_clk_data uniphier_pxs2_sys_clk_data;
+extern const struct uniphier_clk_data uniphier_ld20_sys_clk_data;
extern const struct uniphier_clk_data uniphier_mio_clk_data;
#endif /* __CLK_UNIPHIER_H__ */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx6: don't include unneeded boot_mode array in SPL
On 28/08/2017 17:51, Anatolij Gustschin wrote:
> The soc_boot_modes array is only used by bmode command
> and not needed in SPL. Don't include it into SPL.
>
> Signed-off-by: Anatolij Gustschin
> ---
> arch/arm/mach-imx/mx6/soc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
> index 9ede1f5..13ca286 100644
> --- a/arch/arm/mach-imx/mx6/soc.c
> +++ b/arch/arm/mach-imx/mx6/soc.c
> @@ -551,6 +551,7 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
> }
> #endif
>
> +#ifndef CONFIG_SPL_BUILD
> /*
> * cfg_val will be used for
> * Boot_cfg4[7:0]:Boot_cfg3[7:0]:Boot_cfg2[7:0]:Boot_cfg1[7:0]
> @@ -577,6 +578,7 @@ const struct boot_mode soc_boot_modes[] = {
> {"esdhc4", MAKE_CFGVAL(0x40, 0x38, 0x00, 0x00)},
> {NULL, 0},
> };
> +#endif
>
> void reset_misc(void)
> {
>
Reviewed-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] Kconfig: drop CONFIG_USB_ETHER_DM9601
On Sun, Aug 27, 2017 at 4:44 AM, Chris Packham wrote: > This is not a valid option. Drop it. > > Signed-off-by: Chris Packham > Reviewed-by: Simon Glass Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] Kconfig: drop CONFIG_USB_ETHER_RNDIS
On Sun, Aug 27, 2017 at 4:44 AM, Chris Packham wrote: > This is not a valid option. Drop it. > > Signed-off-by: Chris Packham > Reviewed-by: Simon Glass Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: macb: Add support for Xilinx Zynq SoC
On Tue, Aug 22, 2017 at 10:25 PM, Wilson Lee wrote: > Although Xilinx Zynq SoC was using MACB similar hardware. However, > U-boot MACB driver was not supporting Xilinx Zynq SoC. This patch is > to add support for the Xilinx Zynq SoC to the existing MACB network > driver. > > This patch is to add Zynq GEM DMA Config, provide callback > function for different linkspeed for case of using Xilinx Zynq > Programmable Logic as GMII to RGMII convertor. > > This patch convert the return value to use error codes. > > Signed-off-by: Wilson Lee > Cc: Chen Yee Chew > Cc: Keng Soon Cheah > Cc: Joe Hershberger > Cc: Wenyou Yang Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] lib: don't build regex support into SPL when not using environment
regex code is not used in SPL when environment support is disabled, so do not include this code to reduce SPL size. Signed-off-by: Anatolij Gustschin --- lib/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/Makefile b/lib/Makefile index 1ffa455..b0850a1 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_RBTREE) += rbtree.o obj-$(CONFIG_BITREVERSE) += bitrev.o obj-y += list_sort.o obj-y += hashtable.o +obj-$(CONFIG_REGEX) += slre.o endif obj-$(CONFIG_RSA) += rsa/ @@ -78,7 +79,9 @@ obj-y += hang.o obj-y += linux_compat.o obj-y += linux_string.o obj-y += membuff.o +ifdef CONFIG_SPL_ENV_SUPPORT obj-$(CONFIG_REGEX) += slre.o +endif obj-y += string.o obj-y += tables_csum.o obj-y += time.o -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] lib: disable hashtable and display options code in SPL
We do not need hashtable code in SPL when building without environment support. Also display options code is not used in current SPL configuration and can be disabled. Signed-off-by: Anatolij Gustschin --- lib/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/Makefile b/lib/Makefile index 2eef1eb..1ffa455 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -43,6 +43,7 @@ obj-$(CONFIG_TPM) += tpm.o obj-$(CONFIG_RBTREE) += rbtree.o obj-$(CONFIG_BITREVERSE) += bitrev.o obj-y += list_sort.o +obj-y += hashtable.o endif obj-$(CONFIG_RSA) += rsa/ @@ -61,10 +62,14 @@ obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o obj-$(CONFIG_SPL_NET_SUPPORT) += net_utils.o endif obj-$(CONFIG_ADDR_MAP) += addr_map.o -obj-y += hashtable.o obj-y += errno.o +ifdef CONFIG_SPL_BUILD +obj-$(CONFIG_SPL_ENV_SUPPORT) += hashtable.o +endif +ifndef CONFIG_SPL_BUILD obj-y += display_options.o CFLAGS_display_options.o := $(if $(BUILD_TAG),-DBUILD_TAG='"$(BUILD_TAG)"') +endif obj-$(CONFIG_BCH) += bch.o obj-y += crc32.o obj-y += ctype.o -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx6: don't include unneeded boot_mode array in SPL
The soc_boot_modes array is only used by bmode command
and not needed in SPL. Don't include it into SPL.
Signed-off-by: Anatolij Gustschin
---
arch/arm/mach-imx/mx6/soc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 9ede1f5..13ca286 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -551,6 +551,7 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
}
#endif
+#ifndef CONFIG_SPL_BUILD
/*
* cfg_val will be used for
* Boot_cfg4[7:0]:Boot_cfg3[7:0]:Boot_cfg2[7:0]:Boot_cfg1[7:0]
@@ -577,6 +578,7 @@ const struct boot_mode soc_boot_modes[] = {
{"esdhc4", MAKE_CFGVAL(0x40, 0x38, 0x00, 0x00)},
{NULL, 0},
};
+#endif
void reset_misc(void)
{
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] spl: do not repeat timer init on i.MX6
The GPT timer was already initialised in board_init_f() as it is needed in dram init. Do not repeat timer init in board_init_r(). Signed-off-by: Anatolij Gustschin --- common/spl/spl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl.c b/common/spl/spl.c index d245cfc..8b219ba 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -379,7 +379,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) if (spl_init()) hang(); } -#ifndef CONFIG_PPC +#if !defined(CONFIG_PPC) && !defined(CONFIG_ARCH_MX6) /* * timer_init() does not exist on PPC systems. The timer is initialized * and enabled (decrementer) in interrupt_init() here. -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] imx: timer: don't clear the GPT control register multiple times
There is no need to clear the control register 100 times in a loop, a single zero write clears the register. I didn't find any justification why clearing this register in a loop is needed (no info in i.MX6 errata or GPT timer linux driver, linux driver uses single write to clear this control register). Signed-off-by: Anatolij Gustschin --- arch/arm/mach-imx/timer.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/timer.c b/arch/arm/mach-imx/timer.c index 9b01114..69dbf3c 100644 --- a/arch/arm/mach-imx/timer.c +++ b/arch/arm/mach-imx/timer.c @@ -74,8 +74,7 @@ int timer_init(void) __raw_writel(GPTCR_SWR, &cur_gpt->control); /* We have no udelay by now */ - for (i = 0; i < 100; i++) - __raw_writel(0, &cur_gpt->control); + __raw_writel(0, &cur_gpt->control); i = __raw_readl(&cur_gpt->control); i &= ~GPTCR_CLKSOURCE_MASK; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: uniphier: fix DSPLL init code for LD20 SoC
From: Dai Okamura Signed-off-by: Dai Okamura Signed-off-by: Masahiro Yamada --- arch/arm/mach-uniphier/clk/pll-base-ld20.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-uniphier/clk/pll-base-ld20.c b/arch/arm/mach-uniphier/clk/pll-base-ld20.c index 697eb7aabf01..3aa42f8bfdcd 100644 --- a/arch/arm/mach-uniphier/clk/pll-base-ld20.c +++ b/arch/arm/mach-uniphier/clk/pll-base-ld20.c @@ -88,7 +88,7 @@ int uniphier_ld20_sscpll_set_regi(unsigned long reg_base, unsigned regi) if (!base) return -ENOMEM; - tmp = readl(base + 8); /* SSCPLLCTRL */ + tmp = readl(base + 8); /* SSCPLLCTRL3 */ tmp &= ~SC_PLLCTRL3_REGI_MASK; tmp |= regi << SC_PLLCTRL3_REGI_SHIFT; writel(tmp, base + 8); @@ -133,9 +133,9 @@ int uniphier_ld20_dspll_init(unsigned long reg_base) if (!base) return -ENOMEM; - tmp = readl(base + 8); /* DSPLLCTRL2 */ + tmp = readl(base + 4); /* DSPLLCTRL2 */ tmp |= SC_DSPLLCTRL2_K_LD; - writel(tmp, base + 8); + writel(tmp, base + 4); iounmap(base); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/10] config: sandbox: Add unit tests
Hi Simon, On Sat, 2017-08-26 at 07:37 -0600, Simon Glass wrote: > On 11 August 2017 at 02:52, Pantelis Antoniou > wrote: > > Add unit tests for sandbox default config. > > > > Signed-off-by: Pantelis Antoniou > > --- > > configs/sandbox_defconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > I don't see any tests in this patch? > Err, maybe the wording of the commit message needs to change. There are no new tests, merely enabling overlays for the sandbox config makes them available as unitests. I will reword. > > > > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig > > index fd0b952..df8659a 100644 > > --- a/configs/sandbox_defconfig > > +++ b/configs/sandbox_defconfig > > @@ -187,7 +187,9 @@ CONFIG_CMD_DHRYSTONE=y > > CONFIG_TPM=y > > CONFIG_LZ4=y > > CONFIG_ERRNO_STR=y > > +CONFIG_OF_LIBFDT_OVERLAY=y > > CONFIG_UNIT_TEST=y > > CONFIG_UT_TIME=y > > CONFIG_UT_DM=y > > CONFIG_UT_ENV=y > > +CONFIG_UT_OVERLAY=y > > -- > > 2.1.4 > > > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: davinci: da850: Enable Caches for DA850-EVM
On Sun, Aug 27, 2017 at 5:39 PM, Adam Ford wrote:
> What starting up the DA850-EVM, U-Boot generates a warning:
>WARNING: Caches not enabled
>
> Looking at other arm926 processors, this is an attempt
> to enable the caches and remove the warning.
>
> I am notsure who the proper TI or ARM people are to review this.
>
For what It's worth, I ran some whetstone benchmarks. Using 1000 loops,
the da850-evm increased from 14.3 MIPS without cache to 16.7 MIPS with cache
> Signed-off-by: Adam Ford
> ---
> board/davinci/da8xxevm/da850evm.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/board/davinci/da8xxevm/da850evm.c
> b/board/davinci/da8xxevm/da850evm.c
> index c2d2e8e..33a923c 100644
> --- a/board/davinci/da8xxevm/da850evm.c
> +++ b/board/davinci/da8xxevm/da850evm.c
> @@ -491,3 +491,29 @@ int board_eth_init(bd_t *bis)
> return 0;
> }
> #endif /* CONFIG_DRIVER_TI_EMAC */
> +
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +/* Invalidate entire I-cache and branch predictor array */
> +void invalidate_icache_all(void)
> +{
> + unsigned long i = 0;
> +
> + asm ("mcr p15, 0, %0, c7, c5, 0" : : "r" (i));
> +}
> +#else
> +void invalidate_icache_all(void)
> +{
> +}
> +#endif
> +
> +#ifndef CONFIG_SYS_DCACHE_OFF
> +void enable_caches(void)
> +{
> + /* Enable D-cache. I-cache is already enabled in start.S */
> + dcache_enable();
> +}
> +#else
> +void enable_caches(void)
> +{
> +}
> +#endif /* CONFIG_SYS_DCACHE_OFF */
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] I/O accessors on SuperH and endianness
Hello,
As you've noticed, I'm porting U-Boot to a SH4 board running
big-endian. The big-endian choice cannot be changed, because it's
selected by the HW design: moving to little endian would require a
modification of the board.
The serial_sh driver was working fine in big endian, with no change.
However, the sh_eth driver was not working in big endian mode. After
investigation, I realized that:
- sh_serial is using the read/write (readb, writeb, readw, writew,
etc.) macros to access I/O registers
- sh_eth is using the in/out macros to access I/O registers
The in/out macros assume the device registers are little endian, so
when the CPU is running big endian, they do an endianness conversion.
However, on SuperH, when the CPU runs big endian, the device registers
are also big endian, so there should be no endianness conversion.
On the other hand, read/write, when __mem_pci is not defined, do not do
any endianness conversion. And this is why sh_serial was working out of
the box. Changing sh_eth to use read/write instead of in/out also made
it work in big endian mode.
However, if for some reason I enable PCI on this platform, __mem_pci
will be defined, and read/write will perform endianness conversion,
breaking support for the platform.
So what is the appropriate solution here? Use read/write like sh_serial
is doing today, and ignore the potential problem? Use __raw_*()
variants everywhere? What if a driver is shared with another
platform/architecture where the devices remain little endian even if
the CPU is running big endian?
Best regards,
Thomas
For the record, here is the current patch I have on sh_eth (a few other
changes are needed, but not directly related) :
diff --git a/drivers/net/sh_eth.h b/drivers/net/sh_eth.h
index a09a6d7..0e65f97 100644
--- a/drivers/net/sh_eth.h
+++ b/drivers/net/sh_eth.h
@@ -675,11 +675,11 @@ static inline unsigned long sh_eth_reg_addr(struct
sh_eth_dev *eth,
static inline void sh_eth_write(struct sh_eth_dev *eth, unsigned long data,
int enum_index)
{
- outl(data, sh_eth_reg_addr(eth, enum_index));
+ writel(data, sh_eth_reg_addr(eth, enum_index));
}
static inline unsigned long sh_eth_read(struct sh_eth_dev *eth,
int enum_index)
{
- return inl(sh_eth_reg_addr(eth, enum_index));
+ return readl(sh_eth_reg_addr(eth, enum_index));
}
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] serial: serial_sh: take into account port->clk_mode for SH7785/7786
In the SH7785/SH7786 case, the SCSCR value is harcoded to be 0x3a,
which means bits CKE1/CKE0 have the value 10b. This tells the SCIF
that the "External clock/SCIF_SCK pin functions as clock input".
However, this is not the case in all designs, and it's the purpose of
the clk_mode = EXT_CLK to indicate such a setting.
In order for the serial_sh driver to work on a SH7786 platform that
does not use SCIF_SCK as a clock input, we have to adjust the
SCSCR_INIT value, to have CKE1/CKE0 set to 00b. This is similar to
what is done for other SH platforms.
Signed-off-by: Thomas Petazzoni
---
drivers/serial/serial_sh.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
index 4d27122..d7bbd1a 100644
--- a/drivers/serial/serial_sh.h
+++ b/drivers/serial/serial_sh.h
@@ -184,7 +184,8 @@ struct uart_port {
# define SCSPTR4 0xffee0024 /* 16 bit SCIF */
# define SCSPTR5 0xffef0024 /* 16 bit SCIF */
# define SCIF_ORER 0x0001 /* Overrun error bit */
-# define SCSCR_INIT(port) 0x3a/* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */
+# define SCSCR_INIT(port) (port->clk_mode == EXT_CLK ? 0x3a : 0x38)
+ /* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */
#elif defined(CONFIG_CPU_SH7201) || \
defined(CONFIG_CPU_SH7203) || \
defined(CONFIG_CPU_SH7206) || \
--
2.9.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Drop board_mmc_init
The board_mmc_init() is no longer invoked when DM is used, so move
all the pinmux config into board_init() instead.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
board/renesas/salvator-x/salvator-x.c | 9 ++---
board/renesas/ulcb/ulcb.c | 9 ++---
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/board/renesas/salvator-x/salvator-x.c
b/board/renesas/salvator-x/salvator-x.c
index d8a0d7a8a2..2695de5dbf 100644
--- a/board/renesas/salvator-x/salvator-x.c
+++ b/board/renesas/salvator-x/salvator-x.c
@@ -158,12 +158,7 @@ int board_init(void)
udelay(1);
#endif
- return 0;
-}
-
-#ifdef CONFIG_SH_SDHI
-int board_mmc_init(bd_t *bis)
-{
+#ifdef CONFIG_MMC
/* SDHI0 */
gpio_request(GPIO_GFN_SD0_DAT0, NULL);
gpio_request(GPIO_GFN_SD0_DAT1, NULL);
@@ -227,10 +222,10 @@ int board_mmc_init(bd_t *bis)
gpio_request(GPIO_GP_3_14, NULL);
gpio_direction_output(GPIO_GP_3_15, 1); /* power on */
gpio_direction_output(GPIO_GP_3_14, 1); /* 1: 3.3V, 0: 1.8V */
+#endif
return 0;
}
-#endif
int dram_init(void)
{
diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index 695cce9465..2b6cc612c8 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -137,12 +137,7 @@ int board_init(void)
udelay(1);
#endif
- return 0;
-}
-
-#ifdef CONFIG_SH_SDHI
-int board_mmc_init(bd_t *bis)
-{
+#ifdef CONFIG_MMC
/* SDHI0 */
gpio_request(GPIO_GFN_SD0_DAT0, NULL);
gpio_request(GPIO_GFN_SD0_DAT1, NULL);
@@ -179,10 +174,10 @@ int board_mmc_init(bd_t *bis)
gpio_request(GPIO_GP_5_9, NULL);
gpio_direction_output(GPIO_GP_5_3, 0); /* 1: 3.3V, 0: 1.8V */
gpio_direction_output(GPIO_GP_5_9, 0); /* 1: 3.3V, 0: 1.8V */
+#endif
return 0;
}
-#endif
int dram_init(void)
{
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Add missing IPSR18 bits to R8A7795 PFC
The IPSR18 register bits were missing from the R8A7795 ES2.0+ PFC
tables, which triggered a BUG() in sh_pfc driver. This is because
of an out-of-bounds access to the pinmux_gpios[] array in the PFC
tables, which was too short due to the missing IPSR18 bits.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/mach-rmobile/pfc-r8a7795.c | 42 +
1 file changed, 42 insertions(+)
diff --git a/arch/arm/mach-rmobile/pfc-r8a7795.c
b/arch/arm/mach-rmobile/pfc-r8a7795.c
index 4446093973..93aaf31ed9 100644
--- a/arch/arm/mach-rmobile/pfc-r8a7795.c
+++ b/arch/arm/mach-rmobile/pfc-r8a7795.c
@@ -2185,6 +2185,27 @@ enum {
FSO_TOEx_MARK,
TPU0TO1_MARK,
+ /* IPSR18 */
+ USB3_PWEN_IMARK,
+ AUDIO_CLKOUT2_B_MARK,
+ SSI_SCK9_B_MARK,
+ TS_SDEN0_E_MARK,
+ STP_ISEN_0_E_MARK,
+ RIF2_D0_B_MARK,
+ TPU0TO2_MARK,
+ FMCLK_C_MARK,
+ FMCLK_D_MARK,
+
+ USB3_OVC_IMARK,
+ AUDIO_CLKOUT3_B_MARK,
+ SSI_WS9_B_MARK,
+ TS_SPSYNC0_E_MARK,
+ STP_ISSYNC_0_E_MARK,
+ RIF2_D1_B_MARK,
+ TPU0TO3_MARK,
+ FMIN_C_MARK,
+ FMIN_D_MARK,
+
PINMUX_MARK_END,
};
@@ -3288,6 +3309,27 @@ static struct pinmux_gpio pinmux_gpios[] = {
GPIO_FN(RIF3_D1_B),
GPIO_FN(FSO_TOEx),
GPIO_FN(TPU0TO1),
+
+ /* IPSR18 */
+ GPIO_IFN(USB3_PWEN),
+ GPIO_FN(AUDIO_CLKOUT2_B),
+ GPIO_FN(SSI_SCK9_B),
+ GPIO_FN(TS_SDEN0_E),
+ GPIO_FN(STP_ISEN_0_E),
+ GPIO_FN(RIF2_D0_B),
+ GPIO_FN(TPU0TO2),
+ GPIO_FN(FMCLK_C),
+ GPIO_FN(FMCLK_D),
+
+ GPIO_IFN(USB3_OVC),
+ GPIO_FN(AUDIO_CLKOUT3_B),
+ GPIO_FN(SSI_WS9_B),
+ GPIO_FN(TS_SPSYNC0_E),
+ GPIO_FN(STP_ISSYNC_0_E),
+ GPIO_FN(RIF2_D1_B),
+ GPIO_FN(TPU0TO3),
+ GPIO_FN(FMIN_C),
+ GPIO_FN(FMIN_D),
};
static struct pinmux_cfg_reg pinmux_config_regs[] = {
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Replace CONFIG_RAVB with CONFIG_RENESAS_RAVB in boards
The configuration option name is the later, so replace usage of CONFIG_RAVB in board files with CONFIG_RENESAS_RAVB , otherwise the RAVB pinmux is not set and ethernet does not work. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- board/renesas/salvator-x/salvator-x.c | 2 +- board/renesas/ulcb/ulcb.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/renesas/salvator-x/salvator-x.c b/board/renesas/salvator-x/salvator-x.c index a09cd56d66..d8a0d7a8a2 100644 --- a/board/renesas/salvator-x/salvator-x.c +++ b/board/renesas/salvator-x/salvator-x.c @@ -116,7 +116,7 @@ int board_init(void) /* USB1 pull-up */ setbits_le32(PFC_PUEN6, PUEN_USB1_OVC | PUEN_USB1_PWEN); -#ifdef CONFIG_RAVB +#ifdef CONFIG_RENESAS_RAVB /* EtherAVB Enable */ /* GPSR2 */ gpio_request(GPIO_GFN_AVB_AVTP_CAPTURE_A, NULL); diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c index 068cbdea03..695cce9465 100644 --- a/board/renesas/ulcb/ulcb.c +++ b/board/renesas/ulcb/ulcb.c @@ -105,7 +105,7 @@ int board_init(void) /* USB1 pull-up */ setbits_le32(PFC_PUEN6, PUEN_USB1_OVC | PUEN_USB1_PWEN); -#ifdef CONFIG_RAVB +#ifdef CONFIG_RENESAS_RAVB /* EtherAVB Enable */ /* GPSR2 */ gpio_request(GPIO_GFN_AVB_AVTP_CAPTURE_A, NULL); -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
