Re: [U-Boot] board: add support for Vision System's Baltos Industrial PC
On Wed, May 27, 2015 at 11:54 PM, Tom Rini wrote: > On Tue, May 12, 2015 at 05:16:32PM -0500, Felipe Balbi wrote: > >> From: Yegor Yefremov >> >> Vision Systems's Baltos is based on AM335x SoC >> from Texas Instruments. This patch adds support >> such Industrial PCs in mainline u-boot. >> >> [ ba...@ti.com: updated original patch to current u-boot ] >> >> Signed-off-by: Yegor Yefremov >> Signed-off-by: Felipe Balbi > > This needs a rebase to fix problems like: > #error "Serial is required before relocation - define CONFIG_SYS_MALLOC_F_LEN > to make this work" > And: > warning: implicit declaration of function 'is_valid_ether_addr' > [-Wimplicit-function-declaration] > (and the resulting link failure). Will do. Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: missing CONFIG_NET after consolidation patches
Hello Stefano, Am 27.05.2015 11:29, schrieb Stefano Babic: commit fd3056337e6fcc140f400e11edd33f6f1cb37de1 "Use env callbacks for net variables" has a side effect on i.MX6 boards because they do not set CONFIG_NET: the ip address results not set, but it is stored in the environment. => pri ipaddr ipaddr=192.168.178.66 => ping 192.168.178.1 *** ERROR: `ipaddr' not set ping failed; host 192.168.178.1 is not alive Setting CONFIG_NET solves this issue. Reported-by: Heiko Schoker s/ok/och ;-) Signed-off-by: Stefano Babic --- include/configs/mx6_common.h | 3 +++ 1 file changed, 3 insertions(+) Thanks! bye, Heiko diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 233c6d2..3d859cf 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -105,4 +105,7 @@ #define CONFIG_FSL_ESDHC #define CONFIG_FSL_USDHC +/* NET */ +#define CONFIG_NET + #endif -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk 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
[U-Boot] [PATCH v2] am33xx, spl, siemens: enable debug uart output again
a6b541b090: TI ARMv7: Don't use GD before crt0.S has set it
moves the init of the debug uart at the very end of SPL code.
Enable it for the siemens board earlier, as they print
ddr settings ... all debug output before board_init_r()
is here currently useless. Maybe we must rework this
globally?
Signed-off-by: Heiko Schocher
---
Changes in v2:
- rebase against current mainline 2e2ce6c0c8d3
- resend as patchwork misses the commit message
board/siemens/common/board.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/siemens/common/board.c b/board/siemens/common/board.c
index a39cbd0..c127f6c 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board.c
@@ -43,6 +43,11 @@ void set_mux_conf_regs(void)
/* Initalize the board header */
enable_i2c0_pin_mux();
i2c_set_bus_num(0);
+
+ /* enable early the console */
+ gd->baudrate = CONFIG_BAUDRATE;
+ serial_init();
+ gd->have_console = 1;
if (read_eeprom() < 0)
puts("Could not get board ID.\n");
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Simon, On Thu, May 28, 2015 at 10:55 AM, Simon Glass wrote: > HI Bin, > > On May 27, 2015 8:41 PM, "Bin Meng" wrote: >> >> Hi Simon, >> >> On Thu, May 28, 2015 at 7:25 AM, Simon Glass wrote: >> > Hi, >> > >> > On 27 May 2015 at 10:27, Joe Hershberger >> > wrote: >> >> >> >> Hi Bin, >> >> >> >> On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: >> >> > Hi Joe, >> >> > >> >> > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger >> >> > wrote: >> >> >> Hi Bin, >> >> >> >> >> >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng >> >> >> wrote: >> >> >>> Hi Simon, >> >> >>> >> >> >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng >> >> >>> wrote: >> >> Commit bd328eb "Clean all defconfigs with savedefconfig" >> >> accidentally >> >> removed 'CONFIG_VENDOR_COREBOOT=y' from >> >> configs/coreboot-x86_defconfig. >> >> This commit reverts the change. >> >> >> >> Signed-off-by: Bin Meng >> >> --- >> >> >> >> configs/coreboot-x86_defconfig | 1 + >> >> 1 file changed, 1 insertion(+) >> >> >> >> diff --git a/configs/coreboot-x86_defconfig >> >> b/configs/coreboot-x86_defconfig >> >> index 66f94d0..799853f 100644 >> >> --- a/configs/coreboot-x86_defconfig >> >> +++ b/configs/coreboot-x86_defconfig >> >> @@ -1,4 +1,5 @@ >> >> CONFIG_X86=y >> >> +CONFIG_VENDOR_COREBOOT=y >> >> CONFIG_TARGET_COREBOOT=y >> >> CONFIG_OF_CONTROL=y >> >> CONFIG_DM_PCI=y >> >> -- >> >> >>> >> >> >>> Please apply this patch after commit >> >> >>> >> >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf >> >> >>> and before commit >> >> >>> >> >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. >> >> >>> I've verified the build with buildman on a new 'testing' branch >> >> >>> with >> >> >>> insertion of this patch. >> >> >> >> >> >> This should be squashed as part of >> >> >> >> >> >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc >> >> >> >> >> >> You need to remember to run savedefconfig when changing Kconfig or >> >> >> defconfig. >> >> >> >> >> > >> >> > I still don't get it. commit 65c4ac0 introduced >> >> > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb >> >> > to clean up the defconfig. I suspect there was something wrong with >> >> > 'savedefconfig'? >> >> >> >> No, savedefconfig is doing exactly what it should. Before your patch, >> >> CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. >> >> Therefore savedefconfig sees it as redundant to specify that in the >> >> defconfig as well, so it removed it. When you change that explicit >> >> default to something else, it is up to you to change the defconfigs of >> >> the old and new default boards. >> >> >> >> Your other option is to stop defining a default in the Kconfig and >> >> instead mark the choice as "optional" (like I did for many other >> >> selections like this that had no default explicitly - Kconfig >> >> otherwise treats the first entry as default in that case) in which >> >> case all defconfigs must have a specified vendor. >> > >> > OK I've squashed that in and pushed to u-boot-x86/testing. If it looks >> > OK I'll pull it into master. >> > >> >> It looks OK. Another thing, I noticed this patch [1] is not in the >> testing branch. Did you apply it to somewhere else? > > I was worried that it was submitted after the merge window and affects other > code. OK, understood. But I think it is safe to remove given no board is using it. >> >> [1] http://patchwork.ozlabs.org/patch/472988/ >> Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Joe, On Thu, May 28, 2015 at 7:51 AM, Joe Hershberger wrote: > Hi Simon, > > On Wed, May 27, 2015 at 6:25 PM, Simon Glass wrote: >> Hi, >> >> On 27 May 2015 at 10:27, Joe Hershberger wrote: >>> >>> Hi Bin, >>> >>> On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: >>> > Hi Joe, >>> > >>> > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger >>> > wrote: >>> >> Hi Bin, >>> >> >>> >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: >>> >>> Hi Simon, >>> >>> >>> >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: >>> Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally >>> removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. >>> This commit reverts the change. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> configs/coreboot-x86_defconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/configs/coreboot-x86_defconfig >>> b/configs/coreboot-x86_defconfig >>> index 66f94d0..799853f 100644 >>> --- a/configs/coreboot-x86_defconfig >>> +++ b/configs/coreboot-x86_defconfig >>> @@ -1,4 +1,5 @@ >>> CONFIG_X86=y >>> +CONFIG_VENDOR_COREBOOT=y >>> CONFIG_TARGET_COREBOOT=y >>> CONFIG_OF_CONTROL=y >>> CONFIG_DM_PCI=y >>> -- >>> >>> >>> >>> Please apply this patch after commit >>> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf >>> >>> and before commit >>> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. >>> >>> I've verified the build with buildman on a new 'testing' branch with >>> >>> insertion of this patch. >>> >> >>> >> This should be squashed as part of >>> >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc >>> >> >>> >> You need to remember to run savedefconfig when changing Kconfig or >>> >> defconfig. >>> >> >>> > >>> > I still don't get it. commit 65c4ac0 introduced >>> > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb >>> > to clean up the defconfig. I suspect there was something wrong with >>> > 'savedefconfig'? >>> >>> No, savedefconfig is doing exactly what it should. Before your patch, >>> CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. >>> Therefore savedefconfig sees it as redundant to specify that in the >>> defconfig as well, so it removed it. When you change that explicit >>> default to something else, it is up to you to change the defconfigs of >>> the old and new default boards. >>> Thanks for the explanation. Now it is clear to me. >>> Your other option is to stop defining a default in the Kconfig and >>> instead mark the choice as "optional" (like I did for many other >>> selections like this that had no default explicitly - Kconfig >>> otherwise treats the first entry as default in that case) in which >>> case all defconfigs must have a specified vendor. >> >> OK I've squashed that in and pushed to u-boot-x86/testing. If it looks >> OK I'll pull it into master. > > It should also include removing the (now) redundant > CONFIG_VENDOR_EMULATION from that defconfig. That is best done by > running savedefconfig on that defconfig after applying the "x86: Make > QEMU the default vendor" patch. > > Bin, are you in the middle of this? > Yes, now we should remove CONFIG_VENDOR_EMULATION from configs/qemu-x86_defconfig. But if removing this, I feel this is inconsistent with other x86 boards' defconfig. Is this really a must-have to replace the defconfig with the one generated by 'savedefconfig'? If so, can we make it part of checkpatch.pl so that each time we submit the patch which contains modifications to the defconfig we can make sure the file is clean? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
HI Bin, On May 27, 2015 8:41 PM, "Bin Meng" wrote: > > Hi Simon, > > On Thu, May 28, 2015 at 7:25 AM, Simon Glass wrote: > > Hi, > > > > On 27 May 2015 at 10:27, Joe Hershberger wrote: > >> > >> Hi Bin, > >> > >> On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: > >> > Hi Joe, > >> > > >> > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger > >> > wrote: > >> >> Hi Bin, > >> >> > >> >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: > >> >>> Hi Simon, > >> >>> > >> >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: > >> Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally > >> removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. > >> This commit reverts the change. > >> > >> Signed-off-by: Bin Meng > >> --- > >> > >> configs/coreboot-x86_defconfig | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig > >> index 66f94d0..799853f 100644 > >> --- a/configs/coreboot-x86_defconfig > >> +++ b/configs/coreboot-x86_defconfig > >> @@ -1,4 +1,5 @@ > >> CONFIG_X86=y > >> +CONFIG_VENDOR_COREBOOT=y > >> CONFIG_TARGET_COREBOOT=y > >> CONFIG_OF_CONTROL=y > >> CONFIG_DM_PCI=y > >> -- > >> >>> > >> >>> Please apply this patch after commit > >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf > >> >>> and before commit > >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc . > >> >>> I've verified the build with buildman on a new 'testing' branch with > >> >>> insertion of this patch. > >> >> > >> >> This should be squashed as part of > >> >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc > >> >> > >> >> You need to remember to run savedefconfig when changing Kconfig or defconfig. > >> >> > >> > > >> > I still don't get it. commit 65c4ac0 introduced > >> > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb > >> > to clean up the defconfig. I suspect there was something wrong with > >> > 'savedefconfig'? > >> > >> No, savedefconfig is doing exactly what it should. Before your patch, > >> CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. > >> Therefore savedefconfig sees it as redundant to specify that in the > >> defconfig as well, so it removed it. When you change that explicit > >> default to something else, it is up to you to change the defconfigs of > >> the old and new default boards. > >> > >> Your other option is to stop defining a default in the Kconfig and > >> instead mark the choice as "optional" (like I did for many other > >> selections like this that had no default explicitly - Kconfig > >> otherwise treats the first entry as default in that case) in which > >> case all defconfigs must have a specified vendor. > > > > OK I've squashed that in and pushed to u-boot-x86/testing. If it looks > > OK I'll pull it into master. > > > > It looks OK. Another thing, I noticed this patch [1] is not in the > testing branch. Did you apply it to somewhere else? I was worried that it was submitted after the merge window and affects other code. > > [1] http://patchwork.ozlabs.org/patch/472988/ > > Regards, > Bin Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Simon, On Thu, May 28, 2015 at 7:25 AM, Simon Glass wrote: > Hi, > > On 27 May 2015 at 10:27, Joe Hershberger wrote: >> >> Hi Bin, >> >> On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: >> > Hi Joe, >> > >> > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger >> > wrote: >> >> Hi Bin, >> >> >> >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: >> >>> Hi Simon, >> >>> >> >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: >> Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally >> removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. >> This commit reverts the change. >> >> Signed-off-by: Bin Meng >> --- >> >> configs/coreboot-x86_defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configs/coreboot-x86_defconfig >> b/configs/coreboot-x86_defconfig >> index 66f94d0..799853f 100644 >> --- a/configs/coreboot-x86_defconfig >> +++ b/configs/coreboot-x86_defconfig >> @@ -1,4 +1,5 @@ >> CONFIG_X86=y >> +CONFIG_VENDOR_COREBOOT=y >> CONFIG_TARGET_COREBOOT=y >> CONFIG_OF_CONTROL=y >> CONFIG_DM_PCI=y >> -- >> >>> >> >>> Please apply this patch after commit >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf >> >>> and before commit >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. >> >>> I've verified the build with buildman on a new 'testing' branch with >> >>> insertion of this patch. >> >> >> >> This should be squashed as part of >> >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc >> >> >> >> You need to remember to run savedefconfig when changing Kconfig or >> >> defconfig. >> >> >> > >> > I still don't get it. commit 65c4ac0 introduced >> > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb >> > to clean up the defconfig. I suspect there was something wrong with >> > 'savedefconfig'? >> >> No, savedefconfig is doing exactly what it should. Before your patch, >> CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. >> Therefore savedefconfig sees it as redundant to specify that in the >> defconfig as well, so it removed it. When you change that explicit >> default to something else, it is up to you to change the defconfigs of >> the old and new default boards. >> >> Your other option is to stop defining a default in the Kconfig and >> instead mark the choice as "optional" (like I did for many other >> selections like this that had no default explicitly - Kconfig >> otherwise treats the first entry as default in that case) in which >> case all defconfigs must have a specified vendor. > > OK I've squashed that in and pushed to u-boot-x86/testing. If it looks > OK I'll pull it into master. > It looks OK. Another thing, I noticed this patch [1] is not in the testing branch. Did you apply it to somewhere else? [1] http://patchwork.ozlabs.org/patch/472988/ Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] stv0991: configure device tree for cadence qspi & flash
This patch add the device tree entry for qspi controller & spi flash
memory.
Signed-off-by: Vikas Manocha
---
arch/arm/dts/stv0991.dts | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index b25c48b..3b1efca 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -20,4 +20,38 @@
reg = <0x80406000 0x1000>;
clock = <270>;
};
+
+ aliases {
+ spi0 = "/spi@80203000"; /* QSPI */
+ };
+
+ qspi: spi@80203000 {
+ compatible = "cadence,qspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x80203000 0x100>,
+ <0x4000 0x100>;
+ clocks = <375>;
+ ext-decoder = <0>; /* external decoder */
+ num-cs = <4>;
+ fifo-depth = <256>;
+ bus-num = <0>;
+ status = "okay";
+
+ flash0: n25q32@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-flash";
+ reg = <0>; /* chip select */
+ spi-max-frequency = <5000>;
+ m25p,fast-read;
+ page-size = <256>;
+ block-size = <16>; /* 2^16, 64KB */
+ read-delay = <4>; /* delay value in read
data capture register */
+ tshsl-ns = <50>;
+ tsd2d-ns = <50>;
+ tchsh-ns = <4>;
+ tslch-ns = <4>;
+ };
+ };
};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] stv0991: enable cadence qspi controller & spi flash
This patch does all the board configurations required to use the qspi controller & attached spi flash memory. Signed-off-by: Vikas Manocha --- include/configs/stv0991.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h index df40361..4138b32 100644 --- a/include/configs/stv0991.h +++ b/include/configs/stv0991.h @@ -82,5 +82,23 @@ #define CONFIG_OF_SEPARATE #define CONFIG_OF_CONTROL #define CONFIG_OF_LIBFDT + +/* + * QSPI support + */ +#ifdef CONFIG_OF_CONTROL /* QSPI is controlled via DT */ +#define CONFIG_DM_SPI +#define CONFIG_CADENCE_QSPI +#define CONFIG_CQSPI_DECODER 0 +#define CONFIG_CQSPI_REF_CLK ((30/4)/2)*1000*1000 +#define CONFIG_CMD_SPI + +#define CONFIG_SPI_FLASH /* SPI flash subsystem */ +#define CONFIG_SPI_FLASH_STMICRO /* Micron/Numonyx flash */ +#define CONFIG_SPI_FLASH_WINBOND /* WINBOND */ +#define CONFIG_CMD_SF +#define CONFIG_DM_SPI_FLASH +#endif + #undef CONFIG_HAS_VBAR #endif /* __CONFIG_H */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] stv0991: enable cadence qspi controller & spi flash
This patchset enables cadence qspi controller for stv0991 soc. Vikas Manocha (3): stv0991: configure clock & pad muxing for qspi stv0991: enable cadence qspi controller & spi flash stv0991: configure device tree for cadence qspi & flash arch/arm/cpu/armv7/stv0991/clock.c |4 ++- arch/arm/cpu/armv7/stv0991/pinmux.c|5 +++ arch/arm/dts/stv0991.dts | 34 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 15 + arch/arm/include/asm/arch-stv0991/stv0991_creg.h |9 ++ arch/arm/include/asm/arch-stv0991/stv0991_periph.h |2 ++ board/st/stv0991/stv0991.c |8 + include/configs/stv0991.h | 18 +++ 8 files changed, 94 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] stv0991: configure clock & pad muxing for qspi
stv0991 has cadence qspi controller for flash interfacing, this
patch configures the device pads & clock for the controller.
Signed-off-by: Vikas Manocha
---
arch/arm/cpu/armv7/stv0991/clock.c |4 +++-
arch/arm/cpu/armv7/stv0991/pinmux.c|5 +
arch/arm/include/asm/arch-stv0991/stv0991_cgu.h| 15 +++
arch/arm/include/asm/arch-stv0991/stv0991_creg.h |9 +
arch/arm/include/asm/arch-stv0991/stv0991_periph.h |2 ++
board/st/stv0991/stv0991.c |8
6 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/stv0991/clock.c
b/arch/arm/cpu/armv7/stv0991/clock.c
index 70b8a8d..26c0d36 100644
--- a/arch/arm/cpu/armv7/stv0991/clock.c
+++ b/arch/arm/cpu/armv7/stv0991/clock.c
@@ -33,7 +33,9 @@ void clock_setup(int peripheral)
/* Clock selection for ethernet tx_clk & rx_clk*/
writel((readl(&stv0991_cgu_regs->eth_ctrl) & ETH_CLK_MASK)
| ETH_CLK_CTRL, &stv0991_cgu_regs->eth_ctrl);
-
+ break;
+ case QSPI_CLOCK_CFG:
+ writel(QSPI_CLK_CTRL, &stv0991_cgu_regs->qspi_freq);
break;
default:
break;
diff --git a/arch/arm/cpu/armv7/stv0991/pinmux.c
b/arch/arm/cpu/armv7/stv0991/pinmux.c
index 1d086a2..24c67fa 100644
--- a/arch/arm/cpu/armv7/stv0991/pinmux.c
+++ b/arch/arm/cpu/armv7/stv0991/pinmux.c
@@ -55,6 +55,11 @@ int stv0991_pinmux_config(int peripheral)
ETH_M_VDD_CFG, &stv0991_creg->vdd_pad1);
break;
+ case QSPI_CS_CLK_PAD:
+ writel((readl(&stv0991_creg->mux13) & FLASH_CS_NC_MASK) |
+ CFG_FLASH_CS_NC, &stv0991_creg->mux13);
+ writel((readl(&stv0991_creg->mux13) & FLASH_CLK_MASK) |
+ CFG_FLASH_CLK, &stv0991_creg->mux13);
default:
break;
}
diff --git a/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
b/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
index ddcbb57..f0045f3 100644
--- a/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
+++ b/arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
@@ -113,4 +113,19 @@ struct stv0991_cgu_regs {
#define ETH_CLK_CTRL (ETH_CLK_RX_EXT_PHY << RX_CLK_SHIFT \
| ETH_CLK_TX_EXT_PHY)
+/* CGU qspi clock */
+#define DIV_HCLK1_SHIFT9
+#define DIV_CRYP_SHIFT 6
+#define MDIV_QSPI_SHIFT3
+
+#define CLK_QSPI_OSC 0
+#define CLK_QSPI_MCLK 1
+#define CLK_QSPI_PLL1 2
+#define CLK_QSPI_PLL2 3
+
+#define QSPI_CLK_CTRL (3 << DIV_HCLK1_SHIFT \
+ | 1 << DIV_CRYP_SHIFT \
+ | 0 << MDIV_QSPI_SHIFT \
+ | CLK_QSPI_OSC)
+
#endif
diff --git a/arch/arm/include/asm/arch-stv0991/stv0991_creg.h
b/arch/arm/include/asm/arch-stv0991/stv0991_creg.h
index c804eb5..cc3c0fb 100644
--- a/arch/arm/include/asm/arch-stv0991/stv0991_creg.h
+++ b/arch/arm/include/asm/arch-stv0991/stv0991_creg.h
@@ -49,6 +49,15 @@ struct stv0991_creg {
u32 vdd_comp1; /* offset 0x400 */
};
+/* CREG MUX 13 register */
+#define FLASH_CS_NC_SHIFT 4
+#define FLASH_CS_NC_MASK ~(7 << FLASH_CS_NC_SHIFT)
+#define CFG_FLASH_CS_NC(0 << FLASH_CS_NC_SHIFT)
+
+#define FLASH_CLK_SHIFT0
+#define FLASH_CLK_MASK ~(7 << FLASH_CLK_SHIFT)
+#define CFG_FLASH_CLK (0 << FLASH_CLK_SHIFT)
+
/* CREG MUX 12 register */
#define GPIOC_30_MUX_SHIFT 24
#define GPIOC_30_MUX_MASK ~(1 << GPIOC_30_MUX_SHIFT)
diff --git a/arch/arm/include/asm/arch-stv0991/stv0991_periph.h
b/arch/arm/include/asm/arch-stv0991/stv0991_periph.h
index f728c83..725da83 100644
--- a/arch/arm/include/asm/arch-stv0991/stv0991_periph.h
+++ b/arch/arm/include/asm/arch-stv0991/stv0991_periph.h
@@ -18,6 +18,7 @@ enum periph_id {
UART_GPIOC_30_31 = 0,
UART_GPIOB_16_17,
ETH_GPIOB_10_31_C_0_4,
+ QSPI_CS_CLK_PAD,
PERIPH_ID_I2C0,
PERIPH_ID_I2C1,
PERIPH_ID_I2C2,
@@ -39,6 +40,7 @@ enum periph_id {
enum periph_clock {
UART_CLOCK_CFG = 0,
ETH_CLOCK_CFG,
+ QSPI_CLOCK_CFG,
};
#endif /* __ASM_ARM_ARCH_PERIPH_H */
diff --git a/board/st/stv0991/stv0991.c b/board/st/stv0991/stv0991.c
index 09f973f..add1ce1 100644
--- a/board/st/stv0991/stv0991.c
+++ b/board/st/stv0991/stv0991.c
@@ -55,12 +55,20 @@ int board_eth_enable(void)
return 0;
}
+int board_qspi_enable(void)
+{
+ stv0991_pinmux_config(QSPI_CS_CLK_PAD);
+ clock_setup(QSPI_CLOCK_CFG);
+ return 0;
+}
+
/*
* Miscellaneous platform dependent initialisations
*/
int board_init(void)
{
board_eth_enable();
+
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Simon, On Wed, May 27, 2015 at 6:25 PM, Simon Glass wrote: > Hi, > > On 27 May 2015 at 10:27, Joe Hershberger wrote: >> >> Hi Bin, >> >> On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: >> > Hi Joe, >> > >> > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger >> > wrote: >> >> Hi Bin, >> >> >> >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: >> >>> Hi Simon, >> >>> >> >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: >> Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally >> removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. >> This commit reverts the change. >> >> Signed-off-by: Bin Meng >> --- >> >> configs/coreboot-x86_defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configs/coreboot-x86_defconfig >> b/configs/coreboot-x86_defconfig >> index 66f94d0..799853f 100644 >> --- a/configs/coreboot-x86_defconfig >> +++ b/configs/coreboot-x86_defconfig >> @@ -1,4 +1,5 @@ >> CONFIG_X86=y >> +CONFIG_VENDOR_COREBOOT=y >> CONFIG_TARGET_COREBOOT=y >> CONFIG_OF_CONTROL=y >> CONFIG_DM_PCI=y >> -- >> >>> >> >>> Please apply this patch after commit >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf >> >>> and before commit >> >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. >> >>> I've verified the build with buildman on a new 'testing' branch with >> >>> insertion of this patch. >> >> >> >> This should be squashed as part of >> >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc >> >> >> >> You need to remember to run savedefconfig when changing Kconfig or >> >> defconfig. >> >> >> > >> > I still don't get it. commit 65c4ac0 introduced >> > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb >> > to clean up the defconfig. I suspect there was something wrong with >> > 'savedefconfig'? >> >> No, savedefconfig is doing exactly what it should. Before your patch, >> CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. >> Therefore savedefconfig sees it as redundant to specify that in the >> defconfig as well, so it removed it. When you change that explicit >> default to something else, it is up to you to change the defconfigs of >> the old and new default boards. >> >> Your other option is to stop defining a default in the Kconfig and >> instead mark the choice as "optional" (like I did for many other >> selections like this that had no default explicitly - Kconfig >> otherwise treats the first entry as default in that case) in which >> case all defconfigs must have a specified vendor. > > OK I've squashed that in and pushed to u-boot-x86/testing. If it looks > OK I'll pull it into master. It should also include removing the (now) redundant CONFIG_VENDOR_EMULATION from that defconfig. That is best done by running savedefconfig on that defconfig after applying the "x86: Make QEMU the default vendor" patch. Bin, are you in the middle of this? Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi, On 27 May 2015 at 10:27, Joe Hershberger wrote: > > Hi Bin, > > On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: > > Hi Joe, > > > > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger > > wrote: > >> Hi Bin, > >> > >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: > >>> Hi Simon, > >>> > >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: > Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally > removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. > This commit reverts the change. > > Signed-off-by: Bin Meng > --- > > configs/coreboot-x86_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/coreboot-x86_defconfig > b/configs/coreboot-x86_defconfig > index 66f94d0..799853f 100644 > --- a/configs/coreboot-x86_defconfig > +++ b/configs/coreboot-x86_defconfig > @@ -1,4 +1,5 @@ > CONFIG_X86=y > +CONFIG_VENDOR_COREBOOT=y > CONFIG_TARGET_COREBOOT=y > CONFIG_OF_CONTROL=y > CONFIG_DM_PCI=y > -- > >>> > >>> Please apply this patch after commit > >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf > >>> and before commit > >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. > >>> I've verified the build with buildman on a new 'testing' branch with > >>> insertion of this patch. > >> > >> This should be squashed as part of > >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc > >> > >> You need to remember to run savedefconfig when changing Kconfig or > >> defconfig. > >> > > > > I still don't get it. commit 65c4ac0 introduced > > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb > > to clean up the defconfig. I suspect there was something wrong with > > 'savedefconfig'? > > No, savedefconfig is doing exactly what it should. Before your patch, > CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. > Therefore savedefconfig sees it as redundant to specify that in the > defconfig as well, so it removed it. When you change that explicit > default to something else, it is up to you to change the defconfigs of > the old and new default boards. > > Your other option is to stop defining a default in the Kconfig and > instead mark the choice as "optional" (like I did for many other > selections like this that had no default explicitly - Kconfig > otherwise treats the first entry as default in that case) in which > case all defconfigs must have a specified vendor. OK I've squashed that in and pushed to u-boot-x86/testing. If it looks OK I'll pull it into master. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/4] Kconfig: Enable usage of escape char '\' in string values
On Mon, May 18, 2015 at 02:08:21PM +0200, Stefan Roese wrote: > I might have missed something, but I failed to use the escape char '\' > in strings. To pass a printf format string like "foo %d bar\n" via > Kconfig to the code. > > Right now its not possible to use the escape character '\' in Kconfig > string values correctly to e.g. set this string value "test output\n". > The '\n' will be converted to 'n'. > > The current implementation removes some of the '\' chars from the input > string in conf_set_sym_val(). Examples: > > '\' -> '' > '\\' -> '\' > '\\\' -> '\' > ''-> '\\' > ... > > And then doubles the backslash chars in the output string in > sym_escape_string_value(). Example: > > '\' -> '' -> '' > '\\' -> '\' -> '\\' > '\\\' -> '\' -> '\\' > ''-> '\\' -> '' > ... > > As you see in these examples, its impossible to generate a single '\' > charater in the output string as its needed for something like '\n'. > > This patch now changes this behavior to not drop some backslashes in > conf_set_sym_val() and to not add new backslashes in the resulting > output string. Removing the function sym_escape_string_value() > completely as its not needed anymore. > > Signed-off-by: Stefan Roese > Cc: Masahiro Yamada > Cc: Simon Glass > Reviewed-by: Simon Glass This breaks a number of configs such as TZX-Q8-713B7_defconfig: *** Error in `scripts/kconfig/conf': free(): invalid next size (fast): 0x02972420 *** ../scripts/kconfig/Makefile:111: recipe for target 'TZX-Q8-713B7_defconfig' failed -- 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] [U-Boot, 1/1] board: Add Toby-Churchill SL50 board support.
On Thu, May 14, 2015 at 10:03:56AM +0200, Enric Balletbò i Serra wrote: > Add support for Lightwriter SL50 series board, a small, robust and portable > Voice Output Communication Aids (VOCA) designed to meet the particular and > changing needs of people with speech loss resulting from a wide range of > acquired, progressive and congenital conditions. > > Signed-off-by: Enric Balletbo i Serra This needs a rebase to fix problems like: #error "Serial is required before relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work" And: warning: implicit declaration of function 'is_valid_ether_addr' [-Wimplicit-function-declaration] (and the resulting link failure). -- 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] board: add support for Vision System's Baltos Industrial PC
On Tue, May 12, 2015 at 05:16:32PM -0500, Felipe Balbi wrote: > From: Yegor Yefremov > > Vision Systems's Baltos is based on AM335x SoC > from Texas Instruments. This patch adds support > such Industrial PCs in mainline u-boot. > > [ ba...@ti.com: updated original patch to current u-boot ] > > Signed-off-by: Yegor Yefremov > Signed-off-by: Felipe Balbi This needs a rebase to fix problems like: #error "Serial is required before relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work" And: warning: implicit declaration of function 'is_valid_ether_addr' [-Wimplicit-function-declaration] (and the resulting link failure). -- 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] soft-i2c and i2c-gpio issues with at91
On Wed, May 27, 2015 at 7:32 AM, Przemyslaw Marczak wrote: > Hi all, > > On 05/26/2015 07:23 PM, Matt Wood wrote: > >> Thank you Simon. Getting there, but now I get a data abort and system >> reset when trying to set the i2c bus. I need to chase this down, but if >> you have any suggestions I'd appreciate it. >> >> Below is the output of dm tree and dm uclass. >> >> Thanks, Matt. >> >> U-Boot> i2c dev 3 >> > > ...snip... > > You should first be sure that dm gpio for your board is working properly. > > Are you able to test the output state of some GPIOs on your board, e.g. by > the LED? > If yes, then you can test it with gpio command or just using some > dm_gpio..() calls for some GPIO with the LED. > > And about your data abort. > I can't check your board config/driver at present but will try to give you > a quick suggestion. > > So, when you type i2c dev 3, then the i2c device: > > "gpio-i2c@1 @ 3fb58348, seq -1, (req 3)" > > with alias number 3 (as you requested) is probed. > > One of the routine is calling the function: > * i2c_gpio_ofdata_to_platdata() in gpio-i2c.c - probably succeeds. > > Then, > * post_probe() of i2c uclass is called, and next: > * i2c_post_probe() - from drivers/i2c/i2c-uclass.c, this goes to: > * i2c_gpio_set_bus_speed() - from gpio-i2c.c > > And here probably starts the magic which ends by data abort. > The driver just operates on GPIOs defined in your device tree. > > If you enable the gpio command (CONFIG_CMD_GPIO), then you can easy test, > that change state of some GPIO pins works properly, or you can make some > test by printing the results of dm_gpio..() calls in somewhere. > > Best regards, > -- > Przemyslaw Marczak > Samsung R&D Institute Poland > Samsung Electronics > p.marc...@samsung.com OK very interesting, I enabled CONFIG_CMD_GPIO and if I do a "gpio status" I get a data abort and reset, however if I simply do a "gpio set/clear/toggle ..." on a known pin, the output of the pin changes accordingly. I'm not sure specifically what this means but I know the GPIO driver model is at least partly working. Anyway, due to time constraints I went back to the old I2C driver interface as I don't have time to debug this anymore: https://github.com/linux4sam/u-boot-at91/commit/7ff618b526a04b7fb72df1a3e04a91fe40b6ccf3 Thanks Josh for pointing me to this, I can successfully read the EEPROM I'm after. Regards, Matt. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] zynqmp: gem: Set data bus with to 64bit for arm64
Hi Michal, On Tue, May 26, 2015 at 6:40 AM, Michal Simek wrote: > From: Siva Durga Prasad Paladugu > > Set the data bus width to 64-bit AMBA Databus width in config register. > > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Michal Simek > --- > > drivers/net/zynq_gem.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c > index c723dbb0a694..22195805e6d6 100644 > --- a/drivers/net/zynq_gem.c > +++ b/drivers/net/zynq_gem.c > @@ -58,7 +58,14 @@ > #define ZYNQ_GEM_NWCFG_MDCCLKDIV 0x8 /* Div pclk by 32, 80MHz > */ > #define ZYNQ_GEM_NWCFG_MDCCLKDIV2 0xc /* Div pclk by 48, 120MHz > */ > > -#define ZYNQ_GEM_NWCFG_INIT(ZYNQ_GEM_NWCFG_FDEN | \ > +#ifdef CONFIG_TARGET_XILINX_ZYNQMP Isn't there a more explicit define you can use to select this such as CONFIG_ARM64? > +# define ZYNQ_GEM_DBUS_WIDTH (1 << 21) /* 64 bit bus */ > +#else > +# define ZYNQ_GEM_DBUS_WIDTH (0 << 21) /* 32 bit bus */ > +#endif > + > +#define ZYNQ_GEM_NWCFG_INIT(ZYNQ_GEM_DBUS_WIDTH | \ > + ZYNQ_GEM_NWCFG_FDEN | \ > ZYNQ_GEM_NWCFG_FSREM | \ > ZYNQ_GEM_NWCFG_MDCCLKDIV) There is a typo in the subject. with->width. -Joe On Tue, May 26, 2015 at 6:40 AM, Michal Simek wrote: > From: Siva Durga Prasad Paladugu > > Set the data bus width to 64-bit AMBA Databus width in config register. > > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Michal Simek > --- > > drivers/net/zynq_gem.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c > index c723dbb0a694..22195805e6d6 100644 > --- a/drivers/net/zynq_gem.c > +++ b/drivers/net/zynq_gem.c > @@ -58,7 +58,14 @@ > #define ZYNQ_GEM_NWCFG_MDCCLKDIV 0x8 /* Div pclk by 32, 80MHz > */ > #define ZYNQ_GEM_NWCFG_MDCCLKDIV2 0xc /* Div pclk by 48, 120MHz > */ > > -#define ZYNQ_GEM_NWCFG_INIT(ZYNQ_GEM_NWCFG_FDEN | \ > +#ifdef CONFIG_TARGET_XILINX_ZYNQMP > +# define ZYNQ_GEM_DBUS_WIDTH (1 << 21) /* 64 bit bus */ > +#else > +# define ZYNQ_GEM_DBUS_WIDTH (0 << 21) /* 32 bit bus */ > +#endif > + > +#define ZYNQ_GEM_NWCFG_INIT(ZYNQ_GEM_DBUS_WIDTH | \ > + ZYNQ_GEM_NWCFG_FDEN | \ > ZYNQ_GEM_NWCFG_FSREM | \ > ZYNQ_GEM_NWCFG_MDCCLKDIV) > > -- > 2.3.5 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree
Hi Bin,
On 27 May 2015 at 10:27, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 11:42 PM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 26 May 2015 at 22:06, Bin Meng wrote:
>>> Hi Simon,
>>>
>>> On Wed, May 27, 2015 at 11:59 AM, Simon Glass wrote:
Hi Bin,
On 26 May 2015 at 21:55, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 11:13 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 25 May 2015 at 08:36, Bin Meng wrote:
>>> Although the two qemu-x86 targets (i440fx and q35) share a lot in
>>> common, they still have something that cannot easily handled in one
>>> place (like different configurations, different properties in the
>>> device tree). Split to create two dedicated board configuration and
>>> device tree files and make the i440fx be the default build target.
>>>
>>> Signed-off-by: Bin Meng
>>> ---
>>>
>>> arch/x86/dts/Makefile | 3 +-
>>> arch/x86/dts/qemu-x86_i440fx.dts | 34 +++
>>> arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} | 2 +-
>>> board/coreboot/coreboot/Kconfig | 4 +-
>>> board/emulation/qemu-x86/Kconfig | 19 +++--
>>> configs/qemu-x86_defconfig| 1 -
>>> doc/README.x86| 13 +-
>>> include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
>>> include/configs/qemu-x86_q35.h| 52
>>> +++
>>> 9 files changed, 122 insertions(+), 26 deletions(-)
>>> create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>>> rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
>>> rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
>>> create mode 100644 include/configs/qemu-x86_q35.h
>>
>> Do we need a separate config file? It would be good if all the changes
>> were in the device tree so that we don't need a separate config. Or at
>> least that the configs are the same except for the device tree.
>>
>
> So far the only difference between two separate config files are the
> ATA/SATA settings. i440fx has legacy IDE support while q35 has the
> AHCI support. We can enable them both in just one config files,
> however turning on legacy IDE support on q35 causes significant boot
> delay as the legacy IDE driver has some big timeout in probing the
> attached devices. Do you think this is something we are tolerant of?
> If yes, I can just do separate device trees.
I think it is OK. But another option would be to add an IDE node to
the device tree and check it when CONFIG_OF_CONTROL is defined...
>>>
>>> I feel that we need convert all block drivers to driver model, so that
>>> the driver can probe and initialize IDE/AHCI based on device tree
>>> node. But I guess that's a long term goal?
>>
>> Yes, perhaps latter in the year. I did create a simple MMC uclass that
>> uses the block driver library just as now, and it seems easy enough. I
>> suppose you could do the same with IDE. But in the meantime just some
>> sort of DT config is good enough to avoid your device.
>>
>
> I am not sure I understand your point. Do you mean for now I need
> modify common/cmd_ide.c::ide_init() to probe the existence of an IDE
> node in the device tree? I am afraid that's a lot of work too since
> there are many boards use the IDE driver.
Maybe for now you could do:
#ifdef CONFIG_OF_CONTROL
if (!fdtdec_get_config_bool("legacy-ide"))
return; /* skip IDE */
#endif
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets
Hi Bin,
On 27 May 2015 at 10:17, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 11:37 PM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 26 May 2015 at 21:50, Bin Meng wrote:
>>> Hi Simon,
>>>
>>> On Wed, May 27, 2015 at 11:13 AM, Simon Glass wrote:
Hi Bin,
On 25 May 2015 at 08:36, Bin Meng wrote:
> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
> U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/cpu/coreboot/coreboot.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/x86/cpu/coreboot/coreboot.c
> b/arch/x86/cpu/coreboot/coreboot.c
> index 4cdd0d4..2234cf0 100644
> --- a/arch/x86/cpu/coreboot/coreboot.c
> +++ b/arch/x86/cpu/coreboot/coreboot.c
> @@ -85,10 +85,6 @@ void board_final_cleanup(void)
> wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
> mtrr_close(&state);
> }
> -
> - /* Issue SMI to Coreboot to lock down ME and registers */
> - printf("Finalizing Coreboot\n");
> - outb(0xcb, 0xb2);
> }
>
> void panic_puts(const char *str)
> --
> 1.8.2.1
>
But how does this run with coreboot on platforms that need it? Should
this be controlled by a device tree settings, perhaps?
>>>
>>> I am not sure if the lock down should be done by the coreboot in the
>>> first place. IMHO U-Boot as the coreboot payload should not touch such
>>> low-level stuff.
>>
>> Well it is telling coreboot that it is about to boot the kernel. I
>> think this is an x86 thing and we should support it.
>>
>
> What happens if coreboot directly boot into the kernel? Does coreboot
> do the same 'outb(0xcb, 0xb2)' thing before jumping to kernel? My
Kind of, although in that case it is just a function call within coreboot.
> understanding is that coreboot payload is to enhance coreboot's
> functionality as a system BIOS (either having legacy BIOS interface
> with the help of a SeaBIOS payload, or having UEFI interface with the
> help of a TinaoCore payload). coreboot itself does the mainboard
> initialization and payload does something that is not hardware
> dependent.
Right, but we need to tell coreboot that we have finished with the ME
/ registers, etc. It can't lock them before calling U-Boot since we
may adjust them.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2] Move setexpr to Kconfig
On Mon, May 11, 2015 at 01:53:12PM -0500, Joe Hershberger wrote: > Another shell scripting command that has not been moved. > > Signed-off-by: Joe Hershberger > Cc: Masahiro Yamada This needs rebasing to master if still applicable which I gather it is, 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-uniphier/misc
On Wed, May 27, 2015 at 08:47:02AM +0900, Masahiro Yamada wrote: > Hi Tom, > > Here is a new tool that helps us move CONFIG options easily. > > > > The following changes since commit 9bea236b3402a262772b66d055ec6431cbd3ba87: > > Merge branch 'master' of git://www.denx.de/git/u-boot-imx > (2015-05-26 10:38:01 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-uniphier.git misc > > for you to fetch changes up to 2e2ce6c0c8d3d0d2a86d2464d201aecd9aef693d: > > moveconfig: Print status about the processed defconfigs (2015-05-27 > 08:39:16 +0900) > 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] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng wrote: > Hi Joe, > > On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger > wrote: >> Hi Bin, >> >> On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: >>> Hi Simon, >>> >>> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. This commit reverts the change. Signed-off-by: Bin Meng --- configs/coreboot-x86_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig index 66f94d0..799853f 100644 --- a/configs/coreboot-x86_defconfig +++ b/configs/coreboot-x86_defconfig @@ -1,4 +1,5 @@ CONFIG_X86=y +CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_OF_CONTROL=y CONFIG_DM_PCI=y -- >>> >>> Please apply this patch after commit >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf >>> and before commit >>> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. >>> I've verified the build with buildman on a new 'testing' branch with >>> insertion of this patch. >> >> This should be squashed as part of >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc >> >> You need to remember to run savedefconfig when changing Kconfig or defconfig. >> > > I still don't get it. commit 65c4ac0 introduced > 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb > to clean up the defconfig. I suspect there was something wrong with > 'savedefconfig'? No, savedefconfig is doing exactly what it should. Before your patch, CONFIG_VENDOR_COREBOOT was the default, explicitly in the Kconfig. Therefore savedefconfig sees it as redundant to specify that in the defconfig as well, so it removed it. When you change that explicit default to something else, it is up to you to change the defconfigs of the old and new default boards. Your other option is to stop defining a default in the Kconfig and instead mark the choice as "optional" (like I did for many other selections like this that had no default explicitly - Kconfig otherwise treats the first entry as default in that case) in which case all defconfigs must have a specified vendor. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree
Hi Simon,
On Wed, May 27, 2015 at 11:42 PM, Simon Glass wrote:
> Hi Bin,
>
> On 26 May 2015 at 22:06, Bin Meng wrote:
>> Hi Simon,
>>
>> On Wed, May 27, 2015 at 11:59 AM, Simon Glass wrote:
>>> Hi Bin,
>>>
>>> On 26 May 2015 at 21:55, Bin Meng wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:13 AM, Simon Glass wrote:
> Hi Bin,
>
> On 25 May 2015 at 08:36, Bin Meng wrote:
>> Although the two qemu-x86 targets (i440fx and q35) share a lot in
>> common, they still have something that cannot easily handled in one
>> place (like different configurations, different properties in the
>> device tree). Split to create two dedicated board configuration and
>> device tree files and make the i440fx be the default build target.
>>
>> Signed-off-by: Bin Meng
>> ---
>>
>> arch/x86/dts/Makefile | 3 +-
>> arch/x86/dts/qemu-x86_i440fx.dts | 34 +++
>> arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} | 2 +-
>> board/coreboot/coreboot/Kconfig | 4 +-
>> board/emulation/qemu-x86/Kconfig | 19 +++--
>> configs/qemu-x86_defconfig| 1 -
>> doc/README.x86| 13 +-
>> include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
>> include/configs/qemu-x86_q35.h| 52
>> +++
>> 9 files changed, 122 insertions(+), 26 deletions(-)
>> create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>> rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
>> rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
>> create mode 100644 include/configs/qemu-x86_q35.h
>
> Do we need a separate config file? It would be good if all the changes
> were in the device tree so that we don't need a separate config. Or at
> least that the configs are the same except for the device tree.
>
So far the only difference between two separate config files are the
ATA/SATA settings. i440fx has legacy IDE support while q35 has the
AHCI support. We can enable them both in just one config files,
however turning on legacy IDE support on q35 causes significant boot
delay as the legacy IDE driver has some big timeout in probing the
attached devices. Do you think this is something we are tolerant of?
If yes, I can just do separate device trees.
>>>
>>> I think it is OK. But another option would be to add an IDE node to
>>> the device tree and check it when CONFIG_OF_CONTROL is defined...
>>>
>>
>> I feel that we need convert all block drivers to driver model, so that
>> the driver can probe and initialize IDE/AHCI based on device tree
>> node. But I guess that's a long term goal?
>
> Yes, perhaps latter in the year. I did create a simple MMC uclass that
> uses the block driver library just as now, and it seems easy enough. I
> suppose you could do the same with IDE. But in the meantime just some
> sort of DT config is good enough to avoid your device.
>
I am not sure I understand your point. Do you mean for now I need
modify common/cmd_ide.c::ide_init() to probe the existence of an IDE
node in the device tree? I am afraid that's a lot of work too since
there are many boards use the IDE driver.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger wrote: > Hi Bin, > > On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: >> Hi Simon, >> >> On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: >>> Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally >>> removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. >>> This commit reverts the change. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> configs/coreboot-x86_defconfig | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig >>> index 66f94d0..799853f 100644 >>> --- a/configs/coreboot-x86_defconfig >>> +++ b/configs/coreboot-x86_defconfig >>> @@ -1,4 +1,5 @@ >>> CONFIG_X86=y >>> +CONFIG_VENDOR_COREBOOT=y >>> CONFIG_TARGET_COREBOOT=y >>> CONFIG_OF_CONTROL=y >>> CONFIG_DM_PCI=y >>> -- >> >> Please apply this patch after commit >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf >> and before commit >> http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. >> I've verified the build with buildman on a new 'testing' branch with >> insertion of this patch. > > This should be squashed as part of > http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc > > You need to remember to run savedefconfig when changing Kconfig or defconfig. > I still don't get it. commit 65c4ac0 introduced 'CONFIG_VENDOR_COREBOOT=y' and was applied before your commit bd328eb to clean up the defconfig. I suspect there was something wrong with 'savedefconfig'? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
Hi Tom, On Tue, May 26, 2015 at 9:02 PM, Tom Rini wrote: > On Tue, May 26, 2015 at 12:24:38PM -0500, Joe Hershberger wrote: > >> Hi Tom, >> >> This fixes a few mistakes I made in the rand rework stuff. >> >> The following changes since commit 980267a1445b7b4d8e8d05ef57799d92ba4a2ee3: >> >> Merge git://git.denx.de/u-boot-nand-flash (2015-05-24 21:01:30 -0400) >> >> are available in the git repository at: >> >> >> git://git.denx.de/u-boot-net.git master >> >> for you to fetch changes up to 91fed5574600142f68dac7807bc06173d1f29eb5: >> >> blackfin: fix build error on bct-brettl2 board (2015-05-26 12:18:42 -0500) >> > > NAK: > 06: Merge branch 'master' of git://git.denx.de/u-boot-net > blackfin: bct-brettl2 + bf537-minotaur cm-bf527 ip04 bf537-stamp > cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit bf537-pnav bf537-srv1 tcm-bf537 > dnp5370 bf518f-ezbrd bf526-ezbrd > > All about CONFIG_LIB_RAND being redefined. Sorry about that. Got a little too hasty it appears. Michal, please rework your patch using tools/moveconfig.py Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets
Hi Simon,
On Wed, May 27, 2015 at 11:37 PM, Simon Glass wrote:
> Hi Bin,
>
> On 26 May 2015 at 21:50, Bin Meng wrote:
>> Hi Simon,
>>
>> On Wed, May 27, 2015 at 11:13 AM, Simon Glass wrote:
>>> Hi Bin,
>>>
>>> On 25 May 2015 at 08:36, Bin Meng wrote:
Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.
Signed-off-by: Bin Meng
---
arch/x86/cpu/coreboot/coreboot.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c
b/arch/x86/cpu/coreboot/coreboot.c
index 4cdd0d4..2234cf0 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -85,10 +85,6 @@ void board_final_cleanup(void)
wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
mtrr_close(&state);
}
-
- /* Issue SMI to Coreboot to lock down ME and registers */
- printf("Finalizing Coreboot\n");
- outb(0xcb, 0xb2);
}
void panic_puts(const char *str)
--
1.8.2.1
>>>
>>> But how does this run with coreboot on platforms that need it? Should
>>> this be controlled by a device tree settings, perhaps?
>>>
>>
>> I am not sure if the lock down should be done by the coreboot in the
>> first place. IMHO U-Boot as the coreboot payload should not touch such
>> low-level stuff.
>
> Well it is telling coreboot that it is about to boot the kernel. I
> think this is an x86 thing and we should support it.
>
What happens if coreboot directly boot into the kernel? Does coreboot
do the same 'outb(0xcb, 0xb2)' thing before jumping to kernel? My
understanding is that coreboot payload is to enhance coreboot's
functionality as a system BIOS (either having legacy BIOS interface
with the help of a SeaBIOS payload, or having UEFI interface with the
help of a TinaoCore payload). coreboot itself does the mainboard
initialization and payload does something that is not hardware
dependent.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng wrote: > Hi Simon, > > On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: >> Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally >> removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. >> This commit reverts the change. >> >> Signed-off-by: Bin Meng >> --- >> >> configs/coreboot-x86_defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig >> index 66f94d0..799853f 100644 >> --- a/configs/coreboot-x86_defconfig >> +++ b/configs/coreboot-x86_defconfig >> @@ -1,4 +1,5 @@ >> CONFIG_X86=y >> +CONFIG_VENDOR_COREBOOT=y >> CONFIG_TARGET_COREBOOT=y >> CONFIG_OF_CONTROL=y >> CONFIG_DM_PCI=y >> -- > > Please apply this patch after commit > http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf > and before commit > http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. > I've verified the build with buildman on a new 'testing' branch with > insertion of this patch. This should be squashed as part of http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc You need to remember to run savedefconfig when changing Kconfig or defconfig. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] x86: Make QEMU the default vendor
Hi Bin, On Wed, May 27, 2015 at 10:58 AM, Bin Meng wrote: > Hi Simon, > > On Wed, May 27, 2015 at 11:53 PM, Simon Glass wrote: >> Hi Bin, >> >> On 27 May 2015 at 09:52, Bin Meng wrote: >>> Hi Simon, >>> >>> On Wed, May 27, 2015 at 12:01 PM, Bin Meng wrote: Hi Simon, On Wed, May 27, 2015 at 11:57 AM, Simon Glass wrote: > Hi Bin, > > On 8 May 2015 at 14:42, Simon Glass wrote: >> On 7 May 2015 at 07:34, Bin Meng wrote: >>> Now that we have QEMU support, make it the default vendor in the >>> 'make menuconfig' screen. >>> >>> Signed-off-by: Bin Meng >>> Acked-by: Simon Glass >>> Tested-by: Simon Glass >>> --- >>> >>> Changes in v2: None >>> >>> arch/x86/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Applied to u-boot-x86, thanks! > > For some reason I am seeing a failure here: > > 04: x86: Make QEMU the default vendor >x86: + coreboot-x86 > + > +Device Tree Source is not correctly specified. > +Please define 'CONFIG_DEFAULT_DEVICE_TREE' > +or build with 'DEVICE_TREE=' argument > +make[2]: *** [arch/x86/dts/unset.dtb] Error 1 > +make[1]: *** [dts/dt.dtb] Error 2 > +make: *** [sub-make] Error 2 > That's weird. I didn't see such error when building the patchset with buildman. >>> >>> I've figured out the root cause. For some reason which I don't >>> understand, commit bd328eb broke this. >>> >>> +Joe, >>> >>> Do you know if there is something wrong with commit bd328eb that >>> accidentally removed 'CONFIG_VENDOR_COREBOOT=y'? >> >> It could perhaps be a merge conflict. If it's needed I can put it back in. >> > > No, it looks Joe's commit is already there in the U-Boot main git > repo. I've just worked out a patch to revert the change and sent it to > the mailing list. That patch was simply a call to make *_defconfig && make savedefconfig. The way this usually happens is that the Kconfig file is changed to make the config (for instance CONFIG_VENDOR_COREBOOT) no longer the default, without adding that to the defconfig files. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. This commit reverts the change. Signed-off-by: Bin Meng --- configs/coreboot-x86_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig index 66f94d0..799853f 100644 --- a/configs/coreboot-x86_defconfig +++ b/configs/coreboot-x86_defconfig @@ -1,4 +1,5 @@ CONFIG_X86=y +CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_OF_CONTROL=y CONFIG_DM_PCI=y -- 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] kbuild: define DO_DEPS_ONLY for u-boot.cfg to fix build error
On 25 May 2015 at 21:51, Masahiro Yamada wrote: > Since 741e58e0fc8e (Create a .cfg file containing the CONFIG options > used to build), all the Blackfin boards fail to build if the parallel > (-j) option is passed. > > $ make -s bf506f-ezkit_defconfig > # > # configuration written to .config > # > $ make -j8 CROSS_COMPILE=bfin-elf- > scripts/kconfig/conf --silentoldconfig Kconfig > CHK include/config.h > UPD include/config.h > GEN include/autoconf.mk > GEN include/autoconf.mk.dep > CHK include/config/uboot.release > CHK include/generated/timestamp_autogenerated.h > UPD include/generated/timestamp_autogenerated.h > CFG u-boot.cfg > include/asm-offsets.h:3:43: fatal error: > generated/generic-asm-offsets.h: No such file or directory > compilation terminated. > make: *** [u-boot.cfg] Error 1 > > When parsing header files for defined CONFIG options, DO_DEPS_ONLY > must be defined to exclude generated headers that might not have > been available yet. > > Signed-off-by: Masahiro Yamada > --- > > Makefile | 2 +- > scripts/Makefile.spl | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng wrote: > Commit bd328eb "Clean all defconfigs with savedefconfig" accidentally > removed 'CONFIG_VENDOR_COREBOOT=y' from configs/coreboot-x86_defconfig. > This commit reverts the change. > > Signed-off-by: Bin Meng > --- > > configs/coreboot-x86_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/coreboot-x86_defconfig b/configs/coreboot-x86_defconfig > index 66f94d0..799853f 100644 > --- a/configs/coreboot-x86_defconfig > +++ b/configs/coreboot-x86_defconfig > @@ -1,4 +1,5 @@ > CONFIG_X86=y > +CONFIG_VENDOR_COREBOOT=y > CONFIG_TARGET_COREBOOT=y > CONFIG_OF_CONTROL=y > CONFIG_DM_PCI=y > -- Please apply this patch after commit http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=3506805839e14a67b0971b02c7784e37b85d5fbf and before commit http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=05cab1d6da2a84911fa0ec0ffa8fa038adef4dbc. I've verified the build with buildman on a new 'testing' branch with insertion of this patch. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] x86: Make QEMU the default vendor
Hi Simon, On Wed, May 27, 2015 at 11:53 PM, Simon Glass wrote: > Hi Bin, > > On 27 May 2015 at 09:52, Bin Meng wrote: >> Hi Simon, >> >> On Wed, May 27, 2015 at 12:01 PM, Bin Meng wrote: >>> Hi Simon, >>> >>> On Wed, May 27, 2015 at 11:57 AM, Simon Glass wrote: Hi Bin, On 8 May 2015 at 14:42, Simon Glass wrote: > On 7 May 2015 at 07:34, Bin Meng wrote: >> Now that we have QEMU support, make it the default vendor in the >> 'make menuconfig' screen. >> >> Signed-off-by: Bin Meng >> Acked-by: Simon Glass >> Tested-by: Simon Glass >> --- >> >> Changes in v2: None >> >> arch/x86/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Applied to u-boot-x86, thanks! For some reason I am seeing a failure here: 04: x86: Make QEMU the default vendor x86: + coreboot-x86 + +Device Tree Source is not correctly specified. +Please define 'CONFIG_DEFAULT_DEVICE_TREE' +or build with 'DEVICE_TREE=' argument +make[2]: *** [arch/x86/dts/unset.dtb] Error 1 +make[1]: *** [dts/dt.dtb] Error 2 +make: *** [sub-make] Error 2 >>> >>> That's weird. I didn't see such error when building the patchset with >>> buildman. >>> >> >> I've figured out the root cause. For some reason which I don't >> understand, commit bd328eb broke this. >> >> +Joe, >> >> Do you know if there is something wrong with commit bd328eb that >> accidentally removed 'CONFIG_VENDOR_COREBOOT=y'? > > It could perhaps be a merge conflict. If it's needed I can put it back in. > No, it looks Joe's commit is already there in the U-Boot main git repo. I've just worked out a patch to revert the change and sent it to the mailing list. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon mode with initrd
Hi Tim, On 27/05/2015 17:22, Tim Harvey wrote: > Stefano, > > You may perhaps be the most knowledgeable about Falcon mode based on > the presentations I've found on the web. > > It seems to me that there is currently no support in U-Boot for using > Falcon mode where the kernel is separate from the initrd. If you mind if SPL in Falcon mode loads both kernel and initrd, you're right. This is not supported. SPL loads only one image. > I see that > the 'spl' command is passed the initrd_addr so that it can setup > atags/fdt (I haven't followed through the code to understand what it > does with this addr yet) but there is no support in any of the > common/spl/spl_*.c files for loading anything other than args or > kernel. Yes, the command are thought to prepare the setup for the kernel, ATAGS or DT, but not to load something else. > > Have you had any thoughts on this? The way to load more as one image in U-Boot should be via the FIT image. You can have separate kernel and initrd, and by using the mkimage you can combine them. SPL will still load one single image (I guess some changes are required to allow Falcon to load a FIT), but it is much more general and let open to have a Falcon Boot combined with Secure Boot. > It seems to me a new #define would > need to be created per storage medium pointing to the offset/sector of > initrd and used at compile time. Perhaps your thoughts have always > been that if you want to use an initrd for falcon mode you must always > build it into the kernel? Really in most projects I do not use initrd at all and the rootfs is mounted on a storage (NOR/NAND/..), without a initrd as distros are used to do. When a initrd is required, my preferences go to build a FIT image combinining zImage (not anymore uImage), initrd and DT. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] x86: Make QEMU the default vendor
Hi Bin, On 27 May 2015 at 09:52, Bin Meng wrote: > Hi Simon, > > On Wed, May 27, 2015 at 12:01 PM, Bin Meng wrote: >> Hi Simon, >> >> On Wed, May 27, 2015 at 11:57 AM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 8 May 2015 at 14:42, Simon Glass wrote: On 7 May 2015 at 07:34, Bin Meng wrote: > Now that we have QEMU support, make it the default vendor in the > 'make menuconfig' screen. > > Signed-off-by: Bin Meng > Acked-by: Simon Glass > Tested-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-x86, thanks! >>> >>> For some reason I am seeing a failure here: >>> >>> 04: x86: Make QEMU the default vendor >>>x86: + coreboot-x86 >>> + >>> +Device Tree Source is not correctly specified. >>> +Please define 'CONFIG_DEFAULT_DEVICE_TREE' >>> +or build with 'DEVICE_TREE=' argument >>> +make[2]: *** [arch/x86/dts/unset.dtb] Error 1 >>> +make[1]: *** [dts/dt.dtb] Error 2 >>> +make: *** [sub-make] Error 2 >>> >> >> That's weird. I didn't see such error when building the patchset with >> buildman. >> > > I've figured out the root cause. For some reason which I don't > understand, commit bd328eb broke this. > > +Joe, > > Do you know if there is something wrong with commit bd328eb that > accidentally removed 'CONFIG_VENDOR_COREBOOT=y'? It could perhaps be a merge conflict. If it's needed I can put it back in. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] x86: Make QEMU the default vendor
Hi Simon, On Wed, May 27, 2015 at 12:01 PM, Bin Meng wrote: > Hi Simon, > > On Wed, May 27, 2015 at 11:57 AM, Simon Glass wrote: >> Hi Bin, >> >> On 8 May 2015 at 14:42, Simon Glass wrote: >>> On 7 May 2015 at 07:34, Bin Meng wrote: Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng Acked-by: Simon Glass Tested-by: Simon Glass --- Changes in v2: None arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Applied to u-boot-x86, thanks! >> >> For some reason I am seeing a failure here: >> >> 04: x86: Make QEMU the default vendor >>x86: + coreboot-x86 >> + >> +Device Tree Source is not correctly specified. >> +Please define 'CONFIG_DEFAULT_DEVICE_TREE' >> +or build with 'DEVICE_TREE=' argument >> +make[2]: *** [arch/x86/dts/unset.dtb] Error 1 >> +make[1]: *** [dts/dt.dtb] Error 2 >> +make: *** [sub-make] Error 2 >> > > That's weird. I didn't see such error when building the patchset with > buildman. > I've figured out the root cause. For some reason which I don't understand, commit bd328eb broke this. +Joe, Do you know if there is something wrong with commit bd328eb that accidentally removed 'CONFIG_VENDOR_COREBOOT=y'? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] x86: qemu: Create i440fx and q35 board configuration and device tree
Hi Bin,
On 26 May 2015 at 22:06, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 11:59 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 26 May 2015 at 21:55, Bin Meng wrote:
>>> Hi Simon,
>>>
>>> On Wed, May 27, 2015 at 11:13 AM, Simon Glass wrote:
Hi Bin,
On 25 May 2015 at 08:36, Bin Meng wrote:
> Although the two qemu-x86 targets (i440fx and q35) share a lot in
> common, they still have something that cannot easily handled in one
> place (like different configurations, different properties in the
> device tree). Split to create two dedicated board configuration and
> device tree files and make the i440fx be the default build target.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/dts/Makefile | 3 +-
> arch/x86/dts/qemu-x86_i440fx.dts | 34 +++
> arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} | 2 +-
> board/coreboot/coreboot/Kconfig | 4 +-
> board/emulation/qemu-x86/Kconfig | 19 +++--
> configs/qemu-x86_defconfig| 1 -
> doc/README.x86| 13 +-
> include/configs/{qemu-x86.h => qemu-x86_i440fx.h} | 20 ++---
> include/configs/qemu-x86_q35.h| 52
> +++
> 9 files changed, 122 insertions(+), 26 deletions(-)
> create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
> rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
> rename include/configs/{qemu-x86.h => qemu-x86_i440fx.h} (78%)
> create mode 100644 include/configs/qemu-x86_q35.h
Do we need a separate config file? It would be good if all the changes
were in the device tree so that we don't need a separate config. Or at
least that the configs are the same except for the device tree.
>>>
>>> So far the only difference between two separate config files are the
>>> ATA/SATA settings. i440fx has legacy IDE support while q35 has the
>>> AHCI support. We can enable them both in just one config files,
>>> however turning on legacy IDE support on q35 causes significant boot
>>> delay as the legacy IDE driver has some big timeout in probing the
>>> attached devices. Do you think this is something we are tolerant of?
>>> If yes, I can just do separate device trees.
>>
>> I think it is OK. But another option would be to add an IDE node to
>> the device tree and check it when CONFIG_OF_CONTROL is defined...
>>
>
> I feel that we need convert all block drivers to driver model, so that
> the driver can probe and initialize IDE/AHCI based on device tree
> node. But I guess that's a long term goal?
Yes, perhaps latter in the year. I did create a simple MMC uclass that
uses the block driver library just as now, and it seems easy enough. I
suppose you could do the same with IDE. But in the meantime just some
sort of DT config is good enough to avoid your device.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets
Hi Bin,
On 26 May 2015 at 21:50, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 11:13 AM, Simon Glass wrote:
>> Hi Bin,
>>
>> On 25 May 2015 at 08:36, Bin Meng wrote:
>>> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
>>> U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.
>>>
>>> Signed-off-by: Bin Meng
>>> ---
>>>
>>> arch/x86/cpu/coreboot/coreboot.c | 4
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/arch/x86/cpu/coreboot/coreboot.c
>>> b/arch/x86/cpu/coreboot/coreboot.c
>>> index 4cdd0d4..2234cf0 100644
>>> --- a/arch/x86/cpu/coreboot/coreboot.c
>>> +++ b/arch/x86/cpu/coreboot/coreboot.c
>>> @@ -85,10 +85,6 @@ void board_final_cleanup(void)
>>> wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
>>> mtrr_close(&state);
>>> }
>>> -
>>> - /* Issue SMI to Coreboot to lock down ME and registers */
>>> - printf("Finalizing Coreboot\n");
>>> - outb(0xcb, 0xb2);
>>> }
>>>
>>> void panic_puts(const char *str)
>>> --
>>> 1.8.2.1
>>>
>>
>> But how does this run with coreboot on platforms that need it? Should
>> this be controlled by a device tree settings, perhaps?
>>
>
> I am not sure if the lock down should be done by the coreboot in the
> first place. IMHO U-Boot as the coreboot payload should not touch such
> low-level stuff.
Well it is telling coreboot that it is about to boot the kernel. I
think this is an x86 thing and we should support it.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts status
On 05/26/2015 09:30 PM, Kushwaha Prabhakar-B32579 wrote: >>> >>> Shouldn't this function be called from SoC function? It is not a >>> board- dependent setup, but rather depending on RCW which is an SoC >> feature. >>> > > There are 2 function and their relationship is like this > ft_pci_setup calling ft_pcie_ls_setup. > > ft_pcie_ls_setup is doing thing related to SoC. > So I believe ft_pci_setup can be called from board file. Not sure > I was thinking to move the call to fdt.c for the SoC, for example in the function of ft_cpu_setup(). York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Falcon mode with initrd
Stefano, You may perhaps be the most knowledgeable about Falcon mode based on the presentations I've found on the web. It seems to me that there is currently no support in U-Boot for using Falcon mode where the kernel is separate from the initrd. I see that the 'spl' command is passed the initrd_addr so that it can setup atags/fdt (I haven't followed through the code to understand what it does with this addr yet) but there is no support in any of the common/spl/spl_*.c files for loading anything other than args or kernel. Have you had any thoughts on this? It seems to me a new #define would need to be created per storage medium pointing to the offset/sector of initrd and used at compile time. Perhaps your thoughts have always been that if you want to use an initrd for falcon mode you must always build it into the kernel? Regards, Tim ___ 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 support for Intel Minnowboard Max
On 05/27 13:19, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote:
> > Hi Andrew,
> >
> > On 26 May 2015 at 13:52, Andrew Bradford
> > wrote:
> >> Hi Simon and Bin (sorry for bringing this back from the dead),
> >>
> >> But I have a question about fsp_configs.c down below:
> >>
> >> On 01/27 22:13, Simon Glass wrote:
> >> ->8---
> >>> diff --git a/arch/x86/cpu/baytrail/fsp_configs.c
> >>> b/arch/x86/cpu/baytrail/fsp_configs.c
> >>> new file mode 100644
> >>> index 000..86b6926
> >>> --- /dev/null
> >>> +++ b/arch/x86/cpu/baytrail/fsp_configs.c
> >>> @@ -0,0 +1,156 @@
> >>> +/*
> >>> + * Copyright (C) 2013, Intel Corporation
> >>> + * Copyright (C) 2014, Bin Meng
> >>> + *
> >>> + * SPDX-License-Identifier: Intel
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +/* ALC262 Verb Table - 10EC0262 */
> >>> +static const uint32_t verb_table_data13[] = {
> >>> + /* Pin Complex (NID 0x11) */
> >>> + 0x01171cf0,
> >>> + 0x01171d11,
> >>> + 0x01171e11,
> >>> + 0x01171f41,
> >>> + /* Pin Complex (NID 0x12) */
> >>> + 0x01271cf0,
> >>> + 0x01271d11,
> >>> + 0x01271e11,
> >>> + 0x01271f41,
> >>> + /* Pin Complex (NID 0x14) */
> >>> + 0x01471c10,
> >>> + 0x01471d40,
> >>> + 0x01471e01,
> >>> + 0x01471f01,
> >>> + /* Pin Complex (NID 0x15) */
> >>> + 0x01571cf0,
> >>> + 0x01571d11,
> >>> + 0x01571e11,
> >>> + 0x01571f41,
> >>> + /* Pin Complex (NID 0x16) */
> >>> + 0x01671cf0,
> >>> + 0x01671d11,
> >>> + 0x01671e11,
> >>> + 0x01671f41,
> >>> + /* Pin Complex (NID 0x18) */
> >>> + 0x01871c20,
> >>> + 0x01871d98,
> >>> + 0x01871ea1,
> >>> + 0x01871f01,
> >>> + /* Pin Complex (NID 0x19) */
> >>> + 0x01971c21,
> >>> + 0x01971d98,
> >>> + 0x01971ea1,
> >>> + 0x01971f02,
> >>> + /* Pin Complex (NID 0x1A) */
> >>> + 0x01a71c2f,
> >>> + 0x01a71d30,
> >>> + 0x01a71e81,
> >>> + 0x01a71f01,
> >>> + /* Pin Complex */
> >>> + 0x01b71c1f,
> >>> + 0x01b71d40,
> >>> + 0x01b71e21,
> >>> + 0x01b71f02,
> >>> + /* Pin Complex */
> >>> + 0x01c71cf0,
> >>> + 0x01c71d11,
> >>> + 0x01c71e11,
> >>> + 0x01c71f41,
> >>> + /* Pin Complex */
> >>> + 0x01d71c01,
> >>> + 0x01d71dc6,
> >>> + 0x01d71e14,
> >>> + 0x01d71f40,
> >>> + /* Pin Complex */
> >>> + 0x01e71cf0,
> >>> + 0x01e71d11,
> >>> + 0x01e71e11,
> >>> + 0x01e71f41,
> >>> + /* Pin Complex */
> >>> + 0x01f71cf0,
> >>> + 0x01f71d11,
> >>> + 0x01f71e11,
> >>> + 0x01f71f41,
> >>> +};
> >>> +
> >>> +/*
> >>> + * This needs to be in ROM since if we put it in CAR, FSP init loses it
> >>> when
> >>> + * it drops CAR.
> >>> + *
> >>> + * TODO(s...@chromium.org): Move to device tree when FSP allows it
> >>> + *
> >>> + * VerbTable: (RealTek ALC262)
> >>> + * Revision ID = 0xFF, support all steps
> >>> + * Codec Verb Table For AZALIA
> >>> + * Codec Address: CAd value (0/1/2)
> >>> + * Codec Vendor: 0x10EC0262
> >>> + */
> >>> +static const struct pch_azalia_verb_table azalia_verb_table[] = {
> >>> + {
> >>> + {
> >>> + 0x10ec0262,
> >>> + 0x,
> >>> + 0xff,
> >>> + 0x01,
> >>> + 0x000b,
> >>> + 0x0002,
> >>> + },
> >>> + verb_table_data13
> >>> + }
> >>> +};
> >>> +
> >>> +const struct pch_azalia_config azalia_config = {
> >>> + .pme_enable = 1,
> >>> + .docking_supported = 1,
> >>> + .docking_attached = 0,
> >>> + .hdmi_codec_enable = 1,
> >>> + .azalia_v_ci_enable = 1,
> >>> + .rsvdbits = 0,
> >>> + .azalia_verb_table_num = 1,
> >>> + .azalia_verb_table = azalia_verb_table,
> >>> + .reset_wait_timer_us = 300
> >>> +};
> >>> +
> >>> +void update_fsp_upd(struct upd_region *fsp_upd)
> >>> +{
> >>> + struct memory_down_data *mem;
> >>> +
> >>> + /*
> >>> + * Configure everything here to avoid the poor hard-pressed user
> >>> + * needing to run Intel's binary configuration tool. It may also
> >>> allow
> >>> + * us to support the 1GB single core variant easily.
> >>> + *
> >>> + * TODO(s...@chromium.org): Move to device tree
> >>> + */
> >>> + fsp_upd->mrc_init_tseg_size = 8;
> >>> + fsp_upd->mrc_init_mmio_size = 0x800;
> >>> + fsp_upd->emmc_boot_mode = 0xff;
> >>> + fsp_upd->enable_sdio = 1;
> >>> + fsp_upd->enable_sdcard = 1;
> >>> + fsp_upd->enable_hsuart0 = 1;
> >>> + fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
> >>> + fsp_upd->enable_i2_c0 = 0;
> >>> + fsp_upd->enable_i2_c2 = 0;
> >>> + fsp_upd->enable_i2_c3 = 0;
> >>> + fsp_upd->enable_i2_c4 = 0;
> >>> + fsp_upd->enable_xhci = 0;
> >>> + fsp_upd->igd_render_standby = 1;
> >>> +
> >>> + me
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Simon & Bin,
On 05/26 15:37, Simon Glass wrote:
> Hi Andrew,
>
> On 26 May 2015 at 13:52, Andrew Bradford wrote:
> > Hi Simon and Bin (sorry for bringing this back from the dead),
> >
> > But I have a question about fsp_configs.c down below:
> >
> > On 01/27 22:13, Simon Glass wrote:
> > ->8---
> >> +void update_fsp_upd(struct upd_region *fsp_upd)
> >> +{
> >> + struct memory_down_data *mem;
> >> +
> >> + /*
> >> + * Configure everything here to avoid the poor hard-pressed user
> >> + * needing to run Intel's binary configuration tool. It may also
> >> allow
> >> + * us to support the 1GB single core variant easily.
> >> + *
> >> + * TODO(s...@chromium.org): Move to device tree
> >> + */
> >> + fsp_upd->mrc_init_tseg_size = 8;
> >> + fsp_upd->mrc_init_mmio_size = 0x800;
> >> + fsp_upd->emmc_boot_mode = 0xff;
> >> + fsp_upd->enable_sdio = 1;
> >> + fsp_upd->enable_sdcard = 1;
> >> + fsp_upd->enable_hsuart0 = 1;
> >> + fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
> >> + fsp_upd->enable_i2_c0 = 0;
> >> + fsp_upd->enable_i2_c2 = 0;
> >> + fsp_upd->enable_i2_c3 = 0;
> >> + fsp_upd->enable_i2_c4 = 0;
> >> + fsp_upd->enable_xhci = 0;
> >> + fsp_upd->igd_render_standby = 1;
> >> +
> >> + mem = &fsp_upd->memory_params;
> >> + mem->enable_memory_down = 1;
> >> + mem->dram_speed = 1;
> >> + mem->dimm_width = 1;
> >> + mem->dimm_density = 2;
> >> + mem->dimm_tcl = 0xb;
> >> + mem->dimm_trpt_rcd = 0xb;
> >> + mem->dimm_twr = 0xc;
> >> + mem->dimm_twtr = 6;
> >> + mem->dimm_trrd = 6;
> >> + mem->dimm_trtp = 6;
> >> + mem->dimm_tfaw = 0x14;
> >> +}
> >
> > I am trying to move this fsp upd to use device tree as I am trying to
> > create a patch set to add the Intel Valley Island E38xx board (which
> > uses a SODIMM rather than memory down). In doing so, I've found that
> > global data doesn't seem to be available when update_fsp_upd() is called
> > and generally it seems that gd->fdt_blob is used to get a reference to
> > the flattened device tree.
> >
> > I'm not super familiar with device tree, but I was attempting to use
> > fdtdec_next_compatible(gd->fdt_blob, 0, COMPAT_INTEL_BAYTRAIL_FSP) in a
> > similar way that Quark does in my patchset (I've properly created the
> > COMPAT_INTEL_BAYTRAIL_FSP define and some device tree nodes in my dts
> > file). When I call fdtdec_next_compatible() the board does something
> > which I'm unable to debug (Valley Island does not have the early UART
> > pins connected so I have no early UART capability) but things just seem
> > to stop.
> >
> > In manually tracing the calls which lead to update_fsp_upd(), it seems
> > that we haven't yet set up global data, so it makes sense that I can't
> > reference it. But the device tree should be available in NOR flash or
> > in some other way which we can access in order to get the FSP UPD
> > settings.
> >
> > Is there a simple way to access the device tree while it's still in NOR
> > flash so I can avoid using gd? Or can global data be setup prior to
> > calling update_fsp_upd() (I believe we're still in CAR at this point)?
> > Or am I misunderstanding something basic here?
> >
> > Did you have a rough outline of how this could be moved to device tree?
>
> This is a bit tricky. I would like to move fsp_init() later in the
> init sequence (e.g. to board_init_f()). See this TODO in the code:
>
> /*
> * TODO:
> *
> * According to FSP architecture spec, the fsp_init() will not return
> * to its caller, instead it requires the bootloader to provide a
> * so-called continuation function to pass into the FSP as a parameter
> * of fsp_init, and fsp_init() will call that continuation function
> * directly.
> *
> * The call to fsp_init() may need to be moved out of the car_init()
> * to cpu_init_f() with the help of some inline assembly codes.
> * Note there is another issue that fsp_init() will setup another stack
> * using the fsp_init parameter stack_top after DRAM is initialized,
> * which means any data on the previous stack (on the CAR) gets lost
> * (ie: U-Boot global_data). FSP is supposed to support such scenario,
> * however it does not work. This should be revisited in the future.
> */
>
> The primary issues are:
> 1. The need to recover the global_data
> 2. The need to change to a new stack
>
> Re 1, my reading of the HOB stuff is that it is supposed to provide
> you with a pointer to the CAR RAM (all ~128KB of it) so that you can
> go back and find your old stack (and in our case, global_data).
>
> Bin mentioned that this doesn't work - his is the comment above after
> I asked him about it.
OK, if it doesn't work then that's frustrating.
I do see that HOB 15 on my Valley Island board has the right GUID to be
the FSP_BOOTLOADER_TEMPORARY_MEMORY_HOB and its size is 16408. So that
has me hopeful, but likely I'll run into similar things that you two
have s
Re: [U-Boot] [PATCH] pci: imx: display message if no pcie link
Hi Tim,
On 27/05/2015 15:21, Tim Harvey wrote:
> On Fri, May 8, 2015 at 3:17 PM, Tim Harvey wrote:
>> If CONFIG_PCI_SCAN_SHOW enabled then lets print a message of no link was
>> detected.
>>
>> Signed-off-by: Tim Harvey
>> ---
>> drivers/pci/pcie_imx.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c
>> index fd7e4d4..ca485ba 100644
>> --- a/drivers/pci/pcie_imx.c
>> +++ b/drivers/pci/pcie_imx.c
>> @@ -588,7 +588,9 @@ static int imx_pcie_link_up(void)
>> udelay(10);
>> count++;
>> if (count >= 2000) {
>> - debug("phy link never came up\n");
>> +#ifdef CONFIG_PCI_SCAN_SHOW
>> + puts("PCI: pcie phy link never came up\n");
>> +#endif
>> debug("DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
>> readl(MX6_DBI_ADDR + PCIE_PHY_DEBUG_R0),
>> readl(MX6_DBI_ADDR + PCIE_PHY_DEBUG_R1));
>> --
>> 1.9.1
>>
>
> Stefano,
>
> I probably should have sent this one to you directly being an imx driver.
>
I have seen the patch and the related discussion who should take care of
it ;-)
Do not worry - I set myself as delegate for this and I will merge it soon.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: display header for bus scan
On Fri, May 8, 2015 at 3:16 PM, Tim Harvey wrote:
> If we are displaying detected PCI devices (CONFIG_PCI_SCAN_SHOW) display
> a 'PCI:' header prior to scan.
>
> Signed-off-by: Tim Harvey
> ---
> drivers/pci/pci.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e1296ca..7f53eb0 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -772,6 +772,10 @@ int pci_hose_scan(struct pci_controller *hose)
> }
> #endif /* CONFIG_PCI_BOOTDELAY */
>
> +#ifdef CONFIG_PCI_SCAN_SHOW
> + puts("PCI:\n");
> +#endif
> +
> /*
> * Start scan at current_busno.
> * PCIe will start scan at first_busno+1.
> --
> 1.9.1
>
Tom,
I probably should have sent this one directly to you as there doesn't
seem to be a clear PCI maintainer. If CONFIG_PCI_SCAN_SHOW is defined
then a multi-line tree-like display is printed showing the bus
enumeration - this just puts a header before it so it appears like the
rest of the subsystems.
Regards,
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: imx: display message if no pcie link
On Fri, May 8, 2015 at 3:17 PM, Tim Harvey wrote:
> If CONFIG_PCI_SCAN_SHOW enabled then lets print a message of no link was
> detected.
>
> Signed-off-by: Tim Harvey
> ---
> drivers/pci/pcie_imx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c
> index fd7e4d4..ca485ba 100644
> --- a/drivers/pci/pcie_imx.c
> +++ b/drivers/pci/pcie_imx.c
> @@ -588,7 +588,9 @@ static int imx_pcie_link_up(void)
> udelay(10);
> count++;
> if (count >= 2000) {
> - debug("phy link never came up\n");
> +#ifdef CONFIG_PCI_SCAN_SHOW
> + puts("PCI: pcie phy link never came up\n");
> +#endif
> debug("DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
> readl(MX6_DBI_ADDR + PCIE_PHY_DEBUG_R0),
> readl(MX6_DBI_ADDR + PCIE_PHY_DEBUG_R1));
> --
> 1.9.1
>
Stefano,
I probably should have sent this one to you directly being an imx driver.
Regards,
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_mmc: add error message to pass to set_default_env
On Fri, May 8, 2015 at 2:52 PM, Tim Harvey wrote:
> Add an error message that gets passed to set_default_env() like
> env_nand implements. This message is displayed to the user as the
> reason for falling back to the default environment.
>
> Signed-off-by: Tim Harvey
> ---
> common/env_mmc.c | 40
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/common/env_mmc.c b/common/env_mmc.c
> index 14648e3..6c4ce2f 100644
> --- a/common/env_mmc.c
> +++ b/common/env_mmc.c
> @@ -90,19 +90,18 @@ static int mmc_set_env_part(struct mmc *mmc)
> static inline int mmc_set_env_part(struct mmc *mmc) {return 0; };
> #endif
>
> -static int init_mmc_for_env(struct mmc *mmc)
> +static const char *init_mmc_for_env(struct mmc *mmc)
> {
> - if (!mmc) {
> - puts("No MMC card found\n");
> - return -1;
> - }
> + if (!mmc)
> + return "No MMC card found";
>
> - if (mmc_init(mmc)) {
> - puts("MMC init failed\n");
> - return -1;
> - }
> + if (mmc_init(mmc))
> + return "MMC init failed";
> +
> + if (mmc_set_env_part(mmc))
> + return "MMC partition switch failed";
>
> - return mmc_set_env_part(mmc);
> + return NULL;
> }
>
> static void fini_mmc_for_env(struct mmc *mmc)
> @@ -143,9 +142,13 @@ int saveenv(void)
> struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
> u32 offset;
> int ret, copy = 0;
> + const char *errmsg;
>
> - if (init_mmc_for_env(mmc))
> + errmsg = init_mmc_for_env(mmc);
> + if (errmsg) {
> + printf("%s\n", errmsg);
> return 1;
> + }
>
> ret = env_export(env_new);
> if (ret)
> @@ -213,6 +216,7 @@ void env_relocate_spec(void)
> env_t *ep;
> int ret;
> int dev = CONFIG_SYS_MMC_ENV_DEV;
> + const char *errmsg = NULL;
>
> ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env1, 1);
> ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env2, 1);
> @@ -223,7 +227,8 @@ void env_relocate_spec(void)
>
> mmc = find_mmc_device(dev);
>
> - if (init_mmc_for_env(mmc)) {
> + errmsg = init_mmc_for_env(mmc);
> + if (errmsg) {
> ret = 1;
> goto err;
> }
> @@ -249,6 +254,7 @@ void env_relocate_spec(void)
> (crc32(0, tmp_env2->data, ENV_SIZE) == tmp_env2->crc);
>
> if (!crc1_ok && !crc2_ok) {
> + errmsg = "!bad CRC";
> ret = 1;
> goto fini;
> } else if (crc1_ok && !crc2_ok) {
> @@ -284,8 +290,7 @@ fini:
> fini_mmc_for_env(mmc);
> err:
> if (ret)
> - set_default_env(NULL);
> -
> + set_default_env(errmsg);
> #endif
> }
> #else /* ! CONFIG_ENV_OFFSET_REDUND */
> @@ -297,6 +302,7 @@ void env_relocate_spec(void)
> u32 offset;
> int ret;
> int dev = CONFIG_SYS_MMC_ENV_DEV;
> + const char *errmsg;
>
> #ifdef CONFIG_SPL_BUILD
> dev = 0;
> @@ -304,7 +310,8 @@ void env_relocate_spec(void)
>
> mmc = find_mmc_device(dev);
>
> - if (init_mmc_for_env(mmc)) {
> + errmsg = init_mmc_for_env(mmc);
> + if (errmsg) {
> ret = 1;
> goto err;
> }
> @@ -315,6 +322,7 @@ void env_relocate_spec(void)
> }
>
> if (read_env(mmc, CONFIG_ENV_SIZE, offset, buf)) {
> + errmsg = "!read failed";
> ret = 1;
> goto fini;
> }
> @@ -326,7 +334,7 @@ fini:
> fini_mmc_for_env(mmc);
> err:
> if (ret)
> - set_default_env(NULL);
> + set_default_env(errmsg);
> #endif
> }
> #endif /* CONFIG_ENV_OFFSET_REDUND */
> --
> 1.9.1
>
Tom,
I'm thinking I should have sent the above patch to you for lack of a
clear maintainer of this file/section?
Regards,
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: baytrail: PCI is not always mapped to end of ram
Hi Bin, On 05/27 12:21, Bin Meng wrote: > Hi Andrew, > > On Tue, May 26, 2015 at 8:17 PM, Andrew Bradford > wrote: > > Hi Bin, > > > > On 05/23 23:50, Bin Meng wrote: > >> +Simon. > >> > >> Hi Andrew, > >> > >> On Sat, May 23, 2015 at 3:09 AM, wrote: > >> > From: Andrew Bradford > >> > > >> > PCI on Intel Baytrail is mapped to 0x8000, which is not always at > >> > the end of SDRAM, such as when running with 4 GiB of SDRAM. The PCI bus > >> > memory mapping must stay within low memory and so when running with > > >> > 2 GiB of SDRAM, there is a hole in the SDRAM between 2 GiB and 4 GiB for > >> > memory mapped IO, such as PCI. > >> > >> Are you saying that if we mount 4GB DDR DIMM on the MinnowMax board, > >> the Intel FSP will only put 0~2G as system RAM space, and leave 2G~4G > >> as PCI address and other I/Os? > > > > Yes. If you mount 4 GiB of SDRAM onto an E3800 processor, then physical > > addresses from 0 to just below 2 GiB will be SDRAM (as per the HOBs) and > > also from 4 GiB to 6 GiB (also verified via the HOBs). The space from 2 > > GiB to 4 GiB will be mapped as various other regions. > > Ah, that's exactly the information I want :) > > > If you see section 4.1.1.1 (page 71 in the January 2015, Revision 3.6) > > E3800 datasheet, it shows that from 2 GiB to 4 GiB is mapped for PCI, > > Abort Page, Local APIC, and the Boot Vector. There's a lot of space in > > this area which appears unused, so I'm unsure as to why the area is so > > large. > > > > I have an Intel Valley Island board with E3825 and a 4 GiB SODIMM. I'm > > working on getting patches ready for this board but found that if I > > enabled all 4 GiB of SDRAM that the PCI bus would not function > > correctly. With this patch then the PCI bus functions (I'm able to do > > network operations with the RTL8111 Ethernet adapter). > > > >> I see from minnowmax.h, the PCI address starts from 0xd000. > >> > >> #define CONFIG_PCI_MEM_BUS 0xd000 > >> #define CONFIG_PCI_MEM_PHYS CONFIG_PCI_MEM_BUS > >> #define CONFIG_PCI_MEM_SIZE 0x1000 > >> > >> #define CONFIG_PCI_PREF_BUS 0xc000 > >> #define CONFIG_PCI_PREF_PHYSCONFIG_PCI_PREF_BUS > >> #define CONFIG_PCI_PREF_SIZE0x1000 > > > > I see that hose->regions+0 is set to CONFIG_PCI_MEM_BUS and > > hose->regions+2 is set to CONFIG_PCI_PREF_BUS. However I'm modifying > > hose->regions+3. So the values from minnowmax.h *are* being used. I'm > > not yet that familiar with PCI configuration, so likely I'm not fully > > understanding how u-boot sets this up. > > > > The regions+3 is used by the inbound access, eg: PCI device access to > system memory. > > > Possibly my address of 0x8000 is not correct, even though it works > > for me. But 0x8000 is where it was being placed before, since it > > was going at the end of SDRAM (2GiB on minnowmax). > > > > You understanding is correct. We should only open 2GiB inbound memory > window for PCI devices. But, if you have less than 2 GiB of memory, my patch in theory *could* break things, right?. It seems like a better approach would be to limit the size to the lesser of 0x8000 and gd->ram_size. Does that make sense? > > If I artificially limit the amount of SDRAM by setting the fsp > > configuration to memory-down and then setting the DRAM configuration > > values such that I mimmic 1 GiB or 2 GiB of SDRAM, having my patch still > > provides access to the PCI bus, so with my patch there should be no > > adverse affects on E3800 systems that have less than 4 GiB of SDRAM. > > But without my patch, when running with >=4 GiB of SDRAM, PCI accesses > > end up returning "pci_hose_bus_to_phys: invalid physical address" > > errors. > > > > Yes, this all makes sense, so > > Reviewed-by: Bin Meng Thanks! -Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] soft-i2c and i2c-gpio issues with at91
Hi all, On 05/26/2015 07:23 PM, Matt Wood wrote: Thank you Simon. Getting there, but now I get a data abort and system reset when trying to set the i2c bus. I need to chase this down, but if you have any suggestions I'd appreciate it. Below is the output of dm tree and dm uclass. Thanks, Matt. U-Boot> i2c dev 3 ...snip... You should first be sure that dm gpio for your board is working properly. Are you able to test the output state of some GPIOs on your board, e.g. by the LED? If yes, then you can test it with gpio command or just using some dm_gpio..() calls for some GPIO with the LED. And about your data abort. I can't check your board config/driver at present but will try to give you a quick suggestion. So, when you type i2c dev 3, then the i2c device: "gpio-i2c@1 @ 3fb58348, seq -1, (req 3)" with alias number 3 (as you requested) is probed. One of the routine is calling the function: * i2c_gpio_ofdata_to_platdata() in gpio-i2c.c - probably succeeds. Then, * post_probe() of i2c uclass is called, and next: * i2c_post_probe() - from drivers/i2c/i2c-uclass.c, this goes to: * i2c_gpio_set_bus_speed() - from gpio-i2c.c And here probably starts the magic which ends by data abort. The driver just operates on GPIOs defined in your device tree. If you enable the gpio command (CONFIG_CMD_GPIO), then you can easy test, that change state of some GPIO pins works properly, or you can make some test by printing the results of dm_gpio..() calls in somewhere. Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx: missing CONFIG_NET after consolidation patches
commit fd3056337e6fcc140f400e11edd33f6f1cb37de1 "Use env callbacks for net variables" has a side effect on i.MX6 boards because they do not set CONFIG_NET: the ip address results not set, but it is stored in the environment. => pri ipaddr ipaddr=192.168.178.66 => ping 192.168.178.1 *** ERROR: `ipaddr' not set ping failed; host 192.168.178.1 is not alive Setting CONFIG_NET solves this issue. Reported-by: Heiko Schoker Signed-off-by: Stefano Babic --- include/configs/mx6_common.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 233c6d2..3d859cf 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -105,4 +105,7 @@ #define CONFIG_FSL_ESDHC #define CONFIG_FSL_USDHC +/* NET */ +#define CONFIG_NET + #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vexpress64: let Juno wait for root device
On Thu, May 14, 2015 at 5:38 PM, Linus Walleij wrote: > The Juno reference design typically plugs the root FS > on a USB stick. We need to wait a bit for the root to > appear so tell this on the default command line. > > Signed-off-by: Linus Walleij Ping on this. Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vexpress64: fix various memory issues
On Mon, May 11, 2015 at 10:03 AM, Linus Walleij wrote: > The ARM Trusted Firmware or other security solutions are > eating memory from the top of the physical SDRAM1 space, > moving backward from 0x, currently occupying e.g. > 0xfe00-0x with Trusted Firmware. > > This solution to reserving memory for secure world is not > optimal, so we need to think of how the secure world and > earlier boot stages should communicate to U-Boot what > memory they are eating up. For now let's just put 16MB > aside. > > Also enable the memory test command and define start and > end of the test range so we can check that we actually have > all that memory available and working. > > Suggested-by: Axel Haslam > Signed-off-by: Linus Walleij Ping on this. Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] vexpress64: use uncompressed kernel by default
The foundation model (FVP) emulator nominally boots using
a clean, uncompressed kernel and the "booti" command. Augment
the default U-Boot script to do this.
Signed-off-by: Linus Walleij
---
include/configs/vexpress_aemv8a.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/configs/vexpress_aemv8a.h
b/include/configs/vexpress_aemv8a.h
index 2b41fc5e361e..f7bb7236b73d 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -220,7 +220,7 @@
#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
#define CONFIG_EXTRA_ENV_SETTINGS \
- "kernel_name=uImage\0" \
+ "kernel_name=Image\0" \
"kernel_addr=0x8000\0" \
"initrd_name=ramdisk.img\0" \
"initrd_addr=0x8800\0" \
@@ -234,11 +234,11 @@
"loglevel=9"
#define CONFIG_BOOTCOMMAND "smhload ${kernel_name} ${kernel_addr}; " \
- "smhload ${fdt_name} $fdt_addr; " \
- "smhload ${initrd_name} $initrd_addr
initrd_end; " \
- "fdt addr $fdt_addr; fdt resize; " \
- "fdt chosen $initrd_addr $initrd_end; " \
- "bootm $kernel_addr - $fdt_addr"
+ "smhload ${fdt_name} ${fdt_addr}; " \
+ "smhload ${initrd_name} ${initrd_addr}
initrd_end; " \
+ "fdt addr ${fdt_addr}; fdt resize; " \
+ "fdt chosen ${initrd_addr} ${initrd_end}; " \
+ "booti $kernel_addr - $fdt_addr"
#define CONFIG_BOOTDELAY 1
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
