Re: [U-Boot] [v2 PATCH 14/14] config: sandbox: enable qfw and cmd_qfw for testing
Hi Bin, 2016-05-20 10:29 GMT+08:00 Bin Meng : > Hi Miao, > > On Fri, May 20, 2016 at 10:06 AM, Miao Yan wrote: >> Hi Bin, >> >> 2016-05-19 17:08 GMT+08:00 Bin Meng : >>> Hi Miao, >>> >>> On Wed, May 18, 2016 at 5:40 PM, Miao Yan wrote: This patch enables qfw and cmd_qfw on sandbox for build coverage test Signed-off-by: Miao Yan --- configs/sandbox_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index afdf4a3..f19308d 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -167,3 +167,5 @@ CONFIG_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y CONFIG_UT_ENV=y +CONFIG_QFW=y +CONFIG_CMD_QFW=y -- >>> >>> Please do a 'make savedefconfig' and check the Kconfig options. >> >> I did a 'make savedefconfig' and there was a file generated >> 'defconfig' but with zero content. So what am I supposed to check ? >> Did you find something wrong with this one ? >> > > We need make sure the option order is correct in a defconfig file. Can you elaborate on this, what're the rules to add new config in sandbox_defconfig ? Is is based on the order in kconfig file ? > > We can do it like this: > > $ make sandbox_defconfig > $ make savedefconfig > > Then check the difference between our updated sandbox_defconfig and > defconfig files. And they are supposed to be identical ? Thanks, Miao > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
> On 05/19/2016 10:26 AM, 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 > > --- > > Changes in v2: > > - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is > used > >to switch to AArch64 EL2 or AArch32 Hyp. > > - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is > used > >to switch to AArch64 EL1 or AArch32 SVC. > > > > arch/arm/cpu/armv8/transition.S | 8 ++--- > > arch/arm/include/asm/macro.h| 80 > + > > arch/arm/include/asm/system.h | 25 +++-- > > arch/arm/lib/bootm.c| 26 +++--- > > common/image-fit.c | 12 ++- > > 5 files changed, 133 insertions(+), 18 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/transition.S > > b/arch/arm/cpu/armv8/transition.S index 253a39b..9fa3b59 100644 > > --- a/arch/arm/cpu/armv8/transition.S > > +++ b/arch/arm/cpu/armv8/transition.S > > @@ -11,13 +11,13 @@ > > #include > > > > ENTRY(armv8_switch_to_el2) > > - switch_el x0, 1f, 0f, 0f > > + switch_el x4, 1f, 0f, 0f > > 0:ret > > -1: armv8_switch_to_el2_m x0 > > +1: armv8_switch_to_el2_m x0, x1, x2, x3, x4, x5, x6 > > ENDPROC(armv8_switch_to_el2) > > > > ENTRY(armv8_switch_to_el1) > > - switch_el x0, 0f, 1f, 0f > > + switch_el x4, 0f, 1f, 0f > > 0:ret > > -1: armv8_switch_to_el1_m x0, x1 > > +1: armv8_switch_to_el1_m x0, x1, x2, x3, x4, x5, x6 > > ENDPROC(armv8_switch_to_el1) > > diff --git a/arch/arm/include/asm/macro.h > > b/arch/arm/include/asm/macro.h index 9bb0efa..56d77f6 100644 > > --- a/arch/arm/include/asm/macro.h > > +++ b/arch/arm/include/asm/macro.h > > @@ -8,6 +8,9 @@ > > > > #ifndef __ASM_ARM_MACRO_H__ > > #define __ASM_ARM_MACRO_H__ > > + > > +#include > > + > > #ifdef __ASSEMBLY__ > > > > /* > > @@ -135,9 +138,20 @@ lr .reqx30 > > #endif > > .endm > > > > -.macro armv8_switch_to_el2_m, xreg1 > > - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 > */ > > - mov \xreg1, #0x5b1 > > +.macro armv8_switch_to_el2_m, xreg1, xreg2, xreg3, xreg4, xreg5, > > +xreg6, xreg7 > > These arguments should probably get documented :). Also xreg4 doesn't > seem to actually be a scratch register, but a real parameter. So please > name it accordingly. [Alison Wang] Ok, I will add the descriptions for these arguments. Not only xreg4, xreg1, xreg2 and xreg3 are real parameters too. I will rename them in the next version. > > > + mov \xreg5, \xreg1 > > + mov \xreg6, \xreg2 > > + mov \xreg7, \xreg3 > > + > > + /* > > +* If the next lower exception level is AArch64, 64bit EL2 | HCE | > SMD | > > +* RES1 (Bits[5:4]) | Non-secure EL0/EL1. If the next lower > exception > > +* level is AArch32, 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | > > +* Non-secure EL0/EL1. > > +*/ > > + mov \xreg1, #0x1b1 > > + lsl \xreg2, \xreg4, #10 > > + orr \xreg1, \xreg1, \xreg2 > > Is there any way you can make this obvious from the code? Basically we > would want something like > > mov \xreg1, #(SCR_EL3_EL2_AA64 | SCR_EL3_HCE | SCR_EL3_SMD ...) > > I'm sure there are creative ways to achieve this even with the high bits > set. Maybe ldr = works? [Alison Wang] Yes, I will change them and make them obvious. > > > msr scr_el3, \xreg1 > > msr cptr_el3, xzr /* Disable coprocessor traps to EL3 > */ > > mov \xreg1, #0x33ff > > @@ -156,18 +170,46 @@ lr.reqx30 > > movk\xreg1, #0x30C5, lsl #16 > > msr sctlr_el2, \xreg1 > > > > - /* Return to the EL2_SP2 mode from EL3 */ > > mov \xreg1, sp > > msr sp_el2, \xreg1 /* Migrate SP */ > > mrs \xreg1, vbar_el3 > > msr vbar_el2, \xreg1/* Migrate VBAR */ > > + > > + /* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */ > > + ldr \xreg1, =ES_TO_AARCH64 > > + cmp \xreg4, \xreg1 > > + b.eq1f > > + b.ne2f > > Just b.ne should be enough, no? [Alison Wang] Yes, you are right. > > > + > > +1: > > + /* Return to the EL2_SP2 mode from EL3 */ > > mov \xreg1, #0x3c9 > > Magic values again :). Please convert them to constants getting ORed. [Alison Wang] Ok, I will change the original magic values too. > > > msr spsr_el3, \xreg1/* EL2_SP2 | D | A | I | F */ > > msr elr_el3, lr > > + > > + mov \xreg1, \xreg5 > > + mov \xreg2, \xreg6 > > + mov \xreg3, \xreg7 > > + eret > > + > > +2: > > + /* Return to AArch32 Hypervisor mode */ > > + mov \xreg1, #0x1da > > + msr spsr_el3, \xreg1/* Hyp | D | A | I | F */ > > +
Re: [U-Boot] [PATCH 0/2] Add support for Amlogic Meson MMC controller
Applied this on my Odroid C2, and it worked OK when installed on the SDcard, but failed when installed on the eMMC module: => version U-Boot 2016.05-rc3 (May 14 2016 - 21:06:28 -0700) odroid-c2 aarch64-linux-gnu-gcc (GCC) 5.3.1 20160212 (Red Hat Cross 5.3.1-2) GNU ld version 2.26.20160125 => mmc info Card did not respond to voltage select! Robert Gadsdon. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
On 19.5.2016 21:26, Andreas Dannenberg wrote: > Hi Michael, > > On Thu, May 19, 2016 at 08:33:28PM +0200, Michal Simek wrote: >> Hi Andreas, >> >> 2016-05-19 20:16 GMT+02:00 Andreas Dannenberg : >> >>> Hi Michal, >>> >>> On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote: On 19.5.2016 18:15, Andreas Dannenberg wrote: > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote: >> Support loading FIT in SPL for RAM bootmode. >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored >> in memory. >> >> Signed-off-by: Michal Simek >> Reviewed-by: Simon Glass >> --- > > Reviewed-by: Andreas Dannenberg > > > That's a very useful addition to the SPL FIT toolbox! I have a use case > where I may need to decrypt/authenticate an SPL FIT image in its >>> entirety > before processing it so this can be used for this as well. Do you have also use case where you need to load more files from FIT? There is loadable entry in FIT config entry. >>> >>> Not yet but I may get there. I'm experimenting with using U-Boot to load >>> and install a secure monitor mode application (specifically, OP-TEE OS), >>> so that will need to come from somewhere eventually and FIT would be a >>> natural place for that binary to reside since we can easily authenticate >>> it. >> >> >> ok what arch? >> What's the flow which you want to support? >> SPL to load OPTEE and ATF and full u-boot and jump to ATF which runs OPTEE >> and run to U-Boot? > > I working with TI's current SoCs and those are ARMv7-A and there is no > ATF but instead a proprietary solution comprising ROM code and some > low-level code that gets loaded/authenticated/executed by said ROM in a > secure fashion before the regular boot flow starts (SPL, U-Boot, and so > on). There is flexibility to load/install a new secure monitor code > during SPL, U-Boot, or in fact at any other time (even after let's say > Linux is booted up) but from an overall system architecture POV we need > that new secure monitor (OP-TEE OS in this case) to be up before the > Kernel is loaded. > > Anyways the goal is not only to get it working but also to have a > solution that plays nice with everything else and can be contributed > upstream. Ok. I see. I will definitely keep my eyes on this one. Because I have sent SPL for ZynqMP and if you look closely to setting I use without FIT falcon bootmode to be able to load ATF and full u-boot to the memory. For FIT I have sent patches to extend format with fpga part which bootm supports. I have also additional patches (not in mainline) to load bitstream from SPL. But the goal should be that SPL will be able to load FPGA and several images. Just to make long story short support fpga and loadables sections in FIT format. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform 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] [PATCH v5 02/12] spi: davinci_spi: Convert to driver to adapt to DM
Convert davinci_spi driver so that it complies with SPI DM framework.
Signed-off-by: Vignesh R
Reviewed-by: Tom Rini
---
v5: correct error message.
v4: Check error returned by dev_map_physmem().
v3: No changes
v2: Add comments to struct davinci_spi_slave members.
Use dev_map_physmem() added by previous patch.
drivers/spi/davinci_spi.c | 329 +-
1 file changed, 240 insertions(+), 89 deletions(-)
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 0bd4f88926f1..22274c91a2f1 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* SPIGCR0 */
#define SPIGCR0_SPIENA_MASK0x1
@@ -51,6 +52,7 @@
/* SPIDEF */
#define SPIDEF_CSDEF0_MASK BIT(0)
+#ifndef CONFIG_DM_SPI
#define SPI0_BUS 0
#define SPI0_BASE CONFIG_SYS_SPI_BASE
/*
@@ -83,6 +85,9 @@
#define SPI2_NUM_CSCONFIG_SYS_SPI2_NUM_CS
#define SPI2_BASE CONFIG_SYS_SPI2_BASE
#endif
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
/* davinci spi register set */
struct davinci_spi_regs {
@@ -114,16 +119,17 @@ struct davinci_spi_regs {
/* davinci spi slave */
struct davinci_spi_slave {
+#ifndef CONFIG_DM_SPI
struct spi_slave slave;
+#endif
struct davinci_spi_regs *regs;
- unsigned int freq;
+ unsigned int freq; /* current SPI bus frequency */
+ unsigned int mode; /* current SPI mode used */
+ u8 num_cs; /* total no. of CS available */
+ u8 cur_cs; /* CS of current slave */
+ bool half_duplex; /* true, if master is half-duplex only */
};
-static inline struct davinci_spi_slave *to_davinci_spi(struct spi_slave *slave)
-{
- return container_of(slave, struct davinci_spi_slave, slave);
-}
-
/*
* This functions needs to act like a macro to avoid pipeline reloads in the
* loops below. Use always_inline. This gains us about 160KiB/s and the bloat
@@ -144,15 +150,14 @@ static inline u32 davinci_spi_xfer_data(struct
davinci_spi_slave *ds, u32 data)
return buf_reg_val;
}
-static int davinci_spi_read(struct spi_slave *slave, unsigned int len,
+static int davinci_spi_read(struct davinci_spi_slave *ds, unsigned int len,
u8 *rxp, unsigned long flags)
{
- struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
/* enable CS hold, CS[n] and clear the data bits */
data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
-(slave->cs << SPIDAT1_CSNR_SHIFT));
+(ds->cur_cs << SPIDAT1_CSNR_SHIFT));
/* wait till TXFULL is deasserted */
while (readl(&ds->regs->buf) & SPIBUF_TXFULL_MASK)
@@ -175,15 +180,14 @@ static int davinci_spi_read(struct spi_slave *slave,
unsigned int len,
return 0;
}
-static int davinci_spi_write(struct spi_slave *slave, unsigned int len,
+static int davinci_spi_write(struct davinci_spi_slave *ds, unsigned int len,
const u8 *txp, unsigned long flags)
{
- struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
/* enable CS hold and clear the data bits */
data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
-(slave->cs << SPIDAT1_CSNR_SHIFT));
+(ds->cur_cs << SPIDAT1_CSNR_SHIFT));
/* wait till TXFULL is deasserted */
while (readl(&ds->regs->buf) & SPIBUF_TXFULL_MASK)
@@ -209,16 +213,15 @@ static int davinci_spi_write(struct spi_slave *slave,
unsigned int len,
return 0;
}
-#ifndef CONFIG_SPI_HALF_DUPLEX
-static int davinci_spi_read_write(struct spi_slave *slave, unsigned int len,
- u8 *rxp, const u8 *txp, unsigned long flags)
+static int davinci_spi_read_write(struct davinci_spi_slave *ds, unsigned
+ int len, u8 *rxp, const u8 *txp,
+ unsigned long flags)
{
- struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
/* enable CS hold and clear the data bits */
data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
-(slave->cs << SPIDAT1_CSNR_SHIFT));
+(ds->cur_cs << SPIDAT1_CSNR_SHIFT));
/* wait till TXFULL is deasserted */
while (readl(&ds->regs->buf) & SPIBUF_TXFULL_MASK)
@@ -237,7 +240,115 @@ static int davinci_spi_read_write(struct spi_slave
*slave, unsigned int len,
return 0;
}
-#endif
+
+
+static int __davinci_spi_claim_bus(struct davinci_spi_slave *ds, int cs)
+{
+ unsigned int mode = 0, scalar;
+
+ /* Enable the SPI hardware */
+ writel(SPIGCR0_SPIRST_MASK, &ds->regs->gcr0);
+ udelay(1000);
+ writel(SPIGCR0_SPIENA_MASK, &ds->regs->gcr0);
+
+ /* Set master mode, powered up and not activated */
Re: [U-Boot] [PATCH] net: Add ag7xxx driver for Atheros MIPS
On 05/08/2016 11:22 PM, Marek Vasut wrote: On 05/08/2016 02:58 PM, Daniel Schwierzeck wrote: Hi! Am 05.05.2016 um 21:34 schrieb Marek Vasut: Add ethernet driver for the AR933x and AR934x Atheros MIPS machines. The driver could be easily extended to other WiSoCs. How to make this patch work on ar933x board? I apply this patch on the top of mips/next branch and enable this option in menuconfig, but i can't see any boot information for Ethernet. By the way, the DT node "compatible" in driver is different from arch/mips/dts/ar933x.dtsi, and the following compiling error occur because of commit 4feefdcfe916113ac6e1837ea22857f25fe1771c: drivers/usb/host/built-in.o: In function `ehci_usb_probe': drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x40): undefined reference to `clk_get_by_index' drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x4c): undefined reference to `clk_get_by_index' drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x60): undefined reference to `clk_enable' drivers/usb/host/ehci-generic.c:(.text.ehci_usb_probe+0x68): undefined reference to `clk_enable' -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: fix ifdef in ARMv8 lowlevel_init() again
Commit 116611937faa ("ARM: fix ifdefs in ARMv8 lowlevel_init()")
accidentally inverted the logic of CONFIG_ARMV8_MULTIENTRY.
Fixes: 116611937faa ("ARM: fix ifdefs in ARMv8 lowlevel_init()")
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Rephrase subject
arch/arm/cpu/armv8/start.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index c3cc819..e933021 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -216,7 +216,7 @@ WEAK(lowlevel_init)
#endif
#endif
-#ifndef CONFIG_ARMV8_MULTIENTRY
+#ifdef CONFIG_ARMV8_MULTIENTRY
branch_if_master x0, x1, 2f
/*
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: ARM: fix ifdefs in ARMv8 lowlevel_init() again
Commit 116611937faa ("ARM: fix ifdefs in ARMv8 lowlevel_init()")
accidentally inverted the logic of CONFIG_ARMV8_MULTIENTRY.
Fixes: 116611937faa ("ARM: fix ifdefs in ARMv8 lowlevel_init()")
Signed-off-by: Masahiro Yamada
---
arch/arm/cpu/armv8/start.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index c3cc819..e933021 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -216,7 +216,7 @@ WEAK(lowlevel_init)
#endif
#endif
-#ifndef CONFIG_ARMV8_MULTIENTRY
+#ifdef CONFIG_ARMV8_MULTIENTRY
branch_if_master x0, x1, 2f
/*
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 13/14] cmd: qfw: rename QEMU_FW_CFG to CMD_QFW
2016-05-20 10:30 GMT+08:00 Bin Meng : > Hi Miao, > > On Fri, May 20, 2016 at 10:07 AM, Miao Yan wrote: >> Hi Bin, >> >> 2016-05-19 17:08 GMT+08:00 Bin Meng : >>> Hi Miao, >>> >>> the title should say: CMD_QEMU_FW_CFG >>> >>> I can fix this when applying. >>> >>> On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote: Align macro names with the rest of qfw code >>> >>> and I believe it's better to squash this commit into patch#8 in this >>> series, as they both rename QEMU_FW_CFG to QFW. >> >> Thanks. Do I need a v3 ? >> > > If you have time, let's do a v3 which saves my time. Sorry :( OK, no problem. Miao > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 13/14] cmd: qfw: rename QEMU_FW_CFG to CMD_QFW
Hi Miao, On Fri, May 20, 2016 at 10:07 AM, Miao Yan wrote: > Hi Bin, > > 2016-05-19 17:08 GMT+08:00 Bin Meng : >> Hi Miao, >> >> the title should say: CMD_QEMU_FW_CFG >> >> I can fix this when applying. >> >> On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote: >>> Align macro names with the rest of qfw code >>> >> >> and I believe it's better to squash this commit into patch#8 in this >> series, as they both rename QEMU_FW_CFG to QFW. > > Thanks. Do I need a v3 ? > If you have time, let's do a v3 which saves my time. Sorry :( Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 14/14] config: sandbox: enable qfw and cmd_qfw for testing
Hi Miao, On Fri, May 20, 2016 at 10:06 AM, Miao Yan wrote: > Hi Bin, > > 2016-05-19 17:08 GMT+08:00 Bin Meng : >> Hi Miao, >> >> On Wed, May 18, 2016 at 5:40 PM, Miao Yan wrote: >>> This patch enables qfw and cmd_qfw on sandbox for build coverage test >>> >>> Signed-off-by: Miao Yan >>> --- >>> configs/sandbox_defconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig >>> index afdf4a3..f19308d 100644 >>> --- a/configs/sandbox_defconfig >>> +++ b/configs/sandbox_defconfig >>> @@ -167,3 +167,5 @@ CONFIG_UNIT_TEST=y >>> CONFIG_UT_TIME=y >>> CONFIG_UT_DM=y >>> CONFIG_UT_ENV=y >>> +CONFIG_QFW=y >>> +CONFIG_CMD_QFW=y >>> -- >> >> Please do a 'make savedefconfig' and check the Kconfig options. > > I did a 'make savedefconfig' and there was a file generated > 'defconfig' but with zero content. So what am I supposed to check ? > Did you find something wrong with this one ? > We need make sure the option order is correct in a defconfig file. We can do it like this: $ make sandbox_defconfig $ make savedefconfig Then check the difference between our updated sandbox_defconfig and defconfig files. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 13/14] cmd: qfw: rename QEMU_FW_CFG to CMD_QFW
Hi Bin, 2016-05-19 17:08 GMT+08:00 Bin Meng : > Hi Miao, > > the title should say: CMD_QEMU_FW_CFG > > I can fix this when applying. > > On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote: >> Align macro names with the rest of qfw code >> > > and I believe it's better to squash this commit into patch#8 in this > series, as they both rename QEMU_FW_CFG to QFW. Thanks. Do I need a v3 ? Thanks, Miao > >> Signed-off-by: Miao Yan >> --- >> cmd/Kconfig| 2 +- >> cmd/Makefile | 2 +- >> configs/qemu-x86_defconfig | 2 +- >> drivers/misc/Kconfig | 2 +- >> 4 files changed, 4 insertions(+), 4 deletions(-) >> > > Reviewed-by: Bin Meng > > [snip] > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 14/14] config: sandbox: enable qfw and cmd_qfw for testing
Hi Bin, 2016-05-19 17:08 GMT+08:00 Bin Meng : > Hi Miao, > > On Wed, May 18, 2016 at 5:40 PM, Miao Yan wrote: >> This patch enables qfw and cmd_qfw on sandbox for build coverage test >> >> Signed-off-by: Miao Yan >> --- >> configs/sandbox_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig >> index afdf4a3..f19308d 100644 >> --- a/configs/sandbox_defconfig >> +++ b/configs/sandbox_defconfig >> @@ -167,3 +167,5 @@ CONFIG_UNIT_TEST=y >> CONFIG_UT_TIME=y >> CONFIG_UT_DM=y >> CONFIG_UT_ENV=y >> +CONFIG_QFW=y >> +CONFIG_CMD_QFW=y >> -- > > Please do a 'make savedefconfig' and check the Kconfig options. I did a 'make savedefconfig' and there was a file generated 'defconfig' but with zero content. So what am I supposed to check ? Did you find something wrong with this one ? Thanks, Miao > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/15] arm: Kconfig: Add support for AM43xx SoC specific Kconfig
From: Madan Srinivas Adding support for AM43xx secure devices require the addition of some SOC specific config options like the amount of memory used by public ROM and the address of the entry point of u-boot or SPL, as seen by the ROM code, for the image to be built correctly. This mandates the addition of am AM43xx CONFIG option and the ARM Kconfig file has been modified to source this SOC Kconfig file. Moving the TARGET_AM43XX_EVM config option to the SOC KConfig and out of the arch/arm/Kconfig. Updating defconfigs to add the CONFIG_AM43XX=y statement and removing the #define CONFIG_AM43XX from the header file. Signed-off-by: Madan Srinivas Signed-off-by: Daniel Allred Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: Update more defconfigs Replace CREATE_BOARD_SYMLINK with TI_I2C_BOARD_DETECT Rebase against latest master arch/arm/Kconfig | 19 +-- arch/arm/cpu/armv7/am33xx/Kconfig | 13 + 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 + include/configs/am43xx_evm.h | 2 -- 9 files changed, 32 insertions(+), 8 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6b65d8e..6577572 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -381,12 +381,6 @@ config TARGET_AM335X_SL50 select DM select DM_SERIAL -config TARGET_AM43XX_EVM - bool "Support am43xx_evm" - select CPU_V7 - select SUPPORT_SPL - select TI_I2C_BOARD_DETECT - config TARGET_BAV335X bool "Support bav335x" select CPU_V7 @@ -507,6 +501,17 @@ config OMAP54XX select CPU_V7 select SUPPORT_SPL +config AM43XX + bool "AM43XX SoC" + select CPU_V7 + select SUPPORT_SPL + help + Support for AM43xx SOC from Texas Instruments. + The AM43xx high performance SOC features a Cortex-A9 + ARM core, a quad core PRU-ICSS for industrial Ethernet + protocols, dual camera support, optional 3D graphics + and an optional customer programmable secure boot. + config RMOBILE bool "Renesas ARM SoCs" select CPU_V7 @@ -777,6 +782,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig" source "arch/arm/cpu/armv7/omap5/Kconfig" +source "arch/arm/cpu/armv7/am33xx/Kconfig" + source "arch/arm/mach-orion5x/Kconfig" source "arch/arm/cpu/armv7/rmobile/Kconfig" diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig index 39759cd..dc51e9b 100644 --- a/arch/arm/cpu/armv7/am33xx/Kconfig +++ b/arch/arm/cpu/armv7/am33xx/Kconfig @@ -1,3 +1,15 @@ +if AM43XX +config TARGET_AM43XX_EVM + bool "Support am43xx_evm" + select TI_I2C_BOARD_DETECT + help + This option specifies support for the AM43xx + GP and HS EVM development platforms.The AM437x + GP EVM is a standalone test, development, and + evaluation module system that enables developers + to write software and develop hardware around + an AM43xx processor subsystem. + config ISW_ENTRY_ADDR hex "Address in memory or XIP flash of bootloader entry point" help @@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE image, this area is no longer used, and can be reclaimed for run time use by the boot image. default 0x8400 +endif diff --git a/configs/am437x_gp_evm_defconfig b/configs/am437x_gp_evm_defconfig index 03b02ac..f036bc7 100644 --- a/configs/am437x_gp_evm_defconfig +++ b/configs/am437x_gp_evm_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_AM43XX=y CONFIG_TARGET_AM43XX_EVM=y CONFIG_DM_SERIAL=y CONFIG_DM_GPIO=y diff --git a/configs/am437x_sk_evm_defconfig b/configs/am437x_sk_evm_defconfig index 48ec91f..0251270 100644 --- a/configs/am437x_sk_evm_defconfig +++ b/configs/am437x_sk_evm_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_AM43XX=y CONFIG_TARGET_AM43XX_EVM=y CONFIG_DM_SERIAL=y CONFIG_DM_SPI=y diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig index a6ae011..c9b6e6a 100644 --- a/configs/am43xx_evm_defconfig +++ b/configs/am43xx_evm_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_AM43XX=y CONFIG_TARGET_AM43XX_EVM=y CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND" diff --git a/configs/am43xx_evm_ethboot_defconfig b/configs/am43xx_evm_ethboot_defconfig index 662556a..e1499ad 100644 --- a/configs/am43xx_evm_ethboot_defconfig +++ b/configs/am43xx_evm_ethboot_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_AM43XX=y CONFIG_TARGET_AM43XX_EVM=y CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT" diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig index 00fa6be..bda0ae1
[U-Boot] [PATCH v3 14/15] ARM: omap5: add ft_board_setup for dra7xx/am57xx
Adds the board specific ft_board_setup() functions that
are called when CONFIG_OF_BOARD_SETUP is defined. These functions
will currently just call the ft_cpu_setup() function.
Adds CONFIG_OF_BOARD_SETUP to the defconfig files
for dra72_evm, dra74_evm, and am57xx_evm.
Signed-off-by: Daniel Allred
Signed-off-by: Madan Srinivas
Reviewed-by: Tom Rini
---
V3:
None
V2:
Squash commits 14 and 15 from v1 to this one commit
Move CONFIG_OF_BOARD_SETUP to defconfig files, instead of header files
board/ti/am57xx/board.c | 9 +
board/ti/dra7xx/evm.c| 9 +
configs/am57xx_evm_defconfig | 1 +
configs/dra72_evm_defconfig | 1 +
configs/dra74_evm_defconfig | 1 +
5 files changed, 21 insertions(+)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 86b8f6e..9904047 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -686,3 +686,12 @@ int board_early_init_f(void)
return 0;
}
#endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup(blob, bd);
+
+ return 0;
+}
+#endif
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9bd71d8..d01c785 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -718,3 +718,12 @@ int board_early_init_f(void)
return 0;
}
#endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup(blob, bd);
+
+ return 0;
+}
+#endif
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 8fc3ebb..cccdc10 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -9,6 +9,7 @@ CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
# CONFIG_CMD_IMLS is not set
CONFIG_CMD_ASKENV=y
# CONFIG_CMD_FLASH is not set
diff --git a/configs/dra72_evm_defconfig b/configs/dra72_evm_defconfig
index 00c6ac3..c85c0fb 100644
--- a/configs/dra72_evm_defconfig
+++ b/configs/dra72_evm_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
# CONFIG_CMD_IMLS is not set
CONFIG_CMD_ASKENV=y
# CONFIG_CMD_FLASH is not set
diff --git a/configs/dra74_evm_defconfig b/configs/dra74_evm_defconfig
index a11dcd5..fc121a1 100644
--- a/configs/dra74_evm_defconfig
+++ b/configs/dra74_evm_defconfig
@@ -11,6 +11,7 @@ CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_BOOTZ=y
+CONFIG_OF_BOARD_SETUP=y
# CONFIG_CMD_IMLS is not set
CONFIG_CMD_ASKENV=y
# CONFIG_CMD_FLASH is not set
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 08/15] ti: AM43xx: board: Detect AM43xx HS EVM
From: Madan Srinivas
Adds code to detect AM43xx HS EVMS - the string in the
I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
for evm detection, regardless of whether the evm is for
GP or HS parts, and updates board init to use that.
Modifies findfdt command to pick up am437x-gp-evm.dtb for
the HS EVMs also, as the boards are similar except for
some security specific changes around power supply and
enclosure protection.
Signed-off-by: Madan Srinivas
Signed-off-by: Daniel Allred
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
Reviewed-by: Tom Rini
---
V3:
None
V2:
Rebase against current master
board/ti/am43xx/board.c | 4 ++--
board/ti/am43xx/board.h | 14 --
board/ti/am43xx/mux.c| 2 +-
include/configs/am43xx_evm.h | 2 ++
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index d208d2f..7247107 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -341,7 +341,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
if (board_is_eposevm())
return &epos_evm_dpll_ddr[ind];
- else if (board_is_gpevm() || board_is_sk())
+ else if (board_is_evm() || board_is_sk())
return &gp_evm_dpll_ddr;
else if (board_is_idk())
return &idk_dpll_ddr;
@@ -553,7 +553,7 @@ void sdram_init(void)
enable_vtt_regulator();
config_ddr(0, &ioregs_ddr3, NULL, NULL,
&ddr3_emif_regs_400Mhz_beta, 0);
- } else if (board_is_gpevm()) {
+ } else if (board_is_evm()) {
enable_vtt_regulator();
config_ddr(0, &ioregs_ddr3, NULL, NULL,
&ddr3_emif_regs_400Mhz, 0);
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
index 2cf7a77..3f93d13 100644
--- a/board/ti/am43xx/board.h
+++ b/board/ti/am43xx/board.h
@@ -37,14 +37,24 @@ static inline int board_is_idk(void)
return board_ti_is("AM43_IDK");
}
+static inline int board_is_hsevm(void)
+{
+ return board_ti_is("AM43XXHS");
+}
+
+static inline int board_is_evm(void)
+{
+ return board_is_gpevm() || board_is_hsevm();
+}
+
static inline int board_is_evm_14_or_later(void)
{
- return (board_is_gpevm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0);
+ return board_is_evm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0;
}
static inline int board_is_evm_12_or_later(void)
{
- return (board_is_gpevm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0);
+ return board_is_evm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0;
}
void enable_uart0_pin_mux(void);
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index e03b1bc..f26b21e 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -126,7 +126,7 @@ void enable_board_pin_mux(void)
configure_module_pin_mux(i2c0_pin_mux);
configure_module_pin_mux(mdio_pin_mux);
- if (board_is_gpevm()) {
+ if (board_is_evm()) {
configure_module_pin_mux(gpio5_7_pin_mux);
configure_module_pin_mux(rgmii1_pin_mux);
#if defined(CONFIG_NAND)
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 8a48a9a..a54303d 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -289,6 +289,8 @@
"setenv fdtfile am43x-epos-evm.dtb; fi; " \
"if test $board_name = AM43__GP; then " \
"setenv fdtfile am437x-gp-evm.dtb; fi; " \
+ "if test $board_name = AM43XXHS; then " \
+ "setenv fdtfile am437x-gp-evm.dtb; fi; " \
"if test $board_name = AM43__SK; then " \
"setenv fdtfile am437x-sk-evm.dtb; fi; " \
"if test $board_name = AM43_IDK; then " \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/15] doc: Add info on using secure devices from TI
Adds doc/README.ti-secure file to explain in generic terms
how boot images need to be created for secure devices from
Texas Instruments.
Specific details for creating secure boot images for the
AM43xx, DRA7xx and AM57xx secure devices from Texas
Instruments are also provided in the README file.
Secure devices require a security development package (SECDEV)
package that can be downloaded from:
http://www.ti.com/mysecuresoftware
Login is required and access is granted under appropriate NDA
and export control restrictions.
Signed-off-by: Madan Srinivas
Signed-off-by: Daniel Allred
Reviewed-by: Lokesh Vutla
Reviewed-by: Andreas Dannenberg
Reviewed-by: Tom Rini
---
V3:
None
V2:
Minor whitespace fixes
doc/README.ti-secure | 91
1 file changed, 91 insertions(+)
create mode 100644 doc/README.ti-secure
diff --git a/doc/README.ti-secure b/doc/README.ti-secure
new file mode 100644
index 000..7fc9b9b
--- /dev/null
+++ b/doc/README.ti-secure
@@ -0,0 +1,91 @@
+README on how boot images are created for secure TI devices
+
+CONFIG_TI_SECURE_DEVICE:
+Secure TI devices require a boot image that is authenticated by ROM
+code to function. Without this, even JTAG remains locked and the
+device is essentially useless. In order to create a valid boot image for
+a secure device from TI, the initial public software image must be signed
+and combined with various headers, certificates, and other binary images.
+
+Information on the details on the complete boot image format can be obtained
+from Texas Instruments. The tools used to generate boot images for secure
+devices are part of a secure development package (SECDEV) that can be
+downloaded from:
+
+ http://www.ti.com/mysecuresoftware (login required)
+
+The secure development package is access controlled due to NDA and export
+control restrictions. Access must be requested and granted by TI before the
+package is viewable and downloadable. Contact TI, either online or by way
+of a local TI representative, to request access.
+
+When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires
+the presence and use of these tools in order to create a viable boot image.
+The build process will look for the environment variable TI_SECURE_DEV_PKG,
+which should be the path of the installed SECDEV package. If the
+TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't
+point to a valid SECDEV package, a warning is issued during the build to
+indicate that a final secure bootable image was not created.
+
+Within the SECDEV package exists an image creation script:
+
+${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+This is called as part of the SPL/u-boot build process. As the secure boot
+image formats and requirements differ between secure SOC from TI, the
+purpose of this script is to abstract these details as much as possible.
+
+The script is basically the only required interface to the TI SECDEV package
+for secure TI devices.
+
+Invoking the script for AM43xx Secure Devices
+=
+
+create-boot-image.sh
+
+ is a value that specifies the type of the image to generate OR
+the action the image generation tool will take. Valid values are:
+ SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
+ XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
+ ISSW - Generates an image for all other boot modes
+
+ is the full path and filename of the public world boot loader
+binary file (depending on the boot media, this is usually either
+u-boot-spl.bin or u-boot.bin).
+
+ is the full path and filename of the final secure image. The
+output binary images should be used in place of the standard non-secure
+binary images (see the platform-specific user's guides and releases notes
+for how the non-secure images are typically used)
+ u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
+ u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
+ u-boot-spl_HS_ISSW - boot image for all other boot media
+
+ is the address at which SOC ROM should load the
+
+Invoking the script for DRA7xx/AM57xx Secure Devices
+
+
+create-boot-image.sh
+
+ is a value that specifies the type of the image to generate OR
+the action the image generation tool will take. Valid values are:
+ X-LOADER - Generates an image for NOR or QSPI boot modes
+ MLO - Generates an image for SD/MMC/eMMC boot modes
+ ULO - Generates an image for USB/UART peripheral boot modes
+ Note: ULO is not yet used by the u-boot build process
+
+ is the full path and filename of the public world boot loader
+binary file (for this platform, this is always u-boot-spl.bin).
+
+ is the full path and filename of the final secure image. The
+output binary images should be used in place of the standard non-secure
+binary images (see the platf
[U-Boot] [PATCH v3 09/15] defconfig: Add a config for AM43xx secure part
From: Madan Srinivas Adds a new defconfig file for the AM43xx secure device. This is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. Signed-off-by: Daniel Allred Signed-off-by: Madan Srinivas Reviewed-by: Tom Rini --- V3: None V2: Update to create a single HS defconfig, based off of the one DT+DM version for AM57xx. configs/am437x_hs_evm_defconfig | 53 + 1 file changed, 53 insertions(+) create mode 100644 configs/am437x_hs_evm_defconfig diff --git a/configs/am437x_hs_evm_defconfig b/configs/am437x_hs_evm_defconfig new file mode 100644 index 000..c4accb6 --- /dev/null +++ b/configs/am437x_hs_evm_defconfig @@ -0,0 +1,53 @@ +CONFIG_ARM=y +CONFIG_AM43XX=y +CONFIG_TI_SECURE_DEVICE=y +CONFIG_TARGET_AM43XX_EVM=y +CONFIG_DM_SERIAL=y +CONFIG_DM_GPIO=y +CONFIG_SPL_STACK_R_ADDR=0x8200 +# Device tree file can be same on HS evm +CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm" +CONFIG_SPL=y +CONFIG_ISW_ENTRY_ADDR=0x40302ae0 +CONFIG_SPL_STACK_R=y +CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1" +CONFIG_HUSH_PARSER=y +CONFIG_CMD_BOOTZ=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DM=y +CONFIG_DM_MMC=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SYS_NS16550=y +CONFIG_TI_QSPI=y +CONFIG_TIMER=y +CONFIG_OMAP_TIMER=y +CONFIG_USB=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_DWC3_OMAP=y +CONFIG_USB_DWC3_PHY_OMAP=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_G_DNL_MANUFACTURER="Texas Instruments" +CONFIG_G_DNL_VENDOR_NUM=0x0403 +CONFIG_G_DNL_PRODUCT_NUM=0xbd00 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 11/15] spl: build: ti: add support for secure boot images
Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE is in use (which it should be when building for secure parts), the TI secure development package is used to create a valid secure boot image. The u-boot SPL build processes is NOT aware of the details of creating the boot image - all of that information is encapsulated in the TI secure development package, which is available from TI. More info can be found in README.ti-secure Right now, two image types are generated, MLO and X-LOADER. The types are important, as certain boot modes implemented by the device's ROM boot loader require one or the other (they are not equivalent). The output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The u-boot-spl_HS_MLO image is also copied to a file named MLO, which is the name that the device ROM bootloader requires for loading from the FAT partition of an SD card (same as on non-secure devices). Signed-off-by: Daniel Allred Signed-off-by: Madan Srinivas Reviewed-by: Lokesh Vutla Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: None arch/arm/cpu/armv7/omap5/config.mk | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/cpu/armv7/omap5/config.mk b/arch/arm/cpu/armv7/omap5/config.mk index ef2725a..a7e55a5 100644 --- a/arch/arm/cpu/armv7/omap5/config.mk +++ b/arch/arm/cpu/armv7/omap5/config.mk @@ -6,8 +6,14 @@ # SPDX-License-Identifier: GPL-2.0+ # +include $(srctree)/$(CPUDIR)/omap-common/config_secure.mk + ifdef CONFIG_SPL_BUILD +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) +ALL-y += u-boot-spl_HS_MLO u-boot-spl_HS_X-LOADER +else ALL-y += MLO +endif else ALL-y += u-boot.img endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 05/15] ti: omap-common: Add commands for generating secure SPL images
Adds a centralized config_secure.mk in omap-common for OMAP-style TI secure devices to use for boot image generation Depending on the boot media, different images are needed for secure devices. These commands generates u-boot*_HS_* files that need to be used to boot secure devices. Please refer to README.ti-secure for more information. Signed-off-by: Daniel Allred Signed-off-by: Madan Srinivas Reviewed-by: Lokesh Vutla Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: None arch/arm/cpu/armv7/omap-common/config_secure.mk | 66 + 1 file changed, 66 insertions(+) create mode 100644 arch/arm/cpu/armv7/omap-common/config_secure.mk diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk new file mode 100644 index 000..c7bb101 --- /dev/null +++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk @@ -0,0 +1,66 @@ +# +# Copyright (C) 2016, Texas Instruments, Incorporated - http://www.ti.com/ +# +# SPDX-License-Identifier: GPL-2.0+ +# +quiet_cmd_mkomapsecimg = MKIMAGE $@ +ifneq ($(TI_SECURE_DEV_PKG),) +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh),) +ifneq ($(CONFIG_SPL_BUILD),) +cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \ + $(patsubst u-boot-spl_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \ + $(if $(KBUILD_VERBOSE:1=), >/dev/null) +else +cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \ +$(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \ +$(if $(KBUILD_VERBOSE:1=), >/dev/null) +endif +else +cmd_mkomapsecimg = echo "WARNING:" \ + "$(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh not found." \ + "$@ was NOT created!" +endif +else +cmd_mkomapsecimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \ + "variable must be defined for TI secure devices. $@ was NOT created!" +endif + +# Standard X-LOADER target (QPSI, NOR flash) +u-boot-spl_HS_X-LOADER: $(obj)/u-boot-spl.bin + $(call if_changed,mkomapsecimg) + +# For MLO targets (SD card boot) the final file name +# that is copied to the SD card fAT partition must +# be MLO, so we make a copy of the output file to a +# new file with that name +u-boot-spl_HS_MLO: $(obj)/u-boot-spl.bin + $(call if_changed,mkomapsecimg) + @if [ -f $@ ]; then \ + cp -f $@ MLO; \ + fi + +# Standard 2ND target (certain peripheral boot modes) +u-boot-spl_HS_2ND: $(obj)/u-boot-spl.bin + $(call if_changed,mkomapsecimg) + +# Standard ULO target (certain peripheral boot modes) +u-boot-spl_HS_ULO: $(obj)/u-boot-spl.bin + $(call if_changed,mkomapsecimg) + +# Standard ISSW target (certain devices, various boot modes) +u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin + $(call if_changed,mkomapsecimg) + +# For SPI flash on AM335x and AM43xx, these +# require special byte swap handling so we use +# the SPI_X-LOADER target instead of X-LOADER +# and let the create-boot-image.sh script handle +# that +u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin + $(call if_changed,mkomapsecimg) + +# For supporting single stage XiP QSPI on AM43xx, the +# image is a full u-boot file, not an SPL. In this case +# the mkomapsecimg command looks for a u-boot-HS_* prefix +u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin + $(call if_changed,mkomapsecimg) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 15/15] defconfig: ti: Add configs for OMAP5-class secure parts
Adds new defconfig files for DRA7xx and AM57xx secure devices. These are the same as the non-secure parts, but with the addition of the CONFIG_TI_SECURE_DEVICE option set to 'y'. Signed-off-by: Daniel Allred Signed-off-by: Madan Srinivas Reviewed-by: Tom Rini --- V3: None V2: Rebase from current master, create HS copies of defconfigs configs/am57xx_hs_evm_defconfig | 36 +++ configs/dra72_hs_evm_defconfig | 55 + configs/dra74_hs_evm_defconfig | 54 3 files changed, 145 insertions(+) create mode 100644 configs/am57xx_hs_evm_defconfig create mode 100644 configs/dra72_hs_evm_defconfig create mode 100644 configs/dra74_hs_evm_defconfig diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig new file mode 100644 index 000..60525cd --- /dev/null +++ b/configs/am57xx_hs_evm_defconfig @@ -0,0 +1,36 @@ +CONFIG_ARM=y +CONFIG_OMAP54XX=y +CONFIG_TI_SECURE_DEVICE=y +CONFIG_TARGET_BEAGLE_X15=y +CONFIG_DM_SERIAL=y +CONFIG_DM_GPIO=y +CONFIG_SPL_STACK_R_ADDR=0x8200 +CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15" +CONFIG_SPL=y +CONFIG_SPL_STACK_R=y +CONFIG_HUSH_PARSER=y +CONFIG_CMD_BOOTZ=y +CONFIG_OF_BOARD_SETUP=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DM=y +CONFIG_DM_MMC=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SYS_NS16550=y diff --git a/configs/dra72_hs_evm_defconfig b/configs/dra72_hs_evm_defconfig new file mode 100644 index 000..01f985e --- /dev/null +++ b/configs/dra72_hs_evm_defconfig @@ -0,0 +1,55 @@ +CONFIG_ARM=y +CONFIG_OMAP54XX=y +CONFIG_TI_SECURE_DEVICE=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_TARGET_DRA7XX_EVM=y +CONFIG_DM_SERIAL=y +CONFIG_DM_SPI=y +CONFIG_DM_SPI_FLASH=y +CONFIG_DM_GPIO=y +CONFIG_SPL_STACK_R_ADDR=0x8200 +CONFIG_DEFAULT_DEVICE_TREE="dra72-evm" +CONFIG_SPL=y +CONFIG_SPL_STACK_R=y +CONFIG_HUSH_PARSER=y +CONFIG_CMD_BOOTZ=y +CONFIG_OF_BOARD_SETUP=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DM=y +CONFIG_DM_MMC=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SYS_NS16550=y +CONFIG_TI_QSPI=y +CONFIG_TIMER=y +CONFIG_OMAP_TIMER=y +CONFIG_USB=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_DWC3_OMAP=y +CONFIG_USB_DWC3_PHY_OMAP=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_G_DNL_MANUFACTURER="Texas Instruments" +CONFIG_G_DNL_VENDOR_NUM=0x0451 +CONFIG_G_DNL_PRODUCT_NUM=0xd022 diff --git a/configs/dra74_hs_evm_defconfig b/configs/dra74_hs_evm_defconfig new file mode 100644 index 000..1b30ad4 --- /dev/null +++ b/configs/dra74_hs_evm_defconfig @@ -0,0 +1,54 @@ +CONFIG_ARM=y +CONFIG_OMAP54XX=y +CONFIG_TI_SECURE_DEVICE=y +CONFIG_TARGET_DRA7XX_EVM=y +CONFIG_DM_SERIAL=y +CONFIG_DM_SPI=y +CONFIG_DM_SPI_FLASH=y +CONFIG_DM_GPIO=y +CONFIG_SPL_STACK_R_ADDR=0x8200 +CONFIG_DEFAULT_DEVICE_TREE="dra7-evm" +CONFIG_SPL=y +CONFIG_SPL_STACK_R=y +CONFIG_HUSH_PARSER=y +CONFIG_CMD_BOOTZ=y +CONFIG_OF_BOARD_SETUP=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DM=y +CONFIG_DM_MMC=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SYS_NS16550=y +CONFIG_TI_QSPI=y +CONFIG_TIMER=y +CONFIG_OMAP_TIMER=y +CONFIG_USB=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_DWC3_OMAP=y +CONFIG_USB_DWC3_PHY_OMAP=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_G_DNL_MANUFACTURER="Texas Instruments" +CONFIG_G_DNL_VENDOR_NUM=0x0451 +CONFIG_G_DNL_PRODUCT_NUM=0xd022 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 10/15] ti_omap5_common: Update SPL start address on secure parts
Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving the start address past secure reserved memory and the size of the security certificate that precedes the boot image on secure devices). Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the internal memory actually available on the various device flavors (Common minimum internal RAM guaranteed for various flavors of DRA7xx/AM57xx is 512KB). Signed-off-by: Daniel Allred Signed-off-by: Madan Srinivas --- V3: Rename CONFIG_SPL_BOOT_END to TI_ROM_BOOT_LOAD_END since it is not a a configurable option (fixed based on device ROM). V2: Rename CONFIG_SECURE_BOOT_SRAM to TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ since it is not configurable (dependent on ROM/secure code). include/configs/ti_omap5_common.h | 32 +++- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h index b049be4..eb7f206 100644 --- a/include/configs/ti_omap5_common.h +++ b/include/configs/ti_omap5_common.h @@ -130,13 +130,35 @@ /* * SPL related defines. The Public RAM memory map the ROM defines the - * area between 0x4030 and 0x4031E000 as a download area for OMAP5 - * (dra7xx is larger, but we do not need to be larger at this time). We - * set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and + * area between 0x4030 and 0x4031E000 as a download area for OMAP5. + * On DRA7xx/AM57XX the download area is between 0x4030 and 0x4037E000. + * We set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and * print some information. */ -#define CONFIG_SPL_TEXT_BASE 0x4030 -#define CONFIG_SPL_MAX_SIZE(0x4031E000 - CONFIG_SPL_TEXT_BASE) +#ifdef CONFIG_TI_SECURE_DEVICE +/* + * For memory booting on HS parts, the first 4KB of the internal RAM is + * reserved for secure world use and the flash loader image is + * preceded by a secure certificate. The SPL will therefore run in internal + * RAM from address 0x40301350 (0x4030+0x1000(reserved)+0x350(cert)). + */ +#define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ 0x1000 +#define CONFIG_SPL_TEXT_BASE 0x40301350 +#else +/* + * For all booting on GP parts, the flash loader image is + * downloaded into internal RAM at address 0x4030. + */ +#define CONFIG_SPL_TEXT_BASE 0x4030 +#endif + +/* DRA7xx/AM57xx have 512K of SRAM, OMAP5 only 128K */ +#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX) +#define TI_ROM_BOOT_LOAD_END 0x4037E000 +#else +#define TI_ROM_BOOT_LOAD_END 0x4031E000 +#endif +#define CONFIG_SPL_MAX_SIZE (TI_ROM_BOOT_LOAD_END - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds" #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 13/15] ARM: omap5: add hooks for cpu/SoC fdt fixups
Adds an fdt.c file in that defines the ft_cpu_setup() function,
which should be called from a board-specific ft_board_setup()).
This ft_cpu_setup() will currently do nothing for non-secure (GP)
devices but contains pertinent updates for booting on secure (HS)
devices.
Update the omap5 Makefile to include the fdt.c in the build.
Signed-off-by: Daniel Allred
Signed-off-by: Madan Srinivas
Reviewed-by: Tom Rini
---
V3:
None
V2:
Change CONFIG_SECURE_BOOT_SRAM to TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ
Change CONFIG_SECURE_RUN_SRAM to CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ
arch/arm/cpu/armv7/omap5/Makefile | 1 +
arch/arm/cpu/armv7/omap5/fdt.c| 184 ++
2 files changed, 185 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c
diff --git a/arch/arm/cpu/armv7/omap5/Makefile
b/arch/arm/cpu/armv7/omap5/Makefile
index f2930d5..3caba86 100644
--- a/arch/arm/cpu/armv7/omap5/Makefile
+++ b/arch/arm/cpu/armv7/omap5/Makefile
@@ -12,4 +12,5 @@ obj-y += sdram.o
obj-y += prcm-regs.o
obj-y += hw_data.o
obj-y += abb.o
+obj-y += fdt.o
obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
diff --git a/arch/arm/cpu/armv7/omap5/fdt.c b/arch/arm/cpu/armv7/omap5/fdt.c
new file mode 100644
index 000..0493cd1
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/fdt.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright 2016 Texas Instruments, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+
+/* Give zero values if not already defined */
+#ifndef TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ
+#define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ (0)
+#endif
+#ifndef CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ
+#define CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ (0)
+#endif
+
+static u32 hs_irq_skip[] = {
+ 8, /* Secure violation reporting interrupt */
+ 15, /* One interrupt for SDMA by secure world */
+ 118 /* One interrupt for Crypto DMA by secure world */
+};
+
+static int ft_hs_fixup_crossbar(void *fdt, bd_t *bd)
+{
+ const char *path;
+ int offs;
+ int ret;
+ int len, i, old_cnt, new_cnt;
+ u32 *temp;
+ const u32 *p_data;
+
+ /*
+* Increase the size of the fdt
+* so we have some breathing room
+*/
+ ret = fdt_increase_size(fdt, 512);
+ if (ret < 0) {
+ printf("Could not increase size of device tree: %s\n",
+ fdt_strerror(ret));
+ return ret;
+ }
+
+ /* Reserve IRQs that are used/needed by secure world */
+ path = "/ocp/crossbar";
+ offs = fdt_path_offset(fdt, path);
+ if (offs < 0) {
+ debug("Node %s not found.\n", path);
+ return 0;
+ }
+
+ /* Get current entries */
+ p_data = fdt_getprop(fdt, offs, "ti,irqs-skip", &len);
+ if (p_data)
+ old_cnt = len / sizeof(u32);
+ else
+ old_cnt = 0;
+
+ new_cnt = sizeof(hs_irq_skip) /
+ sizeof(hs_irq_skip[0]);
+
+ /* Create new/updated skip list for HS parts */
+ temp = malloc(sizeof(u32) * (old_cnt + new_cnt));
+ for (i = 0; i < new_cnt; i++)
+ temp[i] = cpu_to_fdt32(hs_irq_skip[i]);
+ for (i = 0; i < old_cnt; i++)
+ temp[i + new_cnt] = p_data[i];
+
+ /* Blow away old data and set new data */
+ fdt_delprop(fdt, offs, "ti,irqs-skip");
+ ret = fdt_setprop(fdt, offs, "ti,irqs-skip",
+ temp,
+ (old_cnt + new_cnt) * sizeof(u32));
+ free(temp);
+
+ /* Check if the update worked */
+ if (ret < 0) {
+ printf("Could not add ti,irqs-skip property to node %s: %s\n",
+ path, fdt_strerror(ret));
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ft_hs_disable_rng(void *fdt, bd_t *bd)
+{
+ const char *path;
+ int offs;
+ int ret;
+
+ /* Make HW RNG reserved for secure world use */
+ path = "/ocp/rng";
+ offs = fdt_path_offset(fdt, path);
+ if (offs < 0) {
+ debug("Node %s not found.\n", path);
+ return 0;
+ }
+ ret = fdt_setprop_string(fdt, offs,
+"status", "disabled");
+ if (ret < 0) {
+ printf("Could not add status property to node %s: %s\n",
+ path, fdt_strerror(ret));
+ return ret;
+ }
+ return 0;
+}
+
+#if ((TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ != 0) || \
+(CONFIG_SECURE_RUNTIME_RESV_SRAM_SZ != 0))
+static int ft_hs_fixup_sram(void *fdt, bd_t *bd)
+{
+ const char *path;
+ int offs;
+ int ret;
+ u32 temp[2];
+
+ /*
+* Update SRAM reservations on secure devices. The OCMC RAM
+* is always reserved for secure use from the start of that
+* memory region
+*/
+
[U-Boot] [PATCH v3 12/15] ARM: omap-common: Add device type to CPU string
Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.
Signed-off-by: Daniel Allred
Signed-off-by: Madan Srinivas
Reviewed-by: Tom Rini
---
V3:
Rebase on current master
V2:
Move device type defines to omap_common.h, remove duplicates
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 22 --
arch/arm/include/asm/arch-omap3/cpu.h | 7 +--
arch/arm/include/asm/omap_common.h | 11 +++
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 01c2d57..078bdd8 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -65,12 +65,30 @@ static void omap_rev_string(void)
u32 major_rev = (omap_rev & 0x0F00) >> 8;
u32 minor_rev = (omap_rev & 0x00F0) >> 4;
+ const char *sec_s;
+
+ switch (get_device_type()) {
+ case TST_DEVICE:
+ sec_s = "TST";
+ break;
+ case EMU_DEVICE:
+ sec_s = "EMU";
+ break;
+ case HS_DEVICE:
+ sec_s = "HS";
+ break;
+ case GP_DEVICE:
+ sec_s = "GP";
+ break;
+ default:
+ sec_s = "?";
+ }
+
if (soc_variant)
printf("OMAP");
else
printf("DRA");
- printf("%x ES%x.%x\n", omap_variant, major_rev,
- minor_rev);
+ printf("%x-%s ES%x.%x\n", omap_variant, sec_s, major_rev, minor_rev);
}
#ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/include/asm/arch-omap3/cpu.h
b/arch/arm/include/asm/arch-omap3/cpu.h
index 53cc2b0..e8aa786 100644
--- a/arch/arm/include/asm/arch-omap3/cpu.h
+++ b/arch/arm/include/asm/arch-omap3/cpu.h
@@ -59,13 +59,8 @@ struct ctrl_id {
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL_STRICT_NAMES */
-/* device type */
-#define DEVICE_MASK(0x7 << 8)
+/* boot pin mask */
#define SYSBOOT_MASK 0x1F
-#define TST_DEVICE 0x0
-#define EMU_DEVICE 0x1
-#define HS_DEVICE 0x2
-#define GP_DEVICE 0x3
/* device speed */
#define SKUID_CLK_MASK 0xf
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 8fb05e1..ac34b0e 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -717,6 +717,17 @@ static inline u8 is_dra72x(void)
#define DRA722_ES2_0 0x07220200
/*
+ * silicon device type
+ * Moving to common from cpu.h, since it is shared by various omap devices
+ */
+#define DEVICE_MASK (BIT(8) | BIT(9) | BIT(10))
+#define TST_DEVICE 0x0
+#define EMU_DEVICE 0x1
+#define HS_DEVICE 0x2
+#define GP_DEVICE 0x3
+
+
+/*
* SRAM scratch space entries
*/
#define OMAP_SRAM_SCRATCH_OMAP_REV SRAM_SCRATCH_SPACE_ADDR
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPL: fat: Fix spl_parse_image_header() return value handling
On Thu, May 19, 2016 at 8:45 PM, Marek Vasut wrote: > The spl_parse_image_header() can return 0 and it is not an error. > Only treat non-zero return value as an error. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Peng Fan > Cc: Stefano Babic > Cc: Tom Rini Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 07/15] ti: AM43xx: Use CONFIG options from SOC Kconfig
From: Madan Srinivas Updates configs/am43xx_evm.h to use CONFIG options from SOC specific Kconfig file for various calculations. On AM43x devices, the address of SPL entry point depends on the device type, i.e. whether it is secure or non-secure. Further, for non-secure devices, the SPL entry point is different between USB HOST boot mode, other "memory" boot modes (MMC, NAND) and "peripheral" boot modes (UART, USB) To add to the complexity, on secure devices, in addition to the above differences, the SPL entry point can change because of the space occupied by other components (other than u-boot or spl) that go into a secure boot image. To prevent the user from having to modify source files every time any component of the secure image changes, the value of CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that is supplied in the am43xx_*_defconfig files Using the CONFIG options also enables us to do away with some compile time flags that were used to specify CONFIG_SPL_TEXT_BASE for different boot modes. On QSPI devices, the same problem described above occurs w.r.t. the address of the u-boot entry point in flash, when booting secure devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via a Kconfig option and the defconfig files. Signed-off-by: Madan Srinivas Signed-off-by: Daniel Allred Reviewed-by: Lokesh Vutla Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: Rebase against current master configs/am43xx_evm_qspiboot_defconfig | 1 + configs/am43xx_evm_usbhost_boot_defconfig | 1 + include/configs/am43xx_evm.h | 19 +++ 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig index bda0ae1..79eac88 100644 --- a/configs/am43xx_evm_qspiboot_defconfig +++ b/configs/am43xx_evm_qspiboot_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_AM43XX=y CONFIG_TARGET_AM43XX_EVM=y +CONFIG_ISW_ENTRY_ADDR=0x3000 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig index d9fc4de..9943be2 100644 --- a/configs/am43xx_evm_usbhost_boot_defconfig +++ b/configs/am43xx_evm_usbhost_boot_defconfig @@ -2,6 +2,7 @@ CONFIG_ARM=y CONFIG_AM43XX=y CONFIG_TARGET_AM43XX_EVM=y CONFIG_SPL=y +CONFIG_ISW_ENTRY_ADDR=0x40300350 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT" CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index a35541b..8a48a9a 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -37,17 +37,10 @@ #define CONFIG_POWER_TPS62362 /* SPL defines. */ -#ifdef CONFIG_SPL_USB_HOST_SUPPORT -/* - * For USB host boot, ROM uses DMA for copying MLO from USB storage - * and ARM internal ram is not accessible for DMA, so SPL text base - * should be in OCMC ram - */ -#define CONFIG_SPL_TEXT_BASE 0x40300350 -#else -#define CONFIG_SPL_TEXT_BASE 0x402F4000 -#endif -#define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */ +#define CONFIG_SPL_TEXT_BASE CONFIG_ISW_ENTRY_ADDR +#define CONFIG_SPL_MAX_SIZE(NON_SECURE_SRAM_END - \ + CONFIG_PUB_ROM_DATA_SIZE - \ + CONFIG_SPL_TEXT_BASE) #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ (128 << 20)) #define CONFIG_SPL_POWER_SUPPORT @@ -190,7 +183,9 @@ #endif #ifdef CONFIG_QSPI_BOOT -#define CONFIG_SYS_TEXT_BASE 0x3000 +#ifndef CONFIG_SYS_TEXT_BASE +#define CONFIG_SYS_TEXT_BASE CONFIG_ISW_ENTRY_ADDR +#endif #undef CONFIG_ENV_IS_IN_FAT #define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_SYS_REDUNDAND_ENVIRONMENT -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/15] ti: AM43xx: config.mk: Add support for generating secure boot images
Modifies the config.mk to build secure images when building the SPL for secure devices. Depending on the boot media, different images are needed for secure devices. The build generates u-boot*_HS_* files as appropriate for the different boot modes. The same u-boot binary file is processed slightly differently to produce a different boot image, depending on whether the user wants to boot off SPI, QSPI or other boot media. Refer to README.ti-secure for more information. Signed-off-by: Madan Srinivas Signed-off-by: Daniel Allred Reviewed-by: Lokesh Vutla Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: None arch/arm/cpu/armv7/am33xx/config.mk | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk index 5294d16..6d95d32 100644 --- a/arch/arm/cpu/armv7/am33xx/config.mk +++ b/arch/arm/cpu/armv7/am33xx/config.mk @@ -3,9 +3,29 @@ # # SPDX-License-Identifier: GPL-2.0+ # + +include $(srctree)/$(CPUDIR)/omap-common/config_secure.mk + ifdef CONFIG_SPL_BUILD +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) +# +# For booting from SPI use +# u-boot-spl_HS_SPI_X-LOADER to program flash +# +# For booting spl from all other media +# use u-boot-spl_HS_ISSW +# +# Refer to README.ti-secure for more info +# +ALL-y += u-boot-spl_HS_ISSW +ALL-$(CONFIG_SPL_SPI_SUPPORT) += u-boot-spl_HS_SPI_X-LOADER +else ALL-y += MLO ALL-$(CONFIG_SPL_SPI_SUPPORT) += MLO.byteswap +endif else +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) +ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER +endif ALL-y += u-boot.img endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 04/15] ti: omap-common: Add Kconfig file for secure device support
From: Madan Srinivas Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on when building images for secure devices. This flag is used to invoke the secure image creation tools for creating a boot image that can be used on secure devices. This flag may also be used to conditionally compile code specific to secure devices. This terminology will be used by all OMAP architecture devices, hence introducing to a common location. With the creation of Kconfig for omap-common, moved the sourcing of the Kconfig files for the omap3/4/5 and am33xx devices from arch/arm/KConfig to the omap-common one. Signed-off-by: Madan Srinivas Signed-off-by: Daniel Allred Reviewed-by: Lokesh Vutla Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: None arch/arm/Kconfig | 8 +--- arch/arm/cpu/armv7/omap-common/Kconfig | 17 + 2 files changed, 18 insertions(+), 7 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6577572..3c545f0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -776,13 +776,7 @@ source "arch/arm/cpu/armv7/mx6/Kconfig" source "arch/arm/cpu/armv7/mx5/Kconfig" -source "arch/arm/cpu/armv7/omap3/Kconfig" - -source "arch/arm/cpu/armv7/omap4/Kconfig" - -source "arch/arm/cpu/armv7/omap5/Kconfig" - -source "arch/arm/cpu/armv7/am33xx/Kconfig" +source "arch/arm/cpu/armv7/omap-common/Kconfig" source "arch/arm/mach-orion5x/Kconfig" diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig new file mode 100644 index 000..7b39506 --- /dev/null +++ b/arch/arm/cpu/armv7/omap-common/Kconfig @@ -0,0 +1,17 @@ +config TI_SECURE_DEVICE + bool "HS Device Type Support" + depends on OMAP54XX || AM43XX + help + If a high secure (HS) device type is being used, this config + must be set. This option impacts various aspects of the + build system (to create signed boot images that can be + authenticated) and the code. See the doc/README.ti-secure + file for further details. + +source "arch/arm/cpu/armv7/omap3/Kconfig" + +source "arch/arm/cpu/armv7/omap4/Kconfig" + +source "arch/arm/cpu/armv7/omap5/Kconfig" + +source "arch/arm/cpu/armv7/am33xx/Kconfig" -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 02/15] arm: am33xx: Kconfig: Add secure device definitions
From: Madan Srinivas Adds a new Kconfig file for AM33xx class devices. We need a common place to define CONFIG parameters for these SOCs, especially for adding support for secure devices. a) Adds a definition for ISW_ENTRY_ADDR. This is the address to which the ROM branches when the SOC ROM hands off execution to the boot loader. CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set to this value for AM43xx devices. b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to calculate CONFIG_SPL_MAX_SIZE. This value indicates the amount of memory needed by the ROM to store data during the boot process. Currently, these CONFIG options are used only by AM43xx, but in future other AM33xx class SOCs will also use them. Signed-off-by: Madan Srinivas Signed-off-by: Daniel Allred Reviewed-by: Lokesh Vutla Tested-by: Andreas Dannenberg Reviewed-by: Tom Rini --- V3: None V2: None arch/arm/cpu/armv7/am33xx/Kconfig | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 arch/arm/cpu/armv7/am33xx/Kconfig diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig new file mode 100644 index 000..39759cd --- /dev/null +++ b/arch/arm/cpu/armv7/am33xx/Kconfig @@ -0,0 +1,27 @@ +config ISW_ENTRY_ADDR + hex "Address in memory or XIP flash of bootloader entry point" + help + After any reset, the boot ROM on the AM43XX SOC + searches the boot media for a valid boot image. + For non-XIP devices, the ROM then copies the + image into internal memory. + For all boot modes, after the ROM processes the + boot image it eventually computes the entry + point address depending on the device type + (secure/non-secure), boot media (xip/non-xip) and + image headers. + default 0x402F4000 + +config PUB_ROM_DATA_SIZE + hex "Size in bytes of the L3 SRAM reserved by ROM to store data" + help + During the device boot, the public ROM uses the top of + the public L3 OCMC RAM to store r/w data like stack, + heap, globals etc. When the ROM is copying the boot + image from the boot media into memory, the image must + not spill over into this area. This value can be used + during compile time to determine the maximum size of a + boot image. Once the ROM transfers control to the boot + image, this area is no longer used, and can be reclaimed + for run time use by the boot image. + default 0x8400 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 00/15] Support for boot image creation for TI secure devices
Adds support for creating bootable images for AM43xx HS and DRA7xx/AM57xx HS devices. Daniel Allred (9): doc: Add info on using secure devices from TI ti: omap-common: Add commands for generating secure SPL images ti: AM43xx: config.mk: Add support for generating secure boot images ti_omap5_common: Update SPL start address on secure parts spl: build: ti: add support for secure boot images ARM: omap-common: Add device type to CPU string ARM: omap5: add hooks for cpu/SoC fdt fixups ARM: omap5: add ft_board_setup for dra7xx/am57xx defconfig: ti: Add configs for OMAP5-class secure parts Madan Srinivas (6): arm: am33xx: Kconfig: Add secure device definitions arm: Kconfig: Add support for AM43xx SoC specific Kconfig ti: omap-common: Add Kconfig file for secure device support ti: AM43xx: Use CONFIG options from SOC Kconfig ti: AM43xx: board: Detect AM43xx HS EVM defconfig: Add a config for AM43xx secure part arch/arm/Kconfig| 23 +-- arch/arm/cpu/armv7/am33xx/Kconfig | 40 ++ arch/arm/cpu/armv7/am33xx/config.mk | 20 +++ arch/arm/cpu/armv7/omap-common/Kconfig | 17 +++ arch/arm/cpu/armv7/omap-common/config_secure.mk | 66 + arch/arm/cpu/armv7/omap-common/hwinit-common.c | 22 ++- arch/arm/cpu/armv7/omap5/Makefile | 1 + arch/arm/cpu/armv7/omap5/config.mk | 6 + arch/arm/cpu/armv7/omap5/fdt.c | 184 arch/arm/include/asm/arch-omap3/cpu.h | 7 +- arch/arm/include/asm/omap_common.h | 11 ++ board/ti/am43xx/board.c | 4 +- board/ti/am43xx/board.h | 14 +- board/ti/am43xx/mux.c | 2 +- board/ti/am57xx/board.c | 9 ++ board/ti/dra7xx/evm.c | 9 ++ configs/am437x_gp_evm_defconfig | 1 + configs/am437x_hs_evm_defconfig | 53 +++ configs/am437x_sk_evm_defconfig | 1 + configs/am43xx_evm_defconfig| 1 + configs/am43xx_evm_ethboot_defconfig| 1 + configs/am43xx_evm_qspiboot_defconfig | 2 + configs/am43xx_evm_usbhost_boot_defconfig | 2 + configs/am57xx_evm_defconfig| 1 + configs/am57xx_hs_evm_defconfig | 36 + configs/dra72_evm_defconfig | 1 + configs/dra72_hs_evm_defconfig | 55 +++ configs/dra74_evm_defconfig | 1 + configs/dra74_hs_evm_defconfig | 54 +++ doc/README.ti-secure| 91 include/configs/am43xx_evm.h| 23 ++- include/configs/ti_omap5_common.h | 32 - 32 files changed, 747 insertions(+), 43 deletions(-) create mode 100644 arch/arm/cpu/armv7/am33xx/Kconfig create mode 100644 arch/arm/cpu/armv7/omap-common/Kconfig create mode 100644 arch/arm/cpu/armv7/omap-common/config_secure.mk create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c create mode 100644 configs/am437x_hs_evm_defconfig create mode 100644 configs/am57xx_hs_evm_defconfig create mode 100644 configs/dra72_hs_evm_defconfig create mode 100644 configs/dra74_hs_evm_defconfig create mode 100644 doc/README.ti-secure -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Treat arm946es as v5te
On 04/30/2016 02:45 PM, Marek Vasut wrote: > The arm946es is armv5te , so use -march=armv5te instead of armv4t. > > Signed-off-by: Marek Vasut > Cc: Albert Aribaud > Cc: Tom Rini Bump? > --- > arch/arm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index d516345..dbc81c0 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -11,7 +11,7 @@ endif > arch-$(CONFIG_CPU_ARM720T) =-march=armv4 > arch-$(CONFIG_CPU_ARM920T) =-march=armv4t > arch-$(CONFIG_CPU_ARM926EJS) =-march=armv5te > -arch-$(CONFIG_CPU_ARM946ES) =-march=armv4 > +arch-$(CONFIG_CPU_ARM946ES) =-march=armv5te > arch-$(CONFIG_CPU_SA1100)=-march=armv4 > arch-$(CONFIG_CPU_PXA) = > arch-$(CONFIG_CPU_ARM1136) =-march=armv5 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mvebu: a38x: Weed out floating point use
On 04/30/2016 02:45 PM, Marek Vasut wrote:
> For reason unknown, recently, the DDR init code writers are really fond
> of hiding some small floating point operating deep in their creations.
> This patch removes one from the Marvell A38x code.
>
> Instead of returning size of chip as float from ddr3_get_device_size()
> in GiB units, return it as int in MiB units. Since this would interfere
> with the huge switch code in ddr3_calc_mem_cs_size(), rework the code
> to match the change.
>
> Before this patch, the cs_mem_size variable could have these values:
> ( { 16, 32 } x { 8, 16 } x { 0.01, 0.5, 1, 2, 4, 8 } ) / 8 =
>{ 0.00, 0.001250, 0.002500, 0.005000, 0.062500, 0.125000,
> 0.25, 0.50, 1.00, 2.00, 4.00, }
> The switch code checked for a subset of the resulting RAM sizes, which
> is in range 128 MiB ... 2048 MiB.
>
> With this patch, the cs_mem_size variable can have these values:
> ( { 16, 32 } x { 8, 16 } x { 0, 512, 1024, 2048, 4096, 8192 } ) / 8 =
>{ 0, 64, 128, 256, 512, 1024, 2048, 4096 }
> To retain previous behavior, filter out 0 MiB (invalid size), 64 MiB
> and 4096 MiB options.
>
> Removing the floating point stuff also saves 1.5k from text segment:
> clearfog : spl/u-boot-spl:all -1592 spl/u-boot-spl:text -1592
>
> Signed-off-by: Marek Vasut
> Cc: Dirk Eibach
> Cc: Stefan Roese
Bump?
> ---
> drivers/ddr/marvell/a38x/ddr3_init.c | 29 ++---
> 1 file changed, 10 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c
> b/drivers/ddr/marvell/a38x/ddr3_init.c
> index ee05f57..55baad4 100644
> --- a/drivers/ddr/marvell/a38x/ddr3_init.c
> +++ b/drivers/ddr/marvell/a38x/ddr3_init.c
> @@ -678,7 +678,7 @@ u32 ddr3_get_device_width(u32 cs)
> return (device_width == 0) ? 8 : 16;
> }
>
> -float ddr3_get_device_size(u32 cs)
> +static int ddr3_get_device_size(u32 cs)
> {
> u32 device_size_low, device_size_high, device_size;
> u32 data, cs_low_offset, cs_high_offset;
> @@ -695,15 +695,15 @@ float ddr3_get_device_size(u32 cs)
>
> switch (device_size) {
> case 0:
> - return 2;
> + return 2048;
> case 2:
> - return 0.5;
> + return 512;
> case 3:
> - return 1;
> + return 1024;
> case 4:
> - return 4;
> + return 4096;
> case 5:
> - return 8;
> + return 8192;
> case 1:
> default:
> DEBUG_INIT_C("Error: Wrong device size of Cs: ", cs, 1);
> @@ -711,13 +711,13 @@ float ddr3_get_device_size(u32 cs)
>* Small value will give wrong emem size in
>* ddr3_calc_mem_cs_size
>*/
> - return 0.01;
> + return 0;
> }
> }
>
> int ddr3_calc_mem_cs_size(u32 cs, u32 *cs_size)
> {
> - float cs_mem_size;
> + int cs_mem_size;
>
> /* Calculate in GiB */
> cs_mem_size = ((ddr3_get_bus_width() / ddr3_get_device_width(cs)) *
> @@ -731,21 +731,12 @@ int ddr3_calc_mem_cs_size(u32 cs, u32 *cs_size)
>*/
> cs_mem_size *= DDR_CONTROLLER_BUS_WIDTH_MULTIPLIER;
>
> - if (cs_mem_size == 0.125) {
> - *cs_size = 128 << 20;
> - } else if (cs_mem_size == 0.25) {
> - *cs_size = 256 << 20;
> - } else if (cs_mem_size == 0.5) {
> - *cs_size = 512 << 20;
> - } else if (cs_mem_size == 1) {
> - *cs_size = 1 << 30;
> - } else if (cs_mem_size == 2) {
> - *cs_size = 2 << 30;
> - } else {
> + if (!cs_mem_size || (cs_mem_size == 64) || (cs_mem_size == 4096)) {
> DEBUG_INIT_C("Error: Wrong Memory size of Cs: ", cs, 1);
> return MV_BAD_VALUE;
> }
>
> + *cs_size = cs_mem_size << 20;
> return MV_OK;
> }
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SPL: fat: Fix spl_parse_image_header() return value handling
The spl_parse_image_header() can return 0 and it is not an error. Only treat non-zero return value as an error. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Cc: Tom Rini --- common/spl/spl_fat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c index 338ea2f..5b0d969 100644 --- a/common/spl/spl_fat.c +++ b/common/spl/spl_fat.c @@ -58,7 +58,7 @@ int spl_load_image_fat(struct blk_desc *block_dev, goto end; err = spl_parse_image_header(header); - if (err <= 0) + if (err) goto end; err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0); -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] imx-common: use simpler runtime cpu dection macros
Dear Peng Fan, On Wed, May 18, 2016 at 9:53 AM, Peng Fan wrote: > Use simpler runtime cpu dection macros. > > Signed-off-by: Peng Fan > Cc: Stefano Babic > Cc: Ulises Cardenas > Cc: Bhuvanchandra DV > Cc: "Benoît Thébaudeau" > --- > arch/arm/imx-common/hab.c | 43 > +- > arch/arm/imx-common/init.c | 5 ++--- > arch/arm/imx-common/iomux-v3.c | 2 +- > arch/arm/imx-common/sata.c | 2 +- > arch/arm/imx-common/timer.c| 11 +++ > 5 files changed, 20 insertions(+), 43 deletions(-) > > diff --git a/arch/arm/imx-common/hab.c b/arch/arm/imx-common/hab.c > index 8bbcc22..a980688 100644 > --- a/arch/arm/imx-common/hab.c > +++ b/arch/arm/imx-common/hab.c > @@ -17,60 +17,45 @@ > > #define hab_rvt_report_event_p \ > ( \ > - ((is_cpu_type(MXC_CPU_MX6Q) || \ > - is_cpu_type(MXC_CPU_MX6D)) && \ > - (soc_rev() >= CHIP_REV_1_5)) ?\ > + (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ? \ > ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT_NEW) : \ > - (is_cpu_type(MXC_CPU_MX6DL) && \ > -(soc_rev() >= CHIP_REV_1_2)) ? \ > + (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ? \ This change silently introduces the possibility of MXC_CPU_MX6SOLO. Is this on purpose? If so, then it means that there was something unrelated to this patch that was wrong in this code for MXC_CPU_MX6SOLO, so this should be fixed in a separate patch before this one. If not, then an is_mx6dl() macro should be introduced. > ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT_NEW) : \ > ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT)\ > ) > > #define hab_rvt_report_status_p\ > ( \ > - ((is_cpu_type(MXC_CPU_MX6Q) || \ > - is_cpu_type(MXC_CPU_MX6D)) && \ > - (soc_rev() >= CHIP_REV_1_5)) ?\ > + (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ? \ > ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS_NEW) :\ > - (is_cpu_type(MXC_CPU_MX6DL) && \ > -(soc_rev() >= CHIP_REV_1_2)) ? \ > + (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ? \ Ditto. > ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS_NEW) :\ > ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS) \ > ) > > #define hab_rvt_authenticate_image_p \ > ( \ > - ((is_cpu_type(MXC_CPU_MX6Q) || \ > - is_cpu_type(MXC_CPU_MX6D)) && \ > - (soc_rev() >= CHIP_REV_1_5)) ?\ > + (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ? \ > ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE_NEW) : \ > - (is_cpu_type(MXC_CPU_MX6DL) && \ > -(soc_rev() >= CHIP_REV_1_2)) ? \ > + (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ? \ Ditto. > ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE_NEW) : \ > ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE)\ > ) > > #define hab_rvt_entry_p\ > ( \ > - ((is_cpu_type(MXC_CPU_MX6Q) || \ > - is_cpu_type(MXC_CPU_MX6D)) && \ > - (soc_rev() >= CHIP_REV_1_5)) ?\ > + (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ? \ > ((hab_rvt_entry_t *)HAB_RVT_ENTRY_NEW) :\ > - (is_cpu_type(MXC_CPU_MX6DL) && \ > -(soc_rev() >= CHIP_REV_1_2)) ? \ > + (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ? \ Ditto. > ((hab_rvt_entry_t *)HAB_RVT_ENTRY_NEW) :\ > ((hab_rvt_entry_t *)HAB_RVT_ENTRY) \ > ) > > #define hab_rvt_exit_p \ > ( \ > - ((is_cpu_type(MXC_CPU_MX6Q) || \ > - is_cpu_type(MXC_CPU_MX6D)) && \ > - (soc_rev() >= CHIP_REV_1_5)) ?\ > + (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ? \ > ((hab_rvt_exit_t *)HAB_RVT_EXIT_NEW) : \ > - (is_cpu_type(MXC_CPU_MX6DL) && \ > -(s
Re: [U-Boot] Linker script u-boot.lds makes u-boot ELF not load with debugger
Hi Héctor, On Wed, May 18, 2016 at 1:28 PM, Palacios, Hector wrote: > I'm loading U-Boot to an i.MX6Q platform using ARM DSTREAM debugger and after > running the DDR initialization script it fails to load the u-boot ELF binary > complaining with: > > loadfile "/home/hpalacio/git/u-boot-denx/u-boot" > ERROR(CMD16-TAD11-NAL18): > ! Failed to load "u-boot" > ! Failed to write 160 bytes to address S:0x00010034 > ! Bus error on memory operation. > Target Message: Memory access caused precise abort. > Debug Precise Abort Registers : DFSR = 0x1808, DFAR = 0x00010034 > > > If I revert the changes introduced to arch/arm/cpu/u-boot.lds in commit > 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7, then the u-boot ELF loads fine: [...] > > Does anybody know if I should do anything special in my debugger > initialization script after commit 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 > to have it load U-Boot normally? As explained in the commit message (http://git.denx.de/?p=u-boot.git;a=commitdiff;h=47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7), this change was required in order to make diagnostic tools such as readelf or objdump produce thorough output. A consequence is that some generated ELF files now have some program headers (see https://sourceware.org/binutils/docs/ld/PHDRS.html#PHDRS) that are incompatible with debuggers such as yours because they order these tools to write to non-writable addresses. One solution is to program with the debugger u-boot.bin or another binary objcopied from the original ELF file. Another solution is not to use any debugger to copy the image to the target RAM, but instead to program u-boot.imx to the boot device (NAND, SD, etc.), in which case you have to instruct the debugger to halt execution after reset. You will then even be able to see the ROM bootloader load and boot the binary image from the boot device. However, this solution may be a bit less convenient for frequent target programming. In the longer term, it would be possible to check the current ELF program headers in order to fix the linker scripts for this use case, but doing this in a scalable way for all the targets might prove difficult and maybe not worth it. I think that being able to program a binary file with debuggers is sufficient. Albert, what do you think? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
Hi Michael, On Thu, May 19, 2016 at 08:33:28PM +0200, Michal Simek wrote: > Hi Andreas, > > 2016-05-19 20:16 GMT+02:00 Andreas Dannenberg : > > > Hi Michal, > > > > On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote: > > > On 19.5.2016 18:15, Andreas Dannenberg wrote: > > > > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote: > > > >> Support loading FIT in SPL for RAM bootmode. > > > >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored > > > >> in memory. > > > >> > > > >> Signed-off-by: Michal Simek > > > >> Reviewed-by: Simon Glass > > > >> --- > > > > > > > > Reviewed-by: Andreas Dannenberg > > > > > > > > > > > > That's a very useful addition to the SPL FIT toolbox! I have a use case > > > > where I may need to decrypt/authenticate an SPL FIT image in its > > entirety > > > > before processing it so this can be used for this as well. > > > > > > Do you have also use case where you need to load more files from FIT? > > > There is loadable entry in FIT config entry. > > > > Not yet but I may get there. I'm experimenting with using U-Boot to load > > and install a secure monitor mode application (specifically, OP-TEE OS), > > so that will need to come from somewhere eventually and FIT would be a > > natural place for that binary to reside since we can easily authenticate > > it. > > > ok what arch? > What's the flow which you want to support? > SPL to load OPTEE and ATF and full u-boot and jump to ATF which runs OPTEE > and run to U-Boot? I working with TI's current SoCs and those are ARMv7-A and there is no ATF but instead a proprietary solution comprising ROM code and some low-level code that gets loaded/authenticated/executed by said ROM in a secure fashion before the regular boot flow starts (SPL, U-Boot, and so on). There is flexibility to load/install a new secure monitor code during SPL, U-Boot, or in fact at any other time (even after let's say Linux is booted up) but from an overall system architecture POV we need that new secure monitor (OP-TEE OS in this case) to be up before the Kernel is loaded. Anyways the goal is not only to get it working but also to have a solution that plays nice with everything else and can be contributed upstream. Thanks and Regards, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Delete tests of CONFIG_OF_LIBFDT when testing CONFIG_OF_BOARD_SETUP
Since CONFIG_OF_BOARD_SETUP depends on CONFIG_OF_LIBFDT:
config OF_BOARD_SETUP
bool "Set up board-specific details in device tree before boot"
depends on OF_LIBFDT
...
remove superfluous tests of CONFIG_OF_LIBFDT when testing for
CONFIG_OF_BOARD_SETUP.
Signed-off-by: Robert P. J. Day
---
i just got annoyed looking at that pair of tests and wondering why
they were both there. feel free to sanity check while i fix myself
another martini. oh, and another trivial fixup or two just to keep
things aesthetically consistent.
diff --git a/arch/nios2/cpu/fdt.c b/arch/nios2/cpu/fdt.c
index 79f72aa..a44f51a 100644
--- a/arch/nios2/cpu/fdt.c
+++ b/arch/nios2/cpu/fdt.c
@@ -12,7 +12,7 @@
#include
-#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_OF_BOARD_SETUP
#include
#include
@@ -35,4 +35,4 @@ void ft_cpu_setup(void *blob, bd_t *bd)
*/
fdt_fixup_ethernet(blob);
}
-#endif /* CONFIG_OF_LIBFDT && CONFIG_OF_BOARD_SETUP */
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/arch/powerpc/cpu/mpc5xxx/cpu.c b/arch/powerpc/cpu/mpc5xxx/cpu.c
index 7a463b5..84fabbd 100644
--- a/arch/powerpc/cpu/mpc5xxx/cpu.c
+++ b/arch/powerpc/cpu/mpc5xxx/cpu.c
@@ -96,7 +96,7 @@ unsigned long get_tbclk (void)
/* - */
-#if defined(CONFIG_OF_LIBFDT) && defined (CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_OF_BOARD_SETUP
void ft_cpu_setup(void *blob, bd_t *bd)
{
int div = in_8((void*)CONFIG_SYS_MBAR + 0x204) & 0x0020 ? 8 : 4;
@@ -117,7 +117,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
do_fixup_by_path(blob, eth_path, "mac-address", enetaddr, 6, 0);
do_fixup_by_path(blob, eth_path, "local-mac-address", enetaddr, 6, 0);
#endif
-#if defined(CONFIG_OF_IDE_FIXUP)
+#ifdef CONFIG_OF_IDE_FIXUP
if (!ide_device_present(0)) {
/* NO CF card detected -> delete ata node in DTS */
int nodeoffset = 0;
@@ -132,10 +132,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
}
}
-#endif
+#endif /* CONFIG_OF_IDE_FIXUP */
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
-#endif
+#endif /* CONFIG_OF_BOARD_SETUP */
#ifdef CONFIG_MPC5xxx_FEC
/* Default initializations for FEC controllers. To override,
diff --git a/arch/powerpc/cpu/mpc8260/cpu.c b/arch/powerpc/cpu/mpc8260/cpu.c
index 6eed6f5..9f2be3c 100644
--- a/arch/powerpc/cpu/mpc8260/cpu.c
+++ b/arch/powerpc/cpu/mpc8260/cpu.c
@@ -284,7 +284,7 @@ void watchdog_reset (void)
#endif /* CONFIG_WATCHDOG */
/* - */
-#if defined(CONFIG_OF_LIBFDT) && defined (CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_OF_BOARD_SETUP
void ft_cpu_setup (void *blob, bd_t *bd)
{
#if defined(CONFIG_HAS_ETH0) || defined(CONFIG_HAS_ETH1) ||\
@@ -303,7 +303,7 @@ void ft_cpu_setup (void *blob, bd_t *bd)
"clock-frequency", bd->bi_intfreq, 1);
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
-#endif /* CONFIG_OF_LIBFDT */
+#endif /* CONFIG_OF_BOARD_SETUP */
/*
* Initializes on-chip ethernet controllers.
diff --git a/arch/powerpc/cpu/ppc4xx/fdt.c b/arch/powerpc/cpu/ppc4xx/fdt.c
index eef9c5a..c73509b 100644
--- a/arch/powerpc/cpu/ppc4xx/fdt.c
+++ b/arch/powerpc/cpu/ppc4xx/fdt.c
@@ -11,7 +11,7 @@
#include
#include
-#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_OF_BOARD_SETUP
#include
#include
#include
@@ -160,4 +160,4 @@ void ft_cpu_setup(void *blob, bd_t *bd)
*/
fdt_pcie_setup(blob);
}
-#endif /* CONFIG_OF_LIBFDT && CONFIG_OF_BOARD_SETUP */
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/board/a3m071/a3m071.c b/board/a3m071/a3m071.c
index ee1681b..55d0bc8 100644
--- a/board/a3m071/a3m071.c
+++ b/board/a3m071/a3m071.c
@@ -391,14 +391,14 @@ int misc_init_r(void)
return 0;
}
-#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
return 0;
}
-#endif /* defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP) */
+#endif /* CONFIG_OF_BOARD_SETUP */
#ifdef CONFIG_SPL_OS_BOOT
/*
diff --git a/board/a4m072/a4m072.c b/board/a4m072/a4m072.c
index c5d161b..20d8b80 100644
--- a/board/a4m072/a4m072.c
+++ b/board/a4m072/a4m072.c
@@ -170,14 +170,14 @@ void pci_init_board(void)
}
#endif
-#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
return 0;
}
-#endif
+#endif /* CONFIG_OF_BOARD_SETUP */
int board_eth_init(bd_t *bis)
{
diff --git a/board/amcc/canyonlands/canyonlands.c
b/board/amcc/canyonlands/canyonlands.c
index c5cc4ff..dc2e3ba 100644
--- a/board/amcc/canyonlands/canyonlands.c
+++ b/board/amcc/canyonlands/canyonlands.c
@@ -489,7 +489,7
Re: [U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
Hi Andreas, 2016-05-19 20:16 GMT+02:00 Andreas Dannenberg : > Hi Michal, > > On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote: > > On 19.5.2016 18:15, Andreas Dannenberg wrote: > > > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote: > > >> Support loading FIT in SPL for RAM bootmode. > > >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored > > >> in memory. > > >> > > >> Signed-off-by: Michal Simek > > >> Reviewed-by: Simon Glass > > >> --- > > > > > > Reviewed-by: Andreas Dannenberg > > > > > > > > > That's a very useful addition to the SPL FIT toolbox! I have a use case > > > where I may need to decrypt/authenticate an SPL FIT image in its > entirety > > > before processing it so this can be used for this as well. > > > > Do you have also use case where you need to load more files from FIT? > > There is loadable entry in FIT config entry. > > Not yet but I may get there. I'm experimenting with using U-Boot to load > and install a secure monitor mode application (specifically, OP-TEE OS), > so that will need to come from somewhere eventually and FIT would be a > natural place for that binary to reside since we can easily authenticate > it. ok what arch? What's the flow which you want to support? SPL to load OPTEE and ATF and full u-boot and jump to ATF which runs OPTEE and run to U-Boot? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] why so little use of ft_system_setup()?
still crawling through the code related to FDTs, and while i see a pile of boards that define CONFIG_OF_SYSTEM_SETUP, i see very few that define the corresponding(?) ft_system_setup() routine. $ grep -r CONFIG_OF_SYSTEM_SETUP * cmd/fdt.c:#ifdef CONFIG_OF_SYSTEM_SETUP cmd/fdt.c:#ifdef CONFIG_OF_SYSTEM_SETUP configs/apalis_t30_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/paz00_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/plutux_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/venice2_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/p2571_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/beaver_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/ventana_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/p2371-_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/tec-ng_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/seaboard_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/dalmore_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/harmony_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/cardhu_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/p2371-2180_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/trimslice_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/colibri_t30_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/colibri_t20_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/whistler_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/tec_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/jetson-tk1_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/e2220-1170_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/medcom-wide_defconfig:CONFIG_OF_SYSTEM_SETUP=y configs/nyan-big_defconfig:CONFIG_OF_SYSTEM_SETUP=y include/image.h:#ifdef CONFIG_OF_SYSTEM_SETUP include/fdt_support.h: * This function is called if CONFIG_OF_SYSTEM_SETUP is defined README: CONFIG_OF_SYSTEM_SETUP $ and yet ... $ grep -rw ft_system_setup * arch/arm/mach-tegra/board2.c:int ft_system_setup(void *blob, bd_t *bd) cmd/fdt.c: int err = ft_system_setup(working_fdt, gd->bd); common/image-fdt.c: fdt_ret = ft_system_setup(blob, gd->bd); include/fdt_support.h:int ft_system_setup(void *blob, bd_t *bd); Kconfig: This causes U-Boot to call ft_system_setup() before booting into README: This causes ft_system_setup() to be called before booting $ am i missing something? what is the point of a board defining that setting but not defining the associated(?) ft_system_setup() function? what else is that CONFIG setting being used for? thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
Hi Michal, On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote: > On 19.5.2016 18:15, Andreas Dannenberg wrote: > > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote: > >> Support loading FIT in SPL for RAM bootmode. > >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored > >> in memory. > >> > >> Signed-off-by: Michal Simek > >> Reviewed-by: Simon Glass > >> --- > > > > Reviewed-by: Andreas Dannenberg > > > > > > That's a very useful addition to the SPL FIT toolbox! I have a use case > > where I may need to decrypt/authenticate an SPL FIT image in its entirety > > before processing it so this can be used for this as well. > > Do you have also use case where you need to load more files from FIT? > There is loadable entry in FIT config entry. Not yet but I may get there. I'm experimenting with using U-Boot to load and install a secure monitor mode application (specifically, OP-TEE OS), so that will need to come from somewhere eventually and FIT would be a natural place for that binary to reside since we can easily authenticate it. Thanks and Regards, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] spi: fsl_qspi: Assign AMBA mem according CS num in dts
On 03/14/2016 11:45 PM, Yuan Yao wrote: > From: Yuan Yao > > QSPI controller automatic enable the chipselect signal according the dest > AMBA memory address. Now we distribute the AMBA memory zone averagely to > every chipselect slave device according chipselect numbers got from dts > node. > > Signed-off-by: Yuan Yao > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Yuan Yao > --- > drivers/spi/fsl_qspi.c | 55 > +++--- > 1 file changed, 43 insertions(+), 12 deletions(-) > Jagan, I plan to merge this set. Please let me know if you have any comment. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
On 19.5.2016 18:15, Andreas Dannenberg wrote: > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote: >> Support loading FIT in SPL for RAM bootmode. >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored >> in memory. >> >> Signed-off-by: Michal Simek >> Reviewed-by: Simon Glass >> --- > > Reviewed-by: Andreas Dannenberg > > > That's a very useful addition to the SPL FIT toolbox! I have a use case > where I may need to decrypt/authenticate an SPL FIT image in its entirety > before processing it so this can be used for this as well. Do you have also use case where you need to load more files from FIT? There is loadable entry in FIT config entry. Thanks, Michal ___ 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 19 May 2016 at 10:18, Alexander Graf wrote:
>
> On 05/18/2016 07:21 PM, Simon Glass wrote:
>>
>> +Tom
>>
>> Hi Alex,
>>
>> On 16 May 2016 at 12:06, Alexander Graf wrote:
>>>
>>>
>>> On 16.05.16 15:24, Simon Glass wrote:
Hi Alexander,
On 14 May 2016 at 14:34, Alexander Graf wrote:
>
>
>> 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(&nethandle);
>>> +
>>> + 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,
>>> +
Re: [U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode
On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote: > Support loading FIT in SPL for RAM bootmode. > CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored > in memory. > > Signed-off-by: Michal Simek > Reviewed-by: Simon Glass > --- Reviewed-by: Andreas Dannenberg That's a very useful addition to the SPL FIT toolbox! I have a use case where I may need to decrypt/authenticate an SPL FIT image in its entirety before processing it so this can be used for this as well. -- Andreas Dannenberg Texas Instruments Inc ___ 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 05/18/2016 07:21 PM, Simon Glass wrote:
+Tom
Hi Alex,
On 16 May 2016 at 12:06, Alexander Graf wrote:
On 16.05.16 15:24, Simon Glass wrote:
Hi Alexander,
On 14 May 2016 at 14:34, Alexander Graf wrote:
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(&nethandle);
+
+ 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 *stat_table);
+ efi_status_t (EFIAPI *mcastiptomac)(struct efi_simple_network *this,
+ int ipv6, struct efi_ip_address *ip,
+ struct efi_mac_address *mac);
+ efi_status_t (EFIAPI *nvdata)(struct efi_simple_network *this,
+ int read_write, ulong offset, ulong buffer_size,
+ char *buffer);
+ efi_status_t
Re: [U-Boot] Please pull u-boot-dm
On Thu, May 19, 2016 at 08:41:05AM -0600, Simon Glass wrote: > Hi Tom, > > On 19 May 2016 at 06:09, Tom Rini wrote: > > On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote: > > > >> Hi Tom, > >> > >> This includes a refinement of the GPIO interface, soft SPI fixes, > >> driver model block-device support (and a legacy driver for > >> non-driver-model code) and a few other things. The changes are fairly > >> major so I'd like to get the maximum possible test window. > >> > >> > >> The following changes since commit > >> aeaec0e682f45b9e0c62c522fafea353931f73ed: > >> > >> Prepare v2016.05 (2016-05-16 10:40:32 -0400) > >> > >> are available in the git repository at: > >> > >> git://git.denx.de/u-boot-dm.git > >> > >> for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30: > >> > >> dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600) > >> > > > > Applied to u-boot/master, thanks! > > > > But please note that this is starting to push some boards to or over the > > SPL edge such as Cubietruck so we need to look into some waste areas > > again. Adding Hans in case there's also stuff we could simply be > > dropping out of SPL but aren't today. > > Yes I saw that but the increase was much larger than it should have > been. I meant to try it with the bug-fixed gcc and see if the increase > was smaller. It does unfortunately add a few hundred bytes of code. I > believe it might be possible to reduce this but I haven't yet figured > out how. I've been happy when I can use gcc-6.x for all the free cost savings but current Debian tools (and current Fedora, and current any other big distro) toolchains matter too. You can also see the size growth (but not to fatal proportions) on CHIP or warp7 or MSI_Primo73 -- 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] SPL and FIT images
Am 2016-05-19 14:05, schrieb Lokesh Vutla: Hi Michael, On Thursday 19 May 2016 05:16 PM, mich...@walle.cc wrote: Hi, I'm looking into the FIT support in the SPL, because we are planning to load bootloader from a filesystem (on a MMC device); the SPL will be stored in a write-protected SPI flash. To make sure that a user does not accidentally put a wrong bootloader image on the filesystem, we would like to do some kind of compatiblity checking. I guess this can be done with the FIT image and its compatibility node. Looking into the code I found out, that FIT images only seems to be supported when the bootloader is loaded from raw MMC. FIT support for other boot media was recently posted. Links below: Fat FS: http://patchwork.ozlabs.org/patch/618400/ http://patchwork.ozlabs.org/patch/618403/ http://patchwork.ozlabs.org/patch/618405/ SPI: http://patchwork.ozlabs.org/patch/606959/ NAND: http://patchwork.ozlabs.org/patch/609326/ UART: http://patchwork.ozlabs.org/patch/623918/ http://patchwork.ozlabs.org/patch/623919/ http://patchwork.ozlabs.org/patch/623920/ Let me know if you need more info. Ah, thanks :) -michael ___ 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/19/2016 08:46 AM, Masahiro Yamada wrote: > Hi Marek, > > 2016-05-17 20:01 GMT+09:00 Masahiro Yamada : >> Hi Marek, >> >> >> 2016-05-16 23:46 GMT+09:00 Marek Vasut : >> delete mode 100644 drivers/usb/host/xhci-uniphier.c >>> CCing Roger, so he can check this series. I will review it later today >>> or tomorrow. >>> >> >> 01-03 are probably OK, but 04- might have conflicts with >> Roger's work. >> >> Maybe we should take our time to figure out how we should arrange this. > > > Could you drop 04- from your repository, for now? > > Perhaps, we should discuss this DWC3 topic more carefully? > > Dropped -- 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 07/20] arm: Avoid error messages in cache_v7
On 05/19/2016 06:02 AM, Simon Glass wrote:
> Hi Marek,
>
> On 14 May 2016 at 15:41, Marek Vasut wrote:
>> On 05/14/2016 11:22 PM, Simon Glass wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> On 14 May 2016 at 14:23, Marek Vasut wrote:
On 05/14/2016 10:02 PM, Simon Glass wrote:
> Move these to debug() like the one in check_cache range(), to save SPL
> space.
This hides cache problems, which were visibly reported so far.
I am opposed to this patch.
>>>
>>> Sure, but see check_cache_range(). It uses debug(). In fact I found
>>> the at91 cache problem only after trying #define DEBUG in the code
>>> there.
>>
>> Which is the reason we should really be vocal about such cache misuse.
>> I had a few of such cache problems bite me too, which is why I would
>> like to avoid silencing this warning with debug() by default.
>>
>> I think check_cache_range() should also be fixed and should use printf()
>> by default.
>>
Wouldn't it make more sense to completely disable printf() and co.
in SPL if you're after saving space?
>>>
>>> Or maybe we need something that prints a message in U-Boot proper, but
>>> not SPL? I'll take a look.
>>
>> But what if you trigger the issue only in SPL ?
>
> Yes, but is that likely? So far I don't think the cache is enabled in SPL...
Yeah, it's probably unlikely.
btw have you tried patching away all console IO support in SPL? Does it
save space?
>>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/cpu/armv7/cache_v7.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
> index dc309da..68cf62e 100644
> --- a/arch/arm/cpu/armv7/cache_v7.c
> +++ b/arch/arm/cpu/armv7/cache_v7.c
> @@ -66,8 +66,8 @@ static void v7_dcache_inval_range(u32 start, u32 stop,
> u32 line_len)
>* invalidate the first cache-line
>*/
> if (start & (line_len - 1)) {
> - printf("ERROR: %s - start address is not aligned -
> 0x%08x\n",
> - __func__, start);
> + debug("ERROR: %s - start address is not aligned - 0x%08x\n",
> + __func__, start);
> /* move to next cache line */
> start = (start + line_len - 1) & ~(line_len - 1);
> }
> @@ -77,8 +77,8 @@ static void v7_dcache_inval_range(u32 start, u32 stop,
> u32 line_len)
>* invalidate the last cache-line
>*/
> if (stop & (line_len - 1)) {
> - printf("ERROR: %s - stop address is not aligned - 0x%08x\n",
> - __func__, stop);
> + debug("ERROR: %s - stop address is not aligned - 0x%08x\n",
> + __func__, stop);
> /* align to the beginning of this cache line */
> stop &= ~(line_len - 1);
> }
>
> Regards,
> Simon
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
Hi Tom, On 19 May 2016 at 06:09, Tom Rini wrote: > On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote: > >> Hi Tom, >> >> This includes a refinement of the GPIO interface, soft SPI fixes, >> driver model block-device support (and a legacy driver for >> non-driver-model code) and a few other things. The changes are fairly >> major so I'd like to get the maximum possible test window. >> >> >> The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed: >> >> Prepare v2016.05 (2016-05-16 10:40:32 -0400) >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-dm.git >> >> for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30: >> >> dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600) >> > > Applied to u-boot/master, thanks! > > But please note that this is starting to push some boards to or over the > SPL edge such as Cubietruck so we need to look into some waste areas > again. Adding Hans in case there's also stuff we could simply be > dropping out of SPL but aren't today. Yes I saw that but the increase was much larger than it should have been. I meant to try it with the bug-fixed gcc and see if the increase was smaller. It does unfortunately add a few hundred bytes of code. I believe it might be possible to reduce this but I haven't yet figured out how. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Breakage on gw_ventana
On Thu, May 19, 2016 at 7:05 AM, Stefano Babic wrote: > Hi Tim, > > On 19/05/2016 15:48, Tim Harvey wrote: >> On Thu, May 19, 2016 at 6:02 AM, Stefano Babic wrote: >>> Hi Tim, >>> >>> last changes break build for the gw_ventana board. In fact, in case >>> kernel is on a fs, we need to pass the name for kernel. These two >>> defines should be set into gw_ventana.h: >>> >>> CONFIG_SPL_FS_LOAD_KERNEL_NAME >>> CONFIG_SPL_FS_LOAD_ARGS_NAME >>> >>> I could simply fix it, but it does not make sense without asking you :-) >>> >>> I have also seen that SPL for gw_ventana raises an exception because SPL >>> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). >>> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the >>> mx6 with smaller SRAM has at least 128KB. >>> >> >> Stefano, >> >> Thanks for the heads-up. I have to admit I haven't looked at mainline >> u-boot on Ventana for quite some time - I'm still using a 2015-04 >> branch with some patches on top that I haven't had time to mainline >> yet. >> >> When you say 'last changes' was there something specific? Something >> must of grown the size of the SPL code quite a bit. > > I think (but I am not sure) the biggest increase was done by allowing to > load image directly from filesystem, and then the size increased. > > But I admit I did not take a closer look before - it looks like that > gw_ventana is the first to fail, just because it supports more methods > for booting. Most boards boots just from one media, > That makes sense. Looking at my notes (again this is based on 2015.04) I found the following increases in SPL: base+serial+i2c: 23K +mmc: +12K +nand: +8K +gpio: +4K +env: +12K (big!) +fat: +4K +ext: +8K +fastboot: +4K These numbers were with backported thumb binary support (without it they get much more inflated). My SPL is at 63K currently but that is largely because I'm including nand+mmc and env (both env from nand and from mmc) with the help of a patch to allow either env that didn't get accepted upstream (because of the desire to re-write the env code for DM). I was after a single SPL that could handle a NAND or MMC boot device. I don't include fs support simply because I didn't have the room so if that truly was added I can see how that through it over the edge. I would say the offender is likely the CONFIG_SPL_EXT_SUPPORT that was just added from 291000894ed4d6257830baba547764b86e335b5c. It seems to me that should be in the board config file(s) where needed and not in the general SPL config file, otherwise your adding support that some boards (like ventana!) don't have room for. >> >> Your right that the smallest imx6 SRAM has 128KB although we have to >> be careful not to clobber the SRAM being used by the boot ROM. The >> reference manual indicates (IMX6*RM Figure 8-3) that there is only >> free area 68KB available after you carve out the 28KB reserved >> section, the 24KB MMU table, and the 8K stack. Admittedly I don't know >> if the BOOT rom code really uses all of these areas in such a way that >> it cant load the SPL into any of them. > > I do not know as well - maybe some NXP developers can tell something more. > >> Take a look at my comments at >> the top of include/configs/imx6_spl.h and let me know if you find >> something wrong with my analysis that led to a 64KB max. > > Nothing wrong, but as far as I know in start.S cache and muu are turned > off, and they are turned on later again. This could let us to reuse > maybe the 24KB space previously set by the Bootrom they may be turned off by the time we get to U-Boot SPL or within U-Boot SPL but the question is 'does the boot ROM need them?'. I suppose its not too difficult to test by artificially growing the SPL with random/zero'd data and letting it clobber the 24KB shown for the MMU table. Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] usb: dwc3: fix kconfig
DWC3 can be used as host or as gadget controller and the actual mode
is determined at runtime so USB_DWC3_DUAL_ROLE must be the default
mode when both host and gadget drivers are available.
As DWC3 core implements an XHCI host controller, we use USB_XHCI_HCD to
check if host driver is available.
USB_DWC3_HOST and USB_DWC3_GADGET are only set if a particular mode
needs to be forced or if both host and gadget drivers are not available.
Build the dwc3 gadget drivers only if gadget mode can be used at runtime.
Signed-off-by: Roger Quadros
---
v2:
- don't depend on USB as dwc3/kconfig already depends on that
- use USB_XHCI_HCD to decide whether host operation is available.
- Add USB_DWC3_DUAL_ROLE, which means that controller can operate
either in host or gadget mode. The actual mode is decided at runtime
based on dwc3->dr_mode.
drivers/usb/dwc3/Kconfig | 18 +-
drivers/usb/dwc3/Makefile | 4 +++-
drivers/usb/dwc3/core.h | 4 ++--
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index e93398f..0db536e 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,19 +1,20 @@
config USB_DWC3
bool "DesignWare USB3 DRD Core Support"
- depends on (USB && USB_GADGET)
- select USB_GADGET_DUALSPEED
+ select USB_GADGET_DUALSPEED if USB_GADGET
help
- Say Y here if your system has a Dual Role SuperSpeed
- USB controller based on the DesignWare USB3 IP Core.
+ Say Y here if your system has DesignWare USB3 IP Core.
if USB_DWC3
choice
bool "DWC3 Mode Selection"
+ default USB_DWC3_DUAL_ROLE if (USB_GADGET && USB_XHCI_HCD)
+ default USB_DWC3_HOST if (!USB_GADGET && USB_XHCI_HCD)
+ default USB_DWC3_GADGET if (USB_GADGET && !USB_XHCI_HCD)
config USB_DWC3_HOST
bool "Host only mode"
- depends on USB
+ depends on USB_XHCI_HCD
help
Select this when you want to use DWC3 in host mode only,
thereby the gadget feature will be regressed.
@@ -25,6 +26,13 @@ config USB_DWC3_GADGET
Select this when you want to use DWC3 in gadget mode only,
thereby the host feature will be regressed.
+config USB_DWC3_DUAL_ROLE
+ bool "Dual role mode"
+ depends on (USB_XHCI_HCD && USB_GADGET)
+ help
+This is the default mode of working of DWC3 controller where
+both host and gadget features are enabled.
+
endchoice
comment "Platform Glue Driver Support"
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 0cd7302..d2ad2e9 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -6,7 +6,9 @@ obj-$(CONFIG_USB_DWC3) += dwc3.o
dwc3-y := core.o
-dwc3-y += gadget.o ep0.o
+ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
+dwc3-yi+= gadget.o ep0.o
+endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_PHY_OMAP)+= ti_usb_phy.o
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 72d2fcd..faf0c0f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -989,7 +989,7 @@ struct dwc3_gadget_ep_cmd_params {
/* prototypes */
int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
-#ifdef CONFIG_USB_DWC3_HOST
+#if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
int dwc3_host_init(struct dwc3 *dwc);
void dwc3_host_exit(struct dwc3 *dwc);
#else
@@ -999,7 +999,7 @@ static inline void dwc3_host_exit(struct dwc3 *dwc)
{ }
#endif
-#ifdef CONFIG_USB_DWC3_GADGET
+#if IS_ENABLED(CONFIG_USB_DWC3_GADGET) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
int dwc3_gadget_init(struct dwc3 *dwc);
void dwc3_gadget_exit(struct dwc3 *dwc);
int dwc3_gadget_set_test_mode(struct dwc3 *dwc, int mode);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Breakage on gw_ventana
Hi Tim, On 19/05/2016 15:48, Tim Harvey wrote: > On Thu, May 19, 2016 at 6:02 AM, Stefano Babic wrote: >> Hi Tim, >> >> last changes break build for the gw_ventana board. In fact, in case >> kernel is on a fs, we need to pass the name for kernel. These two >> defines should be set into gw_ventana.h: >> >> CONFIG_SPL_FS_LOAD_KERNEL_NAME >> CONFIG_SPL_FS_LOAD_ARGS_NAME >> >> I could simply fix it, but it does not make sense without asking you :-) >> >> I have also seen that SPL for gw_ventana raises an exception because SPL >> is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). >> Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the >> mx6 with smaller SRAM has at least 128KB. >> > > Stefano, > > Thanks for the heads-up. I have to admit I haven't looked at mainline > u-boot on Ventana for quite some time - I'm still using a 2015-04 > branch with some patches on top that I haven't had time to mainline > yet. > > When you say 'last changes' was there something specific? Something > must of grown the size of the SPL code quite a bit. I think (but I am not sure) the biggest increase was done by allowing to load image directly from filesystem, and then the size increased. But I admit I did not take a closer look before - it looks like that gw_ventana is the first to fail, just because it supports more methods for booting. Most boards boots just from one media, > > Your right that the smallest imx6 SRAM has 128KB although we have to > be careful not to clobber the SRAM being used by the boot ROM. The > reference manual indicates (IMX6*RM Figure 8-3) that there is only > free area 68KB available after you carve out the 28KB reserved > section, the 24KB MMU table, and the 8K stack. Admittedly I don't know > if the BOOT rom code really uses all of these areas in such a way that > it cant load the SPL into any of them. I do not know as well - maybe some NXP developers can tell something more. > Take a look at my comments at > the top of include/configs/imx6_spl.h and let me know if you find > something wrong with my analysis that led to a 64KB max. Nothing wrong, but as far as I know in start.S cache and muu are turned off, and they are turned on later again. This could let us to reuse maybe the 24KB space previously set by the Bootrom Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] spl: Add an option to load a FIT containing U-Boot from UART
On Thu, May 19, 2016 at 03:57:57PM +0530, Lokesh Vutla wrote: > This provides a way to load a FIT containing U-Boot and a selection of device > tree files from UART. > > Signed-off-by: Lokesh Vutla Reviewed-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 1/3] spl: fit: Do not print selected dtb during fit load
On Thu, May 19, 2016 at 03:57:55PM +0530, Lokesh Vutla wrote: > Uart boot is failing when a printf is called while loading image. So, disable > prints while loading FIT image. > > Signed-off-by: Lokesh Vutla Reviewed-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 2/3] spl: fit: Detect a FS load using filename
On Thu, May 19, 2016 at 03:57:56PM +0530, Lokesh Vutla wrote: > Right now a FS load for fit is being detected using the priv field. But > this can be used by others media. So, introduce a filename field to > detect a FS load. > > Signed-off-by: Lokesh Vutla Reviewed-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] Breakage on gw_ventana
On Thu, May 19, 2016 at 6:02 AM, Stefano Babic wrote: > Hi Tim, > > last changes break build for the gw_ventana board. In fact, in case > kernel is on a fs, we need to pass the name for kernel. These two > defines should be set into gw_ventana.h: > > CONFIG_SPL_FS_LOAD_KERNEL_NAME > CONFIG_SPL_FS_LOAD_ARGS_NAME > > I could simply fix it, but it does not make sense without asking you :-) > > I have also seen that SPL for gw_ventana raises an exception because SPL > is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). > Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the > mx6 with smaller SRAM has at least 128KB. > Stefano, Thanks for the heads-up. I have to admit I haven't looked at mainline u-boot on Ventana for quite some time - I'm still using a 2015-04 branch with some patches on top that I haven't had time to mainline yet. When you say 'last changes' was there something specific? Something must of grown the size of the SPL code quite a bit. Your right that the smallest imx6 SRAM has 128KB although we have to be careful not to clobber the SRAM being used by the boot ROM. The reference manual indicates (IMX6*RM Figure 8-3) that there is only free area 68KB available after you carve out the 28KB reserved section, the 24KB MMU table, and the 8K stack. Admittedly I don't know if the BOOT rom code really uses all of these areas in such a way that it cant load the SPL into any of them. Take a look at my comments at the top of include/configs/imx6_spl.h and let me know if you find something wrong with my analysis that led to a 64KB max. Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Breakage on gw_ventana
Hi Tim, last changes break build for the gw_ventana board. In fact, in case kernel is on a fs, we need to pass the name for kernel. These two defines should be set into gw_ventana.h: CONFIG_SPL_FS_LOAD_KERNEL_NAME CONFIG_SPL_FS_LOAD_ARGS_NAME I could simply fix it, but it does not make sense without asking you :-) I have also seen that SPL for gw_ventana raises an exception because SPL is bigger as the value set into imx6_spl.h (CONFIG_SPL_MAX_SIZE = 64Kb). Anyway, CONFIG_SPL_MAX_SIZE for i.MX& iss too restrictive, and even the mx6 with smaller SRAM has at least 128KB. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] style issue: ft_board_setup() versus ft_verify_fdt()?
curious about recommended coding style related to modifying and
verifying FDTs ... i'm perusing common/image-fdt.c and can see the
order of (possible) operations here in the function
image_setup_libfdt():
* arch_fixup_fdt()
* ft_board_setup()
* ft_system_setup()
* fdt_fixup_ethernet()
... etc etc ...
* ft_verify_fdt()
where an earlier comment explains that last routine:
/*
* Verify the device tree.
*
* This function is called after all device tree fix-ups have been enacted,
* so that the final device tree can be verified. The definition of "verified"
* is up to the specific implementation. However, it generally means that the
* addresses of some of the devices in the device tree are compared with the
* actual addresses at which U-Boot has placed them.
*
* Returns 1 on success, 0 on failure. If 0 is returned, U-Boot will halt the
* boot process.
*/
__weak int ft_verify_fdt(void *fdt)
{
return 1;
}
which seems reasonable ... after you've mangled your FDT in every
way you need, optionally supply a routine to make sure it looks sane.
however, for the freescale board mpc8641hpcn.c, here's part of the
ft_board_setup() routine (actually, this is pretty much all that
function does):
if (tmp) {
u64 addr;
if (addrcells == 1)
addr = *(u32 *)tmp;
else
addr = *tmp;
if (addr != CONFIG_SYS_CCSRBAR_PHYS)
printf("WARNING: The CCSRBAR address in your .dts "
"does not match the address of the CCSR "
"in u-boot. This means your .dts might "
"be old.\n");
}
so the board setup routine is doing some quick sanity checking, which
is perfectly fine, but seems to be exactly the sort of thing
ft_verify_fdt() was designed for.
obviously, one can add sanity checking to any of those routines
depending on how early you want to notice stuff -- is there somewhere
a style guide that gives recommendations? just looking for "best
practices," thanks.
i'm sure there will be more FDT-related questions coming ... thank
you for your patience.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-imx
On 19/05/2016 14:08, Tom Rini wrote: > On Tue, May 17, 2016 at 05:57:32PM +0200, Stefano Babic wrote: > >> Hi Tom, >> >> please pull from u-boot-imx, thanks ! >> >> The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed: >> >> Prepare v2016.05 (2016-05-16 10:40:32 -0400) >> >> are available in the git repository at: >> >> git://www.denx.de/git/u-boot-imx.git master >> >> for you to fetch changes up to 291000894ed4d6257830baba547764b86e335b5c: >> >> ARM: mx6: Enable MMC and SATA extfs boot support (2016-05-17 17:52:20 >> +0200) >> > > Applied to u-boot/master, thanks! > > But please note that this broke gwventana and that needs a minor follow > up to fix, please do so, thanks! > I see - I check it this issue, thanks ! Regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Ethernet on Colombus (sun6i-a31-colombus)
Hi, On Thu, May 19, 2016 at 10:53:50AM +0200, Quentin Schulz wrote: > Hi, > > I put U-Boot for the Colombus on an SD Card but could not make Ethernet > work. > > In U-Boot v2015.10, v2016.01 and v2016.05, Ethernet port is not detected. > In U-Boot v2016.03, the Ethernet port is detected but cannot be used. I > get the following error: To be a Bit more precise, we've been (obviously) using the Colombus_defconfig configuration. In the former case, the ethernet device doesn't even get registered apparently (while it does on the hummingbird, which is kind of weird). In the latter, we get: > => dhcp > ethernet@01c3 Waiting for PHY auto negotiation to complete. > TIMEOUT ! > ethernet@01c3: No link. Which seems to be that the PHY isn't powered up. We looked at the schematics, and there's nothing really standing out. Chen-Yu also suggested to poke the PA21 pin that is usually used for PHY reset, but it didn't really change anything. I think you had a Colombus Hans, have you tested it lately? Was it working out of the box for you, or is there some GPIO that needs to be poked somewhere? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] sh: Add missing symbol for generic board
Signed-off-by: Yoshinori Sato --- arch/sh/cpu/u-boot.lds | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sh/cpu/u-boot.lds b/arch/sh/cpu/u-boot.lds index 30c7a9d..4e8b718 100644 --- a/arch/sh/cpu/u-boot.lds +++ b/arch/sh/cpu/u-boot.lds @@ -80,4 +80,5 @@ SECTIONS PROVIDE (bss_end = .); PROVIDE (__bss_end = .); + PROVIDE (__init_end = .); } -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9] sh: generic board support - Kconfig
Signed-off-by: Yoshinori Sato --- arch/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index ec12013..291e1dc 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -96,6 +96,8 @@ config SANDBOX config SH bool "SuperH architecture" select HAVE_PRIVATE_LIBGCC + select HAVE_GENERIC_BOARD + select SYS_GENERIC_BOARD config SPARC bool "SPARC architecture" -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] sh: Remove arch specific board.c
Signed-off-by: Yoshinori Sato
---
arch/sh/lib/Makefile | 1 -
arch/sh/lib/board.c | 189 ---
2 files changed, 190 deletions(-)
delete mode 100644 arch/sh/lib/board.c
diff --git a/arch/sh/lib/Makefile b/arch/sh/lib/Makefile
index f7ae4f8..c5cf89f 100644
--- a/arch/sh/lib/Makefile
+++ b/arch/sh/lib/Makefile
@@ -6,7 +6,6 @@
#
-obj-y += board.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
ifeq ($(CONFIG_CPU_SH2),y)
obj-y += time_sh2.o
diff --git a/arch/sh/lib/board.c b/arch/sh/lib/board.c
deleted file mode 100644
index 69cdca3..000
--- a/arch/sh/lib/board.c
+++ /dev/null
@@ -1,189 +0,0 @@
-/*
- * Copyright (C) 2007, 2008, 2010
- * Nobuhiro Iwamatsu
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#ifdef CONFIG_BITBANGMII
-#include
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-extern int cpu_init(void);
-extern int board_init(void);
-extern int dram_init(void);
-extern int timer_init(void);
-
-unsigned long monitor_flash_len = CONFIG_SYS_MONITOR_LEN;
-
-#ifndef CONFIG_SYS_NO_FLASH
-static int sh_flash_init(void)
-{
- gd->bd->bi_flashsize = flash_init();
-
- if (gd->bd->bi_flashsize >= (1024 * 1024))
- printf("Flash: %ldMB\n", gd->bd->bi_flashsize / (1024*1024));
- else
- printf("Flash: %ldKB\n", gd->bd->bi_flashsize / 1024);
-
- return 0;
-}
-#endif /* CONFIG_SYS_NO_FLASH */
-
-#if defined(CONFIG_CMD_NAND)
-# include
-# define INIT_FUNC_NAND_INIT nand_init,
-#else
-# define INIT_FUNC_NAND_INIT
-#endif /* CONFIG_CMD_NAND */
-
-#if defined(CONFIG_WATCHDOG)
-extern int watchdog_init(void);
-extern int watchdog_disable(void);
-# undef INIT_FUNC_WATCHDOG_INIT
-# define INIT_FUNC_WATCHDOG_INIT watchdog_init,
-# define WATCHDOG_DISABLE watchdog_disable
-#else
-# define INIT_FUNC_WATCHDOG_INIT
-# define WATCHDOG_DISABLE
-#endif /* CONFIG_WATCHDOG */
-
-#if defined(CONFIG_CMD_IDE)
-# include
-# define INIT_FUNC_IDE_INITide_init,
-#else
-# define INIT_FUNC_IDE_INIT
-#endif /* CONFIG_CMD_IDE */
-
-#if defined(CONFIG_PCI)
-#include
-static int sh_pci_init(void)
-{
- pci_init();
- return 0;
-}
-# define INIT_FUNC_PCI_INIT sh_pci_init,
-#else
-# define INIT_FUNC_PCI_INIT
-#endif /* CONFIG_PCI */
-
-static int sh_mem_env_init(void)
-{
- mem_malloc_init(CONFIG_SYS_TEXT_BASE - GENERATED_GBL_DATA_SIZE -
- CONFIG_SYS_MALLOC_LEN, CONFIG_SYS_MALLOC_LEN - 16);
- env_relocate();
- jumptable_init();
- return 0;
-}
-
-#if defined(CONFIG_CMD_MMC)
-static int sh_mmc_init(void)
-{
- puts("MMC: ");
- mmc_initialize(gd->bd);
- return 0;
-}
-#endif
-
-typedef int (init_fnc_t) (void);
-
-init_fnc_t *init_sequence[] =
-{
- cpu_init, /* basic cpu dependent setup */
- board_init, /* basic board dependent setup */
- interrupt_init, /* set up exceptions */
- env_init, /* event init */
- serial_init,/* SCIF init */
- INIT_FUNC_WATCHDOG_INIT /* watchdog init */
- console_init_f,
- display_options,
- checkcpu,
- checkboard, /* Check support board */
- dram_init, /* SDRAM init */
- timer_init, /* SuperH Timer (TCNT0 only) init */
- sh_mem_env_init,
-#ifndef CONFIG_SYS_NO_FLASH
- sh_flash_init, /* Flash memory init*/
-#endif
- INIT_FUNC_NAND_INIT/* Flash memory (NAND) init */
- INIT_FUNC_PCI_INIT /* PCI init */
- stdio_init,
- console_init_r,
- interrupt_init,
-#ifdef CONFIG_BOARD_LATE_INIT
- board_late_init,
-#endif
-#if defined(CONFIG_CMD_MMC)
- sh_mmc_init,
-#endif
- NULL/* Terminate this list */
-};
-
-void sh_generic_init(void)
-{
- bd_t *bd;
- init_fnc_t **init_fnc_ptr;
-
- memset(gd, 0, GENERATED_GBL_DATA_SIZE);
-
- gd->flags |= GD_FLG_RELOC; /* tell others: relocation done */
-
- gd->bd = (bd_t *)(gd + 1); /* At end of global data */
- gd->baudrate = CONFIG_BAUDRATE;
-
- gd->cpu_clk = CONFIG_SYS_CLK_FREQ;
-
- bd = gd->bd;
- bd->bi_memstart = CONFIG_SYS_SDRAM_BASE;
- bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
-#ifndef CONFIG_SYS_NO_FLASH
- bd->bi_flashstart = CONFIG_SYS_FLASH_BASE;
-#endif
-#if defined(CONFIG_SYS_SRAM_BASE) && defined(CONFIG_SYS_SRAM_SIZE)
- bd->bi_sramstart = CONFIG_SYS_SRAM_BASE;
- bd->bi_sramsize = CONFIG_SYS_SRAM_SIZE;
-#endif
-
- for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
- WATCHDOG_RESET();
- if ((*init_fnc_ptr) () != 0)
- hang();
- }
-
-#ifdef CONFIG_WATCHDOG
- /* disable watchdog if environment is set */
- {
- char *s = getenv("watchdog");
- if (s != NULL)
-
[U-Boot] [PATCH 0/9] sh: Convert generic board
Hello. This patch series convert generic board for SH. Tested on r2dplus target. Yoshinori Sato (9): board_f: Add relocate_code stub board_f: Add SH specific timer_init board_f: if SKIP_RELOC is ture, return from board_init_f board_f: Add SH specific mon_len sh: Add missing symbol for generic board sh: Remove arch specific board.c sh: generic board support - startup sh: generic board support - header sh: generic board support - Kconfig arch/Kconfig | 2 + arch/sh/cpu/sh2/cpu.c| 9 +++ arch/sh/cpu/sh2/start.S | 22 +++-- arch/sh/cpu/sh3/cpu.c| 9 +++ arch/sh/cpu/sh3/start.S | 21 +++-- arch/sh/cpu/sh4/cpu.c| 9 +++ arch/sh/cpu/sh4/start.S | 23 -- arch/sh/cpu/u-boot.lds | 1 + arch/sh/include/asm/u-boot.h | 11 +-- arch/sh/lib/Makefile | 1 - arch/sh/lib/board.c | 189 --- common/board_f.c | 12 ++- 12 files changed, 86 insertions(+), 223 deletions(-) delete mode 100644 arch/sh/lib/board.c -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] board_f: Add SH specific timer_init
Signed-off-by: Yoshinori Sato
---
common/board_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index bf768d1..fcc69b8 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -870,7 +870,7 @@ static init_fnc_t init_sequence_f[] = {
#endif
#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \
defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32) || \
- defined(CONFIG_SPARC)
+ defined(CONFIG_SPARC) || defined(CONFIG_SH)
timer_init, /* initialize timer */
#endif
#ifdef CONFIG_SYS_ALLOC_DPRAM
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] sh: generic board support - startup
Signed-off-by: Yoshinori Sato
---
arch/sh/cpu/sh2/cpu.c | 9 +
arch/sh/cpu/sh2/start.S | 22 --
arch/sh/cpu/sh3/cpu.c | 9 +
arch/sh/cpu/sh3/start.S | 21 +++--
arch/sh/cpu/sh4/cpu.c | 9 +
arch/sh/cpu/sh4/start.S | 23 +++
6 files changed, 73 insertions(+), 20 deletions(-)
diff --git a/arch/sh/cpu/sh2/cpu.c b/arch/sh/cpu/sh2/cpu.c
index a2f856f..8119893 100644
--- a/arch/sh/cpu/sh2/cpu.c
+++ b/arch/sh/cpu/sh2/cpu.c
@@ -10,6 +10,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
#define STBCR4 0xFFFE040C
#define cmt_clock_enable() do {\
writeb(readb(STBCR4) & ~0x04, STBCR4);\
@@ -83,3 +85,10 @@ int dcache_status(void)
{
return 0;
}
+
+int arch_cpu_init(void)
+{
+ gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
+
+ return 0;
+}
diff --git a/arch/sh/cpu/sh2/start.S b/arch/sh/cpu/sh2/start.S
index ebf731a..0ee771c 100644
--- a/arch/sh/cpu/sh2/start.S
+++ b/arch/sh/cpu/sh2/start.S
@@ -7,6 +7,7 @@
#include
#include
+#include
.text
.align 2
@@ -43,12 +44,18 @@ _init:
cmp/hs r5, r4
bf 3b
- mov.l ._gd_init, r13 /* global data */
- mov.l ._stack_init, r15 /* stack */
+ mov.l ._stack_init, r15
+ mov.l ._board_init_f_init_reserve, r0
+ jsr @r0
+ mov r15, r4
- mov.l ._sh_generic_init, r0
+ mov.l ._board_init_f, r0
jsr @r0
- nop
+ mov ._bootflag ,r4
+
+ mov.l ._board_init_r, r0
+ jsr @r0
+ mov r13,r4
loop:
bra loop
@@ -61,5 +68,8 @@ loop:
._bss_start: .long bss_start
._bss_end: .long bss_end
._gd_init: .long (_sh_start - GENERATED_GBL_DATA_SIZE)
-._stack_init: .long (_sh_start - GENERATED_GBL_DATA_SIZE -
CONFIG_SYS_MALLOC_LEN - 16)
-._sh_generic_init: .long sh_generic_init
+._stack_init: .long (_sh_start - GENERATED_GBL_DATA_SIZE -
CONFIG_SYS_MALLOC_LEN - CONFIG_ENV_SIZE- 16)
+._board_init_f:.long board_init_f
+._board_init_r:.long board_init_r
+._board_init_f_init_reserve: .long board_init_f_init_reserve
+._bootflag:.long GD_FLG_SKIP_RELOC
diff --git a/arch/sh/cpu/sh3/cpu.c b/arch/sh/cpu/sh3/cpu.c
index ea0006a..85cb6a3 100644
--- a/arch/sh/cpu/sh3/cpu.c
+++ b/arch/sh/cpu/sh3/cpu.c
@@ -12,6 +12,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
int checkcpu(void)
{
puts("CPU: SH3\n");
@@ -66,3 +68,10 @@ int dcache_status(void)
{
return 0;
}
+
+int arch_cpu_init(void)
+{
+ gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
+
+ return 0;
+}
diff --git a/arch/sh/cpu/sh3/start.S b/arch/sh/cpu/sh3/start.S
index 7a934e2..a1633a7 100644
--- a/arch/sh/cpu/sh3/start.S
+++ b/arch/sh/cpu/sh3/start.S
@@ -10,6 +10,7 @@
#include
#include
+#include
.text
.align 2
@@ -42,13 +43,18 @@ _sh_start:
cmp/hs r5, r4
bf 3b
- mov.l ._gd_init, r13 /* global data */
- mov.l ._stack_init, r15 /* stack */
+ mov.l ._stack_init, r15
+ mov.l ._board_init_f_init_reserve, r0
+ jsr @r0
+ mov r15, r4
- mov.l ._sh_generic_init, r0
+ mov.l ._board_init_f, r0
jsr @r0
- nop
+ mov #._bootflag, r4
+ mov.l ._board_init_r, r0
+ jsr @r0
+ mov r13,r4
loop:
bra loop
@@ -60,5 +66,8 @@ loop:
._bss_start: .long bss_start
._bss_end: .long bss_end
._gd_init: .long (_sh_start - GENERATED_GBL_DATA_SIZE)
-._stack_init: .long (_sh_start - GENERATED_GBL_DATA_SIZE -
CONFIG_SYS_MALLOC_LEN - 16)
-._sh_generic_init: .long sh_generic_init
+._stack_init: .long (_sh_start - GENERATED_GBL_DATA_SIZE -
CONFIG_SYS_MALLOC_LEN - CONFIG_ENV_SIZE - 16)
+._board_init_f:.long board_init_f
+._board_init_r:.long board_init_r
+._board_init_f_init_reserve: .long board_init_f_init_reserve
+._bootflag:.long GD_FLG_SKIP_RELOC
diff --git a/arch/sh/cpu/sh4/cpu.c b/arch/sh/cpu/sh4/cpu.c
index e8ee0a4..fea8e59 100644
--- a/arch/sh/cpu/sh4/cpu.c
+++ b/arch/sh/cpu/sh4/cpu.c
@@ -11,6 +11,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
int checkcpu(void)
{
puts("CPU: SH4\n");
@@ -75,3 +77,10 @@ int cpu_eth_init(bd_t *bis)
#endif
return 0;
}
+
+int arch_cpu_init(void)
+{
+ gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
+
+ return 0;
+}
diff --git a/arch/sh/cpu/sh4/start.S b/arch/sh/cpu/sh4/start.S
index 21644b5..52f960c 100644
--- a/arch/sh/cpu/sh4/start.S
+++ b/arch/sh/cpu/sh4/start.S
@@ -7,6 +7,7 @@
#include
#include
+#include
.text
.align 2
@@ -39,16 +40,20 @@ _sh_start:
cmp/hs r5, r4
bf 3b
- mov.l ._gd_init, r13 /* global data
[U-Boot] [PATCH 8/9] sh: generic board support - header
Signed-off-by: Yoshinori Sato
---
arch/sh/include/asm/u-boot.h | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/sh/include/asm/u-boot.h b/arch/sh/include/asm/u-boot.h
index ea37c24..9e578a6 100644
--- a/arch/sh/include/asm/u-boot.h
+++ b/arch/sh/include/asm/u-boot.h
@@ -12,16 +12,7 @@
#ifndef __ASM_SH_U_BOOT_H_
#define __ASM_SH_U_BOOT_H_
-typedef struct bd_info {
- unsigned long bi_memstart;/* start of DRAM memory */
- phys_size_t bi_memsize; /* size of DRAM memory in bytes */
- unsigned long bi_flashstart; /* start of FLASH memory */
- unsigned long bi_flashsize; /* size of FLASH memory */
- unsigned long bi_flashoffset; /* reserved area for startup monitor */
- unsigned long bi_sramstart; /* start of SRAM memory */
- unsigned long bi_sramsize;/* size of SRAM memory */
- unsigned long bi_boot_params; /* where this board expects params */
-} bd_t;
+#include
/* For image.h:image_check_target_arch() */
#define IH_ARCH_DEFAULT IH_ARCH_SH
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] board_f: Add relocate_code stub
Signed-off-by: Yoshinori Sato
---
common/board_f.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index 109025a..bf768d1 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -826,6 +826,11 @@ __weak int arch_cpu_init_dm(void)
return 0;
}
+__weak void relocate_code(ulong sp, gd_t *new_gd, ulong reloc)
+{
+ for(;;);
+}
+
static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_SANDBOX
setup_ram_buf,
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] board_f: if SKIP_RELOC is ture, return from board_init_f
Signed-off-by: Yoshinori Sato --- common/board_f.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index fcc69b8..e1122e3 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -1067,7 +1067,8 @@ void board_init_f(ulong boot_flags) #if !defined(CONFIG_ARM) && !defined(CONFIG_SANDBOX) && \ !defined(CONFIG_EFI_APP) /* NOTREACHED - jump_to_copy() does not return */ - hang(); +if (!(gd->flags & GD_FLG_SKIP_RELOC)) + hang(); #endif } -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] board_f: Add SH specific mon_len
Signed-off-by: Yoshinori Sato --- common/board_f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index e1122e3..f31f2de 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -270,7 +270,7 @@ static int setup_mon_len(void) gd->mon_len = (ulong)&__bss_end - (ulong)_start; #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP) gd->mon_len = (ulong)&_end - (ulong)_init; -#elif defined(CONFIG_BLACKFIN) || defined(CONFIG_NIOS2) +#elif defined(CONFIG_BLACKFIN) || defined(CONFIG_NIOS2) || defined(CONFIG_SH) gd->mon_len = CONFIG_SYS_MONITOR_LEN; #elif defined(CONFIG_NDS32) gd->mon_len = (ulong)(&__bss_end) - (ulong)(&_start); -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL and FIT images
Hi Michael, On Thursday 19 May 2016 05:16 PM, mich...@walle.cc wrote: > Hi, > > I'm looking into the FIT support in the SPL, because we are planning to > load bootloader from a filesystem (on a MMC device); the SPL will be > stored in a write-protected SPI flash. To make sure that a user does not > accidentally put a wrong bootloader image on the filesystem, we would > like to do some kind of compatiblity checking. I guess this can be done > with the FIT image and its compatibility node. Looking into the code I > found out, that FIT images only seems to be supported when the > bootloader is loaded from raw MMC. FIT support for other boot media was recently posted. Links below: Fat FS: http://patchwork.ozlabs.org/patch/618400/ http://patchwork.ozlabs.org/patch/618403/ http://patchwork.ozlabs.org/patch/618405/ SPI: http://patchwork.ozlabs.org/patch/606959/ NAND: http://patchwork.ozlabs.org/patch/609326/ UART: http://patchwork.ozlabs.org/patch/623918/ http://patchwork.ozlabs.org/patch/623919/ http://patchwork.ozlabs.org/patch/623920/ Let me know if you need more info. Thanks and regards, Lokesh > > Simon, since this code is from you, might I ask, why you didn't put it > into the common spl.c (spl_parse_image_header(), etc) so it could be > used for all other methods, too? I just want to make sure, there is no > reason not to do it for our case. > > -michael > ___ > 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] Please pull u-boot-dm
On Tue, May 17, 2016 at 11:46:53AM -0600, Simon Glass wrote: > Hi Tom, > > This includes a refinement of the GPIO interface, soft SPI fixes, > driver model block-device support (and a legacy driver for > non-driver-model code) and a few other things. The changes are fairly > major so I'd like to get the maximum possible test window. > > > The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed: > > Prepare v2016.05 (2016-05-16 10:40:32 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-dm.git > > for you to fetch changes up to 341392dd115f1385c31bb0b034ec15f542730e30: > > dm: mmc: test: Add tests for MMC (2016-05-17 09:54:43 -0600) > Applied to u-boot/master, thanks! But please note that this is starting to push some boards to or over the SPL edge such as Cubietruck so we need to look into some waste areas again. Adding Hans in case there's also stuff we could simply be dropping out of SPL but aren't today. -- 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 from u-boot-i2c
On Tue, May 17, 2016 at 02:30:28PM +0200, Heiko Schocher wrote: > Hello Tom, > > please pull from u-boot-i2c.git master > > There is a compile fix from Mario, also DM support for fsl_i2c, > DM support for TI PCA954X muxes from Michal, a check for the enable > status register in the designware i2c driver from Stefan and a fix > for the mvtwsi driver, which now does not need writting a global > variable. > > buildman says no errors introduced, so I think its ready for mainline ... > > The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed: > > Prepare v2016.05 (2016-05-16 10:40:32 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-i2c.git master > > for you to fetch changes up to d6b7757e41d22e08f21f58d3fe9183a150582f61: > > i2c: mvtwsi: Eliminate twsi_control_flags (2016-05-17 08:32:02 +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] [PULL] Please pull u-boot-imx
On Tue, May 17, 2016 at 05:57:32PM +0200, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx, thanks ! > > The following changes since commit aeaec0e682f45b9e0c62c522fafea353931f73ed: > > Prepare v2016.05 (2016-05-16 10:40:32 -0400) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 291000894ed4d6257830baba547764b86e335b5c: > > ARM: mx6: Enable MMC and SATA extfs boot support (2016-05-17 17:52:20 > +0200) > Applied to u-boot/master, thanks! But please note that this broke gwventana and that needs a minor follow up to fix, please do so, thanks! -- 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] SPL and FIT images
Hi, I'm looking into the FIT support in the SPL, because we are planning to load bootloader from a filesystem (on a MMC device); the SPL will be stored in a write-protected SPI flash. To make sure that a user does not accidentally put a wrong bootloader image on the filesystem, we would like to do some kind of compatiblity checking. I guess this can be done with the FIT image and its compatibility node. Looking into the code I found out, that FIT images only seems to be supported when the bootloader is loaded from raw MMC. Simon, since this code is from you, might I ask, why you didn't put it into the common spl.c (spl_parse_image_header(), etc) so it could be used for all other methods, too? I just want to make sure, there is no reason not to do it for our case. -michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: ipu: Use lldiv() for 64-bit division in ipu_pixel_clk_set_rate()
Fix compilation problems with a hardfloat toolchain on ARM (libgcc.a(_udivmoddi4.o) uses VFP register arguments, u-boot does not). Cast clk->parent->rate to u64 before the multiplication to avoid overflowing a 32-bit value. Bug introduced by 3cb4f25cc702db17455583599d0940c81337a17a. Signed-off-by: Andrew Shadura --- drivers/video/ipu_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c index 36d4b23..dad3e6f 100644 --- a/drivers/video/ipu_common.c +++ b/drivers/video/ipu_common.c @@ -352,7 +352,7 @@ static int ipu_pixel_clk_set_rate(struct clk *clk, unsigned long rate) */ __raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id)); - clk->rate = (u64)(clk->parent->rate * 16) / div; + clk->rate = lldiv((u64)clk->parent->rate * 16, div); return 0; } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/11] ARM: PSCI: change PSCI function IDs base and offsets
On Thu, May 19, 2016 at 4:40 PM, Hongbo Zhang wrote: > On Wed, May 18, 2016 at 5:19 PM, Chen-Yu Tsai wrote: >> Hi, >> >> On Wed, May 18, 2016 at 5:10 PM, wrote: >>> From: Wang Dongsheng >>> >>> According to PSCI specification v1.0, the PSCI functions should start from >>> 0x8400 for SMC32, this patch changes this base value as well as other >>> function offset values. >> >> I think you should squash this into the PSCI v1.0 skeleton patch. Otherwise >> between these 2 patches, we get a function ID and version mismatch? >> >> ChenYu >> > > Thanks. > But there won't be the mismatch you mentioned, because in v0.1 the > function IDs are implementation defined, the can be set to any values, > here we just make a step forward to adapt legacy v0.1 function IDs > compatible with the coming v1.0. > > This patch is updating legacy ID definitions and the coming v1.0 > skeleton patch is to add new IDs, it is OK to separate them since > there won't be mismatch you pointed, what's more we've already gotten > the Reviewed-by: tag :) Great! Thanks for the explanation. I'm not that familiar with the PSCI spec myself. ChenYu >>> >>> Signed-off-by: Wang Dongsheng >>> Signed-off-by: Hongbo Zhang >>> --- >>> arch/arm/include/asm/psci.h | 10 +- >>> 1 file changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h >>> index 128a606..a4a19e3 100644 >>> --- a/arch/arm/include/asm/psci.h >>> +++ b/arch/arm/include/asm/psci.h >>> @@ -19,13 +19,13 @@ >>> #define __ARM_PSCI_H__ >>> >>> /* PSCI interface */ >>> -#define ARM_PSCI_FN_BASE 0x95c1ba5e >>> +#define ARM_PSCI_FN_BASE 0x8400 >>> #define ARM_PSCI_FN(n) (ARM_PSCI_FN_BASE + (n)) >>> >>> -#define ARM_PSCI_FN_CPU_SUSPENDARM_PSCI_FN(0) >>> -#define ARM_PSCI_FN_CPU_OFFARM_PSCI_FN(1) >>> -#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(2) >>> -#define ARM_PSCI_FN_MIGRATEARM_PSCI_FN(3) >>> +#define ARM_PSCI_FN_CPU_SUSPENDARM_PSCI_FN(1) >>> +#define ARM_PSCI_FN_CPU_OFFARM_PSCI_FN(2) >>> +#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(3) >>> +#define ARM_PSCI_FN_MIGRATEARM_PSCI_FN(5) >>> >>> #define ARM_PSCI_RET_SUCCESS 0 >>> #define ARM_PSCI_RET_NI(-1) >>> -- >>> 2.1.4 >>> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools/env: check that redundant environments have equal size
For double buffering to work, the target buffer must always be big
enough to hold all data. This can only be ensured if buffers are of
equal size, otherwise one must be smaller and we risk data loss
when copying from the bigger to the smaller.
Signed-off-by: Andreas Fenkart
---
tools/env/fw_env.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 06cf63d..60a7394 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1373,12 +1373,21 @@ static int parse_config ()
return -1;
}
- if (HaveRedundEnv && stat (DEVNAME (1), &st)) {
- fprintf (stderr,
- "Cannot access MTD device %s: %s\n",
- DEVNAME (1), strerror (errno));
- return -1;
+ if (HaveRedundEnv) {
+ if (stat(DEVNAME(1), &st)) {
+ fprintf(stderr,
+ "Cannot access MTD device %s: %s\n",
+ DEVNAME(1), strerror(errno));
+ return -1;
+ }
+
+ if (ENVSIZE(0) != ENVSIZE(1)) {
+ fprintf(stderr,
+ "Redundant environments are not of equal size");
+ return -1;
+ }
}
+
return 0;
}
--
2.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] spl: Add an option to load a FIT containing U-Boot from UART
This provides a way to load a FIT containing U-Boot and a selection of device
tree files from UART.
Signed-off-by: Lokesh Vutla
---
common/spl/spl_ymodem.c | 91 +++--
1 file changed, 80 insertions(+), 11 deletions(-)
diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 380d8dd..d7f8c92 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -14,15 +14,60 @@
#include
#include
#include
+#include
#define BUF_SIZE 1024
+/*
+ * Information required to load image using ymodem.
+ *
+ * @image_read: Now of bytes read from the image.
+ * @buf: pointer to the previous read block.
+ */
+struct ymodem_fit_info {
+ int image_read;
+ char *buf;
+};
+
static int getcymodem(void) {
if (tstc())
return (getc());
return -1;
}
+static ulong ymodem_read_fit(struct spl_load_info *load, ulong offset,
+ulong size, void *addr)
+{
+ int res, err;
+ struct ymodem_fit_info *info = load->priv;
+ char *buf = info->buf;
+
+ while (info->image_read < offset) {
+ res = xyzModem_stream_read(buf, BUF_SIZE, &err);
+ if (res <= 0)
+ return res;
+ info->image_read += res;
+ }
+
+ if (info->image_read > offset) {
+ res = info->image_read - offset;
+ memcpy(addr, &buf[BUF_SIZE - res], res);
+ addr = addr + res;
+ }
+
+ while (info->image_read < offset + size) {
+ res = xyzModem_stream_read(buf, BUF_SIZE, &err);
+ if (res <= 0)
+ return res;
+
+ memcpy(addr, buf, res);
+ info->image_read += res;
+ addr += res;
+ }
+
+ return size;
+}
+
int spl_ymodem_load_image(void)
{
int size = 0;
@@ -31,27 +76,51 @@ int spl_ymodem_load_image(void)
int ret;
connection_info_t info;
char buf[BUF_SIZE];
- ulong store_addr = ~0;
ulong addr = 0;
info.mode = xyzModem_ymodem;
ret = xyzModem_stream_open(&info, &err);
+ if (ret) {
+ printf("spl: ymodem err - %s\n", xyzModem_error(err));
+ return ret;
+ }
+
+ res = xyzModem_stream_read(buf, BUF_SIZE, &err);
+ if (res <= 0)
+ goto end_stream;
+
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+ image_get_magic((struct image_header *)buf) == FDT_MAGIC) {
+ struct spl_load_info load;
+ struct ymodem_fit_info info;
+
+ debug("Found FIT\n");
+ load.dev = NULL;
+ load.priv = (void *)&info;
+ load.bl_len = 1;
+ info.buf = buf;
+ info.image_read = BUF_SIZE;
+ load.read = ymodem_read_fit;
+ ret = spl_load_simple_fit(&load, 0, (void *)buf);
+ size = info.image_read;
- if (!ret) {
- while ((res =
- xyzModem_stream_read(buf, BUF_SIZE, &err)) > 0) {
- if (addr == 0)
- spl_parse_image_header((struct image_header
*)buf);
- store_addr = addr + spl_image.load_addr;
+ while ((res = xyzModem_stream_read(buf, BUF_SIZE, &err)) > 0)
+ size += res;
+ } else {
+ spl_parse_image_header((struct image_header *)buf);
+ addr = spl_image.load_addr;
+ memcpy((void *)addr, buf, res);
+ size += res;
+ addr += res;
+
+ while ((res = xyzModem_stream_read(buf, BUF_SIZE, &err)) > 0) {
+ memcpy((void *)addr, buf, res);
size += res;
addr += res;
- memcpy((char *)(store_addr), buf, res);
}
- } else {
- printf("spl: ymodem err - %s\n", xyzModem_error(err));
- return ret;
}
+end_stream:
xyzModem_stream_close(&err);
xyzModem_stream_terminate(false, &getcymodem);
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] spl: fit: Do not print selected dtb during fit load
Uart boot is failing when a printf is called while loading image. So, disable
prints while loading FIT image.
Signed-off-by: Lokesh Vutla
---
common/spl/spl_fit.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ace2543..a0ea44c 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -62,9 +62,7 @@ static int spl_fit_select_fdt(const void *fdt, int images,
int *fdt_offsetp)
*fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
len = fdt_getprop_u32(fdt, fdt_node, "data-size");
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
- printf("FIT: Selected '%s'\n", name);
-#endif
+ debug("FIT: Selected '%s'\n", name);
return len;
}
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] spl: fit: Detect a FS load using filename
Right now a FS load for fit is being detected using the priv field. But
this can be used by others media. So, introduce a filename field to
detect a FS load.
Signed-off-by: Lokesh Vutla
---
common/spl/spl_fat.c | 4 ++--
common/spl/spl_fit.c | 6 +++---
include/spl.h| 2 ++
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
index cdb9811..9df2fc2 100644
--- a/common/spl/spl_fat.c
+++ b/common/spl/spl_fat.c
@@ -45,7 +45,7 @@ static ulong spl_fit_read(struct spl_load_info *load, ulong
file_offset,
{
loff_t actread;
int ret;
- char *filename = (char *)load->priv;
+ const char *filename = load->filename;
ret = fat_read_file(filename, buf, file_offset, size, &actread);
if (ret)
@@ -79,7 +79,7 @@ int spl_load_image_fat(struct blk_desc *block_dev,
debug("Found FIT\n");
load.read = spl_fit_read;
load.bl_len = 1;
- load.priv = (void *)filename;
+ load.filename = filename;
return spl_load_simple_fit(&load, 0, header);
} else {
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a0ea44c..78ce15f 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -87,7 +87,7 @@ static int get_aligned_image_offset(struct spl_load_info
*info, int offset)
* aligned to ARCH_DMA_MINALIGN. If it is raw read return the
* block number to which offset belongs.
*/
- if (info->priv)
+ if (info->filename)
return offset & ~(ARCH_DMA_MINALIGN - 1);
return offset / info->bl_len;
@@ -101,7 +101,7 @@ static int get_aligned_image_overhead(struct spl_load_info
*info, int offset)
* ARCH_DMA_MINALIGN. If it is raw read return the offset within the
* block.
*/
- if (info->priv)
+ if (info->filename)
return offset & (ARCH_DMA_MINALIGN - 1);
return offset % info->bl_len;
@@ -110,7 +110,7 @@ static int get_aligned_image_overhead(struct spl_load_info
*info, int offset)
static int get_aligned_image_size(struct spl_load_info *info, int data_size,
int offset)
{
- if (info->priv)
+ if (info->filename)
return data_size + get_aligned_image_overhead(info, offset);
return (data_size + info->bl_len - 1) / info->bl_len;
diff --git a/include/spl.h b/include/spl.h
index 358e81b..af02a6d 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -35,12 +35,14 @@ struct spl_image_info {
* @dev: Pointer to the device, e.g. struct mmc *
* @priv: Private data for the device
* @bl_len: Block length for reading in bytes
+ * @filename: Name of the fit image file.
* @read: Function to call to read from the device
*/
struct spl_load_info {
void *dev;
void *priv;
int bl_len;
+ const char *filename;
ulong (*read)(struct spl_load_info *load, ulong sector, ulong count,
void *buf);
};
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] spl: fit: Allow to load FIT using UART boot
This series allows to load a FIT image using UART boot mode. Tested: BBB: http://pastebin.ubuntu.com/16505294/ Lokesh Vutla (3): spl: fit: Do not print selected dtb during fit load spl: fit: Detect a FS load using filename spl: Add an option to load a FIT containing U-Boot from UART common/spl/spl_fat.c| 4 +-- common/spl/spl_fit.c| 10 +++--- common/spl/spl_ymodem.c | 91 +++-- include/spl.h | 2 ++ 4 files changed, 88 insertions(+), 19 deletions(-) -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: ipu: Fix build with hard-float ARM toolchain
Hi Guillaume, On 19/05/2016 09:40, Guillaume Gardet wrote: > > > Le 19/05/2016 03:09, Peng Fan a écrit : >> Hi Guillaume, >> >> On Wed, May 18, 2016 at 02:19:43PM +0200, Guillaume GARDET wrote: >>> Build with hard-float ARM toolchain was broken by commit 3cb4f25c: >>> 'video: ipu: avoid overflow issue'. >>> To fix it, we use do_div function. >>> >>> Build tested for mx6qsabrelite_defconfig. >>> >>> Signed-off-by: Guillaume GARDET >>> Cc: Peng Fan >>> Cc: Sandor Yu >>> Cc: Anatolij Gustschin >>> Cc: Stefano Babic >>> Cc: Fabio Estevam >>> Cc: Tom Rini >>> >>> --- >>> drivers/video/ipu_common.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c >>> index 36d4b23..e319c82 100644 >>> --- a/drivers/video/ipu_common.c >>> +++ b/drivers/video/ipu_common.c >>> @@ -352,7 +352,8 @@ static int ipu_pixel_clk_set_rate(struct clk >>> *clk, unsigned long rate) >>> */ >>> __raw_writel((div / 16) << 16, DI_BS_CLKGEN1(clk->id)); >>> >>> -clk->rate = (u64)(clk->parent->rate * 16) / div; >>> +do_div(parent_rate, div); >>> +clk->rate = parent_rate; >> This issue was already fixed,. >> http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commitdiff;h=c510f2e436008e55a50b063f2180cb1e63984224 >> > > Ok. Sorry, I did not checked u-boot-imx git repo. > Do you know why it was not included in the v2016.05 release? No reason, it was simply missed :-( Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] should more use be made of "CONFIG_IS_ENABLED()" macro?
two questions.
first, was perusing include/image.h, familiar with snippets like
this:
#define IMAGE_ENABLE_FITCONFIG_IS_ENABLED(FIT)
#define IMAGE_ENABLE_OF_LIBFDT CONFIG_IS_ENABLED(OF_LIBFDT)
but further down the same file, seems like more content could be
rewritten that way:
#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
# define IMAGE_ENABLE_RAMDISK_HIGH 1
#else
# define IMAGE_ENABLE_RAMDISK_HIGH 0
#endif
#ifdef CONFIG_SYS_BOOT_GET_CMDLINE
# define IMAGE_BOOT_GET_CMDLINE 1
#else
# define IMAGE_BOOT_GET_CMDLINE 0
#endif
... etc etc ...
isn't that amenable to the same rewriting?
and, second, from include/linux/kconfig.h, what is the difference
between IS_ENABLED() and CONFIG_IS_ENABLED():
/*
* IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
* 0 otherwise.
*
*/
#define IS_ENABLED(option) \
(config_enabled(option) || config_enabled(option##_MODULE))
... snip ...
/*
* CONFIG_IS_ENABLED(FOO) evaluates to
* 1 if CONFIG_SPL_BUILD is undefined and CONFIG_FOO is set to 'y' or 'm',
* 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y' or 'm',
* 0 otherwise.
*/
#define CONFIG_IS_ENABLED(option) \
(config_enabled(CONFIG_VAL(option)) || \
config_enabled(CONFIG_VAL(option##_MODULE)))
i'm sure if i kept reading, i'd understand the difference, but the
comment above that second #define doesn't seem to clarify it, since it
refers to "CONFIG_SPL_*" while the definition mentions nothing about
SPL. perhaps a more expansive comment would make things clearer in
terms of where to use one rather than the other.
rday
p.s. there is some potentially confusing usage of that macro, like
this within the same source file drivers/core/device.c:
$ grep -r IS_ENABLED drivers/core/device.c
if (CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(DM_SEQ_ALIAS)) {
if (CONFIG_IS_ENABLED(DM_DEVICE_REMOVE)) {
if (CONFIG_IS_ENABLED(DM_DEVICE_REMOVE)) {
if (CONFIG_IS_ENABLED(DM_DEVICE_REMOVE)) {
#if CONFIG_IS_ENABLED(OF_CONTROL)
if (CONFIG_IS_ENABLED(OF_TRANSLATE)) {
if (CONFIG_IS_ENABLED(SIMPLE_BUS) && addr != FDT_ADDR_T_NONE) {
#if CONFIG_IS_ENABLED(OF_CONTROL)
$
so within the same source file, CONFIG_IS_ENABLED() is being used
for both compile-time *and* run-time testing. um, yuck. IMHO, the
compile-time testing should use the standard test of:
#ifdef CONFIG_OF_CONTROL
for consistency. it just seems messy to be bouncing back and forth
between the two usages.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 14/14] config: sandbox: enable qfw and cmd_qfw for testing
Hi Miao, On Wed, May 18, 2016 at 5:40 PM, Miao Yan wrote: > This patch enables qfw and cmd_qfw on sandbox for build coverage test > > Signed-off-by: Miao Yan > --- > configs/sandbox_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig > index afdf4a3..f19308d 100644 > --- a/configs/sandbox_defconfig > +++ b/configs/sandbox_defconfig > @@ -167,3 +167,5 @@ CONFIG_UNIT_TEST=y > CONFIG_UT_TIME=y > CONFIG_UT_DM=y > CONFIG_UT_ENV=y > +CONFIG_QFW=y > +CONFIG_CMD_QFW=y > -- Please do a 'make savedefconfig' and check the Kconfig options. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 12/14] x86: qemu: rename qemu/acpi_table.c
On Wed, May 18, 2016 at 5:39 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 => e820.c} | 0
> 2 files changed, 1 insertion(+), 2 deletions(-)
> rename arch/x86/cpu/qemu/{acpi_table.c => e820.c} (100%)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 11/14] cmd: qfw: bring ACPI generation code into qfw core
On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote: > Loading ACPI table from QEMU's fw_cfg interface is not x86 specific > (ARM64 may also make use of it). So move the code to common place. > > Signed-off-by: Miao Yan > Reviewed-by: Bin Meng > --- > arch/x86/cpu/qemu/acpi_table.c | 209 > - > drivers/misc/qfw.c | 206 > 2 files changed, 206 insertions(+), 209 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 08/14] cmd: qfw: rename qemu_fw_cfg.[c|h] to qfw.[c|h]
On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote:
> Make file names aligned with CONFIG_QFW
>
> Signed-off-by: Miao Yan
> ---
> arch/x86/cpu/mp_init.c| 2 +-
> arch/x86/cpu/qemu/acpi_table.c| 2 +-
> arch/x86/cpu/qemu/cpu.c | 2 +-
> arch/x86/cpu/qemu/qemu.c | 2 +-
> cmd/qfw.c | 2 +-
> drivers/misc/Makefile | 2 +-
> drivers/misc/{qemu_fw_cfg.c => qfw.c} | 2 +-
> include/{qemu_fw_cfg.h => qfw.h} | 0
> 8 files changed, 7 insertions(+), 7 deletions(-)
> rename drivers/misc/{qemu_fw_cfg.c => qfw.c} (99%)
> rename include/{qemu_fw_cfg.h => qfw.h} (100%)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 13/14] cmd: qfw: rename QEMU_FW_CFG to CMD_QFW
Hi Miao, the title should say: CMD_QEMU_FW_CFG I can fix this when applying. On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote: > Align macro names with the rest of qfw code > and I believe it's better to squash this commit into patch#8 in this series, as they both rename QEMU_FW_CFG to QFW. > Signed-off-by: Miao Yan > --- > cmd/Kconfig| 2 +- > cmd/Makefile | 2 +- > configs/qemu-x86_defconfig | 2 +- > drivers/misc/Kconfig | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/11] ARM: PSCI: change PSCI function IDs base and offsets
Hi, On 19/05/16 09:45, Hongbo Zhang wrote: > On Wed, May 18, 2016 at 6:07 PM, Andre Przywara > wrote: >> Hi, >> >> On 18/05/16 10:10, macro.wav...@gmail.com wrote: >>> From: Wang Dongsheng >>> >>> According to PSCI specification v1.0, the PSCI functions should start from >>> 0x8400 for SMC32, this patch changes this base value as well as other >>> function offset values. >> >> Out of curiosity: Do you plan to ever support ARMv8 boards with PSCI >> services in U-Boot as well? >> Then we would need to think about adjusting the function IDs, because >> they use a "64-bit" flag for some functions. >> > My workmate Hongtao Jia is working for ARMv8 PSCI. > That should be in another separate file, so same or different function > names can both be used freely I think. OK, let's see how this looks like. The offsets are the same, the prefix is different, but not for every function - only for those that carry a register-sized argument (CPU_OFF uses the 32-bit prefix, CPU_ON the 64-bit one, for instance). That's why I was asking how we address this without duplicating everything. But we can discuss this in the ARMv8 support thread. Cheers, Andre. > >>> Signed-off-by: Wang Dongsheng >>> Signed-off-by: Hongbo Zhang >> >> Otherwise: >> Reviewed-by: Andre Przywara >> > Thanks for review. > >>> --- >>> arch/arm/include/asm/psci.h | 10 +- >>> 1 file changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h >>> index 128a606..a4a19e3 100644 >>> --- a/arch/arm/include/asm/psci.h >>> +++ b/arch/arm/include/asm/psci.h >>> @@ -19,13 +19,13 @@ >>> #define __ARM_PSCI_H__ >>> >>> /* PSCI interface */ >>> -#define ARM_PSCI_FN_BASE 0x95c1ba5e >>> +#define ARM_PSCI_FN_BASE 0x8400 >>> #define ARM_PSCI_FN(n) (ARM_PSCI_FN_BASE + (n)) >>> >>> -#define ARM_PSCI_FN_CPU_SUSPEND ARM_PSCI_FN(0) >>> -#define ARM_PSCI_FN_CPU_OFF ARM_PSCI_FN(1) >>> -#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(2) >>> -#define ARM_PSCI_FN_MIGRATE ARM_PSCI_FN(3) >>> +#define ARM_PSCI_FN_CPU_SUSPEND ARM_PSCI_FN(1) >>> +#define ARM_PSCI_FN_CPU_OFF ARM_PSCI_FN(2) >>> +#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(3) >>> +#define ARM_PSCI_FN_MIGRATE ARM_PSCI_FN(5) >>> >>> #define ARM_PSCI_RET_SUCCESS 0 >>> #define ARM_PSCI_RET_NI (-1) >>> > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 05/14] x86: qemu: split qfw command interface and qfw core
On Wed, May 18, 2016 at 5:39 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
nits: . should be removed
I can fix when applying
> 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
> ---
> Changes in v2:
> - do not use #ifdef...#end when including header files
> - cleanup blank line at the end of file
> - rename cmd_qfw.c to qfw.c
>
> arch/x86/Kconfig | 2 +-
> arch/x86/cpu/mp_init.c | 4 +-
> arch/x86/cpu/qemu/Makefile | 3 +-
> arch/x86/cpu/qemu/qemu.c | 2 +
> cmd/Kconfig | 1 +
> cmd/Makefile | 2 +-
> cmd/{qemu_fw_cfg.c => qfw.c} | 172
> drivers/misc/Kconfig | 6 ++
> drivers/misc/Makefile| 1 +
> drivers/misc/qemu_fw_cfg.c | 184
> +++
> 10 files changed, 200 insertions(+), 177 deletions(-)
> rename cmd/{qemu_fw_cfg.c => qfw.c} (55%)
> create mode 100644 drivers/misc/qemu_fw_cfg.c
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 03/14] cmd: qfw: remove qemu_fwcfg_free_files()
On Wed, May 18, 2016 at 5:39 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. > > Signed-off-by: Miao Yan > --- > arch/x86/cpu/qemu/acpi_table.c | 13 +++-- > cmd/qemu_fw_cfg.c | 12 > include/qemu_fw_cfg.h | 1 - > 3 files changed, 11 insertions(+), 15 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 01/14] x86: qemu: fix ACPI Kconfig options
On Wed, May 18, 2016 at 5:39 PM, Miao Yan wrote: > CONFIG_GENENRATE_ACPI_TABLE controls the generation of ACPI table which > uses U-Boot's built-in methods and CONFIG_QEMU_ACPI_TABLE controls whether > to load ACPI table from QEMU's fw_cfg interface. > > But with commit "697ec431469ce0a4c2fc2c02d8685d907491af84 x86: qemu: Drop > our own ACPI implementation", there is only one way to support ACPI table > for QEMU targets which is the fw_cfg interface. Having two Kconfig options > for this purpose is not necessary any more, so this patch consolidates > the two. > > Signed-off-by: Miao Yan > --- > Changes in v2: > - fix a wrong macro name > > arch/x86/Kconfig | 10 +- > arch/x86/cpu/qemu/Makefile | 2 +- > arch/x86/lib/Makefile | 2 +- > 3 files changed, 3 insertions(+), 11 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 05/19/2016 10:26 AM, 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 --- Changes in v2: - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used to switch to AArch64 EL2 or AArch32 Hyp. - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used to switch to AArch64 EL1 or AArch32 SVC. arch/arm/cpu/armv8/transition.S | 8 ++--- arch/arm/include/asm/macro.h| 80 + arch/arm/include/asm/system.h | 25 +++-- arch/arm/lib/bootm.c| 26 +++--- common/image-fit.c | 12 ++- 5 files changed, 133 insertions(+), 18 deletions(-) diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index 253a39b..9fa3b59 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -11,13 +11,13 @@ #include ENTRY(armv8_switch_to_el2) - switch_el x0, 1f, 0f, 0f + switch_el x4, 1f, 0f, 0f 0:ret -1: armv8_switch_to_el2_m x0 +1: armv8_switch_to_el2_m x0, x1, x2, x3, x4, x5, x6 ENDPROC(armv8_switch_to_el2) ENTRY(armv8_switch_to_el1) - switch_el x0, 0f, 1f, 0f + switch_el x4, 0f, 1f, 0f 0:ret -1: armv8_switch_to_el1_m x0, x1 +1: armv8_switch_to_el1_m x0, x1, x2, x3, x4, x5, x6 ENDPROC(armv8_switch_to_el1) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 9bb0efa..56d77f6 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -8,6 +8,9 @@ #ifndef __ASM_ARM_MACRO_H__ #define __ASM_ARM_MACRO_H__ + +#include + #ifdef __ASSEMBLY__ /* @@ -135,9 +138,20 @@ lr .reqx30 #endif .endm -.macro armv8_switch_to_el2_m, xreg1 - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */ - mov \xreg1, #0x5b1 +.macro armv8_switch_to_el2_m, xreg1, xreg2, xreg3, xreg4, xreg5, xreg6, xreg7 These arguments should probably get documented :). Also xreg4 doesn't seem to actually be a scratch register, but a real parameter. So please name it accordingly. + mov \xreg5, \xreg1 + mov \xreg6, \xreg2 + mov \xreg7, \xreg3 + + /* +* If the next lower exception level is AArch64, 64bit EL2 | HCE | SMD | +* RES1 (Bits[5:4]) | Non-secure EL0/EL1. If the next lower exception +* level is AArch32, 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | +* Non-secure EL0/EL1. +*/ + mov \xreg1, #0x1b1 + lsl \xreg2, \xreg4, #10 + orr \xreg1, \xreg1, \xreg2 Is there any way you can make this obvious from the code? Basically we would want something like mov \xreg1, #(SCR_EL3_EL2_AA64 | SCR_EL3_HCE | SCR_EL3_SMD ...) I'm sure there are creative ways to achieve this even with the high bits set. Maybe ldr = works? msr scr_el3, \xreg1 msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ mov \xreg1, #0x33ff @@ -156,18 +170,46 @@ lr.reqx30 movk\xreg1, #0x30C5, lsl #16 msr sctlr_el2, \xreg1 - /* Return to the EL2_SP2 mode from EL3 */ mov \xreg1, sp msr sp_el2, \xreg1 /* Migrate SP */ mrs \xreg1, vbar_el3 msr vbar_el2, \xreg1/* Migrate VBAR */ + + /* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */ + ldr \xreg1, =ES_TO_AARCH64 + cmp \xreg4, \xreg1 + b.eq1f + b.ne2f Just b.ne should be enough, no? + +1: + /* Return to the EL2_SP2 mode from EL3 */ mov \xreg1, #0x3c9 Magic values again :). Please convert them to constants getting ORed. msr spsr_el3, \xreg1/* EL2_SP2 | D | A | I | F */ msr elr_el3, lr + + mov \xreg1, \xreg5 + mov \xreg2, \xreg6 + mov \xreg3, \xreg7 + eret + +2: + /* Return to AArch32 Hypervisor mode */ + mov \xreg1, #0x1da + msr spsr_el3, \xreg1/* Hyp | D | A | I | F */ + msr elr_el3, \xreg5 + + mov \xreg1, #0 + mov \xreg2, \xreg6 + mov \xreg3, \xreg7 eret + .endm -.macro armv8_switch_to_el1_m, xreg1, xreg2 +.macro armv8_switch_to_el1_m, xreg1, xreg2, xreg3, xreg4, xreg5, xreg6, xreg7 + mov \xreg5, \xreg1 + mov \xreg6, \xreg2 + mov \xreg7, \xreg3 + /* Initialize Generic Timers */ mrs \xreg1, cnthctl_el2 orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */ @@ -188,7 +230,7 @@ lr .reqx30 msr cpacr_el1, \xreg1 /* Enable FP/SIMD at EL1 */ /*
[U-Boot] Ethernet on Colombus (sun6i-a31-colombus)
Hi, I put U-Boot for the Colombus on an SD Card but could not make Ethernet work. In U-Boot v2015.10, v2016.01 and v2016.05, Ethernet port is not detected. In U-Boot v2016.03, the Ethernet port is detected but cannot be used. I get the following error: => dhcp ethernet@01c3 Waiting for PHY auto negotiation to complete. TIMEOUT ! ethernet@01c3: No link. Thank you, Quentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] armv8: fsl-layerscape: SMP support for loading 32-bit OS
Spin-table method is used for secondary cores to load 32-bit OS. The
architecture information will be got through checking FIT image and
saved in the os_arch element of spin-table, then the secondary cores
will check os_arch and jump to 32-bit OS or 64-bit OS automatically.
Signed-off-by: Alison Wang
Signed-off-by: Chenhui Zhao
---
Changes in v2:
- Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.
arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 35 ---
arch/arm/cpu/armv8/fsl-layerscape/mp.c| 10
arch/arm/include/asm/arch-fsl-layerscape/mp.h | 6 +
arch/arm/lib/bootm.c | 5
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 04831ca..9dba16c 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -13,6 +13,8 @@
#ifdef CONFIG_MP
#include
#endif
+#include
+#include
ENTRY(lowlevel_init)
mov x29, lr /* Save LR */
@@ -320,6 +322,12 @@ ENTRY(secondary_boot_func)
gic_wait_for_interrupt_m x0, w1
#endif
+ ldr x5, [x11, #24]
+ ldr x6, =IH_ARCH_DEFAULT
+ cmp x6, x5
+ b.neslave_cpu
+
+ ldr x3, =ES_TO_AARCH64
bl secondary_switch_to_el2
#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
bl secondary_switch_to_el1
@@ -337,19 +345,38 @@ slave_cpu:
tbz x1, #25, cpu_is_le
rev x0, x0 /* BE to LE conversion */
cpu_is_le:
+
+ ldr x5, [x11, #24]
+ ldr x6, =IH_ARCH_DEFAULT
+ cmp x6, x5
+ b.eq1f
+
+#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
+ ldr x3, =ES_TO_AARCH64
+ bl secondary_switch_to_el2
+ ldr x0, [x11]
+ ldr x3, =ES_TO_AARCH32
+ bl secondary_switch_to_el1
+#else
+ ldr x0, [x11]
+ ldr x3, =ES_TO_AARCH32
+ bl secondary_switch_to_el2
+#endif
+
+1:
br x0 /* branch to the given address */
ENDPROC(secondary_boot_func)
ENTRY(secondary_switch_to_el2)
- switch_el x0, 1f, 0f, 0f
+ switch_el x4, 1f, 0f, 0f
0: ret
-1: armv8_switch_to_el2_m x0
+1: armv8_switch_to_el2_m x0, x1, x2, x3, x4, x5, x6
ENDPROC(secondary_switch_to_el2)
ENTRY(secondary_switch_to_el1)
- switch_el x0, 0f, 1f, 0f
+ switch_el x4, 0f, 1f, 0f
0: ret
-1: armv8_switch_to_el1_m x0, x1
+1: armv8_switch_to_el1_m x0, x1, x2, x3, x4, x5, x6
ENDPROC(secondary_switch_to_el1)
/* Ensure that the literals used by the secondary boot code are
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index df7ffb8..dd91550 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -22,6 +22,16 @@ phys_addr_t determine_mp_bootpg(void)
return (phys_addr_t)&secondary_boot_code;
}
+void update_os_arch_secondary_cores(uint8_t os_arch)
+{
+ u64 *table = get_spin_tbl_addr();
+ int i;
+
+ for (i = 1; i < CONFIG_MAX_CPUS; i++)
+ table[i * WORDS_PER_SPIN_TABLE_ENTRY +
+ SPIN_TABLE_ELEM_OS_ARCH_IDX] = os_arch;
+}
+
int fsl_layerscape_wake_seconday_cores(void)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
index e46e076..55f0e0c 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
@@ -13,6 +13,7 @@
* uint64_t entry_addr;
* uint64_t status;
* uint64_t lpid;
+* uint64_t os_arch;
* };
* we pad this struct to 64 bytes so each entry is in its own cacheline
* the actual spin table is an array of these structures
@@ -20,6 +21,7 @@
#define SPIN_TABLE_ELEM_ENTRY_ADDR_IDX 0
#define SPIN_TABLE_ELEM_STATUS_IDX 1
#define SPIN_TABLE_ELEM_LPID_IDX 2
+#define SPIN_TABLE_ELEM_OS_ARCH_IDX3
#define WORDS_PER_SPIN_TABLE_ENTRY 8 /* pad to 64 bytes */
#define SPIN_TABLE_ELEM_SIZE 64
@@ -35,4 +37,8 @@ phys_addr_t determine_mp_bootpg(void);
void secondary_boot_func(void);
int is_core_online(u64 cpu_id);
#endif
+
+#define IH_ARCH_ARM2 /* ARM */
+#define IH_ARCH_ARM64 22 /* ARM64 */
+
#endif /* _FSL_LAYERSCAPE_MP_H */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index f6f685a..28027cc 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -268,6 +268,10 @@ bool armv7_boot_nonsec(void)
}
#endif
+__weak void update_os_arch_secondary_cores(uint8_t os_arch)
+{
+}
+
/* Subcommand: GO */
static void boot_jump_linux(bootm_headers_t *images, int flag)
{
@@ -286,6 +290,7 @@ static void boot_jump_linux(bootm_headers_t *images, int
flag)
announce_an
[U-Boot] [PATCH v2 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
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 --- Changes in v2: - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used to switch to AArch64 EL2 or AArch32 Hyp. - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used to switch to AArch64 EL1 or AArch32 SVC. arch/arm/cpu/armv8/transition.S | 8 ++--- arch/arm/include/asm/macro.h| 80 + arch/arm/include/asm/system.h | 25 +++-- arch/arm/lib/bootm.c| 26 +++--- common/image-fit.c | 12 ++- 5 files changed, 133 insertions(+), 18 deletions(-) diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index 253a39b..9fa3b59 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -11,13 +11,13 @@ #include ENTRY(armv8_switch_to_el2) - switch_el x0, 1f, 0f, 0f + switch_el x4, 1f, 0f, 0f 0: ret -1: armv8_switch_to_el2_m x0 +1: armv8_switch_to_el2_m x0, x1, x2, x3, x4, x5, x6 ENDPROC(armv8_switch_to_el2) ENTRY(armv8_switch_to_el1) - switch_el x0, 0f, 1f, 0f + switch_el x4, 0f, 1f, 0f 0: ret -1: armv8_switch_to_el1_m x0, x1 +1: armv8_switch_to_el1_m x0, x1, x2, x3, x4, x5, x6 ENDPROC(armv8_switch_to_el1) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 9bb0efa..56d77f6 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -8,6 +8,9 @@ #ifndef __ASM_ARM_MACRO_H__ #define __ASM_ARM_MACRO_H__ + +#include + #ifdef __ASSEMBLY__ /* @@ -135,9 +138,20 @@ lr .reqx30 #endif .endm -.macro armv8_switch_to_el2_m, xreg1 - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */ - mov \xreg1, #0x5b1 +.macro armv8_switch_to_el2_m, xreg1, xreg2, xreg3, xreg4, xreg5, xreg6, xreg7 + mov \xreg5, \xreg1 + mov \xreg6, \xreg2 + mov \xreg7, \xreg3 + + /* +* If the next lower exception level is AArch64, 64bit EL2 | HCE | SMD | +* RES1 (Bits[5:4]) | Non-secure EL0/EL1. If the next lower exception +* level is AArch32, 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | +* Non-secure EL0/EL1. +*/ + mov \xreg1, #0x1b1 + lsl \xreg2, \xreg4, #10 + orr \xreg1, \xreg1, \xreg2 msr scr_el3, \xreg1 msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ mov \xreg1, #0x33ff @@ -156,18 +170,46 @@ lr.reqx30 movk\xreg1, #0x30C5, lsl #16 msr sctlr_el2, \xreg1 - /* Return to the EL2_SP2 mode from EL3 */ mov \xreg1, sp msr sp_el2, \xreg1 /* Migrate SP */ mrs \xreg1, vbar_el3 msr vbar_el2, \xreg1/* Migrate VBAR */ + + /* Check switch to AArch64 EL2 or AArch32 Hypervisor mode */ + ldr \xreg1, =ES_TO_AARCH64 + cmp \xreg4, \xreg1 + b.eq1f + b.ne2f + +1: + /* Return to the EL2_SP2 mode from EL3 */ mov \xreg1, #0x3c9 msr spsr_el3, \xreg1/* EL2_SP2 | D | A | I | F */ msr elr_el3, lr + + mov \xreg1, \xreg5 + mov \xreg2, \xreg6 + mov \xreg3, \xreg7 + eret + +2: + /* Return to AArch32 Hypervisor mode */ + mov \xreg1, #0x1da + msr spsr_el3, \xreg1/* Hyp | D | A | I | F */ + msr elr_el3, \xreg5 + + mov \xreg1, #0 + mov \xreg2, \xreg6 + mov \xreg3, \xreg7 eret + .endm -.macro armv8_switch_to_el1_m, xreg1, xreg2 +.macro armv8_switch_to_el1_m, xreg1, xreg2, xreg3, xreg4, xreg5, xreg6, xreg7 + mov \xreg5, \xreg1 + mov \xreg6, \xreg2 + mov \xreg7, \xreg3 + /* Initialize Generic Timers */ mrs \xreg1, cnthctl_el2 orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */ @@ -188,7 +230,7 @@ lr .reqx30 msr cpacr_el1, \xreg1 /* Enable FP/SIMD at EL1 */ /* Initialize HCR_EL2 */ - mov \xreg1, #(1 << 31) /* 64bit EL1 */ + lsl \xreg1, \xreg4, #31 orr \xreg1, \xreg1, #(1 << 29) /* Disable HVC */ msr hcr_el2, \xreg1 @@ -203,15 +245,39 @@ lr.reqx30 movk\xreg1, #0x30d0, lsl #16 msr sctlr_el1, \xreg1 - /* Return to the EL1_SP1 mode from EL2 */ mov \xreg1, sp msr sp_el1, \xreg1 /* Migrate SP */ mrs \xreg1, vbar_el2 msr vbar_el1, \xreg1/* Migrate VBAR */ + + /* Check switch to AArch64 EL1 or AAr
Re: [U-Boot] [PATCH v3 01/11] ARM: PSCI: change PSCI function IDs base and offsets
On Wed, May 18, 2016 at 6:07 PM, Andre Przywara wrote: > Hi, > > On 18/05/16 10:10, macro.wav...@gmail.com wrote: >> From: Wang Dongsheng >> >> According to PSCI specification v1.0, the PSCI functions should start from >> 0x8400 for SMC32, this patch changes this base value as well as other >> function offset values. > > Out of curiosity: Do you plan to ever support ARMv8 boards with PSCI > services in U-Boot as well? > Then we would need to think about adjusting the function IDs, because > they use a "64-bit" flag for some functions. > My workmate Hongtao Jia is working for ARMv8 PSCI. That should be in another separate file, so same or different function names can both be used freely I think. >> Signed-off-by: Wang Dongsheng >> Signed-off-by: Hongbo Zhang > > Otherwise: > Reviewed-by: Andre Przywara > Thanks for review. >> --- >> arch/arm/include/asm/psci.h | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h >> index 128a606..a4a19e3 100644 >> --- a/arch/arm/include/asm/psci.h >> +++ b/arch/arm/include/asm/psci.h >> @@ -19,13 +19,13 @@ >> #define __ARM_PSCI_H__ >> >> /* PSCI interface */ >> -#define ARM_PSCI_FN_BASE 0x95c1ba5e >> +#define ARM_PSCI_FN_BASE 0x8400 >> #define ARM_PSCI_FN(n) (ARM_PSCI_FN_BASE + (n)) >> >> -#define ARM_PSCI_FN_CPU_SUSPEND ARM_PSCI_FN(0) >> -#define ARM_PSCI_FN_CPU_OFF ARM_PSCI_FN(1) >> -#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(2) >> -#define ARM_PSCI_FN_MIGRATE ARM_PSCI_FN(3) >> +#define ARM_PSCI_FN_CPU_SUSPEND ARM_PSCI_FN(1) >> +#define ARM_PSCI_FN_CPU_OFF ARM_PSCI_FN(2) >> +#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(3) >> +#define ARM_PSCI_FN_MIGRATE ARM_PSCI_FN(5) >> >> #define ARM_PSCI_RET_SUCCESS 0 >> #define ARM_PSCI_RET_NI (-1) >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/11] ARM: PSCI: change PSCI function IDs base and offsets
On Wed, May 18, 2016 at 5:19 PM, Chen-Yu Tsai wrote: > Hi, > > On Wed, May 18, 2016 at 5:10 PM, wrote: >> From: Wang Dongsheng >> >> According to PSCI specification v1.0, the PSCI functions should start from >> 0x8400 for SMC32, this patch changes this base value as well as other >> function offset values. > > I think you should squash this into the PSCI v1.0 skeleton patch. Otherwise > between these 2 patches, we get a function ID and version mismatch? > > ChenYu > Thanks. But there won't be the mismatch you mentioned, because in v0.1 the function IDs are implementation defined, the can be set to any values, here we just make a step forward to adapt legacy v0.1 function IDs compatible with the coming v1.0. This patch is updating legacy ID definitions and the coming v1.0 skeleton patch is to add new IDs, it is OK to separate them since there won't be mismatch you pointed, what's more we've already gotten the Reviewed-by: tag :) >> >> Signed-off-by: Wang Dongsheng >> Signed-off-by: Hongbo Zhang >> --- >> arch/arm/include/asm/psci.h | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h >> index 128a606..a4a19e3 100644 >> --- a/arch/arm/include/asm/psci.h >> +++ b/arch/arm/include/asm/psci.h >> @@ -19,13 +19,13 @@ >> #define __ARM_PSCI_H__ >> >> /* PSCI interface */ >> -#define ARM_PSCI_FN_BASE 0x95c1ba5e >> +#define ARM_PSCI_FN_BASE 0x8400 >> #define ARM_PSCI_FN(n) (ARM_PSCI_FN_BASE + (n)) >> >> -#define ARM_PSCI_FN_CPU_SUSPENDARM_PSCI_FN(0) >> -#define ARM_PSCI_FN_CPU_OFFARM_PSCI_FN(1) >> -#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(2) >> -#define ARM_PSCI_FN_MIGRATEARM_PSCI_FN(3) >> +#define ARM_PSCI_FN_CPU_SUSPENDARM_PSCI_FN(1) >> +#define ARM_PSCI_FN_CPU_OFFARM_PSCI_FN(2) >> +#define ARM_PSCI_FN_CPU_ON ARM_PSCI_FN(3) >> +#define ARM_PSCI_FN_MIGRATEARM_PSCI_FN(5) >> >> #define ARM_PSCI_RET_SUCCESS 0 >> #define ARM_PSCI_RET_NI(-1) >> -- >> 2.1.4 >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
