October 2013 - U-Boot

[U-Boot] [PATCH v2 0/5] env: Add support for environment files
by Simon Glass 25 Oct '13

25 Oct '13

At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text to this file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. This series adds a feature that brings in a .env file associated with the board config, if present. To use it, create a file in a board/<vendor>/env directory called <board>.env (or common.env if you want the same environment for all boards for that vendor). The environment variables should be of the form "var=value". Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. After discussion on the mailing list the .emv file was moved from include/configs to board/. See here: http://patchwork.ozlabs.org/patch/237120/ There was also talk of using the C preprocessor for these boards. I tried this out and found it to be extremely useful. In fact without it, the scripts probably cannot move from the config header file, since many scripts are put together based on information from CONFIG variables. Another discussion was compatibility with the environment commands 'env export -t' and 'env import -t'. This series permits these to be used and the environment is exported and imported as expected. I have dropped the ugly \0 approach in favour of a more flexible awk script for parsing the environment file. The environment commands use \ at the end of a line for continuation which works nicely with this feature. I have added a patch to 'run' so that it runs the entire script, not just the first line. A nice benefit is that there is no longer any need to put ';' at the end of every line - in other words U-Boot scripts become proper scripts with multiple lines instead of messy and fragile continuations. As an example, I have converted most of the tegra environment over to this new approach on an RFC basis. Changes in v2: - Add additional include to env_embedded to deal with its dirty trick - Add dependency rule so that the environment is rebuilt when it changes - Add information and updated example script to README - Add new patch to adjust 'run' command to better support testing - Add new patch to get 'env import/export' working on sandbox - Add new patch to illustrate the impact on Tegra environment - Add separate patch to enable C preprocessor for environment files - Enable var+=value form to simplify composing variables in multiple steps - Move .env file from include/configs to board/ - Use awk script to process environment since it is much easier on the brain Simon Glass (5): sandbox: Support 'env import' and 'env export' Make 'run' use run_command_list() instead of run_command() Allow U-Boot scripts to be placed in a .env file env: Allow environment files to use the C preprocessor RFC: tegra: Convert to using environment files Makefile | 31 +++++++++- README | 49 +++++++++++++++ board/nvidia/env/common.env | 79 ++++++++++++++++++++++++ common/cmd_nvedit.c | 31 ++++++---- common/env_embedded.c | 1 + common/main.c | 2 +- config.mk | 2 + include/configs/tegra-common-post.h | 120 +----------------------------------- include/env_default.h | 2 + mkconfig | 6 ++ tools/scripts/env2string.awk | 49 +++++++++++++++ 11 files changed, 238 insertions(+), 134 deletions(-) create mode 100644 board/nvidia/env/common.env create mode 100644 tools/scripts/env2string.awk -- 1.8.3

2 12

[U-Boot] u-boot and Linux hanle ubifs ecc in different way on beaglebon variant board
by matti kaasinen 25 Oct '13

25 Oct '13

Hi! Im working on beaglebone variant board - basically the same as beaglebone but with NAND flash on board with am33x processor. Ubifs works fine when I access it purely from Linux (formatting, making ubifs volume etc.). However, when I try to access it from u-boot, e.g execute ubi part - command, I get tons of ecc error messages. If I reboot board after this, it turns out that this ubifs has been corrupted but that ubi part command. Board is running latest beaglebone linux (3.8.11) with device tree (Angstrom distribution). I have tried both with and without BCH8 HW support enabled in kernel. Both seems to work in the same way as far as u-boot is concerned. Any suggestion to find the problem? I do have error code listings, procedures I executed etc. if needed to verify. Best regards, Matti

2 1

[U-Boot] u-boot hw assisted BCH8 not compatible with am335x architecure
by matti kaasinen 25 Oct '13

25 Oct '13

