Re: [U-Boot] [PATCH v5 00/14] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix
On 2015-03-11 16:11, Tom Rini wrote: > On Mon, Mar 09, 2015 at 08:00:10AM +0100, Jan Kiszka wrote: > >> Changes in v4: >> - rebased over master >> - implemented psci_get_cpu_id as weak function >> - implemented psci_disable/enable_smp as weak functions >> - adjusted register interface of psci_get_cpu_stack_top >> >> This version (+ the non-cached memory init fix) can also be found at >> https://github.com/siemens/u-boot/tree/jetson-tk1-v5. > > So, I don't know where exactly this should come in. Hans or Ian, if you > can ack the sunxi changes (I saw you tested it Ian, thanks!) and Tom W., > if you can ack the Tegra parts, I can take this in or Albert, do you > want to chime in too since this is kinda core ARM stuff too? Thanks > everyone! Ping... Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
Hello Lukasz, Am 17.03.2015 16:16, schrieb Lukasz Majewski: Hi Heiko, Hello Lukasz, Am 17.03.2015 13:56, schrieb Lukasz Majewski: Hi Heiko, Hello Lukasz, Am 17.03.2015 10:52, schrieb Lukasz Majewski: Hi Heiko, trigger watchdog before calling usb_gadget_handle_interrupts() This prevents board resets when calling dfu command on boards which have a watchdog. Signed-off-by: Heiko Schocher --- common/cmd_dfu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index e975abe..46af4cf 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -9,6 +9,7 @@ */ #include +#include #include #include #include @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (ctrlc()) goto exit; + WATCHDOG_RESET(); usb_gadget_handle_interrupts(); } exit: It seems strange for me, that we must reset watchdog when looping in the dfu. Hmm.. maybe I overlook something, but If you look into this while(1) loop, there is no trigger of the watchdog ... and if I start the dfu command without a USB cable on the board, what triggers the boards watchdog? So the problem is when cable is not attached to the board and you call dfu command to execute? Yes. For UMS gadget there is defined g_dnl_board_usb_cable_connected() function. However, it is not yet supported in dfu and requires working MUIC block, which might be not available at your board. Maybe, I must check this ... What is the WATCHDOG interval on the affected board? ~5 seconds Ah, this is on an at91 board .. and in the drivers/serial/atmel_usart.c atmel_serial_tstc() is no WATCHDOG_RESET... So ctrlc() does not trigger the watchdog Could you be a bit more specific here. Does your board expect ctrlc() to update watchdog, so it won't reset? I do not know, if ctrlc() must trigger the WDT ... I just looked into the while(1) loop in common/cmd_dfu.c. There is only ctrlc() which could trigger the WDT... and on at91 it does not trigger it ... By trigger you mean reset WDT core and don't reset the board? I mean, the code must trigger the WDT somewhere in this while(1). If not, the WDT resets the board. If dfu transfer is started there is some output on the console, which triggers the WDT too ... do you have a board with a running WDT? On trats/trats2 we disable WDT when we enter the u-boot. Why? So you can test this behaviour. Do not disable the WDT and start the dfu command ... the board should reset when you start the dfu command (without starting dfu-util on the host, and if ctrl() does not call WATCHDOG_RESET for your hw) ... with my patch it should work ... BTW: I could not disable the WDT on this board, once it is enabled. So disabling the WDT is no option ... :-( I can imagine following situation when WDT is enabled when u-boot starts (its timeout is ~5sec) and then you start dfu transfer with not connected cable. Then 5sec pass since cable is not connected and no transfer is ongoing. This causes board reset by WDT. Am I right? Yes, because the WDT gets not triggered in this while(1). And maybe if you start the dfu command with connected cable, but not starting dfu-util on the host also, but I have not yet running the usb gadget on this at91 board (at91sam9g20 based) ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5] mpc85xx/T104xD4RDB: Add T104xD4RDB boards support
T1040D4RDB is a Freescale reference board that hosts the T1040 SoC.
T1040D4RDB is re-designed T1040RDB board with following changes :
- Support of DDR4 memory
- Support of 0x66 serdes protocol which can support following interfaces
- 2 RGMII's on DTSEC4, DTSEC5
- 1 SGMII on DTSEC3
- Support of QE-TDM
Similarily T1042D4RDB is a Freescale reference board that hosts the T1040
SoC. T1042D4RDB is re-designed T1042RDB board with following changes :
- Support of DDR4 memory
- Support for 0x86 serdes protocol which can support following interfaces
- 2 RGMII's on DTSEC4, DTSEC5
- 3 SGMII on DTSEC1, DTSEC2 & DTSEC3
- Support of DIU
Signed-off-by: Vijay Rai
Signed-off-by: Priyanka Jain
---
changes from v2:
- adds SGMII suport using CPLD
- removes extra endif
changes from v3:
- removes checkpatch error
changes from v4:
- wrong use of defined MACRO in eth.c file, adds macro properly
board/freescale/t104xrdb/MAINTAINERS |8 ++
board/freescale/t104xrdb/ddr.c |6
board/freescale/t104xrdb/ddr.h | 13 -
board/freescale/t104xrdb/eth.c | 20 +++--
board/freescale/t104xrdb/t1040d4_rcw.cfg |7 +
board/freescale/t104xrdb/t1042d4_rcw.cfg |7 +
board/freescale/t104xrdb/t104xrdb.c | 17 +--
configs/T1040D4RDB_NAND_defconfig|5
configs/T1040D4RDB_SDCARD_defconfig |5
configs/T1040D4RDB_SPIFLASH_defconfig|5
configs/T1040D4RDB_defconfig |4 +++
configs/T1042D4RDB_NAND_defconfig|5
configs/T1042D4RDB_SDCARD_defconfig |5
configs/T1042D4RDB_SPIFLASH_defconfig|5
configs/T1042D4RDB_defconfig |4 +++
include/configs/T104xRDB.h | 46 --
16 files changed, 148 insertions(+), 14 deletions(-)
create mode 100644 board/freescale/t104xrdb/t1040d4_rcw.cfg
create mode 100644 board/freescale/t104xrdb/t1042d4_rcw.cfg
create mode 100644 configs/T1040D4RDB_NAND_defconfig
create mode 100644 configs/T1040D4RDB_SDCARD_defconfig
create mode 100644 configs/T1040D4RDB_SPIFLASH_defconfig
create mode 100644 configs/T1040D4RDB_defconfig
create mode 100644 configs/T1042D4RDB_NAND_defconfig
create mode 100644 configs/T1042D4RDB_SDCARD_defconfig
create mode 100644 configs/T1042D4RDB_SPIFLASH_defconfig
create mode 100644 configs/T1042D4RDB_defconfig
diff --git a/board/freescale/t104xrdb/MAINTAINERS
b/board/freescale/t104xrdb/MAINTAINERS
index 13d9be9..32e044f 100644
--- a/board/freescale/t104xrdb/MAINTAINERS
+++ b/board/freescale/t104xrdb/MAINTAINERS
@@ -6,7 +6,13 @@ F: include/configs/T104xRDB.h
F: configs/T1040RDB_defconfig
F: configs/T1040RDB_NAND_defconfig
F: configs/T1040RDB_SPIFLASH_defconfig
+F: configs/T1040D4RDB_defconfig
+F: configs/T1040D4RDB_NAND_defconfig
+F: configs/T1040D4RDB_SPIFLASH_defconfig
F: configs/T1042RDB_defconfig
+F: configs/T1042D4RDB_defconfig
+F: configs/T1042D4RDB_NAND_defconfig
+F: configs/T1042D4RDB_SPIFLASH_defconfig
F: configs/T1042RDB_PI_defconfig
F: configs/T1042RDB_PI_NAND_defconfig
F: configs/T1042RDB_PI_SPIFLASH_defconfig
@@ -15,6 +21,8 @@ T1040RDB_SDCARD BOARD
#M:-
S: Maintained
F: configs/T1040RDB_SDCARD_defconfig
+F: configs/T1040D4RDB_SDCARD_defconfig
+F: configs/T1042D4RDB_SDCARD_defconfig
F: configs/T1042RDB_PI_SDCARD_defconfig
T1040RDB_SECURE_BOOT BOARD
diff --git a/board/freescale/t104xrdb/ddr.c b/board/freescale/t104xrdb/ddr.c
index e1148e5..3c4eabf 100644
--- a/board/freescale/t104xrdb/ddr.c
+++ b/board/freescale/t104xrdb/ddr.c
@@ -91,8 +91,14 @@ found:
popts->zq_en = 1;
/* DHC_EN =1, ODT = 75 Ohm */
+#ifdef CONFIG_SYS_FSL_DDR4
+ popts->ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_80ohm);
+ popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) |
+ DDR_CDR2_VREF_OVRD(70); /* Vref = 70% */
+#else
popts->ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_75ohm);
popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_75ohm);
+#endif
}
#if defined(CONFIG_DEEP_SLEEP)
diff --git a/board/freescale/t104xrdb/ddr.h b/board/freescale/t104xrdb/ddr.h
index ab1c32d..eb6ec70 100644
--- a/board/freescale/t104xrdb/ddr.h
+++ b/board/freescale/t104xrdb/ddr.h
@@ -28,6 +28,13 @@ static const struct board_specific_parameters udimm0[] = {
* num| hi| rank| clk| wrlvl | wrlvl
* ranks| mhz| GB |adjst| start | ctl2
*/
+#ifdef CONFIG_SYS_FSL_DDR4
+ {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A},
+ {2, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A},
+ {1, 1666, 0, 4, 6, 0x0708090B, 0x0C0D0E09},
+ {1, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A},
+ {1, 2200, 0, 4, 7, 0x08090A0D, 0x0F0F100C},
+#elif defined(CONFIG_SYS_FSL_DDR3)
{2, 833, 4, 4, 6, 0x060
Re: [U-Boot] [PATCH V4] mpc85xx/T104xD4RDB: Add T104xD4RDB boards support
> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Vijay Rai
> Sent: Wednesday, March 18, 2015 2:50 PM
> To: Sun York-R58495; u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH V4] mpc85xx/T104xD4RDB: Add T104xD4RDB boards
> support
>
> T1040D4RDB is a Freescale reference board that hosts the T1040 SoC.
> T1040D4RDB is re-designed T1040RDB board with following changes :
> - Support of DDR4 memory
> - Support of 0x66 serdes protocol which can support following interfaces
> - 2 RGMII's on DTSEC4, DTSEC5
> - 1 SGMII on DTSEC3
> - Support of QE-TDM
>
> Similarily T1042D4RDB is a Freescale reference board that hosts the T1040
> SoC. T1042D4RDB is re-designed T1042RDB board with following changes :
> - Support of DDR4 memory
> - Support for 0x86 serdes protocol which can support following interfaces
> - 2 RGMII's on DTSEC4, DTSEC5
> - 3 SGMII on DTSEC1, DTSEC2 & DTSEC3
> - Support of DIU
>
> Signed-off-by: Vijay Rai
> Signed-off-by: Priyanka Jain
> ---
> changes from v2 :
> - removes checkpatch error
>
Please maintain version history while sending the patch revision.
> board/freescale/t104xrdb/MAINTAINERS |8 ++
> board/freescale/t104xrdb/ddr.c |6
> board/freescale/t104xrdb/ddr.h | 13 -
> board/freescale/t104xrdb/eth.c | 20 +++--
> board/freescale/t104xrdb/t1040d4_rcw.cfg |7 +
> board/freescale/t104xrdb/t1042d4_rcw.cfg |7 +
> board/freescale/t104xrdb/t104xrdb.c | 17 +--
> configs/T1040D4RDB_NAND_defconfig|5
> configs/T1040D4RDB_SDCARD_defconfig |5
> configs/T1040D4RDB_SPIFLASH_defconfig|5
> configs/T1040D4RDB_defconfig |4 +++
> configs/T1042D4RDB_NAND_defconfig|5
> configs/T1042D4RDB_SDCARD_defconfig |5
> configs/T1042D4RDB_SPIFLASH_defconfig|5
> configs/T1042D4RDB_defconfig |4 +++
> include/configs/T104xRDB.h | 46
> --
> 16 files changed, 148 insertions(+), 14 deletions(-) create mode 100644
> board/freescale/t104xrdb/t1040d4_rcw.cfg
> create mode 100644 board/freescale/t104xrdb/t1042d4_rcw.cfg
> create mode 100644 configs/T1040D4RDB_NAND_defconfig create mode
> 100644 configs/T1040D4RDB_SDCARD_defconfig
> create mode 100644 configs/T1040D4RDB_SPIFLASH_defconfig
> create mode 100644 configs/T1040D4RDB_defconfig create mode 100644
> configs/T1042D4RDB_NAND_defconfig create mode 100644
> configs/T1042D4RDB_SDCARD_defconfig
> create mode 100644 configs/T1042D4RDB_SPIFLASH_defconfig
> create mode 100644 configs/T1042D4RDB_defconfig
>
> diff --git a/board/freescale/t104xrdb/MAINTAINERS
> b/board/freescale/t104xrdb/MAINTAINERS
> index 13d9be9..32e044f 100644
> --- a/board/freescale/t104xrdb/MAINTAINERS
> +++ b/board/freescale/t104xrdb/MAINTAINERS
> @@ -6,7 +6,13 @@ F: include/configs/T104xRDB.h
> F: configs/T1040RDB_defconfig
> F: configs/T1040RDB_NAND_defconfig
> F: configs/T1040RDB_SPIFLASH_defconfig
> +F: configs/T1040D4RDB_defconfig
> +F: configs/T1040D4RDB_NAND_defconfig
> +F: configs/T1040D4RDB_SPIFLASH_defconfig
> F: configs/T1042RDB_defconfig
> +F: configs/T1042D4RDB_defconfig
> +F: configs/T1042D4RDB_NAND_defconfig
> +F: configs/T1042D4RDB_SPIFLASH_defconfig
> F: configs/T1042RDB_PI_defconfig
> F: configs/T1042RDB_PI_NAND_defconfig
> F: configs/T1042RDB_PI_SPIFLASH_defconfig
> @@ -15,6 +21,8 @@ T1040RDB_SDCARD BOARD
> #M: -
> S: Maintained
> F: configs/T1040RDB_SDCARD_defconfig
> +F: configs/T1040D4RDB_SDCARD_defconfig
> +F: configs/T1042D4RDB_SDCARD_defconfig
> F: configs/T1042RDB_PI_SDCARD_defconfig
>
> T1040RDB_SECURE_BOOT BOARD
> diff --git a/board/freescale/t104xrdb/ddr.c b/board/freescale/t104xrdb/ddr.c
> index e1148e5..3c4eabf 100644
> --- a/board/freescale/t104xrdb/ddr.c
> +++ b/board/freescale/t104xrdb/ddr.c
> @@ -91,8 +91,14 @@ found:
> popts->zq_en = 1;
>
> /* DHC_EN =1, ODT = 75 Ohm */
> +#ifdef CONFIG_SYS_FSL_DDR4
> + popts->ddr_cdr1 = DDR_CDR1_DHC_EN |
> DDR_CDR1_ODT(DDR_CDR_ODT_80ohm);
> + popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) |
> + DDR_CDR2_VREF_OVRD(70); /* Vref = 70% */
> +#else
> popts->ddr_cdr1 = DDR_CDR1_DHC_EN |
> DDR_CDR1_ODT(DDR_CDR_ODT_75ohm);
> popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_75ohm);
> +#endif
> }
>
> #if defined(CONFIG_DEEP_SLEEP)
> diff --git a/board/freescale/t104xrdb/ddr.h b/board/freescale/t104xrdb/ddr.h
> index ab1c32d..eb6ec70 100644
> --- a/board/freescale/t104xrdb/ddr.h
> +++ b/board/freescale/t104xrdb/ddr.h
> @@ -28,6 +28,13 @@ static const struct board_specific_parameters udimm0[] =
> {
>* num| hi| rank| clk| wrlvl | wrlvl
>* ranks| mhz| GB |adjst| start | ctl2
>*/
> +#ifdef CONFIG_SYS_FSL_DDR4
> + {2
[U-Boot] [PATCH V4] mpc85xx/T104xD4RDB: Add T104xD4RDB boards support
T1040D4RDB is a Freescale reference board that hosts the T1040 SoC.
T1040D4RDB is re-designed T1040RDB board with following changes :
- Support of DDR4 memory
- Support of 0x66 serdes protocol which can support following interfaces
- 2 RGMII's on DTSEC4, DTSEC5
- 1 SGMII on DTSEC3
- Support of QE-TDM
Similarily T1042D4RDB is a Freescale reference board that hosts the T1040
SoC. T1042D4RDB is re-designed T1042RDB board with following changes :
- Support of DDR4 memory
- Support for 0x86 serdes protocol which can support following interfaces
- 2 RGMII's on DTSEC4, DTSEC5
- 3 SGMII on DTSEC1, DTSEC2 & DTSEC3
- Support of DIU
Signed-off-by: Vijay Rai
Signed-off-by: Priyanka Jain
---
changes from v2 :
- removes checkpatch error
board/freescale/t104xrdb/MAINTAINERS |8 ++
board/freescale/t104xrdb/ddr.c |6
board/freescale/t104xrdb/ddr.h | 13 -
board/freescale/t104xrdb/eth.c | 20 +++--
board/freescale/t104xrdb/t1040d4_rcw.cfg |7 +
board/freescale/t104xrdb/t1042d4_rcw.cfg |7 +
board/freescale/t104xrdb/t104xrdb.c | 17 +--
configs/T1040D4RDB_NAND_defconfig|5
configs/T1040D4RDB_SDCARD_defconfig |5
configs/T1040D4RDB_SPIFLASH_defconfig|5
configs/T1040D4RDB_defconfig |4 +++
configs/T1042D4RDB_NAND_defconfig|5
configs/T1042D4RDB_SDCARD_defconfig |5
configs/T1042D4RDB_SPIFLASH_defconfig|5
configs/T1042D4RDB_defconfig |4 +++
include/configs/T104xRDB.h | 46 --
16 files changed, 148 insertions(+), 14 deletions(-)
create mode 100644 board/freescale/t104xrdb/t1040d4_rcw.cfg
create mode 100644 board/freescale/t104xrdb/t1042d4_rcw.cfg
create mode 100644 configs/T1040D4RDB_NAND_defconfig
create mode 100644 configs/T1040D4RDB_SDCARD_defconfig
create mode 100644 configs/T1040D4RDB_SPIFLASH_defconfig
create mode 100644 configs/T1040D4RDB_defconfig
create mode 100644 configs/T1042D4RDB_NAND_defconfig
create mode 100644 configs/T1042D4RDB_SDCARD_defconfig
create mode 100644 configs/T1042D4RDB_SPIFLASH_defconfig
create mode 100644 configs/T1042D4RDB_defconfig
diff --git a/board/freescale/t104xrdb/MAINTAINERS
b/board/freescale/t104xrdb/MAINTAINERS
index 13d9be9..32e044f 100644
--- a/board/freescale/t104xrdb/MAINTAINERS
+++ b/board/freescale/t104xrdb/MAINTAINERS
@@ -6,7 +6,13 @@ F: include/configs/T104xRDB.h
F: configs/T1040RDB_defconfig
F: configs/T1040RDB_NAND_defconfig
F: configs/T1040RDB_SPIFLASH_defconfig
+F: configs/T1040D4RDB_defconfig
+F: configs/T1040D4RDB_NAND_defconfig
+F: configs/T1040D4RDB_SPIFLASH_defconfig
F: configs/T1042RDB_defconfig
+F: configs/T1042D4RDB_defconfig
+F: configs/T1042D4RDB_NAND_defconfig
+F: configs/T1042D4RDB_SPIFLASH_defconfig
F: configs/T1042RDB_PI_defconfig
F: configs/T1042RDB_PI_NAND_defconfig
F: configs/T1042RDB_PI_SPIFLASH_defconfig
@@ -15,6 +21,8 @@ T1040RDB_SDCARD BOARD
#M:-
S: Maintained
F: configs/T1040RDB_SDCARD_defconfig
+F: configs/T1040D4RDB_SDCARD_defconfig
+F: configs/T1042D4RDB_SDCARD_defconfig
F: configs/T1042RDB_PI_SDCARD_defconfig
T1040RDB_SECURE_BOOT BOARD
diff --git a/board/freescale/t104xrdb/ddr.c b/board/freescale/t104xrdb/ddr.c
index e1148e5..3c4eabf 100644
--- a/board/freescale/t104xrdb/ddr.c
+++ b/board/freescale/t104xrdb/ddr.c
@@ -91,8 +91,14 @@ found:
popts->zq_en = 1;
/* DHC_EN =1, ODT = 75 Ohm */
+#ifdef CONFIG_SYS_FSL_DDR4
+ popts->ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_80ohm);
+ popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) |
+ DDR_CDR2_VREF_OVRD(70); /* Vref = 70% */
+#else
popts->ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_75ohm);
popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_75ohm);
+#endif
}
#if defined(CONFIG_DEEP_SLEEP)
diff --git a/board/freescale/t104xrdb/ddr.h b/board/freescale/t104xrdb/ddr.h
index ab1c32d..eb6ec70 100644
--- a/board/freescale/t104xrdb/ddr.h
+++ b/board/freescale/t104xrdb/ddr.h
@@ -28,6 +28,13 @@ static const struct board_specific_parameters udimm0[] = {
* num| hi| rank| clk| wrlvl | wrlvl
* ranks| mhz| GB |adjst| start | ctl2
*/
+#ifdef CONFIG_SYS_FSL_DDR4
+ {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A},
+ {2, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A},
+ {1, 1666, 0, 4, 6, 0x0708090B, 0x0C0D0E09},
+ {1, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A},
+ {1, 2200, 0, 4, 7, 0x08090A0D, 0x0F0F100C},
+#elif defined(CONFIG_SYS_FSL_DDR3)
{2, 833, 4, 4, 6, 0x06060607, 0x08080807},
{2, 833, 0, 4, 6, 0x06060607, 0x08080807},
{2, 1350, 4, 4, 7, 0x0708080A, 0x0A0B0C09},
@@ -40,10 +47,14 @@
Re: [U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
On Tue, 17 Mar 2015 12:09:17 -0400 Tom Rini wrote: > On Tue, Mar 17, 2015 at 04:16:14PM +0100, Lukasz Majewski wrote: > > Hi Heiko, > > > > > Hello Lukasz, > > > > > > Am 17.03.2015 13:56, schrieb Lukasz Majewski: > > > > Hi Heiko, > > > > > > > >> Hello Lukasz, > > > >> > > > >> Am 17.03.2015 10:52, schrieb Lukasz Majewski: > > > >>> Hi Heiko, > > > >>> > > > trigger watchdog before calling > > > usb_gadget_handle_interrupts() This prevents board resets > > > when calling dfu command on boards which have a watchdog. > > > > > > Signed-off-by: Heiko Schocher > > > --- > > > > > > common/cmd_dfu.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c > > > index e975abe..46af4cf 100644 > > > --- a/common/cmd_dfu.c > > > +++ b/common/cmd_dfu.c > > > @@ -9,6 +9,7 @@ > > > */ > > > > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int > > > flag, int argc, char * const argv[]) if (ctrlc()) > > > goto exit; > > > > > > +WATCHDOG_RESET(); > > > usb_gadget_handle_interrupts(); > > > } > > > exit: > > > >>> > > > >>> It seems strange for me, that we must reset watchdog when > > > >>> looping in the dfu. > > > >> > > > >> Hmm.. maybe I overlook something, but If you look into this > > > >> while(1) loop, there is no trigger of the watchdog ... and if I > > > >> start the dfu command without a USB cable on the board, what > > > >> triggers the boards watchdog? > > > > > > > > So the problem is when cable is not attached to the board and > > > > you call dfu command to execute? > > > > > > Yes. > > > > For UMS gadget there is defined g_dnl_board_usb_cable_connected() > > function. > > > > However, it is not yet supported in dfu and requires working MUIC > > block, which might be not available at your board. > > > > > > > > >>> What is the WATCHDOG interval on the affected board? > > > >> > > > >> ~5 seconds > > > >> > > > >> Ah, this is on an at91 board .. and in the > > > >> drivers/serial/atmel_usart.c atmel_serial_tstc() is no > > > >> WATCHDOG_RESET... > > > >> > > > >> So ctrlc() does not trigger the watchdog > > > > > > > > Could you be a bit more specific here. Does your board expect > > > > ctrlc() to update watchdog, so it won't reset? > > > > > > I do not know, if ctrlc() must trigger the WDT ... I just looked > > > into the while(1) loop in common/cmd_dfu.c. There is only ctrlc() > > > which could trigger the WDT... and on at91 it does not trigger > > > it ... > > > > By trigger you mean reset WDT core and don't reset the board? > > > > > > > > If dfu transfer is started there is some output on the console, > > > which triggers the WDT too ... do you have a board with a running > > > WDT? > > > > On trats/trats2 we disable WDT when we enter the u-boot. > > This seems wrong. We should enable the WDT and then be "petting" or > whatever the right term is for saying "Hey WDT, I'm alive!" which is > what WATCHDOG_RESET() is really about. Tom, I agree with the above. However in trats/trats2 case it is not necessary. Best regards, Lukasz pgpAmGDAP1aUz.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] remove unnecessary version.h includes
Various files are needlessly rebuilt every time due to the version and build time changing. As version.h is not actually needed, remove the include. Signed-off-by: Rob Herring Cc: Albert Aribaud Cc: Stefano Babic Cc: Minkyu Kang Cc: Marek Vasut Cc: Tom Warren Cc: Michal Simek Cc: Macpaul Lin Cc: Wolfgang Denk Cc: York Sun Cc: Stefan Roese Cc: Nobuhiro Iwamatsu Cc: Simon Glass Cc: Philippe Reynes Cc: Eric Jarrige Cc: Linus Walleij Cc: "David Müller" Cc: Phil Edworthy Cc: Robert Baldyga Cc: "Łukasz Majewski" Cc: Torsten Koschorrek Cc: Anatolij Gustschin --- arch/arm/cpu/arm1136/start.S | 1 - arch/arm/cpu/arm1176/start.S | 1 - arch/arm/cpu/arm720t/start.S | 1 - arch/arm/cpu/arm926ejs/mxs/start.S | 1 - arch/arm/cpu/arm926ejs/start.S | 1 - arch/arm/cpu/arm946es/start.S | 1 - arch/arm/cpu/armv7/armada-xp/lowlevel_spl.S| 1 - arch/arm/cpu/armv7/exynos/clock_init_exynos4.c | 1 - arch/arm/cpu/armv7/exynos/exynos4_setup.h | 1 - arch/arm/cpu/armv7/omap3/lowlevel_init.S | 1 - arch/arm/cpu/armv7/socfpga/lowlevel_init.S | 1 - arch/arm/cpu/armv7/socfpga/spl.c | 1 - arch/arm/cpu/armv7/start.S | 1 - arch/arm/cpu/armv8/cache.S | 1 - arch/arm/cpu/armv8/exceptions.S| 1 - arch/arm/cpu/armv8/start.S | 1 - arch/arm/cpu/armv8/tlb.S | 1 - arch/arm/cpu/armv8/transition.S| 1 - arch/arm/cpu/pxa/start.S | 1 - arch/arm/cpu/sa1100/start.S| 1 - arch/arm/mach-tegra/lowlevel_init.S| 1 - arch/microblaze/cpu/spl.c | 1 - arch/nds32/cpu/n1213/start.S | 1 - arch/powerpc/config.mk | 9 + arch/powerpc/cpu/mpc8260/kgdb.S| 1 - arch/powerpc/cpu/mpc85xx/release.S | 1 - arch/powerpc/cpu/mpc86xx/cache.S | 1 - arch/powerpc/cpu/mpc86xx/release.S | 1 - arch/powerpc/cpu/mpc8xx/kgdb.S | 1 - arch/powerpc/cpu/ppc4xx/kgdb.S | 1 - arch/sh/cpu/sh2/start.S| 1 - arch/sh/cpu/sh3/start.S| 1 - arch/sh/cpu/sh4/start.S| 1 - arch/x86/cpu/start.S | 1 - board/alphaproject/ap_sh4a_4a/lowlevel_init.S | 1 - board/armadeus/apf27/lowlevel_init.S | 1 - board/armltd/integrator/lowlevel_init.S| 1 - board/armltd/versatile/lowlevel_init.S | 1 - board/espt/lowlevel_init.S | 1 - board/logicpd/imx27lite/lowlevel_init.S| 1 - board/mpl/vcma9/lowlevel_init.S| 2 -- board/ms7722se/lowlevel_init.S | 1 - board/ms7750se/lowlevel_init.S | 1 - board/renesas/MigoR/lowlevel_init.S| 1 - board/renesas/ap325rxa/lowlevel_init.S | 1 - board/renesas/ecovec/lowlevel_init.S | 1 - board/renesas/r0p7734/lowlevel_init.S | 1 - board/renesas/r2dplus/lowlevel_init.S | 1 - board/renesas/r7780mp/lowlevel_init.S | 1 - board/renesas/rsk7203/lowlevel_init.S | 1 - board/renesas/rsk7264/lowlevel_init.S | 1 - board/renesas/rsk7269/lowlevel_init.S | 1 - board/renesas/sh7752evb/lowlevel_init.S| 1 - board/renesas/sh7753evb/lowlevel_init.S| 1 - board/renesas/sh7757lcr/lowlevel_init.S| 1 - board/renesas/sh7763rdp/lowlevel_init.S| 1 - board/renesas/sh7785lcr/lowlevel_init.S| 1 - board/samsung/goni/lowlevel_init.S | 1 - board/samsung/smdk2410/lowlevel_init.S | 2 -- board/samsung/smdkc100/lowlevel_init.S | 1 - board/samsung/trats/setup.h| 1 - board/scb9328/lowlevel_init.S | 1 - board/shmin/lowlevel_init.S| 1 - common/spl/spl_mmc.c | 1 - common/spl/spl_sata.c | 1 - drivers/rtc/mc146818.c | 1 - drivers/video/mpc8xx_lcd.c | 1 - drivers/video/pxa_lcd.c| 1 - 68 files changed, 5 insertions(+), 73 deletions(-) diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index 1cfcca9..1ec79a6 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -14,7 +14,6 @@ #include #include -#include /* * diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index ac937bf..4c0ab4d 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -16,7 +16,6 @@ #include #include -#include #ifndef CONFIG_SYS_PHY_UBOOT_BASE #define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE diff --git a/arch/arm/cpu/arm720t/start.S b/a
Re: [U-Boot] Kernel to U-boot messaging and vice versa.
Hi Dev, Altough your problem is off-topic from u-boot, we want to help you :-) the only solution what i see, is some watchdog. Maybe your CPU has such feature or your hardware around does offer some watchdog. best regards, Hannes On 2015-03-17 21:53, Dev wrote Thank You Hannes and Andy for replying back. I agree that the kernel and U-boot are very old. There are many units deployed out in the field which are running these versions. Hence, we are stuck on these old versions. There are some kernel modules which are running above linux kernel. When we try to field upgrade these deployed units, due to external failures for example power surge, these kernel modules hang in a bad state, which causes the unit unusable. In those conditions we want the unit to go through reset sequence. Regards, -Dev From: andy.p...@sdcsystems.com To: dsupe...@hotmail.com CC: u-boot@lists.denx.de Subject: RE: [U-Boot] Kernel to U-boot messaging and vice versa. Date: Tue, 17 Mar 2015 19:15:24 + Dev wrote... I am new to U-boot development. We are using U-Boot 1.1.4 on a MIPS 74Kc QCA 9557 processor, which is running Linux Kernel 2.6.32.27. Is there a reason why you have to be running a kernel from 2010 and a version of bootloader that is even older? It makes life much easier to provide support if you can update to more recent versions and you never know they may already have fixed your problems! We have a situation were our firmware keeps hanging due to some issues. What is your "firmware" in this context? As you rightly said, once the Linux kernel is running U-Boot is no more and if U-Boot is hanging then you aren't going to get to the kernel anyway! We are looking into a solution where U-boot and Kernel keep communicating with each other every some minutes. If U-boot finds that there is no communication, it will reset the board. This sounds like it is the territory of watchdog timers. I don't know that CPU to know whether it has one built in though, nor if the kernel supports it. Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel to U-boot messaging and vice versa.
Thank You Hannes and Andy for replying back. I agree that the kernel and U-boot are very old. There are many units deployed out in the field which are running these versions. Hence, we are stuck on these old versions. There are some kernel modules which are running above linux kernel. When we try to field upgrade these deployed units, due to external failures for example power surge, these kernel modules hang in a bad state, which causes the unit unusable. In those conditions we want the unit to go through reset sequence. Regards, -Dev > From: andy.p...@sdcsystems.com > To: dsupe...@hotmail.com > CC: u-boot@lists.denx.de > Subject: RE: [U-Boot] Kernel to U-boot messaging and vice versa. > Date: Tue, 17 Mar 2015 19:15:24 + > > Dev wrote... > > > I am new to U-boot development. We are using U-Boot 1.1.4 on a MIPS > > 74Kc QCA 9557 processor, which is running Linux Kernel 2.6.32.27. > > Is there a reason why you have to be running a kernel from 2010 and a > version of bootloader that is even older? It makes life much easier to > provide support if you can update to more recent versions and you never know > they may already have fixed your problems! > > > We have a situation were our firmware keeps hanging due to some issues. > > What is your "firmware" in this context? As you rightly said, once the > Linux kernel is running U-Boot is no more and if U-Boot is hanging then you > aren't going to get to the kernel anyway! > > > We are looking into a solution where U-boot and Kernel keep communicating > > with each other every some minutes. If U-boot finds that there is no > > communication, it will reset the board. > > This sounds like it is the territory of watchdog timers. I don't know that > CPU to know whether it has one built in though, nor if the kernel supports > it. > > Andy. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ehci-hcd: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.
Signed-off-by: Rob Herring
Cc: Marek Vasut
---
drivers/usb/host/ehci-hcd.c | 82 ++---
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index f1fb190..86f1646 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -45,7 +45,7 @@
static struct ehci_ctrl ehcic[CONFIG_USB_MAX_CONTROLLER_COUNT];
#define ALIGN_END_ADDR(type, ptr, size)\
- ((uint32_t)(ptr) + roundup((size) * sizeof(type), USB_DMA_MINALIGN))
+ ((unsigned long)(ptr) + roundup((size) * sizeof(type),
USB_DMA_MINALIGN))
static struct descriptor {
struct usb_hub_descriptor hub;
@@ -223,7 +223,7 @@ static int ehci_shutdown(struct ehci_ctrl *ctrl)
static int ehci_td_buffer(struct qTD *td, void *buf, size_t sz)
{
uint32_t delta, next;
- uint32_t addr = (uint32_t)buf;
+ uint32_t addr = (unsigned long)buf;
int idx;
if (addr != ALIGN(addr, ARCH_DMA_MINALIGN))
@@ -245,7 +245,7 @@ static int ehci_td_buffer(struct qTD *td, void *buf, size_t
sz)
}
if (idx == QT_BUFFER_CNT) {
- printf("out of buffer pointers (%u bytes left)\n", sz);
+ printf("out of buffer pointers (%zu bytes left)\n", sz);
return -1;
}
@@ -354,7 +354,7 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
* qTD transfer size will be one page shorter, and the first qTD
* data buffer of each transfer will be page-unaligned.
*/
- if ((uint32_t)buffer & (PKT_ALIGN - 1))
+ if ((unsigned long)buffer & (PKT_ALIGN - 1))
xfr_sz--;
/* Convert the qTD transfer size to bytes. */
xfr_sz *= EHCI_PAGE_SIZE;
@@ -394,7 +394,7 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
* qh_overlay.qt_next .. 13-10 H
* - qh_overlay.qt_altnext
*/
- qh->qh_link = cpu_to_hc32((uint32_t)&ctrl->qh_list | QH_LINK_TYPE_QH);
+ qh->qh_link = cpu_to_hc32((unsigned long)&ctrl->qh_list |
QH_LINK_TYPE_QH);
c = (dev->speed != USB_SPEED_HIGH) && !usb_pipeendpoint(pipe);
maxpacket = usb_maxpacket(dev, pipe);
endpt = QH_ENDPT1_RL(8) | QH_ENDPT1_C(c) |
@@ -434,7 +434,7 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
goto fail;
}
/* Update previous qTD! */
- *tdp = cpu_to_hc32((uint32_t)&qtd[qtd_counter]);
+ *tdp = cpu_to_hc32((unsigned long)&qtd[qtd_counter]);
tdp = &qtd[qtd_counter++].qt_next;
toggle = 1;
}
@@ -454,7 +454,7 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
* portion of the first page before the buffer start
* offset within that page is unusable.
*/
- xfr_bytes -= (uint32_t)buf_ptr & (EHCI_PAGE_SIZE - 1);
+ xfr_bytes -= (unsigned long)buf_ptr & (EHCI_PAGE_SIZE -
1);
/*
* In order to keep each packet within a qTD transfer,
* align the qTD transfer size to PKT_ALIGN.
@@ -493,7 +493,7 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
goto fail;
}
/* Update previous qTD! */
- *tdp = cpu_to_hc32((uint32_t)&qtd[qtd_counter]);
+ *tdp = cpu_to_hc32((unsigned long)&qtd[qtd_counter]);
tdp = &qtd[qtd_counter++].qt_next;
/*
* Data toggle has to be adjusted since the qTD transfer
@@ -524,21 +524,21 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer,
QT_TOKEN_STATUS(QT_TOKEN_STATUS_ACTIVE);
qtd[qtd_counter].qt_token = cpu_to_hc32(token);
/* Update previous qTD! */
- *tdp = cpu_to_hc32((uint32_t)&qtd[qtd_counter]);
+ *tdp = cpu_to_hc32((unsigned long)&qtd[qtd_counter]);
tdp = &qtd[qtd_counter++].qt_next;
}
- ctrl->qh_list.qh_link = cpu_to_hc32((uint32_t)qh | QH_LINK_TYPE_QH);
+ ctrl->qh_list.qh_link = cpu_to_hc32((unsigned long)qh |
QH_LINK_TYPE_QH);
/* Flush dcache */
- flush_dcache_range((uint32_t)&ctrl->qh_list,
+ flush_dcache_range((unsigned long)&ctrl->qh_list,
ALIGN_END_ADDR(struct QH, &ctrl->qh_list, 1));
- flush_dcache_range((uint32_t)qh, ALIGN_END
[U-Boot] [PATCH] mv_i2c: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds. Signed-off-by: Rob Herring Cc: Heiko Schocher --- drivers/i2c/mv_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c index e65cce0..fc02e65 100644 --- a/drivers/i2c/mv_i2c.c +++ b/drivers/i2c/mv_i2c.c @@ -73,7 +73,7 @@ static void i2c_board_init(struct mv_i2c *base) } #ifdef CONFIG_I2C_MULTI_BUS -static u32 i2c_regs[CONFIG_MV_I2C_NUM] = CONFIG_MV_I2C_REG; +static unsigned long i2c_regs[CONFIG_MV_I2C_NUM] = CONFIG_MV_I2C_REG; static unsigned int bus_initialized[CONFIG_MV_I2C_NUM]; static unsigned int current_bus; -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ci_udc: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.
Signed-off-by: Rob Herring
Cc: "Łukasz Majewski"
Cc: Marek Vasut
---
drivers/usb/gadget/ci_udc.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index b0ef35e..a231abf 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -160,8 +160,8 @@ static struct ept_queue_item *ci_get_qtd(int ep_num, int
dir_in)
static void ci_flush_qh(int ep_num)
{
struct ept_queue_head *head = ci_get_qh(ep_num, 0);
- const uint32_t start = (uint32_t)head;
- const uint32_t end = start + 2 * sizeof(*head);
+ const unsigned long start = (unsigned long)head;
+ const unsigned long end = start + 2 * sizeof(*head);
flush_dcache_range(start, end);
}
@@ -175,8 +175,8 @@ static void ci_flush_qh(int ep_num)
static void ci_invalidate_qh(int ep_num)
{
struct ept_queue_head *head = ci_get_qh(ep_num, 0);
- uint32_t start = (uint32_t)head;
- uint32_t end = start + 2 * sizeof(*head);
+ unsigned long start = (unsigned long)head;
+ unsigned long end = start + 2 * sizeof(*head);
invalidate_dcache_range(start, end);
}
@@ -190,8 +190,8 @@ static void ci_invalidate_qh(int ep_num)
static void ci_flush_qtd(int ep_num)
{
struct ept_queue_item *item = ci_get_qtd(ep_num, 0);
- const uint32_t start = (uint32_t)item;
- const uint32_t end = start + 2 * ILIST_ENT_SZ;
+ const unsigned long start = (unsigned long)item;
+ const unsigned long end = start + 2 * ILIST_ENT_SZ;
flush_dcache_range(start, end);
}
@@ -205,8 +205,8 @@ static void ci_flush_qtd(int ep_num)
static void ci_invalidate_qtd(int ep_num)
{
struct ept_queue_item *item = ci_get_qtd(ep_num, 0);
- const uint32_t start = (uint32_t)item;
- const uint32_t end = start + 2 * ILIST_ENT_SZ;
+ const unsigned long start = (unsigned long)item;
+ const unsigned long end = start + 2 * ILIST_ENT_SZ;
invalidate_dcache_range(start, end);
}
@@ -308,8 +308,8 @@ static int ci_ep_disable(struct usb_ep *ep)
static int ci_bounce(struct ci_req *ci_req, int in)
{
struct usb_request *req = &ci_req->req;
- uint32_t addr = (uint32_t)req->buf;
- uint32_t hwaddr;
+ unsigned long addr = (unsigned long)req->buf;
+ unsigned long hwaddr;
uint32_t aligned_used_len;
/* Input buffer address is not aligned. */
@@ -343,7 +343,7 @@ align:
memcpy(ci_req->hw_buf, req->buf, req->length);
flush:
- hwaddr = (uint32_t)ci_req->hw_buf;
+ hwaddr = (unsigned long)ci_req->hw_buf;
aligned_used_len = roundup(req->length, ARCH_DMA_MINALIGN);
flush_dcache_range(hwaddr, hwaddr + aligned_used_len);
@@ -353,8 +353,8 @@ flush:
static void ci_debounce(struct ci_req *ci_req, int in)
{
struct usb_request *req = &ci_req->req;
- uint32_t addr = (uint32_t)req->buf;
- uint32_t hwaddr = (uint32_t)ci_req->hw_buf;
+ unsigned long addr = (unsigned long)req->buf;
+ unsigned long hwaddr = (unsigned long)ci_req->hw_buf;
uint32_t aligned_used_len;
if (in)
@@ -388,13 +388,13 @@ static void ci_ep_submit_next_request(struct ci_ep *ci_ep)
len = ci_req->req.length;
item->info = INFO_BYTES(len) | INFO_ACTIVE;
- item->page0 = (uint32_t)ci_req->hw_buf;
- item->page1 = ((uint32_t)ci_req->hw_buf & 0xf000) + 0x1000;
- item->page2 = ((uint32_t)ci_req->hw_buf & 0xf000) + 0x2000;
- item->page3 = ((uint32_t)ci_req->hw_buf & 0xf000) + 0x3000;
- item->page4 = ((uint32_t)ci_req->hw_buf & 0xf000) + 0x4000;
+ item->page0 = (unsigned long)ci_req->hw_buf;
+ item->page1 = ((unsigned long)ci_req->hw_buf & 0xf000) + 0x1000;
+ item->page2 = ((unsigned long)ci_req->hw_buf & 0xf000) + 0x2000;
+ item->page3 = ((unsigned long)ci_req->hw_buf & 0xf000) + 0x3000;
+ item->page4 = ((unsigned long)ci_req->hw_buf & 0xf000) + 0x4000;
- head->next = (unsigned) item;
+ head->next = (unsigned long)item;
head->info = 0;
/*
@@ -422,7 +422,7 @@ static void ci_ep_submit_next_request(struct ci_ep *ci_ep)
* can use the other to transmit the extra zero-length packet.
*/
struct ept_queue_item *other_item = ci_get_qtd(num, 0);
- item->next = (unsigned)other_item;
+ item->next = (unsigned long)other_item;
item = other_item;
item->info = INFO_ACTIVE;
}
@@ -772,7 +772,7 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on)
writel(USBCMD_ITC(MICRO_8FRAME) | USBCMD_RST, &udc->usbcmd);
udelay(200);
- w
[U-Boot] [PATCH] sdhci: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.
Signed-off-by: Rob Herring
Cc: Pantelis Antoniou
---
drivers/mmc/sdhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 82d7984..2d92204 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -194,13 +194,13 @@ static int sdhci_send_command(struct mmc *mmc, struct
mmc_cmd *cmd,
#ifdef CONFIG_MMC_SDMA
if (data->flags == MMC_DATA_READ)
- start_addr = (unsigned int)data->dest;
+ start_addr = (unsigned long)data->dest;
else
- start_addr = (unsigned int)data->src;
+ start_addr = (unsigned long)data->src;
if ((host->quirks & SDHCI_QUIRK_32BIT_DMA_ADDR) &&
(start_addr & 0x7) != 0x0) {
is_aligned = 0;
- start_addr = (unsigned int)aligned_buffer;
+ start_addr = (unsigned long)aligned_buffer;
if (data->flags != MMC_DATA_READ)
memcpy(aligned_buffer, data->src, trans_bytes);
}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mv_sdhci: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.
Signed-off-by: Rob Herring
Cc: Pantelis Antoniou
---
drivers/mmc/mv_sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 63e1f90..75fa014 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -12,7 +12,7 @@ static struct sdhci_ops mv_ops;
static inline void mv_sdhci_writeb(struct sdhci_host *host, u8 val, int reg)
{
struct mmc *mmc = host->mmc;
- u32 ata = (u32)host->ioaddr + SD_CE_ATA_2;
+ u32 ata = (unsigned long)host->ioaddr + SD_CE_ATA_2;
if (!IS_SD(mmc) && reg == SDHCI_HOST_CONTROL) {
if (mmc->bus_width == 8)
@@ -30,7 +30,7 @@ static inline void mv_sdhci_writeb(struct sdhci_host *host,
u8 val, int reg)
#endif /* CONFIG_MMC_SDHCI_IO_ACCESSORS */
static char *MVSDH_NAME = "mv_sdh";
-int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
+int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
{
struct sdhci_host *host = NULL;
host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] travis.yml: add more targets to build on travis
On Tue, Mar 17, 2015 at 08:21:41AM +0100, Heiko Schocher wrote: > - add more targets for building with buildman: > - avr32 > - m68k > > and while at it, sort the list alphabetical > > Reviewed-by: Roger Meier > Signed-off-by: Heiko Schocher 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 6/7] powerpc: ppc4xx: remove korat board support
On Tue, Mar 17, 2015 at 12:28:09PM +0900, Masahiro Yamada wrote: > This has not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada > Cc: Larry Johnson 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 5/7] powerpc: mpc5xxx: remove galaxy5200 board support
On Tue, Mar 17, 2015 at 12:28:08PM +0900, Masahiro Yamada wrote: > This has not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada > Cc: Eric Millbrandt 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 4/7] powerpc: ppc4xx: remove W7OLMC/W7OLMG board support
On Tue, Mar 17, 2015 at 12:28:07PM +0900, Masahiro Yamada wrote: > They have not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada > Cc: Erik Theisen 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 1/7] powerpc: mpc5xxx: remove BC3450 board support
On Tue, Mar 17, 2015 at 12:28:04PM +0900, Masahiro Yamada wrote: > This has not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada 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 3/7] powerpc: mpc5xxx: remove aev, TB5200 board support
On Tue, Mar 17, 2015 at 12:28:06PM +0900, Masahiro Yamada wrote: > They have not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada 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 2/7] powerpc: ppc4xx: remove JSE board support
On Tue, Mar 17, 2015 at 12:28:05PM +0900, Masahiro Yamada wrote: > This has not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada > Cc: Stephen Williams 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] board/BuR/common: use SYS_CONSOLE_OVERWRITE
On Tue, Mar 17, 2015 at 03:31:21PM +0100, Hannes Petermaier wrote: > From: Hannes Petermaier > > We don't want that CONSOLE is redirected to LCD upon init, we rather prefer > that console is still on the serial line. > > Signed-off-by: Hannes Petermaier 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
[U-Boot] [ANN] U-Boot v2015.04-rc4 released
Hey all, I've pushed v2015.04-rc4 out to the repository and tarballs should exist soon. We're getting really close to the end and I hope we'll have a few more small PRs come along with this and that. I think we're looking to be in decent shape overall but there's a few platforms that keep not building without errors / warnings (katmai, openrd*) and I wonder if we shouldn't just drop them. As always, if anything else is broken please speak up. Thanks all! -- 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] mpc83xx: preempt premature board support removal by setting GENERIC_BOARD
Hi Tom On 03/17/2015 03:18 PM, Tom Rini wrote: [...] Signed-off-by: Kim Phillips I'll apply this shortly. But we've been saying for a long while that things need converint to GENERIC_BOARD and stuff that doesn't get converted is getting removed (since we've got even bigger things coming along and if we can't convince people to do and test the "small" things why do the larger things on those platforms). So please push up the chain that some time needs to be spent on mpc83xx support upstream, at least for basic testing. Thanks. As indicated I will be taking up on two boards now and I can help out with some others (particularly for quick tests etc.) if this proves to be helpful. Hope this helps everyone. Regards Sinan Akman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: preempt premature board support removal by setting GENERIC_BOARD (was: [PATCH 7/7] powerpc: mpc83xx: remove non-generic freescale boards)
On Tue, Mar 17, 2015 at 12:00:45PM -0500, Kim Phillips wrote: > On Tue, 17 Mar 2015 12:28:10 +0900 > Masahiro Yamada wrote: > > > Remove MPC8308RDB, MPC8313ERDB, MPC8315ERDB, MPC8323ERDB, > > MPC832XEMDS, MPC8349EMDS, MPC8349ITX, and MPC837XEMDS. > > > > They have not been converted to Generic Board, so should be removed. > > (See doc/README.generic-board for details.) > > > > Signed-off-by: Masahiro Yamada > > Cc: Ilya Yanok > > Cc: Dave Liu > > Cc: Michael Barkowski > > Cc: Kim Phillips > > Nacked-by: Kim Phillips > > From 39cb4e8eb7f768778ada3aed2e1419c88fe3adda Mon Sep 17 00:00:00 2001 > From: Kim Phillips > Date: Tue, 17 Mar 2015 11:44:20 -0500 > Subject: [PATCH] mpc83xx: preempt premature board support removal by setting > GENERIC_BOARD > > Boards that haven't been converted to GENERIC_BOARD does > *not* mean they should be removed. > > Signed-off-by: Kim Phillips I'll apply this shortly. But we've been saying for a long while that things need converint to GENERIC_BOARD and stuff that doesn't get converted is getting removed (since we've got even bigger things coming along and if we can't convince people to do and test the "small" things why do the larger things on those platforms). So please push up the chain that some time needs to be spent on mpc83xx support upstream, at least for basic testing. 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] Kernel to U-boot messaging and vice versa.
Dev wrote... > I am new to U-boot development. We are using U-Boot 1.1.4 on a MIPS > 74Kc QCA 9557 processor, which is running Linux Kernel 2.6.32.27. Is there a reason why you have to be running a kernel from 2010 and a version of bootloader that is even older? It makes life much easier to provide support if you can update to more recent versions and you never know they may already have fixed your problems! > We have a situation were our firmware keeps hanging due to some issues. What is your "firmware" in this context? As you rightly said, once the Linux kernel is running U-Boot is no more and if U-Boot is hanging then you aren't going to get to the kernel anyway! > We are looking into a solution where U-boot and Kernel keep communicating > with each other every some minutes. If U-boot finds that there is no > communication, it will reset the board. This sounds like it is the territory of watchdog timers. I don't know that CPU to know whether it has one built in though, nor if the kernel supports it. Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mkenvimage: Handle text files with length that exceed env size
From: Brian McFarland
The current head revision of mkenvimage
(e72be8947e129f5ab274c0a9f235d2cc0014b2ea) will prevent you from
creating an env image from a text file that is larger than the env
length specified by the '-s' option. That doesn't make sense given that
the tool now allows comments and blank lines. This patch removes that
limitation and allows longer text files to be used.
Signed-off-by: Brian McFarland
Signed-off-by: Joe Hershberger
---
Converted to a proper patch for the mailing list to be able to process.
tools/mkenvimage.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 6971b91..f1f602a 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -214,14 +214,13 @@ int main(int argc, char **argv)
}
ret = close(txt_fd);
}
- /* The +1 is for the additionnal ending \0. See below. */
- if (filesize + 1 > envsize) {
- fprintf(stderr, "The input file is larger than the environment
partition size\n");
- return EXIT_FAILURE;
- }
- /* Replace newlines separating variables with \0 */
- for (fp = 0, ep = 0 ; fp < filesize ; fp++) {
+ /*
+* Parse one byte at a time until reaching the end of the file OR until
+* the environment fills up. Check ep against envsize - 1 to allow for
+* an extra trailing '\0'.
+*/
+ for (fp = 0, ep = 0 ; fp < filesize && ep < envsize - 1; fp++) {
if (filebuf[fp] == '\n') {
if (fp == 0 || filebuf[fp-1] == '\n') {
/*
@@ -250,6 +249,27 @@ int main(int argc, char **argv)
}
}
/*
+* If there are more bytes in the file still, it means the env filled up
+* before parsing the whole file. Eat comments & whitespace here to see
+* if there was anything meaningful left in the file, and if so, throw
+* an error and exit.
+*/
+ for (; fp < filesize; fp++) {
+ if (filebuf[fp] == '\n') {
+ if (fp == 0 || filebuf[fp-1] == '\n') {
+ /* Ignore blank lines */
+ continue;
+ }
+ } else if ((fp == 0 || filebuf[fp-1] == '\n') &&
+ filebuf[fp] == '#') {
+ while (++fp < filesize && filebuf[fp] != '\n')
+ continue;
+ } else {
+ fprintf(stderr, "The environment file is too large for
the target environment storage\n");
+ return EXIT_FAILURE;
+ }
+ }
+ /*
* Make sure there is a final '\0'
* And do it again on the next byte to mark the end of the environment.
*/
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kernel to U-boot messaging and vice versa.
Hi Dev, for opinion, no way. best regards, Hannes On 2015-03-17 16:28, Dev wrote: Hello, I am new to U-boot development. We are using U-Boot 1.1.4 on a MIPS 74Kc QCA 9557 processor, which is running Linux Kernel 2.6.32.27. We have a situation were our firmware keeps hanging due to some issues. We are looking into a solution where U-boot and Kernel keep communicating with each other every some minutes. If U-boot finds that there is no communication, it will reset the board. I understand that once the Linux Kernel is booted, the bootloader is not there anymore. BUT, is there any way by modifying the Linux Kernel, we can achieve periodic U-boot to Kernel communication. Thanks, -Dev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] ARM: DRA7XX: Add config file for Android with fastboot support
- Added new configuration for Android fastboot
- This is based on following patch modified accordingly
http://git.omapzoom.org/?p=repo/u-boot.git;a=commit;h=b2e04f92b5d91c708b6fd6b79d2266966ac51f4b
Signed-off-by: Angela Stegmaier
Signed-off-by: Dileep Katta
---
Changes in v2:
- Merged the header file content to existing dra7xx_evm.h to avoid
duplication
- Removed unnecessary definitions as per comments
board/ti/dra7xx/MAINTAINERS | 1 +
configs/dra7xx_evm_android_defconfig | 5 +
include/configs/dra7xx_evm.h | 30 ++
3 files changed, 36 insertions(+)
create mode 100644 configs/dra7xx_evm_android_defconfig
diff --git a/board/ti/dra7xx/MAINTAINERS b/board/ti/dra7xx/MAINTAINERS
index 5ec6769..1b5ae71 100644
--- a/board/ti/dra7xx/MAINTAINERS
+++ b/board/ti/dra7xx/MAINTAINERS
@@ -6,3 +6,4 @@ F: include/configs/dra7xx_evm.h
F: configs/dra7xx_evm_defconfig
F: configs/dra7xx_evm_qspiboot_defconfig
F: configs/dra7xx_evm_uart3_defconfig
+F: configs/dra7xx_evm_android_defconfig
diff --git a/configs/dra7xx_evm_android_defconfig
b/configs/dra7xx_evm_android_defconfig
new file mode 100644
index 000..5fdce85
--- /dev/null
+++ b/configs/dra7xx_evm_android_defconfig
@@ -0,0 +1,5 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1,DRA7XX_ANDROID"
++S:CONFIG_ARM=y
++S:CONFIG_OMAP54XX=y
++S:CONFIG_TARGET_DRA7XX_EVM=y
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index dee2b11..dd20e08 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -43,6 +43,16 @@
"uuid_disk=${uuid_gpt_disk};" \
"name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}"
+#ifdef CONFIG_DRA7XX_ANDROID
+/* Fastboot */
+#define CONFIG_CMD_FASTBOOT
+#define CONFIG_ANDROID_BOOT_IMAGE
+#define CONFIG_USB_FASTBOOT_BUF_ADDRCONFIG_SYS_LOAD_ADDR
+#define CONFIG_USB_FASTBOOT_BUF_SIZE0x2F00
+#define CONFIG_FASTBOOT_FLASH
+#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1
+#endif
+
#include
/* Enhance our eMMC support / experience. */
@@ -115,7 +125,11 @@
#define CONFIG_SPL_SPI_SUPPORT
#define CONFIG_SPL_SPI_LOAD
#define CONFIG_SPL_SPI_FLASH_SUPPORT
+#ifdef CONFIG_DRA7XX_ANDROID
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8
+#else
#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x4
+#endif
#define CONFIG_SUPPORT_EMMC_BOOT
@@ -130,6 +144,22 @@
#define CONFIG_OMAP_USB_PHY
#define CONFIG_OMAP_USB2PHY2_HOST
+/* USB GADGET */
+#define CONFIG_USB_GADGET
+#define CONFIG_MUSB_GADGET
+#define CONFIG_MUSB_PIO_ONLY
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_USB_GADGET_VBUS_DRAW 2
+#define CONFIG_G_DNL_MANUFACTURER "Texas Instruments"
+#ifdef CONFIG_CMD_FASTBOOT
+#define CONFIG_G_DNL_VENDOR_NUM 0x0451
+#define CONFIG_G_DNL_PRODUCT_NUM 0xd022
+#else
+#define CONFIG_G_DNL_VENDOR_NUM 0x0403
+#define CONFIG_G_DNL_PRODUCT_NUM 0xBD00
+#endif
+#define CONFIG_USB_GADGET_DUALSPEED
+
/* SATA */
#define CONFIG_BOARD_LATE_INIT
#define CONFIG_CMD_SCSI
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Setting up MAC address for eth drivers
Hi Joe, On 03/17/2015 06:21 PM, Joe Hershberger wrote: > Hi Michal, > > On Tue, Mar 17, 2015 at 11:57 AM, Michal Simek > wrote: >> >> Hi Joe, >> >> On 03/17/2015 04:56 PM, Joe Hershberger wrote: >>> Hi Michal, >>> >>> On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek >>> wrote: Hi, I have a question regarding setting mac address for drivers. Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize which is called from common/board_r.c. >>> >>> This is because on at least ARM kernels, the MAC is passed via the MAC's >>> filter registers. Because of this, we need to write hwaddr even before > the >>> MAC is started. >>> But then there are some drivers(macb, designware, altera_tse) which > also >>> calls mac setup from dev->init which has side effect for example when you > setup >>> CONFIG_ENV_OVERWRITE and change mac address you can directly use it. >>> >>> This is probably a work-around for a shortcoming of the net/eth.c not >>> calling write_hwaddr() when the env MAC changes. It already updates the >>> registers used by the network stack, so presumably if those MACs are >>> filtering incoming traffic based on the register as expected, changing > the >>> MAC after boot without rewriting that register would cause all traffic > to >>> not be returned. >>> It also means if there is intention to call hwaddr from dev->init that for the first packet mac address is setup twice - in eth core init and then before every driver use. >>> >>> The design of the network stack assumes the MAC is started each time a >>> network operation is requested and stopped when done. >>> >>> As for the setting of the hwaddr, we should check if it changed. >>> I am asking this question because I would like to know the right flow for eth mac setup. If it is set ethaddr xx saveenv reset eth with new mac or if set ethaddr eth with new mac should work The second approach looks reasonable when ethaddr is not set at all but then at least our driver needs to be fixed to support this feature. >>> >>> I think the second should work ideally, but we need to add a call to >>> eth_init() if the "ethaddr" in the env changes and set it again if so. > We >>> should also remove the calls from the drivers you identified since the >>> framework will now do it. >> >> Does it mean that you are going to write that code for it? > > Yes... I'll write it, but it needs to be on top of the DM_ETH patches, so > I'll probably wait until that's pulled. That's fine. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations
On 17/03/15 17:29, Stephen Warren wrote: Do the RPi 1 and RPi 2 use different kernel binaries in the RPi Foundation's images? I'd assumed there was a single unified binary which supported both. The reason I ask is that I see: We ship separate kernel binaries (kernel.img for 2835 and kernel7.img for 2836). kernel.img is built from bcmrpi_defconfig, and kernel7.img is built from bcm2709_defconfig A single unified binary would sure be nice, but I think we have too many non-device-tree drivers in our kernel and not enough experience to make this happen easily. It's certainly a desirable goal (as it moving closer to the upstream mach-2835 kernel). I assume the SDHCI controller (RPi SD card, CM eMMC) is affected by this just as much; we need to use bus addresses not ARM physical addresses when programming any DMA there? Yes. Any address given to the DMA controller should be a bus address. Similarly any address exchanged with the GPU (e.g. framebuffer address from mailbox interface) should be a bus address. Perhaps this would explain why I had issues with the eMMC on the CM (I think only in the kernel though, whereas U-Boot may have been fine; I'll have to check) Using physical addresses when bus addresses are required can almost work, but with intermittent failure cases, so yes that sounds possible. I assume 128M and 512M there should be 128K and 512K? Yes, quite right. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc83xx: preempt premature board support removal by setting GENERIC_BOARD (was: [PATCH 7/7] powerpc: mpc83xx: remove non-generic freescale boards)
On Tue, 17 Mar 2015 12:28:10 +0900 Masahiro Yamada wrote: > Remove MPC8308RDB, MPC8313ERDB, MPC8315ERDB, MPC8323ERDB, > MPC832XEMDS, MPC8349EMDS, MPC8349ITX, and MPC837XEMDS. > > They have not been converted to Generic Board, so should be removed. > (See doc/README.generic-board for details.) > > Signed-off-by: Masahiro Yamada > Cc: Ilya Yanok > Cc: Dave Liu > Cc: Michael Barkowski > Cc: Kim Phillips Nacked-by: Kim Phillips >From 39cb4e8eb7f768778ada3aed2e1419c88fe3adda Mon Sep 17 00:00:00 2001 From: Kim Phillips Date: Tue, 17 Mar 2015 11:44:20 -0500 Subject: [PATCH] mpc83xx: preempt premature board support removal by setting GENERIC_BOARD Boards that haven't been converted to GENERIC_BOARD does *not* mean they should be removed. Signed-off-by: Kim Phillips --- include/configs/MPC8308RDB.h | 3 +++ include/configs/MPC8313ERDB.h | 3 +++ include/configs/MPC8315ERDB.h | 3 +++ include/configs/MPC8323ERDB.h | 3 +++ include/configs/MPC832XEMDS.h | 3 +++ include/configs/MPC8349EMDS.h | 3 +++ include/configs/MPC8349ITX.h | 3 +++ include/configs/MPC837XEMDS.h | 3 +++ include/configs/TQM834x.h | 3 +++ include/configs/km/km8309-common.h | 3 +++ include/configs/km/km8321-common.h | 3 +++ include/configs/km8360.h | 3 +++ include/configs/mpc8308_p1m.h | 3 +++ include/configs/sbc8349.h | 3 +++ include/configs/ve8313.h | 3 +++ include/configs/vme8349.h | 3 +++ 16 files changed, 48 insertions(+) diff --git a/include/configs/MPC8308RDB.h b/include/configs/MPC8308RDB.h index bf974fd..1ab2379 100644 --- a/include/configs/MPC8308RDB.h +++ b/include/configs/MPC8308RDB.h @@ -9,6 +9,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index dd81229..d9a19c3 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -10,6 +10,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h index 98e9072..1384f36 100644 --- a/include/configs/MPC8315ERDB.h +++ b/include/configs/MPC8315ERDB.h @@ -9,6 +9,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #define CONFIG_SYS_NAND_U_BOOT_SIZE (512 << 10) #define CONFIG_SYS_NAND_U_BOOT_DST 0x0010 #define CONFIG_SYS_NAND_U_BOOT_START 0x00100100 diff --git a/include/configs/MPC8323ERDB.h b/include/configs/MPC8323ERDB.h index 65a63e2..2dd71b7 100644 --- a/include/configs/MPC8323ERDB.h +++ b/include/configs/MPC8323ERDB.h @@ -9,6 +9,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/MPC832XEMDS.h b/include/configs/MPC832XEMDS.h index 1735b3c..14abd35 100644 --- a/include/configs/MPC832XEMDS.h +++ b/include/configs/MPC832XEMDS.h @@ -7,6 +7,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h index 6b7d648..17f230f 100644 --- a/include/configs/MPC8349EMDS.h +++ b/include/configs/MPC8349EMDS.h @@ -13,6 +13,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h index 398918a..2457125 100644 --- a/include/configs/MPC8349ITX.h +++ b/include/configs/MPC8349ITX.h @@ -40,6 +40,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #if (CONFIG_SYS_TEXT_BASE == 0xFE00) #define CONFIG_SYS_LOWBOOT #endif diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h index 832c10f..85f5c40 100644 --- a/include/configs/MPC837XEMDS.h +++ b/include/configs/MPC837XEMDS.h @@ -8,6 +8,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/TQM834x.h b/include/configs/TQM834x.h index 6762e3a..7b496c8 100644 --- a/include/configs/TQM834x.h +++ b/include/configs/TQM834x.h @@ -12,6 +12,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + /* * High Level Configuration Options */ diff --git a/include/configs/km/km8309-common.h b/include/configs/km/km8309-common.h index c8df23b..ec133f9 100644 --- a/include/configs/km/km8309-common.h +++ b/include/configs/km/km8309-com
Re: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations
On 03/17/2015 08:57 AM, popcorn mix wrote: On 17/03/15 03:04, Stephen Warren wrote: It would be nice though if someone from the RPi Foundation could comment on the exact effect of the upper bus address bits, and why 0xc would work for RPi2 but 0x4 for the RPi 1. I wonder if the ARM cache status (enabled, disabled) interacts with the GPU cache enable in any way, e.g. burst vs. non-burst transactions on the bus or something? That's about the only reason I can see for the RPi Foundation kernel working with 0x4 bus addresses on both chips, but U-Boot needing something different on RPi2... Dom, for reference, see: http://lists.denx.de/pipermail/u-boot/2015-March/207947.html http://lists.denx.de/pipermail/u-boot/2015-March/thread.html#207947 Thanks for the great explanation. I'll have to bookmark/archive it:-) First, remember that 2835 is a large GPU with a small ARM attached. On some platforms the ARM is not even used. The GPU boots first and may wake the arm. The GPU is the centre of the universe, and the ARM has to fit in. Okay, I'll try to explain what goes on. Here are my definitions of some terms: bus address: a VideoCore/GPU address. The lower 30-bits define the 1G of addressable memory. The top two bits define the caching alias. physical address: An ARM side address given to the VC MMU. This is a 30 bit address space. The GPU always uses bus addresses. GPU bus mastering peripherals (like DMA) use bus addresses. The ARM uses physical addresses. VC MMU: A coarse MMU used by the arm for accessing GPU memory. Each page is 16M and there are 64 pages. This maps 30-bits of physical address to 32-bits of bus address. > The setup of VC MMU is handled by the GPU and by default the mapping is: 2835: first 32 pages map physical addresses 0x-0x1fff to bus addresses 0x4000-0x5. The next page maps physical adddress 0x2000 to 0x20ff to bus addresses 0x7e00 to 0x7eff > 2836: first 63 pages map physical addresses 0x-0x3eff to bus addresses 0xc000-0xfefff. The next page maps physical adddress 0x3f00 to 0x3fff to bus addresses 0x7e00 to 0x7eff OK, this explains why in U-Boot, we need to OR in 0x4000 on bcm2835 and 0xc000 on bcm2836; that matches the VC MMU setup. I guess we need to fix the U-Boot mailbox driver too, and many things in the upstream RPi kernel. I have two more questions: 1) Do the RPi 1 and RPi 2 use different kernel binaries in the RPi Foundation's images? I'd assumed there was a single unified binary which supported both. The reason I ask is that I see: https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2708/include/mach/memory.h#L38 #ifdef CONFIG_BCM2708_NOL2CACHE #define _REAL_BUS_OFFSET UL(0xC000) /* don't use L1 or L2 caches */ #else #define _REAL_BUS_OFFSET UL(0x4000) /* use L2 cache */ #endif That's identical in the mach-bcm2709 version too. However, arch/arm/mach-bcm270[89]/Kconfig's entry for that config option: config BCM2708_NOL2CACHE bool "Videocore L2 cache disable" depends on MACH_BCM2709 default y help Do not allow ARM to use GPU's L2 cache. Requires disable_l2cache in config.txt. Has "default n" for the bcm2708 version and "default y" for the bcm2709 version. If I'd noticed that difference in default value, it would have been a big clue that what I proposed in the U-Boot patch was correct! Anyway, this implies that there are separate kernel binaries for the RPi 1 and RPi 2, since otherwise those default values wouldn't work. 2) I assume the SDHCI controller (RPi SD card, CM eMMC) is affected by this just as much; we need to use bus addresses not ARM physical addresses when programming any DMA there? Perhaps this would explain why I had issues with the eMMC on the CM (I think only in the kernel though, whereas U-Boot may have been fine; I'll have to check) ... So, on 2835 the ARM has a 16K L1 cache and no L2 cache. The GPU has a 128M L2 cache. The GPU's L2 cache is accessible from the ARM but it's not particularly close (i.e. not very fast). However mapping through the L2 allocating alias (0x4) was shown to be beneficial on 2835, so that is the alias we use. The situation is different on 2836. The ARM has a 32K L1 cache and a 512M integrated/fast L2 cache. Additionally going through the smaller/slower GPU L2 is bad for performance. So, we map through the SDRAM alias (0xc) and avoid the GPU L2 cache. I assume 128M and 512M there should be 128K and 512K? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx5: Add support for USB armory board
Hi Stefano, On Tue, Mar 17, 2015 at 2:09 PM, Stefano Babic wrote: > The arm library calls always print_cpuinfo(), where get_reset_cause() is > called. In this patch, print_cpuinfo() is called the second time in > board_late_init(), too. It should be dropped. > > Without testing, I think that this issue hits the mx53loco, too. Yes, you are right. The reason I called print_cpuinfo() inside board_late_init() was because I wanted to print the cpu speed after the PMIC voltage has been bumped and the clock was set to 1GHz. Without doing so I always got CPU frequency as 800MHz. At that time, I was not able to get the PMIC to setup the required voltage for 1GHz operation early enough so that print_cpuinfo shows 1GHz instead of 800MHz. Maybe this is possible now, but haven't tried it. Will only have access to mx53qsb when I am back to the office on the week of April 6th. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Setting up MAC address for eth drivers
Hi Michal, On Tue, Mar 17, 2015 at 11:57 AM, Michal Simek wrote: > > Hi Joe, > > On 03/17/2015 04:56 PM, Joe Hershberger wrote: > > Hi Michal, > > > > On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek > > wrote: > >> > >> Hi, > >> > >> I have a question regarding setting mac address for drivers. > >> Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize > >> which is called from common/board_r.c. > > > > This is because on at least ARM kernels, the MAC is passed via the MAC's > > filter registers. Because of this, we need to write hwaddr even before the > > MAC is started. > > > >> But then there are some drivers(macb, designware, altera_tse) which also > > calls > >> mac setup from dev->init which has side effect for example when you setup > > CONFIG_ENV_OVERWRITE > >> and change mac address you can directly use it. > > > > This is probably a work-around for a shortcoming of the net/eth.c not > > calling write_hwaddr() when the env MAC changes. It already updates the > > registers used by the network stack, so presumably if those MACs are > > filtering incoming traffic based on the register as expected, changing the > > MAC after boot without rewriting that register would cause all traffic to > > not be returned. > > > >> It also means if there is intention to call hwaddr from dev->init > >> that for the first packet mac address is setup twice - in eth core init > >> and then before every driver use. > > > > The design of the network stack assumes the MAC is started each time a > > network operation is requested and stopped when done. > > > > As for the setting of the hwaddr, we should check if it changed. > > > >> I am asking this question because I would like to know the right flow > >> for eth mac setup. > >> If it is > >> set ethaddr xx > >> saveenv > >> reset > >> eth with new mac > >> > >> or if > >> set ethaddr > >> eth with new mac > >> should work > >> > >> The second approach looks reasonable when ethaddr is not set at all > >> but then at least our driver needs to be fixed to support this feature. > > > > I think the second should work ideally, but we need to add a call to > > eth_init() if the "ethaddr" in the env changes and set it again if so. We > > should also remove the calls from the drivers you identified since the > > framework will now do it. > > Does it mean that you are going to write that code for it? Yes... I'll write it, but it needs to be on top of the DM_ETH patches, so I'll probably wait until that's pulled. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx5: Add support for USB armory board
Hi Fabio, Eric, On 17/03/2015 17:51, Eric Nelson wrote: > Hi Fabio, > > On 03/17/2015 09:30 AM, Fabio Estevam wrote: >> On Mon, Mar 16, 2015 at 1:50 PM, Chris Kuethe wrote: >> >>> U-Boot 2015.04-rc3-00209-ga74ef40-dirty (Mar 15 2015 - 22:04:22) >>> >>> CPU: Freescale i.MX53 rev2.1 at 800 MHz >>> Reset cause: WDOG >> >> Here the reset cause is printed correctly. >> >>> Board: Inverse Path USB armory MkI >>> I2C: ready >>> DRAM: 512 MiB >>> MMC: FSL_SDHC: 0 >>> In:serial >>> Out: serial >>> Err: serial >>> CPU: Freescale i.MX53 rev2.1 at 800 MHz >>> Reset cause: unknown reset >> >> ,but here it fails. >> >> Why does CPU version and reset cause are printed twice? >> > The arm library calls always print_cpuinfo(), where get_reset_cause() is called. In this patch, print_cpuinfo() is called the second time in board_late_init(), too. It should be dropped. Without testing, I think that this issue hits the mx53loco, too. Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Setting up MAC address for eth drivers
Hi Joe, On 03/17/2015 04:56 PM, Joe Hershberger wrote: > Hi Michal, > > On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek > wrote: >> >> Hi, >> >> I have a question regarding setting mac address for drivers. >> Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize >> which is called from common/board_r.c. > > This is because on at least ARM kernels, the MAC is passed via the MAC's > filter registers. Because of this, we need to write hwaddr even before the > MAC is started. > >> But then there are some drivers(macb, designware, altera_tse) which also > calls >> mac setup from dev->init which has side effect for example when you setup > CONFIG_ENV_OVERWRITE >> and change mac address you can directly use it. > > This is probably a work-around for a shortcoming of the net/eth.c not > calling write_hwaddr() when the env MAC changes. It already updates the > registers used by the network stack, so presumably if those MACs are > filtering incoming traffic based on the register as expected, changing the > MAC after boot without rewriting that register would cause all traffic to > not be returned. > >> It also means if there is intention to call hwaddr from dev->init >> that for the first packet mac address is setup twice - in eth core init >> and then before every driver use. > > The design of the network stack assumes the MAC is started each time a > network operation is requested and stopped when done. > > As for the setting of the hwaddr, we should check if it changed. > >> I am asking this question because I would like to know the right flow >> for eth mac setup. >> If it is >> set ethaddr xx >> saveenv >> reset >> eth with new mac >> >> or if >> set ethaddr >> eth with new mac >> should work >> >> The second approach looks reasonable when ethaddr is not set at all >> but then at least our driver needs to be fixed to support this feature. > > I think the second should work ideally, but we need to add a call to > eth_init() if the "ethaddr" in the env changes and set it again if so. We > should also remove the calls from the drivers you identified since the > framework will now do it. Does it mean that you are going to write that code for it? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx5: Add support for USB armory board
Hi Fabio, On 03/17/2015 09:30 AM, Fabio Estevam wrote: > On Mon, Mar 16, 2015 at 1:50 PM, Chris Kuethe wrote: > >> U-Boot 2015.04-rc3-00209-ga74ef40-dirty (Mar 15 2015 - 22:04:22) >> >> CPU: Freescale i.MX53 rev2.1 at 800 MHz >> Reset cause: WDOG > > Here the reset cause is printed correctly. > >> Board: Inverse Path USB armory MkI >> I2C: ready >> DRAM: 512 MiB >> MMC: FSL_SDHC: 0 >> In:serial >> Out: serial >> Err: serial >> CPU: Freescale i.MX53 rev2.1 at 800 MHz >> Reset cause: unknown reset > > ,but here it fails. > > Why does CPU version and reset cause are printed twice? > It appears that get_reset_cause() is being called twice, and since it's destructive, the second will say "unknown reset". This patch will fix the value of the return value: http://patchwork.ozlabs.org/patch/439934/ > Is this happening with all mx53 boards or only with this one? > I have no idea about this, but there appear to be multiple calls to print_cpuinfo(). Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx5: Add support for USB armory board
On Tue, Mar 17, 2015 at 9:30 AM, Fabio Estevam wrote: > On Mon, Mar 16, 2015 at 1:50 PM, Chris Kuethe wrote: > >> U-Boot 2015.04-rc3-00209-ga74ef40-dirty (Mar 15 2015 - 22:04:22) >> >> CPU: Freescale i.MX53 rev2.1 at 800 MHz >> Reset cause: WDOG > > Here the reset cause is printed correctly. > ... > ,but here it fails. > > Why does CPU version and reset cause are printed twice? I noticed that too - will investigate that later tonight. > Is this happening with all mx53 boards or only with this one? > I currently don't have access to any mx53 board to test this myself. Can't say if this happens on other boards as this is the only mx53 I have. It also happens on -rc2 = U-Boot 2015.04-rc2 (Mar 17 2015 - 01:35:15) CPU: Freescale i.MX53 rev2.1 at 800 MHz Reset cause: POR Board: Inverse Path USB armory MkI I2C: ready DRAM: 512 MiB MMC: FSL_SDHC: 0 In:serial Out: serial Err: serial CPU: Freescale i.MX53 rev2.1 at 800 MHz Reset cause: unknown reset Net: CPU Net Initialization Failed No ethernet found. Hit any key to stop autoboot: 0 = > I am adding some folks on Cc who may have access to other mx53 boards > and could probably test whether we have a common mx53 issue here. There was some discussion not long ago about reset cause handling (especially on mx6) which I haven't had a chance to fully digest yet. -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx5: Add support for USB armory board
On Mon, Mar 16, 2015 at 1:50 PM, Chris Kuethe wrote: > U-Boot 2015.04-rc3-00209-ga74ef40-dirty (Mar 15 2015 - 22:04:22) > > CPU: Freescale i.MX53 rev2.1 at 800 MHz > Reset cause: WDOG Here the reset cause is printed correctly. > Board: Inverse Path USB armory MkI > I2C: ready > DRAM: 512 MiB > MMC: FSL_SDHC: 0 > In:serial > Out: serial > Err: serial > CPU: Freescale i.MX53 rev2.1 at 800 MHz > Reset cause: unknown reset ,but here it fails. Why does CPU version and reset cause are printed twice? Is this happening with all mx53 boards or only with this one? I currently don't have access to any mx53 board to test this myself. I am adding some folks on Cc who may have access to other mx53 boards and could probably test whether we have a common mx53 issue here. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression in bootcmd handling in v2015.04-rc3?
On Wed, Mar 11, 2015 at 10:48:25PM +0100, Karsten Merker wrote: > On Wed, Mar 11, 2015 at 03:35:02PM -0600, Stephen Warren wrote: > > On 03/11/2015 03:21 PM, Karsten Merker wrote: > > > >As a result I will need to update the Debian installation > > >documentation. As I would like to do it right this time ;-), I > > >just would like to get the confirmation that the device-specific > > >commands, such as "run bootcmd_usb0", are an "official" interface > > >that is going to stay in future u-boot versions, or - if they are > > >not - get the information what is the offical method for booting > > >from a specific device at the prompt. > > > > We don't actually have an official specification of that at present. > > doc/README.distro should probably cover this but doesn't. > > > > Suffice to say, I use those macros all the time, and I intended them > > to be used this way when I wrote the boot scripts. So, if I notice a > > change that stops them from working without extremely good reason, > > I'll complain. > > Thanks, I'll update the Debian docs accordingly. So then we're settled on "run bootcmd_usb" was unintended but "run bootcmd_usb0" is and must remain so if anything a slight update to doc/README.distro would be expected and we're good, right? Thanks guys! -- 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] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
On Tue, Mar 17, 2015 at 04:16:14PM +0100, Lukasz Majewski wrote: > Hi Heiko, > > > Hello Lukasz, > > > > Am 17.03.2015 13:56, schrieb Lukasz Majewski: > > > Hi Heiko, > > > > > >> Hello Lukasz, > > >> > > >> Am 17.03.2015 10:52, schrieb Lukasz Majewski: > > >>> Hi Heiko, > > >>> > > trigger watchdog before calling usb_gadget_handle_interrupts() > > This prevents board resets when calling dfu command on boards > > which have a watchdog. > > > > Signed-off-by: Heiko Schocher > > --- > > > > common/cmd_dfu.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c > > index e975abe..46af4cf 100644 > > --- a/common/cmd_dfu.c > > +++ b/common/cmd_dfu.c > > @@ -9,6 +9,7 @@ > > */ > > > > #include > > +#include > > #include > > #include > > #include > > @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, > > int argc, char * const argv[]) if (ctrlc()) > > goto exit; > > > > + WATCHDOG_RESET(); > > usb_gadget_handle_interrupts(); > > } > > exit: > > >>> > > >>> It seems strange for me, that we must reset watchdog when looping > > >>> in the dfu. > > >> > > >> Hmm.. maybe I overlook something, but If you look into this > > >> while(1) loop, there is no trigger of the watchdog ... and if I > > >> start the dfu command without a USB cable on the board, what > > >> triggers the boards watchdog? > > > > > > So the problem is when cable is not attached to the board and you > > > call dfu command to execute? > > > > Yes. > > For UMS gadget there is defined g_dnl_board_usb_cable_connected() > function. > > However, it is not yet supported in dfu and requires working MUIC > block, which might be not available at your board. > > > > > >>> What is the WATCHDOG interval on the affected board? > > >> > > >> ~5 seconds > > >> > > >> Ah, this is on an at91 board .. and in the > > >> drivers/serial/atmel_usart.c atmel_serial_tstc() is no > > >> WATCHDOG_RESET... > > >> > > >> So ctrlc() does not trigger the watchdog > > > > > > Could you be a bit more specific here. Does your board expect > > > ctrlc() to update watchdog, so it won't reset? > > > > I do not know, if ctrlc() must trigger the WDT ... I just looked into > > the while(1) loop in common/cmd_dfu.c. There is only ctrlc() which > > could trigger the WDT... and on at91 it does not trigger it ... > > By trigger you mean reset WDT core and don't reset the board? > > > > > If dfu transfer is started there is some output on the console, which > > triggers the WDT too ... do you have a board with a running WDT? > > On trats/trats2 we disable WDT when we enter the u-boot. This seems wrong. We should enable the WDT and then be "petting" or whatever the right term is for saying "Hey WDT, I'm alive!" which is what WATCHDOG_RESET() is really about. -- 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] Setting up MAC address for eth drivers
Hi Michal, On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek wrote: > > Hi, > > I have a question regarding setting mac address for drivers. > Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize > which is called from common/board_r.c. This is because on at least ARM kernels, the MAC is passed via the MAC's filter registers. Because of this, we need to write hwaddr even before the MAC is started. > But then there are some drivers(macb, designware, altera_tse) which also calls > mac setup from dev->init which has side effect for example when you setup CONFIG_ENV_OVERWRITE > and change mac address you can directly use it. This is probably a work-around for a shortcoming of the net/eth.c not calling write_hwaddr() when the env MAC changes. It already updates the registers used by the network stack, so presumably if those MACs are filtering incoming traffic based on the register as expected, changing the MAC after boot without rewriting that register would cause all traffic to not be returned. > It also means if there is intention to call hwaddr from dev->init > that for the first packet mac address is setup twice - in eth core init > and then before every driver use. The design of the network stack assumes the MAC is started each time a network operation is requested and stopped when done. As for the setting of the hwaddr, we should check if it changed. > I am asking this question because I would like to know the right flow > for eth mac setup. > If it is > set ethaddr xx > saveenv > reset > eth with new mac > > or if > set ethaddr > eth with new mac > should work > > The second approach looks reasonable when ethaddr is not set at all > but then at least our driver needs to be fixed to support this feature. I think the second should work ideally, but we need to add a call to eth_init() if the "ethaddr" in the env changes and set it again if so. We should also remove the calls from the drivers you identified since the framework will now do it. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DRAM initialization hangs on MX28EVK rev. D
Hello Otavio, Thanks a lot for your answer. It is now working by using the mx28evk config for uboot and specifying u-boot.sb as U-boot binary format in buildroot. Best regards Adrien On Mon, Mar 16, 2015 at 5:35 PM, Otavio Salvador wrote: > On Mon, Mar 16, 2015 at 12:51 PM, Adrien Decostre > wrote: > > Thanks a lot for your quick answer. > > If I correctly understand the board/freescale/mx28evk/README file, only > > boot up from SD card or flash is supported. It is not possible to boot > > uboot via USB (and by example the sbloader tool)? > > It is, for sure. > > http://www.denx-cs.de/doku/?q=m28evkusbdownloader > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Kernel to U-boot messaging and vice versa.
Hello, I am new to U-boot development. We are using U-Boot 1.1.4 on a MIPS 74Kc QCA 9557 processor, which is running Linux Kernel 2.6.32.27. We have a situation were our firmware keeps hanging due to some issues. We are looking into a solution where U-boot and Kernel keep communicating with each other every some minutes. If U-boot finds that there is no communication, it will reset the board. I understand that once the Linux Kernel is booted, the bootloader is not there anymore. BUT, is there any way by modifying the Linux Kernel, we can achieve periodic U-boot to Kernel communication. Thanks, -Dev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations
On 17/03/15 03:04, Stephen Warren wrote: It would be nice though if someone from the RPi Foundation could comment on the exact effect of the upper bus address bits, and why 0xc would work for RPi2 but 0x4 for the RPi 1. I wonder if the ARM cache status (enabled, disabled) interacts with the GPU cache enable in any way, e.g. burst vs. non-burst transactions on the bus or something? That's about the only reason I can see for the RPi Foundation kernel working with 0x4 bus addresses on both chips, but U-Boot needing something different on RPi2... Dom, for reference, see: http://lists.denx.de/pipermail/u-boot/2015-March/207947.html http://lists.denx.de/pipermail/u-boot/2015-March/thread.html#207947 First, remember that 2835 is a large GPU with a small ARM attached. On some platforms the ARM is not even used. The GPU boots first and may wake the arm. The GPU is the centre of the universe, and the ARM has to fit in. Okay, I'll try to explain what goes on. Here are my definitions of some terms: bus address: a VideoCore/GPU address. The lower 30-bits define the 1G of addressable memory. The top two bits define the caching alias. physical address: An ARM side address given to the VC MMU. This is a 30 bit address space. The GPU always uses bus addresses. GPU bus mastering peripherals (like DMA) use bus addresses. The ARM uses physical addresses. VC MMU: A coarse MMU used by the arm for accessing GPU memory. Each page is 16M and there are 64 pages. This maps 30-bits of physical address to 32-bits of bus address. The setup of VC MMU is handled by the GPU and by default the mapping is: 2835: first 32 pages map physical addresses 0x-0x1fff to bus addresses 0x4000-0x5. The next page maps physical adddress 0x2000 to 0x20ff to bus addresses 0x7e00 to 0x7eff 2836: first 63 pages map physical addresses 0x-0x3eff to bus addresses 0xc000-0xfefff. The next page maps physical adddress 0x3f00 to 0x3fff to bus addresses 0x7e00 to 0x7eff Bus address 0x7exx contains the peripherals. Note: the top 16M of sdram is not visible to the arm due the mapping of the peripherals. The GPU and GPU peripherals (DMA) can see it as they use bus addresses The bus address cache alias bits are: From the VideoCore processor: 0x0 L1 and L2 cache allocating and coherent 0x4 L1 non-allocating, but coherent. L2 allocating and coherent 0x8 L1 non-allocating, but coherent. L2 non-allocating, but coherent 0xc SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent From the GPU peripherals (note: all peripherals bypass the L1 cache. The arm will see this view once through the VC MMU): 0x0 Do not use 0x4 L1 non-allocating, and incoherent. L2 allocating and coherent. 0x8 L1 non-allocating, and incoherent. L2 non-allocating, but coherent 0xc SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent In general as long as VideoCore processor and GPU peripherals use the same alias everything works out. Mixing aliases requires flushing/invalidating for coherency and is generally avoided. So, on 2835 the ARM has a 16K L1 cache and no L2 cache. The GPU has a 128M L2 cache. The GPU's L2 cache is accessible from the ARM but it's not particularly close (i.e. not very fast). However mapping through the L2 allocating alias (0x4) was shown to be beneficial on 2835, so that is the alias we use. The situation is different on 2836. The ARM has a 32K L1 cache and a 512M integrated/fast L2 cache. Additionally going through the smaller/slower GPU L2 is bad for performance. So, we map through the SDRAM alias (0xc) and avoid the GPU L2 cache. So, what does this mean? In general if you don't use GPU peripherals or communicate with the GPU, you only care about physical addresses and it makes no difference what bus address is actually being used. The ARM just sees 1G of physical space that is always coherent. No flushing of GPU L2 cache is ever required. No need to know about aliases. However if you do want to use GPU bus mastering peripherals (like DMA), or you communicate with the GPU (e.g. using the mailbox interface) you do need to distinguish physical and bus addresses, and you must use the correct alias. So, on 2835 you convert from physical to bus address with bus_address = 0x4000 | physical_address; And on 2836 you convert from physical to bus address with bus_address = 0xC000 | physical_address; (Note: you can get these offsets from device tree. See: https://github.com/raspberrypi/userland/commit/3b81b91c18ff19f97033e146a9f3262ca631f0e9#diff-c65a4fe18bb33aed0fc9536339f06b80R168) So, when using GPU DMA, the addresses used for SCB, SA (source address), DA (dest address) must never be zero. They should be bus addresses and therefore 0x4 or 0xc aliases. However the difference between a 0x0 alias and a 0x4 alias is small. Using 0x0 is wrong, may be incoherent, and may trigger exceptions on the GPU. But you may get awa
Re: [U-Boot] [PATCH v3] mpc85xx/T104xD4RDB: Add T104xD4RDB boards support
On 03/17/2015 04:59 AM, Vijay Rai wrote: > T1040D4RDB is a Freescale reference board that hosts the T1040 SoC. > T1040D4RDB is re-designed T1040RDB board with following changes : > - Support of DDR4 memory > - Support of 0x66 serdes protocol which can support following interfaces > - 2 RGMII's on DTSEC4, DTSEC5 > - 1 SGMII on DTSEC3 > - Support of QE-TDM > > Similarily T1042D4RDB is a Freescale reference board that hosts the T1040 > SoC. T1042D4RDB is re-designed T1042RDB board with following changes : > - Support of DDR4 memory > - Support for 0x86 serdes protocol which can support following interfaces > - 2 RGMII's on DTSEC4, DTSEC5 > - 3 SGMII on DTSEC1, DTSEC2 & DTSEC3 > - Support of DIU > > Signed-off-by: Vijay Rai > Signed-off-by: Priyanka Jain > --- > changes from v2 : > - removes checkpatch error You sent v3 twice, didn't you? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
Hi Heiko, > Hello Lukasz, > > Am 17.03.2015 13:56, schrieb Lukasz Majewski: > > Hi Heiko, > > > >> Hello Lukasz, > >> > >> Am 17.03.2015 10:52, schrieb Lukasz Majewski: > >>> Hi Heiko, > >>> > trigger watchdog before calling usb_gadget_handle_interrupts() > This prevents board resets when calling dfu command on boards > which have a watchdog. > > Signed-off-by: Heiko Schocher > --- > > common/cmd_dfu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c > index e975abe..46af4cf 100644 > --- a/common/cmd_dfu.c > +++ b/common/cmd_dfu.c > @@ -9,6 +9,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, > int argc, char * const argv[]) if (ctrlc()) > goto exit; > > +WATCHDOG_RESET(); > usb_gadget_handle_interrupts(); > } > exit: > >>> > >>> It seems strange for me, that we must reset watchdog when looping > >>> in the dfu. > >> > >> Hmm.. maybe I overlook something, but If you look into this > >> while(1) loop, there is no trigger of the watchdog ... and if I > >> start the dfu command without a USB cable on the board, what > >> triggers the boards watchdog? > > > > So the problem is when cable is not attached to the board and you > > call dfu command to execute? > > Yes. For UMS gadget there is defined g_dnl_board_usb_cable_connected() function. However, it is not yet supported in dfu and requires working MUIC block, which might be not available at your board. > > >>> What is the WATCHDOG interval on the affected board? > >> > >> ~5 seconds > >> > >> Ah, this is on an at91 board .. and in the > >> drivers/serial/atmel_usart.c atmel_serial_tstc() is no > >> WATCHDOG_RESET... > >> > >> So ctrlc() does not trigger the watchdog > > > > Could you be a bit more specific here. Does your board expect > > ctrlc() to update watchdog, so it won't reset? > > I do not know, if ctrlc() must trigger the WDT ... I just looked into > the while(1) loop in common/cmd_dfu.c. There is only ctrlc() which > could trigger the WDT... and on at91 it does not trigger it ... By trigger you mean reset WDT core and don't reset the board? > > If dfu transfer is started there is some output on the console, which > triggers the WDT too ... do you have a board with a running WDT? On trats/trats2 we disable WDT when we enter the u-boot. I can imagine following situation when WDT is enabled when u-boot starts (its timeout is ~5sec) and then you start dfu transfer with not connected cable. Then 5sec pass since cable is not connected and no transfer is ongoing. This causes board reset by WDT. Am I right? > > bye, > Heiko -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 4/4] paz00: enable bootmenu
On 03/17/2015 01:58 AM, Andrey Danin wrote: On 16.03.2015 21:14, Stephen Warren wrote: On 03/13/2015 04:49 PM, Andrey Danin wrote: Signed-off-by: Andrey Danin Some explanation of what these new options do might be nice; the features/benefits they enable. Are any of the options generally useful? If so, should they be enabled in tegra-common*.h? You also didn't Cc Tom Warren (Tegra maintainer) so he likely won't see the emails and hence won't apply this patch. Thanks for the reply Stephen! I will add Tom Warren to Cc next time. Bootmenu allows to create user friendly menu to choose different boot options. For example next 3 lines in boot config --- setenv bootmenu_0 "Boot kernel = setenv bootargs ..." setenv bootmenu_1 "Boot recovery = setenv bootargs ..." bootmenu 20 --- will generate bootmenu with 3 options: --- *** U-Boot Boot Menu *** Boot kernel Boot recovery U-Boot console Press UP/DOWN to move, ENTER to select --- More information about bootmenu is available at doc/README.bootmenu OK. Might it be better to use an extlinux.conf file? It already has support for displaying a menu for all the options in the file, and allowing the user to select which to boot. (Although I suspect the extlinux.conf menu could be prettied up some). I suppose your example above are more than just selecting which kernel to boot though, so perhaps extlinux.conf wouldn't work. I was focused on console part for this RFC. This patch is for testing purposes. I will use tegra config instead of paz00 next time to allow other users of tegra devices to try changes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] powerpc: mpc83xx: remove non-generic freescale boards
On 03/17/2015 08:28 AM, Masahiro Yamada wrote: [...] I marked 7/7 as Deferred. Thanks much Masahiro. As per Tom's other e-mail I'll be sending the patches soon. BTW, please stop full-quote against a big patch. Oh I apologise for this. It was already late when I realized. I'll sure pay more attention. Regards Sinan Akman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/BuR/common: use SYS_CONSOLE_OVERWRITE
From: Hannes Petermaier
We don't want that CONSOLE is redirected to LCD upon init, we rather prefer
that console is still on the serial line.
Signed-off-by: Hannes Petermaier
---
board/BuR/common/common.c |4
include/configs/bur_am335x_common.h |2 ++
2 files changed, 6 insertions(+)
diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index 18e1520..5ff8a7e 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -641,3 +641,7 @@ int board_mmc_init(bd_t *bis)
return omap_mmc_init(1, 0, 0, -1, -1);
}
#endif
+int overwrite_console(void)
+{
+ return 1;
+}
diff --git a/include/configs/bur_am335x_common.h
b/include/configs/bur_am335x_common.h
index 377e6cf..240fc46 100644
--- a/include/configs/bur_am335x_common.h
+++ b/include/configs/bur_am335x_common.h
@@ -142,6 +142,8 @@
#define CONFIG_SYS_PROMPT "U-Boot (BuR V2.0)# "
#define CONFIG_SYS_CONSOLE_INFO_QUIET
#define CONFIG_ENV_OVERWRITE /* Overwrite ethaddr / serial# */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
/* As stated above, the following choices are optional. */
#define CONFIG_SYS_LONGHELP
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iMX6 IPU configuration by EDID
Hi Luca, On 03/17/2015 03:04 AM, Luca Ellero wrote: > Hi all, > > I'm trying to configure IPU on a iMX6 based platform by reading EDID > from the external monitor. > > Everything seem to work fine except for the pixelclock. In particular my > monitor has a standard resolution of 1280x1024@60 (108 MHz pixelclock). > > When the function ipu_init_sync_panel (file ipu_disp.c) is called it > correctly receive 108 MHz as pixelclock. but during the execution of > this function it gets rounded to 130 MHz. > > I can see that the function calls clk_round_rate to round the clock to > 130 MHz but it's not clear for me how it works. > It's been a while since I've looked at this, but I believe there's a hidden fixed clock somewhere in the IPU driver. http://lists.denx.de/pipermail/u-boot/2014-January/thread.html#170363 > Can someone please tell me how to get the exact pixelclock I would like > to achieve? I've carefully read the iMX6 manual but it's not very useful > in this case. > > Another doubt that I have regards the field "ext_clk" of parameter > "ipu_di_signal_cfg_t sig". In this case, is it better to set it or not? > I believe this is supposed to be set for HDMI, such that the IPU clock is derived from the HDMI PHY clock and it's best to use the Linux driver as a guide. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
Hello Lukasz, Am 17.03.2015 13:56, schrieb Lukasz Majewski: Hi Heiko, Hello Lukasz, Am 17.03.2015 10:52, schrieb Lukasz Majewski: Hi Heiko, trigger watchdog before calling usb_gadget_handle_interrupts() This prevents board resets when calling dfu command on boards which have a watchdog. Signed-off-by: Heiko Schocher --- common/cmd_dfu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index e975abe..46af4cf 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -9,6 +9,7 @@ */ #include +#include #include #include #include @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (ctrlc()) goto exit; + WATCHDOG_RESET(); usb_gadget_handle_interrupts(); } exit: It seems strange for me, that we must reset watchdog when looping in the dfu. Hmm.. maybe I overlook something, but If you look into this while(1) loop, there is no trigger of the watchdog ... and if I start the dfu command without a USB cable on the board, what triggers the boards watchdog? So the problem is when cable is not attached to the board and you call dfu command to execute? Yes. What is the WATCHDOG interval on the affected board? ~5 seconds Ah, this is on an at91 board .. and in the drivers/serial/atmel_usart.c atmel_serial_tstc() is no WATCHDOG_RESET... So ctrlc() does not trigger the watchdog Could you be a bit more specific here. Does your board expect ctrlc() to update watchdog, so it won't reset? I do not know, if ctrlc() must trigger the WDT ... I just looked into the while(1) loop in common/cmd_dfu.c. There is only ctrlc() which could trigger the WDT... and on at91 it does not trigger it ... If dfu transfer is started there is some output on the console, which triggers the WDT too ... do you have a board with a running WDT? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] powerpc: mpc83xx: remove non-generic freescale boards
On Tue, Mar 17, 2015 at 02:07:34AM -0400, Sinan Akman wrote: > Hi Masahiro > > On 03/16/2015 11:28 PM, Masahiro Yamada wrote: > >Remove MPC8308RDB, MPC8313ERDB, MPC8315ERDB, MPC8323ERDB, > >MPC832XEMDS, MPC8349EMDS, MPC8349ITX, and MPC837XEMDS. > > I had sent an e-mail on that few weeks ago : > > http://lists.denx.de/pipermail/u-boot/2015-February/203613.html > > I am receiving the boards from FSL and I would like to > take over the maintainership of MPC8323ERDB and MPC8308RDB > boards. I should have them in about a week. > > Could you please delay the removal of those two boards > to give me a bit time to test generic board changes on the > actual board. I really like to keep those boards supported. Can you please start with a patch that adds yourself to MAINTAINERS? Thanks. And based on other mpc83xx boards having already been converted to generic board doing the switch now and making sure it compiles is probably OK enough for now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mmc: fsl_esdhc fix register offset
On Tue, Mar 10, 2015 at 03:35:46PM +0800, Peng Fan wrote: > Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces > error register offset. > > Change the "char reserved3[59]" to "char reserved3[56]". > > Signed-off-by: Peng Fan > Tested-by: Fabio Estevam 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] odroid: defconfig: fix build break caused by missing dts
On Tue, Mar 10, 2015 at 10:52:59AM +0100, Przemyslaw Marczak wrote: > The build break was caused by one of my previous commit: > 'odroid: defconfig: disable memset at malloc init' > > It removes the dts from odroid defconfig - rebase mistake. > > Signed-off-by: Przemyslaw Marczak > Cc: Minkyu Kang > Acked-by: Lukasz Majewski > Acked-by: Minkyu Kang 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] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
Hi Heiko, > Hello Lukasz, > > Am 17.03.2015 10:52, schrieb Lukasz Majewski: > > Hi Heiko, > > > >> trigger watchdog before calling usb_gadget_handle_interrupts() > >> This prevents board resets when calling dfu command on boards > >> which have a watchdog. > >> > >> Signed-off-by: Heiko Schocher > >> --- > >> > >> common/cmd_dfu.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c > >> index e975abe..46af4cf 100644 > >> --- a/common/cmd_dfu.c > >> +++ b/common/cmd_dfu.c > >> @@ -9,6 +9,7 @@ > >>*/ > >> > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int > >> argc, char * const argv[]) if (ctrlc()) > >>goto exit; > >> > >> + WATCHDOG_RESET(); > >>usb_gadget_handle_interrupts(); > >>} > >> exit: > > > > It seems strange for me, that we must reset watchdog when looping in > > the dfu. > > Hmm.. maybe I overlook something, but If you look into this while(1) > loop, there is no trigger of the watchdog ... and if I start the dfu > command without a USB cable on the board, what triggers the boards > watchdog? So the problem is when cable is not attached to the board and you call dfu command to execute? > > > What is the WATCHDOG interval on the affected board? > > ~5 seconds > > Ah, this is on an at91 board .. and in the > drivers/serial/atmel_usart.c atmel_serial_tstc() is no > WATCHDOG_RESET... > > So ctrlc() does not trigger the watchdog Could you be a bit more specific here. Does your board expect ctrlc() to update watchdog, so it won't reset? > > bye, > Heiko -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers:usb: Check if USB Erratum A005697 is applicable on BSC913x
Check if USB Erratum A005697 is applicable on BSC913x and
add corresponding property in the device tree via device
tree fixup which is used by linux driver
Signed-off-by: Nikhil Badola
---
Depends on "drivers:usb:fsl: Add affected SOCs for USB Erratum A007792"
http://patchwork.ozlabs.org/patch/448965/
drivers/usb/host/ehci-fsl.c | 9 +
include/fsl_usb.h | 18 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index ed83eb4..2dca524 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -263,6 +263,7 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
int usb_erratum_a006261_off = -1;
int usb_erratum_a007075_off = -1;
int usb_erratum_a007792_off = -1;
+ int usb_erratum_a005697_off = -1;
int usb_mode_off = -1;
int usb_phy_off = -1;
char str[5];
@@ -346,6 +347,14 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
if (usb_erratum_a007792_off < 0)
return;
}
+ if (has_erratum_a005697()) {
+ usb_erratum_a005697_off = fdt_fixup_usb_erratum
+ (blob,
+ "fsl,usb-erratum-a005697",
+ usb_erratum_a005697_off);
+ if (usb_erratum_a005697_off < 0)
+ return;
+ }
}
}
#endif
diff --git a/include/fsl_usb.h b/include/fsl_usb.h
index 92751dd..33d9f03 100644
--- a/include/fsl_usb.h
+++ b/include/fsl_usb.h
@@ -196,6 +196,19 @@ static inline bool has_erratum_a007792(void)
return false;
}
+static inline bool has_erratum_a005697(void)
+{
+ u32 svr = get_svr();
+ u32 soc = SVR_SOC_VER(svr);
+
+ switch (soc) {
+ case SVR_9131:
+ case SVR_9132:
+ return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1);
+ }
+ return false;
+}
+
#else
static inline bool has_dual_phy(void)
{
@@ -221,5 +234,10 @@ static inline bool has_erratum_a007792(void)
{
return false;
}
+
+static inline bool has_erratum_a005697(void)
+{
+ return false;
+}
#endif
#endif /*_ASM_FSL_USB_H_ */
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] powerpc: mpc83xx: remove non-generic freescale boards
2015-03-17 15:07 GMT+09:00 Sinan Akman : > > Hi Masahiro > > On 03/16/2015 11:28 PM, Masahiro Yamada wrote: >> >> Remove MPC8308RDB, MPC8313ERDB, MPC8315ERDB, MPC8323ERDB, >> MPC832XEMDS, MPC8349EMDS, MPC8349ITX, and MPC837XEMDS. > > > I had sent an e-mail on that few weeks ago : > > http://lists.denx.de/pipermail/u-boot/2015-February/203613.html > > I am receiving the boards from FSL and I would like to > take over the maintainership of MPC8323ERDB and MPC8308RDB > boards. I should have them in about a week. > > Could you please delay the removal of those two boards > to give me a bit time to test generic board changes on the > actual board. I really like to keep those boards supported. I marked 7/7 as Deferred. BTW, please stop full-quote against a big patch. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: mvtwsi: Fix problem with baud rate calculation
Hi, On 17-03-15 12:25, Stefan Roese wrote: Hi Hans, On 17.03.2015 12:15, Hans de Goede wrote: On 17-03-15 11:08, Stefan Roese wrote: The current implementation for baudrate calculation is incorrect. This part from the formula: "2 ^ (n + 1)" is not equivalent to (1 << n) but to (2 << n)! This patch fixes this and moves this calculation to a function instead of using a macro. Hmm, this does not match with what the Allwinner datasheets say: https://github.com/allwinner-zh/documents/blob/master/A20/A20%20user%20manual%20v1.3%2020141010.pdf They say: Fsamp = F 0 = Fin / 2^CLK_N F1 = F0 / (CLK_M + 1) Foscl = F1 / 10 = Fin / (2^CLK_N * (CLK_M + 1)*10) With Foscl being the ultimate i2c speed. Notice that they are talking about 2 ^ CLK_N not 2 ^ (CLK_N + 1) And they have a few examples which match this. Now it could be that a register value of 0 means CLK_N = 1, reg 1 CLK_N = 2, etc. this is not clearly specified ... This new function is taken from the Linux kernel. Interesting, because on Allwinnner / sunxi devices we are using the kernel driver formula unmodified, and things seem to work fine despite this. Could be tolerances allowing this, could be the Allwinner datasheet being unclear. I've send allwinner a mail asking them to clarify this. Good. Here the complete formula from the A38x manual: F_SCL = F_TCLK / (10 * (M + 1) * 2 ^ (N + 1)) This was detected and tested on the Marvell Armada A38x DB-88F6820-GP eval board. So I take it you connected a memory oscilloscope to the i2c wires ? No. I noticed that I2C doesn't work on this board with the current code. And checked for differences to the Linux code. And with this change, I2C does work on this board. Ok (note neither have I measured the actual speed on Allwinner devices), lets wait a bit to see what Allwinner has to say. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] arc: re-generate defconfigs
Before that moment our defconfigs were manually modified with addition of new options. That means once anybody wants to addd another option and re-genarate defconfig with "make defconfig" there will be lots of differences. So to make future modifications more clean we'll do bulk re-generation right away. Signed-off-by: Alexey Brodkin --- configs/arcangel4-be_defconfig | 4 ++-- configs/arcangel4_defconfig| 2 +- configs/axs101_defconfig | 6 +++--- configs/axs103_defconfig | 4 ++-- configs/tb100_defconfig| 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/configs/arcangel4-be_defconfig b/configs/arcangel4-be_defconfig index 979f26e..990c74a 100644 --- a/configs/arcangel4-be_defconfig +++ b/configs/arcangel4-be_defconfig @@ -1,5 +1,5 @@ CONFIG_ARC=y -CONFIG_TARGET_ARCANGEL4=y -CONFIG_SYS_CLK_FREQ=7000 CONFIG_CPU_BIG_ENDIAN=y +CONFIG_TARGET_ARCANGEL4=y CONFIG_SYS_TEXT_BASE=0x8100 +CONFIG_SYS_CLK_FREQ=7000 diff --git a/configs/arcangel4_defconfig b/configs/arcangel4_defconfig index 797595f..fbc0ffe 100644 --- a/configs/arcangel4_defconfig +++ b/configs/arcangel4_defconfig @@ -1,4 +1,4 @@ CONFIG_ARC=y CONFIG_TARGET_ARCANGEL4=y -CONFIG_SYS_CLK_FREQ=7000 CONFIG_SYS_TEXT_BASE=0x8100 +CONFIG_SYS_CLK_FREQ=7000 diff --git a/configs/axs101_defconfig b/configs/axs101_defconfig index 34ed963..e5e1d87 100644 --- a/configs/axs101_defconfig +++ b/configs/axs101_defconfig @@ -1,6 +1,6 @@ CONFIG_ARC=y +CONFIG_SYS_DCACHE_OFF=y +CONFIG_ARC_CACHE_LINE_SHIFT=5 CONFIG_TARGET_AXS101=y +CONFIG_SYS_TEXT_BASE=0x8100 CONFIG_SYS_CLK_FREQ=75000 -CONFIG_ARC_CACHE_LINE_SHIFT=5 -CONFIG_SYS_DCACHE_OFF=y -CONFIG_SYS_TEXT_BASE=0x8100 \ No newline at end of file diff --git a/configs/axs103_defconfig b/configs/axs103_defconfig index c63dd4a..7d662ad 100644 --- a/configs/axs103_defconfig +++ b/configs/axs103_defconfig @@ -1,5 +1,5 @@ -CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_SYS_CLK_FREQ=5000 CONFIG_ARC=y CONFIG_ISA_ARCV2=y CONFIG_TARGET_AXS101=y +CONFIG_SYS_TEXT_BASE=0x8100 +CONFIG_SYS_CLK_FREQ=5000 diff --git a/configs/tb100_defconfig b/configs/tb100_defconfig index b0e8c9f..c964272 100644 --- a/configs/tb100_defconfig +++ b/configs/tb100_defconfig @@ -1,5 +1,5 @@ CONFIG_ARC=y -CONFIG_TARGET_TB100=y -CONFIG_SYS_CLK_FREQ=5 CONFIG_ARC_CACHE_LINE_SHIFT=5 +CONFIG_TARGET_TB100=y CONFIG_SYS_TEXT_BASE=0x8400 +CONFIG_SYS_CLK_FREQ=5 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] arc: minor fixes in Kconfig
[1] Fix misspeling in ARC_CACHE_LINE_SHIFT dependency, now cache-line lenth selection is correctly enabled if either I$ or D$ are enabled. [2] Add dummy entry to target list to make sure target type is always mentioned in defconfig. Otherwise defconfig for the first target in the list will not have target name and later on with addition of the new target on top of the list in Kconfig will lead to corrupted configuration expanded from defconfig. Signed-off-by: Alexey Brodkin --- arch/arc/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 24f5c02..c044ad4 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -123,7 +123,7 @@ config ARC_CACHE_LINE_SHIFT int "Cache Line Length (as power of 2)" range 5 7 default "6" - depends on !SYS_DCACHE_OFF || !SYS_DCACHE_OFF + depends on !SYS_DCACHE_OFF || !SYS_ICACHE_OFF help Starting with ARC700 4.9, Cache line length is configurable, This option specifies "N", with Line-len = 2 power N @@ -133,6 +133,14 @@ config ARC_CACHE_LINE_SHIFT choice prompt "Target select" +config TARGET_DUMMY + bool "Dummy target" + help + Please select one of real target boards below! + This target is only meant to force "makedefconfig" to put + TARGET_xxx in defconfig even this is the first target from the list + below. + config TARGET_TB100 bool "Support tb100" -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] arc: move low-level interrupt and exception handlers in a separate file
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.
Signed-off-by: Alexey Brodkin
---
arch/arc/lib/Makefile| 1 +
arch/arc/lib/{start.S => ints_low.S} | 92 +-
arch/arc/lib/start.S | 144 ---
3 files changed, 2 insertions(+), 235 deletions(-)
copy arch/arc/lib/{start.S => ints_low.S} (50%)
diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile
index ad66ac2..b1f1fbe 100644
--- a/arch/arc/lib/Makefile
+++ b/arch/arc/lib/Makefile
@@ -19,6 +19,7 @@ obj-y += memset.o
obj-y += reset.o
obj-y += timer.o
obj-y += start.o
+obj-y += ints_low.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/arch/arc/lib/start.S b/arch/arc/lib/ints_low.S
similarity index 50%
copy from arch/arc/lib/start.S
copy to arch/arc/lib/ints_low.S
index 39eace3..161cf37 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/ints_low.S
@@ -1,13 +1,10 @@
/*
- * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved.
+ * Copyright (C) 2013-2015 Synopsys, Inc. All rights reserved.
*
* SPDX-License-Identifier:GPL-2.0+
*/
-#include
-#include
#include
-#include
/*
* Note on the LD/ST addressing modes with address register write-back
@@ -89,27 +86,6 @@
#endif
.endm
-ENTRY(_start)
- /* Setup interrupt vector base that matches "__text_start" */
- sr __ivt_start, [ARC_AUX_INTR_VEC_BASE]
-
- /* Setup stack pointer */
- mov %sp, CONFIG_SYS_INIT_SP_ADDR
- mov %fp, %sp
-
- /* Clear bss */
- mov %r0, __bss_start
- mov %r1, __bss_end
-
-clear_bss:
- st.ab 0, [%r0, 4]
- brlt%r0, %r1, clear_bss
-
- /* Zero the one and only argument of "board_init_f" */
- mov_s %r0, 0
- j board_init_f
-ENDPROC(_start)
-
ENTRY(memory_error)
SAVE_ALL_SYS
SAVE_EXCEPTION_SOURCE
@@ -173,69 +149,3 @@ ENTRY(EV_Extension)
mov %r0, %sp
j do_extension
ENDPROC(EV_Extension)
-
-/*
- * void relocate_code (addr_sp, gd, addr_moni)
- *
- * This "function" does not return, instead it continues in RAM
- * after relocating the monitor code.
- *
- * r0 = start_addr_sp
- * r1 = new__gd
- * r2 = relocaddr
- */
-ENTRY(relocate_code)
- /*
-* r0-r12 might be clobbered by C functions
-* so we use r13-r16 for storage here
-*/
- mov %r13, %r0 /* save addr_sp */
- mov %r14, %r1 /* save addr of gd */
- mov %r15, %r2 /* save addr of destination */
-
- mov %r16, %r2 /* %r9 - relocation offset */
- sub %r16, %r16, __image_copy_start
-
-/* Set up the stack */
-stack_setup:
- mov %sp, %r13
- mov %fp, %sp
-
-/* Check if monitor is loaded right in place for relocation */
- mov %r0, __image_copy_start
- cmp %r0, %r15 /* skip relocation if code loaded */
- bz do_board_init_r /* in target location already */
-
-/* Copy data (__image_copy_start - __image_copy_end) to new location */
- mov %r1, %r15
- mov %r2, __image_copy_end
- sub %r2, %r2, %r0 /* r3 <- amount of bytes to copy */
- asr %r2, %r2, 2 /* r3 <- amount of words to copy */
- mov %lp_count, %r2
- lp copy_end
- ld.ab %r2,[%r0,4]
- st.ab %r2,[%r1,4]
-copy_end:
-
-/* Fix relocations related issues */
- bl do_elf_reloc_fixups
-#ifndef CONFIG_SYS_ICACHE_OFF
- bl invalidate_icache_all
-#endif
-#ifndef CONFIG_SYS_DCACHE_OFF
- bl flush_dcache_all
-#endif
-
-/* Update position of intterupt vector table */
- lr %r0, [ARC_AUX_INTR_VEC_BASE]/* Read current position */
- add %r0, %r0, %r16 /* Update address */
- sr %r0, [ARC_AUX_INTR_VEC_BASE]/* Write new position */
-
-do_board_init_r:
-/* Prepare for exection of "board_init_r" in relocated monitor */
- mov %r2, board_init_r /* old address of "board_init_r()" */
- add %r2, %r2, %r16 /* new address of "board_init_r()" */
- mov %r0, %r14 /* 1-st parameter: gd_t */
- mov %r1, %r15 /* 2-nd parameter: dest_addr */
- j [%r2]
-ENDPROC(relocate_code)
diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index 39eace3..3408f45 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -9,86 +9,6 @@
#include
#include
-/*
- * Note on the LD/ST addressing modes with address register write-back
- *
- * LD.a same as LD.aw
- *
- * LD.areg1, [reg2, x] => Pre Incr
- * Eff Addr for load = [reg2 + x]
- *
- * LD.ab reg1, [reg2, x] => Post Incr
- * Eff Addr for loa
[U-Boot] [PATCH 3/6] arc: clean-up init procedure
Intention behind this work was elimination of as much assembly-written
code as it is possible.
In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.
It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.
Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.
Signed-off-by: Alexey Brodkin
Cc: Simon Glass
---
arch/arc/include/asm/init_helpers.h | 12 ++
arch/arc/include/asm/relocate.h | 16
arch/arc/include/asm/u-boot-arc.h | 3 ++
arch/arc/lib/Makefile | 1 +
arch/arc/lib/cpu.c | 13 ---
arch/arc/lib/init_helpers.c | 27 +
arch/arc/lib/relocate.c | 19 +
arch/arc/lib/start.S| 77 +++--
common/board_f.c| 8 ++--
9 files changed, 95 insertions(+), 81 deletions(-)
create mode 100644 arch/arc/include/asm/init_helpers.h
create mode 100644 arch/arc/include/asm/relocate.h
create mode 100644 arch/arc/lib/init_helpers.c
diff --git a/arch/arc/include/asm/init_helpers.h
b/arch/arc/include/asm/init_helpers.h
new file mode 100644
index 000..7607e19
--- /dev/null
+++ b/arch/arc/include/asm/init_helpers.h
@@ -0,0 +1,12 @@
+/*
+ * Copyright (C) 2013-2015 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_ARC_INIT_HELPERS_H
+#define _ASM_ARC_INIT_HELPERS_H
+
+int init_cache_f_r(void);
+
+#endif /* _ASM_ARC_INIT_HELPERS_H */
diff --git a/arch/arc/include/asm/relocate.h b/arch/arc/include/asm/relocate.h
new file mode 100644
index 000..4c5f923
--- /dev/null
+++ b/arch/arc/include/asm/relocate.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2013-2015 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_ARC_RELOCATE_H
+#define _ASM_ARC_RELOCATE_H
+
+#include
+
+int copy_uboot_to_ram(void);
+int clear_bss(void);
+int do_elf_reloc_fixups(void);
+
+#endif /* _ASM_ARC_RELOCATE_H */
diff --git a/arch/arc/include/asm/u-boot-arc.h
b/arch/arc/include/asm/u-boot-arc.h
index 0c0e8e6..a56ccf1 100644
--- a/arch/arc/include/asm/u-boot-arc.h
+++ b/arch/arc/include/asm/u-boot-arc.h
@@ -9,4 +9,7 @@
int arch_early_init_r(void);
+void board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
+void board_init_f_r(void) __attribute__ ((noreturn));
+
#endif /* __ASM_ARC_U_BOOT_ARC_H__ */
diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile
index b1f1fbe..b887904 100644
--- a/arch/arc/lib/Makefile
+++ b/arch/arc/lib/Makefile
@@ -20,6 +20,7 @@ obj-y += reset.o
obj-y += timer.o
obj-y += start.o
obj-y += ints_low.o
+obj-y += init_helpers.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c
index 50634b8..3c930bc 100644
--- a/arch/arc/lib/cpu.c
+++ b/arch/arc/lib/cpu.c
@@ -12,19 +12,6 @@ DECLARE_GLOBAL_DATA_PTR;
int arch_cpu_init(void)
{
-#ifdef CONFIG_SYS_ICACHE_OFF
- icache_disable();
-#else
- icache_enable();
- invalidate_icache_all();
-#endif
-
- flush_dcache_all();
-#ifdef CONFIG_SYS_DCACHE_OFF
- dcache_disable();
-#else
- dcache_enable();
-#endif
timer_init();
/* In simulation (ISS) "CHIPID" and "ARCNUM" are all "ff" */
diff --git a/arch/arc/lib/init_helpers.c b/arch/arc/lib/init_helpers.c
new file mode 100644
index 000..ef9fac2
--- /dev/null
+++ b/arch/arc/lib/init_helpers.c
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2013-2015 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int init_cache_f_r(void)
+{
+#ifdef CONFIG_SYS_ICACHE_OFF
+ icache_disable();
+#else
+ icache_enable();
+ invalidate_icache_all();
+#endif
+
+ flush_dcache_all();
+#ifdef CONFIG_SYS_DCACHE_OFF
+ dcache_disable();
+#else
+ dcache_enable();
+#endif
+ return 0;
+}
diff --git a/arch/arc/lib/relocate.c b/arch/arc/lib/relocate.c
index 7797782..5c2c2d1 100644
--- a/arch/arc/lib/relocate.c
+++ b/arch/arc/lib/relocate.c
@@ -10,6 +10,25 @@
DECLARE_GLOBAL_DATA_PTR;
+int copy_uboot_to_ram(void)
+{
+ size_t len = (size_t)&__image_copy_end - (size_t)&__image_copy_start;
+
+ memcpy((void *)gd->relocaddr, (void *)&__image_copy_start, len);
+
+ return 0;
+}
+
+int clear_bss(void)
+{
+ ulong dst_addr = (ulong)&__bss_start + gd->reloc_off;
+ size_t len = (size_t)&__bss_end - (size_t)&__bss_start;
+
+ memset((void *)dst_addr, 0x00, len);
+
+ return 0;
+}
+
/*
* Base functionality is taken from x86 version with added ARC-specifics
*/
diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index 3408f45..a9aa2b5 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -17,81 +17,30 @@ ENTRY(_start)
mov %sp, CONFIG_SYS_INIT_SP_ADDR
[U-Boot] [PATCH 1/6] arc: merge common start-up code between ARC and ARCv2
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.
Still IVTs are implemented differently so we're keeping them in separate
files.
Signed-off-by: Alexey Brodkin
---
arch/arc/cpu/arcv1/Makefile | 2 +-
arch/arc/cpu/arcv1/ivt.S| 27
arch/arc/cpu/arcv2/Makefile | 2 +-
arch/arc/cpu/arcv2/ivt.S| 27
arch/arc/cpu/arcv2/start.S | 254
arch/arc/lib/Makefile | 1 +
arch/arc/{cpu/arcv1 => lib}/start.S | 63 -
7 files changed, 82 insertions(+), 294 deletions(-)
create mode 100644 arch/arc/cpu/arcv1/ivt.S
create mode 100644 arch/arc/cpu/arcv2/ivt.S
delete mode 100644 arch/arc/cpu/arcv2/start.S
rename arch/arc/{cpu/arcv1 => lib}/start.S (82%)
diff --git a/arch/arc/cpu/arcv1/Makefile b/arch/arc/cpu/arcv1/Makefile
index 3704ebe..6d17ab2 100644
--- a/arch/arc/cpu/arcv1/Makefile
+++ b/arch/arc/cpu/arcv1/Makefile
@@ -4,4 +4,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y += start.o
+obj-y += ivt.o
diff --git a/arch/arc/cpu/arcv1/ivt.S b/arch/arc/cpu/arcv1/ivt.S
new file mode 100644
index 000..7df47a2
--- /dev/null
+++ b/arch/arc/cpu/arcv1/ivt.S
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+.section .ivt, "ax",@progbits
+.align 4
+_ivt:
+ /* Critical system events */
+ j _start /* 0 - 0x000 */
+ j memory_error/* 1 - 0x008 */
+ j instruction_error /* 2 - 0x010 */
+
+ /* Device interrupts */
+.rept 29
+ j interrupt_handler /* 3:31 - 0x018:0xF8 */
+.endr
+ /* Exceptions */
+ j EV_MachineCheck /* 0x100, Fatal Machine check (0x20) */
+ j EV_TLBMissI /* 0x108, Intruction TLB miss (0x21) */
+ j EV_TLBMissD /* 0x110, Data TLB miss(0x22) */
+ j EV_TLBProtV /* 0x118, Protection Violation (0x23)
+ or Misaligned Access */
+ j EV_PrivilegeV /* 0x120, Privilege Violation (0x24) */
+ j EV_Trap /* 0x128, Trap exception (0x25) */
+ j EV_Extension/* 0x130, Extn Intruction Excp (0x26) */
diff --git a/arch/arc/cpu/arcv2/Makefile b/arch/arc/cpu/arcv2/Makefile
index cc69e5a..e338a0a 100644
--- a/arch/arc/cpu/arcv2/Makefile
+++ b/arch/arc/cpu/arcv2/Makefile
@@ -4,4 +4,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y += start.o
+obj-y += ivt.o
diff --git a/arch/arc/cpu/arcv2/ivt.S b/arch/arc/cpu/arcv2/ivt.S
new file mode 100644
index 000..d110b5b
--- /dev/null
+++ b/arch/arc/cpu/arcv2/ivt.S
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2013-2015 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+.section .ivt, "a",@progbits
+.align 4
+ /* Critical system events */
+.word _start /* 0 - 0x000 */
+.word memory_error/* 1 - 0x008 */
+.word instruction_error /* 2 - 0x010 */
+
+ /* Exceptions */
+.word EV_MachineCheck /* 0x100, Fatal Machine check (0x20) */
+.word EV_TLBMissI /* 0x108, Intruction TLB miss (0x21) */
+.word EV_TLBMissD /* 0x110, Data TLB miss(0x22) */
+.word EV_TLBProtV /* 0x118, Protection Violation (0x23)
+ or Misaligned Access */
+.word EV_PrivilegeV /* 0x120, Privilege Violation (0x24) */
+.word EV_Trap /* 0x128, Trap exception (0x25) */
+.word EV_Extension/* 0x130, Extn Intruction Excp (0x26) */
+
+ /* Device interrupts */
+.rept 29
+ j interrupt_handler /* 3:31 - 0x018:0xF8 */
+.endr
diff --git a/arch/arc/cpu/arcv2/start.S b/arch/arc/cpu/arcv2/start.S
deleted file mode 100644
index 3ce6896..000
--- a/arch/arc/cpu/arcv2/start.S
+++ /dev/null
@@ -1,254 +0,0 @@
-/*
- * Copyright (C) 2013-2015 Synopsys, Inc. All rights reserved.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-
-/*
- * Note on the LD/ST addressing modes with address register write-back
- *
- * LD.a same as LD.aw
- *
- * LD.areg1, [reg2, x] => Pre Incr
- * Eff Addr for load = [reg2 + x]
- *
- * LD.ab reg1, [reg2, x] => Post Incr
- * Eff Addr for load = [reg2]
- */
-
-.macro PUSH reg
- st.a\reg, [%sp, -4]
-.endm
-
-.macro PUSHAX aux
- lr %r9, [\aux]
- PUSH%r9
-.endm
-
-.macro SAVE_R1_TO_R24
- PUSH%r1
- PUSH%r2
- PUSH%r3
- PUSH%r4
- PUSH%r5
- PUSH%r6
- PUSH%r7
- PUSH%r8
- PUSH%r9
- PUSH%r10
- PUSH%r11
- PUSH%r12
[U-Boot] [PATCH 4/6] arc: get rid of CONFIG_SYS_GENERIC_GLOBAL_DATA
As discussed on mailing list we're drifting away from CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem() for global data. So do this for ARC architecture. Signed-off-by: Alexey Brodkin --- arch/arc/include/asm/config.h | 1 - arch/arc/lib/start.S | 7 ++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arc/include/asm/config.h b/arch/arc/include/asm/config.h index b4e9099..450adda 100644 --- a/arch/arc/include/asm/config.h +++ b/arch/arc/include/asm/config.h @@ -8,7 +8,6 @@ #define __ASM_ARC_CONFIG_H_ #define CONFIG_SYS_GENERIC_BOARD -#define CONFIG_SYS_GENERIC_GLOBAL_DATA #define CONFIG_SYS_BOOT_RAMDISK_HIGH #define CONFIG_ARCH_EARLY_INIT_R diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S index a9aa2b5..8fcd896 100644 --- a/arch/arc/lib/start.S +++ b/arch/arc/lib/start.S @@ -13,9 +13,14 @@ ENTRY(_start) /* Setup interrupt vector base that matches "__text_start" */ sr __ivt_start, [ARC_AUX_INTR_VEC_BASE] - /* Setup stack pointer */ + /* Setup stack- and frame-pointers */ mov %sp, CONFIG_SYS_INIT_SP_ADDR mov %fp, %sp + mov %r0, %sp + bl board_init_f_mem + /* Update stack- and frame-pointers */ + mov %sp, %r0 + mov %fp, %sp /* Zero the one and only argument of "board_init_f" */ mov_s %r0, 0 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] ARC updates
This patchset is meant to prepare ARC for device model utilization. The most important things done: [1] Separation of interrupt vectore tables from start.S [2] Merge of low-level start-up code (written in assembly) for ARCompat and ARCv2 architectures [3] Separation of interrupt and exception handling code in a separate source file (ints_low.S) [4] Major clean-up of start-up code and switch to heavy use of routines written in C (re-use implementations for x86 in board_f.c) Alexey Brodkin (6): arc: merge common start-up code between ARC and ARCv2 arc: move low-level interrupt and exception handlers in a separate file arc: clean-up init procedure arc: get rid of CONFIG_SYS_GENERIC_GLOBAL_DATA arc: minor fixes in Kconfig arc: re-generate defconfigs arch/arc/Kconfig| 10 +- arch/arc/cpu/arcv1/Makefile | 2 +- arch/arc/cpu/arcv1/ivt.S| 27 arch/arc/cpu/arcv1/start.S | 254 arch/arc/cpu/arcv2/Makefile | 2 +- arch/arc/cpu/arcv2/ivt.S| 27 arch/arc/cpu/arcv2/start.S | 254 arch/arc/include/asm/config.h | 1 - arch/arc/include/asm/init_helpers.h | 12 ++ arch/arc/include/asm/relocate.h | 16 +++ arch/arc/include/asm/u-boot-arc.h | 3 + arch/arc/lib/Makefile | 3 + arch/arc/lib/cpu.c | 13 -- arch/arc/lib/init_helpers.c | 27 arch/arc/lib/ints_low.S | 151 + arch/arc/lib/relocate.c | 19 +++ arch/arc/lib/start.S| 51 common/board_f.c| 8 +- configs/arcangel4-be_defconfig | 4 +- configs/arcangel4_defconfig | 2 +- configs/axs101_defconfig| 6 +- configs/axs103_defconfig| 4 +- configs/tb100_defconfig | 4 +- 23 files changed, 361 insertions(+), 539 deletions(-) create mode 100644 arch/arc/cpu/arcv1/ivt.S delete mode 100644 arch/arc/cpu/arcv1/start.S create mode 100644 arch/arc/cpu/arcv2/ivt.S delete mode 100644 arch/arc/cpu/arcv2/start.S create mode 100644 arch/arc/include/asm/init_helpers.h create mode 100644 arch/arc/include/asm/relocate.h create mode 100644 arch/arc/lib/init_helpers.c create mode 100644 arch/arc/lib/ints_low.S create mode 100644 arch/arc/lib/start.S -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1] dm: spi: Convert Freescale QSPI driver to driver model
Move the Freescale QSPI driver over to driver model.
Signed-off-by: Haikun Wang
Signed-off-by: Peng Fan
---
This patch adds DM support for FSL QSPI driver.
Now this driver can support both DM frame and old SPI frame.
Driver structure like below:
QSPI driver common code
#ifndef CONFIG_DM_SPI
Old SPI frame interface
#else
DM SPI frame interface
#endif
changes in v1: None
drivers/spi/fsl_qspi.c | 970 -
1 file changed, 645 insertions(+), 325 deletions(-)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 5e0b069..1429295 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -11,8 +11,12 @@
#include
#include
#include
+#include
+#include
#include "fsl_qspi.h"
+DECLARE_GLOBAL_DATA_PTR;
+
#define RX_BUFFER_SIZE 0x80
#ifdef CONFIG_MX6SX
#define TX_BUFFER_SIZE 0x200
@@ -63,35 +67,85 @@
#define QSPI_CMD_PP_4B 0x12/* Page program (up to 256 bytes) */
#define QSPI_CMD_SE_4B 0xdc/* Sector erase (usually 64KiB) */
-#ifdef CONFIG_SYS_FSL_QSPI_LE
-#define qspi_read32in_le32
-#define qspi_write32 out_le32
-#elif defined(CONFIG_SYS_FSL_QSPI_BE)
-#define qspi_read32in_be32
-#define qspi_write32 out_be32
-#endif
+/* fsl_qspi_platdata flags */
+#define QSPI_FLAG_REGMAP_ENDIAN_BIG(1 << 0)
-static unsigned long spi_bases[] = {
- QSPI0_BASE_ADDR,
-#ifdef CONFIG_MX6SX
- QSPI1_BASE_ADDR,
-#endif
-};
+/* default SCK frequency, unit: HZ */
+#define FSL_QSPI_DEFAULT_SCK_FREQ 5000
-static unsigned long amba_bases[] = {
- QSPI0_AMBA_BASE,
-#ifdef CONFIG_MX6SX
- QSPI1_AMBA_BASE,
+/* QSPI max chipselect signals number */
+#define FSL_QSPI_MAX_CHIPSELECT_NUM 4
+
+#ifdef CONFIG_DM_SPI
+/**
+ * struct fsl_qspi_platdata - platform data for Freescale QSPI
+ *
+ * @flags: Flags for QSPI QSPI_FLAG_...
+ * @speed_hz: Default SCK frequency
+ * @reg_base: Base address of QSPI registers
+ * @amba_base: Base address of QSPI memory mapping
+ * @amba_total_size: size of QSPI memory mapping
+ * @flash_num: Number of active slave devices
+ * @num_chipselect: Number of QSPI chipselect signals
+ */
+struct fsl_qspi_platdata {
+ u32 flags;
+ u32 speed_hz;
+ u32 reg_base;
+ u32 amba_base;
+ u32 amba_total_size;
+ u32 flash_num;
+ u32 num_chipselect;
+};
#endif
+
+/**
+ * struct fsl_qspi_priv - private data for Freescale QSPI
+ *
+ * @flags: Flags for QSPI QSPI_FLAG_...
+ * @bus_clk: QSPI input clk frequency
+ * @speed_hz: Default SCK frequency
+ * @cur_seqid: current LUT table sequence id
+ * @sf_addr: flash access offset
+ * @amba_base: Base address of QSPI memory mapping of every CS
+ * @amba_total_size: size of QSPI memory mapping
+ * @cur_amba_base: Base address of QSPI memory mapping of current CS
+ * @flash_num: Number of active slave devices
+ * @num_chipselect: Number of QSPI chipselect signals
+ * @regs: Point to QSPI register structure for I/O access
+ */
+struct fsl_qspi_priv {
+ u32 flags;
+ u32 bus_clk;
+ u32 speed_hz;
+ u32 cur_seqid;
+ u32 sf_addr;
+ u32 amba_base[FSL_QSPI_MAX_CHIPSELECT_NUM];
+ u32 amba_total_size;
+ u32 cur_amba_base;
+ u32 flash_num;
+ u32 num_chipselect;
+ struct fsl_qspi_regs *regs;
};
+#ifndef CONFIG_DM_SPI
struct fsl_qspi {
struct spi_slave slave;
- unsigned long reg_base;
- unsigned long amba_base;
- u32 sf_addr;
- u8 cur_seqid;
+ struct fsl_qspi_priv priv;
};
+#endif
+
+static u32 qspi_read32(u32 flags, u32 *addr)
+{
+ return flags & QSPI_FLAG_REGMAP_ENDIAN_BIG ?
+ in_be32(addr) : in_le32(addr);
+}
+
+static void qspi_write32(u32 flags, u32 *addr, u32 val)
+{
+ flags & QSPI_FLAG_REGMAP_ENDIAN_BIG ?
+ out_be32(addr, val) : out_le32(addr, val);
+}
/* QSPI support swapping the flash read/write data
* in hardware for LS102xA, but not for VF610 */
@@ -104,131 +158,135 @@ static inline u32 qspi_endian_xchg(u32 data)
#endif
}
-static inline struct fsl_qspi *to_qspi_spi(struct spi_slave *slave)
-{
- return container_of(slave, struct fsl_qspi, slave);
-}
-
-static void qspi_set_lut(struct fsl_qspi *qspi)
+static void qspi_set_lut(struct fsl_qspi_priv *priv)
{
- struct fsl_qspi_regs *regs = (struct fsl_qspi_regs *)qspi->reg_base;
+ struct fsl_qspi_regs *regs = priv->regs;
u32 lut_base;
/* Unlock the LUT */
- qspi_write32(®s->lutkey, LUT_KEY_VALUE);
- qspi_write32(®s->lckcr, QSPI_LCKCR_UNLOCK);
+ qspi_write32(priv->flags, ®s->lutkey, LUT_KEY_VALUE);
+ qspi_write32(priv->flags, ®s->lckcr, QSPI_LCKCR_UNLOCK);
/* Write Enable */
lut_base = SEQID_WREN * 4;
- qspi_write32(®s->lut[lut_base], OPRND0(QSPI_CMD_WREN) |
+ qspi_write32(priv->flags, ®s->lut[lut_base], OPRND0(QSPI_CMD_WREN) |
PAD0(LUT_PAD1) |
Re: [U-Boot] [PATCH] i2c: mvtwsi: Fix problem with baud rate calculation
Hi Hans, On 17.03.2015 12:15, Hans de Goede wrote: On 17-03-15 11:08, Stefan Roese wrote: The current implementation for baudrate calculation is incorrect. This part from the formula: "2 ^ (n + 1)" is not equivalent to (1 << n) but to (2 << n)! This patch fixes this and moves this calculation to a function instead of using a macro. Hmm, this does not match with what the Allwinner datasheets say: https://github.com/allwinner-zh/documents/blob/master/A20/A20%20user%20manual%20v1.3%2020141010.pdf They say: Fsamp = F 0 = Fin / 2^CLK_N F1 = F0 / (CLK_M + 1) Foscl = F1 / 10 = Fin / (2^CLK_N * (CLK_M + 1)*10) With Foscl being the ultimate i2c speed. Notice that they are talking about 2 ^ CLK_N not 2 ^ (CLK_N + 1) And they have a few examples which match this. Now it could be that a register value of 0 means CLK_N = 1, reg 1 CLK_N = 2, etc. this is not clearly specified ... This new function is taken from the Linux kernel. Interesting, because on Allwinnner / sunxi devices we are using the kernel driver formula unmodified, and things seem to work fine despite this. Could be tolerances allowing this, could be the Allwinner datasheet being unclear. I've send allwinner a mail asking them to clarify this. Good. Here the complete formula from the A38x manual: F_SCL = F_TCLK / (10 * (M + 1) * 2 ^ (N + 1)) This was detected and tested on the Marvell Armada A38x DB-88F6820-GP eval board. So I take it you connected a memory oscilloscope to the i2c wires ? No. I noticed that I2C doesn't work on this board with the current code. And checked for differences to the Linux code. And with this change, I2C does work on this board. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: mvtwsi: Fix problem with baud rate calculation
Hi,
On 17-03-15 11:08, Stefan Roese wrote:
The current implementation for baudrate calculation is incorrect.
This part from the formula:
"2 ^ (n + 1)" is not equivalent to (1 << n) but to (2 << n)!
This patch fixes this and moves this calculation to a function instead of using
a macro.
Hmm, this does not match with what the Allwinner datasheets say:
https://github.com/allwinner-zh/documents/blob/master/A20/A20%20user%20manual%20v1.3%2020141010.pdf
They say:
Fsamp = F 0 = Fin / 2^CLK_N
F1 = F0 / (CLK_M + 1)
Foscl = F1 / 10 = Fin / (2^CLK_N * (CLK_M + 1)*10)
With Foscl being the ultimate i2c speed. Notice that they are talking about
2 ^ CLK_N not 2 ^ (CLK_N + 1)
And they have a few examples which match this. Now it could be that a
register value of 0 means CLK_N = 1, reg 1 CLK_N = 2, etc. this is not clearly
specified ...
This new function is taken from the Linux kernel.
Interesting, because on Allwinnner / sunxi devices we are using the kernel
driver formula unmodified, and things seem to work fine despite this. Could
be tolerances allowing this, could be the Allwinner datasheet being unclear.
I've send allwinner a mail asking them to clarify this.
This was detected and tested on the Marvell Armada A38x DB-88F6820-GP eval
board.
So I take it you connected a memory oscilloscope to the i2c wires ?
Regards,
Hans
Signed-off-by: Stefan Roese
Cc: Prafulla Wadaskar
Cc: Luka Perkov
Cc: Hans de Goede
Cc: Ian Campbell
Cc: Heiko Schocher
---
drivers/i2c/mvtwsi.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 9b2ca1e..320235c 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -228,13 +228,10 @@ static int twsi_stop(int status)
return status;
}
-/*
- * Ugly formula to convert m and n values to a frequency comes from
- * TWSI specifications
- */
-
-#define TWSI_FREQUENCY(m, n) \
- (CONFIG_SYS_TCLK / (10 * (m + 1) * (1 << n)))
+static unsigned int twsi_calc_freq(const int n, const int m)
+{
+ return CONFIG_SYS_TCLK / (10 * (m + 1) * (2 << n));
+}
/*
* Reset controller.
@@ -266,7 +263,7 @@ static unsigned int twsi_i2c_set_bus_speed(struct
i2c_adapter *adap,
/* compute m, n setting for highest speed not above requested speed */
for (n = 0; n < 8; n++) {
for (m = 0; m < 16; m++) {
- tmp_speed = TWSI_FREQUENCY(m, n);
+ tmp_speed = twsi_calc_freq(n, m);
if ((tmp_speed <= requested_speed)
&& (tmp_speed > highest_speed)) {
highest_speed = tmp_speed;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do I use AM335x eth1 rather than eth0 ? [SOLVED]
We are also facing the same issue.We are trying to use phy id1 on eth1 for ethernet gigabit phy and rest is for ethernet switch.I did some of the changes w.r.t slaves and CONFIG_ADDR_PHY but nothing come out.So Kindly let me know what other changes you made in order to enable eth1 . Tj -- View this message in context: http://u-boot.10912.n7.nabble.com/How-do-I-use-AM335x-eth1-rather-than-eth0-tp152268p208620.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
Hello Lukasz, Am 17.03.2015 10:52, schrieb Lukasz Majewski: Hi Heiko, trigger watchdog before calling usb_gadget_handle_interrupts() This prevents board resets when calling dfu command on boards which have a watchdog. Signed-off-by: Heiko Schocher --- common/cmd_dfu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index e975abe..46af4cf 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -9,6 +9,7 @@ */ #include +#include #include #include #include @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (ctrlc()) goto exit; + WATCHDOG_RESET(); usb_gadget_handle_interrupts(); } exit: It seems strange for me, that we must reset watchdog when looping in the dfu. Hmm.. maybe I overlook something, but If you look into this while(1) loop, there is no trigger of the watchdog ... and if I start the dfu command without a USB cable on the board, what triggers the boards watchdog? What is the WATCHDOG interval on the affected board? ~5 seconds Ah, this is on an at91 board .. and in the drivers/serial/atmel_usart.c atmel_serial_tstc() is no WATCHDOG_RESET... So ctrlc() does not trigger the watchdog bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Setting up MAC address for eth drivers
Hi, any update on this one? Thanks, Michal On 03/13/2015 01:25 PM, Michal Simek wrote: > Hi, > > I have a question regarding setting mac address for drivers. > Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize > which is called from common/board_r.c. > > But then there are some drivers(macb, designware, altera_tse) which also calls > mac setup from dev->init which has side effect for example when you setup > CONFIG_ENV_OVERWRITE > and change mac address you can directly use it. > > It also means if there is intention to call hwaddr from dev->init > that for the first packet mac address is setup twice - in eth core init > and then before every driver use. > > I am asking this question because I would like to know the right flow > for eth mac setup. > If it is > set ethaddr xx > saveenv > reset > eth with new mac > > or if > set ethaddr > eth with new mac > should work > > The second approach looks reasonable when ethaddr is not set at all > but then at least our driver needs to be fixed to support this feature. > > Thanks, > Michal > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i2c: mvtwsi: Fix problem with baud rate calculation
The current implementation for baudrate calculation is incorrect.
This part from the formula:
"2 ^ (n + 1)" is not equivalent to (1 << n) but to (2 << n)!
This patch fixes this and moves this calculation to a function instead of using
a macro.
This new function is taken from the Linux kernel.
This was detected and tested on the Marvell Armada A38x DB-88F6820-GP eval
board.
Signed-off-by: Stefan Roese
Cc: Prafulla Wadaskar
Cc: Luka Perkov
Cc: Hans de Goede
Cc: Ian Campbell
Cc: Heiko Schocher
---
drivers/i2c/mvtwsi.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 9b2ca1e..320235c 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -228,13 +228,10 @@ static int twsi_stop(int status)
return status;
}
-/*
- * Ugly formula to convert m and n values to a frequency comes from
- * TWSI specifications
- */
-
-#define TWSI_FREQUENCY(m, n) \
- (CONFIG_SYS_TCLK / (10 * (m + 1) * (1 << n)))
+static unsigned int twsi_calc_freq(const int n, const int m)
+{
+ return CONFIG_SYS_TCLK / (10 * (m + 1) * (2 << n));
+}
/*
* Reset controller.
@@ -266,7 +263,7 @@ static unsigned int twsi_i2c_set_bus_speed(struct
i2c_adapter *adap,
/* compute m, n setting for highest speed not above requested speed */
for (n = 0; n < 8; n++) {
for (m = 0; m < 16; m++) {
- tmp_speed = TWSI_FREQUENCY(m, n);
+ tmp_speed = twsi_calc_freq(n, m);
if ((tmp_speed <= requested_speed)
&& (tmp_speed > highest_speed)) {
highest_speed = tmp_speed;
--
2.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] travis.yml: add more targets to build on travis
> -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Dienstag, 17. März 2015 08:22 > To: u-boot@lists.denx.de > Cc: Heiko Schocher; Tom Rini; Meier, Roger; Angelo Dureghello; Alison Wang > Subject: [PATCH] travis.yml: add more targets to build on travis > > - add more targets for building with buildman: > - avr32 > - m68k > > and while at it, sort the list alphabetical > > Signed-off-by: Heiko Schocher Reviewed-by: Roger Meier Thanks Heiko for pushing this forward! -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] iMX6 IPU configuration by EDID
Hi all, I'm trying to configure IPU on a iMX6 based platform by reading EDID from the external monitor. Everything seem to work fine except for the pixelclock. In particular my monitor has a standard resolution of 1280x1024@60 (108 MHz pixelclock). When the function ipu_init_sync_panel (file ipu_disp.c) is called it correctly receive 108 MHz as pixelclock. but during the execution of this function it gets rounded to 130 MHz. I can see that the function calls clk_round_rate to round the clock to 130 MHz but it's not clear for me how it works. Can someone please tell me how to get the exact pixelclock I would like to achieve? I've carefully read the iMX6 manual but it's not very useful in this case. Another doubt that I have regards the field "ext_clk" of parameter "ipu_di_signal_cfg_t sig". In this case, is it better to set it or not? Thanks Regards Luca -- Luca Ellero E-mail: luca.ell...@brickedbrain.com Internet: www.brickedbrain.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: cmd: trigger watchdog before calling usb_gadget_handle_interrupts
Hi Heiko, > trigger watchdog before calling usb_gadget_handle_interrupts() > This prevents board resets when calling dfu command on boards > which have a watchdog. > > Signed-off-by: Heiko Schocher > --- > > common/cmd_dfu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c > index e975abe..46af4cf 100644 > --- a/common/cmd_dfu.c > +++ b/common/cmd_dfu.c > @@ -9,6 +9,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -64,6 +65,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int > argc, char * const argv[]) if (ctrlc()) > goto exit; > > + WATCHDOG_RESET(); > usb_gadget_handle_interrupts(); > } > exit: It seems strange for me, that we must reset watchdog when looping in the dfu. What is the WATCHDOG interval on the affected board? -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, imx: fix spl compile for mxs boards
Hello Stefano, Am 17.03.2015 09:27, schrieb Stefano Babic: Hi Heiko, Daniel, On 17/03/2015 08:20, Heiko Schocher wrote: files in arch/arm/imx-common/ get not yet compiled for SPL case as "mxs" is missing in filter rule. This is possible, but... Yes .. I thought so too ... Signed-off-by: Heiko Schocher --- Fixes build error on for example the mx28evk_auart_console board: Building mx28evk_auart_console board... textdata bss dec hex filename 442689 36826 327648 807163 c50fb ./u-boot ...I do not understand why I can compile clean (u-boot-imx): ./tools/buildman/buildman mx28evk boards.cfg is up to date. Nothing to do. Building current source for 4 boards (4 threads, 2 jobs per thread) 400 /4 0:00:48 : mx28evk_auart_console And all mxb boards are compiled clean, too. Hmm... I just did a "make mrproper" and now I see them without this patch compiling again ... but it seems bogus to me not to add "mxs" also to the SPL build, as it is in the "else" ... did this boards use puts, printf in SPL ? spl/drivers/serial/mxs_auart.o is not compiled in the SPL case ... Hmm... no idea, why I got this error ... bye, Heiko make[1]: *** [spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl] Error 2 drivers/serial/built-in.o: In function `mxs_auart_init': /home/hs/zug/u-boot/drivers/serial/mxs_auart.c:84: undefined reference to `mxs_reset_block' make[1]: *** [spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl] Error 2 make: *** Warte auf noch nicht beendete Prozesse... arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 08946de..55fe509 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -37,7 +37,7 @@ libs-y += arch/arm/cpu/ libs-y += arch/arm/lib/ ifeq ($(CONFIG_SPL_BUILD),y) -ifneq (,$(CONFIG_MX23)$(CONFIG_MX35)$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35)) +ifneq (,$(CONFIG_MX23)$(CONFIG_MX35)$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs)) libs-y += arch/arm/imx-common/ endif else Best regards, Stefano Babic -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/kwbimage.c: Correct header size for SPI boot
On 16.03.2015 15:58, Kevin Smith wrote: If defined, the macro CONFIG_SYS_SPI_U_BOOT_OFFS allows a board to specify the offset of the payload image into the kwb image file. This value was being used to locate the image, but was not used in the "header size" field of the main header. Move the use of this macro into the function that returns the header size so that the same value is used in all places. Signed-off-by: Kevin Smith Works fine, so: Tested-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootcount: Add dcache flush to bootcount_store()
Hi Tom, On 03/13/2015 03:34 PM, Tom Rini wrote: > On Fri, Mar 13, 2015 at 09:48:56AM -0400, Tom Rini wrote: >> On Wed, Mar 11, 2015 at 09:51:38AM +0100, Stefan Roese wrote: >> >>> Without this dcache_flush the updated bootcounter may not be saved to >>> its location. >>> >>> This was detected on an iMX.6 platform using the OCRAM (internal SRAM) >>> as bootcounter storage area. And issuing "reset" from within U-Boot >>> cause the bootcounter to stay on its initial value. >>> >>> Signed-off-by: Stefan Roese >>> Reviewed-by: Tom Rini >> >> OK, this breaks some platforms: >>powerpc: + TQM850L >> +(TQM850L) drivers/built-in.o: In function `bootcount_store': >> +(TQM850L) build/../drivers/bootcount/bootcount.c:64: undefined reference to >> `flush_dcache_range' >> +(TQM850L) make[1]: *** [u-boot] Error 1 >> +(TQM850L) make: *** [sub-make] Error 2 >> >> We'll see how many others have the same problem soon and then I'll >> decide on nuking the old platforms of holding off on this change. > > Aside from the TQM 8xx family that Wolfgang owns we have mgcoge and > mgcoge3ne also breaking from this > (http://patchwork.ozlabs.org/patch/448849/) change. Wolfgang, Holger, > how do you want to proceed? We either need cache operations or dropping > bootcount from the platforms or dropping the platforms. > we still would like to keep mgcoge and mgcoge3ne support. These boards are still in maintenance. Unfortunately this week we are very busy. Next week Valentin or myself have planned to find some time to look at this. Regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bav335x support broken
Hello Gilles, On Tue, 17 Mar 2015 01:09:04 -0700, Gilles wrote: > Hi Anish, > > Yes, actually my board support is based on an older sitara patch and it works > when applied to v2015.01. But I was mistaken about the problem. > I went back to my original patch applied to v2015.01 and it gives the same > error but then moves on to SPL and boots ok. > > http://pastebin.com/A23qKkj8 > > So I guess it's safe to say that the "fat" error is not the problem. The > problem when I compile a74ef40a471d9d4bffb36a8c89744cf6fd631e6f is that it > restarts over and over. > > http://pastebin.com/wvjx4mB8 This is typically caused by the u-boot image being corrupt, or corrupting the SPL somehow, frequently because some memory is being mapped by both for conflicting uses. Check memory mappings for SPL and U-Boot including stack, BSS and malloc area locations. > Do you have any suggestions how how to find the cause of the constant > restart? I actually don't have a debugger for this hardware :-( What you can do is enable debugging (define DEBUG macro) globally, rebuild SPL and look at the console output. You can also add your own debug() or printf() calls to track which parts of your code get run and which ones don't. > Cheers, > Gilles Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, imx: fix spl compile for mxs boards
Hi Heiko, Daniel, On 17/03/2015 08:20, Heiko Schocher wrote: > files in arch/arm/imx-common/ get not yet compiled for > SPL case as "mxs" is missing in filter rule. > This is possible, but... > Signed-off-by: Heiko Schocher > > --- > > Fixes build error on for example the mx28evk_auart_console board: > > Building mx28evk_auart_console board... >textdata bss dec hex filename > 442689 36826 327648 807163 c50fb ./u-boot ...I do not understand why I can compile clean (u-boot-imx): ./tools/buildman/buildman mx28evk boards.cfg is up to date. Nothing to do. Building current source for 4 boards (4 threads, 2 jobs per thread) 400 /4 0:00:48 : mx28evk_auart_console And all mxb boards are compiled clean, too. > make[1]: *** [spl/u-boot-spl] Error 1 > make: *** [spl/u-boot-spl] Error 2 > drivers/serial/built-in.o: In function `mxs_auart_init': > /home/hs/zug/u-boot/drivers/serial/mxs_auart.c:84: undefined reference to > `mxs_reset_block' > make[1]: *** [spl/u-boot-spl] Error 1 > make: *** [spl/u-boot-spl] Error 2 > make: *** Warte auf noch nicht beendete Prozesse... > > arch/arm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 08946de..55fe509 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -37,7 +37,7 @@ libs-y += arch/arm/cpu/ > libs-y += arch/arm/lib/ > > ifeq ($(CONFIG_SPL_BUILD),y) > -ifneq (,$(CONFIG_MX23)$(CONFIG_MX35)$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 > mx35)) > +ifneq (,$(CONFIG_MX23)$(CONFIG_MX35)$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 > mx35 mxs)) > libs-y += arch/arm/imx-common/ > endif > else Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: atmel: arm926ejs: fix clock configuration
Hello Bo,
Am 17.03.2015 08:58, schrieb Bo Shen:
Hi Heiko,
On 03/17/2015 03:45 PM, Heiko Schocher wrote:
Hello Bo,
Am 13.03.2015 10:19, schrieb Bo Shen:
Config MCKR according to the datasheet sequence, or else it
will cause the MCKR configuration failed.
Remove timeout checking for clock configuration, if configure
the clock failed, let the system hang while not run in wrong
clock configuration.
Signed-off-by: Bo Shen
---
arch/arm/mach-at91/arm926ejs/clock.c | 54
+++-
1 file changed, 28 insertions(+), 26 deletions(-)
Tested on the corvus and taurus board.
Tested-by: Heiko Schocher
Thanks.
diff --git a/arch/arm/mach-at91/arm926ejs/clock.c
b/arch/arm/mach-at91/arm926ejs/clock.c
index f363982..8d6934e 100644
--- a/arch/arm/mach-at91/arm926ejs/clock.c
+++ b/arch/arm/mach-at91/arm926ejs/clock.c
@@ -195,50 +195,52 @@ int at91_clock_init(unsigned long main_clock)
void at91_plla_init(u32 pllar)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
-int timeout = AT91_PLL_LOCK_TIMEOUT;
writel(pllar, &pmc->pllar);
-while (!(readl(&pmc->sr) & (AT91_PMC_LOCKA | AT91_PMC_MCKRDY))) {
-timeout--;
-if (timeout == 0)
-break;
-}
+while (!(readl(&pmc->sr) & AT91_PMC_LOCKA))
+;
just hanging is maybe also bad ... could we hang with adding a
if (timeout == 0) {
debug("could not set PLL(A|B)\n");
timeout = AT91_PLL_LOCK_TIMEOUT;
}
Thinking about it ... have we setup here the debug uart already?
If not, forget my comment
Yes the uart is not ready. And one more thing, if the clock is not setup
correctly, then the system will run in abnormal status. So, I remove the
timeout check here.
Ok, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bav335x support broken
Hi Anish, Yes, actually my board support is based on an older sitara patch and it works when applied to v2015.01. But I was mistaken about the problem. I went back to my original patch applied to v2015.01 and it gives the same error but then moves on to SPL and boots ok. http://pastebin.com/A23qKkj8 So I guess it's safe to say that the "fat" error is not the problem. The problem when I compile a74ef40a471d9d4bffb36a8c89744cf6fd631e6f is that it restarts over and over. http://pastebin.com/wvjx4mB8 Do you have any suggestions how how to find the cause of the constant restart? I actually don't have a debugger for this hardware :-( Cheers, Gilles . > On Mar 16, 2015, at 09:14 , Anish Khurana > wrote: > > Hi Giles, > > I was browsing the code and it seems it is failing in spl_fat.c file > in function spl_load_image_fat_os() and internally calls > do_fat_read_at() function. Also I noticed that configuration is very > near to am335x( ti sitara) architecture, so probably can try some more > configure similar to am335x . > > Thanks, > Anish > > > On Mon, Mar 16, 2015 at 12:02 PM, Gilles wrote: >> Hi Anish, >> >> Thanks for pointing that out. I ran menuconfig and that fixed the >> compilation issue however, now I'm getting this error when I try to run it: >> >> spl_load_image_fat_os: error reading image args, err - -1 >> >> I guess I'll fool around with menuconfig see if there is something that >> should be enabled and isn't. (maybe you have a suggestion on this?) >> >> Anyway, I'll post updated defconfigs when I figure it out. Hopefully this is >> just a config issue. >> >> Thanks, >> Gilles >> . >> >> >>> On Mar 14, 2015, at 10:55 , Anish Khurana >>> wrote: >>> >>> Hi Gilles, >>> >>> This u-boot version is having lot of changes , they have enabled >>> Kconfig similar to Kernel and having GUI support ( make menuconfig) . >>> so if you are gettting error as you mentioned , try to add Device >>> model configurations and SYS malloc() as : >>> >>> Steps 1 make >>> Step 2 make menuconfig >>> Step 3 Device driver -> Enable driver model, enable Driver model for serial) >>> Step 4 malloc() pool , General setup --> Enable malloc() pool. >>> >>> Please try this , I think it will work. >>> >>> Thanks, >>> Anish >>> >>> >>> On Sat, Mar 14, 2015 at 10:36 AM, Gilles wrote: Folks, I posted a patch to add support for bav335x boards (a322aad99de4). The patch was tested against v2015.04-rc1 and worked perfectly but somehow, something was introduced since then which breaks the board support. There are two main errors I need to fix before posting another patch but need help with the second error. The first error is easy. Compilation throws: #error "Please define NS16550 registers size." which I can simply fix by defining CONFIG_SYS_NS16550_REG_SIZE in include/configs/bav335x.h ((( Altough I am stil puzzled as to why this was defined as -4 (where?) on v2015.04-rc1 ))) After adding the define, everything compiles up to failing on the final link with: drivers/serial/built-in.o: In function `get_current': /home/gilles/bbdev/u-boot/drivers/serial/serial.c:389: undefined reference to `default_serial_console' drivers/serial/built-in.o: In function `serial_initialize': Can anyone please explain what changed between 2015.04-rc1 and 2015.04-rc2 which could cause such a behavior? I have spent the last couple hours re-basing a branch to see where it breaks as to maybe get a clue on what changed but no luck so far. Any tips would be appreciated. Thanks, Gilles . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: atmel: arm926ejs: fix clock configuration
Hi Heiko,
On 03/17/2015 03:45 PM, Heiko Schocher wrote:
Hello Bo,
Am 13.03.2015 10:19, schrieb Bo Shen:
Config MCKR according to the datasheet sequence, or else it
will cause the MCKR configuration failed.
Remove timeout checking for clock configuration, if configure
the clock failed, let the system hang while not run in wrong
clock configuration.
Signed-off-by: Bo Shen
---
arch/arm/mach-at91/arm926ejs/clock.c | 54
+++-
1 file changed, 28 insertions(+), 26 deletions(-)
Tested on the corvus and taurus board.
Tested-by: Heiko Schocher
Thanks.
diff --git a/arch/arm/mach-at91/arm926ejs/clock.c
b/arch/arm/mach-at91/arm926ejs/clock.c
index f363982..8d6934e 100644
--- a/arch/arm/mach-at91/arm926ejs/clock.c
+++ b/arch/arm/mach-at91/arm926ejs/clock.c
@@ -195,50 +195,52 @@ int at91_clock_init(unsigned long main_clock)
void at91_plla_init(u32 pllar)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
-int timeout = AT91_PLL_LOCK_TIMEOUT;
writel(pllar, &pmc->pllar);
-while (!(readl(&pmc->sr) & (AT91_PMC_LOCKA | AT91_PMC_MCKRDY))) {
-timeout--;
-if (timeout == 0)
-break;
-}
+while (!(readl(&pmc->sr) & AT91_PMC_LOCKA))
+;
just hanging is maybe also bad ... could we hang with adding a
if (timeout == 0) {
debug("could not set PLL(A|B)\n");
timeout = AT91_PLL_LOCK_TIMEOUT;
}
Thinking about it ... have we setup here the debug uart already?
If not, forget my comment
Yes the uart is not ready. And one more thing, if the clock is not setup
correctly, then the system will run in abnormal status. So, I remove the
timeout check here.
Best Regards,
Bo Shen
bye,
Heiko
}
void at91_pllb_init(u32 pllbr)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
-int timeout = AT91_PLL_LOCK_TIMEOUT;
writel(pllbr, &pmc->pllbr);
-while (!(readl(&pmc->sr) & (AT91_PMC_LOCKB | AT91_PMC_MCKRDY))) {
-timeout--;
-if (timeout == 0)
-break;
-}
+while (!(readl(&pmc->sr) & AT91_PMC_LOCKB))
+;
}
void at91_mck_init(u32 mckr)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
-int timeout = AT91_PLL_LOCK_TIMEOUT;
u32 tmp;
tmp = readl(&pmc->mckr);
-tmp &= ~(AT91_PMC_MCKR_PRES_MASK |
- AT91_PMC_MCKR_MDIV_MASK |
- AT91_PMC_MCKR_PLLADIV_MASK |
- AT91_PMC_MCKR_CSS_MASK);
-tmp |= mckr & (AT91_PMC_MCKR_PRES_MASK |
- AT91_PMC_MCKR_MDIV_MASK |
- AT91_PMC_MCKR_PLLADIV_MASK |
- AT91_PMC_MCKR_CSS_MASK);
+tmp &= ~AT91_PMC_MCKR_PRES_MASK;
+tmp |= mckr & AT91_PMC_MCKR_PRES_MASK;
writel(tmp, &pmc->mckr);
+while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+;
-while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY)) {
-timeout--;
-if (timeout == 0)
-break;
-}
+tmp = readl(&pmc->mckr);
+tmp &= ~AT91_PMC_MCKR_MDIV_MASK;
+tmp |= mckr & AT91_PMC_MCKR_MDIV_MASK;
+writel(tmp, &pmc->mckr);
+while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+;
+
+tmp = readl(&pmc->mckr);
+tmp &= ~AT91_PMC_MCKR_PLLADIV_MASK;
+tmp |= mckr & AT91_PMC_MCKR_PLLADIV_MASK;
+writel(tmp, &pmc->mckr);
+while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+;
+
+tmp = readl(&pmc->mckr);
+tmp &= ~AT91_PMC_MCKR_CSS_MASK;
+tmp |= mckr & AT91_PMC_MCKR_CSS_MASK;
+writel(tmp, &pmc->mckr);
+while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+;
}
void at91_periph_clk_enable(int id)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 4/4] paz00: enable bootmenu
On 16.03.2015 21:14, Stephen Warren wrote: On 03/13/2015 04:49 PM, Andrey Danin wrote: Signed-off-by: Andrey Danin Some explanation of what these new options do might be nice; the features/benefits they enable. Are any of the options generally useful? If so, should they be enabled in tegra-common*.h? You also didn't Cc Tom Warren (Tegra maintainer) so he likely won't see the emails and hence won't apply this patch. Thanks for the reply Stephen! I will add Tom Warren to Cc next time. Bootmenu allows to create user friendly menu to choose different boot options. For example next 3 lines in boot config --- setenv bootmenu_0 "Boot kernel = setenv bootargs ..." setenv bootmenu_1 "Boot recovery = setenv bootargs ..." bootmenu 20 --- will generate bootmenu with 3 options: --- *** U-Boot Boot Menu *** Boot kernel Boot recovery U-Boot console Press UP/DOWN to move, ENTER to select --- More information about bootmenu is available at doc/README.bootmenu I was focused on console part for this RFC. This patch is for testing purposes. I will use tegra config instead of paz00 next time to allow other users of tegra devices to try changes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: atmel: arm926ejs: fix clock configuration
Hello Bo,
Am 13.03.2015 10:19, schrieb Bo Shen:
Config MCKR according to the datasheet sequence, or else it
will cause the MCKR configuration failed.
Remove timeout checking for clock configuration, if configure
the clock failed, let the system hang while not run in wrong
clock configuration.
Signed-off-by: Bo Shen
---
arch/arm/mach-at91/arm926ejs/clock.c | 54 +++-
1 file changed, 28 insertions(+), 26 deletions(-)
Tested on the corvus and taurus board.
Tested-by: Heiko Schocher
diff --git a/arch/arm/mach-at91/arm926ejs/clock.c
b/arch/arm/mach-at91/arm926ejs/clock.c
index f363982..8d6934e 100644
--- a/arch/arm/mach-at91/arm926ejs/clock.c
+++ b/arch/arm/mach-at91/arm926ejs/clock.c
@@ -195,50 +195,52 @@ int at91_clock_init(unsigned long main_clock)
void at91_plla_init(u32 pllar)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
- int timeout = AT91_PLL_LOCK_TIMEOUT;
writel(pllar, &pmc->pllar);
- while (!(readl(&pmc->sr) & (AT91_PMC_LOCKA | AT91_PMC_MCKRDY))) {
- timeout--;
- if (timeout == 0)
- break;
- }
+ while (!(readl(&pmc->sr) & AT91_PMC_LOCKA))
+ ;
just hanging is maybe also bad ... could we hang with adding a
if (timeout == 0) {
debug("could not set PLL(A|B)\n");
timeout = AT91_PLL_LOCK_TIMEOUT;
}
Thinking about it ... have we setup here the debug uart already?
If not, forget my comment
bye,
Heiko
}
void at91_pllb_init(u32 pllbr)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
- int timeout = AT91_PLL_LOCK_TIMEOUT;
writel(pllbr, &pmc->pllbr);
- while (!(readl(&pmc->sr) & (AT91_PMC_LOCKB | AT91_PMC_MCKRDY))) {
- timeout--;
- if (timeout == 0)
- break;
- }
+ while (!(readl(&pmc->sr) & AT91_PMC_LOCKB))
+ ;
}
void at91_mck_init(u32 mckr)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
- int timeout = AT91_PLL_LOCK_TIMEOUT;
u32 tmp;
tmp = readl(&pmc->mckr);
- tmp &= ~(AT91_PMC_MCKR_PRES_MASK |
-AT91_PMC_MCKR_MDIV_MASK |
-AT91_PMC_MCKR_PLLADIV_MASK |
-AT91_PMC_MCKR_CSS_MASK);
- tmp |= mckr & (AT91_PMC_MCKR_PRES_MASK |
- AT91_PMC_MCKR_MDIV_MASK |
- AT91_PMC_MCKR_PLLADIV_MASK |
- AT91_PMC_MCKR_CSS_MASK);
+ tmp &= ~AT91_PMC_MCKR_PRES_MASK;
+ tmp |= mckr & AT91_PMC_MCKR_PRES_MASK;
writel(tmp, &pmc->mckr);
+ while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+ ;
- while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY)) {
- timeout--;
- if (timeout == 0)
- break;
- }
+ tmp = readl(&pmc->mckr);
+ tmp &= ~AT91_PMC_MCKR_MDIV_MASK;
+ tmp |= mckr & AT91_PMC_MCKR_MDIV_MASK;
+ writel(tmp, &pmc->mckr);
+ while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+ ;
+
+ tmp = readl(&pmc->mckr);
+ tmp &= ~AT91_PMC_MCKR_PLLADIV_MASK;
+ tmp |= mckr & AT91_PMC_MCKR_PLLADIV_MASK;
+ writel(tmp, &pmc->mckr);
+ while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+ ;
+
+ tmp = readl(&pmc->mckr);
+ tmp &= ~AT91_PMC_MCKR_CSS_MASK;
+ tmp |= mckr & AT91_PMC_MCKR_CSS_MASK;
+ writel(tmp, &pmc->mckr);
+ while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
+ ;
}
void at91_periph_clk_enable(int id)
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] lpc32xx: mtd: nand: add MLC NAND controller
Hi Scott,
Le Mon, 16 Mar 2015 16:30:29 -0500, Scott Wood
a écrit :
> On Sat, 2015-03-14 at 15:27 +0100, Albert ARIBAUD wrote:
> > Bonjour Scott,
> >
> > Le Fri, 13 Mar 2015 16:57:33 -0500, Scott Wood
> > a écrit :
> >
> > > On Fri, 2015-03-13 at 09:04 +0100, Albert ARIBAUD (3ADEV) wrote:
> > > > + /* go through all four small pages */
> > > > + for (i = 0; i < 4; i++) {
> > > > + /* start auto decode (reads 528 NAND bytes) */
> > > > + writel(0,
> > > > &lpc32xx_nand_mlc_registers->ecc_auto_dec_reg);
> > > > + /* wait for controller to return to ready state */
> > > > + timeout = LPC32X_NAND_TIMEOUT;
> > > > + do {
> > > > + if (timeout-- == 0)
> > > > + return -1;
> > > > + status =
> > > > readl(&lpc32xx_nand_mlc_registers->isr);
> > > > + } while (!(status & ISR_CONTROLLER_READY));
> > >
> > > How much time does 1 reads of this register equate to? Are you sure
> > > it's enough? Timeouts should generally be in terms of time, not loop
> > > iterations.
> >
> > I followed the examples in several drivers where timeouts are by
> > iteration. Note that -- while this does not void your point -- I did
> > not use 1 but 10, which at a CPU clock of 208 MHz, and assuming
> > an optimistic one instruction per cycle and two instructions per loop,
> > makes the loop last at least 960 us, well over the 600 us which the
> > NAND takes for any page programming.
>
> What if this driver ends up being used on hardware that runs
> significantly faster than 208 MHz? I could understand if it's hugely
> space-constrained SPL code (like the ones that have to fit in 4K), but
> otherwise why not make use of the timekeeping code that exists in U-Boot
> (either by reading the timer, or by putting udelay(1) in the loop body)?
The udelay(1) in the loop is ok with me -- I'll put it in v6.
> > > > +#define LARGE_PAGE_SIZE 2048
> > > > +
> > > > +int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
> > > > +{
> > > > + struct lpc32xx_oob oob;
> > > > + unsigned int page = offs / LARGE_PAGE_SIZE;
> > > > + unsigned int left = DIV_ROUND_UP(size, LARGE_PAGE_SIZE);
> > > > +
> > > > + while (left) {
> > > > + int res = read_single_page(dst, page, &oob);
> > > > + page++;
> > > > + /* if read succeeded, even if fixed by ECC */
> > > > + if (res >= 0) {
> > > > + /* skip bad block */
> > > > + if (oob.free[0].free_oob_bytes[0] != 0xff)
> > > > + continue;
> > > > + if (oob.free[0].free_oob_bytes[1] != 0xff)
> > > > + continue;
> > > > + /* page is good, keep it */
> > > > + dst += LARGE_PAGE_SIZE;
> > > > + left--;
> > > > + }
> > >
> > > You should be checking the designated page(s) of the block, rather than
> > > the current page, for the bad block markers -- and skipping the entire
> > > block if it's bad.
> >
> > Will fix this -- is there any helper function in the bad block
> > management code for this? I could not find one, but I'm no NAND expert.
>
> I don't know of any such helper -- outside of SPL it's handled via the
> BBT. fsl_ifc_spl.c is an example that checks for bad block markers, but
> it's hardcoded to assume the first two pages of a block which is a bit
> simpler than checking at the end of the block.
Thanks -- I'll dig into the BBT code to see how it's handled in my
target and put a fix in v6 based on that.
> -Scott
Cordialement,
Albert ARIBAUD
3ADEV
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, at91: corvus: move MACH_TYPE to defconfig
move MACH_TYPE into defconfig Signed-off-by: Heiko Schocher --- configs/corvus_defconfig | 2 +- include/configs/corvus.h | 3 --- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/configs/corvus_defconfig b/configs/corvus_defconfig index 266a2ab..0427e9e 100644 --- a/configs/corvus_defconfig +++ b/configs/corvus_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9M10G45,SYS_USE_NANDFLASH" +CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9M10G45,MACH_TYPE=2066,SYS_USE_NANDFLASH" CONFIG_ARM=y CONFIG_ARCH_AT91=y CONFIG_TARGET_CORVUS=y diff --git a/include/configs/corvus.h b/include/configs/corvus.h index ace511f..f5b8f9b 100644 --- a/include/configs/corvus.h +++ b/include/configs/corvus.h @@ -16,9 +16,6 @@ #include -#define MACH_TYPE_CORVUS 2066 - -#define CONFIG_MACH_TYPE MACH_TYPE_CORVUS #define CONFIG_SYS_GENERIC_BOARD /* * Warning: changing CONFIG_SYS_TEXT_BASE requires -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] travis.yml: add more targets to build on travis
- add more targets for building with buildman:
- avr32
- m68k
and while at it, sort the list alphabetical
Signed-off-by: Heiko Schocher
---
m68k build fails with:
Building current source for 48 boards (32 threads, 1 job per thread)
m68k: +M53017EVB
+(M53017EVB) arch/m68k/cpu/mcf532x/start.o: In function `_start':
+(M53017EVB) arch/m68k/cpu/mcf532x/start.S:159:(.text+0x462): relocation
truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in
.text.board_init_f section in common/built-in.o
+(M53017EVB) make[1]: *** [u-boot] Error 1
+(M53017EVB) make: *** [sub-make] Error 2
m68k: +eb_cpu5282_internal
+(eb_cpu5282_internal) common/built-in.o: In function `reserve_video':
+(eb_cpu5282_internal) common/board_f.c:500: undefined reference to
`video_setmem'
+(eb_cpu5282_internal) make[1]: *** [u-boot] Error 1
+(eb_cpu5282_internal) make: *** [sub-make] Error 2
m68k: +eb_cpu5282
+(eb_cpu5282) common/built-in.o: In function `reserve_video':
+(eb_cpu5282) common/board_f.c:500: undefined reference to `video_setmem'
+(eb_cpu5282) make[1]: *** [u-boot] Error 1
+(eb_cpu5282) make: *** [sub-make] Error 2
4503/48 0:00:01 : M5485DFE
@Alison, @Angelo: Could you look into this issue?
.travis.yml | 64 +++--
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 1d5c18a..4e20e09 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -42,14 +42,16 @@ env:
before_script:
# install toolchains based on INSTALL_TOOLCHAIN} variable
- - if [[ "${INSTALL_TOOLCHAIN}" == *ppc* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh
; fi
- - if [[ "${INSTALL_TOOLCHAIN}" == *ppc* ]]; then sh
eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh -y ; fi
- - if [[ "${INSTALL_TOOLCHAIN}" == *mips* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/mips/eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh
; fi
- - if [[ "${INSTALL_TOOLCHAIN}" == *mips* ]]; then sh
eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh -y ; fi
- if [[ "${INSTALL_TOOLCHAIN}" == *arm* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/armv5te/eldk-eglibc-i686-arm-toolchain-gmae-5.4.sh
; fi
- if [[ "${INSTALL_TOOLCHAIN}" == *arm* ]]; then sh
eldk-eglibc-i686-arm-toolchain-gmae-5.4.sh -y ; fi
- if [[ "${INSTALL_TOOLCHAIN}" == *arm* ]]; then ls -al
/opt/eldk-5.4/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi ;
fi
+ - if [[ "${INSTALL_TOOLCHAIN}" == *avr32* ]]; then ./tools/buildman/buildman
--fetch-arch avr32 ; fi
- if [[ "${INSTALL_TOOLCHAIN}" == *i386* ]]; then ./tools/buildman/buildman
sandbox --fetch-arch i386 ; fi
+ - if [[ "${INSTALL_TOOLCHAIN}" == *m68k* ]]; then ./tools/buildman/buildman
--fetch-arch m68k ; fi
+ - if [[ "${INSTALL_TOOLCHAIN}" == *mips* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/mips/eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh
; fi
+ - if [[ "${INSTALL_TOOLCHAIN}" == *mips* ]]; then sh
eldk-eglibc-i686-mips-toolchain-gmae-5.4.sh -y ; fi
+ - if [[ "${INSTALL_TOOLCHAIN}" == *ppc* ]]; then wget
ftp://ftp.denx.de/pub/eldk/5.4/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh
; fi
+ - if [[ "${INSTALL_TOOLCHAIN}" == *ppc* ]]; then sh
eldk-eglibc-i686-powerpc-toolchain-gmae-5.4.sh -y ; fi
script:
# the execution sequence for each test
@@ -98,63 +100,67 @@ matrix:
CROSS_COMPILE="/opt/eldk-5.4/mips/sysroots/i686-eldk-linux/usr/bin/mips32-linux/mips-linux-"
- env:
- TEST_CONFIG_CMD="tools/buildman/buildman --list-tool-chains"
- TEST_CMD="tools/buildman/buildman --list-error-boards atmel -x avr32"
+ TEST_CMD="tools/buildman/buildman --list-error-boards arm1136"
INSTALL_TOOLCHAIN="arm"
- env:
- TEST_CONFIG_CMD="tools/buildman/buildman --list-tool-chains"
- TEST_CMD="tools/buildman/buildman --list-error-boards denx"
+ TEST_CMD="tools/buildman/buildman --list-error-boards arm1176"
INSTALL_TOOLCHAIN="arm"
- env:
- TEST_CONFIG_CMD="tools/buildman/buildman --list-tool-chains"
- TEST_CMD="tools/buildman/buildman --list-error-boards freescale -x
powerpc,m68k,aarch64"
+ TEST_CMD="tools/buildman/buildman --list-error-boards arm720t"
INSTALL_TOOLCHAIN="arm"
- env:
- TEST_CONFIG_CMD="tools/buildman/buildman --list-tool-chains"
- TEST_CMD="tools/buildman/buildman --list-error-boards freescale -x
arm,m68k,aarch64"
- INSTALL_TOOLCHAIN="ppc"
+ TEST_CMD="tools/buildman/buildman --list-error-boards arm920t"
+ INSTALL_TOOLCHAIN="arm"
- env:
- TEST_CONFIG_CMD="tools/buildman/buildman --list-tool-chains"
- TEST_CMD="tools/buildman/buildman --list-error-boards siemens"
+ TEST_CMD="tools/buildman/buildman --list-error-boards atmel -x avr32"
INSTALL_TOOLCHAIN="arm"
- env:
- TEST_CONFIG_CMD="tools/
[U-Boot] [PATCH] arm, imx: fix spl compile for mxs boards
files in arch/arm/imx-common/ get not yet compiled for SPL case as "mxs" is missing in filter rule. Signed-off-by: Heiko Schocher --- Fixes build error on for example the mx28evk_auart_console board: Building mx28evk_auart_console board... textdata bss dec hex filename 442689 36826 327648 807163 c50fb ./u-boot make[1]: *** [spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl] Error 2 drivers/serial/built-in.o: In function `mxs_auart_init': /home/hs/zug/u-boot/drivers/serial/mxs_auart.c:84: undefined reference to `mxs_reset_block' make[1]: *** [spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl] Error 2 make: *** Warte auf noch nicht beendete Prozesse... arch/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 08946de..55fe509 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -37,7 +37,7 @@ libs-y += arch/arm/cpu/ libs-y += arch/arm/lib/ ifeq ($(CONFIG_SPL_BUILD),y) -ifneq (,$(CONFIG_MX23)$(CONFIG_MX35)$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35)) +ifneq (,$(CONFIG_MX23)$(CONFIG_MX35)$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs)) libs-y += arch/arm/imx-common/ endif else -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
