September 2015 - U-Boot

[U-Boot] [PATCH 1/3] dm: dts: ls1021a-twr: Enable DSPI2 on LS1021ATWR
by Yuan Yao 30 Sep '15

30 Sep '15

Erratum A-008022 has been fixed on LS1021A Rev2.0. So we can use DSPI2 now, this patch enable DSPI2 in dts for LS1021ATWR. Signed-off-by: Yuan Yao <yao.yuan(a)freescale.com> --- arch/arm/dts/ls1021a-twr.dts | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/arm/dts/ls1021a-twr.dts b/arch/arm/dts/ls1021a-twr.dts index 0e61c07..6ccd332 100644 --- a/arch/arm/dts/ls1021a-twr.dts +++ b/arch/arm/dts/ls1021a-twr.dts @@ -17,6 +17,7 @@ enet0_sgmii_phy = &sgmii_phy2; enet1_sgmii_phy = &sgmii_phy0; spi0 = &qspi; + spi1 = &dspi1; }; }; @@ -33,6 +34,21 @@ }; }; +&dspi1 { + bus-num = <0>; + status = "okay"; + + dspiflash: at26df081a@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "spi-flash"; + spi-max-frequency = <16000000>; + spi-cpol; + spi-cpha; + reg = <0>; + }; +}; + &i2c0 { status = "okay"; }; -- 2.1.0.27.g96db324

2 5

Re: [U-Boot] [PATCH v3 5/5] common: Enable fdt_support in SPL build
by Chin Liang See 30 Sep '15

30 Sep '15

