[U-Boot] [PATCH 0/21] dm: Support GPIO device tree bindings in the uclass
At present U-Boot sort-of supports the standard way of reading GPIOs from device tree nodes, but the support is incomplete, a bit clunky and only works for GPIO bindings where #gpio-cells is 2. Also, this support can now be built into the uclass, rather than parked in a separate file. Add support for requesting GPIOs based on a list in a device tree node, by looking up the phandles. Convert existing boards and remove the old code. As a side-effect, we now no-longer need to include asm/gpio.h in fdtdec.h, a problem reported by Masahiro and others. This series is tested on boards as follows, with the objective being to cover each code path: seaboard LCD comes up, USB host shows partitions, NAND can read/write. Both internal MMC and external SD card partition can be read. Ejecting external SD card is detected Tegra20 (SeaBoard) # gpio status Bank B: B2: output: 1 [x] panel.nvidia,lvds-shutdown-gpios Bank C: C6: output: 1 [x] panel.nvidia,panel-vdd-gpios Bank D: D0: output: 0 [x] usb@c500.nvidia,vbus-gpio D4: output: 1 [x] panel.nvidia,backlight-enable-gpios Bank H: H1: input: 0 [x] sd...@c8000400.wp-gpios H3: output: 1 [x] nand-controller@70008000.nvidia,wp-gpios Bank I: I5: input: 0 [x] sd...@c8000400.cd-gpios I6: output: 1 [x] sdhci@c8000400.power-gpios Bank W: W0: output: 1 [x] panel.nvidia,backlight-vdd-gpios pit --- LCD comes up, internal MMC and external uSD cards can show a partition list. EC works and the interrupt line behaves as expected. USB stick can display a partition list. pi -- EC works correctly. Simon Glass (21): dm: gpio: Bring in GPIO device tree binding dm: exynos: Bring in GPIO device tree binding dm: tegra: Bring in GPIO device tree binding dm: fdt: Add a function to decode phandles with arguments dm: gpio: Add a native driver model API dm: gpio: Add a driver GPIO translation method dm: gpio: Add better functions to request GPIOs dm: gpio: Mark the old GPIO API deprecated dm: demo: Add a simple GPIO demonstration dm: cros_ec: Remove use of fdtdec GPIO support dm: tegra: Add a GPIO translation function dm: exynos: Add a GPIO translation function dm: tegra: video: Remove use of fdtdec GPIO support dm: tegra: nand: Remove use of fdtdec GPIO support dm: zynq: Remove inline gpio functions dm: mmc: Remove use of fdtdec GPIO support dm: usb: Remove use of fdtdec GPIO support dm: spi: Remove use of fdtdec GPIO support dm: tegra: dts: Use TEGRA_GPIO() macro for all GPIOs dm: exynos: dts: Use GPIO bank phandles for GPIOs dm: fdt: Remove the old GPIO functions arch/arm/dts/exynos4.dtsi | 7 - arch/arm/dts/exynos4210-origen.dts | 2 +- arch/arm/dts/exynos4210-trats.dts | 4 +- arch/arm/dts/exynos4210-universal_c210.dts | 12 +- arch/arm/dts/exynos4412-odroid.dts | 2 +- arch/arm/dts/exynos4412-trats2.dts | 6 +- arch/arm/dts/exynos5.dtsi | 4 +- arch/arm/dts/exynos5250-smdk5250.dts | 2 +- arch/arm/dts/exynos5250-snow.dts | 10 +- arch/arm/dts/exynos5420-peach-pit.dts | 8 +- arch/arm/dts/exynos5422-odroidxu3.dts | 2 +- arch/arm/dts/exynos5800-peach-pi.dts | 10 +- arch/arm/dts/tegra114-dalmore.dts | 5 +- arch/arm/dts/tegra124-jetson-tk1.dts | 9 +- arch/arm/dts/tegra124-venice2.dts | 9 +- arch/arm/dts/tegra20-colibri_t20_iris.dts | 10 +- arch/arm/dts/tegra20-harmony.dts | 28 +- arch/arm/dts/tegra20-medcom-wide.dts | 9 +- arch/arm/dts/tegra20-paz00.dts | 18 +- arch/arm/dts/tegra20-seaboard.dts | 22 +- arch/arm/dts/tegra20-tamonten.dtsi | 9 +- arch/arm/dts/tegra20-tec.dts | 9 +- arch/arm/dts/tegra20-trimslice.dts | 8 +- arch/arm/dts/tegra20-ventana.dts | 18 +- arch/arm/dts/tegra20-whistler.dts | 2 +- arch/arm/dts/tegra30-apalis.dts| 10 +- arch/arm/dts/tegra30-beaver.dts| 10 +- arch/arm/dts/tegra30-cardhu.dts| 8 +- arch/arm/dts/tegra30-colibri.dts | 6 +- arch/arm/dts/tegra30-tamonten.dtsi | 4 +- arch/arm/include/asm/arch-pantheon/gpio.h | 0 arch/arm/include/asm/arch-tegra/tegra_mmc.h| 7 +- arch/arm/include/asm/arch-tegra20/display.h| 9 +- arch/arm/include/asm/arch-zynq/gpio.h | 15 - arch/sandbox/dts/sandbox.dts | 11 +- common/cmd_demo.c | 29 +- doc/device-tree-bindings/gpio/gpio-samsung.txt | 41 +++ doc/device-tree-bindings/gpio/gpio.txt | 211 +++ .../gpio/nvidia,tegra20-gpio.txt | 40 +++ drivers/demo/demo-shape.c
[U-Boot] [PATCH] net: Add mv88e60xx support to the mv88e61xx driver
The Marvell Link Street mv88e60xx is a series of FastEthernet switch
chips, some of which also support Gigabit ports. It is similar to the
mv88e61xx series which support Gigabit on all ports.
There is already a driver for the mv88e61xx in U-Boot, and this patch
updates it to also work with the mv88e60xx.
The main change that was required was the size of the port bitmaps.
Previously, 8-bit port bitmaps were in use, as the driver had only
been used with six-port mv88e61xx devices.
This has been changed so that 16-bit port bitmaps are now used, which
covers the largest port-counts available for the mv88e60xx / mv88e61xx.
Reviewed-by: Chris Packham chris.pack...@alliedtelesis.co.nz
Signed-off-by: Joshua Scott joshua.sc...@alliedtelesis.co.nz
---
drivers/net/phy/mv88e61xx.c | 29 +
drivers/net/phy/mv88e61xx.h | 2 --
include/netdev.h| 20 +++-
3 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index 302abe8..79204f3 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -215,17 +215,17 @@ static void mv88e61xx_port_vlan_config(struct
mv88e61xx_config *swconfig)
u32 port_mask = swconfig-ports_enabled;
/* apply internal vlan config */
- for (prt = 0; prt MV88E61XX_MAX_PORTS_NUM; prt++) {
+ for (prt = 0; prt swconfig-numports; prt++) {
/* only for enabled ports */
if ((1 prt) port_mask) {
/* take vlan map from swconfig */
- u8 vlanmap = swconfig-vlancfg[prt];
+ u16 vlanmap = swconfig-vlancfg[prt];
/* remove disabled ports from vlan map */
vlanmap = swconfig-ports_enabled;
/* apply vlan map to port */
RD_SWITCH_PORT_REG(name, prt,
MV88E61XX_PRT_VMAP_REG, reg);
- reg = ~((1 MV88E61XX_MAX_PORTS_NUM) - 1);
+ reg = ~((1 swconfig-numports) - 1);
reg |= vlanmap;
WR_SWITCH_PORT_REG(name, prt,
MV88E61XX_PRT_VMAP_REG, reg);
@@ -331,32 +331,44 @@ int mv88e61xx_switch_initialize(struct mv88e61xx_config
*swconfig)
return -1;
}
- if (!(swconfig-cpuport ((1 4) | (1 5 {
+ if (!(swconfig-cpuport ((1 4) | (1 5) | (1 10 {
swconfig-cpuport = (1 5);
printf(Invalid cpu port config, using default port5\n);
}
RD_SWITCH_PORT_REG(name, 0, MII_PHYSID2, reg);
switch (reg = 0xfff0) {
+ case 0x0980:
+ idstr = 88E6096;
+ swconfig-numports = 0x0b;
+ break;
+ case 0x0990:
+ idstr = 88E6097;
+ swconfig-numports = 0x0b;
+ break;
case 0x1610:
idstr = 88E6161;
+ swconfig-numports = 0x06;
break;
case 0x1650:
idstr = 88E6165;
+ swconfig-numports = 0x06;
break;
case 0x1210:
idstr = 88E6123;
+ swconfig-numports = 0x06;
/* ports 2,3,4 not available */
swconfig-ports_enabled = 0x023;
break;
default:
/* Could not detect switch id */
idstr = 88E61??;
+ swconfig-numports = 0x06;
break;
}
/* be sure all ports are disabled */
- for (prt = 0; prt MV88E61XX_MAX_PORTS_NUM; prt++) {
+ for (prt = 0; prt swconfig-numports; prt++) {
RD_SWITCH_PORT_REG(name, prt, MV88E61XX_PRT_CTRL_REG, reg);
reg = ~0x3;
WR_SWITCH_PORT_REG(name, prt, MV88E61XX_PRT_CTRL_REG, reg);
@@ -405,12 +417,13 @@ int mv88e61xx_switch_initialize(struct mv88e61xx_config
*swconfig)
WR_SWITCH_PORT_REG(name, 5, MV88E61XX_PCS_CTRL_REG, 0x3e);
}
- for (prt = 0; prt MV88E61XX_MAX_PORTS_NUM; prt++) {
+ for (prt = 0; prt swconfig-numports; prt++) {
/* configure port's PHY */
if (!((1 prt) swconfig-cpuport)) {
- /* port 4 has phy 6, not 4 */
- int phy = (prt == 4) ? 6 : prt;
+ /* 88e61xx: port 4 has phy 6, not 4 */
+ int phy = (swconfig-numports == 6
+ prt == 4) ? 6 : prt;
if (mv88361xx_powerup(swconfig, phy))
return -1;
if (mv88361xx_reverse_mdipn(swconfig, phy))
diff --git a/drivers/net/phy/mv88e61xx.h b/drivers/net/phy/mv88e61xx.h
index 9c62e4a..b289f21 100644
--- a/drivers/net/phy/mv88e61xx.h
+++ b/drivers/net/phy/mv88e61xx.h
@@ -11,8 +11,6 @@
[U-Boot] [PATCH 1/1] sunxi: add Linksprite pcDuino v1/v2 support
Add support for a sun4i board built by Linksprite. This addition covers
both v1 and v2 versions. As the board has been working with 408MHz memory
setting in the u-boot-sunxi branch, and has been proven to be running stable
during my tests as well, a respective new DRAM config file is added as well.
Signed-off-by: Zoltan HERPAI wigy...@uid0.hu
---
board/sunxi/Kconfig|4
board/sunxi/Makefile |1 +
board/sunxi/dram_sun4i_408_1024_iow8.c | 31 +++
configs/Linksprite_pcDuino_defconfig |7 +++
4 files changed, 43 insertions(+)
create mode 100644 board/sunxi/dram_sun4i_408_1024_iow8.c
create mode 100644 configs/Linksprite_pcDuino_defconfig
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 246cd9a..ccf583f 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -99,6 +99,10 @@ config TARGET_IPPO_Q8H_V5
bool IPPO_Q8H_V5
depends on MACH_SUN8I
+config TARGET_PCDUINO
+ bool PCDUINO
+ depends on MACH_SUN4I
+
config TARGET_PCDUINO3
bool PCDUINO3
depends on MACH_SUN7I
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index b84ff9b..c947b09 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_TARGET_MELE_A1000G) +=
dram_sun4i_360_1024_iow8.o
obj-$(CONFIG_TARGET_MELE_M3) += dram_sun7i_384_1024_iow16.o
obj-$(CONFIG_TARGET_MINI_X)+= dram_sun4i_360_512.o
obj-$(CONFIG_TARGET_MINI_X_1GB)+= dram_sun4i_360_1024_iow16.o
+obj-$(CONFIG_TARGET_PCDUINO) += dram_sun4i_408_1024_iow8.o
obj-$(CONFIG_TARGET_PCDUINO3) += dram_linksprite_pcduino3.o
obj-$(CONFIG_TARGET_QT840A)+= dram_sun7i_384_512_busw16_iow16.o
obj-$(CONFIG_TARGET_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_sun4i_408_1024_iow8.c
b/board/sunxi/dram_sun4i_408_1024_iow8.c
new file mode 100644
index 000..c6d87d2
--- /dev/null
+++ b/board/sunxi/dram_sun4i_408_1024_iow8.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+ .clock = 408,
+ .type = 3,
+ .rank_num = 1,
+ .density = 2048,
+ .io_width = 8,
+ .bus_width = 32,
+ .cas = 6,
+ .zq = 123,
+ .odt_en = 0,
+ .size = 1024,
+ .tpr0 = 0x30926692,
+ .tpr1 = 0x1090,
+ .tpr2 = 0x1a0c8,
+ .tpr3 = 0,
+ .tpr4 = 0,
+ .tpr5 = 0,
+ .emr1 = 0,
+ .emr2 = 0,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(dram_para);
+}
diff --git a/configs/Linksprite_pcDuino_defconfig
b/configs/Linksprite_pcDuino_defconfig
new file mode 100644
index 000..f5b0ca9
--- /dev/null
+++ b/configs/Linksprite_pcDuino_defconfig
@@ -0,0 +1,7 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_EMAC,USB_EHCI
+CONFIG_FDTFILE=sun4i-a10-pcduino.dtb
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN4I=y
++S:CONFIG_TARGET_PCDUINO=y
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Remove CONFIG_DISPLAY_CPUINFO in chromebook_link.h
CONFIG_DISPLAY_CPUINFO is already defined in x86-common.h, so remove it to avoid duplication. Signed-off-by: Bin Meng bmeng...@gmail.com --- include/configs/chromebook_link.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h index e0bf309..7e6d239 100644 --- a/include/configs/chromebook_link.h +++ b/include/configs/chromebook_link.h @@ -20,7 +20,6 @@ #define CONFIG_DCACHE_RAM_MRC_VAR_SIZE 0x4000 #define CONFIG_BOARD_EARLY_INIT_F -#define CONFIG_DISPLAY_CPUINFO #define CONFIG_NR_DRAM_BANKS 8 #define CONFIG_X86_MRC_ADDR0xfffa -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/19] powerpc: ppc4xx: Move CANYONLANDS/GLACIER/ARCHES to Kconfig
Hi Simon, On Mon, 15 Dec 2014 07:19:39 -0700 Simon Glass s...@chromium.org wrote: diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h index 7b1f368..ed790cc 100644 --- a/include/configs/canyonlands.h +++ b/include/configs/canyonlands.h @@ -11,6 +11,8 @@ #ifndef __CONFIG_H #define __CONFIG_H +#include linux/kconfig.h + Please do not explicitely include linux/kconfig.h from C sources. It is automatically included. See Makefile UBOOTINCLUDE:= \ -Iinclude \ $(if $(KBUILD_SRC), -I$(srctree)/include) \ -I$(srctree)/arch/$(ARCH)/include \ -include $(srctree)/include/linux/kconfig.h Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot compile arm u-boot with hardfloat toolchain
On 5 January 2015 at 02:28, Tom Rini tr...@ti.com wrote: On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote: Hello, when using a hardfloat toolchain linking u-boot fails. What version of U-Boot are you building? There's a few rc releases that fail with hardfp-only because a few things leaked in with 64bit math. I am building master (or what you get by cloning git) with some extra patches for sunxi support. Maybe I should check if some of the sunxi patches cause the failure. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot compile arm u-boot with hardfloat toolchain
Hi, On 05-01-15 11:46, B.R. Oake wrote: On 05/01/15 01:28, Tom Rini wrote: On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote: when using a hardfloat toolchain linking u-boot fails. What version of U-Boot are you building? There's a few rc releases that fail with hardfp-only because a few things leaked in with 64bit math. Hi Tom, I also encountered this problem ( http://lists.denx.de/pipermail/u-boot/2015-January/200123.html ) and found it was indeed when 64-bit maths operations were included. To be exact, it was this division of a long long in drivers/video/videomodes.c: mode-pixclock = 1LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); which was part of this commit in Hans' sunxi video series: 0cd5efe videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function and which was linked into the u-boot binary in a later commit: e7872f3 sunxi: video: Use video-mode/-timing from videomodes diff --git a/drivers/video/Makefile b/drivers/video/Makefile [...] -obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o Ah, ok, thanks for figuring that out, so this only happens to people following my sunxi-wip branch, because that commit is not upstream yet. So I guess I will need to fix this somehow without using 64 bit math, any suggestions? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot compile arm u-boot with hardfloat toolchain
On 05/01/15 01:28, Tom Rini wrote: On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote: when using a hardfloat toolchain linking u-boot fails. What version of U-Boot are you building? There's a few rc releases that fail with hardfp-only because a few things leaked in with 64bit math. Hi Tom, I also encountered this problem ( http://lists.denx.de/pipermail/u-boot/2015-January/200123.html ) and found it was indeed when 64-bit maths operations were included. To be exact, it was this division of a long long in drivers/video/videomodes.c: mode-pixclock = 1LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); which was part of this commit in Hans' sunxi video series: 0cd5efe videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function and which was linked into the u-boot binary in a later commit: e7872f3 sunxi: video: Use video-mode/-timing from videomodes diff --git a/drivers/video/Makefile b/drivers/video/Makefile [...] -obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o Thanks, B.R. Oake. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help on eTSEC initialization for p2020ds board
Hi, On Mon, Jan 5, 2015 at 1:27 PM, anupamdev dev.anu...@gmail.com wrote: Hi, I am trying to understand the uboot code for etsec initialization for ethernet on p2020ds board The function int tsec_init(struct eth_device *dev,bd_t bd) is a pointer to dev-init in the function tsec_initialize I need to know from where dev-init is being called so that i could initialize and reset he registers Check eth_init() in net/eth.c Thanks Anupam Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hi Heiko,
On 01/05/2015 03:59 PM, Heiko Schocher wrote:
+#ifdef CONFIG_SKIP_LOWLEVEL_INIT
void spl_board_init(void)
+#else
+void s_init(void)
+#endif
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
... and adding this ifdefs could be prevented ...
What do you think?
Ah! you wrote:
As the boot from SD/MMC card with FAT file system, the BSS
segment is too big to fit into SRAM, so, use the lds to put
it into SDRAM. So, we need to initialize the SDRAM as soon
as possible. Borrow the low level init code from
arm/arm/cpu/armv7/lowlevel_init.S for this purpose.
Hmm... maybe we can include this in the existing code? So we
The existed code is located in arch/arm/cpu/armv7 directory, I think
it is difficult to include it.
I think we can put it into arch/arm/cpu/arm926ejs directory, I am not
sure it will help others. As other SoC has low level init code. Or, as
the patch, put it into arch/arm/cpu/arm926ejs/at91 directory for at91
series only.
have BSS for all at91 boards in RAM?
It depends, we still can put the BSS into SRAM use the common
u-boot-spl.lds.
Only put BSS into SDRAM/DDR, when use u-boot-spl-arm9.lds.
Or, if not possible, we should convert the existing boards into
your framework ... if you can prepare such a patch I can test it
on the corvus, taurus and axm boards ...
If the upper method for low level initialize code is chosen, I will
prepare such patch for the boards you mentioned.
bye,
Heiko
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hello Bo,
Am 05.01.2015 09:19, schrieb Bo Shen:
Hi Heiko,
On 01/05/2015 03:59 PM, Heiko Schocher wrote:
+#ifdef CONFIG_SKIP_LOWLEVEL_INIT
void spl_board_init(void)
+#else
+void s_init(void)
+#endif
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
... and adding this ifdefs could be prevented ...
What do you think?
Ah! you wrote:
As the boot from SD/MMC card with FAT file system, the BSS
segment is too big to fit into SRAM, so, use the lds to put
it into SDRAM. So, we need to initialize the SDRAM as soon
as possible. Borrow the low level init code from
arm/arm/cpu/armv7/lowlevel_init.S for this purpose.
Hmm... maybe we can include this in the existing code? So we
The existed code is located in arch/arm/cpu/armv7 directory, I think it is
difficult to include it.
I think we can put it into arch/arm/cpu/arm926ejs directory, I am not sure it will
help others. As other SoC has low level init code. Or, as the patch, put it into
arch/arm/cpu/arm926ejs/at91 directory for at91 series only.
I thought with maybe we can include this in the existing code?
adding into existing at91 code the earlier RAM initialization and
using BSS in RAM, without needing CONFIG_SKIP_LOWLEVEL_INIT ...
have BSS for all at91 boards in RAM?
It depends, we still can put the BSS into SRAM use the common u-boot-spl.lds.
Only put BSS into SDRAM/DDR, when use u-boot-spl-arm9.lds.
Ok, Yes.
Or, if not possible, we should convert the existing boards into
your framework ... if you can prepare such a patch I can test it
on the corvus, taurus and axm boards ...
If the upper method for low level initialize code is chosen, I will prepare
such patch for the boards you mentioned.
I vote for having only one way for the at91 boards, so
your approach is also OK for me ... if andreas is fine
with it, please feel free to send me a patch for testing
on the mentioned boards, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: atmel: at91sam9m10g45ek: enable SPL
Hello Bo,
Am 29.12.2014 08:53, schrieb Bo Shen:
Supports boot up from NAND flash with software ECC eanbled.
And supports boot up from SD/MMC card with FAT file system.
As the boot from SD/MMC card with FAT file system, the BSS
segment is too big to fit into SRAM, so, use the lds to put
it into SDRAM. So, we need to initialize the SDRAM as soon
as possible. Borrow the low level init code from
arm/arm/cpu/armv7/lowlevel_init.S for this purpose.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
arch/arm/Kconfig| 1 +
arch/arm/cpu/arm926ejs/at91/Makefile| 4 ++
arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S | 37
arch/arm/cpu/at91-common/spl_at91.c | 10
arch/arm/cpu/at91-common/u-boot-spl-arm9.lds| 48 +++
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 80 +
configs/at91sam9m10g45ek_mmc_defconfig | 5 +-
configs/at91sam9m10g45ek_nandflash_defconfig| 5 +-
include/configs/at91sam9m10g45ek.h | 64
9 files changed, 250 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S
create mode 100644 arch/arm/cpu/at91-common/u-boot-spl-arm9.lds
[...]
diff --git a/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S
b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S
new file mode 100644
index 000..f1b2ec9
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/at91/spl_lowlevel_init.S
@@ -0,0 +1,37 @@
+/*
+ * A lowlevel_init function that sets up the stack to call a C function to
+ * perform further init.
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ *
+ * Author :
+ * Aneesh Vane...@ti.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm-offsets.h
+#include config.h
+#include linux/linkage.h
+
+ENTRY(lowlevel_init)
+ /*
+* Setup a temporary stack
+*/
+ ldr sp, =CONFIG_SYS_INIT_SP_ADDR
+ bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
+
+ ldr r9, =gdata
+
+ /*
+* Save the old lr(passed in ip) and the current lr to stack
+*/
+ push{ip, lr}
+
+ /*
+* go setup pll, mux, memory
+*/
+ bl s_init
+ pop {ip, pc}
+ENDPROC(lowlevel_init)
Hmm ... we have SPL support for at91sam9* boards without
such a file in U-Boot (and without an
arch/arm/cpu/at91-common/u-boot-spl-arm9.lds),
see for example:
http://git.denx.de/?p=u-boot.git;a=blob;f=configs/corvus_defconfig;h=5d60847523487cac5e2e9421d9e6c6ff3fa2ce9e;hb=b7b3b8c6a0bfc87047cb18a7abfa06fb6e9d0331
The spl_board_init is called from ./common/spl/spl.c
from board_init_r which is called from board_init_f
in ./arch/arm/lib/spl.c, which is called from
./arch/arm/lib/crt0.S
Is this new file really needed? It should possible to remove
CONFIG_SKIP_LOWLEVEL_INIT
in include/configs/at91sam9m10g45ek.h ...
diff --git a/arch/arm/cpu/at91-common/spl_at91.c
b/arch/arm/cpu/at91-common/spl_at91.c
index 89f588b..f044117 100644
--- a/arch/arm/cpu/at91-common/spl_at91.c
+++ b/arch/arm/cpu/at91-common/spl_at91.c
@@ -71,7 +71,17 @@ void __weak at91_spl_board_init(void)
{
}
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT
+__weak void spl_board_init(void)
+{
+}
+#endif
+
+#ifdef CONFIG_SKIP_LOWLEVEL_INIT
void spl_board_init(void)
+#else
+void s_init(void)
+#endif
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
... and adding this ifdefs could be prevented ...
What do you think?
Ah! you wrote:
As the boot from SD/MMC card with FAT file system, the BSS
segment is too big to fit into SRAM, so, use the lds to put
it into SDRAM. So, we need to initialize the SDRAM as soon
as possible. Borrow the low level init code from
arm/arm/cpu/armv7/lowlevel_init.S for this purpose.
Hmm... maybe we can include this in the existing code? So we
have BSS for all at91 boards in RAM?
Or, if not possible, we should convert the existing boards into
your framework ... if you can prepare such a patch I can test it
on the corvus, taurus and axm boards ...
bye,
Heiko
diff --git a/arch/arm/cpu/at91-common/u-boot-spl-arm9.lds
b/arch/arm/cpu/at91-common/u-boot-spl-arm9.lds
new file mode 100644
index 000..6f350a9
--- /dev/null
+++ b/arch/arm/cpu/at91-common/u-boot-spl-arm9.lds
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014 Atmel Corporation
+ * Bo Shen voice.s...@atmel.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE, \
+ LENGTH = CONFIG_SPL_MAX_SIZE }
+MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
+ LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
+
+OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+ .text :
+ {
+ __start = .;
+ *(.vectors)
+ arch/arm/cpu/arm926ejs/start.o (.text*)
+
Re: [U-Boot] Cannot compile arm u-boot with hardfloat toolchain
Hi On Mon, Jan 5, 2015 at 11:51 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 05-01-15 11:46, B.R. Oake wrote: On 05/01/15 01:28, Tom Rini wrote: On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote: when using a hardfloat toolchain linking u-boot fails. What version of U-Boot are you building? There's a few rc releases that fail with hardfp-only because a few things leaked in with 64bit math. Hi Tom, I also encountered this problem ( http://lists.denx.de/pipermail/u-boot/2015-January/200123.html ) and found it was indeed when 64-bit maths operations were included. To be exact, it was this division of a long long in drivers/video/videomodes.c: mode-pixclock = 1LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); which was part of this commit in Hans' sunxi video series: 0cd5efe videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function and which was linked into the u-boot binary in a later commit: e7872f3 sunxi: video: Use video-mode/-timing from videomodes diff --git a/drivers/video/Makefile b/drivers/video/Makefile [...] -obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o Ah, ok, thanks for figuring that out, so this only happens to people following my sunxi-wip branch, because that commit is not upstream yet. So I guess I will need to fix this somehow without using 64 bit math, any suggestions? do_div? Michael Regards, Hans ___ 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] Cannot compile arm u-boot with hardfloat toolchain
On 05/01/15 10:51, Hans de Goede wrote: Ah, ok, thanks for figuring that out, so this only happens to people following my sunxi-wip branch, because that commit is not upstream yet. So I guess I will need to fix this somehow without using 64 bit math, any suggestions? EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is 10,000 times a uint16, so one way of avoiding 64-bit arithmetic would be to cancel out the 10,000 before the division: --- a/drivers/video/videomodes.c2015-01-05 10:18:58.745985034 + +++ b/drivers/video/videomodes.c2015-01-05 12:15:27.484150964 + @@ -411,7 +411,8 @@ mode-refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / (h_total * v_total); - mode-pixclock = 1LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); + mode-pixclock = 1L / + (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 1); mode-pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) / 1000; I still wonder though whether a nicer way would be for the configs to be refactored so that -msoft-float was not set on platforms where it wasn't appropriate. Cheers, B.R. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] x86: config: chromebook_link: Enable environment
Hi Simon, On Mon, Jan 5, 2015 at 9:54 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 January 2015 at 01:08, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Dec 30, 2014 at 9:12 AM, Simon Glass s...@chromium.org wrote: Enable an environment area. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/chromebook_link.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h index 22cb134..9b70435 100644 --- a/include/configs/chromebook_link.h +++ b/include/configs/chromebook_link.h @@ -68,6 +68,11 @@ #define CONFIG_CMD_CROS_EC #define CONFIG_ARCH_EARLY_INIT_R +#undef CONFIG_ENV_IS_NOWHERE +#define CONFIG_ENV_IS_IN_SPI_FLASH I don't see CONFIG_ENV_SIZE is defined anywhere. Will that work without CONFIG_ENV_SIZE? That's in x86_common.h Ah, I see, thanks. Maybe we need just redefine it here since I believe CONFIG_ENV_SIZE should match to multiple times of CONFIG_ENV_SECT_SIZE. +#define CONFIG_ENV_OFFSET 0x003f8000 +#define CONFIG_ENV_SECT_SIZE 256 I think the CONFIG_ENV_SECT_SIZE should match the SPI flash sector size. Ah yes I think this should be 4096. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Full paths when compiling
Hi Simon, On Mon, Jan 5, 2015 at 10:11 AM, Simon Glass s...@chromium.org wrote: Hi Masahiro, I notice that when compiling I get the full paths to the source when I use __FILE__: /home/sjg/c/src/third_party/u-boot/files/cros/lib/readwrite.c: vboot_rw_select_kernel: VbSelectAndLoadKernel: 65552 /home/sjg/c/src/third_party/u-boot/files/cros/lib/vboot.c: vboot_set_error: Stage 'VbSelectAndLoadKernel' produced vboot error 0x10010 /home/sjg/c/src/third_party/u-boot/files/cros/vboot/stages.c: vboot_run_stage: Error: stage 'rw_selectkernel' returned -1 Is there a way to only get the relative path, say cros/lib/readwrite.c? I believe you are asking for a preprocessor level solution in gcc? Unforunately AFAIK there is no such support in gcc. We have to do it ourselves with some runtime string operations :- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] RFC: Add driver model support for PCI
Hi Simon, On Tue, Nov 25, 2014 at 3:32 AM, Simon Glass s...@chromium.org wrote: This is an early preview of some recent work to support PCI in driver model. It was prompted by fiddling with bare x86 support and finding that PCI has its own device model, but no actual storage as to what devices exist in the system. It is not possible to specify configuration information for devices other than in board code. This patch is a collection of changes in core DM, sandbox and PCI code to implement a PCI uclass and associated operations. Some basic tests are provided but they are incomplete. As is becoming common with DM conversions, the existing structure (here struct pci_controller) becomes per-bus uclass data. This allows the concept of a 'hose' (generally a PCI host controller and a bus) to continue to exist in the interim, even if it should not be needed in the end. This makes it much easier to convert over existing code. There is one major core DM change tacked into this patch. The core DM code is updated to move allocation of platform data into the bind() stage instead of probe(). This is because with PCI we need to know the bus address of a device (in PCI speak: device and function or devfn) before we can probe it. Actually a similar problem arose with SPI and I2C and I worked around it, but with evidence from PCI also it seems we should make this change. PCI buses are not scanned in the bind() method but only later when probe() is called. This will be automatic if you access a bus, but it does mean that if PCI is not used it will not be touched, in keeping with U-Boot's lazy- init philosophy. The existing 'pciauto' bus configuration code is still used, although it now uses DM underneath. It works exclusively by reading and writing PCI config and does not refer to DM data structures. In fact that file is not touched in this patch which is an indication that a good level of compatibility is achieved between DM and legacy PCI. In order to support testing of PCI I/O and memory space, support has been added to sandbox to allow mapping of these. This allows commands like 'md' and 'iod' to display data from mapped PCI devices. Similarly, it is possible to make changes to this space. This support relies on the existing map_sysmem() and unmap_sysmem() calls which are now fairly widespread in U-Boot. Apart from the driver model tests (run with ./test/dm/test-dm.sh) you can try out these commands which use the new 'swap_case' test device: ../u-boot -d b/sandbox/u-boot.dtb = iow.b 2000 2 = iod.b 2000 : 02 = mw.l 1000 64436241 = md.l 1000 1 1000: 44634261 aBcD = This shows an I/O access to 2000, setting the value 2 which means to swap the case. Then 'AbCd' is written to the memory space at 1000 and 'aBcD' is read back. The 'pci' command works to some extent. Most existing PCI functions still work, but route through driver model. The file drivers/pci/pci.c is replaced when driver model is enabled so not everything is present. Also multiple bus support is untested and probably broken. A new pci_common.c file holds functions common to driver model and the old system, and pci_compat.c contains functions I would like to eventually deprecate. This series is not tested on any real hardware at this stage. Once the bare x86 support is merged I will tidy this patch up and move it over, fix up Kconfig, etc. This patch is available at u-boot-dm.git branch pci-working. Signed-off-by: Simon Glass s...@chromium.org --- arch/sandbox/Kconfig | 6 + arch/sandbox/cpu/cpu.c| 37 ++- arch/sandbox/dts/sandbox.dts | 26 ++- arch/sandbox/include/asm/io.h | 16 +- arch/sandbox/include/asm/processor.h | 12 + arch/sandbox/include/asm/test.h | 7 +- arch/sandbox/include/asm/u-boot-sandbox.h | 7 + arch/sandbox/lib/Makefile | 2 +- arch/sandbox/lib/pci_io.c | 137 +++ common/board_r.c | 2 + common/cmd_mem.c | 7 +- common/cmd_pci.c | 14 +- configs/sandbox_defconfig | 4 + doc/driver-model/pci-info.txt | 52 + drivers/core/device.c | 92 ++-- drivers/core/root.c | 3 + drivers/misc/Makefile | 1 + drivers/misc/swap_case.c | 284 +++ drivers/pci/Kconfig | 22 ++ drivers/pci/Makefile | 10 +- drivers/pci/pci-emul-uclass.c | 66 ++ drivers/pci/pci-uclass.c | 374 ++ drivers/pci/pci.c | 72 +- drivers/pci/pci_common.c | 72 ++ drivers/pci/pci_compat.c | 67
Re: [U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed
Hi Simon,
On Mon, Jan 5, 2015 at 9:45 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 3 January 2015 at 22:54, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass s...@chromium.org wrote:
Add code to the generic pci_rom file to access the VGA ROM in PCI space
when needed.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/pci/pci_auto.c | 28 +++-
drivers/pci/pci_rom.c | 7 ++-
include/pci.h | 9 +
3 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 44470fa..61bf6b4 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -11,7 +11,7 @@
*/
#include common.h
-
+#include errno.h
#include pci.h
#undef DEBUG
@@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
}
+int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
+{
+ pci_addr_t bar_value;
+ pci_size_t bar_size;
+ u32 bar_response;
+ u16 cmdstat = 0;
+
+ pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);
I think it is better for people to understand if not writing -2.
+ pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS,
bar_response);
+ if (!bar_response)
+ return -ENOENT;
+
+ bar_size = -(bar_response ~1);
+ DEBUGF(PCI Autoconfig: ROM, size=%#x, , bar_size);
+ if (pciauto_region_allocate(hose-pci_mem, bar_size, bar_value) ==
0) {
Should we assume pci roms are always mapped using the pci_mem region?
If not, maybe we can add another parameter 'region_type' to
pciauto_setup_rom()?
I'm not sure - do you think we should support the cacheable area too?
Would that help?
I'm not sure either. I thought you might know more than me as so far I
see pci rom is used for vga, ahci, pxe roms, and storage media for mac
addresses on some ethernet cards. They all belong to pci_mem regions.
Let's do it pci_mem and revisit it in the future if we see something
different.
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [UBOOT NAND] [PATCH 0/4] Add nand reading support to u-boot
Hi, On 02-01-15 09:53, Daniel Kochmański wrote: This is a series of patches to enable nand read functionality on sunxi devices. It uses DMA and is able to read from syndrome partitions and normal ones. Additionaly mksunxiboot tool is patched to be able to format resulting binary to be able to read from BROM, so NAND SPL builds are now possible. a20_nandread command is added for conveniance. Afaik DMA controller doesn't vary between a10 and a20, so this should work on a10 devices, but due to no a10 hardware it wasn't tested. First of all many thanks for working on this! I see that this is against linux-sunxi/u-boot-sunxi.git, that is not (really) being actively developed anymore, see: https://www.marshut.net/kuispp/linux-sunxi-u-boot-sunxi-is-no-longer-supported-time-to-switch-to-upstream-u-boot.html Can you please rebase on top of upstream u-boot, on top of the next branch: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog;h=refs/heads/next ? Your patches all seem to only have a subject and not a proper commit message, please add a commit message to all of them describing the changes in somewhat more detail then you do in the subject, you could e.g. re-use bits of your coverletter. Also for upstream u-boot we require a Signed-off-by as part of the commit message, so please add a line like this one to all your commit messages: Signed-off-by: Daniel Kochmański dkochman...@antmicro.com You can make git do this automatically by specifying the -s option when committing, also please send further versions of this patch-set to the upstream u-boot list. Besides all the above, which is easily fixed, unfortunately we also have the problem (or luxury) that Yassin Jaffer (added to the CC) has also been working on nand support, re-using the upstream kernel code Boris Brezillon has been working on, see: https://github.com/yassinjaffer/u-boot/commits/sunxi-nand I believe that Yassin's version is better then yours because it re-uses existing nand infrastructure rather then more or less starting from scratch. But Yassin has not been very active on this, and has been reluctant to submit his work upstream because it has not been tested a lot yet. The best way forward may very well be you picking up Yassin's work (in coordination with Yassin), and submitting that to upstream u-boot. Yassin, I notice that the patches in your git repo do not have a Signed-off-by, can you please reply to this mail with your Signed-off-by to indicate that it is ok for us to add your Signed-off-by to your patches ? Regards, Hans Daniel Kochmański (4): sunxi: nand: add minimal nand driver (reading flash only). sunxi: mksunxiboot: increase block size, so checksum is correct on nand sunxi: nand: add nand spl boot option sunxi: nand: add a20_nandread command arch/arm/cpu/armv7/sunxi/board.c | 4 + board/sunxi/Makefile | 1 + board/sunxi/nand.c | 252 +++ common/Makefile | 1 + common/cmd_a20_nandread.c| 26 common/spl/spl_nand.c| 23 +++- include/configs/sunxi-common.h | 25 ++-- tools/mksunxiboot.c | 2 +- 8 files changed, 322 insertions(+), 12 deletions(-) create mode 100644 board/sunxi/nand.c create mode 100644 common/cmd_a20_nandread.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot compile arm u-boot with hardfloat toolchain
On Mon, Jan 05, 2015 at 12:24:13PM +, B.R. Oake wrote: On 05/01/15 10:51, Hans de Goede wrote: Ah, ok, thanks for figuring that out, so this only happens to people following my sunxi-wip branch, because that commit is not upstream yet. So I guess I will need to fix this somehow without using 64 bit math, any suggestions? EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is 10,000 times a uint16, so one way of avoiding 64-bit arithmetic would be to cancel out the 10,000 before the division: Good idea! [snip] I still wonder though whether a nicer way would be for the configs to be refactored so that -msoft-float was not set on platforms where it wasn't appropriate. We've gone over this before (so there's discussions in the archive) but in sum, no, we don't want to get into doing floating point. -- 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 16/22] x86: board_f: Adjust x86 boot order for performance
Hi Simon,
On Mon, Jan 5, 2015 at 9:44 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 3 January 2015 at 20:26, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Fri, Jan 2, 2015 at 6:23 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 30 December 2014 at 22:51, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Sun, Dec 28, 2014 at 10:20 AM, Simon Glass s...@chromium.org wrote:
For bare platforms we turn off ROM-caching before calling
board_init_f_r()
It is then very slow to copy U-Boot from ROM to RAM. So adjust the order
so
that the copying happens before we turn off ROM-caching.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_f.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 98c9c72..1b65575 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -983,6 +983,11 @@ static init_fnc_t init_sequence_f[] = {
INIT_FUNC_WATCHDOG_RESET
reloc_fdt,
setup_reloc,
+#ifdef CONFIG_X86
+ copy_uboot_to_ram,
+ clear_bss,
+ do_elf_reloc_fixups,
+#endif
#if !defined(CONFIG_ARM) !defined(CONFIG_SANDBOX)
jump_to_copy,
#endif
@@ -1042,9 +1047,6 @@ void board_init_f(ulong boot_flags)
*/
static init_fnc_t init_sequence_f_r[] = {
init_cache_f_r,
- copy_uboot_to_ram,
- clear_bss,
- do_elf_reloc_fixups,
NULL,
};
--
I don't understand. Isn't the init_cache_f_r() which turns on the cache?
Yes it turns on the cache, but turns off the ROM cache (they are
different things). So this ordering is much faster. I think I might
have more tuning to do though.
Got it. Since we moved these 3 routines from init_sequence_f_r[] to
init_sequence_f[], how about we remove the whole init_sequence_f_r[]
completely? If not possible, the comment block above
init_sequence_f_r[] needs to be fixed?
I'll remove the comment.
*
* The '_f_r' sequence must, as a minimum, copy U-Boot to RAM (if
* supported). It _should_, if possible, copy global data to RAM and
* initialise the CPU caches (to speed up the relocation process)
*
* NOTE: At present only x86 uses this route, but it is intended that
* all archs will move to this when generic relocation is implemented.
*/
So looks that we should either drop this _f_r stage, or make other
arch use this _f_r?
I think we should move to generic relocation, meaning that all archs
do relocation the same way with the same code. Then only arch-specific
stuff is the then ELF fixup function, which adjusts a relocation site,
and the code to actually change the stack pointer.
This board_init_f_r() code is part of one attempt to do this - the
premise was that turning the cache on before relocating U-Boot will
save time. That's true, but it would be even better to turn the cache
on much earlier. With pit (Chromebook 2) we turn on the cache in SPL.
So I think turning it on here is too late if we are trying to save
time. Still it is a good start and if we could make it happen
generally it would be nice.
See here for my original attempt, which was tied up with generic
board. In the end I untied them and we got one but not the other.
http://lists.denx.de/pipermail/u-boot/2012-February/118409.html
Since then Albert has tidied up ARM start.S a lot which makes this much
easier.
So that's the background. One of these days I might take another look
at it if it doesn't get someone's attention.
Regards,
Simon
Thanks for the background information. I will take a look. Hope we can
achieve generic board support as soon as we can.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] x86: Implement a cache for Memory Reference Code parameters
Hi Simon, On Mon, Jan 5, 2015 at 9:49 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 January 2015 at 00:49, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Dec 30, 2014 at 9:12 AM, Simon Glass s...@chromium.org wrote: The memory reference code takes a very long time to 'train' its SDRAM interface, around half a second. To avoid this delay on every boot we can store the parameters from the last training sessions to speed up the next. Add an implementation of this, storing the training data in CMOS RAM and SPI flash. Is storing mrc data to cmos ram not enough, so that we must store it to spi flash? It's about 3KB of data, so doesn't fit in CMOS. Sorry but I did not get into the details of the codes, but if CMOS cannot hold the whole MRC cache data, what information do we need save in the CMOS? Can we just save them into SPI flash all toghether without having CMOS? [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Full paths when compiling
Hi Simon, 2015-01-05 11:11 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, I notice that when compiling I get the full paths to the source when I use __FILE__: /home/sjg/c/src/third_party/u-boot/files/cros/lib/readwrite.c: vboot_rw_select_kernel: VbSelectAndLoadKernel: 65552 /home/sjg/c/src/third_party/u-boot/files/cros/lib/vboot.c: vboot_set_error: Stage 'VbSelectAndLoadKernel' produced vboot error 0x10010 /home/sjg/c/src/third_party/u-boot/files/cros/vboot/stages.c: vboot_run_stage: Error: stage 'rw_selectkernel' returned -1 Is there a way to only get the relative path, say cros/lib/readwrite.c? [1] In-tree build (without O=...) [2] Out-of-tree build and the build directory is right under the source tree For example, O=foo [3] Out-of-tree build and the build directory is not right under the source tree For example, O=foo/bar or O=../foo __FILE__ points to the source file in relative path for [1] and [2], and in absolute path for [3]. I guess you are doing [3]. Just try [1] or [2]. FYI, the relative/absolute path is determined by srctree of the top Makefile. ifeq ($(KBUILD_SRC),) # building in the source tree srctree := . else ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR))) # building in a subdirectory of the source tree srctree := .. else srctree := $(KBUILD_SRC) endif endif -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] i2c: UniPhier: add driver for UniPhier i2c controller
Hi Heiko, 2015-01-05 15:52 GMT+09:00 Heiko Schocher h...@denx.de: Hello Masahiro, Am 26.12.2014 04:07, schrieb Masahiro Yamada: This commit adds on-chip I2C driver used on some old Panasonic UniPhier SoCs. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Fix a typo. s/freqency/frequency/ - Add some comments to explain the formula calculating wait time. - add comments on every register - skip stop condition if the next message is read drivers/i2c/Kconfig| 14 +++ drivers/i2c/Makefile | 1 + drivers/i2c/i2c-uniphier.c | 233 + 3 files changed, 248 insertions(+) create mode 100644 drivers/i2c/i2c-uniphier.c diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index e69de29..6a479ef 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -0,0 +1,14 @@ +config DM_I2C + bool Enable Driver Model for I2C drivers + depends on DM + help + If you want to use driver model for I2C drivers, say Y. + To use legacy I2C drivers, say N. This change seems not related to the add driver for UniPhier i2c controller topic ... OK, I can split it into two patches. Beside of that, you can add my Acked-by: Heiko Schocher h...@denx.de to the hole serie. I think this should go to the u-boot-dm tree from Simon, as it depends on DM changes, or? Simon? Is this OK for you? I do not mind if Simon is willing to apply it to u-boot-dm. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] dm: i2c: support 10bit addressing in I2C uclass layer
Hi Simon, 2014-12-22 3:53 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 20 December 2014 at 00:25, Masahiro YAMADA yamad...@jp.panasonic.com wrote: Hi Simon, 2014-12-20 6:34 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 19 December 2014 at 11:34, Masahiro Yamada yamad...@jp.panasonic.com wrote: Master send to / receive from 10-bit addressed slave devices can be supported by software layer without any hardware change because the LSB 8bit of the slave address is treated as data part. Master Send to a 10bit-addressed slave chip is performed like this: DIRFormat M-S 0 + address[9:8] + R/W(0) M-S address[7:0] M-S data0 M-S data1 ... Master Receive from a 10bit-addressed slave chip is like this: DIRFormat M-S 0 + address[9:8] + R/W(0) M-S address[7:0] (Restart) M-S 10 + address[9:8] + R/W(1) S-M data0 S-M data1 ... Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org --- drivers/i2c/i2c-uclass.c | 80 +++- include/i2c.h| 4 +++ 2 files changed, 56 insertions(+), 28 deletions(-) Seems like a good idea if we can make it work... But this is driver-specific. Some drivers have hardware to send the address and it isn't part of the message. For example see the tegra driver. So what you have here feels a bit like a hack to me. Can't the driver implement it? If you are trying to avoid driver work to support 10-bit addresses, maybe it should be an option that we can enable for each driver, so we don't break the other drivers? I was writing two I2C drivers on DM, both of which have no dedicated hardware support for 10bit addressing. Of course, the driver could implement it, but it means I put the completely the same code in each of driver. For write transaction, for example, we create a new buffer and copy offset-address + data in Uclass layer. Do I have to create a new buffer again, in my driver, and copy lower-slave-address + offset-address + data ? I see your point! Perhaps, is it a good idea to have it optional? DM_I2C_FLAG_SW_TENBIT - if set, uclass takes care of 10bit addressing by software if unset, each driver is responsible to handle I2C_M_TEN correctly altough I do think 10bit support on U-Boot is urgent necessity... I've thought about this quite a bit. We have only just changed the API to be the same as Linux (the list of messages). It seems wrong to now hack it around, such that the address field only stores the first part of the address in 10-bit mode. Did we like the API or not? I am not sure... That is why I sent this series as RFC. I see two options that are somewhat sane and defensible: I see another option: Do not support 10bit address (or leave it to each driver if necessary). Rationale: Until now, U-boot has not supported 10bit address and nobody has not complained about that. - Add a helper function in the uclass that the driver can call to turn the address + message into a single stream of bytes (we can avoid a second malloc() by reserving space for the address bytes before the message or similar similar, so long is it is clearly documented) - Allow the driver to request that the message bytes should always contain the address, which would remove the address-processing code from the driver. How? set a flag?? I think this needs a little more discussion before we decide what to do. Agreed. We do not rush to make a decision. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cannot compile arm u-boot with hardfloat toolchain
Hi, On 05-01-15 13:24, B.R. Oake wrote: On 05/01/15 10:51, Hans de Goede wrote: Ah, ok, thanks for figuring that out, so this only happens to people following my sunxi-wip branch, because that commit is not upstream yet. So I guess I will need to fix this somehow without using 64 bit math, any suggestions? EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is 10,000 times a uint16, so one way of avoiding 64-bit arithmetic would be to cancel out the 10,000 before the division: --- a/drivers/video/videomodes.c2015-01-05 10:18:58.745985034 + +++ b/drivers/video/videomodes.c2015-01-05 12:15:27.484150964 + @@ -411,7 +411,8 @@ mode-refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / (h_total * v_total); - mode-pixclock = 1LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); + mode-pixclock = 1L / + (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 1); mode-pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) / 1000; I still wonder though whether a nicer way would be for the configs to be refactored so that -msoft-float was not set on platforms where it wasn't appropriate. Ah I did not realize that the EDID_DETAILED_TIMING_PIXEL_CLOCK did * 1, that indeed makes things easier, I've done this instead (somewhat cleaner) : - mode-pixclock = 1LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); - mode-pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) / - 1000; + mode-pixclock_khz = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 1000; + mode-pixclock = 10L / mode-pixclock_khz; I've squashed this fix into my personal tree, sunxi-wip branch, so people building from there should not longer see those compile errors, and I'll preserve the fix when the patches move to u-boot-sunxi/next :) Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (resending) Please pull u-boot-tegra.git/master
On Thu, Jan 01, 2015 at 11:31:34AM -0700, Simon Glass wrote: Hi, This one got lost in another thread and the pull request did not appear in patchwork, so I'm resending it copied from Tom's email...it should be applied to mainline. http://patchwork.ozlabs.org/patch/419415/ Please pull u-boot-tegra.git/master into ARM master. ./MAKEALL -s tegra is clean. The following changes since commit e3bf81b1e841ecabe7c8b3d48621256db8b8623e: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-12-16 15:20:02 -0500) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to cc0856cd149acc7069ae97ebe10b92090a65f575: net: rtl8169: Add support for RTL-8168/8111g (2014-12-18 13:21:41 -0700) 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 request: u-boot-spi/master
On Mon, Dec 29, 2014 at 10:37:52PM +0530, Jagannadha Sutradharudu Teki wrote: Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit e3bf81b1e841ecabe7c8b3d48621256db8b8623e: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-12-16 15:20:02 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to babe6994ca28e5a354ee32b33b7a54b0276d9df1: sf: sf_params: Add S25FL164K flash identifier info (2014-12-18 18:48:30 +0530) 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 request: u-boot-spi/master
On Fri, Jan 02, 2015 at 02:15:21AM +0530, Jagannadha Sutradharudu Teki wrote: Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit babe6994ca28e5a354ee32b33b7a54b0276d9df1: sf: sf_params: Add S25FL164K flash identifier info (2014-12-18 18:48:30 +0530) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to be2fde60b0de7723d29035ba952a970d9e1ca94d: imx:mx6slevk add spi nor boot support (2014-12-31 14:54:01 +0530) 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 request: u-boot-arm/master
On Sun, Jan 04, 2015 at 07:11:42PM +0100, Albert ARIBAUD wrote: Hi Tom, The following changes since commit e3bf81b1e841ecabe7c8b3d48621256db8b8623e: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-12-16 15:20:02 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to ed710457a52ff09880af52540c997615adbc91ee: ARM: Implement non-cached memory support (2014-12-18 21:18:43 +0100) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] sun6i: Add basic axp221 driver
Hi, On 02-01-15 06:17, Siarhei Siamashka wrote: On Mon, 10 Nov 2014 14:11:51 +0100 Hans de Goede hdego...@redhat.com wrote: From: Oliver Schinagl oli...@schinagl.nl The A31 uses the AXP221 pmic for various voltages. Signed-off-by: Oliver Schinagl oli...@schinagl.nl Signed-off-by: Hans de Goede hdego...@redhat.com -- Changes in v2: -Rebase Changes in v3: -Add support for all dldo and aldo-s -Add Kconfig option to select building AXP221 and to select voltage of dldo and aldo-s Changes in v4: -Add axp221_setbits helper function -Use symbolic names for enabled bits in CTRL1 - CTRL3 registers --- [...] diff --git a/include/axp221.h b/include/axp221.h new file mode 100644 index 000..e3b4409 --- /dev/null +++ b/include/axp221.h @@ -0,0 +1,50 @@ +/* + * (C) Copyright 2013 Oliver Schinagl oli...@schinagl.nl + * + * X-Powers AXP221 Power Management IC driver + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#define AXP221_CHIP_ADDR 0x68 +#define AXP221_CTRL_ADDR 0x3e +#define AXP221_INIT_DATA 0x3e + +#define AXP221_CHIP_ID 0x03 +#define AXP221_OUTPUT_CTRL10x10 +#define AXP221_OUTPUT_CTRL1_ALDO1_EN (1 6) +#define AXP221_OUTPUT_CTRL1_ALDO2_EN (1 7) +#define AXP221_OUTPUT_CTRL20x12 +#define AXP221_OUTPUT_CTRL2_DLDO1_EN (1 3) +#define AXP221_OUTPUT_CTRL2_DLDO2_EN (1 4) +#define AXP221_OUTPUT_CTRL2_DLDO3_EN (1 5) +#define AXP221_OUTPUT_CTRL2_DLDO4_EN (1 6) +#define AXP221_OUTPUT_CTRL2_DCDC1_EN (1 7) +#define AXP221_OUTPUT_CTRL30x13 +#define AXP221_OUTPUT_CTRL3_ALDO3_EN (1 7) +#define AXP221_DLDO1_CTRL 0x15 +#define AXP221_DLDO2_CTRL 0x16 +#define AXP221_DLDO3_CTRL 0x17 +#define AXP221_DLDO4_CTRL 0x18 +#define AXP221_DCDC1_CTRL 0x21 +#define AXP221_DCDC2_CTRL 0x22 +#define AXP221_DCDC3_CTRL 0x23 +#define AXP221_DCDC4_CTRL 0x24 +#define AXP221_DCDC5_CTRL 0x25 +#define AXP221_ALDO1_CTRL 0x28 +#define AXP221_ALDO2_CTRL 0x28 The register offset of ALDO2 seems to be incorrect here (same as ALDO1): http://linux-sunxi.org/AXP221#Reg_29h:_ALDO2_output_voltage In the current u-boot master, ALDO2 is only used by: configs/Mele_M9_defconfig:+S:CONFIG_AXP221_ALDO1_VOLT=3300 Ouch, good catch, I'll send a fix out right away and I'll try to get this included in v2015.01. Regards, Hans $ cat Mele_M9_defconfig CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI,SUNXI_GMAC CONFIG_FDTFILE=sun6i-a31-m9.dtb +S:CONFIG_ARM=y +S:CONFIG_ARCH_SUNXI=y +S:CONFIG_MACH_SUN6I=y +S:CONFIG_TARGET_MELE_M9=y # Ethernet phy power +S:CONFIG_AXP221_DLDO1_VOLT=3300 # USB hub power +S:CONFIG_AXP221_DLDO4_VOLT=3300 # Wifi power +S:CONFIG_AXP221_ALDO1_VOLT=3300 # HDMI power ? +S:CONFIG_AXP221_ALDO2_VOLT=1800 +S:CONFIG_AXP221_ALDO3_VOLT=3000 # Vbus gpio for usb1 +S:CONFIG_USB1_VBUS_PIN=PC27 # No Vbus gpio for usb2 +S:CONFIG_USB2_VBUS_PIN= It means that the code in boards/sunxi/board.c is likely to set 1.8V for ALDO1 instead of 3.3V: #if CONFIG_AXP221_ALDO1_VOLT != -1 power_failed |= axp221_set_aldo1(CONFIG_AXP221_ALDO1_VOLT); #endif #if CONFIG_AXP221_ALDO2_VOLT != -1 power_failed |= axp221_set_aldo2(CONFIG_AXP221_ALDO2_VOLT); #endif Does Wifi actually work on Mele M9? And if not, then is this something that needs to be fixed in the v2015.01 release? Also ALDO1/ALDO2 have much heavier use in the u-boot-sunxi next branch. +#define AXP221_ALDO3_CTRL 0x2a + +int axp221_set_dcdc1(unsigned int mvolt); +int axp221_set_dcdc2(unsigned int mvolt); +int axp221_set_dcdc3(unsigned int mvolt); +int axp221_set_dcdc4(unsigned int mvolt); +int axp221_set_dcdc5(unsigned int mvolt); +int axp221_set_dldo1(unsigned int mvolt); +int axp221_set_dldo2(unsigned int mvolt); +int axp221_set_dldo3(unsigned int mvolt); +int axp221_set_dldo4(unsigned int mvolt); +int axp221_set_aldo1(unsigned int mvolt); +int axp221_set_aldo2(unsigned int mvolt); +int axp221_set_aldo3(unsigned int mvolt); +int axp221_init(void); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] sunxi: video: Add lcd output support
Hi,
On 01-01-15 21:21, Siarhei Siamashka wrote:
On Wed, 31 Dec 2014 13:07:20 +0100
Hans de Goede hdego...@redhat.com wrote:
Add lcd output support, see the new Kconfig entries and doc/README.video for
how to enable / configure this.
Signed-off-by: Hans de Goede hdego...@redhat.com
snip
@@ -179,7 +178,21 @@ struct sunxi_hdmi_reg {
#define SUNXI_LCDC_CTRL_IO_MAP_TCON0 (0 0)
#define SUNXI_LCDC_CTRL_IO_MAP_TCON1 (1 0)
#define SUNXI_LCDC_CTRL_TCON_ENABLE (1 31)
+#define SUNXI_LCDC_FRAME_CTRL0_RGB666 ((1 31) | (0 4))
+#define SUNXI_LCDC_FRAME_CTRL0_RGB656 ((1 31) | (5 4))
This would be probably SUNXI_LCDC_FRAME_CTRL0_RGB565 according to
the Allwinner documentation of the TCON0_FRM_CTL_REG register:
0: 6bit frm output
1: 5bit frm output
Since we have 5 there (101 bit pattern), it simply means RGB565.
You're completely right, I took over the weird RGB656 naming from the
allwinner kernel code without thinking things through properly.
snip
+ bp = mode-vsync_len + mode-upper_margin;
+ total = mode-yres + mode-lower_margin + bp;
+ writel(SUNXI_LCDC_TCON0_TIMING_V_TOTAL(total) |
+ SUNXI_LCDC_TCON0_TIMING_V_BP(bp), lcdc-tcon0_timing_v);
+
+ writel(SUNXI_LCDC_X(mode-hsync_len) | SUNXI_LCDC_Y(mode-vsync_len),
+ lcdc-tcon0_timing_sync);
+
+ /* We only support hv-sync parallel lcd-s for now */
+ writel(0, lcdc-tcon0_hv_intf);
+ writel(0, lcdc-tcon0_cpu_intf);
+
+ if (sunxi_display.depth == 18 || sunxi_display.depth == 17) {
Here 17 is not quite correct for RGB565.
Right, this should be 16 meaning plain old RGB565, I've fixed both in
my personal tree. Thanks for pointing this out!
Also these are dithering settings, and this code just unconditionally
enables the right dithering for 16-bit LCD displays (this seems to
be never used in any real device from the sunxi-boards repository) or
18-bit LCD displays, which are very common.
Because 32-bit framebuffers support more colors than the 18-bit LCD
hardware can show, dithering is needed and used:
http://en.wikipedia.org/wiki/Frame_rate_control
Do we want to have a separate option to enable/disable dithering? Or
just keep it always enabled until somebody complains?
A simple program for testing dithering effects/usefulness can be found
here:
http://lists.denx.de/pipermail/u-boot/2015-January/200031.html
snip
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: axp221: Fix using the wrong register address for ALDO2
This fixes us never programming ALDO2, and programming the ALDO2 voltage into ALDo1. Reported-by: Siarhei Siamashka siarhei.siamas...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com --- include/axp221.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/axp221.h b/include/axp221.h index a6e52e3..e9552f6 100644 --- a/include/axp221.h +++ b/include/axp221.h @@ -43,7 +43,7 @@ #define AXP221_DCDC4_CTRL 0x24 #define AXP221_DCDC5_CTRL 0x25 #define AXP221_ALDO1_CTRL 0x28 -#define AXP221_ALDO2_CTRL 0x28 +#define AXP221_ALDO2_CTRL 0x29 #define AXP221_ALDO3_CTRL 0x2a #define AXP221_PAGE0xff -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2015.01 fix] sunxi: axp221: Fix using the wrong register address for ALDO2
Hi Ian (et al), Trivial patch fixing an important bug for the new sun6i / axp221 support in v2015.01, if someone can give me a quick ack, then I'll send a pull-req to Tom to get this included in v2015.01. Thanks Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Mainline U-Boot, EHCI, usbkbd not working (workaround)
Hi Hans, On 5 January 2015 at 00:10, Hans de Goede hdego...@redhat.com wrote: Hi, On 05-01-15 03:49, Simon Glass wrote: Hi Hans, On 4 January 2015 at 12:05, Hans de Goede hdego...@redhat.com wrote: Hi, On 04-01-15 19:21, B.R. Oake wrote: (This started on the linux-sunxi mailing list but will hopefully be of interest on the U-Boot list) On 04/01/15 13:45, Lars Doelle wrote: while testing with mainline u-boot, I came over the problem, that the USB keyboard is not recognized. The device is an A20-OLinuXIno-LIME2. I used the current A20-OLinuXino-Lime2_defconfig for building. In my understanding, the issue should be reproducible with all devices having an EHCI root hub. --- sun7i# usb reset (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... cannot reset port 1!? 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found sun7i# usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 2 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller --- As a workaround, i plugged an USB hub in between: [...] I also have this problem. I've tried three different USB keyboards on an A20-Olinuxino-Micro and a Banana Pi, and I always get that error cannot reset port N!? where N is whichever USB socket I've plugged it into, and U-Boot cannot see the keyboard. Once Linux has loaded, the keyboard works without any trouble. Can anyone suggest what is causing this? The problem is that u-boot does not allow building both ohci and ehci drivers into the same u-boot binary, so we cannot enable both usb-1 and usb-2 support at the same time. So we're stuck with having only usb-2 support until someone reworks u-boot's usb code, and keyboards and mice are typically usb-1 devices, the workaround for this is to plug in a usb-2 hub so that the board sees a usb-2 device, and then plug the mouse / keyboard into that hub. This could be solved by moving USB to driver model. Yes, that is what I was thinking too. Marek do you know if anyone is looking at this? Actually I was about to ask you (Simon) if you are looking into converting the usb stuff to dm, AFAIK no one else is working on this. I think Marek is busy for a while. I'd like to get PCI over the line first, and I have a few other things on my plate. But I think it would not be too difficult to move the usb_lowlevel_init() stuff into driver model. That would solve the primary problem I think. I'll see how things look later in the month. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: axp221: Fix using the wrong register address for ALDO2
On Mon, 2015-01-05 at 17:18 +0100, Hans de Goede wrote: This fixes us never programming ALDO2, and programming the ALDO2 voltage into ALDo1. Reported-by: Siarhei Siamashka siarhei.siamas...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk --- include/axp221.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/axp221.h b/include/axp221.h index a6e52e3..e9552f6 100644 --- a/include/axp221.h +++ b/include/axp221.h @@ -43,7 +43,7 @@ #define AXP221_DCDC4_CTRL0x24 #define AXP221_DCDC5_CTRL0x25 #define AXP221_ALDO1_CTRL0x28 -#define AXP221_ALDO2_CTRL0x28 +#define AXP221_ALDO2_CTRL0x29 #define AXP221_ALDO3_CTRL0x2a #define AXP221_PAGE 0xff ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] distro_distro_bootcmd: use CONFIG_BOOTCOMMAND instead of setting bootcmd=
Move the bootcmd commands into a seperate distro_bootcmd environment
variable. Allowing a user to easily launch the distro boot sequence if
the default bootcmd did not default to distro boot commands.
Also set CONFIG_BOOTCOMMAND to run distro_bootcmd if it hasn't been
configured yet rather then putting it directly in the environment. This
allows boards to make the distro boot commands available without
necessarily default to them or to use them as a fallback after running
some board specific commands instead.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
include/config_distro_bootcmd.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 68f5fcb..793e4d7 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -210,9 +210,14 @@
\
BOOT_TARGET_DEVICES(BOOTENV_DEV) \
\
- bootcmd= BOOTENV_SET_USB_NEED_INIT BOOTENV_SET_SCSI_NEED_INIT \
+ distro_bootcmd= BOOTENV_SET_USB_NEED_INIT \
+ BOOTENV_SET_SCSI_NEED_INIT\
for target in ${boot_targets}; do \
run bootcmd_${target}; \
done\0
+#ifndef CONFIG_BOOTCOMMAND
+#define CONFIG_BOOTCOMMAND run distro_bootcmd
+#endif
+
#endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] part: let list put the list in an environment variable
Add an optional third argument to the part list command which puts a
space seperated list of valid partitions into the given environment
variable. This is useful for allowing boot scripts to iterate of all
partitions of a device.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
common/cmd_part.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/common/cmd_part.c b/common/cmd_part.c
index 39e8666..c99f527 100644
--- a/common/cmd_part.c
+++ b/common/cmd_part.c
@@ -54,13 +54,31 @@ static int do_part_list(int argc, char * const argv[])
int ret;
block_dev_desc_t *desc;
- if (argc != 2)
+ if (argc 2 || argc 3)
return CMD_RET_USAGE;
ret = get_device(argv[0], argv[1], desc);
if (ret 0)
return 1;
+ if (argc == 3) {
+ int p;
+ char str[512] = { 0, };
+ disk_partition_t info;
+
+ for (p = 1; p 128; p++) {
+ int r = get_partition_info(desc, p, info);
+
+ if (r == 0) {
+ char t[5];
+ sprintf(t, %s%d, str[0] ? : , p);
+ strcat(str, t);
+ }
+ }
+ setenv(argv[2], str);
+ return 0;
+ }
+
print_part(desc);
return 0;
@@ -87,5 +105,7 @@ U_BOOT_CMD(
part uuid interface dev:part varname\n
- set environment variable to partition UUID\n
part list interface dev\n
- - print a device's partition table
+ - print a device's partition table\n
+ part list interface dev varname\n
+ - set environment variable to the list of partitions
);
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/22] x86: board_f: Adjust x86 boot order for performance
Hi,
On 5 January 2015 at 10:22, Graeme Russ gr...@tss-engineering.com wrote:
Hi Simon Bin,
On Tue, Jan 6, 2015 at 12:40 AM, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Mon, Jan 5, 2015 at 9:44 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 3 January 2015 at 20:26, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Fri, Jan 2, 2015 at 6:23 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 30 December 2014 at 22:51, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Sun, Dec 28, 2014 at 10:20 AM, Simon Glass s...@chromium.org
wrote:
For bare platforms we turn off ROM-caching before calling
board_init_f_r()
It is then very slow to copy U-Boot from ROM to RAM. So adjust the
order so
that the copying happens before we turn off ROM-caching.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_f.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 98c9c72..1b65575 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -983,6 +983,11 @@ static init_fnc_t init_sequence_f[] = {
INIT_FUNC_WATCHDOG_RESET
reloc_fdt,
setup_reloc,
+#ifdef CONFIG_X86
+ copy_uboot_to_ram,
+ clear_bss,
+ do_elf_reloc_fixups,
+#endif
#if !defined(CONFIG_ARM) !defined(CONFIG_SANDBOX)
jump_to_copy,
#endif
@@ -1042,9 +1047,6 @@ void board_init_f(ulong boot_flags)
*/
static init_fnc_t init_sequence_f_r[] = {
init_cache_f_r,
- copy_uboot_to_ram,
- clear_bss,
- do_elf_reloc_fixups,
NULL,
};
--
Wow, doesn't this bring back some memories. I've had a look over this code
as it is now and it took a while to sink in. Things have moved on in the
past 2 years :)
Nice to hear from you again!
I don't understand. Isn't the init_cache_f_r() which turns on the
cache?
Yes it turns on the cache, but turns off the ROM cache (they are
different things). So this ordering is much faster. I think I might
have more tuning to do though.
Got it. Since we moved these 3 routines from init_sequence_f_r[] to
init_sequence_f[], how about we remove the whole init_sequence_f_r[]
completely? If not possible, the comment block above
init_sequence_f_r[] needs to be fixed?
I'll remove the comment.
I think init_sequence_f_r can go... but I need to have a better look at the
code
If turning off the ROM cache by init_cache_f_r is the problem, then perhaps
the following order would be better:
copy_uboot_to_ram,
init_cache_f_r,
clear_bss,
do_elf_reloc_fixups,
Without enabling the CPU's cache, clear_bss and do_elf_reloc_fixups will
suffer.
Better would be to have init_cache_f_r after all this I think.
*
* The '_f_r' sequence must, as a minimum, copy U-Boot to RAM (if
* supported). It _should_, if possible, copy global data to RAM and
* initialise the CPU caches (to speed up the relocation process)
*
* NOTE: At present only x86 uses this route, but it is intended that
* all archs will move to this when generic relocation is implemented.
*/
So looks that we should either drop this _f_r stage, or make other
arch use this _f_r?
I think we should move to generic relocation, meaning that all archs
do relocation the same way with the same code. Then only arch-specific
stuff is the then ELF fixup function, which adjusts a relocation site,
and the code to actually change the stack pointer.
This was always my plan - have arch specific do_reloc_fixups and the rest
would be generic
This board_init_f_r() code is part of one attempt to do this - the
premise was that turning the cache on before relocating U-Boot will
save time. That's true, but it would be even better to turn the cache
on much earlier. With pit (Chromebook 2) we turn on the cache in SPL.
So I think turning it on here is too late if we are trying to save
time. Still it is a good start and if we could make it happen
generally it would be nice.
And now you have me thinking board_init_f_r is not needed at all...
If we can setup the stack, clear BSS, copy U-Boot to RAM and perform
relocation fixups while running from ROM, what is left for board_init_f_r to
do?
The only thing I can think of is the caveats mentioned in the comment
('static' variables are read-only / Global Data (gd-xxx) is read/write).
But aren't these true when running from ROM?
Looking at non-x86 arches, relocate_code() looks to do what
copy_uboot_to_ram and clear_bss does in x86 land (not sure about
do_elf_reloc_fixups - seems to be arch specific as to whether
relocate_code() does this or it is done later (hence the
CONFIG_NEEDS_MANUAL_RELOC #define?)
Yes this can be unified. There is still something in there though for
board_init_f_r(), at least as things are now. It just so happens on
x86 that we are
[U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files
Not all devices use the convention that the boot scripts are on the
first partition. For example on chromebooks it seems common for the
first two partitions to be ChromeOS kernel partitions.
So instead of just the first partition scan all partitions on a device
with a filesystem u-boot can recognize.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
include/config_distro_bootcmd.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index be616e8..68f5fcb 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -13,7 +13,7 @@
#define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
if #devtypel dev ${devnum}; then \
setenv devtype #devtypel ; \
- run scan_dev_for_boot; \
+ run scan_dev_for_boot_part; \
fi\0
#define BOOTENV_SHARED_BLKDEV(devtypel) \
@@ -163,7 +163,6 @@
boot_prefixes=/ /boot/\0 \
boot_scripts=boot.scr.uimg boot.scr\0 \
BOOTENV_BOOT_TARGETS \
- bootpart=1\0 \
\
boot_extlinux= \
sysboot ${devtype} ${devnum}:${bootpart} any\
@@ -194,12 +193,21 @@
done\0 \
\
scan_dev_for_boot= \
- echo Scanning ${devtype} ${devnum}...; \
+ echo Scanning ${devtype} ${devnum}:${bootpart}...; \
for prefix in ${boot_prefixes}; do \
run scan_dev_for_extlinux; \
run scan_dev_for_scripts; \
done\0 \
\
+ scan_dev_for_boot_part= \
+ part list ${devtype} ${devnum} devplist;\
+ for bootpart in ${devplist}; do \
+ if fstype ${devtype} ${devnum}:${bootpart} \
+ bootfstype; then\
+ run scan_dev_for_boot; \
+ fi; \
+ done\0 \
+ \
BOOT_TARGET_DEVICES(BOOTENV_DEV) \
\
bootcmd= BOOTENV_SET_USB_NEED_INIT BOOTENV_SET_SCSI_NEED_INIT \
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Let the distro boot command scan all partitions
Not all devices use the convention of the first partition holding the boot files. E.g. on chromebooks partition 1 and 2 are usually of the Chromeos kernel data type. So instead of hardcoding just the first partitions scan all partition on a storage device. First two patches add some supporting commands, which help in determining the list of partitions to scan and detect whether they have a known filesystem (No need to scan for a bunch of different fiels if the filesystem isn't supported). Third patch has the actual changes, while the last one tries to make it a bit easier for board files to include the distro boot commands even if they don't use it as their default. Sjoerd Simons (4): fs: Add command to retrieve the filesystem type part: let list put the list in an environment variable config_distro_bootcmd: Scan all partitions for boot files distro_distro_bootcmd: use CONFIG_BOOTCOMMAND instead of setting bootcmd= common/cmd_fs.c | 15 +++ common/cmd_part.c | 24 ++-- fs/fs.c | 27 +++ include/config_distro_bootcmd.h | 21 + include/fs.h| 6 ++ 5 files changed, 87 insertions(+), 6 deletions(-) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] fs: Add command to retrieve the filesystem type
New command to determine the filesystem type of a given partition.
Optionally stores the filesystem type in a environment variable.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
common/cmd_fs.c | 15 +++
fs/fs.c | 27 +++
include/fs.h| 6 ++
3 files changed, 48 insertions(+)
diff --git a/common/cmd_fs.c b/common/cmd_fs.c
index 0d9da11..e146254 100644
--- a/common/cmd_fs.c
+++ b/common/cmd_fs.c
@@ -81,3 +81,18 @@ U_BOOT_CMD(
- List files in directory 'directory' of partition 'part' on\n
device type 'interface' instance 'dev'.
)
+
+static int do_fstype_wrapper(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return do_fs_type(cmdtp, flag, argc, argv);
+}
+
+U_BOOT_CMD(
+ fstype, 4, 1, do_fstype_wrapper,
+ Look up a filesystem type,
+ interface dev:part\n
+ - print filesystem type\n
+ fstype interface dev:part varname\n
+ - set environment variable to filesystem type\n
+);
diff --git a/fs/fs.c b/fs/fs.c
index ddd751c..483273f 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -79,6 +79,7 @@ static inline int fs_uuid_unsupported(char *uuid_str)
struct fstype_info {
int fstype;
+ char *name;
/*
* Is it legal to pass NULL as .probe()'s fs_dev_desc parameter? This
* should be false in most cases. For virtual filesystems which
@@ -105,6 +106,7 @@ static struct fstype_info fstypes[] = {
#ifdef CONFIG_FS_FAT
{
.fstype = FS_TYPE_FAT,
+ .name = fat,
.null_dev_desc_ok = false,
.probe = fat_set_blk_dev,
.close = fat_close,
@@ -123,6 +125,7 @@ static struct fstype_info fstypes[] = {
#ifdef CONFIG_FS_EXT4
{
.fstype = FS_TYPE_EXT,
+ .name = ext4,
.null_dev_desc_ok = false,
.probe = ext4fs_probe,
.close = ext4fs_close,
@@ -141,6 +144,7 @@ static struct fstype_info fstypes[] = {
#ifdef CONFIG_SANDBOX
{
.fstype = FS_TYPE_SANDBOX,
+ .name = sandbox,
.null_dev_desc_ok = true,
.probe = sandbox_fs_set_blk_dev,
.close = sandbox_fs_close,
@@ -154,6 +158,7 @@ static struct fstype_info fstypes[] = {
#endif
{
.fstype = FS_TYPE_ANY,
+ .name = unsupported,
.null_dev_desc_ok = true,
.probe = fs_probe_unsupported,
.close = fs_close_unsupported,
@@ -190,6 +195,7 @@ int fs_set_blk_dev(const char *ifname, const char
*dev_part_str, int fstype)
if (!relocated) {
for (i = 0, info = fstypes; i ARRAY_SIZE(fstypes);
i++, info++) {
+ info-name += gd-reloc_off;
info-probe += gd-reloc_off;
info-close += gd-reloc_off;
info-ls += gd-reloc_off;
@@ -503,3 +509,24 @@ int do_fs_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[],
return CMD_RET_SUCCESS;
}
+
+int do_fs_type(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct fstype_info *info;
+
+ if (argc 3 || argc 4)
+ return CMD_RET_USAGE;
+
+ if (fs_set_blk_dev(argv[1], argv[2], FS_TYPE_ANY))
+ return 1;
+
+ info = fs_get_info(fs_type);
+
+ if (argc == 4)
+ setenv(argv[3], info-name);
+ else
+ printf(%s\n, info-name);
+
+ return CMD_RET_SUCCESS;
+}
+
diff --git a/include/fs.h b/include/fs.h
index ffb6ce7..fd1e4ab 100644
--- a/include/fs.h
+++ b/include/fs.h
@@ -109,4 +109,10 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[],
int do_fs_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype);
+/*
+ * Determine the type of the specified filesystem and print it. Optionally it
is
+ * possible to store the type directly in env.
+ */
+int do_fs_type(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
+
#endif /* _FS_H */
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] x86: Correct XIP_ROM_SIZE
On 1 January 2015 at 16:17, Simon Glass s...@chromium.org wrote: This should default to the size of the ROM for faster execution before relocation. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/22] x86: Drop RAMTOP Kconfig
On 3 January 2015 at 19:26, Bin Meng bmeng...@gmail.com wrote:
On Fri, Jan 2, 2015 at 7:17 AM, Simon Glass s...@chromium.org wrote:
We don't need this in U-Boot since we calculate it based on available memory.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Remove CONFIG_RAMTOP from mtrr.h in this patch
arch/x86/Kconfig| 4
arch/x86/include/asm/mtrr.h | 8
2 files changed, 12 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7d007bb..e992e64 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -47,10 +47,6 @@ config RAMBASE
hex
default 0x10
-config RAMTOP
- hex
- default 0x20
-
config XIP_ROM_SIZE
hex
default ROM_SIZE
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 5f05a48..dcc995d 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -100,10 +100,6 @@ static inline long x86_mtrr_rom_cache_var_index(void) {
return -1; }
#endif
-#if !defined(CONFIG_RAMTOP)
-# error CONFIG_RAMTOP not defined
-#endif
-
#if ((CONFIG_XIP_ROM_SIZE (CONFIG_XIP_ROM_SIZE - 1)) != 0)
# error CONFIG_XIP_ROM_SIZE is not a power of 2
#endif
@@ -114,8 +110,4 @@ static inline long x86_mtrr_rom_cache_var_index(void) {
return -1; }
#define CACHE_ROM_BASE (((1 20) - (CONFIG_CACHE_ROM_SIZE 12)) 12)
-#if (CONFIG_RAMTOP (CONFIG_RAMTOP - 1)) != 0
-# error CONFIG_RAMTOP must be a power of 2
-#endif
-
#endif
--
Reviewed-by: Bin Meng bmeng...@gmail.com
Applied to u-boot-x86/next.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/22] x86: Correct ifdtool microcode calculation
On 1 January 2015 at 16:17, Simon Glass s...@chromium.org wrote: This currently assumes that U-Boot resides at the start of ROM. Update it to remove this assumption. Signed-off-by: Simon Glass s...@chromium.org Tested-by: Bin Meng bmeng...@gmail.com --- Changes in v2: None tools/ifdtool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] x86: video: Add debug option to time the BIOS copy
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: This can be very slow - typically 80ms even on a fast machine since it uses the SPI flash to read the data. Add an option to display the time taken. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Bin Meng bmeng...@gmail.com --- Changes in v2: None drivers/pci/pci_rom.c | 3 +++ 1 file changed, 3 insertions(+) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] x86: ivybridge: Only run the Video BIOS when video is enabled
On 3 January 2015 at 19:31, Bin Meng bmeng...@gmail.com wrote:
On Fri, Jan 2, 2015 at 7:18 AM, Simon Glass s...@chromium.org wrote:
This takes about about 700ms on link when running natively and 900ms when
running using the emulator. It is a waste of time if video is not enabled,
so don't bother running the video BIOS in that case.
We could add a command to run the video BIOS later when needed, but this is
not considered at present.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use CONFIG_VIDEO directly to control running the video BIOS
arch/x86/cpu/ivybridge/gma.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/ivybridge/gma.c b/arch/x86/cpu/ivybridge/gma.c
index 3d7f740..cf4f87c 100644
--- a/arch/x86/cpu/ivybridge/gma.c
+++ b/arch/x86/cpu/ivybridge/gma.c
@@ -15,6 +15,7 @@
#include asm/pci.h
#include asm/arch/pch.h
#include asm/arch/sandybridge.h
+#include linux/kconfig.h
struct gt_powermeter {
u16 reg;
@@ -730,6 +731,9 @@ static int int15_handler(void)
int gma_func0_init(pci_dev_t dev, struct pci_controller *hose,
const void *blob, int node)
{
+#ifdef CONFIG_VIDEO
+ ulong start;
+#endif
void *gtt_bar;
u32 reg32;
int ret;
@@ -745,8 +749,11 @@ int gma_func0_init(pci_dev_t dev, struct pci_controller
*hose,
if (ret)
return ret;
+#ifdef CONFIG_VIDEO
+ start = get_timer(0);
ret = pci_run_vga_bios(dev, int15_handler, false);
-
+ debug(BIOS ran in %lums\n, get_timer(start));
+#endif
/* Post VBIOS init */
ret = gma_pm_init_post_vbios(gtt_bar, blob, node);
if (ret)
--
Reviewed-by: Bin Meng bmeng...@gmail.com
Applied to u-boot-x86/next.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/22] x86: Use cache, don't clear the display in video BIOS
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: There is no need to run with the cache disabled, and there is no point in clearing the display frame buffer since U-Boot does it later. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/x86/lib/bios.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/22] x86: pci: Don't return a vesa mode when there is not video
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: If the video has not been set up, we should not return a success code. This can be detected by seeing if any of the variables are non-zero. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/pci/pci_rom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] x86: video: Add a debug() to display the frame buffer address
On 1 January 2015 at 16:17, Simon Glass s...@chromium.org wrote: Provide a way to display this address when booting. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None drivers/video/x86_fb.c | 1 + 1 file changed, 1 insertion(+) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/22] x86: board_f: Adjust x86 boot order for performance
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: For bare platforms we turn off ROM-caching before calling board_init_f_r() It is then very slow to copy U-Boot from ROM to RAM. So adjust the order so that the copying happens before we turn off ROM-caching. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None common/board_f.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/22] x86: ivybridge: Set up an MTRR for the video frame buffer
On 3 January 2015 at 20:28, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Sun, Jan 4, 2015 at 11:20 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 3 January 2015 at 20:18, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Jan 2, 2015 at 7:18 AM, Simon Glass s...@chromium.org wrote: Set the frame buffer to write-combining. This makes it faster, although for scrolling write-through is even faster for U-Boot. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Remove definition of 'ulong start' from this patch arch/x86/cpu/ivybridge/gma.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/cpu/ivybridge/gma.c b/arch/x86/cpu/ivybridge/gma.c index cf4f87c..6cf9654 100644 --- a/arch/x86/cpu/ivybridge/gma.c +++ b/arch/x86/cpu/ivybridge/gma.c @@ -12,6 +12,7 @@ #include fdtdec.h #include pci_rom.h #include asm/io.h +#include asm/mtrr.h #include asm/pci.h #include asm/arch/pch.h #include asm/arch/sandybridge.h @@ -735,6 +736,7 @@ int gma_func0_init(pci_dev_t dev, struct pci_controller *hose, ulong start; #endif void *gtt_bar; + ulong base; u32 reg32; int ret; @@ -743,6 +745,11 @@ int gma_func0_init(pci_dev_t dev, struct pci_controller *hose, reg32 |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO; pci_write_config32(dev, PCI_COMMAND, reg32); + /* Use write-combining for the graphics memory, 256MB */ + base = pci_read_bar32(hose, dev, 2); + mtrr_add_request(MTRR_TYPE_WRCOMB, base, 256 20); + mtrr_commit(true); + gtt_bar = (void *)pci_read_bar32(pci_bus_to_hose(0), dev, 0); debug(GT bar %p\n, gtt_bar); ret = gma_pm_init_pre_vbios(gtt_bar); -- Do you have any comments regarding to what I said in http://lists.denx.de/pipermail/u-boot/2014-December/199955.html? Ah yes I meant to say that I did look at a function to return the BAR size, but it involves changing the BAR. I have a patch out to convert PCI to driver model and there we will be able to store the size. So perhaps we should revisit this later? Sounds good. Let's revisit it later. OK. I've pinged the PCI driver model thread, and will revisit soonish. Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/22] x86: ivybridge: Drop support for ROM caching
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: This is set up along with CAR (Cache-as-RAM) anyway. When we relocate we don't really need ROM caching (we read the VGA BIOS from ROM but that is about it) Drop it. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/x86/cpu/ivybridge/cpu.c | 25 - 1 file changed, 25 deletions(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/22] x86: Add support for MTRRs
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: Memory Type Range Registers are used to tell the CPU whether memory is cacheable and if so the cache write mode to use. Clean up the existing header file to follow style, and remove the unneeded code. These can speed up booting so should be supported. Add these to global_data so they can be requested while booting. We will apply the changes during relocation (in a later commit). Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/x86/cpu/Makefile | 1 + arch/x86/cpu/coreboot/coreboot.c | 22 +++--- arch/x86/cpu/ivybridge/car.S | 12 +-- arch/x86/cpu/mtrr.c| 81 +++ arch/x86/include/asm/global_data.h | 15 arch/x86/include/asm/mtrr.h| 157 + 6 files changed, 187 insertions(+), 101 deletions(-) create mode 100644 arch/x86/cpu/mtrr.c Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/22] x86: pci: Display vesa modes in hex
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: The hex value is more commonly understood, so use that instead of decimal. Add a 0x prefix to avoid confusion. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Bin Meng bmeng...@gmail.com --- Changes in v2: None drivers/pci/pci_rom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/22] x86: Tidy up VESA mode numbers
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: There are some bits which should be ignored when displaying the mode number. Make sure that they are not included in the mode that is displayed. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/x86/lib/bios.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: move EXPERT option under General setup menu
On Tue, Jan 06, 2015 at 12:37:24AM +0900, Masahiro YAMADA wrote: Tom, Is there any reason why this patch is not applied? Eh? $ git log --pretty=fuller 1bf0979f5ff4c297149a705d129ab8db4bec7763 -n1 commit 1bf0979f5ff4c297149a705d129ab8db4bec7763 Author: Tom Rini tr...@ti.com AuthorDate: Fri Nov 14 09:34:29 2014 +0100 Commit: Albert ARIBAUD albert.u.b...@aribaud.net CommitDate: Mon Nov 24 09:09:46 2014 +0100 Kconfig: Add EXPERT option For similar reasons to why the Linux Kernel has an EXPERT option, we too want an option to allow for tweaking of some options that while normally should remain hidden, may need to be changed in some cases. Signed-off-by: Tom Rini tr...@ti.com Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Hans de Goede hdego...@redhat.com Signed-off-by: Hans de Goede hdego...@redhat.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 22/22] x86: Add an 'mtrr' command to list and adjust MTRRs
On 3 January 2015 at 21:13, Bin Meng bmeng...@gmail.com wrote: On Fri, Jan 2, 2015 at 7:18 AM, Simon Glass s...@chromium.org wrote: It is useful to be able to see the MTRR setup in U-Boot. Add a command to list the state of the variable MTRR registers and allow them to be changed. Update the documentation to list some of the available commands. This does not support fixed MTRRs as yet. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Move cmd_mtrr to arch/x86/lib - Correct 'platform' typo arch/x86/lib/Makefile | 1 + arch/x86/lib/cmd_mtrr.c | 138 doc/README.x86 | 18 ++- 3 files changed, 156 insertions(+), 1 deletion(-) create mode 100644 arch/x86/lib/cmd_mtrr.c [snip] Tested-by: Bin Meng bmeng...@gmail.com Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/22] x86: ivybridge: Add a way to turn off the CAR
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: Cache-as-RAM should be turned off when we relocate since we want to run from RAM. Add a function to perform this task. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Remove unused Lhlt code - Use a simple 'ret' instruction to return arch/x86/cpu/ivybridge/car.S | 46 1 file changed, 46 insertions(+) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/22] x86: ivybridge: Request MTRRs for DRAM regions
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: We should use MTRRs to speed up execution. Add a list of MTRR requests which will dealt with when we relocate and run from RAM. We set RAM as cacheable (with write-back) and registers as non-cacheable. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/x86/cpu/ivybridge/sdram.c | 10 ++ 1 file changed, 10 insertions(+) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/22] x86: Commit the current MTRRs before relocation
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: Once we stop running from ROM we should set up the MTTRs to speed up execution. This is only needed for platforms that don't have an FSP. Also in the Coreboot case, the MTRRs are set up for us. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/x86/lib/init_helpers.c | 8 1 file changed, 8 insertions(+) Applied to u-boot-x86/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/22] x86: Disable CAR before relocation on platforms that need it
On 3 January 2015 at 20:53, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Jan 2, 2015 at 7:18 AM, Simon Glass s...@chromium.org wrote: For platforms with CAR we should disable it before relocation. Check if this function is available and call it if so. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Use a simple call instruction to call car_uninit arch/x86/cpu/start.S | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index 125782c..be8a2dc 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -205,6 +205,15 @@ board_init_f_r_trampoline: /* Setup global descriptor table so gd-xyz works */ callsetup_gdt + /* Set if we need to disable CAR */ +.weak car_uninit + movl$car_uninit, %eax + cmpl$0, %eax + jz 1f + + /* Pass return address in ebx */ The comment need to be fixed, or just simply remove this. Applied to u-boot-x86/next. (With comment removed) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 21/22] x86: ivybridge: Update microcode early in boot
On 1 January 2015 at 16:18, Simon Glass s...@chromium.org wrote: At present the normal update (which happens much later) does not work. This seems to have something to do with the 'no eviction' mode in the CAR, or at least moving the microcode update after that causes it not to work. For now, do an update early on so that it definitely works. Also refuse to continue unless the microcode update check (later in boot) is successful. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Use constants for microcode MSRs and header length Applied to u-boot-x86/next. arch/x86/cpu/ivybridge/car.S| 16 +++ arch/x86/cpu/ivybridge/cpu.c| 2 +- arch/x86/cpu/ivybridge/microcode_intel.c| 26 - arch/x86/dts/link.dts | 3 --- arch/x86/include/asm/arch-ivybridge/microcode.h | 6 ++ 5 files changed, 40 insertions(+), 13 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: build arch memset/memcpy in Thumb2 mode
Albert, I guess it is too late for that now. Thought it would make it into 2015.01, since your last comment in v2 suggested that you would treat it as bugfix... -- Stefan On 2014-12-18 18:10, Stefan Agner wrote: Resynchronize memcpy/memset with kernel 3.17 and build them in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). However, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. To build the files without warning, some assembler instructions had to be replaced with their UAL compliant variant (thanks Jeroen for this input). To build the file in Thumb2 mode the implicit-it=always option need to be set to generate Thumb2 compliant IT instructions where needed. We add this option to the general AFLAGS when building for Thumb2. Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Signed-off-by: Stefan Agner ste...@agner.ch --- arch/arm/config.mk | 4 +- arch/arm/include/asm/assembler.h | 33 ++-- arch/arm/lib/memcpy.S| 80 +++- arch/arm/lib/memset.S| 112 --- 4 files changed, 142 insertions(+), 87 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f0eafd6..9a4c270 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -26,7 +26,9 @@ PLATFORM_CPPFLAGS += -D__ARM__ # Choose between ARM/Thumb instruction sets ifeq ($(CONFIG_SYS_THUMB_BUILD),y) -PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ +AFLAGS_IMPLICIT_IT := $(call as-option,-Wa$(comma)-mimplicit-it=always) +PF_CPPFLAGS_ARM := $(AFLAGS_IMPLICIT_IT) \ + $(call cc-option, -mthumb -mthumb-interwork,\ $(call cc-option,-marm,)\ $(call cc-option,-mno-thumb-interwork,)\ ) diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 5e4789b..11b80fb 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -14,12 +14,14 @@ * assembler source. */ +#include config.h + /* * Endian independent macros for shifting bytes within registers. */ #ifndef __ARMEB__ -#define pull lsr -#define push lsl +#define lspull lsr +#define lspush lsl #define get_byte_0 lsl #0 #define get_byte_1 lsr #8 #define get_byte_2 lsr #16 @@ -29,8 +31,8 @@ #define put_byte_2 lsl #16 #define put_byte_3 lsl #24 #else -#define pull lsl -#define push lsr +#define lspull lsl +#define lspush lsr #define get_byte_0 lsr #24 #define get_byte_1 lsr #16 #define get_byte_2 lsr #8 @@ -54,7 +56,28 @@ #define PLD(code...) #endif + .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo + .macro ret\c, reg +#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) + mov\c pc, \reg +#else + .ifeqs \reg, lr + bx\c\reg + .else + mov\c pc, \reg + .endif +#endif + .endm + .endr + /* - * Cache alligned + * Cache aligned, used for optimized memcpy/memset + * In the kernel this is only enabled for Feroceon CPU's... + * We disable it especially for Thumb builds since those instructions + * are not made in a Thumb ready way... */ +#ifdef CONFIG_SYS_THUMB_BUILD +#define CALGN(code...) +#else #define CALGN(code...) code +#endif diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S index f655256..eeaf003 100644 --- a/arch/arm/lib/memcpy.S +++ b/arch/arm/lib/memcpy.S @@ -10,9 +10,14 @@ * published by the Free Software Foundation. */ +#include linux/linkage.h #include asm/assembler.h +#ifdef CONFIG_SYS_THUMB_BUILD +#define W(instr) instr.w +#else #define W(instr) instr +#endif #define LDR1W_SHIFT 0 #define STR1W_SHIFT 0 @@ -30,7 +35,7 @@ .endm .macro ldr1b ptr reg cond=al abort - ldr\cond\()b \reg, [\ptr], #1 + ldrb\cond\() \reg, [\ptr], #1 .endm .macro str1w ptr reg abort @@ -42,7 +47,7 @@ .endm .macro str1b ptr reg cond=al abort - str\cond\()b \reg, [\ptr], #1 + strb\cond\() \reg, [\ptr], #1 .endm .macro enter reg1 reg2 @@ -56,10 +61,12 @@ .text /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */ - -.globl memcpy -memcpy: - + .syntax unified +#ifdef CONFIG_SYS_THUMB_BUILD + .thumb + .thumb_func +#endif +ENTRY(memcpy) cmp r0, r1 moveq pc, lr @@ -79,7 +86,7 @@ memcpy: CALGN( ands
[U-Boot] mx25pdk does not boot with 3ff46cc42b9d7
Hi, I noticed that mx25pdk (ARM926) does not boot anymore with top of tree U-boot. Doing a git bisect resulted in the following commit as being the guilty one: commit 3ff46cc42b9d73d01c86df904425704410958470 Author: Georges Savoundararadj savou...@gmail.com Date: Tue Oct 28 23:16:11 2014 +0100 arm: relocate the exception vectors This commit relocates the exception vectors. As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For the other ARM processors, it copies the relocated exception vectors to the correct address: 0x or 0x. Signed-off-by: Georges Savoundararadj savou...@gmail.com Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Tom Warren twar...@nvidia.com Any ideas? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx25: Fix relocation by adding specific relocate_vectors
From: Fabio Estevam fabio.este...@freescale.com
Since commit (arm: relocate the exception vectors) mx25pdk hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: WDOG
Board: MX25PDK
I2C: ready
DRAM: 64 MiB
(hangs)
We need to add a specific relocate_vectors macro, just like it was done for
mx27 SoC in commit db544b9662622826b8 (imx: fix exception vectors relocation
in imx27).
This allows mx25 to boot again.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/arm926ejs/mx25/Makefile | 4 +++
arch/arm/cpu/arm926ejs/mx25/relocate.S | 51 ++
2 files changed, 55 insertions(+)
create mode 100644 arch/arm/cpu/arm926ejs/mx25/relocate.S
diff --git a/arch/arm/cpu/arm926ejs/mx25/Makefile
b/arch/arm/cpu/arm926ejs/mx25/Makefile
index 134c69d..ebc0407 100644
--- a/arch/arm/cpu/arm926ejs/mx25/Makefile
+++ b/arch/arm/cpu/arm926ejs/mx25/Makefile
@@ -5,3 +5,7 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y = generic.o timer.o reset.o
+
+ifndef CONFIG_SPL_BUILD
+obj-y += relocate.o
+endif
diff --git a/arch/arm/cpu/arm926ejs/mx25/relocate.S
b/arch/arm/cpu/arm926ejs/mx25/relocate.S
new file mode 100644
index 000..e0dfdee
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mx25/relocate.S
@@ -0,0 +1,51 @@
+/*
+ * relocate - i.MX25-specific vector relocation
+ *
+ * Copyright (c) 2013 Albert ARIBAUD albert.u.b...@aribaud.net
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm-offsets.h
+#include config.h
+#include linux/linkage.h
+
+/*
+ * The i.MX25 SoC is very specific with respect to exceptions: it
+ * does not provide RAM at the high vectors address (0x),
+ * thus only the low address (0x) is useable; but that is
+ * in ROM. Therefore, vectors cannot be changed at all.
+ *
+ * However, these ROM-based vectors actually just perform indirect
+ * calls through pointers located in RAM at SoC-specific addresses,
+ * as follows:
+ *
+ * Offset Exception Use by ROM code
+ * 0x reset indirect branch to [0x0014]
+ * 0x0004 undefined instruction indirect branch to [0xfef0]
+ * 0x0008 software interrupt indirect branch to [0xfef4]
+ * 0x000c prefetch abort indirect branch to [0xfef8]
+ * 0x0010 data abort indirect branch to [0xfefc]
+ * 0x0014 (reserved in ARMv5)vector to ROM reset: 0xc000
+ * 0x0018 IRQindirect branch to [0xff00]
+ * 0x001c FIQindirect branch to [0xff04]
+ *
+ * In order to initialize exceptions on i.MX25, we must copy U-Boot's
+ * indirect (not exception!) vector table into 0xfef0..0xff04
+ * taking care not to copy vectors number 5 (reserved exception).
+ */
+
+ .section.text.relocate_vectors,ax,%progbits
+
+ENTRY(relocate_vectors)
+
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ ldr r1, =32 /* size of vector table */
+ add r0, r0, r1 /* skip to indirect table */
+ ldr r1, =0xFEF0 /* i.MX25 indirect table */
+ ldmia r0!, {r2-r8}/* load indirect vectors 1..7 */
+ stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */
+
+ bx lr
+
+ENDPROC(relocate_vectors)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx25: Fix relocation by adding specific relocate_vectors
From: Fabio Estevam fabio.este...@freescale.com
Since commit (arm: relocate the exception vectors) mx25pdk hangs like this:
CPU: Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: WDOG
Board: MX25PDK
I2C: ready
DRAM: 64 MiB
(hangs)
We need to add a specific relocate_vectors macro, just like it was done for
mx27 SoC in commit db544b9662622826b8 (imx: fix exception vectors relocation
in imx27).
This allows mx25 to boot again.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/arm926ejs/mx25/Makefile | 4 +++
arch/arm/cpu/arm926ejs/mx25/relocate.S | 51 ++
2 files changed, 55 insertions(+)
create mode 100644 arch/arm/cpu/arm926ejs/mx25/relocate.S
diff --git a/arch/arm/cpu/arm926ejs/mx25/Makefile
b/arch/arm/cpu/arm926ejs/mx25/Makefile
index 134c69d..ebc0407 100644
--- a/arch/arm/cpu/arm926ejs/mx25/Makefile
+++ b/arch/arm/cpu/arm926ejs/mx25/Makefile
@@ -5,3 +5,7 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y = generic.o timer.o reset.o
+
+ifndef CONFIG_SPL_BUILD
+obj-y += relocate.o
+endif
diff --git a/arch/arm/cpu/arm926ejs/mx25/relocate.S
b/arch/arm/cpu/arm926ejs/mx25/relocate.S
new file mode 100644
index 000..e0dfdee
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mx25/relocate.S
@@ -0,0 +1,51 @@
+/*
+ * relocate - i.MX25-specific vector relocation
+ *
+ * Copyright (c) 2013 Albert ARIBAUD albert.u.b...@aribaud.net
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm-offsets.h
+#include config.h
+#include linux/linkage.h
+
+/*
+ * The i.MX25 SoC is very specific with respect to exceptions: it
+ * does not provide RAM at the high vectors address (0x),
+ * thus only the low address (0x) is useable; but that is
+ * in ROM. Therefore, vectors cannot be changed at all.
+ *
+ * However, these ROM-based vectors actually just perform indirect
+ * calls through pointers located in RAM at SoC-specific addresses,
+ * as follows:
+ *
+ * Offset Exception Use by ROM code
+ * 0x reset indirect branch to [0x0014]
+ * 0x0004 undefined instruction indirect branch to [0xfef0]
+ * 0x0008 software interrupt indirect branch to [0xfef4]
+ * 0x000c prefetch abort indirect branch to [0xfef8]
+ * 0x0010 data abort indirect branch to [0xfefc]
+ * 0x0014 (reserved in ARMv5)vector to ROM reset: 0xc000
+ * 0x0018 IRQindirect branch to [0xff00]
+ * 0x001c FIQindirect branch to [0xff04]
+ *
+ * In order to initialize exceptions on i.MX25, we must copy U-Boot's
+ * indirect (not exception!) vector table into 0xfef0..0xff04
+ * taking care not to copy vectors number 5 (reserved exception).
+ */
+
+ .section.text.relocate_vectors,ax,%progbits
+
+ENTRY(relocate_vectors)
+
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ ldr r1, =32 /* size of vector table */
+ add r0, r0, r1 /* skip to indirect table */
+ ldr r1, =0xFEF0 /* i.MX25 indirect table */
+ ldmia r0!, {r2-r8}/* load indirect vectors 1..7 */
+ stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */
+
+ bx lr
+
+ENDPROC(relocate_vectors)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx25pdk does not boot with 3ff46cc42b9d7
On 5 Jan 2015, feste...@gmail.com wrote: I noticed that mx25pdk (ARM926) does not boot anymore with top of tree U-boot. Doing a git bisect resulted in the following commit as being the guilty one: commit 3ff46cc42b9d73d01c86df904425704410958470 Author: Georges Savoundararadj savou...@gmail.com Date: Tue Oct 28 23:16:11 2014 +0100 arm: relocate the exception vectors This commit relocates the exception vectors. As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For the other ARM processors, it copies the relocated exception vectors to the correct address: 0x or 0x. Signed-off-by: Georges Savoundararadj savou...@gmail.com Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Tom Warren twar...@nvidia.com Any ideas? $ git show 3ff46cc42b9d73d01c86df9044257 /* * Default/weak exception vectors relocation routine * * This routine covers the standard ARM cases: normal (0x), * high (0x) and VBAR. SoCs which do not comply with any of * the standard cases must provide their own, strong, version. */ The code looks correct. However, the imx25 has the HAB and some default vectors set up. Do you assume they overwrite the HAB vectors? For the imx25, the 'V bit = 0' for the physical HAB ROM location, but it can be remapped to 0x. However, there is nothing there (0x) initially and this only makes sense with the MMU enabled. I am not sure what happened before; why it worked. Maybe you could define an empty relocate_vectors() in the imx25 board file and see if everything is ok? I don't think that a write to the ROM code will BUS error? If a write BUS errors, then the empty routine will work/boot. However, u-boot will not be handling the vectors unless we hook in the IRAM at 0x7801, where I guess the ROM code (at address zero) branches too. Fwiw, Bill Pringlemeir. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx25pdk does not boot with 3ff46cc42b9d7
Hi Bill, On Mon, Jan 5, 2015 at 8:25 PM, Bill Pringlemeir bpringlem...@nbsps.com wrote: $ git show 3ff46cc42b9d73d01c86df9044257 /* * Default/weak exception vectors relocation routine * * This routine covers the standard ARM cases: normal (0x), * high (0x) and VBAR. SoCs which do not comply with any of * the standard cases must provide their own, strong, version. */ The code looks correct. However, the imx25 has the HAB and some default vectors set up. Do you assume they overwrite the HAB vectors? For the imx25, the 'V bit = 0' for the physical HAB ROM location, but it can be remapped to 0x. However, there is nothing there (0x) initially and this only makes sense with the MMU enabled. I am not sure what happened before; why it worked. Maybe you could define an empty relocate_vectors() in the imx25 board file and see if everything is ok? I don't think that a write to the ROM code will BUS error? If a write BUS errors, then the empty routine will work/boot. However, u-boot will not be handling the vectors unless we hook in the IRAM at 0x7801, where I guess the ROM code (at address zero) branches too. I have just fixed by using the same approach done on mx27 with its own relocate.S: arch/arm/cpu/arm926ejs/mx27/relocate.S Will submit the patch shortly. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: designware_spi: Fix detecting FIFO depth
Current code tries to find the highest valid fifo depth by checking the value
it wrote to DW_SPI_TXFLTR. There are a few problems in current code:
1) There is an off-by-one in dws-fifo_len setting because it assumes the latest
register write fails so the latest valid value should be fifo - 1.
2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary
to test fifo == 257. In the case fifo is 257, it means the latest valid
setting is fifo = 256. So after the for loop iteration, we should check
fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails.
This patch fixes above issues.
Signed-off-by: Axel Lin axel@ingics.com
---
The same fix is already applied to linux-spi tree:
http://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/commit/?h=for-linusid=d297933cc7fcfbaaf2d37570baac73287bf0357d
This patch replaces my previous patch:
http://lists.denx.de/pipermail/u-boot/2014-December/199228.html
drivers/spi/designware_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 98c9f03..0210667 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -164,13 +164,13 @@ static void spi_hw_init(struct dw_spi_priv *priv)
if (!priv-fifo_len) {
u32 fifo;
- for (fifo = 2; fifo = 257; fifo++) {
+ for (fifo = 2; fifo = 256; fifo++) {
dw_writew(priv, DW_SPI_TXFLTR, fifo);
if (fifo != dw_readw(priv, DW_SPI_TXFLTR))
break;
}
- priv-fifo_len = (fifo == 257) ? 0 : fifo;
+ priv-fifo_len = (fifo == 2) ? 0 : fifo - 1;
dw_writew(priv, DW_SPI_TXFLTR, 0);
}
debug(%s: fifo_len=%d\n, __func__, priv-fifo_len);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: coreboot: Set up timer base correctly
On 5 January 2015 at 08:27, Bin Meng bmeng...@gmail.com wrote: If coreboot is built with CONFIG_COLLECT_TIMESTAMPS, use the value of base_time in coreboot's timestamp table as our timer base, otherwise TSC counter value will be used. Sometimes even coreboot is built with CONFIG_COLLECT_TIMESTAMPS, the value of base_time in the timestamp table is still zero, so we must exclude this case too (this is currently seen on booting coreboot in qemu). Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Fix the CONFIG_COLLECT_TIMESTAMPS typo in the comment block and commit message Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/12] x86: Allow a hardcoded TSC frequency provided by Kconfig
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: By default U-Boot automatically calibrates TSC running frequency via MSR and PIT. The calibration may not work on every x86 processor, so a new Kconfig option CONFIG_TSC_CALIBRATION_BYPASS is introduced to allow bypassing the calibration and assign a hardcoded TSC frequency CONFIG_TSC_FREQ_IN_MHZ. Normally the bypass should be turned on in a simulation environment like qemu. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Spell out TSC, MSR and PIT in the Kconfig help Acked-by: Simon Glass s...@chromium.org arch/x86/Kconfig | 20 arch/x86/lib/tsc_timer.c | 8 ++-- 2 files changed, 26 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/12] x86: Move CONFIG_SYS_CAR_xxx to Kconfig
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Move CONFIG_SYS_CAR_ADDR and CONFIG_SYS_CAR_SIZE to Kconfig so that we don't need them in the board configuration file thus the same board configuratoin file can be used to build both coreboot version and bare version. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to move CONFIG_SYS_CAR_xxx to Kconfig board/coreboot/coreboot/Kconfig | 12 board/google/chromebook_link/Kconfig | 8 include/configs/chromebook_link.h| 4 ++-- 3 files changed, 22 insertions(+), 2 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/12] x86: coreboot: Move coreboot specific defines from coreboot.h to Kconfig
Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: nit: coreboot-specific defines There are many places in the U-Boot source tree which refer to CONFIG_SYS_COREBOOT, CONFIG_CBMEM_CONSOLE and CONFIG_VIDEO_COREBOOT that is currently defined in coreboot.h. Move them to arch/x86/cpu/coreboot/Kconfig so that we can switch to board configuration file to build U-Boot later. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to move coreboot specific defines from coreboot.h to Kconfig arch/x86/Kconfig | 2 ++ arch/x86/cpu/coreboot/Kconfig | 11 +++ 2 files changed, 13 insertions(+) create mode 100644 arch/x86/cpu/coreboot/Kconfig diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1fabcce..01943e8 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -347,6 +347,8 @@ config TSC_FREQ_IN_MHZ help The running frequency in MHz of Time-Stamp Counter (TSC). +source arch/x86/cpu/coreboot/Kconfig + source arch/x86/cpu/ivybridge/Kconfig source arch/x86/cpu/queensbay/Kconfig diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig new file mode 100644 index 000..d1454c5 --- /dev/null +++ b/arch/x86/cpu/coreboot/Kconfig @@ -0,0 +1,11 @@ I think you need if TARGET_COREBOOT ... endif around this. We don't wan to use coreboot for chromebook_link, for example. +config SYS_COREBOOT + bool + default y + +config CBMEM_CONSOLE + bool + default y + +config VIDEO_COREBOOT + bool + default y \ No newline at end of file -- 1.8.2.1 Also you should remove these options from include/configs/coreboot.h to avoid build errors. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/12] x86: Make chromebook_link the default board for coreboot
Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Change SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE to chromebook_link which is currently the only real board officially supported to run U-Boot loaded by coreboot. Note the symbolic link file chromebook_link.dts is deleted and link.dts is renamed to chromebook_link.dts. To avoid multiple definition of video_hw_init, the CONFIG_VIDEO_X86 define needs to be moved to arch/x86/cpu/ivybridge/Kconfig. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to make chromebook_link the default board for coreboot arch/x86/cpu/ivybridge/Kconfig| 8 ++ arch/x86/dts/Makefile | 3 +- arch/x86/dts/chromebook_link.dts | 220 +- arch/x86/dts/link.dts | 219 - board/coreboot/coreboot/Kconfig | 4 +- configs/coreboot-x86_defconfig| 1 - include/configs/chromebook_link.h | 1 - 7 files changed, 230 insertions(+), 226 deletions(-) mode change 12 = 100644 arch/x86/dts/chromebook_link.dts delete mode 100644 arch/x86/dts/link.dts diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig index afca957..9c0259c 100644 --- a/arch/x86/cpu/ivybridge/Kconfig +++ b/arch/x86/cpu/ivybridge/Kconfig @@ -152,6 +152,14 @@ config ENABLE_VMX will be unable to support virtualisation, or it will run very slowly. +config VIDEO_X86 + bool Enable x86 video driver support + default y + help + Turn on this option to enable a very simple driver which uses vesa + to discover the video mode and then provides a frame buffer for use + by U-Boot. + I think this should be in drivers/video/Kconfig. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/12] x86: coreboot: Wrap cros_ec initialization
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: cros_ec_board_init() should be called only when CONFIG_CROS_EC is enabled. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Leave CROS_EC defines unchanged in coreboot.h board/coreboot/coreboot/coreboot.c | 2 ++ 1 file changed, 2 insertions(+) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/12] x86: coreboot: Configure pci memory regions
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Configure coreboot pci memory regions so that pci device drivers could work correctly. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to configure pci memory regions arch/x86/cpu/coreboot/pci.c | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) Acked-by: Simon Glass s...@chromium.org At some point much of this code could go into arch/x86/lib/pci_type1.c or similar since ivybridge is common. Let's see how things land first. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/12] x86: Remove include/configs/coreboot.h
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Since we already swtiched to use the new mechanism for building U-Boot for coreboot, coreboot.h is no longer needed so remove it. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to remove include/configs/coreboot.h board/coreboot/coreboot/MAINTAINERS | 2 +- include/configs/coreboot.h | 75 - 2 files changed, 1 insertion(+), 76 deletions(-) delete mode 100644 include/configs/coreboot.h Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/12] x86: Update REAME.x86 for coreboot support
Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Update README.x86 to include new build instructions for U-Boot as the coreboot payload and testing considerations with coreboot. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to update REAME.x86 for coreboot support doc/README.x86 | 35 +++ 1 file changed, 35 insertions(+) Looks good. Acked-by: Simon Glass s...@chromium.org What method are you using to boot a kernel? I'm wondering how we document use cases like booting Ubuntu, booting from different boot devices, etc. Mostly this is zImage but we could link to x86-fit-boot.txt also. There is a syslinux approach used by many ARM boards now - e.g. see rpi.h which includes config_distro_defaults.h. Should we enable this for x86 too? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/12] x86: Hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: When CONFIG_X86_RESET_VECTOR is not selected, specifying the ROM chip size is meaningless, hence hide it. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 76dc02d..1fabcce 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -94,6 +94,7 @@ config BOARD_ROMSIZE_KB_16384 choice prompt ROM chip size + depends on X86_RESET_VECTOR default UBOOT_ROMSIZE_KB_512 if BOARD_ROMSIZE_KB_512 default UBOOT_ROMSIZE_KB_1024 if BOARD_ROMSIZE_KB_1024 default UBOOT_ROMSIZE_KB_2048 if BOARD_ROMSIZE_KB_2048 -- 1.8.2.1 Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/12] x86: Move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Convert CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig options so that we can remove them from board configuration file. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig arch/x86/Kconfig | 9 + board/google/chromebook_link/Kconfig | 1 + board/intel/crownbay/Kconfig | 1 + include/configs/chromebook_link.h| 2 -- include/configs/crownbay.h | 2 -- 5 files changed, 11 insertions(+), 4 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/12] x86: coreboot: Make SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE configurable
On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: In theory U-Boot built for coreboot is supposed to run as a payload to be loaded by coreboot on every board that coreboot supports. The U-Boot build process uses SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE which are hardcoded in board defconfig and Kconfig files. For better support of coreboot, we want to make these two options configurable so that we can easily change them during 'make menuconfig' so that the generated U-Boot image for coreboot is board configuration aware. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to make SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE configurable board/coreboot/coreboot/Kconfig | 13 + 1 file changed, 13 insertions(+) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx25: Fix relocation by adding specific relocate_vectors
On Mon, Jan 5, 2015 at 8:41 PM, Fabio Estevam feste...@gmail.com wrote:
+ENTRY(relocate_vectors)
+
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ ldr r1, =32 /* size of vector table */
+ add r0, r0, r1 /* skip to indirect table */
+ ldr r1, =0xFEF0 /* i.MX25 indirect table */
+ ldmia r0!, {r2-r8}/* load indirect vectors 1..7 */
+ stmia r1!, {r2-r5, r7,r8} /* write all but vector 5 */
+
+ bx lr
+
+ENDPROC(relocate_vectors)
If I simply do like this:
ENTRY(relocate_vectors)
bxlr
ENDPROC(relocate_vectors)
,then it also boots fine. So maybe we don't even need to do the
relocation on mx25?
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86.git branch misc
Hi Tom, This didn't go through last time, it is on branch 'misc'. The following changes since commit d622ac39274a949b6445f1bfd92dc1644014388b: powerpc: mpc824x: remove MPC824X cpu support (2015-01-05 12:08:55 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 9332274989009b213a405134202088e1bd81fe51: cros-ec-keyboard: Synchronize DT binding from linux (2015-01-05 17:45:16 -0700) Masahiro Yamada (2): dm: README: recommend u-boot.dtb to try driver-model on sandbox i2c_eeprom: include linux/err.h to fix build error Sjoerd Simons (1): cros-ec-keyboard: Synchronize DT binding from linux arch/arm/dts/exynos5250-snow.dts| 59 +++ arch/arm/dts/exynos5420-peach-pit.dts | 59 +++ arch/arm/dts/exynos5800-peach-pi.dts| 4 +++- doc/device-tree-bindings/input/cros-ec-keyb.txt | 53 +++-- doc/driver-model/README.txt | 4 ++-- drivers/input/cros_ec_keyb.c| 16 ++-- drivers/misc/i2c_eeprom.c | 1 + 7 files changed, 41 insertions(+), 155 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git branch misc
Hi Tom, On 29 December 2014 at 19:26, Tom Rini tr...@ti.com wrote: On Mon, Dec 29, 2014 at 03:07:41PM -0700, Simon Glass wrote: Hi Tom, Here are a few misc fixes and updates. Note that the branch is 'misc' (there is also a 'master' branch pull out there). The following changes since commit d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 90f20e002e16c53f7857740a5e6baaa7183f584c: cros-ec-keyboard: Synchronize DT binding from linux (2014-12-29 15:02:02 -0700) Applied to u-boot/master, thanks! Sorry for the delay - I was just looking and could not see this pull request applied. I will rebase and send a new pull request. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/12] x86: Make chromebook_link the default board for coreboot
Hi Simon, On Tue, Jan 6, 2015 at 9:50 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Change SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE to chromebook_link which is currently the only real board officially supported to run U-Boot loaded by coreboot. Note the symbolic link file chromebook_link.dts is deleted and link.dts is renamed to chromebook_link.dts. To avoid multiple definition of video_hw_init, the CONFIG_VIDEO_X86 define needs to be moved to arch/x86/cpu/ivybridge/Kconfig. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to make chromebook_link the default board for coreboot arch/x86/cpu/ivybridge/Kconfig| 8 ++ arch/x86/dts/Makefile | 3 +- arch/x86/dts/chromebook_link.dts | 220 +- arch/x86/dts/link.dts | 219 - board/coreboot/coreboot/Kconfig | 4 +- configs/coreboot-x86_defconfig| 1 - include/configs/chromebook_link.h | 1 - 7 files changed, 230 insertions(+), 226 deletions(-) mode change 12 = 100644 arch/x86/dts/chromebook_link.dts delete mode 100644 arch/x86/dts/link.dts diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig index afca957..9c0259c 100644 --- a/arch/x86/cpu/ivybridge/Kconfig +++ b/arch/x86/cpu/ivybridge/Kconfig @@ -152,6 +152,14 @@ config ENABLE_VMX will be unable to support virtualisation, or it will run very slowly. +config VIDEO_X86 + bool Enable x86 video driver support + default y + help + Turn on this option to enable a very simple driver which uses vesa + to discover the video mode and then provides a frame buffer for use + by U-Boot. + I think this should be in drivers/video/Kconfig OK, will fix. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/12] x86: coreboot: Move coreboot specific defines from coreboot.h to Kconfig
Hi Simon, On Tue, Jan 6, 2015 at 9:50 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: nit: coreboot-specific defines OK. There are many places in the U-Boot source tree which refer to CONFIG_SYS_COREBOOT, CONFIG_CBMEM_CONSOLE and CONFIG_VIDEO_COREBOOT that is currently defined in coreboot.h. Move them to arch/x86/cpu/coreboot/Kconfig so that we can switch to board configuration file to build U-Boot later. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to move coreboot specific defines from coreboot.h to Kconfig arch/x86/Kconfig | 2 ++ arch/x86/cpu/coreboot/Kconfig | 11 +++ 2 files changed, 13 insertions(+) create mode 100644 arch/x86/cpu/coreboot/Kconfig diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1fabcce..01943e8 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -347,6 +347,8 @@ config TSC_FREQ_IN_MHZ help The running frequency in MHz of Time-Stamp Counter (TSC). +source arch/x86/cpu/coreboot/Kconfig + source arch/x86/cpu/ivybridge/Kconfig source arch/x86/cpu/queensbay/Kconfig diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig new file mode 100644 index 000..d1454c5 --- /dev/null +++ b/arch/x86/cpu/coreboot/Kconfig @@ -0,0 +1,11 @@ I think you need if TARGET_COREBOOT ... endif around this. We don't wan to use coreboot for chromebook_link, for example. Yes, will fix. +config SYS_COREBOOT + bool + default y + +config CBMEM_CONSOLE + bool + default y + +config VIDEO_COREBOOT + bool + default y \ No newline at end of file -- 1.8.2.1 Also you should remove these options from include/configs/coreboot.h to avoid build errors. The coreboot.h is removed in the follow-up patch in this series. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: move EXPERT option under General setup menu
Hi Tom, Please see my patch carefully. http://patchwork.ozlabs.org/patch/415041/ Your commit (1bf0979f5ff4c297) added the expert menu at the root menu. Mine moves it under the General setup menu like Linux. On Mon, 5 Jan 2015 12:41:56 -0500 Tom Rini tr...@ti.com wrote: On Tue, Jan 06, 2015 at 12:37:24AM +0900, Masahiro YAMADA wrote: Tom, Is there any reason why this patch is not applied? Eh? $ git log --pretty=fuller 1bf0979f5ff4c297149a705d129ab8db4bec7763 -n1 commit 1bf0979f5ff4c297149a705d129ab8db4bec7763 Author: Tom Rini tr...@ti.com AuthorDate: Fri Nov 14 09:34:29 2014 +0100 Commit: Albert ARIBAUD albert.u.b...@aribaud.net CommitDate: Mon Nov 24 09:09:46 2014 +0100 Kconfig: Add EXPERT option For similar reasons to why the Linux Kernel has an EXPERT option, we too want an option to allow for tweaking of some options that while normally should remain hidden, may need to be changed in some cases. Signed-off-by: Tom Rini tr...@ti.com Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Hans de Goede hdego...@redhat.com Signed-off-by: Hans de Goede hdego...@redhat.com -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/12] x86: Update REAME.x86 for coreboot support
Hi Bin, On 5 January 2015 at 19:31, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Jan 6, 2015 at 9:50 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: Update README.x86 to include new build instructions for U-Boot as the coreboot payload and testing considerations with coreboot. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to update REAME.x86 for coreboot support doc/README.x86 | 35 +++ 1 file changed, 35 insertions(+) Looks good. Acked-by: Simon Glass s...@chromium.org Thanks for the fast response as always! Sorry, but I have to respin this patch due to I've found 3 typos (REAME.x86, aginst, u-boot-dtb.in) myself this morning. I must have had my brain cells tired last night :- What method are you using to boot a kernel? I'm wondering how we document use cases like booting Ubuntu, booting from different boot devices, etc. Mostly this is zImage but we could link to x86-fit-boot.txt also. I am using zboot to boot a kernel bzImage with initramfs and nfs mounted as root. I have not tried to boot any distro out there. There is a syslinux approach used by many ARM boards now - e.g. see rpi.h which includes config_distro_defaults.h. Should we enable this for x86 too? I will have a look. If we consider supporting syslinux, how about other bootloaders like grub? Could do, I'm not sure how to run it, but I suppose it's not that hard. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/12] x86: coreboot: Move coreboot specific defines from coreboot.h to Kconfig
Hi Simon, On Tue, Jan 6, 2015 at 10:38 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 5 January 2015 at 19:14, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Tue, Jan 6, 2015 at 9:50 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 5 January 2015 at 08:28, Bin Meng bmeng...@gmail.com wrote: nit: coreboot-specific defines OK. There are many places in the U-Boot source tree which refer to CONFIG_SYS_COREBOOT, CONFIG_CBMEM_CONSOLE and CONFIG_VIDEO_COREBOOT that is currently defined in coreboot.h. Move them to arch/x86/cpu/coreboot/Kconfig so that we can switch to board configuration file to build U-Boot later. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to move coreboot specific defines from coreboot.h to Kconfig arch/x86/Kconfig | 2 ++ arch/x86/cpu/coreboot/Kconfig | 11 +++ 2 files changed, 13 insertions(+) create mode 100644 arch/x86/cpu/coreboot/Kconfig diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 1fabcce..01943e8 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -347,6 +347,8 @@ config TSC_FREQ_IN_MHZ help The running frequency in MHz of Time-Stamp Counter (TSC). +source arch/x86/cpu/coreboot/Kconfig + source arch/x86/cpu/ivybridge/Kconfig source arch/x86/cpu/queensbay/Kconfig diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig new file mode 100644 index 000..d1454c5 --- /dev/null +++ b/arch/x86/cpu/coreboot/Kconfig @@ -0,0 +1,11 @@ I think you need if TARGET_COREBOOT ... endif around this. We don't wan to use coreboot for chromebook_link, for example. Yes, will fix. +config SYS_COREBOOT + bool + default y + +config CBMEM_CONSOLE + bool + default y + +config VIDEO_COREBOOT + bool + default y \ No newline at end of file -- 1.8.2.1 Also you should remove these options from include/configs/coreboot.h to avoid build errors. The coreboot.h is removed in the follow-up patch in this series. Yes I see that, but then this patch will break the build - we do try to keep things bisectable, so that you can check out any commit and build it (in extremis it is OK if it doesn't actually work fully though). Understood, will fix. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/12] x86: coreboot: Set up timer base correctly
If coreboot is built with CONFIG_COLLECT_TIMESTAMPS, use the value
of base_time in coreboot's timestamp table as our timer base,
otherwise TSC counter value will be used.
Sometimes even coreboot is built with CONFIG_COLLECT_TIMESTAMPS,
the value of base_time in the timestamp table is still zero, so
we must exclude this case too (this is currently seen on booting
coreboot in qemu).
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Fix the CONFIG_COLLECT_TIMESTAMPS typo in the comment block
and commit message
arch/x86/cpu/coreboot/timestamp.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/cpu/coreboot/timestamp.c
b/arch/x86/cpu/coreboot/timestamp.c
index bd3558a..0edee6b 100644
--- a/arch/x86/cpu/coreboot/timestamp.c
+++ b/arch/x86/cpu/coreboot/timestamp.c
@@ -3,18 +3,7 @@
*
* Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ * SPDX-License-Identifier:GPL-2.0+
*/
#include common.h
@@ -38,9 +27,27 @@ static struct timestamp_table *ts_table
__attribute__((section(.data)));
void timestamp_init(void)
{
+#ifdef CONFIG_SYS_X86_TSC_TIMER
+ uint64_t base_time;
+#endif
+
ts_table = lib_sysinfo.tstamp_table;
#ifdef CONFIG_SYS_X86_TSC_TIMER
- timer_set_base(ts_table-base_time);
+ /*
+* If coreboot is built with CONFIG_COLLECT_TIMESTAMPS, use the value
+* of base_time in coreboot's timestamp table as our timer base,
+* otherwise TSC counter value will be used.
+*
+* Sometimes even coreboot is built with CONFIG_COLLECT_TIMESTAMPS,
+* the value of base_time in the timestamp table is still zero, so
+* we must exclude this case too (this is currently seen on booting
+* coreboot in qemu)
+*/
+ if (ts_table ts_table-base_time)
+ base_time = ts_table-base_time;
+ else
+ base_time = rdtsc();
+ timer_set_base(base_time);
#endif
timestamp_add_now(TS_U_BOOT_INITTED);
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 02/12] x86: Allow a hardcoded TSC frequency provided by Kconfig
By default U-Boot automatically calibrates TSC running frequency via
MSR and PIT. The calibration may not work on every x86 processor, so
a new Kconfig option CONFIG_TSC_CALIBRATION_BYPASS is introduced to
allow bypassing the calibration and assign a hardcoded TSC frequency
CONFIG_TSC_FREQ_IN_MHZ.
Normally the bypass should be turned on in a simulation environment
like qemu.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Spell out TSC, MSR and PIT in the Kconfig help
arch/x86/Kconfig | 20
arch/x86/lib/tsc_timer.c | 8 ++--
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ebf72b3..4bd945e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -317,6 +317,26 @@ config FRAMEBUFFER_VESA_MODE
endmenu
+config TSC_CALIBRATION_BYPASS
+ bool Bypass Time-Stamp Counter (TSC) calibration
+ default n
+ help
+ By default U-Boot automatically calibrates Time-Stamp Counter (TSC)
+ running frequency via Model-Specific Register (MSR) and Programmable
+ Interval Timer (PIT). If the calibration does not work on your board,
+ select this option and provide a hardcoded TSC running frequency with
+ CONFIG_TSC_FREQ_IN_MHZ below.
+
+ Normally this option should be turned on in a simulation environment
+ like qemu.
+
+config TSC_FREQ_IN_MHZ
+ int Time-Stamp Counter (TSC) running frequency in MHz
+ depends on TSC_CALIBRATION_BYPASS
+ default 1000
+ help
+ The running frequency in MHz of Time-Stamp Counter (TSC).
+
source arch/x86/cpu/ivybridge/Kconfig
source arch/x86/cpu/queensbay/Kconfig
diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c
index fb9afed..7f5ba2c 100644
--- a/arch/x86/lib/tsc_timer.c
+++ b/arch/x86/lib/tsc_timer.c
@@ -78,7 +78,7 @@ static int match_cpu(u8 family, u8 model)
*
* Returns the calibration value or 0 if MSR calibration failed.
*/
-static unsigned long try_msr_calibrate_tsc(void)
+static unsigned long __maybe_unused try_msr_calibrate_tsc(void)
{
u32 lo, hi, ratio, freq_id, freq;
unsigned long res;
@@ -199,7 +199,7 @@ static inline int pit_expect_msb(unsigned char val, u64
*tscp,
#define MAX_QUICK_PIT_MS 50
#define MAX_QUICK_PIT_ITERATIONS (MAX_QUICK_PIT_MS * PIT_TICK_RATE / 1000 /
256)
-static unsigned long quick_pit_calibrate(void)
+static unsigned long __maybe_unused quick_pit_calibrate(void)
{
int i;
u64 tsc, delta;
@@ -306,6 +306,9 @@ unsigned __attribute__((no_instrument_function)) long
get_tbclk_mhz(void)
if (gd-arch.tsc_mhz)
return gd-arch.tsc_mhz;
+#ifdef CONFIG_TSC_CALIBRATION_BYPASS
+ fast_calibrate = CONFIG_TSC_FREQ_IN_MHZ;
+#else
fast_calibrate = try_msr_calibrate_tsc();
if (!fast_calibrate) {
@@ -313,6 +316,7 @@ unsigned __attribute__((no_instrument_function)) long
get_tbclk_mhz(void)
if (!fast_calibrate)
panic(TSC frequency is ZERO);
}
+#endif
gd-arch.tsc_mhz = fast_calibrate;
return fast_calibrate;
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/12] x86: Update README.x86 for coreboot support
Hi, On Tue, Jan 6, 2015 at 12:20 PM, Bin Meng bmeng...@gmail.com wrote: Update README.x86 to include new build instructions for U-Boot as the coreboot payload and testing considerations with coreboot. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Fix several typos in README.x86 Oops, wrong 'Series-changes' version. Should be v3. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 09/12] x86: Make chromebook_link the default board for coreboot
Change SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE to chromebook_link
which is currently the only real board officially supported to run
U-Boot loaded by coreboot.
Note the symbolic link file chromebook_link.dts is deleted and
link.dts is renamed to chromebook_link.dts.
To avoid multiple definition of video_hw_init, the CONFIG_VIDEO_X86
define needs to be moved to arch/x86/cpu/ivybridge/Kconfig.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
Changes in v4:
- Rebase to u-boot-x86/next
Changes in v3:
- Move CONFIG_VIDEO_X86 to drivers/video/Kconfig
Changes in v2:
- New patch to make chromebook_link the default board for coreboot
arch/x86/dts/Makefile | 3 +-
arch/x86/dts/chromebook_link.dts | 217 +-
arch/x86/dts/link.dts | 216 -
board/coreboot/coreboot/Kconfig | 4 +-
configs/chromebook_link_defconfig | 1 +
configs/coreboot-x86_defconfig| 1 -
drivers/video/Kconfig | 8 ++
include/configs/chromebook_link.h | 1 -
8 files changed, 228 insertions(+), 223 deletions(-)
mode change 12 = 100644 arch/x86/dts/chromebook_link.dts
delete mode 100644 arch/x86/dts/link.dts
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index 5525094..97ed884 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -1,5 +1,4 @@
-dtb-y += link.dtb \
- chromebook_link.dtb \
+dtb-y += chromebook_link.dtb \
crownbay.dtb
targets += $(dtb-y)
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
deleted file mode 12
index 6f8c5cd..000
--- a/arch/x86/dts/chromebook_link.dts
+++ /dev/null
@@ -1 +0,0 @@
-link.dts
\ No newline at end of file
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
new file mode 100644
index 000..9490b16
--- /dev/null
+++ b/arch/x86/dts/chromebook_link.dts
@@ -0,0 +1,216 @@
+/dts-v1/;
+
+/include/ skeleton.dtsi
+/include/ serial.dtsi
+
+/ {
+ model = Google Link;
+ compatible = google,link, intel,celeron-ivybridge;
+
+ config {
+ silent_console = 0;
+ };
+
+ gpioa {
+ compatible = intel,ich6-gpio;
+ u-boot,dm-pre-reloc;
+ reg = 0 0x10;
+ bank-name = A;
+ };
+
+ gpiob {
+ compatible = intel,ich6-gpio;
+ u-boot,dm-pre-reloc;
+ reg = 0x30 0x10;
+ bank-name = B;
+ };
+
+ gpioc {
+ compatible = intel,ich6-gpio;
+ u-boot,dm-pre-reloc;
+ reg = 0x40 0x10;
+ bank-name = C;
+ };
+
+ chosen {
+ stdout-path = /serial;
+ };
+
+ spd {
+ compatible = memory-spd;
+ #address-cells = 1;
+ #size-cells = 0;
+ elpida_4Gb_1600_x16 {
+ reg = 0;
+ data = [92 10 0b 03 04 19 02 02
+ 03 52 01 08 0a 00 fe 00
+ 69 78 69 3c 69 11 18 81
+ 20 08 3c 3c 01 40 83 81
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 0f 11 42 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 02 fe 00
+ 11 52 00 00 00 07 7f 37
+ 45 42 4a 32 30 55 47 36
+ 45 42 55 30 2d 47 4e 2d
+ 46 20 30 20 02 fe 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00];
+ };
+ samsung_4Gb_1600_1.35v_x16 {
+ reg = 1;
+ data = [92 11 0b 03 04 19 02 02
+ 03 11 01 08 0a 00 fe 00
+ 69 78 69 3c 69
[U-Boot] [PATCH v4 05/12] x86: coreboot: Make SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE configurable
In theory U-Boot built for coreboot is supposed to run as a payload to be loaded by coreboot on every board that coreboot supports. The U-Boot build process uses SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE which are hardcoded in board defconfig and Kconfig files. For better support of coreboot, we want to make these two options configurable so that we can easily change them during 'make menuconfig' so that the generated U-Boot image for coreboot is board configuration aware. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org --- Changes in v4: None Changes in v3: None Changes in v2: - New patch to make SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE configurable board/coreboot/coreboot/Kconfig | 13 + 1 file changed, 13 insertions(+) diff --git a/board/coreboot/coreboot/Kconfig b/board/coreboot/coreboot/Kconfig index 6ca6ced..e5ccf58 100644 --- a/board/coreboot/coreboot/Kconfig +++ b/board/coreboot/coreboot/Kconfig @@ -9,7 +9,20 @@ config SYS_VENDOR config SYS_SOC default coreboot +comment coreboot-specific options + config SYS_CONFIG_NAME + string Board configuration file default coreboot + help + This option selects the board configuration file in include/configs/ + directory to be used to build U-Boot for coreboot. + +config DEFAULT_DEVICE_TREE + string Board Device Tree Source (dts) file + default link + help + This option selects the board Device Tree Source (dts) file in + arch/x86/dts/ directory to be used to build U-Boot for coreboot. endif -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 10/12] x86: coreboot: Wrap cros_ec initialization
cros_ec_board_init() should be called only when CONFIG_CROS_EC is
enabled.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Leave CROS_EC defines unchanged in coreboot.h
board/coreboot/coreboot/coreboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/coreboot/coreboot/coreboot.c
b/board/coreboot/coreboot/coreboot.c
index 154faf6..e076ea6 100644
--- a/board/coreboot/coreboot/coreboot.c
+++ b/board/coreboot/coreboot/coreboot.c
@@ -10,8 +10,10 @@
int arch_early_init_r(void)
{
+#ifdef CONFIG_CROS_EC
if (cros_ec_board_init())
return -1;
+#endif
return 0;
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/12] x86: Better support of coreboot
In theory U-Boot built for coreboot is supposed to run as a payload to be loaded by coreboot on every board that coreboot supports. The U-Boot build process uses SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE which are hardcoded in board defconfig and Kconfig files. For better support of coreboot, we want to make these two options configurable so that we can easily change them during 'make menuconfig' so that the generated U-Boot image for coreboot is board configuration aware. Note v2/v3/v4 patch series aims to better support coreboot, while v1 patch series just tried to resolve the issues seen on qemu. Several issues are fixed to make coreboot support in U-Boot more robust. See v1 patch discussion @ http://lists.denx.de/pipermail/u-boot/2015-January/200140.html The official qemu U-Boot support will come in the future. This patch series have been tested with coreboot running on qemu and Intel Crown Bay (my own unofficiall simple port, not in coreboot mainline) then loading the U-Boot built with the new mechanism. Changes in v4: - Rebase to u-boot-x86/next Changes in v3: - Make coreboot options wrapped by TARGET_COREBOOT - Remove these options from include/configs/coreboot.h for bisectability - Move CONFIG_VIDEO_X86 to drivers/video/Kconfig - Fix several typos in README.x86 Changes in v2: - Fix the CONFIG_COLLECT_TIMESTAMPS typo in the comment block and commit message - Spell out TSC, MSR and PIT in the Kconfig help - New patch to move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig - New patch to hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected - New patch to make SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE configurable - New patch to move coreboot specific defines from coreboot.h to Kconfig - New patch to move CONFIG_SYS_CAR_xxx to Kconfig - New patch to remove include/configs/coreboot.h - New patch to make chromebook_link the default board for coreboot - Leave CROS_EC defines unchanged in coreboot.h - New patch to configure pci memory regions - New patch to update REAME.x86 for coreboot support Bin Meng (12): x86: coreboot: Set up timer base correctly x86: Allow a hardcoded TSC frequency provided by Kconfig x86: Move CONFIG_X86_RESET_VECTOR and CONFIG_SYS_X86_START16 to Kconfig x86: Hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected x86: coreboot: Make SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE configurable x86: coreboot: Move coreboot-specific defines from coreboot.h to Kconfig x86: Move CONFIG_SYS_CAR_xxx to Kconfig x86: Remove include/configs/coreboot.h x86: Make chromebook_link the default board for coreboot x86: coreboot: Wrap cros_ec initialization x86: coreboot: Configure pci memory regions x86: Update README.x86 for coreboot support arch/x86/Kconfig | 32 ++ arch/x86/cpu/coreboot/Kconfig| 15 +++ arch/x86/cpu/coreboot/pci.c | 30 - arch/x86/cpu/coreboot/timestamp.c| 33 +++--- arch/x86/dts/Makefile| 3 +- arch/x86/dts/chromebook_link.dts | 217 ++- arch/x86/dts/link.dts| 216 -- arch/x86/lib/tsc_timer.c | 8 +- board/coreboot/coreboot/Kconfig | 27 - board/coreboot/coreboot/MAINTAINERS | 2 +- board/coreboot/coreboot/coreboot.c | 2 + board/google/chromebook_link/Kconfig | 9 ++ board/intel/crownbay/Kconfig | 1 + configs/chromebook_link_defconfig| 1 + configs/coreboot-x86_defconfig | 1 - doc/README.x86 | 39 ++- drivers/video/Kconfig| 8 ++ include/configs/chromebook_link.h| 7 +- include/configs/coreboot.h | 75 include/configs/crownbay.h | 2 - 20 files changed, 405 insertions(+), 323 deletions(-) create mode 100644 arch/x86/cpu/coreboot/Kconfig mode change 12 = 100644 arch/x86/dts/chromebook_link.dts delete mode 100644 arch/x86/dts/link.dts delete mode 100644 include/configs/coreboot.h -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 04/12] x86: Hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected
When CONFIG_X86_RESET_VECTOR is not selected, specifying the ROM chip size is meaningless, hence hide it. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org --- Changes in v4: None Changes in v3: None Changes in v2: - New patch to hide ROM chip size when CONFIG_X86_RESET_VECTOR is not selected arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ba0c1aa..25f6a7b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -90,6 +90,7 @@ config BOARD_ROMSIZE_KB_16384 choice prompt ROM chip size + depends on X86_RESET_VECTOR default UBOOT_ROMSIZE_KB_512 if BOARD_ROMSIZE_KB_512 default UBOOT_ROMSIZE_KB_1024 if BOARD_ROMSIZE_KB_1024 default UBOOT_ROMSIZE_KB_2048 if BOARD_ROMSIZE_KB_2048 -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 11/12] x86: coreboot: Configure pci memory regions
Configure coreboot pci memory regions so that pci device drivers
could work correctly.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch to configure pci memory regions
arch/x86/cpu/coreboot/pci.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/coreboot/pci.c b/arch/x86/cpu/coreboot/pci.c
index 6a3dd93..c9983f1 100644
--- a/arch/x86/cpu/coreboot/pci.c
+++ b/arch/x86/cpu/coreboot/pci.c
@@ -13,6 +13,8 @@
#include pci.h
#include asm/pci.h
+DECLARE_GLOBAL_DATA_PTR;
+
static void config_pci_bridge(struct pci_controller *hose, pci_dev_t dev,
struct pci_config_table *table)
{
@@ -35,7 +37,31 @@ void board_pci_setup_hose(struct pci_controller *hose)
hose-first_busno = 0;
hose-last_busno = 0;
- pci_set_region(hose-regions + 0, 0x0, 0x0, 0x,
+ /* PCI memory space */
+ pci_set_region(hose-regions + 0,
+ CONFIG_PCI_MEM_BUS,
+ CONFIG_PCI_MEM_PHYS,
+ CONFIG_PCI_MEM_SIZE,
PCI_REGION_MEM);
- hose-region_count = 1;
+
+ /* PCI IO space */
+ pci_set_region(hose-regions + 1,
+ CONFIG_PCI_IO_BUS,
+ CONFIG_PCI_IO_PHYS,
+ CONFIG_PCI_IO_SIZE,
+ PCI_REGION_IO);
+
+ pci_set_region(hose-regions + 2,
+ CONFIG_PCI_PREF_BUS,
+ CONFIG_PCI_PREF_PHYS,
+ CONFIG_PCI_PREF_SIZE,
+ PCI_REGION_PREFETCH);
+
+ pci_set_region(hose-regions + 3,
+ 0,
+ 0,
+ gd-ram_size,
+ PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
+
+ hose-region_count = 4;
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 12/12] x86: Update README.x86 for coreboot support
Update README.x86 to include new build instructions for U-Boot as the coreboot payload and testing considerations with coreboot. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org --- Changes in v4: None Changes in v3: - Fix several typos in README.x86 Changes in v2: - New patch to update REAME.x86 for coreboot support doc/README.x86 | 39 +-- 1 file changed, 37 insertions(+), 2 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index b474161..7df8cc5 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -32,6 +32,21 @@ on other architectures, like below: $ make coreboot-x86_defconfig $ make all +Note this default configuration will build a U-Boot payload for the Link board. +To build a coreboot payload against another board, you can change the build +configuration during the 'make menuconfig' process. + +x86 architecture --- + ... + (chromebook_link) Board configuration file + (chromebook_link) Board Device Tree Source (dts) file + (0x1920) Board specific Cache-As-RAM (CAR) address + (0x4000) Board specific Cache-As-RAM (CAR) size + +Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' +to point to a new board. You can also change the Cache-As-RAM (CAR) related +settings here if the default values do not fit your new board. + Building ROM version of U-Boot (hereafter referred to as u-boot.rom) is a little bit tricky, as generally it requires several binary blobs which are not shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is @@ -88,11 +103,31 @@ in this FSP package too. Rename the first one to fsp.bin and second one to cmc.bin and put them in the board directory. -Now you can build U-Boot and obtaim u-boot.rom +Now you can build U-Boot and obtain u-boot.rom $ make crownbay_defconfig $ make all +Test with coreboot +-- +For testing U-Boot as the coreboot payload, there are things that need be paid +attention to. coreboot supports loading an ELF executable and a 32-bit plain +binary, as well as other supported payloads. With the default configuration, +U-Boot is set up to use a separate Device Tree Blob (dtb). As of today, the +generated u-boot-dtb.bin needs to be packaged by the cbfstool utility (a tool +provided by coreboot) manually as coreboot's 'make menuconfig' does not provide +this capability yet. The command is as follows: + +# in the coreboot root directory +$ ./build/util/cbfstool/cbfstool build/coreboot.rom add-flat-binary \ + -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x111 -e 0x1110015 + +Make sure 0x111 matches CONFIG_SYS_TEXT_BASE and 0x1110015 matches the +symbol address of _start (in arch/x86/cpu/start.S). + +If you want to use ELF as the coreboot payload, change U-Boot configuration to +use CONFIG_OF_EMBED. + CPU Microcode - Modern CPU usually requires a special bit stream called microcode [5] to be @@ -106,7 +141,7 @@ x86 has been converted to use driver model for serial and GPIO. Device Tree --- x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to -be turned on. Not every device on the board is configured via devie tree, but +be turned on. Not every device on the board is configured via device tree, but more and more devices will be added as time goes by. Check out the directory arch/x86/dts/ for these device tree source files. -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
