Re: [U-Boot] {PATCH v3 4/4] board: trats2: Enable device tree on Trats2
On 03/20/2014 01:14 PM, Beomho Seo wrote:
> This patch add dwmmc emmc controller node on exynos4 and exynos4412 device
> tree.
>
> Signed-off-by: Beomho Seo
> Signed-off-by: Jaehoon Chung
> Tested-by: Piotr Wilczek
> Cc: Lukasz Majewski
> Cc: Piotr Wilczek
> Cc: Minkyu Kang
> ---
> Changes for v3:
> - Subtract one from div to set accurate frequency.
>
Sorry for the mistake.
This change log for the patch 1.(drivers: mmc: dwmmc: enable support for DT)
> Changes for v2:
> - None.
>
> arch/arm/dts/exynos4.dtsi |8
> arch/arm/dts/exynos4412-trats2.dts |8
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/dts/exynos4.dtsi b/arch/arm/dts/exynos4.dtsi
> index 71dc7eb..ab99906 100644
> --- a/arch/arm/dts/exynos4.dtsi
> +++ b/arch/arm/dts/exynos4.dtsi
> @@ -128,6 +128,14 @@
> interrupts = <0 78 0>;
> };
>
> + dwmmc@1255 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "samsung,exynos4412-dwmmc";
> + reg = <0x1255 0x1000>;
> + interrupts = <0 131 0>;
> + };
> +
> gpio: gpio {
> gpio-controller;
> #gpio-cells = <2>;
> diff --git a/arch/arm/dts/exynos4412-trats2.dts
> b/arch/arm/dts/exynos4412-trats2.dts
> index 7d32067..438e70e 100644
> --- a/arch/arm/dts/exynos4412-trats2.dts
> +++ b/arch/arm/dts/exynos4412-trats2.dts
> @@ -31,6 +31,7 @@
> console = "/serial@1382";
> mmc0 = "sdhci@1251";
> mmc2 = "sdhci@1253";
> + mmc4 = "dwmmc@1255";
> };
>
> i2c@138d {
> @@ -431,4 +432,11 @@
> sdhci@1254 {
> status = "disabled";
> };
> +
> + dwmmc@1255 {
> + samsung,bus-width = <8>;
> + samsung,timing = <0 1 0>;
> + pwr-gpios = <&gpio 0x2004002 0>;
> + index = <4>;
> + };
> };
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] arm: exynos: pinmux: add sdmmc4 gpio configratuion
For use dwmmc controller at exynos4, add SDMMC4 gpio configuration.
In case SDMMC2, do not use 8 bit mode at exynos4.
Signed-off-by: Beomho Seo
Signed-off-by: Jaehoon Chung
Tested-by: Piotr Wilczek
Cc: Lukasz Majewski
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
Changes for v3:
- Set bank_ext of SDMMC2 for prevent compile warning.
Changes for v2:
- Fixed value initialinse.
- Comment add in function.
arch/arm/cpu/armv7/exynos/pinmux.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 9edb475..55c1c95 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -632,16 +632,27 @@ static int exynos4_mmc_config(int peripheral, int flags)
struct exynos4_gpio_part2 *gpio2 =
(struct exynos4_gpio_part2 *)samsung_get_base_gpio_part2();
struct s5p_gpio_bank *bank, *bank_ext;
+ unsigned int func, func_ext;
int i;
switch (peripheral) {
case PERIPH_ID_SDMMC0:
bank = &gpio2->k0;
bank_ext = &gpio2->k1;
+ func = GPIO_FUNC(0x2);
+ func_ext = GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC2:
bank = &gpio2->k2;
bank_ext = &gpio2->k3;
+ func = GPIO_FUNC(0x2);
+ func_ext = GPIO_FUNC(0x3);
+ break;
+ case PERIPH_ID_SDMMC4:
+ bank = &gpio2->k0;
+ bank_ext = &gpio2->k1;
+ func = GPIO_FUNC(0x3);
+ func_ext = GPIO_FUNC(0x4);
break;
default:
return -1;
@@ -649,13 +660,14 @@ static int exynos4_mmc_config(int peripheral, int flags)
for (i = 0; i < 7; i++) {
if (i == 2)
continue;
- s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+ s5p_gpio_cfg_pin(bank, i, func);
s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
}
+ /* SDMMC2 do not use 8bit mode at exynos4 */
if (flags & PINMUX_FLAG_8BIT_MODE) {
for (i = 3; i < 7; i++) {
- s5p_gpio_cfg_pin(bank_ext, i, GPIO_FUNC(0x3));
+ s5p_gpio_cfg_pin(bank_ext, i, func_ext);
s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_NONE);
s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
}
@@ -722,10 +734,10 @@ static int exynos4_pinmux_config(int peripheral, int
flags)
break;
case PERIPH_ID_SDMMC0:
case PERIPH_ID_SDMMC2:
+ case PERIPH_ID_SDMMC4:
return exynos4_mmc_config(peripheral, flags);
case PERIPH_ID_SDMMC1:
case PERIPH_ID_SDMMC3:
- case PERIPH_ID_SDMMC4:
debug("SDMMC device %d not implemented\n", peripheral);
return -1;
default:
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] {PATCH v3 3/4] arm: exynos: clock: Remove exynos4x12_set_mmc_clk function
exynos4x12_set_mmc_clk function have been removed.
Because, exynos4x12_clock and exynos4_clock return smae div_fsys* value.
Signed-off-by: Beomho Seo
Signed-off-by: Jaehoon Chung
Tested-by: Piotr Wilczek
Cc: Lukasz Majewski
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
Changes for v3:
- None.
Changes for v2:
- None.
arch/arm/cpu/armv7/exynos/clock.c | 29 +
1 file changed, 1 insertion(+), 28 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 1fea4d6..2c2029a 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -893,30 +893,6 @@ static void exynos4_set_mmc_clk(int dev_index, unsigned
int div)
(div & 0xff) << ((dev_index << 4) + 8));
}
-/* exynos4x12: set the mmc clock */
-static void exynos4x12_set_mmc_clk(int dev_index, unsigned int div)
-{
- struct exynos4x12_clock *clk =
- (struct exynos4x12_clock *)samsung_get_base_clock();
- unsigned int addr;
-
- /*
-* CLK_DIV_FSYS1
-* MMC0_PRE_RATIO [15:8], MMC1_PRE_RATIO [31:24]
-* CLK_DIV_FSYS2
-* MMC2_PRE_RATIO [15:8], MMC3_PRE_RATIO [31:24]
-*/
- if (dev_index < 2) {
- addr = (unsigned int)&clk->div_fsys1;
- } else {
- addr = (unsigned int)&clk->div_fsys2;
- dev_index -= 2;
- }
-
- clrsetbits_le32(addr, 0xff << ((dev_index << 4) + 8),
- (div & 0xff) << ((dev_index << 4) + 8));
-}
-
/* exynos5: set the mmc clock */
static void exynos5_set_mmc_clk(int dev_index, unsigned int div)
{
@@ -1612,10 +1588,7 @@ void set_mmc_clk(int dev_index, unsigned int div)
else
exynos5_set_mmc_clk(dev_index, div);
} else {
- if (proid_is_exynos4412())
- exynos4x12_set_mmc_clk(dev_index, div);
- else
- exynos4_set_mmc_clk(dev_index, div);
+ exynos4_set_mmc_clk(dev_index, div);
}
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] {PATCH v3 4/4] board: trats2: Enable device tree on Trats2
This patch add dwmmc emmc controller node on exynos4 and exynos4412 device tree.
Signed-off-by: Beomho Seo
Signed-off-by: Jaehoon Chung
Tested-by: Piotr Wilczek
Cc: Lukasz Majewski
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
Changes for v3:
- Subtract one from div to set accurate frequency.
Changes for v2:
- None.
arch/arm/dts/exynos4.dtsi |8
arch/arm/dts/exynos4412-trats2.dts |8
2 files changed, 16 insertions(+)
diff --git a/arch/arm/dts/exynos4.dtsi b/arch/arm/dts/exynos4.dtsi
index 71dc7eb..ab99906 100644
--- a/arch/arm/dts/exynos4.dtsi
+++ b/arch/arm/dts/exynos4.dtsi
@@ -128,6 +128,14 @@
interrupts = <0 78 0>;
};
+ dwmmc@1255 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos4412-dwmmc";
+ reg = <0x1255 0x1000>;
+ interrupts = <0 131 0>;
+ };
+
gpio: gpio {
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/dts/exynos4412-trats2.dts
b/arch/arm/dts/exynos4412-trats2.dts
index 7d32067..438e70e 100644
--- a/arch/arm/dts/exynos4412-trats2.dts
+++ b/arch/arm/dts/exynos4412-trats2.dts
@@ -31,6 +31,7 @@
console = "/serial@1382";
mmc0 = "sdhci@1251";
mmc2 = "sdhci@1253";
+ mmc4 = "dwmmc@1255";
};
i2c@138d {
@@ -431,4 +432,11 @@
sdhci@1254 {
status = "disabled";
};
+
+ dwmmc@1255 {
+ samsung,bus-width = <8>;
+ samsung,timing = <0 1 0>;
+ pwr-gpios = <&gpio 0x2004002 0>;
+ index = <4>;
+ };
};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4]drivers: mmc: dwmmc: enable support for DT
This patch enables for device tree for dw-mmc driver.
Driver have been fixed because it is used exynos5 and exynos4.
Add, fdt compat id of exynos4 dwmmc.
Signed-off-by: Beomho Seo
Signed-off-by: Jaehoon Chung
Tested-by: Piotr Wilczek
Cc: Lukasz Majewski
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
Changes for v3:
- None.
drivers/mmc/exynos_dw_mmc.c | 21 +
include/fdtdec.h|1 +
lib/fdtdec.c|1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index de8cdcc..b9d41d4 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#defineDWMMC_MAX_CH_NUM4
#defineDWMMC_MAX_FREQ 5200
@@ -82,6 +83,7 @@ int exynos_dwmci_add_port(int index, u32 regbase, int
bus_width, u32 clksel)
freq = 5200;
sclk = get_mmc_clk(index);
div = DIV_ROUND_UP(sclk, freq);
+ div -= 1;
/* set the clock divisor for mmc */
set_mmc_clk(index, div);
@@ -118,15 +120,21 @@ int exynos_dwmmc_init(const void *blob)
{
int index, bus_width;
int node_list[DWMMC_MAX_CH_NUM];
- int err = 0, dev_id, flag, count, i;
+ int err = 0, dev_id, flag, count, i, compat_id;
u32 clksel_val, base, timing[3];
+#ifdef CONFIG_EXYNOS4
+ compat_id = COMPAT_SAMSUNG_EXYNOS4_DWMMC;
+#else
+ compat_id = COMPAT_SAMSUNG_EXYNOS5_DWMMC;
+#endif
+
count = fdtdec_find_aliases_for_id(blob, "mmc",
- COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
- DWMMC_MAX_CH_NUM);
+ compat_id, node_list, DWMMC_MAX_CH_NUM);
for (i = 0; i < count; i++) {
int node = node_list[i];
+ struct fdt_gpio_state pwr_gpio;
if (node <= 0)
continue;
@@ -145,6 +153,9 @@ int exynos_dwmmc_init(const void *blob)
else
flag = PINMUX_FLAG_NONE;
+ fdtdec_decode_gpio(blob, node, "pwr-gpios", &pwr_gpio);
+ if (fdt_gpio_isvalid(&pwr_gpio))
+ gpio_direction_output(pwr_gpio.gpio, 1);
/* config pinmux for each mmc channel */
err = exynos_pinmux_config(dev_id, flag);
if (err) {
@@ -152,7 +163,9 @@ int exynos_dwmmc_init(const void *blob)
return err;
}
- index = dev_id - PERIPH_ID_SDMMC0;
+ index = fdtdec_get_int(blob, node, "index", dev_id);
+ if (index == dev_id)
+ index = dev_id - PERIPH_ID_SDMMC0;
/* Get the base address from the device node */
base = fdtdec_get_addr(blob, node, "reg");
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 63027bd..15f50fe 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -83,6 +83,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS5_DP, /* Exynos Display port controller */
COMPAT_SAMSUNG_EXYNOS5_DWMMC, /* Exynos5 DWMMC controller */
COMPAT_SAMSUNG_EXYNOS_MMC, /* Exynos MMC controller */
+ COMPAT_SAMSUNG_EXYNOS4_DWMMC, /* Exynos4 DWMMC controller */
COMPAT_SAMSUNG_EXYNOS_SERIAL, /* Exynos UART */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
COMPAT_GENERIC_SPI_FLASH, /* Generic SPI Flash chip */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index be04598..79179cf 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS5_DP, "samsung,exynos5-dp"),
COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
COMPAT(SAMSUNG_EXYNOS_MMC, "samsung,exynos-mmc"),
+ COMPAT(SAMSUNG_EXYNOS4_DWMMC, "samsung,exynos4412-dwmmc"),
COMPAT(SAMSUNG_EXYNOS_SERIAL, "samsung,exynos4210-uart"),
COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
COMPAT(GENERIC_SPI_FLASH, "spi-flash"),
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] samsung: Add mmc controller to use dwmmc
This patch set for use dw mmc controller. Patch enable supporting device tree for dw mmc controller. For use dwmmc controller on trats2 board, enable configuration dw_mmc, exynos_dwmmc, bounce_buffer and then disable sdhci configuration. This patch set tested on TRATS2 board. Changes for v3: - Set bank_ext of SDMMC2 for prevent compile warning. - Subtract one from div to set accurate frequency. Changes for v2: - Use device tree for dw mmc controller. - dw mmc node is added device node on exynos4 device tree. - dw mmc controller driver is fixed for use exynos4 and 5. - Add fdt compat id of exynos4 dwmmc. - Add comment. Beomho Seo (4): drivers: mmc: dwmmc: enable support for DT arm: exynos: pinmux: Add sdmmc4 gpio configuration arm: exynos: clock: Remove exynos4x12_set_mmc_clk function board: trats2: Enable device tree on Trats2 arch/arm/cpu/armv7/exynos/clock.c | 29 + arch/arm/cpu/armv7/exynos/pinmux.c | 18 +++--- arch/arm/dts/exynos4.dtsi |8 arch/arm/dts/exynos4412-trats2.dts |8 drivers/mmc/exynos_dw_mmc.c| 21 + include/fdtdec.h |1 + lib/fdtdec.c |1 + 7 files changed, 51 insertions(+), 35 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem on SPL build
Hi Minkyu, I want to try to support SPL at smdkc100, but I just a newer to u-boot and linux. I am afraid that it's a difficult job to me. Still, I will try. If you could contribute this, It will be a wonderful job. Best regards, Simon 2014-03-19 18:17 GMT+08:00 Minkyu Kang : > On 19/03/14 15:25, hua dillon wrote: > > you can use board_init_f from arch/arm/lib/spl.c in SPL > > > > > > > SPL is not supported at smdkc100. > You can contribute on this. > Patches always welcome. > > Thanks, > Minkyu Kang. > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Daniel, > agree. But at first we should introduce Kconfig files in all arch, > CPU, SOC, SOC common, board vendor, board and driver directories where > we put all CONFIG_SYS_ symbols. We also need to convert the current > config options for CPU, SOC, vendor and board. For example: > > CONFIG_SYS_CPU="armv7" > CONFIG_SOC_DIR=y > CONFIG_SYS_SOC="tegra30" > CONFIG_SYS_BOARD="beaver" > CONFIG_VENDOR_DIR=y > CONFIG_SYS_VENDOR="nvidia" > CONFIG_SYS_CONFIG_NAME="beaver" > > should be converted to something like this: > > CONFIG_CPU_ARMV7=y > CONFIG_SOC_TEGRA30=y > CONFIG_VENDOR_NVIDIA=y > CONFIG_BOARD_BEAVER=y > > Then we can use the Kconfig symbol dependencies to create a minimal > working board config. For example: > > board/nvidia/beaver/Kconfig: > config BOARD_BEAVER > bool "board description" > select VENDOR_NVIDIA > select SOC_TEGRA30 > select SPL > ... > > arch/arm/cpu/armv7/tegra30/Kconfig: > config SOC_TEGRA30 > bool > select ARMV7 > ... > > The beaver_defconfig file could reduced then to > "CONFIG_BOARD_BEAVER=y" and some default user-editable options. Basicly I think it's a good idea, but I am afraid there are some problems. [1] First, in this case, how can we select the target board? Like this? choice prompt "Board select" default BOARD_SANDBOX config BOARD_VEXPRESS_AEMV8A bool "vexpress_aemv8a board" config BOARD_ARCANGEL4 bool "arcangel4 board" [ Snip: a thousand of boards ] endchoice If we run "make config", a bunch of board choices would be displayed and be gone away quickly. For "make menuconfig", it would be hard to select the board you are aiming at. Maybe we should choose it in the top-down order? Like this? (1) 1st Level : Architecture select choice prompt "Architecture select" config ARM bool "ARM architecture" . (2) 2rd Level: CPU select choice prompt "CPU select" depends on ARM config CPU_ARMV7 bool "ARM v7" (3) 3rd level: SoC select choice prompt "SoC select" depends on CPU_ARMV7 config SOC_TEGRA bool "Tegra SoC" . (4) 4th level: Board select choice prompt "Board select" depends on SOC_TEGRA config BOARD_BEAVER bool "Tegra SoC" [2] CONFIG_CPU_ CONFIG_SOC_ CONFIG_VENDOR_ CONFIG_BOARD_ are systematic prefixes and easy to understand. But there are already some macros bound to specific CPUs, SoCs. For example, CONFIG_SOC_TEGRA30 would be the same as existing CONFIG_TEGRA30. We will have to merge macros with the same meaning. [3] How to select board directoy by using boolean macros. If we try to emulate arch/arm/Makefile of Linux, board-$(CONFIG_BOARD_VEXPRESS_AEMV8A) := vexpress_aemv8a board-$(CONFIG_BOARD_AXS101) := axs101 board-$(CONFIG_BOARD_ARCANGEL4) := arcangel4 Like this? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Tom, > > In message > > you > > wrote: > > > > > > maybe we should import get_maintainers.pl from kernel and readd > > > MAINTAINERS in the according format. So we could easily maintain infos > > > about board maintainers, custodians, custodian trees and maintaining > > > status per arch, CPU, SOC, drivers and boards in one place. Currently > > > that is not possible because one has to look into different sources > > > (boards.cfg, README's, U-Boot Wiki, git history, source file) to get > > > those infos. > > > > We have just created such a single point of information (boards.cfg), > > and now we're ripping it apart again :-( > > What Daniel said is right, we don't have a single point today, we have > boards.cfg, wiki and other stuff. Being able to leverage > get_maintainers.pl would be nice, even if it's a bit of a pain that we > just got things into boards.cfg. On the other hand, it's good that > we've just spent some time sorting and checking the information and it's > a regex'able problem to go from boards.cfg to MAINTAINERS. We can move forward this work first apart from Kconfig, can't we? It is a cosmetic change so it can be merged even if MW is closed. BTW, is this task expected to me? Or can anyone do it? (This would be very appreciated.) Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Tom, > So, what this series is doing, roughly, is turning just the boards.cfg > entry into a small Kconfig snippet, and saying we'll keep using > include/configs/foo.h for most of the work. This is just the first step > in moving away from include/configs/foo.h eventually, yes? Yes, exactly. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARMv8/FSL_LSCH3: SoC and board support
On 03/19/2014 02:02 PM, York Sun wrote: > [Patch v2 1/5] Added 64-bit MMIO accessors for ARMv8 > [Patch v2 2/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC > [Patch v2 3/5] ARMv8/ls2100a_emu: Add LS2100A emulator board support > [Patch v2 4/5] armv8/fsl-lsch3: Add support to load and start MC > [Patch v2 5/5] fsl-lsch3/ls2100a_emu: Enabled MC > > I have sent 2/5 as individual patch before. To avoid confusion, let's > start with v2. > > Change since v1: > 2/5 ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC > Add L3 cache flushing > Revised MMU table > Re-create MMU in DDR after relocation > Fix topology and clock registers > > This set should be applied in order. I will create a bundle in patchwor to > include floating patches to show the dependency. > Here is the bundle http://patchwork.ozlabs.org/bundle/yorksun/armv8_fsl-lsch3/ York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v2 4/5] armv8/fsl-lsch3: Add support to load and start MC Firmware
From: "J. German Rivera"
Adding supoort to load and start the Layerscape Management Complex (MC)
firmware. First, the MC GCR register is set to 0 to reset all cores. MC
firmware and DPL images are copied from their location in NOR flash to
DDR. MC registers are updated with the location of these images.
Deasserting the reset bit of MC GCR register releases core 0 to run.
Core 1 will be released by MC firmware. Stop bits are not touched for
this step. U-boot waits for MC until it boots up.
Signed-off-by: J. German Rivera
Signed-off-by: York Sun
---
README | 27
arch/arm/cpu/armv8/fsl-lsch3/cpu.c | 11 +++
drivers/net/Makefile |1 +
drivers/net/fsl_mc/Makefile|9 +++
drivers/net/fsl_mc/mc.c| 132
include/fsl_mc.h | 59
6 files changed, 239 insertions(+)
create mode 100644 drivers/net/fsl_mc/Makefile
create mode 100644 drivers/net/fsl_mc/mc.c
create mode 100644 include/fsl_mc.h
diff --git a/README b/README
index 216f0c7..2f6532e 100644
--- a/README
+++ b/README
@@ -4520,6 +4520,33 @@ within that device.
window->master inbound window->master LAW->the ucode address in
master's memory space.
+Freescale Layerscape Management Complex Firmware Support:
+-
+The Freescale Layerscape Management Complex (MC) supports the loading of
+"firmware".
+This firmware often needs to be loaded during U-Boot booting, so macros
+are used to identify the storage device (NOR flash, SPI, etc) and the address
+within that device.
+
+- CONFIG_FSL_MC_ENET
+ Enable the MC driver for Layerscape SoCs.
+
+- CONFIG_SYS_LS_MC_FW_ADDR
+ The address in the storage device where the firmware is located. The
+ meaning of this address depends on which CONFIG_SYS_LS_MC_FW_IN_xxx
macro
+ is also specified.
+
+- CONFIG_SYS_LS_MC_FW_LENGTH
+ The maximum possible size of the firmware. The firmware binary format
+ has a field that specifies the actual size of the firmware, but it
+ might not be possible to read any part of the firmware unless some
+ local storage is allocated to hold the entire firmware first.
+
+- CONFIG_SYS_LS_MC_FW_IN_NOR
+ Specifies that MC firmware is located in NOR flash, mapped as
+ normal addressable memory via the LBC. CONFIG_SYS_LS_MC_FW_ADDR is the
+ virtual address in NOR flash.
+
Building the Software:
==
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
index 69c78a9..f976235 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
@@ -12,6 +12,7 @@
#include
#include "cpu.h"
#include "speed.h"
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -463,3 +464,13 @@ int print_cpuinfo(void)
return 0;
}
#endif
+
+int cpu_eth_init(bd_t *bis)
+{
+ int error = 0;
+
+#ifdef CONFIG_FSL_MC_ENET
+ error = mc_init(bis);
+#endif
+ return error;
+}
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7f9ce90..184133a 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -63,3 +63,4 @@ obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o xilinx_ll_temac_mdio.o \
xilinx_ll_temac_fifo.o xilinx_ll_temac_sdma.o
obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
+obj-$(CONFIG_FSL_MC_ENET) += fsl_mc/
diff --git a/drivers/net/fsl_mc/Makefile b/drivers/net/fsl_mc/Makefile
new file mode 100644
index 000..c3e6690
--- /dev/null
+++ b/drivers/net/fsl_mc/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+# Layerscape MC driver
+obj-y += mc.o
+
diff --git a/drivers/net/fsl_mc/mc.c b/drivers/net/fsl_mc/mc.c
new file mode 100644
index 000..fe729c5
--- /dev/null
+++ b/drivers/net/fsl_mc/mc.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * Upload MC firmware or DPL image from NOR flash to DDR
+ */
+static int mc_upload_nor_image(const char *title,
+ u64 image_addr, u32 image_size, u64 mc_ram_addr)
+{
+ debug("%s copied to address %p\n", title, (void *)mc_ram_addr);
+ memcpy((void *)mc_ram_addr, (void *)image_addr, image_size);
+ return 0;
+}
+
+int mc_init(bd_t *bis)
+{
+ int error = 0;
+ int timeout = 20;
+ struct mc_ccsr_registers __iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
+ u64 mc_ram_addr;
+ u32 dpl_offset;
+
+ BUILD_BUG_ON(CONFIG_SYS_LS_MC_FW_LENGTH % 4 != 0);
+
+ if (gd->bd->bi_dram[1].start) {
+ mc_ram_addr =
+ gd->bd->bi_dram[1].start + gd->bd->bi_dram[1].size;
+ } else {
+ mc_ram_addr =
+
[U-Boot] [PATCH] driver/fsl_ifc: Add a function to finalize CS0 address binding
For fsl-lsch3 NOR flash boot, IFC CS0 needs to be binded with address
within 32-bit at fist. After u-boot relocates to DDR, CS0 can be binded
to higher address to support large space.
Signed-off-by: York Sun
CC: Prabhakar Kushwaha
---
drivers/misc/fsl_ifc.c |7 +++
include/fsl_ifc.h |1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/misc/fsl_ifc.c b/drivers/misc/fsl_ifc.c
index be61973..3902e9f 100644
--- a/drivers/misc/fsl_ifc.c
+++ b/drivers/misc/fsl_ifc.c
@@ -162,3 +162,10 @@ void init_early_memctl_regs(void)
set_ifc_csor(IFC_CS7, CONFIG_SYS_CSOR7);
#endif
}
+
+void init_final_memctl_regs(void)
+{
+#ifdef CONFIG_SYS_CSPR0_FINAL
+ set_ifc_cspr(IFC_CS0, CONFIG_SYS_CSPR0_FINAL);
+#endif
+}
diff --git a/include/fsl_ifc.h b/include/fsl_ifc.h
index 58a6efd..630e4b4 100644
--- a/include/fsl_ifc.h
+++ b/include/fsl_ifc.h
@@ -784,6 +784,7 @@ enum ifc_nand_fir_opcodes {
extern void print_ifc_regs(void);
extern void init_early_memctl_regs(void);
+void init_final_memctl_regs(void);
#define IFC_BASE_ADDR ((struct fsl_ifc *)CONFIG_SYS_IFC_ADDR)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v2 5/5] fsl-lsch3/ls2100a_emu: Enabled MC
Reserve last 512MB from main memory for MC to use. Specify the location
of MC firmware and DPL image in NOR flash.
Signed-off-by: J. German Rivera
Signed-off-by: York Sun
---
board/freescale/ls2100a_emu/ls2100a_emu.c | 10 ++
include/configs/ls2100a_emu.h | 14 ++
2 files changed, 24 insertions(+)
diff --git a/board/freescale/ls2100a_emu/ls2100a_emu.c
b/board/freescale/ls2100a_emu/ls2100a_emu.c
index 608a88c..bb0bb1e 100644
--- a/board/freescale/ls2100a_emu/ls2100a_emu.c
+++ b/board/freescale/ls2100a_emu/ls2100a_emu.c
@@ -54,3 +54,13 @@ int timer_init(void)
void reset_cpu(ulong addr)
{
}
+
+int board_eth_init(bd_t *bis)
+{
+ int error = 0;
+
+#ifdef CONFIG_FSL_MC_ENET
+ error = cpu_eth_init(bis);
+#endif
+ return error;
+}
diff --git a/include/configs/ls2100a_emu.h b/include/configs/ls2100a_emu.h
index dce25bd..8829975 100644
--- a/include/configs/ls2100a_emu.h
+++ b/include/configs/ls2100a_emu.h
@@ -54,6 +54,9 @@
#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE
#define CONFIG_SYS_DDR_BLOCK2_BASE 0x808000ULL
+/* don't use last 512MB, reserved for MC firmware */
+#define CONFIG_SYS_MEM_TOP_HIDE(512UL * 1024 * 1024)
+
/* Generic Timer Definitions */
#define COUNTER_FREQUENCY 1200/* 12MHz */
@@ -129,6 +132,17 @@
#define CONFIG_SYS_CS0_FTIM2 CONFIG_SYS_NOR_FTIM2
#define CONFIG_SYS_CS0_FTIM3 CONFIG_SYS_NOR_FTIM3
+/* MC firmware */
+#define CONFIG_FSL_MC_ENET
+#define CONFIG_SYS_LS_MC_FW_IN_NOR
+#define CONFIG_SYS_LS_MC_FW_ADDR 0x3024ULL
+/* TODO Actual FW length needs to be determined at runtime from FW header */
+#define CONFIG_SYS_LS_MC_FW_LENGTH (4U * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DPL_IN_NOR
+#define CONFIG_SYS_LS_MC_DPL_ADDR 0x3020ULL
+/* TODO Actual DPL max length needs to be confirmed with the MC FW team */
+#define CONFIG_SYS_LS_MC_DPL_LENGTH4096
+
/* Command line configuration */
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_BDI
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v2 3/5] ARMv8/ls2100a_emu: Add LS2100A emulator board support
LS2100A is an ARMv8 implementation. This adds board support for emulator:
Two DDR controllers
UART2 is used as the console
IFC timing is tightened for speedy booting
Signed-off-by: York Sun
Signed-off-by: Arnab Basu
---
board/freescale/ls2100a_emu/Makefile |8 +
board/freescale/ls2100a_emu/README | 16 ++
board/freescale/{t4qds => ls2100a_emu}/ddr.c | 90 ---
board/freescale/ls2100a_emu/ddr.h| 57 +++
board/freescale/ls2100a_emu/ls2100a_emu.c| 56 +++
boards.cfg |1 +
include/configs/ls2100a_emu.h| 205 ++
7 files changed, 409 insertions(+), 24 deletions(-)
create mode 100644 board/freescale/ls2100a_emu/Makefile
create mode 100644 board/freescale/ls2100a_emu/README
copy board/freescale/{t4qds => ls2100a_emu}/ddr.c (58%)
create mode 100644 board/freescale/ls2100a_emu/ddr.h
create mode 100644 board/freescale/ls2100a_emu/ls2100a_emu.c
create mode 100644 include/configs/ls2100a_emu.h
diff --git a/board/freescale/ls2100a_emu/Makefile
b/board/freescale/ls2100a_emu/Makefile
new file mode 100644
index 000..3fee04b
--- /dev/null
+++ b/board/freescale/ls2100a_emu/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright 2014 Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += ls2100a_emu.o
+obj-y += ddr.o
diff --git a/board/freescale/ls2100a_emu/README
b/board/freescale/ls2100a_emu/README
new file mode 100644
index 000..9a8a618
--- /dev/null
+++ b/board/freescale/ls2100a_emu/README
@@ -0,0 +1,16 @@
+Freescale ls2100a_emu
+
+This is a emulator target with limited peripherals.
+
+Memory map from core's view
+
+0x00__ .. 0x00_000F_ Boot Rom
+0x00_0100_ .. 0x00_0FFF_ CCSR
+0x00_1800_ .. 0x00_181F_ OCRAM
+0x00_3000_ .. 0x00_3FFF_ IFC region #1
+0x00_8000_ .. 0x00__ DDR region #1
+0x05_1000_ .. 0x05__ IFC region #2
+0x80_8000_ .. 0xFF__ DDR region #2
+
+Other addresses are either reserved, or not used directly by u-boot.
+This list should be updated when more addresses are used.
diff --git a/board/freescale/t4qds/ddr.c b/board/freescale/ls2100a_emu/ddr.c
similarity index 58%
copy from board/freescale/t4qds/ddr.c
copy to board/freescale/ls2100a_emu/ddr.c
index 7586cc3..4c16b3f 100644
--- a/board/freescale/t4qds/ddr.c
+++ b/board/freescale/ls2100a_emu/ddr.c
@@ -1,18 +1,12 @@
/*
- * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2014 Freescale Semiconductor, Inc.
*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * Version 2 or later as published by the Free Software Foundation.
+ * SPDX-License-Identifier:GPL-2.0+
*/
#include
-#include
-#include
-#include
#include
#include
-#include
#include "ddr.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -24,7 +18,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
const struct board_specific_parameters *pbsp, *pbsp_highest = NULL;
ulong ddr_freq;
- if (ctrl_num > 2) {
+ if (ctrl_num > 3) {
printf("Not supported controller number %d\n", ctrl_num);
return;
}
@@ -41,7 +35,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
pbsp = udimms[0];
- /* Get clk_adjust, cpo, write_data_delay,2T, according to the board ddr
+ /* Get clk_adjust, wrlvl_start, wrlvl_ctl, according to the board ddr
* freqency and n_banks specified in board_specific_parameters table.
*/
ddr_freq = get_ddr_freq(0) / 100;
@@ -49,14 +43,10 @@ void fsl_ddr_board_options(memctl_options_t *popts,
if (pbsp->n_ranks == pdimm->n_ranks &&
(pdimm->rank_density >> 30) >= pbsp->rank_gb) {
if (ddr_freq <= pbsp->datarate_mhz_high) {
- popts->cpo_override = pbsp->cpo;
- popts->write_data_delay =
- pbsp->write_data_delay;
popts->clk_adjust = pbsp->clk_adjust;
popts->wrlvl_start = pbsp->wrlvl_start;
popts->wrlvl_ctl_2 = pbsp->wrlvl_ctl_2;
popts->wrlvl_ctl_3 = pbsp->wrlvl_ctl_3;
- popts->twot_en = pbsp->force_2t;
goto found;
}
pbsp_highest = pbsp;
@@ -65,17 +55,13 @@ void fsl_ddr_board_options(memctl_options_t *popts,
}
if (pbsp_highest) {
- printf("Error: board specific timing not found "
- "for data rate %lu MT/s\n"
+ printf("Error: board specific timing not found for data rate
%lu MT/s\n"
"Trying to use the highest speed (%u
[U-Boot] [Patch v2 2/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC
Freescale LayerScape with Chassis Generation 3 is a set of SoCs with
ARMv8 cores and 3rd generation of Chassis. We use different MMU setup
to support memory map and cache attribute for these SoCs. MMU and cache
are enabled very early to bootst performance, especially for early
development on emulators. After u-boot relocates to DDR, a new MMU
table is created in DDR.
Signed-off-by: York Sun
---
arch/arm/cpu/armv8/cache_v8.c |7 +-
arch/arm/cpu/armv8/fsl-lsch3/Makefile | 10 +
arch/arm/cpu/armv8/fsl-lsch3/README | 10 +
arch/arm/cpu/armv8/fsl-lsch3/cpu.c| 465 +
arch/arm/cpu/armv8/fsl-lsch3/cpu.h|7 +
arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S | 59 +++
arch/arm/cpu/armv8/fsl-lsch3/speed.c | 176
arch/arm/cpu/armv8/fsl-lsch3/speed.h |7 +
arch/arm/cpu/armv8/fsl-lsch3/timer.c | 63 +++
arch/arm/include/asm/arch-fsl-lsch3/clock.h | 23 +
arch/arm/include/asm/arch-fsl-lsch3/config.h | 56 +++
arch/arm/include/asm/arch-fsl-lsch3/gpio.h|9 +
arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h | 116 +
arch/arm/include/asm/arch-fsl-lsch3/imx-regs.h| 13 +
arch/arm/include/asm/arch-fsl-lsch3/mmu.h | 10 +
arch/arm/include/asm/config.h |4 +
arch/arm/include/asm/system.h |2 +
drivers/i2c/mxc_i2c.c |5 +
include/common.h |5 +-
19 files changed, 1043 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/Makefile
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/README
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/cpu.c
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/cpu.h
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/speed.c
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/speed.h
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/timer.c
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/clock.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/config.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/gpio.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/imx-regs.h
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/mmu.h
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index a96ecda..c47acba 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -83,12 +83,17 @@ void invalidate_dcache_all(void)
__asm_invalidate_dcache_all();
}
+void __weak flush_l3_cache(void)
+{
+}
+
/*
* Performs a clean & invalidation of the entire data cache at all levels
*/
void flush_dcache_all(void)
{
__asm_flush_dcache_all();
+ flush_l3_cache();
}
/*
@@ -221,7 +226,7 @@ void invalidate_icache_all(void)
* Enable dCache & iCache, whether cache is actually enabled
* depend on CONFIG_SYS_DCACHE_OFF and CONFIG_SYS_ICACHE_OFF
*/
-void enable_caches(void)
+void __weak enable_caches(void)
{
icache_enable();
dcache_enable();
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/Makefile
b/arch/arm/cpu/armv8/fsl-lsch3/Makefile
new file mode 100644
index 000..4b859cf
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-lsch3/Makefile
@@ -0,0 +1,10 @@
+#
+# Copyright 2014, Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += cpu.o
+obj-y += timer.o
+obj-y += lowlevel.o
+obj-y += speed.o
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/README
b/arch/arm/cpu/armv8/fsl-lsch3/README
new file mode 100644
index 000..de34a91
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-lsch3/README
@@ -0,0 +1,10 @@
+#
+# Copyright 2014 Freescale Semiconductor
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+Freescale LayerScape with Chassis Generation 3
+
+This architecture supports Freescale ARMv8 SoCs with Chassis generation 3,
+for example LS2100A.
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
new file mode 100644
index 000..69c78a9
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
@@ -0,0 +1,465 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cpu.h"
+#include "speed.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+/*
+ * To start MMU before DDR is available, we create MMU table in SRAM.
+ * The base address of SRAM is CONFIG_SYS_FSL_OCRAM_BASE. We use three
+ * levels of translation tables here to cover 40-bit address space.
+ * We use 4KB granule size, with 40 bits physical address, T0SZ=24
+ * Level 0 IA[39], table address @0
+ * Level 1 IA[31:30], table address @01000, 0x2000
+ * Level 2 IA[29:21], table address @0x3000
+ */
+
[U-Boot] [Patch v2 1/5] Added 64-bit MMIO accessors for ARMv8
From: "J. German Rivera"
This is needed for accessing peripherals with 64-bit MMIO registers,
from ARMv8 processors.
Signed-off-by: J. German Rivera
---
arch/arm/include/asm/io.h |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 6a1f05a..95528dd 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -70,10 +70,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr)
#define __arch_getb(a) (*(volatile unsigned char *)(a))
#define __arch_getw(a) (*(volatile unsigned short *)(a))
#define __arch_getl(a) (*(volatile unsigned int *)(a))
+#define __arch_getq(a) (*(volatile unsigned long long *)(a))
#define __arch_putb(v,a) (*(volatile unsigned char *)(a) = (v))
#define __arch_putw(v,a) (*(volatile unsigned short *)(a) = (v))
#define __arch_putl(v,a) (*(volatile unsigned int *)(a) = (v))
+#define __arch_putq(v,a) (*(volatile unsigned long long *)(a) =
(v))
extern inline void __raw_writesb(unsigned long addr, const void *data,
int bytelen)
@@ -123,10 +125,12 @@ extern inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define __raw_writeb(v,a) __arch_putb(v,a)
#define __raw_writew(v,a) __arch_putw(v,a)
#define __raw_writel(v,a) __arch_putl(v,a)
+#define __raw_writeq(v,a) __arch_putq(v,a)
#define __raw_readb(a) __arch_getb(a)
#define __raw_readw(a) __arch_getw(a)
#define __raw_readl(a) __arch_getl(a)
+#define __raw_readq(a) __arch_getq(a)
/*
* TODO: The kernel offers some more advanced versions of barriers, it might
@@ -139,10 +143,12 @@ extern inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define writeb(v,c)({ u8 __v = v; __iowmb(); __arch_putb(__v,c); __v; })
#define writew(v,c)({ u16 __v = v; __iowmb(); __arch_putw(__v,c); __v; })
#define writel(v,c)({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
+#define writeq(v,c)({ u64 __v = v; __iowmb(); __arch_putq(__v,c); __v; })
#define readb(c) ({ u8 __v = __arch_getb(c); __iormb(); __v; })
#define readw(c) ({ u16 __v = __arch_getw(c); __iormb(); __v; })
#define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v; })
+#define readq(c) ({ u64 __v = __arch_getq(c); __iormb(); __v; })
/*
* The compiler seems to be incapable of optimising constants
@@ -168,9 +174,11 @@ extern inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a)
#define in_arch(type,endian,a) endian##_to_cpu(__raw_read##type(a))
+#define out_le64(a,v) out_arch(q,le64,a,v)
#define out_le32(a,v) out_arch(l,le32,a,v)
#define out_le16(a,v) out_arch(w,le16,a,v)
+#define in_le64(a) in_arch(q,le64,a)
#define in_le32(a) in_arch(l,le32,a)
#define in_le16(a) in_arch(w,le16,a)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARMv8/FSL_LSCH3: SoC and board support
[Patch v2 1/5] Added 64-bit MMIO accessors for ARMv8 [Patch v2 2/5] ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC [Patch v2 3/5] ARMv8/ls2100a_emu: Add LS2100A emulator board support [Patch v2 4/5] armv8/fsl-lsch3: Add support to load and start MC [Patch v2 5/5] fsl-lsch3/ls2100a_emu: Enabled MC I have sent 2/5 as individual patch before. To avoid confusion, let's start with v2. Change since v1: 2/5 ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoC Add L3 cache flushing Revised MMU table Re-create MMU in DDR after relocation Fix topology and clock registers This set should be applied in order. I will create a bundle in patchwor to include floating patches to show the dependency. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 4xx: cleanup ethernet phy initialization on PMC440 boards
This patch moves phy initialization for VSC8601 ethernet
phys that are used on early board revisions into a separate
setup function.
Signed-off-by: Matthias Fuchs
---
board/esd/pmc440/pmc440.c | 45 ++---
1 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/board/esd/pmc440/pmc440.c b/board/esd/pmc440/pmc440.c
index 7aee8e4..3165486 100644
--- a/board/esd/pmc440/pmc440.c
+++ b/board/esd/pmc440/pmc440.c
@@ -643,6 +643,23 @@ int is_pci_host(struct pci_controller *hose)
#endif /* defined(CONFIG_PCI) */
#ifdef CONFIG_RESET_PHY_R
+int pmc440_setup_vsc8601(char *devname, int phy_addr,
+unsigned short behavior, unsigned short method)
+{
+ /* adjust LED behavior */
+ if (miiphy_write(devname, phy_addr, 0x1f, 0x0001) != 0) {
+ printf("Phy%d: register write access failed\n", phy_addr);
+ return -1;
+ }
+
+ miiphy_write(devname, phy_addr, 0x11, 0x0010);
+ miiphy_write(devname, phy_addr, 0x11, behavior);
+ miiphy_write(devname, phy_addr, 0x10, method);
+ miiphy_write(devname, phy_addr, 0x1f, 0x);
+
+ return 0;
+}
+
int pmc440_setup_ksz9031(char *devname, int phy_addr)
{
unsigned short id1, id2;
@@ -683,29 +700,11 @@ void reset_phy(void)
val_behavior = 0x0cf0;
}
- if (miiphy_write("ppc_4xx_eth0",
-CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
- miiphy_write("ppc_4xx_eth0",
-CONFIG_PHY_ADDR, 0x11, 0x0010);
- miiphy_write("ppc_4xx_eth0",
-CONFIG_PHY_ADDR, 0x11, val_behavior);
- miiphy_write("ppc_4xx_eth0",
-CONFIG_PHY_ADDR, 0x10, val_method);
- miiphy_write("ppc_4xx_eth0",
-CONFIG_PHY_ADDR, 0x1f, 0x);
- }
-
- if (miiphy_write("ppc_4xx_eth1",
-CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
- miiphy_write("ppc_4xx_eth1",
-CONFIG_PHY1_ADDR, 0x11, 0x0010);
- miiphy_write("ppc_4xx_eth1",
-CONFIG_PHY1_ADDR, 0x11, val_behavior);
- miiphy_write("ppc_4xx_eth1",
-CONFIG_PHY1_ADDR, 0x10, val_method);
- miiphy_write("ppc_4xx_eth1",
-CONFIG_PHY1_ADDR, 0x1f, 0x);
- }
+ /* boards up to rev. 1.3 use Vitesse VSC8601 phys */
+ pmc440_setup_vsc8601("ppc_4xx_eth0", CONFIG_PHY_ADDR,
+val_method, val_behavior);
+ pmc440_setup_vsc8601("ppc_4xx_eth1", CONFIG_PHY1_ADDR,
+val_method, val_behavior);
} else {
/* rev. 1.4 uses a Micrel KSZ9031 */
pmc440_setup_ksz9031("ppc_4xx_eth0", CONFIG_PHY_ADDR);
--
1.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On 03/18/2014 10:50 PM, Masahiro Yamada wrote: > diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig > new file mode 100644 > index 000..fbf00f3 > --- /dev/null > +++ b/configs/beaver_defconfig > @@ -0,0 +1,10 @@ > +CONFIG_SPL=y > +CONFIG_ARM=y > +CONFIG_SYS_CPU="armv7" > +CONFIG_SOC_DIR=y > +CONFIG_SYS_SOC="tegra30" > +CONFIG_SYS_BOARD="beaver" > +CONFIG_VENDOR_DIR=y > +CONFIG_SYS_VENDOR="nvidia" > +CONFIG_SYS_CONFIG_NAME="beaver" > +CONFIG_BOARD_MAINTAINER="Tom Warren :Stephen Warren > " ... Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... >>> >>> This is really really Tegra-specific matter. >> >> Absolutely not at all. >> >> Any board contains a specific SoC. Each specific SoC is a particular CPU >> architecture and type, etc. > > In that case, all boards must have board/*/Kconfig to > automatically select correct CONFIG_SYS_VENDOR, CONFIG_SYS_SOC, etc. Yes. I would fully expect that. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] lib: uuid: code refactor for proper maintain between uuid bin and string
Dear Przemyslaw Marczak,
In message <1395251911-26540-2-git-send-email-p.marc...@samsung.com> you wrote:
> Changes in lib/uuid.c to:
> - uuid_str_to_bin()
> - uuid_bin_to_str()
Checkpatch says:
WARNING: do not add new typedefs
#199: FILE: include/uuid.h:10:
+typedef enum {
WARNING: line over 80 characters
#209: FILE: include/uuid.h:20:
+void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str, uuid_str_t
format);
Please fix.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/6] part_efi: move uuid<->string conversion functions into lib/uuid.c
Dear Przemyslaw Marczak, In message <1395251911-26540-1-git-send-email-p.marc...@samsung.com> you wrote: > Changes: > - move uuid<->string conversion functions into lib/uuid.c so they can be > used by code outside part_efi.c. > - rename uuid_string() to uuid_bin_to_str() for consistency with existing > uuid_str_to_bin() > - add an error return code to uuid_str_to_bin() > > Update existing code to the new library functions. Please make sure to run your patches through checkpatch. Here I get this: WARNING: line over 80 characters #331: FILE: lib/uuid.c:41: + * GUID is used e.g. in GPT (GUID Partition Table) as a partiions unique numbers. Please fix. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de People are very flexible and learn to adjust to strange surroundings -- they can become accustomed to read Lisp and Fortran programs, for example. - Leon Sterling and Ehud Shapiro, Art of Prolog, MIT Press ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MMC and buffer alignment question
Dear Eric Nelson, In message <5329df5a.7090...@boundarydevices.com> you wrote: > > IMHO, this seems like overkill. Should we also prevent over-writing > the stack or heap? No. But we should not add any specific alignment requirements to commands that transfer data to memory. If some driver has such needs internally, then it should be handled there, but in a way that is transparent to the user. > Note that "sata read/write" and "usb read/write" have the same issues. So these should be fixed, too. Patches welcome :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] PPC 85xx: Add qemu-ppce500 machine
On 02/20/2014 07:59 AM, Scott Wood wrote:
> On Thu, 2014-02-20 at 13:52 +0100, Alexander Graf wrote:
>> diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
>> index 3e99b07..51f2085 100644
>> --- a/arch/powerpc/cpu/mpc85xx/cpu.c
>> +++ b/arch/powerpc/cpu/mpc85xx/cpu.c
>> @@ -272,6 +272,7 @@ int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char
>> * const argv[])
>> #ifndef CONFIG_SYS_FSL_TBCLK_DIV
>> #define CONFIG_SYS_FSL_TBCLK_DIV 8
>> #endif
>> +__attribute__((weak))
>> unsigned long get_tbclk (void)
>> {
>> unsigned long tbclk_div = CONFIG_SYS_FSL_TBCLK_DIV;
>
> It's not a big deal, but we do have __weak available.
>
>> +static void map_fdt_as(int esel)
>> +{
>> +u32 mas0, mas1, mas2, mas3, mas7;
>> +uint64_t fdt_phys = get_fdt_phys();
>> +unsigned long fdt_phys_tlb = fdt_phys & ~0xful;
>> +unsigned long fdt_virt_tlb = (ulong)get_fdt_virt() & ~0xful;
>> +
>> +mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(10);
>
> Shouldn't you use the esel parameter here?
>
Are you going to address this comment with a new version?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Secure booting
+U-Boot mailing list Hi Jyoti, On 17 March 2014 22:25, JYOTI DUBEY wrote: > I am using i.mx6 board (Sabre lite design). The document that I have > followed is attached with this mail. But since there are differences > between u-boot 2009(as per the document) and u-boot 2013 I am not able to > figure out the locations at which the changes to be made. I am not sure the > value that should be made available in the csf pointer and also the size of > CSF data. Also since the size of u-boot 2009 is 2ec00 whereas that of > u-boot 2013 is 51c00 I am not sure if any addition padding is required(as > per the document) while using u-boot 2013. > Thanks in Advance! > Actually this is an SOC-specific secure boot, so not something I know anything about, sorry. Perhaps someone from the mx6 side will have some ideas. Regards, Simon > > > On Mon, Mar 17, 2014 at 9:25 AM, Simon Glass wrote: > >> Hi, >> >> On 15 March 2014 21:39, JYOTI DUBEY wrote: >> > >> > Can somebody inform me what all changes I need to make in U-boot 2013 >> > source code to enable secure booting? >> >> >> Please can you provide more details? >> >> - What board? >> - What docs have you already read? >> - Did you look at the settings in sandbox? >> - What problems do you have getting it running? >> >> Regards, >> Simon >> >> > >> > >> > >> > Thanks in Advance! >> > >> > ___ >> > 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] MMC and buffer alignment question
Hi Markus and Wolfgang, On 03/19/2014 10:40 AM, Markus Niebel wrote: Am 19.03.2014 15:44, wrote Wolfgang Denk: Dear Eric Nelson, In message <5329a80b.9020...@boundarydevices.com> you wrote: short question to the usage of the mmc command (and also the mmc driver API): is it intended that mmc read / write may fail when the supplied address in RAM is not aligned? If not intended, it is known. I consider this a known bug. ARMV7 will give output like this: U-Boot > mmc read 1202 44 44 Why would you want to do this? For example, BMP images require loading on a +2 aligned address due to their stupid header format. I ran into this before myself: it is impossible to match both the alignment reuqirements of the bmp command and the mmc read command at the same time. One must manually copy the memory ragen again. This is a plain, stupid bug. Exactly here it popped up ... It seems to me that if you're resorting to using un-formatted storage space to store a broken data structure (the BMP header), you could just write it at an offset +2. The BMP support is pretty difficult to use anyway (only supports BMPV3 headers), so asking the user to know about the offset doesn't seem onerous. Also note that the patch I submitted recently handles the case for gzipped files for those using cfb_console. Special commands inside the mmc drivers and in env_mmc implement the alignment magic. Shouldn't the mmc do the magic (and if neccesarry provide help using temp buffers if needed) so that all users outside can read / write without caring for special cases? Is there a use case here? There are plenty of memory addresses that won't work with commands like "mmc read". env_mmc needs to care for cache aligned buffers - This was fixed some time ago for the redundant env case "mmc read" and "mmc write" are operations that work on character buffers, like all other file IO ops. These should not require any specific alignment. Is it worth **any** code to try and catch them? Definitely yes. IMHO, this seems like overkill. Should we also prevent over-writing the stack or heap? So just as an idea - we could use a bounce buffer for mmc_bwrite / mmc_bread for the unaligned case. Is definitely slow but should work. Note that "sata read/write" and "usb read/write" have the same issues. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/6] lib: uuid: code refactor for proper maintain between uuid bin and string
Changes in lib/uuid.c to:
- uuid_str_to_bin()
- uuid_bin_to_str()
New parameter is added to specify input/output string format in listed functions
This change allows easy recognize which UUID type is or should be stored in
given
string array. Binary data of UUID and GUID is always stored in big endian, only
string representations are different as follows.
String byte: 0 36
String char: ----
string UUID:be be be be be
string GUID:le le le be be
This patch also updates functions calls and declarations in a whole code.
Signed-off-by: Przemyslaw Marczak
Cc: Stephen Warren
Cc: Lukasz Majewski
Cc: tr...@ti.com
---
Changes v4: (new commit)
- change simple error checking to uuid_str_valid() in uuid_str_to_bin()
- add new parameter to define UUID string format for UUID or GUID which diffe
in endianness of first three string blocks.
- update functions calls and declarations
- add uuid.h header
- remove functions declarations from common.h
---
disk/part_efi.c | 17 ++--
include/common.h | 4 +--
include/uuid.h | 21 ++
lib/uuid.c | 85
4 files changed, 92 insertions(+), 35 deletions(-)
create mode 100644 include/uuid.h
diff --git a/disk/part_efi.c b/disk/part_efi.c
index a280ab5..216a292 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -100,8 +100,8 @@ void print_part_efi(block_dev_desc_t * dev_desc)
printf("Part\tStart LBA\tEnd LBA\t\tName\n");
printf("\tAttributes\n");
- printf("\tType UUID\n");
- printf("\tPartition UUID\n");
+ printf("\tType GUID\n");
+ printf("\tPartition GUID\n");
for (i = 0; i < le32_to_cpu(gpt_head->num_partition_entries); i++) {
/* Stop at the first non valid PTE */
@@ -114,11 +114,11 @@ void print_part_efi(block_dev_desc_t * dev_desc)
print_efiname(&gpt_pte[i]));
printf("\tattrs:\t0x%016llx\n", gpt_pte[i].attributes.raw);
uuid_bin = (unsigned char *)gpt_pte[i].partition_type_guid.b;
- uuid_bin_to_str(uuid_bin, uuid);
+ uuid_bin_to_str(uuid_bin, uuid, UUID_STR_FORMAT_GUID);
printf("\ttype:\t%s\n", uuid);
uuid_bin = (unsigned char *)gpt_pte[i].unique_partition_guid.b;
- uuid_bin_to_str(uuid_bin, uuid);
- printf("\tuuid:\t%s\n", uuid);
+ uuid_bin_to_str(uuid_bin, uuid, UUID_STR_FORMAT_GUID);
+ printf("\tguid:\t%s\n", uuid);
}
/* Remember to free pte */
@@ -165,7 +165,8 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int
part,
sprintf((char *)info->type, "U-Boot");
info->bootable = is_bootable(&gpt_pte[part - 1]);
#ifdef CONFIG_PARTITION_UUIDS
- uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b, info->uuid);
+ uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b, info->uuid,
+ UUID_STR_FORMAT_GUID);
#endif
debug("%s: start 0x" LBAF ", size 0x" LBAF ", name %s", __func__,
@@ -323,7 +324,7 @@ int gpt_fill_pte(gpt_header *gpt_h, gpt_entry *gpt_e,
str_uuid = partitions[i].uuid;
bin_uuid = gpt_e[i].unique_partition_guid.b;
- if (uuid_str_to_bin(str_uuid, bin_uuid)) {
+ if (uuid_str_to_bin(str_uuid, bin_uuid, UUID_STR_FORMAT_STD)) {
printf("Partition no. %d: invalid guid: %s\n",
i, str_uuid);
return -1;
@@ -370,7 +371,7 @@ int gpt_fill_header(block_dev_desc_t *dev_desc, gpt_header
*gpt_h,
gpt_h->header_crc32 = 0;
gpt_h->partition_entry_array_crc32 = 0;
- if (uuid_str_to_bin(str_guid, gpt_h->disk_guid.b))
+ if (uuid_str_to_bin(str_guid, gpt_h->disk_guid.b, UUID_STR_FORMAT_GUID))
return -1;
return 0;
diff --git a/include/common.h b/include/common.h
index b1d1068..658c326 100644
--- a/include/common.h
+++ b/include/common.h
@@ -816,9 +816,7 @@ voidudelay(unsigned long);
void mdelay(unsigned long);
/* lib/uuid.c */
-void uuid_bin_to_str(unsigned char *uuid, char *str);
-int uuid_str_to_bin(char *uuid, unsigned char *out);
-int uuid_str_valid(const char *uuid);
+#include
/* lib/vsprintf.c */
#include
diff --git a/include/uuid.h b/include/uuid.h
new file mode 100644
index 000..0d16038
--- /dev/null
+++ b/include/uuid.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ * Przemyslaw Marczak
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef __UUID_H__
+#define __UUID_H__
+
+typedef enum {
+ UUID_STR_FORMAT_STD,
+ UUID_STR_FORMAT_GUID
+} uuid_str_t;
+
+#define UUID_STR_LEN 36
+#define UUID_BIN_LEN 16
+
+int uuid_str_valid(const char *uuid);
+int uuid_str_to_bin(char *uuid_str, unsigned c
[U-Boot] [PATCH v4 5/6] cmd:gpt: randomly generate each partition uuid if undefined
Changes:
- randomly generate partition uuid if any is undefined and CONFIG_RAND_UUID
is defined
- print debug info about set/unset/generated uuid
- update doc/README.gpt
Signed-off-by: Przemyslaw Marczak
Acked-by: Lukasz Majewski
Cc: Piotr Wilczek
Cc: Tom Rini
Cc: Stephen Warren
Cc: Lukasz Majewski
---
Changes v2:
- cmd_gpt: extract_env: change return type from char to int
- add tmp array to generate uuid string
- store generated uuid in env and next get it from it - don't need to alloc
and maintain allcoated memory outside extract_env()
Changes v3:
- print info if uuid_gpt_* env is get from env/set random
- change some word in README.gpt to meaningful
Changes v4:
- change printf/puts to debug
- reduce indentation level in extract_env()
- generate rand uuid if CONFIG_RAND_UUID is defined
---
common/cmd_gpt.c | 62 +---
doc/README.gpt | 24 --
lib/uuid.c | 4 ++--
3 files changed, 66 insertions(+), 24 deletions(-)
diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
index 1f12e6d..4048b77 100644
--- a/common/cmd_gpt.c
+++ b/common/cmd_gpt.c
@@ -29,30 +29,52 @@
*
* @return - zero on successful expand and env is set
*/
-static char extract_env(const char *str, char **env)
+static int extract_env(const char *str, char **env)
{
+ int ret = -1;
char *e, *s;
-
+#ifdef CONFIG_RANDOM_UUID
+ char uuid_str[UUID_STR_LEN + 1];
+#endif
if (!str || strlen(str) < 4)
return -1;
- if ((strncmp(str, "${", 2) == 0) && (str[strlen(str) - 1] == '}')) {
- s = strdup(str);
- if (s == NULL)
- return -1;
- memset(s + strlen(s) - 1, '\0', 1);
- memmove(s, s + 2, strlen(s) - 1);
+ if (!((strncmp(str, "${", 2) == 0) && (str[strlen(str) - 1] == '}')))
+ return -1;
+
+ s = strdup(str);
+ if (s == NULL)
+ return -1;
+
+ memset(s + strlen(s) - 1, '\0', 1);
+ memmove(s, s + 2, strlen(s) - 1);
+
+ e = getenv(s);
+ if (e == NULL) {
+#ifdef CONFIG_RANDOM_UUID
+ debug("%s unset. ", str);
+ gen_rand_uuid_str(uuid_str, UUID_STR_FORMAT_STD);
+ setenv(s, uuid_str);
+
e = getenv(s);
- free(s);
- if (e == NULL) {
- printf("Environmental '%s' not set\n", str);
- return -1; /* env not set */
+ if (e) {
+ debug("Set to random.\n");
+ ret = 0;
+ } else {
+ debug("Can't get random UUID.\n");
}
- *env = e;
- return 0;
+#else
+ debug("%s unset.\n", str);
+#endif
+ } else {
+ debug("%s get from environment.\n", str);
+ ret = 0;
}
- return -1;
+ *env = e;
+ free(s);
+
+ return ret;
}
/**
@@ -299,8 +321,16 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return CMD_RET_FAILURE;
}
- if (gpt_default(blk_dev_desc, argv[4]))
+ puts("Writing GPT: ");
+
+ ret = gpt_default(blk_dev_desc, argv[4]);
+ if (!ret) {
+ puts("success!\n");
+ return CMD_RET_SUCCESS;
+ } else {
+ puts("error!\n");
return CMD_RET_FAILURE;
+ }
} else {
return CMD_RET_USAGE;
}
diff --git a/doc/README.gpt b/doc/README.gpt
index 5c133f3..51515c8 100644
--- a/doc/README.gpt
+++ b/doc/README.gpt
@@ -101,7 +101,7 @@ Offset SizeDescription
40 8 B First usable LBA for partitions (primary partition table last
LBA + 1)
48 8 B Last usable LBA (secondary partition table first LBA - 1)
-56 16 BDisk GUID (also referred as UUID on UNIXes)
+56 16 BDisk GUID (also referred as UUID on UNIXes) in big endian
72 8 B Partition entries starting LBA (always 2 in primary copy)
80 4 B Number of partition entries
84 4 B Size of a partition entry (usually 128)
@@ -132,8 +132,8 @@ of the Primary.
--
Offset SizeDescription
- 0 16 BPartition type GUID
- 16 16 BUnique partition GUID
+ 0 16 BPartition type GUID (Big Endian)
+ 16 16 BUnique partition GUID in (Big Endian)
32 8 BFirst LBA (Little Endian)
40 8 BLast LBA (inclusive)
48 8 BAttribute flags [+]
@@ -160,6 +160,9 @@ To restore GUID partition table one needs to:
Fields 'name', 'size' and 'uuid' are mandatory for every partition.
The field 'start' is optional.
+ option: CON
[U-Boot] [PATCH v4 3/6] lib: uuid: add functions to generate UUID version 4
This patch adds support to generate UUID (Universally Unique Identifier)
in version 4 based on RFC4122, which is randomly.
Source: https://www.ietf.org/rfc/rfc4122.txt
Changes:
- add new config: CONFIG_RANDOM_UUID: compile uuid.c and rand.c
lib/uuid.c:
- add gen_rand_uuid() - this function writes 16 bytes len binary representati
UUID v4 to the memory at given address.
- add gen_rand_uuid_str() - this function writes 37 bytes len hexadecimal
ASCII string representation of UUID v4 to the memory at given address.
Signed-off-by: Przemyslaw Marczak
Cc: Stephen Warren
Cc: Lukasz Majewski
Cc: tr...@ti.com
---
Changes v2:
- put uuid generation changes in a separate commit
- get_uuid_str() - change name to gen_rand_uuid_str()
- add new function: gen_rand_uuid()
- remove unnecessary '\0' at the end of uuid string
- drop unnecessary error checking
- functions now takes pointers to allocated memory instead of alloc it itself
- add new config option: CONFIG_RANDOM_UUID
Changes v3:
- remove unused UUID_STR_BYTE_LEN
- reword comments
- remove null pointer checking from gen_rand_uuid() and gen_rand_uuid_str()
- remove unneeded memset from gen_rand_uuid()
- undo moving vsprintf.o object in lib/Makefile
- add attribute "packed" to the uuid structure
- gen_rand_uuid(): add endian functions for modify uuid data
- gen_rand_uuid(): use memcpy() to store uuid data into given buffer for avoi
unaligned access issues
- change uuid version and variant masks to proper for use with clrsetbits_*
- add #ifdef CONFIG_RANDOM_UUID to random uuid code for avoid warnings
Changes v4:
- add new parameter to define UUID string format for UUID or GUID which differs
in endianness of first three string blocks.
- add uuid structure and version 4 data to uuid header file
- lib/Makefile: add CONFIG_RAND_UUID dependency to rand.o and uuid.o
---
include/common.h | 3 ++-
include/uuid.h | 22 ++-
lib/Makefile | 2 ++
lib/uuid.c | 65 ++--
4 files changed, 88 insertions(+), 4 deletions(-)
diff --git a/include/common.h b/include/common.h
index 658c326..deb08f2 100644
--- a/include/common.h
+++ b/include/common.h
@@ -830,7 +830,8 @@ char * strmhz(char *buf, unsigned long hz);
/* lib/rand.c */
#if defined(CONFIG_RANDOM_MACADDR) || \
defined(CONFIG_BOOTP_RANDOM_DELAY) || \
- defined(CONFIG_CMD_LINK_LOCAL)
+ defined(CONFIG_CMD_LINK_LOCAL) || \
+ defined(CONFIG_RANDOM_UUID)
#define RAND_MAX -1U
void srand(unsigned int seed);
unsigned int rand(void);
diff --git a/include/uuid.h b/include/uuid.h
index 0d16038..32e592c 100644
--- a/include/uuid.h
+++ b/include/uuid.h
@@ -7,15 +7,35 @@
#ifndef __UUID_H__
#define __UUID_H__
+/* This is structure is in big-endian */
+struct uuid {
+ unsigned int time_low;
+ unsigned short time_mid;
+ unsigned short time_hi_and_version;
+ unsigned char clock_seq_hi_and_reserved;
+ unsigned char clock_seq_low;
+ unsigned char node[6];
+} __packed;
+
typedef enum {
UUID_STR_FORMAT_STD,
UUID_STR_FORMAT_GUID
} uuid_str_t;
#define UUID_STR_LEN 36
-#define UUID_BIN_LEN 16
+#define UUID_BIN_LEN sizeof(struct uuid)
+
+#define UUID_VERSION_MASK 0xf000
+#define UUID_VERSION_SHIFT 12
+#define UUID_VERSION 0x4
+
+#define UUID_VARIANT_MASK 0xc0
+#define UUID_VARIANT_SHIFT 7
+#define UUID_VARIANT 0x1
int uuid_str_valid(const char *uuid);
int uuid_str_to_bin(char *uuid_str, unsigned char *uuid_bin, uuid_str_t
format);
void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str, uuid_str_t
format);
+void gen_rand_uuid(unsigned char *uuid_bin);
+void gen_rand_uuid_str(char *uuid_str, uuid_str_t format);
#endif
diff --git a/lib/Makefile b/lib/Makefile
index 2e8bd20..fd75e80 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -63,6 +63,8 @@ obj-$(CONFIG_TRACE) += trace.o
obj-$(CONFIG_BOOTP_PXE) += uuid.o
obj-$(CONFIG_PARTITION_UUIDS) += uuid.o
obj-y += vsprintf.o
+obj-$(CONFIG_RANDOM_UUID) += uuid.o
+obj-$(CONFIG_RANDOM_UUID) += rand.o
obj-$(CONFIG_RANDOM_MACADDR) += rand.o
obj-$(CONFIG_BOOTP_RANDOM_DELAY) += rand.o
obj-$(CONFIG_CMD_LINK_LOCAL) += rand.o
diff --git a/lib/uuid.c b/lib/uuid.c
index 75a5608..d3ba60e 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -14,8 +14,23 @@
/*
* UUID - Universally Unique IDentifier - 128 bits unique number.
*There are 5 versions and one variant of UUID defined by RFC4122
- *specification. Depends on version uuid number base on a time,
- *host name, MAC address or random data.
+ *specification. Depends on version uuid number base on:
+ *- time, MAC address(v1),
+ *- user ID(v2),
+ *- MD5 of name or URL(v3),
+ *- random data(v4),
+ *- SHA-1 of name or URL(v5),
+ *
+ * This library implements UUID v4.
+ *
+ * Layout of UUID Version 4:
+ * timestamp - 60-bit: time_low, time_m
[U-Boot] [PATCH v4 4/6] new commands: uuid and guid - generate random unique identifier
Those commands basis on implementation of random UUID generator version 4
which is described in RFC4122. The same algorithm is used for generation
both ids but string representation is different as below.
char: 0914 19 24 36
----
UUID: be be be be be
GUID: le le le be be
Commands usage:
- uuid
- guid
The result is saved in environment as a "varname" variable if argument is given,
if not then its printed.
New config:
- CONFIG_CMD_UUID
Signed-off-by: Przemyslaw Marczak
Cc: Stephen Warren
Cc: Lukasz Majewski
Cc: tr...@ti.com
---
Changes v4:
- new commit
---
README | 2 +-
include/common.h | 4 +++-
lib/Makefile | 2 ++
lib/uuid.c | 44 +++-
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 216f0c7..f69b94e 100644
--- a/README
+++ b/README
@@ -1012,7 +1012,7 @@ The following options need to be configured:
CONFIG_CMD_CDP * Cisco Discover Protocol support
CONFIG_CMD_MFSL * Microblaze FSL support
CONFIG_CMD_XIMG Load part of Multi Image
-
+ CONFIG_CMD_UUID * Generate random UUID or GUID string
EXAMPLE: If you want all functions except of network
support you can write:
diff --git a/include/common.h b/include/common.h
index deb08f2..de748f1 100644
--- a/include/common.h
+++ b/include/common.h
@@ -831,7 +831,9 @@ char * strmhz(char *buf, unsigned long hz);
#if defined(CONFIG_RANDOM_MACADDR) || \
defined(CONFIG_BOOTP_RANDOM_DELAY) || \
defined(CONFIG_CMD_LINK_LOCAL) || \
- defined(CONFIG_RANDOM_UUID)
+ defined(CONFIG_RANDOM_UUID) || \
+ defined(CONFIG_CMD_UUID)
+
#define RAND_MAX -1U
void srand(unsigned int seed);
unsigned int rand(void);
diff --git a/lib/Makefile b/lib/Makefile
index fd75e80..b85c825 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -65,6 +65,8 @@ obj-$(CONFIG_PARTITION_UUIDS) += uuid.o
obj-y += vsprintf.o
obj-$(CONFIG_RANDOM_UUID) += uuid.o
obj-$(CONFIG_RANDOM_UUID) += rand.o
+obj-$(CONFIG_CMD_UUID) += uuid.o
+obj-$(CONFIG_CMD_UUID) += rand.o
obj-$(CONFIG_RANDOM_MACADDR) += rand.o
obj-$(CONFIG_BOOTP_RANDOM_DELAY) += rand.o
obj-$(CONFIG_CMD_LINK_LOCAL) += rand.o
diff --git a/lib/uuid.c b/lib/uuid.c
index d3ba60e..0112b03 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -4,6 +4,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include
#include
#include
#include
@@ -172,7 +173,7 @@ void uuid_bin_to_str(unsigned char *uuid_bin, char
*uuid_str,
*
* @param uuid_bin - pointer to allocated array [16B]. Output is in big endian.
*/
-#ifdef CONFIG_RANDOM_UUID
+#if defined(CONFIG_RANDOM_UUID) || defined(CONFIG_CMD_UUID)
void gen_rand_uuid(unsigned char *uuid_bin)
{
struct uuid uuid;
@@ -211,4 +212,45 @@ void gen_rand_uuid_str(char *uuid_str, uuid_str_t
str_format)
/* Convert UUID bin to UUID or GUID formated STRING */
uuid_bin_to_str(uuid_bin, uuid_str, str_format);
}
+
+#ifdef CONFIG_CMD_UUID
+int do_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ char uuid[UUID_STR_LEN + 1];
+ uuid_str_t str_format;
+
+ if (!strcmp(argv[0], "uuid"))
+ str_format = UUID_STR_FORMAT_STD;
+ else
+ str_format = UUID_STR_FORMAT_GUID;
+
+ if (argc == 1) {
+ gen_rand_uuid_str(uuid, str_format);
+ printf("%s\n", uuid);
+ } else if (argc == 2) {
+ gen_rand_uuid_str(uuid, str_format);
+ setenv(argv[1], uuid);
+ } else {
+ return CMD_RET_USAGE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(uuid, CONFIG_SYS_MAXARGS, 1, do_uuid,
+ "UUID - generate Universally Unique Identifier version 4",
+ "\n"
+ "Argument:\n"
+ "varname: for set result in a environment variable\n"
+ "e.g. uuid uuid_env"
+);
+
+U_BOOT_CMD(guid, CONFIG_SYS_MAXARGS, 1, do_uuid,
+ "GUID - generate Globally Unique Identifier based on UUID version 4",
+ "\n"
+ "Argument:\n"
+ "varname: for set result in a environment variable\n"
+ "e.g. guid guid_env"
+);
+#endif
#endif
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/6] part_efi: move uuid<->string conversion functions into lib/uuid.c
Changes:
- move uuid<->string conversion functions into lib/uuid.c so they can be
used by code outside part_efi.c.
- rename uuid_string() to uuid_bin_to_str() for consistency with existing
uuid_str_to_bin()
- add an error return code to uuid_str_to_bin()
Update existing code to the new library functions.
Signed-off-by: Przemyslaw Marczak
Cc: Stephen Warren
Cc: Lukasz Majewski
Cc: tr...@ti.com
---
Changes v2:
- This commit is new after separate:
[PATCH 1/2] lib: uuid: add function to generate UUID version 4
- it introduces small refactor of common lib uuid functions
Changes v3:
- reword commit message
- add UUID_STR_LEN definition in lib/uuid.c
- remove unused string pointer from uuid_bin_to_str()
Changes v4:
- add uuid/guid description
---
disk/part_efi.c | 90 +++-
include/common.h | 3 +-
lib/Makefile | 1 +
lib/uuid.c | 61 +-
4 files changed, 68 insertions(+), 87 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 733d5bd..a280ab5 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -63,26 +63,6 @@ static char *print_efiname(gpt_entry *pte)
return name;
}
-static void uuid_string(unsigned char *uuid, char *str)
-{
- static const u8 le[16] = {3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11,
- 12, 13, 14, 15};
- int i;
-
- for (i = 0; i < 16; i++) {
- sprintf(str, "%02x", uuid[le[i]]);
- str += 2;
- switch (i) {
- case 3:
- case 5:
- case 7:
- case 9:
- *str++ = '-';
- break;
- }
- }
-}
-
static efi_guid_t system_guid = PARTITION_SYSTEM_GUID;
static inline int is_bootable(gpt_entry *p)
@@ -103,6 +83,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
gpt_entry *gpt_pte = NULL;
int i = 0;
char uuid[37];
+ unsigned char *uuid_bin;
if (!dev_desc) {
printf("%s: Invalid Argument(s)\n", __func__);
@@ -132,9 +113,11 @@ void print_part_efi(block_dev_desc_t * dev_desc)
le64_to_cpu(gpt_pte[i].ending_lba),
print_efiname(&gpt_pte[i]));
printf("\tattrs:\t0x%016llx\n", gpt_pte[i].attributes.raw);
- uuid_string(gpt_pte[i].partition_type_guid.b, uuid);
+ uuid_bin = (unsigned char *)gpt_pte[i].partition_type_guid.b;
+ uuid_bin_to_str(uuid_bin, uuid);
printf("\ttype:\t%s\n", uuid);
- uuid_string(gpt_pte[i].unique_partition_guid.b, uuid);
+ uuid_bin = (unsigned char *)gpt_pte[i].unique_partition_guid.b;
+ uuid_bin_to_str(uuid_bin, uuid);
printf("\tuuid:\t%s\n", uuid);
}
@@ -182,7 +165,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int
part,
sprintf((char *)info->type, "U-Boot");
info->bootable = is_bootable(&gpt_pte[part - 1]);
#ifdef CONFIG_PARTITION_UUIDS
- uuid_string(gpt_pte[part - 1].unique_partition_guid.b, info->uuid);
+ uuid_bin_to_str(gpt_pte[part - 1].unique_partition_guid.b, info->uuid);
#endif
debug("%s: start 0x" LBAF ", size 0x" LBAF ", name %s", __func__,
@@ -237,60 +220,6 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
return 0;
}
-/**
- * string_uuid(); Convert UUID stored as string to bytes
- *
- * @param uuid - UUID represented as string
- * @param dst - GUID buffer
- *
- * @return return 0 on successful conversion
- */
-static int string_uuid(char *uuid, u8 *dst)
-{
- efi_guid_t guid;
- u16 b, c, d;
- u64 e;
- u32 a;
- u8 *p;
- u8 i;
-
- const u8 uuid_str_len = 36;
-
- /* The UUID is written in text: */
- /* 1914 19 24 */
- /* ---- */
-
- debug("%s: uuid: %s\n", __func__, uuid);
-
- if (strlen(uuid) != uuid_str_len)
- return -1;
-
- for (i = 0; i < uuid_str_len; i++) {
- if ((i == 8) || (i == 13) || (i == 18) || (i == 23)) {
- if (uuid[i] != '-')
- return -1;
- } else {
- if (!isxdigit(uuid[i]))
- return -1;
- }
- }
-
- a = (u32)simple_strtoul(uuid, NULL, 16);
- b = (u16)simple_strtoul(uuid + 9, NULL, 16);
- c = (u16)simple_strtoul(uuid + 14, NULL, 16);
- d = (u16)simple_strtoul(uuid + 19, NULL, 16);
- e = (u64)simple_strtoull(uuid + 24, NULL, 16);
-
- p = (u8 *) &e;
- guid = EFI_GUID(a, b, c, d >> 8, d & 0xFF,
- *(p + 5), *(p + 4), *(p + 3),
- *(p + 2), *(p + 1) , *p);
-
- memcpy(dst, guid.b, sizeof(efi_guid_t));
-
- return 0;
-}
-
int write_gpt_table(block
[U-Boot] [PATCH v4 6/6] trats/trats2: enable CONFIG_RANDOM_UUID
Signed-off-by: Przemyslaw Marczak Cc: Minkyu Kang Cc: Piotr Wilczek Cc: Stephen Warren Cc: Lukasz Majewski Cc: tr...@ti.com --- include/configs/trats.h | 1 + include/configs/trats2.h | 1 + 2 files changed, 2 insertions(+) diff --git a/include/configs/trats.h b/include/configs/trats.h index 7cea259..30a978c 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -276,6 +276,7 @@ /* GPT */ #define CONFIG_EFI_PARTITION #define CONFIG_PARTITION_UUIDS +#define CONFIG_RANDOM_UUID #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_CACHELINE_SIZE 32 diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 6d389df..df98b70 100644 --- a/include/configs/trats2.h +++ b/include/configs/trats2.h @@ -283,6 +283,7 @@ #define CONFIG_ENV_OFFSET ((32 - 4) << 10) /* 32KiB - 4KiB */ #define CONFIG_EFI_PARTITION #define CONFIG_PARTITION_UUIDS +#define CONFIG_RANDOM_UUID #define CONFIG_BOARD_EARLY_INIT_F -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MMC and buffer alignment question
Am 19.03.2014 15:44, wrote Wolfgang Denk: > Dear Eric Nelson, > > In message <5329a80b.9020...@boundarydevices.com> you wrote: >> >>> short question to the usage of the mmc command (and also the mmc >>> driver API): is it intended that mmc read / write may fail when the >>> supplied address in RAM is not aligned? >> >> If not intended, it is known. > > I consider this a known bug. > >>> ARMV7 will give output like this: >>> >>> U-Boot > mmc read 1202 44 44 >>> >> Why would you want to do this? > > For example, BMP images require loading on a +2 aligned address due to > their stupid header format. I ran into this before myself: it is > impossible to match both the alignment reuqirements of the bmp command > and the mmc read command at the same time. One must manually copy the > memory ragen again. This is a plain, stupid bug. > Exactly here it popped up ... >>> Special commands inside the mmc drivers and in env_mmc implement the >>> alignment magic. Shouldn't the mmc do the magic (and if neccesarry >>> provide help using temp buffers if needed) so that all users outside can >>> read / write without caring for special cases? >> >> Is there a use case here? There are plenty of memory addresses that >> won't work with commands like "mmc read". > env_mmc needs to care for cache aligned buffers - This was fixed some time ago for the redundant env case > "mmc read" and "mmc write" are operations that work on character > buffers, like all other file IO ops. These should not require any > specific alignment. > >> Is it worth **any** code to try and catch them? > > Definitely yes. > So just as an idea - we could use a bounce buffer for mmc_bwrite / mmc_bread for the unaligned case. Is definitely slow but should work. > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On Wed, Mar 19, 2014 at 03:20:49PM +0100, Wolfgang Denk wrote: > Dear Daniel Schwierzeck, > > please do not full-quote. Thanks. > > In message > you > wrote: > > > > maybe we should import get_maintainers.pl from kernel and readd > > MAINTAINERS in the according format. So we could easily maintain infos > > about board maintainers, custodians, custodian trees and maintaining > > status per arch, CPU, SOC, drivers and boards in one place. Currently > > that is not possible because one has to look into different sources > > (boards.cfg, README's, U-Boot Wiki, git history, source file) to get > > those infos. > > We have just created such a single point of information (boards.cfg), > and now we're ripping it apart again :-( What Daniel said is right, we don't have a single point today, we have boards.cfg, wiki and other stuff. Being able to leverage get_maintainers.pl would be nice, even if it's a bit of a pain that we just got things into boards.cfg. On the other hand, it's good that we've just spent some time sorting and checking the information and it's a regex'able problem to go from boards.cfg to MAINTAINERS. -- 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] MMC and buffer alignment question
Dear Eric Nelson, In message <5329a80b.9020...@boundarydevices.com> you wrote: > > > short question to the usage of the mmc command (and also the mmc > > driver API): is it intended that mmc read / write may fail when the > > supplied address in RAM is not aligned? > > If not intended, it is known. I consider this a known bug. > > ARMV7 will give output like this: > > > > U-Boot > mmc read 1202 44 44 > > > Why would you want to do this? For example, BMP images require loading on a +2 aligned address due to their stupid header format. I ran into this before myself: it is impossible to match both the alignment reuqirements of the bmp command and the mmc read command at the same time. One must manually copy the memory ragen again. This is a plain, stupid bug. > > Special commands inside the mmc drivers and in env_mmc implement the > > alignment magic. Shouldn't the mmc do the magic (and if neccesarry > > provide help using temp buffers if needed) so that all users outside can > > read / write without caring for special cases? > > Is there a use case here? There are plenty of memory addresses that > won't work with commands like "mmc read". "mmc read" and "mmc write" are operations that work on character buffers, like all other file IO ops. These should not require any specific alignment. > Is it worth **any** code to try and catch them? Definitely yes. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MMC and buffer alignment question
Hi Markus, On 03/19/2014 07:16 AM, Markus Niebel wrote: Hello Pantelis, short question to the usage of the mmc command (and also the mmc driver API): is it intended that mmc read / write may fail when the supplied address in RAM is not aligned? If not intended, it is known. ARMV7 will give output like this: U-Boot > mmc read 1202 44 44 Why would you want to do this? MMC read: dev # 0, block # 68, count 68 ... INFO: 24994 of 25000 loops left to DAT0 timeout ERROR: v7_dcache_inval_range - start address is not aligned - 0x1202 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x12008802 68 blocks read: OK On my platform (i.MX6 / Cortex A9) the alignment needed is 32 Byte. Special commands inside the mmc drivers and in env_mmc implement the alignment magic. Shouldn't the mmc do the magic (and if neccesarry provide help using temp buffers if needed) so that all users outside can read / write without caring for special cases? Is there a use case here? There are plenty of memory addresses that won't work with commands like "mmc read". Is it worth **any** code to try and catch them? Please advise, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question about mpc85xx startup using Nor Flash
I'm porting u-boot to P2040 based board these days. As u-boot/arch/powerpc/mpc85xx/start.s commented: *The processor starts at 0x_fffc and the code is first executed in the last 4K page in flash/rom.* The E500MCRM Chapter 6.6 mentioned: *This default TLB entry translates the first instruction fetch out of reset(at effective address 0x_fffc).* *This instruction should be a branch to the beginning of this page.* So, if I configure the HCW to let powerpc boot from Nor Flash, why should I suppose that the Nor Flash's last 4K is mapped to 0x_f000~0x_. Since there're no LAW setup yet and the default BR0/OR0 of Local Bus does not match that range. And what is the instruction at 0x_fffc and where is it from? Best Regards, Hook Guo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Porting U-Boot Issue - Linking fails
Hi, I'm attempting to port u-boot for NS7520 (arm7tdmi). My idea was to first revive the port of NS9750 (removed in commit4cfc611b4a4ce009cfad46804bec2a1caad8e329) and then rename and configure it for NS7520 which is quite similar. But I've kind of hit a wall, that I don't understand. === git clean -dfx > /dev/null && make ns9750dev_config all LDS u-boot.lds LD u-boot arm-linux-gnueabi-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.23.2 assertion fail ../../bfd/elf32-arm.c:7683 arm-linux-gnueabi-ld.bfd: error: required section '.rel.plt' not found in the linker script arm-linux-gnueabi-ld.bfd: final link failed: Invalid operation make[1]: *** [u-boot] Error 1 === At first I thought this issue was thou to the toolchain I used. I expressed these thoughts in #u-boot@freenode, but no matter which toolchain I use, I always get this error, for this port. (Other configurations that are similar builds without any noticeable issues.) I have tried the following toolchains 1. ELDK-5.5 armv5te 2. arm-linux-gnueabi from gcc-arm-linux-gnueabi package 3. arm-none-eabi from gcc-arm-none-eabi package (ppa:terry.guo/gcc-embedded) All resulting in the same build error. I have also tried using all three different linkers that comes with the gcc-arm-linux-gnueabi package (ld, ld.bfd and ld.gold), all of this also fails in the same way. So all in all, it feels highly unlikely that this is a compiler issue. It is rather something with the code (https://github.com/soderstrom-rikard/u-boot/tree/ns9750) Off course I've tried just adding the section .rel.plt to the linker description script, this had no effect either. I mimicked patch lists.denx.de/pipermail/u-boot/2010-November/081709.html Can anyone help me? I feel so clueless about this, that it is ridiculous :) Yours Sincerely Rikard Söderström -- View this message in context: http://u-boot.10912.n7.nabble.com/Porting-U-Boot-Issue-Linking-fails-tp176245.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Dear Daniel Schwierzeck, please do not full-quote. Thanks. In message you wrote: > > maybe we should import get_maintainers.pl from kernel and readd > MAINTAINERS in the according format. So we could easily maintain infos > about board maintainers, custodians, custodian trees and maintaining > status per arch, CPU, SOC, drivers and boards in one place. Currently > that is not possible because one has to look into different sources > (boards.cfg, README's, U-Boot Wiki, git history, source file) to get > those infos. We have just created such a single point of information (boards.cfg), and now we're ripping it apart again :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "It is better to have tried and failed than to have failed to try, but the result's the same." - Mike Dennison ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MMC and buffer alignment question
Hello Pantelis, short question to the usage of the mmc command (and also the mmc driver API): is it intended that mmc read / write may fail when the supplied address in RAM is not aligned? ARMV7 will give output like this: U-Boot > mmc read 1202 44 44 MMC read: dev # 0, block # 68, count 68 ... INFO: 24994 of 25000 loops left to DAT0 timeout ERROR: v7_dcache_inval_range - start address is not aligned - 0x1202 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x12008802 68 blocks read: OK On my platform (i.MX6 / Cortex A9) the alignment needed is 32 Byte. Special commands inside the mmc drivers and in env_mmc implement the alignment magic. Shouldn't the mmc do the magic (and if neccesarry provide help using temp buffers if needed) so that all users outside can read / write without caring for special cases? Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] config:trats2: Change u-boot's TEXT_BASE from 0x78100000 to 0x43e00000
The u-boot's image TEXT_BASE needs to be changed to 0x43e0 from 0x7810. This change provides compatibility with other trats2 (RD_PQ) devices (http://download.tizen.org/releases/system/). Signed-off-by: Lukasz Majewski Cc: Minkyu Kang --- include/configs/trats2.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 823a8ae..85cf4aa 100644 --- a/include/configs/trats2.h +++ b/include/configs/trats2.h @@ -36,7 +36,7 @@ #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 0x5E0) #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x3E0) -#define CONFIG_SYS_TEXT_BASE 0x7810 +#define CONFIG_SYS_TEXT_BASE 0x43e0 #include /* Size of malloc() pool */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot doesnt execute
Hi, This is not the list where you should ask this question. Please use forums.xilinx.com instead. Thanks, Michal On 03/19/2014 01:33 PM, Donkor, Cletus-Afrifa wrote: > Dear Sir/Madam, > > i am currently facing a few problems with my U-boot. I am using a customised > Xilinx Zynq 7045 board. > I have been struggling for the past few days to run linux on this board. I > aquired the u-boot file from the > Zynq 2013.4-release.tar.xz. > > I have been able to successfully download the u-boot.elf to my QSPI and the > image file to my DDR. > The uboot can however not execute. > > I hope you can help me find a solution to this problem. Hoping to hear from > you soon. > > Thank you. > > > > Best Regards / Mit freundlichen Grüßen > > Cletus Afrifa Donkor > Werkstudent > Airbus Defence and Space > COEED3 > > Wörthstraße 85 > 89077 ULM- Germany > cletus-afrifa.don...@cassidian.com > > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot doesnt execute
Dear Sir/Madam, i am currently facing a few problems with my U-boot. I am using a customised Xilinx Zynq 7045 board. I have been struggling for the past few days to run linux on this board. I aquired the u-boot file from the Zynq 2013.4-release.tar.xz. I have been able to successfully download the u-boot.elf to my QSPI and the image file to my DDR. The uboot can however not execute. I hope you can help me find a solution to this problem. Hoping to hear from you soon. Thank you. Best Regards / Mit freundlichen Grüßen Cletus Afrifa Donkor Werkstudent Airbus Defence and Space COEED3 Wörthstraße 85 89077 ULM- Germany cletus-afrifa.don...@cassidian.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On Mon, Mar 17, 2014 at 05:52:59PM +0900, Masahiro Yamada wrote:
> In Kconfig, we use "*_defconfig" files for board configuration.
>
> In Linux Kernel, they are located under arch/${ARCH}/configs/ directory.
> It works in Linux Kernel because ARCH is always given from the
> command line for cross compile.
>
> But in U-Boot, ARCH is not given from the command line.
> Which means we cannot know ARCH before the board configuration.
> That is why "*_defconfig" files over all architectures should be
> moved into one directory ./configs/.
> (The problem is configs/ directory contains more than 1200 files!)
>
> Besides, we must configure boards for SPL and TPL too
> if they are supported.
> For those boards, defconfig files with the same name are placed
> in spl/configs/, tpl/configs/ directories.
>
> Signed-off-by: Masahiro Yamada
So, what this series is doing, roughly, is turning just the boards.cfg
entry into a small Kconfig snippet, and saying we'll keep using
include/configs/foo.h for most of the work. This is just the first step
in moving away from include/configs/foo.h eventually, yes?
--
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] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
2014-03-19 11:51 GMT+01:00 Masahiro Yamada : > Hi Wolfgang, > > > On Wed, 19 Mar 2014 10:56:46 +0100 > Wolfgang Denk wrote: > >> Dear Masahiro, >> >> In message <20140319135026.7a64.aa925...@jp.panasonic.com> you wrote: >> > >> > > >>> +++ b/configs/beaver_defconfig >> > > >>> @@ -0,0 +1,10 @@ >> > > >>> +CONFIG_SPL=y >> > > >>> +CONFIG_ARM=y >> > > >>> +CONFIG_SYS_CPU="armv7" >> > > >>> +CONFIG_SOC_DIR=y >> > > >>> +CONFIG_SYS_SOC="tegra30" >> > > >>> +CONFIG_SYS_BOARD="beaver" >> > > >>> +CONFIG_VENDOR_DIR=y >> > > >>> +CONFIG_SYS_VENDOR="nvidia" >> > > >>> +CONFIG_SYS_CONFIG_NAME="beaver" >> > > >>> +CONFIG_BOARD_MAINTAINER="Tom Warren :Stephen >> > > >>> Warren " >> > > >> >> > > >> This is odd; defconfig in the Linux kernel is for defining values for >> > > >> user-editable configuration options. However, at least >> > > >> CONFIG_BOARD_MAINTAINERS is a property of the board port, not >> > > >> something >> > > >> the a user should be editing. >> > > > >> > > > In U-Boot, each board and its maintainer are tightly coupled. >> > > > So, Albert chose to merge boards.cfg and MAINTAINERS in commit >> > > > 27af930e9a. maybe we should import get_maintainers.pl from kernel and readd MAINTAINERS in the according format. So we could easily maintain infos about board maintainers, custodians, custodian trees and maintaining status per arch, CPU, SOC, drivers and boards in one place. Currently that is not possible because one has to look into different sources (boards.cfg, README's, U-Boot Wiki, git history, source file) to get those infos. >> > > >> > > I think you're completely missing my point. None of the information >> > > contained in the defconfig files you posted is even *remotely* related >> > > to what a defconfig file is. defconfig is for user-configurable >> > > configuration of the software, not for core values that must be set up >> > > in a certain way for the code to compile or work. >> > >> > Right. >> > None of settings in Kconfig in this series is not user-editable. >> > "make randconfig" or "make allyesconfig" will not work at all. >> >> I'm not sure if I understand your double negation here correctly. >> Avoiding the double negation, you state that ALL values in this >> defconfig are user-editable. > > Oops, sorry. > What I wanted to say is: > None of settings in Kconfig in this series is user-editable. > > > >> I fully agree with Stephen that this should not be the case. >> >> I'm afraid we are approaching one of the areas where we run into >> problems if we try to reuse Kconfig as done in Linux, without changes. >> >> As Stephen already explained, we have the situation that there are >> certain settings that are not actually supported to be user-editable. > > If "prompt" is not specified, the entry will not appear on > "make config", "make menuconfig", etc. > > Linux Kernel does this for user-uneditable CONFIG. > > The following is a snippet from arch/arm/Kconfig of Linux Kernel. > > < > config STACKTRACE_SUPPORT > bool > default y > > config HAVE_LATENCYTOP_SUPPORT > bool > depends on !SMP > default y > > config LOCKDEP_SUPPORT > bool > default y > > config TRACE_IRQFLAGS_SUPPORT > bool > default y > > config RWSEM_GENERIC_SPINLOCK > bool > default y >> > > Above are forced to the default value. > We should do this in U-Boot too. agree. But at first we should introduce Kconfig files in all arch, CPU, SOC, SOC common, board vendor, board and driver directories where we put all CONFIG_SYS_ symbols. We also need to convert the current config options for CPU, SOC, vendor and board. For example: CONFIG_SYS_CPU="armv7" CONFIG_SOC_DIR=y CONFIG_SYS_SOC="tegra30" CONFIG_SYS_BOARD="beaver" CONFIG_VENDOR_DIR=y CONFIG_SYS_VENDOR="nvidia" CONFIG_SYS_CONFIG_NAME="beaver" should be converted to something like this: CONFIG_CPU_ARMV7=y CONFIG_SOC_TEGRA30=y CONFIG_VENDOR_NVIDIA=y CONFIG_BOARD_BEAVER=y Then we can use the Kconfig symbol dependencies to create a minimal working board config. For example: board/nvidia/beaver/Kconfig: config BOARD_BEAVER bool "board description" select VENDOR_NVIDIA select SOC_TEGRA30 select SPL ... arch/arm/cpu/armv7/tegra30/Kconfig: config SOC_TEGRA30 bool select ARMV7 ... The beaver_defconfig file could reduced then to "CONFIG_BOARD_BEAVER=y" and some default user-editable options. ideally the current target "make beaver_config" could be implemented as echo "CONFIG_BOARD_BEAVER=y" > .config make oldconfig > > > >> This is OK - the question is, what should it contain. In my opinion, >> we should fiond here the user changable settings (i. e. CONFIG_ >> stuff), but not the "unchangable" things (like CONFIG_SYS_). >> >> Yes, I am aware that there is a lot of incorrectly chosen names, i. e. >> cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this >> adds to the complexity of converting to Kconfig. > > Fo
[U-Boot] Question about mpc85xx startup using Nor Flash
I'm porting u-boot to P2040 based board these days. As u-boot/arch/powerpc/mpc85xx/start.s commented: *The processor starts at 0x_fffc and the code is first executed in the last 4K page in flash/rom.* The E500MCRM Chapter 6.6 mentioned: *This default TLB entry translates the first instruction fetch out of reset(at effective address 0x_fffc).* *This instruction should be a branch to the beginning of this page.* So, if I configure the HCW to let powerpc boot from Nor Flash, why should I suppose that the Nor Flash's last 4K is mapped to 0x_f000~0x_. Since there're no LAW setup yet and the default BR0/OR0 of Local Bus does not match that range. And what is the instruction at 0x_fffc and where is it from? Best Regards, Hook Guo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 4xx: add support for new PMC440 revision
On 19.03.2014 12:44, Stefan Roese wrote:
>> -if (miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
>> -miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x11, 0x0010);
>> -miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x11,
>> val_behavior);
>> -miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x10, val_method);
>> -miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x1f, 0x);
>> -}
>> +if (miiphy_write("ppc_4xx_eth0",
>> + CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
>> +miiphy_write("ppc_4xx_eth0",
>> + CONFIG_PHY_ADDR, 0x11, 0x0010);
>> +miiphy_write("ppc_4xx_eth0",
>> + CONFIG_PHY_ADDR, 0x11, val_behavior);
>> +miiphy_write("ppc_4xx_eth0",
>> + CONFIG_PHY_ADDR, 0x10, val_method);
>> +miiphy_write("ppc_4xx_eth0",
>> + CONFIG_PHY_ADDR, 0x1f, 0x);
>> +}
>>
>> -if (miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
>> -miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x11, 0x0010);
>> -miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x11,
>> val_behavior);
>> -miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x10,
>> val_method);
>> -miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x1f, 0x);
>> +if (miiphy_write("ppc_4xx_eth1",
>> + CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
>> +miiphy_write("ppc_4xx_eth1",
>> + CONFIG_PHY1_ADDR, 0x11, 0x0010);
>> +miiphy_write("ppc_4xx_eth1",
>> + CONFIG_PHY1_ADDR, 0x11, val_behavior);
>> +miiphy_write("ppc_4xx_eth1",
>> + CONFIG_PHY1_ADDR, 0x10, val_method);
>> +miiphy_write("ppc_4xx_eth1",
>> + CONFIG_PHY1_ADDR, 0x1f, 0x);
>> +}
>
> This if () section looks very similar to the one before in this patch.
> Only difference is the string "ppc_4xx_eth1". Can't you move this code
> into a function to reduce the code size?
>
> I know this code duplication was not introduced with this patch. But it
> makes sense to simplify this now for my taste.
You might be right. But I will put it into a separate "refacturing"
patch. Stay tuned.
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 4xx: add support for new PMC440 revision
Hi Matthias,
On 19.03.2014 10:25, Matthias Fuchs wrote:
This patch adds support for the new PMC440 hardware revision 1.4.
The board now uses Micrel KSZ9031 phys.
Add missing i2c initialization before reading bootstrap eeprom.
Signed-off-by: Matthias Fuchs
---
board/esd/pmc440/pmc440.c | 83 +
1 file changed, 62 insertions(+), 21 deletions(-)
diff --git a/board/esd/pmc440/pmc440.c b/board/esd/pmc440/pmc440.c
index e86996c..7aee8e4 100644
--- a/board/esd/pmc440/pmc440.c
+++ b/board/esd/pmc440/pmc440.c
@@ -63,6 +63,8 @@ struct serial_device *default_serial_console(void)
/* mark scratchreg valid */
scratchreg = (scratchreg & 0xff00) | 0x80;
+ i2c_init_all();
+
i = bootstrap_eeprom_read(CONFIG_SYS_I2C_BOOT_EEPROM_ADDR,
0x10, buf, 4);
if ((i != -1) && (buf[0] == 0x19) && (buf[1] == 0x75)) {
@@ -641,34 +643,73 @@ int is_pci_host(struct pci_controller *hose)
#endif /* defined(CONFIG_PCI) */
#ifdef CONFIG_RESET_PHY_R
+int pmc440_setup_ksz9031(char *devname, int phy_addr)
+{
+ unsigned short id1, id2;
+
+ if (miiphy_read(devname, phy_addr, 2, &id1) ||
+ miiphy_read(devname, phy_addr, 3, &id2)) {
+ printf("Phy%d: cannot read id\n", phy_addr);
+ return -1;
+ }
+
+ if ((id1 != 0x0022) || ((id2 & 0xfff0) != 0x1620)) {
+ printf("Phy%d: unexpected id\n", phy_addr);
+ return -1;
+ }
+
+ /* MMD 2.08: adjust tx_clk pad skew */
+ miiphy_write(devname, phy_addr, 0x0d, 2);
+ miiphy_write(devname, phy_addr, 0x0e, 8);
+ miiphy_write(devname, phy_addr, 0x0d, 0x4002);
+ miiphy_write(devname, phy_addr, 0x0e, 0xf | (0x17 << 5));
+
+ return 0;
+}
void reset_phy(void)
{
char *s;
unsigned short val_method, val_behavior;
- /* special LED setup for NGCC/CANDES */
- if ((s = getenv("bd_type")) &&
- ((!strcmp(s, "ngcc")) || (!strcmp(s, "candes" {
- val_method = 0x0e0a;
- val_behavior = 0x0cf2;
- } else {
- /* PMC440 standard type */
- val_method = 0x0e10;
- val_behavior = 0x0cf0;
- }
+ if (gd->board_type < 4) {
+ /* special LED setup for NGCC/CANDES */
+ s = getenv("bd_type");
+ if (s && ((!strcmp(s, "ngcc")) || (!strcmp(s, "candes" {
+ val_method = 0x0e0a;
+ val_behavior = 0x0cf2;
+ } else {
+ /* PMC440 standard type */
+ val_method = 0x0e10;
+ val_behavior = 0x0cf0;
+ }
- if (miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x11, 0x0010);
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x11,
val_behavior);
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x10, val_method);
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x1f, 0x);
- }
+ if (miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x11, 0x0010);
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x11, val_behavior);
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x10, val_method);
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x1f, 0x);
+ }
- if (miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x11, 0x0010);
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x11,
val_behavior);
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x10,
val_method);
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x1f, 0x);
+ if (miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x11, 0x0010);
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x11, val_behavior);
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x10, val_method);
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x1f, 0x);
+ }
This if () section looks very similar to the one before in this patch.
Only diff
Re: [U-Boot] [PATCH v6] nand/denali: Adding Denali NAND driver support
Hi Chin,
> --- /dev/null
> +++ b/drivers/mtd/nand/denali.c
> @@ -0,0 +1,1132 @@
> +/*
> + * Copyright (C) 2013-2014 Altera Corporation
> + * Copyright (C) 2009-2010, Intel Corporation and its suppliers.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
If you don't mind, is it OK to add the creadit of Panasonic?
Going forward, Altera and Panasonic will share this driver
and I am contributing on code improvement and run test.
(I will post Panasonic boards support code after
this driver is merged.)
> +/* setups the HW to perform the data DMA */
> +static void denali_setup_dma(int op)
> +{
I sent a question to Cadence again and
finally received an answer I had wanted.
They said DMA command sequence depends on the bus width.
Panasonic bought 64bit bus version.
I guess Altera bought 32bit bus version.
So I'd like to suggest to use #ifdef CONFIG_NAND_DENALI_64BIT
here.
> +/*
> + * Although controller spec said SLC ECC is forceb to be 4bit, but denali
> + * controller in MRST only support 15bit and 8bit ECC correction
> + */
> +#ifdef CONFIG_SYS_NAND_15BIT_HW_ECC_OOBFIRST
> +#define ECC_15BITS 26
> +static struct nand_ecclayout nand_15bit_oob = {
> + .eccbytes = ECC_15BITS,
> +};
> +#else
> +#define ECC_8BITS14
> +static struct nand_ecclayout nand_8bit_oob = {
> + .eccbytes = ECC_8BITS,
> +};
I think supporting only 15bit, 8bit is odd.
The number of ECC bits depends on the hardware.
(You can choose ECC bits you like when you buy the IP
from Cadence.)
I'd like to suggest to re-write this part in a generic way
by using the formula given in Denali's document.
if (ecc.size == 512)
ecc.bytes = Ceiling_to_next_word(ecc.strength * 13)
if (ecc.size == 1024)
ecc.bytes = Ceiling_to_next_word(ecc.strength * 14)
> + nand->ecc.mode = NAND_ECC_HW;
> + nand->ecc.size = CONFIG_NAND_DENALI_ECC_SIZE;
> + nand->ecc.read_oob = denali_read_oob;
> + nand->ecc.write_oob = denali_write_oob;
> + nand->ecc.read_page = denali_read_page;
> + nand->ecc.read_page_raw = denali_read_page_raw;
> + nand->ecc.write_page = denali_write_page;
> + nand->ecc.write_page_raw = denali_write_page_raw;
> +#ifdef CONFIG_SYS_NAND_15BIT_HW_ECC_OOBFIRST
> + /* 15bit ECC */
> + nand->ecc.bytes = 26;
> + nand->ecc.layout = &nand_15bit_oob;
> +#else/* 8bit ECC */
> + nand->ecc.bytes = 14;
> + nand->ecc.layout = &nand_8bit_oob;
> +#endif
> + nand->ecc.calculate = denali_ecc_calculate;
> + nand->ecc.correct = denali_ecc_correct;
> + nand->ecc.hwctl = denali_ecc_hwctl;
denali_ecc_calculate(),
denali_ecc_correct(),
denali_ecc_hwctl()
are never called. Nor do we need to set stub functions.
Besides, ecc.strength must be set.
I guess ECC_CORRECTION register is already set correctly.
(In the case of SOCFPGA, it would be set to 8.)
So, ecc.strength should be set to the value of ECC_CORRECTION.
> +
> +typedef int irqreturn_t;
> +
> +#define IRQ_HANDLED 1
> +#define IRQ_NONE 0
These typedef and macros are not used.
denali.h in Linux Kernel does not have them either.
Please delete.
> +#define SUPPORT_15BITECC1
> +#define SUPPORT_8BITECC 1
These are no longer necessary.
> +#define DENALI_BUF_SIZE (NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE)
NAND_MAX_PAGESIZE and NAND_MAX_OOBSIZE are defined in
include/linux/mtd/nand.h
So, denali.h must include it.
Code diff is as follows:
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index fce1b62..8ba8f04 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2013-2014 Altera Corporation
+ * Copyright (C) 2014 Panasonic Corporation
+ * Copyright (C) 2013-2014 Altera Corporation
* Copyright (C) 2009-2010, Intel Corporation and its suppliers.
*
* SPDX-License-Identifier:GPL-2.0+
@@ -660,6 +661,21 @@ static void denali_setup_dma(int op)
flush_dcache_range(addr, addr + sizeof(denali.buf.dma_buf));
+#ifdef CONFIG_NAND_DENALI_64BIT
+ mode = MODE_10 | BANK(denali.flash_bank) | denali.page;
+
+ /* DMA is a three step process */
+
+ /* 1. setup transfer type, interrupt when complete,
+ burst len = 64 bytes, the number of pages */
+ index_addr(mode, 0x01002000 | (64 << 16) | op | page_count);
+
+ /* 2. set memory low address bits 31:0 */
+ index_addr(mode, addr);
+
+ /* 3. set memory high address bits 64:32 */
+ index_addr(mode, 0);
+#else
mode = MODE_10 | BANK(denali.flash_bank);
/* DMA is a four step process */
@@ -675,6 +691,7 @@ static void denali_setup_dma(int op)
/* 4. interrupt when complete, burst len = 64 bytes*/
index_addr(mode | 0x14000, 0x2400);
+#endif
}
/* Common DMA function */
@@ -1017,26 +1034,6 @@ static void denali_cmdfunc(struct mtd_info *mtd,
unsigned int cmd, int col,
break;
}
}
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Wolfgang, On Wed, 19 Mar 2014 10:56:46 +0100 Wolfgang Denk wrote: > Dear Masahiro, > > In message <20140319135026.7a64.aa925...@jp.panasonic.com> you wrote: > > > > > >>> +++ b/configs/beaver_defconfig > > > >>> @@ -0,0 +1,10 @@ > > > >>> +CONFIG_SPL=y > > > >>> +CONFIG_ARM=y > > > >>> +CONFIG_SYS_CPU="armv7" > > > >>> +CONFIG_SOC_DIR=y > > > >>> +CONFIG_SYS_SOC="tegra30" > > > >>> +CONFIG_SYS_BOARD="beaver" > > > >>> +CONFIG_VENDOR_DIR=y > > > >>> +CONFIG_SYS_VENDOR="nvidia" > > > >>> +CONFIG_SYS_CONFIG_NAME="beaver" > > > >>> +CONFIG_BOARD_MAINTAINER="Tom Warren :Stephen > > > >>> Warren " > > > >> > > > >> This is odd; defconfig in the Linux kernel is for defining values for > > > >> user-editable configuration options. However, at least > > > >> CONFIG_BOARD_MAINTAINERS is a property of the board port, not something > > > >> the a user should be editing. > > > > > > > > In U-Boot, each board and its maintainer are tightly coupled. > > > > So, Albert chose to merge boards.cfg and MAINTAINERS in commit > > > > 27af930e9a. > > > > > > I think you're completely missing my point. None of the information > > > contained in the defconfig files you posted is even *remotely* related > > > to what a defconfig file is. defconfig is for user-configurable > > > configuration of the software, not for core values that must be set up > > > in a certain way for the code to compile or work. > > > > Right. > > None of settings in Kconfig in this series is not user-editable. > > "make randconfig" or "make allyesconfig" will not work at all. > > I'm not sure if I understand your double negation here correctly. > Avoiding the double negation, you state that ALL values in this > defconfig are user-editable. Oops, sorry. What I wanted to say is: None of settings in Kconfig in this series is user-editable. > I fully agree with Stephen that this should not be the case. > > I'm afraid we are approaching one of the areas where we run into > problems if we try to reuse Kconfig as done in Linux, without changes. > > As Stephen already explained, we have the situation that there are > certain settings that are not actually supported to be user-editable. If "prompt" is not specified, the entry will not appear on "make config", "make menuconfig", etc. Linux Kernel does this for user-uneditable CONFIG. The following is a snippet from arch/arm/Kconfig of Linux Kernel. < config STACKTRACE_SUPPORT bool default y config HAVE_LATENCYTOP_SUPPORT bool depends on !SMP default y config LOCKDEP_SUPPORT bool default y config TRACE_IRQFLAGS_SUPPORT bool default y config RWSEM_GENERIC_SPINLOCK bool default y > Above are forced to the default value. We should do this in U-Boot too. > This is OK - the question is, what should it contain. In my opinion, > we should fiond here the user changable settings (i. e. CONFIG_ > stuff), but not the "unchangable" things (like CONFIG_SYS_). > > Yes, I am aware that there is a lot of incorrectly chosen names, i. e. > cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this > adds to the complexity of converting to Kconfig. For example, CONFIG_SYS_PROMPT. > > I believe the right way to reuse the Linux's Kconfig with minimum > > modification. > > Whithout modification, we will probably have to restrict ourself to > the really simple, user-configurable options - i. e. the CONFIG_ set > of options (and even then we will either have to make a number of > exceptions, and/or rename a number of such names, and/or provide in > some cases quite complex dependencies). This is the outcome we have developed. What we should do it to fix them correctly, not to change Kconfig concept. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem on SPL build
On 19/03/14 15:25, hua dillon wrote: > you can use board_init_f from arch/arm/lib/spl.c in SPL > > > 2014-03-19 11:29 GMT+08:00 Simon : > >> Hi, >> >> I'am studying on u-boot, and i am trying to port it on smdkc100. I setup >> cross-compile on ubuntu12.04 and build the u-boot, it works okay. >> But i have a problem on SPL build. >> >> I hope you can help me to solve it, thanks! >> >> problem: >> >> insert file "smdkc100.h" at Line 25 >> #define CONFIG_SPL >> and then >> make distclean >> make smdkc100_config >> make all >> but get error: >> /u-boot-2014.01/arch/arm/lib/crt0.S:74: undefined reference to >> `board_init_f' >> SPL is not supported at smdkc100. You can contribute on this. Patches always welcome. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Dear Masahiro, In message <20140319135026.7a64.aa925...@jp.panasonic.com> you wrote: > > > >>> +++ b/configs/beaver_defconfig > > >>> @@ -0,0 +1,10 @@ > > >>> +CONFIG_SPL=y > > >>> +CONFIG_ARM=y > > >>> +CONFIG_SYS_CPU="armv7" > > >>> +CONFIG_SOC_DIR=y > > >>> +CONFIG_SYS_SOC="tegra30" > > >>> +CONFIG_SYS_BOARD="beaver" > > >>> +CONFIG_VENDOR_DIR=y > > >>> +CONFIG_SYS_VENDOR="nvidia" > > >>> +CONFIG_SYS_CONFIG_NAME="beaver" > > >>> +CONFIG_BOARD_MAINTAINER="Tom Warren :Stephen > > >>> Warren " > > >> > > >> This is odd; defconfig in the Linux kernel is for defining values for > > >> user-editable configuration options. However, at least > > >> CONFIG_BOARD_MAINTAINERS is a property of the board port, not something > > >> the a user should be editing. > > > > > > In U-Boot, each board and its maintainer are tightly coupled. > > > So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. > > > > I think you're completely missing my point. None of the information > > contained in the defconfig files you posted is even *remotely* related > > to what a defconfig file is. defconfig is for user-configurable > > configuration of the software, not for core values that must be set up > > in a certain way for the code to compile or work. > > Right. > None of settings in Kconfig in this series is not user-editable. > "make randconfig" or "make allyesconfig" will not work at all. I'm not sure if I understand your double negation here correctly. Avoiding the double negation, you state that ALL values in this defconfig are user-editable. I fully agree with Stephen that this should not be the case. I'm afraid we are approaching one of the areas where we run into problems if we try to reuse Kconfig as done in Linux, without changes. As Stephen already explained, we have the situation that there are certain settings that are not actually supported to be user-editable. > There is a plan to move user-editable macros to Kconfig. > For example, CONFIG_BAUDRATE. Yes, this is a good example for a setting where the user might want to adjust a setting, and where it is harmless to do so. > Or someone might to disable CONFIG_CMD_* to reduce > the binary size. Agreed, too - a user may want to enable (or disable) a specific set of commands in his configuration - but this is already one of the more complicated cases, as there will be a ton of dependencies you will have to include. On the other hand, a user should probably not be able to change the maintainer name, and similar so for a large number of other values. Following the originally intended logic of the naming scheme, only the CONFIG_ variables should show up here, where CONFIG_SYS_ variables should be not changable like this - or at least require some specific "expert menu" mode. > We definitely need "defconfig". This is OK - the question is, what should it contain. In my opinion, we should fiond here the user changable settings (i. e. CONFIG_ stuff), but not the "unchangable" things (like CONFIG_SYS_). Yes, I am aware that there is a lot of incorrectly chosen names, i. e. cases where CONFIG_ resp. CONFIG_SYS_ are incorrectly assigned - this adds to the complexity of converting to Kconfig. > I believe the right way to reuse the Linux's Kconfig with minimum > modification. Whithout modification, we will probably have to restrict ourself to the really simple, user-configurable options - i. e. the CONFIG_ set of options (and even then we will either have to make a number of exceptions, and/or rename a number of such names, and/or provide in some cases quite complex dependencies). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Anyone can count the seeds in an apple. No one can count the apples in a seed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Hi Lukasz, On Fri, 14 Mar 2014 08:37:00 +0100, Lukasz Majewski wrote: > Hi Albert, > > > Hi Lukasz, > > > > On Thu, 13 Mar 2014 16:43:09 +0100, Lukasz Majewski > > wrote: > > > > > I can report the same issue with OBS build of u-boot. > > > > > > When u-boot is build with qemu emulated environment with gcc-4.8.2 > > > (native armv7l toolchain) in the OBS it needs patch prepared by > > > Andreas. > > > > Hmm, ok, so maybe I can reproduce this by building U-Boot on native > > armv7 hardware. Any target which systematically fails building? > > The Trats2 fails to be build. But to me it seems like compiler and > linker issue. > > > > > > However I can build the same code from u-boot directory (without > > > this patch) with following toolchain: > > > arm-v7a-linux-gnueabi-gcc (OSELAS.Toolchain-2013.12.0 > > > linaro-4.8-2013.11) 4.8.3 2013 > > > > Hmm... So it depends on the toolchain. > > > > > Any ideas how to solve this? > > > > Are both toolchains you used available somewhere so that I can fetch > > them and experiment locally? > > Yes they are available. References below: > > arm-v7a-linux-gnueabi-gcc > (OSELAS.Toolchain-2013.12.0linaro-4.8-2013.11) 4.8.3 2013 > linaro-4.8-2013.11) 4.8.3 2013 > http://www.ptxdist.org/software/ptxdist/index_en.html > > > The one which is used in the OBS: > gcc-4.8-2.56.armv7l.rpm > > can be download from: > http://download.tizen.org/snapshots/tizen/rd-pq/latest/repos/mobile/armv7l/packages/armv7l/ > > I hope, that it helps. Thanks -- I'll test these, not today but certainly before next monday. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 4xx: add support for new PMC440 revision
This patch adds support for the new PMC440 hardware revision 1.4.
The board now uses Micrel KSZ9031 phys.
Add missing i2c initialization before reading bootstrap eeprom.
Signed-off-by: Matthias Fuchs
---
board/esd/pmc440/pmc440.c | 83 +
1 file changed, 62 insertions(+), 21 deletions(-)
diff --git a/board/esd/pmc440/pmc440.c b/board/esd/pmc440/pmc440.c
index e86996c..7aee8e4 100644
--- a/board/esd/pmc440/pmc440.c
+++ b/board/esd/pmc440/pmc440.c
@@ -63,6 +63,8 @@ struct serial_device *default_serial_console(void)
/* mark scratchreg valid */
scratchreg = (scratchreg & 0xff00) | 0x80;
+ i2c_init_all();
+
i = bootstrap_eeprom_read(CONFIG_SYS_I2C_BOOT_EEPROM_ADDR,
0x10, buf, 4);
if ((i != -1) && (buf[0] == 0x19) && (buf[1] == 0x75)) {
@@ -641,34 +643,73 @@ int is_pci_host(struct pci_controller *hose)
#endif /* defined(CONFIG_PCI) */
#ifdef CONFIG_RESET_PHY_R
+int pmc440_setup_ksz9031(char *devname, int phy_addr)
+{
+ unsigned short id1, id2;
+
+ if (miiphy_read(devname, phy_addr, 2, &id1) ||
+ miiphy_read(devname, phy_addr, 3, &id2)) {
+ printf("Phy%d: cannot read id\n", phy_addr);
+ return -1;
+ }
+
+ if ((id1 != 0x0022) || ((id2 & 0xfff0) != 0x1620)) {
+ printf("Phy%d: unexpected id\n", phy_addr);
+ return -1;
+ }
+
+ /* MMD 2.08: adjust tx_clk pad skew */
+ miiphy_write(devname, phy_addr, 0x0d, 2);
+ miiphy_write(devname, phy_addr, 0x0e, 8);
+ miiphy_write(devname, phy_addr, 0x0d, 0x4002);
+ miiphy_write(devname, phy_addr, 0x0e, 0xf | (0x17 << 5));
+
+ return 0;
+}
void reset_phy(void)
{
char *s;
unsigned short val_method, val_behavior;
- /* special LED setup for NGCC/CANDES */
- if ((s = getenv("bd_type")) &&
- ((!strcmp(s, "ngcc")) || (!strcmp(s, "candes" {
- val_method = 0x0e0a;
- val_behavior = 0x0cf2;
- } else {
- /* PMC440 standard type */
- val_method = 0x0e10;
- val_behavior = 0x0cf0;
- }
+ if (gd->board_type < 4) {
+ /* special LED setup for NGCC/CANDES */
+ s = getenv("bd_type");
+ if (s && ((!strcmp(s, "ngcc")) || (!strcmp(s, "candes" {
+ val_method = 0x0e0a;
+ val_behavior = 0x0cf2;
+ } else {
+ /* PMC440 standard type */
+ val_method = 0x0e10;
+ val_behavior = 0x0cf0;
+ }
- if (miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x11, 0x0010);
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x11,
val_behavior);
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x10, val_method);
- miiphy_write("ppc_4xx_eth0", CONFIG_PHY_ADDR, 0x1f, 0x);
- }
+ if (miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x1f, 0x0001) == 0) {
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x11, 0x0010);
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x11, val_behavior);
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x10, val_method);
+ miiphy_write("ppc_4xx_eth0",
+CONFIG_PHY_ADDR, 0x1f, 0x);
+ }
- if (miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x11, 0x0010);
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x11,
val_behavior);
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x10,
val_method);
- miiphy_write("ppc_4xx_eth1", CONFIG_PHY1_ADDR, 0x1f, 0x);
+ if (miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x1f, 0x0001) == 0) {
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x11, 0x0010);
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x11, val_behavior);
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x10, val_method);
+ miiphy_write("ppc_4xx_eth1",
+CONFIG_PHY1_ADDR, 0x1f, 0x);
+ }
+ } else {
+ /* rev. 1.4 uses a Micrel KSZ9031 */
+ pmc440_setup_ksz9031("ppc_4xx_eth0", CONFIG_PHY_ADDR);
+
[U-Boot] [PATCH] common, env: Fix support for environment in i2c eeprom
When using CONFIG_SYS_I2C i2c needs to be initialized by i2c_init_all(). This is done in some places but not in eeprom_init(). Signed-off-by: Matthias Fuchs --- common/cmd_eeprom.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index 3924805..fad462f 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -389,8 +389,13 @@ void eeprom_init (void) #if defined(CONFIG_SPI) && !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_init_f (); #endif -#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) - i2c_init (CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); +#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SYS_I2C_SOFT) || \ + defined(CONFIG_SYS_I2C) +#ifdef CONFIG_SYS_I2C + i2c_init_all(); +#else + i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); +#endif #endif } -- 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] build:arm: Remove setting of CROSS_COMPILE environment variable
Hi Masahiro,
> Hi Lukasz, Tom,
>
>
> > Hi Tom,
> >
> > > On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski wrote:
> > >
> > > > After Kbuild introduction, the CROSS_COMPILE environment
> > > > variable has been set to some default value (prefix arm-linux-).
> > >
> > > Note that this is quite a long-standing thing. Perhaps we're now
> > > not detecting a native build when we used to?
> >
> > My point is that we are relying on assigning default prefix (i.e.
> > arm-linux-)
> >
> > For example OSELAS toolchains can have an arbitrary prefix
> > (e.g. arm-linux-gnueabi-).
> >
> > When I cross compile I set explicitly "CROSS_COMPILE=
> > make" and it works as it should (with or without this patch). Such
> > approach seems natural for me.
> >
> > However, I don't know what is the exact rationale for seting this
> > arm-linux- prefix to CROSS_COMPILE.
> > I can only guess, that it is connected with situation when one just
> > type "make" on x86_64 host and expect u-boot to be CROSS_COMPILE'd
> > out of the box.
>
> Agree.
> It is useful only for people using "arm-linux-gcc" on x86 host.
> I usually use "arm-linux-gnueabi-gcc". Someone else may be using other
> prefixes.
>
> I think there is no rationale more sophisticated than that it just has
> been there since long time before.
>
> So, I agree with this patch except a little misleading
> commit description I commented below.
>
> Acked-by: Masahiro Yamada
>
Thanks for review.
>
>
> > Unfortunately this doesn't work with ARM host emulated with qemu
> > (like OBS). Here when I type "make" I expect that "native" gcc for
> > arm will run without even touching CROSS_COMPILE environment
> > variable.
>
> I believe it is the same as prior to Kbuild.
>
> So, I am not convined with this part of your commit description:
> > After Kbuild introduction, the CROSS_COMPILE environment variable
> > has been set to some default value (prefix arm-linux-).
>
>
> > Any idea how to fix this is more than welcome.
>
> If you are searching some other choices,
>
>
> [1]
> ifneq ("$(origin CROSS_COMPILE)", "command line")
> ifeq ($(CROSS_COMPILE),)
> CROSS_COMPILE := arm-linux-
> endif
> endif
>
> For native build on ARM, you can explicitely set CROSS_COMPILE as
> empty:"make CROSS_COMPILE="
> In this case, CROSS_COMPILE will not be overwritten in
> arch/arm/config.mk.
>
>
> [2]
> ifneq ($(HOSTARCH),$(ARCH))
> ifeq ($(CROSS_COMPILE),)
> CROSS_COMPILE := arm-linux-
> endif
> endif
>
> For native build on ARM, both $(HOSTARCH) and $(ARCH)
> are "arm", so CROSS_COMPILE will not be set.
>
>
>
> But, I think deleting CROSS_COMPILE setting is the simplest and the
> best.
Ok, lets stick to this solution.
>
>
> Best Regards
> Masahiro Yamada
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