Hi, > From: marex(a)denx.de > Sent: Friday, September 11, 2015 8:45 AM > To: Simon Glass > Cc: Chin Liang See; ZY - u-boot; Dinh Nguyen; Dinh Nguyen; ZY - sr; Vikas Manocha; Jagannadh Teki; ZY - pavel > Subject: Re: [PATCH v3 5/5] common: Enable fdt_support in SPL build > > On Friday, September 11, 2015 at 02:14:17 AM, Simon Glass wrote: > > Hi, > > > > On 10 September 2015 at 04:49, Marek Vasut <marex(a)denx.de> wrote: > > > On Thursday, September 10, 2015 at 07:02:16 AM, Chin Liang See wrote: > > >> Enable more device tree function support such as > > >> fdt_getprop_u32_default_node in SPL. > > >> > > >> Signed-off-by: Chin Liang See <clsee(a)altera.com> > > >> Cc: Dinh Nguyen <dinguyen(a)opensource.altera.com> > > >> Cc: Dinh Nguyen <dinh.linux(a)gmail.com> > > >> Cc: Marek Vasut <marex(a)denx.de> > > >> Cc: Stefan Roese <sr(a)denx.de> > > >> Cc: Vikas Manocha <vikas.manocha(a)st.com> > > >> Cc: Jagannadh Teki <jteki(a)openedev.com> > > >> Cc: Pavel Machek <pavel(a)denx.de> > > > > > > +CC Simon, I'm worried this might blow the size of all SPLs , which is > > > not the thing we'd like to see. > > > > > >> --- > > >> > > >> common/Makefile | 4 ++-- > > >> 1 files changed, 2 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/common/Makefile b/common/Makefile > > >> index 556fb07..9e059fe 100644 > > >> --- a/common/Makefile > > >> +++ b/common/Makefile > > >> @@ -97,7 +97,7 @@ obj-$(CONFIG_CMD_EXT4) += cmd_ext4.o > > >> > > >> obj-$(CONFIG_CMD_EXT2) += cmd_ext2.o > > >> obj-$(CONFIG_CMD_FAT) += cmd_fat.o > > >> obj-$(CONFIG_CMD_FDC) += cmd_fdc.o > > >> > > >> -obj-$(CONFIG_OF_LIBFDT) += cmd_fdt.o fdt_support.o > > >> +obj-$(CONFIG_OF_LIBFDT) += cmd_fdt.o > > >> > > >> obj-$(CONFIG_CMD_FITUPD) += cmd_fitupd.o > > >> obj-$(CONFIG_CMD_FLASH) += cmd_flash.o > > >> ifdef CONFIG_FPGA > > >> > > >> @@ -265,7 +265,7 @@ obj-y += malloc_simple.o > > >> > > >> endif > > >> obj-y += image.o > > >> obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o > > >> > > >> -obj-$(CONFIG_OF_LIBFDT) += image-fdt.o > > >> +obj-$(CONFIG_OF_LIBFDT) += image-fdt.o fdt_support.o > > >> > > >> obj-$(CONFIG_FIT) += image-fit.o > > >> obj-$(CONFIG_FIT_SIGNATURE) += image-sig.o > > >> obj-$(CONFIG_IO_TRACE) += iotrace.o > > >> > > >> -- > > >> 1.7.7.4 > > > > It might need a bit of work - here's a buildman run: > > > > 02: common: Enable fdt_support in SPL build > > powerpc: + P1022DS_36BIT_NAND T1024RDB_SPIFLASH > > P1010RDB-PA_SPIFLASH P1021RDB-PC_36BIT_NAND T2080QDS_SPIFLASH > > P1025RDB_SDCARD P2020RDB-PC_36BIT_SPIFLASH T1042RDB_PI_SPIFLASH > > P1010RDB-PA_36BIT_NAND P1010RDB-PB_SDCARD P2020RDB-PC_SPIFLASH > > P1020MBG-PC_36BIT_SDCARD P1024RDB_SPIFLASH T1042D4RDB_NAND > > T4240RDB_SDCARD P1010RDB-PB_36BIT_NAND P1022DS_36BIT_SDCARD > > T1024QDS_NAND P1021RDB-PC_SPIFLASH T1024RDB_NAND T1023RDB_SDCARD > > P1010RDB-PB_36BIT_SDCARD P1022DS_NAND P1020RDB-PC_36BIT_NAND > > P1020RDB-PC_SDCARD T1042RDB_PI_NAND P1020RDB-PD_SPIFLASH T2080RDB_NAND > > P1022DS_SDCARD P1020RDB-PC_36BIT_SPIFLASH T1042RDB_PI_SDCARD > > T2081QDS_NAND T4160QDS_SDCARD P1010RDB-PB_SPIFLASH T2080QDS_SDCARD > > P1020MBG-PC_SDCARD P1020RDB-PC_SPIFLASH T4240QDS_SDCARD > > P2020RDB-PC_36BIT_SDCARD T1040RDB_SDCARD P1021RDB-PC_SDCARD > > B4860QDS_NAND T2080RDB_SDCARD P1020RDB-PC_36BIT_SDCARD > > T1040D4RDB_SDCARD T1040D4RDB_SPIFLASH P1020RDB-PC_NAND T2080QDS_NAND > > T1023RDB_NAND P1020RDB-PD_NAND T1040D4RDB_NAND P1010RDB-PA_NAND > > T1040RDB_SPIFLASH P2020RDB-PC_SDCARD T2081QDS_SDCARD > > P1010RDB-PA_36BIT_SDCARD P1024RDB_NAND P1024RDB_SDCARD T4240QDS_NAND > > C29XPCIE_NAND B4420QDS_NAND P1021RDB-PC_36BIT_SPIFLASH > > P1025RDB_SPIFLASH T2081QDS_SPIFLASH T1040RDB_NAND P1010RDB-PA_SDCARD > > P1010RDB-PB_NAND T1024QDS_SDCARD T1024QDS_SPIFLASH P1021RDB-PC_NAND > > T1042D4RDB_SPIFLASH P1020UTM-PC_36BIT_SDCARD T4160QDS_NAND > > T2080RDB_SPIFLASH P1022DS_SPIFLASH T1042D4RDB_SDCARD > > P1021RDB-PC_36BIT_SDCARD P1020RDB-PD_SDCARD P1022DS_36BIT_SPIFLASH > > T1024RDB_SDCARD P1020UTM-PC_SDCARD P2020RDB-PC_36BIT_NAND > > P2020RDB-PC_NAND T1023RDB_SPIFLASH P1010RDB-PB_36BIT_SPIFLASH > > P1025RDB_NAND P1010RDB-PA_36BIT_SPIFLASH > > blackfin: (for 34/35 boards) all +16.0 rodata +16.0 > > x86: (for 9/9 boards) bss -14.2 rodata +14.2 > > aarch64: (for 13/13 boards) all +17.2 rodata +17.2 > > spl/u-boot-spl:all +151.4 spl/u-boot-spl:rodata +151.4 > > avr32: (for 4/4 boards) all +16.0 rodata +16.0 > > sandbox: (for 1/1 boards) all +16.0 rodata +16.0 > > m68k: (for 48/48 boards) all +11.7 text +11.7 > > powerpc: (for 412/416 boards) all +3.6 data +1.6 rodata +2.0 > > spl/u-boot-spl:all +5.8 spl/u-boot-spl:rodata +5.0 > > spl/u-boot-spl:text +0.8 > > sparc: (for 5/5 boards) all +32.0 data +16.0 text +16.0 > > sh: (for 21/22 boards) all +16.0 rodata +16.0 > > nios2: (for 1/1 boards) all +16.0 data +16.0 > > mips: (for 24/24 boards) all +20.0 bss +4.0 rodata +16.0 > > arm: (for 531/531 boards) all +17.7 bss +0.3 rodata +17.4 > > spl/u-boot-spl:all +69.0 spl/u-boot-spl:rodata +69.0 > > nds32: (for 1/1 boards) all +16.0 rodata +16.0 > > Just what I was worried about. > > > So there are some code size changes (which may not be a big deal at 15 > > -60 bytes) but it breaks lots of powerpc boards. > > > > Can we instead add CONFIG_SPL_OF_LIBFDT? > > What would be the difference between having CONFIG_OF_LIBFDT enabled in > SPL (which is the case now) and having CONFIG_SPL_OF_LIBFDT enabled ? > The naming seems a bit difficult to comprehend to me. Sorry for late reply as fully tight up with something. To minimize the impact, we can create fdtdec_get_uint32 in lib/fdtdec_common.c. Then we can drop this patch. Any thought? Thanks Chin Liang

