[U-Boot] [PATCH 0/4] fix and update LP-8x4x to boot DTS kernel
Linux kernel maintainers require new machnines to support device tree boot. The config for LP-8x4x needs updating.
In addition, there are a few fixes to board's configuration.
Sergei Ianovich (4): ARM: pxa: prevent PXA270 occasional reboot freezes arm: pxa: always init ethaddr for LP-8x4x arm: pxa: fix 2nd flash chip address on LP-8x4x arm: pxa: update LP-8x4x to boot DTS kernel
arch/arm/cpu/pxa/pxa2xx.c | 2 +- board/icpdas/lp8x4x/lp8x4x.c | 8 ++++++++ include/configs/lp8x4x.h | 12 ++++++------ 3 files changed, 15 insertions(+), 7 deletions(-)
Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and the device hangs.
We put SDRAM in selfresh mode before watchdog reset, removing potential freezes.
Signed-off-by: Sergei Ianovich ynvich@gmail.com --- arch/arm/cpu/pxa/pxa2xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c index c9a7d45..93ca2f0 100644 --- a/arch/arm/cpu/pxa/pxa2xx.c +++ b/arch/arm/cpu/pxa/pxa2xx.c @@ -281,5 +281,5 @@ void reset_cpu(ulong ignored) writel(tmp, OSMR3);
for (;;) - ; + writel(MDREFR_SLFRSH, MDREFR); }
On Saturday, December 14, 2013 at 06:41:57 AM, Sergei Ianovich wrote:
Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and the device hangs.
We put SDRAM in selfresh mode before watchdog reset, removing potential freezes.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
arch/arm/cpu/pxa/pxa2xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c index c9a7d45..93ca2f0 100644 --- a/arch/arm/cpu/pxa/pxa2xx.c +++ b/arch/arm/cpu/pxa/pxa2xx.c @@ -281,5 +281,5 @@ void reset_cpu(ulong ignored) writel(tmp, OSMR3);
for (;;)
;
writel(MDREFR_SLFRSH, MDREFR);
Do you need to write this register in an endless loop ?
}
Best regards, Marek Vasut
On Sat, 2013-12-14 at 13:29 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 06:41:57 AM, Sergei Ianovich wrote:
Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and the device hangs.
We put SDRAM in selfresh mode before watchdog reset, removing potential freezes.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
arch/arm/cpu/pxa/pxa2xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c index c9a7d45..93ca2f0 100644 --- a/arch/arm/cpu/pxa/pxa2xx.c +++ b/arch/arm/cpu/pxa/pxa2xx.c @@ -281,5 +281,5 @@ void reset_cpu(ulong ignored) writel(tmp, OSMR3);
for (;;)
;
writel(MDREFR_SLFRSH, MDREFR);Do you need to write this register in an endless loop ?
I didn't think this way. We need to have at least 3, but up to 5 cycles to put SDRAM in SLFRFRSH. It depends on the current state of SDRAM. There is no way to know.
It can probably work if we write just once. But if we have another thread doing something with SDRAM in between, we will still hang. I am not sure how likely is the situation, though.
On Saturday, December 14, 2013 at 04:31:31 PM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 13:29 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 06:41:57 AM, Sergei Ianovich wrote:
Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and the device hangs.
We put SDRAM in selfresh mode before watchdog reset, removing potential freezes.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
arch/arm/cpu/pxa/pxa2xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c index c9a7d45..93ca2f0 100644 --- a/arch/arm/cpu/pxa/pxa2xx.c +++ b/arch/arm/cpu/pxa/pxa2xx.c @@ -281,5 +281,5 @@ void reset_cpu(ulong ignored)
writel(tmp, OSMR3); for (;;)
;
writel(MDREFR_SLFRSH, MDREFR);Do you need to write this register in an endless loop ?
I didn't think this way. We need to have at least 3, but up to 5 cycles to put SDRAM in SLFRFRSH. It depends on the current state of SDRAM. There is no way to know.
OK, I seem to remember the uglinesses of the PXA DRAM controller, indeed :(
It can probably work if we write just once. But if we have another thread doing something with SDRAM in between, we will still hang.
U-Boot is single-threaded ;-)
I am not sure how likely is the situation, though.
It cannot happen, really ;-)
BUT (!) I understand your intention. If writing the MDREFR multiple times won't be a problem, I am _not_ opposed to this patch. So please only make sure that's not a problem and if it's not, I won't block this patch.
Thank you very much for your efforts on the PXA front !
Best regards, Marek Vasut
On Sat, 2013-12-14 at 18:14 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 04:31:31 PM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 13:29 +0100, Marek Vasut wrote:
Do you need to write this register in an endless loop ?
I didn't think this way. We need to have at least 3, but up to 5 cycles to put SDRAM in SLFRFRSH. It depends on the current state of SDRAM. There is no way to know.
OK, I seem to remember the uglinesses of the PXA DRAM controller, indeed :(
It can probably work if we write just once. But if we have another thread doing something with SDRAM in between, we will still hang.
U-Boot is single-threaded ;-)
I am not sure how likely is the situation, though.
It cannot happen, really ;-)
BUT (!) I understand your intention. If writing the MDREFR multiple times won't be a problem, I am _not_ opposed to this patch. So please only make sure that's not a problem and if it's not, I won't block this patch.
The relevant doc is [1, section 6.1.5.4]. Refresh rules are rather complex. However, clearing DRI and repeatedly writing to MDREFR should refresh. The refreshes should advance SDRAM state machine to "Self-refresh and Clock-stop". This is what we are trying to achieve.
I've run close to 1000 reboot of patched linux kernel. This mean several billions writes to MDREFR. If a write can cause a problem, it should have already shown up. So I think it is not a problem.
Nevertheless, I've put a patched U-Boot with a single write to MDREFR to test (reset every 2 sec). After several hours, it will be clear, if a single write works. Let's do it the right way.
1. http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_...
On Sunday, December 15, 2013 at 12:51:44 AM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 18:14 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 04:31:31 PM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 13:29 +0100, Marek Vasut wrote:
Do you need to write this register in an endless loop ?
I didn't think this way. We need to have at least 3, but up to 5 cycles to put SDRAM in SLFRFRSH. It depends on the current state of SDRAM. There is no way to know.
OK, I seem to remember the uglinesses of the PXA DRAM controller, indeed :(
It can probably work if we write just once. But if we have another thread doing something with SDRAM in between, we will still hang.
U-Boot is single-threaded ;-)
I am not sure how likely is the situation, though.
It cannot happen, really ;-)
BUT (!) I understand your intention. If writing the MDREFR multiple times won't be a problem, I am _not_ opposed to this patch. So please only make sure that's not a problem and if it's not, I won't block this patch.
The relevant doc is [1, section 6.1.5.4]. Refresh rules are rather complex. However, clearing DRI and repeatedly writing to MDREFR should refresh. The refreshes should advance SDRAM state machine to "Self-refresh and Clock-stop". This is what we are trying to achieve.
I've run close to 1000 reboot of patched linux kernel. This mean several billions writes to MDREFR. If a write can cause a problem, it should have already shown up. So I think it is not a problem.
I saw this kernel patch, yes.
Nevertheless, I've put a patched U-Boot with a single write to MDREFR to test (reset every 2 sec). After several hours, it will be clear, if a single write works. Let's do it the right way.
Thank you !
http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_de v_man.pdf
Best regards, Marek Vasut
On Sun, 2013-12-15 at 06:17 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 12:51:44 AM, Sergei Ianovich wrote:
Nevertheless, I've put a patched U-Boot with a single write to MDREFR to test (reset every 2 sec). After several hours, it will be clear, if a single write works. Let's do it the right way.
It works with a single write. I'll post v2 to the series.
Thanks for constructive reviewing.
On Sunday, December 15, 2013 at 10:48:16 AM, Sergei Ianovich wrote:
On Sun, 2013-12-15 at 06:17 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 12:51:44 AM, Sergei Ianovich wrote:
Nevertheless, I've put a patched U-Boot with a single write to MDREFR to test (reset every 2 sec). After several hours, it will be clear, if a single write works. Let's do it the right way.
It works with a single write. I'll post v2 to the series.
Thanks for constructive reviewing.
No, thank _you_ for the efforts!
Best regards, Marek Vasut
I always used tftp in my test, so the first dm9000 on LP-8x4x was always properly initialized. However, if the boot doesn't include network related commands, linux will not find a valid MAC and will complain.
No longer.
Signed-off-by: Sergei Ianovich ynvich@gmail.com --- board/icpdas/lp8x4x/lp8x4x.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c index 1b68ef3..8396caa 100644 --- a/board/icpdas/lp8x4x/lp8x4x.c +++ b/board/icpdas/lp8x4x/lp8x4x.c @@ -112,10 +112,18 @@ void usb_board_stop(void) #ifdef CONFIG_DRIVER_DM9000 void lp8x4x_eth1_mac_init(void) { + u8 ethaddr[8]; u8 eth1addr[8]; int i; u8 reg;
+ eth_getenv_enetaddr_by_index("eth", 0, ethaddr); + if (is_valid_ether_addr(ethaddr)) { + for (i = 0, reg = 0x10; i < 6; i++, reg++) { + writeb(reg, (u8 *)(DM9000_IO)); + writeb(ethaddr[i], (u8 *)(DM9000_DATA)); + } + } eth_getenv_enetaddr_by_index("eth", 1, eth1addr); if (!is_valid_ether_addr(eth1addr)) return;
On Saturday, December 14, 2013 at 06:41:58 AM, Sergei Ianovich wrote:
I always used tftp in my test, so the first dm9000 on LP-8x4x was always properly initialized. However, if the boot doesn't include network related commands, linux will not find a valid MAC and will complain.
No longer.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
board/icpdas/lp8x4x/lp8x4x.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c index 1b68ef3..8396caa 100644 --- a/board/icpdas/lp8x4x/lp8x4x.c +++ b/board/icpdas/lp8x4x/lp8x4x.c @@ -112,10 +112,18 @@ void usb_board_stop(void) #ifdef CONFIG_DRIVER_DM9000 void lp8x4x_eth1_mac_init(void) {
u8 ethaddr[8]; u8 eth1addr[8]; int i; u8 reg;
eth_getenv_enetaddr_by_index("eth", 0, ethaddr);
if (is_valid_ether_addr(ethaddr)) {
for (i = 0, reg = 0x10; i < 6; i++, reg++) {writeb(reg, (u8 *)(DM9000_IO));writeb(ethaddr[i], (u8 *)(DM9000_DATA));}} eth_getenv_enetaddr_by_index("eth", 1, eth1addr); if (!is_valid_ether_addr(eth1addr)) return;
Please pass the ethernet address via DT, will that not work for you ?
Best regards, Marek Vasut
On Sat, 2013-12-14 at 13:30 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 06:41:58 AM, Sergei Ianovich wrote:
I always used tftp in my test, so the first dm9000 on LP-8x4x was always properly initialized. However, if the boot doesn't include network related commands, linux will not find a valid MAC and will complain.
Please pass the ethernet address via DT, will that not work for you ?
This will require a custom dtb object for every device recompiled every time kernel is upgraded. The current way is to set once per device in U-Boot environment variable, which doesn't need to change if kernel changes.
I strongly believe the current way is easier.
On Saturday, December 14, 2013 at 04:39:00 PM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 13:30 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 06:41:58 AM, Sergei Ianovich wrote:
I always used tftp in my test, so the first dm9000 on LP-8x4x was always properly initialized. However, if the boot doesn't include network related commands, linux will not find a valid MAC and will complain.
Please pass the ethernet address via DT, will that not work for you ?
This will require a custom dtb object for every device recompiled every time kernel is upgraded. The current way is to set once per device in U-Boot environment variable, which doesn't need to change if kernel changes.
I strongly believe the current way is easier.
I disagree :)
IF you set 'ethaddr' variable in U-Boot THEN U-Boot will patch this 'ethaddr' value into your DT. The /aliases/ethernet0 node will be augmented with a new property 'local-mac-address', which will contain the MAC address from 'ethaddr' . The kernel will use this as the MAC address for that particular ethernet interface afterwards.
NOTE: It is very important to have the alias set, it has to point to your ethernet device. A good example in Linux's arch/arm/boot/dts/imx28.dtsi, which even has two ethernet interfaces. Notice each of them has an alias. NOTE: If you have two interfaces, then 'eth1addr' is patches into /aliases/ethernet1 etc.
The only problem here is the non-DT kernel. Do you need to support that? Is there no other way to pass MAC address of an ethernet interface to Linux but programming it into the ethernet interface itself ?
Best regards, Marek Vasut
On Sat, 2013-12-14 at 18:12 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 04:39:00 PM, Sergei Ianovich wrote:
I strongly believe the current way is easier.
I disagree :)
IF you set 'ethaddr' variable in U-Boot THEN U-Boot will patch this 'ethaddr' value into your DT. The /aliases/ethernet0 node will be augmented with a new property 'local-mac-address', which will contain the MAC address from 'ethaddr' . The kernel will use this as the MAC address for that particular ethernet interface afterwards.
NOTE: It is very important to have the alias set, it has to point to your ethernet device. A good example in Linux's arch/arm/boot/dts/imx28.dtsi, which even has two ethernet interfaces. Notice each of them has an alias. NOTE: If you have two interfaces, then 'eth1addr' is patches into /aliases/ethernet1 etc.
Thanks for explaining. It works. This is COOL!
The only problem here is the non-DT kernel. Do you need to support that? Is there no other way to pass MAC address of an ethernet interface to Linux but programming it into the ethernet interface itself ?
Hardware vendor uses U-Boot environment values to init MAC-addresses. I think it is even worse than what I was doing in the patch.
I don't think we need to support non-DT kernel. So we drop the patch.
On Saturday, December 14, 2013 at 09:53:48 PM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 18:12 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 04:39:00 PM, Sergei Ianovich wrote:
I strongly believe the current way is easier.
I disagree :)
IF you set 'ethaddr' variable in U-Boot THEN
U-Boot will patch this 'ethaddr' value into your DT. The /aliases/ethernet0 node will be augmented with a new property 'local-mac-address', which will contain the MAC address from 'ethaddr' . The kernel will use this as the MAC address for that particular ethernet interface afterwards.
NOTE: It is very important to have the alias set, it has to point to your ethernet device. A good example in Linux's arch/arm/boot/dts/imx28.dtsi, which even has two ethernet interfaces. Notice each of them has an alias. NOTE: If you have two interfaces, then 'eth1addr' is patches into /aliases/ethernet1 etc.
Thanks for explaining. It works. This is COOL!
Glad it helps :)
The only problem here is the non-DT kernel. Do you need to support that? Is there no other way to pass MAC address of an ethernet interface to Linux but programming it into the ethernet interface itself ?
Hardware vendor uses U-Boot environment values to init MAC-addresses. I think it is even worse than what I was doing in the patch.
I don't think we need to support non-DT kernel. So we drop the patch.
OK, that's nice :)
Best regards, Marek Vasut
On Sat, 2013-12-14 at 21:57 +0100, Marek Vasut wrote:
I don't think we need to support non-DT kernel. So we drop the patch.
OK, that's nice :)
It may even make sense to remove the code that initializes eth1, right?
On Sunday, December 15, 2013 at 12:53:18 AM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 21:57 +0100, Marek Vasut wrote:
I don't think we need to support non-DT kernel. So we drop the patch.
OK, that's nice :)
It may even make sense to remove the code that initializes eth1, right?
Which code?
Best regards, Marek Vasut
On Sun, 2013-12-15 at 06:17 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 12:53:18 AM, Sergei Ianovich wrote:
It may even make sense to remove the code that initializes eth1, right?
Which code?
I mean:
lp8x4x_eth1_mac_init() in board/icpdas/lp8x4x/lp8x4x.c
and its invocation in board_eth_init()
On Sunday, December 15, 2013 at 10:44:06 AM, Sergei Ianovich wrote:
On Sun, 2013-12-15 at 06:17 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 12:53:18 AM, Sergei Ianovich wrote:
It may even make sense to remove the code that initializes eth1, right?
Which code?
I mean:
lp8x4x_eth1_mac_init() in board/icpdas/lp8x4x/lp8x4x.c
and its invocation in board_eth_init()
Heh, yes. The DT will solve it through the ethernet1 alias, just set the eth1addr and test it to make sure please.
Best regards, Marek Vasut
On Sun, 2013-12-15 at 16:05 +0100, Marek Vasut wrote:
Heh, yes. The DT will solve it through the ethernet1 alias, just set the eth1addr and test it to make sure please.
It works. I've updated the dts in kernel for next version of patch series.
I will update this patch for v2.
Initial configuration has worng address of the second chip. There is an alias for the 1st chip at 0x02000000 in earlier verions of LP-8x4x, so the boot normally.
However, new LP-8x4xs have a bigger 1st flash chip, and hang on boot without this patch.
Signed-off-by: Sergei Ianovich ynvich@gmail.com --- include/configs/lp8x4x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 6df6f2b..55658ab 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -150,7 +150,7 @@ #define CONFIG_ENV_SECT_SIZE 0x40000
#define PHYS_FLASH_1 0x00000000 /* Flash Bank #1 */ -#define PHYS_FLASH_2 0x02000000 /* Flash Bank #2 */ +#define PHYS_FLASH_2 0x04000000 /* Flash Bank #2 */
#define CONFIG_SYS_FLASH_CFI #define CONFIG_FLASH_CFI_DRIVER 1
The device has only 256 kiB for U-Boot binary.
Binary size exceeds 256 kiB after activating CONFIG_OF_LIBFDT, so we disable USB support which was not working anyway.
Disabled USD frees more space than libfdt requires, so activate long command line help.
Signed-off-by: Sergei Ianovich ynvich@gmail.com --- include/configs/lp8x4x.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 55658ab..16c8c03 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -20,18 +20,18 @@ #define CONFIG_SYS_MALLOC_LEN (128*1024) #define CONFIG_ARCH_CPU_INIT #define CONFIG_BOOTCOMMAND \ - "bootm 80000;" + "bootm 80000 - 240000;"
#define CONFIG_BOOTARGS \ "console=ttySA0,115200 mem=128M root=/dev/mmcblk0p1 rw" \ - "init=/sbin/init rootfstype=ext3" + "init=/sbin/init rootfstype=ext4 rootwait"
#define CONFIG_TIMESTAMP #define CONFIG_BOOTDELAY 2 /* Autoboot delay */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_LZMA /* LZMA compression support */ -#undef CONFIG_OF_LIBFDT +#define CONFIG_OF_LIBFDT
/* * Serial Console Configuration @@ -50,7 +50,7 @@ #define CONFIG_CMD_ENV #undef CONFIG_CMD_IMLS #define CONFIG_CMD_MMC -#define CONFIG_CMD_USB +#undef CONFIG_CMD_USB #undef CONFIG_LCD #undef CONFIG_CMD_IDE
@@ -101,7 +101,7 @@ */ #define CONFIG_SYS_HUSH_PARSER 1
-#undef CONFIG_SYS_LONGHELP +#define CONFIG_SYS_LONGHELP #ifdef CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT "$ " #else
On Saturday, December 14, 2013 at 06:42:00 AM, Sergei Ianovich wrote:
The device has only 256 kiB for U-Boot binary.
Binary size exceeds 256 kiB after activating CONFIG_OF_LIBFDT, so we disable USB support which was not working anyway.
Disabled USD frees more space than libfdt requires, so activate long command line help.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
Is this device not running from DRAM, which has about infinite (in the context of U-Boot) size ?
include/configs/lp8x4x.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 55658ab..16c8c03 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -20,18 +20,18 @@ #define CONFIG_SYS_MALLOC_LEN (128*1024) #define CONFIG_ARCH_CPU_INIT #define CONFIG_BOOTCOMMAND \
- "bootm 80000;"
- "bootm 80000 - 240000;"
#define CONFIG_BOOTARGS \ "console=ttySA0,115200 mem=128M root=/dev/mmcblk0p1 rw" \
- "init=/sbin/init rootfstype=ext3"
- "init=/sbin/init rootfstype=ext4 rootwait"
#define CONFIG_TIMESTAMP #define CONFIG_BOOTDELAY 2 /* Autoboot delay */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_LZMA /* LZMA compression support */ -#undef CONFIG_OF_LIBFDT +#define CONFIG_OF_LIBFDT
/*
- Serial Console Configuration
@@ -50,7 +50,7 @@ #define CONFIG_CMD_ENV #undef CONFIG_CMD_IMLS #define CONFIG_CMD_MMC -#define CONFIG_CMD_USB +#undef CONFIG_CMD_USB #undef CONFIG_LCD #undef CONFIG_CMD_IDE
@@ -101,7 +101,7 @@ */ #define CONFIG_SYS_HUSH_PARSER 1
-#undef CONFIG_SYS_LONGHELP +#define CONFIG_SYS_LONGHELP #ifdef CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT "$ " #else
Best regards, Marek Vasut
On Sat, 2013-12-14 at 13:32 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 06:42:00 AM, Sergei Ianovich wrote:
The device has only 256 kiB for U-Boot binary.
Binary size exceeds 256 kiB after activating CONFIG_OF_LIBFDT, so we disable USB support which was not working anyway.
Disabled USD frees more space than libfdt requires, so activate long command line help.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
Is this device not running from DRAM, which has about infinite (in the context of U-Boot) size ?
Factory flash partition layout is just 256 kiB for the U-Boot. I am not associated with the producer, so I cannot fix this.
On Saturday, December 14, 2013 at 04:41:30 PM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 13:32 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 06:42:00 AM, Sergei Ianovich wrote:
The device has only 256 kiB for U-Boot binary.
Binary size exceeds 256 kiB after activating CONFIG_OF_LIBFDT, so we disable USB support which was not working anyway.
Disabled USD frees more space than libfdt requires, so activate long command line help.
Signed-off-by: Sergei Ianovich ynvich@gmail.com
Is this device not running from DRAM, which has about infinite (in the context of U-Boot) size ?
Factory flash partition layout is just 256 kiB for the U-Boot. I am not associated with the producer, so I cannot fix this.
I see, understood. I won't bug you here, but you _might_ want to investigate if the U-Boot can't be for example compiled using THUMB instruction set and thus shrink it in size. But that'd be a long shot :)
Best regards, Marek Vasut
On Sat, 2013-12-14 at 18:05 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 04:41:30 PM, Sergei Ianovich wrote:
Factory flash partition layout is just 256 kiB for the U-Boot. I am not associated with the producer, so I cannot fix this.
I see, understood. I won't bug you here, but you _might_ want to investigate if the U-Boot can't be for example compiled using THUMB instruction set and thus shrink it in size. But that'd be a long shot :)
After a clean rebuild, U-Boot with both OF_LIBFDT and CMD_USB, but without SYS_LONGHELP is under 256 kiB. I won't disable USB. Instead, I'll try to make it actually work.
Thanks for constructive reviewing.
On Sunday, December 15, 2013 at 10:57:55 AM, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 18:05 +0100, Marek Vasut wrote:
On Saturday, December 14, 2013 at 04:41:30 PM, Sergei Ianovich wrote:
Factory flash partition layout is just 256 kiB for the U-Boot. I am not associated with the producer, so I cannot fix this.
I see, understood. I won't bug you here, but you _might_ want to investigate if the U-Boot can't be for example compiled using THUMB instruction set and thus shrink it in size. But that'd be a long shot :)
After a clean rebuild, U-Boot with both OF_LIBFDT and CMD_USB, but without SYS_LONGHELP is under 256 kiB. I won't disable USB. Instead, I'll try to make it actually work.
Thanks for constructive reviewing.
Again, thank you for the effort! :)
Best regards, Marek Vasut
On Sun, 2013-12-15 at 16:06 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 10:57:55 AM, Sergei Ianovich wrote:
After a clean rebuild, U-Boot with both OF_LIBFDT and CMD_USB, but without SYS_LONGHELP is under 256 kiB. I won't disable USB. Instead, I'll try to make it actually work.
While testing, I've run into an issue with USB support. If I do
$ usb start
in U-Boot, not only it doesn't see an attached flash storage, but also it break USB in the kernel. If I just boot the kernel from flash or tftp, USB works in the kernel.
I've verified that my usb_board_init() is exactly the same sequence of commands, that the kernel uses to initialize the stack up to usb_add_hcd() at linux/drivers/usb/host/ohci-pxa27x.c:445
I suspect the issue is in U-Boot OHCI PXA driver. Are you aware of any?
It probably makes sense to disable USB at LP-8x4 for now.
On Sunday, December 15, 2013 at 07:56:35 PM, Sergei Ianovich wrote:
On Sun, 2013-12-15 at 16:06 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 10:57:55 AM, Sergei Ianovich wrote:
After a clean rebuild, U-Boot with both OF_LIBFDT and CMD_USB, but without SYS_LONGHELP is under 256 kiB. I won't disable USB. Instead, I'll try to make it actually work.
While testing, I've run into an issue with USB support. If I do
$ usb start
in U-Boot, not only it doesn't see an attached flash storage, but also it break USB in the kernel. If I just boot the kernel from flash or tftp, USB works in the kernel.
The OHCI controller is not properly shut down before booting kernel, that's what I'd check first.
I've verified that my usb_board_init() is exactly the same sequence of commands, that the kernel uses to initialize the stack up to usb_add_hcd() at linux/drivers/usb/host/ohci-pxa27x.c:445
I suspect the issue is in U-Boot OHCI PXA driver. Are you aware of any?
No, not really. I didn't use the OHCI stuff for a while.
It probably makes sense to disable USB at LP-8x4 for now.
Can you maybe try debugging it please ?
Best regards, Marek Vasut
On Sun, 2013-12-15 at 20:22 +0100, Marek Vasut wrote:
On Sunday, December 15, 2013 at 07:56:35 PM, Sergei Ianovich wrote:
While testing, I've run into an issue with USB support. If I do
$ usb startin U-Boot, not only it doesn't see an attached flash storage, but also it break USB in the kernel. If I just boot the kernel from flash or tftp, USB works in the kernel.
The OHCI controller is not properly shut down before booting kernel, that's what I'd check first.
Thanks for the tip. That was practically it. USB was started and stopped twice (first by board then by CPU code). The driver is fine.
Linux kernel maintainers require new machnines to support device tree boot. The config for LP-8x4x needs updating.
In addition, there are a few fixes to board's configuration.
v2 fixes review comments made by Marek Vasut.
Sergei Ianovich (5): ARM: pxa: prevent PXA270 occasional reboot freezes arm: pxa: fix LP-8x4x USB support arm: pxa: fix 2nd flash chip address on LP-8x4x arm: pxa: update LP-8x4x to boot DT kernel arm: pxa: init ethaddr for LP-8x4x using DT
arch/arm/cpu/pxa/pxa2xx.c | 1 + board/icpdas/lp8x4x/lp8x4x.c | 39 +++++++++++++-------------------------- include/configs/lp8x4x.h | 15 +++++++-------- 3 files changed, 21 insertions(+), 34 deletions(-)
Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS.
If SDRAM is not reset, it causes memory bus congestion and the device hangs.
We put SDRAM in selfresh mode before watchdog reset, removing potential freezes.
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de --- Changes v1..v2 * write to MDREFR once instead of in a cycle as suggested by Marek Vasut
arch/arm/cpu/pxa/pxa2xx.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c index c9a7d45..7e861e2 100644 --- a/arch/arm/cpu/pxa/pxa2xx.c +++ b/arch/arm/cpu/pxa/pxa2xx.c @@ -279,6 +279,7 @@ void reset_cpu(ulong ignored) tmp = readl(OSCR); tmp += 0x1000; writel(tmp, OSMR3); + writel(MDREFR_SLFRSH, MDREFR);
for (;;) ;
USB was broken initially. Power polarity should be direct.
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de --- Changes v1..v2 * new patch
board/icpdas/lp8x4x/lp8x4x.c | 22 +++++++++++++--------- include/configs/lp8x4x.h | 3 +-- 2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c index 1b68ef3..0888960 100644 --- a/board/icpdas/lp8x4x/lp8x4x.c +++ b/board/icpdas/lp8x4x/lp8x4x.c @@ -60,15 +60,21 @@ int board_mmc_init(bd_t *bis) #ifdef CONFIG_CMD_USB int usb_board_init(void) { - writel((UHCHR | UHCHR_PCPL | UHCHR_PSPL) & - ~(UHCHR_SSEP0 | UHCHR_SSEP1 | UHCHR_SSEP2 | UHCHR_SSE), - UHCHR); + writel(readl(CKEN) | CKEN10_USBHOST, CKEN); + + writel(readl(UHCHR) | UHCHR_FHR, UHCHR); + udelay(11); + writel(readl(UHCHR) & ~UHCHR_FHR, UHCHR);
writel(readl(UHCHR) | UHCHR_FSBIR, UHCHR);
while (readl(UHCHR) & UHCHR_FSBIR) continue; /* required by checkpath.pl */
+ writel(readl(UHCHR) & ~UHCHR_SSEP0, UHCHR); + writel(readl(UHCRHDA) & ~(0x1000), UHCRHDA); + writel(readl(UHCRHDA) | 0x800, UHCRHDA); + writel(readl(UHCHR) & ~UHCHR_SSE, UHCHR); writel((UHCHIE_UPRIE | UHCHIE_RWIE), UHCHIE);
@@ -82,10 +88,6 @@ int usb_board_init(void) /* Set port power control mask bits, only 3 ports. */ writel(readl(UHCRHDB) | (0x7<<17), UHCRHDB);
- /* enable port 2 */ - writel(readl(UP2OCR) | UP2OCR_HXOE | UP2OCR_HXS | - UP2OCR_DMPDE | UP2OCR_DPPDE, UP2OCR); - return 0; }
@@ -94,7 +96,7 @@ void usb_board_init_fail(void) return; }
-void usb_board_stop(void) +int usb_board_stop(void) { writel(readl(UHCHR) | UHCHR_FHR, UHCHR); udelay(11); @@ -103,9 +105,11 @@ void usb_board_stop(void) writel(readl(UHCCOMS) | 1, UHCCOMS); udelay(10);
+ writel(readl(UHCHR) | UHCHR_SSEP0 | UHCHR_SSE, UHCHR); + writel(readl(CKEN) & ~CKEN10_USBHOST, CKEN);
- return; + return 0; } #endif
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 6df6f2b..2c03425 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -190,7 +190,7 @@ #define CONFIG_SYS_GAFR1_L_VAL 0x999a955a #define CONFIG_SYS_GAFR1_U_VAL 0xaaa5a00a #define CONFIG_SYS_GAFR2_L_VAL 0xaaaaaaaa -#define CONFIG_SYS_GAFR2_U_VAL 0x55f0a402 +#define CONFIG_SYS_GAFR2_U_VAL 0x55f9a402 #define CONFIG_SYS_GAFR3_L_VAL 0x540a950c #define CONFIG_SYS_GAFR3_U_VAL 0x00001599
@@ -238,7 +238,6 @@ */ #ifdef CONFIG_CMD_USB #define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT #define CONFIG_SYS_USB_OHCI_BOARD_INIT #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 #define CONFIG_SYS_USB_OHCI_REGS_BASE 0x4C000000
On Tuesday, December 17, 2013 at 02:03:41 AM, Sergei Ianovich wrote:
USB was broken initially. Power polarity should be direct.
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de
I pushed new u-boot-pxa/master, can you please rebase this one patch and repost?
Best regards, Marek Vasut
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de --- Changes v2..v3 * fixed merge conflict * added checks for index and init type
Changes v1..v2 * new patch
board/icpdas/lp8x4x/lp8x4x.c | 38 ++++++++++++++++++++++++-------------- include/configs/lp8x4x.h | 3 +-- 2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c index aea18aa..a136dc4 100644 --- a/board/icpdas/lp8x4x/lp8x4x.c +++ b/board/icpdas/lp8x4x/lp8x4x.c @@ -61,15 +61,24 @@ int board_mmc_init(bd_t *bis) #ifdef CONFIG_CMD_USB int board_usb_init(int index, enum usb_init_type init) { - writel((UHCHR | UHCHR_PCPL | UHCHR_PSPL) & - ~(UHCHR_SSEP0 | UHCHR_SSEP1 | UHCHR_SSEP2 | UHCHR_SSE), - UHCHR); + if (index !=0 || init != USB_INIT_HOST) + return -1; + + writel(readl(CKEN) | CKEN10_USBHOST, CKEN); + + writel(readl(UHCHR) | UHCHR_FHR, UHCHR); + udelay(11); + writel(readl(UHCHR) & ~UHCHR_FHR, UHCHR);
writel(readl(UHCHR) | UHCHR_FSBIR, UHCHR);
while (readl(UHCHR) & UHCHR_FSBIR) continue; /* required by checkpath.pl */
+ writel(readl(UHCHR) & ~UHCHR_SSEP0, UHCHR); + writel(readl(UHCRHDA) & ~(0x1000), UHCRHDA); + writel(readl(UHCRHDA) | 0x800, UHCRHDA); + writel(readl(UHCHR) & ~UHCHR_SSE, UHCHR); writel((UHCHIE_UPRIE | UHCHIE_RWIE), UHCHIE);
@@ -83,19 +92,10 @@ int board_usb_init(int index, enum usb_init_type init) /* Set port power control mask bits, only 3 ports. */ writel(readl(UHCRHDB) | (0x7<<17), UHCRHDB);
- /* enable port 2 */ - writel(readl(UP2OCR) | UP2OCR_HXOE | UP2OCR_HXS | - UP2OCR_DMPDE | UP2OCR_DPPDE, UP2OCR); - return 0; }
-int board_usb_cleanup(int index, enum usb_init_type init) -{ - return 0; -} - -void usb_board_stop(void) +int usb_board_stop(void) { writel(readl(UHCHR) | UHCHR_FHR, UHCHR); udelay(11); @@ -104,9 +104,19 @@ void usb_board_stop(void) writel(readl(UHCCOMS) | 1, UHCCOMS); udelay(10);
+ writel(readl(UHCHR) | UHCHR_SSEP0 | UHCHR_SSE, UHCHR); + writel(readl(CKEN) & ~CKEN10_USBHOST, CKEN);
- return; + return 0; +} + +int board_usb_cleanup(int index, enum usb_init_type init) +{ + if (index !=0 || init != USB_INIT_HOST) + return -1; + + return usb_board_stop(); } #endif
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 4b70cc4..8e58fea 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -184,7 +184,7 @@ #define CONFIG_SYS_GAFR1_L_VAL 0x999a955a #define CONFIG_SYS_GAFR1_U_VAL 0xaaa5a00a #define CONFIG_SYS_GAFR2_L_VAL 0xaaaaaaaa -#define CONFIG_SYS_GAFR2_U_VAL 0x55f0a402 +#define CONFIG_SYS_GAFR2_U_VAL 0x55f9a402 #define CONFIG_SYS_GAFR3_L_VAL 0x540a950c #define CONFIG_SYS_GAFR3_U_VAL 0x00001599
@@ -232,7 +232,6 @@ */ #ifdef CONFIG_CMD_USB #define CONFIG_USB_OHCI_NEW -#define CONFIG_SYS_USB_OHCI_CPU_INIT #define CONFIG_SYS_USB_OHCI_BOARD_INIT #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 #define CONFIG_SYS_USB_OHCI_REGS_BASE 0x4C000000
On Wednesday, December 18, 2013 at 05:19:20 PM, Sergei Ianovich wrote:
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de
Applied, thanks
Best regards, Marek Vasut
Initial configuration has worng address of the second chip. There is an alias for the 1st chip at 0x02000000 in earlier verions of LP-8x4x, so the boot normally.
However, new LP-8x4xs have a bigger 1st flash chip, and hang on boot without this patch.
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de --- Changes v1..v2 * no changes
include/configs/lp8x4x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 2c03425..565940c 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -150,7 +150,7 @@ #define CONFIG_ENV_SECT_SIZE 0x40000
#define PHYS_FLASH_1 0x00000000 /* Flash Bank #1 */ -#define PHYS_FLASH_2 0x02000000 /* Flash Bank #2 */ +#define PHYS_FLASH_2 0x04000000 /* Flash Bank #2 */
#define CONFIG_SYS_FLASH_CFI #define CONFIG_FLASH_CFI_DRIVER 1
DT kernel requires CONFIG_OF_LIBFDT. 'bootm' needs to know DT location. In addition, fix kernel console device and enable U-Boot long help.
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de --- Changes v1..v2 * don't disable USB * update serial console
include/configs/lp8x4x.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/configs/lp8x4x.h b/include/configs/lp8x4x.h index 565940c..501b94a 100644 --- a/include/configs/lp8x4x.h +++ b/include/configs/lp8x4x.h @@ -20,18 +20,18 @@ #define CONFIG_SYS_MALLOC_LEN (128*1024) #define CONFIG_ARCH_CPU_INIT #define CONFIG_BOOTCOMMAND \ - "bootm 80000;" + "bootm 80000 - 240000;"
#define CONFIG_BOOTARGS \ - "console=ttySA0,115200 mem=128M root=/dev/mmcblk0p1 rw" \ - "init=/sbin/init rootfstype=ext3" + "console=ttyS0,115200 mem=128M root=/dev/mmcblk0p1 rw" \ + "init=/sbin/init rootfstype=ext4 rootwait"
#define CONFIG_TIMESTAMP #define CONFIG_BOOTDELAY 2 /* Autoboot delay */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_LZMA /* LZMA compression support */ -#undef CONFIG_OF_LIBFDT +#define CONFIG_OF_LIBFDT
/* * Serial Console Configuration @@ -101,7 +101,7 @@ */ #define CONFIG_SYS_HUSH_PARSER 1
-#undef CONFIG_SYS_LONGHELP +#define CONFIG_SYS_LONGHELP #ifdef CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT "$ " #else
When DT define aliases for etherner0 and ethernet1, U-Boot automatically patched MAC addresses using ethaddr and eth1addr environment variables respectively.
Custom initialization is no longer needed.
Signed-off-by: Sergei Ianovich ynvich@gmail.com CC: Marek Vasut marex@denx.de --- Changes v1..v2 * use alias instead of manual updating as suggested by Marek Vasut
board/icpdas/lp8x4x/lp8x4x.c | 17 ----------------- 1 file changed, 17 deletions(-)
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c index 0888960..a7a2e21 100644 --- a/board/icpdas/lp8x4x/lp8x4x.c +++ b/board/icpdas/lp8x4x/lp8x4x.c @@ -114,25 +114,8 @@ int usb_board_stop(void) #endif
#ifdef CONFIG_DRIVER_DM9000 -void lp8x4x_eth1_mac_init(void) -{ - u8 eth1addr[8]; - int i; - u8 reg; - - eth_getenv_enetaddr_by_index("eth", 1, eth1addr); - if (!is_valid_ether_addr(eth1addr)) - return; - - for (i = 0, reg = 0x10; i < 6; i++, reg++) { - writeb(reg, (u8 *)(DM9000_IO_2)); - writeb(eth1addr[i], (u8 *)(DM9000_DATA_2)); - } -} - int board_eth_init(bd_t *bis) { - lp8x4x_eth1_mac_init(); return dm9000_initialize(bis); } #endif
On Tuesday, December 17, 2013 at 02:03:39 AM, Sergei Ianovich wrote:
Linux kernel maintainers require new machnines to support device tree boot. The config for LP-8x4x needs updating.
In addition, there are a few fixes to board's configuration.
v2 fixes review comments made by Marek Vasut.
Sergei Ianovich (5): ARM: pxa: prevent PXA270 occasional reboot freezes arm: pxa: fix LP-8x4x USB support arm: pxa: fix 2nd flash chip address on LP-8x4x arm: pxa: update LP-8x4x to boot DT kernel arm: pxa: init ethaddr for LP-8x4x using DT
arch/arm/cpu/pxa/pxa2xx.c | 1 + board/icpdas/lp8x4x/lp8x4x.c | 39 +++++++++++++-------------------------- include/configs/lp8x4x.h | 15 +++++++-------- 3 files changed, 21 insertions(+), 34 deletions(-)
Applied 1,3,4,5 , thanks!
2 doesn't apply so see my comment please.
Best regards, Marek Vasut
participants (2)
-
Marek Vasut -
Sergei Ianovich