[U-Boot] [U-boot] CONFIG_FIT and CONFIG_OF_LIBFDT
Hi, experts: I have a question about supporting FDT in uboot. 1. If i want to provide FDT support function in uboot code, just need to : Define CONFIG_OF_LIBFDT in vendor_config.h If my uImage is still a single component image, not need to define CONFIG_FIT at the same time? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtd: atmel_nand: pmecc: fix bug fail to correct bit error in 1024-bytes sector
The PMECC use BCH algorithm to correct error. In BCH algorithm, the
primitive polynomial value is GF(2^13) for 512-bytes sector size. And it is
GF(2^14) for 1024-bytes sector size.
This patch will choose correct degree of the remainders(13 or 14) for
different sector size.
Tested in AT91SAM9X5-EK with MLC nand flash.
More detail can be refered to section 5.4.1 of:
AT91SAM ARM-based Embedded MPU Application Note
http://www.atmel.com/Images/doc11127.pdf
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/mtd/nand/atmel_nand.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 96aca00..da83f06 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -827,7 +827,8 @@ static int atmel_pmecc_nand_init_params(struct nand_chip
*nand,
switch (mtd-writesize) {
case 2048:
case 4096:
- host-pmecc_degree = PMECC_GF_DIMENSION_13;
+ host-pmecc_degree = (sector_size == 512) ?
+ PMECC_GF_DIMENSION_13 : PMECC_GF_DIMENSION_14;
host-pmecc_cw_len = (1 host-pmecc_degree) - 1;
host-pmecc_sector_number = mtd-writesize / sector_size;
host-pmecc_bytes_per_sector = pmecc_get_ecc_bytes(
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c: fix i2c dev command for not using new framework
From: Heiko Schocher h...@denx.de
i2c dev command does not work anymore for legacy drivers
because a check is executed that is valid only
in the new framework.
Signed-off-by: Heiko Schocher h...@denx.de
Tested-by: Stefano Babic sba...@denx.de
---
common/cmd_i2c.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 29f5181..ebce7d4 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -1438,10 +1438,12 @@ int do_i2c_bus_num(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
printf(Current bus is %d\n, i2c_get_bus_num());
else {
bus_no = simple_strtoul(argv[1], NULL, 10);
+#if defined(CONFIG_SYS_I2C)
if (bus_no = CONFIG_SYS_NUM_I2C_BUSES) {
printf(Invalid bus %d\n, bus_no);
return -1;
}
+#endif
printf(Setting bus to %d\n, bus_no);
ret = i2c_set_bus_num(bus_no);
if (ret)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Failing USB devices
Hello, I'm unable to use some mass storage devices with the current git version (6612ab33956ae09c5ba2fde9c1540b519625ba37) of UBoot on a TI Davinci custom board. I have 7 pen drives, and 2 of them fail. I-O DATA USB Flash Disk (0x04bb/0x0c43) ... 2 USB Device(s) found scan end scanning usb for storage devices... i=0 i=1 USB Mass Storage device detected Transport: Bulk/Bulk/Bulk Endpoints In 1 Out 2 Int 0 usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 length 0x1 Get Max LUN - len = 1, result = 0 address 2 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 error in inquiry i=2 0 Storage Device(s) found In this case putting a delay of 1000ms in usb_stor_BBB_transport between the COMMAND and DATA phase, (in place of the conditional 5ms USB_READY delay), overcomes this issue. It seems this 1000ms delay is only required for the first COMMAND, subsequent COMMAND phases seem happy with the 5ms delay. Lexar JumpDrive 32GB (0x0424/0x2507): DM36x EVM # usb start (Re)start USB... USB0: scanning bus 0 for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x29 get_conf_no 0 Result 41, wLength 41 if 0, ep 0 if 0, ep 1 ##EP epmaxpacketin[1] = 1 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=0, Product=0, SerialNumber=0 Manufacturer Product SerialNumber USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x9 7 ports detected ganged power switching part of a compound device global over-current protection power on to power good time: 100ms hub controller current requirement: 1mA port 1 is not removable port 2 is not removable port 3 is not removable port 4 is removable port 5 is removable port 6 is removable port 7 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 0, change 0 local power source is good no over-current condition exists enabling power on all ports usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x3 length 0x0 port 3 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x4 length 0x0 port 4 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x5 length 0x0 port 5 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x6 length 0x0 port 6 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x7 length 0x0 port 7 returns 0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x6 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x7 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3 length 0x0 port 3 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x4 length 0x0 port 4 returns 0 usb_control_msg: request: 0x3,
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
On 30/07/13 06:18, Lokesh Vutla wrote:
From: Heiko Schocher h...@denx.de
s_init has the same outline for all the AM33xx based
board. So making it generic.
This also helps in addition of new Soc with minimal changes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Tom Rini tr...@ti.com
snip
This patch introduces the following new function call ...
+void s_init(void)
+{
+ /*
+ * The ROM will only have set up sufficient pinmux to allow for the
+ * first 4KiB NOR to be read, we must finish doing what we know of
+ * the NOR mux in this space in order to continue.
+ */
+#ifdef CONFIG_NOR_BOOT
+ enable_norboot_pin_mux();
+#endif
... which replaces the old code ...
- /*
- * The ROM will only have set up sufficient pinmux to allow for the
- * first 4KiB NOR to be read, we must finish doing what we know of
- * the NOR mux in this space in order to continue.
- */
-#ifdef CONFIG_NOR_BOOT
- asm(stmfd sp!, {r2 - r4});
- asm(movw r4, #0x8A4);
- asm(movw r3, #0x44E1);
- asm(orrr4, r4, r3, lsl #16);
- asm(movr2, #9);
- asm(movr3, #8);
- asm(gpmc_mux: str r2, [r4], #4);
- asm(subs r3, r3, #1);
- asm(bnegpmc_mux);
- asm(ldmfd sp!, {r2 - r4});
-#endif
Now (for the TI boards) enable_norboot_pin_mux() is defined as:-
+#if defined(CONFIG_NOR_BOOT)
+static struct module_pin_mux norboot_pin_mux[] = {
+ {OFFSET(lcd_data1), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data2), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data3), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data4), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data5), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data6), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data7), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data8), MODE(1) | PULLUDDIS},
+ {OFFSET(lcd_data9), MODE(1) | PULLUDDIS},
+ {-1},
+};
+
+void enable_norboot_pin_mux(void)
+{
+ configure_module_pin_mux(norboot_pin_mux);
+}
+#endif
Firstly, this pinmux code seems wrong, since lcd_data pin map:-
lcd_data1 (mode 1) = gpmc_a1_mux1
lcd_data2 (mode 1) = gpmc_a2_mux1
lcd_data3 (mode 1) = gpmc_a3_mux1
lcd_data4 (mode 1) = gpmc_a4_mux1
lcd_data5 (mode 1) = gpmc_a5_mux1
lcd_data6 (mode 1) = gpmc_a6_mux1
lcd_data7 (mode 1) = gpmc_a7_mux1
lcd_data8 (mode 1) = gpmc_a12_mux1
lcd_data9 (mode 1) = gpmc_a13_mux1
Doesn't this leave gpmc_a[8..11] unconfigured ?
Shouldn't we configure lcd_vsync, lcd_hsync and lcd_pclk ?
Secondly, I've modded our Nanobone code to match this new setup, as follows:-
static struct module_pin_mux norboot_pin_mux[] = {
{OFFSET(lcd_data1), (MODE(1) | PULLUDDIS)}, /* GPMC A17 */
{OFFSET(lcd_data2), (MODE(1) | PULLUDDIS)}, /* GPMC A18 */
{OFFSET(lcd_data3), (MODE(1) | PULLUDDIS)}, /* GPMC A19 */
{OFFSET(lcd_data4), (MODE(1) | PULLUDDIS)}, /* GPMC A20 */
{OFFSET(lcd_data5), (MODE(1) | PULLUDDIS)}, /* GPMC A21 */
{OFFSET(lcd_data6), (MODE(1) | PULLUDDIS)}, /* GPMC A22 */
{OFFSET(lcd_data7), (MODE(1) | PULLUDDIS)}, /* GPMC A23 */
{OFFSET(lcd_vsync), (MODE(1) | PULLUDDIS)}, /* GPMC A24 */
{OFFSET(lcd_hsync), (MODE(1) | PULLUDDIS)}, /* GPMC A25 */
{OFFSET(lcd_pclk), (MODE(1) | PULLUDDIS)}, /* GPMC A26 */
{-1},
};
void enable_norboot_pin_mux(void)
{
configure_module_pin_mux(norboot_pin_mux);
}
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
}
... this now boots correctly !!
Anyone care to comment ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
On Thu, 18 Jul 2013 13:30:55 -0400 Michael Cashwell mboa...@prograde.net wrote, On Jul 18, 2013, at 12:39 PM, Tom Rini tr...@ti.com wrote: uImage | raw | nand | 0 | kernel | - | - | - | Since partitions provide start/size. Hi Michael, I've got some WIP that pulls the alt info from a GPT partition map on mmc. That alt settings in DFU can be strings or numbers was handy to allow the name to identify the partition. Will you be ready to show the mentioned patch in a near future? -Mike -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
Hi Mark,
On Friday 23 August 2013 02:58 PM, Mark Jackson wrote:
On 30/07/13 06:18, Lokesh Vutla wrote:
From: Heiko Schocher h...@denx.de
s_init has the same outline for all the AM33xx based
board. So making it generic.
This also helps in addition of new Soc with minimal changes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Tom Rini tr...@ti.com
snip
This patch introduces the following new function call ...
+void s_init(void)
+{
+/*
+ * The ROM will only have set up sufficient pinmux to allow for the
+ * first 4KiB NOR to be read, we must finish doing what we know of
+ * the NOR mux in this space in order to continue.
+ */
+#ifdef CONFIG_NOR_BOOT
+enable_norboot_pin_mux();
+#endif
... which replaces the old code ...
-/*
- * The ROM will only have set up sufficient pinmux to allow for the
- * first 4KiB NOR to be read, we must finish doing what we know of
- * the NOR mux in this space in order to continue.
- */
-#ifdef CONFIG_NOR_BOOT
-asm(stmfd sp!, {r2 - r4});
-asm(movw r4, #0x8A4);
-asm(movw r3, #0x44E1);
-asm(orrr4, r4, r3, lsl #16);
-asm(movr2, #9);
-asm(movr3, #8);
-asm(gpmc_mux: str r2, [r4], #4);
-asm(subs r3, r3, #1);
-asm(bnegpmc_mux);
-asm(ldmfd sp!, {r2 - r4});
-#endif
Now (for the TI boards) enable_norboot_pin_mux() is defined as:-
+#if defined(CONFIG_NOR_BOOT)
+static struct module_pin_mux norboot_pin_mux[] = {
+{OFFSET(lcd_data1), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data2), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data3), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data4), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data5), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data6), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data7), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data8), MODE(1) | PULLUDDIS},
+{OFFSET(lcd_data9), MODE(1) | PULLUDDIS},
+{-1},
+};
Is this configuration not working for you?
+
+void enable_norboot_pin_mux(void)
+{
+configure_module_pin_mux(norboot_pin_mux);
+}
+#endif
Firstly, this pinmux code seems wrong, since lcd_data pin map:-
lcd_data1 (mode 1) = gpmc_a1_mux1
lcd_data2 (mode 1) = gpmc_a2_mux1
lcd_data3 (mode 1) = gpmc_a3_mux1
lcd_data4 (mode 1) = gpmc_a4_mux1
lcd_data5 (mode 1) = gpmc_a5_mux1
lcd_data6 (mode 1) = gpmc_a6_mux1
lcd_data7 (mode 1) = gpmc_a7_mux1
lcd_data8 (mode 1) = gpmc_a12_mux1
lcd_data9 (mode 1) = gpmc_a13_mux1
Doesn't this leave gpmc_a[8..11] unconfigured ?
Shouldn't we configure lcd_vsync, lcd_hsync and lcd_pclk ?
Secondly, I've modded our Nanobone code to match this new setup, as follows:-
static struct module_pin_mux norboot_pin_mux[] = {
{OFFSET(lcd_data1), (MODE(1) | PULLUDDIS)}, /* GPMC A17 */
{OFFSET(lcd_data2), (MODE(1) | PULLUDDIS)}, /* GPMC A18 */
{OFFSET(lcd_data3), (MODE(1) | PULLUDDIS)}, /* GPMC A19 */
{OFFSET(lcd_data4), (MODE(1) | PULLUDDIS)}, /* GPMC A20 */
{OFFSET(lcd_data5), (MODE(1) | PULLUDDIS)}, /* GPMC A21 */
{OFFSET(lcd_data6), (MODE(1) | PULLUDDIS)}, /* GPMC A22 */
{OFFSET(lcd_data7), (MODE(1) | PULLUDDIS)}, /* GPMC A23 */
{OFFSET(lcd_vsync), (MODE(1) | PULLUDDIS)}, /* GPMC A24 */
{OFFSET(lcd_hsync), (MODE(1) | PULLUDDIS)}, /* GPMC A25 */
{OFFSET(lcd_pclk), (MODE(1) | PULLUDDIS)}, /* GPMC A26 */
{-1},
};
void enable_norboot_pin_mux(void)
{
configure_module_pin_mux(norboot_pin_mux);
}
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
}
This code writes 0x9 into 8 continuous registers starting from
0x44e108a4, this is what done in module_pin_mux norboot_pin_mux
except that it has 9 registers(i guess 9th register was added by mistake..:( )
Correct me if I am wrong.
So you are telling this is wrong but boots properly ?
Steve in CC can comment more on this configuration.
Thanks and regards,
Lokesh
... this now boots correctly !!
Anyone care to comment ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
On 23/08/13 11:25, Lokesh Vutla wrote:
Hi Mark,
On Friday 23 August 2013 02:58 PM, Mark Jackson wrote:
On 30/07/13 06:18, Lokesh Vutla wrote:
From: Heiko Schocher h...@denx.de
s_init has the same outline for all the AM33xx based
board. So making it generic.
This also helps in addition of new Soc with minimal changes.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Tom Rini tr...@ti.com
snip
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm(stmfd sp!, {r2 - r4});
asm(movw r4, #0x8A4);
asm(movw r3, #0x44E1);
asm(orrr4, r4, r3, lsl #16);
asm(movr2, #9);
asm(movr3, #8);
asm(gpmc_mux: str r2, [r4], #4);
asm(subs r3, r3, #1);
asm(bnegpmc_mux);
asm(ldmfd sp!, {r2 - r4});
}
This code writes 0x9 into 8 continuous registers starting from
0x44e108a4, this is what done in module_pin_mux norboot_pin_mux
except that it has 9 registers(i guess 9th register was added by mistake..:( )
Correct me if I am wrong.
Not sure about the code, but it was introduced here:-
http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=c5c7a7c32d552592ac49749e5c184c89bd50c098
So you are telling this is wrong but boots properly ?
Basically ... yes !!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Failing USB devices
Dear Marek, Andrew, On Friday, August 23, 2013 5:23:14 AM, Marek Vasut wrote: Dear Andrew Murray, Hello, I'm unable to use some mass storage devices with the current git version (6612ab33956ae09c5ba2fde9c1540b519625ba37) of UBoot on a TI Davinci custom board. I have 7 pen drives, and 2 of them fail. I-O DATA USB Flash Disk (0x04bb/0x0c43) ... 2 USB Device(s) found scan end scanning usb for storage devices... i=0 i=1 USB Mass Storage device detected Transport: Bulk/Bulk/Bulk Endpoints In 1 Out 2 Int 0 usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 length 0x1 Get Max LUN - len = 1, result = 0 address 2 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 error in inquiry i=2 0 Storage Device(s) found In this case putting a delay of 1000ms in usb_stor_BBB_transport between the COMMAND and DATA phase, (in place of the conditional 5ms USB_READY delay), overcomes this issue. It seems this 1000ms delay is only required for the first COMMAND, subsequent COMMAND phases seem happy with the 5ms delay. Lexar JumpDrive 32GB (0x0424/0x2507): So the device takes too long to init itself after powering up the port. It would be nice if you could check the spec and see if there is a way to query the device for ready condition. Although I remember we already do that. This is the kind of issue that made me create this (discarded) patch at some point: http://patchwork.ozlabs.org/patch/176527/ Can you try it? I'm not sure that it will be helpful for your specific case. I also have this issue with some devices and mainline U-Boot. I can confirm that this is a device initialization delay issue because subsequent USB commands on the device succeed (only the single automatic U-Boot USB command that I use at boot time fails). Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] CONFIG_OF_EMBED question
Hi, experts: If i defined CONFIG_OF_EMBED, then: Where could i find _binary_dt_dtb_start's definition? In arch/arm/lib/board.c: gd-fdt_blob = _binary_dt_dtb_start; but i could not find _binary_dt_dtb_start's definition. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: DRA7: Enable saveenv command
dra7xx_evm has eMMC and the default environment can be stored in it. So enabling saveenv command and the configs to store environment in eMMC. Tested on DRA752 ES1.0 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- include/configs/dra7xx_evm.h |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index 58786ff..6b1a0cb 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -14,7 +14,13 @@ #define CONFIG_DRA7XX -#define CONFIG_ENV_IS_NOWHERE /* For now. */ +/* MMC ENV related defines */ +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */ +#define CONFIG_ENV_OFFSET 0xE +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT +#define CONFIG_CMD_SAVEENV #define CONSOLEDEV ttyO0 #define CONFIG_CONS_INDEX 1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: Avoid writing into LDO SRAM bits
Writing magic bits into LDO SRAM was suggested only for OMAP5432
ES1.0. Now these are no longer applicable. Moreover these bits should
not be overwritten as they are loaded from EFUSE. So avoid
writing into these registers.
Boot tested on OMAP5432 ES2.0
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |7 ---
arch/arm/cpu/armv7/omap5/prcm-regs.c | 12
arch/arm/include/asm/omap_common.h |6 --
3 files changed, 25 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 7580594..ab0c568 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -589,13 +589,6 @@ void scale_vcores(struct vcores_data const *vcores)
val = optimize_vcore_voltage(vcores-iva);
do_scale_vcore(vcores-iva.addr, val, vcores-iva.pmic);
-
-if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
- /* Configure LDO SRAM magic bits */
- writel(2, (*prcm)-prm_sldo_core_setup);
- writel(2, (*prcm)-prm_sldo_mpu_setup);
- writel(2, (*prcm)-prm_sldo_mm_setup);
- }
}
static inline void enable_clock_domain(u32 const clkctrl_reg, u32 enable_mode)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 579818d..5a3d52c 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -286,12 +286,6 @@ struct prcm_regs const omap5_es1_prcm = {
.prm_vc_val_bypass = 0x4ae07ba0,
.prm_vc_cfg_i2c_mode = 0x4ae07bb4,
.prm_vc_cfg_i2c_clk = 0x4ae07bb8,
- .prm_sldo_core_setup = 0x4ae07bc4,
- .prm_sldo_core_ctrl = 0x4ae07bc8,
- .prm_sldo_mpu_setup = 0x4ae07bcc,
- .prm_sldo_mpu_ctrl = 0x4ae07bd0,
- .prm_sldo_mm_setup = 0x4ae07bd4,
- .prm_sldo_mm_ctrl = 0x4ae07bd8,
/* SCRM stuff, used by some boards */
.scrm_auxclk0 = 0x4ae0a310,
@@ -735,12 +729,6 @@ struct prcm_regs const omap5_es2_prcm = {
.prm_vc_cfg_i2c_mode = 0x4ae07cb4,
.prm_vc_cfg_i2c_clk = 0x4ae07cb8,
- .prm_sldo_core_setup = 0x4ae07cc4,
- .prm_sldo_core_ctrl = 0x4ae07cc8,
- .prm_sldo_mpu_setup = 0x4ae07ccc,
- .prm_sldo_mpu_ctrl = 0x4ae07cd0,
- .prm_sldo_mm_setup = 0x4ae07cd4,
- .prm_sldo_mm_ctrl = 0x4ae07cd8,
.prm_abbldo_mpu_setup = 0x4ae07cdc,
.prm_abbldo_mpu_ctrl = 0x4ae07ce0,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 66f416f..c7efbb4 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -310,12 +310,6 @@ struct prcm_regs {
u32 prm_vc_val_bypass;
u32 prm_vc_cfg_i2c_mode;
u32 prm_vc_cfg_i2c_clk;
- u32 prm_sldo_core_setup;
- u32 prm_sldo_core_ctrl;
- u32 prm_sldo_mpu_setup;
- u32 prm_sldo_mpu_ctrl;
- u32 prm_sldo_mm_setup;
- u32 prm_sldo_mm_ctrl;
u32 prm_abbldo_mpu_setup;
u32 prm_abbldo_mpu_ctrl;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
i'm sure there's a simple answer to this -- i built u-boot for my beaglebone black using the am335x_boneblack config, which supports saving env info to the eMMC HW partition boot1. but now that it's there, is there a way i can manipulate that info with fw_printenv and fw_setenv? that info is actually visible from the linux command line via the special device file /dev/mmcblk1boot1, which i can hexdump if i wish: # hexdump -C /dev/mmcblk1boot1 | less fc d7 b6 21 61 72 63 68 3d 61 72 6d 00 62 61 75 |...!arch=arm.bau| 0010 64 72 61 74 65 3d 31 31 35 32 30 30 00 62 6f 61 |drate=115200.boa| 0020 72 64 3d 61 6d 33 33 35 78 00 62 6f 61 72 64 5f |rd=am335x.board_| 0030 6e 61 6d 65 3d 41 33 33 35 42 4e 4c 54 00 62 6f |name=A335BNLT.bo| 0040 61 72 64 5f 72 65 76 3d 30 41 35 43 00 62 6f 6f |ard_rev=0A5C.boo| 0050 74 5f 66 64 74 3d 74 72 79 00 62 6f 6f 74 61 72 |t_fdt=try.bootar| ... snip ... so it's clearly there, but i have no idea what i'd put in /etc/fw_env.config to refer to that partition. i tried adding the simple line: /dev/mmcblk1boot1 0x0 0x4000 to (allegedly) represent a block device, but i got the error: # fw_printenv Cannot access MTD device /dev/mmcblk1boot: No such file or directory # so i'm guessing that was a really bad initial guess. i'm guessing i'd need to add a line referring to the existing device file /dev/mmcblk1, and add the actual HW partition offset and size, yes? i just have to figure out what that is, if that's the way it's done. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
Dear Robert P. J. Day,
On 08/23/2013 02:25 PM, Robert P. J. Day wrote:
snip
so it's clearly there, but i have no idea what i'd put in
/etc/fw_env.config to refer to that partition.
i tried adding the simple line:
/dev/mmcblk1boot1 0x0 0x4000
to (allegedly) represent a block device, but i got the error:
# fw_printenv
Cannot access MTD device /dev/mmcblk1boot: No such file or directory
#
I think you stumble over this:
---8---
abiessmann@punisher % grep -C 4 'struct envdev_s' tools/env/fw_env.c
typeof(y) _min2 = (y); \
(void) (_min1 == _min2); \
_min1 _min2 ? _min1 : _min2; })
struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
ulong env_sectors; /* number of environment sectors */
uint8_t mtd_type; /* type of the MTD device */
};
---8---
An device name can only have 16 char by this declaration ;)
so i'm guessing that was a really bad initial guess. i'm guessing i'd
need to add a line referring to the existing device file /dev/mmcblk1,
and add the actual HW partition offset and size, yes? i just have to
figure out what that is, if that's the way it's done.
Dunno if that'd be all to support RAW eMMC partition. As long as thy
behave like raw MTD partition it should work out.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/2013 06:25 PM, Scott Wood wrote: On Wed, 2013-08-14 at 11:46 +0530, Pekon Gupta wrote: BCH8_ECC scheme implemented in omap_gpmc.c driver has following two favours +---+-+-+ |ECC Scheme | ECC Calculation | Error Detection | +---+-+-+ |OMAP_ECC_BCH8_CODE_HW |GPMC |ELM H/W engine | |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |GPMC |S/W BCH library | +---+-+-+ Current implementation enables of BCH8_CODE_HW only for AM33xx SoC family. (using CONFIG_AM33XX). However, other SoC families (like TI81xx) also have ELM hardware module, and can support ECC error detection using ELM. This patch - replaces CONFIG_AM33xx define with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW so that all device families having required h/w capability can use ELM for error detection in ECC_BCHx schemes. - replaces CONFIG_NAND_OMAP_BCH8 with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW CONFIG_BCH and separates out code for above mentioned BCH8_ECC implementations so that driver can be build independently using anyone of them. CONFIG_BCH is used to enable software BCH library in lib/bch.c Signed-off-by: Pekon Gupta pe...@ti.com --- doc/README.nand | 20 +++ drivers/mtd/nand/omap_gpmc.c | 128 --- include/configs/am335x_evm.h | 1 + include/configs/ti814x_evm.h | 2 +- include/configs/tricorder.h | 2 +- 5 files changed, 96 insertions(+), 57 deletions(-) The ti814x_evm.h changes do not apply. What tree is this against? Can someone familiar with the OMAP driver review this patchset? The ti814x_evm.h part depends on his earlier patch I suspect. If you're happy NAND-wise, I'll pick these up (and formally review 'em, I have skimmed) for the TI tree if that works for you. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSF1kHAAoJENk4IS6UOR1WpSQP/RKHIQxwNKNhHA1QpwJHBW1w jQcil0HA1GEtovq4YdoYjIENzdVa9pElY+YvkOMy8/sf8CAxgpXDBuFwuJJEkdX7 FVX+HBvMDFvEp7b2epm2Icz2/SQGFMDM2XX1yOT8ojBmuS9vPXylBbQwZBSdq4V8 kdZ4065PtsPZ7ZtH43CwKYEMeYUPLxQOelQZDKY0OZYymfgsuIA7P57g21AD9EtR P+njljb8PHTaTabD35DMKdds3hNy/MYBpZ0VxCWH9O6t6K9eo6TWo+WhEYTyanI+ JE3Dj1YZecyPFLAqdeY6Irz1hGwBtkkS1He6InBsIOlJ5dsjSZmU5ABqNKP8i3Sx 4BypEIo0OUIz8p26DzppSPvy1tvxib2wEY2mDqKKqqhKHwo9XgmJfRDfIYurhKxY N3DgoOPoNuVUKsVFEkD4r9gvlrSyl1wZgRf0sc3qvFQvbOzgIz8AQ+DOPrGTKVGk /HDVH0I9uRkJFtAIBOY5ckygIb0uuzyXc6W7yuNpDu6nVt0Vb4/Uk0OeIBIagbR8 1dN0nqRyu6f4+xwtRF7DrdfgULyAgKnubjr9i0eR6KE+xVdcKq9zStzMCN/hE623 0g/kfVEM8iIPZYb6oxeMx7N2mEe8L/W9lz3bXTibtwCSB+NJF7RjTto7ltT+R9Az 3Nr2HudfhOUBpQISAmyA =cJ/1 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
Hi Robert, On 23/08/2013 14:25, Robert P. J. Day wrote: i'm sure there's a simple answer to this There is -- i built u-boot for my beaglebone black using the am335x_boneblack config, which supports saving env info to the eMMC HW partition boot1. but now that it's there, is there a way i can manipulate that info with fw_printenv and fw_setenv? Check in code - fw_printenv / fw_setenv are supposed to work with a MTD device, and the MMC is not. There are some additional checks and handling of NOR and NAND devices is done differently. But there is no code for MMC. However, managing MMC is easier: no need of erasing flash, simply write into the device computing the CRC. You could add the required functions to rwad / write a buffer from MMC to fw_printenv (and posting here the patch, thanks !). Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Fri, 23 Aug 2013, Andreas Bießmann wrote:
Dear Robert P. J. Day,
On 08/23/2013 02:25 PM, Robert P. J. Day wrote:
snip
so it's clearly there, but i have no idea what i'd put in
/etc/fw_env.config to refer to that partition.
i tried adding the simple line:
/dev/mmcblk1boot1 0x0 0x4000
to (allegedly) represent a block device, but i got the error:
# fw_printenv
Cannot access MTD device /dev/mmcblk1boot: No such file or directory
#
I think you stumble over this:
---8---
abiessmann@punisher % grep -C 4 'struct envdev_s' tools/env/fw_env.c
typeof(y) _min2 = (y); \
(void) (_min1 == _min2); \
_min1 _min2 ? _min1 : _min2; })
struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
ulong env_sectors; /* number of environment sectors */
uint8_t mtd_type; /* type of the MTD device */
};
---8---
An device name can only have 16 char by this declaration ;)
good lord, you're right, that explains why the last character of the
device file was getting mysteriously dropped. :-( so as a quick hack,
i just did a mknod (i suspect a symlink would have worked just as
well) to invent a shorter name, /dev/mmcboot1, and got
(predictably):
# fw_printenv
Cannot get MTD information: Invalid argument
#
which leads me into stefano's response which i just saw.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Fri, 23 Aug 2013, Stefano Babic wrote:
Hi Robert,
On 23/08/2013 14:25, Robert P. J. Day wrote:
i'm sure there's a simple answer to this
There is
-- i built u-boot for my
beaglebone black using the am335x_boneblack config, which
supports saving env info to the eMMC HW partition boot1. but now
that it's there, is there a way i can manipulate that info with
fw_printenv and fw_setenv?
Check in code - fw_printenv / fw_setenv are supposed to work with a
MTD device, and the MMC is not. There are some additional checks and
handling of NOR and NAND devices is done differently. But there is
no code for MMC.
yup, i can see that. the tools i was using were an earlier version
selected by my OE build, where the code in fw_env.c was:
static int flash_read (int fd)
{
struct mtd_info_user mtdinfo;
int rc;
rc = ioctl (fd, MEMGETINFO, mtdinfo);
if (rc 0) {
perror (Cannot get MTD information); -- where it was failing
return -1;
}
if (mtdinfo.type != MTD_NORFLASH
mtdinfo.type != MTD_NANDFLASH
mtdinfo.type != MTD_DATAFLASH) {
fprintf (stderr, Unsupported flash type %u\n, mtdinfo.type);
return -1;
}
... snip ...
i can see, in the current repo, that's been refined to distinguish
between block and character device files:
static int flash_read (int fd)
{
struct mtd_info_user mtdinfo;
struct stat st;
int rc;
rc = fstat(fd, st);
if (rc 0) {
fprintf(stderr, Cannot stat the file %s\n,
DEVNAME(dev_current));
return -1;
}
if (S_ISCHR(st.st_mode)) {
rc = ioctl(fd, MEMGETINFO, mtdinfo);
if (rc 0) {
fprintf(stderr, Cannot get MTD information for %s\n,
DEVNAME(dev_current));
return -1;
}
if (mtdinfo.type != MTD_NORFLASH
mtdinfo.type != MTD_NANDFLASH
mtdinfo.type != MTD_DATAFLASH
mtdinfo.type != MTD_UBIVOLUME) {
fprintf (stderr, Unsupported flash type %u on %s\n,
mtdinfo.type, DEVNAME(dev_current));
return -1;
}
} else {
memset(mtdinfo, 0, sizeof(mtdinfo));
mtdinfo.type = MTD_ABSENT;
}
... snip ...
which, as you point out, still doesn't solve the problem.
However, managing MMC is easier: no need of erasing flash, simply
write into the device computing the CRC. You could add the required
functions to rwad / write a buffer from MMC to fw_printenv (and
posting here the patch, thanks !).
as i read it (and i could be totally wrong here), all that needs to
be added is a way to specify to the fw_* tools that a given (block)
partition has nothing to do with flash, and that it should be treated
as pure data, bypassing any flash-related processing as you say.
i'm assuming that this would require deciding how to specify this in
/etc/fw_env.config so the tools understand what's happening. thoughts
on that? the line will look like:
/dev/mmcblk1boot1 ... and what goes here? ...
to identify this as a non-MTD partition?
and i guess that 16-character filename limit needs to be adjusted as
well, yes?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mxsmmc: Enable MMC HC support
Hi, From: Amaury Pouly amaury.po...@gmail.com Enable support for high-capacity eMMC and MMC cards. The MXS MMC driver has no problem with those. Signed-off-by: Marek Vasut ma...@denx.de Signed-off-by: Amaury Pouly amaury.po...@gmail.com Cc: Andy Fleming aflem...@freescale.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Stefano, can you apply this please? It's quite important fix. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mxsmmc: Enable MMC HC support
Hi Marek, On 23/08/2013 15:45, Marek Vasut wrote: Hi, From: Amaury Pouly amaury.po...@gmail.com Enable support for high-capacity eMMC and MMC cards. The MXS MMC driver has no problem with those. Signed-off-by: Marek Vasut ma...@denx.de Signed-off-by: Amaury Pouly amaury.po...@gmail.com Cc: Andy Fleming aflem...@freescale.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Stefano, can you apply this please? It's quite important fix. Done ! Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mxsmmc: Enable MMC HC support
Dear Stefano Babic, Hi Marek, On 23/08/2013 15:45, Marek Vasut wrote: Hi, From: Amaury Pouly amaury.po...@gmail.com Enable support for high-capacity eMMC and MMC cards. The MXS MMC driver has no problem with those. Signed-off-by: Marek Vasut ma...@denx.de Signed-off-by: Amaury Pouly amaury.po...@gmail.com Cc: Andy Fleming aflem...@freescale.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Stefano, can you apply this please? It's quite important fix. Done ! Applied to u-boot-imx, thanks. Thanks. Did Andry disappear btw? I get the address no longer exists. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mxsmmc: Enable MMC HC support
Hi Marek, On 23/08/2013 15:58, Marek Vasut wrote: Dear Stefano Babic, Hi Marek, On 23/08/2013 15:45, Marek Vasut wrote: Hi, From: Amaury Pouly amaury.po...@gmail.com Enable support for high-capacity eMMC and MMC cards. The MXS MMC driver has no problem with those. Signed-off-by: Marek Vasut ma...@denx.de Signed-off-by: Amaury Pouly amaury.po...@gmail.com Cc: Andy Fleming aflem...@freescale.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Stefano, can you apply this please? It's quite important fix. Done ! Applied to u-boot-imx, thanks. Thanks. Did Andry disappear btw? I get the address no longer exists. Yes, search for Tom's Announcement: http://u-boot.10912.n7.nabble.com/Some-custodian-changes-td160994.html Antonio is the new custodian for MMC stuff. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] beaglxm/bootz: kernel boot fail due to align err: cache handling issues?
Hi, Noticed an interesting behavior where adding a dcache flush kernel boot fail due to unaligned-accesses seems to go away. Full details: http://pastebin.com/kVBRWsbE Without dcache flush being added to my uenvcmd: Kernel image @ 0x8020 [ 0x00 - 0x3e2690 ] data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [9ff6f6b4] lr : [9ff6ef6c] sp : 9fefaaf0 ip : 9fefe8ec fp : r10: 9ffa6544 r9 : 9ffa5e5c r8 : 9fefaf30 r7 : 0f80 r6 : 9ffa6544 r5 : 9ffa65b0 r4 : 9ffa65b4 r3 : 0049 r2 : 0010 r1 : r0 : 0f80 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... With dcache flush being added to my uenvcmd: complete boot I think something of the form was highlighted here: http://marc.info/?l=u-bootm=137276534624656w=2 Not sure if there was any conclusion to the effect. A quick tag bisect attempt was'nt too useful either. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Documentation review request: Cache management and stand alone application
Based on some recent mailing list discussions about cache management for stand alone applications, and on my own recent experience, I've made two small additions to the documentation wiki. Since I can't find any procedure for having this work reviewed, I'm asking for a review here. Please see the new sections, _5.12.3. Processor cache considerations_ and _5.12.4 Running on core other than core 0_, at http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.3. and http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.4., respectively. If there is a standard review process for the wiki that I have not seen, I'd appreciate a pointer. I'll be happy to retroactively make any adjustments needed. My additions reflect my concerns with the MPC85xx (P1022) which I am working with. I would not be surprised in the least if the discussion I have provided apply poorly for other architectures. Thank you and best regards, Jim -- Jim Chargin AJA Video Systems j...@aja.com (530) 271-3334 http://www.aja.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Failing USB devices
On Aug 23, 2013, at 6:54 AM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: This is the kind of issue that made me create this (discarded) patch at some point: http://patchwork.ozlabs.org/patch/176527/ Can you try it? I'm not sure that it will be helpful for your specific case. I also have this issue with some devices and mainline U-Boot. I can confirm that this is a device initialization delay issue because subsequent USB commands on the device succeed (only the single automatic U-Boot USB command that I use at boot time fails). FWIW I've had a similar problem with an OMAP3 board. I run usb start and then immediately usb reset once or twice until my USB device shows up. I'll try the suggestions here. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beaglxm/bootz: kernel boot fail due to align err: cache handling issues?
On Fri, Aug 23, 2013 at 9:21 AM, Nishanth Menon n...@ti.com wrote:
Hi,
Noticed an interesting behavior where adding a dcache flush kernel boot
fail due to unaligned-accesses seems to go away.
Full details: http://pastebin.com/kVBRWsbE
Without dcache flush being added to my uenvcmd:
Kernel image @ 0x8020 [ 0x00 - 0x3e2690 ]
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff6f6b4] lr : [9ff6ef6c]
sp : 9fefaaf0 ip : 9fefe8ec fp :
r10: 9ffa6544 r9 : 9ffa5e5c r8 : 9fefaf30
r7 : 0f80 r6 : 9ffa6544 r5 : 9ffa65b0 r4 : 9ffa65b4
r3 : 0049 r2 : 0010 r1 : r0 : 0f80
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
With dcache flush being added to my uenvcmd: complete boot
I think something of the form was highlighted here:
http://marc.info/?l=u-bootm=137276534624656w=2
Not sure if there was any conclusion to the effect.
There may still be an underline bug, but the bootz ${loadaddr} issue
i showed in that post was fixed very late in the v2013.07, i forget
the commit, it may have been a day or two right before.
So looking at your pastebin.com log: U-Boot
2013.07-rc2-00044-g1d28a6a it might be worthwhile to re-test with
v2013.07 final, specially since your using bootz...
(I've already been shipping a bootz enabled u-boot v2013.07 for the
beagle-xm to end users)..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] net: phy/vitesse: Add support for VSC8514 phy module
From: Arpit Goel b44...@freescale.com
This patch adds support for VSC8514 PHY module which can be
found on Freescale's T1040RDB boards.
Signed-off-by: Arpit Goel b44...@freescale.com
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
---
drivers/net/phy/vitesse.c | 69 ++-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 5cf103e..c555979 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -49,6 +49,15 @@
#define MIIM_VSC8574_18G_QSGMII0x80e0
#define MIIM_VSC8574_18G_CMDSTAT 0x8000
+/* Vitesse VSC8514 control register */
+#define MIIM_VSC8514_GENERAL18 0x12
+#define MIIM_VSC8514_GENERAL19 0x13
+#define MIIM_VSC8514_GENERAL23 0x17
+
+/* Vitesse VSC8514 gerenal purpose register 18 */
+#define MIIM_VSC8514_18G_QSGMII0x80e0
+#define MIIM_VSC8514_18G_CMDSTAT 0x8000
+
/* CIS8201 */
static int vitesse_config(struct phy_device *phydev)
{
@@ -148,7 +157,7 @@ static int vsc8601_config(struct phy_device *phydev)
static int vsc8574_config(struct phy_device *phydev)
{
u32 val;
- /* configure regiser 19G for MAC */
+ /* configure register 19G for MAC */
phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
PHY_EXT_PAGE_ACCESS_GENERAL);
@@ -188,6 +197,53 @@ static int vsc8574_config(struct phy_device *phydev)
return 0;
}
+static int vsc8514_config(struct phy_device *phydev)
+{
+ u32 val;
+ int timeout = 100;
+
+ /* configure register to access 19G */
+ phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
+ PHY_EXT_PAGE_ACCESS_GENERAL);
+
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL19);
+ if (phydev-interface == PHY_INTERFACE_MODE_QSGMII) {
+ /* set bit 15:14 to '01' for QSGMII mode */
+ val = (val 0x3fff) | (1 14);
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MIIM_VSC8514_GENERAL19, val);
+ /* Enable 4 ports MAC QSGMII */
+ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL18,
+ MIIM_VSC8514_18G_QSGMII);
+ } else {
+ /*TODO Add SGMII functionality once spec sheet
+* for VSC8514 defines complete functionality
+*/
+ }
+
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL18);
+ /* When bit 15 is cleared the command has completed */
+ while ((val MIIM_VSC8514_18G_CMDSTAT) timeout--)
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL18);
+
+ if (0 == timeout) {
+ printf(PHY 8514 config failed\n);
+ return -1;
+ }
+
+ phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 0);
+
+ /* configure register to access 23 */
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23);
+ /* set bits 10:8 to '000' */
+ val = (val 0xf8ff);
+ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23, val);
+
+ genphy_config_aneg(phydev);
+
+ return 0;
+}
+
static struct phy_driver VSC8211_driver = {
.name = Vitesse VSC8211,
.uid= 0xfc4b0,
@@ -238,6 +294,16 @@ static struct phy_driver VSC8574_driver = {
.shutdown = genphy_shutdown,
};
+static struct phy_driver VSC8514_driver = {
+ .name = Vitesse VSC8514,
+ .uid = 0x70570,
+ .mask = 0x0,
+ .features = PHY_GBIT_FEATURES,
+ .config = vsc8514_config,
+ .startup = vitesse_startup,
+ .shutdown = genphy_shutdown,
+};
+
static struct phy_driver VSC8601_driver = {
.name = Vitesse VSC8601,
.uid = 0x70420,
@@ -298,6 +364,7 @@ int phy_vitesse_init(void)
phy_register(VSC8211_driver);
phy_register(VSC8221_driver);
phy_register(VSC8574_driver);
+ phy_register(VSC8514_driver);
phy_register(VSC8662_driver);
phy_register(cis8201_driver);
phy_register(cis8204_driver);
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beaglxm/bootz: kernel boot fail due to align err: cache handling issues?
On 08/23/2013 09:32 AM, Robert Nelson wrote:
On Fri, Aug 23, 2013 at 9:21 AM, Nishanth Menon n...@ti.com wrote:
Hi,
Noticed an interesting behavior where adding a dcache flush kernel boot
fail due to unaligned-accesses seems to go away.
Full details: http://pastebin.com/kVBRWsbE
Without dcache flush being added to my uenvcmd:
Kernel image @ 0x8020 [ 0x00 - 0x3e2690 ]
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff6f6b4] lr : [9ff6ef6c]
sp : 9fefaaf0 ip : 9fefe8ec fp :
r10: 9ffa6544 r9 : 9ffa5e5c r8 : 9fefaf30
r7 : 0f80 r6 : 9ffa6544 r5 : 9ffa65b0 r4 : 9ffa65b4
r3 : 0049 r2 : 0010 r1 : r0 : 0f80
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
With dcache flush being added to my uenvcmd: complete boot
I think something of the form was highlighted here:
http://marc.info/?l=u-bootm=137276534624656w=2
Not sure if there was any conclusion to the effect.
There may still be an underline bug, but the bootz ${loadaddr} issue
i showed in that post was fixed very late in the v2013.07, i forget
the commit, it may have been a day or two right before.
So looking at your pastebin.com log: U-Boot
2013.07-rc2-00044-g1d28a6a it might be worthwhile to re-test with
v2013.07 final, specially since your using bootz...
Arrgh... I must have been completely blind :(
you are right,
v2013.07 - still failed, BUT,
v2013.10-rc1 just works fine.
2013.10-rc1-00029-g6612ab also works fine.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] ARMv7: Add HYP mode switching support
Hello, On Fri, Aug 9, 2013 at 6:03 PM, Andre Przywara andre.przyw...@linaro.orgwrote: (for GIT URL and Changelog see below) ARM CPUs with the virtualization extension have a new mode called HYP mode, which allows hypervisors to safely control and monitor guests. The current hypervisor implementations (KVM and Xen) require the kernel to be entered in that HYP mode. This patch series introduces a configuration variable CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP mode. This is done automatically during execution of the bootm command. The process of switching into HYP mode requires the CPU to be in secure state initially when entering u-boot, it will then setup some register and switch to non-secure state. This requires the GIC to be programmed properly first. Explanations about the details are in the commit messages of the respective patches. The patches are structured like this: 1/8: prepare header file 2/8: add monitor handler (assembly) 3/8: add per CPU non-secure switch routine (assembly) 4/8: add system wide non-secure setup (C) 5/8: trigger non-secure switch during bootm command 6/8: add generic SMP functionality 7/8: add HYP mode switching 8/8: board specific code for ARM Versatile Express TC2 Since up to patch 6/8 this code works on non-virtualization capable CPUs also and there has been a request, there is now a second configuration variable CONFIG_ARMV7_NONSEC, which omits the final HYP mode switch and just goes into non-secure SVC state. You can specify either (or none) of them, the code cares about the dependency. The code aims to be as generic as possible, though currently it has only been tested on the Versatile Express TC-2 board. The last patch We have backported [1] these patches to U-Boot for the ARM Chromebook (Samsung Exynos5250 SoC). They work without functional changes, including this last v4. We can consider the code tested on Exynos5 also. thus enables the feature for that board and should serve as an example for supporting other boards. For convenience there is a GIT tree which you can pull these patches from (hypmode_v4 branch): git://git.linaro.org/people/aprzywara/u-boot.git Changes RFC..v1 * not a dedicated command anymore, code run by bootm friends * protecting code with #ifdefs to avoid unnecessary inclusion and accidental crashing (when accessing restricted registers) * moving prototypes to header file to meet checkpatch recommendation * adding comment as proposed by Christoffer Changes v1..v2 mostly style and code layout changes * restructure assembly code to live in a new file and not start.S * split smp, nonsec_init and hyp_init to be separate functions * used named constants from common header files * split C function to be more readable * extend comments to be more precise and elaborate * add provision to override GIC base address (needed for Arndale?) * add configuration variable to enable VExpress specific SMP code * use writel/readl for MMIO GIC accesses * remove superfluous isb instructions * more minor fixes Changes v2..v3 * fix clobbering of GICC address actually spoiling the stack * do CNTFRQ setup in assembly per core (and not only once per SoC) * moving the new code files into arch/arm/cpu/armv7 * add config variable for doing non-secure switch only * use actual HYP and secure instructions mnemonics instead of the encoded byte sequence. This requires more recent compilers. * make the identification of the CPU core more robust and saner * use enum for error codes and rename them * lots of smaller layout and style fixes Changes v3..v4 * mask reserved bits in CBAR register * move the VExpress board specific SMP code into the board directory * embed error reporting in the respective functions and getting rid of the error code enum at all (by popular demand ;-) * minor style fixes Please review and comment! Contributions and comments to support other boards are welcome. Andre Przywara (8): ARM: prepare armv7.h to be included from assembly source ARM: add secure monitor handler to switch to non-secure state ARM: add assembly routine to switch to non-secure state ARM: add C function to switch to non-secure state ARM: trigger non-secure state switch during bootm execution ARM: add SMP support for non-secure switch ARM: extend non-secure switch to also go into HYP mode ARM: VExpress: enable ARMv7 virt support for VExpress A15 arch/arm/cpu/armv7/Makefile | 5 + arch/arm/cpu/armv7/nonsec_virt.S| 196 arch/arm/cpu/armv7/virt-v7.c| 172 arch/arm/include/asm/armv7.h| 33 +- arch/arm/include/asm/gic.h | 19 arch/arm/lib/bootm.c| 18 +++ board/armltd/vexpress/Makefile | 7 +- board/armltd/vexpress/vexpress_common.c | 13 +++
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:
i'm sure there's a simple answer to this -- i built u-boot for my
beaglebone black using the am335x_boneblack config, which supports
saving env info to the eMMC HW partition boot1. but now that it's
there, is there a way i can manipulate that info with fw_printenv and
fw_setenv?
I have put this in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/110-add-support-for-MTD_ABSENT.patch
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/115-writing-environment-for-mtd-devices.patch
With those two you will be able to use fw_{printenv,setenv} on MMC
devices.
Luka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Fri, 23 Aug 2013, Luka Perkov wrote:
On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:
i'm sure there's a simple answer to this -- i built u-boot for my
beaglebone black using the am335x_boneblack config, which supports
saving env info to the eMMC HW partition boot1. but now that it's
there, is there a way i can manipulate that info with fw_printenv and
fw_setenv?
I have put this in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/110-add-support-for-MTD_ABSENT.patch
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/115-writing-environment-for-mtd-devices.patch
With those two you will be able to use fw_{printenv,setenv} on MMC
devices.
and how would you specify the partition in the /etc/fw_env.config
file?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit 6612ab33956ae09c5ba2fde9c1540b519625ba37: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2013-08-21 16:27:47 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to 2b26201a2aef0b310b7c04702b0dba5dea493f77: env_nand.c: support falling back to redundant env when writing (2013-08-22 17:49:47 -0500) Masahiro Yamada (4): cmd_nand: fix a memory leak in nand_dump function cmd_nand: slight optimization of nand_dump function cmd_nand: Do not show usage when scrub is aborted nand_util: delete a useless variable Phil Sutter (1): env_nand.c: support falling back to redundant env when writing common/cmd_nand.c| 40 +-- common/env_nand.c| 116 --- drivers/mtd/nand/nand_util.c | 3 +- 3 files changed, 81 insertions(+), 78 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am33xx: Enable D-CACHE on !CONFIG_SYS_DCACHE_OFF
Test on Beaglebone white over cpsw, usb ether and SD card (read and
write), performance increased, crc32 of data matches.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/am33xx/board.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 2ea3d69..c261af5 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -225,3 +225,11 @@ void s_init(void)
sdram_init();
#endif
}
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in start.S */
+ dcache_enable();
+}
+#endif /* !CONFIG_SYS_DCACHE_OFF */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] CONFIG_OF_EMBED question
On Fri, Aug 23, 2013 at 19:35 +0800, tiger...@viatech.com.cn wrote: Hi, experts: If i defined CONFIG_OF_EMBED, then: Where could i find _binary_dt_dtb_start's definition? In arch/arm/lib/board.c: gd-fdt_blob = _binary_dt_dtb_start; but i could not find _binary_dt_dtb_start's definition. Looks like something the linker will resolve while the symbol is introduced by something that isn't generated from compiling source code. See the objcopy(1) manpage and search for '_start' there. This appears to be a feature of incorporating BLOBs and data files into your executables without taking the detour of generating header files, and perfectly fits into what the embed name of the config option suggests. So depending on why you are asking (you don't tell what is the actual problem you are trying to solve, just which detail you currently are digging into), you may want to search the makefiles and other build instructions on where a file named dt.dtb or similar gets referenced. See the output of `git grep -C 5 'dt.dtb'` -- Makefile and dtc/Makefile probably are what you are looking for. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
On Fri, 2013-08-23 at 08:43 -0400, Tom Rini wrote: On 08/22/2013 06:25 PM, Scott Wood wrote: On Wed, 2013-08-14 at 11:46 +0530, Pekon Gupta wrote: BCH8_ECC scheme implemented in omap_gpmc.c driver has following two favours +---+-+-+ |ECC Scheme | ECC Calculation | Error Detection | +---+-+-+ |OMAP_ECC_BCH8_CODE_HW |GPMC |ELM H/W engine | |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |GPMC |S/W BCH library | +---+-+-+ Current implementation enables of BCH8_CODE_HW only for AM33xx SoC family. (using CONFIG_AM33XX). However, other SoC families (like TI81xx) also have ELM hardware module, and can support ECC error detection using ELM. This patch - replaces CONFIG_AM33xx define with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW so that all device families having required h/w capability can use ELM for error detection in ECC_BCHx schemes. - replaces CONFIG_NAND_OMAP_BCH8 with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW CONFIG_BCH and separates out code for above mentioned BCH8_ECC implementations so that driver can be build independently using anyone of them. CONFIG_BCH is used to enable software BCH library in lib/bch.c Signed-off-by: Pekon Gupta pe...@ti.com --- doc/README.nand | 20 +++ drivers/mtd/nand/omap_gpmc.c | 128 --- include/configs/am335x_evm.h | 1 + include/configs/ti814x_evm.h | 2 +- include/configs/tricorder.h | 2 +- 5 files changed, 96 insertions(+), 57 deletions(-) The ti814x_evm.h changes do not apply. What tree is this against? Can someone familiar with the OMAP driver review this patchset? The ti814x_evm.h part depends on his earlier patch I suspect. If you're happy NAND-wise, I'll pick these up (and formally review 'em, I have skimmed) for the TI tree if that works for you. OK: Acked-by: Scott Wood scottw...@freescale.com -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
On Fri, Aug 23, 2013 at 10:48:50AM -0500, Scott Wood wrote: The following changes since commit 6612ab33956ae09c5ba2fde9c1540b519625ba37: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2013-08-21 16:27:47 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to 2b26201a2aef0b310b7c04702b0dba5dea493f77: env_nand.c: support falling back to redundant env when writing (2013-08-22 17:49:47 -0500) Masahiro Yamada (4): cmd_nand: fix a memory leak in nand_dump function cmd_nand: slight optimization of nand_dump function cmd_nand: Do not show usage when scrub is aborted nand_util: delete a useless variable Phil Sutter (1): env_nand.c: support falling back to redundant env when writing common/cmd_nand.c| 40 +-- common/env_nand.c| 116 --- drivers/mtd/nand/nand_util.c | 3 +- 3 files changed, 81 insertions(+), 78 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/5] board support of arm64
On Thu, Aug 22, 2013 at 12:50:44PM -0500, Scott Wood wrote: On Thu, 2013-08-22 at 12:44 -0500, Stuart Yoder wrote: On Thu, Aug 22, 2013 at 11:23 AM, Scott Wood scottw...@freescale.com wrote: On Thu, 2013-08-22 at 11:15 -0500, Stuart Yoder wrote: On Mon, Aug 19, 2013 at 2:59 PM, Scott Wood scottw...@freescale.com wrote: On Fri, 2013-08-16 at 09:14 -0500, Stuart Yoder wrote: Why is the device tree source in u-boot (instead of in the kernel)? Is this temporary? It looks like this device tree is just a copy from somewhere else. Would suggest removing this from this patch series and keep the dts maintained in the Linux kernel. U-Boot itself uses the device tree (not just to patch up for Linux) on some targets. Even with the way PPC uses device trees, it doesn't really make sense to keep them in the kernel given that they're meant to be OS-neutral, and have ties to U-Boot in terms of what gets fixed up at runtime. It may not make sense, but that is where they are kept currently. For PPC. $ find arch/arm/boot/dts | wc -l 425 $ find arch/powerpc/boot/dts | wc -l 315 My point is this isn't the first device tree to go into U-Boot for ARM. Right, but a problem we have today is that the existing ones are incompatible with the real device trees for the devices in question. It doesn't make sense to maintain 2 copies of a vexpress64.dts device tree in 2 different places...or to maintain 1 lone device tree in u-boot. Why does it not make sense for there to be one lone device tree in U-Boot? It doesn't make sense to me to keep one device tree in u-boot and the rest in the kernel. That's not what's being proposed. Submodules can be a pain. If we don't use them for DTC, why would we use them for this? Since they require extra commands, you'd be modifying the workflow of everyone that builds U-Boot and/or Linux for affected platforms. You shouldn't need device trees for building u-boot or the kernel. Then why mess around with submodules instead of just a separate repository? I don't think a couple of extra commands is that burdensome. I disagree, and at the least don't want to be the one to advocate such a change. :-) I agree the DTS files really don't belong in the kernel, but there is currently no better repository that has been proposed. I'm not sure u-boot is a better place.Device trees should be independent of any particular bootloader or OS. The final device tree that the OS sees should be independent of the OS. The dts is not the final device tree, and is tied to U-Boot. The device tree in general is also tied to the bootloader in other ways -- U-Boot expects certain aliases, configurable addresses must match, etc. I really hope that when the data gets pulled out of the kernel we'll have a useable central repository somewhere that can be used and various problems like this are taken into consideration. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] CONFIG_FIT and CONFIG_OF_LIBFDT
On Fri, Aug 23, 2013 at 02:36:23PM +0800, tiger...@viatech.com.cn wrote: Hi, experts: I have a question about supporting FDT in uboot. 1. If i want to provide FDT support function in uboot code, just need to : Define CONFIG_OF_LIBFDT in vendor_config.h If my uImage is still a single component image, not need to define CONFIG_FIT at the same time? CONFIG_FIT and CONFIG_OF_LIBFDT are indeed unrelated options. You can use DT files with legacy images and plain zImages as well. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] common: Add CCACHE variable to allow use of ccache
On 08/22/2013 08:05 PM, Marek Vasut wrote: Dear York Sun, On 08/22/2013 12:36 PM, Marek Vasut wrote: There is an env variable to configure separate ccache cache dir , so just by setting that. But then , when each build ends, you would need to clean it up somehow. It was mentioned in the discussion with the patch. You can try working on this some more and post a patch, then we can talk about further forging of this. I fixed the 2nd patch and I am running MAKEALL with individual board folder for ccache. The compiling time for the first run on my laptop is 56 minutes. The 2nd run is 23 minutes. About the same improvement if using a big unified cache for all boards. By the way, each board cache is about 7~8MB. You set my expectation high. I was hoping to get 10x or more improvement. It should be more, try checking if there is no bottleneck. I can send you the patch. Will you be able to test? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Fri, 23 Aug 2013, Luka Perkov wrote:
On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:
i'm sure there's a simple answer to this -- i built u-boot for my
beaglebone black using the am335x_boneblack config, which supports
saving env info to the eMMC HW partition boot1. but now that it's
there, is there a way i can manipulate that info with fw_printenv and
fw_setenv?
I have put this in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/110-add-support-for-MTD_ABSENT.patch
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/115-writing-environment-for-mtd-devices.patch
With those two you will be able to use fw_{printenv,setenv} on MMC
devices.
i'll get a chance to test the above this weekend, but i just want to
make absolutely sure we're talking about the same thing. are you
saying that with the above patches, the u-boot-tools will be able to
manipulate an eMMC HW partition just as easily as a regular MTD
partition? and, if so, what is the format of the entry one would add
to /etc/fw_env.config to refer to that eMMC HW partition (in this
case, boot1)?
thanks.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
On Wed, Aug 14, 2013 at 11:46:51AM +0530, Pekon Gupta wrote: [changes in v2] - added documentation for CONFIG_NAND_OMAP_xx in doc/README.nand - added CONFIG_BCH along with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW to include software library lib/bch.c - fixed board_nand_init() and omap_enable_hwecc() [Original v1] This patch series updates BCH8_ECC schemes in mtd/nand/omap_gpmc.c driver - adds scalability for higher ECC schemes in future. - removes CONFIG_AM335x and it makes it generic for all platforms. - optimizes read_data paths This series is tested for H/W BCH8_ECC scheme on - AM335x_EVM and TI814x_EVM Pekon Gupta (4): [PATCH 1/4] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform [PATCH 2/4] mtd: nand: omap: optimize chip-ecc.hwctl() for H/W ECC schemes [PATCH 3/4] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes [PATCH 4/4] mtd: nand: omap: optimized chip-ecc.correct() for H/W ECC schemes doc/README.nand | 20 ++ drivers/mtd/nand/omap_gpmc.c | 514 +++ include/configs/am335x_evm.h | 1 + include/configs/ti814x_evm.h | 2 +- include/configs/tricorder.h | 2 +- 5 files changed, 203 insertions(+), 336 deletions(-) Series looks good to me, I'll pick these up soon, after I test them on beagle as well. -- 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] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Fri, Aug 23, 2013 at 05:11:01PM -0400, Robert P. J. Day wrote:
On Fri, 23 Aug 2013, Luka Perkov wrote:
On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:
i'm sure there's a simple answer to this -- i built u-boot for my
beaglebone black using the am335x_boneblack config, which supports
saving env info to the eMMC HW partition boot1. but now that it's
there, is there a way i can manipulate that info with fw_printenv and
fw_setenv?
I have put this in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/110-add-support-for-MTD_ABSENT.patch
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/115-writing-environment-for-mtd-devices.patch
With those two you will be able to use fw_{printenv,setenv} on MMC
devices.
i'll get a chance to test the above this weekend, but i just want to
make absolutely sure we're talking about the same thing. are you
saying that with the above patches, the u-boot-tools will be able to
manipulate an eMMC HW partition just as easily as a regular MTD
partition?
Yes.
and, if so, what is the format of the entry one would add
to /etc/fw_env.config to refer to that eMMC HW partition (in this
case, boot1)?
I have done this for imx6 wandboard in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/files/imx6
So example config would look like:
/dev/mmcblk0 0x6 0x2000 0x2000
Luka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
Hi, On Thu, Aug 22, 2013 at 8:55 AM, FengHua feng...@phytium.com.cn wrote: On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote: -- ?: Scott Wood scottw...@freescale.com : 2013???8???22??? ? ?: Simon Glass s...@chromium.org ??: FengHua feng...@phytium.com.cn, tr...@ti.com tr...@ti.com, U-Boot Mailing List u-boot@lists.denx.de ??: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote: Hi David, On Tue, Aug 20, 2013 at 4:48 AM, feng...@phytium.com.cn wrote: diff --git a/common/board_r.c b/common/board_r.c index 86ca1cb..1b4bdd2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) */ gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE; #endif +#ifdef CONFIG_NEEDS_MANUAL_RELOC + /* +* We have to relocate the command table manually +*/ + fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd), + ll_entry_count(cmd_tbl_t, cmd)); +#endif /* CONFIG_NEEDS_MANUAL_RELOC */ Should this be done here or in main_loop()? How is this currently done when not using generic board? It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working. Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation. No, the point is that manual relocation is legacy and new platforms should be using proper relocation. Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem. Possible there is a new relocation type that you need to support? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Fri, 2013-08-23 at 18:12 -0600, Simon Glass wrote: Hi, On Thu, Aug 22, 2013 at 8:55 AM, FengHua feng...@phytium.com.cn wrote: On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote: -- ?: Scott Wood scottw...@freescale.com : 2013???8???22??? ? ?: Simon Glass s...@chromium.org ??: FengHua feng...@phytium.com.cn, tr...@ti.com tr...@ti.com, U-Boot Mailing List u-boot@lists.denx.de ??: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote: Hi David, On Tue, Aug 20, 2013 at 4:48 AM, feng...@phytium.com.cn wrote: diff --git a/common/board_r.c b/common/board_r.c index 86ca1cb..1b4bdd2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) */ gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE; #endif +#ifdef CONFIG_NEEDS_MANUAL_RELOC + /* +* We have to relocate the command table manually +*/ + fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd), + ll_entry_count(cmd_tbl_t, cmd)); +#endif /* CONFIG_NEEDS_MANUAL_RELOC */ Should this be done here or in main_loop()? How is this currently done when not using generic board? It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working. Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation. No, the point is that manual relocation is legacy and new platforms should be using proper relocation. Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem. Possible there is a new relocation type that you need to support? Yes, it's rela instead of rel. FengHua claimed to have run into problems supporting it; I'll try to debug it hopefully somewhat soon (though I'll be on vacation most of next week, so probably not until at least the week after). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/4] arm64 patch
From: David Feng feng...@phytium.com.cn The porting has been merged with arm architecture. Most architecture codes are placed in arch/arm/cpu/armv8 directory. Generic board is also supported after a few bugs are fixed. Changes for v4: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 David Feng (4): core support of arm64 board support of arm64 generic board patch of manual reloc and zero gd_t 64bit initrd start address support arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 56 arch/arm/cpu/armv8/cache.S | 145 ++ arch/arm/cpu/armv8/cache_v8.c | 291 arch/arm/cpu/armv8/config.mk| 31 +++ arch/arm/cpu/armv8/cpu.c| 68 + arch/arm/cpu/armv8/crt0.S | 130 + arch/arm/cpu/armv8/exceptions.S | 182 + arch/arm/cpu/armv8/interrupts.c | 116 arch/arm/cpu/armv8/relocate.S | 71 + arch/arm/cpu/armv8/start.S | 200 ++ arch/arm/cpu/armv8/timer.c | 95 +++ arch/arm/cpu/armv8/tlb.S| 38 +++ arch/arm/cpu/armv8/u-boot.lds | 83 ++ arch/arm/include/asm/arch-armv8/armv8.h | 44 arch/arm/include/asm/arch-armv8/gpio.h | 26 ++ arch/arm/include/asm/arch-armv8/mmu.h | 117 arch/arm/include/asm/byteorder.h| 12 + arch/arm/include/asm/config.h | 10 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 12 +- arch/arm/include/asm/macro.h| 26 ++ arch/arm/include/asm/posix_types.h | 31 +++ arch/arm/include/asm/proc-armv/ptrace.h | 38 +++ arch/arm/include/asm/proc-armv/system.h | 58 +++- arch/arm/include/asm/types.h| 14 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h| 14 + arch/arm/lib/Makefile |8 + arch/arm/lib/board.c| 18 ++ arch/arm/lib/bootm.c| 16 ++ board/armltd/dts/vexpress64.dts | 439 +++ board/armltd/vexpress64/Makefile| 43 +++ board/armltd/vexpress64/vexpress64.c| 79 ++ boards.cfg |1 + common/board_f.c| 19 +- common/board_r.c| 17 ++ common/fdt_support.c| 66 ++--- common/image.c |1 + doc/README.armv8| 14 + examples/standalone/stubs.c | 15 ++ include/configs/vexpress_aemv8a.h | 203 ++ include/image.h |1 + 43 files changed, 2816 insertions(+), 46 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/crt0.S create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/interrupts.c create mode 100644 arch/arm/cpu/armv8/relocate.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/arch-armv8/armv8.h create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h create mode 100644 arch/arm/include/asm/arch-armv8/mmu.h create mode 100644 board/armltd/dts/vexpress64.dts create mode 100644 board/armltd/vexpress64/Makefile create mode 100644 board/armltd/vexpress64/vexpress64.c create mode 100644 doc/README.armv8 create mode 100644 include/configs/vexpress_aemv8a.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/4] arm64 patch
From: David Feng feng...@phytium.com.cn The porting has been merged with arm architecture. Most architecture codes are placed in arch/arm/cpu/armv8 directory. Generic board is also supported after a few bugs are fixed. Changes for v4: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 David Feng (4): core support of arm64 board support of arm64 generic board patch of manual reloc and zero gd_t 64bit initrd start address support arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 56 arch/arm/cpu/armv8/cache.S | 145 ++ arch/arm/cpu/armv8/cache_v8.c | 291 arch/arm/cpu/armv8/config.mk| 31 +++ arch/arm/cpu/armv8/cpu.c| 68 + arch/arm/cpu/armv8/crt0.S | 130 + arch/arm/cpu/armv8/exceptions.S | 182 + arch/arm/cpu/armv8/interrupts.c | 116 arch/arm/cpu/armv8/relocate.S | 71 + arch/arm/cpu/armv8/start.S | 200 ++ arch/arm/cpu/armv8/timer.c | 95 +++ arch/arm/cpu/armv8/tlb.S| 38 +++ arch/arm/cpu/armv8/u-boot.lds | 83 ++ arch/arm/include/asm/arch-armv8/armv8.h | 44 arch/arm/include/asm/arch-armv8/gpio.h | 26 ++ arch/arm/include/asm/arch-armv8/mmu.h | 117 arch/arm/include/asm/byteorder.h| 12 + arch/arm/include/asm/config.h | 10 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 12 +- arch/arm/include/asm/macro.h| 26 ++ arch/arm/include/asm/posix_types.h | 31 +++ arch/arm/include/asm/proc-armv/ptrace.h | 38 +++ arch/arm/include/asm/proc-armv/system.h | 58 +++- arch/arm/include/asm/types.h| 14 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h| 14 + arch/arm/lib/Makefile |8 + arch/arm/lib/board.c| 18 ++ arch/arm/lib/bootm.c| 16 ++ board/armltd/dts/vexpress64.dts | 439 +++ board/armltd/vexpress64/Makefile| 43 +++ board/armltd/vexpress64/vexpress64.c| 79 ++ boards.cfg |1 + common/board_f.c| 19 +- common/board_r.c| 17 ++ common/fdt_support.c| 66 ++--- common/image.c |1 + doc/README.armv8| 14 + examples/standalone/stubs.c | 15 ++ include/configs/vexpress_aemv8a.h | 203 ++ include/image.h |1 + 43 files changed, 2816 insertions(+), 46 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/crt0.S create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/interrupts.c create mode 100644 arch/arm/cpu/armv8/relocate.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/arch-armv8/armv8.h create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h create mode 100644 arch/arm/include/asm/arch-armv8/mmu.h create mode 100644 board/armltd/dts/vexpress64.dts create mode 100644 board/armltd/vexpress64/Makefile create mode 100644 board/armltd/vexpress64/vexpress64.c create mode 100644 doc/README.armv8 create mode 100644 include/configs/vexpress_aemv8a.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/4] generic board patch of manual reloc and zero gd_t
From: David Feng feng...@phytium.com.cn
1. function board_init_f in board_f.c should firstly zero gd_t structure
before it call initcall_run_list, otherwise the debug print will go run
if DEBUG is defined. Because the printf function will use global data
to determine whether serial port is initialized and could be written.
2. function board_init_r in board_r.c should firstly relocate init_sequence_r
table before it call initcall_run_list. Command table also should be
relocated.
Signed-off-by: David Feng feng...@phytium.com.cn
---
Changes for v4:
- fix the generic board_f.c, remove zero_global_data from init_sequence_f
array
and move it to board_init_f() function with CONFIG_X86 switch. The previous
fixup is inaccurate.
common/board_f.c | 19 +--
common/board_r.c | 17 +
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..98e24c3 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -458,7 +458,11 @@ static int reserve_round_4k(void)
static int reserve_mmu(void)
{
/* reserve TLB table */
+#ifndef CONFIG_ARMV8
gd-arch.tlb_size = 4096 * 4;
+#else
+ gd-arch.tlb_size = 0x1;
+#endif
gd-relocaddr -= gd-arch.tlb_size;
/* round down to next 64 kB limit */
@@ -610,7 +614,7 @@ static int reserve_stacks(void)
* TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
* to handle this and put in arch/xxx/lib/stack.c
*/
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM) !defined(CONFIG_ARMV8)
# ifdef CONFIG_USE_IRQ
gd-start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug(Reserving %zu Bytes for IRQ stack at: %08lx\n,
@@ -807,11 +811,6 @@ static int mark_bootstage(void)
}
static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2) !defined(CONFIG_MPC512X) \
- !defined(CONFIG_MPC83xx) !defined(CONFIG_MPC85xx) \
- !defined(CONFIG_MPC86xx) !defined(CONFIG_X86)
- zero_global_data,
-#endif
#ifdef CONFIG_SANDBOX
setup_ram_buf,
#endif
@@ -1005,6 +1004,14 @@ void board_init_f(ulong boot_flags)
gd = data;
#endif
+ /*
+* Zero gd_t first, otherwise the debug print in initcall_run_list
+* function before zero_global_data is called will go wrong.
+*/
+#ifndef CONFIG_X86
+ zero_global_data();
+#endif
+
gd-flags = boot_flags;
if (initcall_run_list(init_sequence_f))
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..1b4bdd2 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -157,6 +157,13 @@ static int initr_reloc_global_data(void)
*/
gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the command table manually
+*/
+ fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),
+ ll_entry_count(cmd_tbl_t, cmd));
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
return 0;
}
@@ -899,6 +906,7 @@ init_fnc_t init_sequence_r[] = {
initr_modem,
#endif
run_main_loop,
+ NULL,
};
void board_init_r(gd_t *new_gd, ulong dest_addr)
@@ -906,6 +914,15 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
#ifndef CONFIG_X86
gd = new_gd;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the init_sequence_r table manually
+*/
+ init_fnc_t *init_fnc_ptr;
+ for (init_fnc_ptr = init_sequence_r; *init_fnc_ptr; ++init_fnc_ptr)
+ *init_fnc_ptr = (init_fnc_t *)((unsigned long)(*init_fnc_ptr) +
gd-reloc_off);
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/4] generic board patch of manual reloc and zero gd_t
From: David Feng feng...@phytium.com.cn
1. function board_init_f in board_f.c should firstly zero gd_t structure
before it call initcall_run_list, otherwise the debug print will go run
if DEBUG is defined. Because the printf function will use global data
to determine whether serial port is initialized and could be written.
2. function board_init_r in board_r.c should firstly relocate init_sequence_r
table before it call initcall_run_list. Command table also should be
relocated.
Signed-off-by: David Feng feng...@phytium.com.cn
---
Changes for v4:
- fix the generic board_f.c, remove zero_global_data from init_sequence_f
array
and move it to board_init_f() function with CONFIG_X86 switch. The previous
fixup is inaccurate.
common/board_f.c | 19 +--
common/board_r.c | 17 +
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..98e24c3 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -458,7 +458,11 @@ static int reserve_round_4k(void)
static int reserve_mmu(void)
{
/* reserve TLB table */
+#ifndef CONFIG_ARMV8
gd-arch.tlb_size = 4096 * 4;
+#else
+ gd-arch.tlb_size = 0x1;
+#endif
gd-relocaddr -= gd-arch.tlb_size;
/* round down to next 64 kB limit */
@@ -610,7 +614,7 @@ static int reserve_stacks(void)
* TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
* to handle this and put in arch/xxx/lib/stack.c
*/
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM) !defined(CONFIG_ARMV8)
# ifdef CONFIG_USE_IRQ
gd-start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug(Reserving %zu Bytes for IRQ stack at: %08lx\n,
@@ -807,11 +811,6 @@ static int mark_bootstage(void)
}
static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2) !defined(CONFIG_MPC512X) \
- !defined(CONFIG_MPC83xx) !defined(CONFIG_MPC85xx) \
- !defined(CONFIG_MPC86xx) !defined(CONFIG_X86)
- zero_global_data,
-#endif
#ifdef CONFIG_SANDBOX
setup_ram_buf,
#endif
@@ -1005,6 +1004,14 @@ void board_init_f(ulong boot_flags)
gd = data;
#endif
+ /*
+* Zero gd_t first, otherwise the debug print in initcall_run_list
+* function before zero_global_data is called will go wrong.
+*/
+#ifndef CONFIG_X86
+ zero_global_data();
+#endif
+
gd-flags = boot_flags;
if (initcall_run_list(init_sequence_f))
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..1b4bdd2 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -157,6 +157,13 @@ static int initr_reloc_global_data(void)
*/
gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the command table manually
+*/
+ fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),
+ ll_entry_count(cmd_tbl_t, cmd));
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
return 0;
}
@@ -899,6 +906,7 @@ init_fnc_t init_sequence_r[] = {
initr_modem,
#endif
run_main_loop,
+ NULL,
};
void board_init_r(gd_t *new_gd, ulong dest_addr)
@@ -906,6 +914,15 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
#ifndef CONFIG_X86
gd = new_gd;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the init_sequence_r table manually
+*/
+ init_fnc_t *init_fnc_ptr;
+ for (init_fnc_ptr = init_sequence_r; *init_fnc_ptr; ++init_fnc_ptr)
+ *init_fnc_ptr = (init_fnc_t *)((unsigned long)(*init_fnc_ptr) +
gd-reloc_off);
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/4] board support of arm64
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
Changes for v4:
- No
board/armltd/dts/vexpress64.dts | 439 ++
board/armltd/vexpress64/Makefile | 43
board/armltd/vexpress64/vexpress64.c | 79 ++
boards.cfg |1 +
include/configs/vexpress_aemv8a.h| 203
5 files changed, 765 insertions(+)
create mode 100644 board/armltd/dts/vexpress64.dts
create mode 100644 board/armltd/vexpress64/Makefile
create mode 100644 board/armltd/vexpress64/vexpress64.c
create mode 100644 include/configs/vexpress_aemv8a.h
diff --git a/board/armltd/dts/vexpress64.dts b/board/armltd/dts/vexpress64.dts
new file mode 100644
index 000..067fea7
--- /dev/null
+++ b/board/armltd/dts/vexpress64.dts
@@ -0,0 +1,439 @@
+/*
+ * ARM Ltd. Fast Models
+ *
+ * Architecture Envelope Model (AEM) ARMv8-A
+ * ARMAEMv8AMPCT
+ *
+ * RTSM_VE_AEMv8A.lisa
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ /* boot configurations for u-boot */
+ config {
+ /*bootdelay = 1;*/
+ kernel-offset = 0x10;
+ rootdisk-offset = 0x80;
+ bootcmd = bootm 0x10 0x80:0x200;
+ };
+};
+
+/ {
+ model = RTSM_VE_AEMv8A;
+ compatible = arm,rtsm_ve,aemv8a, arm,vexpress;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ /* chosen */
+ /* generated by u-boot */
+
+
+ aliases {
+ serial0 = v2m_serial0;
+ serial1 = v2m_serial1;
+ serial2 = v2m_serial2;
+ serial3 = v2m_serial3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 1;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 2;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 3;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000,
+ 0x0008 0x8000 0 0x8000;
+ };
+
+ gic: interrupt-controller@2c001000 {
+ compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x0 0x2c001000 0 0x1000,
+ 0x0 0x2c002000 0 0x1000,
+ 0x0 0x2c004000 0 0x2000,
+ 0x0 0x2c006000 0 0x2000;
+ interrupts = 1 9 0xf04;
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
+ clock-frequency = 1;
+ };
+
+ pmu {
+ compatible = arm,armv8-pmuv3;
+ interrupts = 0 60 4,
+0 61 4,
+0 62 4,
+0 63 4;
+ };
+
+ smb {
+ compatible = simple-bus;
+
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0 0x0800 0x0400,
+1 0 0 0x1400 0x0400,
+2 0 0 0x1800 0x0400,
+3 0 0 0x1c00 0x0400,
+4 0 0 0x0c00 0x0400,
+5 0 0 0x1000 0x0400;
+
+ #interrupt-cells = 1;
+ interrupt-map-mask = 0 0 63;
+ interrupt-map = 0 0 0 gic 0 0 4,
+ 0 0 1 gic 0 1 4,
+ 0 0 2 gic 0 2 4,
+ 0 0 3 gic 0 3 4,
+ 0 0 4 gic 0 4 4,
+ 0 0 5 gic 0 5 4,
+ 0 0 6 gic 0 6
[U-Boot] [PATCH v5 4/4] 64bit initrd start address support
From: David Feng feng...@phytium.com.cn
This patch fix the fdt_initrd function.
It will get #adress_cells property fisrt, then write linux,initrd-start
and linux,initrd-end property value to fdt according to address cell size
such that the 64bit initrd start address could be supported.
Signed-off-by: David Feng feng...@phytium.com.cn
---
Changes for v4:
- No
common/fdt_support.c | 66 ++
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..9bc5821 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
*/
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+ const fdt32_t *cell;
+
+ cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+ if (cell fdt32_to_cpu(*cell) == 2)
+ return 8;
+
+ return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+ int shift = (size - 1) * 8;
+ while (size-- 0) {
+ *addr++ = (val shift) 0xff;
+ shift -= 8;
+ }
+}
+
/**
* fdt_getprop_u32_default - Find a node and return it's property or a default
*
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
{
- int nodeoffset;
+ int nodeoffset, addr_cell_len;
int err, j, total;
- fdt32_t tmp;
+ fdt64_t tmp;
const char *path;
uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
return err;
}
+ addr_cell_len = get_cells_len(fdt, #address-cells);
+
path = fdt_getprop(fdt, nodeoffset, linux,initrd-start, NULL);
if ((path == NULL) || force) {
- tmp = cpu_to_fdt32(initrd_start);
+ write_cell((u8 *)tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-start, tmp, sizeof(tmp));
if (err 0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
fdt_strerror(err));
return err;
}
- tmp = cpu_to_fdt32(initrd_end);
+ write_cell((u8 *)tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-end, tmp, sizeof(tmp));
if (err 0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, tmp, 4, create);
}
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
- const fdt32_t *cell;
-
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell fdt32_to_cpu(*cell) == 2)
- return 8;
-
- return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
- int shift = (size - 1) * 8;
- while (size-- 0) {
- *addr++ = (val shift) 0xff;
- shift -= 8;
- }
-}
-
#ifdef CONFIG_NR_DRAM_BANKS
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/4] board support of arm64
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
board/armltd/dts/vexpress64.dts | 439 ++
board/armltd/vexpress64/Makefile | 43
board/armltd/vexpress64/vexpress64.c | 79 ++
boards.cfg |1 +
include/configs/vexpress_aemv8a.h| 203
5 files changed, 765 insertions(+)
create mode 100644 board/armltd/dts/vexpress64.dts
create mode 100644 board/armltd/vexpress64/Makefile
create mode 100644 board/armltd/vexpress64/vexpress64.c
create mode 100644 include/configs/vexpress_aemv8a.h
diff --git a/board/armltd/dts/vexpress64.dts b/board/armltd/dts/vexpress64.dts
new file mode 100644
index 000..067fea7
--- /dev/null
+++ b/board/armltd/dts/vexpress64.dts
@@ -0,0 +1,439 @@
+/*
+ * ARM Ltd. Fast Models
+ *
+ * Architecture Envelope Model (AEM) ARMv8-A
+ * ARMAEMv8AMPCT
+ *
+ * RTSM_VE_AEMv8A.lisa
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ /* boot configurations for u-boot */
+ config {
+ /*bootdelay = 1;*/
+ kernel-offset = 0x10;
+ rootdisk-offset = 0x80;
+ bootcmd = bootm 0x10 0x80:0x200;
+ };
+};
+
+/ {
+ model = RTSM_VE_AEMv8A;
+ compatible = arm,rtsm_ve,aemv8a, arm,vexpress;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ /* chosen */
+ /* generated by u-boot */
+
+
+ aliases {
+ serial0 = v2m_serial0;
+ serial1 = v2m_serial1;
+ serial2 = v2m_serial2;
+ serial3 = v2m_serial3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 1;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 2;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 3;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000,
+ 0x0008 0x8000 0 0x8000;
+ };
+
+ gic: interrupt-controller@2c001000 {
+ compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x0 0x2c001000 0 0x1000,
+ 0x0 0x2c002000 0 0x1000,
+ 0x0 0x2c004000 0 0x2000,
+ 0x0 0x2c006000 0 0x2000;
+ interrupts = 1 9 0xf04;
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
+ clock-frequency = 1;
+ };
+
+ pmu {
+ compatible = arm,armv8-pmuv3;
+ interrupts = 0 60 4,
+0 61 4,
+0 62 4,
+0 63 4;
+ };
+
+ smb {
+ compatible = simple-bus;
+
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0 0x0800 0x0400,
+1 0 0 0x1400 0x0400,
+2 0 0 0x1800 0x0400,
+3 0 0 0x1c00 0x0400,
+4 0 0 0x0c00 0x0400,
+5 0 0 0x1000 0x0400;
+
+ #interrupt-cells = 1;
+ interrupt-map-mask = 0 0 63;
+ interrupt-map = 0 0 0 gic 0 0 4,
+ 0 0 1 gic 0 1 4,
+ 0 0 2 gic 0 2 4,
+ 0 0 3 gic 0 3 4,
+ 0 0 4 gic 0 4 4,
+ 0 0 5 gic 0 5 4,
+ 0 0 6 gic 0 6 4,
+
[U-Boot] [PATCH v5 4/4] 64bit initrd start address support
From: David Feng feng...@phytium.com.cn
This patch fix the fdt_initrd function.
It will get #adress_cells property fisrt, then write linux,initrd-start
and linux,initrd-end property value to fdt according to address cell size
such that the 64bit initrd start address could be supported.
Signed-off-by: David Feng feng...@phytium.com.cn
---
Changes for v4:
- No
common/fdt_support.c | 66 ++
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..9bc5821 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
*/
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+ const fdt32_t *cell;
+
+ cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+ if (cell fdt32_to_cpu(*cell) == 2)
+ return 8;
+
+ return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+ int shift = (size - 1) * 8;
+ while (size-- 0) {
+ *addr++ = (val shift) 0xff;
+ shift -= 8;
+ }
+}
+
/**
* fdt_getprop_u32_default - Find a node and return it's property or a default
*
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
{
- int nodeoffset;
+ int nodeoffset, addr_cell_len;
int err, j, total;
- fdt32_t tmp;
+ fdt64_t tmp;
const char *path;
uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
return err;
}
+ addr_cell_len = get_cells_len(fdt, #address-cells);
+
path = fdt_getprop(fdt, nodeoffset, linux,initrd-start, NULL);
if ((path == NULL) || force) {
- tmp = cpu_to_fdt32(initrd_start);
+ write_cell((u8 *)tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-start, tmp, sizeof(tmp));
if (err 0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
fdt_strerror(err));
return err;
}
- tmp = cpu_to_fdt32(initrd_end);
+ write_cell((u8 *)tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-end, tmp, sizeof(tmp));
if (err 0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, tmp, 4, create);
}
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
- const fdt32_t *cell;
-
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell fdt32_to_cpu(*cell) == 2)
- return 8;
-
- return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
- int shift = (size - 1) * 8;
- while (size-- 0) {
- *addr++ = (val shift) 0xff;
- shift -= 8;
- }
-}
-
#ifdef CONFIG_NR_DRAM_BANKS
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
--
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 v4 3/4] generic board patch of manual reloc and zero gd_t
-原始邮件- 发件人: Scott Wood scottw...@freescale.com 发送时间: 2013年8月24日 星期六 收件人: Simon Glass s...@chromium.org 抄送: FengHua feng...@phytium.com.cn, trini tr...@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Fri, 2013-08-23 at 18:12 -0600, Simon Glass wrote: Hi, On Thu, Aug 22, 2013 at 8:55 AM, FengHua feng...@phytium.com.cn wrote: On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote: -- ?: Scott Wood scottw...@freescale.com : 2013???8???22??? ? ?: Simon Glass s...@chromium.org ??: FengHua feng...@phytium.com.cn, tr...@ti.com tr...@ti.com, U-Boot Mailing List u-boot@lists.denx.de ??: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote: Hi David, On Tue, Aug 20, 2013 at 4:48 AM, feng...@phytium.com.cn wrote: diff --git a/common/board_r.c b/common/board_r.c index 86ca1cb..1b4bdd2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) */ gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE; #endif +#ifdef CONFIG_NEEDS_MANUAL_RELOC + /* +* We have to relocate the command table manually +*/ + fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd), + ll_entry_count(cmd_tbl_t, cmd)); +#endif /* CONFIG_NEEDS_MANUAL_RELOC */ Should this be done here or in main_loop()? How is this currently done when not using generic board? It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working. Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation. No, the point is that manual relocation is legacy and new platforms should be using proper relocation. Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem. Possible there is a new relocation type that you need to support? Yes, it's rela instead of rel. FengHua claimed to have run into problems supporting it; I'll try to debug it hopefully somewhat soon (though I'll be on vacation most of next week, so probably not until at least the week after). -Scott hi scott, I am looking forward to your result. In my knowledge, the RELA format relocation has no initial addend encoded. So application should be relocated before it runs. But u-boot make the relocation during it's running, it can not reference global variables and functions before it is copied to RAM and relocated. I don't know how to encode the initial addend to variables. Wish you make it! br, david ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can u-boot tools fw_{printenv, setenv} work with eMMC HW partition?
On Sat, 24 Aug 2013, Luka Perkov wrote:
On Fri, Aug 23, 2013 at 05:11:01PM -0400, Robert P. J. Day wrote:
On Fri, 23 Aug 2013, Luka Perkov wrote:
On Fri, Aug 23, 2013 at 08:25:07AM -0400, Robert P. J. Day wrote:
i'm sure there's a simple answer to this -- i built u-boot for my
beaglebone black using the am335x_boneblack config, which supports
saving env info to the eMMC HW partition boot1. but now that it's
there, is there a way i can manipulate that info with fw_printenv and
fw_setenv?
I have put this in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/110-add-support-for-MTD_ABSENT.patch
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/patches/115-writing-environment-for-mtd-devices.patch
With those two you will be able to use fw_{printenv,setenv} on MMC
devices.
i'll get a chance to test the above this weekend, but i just want to
make absolutely sure we're talking about the same thing. are you
saying that with the above patches, the u-boot-tools will be able to
manipulate an eMMC HW partition just as easily as a regular MTD
partition?
Yes.
and, if so, what is the format of the entry one would add
to /etc/fw_env.config to refer to that eMMC HW partition (in this
case, boot1)?
I have done this for imx6 wandboard in OpenWrt:
https://dev.openwrt.org/browser/trunk/package/boot/uboot-envtools/files/imx6
So example config would look like:
/dev/mmcblk0 0x6 0x2000 0x2000
ah, there's the misunderstanding. i thought we were discussing how
to be able to refer *directly* to the eMMC partition boot1, as in
/dev/mmcblk1boot1. it looks like what you're describing would refer
instead simply to /dev/mmcblk1, correct?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
From: Tom Rini [tom.r...@gmail.com] on behalf of Rini, Tom Sent: Saturday, August 24, 2013 3:49 AM To: Gupta, Pekon Cc: scottw...@freescale.com; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2 0/4] mtd: nand: omap: optimize and clean-up of OMAP NAND driver On Wed, Aug 14, 2013 at 11:46:51AM +0530, Pekon Gupta wrote: [changes in v2] - added documentation for CONFIG_NAND_OMAP_xx in doc/README.nand - added CONFIG_BCH along with CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW to include software library lib/bch.c - fixed board_nand_init() and omap_enable_hwecc() [Original v1] This patch series updates BCH8_ECC schemes in mtd/nand/omap_gpmc.c driver - adds scalability for higher ECC schemes in future. - removes CONFIG_AM335x and it makes it generic for all platforms. - optimizes read_data paths This series is tested for H/W BCH8_ECC scheme on - AM335x_EVM and TI814x_EVM Pekon Gupta (4): [PATCH 1/4] mtd: nand: omap: enable BCH ECC scheme usinmg ELM for generic platform [PATCH 2/4] mtd: nand: omap: optimize chip-ecc.hwctl() for H/W ECC schemes [PATCH 3/4] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes [PATCH 4/4] mtd: nand: omap: optimized chip-ecc.correct() for H/W ECC schemes doc/README.nand | 20 ++ drivers/mtd/nand/omap_gpmc.c | 514 +++ include/configs/am335x_evm.h | 1 + include/configs/ti814x_evm.h | 2 +- include/configs/tricorder.h | 2 +- 5 files changed, 203 insertions(+), 336 deletions(-) Series looks good to me, I'll pick these up soon, after I test them on beagle as well. -- Tom Thanks Scott and Tom for reviews.. - I just realized few minor cleanup that could help in future. - Also, I'll split the patch-set for AM335x and TI814x boards so that they can be independently tested. So plz wait as I'll post a v3 for this and TI814x series soon, and then may be you can verify them independently. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