2 2

Re: [U-Boot] [PATCH v3 1/5] spi: cadence_qspi: Ensure spi_calibration is run when sclk change
by Chin Liang See 30 Sep '15

30 Sep '15

Hi, On Wed, 2015-09-23 at 11:13 +0800, Chin Liang See wrote: > > From: marex(a)denx.de > Sent: Thursday, September 10, 2015 7:52 PM > To: Chin Liang See > Cc: ZY - u-boot; Dinh Nguyen; Dinh Nguyen; ZY - sr; Vikas Manocha; Jagannadh Teki; ZY - pavel > Subject: Re: [PATCH v3 1/5] spi: cadence_qspi: Ensure spi_calibration is run when sclk change > > On Thursday, September 10, 2015 at 07:01:12 AM, Chin Liang See wrote: > > Ensuring spi_calibration is run when there is a change of sclk > > frequency. This will ensure the qspi flash access works for high > > sclk frequency > > > > Signed-off-by: Chin Liang See <clsee(a)altera.com> > > Cc: Dinh Nguyen <dinguyen(a)opensource.altera.com> > > Cc: Dinh Nguyen <dinh.linux(a)gmail.com> > > Cc: Marek Vasut <marex(a)denx.de> > > Cc: Stefan Roese <sr(a)denx.de> > > Cc: Vikas Manocha <vikas.manocha(a)st.com> > > Cc: Jagannadh Teki <jteki(a)openedev.com> > > Cc: Pavel Machek <pavel(a)denx.de> > > Acked-by: Marek Vasut <marex(a)denx.de> > > Reviewed-by: Jagan Teki <jteki(a)openedev.com> > > --- > > Changes for v2 > > - remove frequency set before calibration > > - introducing previous_hz to store requested frequency > > - prevent calibration run when request same frequency > > --- > > drivers/spi/cadence_qspi.c | 20 ++++++++++++-------- > > drivers/spi/cadence_qspi.h | 1 + > > 2 files changed, 13 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c > > index 34a0f46..0e7450c 100644 > > --- a/drivers/spi/cadence_qspi.c > > +++ b/drivers/spi/cadence_qspi.c > > @@ -37,15 +37,18 @@ static int cadence_spi_write_speed(struct udevice *bus, > > uint hz) } > > > > /* Calibration sequence to determine the read data capture delay register > > */ -static int spi_calibration(struct udevice *bus) > > +static int spi_calibration(struct udevice *bus, uint hz) > > { > > - struct cadence_spi_platdata *plat = bus->platdata; > > struct cadence_spi_priv *priv = dev_get_priv(bus); > > void *base = priv->regbase; > > u8 opcode_rdid = 0x9F; > > unsigned int idcode = 0, temp = 0; > > int err = 0, i, range_lo = -1, range_hi = -1; > > > > + /* if calibrated frequency same as reqeusted, skip it */ > > + if (priv->qspi_calibrated_hz == hz) > > + return 0; > > Do you need this check ? I think you're doing the same check in > cadence_spi_set_speed() down below here, so this is redundant. Oh this is checked against calibrated value. It works together with the check of previous_hz. This is to cater the incident where the calibrated frequency = max frequency when requested frequency exceed the max frequency. Some examples as below Request 100MHz, Max 50MHz, run, calibrated 50MHz, previous 100MHz Request 100MHz, Max 50MHz, skip, calibrated 50MHz, previous 100MHz Request 90MHz, Max 50MHz, skip, calibrated 50MHz, previous 90MHz The check here will skip calibration for third incident. Hope that explains. Thanks Chin Liang > > > /* start with slowest clock (1 MHz) */ > > cadence_spi_write_speed(bus, 1000000); > > > > @@ -64,7 +67,7 @@ static int spi_calibration(struct udevice *bus) > > } > > > > /* use back the intended clock and find low range */ > > - cadence_spi_write_speed(bus, plat->max_hz); > > + cadence_spi_write_speed(bus, hz); > > for (i = 0; i < CQSPI_READ_CAPTURE_MAX_DELAY; i++) { > > /* Disable QSPI */ > > cadence_qspi_apb_controller_disable(base); > > @@ -111,7 +114,7 @@ static int spi_calibration(struct udevice *bus) > > (range_hi + range_lo) / 2, range_lo, range_hi); > > > > /* just to ensure we do once only when speed or chip select change */ > > - priv->qspi_calibrated_hz = plat->max_hz; > > + priv->qspi_calibrated_hz = hz; > > priv->qspi_calibrated_cs = spi_chip_select(bus); > > > > return 0; > > @@ -126,14 +129,15 @@ static int cadence_spi_set_speed(struct udevice *bus, > > uint hz) /* Disable QSPI */ > > cadence_qspi_apb_controller_disable(priv->regbase); > > > > - cadence_spi_write_speed(bus, hz); > > - > > /* Calibration required for different SCLK speed or chip select */ > > - if (priv->qspi_calibrated_hz != plat->max_hz || > > + if (priv->previous_hz != hz || > > priv->qspi_calibrated_cs != spi_chip_select(bus)) { > > This check here is what I'm referring to. > > > - err = spi_calibration(bus); > > + err = spi_calibration(bus, hz); > > if (err) > > return err; > > + > > + /* prevent calibration run when same as previous request */ > > + priv->previous_hz = hz; > > } > > > > /* Enable QSPI */ > > diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h > > index 98e57aa..2912e36 100644 > > --- a/drivers/spi/cadence_qspi.h > > +++ b/drivers/spi/cadence_qspi.h > > @@ -38,6 +38,7 @@ struct cadence_spi_priv { > > int qspi_is_init; > > unsigned int qspi_calibrated_hz; > > unsigned int qspi_calibrated_cs; > > + unsigned int previous_hz; > > }; > > > > /* Functions call declaration */ > > -- > > 1.7.7.4