Hi! I have found that ubifs formatted on Linux (2.8.13) side is not compatible on u-boot side. Executing ubi part <partition> throws tons of ECC error messages and in fact this same ubifs partition will be found corrupted on Linux side immediately after this single operation. I have investigated this issue and have found following: Linux 3.8.13 seems to use 52 ecc bytes mapping them to positions 12..64. Default u-boot set-up found from include/asm/arch-am33x/omap_gpmc.h define: #define GPMC_NAND_HW_BCH8_ECC_LAYOUT {\ .eccbytes = 56,\ .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\ 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,\ 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,\ 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51,\ 52, 53, 54, 55, 56, 57},\ .oobfree = {\ {.offset = 58,\ .length = 6 } } \ } that seems using 56 ecc bytes, mapping them to positions 2..57. This 56 bytes seems fighting with the fact found from README.omap3/BCH8 set-up that points, that * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 set-up On the other hand, am335x_evm.h use CONFIG_SYS_NAND_ECCBYTES to calculate CONFIG_SYS_NAND_ECCTOTAL that is same as .eccbytes in GPMC_NAND_HW_BCH8_ECC_LAYOUT definition. Value 13 gives 52 bytes that is compatible with Linux whereas 14 gives that 56 found from GPMC_NAND_HW_BCH8_ECC_LAYOUT definition above. Also text in README.omap3 states: "The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8 implementation for OMAP3 works for you so the u-boot version should also. When you require the SPL to read with BCH8 there are two more configs to change: * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in arch/arm/include/asm/arch-omap3/omap_gpmc.h) * CONFIG_SYS_NAND_ECCSIZE must be 512 * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup" I would interpret this so that no modifications are needed GPMC_NAND_HW_BCH8_ECC_LAYOUT structure. That can't be true even if the mapping was the same as .eccbytes field hae wrong value considering what the last line states for BCH8 set-up. If above assumption is correct, isn't this really a bug in omap_gpmc.h, not just a Linux version related problem? My questions are: 1) Are my findings correct or should I try try find something else? 2) If 1) ok, then should I edit both omap_gpmc.h and am335x_evm.h or just one of them? 3) Is there anything else to be taken into account? Best regards, Matti

1 1

[U-Boot] check if board is in uboot / kernel via ethernet?
by Andreas Neubacher 25 Oct '13

25 Oct '13

hi, is it possible to check if board is in uboot or in kernel via ethernet? is there any additional information we can readout with a simple ping, ...? br, Andy

2 1

[U-Boot] [PATCH 0/6][v2] powerpc: Add support 2 stage boot loader for corenet platform
by Prabhakar Kushwaha 25 Oct '13

25 Oct '13

Signed-off-by: Prabhakar Kushwaha <prabhakar(a)freescale.com> --- Add support of 2 stage NAND boot loader in cornet platforms using SPL framework. This will be helpful for those SoC which has less internal SRAM(256K) like T1040. here, PBL initialise the internal SRAM and copy SPL(192K) in SRAM. SPL further initialise DDR using SPD and environment variables and copy u-boot(512 KB) from NAND flash to DDR. Finally SPL transer control to u-boot for futher booting. SPL has following features: - Executes within 256K - SPL size 192K - No relocation required Run time view of SPL framework ============================== ----------------------------------------------- Area | Address | ----------------------------------------------- GD, BD | 0x0xFFFC0000 (4K) | ----------------------------------------------- HEAP | 0xFFFC1000 (40K) grow downwards | ----------------------------------------------- STACK | 0xFFFD0000 (20K) grow upwards | ----------------------------------------------- U-boot SPL | 0xfffD0000 - 0xfffffffc (192K) | ----------------------------------------------- --- This patch set contains:- [PATCH 1/6] powerpc:Add support of SPL non-relocation [PATCH 2/6] powerpc/SPL:Allow Parsing of LAW table in both SPL & non SPL [PATCH 3/6] common/env: Point default envirenoment for GD [PATCH 4/6] Makefile:Add u-boot-with-spl-pbl.bin target for SPL [PATCH 5/6] SPL:Defines function required to env read for IFC & env_nand [PATCH 6/6] T1040QDS: Add support of 2 stage NAND boot loader -- 1.7.9.5

1 0

[U-Boot] [PATCH 1/2] esdhc: memset mmc struct before putting into use
by Haijun Zhang 25 Oct '13

25 Oct '13

struct mmc should be clear to all '0' after malloc to avoid unexpect variable value. Like mmc->has_init = xxx. In this case mmcinfo will believe the card had been initialized before and skip the initialization. Test on P5040 and T4240, Error Log: => mmcinfo Device: FSL_SDHC Manufacturer ID: 0 OEM: 0 Name: Tran Speed: 0 Rd Block Len: 0 MMC version 0.0 High Capacity: No Capacity: 0 Bytes Bus Width: 0-bit => Signed-off-by: Haijun Zhang <Haijun.Zhang(a)freescale.com> Signed-off-by: Xie Shaohui-B21989 <B21989(a)freescale.com> --- drivers/mmc/fsl_esdhc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index a7170b4..d4c1eef 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -521,6 +521,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg) if (!mmc) return -ENOMEM; + memset(mmc, 0, sizeof(struct mmc)); sprintf(mmc->name, "FSL_SDHC"); regs = (struct fsl_esdhc *)cfg->esdhc_base; -- 1.8.4

1 1

[U-Boot] [PATCH 3/6] common/env: Point default envirenoment for GD
by Prabhakar Kushwaha 24 Oct '13

24 Oct '13

