[U-Boot] [PATCH 01/11] arm: pxa: clean-up include file order
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
arch/arm/cpu/pxa/pxa2xx.c | 4 ++-- arch/arm/cpu/pxa/timer.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c index 7e861e2..2f12fb9 100644 --- a/arch/arm/cpu/pxa/pxa2xx.c +++ b/arch/arm/cpu/pxa/pxa2xx.c @@ -10,11 +10,11 @@ * SPDX-License-Identifier: GPL-2.0+ */
+#include <common.h> +#include <asm/arch/pxa-regs.h> #include <asm/io.h> #include <asm/system.h> #include <command.h> -#include <common.h> -#include <asm/arch/pxa-regs.h>
/* Flush I/D-cache */ static void cache_flush(void) diff --git a/arch/arm/cpu/pxa/timer.c b/arch/arm/cpu/pxa/timer.c index 11fefd5..7c25e67 100644 --- a/arch/arm/cpu/pxa/timer.c +++ b/arch/arm/cpu/pxa/timer.c @@ -6,8 +6,8 @@ * SPDX-License-Identifier: GPL-2.0+ */
-#include <asm/io.h> #include <common.h> +#include <asm/io.h>
DECLARE_GLOBAL_DATA_PTR;
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
drivers/mmc/pxa_mmc_gen.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/pxa_mmc_gen.c b/drivers/mmc/pxa_mmc_gen.c index 25ab0b1..19ae81d 100644 --- a/drivers/mmc/pxa_mmc_gen.c +++ b/drivers/mmc/pxa_mmc_gen.c @@ -6,15 +6,13 @@ * SPDX-License-Identifier: GPL-2.0+ */
-#include <config.h> #include <common.h> -#include <malloc.h> - -#include <mmc.h> -#include <asm/errno.h> #include <asm/arch/hardware.h> #include <asm/arch/regs-mmc.h> +#include <asm/errno.h> #include <asm/io.h> +#include <malloc.h> +#include <mmc.h>
/* PXAMMC Generic default config for various CPUs */ #if defined(CONFIG_CPU_PXA25X)
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
drivers/mmc/tegra_mmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c index 6f8b4d0..078df39 100644 --- a/drivers/mmc/tegra_mmc.c +++ b/drivers/mmc/tegra_mmc.c @@ -7,14 +7,14 @@ * SPDX-License-Identifier: GPL-2.0+ */
-#include <bouncebuf.h> #include <common.h> -#include <asm/gpio.h> -#include <asm/io.h> #include <asm/arch/clock.h> #include <asm/arch-tegra/clk_rst.h> #include <asm/arch-tegra/mmc.h> #include <asm/arch-tegra/tegra_mmc.h> +#include <asm/gpio.h> +#include <asm/io.h> +#include <bouncebuf.h> #include <mmc.h>
DECLARE_GLOBAL_DATA_PTR;
Hi Marcel,
On 15 August 2015 at 20:16, Marcel Ziswiler marcel@ziswiler.com wrote:
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com
drivers/mmc/tegra_mmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c index 6f8b4d0..078df39 100644 --- a/drivers/mmc/tegra_mmc.c +++ b/drivers/mmc/tegra_mmc.c @@ -7,14 +7,14 @@
- SPDX-License-Identifier: GPL-2.0+
*/
-#include <bouncebuf.h> #include <common.h> -#include <asm/gpio.h> -#include <asm/io.h> #include <asm/arch/clock.h> #include <asm/arch-tegra/clk_rst.h> #include <asm/arch-tegra/mmc.h> #include <asm/arch-tegra/tegra_mmc.h> +#include <asm/gpio.h> +#include <asm/io.h> +#include <bouncebuf.h> #include <mmc.h>
DECLARE_GLOBAL_DATA_PTR;
2.4.3
Thanks for tidying this up. But the ordering should be:
<common.h> <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h"
Regards, Simon
On Sun, 2015-08-16 at 15:11 -0600, Simon Glass wrote:
Thanks for tidying this up. But the ordering should be:
<common.h> <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h"
Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?
Hi Marcel,
On 16 August 2015 at 15:19, Marcel Ziswiler marcel@ziswiler.com wrote:
On Sun, 2015-08-16 at 15:11 -0600, Simon Glass wrote:
Thanks for tidying this up. But the ordering should be:
<common.h> <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h"
Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?
I originally got it from here (and another thread I can't find):
http://lists.denx.de/pipermail/u-boot/2012-January/114965.html
Regards, Simon
On Sun, 2015-08-16 at 15:26 -0600, Simon Glass wrote:
Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?
I originally got it from here (and another thread I can't find):
http://lists.denx.de/pipermail/u-boot/2012-January/114965.html
Hm, interesting. But that one suggests a different order yet again. Unfortunately it misses giving any reason for any of this. Me seriously wondering now.
BTW: Marek was happy with my order of things for the PXA stuff:
http://git.denx.de/?p=u-boot/u-boot-pxa.git;a=commitdiff;h=940ed38dd673 ecfbe03ed5e36c25bc4238356947
Marcel,
-----Original Message----- From: Marcel Ziswiler [mailto:marcel@ziswiler.com] Sent: Sunday, August 16, 2015 2:34 PM To: Simon Glass Cc: U-Boot Mailing List; Tom Warren; Pantelis Antoniou; Tom Rini; Albert Aribaud; Stephen Warren Subject: Re: [PATCH 03/11] arm: tegra: mmc: clean-up include file order
On Sun, 2015-08-16 at 15:26 -0600, Simon Glass wrote:
Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?
I originally got it from here (and another thread I can't find):
http://lists.denx.de/pipermail/u-boot/2012-January/114965.html
Hm, interesting. But that one suggests a different order yet again. Unfortunately it misses giving any reason for any of this. Me seriously wondering now.
BTW: Marek was happy with my order of things for the PXA stuff:
http://git.denx.de/?p=u-boot/u-boot-pxa.git;a=commitdiff;h=940ed38dd673 ecfbe03ed5e36c25bc4238356947
I have no problem with this sort order. Let me know if you want me to take this in to Tegra or if it should go into u-boot-mmc tree via Panto.
Tom -- nvpublic
On Mon, 2015-08-17 at 20:55 +0000, Tom Warren wrote:
I have no problem with this sort order. Let me know if you want me to take this in to Tegra or if it should go into u-boot-mmc tree via Panto.
I would be OK either way but as Panto has not responded I would be more than grateful if you can pull it in.
Thanks, Tom.
Hi Marcel,
On 16 August 2015 at 15:34, Marcel Ziswiler marcel@ziswiler.com wrote:
On Sun, 2015-08-16 at 15:26 -0600, Simon Glass wrote:
Says who? I was only aware that common.h needs to go on top, the local stuff (e.g. in double quotes) on the bottom and the rest I assumed can go alphabetically ordered in between, not?
I originally got it from here (and another thread I can't find):
http://lists.denx.de/pipermail/u-boot/2012-January/114965.html
Hm, interesting. But that one suggests a different order yet again. Unfortunately it misses giving any reason for any of this. Me seriously wondering now.
BTW: Marek was happy with my order of things for the PXA stuff:
http://git.denx.de/?p=u-boot/u-boot-pxa.git;a=commitdiff;h=940ed38dd673 ecfbe03ed5e36c25bc4238356947
The nice thing about sorting things in groups is that you can see at a glance what is missing. It doesn't make sense to have:
<asm/aaa.h> <bbb.c> <asm/ccc.h>
since the asm/ includes are quite a different category.
Regards, Simon
On Mon, 2015-08-17 at 16:14 -0600, Simon Glass wrote:
The nice thing about sorting things in groups is that you can see at a glance what is missing. It doesn't make sense to have:
<asm/aaa.h> <bbb.c> <asm/ccc.h>
since the asm/ includes are quite a different category.
But that's not at all what I proposed. What I was talking about looks as follows:
<common.h> <asm/aaa.h> <asm/ccc.h> <bbb.c> <linux/aaa.h> "local.h"
Which is exactly what I actually did in the patch we are talking about.
OK, I agree that there seems to be one nitty-gritty detail concerning the sort order of - aka dash vs. / aka slash going back to GNU sort (which is what I used) not seeming to enforce the same but I actually see that as a minor detail.
Hi Marcel,
On 18 August 2015 at 02:11, Marcel Ziswiler marcel@ziswiler.com wrote:
On Mon, 2015-08-17 at 16:14 -0600, Simon Glass wrote:
The nice thing about sorting things in groups is that you can see at a glance what is missing. It doesn't make sense to have:
<asm/aaa.h> <bbb.c> <asm/ccc.h>
since the asm/ includes are quite a different category.
But that's not at all what I proposed. What I was talking about looks as follows:
<common.h> <asm/aaa.h> <asm/ccc.h> <bbb.c> <linux/aaa.h> "local.h"
Which is exactly what I actually did in the patch we are talking about.
OK, I agree that there seems to be one nitty-gritty detail concerning the sort order of - aka dash vs. / aka slash going back to GNU sort (which is what I used) not seeming to enforce the same but I actually see that as a minor detail.
No I think you misunderstand. Another way of explaining this is sorting fruit and animals:
apple grapefruit orange elephant lion zebra
We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.
This is not a case of running 'sort' on the includes. The 'asm' files are arch-specific includes and should go after all the 'generic' includes, like <bbb.c>, etc.
So to repeat, the ordering should be:
<common.h> <- most general <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h" <- least general
Regards, Simon
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: Tuesday, August 18, 2015 5:44 AM To: Marcel Ziswiler Cc: U-Boot Mailing List; Tom Warren; Pantelis Antoniou; Tom Rini; Albert Aribaud; Stephen Warren Subject: Re: [PATCH 03/11] arm: tegra: mmc: clean-up include file order
Hi Marcel,
On 18 August 2015 at 02:11, Marcel Ziswiler marcel@ziswiler.com wrote:
On Mon, 2015-08-17 at 16:14 -0600, Simon Glass wrote:
The nice thing about sorting things in groups is that you can see at a glance what is missing. It doesn't make sense to have:
<asm/aaa.h> <bbb.c> <asm/ccc.h>
since the asm/ includes are quite a different category.
But that's not at all what I proposed. What I was talking about looks as follows:
<common.h> <asm/aaa.h> <asm/ccc.h> <bbb.c> <linux/aaa.h> "local.h"
Which is exactly what I actually did in the patch we are talking about.
OK, I agree that there seems to be one nitty-gritty detail concerning the sort order of - aka dash vs. / aka slash going back to GNU sort (which is what I used) not seeming to enforce the same but I actually see that as a minor detail.
No I think you misunderstand. Another way of explaining this is sorting fruit and animals:
apple grapefruit orange elephant lion zebra
We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.
This is not a case of running 'sort' on the includes. The 'asm' files are arch- specific includes and should go after all the 'generic' includes, like <bbb.c>, etc.
So to repeat, the ordering should be:
<common.h> <- most general <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h" <- least general
Regards, Simon
After reading Simon's latest explanation, I tend to agree with him. Marcel - I'll wait until this is amicably resolved and then I'll apply whatever you come up with to the Tegra repo.
Tom -- nvpublic
On 18 August 2015 14:44:01 CEST, Simon Glass sjg@chromium.org wrote:
No I think you misunderstand. Another way of explaining this is sorting fruit and animals:
apple grapefruit orange elephant lion zebra
We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.
I see but I still don't think your example matches our problem at hand quite that accurately.
This is not a case of running 'sort' on the includes. The 'asm' files are arch-specific includes and should go after all the 'generic' includes, like <bbb.c>, etc.
So to repeat, the ordering should be:
<common.h> <- most general <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h" <- least general
Your proposal sounds quite honourable but the problem I see with it is that your order is based on some generality rule I don't quite see where it could be looked up.
At the end I believe the order actually does not even matter apart from U-Boot's special common.h having to go first. And even that could be worked around by the build system itself (see e.g. Linux kernel for that matter).
So for me such ordering is just cosmetic and might at best help us humble programmers when comparing stuff or looking through to make sure a certain include is indeed already there or the like.
The only practical way I see to achieve this would be to plain simply alphabetically sort them.
As I don't think this is much worth discussing any further I'm fine with dropping this patch even though I actually think the actual file in question is seriously buggy as it does not put common.h first.
Hi Marcel,
On 19 August 2015 at 10:00, Marcel Ziswiler marcel@ziswiler.com wrote:
On 18 August 2015 14:44:01 CEST, Simon Glass sjg@chromium.org wrote:
No I think you misunderstand. Another way of explaining this is sorting fruit and animals:
apple grapefruit orange elephant lion zebra
We don't want to mix up the fruit and animals, so each has its own position in the table.We can then easily see what animals are in the table.
I see but I still don't think your example matches our problem at hand quite that accurately.
This is not a case of running 'sort' on the includes. The 'asm' files are arch-specific includes and should go after all the 'generic' includes, like <bbb.c>, etc.
So to repeat, the ordering should be:
<common.h> <- most general <others.h> <asm/...> <arch/arm/...> <linux/...> "local.h" <- least general
Your proposal sounds quite honourable but the problem I see with it is that your order is based on some generality rule I don't quite see where it could be looked up.
At the end I believe the order actually does not even matter apart from U-Boot's special common.h having to go first. And even that could be worked around by the build system itself (see e.g. Linux kernel for that matter).
So for me such ordering is just cosmetic and might at best help us humble programmers when comparing stuff or looking through to make sure a certain include is indeed already there or the like.
The only practical way I see to achieve this would be to plain simply alphabetically sort them.
As I don't think this is much worth discussing any further I'm fine with dropping this patch even though I actually think the actual file in question is seriously buggy as it does not put common.h first.
As you say the compiler doesn't care about the order apart from common.h. But the code is written as much for us software engineers as the compiler. Linux puts the asm includes at the end and we more-or-less follow this in U-Boot.
I don't want to be annoying and this is Tegra code so I will leave it to you and Tom to sort out.
Regards, Simon
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
drivers/serial/serial_pxa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_pxa.c b/drivers/serial/serial_pxa.c index d514004..8fbcc10 100644 --- a/drivers/serial/serial_pxa.c +++ b/drivers/serial/serial_pxa.c @@ -18,12 +18,12 @@ */
#include <common.h> -#include <watchdog.h> -#include <serial.h> #include <asm/arch/pxa-regs.h> #include <asm/arch/regs-uart.h> #include <asm/io.h> #include <linux/compiler.h> +#include <serial.h> +#include <watchdog.h>
DECLARE_GLOBAL_DATA_PTR;
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
drivers/usb/gadget/pxa27x_udc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c index 9423555..c7b21ae 100644 --- a/drivers/usb/gadget/pxa27x_udc.c +++ b/drivers/usb/gadget/pxa27x_udc.c @@ -10,11 +10,10 @@
#include <common.h> -#include <config.h> -#include <asm/byteorder.h> -#include <usbdevice.h> #include <asm/arch/hardware.h> +#include <asm/byteorder.h> #include <asm/io.h> +#include <usbdevice.h> #include <usb/pxa27x_udc.h> #include <usb/udc.h>
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
drivers/video/pxa_lcd.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/pxa_lcd.c b/drivers/video/pxa_lcd.c index 64cef37..2799425 100644 --- a/drivers/video/pxa_lcd.c +++ b/drivers/video/pxa_lcd.c @@ -11,14 +11,13 @@ /* ** HEADER FILES */ /************************************************************************/
-#include <config.h> #include <common.h> -#include <stdarg.h> -#include <linux/types.h> -#include <stdio_dev.h> -#include <lcd.h> #include <asm/arch/pxa-regs.h> #include <asm/io.h> +#include <lcd.h> +#include <linux/types.h> +#include <stdarg.h> +#include <stdio_dev.h>
/* #define DEBUG */
Fix boot hang caused by incompatible libgcc which has been observed when using later Linaro toolchains like gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux or gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
configs/colibri_pxa270_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/colibri_pxa270_defconfig b/configs/colibri_pxa270_defconfig index 3963a50..2ef9ccb 100644 --- a/configs/colibri_pxa270_defconfig +++ b/configs/colibri_pxa270_defconfig @@ -4,3 +4,4 @@ CONFIG_TARGET_COLIBRI_PXA270=y # CONFIG_CMD_LOADB is not set # CONFIG_CMD_LOADS is not set # CONFIG_CMD_SETEXPR is not set +CONFIG_USE_PRIVATE_LIBGCC=y
On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:
Fix boot hang caused by incompatible libgcc which has been observed when using later Linaro toolchains like gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux or gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.
That's no surprise, since U-Boot links libgcc into itself. And since PXA2xx is armv5-compatible, you'd need armv5 toolchain. The hang you're observing is most likely happening in some aeabi_* function pulled in from libgcc, which contains some armv7 instruction(s), which in turn upsets the xscale.
I would suggest that we drop this patch, but I would also suggest that we do the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC globally for everyone to break this constant nonsensical influx of toolchain-related problems. This nonsense has been dragging on for too long. Tom? Albert?
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com
configs/colibri_pxa270_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/colibri_pxa270_defconfig b/configs/colibri_pxa270_defconfig index 3963a50..2ef9ccb 100644 --- a/configs/colibri_pxa270_defconfig +++ b/configs/colibri_pxa270_defconfig @@ -4,3 +4,4 @@ CONFIG_TARGET_COLIBRI_PXA270=y # CONFIG_CMD_LOADB is not set # CONFIG_CMD_LOADS is not set # CONFIG_CMD_SETEXPR is not set +CONFIG_USE_PRIVATE_LIBGCC=y
Best regards, Marek Vasut
On 16 August 2015 05:31:58 CEST, Marek Vasut marex@denx.de wrote:
On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:
I would suggest that we drop this patch, but I would also suggest that we do the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC globally for everyone to break this constant nonsensical influx of toolchain-related problems. This nonsense has been dragging on for too long. Tom? Albert?
I don't really care how this gets fixed I just don't ever want to have to debug through that one ever again!
Thanks, Marek.
On Sunday, August 16, 2015 at 10:03:51 AM, Marcel Ziswiler wrote:
On 16 August 2015 05:31:58 CEST, Marek Vasut marex@denx.de wrote:
On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:
I would suggest that we drop this patch, but I would also suggest that we do the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC globally for everyone to break this constant nonsensical influx of toolchain-related problems. This nonsense has been dragging on for too long. Tom? Albert?
I don't really care how this gets fixed I just don't ever want to have to debug through that one ever again!
I've been there, multiple times. I can feel your pain, this is a terrible nastiness with the libgcc.
Thanks, Marek.
Best regards, Marek Vasut
Looks like the define CONFIG_SYS_LCD_PXA_NO_L_BIAS is not used anywhere else throughout the U-Boot sources any more. Drop it.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
include/configs/palmtreo680.h | 1 - 1 file changed, 1 deletion(-)
diff --git a/include/configs/palmtreo680.h b/include/configs/palmtreo680.h index 3946607..9842eb0 100644 --- a/include/configs/palmtreo680.h +++ b/include/configs/palmtreo680.h @@ -67,7 +67,6 @@ #define CONFIG_PXA_LCD #define CONFIG_ACX544AKN #define CONFIG_LCD_LOGO -#define CONFIG_SYS_LCD_PXA_NO_L_BIAS /* don't configure GPIO77 as L_BIAS */ #define LCD_BPP LCD_COLOR16 #define CONFIG_FB_ADDR 0x5c000000 /* internal SRAM */ #define CONFIG_CMD_BMP
Add some more NOR flash details like size, bus width and lock/unlock time outs.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
include/configs/colibri_pxa270.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h index e3f0ab0..08ebd76 100644 --- a/include/configs/colibri_pxa270.h +++ b/include/configs/colibri_pxa270.h @@ -121,16 +121,20 @@ */ #ifdef CONFIG_CMD_FLASH #define PHYS_FLASH_1 0x00000000 /* Flash Bank #1 */ +#define PHYS_FLASH_SIZE 0x02000000 /* 32 MB */ #define CONFIG_SYS_FLASH_BASE PHYS_FLASH_1
#define CONFIG_SYS_FLASH_CFI #define CONFIG_FLASH_CFI_DRIVER 1 +#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_32BIT
#define CONFIG_SYS_MAX_FLASH_SECT (4 + 255) #define CONFIG_SYS_MAX_FLASH_BANKS 1
#define CONFIG_SYS_FLASH_ERASE_TOUT (25 * CONFIG_SYS_HZ) #define CONFIG_SYS_FLASH_WRITE_TOUT (25 * CONFIG_SYS_HZ) +#define CONFIG_SYS_FLASH_LOCK_TOUT (25 * CONFIG_SYS_HZ) +#define CONFIG_SYS_FLASH_UNLOCK_TOUT (25 * CONFIG_SYS_HZ)
#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE 1 #define CONFIG_SYS_FLASH_PROTECTION 1
Add optional LCD support. Note that depending on the toolchain used one might have to drop some other features to stay within the 0x40000 size limit.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com ---
include/configs/colibri_pxa270.h | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h index 08ebd76..a8cdde5 100644 --- a/include/configs/colibri_pxa270.h +++ b/include/configs/colibri_pxa270.h @@ -19,6 +19,9 @@ /* Avoid overwriting factory configuration block */ #define CONFIG_BOARD_SIZE_LIMIT 0x40000
+/* We will never enable dcache because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF + /* * Environment settings */ @@ -56,6 +59,16 @@ #define CONFIG_CMD_MMC #define CONFIG_CMD_USB
+/* LCD support */ +#ifdef CONFIG_LCD +#define CONFIG_PXA_LCD +#define CONFIG_PXA_VGA +#define CONFIG_SYS_WHITE_ON_BLACK +#define CONFIG_CONSOLE_SCROLL_LINES 10 +#define CONFIG_CMD_BMP +#define CONFIG_LCD_LOGO +#endif + /* * Networking Configuration */
This is useful once Andrew's PXA I2C driver gets merged.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com
---
include/configs/colibri_pxa270.h | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h index a8cdde5..a250541 100644 --- a/include/configs/colibri_pxa270.h +++ b/include/configs/colibri_pxa270.h @@ -59,6 +59,15 @@ #define CONFIG_CMD_MMC #define CONFIG_CMD_USB
+/* I2C support */ +#ifdef CONFIG_SYS_I2C +#define CONFIG_CMD_I2C +#define CONFIG_SYS_I2C_PXA +#define CONFIG_PXA_STD_I2C +#define CONFIG_PXA_PWR_I2C +#define CONFIG_SYS_I2C_SPEED 100000 +#endif + /* LCD support */ #ifdef CONFIG_LCD #define CONFIG_PXA_LCD
On Sunday, August 16, 2015 at 04:16:26 AM, Marcel Ziswiler wrote:
Cleaning up order of include files by sorting them alphabetically keeping in mind to leave common.h on top.
Signed-off-by: Marcel Ziswiler marcel@ziswiler.com
I cannot find 03/11 , why ?
I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)
Best regards, Marek Vasut
On 16 August 2015 18:53:40 CEST, Marek Vasut marex@denx.de wrote:
I cannot find 03/11 , why ?
Ah, I believe that one is actually meant for Tegra rather than PXA and will hopefully be picked up by Tom.
I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)
Thanks, Marek. I hope we can sort out 07/11 soon as well.
BTW: I just got it booting Linux -next with a preliminary device tree I put together including NFSv4 mounted rootfs. Just wondering why there aren't any PXA device trees mainline yet.
On Sunday, August 16, 2015 at 07:16:09 PM, Marcel Ziswiler wrote:
On 16 August 2015 18:53:40 CEST, Marek Vasut marex@denx.de wrote:
I cannot find 03/11 , why ?
Ah, I believe that one is actually meant for Tegra rather than PXA and will hopefully be picked up by Tom.
Errr, right. What weird sort of battle tactics is this, are you trying to confuse the enemy with random unrelated patches right in the middle of a coherent series? :)
I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)
Thanks, Marek. I hope we can sort out 07/11 soon as well.
Well, I'm not so sure. But I'd definitelly be in favor of dropping our odd dependency on libgcc. It is just a hindrance and I fail to see the benefit.
BTW: I just got it booting Linux -next with a preliminary device tree I put together including NFSv4 mounted rootfs. Just wondering why there aren't any PXA device trees mainline yet.
I think Daniel Mack was the last one who worked on PXA DT support.
Best regards, Marek Vasut
On Sun, 2015-08-16 at 19:26 +0200, Marek Vasut wrote:
Errr, right. What weird sort of battle tactics is this, are you
trying to confuse the enemy with random unrelated patches right in the middle of a coherent series? :)
Yes, I agree. But I trusted it all into the hands of patman this time (;-p).
I think Daniel Mack was the last one who worked on PXA DT support.
Yes, I met him in Düsseldorf last year and later sent him a bunch of free hardware but he has been rather quiet since. Oh, well. Probably he is busy with his day job not touching much embedded stuff any more.
participants (4)
-
Marcel Ziswiler -
Marek Vasut -
Simon Glass -
Tom Warren