2 2

[U-Boot] [PATCH 1/3] imx: cpu: move common chip revision id's
by Adrian Alonso 29 Sep '15

29 Sep '15

Move common chip revision id's to main cpu header file mx25 generic include cpu header for chip revision Signed-off-by: Adrian Alonso <aalonso(a)freescale.com> --- arch/arm/cpu/arm926ejs/mx25/generic.c | 1 + arch/arm/include/asm/arch-imx/cpu.h | 12 ++++++++++++ arch/arm/include/asm/arch-mx25/imx-regs.h | 4 ---- arch/arm/include/asm/arch-mx5/imx-regs.h | 11 ----------- arch/arm/include/asm/arch-mx6/imx-regs.h | 4 ---- 5 files changed, 13 insertions(+), 19 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c b/arch/arm/cpu/arm926ejs/mx25/generic.c index 8912098..0b1a8f4 100644 --- a/arch/arm/cpu/arm926ejs/mx25/generic.c +++ b/arch/arm/cpu/arm926ejs/mx25/generic.c @@ -13,6 +13,7 @@ #include <div64.h> #include <netdev.h> #include <asm/io.h> +#include <asm/arch-imx/cpu.h> #include <asm/arch/imx-regs.h> #include <asm/arch/clock.h> diff --git a/arch/arm/include/asm/arch-imx/cpu.h b/arch/arm/include/asm/arch-imx/cpu.h index 7e681e9..8a75902 100644 --- a/arch/arm/include/asm/arch-imx/cpu.h +++ b/arch/arm/include/asm/arch-imx/cpu.h @@ -27,6 +27,18 @@ #define MXC_SOC_MX6 0x60 #define MXC_SOC_MX7 0x70 +#define CHIP_REV_1_0 0x10 +#define CHIP_REV_1_1 0x11 +#define CHIP_REV_1_2 0x12 +#define CHIP_REV_1_5 0x15 +#define CHIP_REV_2_0 0x20 +#define CHIP_REV_2_5 0x25 +#define CHIP_REV_3_0 0x30 + +#define BOARD_REV_1_0 0x0 +#define BOARD_REV_2_0 0x1 +#define BOARD_VER_OFFSET 0x8 + #define CS0_128 0 #define CS0_64M_CS1_64M 1 #define CS0_64M_CS1_32M_CS2_32M 2 diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h b/arch/arm/include/asm/arch-mx25/imx-regs.h index 78c4e9b..1b00ed7 100644 --- a/arch/arm/include/asm/arch-mx25/imx-regs.h +++ b/arch/arm/include/asm/arch-mx25/imx-regs.h @@ -526,8 +526,4 @@ struct cspi_regs { IMX_CSPI2_BASE, \ IMX_CSPI3_BASE -#define CHIP_REV_1_0 0x10 -#define CHIP_REV_1_1 0x11 -#define CHIP_REV_1_2 0x12 - #endif /* _IMX_REGS_H */ diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h index 5f0e1e6..e73cc07 100644 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h @@ -291,17 +291,6 @@ #define DP_MFD_216 (4 - 1) #define DP_MFN_216 3 -#define CHIP_REV_1_0 0x10 -#define CHIP_REV_1_1 0x11 -#define CHIP_REV_2_0 0x20 -#define CHIP_REV_2_5 0x25 -#define CHIP_REV_3_0 0x30 - -#define BOARD_REV_1_0 0x0 -#define BOARD_REV_2_0 0x1 - -#define BOARD_VER_OFFSET 0x8 - #define IMX_IIM_BASE (IIM_BASE_ADDR) #if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__)) diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h b/arch/arm/include/asm/arch-mx6/imx-regs.h index 74512ac..6249b33 100644 --- a/arch/arm/include/asm/arch-mx6/imx-regs.h +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h @@ -325,10 +325,6 @@ #define WDOG3_BASE_ADDR (is_cpu_type(MXC_CPU_MX6UL) ? \ MX6UL_WDOG3_BASE_ADDR : MX6SX_WDOG3_BASE_ADDR) -#define CHIP_REV_1_0 0x10 -#define CHIP_REV_1_2 0x12 -#define CHIP_REV_1_5 0x15 -#define CHIP_REV_2_0 0x20 #if !(defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL)) #define IRAM_SIZE 0x00040000 #else -- 2.1.4