GD(Global Data) structure has pointer to envirenoment variable array. but, it is not being assigned for SPL framwork. So update GD pointer with env variable array. Signed-off-by: Prabhakar Kushwaha <prabhakar(a)freescale.com> --- Based upon git://git.denx.de/u-boot-mpc85xx.git branch next common/env_common.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/env_common.c b/common/env_common.c index 1ac3377..84843e1 100644 --- a/common/env_common.c +++ b/common/env_common.c @@ -162,6 +162,9 @@ int env_import(const char *buf, int check) if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0, 0, NULL)) { gd->flags |= GD_FLG_ENV_READY; +#ifdef CONFIG_SPL_BUILD + gd->env_addr = ep->data; +#endif return 1; } -- 1.7.9.5

2 1

[U-Boot] [PATCH] malta: enable RTC support
by Paul Burton 24 Oct '13

24 Oct '13

This is actually required in order for a Linux kernel to boot successfully on a physical Malta board. Without enabling the RTC, a Malta Linux kernel will get stuck in its estimate_frequencies function on boot. Signed-off-by: Paul Burton <paul.burton(a)imgtec.com> --- This is dependant upon my "MIPS Malta board support" series. The line numbers in include/configs/malta.h will only match up exactly following Gabor Juhos' "malta: define CONFIG_MEMSIZE_IN_BYTES" patch, but will apply with or without it. With this I have verified that Linux boots successfully on a physical Malta with a coreFPGA6 core card & proAptiv bitstream. --- board/imgtec/malta/malta.c | 7 +++++++ drivers/rtc/mc146818.c | 2 +- include/configs/malta.h | 5 +++++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c index d876507..a4ded67 100644 --- a/board/imgtec/malta/malta.c +++ b/board/imgtec/malta/malta.c @@ -147,6 +147,13 @@ int board_early_init_f(void) return 0; } +int misc_init_r(void) +{ + rtc_reset(); + + return 0; +} + struct serial_device *default_serial_console(void) { switch (malta_sys_con()) { diff --git a/drivers/rtc/mc146818.c b/drivers/rtc/mc146818.c index 5f9d359..f7cf106 100644 --- a/drivers/rtc/mc146818.c +++ b/drivers/rtc/mc146818.c @@ -15,7 +15,7 @@ #include <command.h> #include <rtc.h> -#ifdef __I386__ +#if defined(__I386__) || defined(CONFIG_MALTA) #include <asm/io.h> #define in8(p) inb(p) #define out8(p, v) outb(v, p) diff --git a/include/configs/malta.h b/include/configs/malta.h index a4370ae..492b63a 100644 --- a/include/configs/malta.h +++ b/include/configs/malta.h @@ -25,6 +25,10 @@ #define CONFIG_PCNET_79C973 #define PCNET_HAS_PROM +#define CONFIG_MISC_INIT_R +#define CONFIG_RTC_MC146818 +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS 0 + /* * CPU Configuration */ @@ -108,6 +112,7 @@ #undef CONFIG_CMD_LOADS #undef CONFIG_CMD_NFS +#define CONFIG_CMD_DATE #define CONFIG_CMD_DHCP #define CONFIG_CMD_PCI #define CONFIG_CMD_PING -- 1.8.4

1 0

[U-Boot] [PATCH 00/15] MIPS Malta board support
by Paul Burton 24 Oct '13

24 Oct '13

This series adds support for booting on a physical MIPS Malta board using a coreFPGA6 core card. The first 6 patches lay some groundwork, then the next 8 genericise the existing qemu-malta board to also function on a physical Malta. In the final patch I stake my claim upon, errm I mean step up to support :), the malta(el) board(s). Paul Burton (15): mips32: detect L1 cache sizes if they're not defined pcnet: code style cleanup pcnet: s/le16_to_cpu/cpu_to_le16/ in pcnet_send pcnet: add cache flushing & invalidation pcnet: enable the NOUFLO feature pci.h: allow inclusion in assembly source qemu-malta: rename to just "malta" malta: setup super I/O UARTs malta: support for coreFPGA6 boards malta: display "U-boot" on the LCD screen malta: enable CONFIG_PCNET_79C973, PCNET_HAS_PROM, CONFIG_CMD_DHCP malta: remove cache size definitions malta: disable L2 caches malta: add script & instructions to flash U-boot malta: add myself to maintainers arch/mips/cpu/mips32/cache.S | 90 +++++++++++-- arch/mips/cpu/mips32/cpu.c | 73 +++++++++- arch/mips/include/asm/malta.h | 45 ++++++- arch/mips/include/asm/mipsregs.h | 6 + arch/mips/lib/bootm.c | 12 +- board/malta/Makefile | 29 ++++ board/malta/README | 16 +++ board/malta/flash-malta-boot.tcl | 40 ++++++ board/malta/lowlevel_init.S | 238 +++++++++++++++++++++++++++++++++ board/malta/malta.c | 186 ++++++++++++++++++++++++++ board/malta/superio.c | 63 +++++++++ board/malta/superio.h | 15 +++ board/qemu-malta/Makefile | 29 ---- board/qemu-malta/lowlevel_init.S | 69 ---------- board/qemu-malta/qemu-malta.c | 47 ------- boards.cfg | 4 +- drivers/net/pcnet.c | 279 +++++++++++++++++++++------------------ drivers/pci/Makefile | 1 + drivers/pci/pci_msc01.c | 126 ++++++++++++++++++ include/configs/malta.h | 115 ++++++++++++++++ include/configs/qemu-malta.h | 114 ---------------- include/msc01.h | 135 +++++++++++++++++++ include/pci.h | 6 +- include/pci_ids.h | 3 + include/pci_msc01.h | 17 +++ 25 files changed, 1340 insertions(+), 418 deletions(-) create mode 100644 board/malta/Makefile create mode 100644 board/malta/README create mode 100644 board/malta/flash-malta-boot.tcl create mode 100644 board/malta/lowlevel_init.S create mode 100644 board/malta/malta.c create mode 100644 board/malta/superio.c create mode 100644 board/malta/superio.h delete mode 100644 board/qemu-malta/Makefile delete mode 100644 board/qemu-malta/lowlevel_init.S delete mode 100644 board/qemu-malta/qemu-malta.c create mode 100644 drivers/pci/pci_msc01.c create mode 100644 include/configs/malta.h delete mode 100644 include/configs/qemu-malta.h create mode 100644 include/msc01.h create mode 100644 include/pci_msc01.h -- 1.8.4

