[U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
The patch adds an unified linker script file which
can be used for all currently supported MIPS targets.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Vlad Lungu v...@comsys.ro
Cc: Thomas Sailer sai...@scs.ch
Cc: Stefan Roese s...@denx.de
Cc: Wolfgang Denk w...@denx.de
Cc: Thomas Lange tho...@corelatus.se
Cc: Xiangfu Liu xian...@openmobilefree.net
---
arch/mips/cpu/u-boot.lds | 90 ++
1 file changed, 90 insertions(+)
create mode 100644 arch/mips/cpu/u-boot.lds
diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
new file mode 100644
index 000..988764d
--- /dev/null
+++ b/arch/mips/cpu/u-boot.lds
@@ -0,0 +1,90 @@
+/*
+ * (C) Copyright 2003
+ * Wolfgang Denk Engineering, w...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#if defined(CONFIG_64BIT)
+#define ELF_FMTelf64
+#define PTR_COUNT_SHIFT3
+#else
+#define ELF_FMTelf32
+#define PTR_COUNT_SHIFT2
+#endif
+
+#if defined(CONFIG_SYS_LITTLE_ENDIAN)
+#define ELF_ENDIAN tradlittlemips
+#else
+#define ELF_ENDIAN tradbigmips
+#endif
+
+#define _MIPS_FORMAT2(x) #x
+#define _MIPS_FORMAT(x,y) _MIPS_FORMAT2(x-y)
+
+#define MIPS_FORMAT_MIPS_FORMAT(ELF_FMT,ELF_ENDIAN)
+
+OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
+OUTPUT_ARCH(mips)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ *(.text*)
+ }
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : { *(.data*) }
+
+ . = .;
+ _gp = ALIGN(16) +0x7ff0;
+
+ .got : {
+ __got_start = .;
+ *(.got)
+ __got_end = .;
+ }
+
+ . = ALIGN(4);
+ .sdata : { *(.sdata*) }
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ #include u-boot.lst
+ }
+
+ uboot_end_data = .;
+
+ num_got_entries = (__got_end - __got_start) PTR_COUNT_SHIFT;
+
+ . = ALIGN(4);
+ .sbss : { *(.sbss*) }
+ .bss : {
+ *(.bss*)
+ . = ALIGN(4);
+ }
+ uboot_end = .;
+}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] MIPS: qi_lb60: remove custom u-boot.lds script
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
The qi_lb60 target produces a slightly different
image after the change than before. The value of
'num_got_entries' symbol is different:
@@ -49,7 +49,7 @@
801000b4: 80122d00lb s2,11520(zero)
801000b8: 80123500lb s2,13568(zero)
801000bc: 80123ef8lb s2,16120(zero)
-801000c0: 01390x139
+801000c0: 0136tne zero,zero,0x4
801000c4 in_ram:
801000c4: 8d0bfffclw t3,-4(t0)
This is caused by the different placement of the
'__got_start' and '__got_end' symbols between the
board specific scrip and the unified script.
board specific script:
__got_start = .;
.got : { *(.got) }
__got_end = .;
unified script:
.got : {
__got_start = .;
*(.got)
__got_end = .;
}
Despite this difference, the resulting images are
functionally identical.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Xiangfu Liu xian...@openmobilefree.net
---
board/qi/qi_lb60/u-boot.lds | 63 ---
1 file changed, 63 deletions(-)
delete mode 100644 board/qi/qi_lb60/u-boot.lds
diff --git a/board/qi/qi_lb60/u-boot.lds b/board/qi/qi_lb60/u-boot.lds
deleted file mode 100644
index b3cb869..000
--- a/board/qi/qi_lb60/u-boot.lds
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * (C) Copyright 2006
- * Ingenic Semiconductor, jl...@ingenic.cn
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_FORMAT(elf32-tradlittlemips, elf32-tradlittlemips,
elf32-tradlittlemips)
-
-OUTPUT_ARCH(mips)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data*) }
-
- . = .;
- _gp = ALIGN(16) + 0x7ff0;
-
- __got_start = .;
- .got : { *(.got) }
- __got_end = .;
-
- .sdata : { *(.sdata*) }
-
-
- . = ALIGN(4);
- .u_boot_list : {
- #include u-boot.lst
- }
-
- uboot_end_data = .;
- num_got_entries = (__got_end - __got_start) 2;
-
- . = ALIGN(4);
- .sbss : { *(.sbss*) }
- .bss : { *(.bss*) . = ALIGN(4); }
- uboot_end = .;
-}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] MIPS: pb1x00: remove custom u-boot.lds script
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All pb1x00 targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Thomas Sailer sai...@scs.ch
---
board/pb1x00/u-boot.lds | 69 ---
1 file changed, 69 deletions(-)
delete mode 100644 board/pb1x00/u-boot.lds
diff --git a/board/pb1x00/u-boot.lds b/board/pb1x00/u-boot.lds
deleted file mode 100644
index 07ddd36..000
--- a/board/pb1x00/u-boot.lds
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk Engineering, w...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-/*
-OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-bigmips)
-*/
-OUTPUT_FORMAT(elf32-tradlittlemips, elf32-tradbigmips,
elf32-tradlittlemips)
-OUTPUT_ARCH(mips)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data*) }
-
- . = .;
- _gp = ALIGN(16) + 0x7ff0;
-
- .got : {
- __got_start = .;
- *(.got)
- __got_end = .;
- }
-
- .sdata : { *(.sdata*) }
-
- . = ALIGN(4);
- .u_boot_list : {
- #include u-boot.lst
- }
-
- uboot_end_data = .;
- num_got_entries = (__got_end - __got_start) 2;
-
- . = ALIGN(4);
- .sbss (NOLOAD) : { *(.sbss*) }
- .bss (NOLOAD) : { *(.bss*) . = ALIGN(4); }
- uboot_end = .;
-}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] MIPS: dbau1x00: remove custom u-boot.lds script
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All dbau1x00 targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Thomas Lange tho...@corelatus.se
---
board/dbau1x00/u-boot.lds | 69 -
1 file changed, 69 deletions(-)
delete mode 100644 board/dbau1x00/u-boot.lds
diff --git a/board/dbau1x00/u-boot.lds b/board/dbau1x00/u-boot.lds
deleted file mode 100644
index 8a871cf..000
--- a/board/dbau1x00/u-boot.lds
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk Engineering, w...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-/*
-OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-bigmips)
-*/
-OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips, elf32-tradlittlemips)
-OUTPUT_ARCH(mips)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data*) }
-
- . = .;
- _gp = ALIGN(16) + 0x7ff0;
-
- .got : {
- __got_start = .;
- *(.got)
- __got_end = .;
- }
-
- .sdata : { *(.sdata*) }
-
- . = ALIGN(4);
- .u_boot_list : {
- #include u-boot.lst
- }
-
- uboot_end_data = .;
- num_got_entries = (__got_end - __got_start) 2;
-
- . = ALIGN(4);
- .sbss (NOLOAD) : { *(.sbss*) }
- .bss (NOLOAD) : { *(.bss*) . = ALIGN(4); }
- uboot_end = .;
-}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] MIPS: qemu-mips: use the unified u-boot.lds script
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All qemu_mips targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Vlad Lungu v...@comsys.ro
---
board/qemu-mips/u-boot.lds | 78
1 file changed, 78 deletions(-)
delete mode 100644 board/qemu-mips/u-boot.lds
diff --git a/board/qemu-mips/u-boot.lds b/board/qemu-mips/u-boot.lds
deleted file mode 100644
index cb2356f..000
--- a/board/qemu-mips/u-boot.lds
+++ /dev/null
@@ -1,78 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk Engineering, w...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-/*
-OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-bigmips)
-*/
-#if defined(CONFIG_64BIT)
-OUTPUT_FORMAT(elf64-tradbigmips, elf64-tradbigmips, elf64-tradlittlemips)
-#else
-OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips, elf32-tradlittlemips)
-#endif
-OUTPUT_ARCH(mips)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data*) }
-
- . = .;
- _gp = ALIGN(16) +0x7ff0;
-
- .got : {
- __got_start = .;
- *(.got)
- __got_end = .;
- }
-
- . = ALIGN(4);
- .sdata : { *(.sdata*) }
-
- . = ALIGN(4);
- .u_boot_list : {
- #include u-boot.lst
- }
-
- uboot_end_data = .;
-#if defined(CONFIG_64BIT)
- num_got_entries = (__got_end - __got_start) 3;
-#else
- num_got_entries = (__got_end - __got_start) 2;
-#endif
-
- . = ALIGN(4);
- .sbss : { *(.sbss*) }
- .bss : { *(.bss*) . = ALIGN(4); }
- uboot_end = .;
-}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] MIPS: vct: remove custom u-boot.lds script
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All vct targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Stefan Roese s...@denx.de
---
board/micronas/vct/u-boot.lds | 69 -
1 file changed, 69 deletions(-)
delete mode 100644 board/micronas/vct/u-boot.lds
diff --git a/board/micronas/vct/u-boot.lds b/board/micronas/vct/u-boot.lds
deleted file mode 100644
index 2ce8d0e..000
--- a/board/micronas/vct/u-boot.lds
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk Engineering, w...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips, elf32-tradlittlemips)
-OUTPUT_ARCH(mips)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data*) }
-
- . = .;
- _gp = ALIGN(16) + 0x7ff0;
-
- .got : {
- __got_start = .;
- *(.got)
- __got_end = .;
- }
-
- . = ALIGN(4);
- .sdata : { *(.sdata*) }
-
- . = ALIGN(4);
- .u_boot_list : {
- #include u-boot.lst
- }
-
- . = ALIGN(4);
- uboot_end_data = .;
- num_got_entries = (__got_end - __got_start) 2;
-
- . = ALIGN(4);
- .sbss (NOLOAD) : { *(.sbss*) }
- . = ALIGN(4);
- .bss (NOLOAD) : { *(.bss*) }
- uboot_end = .;
-}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] MIPS: incaip: remove custom u-boot.lds script
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All incaip targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Wolfgang Denk w...@denx.de
---
board/incaip/u-boot.lds | 69 ---
1 file changed, 69 deletions(-)
delete mode 100644 board/incaip/u-boot.lds
diff --git a/board/incaip/u-boot.lds b/board/incaip/u-boot.lds
deleted file mode 100644
index 8a871cf..000
--- a/board/incaip/u-boot.lds
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * (C) Copyright 2003
- * Wolfgang Denk Engineering, w...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-/*
-OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-bigmips)
-*/
-OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips, elf32-tradlittlemips)
-OUTPUT_ARCH(mips)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(4);
- .text :
- {
- *(.text*)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(4);
- .data : { *(.data*) }
-
- . = .;
- _gp = ALIGN(16) + 0x7ff0;
-
- .got : {
- __got_start = .;
- *(.got)
- __got_end = .;
- }
-
- .sdata : { *(.sdata*) }
-
- . = ALIGN(4);
- .u_boot_list : {
- #include u-boot.lst
- }
-
- uboot_end_data = .;
- num_got_entries = (__got_end - __got_start) 2;
-
- . = ALIGN(4);
- .sbss (NOLOAD) : { *(.sbss*) }
- .bss (NOLOAD) : { *(.bss*) . = ALIGN(4); }
- uboot_end = .;
-}
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/t4240qds: Fix SPI flash type
T4240QDS uses a SST instead of SPANSION SPI flash. Signed-off-by: Shaohui Xie shaohui@freescale.com --- include/configs/t4qds.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/t4qds.h b/include/configs/t4qds.h index d58c24c..b3eaf5d 100644 --- a/include/configs/t4qds.h +++ b/include/configs/t4qds.h @@ -504,7 +504,7 @@ unsigned long get_board_ddr_clk(void); */ #define CONFIG_FSL_ESPI #define CONFIG_SPI_FLASH -#define CONFIG_SPI_FLASH_SPANSION +#define CONFIG_SPI_FLASH_SST #define CONFIG_CMD_SF #define CONFIG_SF_DEFAULT_SPEED 1000 #define CONFIG_SF_DEFAULT_MODE 0 -- 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/t4240qds: fix XAUI card PHY address
Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- include/configs/t4qds.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/t4qds.h b/include/configs/t4qds.h index b3eaf5d..5f0286d 100644 --- a/include/configs/t4qds.h +++ b/include/configs/t4qds.h @@ -646,10 +646,10 @@ unsigned long get_board_ddr_clk(void); #define XFI_CARD_PORT3_PHY_ADDR0x3 #define XFI_CARD_PORT4_PHY_ADDR0x4 #define QSGMII_CARD_PHY_ADDR 0x5 -#define FM1_10GEC1_PHY_ADDR0x6 -#define FM1_10GEC2_PHY_ADDR0x7 -#define FM2_10GEC1_PHY_ADDR0x8 -#define FM2_10GEC2_PHY_ADDR0x9 +#define FM1_10GEC1_PHY_ADDR0x0 +#define FM1_10GEC2_PHY_ADDR0x1 +#define FM2_10GEC1_PHY_ADDR0x2 +#define FM2_10GEC2_PHY_ADDR0x3 #endif #ifdef CONFIG_PCI -- 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/Fman/mEMAC: mEMAC fix for 10G MAC and PHY
1. use Payload length check disable when enable MAC;
2. add XGMII support for setting MAC interface mode;
3. only enable auto negotiation for Non-XGMII mode;
4. return 0x if clause 22 is used to read 10G phy_id;
Signed-off-by: Shaohui Xie shaohui@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
arch/powerpc/include/asm/fsl_memac.h |1 +
drivers/net/fm/memac.c | 12 +---
drivers/net/fm/memac_phy.c |2 ++
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_memac.h
b/arch/powerpc/include/asm/fsl_memac.h
index d6b60e6..7359f8b 100644
--- a/arch/powerpc/include/asm/fsl_memac.h
+++ b/arch/powerpc/include/asm/fsl_memac.h
@@ -172,6 +172,7 @@ struct memac {
#define MEMAC_CMD_CFG_RX_EN0x0002 /* MAC Rx path enable */
#define MEMAC_CMD_CFG_TX_EN0x0001 /* MAC Tx path enable */
#define MEMAC_CMD_CFG_RXTX_EN (MEMAC_CMD_CFG_RX_EN | MEMAC_CMD_CFG_TX_EN)
+#define MEMAC_CMD_CFG_NO_LEN_CHK 0x2 /* Payload length check disable */
/* HASHTABLE_CTRL - Hashtable control register */
#define HASHTABLE_CTRL_MCAST_EN0x0200 /* enable mulitcast Rx hash
*/
diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c
index 32c7054..8eec7b3 100644
--- a/drivers/net/fm/memac.c
+++ b/drivers/net/fm/memac.c
@@ -51,7 +51,8 @@ static void memac_enable_mac(struct fsl_enet_mac *mac)
{
struct memac *regs = mac-base;
- setbits_be32(regs-command_config, MEMAC_CMD_CFG_RXTX_EN);
+ setbits_be32(regs-command_config, MEMAC_CMD_CFG_RXTX_EN
+ | MEMAC_CMD_CFG_NO_LEN_CHK);
}
static void memac_disable_mac(struct fsl_enet_mac *mac)
@@ -106,11 +107,16 @@ static void memac_set_interface_mode(struct fsl_enet_mac
*mac,
if_mode = ~IF_MODE_MASK;
if_mode |= (IF_MODE_GMII);
break;
+ case PHY_INTERFACE_MODE_XGMII:
+ if_mode = ~IF_MODE_MASK;
+ if_mode |= IF_MODE_XGMII;
+ break;
default:
break;
}
- /* Enable automatic speed selection */
- if_mode |= IF_MODE_EN_AUTO;
+ /* Enable automatic speed selection for Non-XGMII */
+ if (type != PHY_INTERFACE_MODE_XGMII)
+ if_mode |= IF_MODE_EN_AUTO;
debug( %s, if_mode = %x\n, __func__, if_mode);
debug( %s, if_status = %x\n, __func__, if_status);
diff --git a/drivers/net/fm/memac_phy.c b/drivers/net/fm/memac_phy.c
index ea6118b..18dc2aa 100644
--- a/drivers/net/fm/memac_phy.c
+++ b/drivers/net/fm/memac_phy.c
@@ -86,6 +86,8 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int
dev_addr,
u32 c45 = 1;
if (dev_addr == MDIO_DEVAD_NONE) {
+ if (!strcmp(bus-name, DEFAULT_FM_TGEC_MDIO_NAME))
+ return 0x;
c45 = 0; /* clause 22 */
dev_addr = regnum 0x1f;
clrbits_be32(regs-mdio_stat, MDIO_STAT_ENC);
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] MIPS: vct: remove custom u-boot.lds script
On 01/29/2013 09:31 AM, Gabor Juhos wrote: Remove the board specific linker script. It is not needed anymore, the unified MIPS linker script can be used instead. All vct targets are producing identical binary images after the change than before. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com Cc: Stefan Roese s...@denx.de I can't really test this, but it looks good. So: Acked-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smdk2416 support?
On Mon, Jan 28, 2013 at 11:40:32PM -0800, James W. wrote: uboot's source code may can't directly drive 2410 SoC peripherals, but It can work, and print U-boot logo. typo? by 2410 SoC, you actually means 2416, right? If my understand you correctly, I think you mean, with 2410 board definition in u-boot source code, I can make an u-boot image by 'make smdk2410_config', then directly use the resulted image on a 2416 board. It should work althought not all functionalities are ready. If this is true, it is a really a good news to me. 2013/1/28 Woody Wu narkewo...@gmail.com On Mon, Jan 28, 2013 at 08:40:19PM -0800, James W. wrote: ok ,I think ,you can try smdk2410, And porting it to 2416. boot from nand ? At the first phase, I think I'd better boot from nand. After then I hope I can boot from SD card. (Is that possible? Is that easy? thanks) I want to ask, to driver some very basic SoC peripherals, such as SDRAM and UARTs, how much work left to do if starting from smdk2410? But it is still strange to me, since smdk2416 has existed for a long time. Thanks a lot. 2013/1/28 Woody Wu narkewo...@gmail.com Hi, List Does u-boot have support for smdk2416? Our customized board is based on smdk2416 and I want to find a good starting point to configure/port the u-boot for our hardware. Thanks in advance. -- woody I can't go back to yesterday - because I was a different person then. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- woody I can't go back to yesterday - because I was a different person then. -- woody I can't go back to yesterday - because I was a different person then. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr
Hi all, in U-Boot version 2012.10 I used to skip relocate_code setting CONFIG_SYS_TEXT_BASE to relocaddr (obtained from bdinfo command). This since some hardware is able to configure SDRAM and load U-Boot directly to SDRAM, so relocation is useless and time consuming. Now I'm using latest git version and this isn't working anymore. Can someone explain me way? And what is the suggested way to skip relocation now. Thanks in advance Best regards Luca Ellero ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr
Dear Luca Ellero, In message 51078bfd.60...@gmail.com you wrote: in U-Boot version 2012.10 I used to skip relocate_code setting CONFIG_SYS_TEXT_BASE to relocaddr (obtained from bdinfo command). This since some hardware is able to configure SDRAM and load U-Boot directly to SDRAM, so relocation is useless and time consuming. You are wrong. relocation is not useless, even in your case. there are quite a number of configuration options that will put stuff above the U-Boot image, directly at the end of RAM (things like protected RAM, shared frame buffer, shared log buffer, etc.). In these cases, the relocation address may even be dynamic (i. e. depending on settings of environment variables, and thus unknown at compile time). Now I'm using latest git version and this isn't working anymore. Can someone explain me way? And what is the suggested way to skip relocation now. Don't. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The Empire didn't encourage its subjects to go far away, in case they saw things that might disturb them. For the same reason it had built a wall around the entire country, patrolled by the Heavenly Guard whose main function was to tread heavily on the fingers of any inha- bitants who felt they might like to step outside for five minutes for a breath of fresh air. - Terry Pratchett, _Mort_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can I read env from RAM in uboot script?
Hi John Stile,
On 01/29/2013 08:25 AM, John Stile wrote:
[snip]
I saw that.
I tried to update u-boot-1.3.4 to u-boot-2013.
I changed at91bootstrap's JUMP_ADDR from 0x23F0 to 0x21F0, as
advised by previous posts.
Now I am getting the wrong board type error from the kernel.
my board is an AT91SAM9G20EK_2MMC
I am having a hard time setting:
#define MACH_TYPE_AT91SAM9G20EK_2MMC 2288
insted of
#define MACH_TYPE_AT91SAM9G20EK1624
In had to change buildroot's .config from:
BR2_TARGET_UBOOT_BOARDNAME=at91sam9g20ek_2mmc_nandflash
to
BR2_TARGET_UBOOT_BOARDNAME=at91sam9g20ek_nandflash
whihch I suspect is the problem.
I'm trying to change the buildroots output/build/uboot-custom manually,
and rerun the build, but no luck yet.
My kernel is built with CONFIG_MACH_AT91SAM9G20EK_2MMC=y
So how do I force u-boot to agree?
Please have test with the following patch (add at91sam9g20ek 2mmc
nandflash boot support) and check whether it will solve you problem.
You should use at91sam9g20ek_2mmc_nandflash to configure the u-boot
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 2555672..ce475df 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -157,6 +157,10 @@ int board_early_init_f(void)
int board_init(void)
{
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+ /* arch number of AT91SAM9260EK-Board */
+ gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
#ifdef CONFIG_AT91SAM9G20EK
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
@@ -164,6 +168,7 @@ int board_init(void)
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9260EK;
#endif
+#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
diff --git a/boards.cfg b/boards.cfg
index e4b0d44..fa863dc 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -95,6 +95,7 @@ at91sam9g10ek_nandflash arm arm926ejs
at91sam9261ek atmel
at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek
atmel at91at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
+at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
at91sam9m10g45ek_nandflash arm arm926ejs at91sam9m10g45ek
atmel at91
at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
at91sam9rlek_dataflash arm arm926ejs at91sam9rlek
atmel at91at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
at91sam9rlek_nandflash arm arm926ejs at91sam9rlek
atmel at91at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
---
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
On Tue, Jan 29, 2013 at 12:33 AM, Marek Vasut marek.va...@gmail.com wrote:
Dear Otavio Salvador,
This enables the 'Fast Auto Pre-Charge' found in the memory chip.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Improve commit message
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
#elif defined(CONFIG_MX23)
0x01010001, 0x00010100, 0x01000101, 0x0001,
0x0101, 0x, 0x0001, 0x0101,
- 0x, 0x0001, 0x07000200, 0x00070202,
+ 0x0100, 0x0001, 0x07000200, 0x00070202,
0x0202, 0x04040a01, 0x0201, 0x0204,
0x0200, 0x19000f08, 0x0d0d, 0x02021313,
0x02061521, 0x000a, 0x00080008, 0x00200020,
I went through the u-boot mem init and detected you apparently added the
following undocumented portion of code (the writel((1 24 ...) already:
112 static void initialize_dram_values(void)
113 {
114 int i;
115
116 mxs_adjust_memory_params(dram_vals);
117
118 for (i = 0; i ARRAY_SIZE(dram_vals); i++)
119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
120
121 #ifdef CONFIG_MX23
122 writel((1 24), MXS_DRAM_BASE + (4 * 8));
123 #endif
124 }
It does enable the TRANS_LOCKOUT. So what the heck is going on here? Are you
coding this stuff at random now ? WHAT THE FUCK IS HAPPENING HERE ?!
What your tone, please.
Indeed, it does it. It has been done lng time ago when we started
looking at MX23 and it was not obvious for me it.
I will send a patch reverting it and adding a comment explaning it
there so it is documented.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
On Tue, Jan 29, 2013 at 1:14 AM, Marek Vasut ma...@denx.de wrote:
Dear Marek Vasut,
Dear Otavio Salvador,
This enables the 'Fast Auto Pre-Charge' found in the memory chip.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Improve commit message
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
#elif defined(CONFIG_MX23)
0x01010001, 0x00010100, 0x01000101, 0x0001,
0x0101, 0x, 0x0001, 0x0101,
- 0x, 0x0001, 0x07000200, 0x00070202,
+ 0x0100, 0x0001, 0x07000200, 0x00070202,
0x0202, 0x04040a01, 0x0201, 0x0204,
0x0200, 0x19000f08, 0x0d0d, 0x02021313,
0x02061521, 0x000a, 0x00080008, 0x00200020,
I went through the u-boot mem init and detected you apparently added the
following undocumented portion of code (the writel((1 24 ...) already:
112 static void initialize_dram_values(void)
113 {
114 int i;
115
116 mxs_adjust_memory_params(dram_vals);
117
118 for (i = 0; i ARRAY_SIZE(dram_vals); i++)
119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
120
121 #ifdef CONFIG_MX23
122 writel((1 24), MXS_DRAM_BASE + (4 * 8));
123 #endif
124 }
[...]
Sorry about me blowing. Anyway, I better put down the message I would like to
relay. Otavio, please follow these steps:
* Work in proper sequence -- patches must apply one after another. The same
way
you cannot build house from the roof to the ground, you can not apply patches
in
anachronistic order against their dependencies.
* Prove why your patch fixes issues -- apply proper reasoning. Do a proper
research, there's no time-limit for sending a patch. There is no deadline,
take
your time.
* Step back and slow down -- please do not roll one patch after another, wait
for more reviews. This does put a great deal of strain on everyone in the ML,
so
please be considerate ; you are flooding the mailing list for no reason ; you
are also pushing too much work on the reviewers. Thus, wait for some reviews,
then fix the issues and repost.
* Focus on the changes you make -- look at the stuff above, you need to
properly
study the code instead of rolling out random patches. Properly focus on a
single
task, finish it, then move on to the other task.
Hacking is not a race, it's an art .
I've been trying to be cooperative and to improve on the way. I (as
other humans) do mistakes but I try to fix them as soon as possible.
I've been trying to get MX23 in basic working state (for users) and do
wish to have it for next release and that's why I am trying to make
things fast; I am sorry by the patch but it is normal to make mistakes
on the way.
I am glad you noticed it but not so glad by the way you communicated it.
Regards,
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: Reset the EMI block on mx23
On Tue, Jan 29, 2013 at 12:46 AM, Marek Vasut ma...@denx.de wrote: The real reason for memory instability was the fact that the EMI block was gated and not reset throughout the boards' operation. This patch resets the EMI block properly while also reverts the memory voltage bump. The memory stability issues were caused by the EMI not being reset properly and thus there is no longer need to run the memory at higher voltage than it ought to run at. This partly reverts 8303ed128a55519f19c5f11087032d4bc4e0537a . Signed-off-by: Marek Vasut ma...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Otavio Salvador ota...@ossystems.com.br Cc: Stefano Babic sba...@denx.de --- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) NOTE: Please apply _SEVERE_ testing! I did a test with and without the patch. *Without* this patch I see an error in memony but it takes some time to it to error out. With the patch, the error is mostly instantaneous: = mtest Pattern FFDD Writing... Reading... Mem error @ 0x40087F6C: found BFFDE002, expected FFFDE002 So it seems to make it worse; but I am not sure if something else is missing too. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] MIPS: vct: remove custom u-boot.lds script
2013.01.29. 10:05 keltezéssel, Stefan Roese írta: On 01/29/2013 09:31 AM, Gabor Juhos wrote: Remove the board specific linker script. It is not needed anymore, the unified MIPS linker script can be used instead. All vct targets are producing identical binary images after the change than before. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com Cc: Stefan Roese s...@denx.de I can't really test this, but it looks good. So: Acked-by: Stefan Roese s...@denx.de Thanks! -Gabor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to CONFIG_SPL_MXS_PSWITCH_WAIT
The power switch option is compatible with i.MX23 and i.MX28 so the
configration option needs to reflect it. We choose
'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v3: None
Changes in v2:
- Rewrite short description as per Marek's request
arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +-
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
index 2ddc5bc..084def5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
@@ -30,7 +30,7 @@ void early_delay(int delay);
void mxs_power_init(void);
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void);
#else
static inline void mxs_power_wait_pswitch(void) { }
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index e9d6302..287c698 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -921,7 +921,7 @@ void mxs_power_init(void)
early_delay(1000);
}
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void)
{
struct mxs_power_regs *power_regs =
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] mx23: Document the tRAS lockout setting in memory initialization
Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to enable the 'Fast Auto Pre-Charge' found in the memory chip. The setting is applied after memory initialization and it is worth document it. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v3: - Revert initialization change and comment the code Changes in v2: - Improve commit message arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -119,6 +119,7 @@ static void initialize_dram_values(void) writel(dram_vals[i], MXS_DRAM_BASE + (4 * i)); #ifdef CONFIG_MX23 + /* Enable tRAS lockout in HW_DRAM_CTL08 */ writel((1 24), MXS_DRAM_BASE + (4 * 8)); #endif } -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] mx23evk: Adjust DRAM control register to use full 128MB of RAM
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v3: None
Changes in v2: None
board/freescale/mx23evk/spl_boot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/freescale/mx23evk/spl_boot.c
index 6007433..b6f4e7e 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = {
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
};
+#define HW_DRAM_CTL14 (0x38 2)
+#define CS_MAP 0x3
+#define INTAREF0x2
+#define HW_DRAM_CTL14_CONFIG (INTAREF 8 | CS_MAP)
+
+void mxs_adjust_memory_params(uint32_t *dram_vals)
+{
+ dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;
+}
+
void board_init_ll(void)
{
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/3] led: Use STATUS_LED_ON and STATUS_LED_OFF when calling __led_set
This fixes the gpio_led driver which needs to compare againt a STATUS_LED_ON to enable a led. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None common/cmd_led.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/common/cmd_led.c b/common/cmd_led.c index 7f5ab43..84f79fa 100644 --- a/common/cmd_led.c +++ b/common/cmd_led.c @@ -110,13 +110,15 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (led_commands[i].on) led_commands[i].on(); else - __led_set(led_commands[i].mask, 1); + __led_set(led_commands[i].mask, + STATUS_LED_ON); break; case LED_OFF: if (led_commands[i].off) led_commands[i].off(); else - __led_set(led_commands[i].mask, 0); + __led_set(led_commands[i].mask, + STATUS_LED_OFF); break; case LED_TOGGLE: if (led_commands[i].toggle) -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/3] mxs: Fix iomux.h to not break build during assembly stage
This fixes the build failure when included in mx23_olinuxino.h board config; the addition of asm/types.h is due u32 being otherwise undefined. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v6: None Changes in v5: - Extend commit log Changes in v4: - New patch Changes in v3: None Changes in v2: None arch/arm/include/asm/arch-mxs/iomux.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 7abdf58..4288715 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -21,6 +21,10 @@ #ifndef __MACH_MXS_IOMUX_H__ #define __MACH_MXS_IOMUX_H__ +#ifndef __ASSEMBLY__ + +#include asm/types.h + /* * IOMUX/PAD Bit field definitions * @@ -165,4 +169,5 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad); */ int mxs_iomux_setup_multiple_pads(const iomux_cfg_t *pad_list, unsigned count); +#endif /* __ASSEMBLY__ */ #endif /* __MACH_MXS_IOMUX_H__*/ -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 3/3] mx23_olinuxino: Add support for status LED
This allow user to know if the bootloader is running, even without a
serial console.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v6:
- Use GPIO number
Changes in v5: None
Changes in v4:
- Use MUX PIN macro
Changes in v3:
- Added the MUX settings back (requested by Fabio)
- Added name of the PIN in the board config file
Changes in v2:
- Remove MUX setting - not need
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 +++
board/olimex/mx23_olinuxino/spl_boot.c | 4
include/configs/mx23_olinuxino.h | 12
3 files changed, 23 insertions(+)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
index 6a6053b..2501417 100644
--- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
+++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
@@ -28,6 +28,9 @@
#include asm/arch/imx-regs.h
#include asm/arch/clock.h
#include asm/arch/sys_proto.h
+#ifdef CONFIG_STATUS_LED
+#include status_led.h
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -67,5 +70,9 @@ int board_init(void)
/* Adress of boot parameters */
gd-bd-bi_boot_params = PHYS_SDRAM_1 + 0x100;
+#if defined(CONFIG_STATUS_LED) defined(STATUS_LED_BOOT)
+ status_led_set(STATUS_LED_BOOT, STATUS_LED_STATE);
+#endif
+
return 0;
}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index 7def8bc..3bbf5ad 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -84,6 +84,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_EMI_RASN__EMI_RASN | MUX_CONFIG_EMI,
MX23_PAD_EMI_WEN__EMI_WEN | MUX_CONFIG_EMI,
+ /* Green LED */
+ MX23_PAD_SSP1_DETECT__GPIO_2_1 |
+ (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL),
+
/* MMC 0 */
MX23_PAD_SSP1_CMD__SSP1_CMD | MUX_CONFIG_SSP,
MX23_PAD_SSP1_DATA0__SSP1_DATA0 | MUX_CONFIG_SSP,
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index 7983c5d..968aec8 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -56,6 +56,7 @@
#defineCONFIG_CMD_EXT2
#defineCONFIG_CMD_FAT
#defineCONFIG_CMD_GPIO
+#defineCONFIG_CMD_LED
#defineCONFIG_CMD_MMC
/*
@@ -112,6 +113,17 @@
#defineCONFIG_BAUDRATE 115200 /* Default baud rate */
/*
+ * Status LED
+ */
+#defineCONFIG_STATUS_LED
+#defineCONFIG_GPIO_LED
+#defineCONFIG_BOARD_SPECIFIC_LED
+#defineSTATUS_LED_BOOT 0
+#defineSTATUS_LED_BIT 10
+#defineSTATUS_LED_STATESTATUS_LED_ON
+#defineSTATUS_LED_PERIOD (CONFIG_SYS_HZ / 2)
+
+/*
* MMC Driver
*/
#ifdef CONFIG_CMD_MMC
--
1.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/4] usb: mxs: Disable USB Port 1 for i.MX23
The i.MX23 just one USB port so disable the second controller probe when building for i.MX23. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/usb/host/ehci-mxs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c index 5062af5..28c8cde 100644 --- a/drivers/usb/host/ehci-mxs.c +++ b/drivers/usb/host/ehci-mxs.c @@ -50,10 +50,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port) usb_base = MXS_USBCTRL0_BASE; phy_base = MXS_USBPHY0_BASE; break; +#ifdef CONFIG_MX28 case 1: usb_base = MXS_USBCTRL1_BASE; phy_base = MXS_USBPHY1_BASE; break; +#endif default: printf(CONFIG_EHCI_MXS_PORT (port = %d)\n, port); return -1; -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/4] mx23evk: Enable USB support
This enabled USB support for the mx23evk board. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v4: None Changes in v3: - Add a obvious commitlog; Changes in v2: None include/configs/mx23evk.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/configs/mx23evk.h b/include/configs/mx23evk.h index d206c95..99dfb8f 100644 --- a/include/configs/mx23evk.h +++ b/include/configs/mx23evk.h @@ -58,6 +58,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_MMC +#define CONFIG_CMD_USB #define CONFIG_CMD_BOOTZ /* Memory configurations */ @@ -122,6 +123,15 @@ #define CONFIG_MXS_MMC #endif +/* USB */ +#ifdef CONFIG_CMD_USB +#defineCONFIG_USB_EHCI +#defineCONFIG_USB_EHCI_MXS +#defineCONFIG_EHCI_MXS_PORT 0 +#defineCONFIG_EHCI_IS_TDI +#defineCONFIG_USB_STORAGE +#endif + /* Boot Linux */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/4] mx23_olinuxino: Add ethernet support
This adds support to the LAN9512 chip included in the board and extend
the environment to easy netboot use.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v4:
- Fix build warning due missing gpio.h
Changes in v3:
- Remove useless newlines
- Add NOPULL in MUX setup
- Fix commitlog to say the right chip number
- Use CONFIG_CMD_USB to disable GPIO setting
Changes in v2:
- Move GPIO initialization to board_early_init_f;
- Extend commitlog;
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +
board/olimex/mx23_olinuxino/spl_boot.c | 4 +++
include/configs/mx23_olinuxino.h | 40 +---
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
index 2501417..9ed7718 100644
--- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
+++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
@@ -23,6 +23,7 @@
*/
#include common.h
+#include asm/gpio.h
#include asm/io.h
#include asm/arch/iomux-mx23.h
#include asm/arch/imx-regs.h
@@ -45,6 +46,11 @@ int board_early_init_f(void)
/* SSP0 clock at 96MHz */
mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+#ifdef CONFIG_CMD_USB
+ /* Enable LAN9512 */
+ gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);
+#endif
+
return 0;
}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/board/olimex/mx23_olinuxino/spl_boot.c
index 3bbf5ad..a96c293 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP,
MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP,
MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
+
+ /* Ethernet */
+ MX23_PAD_GPMI_ALE__GPIO_0_17 |
+ (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),
};
void board_init_ll(void)
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index 7e17809..42de557 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -53,11 +53,13 @@
#defineCONFIG_DOS_PARTITION
#defineCONFIG_CMD_CACHE
+#defineCONFIG_CMD_DHCP
#defineCONFIG_CMD_EXT2
#defineCONFIG_CMD_FAT
#defineCONFIG_CMD_GPIO
#defineCONFIG_CMD_LED
#defineCONFIG_CMD_MMC
+#defineCONFIG_CMD_NET
#defineCONFIG_CMD_USB
/*
@@ -148,6 +150,12 @@
#defineCONFIG_USB_STORAGE
#endif
+/* Ethernet */
+#ifdef CONFIG_CMD_NET
+#defineCONFIG_USB_HOST_ETHER
+#defineCONFIG_USB_ETHER_SMSC95XX
+#endif
+
/*
* Boot Linux
*/
@@ -173,6 +181,7 @@
/*
* Extra Environments
*/
+
#define CONFIG_EXTRA_ENV_SETTINGS \
update_sd_firmware_filename=u-boot.sd\0 \
update_sd_firmware= /* Update the SD firmware partition */ \
@@ -189,6 +198,7 @@
fdt_file=imx23-olinuxino.dtb\0 \
fdt_addr=0x4100\0 \
boot_fdt=try\0 \
+ ip_dyn=yes\0 \
mmcdev=0\0 \
mmcpart=2\0 \
mmcroot=/dev/mmcblk0p3 rw rootwait\0 \
@@ -214,6 +224,31 @@
fi; \
else \
bootm; \
+ fi;\0 \
+ netargs=setenv bootargs console=${console_mainline},${baudrate} \
+ root=/dev/nfs \
+ ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
+ netboot=echo Booting from net ...; \
+ usb start; \
+ run netargs; \
+ if test ${ip_dyn} = yes; then \
+ setenv get_cmd dhcp; \
+ else \
+ setenv get_cmd tftp; \
+ fi; \
+ ${get_cmd} ${uimage}; \
+ if test ${boot_fdt} = yes; then \
+ if ${get_cmd} ${fdt_addr} ${fdt_file}; then \
+ bootm ${loadaddr} - ${fdt_addr}; \
+ else \
+ if test ${boot_fdt} = try; then \
+ bootm; \
+ else \
+ echo WARN: Cannot load the DT; \
+ fi; \
+ fi; \
+ else \
+ bootm; \
fi;\0
#define CONFIG_BOOTCOMMAND \
@@ -223,10 +258,9 @@
else \
if run loaduimage; then \
run mmcboot; \
- else \
- echo ERR: Fail to boot from MMC; \
+ else run netboot; \
fi; \
fi; \
- else exit; fi
+ else run netboot; fi
#endif /* __MX23_OLINUXINO_CONFIG_H__ */
--
1.8.1
___
U-Boot mailing list
[U-Boot] [PATCH v4 3/4] mx23_olinuxino: Enable USB support
This enabled USB support for the mx23_olinuxino board. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v4: None Changes in v3: - Add a obvious commitlog; Changes in v2: None include/configs/mx23_olinuxino.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 968aec8..7e17809 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -58,6 +58,7 @@ #defineCONFIG_CMD_GPIO #defineCONFIG_CMD_LED #defineCONFIG_CMD_MMC +#defineCONFIG_CMD_USB /* * Memory configurations @@ -138,6 +139,15 @@ */ #define CONFIG_APBH_DMA +/* USB */ +#ifdef CONFIG_CMD_USB +#defineCONFIG_USB_EHCI +#defineCONFIG_USB_EHCI_MXS +#defineCONFIG_EHCI_MXS_PORT 0 +#defineCONFIG_EHCI_IS_TDI +#defineCONFIG_USB_STORAGE +#endif + /* * Boot Linux */ -- 1.8.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
2013/1/29 Gabor Juhos juh...@openwrt.org:
The patch adds an unified linker script file which
can be used for all currently supported MIPS targets.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Vlad Lungu v...@comsys.ro
Cc: Thomas Sailer sai...@scs.ch
Cc: Stefan Roese s...@denx.de
Cc: Wolfgang Denk w...@denx.de
Cc: Thomas Lange tho...@corelatus.se
Cc: Xiangfu Liu xian...@openmobilefree.net
AFAIK you can remove Vlad Lungu and Thomas Lange from the list of
board maintainers
---
arch/mips/cpu/u-boot.lds | 90
++
1 file changed, 90 insertions(+)
create mode 100644 arch/mips/cpu/u-boot.lds
diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
new file mode 100644
index 000..988764d
--- /dev/null
+++ b/arch/mips/cpu/u-boot.lds
@@ -0,0 +1,90 @@
+/*
+ * (C) Copyright 2003
+ * Wolfgang Denk Engineering, w...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#if defined(CONFIG_64BIT)
+#define ELF_FMTelf64
+#define PTR_COUNT_SHIFT3
+#else
+#define ELF_FMTelf32
+#define PTR_COUNT_SHIFT2
+#endif
+
+#if defined(CONFIG_SYS_LITTLE_ENDIAN)
+#define ELF_ENDIAN tradlittlemips
+#else
+#define ELF_ENDIAN tradbigmips
+#endif
+
+#define _MIPS_FORMAT2(x) #x
+#define _MIPS_FORMAT(x,y) _MIPS_FORMAT2(x-y)
+
+#define MIPS_FORMAT_MIPS_FORMAT(ELF_FMT,ELF_ENDIAN)
+
+OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
we need to get rid of OUTPUT_FORMAT. This was always misused due to
some endianess and toolchain problems which have been resolved in the meantime.
We should use gcc flags like it is done in linux kernel. The config.mk
of mips64 already
has those flags. Mips32 and xburst need to be extended with:
PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
ifdef CONFIG_SYS_BIG_ENDIAN
PLATFORM_LDFLAGS += -m elf32btsmip
else
PLATFORM_LDFLAGS += -m elf32ltsmip
endif
+OUTPUT_ARCH(mips)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ *(.text*)
+ }
please fix the style globally to
.text : {
*(.text*)
}
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : { *(.data*) }
+
+ . = .;
+ _gp = ALIGN(16) +0x7ff0;
+
+ .got : {
+ __got_start = .;
+ *(.got)
+ __got_end = .;
+ }
+
+ . = ALIGN(4);
+ .sdata : { *(.sdata*) }
*(.sdata*) should be merged with .data
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ #include u-boot.lst
+ }
+
+ uboot_end_data = .;
+
+ num_got_entries = (__got_end - __got_start) PTR_COUNT_SHIFT;
+
+ . = ALIGN(4);
+ .sbss : { *(.sbss*) }
+ .bss : {
+ *(.bss*)
+ . = ALIGN(4);
+ }
. = ALIGN(4);
.bss : {
*(.bss*)
*(.sbss*)
. = ALIGN(4);
}
+ uboot_end = .;
+}
--
1.7.10
--
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
Dear Otavio Salvador,
On Tue, Jan 29, 2013 at 1:14 AM, Marek Vasut ma...@denx.de wrote:
Dear Marek Vasut,
Dear Otavio Salvador,
This enables the 'Fast Auto Pre-Charge' found in the memory chip.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Improve commit message
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87
100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
#elif defined(CONFIG_MX23)
0x01010001, 0x00010100, 0x01000101, 0x0001,
0x0101, 0x, 0x0001, 0x0101,
- 0x, 0x0001, 0x07000200, 0x00070202,
+ 0x0100, 0x0001, 0x07000200, 0x00070202,
0x0202, 0x04040a01, 0x0201, 0x0204,
0x0200, 0x19000f08, 0x0d0d, 0x02021313,
0x02061521, 0x000a, 0x00080008, 0x00200020,
I went through the u-boot mem init and detected you apparently added the
following undocumented portion of code (the writel((1 24 ...)
already:
112 static void initialize_dram_values(void)
113 {
114 int i;
115
116 mxs_adjust_memory_params(dram_vals);
117
118 for (i = 0; i ARRAY_SIZE(dram_vals); i++)
119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
120
121 #ifdef CONFIG_MX23
122 writel((1 24), MXS_DRAM_BASE + (4 * 8));
123 #endif
124 }
[...]
Sorry about me blowing. Anyway, I better put down the message I would
like to relay. Otavio, please follow these steps:
* Work in proper sequence -- patches must apply one after another. The
same way you cannot build house from the roof to the ground, you can not
apply patches in anachronistic order against their dependencies.
* Prove why your patch fixes issues -- apply proper reasoning. Do a
proper research, there's no time-limit for sending a patch. There is no
deadline, take your time.
* Step back and slow down -- please do not roll one patch after another,
wait for more reviews. This does put a great deal of strain on everyone
in the ML, so please be considerate ; you are flooding the mailing list
for no reason ; you are also pushing too much work on the reviewers.
Thus, wait for some reviews, then fix the issues and repost.
* Focus on the changes you make -- look at the stuff above, you need to
properly study the code instead of rolling out random patches. Properly
focus on a single task, finish it, then move on to the other task.
Hacking is not a race, it's an art .
I've been trying to be cooperative and to improve on the way. I (as
other humans) do mistakes but I try to fix them as soon as possible.
I've been trying to get MX23 in basic working state (for users) and do
wish to have it for next release and that's why I am trying to make
things fast; I am sorry by the patch but it is normal to make mistakes
on the way.
I am glad you noticed it but not so glad by the way you communicated it.
Slow down already. We can apply minor things after the MW. If you go at this
pace, it helps noone really. So just take it easy, carefully review the patches
etc.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
Dear Otavio Salvador,
On Tue, Jan 29, 2013 at 12:33 AM, Marek Vasut marek.va...@gmail.com wrote:
Dear Otavio Salvador,
This enables the 'Fast Auto Pre-Charge' found in the memory chip.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Improve commit message
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87
100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
#elif defined(CONFIG_MX23)
0x01010001, 0x00010100, 0x01000101, 0x0001,
0x0101, 0x, 0x0001, 0x0101,
- 0x, 0x0001, 0x07000200, 0x00070202,
+ 0x0100, 0x0001, 0x07000200, 0x00070202,
0x0202, 0x04040a01, 0x0201, 0x0204,
0x0200, 0x19000f08, 0x0d0d, 0x02021313,
0x02061521, 0x000a, 0x00080008, 0x00200020,
I went through the u-boot mem init and detected you apparently added the
following undocumented portion of code (the writel((1 24 ...) already:
112 static void initialize_dram_values(void)
113 {
114 int i;
115
116 mxs_adjust_memory_params(dram_vals);
117
118 for (i = 0; i ARRAY_SIZE(dram_vals); i++)
119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
120
121 #ifdef CONFIG_MX23
122 writel((1 24), MXS_DRAM_BASE + (4 * 8));
123 #endif
124 }
It does enable the TRANS_LOCKOUT. So what the heck is going on here? Are
you coding this stuff at random now ? WHAT THE FUCK IS HAPPENING HERE ?!
What your tone, please.
My tone reflects my frustration here.
Indeed, it does it. It has been done lng time ago when we started
looking at MX23 and it was not obvious for me it.
I will send a patch reverting it and adding a comment explaning it
there so it is documented.
No! Again, you are charging forward without thinking first!
Why was this code written like that in the first place? Why was this bit set
later instead of during the register programming in the first place?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx23: Enable tRAS lockout (24 bit of HW_DRAM_CTL08) as in imx-bootlets
On Tue, Jan 29, 2013 at 10:26 AM, Marek Vasut marek.va...@gmail.com wrote:
Dear Otavio Salvador,
On Tue, Jan 29, 2013 at 12:33 AM, Marek Vasut marek.va...@gmail.com wrote:
Dear Otavio Salvador,
This enables the 'Fast Auto Pre-Charge' found in the memory chip.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Improve commit message
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index 836e636..a9efd87
100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -90,7 +90,7 @@ static uint32_t dram_vals[] = {
#elif defined(CONFIG_MX23)
0x01010001, 0x00010100, 0x01000101, 0x0001,
0x0101, 0x, 0x0001, 0x0101,
- 0x, 0x0001, 0x07000200, 0x00070202,
+ 0x0100, 0x0001, 0x07000200, 0x00070202,
0x0202, 0x04040a01, 0x0201, 0x0204,
0x0200, 0x19000f08, 0x0d0d, 0x02021313,
0x02061521, 0x000a, 0x00080008, 0x00200020,
I went through the u-boot mem init and detected you apparently added the
following undocumented portion of code (the writel((1 24 ...) already:
112 static void initialize_dram_values(void)
113 {
114 int i;
115
116 mxs_adjust_memory_params(dram_vals);
117
118 for (i = 0; i ARRAY_SIZE(dram_vals); i++)
119 writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
120
121 #ifdef CONFIG_MX23
122 writel((1 24), MXS_DRAM_BASE + (4 * 8));
123 #endif
124 }
It does enable the TRANS_LOCKOUT. So what the heck is going on here? Are
you coding this stuff at random now ? WHAT THE FUCK IS HAPPENING HERE ?!
What your tone, please.
My tone reflects my frustration here.
This does not give you the right to be hard at someone, specially when
someone does not make a mistake by propose.
Indeed, it does it. It has been done lng time ago when we started
looking at MX23 and it was not obvious for me it.
I will send a patch reverting it and adding a comment explaning it
there so it is documented.
No! Again, you are charging forward without thinking first!
Why was this code written like that in the first place? Why was this bit set
later instead of during the register programming in the first place?
Check the patchset I sent before to shoot, please.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] sf: stmicro: Add support for N25Q32A
From: Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com
Add support for Numonyx N25Q32A SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 09a3d68..87ed3d3 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -99,6 +99,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.name = N25Q32,
},
{
+ .id = 0xbb16,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = N25Q32A,
+ },
+ {
.id = 0xba17,
.pages_per_sector = 256,
.nr_sectors = 128,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] sf: stmicro: Add support for N25Q256A
From: Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com
Add support for Numonyx N25Q256A SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 87ed3d3..df432a1 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -134,6 +134,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 512,
.name = N25Q256,
},
+ {
+ .id = 0xbb19,
+ .pages_per_sector = 256,
+ .nr_sectors = 512,
+ .name = N25Q256A,
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] sf: stmicro: Add support for N25Q32
From: Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com
Add support for Numonyx N25Q32 SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
drivers/mtd/spi/stmicro.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 32df827..09a3d68 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -93,6 +93,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.name = M25P128,
},
{
+ .id = 0xba16,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = N25Q32,
+ },
+ {
.id = 0xba17,
.pages_per_sector = 256,
.nr_sectors = 128,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to CONFIG_SPL_MXS_PSWITCH_WAIT
Dear Otavio Salvador,
The power switch option is compatible with i.MX23 and i.MX28 so the
configration option needs to reflect it. We choose
'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
Acked-by: Marek Vasut ma...@denx.de
Please read [1] too, I'm completely lost in the flurry of patches. I just can't
figure out anymore what's going on. I don't know what patches to review, in
what
order and what patches are obsolete and what are not.
Moreover, it's generally better to use Cc: in the patches. Also, if you want
my threading to work well so I want be lost, Cc me on the whole series.
http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules
---
Changes in v3: None
Changes in v2:
- Rewrite short description as per Marek's request
arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +-
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h index 2ddc5bc..084def5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
@@ -30,7 +30,7 @@ void early_delay(int delay);
void mxs_power_init(void);
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void);
#else
static inline void mxs_power_wait_pswitch(void) { }
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index e9d6302..287c698
100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -921,7 +921,7 @@ void mxs_power_init(void)
early_delay(1000);
}
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
void mxs_power_wait_pswitch(void)
{
struct mxs_power_regs *power_regs =
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/7] Add splash screen for CM-T35
This patchset adds splash screen support for CM-T35. It includes the ability to initialize the display subsystem either using predefines (selected via env variable displaytype), or user supplied configuration options, also stored in an environment variables and pointed to by displaytype. The splash image data is currently read from NAND. As a preparation for the above functionality this patchset adds: - new DSS #defines - an option for board-specific splash screen preparation, which can be invoked in lcd_logo() right before displaying the splash screen (typical use case: load the image data from non-memory mapped storage in time for it to be displayed). - struct panel_config is extended to support setting the gfx_format dynamically - protection from data aborts due to unaligned bmp headers is added to lcd_logo's splashscreen section (I'm also looking into refining this protection later on). Changes in V2: - GFXFORMAT_RGB16 now passed to omap3_dss_panel_config() in a new field of panel_cfg. Updated existing panel_config structs to set this field to the value that was originally hardcoded into omap3_dss_panel_config(). [Jeroen Hofstee] - Used LCD_BPP for vl_bpix. [Jeroen Hofstee] - Added a comment to explain the choice of GFXFORMAT_RGB16. [Jeroen Hofstee] - Added an address check (and fix) to the address of splashimage in order to avoid alignment problems with bmp header. A similar check appears in board_splash_screen_prepare() for cm_t35. [Albert ARIBAUD] - Do not manually set gfx burst size to GFXBURSTSIZE16, as it is apparently not necessary. GFXBURSTSIZE* #defines were kept in patch 1 anyway in the hope they will be useful for someone. Nikita Kiryanov (7): omap3: add useful dss defines omap3: allow dynamic selection of gfx_format lcd: prevent unaligned memory access when displaying splash screen lcd: add option for board specific splash screen preparation cm-t35: add support for dvi displays cm-t35: add support for user defined lcd parameters cm-t35: add support for loading splash image from NAND README|8 + arch/arm/include/asm/arch-omap3/dss.h | 36 +++ board/cm_t35/Makefile |1 + board/cm_t35/cm_t35.c | 68 ++ board/cm_t35/display.c| 426 + board/htkw/mcx/mcx.c |1 + board/teejet/mt_ventoux/mt_ventoux.c |2 + board/ti/beagle/beagle.h |6 +- common/lcd.c | 23 ++ drivers/video/omap3_dss.c |2 +- include/configs/cm_t35.h | 11 + include/lcd.h |1 + 12 files changed, 582 insertions(+), 3 deletions(-) create mode 100644 board/cm_t35/display.c -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V1 1/7] omap3: add useful dss defines
Add useful omap3 dss defines for: polarity, TFT data lines, lcd
display type, gfx burst size, and gfx format
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/include/asm/arch-omap3/dss.h | 35 +
1 file changed, 35 insertions(+)
diff --git a/arch/arm/include/asm/arch-omap3/dss.h
b/arch/arm/include/asm/arch-omap3/dss.h
index ffaffbb..74321ae 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -167,6 +167,41 @@ struct venc_regs {
#define VENC_OUT_SEL (1 6)
#define DIG_LPP_SHIFT 16
+/* LCD display type */
+#define PASSIVE_DISPLAY0
+#define ACTIVE_DISPLAY 1
+
+/* TFTDATALINES */
+#define LCD_INTERFACE_12_BIT 0
+#define LCD_INTERFACE_16_BIT 1
+#define LCD_INTERFACE_18_BIT 2
+#define LCD_INTERFACE_24_BIT 3
+
+/* Polarity */
+#define DSS_IVS(1 12)
+#define DSS_IHS(1 13)
+#define DSS_IPC(1 14)
+#define DSS_IEO(1 15)
+
+/* GFX format */
+#define GFXFORMAT_BITMAP1 (0x0 1)
+#define GFXFORMAT_BITMAP2 (0x1 1)
+#define GFXFORMAT_BITMAP4 (0x2 1)
+#define GFXFORMAT_BITMAP8 (0x3 1)
+#define GFXFORMAT_RGB12(0x4 1)
+#define GFXFORMAT_ARGB16 (0x5 1)
+#define GFXFORMAT_RGB16(0x6 1)
+#define GFXFORMAT_RGB24_UNPACKED (0x8 1)
+#define GFXFORMAT_RGB24_PACKED (0x9 1)
+#define GFXFORMAT_ARGB32 (0xC 1)
+#define GFXFORMAT_RGBA32 (0xD 1)
+#define GFXFORMAT_RGBx32 (0xE 1)
+
+/* GFX burst size */
+#define GFXBURSTSIZE4 (0 6)
+#define GFXBURSTSIZE8 (1 6)
+#define GFXBURSTSIZE16 (2 6)
+
/* Panel Configuration */
struct panel_config {
u32 timing_h;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/7] omap3: allow dynamic selection of gfx_format
Currently the value of gfx_format is hardcoded into
omap3_dss_panel_config(). Make it a field in struct panel_config, and
update existing structs to set this field to the value that was originally hard
coded.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
NOTE: New patch in the series; no V1.
arch/arm/include/asm/arch-omap3/dss.h |1 +
board/htkw/mcx/mcx.c |1 +
board/teejet/mt_ventoux/mt_ventoux.c |2 ++
board/ti/beagle/beagle.h |6 --
drivers/video/omap3_dss.c |2 +-
5 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/dss.h
b/arch/arm/include/asm/arch-omap3/dss.h
index 74321ae..ad5a73e 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -213,6 +213,7 @@ struct panel_config {
u32 data_lines;
u32 load_mode;
u32 panel_color;
+ u32 gfx_format;
void *frame_buffer;
};
diff --git a/board/htkw/mcx/mcx.c b/board/htkw/mcx/mcx.c
index 9fe6408..5eda6c4 100644
--- a/board/htkw/mcx/mcx.c
+++ b/board/htkw/mcx/mcx.c
@@ -130,6 +130,7 @@ static struct panel_config lcd_cfg = {
.load_mode = 0x02, /* Frame Mode */
.panel_color= 0,
.lcd_size = PANEL_LCD_SIZE(800, 480),
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
};
int board_video_init(void)
diff --git a/board/teejet/mt_ventoux/mt_ventoux.c
b/board/teejet/mt_ventoux/mt_ventoux.c
index c516c75..78d81d6 100644
--- a/board/teejet/mt_ventoux/mt_ventoux.c
+++ b/board/teejet/mt_ventoux/mt_ventoux.c
@@ -81,6 +81,7 @@ static struct panel_config lcd_cfg[] = {
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
.panel_color= 0,
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
},
{
.timing_h = PANEL_TIMING_H(20, 192, 4),
@@ -91,6 +92,7 @@ static struct panel_config lcd_cfg[] = {
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
.panel_color= 0,
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
}
};
#endif
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index c0a94a9..6d71bbc 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -544,7 +544,8 @@ static const struct panel_config dvid_cfg = {
.panel_type = 0x01, /* TFT */
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
- .panel_color= DVI_BEAGLE_ORANGE_COL /* ORANGE */
+ .panel_color= DVI_BEAGLE_ORANGE_COL, /* ORANGE */
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
};
static const struct panel_config dvid_cfg_xm = {
@@ -556,6 +557,7 @@ static const struct panel_config dvid_cfg_xm = {
.panel_type = 0x01, /* TFT */
.data_lines = 0x03, /* 24 Bit RGB */
.load_mode = 0x02, /* Frame Mode */
- .panel_color= DVI_BEAGLE_ORANGE_COL /* ORANGE */
+ .panel_color= DVI_BEAGLE_ORANGE_COL, /* ORANGE */
+ .gfx_format = GFXFORMAT_RGB24_UNPACKED,
};
#endif
diff --git a/drivers/video/omap3_dss.c b/drivers/video/omap3_dss.c
index b1424bf..6efba12 100644
--- a/drivers/video/omap3_dss.c
+++ b/drivers/video/omap3_dss.c
@@ -121,7 +121,7 @@ void omap3_dss_panel_config(const struct panel_config
*panel_cfg)
if (!panel_cfg-frame_buffer)
return;
- writel(8 GFX_FORMAT_SHIFT | GFX_ENABLE, dispc-gfx_attributes);
+ writel(panel_cfg-gfx_format | GFX_ENABLE, dispc-gfx_attributes);
writel(1, dispc-gfx_row_inc);
writel(1, dispc-gfx_pixel_inc);
writel(panel_cfg-lcd_size, dispc-gfx_size);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V1 4/7] lcd: add option for board specific splash screen preparation
Currently there is no logical place to put the code that prepares the
splash image data. The splash image data should be ready in memory
before bmp_display() is called, and after the environment is ready
(since lcd.c looks for the splash image in an address specified by
the environment variable splashimage).
Our window of opportunity in board_init_r() is therefore: between
env_relocate() and bmp_display(), and from the available options
only the lcd related functions in drv_lcd_init() seem appropriate
for such lcd oriented code.
Add the option to prepare the splash image data in lcd_logo() right
before it is sent to be displayed.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
README|8
common/lcd.c | 15 +++
include/lcd.h |1 +
3 files changed, 24 insertions(+)
diff --git a/README b/README
index a336476..89694d7 100644
--- a/README
+++ b/README
@@ -1550,6 +1550,14 @@ CBFS (Coreboot Filesystem) support
= vertically centered image
at x = dspWidth - bmpWidth - 9
+ CONFIG_SPLASH_SCREEN_PREPARE
+
+ If this option is set then the board_splash_screen_prepare()
+ function, which must be defined in your code, is called as part
+ of the splash screen display sequence. It gives the board an
+ opportunity to prepare the splash image data before it is
+ processed and sent to the frame buffer by U-Boot.
+
- Gzip compressed BMP image support: CONFIG_VIDEO_BMP_GZIP
If this option is set, additionally to standard BMP
diff --git a/common/lcd.c b/common/lcd.c
index 104125d..bb8a7d2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1034,6 +1034,18 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
#endif
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+static inline int splash_screen_prepare(void)
+{
+ return board_splash_screen_prepare();
+}
+#else
+static inline int splash_screen_prepare(void)
+{
+ return 0;
+}
+#endif
+
static void *lcd_logo(void)
{
#ifdef CONFIG_SPLASH_SCREEN
@@ -1045,6 +1057,9 @@ static void *lcd_logo(void)
int x = 0, y = 0;
do_splash = 0;
+ if (splash_screen_prepare())
+ return (void *)gd-fb_base;
+
addr = simple_strtoul (s, NULL, 16);
/*
* In order for the fields of bmp header to be properly aligned
diff --git a/include/lcd.h b/include/lcd.h
index c24164a..4ac4ddd 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -47,6 +47,7 @@ extern struct vidinfo panel_info;
extern void lcd_ctrl_init (void *lcdbase);
extern void lcd_enable (void);
+extern int board_splash_screen_prepare(void);
/* setcolreg used in 8bpp/16bpp; initcolregs used in monochrome */
extern void lcd_setcolreg (ushort regno,
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/7] lcd: prevent unaligned memory access when displaying splash screen
When the bmp file is loaded to an address specified by the environment
variable splashimage, its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by
mostly 32 bit fields, so when the address in splashimage is not equal to aligned
address plus/minus 2, the 32 bit members will be placed in unaligned addresses.
This results in a data abort on targets that cannot handle unaligned memory
accesses.
Check that the address is safe to use, and fix it if it's not.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
NOTE: New patch in the series; no V1.
common/lcd.c |8
1 file changed, 8 insertions(+)
diff --git a/common/lcd.c b/common/lcd.c
index 66d4f94..104125d 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1046,6 +1046,14 @@ static void *lcd_logo(void)
do_splash = 0;
addr = simple_strtoul (s, NULL, 16);
+ /*
+* In order for the fields of bmp header to be properly aligned
+* in memory, splash image addr must be aligned to aligned
+* address plus 2. Fix addr if necessary.
+*/
+ if (addr % 4 != 2)
+ addr += (addr % 4) ?: 2;
+
#ifdef CONFIG_SPLASH_SCREEN_ALIGN
s = getenv(splashpos);
if (s != NULL) {
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 7/7] cm-t35: add support for loading splash image from NAND
Add support for loading splash image from NAND
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in V2:
- Added fix to bmp_load_addr to comply with what happens in lcd.c
following patch number 3.
board/cm_t35/cm_t35.c| 65 ++
include/configs/cm_t35.h |4 +++
2 files changed, 69 insertions(+)
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index 8f3d735..9ad5cbe 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -33,7 +33,9 @@
#include net.h
#include i2c.h
#include usb.h
+#include nand.h
#include twl4030.h
+#include bmp_layout.h
#include linux/compiler.h
#include asm/io.h
@@ -75,6 +77,69 @@ static u32 gpmc_nand_config[GPMC_MAX_REG] = {
0,
};
+#ifdef CONFIG_LCD
+#ifdef CONFIG_CMD_NAND
+static int splash_load_from_nand(u32 bmp_load_addr)
+{
+ struct bmp_header *bmp_hdr;
+ int res, splash_screen_nand_offset = 0x10;
+ size_t bmp_size, bmp_header_size = sizeof(struct bmp_header);
+
+ if (bmp_load_addr + bmp_header_size = gd-start_addr_sp)
+ goto splash_address_too_high;
+
+ res = nand_read_skip_bad(nand_info[nand_curr_device],
+ splash_screen_nand_offset, bmp_header_size,
+ (u_char *)bmp_load_addr);
+ if (res 0)
+ return res;
+
+ bmp_hdr = (struct bmp_header *)bmp_load_addr;
+ bmp_size = le32_to_cpu(bmp_hdr-file_size);
+
+ if (bmp_load_addr + bmp_size = gd-start_addr_sp)
+ goto splash_address_too_high;
+
+ return nand_read_skip_bad(nand_info[nand_curr_device],
+ splash_screen_nand_offset, bmp_size,
+ (u_char *)bmp_load_addr);
+
+splash_address_too_high:
+ printf(Error: splashimage address too high. Data overwrites U-Boot
+ and/or placed beyond DRAM boundaries.\n);
+
+ return -1;
+}
+#else
+static inline int splash_load_from_nand(void)
+{
+ return -1;
+}
+#endif /* CONFIG_CMD_NAND */
+
+int board_splash_screen_prepare(void)
+{
+ char *env_splashimage_value;
+ u32 bmp_load_addr;
+
+ env_splashimage_value = getenv(splashimage);
+ if (env_splashimage_value == NULL)
+ return -1;
+
+ bmp_load_addr = simple_strtoul(env_splashimage_value, 0, 16);
+ if (bmp_load_addr == 0) {
+ printf(Error: bad splashimage address specified\n);
+ return -1;
+ }
+
+ /* Fix bmp_load_addr to the alignment that lcd.c expects */
+ if (bmp_load_addr % 4 != 2)
+ bmp_load_addr += (bmp_load_addr % 4) ?: 2;
+
+ return splash_load_from_nand(bmp_load_addr);
+}
+#endif /* CONFIG_LCD */
+
/*
* Routine: board_init
* Description: hardware init.
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 46d35ba..53c4e3c 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -344,5 +344,9 @@
#define LCD_BPPLCD_COLOR16
#define CONFIG_LCD
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+#define CONFIG_SPLASH_SCREEN_PREPARE
#endif /* __CONFIG_H */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 5/7] cm-t35: add support for dvi displays
Add support for dvi displays with user selectable dvi presets.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in V2:
- Used LCD_BPP for vl_bpix [Jeroen Hofstee]
- GFXFORMAT_RGB16 now passed to omap3_dss_panel_config() as part of
panel_cfg predefines. [Jeroen Hofstee]
- Added a comment to explain the choice of GFXFORMAT_RGB16.
[Jeroen Hofstee]
- Do not set gfx burst size to GFXBURSTSIZE16, as it is apparently not
necessary.
board/cm_t35/Makefile|1 +
board/cm_t35/cm_t35.c|3 +
board/cm_t35/display.c | 218 ++
include/configs/cm_t35.h |7 ++
4 files changed, 229 insertions(+)
create mode 100644 board/cm_t35/display.c
diff --git a/board/cm_t35/Makefile b/board/cm_t35/Makefile
index 894fa09..bde56e6 100644
--- a/board/cm_t35/Makefile
+++ b/board/cm_t35/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+COBJS-$(CONFIG_LCD) += display.o
COBJS := cm_t35.o leds.o $(COBJS-y)
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index edbb941..8f3d735 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
/* SB-T35 Ethernet */
MUX_VAL(CP(GPMC_NCS4), (IEN | PTU | EN | M0)); /*GPMC_nCS4*/
+ /* DVI enable */
+ MUX_VAL(CP(GPMC_NCS3), (IDIS | PTU | DIS | M4));/*GPMC_nCS3*/
+
/* CM-T3x Ethernet */
MUX_VAL(CP(GPMC_NCS5), (IDIS | PTU | DIS | M0)); /*GPMC_nCS5*/
MUX_VAL(CP(GPMC_CLK), (IEN | PTD | DIS | M4)); /*GPIO_59*/
diff --git a/board/cm_t35/display.c b/board/cm_t35/display.c
new file mode 100644
index 000..da7784a
--- /dev/null
+++ b/board/cm_t35/display.c
@@ -0,0 +1,218 @@
+/*
+ * (C) Copyright 2012 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Nikita Kiryanov nik...@compulab.co.il
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.
+ */
+#include common.h
+#include asm/gpio.h
+#include asm/io.h
+#include stdio_dev.h
+#include asm/arch/dss.h
+#include lcd.h
+#include asm/arch-omap3/dss.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+enum display_type {
+ NONE,
+ DVI,
+};
+
+/*
+ * The frame buffer is allocated before we have the chance to parse user input.
+ * To make sure enough memory is allocated for all resolutions, we define
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+ .vl_col = 1400,
+ .vl_row = 1050,
+ .vl_bpix = LCD_BPP,
+ .cmap = (ushort *)0x8010,
+};
+
+static struct panel_config panel_cfg;
+static enum display_type lcd_def;
+
+/*
+ * A note on DVI presets;
+ * U-Boot can convert 8 bit BMP data to 16 bit BMP data, and OMAP DSS can
+ * convert 16 bit data into 24 bit data. Thus, GFXFORMAT_RGB16 allows us to
+ * support two BMP types with one setting.
+ */
+static const struct panel_config preset_dvi_640X480 = {
+ .lcd_size = PANEL_LCD_SIZE(640, 480),
+ .timing_h = DSS_HBP(48) | DSS_HFP(16) | DSS_HSW(96),
+ .timing_v = DSS_VBP(33) | DSS_VFP(10) | DSS_VSW(2),
+ .divisor= 12 | (1 16),
+ .data_lines = LCD_INTERFACE_24_BIT,
+ .panel_type = ACTIVE_DISPLAY,
+ .load_mode = 2,
+ .gfx_format = GFXFORMAT_RGB16,
+};
+
+static const struct panel_config preset_dvi_800X600 = {
+ .lcd_size = PANEL_LCD_SIZE(800, 600),
+ .timing_h = DSS_HBP(88) | DSS_HFP(40) | DSS_HSW(128),
+ .timing_v = DSS_VBP(23) | DSS_VFP(1) | DSS_VSW(4),
+ .divisor= 8 | (1 16),
+ .data_lines = LCD_INTERFACE_24_BIT,
+ .panel_type = ACTIVE_DISPLAY,
+ .load_mode = 2,
+ .gfx_format = GFXFORMAT_RGB16,
+};
+
+static const struct panel_config preset_dvi_1024X768 = {
+ .lcd_size = PANEL_LCD_SIZE(1024, 768),
+ .timing_h = DSS_HBP(160) | DSS_HFP(24) | DSS_HSW(136),
+ .timing_v = DSS_VBP(29) | DSS_VFP(3) | DSS_VSW(6),
+ .divisor= 5 | (1 16),
+ .data_lines = LCD_INTERFACE_24_BIT,
+
[U-Boot] [PATCH V2 6/7] cm-t35: add support for user defined lcd parameters
Add support for user defined lcd parameters for cm-t35 splash screen.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Changes in V2:
- Set gfx_format to GFXFORMAT_RGB16 after parsing custom lcd settings.
board/cm_t35/display.c | 214 +++-
1 file changed, 211 insertions(+), 3 deletions(-)
diff --git a/board/cm_t35/display.c b/board/cm_t35/display.c
index da7784a..6d46762 100644
--- a/board/cm_t35/display.c
+++ b/board/cm_t35/display.c
@@ -3,6 +3,8 @@
*
* Authors: Nikita Kiryanov nik...@compulab.co.il
*
+ * Parsing code based on linux/drivers/video/pxafb.c
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -33,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
enum display_type {
NONE,
DVI,
+ DVI_CUSTOM,
};
/*
@@ -150,6 +153,206 @@ static enum display_type set_dvi_preset(const struct
panel_config preset,
}
/*
+ * parse_mode() - parse the mode parameter of custom lcd settings
+ *
+ * @mode: res_xxres_y
+ *
+ * Returns -1 on error, 0 on success.
+ */
+static int parse_mode(const char *mode)
+{
+ unsigned int modelen = strlen(mode);
+ int res_specified = 0;
+ unsigned int xres = 0, yres = 0;
+ int yres_specified = 0;
+ int i;
+
+ for (i = modelen - 1; i = 0; i--) {
+ switch (mode[i]) {
+ case 'x':
+ if (!yres_specified) {
+ yres = simple_strtoul(mode[i + 1], NULL, 0);
+ yres_specified = 1;
+ } else {
+ goto done_parsing;
+ }
+
+ break;
+ case '0' ... '9':
+ break;
+ default:
+ goto done_parsing;
+ }
+ }
+
+ if (i 0 yres_specified) {
+ xres = simple_strtoul(mode, NULL, 0);
+ res_specified = 1;
+ }
+
+done_parsing:
+ if (res_specified) {
+ set_resolution_params(xres, yres);
+ } else {
+ printf(LCD: invalid mode: %s\n, mode);
+ return -1;
+ }
+
+ return 0;
+}
+
+#define PIXEL_CLK_NUMERATOR (26 * 432 / 39)
+/*
+ * parse_pixclock() - Parse the pixclock parameter of custom lcd settings
+ *
+ * @pixclock: the desired pixel clock
+ *
+ * Returns -1 on error, 0 on success.
+ *
+ * Handling the pixel_clock:
+ *
+ * Pixel clock is defined in the OMAP35x TRM as follows:
+ * pixel_clock =
+ * (SYS_CLK * 2 * PRCM.CM_CLKSEL2_PLL[18:8]) /
+ * (DSS.DISPC_DIVISOR[23:16] * DSS.DISPC_DIVISOR[6:0] *
+ * PRCM.CM_CLKSEL_DSS[4:0] * (PRCM.CM_CLKSEL2_PLL[6:0] + 1))
+ *
+ * In practice, this means that in order to set the
+ * divisor for the desired pixel clock one needs to
+ * solve the following equation:
+ *
+ * 26 * 432 / (39 * pixel_clock) = DSS.DISPC_DIVISOR[6:0]
+ *
+ * NOTE: the explicit equation above is reduced. Do not
+ * try to infer anything from these numbers.
+ */
+static int parse_pixclock(char *pixclock)
+{
+ int divisor, pixclock_val;
+ char *pixclk_start = pixclock;
+
+ pixclock_val = simple_strtoul(pixclock, pixclock, 10);
+ divisor = DIV_ROUND_UP(PIXEL_CLK_NUMERATOR, pixclock_val);
+ /* 0 and 1 are illegal values for PCD */
+ if (divisor = 1)
+ divisor = 2;
+
+ panel_cfg.divisor = divisor | (1 16);
+ if (pixclock[0] != '\0') {
+ printf(LCD: invalid value for pixclock:%s\n, pixclk_start);
+ return -1;
+ }
+
+ return 0;
+}
+
+/*
+ * parse_setting() - parse a single setting of custom lcd parameters
+ *
+ * @setting: The custom lcd setting name:value
+ *
+ * Returns -1 on failure, 0 on success.
+ */
+static int parse_setting(char *setting)
+{
+ int num_val;
+ char *setting_start = setting;
+
+ if (!strncmp(setting, mode:, 5)) {
+ return parse_mode(setting + 5);
+ } else if (!strncmp(setting, pixclock:, 9)) {
+ return parse_pixclock(setting + 9);
+ } else if (!strncmp(setting, left:, 5)) {
+ num_val = simple_strtoul(setting + 5, setting, 0);
+ panel_cfg.timing_h |= DSS_HBP(num_val);
+ } else if (!strncmp(setting, right:, 6)) {
+ num_val = simple_strtoul(setting + 6, setting, 0);
+ panel_cfg.timing_h |= DSS_HFP(num_val);
+ } else if (!strncmp(setting, upper:, 6)) {
+ num_val = simple_strtoul(setting + 6, setting, 0);
+ panel_cfg.timing_v |= DSS_VBP(num_val);
+ } else if (!strncmp(setting, lower:, 6)) {
+ num_val = simple_strtoul(setting + 6, setting, 0);
+ panel_cfg.timing_v |= DSS_VFP(num_val);
+ } else if (!strncmp(setting, hsynclen:, 9)) {
+ num_val = simple_strtoul(setting + 9, setting, 0);
+
Re: [U-Boot] [PATCH V2 3/7] lcd: prevent unaligned memory access when displaying splash screen
Dear Nikita Kiryanov, In message 1359463349-11649-4-git-send-email-nik...@compulab.co.il you wrote: When the bmp file is loaded to an address specified by the environment variable splashimage, its header members might be unaligned. This happens because the bmp header starts with two byte-size fields followd by mostly 32 bit fields, so when the address in splashimage is not equal to aligned address plus/minus 2, the 32 bit members will be placed in unaligned addresses. This results in a data abort on targets that cannot handle unaligned memory accesses. I don;t understand your +/- 2 argument. When there are 32 bit fielkds in the header, these have to be 32 bit aligned, right? Check that the address is safe to use, and fix it if it's not. If you perform any such fixes (thus essentially not doing what the user asked for), you should at least print a warning message so the user gets aware of such issues. Also, you should add the video custodian on Cc: for such patches. [Done here]. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are some good people in it, but the orchestra as a whole is equivalent to a gang bent on destruction. - John Cage, composer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 6/7] cm-t35: add support for user defined lcd parameters
Dear Nikita Kiryanov, In message 1359463349-11649-7-git-send-email-nik...@compulab.co.il you wrote: Add support for user defined lcd parameters for cm-t35 splash screen. Why do you implement another custom method to configure the display? This has been done before, and we should reuse existing methods. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Name one thing windows is better than unix in? Making money for Microsoft? -- Randal L. Schwartz in 8cvi5t4c3t@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 7/7] cm-t35: add support for loading splash image from NAND
Dear Nikita Kiryanov, In message 1359463349-11649-8-git-send-email-nik...@compulab.co.il you wrote: Add support for loading splash image from NAND Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- Changes in V2: - Added fix to bmp_load_addr to comply with what happens in lcd.c following patch number 3. board/cm_t35/cm_t35.c| 65 ++ include/configs/cm_t35.h |4 +++ 2 files changed, 69 insertions(+) Why exactly do you need to add code here? Is it not sufficient to add, for example, a nand read command as part of your preboot settings? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, Wolf in the Fold, stardate 3615.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/7] omap3: allow dynamic selection of gfx_format
Dear Nikita Kiryanov, In message 1359463349-11649-3-git-send-email-nik...@compulab.co.il you wrote: Currently the value of gfx_format is hardcoded into omap3_dss_panel_config(). Make it a field in struct panel_config, and update existing structs to set this field to the value that was originally hard coded. It is not exactly clear to me what exactly this is needed for? Are you just adding dead code? if not, then please explain this in the commit message. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The word fit, as I understand it, means appropriate to a purpose, and I would say the body of the Dean is supremely appropriate to the purpose of sitting around all day and eating big heavy meals. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 1/7] omap3: add useful dss defines
Dear Nikita Kiryanov, In message 1359463349-11649-2-git-send-email-nik...@compulab.co.il you wrote: Add useful omap3 dss defines for: polarity, TFT data lines, lcd display type, gfx burst size, and gfx format Just useful (as in generally useful, but mostly dead code here), or actually used somewhere? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Often it is fatal to live too long. - Racine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Current state and existing users of FIT (Flattened Image Tree)?
Just trying to correlate old patches on U-boot mailing list to draw a picture of the current state of FIT (Flattened Image Tree format).. still have the following questions: Can anyone familiar with this topic comment on the following? (1) Other than Chromium OS, who are the most notable examples/users of FIT? (2) There is no kernel build support for FIT (all patches that were sent for building FIT from kernel sources were NAK'ed). How does chromium-OS or other platforms build FIT images today? (3) Are there any open examples on the web or in the sources for any existing open source projects that show a working example of FIT? The only example I could find were few .its files in the U-boot doc/uImage.FIT directory. Thanks! Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 5/7] cm-t35: add support for dvi displays
Dear Nikita Kiryanov,
In message 1359463349-11649-6-git-send-email-nik...@compulab.co.il you wrote:
Add support for dvi displays with user selectable dvi presets.
...
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
/* SB-T35 Ethernet */
MUX_VAL(CP(GPMC_NCS4), (IEN | PTU | EN | M0)); /*GPMC_nCS4*/
+ /* DVI enable */
+ MUX_VAL(CP(GPMC_NCS3), (IDIS | PTU | DIS | M4));/*GPMC_nCS3*/
Is it intentional and correct to always enable DVI, even when this is
not configured by the user?
+/*
+ * The frame buffer is allocated before we have the chance to parse user
input.
This seems broken to me.
Please explain why you think so?
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+ .vl_col = 1400,
+ .vl_row = 1050,
+ .vl_bpix = LCD_BPP,
+ .cmap = (ushort *)0x8010,
Can we please avoid such hard coded magic numbers?
+/*
+ * env_parse_displaytype() - parse display type.
+ *
+ * Parses the environment variable displaytype, which contains the
+ * name of the display type or preset, in which case it applies its
+ * configurations.
So we have yet another custom implementation for setting the display
type? Can we please agree on using common standard methods? thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, Who Mourns for Adonais?,
stardate 3468.1.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 1/7] omap3: add useful dss defines
Hi Wolfgang Denk, On 01/29/2013 03:55 PM, Wolfgang Denk wrote: Dear Nikita Kiryanov, In message 1359463349-11649-2-git-send-email-nik...@compulab.co.il you wrote: Add useful omap3 dss defines for: polarity, TFT data lines, lcd display type, gfx burst size, and gfx format Just useful (as in generally useful, but mostly dead code here), or actually used somewhere? They are used in other patches in this series. The only exception is the #defines for gfx burst size, which were used in V1, but not in this version. I kept the gfx burst size defines in the hope they will be useful to someone, but I can remove them if you think this shouldn't be done. Best regards, Wolfgang Denk -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/7] omap3: allow dynamic selection of gfx_format
Hi Wolfgang Denk, On 01/29/2013 03:52 PM, Wolfgang Denk wrote: Dear Nikita Kiryanov, In message 1359463349-11649-3-git-send-email-nik...@compulab.co.il you wrote: Currently the value of gfx_format is hardcoded into omap3_dss_panel_config(). Make it a field in struct panel_config, and update existing structs to set this field to the value that was originally hard coded. It is not exactly clear to me what exactly this is needed for? Are you just adding dead code? if not, then please explain this in the commit message. Currently if you want to use a gfx format other than what omap3_dss_panel_config() sets, you have to change it manually. It was suggested in the review of V1 that it would be better if this value could simply be passed to omap3_dss_panel_config() so that there wouldn't be a need for adjustments. I'll try to rephrase the commit message to explain the benefits of this. Best regards, Wolfgang Denk -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/7] lcd: prevent unaligned memory access when displaying splash screen
Hi Wolfgang Denk,
On 01/29/2013 03:46 PM, Wolfgang Denk wrote:
Dear Nikita Kiryanov,
In message 1359463349-11649-4-git-send-email-nik...@compulab.co.il you wrote:
When the bmp file is loaded to an address specified by the environment
variable splashimage, its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by
mostly 32 bit fields, so when the address in splashimage is not equal to aligned
address plus/minus 2, the 32 bit members will be placed in unaligned addresses.
This results in a data abort on targets that cannot handle unaligned memory
accesses.
I don;t understand your +/- 2 argument. When there are 32 bit fielkds
in the header, these have to be 32 bit aligned, right?
Right. The problem stems from the structure of the bmp header, which
places the 32 bit fields at an offset of 2 from the load address.
From bmp_layout.h:
typedef struct bmp_header {
/* Header */
char signature[2]; --- This is what's causing the offset
__u32 file_size;
__u32 reserved;
__u32 data_offset;
...
}
This means that in order for these 32 bit fields to be properly aligned
when you load the bmp into memory, it has to be placed with a +/- offset
relative to an aligned address to cancel the shift that
char signature[2] causes.
Check that the address is safe to use, and fix it if it's not.
If you perform any such fixes (thus essentially not doing what the
user asked for), you should at least print a warning message so the
user gets aware of such issues.
Also, you should add the video custodian on Cc: for such patches.
[Done here].
Thanks, I'll do that in the future.
Best regards,
Wolfgang Denk
--
Regards,
Nikita.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 4/7] lcd: add option for board specific splash screen preparation
Hi Wolfgang Denk, On 01/29/2013 03:46 PM, Wolfgang Denk wrote: Dear Nikita Kiryanov, In message 1359463349-11649-5-git-send-email-nik...@compulab.co.il you wrote: Currently there is no logical place to put the code that prepares the splash image data. The splash image data should be ready in memory before bmp_display() is called, and after the environment is ready (since lcd.c looks for the splash image in an address specified by the environment variable splashimage). Our window of opportunity in board_init_r() is therefore: between env_relocate() and bmp_display(), and from the available options only the lcd related functions in drv_lcd_init() seem appropriate for such lcd oriented code. Add the option to prepare the splash image data in lcd_logo() right before it is sent to be displayed. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Signed-off-by: Igor Grinberg grinb...@compulab.co.il You should add the video custodian on Cc: for such patches. [Done here]. Will do... I did Cc Anatolij when running git send-patch though... It's possible that it was dropped by mailman (see this discussion: http://www.mail-archive.com/u-boot@lists.denx.de/msg103585.html) but he should still get the email. Anyway, I'll start using the Cc line in the patches as requested.. Best regards, Wolfgang Denk -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization
Dear All, Any feedback about this patch? This patch changes sdhci_init()'s behavior to NOT enable all interrupt sources by default. Moreover interrupt signaling has been disabled. This patch do not enable interrupts which aren't served in u-boot (they are defined at sdhci.h but NOT used elsewhere): - SDHCI_INT_CARD_INSERT, SDHCI_INT_CARD_REMOVE, SDHCI_BUS_POWER, SDHCI_INT_CARD_REMOVE, SDHCI_INT_CARD_INT Special care shall be put on SDHCI_INT_CARD_INT, which indicates interrupt generated by SD card. According to SD Host Controller Simplified Spec. ver 3.00 when bit 8 (Card Interrupt Status Enable) at Normal Interrupt Status Enable Register (offset 0x34) is set, the card interrupt detection is started. Then eMMC card may cause the SD controller to set this bit and then this interrupt is passed to booted OS and might cause kernel crash. To sum up: - Only enable interrupts, which are served at u-boot - This cleanup as a side effect fixes SDHCI's CARD INTERRUPT problem at Linux kernel (versions 3.6+, sdhci controller) - Keep masked bits at Normal Interrupt Signal Enable Register (0x38h) Signed-off-by: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Lei Wen lei...@marvell.com Cc: Andy Fleming aflem...@freescale.com --- drivers/mmc/sdhci.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 0fd1337..76c14fb 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -412,9 +412,11 @@ int sdhci_init(struct mmc *mmc) status = sdhci_readl(host, SDHCI_PRESENT_STATE); } - /* Eable all state */ - sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_ENABLE); - sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_SIGNAL_ENABLE); + /* Enable only interrupts served by the SD controller */ + sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK + , SDHCI_INT_ENABLE); + /* Mask all sdhci interrupt sources */ + sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE); return 0; } -- Best regards, Lukasz Majewski Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 5/7] cm-t35: add support for dvi displays
Hi Wolfgang Denk,
On 01/29/2013 04:00 PM, Wolfgang Denk wrote:
Dear Nikita Kiryanov,
In message 1359463349-11649-6-git-send-email-nik...@compulab.co.il you wrote:
Add support for dvi displays with user selectable dvi presets.
...
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
/* SB-T35 Ethernet */
MUX_VAL(CP(GPMC_NCS4), (IEN | PTU | EN | M0)); /*GPMC_nCS4*/
+ /* DVI enable */
+ MUX_VAL(CP(GPMC_NCS3), (IDIS | PTU | DIS | M4));/*GPMC_nCS3*/
Is it intentional and correct to always enable DVI, even when this is
not configured by the user?
This simply prepares the mux that makes it possible to enable DVI.
The actual enabling of DVI is indeed conditional on user setup.
+/*
+ * The frame buffer is allocated before we have the chance to parse user input.
This seems broken to me.
Agreed.
Please explain why you think so?
This isn't just my impression. A patch was submitted by Stephen Warren
to address this issue (http://patchwork.ozlabs.org/patch/212378/), but
it isn't in mainline yet.
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+ .vl_col = 1400,
+ .vl_row = 1050,
+ .vl_bpix = LCD_BPP,
+ .cmap = (ushort *)0x8010,
Can we please avoid such hard coded magic numbers?
OK.
+/*
+ * env_parse_displaytype() - parse display type.
+ *
+ * Parses the environment variable displaytype, which contains the
+ * name of the display type or preset, in which case it applies its
+ * configurations.
So we have yet another custom implementation for setting the display
type? Can we please agree on using common standard methods? thanks.
Most of what is custom in this patchset is parsing of environment
variables. For actually setting up the DSS I do use common code
(specifically omap3_dss_panel_config() and related structs/defines).
Best regards,
Wolfgang Denk
--
Regards,
Nikita.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr
Dear Wolfgang, On 29/01/2013 10.48, Wolfgang Denk wrote: Dear Luca Ellero, In message 51078bfd.60...@gmail.com you wrote: in U-Boot version 2012.10 I used to skip relocate_code setting CONFIG_SYS_TEXT_BASE to relocaddr (obtained from bdinfo command). This since some hardware is able to configure SDRAM and load U-Boot directly to SDRAM, so relocation is useless and time consuming. You are wrong. relocation is not useless, even in your case. there are quite a number of configuration options that will put stuff above the U-Boot image, directly at the end of RAM (things like protected RAM, shared frame buffer, shared log buffer, etc.). In these cases, the relocation address may even be dynamic (i. e. depending on settings of environment variables, and thus unknown at compile time). Now I'm using latest git version and this isn't working anymore. Can someone explain me way? And what is the suggested way to skip relocation now. Don't. Got your point ;-) Thanks I'm asking that since I'm digging on ARM SDRAM configuration and found a bug on getting top of SDRAM (where u-boot will be relocated). On ARM architectures top of SDRAM will always be: CONFIG_SYS_SDRAM_BASE + gd-ram_size anyway this can be wrong since SDRAM can be composed by more that one bank in not-contiguous address space. (CONFIG_SYS_SDRAM_BASE + gd-ram_size) can land to not existent SDRAM addresses and can be very dangerous since it can potentially corrupt real SDRAM (in most cases SDRAM is aliased so writing to some not-existent address can write to real address). My proposed patch is something like this: - diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index cfe32cc..7525caf 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -333,7 +333,18 @@ void board_init_f(ulong bootflag) gd-ram_size -= CONFIG_SYS_MEM_TOP_HIDE; #endif +#if defined(PHYS_SDRAM_2) defined(PHYS_SDRAM_2_SIZE) + if ( CONFIG_NR_DRAM_BANKS 1 + (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE) != PHYS_SDRAM_2 ) + addr = PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE; + else + addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size; +#else addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size; +#endif + - I know that some arch use more than 2 banks but implementing all macros checks to PHYS_SDRAM_* leads to some macro hell. So the point here is: if (n banks 2) and they are not contiguous, relocate u-boot at the end of 2nd bank even if there are more than 2 banks. Please suggest me if this is the right way to follow or suggest me some more appropriate way to correct this bug Thanks again Regards Luca Ellero ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel
Dear Marek Vasut, On 01/25/2013 12:16 PM, Marek Vasut wrote: Dear Piotr Wilczek, Dear Marek Vasut, -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Thursday, January 24, 2013 1:33 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski; Tom Rini; Andrzej Pietrasiewicz Subject: Re: [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel Dear Piotr Wilczek, From: Lukasz Majewski l.majew...@samsung.com The storage_common.c source file from v2.6.36 Linux kernel. Is it not possibly to port anything more recent? If not, so be it. The reason was to use the simplest and tested version. Nevermind my dumb comment, I took a peek and figured as much as that we're stuck with .36-ish gadget framework. Now, completely unrelated question, but since you're the expert at these things, I'll just fire it at you -- do you think porting serial gadget would be too hard? Apparently the CONFIG_USB_TTY is a junk and with the new gadget drivers, this won't work, thus we need new usb-serial-gadget driver. Thank you for all your comments. Regarding your question, I'm not sure at the moment how much effort it is required to port that driver. Best regards, Marek Vasut Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vfat: Fix mkcksum argument sizes
Marek Vasut marex at denx.de wrote: In case a function argument is known/fixed size array in C, the argument is still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore calling sizeof on the function argument will result in the size of the pointer, not the size of the array. The VFAT code contains such a bug, this patch fixes it. I had the same problem with VFAT formatted USB stick on U-Boot 2013.01 as the original bug reported by Michail Simek. I have not made any deeper analysis of your patch, but it solved the problem. Thanks! BR / Mats ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
2013.01.29. 11:44 keltezéssel, Daniel Schwierzeck írta:
2013/1/29 Gabor Juhos juh...@openwrt.org:
The patch adds an unified linker script file which
can be used for all currently supported MIPS targets.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Vlad Lungu v...@comsys.ro
Cc: Thomas Sailer sai...@scs.ch
Cc: Stefan Roese s...@denx.de
Cc: Wolfgang Denk w...@denx.de
Cc: Thomas Lange tho...@corelatus.se
Cc: Xiangfu Liu xian...@openmobilefree.net
AFAIK you can remove Vlad Lungu and Thomas Lange from the list of
board maintainers
Ok. I will remove Thomas Sailer as well because his e-mail address bounces.
---
arch/mips/cpu/u-boot.lds | 90
++
1 file changed, 90 insertions(+)
create mode 100644 arch/mips/cpu/u-boot.lds
...
+OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
we need to get rid of OUTPUT_FORMAT. This was always misused due to
some endianess and toolchain problems which have been resolved in the
meantime.
We should use gcc flags like it is done in linux kernel. The config.mk
of mips64 already
has those flags. Mips32 and xburst need to be extended with:
PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
ifdef CONFIG_SYS_BIG_ENDIAN
PLATFORM_LDFLAGS += -m elf32btsmip
else
PLATFORM_LDFLAGS += -m elf32ltsmip
endif
Makes sense. However I would do that in a separate change. Either before or
after the current series.
+OUTPUT_ARCH(mips)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ *(.text*)
+ }
please fix the style globally to
.text : {
*(.text*)
}
Ok, will change it.
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : { *(.data*) }
+
+ . = .;
+ _gp = ALIGN(16) +0x7ff0;
+
+ .got : {
+ __got_start = .;
+ *(.got)
+ __got_end = .;
+ }
+
+ . = ALIGN(4);
+ .sdata : { *(.sdata*) }
*(.sdata*) should be merged with .data
This is separated in all current linker scripts, so the merge should be done in
a separate patch IMHO.
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ #include u-boot.lst
+ }
+
+ uboot_end_data = .;
+
+ num_got_entries = (__got_end - __got_start) PTR_COUNT_SHIFT;
+
+ . = ALIGN(4);
+ .sbss : { *(.sbss*) }
+ .bss : {
+ *(.bss*)
+ . = ALIGN(4);
+ }
. = ALIGN(4);
.bss : {
*(.bss*)
*(.sbss*)
. = ALIGN(4);
}
Same as above.
Thank you for the review!
-Gabor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can I read env from RAM in uboot script?
On Tue, 2013-01-29 at 17:58 +0800, Bo Shen wrote:
You should use at91sam9g20ek_2mmc_nandflash to configure the u-boot
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 2555672..ce475df 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -157,6 +157,10 @@ int board_early_init_f(void)
int board_init(void)
{
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+ /* arch number of AT91SAM9260EK-Board */
+ gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
#ifdef CONFIG_AT91SAM9G20EK
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
@@ -164,6 +168,7 @@ int board_init(void)
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9260EK;
#endif
+#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
diff --git a/boards.cfg b/boards.cfg
index e4b0d44..fa863dc 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -95,6 +95,7 @@ at91sam9g10ek_nandflash arm arm926ejs
at91sam9261ek atmel
at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
+at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek
atmel at91
at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
at91sam9m10g45ek_nandflash arm arm926ejs
at91sam9m10g45ek
atmel at91
at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
at91sam9rlek_dataflash arm arm926ejs at91sam9rlek
atmel at91
at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
at91sam9rlek_nandflash arm arm926ejs at91sam9rlek
atmel at91
at91sam9rlek:AT91SAM9RL,SYS_USE_NANDFLASH
---
That worked! Very nice! But, I had to apply the patches manually.
Email may have messed up the patch sets with new-lines and indentation.
Can this be added to the main stream? I am on to learning 'env import'.
Thank you.
If email messed it up once, I guess it could mess it up again, but I
generated patches using:
diff -Naur before/ after/ diff.patch
--- board/atmel/at91sam9260ek/at91sam9260ek.c.orig2013-01-29
09:09:35.0 -0800
+++ board/atmel/at91sam9260ek/at91sam9260ek.c 2013-01-29 09:10:46.0
-0800
@@ -157,6 +157,10 @@
int board_init(void)
{
+#ifdef CONFIG_AT91SAM9G20EK_2MMC
+ /* arch number of AT91SAM9260EK-Board */
+ gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC;
+#else
#ifdef CONFIG_AT91SAM9G20EK
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9G20EK;
@@ -164,6 +168,7 @@
/* arch number of AT91SAM9260EK-Board */
gd-bd-bi_arch_number = MACH_TYPE_AT91SAM9260EK;
#endif
+#endif
/* adress of boot parameters */
gd-bd-bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
--- boards.cfg.orig 2013-01-29 08:56:47.0 -0800
+++ boards.cfg2013-01-29 08:58:21.0 -0800
@@ -94,6 +94,7 @@
at91sam9g10ek_nandflash arm arm926ejs at91sam9261ek atmel
at91at91sam9261ek:AT91SAM9G10,SYS_USE_NANDFLASH
at91sam9g20ek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS0
at91sam9g20ek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_DATAFLASH_CS1
+at91sam9g20ek_2mmc_nandflash arm arm926ejs at91sam9260ek atmel
at91
at91sam9260ek:AT91SAM9G20,AT91SAM9G20EK_2MMC,SYS_USE_NANDFLASH
at91sam9g20ek_nandflash arm arm926ejs at91sam9260ek atmel
at91at91sam9260ek:AT91SAM9G20,SYS_USE_NANDFLASH
at91sam9m10g45ek_nandflash arm arm926ejs at91sam9m10g45ekatmel
at91at91sam9m10g45ek:AT91SAM9M10G45,SYS_USE_NANDFLASH
at91sam9rlek_dataflash arm arm926ejs at91sam9rlekatmel
at91at91sam9rlek:AT91SAM9RL,SYS_USE_DATAFLASH
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help : Marvell SDIO/MMC driver for Sheevaplug
Hi all, -Original Message- From: u-boot-bounces at lists.denx.de [mailto:u-boot- bounces at lists.denx.de] On Behalf Of DrEagle Sent: 22 September 2012 12:45 To: DrEagle Cc: Lior Amsalem; u-boot at lists.denx.de; uboot at doukki.net Subject: [U-Boot] [PATCH v2 0/5] Marvell SDIO/MMC driver for Sheevaplug This serie of patch add SDIO/MMC support to Sheevaplug board Change from v1: - Fix an issue with most SDHC cards because of timeout delay drEagle (5): Add Marvell SDIO/MMC driver for Kirkwood SoC Add SDIO/MMC support for kirkwood SoC Add SDIO/MMC support for Sheevaplug board Fix env address for Sheevaplug board Fix timeout in Marvell SDIO MMC driver Hi DrEagle I still request you to study mvsdhci.c which is similar framework used for Pantheon family of SoCs, try to use this infrastructure is possible for Kirkwood support. Regards... Prafulla . . . I have started looking at sdhci component but I find only theses small details : ... 9) mv_sdhci.c - This is a component of the SDHCI support, allowing it to run on Marvell Kirkwood chip. It is probable the SDHCI support will have to be modified to allow calling functions from this file based on information passed via platform_data. ... 16) sdhci.c --- Follows the new API and also has a good encapsulation of the whole driver. The conversion here will be simple, though it'd be necessary to modify this driver to also support the Kirkwood series and probably also Tegra series of CPUs. See the respective parts of this section for details. ... Can anybody give me more advice on how to port efficiently a patch for SDIO/MMC for SheevaPlug/Kirkwood SoC while using, as Prafulla asked, the *sdhci* framework. What are the best practices and the technical details which can help me into this ? Regards, drEagle signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help : Marvell SDIO/MMC driver for Sheevaplug
Hi, On Tue, Jan 29, 2013 at 11:35 PM, DrEagle drea...@doukki.net wrote: Hi all, -Original Message- From: u-boot-bounces at lists.denx.de [mailto:u-boot- bounces at lists.denx.de] On Behalf Of DrEagle Sent: 22 September 2012 12:45 To: DrEagle Cc: Lior Amsalem; u-boot at lists.denx.de; uboot at doukki.net Subject: [U-Boot] [PATCH v2 0/5] Marvell SDIO/MMC driver for Sheevaplug This serie of patch add SDIO/MMC support to Sheevaplug board Change from v1: - Fix an issue with most SDHC cards because of timeout delay drEagle (5): Add Marvell SDIO/MMC driver for Kirkwood SoC Add SDIO/MMC support for kirkwood SoC Add SDIO/MMC support for Sheevaplug board Fix env address for Sheevaplug board Fix timeout in Marvell SDIO MMC driver Hi DrEagle I still request you to study mvsdhci.c which is similar framework used for Pantheon family of SoCs, try to use this infrastructure is possible for Kirkwood support. Regards... Prafulla . . . I have started looking at sdhci component but I find only theses small details : ... 9) mv_sdhci.c - This is a component of the SDHCI support, allowing it to run on Marvell Kirkwood chip. It is probable the SDHCI support will have to be modified to allow calling functions from this file based on information passed via platform_data. ... 16) sdhci.c --- Follows the new API and also has a good encapsulation of the whole driver. The conversion here will be simple, though it'd be necessary to modify this driver to also support the Kirkwood series and probably also Tegra series of CPUs. See the respective parts of this section for details. ... Can anybody give me more advice on how to port efficiently a patch for SDIO/MMC for SheevaPlug/Kirkwood SoC while using, as Prafulla asked, the *sdhci* framework. Giving sdhci core support to your driver: I have listed few steps that I followed while doing on my driver. 1. On your driver need to allocate a sdhci_host 2. assign your sd bases address, version, some quirks (quirks are very impotent to change the functionalities of sdhci core)and few more... 3. call add_sdhci(sdhci_host, max_clk, min_clk) 4. any misc based on ur controller. On my experience using with SDHCI is it is functionally an intelligent core have issues with command delay..this may be because it's implemented newly. Starts using sdhci...post any issues..so-that we can tune sdhci more and more. Thanks, Jagan. What are the best practices and the technical details which can help me into this ? Regards, drEagle ___ 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 0/2] Add I2C driver for Tegra114 Dalmore
Update DT tables and enable I2C driver support for the Tegra114 Dalmore board. This uses the standard Tegra I2C driver. 5 controllers are supported, although all may not have devices behind them on every board. Tom Warren (2): Tegra114: fdt: Update DT files with I2C info for T114/Dalmore Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board arch/arm/dts/tegra114.dtsi| 93 + board/nvidia/dts/tegra114-dalmore.dts | 33 include/configs/dalmore.h |9 +++ include/configs/tegra114-common.h |3 + 4 files changed, 138 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/dts/tegra114.dtsi| 93 +
board/nvidia/dts/tegra114-dalmore.dts | 33
2 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index d06cd12..76fc83b 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -2,4 +2,97 @@
/ {
compatible = nvidia,tegra114;
+
+ tegra_car: clock@60006000 {
+ compatible = nvidia,tegra114-car, nvidia,tegra20-car;
+ reg = 0x60006000 0x1000;
+ #clock-cells = 1;
+ };
+
+ apbdma: dma {
+ compatible = nvidia,tegra114-apbdma, nvidia,tegra20-apbdma;
+ reg = 0x6000a000 0x1400;
+ interrupts = 0 104 0x04
+ 0 105 0x04
+ 0 106 0x04
+ 0 107 0x04
+ 0 108 0x04
+ 0 109 0x04
+ 0 110 0x04
+ 0 111 0x04
+ 0 112 0x04
+ 0 113 0x04
+ 0 114 0x04
+ 0 115 0x04
+ 0 116 0x04
+ 0 117 0x04
+ 0 118 0x04
+ 0 119 0x04
+ 0 128 0x04
+ 0 129 0x04
+ 0 130 0x04
+ 0 131 0x04
+ 0 132 0x04
+ 0 133 0x04
+ 0 134 0x04
+ 0 135 0x04
+ 0 136 0x04
+ 0 137 0x04
+ 0 138 0x04
+ 0 139 0x04
+ 0 140 0x04
+ 0 141 0x04
+ 0 142 0x04
+ 0 143 0x04;
+ };
+
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
+ reg = 0x7000c000 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_I2C1 */
+ clocks = tegra_car 12;
+ };
+
+ i2c@7000c400 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
+ reg = 0x7000c400 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_I2C2 */
+ clocks = tegra_car 54;
+ };
+
+ i2c@7000c500 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
+ reg = 0x7000c500 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_I2C3 */
+ clocks = tegra_car 67;
+ };
+
+ i2c@7000c700 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
+ reg = 0x7000c700 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_I2C4 */
+ clocks = tegra_car 103;
+ };
+
+ i2c@7000d000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
+ reg = 0x7000d000 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_I2C5 */
+ clocks = tegra_car 47;
+ };
};
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
index 7315577..13b07f3 100644
--- a/board/nvidia/dts/tegra114-dalmore.dts
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -6,8 +6,41 @@
model = NVIDIA Dalmore;
compatible = nvidia,dalmore, nvidia,tegra114;
+ aliases {
+ i2c0 = /i2c@7000d000;
+ i2c1 = /i2c@7000c000;
+ i2c2 = /i2c@7000c400;
+ i2c3 = /i2c@7000c500;
+ i2c4 = /i2c@7000c700;
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x8000;
};
+
+ i2c@7000c000 {
+ status = okay;
+ clock-frequency = 10;
+ };
+
+ i2c@7000c400 {
+ status = okay;
+ clock-frequency = 10;
+ };
+
+ i2c@7000c500 {
+ status = okay;
+ clock-frequency = 10;
+ };
+
+ i2c@7000c700 {
+
[U-Boot] [PATCH 2/2] Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board
Tested all 5 'buses', i2c probe enumerates device addresses on bus 1 and 2. Note that this uses the tegra_i2c.c driver w/o modification. Signed-off-by: Tom Warren twar...@nvidia.com --- include/configs/dalmore.h |9 + include/configs/tegra114-common.h |3 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/configs/dalmore.h b/include/configs/dalmore.h index ce32c80..b1a6e34 100644 --- a/include/configs/dalmore.h +++ b/include/configs/dalmore.h @@ -41,6 +41,15 @@ #define CONFIG_MACH_TYPE MACH_TYPE_DALMORE #define CONFIG_BOARD_EARLY_INIT_F + +/* I2C */ +#define CONFIG_TEGRA_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_MAX_I2C_BUS TEGRA_I2C_NUM_CONTROLLERS +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C + #define CONFIG_ENV_IS_NOWHERE #define MACH_TYPE_DALMORE 4304/* not yet in mach-types.h */ diff --git a/include/configs/tegra114-common.h b/include/configs/tegra114-common.h index 0033530..c2986d8 100644 --- a/include/configs/tegra114-common.h +++ b/include/configs/tegra114-common.h @@ -76,4 +76,7 @@ #define CONFIG_SPL_LDSCRIPT$(CPUDIR)/tegra114/u-boot-spl.lds +/* Total I2C ports on Tegra114 */ +#define TEGRA_I2C_NUM_CONTROLLERS 5 + #endif /* _TEGRA114_COMMON_H_ */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x: NAND: add BCH16 and 4k page size support
On 01/28/2013 07:35:40 AM, Jordy van Wolferen wrote:
This is tested with a custom AM3359 (rev 2.0) board.
NAND chip: MT29F16G08ABABAWP
This code allows me to boot from ROM code.
The ROM code forces BCH16 on NAND chips with a 4k page size.
BCH16 is not enabled by default.
---
Missing Signed-off-by (please read the Sign your work section of
Documentation/SubmittingPatches in Linux and be sure that you meet the
conditions of the Developer's Certificate of Origin before adding your
sign off).
Could you explain the patch in a bit more detail? You say it is not
enabled by default -- what would be required to enable it?
arch/arm/include/asm/arch-am33xx/cpu.h | 8 +-
arch/arm/include/asm/arch-am33xx/omap_gpmc.h | 43
drivers/mtd/nand/omap_gpmc.c | 150
+--
include/linux/mtd/mtd-abi.h | 2 +-
4 files changed, 148 insertions(+), 55 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 16e8a80..0a1f1ff 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -78,6 +78,10 @@ struct bch_res_0_3 {
u32 bch_result_x[4];
};
+struct bch_res_4_6 {
+ u32 bch_result_x[3];
+};
+
struct gpmc {
u8 res1[0x10];
u32 sysconfig; /* 0x10 */
@@ -107,7 +111,9 @@ struct gpmc {
u8 res7[12];/* 0x224 */
u32 testmomde_ctrl; /* 0x230 */
u8 res8[12];/* 0x234 */
- struct bch_res_0_3 bch_result_0_3[2]; /* 0x240 */
+ struct bch_res_0_3 bch_result_0_3; /* 0x240 */
+ u32 dummy[44]; /* not used */
+ struct bch_res_4_6 bch_result_4_6; /* 300 */
};
/* Used for board specific gpmc initialization */
diff --git a/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
b/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
index 572f9d0..534fa6e 100644
--- a/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
+++ b/arch/arm/include/asm/arch-am33xx/omap_gpmc.h
@@ -117,4 +117,47 @@
{.offset = 106,\
.length = 8 } } \
}
+
+#define GPMC_NAND_4K_HW_BCH8_ECC_LAYOUT {\
+ .eccbytes = 112,\
+ .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
+16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
26, 27,\
+28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39,\
+40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51,\
+52, 53, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63,\
+64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75,\
+76, 77, 78, 79, 80, 81, 82, 83, 84, 85,
86, 87,\
+88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99,\
+100, 101, 102, 103, 104, 105, 106, 107,
108, 109,\
+ 110, 111, 112, 113},\
+ .oobfree = {\
+ {.offset = 114,\
+.length = 110 } } \
+}
+
+#define GPMC_NAND_4K_HW_BCH16_ECC_LAYOUT {\
+ .eccbytes = 208,\
+ .eccpos = { 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
+16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
26, 27,\
+28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39,\
+40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51,\
+52, 53, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63,\
+64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75,\
+76, 77, 78, 79, 80, 81, 82, 83, 84, 85,
86, 87,\
+88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99,\
+100, 101, 102, 103, 104, 105, 106, 107,
108, 109,\
+110, 111, 112, 113, 114, 115, 116, 117,
118, 119,\
+120, 121, 122, 123, 124, 125, 126, 127,
128, 129,\
+130, 131, 132, 133, 134, 135, 136, 137,
138, 139,\
+140, 141, 142, 143, 144, 145, 146, 147,
148, 149,\
+150, 151, 152, 153, 154, 155, 156, 157,
158, 159,\
+160, 161, 162, 163, 164, 165, 166, 167,
168, 169,\
+170, 171, 172, 173, 174, 175, 176, 177,
178, 179,\
+180, 181, 182, 183, 184, 185, 186, 187,
188, 189,\
+190, 191, 192, 193, 194, 195, 196, 197,
198, 199,\
+200, 201, 202, 203, 204, 205, 206, 207,
208, 209},\
You have too many tabs here -- be sure your editor is set for
8-character tabs.
+ .oobfree = {\
+ {.offset = 210,\
+.length = 14 } } \
+}
#endif /* __ASM_ARCH_OMAP_GPMC_H */
diff --git a/drivers/mtd/nand/omap_gpmc.c
b/drivers/mtd/nand/omap_gpmc.c
index cee394e..3c42a54 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -76,8 +76,8 @@ int omap_spl_dev_ready(struct mtd_info *mtd)
/*
* omap_hwecc_init - Initialize the Hardware ECC for NAND flash in
- * GPMC controller
- * @mtd:MTD device structure
+ * GPMC controller
+ * @mtd: MTD device structure
*
*/
static void __maybe_unused omap_hwecc_init(struct nand_chip *chip)
No unrelated whitespace changes, please.
@@ -258,7 +258,7 @@ struct nand_bch_priv {
#define ECC_BCH8_NIBBLES 26
#define
Re: [U-Boot] [PATCH] am335x: NAND: add BCH16 and 4k page size support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2013 02:54 PM, Scott Wood wrote:
On 01/28/2013 07:35:40 AM, Jordy van Wolferen wrote:
This is tested with a custom AM3359 (rev 2.0) board. NAND chip:
MT29F16G08ABABAWP
This code allows me to boot from ROM code. The ROM code forces
BCH16 on NAND chips with a 4k page size.
BCH16 is not enabled by default.
---
Missing Signed-off-by (please read the Sign your work section of
Documentation/SubmittingPatches in Linux and be sure that you meet
the conditions of the Developer's Certificate of Origin before
adding your sign off).
Note that this also appears to be versus a TI SDK tree and not mainline
(but migrating the code shouldn't be overly difficult now that NAND
support is mainline).
Could you explain the patch in a bit more detail? You say it is
not enabled by default -- what would be required to enable it?
It needs to be auto-detected and switched to, just like how the ROM
does (which is to say when the ROM picks up BCH16 and wants it, we do
too).
[snip]
diff --git a/include/linux/mtd/mtd-abi.h
b/include/linux/mtd/mtd-abi.h index 8bdd231..6979a2a 100644 ---
a/include/linux/mtd/mtd-abi.h +++ b/include/linux/mtd/mtd-abi.h
@@ -125,7 +125,7 @@ struct nand_oobfree { */ struct
nand_ecclayout { uint32_t eccbytes; -uint32_t eccpos[128]; +
uint32_t eccpos[208]; uint32_t oobavail; struct nand_oobfree
oobfree[MTD_MAX_OOBFREE_ENTRIES]; };
Changes to generic code should ideally be separate patches.
True. And I wonder if the mtd re-sync covers this or not.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRCCquAAoJENk4IS6UOR1WcP4P+wUmTIMJlxEVP0JQseXL3fG1
gS0+KRYzFgceBkunfbgXcCGAqP2z3gcmyNEn0s/8dVkrN1F9MirUNz2VApqQwn0b
lj8E/30e042EzM3sM/HyPO0S4yWBVf8GjYiRJMDb80gKOJelthrKNAjermIxqax6
dIHlSvV9pk6DYHTAmcgC7H3QLyHkwyZfSwii+ZRKm5hRPgpiQA2kI7klV8rEH8m7
x5d5c1Ry59hIrefmWWpJvrXhy9u8ipCzk37CCafyl3KbZJoOhZSHiXx73TebI1gP
Sg1ONCvi8MkOZrMmC+iXqbKtrPYUGYApd7TonIoJg2yTlkIBevbTY4OLS/p81Btq
HoJZ7PziCbeu4jZCVlS4Pz7OiIf5GyBbW1oJP/Uhz4tJAuSLJTrxHaiz7sUIZt3p
zNr1ZrL7d5h6hlv3XBuERxRvAn2E4K+sSUJsS+C+8zi/rYMWfWxm5ncB4ygGqCNn
QYvJSwWXK/yyFpq0NSbXZnHvBInwGcdrcQVJy3RftATxEW7B2EJKbLx8yJxcpoaU
nDyN/NDYEeqZx3Vwf8q2YAv7S72vFP6Lwfy+bAbOeyc3emH6sYTE9iDt2EzTYuMM
3nDjgWZiNGDzJ7WzUv6ptDUIV9UQXxdwa7Ay4qc7aKbSx4t/LhjtIDXJYVh9Bbxq
3cYj8flqqYG9yQQn5xk/
=fOZt
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/corenet: Add workaround for ELBC multi-bit ECC error
On 01/28/2013 01:16:53 AM, Shaohui Xie wrote: diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c b/arch/powerpc/cpu/mpc85xx/cmd_errata.c index e5ecf5d..f26d608 100644 --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c @@ -227,6 +227,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #ifdef CONFIG_SYS_FSL_ERRATUM_NMG_LBC103 puts(Work-around for Erratum NMG_LBC103 enabled\n); #endif +#ifdef CONFIG_SYS_FSL_ELBC_MULTIBIT_ECC + puts(Work-around for Erratum ELBC MULTIBIT ECC enabled\n); +#endif Is there still no erratum number for this? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/dts/tegra114.dtsi| 93
+
board/nvidia/dts/tegra114-dalmore.dts | 33
2 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index d06cd12..76fc83b 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -2,4 +2,97 @@
/ {
compatible = nvidia,tegra114;
+
+ tegra_car: clock@60006000 {
+ compatible = nvidia,tegra114-car, nvidia,tegra20-car;
I don't believe the Tegra114 CAR is backwards-compatible enough with
Tegra20 to include the Tegra20 entry in compatible. In other words, just:
compatible = nvidia,tegra114-car;
+ reg = 0x60006000 0x1000;
+ #clock-cells = 1;
+ };
+ apbdma: dma {
+ compatible = nvidia,tegra114-apbdma, nvidia,tegra20-apbdma;
Same here; it isn't fully backwards-compatible according to Laxman's
kernel patches.
I don't think you need the APB DMA node for I2C though; perhaps just
drop it.
If you do keep this node, it needs the clocks property filled in.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
The I2C nodes also aren't backwards-compatible.
+ reg = 0x7000c000 0x100;
The interrupts property is missing here.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
Board changes would usually be a separate patch to an SoC change, but I
guess not a big deal.
All 5 I2C ports are used on the board and only support 100KHz? That
seems unusual, but I suppose it's possible.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board
On 01/29/2013 12:19 PM, Tom Warren wrote: Tested all 5 'buses', i2c probe enumerates device addresses on bus 1 and 2. Why don't the other 3 buses work? Note that this uses the tegra_i2c.c driver w/o modification. The kernel patches imply some mandatory differences in clock divider programming; see: https://patchwork.kernel.org/patch/1936371/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Davinci: Make MAC address offset in EEPROM configurable, CONFIG_MAC_EEPROM_ADDR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/29/2013 02:28 AM, Kim Bndergaard wrote:
--- arch/arm/cpu/arm926ejs/davinci/misc.c | 5 - 1 file changed,
4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/misc.c
b/arch/arm/cpu/arm926ejs/davinci/misc.c index c310c69..d0389a4
100644 --- a/arch/arm/cpu/arm926ejs/davinci/misc.c +++
b/arch/arm/cpu/arm926ejs/davinci/misc.c @@ -55,11 +55,14 @@ void
dram_init_banksize(void) * Read ethernet MAC address from EEPROM
for DVEVM compatible boards. * Returns 1 if found, 0 otherwise. */
+#ifndef CONFIG_MAC_EEPROM_ADDR +#define CONFIG_MAC_EEPROM_ADDR
0x7F00 +#endif int dvevm_read_mac_address(uint8_t *buf) { #ifdef
CONFIG_SYS_I2C_EEPROM_ADDR /* Read MAC address. */ - if
(i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0x7F00, + if
(i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, CONFIG_MAC_EEPROM_ADDR,
CONFIG_SYS_I2C_EEPROM_ADDR_LEN, (uint8_t *) buf[0], 6)) goto
i2cerr;
Lets use CONFIG_SYS_I2C_EEPROM_MAC_OFFSET and just set it in all of
the davinci configs (yes, that's touching more files). Thanks!
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRCDGxAAoJENk4IS6UOR1WAXUP/1W8kLQrWCuIunb6SB2m1ef3
7I3i9hFpENqyX1agmQtXbqaxqUC3claLWrbzzIr/3Ddrwq9ZEmjRjgl0ZWnhYsUx
sryioGP+xMd6GXzVsCO59He1Qnb9x7n5NqActNdeC2gQvVV7H0ED/7tuYO97kXRV
hfUkuw6zZl/TSK4Sz7aNBkk0xCGkvcMVZbghjW+KdgmEJRp3QJOg8USUbypN9Osp
VDVDXPB/BZkALyX30/w1qTxMDXebq3yhkEAs6LypEVeq/2KOMRs6zrCLQfO2yL2t
sEaVFWPJMH8BJL+/Us8Ol4mV3PWkE1JaI7IDpPDYpZmmAdzA8kMb6xymTCa35+r8
KKCNYnHi/uVLzL6KilBAJGqRT6HSlsxwjO3WP4XHDaWlfL3IIITJg/es3NUIvDzF
GAgR3ORY/myZ4wWhlY5BKxVONvq08ZTG5wVvuxmSpBVpmXQrpXqGRR1Tjcg/rjP5
+bFsguseMxJnYuCmWz/DS/93/NRpIGLPd4lt+nGxgnWsWYA2iY7F8UCFhPB/gAse
NTkIMEf0L1eRJM88Ktl4KLsElHBPGAsa1nEkrDfrfUOlqTzHKnTp/c1jX+AUArLW
U0kOyTfS69quoJQmPbSC9f5QlnzSWKw7nUE36xryFgdMGXaxzXYyDbHj1b7jtI3Y
rA5AhaQw/jpeBBxcmfgB
=WlpG
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Stephen,
On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/dts/tegra114.dtsi| 93
+
board/nvidia/dts/tegra114-dalmore.dts | 33
2 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index d06cd12..76fc83b 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -2,4 +2,97 @@
/ {
compatible = nvidia,tegra114;
+
+ tegra_car: clock@60006000 {
+ compatible = nvidia,tegra114-car, nvidia,tegra20-car;
I don't believe the Tegra114 CAR is backwards-compatible enough with
Tegra20 to include the Tegra20 entry in compatible. In other words, just:
compatible = nvidia,tegra114-car;
Will do.
+ reg = 0x60006000 0x1000;
+ #clock-cells = 1;
+ };
+ apbdma: dma {
+ compatible = nvidia,tegra114-apbdma, nvidia,tegra20-apbdma;
Same here; it isn't fully backwards-compatible according to Laxman's
kernel patches.
OK.
I don't think you need the APB DMA node for I2C though; perhaps just
drop it.
It exists in T20 and T30 (via Allen's apdma patch), so I brought it
forward. I can drop it if you feel strongly enough about it. Whoever
needs it (SPI?) will have to add it later.
If you do keep this node, it needs the clocks property filled in.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
The I2C nodes also aren't backwards-compatible.
They were on T30 (same compatible string there, except of course
s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
(compat_names table).
+ reg = 0x7000c000 0x100;
The interrupts property is missing here.
I didn't have an interrupts property for I2C on the T30 dts files,
either. What is it used for in U-Boot? If it's really needed, can I
just crib it from the kernel dts file(s)?
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
Board changes would usually be a separate patch to an SoC change, but I
guess not a big deal.
Actually, this is the way I've always done DT files (in a separate
patch), and then the config files in a separate patch the enable the
feature.
All 5 I2C ports are used on the board and only support 100KHz? That
seems unusual, but I suppose it's possible.
That's the way I have it on T30, and looking at
arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
100KHz.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] MIPS: add unified u-boot.lds file
On Tue, Jan 29, 2013 at 11:13 AM, Gabor Juhos juh...@openwrt.org wrote:
2013.01.29. 11:44 keltezéssel, Daniel Schwierzeck írta:
2013/1/29 Gabor Juhos juh...@openwrt.org:
The patch adds an unified linker script file which
can be used for all currently supported MIPS targets.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
Cc: Vlad Lungu v...@comsys.ro
Cc: Thomas Sailer sai...@scs.ch
Cc: Stefan Roese s...@denx.de
Cc: Wolfgang Denk w...@denx.de
Cc: Thomas Lange tho...@corelatus.se
Cc: Xiangfu Liu xian...@openmobilefree.net
AFAIK you can remove Vlad Lungu and Thomas Lange from the list of
board maintainers
Ok. I will remove Thomas Sailer as well because his e-mail address bounces.
---
arch/mips/cpu/u-boot.lds | 90
++
1 file changed, 90 insertions(+)
create mode 100644 arch/mips/cpu/u-boot.lds
...
+OUTPUT_FORMAT(MIPS_FORMAT, MIPS_FORMAT, MIPS_FORMAT)
we need to get rid of OUTPUT_FORMAT. This was always misused due to
some endianess and toolchain problems which have been resolved in the
meantime.
We should use gcc flags like it is done in linux kernel. The config.mk
of mips64 already
has those flags. Mips32 and xburst need to be extended with:
PLATFORM_CPPFLAGS += -mabi=32 -DCONFIG_32BIT
ifdef CONFIG_SYS_BIG_ENDIAN
PLATFORM_LDFLAGS += -m elf32btsmip
else
PLATFORM_LDFLAGS += -m elf32ltsmip
endif
Makes sense. However I would do that in a separate change. Either before or
after the current series.
+OUTPUT_ARCH(mips)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ *(.text*)
+ }
please fix the style globally to
.text : {
*(.text*)
}
Ok, will change it.
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : { *(.data*) }
+
+ . = .;
+ _gp = ALIGN(16) +0x7ff0;
+
+ .got : {
+ __got_start = .;
+ *(.got)
+ __got_end = .;
+ }
+
+ . = ALIGN(4);
+ .sdata : { *(.sdata*) }
*(.sdata*) should be merged with .data
This is separated in all current linker scripts, so the merge should be
done in
a separate patch IMHO.
IIRC, If you put .sdata in with .data, you also have to adjust the _gp
initialization so the .sdata section is within the signed 16 bit address
offset allowed.
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ #include u-boot.lst
+ }
+
+ uboot_end_data = .;
+
+ num_got_entries = (__got_end - __got_start) PTR_COUNT_SHIFT;
+
+ . = ALIGN(4);
+ .sbss : { *(.sbss*) }
+ .bss : {
+ *(.bss*)
+ . = ALIGN(4);
+ }
. = ALIGN(4);
.bss : {
*(.bss*)
*(.sbss*)
. = ALIGN(4);
}
Same as above.
Thank you for the review!
-Gabor
___
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 2/2] Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board
Stephen, On Tue, Jan 29, 2013 at 1:11 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 01/29/2013 12:19 PM, Tom Warren wrote: Tested all 5 'buses', i2c probe enumerates device addresses on bus 1 and 2. Why don't the other 3 buses work? No idea, but I assume because my Dalmore doesn't have sub-boards w/I2C devices connected (gyro, accel, camera, etc.) Note that this uses the tegra_i2c.c driver w/o modification. The kernel patches imply some mandatory differences in clock divider programming; see: https://patchwork.kernel.org/patch/1936371/ I'll take a look. Thanks. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 01:40 PM, Tom Warren wrote:
Stephen,
On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
If you do keep this node, it needs the clocks property filled in.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
The I2C nodes also aren't backwards-compatible.
They were on T30 (same compatible string there, except of course
s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
(compat_names table).
Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
the Tegra20 driver would run unmodified on Tegra30 without issue. I
don't believe that's the case for Tegra114 though. The solution would be
to add the Tegra114 compatible value to the I2C driver so that it can
search for both.
+ reg = 0x7000c000 0x100;
The interrupts property is missing here.
I didn't have an interrupts property for I2C on the T30 dts files,
either.
That sounds like a bug in the DT.
What is it used for in U-Boot?
U-Boot doesn't use interrupts at least on Tegra, so it's not used.
However, it'd be best to keep the U-Boot DT in line with the kernel DT
so we can easily spot differences. There has been talk of trying to use
the same DT for both too, although we're a long long way off from that.
If it's really needed, can I
just crib it from the kernel dts file(s)?
Yes, but the Tegra114 patches aren't all checked in yet. See the
following proposed patch for what you need:
https://lkml.org/lkml/2013/1/29/235
(note that patch is missing the clocks properties since the clock
binding isn't finalized and checked in yet)
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
Board changes would usually be a separate patch to an SoC change, but I
guess not a big deal.
Actually, this is the way I've always done DT files (in a separate
patch), and then the config files in a separate patch the enable the
feature.
I meant that tegra114.dtsi and tegra114-dalmore.dts would usually be
separate patches.
All 5 I2C ports are used on the board and only support 100KHz? That
seems unusual, but I suppose it's possible.
That's the way I have it on T30, and looking at
arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
100KHz.
But this is board-specific; it depends on which of the I2C controllers
are actually pinmux'd out onto the board (- which to enable), and which
devices are attached to those buses (- max I2C clock rate). I don't see
how Tegra30 nor tegra30.dtsi are relevant here.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Stephen,
On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/29/2013 01:40 PM, Tom Warren wrote:
Stephen,
On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
If you do keep this node, it needs the clocks property filled in.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
The I2C nodes also aren't backwards-compatible.
They were on T30 (same compatible string there, except of course
s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
(compat_names table).
Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
the Tegra20 driver would run unmodified on Tegra30 without issue. I
don't believe that's the case for Tegra114 though. The solution would be
to add the Tegra114 compatible value to the I2C driver so that it can
search for both.
Looking at the TRMs for both T30 and T114, I2C looks nearly identical,
except for some additional registers tacked onto the end for bus clear
support. 99% of the bits appear exactly the same, too (with the
addition of a bus clear int bit on T114 in an used bit position). I
know next to nothing about I2C, but it appears to me that the current
tegra_I2C.c driver should work fine on T114 (and does, since I can
probe addresses with it). I don't see a need for a different driver
or compat value here.
+ reg = 0x7000c000 0x100;
The interrupts property is missing here.
I didn't have an interrupts property for I2C on the T30 dts files,
either.
That sounds like a bug in the DT.
What is it used for in U-Boot?
U-Boot doesn't use interrupts at least on Tegra, so it's not used.
However, it'd be best to keep the U-Boot DT in line with the kernel DT
so we can easily spot differences. There has been talk of trying to use
the same DT for both too, although we're a long long way off from that.
I'll add it, but it seems silly to add unused values, especially when
your past review critiques of DT files have asked for minimum
functionality, which I agree with.
If it's really needed, can I
just crib it from the kernel dts file(s)?
Yes, but the Tegra114 patches aren't all checked in yet. See the
following proposed patch for what you need:
https://lkml.org/lkml/2013/1/29/235
The only diff between Laxman's dtsi file in the proposed patch and
mine is the interrupts property. I added it (it's exactly the same as
the T30 values, BTW, so I'll add interrupts to the T30 dtsi file in a
separate patch).
(note that patch is missing the clocks properties since the clock
binding isn't finalized and checked in yet)
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
Board changes would usually be a separate patch to an SoC change, but I
guess not a big deal.
Actually, this is the way I've always done DT files (in a separate
patch), and then the config files in a separate patch the enable the
feature.
I meant that tegra114.dtsi and tegra114-dalmore.dts would usually be
separate patches.
All 5 I2C ports are used on the board and only support 100KHz? That
seems unusual, but I suppose it's possible.
That's the way I have it on T30, and looking at
arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
100KHz.
But this is board-specific; it depends on which of the I2C controllers
are actually pinmux'd out onto the board (- which to enable), and which
devices are attached to those buses (- max I2C clock rate). I don't see
how Tegra30 nor tegra30.dtsi are relevant here.
I see your point, but I don't know exactly how to find out the proper
clock disable settings for E1611 Dalmore. I'll talk to Yen peruse
the docs.
Thanks,
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 02:57 PM, Tom Warren wrote:
Stephen,
On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/29/2013 01:40 PM, Tom Warren wrote:
Stephen,
On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 01/29/2013 12:19 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
If you do keep this node, it needs the clocks property filled in.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
The I2C nodes also aren't backwards-compatible.
They were on T30 (same compatible string there, except of course
s/114/30/). And the tegra20-i2c is needed for fdtdec.c to find it
(compat_names table).
Yes, I believe the HW changes between Tegra20 and Tegra30 were such that
the Tegra20 driver would run unmodified on Tegra30 without issue. I
don't believe that's the case for Tegra114 though. The solution would be
to add the Tegra114 compatible value to the I2C driver so that it can
search for both.
Looking at the TRMs for both T30 and T114, I2C looks nearly identical,
except for some additional registers tacked onto the end for bus clear
support. 99% of the bits appear exactly the same, too (with the
addition of a bus clear int bit on T114 in an used bit position). I
know next to nothing about I2C, but it appears to me that the current
tegra_I2C.c driver should work fine on T114 (and does, since I can
probe addresses with it). I don't see a need for a different driver
or compat value here.
I Cc'd in Laxman here, since he wrote the Tegra114 I2C support for the
kernel. He made the decision that Tegra114 I2C wasn't compatible with
Tegra20/30 I2C, and can explain that. Certainly looking at the kernel
patch I pointed at, it seems some of the clock divisors must be
programmed differently, which certainly seems enough to declare the HW
blocks incompatible, even if everything else is identical.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
That's the way I have it on T30, and looking at
arch/arm/boot/dts/tegra30.dtsi in the kernel, all 5 ports are set to
100KHz.
But this is board-specific; it depends on which of the I2C controllers
are actually pinmux'd out onto the board (- which to enable), and which
devices are attached to those buses (- max I2C clock rate). I don't see
how Tegra30 nor tegra30.dtsi are relevant here.
I see your point, but I don't know exactly how to find out the proper
clock disable settings for E1611 Dalmore. I'll talk to Yen peruse
the docs.
The board schematics should show which I2C buses are hooked up.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,GIT,PULL] u-boot-mpc83xx: support for new SPL
On Wed, Jan 16, 2013 at 02:41:08PM -, Kim Phillips wrote:
Hi Tom,
Please pull:
The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d:
Prepare v2013.01 (2013-01-15 14:47:42 -0700)
are available in the git repository at:
git://git.denx.de/u-boot-mpc83xx.git master
for you to fetch changes up to a6187dccd813920524987792e49ef2feffb213e6:
Merge remote-tracking branch 'mpc83xx/next' (2013-01-16 18:34:09 -0600)
Kim Phillips (1):
Merge remote-tracking branch 'mpc83xx/next'
Scott Wood (3):
spl: Change PAD_TO to CONFIG_SPL_PAD_TO
powerpc/mpc83xx: add support for new SPL
powerpc/mpc83xx: convert MPC8313ERDB to new-SPL
Makefile | 6 +-
README | 10 ++
arch/powerpc/cpu/mpc83xx/Makefile | 16 +++
.../cpu/mpc83xx/{nand_init.c = spl_minimal.c} | 0
arch/powerpc/cpu/mpc83xx/start.S | 31 +++---
.../powerpc/cpu/mpc83xx/u-boot-spl.lds | 0
arch/powerpc/lib/Makefile | 3 +-
board/ait/cam_enc_4xx/config.mk| 2 +-
board/freescale/mpc8313erdb/mpc8313erdb.c | 10 +-
boards.cfg | 4 +-
include/configs/MPC8313ERDB.h | 43 +---
nand_spl/board/freescale/mpc8313erdb/Makefile | 108
-
nand_spl/board/freescale/mpc8315erdb/Makefile | 6 +-
nand_spl/board/sheldon/simpc8313/Makefile | 6 +-
14 files changed, 96 insertions(+), 149 deletions(-)
rename arch/powerpc/cpu/mpc83xx/{nand_init.c = spl_minimal.c} (100%)
rename nand_spl/board/freescale/mpc8313erdb/u-boot.lds =
arch/powerpc/cpu/mpc83xx/u-boot-spl.lds (100%)
delete mode 100644 nand_spl/board/freescale/mpc8313erdb/Makefile
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] [PULL] : Please pull u-boot-i2c
On Tue, Jan 29, 2013 at 08:41:26AM +0100, Heiko Schocher wrote: Hello Tom, please pull from u-boot-i2c: The following changes since commit 54b08efcf2f4ff532ce99c53f341a59c193331a5: README.mips: update known issues and TODOs (2013-01-16 10:52:08 +0100) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to 019be4af642cf59df0fa97082e5d9e290d26f997: Remove unused CONFIG_SYS_I2C_BUS[_SELECT] (2013-01-29 06:40:01 +0100) Marek Vasut (1): i2c: mxs: Staticize the functions in the driver Michael Jones (1): Remove unused CONFIG_SYS_I2C_BUS[_SELECT] drivers/i2c/mxs_i2c.c | 8 include/configs/am3517_crane.h | 2 -- include/configs/am3517_evm.h | 2 -- include/configs/cm_t35.h | 2 -- include/configs/devkit8000.h | 2 -- include/configs/dig297.h | 2 -- include/configs/igep00x0.h | 2 -- include/configs/mcx.h | 1 - include/configs/omap3_beagle.h | 2 -- include/configs/omap3_evm_common.h | 2 -- include/configs/omap3_logic.h | 2 -- include/configs/omap3_mvblx.h | 2 -- include/configs/omap3_pandora.h| 2 -- include/configs/omap3_sdp3430.h| 2 -- include/configs/omap3_zoom1.h | 2 -- include/configs/omap3_zoom2.h | 2 -- include/configs/omap4_common.h | 2 -- include/configs/tam3517-common.h | 2 -- include/configs/tricorder.h| 2 -- 19 Dateien ge?ndert, 4 Zeilen hinzugef?gt(+), 39 Zeilen entfernt(-) 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] MX23 patches
Hello, due to the recent influx of patches, I completely lost track of what is going on, what patches need review and what patches are already obsolete. Therefore, I'd like to ask you, Otavio, to proceed as follows: - I will discard all patches for mx23 currently in my mailbox - I'd like you to reset the versioning on all your patches and start with clean slate (from V1, as of this moment) - Repost all series you currently have, incl. those you already submitted with proper description in all patches and with a proper cover letter (git NNN -- cover-letter) - Wait at least one full day (24 hours) between re-sending a series, unless explicitly requested otherwise. - Always CC me, Fabio and Stefano on _all_ the patches in the series, not only selected ones. (you can add Cc: Us Er u...@s.er in the patch description, this will let git send-email automatically handle the Cc) - Read [1], esp. the part about In-Reply-To please , apply this only when re- posting series. Do NOT do In-Reply-To for the re-post of the series after this restart, only if V2 is needed from now on. That is all. [1] http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MX23 patches
Am 29/01/2013 23:21, schrieb Marek Vasut: Hello, Hi Marek, hi Otavio, - Wait at least one full day (24 hours) between re-sending a series, unless explicitly requested otherwise. I am on business trip and I have this week very few possibilities to access to my e-mail. Today I saw 80 messages related to mx23 patches, and I have no chances to read them, until I will be back next week. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MX23 patches
On Tue, Jan 29, 2013 at 8:21 PM, Marek Vasut ma...@denx.de wrote: Hello, due to the recent influx of patches, I completely lost track of what is going on, what patches need review and what patches are already obsolete. Therefore, I'd like to ask you, Otavio, to proceed as follows: - I will discard all patches for mx23 currently in my mailbox - I'd like you to reset the versioning on all your patches and start with clean slate (from V1, as of this moment) - Repost all series you currently have, incl. those you already submitted with proper description in all patches and with a proper cover letter (git NNN -- cover-letter) I rolled out, early this morning, the last series (3 series): http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152364 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152361 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152358 So if you really need me to resend them all, I can do it but those are the current versions and previous ones can be ignored. - Wait at least one full day (24 hours) between re-sending a series, unless explicitly requested otherwise. Ok; deal. - Always CC me, Fabio and Stefano on _all_ the patches in the series, not only selected ones. (you can add Cc: Us Er u...@s.er in the patch description, this will let git send-email automatically handle the Cc) I've been trying to follow maintainers role here but I can change it and copy you three in all messages. No problem for me. - Read [1], esp. the part about In-Reply-To please , apply this only when re- posting series. Do NOT do In-Reply-To for the re-post of the series after this restart, only if V2 is needed from now on. One doubt here: when sending v2 I should put the In-Reply-To for v1? I read it but it was not clear for me. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MX23 patches
Dear Otavio Salvador, On Tue, Jan 29, 2013 at 8:21 PM, Marek Vasut ma...@denx.de wrote: Hello, due to the recent influx of patches, I completely lost track of what is going on, what patches need review and what patches are already obsolete. Therefore, I'd like to ask you, Otavio, to proceed as follows: - I will discard all patches for mx23 currently in my mailbox - I'd like you to reset the versioning on all your patches and start with clean slate (from V1, as of this moment) - Repost all series you currently have, incl. those you already submitted with proper description in all patches and with a proper cover letter (git NNN -- cover-letter) I rolled out, early this morning, the last series (3 series): http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152364 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152361 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/152358 So if you really need me to resend them all, I can do it but those are the current versions and previous ones can be ignored. I wiped all the patches from patchwork now, resubmit everything that is not yet applied. - Wait at least one full day (24 hours) between re-sending a series, unless explicitly requested otherwise. Ok; deal. - Always CC me, Fabio and Stefano on _all_ the patches in the series, not only selected ones. (you can add Cc: Us Er u...@s.er in the patch description, this will let git send-email automatically handle the Cc) I've been trying to follow maintainers role here but I can change it and copy you three in all messages. No problem for me. Just add us on the Cc since we are all directly involved. Obviously, also Cc the custodians. - Read [1], esp. the part about In-Reply-To please , apply this only when re- posting series. Do NOT do In-Reply-To for the re-post of the series after this restart, only if V2 is needed from now on. One doubt here: when sending v2 I should put the In-Reply-To for v1? I read it but it was not clear for me. Hang the V2 series under the V1 series cover letter. Or resubmit separate patches I-R-T. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/7] tegra20: fdt: add SPI SFLASH node
Add node for tegra20 SPI SFLASH controller to fdt.
Signed-off-by: Allen Martin amar...@nvidia.com
---
arch/arm/dts/tegra20.dtsi| 12
board/compulab/dts/tegra20-trimslice.dts |5 +
2 files changed, 17 insertions(+)
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 12049fd..9a89685 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -236,6 +236,18 @@
clocks = tegra_car 12, tegra_car 124;
};
+ spi@7000c380 {
+ compatible = nvidia,tegra20-sflash;
+ reg = 0x7000c380 0x80;
+ interrupts = 0 39 0x04;
+ nvidia,dma-request-selector = apbdma 11;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SPI1, PLLP_OUT0 */
+ clocks = tegra_car 43;
+ };
+
i2c@7000c400 {
#address-cells = 1;
#size-cells = 0;
diff --git a/board/compulab/dts/tegra20-trimslice.dts
b/board/compulab/dts/tegra20-trimslice.dts
index c8a4dd4..7aeed67 100644
--- a/board/compulab/dts/tegra20-trimslice.dts
+++ b/board/compulab/dts/tegra20-trimslice.dts
@@ -23,6 +23,11 @@
status = disabled;
};
+ spi@7000c380 {
+ status = okay;
+ spi-max-frequency = 2500;
+ };
+
i2c@7000c400 {
status = disabled;
};
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/7] tegra30: add SBC1 to periph id mapping table
SBC1 is SPI controller 1 on tegra30
Signed-off-by: Allen Martin amar...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/tegra30-common/clock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/tegra30-common/clock.c
b/arch/arm/cpu/tegra30-common/clock.c
index ee3c8b1..a93f2c9 100644
--- a/arch/arm/cpu/tegra30-common/clock.c
+++ b/arch/arm/cpu/tegra30-common/clock.c
@@ -290,7 +290,7 @@ static s8 periph_id_to_internal_id[PERIPH_ID_COUNT] = {
/* 40 */
NONE(KFUSE),
- NONE(SBC1), /* SBC1, 0x34, is this SPI1? */
+ PERIPHC_SBC1,
PERIPHC_NOR,
NONE(RESERVED43),
PERIPHC_SBC2,
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/7] tegra: spi: add fdt support to tegra SPI SFLASH driver
Add support for configuring tegra SPI driver from devicetree.
Support is keyed off CONFIG_OF_CONTROL. Add entry in seaboard dts
file for spi controller to describe seaboard spi.
Signed-off-by: Allen Martin amar...@nvidia.com
---
drivers/spi/tegra_spi.c | 45 +++--
include/fdtdec.h|1 +
lib/fdtdec.c|1 +
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/tegra_spi.c b/drivers/spi/tegra_spi.c
index 9bb34e2..ce19095 100644
--- a/drivers/spi/tegra_spi.c
+++ b/drivers/spi/tegra_spi.c
@@ -32,6 +32,9 @@
#include asm/arch-tegra/clk_rst.h
#include asm/arch-tegra/tegra_spi.h
#include spi.h
+#include fdtdec.h
+
+DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SPI_CORRUPTS_UART)
#define corrupt_delay() udelay(CONFIG_SPI_CORRUPTS_UART_DLY);
@@ -44,6 +47,7 @@ struct tegra_spi_slave {
struct spi_tegra *regs;
unsigned int freq;
unsigned int mode;
+ int periph_id;
};
static inline struct tegra_spi_slave *to_tegra_spi(struct spi_slave *slave)
@@ -84,8 +88,45 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned
int cs,
}
spi-slave.bus = bus;
spi-slave.cs = cs;
- spi-freq = max_hz;
+#ifdef CONFIG_OF_CONTROL
+ int node = fdtdec_next_compatible(gd-fdt_blob, 0,
+ COMPAT_NVIDIA_TEGRA20_SFLASH);
+ if (node 0) {
+ debug(%s: cannot locate sflash node\n, __func__);
+ return NULL;
+ }
+ if (!fdtdec_get_is_enabled(gd-fdt_blob, node)) {
+ debug(%s: sflash is disabled\n, __func__);
+ return NULL;
+ }
+ spi-regs = (struct spi_tegra *)fdtdec_get_addr(gd-fdt_blob,
+ node, reg);
+ if ((fdt_addr_t)spi-regs == FDT_ADDR_T_NONE) {
+ debug(%s: no sflash register found\n, __func__);
+ return NULL;
+ }
+ spi-freq = fdtdec_get_int(gd-fdt_blob, node, spi-max-frequency, 0);
+ if (!spi-freq) {
+ debug(%s: no sflash max frequency found\n, __func__);
+ return NULL;
+ }
+ spi-periph_id = clock_decode_periph_id(gd-fdt_blob, node);
+ if (spi-periph_id == PERIPH_ID_NONE) {
+ debug(%s: could not decode periph id\n, __func__);
+ return NULL;
+ }
+#else
spi-regs = (struct spi_tegra *)NV_PA_SPI_BASE;
+ spi-freq = TEGRA_SPI_MAX_FREQ;
+ spi-periph_id = PERIPH_ID_SPI1;
+#endif
+ if (max_hz spi-freq) {
+ debug(%s: limiting frequency from %u to %u\n, __func__,
+ spi-freq, max_hz);
+ spi-freq = max_hz;
+ }
+ debug(%s: controller initialized at %p, freq = %u, periph_id = %d\n,
+ __func__, spi-regs, spi-freq, spi-periph_id);
spi-mode = mode;
return spi-slave;
@@ -110,7 +151,7 @@ int spi_claim_bus(struct spi_slave *slave)
u32 reg;
/* Change SPI clock to correct frequency, PLLP_OUT0 source */
- clock_start_periph_pll(PERIPH_ID_SPI1, CLOCK_ID_PERIPH, spi-freq);
+ clock_start_periph_pll(spi-periph_id, CLOCK_ID_PERIPH, spi-freq);
/* Clear stale status here */
reg = SPI_STAT_RDY | SPI_STAT_RXF_FLUSH | SPI_STAT_TXF_FLUSH | \
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..5b67a77 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -70,6 +70,7 @@ enum fdt_compat_id {
COMPAT_NVIDIA_TEGRA20_NAND, /* Tegra2 NAND controller */
COMPAT_NVIDIA_TEGRA20_PWM, /* Tegra 2 PWM controller */
COMPAT_NVIDIA_TEGRA20_DC, /* Tegra 2 Display controller */
+ COMPAT_NVIDIA_TEGRA20_SFLASH, /* Tegra 2 SPI flash controller */
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16921e1..385e0e5 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -45,6 +45,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(NVIDIA_TEGRA20_NAND, nvidia,tegra20-nand),
COMPAT(NVIDIA_TEGRA20_PWM, nvidia,tegra20-pwm),
COMPAT(NVIDIA_TEGRA20_DC, nvidia,tegra20-dc),
+ COMPAT(NVIDIA_TEGRA20_SFLASH, nvidia,tegra20-sflash),
COMPAT(SMSC_LAN9215, smsc,lan9215),
COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/7] tegra: add addresses of SPI SLINK controllers
Add I/O addresses of SPI SLINK controllers 1-6 Signed-off-by: Allen Martin amar...@nvidia.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/include/asm/arch-tegra/tegra.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/include/asm/arch-tegra/tegra.h b/arch/arm/include/asm/arch-tegra/tegra.h index f97cfd0..bf7229d 100644 --- a/arch/arm/include/asm/arch-tegra/tegra.h +++ b/arch/arm/include/asm/arch-tegra/tegra.h @@ -40,6 +40,12 @@ #define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400) #define NV_PA_NAND_BASE(NV_PA_APB_MISC_BASE + 0x8000) #define NV_PA_SPI_BASE (NV_PA_APB_MISC_BASE + 0xC380) +#define NV_PA_SLINK1_BASE (NV_PA_APB_MISC_BASE + 0xD400) +#define NV_PA_SLINK2_BASE (NV_PA_APB_MISC_BASE + 0xD600) +#define NV_PA_SLINK3_BASE (NV_PA_APB_MISC_BASE + 0xD800) +#define NV_PA_SLINK4_BASE (NV_PA_APB_MISC_BASE + 0xDA00) +#define NV_PA_SLINK5_BASE (NV_PA_APB_MISC_BASE + 0xDC00) +#define NV_PA_SLINK6_BASE (NV_PA_APB_MISC_BASE + 0xDE00) #define TEGRA_DVC_BASE (NV_PA_APB_MISC_BASE + 0xD000) #define NV_PA_PMC_BASE (NV_PA_APB_MISC_BASE + 0xE400) #define NV_PA_EMC_BASE (NV_PA_APB_MISC_BASE + 0xF400) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/7] tegra: cardhu: config: enable SPI
Turn on SPI in cardhu config file Signed-off-by: Allen Martin amar...@nvidia.com Acked-by: Simon Glass s...@chromium.org --- include/configs/cardhu.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/configs/cardhu.h b/include/configs/cardhu.h index aa725ba..1616b39 100644 --- a/include/configs/cardhu.h +++ b/include/configs/cardhu.h @@ -49,6 +49,17 @@ #define CONFIG_ENV_IS_NOWHERE +/* SPI */ +#define CONFIG_TEGRA_SLINK +#define CONFIG_TEGRA_SLINK_CTRLS 6 +#define CONFIG_SPI_FLASH +#define CONFIG_SPI_FLASH_WINBOND +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 +#define CONFIG_SF_DEFAULT_SPEED2400 +#define CONFIG_CMD_SPI +#define CONFIG_CMD_SF +#define CONFIG_SPI_FLASH_SIZE (4 20) + #include tegra-common-post.h #endif /* __CONFIG_H */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/7] tegra: SPI drivers
This series updates the tegra20 SPI driver to add fdt support and adds a new tegra30 SPI driver. Testing was done on trimslice (tegra20) and cardhu (tegra30). Changes in v4: -Added support for fdt aliases to slink driver -Check status field of fdt node to make sure node is enabled Changes in v3: -Dropped some fdt patches from the series that were picked up in u-boot-tegra/next already -Removed SPI node from seaboard, added to trimslice -Incorporated feedback from Simon Glass and Stephen Warren to slink driver Changes in v2: -Added new patch to sort dts files prior to adding new nodes -Moved max-spi-frequency out to board dts files -Moved tegra20 SFLASH fdt changes out to separate patch -Added valid flag to slink driver controller structure Allen Martin (7): tegra20: fdt: add SPI SFLASH node tegra: spi: add fdt support to tegra SPI SFLASH driver tegra30: add SBC1 to periph id mapping table tegra30: fdt: add SPI SLINK nodes tegra: add addresses of SPI SLINK controllers tegra: add SPI SLINK driver tegra: cardhu: config: enable SPI arch/arm/cpu/tegra30-common/clock.c |2 +- arch/arm/dts/tegra20.dtsi | 12 + arch/arm/dts/tegra30.dtsi | 72 ++ arch/arm/include/asm/arch-tegra/tegra.h |6 + arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 ++ board/compulab/dts/tegra20-trimslice.dts |5 + board/nvidia/common/board.c |3 +- board/nvidia/dts/tegra30-cardhu.dts |5 + drivers/spi/Makefile |1 + drivers/spi/tegra_slink.c | 343 + drivers/spi/tegra_spi.c | 45 +++- include/configs/cardhu.h | 11 + include/fdtdec.h |2 + lib/fdtdec.c |2 + 14 files changed, 589 insertions(+), 4 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra/tegra_slink.h create mode 100644 drivers/spi/tegra_slink.c -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/7] tegra: add SPI SLINK driver
Add driver for tegra SPI SLINK style driver. This controller is
similar to the tegra20 SPI SFLASH controller. The difference is
that the SLINK controller is a genernal purpose SPI controller and the
SFLASH controller is special purpose and can only talk to FLASH
devices. In addition there are potentially many instances of an SLINK
controller on tegra and only a single instance of SFLASH. Tegra20 is
currently ths only version of tegra that instantiates an SFLASH
controller.
This driver supports basic PIO mode of operation and is configurable
(CONFIG_OF_CONTROL) to be driven off devicetree bindings. Up to 4
devices per controller may be attached, although typically only a
single chip select line is exposed from tegra per controller so in
reality this is usually limited to 1.
To enable this driver, use CONFIG_TEGRA_SLINK
Signed-off-by: Allen Martin amar...@nvidia.com
---
arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 ++
board/nvidia/common/board.c |3 +-
drivers/spi/Makefile |1 +
drivers/spi/tegra_slink.c | 343 +
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
6 files changed, 432 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-tegra/tegra_slink.h
create mode 100644 drivers/spi/tegra_slink.c
diff --git a/arch/arm/include/asm/arch-tegra/tegra_slink.h
b/arch/arm/include/asm/arch-tegra/tegra_slink.h
new file mode 100644
index 000..74804b5
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/tegra_slink.h
@@ -0,0 +1,84 @@
+/*
+ * NVIDIA Tegra SPI-SLINK controller
+ *
+ * Copyright 2010-2013 NVIDIA Corporation
+ *
+ * This software may be used and distributed according to the
+ * terms of the GNU Public License, Version 2, incorporated
+ * herein by reference.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _TEGRA_SLINK_H_
+#define _TEGRA_SLINK_H_
+
+#include asm/types.h
+
+struct slink_tegra {
+ u32 command;/* SLINK_COMMAND_0 register */
+ u32 command2; /* SLINK_COMMAND2_0 reg */
+ u32 status; /* SLINK_STATUS_0 register */
+ u32 reserved; /* Reserved offset 0C */
+ u32 mas_data; /* SLINK_MAS_DATA_0 reg */
+ u32 slav_data; /* SLINK_SLAVE_DATA_0 reg */
+ u32 dma_ctl;/* SLINK_DMA_CTL_0 register */
+ u32 status2;/* SLINK_STATUS2_0 reg */
+ u32 rsvd[56]; /* 0x20 to 0xFF reserved */
+ u32 tx_fifo;/* SLINK_TX_FIFO_0 reg off 100h */
+ u32 rsvd2[31]; /* 0x104 to 0x17F reserved */
+ u32 rx_fifo;/* SLINK_RX_FIFO_0 reg off 180h */
+};
+
+/* COMMAND */
+#define SLINK_CMD_ENB (1 31)
+#define SLINK_CMD_GO (1 30)
+#define SLINK_CMD_M_S (1 28)
+#define SLINK_CMD_CK_SDA (1 21)
+#define SLINK_CMD_CS_POL (1 13)
+#define SLINK_CMD_CS_VAL (1 12)
+#define SLINK_CMD_CS_SOFT (1 11)
+#define SLINK_CMD_BIT_LENGTH (1 4)
+#define SLINK_CMD_BIT_LENGTH_MASK 0x001F
+/* COMMAND2 */
+#define SLINK_CMD2_TXEN(1 30)
+#define SLINK_CMD2_RXEN(1 31)
+#define SLINK_CMD2_SS_EN (1 18)
+#define SLINK_CMD2_SS_EN_SHIFT 18
+#define SLINK_CMD2_SS_EN_MASK 0x000C
+#define SLINK_CMD2_CS_ACTIVE_BETWEEN (1 17)
+/* STATUS */
+#define SLINK_STAT_BSY (1 31)
+#define SLINK_STAT_RDY (1 30)
+#define SLINK_STAT_ERR (1 29)
+#define SLINK_STAT_RXF_FLUSH (1 27)
+#define SLINK_STAT_TXF_FLUSH (1 26)
+#define SLINK_STAT_RXF_OVF (1 25)
+#define SLINK_STAT_TXF_UNR (1 24)
+#define SLINK_STAT_RXF_EMPTY (1 23)
+#define SLINK_STAT_RXF_FULL(1 22)
+#define SLINK_STAT_TXF_EMPTY (1 21)
+#define SLINK_STAT_TXF_FULL(1 20)
+#define SLINK_STAT_TXF_OVF (1 19)
+#define SLINK_STAT_RXF_UNR (1 18)
+#define SLINK_STAT_CUR_BLKCNT (1 15)
+/* STATUS2 */
+#define SLINK_STAT2_RXF_FULL_CNT (1 16)
+#define SLINK_STAT2_TXF_FULL_CNT (1 0)
+
+#define SPI_TIMEOUT1000
+#define TEGRA_SPI_MAX_FREQ 5200
+
+#endif /* _TEGRA_SLINK_H_ */
diff
[U-Boot] [PATCH v4 4/7] tegra30: fdt: add SPI SLINK nodes
Add tegra30 SPI SLINK nodes to fdt.
Signed-off-by: Allen Martin amar...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/dts/tegra30.dtsi | 72 +++
board/nvidia/dts/tegra30-cardhu.dts |5 +++
2 files changed, 77 insertions(+)
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index aa7e7ae..7b8126f 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -90,4 +90,76 @@
/* PERIPH_ID_I2C_DVC, CLK_M */
clocks = tegra_car 47;
};
+
+ spi@7000d400 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000d400 0x200;
+ interrupts = 0 59 0x04;
+ nvidia,dma-request-selector = apbdma 15;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC1, PLLP_OUT0 */
+ clocks = tegra_car 41;
+ };
+
+ spi@7000d600 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000d600 0x200;
+ interrupts = 0 82 0x04;
+ nvidia,dma-request-selector = apbdma 16;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC2, PLLP_OUT0 */
+ clocks = tegra_car 44;
+ };
+
+ spi@7000d800 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000d480 0x200;
+ interrupts = 0 83 0x04;
+ nvidia,dma-request-selector = apbdma 17;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC3, PLLP_OUT0 */
+ clocks = tegra_car 46;
+ };
+
+ spi@7000da00 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000da00 0x200;
+ interrupts = 0 93 0x04;
+ nvidia,dma-request-selector = apbdma 18;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC4, PLLP_OUT0 */
+ clocks = tegra_car 68;
+ };
+
+ spi@7000dc00 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000dc00 0x200;
+ interrupts = 0 94 0x04;
+ nvidia,dma-request-selector = apbdma 27;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC5, PLLP_OUT0 */
+ clocks = tegra_car 104;
+ };
+
+ spi@7000de00 {
+ compatible = nvidia,tegra30-slink, nvidia,tegra20-slink;
+ reg = 0x7000de00 0x200;
+ interrupts = 0 79 0x04;
+ nvidia,dma-request-selector = apbdma 28;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ /* PERIPH_ID_SBC6, PLLP_OUT0 */
+ clocks = tegra_car 105;
+ };
};
diff --git a/board/nvidia/dts/tegra30-cardhu.dts
b/board/nvidia/dts/tegra30-cardhu.dts
index 3223ed4..f9f80c5 100644
--- a/board/nvidia/dts/tegra30-cardhu.dts
+++ b/board/nvidia/dts/tegra30-cardhu.dts
@@ -39,4 +39,9 @@
i2c@7000d000 {
clock-frequency = 10;
};
+
+ spi@7000da00 {
+ status = okay;
+ spi-max-frequency = 2500;
+ };
};
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] common: cmd_bdinfo: Fix compilation warning for microblaze
Dear Michal Simek Michal Simek michal.simek at xilinx.com writes: Fix one printf compilation warning in microblaze bdinfo part. Warning log: cmd_bdinfo.c: In function 'do_bdinfo': cmd_bdinfo.c:219:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat] Signed-off-by: Michal Simek michal.simek at xilinx.com --- common/cmd_bdinfo.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I build tested these series of Xilinx patches on an ml507. This doesn't apply cleanly to HEAD. All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] tegra: SPI drivers
On Tue, Jan 29, 2013 at 03:51:22PM -0800, Allen Martin wrote: This series updates the tegra20 SPI driver to add fdt support and adds a new tegra30 SPI driver. Testing was done on trimslice (tegra20) and cardhu (tegra30). Tom, this series applies cleanly on top of your T114 series. Changes in v4: -Added support for fdt aliases to slink driver -Check status field of fdt node to make sure node is enabled Changes in v3: -Dropped some fdt patches from the series that were picked up in u-boot-tegra/next already -Removed SPI node from seaboard, added to trimslice -Incorporated feedback from Simon Glass and Stephen Warren to slink driver Changes in v2: -Added new patch to sort dts files prior to adding new nodes -Moved max-spi-frequency out to board dts files -Moved tegra20 SFLASH fdt changes out to separate patch -Added valid flag to slink driver controller structure Allen Martin (7): tegra20: fdt: add SPI SFLASH node tegra: spi: add fdt support to tegra SPI SFLASH driver tegra30: add SBC1 to periph id mapping table tegra30: fdt: add SPI SLINK nodes tegra: add addresses of SPI SLINK controllers tegra: add SPI SLINK driver tegra: cardhu: config: enable SPI arch/arm/cpu/tegra30-common/clock.c |2 +- arch/arm/dts/tegra20.dtsi | 12 + arch/arm/dts/tegra30.dtsi | 72 ++ arch/arm/include/asm/arch-tegra/tegra.h |6 + arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 ++ board/compulab/dts/tegra20-trimslice.dts |5 + board/nvidia/common/board.c |3 +- board/nvidia/dts/tegra30-cardhu.dts |5 + drivers/spi/Makefile |1 + drivers/spi/tegra_slink.c | 343 + drivers/spi/tegra_spi.c | 45 +++- include/configs/cardhu.h | 11 + include/fdtdec.h |2 + lib/fdtdec.c |2 + 14 files changed, 589 insertions(+), 4 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra/tegra_slink.h create mode 100644 drivers/spi/tegra_slink.c -- 1.7.10.4 -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/7] tegra20: fdt: add SPI SFLASH node
On 01/29/2013 04:51 PM, Allen Martin wrote: Add node for tegra20 SPI SFLASH controller to fdt. The series, briefly, Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 01/29/2013 02:57 PM, Tom Warren wrote: Stephen, On Tue, Jan 29, 2013 at 2:08 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 01/29/2013 01:40 PM, Tom Warren wrote: Stephen, On Tue, Jan 29, 2013 at 1:09 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 01/29/2013 12:19 PM, Tom Warren wrote: Note that T114 does not have a separate/different DVC (power I2C) controller like T20 - all 5 I2C controllers are identical, but I2C5 is used to designate the controller intended for power control (PWR_I2C in the schematics). + reg = 0x7000c000 0x100; The interrupts property is missing here. I didn't have an interrupts property for I2C on the T30 dts files, either. That sounds like a bug in the DT. What is it used for in U-Boot? U-Boot doesn't use interrupts at least on Tegra, so it's not used. However, it'd be best to keep the U-Boot DT in line with the kernel DT so we can easily spot differences. There has been talk of trying to use the same DT for both too, although we're a long long way off from that. I'll add it, but it seems silly to add unused values, especially when your past review critiques of DT files have asked for minimum functionality, which I agree with. I meant to mention here that my previous comments were about unused nodes; it doesn't seem useful to add a bunch of nodes that we aren't using, until the drivers are ready and we actually end up using those nodes. However, when a node is added, we should fill it in fully, so the DT conforms to the binding for that node. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MAKEALL: add support for per architecture toolchains
Add support for per architecture CROSS_COMPILE toolchain definitions
via CROSS_COMPILE_ARCH where ARCH is any of the supported u-boot
architectures. This allows building every supported u-boot board in a
single pass of MAKEALL.
Signed-off-by: Allen Martin amar...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
---
v2: Changed CROSS_COMPILE_ARM to CROSS_COMPILE_ARCH in help text
---
MAKEALL | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 5b06c54..397adef 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -35,6 +35,9 @@ usage()
Environment variables:
BUILD_NCPUS number of parallel make jobs (default: auto)
CROSS_COMPILEcross-compiler toolchain prefix (default: )
+ CROSS_COMPILE_ARCH cross-compiler toolchain prefix for
+ architecture ARCH. Substitute ARCH for any
+ supported architecture (default: )
MAKEALL_LOGDIR output all logs to here (default: ./LOG/)
BUILD_DIRoutput build directory (default: ./)
BUILD_NBUILDSnumber of parallel targets (default: 1)
@@ -180,13 +183,6 @@ else
JOBS=
fi
-
-if [ ${CROSS_COMPILE} ] ; then
- MAKE=make CROSS_COMPILE=${CROSS_COMPILE}
-else
- MAKE=make
-fi
-
if [ ${MAKEALL_LOGDIR} ] ; then
LOG_DIR=${MAKEALL_LOGDIR}
else
@@ -585,6 +581,18 @@ get_target_maintainers() {
echo $mail
}
+get_target_arch() {
+ local target=$1
+
+ # Automatic mode
+ local line=`egrep -i ^[[:space:]]*${target}[[:space:]] boards.cfg`
+
+ if [ -z ${line} ] ; then echo ; return ; fi
+
+ set ${line}
+ echo $2
+}
+
list_target() {
if [ $PRINT_MAINTS != 'y' ] ; then
echo $1
@@ -655,6 +663,16 @@ build_target() {
export BUILD_DIR=${output_dir}
+ target_arch=$(get_target_arch ${target})
+ eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
+ if [ ${cross_toolchain} ] ; then
+ MAKE=make CROSS_COMPILE=${cross_toolchain}
+ elif [ ${CROSS_COMPILE} ] ; then
+ MAKE=make CROSS_COMPILE=${CROSS_COMPILE}
+ else
+ MAKE=make
+ fi
+
${MAKE} distclean /dev/null
${MAKE} -s ${target}_config
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can I read env from RAM in uboot script?
Hi John Stile, On 01/30/2013 01:33 AM, John Stile wrote: That worked! Very nice! But, I had to apply the patches manually. Email may have messed up the patch sets with new-lines and indentation. Can this be added to the main stream? I am on to learning 'env import'. Thank you. I will prepare the patch and send to u-boot mainline. If email messed it up once, I guess it could mess it up again, but I generated patches using: diff -Naur before/ after/ diff.patch I think this can not be applied to u-boot mainline directly, because it missed comments and author, and etc. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