2 3

[U-Boot] [PATCH v3 00/13] sf: BAR/wait_ready logic updates
by Jagan Teki 29 Sep '15

29 Sep '15

BAR and spi_flash_cmd_wait_ready are updated to make more module to add new status checks. Hou Zhiqiang (1): sf: Add clear flag status register support Jagan Teki (12): spi: zynq_spi: Remove unneeded headers sf: Return bank_sel, if flash->bank_curr == bank_sel sf: Make BAR discovery, as spi_flash_read_bar sf: Optimize BAR write code sf: Make flash->flags use for generic usage sf: Update status reg check in spi_flash_cmd_wait_ready sf: Add FSR support to spi_flash_cmd_wait_ready sf: Add flash_read_reg support sf: Use flash_read_reg routine sf: Add flash_read support sf: Use flash_read routine in spi_flash_read_ops sf: Rename read register functions drivers/mtd/spi/sf.c | 46 ++++++++++ drivers/mtd/spi/sf_internal.h | 30 ++++--- drivers/mtd/spi/sf_ops.c | 199 ++++++++++++++++++------------------------ drivers/mtd/spi/sf_probe.c | 80 +++++++++-------- drivers/spi/zynq_spi.c | 6 +- include/spi_flash.h | 6 +- 6 files changed, 195 insertions(+), 172 deletions(-) -- 1.9.1

