Re: [U-Boot] [PATCH 5/8] sun8i: Display silicon revision of A83t processors
Hi, On Tue, May 17, 2016 at 10:39 AM,wrote: Description please. How did you learn of the different revisions? Any differences between the revisions? > Signed-off-by: Timothy Pearson > --- > arch/arm/mach-sunxi/cpu_info.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c > index 76b6719..d552061 100644 > --- a/arch/arm/mach-sunxi/cpu_info.c > +++ b/arch/arm/mach-sunxi/cpu_info.c > @@ -50,6 +50,17 @@ uint sunxi_get_sram_id(void) > > return id; > } > + > +uint sunxi_get_revision(void) > +{ > + uint rev; > + > + /* Unlock sram info reg, read it, relock */ > + rev = readl(SUNXI_SRAMC_BASE + 0x24) & 0x1; > + > + return rev; > +} > + > #endif > > #ifdef CONFIG_DISPLAY_CPUINFO > @@ -84,7 +95,7 @@ int print_cpuinfo(void) > #elif defined CONFIG_MACH_SUN8I_A33 > printf("CPU: Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id()); > #elif defined CONFIG_MACH_SUN8I_A83T > - printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id()); > + printf("CPU: Allwinner A83T (SUN8I %04x rev. %s)\n", > sunxi_get_sram_id(), (sunxi_get_revision() == 0)?"A":"B"); Please wrap the line properly. ChenYu > #elif defined CONFIG_MACH_SUN8I_H3 > printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id()); > #elif defined CONFIG_MACH_SUN9I > -- > 2.8.0.rc3 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] sun8i: Add TZPC setup for A83t
Hi, On Tue, May 17, 2016 at 10:39 AM,wrote: Description please. > Signed-off-by: Timothy Pearson > --- > arch/arm/cpu/armv7/sunxi/Makefile | 1 + > arch/arm/cpu/armv7/sunxi/tzpc.c| 10 ++ > arch/arm/include/asm/arch-sunxi/tzpc.h | 10 ++ > arch/arm/mach-sunxi/board.c| 2 +- > 4 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/armv7/sunxi/Makefile > b/arch/arm/cpu/armv7/sunxi/Makefile > index 4d2274a..4dd449b 100644 > --- a/arch/arm/cpu/armv7/sunxi/Makefile > +++ b/arch/arm/cpu/armv7/sunxi/Makefile > @@ -11,6 +11,7 @@ obj-y += timer.o > > obj-$(CONFIG_MACH_SUN6I) += tzpc.o > obj-$(CONFIG_MACH_SUN8I_H3)+= tzpc.o > +obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o > > ifndef CONFIG_SPL_BUILD > ifdef CONFIG_ARMV7_PSCI > diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c > index 6c8a0fd..7723853 100644 > --- a/arch/arm/cpu/armv7/sunxi/tzpc.c > +++ b/arch/arm/cpu/armv7/sunxi/tzpc.c > @@ -24,4 +24,14 @@ void tzpc_init(void) > writel(SUN8I_H3_TZPC_DECPORT1_ALL, >decport1_set); > writel(SUN8I_H3_TZPC_DECPORT2_ALL, >decport2_set); > #endif > + > +#ifdef SUN8I_A83T_TZPC_DECPORT0_ALL > + /* Emable non-secure access to RAM */ > + writel(R0SIZE, >r0size); Why would you do that? That defeats the whole purpose of having the secure monitor running in secure SRAM. > + > + /* Enable non-secure access to all peripherals */ > + writel(SUN8I_A83T_TZPC_DECPORT0_ALL, >decport0_set); > + writel(SUN8I_A83T_TZPC_DECPORT1_ALL, >decport1_set); > + writel(SUN8I_A83T_TZPC_DECPORT2_ALL, >decport2_set); > +#endif And move this block above H3's block. > } > diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h > b/arch/arm/include/asm/arch-sunxi/tzpc.h > index 95c55cd..bcf0713 100644 > --- a/arch/arm/include/asm/arch-sunxi/tzpc.h > +++ b/arch/arm/include/asm/arch-sunxi/tzpc.h > @@ -29,6 +29,16 @@ struct sunxi_tzpc { > #define SUN8I_H3_TZPC_DECPORT1_ALL 0xff > #define SUN8I_H3_TZPC_DECPORT2_ALL 0x7f > > +#define SUN8I_A83T_TZPC_DECPORT0_ALL 0xbe > +#define SUN8I_A83T_TZPC_DECPORT1_ALL 0x7f > +#define SUN8I_A83T_TZPC_DECPORT2_ALL 0x10 A83T before H3. > + > +/* > + * TZPC Register Value : > + * R0SIZE: 0x10 : Size of secured ram (64Kib) > + */ > +#define R0SIZE 0x10 Where did this come from? > + > void tzpc_init(void); > > #endif /* _SUNXI_TZPC_H */ > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c > index 20149da..4e0f7f9 100644 > --- a/arch/arm/mach-sunxi/board.c > +++ b/arch/arm/mach-sunxi/board.c > @@ -183,7 +183,7 @@ void s_init(void) > "orr r0, r0, #1 << 6\n" > "mcr p15, 0, r0, c1, c0, 1\n"); > #endif > -#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 > +#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 || defined > CONFIG_MACH_SUN8I_A83T A83T comes before H3. ChenYu > /* Enable non-secure access to some peripherals */ > tzpc_init(); > #endif > -- > 2.8.0.rc3 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] sun8i: Extend stack size to allow for up to 8 CPUs
Hi, On Tue, May 17, 2016 at 10:38 AM,wrote: > --- > arch/arm/cpu/armv7/psci.S | 1 + > arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 4 ++-- > arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 4 ++-- > 3 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S > index 87c0c0b..18a0cc2 100644 > --- a/arch/arm/cpu/armv7/psci.S > +++ b/arch/arm/cpu/armv7/psci.S > @@ -203,6 +203,7 @@ ENTRY(psci_get_cpu_stack_top) > add r5, r5, #0x2000 @ Skip two pages > lsr r5, r5, #12 @ Align to start of page Why not just change this line instead? ChenYu > lsl r5, r5, #12 > + add r5, r5, #0x1000 @ Skip an additional page > sub r5, r5, #4 @ reserve 1 word for target PC > sub r0, r5, r0 @ here's our stack! > > diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S > b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S > index 90b5bfd..d35b63e 100644 > --- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S > +++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S > @@ -32,8 +32,8 @@ > * ._secure_text section > * text_end to ALIGN_PAGE(text_end): > * nothing > - * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000) > - * 1kB of stack per CPU (4 CPUs max). > + * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000) > + * 1kB of stack per CPU (8 CPUs max). > */ > > .pushsection ._secure.text, "ax" > diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S > b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S > index e15d587..b8ac50e 100644 > --- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S > +++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S > @@ -32,8 +32,8 @@ > * ._secure_text section > * text_end to ALIGN_PAGE(text_end): > * nothing > - * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000) > - * 1kB of stack per CPU (4 CPUs max). > + * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000) > + * 1kB of stack per CPU (8 CPUs max). > */ > > .pushsection ._secure.text, "ax" > -- > 2.8.0.rc3 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] net: macb: Fix build error for CONFIG_DM_ETH enabled
Use the right phy_connect() prototype for CONFIGF_DM_ETH. Support to get the phy interface from dt and set GMAC_UR. Signed-off-by: Wenyou Yang--- This patch is based on the patch set, [PATCH 00/18] at91: Convert Ethernet and LCD to driver model http://lists.denx.de/pipermail/u-boot/2016-May/253559.html Hi Simon, With this patch, the ethernet works on SAMA5D2 Xplained board. But it includes a lot of #ifdef, I think it is not pretty. What is your opinions? drivers/net/macb.c | 77 -- 1 file changed, 69 insertions(+), 8 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 63fb466..ddb9e23 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -43,6 +43,8 @@ #include "macb.h" +DECLARE_GLOBAL_DATA_PTR; + #define MACB_RX_BUFFER_SIZE4096 #define MACB_RX_RING_SIZE (MACB_RX_BUFFER_SIZE / 128) #define MACB_TX_RING_SIZE 16 @@ -108,6 +110,10 @@ struct macb_device { #endif unsigned short phy_addr; struct mii_dev *bus; + +#ifdef CONFIG_DM_ETH + phy_interface_t phy_interface; +#endif }; #ifndef CONFIG_DM_ETH #define to_macb(_nd) container_of(_nd, struct macb_device, netdev) @@ -434,7 +440,7 @@ static void macb_phy_reset(struct macb_device *macb, const char *name) } #ifdef CONFIG_MACB_SEARCH_PHY -static int macb_phy_find(struct macb_device *macb) +static int macb_phy_find(struct macb_device *macb, const char *name) { int i; u16 phy_id; @@ -444,21 +450,27 @@ static int macb_phy_find(struct macb_device *macb) macb->phy_addr = i; phy_id = macb_mdio_read(macb, MII_PHYSID1); if (phy_id != 0x) { - printf("%s: PHY present at %d\n", macb->netdev.name, i); + printf("%s: PHY present at %d\n", name, i); return 1; } } /* PHY isn't up to snuff */ - printf("%s: PHY not found\n", macb->netdev.name); + printf("%s: PHY not found\n", name); return 0; } #endif /* CONFIG_MACB_SEARCH_PHY */ - +#ifdef CONFIG_DM_ETH +static int macb_phy_init(struct udevice *dev, const char *name) +#else static int macb_phy_init(struct macb_device *macb, const char *name) +#endif { +#ifdef CONFIG_DM_ETH + struct macb_device *macb = dev_get_priv(dev); +#endif #ifdef CONFIG_PHYLIB struct phy_device *phydev; #endif @@ -470,7 +482,7 @@ static int macb_phy_init(struct macb_device *macb, const char *name) arch_get_mdio_control(name); #ifdef CONFIG_MACB_SEARCH_PHY /* Auto-detect phy_addr */ - if (!macb_phy_find(macb)) + if (!macb_phy_find(macb, name)) return 0; #endif /* CONFIG_MACB_SEARCH_PHY */ @@ -482,9 +494,14 @@ static int macb_phy_init(struct macb_device *macb, const char *name) } #ifdef CONFIG_PHYLIB +#ifdef CONFIG_DM_ETH + phydev = phy_connect(macb->bus, macb->phy_addr, dev, +macb->phy_interface); +#else /* need to consider other phy interface mode */ phydev = phy_connect(macb->bus, macb->phy_addr, >netdev, PHY_INTERFACE_MODE_RGMII); +#endif if (!phydev) { printf("phy_connect failed\n"); return -ENODEV; @@ -585,8 +602,15 @@ static int gmac_init_multi_queues(struct macb_device *macb) return 0; } +#ifdef CONFIG_DM_ETH +static int _macb_init(struct udevice *dev, const char *name) +#else static int _macb_init(struct macb_device *macb, const char *name) +#endif { +#ifdef CONFIG_DM_ETH + struct macb_device *macb = dev_get_priv(dev); +#endif unsigned long paddr; int i; @@ -634,13 +658,35 @@ static int _macb_init(struct macb_device *macb, const char *name) * When the GMAC IP without GE feature, this bit is used * to select interface between RMII and MII. */ +#ifdef CONFIG_DM_ETH + if (macb->phy_interface == PHY_INTERFACE_MODE_RMII) + gem_writel(macb, UR, GEM_BIT(RGMII)); + else + gem_writel(macb, UR, 0); +#else #if defined(CONFIG_RGMII) || defined(CONFIG_RMII) gem_writel(macb, UR, GEM_BIT(RGMII)); #else gem_writel(macb, UR, 0); #endif +#endif } else { /* choose RMII or MII mode. This depends on the board */ +#ifdef CONFIG_DM_ETH +#ifdef CONFIG_AT91FAMILY + if (macb->phy_interface == PHY_INTERFACE_MODE_RMII) { + macb_writel(macb, USRIO, + MACB_BIT(RMII) | MACB_BIT(CLKEN)); + } else { + macb_writel(macb, USRIO, MACB_BIT(CLKEN)); + } +#else + if (macb->phy_interface == PHY_INTERFACE_MODE_RMII) +
Re: [U-Boot] [PATCH 2/8] sun8i: Add CCI-400 definitions
Hi, On Tue, May 17, 2016 at 10:38 AM,wrote: A commit message would be nice. > Signed-off-by: Timothy Pearson > --- > arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > index 65c0441..76da00f 100644 > --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > @@ -18,6 +18,9 @@ > #define SUNXI_SRAM_D_BASE 0x0001 /* 4 kiB */ > #define SUNXI_SRAM_B_BASE 0x0002 /* 64 kiB (secure) */ > > +#define SUN8I_CPUXCFG_BASE 0x0170 > +#define SUN8I_CCI400_BASE 0x0179 Please use SUNXI_ prefix. We can potentially add A80 support later on using the same macro names. > + > #define SUNXI_SRAMC_BASE 0x01c0 > #define SUNXI_DRAMC_BASE 0x01c01000 > #define SUNXI_DMA_BASE 0x01c02000 > @@ -168,6 +171,10 @@ > #define SUNXI_SS_BOND_ID_A31 4 > #define SUNXI_SS_BOND_ID_A31S 5 > > +#define CCI400_DVM_MESSAGE_REQ_EN 0x0002 > +#define CCI400_SNOOP_REQ_EN0x0001 > +#defineCCI400_SHAORD_NON_SHAREABLE 0x0002 _SHA_ORD_ would be better as the original name is "Shareable Override Register". > + CCI-400 is a standard IP block from ARM. Please move the definitions to a separate, shared header, preferably under arch/arm/include/asm/. ChenYu > #ifndef __ASSEMBLY__ > void sunxi_board_init(void); > void sunxi_reset(void); > -- > 2.8.0.rc3 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: rmobile: Fix HDMI output for BLANCHE board
This commit fixes HDMI output for BLANCHE board Signed-off-by: Masakazu Mochizuki--- board/renesas/blanche/blanche.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/board/renesas/blanche/blanche.c b/board/renesas/blanche/blanche.c index 717c169..b2e2e3b 100644 --- a/board/renesas/blanche/blanche.c +++ b/board/renesas/blanche/blanche.c @@ -36,8 +36,23 @@ struct pin_db { }; #definePMMR0xE606 +#defineGPSR0 0xE6060004 +#defineGPSR1 0xE6060008 +#defineGPSR4 0xE6060014 +#defineGPSR5 0xE6060018 +#defineGPSR6 0xE606001C +#defineGPSR7 0xE6060020 +#defineGPSR8 0xE6060024 +#defineGPSR9 0xE6060028 #defineGPSR10 0xE606002C +#defineGPSR11 0xE6060030 +#defineIPSR6 0xE6060058 +#definePUPR2 0xE6060108 #definePUPR3 0xE606010C +#definePUPR4 0xE6060110 +#definePUPR5 0xE6060114 +#definePUPR7 0xE606011C +#definePUPR9 0xE6060124 #definePUPR10 0xE6060128 #definePUPR11 0xE606012C @@ -56,11 +71,26 @@ struct pin_db { } struct pin_db pin_guard[] = { + { GPSR0,0x, 0x0BFF }, + { GPSR1,0x, 0x002F }, + { GPSR4,0x, 0x0FFF }, + { GPSR5,0x, 0x00010FFF }, + { GPSR6,0x, 0x00010FFF }, + { GPSR7,0x, 0x00010FFF }, + { GPSR8,0x, 0x00010FFF }, + { GPSR9,0x, 0x00010FFF }, { GPSR10, 0x, 0x04006000 }, + { GPSR11, 0x, 0x303FEFE0 }, + { IPSR6,0x, 0x0002000E }, }; struct pin_db pin_tbl[] = { + { PUPR2,0x, 0x }, { PUPR3,0x, 0x0803FF40 }, + { PUPR4,0x, 0x }, + { PUPR5,0x, 0x00010FFF }, + { PUPR7,0x, 0x0001AFFF }, + { PUPR9,0x, 0x0001CFFF }, { PUPR10, 0x, 0xC0438001 }, { PUPR11, 0x, 0x0FC7 }, }; -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/25] exynos: video: Convert exynos LCD driver to use driver model
Hi, On 17/05/16 13:22, Jaehoon Chung wrote: > Hi Simon. > > On 05/15/2016 06:22 AM, Simon Glass wrote: >> Hi Jaehoon, >> >> On 13 May 2016 at 07:09, Jaehoon Chungwrote: >>> Hi Simon, >>> >>> On 05/09/2016 08:00 PM, Minkyu Kang wrote: Hi Jaehoon, On 08/05/16 06:25, Simon Glass wrote: > Hi, > > On 1 March 2016 at 18:51, Minkyu Kang wrote: >> Hi, >> >> On 29/02/16 16:18, Jaehoon Chung wrote: >>> Hi, >>> >>> On 02/29/2016 01:23 PM, Simon Glass wrote: Hi, On 23 February 2016 at 05:04, Minkyu Kang wrote: > Dear Simon Glass, > > On 23/02/16 15:42, Simon Glass wrote: >> Hi Minkyu, >> >> On 21 February 2016 at 21:08, Simon Glass wrote: >>> >>> This series converts the exynos LCD driver to work with driver >>> model. Only >>> the eDP display is converted - the MIPI display is left mostly >>> alone as I >>> do not have a device to test with. >>> >>> The conversion involves some refactoring to simplify the code, >>> reduce the >>> amount of global/static data and allow boards to be built without >>> LCD >>> support. >>> >>> The series is tested with snow, spring, pit and pi. It disables LCD >>> on other >>> exynos boards so that they will still build with these changes. >>> Further work >>> will be needed (by someone with a board) to convert the others. I >>> am not >>> sure when this series can be applied. >>> >>> The series also brings in device tree features from Linux v4.4. It >>> would be >>> useful to do a full sync with the kernel on these files, but this >>> is really >>> a job for the Samsung maintainer :-) >>> >>> The series is available at u-boot-dm/rkg-working. >>> >>> Changes in v2: >>> - Rebase to master >>> - Rebase to master >>> >> >> What do you think we should do about applying this series? >> > > Although we have to do remaining work, I think applying is possible > without next work. > > Board maintainers, what do you think? > > Remaining Work: > - MIPI display driver > - s5pc210_universal > - smdk5420 > - smdk5250 > - trats > - trats2 > > Thanks, > Minkyu Kang. Well, no replies as yet. The main work requires is MIPI, but as I don't have the hardware, I can't help with that. At least I have made sure that everything builds OK. >>> >>> Sorry for late..I will check these patches on this week..Tomorrow is >>> holiday.. >>> So I can check from Wed. >> >> Thank you, Jaehoon. > > It has been a few months now - if you like I can apply these via the -dm > tree. >>> >>> Yep, I checked these..It needs to remain the future work. >>> But it seems that it's not problem to apply at -dm repository. >>> (I have checked with your patch on other boadrs.) >>> >>> I needs to check one more things..Could you wait until next Tuesday? >>> >> >> Sure, it's been 3 months so another week won't matter :-) > > Sorry. I have checked more with these patches..We have to work too many > things in future for remaining work. > But it seems those task are our role..If you and Minkyu are ok, you can apply > these at dm repository. I'm OK. If you want, those can be merged to samsung tree. > > I will make a plan to work. (Based on your repository.) > > Actually, i didn't follow a few month, so i'm looking for u-boot history. > Sorry. :( > If you want to add my Reviewed-by tag, then you can add. > > In future work, > Change to driver model for above targets. (trats2/trats...) > MIPI display driver..(I will assign to my colleague for this task.) > Thank you! Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8] sunxi: Add optional logic to start cluster 1 and the associated CCI-400 ports
Signed-off-by: Timothy Pearson--- arch/arm/include/asm/arch-sunxi/prcm.h | 3 ++- board/sunxi/board.c| 49 ++ 2 files changed, 51 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h b/arch/arm/include/asm/arch-sunxi/prcm.h index 556c1af..9e8a367 100644 --- a/arch/arm/include/asm/arch-sunxi/prcm.h +++ b/arch/arm/include/asm/arch-sunxi/prcm.h @@ -219,7 +219,8 @@ struct sunxi_prcm_reg { u32 clk_outd; /* 0x0f0 */ u8 res6[0xc]; /* 0x0f4 */ u32 cpu_pwroff; /* 0x100 */ - u8 res7[0xc]; /* 0x104 */ + u32 cluster1_cpu_pwr; /* 0x104 */ + u8 res7[0x8]; /* 0x108 */ u32 vdd_sys_pwroff; /* 0x110 */ u8 res8[0x4]; /* 0x114 */ u32 gpu_pwroff; /* 0x118 */ diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 3cf3614..65029ab 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #ifndef CONFIG_ARM64 #include @@ -30,6 +31,18 @@ #include #include +/* CCI-400 registers */ +struct cci400_control { + uint32_t unused0[0x3]; + uint32_t status; + uint32_t unused1[0xffc]; + uint32_t snoop_ctrl_a7; + uint32_t sha_ord_a7; + uint32_t unused2[0x3fe]; + uint32_t snoop_ctrl_a15; + uint32_t sha_ord_a15; +}; + #if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD) /* So that we can use pin names in Kconfig and sunxi_name_to_gpio() */ int soft_i2c_gpio_sda; @@ -122,6 +135,42 @@ int board_init(void) gpio_direction_output(CONFIG_MACPWR, 1); #endif +#ifdef CONFIG_ENABLE_CLUSTER_1 +struct sunxi_prcm_reg *prcm = + (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE; + clrbits_le32(>cluster1_cpu_pwr, 0x1); +#endif + +#ifdef CONFIG_ENABLE_CCI400_SNOOP_CLUSTERS_0_1 + printf("Enabling snoop controls..."); + struct cci400_control *cci = (struct cci400_control *)SUN8I_CCI400_BASE; + uint32_t snoop_ctl; + + /* Set up cluster 0 CCI port */ + snoop_ctl = readl(>snoop_ctrl_a7); + snoop_ctl |= CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN; + writel(snoop_ctl, >snoop_ctrl_a7); + + /* Wait for snoop control change to take effect */ + while (readl(>status) & 0x1); + + /* Set up cluster 1 CCI port */ + snoop_ctl = readl(>snoop_ctrl_a15); + snoop_ctl |= CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN; + writel(snoop_ctl, >snoop_ctrl_a15); + + /* Wait for snoop control change to take effect */ + while (readl(>status) & 0x1); + + /* Force non-sharable memory */ + writel(CCI400_SHAORD_NON_SHAREABLE, >sha_ord_a7); + writel(CCI400_SHAORD_NON_SHAREABLE, >sha_ord_a15); + + /* Synchronize CCI enable */ + __asm__ volatile ("dsb\n"); + printf("done!\n"); +#endif + /* Uses dm gpio code so do this here and not in i2c_init_board() */ return soft_i2c_board_init(); } -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] a83t: Enable PSCI, non-secure mode, and cluster / cache setup
Signed-off-by: Timothy Pearson--- board/sunxi/Kconfig | 13 + 1 file changed, 13 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index fa78720..4b82d3d 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -85,8 +85,13 @@ config MACH_SUN50I config MACH_SUN8I_A83T bool "sun8i (Allwinner A83T)" select CPU_V7 + select CPU_V7_HAS_NONSEC + select CPU_V7_HAS_VIRT select SUNXI_GEN_SUN6I select SUPPORT_SPL + select ENABLE_CLUSTER_1 + select ENABLE_CCI400_SNOOP_CLUSTERS_0_1 + select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT config MACH_SUN9I bool "sun9i (Allwinner A80)" @@ -623,4 +628,12 @@ config SPL_STACK_R_ADDR default 0x4fe0 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN7I || MACH_SUN8I || MACH_SUN50I default 0x2fe0 if MACH_SUN9I +config ENABLE_CLUSTER_1 + bool + default n + +config ENABLE_CCI400_SNOOP_CLUSTERS_0_1 + bool + default n + endif -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] sun8i: Enable PSCI cpu_on support for A83t
Signed-off-by: Timothy Pearson--- arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 174 -- 1 file changed, 164 insertions(+), 10 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S index d35b63e..b3090ec 100644 --- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S +++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S @@ -21,6 +21,7 @@ #include #include +#include #include #include #include @@ -45,6 +46,16 @@ #defineGICD_BASE 0x1c81000 #defineGICC_BASE 0x1c82000 +@ Attempts to condense sparse ID space on multi-cluster systems to dense ID space +ENTRY(psci_get_cpu_id) + mrc p15, 0, r0, c0, c0, 5 /* read MPIDR */ + lsr r1, r0, #6 /* extract cluster offset */ + and r1, r1, #0xff + and r0, r0, #0xff /* extract CPU ID in cluster */ + add r0, r0, r1 /* return adjusted CPU ID */ + bx lr +ENDPROC(psci_get_cpu_id) + .globl psci_fiq_enter psci_fiq_enter: push{r0-r12} @@ -106,7 +117,7 @@ psci_fiq_enter: str r10, [r8, #0x100] timer_wait r10, ONE_MS -#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I_H3) +#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN8I_A83T) @ Activate power clamp lsl r12, r9, #2 @ x4 add r12, r12, r8 @@ -134,7 +145,13 @@ out: mcr p15, 0, r7, c1, c1, 0 psci_cpu_on: push{lr} - mov r0, r1 +#if defined(CONFIG_MACH_SUN8I_A83T) + lsr r3, r1, #6 @ extract cluster offset + and r0, r1, #3 @ extract CPU number + add r0, r0, r3 @ pass adjusted CPU number to setup +#else + mov r0, r1 @ pass CPU number to setup +#endif bl psci_get_cpu_stack_top @ get stack top of target CPU str r2, [r0]@ store target PC at stack top dsb @@ -142,15 +159,74 @@ psci_cpu_on: movwr0, #(SUN6I_CPUCFG_BASE & 0x) movtr0, #(SUN6I_CPUCFG_BASE >> 16) + ldr r6, =psci_cpu_entry + str r6, [r0, #0x1a4] @ PRIVATE_REG (boot vector) + @ CPU mask +#if defined(CONFIG_MACH_SUN8I_A83T) + lsr r3, r1, #8 @ extract cluster number + and r1, r1, #3 @ extract CPU number + + @ obtain silicon revision level + movwr0, #(SUNXI_SRAMC_BASE & 0x) + movtr0, #(SUNXI_SRAMC_BASE >> 16) + ldr r2, [r0, #0x24] + and r2, r2, #0x1 +#else + ldr r3, #0 @ only one cluster and r1, r1, #3 @ only care about first cluster + ldr r2, #0 @ default revision +#endif mov r4, #1 lsl r4, r4, r1 - ldr r6, =psci_cpu_entry - str r6, [r0, #0x1a4] @ PRIVATE_REG (boot vector) - @ Assert reset on target CPU +#if defined(CONFIG_MACH_SUN8I_A83T) + movwr0, #(SUN8I_CPUXCFG_BASE & 0x) + movtr0, #(SUN8I_CPUXCFG_BASE >> 16) + + lsl r5, r3, #2 @ cluster offset + add r5, r5, #0x80 @ SUNXI_CPU_RST_CTRL + ldr r6, [r0, r5] + bic r6, r6, r4 @ assert reset + str r6, [r0, r5] + + cmp r1, #0 + bne skip_cluster_reset_assert + + lsl r5, r3, #4 @ cluster offset + add r5, r5, #0x04 @ SUNXI_CLUSTER_CTRL1 + ldr r6, [r0, r5] + orr r6, r6, #0x1@ assert ACINACTM + str r6, [r0, r5] + + lsl r5, r3, #2 @ cluster offset + add r5, r5, #0x80 @ SUNXI_CPU_RST_CTRL + ldr r6, [r0, r5] + bic r6, r6, #0x1000 @ assert HRESET + bic r6, r6, #0x100 @ assert L2 cache reset + str r6, [r0, r5] +skip_cluster_reset_assert: + + @ re-calculate CPU control register address + movwr0, #(SUN6I_CPUCFG_BASE & 0x) + movtr0, #(SUN6I_CPUCFG_BASE >> 16) + + lsl r5, r3, #2 @ cluster offset + add r5, r5, #0x30 @ SUNXI_CLUSTER_PWRON_RESET + ldr r6, [r0, r5] + bic r6, r6, r4 @ assert reset + str r6, [r0, r5] + + movwr0, #(SUN8I_CPUXCFG_BASE & 0x) + movtr0, #(SUN8I_CPUXCFG_BASE >> 16) + + @ l1 invalidate + lsl r5, r3, #4 @ calculate cluster offset + ldr r6, [r0, r5]@ CX_CTRL_REG0 + bic r6, r6, r4 + str r6, [r0, r5] +#else mov r6, #0 lsl r5, r1, #6 @ 64 bytes per CPU add r5, r5, #0x40 @ Offset from base @@ -166,32 +242,109 @@ psci_cpu_on: ldr r6, [r0, #0x1e4] @ CPUCFG_DBG_CTL1_REG bic r6, r6, r4 str r6, [r0, #0x1e4] +#endif movwr0, #(SUNXI_PRCM_BASE & 0x) movtr0, #(SUNXI_PRCM_BASE >> 16)
[U-Boot] [PATCH 5/8] sun8i: Display silicon revision of A83t processors
Signed-off-by: Timothy Pearson--- arch/arm/mach-sunxi/cpu_info.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c index 76b6719..d552061 100644 --- a/arch/arm/mach-sunxi/cpu_info.c +++ b/arch/arm/mach-sunxi/cpu_info.c @@ -50,6 +50,17 @@ uint sunxi_get_sram_id(void) return id; } + +uint sunxi_get_revision(void) +{ + uint rev; + + /* Unlock sram info reg, read it, relock */ + rev = readl(SUNXI_SRAMC_BASE + 0x24) & 0x1; + + return rev; +} + #endif #ifdef CONFIG_DISPLAY_CPUINFO @@ -84,7 +95,7 @@ int print_cpuinfo(void) #elif defined CONFIG_MACH_SUN8I_A33 printf("CPU: Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id()); #elif defined CONFIG_MACH_SUN8I_A83T - printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id()); + printf("CPU: Allwinner A83T (SUN8I %04x rev. %s)\n", sunxi_get_sram_id(), (sunxi_get_revision() == 0)?"A":"B"); #elif defined CONFIG_MACH_SUN8I_H3 printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id()); #elif defined CONFIG_MACH_SUN9I -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] sun8i: Add A83t SMP definitions
Signed-off-by: Timothy Pearson--- include/configs/sun8i.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h index b9a8731..b239548 100644 --- a/include/configs/sun8i.h +++ b/include/configs/sun8i.h @@ -26,7 +26,6 @@ #define CONFIG_SUNXI_USB_PHYS 2 #endif -#ifndef CONFIG_MACH_SUN8I_A83T #define CONFIG_ARMV7_PSCI 1 #if defined(CONFIG_MACH_SUN8I_A23) #define CONFIG_ARMV7_PSCI_NR_CPUS 2 @@ -34,10 +33,12 @@ #define CONFIG_ARMV7_PSCI_NR_CPUS 4 #elif defined(CONFIG_MACH_SUN8I_H3) #define CONFIG_ARMV7_PSCI_NR_CPUS 4 +#elif defined(CONFIG_MACH_SUN8I_A83T) +#define CONFIG_ARMV7_PSCI_NR_CPUS 8 +#define CONFIG_ARMV7_SECURE_BASE SUNXI_SRAM_B_BASE #else #error Unsupported sun8i variant #endif -#endif /* * Include common sunxi configuration where most the settings are -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] [PATCH 0/8] a83t: Add initial PSCI / SMP support
This is an intial series aimed at getting non-secure mode for virtualization to work on the Allwinner A83t devices. This series adds PSCI support along with a few other other low-level initialization routines and boots the mainline kernel enough to detect 8 started SMP cores / threads. Unfortunately the mainline kernel appears to have other issues with timers so this could not be tested further, however it is hoped that with proper u-boot PSCI support the kernel developers will be able to work on SMP support for these SoCs. This is a first rough draft; in particular the WFI PSCI state has not been updated for the new device. Comments on the overall approach are welcome! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] sun8i: Add TZPC setup for A83t
Signed-off-by: Timothy Pearson--- arch/arm/cpu/armv7/sunxi/Makefile | 1 + arch/arm/cpu/armv7/sunxi/tzpc.c| 10 ++ arch/arm/include/asm/arch-sunxi/tzpc.h | 10 ++ arch/arm/mach-sunxi/board.c| 2 +- 4 files changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile index 4d2274a..4dd449b 100644 --- a/arch/arm/cpu/armv7/sunxi/Makefile +++ b/arch/arm/cpu/armv7/sunxi/Makefile @@ -11,6 +11,7 @@ obj-y += timer.o obj-$(CONFIG_MACH_SUN6I) += tzpc.o obj-$(CONFIG_MACH_SUN8I_H3)+= tzpc.o +obj-$(CONFIG_MACH_SUN8I_A83T) += tzpc.o ifndef CONFIG_SPL_BUILD ifdef CONFIG_ARMV7_PSCI diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c index 6c8a0fd..7723853 100644 --- a/arch/arm/cpu/armv7/sunxi/tzpc.c +++ b/arch/arm/cpu/armv7/sunxi/tzpc.c @@ -24,4 +24,14 @@ void tzpc_init(void) writel(SUN8I_H3_TZPC_DECPORT1_ALL, >decport1_set); writel(SUN8I_H3_TZPC_DECPORT2_ALL, >decport2_set); #endif + +#ifdef SUN8I_A83T_TZPC_DECPORT0_ALL + /* Emable non-secure access to RAM */ + writel(R0SIZE, >r0size); + + /* Enable non-secure access to all peripherals */ + writel(SUN8I_A83T_TZPC_DECPORT0_ALL, >decport0_set); + writel(SUN8I_A83T_TZPC_DECPORT1_ALL, >decport1_set); + writel(SUN8I_A83T_TZPC_DECPORT2_ALL, >decport2_set); +#endif } diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h b/arch/arm/include/asm/arch-sunxi/tzpc.h index 95c55cd..bcf0713 100644 --- a/arch/arm/include/asm/arch-sunxi/tzpc.h +++ b/arch/arm/include/asm/arch-sunxi/tzpc.h @@ -29,6 +29,16 @@ struct sunxi_tzpc { #define SUN8I_H3_TZPC_DECPORT1_ALL 0xff #define SUN8I_H3_TZPC_DECPORT2_ALL 0x7f +#define SUN8I_A83T_TZPC_DECPORT0_ALL 0xbe +#define SUN8I_A83T_TZPC_DECPORT1_ALL 0x7f +#define SUN8I_A83T_TZPC_DECPORT2_ALL 0x10 + +/* + * TZPC Register Value : + * R0SIZE: 0x10 : Size of secured ram (64Kib) + */ +#define R0SIZE 0x10 + void tzpc_init(void); #endif /* _SUNXI_TZPC_H */ diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 20149da..4e0f7f9 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -183,7 +183,7 @@ void s_init(void) "orr r0, r0, #1 << 6\n" "mcr p15, 0, r0, c1, c0, 1\n"); #endif -#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 +#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 || defined CONFIG_MACH_SUN8I_A83T /* Enable non-secure access to some peripherals */ tzpc_init(); #endif -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] sun8i: Add CCI-400 definitions
Signed-off-by: Timothy Pearson--- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h index 65c0441..76da00f 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h @@ -18,6 +18,9 @@ #define SUNXI_SRAM_D_BASE 0x0001 /* 4 kiB */ #define SUNXI_SRAM_B_BASE 0x0002 /* 64 kiB (secure) */ +#define SUN8I_CPUXCFG_BASE 0x0170 +#define SUN8I_CCI400_BASE 0x0179 + #define SUNXI_SRAMC_BASE 0x01c0 #define SUNXI_DRAMC_BASE 0x01c01000 #define SUNXI_DMA_BASE 0x01c02000 @@ -168,6 +171,10 @@ #define SUNXI_SS_BOND_ID_A31 4 #define SUNXI_SS_BOND_ID_A31S 5 +#define CCI400_DVM_MESSAGE_REQ_EN 0x0002 +#define CCI400_SNOOP_REQ_EN0x0001 +#defineCCI400_SHAORD_NON_SHAREABLE 0x0002 + #ifndef __ASSEMBLY__ void sunxi_board_init(void); void sunxi_reset(void); -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] sun8i: Extend stack size to allow for up to 8 CPUs
--- arch/arm/cpu/armv7/psci.S | 1 + arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 4 ++-- arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S index 87c0c0b..18a0cc2 100644 --- a/arch/arm/cpu/armv7/psci.S +++ b/arch/arm/cpu/armv7/psci.S @@ -203,6 +203,7 @@ ENTRY(psci_get_cpu_stack_top) add r5, r5, #0x2000 @ Skip two pages lsr r5, r5, #12 @ Align to start of page lsl r5, r5, #12 + add r5, r5, #0x1000 @ Skip an additional page sub r5, r5, #4 @ reserve 1 word for target PC sub r0, r5, r0 @ here's our stack! diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S index 90b5bfd..d35b63e 100644 --- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S +++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S @@ -32,8 +32,8 @@ * ._secure_text section * text_end to ALIGN_PAGE(text_end): * nothing - * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000) - * 1kB of stack per CPU (4 CPUs max). + * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000) + * 1kB of stack per CPU (8 CPUs max). */ .pushsection ._secure.text, "ax" diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S index e15d587..b8ac50e 100644 --- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S +++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S @@ -32,8 +32,8 @@ * ._secure_text section * text_end to ALIGN_PAGE(text_end): * nothing - * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000) - * 1kB of stack per CPU (4 CPUs max). + * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000) + * 1kB of stack per CPU (8 CPUs max). */ .pushsection ._secure.text, "ax" -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> From: Alexander Graf [mailto:ag...@suse.de] > Sent: Monday, May 16, 2016 7:21 AM > To: Bhupesh Sharma; Amit Tomer > > Cc: york sun ; u-boot@lists.denx.de; Peter Newton > > Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot > > > > On 16.05.16 14:04, Bhupesh Sharma wrote: > > > > > >> -Original Message- > >> From: Alexander Graf [mailto:ag...@suse.de] > >> Sent: Monday, May 16, 2016 1:09 PM > >> To: Amit Tomer > >> Cc: Bhupesh Sharma ; york sun > >> ; u-boot@lists.denx.de; Peter Newton > >> > >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot > >> > >> > >> > >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer : > >>> > On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma > >> wrote: > Note that UEFI firmware support is already available on LS2080A-RDB > and allows Booting distributions like CentOS on the same. > >>> > >>> Sorry to intervene here but it's about having the EFI support inside > >>> u-boot itself that may *not* required to have separate UEFI firmware > >>> to boot various distributions. > >>> > >>> Please correct, if it's not right ? > >> > >> It's correct. The idea is to allow everyone to boot using the uEFI > >> entry point in Linux (or any other OS), regardless of whether they > >> want to run U-Boot or a TianoCore based formware. > >> > >> This might seem useless today for embedded use cases, but some > >> features are only available via an EFI entry, such as kASLR. You can > >> also invoke Linux directly using the "bootefi" command, as Linux is > >> an EFI binary itself. That way the boot path doesn't become much > >> longer than with booti today. > >> > > > > The default firmware being offered by NXP to boot distros on LS2080A and > > variants is UEFI. > > > > EFI application support in u-boot doesn't present a solution to things > > like run-time variable/service support that is required by distros to > > update firmware components on the go. And there are several other > > services being offered by UEFI to help distro boot e.g. secure uefi boot > > through x.509 certifications compliant to UEFI specifications. > > Don't get me wrong - I think it's great if there is a TianoCore based > firmware for LS2080A. But I didn't get the impression that there is a > TianoCore based firmware for every NXP SoC out there, so enabling all of them > to use the U-Boot provided uEFI implementation is still > a win. > > That said, there's nothing that keeps us from implementing the bits you > mentioned in U-Boot either. There is support for RTS in U- > Boot, we just didn't convert any drivers (RTC comes to mind first) yet. > > There's also no support for uEFI environment variables, but mostly because > most systems I've used this code on so far just didn't have > any storage to put them. > > Certification checks also shouldn't be an issue if someone cared enough about > them. > > But I don't think we need a discussion of TianoCore vs U-Boot. What everyone > really wants is to have things "just work". And some > customers just prefer U-Boot for various reasons that are outside of my > control. > If they can run the same boot path as everyone else, it makes life for me as > distribution vendor easier. And unlike other people in the > community, I don't think being a TianoCore+ACPI messiah is any helpful for > that goal. Agreed, this should not become a U-Boot vs UEFI thread. And just to be sure it is clear to everyone, NXP currently offers both U-Boot and is starting to have UEFI firmware releases also. We are not dropping U-Boot just because we begin to have UEFI. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Altera Cyclone 5 UART Communication Issues - U-Boot 2016.03
Hello All, I'm currently running U-Boot 2016.03 on a Terasic SoC Kit without any apparent issues. However, when I go to run the same build on our custom board, the debug port's UART0 RXD fails to receive any key presses when I'm attempting to stop autoboot. On both boards, the debug UART0 TX and RX lines are using the same pins for. The only difference between the boards is that our custom board is routing the UART TX and RX lines through the FPGA fabric. I'm making sure to start up the FPGA with these few additional lines in the boot sequence: #fatload mmc 0:${mmcloadpart} 0x200 soc_system.rbf; fpga load 0 0x200 0x23C1B4; I can tell that the FPGA does seem to be running fine, as the UART TX is coming through (I see all the proper boot info) and an FPGA controlled heartbeat LED starts blinking. Does anyone have any insight into what could be going on? Thank you, Nathan Barrett confidentiality: This e-mail and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this e- mail and highlight the error. Security Warning: Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] askenv with timeout?
Hi everyone, Recently I got the need to read some environment variable from stdin, as user input. So, I discovered the 'askenv' command. One additional requirement I have is avoiding any blocking behavior, which would be possible if askenv supported the timeout concept. However, it doesn't seem to be the case in the 'do_env_ask' function. Here follow some questions: - Will there be a timeout option for askenv in future? - What is the closest alternative right now (I believe some 'echo' statements combined with 'bootdelay')? Thanks for your time. Best regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] scsi: add PCIe to sata converter Marvell chip 88SE9170
> -Original Message- > From: York Sun [mailto:york@nxp.com] > Sent: Tuesday, May 17, 2016 12:03 AM > To: Po Liu > Cc: u-boot@lists.denx.de; Simon Glass; Bin Meng; o...@andrep.de; > mark.langsd...@gmail.com > Subject: Re: [PATCH 1/2] scsi: add PCIe to sata converter Marvell chip > 88SE9170 > > On 04/13/2016 04:09 AM, Po Liu wrote: > > Add to the command scsi device list. > > > > Signed-off-by: Po Liu> > --- > > cmd/scsi.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/cmd/scsi.c b/cmd/scsi.c > > index 8991125..c85fefc 100644 > > --- a/cmd/scsi.c > > +++ b/cmd/scsi.c > > @@ -31,6 +31,11 @@ > > #define SCSI_VEND_ID 0x10b9 > > #define SCSI_DEV_ID 0x5288 > > > > +#elif defined CONFIG_SATA_88SE9170 > > + > > +#define SCSI_VEND_ID 0x1b4b > > +#define SCSI_DEV_ID 0x9170 > > + > > #elif !defined(CONFIG_SCSI_AHCI_PLAT) #error no scsi device defined > > #endif > > > > Po, > > Would it be a better idea to define CONFIG_SCSI_DEV_LIST in your board > header > file? You can merge your two patches into one. Ok, Understand. > > York > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/25] exynos: video: Convert exynos LCD driver to use driver model
Hi Simon. On 05/15/2016 06:22 AM, Simon Glass wrote: > Hi Jaehoon, > > On 13 May 2016 at 07:09, Jaehoon Chungwrote: >> Hi Simon, >> >> On 05/09/2016 08:00 PM, Minkyu Kang wrote: >>> Hi Jaehoon, >>> >>> On 08/05/16 06:25, Simon Glass wrote: Hi, On 1 March 2016 at 18:51, Minkyu Kang wrote: > Hi, > > On 29/02/16 16:18, Jaehoon Chung wrote: >> Hi, >> >> On 02/29/2016 01:23 PM, Simon Glass wrote: >>> Hi, >>> >>> On 23 February 2016 at 05:04, Minkyu Kang wrote: Dear Simon Glass, On 23/02/16 15:42, Simon Glass wrote: > Hi Minkyu, > > On 21 February 2016 at 21:08, Simon Glass wrote: >> >> This series converts the exynos LCD driver to work with driver >> model. Only >> the eDP display is converted - the MIPI display is left mostly alone >> as I >> do not have a device to test with. >> >> The conversion involves some refactoring to simplify the code, >> reduce the >> amount of global/static data and allow boards to be built without LCD >> support. >> >> The series is tested with snow, spring, pit and pi. It disables LCD >> on other >> exynos boards so that they will still build with these changes. >> Further work >> will be needed (by someone with a board) to convert the others. I am >> not >> sure when this series can be applied. >> >> The series also brings in device tree features from Linux v4.4. It >> would be >> useful to do a full sync with the kernel on these files, but this is >> really >> a job for the Samsung maintainer :-) >> >> The series is available at u-boot-dm/rkg-working. >> >> Changes in v2: >> - Rebase to master >> - Rebase to master >> > > What do you think we should do about applying this series? > Although we have to do remaining work, I think applying is possible without next work. Board maintainers, what do you think? Remaining Work: - MIPI display driver - s5pc210_universal - smdk5420 - smdk5250 - trats - trats2 Thanks, Minkyu Kang. >>> >>> Well, no replies as yet. The main work requires is MIPI, but as I >>> don't have the hardware, I can't help with that. At least I have made >>> sure that everything builds OK. >> >> Sorry for late..I will check these patches on this week..Tomorrow is >> holiday.. >> So I can check from Wed. > > Thank you, Jaehoon. It has been a few months now - if you like I can apply these via the -dm tree. >> >> Yep, I checked these..It needs to remain the future work. >> But it seems that it's not problem to apply at -dm repository. >> (I have checked with your patch on other boadrs.) >> >> I needs to check one more things..Could you wait until next Tuesday? >> > > Sure, it's been 3 months so another week won't matter :-) Sorry. I have checked more with these patches..We have to work too many things in future for remaining work. But it seems those task are our role..If you and Minkyu are ok, you can apply these at dm repository. I will make a plan to work. (Based on your repository.) Actually, i didn't follow a few month, so i'm looking for u-boot history. Sorry. :( If you want to add my Reviewed-by tag, then you can add. In future work, Change to driver model for above targets. (trats2/trats...) MIPI display driver..(I will assign to my colleague for this task.) Best Regards, Jaehoon Chung > > >> >> Best Regards, >> Jaehoon Chung >> >>> >>> any progress? >>> >>> Thanks, >>> Minkyu Kang. >>> >> > > Regards, > Simon > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] board: am335x: Allow to choose serial device dynamically
On 5/17/2016 6:11 AM, Tom Rini wrote: On Mon, May 16, 2016 at 11:47:29AM +0530, Lokesh Vutla wrote: Different AM335x based platforms have different serial consoles. As serial console is Kconfig option a separate defconfig has to be created for each platform. So pass the serial device dynamically. Signed-off-by: Lokesh Vutla--- Changes since v1: - New patch. board/ti/am335x/board.c | 11 +++ include/serial.h| 4 2 files changed, 15 insertions(+) diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c index ff52314..56f4984 100644 --- a/board/ti/am335x/board.c +++ b/board/ti/am335x/board.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -59,6 +60,16 @@ static inline int __maybe_unused read_eeprom(void) return ti_i2c_eeprom_am_get(-1, CONFIG_SYS_I2C_EEPROM_ADDR); } +#ifndef CONFIG_DM_SERIAL +struct serial_device *default_serial_console(void) +{ + if (board_is_icev2()) + return _device; + else + return _device; +} +#endif + #ifndef CONFIG_SKIP_LOWLEVEL_INIT static const struct ddr_data ddr2_data = { .datardsratio0 = MT47H128M16RT25E_RD_DQS, ... so in the DM case we're already handling this correctly? Can't we With DM+DT we are handling it correctly which is only in U-Boot. This part of code is meant for only SPL(DM_* is not yet enabled in SPL). Thanks and regards, Lokesh just say that ICEv2 is only supported with DM enabled so that we don't need to add compat code that we'll remove rather soon (I hope..) ? Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot
Hi York, > -Original Message- > From: York Sun [mailto:york@nxp.com] > Sent: Tuesday, May 17, 2016 12:47 AM > To: Qianyu Gong; u-boot@lists.denx.de; > o...@buserror.net > Cc: Mingkai Hu > Subject: Re: [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is > avaliable in U- > Boot > > On 04/27/2016 11:19 PM, Gong Qianyu wrote: > > IFC is considered as a required component in Layerscape platforms' Linux. > > But if IFC is not enabled in U-Boot on some boards, accessing IFC > > memory space would cause kernel call trace. So disable IFC node in such > > cases. > > > > Signed-off-by: Gong Qianyu > > --- > > V2: > > - Revised the title and message. > > - Used #ifndef CONFIG_FSL_IFC rather than #ifdef CONFIG_FSL_QSPI. > > > > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > index 1e875c4..96dab56 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > > @@ -98,4 +98,9 @@ void ft_cpu_setup(void *blob, bd_t *bd) #ifdef > > CONFIG_SYS_DPAA_FMAN > > fdt_fixup_fman_firmware(blob); > > #endif > > + > > +#ifndef CONFIG_FSL_IFC > > + do_fixup_by_compat(blob, "fsl,ifc", > > + "status", "disabled", 8 + 1, 1); #endif > > } > > > > Qianyu, > > For the platforms you are testing, is IFC disabled/enabled at SoC level (eg. > RCW) or board level (eg. FPGA)? Can you detect if IFC is enabled by checking > registers? > > York For LS1043AQDS, IFC is disabled at board level(at SoC level, only IFC NOR is disabled). Yes, I can detect if IFC is enabled by checking QIXIS registers. Regards, Qianyu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] armv8/ls2080a: configure PMU's PCTBENR to enable WDT
Hi York, I think you can move your code into timer_init() in cpu.c and follow the example of cltbenr. [Yunhui] During the u_boot imamge compiled by using the ls2080ardb_defconfig bootup on ls2080ardb, timer_init() cannot be called ... So maybe cannot move the code to timer_init(). Thanks Yunhui > -Original Message- > From: York Sun [mailto:york@nxp.com] > Sent: Tuesday, May 17, 2016 12:14 AM > To: Yunhui Cui > Cc: u-boot@lists.denx.de; Yunhui Cui; Prabhakar Kushwaha > Subject: Re: [PATCH v3] armv8/ls2080a: configure PMU's PCTBENR to enable > WDT > > On 04/14/2016 08:57 PM, Yunhui Cui wrote: > > From: Yunhui Cui> > > > The SP805-WDT module on LS2080A and LS2085A, requires configuration of > > PMU's PCTBENR register to enable watchdog counter decrement and reset > > signal generation. In order not to affect the sp805wdt driver frame, > > we enable the watchdog clk in advance. > > > > Signed-off-by: Yunhui Cui > > --- > > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 15 +++ > > arch/arm/include/asm/arch-fsl-layerscape/config.h | 4 > > arch/arm/include/asm/arch-fsl-layerscape/soc.h| 1 + > > board/freescale/ls2080aqds/ls2080aqds.c | 2 ++ > > board/freescale/ls2080ardb/ls2080ardb.c | 2 ++ > > 5 files changed, 24 insertions(+) > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > index 0cb0100..c36976d 100644 > > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > > @@ -42,6 +42,21 @@ bool soc_has_aiop(void) > > return false; > > } > > > > +#if defined(CONFIG_LS2080A) > > +/* > > + * In certain Layerscape SoCs, the clock for each core's watchdog > > + * has an enable bit in the PMU Physical Core Time Base Enable > > +Register > > + * (PCTBENR), which allows the watchdog to operate. > > + */ > > +void enable_watchdog_clk(void) > > +{ > > + u32 pmu_val; > > + > > + pmu_val = *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET); > > + *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET) = pmu_val | > > +0xff; } #endif > > + > > #ifdef CONFIG_LS2080A > > /* > > * This erratum requires setting a value to eddrtqcr1 to diff --git > > a/arch/arm/include/asm/arch-fsl-layerscape/config.h > > b/arch/arm/include/asm/arch-fsl-layerscape/config.h > > index 10d17b2..62e4f95 100644 > > --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h > > +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h > > @@ -143,6 +143,10 @@ > > #define CONFIG_ARM_ERRATA_829520 > > #define CONFIG_ARM_ERRATA_833471 > > > > +/* PMU-Physical Core Time Base Enable Register */ > > +#define FSL_PMU_REG_BASE 0x1E3 > > +#define FSL_PMU_PCTBENR_OFFSET 0x8A0 > > + > > #elif defined(CONFIG_LS1043A) > > #define CONFIG_MAX_CPUS4 > > #define CONFIG_SYS_CACHELINE_SIZE 64 > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h > > b/arch/arm/include/asm/arch-fsl-layerscape/soc.h > > index 831d817..bd4a8f1 100644 > > --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h > > +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h > > @@ -91,6 +91,7 @@ void fsl_lsch2_early_init_f(void); #endif > > > > void cpu_name(char *name); > > +void enable_watchdog_clk(void); > > #ifdef CONFIG_SYS_FSL_ERRATUM_A009635 void erratum_a009635(void); > > #endif diff --git a/board/freescale/ls2080aqds/ls2080aqds.c > > b/board/freescale/ls2080aqds/ls2080aqds.c > > index b3bd40a..c109349 100644 > > --- a/board/freescale/ls2080aqds/ls2080aqds.c > > +++ b/board/freescale/ls2080aqds/ls2080aqds.c > > @@ -213,6 +213,8 @@ int board_init(void) > > select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT); > > rtc_enable_32khz_output(); > > > > + enable_watchdog_clk(); > > + > > return 0; > > } > > > > diff --git a/board/freescale/ls2080ardb/ls2080ardb.c > > b/board/freescale/ls2080ardb/ls2080ardb.c > > index fb39af6..7872f1f 100644 > > --- a/board/freescale/ls2080ardb/ls2080ardb.c > > +++ b/board/freescale/ls2080ardb/ls2080ardb.c > > @@ -181,6 +181,8 @@ int board_init(void) > > /* invert AQR405 IRQ pins polarity */ > > out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK); > > > > + enable_watchdog_clk(); > > + > > return 0; > > } > > > > > Yunhui, > > I think you can move your code into timer_init() in cpu.c and follow the > example of cltbenr. > > York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] x86: qemu: rename qemu/acpi_table.c
2016-05-17 8:42 GMT+08:00 Tom Rini: > On Mon, May 16, 2016 at 05:40:16PM +0800, Miao Yan wrote: >> Hi Bin, >> >> 2016-05-13 22:01 GMT+08:00 Bin Meng : >> > Hi Miao, >> > >> > On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: >> >> Rename qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved >> >> to qfw core, this file only contains code for installing e820 table. >> >> >> >> Signed-off-by: Miao Yan >> >> --- >> >> arch/x86/cpu/qemu/Makefile | 3 +-- >> >> arch/x86/cpu/qemu/acpi_table.c | 43 >> >> -- >> >> arch/x86/cpu/qemu/e820.c | 43 >> >> ++ >> > >> > Please use "git mv". >> >> I did use "git mv". I'll double check. > > I believe you need to tell git to work harder to detect renames. You'll > have to do git format-patch --find-copies-harder ... and git send-email > ... rather than just using send-email by itself (or, there's a knob > somewhere I've missed that lets you tweak the rename threshold via the > config file). Thanks Tom, I'll try that. Miao > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] cmd: qfw: remove qemu_fwcfg_free_files()
On Mon, May 16, 2016 at 05:47:43PM +0800, Miao Yan wrote: > 2016-05-14 4:46 GMT+08:00 Tom Rini: > > On Fri, May 13, 2016 at 10:00:05PM +0800, Bin Meng wrote: > >> Hi Miao, > >> > >> On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: > >> > This patch is part of the qfw refactor work. > >> > > >> > The qemu_fwcfg_free_files() function is only used in error handling in > >> > ACPI table generation, let's not make this a core function and move it > >> > to the right place. > >> > > >> > >> But I suspect this API may still be needed in some other scenarioes? > >> eg: for future ARM64 ACPI? > > > > Yes, as it stands currently the code looks likely useful for non-x86 > > QEMU+ACPI. > > ARM64 and x86 should be able to share common ACPI code. As for now, > this function is not used anywhere but error handling in only one > place. I'd prefer not to make this public. Well, OK, I'm not going to argue too too hard here, but if someone duplicates this part of the qemu code since it wasn't in common, it's on you :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] x86: qemu: rename qemu/acpi_table.c
On Mon, May 16, 2016 at 05:40:16PM +0800, Miao Yan wrote: > Hi Bin, > > 2016-05-13 22:01 GMT+08:00 Bin Meng: > > Hi Miao, > > > > On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: > >> Rename qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved > >> to qfw core, this file only contains code for installing e820 table. > >> > >> Signed-off-by: Miao Yan > >> --- > >> arch/x86/cpu/qemu/Makefile | 3 +-- > >> arch/x86/cpu/qemu/acpi_table.c | 43 > >> -- > >> arch/x86/cpu/qemu/e820.c | 43 > >> ++ > > > > Please use "git mv". > > I did use "git mv". I'll double check. I believe you need to tell git to work harder to detect renames. You'll have to do git format-patch --find-copies-harder ... and git send-email ... rather than just using send-email by itself (or, there's a knob somewhere I've missed that lets you tweak the rename threshold via the config file). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] board: am33xx: fit: add support for selecting dtb dynamically
On Mon, May 16, 2016 at 11:24:24AM +0530, Lokesh Vutla wrote: > FIT allows for a multiple dtb in a single image. SPL needs a way to > detect the right dtb to be used. Adding support for the same. > > Signed-off-by: Lokesh VutlaReviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ARM: AM43xx: Enable FIT
On Mon, May 16, 2016 at 11:11:16AM +0530, Lokesh Vutla wrote: > Use a single defconfig for all AM43xx platforms by enabling FIT and delete > the platform specific defconfigs. > > Signed-off-by: Lokesh VutlaReviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] board: am335x: Allow to choose serial device dynamically
On Mon, May 16, 2016 at 11:47:29AM +0530, Lokesh Vutla wrote: > Different AM335x based platforms have different serial consoles. As serial > console is Kconfig option a separate defconfig has to be created for each > platform. So pass the serial device dynamically. > > Signed-off-by: Lokesh Vutla> --- > Changes since v1: > - New patch. > board/ti/am335x/board.c | 11 +++ > include/serial.h| 4 > 2 files changed, 15 insertions(+) > > diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c > index ff52314..56f4984 100644 > --- a/board/ti/am335x/board.c > +++ b/board/ti/am335x/board.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -59,6 +60,16 @@ static inline int __maybe_unused read_eeprom(void) > return ti_i2c_eeprom_am_get(-1, CONFIG_SYS_I2C_EEPROM_ADDR); > } > > +#ifndef CONFIG_DM_SERIAL > +struct serial_device *default_serial_console(void) > +{ > + if (board_is_icev2()) > + return _device; > + else > + return _device; > +} > +#endif > + > #ifndef CONFIG_SKIP_LOWLEVEL_INIT > static const struct ddr_data ddr2_data = { > .datardsratio0 = MT47H128M16RT25E_RD_DQS, ... so in the DM case we're already handling this correctly? Can't we just say that ICEv2 is only supported with DM enabled so that we don't need to add compat code that we'll remove rather soon (I hope..) ? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] ARM: AM335x: Enable FIT
On Mon, May 16, 2016 at 11:24:26AM +0530, Lokesh Vutla wrote: > Use a single defconfig for all AM335x platforms by enabling FIT > > Signed-off-by: Lokesh VutlaReviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] ARM: DRA7: Enable FIT
On Mon, May 16, 2016 at 10:51:24AM +0530, Lokesh Vutla wrote: > Use a single defconfig for all DRA7 platforms by enabling FIT and delete > the platform specific defconfigs. > > Signed-off-by: Lokesh VutlaReviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] mailbox: implement a sandbox test
From: Stephen WarrenThis adds a sandbox mailbox implementation (provider), a test client device, instantiates them both from Sandbox's DT, and adds a DM test that excercises everything. Signed-off-by: Stephen Warren Acked-by: Simon Glass # v1 --- v2: * Share SANDBOX_MBOX_PING_XOR via header file. * Add include guards to header file. * Use UCLASS_MISC not UCLASS_TEST since the latter seems to have some semantics associated with it not desired for this test. --- arch/sandbox/dts/test.dts | 11 arch/sandbox/include/asm/mbox.h | 21 configs/sandbox_defconfig | 3 ++ drivers/mailbox/Kconfig | 7 +++ drivers/mailbox/Makefile| 2 + drivers/mailbox/sandbox-mbox-test.c | 54 +++ drivers/mailbox/sandbox-mbox.c | 104 test/dm/Makefile| 1 + test/dm/mailbox.c | 31 +++ 9 files changed, 234 insertions(+) create mode 100644 arch/sandbox/include/asm/mbox.h create mode 100644 drivers/mailbox/sandbox-mbox-test.c create mode 100644 drivers/mailbox/sandbox-mbox.c create mode 100644 test/dm/mailbox.c diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 89300096a5ab..686c215aea72 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -216,6 +216,17 @@ }; }; + mbox: mbox { + compatible = "sandbox,mbox"; + #mbox-cells = <1>; + }; + + mbox-test { + compatible = "sandbox,mbox-test"; + mboxes = < 100>, < 1>; + mbox-names = "other", "test"; + }; + mmc { compatible = "sandbox,mmc"; }; diff --git a/arch/sandbox/include/asm/mbox.h b/arch/sandbox/include/asm/mbox.h new file mode 100644 index ..2d7b7d03e522 --- /dev/null +++ b/arch/sandbox/include/asm/mbox.h @@ -0,0 +1,21 @@ +/* + * Copyright (c) 2016, NVIDIA CORPORATION. + * + * SPDX-License-Identifier: GPL-2.0 + */ + +#ifndef __SANDBOX_MBOX_H +#define __SANDBOX_MBOX_H + +#include + +#define SANDBOX_MBOX_PING_XOR 0x12345678 + +struct udevice; + +int sandbox_mbox_test_get(struct udevice *dev); +int sandbox_mbox_test_send(struct udevice *dev, uint32_t msg); +int sandbox_mbox_test_recv(struct udevice *dev, uint32_t *msg); +int sandbox_mbox_test_free(struct udevice *dev); + +#endif diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 9ad570c7fc49..8613da2c15f5 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -167,3 +167,6 @@ CONFIG_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y CONFIG_UT_ENV=y +CONFIG_MISC=y +CONFIG_DM_MAILBOX=y +CONFIG_SANDBOX_MBOX=y diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index 8ae8edd28c52..9649b705895b 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -10,6 +10,13 @@ config DM_MAILBOX the basis of a variety of inter-process/inter-CPU communication protocols. +config SANDBOX_MBOX + bool "Enable the sandbox mailbox test driver" + depends on DM_MAILBOX && SANDBOX + help + Enable support for a test mailbox implementation, which simply echos + back a modified version of any message that is sent. + config TEGRA_HSP bool "Enable Tegra HSP controller support" depends on DM_MAILBOX && TEGRA diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index b5bc84032573..155dbeb09942 100644 --- a/drivers/mailbox/Makefile +++ b/drivers/mailbox/Makefile @@ -3,4 +3,6 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_DM_MAILBOX) += mailbox-uclass.o +obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox.o +obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox-test.o obj-$(CONFIG_TEGRA_HSP) += tegra-hsp.o diff --git a/drivers/mailbox/sandbox-mbox-test.c b/drivers/mailbox/sandbox-mbox-test.c new file mode 100644 index ..02d161aada33 --- /dev/null +++ b/drivers/mailbox/sandbox-mbox-test.c @@ -0,0 +1,54 @@ +/* + * Copyright (c) 2016, NVIDIA CORPORATION. + * + * SPDX-License-Identifier: GPL-2.0 + */ + +#include +#include +#include +#include + +struct sandbox_mbox_test { + struct mbox_chan chan; +}; + +int sandbox_mbox_test_get(struct udevice *dev) +{ + struct sandbox_mbox_test *sbmt = dev_get_priv(dev); + + return mbox_get_by_name(dev, "test", >chan); +} + +int sandbox_mbox_test_send(struct udevice *dev, uint32_t msg) +{ + struct sandbox_mbox_test *sbmt = dev_get_priv(dev); + + return mbox_send(>chan, ); +} + +int sandbox_mbox_test_recv(struct udevice *dev, uint32_t *msg) +{ + struct sandbox_mbox_test *sbmt = dev_get_priv(dev); + + return mbox_recv(>chan, msg, 100); +} + +int sandbox_mbox_test_free(struct udevice *dev) +{ + struct sandbox_mbox_test *sbmt = dev_get_priv(dev); + + return mbox_free(>chan); +} + +static const
[U-Boot] [RFC] tools/env: Support UBI devices
Instead of requiring gluebi to update u-boot environments from Linux, directly support writing to an UBI device. The fw_env.config file will look something like this: Device Offset Envsize LEB SizeCount /dev/ubi0_0 0 0x1 0x1f000 1 It is important to use LEB size instead of PEB size when using UBI. Signed-off-by: Kevin SmithCc: Michael Heimpold Cc: Joe Hershberger --- tools/env/fw_env.c | 71 -- 1 file changed, 48 insertions(+), 23 deletions(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index ba11f77..af7a8ae 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include #include @@ -29,6 +30,7 @@ #else # define __user /* nothing */ # include +# include #endif #include "fw_env.h" @@ -54,6 +56,8 @@ struct envdev_s { uint8_t mtd_type; /* type of the MTD device */ }; +#define UBI_TYPE UCHAR_MAX + static struct envdev_s envdevices[2] = { { @@ -943,7 +947,7 @@ static int flash_write_buf (int dev, int fd, void *buf, size_t count, continue; } - if (mtd_type != MTD_ABSENT) { + if (mtd_type != MTD_ABSENT && mtd_type != UBI_TYPE) { erase.start = blockstart; ioctl(fd, MEMUNLOCK, ); /* These do not need an explicit erase cycle */ @@ -956,11 +960,21 @@ static int flash_write_buf (int dev, int fd, void *buf, size_t count, } } - if (lseek (fd, blockstart, SEEK_SET) == -1) { - fprintf (stderr, -"Seek error on %s: %s\n", -DEVNAME (dev), strerror (errno)); - return -1; + if (mtd_type == UBI_TYPE) { + uint64_t updatesize = erasesize; + if (ioctl(fd, UBI_IOCVOLUP, ) != 0) { + fprintf(stderr, + "Error updating UBI volume: %s\n", + strerror(errno)); + return -1; + } + } else { + if (lseek (fd, blockstart, SEEK_SET) == -1) { + fprintf (stderr, +"Seek error on %s: %s\n", +DEVNAME (dev), strerror (errno)); + return -1; + } } #ifdef DEBUG @@ -973,7 +987,7 @@ static int flash_write_buf (int dev, int fd, void *buf, size_t count, return -1; } - if (mtd_type != MTD_ABSENT) + if (mtd_type != MTD_ABSENT && mtd_type != UBI_TYPE) ioctl(fd, MEMLOCK, ); processed += erasesize; @@ -1084,6 +1098,7 @@ static int flash_read (int fd) { struct mtd_info_user mtdinfo; struct stat st; + int32_t lnum; int rc; rc = fstat(fd, ); @@ -1095,28 +1110,38 @@ static int flash_read (int fd) if (S_ISCHR(st.st_mode)) { rc = ioctl(fd, MEMGETINFO, ); - if (rc < 0) { - fprintf(stderr, "Cannot get MTD information for %s\n", - DEVNAME(dev_current)); - return -1; + if (rc >= 0) { + if (mtdinfo.type != MTD_NORFLASH && + mtdinfo.type != MTD_NANDFLASH && + mtdinfo.type != MTD_DATAFLASH && + mtdinfo.type != MTD_UBIVOLUME) { + fprintf (stderr, + "Unsupported flash type %u on %s\n", + mtdinfo.type, DEVNAME(dev_current)); + return -1; + } + DEVTYPE(dev_current) = mtdinfo.type; + goto read; } - if (mtdinfo.type != MTD_NORFLASH && - mtdinfo.type != MTD_NANDFLASH && - mtdinfo.type != MTD_DATAFLASH && - mtdinfo.type != MTD_UBIVOLUME) { - fprintf (stderr, "Unsupported flash type %u on %s\n", -mtdinfo.type, DEVNAME(dev_current)); - return -1; + + /* Check for an UBI-type device */ + lnum = 0; + rc = ioctl(fd, UBI_IOCEBISMAP, ); + if (rc >= 0) { + DEVTYPE(dev_current) = UBI_TYPE; +
Re: [U-Boot] [PATCH v2 3/5] dm: ns16550: Don't map_physmem for I/O ports
Am 16.05.2016 um 19:44 schrieb Paul Burton: > If the UART is to be accessed using I/O port accessors (inb & outb) then > using map_physmem doesn't make sense, since it operates in a different > memory space. Remove the call to map_physmem when > CONFIG_SYS_NS16550_PORT_MAPPED is defined, allowing I/O port addresses > to not be mangled by the incorrect mapping. > > Signed-off-by: Paul BurtonReviewed-by: Daniel Schwierzeck Tested-by: Daniel Schwierzeck > --- > > Changes in v2: > - New patch, part of a simplified approach tackling only a single Malta UART. > > drivers/serial/ns16550.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > index 28da9dd..e58e6aa 100644 > --- a/drivers/serial/ns16550.c > +++ b/drivers/serial/ns16550.c > @@ -100,7 +100,11 @@ static void ns16550_writeb(NS16550_t port, int offset, > int value) > unsigned char *addr; > > offset *= 1 << plat->reg_shift; > +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED > + addr = (unsigned char *)plat->base + offset; > +#else > addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset; > +#endif > /* >* As far as we know it doesn't make sense to support selection of >* these options at run-time, so use the existing CONFIG options. > @@ -114,7 +118,11 @@ static int ns16550_readb(NS16550_t port, int offset) > unsigned char *addr; > > offset *= 1 << plat->reg_shift; > +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED > + addr = (unsigned char *)plat->base + offset; > +#else > addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset; > +#endif > > return serial_in_shift(addr + plat->reg_offset, plat->reg_shift); > } > -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] malta: Tidy up UART address selection
Am 16.05.2016 um 19:44 schrieb Paul Burton: > The address of the UART differs based upon the system controller because > it's actually within the I/O port region, which is in a different > location for each system controller. Rather than handling this as 2 > UARTs with the correct one selected at runtime, use I/O port accessors > for the UART such that access to it gets translated into the I/O port > region automatically. > > Signed-off-by: Paul BurtonReviewed-by: Daniel Schwierzeck > --- > > Changes in v2: > - New patch, simplifying the later DT conversion. > > board/imgtec/malta/malta.c | 13 - > include/configs/malta.h| 4 ++-- > 2 files changed, 2 insertions(+), 15 deletions(-) > > diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c > index 3a9e780..4955043 100644 > --- a/board/imgtec/malta/malta.c > +++ b/board/imgtec/malta/malta.c > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > > #include > #include > @@ -161,18 +160,6 @@ int misc_init_r(void) > return 0; > } > > -struct serial_device *default_serial_console(void) > -{ > - switch (malta_sys_con()) { > - case SYSCON_GT64120: > - return _device; > - > - default: > - case SYSCON_MSC01: > - return _device; > - } > -} > - > void pci_init_board(void) > { > pci_dev_t bdf; > diff --git a/include/configs/malta.h b/include/configs/malta.h > index 04dca71..1c3c83c 100644 > --- a/include/configs/malta.h > +++ b/include/configs/malta.h > @@ -67,10 +67,10 @@ > #define CONFIG_BAUDRATE 115200 > > #define CONFIG_SYS_NS16550_SERIAL > +#define CONFIG_SYS_NS16550_PORT_MAPPED > #define CONFIG_SYS_NS16550_REG_SIZE 1 > #define CONFIG_SYS_NS16550_CLK (115200 * 16) > -#define CONFIG_SYS_NS16550_COM1 0xb80003f8 > -#define CONFIG_SYS_NS16550_COM2 0xbb0003f8 > +#define CONFIG_SYS_NS16550_COM1 0x3f8 > #define CONFIG_CONS_INDEX1 > > /* > -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] malta: Use device model & tree for UART
Am 16.05.2016 um 19:44 schrieb Paul Burton: > Make use of device model & device tree to probe the UART driver. This is > the initial step in bringing Malta up to date with driver model, and > allows for cleaner handling of the different I/O addresses for different > system controllers by specifying the ISA bus address instead of a > translated memory address. > > Signed-off-by: Paul BurtonReviewed-by: Daniel Schwierzeck nits below > --- > > Changes in v2: > - Only handle the UART we already use, for simplicity. > > arch/mips/Kconfig | 5 + > arch/mips/dts/Makefile | 3 ++- > arch/mips/dts/mti,malta.dts | 32 > configs/malta_defconfig | 1 + > configs/maltael_defconfig | 1 + > include/configs/malta.h | 6 -- > 6 files changed, 41 insertions(+), 7 deletions(-) > create mode 100644 arch/mips/dts/mti,malta.dts > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index fe37d1f..e407b19 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -23,7 +23,12 @@ config TARGET_QEMU_MIPS > > config TARGET_MALTA > bool "Support malta" > + select DM > + select DM_SERIAL actually DM_SERIAL should be selected in the defconfig. But Malta is a single target so it's ok. > select DYNAMIC_IO_PORT_BASE > + select OF_CONTROL > + select OF_EMBED but OF_EMBED should go into the defconfig. The user should decide if the DTB should be appended or be embedded. > + select OF_ISA_BUS > select SUPPORTS_BIG_ENDIAN > select SUPPORTS_LITTLE_ENDIAN > select SUPPORTS_CPU_MIPS32_R1 > diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile > index b513918..45d623f 100644 > --- a/arch/mips/dts/Makefile > +++ b/arch/mips/dts/Makefile > @@ -2,7 +2,8 @@ > # SPDX-License-Identifier: GPL-2.0+ > # > > -dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb > +dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb > +dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb this doesn't apply to u-boot-mips/next but I can fix it. > > targets += $(dtb-y) > > diff --git a/arch/mips/dts/mti,malta.dts b/arch/mips/dts/mti,malta.dts > new file mode 100644 > index 000..1dba606 > --- /dev/null > +++ b/arch/mips/dts/mti,malta.dts > @@ -0,0 +1,32 @@ > +/dts-v1/; > + > +/memreserve/ 0x 0x1000; /* Exception vectors */ > +/memreserve/ 0x000f 0x0001; /* PIIX4 ISA memory */ > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "mti,malta"; > + > + chosen { > + stdout-path = > + }; > + > + isa { > + compatible = "isa"; > + #address-cells = <2>; > + #size-cells = <1>; > + ranges = <1 0 0 0x1000>; is following dtc warning fixable? Warning (unit_address_vs_reg): Node /isa has a reg or ranges property, but no unit name > + > + uart0: serial@3f8 { > + compatible = "ns16550a"; > + > + reg = <1 0x3f8 0x40>; > + reg-shift = <0>; > + > + clock-frequency = <1843200>; > + > + u-boot,dm-pre-reloc; > + }; > + }; > +}; > diff --git a/configs/malta_defconfig b/configs/malta_defconfig > index a16f10b..0b5075f 100644 > --- a/configs/malta_defconfig > +++ b/configs/malta_defconfig > @@ -11,3 +11,4 @@ CONFIG_CMD_DHCP=y > CONFIG_CMD_PING=y > CONFIG_SYS_NS16550=y > CONFIG_USE_PRIVATE_LIBGCC=y > +CONFIG_DEFAULT_DEVICE_TREE="mti,malta" > diff --git a/configs/maltael_defconfig b/configs/maltael_defconfig > index 5289797..876e806 100644 > --- a/configs/maltael_defconfig > +++ b/configs/maltael_defconfig > @@ -12,3 +12,4 @@ CONFIG_CMD_DHCP=y > CONFIG_CMD_PING=y > CONFIG_SYS_NS16550=y > CONFIG_USE_PRIVATE_LIBGCC=y > +CONFIG_DEFAULT_DEVICE_TREE="mti,malta" > diff --git a/include/configs/malta.h b/include/configs/malta.h > index 1c3c83c..e03935b 100644 > --- a/include/configs/malta.h > +++ b/include/configs/malta.h > @@ -65,13 +65,7 @@ > * Serial driver > */ > #define CONFIG_BAUDRATE 115200 > - > -#define CONFIG_SYS_NS16550_SERIAL > #define CONFIG_SYS_NS16550_PORT_MAPPED > -#define CONFIG_SYS_NS16550_REG_SIZE 1 > -#define CONFIG_SYS_NS16550_CLK (115200 * 16) > -#define CONFIG_SYS_NS16550_COM1 0x3f8 > -#define CONFIG_CONS_INDEX1 > > /* > * Flash configuration > -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2016.05 is released
Hey all, Due to some odds and ends, I ended up taking in some code a bit close to the original release date, so I ended up just pushing things out a week. I think moving forward, I really should say that in public, sorry. But things are live on git and FTP and Amazon Cloud Drive now. So, v2016.05 has been released, and there's a few things worth pointing out here. First of all, U-Boot can now run EFI applications on ARM and ARMv8. The main use case here has been GRUB and that works. This is enabled by default on ARM and ARMv8 and a few platforms have turned it off due to not being useful for their needs or space savings. Next, we continue to make good progress on device model work and to me one of the exciting parts is that we brought in the ground work this release for FIT images from SPL and we've got a bunch of patches queued up for the next release to make use of it. The end result here is that we're now able to keep having one binary that runs on many platforms, when we can tell what the platforms are at run time, but that need different DTs to run correctly. I don't like to single out specific boards that we've added support for in these emails but looking over the log a lot of things have come in or gotten big updates including a number of popular / prominent boards. I'll let the respective custodians and authors showcase that themselves. Finally, we're making more progress on the testing front. The test/py/test.py infrastructure is getting more use and robustness and there's also tbot, see tools/tbot/README for more details there. Thanks again everyone! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master (v2016.05 bugfix)
On Sun, May 15, 2016 at 11:30:40AM +0200, Hans de Goede wrote: > Hi Tom, > > Here is a sunxi pull-req with a small bugfix for v2016.05: > > The following changes since commit 4cf4600f2569d7677a6f3cd933d7a189de6e7973: > > test, tools: update tbot documentation (2016-05-13 11:25:59 -0400) > > are available in the git repository at: > > http://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to f0a711ec40a6af4ea438db0bd776886c32780ddd: > > sunxi: Enable USB host in CHIP defconfig (2016-05-15 11:04:29 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] efi_loader: Add network access support
On 16.05.16 15:24, Simon Glass wrote: > Hi Alexander, > > On 14 May 2016 at 14:34, Alexander Grafwrote: >> >> >>> Am 14.05.2016 um 21:49 schrieb Simon Glass : >>> >>> Hi Alexander, >>> On 10 May 2016 at 15:25, Alexander Graf wrote: We can now successfully boot EFI applications from disk, but users may want to also run them from a PXE setup. This patch implements rudimentary network support, allowing a payload to send and receive network packets. With this patch, I was able to successfully run grub2 with network access inside of QEMU's -M xlnx-ep108 and on a zcu102 system. Signed-off-by: Alexander Graf --- v2 -> v3: - Align initialization sequence with net code - Set device to initialized after init call - Align tx buffers to DMA alignment (rx gets memcpy'd) - Add comment about eth_rx() --- cmd/bootefi.c| 7 ++ include/efi_api.h| 119 ++ include/efi_loader.h | 7 ++ include/net.h| 2 +- lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_net.c | 314 +++ net/bootp.c | 2 + net/net.c| 4 +- net/tftp.c | 2 + 9 files changed, 455 insertions(+), 3 deletions(-) create mode 100644 lib/efi_loader/efi_net.c diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 7f552fc..d3a2331 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -197,6 +197,13 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt) #ifdef CONFIG_LCD efi_gop_register(); #endif +#ifdef CONFIG_NET + void *nethandle = loaded_image_info.device_handle; + efi_net_register(); + + if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6)) + loaded_image_info.device_handle = nethandle; +#endif /* Call our payload! */ #ifdef DEBUG_EFI diff --git a/include/efi_api.h b/include/efi_api.h index 51d7586..20035d7 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -412,4 +412,123 @@ struct efi_gop struct efi_gop_mode *mode; }; +#define EFI_SIMPLE_NETWORK_GUID \ + EFI_GUID(0xa19832b9, 0xac25, 0x11d3, \ +0x9a, 0x2d, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d) + +struct efi_mac_address { + char mac_addr[32]; +}; + +struct efi_ip_address { + u8 ip_addr[16]; +}; + +enum efi_simple_network_state { + EFI_NETWORK_STOPPED, + EFI_NETWORK_STARTED, + EFI_NETWORK_INITIALIZED, +}; + +struct efi_simple_network_mode { + enum efi_simple_network_state state; + u32 hwaddr_size; + u32 media_header_size; + u32 max_packet_size; + u32 nvram_size; + u32 nvram_access_size; + u32 receive_filter_mask; + u32 receive_filter_setting; + u32 max_mcast_filter_count; + u32 mcast_filter_count; + struct efi_mac_address mcast_filter[16]; + struct efi_mac_address current_address; + struct efi_mac_address broadcast_address; + struct efi_mac_address permanent_address; + u8 if_type; + u8 mac_changeable; + u8 multitx_supported; + u8 media_present_supported; + u8 media_present; +}; + +#define EFI_SIMPLE_NETWORK_RECEIVE_UNICAST 0x01, +#define EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST 0x02, +#define EFI_SIMPLE_NETWORK_RECEIVE_BROADCAST 0x04, +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS 0x08, +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST 0x10, + +struct efi_simple_network +{ + u64 revision; + efi_status_t (EFIAPI *start)(struct efi_simple_network *this); + efi_status_t (EFIAPI *stop)(struct efi_simple_network *this); + efi_status_t (EFIAPI *initialize)(struct efi_simple_network *this, + ulong extra_rx, ulong extra_tx); + efi_status_t (EFIAPI *reset)(struct efi_simple_network *this, + int extended_verification); + efi_status_t (EFIAPI *shutdown)(struct efi_simple_network *this); + efi_status_t (EFIAPI *receive_filters)(struct efi_simple_network *this, + u32 enable, u32 disable, int reset_mcast_filter, + ulong mcast_filter_count, + struct efi_mac_address *mcast_filter); + efi_status_t (EFIAPI *station_address)(struct efi_simple_network *this, + int
Re: [U-Boot] [PATCH v2] sunxi: Increase SPL header size to 64 bytes to avoid code corruption
Hi, On 16-05-16 11:56, Bernhard Nortmann wrote: Given that there now are quite a few additional "reserved" entries, and while we're still at SPL_HEADER_VERSION 1, I'd like to renew my request of dedicating one of these fields to the script length - which would enable us to set the U-Boot ${filesize} accordingly. i.e. --- arch-arm-include-asm-arch-sunxi-spl.h +++ arch-arm-include-asm-arch-sunxi-spl.new.h @@ -49,7 +49,8 @@ uint8_t spl_signature[4]; }; uint32_t fel_script_address; - uint32_t reserved1[3]; + uint32_t fel_script_length; + uint32_t reserved1[2]; uint32_t boot_media;/* written here by the boot ROM */ uint32_t reserved2[5]; /* padding, align to 64 bytes */ }; I do not intend to further push my specific use cases, however I still consider the (then somewhat theoretical) ability to do "import -t ${fel_script_addr} ${filesize}" useful. For reference, the previous discussion related to this was somewhere around http://lists.denx.de/pipermail/u-boot/2015-September/227454.html Hmm, given that the boot-rom touches some of these, I wonder if we should be putting anything here at all. Other then that worry, I see no problem with adding a fel_script_length, Siarhei what is your opinion on this ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/13] usb: dwc3: add UniPhier specific glue layer
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > Add UniPhier platform specific glue layer to support USB3 Host mode > on Synopsys DWC3 IP. > > Signed-off-by: Masahiro Yamada> Reviewed-by: Marek Vasut > --- > > Changes in v2: > - Fix build error > - Add missing PHY reset deassert Applied, thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/13] usb: dwc3: change DWC3 core support code into a driver
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > Synopsys DWC3 IP generally works with an SoC-specific glue layer. > DT binding for that is like this: > > usb3_glue { > compatible = "foo,dwc3"; > ... > > usb3 { > compatible = "snps,dwc3"; > ... > }; > }; > > The glue layer initializes some SoC-specific parts, then populates > the child DWC3 core. To see how it works, refer to > > drivers/usb/dwc3/dwc3-exynos.c > drivers/usb/dwc3/dwc3-keystone.c > drivers/usb/dwc3/dwc3-omap.c > drivers/usb/dwc3/dwc3-st.c > > of Linux Kernel. > > This commit implements a driver compatible with "snps,dwc3", allowing > to use the same binding in U-Boot. The glue layer can be simply > implemented based on Simple Bus Uclass. > > Signed-off-by: Masahiro Yamada> Reviewed-by: Marek Vasut > --- Applied, thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/13] usb: move CONFIG_USB_XHCI_DWC3 to Kconfig
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > Create an entry for "config USB_XHCI_DWC3" in Kconfig and > switch over to it for all boards. > > Signed-off-by: Masahiro YamadaApplied, thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/13] usb: move CONFIG_USB_XHCI to Kconfig with renaming
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > Move CONFIG_USB_XHCI to defconfig files for all boards, renaming it > into CONFIG_USB_XHCI_HCD. > > As commented in the help of "config USB_XHCI" entry, this has been > a TODO for a long time; now CONFIG_USB_XHCI_HCD and CONFIG_USB_XHCI > have been unified in favor of the former. > > Note: > Some boards define CONFIG_USB_XHCI in their headers without > CONFIG_USB, which does not meet the "depends on" in Kconfig. > I added CONFIG_USB=y for those boards when converting. > Otherwise, they would fail to build. > > Signed-off-by: Masahiro YamadaApplied, thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/13] configs: blackfin: move CONFIG_USB to defconfig
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > These Blackfin boards are the last ones that define CONFIG_USB in > their headers. > > Signed-off-by: Masahiro YamadaApplied, thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/13] usb: xhci: add struct devrequest declaration to xhci.h
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > If xhci.h is included without include/usb.h, the compiler > complains like follows: > warning: 'struct devrequest' declared inside parameter list > > We have two options to teach the compiler that devrequest is > a structure: > > [1] Declare "struct devrequest;" in xhci.h > > [2] Include from xhci.h > > This commit takes [1] because nothing else in xhci.h depends on > include/usb.h. [2] would require the compiler additional header > parsing. > > Signed-off-by: Masahiro YamadaApplied, thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] malta: Use device model & tree for UART
Make use of device model & device tree to probe the UART driver. This is the initial step in bringing Malta up to date with driver model, and allows for cleaner handling of the different I/O addresses for different system controllers by specifying the ISA bus address instead of a translated memory address. Signed-off-by: Paul Burton--- Changes in v2: - Only handle the UART we already use, for simplicity. arch/mips/Kconfig | 5 + arch/mips/dts/Makefile | 3 ++- arch/mips/dts/mti,malta.dts | 32 configs/malta_defconfig | 1 + configs/maltael_defconfig | 1 + include/configs/malta.h | 6 -- 6 files changed, 41 insertions(+), 7 deletions(-) create mode 100644 arch/mips/dts/mti,malta.dts diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index fe37d1f..e407b19 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -23,7 +23,12 @@ config TARGET_QEMU_MIPS config TARGET_MALTA bool "Support malta" + select DM + select DM_SERIAL select DYNAMIC_IO_PORT_BASE + select OF_CONTROL + select OF_EMBED + select OF_ISA_BUS select SUPPORTS_BIG_ENDIAN select SUPPORTS_LITTLE_ENDIAN select SUPPORTS_CPU_MIPS32_R1 diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile index b513918..45d623f 100644 --- a/arch/mips/dts/Makefile +++ b/arch/mips/dts/Makefile @@ -2,7 +2,8 @@ # SPDX-License-Identifier: GPL-2.0+ # -dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb +dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb +dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb targets += $(dtb-y) diff --git a/arch/mips/dts/mti,malta.dts b/arch/mips/dts/mti,malta.dts new file mode 100644 index 000..1dba606 --- /dev/null +++ b/arch/mips/dts/mti,malta.dts @@ -0,0 +1,32 @@ +/dts-v1/; + +/memreserve/ 0x 0x1000;/* Exception vectors */ +/memreserve/ 0x000f 0x0001;/* PIIX4 ISA memory */ + +/ { + #address-cells = <1>; + #size-cells = <1>; + compatible = "mti,malta"; + + chosen { + stdout-path = + }; + + isa { + compatible = "isa"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <1 0 0 0x1000>; + + uart0: serial@3f8 { + compatible = "ns16550a"; + + reg = <1 0x3f8 0x40>; + reg-shift = <0>; + + clock-frequency = <1843200>; + + u-boot,dm-pre-reloc; + }; + }; +}; diff --git a/configs/malta_defconfig b/configs/malta_defconfig index a16f10b..0b5075f 100644 --- a/configs/malta_defconfig +++ b/configs/malta_defconfig @@ -11,3 +11,4 @@ CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_DEFAULT_DEVICE_TREE="mti,malta" diff --git a/configs/maltael_defconfig b/configs/maltael_defconfig index 5289797..876e806 100644 --- a/configs/maltael_defconfig +++ b/configs/maltael_defconfig @@ -12,3 +12,4 @@ CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_DEFAULT_DEVICE_TREE="mti,malta" diff --git a/include/configs/malta.h b/include/configs/malta.h index 1c3c83c..e03935b 100644 --- a/include/configs/malta.h +++ b/include/configs/malta.h @@ -65,13 +65,7 @@ * Serial driver */ #define CONFIG_BAUDRATE115200 - -#define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_PORT_MAPPED -#define CONFIG_SYS_NS16550_REG_SIZE1 -#define CONFIG_SYS_NS16550_CLK (115200 * 16) -#define CONFIG_SYS_NS16550_COM10x3f8 -#define CONFIG_CONS_INDEX 1 /* * Flash configuration -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] malta: Tidy up UART address selection
The address of the UART differs based upon the system controller because it's actually within the I/O port region, which is in a different location for each system controller. Rather than handling this as 2 UARTs with the correct one selected at runtime, use I/O port accessors for the UART such that access to it gets translated into the I/O port region automatically. Signed-off-by: Paul Burton--- Changes in v2: - New patch, simplifying the later DT conversion. board/imgtec/malta/malta.c | 13 - include/configs/malta.h| 4 ++-- 2 files changed, 2 insertions(+), 15 deletions(-) diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c index 3a9e780..4955043 100644 --- a/board/imgtec/malta/malta.c +++ b/board/imgtec/malta/malta.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include @@ -161,18 +160,6 @@ int misc_init_r(void) return 0; } -struct serial_device *default_serial_console(void) -{ - switch (malta_sys_con()) { - case SYSCON_GT64120: - return _device; - - default: - case SYSCON_MSC01: - return _device; - } -} - void pci_init_board(void) { pci_dev_t bdf; diff --git a/include/configs/malta.h b/include/configs/malta.h index 04dca71..1c3c83c 100644 --- a/include/configs/malta.h +++ b/include/configs/malta.h @@ -67,10 +67,10 @@ #define CONFIG_BAUDRATE115200 #define CONFIG_SYS_NS16550_SERIAL +#define CONFIG_SYS_NS16550_PORT_MAPPED #define CONFIG_SYS_NS16550_REG_SIZE1 #define CONFIG_SYS_NS16550_CLK (115200 * 16) -#define CONFIG_SYS_NS16550_COM10xb80003f8 -#define CONFIG_SYS_NS16550_COM20xbb0003f8 +#define CONFIG_SYS_NS16550_COM10x3f8 #define CONFIG_CONS_INDEX 1 /* -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] dm: ns16550: Don't map_physmem for I/O ports
If the UART is to be accessed using I/O port accessors (inb & outb) then using map_physmem doesn't make sense, since it operates in a different memory space. Remove the call to map_physmem when CONFIG_SYS_NS16550_PORT_MAPPED is defined, allowing I/O port addresses to not be mangled by the incorrect mapping. Signed-off-by: Paul Burton--- Changes in v2: - New patch, part of a simplified approach tackling only a single Malta UART. drivers/serial/ns16550.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 28da9dd..e58e6aa 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -100,7 +100,11 @@ static void ns16550_writeb(NS16550_t port, int offset, int value) unsigned char *addr; offset *= 1 << plat->reg_shift; +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED + addr = (unsigned char *)plat->base + offset; +#else addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset; +#endif /* * As far as we know it doesn't make sense to support selection of * these options at run-time, so use the existing CONFIG options. @@ -114,7 +118,11 @@ static int ns16550_readb(NS16550_t port, int offset) unsigned char *addr; offset *= 1 << plat->reg_shift; +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED + addr = (unsigned char *)plat->base + offset; +#else addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset; +#endif return serial_in_shift(addr + plat->reg_offset, plat->reg_shift); } -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] fdt: Document the rest of struct of_bus
Provide some documentation for the fields of struct of_bus, for consistency with that provided for the new match field. Signed-off-by: Paul Burton--- Changes in v2: - New patch. common/fdt_support.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/common/fdt_support.c b/common/fdt_support.c index 96b5d0a..5d8eb12 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -966,10 +966,29 @@ static void of_dump_addr(const char *s, const fdt32_t *addr, int na) { } /** * struct of_bus - Callbacks for bus specific translators + * @name: A string used to identify this bus in debug output. + * @addresses: The name of the DT property from which addresses are + * to be read, typically "reg". * @match: Return non-zero if the node whose parent is at * parentoffset in the FDT blob corresponds to a bus * of this type, otherwise return zero. If NULL a match * is assumed. + * @count_cells:Count how many cells (be32 values) a node whose parent + * is at parentoffset in the FDT blob will require to + * represent its address (written to *addrc) & size + * (written to *sizec). + * @map: Map the address addr from the address space of this + * bus to that of its parent, making use of the ranges + * read from DT to an array at range. na and ns are the + * number of cells (be32 values) used to hold and address + * or size, respectively, for this bus. pna is the number + * of cells used to hold an address for the parent bus. + * Returns the address in the address space of the parent + * bus. + * @translate: Update the value of the address cells at addr within an + * FDT by adding offset to it. na specifies the number of + * cells used to hold the address being translated. Returns + * zero on success, non-zero on error. * * Each bus type will include a struct of_bus in the of_busses array, * providing implementations of some or all of the functions used to -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] fdt: Support for ISA busses
Support ISA busses in much the same way as Linux does. This allows for ISA bus addresses to be translated, and only if CONFIG_OF_ISA_BUS is selected in order to avoid including the code in builds which won't need it. Signed-off-by: Paul Burton--- Changes in v2: - Document the match function pointer in struct of_bus. - Make CONFIG_OF_ISA_BUS not user-selectable, and explain it in help text. - assert() that of_match_bus didn't fail instead of BUG(), and comment why. - s/_busses[0]/of_busses/ common/fdt_support.c | 101 +-- drivers/core/Kconfig | 23 2 files changed, 121 insertions(+), 3 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index 42e5d8a..96b5d0a 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -964,10 +964,21 @@ static void of_dump_addr(const char *s, const fdt32_t *addr, int na) static void of_dump_addr(const char *s, const fdt32_t *addr, int na) { } #endif -/* Callbacks for bus specific translators */ +/** + * struct of_bus - Callbacks for bus specific translators + * @match: Return non-zero if the node whose parent is at + * parentoffset in the FDT blob corresponds to a bus + * of this type, otherwise return zero. If NULL a match + * is assumed. + * + * Each bus type will include a struct of_bus in the of_busses array, + * providing implementations of some or all of the functions used to + * match the bus & handle address translation for its children. + */ struct of_bus { const char *name; const char *addresses; + int (*match)(void *blob, int parentoffset); void(*count_cells)(void *blob, int parentoffset, int *addrc, int *sizec); u64 (*map)(fdt32_t *addr, const fdt32_t *range, @@ -1022,8 +1033,70 @@ static int of_bus_default_translate(fdt32_t *addr, u64 offset, int na) return 0; } +#ifdef CONFIG_OF_ISA_BUS + +/* ISA bus translator */ +static int of_bus_isa_match(void *blob, int parentoffset) +{ + const char *name; + + name = fdt_get_name(blob, parentoffset, NULL); + if (!name) + return 0; + + return !strcmp(name, "isa"); +} + +static void of_bus_isa_count_cells(void *blob, int parentoffset, + int *addrc, int *sizec) +{ + if (addrc) + *addrc = 2; + if (sizec) + *sizec = 1; +} + +static u64 of_bus_isa_map(fdt32_t *addr, const fdt32_t *range, + int na, int ns, int pna) +{ + u64 cp, s, da; + + /* Check address type match */ + if ((addr[0] ^ range[0]) & cpu_to_be32(1)) + return OF_BAD_ADDR; + + cp = of_read_number(range + 1, na - 1); + s = of_read_number(range + na + pna, ns); + da = of_read_number(addr + 1, na - 1); + + debug("OF: ISA map, cp=%" PRIu64 ", s=%" PRIu64 + ", da=%" PRIu64 "\n", cp, s, da); + + if (da < cp || da >= (cp + s)) + return OF_BAD_ADDR; + return da - cp; +} + +static int of_bus_isa_translate(fdt32_t *addr, u64 offset, int na) +{ + return of_bus_default_translate(addr + 1, offset, na - 1); +} + +#endif /* CONFIG_OF_ISA_BUS */ + /* Array of bus specific translators */ static struct of_bus of_busses[] = { +#ifdef CONFIG_OF_ISA_BUS + /* ISA */ + { + .name = "isa", + .addresses = "reg", + .match = of_bus_isa_match, + .count_cells = of_bus_isa_count_cells, + .map = of_bus_isa_map, + .translate = of_bus_isa_translate, + }, +#endif /* CONFIG_OF_ISA_BUS */ /* Default */ { .name = "default", @@ -1034,6 +1107,28 @@ static struct of_bus of_busses[] = { }, }; +static struct of_bus *of_match_bus(void *blob, int parentoffset) +{ + struct of_bus *bus; + + if (ARRAY_SIZE(of_busses) == 1) + return of_busses; + + for (bus = of_busses; bus; bus++) { + if (!bus->match || bus->match(blob, parentoffset)) + return bus; + } + + /* +* We should always have matched the default bus at least, since +* it has a NULL match field. If we didn't then it somehow isn't +* in the of_busses array or something equally catastrophic has +* gone wrong. +*/ + assert(0); + return NULL; +} + static int of_translate_one(void * blob, int parent, struct of_bus *bus, struct of_bus *pbus, fdt32_t *addr, int na, int ns, int pna, const char *rprop) @@ -1113,7 +1208,7 @@ static u64 __of_translate_address(void *blob, int node_offset, const fdt32_t *in parent = fdt_parent_offset(blob, node_offset); if (parent < 0) goto bail; - bus =
[U-Boot] [PATCH v2 0/5] Malta UART using device model & device tree
This series converts the MIPS Malta development board to make use of device model & device tree to probe the UART. This results in a tidier way to handle differences between Malta boards & starts Malta on the path to device model conversion. Paul Burton (5): fdt: Support for ISA busses fdt: Document the rest of struct of_bus dm: ns16550: Don't map_physmem for I/O ports malta: Tidy up UART address selection malta: Use device model & tree for UART arch/mips/Kconfig | 5 ++ arch/mips/dts/Makefile | 3 +- arch/mips/dts/mti,malta.dts | 32 board/imgtec/malta/malta.c | 13 - common/fdt_support.c| 120 ++-- configs/malta_defconfig | 1 + configs/maltael_defconfig | 1 + drivers/core/Kconfig| 23 + drivers/serial/ns16550.c| 8 +++ include/configs/malta.h | 8 +-- 10 files changed, 190 insertions(+), 24 deletions(-) create mode 100644 arch/mips/dts/mti,malta.dts -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PSCI patch set for ARMv7
Albert, I noticed a set of patch is delegated to you https://patchwork.ozlabs.org/project/uboot/list/?submitter=68732 Please kindly let me know if you will act on them, or if you prefer I take care of them. My testing capacity will be limited to ls1 series SoCs. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] drivers/ddr/fsl: Update clk_adjust of sdram_clk_cntl
On 05/03/2016 07:30 PM, Shengzhou Liu wrote: > The clk_adjust is of SDRAM_CLK_CNTL[5:8] 4-bits on MPC85xx and P-series, > but is of SDRAM_CLK_CNTL[5:9] 5-bits on T-series and LS-series SoCs. > We should update it to adapt the case that clk_adjust is odd data. > > Signed-off-by: Shengzhou Liu> --- > drivers/ddr/fsl/ctrl_regs.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c > index 9073917..b26269c 100644 > --- a/drivers/ddr/fsl/ctrl_regs.c > +++ b/drivers/ddr/fsl/ctrl_regs.c > @@ -1835,10 +1835,17 @@ static void set_ddr_sdram_clk_cntl(fsl_ddr_cfg_regs_t > *ddr, > /* Per FSL Application Note: AN2805 */ > ss_en = 1; > #endif > - clk_adjust = popts->clk_adjust; > + if (fsl_ddr_get_version(0) >= 0x40701) { > + /* clk_adjust in 5-bits on T-series and LS-series */ > + clk_adjust = (popts->clk_adjust & 0x1F) << 22; > + } else { > + /* clk_adjust in 4-bits on earlier MPC85xx and P-series */ > + clk_adjust = (popts->clk_adjust & 0xF) << 23; > + } > + > ddr->ddr_sdram_clk_cntl = (0 > | ((ss_en & 0x1) << 31) > -| ((clk_adjust & 0xF) << 23) > +| clk_adjust > ); > debug("FSLDDR: clk_cntl = 0x%08x\n", ddr->ddr_sdram_clk_cntl); > } > Shengzhou, Your understanding is correct. However, we have done analysis that the additional bit is not used for finer adjustment. So unless you have a case requiring values in the middle, I suggest to keep current code. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot
On 04/27/2016 11:19 PM, Gong Qianyu wrote: > IFC is considered as a required component in Layerscape platforms' Linux. > But if IFC is not enabled in U-Boot on some boards, accessing IFC memory > space would cause kernel call trace. So disable IFC node in such cases. > > Signed-off-by: Gong Qianyu> --- > V2: > - Revised the title and message. > - Used #ifndef CONFIG_FSL_IFC rather than #ifdef CONFIG_FSL_QSPI. > > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > index 1e875c4..96dab56 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c > @@ -98,4 +98,9 @@ void ft_cpu_setup(void *blob, bd_t *bd) > #ifdef CONFIG_SYS_DPAA_FMAN > fdt_fixup_fman_firmware(blob); > #endif > + > +#ifndef CONFIG_FSL_IFC > + do_fixup_by_compat(blob, "fsl,ifc", > +"status", "disabled", 8 + 1, 1); > +#endif > } > Qianyu, For the platforms you are testing, is IFC disabled/enabled at SoC level (eg. RCW) or board level (eg. FPGA)? Can you detect if IFC is enabled by checking registers? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] scsi: add PCIe to sata converter Marvell chip 88SE9170
On 04/13/2016 04:09 AM, Po Liu wrote: > Add to the command scsi device list. > > Signed-off-by: Po Liu> --- > cmd/scsi.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/cmd/scsi.c b/cmd/scsi.c > index 8991125..c85fefc 100644 > --- a/cmd/scsi.c > +++ b/cmd/scsi.c > @@ -31,6 +31,11 @@ > #define SCSI_VEND_ID 0x10b9 > #define SCSI_DEV_ID 0x5288 > > +#elif defined CONFIG_SATA_88SE9170 > + > +#define SCSI_VEND_ID 0x1b4b > +#define SCSI_DEV_ID 0x9170 > + > #elif !defined(CONFIG_SCSI_AHCI_PLAT) > #error no scsi device defined > #endif > Po, Would it be a better idea to define CONFIG_SCSI_DEV_LIST in your board header file? You can merge your two patches into one. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] armv8/ls2080a: configure PMU's PCTBENR to enable WDT
On 04/14/2016 08:57 PM, Yunhui Cui wrote: > From: Yunhui Cui> > The SP805-WDT module on LS2080A and LS2085A, requires configuration > of PMU's PCTBENR register to enable watchdog counter decrement and > reset signal generation. In order not to affect the sp805wdt driver > frame, we enable the watchdog clk in advance. > > Signed-off-by: Yunhui Cui > --- > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 15 +++ > arch/arm/include/asm/arch-fsl-layerscape/config.h | 4 > arch/arm/include/asm/arch-fsl-layerscape/soc.h| 1 + > board/freescale/ls2080aqds/ls2080aqds.c | 2 ++ > board/freescale/ls2080ardb/ls2080ardb.c | 2 ++ > 5 files changed, 24 insertions(+) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > index 0cb0100..c36976d 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c > @@ -42,6 +42,21 @@ bool soc_has_aiop(void) > return false; > } > > +#if defined(CONFIG_LS2080A) > +/* > + * In certain Layerscape SoCs, the clock for each core's watchdog > + * has an enable bit in the PMU Physical Core Time Base Enable Register > + * (PCTBENR), which allows the watchdog to operate. > + */ > +void enable_watchdog_clk(void) > +{ > + u32 pmu_val; > + > + pmu_val = *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET); > + *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET) = pmu_val | 0xff; > +} > +#endif > + > #ifdef CONFIG_LS2080A > /* > * This erratum requires setting a value to eddrtqcr1 to > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h > b/arch/arm/include/asm/arch-fsl-layerscape/config.h > index 10d17b2..62e4f95 100644 > --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h > +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h > @@ -143,6 +143,10 @@ > #define CONFIG_ARM_ERRATA_829520 > #define CONFIG_ARM_ERRATA_833471 > > +/* PMU-Physical Core Time Base Enable Register */ > +#define FSL_PMU_REG_BASE 0x1E3 > +#define FSL_PMU_PCTBENR_OFFSET 0x8A0 > + > #elif defined(CONFIG_LS1043A) > #define CONFIG_MAX_CPUS 4 > #define CONFIG_SYS_CACHELINE_SIZE64 > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h > b/arch/arm/include/asm/arch-fsl-layerscape/soc.h > index 831d817..bd4a8f1 100644 > --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h > +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h > @@ -91,6 +91,7 @@ void fsl_lsch2_early_init_f(void); > #endif > > void cpu_name(char *name); > +void enable_watchdog_clk(void); > #ifdef CONFIG_SYS_FSL_ERRATUM_A009635 > void erratum_a009635(void); > #endif > diff --git a/board/freescale/ls2080aqds/ls2080aqds.c > b/board/freescale/ls2080aqds/ls2080aqds.c > index b3bd40a..c109349 100644 > --- a/board/freescale/ls2080aqds/ls2080aqds.c > +++ b/board/freescale/ls2080aqds/ls2080aqds.c > @@ -213,6 +213,8 @@ int board_init(void) > select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT); > rtc_enable_32khz_output(); > > + enable_watchdog_clk(); > + > return 0; > } > > diff --git a/board/freescale/ls2080ardb/ls2080ardb.c > b/board/freescale/ls2080ardb/ls2080ardb.c > index fb39af6..7872f1f 100644 > --- a/board/freescale/ls2080ardb/ls2080ardb.c > +++ b/board/freescale/ls2080ardb/ls2080ardb.c > @@ -181,6 +181,8 @@ int board_init(void) > /* invert AQR405 IRQ pins polarity */ > out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK); > > + enable_watchdog_clk(); > + > return 0; > } > > Yunhui, I think you can move your code into timer_init() in cpu.c and follow the example of cltbenr. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/13] usb: dwc3: rework DWC3 and convert UniPhier xHCI driver to DM
On 05/16/2016 02:51 PM, Masahiro Yamada wrote: > Masahiro Yamada (13): > configs: blackfin: move CONFIG_USB to defconfig > usb: move CONFIG_USB_XHCI to Kconfig with renaming > usb: move CONFIG_USB_XHCI_DWC3 to Kconfig > usb: xhci: add struct devrequest declaration to xhci.h > usb: dwc3: change DWC3 core support code into a driver > usb: dwc3: add UniPhier specific glue layer > ARM: uniphier: switch over to USB DM > ARM: uniphier: enable DWC3 xHCI driver > usb: uniphier: remove UniPhier xHCI driver > ARM: uniphier: delete unnecessary xHCI pin-mux settings > ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG > ARM: dts: uniphier: add/update xHCI nodes > ARM: uniphier: enable Generic EHCI for PH1-Pro4 > > arch/arm/Kconfig | 1 + > arch/arm/dts/uniphier-ph1-ld20.dtsi | 17 > arch/arm/dts/uniphier-ph1-pro4-ref.dts | 4 + > arch/arm/dts/uniphier-ph1-pro4.dtsi | 32 -- > arch/arm/dts/uniphier-ph1-pro5.dtsi | 32 -- > arch/arm/dts/uniphier-proxstream2.dtsi | 32 -- > arch/arm/mach-uniphier/clk/clk-pro4.c| 6 +- > arch/arm/mach-uniphier/clk/clk-pro5.c| 6 +- > arch/arm/mach-uniphier/clk/clk-pxs2.c| 6 +- > arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c| 12 --- > arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c| 11 --- > arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c| 7 -- > arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c| 7 -- > arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c| 11 --- > common/usb.c | 2 +- > configs/am437x_gp_evm_defconfig | 2 + > configs/am437x_sk_evm_defconfig | 2 + > configs/am43xx_evm_defconfig | 2 + > configs/am43xx_evm_ethboot_defconfig | 2 + > configs/am43xx_evm_qspiboot_defconfig| 2 + > configs/am43xx_evm_usbhost_boot_defconfig| 2 + > configs/am57xx_evm_defconfig | 3 + > configs/am57xx_evm_nodt_defconfig| 3 + > configs/bf526-ezbrd_defconfig| 1 + > configs/bf527-ezkit-v2_defconfig | 1 + > configs/bf527-ezkit_defconfig| 1 + > configs/bf548-ezkit_defconfig| 1 + > configs/cm_t43_defconfig | 3 + > configs/dra72_evm_defconfig | 2 + > configs/dra74_evm_defconfig | 2 + > configs/dra7xx_evm_defconfig | 2 + > configs/dra7xx_evm_qspiboot_defconfig| 2 + > configs/dra7xx_evm_uart3_defconfig | 2 + > configs/k2e_evm_defconfig| 3 + > configs/k2g_evm_defconfig| 3 + > configs/k2hk_evm_defconfig | 3 + > configs/k2l_evm_defconfig| 3 + > configs/ls1021aqds_ddr4_nor_defconfig| 3 + > configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 3 + > configs/ls1021aqds_nand_defconfig| 3 + > configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 3 + > configs/ls1021aqds_nor_defconfig | 3 + > configs/ls1021aqds_nor_lpuart_defconfig | 3 + > configs/ls1021aqds_qspi_defconfig| 3 + > configs/ls1021aqds_sdcard_ifc_defconfig | 3 + > configs/ls1021aqds_sdcard_qspi_defconfig | 3 + > configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 3 + > configs/ls1021atwr_nor_defconfig | 3 + > configs/ls1021atwr_nor_lpuart_defconfig | 3 + > configs/ls1021atwr_qspi_defconfig| 3 + > configs/ls1021atwr_sdcard_ifc_defconfig | 3 + > configs/ls1021atwr_sdcard_qspi_defconfig | 3 + > configs/ls1043aqds_defconfig | 3 + > configs/ls1043aqds_lpuart_defconfig | 3 + > configs/ls1043aqds_nand_defconfig| 3 + > configs/ls1043aqds_nor_ddr3_defconfig| 3 + > configs/ls1043aqds_qspi_defconfig| 3 + > configs/ls1043aqds_sdcard_ifc_defconfig | 3 + > configs/ls1043aqds_sdcard_qspi_defconfig | 3 + > configs/ls1043ardb_SECURE_BOOT_defconfig | 3 + > configs/ls1043ardb_defconfig | 3 + > configs/ls1043ardb_nand_defconfig| 3 + > configs/ls1043ardb_sdcard_defconfig | 3 + > configs/ls2080aqds_SECURE_BOOT_defconfig | 3 + > configs/ls2080aqds_defconfig | 3 + > configs/ls2080aqds_nand_defconfig| 3 + > configs/ls2080ardb_SECURE_BOOT_defconfig | 3 + > configs/ls2080ardb_defconfig | 3 + > configs/ls2080ardb_nand_defconfig| 3 + > configs/odroid-xu3_defconfig | 2 + >
Re: [U-Boot] [PATCH] MARVELL: Delete now-superfluous board/Marvell/{common, include} dirs.
On 05/15/2016 06:12 PM, Robert P. J. Day wrote: > > With dropping support for some boards and the deletion of some source > files, it appears that both of these directories are now superfluous. > > Signed-off-by: Robert P. J. Day> > --- You can always run buildman for all arm boards and see what broke. I use this script: {( branch=`git branch | grep '^*' | sed "s/^..//"` dir=/tmp/bm-$1 arch="arm aarch64 mips powerpc nios2" shift 1 ./tools/buildman/buildman -o ${dir} -b ${branch} \ --step=0 ${arch} $@ )} -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ARM: uniphier: switch over to USB DM
On 05/16/2016 03:03 PM, Masahiro Yamada wrote: > Hi Marek, > > 2016-05-11 20:26 GMT+09:00 Marek Vasut: >> On 05/11/2016 12:28 PM, Masahiro Yamada wrote: >> >> Please, do write commit messages. >> >>> Signed-off-by: Masahiro Yamada >>> --- >>> >>> arch/arm/Kconfig | 1 + >>> include/configs/uniphier.h | 4 >>> 2 files changed, 5 insertions(+) >>> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >>> index 6b65d8e..59410cb 100644 >>> --- a/arch/arm/Kconfig >>> +++ b/arch/arm/Kconfig >>> @@ -723,6 +723,7 @@ config ARCH_UNIPHIER >>> select DM_SERIAL >>> select DM_I2C >>> select DM_MMC >>> + select DM_USB >>> help >>> Support for UniPhier SoC family developed by Socionext Inc. >>> (formerly, System LSI Business Division of Panasonic Corporation) >>> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h >>> index 18cb963..868f001 100644 >>> --- a/include/configs/uniphier.h >>> +++ b/include/configs/uniphier.h >>> @@ -136,6 +136,10 @@ >>> #define CONFIG_FAT_WRITE >>> #define CONFIG_DOS_PARTITION >>> >>> +#ifdef CONFIG_USB_DWC3_UNIPHIER >>> +#define CONFIG_USB_XHCI_DWC3 >> >> Could this be converted to Kconfig ? >> > > I noticed this task was not so easy as I had imagined first. > > Before moving CONFIB_USB_XHCI_DWC3, > I need to move CONFIG_USB_XHCI(_HCD) > because USB_XHCI_DWC3 depends on USB_XHCI_HCD. > > Before moving CONFIB_USB_XHCI(_HCD), > I need to move CONFIG_USB > because USB_XHCI(_HCD) depends on USB. > > A problem here is that many boards > define CONFIG_USB_XHCI without CONFIG_USB. > > In spite of that fact, finally I managed to > convert them and pass buildman test. > So, v2 is out now. > > > Thanks! -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration
On 16/05/16 14:10, Kishon Vijay Abraham I wrote: > Hi Roger, > > On Monday 16 May 2016 04:01 PM, Roger Quadros wrote: >> On 16/05/16 13:03, Kishon Vijay Abraham I wrote: >>> Hi Roger, >>> >>> On Monday 16 May 2016 03:19 PM, Roger Quadros wrote: On 16/05/16 12:26, Roger Quadros wrote: > On 16/05/16 12:06, Roger Quadros wrote: >> On 13/05/16 15:45, Marek Vasut wrote: >>> On 05/13/2016 02:36 PM, Roger Quadros wrote: Currently CONFIG_USB_DWC3 is not selected so doing a usb start command results in a serious error [1]. >>> >>> Why does this error happen ? That is what should be fixed. Selecting >>> some random options seems like papering over a bug. >> >> Agreed. I was lazy :P. > > OK. The issue is like this. > > CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls > usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c > which calls > board_usb_init(). >>> >>> IIRC, board_usb_init for xhci (omap) is mostly a NOP. >> >> Then who will call board_usb_init() for host case? >> > > But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 > is defined > and that is missing in am57xx_evm.h leading to the serious error. We're > trying to > access the IP without turning on the necessary clocks. >>> >>> clocks are not turned on in board_usb_init() right? The board_usb_init() in >>> am57xx/board.c is used only for gadget mode. > > So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or > something else. >>> >>> right, but before that we might have to cleanup xhci-omap. > > But then again looking into the future, what if we want only gadget > operation? > That would not define XHCI, but we still need board_usb_init(). So > board_usb_init() > should be defined based on CONFIG_CMD_USB=y? > > What do you suggest? But board_usb_init() calls ti_usb_phy_uboot_init(_phy1_device); dwc3_omap_uboot_init(_otg_ss1_glue); dwc3_uboot_init(_otg_ss1); which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and CONFIG_USB_DWC3 respectively. >>> >>> IMO we should cleanup xhci-omap so that all the initializations are done >>> using >>> ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify >>> dwc3_uboot_init to initialize host or device based on CONFIG_*. >>> >> >> I'm still trying to get a grip of how USB works in u-boot. >> Is CONFIG_CMD_USB only meant for host mode or gadget mode as well? > > IIRC it is only for host. Commands like usb start, usb stop are used to start > and stop host. >> Is dual-role even required in u-boot? probably it is not a good idea and we >> just >> ignore it for simplicity. > > yeah. >> >> What determines whether a USB port is meant for Host or device operation? Is >> it >> the CONFIG_ or caller of board_usb_init()? > It should be the caller of board_usb_init(). The same port can be used as > device or host based on command used (the command determines the caller of > board_usb_init). Then it is upto board_usb_init() to complain if it is called for some mode and the respective drivers are not enabled. board_usb_init() must be defined in the board if CONFIG_CMD_USB || USB_GADGET But there is no single config option for USB_GADGET. people seem to be calling board_usb_init() from all over the place without any dependency on USB_GADGET. e.g. dfu.c, ether.c, fastboot.c, thordown.c, usb_mass_storage.c, ether.c So things will break with various configurations. So probably for now board_usb_init() has to be always defined. cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/12] cmd: qfw: do not depend on x86
Hi Miao, On Mon, May 16, 2016 at 5:44 PM, Miao Yanwrote: > Hi Bin, > > 2016-05-13 22:00 GMT+08:00 Bin Meng : >> Hi Miao, >> >> On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: >>> The qfw command interface used to depend on X86, this patch removes >>> this restriction so it can be built for sandbox for testing. For normal >>> usage, it can only be used with CONFIG_QEMU. >>> >>> Signed-off-by: Miao Yan >>> --- >> >> Reviewed-by: Bin Meng >> >> Would you prepare a patch to enable this on Sandbox? > > I'll give it a try. Do you prefer to do that in this patch-set or submit > later ? > Please do in this patch-set so that we can test the sandbox build with this qfw command. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] x86: qemu: split qfw command interface and qfw core
Hi Miao, On Mon, May 16, 2016 at 5:50 PM, Miao Yanwrote: > Hi Bin, > > 2016-05-16 16:47 GMT+08:00 Bin Meng : >> Hi Miao, >> >> On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: >>> This patch splits qfw command interface and qfw core function into two >>> files, and introduces a new Kconfig option (CONFIG_QFW). for >>> qfw core. >>> >>> Now when qfw command interface is enabled, it will automatically select >>> qfw core. This patch also makes the ACPI table generation select >>> CONFIG_QFW. >>> >>> Signed-off-by: Miao Yan >>> --- >>> arch/x86/Kconfig | 2 +- >>> arch/x86/cpu/mp_init.c | 6 +- >>> arch/x86/cpu/qemu/Makefile | 3 +- >>> arch/x86/cpu/qemu/acpi_table.c | 2 + >>> arch/x86/cpu/qemu/qemu.c | 4 + >>> cmd/Kconfig| 1 + >>> cmd/Makefile | 2 +- >>> cmd/cmd_qfw.c | 182 + >> >> The file name should be qfw.c without cmd_ >> >>> cmd/qemu_fw_cfg.c | 353 >>> - >> >> And I suspect you can also use "git mv" for cmd/qemu_fw_cfg.c. "git mv >> cmd/qemu_fw_cfg.c cmd/qfw.c" > > But there is already a qfw.c under driver/misc/, having two files > using the same name seems a bit confusing. > No problem because they are in different directory, and the command one is in a directory named 'cmd'. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] efi_loader: Add network access support
Hi Alexander, On 14 May 2016 at 14:34, Alexander Grafwrote: > > >> Am 14.05.2016 um 21:49 schrieb Simon Glass : >> >> Hi Alexander, >> >>> On 10 May 2016 at 15:25, Alexander Graf wrote: >>> We can now successfully boot EFI applications from disk, but users >>> may want to also run them from a PXE setup. >>> >>> This patch implements rudimentary network support, allowing a payload >>> to send and receive network packets. >>> >>> With this patch, I was able to successfully run grub2 with network >>> access inside of QEMU's -M xlnx-ep108 and on a zcu102 system. >>> >>> Signed-off-by: Alexander Graf >>> >>> --- >>> >>> v2 -> v3: >>> >>> - Align initialization sequence with net code >>> - Set device to initialized after init call >>> - Align tx buffers to DMA alignment (rx gets memcpy'd) >>> - Add comment about eth_rx() >>> --- >>> cmd/bootefi.c| 7 ++ >>> include/efi_api.h| 119 ++ >>> include/efi_loader.h | 7 ++ >>> include/net.h| 2 +- >>> lib/efi_loader/Makefile | 1 + >>> lib/efi_loader/efi_net.c | 314 >>> +++ >>> net/bootp.c | 2 + >>> net/net.c| 4 +- >>> net/tftp.c | 2 + >>> 9 files changed, 455 insertions(+), 3 deletions(-) >>> create mode 100644 lib/efi_loader/efi_net.c >>> >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c >>> index 7f552fc..d3a2331 100644 >>> --- a/cmd/bootefi.c >>> +++ b/cmd/bootefi.c >>> @@ -197,6 +197,13 @@ static unsigned long do_bootefi_exec(void *efi, void >>> *fdt) >>> #ifdef CONFIG_LCD >>>efi_gop_register(); >>> #endif >>> +#ifdef CONFIG_NET >>> + void *nethandle = loaded_image_info.device_handle; >>> + efi_net_register(); >>> + >>> + if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6)) >>> + loaded_image_info.device_handle = nethandle; >>> +#endif >>> >>>/* Call our payload! */ >>> #ifdef DEBUG_EFI >>> diff --git a/include/efi_api.h b/include/efi_api.h >>> index 51d7586..20035d7 100644 >>> --- a/include/efi_api.h >>> +++ b/include/efi_api.h >>> @@ -412,4 +412,123 @@ struct efi_gop >>>struct efi_gop_mode *mode; >>> }; >>> >>> +#define EFI_SIMPLE_NETWORK_GUID \ >>> + EFI_GUID(0xa19832b9, 0xac25, 0x11d3, \ >>> +0x9a, 0x2d, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d) >>> + >>> +struct efi_mac_address { >>> + char mac_addr[32]; >>> +}; >>> + >>> +struct efi_ip_address { >>> + u8 ip_addr[16]; >>> +}; >>> + >>> +enum efi_simple_network_state { >>> + EFI_NETWORK_STOPPED, >>> + EFI_NETWORK_STARTED, >>> + EFI_NETWORK_INITIALIZED, >>> +}; >>> + >>> +struct efi_simple_network_mode { >>> + enum efi_simple_network_state state; >>> + u32 hwaddr_size; >>> + u32 media_header_size; >>> + u32 max_packet_size; >>> + u32 nvram_size; >>> + u32 nvram_access_size; >>> + u32 receive_filter_mask; >>> + u32 receive_filter_setting; >>> + u32 max_mcast_filter_count; >>> + u32 mcast_filter_count; >>> + struct efi_mac_address mcast_filter[16]; >>> + struct efi_mac_address current_address; >>> + struct efi_mac_address broadcast_address; >>> + struct efi_mac_address permanent_address; >>> + u8 if_type; >>> + u8 mac_changeable; >>> + u8 multitx_supported; >>> + u8 media_present_supported; >>> + u8 media_present; >>> +}; >>> + >>> +#define EFI_SIMPLE_NETWORK_RECEIVE_UNICAST 0x01, >>> +#define EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST 0x02, >>> +#define EFI_SIMPLE_NETWORK_RECEIVE_BROADCAST 0x04, >>> +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS 0x08, >>> +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST 0x10, >>> + >>> +struct efi_simple_network >>> +{ >>> + u64 revision; >>> + efi_status_t (EFIAPI *start)(struct efi_simple_network *this); >>> + efi_status_t (EFIAPI *stop)(struct efi_simple_network *this); >>> + efi_status_t (EFIAPI *initialize)(struct efi_simple_network *this, >>> + ulong extra_rx, ulong extra_tx); >>> + efi_status_t (EFIAPI *reset)(struct efi_simple_network *this, >>> + int extended_verification); >>> + efi_status_t (EFIAPI *shutdown)(struct efi_simple_network *this); >>> + efi_status_t (EFIAPI *receive_filters)(struct efi_simple_network >>> *this, >>> + u32 enable, u32 disable, int reset_mcast_filter, >>> + ulong mcast_filter_count, >>> + struct efi_mac_address *mcast_filter); >>> + efi_status_t (EFIAPI *station_address)(struct efi_simple_network >>> *this, >>> + int reset, struct efi_mac_address *new_mac); >>> + efi_status_t (EFIAPI *statistics)(struct efi_simple_network *this, >>> + int reset, ulong *stat_size, void
Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> From: Alexander Graf [mailto:ag...@suse.de] > Sent: Monday, May 16, 2016 5:51 PM > On 16.05.16 14:04, Bhupesh Sharma wrote: > > > > > >> -Original Message- > >> From: Alexander Graf [mailto:ag...@suse.de] > >> Sent: Monday, May 16, 2016 1:09 PM > >> To: Amit Tomer> >> Cc: Bhupesh Sharma ; york sun > >> ; u-boot@lists.denx.de; Peter Newton > >> > >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot > >> > >> > >> > >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer : > >>> > On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma > >> wrote: > Note that UEFI firmware support is already available on LS2080A- > RDB > and allows Booting distributions like CentOS on the same. > >>> > >>> Sorry to intervene here but it's about having the EFI support > inside > >>> u-boot itself that may *not* required to have separate UEFI > firmware > >>> to boot various distributions. > >>> > >>> Please correct, if it's not right ? > >> > >> It's correct. The idea is to allow everyone to boot using the uEFI > >> entry point in Linux (or any other OS), regardless of whether they > >> want to run U-Boot or a TianoCore based formware. > >> > >> This might seem useless today for embedded use cases, but some > >> features are only available via an EFI entry, such as kASLR. You can > >> also invoke Linux directly using the "bootefi" command, as Linux is > >> an EFI binary itself. That way the boot path doesn't become much > >> longer than with booti today. > >> > > > > The default firmware being offered by NXP to boot distros on LS2080A > and variants is UEFI. > > > > EFI application support in u-boot doesn't present a solution to > things > > like run-time variable/service support that is required by distros to > > update firmware components on the go. And there are several other > > services being offered by UEFI to help distro boot e.g. secure uefi > boot through x.509 certifications compliant to UEFI specifications. > > Don't get me wrong - I think it's great if there is a TianoCore based > firmware for LS2080A. But I didn't get the impression that there is a > TianoCore based firmware for every NXP SoC out there, so enabling all > of them to use the U-Boot provided uEFI implementation is still a win. > > That said, there's nothing that keeps us from implementing the bits you > mentioned in U-Boot either. There is support for RTS in U-Boot, we just > didn't convert any drivers (RTC comes to mind first) yet. > > There's also no support for uEFI environment variables, but mostly > because most systems I've used this code on so far just didn't have any > storage to put them. > > Certification checks also shouldn't be an issue if someone cared enough > about them. > > But I don't think we need a discussion of TianoCore vs U-Boot. What > everyone really wants is to have things "just work". And some customers > just prefer U-Boot for various reasons that are outside of my control. > If they can run the same boot path as everyone else, it makes life for > me as distribution vendor easier. And unlike other people in the > community, I don't think being a TianoCore+ACPI messiah is any helpful > for that goal. Alex - that's exactly my point. UEFI is currently planned as the default firmware on all QorIQ-LS ARMv8 SoCs for supporting distros. It's good to have a u-boot based solution for SoCs which don't support UEFI, but having both supported to boot distros causes confusion to the end user (IMHO), as the capabilities would vary drastically. Regarding adding support for run-time variable/services, we can always port everything over from the UEFI specifications - ACPI, run-time variable/services into u-boot. I think it's a great alternative on SoCs which don't have UEFI support available. But LS2080A and friends (LS1043A) already have UEFI support available and support distros like CentOS to be installed and boot'ed. So, these SoCs would not require an equivalent u-boot + EFI_Application like environment to boot distro. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] MIPS Release 6 Support
Am 16.05.2016 um 11:52 schrieb Paul Burton: > This series introduces support for building U-Boot for release 6 of the > MIPS architecture. This is supported by CPUs such as the M62xx, I6400 & > P6600 as well as by emulators such as QEMU. > > Paul Burton (5): > MIPS: Use unchecked immediate addition/subtraction > MIPS: Simplify CONFIG_SYS_CPU values > MIPS: Support for targetting MIPSr6 > malta: Remove ".set mips32" directive > malta: Support MIPS32r6 configurations > > arch/mips/Kconfig | 39 > ++ > arch/mips/Makefile | 2 ++ > arch/mips/cpu/start.S | 22 +++-- > arch/mips/lib/cache_init.S | 2 +- > board/imgtec/malta/lowlevel_init.S | 1 - > 5 files changed, 46 insertions(+), 20 deletions(-) > all patches applied to u-boot-mips/next, thanks -- - Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Remove sh2, sh3, sh4 architecture?
Hi, On 16 May 2016 at 00:18, Yoshinori Satowrote: > On Sun, 15 May 2016 08:19:39 +0900, > Simon Glass wrote: >> >> Hi, >> >> On 18 October 2015 at 10:19, Masahiro Yamada >> wrote: >> > 2015-10-19 0:54 GMT+09:00 Tom Rini : >> >> On Mon, Oct 19, 2015 at 12:30:43AM +0900, Masahiro Yamada wrote: >> >>> 2015-10-18 21:19 GMT+09:00 Simon Glass : >> >>> > Hi, >> >>> > >> >>> > It looks like these have no maintainer and have not been converted to >> >>> > generic board. Should we remove the 'sh' architecture? >> >>> > >> >>> > Regards, >> >>> > Simon >> >>> >> >>> >> >>> The maintainer, Nobuhiro, was at the U-Boot mini summit, >> >>> but, indeed, no work for SH these days. >> >>> >> >>> Since he left Renesas and went back to Hitachi, >> >>> he is now a complete volunteer, I guess. >> >>> >> >>> If the maintainer responsibility is painful for him, >> >>> he can take a step back, but I hope he can continue contribution... >> >>> Nobuhiro? >> >> >> >> I'd hate to see SH2 leave since it's becoming the J-Core architecture.. >> >> Perhaps someone in the community would like to help out too? >> > >> > Agree. Jeff talked about that at Dublin. >> > >> >> I haven't seen any activity. Does anyone have an update? >> > > I have converted code, but it can't be tested by a exsitance target. > Are you planning to send patches? We could still take them given that the alternative is removal. Is there an emulator/qemu? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] ARM: uniphier: switch over to USB DM
Hi Marek, 2016-05-11 20:26 GMT+09:00 Marek Vasut: > On 05/11/2016 12:28 PM, Masahiro Yamada wrote: > > Please, do write commit messages. > >> Signed-off-by: Masahiro Yamada >> --- >> >> arch/arm/Kconfig | 1 + >> include/configs/uniphier.h | 4 >> 2 files changed, 5 insertions(+) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 6b65d8e..59410cb 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -723,6 +723,7 @@ config ARCH_UNIPHIER >> select DM_SERIAL >> select DM_I2C >> select DM_MMC >> + select DM_USB >> help >> Support for UniPhier SoC family developed by Socionext Inc. >> (formerly, System LSI Business Division of Panasonic Corporation) >> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h >> index 18cb963..868f001 100644 >> --- a/include/configs/uniphier.h >> +++ b/include/configs/uniphier.h >> @@ -136,6 +136,10 @@ >> #define CONFIG_FAT_WRITE >> #define CONFIG_DOS_PARTITION >> >> +#ifdef CONFIG_USB_DWC3_UNIPHIER >> +#define CONFIG_USB_XHCI_DWC3 > > Could this be converted to Kconfig ? > I noticed this task was not so easy as I had imagined first. Before moving CONFIB_USB_XHCI_DWC3, I need to move CONFIG_USB_XHCI(_HCD) because USB_XHCI_DWC3 depends on USB_XHCI_HCD. Before moving CONFIB_USB_XHCI(_HCD), I need to move CONFIG_USB because USB_XHCI(_HCD) depends on USB. A problem here is that many boards define CONFIG_USB_XHCI without CONFIG_USB. In spite of that fact, finally I managed to convert them and pass buildman test. So, v2 is out now. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 00/13] usb: dwc3: rework DWC3 and convert UniPhier xHCI driver to DM
Masahiro Yamada (13): configs: blackfin: move CONFIG_USB to defconfig usb: move CONFIG_USB_XHCI to Kconfig with renaming usb: move CONFIG_USB_XHCI_DWC3 to Kconfig usb: xhci: add struct devrequest declaration to xhci.h usb: dwc3: change DWC3 core support code into a driver usb: dwc3: add UniPhier specific glue layer ARM: uniphier: switch over to USB DM ARM: uniphier: enable DWC3 xHCI driver usb: uniphier: remove UniPhier xHCI driver ARM: uniphier: delete unnecessary xHCI pin-mux settings ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG ARM: dts: uniphier: add/update xHCI nodes ARM: uniphier: enable Generic EHCI for PH1-Pro4 arch/arm/Kconfig | 1 + arch/arm/dts/uniphier-ph1-ld20.dtsi | 17 arch/arm/dts/uniphier-ph1-pro4-ref.dts | 4 + arch/arm/dts/uniphier-ph1-pro4.dtsi | 32 -- arch/arm/dts/uniphier-ph1-pro5.dtsi | 32 -- arch/arm/dts/uniphier-proxstream2.dtsi | 32 -- arch/arm/mach-uniphier/clk/clk-pro4.c| 6 +- arch/arm/mach-uniphier/clk/clk-pro5.c| 6 +- arch/arm/mach-uniphier/clk/clk-pxs2.c| 6 +- arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c| 12 --- arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c| 11 --- arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c| 7 -- arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c| 7 -- arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c| 11 --- common/usb.c | 2 +- configs/am437x_gp_evm_defconfig | 2 + configs/am437x_sk_evm_defconfig | 2 + configs/am43xx_evm_defconfig | 2 + configs/am43xx_evm_ethboot_defconfig | 2 + configs/am43xx_evm_qspiboot_defconfig| 2 + configs/am43xx_evm_usbhost_boot_defconfig| 2 + configs/am57xx_evm_defconfig | 3 + configs/am57xx_evm_nodt_defconfig| 3 + configs/bf526-ezbrd_defconfig| 1 + configs/bf527-ezkit-v2_defconfig | 1 + configs/bf527-ezkit_defconfig| 1 + configs/bf548-ezkit_defconfig| 1 + configs/cm_t43_defconfig | 3 + configs/dra72_evm_defconfig | 2 + configs/dra74_evm_defconfig | 2 + configs/dra7xx_evm_defconfig | 2 + configs/dra7xx_evm_qspiboot_defconfig| 2 + configs/dra7xx_evm_uart3_defconfig | 2 + configs/k2e_evm_defconfig| 3 + configs/k2g_evm_defconfig| 3 + configs/k2hk_evm_defconfig | 3 + configs/k2l_evm_defconfig| 3 + configs/ls1021aqds_ddr4_nor_defconfig| 3 + configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 3 + configs/ls1021aqds_nand_defconfig| 3 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 3 + configs/ls1021aqds_nor_defconfig | 3 + configs/ls1021aqds_nor_lpuart_defconfig | 3 + configs/ls1021aqds_qspi_defconfig| 3 + configs/ls1021aqds_sdcard_ifc_defconfig | 3 + configs/ls1021aqds_sdcard_qspi_defconfig | 3 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 3 + configs/ls1021atwr_nor_defconfig | 3 + configs/ls1021atwr_nor_lpuart_defconfig | 3 + configs/ls1021atwr_qspi_defconfig| 3 + configs/ls1021atwr_sdcard_ifc_defconfig | 3 + configs/ls1021atwr_sdcard_qspi_defconfig | 3 + configs/ls1043aqds_defconfig | 3 + configs/ls1043aqds_lpuart_defconfig | 3 + configs/ls1043aqds_nand_defconfig| 3 + configs/ls1043aqds_nor_ddr3_defconfig| 3 + configs/ls1043aqds_qspi_defconfig| 3 + configs/ls1043aqds_sdcard_ifc_defconfig | 3 + configs/ls1043aqds_sdcard_qspi_defconfig | 3 + configs/ls1043ardb_SECURE_BOOT_defconfig | 3 + configs/ls1043ardb_defconfig | 3 + configs/ls1043ardb_nand_defconfig| 3 + configs/ls1043ardb_sdcard_defconfig | 3 + configs/ls2080aqds_SECURE_BOOT_defconfig | 3 + configs/ls2080aqds_defconfig | 3 + configs/ls2080aqds_nand_defconfig| 3 + configs/ls2080ardb_SECURE_BOOT_defconfig | 3 + configs/ls2080ardb_defconfig | 3 + configs/ls2080ardb_nand_defconfig| 3 + configs/odroid-xu3_defconfig | 2 + configs/peach-pi_defconfig | 2 + configs/peach-pit_defconfig | 2 + configs/smdk5420_defconfig | 2 + configs/uniphier_ld20_defconfig | 2 +
[U-Boot] [PATCH v2 09/13] usb: uniphier: remove UniPhier xHCI driver
UniPhier platform switched to DWC3 core with UniPhier specific glue layer to support USB3. This pre-DM driver is no longer needed. Signed-off-by: Masahiro YamadaReviewed-by: Marek Vasut --- Changes in v2: None drivers/usb/host/Kconfig | 7 drivers/usb/host/Makefile| 1 - drivers/usb/host/xhci-uniphier.c | 85 include/fdtdec.h | 1 - lib/fdtdec.c | 1 - 5 files changed, 95 deletions(-) delete mode 100644 drivers/usb/host/xhci-uniphier.c diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index a6645dd..3710588 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -11,13 +11,6 @@ config USB_XHCI_HCD if USB_XHCI_HCD -config USB_XHCI_UNIPHIER - bool "Support for UniPhier on-chip xHCI USB controller" - depends on ARCH_UNIPHIER - default y - ---help--- - Enables support for the on-chip xHCI controller on UniPhier SoCs. - config USB_XHCI_DWC3 bool "DesignWare USB3 DRD Core Support" help diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 8b54fde..eb85650 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -63,7 +63,6 @@ obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o -obj-$(CONFIG_USB_XHCI_UNIPHIER) += xhci-uniphier.o # designware obj-$(CONFIG_USB_DWC2) += dwc2.o diff --git a/drivers/usb/host/xhci-uniphier.c b/drivers/usb/host/xhci-uniphier.c deleted file mode 100644 index 1b3f3d2..000 --- a/drivers/usb/host/xhci-uniphier.c +++ /dev/null @@ -1,85 +0,0 @@ -/* - * Copyright (C) 2015 Masahiro Yamada - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -#include -#include -#include -#include -#include -#include "xhci.h" - -static int get_uniphier_xhci_base(int index, struct xhci_hccr **base) -{ - DECLARE_GLOBAL_DATA_PTR; - int node_list[2]; - fdt_addr_t addr; - int count; - - count = fdtdec_find_aliases_for_id(gd->fdt_blob, "usb", - COMPAT_SOCIONEXT_XHCI, node_list, - ARRAY_SIZE(node_list)); - - if (index >= count) - return -ENODEV; - - addr = fdtdec_get_addr(gd->fdt_blob, node_list[index], "reg"); - if (addr == FDT_ADDR_T_NONE) - return -ENODEV; - - *base = (struct xhci_hccr *)addr; - - return 0; -} - -#define USB3_RST_CTRL 0x00100040 -#define IOMMU_RST_N(1 << 5) -#define LINK_RST_N (1 << 4) - -static void uniphier_xhci_reset(void __iomem *base, int on) -{ - u32 tmp; - - tmp = readl(base + USB3_RST_CTRL); - - if (on) - tmp &= ~(IOMMU_RST_N | LINK_RST_N); - else - tmp |= IOMMU_RST_N | LINK_RST_N; - - writel(tmp, base + USB3_RST_CTRL); -} - -int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor) -{ - int ret; - struct xhci_hccr *cr; - struct xhci_hcor *or; - - ret = get_uniphier_xhci_base(index, ); - if (ret < 0) - return ret; - - uniphier_xhci_reset(cr, 0); - - or = (void *)cr + HC_LENGTH(xhci_readl(>cr_capbase)); - - *hccr = cr; - *hcor = or; - - return 0; -} - -void xhci_hcd_stop(int index) -{ - int ret; - struct xhci_hccr *cr; - - ret = get_uniphier_xhci_base(index, ); - if (ret < 0) - return; - - uniphier_xhci_reset(cr, 1); -} diff --git a/include/fdtdec.h b/include/fdtdec.h index 37d482a..d1fddaa 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -158,7 +158,6 @@ enum fdt_compat_id { COMPAT_AMS_AS3722, /* AMS AS3722 PMIC */ COMPAT_INTEL_ICH_SPI, /* Intel ICH7/9 SPI controller */ COMPAT_INTEL_QRK_MRC, /* Intel Quark MRC */ - COMPAT_SOCIONEXT_XHCI, /* Socionext UniPhier xHCI */ COMPAT_INTEL_PCH, /* Intel PCH */ COMPAT_ALTERA_SOCFPGA_DWMAC,/* SoCFPGA Ethernet controller */ COMPAT_ALTERA_SOCFPGA_DWMMC,/* SoCFPGA DWMMC controller */ diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 70acc29..e316cc8 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -63,7 +63,6 @@ static const char * const compat_names[COMPAT_COUNT] = { COMPAT(AMS_AS3722, "ams,as3722"), COMPAT(INTEL_ICH_SPI, "intel,ich-spi"), COMPAT(INTEL_QRK_MRC, "intel,quark-mrc"), - COMPAT(SOCIONEXT_XHCI, "socionext,uniphier-xhci"), COMPAT(COMPAT_INTEL_PCH, "intel,bd82x6x"), COMPAT(ALTERA_SOCFPGA_DWMAC, "altr,socfpga-stmmac"), COMPAT(ALTERA_SOCFPGA_DWMMC, "altr,socfpga-dw-mshc"), -- 1.9.1 ___ U-Boot mailing
[U-Boot] [PATCH v2 13/13] ARM: uniphier: enable Generic EHCI for PH1-Pro4
On Driver Model USB, EHCI and xHCI can be enabled at the same time. PH1-Pro4 SoC has two EHCI cores and two xHCI cores, so enable the Generic EHCI driver. Signed-off-by: Masahiro Yamada--- Changes in v2: None configs/uniphier_pro4_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig index c9d104b..1e960b0 100644 --- a/configs/uniphier_pro4_defconfig +++ b/configs/uniphier_pro4_defconfig @@ -33,4 +33,6 @@ CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3_UNIPHIER=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_STORAGE=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 12/13] ARM: dts: uniphier: add/update xHCI nodes
Adjust xHCI nodes to use the DWC3 core and the SoC-specific glue layer for former SoCs. Signed-off-by: Masahiro Yamada--- Changes in v2: None arch/arm/dts/uniphier-ph1-ld20.dtsi| 17 + arch/arm/dts/uniphier-ph1-pro4-ref.dts | 4 arch/arm/dts/uniphier-ph1-pro4.dtsi| 32 arch/arm/dts/uniphier-ph1-pro5.dtsi| 32 arch/arm/dts/uniphier-proxstream2.dtsi | 32 5 files changed, 93 insertions(+), 24 deletions(-) diff --git a/arch/arm/dts/uniphier-ph1-ld20.dtsi b/arch/arm/dts/uniphier-ph1-ld20.dtsi index f9cc3c4..5e2b595 100644 --- a/arch/arm/dts/uniphier-ph1-ld20.dtsi +++ b/arch/arm/dts/uniphier-ph1-ld20.dtsi @@ -256,6 +256,23 @@ #interrupt-cells = <3>; interrupts = <1 9 4>; }; + + usb: usb@65b0 { + compatible = "socionext,uniphier-ld20-dwc3"; + reg = <0x65b0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + pinctrl-names = "default"; + pinctrl-0 = <_usb0>, <_usb1>, + <_usb2>, <_usb3>; + dwc3@65a0 { + compatible = "snps,dwc3"; + reg = <0x65a0 0x1>; + interrupts = <0 134 4>; + tx-fifo-resize; + }; + }; }; }; diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts b/arch/arm/dts/uniphier-ph1-pro4-ref.dts index 5be76e2..6cc5d1e 100644 --- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts +++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts @@ -71,6 +71,10 @@ status = "okay"; }; + { + status = "okay"; +}; + { status = "okay"; }; diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi b/arch/arm/dts/uniphier-ph1-pro4.dtsi index d5767b6..7f42bc2 100644 --- a/arch/arm/dts/uniphier-ph1-pro4.dtsi +++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi @@ -400,22 +400,38 @@ clocks = < 4>, < 6>; }; - usb0: usb@65a0 { - compatible = "socionext,uniphier-xhci", "generic-xhci"; + usb0: usb@65b0 { + compatible = "socionext,uniphier-pro4-dwc3"; status = "disabled"; - reg = <0x65a0 0x100>; - interrupts = <0 134 4>; + reg = <0x65b0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; pinctrl-names = "default"; pinctrl-0 = <_usb0>; + dwc3@65a0 { + compatible = "snps,dwc3"; + reg = <0x65a0 0x1>; + interrupts = <0 134 4>; + tx-fifo-resize; + }; }; - usb1: usb@65c0 { - compatible = "socionext,uniphier-xhci", "generic-xhci"; + usb1: usb@65d0 { + compatible = "socionext,uniphier-pro4-dwc3"; status = "disabled"; - reg = <0x65c0 0x100>; - interrupts = <0 137 4>; + reg = <0x65d0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; pinctrl-names = "default"; pinctrl-0 = <_usb1>; + dwc3@65c0 { + compatible = "snps,dwc3"; + reg = <0x65c0 0x1>; + interrupts = <0 137 4>; + tx-fifo-resize; + }; }; }; diff --git a/arch/arm/dts/uniphier-ph1-pro5.dtsi b/arch/arm/dts/uniphier-ph1-pro5.dtsi index bd1b4b1..3036a76 100644 --- a/arch/arm/dts/uniphier-ph1-pro5.dtsi +++ b/arch/arm/dts/uniphier-ph1-pro5.dtsi @@ -379,22 +379,38 @@ bus-width = <4>; }; - usb0: usb@65a0 { - compatible = "socionext,uniphier-xhci", "generic-xhci"; + usb0: usb@65b0 { + compatible = "socionext,uniphier-pro5-dwc3"; status = "disabled"; - reg = <0x65a0 0x100>; - interrupts = <0 134 4>; + reg = <0x65b0 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; pinctrl-names = "default"; pinctrl-0 = <_usb0>; + dwc3@65a0 { + compatible = "snps,dwc3"; + reg = <0x65a0 0x1>; + interrupts = <0 134 4>; + tx-fifo-resize; + }; }; - usb1: usb@65c0 { - compatible = "socionext,uniphier-xhci",
[U-Boot] [PATCH v2 11/13] ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG
Now USB 3.0 feature is enabled/disabled by CONFIG_USB_DWC3_UNIPHIER. Signed-off-by: Masahiro Yamada--- Changes in v2: None arch/arm/mach-uniphier/clk/clk-pro4.c | 6 +++--- arch/arm/mach-uniphier/clk/clk-pro5.c | 6 +++--- arch/arm/mach-uniphier/clk/clk-pxs2.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-uniphier/clk/clk-pro4.c b/arch/arm/mach-uniphier/clk/clk-pro4.c index 8746d7d..6a01543 100644 --- a/arch/arm/mach-uniphier/clk/clk-pro4.c +++ b/arch/arm/mach-uniphier/clk/clk-pro4.c @@ -15,7 +15,7 @@ void uniphier_pro4_clk_init(void) /* deassert reset */ tmp = readl(SC_RSTCTRL); -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_USB3C0 | SC_RSTCTRL_NRST_GIO; #endif @@ -31,7 +31,7 @@ void uniphier_pro4_clk_init(void) writel(tmp, SC_RSTCTRL); readl(SC_RSTCTRL); /* dummy read */ -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp = readl(SC_RSTCTRL2); tmp |= SC_RSTCTRL2_NRST_USB3B1 | SC_RSTCTRL2_NRST_USB3C1; writel(tmp, SC_RSTCTRL2); @@ -40,7 +40,7 @@ void uniphier_pro4_clk_init(void) /* provide clocks */ tmp = readl(SC_CLKCTRL); -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 | SC_CLKCTRL_CEN_GIO; #endif diff --git a/arch/arm/mach-uniphier/clk/clk-pro5.c b/arch/arm/mach-uniphier/clk/clk-pro5.c index 823bb06..dd86cad 100644 --- a/arch/arm/mach-uniphier/clk/clk-pro5.c +++ b/arch/arm/mach-uniphier/clk/clk-pro5.c @@ -15,7 +15,7 @@ void uniphier_pro5_clk_init(void) /* deassert reset */ tmp = readl(SC_RSTCTRL); -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_GIO; #endif #ifdef CONFIG_NAND_DENALI @@ -24,7 +24,7 @@ void uniphier_pro5_clk_init(void) writel(tmp, SC_RSTCTRL); readl(SC_RSTCTRL); /* dummy read */ -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp = readl(SC_RSTCTRL2); tmp |= SC_RSTCTRL2_NRST_USB3B1; writel(tmp, SC_RSTCTRL2); @@ -33,7 +33,7 @@ void uniphier_pro5_clk_init(void) /* provide clocks */ tmp = readl(SC_CLKCTRL); -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 | SC_CLKCTRL_CEN_GIO; #endif diff --git a/arch/arm/mach-uniphier/clk/clk-pxs2.c b/arch/arm/mach-uniphier/clk/clk-pxs2.c index 76bf856..3b50a20 100644 --- a/arch/arm/mach-uniphier/clk/clk-pxs2.c +++ b/arch/arm/mach-uniphier/clk/clk-pxs2.c @@ -15,7 +15,7 @@ void uniphier_pxs2_clk_init(void) /* deassert reset */ tmp = readl(SC_RSTCTRL); -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_GIO; #endif #ifdef CONFIG_UNIPHIER_ETH @@ -27,7 +27,7 @@ void uniphier_pxs2_clk_init(void) writel(tmp, SC_RSTCTRL); readl(SC_RSTCTRL); /* dummy read */ -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp = readl(SC_RSTCTRL2); tmp |= SC_RSTCTRL2_NRST_USB3B1; writel(tmp, SC_RSTCTRL2); @@ -36,7 +36,7 @@ void uniphier_pxs2_clk_init(void) /* provide clocks */ tmp = readl(SC_CLKCTRL); -#ifdef CONFIG_USB_XHCI_UNIPHIER +#ifdef CONFIG_USB_DWC3_UNIPHIER tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 | SC_CLKCTRL_CEN_GIO; #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/13] usb: move CONFIG_USB_XHCI to Kconfig with renaming
Move CONFIG_USB_XHCI to defconfig files for all boards, renaming it into CONFIG_USB_XHCI_HCD. As commented in the help of "config USB_XHCI" entry, this has been a TODO for a long time; now CONFIG_USB_XHCI_HCD and CONFIG_USB_XHCI have been unified in favor of the former. Note: Some boards define CONFIG_USB_XHCI in their headers without CONFIG_USB, which does not meet the "depends on" in Kconfig. I added CONFIG_USB=y for those boards when converting. Otherwise, they would fail to build. Signed-off-by: Masahiro Yamada--- Changes in v2: - Newly added common/usb.c | 2 +- configs/am437x_gp_evm_defconfig | 1 + configs/am437x_sk_evm_defconfig | 1 + configs/am43xx_evm_defconfig | 1 + configs/am43xx_evm_ethboot_defconfig | 1 + configs/am43xx_evm_qspiboot_defconfig| 1 + configs/am43xx_evm_usbhost_boot_defconfig| 1 + configs/am57xx_evm_defconfig | 2 ++ configs/am57xx_evm_nodt_defconfig| 2 ++ configs/cm_t43_defconfig | 2 ++ configs/dra72_evm_defconfig | 1 + configs/dra74_evm_defconfig | 1 + configs/dra7xx_evm_defconfig | 1 + configs/dra7xx_evm_qspiboot_defconfig| 1 + configs/dra7xx_evm_uart3_defconfig | 1 + configs/k2e_evm_defconfig| 2 ++ configs/k2g_evm_defconfig| 2 ++ configs/k2hk_evm_defconfig | 2 ++ configs/k2l_evm_defconfig| 2 ++ configs/ls1021aqds_ddr4_nor_defconfig| 2 ++ configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 2 ++ configs/ls1021aqds_nand_defconfig| 2 ++ configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 2 ++ configs/ls1021aqds_nor_defconfig | 2 ++ configs/ls1021aqds_nor_lpuart_defconfig | 2 ++ configs/ls1021aqds_qspi_defconfig| 2 ++ configs/ls1021aqds_sdcard_ifc_defconfig | 2 ++ configs/ls1021aqds_sdcard_qspi_defconfig | 2 ++ configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 2 ++ configs/ls1021atwr_nor_defconfig | 2 ++ configs/ls1021atwr_nor_lpuart_defconfig | 2 ++ configs/ls1021atwr_qspi_defconfig| 2 ++ configs/ls1021atwr_sdcard_ifc_defconfig | 2 ++ configs/ls1021atwr_sdcard_qspi_defconfig | 2 ++ configs/ls1043aqds_defconfig | 2 ++ configs/ls1043aqds_lpuart_defconfig | 2 ++ configs/ls1043aqds_nand_defconfig| 2 ++ configs/ls1043aqds_nor_ddr3_defconfig| 2 ++ configs/ls1043aqds_qspi_defconfig| 2 ++ configs/ls1043aqds_sdcard_ifc_defconfig | 2 ++ configs/ls1043aqds_sdcard_qspi_defconfig | 2 ++ configs/ls1043ardb_SECURE_BOOT_defconfig | 2 ++ configs/ls1043ardb_defconfig | 2 ++ configs/ls1043ardb_nand_defconfig| 2 ++ configs/ls1043ardb_sdcard_defconfig | 2 ++ configs/ls2080aqds_SECURE_BOOT_defconfig | 2 ++ configs/ls2080aqds_defconfig | 2 ++ configs/ls2080aqds_nand_defconfig| 2 ++ configs/ls2080ardb_SECURE_BOOT_defconfig | 2 ++ configs/ls2080ardb_defconfig | 2 ++ configs/ls2080ardb_nand_defconfig| 2 ++ configs/odroid-xu3_defconfig | 1 + configs/peach-pi_defconfig | 1 + configs/peach-pit_defconfig | 1 + configs/smdk5420_defconfig | 1 + configs/xilinx_zynqmp_ep_defconfig | 1 + configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 + configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 + configs/xilinx_zynqmp_zcu102_defconfig | 1 + configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 + drivers/usb/host/Kconfig | 6 -- drivers/usb/host/Makefile| 2 +- include/configs/am43xx_evm.h | 1 - include/configs/am57xx_evm.h | 1 - include/configs/cm_t43.h | 1 - include/configs/dra7xx_evm.h | 1 - include/configs/ds414.h | 3 +-- include/configs/exynos5420-common.h | 1 - include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - include/configs/ls1043aqds.h | 1 - include/configs/ls1043ardb.h | 1 - include/configs/ls2080aqds.h | 1 - include/configs/ls2080ardb.h | 1 - include/configs/smdk5420.h | 1 - include/configs/ti_armv7_keystone2.h | 1 - include/configs/xilinx_zynqmp.h | 1 - 77 files changed, 101 insertions(+), 24
[U-Boot] [PATCH v2 03/13] usb: move CONFIG_USB_XHCI_DWC3 to Kconfig
Create an entry for "config USB_XHCI_DWC3" in Kconfig and switch over to it for all boards. Signed-off-by: Masahiro Yamada--- Changes in v2: - Newly added configs/am437x_gp_evm_defconfig | 1 + configs/am437x_sk_evm_defconfig | 1 + configs/am43xx_evm_defconfig | 1 + configs/am43xx_evm_ethboot_defconfig | 1 + configs/am43xx_evm_qspiboot_defconfig| 1 + configs/am43xx_evm_usbhost_boot_defconfig| 1 + configs/am57xx_evm_defconfig | 1 + configs/am57xx_evm_nodt_defconfig| 1 + configs/cm_t43_defconfig | 1 + configs/dra72_evm_defconfig | 1 + configs/dra74_evm_defconfig | 1 + configs/dra7xx_evm_defconfig | 1 + configs/dra7xx_evm_qspiboot_defconfig| 1 + configs/dra7xx_evm_uart3_defconfig | 1 + configs/k2e_evm_defconfig| 1 + configs/k2g_evm_defconfig| 1 + configs/k2hk_evm_defconfig | 1 + configs/k2l_evm_defconfig| 1 + configs/ls1021aqds_ddr4_nor_defconfig| 1 + configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 + configs/ls1021aqds_nand_defconfig| 1 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021aqds_nor_defconfig | 1 + configs/ls1021aqds_nor_lpuart_defconfig | 1 + configs/ls1021aqds_qspi_defconfig| 1 + configs/ls1021aqds_sdcard_ifc_defconfig | 1 + configs/ls1021aqds_sdcard_qspi_defconfig | 1 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_nor_defconfig | 1 + configs/ls1021atwr_nor_lpuart_defconfig | 1 + configs/ls1021atwr_qspi_defconfig| 1 + configs/ls1021atwr_sdcard_ifc_defconfig | 1 + configs/ls1021atwr_sdcard_qspi_defconfig | 1 + configs/ls1043aqds_defconfig | 1 + configs/ls1043aqds_lpuart_defconfig | 1 + configs/ls1043aqds_nand_defconfig| 1 + configs/ls1043aqds_nor_ddr3_defconfig| 1 + configs/ls1043aqds_qspi_defconfig| 1 + configs/ls1043aqds_sdcard_ifc_defconfig | 1 + configs/ls1043aqds_sdcard_qspi_defconfig | 1 + configs/ls1043ardb_SECURE_BOOT_defconfig | 1 + configs/ls1043ardb_defconfig | 1 + configs/ls1043ardb_nand_defconfig| 1 + configs/ls1043ardb_sdcard_defconfig | 1 + configs/ls2080aqds_SECURE_BOOT_defconfig | 1 + configs/ls2080aqds_defconfig | 1 + configs/ls2080aqds_nand_defconfig| 1 + configs/ls2080ardb_SECURE_BOOT_defconfig | 1 + configs/ls2080ardb_defconfig | 1 + configs/ls2080ardb_nand_defconfig| 1 + configs/odroid-xu3_defconfig | 1 + configs/peach-pi_defconfig | 1 + configs/peach-pit_defconfig | 1 + configs/smdk5420_defconfig | 1 + configs/xilinx_zynqmp_ep_defconfig | 1 + configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 + configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 + configs/xilinx_zynqmp_zcu102_defconfig | 1 + configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 + drivers/usb/host/Kconfig | 6 ++ include/configs/am43xx_evm.h | 1 - include/configs/am57xx_evm.h | 1 - include/configs/cm_t43.h | 1 - include/configs/dra7xx_evm.h | 1 - include/configs/exynos5-common.h | 1 - include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - include/configs/ls1043aqds.h | 1 - include/configs/ls1043ardb.h | 1 - include/configs/ls2080aqds.h | 1 - include/configs/ls2080ardb.h | 1 - include/configs/ti_armv7_keystone2.h | 1 - include/configs/xilinx_zynqmp.h | 1 - 73 files changed, 65 insertions(+), 13 deletions(-) diff --git a/configs/am437x_gp_evm_defconfig b/configs/am437x_gp_evm_defconfig index 22620f0..f911281 100644 --- a/configs/am437x_gp_evm_defconfig +++ b/configs/am437x_gp_evm_defconfig @@ -39,6 +39,7 @@ CONFIG_TIMER=y CONFIG_OMAP_TIMER=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GADGET=y CONFIG_USB_DWC3_OMAP=y diff --git a/configs/am437x_sk_evm_defconfig b/configs/am437x_sk_evm_defconfig index 6c96a17..b9e0aae 100644 --- a/configs/am437x_sk_evm_defconfig +++ b/configs/am437x_sk_evm_defconfig @@ -43,6 +43,7 @@ CONFIG_TIMER=y CONFIG_OMAP_TIMER=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y
[U-Boot] [PATCH v2 10/13] ARM: uniphier: delete unnecessary xHCI pin-mux settings
Now UniPhier platform switched over to the DM-based xHCI driver. The pin-muxing for that is automatically cared by the pinctrl driver. These ad-hoc pin-muxing code is no longer needed. Signed-off-by: Masahiro Yamada--- Changes in v2: None arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c | 12 arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c | 11 --- arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c | 7 --- arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c | 7 --- arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c | 11 --- 5 files changed, 48 deletions(-) diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c index 6066b16..0da280f 100644 --- a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c +++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c @@ -31,16 +31,4 @@ void uniphier_ld20_pin_init(void) sg_set_pinsel(17, 0, 8, 4); /* NFD7-> NFD7 */ sg_set_iectrl_range(3, 17); #endif - -#ifdef CONFIG_USB_XHCI_UNIPHIER - sg_set_pinsel(46, 0, 8, 4); /* USB0VBUS -> USB0VBUS */ - sg_set_pinsel(47, 0, 8, 4); /* USB0OD -> USB0OD */ - sg_set_pinsel(48, 0, 8, 4); /* USB1VBUS -> USB1VBUS */ - sg_set_pinsel(49, 0, 8, 4); /* USB1OD -> USB1OD */ - sg_set_pinsel(50, 0, 8, 4); /* USB2VBUS -> USB2VBUS */ - sg_set_pinsel(51, 0, 8, 4); /* USB2OD -> USB2OD */ - sg_set_pinsel(52, 0, 8, 4); /* USB3VBUS -> USB3VBUS */ - sg_set_pinsel(53, 0, 8, 4); /* USB3OD -> USB3OD */ - sg_set_iectrl_range(46, 53); -#endif } diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c index 913722b..f3b7115 100644 --- a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c +++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c @@ -32,15 +32,4 @@ void uniphier_ld6b_pin_init(void) sg_set_pinsel(45, 0, 8, 4); /* NFD6 -> NFD6 */ sg_set_pinsel(46, 0, 8, 4); /* NFD7 -> NFD7 */ #endif - -#ifdef CONFIG_USB_XHCI_UNIPHIER - sg_set_pinsel(56, 0, 8, 4); /* USB0VBUS -> USB0VBUS */ - sg_set_pinsel(57, 0, 8, 4); /* USB0OD -> USB0OD */ - sg_set_pinsel(58, 0, 8, 4); /* USB1VBUS -> USB1VBUS */ - sg_set_pinsel(59, 0, 8, 4); /* USB1OD -> USB1OD */ - sg_set_pinsel(60, 0, 8, 4); /* USB2VBUS -> USB2VBUS */ - sg_set_pinsel(61, 0, 8, 4); /* USB2OD -> USB2OD */ - sg_set_pinsel(62, 0, 8, 4); /* USB3VBUS -> USB3VBUS */ - sg_set_pinsel(63, 0, 8, 4); /* USB3OD -> USB3OD */ -#endif } diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c index 3796491..871d3ef 100644 --- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c +++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c @@ -33,12 +33,5 @@ void uniphier_pro4_pin_init(void) /* sg_set_pinsel(132, 1, 4, 8); */ /* TXD2 -> XNFCE1 */ #endif -#ifdef CONFIG_USB_XHCI_UNIPHIER - sg_set_pinsel(180, 0, 4, 8);/* USB0VBUS -> USB0VBUS */ - sg_set_pinsel(181, 0, 4, 8);/* USB0OD -> USB0OD */ - sg_set_pinsel(182, 0, 4, 8);/* USB1VBUS -> USB1VBUS */ - sg_set_pinsel(183, 0, 4, 8);/* USB1OD -> USB1OD */ -#endif - writel(1, SG_LOADPINCTRL); } diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c index 32ba923..58dff18 100644 --- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c +++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c @@ -33,12 +33,5 @@ void uniphier_pro5_pin_init(void) sg_set_pinsel(35, 0, 4, 8); /* NFD7 -> NFD7 */ #endif -#ifdef CONFIG_USB_XHCI_UNIPHIER - sg_set_pinsel(124, 0, 4, 8);/* USB0VBUS -> USB0VBUS */ - sg_set_pinsel(125, 0, 4, 8);/* USB0OD -> USB0OD */ - sg_set_pinsel(126, 0, 4, 8);/* USB1VBUS -> USB1VBUS */ - sg_set_pinsel(127, 0, 4, 8);/* USB1OD -> USB1OD */ -#endif - writel(1, SG_LOADPINCTRL); } diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c b/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c index 2d62ab3..fc59205 100644 --- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c +++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c @@ -32,15 +32,4 @@ void uniphier_pxs2_pin_init(void) sg_set_pinsel(45, 8, 8, 4); /* NFD6 -> NFD6 */ sg_set_pinsel(46, 8, 8, 4); /* NFD7 -> NFD7 */ #endif - -#ifdef CONFIG_USB_XHCI_UNIPHIER - sg_set_pinsel(56, 8, 8, 4); /* USB0VBUS -> USB0VBUS */ - sg_set_pinsel(57, 8, 8, 4); /* USB0OD -> USB0OD */ - sg_set_pinsel(58, 8, 8, 4); /* USB1VBUS -> USB1VBUS */ - sg_set_pinsel(59, 8, 8, 4); /* USB1OD -> USB1OD */ - sg_set_pinsel(60, 8, 8, 4); /* USB2VBUS -> USB2VBUS */ - sg_set_pinsel(61, 8, 8, 4); /* USB2OD -> USB2OD */ - sg_set_pinsel(62, 8, 8, 4); /* USB3VBUS -> USB3VBUS */ -
[U-Boot] [PATCH v2 06/13] usb: dwc3: add UniPhier specific glue layer
Add UniPhier platform specific glue layer to support USB3 Host mode on Synopsys DWC3 IP. Signed-off-by: Masahiro YamadaReviewed-by: Marek Vasut --- Changes in v2: - Fix build error - Add missing PHY reset deassert drivers/usb/host/Kconfig | 7 +++ drivers/usb/host/Makefile| 1 + drivers/usb/host/dwc3-uniphier.c | 119 +++ 3 files changed, 127 insertions(+) create mode 100644 drivers/usb/host/dwc3-uniphier.c diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 89580cc..a6645dd 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -24,6 +24,13 @@ config USB_XHCI_DWC3 Say Y or if your system has a Dual Role SuperSpeed USB controller based on the DesignWare USB3 IP Core. +config USB_DWC3_UNIPHIER + bool "DesignWare USB3 Host Support on UniPhier Platforms" + depends on ARCH_UNIPHIER && USB_XHCI_DWC3 + help + Support of USB2/3 functionality in Socionext UniPhier platforms. + Say 'Y' here if you have one such device. + endif config USB_OHCI_GENERIC diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 620d114..8b54fde 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -56,6 +56,7 @@ obj-$(CONFIG_USB_EHCI_ZYNQ) += ehci-zynq.o # xhci obj-$(CONFIG_USB_XHCI_HCD) += xhci.o xhci-mem.o xhci-ring.o obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o +obj-$(CONFIG_USB_DWC3_UNIPHIER) += dwc3-uniphier.o obj-$(CONFIG_USB_XHCI_ZYNQMP) += xhci-zynqmp.o obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o diff --git a/drivers/usb/host/dwc3-uniphier.c b/drivers/usb/host/dwc3-uniphier.c new file mode 100644 index 000..e0358ac --- /dev/null +++ b/drivers/usb/host/dwc3-uniphier.c @@ -0,0 +1,119 @@ +/* + * UniPhier Specific Glue Layer for DWC3 + * + * Copyright (C) 2016 Socionext Inc. + * Author: Masahiro Yamada + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include + +#define UNIPHIER_PRO4_DWC3_RESET 0x40 +#define UNIPHIER_PRO4_DWC3_RESET_XIOMMU BIT(5) +#define UNIPHIER_PRO4_DWC3_RESET_XLINK BIT(4) +#define UNIPHIER_PRO4_DWC3_RESET_PHY_SS BIT(2) + +#define UNIPHIER_PRO5_DWC3_RESET 0x00 +#define UNIPHIER_PRO5_DWC3_RESET_PHY_S1 BIT(17) +#define UNIPHIER_PRO5_DWC3_RESET_PHY_S0 BIT(16) +#define UNIPHIER_PRO5_DWC3_RESET_XLINK BIT(15) +#define UNIPHIER_PRO5_DWC3_RESET_XIOMMU BIT(14) + +#define UNIPHIER_PXS2_DWC3_RESET 0x00 +#define UNIPHIER_PXS2_DWC3_RESET_XLINK BIT(15) + +static int uniphier_pro4_dwc3_init(void __iomem *regs) +{ + u32 tmp; + + tmp = readl(regs + UNIPHIER_PRO4_DWC3_RESET); + tmp &= ~UNIPHIER_PRO4_DWC3_RESET_PHY_SS; + tmp |= UNIPHIER_PRO4_DWC3_RESET_XIOMMU | UNIPHIER_PRO4_DWC3_RESET_XLINK; + writel(tmp, regs + UNIPHIER_PRO4_DWC3_RESET); + + return 0; +} + +static int uniphier_pro5_dwc3_init(void __iomem *regs) +{ + u32 tmp; + + tmp = readl(regs + UNIPHIER_PRO5_DWC3_RESET); + tmp &= ~(UNIPHIER_PRO5_DWC3_RESET_PHY_S1 | +UNIPHIER_PRO5_DWC3_RESET_PHY_S0); + tmp |= UNIPHIER_PRO5_DWC3_RESET_XLINK | UNIPHIER_PRO5_DWC3_RESET_XIOMMU; + writel(tmp, regs + UNIPHIER_PRO5_DWC3_RESET); + + return 0; +} + +static int uniphier_pxs2_dwc3_init(void __iomem *regs) +{ + u32 tmp; + + tmp = readl(regs + UNIPHIER_PXS2_DWC3_RESET); + tmp |= UNIPHIER_PXS2_DWC3_RESET_XLINK; + writel(tmp, regs + UNIPHIER_PXS2_DWC3_RESET); + + return 0; +} + +static int uniphier_dwc3_probe(struct udevice *dev) +{ + fdt_addr_t base; + void __iomem *regs; + int (*init)(void __iomem *regs); + int ret; + + base = dev_get_addr(dev); + if (base == FDT_ADDR_T_NONE) + return -EINVAL; + + regs = map_sysmem(base, SZ_32K); + if (!regs) + return -ENOMEM; + + init = (int (*)(void __iomem *regs))dev_get_driver_data(dev); + ret = init(regs); + if (ret) { + dev_err(dev, "failed to init glue layer\n"); + return ret; + } + + unmap_sysmem(regs); + + return 0; +} + +static const struct udevice_id uniphier_dwc3_match[] = { + { + .compatible = "socionext,uniphier-pro4-dwc3", + .data = (ulong)uniphier_pro4_dwc3_init, + }, + { + .compatible = "socionext,uniphier-pro5-dwc3", + .data = (ulong)uniphier_pro5_dwc3_init, + }, + { + .compatible = "socionext,uniphier-pxs2-dwc3", + .data = (ulong)uniphier_pxs2_dwc3_init, + }, + { + .compatible = "socionext,uniphier-ld20-dwc3", + .data = (ulong)uniphier_pxs2_dwc3_init, + },
[U-Boot] [PATCH v2 01/13] configs: blackfin: move CONFIG_USB to defconfig
These Blackfin boards are the last ones that define CONFIG_USB in their headers. Signed-off-by: Masahiro Yamada--- Changes in v2: - Newly added configs/bf526-ezbrd_defconfig| 1 + configs/bf527-ezkit-v2_defconfig | 1 + configs/bf527-ezkit_defconfig| 1 + configs/bf548-ezkit_defconfig| 1 + include/configs/bf526-ezbrd.h| 1 - include/configs/bf527-ezkit.h| 1 - include/configs/bf548-ezkit.h| 1 - 7 files changed, 4 insertions(+), 3 deletions(-) diff --git a/configs/bf526-ezbrd_defconfig b/configs/bf526-ezbrd_defconfig index 85c2a6b..ea4f8e4 100644 --- a/configs/bf526-ezbrd_defconfig +++ b/configs/bf526-ezbrd_defconfig @@ -17,3 +17,4 @@ CONFIG_CMD_FAT=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SST=y +CONFIG_USB=y diff --git a/configs/bf527-ezkit-v2_defconfig b/configs/bf527-ezkit-v2_defconfig index ff797f8..faac28d 100644 --- a/configs/bf527-ezkit-v2_defconfig +++ b/configs/bf527-ezkit-v2_defconfig @@ -17,4 +17,5 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_USB=y CONFIG_LIB_RAND=y diff --git a/configs/bf527-ezkit_defconfig b/configs/bf527-ezkit_defconfig index eff2a12..d69b146 100644 --- a/configs/bf527-ezkit_defconfig +++ b/configs/bf527-ezkit_defconfig @@ -17,3 +17,4 @@ CONFIG_NET_RANDOM_ETHADDR=y # CONFIG_NET_TFTP_VARS is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_USB=y diff --git a/configs/bf548-ezkit_defconfig b/configs/bf548-ezkit_defconfig index 6d398ac..e4fa136 100644 --- a/configs/bf548-ezkit_defconfig +++ b/configs/bf548-ezkit_defconfig @@ -16,5 +16,6 @@ CONFIG_CMD_EXT2=y CONFIG_CMD_FAT=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_USB=y CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED=y CONFIG_LIB_RAND=y diff --git a/include/configs/bf526-ezbrd.h b/include/configs/bf526-ezbrd.h index 74c3464..cf8ef8a 100644 --- a/include/configs/bf526-ezbrd.h +++ b/include/configs/bf526-ezbrd.h @@ -125,7 +125,6 @@ * USB Settings */ #if !defined(__ADSPBF522__) && !defined(__ADSPBF523__) -#define CONFIG_USB #define CONFIG_USB_MUSB_HCD #define CONFIG_USB_BLACKFIN #define CONFIG_USB_STORAGE diff --git a/include/configs/bf527-ezkit.h b/include/configs/bf527-ezkit.h index e268473..c958a94 100644 --- a/include/configs/bf527-ezkit.h +++ b/include/configs/bf527-ezkit.h @@ -128,7 +128,6 @@ * USB Settings */ #if !defined(__ADSPBF522__) && !defined(__ADSPBF523__) -#define CONFIG_USB #define CONFIG_USB_MUSB_HCD #define CONFIG_USB_BLACKFIN #define CONFIG_USB_STORAGE diff --git a/include/configs/bf548-ezkit.h b/include/configs/bf548-ezkit.h index 6830e4d..be28ea3 100644 --- a/include/configs/bf548-ezkit.h +++ b/include/configs/bf548-ezkit.h @@ -151,7 +151,6 @@ * USB Settings */ #if !defined(__ADSPBF544__) -#define CONFIG_USB #define CONFIG_USB_MUSB_HCD #define CONFIG_USB_BLACKFIN #define CONFIG_USB_STORAGE -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/13] usb: xhci: add struct devrequest declaration to xhci.h
If xhci.h is included without include/usb.h, the compiler complains like follows: warning: 'struct devrequest' declared inside parameter list We have two options to teach the compiler that devrequest is a structure: [1] Declare "struct devrequest;" in xhci.h [2] Include from xhci.h This commit takes [1] because nothing else in xhci.h depends on include/usb.h. [2] would require the compiler additional header parsing. Signed-off-by: Masahiro Yamada--- Changes in v2: - Rephrase git-log drivers/usb/host/xhci.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 2afa386..16dd61a 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1252,6 +1252,8 @@ void xhci_acknowledge_event(struct xhci_ctrl *ctrl); union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected); int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe, int length, void *buffer); + +struct devrequest; int xhci_ctrl_tx(struct usb_device *udev, unsigned long pipe, struct devrequest *req, int length, void *buffer); int xhci_check_maxpacket(struct usb_device *udev); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/13] ARM: uniphier: enable DWC3 xHCI driver
Enable CONFIGs for the DWC3 core and UniPhier specific glue layer. Signed-off-by: Masahiro Yamada--- Changes in v2: None configs/uniphier_ld20_defconfig | 2 ++ configs/uniphier_pro4_defconfig | 2 ++ configs/uniphier_pxs2_ld6b_defconfig | 2 ++ 3 files changed, 6 insertions(+) diff --git a/configs/uniphier_ld20_defconfig b/configs/uniphier_ld20_defconfig index cbc65dd..ecf5649 100644 --- a/configs/uniphier_ld20_defconfig +++ b/configs/uniphier_ld20_defconfig @@ -27,4 +27,6 @@ CONFIG_SPL_PINCTRL=y CONFIG_UNIPHIER_SERIAL=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_DWC3_UNIPHIER=y CONFIG_USB_STORAGE=y diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig index 18f4caf..c9d104b 100644 --- a/configs/uniphier_pro4_defconfig +++ b/configs/uniphier_pro4_defconfig @@ -31,4 +31,6 @@ CONFIG_SPL_PINCTRL=y CONFIG_UNIPHIER_SERIAL=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_DWC3_UNIPHIER=y CONFIG_USB_STORAGE=y diff --git a/configs/uniphier_pxs2_ld6b_defconfig b/configs/uniphier_pxs2_ld6b_defconfig index cf6d3e4..8356437 100644 --- a/configs/uniphier_pxs2_ld6b_defconfig +++ b/configs/uniphier_pxs2_ld6b_defconfig @@ -32,4 +32,6 @@ CONFIG_SPL_PINCTRL=y CONFIG_UNIPHIER_SERIAL=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_DWC3_UNIPHIER=y CONFIG_USB_STORAGE=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 05/13] usb: dwc3: change DWC3 core support code into a driver
Synopsys DWC3 IP generally works with an SoC-specific glue layer. DT binding for that is like this: usb3_glue { compatible = "foo,dwc3"; ... usb3 { compatible = "snps,dwc3"; ... }; }; The glue layer initializes some SoC-specific parts, then populates the child DWC3 core. To see how it works, refer to drivers/usb/dwc3/dwc3-exynos.c drivers/usb/dwc3/dwc3-keystone.c drivers/usb/dwc3/dwc3-omap.c drivers/usb/dwc3/dwc3-st.c of Linux Kernel. This commit implements a driver compatible with "snps,dwc3", allowing to use the same binding in U-Boot. The glue layer can be simply implemented based on Simple Bus Uclass. Signed-off-by: Masahiro YamadaReviewed-by: Marek Vasut --- Changes in v2: None drivers/usb/host/xhci-dwc3.c | 71 +++- 1 file changed, 70 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c index 33961cd..c7c8324 100644 --- a/drivers/usb/host/xhci-dwc3.c +++ b/drivers/usb/host/xhci-dwc3.c @@ -9,8 +9,13 @@ */ #include -#include +#include +#include +#include #include +#include + +#include "xhci.h" void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode) { @@ -97,3 +102,67 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val) setbits_le32(_reg->g_fladj, GFLADJ_30MHZ_REG_SEL | GFLADJ_30MHZ(val)); } + +struct dwc3_priv { + struct xhci_ctrl ctrl; /* should be the first member */ + void __iomem *regs; +}; + +static int dwc3_probe(struct udevice *dev) +{ + struct dwc3_priv *priv = dev_get_priv(dev); + struct xhci_hccr *hccr; + struct xhci_hcor *hcor; + fdt_addr_t base; + int ret; + + base = dev_get_addr(dev); + if (base == FDT_ADDR_T_NONE) + return -EINVAL; + + priv->regs = map_sysmem(base, SZ_32K); + if (!priv->regs) + return -ENOMEM; + + hccr = priv->regs; + + hcor = priv->regs + HC_LENGTH(xhci_readl(>cr_capbase)); + + ret = dwc3_core_init(priv->regs + DWC3_REG_OFFSET); + if (ret) { + puts("XHCI: failed to initialize controller\n"); + return ret; + } + + /* We are hard-coding DWC3 core to Host Mode */ + dwc3_set_mode(priv->regs + DWC3_REG_OFFSET, DWC3_GCTL_PRTCAP_HOST); + + return xhci_register(dev, hccr, hcor); +} + +static int dwc3_remove(struct udevice *dev) +{ + struct dwc3_priv *priv = dev_get_priv(dev); + + xhci_deregister(dev); + unmap_sysmem(priv->regs); + + return 0; +} + +static const struct udevice_id of_dwc3_match[] = { + { .compatible = "snps,dwc3" }, + { .compatible = "synopsys,dwc3" }, + { /* sentinel */ } +}; + +U_BOOT_DRIVER(dwc3) = { + .name = "dwc3", + .id = UCLASS_USB, + .of_match = of_dwc3_match, + .probe = dwc3_probe, + .remove = dwc3_remove, + .ops = _usb_ops, + .priv_auto_alloc_size = sizeof(struct dwc3_priv), + .flags = DM_FLAG_ALLOC_PRIV_DMA, +}; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/13] ARM: uniphier: switch over to USB DM
Now UniPhier platform can completely switch over to Driver Model USB, which allows ARCH_UNIPHIER select DM_USB. Drop CONFIG_DM_USB=y of two of UniPhier defconfig files. Signed-off-by: Masahiro Yamada--- Changes in v2: None arch/arm/Kconfig| 1 + configs/uniphier_ld4_sld8_defconfig | 1 - configs/uniphier_sld3_defconfig | 1 - 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6b65d8e..59410cb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -723,6 +723,7 @@ config ARCH_UNIPHIER select DM_SERIAL select DM_I2C select DM_MMC + select DM_USB help Support for UniPhier SoC family developed by Socionext Inc. (formerly, System LSI Business Division of Panasonic Corporation) diff --git a/configs/uniphier_ld4_sld8_defconfig b/configs/uniphier_ld4_sld8_defconfig index 22615a6..d13d112 100644 --- a/configs/uniphier_ld4_sld8_defconfig +++ b/configs/uniphier_ld4_sld8_defconfig @@ -31,7 +31,6 @@ CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_UNIPHIER_SERIAL=y CONFIG_USB=y -CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_STORAGE=y diff --git a/configs/uniphier_sld3_defconfig b/configs/uniphier_sld3_defconfig index 0965019..accbd8a 100644 --- a/configs/uniphier_sld3_defconfig +++ b/configs/uniphier_sld3_defconfig @@ -28,7 +28,6 @@ CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 CONFIG_SPL_NAND_DENALI=y CONFIG_UNIPHIER_SERIAL=y CONFIG_USB=y -CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_STORAGE=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
On 16.05.16 14:04, Bhupesh Sharma wrote: > > >> -Original Message- >> From: Alexander Graf [mailto:ag...@suse.de] >> Sent: Monday, May 16, 2016 1:09 PM >> To: Amit Tomer>> Cc: Bhupesh Sharma ; york sun >> ; u-boot@lists.denx.de; Peter Newton >> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot >> >> >> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer : >>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma >> wrote: Note that UEFI firmware support is already available on LS2080A-RDB and allows Booting distributions like CentOS on the same. >>> >>> Sorry to intervene here but it's about having the EFI support inside >>> u-boot itself that may *not* required to have separate UEFI firmware >>> to boot various distributions. >>> >>> Please correct, if it's not right ? >> >> It's correct. The idea is to allow everyone to boot using the uEFI >> entry point in Linux (or any other OS), regardless of whether they want >> to run U-Boot or a TianoCore based formware. >> >> This might seem useless today for embedded use cases, but some features >> are only available via an EFI entry, such as kASLR. You can also invoke >> Linux directly using the "bootefi" command, as Linux is an EFI binary >> itself. That way the boot path doesn't become much longer than with >> booti today. >> > > The default firmware being offered by NXP to boot distros on LS2080A and > variants is UEFI. > > EFI application support in u-boot doesn't present a solution to things like > run-time variable/service > support that is required by distros to update firmware components on the go. > And there are several > other services being offered by UEFI to help distro boot e.g. secure uefi > boot through x.509 certifications > compliant to UEFI specifications. Don't get me wrong - I think it's great if there is a TianoCore based firmware for LS2080A. But I didn't get the impression that there is a TianoCore based firmware for every NXP SoC out there, so enabling all of them to use the U-Boot provided uEFI implementation is still a win. That said, there's nothing that keeps us from implementing the bits you mentioned in U-Boot either. There is support for RTS in U-Boot, we just didn't convert any drivers (RTC comes to mind first) yet. There's also no support for uEFI environment variables, but mostly because most systems I've used this code on so far just didn't have any storage to put them. Certification checks also shouldn't be an issue if someone cared enough about them. But I don't think we need a discussion of TianoCore vs U-Boot. What everyone really wants is to have things "just work". And some customers just prefer U-Boot for various reasons that are outside of my control. If they can run the same boot path as everyone else, it makes life for me as distribution vendor easier. And unlike other people in the community, I don't think being a TianoCore+ACPI messiah is any helpful for that goal. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Monday, May 16, 2016 1:09 PM > To: Amit Tomer> Cc: Bhupesh Sharma ; york sun > ; u-boot@lists.denx.de; Peter Newton > > Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot > > > > > Am 16.05.2016 um 08:58 schrieb Amit Tomer : > > > >> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma > wrote: > >> Note that UEFI firmware support is already available on LS2080A-RDB > >> and allows Booting distributions like CentOS on the same. > > > > Sorry to intervene here but it's about having the EFI support inside > > u-boot itself that may *not* required to have separate UEFI firmware > > to boot various distributions. > > > > Please correct, if it's not right ? > > It's correct. The idea is to allow everyone to boot using the uEFI > entry point in Linux (or any other OS), regardless of whether they want > to run U-Boot or a TianoCore based formware. > > This might seem useless today for embedded use cases, but some features > are only available via an EFI entry, such as kASLR. You can also invoke > Linux directly using the "bootefi" command, as Linux is an EFI binary > itself. That way the boot path doesn't become much longer than with > booti today. > The default firmware being offered by NXP to boot distros on LS2080A and variants is UEFI. EFI application support in u-boot doesn't present a solution to things like run-time variable/service support that is required by distros to update firmware components on the go. And there are several other services being offered by UEFI to help distro boot e.g. secure uefi boot through x.509 certifications compliant to UEFI specifications. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
Hi Scott, On Tue, 03 May 2016 00:06:45 -0500 Scott Woodwrote: > On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote: > > On Mon, 25 Apr 2016 13:36:46 -0400 > > Tom Rini wrote: > > > > > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote: > > > > > > > Hi Scott, > > > > > > > > I've recently contributed a lot of MTD/NAND related patches (and intend > > > > to continue doing so). Some of them are transversal changes touching the > > > > MTD and NAND framework internals, which implies patching all NAND > > > > drivers along with the core changes. > > > > > > > > All those changes are required to properly handle modern NANDs (MLC/TLC > > > > NANDs), and I need them to add proper NAND support to the sunxi > > > > platform (and more particularly to the C.H.I.P from NextThing Co.). > > > > > > > > So my question is, how should I port those changes to U-Boot? I see > > > > that your doing "synchronization commits", but in my case this mean > > > > including a bunch of driver specific changes into this "sync commit". > > > > > > > > I think it's also worth mentioning that I plan to heavily rework the > > > > Linux NAND framework to improve NAND performances on modern NAND > > > > controllers and clarify the NAND chip / NAND controller concepts, and > > > > other people are also working on merging the BBT code of the NAND and > > > > OneNAND framework. Which unfortunately means that we're not done porting > > > > invasive changes to U-Boot :-/. > > > > > > > > Any advice is welcome. > > > > > > I suppose my first suggestion would be to sync the kernel back into > > > U-Boot more frequently. With our bi-monthly release cycle it shouldn't > > > be too hard to pick a window to grab the current kernel release and > > > bring it over. I think the more stuff we let build up prior to syncing > > > the harder it will be. > > > > > > > Okay, so this means I should be the one back-porting Linux changes into > > U-Boot? I was planning on porting my current work on the sunxi NAND > > driver (including all the core dependencies) and submitting it to > > U-Boot, but honestly, I don't see how I can keep things in sync in the > > long run. From my experience, porting things to U-Boot is never as > > easy at it seems, and I don't think I'll have the time to maintain that > > by myself. Scott, what's your policy regarding Linux -> U-Boot syncs? > > Can I expect some help from your side? > > I usually do syncs when someone complains about needing a sync. Every release > seems a bit much. I'll try to do one soon. Sorry to bother you with that, but can I ask when you plan to do this sync (I guess you'll sync with 4.6)? As I explained, I depend on features introduced in 4.6 to make the sunxi NAND driver usable on sunxi based boards (the concept of data randomizer/scrambler is required on some MLC NANDs, and most Allwinner boards embed this kind of NAND chips). Don't hesitate to let me know if you need some help. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration
Hi Roger, On Monday 16 May 2016 04:01 PM, Roger Quadros wrote: > On 16/05/16 13:03, Kishon Vijay Abraham I wrote: >> Hi Roger, >> >> On Monday 16 May 2016 03:19 PM, Roger Quadros wrote: >>> On 16/05/16 12:26, Roger Quadros wrote: On 16/05/16 12:06, Roger Quadros wrote: > On 13/05/16 15:45, Marek Vasut wrote: >> On 05/13/2016 02:36 PM, Roger Quadros wrote: >>> Currently CONFIG_USB_DWC3 is not selected so doing a usb start >>> command results in a serious error [1]. >> >> Why does this error happen ? That is what should be fixed. Selecting >> some random options seems like papering over a bug. > > Agreed. I was lazy :P. OK. The issue is like this. CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c which calls board_usb_init(). >> >> IIRC, board_usb_init for xhci (omap) is mostly a NOP. > > Then who will call board_usb_init() for host case? > But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 is defined and that is missing in am57xx_evm.h leading to the serious error. We're trying to access the IP without turning on the necessary clocks. >> >> clocks are not turned on in board_usb_init() right? The board_usb_init() in >> am57xx/board.c is used only for gadget mode. So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or something else. >> >> right, but before that we might have to cleanup xhci-omap. But then again looking into the future, what if we want only gadget operation? That would not define XHCI, but we still need board_usb_init(). So board_usb_init() should be defined based on CONFIG_CMD_USB=y? What do you suggest? >>> >>> But board_usb_init() calls >>> >>> ti_usb_phy_uboot_init(_phy1_device); >>> dwc3_omap_uboot_init(_otg_ss1_glue); >>> dwc3_uboot_init(_otg_ss1); >>> >>> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and >>> CONFIG_USB_DWC3 >>> respectively. >> >> IMO we should cleanup xhci-omap so that all the initializations are done >> using >> ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify >> dwc3_uboot_init to initialize host or device based on CONFIG_*. >> > > I'm still trying to get a grip of how USB works in u-boot. > Is CONFIG_CMD_USB only meant for host mode or gadget mode as well? IIRC it is only for host. Commands like usb start, usb stop are used to start and stop host. > Is dual-role even required in u-boot? probably it is not a good idea and we > just > ignore it for simplicity. yeah. > > What determines whether a USB port is meant for Host or device operation? Is > it > the CONFIG_ or caller of board_usb_init()? It should be the caller of board_usb_init(). The same port can be used as device or host based on command used (the command determines the caller of board_usb_init). Thanks Kishon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration
Hi Roger, On Monday 16 May 2016 03:19 PM, Roger Quadros wrote: > On 16/05/16 12:26, Roger Quadros wrote: >> On 16/05/16 12:06, Roger Quadros wrote: >>> On 13/05/16 15:45, Marek Vasut wrote: On 05/13/2016 02:36 PM, Roger Quadros wrote: > Currently CONFIG_USB_DWC3 is not selected so doing a usb start > command results in a serious error [1]. Why does this error happen ? That is what should be fixed. Selecting some random options seems like papering over a bug. >>> >>> Agreed. I was lazy :P. >> >> OK. The issue is like this. >> >> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls >> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c which >> calls >> board_usb_init(). IIRC, board_usb_init for xhci (omap) is mostly a NOP. >> >> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 is >> defined >> and that is missing in am57xx_evm.h leading to the serious error. We're >> trying to >> access the IP without turning on the necessary clocks. clocks are not turned on in board_usb_init() right? The board_usb_init() in am57xx/board.c is used only for gadget mode. >> >> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or >> something else. right, but before that we might have to cleanup xhci-omap. >> >> But then again looking into the future, what if we want only gadget >> operation? >> That would not define XHCI, but we still need board_usb_init(). So >> board_usb_init() >> should be defined based on CONFIG_CMD_USB=y? >> >> What do you suggest? > > But board_usb_init() calls > > ti_usb_phy_uboot_init(_phy1_device); > dwc3_omap_uboot_init(_otg_ss1_glue); > dwc3_uboot_init(_otg_ss1); > > which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and > CONFIG_USB_DWC3 > respectively. IMO we should cleanup xhci-omap so that all the initializations are done using ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify dwc3_uboot_init to initialize host or device based on CONFIG_*. Thanks Kishon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration
On 16/05/16 13:03, Kishon Vijay Abraham I wrote: > Hi Roger, > > On Monday 16 May 2016 03:19 PM, Roger Quadros wrote: >> On 16/05/16 12:26, Roger Quadros wrote: >>> On 16/05/16 12:06, Roger Quadros wrote: On 13/05/16 15:45, Marek Vasut wrote: > On 05/13/2016 02:36 PM, Roger Quadros wrote: >> Currently CONFIG_USB_DWC3 is not selected so doing a usb start >> command results in a serious error [1]. > > Why does this error happen ? That is what should be fixed. Selecting > some random options seems like papering over a bug. Agreed. I was lazy :P. >>> >>> OK. The issue is like this. >>> >>> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls >>> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c >>> which calls >>> board_usb_init(). > > IIRC, board_usb_init for xhci (omap) is mostly a NOP. Then who will call board_usb_init() for host case? >>> >>> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 >>> is defined >>> and that is missing in am57xx_evm.h leading to the serious error. We're >>> trying to >>> access the IP without turning on the necessary clocks. > > clocks are not turned on in board_usb_init() right? The board_usb_init() in > am57xx/board.c is used only for gadget mode. >>> >>> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or >>> something else. > > right, but before that we might have to cleanup xhci-omap. >>> >>> But then again looking into the future, what if we want only gadget >>> operation? >>> That would not define XHCI, but we still need board_usb_init(). So >>> board_usb_init() >>> should be defined based on CONFIG_CMD_USB=y? >>> >>> What do you suggest? >> >> But board_usb_init() calls >> >> ti_usb_phy_uboot_init(_phy1_device); >> dwc3_omap_uboot_init(_otg_ss1_glue); >> dwc3_uboot_init(_otg_ss1); >> >> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and >> CONFIG_USB_DWC3 >> respectively. > > IMO we should cleanup xhci-omap so that all the initializations are done using > ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify > dwc3_uboot_init to initialize host or device based on CONFIG_*. > I'm still trying to get a grip of how USB works in u-boot. Is CONFIG_CMD_USB only meant for host mode or gadget mode as well? Is dual-role even required in u-boot? probably it is not a good idea and we just ignore it for simplicity. What determines whether a USB port is meant for Host or device operation? Is it the CONFIG_ or caller of board_usb_init()? I see board_usb_init() being used by gadget drivers, host drivers, dfu.c, etc. cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 16.05.16 07:28, Huan Wang wrote: >> On 13.05.16 10:40, Alison Wang wrote: >>> To support loading a 32-bit OS, the execution state will change from >>> AArch64 to AArch32 when jumping to kernel. >>> >>> The architecture information will be got through checking FIT image, >>> then U-Boot will load 32-bit OS or 64-bit OS automatically. >>> >>> Signed-off-by: Ebony Zhu>>> Signed-off-by: Alison Wang >>> Signed-off-by: Chenhui Zhao >>> --- >>> arch/arm/cpu/armv8/transition.S | 100 >> >>> arch/arm/include/asm/system.h | 2 + >>> arch/arm/lib/bootm.c| 20 +++- >>> common/image-fit.c | 12 - >>> 4 files changed, 131 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/arm/cpu/armv8/transition.S >>> b/arch/arm/cpu/armv8/transition.S index 253a39b..9d7a17a 100644 >>> --- a/arch/arm/cpu/armv8/transition.S >>> +++ b/arch/arm/cpu/armv8/transition.S >>> @@ -21,3 +21,103 @@ ENTRY(armv8_switch_to_el1) >>> 0: ret >>> 1: armv8_switch_to_el1_m x0, x1 >>> ENDPROC(armv8_switch_to_el1) >>> + >>> +/* >>> + * x0: kernel entry point >>> + * x1: machine nr >>> + * x2: fdt address >>> + */ >>> +ENTRY(armv8_switch_to_el2_aarch32) >>> + switch_el x3, 1f, 0f, 0f >>> +0: ret >>> +1: >>> + mov x7, x0 >>> + mov x8, x1 >>> + mov x9, x2 >>> + >>> + /* 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 >> */ >>> + mov x1, 0x1b1 >>> + msr scr_el3, x1 >>> + msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ >>> + mov x1, 0x33ff >>> + msr cptr_el2, x1/* Disable coprocessor traps to EL2 */ >>> + >>> + /* Initialize Generic Timers */ >>> + msr cntvoff_el2, xzr >>> + >>> + mov x1, #0x0830 >>> + movkx1, #0x30c5, lsl #16 >>> + msr sctlr_el2, x1 >> >> Why is this necessary? > [Alison Wang] SCTLR_EL2 is architecturally mapped to AArch32 register HSCTLR. > HSCTLR will provide control of the system operation in Hyp mode. It still doesn't explain why you move magical values into a random register that is not set in the 64-bit path. Please make this code more readable :). Try to #define values for the bits that you set. Add comments explaining why you do what you do. >> >>> + >>> + /* Return to AArch32 Hypervisor mode */ >>> + mov x1, sp >>> + msr sp_el2, x1 >>> + mrs x1, vbar_el3 >>> + msr vbar_el2, x1/* Migrate VBAR */ >>> + mov x1, #0x1da >>> + msr spsr_el3, x1 >>> + msr elr_el3, x7 >>> + >>> + mov x0, #0 >>> + mov x1, x8 >>> + mov x2, x9 >>> + >>> + eret >>> +ENDPROC(armv8_switch_to_el2_aarch32) >> >> This whole thing looks like a copy of armv8_switch_to_el2_m. Just >> parameterize that one and put the few bits that are different in macro >> ifs. > [Alison Wang] Yes, they are similar because they both switch from EL3 to EL2. > But some bits are different because one switch from AArch64 EL3 to AArch64 EL2 > and the other switch from AArch64 EL3 to AArch32 EL2. The parameters need to > use too. Yes, so I think it makes a lot of sense to combine the jump-to-64-bit-el2 and jump-to-32-bit-el2 functions be a single implementation. That way there's less chance an accidental difference creeps in. >> >>> + >>> +/* >>> + * x0: kernel entry point >>> + * x1: machine nr >>> + * x2: fdt address >>> + */ >>> +ENTRY(armv8_switch_to_el1_aarch32) >>> + switch_el x3, 0f, 1f, 0f >>> +0: ret >>> +1: >>> + mov x7, x0 >>> + mov x8, x1 >>> + mov x9, x2 >>> + >>> + /* Initialize Generic Timers */ >>> + mrs x0, cnthctl_el2 >>> + orr x0, x0, #0x3/* Enable EL1 access to timers */ >>> + msr cnthctl_el2, x0 >>> + msr cntvoff_el2, xzr >>> + >>> +/* Initialize MPID/MPIDR registers */ >>> + mrs x0, midr_el1 >>> + mrs x1, mpidr_el1 >>> + msr vpidr_el2, x0 >>> + msr vmpidr_el2, x1 >>> + >>> +/* Disable coprocessor traps */ >>> + mov x0, #0x33ff >>> + msr cptr_el2, x0/* Disable coprocessor traps to EL2 */ >>> +msrhstr_el2, xzr /* Disable coprocessor traps >> to EL2 */ >>> +movx0, #3 << 20 >>> +msrcpacr_el1, x0 /* Enable FP/SIMD at EL1 */ >>> + >>> + /* Initialize HCR_EL2 */ >>> + mov x0, #(0 << 31) /* 32bit EL1 */ >>> + orr x0, x0, #(1 << 29) /* Disable HVC */ >>> + msr hcr_el2, x0 >>> + >>> + mov x0, #0x0800 >>> + movkx0, #0x30d0, lsl #16 >>> + msr sctlr_el1, x0 >>> + >>> + /* Return to AArch32 Supervisor mode */ >>> + mov x0, sp >>> + msr sp_el1, x0 /* Migrate SP */ >>> + mrs x0, vbar_el2 >>> + msr vbar_el1, x0/* Migrate VBAR */ >>> + mov x0, #0x1d3 >>> + msr spsr_el2, x0 >>> + msr elr_el2, x7 >>> + >>> + mov x0, #0 >>> + mov x1, x8 >>> +
[U-Boot] [PATCH 4/5] malta: Remove ".set mips32" directive
We always build for a mips32 or higher ISA, so this ".set mips32" directive is redundant. Once MIPSr6 support is added it will become harmful since some instruction encodings change & this directive will cause the older encodings to be incorrectly emitted instead of the appropriate ones for the build. In preparation for supporting MIPSr6, remove this redundant directive. Signed-off-by: Paul Burton--- board/imgtec/malta/lowlevel_init.S | 1 - 1 file changed, 1 deletion(-) diff --git a/board/imgtec/malta/lowlevel_init.S b/board/imgtec/malta/lowlevel_init.S index ae09c27..534db1d 100644 --- a/board/imgtec/malta/lowlevel_init.S +++ b/board/imgtec/malta/lowlevel_init.S @@ -24,7 +24,6 @@ .text .set noreorder - .set mips32 .globl lowlevel_init lowlevel_init: -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] MIPS Release 6 Support
This series introduces support for building U-Boot for release 6 of the MIPS architecture. This is supported by CPUs such as the M62xx, I6400 & P6600 as well as by emulators such as QEMU. Paul Burton (5): MIPS: Use unchecked immediate addition/subtraction MIPS: Simplify CONFIG_SYS_CPU values MIPS: Support for targetting MIPSr6 malta: Remove ".set mips32" directive malta: Support MIPS32r6 configurations arch/mips/Kconfig | 39 ++ arch/mips/Makefile | 2 ++ arch/mips/cpu/start.S | 22 +++-- arch/mips/lib/cache_init.S | 2 +- board/imgtec/malta/lowlevel_init.S | 1 - 5 files changed, 46 insertions(+), 20 deletions(-) -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] malta: Support MIPS32r6 configurations
Both real Malta boards & QEMU's Malta emulation can feature MIPS32r6 CPUs. Allow building U-Boot for such systems by selecting CONFIG_SUPPORTS_CPU_MIPS32_R6 for Malta. Signed-off-by: Paul Burton--- arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index e53fa83..fbf3e4c 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -28,6 +28,7 @@ config TARGET_MALTA select SUPPORTS_LITTLE_ENDIAN select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 + select SUPPORTS_CPU_MIPS32_R6 select SWAP_IO_SPACE select MIPS_L1_CACHE_SHIFT_6 -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] MIPS: Simplify CONFIG_SYS_CPU values
Rather than having the values for CONFIG_SYS_CPU depend upon each architecture revision, have them depend upon the more general CONFIG_CPU_MIPS32 & CONFIG_CPU_MIPS64 which in turn depend upon the architecture revisions. This is done in preparation for adding MIPSr6 support, which would otherwise need to introduce new cases here. Signed-off-by: Paul Burton--- arch/mips/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index fe37d1f..0520b30 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -5,8 +5,8 @@ config SYS_ARCH default "mips" config SYS_CPU - default "mips32" if CPU_MIPS32_R1 || CPU_MIPS32_R2 - default "mips64" if CPU_MIPS64_R1 || CPU_MIPS64_R2 + default "mips32" if CPU_MIPS32 + default "mips64" if CPU_MIPS64 choice prompt "Target select" -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] MIPS: Support for targetting MIPSr6
Add support for targetting MIPS32r6 & MIPS64r6 systems, in the same way that we currently select release 1 or release 2 targets. MIPSr6 is not entirely backwards compatible with earlier releases of the architecture. Some instructions are encoded differently, some are removed, some are reused, so it is not practical to run U-Boot built for earlier revisions on a MIPSr6 system. Update their Kconfig help text to reflect that. Signed-off-by: Paul Burton--- arch/mips/Kconfig | 34 -- arch/mips/Makefile | 2 ++ 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 0520b30..e53fa83 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -98,7 +98,7 @@ config CPU_MIPS32_R1 depends on SUPPORTS_CPU_MIPS32_R1 select 32BIT help - Choose this option to build an U-Boot for release 1 or later of the + Choose this option to build an U-Boot for release 1 through 5 of the MIPS32 architecture. config CPU_MIPS32_R2 @@ -106,7 +106,15 @@ config CPU_MIPS32_R2 depends on SUPPORTS_CPU_MIPS32_R2 select 32BIT help - Choose this option to build an U-Boot for release 2 or later of the + Choose this option to build an U-Boot for release 2 through 5 of the + MIPS32 architecture. + +config CPU_MIPS32_R6 + bool "MIPS32 Release 6" + depends on SUPPORTS_CPU_MIPS32_R6 + select 32BIT + help + Choose this option to build an U-Boot for release 6 or later of the MIPS32 architecture. config CPU_MIPS64_R1 @@ -114,7 +122,7 @@ config CPU_MIPS64_R1 depends on SUPPORTS_CPU_MIPS64_R1 select 64BIT help - Choose this option to build a kernel for release 1 or later of the + Choose this option to build a kernel for release 1 through 5 of the MIPS64 architecture. config CPU_MIPS64_R2 @@ -122,7 +130,15 @@ config CPU_MIPS64_R2 depends on SUPPORTS_CPU_MIPS64_R2 select 64BIT help - Choose this option to build a kernel for release 2 or later of the + Choose this option to build a kernel for release 2 through 5 of the + MIPS64 architecture. + +config CPU_MIPS64_R6 + bool "MIPS64 Release 6" + depends on SUPPORTS_CPU_MIPS64_R6 + select 64BIT + help + Choose this option to build a kernel for release 6 or later of the MIPS64 architecture. endchoice @@ -169,19 +185,25 @@ config SUPPORTS_CPU_MIPS32_R1 config SUPPORTS_CPU_MIPS32_R2 bool +config SUPPORTS_CPU_MIPS32_R6 + bool + config SUPPORTS_CPU_MIPS64_R1 bool config SUPPORTS_CPU_MIPS64_R2 bool +config SUPPORTS_CPU_MIPS64_R6 + bool + config CPU_MIPS32 bool - default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 + default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R6 config CPU_MIPS64 bool - default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 + default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R6 config MIPS_TUNE_4KC bool diff --git a/arch/mips/Makefile b/arch/mips/Makefile index aec5a15..c822178 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -18,8 +18,10 @@ PLATFORM_CPPFLAGS += $(patsubst %,-I$(srctree)/%include,$(machdirs)) # Optimize for MIPS architectures arch-$(CONFIG_CPU_MIPS32_R1) += -march=mips32 -Wa,-mips32 arch-$(CONFIG_CPU_MIPS32_R2) += -march=mips32r2 -Wa,-mips32r2 +arch-$(CONFIG_CPU_MIPS32_R6) += -march=mips32r6 -Wa,-mips32r6 arch-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 -Wa,-mips64 arch-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,-mips64r2 +arch-$(CONFIG_CPU_MIPS64_R6) += -march=mips64r6 -Wa,-mips64r6 # Allow extra optimization for specific CPUs/SoCs tune-$(CONFIG_MIPS_TUNE_4KC) += -mtune=4kc -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] MIPS: Use unchecked immediate addition/subtraction
In MIPS assembly there have historically been 2 variants of immediate addition - the standard "addi" which traps if an overflow occurs, and the unchecked "addiu" which does not trap on overflow. In release 6 of the MIPS architecture the trapping variants of immediate addition & subtraction have been removed. In preparation for supporting MIPSr6, stop using the trapping instructions from assembly & switch to their unchecked variants. Signed-off-by: Paul Burton--- arch/mips/cpu/start.S | 22 -- arch/mips/lib/cache_init.S | 2 +- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S index 1b56ca3..fc6dd66 100644 --- a/arch/mips/cpu/start.S +++ b/arch/mips/cpu/start.S @@ -164,12 +164,14 @@ reset: li t0, -16 PTR_LI t1, CONFIG_SYS_INIT_SP_ADDR and sp, t1, t0 # force 16 byte alignment - PTR_SUB sp, sp, GD_SIZE # reserve space for gd + PTR_SUBU \ + sp, sp, GD_SIZE # reserve space for gd and sp, sp, t0 # force 16 byte alignment movek0, sp # save gd pointer #ifdef CONFIG_SYS_MALLOC_F_LEN li t2, CONFIG_SYS_MALLOC_F_LEN - PTR_SUB sp, sp, t2 # reserve space for early malloc + PTR_SUBU \ + sp, sp, t2 # reserve space for early malloc and sp, sp, t0 # force 16 byte alignment #endif movefp, sp @@ -179,7 +181,7 @@ reset: 1: PTR_S zero, 0(t0) blt t0, t1, 1b -PTR_ADDI t0, PTRSIZE +PTR_ADDIU t0, PTRSIZE #ifdef CONFIG_SYS_MALLOC_F_LEN PTR_S sp, GD_MALLOC_BASE(k0) # gd->malloc_base offset @@ -237,7 +239,7 @@ ENTRY(relocate_code) move a0, s2 # a0 <-- destination address /* Jump to where we've relocated ourselves */ - PTR_ADDI t0, s2, in_ram - _start + PTR_ADDIU t0, s2, in_ram - _start jr t0 nop @@ -257,7 +259,7 @@ in_ram: PTR_L t3, -(1 * PTRSIZE)(t0) # t3 <-- num_got_entries PTR_L t8, -(2 * PTRSIZE)(t0) # t8 <-- _GLOBAL_OFFSET_TABLE_ PTR_ADD t8, s1 # t8 now holds relocated _G_O_T_ - PTR_ADDI t8, t8, 2 * PTRSIZE# skipping first two entries + PTR_ADDIU t8, t8, 2 * PTRSIZE # skipping first two entries PTR_LI t2, 2 1: PTR_L t1, 0(t8) @@ -265,16 +267,16 @@ in_ram: PTR_ADD t1, s1 PTR_S t1, 0(t8) 2: - PTR_ADDI t2, 1 + PTR_ADDIU t2, 1 blt t2, t3, 1b -PTR_ADDI t8, PTRSIZE +PTR_ADDIU t8, PTRSIZE /* Update dynamic relocations */ PTR_L t1, -(4 * PTRSIZE)(t0) # t1 <-- __rel_dyn_start PTR_L t2, -(5 * PTRSIZE)(t0) # t2 <-- __rel_dyn_end b 2f # skip first reserved entry -PTR_ADDI t1, 2 * PTRSIZE +PTR_ADDIU t1, 2 * PTRSIZE 1: lw t8, -4(t1) # t8 <-- relocation info @@ -293,7 +295,7 @@ in_ram: 2: blt t1, t2, 1b -PTR_ADDI t1, 2 * PTRSIZE # each rel.dyn entry is 2*PTRSIZE bytes +PTR_ADDIU t1, 2 * PTRSIZE # each rel.dyn entry is 2*PTRSIZE bytes /* * Clear BSS @@ -307,7 +309,7 @@ in_ram: 1: PTR_S zero, 0(t1) blt t1, t2, 1b -PTR_ADDI t1, PTRSIZE +PTR_ADDIU t1, PTRSIZE movea0, s0 # a0 <-- gd movea1, s2 diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index 14cc2c4..08b7c3a 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -64,7 +64,7 @@ /* detect associativity */ srl \sz, $1, \off + MIPS_CONF1_DA_SHF - MIPS_CONF1_DA_SHF andi\sz, \sz, (MIPS_CONF1_DA >> MIPS_CONF1_DA_SHF) - addi\sz, \sz, 1 + addiu \sz, \sz, 1 /* sz *= line_sz */ mul \sz, \sz, \line_sz -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sunxi: Increase SPL header size to 64 bytes to avoid code corruption
Given that there now are quite a few additional "reserved" entries, and while we're still at SPL_HEADER_VERSION 1, I'd like to renew my request of dedicating one of these fields to the script length - which would enable us to set the U-Boot ${filesize} accordingly. i.e. --- arch-arm-include-asm-arch-sunxi-spl.h +++ arch-arm-include-asm-arch-sunxi-spl.new.h @@ -49,7 +49,8 @@ uint8_t spl_signature[4]; }; uint32_t fel_script_address; - uint32_t reserved1[3]; + uint32_t fel_script_length; + uint32_t reserved1[2]; uint32_t boot_media;/* written here by the boot ROM */ uint32_t reserved2[5]; /* padding, align to 64 bytes */ }; I do not intend to further push my specific use cases, however I still consider the (then somewhat theoretical) ability to do "import -t ${fel_script_addr} ${filesize}" useful. For reference, the previous discussion related to this was somewhere around http://lists.denx.de/pipermail/u-boot/2015-September/227454.html Regards, B. Nortmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] x86: qemu: split qfw command interface and qfw core
Hi Bin, 2016-05-16 16:47 GMT+08:00 Bin Meng: > Hi Miao, > > On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: >> This patch splits qfw command interface and qfw core function into two >> files, and introduces a new Kconfig option (CONFIG_QFW). for >> qfw core. >> >> Now when qfw command interface is enabled, it will automatically select >> qfw core. This patch also makes the ACPI table generation select >> CONFIG_QFW. >> >> Signed-off-by: Miao Yan >> --- >> arch/x86/Kconfig | 2 +- >> arch/x86/cpu/mp_init.c | 6 +- >> arch/x86/cpu/qemu/Makefile | 3 +- >> arch/x86/cpu/qemu/acpi_table.c | 2 + >> arch/x86/cpu/qemu/qemu.c | 4 + >> cmd/Kconfig| 1 + >> cmd/Makefile | 2 +- >> cmd/cmd_qfw.c | 182 + > > The file name should be qfw.c without cmd_ > >> cmd/qemu_fw_cfg.c | 353 >> - > > And I suspect you can also use "git mv" for cmd/qemu_fw_cfg.c. "git mv > cmd/qemu_fw_cfg.c cmd/qfw.c" But there is already a qfw.c under driver/misc/, having two files using the same name seems a bit confusing. Thanks, Miao > >> common/Kconfig | 1 + >> drivers/misc/Kconfig | 6 + >> drivers/misc/Makefile | 1 + >> drivers/misc/qemu_fw_cfg.c | 185 + >> 13 files changed, 390 insertions(+), 358 deletions(-) >> create mode 100644 cmd/cmd_qfw.c >> delete mode 100644 cmd/qemu_fw_cfg.c >> create mode 100644 drivers/misc/qemu_fw_cfg.c >> > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration
On 16/05/16 12:26, Roger Quadros wrote: > On 16/05/16 12:06, Roger Quadros wrote: >> On 13/05/16 15:45, Marek Vasut wrote: >>> On 05/13/2016 02:36 PM, Roger Quadros wrote: Currently CONFIG_USB_DWC3 is not selected so doing a usb start command results in a serious error [1]. >>> >>> Why does this error happen ? That is what should be fixed. Selecting >>> some random options seems like papering over a bug. >> >> Agreed. I was lazy :P. > > OK. The issue is like this. > > CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls > usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c which > calls > board_usb_init(). > > But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 is > defined > and that is missing in am57xx_evm.h leading to the serious error. We're > trying to > access the IP without turning on the necessary clocks. > > So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or > something else. > > But then again looking into the future, what if we want only gadget operation? > That would not define XHCI, but we still need board_usb_init(). So > board_usb_init() > should be defined based on CONFIG_CMD_USB=y? > > What do you suggest? But board_usb_init() calls ti_usb_phy_uboot_init(_phy1_device); dwc3_omap_uboot_init(_otg_ss1_glue); dwc3_uboot_init(_otg_ss1); which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and CONFIG_USB_DWC3 respectively. So I really don't know how to fix all this. -- cheers, -roger >> >>> Fix that by enabling CONFIG_USB_DWC3 and other related options CONFIG_USB_DWC3_PHY_OMAP and CONFIG_USB_DWC3_OMAP. [1] => usb start starting USB... USB0: data abort pc : [] lr : [] reloc pc : [<8081dd10>]lr : [<8081dbbf>] sp : fef3d260 ip : fp : fef3d2a8 r10: fffa4610 r9 : fef50ed0 r8 : r7 : fef3d280 r6 : fef3d284 r5 : fffbc380 r4 : r3 : 4888 r2 : r1 : r0 : fffbc380 Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Signed-off-by: Roger Quadros--- include/configs/am57xx_evm.h | 3 +++ 1 file changed, 3 insertions(+) >>> >>> Changelog is missing ;-) >>> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h index 32d7d4d..939057c 100644 --- a/include/configs/am57xx_evm.h +++ b/include/configs/am57xx_evm.h @@ -63,6 +63,7 @@ #define CONFIG_SUPPORT_EMMC_BOOT /* USB xHCI HOST */ +#define CONFIG_USB_DWC3 #define CONFIG_USB_HOST #define CONFIG_USB_XHCI_DWC3 #define CONFIG_USB_XHCI @@ -72,6 +73,8 @@ #define CONFIG_OMAP_USB_PHY #define CONFIG_OMAP_USB3PHY1_HOST +#define CONFIG_USB_DWC3_PHY_OMAP +#define CONFIG_USB_DWC3_OMAP /* SATA */ #define CONFIG_BOARD_LATE_INIT >>> >>> >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] cmd: qfw: remove qemu_fwcfg_free_files()
2016-05-14 4:46 GMT+08:00 Tom Rini: > On Fri, May 13, 2016 at 10:00:05PM +0800, Bin Meng wrote: >> Hi Miao, >> >> On Fri, May 13, 2016 at 2:29 PM, Miao Yan wrote: >> > This patch is part of the qfw refactor work. >> > >> > The qemu_fwcfg_free_files() function is only used in error handling in >> > ACPI table generation, let's not make this a core function and move it >> > to the right place. >> > >> >> But I suspect this API may still be needed in some other scenarioes? >> eg: for future ARM64 ACPI? > > Yes, as it stands currently the code looks likely useful for non-x86 > QEMU+ACPI. ARM64 and x86 should be able to share common ACPI code. As for now, this function is not used anywhere but error handling in only one place. I'd prefer not to make this public. Thanks, Miao > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot