[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 h...@denx.de Signed-off-by: Stefano Babic sba...@denx.de --- 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] 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 RD 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
Re: [U-Boot] [PATCH] pci: display header for bus scan
On Fri, May 8, 2015 at 3:16 PM, Tim Harvey thar...@gateworks.com wrote: If we are displaying detected PCI devices (CONFIG_PCI_SCAN_SHOW) display a 'PCI:' header prior to scan. Signed-off-by: Tim Harvey thar...@gateworks.com --- 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] 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 and...@bradfordembedded.com wrote: Hi Bin, On 05/23 23:50, Bin Meng wrote: +Simon. Hi Andrew, On Sat, May 23, 2015 at 3:09 AM, and...@bradfordembedded.com wrote: From: Andrew Bradford andrew.bradf...@kodakalaris.com 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 bmeng...@gmail.com Thanks! -Andrew ___ 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 thar...@gateworks.com 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 thar...@gateworks.com
---
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] pci: imx: display message if no pcie link
On Fri, May 8, 2015 at 3:17 PM, Tim Harvey thar...@gateworks.com wrote:
If CONFIG_PCI_SCAN_SHOW enabled then lets print a message of no link was
detected.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
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] 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 thar...@gateworks.com wrote:
If CONFIG_PCI_SCAN_SHOW enabled then lets print a message of no link was
detected.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
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 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 michal.si...@xilinx.com wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Set the data bus width to 64-bit AMBA Databus width in config register. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- 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 michal.si...@xilinx.com wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Set the data bus width to 64-bit AMBA Databus width in config register. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- 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] soft-i2c and i2c-gpio issues with at91
On Wed, May 27, 2015 at 7:32 AM, Przemyslaw Marczak p.marc...@samsung.com 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 RD 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] 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] Pull request: u-boot-net.git master
Hi Tom, On Tue, May 26, 2015 at 9:02 PM, Tom Rini tr...@konsulko.com 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 v2 3/6] x86: Make QEMU the default vendor
Hi Bin, On 27 May 2015 at 09:52, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 12:01 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:57 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 May 2015 at 14:42, Simon Glass s...@chromium.org wrote: On 7 May 2015 at 07:34, Bin Meng bmeng...@gmail.com wrote: Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- 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=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 Bin, On Wed, May 27, 2015 at 10:58 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:53 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On 27 May 2015 at 09:52, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 12:01 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:57 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 May 2015 at 14:42, Simon Glass s...@chromium.org wrote: On 7 May 2015 at 07:34, Bin Meng bmeng...@gmail.com wrote: Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- 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=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
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 s...@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 22:06, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:59 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 21:55, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com
---
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 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
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 bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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 v2 3/6] x86: Make QEMU the default vendor
Hi Simon, On Wed, May 27, 2015 at 12:01 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:57 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 May 2015 at 14:42, Simon Glass s...@chromium.org wrote: On 7 May 2015 at 07:34, Bin Meng bmeng...@gmail.com wrote: Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- 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=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 v2 3/6] x86: Make QEMU the default vendor
Hi Simon, On Wed, May 27, 2015 at 11:53 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On 27 May 2015 at 09:52, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 12:01 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:57 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 May 2015 at 14:42, Simon Glass s...@chromium.org wrote: On 7 May 2015 at 07:34, Bin Meng bmeng...@gmail.com wrote: Now that we have QEMU support, make it the default vendor in the 'make menuconfig' screen. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- 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=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] [PATCH] kbuild: define DO_DEPS_ONLY for u-boot.cfg to fix build error
On 25 May 2015 at 21:51, Masahiro Yamada yamada.masah...@socionext.com 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 yamada.masah...@socionext.com --- Makefile | 2 +- scripts/Makefile.spl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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] x86: Fix regression build issue of coreboot-x86_defconfig
Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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 Bin,
On 26 May 2015 at 22:06, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:59 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 21:55, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com
---
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
[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 bmeng...@gmail.com --- 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 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 s...@chromium.org wrote: Hi Bin, On 26 May 2015 at 21:50, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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 Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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] [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 s...@chromium.org wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@bradfordembedded.com
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 bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier: Intel
+ */
+
+#include common.h
+#include asm/arch/fsp/azalia.h
+#include asm/fsp/fsp_support.h
+
+/* 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;
+
+ 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).
[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
Hi Simon Bin,
On 05/26 15:37, Simon Glass wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@bradfordembedded.com 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 seen before.
Any pointers on why it was determined that the CAR RAM pointer doesn't
work correctly so I can avoid spending too much time investigating
things which have already been done?
But if it could be made to work,
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 bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:42 PM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 22:06, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:59 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 26 May 2015 at 21:55, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com
---
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] 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] [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 joe.hershber...@ni.com Cc: Masahiro Yamada yamada.masah...@socionext.com 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] [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 bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:37 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On 26 May 2015 at 21:50, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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
[U-Boot] [PATCH v2 0/2] kbuild: create a symbolic link only when necessary
1/2: refactors a little because NDS32 actually need not the symbolic link 2/2: introduce a new config to avoid broken symbolic links. Changes in v2: - Use 'ifdef CONFIG_CREATE_ARCH_SYMLINK' for readability Masahiro Yamada (2): nds32: include asm/arch-*/*.h instead of asm/arch/*.h kbuild: create symbolic link only for ARM, SPARC, PowerPC, x86 arch/Kconfig | 6 ++ arch/powerpc/Kconfig | 3 +++ include/configs/adp-ag101.h | 2 +- include/configs/adp-ag101p.h | 2 +- include/configs/adp-ag102.h | 2 +- scripts/Makefile.autoconf| 2 ++ 6 files changed, 14 insertions(+), 3 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] nds32: include asm/arch-*/*.h instead of asm/arch/*.h
There are only two SoC-specific headers for this architecture: - arch/nds32/include/asm/arch-ag101/ag101.h - arch/nds32/include/asm/arch-ag102/ag102.h Those two have different file names, so there is no advantage to include them via symbolic linked directory. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Changes in v2: None include/configs/adp-ag101.h | 2 +- include/configs/adp-ag101p.h | 2 +- include/configs/adp-ag102.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/adp-ag101.h b/include/configs/adp-ag101.h index e318c75..f70ee10 100644 --- a/include/configs/adp-ag101.h +++ b/include/configs/adp-ag101.h @@ -9,7 +9,7 @@ #ifndef __CONFIG_H #define __CONFIG_H -#include asm/arch/ag101.h +#include asm/arch-ag101/ag101.h /* * CPU and Board Configuration Options diff --git a/include/configs/adp-ag101p.h b/include/configs/adp-ag101p.h index 24904b0..60a5038 100644 --- a/include/configs/adp-ag101p.h +++ b/include/configs/adp-ag101p.h @@ -9,7 +9,7 @@ #ifndef __CONFIG_H #define __CONFIG_H -#include asm/arch/ag101.h +#include asm/arch-ag101/ag101.h /* * CPU and Board Configuration Options diff --git a/include/configs/adp-ag102.h b/include/configs/adp-ag102.h index 39f7a3c..ffd5d33 100644 --- a/include/configs/adp-ag102.h +++ b/include/configs/adp-ag102.h @@ -8,7 +8,7 @@ #ifndef __CONFIG_H #define __CONFIG_H -#include asm/arch/ag102.h +#include asm/arch-ag102/ag102.h /* * CPU and Board Configuration Options -- 1.9.1 ___ 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
Hi York, 1. board/freescale/ls2085a/ls2085a.c is for board ls2085a_emu like ls2085aqds.c not SoC file. But I am not sure whether emulator board should call this function. 2. ft_pcie_setup(blob, bd) should be changed to ft_pci_setup(blob, bd) ft_pci_setup is the common function name defined in common.h Thanks, Minghuan -Original Message- From: Sun York-R58495 Sent: Tuesday, May 26, 2015 11:54 PM To: Kushwaha Prabhakar-B32579; u-boot@lists.denx.de Cc: Lian Minghuan-B31939 Subject: Re: [PATCH 05/20] armv8/ls2085a: call ft_pcie_setup() to change dts status Prabhakar and Minghuan, On 05/18/2015 12:08 AM, Prabhakar Kushwaha wrote: From: Minghuan Lian minghuan.l...@freescale.com 1. The patch call ft_pcie_setup() to disable PCIe dts node if corresponding PCIe controller is disabled according to RCW. 2. Fix LS2085a PCIe compatible Signed-off-by: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- board/freescale/ls2085a/ls2085a.c | 4 board/freescale/ls2085aqds/ls2085aqds.c | 4 board/freescale/ls2085ardb/ls2085ardb.c | 4 include/configs/ls2085a_common.h| 3 ++- 4 files changed, 14 insertions(+), 1 deletion(-) diff --git a/board/freescale/ls2085a/ls2085a.c b/board/freescale/ls2085a/ls2085a.c index dd0acf2..afb99d1 100644 --- a/board/freescale/ls2085a/ls2085a.c +++ b/board/freescale/ls2085a/ls2085a.c @@ -142,6 +142,10 @@ int ft_board_setup(void *blob, bd_t *bd) fsl_mc_ldpaa_exit(bd); #endif +#ifdef CONFIG_PCI + ft_pcie_setup(blob, bd); +#endif + 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. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/10 v3] i.MX6: move duplicated options to mx6_common to standardise mx6 config
Hi Fabio, On 27/05/2015 04:08, Fabio Estevam wrote: On Tue, May 26, 2015 at 10:45 PM, Fabio Estevam feste...@gmail.com wrote: On Tue, May 26, 2015 at 11:06 AM, Stefano Babic sba...@denx.de wrote: Hi Peter, Heiko, On 26/05/2015 15:23, Peter Robinson wrote: Please do, getting them applied so we can move forward would be great. Ok, all boards compile fine now - I have pushed all changes. I noticed that this series broke warp board and the board does not boot anymore. Reverting this series I am able to boot it again. Ok, so the problem is commit 8183058188c (imx6: centralise common boot options in mx6_common.h), as it changes all mx6 SoCs to use CONFIG_LOADADDR=0x1200, but this is not correct for mx6sx and mx6sl that should use 0x8200 instead. urgh...thanks to have solved this, I will pick up your patches 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
[U-Boot] [PATCH v2 2/2] kbuild: create symbolic link only for ARM, SPARC, PowerPC, x86
The symbolic link to SoC/CPU specific header directory is created during the build, while it is only necessary for ARM, SPARC, x86, and some CPUs of PowerPC. For the other architectures, it just results in a broken symbolic link. Introduce CONFIG_CREATE_ARCH_SYMLINK to not create unneeded symbolic links. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Changes in v2: - Use 'ifdef CONFIG_CREATE_ARCH_SYMLINK' for readability arch/Kconfig | 6 ++ arch/powerpc/Kconfig | 3 +++ scripts/Makefile.autoconf | 2 ++ 3 files changed, 11 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 200588a..c495267 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1,3 +1,6 @@ +config CREATE_ARCH_SYMLINK + bool + config HAVE_GENERIC_BOARD bool @@ -18,6 +21,7 @@ config ARC config ARM bool ARM architecture + select CREATE_ARCH_SYMLINK select HAVE_PRIVATE_LIBGCC select HAVE_GENERIC_BOARD select SUPPORT_OF_CONTROL @@ -83,9 +87,11 @@ config SH config SPARC bool SPARC architecture + select CREATE_ARCH_SYMLINK config X86 bool x86 architecture + select CREATE_ARCH_SYMLINK select HAVE_PRIVATE_LIBGCC select HAVE_GENERIC_BOARD select SYS_GENERIC_BOARD diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 3b3f446..18451d3 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -22,9 +22,11 @@ config MPC8260 config MPC83xx bool MPC83xx + select CREATE_ARCH_SYMLINK config MPC85xx bool MPC85xx + select CREATE_ARCH_SYMLINK config MPC86xx bool MPC86xx @@ -34,6 +36,7 @@ config 8xx config 4xx bool PPC4xx + select CREATE_ARCH_SYMLINK endchoice diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf index f054081..7387654 100644 --- a/scripts/Makefile.autoconf +++ b/scripts/Makefile.autoconf @@ -106,6 +106,7 @@ include/config.h: scripts/Makefile.autoconf create_symlink FORCE # Otherwise, create a symbolic link to arch/$(ARCH)/include/asm/arch-$(SOC). PHONY += create_symlink create_symlink: +ifdef CONFIG_CREATE_ARCH_SYMLINK ifneq ($(KBUILD_SRC),) $(Q)mkdir -p include/asm $(Q)if [ -d $(KBUILD_SRC)/arch/$(ARCH)/mach-$(SOC)/include/mach ]; then \ @@ -122,6 +123,7 @@ else fi; \ ln -fsn $$dest arch/$(ARCH)/include/asm/arch endif +endif PHONY += FORCE FORCE: -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6_common: Fix LOADADDR and SYS_TEXT_BASE for MX6SL and MX6SX
Hi Fabio, On 27/05/2015 04:22, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Commit 8183058188cd2d942 (imx6: centralise common boot options in mx6_common.h) broke boot on mx6sl and mx6sx by assuming that all mx6 SoCs use the same LOADADDR/SYS_TEXT_BASE range, which is not correct. DDR on mx6sx/mx6sl starts at 0x8000. Adjust LOADADDR/SYS_TEXT_BASE to the proper values for mx6sx/mx6sl, so that these SoCs can boot again. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6_common.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 233c6d2..bd16ec2 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -53,10 +53,15 @@ #define CONFIG_REVISION_TAG /* Boot options */ +#if (defined(CONFIG_MX6SX) || defined(CONFIG_MX6SL)) +#define CONFIG_LOADADDR 0x8200 +#define CONFIG_SYS_TEXT_BASE 0x8780 +#else #define CONFIG_LOADADDR 0x1200 +#define CONFIG_SYS_TEXT_BASE 0x1780 +#endif #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR #ifndef CONFIG_SYS_TEXT_BASE -#define CONFIG_SYS_TEXT_BASE 0x1780 #endif #ifndef CONFIG_BOOTDELAY #define CONFIG_BOOTDELAY 3 Acked-by: Stefano Babic sba...@denx.de 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] x86: Fix regression build issue of coreboot-x86_defconfig
HI Bin, On May 27, 2015 8:41 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Thu, May 28, 2015 at 7:25 AM, Simon Glass s...@chromium.org wrote: Hi, On 27 May 2015 at 10:27, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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] 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 h...@denx.de s/ok/och ;-) Signed-off-by: Stefano Babic sba...@denx.de --- 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 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 vikas.mano...@st.com
---
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();
+
[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 h...@denx.de --- 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 7:25 AM, Simon Glass s...@chromium.org wrote: Hi, On 27 May 2015 at 10:27, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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
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 s...@chromium.org wrote: Hi, On 27 May 2015 at 10:27, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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
[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 vikas.mano...@st.com --- 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 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 vikas.mano...@st.com
---
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
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 joe.hershber...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 6:25 PM, Simon Glass s...@chromium.org wrote: Hi, On 27 May 2015 at 10:27, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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 Simon, On Thu, May 28, 2015 at 10:55 AM, Simon Glass s...@chromium.org wrote: HI Bin, On May 27, 2015 8:41 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Thu, May 28, 2015 at 7:25 AM, Simon Glass s...@chromium.org wrote: Hi, On 27 May 2015 at 10:27, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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, On 27 May 2015 at 10:27, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:21 AM, Bin Meng bmeng...@gmail.com wrote: Hi Joe, On Thu, May 28, 2015 at 12:13 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Bin, On Wed, May 27, 2015 at 11:01 AM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Wed, May 27, 2015 at 11:55 PM, Bin Meng bmeng...@gmail.com 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 bmeng...@gmail.com --- 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 s...@denx.de Cc: Masahiro Yamada yamada.masah...@socionext.com Cc: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org 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] 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 yegorsli...@googlemail.com 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 yegorsli...@googlemail.com Signed-off-by: Felipe Balbi ba...@ti.com 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] [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 enric.balle...@collabora.com 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
[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 linus.wall...@linaro.org
---
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
Re: [U-Boot] [PATCH] vexpress64: fix various memory issues
On Mon, May 11, 2015 at 10:03 AM, Linus Walleij linus.wall...@linaro.org 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 ahas...@baylibre.com Signed-off-by: Linus Walleij linus.wall...@linaro.org 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: let Juno wait for root device
On Thu, May 14, 2015 at 5:38 PM, Linus Walleij linus.wall...@linaro.org 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 linus.wall...@linaro.org Ping on this. Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