3 23

[U-Boot] [PATCH 00/11] vexpress64 FVP and Juno configuration updates
by Ryan Harkin 29 Sep '15

29 Sep '15

This patch series updates the default configuration of the vexpress64 FVP and Juno platforms to allow it to work on a variety of setups without modification by the user. [PATCH 01/11] vexpress64: fix checkpatch warnings [PATCH 02/11] vexpress64: Kconfig: tidy up [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 04/11] vexpress64: Kconfig: add CONFIG_SYS_BOOTM_LEN [PATCH 05/11] vexpress64: fvp dram: add DRAM configuration [PATCH 06/11] vexpress64: juno: add androidboot.hardware=juno [PATCH 07/11] common/armflash: add command to check if image exists [PATCH 08/11] common/armflash: load_image returns success or failure [PATCH 09/11] vexpress64: juno: add optional initrd [PATCH 10/11] vexpress64: juno: add alternate kernel and device tree [PATCH 11/11] vexpress64: juno: use /dev/sda2 Kconfig | 7 +++++++ arch/arm/Kconfig | 4 ++++ board/armltd/vexpress64/Kconfig | 18 ++---------------- common/cmd_armflash.c | 31 ++++++++++++++++++++++++++----- configs/vexpress_aemv8a_dram_defconfig | 19 +++++++++++++++++++ include/configs/vexpress_aemv8a.h | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++-------- 6 files changed, 109 insertions(+), 29 deletions(-)

4 22

[U-Boot] [PATCH 1/2] bitops: Add support for order_base_2()
by Fabio Estevam 29 Sep '15

29 Sep '15

From: Fabio Estevam <fabio.estevam(a)freescale.com> Add support for the order_base_2() macro from the Linux kernel. This is useful for the SPI NOR unlock function. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- arch/arm/include/asm/bitops.h | 56 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h index 9b78043..b9b6d21 100644 --- a/arch/arm/include/asm/bitops.h +++ b/arch/arm/include/asm/bitops.h @@ -108,6 +108,62 @@ static inline int __ilog2(unsigned int x) return generic_fls(x) - 1; } +static inline int fls64(__u64 x) +{ + if (x == 0) + return 0; + return generic_fls(x) + 1; +} + +static inline unsigned fls_long(unsigned long l) +{ + if (sizeof(l) == 4) + return generic_fls(l); + return fls64(l); +} + +/* + * round up to nearest power of two + */ +static inline __attribute__((const)) +unsigned long __roundup_pow_of_two(unsigned long n) +{ + return 1UL << fls_long(n - 1); +} + +/** + * roundup_pow_of_two - round the given value up to nearest power of two + * @n - parameter + * + * round the given value up to the nearest power of two + * - the result is undefined when n == 0 + * - this can be used to initialise global variables from constant data + */ +#define roundup_pow_of_two(n) \ +( \ + __builtin_constant_p(n) ? ( \ + (n == 1) ? 1 : \ + (1UL << (__ilog2((n) - 1) + 1)) \ + ) : \ + __roundup_pow_of_two(n) \ +) + +/** + * order_base_2 - calculate the (rounded up) base 2 order of the argument + * @n: parameter + * + * The first few values calculated by this routine: + * ob2(0) = 0 + * ob2(1) = 0 + * ob2(2) = 1 + * ob2(3) = 2 + * ob2(4) = 2 + * ob2(5) = 3 + * ... and so on. + */ + +#define order_base_2(n) __ilog2(roundup_pow_of_two(n)) + /* * ffz = Find First Zero in word. Undefined if no zero exists, * so code should check against ~0UL first.. -- 1.9.1

2 2