3 34

[U-Boot] [PATCH v1 0/5] arm, am33xx: update for the am33xx based siemens boards
by Heiko Schocher 24 Oct '13

24 Oct '13

Patch 1 introduces bootcount support for the 3 siemens boards. As there is no other possibility on this boards, the bootcounter is stored in the environment. To prevent a "saveenv" on all reboots, a "upgrade_available" U-Boot Environment variable is introduced. Patch 2 makes the enabling of the RTC32K OSC configurable, as on the dxr2 board it is not used, and http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#2_Keep_it_Fast says not enable things not used ... Patch 3 adds an option to set the iSerialNumber board specific, which is used on the 3 siemens boards. Patch 4 adds an option to set the bcdDevice number board specific, which is used on the 3 siemens boards. Patch 5 contains a lot of updates for the siemens boards, see commit message for detailed information. already posted patches on which this patchserie is based: [U-Boot,v4] i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework http://patchwork.ozlabs.org/patch/285390/ [U-Boot] video, cfb_console: make background and foreground color configurable http://patchwork.ozlabs.org/patch/285385/ [U-Boot] video, formike: change tag/val write http://patchwork.ozlabs.org/patch/285386/ [U-Boot] net, phy: fix AR8031 phy_mask http://patchwork.ozlabs.org/patch/276944/ [U-Boot,2/3] net, phy: fix NULL pointer deference http://patchwork.ozlabs.org/patch/272797/ "./MAKEALL arm" on current u-boot mainline commit 183acb700378a8cfc5d50a01a65de93fb2c24586 compiles without errors Heiko Schocher (4): bootcount: store bootcount var in environment arm, am33x: make RTC32K OSC enable configurable usb, g_dnl: make iSerialNumber board configurable usb, g_dnl: make bcdDevice value configurable Samuel Egli (1): arm, am335x: update for the siemens boards README | 19 ++++ arch/arm/cpu/armv7/am33xx/board.c | 4 + board/siemens/common/factoryset.c | 27 +++++- board/siemens/common/factoryset.h | 4 + board/siemens/dxr2/board.c | 11 +-- board/siemens/dxr2/board.h | 9 +- board/siemens/dxr2/mux.c | 158 +++++++++++++++++++++++++++++++++ board/siemens/pxm2/board.c | 3 +- board/siemens/rut/board.c | 51 +++++++++-- drivers/bootcount/Makefile | 1 + drivers/bootcount/bootcount_env.c | 29 ++++++ drivers/usb/gadget/g_dnl.c | 51 ++++++++++- include/configs/dxr2.h | 13 ++- include/configs/pxm2.h | 7 +- include/configs/rut.h | 10 ++- include/configs/siemens-am33x-common.h | 70 +++++++++++---- include/configs/ti_am335x_common.h | 1 + include/g_dnl.h | 3 + 18 files changed, 415 insertions(+), 56 deletions(-) create mode 100644 drivers/bootcount/bootcount_env.c Cc: Tom Rini <trini(a)ti.com> Cc: Marek Vasut <marek.vasut(a)gmail.com> Cc: Lukasz Majewski <l.majewski(a)samsung.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Samuel Egli <samuel.egli(a)siemens.com> Cc: Pascal Bach <pascal.bach(a)siemens.com> Cc: Roger Meier <r.meier(a)siemens.com> Cc: Matthias Michel <matthias.michel(a)siemens.com> -- 1.8.3.1

3 10