Re: [U-Boot] [PATCH 05/22] board/linkstation/ide.c: Fix GCC 4.6 build warnings
Hi Wolfgang
On Sat, 5 Nov 2011, Wolfgang Denk wrote:
Fix:
ide.c: In function 'ide_preinit':
ide.c:69:21: warning: array subscript is above array bounds
[-Warray-bounds]
ide.c:69:21: warning: array subscript is above array bounds
[-Warray-bounds]
ide.c:70:17: warning: array subscript is above array bounds
[-Warray-bounds]
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
board/linkstation/ide.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index 568fdf5..14e3fd0 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -64,12 +64,14 @@ int ide_preinit (void)
ide_bus_offset[0] = pci_hose_bus_to_phys(hose,
ide_bus_offset[0]
0xfffe,
PCI_REGION_IO);
+#if CONFIG_SYS_IDE_MAXBUS 1
I don't have gcc 4.6 installed here unfortunately, but wondering, wouldn't
this
if (CONFIG_SYS_IDE_MAXBUS 1) {
ide_bus_offset[1]...
}
also make the compiler happy? Maybe not, because, probably, the above if
would be optimised away after indicies are verifies. But if it does fix
the problem too - it would be preferable IMHO. Of course, one could also
use a perversion like
if (CONFIG_SYS_IDE_MAXBUS 1) {
ide_bus_offset[CONFIG_SYS_IDE_MAXBUS 1]...
}
But that'd be even uglier, than the preprocessor #if:)
Thanks
Guennadi
pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_2,
(u32 *) ide_bus_offset[1]);
ide_bus_offset[1] = 0xfffe;
ide_bus_offset[1] = pci_hose_bus_to_phys(hose,
ide_bus_offset[1]
0xfffe,
PCI_REGION_IO);
+#endif
}
if (pci_find_device (PCI_VENDOR_ID_ITE, PCI_DEVICE_ID_ITE_8212, 0) !=
-1) {
--
1.7.6.4
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hi All, is anybody involved into Renesas SH development?
On Wed, 14 Jul 2010, Fabio Giovagnini wrote: Hi Guennadi. I saw your work about sh mobile. I have these problem: 1) I have my own board a little bit different than rsk7203; much NOR flash; much SDRAM; 2) To know better the structure I'd like to run from NOR flash without reloc. How can I change noot.lds? Sorry, I'm not involved in U-Boot development on SH, I just pointed out, that it exists and is maintained. I'd not have the email of Nobuhiro Iwamatsu. Do you have? Why don't you just look in the MAINTAINERS file in U-Boot sources? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hi All, is anybody involved into Renesas SH development?
On Tue, 13 Jul 2010, Fabio Giovagnini wrote: Good morning, if any of you is involved in such a develop, I'd like to have discussion if possible about u-boot onto sh architecture You're probably aware, that U-Boot is already running on SH. So, just post your specific questions, you might want to CC U-Boot SH maintainer, if you like. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] remove myself as a maintainer of several ARM boards
Since I haven't been actively maintaining these boards for a long while, keeping myself as their maintainer makes no sense. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v1 - v2 added to the orphaned list diff --git a/MAINTAINERS b/MAINTAINERS index bb03f17..6274599 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -645,12 +645,6 @@ Sergey Lapin sla...@ossfans.org afeb9260ARM926EJS (AT91SAM9260 SoC) -Guennadi Liakhovetski g.liakhovet...@gmx.de - - imx31_phycore_eet i.MX31 - mx31ads i.MX31 - SMDK6400S3C6400 - Nishanth Menon n...@ti.com omap3_sdp3430 ARM CORTEX-A8 (OMAP3xx SoC) @@ -786,6 +780,10 @@ Unknown / orphaned boards: ixdp425 xscale Kyle Harris khar...@nexus-tech.net / dead address lubbock xscale Kyle Harris khar...@nexus-tech.net / dead address + imx31_phycore_eet i.MX31 Guennadi Liakhovetski g.liakhovet...@gmx.de / resigned + mx31ads i.MX31 Guennadi Liakhovetski g.liakhovet...@gmx.de / resigned + SMDK6400 S3C6400 Guennadi Liakhovetski g.liakhovet...@gmx.de / resigned + # # x86 Systems: # # # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] remove myself as a maintainer of several ARM boards
Since I haven't been actively maintaining these boards for a long while, keeping myself as their maintainer makes no sense. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- I've submitted my last patch to U-Boot almost a year ago and haven't been following U-Boot development since then. This, the general lack of time and limited access to affected hardware make me unsuitable for the role of a maintainer of these boards. This patch just confirms in writing the de-facto situation. I'm also listed as the maintainer of the PPC Linkstation board, we can try to keep myself for that role for a while and see if I can be of any use at all. At least I have the hardware (although it is currently in use, and jtag access to it hasn't been exercised for a few years) and I have contact to other developers for this platform, so, maybe I'll still be able to help with it. diff --git a/MAINTAINERS b/MAINTAINERS index bb03f17..146d98d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -645,12 +645,6 @@ Sergey Lapin sla...@ossfans.org afeb9260ARM926EJS (AT91SAM9260 SoC) -Guennadi Liakhovetski g.liakhovet...@gmx.de - - imx31_phycore_eet i.MX31 - mx31ads i.MX31 - SMDK6400S3C6400 - Nishanth Menon n...@ti.com omap3_sdp3430 ARM CORTEX-A8 (OMAP3xx SoC) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPI: Fix 32 bit transfers in mxc_spi.c
On Mon, 4 Jan 2010, Magnus Lilja wrote: Hi Magnus Lilja skrev: 2009/12/3 Guennadi Liakhovetski l...@denx.de: On Wed, 2 Dec 2009, Wolfgang Denk wrote: Dear Guennadi, In message 1257965907-5622-1-git-send-email-lilja.mag...@gmail.com Magnus Lilja wrote: diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index fad9840..8b5d4be 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -142,6 +142,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout, *(u8 *)din = data; else if (bitlen 17) *(u16 *)din = data; + else + *in_l = data; } } Could you please comment ? Hm, I'm afraid, I broke more than just that. Now that I look at this loop, looks like I broke not only 32-bit transfers, but also all transfers with bitlen 16, and this fix is then incomplete - it doesn't fix cases with bitlen 32. Magnus, looks like you also only use single-block (bitlen=32) transfers? Do you have a chance to test 32-bit transfers too? No, I don't have anything suitable on the SPI bus that would allow me to test 32-bit transfer. So, what was the verdict? I can only test SPI with the ATLAS (32 bit xfers). Can the patch be accepted even though it doesn't fix all problems or does it have to a fix-everything-patch? I would prefer a proper fix, or an explicit restriction on transfer length. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPI: Fix 32 bit transfers in mxc_spi.c
On Wed, 2 Dec 2009, Wolfgang Denk wrote: Dear Guennadi, In message 1257965907-5622-1-git-send-email-lilja.mag...@gmail.com Magnus Lilja wrote: Commit f9b6a1575d9f1ca192e4cb60e547aa66f08baa3f, i.MX31: fix SPI driver for shorter than 32 bit broke 32 bit transfers. This patch makes single 32 bit transfer work again. Tested on i.MX31 Litekit and i.MX31 PDK using 32 bit transfers to the MC13783/ATLAS chip (using the 'date' command). Signed-off-by: Magnus Lilja lilja.mag...@gmail.com Cc: Guennadi Liakhovetski l...@denx.de --- I don't think transfers larger than 32 bits will work. It seems like they worked in the original driver, but the above commit broke that. This patch does not try to fix that problem. drivers/spi/mxc_spi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index fad9840..8b5d4be 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -142,6 +142,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout, *(u8 *)din = data; else if (bitlen 17) *(u16 *)din = data; + else + *in_l = data; } } Could you please comment ? Hm, I'm afraid, I broke more than just that. Now that I look at this loop, looks like I broke not only 32-bit transfers, but also all transfers with bitlen 16, and this fix is then incomplete - it doesn't fix cases with bitlen 32. Magnus, looks like you also only use single-block (bitlen=32) transfers? Do you have a chance to test 32-bit transfers too? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning
On Tue, 22 Sep 2009, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message pine.lnx.4.64.0909162240120.19...@axis700.grange you wrote: I have the hardware, yes, and I even have something, that should be a Jtag cable for it... But I don't have near 100% certainty, that if I brick it I will be able in reasonable time to recover it... But, hey, that's what I have that hardware for... So, yes, I would be able to test, just not immediately. Do you think you can submit this patch before the end of the current merge window? Otherwise I'd check in my previous clean up patch now, and then wait for your rework in the next (?) version. don't think so, very unlikely I'll have time for this in the next month. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning
On Tue, 15 Sep 2009, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message pine.lnx.4.64.0909152214370.4...@axis700.grange you wrote: pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0, -(u32 *) ide_bus_offset[0]); - ide_bus_offset[0] = 0xfffe; +ide_bus_offset32); + ide_bus_offset[0] = ide_bus_offset32 0xfffe; ide_bus_offset[0] = pci_hose_bus_to_phys(hose, ide_bus_offset[0] 0xfffe, PCI_REGION_IO); Ok, yes, this looks much better now without casts, but - the double 0xfffe above seems completely redundant to me. I understand, that that's not the problem you're fixing with this patch, and I will perfectly understand if you refuse to mix these two fixes, but... Another thing - Ah, I see. Sorry I missed that. It's easy to fix. why doesn't the compiler complain about exactly identical cast (ok, almost) a couple of lines down for ide_bus_offset[1]? So, how about this Good question. Please post it on a gcc mailing ist and report back the results you get. diff instead (only compile-tested) (not for submission yet, so, no Sob's, no patch header): Hm, this is much more intrusive - do you have a way to test in on real hardware? I have the hardware, yes, and I even have something, that should be a Jtag cable for it... But I don't have near 100% certainty, that if I brick it I will be able in reasonable time to recover it... But, hey, that's what I have that hardware for... So, yes, I would be able to test, just not immediately. Thanks Guennadi --- Guennadi Liakhovetski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning
On Tue, 15 Sep 2009, Wolfgang Denk wrote:
Fix warning: ide.c:60: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Guennadi Liakhovetski l...@denx.de
---
v2: Better implementation as suggested by Scott Wood in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67840/focus=67891
board/linkstation/ide.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index 2c89d62..568fdf5 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -54,11 +54,13 @@ int ide_preinit (void)
if (devbusfn == -1)
devbusfn =
pci_find_device(PCI_VENDOR_ID_ITE,PCI_DEVICE_ID_ITE_8212,0);
if (devbusfn != -1) {
+ u32 ide_bus_offset32;
+
status = 0;
pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
-(u32 *)
ide_bus_offset[0]);
- ide_bus_offset[0] = 0xfffe;
+ide_bus_offset32);
+ ide_bus_offset[0] = ide_bus_offset32 0xfffe;
ide_bus_offset[0] = pci_hose_bus_to_phys(hose,
ide_bus_offset[0]
0xfffe,
PCI_REGION_IO);
Ok, yes, this looks much better now without casts, but - the double
0xfffe above seems completely redundant to me. I understand, that
that's not the problem you're fixing with this patch, and I will perfectly
understand if you refuse to mix these two fixes, but... Another thing -
why doesn't the compiler complain about exactly identical cast (ok,
almost) a couple of lines down for ide_bus_offset[1]? So, how about this
diff instead (only compile-tested) (not for submission yet, so, no Sob's,
no patch header):
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index 2c89d62..f96af74 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -54,20 +54,23 @@ int ide_preinit (void)
if (devbusfn == -1)
devbusfn =
pci_find_device(PCI_VENDOR_ID_ITE,PCI_DEVICE_ID_ITE_8212,0);
if (devbusfn != -1) {
+ u32 ide_bus_offset32;
+
status = 0;
- pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
- (u32 *)
ide_bus_offset[0]);
- ide_bus_offset[0] = 0xfffe;
+ pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0,
+ ide_bus_offset32);
+ ide_bus_offset[0] = ide_bus_offset32 0xfffe;
ide_bus_offset[0] = pci_hose_bus_to_phys(hose,
-ide_bus_offset[0]
0xfffe,
-PCI_REGION_IO);
- pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_2,
- (u32 *) ide_bus_offset[1]);
- ide_bus_offset[1] = 0xfffe;
- ide_bus_offset[1] = pci_hose_bus_to_phys(hose,
-ide_bus_offset[1]
0xfffe,
-PCI_REGION_IO);
+ ide_bus_offset[0], PCI_REGION_IO);
+
+ if (CONFIG_SYS_IDE_MAXBUS 1) {
+ pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_2,
+ ide_bus_offset32);
+ ide_bus_offset[1] = ide_bus_offset32 0xfffe;
+ ide_bus_offset[1] = pci_hose_bus_to_phys(hose,
+ ide_bus_offset[1], PCI_REGION_IO);
+ }
}
if (pci_find_device (PCI_VENDOR_ID_ITE, PCI_DEVICE_ID_ITE_8212, 0) !=
-1) {
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/linkstation/ide.c: Fix compile warning
Hi Wolfgang
On Fri, 11 Sep 2009, Wolfgang Denk wrote:
Fix warning: ide.c:60: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Guennadi Liakhovetski l...@denx.de
---
board/linkstation/ide.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index 2c89d62..5dd1d0e 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -54,10 +54,12 @@ int ide_preinit (void)
if (devbusfn == -1)
devbusfn =
pci_find_device(PCI_VENDOR_ID_ITE,PCI_DEVICE_ID_ITE_8212,0);
if (devbusfn != -1) {
+ ulong *ide_bus_offset_ptr = ide_bus_offset[0];
+
status = 0;
pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
-(u32 *)
ide_bus_offset[0]);
+(u32
*)ide_bus_offset_ptr);
Can we also use this occasion to get rid of this typecast?
ide_bus_offset[0] = 0xfffe;
ide_bus_offset[0] = pci_hose_bus_to_phys(hose,
ide_bus_offset[0]
0xfffe,
--
1.6.0.6
Thanks
Guennadi
---
Guennadi Liakhovetski
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] FDT: remove obsolete OF_CPU and OF_SOC macros.
On Wed, 9 Sep 2009, Marcel Ziswiler wrote: Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Changes since v1: - CC all respective board maintainers README|6 -- include/configs/IDS8247.h |2 -- include/configs/MPC8260ADS.h |1 - include/configs/linkstation.h |2 -- include/configs/mgcoge.h |2 -- include/configs/mpc7448hpc2.h |1 - include/configs/muas3001.h|2 -- include/configs/stxxtc.h |1 - 8 files changed, 4 insertions(+), 13 deletions(-) diff --git a/README b/README index ff4ed8b..3cb7786 100644 --- a/README +++ b/README @@ -368,8 +368,10 @@ The following options need to be configured: * Adds the fdt command * The bootm command automatically updates the fdt - OF_CPU - The proper name of the cpus node. - OF_SOC - The proper name of the soc node. + OF_CPU - The proper name of the cpus node (only required for + MPC512X and MPC5xxx based boards). + OF_SOC - The proper name of the soc node (only required for + MPC512X and MPC5xxx based boards). OF_TBCLK - The timebase frequency. OF_STDOUT_PATH - The path to the console device diff --git a/include/configs/IDS8247.h b/include/configs/IDS8247.h index 4c4af05..147a8b2 100644 --- a/include/configs/IDS8247.h +++ b/include/configs/IDS8247.h @@ -125,8 +125,6 @@ #define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP1 -#define OF_CPU PowerPC,8...@0 -#define OF_SOC s...@f000 #define OF_TBCLK (bd-bi_busfreq / 4) #define OF_STDOUT_PATH /s...@f000/serial8...@e0008000 diff --git a/include/configs/MPC8260ADS.h b/include/configs/MPC8260ADS.h index 942a4cc..677a143 100644 --- a/include/configs/MPC8260ADS.h +++ b/include/configs/MPC8260ADS.h @@ -209,7 +209,6 @@ #define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP1 #if defined(CONFIG_OF_LIBFDT) -#define OF_CPU c...@0 #define OF_TBCLK (bd-bi_busfreq / 4) #endif diff --git a/include/configs/linkstation.h b/include/configs/linkstation.h index 2feb3ae..16b464c 100644 --- a/include/configs/linkstation.h +++ b/include/configs/linkstation.h @@ -96,8 +96,6 @@ #define CONFIG_OF_LIBFDT 1 -#define OF_CPU PowerPC,603e -#define OF_SOC soc...@8000 #define OF_STDOUT_PATH /soc10x/ser...@80004600 /* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */ diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h index b955749..55d1fc9 100644 --- a/include/configs/mgcoge.h +++ b/include/configs/mgcoge.h @@ -347,8 +347,6 @@ #define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP1 -#define OF_CPU PowerPC,8...@0 -#define OF_SOC s...@f000 #define OF_TBCLK (bd-bi_busfreq / 4) #define OF_STDOUT_PATH /soc/cpm/ser...@11a90 diff --git a/include/configs/mpc7448hpc2.h b/include/configs/mpc7448hpc2.h index 4f98ba4..be12186 100644 --- a/include/configs/mpc7448hpc2.h +++ b/include/configs/mpc7448hpc2.h @@ -79,7 +79,6 @@ #define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP1 -#define OF_CPU PowerPC,7...@0 #define OF_TSI tsi...@c000 #define OF_TBCLK (bd-bi_busfreq / 8) #define OF_STDOUT_PATH /tsi...@c000/ser...@7808 diff --git a/include/configs/muas3001.h b/include/configs/muas3001.h index ae033b2..c94daa3 100644 --- a/include/configs/muas3001.h +++ b/include/configs/muas3001.h @@ -405,8 +405,6 @@ #define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP1 -#define OF_CPU PowerPC,8...@0 -#define OF_SOC s...@f000 #define OF_TBCLK (bd-bi_busfreq / 4) #if defined(CONFIG_MUAS_DEV_BOARD) #define OF_STDOUT_PATH /soc/cpm/ser...@11a90 diff --git a/include/configs/stxxtc.h b/include/configs/stxxtc.h index d16262b..5854366 100644 --- a/include/configs/stxxtc.h +++ b/include/configs/stxxtc.h @@ -509,7 +509,6 @@ typedef unsigned int led_id_t; /* pass open firmware flattened device tree */ #define CONFIG_OF_LIBFDT 1 -#define OF_CPU PowerPC,mpc...@0 #define OF_TBCLK (MPC8XX_HZ / 16) #endif /* __CONFIG_H */ -- 1.6.4.2 --- Guennadi Liakhovetski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/linkstation/ide.c: Fix compile warning
On Fri, 11 Sep 2009, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message pine.lnx.4.64.0909111259280.6...@axis700.grange you wrote:
Hi Wolfgang
On Fri, 11 Sep 2009, Wolfgang Denk wrote:
Fix warning: ide.c:60: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Guennadi Liakhovetski l...@denx.de
---
board/linkstation/ide.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index 2c89d62..5dd1d0e 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -54,10 +54,12 @@ int ide_preinit (void)
if (devbusfn == -1)
devbusfn =
pci_find_device(PCI_VENDOR_ID_ITE,PCI_DEVICE_ID_ITE_8212,0);
if (devbusfn != -1) {
+ ulong *ide_bus_offset_ptr = ide_bus_offset[0];
+
status = 0;
pci_read_config_dword (devbusfn, PCI_BASE_ADDRESS_0,
-(u32 *)
ide_bus_offset[0]);
+(u32
*)ide_bus_offset_ptr);
Can we also use this occasion to get rid of this typecast?
No, as this would result in
ide.c:62: warning: passing argument 3 of 'pci_read_config_dword' from
incompatible pointer type
OK, we can declare ide_bus_offset_ptr as u32 8, but then we need the
cast there to avoid a initialization from incompatible pointer type
warning - so this isn't exactly an improvement.
Ok, understand.
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
I suggest we leave it as is, as this is the minimal-invasive change.
If you want to submit a more general cleanup patch (unifying data
types) you are welcome (but that would be a separate action in any
case).
Best regards,
Wolfgang Denk
Thanks
Guennadi
---
Guennadi Liakhovetski
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31ads: update board configuration
On Thu, 13 Aug 2009, Wolfgang Denk wrote:
Bring default environment more in line with other boards;
fix address range for mtest command.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Guennadi Liakhovetski l...@denx.de
Having various board configurations look similar has, certainly,
advantages, but I've got a couple of comments / questions:
---
include/configs/mx31ads.h | 62
++---
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 363ea1b..e6c02c8 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -56,7 +56,6 @@
/*
* Hardware drivers
*/
-
Is this removed empty line also to make it look more in line with others?
#define CONFIG_MXC_UART 1
#define CONFIG_SYS_MX31_UART11
@@ -87,27 +86,38 @@
#define CONFIG_CMD_SPI
#define CONFIG_CMD_DATE
-#define CONFIG_BOOTDELAY 3
+#define CONFIG_BOOTDELAY 5
And this? do (most) other boards also have 5 seconds bootdelay?
Personally, I find shorter delays better, they spare you a couple of
seconds on default boots and usually hitting a key within a 2 or 3 second
delay is not a problem either. Or is there a technical reason for this
with this specific board?
#define CONFIG_LOADADDR 0x8080 /* loadaddr env var */
#define CONFIG_EXTRA_ENV_SETTINGS
\
netdev=eth0\0 \
- uboot_addr=0xa000\0 \
- uboot=mx31ads/u-boot.bin\0\
+ u-boot_addr=0xa000\0 \
+ u-boot=mx31ads/u-boot.bin\0 \
+ load=tftp ${loadaddr} ${u-boot}\0 \
+ update=prot off ${u-boot_addr} +${filesize}; \
+ era ${u-boot_addr} +${filesize}; \
+ cp.b ${loadaddr} ${u-boot_addr} ${filesize}; \
+ sete filesize;sete fileaddr;save\0\
Having abbreviated commands is good for typing, but IMHO in the
environment, especially in the default environment, it is better to have
complete commands. Besides, this seems inconsistent with the below:
kernel=mx31ads/uImage\0 \
- nfsroot=/opt/eldk/arm\0 \
- bootargs_base=setenv bootargs console=ttymxc0,115200\0\
- bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs\
- ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
- bootcmd=run bootcmd_net\0 \
- bootcmd_net=run bootargs_base bootargs_nfs; \
- tftpboot ${loadaddr} ${kernel}; bootm\0 \
- prg_uboot=tftpboot ${loadaddr} ${uboot}; \
- protect off ${uboot_addr} 0xa003; \
- erase ${uboot_addr} 0xa003; \
- cp.b ${loadaddr} ${uboot_addr} ${filesize}; \
- setenv filesize; saveenv\0
+ rootpath=/opt/eldk/armVFP\0 \
+ netdev=eth0\0 \
+ consdev=ttymxc0\0 \
+ nfsargs=setenv bootargs root=/dev/nfs rw \
+ nfsroot=${serverip}:${rootpath}\0 \
+ ramargs=setenv bootargs root=/dev/ram rw\0\
+ addip=setenv bootargs ${bootargs} \
+ ip=${ipaddr}:${serverip}:${gatewayip}:${netmask} \
+ :${hostname}:${netdev}:off\0 \
+ addcons=setenv bootargs ${bootargs} \
+ console=${consdev},${baudrate}\0 \
Above setenvs are spelled out completely.
+ flash_nfs=run nfsargs addip addcons; \
+ bootm ${kernel_addr}\0\
+ flash_self=run ramargs addip addcons; \
+ bootm ${kernel_addr} ${ramdisk_addr}\0\
+ net_nfs=tftp 20 ${bootfile}; \
+ run nfsargs addip addcons;bootm\0 \
+ bootcmd=run net_nfs\0
#define CONFIG_DRIVER_CS8900 1
#define CS8900_BASE 0xb4020300
@@ -128,20 +138,20 @@
/*
* Miscellaneous configurable options
*/
-#define CONFIG_SYS_LONGHELP /* undef to save memory */
-#define CONFIG_SYS_PROMPT=
-#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer
Size */
+#define CONFIG_SYS_LONGHELP /* undef to save
Re: [U-Boot] howto get the nand flash enviroment variables in env_init ?
On Thu, 18 Jun 2009, Manuel Sahm wrote: Hello, I want to use the silent paramter of ubbot in a dynamically way. The problem is that I use a Nand Flash to store my uboot paramters. When the function env_init is called only the default enviroment is linked as the actual enviroment. After env_init the serial console is initialized and the banner is printed. I want to read out my actual uboot paramters from NAND to check the silent paramter before any character is sent through the Serial-Console. I placed the functions nand_init(); and env_relocate(); into the function env_init, buth that desn´t work. (I think there is always a reset ?!) Doesn't this patch help: http://lists.denx.de/pipermail/u-boot/2009-May/052901.html Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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] howto get the nand flash enviroment variables inenv_init ?
On Thu, 18 Jun 2009, Manuel Sahm wrote: Hello, Please, do not top-post. thanks for reply, this patch is very good in general, but the problem is that the function nand_boot() is never called in my architecture. I use a AT91SAM9G20 from Atmel [ARM9]. Do oyu have another idea ? You mean you boot from another memory (NOR) and have your environment in NAND? I think, this is one of configurations, that we said noone would ever come up with... Maybe I'm wrong though, see if others correct me. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] nand_spl: read environment early, when booting from NAND using nand_spl
On Tue, 19 May 2009, Scott Wood wrote:
On Mon, May 18, 2009 at 04:07:22PM +0200, Guennadi Liakhovetski wrote:
int env_init(void)
{
-#if defined(ENV_IS_EMBEDDED)
+#if defined(ENV_IS_EMBEDDED) || defined(CONFIG_NAND_ENV_DST)
int crc1_ok = 0, crc2_ok = 0;
- env_t *tmp_env1, *tmp_env2;
+ env_t *tmp_env1;
+
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ env_t *tmp_env2;
- tmp_env1 = env_ptr;
tmp_env2 = (env_t *)((ulong)env_ptr + CONFIG_ENV_SIZE);
+ crc2_ok = (crc32(0, tmp_env2-data, ENV_SIZE) == tmp_env2-crc);
+#endif
Are there any existing boards that use a redundant embedded environment
without defining CONFIG_ENV_OFFSET_REDUND, since it seems it was done
unconditionally before?
Hm, interesting question. On the one hand, env_init() indeed just looks at
(ulong)env_ptr + CONFIG_ENV_SIZE for a copy of the redundant environment,
without even using CONFIG_ENV_OFFSET_REDUND. On the other hand, the
saveenv() function on NAND exists in two versions depending on whether
CONFIG_ENV_OFFSET_REDUND is defined or not, and only one of them really
handles the redundant environment, and there it uses
CONFIG_ENV_OFFSET_REDUND, and not (ulong)env_ptr + CONFIG_ENV_SIZE.
Ok, here's the ultimate answer: to use redundant environment you need the
flags member in env_t, and that one is only present, if
CONFIG_SYS_REDUNDAND_ENVIRONMENT is defined. And on NAND that one is only
defined if CONFIG_ENV_OFFSET_REDUND is defined. So, no, you cannot use
redundant environment without CONFIG_ENV_OFFSET_REDUND in NAND, and we
better use CONFIG_ENV_OFFSET_REDUND in env_init() too...
+ tmp_env1 = env_ptr;
crc1_ok = (crc32(0, tmp_env1-data, ENV_SIZE) == tmp_env1-crc);
- crc2_ok = (crc32(0, tmp_env2-data, ENV_SIZE) == tmp_env2-crc);
- if (!crc1_ok !crc2_ok)
+ if (!crc1_ok !crc2_ok) {
+ gd-env_addr = 0;
gd-env_valid = 0;
- else if(crc1_ok !crc2_ok)
+
+ return 0;
+ } else if (crc1_ok !crc2_ok) {
No need for else after return.
Right, but, I think, it just looks more uniform for handling the four
[!]crc1_ok [!]crc2_ok cases. Can remove it if you prefer, sure.
diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
index cac58cf..018f576 100644
--- a/include/configs/smdk6400.h
+++ b/include/configs/smdk6400.h
@@ -209,6 +209,9 @@
/* total memory available to uboot */
#define CONFIG_SYS_UBOOT_SIZE (1024 * 1024)
+/* Put environment copies after the end of U-Boot owned RAM */
+#define CONFIG_NAND_ENV_DST(CONFIG_SYS_UBOOT_BASE +
CONFIG_SYS_UBOOT_SIZE)
+
This is the only board where I see CONFIG_SYS_UBOOT_SIZE defined. What
would other boards supply here? How would they make sure that u-boot
doesn't clobber the RAM environment (the u-boot image itself relocates,
avoiding this problem)? Perhaps we should move the environment when
relocating.
It is moved into a malloc()'ed buffer, I haven't changed
env_relocate_spec(). As for other boards, they have to find a suitable
location for CONFIG_NAND_ENV_DST themselves too, of course.
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index c7eadad..be2e69c 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -246,6 +246,16 @@ void nand_boot(void)
ret = nand_load(nand_info, CONFIG_SYS_NAND_U_BOOT_OFFS,
CONFIG_SYS_NAND_U_BOOT_SIZE,
(uchar *)CONFIG_SYS_NAND_U_BOOT_DST);
+#ifdef CONFIG_NAND_ENV_DST
+ nand_load(nand_info, CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
+ (uchar *)CONFIG_NAND_ENV_DST);
+
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ nand_load(nand_info, CONFIG_ENV_OFFSET_REDUND, CONFIG_ENV_SIZE,
+ (uchar *)CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE);
+#endif
+#endif
Don't forget the other NAND boot drivers... perhaps we should factor out
the nand_load calls into something common.
Hm, I cannot test any other NAND boot drivers, so, I would prefer to leave
them to someone who actually can do that.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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
[U-Boot] [PATCH 1/2] env_nand: remove unused variable.
Remove an unused total variable in multiple functions.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
common/env_nand.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/common/env_nand.c b/common/env_nand.c
index 76569da..21bce25 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -103,12 +103,9 @@ uchar env_get_char_spec (int index)
int env_init(void)
{
#if defined(ENV_IS_EMBEDDED)
- size_t total;
int crc1_ok = 0, crc2_ok = 0;
env_t *tmp_env1, *tmp_env2;
- total = CONFIG_ENV_SIZE;
-
tmp_env1 = env_ptr;
tmp_env2 = (env_t *)((ulong)env_ptr + CONFIG_ENV_SIZE);
@@ -183,12 +180,10 @@ int writeenv(size_t offset, u_char *buf)
#ifdef CONFIG_ENV_OFFSET_REDUND
int saveenv(void)
{
- size_t total;
int ret = 0;
nand_erase_options_t nand_erase_options;
env_ptr-flags++;
- total = CONFIG_ENV_SIZE;
nand_erase_options.length = CONFIG_ENV_RANGE;
nand_erase_options.quiet = 0;
@@ -226,7 +221,6 @@ int saveenv(void)
#else /* ! CONFIG_ENV_OFFSET_REDUND */
int saveenv(void)
{
- size_t total;
int ret = 0;
nand_erase_options_t nand_erase_options;
@@ -243,7 +237,6 @@ int saveenv(void)
return 1;
puts (Writing to Nand... );
- total = CONFIG_ENV_SIZE;
if (writeenv(CONFIG_ENV_OFFSET, (u_char *) env_ptr)) {
puts(FAILED!\n);
return 1;
@@ -287,12 +280,9 @@ int readenv (size_t offset, u_char * buf)
void env_relocate_spec (void)
{
#if !defined(ENV_IS_EMBEDDED)
- size_t total;
int crc1_ok = 0, crc2_ok = 0;
env_t *tmp_env1, *tmp_env2;
- total = CONFIG_ENV_SIZE;
-
tmp_env1 = (env_t *) malloc(CONFIG_ENV_SIZE);
tmp_env2 = (env_t *) malloc(CONFIG_ENV_SIZE);
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] nand_spl: read environment early, when booting from NAND using nand_spl
Currently, when booting from NAND using nand_spl, in the beginning the default
environment is used until later in boot process the dynamic environment is read
out. This way environment variables that must be interpreted early, like the
baudrate or silent, cannot be modified dynamically and remain at their
default values. Fix this problem by reading out main and redundand (if used)
copies of the environment in the nand_spl code.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
README |6 ++
common/env_nand.c | 43 ++-
include/configs/smdk6400.h |3 +++
nand_spl/nand_boot.c | 10 ++
4 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/README b/README
index 142dbcc..060b676 100644
--- a/README
+++ b/README
@@ -2422,6 +2422,12 @@ to save the current settings.
to a block boundary, and CONFIG_ENV_SIZE must be a multiple of
the NAND devices block size.
+- CONFIG_NAND_ENV_DST
+
+ Defines address in RAM to which the nand_spl code should copy the
+ environment. If redundant environment is used, it will be copied to
+ CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE.
+
- CONFIG_SYS_SPI_INIT_OFFSET
Defines offset to the initial SPI buffer area in DPRAM. The
diff --git a/common/env_nand.c b/common/env_nand.c
index 21bce25..90a1c45 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -68,9 +68,11 @@ extern int default_environment_size;
char * env_name_spec = NAND;
-#ifdef ENV_IS_EMBEDDED
+#if defined(ENV_IS_EMBEDDED)
extern uchar environment[];
env_t *env_ptr = (env_t *)(environment[0]);
+#elif defined(CONFIG_NAND_ENV_DST)
+env_t *env_ptr = (env_t *)CONFIG_NAND_ENV_DST;
#else /* ! ENV_IS_EMBEDDED */
env_t *env_ptr = 0;
#endif /* ENV_IS_EMBEDDED */
@@ -102,23 +104,33 @@ uchar env_get_char_spec (int index)
*/
int env_init(void)
{
-#if defined(ENV_IS_EMBEDDED)
+#if defined(ENV_IS_EMBEDDED) || defined(CONFIG_NAND_ENV_DST)
int crc1_ok = 0, crc2_ok = 0;
- env_t *tmp_env1, *tmp_env2;
+ env_t *tmp_env1;
+
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ env_t *tmp_env2;
- tmp_env1 = env_ptr;
tmp_env2 = (env_t *)((ulong)env_ptr + CONFIG_ENV_SIZE);
+ crc2_ok = (crc32(0, tmp_env2-data, ENV_SIZE) == tmp_env2-crc);
+#endif
+
+ tmp_env1 = env_ptr;
crc1_ok = (crc32(0, tmp_env1-data, ENV_SIZE) == tmp_env1-crc);
- crc2_ok = (crc32(0, tmp_env2-data, ENV_SIZE) == tmp_env2-crc);
- if (!crc1_ok !crc2_ok)
+ if (!crc1_ok !crc2_ok) {
+ gd-env_addr = 0;
gd-env_valid = 0;
- else if(crc1_ok !crc2_ok)
+
+ return 0;
+ } else if (crc1_ok !crc2_ok) {
gd-env_valid = 1;
- else if(!crc1_ok crc2_ok)
+ }
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ else if (!crc1_ok crc2_ok) {
gd-env_valid = 2;
- else {
+ } else {
/* both ok - check serial */
if(tmp_env1-flags == 255 tmp_env2-flags == 0)
gd-env_valid = 2;
@@ -132,14 +144,19 @@ int env_init(void)
gd-env_valid = 1;
}
+ if (gd-env_valid == 2)
+ env_ptr = tmp_env2;
+ else
+#endif
if (gd-env_valid == 1)
env_ptr = tmp_env1;
- else if (gd-env_valid == 2)
- env_ptr = tmp_env2;
-#else /* ENV_IS_EMBEDDED */
+
+ gd-env_addr = (ulong)env_ptr-data;
+
+#else /* ENV_IS_EMBEDDED || CONFIG_NAND_ENV_DST */
gd-env_addr = (ulong)default_environment[0];
gd-env_valid = 1;
-#endif /* ENV_IS_EMBEDDED */
+#endif /* ENV_IS_EMBEDDED || CONFIG_NAND_ENV_DST */
return (0);
}
diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
index cac58cf..018f576 100644
--- a/include/configs/smdk6400.h
+++ b/include/configs/smdk6400.h
@@ -209,6 +209,9 @@
/* total memory available to uboot */
#define CONFIG_SYS_UBOOT_SIZE (1024 * 1024)
+/* Put environment copies after the end of U-Boot owned RAM */
+#define CONFIG_NAND_ENV_DST(CONFIG_SYS_UBOOT_BASE + CONFIG_SYS_UBOOT_SIZE)
+
#ifdef CONFIG_ENABLE_MMU
#define CONFIG_SYS_MAPPED_RAM_BASE 0xc000
#define CONFIG_BOOTCOMMAND nand read 0xc0018000 0x6 0x1c; \
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index c7eadad..be2e69c 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -246,6 +246,16 @@ void nand_boot(void)
ret = nand_load(nand_info, CONFIG_SYS_NAND_U_BOOT_OFFS,
CONFIG_SYS_NAND_U_BOOT_SIZE,
(uchar *)CONFIG_SYS_NAND_U_BOOT_DST);
+#ifdef CONFIG_NAND_ENV_DST
+ nand_load(nand_info, CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
+ (uchar *)CONFIG_NAND_ENV_DST);
+
+#ifdef CONFIG_ENV_OFFSET_REDUND
+ nand_load(nand_info, CONFIG_ENV_OFFSET_REDUND, CONFIG_ENV_SIZE,
+ (uchar *)CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE);
+#endif
Re: [U-Boot] Out-of-tree build for imx31_phycore_eet fails
Hi Wolfgang, On Sun, 29 Mar 2009, Wolfgang Denk wrote: Dear Guennadi, out-of-tree building for the imx31_phycore_eet target fails: - make O=/work/wd/tmp-arm imx31_phycore_eet_config /bin/sh: line 1: /work/wd/tmp-arm/include/config.h: No such file or directory make: *** [imx31_phycore_eet_config] Error 1 ok, that's just a missing + @mkdir -p $(obj)include right? will submit. Please fix. BTW: you also forgot to add your name to the MAINTAINERS file. Please fix this, too. Hm, this is not a new board, just a new configuration for an existing board. Do we really want a new MAINTAINERS entry for it? I looked at a couple other boards with multiple configs, they all had only one entry in MAINTAINERS (at most:-)). Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH] ARM: Add the imx31_phycore_eet board to MAKEALL
Signed-off-by: Guennadi Liakhovetski l...@denx.de --- diff --git a/MAKEALL b/MAKEALL index cf05133..1456a30 100755 --- a/MAKEALL +++ b/MAKEALL @@ -535,15 +535,16 @@ LIST_ARM10= \ # ## ARM11 Systems # -LIST_ARM11= \ - cp1136 \ - omap2420h4 \ - apollon \ - imx31_litekit \ - imx31_phycore \ - mx31ads \ - qong\ - smdk6400\ +LIST_ARM11= \ + cp1136 \ + omap2420h4 \ + apollon \ + imx31_litekit \ + imx31_phycore \ + imx31_phycore_eet \ + mx31ads \ + qong\ + smdk6400\ # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX31: fir imx31_phycore to work after Linux reboot
On Mon, 23 Feb 2009, Sascha Hauer wrote: Hi, On Sat, Feb 21, 2009 at 10:32:33PM +0100, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message pine.lnx.4.64.0902061353280.7...@axis700.grange you wrote: In message pine.lnx.4.64.0902061002160.4...@axis700.grange you wrote: Upon power on i.MX31 enables most peripheral clocks, Linux disables the ones Why does U-Boot do that? i.MX31 does that - the CPU, not U-Boot. I.e., this is the default power-on mode. Yea, but U-Boot performs h/w initialization. So why does it not - like Linux - set sane defaults (with only the necessary clocks enabled) ? I simply forgot it. The clock registers do not get resetted on reset, only on power up. Well, it depends. On U-Boot reset they do get resetted, but not on Linux reboot. Reason - U-Boot uses the watchdog for reset, Linux just jumps to address 0. I tried using watchdog under Linux for reset - it just hung the system. You might want to investigate it further... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH 9/9 v4] ARM: add an eet variant of the imx31_phycore board
The eet variant of the imx31_phycore board has an OLED display, using a
s6e63d6 display controller on the first SPI interface, using GPIO57 as a
chip-select for it. With this configuration you can display 256 colour BMP
images in 16-bit RGB (RGB565) LCD mode.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
On Mon, 23 Feb 2009, Anatolij Gustschin wrote:
can you please address comments from Jean-Christophe to this 9/9 v3 patch?
I'm steel waiting for ACK from Jean-Christophe for 1/9 v4, 2/9 v4 and 9/9 v3
patches from this series.
Oops, sorry, I was sure I had sent it already.
Changes since v1: adjusted to reflect changes in earlier patches: add .id
field initialisation, configuration parameter renamed to CONFIG_S6E63D6.
Changes since v2: fixed the left-over CONFIG_DISPLAY_S6E63D6 parameter.
Changes since v3: added a comment to clarify the SPI chipselect value.
Makefile |6 +++-
board/imx31_phycore/imx31_phycore.c | 57 +
include/asm-arm/arch-mx31/mx31-regs.h | 16 +
include/configs/imx31_phycore.h | 23 +
4 files changed, 101 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 787c5f2..6151e2c 100644
--- a/Makefile
+++ b/Makefile
@@ -3025,8 +3025,12 @@ apollon_config : unconfig
imx31_litekit_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 imx31_litekit NULL mx31
+imx31_phycore_eet_config \
imx31_phycore_config : unconfig
- @$(MKCONFIG) $(@:_config=) arm arm1136 imx31_phycore NULL mx31
+ @if [ -n $(findstring imx31_phycore_eet_config,$@) ]; then
\
+ echo #define CONFIG_IMX31_PHYCORE_EET
$(obj)include/config.h; \
+ fi
+ @$(MKCONFIG) -a imx31_phycore arm arm1136 imx31_phycore NULL mx31
mx31ads_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 mx31ads freescale mx31
diff --git a/board/imx31_phycore/imx31_phycore.c
b/board/imx31_phycore/imx31_phycore.c
index 4c64cb9..0cfa172 100644
--- a/board/imx31_phycore/imx31_phycore.c
+++ b/board/imx31_phycore/imx31_phycore.c
@@ -23,6 +23,7 @@
#include common.h
+#include s6e63d6.h
#include asm/arch/mx31.h
#include asm/arch/mx31-regs.h
@@ -66,6 +67,62 @@ int board_init (void)
return 0;
}
+#ifdef BOARD_LATE_INIT
+int board_late_init(void)
+{
+#ifdef CONFIG_S6E63D6
+ struct s6e63d6 data = {
+ /*
+* See comment in mxc_spi.c::decode_cs() for .cs field format.
+* We use GPIO 57 as a chipselect for the S6E63D6 and chipselect
+* 2 of the SPI controller #1, since it is unused.
+*/
+ .cs = 2 | (57 8),
+ .bus = 0,
+ .id = 0,
+ };
+ int ret;
+
+ /* SPI1 */
+ mx31_gpio_mux(MUX_CSPI1_SCLK__CSPI1_CLK);
+ mx31_gpio_mux(MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B);
+ mx31_gpio_mux(MUX_CSPI1_MOSI__CSPI1_MOSI);
+ mx31_gpio_mux(MUX_CSPI1_MISO__CSPI1_MISO);
+ mx31_gpio_mux(MUX_CSPI1_SS0__CSPI1_SS0_B);
+ mx31_gpio_mux(MUX_CSPI1_SS1__CSPI1_SS1_B);
+ mx31_gpio_mux(MUX_CSPI1_SS2__CSPI1_SS2_B);
+
+ /* start SPI1 clock */
+ __REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 2);
+
+ /* GPIO 57 */
+ /* sw_mux_ctl_key_col4_key_col5_key_col6_key_col7 */
+ mx31_gpio_mux(IOMUX_MODE(0x63, MUX_CTL_GPIO));
+
+ /* SPI1 CS2 is free */
+ ret = s6e63d6_init(data);
+ if (ret)
+ return ret;
+
+ /*
+* This is a magic sequence to initialise a C0240QGLA / C0283QGLC
+* OLED display connected to a S6E63D6 SPI display controller in the
+* 18 bit RGB mode
+*/
+ s6e63d6_index(data, 2);
+ s6e63d6_param(data, 0x0182);
+ s6e63d6_index(data, 3);
+ s6e63d6_param(data, 0x8130);
+ s6e63d6_index(data, 0x10);
+ s6e63d6_param(data, 0x);
+ s6e63d6_index(data, 5);
+ s6e63d6_param(data, 0x0001);
+ s6e63d6_index(data, 0x22);
+#endif
+ return 0;
+}
+#endif
+
int checkboard (void)
{
printf(Board: Phytec phyCore i.MX31\n);
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h
b/include/asm-arm/arch-mx31/mx31-regs.h
index e736052..dcc0805 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -124,7 +124,14 @@
#define MUX_CTL_CSPI2_SS0 0x85
#define MUX_CTL_CSPI2_SS1 0x86
#define MUX_CTL_CSPI2_SS2 0x87
+#define MUX_CTL_CSPI1_SS2 0x88
+#define MUX_CTL_CSPI1_SCLK 0x89
+#define MUX_CTL_CSPI1_SPI_RDY 0x8a
#define MUX_CTL_CSPI2_MOSI 0x8b
+#define MUX_CTL_CSPI1_MOSI 0x8c
+#define MUX_CTL_CSPI1_MISO 0x8d
+#define MUX_CTL_CSPI1_SS0 0x8e
+#define MUX_CTL_CSPI1_SS1 0x8f
/*
* Helper macros for the MUX_[contact name]__[pin function] macros
@@ -150,6 +157,15 @@
IOMUX_MODE(MUX_CTL_CSPI2_SPI_RDY, MUX_CTL_FUNC)
#define
Re: [U-Boot] [PATCH v3] smc911x: split out useful defines/functions into local header
On Mon, 23 Feb 2009, Mike Frysinger wrote: The smc911x driver has a lot of useful defines/functions which can be used by pieces of code (such as example eeprom programmers). Rather than forcing each place to duplicate these defines/functions, split them out of the smdc911x driver into a local header. Signed-off-by: Mike Frysinger vap...@gentoo.org CC: Sascha Hauer s.ha...@pengutronix.de CC: Guennadi Liakhovetski l...@denx.de CC: Magnus Lilja lilja.mag...@gmail.com CC: Ben Warren biggerbadder...@gmail.com Hm, sorry, have any of those other pieces of code been posted to the list? I'd like to have a look at them to see what they need all those register definitions for. --- v3 - rebased against master this applies against master and next of u-boot.git drivers/net/smc911x.c | 457 +- drivers/net/smc911x.h | 494 + 2 files changed, 496 insertions(+), 455 deletions(-) create mode 100644 drivers/net/smc911x.h Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] smc911x: split out useful defines/functions into local header
On Mon, 23 Feb 2009, Mike Frysinger wrote: On Monday 23 February 2009 10:44:04 Guennadi Liakhovetski wrote: On Mon, 23 Feb 2009, Mike Frysinger wrote: The smc911x driver has a lot of useful defines/functions which can be used by pieces of code (such as example eeprom programmers). Rather than forcing each place to duplicate these defines/functions, split them out of the smdc911x driver into a local header. Signed-off-by: Mike Frysinger vap...@gentoo.org CC: Sascha Hauer s.ha...@pengutronix.de CC: Guennadi Liakhovetski l...@denx.de CC: Magnus Lilja lilja.mag...@gmail.com CC: Ben Warren biggerbadder...@gmail.com Hm, sorry, have any of those other pieces of code been posted to the list? I'd like to have a look at them to see what they need all those register definitions for. it's already been posted in this thread (and Ben has merged it). but to answer your question, external code doesnt generally need most of those register definitions. they're moved because they belong in a header file and because it doesnt make sense to move just a few. Ok, you mean these patches [PATCH] smc911x_eeprom: new example app for managing newer SMC parts Yep, agree, as long as some register definitions are used, it is better to move all to a header. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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] where is i.MX31 branch?
Hi Dennis, On Sat, 14 Feb 2009, Dennis.Yxun wrote: Dear Guennadi: I see you constantly post patches related to i.MX31 branch :_), great job but i find the i.MX31 branch in the main repository is quite old. Last commit was Apr 3 2008. (git://www.denx.de/git/u-boot.git branch i.MX31) That branch is not active any more. Just wonder is there any local tree where I track before it's merged into the main repository. Not really. i.MX31 Patches appear on the mailing list, then get merged in a custodian tree, usually ARM, and then in the mainline. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH v2] i.MX31: Start the I2C clock on driver initialisation
i.MX31 powers on with most clocks running, so, after a power on this explicit clock start up is not required. However, as Linux boots it disables most clocks to save power. This includes the I2C clock. If we then soft reboot from Linux the I2C clock stays off. This breaks the phycore, which has its environment in I2C EEPROM. Fix the problem by explicitly starting the clock in I2C driver initialisation routine. Signed-off-by: Guennadi Liakhovetski l...@denx.de --- Changes since v1: Clock is initialised in the I2C driver now, not in board code. Thanks to Jean-Christophe for suggesting. drivers/i2c/mxc_i2c.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index eedad06..8e10fbb 100644 --- a/drivers/i2c/mxc_i2c.c +++ b/drivers/i2c/mxc_i2c.c @@ -49,10 +49,13 @@ #ifdef CONFIG_SYS_I2C_MX31_PORT1 #define I2C_BASE 0x43f8 +#define I2C_CLK_OFFSET 26 #elif defined (CONFIG_SYS_I2C_MX31_PORT2) #define I2C_BASE 0x43f98000 +#define I2C_CLK_OFFSET 28 #elif defined (CONFIG_SYS_I2C_MX31_PORT3) #define I2C_BASE 0x43f84000 +#define I2C_CLK_OFFSET 30 #else #error define CONFIG_SYS_I2C_MX31_PORTx to use the mx31 I2C driver #endif @@ -72,6 +75,9 @@ void i2c_init(int speed, int unused) int freq = mx31_get_ipg_clk(); int i; + /* start the required I2C clock */ + __REG(CCM_CGR0) = __REG(CCM_CGR0) | (3 I2C_CLK_OFFSET); + for (i = 0; i 0x1f; i++) if (freq / div[i] = speed) break; -- 1.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9 v4] i.MX31: support GPIO as a chip-select in the mxc_spi driver
Some SPI devices have special requirements on chip-select handling.
With this patch we can use a GPIO as a chip-select and strictly follow
the SPI_XFER_BEGIN and SPI_XFER_END flags.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: long lines split, mx31_gpio_* calls now also defined if
CONFIG_MX31_GPIO is not defined (see patch 2/9), '!!' removed.
Changes since v2: added braces in a multiline if, switched to
ARRAY_SIZE().
Changes since v3: moved GPIO chipselect initialisation into a separate
function, as suggested by Wolfgang Denk
drivers/spi/mxc_spi.c | 64 ++--
1 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 3135817..daad1bb 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -21,6 +21,7 @@
#include common.h
#include malloc.h
#include spi.h
+#include asm/errno.h
#include asm/io.h
#ifdef CONFIG_MX27
@@ -32,6 +33,8 @@
#else
+#include asm/arch/mx31.h
+
#define MXC_CSPIRXDATA 0x00
#define MXC_CSPITXDATA 0x04
#define MXC_CSPICTRL 0x08
@@ -68,6 +71,7 @@ struct mxc_spi_slave {
struct spi_slave slave;
unsigned long base;
u32 ctrl_reg;
+ int gpio;
};
static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -85,7 +89,8 @@ static inline void reg_write(unsigned long addr, u32 val)
*(volatile unsigned long*)addr = val;
}
-static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen)
+static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen,
+ unsigned long flags)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
unsigned int cfg_reg = reg_read(mxcs-base + MXC_CSPICTRL);
@@ -96,6 +101,9 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
if (cfg_reg != mxcs-ctrl_reg)
reg_write(mxcs-base + MXC_CSPICTRL, mxcs-ctrl_reg);
+ if (mxcs-gpio 0 (flags SPI_XFER_BEGIN))
+ mx31_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
+
reg_write(mxcs-base + MXC_CSPITXDATA, data);
reg_write(mxcs-base + MXC_CSPICTRL, mxcs-ctrl_reg | MXC_CSPICTRL_XCH);
@@ -103,6 +111,11 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
while (reg_read(mxcs-base + MXC_CSPICTRL) MXC_CSPICTRL_XCH)
;
+ if (mxcs-gpio 0 (flags SPI_XFER_END)) {
+ mx31_gpio_set(mxcs-gpio,
+ !(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL));
+ }
+
return reg_read(mxcs-base + MXC_CSPIRXDATA);
}
@@ -121,7 +134,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
i n_blks;
i++, in_l++, out_l++, bitlen -= 32) {
- u32 data = spi_xchg_single(slave, *out_l, bitlen);
+ u32 data = spi_xchg_single(slave, *out_l, bitlen, flags);
/* Check if we're only transfering 8 or 16 bits */
if (!i) {
@@ -139,15 +152,54 @@ void spi_init(void)
{
}
+static int decode_cs(struct mxc_spi_slave *mxcs, unsigned int cs)
+{
+ int ret;
+
+ /*
+* Some SPI devices require active chip-select over multiple
+* transactions, we achieve this using a GPIO. Still, the SPI
+* controller has to be configured to use one of its own chipselects.
+* To use this feature you have to call spi_setup_slave() with
+* cs = internal_cs | (gpio 8), and you have to use some unused
+* on this SPI controller cs between 0 and 3.
+*/
+ if (cs 3) {
+ mxcs-gpio = cs 8;
+ cs = 3;
+ ret = mx31_gpio_direction(mxcs-gpio, MX31_GPIO_DIRECTION_OUT);
+ if (ret) {
+ printf(mxc_spi: cannot setup gpio %d\n, mxcs-gpio);
+ return -EINVAL;
+ }
+ } else {
+ mxcs-gpio = -1;
+ }
+
+ return cs;
+}
+
struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
unsigned int ctrl_reg;
struct mxc_spi_slave *mxcs;
+ int ret;
+
+ if (bus = ARRAY_SIZE(spi_bases))
+ return NULL;
+
+ mxcs = malloc(sizeof(struct mxc_spi_slave));
+ if (!mxcs)
+ return NULL;
- if (bus = sizeof(spi_bases) / sizeof(spi_bases[0]) ||
- cs 3)
+ ret = decode_cs(mxcs, cs);
+ if (ret 0) {
+ free(mxcs);
return NULL;
+ }
+
+ cs = ret;
ctrl_reg = MXC_CSPICTRL_CHIPSELECT(cs) |
MXC_CSPICTRL_BITCOUNT(31) |
@@ -162,10 +214,6 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs
[U-Boot] [PATCH] i.MX31: fir imx31_phycore to work after Linux reboot
Upon power on i.MX31 enables most peripheral clocks, Linux disables the ones that it's not using to save power. Until now U-Boot on imx31_phycore didn't enable the I2C clock explicitly, so, after a reboot under Linux, if Linux didn't use I2C, the clock would stay disabled. And U-Boot on imx31_phycore uses an I2C EEPROM for environment data. So, after a reboot U-Boot would be left with its default environment. This patch fixes this problem by enabling the I2C clock explicitly. Signed-off-by: Guennadi Liakhovetski l...@denx.de --- board/imx31_phycore/imx31_phycore.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/board/imx31_phycore/imx31_phycore.c b/board/imx31_phycore/imx31_phycore.c index 4c64cb9..6b78194 100644 --- a/board/imx31_phycore/imx31_phycore.c +++ b/board/imx31_phycore/imx31_phycore.c @@ -60,6 +60,9 @@ int board_init (void) mx31_gpio_mux(MUX_CSPI2_MOSI__I2C2_SCL); mx31_gpio_mux(MUX_CSPI2_MISO__I2C2_SDA); + /* start I2C2 clock */ + __REG(CCM_CGR0) = __REG(CCM_CGR0) | (3 28); + gd-bd-bi_arch_number = MACH_TYPE_PCM037; /* board id for linux */ gd-bd-bi_boot_params = (0x8100); /* adress of boot parameters */ -- 1.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9 v3] ARM: Support for splashimage om i.MX31-based phycore eet variant
Hi again, this is version 3 of the patch-series, that adds support for the graphics engine on i.MX31 SoC. Changes since v1 and v2 will be reflected in each single patch. As all correction requests have been addressed, I hope we can get it in on the last day of the merge window (today). Should any further problems surface, we can address them in incremental patches. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH 1/9 v3] i.MX31: fix SPI driver for shorter than 32 bit transfers
Fix setting the SPI Control register, 8 and 16-bit transfers and a wrong
pointer in the free routine in the mxc_spi driver.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: chose a simpler fix
Changes since v2: fix the simpler fix: v2 worked as long as I just
resetted the board, powering the board down showed, that v2 wasn't
sufficient, it has lost the SPI Control register fix from v1.
drivers/spi/mxc_spi.c | 30 +++---
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 5957ada..3135817 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -90,17 +90,15 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
unsigned int cfg_reg = reg_read(mxcs-base + MXC_CSPICTRL);
- if (MXC_CSPICTRL_BITCOUNT(bitlen - 1) != (cfg_reg
MXC_CSPICTRL_BITCOUNT(31))) {
- cfg_reg = (cfg_reg ~MXC_CSPICTRL_BITCOUNT(31)) |
- MXC_CSPICTRL_BITCOUNT(bitlen - 1);
- reg_write(mxcs-base + MXC_CSPICTRL, cfg_reg);
- }
+ mxcs-ctrl_reg = (mxcs-ctrl_reg ~MXC_CSPICTRL_BITCOUNT(31)) |
+ MXC_CSPICTRL_BITCOUNT(bitlen - 1);
- reg_write(mxcs-base + MXC_CSPITXDATA, data);
+ if (cfg_reg != mxcs-ctrl_reg)
+ reg_write(mxcs-base + MXC_CSPICTRL, mxcs-ctrl_reg);
- cfg_reg |= MXC_CSPICTRL_XCH;
+ reg_write(mxcs-base + MXC_CSPITXDATA, data);
- reg_write(mxcs-base + MXC_CSPICTRL, cfg_reg);
+ reg_write(mxcs-base + MXC_CSPICTRL, mxcs-ctrl_reg | MXC_CSPICTRL_XCH);
while (reg_read(mxcs-base + MXC_CSPICTRL) MXC_CSPICTRL_XCH)
;
@@ -122,8 +120,17 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
i n_blks;
-i++, in_l++, out_l++, bitlen -= 32)
- *in_l = spi_xchg_single(slave, *out_l, bitlen);
+i++, in_l++, out_l++, bitlen -= 32) {
+ u32 data = spi_xchg_single(slave, *out_l, bitlen);
+
+ /* Check if we're only transfering 8 or 16 bits */
+ if (!i) {
+ if (bitlen 9)
+ *(u8 *)din = data;
+ else if (bitlen 17)
+ *(u16 *)din = data;
+ }
+ }
return 0;
}
@@ -169,7 +176,8 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
void spi_free_slave(struct spi_slave *slave)
{
- free(slave);
+ struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
+ free(mxcs);
}
int spi_claim_bus(struct spi_slave *slave)
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9 v3] i.MX31: support GPIO as a chip-select in the mxc_spi driver
Some SPI devices have special requirements on chip-select handling.
With this patch we can use a GPIO as a chip-select and strictly follow
the SPI_XFER_BEGIN and SPI_XFER_END flags.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: long lines split, mx31_gpio_* calls now also defined if
CONFIG_MX31_GPIO is not defined (see patch 2/9), '!!' removed.
Changes since v2: added braces in a multiline if, switched to
ARRAY_SIZE().
drivers/spi/mxc_spi.c | 48
1 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 3135817..524b2e1 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -32,6 +32,8 @@
#else
+#include asm/arch/mx31.h
+
#define MXC_CSPIRXDATA 0x00
#define MXC_CSPITXDATA 0x04
#define MXC_CSPICTRL 0x08
@@ -68,6 +70,7 @@ struct mxc_spi_slave {
struct spi_slave slave;
unsigned long base;
u32 ctrl_reg;
+ int gpio;
};
static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -85,7 +88,8 @@ static inline void reg_write(unsigned long addr, u32 val)
*(volatile unsigned long*)addr = val;
}
-static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen)
+static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen,
+ unsigned long flags)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
unsigned int cfg_reg = reg_read(mxcs-base + MXC_CSPICTRL);
@@ -96,6 +100,9 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
if (cfg_reg != mxcs-ctrl_reg)
reg_write(mxcs-base + MXC_CSPICTRL, mxcs-ctrl_reg);
+ if (mxcs-gpio 0 (flags SPI_XFER_BEGIN))
+ mx31_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
+
reg_write(mxcs-base + MXC_CSPITXDATA, data);
reg_write(mxcs-base + MXC_CSPICTRL, mxcs-ctrl_reg | MXC_CSPICTRL_XCH);
@@ -103,6 +110,11 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
while (reg_read(mxcs-base + MXC_CSPICTRL) MXC_CSPICTRL_XCH)
;
+ if (mxcs-gpio 0 (flags SPI_XFER_END)) {
+ mx31_gpio_set(mxcs-gpio,
+ !(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL));
+ }
+
return reg_read(mxcs-base + MXC_CSPIRXDATA);
}
@@ -121,7 +133,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
i n_blks;
i++, in_l++, out_l++, bitlen -= 32) {
- u32 data = spi_xchg_single(slave, *out_l, bitlen);
+ u32 data = spi_xchg_single(slave, *out_l, bitlen, flags);
/* Check if we're only transfering 8 or 16 bits */
if (!i) {
@@ -144,11 +156,35 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
{
unsigned int ctrl_reg;
struct mxc_spi_slave *mxcs;
+ int ret;
- if (bus = sizeof(spi_bases) / sizeof(spi_bases[0]) ||
- cs 3)
+ if (bus = ARRAY_SIZE(spi_bases))
+ return NULL;
+
+ mxcs = malloc(sizeof(struct mxc_spi_slave));
+ if (!mxcs)
return NULL;
+ /*
+* Some SPI devices require active chip-select over multiple
+* transactions, we achieve this using a GPIO. Still, the SPI
+* controller has to be configured to use one of its own chipselects.
+* To use this feature you have to call spi_setup_slave() with
+* cs = internal_cs | (gpio 8), and you have to use some unused
+* on this SPI controller cs between 0 and 3.
+*/
+ if (cs 3) {
+ mxcs-gpio = cs 8;
+ cs = 3;
+ ret = mx31_gpio_direction(mxcs-gpio, MX31_GPIO_DIRECTION_OUT);
+ if (ret) {
+ printf(mxc_spi: cannot setup gpio %d\n, mxcs-gpio);
+ return NULL;
+ }
+ } else {
+ mxcs-gpio = -1;
+ }
+
ctrl_reg = MXC_CSPICTRL_CHIPSELECT(cs) |
MXC_CSPICTRL_BITCOUNT(31) |
MXC_CSPICTRL_DATARATE(7) | /* FIXME: calculate data rate */
@@ -162,10 +198,6 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (mode SPI_CS_HIGH)
ctrl_reg |= MXC_CSPICTRL_SSPOL;
- mxcs = malloc(sizeof(struct mxc_spi_slave));
- if (!mxcs)
- return NULL;
-
mxcs-slave.bus = bus;
mxcs-slave.cs = cs;
mxcs-base = spi_bases[bus];
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9 v3] ARM: remove unused variable
The size variable in start_armboot() in lib_arm/board.c is only really
used in #ifndef CONFIG_SYS_NO_FLASH case, and even there it can be
eliminated (thanks to Jean-Christophe PLAGNIOL-VILLARD for a suggestion.)
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: removed the size variable completely.
Changes since v2: none.
lib_arm/board.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 964f5cc..41f7603 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -287,9 +287,6 @@ void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
-#if !defined(CONFIG_SYS_NO_FLASH) || defined (CONFIG_VFD) ||
defined(CONFIG_LCD)
- ulong size;
-#endif
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
unsigned long addr;
#endif
@@ -315,8 +312,7 @@ void start_armboot (void)
#ifndef CONFIG_SYS_NO_FLASH
/* configure available FLASH banks */
- size = flash_init ();
- display_flash_config (size);
+ display_flash_config (flash_init ());
#endif /* CONFIG_SYS_NO_FLASH */
#ifdef CONFIG_VFD
@@ -328,7 +324,7 @@ void start_armboot (void)
*/
/* bss_end is defined in the board-specific linker script */
addr = (_bss_end + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1);
- size = vfd_setmem (addr);
+ vfd_setmem (addr);
gd-fb_base = addr;
#endif /* CONFIG_VFD */
@@ -343,7 +339,7 @@ void start_armboot (void)
*/
/* bss_end is defined in the board-specific linker script */
addr = (_bss_end + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1);
- size = lcd_setmem (addr);
+ lcd_setmem (addr);
gd-fb_base = addr;
}
#endif /* CONFIG_LCD */
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9 v3] video: add an i.MX31 framebuffer driver
Add a driver for the Synchronous Display Controller and the Display
Interface on i.MX31, using IPU for DMA channel setup. So far only
displaying of bitmaps is supported, no text output.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: added breaks, shorter title, splitted long lines,
unified style.
Changes since v2: fixed comment formatting, function parameters in
comments, a typo in a comment, and removed an unused parameter from
mx3fb_set_par()
drivers/video/Makefile |1 +
drivers/video/mx3fb.c | 856
2 files changed, 857 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mx3fb.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 84d4cb7..bc00852 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_CFB_CONSOLE) += cfb_console.o
COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
+COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
COBJS-$(CONFIG_SED156X) += sed156x.o
COBJS-$(CONFIG_VIDEO_SM501) += sm501.o
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
new file mode 100644
index 000..1e1d507
--- /dev/null
+++ b/drivers/video/mx3fb.c
@@ -0,0 +1,856 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@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
+ */
+#include common.h
+#include lcd.h
+#include asm/arch/mx31.h
+#include asm/arch/mx31-regs.h
+#include asm/errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void *lcd_base;/* Start of framebuffer memory */
+void *lcd_console_address; /* Start of console buffer */
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+short console_col;
+short console_row;
+
+void lcd_initcolregs(void)
+{
+}
+
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+}
+
+void lcd_disable(void)
+{
+}
+
+void lcd_panel_disable(void)
+{
+}
+
+#define msleep(a) udelay(a * 1000)
+
+#define XRES 240
+#define YRES 320
+#define PANEL_TYPE IPU_PANEL_TFT
+#define PIXEL_CLK 185925
+#define PIXEL_FMT IPU_PIX_FMT_RGB666
+#define H_START_WIDTH 9 /* left_margin */
+#define H_SYNC_WIDTH 1 /* hsync_len */
+#define H_END_WIDTH(16 + 1)/* right_margin + hsync_len */
+#define V_START_WIDTH 7 /* upper_margin */
+#define V_SYNC_WIDTH 1 /* vsync_len */
+#define V_END_WIDTH(9 + 1) /* lower_margin + vsync_len */
+#define SIG_POL(DI_D3_DRDY_SHARP_POL | DI_D3_CLK_POL)
+#define IF_CONF0
+#define IF_CLK_DIV 0x175
+
+#define LCD_COLOR_IPU LCD_COLOR16
+
+static ushort colormap[256];
+
+vidinfo_t panel_info = {
+ .vl_col = XRES,
+ .vl_row = YRES,
+ .vl_bpix= LCD_COLOR_IPU,
+ .cmap = colormap,
+};
+
+#define BIT_PER_PIXEL NBITS(LCD_COLOR_IPU)
+
+/* IPU DMA Controller channel definitions. */
+enum ipu_channel {
+ IDMAC_IC_0 = 0, /* IC (encoding task) to memory */
+ IDMAC_IC_1 = 1, /* IC (viewfinder task) to memory */
+ IDMAC_ADC_0 = 1,
+ IDMAC_IC_2 = 2,
+ IDMAC_ADC_1 = 2,
+ IDMAC_IC_3 = 3,
+ IDMAC_IC_4 = 4,
+ IDMAC_IC_5 = 5,
+ IDMAC_IC_6 = 6,
+ IDMAC_IC_7 = 7, /* IC (sensor data) to memory */
+ IDMAC_IC_8 = 8,
+ IDMAC_IC_9 = 9,
+ IDMAC_IC_10 = 10,
+ IDMAC_IC_11 = 11,
+ IDMAC_IC_12 = 12,
+ IDMAC_IC_13 = 13,
+ IDMAC_SDC_0 = 14, /* Background synchronous display data */
+ IDMAC_SDC_1 = 15, /* Foreground data (overlay) */
+ IDMAC_SDC_2 = 16,
+ IDMAC_SDC_3 = 17,
+ IDMAC_ADC_2 = 18,
+ IDMAC_ADC_3 = 19,
+ IDMAC_ADC_4 = 20,
+ IDMAC_ADC_5 = 21,
+ IDMAC_ADC_6 = 22,
+ IDMAC_ADC_7 = 23,
+ IDMAC_PF_0 = 24,
+ IDMAC_PF_1 = 25,
+ IDMAC_PF_2 = 26,
+ IDMAC_PF_3 = 27,
+ IDMAC_PF_4 = 28,
+ IDMAC_PF_5 = 29,
+ IDMAC_PF_6 = 30,
+ IDMAC_PF_7 = 31,
+};
+
+/* More
[U-Boot] [PATCH 9/9 v3] ARM: add an eet variant of the imx31_phycore board
The eet variant of the imx31_phycore board has an OLED display, using a
s6e63d6 display controller on the first SPI interface, using GPIO57 as a
chip-select for it. With this configuration you can display 256 colour BMP
images in 16-bit RGB (RGB565) LCD mode.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: adjusted to reflect changes in earlier patches: add .id
field initialisation, configuration parameter renamed to CONFIG_S6E63D6.
Changes since v2: fixed the left-over CONFIG_DISPLAY_S6E63D6 parameter.
Makefile |6 +++-
board/imx31_phycore/imx31_phycore.c | 52 +
include/asm-arm/arch-mx31/mx31-regs.h | 16 ++
include/configs/imx31_phycore.h | 23 ++
4 files changed, 96 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 787c5f2..6151e2c 100644
--- a/Makefile
+++ b/Makefile
@@ -3025,8 +3025,12 @@ apollon_config : unconfig
imx31_litekit_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 imx31_litekit NULL mx31
+imx31_phycore_eet_config \
imx31_phycore_config : unconfig
- @$(MKCONFIG) $(@:_config=) arm arm1136 imx31_phycore NULL mx31
+ @if [ -n $(findstring imx31_phycore_eet_config,$@) ]; then
\
+ echo #define CONFIG_IMX31_PHYCORE_EET
$(obj)include/config.h; \
+ fi
+ @$(MKCONFIG) -a imx31_phycore arm arm1136 imx31_phycore NULL mx31
mx31ads_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 mx31ads freescale mx31
diff --git a/board/imx31_phycore/imx31_phycore.c
b/board/imx31_phycore/imx31_phycore.c
index 6b78194..9456468 100644
--- a/board/imx31_phycore/imx31_phycore.c
+++ b/board/imx31_phycore/imx31_phycore.c
@@ -23,6 +23,7 @@
#include common.h
+#include s6e63d6.h
#include asm/arch/mx31.h
#include asm/arch/mx31-regs.h
@@ -69,6 +70,57 @@ int board_init (void)
return 0;
}
+#ifdef BOARD_LATE_INIT
+int board_late_init(void)
+{
+#ifdef CONFIG_S6E63D6
+ struct s6e63d6 data = {
+ .cs = 2 | (57 8),
+ .bus = 0,
+ .id = 0,
+ };
+ int ret;
+
+ /* SPI1 */
+ mx31_gpio_mux(MUX_CSPI1_SCLK__CSPI1_CLK);
+ mx31_gpio_mux(MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B);
+ mx31_gpio_mux(MUX_CSPI1_MOSI__CSPI1_MOSI);
+ mx31_gpio_mux(MUX_CSPI1_MISO__CSPI1_MISO);
+ mx31_gpio_mux(MUX_CSPI1_SS0__CSPI1_SS0_B);
+ mx31_gpio_mux(MUX_CSPI1_SS1__CSPI1_SS1_B);
+ mx31_gpio_mux(MUX_CSPI1_SS2__CSPI1_SS2_B);
+
+ /* start SPI1 clock */
+ __REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 2);
+
+ /* GPIO 57 */
+ /* sw_mux_ctl_key_col4_key_col5_key_col6_key_col7 */
+ mx31_gpio_mux(IOMUX_MODE(0x63, MUX_CTL_GPIO));
+
+ /* SPI1 CS2 is free */
+ ret = s6e63d6_init(data);
+ if (ret)
+ return ret;
+
+ /*
+* This is a magic sequence to initialise a C0240QGLA / C0283QGLC
+* OLED display connected to a S6E63D6 SPI display controller in the
+* 18 bit RGB mode
+*/
+ s6e63d6_index(data, 2);
+ s6e63d6_param(data, 0x0182);
+ s6e63d6_index(data, 3);
+ s6e63d6_param(data, 0x8130);
+ s6e63d6_index(data, 0x10);
+ s6e63d6_param(data, 0x);
+ s6e63d6_index(data, 5);
+ s6e63d6_param(data, 0x0001);
+ s6e63d6_index(data, 0x22);
+#endif
+ return 0;
+}
+#endif
+
int checkboard (void)
{
printf(Board: Phytec phyCore i.MX31\n);
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h
b/include/asm-arm/arch-mx31/mx31-regs.h
index e736052..dcc0805 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -124,7 +124,14 @@
#define MUX_CTL_CSPI2_SS0 0x85
#define MUX_CTL_CSPI2_SS1 0x86
#define MUX_CTL_CSPI2_SS2 0x87
+#define MUX_CTL_CSPI1_SS2 0x88
+#define MUX_CTL_CSPI1_SCLK 0x89
+#define MUX_CTL_CSPI1_SPI_RDY 0x8a
#define MUX_CTL_CSPI2_MOSI 0x8b
+#define MUX_CTL_CSPI1_MOSI 0x8c
+#define MUX_CTL_CSPI1_MISO 0x8d
+#define MUX_CTL_CSPI1_SS0 0x8e
+#define MUX_CTL_CSPI1_SS1 0x8f
/*
* Helper macros for the MUX_[contact name]__[pin function] macros
@@ -150,6 +157,15 @@
IOMUX_MODE(MUX_CTL_CSPI2_SPI_RDY, MUX_CTL_FUNC)
#define MUX_CSPI2_SCLK__CSPI2_CLK IOMUX_MODE(MUX_CTL_CSPI2_SCLK, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS0__CSPI1_SS0_B IOMUX_MODE(MUX_CTL_CSPI1_SS0, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS1__CSPI1_SS1_B IOMUX_MODE(MUX_CTL_CSPI1_SS1, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS2__CSPI1_SS2_B IOMUX_MODE(MUX_CTL_CSPI1_SS2, MUX_CTL_FUNC)
+#define MUX_CSPI1_MOSI__CSPI1_MOSI IOMUX_MODE(MUX_CTL_CSPI1_MOSI, MUX_CTL_FUNC)
+#define MUX_CSPI1_MISO__CSPI1_MISO IOMUX_MODE(MUX_CTL_CSPI1_MISO, MUX_CTL_FUNC)
+#define MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B \
+ IOMUX_MODE(MUX_CTL_CSPI1_SPI_RDY, MUX_CTL_FUNC)
+#define MUX_CSPI1_SCLK__CSPI1_CLK IOMUX_MODE
[U-Boot] [PATCH 6/9 v3] Add 16bpp BMP support
From: Mark Jackson m...@mimc.co.uk
This patch adds 16bpp BMP support to the common lcd code.
Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
At the moment it's only been tested on the MIMC200 AVR32 board, but extending
this to other platforms should be a simple task !!
Signed-off-by: Mark Jackson m...@mimc.co.uk
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: added this comment to explain, that this patch from Mark
Jackson is included in this patch series for completeness, because future
patches base on it, long lines split.
Changes since v2: none.
common/lcd.c | 51 +--
1 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 5f73247..756b30d 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -84,7 +84,7 @@ extern void lcd_enable (void);
static void *lcd_logo (void);
-#if LCD_BPP == LCD_COLOR8
+#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
extern void lcd_setcolreg (ushort regno,
ushort red, ushort green, ushort blue);
#endif
@@ -656,7 +656,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bpix = NBITS(panel_info.vl_bpix);
- if ((bpix != 1) (bpix != 8)) {
+ if ((bpix != 1) (bpix != 8) (bpix != 16)) {
printf (Error: %d bit/pixel mode not supported by U-Boot\n,
bpix);
return 1;
@@ -738,17 +738,48 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bmap = (uchar *)bmp + le32_to_cpu (bmp-header.data_offset);
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- for (i = 0; i height; ++i) {
- WATCHDOG_RESET();
- for (j = 0; j width ; j++)
+
+ switch (bpix) {
+ case 1: /* pass through */
+ case 8:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width ; j++)
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++)=255-*(bmap++);
#endif
- bmap += (width - padded_line);
- fb -= (width + lcd_line_length);
- }
+ bmap += (width - padded_line);
+ fb -= (width + lcd_line_length);
+ }
+ break;
+
+#if defined(CONFIG_BMP_16BPP)
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_ATMEL_LCD_BGR555)
+ *(fb++) = ((bmap[0] 0x1f) 2) |
+ (bmap[1] 0x03);
+ *(fb++) = (bmap[0] 0xe0) |
+ ((bmap[1] 0x7c) 2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+ }
+ bmap += (padded_line - width) * 2;
+ fb -= (width * 2 + lcd_line_length);
+ }
+ break;
+#endif /* CONFIG_BMP_16BPP */
+
+ default:
+ break;
+ };
return (0);
}
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9 v3] A driver for the S6E63D6 SPI display controller from Samsung
This is a driver for the S6E63D6 SPI OLED display controller from Samsung.
It only provides access to controller's registers so the client can freely
configure it.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: parameters added in function declarations, alphabetical
order in Makefile, id made configurable by the user, renamed
configuration parameter to CONFIG_S6E63D6.
Changes since v2: added a comment, explaining the start byte format, empty
line added before the final return in a function.
drivers/video/Makefile |1 +
drivers/video/s6e63d6.c | 76 +++
include/s6e63d6.h | 37 +++
3 files changed, 114 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/s6e63d6.c
create mode 100644 include/s6e63d6.h
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 7fba29f..84d4cb7 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libvideo.a
COBJS-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o
COBJS-$(CONFIG_ATMEL_LCD) += atmel_lcdfb.o
COBJS-$(CONFIG_CFB_CONSOLE) += cfb_console.o
+COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
diff --git a/drivers/video/s6e63d6.c b/drivers/video/s6e63d6.c
new file mode 100644
index 000..d163506
--- /dev/null
+++ b/drivers/video/s6e63d6.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@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
+ */
+#include common.h
+#include spi.h
+#include s6e63d6.h
+
+/*
+ * Each transfer is performed as:
+ * 1. chip-select active
+ * 2. send 8-bit start code
+ * 3. send 16-bit data
+ * 4. chip-select inactive
+ */
+static int send_word(struct s6e63d6 *data, u8 rs, u16 word)
+{
+ /*
+* The start byte looks like (binary):
+* 01110IDRSR/W
+* RS is 0 for index or 1 for data, and R/W is 0 for write.
+*/
+ u32 buf8 = 0x70 | data-id | (rs 2);
+ u32 buf16 = cpu_to_le16(word);
+ u32 buf_in;
+ int err;
+
+ err = spi_xfer(data-slave, 8, buf8, buf_in, SPI_XFER_BEGIN);
+ if (err)
+ return err;
+
+ return spi_xfer(data-slave, 16, buf16, buf_in, SPI_XFER_END);
+}
+
+/* Index and param differ in Register Select bit */
+int s6e63d6_index(struct s6e63d6 *data, u8 idx)
+{
+ return send_word(data, 0, idx);
+}
+
+int s6e63d6_param(struct s6e63d6 *data, u16 param)
+{
+ return send_word(data, 2, param);
+}
+
+int s6e63d6_init(struct s6e63d6 *data)
+{
+ if (data-id != 0 data-id != 4) {
+ printf(s6e63d6: invalid ID %u\n, data-id);
+ return 1;
+ }
+
+ data-slave = spi_setup_slave(data-bus, data-cs, 10, SPI_MODE_3);
+ if (!data-slave)
+ return 1;
+
+ return 0;
+}
diff --git a/include/s6e63d6.h b/include/s6e63d6.h
new file mode 100644
index 000..9f17fc0
--- /dev/null
+++ b/include/s6e63d6.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@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
+ */
+#ifndef _S6E63D6_H_
+#define _S6E63D6_H_
+
+struct s6e63d6 {
+ unsigned int bus;
+ unsigned int cs;
+ unsigned int id;
+ struct spi_slave *slave;
+};
+
+extern
Re: [U-Boot] [PATCH 7/9 v3] LCD: support 8bpp BMPs on 16bpp displays
On Fri, 6 Feb 2009, Anatolij Gustschin wrote: Guennadi Liakhovetski wrote: This patch also simplifies some ifdefs in lcd.c, introduces a generic vidinfo_t, which new drivers are encouraged to use and old drivers to switch over to. Signed-off-by: Guennadi Liakhovetski l...@denx.de --- Changes since v1: no changes. common/lcd.c | 56 include/lcd.h | 21 + 2 files changed, 45 insertions(+), 32 deletions(-) Applied to u-boot-video/master. Also fixed some style issues by additionally applying a trivial patch below. Note that I consider this horrible ifdef mess in common/lcd.c as a bug (not your bug!) that should be fixed before 2009.03-rc1 or even earlier. pxa, mpc823 and atmel LCD drivers provide lcd_setcolreg() for color map setting and it could be used in lcd_display_bitmap() instead of duplicating the color map setting code for platforms in question. Other LCD drivers should provide own/controller-specific lcd_setcolreg(). That's why I introduced a generic vidinfo_t with only members in it, used by the generic code (lcd.c,...), a pointer to a colour map and a void *priv pointer for driver-specific data. It shouldn't be too difficult to migrate all in-tree users to this or a similar scheme. This alone would eliminate a few ifdefs, but maybe you have a better idea how to do this. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH 7/9 v3] LCD: support 8bpp BMPs on 16bpp displays
This patch also simplifies some ifdefs in lcd.c, introduces a generic
vidinfo_t, which new drivers are encouraged to use and old drivers to switch
over to.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: no changes.
common/lcd.c | 56
include/lcd.h | 21 +
2 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 756b30d..e4ac6c2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -622,19 +622,15 @@ void bitmap_plot (int x, int y)
*/
int lcd_display_bitmap(ulong bmp_image, int x, int y)
{
-#ifdef CONFIG_ATMEL_LCD
- uint *cmap;
-#elif !defined(CONFIG_MCC200)
- ushort *cmap;
-#endif
+ ushort *cmap = NULL, *cmap_base = NULL;
ushort i, j;
uchar *fb;
bmp_image_t *bmp=(bmp_image_t *)bmp_image;
uchar *bmap;
ushort padded_line;
- unsigned long width, height;
+ unsigned long width, height, byte_width;
unsigned long pwidth = panel_info.vl_col;
- unsigned colors,bpix;
+ unsigned colors, bpix, bmp_bpix;
unsigned long compression;
#if defined(CONFIG_PXA250)
struct pxafb_info *fbi = panel_info.pxa;
@@ -647,22 +643,24 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
(bmp-header.signature[1]=='M'))) {
printf (Error: no valid bmp image at %lx\n, bmp_image);
return 1;
-}
+ }
width = le32_to_cpu (bmp-header.width);
height = le32_to_cpu (bmp-header.height);
- colors = 1le16_to_cpu (bmp-header.bit_count);
+ bmp_bpix = le16_to_cpu(bmp-header.bit_count);
+ colors = 1 bmp_bpix;
compression = le32_to_cpu (bmp-header.compression);
bpix = NBITS(panel_info.vl_bpix);
if ((bpix != 1) (bpix != 8) (bpix != 16)) {
- printf (Error: %d bit/pixel mode not supported by U-Boot\n,
- bpix);
+ printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
+ bpix, bmp_bpix);
return 1;
}
- if (bpix != le16_to_cpu(bmp-header.bit_count)) {
+ /* We support displaying 8bpp BMPs on 16bpp LCDs */
+ if (bpix != bmp_bpix (bmp_bpix != 8 || bpix != 16)) {
printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
bpix,
le16_to_cpu(bmp-header.bit_count));
@@ -674,17 +672,17 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#if !defined(CONFIG_MCC200)
/* MCC200 LCD doesn't need CMAP, supports 1bpp bw only */
- if (bpix==8) {
+ if (bmp_bpix == 8) {
#if defined(CONFIG_PXA250)
cmap = (ushort *)fbi-palette;
#elif defined(CONFIG_MPC823)
cmap = (ushort *)(cp-lcd_cmap[255*sizeof(ushort)]);
-#elif defined(CONFIG_ATMEL_LCD)
- cmap = (uint *) (panel_info.mmio + ATMEL_LCDC_LUT(0));
-#else
-# error Don't know location of color map
+#elif !defined(CONFIG_ATMEL_LCD)
+ cmap = panel_info.cmap;
#endif
+ cmap_base = cmap;
+
/* Set color map */
for (i=0; icolors; ++i) {
bmp_color_table_entry_t cte = bmp-color_table[i];
@@ -698,10 +696,10 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#else
*cmap = colreg;
#endif
-#if defined(CONFIG_PXA250)
- cmap++;
-#elif defined(CONFIG_MPC823)
+#if defined(CONFIG_MPC823)
cmap--;
+#else
+ cmap++;
#endif
#else /* CONFIG_ATMEL_LCD */
lcd_setcolreg(i, cte.red, cte.green, cte.blue);
@@ -739,19 +737,29 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- switch (bpix) {
+ switch (bmp_bpix) {
case 1: /* pass through */
case 8:
+ if (bpix != 16)
+ byte_width = width;
+ else
+ byte_width = width * 2;
+
for (i = 0; i height; ++i) {
WATCHDOG_RESET();
for (j = 0; j width ; j++)
+ if (bpix!=16) {
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++) = 255 - *(bmap++);
#endif
+ } else {
+ *(uint16_t *)fb = cmap_base[*(bmap++)];
+ fb += sizeof(uint16_t) / sizeof(*fb);
+ }
bmap += (width
Re: [U-Boot] [PATCH 0/9 v3] ARM: Support for splashimage om i.MX31-based phycore eet variant
On Fri, 6 Feb 2009, Anatolij Gustschin wrote: Hello all, On Friday 06 February 2009 10:37:23 am Guennadi Liakhovetski wrote: Hi again, this is version 3 of the patch-series, that adds support for the graphics engine on i.MX31 SoC. Changes since v1 and v2 will be reflected in each single patch. As all correction requests have been addressed, I hope we can get it in on the last day of the merge window (today). Should any further problems surface, we can address them in incremental patches. I applied following patches [PATCH 4/9 v3] A driver for the S6E63D6 SPI display controller from Samsung [PATCH 6/9 v3] Add 16bpp BMP support [PATCH 7/9 v3] LCD: support 8bpp BMPs on 16bpp displays [PATCH 8/9 v3] video: add an i.MX31 framebuffer driver to the u-boot-video/master branch. Jean-Christophe, do you prefer to push other patches from this series (1/9, 2/9, 3/9, 5/9, 9/9) to the arm tree or should I push them to the video tree? I need an ACK from you in the latter case. As I said in one of the first versions of this series, it should better be pushed via one tree completely, because otherwise cross-dependencies will break things, or you'll have to imply a specific merge order, which isn't nice either. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] i.MX31: fix SPI driver for shorter than 32 bit transfers
On Wed, 4 Feb 2009, Mike Frysinger wrote: On Wednesday 04 February 2009 17:39:45 Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:59 Wed 04 Feb , Guennadi Liakhovetski wrote: Fix 8 and 16-bit transfers in mxc_spi driver and a wrong pointer in the free routine. Signed-off-by: Guennadi Liakhovetski l...@denx.de --- No SPI custodian, so, Jean-Christophe will have to Ack it? I'd like to have Mike and Haaward ack too i dont have any arm hardware let alone familiar with any hardware-level things like the SPI controller. so from a quick high level look ... does this controller actually support transfers that arent a multiple of 8 ? Yes, it does. if the smallest increment you can do is 8bits, then you should be rejecting anything that isnt a multiple of it rather than holding the user's hand. as for the assumption that more than 32bits means do 32bit transfers, that sounds plain wrong to me. u-boot should do exactly as instructed and nothing more/less. so if the user tries to send 40bits, that better be 40bits and not 64bits. That's what my patch would do, but it is actually unclear to me what you should do for 40 bits? Do you want to send 32 + 8 or 20 + 20 or?.. In fact, I would reject if (bitlen 32 (bitlen 31)). But, for example, mpc8xxx_spi.c also first sends data in 32-bit chunks, and then the rest. But I just noticed there is another bug in my driver, the bit-length in the control register is set wrongly if (bitlen 32). Also, the function can be simplified by putting the 32-bit loop bofore residue transfer. I'll change both in the next revision. the spi_free_slave() change looks correct ... not that it should change the generated code as spi_slave is the first member of mxc_spi_slave, so they'll be the same pointer and gcc will do the right thing. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] i.MX31: support GPIO as a chip-select in the mxc_spi driver
On Wed, 4 Feb 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:59 Wed 04 Feb , Guennadi Liakhovetski wrote:
+ /*
+* Some SPI devices require active chip-select over multiple
+* transactions, we achieve this using a GPIO. Still, the SPI
+* controller has to be configured to use one of its own chipselects.
+* To use this feature you have to call spi_setup_slave() with
+* cs = internal_cs | (gpio 8), and you have to use some unused
+* on this SPI controller cs between 0 and 3.
+*/
+ if (cs 3) {
+ mxcs-gpio = cs 8;
+ cs = 3;
+ mx31_gpio_direction(mxcs-gpio, MX31_GPIO_DIRECTION_OUT);
+ } else
+ mxcs-gpio = -1;
+
why not add a callback for the chipselect instead
as example if you have to use a gpio extender it will simplest to implent
instead of hack the SPI driver
and how shall I pass this callback to
struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] ARM: add an eet variant of the imx31_phycore board
On Wed, 4 Feb 2009, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message pine.lnx.4.64.0902042316110.6...@axis700.grange you wrote: +#ifdef BOARD_LATE_INIT CONFIG_? grep?: $ grep -r BOARD_LATE_INIT lib* lib_arm/board.c:#ifdef BOARD_LATE_INIT lib_nios2/board.c:#if defined(CONFIG_BOARD_LATE_INIT) lib_sh/board.c:#ifdef BOARD_LATE_INIT lib_sparc/board.c:#if defined(CONFIG_BOARD_LATE_INIT) Good idea to search - so you can fix the other occurances, too. This is outside of the scope of this patch series, so, I'll put it on my todo. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH 0/9 v2] ARM: Support for splashimage om i.MX31-based phycore eet variant
On Wed, 4 Feb 2009, Guennadi Liakhovetski wrote: Hi again, this is version 2 of the patch-series, that adds support for the graphics engine on i.MX31 SoC. Changes since v1 will be reflected in each single patch. And - we still have one more day in the merge window...:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [PATCH 4/9 v2] A driver for the S6E63D6 SPI display controller from Samsung
This is a driver for the S6E63D6 SPI OLED display controller from Samsung.
It only provides access to controller's registers so the client can freely
configure it.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: parameters added in function declarations, alphabetical
order in Makefile, id made configurable by the user, renamed
configuration parameter to CONFIG_S6E63D6.
drivers/video/Makefile |1 +
drivers/video/s6e63d6.c | 70 +++
include/s6e63d6.h | 37 +
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/s6e63d6.c
create mode 100644 include/s6e63d6.h
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 7fba29f..84d4cb7 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libvideo.a
COBJS-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o
COBJS-$(CONFIG_ATMEL_LCD) += atmel_lcdfb.o
COBJS-$(CONFIG_CFB_CONSOLE) += cfb_console.o
+COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
diff --git a/drivers/video/s6e63d6.c b/drivers/video/s6e63d6.c
new file mode 100644
index 000..4a59f05
--- /dev/null
+++ b/drivers/video/s6e63d6.c
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@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
+ */
+#include common.h
+#include spi.h
+#include s6e63d6.h
+
+/*
+ * Each transfer is performed as:
+ * 1. chip-select active
+ * 2. send 8-bit start code
+ * 3. send 16-bit data
+ * 4. chip-select inactive
+ */
+static int send_word(struct s6e63d6 *data, u8 rs, u16 word)
+{
+ u32 buf8 = 0x70 | data-id | (rs 2);
+ u32 buf16 = cpu_to_le16(word);
+ u32 buf_in;
+ int err;
+
+ err = spi_xfer(data-slave, 8, buf8, buf_in, SPI_XFER_BEGIN);
+ if (err)
+ return err;
+ return spi_xfer(data-slave, 16, buf16, buf_in, SPI_XFER_END);
+}
+
+/* Index and param differ in Register Select bit */
+int s6e63d6_index(struct s6e63d6 *data, u8 idx)
+{
+ return send_word(data, 0, idx);
+}
+
+int s6e63d6_param(struct s6e63d6 *data, u16 param)
+{
+ return send_word(data, 2, param);
+}
+
+int s6e63d6_init(struct s6e63d6 *data)
+{
+ if (data-id != 0 data-id != 4) {
+ printf(s6e63d6: invalid ID %u\n, data-id);
+ return 1;
+ }
+
+ data-slave = spi_setup_slave(data-bus, data-cs, 10, SPI_MODE_3);
+ if (!data-slave)
+ return 1;
+
+ return 0;
+}
diff --git a/include/s6e63d6.h b/include/s6e63d6.h
new file mode 100644
index 000..9f17fc0
--- /dev/null
+++ b/include/s6e63d6.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@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
+ */
+#ifndef _S6E63D6_H_
+#define _S6E63D6_H_
+
+struct s6e63d6 {
+ unsigned int bus;
+ unsigned int cs;
+ unsigned int id;
+ struct spi_slave *slave;
+};
+
+extern int s6e63d6_init(struct s6e63d6 *data);
+extern int s6e63d6_index(struct s6e63d6 *data, u8 idx);
+extern int s6e63d6_param(struct s6e63d6 *data, u16 param);
+
+#endif
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de
[U-Boot] [PATCH 5/9 v2] ARM: remove unused variable
The size variable in start_armboot() in lib_arm/board.c is only really
used in
#ifndef CONFIG_SYS_NO_FLASH
case, and even there it can be eliminated (thanks to Jean-Christophe
PLAGNIOL-VILLARD for a suggestion.)
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: removed the size variable completely.
lib_arm/board.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 964f5cc..41f7603 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -287,9 +287,6 @@ void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
-#if !defined(CONFIG_SYS_NO_FLASH) || defined (CONFIG_VFD) ||
defined(CONFIG_LCD)
- ulong size;
-#endif
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
unsigned long addr;
#endif
@@ -315,8 +312,7 @@ void start_armboot (void)
#ifndef CONFIG_SYS_NO_FLASH
/* configure available FLASH banks */
- size = flash_init ();
- display_flash_config (size);
+ display_flash_config (flash_init ());
#endif /* CONFIG_SYS_NO_FLASH */
#ifdef CONFIG_VFD
@@ -328,7 +324,7 @@ void start_armboot (void)
*/
/* bss_end is defined in the board-specific linker script */
addr = (_bss_end + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1);
- size = vfd_setmem (addr);
+ vfd_setmem (addr);
gd-fb_base = addr;
#endif /* CONFIG_VFD */
@@ -343,7 +339,7 @@ void start_armboot (void)
*/
/* bss_end is defined in the board-specific linker script */
addr = (_bss_end + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1);
- size = lcd_setmem (addr);
+ lcd_setmem (addr);
gd-fb_base = addr;
}
#endif /* CONFIG_LCD */
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9 v2] video: add a i.MX31 framebuffer driver
Add a driver for the Synchronous Display Controller and the Display
Interface on i.MX31, using IPU for DMA channel setup. So far only
displaying of bitmaps is supported, no text output.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: added breaks, shorter title, splitted long lines,
unified style.
From eec7cc435a822b2b29b6828e8e068dc4c4dcc122 Mon Sep 17 00:00:00 2001
From: Guennadi Liakhovetski l...@denx.de
Date: Thu, 5 Feb 2009 13:15:54 +0100
Subject: [PATCH] video: add a i.MX31 framebuffer driver
Add a driver for the Synchronous Display Controller and the Display
Interface on i.MX31, using IPU for DMA channel setup. So far only
displaying of bitmaps is supported, no text output.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
drivers/video/Makefile |1 +
drivers/video/mx3fb.c | 871
2 files changed, 872 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mx3fb.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 84d4cb7..bc00852 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_CFB_CONSOLE) += cfb_console.o
COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
+COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
COBJS-$(CONFIG_SED156X) += sed156x.o
COBJS-$(CONFIG_VIDEO_SM501) += sm501.o
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
new file mode 100644
index 000..d9b673e
--- /dev/null
+++ b/drivers/video/mx3fb.c
@@ -0,0 +1,871 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@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
+ */
+#include common.h
+#include lcd.h
+#include asm/arch/mx31.h
+#include asm/arch/mx31-regs.h
+#include asm/errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void *lcd_base;/* Start of framebuffer memory */
+void *lcd_console_address; /* Start of console buffer */
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+short console_col;
+short console_row;
+
+void lcd_initcolregs(void)
+{
+}
+
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+}
+
+void lcd_disable(void)
+{
+}
+
+void lcd_panel_disable(void)
+{
+}
+
+#define msleep(a) udelay(a * 1000)
+
+#define XRES 240
+#define YRES 320
+#define PANEL_TYPE IPU_PANEL_TFT
+#define PIXEL_CLK 185925
+#define PIXEL_FMT IPU_PIX_FMT_RGB666
+#define H_START_WIDTH 9 /* left_margin */
+#define H_SYNC_WIDTH 1 /* hsync_len */
+#define H_END_WIDTH(16 + 1)/* right_margin + hsync_len */
+#define V_START_WIDTH 7 /* upper_margin */
+#define V_SYNC_WIDTH 1 /* vsync_len */
+#define V_END_WIDTH(9 + 1) /* lower_margin + vsync_len */
+#define SIG_POL(DI_D3_DRDY_SHARP_POL | DI_D3_CLK_POL)
+#define IF_CONF0
+#define IF_CLK_DIV 0x175
+
+#define LCD_COLOR_IPU LCD_COLOR16
+
+static ushort colormap[256];
+
+vidinfo_t panel_info = {
+ .vl_col = XRES,
+ .vl_row = YRES,
+ .vl_bpix= LCD_COLOR_IPU,
+ .cmap = colormap,
+};
+
+#define BIT_PER_PIXEL NBITS(LCD_COLOR_IPU)
+
+/* IPU DMA Controller channel definitions. */
+enum ipu_channel {
+ IDMAC_IC_0 = 0, /* IC (encoding task) to memory */
+ IDMAC_IC_1 = 1, /* IC (viewfinder task) to memory */
+ IDMAC_ADC_0 = 1,
+ IDMAC_IC_2 = 2,
+ IDMAC_ADC_1 = 2,
+ IDMAC_IC_3 = 3,
+ IDMAC_IC_4 = 4,
+ IDMAC_IC_5 = 5,
+ IDMAC_IC_6 = 6,
+ IDMAC_IC_7 = 7, /* IC (sensor data) to memory */
+ IDMAC_IC_8 = 8,
+ IDMAC_IC_9 = 9,
+ IDMAC_IC_10 = 10,
+ IDMAC_IC_11 = 11,
+ IDMAC_IC_12 = 12,
+ IDMAC_IC_13 = 13,
+ IDMAC_SDC_0 = 14, /* Background synchronous display data */
+ IDMAC_SDC_1 = 15, /* Foreground data (overlay) */
+ IDMAC_SDC_2 = 16,
+ IDMAC_SDC_3 = 17,
+ IDMAC_ADC_2 = 18,
+ IDMAC_ADC_3 = 19,
+ IDMAC_ADC_4 = 20
[U-Boot] [PATCH 9/9 v2] ARM: add an eet variant of the imx31_phycore board
The eet variant of the imx31_phycore board has an OLED display, using a
s6e63d6 display controller on the first SPI interface, using GPIO57 as a
chip-select for it. With this configuration you can display 256 colour BMP
images in 16-bit RGB (RGB565) LCD mode.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: adjusted to reflect changes in earlier patches: add .id
field initialisation, configuration parameter renamed to CONFIG_S6E63D6.
Makefile |6 +++-
board/imx31_phycore/imx31_phycore.c | 52 +
include/asm-arm/arch-mx31/mx31-regs.h | 16 ++
include/configs/imx31_phycore.h | 23 ++
4 files changed, 96 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 787c5f2..6151e2c 100644
--- a/Makefile
+++ b/Makefile
@@ -3025,8 +3025,12 @@ apollon_config : unconfig
imx31_litekit_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 imx31_litekit NULL mx31
+imx31_phycore_eet_config \
imx31_phycore_config : unconfig
- @$(MKCONFIG) $(@:_config=) arm arm1136 imx31_phycore NULL mx31
+ @if [ -n $(findstring imx31_phycore_eet_config,$@) ]; then
\
+ echo #define CONFIG_IMX31_PHYCORE_EET
$(obj)include/config.h; \
+ fi
+ @$(MKCONFIG) -a imx31_phycore arm arm1136 imx31_phycore NULL mx31
mx31ads_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 mx31ads freescale mx31
diff --git a/board/imx31_phycore/imx31_phycore.c
b/board/imx31_phycore/imx31_phycore.c
index 4c64cb9..6b7cbb6 100644
--- a/board/imx31_phycore/imx31_phycore.c
+++ b/board/imx31_phycore/imx31_phycore.c
@@ -23,6 +23,7 @@
#include common.h
+#include s6e63d6.h
#include asm/arch/mx31.h
#include asm/arch/mx31-regs.h
@@ -66,6 +67,57 @@ int board_init (void)
return 0;
}
+#ifdef BOARD_LATE_INIT
+int board_late_init(void)
+{
+#ifdef CONFIG_DISPLAY_S6E63D6
+ struct s6e63d6 data = {
+ .cs = 2 | (57 8),
+ .bus = 0,
+ .id = 0,
+ };
+ int ret;
+
+ /* SPI1 */
+ mx31_gpio_mux(MUX_CSPI1_SCLK__CSPI1_CLK);
+ mx31_gpio_mux(MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B);
+ mx31_gpio_mux(MUX_CSPI1_MOSI__CSPI1_MOSI);
+ mx31_gpio_mux(MUX_CSPI1_MISO__CSPI1_MISO);
+ mx31_gpio_mux(MUX_CSPI1_SS0__CSPI1_SS0_B);
+ mx31_gpio_mux(MUX_CSPI1_SS1__CSPI1_SS1_B);
+ mx31_gpio_mux(MUX_CSPI1_SS2__CSPI1_SS2_B);
+
+ /* start SPI1 clock */
+ __REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 2);
+
+ /* GPIO 57 */
+ /* sw_mux_ctl_key_col4_key_col5_key_col6_key_col7 */
+ mx31_gpio_mux(IOMUX_MODE(0x63, MUX_CTL_GPIO));
+
+ /* SPI1 CS2 is free */
+ ret = s6e63d6_init(data);
+ if (ret)
+ return ret;
+
+ /*
+* This is a magic sequence to initialise a C0240QGLA / C0283QGLC
+* OLED display connected to a S6E63D6 SPI display controller in the
+* 18 bit RGB mode
+*/
+ s6e63d6_index(data, 2);
+ s6e63d6_param(data, 0x0182);
+ s6e63d6_index(data, 3);
+ s6e63d6_param(data, 0x8130);
+ s6e63d6_index(data, 0x10);
+ s6e63d6_param(data, 0x);
+ s6e63d6_index(data, 5);
+ s6e63d6_param(data, 0x0001);
+ s6e63d6_index(data, 0x22);
+#endif
+ return 0;
+}
+#endif
+
int checkboard (void)
{
printf(Board: Phytec phyCore i.MX31\n);
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h
b/include/asm-arm/arch-mx31/mx31-regs.h
index e736052..dcc0805 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -124,7 +124,14 @@
#define MUX_CTL_CSPI2_SS0 0x85
#define MUX_CTL_CSPI2_SS1 0x86
#define MUX_CTL_CSPI2_SS2 0x87
+#define MUX_CTL_CSPI1_SS2 0x88
+#define MUX_CTL_CSPI1_SCLK 0x89
+#define MUX_CTL_CSPI1_SPI_RDY 0x8a
#define MUX_CTL_CSPI2_MOSI 0x8b
+#define MUX_CTL_CSPI1_MOSI 0x8c
+#define MUX_CTL_CSPI1_MISO 0x8d
+#define MUX_CTL_CSPI1_SS0 0x8e
+#define MUX_CTL_CSPI1_SS1 0x8f
/*
* Helper macros for the MUX_[contact name]__[pin function] macros
@@ -150,6 +157,15 @@
IOMUX_MODE(MUX_CTL_CSPI2_SPI_RDY, MUX_CTL_FUNC)
#define MUX_CSPI2_SCLK__CSPI2_CLK IOMUX_MODE(MUX_CTL_CSPI2_SCLK, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS0__CSPI1_SS0_B IOMUX_MODE(MUX_CTL_CSPI1_SS0, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS1__CSPI1_SS1_B IOMUX_MODE(MUX_CTL_CSPI1_SS1, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS2__CSPI1_SS2_B IOMUX_MODE(MUX_CTL_CSPI1_SS2, MUX_CTL_FUNC)
+#define MUX_CSPI1_MOSI__CSPI1_MOSI IOMUX_MODE(MUX_CTL_CSPI1_MOSI, MUX_CTL_FUNC)
+#define MUX_CSPI1_MISO__CSPI1_MISO IOMUX_MODE(MUX_CTL_CSPI1_MISO, MUX_CTL_FUNC)
+#define MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B \
+ IOMUX_MODE(MUX_CTL_CSPI1_SPI_RDY, MUX_CTL_FUNC)
+#define MUX_CSPI1_SCLK__CSPI1_CLK IOMUX_MODE(MUX_CTL_CSPI1_SCLK, MUX_CTL_FUNC)
+
#define MUX_CSPI2_MOSI__I2C2_SCL
[U-Boot] [PATCH 7/9 v2] LCD: support 8bpp BMPs on 16bpp displays
This patch also simplifies some ifdefs in lcd.c, introduces a generic
vidinfo_t, which new drivers are encouraged to use and old drivers to switch
over to.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: no changes.
common/lcd.c | 56
include/lcd.h | 21 +
2 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 756b30d..e4ac6c2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -622,19 +622,15 @@ void bitmap_plot (int x, int y)
*/
int lcd_display_bitmap(ulong bmp_image, int x, int y)
{
-#ifdef CONFIG_ATMEL_LCD
- uint *cmap;
-#elif !defined(CONFIG_MCC200)
- ushort *cmap;
-#endif
+ ushort *cmap = NULL, *cmap_base = NULL;
ushort i, j;
uchar *fb;
bmp_image_t *bmp=(bmp_image_t *)bmp_image;
uchar *bmap;
ushort padded_line;
- unsigned long width, height;
+ unsigned long width, height, byte_width;
unsigned long pwidth = panel_info.vl_col;
- unsigned colors,bpix;
+ unsigned colors, bpix, bmp_bpix;
unsigned long compression;
#if defined(CONFIG_PXA250)
struct pxafb_info *fbi = panel_info.pxa;
@@ -647,22 +643,24 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
(bmp-header.signature[1]=='M'))) {
printf (Error: no valid bmp image at %lx\n, bmp_image);
return 1;
-}
+ }
width = le32_to_cpu (bmp-header.width);
height = le32_to_cpu (bmp-header.height);
- colors = 1le16_to_cpu (bmp-header.bit_count);
+ bmp_bpix = le16_to_cpu(bmp-header.bit_count);
+ colors = 1 bmp_bpix;
compression = le32_to_cpu (bmp-header.compression);
bpix = NBITS(panel_info.vl_bpix);
if ((bpix != 1) (bpix != 8) (bpix != 16)) {
- printf (Error: %d bit/pixel mode not supported by U-Boot\n,
- bpix);
+ printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
+ bpix, bmp_bpix);
return 1;
}
- if (bpix != le16_to_cpu(bmp-header.bit_count)) {
+ /* We support displaying 8bpp BMPs on 16bpp LCDs */
+ if (bpix != bmp_bpix (bmp_bpix != 8 || bpix != 16)) {
printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
bpix,
le16_to_cpu(bmp-header.bit_count));
@@ -674,17 +672,17 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#if !defined(CONFIG_MCC200)
/* MCC200 LCD doesn't need CMAP, supports 1bpp bw only */
- if (bpix==8) {
+ if (bmp_bpix == 8) {
#if defined(CONFIG_PXA250)
cmap = (ushort *)fbi-palette;
#elif defined(CONFIG_MPC823)
cmap = (ushort *)(cp-lcd_cmap[255*sizeof(ushort)]);
-#elif defined(CONFIG_ATMEL_LCD)
- cmap = (uint *) (panel_info.mmio + ATMEL_LCDC_LUT(0));
-#else
-# error Don't know location of color map
+#elif !defined(CONFIG_ATMEL_LCD)
+ cmap = panel_info.cmap;
#endif
+ cmap_base = cmap;
+
/* Set color map */
for (i=0; icolors; ++i) {
bmp_color_table_entry_t cte = bmp-color_table[i];
@@ -698,10 +696,10 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#else
*cmap = colreg;
#endif
-#if defined(CONFIG_PXA250)
- cmap++;
-#elif defined(CONFIG_MPC823)
+#if defined(CONFIG_MPC823)
cmap--;
+#else
+ cmap++;
#endif
#else /* CONFIG_ATMEL_LCD */
lcd_setcolreg(i, cte.red, cte.green, cte.blue);
@@ -739,19 +737,29 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- switch (bpix) {
+ switch (bmp_bpix) {
case 1: /* pass through */
case 8:
+ if (bpix != 16)
+ byte_width = width;
+ else
+ byte_width = width * 2;
+
for (i = 0; i height; ++i) {
WATCHDOG_RESET();
for (j = 0; j width ; j++)
+ if (bpix!=16) {
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++) = 255 - *(bmap++);
#endif
+ } else {
+ *(uint16_t *)fb = cmap_base[*(bmap++)];
+ fb += sizeof(uint16_t) / sizeof(*fb);
+ }
bmap += (width
[U-Boot] [PATCH 3/9 v2] i.MX31: support GPIO as a chip-select in the mxc_spi driver
Some SPI devices have special requirements on chip-select handling.
With this patch we can use a GPIO as a chip-select and strictly follow
the SPI_XFER_BEGIN and SPI_XFER_END flags.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Changes since v1: long lines split, mx31_gpio_* calls now also defined if
CONFIG_MX31_GPIO is not defined (see patch 2/9), '!!' removed.
drivers/spi/mxc_spi.c | 47 +++
1 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index b7bd84b..1341543 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -32,6 +32,8 @@
#else
+#include asm/arch/mx31.h
+
#define MXC_CSPIRXDATA 0x00
#define MXC_CSPITXDATA 0x04
#define MXC_CSPICTRL 0x08
@@ -68,6 +70,7 @@ struct mxc_spi_slave {
struct spi_slave slave;
unsigned long base;
u32 ctrl_reg;
+ int gpio;
};
static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -85,7 +88,8 @@ static inline void reg_write(unsigned long addr, u32 val)
*(volatile unsigned long*)addr = val;
}
-static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen)
+static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen,
+ unsigned long flags)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
unsigned int cfg_reg = reg_read(mxcs-base + MXC_CSPICTRL);
@@ -96,6 +100,9 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
reg_write(mxcs-base + MXC_CSPICTRL, cfg_reg);
}
+ if (mxcs-gpio 0 (flags SPI_XFER_BEGIN))
+ mx31_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
+
reg_write(mxcs-base + MXC_CSPITXDATA, data);
cfg_reg |= MXC_CSPICTRL_XCH;
@@ -105,6 +112,10 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32
data, int bitlen)
while (reg_read(mxcs-base + MXC_CSPICTRL) MXC_CSPICTRL_XCH)
;
+ if (mxcs-gpio 0 (flags SPI_XFER_END))
+ mx31_gpio_set(mxcs-gpio,
+ !(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL));
+
return reg_read(mxcs-base + MXC_CSPIRXDATA);
}
@@ -123,7 +134,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
i n_blks;
i++, in_l++, out_l++, bitlen -= 32) {
- u32 data = spi_xchg_single(slave, *out_l, bitlen);
+ u32 data = spi_xchg_single(slave, *out_l, bitlen, flags);
/* Check if we're only transfering 8 or 16 bits */
if (!i) {
@@ -146,11 +157,35 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
{
unsigned int ctrl_reg;
struct mxc_spi_slave *mxcs;
+ int ret;
- if (bus = sizeof(spi_bases) / sizeof(spi_bases[0]) ||
- cs 3)
+ if (bus = sizeof(spi_bases) / sizeof(spi_bases[0]))
+ return NULL;
+
+ mxcs = malloc(sizeof(struct mxc_spi_slave));
+ if (!mxcs)
return NULL;
+ /*
+* Some SPI devices require active chip-select over multiple
+* transactions, we achieve this using a GPIO. Still, the SPI
+* controller has to be configured to use one of its own chipselects.
+* To use this feature you have to call spi_setup_slave() with
+* cs = internal_cs | (gpio 8), and you have to use some unused
+* on this SPI controller cs between 0 and 3.
+*/
+ if (cs 3) {
+ mxcs-gpio = cs 8;
+ cs = 3;
+ ret = mx31_gpio_direction(mxcs-gpio, MX31_GPIO_DIRECTION_OUT);
+ if (ret) {
+ printf(mxc_spi: cannot setup gpio %d\n, mxcs-gpio);
+ return NULL;
+ }
+ } else {
+ mxcs-gpio = -1;
+ }
+
ctrl_reg = MXC_CSPICTRL_CHIPSELECT(cs) |
MXC_CSPICTRL_BITCOUNT(31) |
MXC_CSPICTRL_DATARATE(7) | /* FIXME: calculate data rate */
@@ -164,10 +199,6 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (mode SPI_CS_HIGH)
ctrl_reg |= MXC_CSPICTRL_SSPOL;
- mxcs = malloc(sizeof(struct mxc_spi_slave));
- if (!mxcs)
- return NULL;
-
mxcs-slave.bus = bus;
mxcs-slave.cs = cs;
mxcs-base = spi_bases[bus];
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] A driver for the S6E63D6 SPI display controller from Samsung
On Wed, 4 Feb 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:59 Wed 04 Feb , Guennadi Liakhovetski wrote:
+
+/*
+ * Each transfer is performed as:
+ * 1. chip-select active
+ * 2. send 8-bit start code
+ * 3. send 16-bit data
+ * 4. chip-select inactive
+ */
+static int send_word(struct spi_slave *spi, u8 rs, u16 data)
+{
+ u32 buf8 = 0x70 | ID | (rs 2);
why?
That's how the start byte looks like:
01110IDRSR/W
rs is 0 for index or 1 for data, and R/W is 0 for write.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9 v2] i.MX31: support GPIO as a chip-select in the mxc_spi driver
On Thu, 5 Feb 2009, Anatolij Gustschin wrote:
Guennadi Liakhovetski wrote:
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index b7bd84b..1341543 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
snip
@@ -105,6 +112,10 @@ static u32 spi_xchg_single(struct spi_slave *slave,
u32 data, int bitlen)
while (reg_read(mxcs-base + MXC_CSPICTRL) MXC_CSPICTRL_XCH)
;
+ if (mxcs-gpio 0 (flags SPI_XFER_END))
+ mx31_gpio_set(mxcs-gpio,
+ !(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL));
this is a multi-line if statement, I think the preferred coding style
is as follows:
if (...) {
/*
* multi-line if statement
*/
...
}
please fix, Thanks!
Sorry, cannot find this in CodingStyle. Can you point me out? What I do
find there is this example in Chapter 2:
if (condition)
printk(KERN_WARNING Warning this is a long printk with
3 parameters a: %u b: %u
c: %u \n, a, b, c);
else
next_statement;
which implicitly (it is given as an example of breaking lines, not
parenthesising) states the contrary to your proposition.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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
[U-Boot] [PATCH 5/9] ARM: remove unused variable
The size variable in start_armboot() in lib_arm/board.c is only really
used in
#if !defined(CONFIG_SYS_NO_FLASH)
case, remove where unused.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
This one actually doesn't have to be in this series, so, it can go
separately over the ARM tree.
lib_arm/board.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib_arm/board.c b/lib_arm/board.c
index 964f5cc..2257b2e 100644
--- a/lib_arm/board.c
+++ b/lib_arm/board.c
@@ -287,7 +287,7 @@ void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
-#if !defined(CONFIG_SYS_NO_FLASH) || defined (CONFIG_VFD) ||
defined(CONFIG_LCD)
+#if !defined(CONFIG_SYS_NO_FLASH)
ulong size;
#endif
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
@@ -328,7 +328,7 @@ void start_armboot (void)
*/
/* bss_end is defined in the board-specific linker script */
addr = (_bss_end + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1);
- size = vfd_setmem (addr);
+ vfd_setmem (addr);
gd-fb_base = addr;
#endif /* CONFIG_VFD */
@@ -343,7 +343,7 @@ void start_armboot (void)
*/
/* bss_end is defined in the board-specific linker script */
addr = (_bss_end + (PAGE_SIZE - 1)) ~(PAGE_SIZE - 1);
- size = lcd_setmem (addr);
+ lcd_setmem (addr);
gd-fb_base = addr;
}
#endif /* CONFIG_LCD */
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] Add 16bpp BMP support
From: Mark Jackson m...@mimc.co.uk
This patch adds 16bpp BMP support to the common lcd code.
Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
At the moment it's only been tested on the MIMC200 AVR32 board, but extending
this to other platforms should be a simple task !!
Signed-off-by: Mark Jackson m...@mimc.co.uk
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
common/lcd.c | 49 +++--
1 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 5f73247..14a0d01 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -84,7 +84,7 @@ extern void lcd_enable (void);
static void *lcd_logo (void);
-#if LCD_BPP == LCD_COLOR8
+#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
extern void lcd_setcolreg (ushort regno,
ushort red, ushort green, ushort blue);
#endif
@@ -656,7 +656,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bpix = NBITS(panel_info.vl_bpix);
- if ((bpix != 1) (bpix != 8)) {
+ if ((bpix != 1) (bpix != 8) (bpix != 16)) {
printf (Error: %d bit/pixel mode not supported by U-Boot\n,
bpix);
return 1;
@@ -738,17 +738,46 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bmap = (uchar *)bmp + le32_to_cpu (bmp-header.data_offset);
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- for (i = 0; i height; ++i) {
- WATCHDOG_RESET();
- for (j = 0; j width ; j++)
+
+ switch (bpix) {
+ case 1: /* pass through */
+ case 8:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width ; j++)
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++)=255-*(bmap++);
#endif
- bmap += (width - padded_line);
- fb -= (width + lcd_line_length);
- }
+ bmap += (width - padded_line);
+ fb -= (width + lcd_line_length);
+ }
+ break;
+
+#if defined(CONFIG_BMP_16BPP)
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_ATMEL_LCD_BGR555)
+ *(fb++) = ((bmap[0] 0x1f) 2) | (bmap[1]
0x03);
+ *(fb++) = (bmap[0] 0xe0) | ((bmap[1] 0x7c)
2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+ }
+ bmap += (padded_line - width) * 2;
+ fb -= (width * 2 + lcd_line_length);
+ }
+ break;
+#endif /* CONFIG_BMP_16BPP */
+
+ default:
+ break;
+ };
return (0);
}
--
1.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] LCD: support 8bpp BMPs on 16bpp displays
This patch also simplifies some ifdefs in lcd.c, introduces a generic
vidinfo_t, which new drivers are encouraged to use and old drivers to switch
over to.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
common/lcd.c | 56
include/lcd.h | 21 +
2 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 14a0d01..ef0d488 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -622,19 +622,15 @@ void bitmap_plot (int x, int y)
*/
int lcd_display_bitmap(ulong bmp_image, int x, int y)
{
-#ifdef CONFIG_ATMEL_LCD
- uint *cmap;
-#elif !defined(CONFIG_MCC200)
- ushort *cmap;
-#endif
+ ushort *cmap = NULL, *cmap_base = NULL;
ushort i, j;
uchar *fb;
bmp_image_t *bmp=(bmp_image_t *)bmp_image;
uchar *bmap;
ushort padded_line;
- unsigned long width, height;
+ unsigned long width, height, byte_width;
unsigned long pwidth = panel_info.vl_col;
- unsigned colors,bpix;
+ unsigned colors, bpix, bmp_bpix;
unsigned long compression;
#if defined(CONFIG_PXA250)
struct pxafb_info *fbi = panel_info.pxa;
@@ -647,22 +643,24 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
(bmp-header.signature[1]=='M'))) {
printf (Error: no valid bmp image at %lx\n, bmp_image);
return 1;
-}
+ }
width = le32_to_cpu (bmp-header.width);
height = le32_to_cpu (bmp-header.height);
- colors = 1le16_to_cpu (bmp-header.bit_count);
+ bmp_bpix = le16_to_cpu(bmp-header.bit_count);
+ colors = 1 bmp_bpix;
compression = le32_to_cpu (bmp-header.compression);
bpix = NBITS(panel_info.vl_bpix);
if ((bpix != 1) (bpix != 8) (bpix != 16)) {
- printf (Error: %d bit/pixel mode not supported by U-Boot\n,
- bpix);
+ printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
+ bpix, bmp_bpix);
return 1;
}
- if (bpix != le16_to_cpu(bmp-header.bit_count)) {
+ /* We support displaying 8bpp BMPs on 16bpp LCDs */
+ if (bpix != bmp_bpix (bmp_bpix != 8 || bpix != 16)) {
printf (Error: %d bit/pixel mode, but BMP has %d bit/pixel\n,
bpix,
le16_to_cpu(bmp-header.bit_count));
@@ -674,17 +672,17 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#if !defined(CONFIG_MCC200)
/* MCC200 LCD doesn't need CMAP, supports 1bpp bw only */
- if (bpix==8) {
+ if (bmp_bpix == 8) {
#if defined(CONFIG_PXA250)
cmap = (ushort *)fbi-palette;
#elif defined(CONFIG_MPC823)
cmap = (ushort *)(cp-lcd_cmap[255*sizeof(ushort)]);
-#elif defined(CONFIG_ATMEL_LCD)
- cmap = (uint *) (panel_info.mmio + ATMEL_LCDC_LUT(0));
-#else
-# error Don't know location of color map
+#elif !defined(CONFIG_ATMEL_LCD)
+ cmap = panel_info.cmap;
#endif
+ cmap_base = cmap;
+
/* Set color map */
for (i=0; icolors; ++i) {
bmp_color_table_entry_t cte = bmp-color_table[i];
@@ -698,10 +696,10 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#else
*cmap = colreg;
#endif
-#if defined(CONFIG_PXA250)
- cmap++;
-#elif defined(CONFIG_MPC823)
+#if defined(CONFIG_MPC823)
cmap--;
+#else
+ cmap++;
#endif
#else /* CONFIG_ATMEL_LCD */
lcd_setcolreg(i, cte.red, cte.green, cte.blue);
@@ -739,19 +737,29 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- switch (bpix) {
+ switch (bmp_bpix) {
case 1: /* pass through */
case 8:
+ if (bpix != 16)
+ byte_width = width;
+ else
+ byte_width = width * 2;
+
for (i = 0; i height; ++i) {
WATCHDOG_RESET();
for (j = 0; j width ; j++)
+ if (bpix!=16) {
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++) = 255 - *(bmap++);
#endif
+ } else {
+ *(uint16_t *)fb = cmap_base[*(bmap++)];
+ fb += sizeof(uint16_t) / sizeof(*fb);
+ }
bmap += (width - padded_line
[U-Boot] [PATCH 8/9] video: add a i.MX31 framebuffer driver only for bitmaps so far
Add a driver for the Synchronous Display Controller and the Display
Interface on i.MX31, using IPU for DMA channel setup. So far only
displaying of bitmaps is supported, no text output.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
drivers/video/Makefile |1 +
drivers/video/mx3fb.c | 865
2 files changed, 866 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mx3fb.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index a7dc74c..2d3711e 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -35,6 +35,7 @@ COBJS-$(CONFIG_SED156X) += sed156x.o
COBJS-$(CONFIG_VIDEO_SM501) += sm501.o
COBJS-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o
COBJS-$(CONFIG_DISPLAY_S6E63D6) += s6e63d6.o
+COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o
COBJS-y += videomodes.o
COBJS := $(COBJS-y)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
new file mode 100644
index 000..df5193f
--- /dev/null
+++ b/drivers/video/mx3fb.c
@@ -0,0 +1,865 @@
+/*
+ * Copyright (C) 2009
+ * Guennadi Liakhovetski, DEXN Software Engineering, l...@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
+ */
+#include common.h
+#include lcd.h
+#include asm/arch/mx31.h
+#include asm/arch/mx31-regs.h
+#include asm/errno.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void *lcd_base;/* Start of framebuffer memory */
+void *lcd_console_address; /* Start of console buffer */
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+short console_col;
+short console_row;
+
+void lcd_initcolregs(void)
+{
+}
+
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+}
+
+void lcd_disable(void)
+{
+}
+
+void lcd_panel_disable(void)
+{
+}
+
+#define msleep(a) udelay(a * 1000)
+
+#define XRES 240
+#define YRES 320
+#define PANEL_TYPE IPU_PANEL_TFT
+#define PIXEL_CLK 185925
+#define PIXEL_FMT IPU_PIX_FMT_RGB666
+#define H_START_WIDTH 9 /* left_margin */
+#define H_SYNC_WIDTH 1 /* hsync_len */
+#define H_END_WIDTH(16 + 1)/* right_margin + hsync_len */
+#define V_START_WIDTH 7 /* upper_margin */
+#define V_SYNC_WIDTH 1 /* vsync_len */
+#define V_END_WIDTH(9 + 1) /* lower_margin + vsync_len */
+#define SIG_POL(DI_D3_DRDY_SHARP_POL | DI_D3_CLK_POL)
+#define IF_CONF0
+#define IF_CLK_DIV 0x175
+
+#define LCD_COLOR_IPU LCD_COLOR16
+
+static ushort colormap[256];
+
+vidinfo_t panel_info = {
+ .vl_col = XRES,
+ .vl_row = YRES,
+ .vl_bpix= LCD_COLOR_IPU,
+ .cmap = colormap,
+};
+
+#define BIT_PER_PIXEL NBITS(LCD_COLOR_IPU)
+
+/* IPU DMA Controller channel definitions. */
+enum ipu_channel {
+ IDMAC_IC_0 = 0, /* IC (encoding task) to memory */
+ IDMAC_IC_1 = 1, /* IC (viewfinder task) to memory */
+ IDMAC_ADC_0 = 1,
+ IDMAC_IC_2 = 2,
+ IDMAC_ADC_1 = 2,
+ IDMAC_IC_3 = 3,
+ IDMAC_IC_4 = 4,
+ IDMAC_IC_5 = 5,
+ IDMAC_IC_6 = 6,
+ IDMAC_IC_7 = 7, /* IC (sensor data) to memory */
+ IDMAC_IC_8 = 8,
+ IDMAC_IC_9 = 9,
+ IDMAC_IC_10 = 10,
+ IDMAC_IC_11 = 11,
+ IDMAC_IC_12 = 12,
+ IDMAC_IC_13 = 13,
+ IDMAC_SDC_0 = 14, /* Background synchronous display data */
+ IDMAC_SDC_1 = 15, /* Foreground data (overlay) */
+ IDMAC_SDC_2 = 16,
+ IDMAC_SDC_3 = 17,
+ IDMAC_ADC_2 = 18,
+ IDMAC_ADC_3 = 19,
+ IDMAC_ADC_4 = 20,
+ IDMAC_ADC_5 = 21,
+ IDMAC_ADC_6 = 22,
+ IDMAC_ADC_7 = 23,
+ IDMAC_PF_0 = 24,
+ IDMAC_PF_1 = 25,
+ IDMAC_PF_2 = 26,
+ IDMAC_PF_3 = 27,
+ IDMAC_PF_4 = 28,
+ IDMAC_PF_5 = 29,
+ IDMAC_PF_6 = 30,
+ IDMAC_PF_7 = 31,
+};
+
+/* More formats can be copied from the Linux driver if needed */
+enum pixel_fmt {
+ /* 2 bytes */
+ IPU_PIX_FMT_RGB565,
+ IPU_PIX_FMT_RGB666,
+ IPU_PIX_FMT_BGR666,
+ /* 3 bytes */
+ IPU_PIX_FMT_RGB24,
+};
+
+struct pixel_fmt_cfg {
+ u32 b0;
+ u32 b1;
+ u32
[U-Boot] [PATCH 9/9] ARM: add an eet variant of the imx31_phycore board
The eet variant of the imx31_phycore board has an OLED display, using a
s6e63d6 display controller on the first SPI interface, using GPIO57 as a
chip-select for it. With this configuration you can display 256 colour BMP
images in 16-bit RGB (RGB565) LCD mode.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
Jean-Christophe: another ack, please.
Makefile |6 +++-
board/imx31_phycore/imx31_phycore.c | 51 +
include/asm-arm/arch-mx31/mx31-regs.h | 16 ++
include/configs/imx31_phycore.h | 23 +++
4 files changed, 95 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 787c5f2..6151e2c 100644
--- a/Makefile
+++ b/Makefile
@@ -3025,8 +3025,12 @@ apollon_config : unconfig
imx31_litekit_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 imx31_litekit NULL mx31
+imx31_phycore_eet_config \
imx31_phycore_config : unconfig
- @$(MKCONFIG) $(@:_config=) arm arm1136 imx31_phycore NULL mx31
+ @if [ -n $(findstring imx31_phycore_eet_config,$@) ]; then
\
+ echo #define CONFIG_IMX31_PHYCORE_EET
$(obj)include/config.h; \
+ fi
+ @$(MKCONFIG) -a imx31_phycore arm arm1136 imx31_phycore NULL mx31
mx31ads_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm1136 mx31ads freescale mx31
diff --git a/board/imx31_phycore/imx31_phycore.c
b/board/imx31_phycore/imx31_phycore.c
index 4c64cb9..c70353d 100644
--- a/board/imx31_phycore/imx31_phycore.c
+++ b/board/imx31_phycore/imx31_phycore.c
@@ -23,6 +23,7 @@
#include common.h
+#include s6e63d6.h
#include asm/arch/mx31.h
#include asm/arch/mx31-regs.h
@@ -66,6 +67,56 @@ int board_init (void)
return 0;
}
+#ifdef BOARD_LATE_INIT
+int board_late_init(void)
+{
+#ifdef CONFIG_DISPLAY_S6E63D6
+ struct s6e63d6 data = {
+ .cs = 2 | (57 8),
+ .bus = 0,
+ };
+ int ret;
+
+ /* SPI1 */
+ mx31_gpio_mux(MUX_CSPI1_SCLK__CSPI1_CLK);
+ mx31_gpio_mux(MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B);
+ mx31_gpio_mux(MUX_CSPI1_MOSI__CSPI1_MOSI);
+ mx31_gpio_mux(MUX_CSPI1_MISO__CSPI1_MISO);
+ mx31_gpio_mux(MUX_CSPI1_SS0__CSPI1_SS0_B);
+ mx31_gpio_mux(MUX_CSPI1_SS1__CSPI1_SS1_B);
+ mx31_gpio_mux(MUX_CSPI1_SS2__CSPI1_SS2_B);
+
+ /* start SPI1 clock */
+ __REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 2);
+
+ /* GPIO 57 */
+ /* sw_mux_ctl_key_col4_key_col5_key_col6_key_col7 */
+ mx31_gpio_mux(IOMUX_MODE(0x63, MUX_CTL_GPIO));
+
+ /* SPI1 CS2 is free */
+ ret = s6e63d6_init(data);
+ if (ret)
+ return ret;
+
+ /*
+* This is a magic sequence to initialise a C0240QGLA / C0283QGLC
+* OLED display connected to a S6E63D6 SPI display controller in the
+* 18 bit RGB mode
+*/
+ s6e63d6_index(data, 2);
+ s6e63d6_param(data, 0x0182);
+ s6e63d6_index(data, 3);
+ s6e63d6_param(data, 0x8130);
+ s6e63d6_index(data, 0x10);
+ s6e63d6_param(data, 0x);
+ s6e63d6_index(data, 5);
+ s6e63d6_param(data, 0x0001);
+ s6e63d6_index(data, 0x22);
+#endif
+ return 0;
+}
+#endif
+
int checkboard (void)
{
printf(Board: Phytec phyCore i.MX31\n);
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h
b/include/asm-arm/arch-mx31/mx31-regs.h
index e736052..dcc0805 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -124,7 +124,14 @@
#define MUX_CTL_CSPI2_SS0 0x85
#define MUX_CTL_CSPI2_SS1 0x86
#define MUX_CTL_CSPI2_SS2 0x87
+#define MUX_CTL_CSPI1_SS2 0x88
+#define MUX_CTL_CSPI1_SCLK 0x89
+#define MUX_CTL_CSPI1_SPI_RDY 0x8a
#define MUX_CTL_CSPI2_MOSI 0x8b
+#define MUX_CTL_CSPI1_MOSI 0x8c
+#define MUX_CTL_CSPI1_MISO 0x8d
+#define MUX_CTL_CSPI1_SS0 0x8e
+#define MUX_CTL_CSPI1_SS1 0x8f
/*
* Helper macros for the MUX_[contact name]__[pin function] macros
@@ -150,6 +157,15 @@
IOMUX_MODE(MUX_CTL_CSPI2_SPI_RDY, MUX_CTL_FUNC)
#define MUX_CSPI2_SCLK__CSPI2_CLK IOMUX_MODE(MUX_CTL_CSPI2_SCLK, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS0__CSPI1_SS0_B IOMUX_MODE(MUX_CTL_CSPI1_SS0, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS1__CSPI1_SS1_B IOMUX_MODE(MUX_CTL_CSPI1_SS1, MUX_CTL_FUNC)
+#define MUX_CSPI1_SS2__CSPI1_SS2_B IOMUX_MODE(MUX_CTL_CSPI1_SS2, MUX_CTL_FUNC)
+#define MUX_CSPI1_MOSI__CSPI1_MOSI IOMUX_MODE(MUX_CTL_CSPI1_MOSI, MUX_CTL_FUNC)
+#define MUX_CSPI1_MISO__CSPI1_MISO IOMUX_MODE(MUX_CTL_CSPI1_MISO, MUX_CTL_FUNC)
+#define MUX_CSPI1_SPI_RDY__CSPI1_DATAREADY_B \
+ IOMUX_MODE(MUX_CTL_CSPI1_SPI_RDY, MUX_CTL_FUNC)
+#define MUX_CSPI1_SCLK__CSPI1_CLK IOMUX_MODE(MUX_CTL_CSPI1_SCLK, MUX_CTL_FUNC)
+
#define MUX_CSPI2_MOSI__I2C2_SCL IOMUX_MODE(MUX_CTL_CSPI2_MOSI, MUX_CTL_ALT1)
#define MUX_CSPI2_MISO__I2C2_SDA IOMUX_MODE(MUX_CTL_CSPI2_MISO, MUX_CTL_ALT1)
diff --git
Re: [U-Boot] [PATCH 3/9] i.MX31: support GPIO as a chip-select in the mxc_spi driver
On Wed, 4 Feb 2009, Anatolij Gustschin wrote: Hello Guennadi, diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 9267341..eacd36c 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c snip @@ -91,6 +94,9 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32 data, struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave); unsigned int cfg_reg = reg_read(mxcs-base + MXC_CSPICTRL); + if (mxcs-gpio 0 (flags SPI_XFER_BEGIN)) + mx31_gpio_set(mxcs-gpio, !!(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL)); above line to long ( 80 chars). Also you add mx31_gpio_* calls from the new mx31 GPIO driver to this driver unconditionally. I think, this will break linking for imx31_litekit and mx31ads boards as these boards include the mxc_spi driver but do not define CONFIG_MX31_GPIO. How can we separate this? Or am I missing something? @@ -100,6 +106,9 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32 data, while (reg_read(mxcs-base + MXC_CSPICTRL) MXC_CSPICTRL_XCH) ; + if (mxcs-gpio 0 (flags SPI_XFER_END)) + mx31_gpio_set(mxcs-gpio, !(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL)); above line to long ( 80 chars). Right, will fix all above. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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] [ARM] Environment variables not available during console initialisation?
(). But documenting is always good, sure:-) What has the location in RAM to do with the image structure on NAND? We don't need to allocate any space for BSS on the NAND device, right? 1. nand_spl copies u-boot proper at a location in RAM 2. nand_spl copies environment at another location in RAM 3. nand_spl jumps to u-boot proper 4. u-boot nullifies bss 5. u-boot looks for environment - either embedded, or default, or copied by nand_spl in 2. Agreed. I don't see any mention of BSS in your description, though - as expected. in 4. - as a reason why you have to skip it. ideally you would tell nand_spl to put environment directly after bss, but I haven't find a way (without adding some ugly scripts) to do this. No, that is definitely not ideally, that's most likely buggy, as it messes with the memory map we're using so far. Notice, 1) I am not an expert in U-Boot environment operation, so, there well might be issues I'm overseeing, 2) redundant environment is not handled yet, 3) would be nice to hear comments from nand(_spl) maintainers. I don't see what nand(_spl) maintainers should comment here - their code is so far completley unaffected. We just agreed on needing another call to the load routine. We still have the other possibility - properly initialise NAND before calling env_init() and then read out env? This would be a preferred solution IMHO, because it leverages restrictions like only the boot NAND, simplifies the choice of a location in RAM, leaves nand_spl code intact, thus avoiding even minimal size increment. NAND maintainer's opinion as to how feasible / difficult this would be would be appreciated. Or even better - a patch:-) I think, we could even move mem_malloc_init() before the initcall loop and use a malloc()ed buffer just as env_relocate() would do. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] arm: fix some arch_number definition
Sorry for a late reply, but it seems not to be upstream yet, so On Thu, 22 Jan 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: On 07:51 Thu 22 Jan , Jens Gehrlein wrote: Jean-Christophe PLAGNIOL-VILLARD schrieb: diff --git a/board/imx31_phycore/imx31_phycore.c b/board/imx31_phycore/imx31_phycore.c index ae93444..4b72d57 100644 --- a/board/imx31_phycore/imx31_phycore.c +++ b/board/imx31_phycore/imx31_phycore.c @@ -60,7 +60,7 @@ int board_init (void) mx31_gpio_mux(MUX_CSPI2_MOSI__I2C2_SCL); mx31_gpio_mux(MUX_CSPI2_MISO__I2C2_SDA); - gd-bd-bi_arch_number = 447; /* board id for linux */ + gd-bd-bi_arch_number = MACH_TYPE_MX31ADS; /* board id for linux */ Why ADS board ID for the Phycore? the 447 is the MX31ADS There is a number already, could you please use MACH_TYPE_PCM037 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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] [ARM] Environment variables not available during console initialisation?
Hi,
below is a patch / rfc that allows me to read the envorinment from NAND
early enough to be used in the console initialisation. It turns out this
is not only an ARM problem, rather it is common to all platforms storing
environment in NAND. Similarly, probably, env in SPI flash would have this
problem on all platforms too. The patch is not meant for mainline in its
present form because it only solves the problem for platforms, that not
only have their env in NAND, but also boot from NAND (using nand_spl).
OTOH, who would want to store environment in NAND if they didn't have to
boot from it? Anyway, it lacks generality. Also, it contains a couple of
clean ups, that actually would have to be submitted separately (removal
of unused total variable, and a typo fix in a comment).
So, this is mostly as an inspiration for someone to develop a proper
patch, or, if we do decide, that this approach is good enough, I'll split
it up and submit properly.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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
diff --git a/common/env_nand.c b/common/env_nand.c
index a8f0de7..1261dd2 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -71,9 +71,11 @@ extern int default_environment_size;
char * env_name_spec = NAND;
-#ifdef ENV_IS_EMBEDDED
+#if defined(ENV_IS_EMBEDDED)
extern uchar environment[];
env_t *env_ptr = (env_t *)(environment[0]);
+#elif defined(CFG_ENV_IS_APPENDED)
+env_t *env_ptr = (env_t *)CFG_NAND_ENV_DST;
#else /* ! ENV_IS_EMBEDDED */
env_t *env_ptr = 0;
#endif /* ENV_IS_EMBEDDED */
@@ -105,23 +107,28 @@ uchar env_get_char_spec (int index)
*/
int env_init(void)
{
-#if defined(ENV_IS_EMBEDDED)
- size_t total;
+#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED)
int crc1_ok = 0, crc2_ok = 0;
- env_t *tmp_env1, *tmp_env2;
+ env_t *tmp_env1;
- total = CFG_ENV_SIZE;
+#ifdef CFG_REDUNDAND_ENVIRONMENT
+ env_t *tmp_env2;
- tmp_env1 = env_ptr;
tmp_env2 = (env_t *)((ulong)env_ptr + CFG_ENV_SIZE);
+ crc2_ok = (crc32(0, tmp_env2-data, ENV_SIZE) == tmp_env2-crc);
+#endif
+ tmp_env1 = env_ptr;
crc1_ok = (crc32(0, tmp_env1-data, ENV_SIZE) == tmp_env1-crc);
- crc2_ok = (crc32(0, tmp_env2-data, ENV_SIZE) == tmp_env2-crc);
- if (!crc1_ok !crc2_ok)
+ gd-env_addr = (ulong)env_ptr-data;
+
+ if (!crc1_ok !crc2_ok) {
+ gd-env_addr = 0;
gd-env_valid = 0;
- else if(crc1_ok !crc2_ok)
+ } else if(crc1_ok !crc2_ok)
gd-env_valid = 1;
+#ifdef CFG_REDUNDAND_ENVIRONMENT
else if(!crc1_ok crc2_ok)
gd-env_valid = 2;
else {
@@ -138,10 +145,13 @@ int env_init(void)
gd-env_valid = 1;
}
+ if (gd-env_valid == 2)
+ env_ptr = tmp_env2;
+ else
+#endif
if (gd-env_valid == 1)
env_ptr = tmp_env1;
- else if (gd-env_valid == 2)
- env_ptr = tmp_env2;
+
#else /* ENV_IS_EMBEDDED */
gd-env_addr = (ulong)default_environment[0];
gd-env_valid = 1;
@@ -186,12 +196,10 @@ int writeenv(size_t offset, u_char *buf)
#ifdef CFG_ENV_OFFSET_REDUND
int saveenv(void)
{
- size_t total;
int ret = 0;
nand_erase_options_t nand_erase_options;
env_ptr-flags++;
- total = CFG_ENV_SIZE;
nand_erase_options.length = CFG_ENV_RANGE;
nand_erase_options.quiet = 0;
@@ -229,7 +237,6 @@ int saveenv(void)
#else /* ! CFG_ENV_OFFSET_REDUND */
int saveenv(void)
{
- size_t total;
int ret = 0;
nand_erase_options_t nand_erase_options;
@@ -246,7 +253,6 @@ int saveenv(void)
return 1;
puts (Writing to Nand... );
- total = CFG_ENV_SIZE;
if (writeenv(CFG_ENV_OFFSET, (u_char *) env_ptr)) {
puts(FAILED!\n);
return 1;
@@ -290,12 +296,9 @@ int readenv (size_t offset, u_char * buf)
void env_relocate_spec (void)
{
#if !defined(ENV_IS_EMBEDDED)
- size_t total;
int crc1_ok = 0, crc2_ok = 0;
env_t *tmp_env1, *tmp_env2;
- total = CFG_ENV_SIZE;
-
tmp_env1 = (env_t *) malloc(CFG_ENV_SIZE);
tmp_env2 = (env_t *) malloc(CFG_ENV_SIZE);
diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
index 1ee4191..3acf7cd 100644
--- a/include/configs/smdk6400.h
+++ b/include/configs/smdk6400.h
@@ -223,6 +224,8 @@
#define CFG_UBOOT_BASE (CFG_MAPPED_RAM_BASE + 0x07e0)
#define CFG_ENV_OFFSET 0x004
+/* Leave enough space for bss, currently __bss_end == 0x57e74800 */
+#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8)
/* NAND configuration */
#define CFG_MAX_NAND_DEVICE1
@@ -284,7 +287,8 @@
*/
/* Settings
Re: [U-Boot] [ARM] Environment variables not available during console initialisation?
On Mon, 2 Feb 2009, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message pine.lnx.4.64.0902021725100.4...@axis700.grange you wrote: -#ifdef ENV_IS_EMBEDDED +#if defined(ENV_IS_EMBEDDED) extern uchar environment[]; env_t *env_ptr = (env_t *)(environment[0]); +#elif defined(CFG_ENV_IS_APPENDED) What makes you think an appended environment is so special that it is worth a separate #ifdef here? What about a prepended environment? Or one two sectors apart? Ok, agree, the name is badly chosen. The real restriction of this specific implementation is that the environment must be on the same NAND chip as the one we are booting from. Any location on that chip can be handled, I think. -#if defined(ENV_IS_EMBEDDED) - size_t total; +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED) int crc1_ok = 0, crc2_ok = 0; - env_t *tmp_env1, *tmp_env2; + env_t *tmp_env1; Note that there is a fundamental difference between embedded and non-embedded (in whatever which way) environments, but I can see no significant difference between an appended or a prepended or otherwise separate environment. The reason they share the same #if case here is that both get initialised early, not as was only possible until now on NAND - after all initcalls. Maybe you try to explain what you have in mind with this special-casing here? And I don't understand the rest of your implementation either. Please explain... Ok, currently environment in NAND has two cases: 1. embedded, in this case the real environment is initialised at env_init() time, otherwise first default environment is used 2. other, env_init() initialises the default environment, the real (stored in NAND) environment is first activated at env_relocate() time. With this patch we add one more case 3. environment, located on the same NAND chip as the boot NAND. in this case we can also let the nand_spl code load it for is in RAM and then we can use it in env_init(). diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h index 1ee4191..3acf7cd 100644 --- a/include/configs/smdk6400.h +++ b/include/configs/smdk6400.h @@ -223,6 +224,8 @@ #define CFG_UBOOT_BASE (CFG_MAPPED_RAM_BASE + 0x07e0) #define CFG_ENV_OFFSET 0x004 +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */ +#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8) What's that? What has BSS to do with the environment storage ??? This is smdk6400 header, on this board I chose to place the environment read in by nand_spl above bss, because, AFAIU, the area above __bss_end is unused by u-boot. But I didn't find an easy way to pass a calculated value from u-boot proper to nand_spl or vice versa. As you know, these two objects use saparate linker scripts and are linked absolutely independently, and just cat'ed together in the end. So, I had to use a macro to specify the location of the environment copy in RAM instead of calculating it precisely. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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] [ARM] Environment variables not available during console initialisation?
On Mon, 2 Feb 2009, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message pine.lnx.4.64.0902022141190.8...@axis700.grange you wrote:
-#ifdef ENV_IS_EMBEDDED
+#if defined(ENV_IS_EMBEDDED)
extern uchar environment[];
env_t *env_ptr = (env_t *)(environment[0]);
+#elif defined(CFG_ENV_IS_APPENDED)
What makes you think an appended environment is so special that it
is worth a separate #ifdef here? What about a prepended environment?
Or one two sectors apart?
Ok, agree, the name is badly chosen. The real restriction of this specific
implementation is that the environment must be on the same NAND chip as
the one we are booting from. Any location on that chip can be handled, I
think.
Such an explanation belongs into the commit message.
Sure, _if_ we decide, that this is the correct direction to fix this
problem.
And I'm not really sure why this file is affected, then.
This file provides the env_init() function, which now has to become aware
of the new possibility - proper (not default) environment already in RAM
(after being loaded by nand_spl).
+#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED)
int crc1_ok = 0, crc2_ok = 0;
- env_t *tmp_env1, *tmp_env2;
+ env_t *tmp_env1;
Note that there is a fundamental difference between embedded and
non-embedded (in whatever which way) environments, but I can see no
significant difference between an appended or a prepended or
otherwise separate environment.
The reason they share the same #if case here is that both get initialised
early, not as was only possible until now on NAND - after all initcalls.
But why does this matter here, and why do we have to change this file
for that?
I haven't found a better way to do this. Maybe there is one. I understood,
that the proper place to provide an early copy of the dynamic (not
default / static) environment is env_init(), a copy of which is present in
each of env_{flash,nand,nvram,onenand,dataflash,sf}.c.
1. embedded, in this case the real environment is initialised at
env_init() time, otherwise first default environment is used
First default environment? Do we have more than one default
environment?
s/first/at first/ (in the beginning, before env_relocate()).
2. other, env_init() initialises the default environment, the real (stored
in NAND) environment is first activated at env_relocate() time.
With this patch we add one more case
3. environment, located on the same NAND chip as the boot NAND. in this
case we can also let the nand_spl code load it for is in RAM and then we
can use it in env_init().
I don't see why we need a special case here.
We have two situations only:
1) environment is on the same NAND chip as the U-Boot image; this is
the case we can handle cleanly. But it does not play any role of
the environment is embedded, or directly adjacent (either before
or after) to the U-Boot image, or if it is on a completely
different location on this NAND chip.
Well, there is a difference. If the environment is embedded, it is loaded
by nand_spl automatically with the image with a single nand_load() (that's
how it worked until now, I think). If the environment is not embedded but
on the same chip, we still can handle it, but we need an additional
nand_load(). And the copy of the environment from NAND as loaded into RAM
will be at a different location. Maybe env_nand.c doesn't have to know
about this difference, but I haven't gone that far to unify these two
cases.
2) environment is on a different NAND chip than the U-Boot image; in
this case we cannot access the environment as early as needed,
i.e. proper operation of U-Boot is not possible.
To me this means that 1) is the case we implement, without additional
#ifdef'fery, and 2) is a configuration error for which we should add
appropriate #error handling.
Hm, as I briefly looked through other env_*.c, it looks like a few of them
resort to the default environment until env_relocate(). So, we can either
accept that and say on those media you can store environment, but it will
be only available late in boot process, or we can start fixing them all
by shifting hardware initialisation before env_init()... Or are you
suggesting to declare them all as broken?
#define CFG_ENV_OFFSET 0x004
+/* Leave enough space for bss, currently __bss_end == 0x57e74800 */
+#define CFG_NAND_ENV_DST (CFG_UBOOT_BASE + 0x8)
What's that? What has BSS to do with the environment storage ???
This is smdk6400 header, on this board I chose to place the environment
read in by nand_spl above bss, because, AFAIU, the area above __bss_end is
What has BSS to do with the environment storage ???
BSS does not take any space in the U-Boot image, so why leave a
(eventually huge) gap unused?
I need a location in RAM
Re: [U-Boot] [PATCH v3] Add 16bpp BMP support
On Fri, 30 Jan 2009, Wolfgang Denk wrote: If we really add more bmp formats, we also get more combinations like of bmp / lcd: Not necessarily. We can always request that bitmap images match the natural color depth of the display. It makes no sense to send a 16 bpp image to a 1 bpp display, nor does it vice versa. Hm, then I wouldn't be able to present 8bpp BMP on i.MX31 with 16bpp colours? BMP LCD 1-bit 1-bit 8-bit 1-bit 16-bit 1-bit 1-bit 8-bit ... if we really want to go that way, maybe better break this code into several functions for different format conversions? We do NOT want to do everything that is possible, but only what is reasonable. Isn't sending RGB24 image with 256 colours to a 16-bit display reasonable? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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
[U-Boot] [ARM] Environment variables not available during console initialisation?
Hi, a user is reporting, that setting silent and baudrate environment variables on ARM have no effect on the console bahaviour. I didn't test this but looking at the code it looks logical - the console is initialised before environment variables are read. Question - is this a bug that has to be fixed, or is there no good fix for this, because we really want to have console initialised ASAP - before the driver for the environment storage is initialised? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] iMX31: Add support to copy NAND Flash code to RAM
On Thu, 23 Oct 2008, Alan Carvalho de Assis wrote: Hi Guennadi, On Thu, Oct 23, 2008 at 4:10 PM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: Last time Scott Wood suggested to use nand_spl you replied I think using nand_spl is the best approach, but it will needs more effort to complete. and Anyway, right now we can have iMX31PDK booting with this code as an option for users willing to use U-Boot in this board. So, what's the status of this effort? If this your new submission, which still doesn't use nand_spl is not really targeted for upstream merge, I think, it would be better not to mark these mails PATCH. Or have I missed anything? This patch is just a rebase of previous patch, to be merged on u-boot-arm/master repository. I don't have nand_spl working until now. I am new sending patches to u-boot mailing list. So what is the problem when calling it of PATCH? Please, let me know about my mistake, can you explain about it? My understanding was, that the patch in this form, i.e., not using nand_spl should _not_ be accepted in the mainline and you sent it to the list just as a FYI for users willing to use your solution. That's why I suggested not to mark it as a PATCH. I haven't followed discussions of your previous submissions of this patch very closely, so I might have missed something, but I would agree with Scott and wait until a nand_spl version of this patch appears, and _not_ apply this patch in its present form. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] iMX31: Add support to copy NAND Flash code to RAM
On Fri, 24 Oct 2008, Magnus Lilja wrote: Where can one find developer documentation for nand_spl? doc/README.nand-boot-ppc440 Also, is there any ARM board supporting this already? nand_spl/board/samsung/smdk6400/ The nand_spl for the i.MX31 has to fit within 2048 bytes, along with some of the usual low_levelinit.S stuff. src/u-boot$ ls -l nand_spl/u-boot-spl.bin -rwxrwxr-x 1 * * 2840 2008-10-23 09:22 nand_spl/u-boot-spl.bin So, you just need to reduce it by about 30%:-) Also, for anyone implementing a new nand_spl board, please, change the SPL-image name from nand_spl/u-boot-spl-16k.bin to something more flexible:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
On Wed, 22 Oct 2008, Kyungmin Park wrote: Move machine specific code to smdk6400. Some board use OneNAND instead of NAND. Signed-off-by: Kyungmin Park [EMAIL PROTECTED] --- diff --git a/board/samsung/smdk6400/lowlevel_init.S b/board/samsung/smdk6400/lowlevel_init.S index e0119a7..53d9125 100644 --- a/board/samsung/smdk6400/lowlevel_init.S +++ b/board/samsung/smdk6400/lowlevel_init.S @@ -104,6 +104,13 @@ lowlevel_init: bl nand_asm_init #endif + /* Memory subsystem address 0x7e00f120 */ + ldr r0, =ELFIN_MEM_SYS_CFG + + /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ + mov r1, #0xd + str r1, [r0] + Hm, no, I don't quite agree. In principle, yes, this configuration can be considered platform-specific and moving it this way of course works. But: 1. The patch comment is not correct. This code doesn't select between NAND and OneNAND. It selects between (one of) NANDs and SROMs. 2. While at it, we could fix the value being written to the MEM_SYS_CFG register too. Currently it writes 0xd = (1 0) - ignored, default 0, so, better set it to 0 | (0 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 2) - ignored, default 0, so, better set it to 0 | (1 3) - set Xm0CSn[3] to SROMC CS3 So, we should just write an 8 in it: + mov r1, #0x8 + str r1, [r0] 3. The comment in the code doesn't look right. According to the above it should read + /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */ The only thing that confuses me, is why the author, belonging to the manufacturer of the chip, hasn't done this. Maybe the documentation is wrong? I tested it with the 8 - it works. So, once the issues are fixed, you get my Tested-by, although, I guess, you can test it just as well:-) Thanks Guennadi bl mem_ctrl_asm_init /* Wakeup support. Don't know if it's going to be used, untested. */ diff --git a/cpu/arm1176/s3c64xx/cpu_init.S b/cpu/arm1176/s3c64xx/cpu_init.S index 08bda99..32bb467 100644 --- a/cpu/arm1176/s3c64xx/cpu_init.S +++ b/cpu/arm1176/s3c64xx/cpu_init.S @@ -28,13 +28,6 @@ .globl mem_ctrl_asm_init mem_ctrl_asm_init: - /* Memory subsystem address 0x7e00f120 */ - ldr r0, =ELFIN_MEM_SYS_CFG - - /* Xm0CSn2 = NFCON CS0, Xm0CSn3 = NFCON CS1 */ - mov r1, #0xd - str r1, [r0] - /* DMC1 base address 0x7e001000 */ ldr r0, =ELFIN_DMC1_BASE ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
On Thu, 23 Oct 2008, Kyungmin Park wrote: (1 0) - ignored, default 0, so, better set it to 0 | (0 1) - set Xm0CSn[2] to OneNANDC CS0 or NFCON CS0 | (1 2) - ignored, default 0, so, better set it to 0 | (1 3) - set Xm0CSn[3] to SROMC CS3 So, we should just write an 8 in it: + mov r1, #0x8 + str r1, [r0] 3. The comment in the code doesn't look right. According to the above it should read + /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */ Right, and also add OneNAND NFCON is depends on XNANDSEL. In the datasheet this signal is called XSELNAND. And I don't think we have to quote this in the comment. This is a hardware configuration issue, not software, and we are not explaining the complete NAND configuration here, otherwise we would have to mention OM signals too, maybe more. As you know mem_ctrl_asm_init is common code and other boards can use it without board specific codes. In OneNAND board, it should be set as 0x1002 Sorry, do not understand what it. If you mean the MEM_SYS_CFG then I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
On Thu, 23 Oct 2008, Kyungmin Park wrote: In OneNAND board, it should be set as 0x1002 Sorry, do not understand what it. If you mean the MEM_SYS_CFG then I also don't understand this. As I quoted from the datasheet above, bit 1 set to 0 (0 1) is for _both_ - NAND or OneNAND. You suggest to set it to 1, which is SROMC CS2. And (1 12) is the data bus width, which also doesn't seem to be directly related to the NAND / OneNAND selection. Or did you mean another register? Right, I write wrong value, MEM_SYS_CFG has 0x1000. In OneNAND booting mode, MP0_CS_CFG[1] and MP0_CS_CFG[3] are ignored. It's not easy to describe since it depends on hardware configuration. However, there are not too much configurations S3C64XX_MEM_SYS_CFG_NAND0x0008 S3C64XX_MEM_SYS_CFG_ONENAND 0x1000 ? I asked above what the bus width has to do with OneNAND selection, you didn't reply. S3C64XX_MEM_SYS_CFG_MOVINAND 0x Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
On Thu, 23 Oct 2008, Kyungmin Park wrote: S3C64XX_MEM_SYS_CFG_NAND0x0008 S3C64XX_MEM_SYS_CFG_ONENAND 0x1000 ? I asked above what the bus width has to do with OneNAND selection, you didn't reply. OneNAND has always 16-bit butwidth. there's no exception. Ok, thanks, but I wouldn't call the macro ONENAND, but rather 16BIT, but that's just IMHO. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
On Thu, 23 Oct 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: + /* Xm0CSn[2] = OneNANDC CS0 or NFCON CS0, Xm0CSn[3] = SROMC CS3 */ Right, and also add OneNAND NFCON is depends on XNANDSEL. In the datasheet this signal is called XSELNAND. And I don't think we have to quote this in the comment. This is a hardware configuration issue, not software, and we are not explaining the complete NAND configuration here, otherwise we would have to mention OM signals too, maybe more. Hey, actually I do think that describing which hardware configurations the software performs is a Good Thing (TM). Exactly, which hardware configurations the software performs, XSELNAND is not performed in software, this is just a pin you wire high or low on your board. That's why I said we might not need to comment upon it. That's how I interpreted the datasheet anyway. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [ARM] Move machine specific code to board at s3c64xx
On Thu, 23 Oct 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: Hey, actually I do think that describing which hardware configurations the software performs is a Good Thing (TM). Exactly, which hardware configurations the software performs, XSELNAND is not performed in software, this is just a pin you wire high or low on your board. That's why I said we might not need to comment upon it. That's how I interpreted the datasheet anyway. I don;t think how this would make a difference. Even if the signal is defined by the hardware dsign - the very moment I am referencing this signal in any piece of software I should explain it so the reader of the code understands what I'm doing. I don't think this pin is referenced in software, at least not in this register, AFAICS. The only reason why Kyungmin mentioned it and why it is mentioned in the datasheet in the description of this register, is that this pin defines the selection between NAND and OneNAND - along with some other pins (OM[4:1] or some such). So, you cannot set this pin in software, you cannot read this pin in software (I think), maybe you have to switch a jumper when selecting another configuration, but that again has little to do with software, IMHO. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] iMX31: Add support to copy NAND Flash code to RAM
+ /* Restore return address and return to caller */ + ldr lr, [sp] + bx lr + +MXC_UBOOT_ROM_START: .word 0x87F0 +UBOOT_IMAGE_SIZE:.word 0x4 + diff --git a/include/asm-arm/arch-mx31/mx31-regs.h b/include/asm-arm/arch-mx31/mx31-regs.h index b04a718..1c5c121 100644 --- a/include/asm-arm/arch-mx31/mx31-regs.h +++ b/include/asm-arm/arch-mx31/mx31-regs.h @@ -84,8 +84,14 @@ #define IPU_CONF_IC_EN (11) #define IPU_CONF_SCI_EN (10) +#define ARM_PPMRR0x4015 + #define WDOG_BASE0x53FDC000 +#define AVIC_BASE0x6800 +#define AVIC_VECTOR0 (AVIC_BASE + 0x100) +#define AVIC_VECTOR1 (AVIC_BASE + 0x104) + /* * Signal Multiplexing (IOMUX) */ @@ -168,4 +174,67 @@ #define CS5_BASE 0xB600 #define PCMCIA_MEM_BASE 0xC000 +/* + * NAND controller + */ +#define NFC_BASE_ADDR0xB800 +#define NFC_REGS (NFC_BASE_ADDR + 0xE00) + +/* + * Addresses for NFC registers + */ +#define NFC_BUF_SIZE_OFF 0 +#define NFC_BUF_SIZE (*((volatile u16 *)(NFC_REGS + NFC_BUF_SIZE_OFF))) +#define NFC_BUF_ADDR_OFF 0x04 +#define NFC_BUF_ADDR (*((volatile u16 *)(NFC_REGS + NFC_BUF_ADDR_OFF))) +#define NFC_FLASH_ADDR_OFF 0x06 +#define NFC_FLASH_ADDR (*((volatile u16 *)(NFC_REGS + NFC_FLASH_ADDR_OFF))) +#define NFC_FLASH_CMD_OFF0x08 +#define NFC_FLASH_CMD(*((volatile u16 *)(NFC_REGS + NFC_FLASH_CMD_OFF))) +#define NFC_CONFIG_OFF 0x0A +#define NFC_CONFIG (*((volatile u16 *)(NFC_REGS + NFC_CONFIG_OFF))) +#define NFC_ECC_RSLT_OFF 0x0C +#define NFC_ECC_STATUS_RESULT(*((volatile u16 *)(NFC_REGS + NFC_ECC_RSLT_OFF))) +#define NFC_RSLTMAIN_AREA_OFF0x0E +#define NFC_RSLTMAIN_AREA(*((volatile u16 *)(NFC_REGS + NFC_RSLTMAIN_AREA_OFF))) +#define NFC_RSLTSPARE_AREA_OFF 0x10 +#define NFC_RSLTSPARE_AREA (*((volatile u16 *)(NFC_REGS + NFC_RSLTSPARE_AREA_OFF))) +#define NFC_WRPROT_OFF 0x12 +#define NFC_WRPROT (*((volatile u16 *)(NFC_REGS + NFC_WRPROT_OFF))) +#define NFC_UNLCKSTART_BLK_OFF 0x14 +#define NFC_UNLCKSTART_BLKADDR (*((volatile u16 *)(NFC_REGS + NFC_UNLOCKSTART_BLK_OFF))) +#define NFC_UNLCKEND_BLK_OFF 0x16 +#define NFC_UNLCKEND_BLKADDR (*((volatile u16 *)(NFC_REGS + NFC_UNLOCKEND_BLK_OFF))) +#define NFC_NF_WRPRST_OFF0x18 +#define NFC_NF_WRPRST(*((volatile u16 *)(NFC_REGS + NFC_NF_WRPRST_OFF))) +#define NFC_CONFIG1_OFF 0x1A +#define NFC_CONFIG1 (*((volatile u16 *)(NFC_REGS + NFC_CONFIG1_OFF))) +#define NFC_CONFIG2_OFF 0x1C +#define NFC_CONFIG2 (*((volatile u16 *)(NFC_REGS + NFC_CONFIG2_OFF))) + +#define RAM_BUFFER_ADDRESS_RBA_3 0x3 +#define NFC_BUFSIZE_1KB 0x0 +#define NFC_BUFSIZE_2KB 0x1 +#define NFC_CONFIGURATION_UNLOCKED 0x2 +#define ECC_STATUS_RESULT_NO_ERR 0x0 +#define ECC_STATUS_RESULT_1BIT_ERR 0x1 +#define ECC_STATUS_RESULT_2BIT_ERR 0x2 +#define NF_WR_PROT_UNLOCK0x4 +#define NAND_FLASH_CONFIG1_FORCE_CE (1 7) +#define NAND_FLASH_CONFIG1_RST (1 6) +#define NAND_FLASH_CONFIG1_BIG (1 5) +#define NAND_FLASH_CONFIG1_INT_MSK (1 4) +#define NAND_FLASH_CONFIG1_ECC_EN(1 3) +#define NAND_FLASH_CONFIG1_SP_EN (1 2) +#define NAND_FLASH_CONFIG2_INT_DONE (1 15) +#define NAND_FLASH_CONFIG2_FDO_PAGE (0 3) +#define NAND_FLASH_CONFIG2_FDO_ID(2 3) +#define NAND_FLASH_CONFIG2_FDO_STATUS(4 3) +#define NAND_FLASH_CONFIG2_FDI_EN(1 2) +#define NAND_FLASH_CONFIG2_FADD_EN (1 1) +#define NAND_FLASH_CONFIG2_FCMD_EN (1 0) +#define FDO_PAGE_SPARE_VAL 0x8 +#define NAND_FLASH_BOOT 0x1000 +#define MXCFIS_NAND 0x1000 + #endif /* __ASM_ARCH_MX31_REGS_H */ -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX31: document timer precision option
On Thu, 18 Sep 2008, Shinya Kuribayashi wrote: Hi Guennadi, Guennadi Liakhovetski wrote: Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED] --- diff -u /dev/null doc/README.imx31 --- /dev/null 2008-08-28 10:21:05.503011301 +0200 +++ doc/README.imx312008-08-28 12:15:21.0 +0200 @@ -0,0 +1,13 @@ +i.MX31 specific Configuration Options: +-- + +- Timer precision: + CONFIG_MX31_TIMER_HIGH_PRECISION + + Enable higher precision timer. The low-precision timer + (default) provides approximately 4% error, whereas the + high-precision timer is about 0.4% accurate. The extra + accuracy is achieved at the cost of higher computational + overhead, which, in places where time is measured, should + not be critical, so, it should be safe to enable this + option. I'm not familiar with the maintainance policy of README and doc/*, but is there any reasone this README.imx31 is sitting on the top of tree? Should be marged into $(TOPDIR)/README, or moved to doc/ directory? Noticed a few minutes ago, so just let you know... +++ doc/README.imx312008-08-28 12:15:21.0 +0200 Looks like doc/ to me. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] erase and saveenv stop working after using fw_setenv
On Tue, 16 Sep 2008, Wolfgang Denk wrote: b) Guennadi, I think it would be nice, user-friendly behaviour if fw_setenv did not unconditional locking, but would instead leave the flash in the same state it found it. Do you think it would be possible to test the state first, and then perform the unlock / lock operations only when the flash sectors were already locked when fw_setenv was called? I am not sure if this is possible with the current MTD ABI, it looks like it is not. There is a flags member in struct mtd_info_user, which can take value MTD_WRITEABLE, but I think it means something different - whether this mtd-device is writable in principle. So, it looks like the only way to find out whether the specific sector is locked is to try to write / erase it:-( Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [fw_printenv should open device as O_SYNC]
On Wed, 10 Sep 2008, Mari Ivan-AIM018 wrote: Hi all, We have hit the following issue in a board with 2 flash banks. First I set some env variable in U-boot, using fw_setenv, then immediately I switch the banks. But as the buffers have not yet been flushed to the mtd driver, the bank switching leaves the flash in corrupted state. Isn't this a bug in the respective MTD driver then? You should be able to open as many file-descriptors to different mtd devices as you like and be able to operate on them simultaneously. Or doesn't it work like that? I ve modified the fw_env.c file to open the mtd O_SYNC and it works fine. If it is OK I can submit a patch for this. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: Use do_div() instead of division for long long.
On Tue, 9 Sep 2008, Wolfgang Denk wrote:
diff --git a/board/trab/tsc2000.c b/board/trab/tsc2000.c
index 382a85b..f13a5a9 100644
--- a/board/trab/tsc2000.c
+++ b/board/trab/tsc2000.c
@@ -27,6 +27,7 @@
#include common.h
#include s3c2400.h
+#include div64.h
#include tsc2000.h
#include Pt1000_temp_data.h
@@ -332,6 +333,7 @@ void tsc2000_reg_init (void)
int tsc2000_interpolate(long value, long data[][2], long *result)
{
int i;
+ unsigned long long val;
/* the data is sorted and the first element is upper
* limit so we can easily check for out-of-band values
@@ -347,10 +349,10 @@ int tsc2000_interpolate(long value, long data[][2],
long *result)
result in 'long long'.
*/
- *result = data[i-1][1] +
- ((unsigned long long)(data[i][1] - data[i-1][1])
- * (unsigned long long)(value - data[i-1][0]))
- / (data[i][0] - data[i-1][0]);
+ val = ((unsigned long long)(data[i][1] - data[i-1][1])
+* (unsigned long long)(value - data[i-1][0]));
+ do_div(val, (data[i][0] - data[i-1][0]));
Looking at how do_div() is defined, and it handles its parameters
carefully, one shouldn't need the extra parenthesis here, i.e.,
+ do_div(val, data[i][0] - data[i-1][0]);
should be enough.
+ *result = data[i-1][1] + val;
return 0;
}
diff --git a/cpu/arm1176/s3c64xx/interrupts.c
b/cpu/arm1176/s3c64xx/interrupts.c
index 8356ae4..e34369f 100644
--- a/cpu/arm1176/s3c64xx/interrupts.c
+++ b/cpu/arm1176/s3c64xx/interrupts.c
@@ -41,6 +41,7 @@
#include common.h
#include asm/proc-armv/ptrace.h
#include s3c6400.h
+#include div64.h
static ulong timer_load_val;
@@ -148,7 +149,9 @@ void reset_timer(void)
ulong get_timer_masked(void)
{
- return get_ticks() / (timer_load_val / (100 * CFG_HZ));
+ unsigned long long res = get_ticks();
+ do_div (res, (timer_load_val / (100 * CFG_HZ)));
Same here.
+ do_div (res, timer_load_val / (100 * CFG_HZ));
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Suppressing Diagnostic Output for 'fw_setenv'
On Sun, 7 Sep 2008, Wolfgang Denk wrote: Dear Grant Erickson, In message [EMAIL PROTECTED] you wrote: Added support for a ``-v'' option for fw_setenv to explicitly enable what was formerly default verbose diagnostic output when updating the environment. Signed-off-by: Grant Erickson [EMAIL PROTECTED] --- tools/env/fw_env.c | 43 +-- tools/env/fw_env_main.c |4 +++- 2 files changed, 32 insertions(+), 15 deletions(-) I will not apply this patch for now, as I expect that Guennadi will address this issue in his rewrite of the fw_setenv command when adding NAND support. Please check again and resubmit (if still needed) later (affter Guennadi's patch went in). In my last patch version (v2, submitted last Thursday, 4 Sep), I put all debugging output in #ifdef DEBUG blocks. So, if this patch is accepted in its current form, you will have to look at those ifdef's and see which of them you want to make dynamically selectable per '-v' switch. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [REGRESSION] commit b502611b51... Change env_get_char from a... breaks imx31_phycore
On Sat, 6 Sep 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: Was this patch correct then? http://lists.denx.de/pipermail/u-boot/2008-July/037375.html So, we just have to revert this one http://lists.denx.de/pipermail/u-boot/attachments/20080722/92a646d6/attachment.txt and apply the former one? I cannot test now, will be able to do this in about 10 hours:-) I don't understand all impleications of the ARM implementation (which really should be fixed one day), but to me this sounds reasonable. Ok, took a bit longer, like 30 hours, but it's tested now - it works for imx31_phycore. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [REGRESSION] commit b502611b51... Change env_get_char from a... breaks imx31_phycore
On Sat, 6 Sep 2008, Remy Bohmer wrote: Hello Guennadi, http://lists.denx.de/pipermail/u-boot/attachments/20080722/92a646d6/attachment.txt which does indeed fix it for all boards setting CONFIG_SKIP_RELOCATE_UBOOT, i.e., booting directly from RAM... Please, correct me if I am wrong! You are _not_ wrong. It was my goal to fix it for all boards at once. Have you tried it already with the imx31_phycore board? Sorry, do not understand. I tried it - what? I was testing with the current git snapshot, where your patch is in, yes, and that is where I detected the breakage on imx31_phycore. But that board does not set CONFIG_SKIP_RELOCATE_UBOOT, because it is not booting directly from RAM as described in the README. So, your patch does not help, as well as on all other boards which do not or shall not define CONFIG_SKIP_RELOCATE_UBOOT. And you say, that I am _not_ wrong, which means, a patch that aimed to fix the problem for all ARM boards has been replaced with your patch, which only fixes it for CONFIG_SKIP_RELOCATE_UBOOT boards, of which there probably should be very few or none at all out there. Hence the question: shell we set GD_FLG_RELOC centrally really for all boards or are there boards out there that really must not have this flag set? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [REGRESSION] commit b502611b51... Change env_get_char from a... breaks imx31_phycore
On Fri, 5 Sep 2008, Joakim Tjernlund wrote: -Original Message- From: Guennadi Liakhovetski [mailto:[EMAIL PROTECTED] Sent: den 5 september 2008 20:01 To: U-Boot@lists.denx.de Cc: Joakim Tjernlund Subject: [REGRESSION] commit b502611b51... Change env_get_char from a... breaks imx31_phycore Hi, The aforementioned commit commit b502611b51f02718c2d1117d4981dabceb5af6de Author: Joakim Tjernlund [EMAIL PROTECTED] Date: Sun Jul 6 12:30:09 2008 +0200 Change env_get_char from a global function ptr to a function This avoids an early global data reference. Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED] found by bisection and causes at least the imx31_phycore board to break. The boot process becomes slow, printenv is very slow too, booting does not always come to the bootdelay countdown, tftp wtops working too. Reverting this commit from the current HEAD fixes the problem. Your board probably don't flip the GD_FLG_RELOC flag after relocation. A few ARM boards had a problem with this too. Ok, this sounds good, but a grep over the current tree (as of commit 3e3c026ed746a284c6f0ef139b26d859939de7e9) reveals only one ARM board that does this: davinci. It is also set globally if you define CONFIG_SKIP_RELOCATE_UBOOT, which also is done by a couple of boards. From the README: - CONFIG_SKIP_LOWLEVEL_INIT - CONFIG_SKIP_RELOCATE_UBOOT [ARM only] If these variables are defined, then certain low level initializations (like setting up the memory controller) are omitted and/or U-Boot does not relocate itself into RAM. Normally these variables MUST NOT be defined. The only exception is when U-Boot is loaded (to RAM) by some other boot loader or by a debugger which performs these initializations itself. So, this doesn't look like the proper way to force setting of GD_FLG_RELOC. OTOH, other architectures do it centrally in their lib_*/board.c::board_init_[fr](). I certainly do not know all ARM boards (maintainer added to CC), so, the question is: shall / can we do the same on ARM - set this flag centrally, or is there a reason not to do that? I see this email http://lists.denx.de/pipermail/u-boot/2008-July/037375.html trying to do exactly this, as a reply came this http://lists.denx.de/pipermail/u-boot/2008-July/037389.html promising a fix for all, and that resulted in this: http://lists.denx.de/pipermail/u-boot/attachments/20080722/92a646d6/attachment.txt which does indeed fix it for all boards setting CONFIG_SKIP_RELOCATE_UBOOT, i.e., booting directly from RAM... Please, correct me if I am wrong! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] fw_env: add NAND support
Add support for environment in NAND with automatic NOR / NAND recognition,
including unaligned environment, bad-block skipping, redundant environment
copy.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
Changes since v1: multiple style updates, added Copyright, restored
flash_io() function, fixed NAND flag handling. Thanks for all the
comments.
diff --git a/tools/env/README b/tools/env/README
index f8a644e..91e679a 100644
--- a/tools/env/README
+++ b/tools/env/README
@@ -22,9 +22,11 @@ following lines are relevant:
#define DEVICE1_OFFSET0x
#define ENV1_SIZE 0x4000
#define DEVICE1_ESIZE 0x4000
+#define DEVICE1_ENVSECTORS 2
#define DEVICE2_OFFSET0x
#define ENV2_SIZE 0x4000
#define DEVICE2_ESIZE 0x4000
+#define DEVICE2_ENVSECTORS 2
Current configuration matches the environment layout of the TRAB
board.
@@ -46,3 +48,7 @@ then 1 sector.
DEVICEx_ESIZE defines the size of the first sector in the flash
partition where the environment resides.
+
+DEVICEx_ENVSECTORS defines the number of sectors that may be used for
+this environment instance. On NAND this is used to limit the range
+within which bad blocks are skipped, on NOR it is not used.
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index e4fc02d..b6036c8 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -2,6 +2,9 @@
* (C) Copyright 2000-2008
* Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
*
+ * (C) Copyright 2008
+ * Guennadi Liakhovetski, DENX Software Engineering, [EMAIL PROTECTED]
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -45,36 +48,75 @@
#defineCMD_GETENV fw_printenv
#defineCMD_SETENV fw_setenv
-typedef struct envdev_s {
+#define min(x, y) ({ \
+ typeof(x) _min1 = (x); \
+ typeof(y) _min2 = (y); \
+ (void) (_min1 == _min2); \
+ _min1 _min2 ? _min1 : _min2; })
+
+struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
-} envdev_t;
+ ulong env_sectors; /* number of environment sectors */
+ uint8_t mtd_type; /* type of the MTD device */
+};
-static envdev_t envdevices[2];
-static int curdev;
+static struct envdev_s envdevices[2] =
+{
+ {
+ .mtd_type = MTD_ABSENT,
+ }, {
+ .mtd_type = MTD_ABSENT,
+ },
+};
+static int dev_current;
#define DEVNAME(i)envdevices[(i)].devname
#define DEVOFFSET(i) envdevices[(i)].devoff
#define ENVSIZE(i)envdevices[(i)].env_size
#define DEVESIZE(i) envdevices[(i)].erase_size
+#define ENVSECTORS(i) envdevices[(i)].env_sectors
+#define DEVTYPE(i)envdevices[(i)].mtd_type
-#define CFG_ENV_SIZE ENVSIZE(curdev)
+#define CFG_ENV_SIZE ENVSIZE(dev_current)
#define ENV_SIZE getenvsize()
-typedef struct environment_s {
- ulong crc; /* CRC32 over data bytes*/
- unsigned char flags;/* active or obsolete */
- char *data;
-} env_t;
+struct env_image_single {
+ uint32_tcrc;/* CRC32 over data bytes*/
+ chardata[];
+};
-static env_t environment;
+struct env_image_redundant {
+ uint32_tcrc;/* CRC32 over data bytes*/
+ unsigned char flags; /* active or obsolete */
+ chardata[];
+};
+
+enum flag_scheme {
+ FLAG_NONE,
+ FLAG_BOOLEAN,
+ FLAG_INCREMENTAL,
+};
+
+struct environment {
+ void*image;
+ uint32_t*crc;
+ unsigned char *flags;
+ char*data;
+ enum flag_schemeflag_scheme;
+};
+
+static struct environment environment = {
+ .flag_scheme = FLAG_NONE,
+};
static int HaveRedundEnv = 0;
static unsigned char active_flag = 1;
+/* obsolete_flag must be 0 to efficiently set it on NOR flash without erasing
*/
static unsigned char obsolete_flag = 0;
@@ -157,7 +199,7 @@ static char default_environment[] = {
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
- \0/* Termimate env_t data with 2 NULs */
+ \0/* Termimate struct environment data with 2 NULs */
};
static int flash_io (int mode);
@@ -186,7 +228,7 @@ char *fw_getenv (char *name)
char *env, *nxt;
if (env_init ())
- return (NULL);
+ return NULL;
for (env = environment.data; *env; env = nxt + 1) {
char *val;
@@ -195,15 +237,15 @@ char *fw_getenv (char *name)
if (nxt = environment.data[ENV_SIZE]) {
fprintf (stderr
Re: [U-Boot] [PATCH] fw_env: add NAND support
On Tue, 2 Sep 2008, Wolfgang Denk wrote:
@@ -596,107 +844,120 @@ static char *envmatch (char * s1, char * s2)
static int env_init (void)
{
int crc1, crc1_ok;
+ char flag1, *addr1;
int crc2, crc2_ok;
+ char flag2, *addr2;
I think you should number these 0 an 1, respectively here.
Because then you can read this code much better:
if (crc1_ok !crc2_ok) {
+ dev_current = 0;
} else if (!crc1_ok crc2_ok) {
+ dev_current = 1;
would become:
if (crc0_ok !crc1_ok) {
dev_current = 0;
} else if (!crc0_ok crc1_ok) {
dev_current = 1;
If 0 is OK, then use 0; if 1 is ok then use 1.
Your version: if 1 is OK then use 0, if 2 is OK then use 1
is more difficult to read.
[Or stick with the old identifiers, i. e. use 1 and 2 consistently,
but don't mix 0/1 here and 1/2 there.]
Sorry, don't understand. This is the original code:
if (crc1_ok !crc2_ok) {
environment.data = addr1;
environment.flags = flag1;
environment.crc = crc1;
curdev = 0;
free (addr2);
Which looks to me like if (crc1_ok...) {... curdev = 0;...}, which I
tried to preserve. So, you would prefer me to _change_ it?
+ if ((fp = fopen (fname, r)) == NULL)
+ return -1;
+ while (i 2 fgets (dump, sizeof (dump), fp)) {
/* Skip incomplete conversions and comment strings */
+ if (dump[0] == '#')
continue;
I think you must initialize ENVSECTORS(i) here...
+ rc = sscanf (dump, %s %lx %lx %lx %lx,
+DEVNAME (i),
+DEVOFFSET (i),
+ENVSIZE (i),
+DEVESIZE (i),
+ENVSECTORS (i));
+
+ if (rc 4)
+ continue;
+
+ if (rc 5)
+ /* Default - 1 sector */
+ ENVSECTORS (i) = 1;
Because if rc 4, you already continued and left ENVSECTORS uninitialized.
As far as I understand, with rc == 3 there is no DEVESIZE in the line,
which doesn't look like a valid configuration line to me. The orginal code
however accepted such lines and only dropped lines with rc 3. I do not
understand how the original code managed to work with rc == 3. As I
thought this was a bug, I changed the test to rc 4, i.e., now I
require at least 4 fields, in which case I initialise ENVSECTORS to the
default value - 1 sector. If rc 4 the counter i is not incremented and
the line is dropped - in the same way as in the original version. Or am I
missing something?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env: add NAND support
On Tue, 2 Sep 2008, Wolfgang Denk wrote: Note that this is a serious impairment compared to the old version. The whole logic of writing the envrionment (and especially so when redundancy is used) is based on separate logic steps that are per- formed strictly sequentially, and only when the previous one was successfully completed. This essential to maintain consistent data. For the redundant case that means: 1) write the environment data to flash. *After* this has completed, make the data valid by 2) writing the CRC checksum. *After* this has completed, make this copy of the environment valid by 3) writing the valid flag to this copy. *After* this has completed, make the other copy of the environment obsolete by 4) writing the obsolete flag to the other copy. I am afraid, I cannot confirm this in the current version. In it first CRC and flag is written with one write, then the data, then optionally any residual data. Which seems like not providing any additional robustness. Would you like me to replicate this behaviour, in which case we could just as well write the whole buffer at once as I did up to now, or change it to follow your scheme above? In the latter case I am not sure if this will work with all kernel versions with all mtd drivers and all NOR flashes. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fw_env: add NAND support
On Wed, 3 Sep 2008, Wolfgang Denk wrote: As far as I understand, with rc == 3 there is no DEVESIZE in the line, which doesn't look like a valid configuration line to me. The orginal code however accepted such lines and only dropped lines with rc 3. I do not understand how the original code managed to work with rc == 3. As I thought this was a bug, I changed the test to rc 4, i.e., now I Did you verify that is was a bug? Yes: Unlocking flash... Done Cannot malloc -32768 bytes: Cannot allocate memory Error: can't write fw_env to flash Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Support NAND in fw_printenv/fw_setenv
On Sun, 31 Aug 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: What follows is a patch series to support NAND environment under Linux, including bad blocks. In principle, this is just one logical change, but it is a big one... So I split it into 6 smaller patches, which should be easier to review. Tested with and without redundant environment, with an injected bad block, crossing block border, read and write. I just tried building for older kernels - it doesn't work: - make env MTD_VERSION=old I am not sure if I am doing this right - maybe I have to point U-Boot to older kernel headers too, or it has to be done with an older tolchain, in any case, this doesn't seem to work also with the current mainline version: $ make env MTD_VERSION=old make -C tools/env all MTD_VERSION=old || exit 1 make[1]: Entering directory `/home/lyakh/project/17/src/u-boot/tools/env' ppc_4xx-gcc -Wall -DUSE_HOSTCC -I/home/lyakh/project/17/src/u-boot/include -DMTD_OLD crc32.c fw_env.c fw_env_main.c -o fw_printenv In file included from /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd.h:13, from fw_env.c:36: /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:15: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:20: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:57: error: expected specifier-qualifier-list before 'uint8_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:70: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:78: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:108: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:115: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:125: error: expected specifier-qualifier-list before 'uint32_t' /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd-abi.h:140: error: expected specifier-qualifier-list before 'uint32_t' In file included from fw_env.c:36: /home/lyakh/project/17/src/u-boot/include/linux/mtd/mtd.h:107: error: expected specifier-qualifier-list before 'uint32_t' fw_env.c: In function 'fw_setenv': fw_env.c:386: error: 'uint8_t' undeclared (first use in this function) fw_env.c:386: error: (Each undeclared identifier is reported only once fw_env.c:386: error: for each function it appears in.) fw_env.c:386: error: expected expression before ')' token fw_env.c:386: error: too few arguments to function 'crc32' fw_env.c: In function 'flash_io': fw_env.c:400: error: 'erase_info_t' undeclared (first use in this function) fw_env.c:400: error: expected ';' before 'erase' fw_env.c:431: error: 'erase' undeclared (first use in this function) fw_env.c: In function 'env_init': fw_env.c:621: error: 'uint8_t' undeclared (first use in this function) fw_env.c:621: error: expected expression before ')' token fw_env.c:621: error: too few arguments to function 'crc32' fw_env.c:645: error: expected expression before ')' token fw_env.c:645: error: too few arguments to function 'crc32' make[1]: *** [fw_printenv] Error 1 make[1]: Leaving directory `/home/lyakh/project/17/src/u-boot/tools/env' make: *** [env] Error 1 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fw_env: add NAND support
Add support for environment in NAND with automatic NOR / NAND recognition,
including unaligned environment, bad-block skipping, redundant environment
copy.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
This is now a single patch. No union any more, instead a struct with
pointers into a flat image buffer is used. Still, MTD_VERSION=old doesn't
work, it looks it is also broken in the current version.
diff --git a/tools/env/README b/tools/env/README
index f8a644e..f32f872 100644
--- a/tools/env/README
+++ b/tools/env/README
@@ -22,9 +22,11 @@ following lines are relevant:
#define DEVICE1_OFFSET0x
#define ENV1_SIZE 0x4000
#define DEVICE1_ESIZE 0x4000
+#define DEVICE1_ENVSECTORS 2
#define DEVICE2_OFFSET0x
#define ENV2_SIZE 0x4000
#define DEVICE2_ESIZE 0x4000
+#define DEVICE2_ENVSECTORS 2
Current configuration matches the environment layout of the TRAB
board.
@@ -46,3 +48,7 @@ then 1 sector.
DEVICEx_ESIZE defines the size of the first sector in the flash
partition where the environment resides.
+
+DEVICEx_ENVSECTORS defines the number of sectors that may be used for
+this environment instance. On NAND this is used to limit the range
+within which bad blocks are skipped, on NOR it is unused.
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index b8bca91..7479dbe 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -44,36 +44,57 @@
#defineCMD_GETENV fw_printenv
#defineCMD_SETENV fw_setenv
+#define min(x, y) ({ \
+ typeof(x) _min1 = (x); \
+ typeof(y) _min2 = (y); \
+ (void) (_min1 == _min2); \
+ _min1 _min2 ? _min1 : _min2; })
+
typedef struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
+ ulong env_sectors; /* number of environment sectors */
} envdev_t;
static envdev_t envdevices[2];
-static int curdev;
+static int dev_current;
#define DEVNAME(i)envdevices[(i)].devname
#define DEVOFFSET(i) envdevices[(i)].devoff
#define ENVSIZE(i)envdevices[(i)].env_size
#define DEVESIZE(i) envdevices[(i)].erase_size
+#define ENVSECTORS(i) envdevices[(i)].env_sectors
-#define CFG_ENV_SIZE ENVSIZE(curdev)
+#define CFG_ENV_SIZE ENVSIZE(dev_current)
#define ENV_SIZE getenvsize()
-typedef struct environment_s {
- ulong crc; /* CRC32 over data bytes*/
- unsigned char flags;/* active or obsolete */
- char *data;
-} env_t;
+struct env_image_single {
+ uint32_tcrc;/* CRC32 over data bytes*/
+ chardata[];
+};
+
+struct env_image_redundant {
+ uint32_tcrc;/* CRC32 over data bytes*/
+ unsigned char flags; /* active or obsolete */
+ chardata[];
+};
+
+struct environment {
+ void*image;
+ uint32_t*crc;
+ unsigned char *flags;
+ char*data;
+};
-static env_t environment;
+static struct environment environment;
static int HaveRedundEnv = 0;
static unsigned char active_flag = 1;
+/* obsolete_flag must be 0 to efficiently set it on NOR flash without erasing
*/
static unsigned char obsolete_flag = 0;
@@ -156,10 +177,11 @@ static char default_environment[] = {
#ifdef CONFIG_EXTRA_ENV_SETTINGS
CONFIG_EXTRA_ENV_SETTINGS
#endif
- \0/* Termimate env_t data with 2 NULs */
+ \0/* Termimate struct environment data with 2
NULs */
};
-static int flash_io (int mode);
+static int flash_write (void);
+static int flash_read (void);
static char *envmatch (char * s1, char * s2);
static int env_init (void);
static int parse_config (void);
@@ -185,7 +207,7 @@ char *fw_getenv (char *name)
char *env, *nxt;
if (env_init ())
- return (NULL);
+ return NULL;
for (env = environment.data; *env; env = nxt + 1) {
char *val;
@@ -194,15 +216,15 @@ char *fw_getenv (char *name)
if (nxt = environment.data[ENV_SIZE]) {
fprintf (stderr, ## Error:
environment not terminated\n);
- return (NULL);
+ return NULL;
}
}
val = envmatch (name, env);
if (!val)
continue;
- return (val);
+ return val;
}
- return (NULL);
+ return NULL;
}
/*
@@ -216,7 +238,7 @@ int fw_printenv (int argc, char *argv[])
int rc = 0;
if (env_init ())
- return
Re: [U-Boot] [PATCH] fw_env: add NAND support
On Tue, 2 Sep 2008, Wolfgang Denk wrote:
+ /* Offset inside a block */
+ block_seek = offset - blockstart;
...
+ /* Limit to one block for the first read */
Why?
Because this is on NAND, there we have to perform all IO block at a time.
+
+ /*
+* If a block is bad, we retry in the next block at the same
+* offset - see common/env_nand.c::writeenv()
+*/
+ lseek (fd, blockstart + block_seek, SEEK_SET);
Hm... there was a continue for the badblock case just above, so do
we really try the _next_ block here?
I meant, if the first block with non-zero offset (block_seek) was bad,
then in the _next_ after it block we try at the same offset.
+ /*
+* Data size we actually have to write: from the start of the block
+* to the start of the data, then count bytes ob data, and to the
---^ f
+* end of the block
+*/
Hm... sounds as if this was always exactly one full block, then?
or two, or three...
+ write_total = (block_seek + count + blocklen - 1) ~(blocklen - 1);
+
+ /*
+* Support data anywhere within erase sectors: read out the complete
+* area to be erased, replace the environment image, write the whole
+* block back again.
+*/
+ if (write_total count) {
+ data = malloc (erase_len);
My understanding is, that erase_len can be block size. Is this
correct?
Yes.
I don't see where the actual size of the environment data is taken
into considration?
in the count function parameter, which is then used to calculate
write_total.
+ } else {
+ /* Offset is block-aligned by construction here */
What does block-aligned by construction mean?
It means, by the way I constructed (calculated) lengths above this place,
we land here only if offset is block-aligned.
+ erase.length = erasesize;
+
+ /* This only runs once on NOR flash */
How comes that?
Because on NOR I set erasesize to the total length of the data plus
alignment.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Support NAND in fw_printenv/fw_setenv
On Sun, 31 Aug 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: Ok, how about this: we leave the current fw_env.c as it is, I submit _exactly_ the state after applying my 6 patches as a new file, with suitable changes to the Makefile, fix building with MTD_VERSION=old, and try to improve comments in the code. Would this be accepted? Just improvements of comments? I think there were comments about code as well. These shall be addressed, too. Ok, I looked through all your comments today, and this is what I extracted from all of them as code improvement suggestions (sorry if I missed anything, please remind): 1. do not use the union well, I would still prefer to use it and I hope I will be allowed to do so in a separate NAND-tool. I agree, it would be better to use the definition from the environment.h directly. But: a) env_t in environment.h does indeed describe the environment layout on the media, but, this is only possible thanks to the compile-time decisions whether or not to include flags and how long is data. b) it wasn't done before, env_t in the original tool was not equivalent with the environment.h definition: it couldn't decide at compile time whether or not to have flags, so, the struct always included it, and it had char *data in it, which is not the same as char data[...], so you couldn't cast this type on the environment image. c) Now the union I proposed does describe the environment layout, can be casted on the image, and I really don't see another clean way of doing this. 2. do not use single.crc in redundant case This is done only at two places, yes, I realise, this is not very clean, but in the present configuration with a comment explaining why this is correct, I would consider this acceptable. Otherwise, I could either introducs a reference to crc in struct environment similar to the pointer to data, or I could open code using the correct - single or redundant - crc at these two occasions, which, of course, is actually not needed. 3. use a type equivalent with the one from the environment.h header See 1. above. 4. fix MTD_OLD Would we still need this with NAND-only tool? 5. clarify back-up mode This is actually a comment improvement, can do. 6. erase / write only as much as needed Yes, this is important, I'll have a look at it. 7. in flash_bad_blocks do not modify blockstart Can do this, good point. Have I missed anything? Would the current v2 version _with_ these changes be accepted? A couple more questions then: Shall I keep support for NOR in the separate NAND version or completely remove it? The type == MTD_NORFLASH code is quite small, so, removing it would not significantly simplify or reduce the size of the nand-version. In fact, I still think having one tool support both might be preferable from the maintenance point of view - all fixes, improvements, changes, that affect both versions would only have to be done once... So, maybe if we now add a new tool, which supports both, after we have sufficiently tested it, we could remove the original one? How shall I name it? nand_env? New issue: I just noted that the default environment built into the fw_ tool has not much to do with the default environment build into the U-Boot binary image; in theory both should be the same. Don;t know yet if this is a new or an old bug, though. Will have a look. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Support NAND in fw_printenv/fw_setenv
On Mon, 1 Sep 2008, Guennadi Liakhovetski wrote: New issue: I just noted that the default environment built into the fw_ tool has not much to do with the default environment build into the U-Boot binary image; in theory both should be the same. Don;t know yet if this is a new or an old bug, though. Will have a look. This seems to be also the case in the mainline version, and fixing it would take a bit more than a oneliner - just including config.h produces a couple of redefeined warnings. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7 v7] ARM: Add support for S3C6400 based SMDK6400 board
On Mon, 1 Sep 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: SMDK6400 can only boot U-Boot from NAND-flash. This patch adds a nand_spl driver for it too. The board can also boot from the NOR flash, but due to hardware limitations it can only address 64KiB on it, which is not enough for U-Boot. Based on the original sources by Samsung for U-Boot 1.1.6. Can you please check the compiler options? This is what I get with ELDK 4.1 for ARM: - ./MAKEALL smdk6400 cc1: error: invalid option 'eabi' cc1: error: invalid option 'string' ... Looks like the problem is with the build system somewhere. After a distclean it builds cleanly. Whereas, just tried it after kilauea without any clean - was flooded with errors. A look in the log reveals, that it is trying to call ppc_4xx-gcc with arm options. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-arm pull request
On Sun, 31 Aug 2008, Jean-Christophe PLAGNIOL-VILLARD wrote: Hi Wolfgang, please pull The following changes since commit 33aa4eac66b71c797bbc13b3afe432a2132947d4: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm.git master Guennadi Liakhovetski (7): ARM: Add arm1176 core with S3C6400 SoC USB: Add support for OHCI controller on S3C6400 serial: add S3C64XX serial driver S3C64XX: remove broken HWFLOW support from the serial driver NAND: add NAND driver for S3C64XX ARM: Add support for S3C6400 based SMDK6400 board smdk6400: remove redundant bootargs definition Just tested on smdk6400 with the current arm/master HEAD - not good, the board just reboots somewhere near / after NAND-probe. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] Unify active vs. redundant environment variable naming
On Sun, 31 Aug 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: Use consistent naming for active and redundant environment variables, remove redundant erase struct initialisation by using separate structs for the active and redundant environments. This is another sylistic change that is IMHO not justified by any functional improvements or code fixes. If you are woking on other people's code you will have to accept that these other people have other preferences for variable names and the like. Reformatting the code and renaming variables just to make it better match your own style is IMHO not justified. Your new code gets longer, you even have to split a couple of lines because of that. That's not an improvement to me. It's not purely stylistic. For example, previously the code had fd and fdr, curdev and otherdev. It used one erase struct for both main and redundant copies, thus they had to initialise it multiple times to one or another version. I separated it into two erase_current and erase_target thus removing the need for multiple initialisation. I think, having dev_target, erase_target, fd_target vs. dev_current, erase_current and fd_current is also a readability improvement. I reject this patch. Please, reconsider. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] Support environment anywhere within erase area
On Sun, 31 Aug 2008, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message [EMAIL PROTECTED] you wrote:
This will become more important with NAND support, in which case the minimum
erase region is a block, which consists of several pages and can be 256KiB
large.
Please explain.
What does anywhere mean? At offset 0, 1, 5, 17 or 42? Or what? And
what exactly is the erase area ?
Yes, at any offset. I hope, everybody will not start from tomorrow putting
their environment at offset 17, but this is supported by this tool now,
yes.
Erase area - this is all we erase, as opposed to one erase sector. On NOR
this is limited by the environment size, on NAND by the number of blocks -
the fifth parameter in the configuration file. This area may contain other
useful data, which is first read in, then the whole area is erased, the
environment is replaced in the read-in data, and it is written back - this
is what I call the back-up process in the code.
And where's the difference between NAND and NOR flash? For NOR, the
minimum erase region is a block, either, which also can be 256KiB
large.
This patch enables this for NOR - NAND support comes first with patch 6.
So, it just enables placing the actual environment at any offset in the
erase area.
+ /*
+* Support environment anywhere within erase sectors: read out the
+* complete area to be erased, replace the environment image, write
+* the whole block back again.
+*/
This comment should actually serve as an explanation...
+ if (DEVESIZE (dev_target) CFG_ENV_SIZE) {
+ data = malloc (DEVESIZE (dev_target));
+ if (!data) {
+ fprintf (stderr,
+Cannot malloc %lu bytes: %s\n,
+DEVESIZE (dev_target),
+strerror (errno));
+ return -1;
+ }
+
+ rc = ioctl (fd_target, MEMGETINFO, mtdinfo_target);
+ if (rc 0) {
+ perror (Cannot get MTD information);
+ return -1;
+ }
+
+ /* Erase sector size is always a power of 2 */
+ erase_offset = DEVOFFSET (dev_target)
+ ~(mtdinfo_target.erasesize - 1);
+
+ rc = flash_read_buf (dev_target, fd_target, data,
+DEVESIZE (dev_target), erase_offset);
+ if (rc 0)
+ return rc;
+
+ /* Overwrite the old environment */
+ memcpy(DEVOFFSET (dev_target) - erase_offset + data,
+ environment.image, CFG_ENV_SIZE);
+ } else {
+ data = (char *)environment.image;
+ erase_offset = DEVOFFSET (dev_target);
+ }
You are talking about several pages above. Where is this refelected
in the code?
You mean in the commit comment? There I am talking about the future code -
NAND case, which is not yet in this patch.
Frankly, I don't understand what you are trying to do. Please explain
your implementation.
Hope, it is a bit clearer now. If not, please ask, will try to explain
again.
Indeed, this patch series changes the programme in a non-trivial way,
that's why I had to split this NAND-support into several patches, still
some of them seem to be not clear enough.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] Separate flash read and write operations
On Sun, 31 Aug 2008, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message [EMAIL PROTECTED] you wrote:
So, no, this is not because I didn't like somebody else's coding style.
This is because with NAND addition this function would become an
absolutely unreadable monster. So, I would consider this patch a
readability improvement.
But you are duplicating code. It may be just 20 lines or so, but the
better approach would be to leave the common code as is and factor
out two new functions being called from the common code.
Yes, the original code was:
...
flash_io(O_RDONLY);
...
flash_io(O_RDONLY);
...
flash_io(O_RDWR);
int flash_io(int mode)
{
fd = open(path, mode);
if (mode == O_RDONLY) {
...
} else {
...
}
close(fd);
}
I changed it to
...
flash_read();
...
flash_read();
...
flash_write();
...
int flash_read(void)
{
fd = open(path, O_RDONLY);
...
close(fd);
}
int flash_write(void)
{
fd = open(path, O_RDWR);
...
close(fd);
}
yes, I thus duplicate open and close. We could do
...
flash_io(O_RDONLY);
...
flash_io(O_RDONLY);
...
flash_io(O_RDWR);
int flash_io(int mode)
{
fd = open(path, mode);
if (mode == O_RDONLY) {
do_flash_read(fd);
} else {
do_flash_write(fd);
}
close(fd);
}
but, honestly, I prefer my version. If you disagree, I can change it to
variant 3, no problem. This will mean redoing all patches 2-6 though...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
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: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Support NAND in fw_printenv/fw_setenv
On Sun, 31 Aug 2008, Wolfgang Denk wrote: Dear Guennadi Liakhovetski, In message [EMAIL PROTECTED] you wrote: What follows is a patch series to support NAND environment under Linux, including bad blocks. In principle, this is just one logical change, but it is a big one... So I split it into 6 smaller patches, which should be easier to review. Tested with and without redundant environment, with an injected bad block, crossing block border, read and write. I just tried building for older kernels - it doesn't work: - make env MTD_VERSION=old make -C tools/env all MTD_VERSION=old || exit 1 make[1]: Entering directory `/home/wd/git/u-boot/tmp/tools/env' ppc_8xx-gcc -Wall -DUSE_HOSTCC -I/home/wd/git/u-boot/tmp/include -DMTD_OLD crc32.c fw_env.c fw_env_main.c -o fw_printenv In file included from /home/wd/git/u-boot/tmp/include/linux/mtd/mtd.h:13, from fw_env.c:36: /home/wd/git/u-boot/tmp/include/linux/mtd/mtd-abi.h:15: error: parse error before uint32_t /home/wd/git/u-boot/tmp/include/linux/mtd/mtd-abi.h:15: warning: no semicolon at end of struct or union /home/wd/git/u-boot/tmp/include/linux/mtd/mtd-abi.h:16: warning: type defaults to `int' in declaration of `length' /home/wd/git/u-boot/tmp/include/linux/mtd/mtd-abi.h:16: warning: data definition has no type or storage class ... Ok, how about this: we leave the current fw_env.c as it is, I submit _exactly_ the state after applying my 6 patches as a new file, with suitable changes to the Makefile, fix building with MTD_VERSION=old, and try to improve comments in the code. Would this be accepted? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. 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: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] Support environment in NAND
On Sun, 31 Aug 2008, Wolfgang Denk wrote:
Dear Guennadi Liakhovetski,
In message [EMAIL PROTECTED] you wrote:
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -44,6 +44,12 @@
#defineCMD_GETENV fw_printenv
#defineCMD_SETENV fw_setenv
+#define min(x, y) ({ \
+ typeof(x) _min1 = (x); \
+ typeof(y) _min2 = (y); \
+ (void) (_min1 == _min2); \
What does this do?
This min definition is copied from Linux. This useless comparison
operation forces the compiler to verify type compatibility of the two
parameters.
+ _min1 _min2 ? _min1 : _min2; })
typedef struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
@@ -413,179 +419,290 @@ int fw_setenv (int argc, char *argv[])
return 0;
}
+static int flash_bad_block (int dev, int fd, struct mtd_info_user *mtdinfo,
+ loff_t *blockstart, size_t blocklen)
+{
+ if (mtdinfo-type == MTD_NANDFLASH) {
+ int badblock = ioctl (fd, MEMGETBADBLOCK, blockstart);
+
+ if (badblock 0) {
+ perror (Cannot read bad block mark);
It would be probably helpful to print the block address.
Ok, can do.
+ return badblock;
+ }
+
+ if (badblock) {
+ fprintf (stderr, Bad block at 0x%llx,
+skipping\n, *blockstart);
+ *blockstart += blocklen;
+ return badblock;
+ }
+ }
+
+ return 0;
+}
+
+/*
+ * We are called with count == 0 for backing up as much data from the
+ * range as possible
+ */
Backing up?
As explained before - I am preserving the data outside of the environment
and I call this procedure backing-up.
static int flash_read_buf (int dev, int fd, void *buf, size_t count,
- off_t offset)
+ off_t offset, size_t range)
{
+ struct mtd_info_user mtdinfo;
+ size_t blocklen, processed = 0;
+ size_t readlen = count ? : range;
+ off_t erase_offset, block_seek;
+ loff_t blockstart;
int rc;
+ int backup_mode = !count;
backup_mode ?
I think there should be an explanation what exactly you are trying to
do.
I'll try to improve comments.
- rc = lseek (fd, offset, SEEK_SET);
- if (rc == -1) {
- fprintf (stderr,
-seek error on %s: %s\n,
-DEVNAME (dev), strerror (errno));
+ if (!count)
+ count = range;
+
+ rc = ioctl (fd, MEMGETINFO, mtdinfo);
+ if (rc 0) {
+ perror (Cannot get MTD information);
return rc;
}
Did you verify that the code still builds when MTD_OLD is set?
No. If we separate the NAND tool - does it still have to build with this
flag? Will anyone want to build it with older kernels?
- rc = read (fd, buf, count);
- if (rc != count) {
- fprintf (stderr,
-Read error on %s: %s\n,
-DEVNAME (dev), strerror (errno));
- return -1;
+ /* Erase sector size is always a power of 2 */
+ erase_offset = offset ~(mtdinfo.erasesize - 1);
Please explain this logic.
Ok, will do.
+ blockstart = erase_offset;
+ /* Offset inside a block */
+ block_seek = offset - erase_offset;
+
+ if (mtdinfo.type == MTD_NANDFLASH) {
+ /*
+* NAND: calculate which blocks we are reading. We have
+* to read one block at a time to skip bad blocks.
+*/
+ blocklen = mtdinfo.erasesize;
+ /* Limit to one block for the first read */
+ if (readlen blocklen - block_seek)
+ readlen = blocklen - block_seek;
+ } else {
+ blocklen = 0;
}
- return rc;
+ /* This only runs once for NOR flash */
+ while (processed count) {
+ rc = flash_bad_block (dev, fd, mtdinfo, blockstart, blocklen);
But - NOR flash does not have bad block, so all of this is not needed
at all?
See function implementation. It just returns 0 in non-NAND case. There are
two possibilities: either
if (NAND)
verify_bad_block();
or
verify_bad_block();
int verify_bad_block()
{
if (!NAND)
return 0;
...
}
in Linux the latter is generally preferred, as it doesn't clutter the
caller's flow.
+ if (rc 0)
+ return -1;
+ else if (blockstart + block_seek + readlen offset + range) {
I do not understand what you are doing here. Comment?
The comment is one line below:
+ /* End of range is reached */
If this is not enough, I can try to improve it.
+ if (backup_mode
[U-Boot] [PATCH 6/6 v2] Support environment in NAND
Add support for environment in NAND with automatic recognition, including
unaligned environment, bad-block skipping, redundant environment copy.
A new parameter is introduced to limit the number of sectors that may be
used on NAND, when skipping bad blocks, it is unused on NOR.
Take care to preserve backwards compatibility on NOR, including identical
erase / write behaviour.
Also fix some return codes.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
I am not resending patches 1-5, they remain unchanged.
Changes since v1: instead of abusing the erase sector size parameter on
NAND and retrieving it from the kernel, switched back to using
user-provided erase size, and introduced a new parameter for the number of
sectors, that can be used.
tools/env/README|6 +
tools/env/fw_env.c | 504 +--
tools/env/fw_env.config |6 +-
3 files changed, 365 insertions(+), 151 deletions(-)
diff --git a/tools/env/README b/tools/env/README
index f8a644e..f32f872 100644
--- a/tools/env/README
+++ b/tools/env/README
@@ -22,9 +22,11 @@ following lines are relevant:
#define DEVICE1_OFFSET0x
#define ENV1_SIZE 0x4000
#define DEVICE1_ESIZE 0x4000
+#define DEVICE1_ENVSECTORS 2
#define DEVICE2_OFFSET0x
#define ENV2_SIZE 0x4000
#define DEVICE2_ESIZE 0x4000
+#define DEVICE2_ENVSECTORS 2
Current configuration matches the environment layout of the TRAB
board.
@@ -46,3 +48,7 @@ then 1 sector.
DEVICEx_ESIZE defines the size of the first sector in the flash
partition where the environment resides.
+
+DEVICEx_ENVSECTORS defines the number of sectors that may be used for
+this environment instance. On NAND this is used to limit the range
+within which bad blocks are skipped, on NOR it is unused.
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 931e647..9adfdad 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -44,11 +44,18 @@
#defineCMD_GETENV fw_printenv
#defineCMD_SETENV fw_setenv
+#define min(x, y) ({ \
+ typeof(x) _min1 = (x); \
+ typeof(y) _min2 = (y); \
+ (void) (_min1 == _min2); \
+ _min1 _min2 ? _min1 : _min2; })
+
typedef struct envdev_s {
char devname[16]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
+ ulong env_sectors; /* number of environment sectors */
} envdev_t;
static envdev_t envdevices[2];
@@ -58,6 +65,7 @@ static int dev_current;
#define DEVOFFSET(i) envdevices[(i)].devoff
#define ENVSIZE(i)envdevices[(i)].env_size
#define DEVESIZE(i) envdevices[(i)].erase_size
+#define ENVSECTORS(i) envdevices[(i)].env_sectors
#define CFG_ENV_SIZE ENVSIZE(dev_current)
@@ -88,6 +96,7 @@ static int HaveRedundEnv = 0;
#define ENV_FLAGS(e) e.image-redund.flags
static unsigned char active_flag = 1;
+/* obsolete_flag must be 0 to efficiently set it on NOR flash without erasing
*/
static unsigned char obsolete_flag = 0;
@@ -309,11 +318,12 @@ int fw_setenv (int argc, char *argv[])
char *name;
if (argc 2) {
- return EINVAL;
+ errno = EINVAL;
+ return -1;
}
if (env_init ())
- return errno;
+ return -1;
name = argv[1];
@@ -325,7 +335,8 @@ int fw_setenv (int argc, char *argv[])
if (nxt = environment.data[ENV_SIZE]) {
fprintf (stderr, ## Error:
environment not terminated\n);
- return EINVAL;
+ errno = EINVAL;
+ return -1;
}
}
if ((oldval = envmatch (name, env)) != NULL)
@@ -342,7 +353,8 @@ int fw_setenv (int argc, char *argv[])
if ((strcmp (name, ethaddr) == 0) ||
(strcmp (name, serial#) == 0)) {
fprintf (stderr, Can't overwrite \%s\\n, name);
- return EROFS;
+ errno = EROFS;
+ return -1;
}
if (*++nxt == '\0') {
@@ -413,179 +425,366 @@ int fw_setenv (int argc, char *argv[])
return 0;
}
+static int flash_bad_block (int dev, int fd, struct mtd_info_user *mtdinfo,
+ loff_t *blockstart, size_t blocklen)
+{
+ if (mtdinfo-type == MTD_NANDFLASH) {
+ int badblock = ioctl (fd, MEMGETBADBLOCK, blockstart);
+
+ if (badblock 0) {
+ perror (Cannot read bad block mark);
+ return badblock
[U-Boot] [PATCH] S3C64XX: remove broken HWFLOW support from the serial driver
As noted by Harald Welte, HWFLOW support in the S3C64XX serial driver is
broken and currently unused. Remove it.
Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
---
As well as the previous patch, please, apply after the s3c64xx / smdk6400
support is merged in.
diff --git a/drivers/serial/s3c64xx.c b/drivers/serial/s3c64xx.c
index ea6eb4b..9d8fcb9 100644
--- a/drivers/serial/s3c64xx.c
+++ b/drivers/serial/s3c64xx.c
@@ -119,22 +119,6 @@ int serial_getc(void)
return uart-URXH 0xff;
}
-#ifdef CONFIG_HWFLOW
-static int hwflow; /* turned off by default */
-int hwflow_onoff(int on)
-{
- switch (on) {
- case 1:
- hwflow = 1; /* turn on */
- break;
- case -1:
- hwflow = 0; /* turn off */
- break;
- }
- return hwflow;
-}
-#endif
-
#ifdef CONFIG_MODEM_SUPPORT
static int be_quiet;
void disable_putc(void)
@@ -164,11 +148,6 @@ void serial_putc(const char c)
/* wait for room in the tx FIFO */
while (!(uart-UTRSTAT 0x2));
-#ifdef CONFIG_HWFLOW
- /* Wait for CTS up */
- while (hwflow !(uart-UMSTAT 0x1));
-#endif
-
uart-UTXH = c;
/* If \n, also do \r */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