Re: [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
by Hannes Schmelzer 29 Sep '15

29 Sep '15

Hi Bin, works now well. Also the thing with bootvx and the bootline works fine. I will send some v2 of my patch today. many thanks and best regards, Hannes On 29.09.2015 04:46, Bin Meng wrote: > Hi Hannes, > > On Mon, Sep 28, 2015 at 8:01 PM, Bin Meng <bmeng.cn(a)gmail.com> wrote: >> Hi Hannes, >> >> On Mon, Sep 28, 2015 at 7:08 PM, Hannes Schmelzer >> <hannes(a)schmelzer.or.at> wrote: >>> Hi Bin, >>> >>> i am not able to apply your patch from >>> http://patchwork.ozlabs.org/patch/523289/ >>> to most current master. >>> >>> schmelzerh@hpm-debian ~/work/u-boot $ git am >>> U-Boot-v2-01-13-Reorder-defconfigs-with-savedefconfig.patch >>> Applying: Reorder defconfigs with 'savedefconfig' >>> error: patch failed: configs/e2220-1170_defconfig:9 >>> error: configs/e2220-1170_defconfig: patch does not apply >>> error: patch failed: configs/p2371-0000_defconfig:9 >>> error: configs/p2371-0000_defconfig: patch does not apply >>> error: patch failed: configs/p2571_defconfig:9 >>> error: configs/p2571_defconfig: patch does not apply >>> Patch failed at 0001 Reorder defconfigs with 'savedefconfig' >>> >>> maybe you've to rebase your working branch. >>> >> Sorry. Yes, I forgot to rebase. Will send a new patch soon. >> > The patch#1 has been merged into u-boot/master. Please apply patch > 2-13 on top of latest mainline in the series and have a try. > > Regards, > Bin > >

2 1

[U-Boot] Please pull u-boot-x86
by Simon Glass 29 Sep '15

29 Sep '15

Hi, A little bug fix, The following changes since commit 1f8836396de8215b7f460616926052b32597bb29: Prepare v2015.10-rc4 (2015-09-28 16:57:42 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to c1446ac6c11dab19490a552f16ab39df8d5b3de3: x86: chromebook_link: Expand early malloc() memory (2015-09-28 22:27:17 -0600) ---------------------------------------------------------------- Simon Glass (1): x86: chromebook_link: Expand early malloc() memory configs/chromebook_link_defconfig | 1 + 1 file changed, 1 insertion(+) Regards, Simon

2 2

[U-Boot] PCI issues for bringing up ACPI support on QEMU and Minnowmax target
by Saket Sinha 29 Sep '15

29 Sep '15

Hi, This is regarding the PCI configuration issue I am facing for bringing up ACPI Support on QEMU and Minnowmax. Please find below my observations for the QEMU architecture. I am comparing arch/x86/cpu/qemu/acpi/pci-crs.asl and arch/x86/dts/qemu-x86_q35.dts and we find there are different ranges been specified for PCI configuration in both the files. I have found out the following things -- a) What does ACPI tell the OS - The most important chips which responsible for the BIOS code handling are the southbridge and northbridge. The northbridge acts as the address forwarder, meaning: it responds to this "special" memory address in different fashion compared to "normal" memory address which is forwarded directly to RAM. The southbridge acts as the address decoder, meaning: it decodes this "special" memory addresses into the right chip "beneath" it, such as the BIOS chip. Below is an example:*Physical Address**Also Known As**Used by**Address Aliasing Note*000F_0000h - 000F_FFFFhF_seg / F_segment1 Mbit, 2 MBit, and 4 Mbit BIOSalias to FFFF_0000h - FFFF_FFFFh in *all* chipset just after power-up000E_0000h - 000E_FFFFhE_seg / E_segment1 Mbit, 2 Mbit, and 4 Mbit BIOSalias to FFFE_0000h - FFFE_FFFFh in *some* chipset just after power-upFFFD_0000h - FFFD_FFFFhD_seg / D_segment2 Mbit, and 4 Mbit BIOS-FFFC_0000h - FFFC_FFFFhC_seg / C_segment2 Mbit, and 4 Mbit BIOS-FFF8_0000h - FFFB_FFFFh-4 Mbit BIOS- The address ranges shown above contain the BIOS code(part of the ACPI) and pretty much system specific. Thus all this is communicated by the ACPI to the OS. b) What does Device Tree tell the OS - >From 0x80000000 to 0xe0000000 is the PCI memory space, I/O space and prefetch space where memory mapping of the PCI bus. This is what device tree is dictating. To sum up Device Tree and ACPI do NOT the same things and thus play different values to make devices connected to PCI bus available. The issue I am facing is that I am getting configuration errors with BARs. >> [ 0.660567] pci 0000:00:01.0: can't claim BAR 0 [mem >> 0xd0000000-0xd0ffffff pref]: no compatible bridge window >> [ 0.662083] pci 0000:00:01.0: can't claim BAR 2 [mem >> 0xc0000000-0xc0000fff]: no compatible bridge window >> [ 0.663062] pci 0000:00:02.0: can't claim BAR 0 [mem >> 0xc0020000-0xc003ffff]: no compatible bridge window >> [ 0.664164] pci 0000:00:1f.2: can't claim BAR 5 [mem >> 0xc0080000-0xc0080fff]: no compatible bridge window BARs are part of the so-called PCI configuration register. Every PCI device must implement the PCI configuration register dictated by the PCI specification. Otherwise, the device will not be regarded as a valid PCI device. As per my understanding for Qemu q35 (emulation of the ICH9 hostchipset) where we have PCIe support which is made possible by PCI express enhanced accessmechanism (ECAM). This address is 0xe0000000 which is what I have put in arch/x86/dts/qemu-x86_q35.dts when I am memory mapping the PCI bus. Any inputs regarding the issue, as to what I am doing wrong here, are welcome. Regards, Saket Sinha

2 1