Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
> But what about the bad block markers , do they get erased when you write > this U-Boot image into the NAND ? The image includes OOB data, because the rom-mandated map is different from normal standards. If OOB is zeroed, blocks appear as bad (correctly!). By memsetting to 0xff, before filling data structures and checksums, we get a binary that written with "nand write.raw" works properly (the rom is happy with the format and boots) but doesn't mark blocks as bad. [actually, only the first half-a-meg is with-oob, the trailing part is not, and the image is partly written with "nand write.raw" and partly with "nand write". Hairy things based on hairy vendor choices in hw/rom] But tools/mxsboot works fine, and saved my day (or more). thanks /alessandro
Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
Hello. >>> pre-filling with 0xff creates a proper boot loader image, but no >>> bad-block marker is there when written to flash. > Isn't there some kobs-ng or whatever tool it was to properly initialize > the NAND on MXS ? I didn't know. I used what u-boot offers, which works for me without vendor tools -- and dare I say I trust u-boot tools more than vendor tools?. The default environment even has the rule to reflash from any u-boot.nand you manage to put into RAM. The only issue is that u-boot.nand, as created, marks good blocks as bad by prefilling with zeores. thanks /alessandro
[PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
The tool works for me, with imx28 and NAND memory, but the resulting
blocks are reported as bad, both by u-boot and the kernel.
This makes it impossible to erase from Linux (for an upgrade without
console access, for example -- u-boot can "nand scrub" but linux can't).
pre-filling with 0xff creates a proper boot loader image, but no
bad-block marker is there when written to flash.
Signed-off-by: Alessandro Rubini
---
tools/mxsboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 04d86f87a8..8f4018aa56 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -478,7 +478,7 @@ static int mx28_create_nand_image(int infd, int outfd)
goto err0;
}
- memset(buf, 0, size);
+ memset(buf, 0xff, size);
fcb = mx28_nand_get_fcb(MAX_BOOTSTREAM_SIZE);
if (!fcb) {
--
2.30.2
Re: [U-Boot] [PATCH 01/10] lcd, amba: remove this frame buffer driver since it is not used
Hello. > Since CONFIG_VIDEO_AMBA is not set by any board, it does not seem > to be used, so remove it since there is no way to (compile) test it. I used the driver on the nhk8815. But actually it looks like the "later patch in this set", that my commit message references, was not merged. I remember I used it in 32-bit mode and had to hack some things to make it work, inluding a fater memcopy as scrolling was very slow. I don't think I can resurrect my nhk8815 device any soon, and it looks like nobody else is using this logic cell, so I'm fine removing the driver. Acked-by: Alessandro Rubini /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nhk8815: fix build errors
Acked-by: Alessandro Rubini ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] arm: omap: innovator: Prepare for mach-types.h changes
I'm sorry for sounding rude, it's not my intention. I didn't follow closely the discussion about mach_types.h, but I think we are heading in the wrong direction. For example, this patch: > - if (machine_is_omap_h2()) > - gd->bd->bi_arch_number = MACH_TYPE_OMAP_H2; > - else if (machine_is_omap_innovator()) > - gd->bd->bi_arch_number = MACH_TYPE_OMAP_INNOVATOR; > - else > - gd->bd->bi_arch_number = MACH_TYPE_OMAP_GENERIC; > +#if defined(CONFIG_MACH_OMAP_H2) > + gd->bd->bi_arch_number = MACH_TYPE_OMAP_H2; > +#elif defined(CONFIG_MACH_OMAP_INNOVATOR) > + gd->bd->bi_arch_number = MACH_TYPE_OMAP_INNOVATOR; > +#else > + gd->bd->bi_arch_number = MACH_TYPE_OMAP_GENERIC; > +#endif Since when turning if into ifdef has been a wise move for maintainability? The commis says: > This board used machine_is_* macros for identifying the arch number. > Use compile time defines instead. But this already was compile-time: no code generated. But even if it generated code, I prefer 3 run-time comparisons than 3 compile-time ifdefs. Note that mach_types.h, as designed by Russell King, already had compile time selection, becuase if you selected one machine only (like in u-boot), one of the "if" becomes compile-time-true and the other ones become "0". I see a lot of discussion about checkpatch compliance and cleanup-only patches are being accepted; this goes in the opposite direction, for no reason apparent to me. thanks for your patience /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] at91sam9261/g10: move config from Makefile to boards.cfg
This moves config targets, but defines DATAFLASH_CS0 for "dataflash_cs0" configs and DATAFLASH_CS3 for "dataflash_cs3" configs, whereas the Makefile targets had it swapped. Signed-off-by: Alessandro Rubini --- Makefile | 22 -- boards.cfg |8 2 files changed, 8 insertions(+), 22 deletions(-) diff --git a/Makefile b/Makefile index 584105c..93c33c7 100644 --- a/Makefile +++ b/Makefile @@ -803,28 +803,6 @@ at91sam9xeek_config: unconfig fi; @$(MKCONFIG) -n $@ -a at91sam9260ek arm arm926ejs at91sam9260ek atmel at91 -at91sam9261ek_nandflash_config \ -at91sam9261ek_dataflash_cs0_config \ -at91sam9261ek_dataflash_cs3_config \ -at91sam9261ek_config \ -at91sam9g10ek_nandflash_config \ -at91sam9g10ek_dataflash_cs0_config \ -at91sam9g10ek_dataflash_cs3_config \ -at91sam9g10ek_config : unconfig - @mkdir -p $(obj)include - @if [ "$(findstring 9g10,$@)" ] ; then \ - echo "#define CONFIG_AT91SAM9G10EK 1" >>$(obj)include/config.h ; \ - else \ - echo "#define CONFIG_AT91SAM9261EK 1" >>$(obj)include/config.h ; \ - fi; - @if [ "$(findstring _nandflash,$@)" ] ; then \ - echo "#define CONFIG_SYS_USE_NANDFLASH 1" >>$(obj)include/config.h ; \ - elif [ "$(findstring dataflash_cs0,$@)" ] ; then \ - echo "#define CONFIG_SYS_USE_DATAFLASH_CS3 1" >>$(obj)include/config.h ; \ - else \ - echo "#define CONFIG_SYS_USE_DATAFLASH_CS0 1" >>$(obj)include/config.h ; \ - fi; - @$(MKCONFIG) -n $@ -a at91sam9261ek arm arm926ejs at91sam9261ek atmel at91 at91sam9263ek_norflash_config \ at91sam9263ek_norflash_boot_config \ diff --git a/boards.cfg b/boards.cfg index 9194610..80488b8 100644 --- a/boards.cfg +++ b/boards.cfg @@ -73,6 +73,14 @@ omap1510inn arm arm925t - ti aspenite arm arm926ejs - Marvellarmada100 afeb9260 arm arm926ejs - - at91 at91cap9adk arm arm926ejs - atmel at91 +at91sam9261ekarm arm926ejs - atmel at91at91sam9261ek:AT91SAM9261EK,SYS_USE_DATAFLASH_CS0 +at91sam9261ek_dataflash_cs0 arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9261EK,SYS_USE_DATAFLASH_CS0 +at91sam9261ek_dataflash_cs3 arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9261EK,SYS_USE_DATAFLASH_CS3 +at91sam9261ek_nandflash arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9261EK,SYS_USE_NANDFLASH +at91sam92g10ek arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9G10EK,SYS_USE_DATAFLASH_CS0 +at91sam92g10ek_dataflash_cs0 arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9G10EK,SYS_USE_DATAFLASH_CS0 +at91sam92g10ek_dataflash_cs3 arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9G10EK,SYS_USE_DATAFLASH_CS3 +at91sam92g10ek_nandflash arm arm926ejs - atmel at91at91sam9261ek:AT91SAM9G10EK,SYS_USE_NANDFLASH top9000eval_xe arm arm926ejs top9000 emk at91top9000:EVAL9000 top9000su_xe arm arm926ejs top9000 emk at91top9000:SU9000 meescarm arm926ejs - esd at91 -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] at91sam9261/g10: support relocation
This adds support for relocation, but won't work for the default
settings whereas AT91Boot loads u-boot to the last meg and it then
tries to relocate slightly later, thus overwriting itself.
Signed-off-by: Alessandro Rubini
---
board/atmel/at91sam9261ek/at91sam9261ek.c |3 +--
include/configs/at91sam9261ek.h |4
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/board/atmel/at91sam9261ek/at91sam9261ek.c
b/board/atmel/at91sam9261ek/at91sam9261ek.c
index de5cfae..ec1d2a3 100644
--- a/board/atmel/at91sam9261ek/at91sam9261ek.c
+++ b/board/atmel/at91sam9261ek/at91sam9261ek.c
@@ -273,8 +273,7 @@ int board_eth_init(bd_t *bis)
int dram_init(void)
{
- gd->bd->bi_dram[0].start = PHYS_SDRAM;
- gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+ gd->ram_size = get_ram_size(PHYS_SDRAM, PHYS_SDRAM_SIZE);
return 0;
}
diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h
index 401478b..71a4357 100644
--- a/include/configs/at91sam9261ek.h
+++ b/include/configs/at91sam9261ek.h
@@ -30,6 +30,7 @@
#define CONFIG_AT91_LEGACY
/* ARM asynchronous clock */
+#define CONFIG_AT91FAMILY
#define CONFIG_SYS_AT91_MAIN_CLOCK 18432000/* 18.432 MHz crystal */
#define CONFIG_SYS_HZ 1000
@@ -110,6 +111,9 @@
#define CONFIG_NR_DRAM_BANKS 1
#define PHYS_SDRAM 0x2000
#define PHYS_SDRAM_SIZE0x0400 /* 64 megs */
+#define CONFIG_SYS_SDRAM_BASE 0x2000
+#define CONFIG_SYS_INIT_SP_ADDR0x2010 /* within RAM
is ok */
+
/* DataFlash */
#define CONFIG_ATMEL_DATAFLASH_SPI
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: don't relocate if we are already too high
Signed-off-by: Alessandro Rubini
---
arch/arm/lib/board.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index dc46e21..dab70b5 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -423,8 +423,29 @@ void board_init_f (ulong bootflag)
gd->relocaddr = addr;
gd->start_addr_sp = addr_sp;
gd->reloc_off = addr - _TEXT_BASE;
+
+ /*
+* Destination is higher than current address, but may overlap
+* our address range. If so, pass the source address as destination
+* address so the asm will not relocate and only clear bss
+*/
+ if ((addr_sp - 256) < _bss_start_ofs+_TEXT_BASE) {
+ debug("Won't fit above us: disabling relocation\n");
+ if (gd->reloc_off < 0) {
+ printf("Can't relocate to lower ram, currently\n");
+ hang();
+ }
+ addr -= gd->reloc_off;
+ addr_sp -= gd->reloc_off;
+ gd->start_addr_sp = addr_sp;
+ id -= gd->reloc_off;
+ gd->reloc_off = 0;
+ }
+
+
debug ("relocation Offset is: %08lx\n", gd->reloc_off);
- memcpy (id, (void *)gd, sizeof (gd_t));
+ if (id != (void *)gd)
+ memcpy (id, (void *)gd, sizeof (gd_t));
relocate_code (addr_sp, id, addr);
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] atmel_dataflash: remove use of get_timer_masked
Commit 5dca710a3d7703e41da0e9894f2d71f9e25bea6b removed get_timer_masked for at91. The dataflash driver was still using it and so stopped compiling. This blindly fixes the compilation problem (I am not currently using dataflash). Signed-off-by: Alessandro Rubini --- drivers/spi/atmel_dataflash_spi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/atmel_dataflash_spi.c b/drivers/spi/atmel_dataflash_spi.c index 4a5c4aa..d5215c0 100644 --- a/drivers/spi/atmel_dataflash_spi.c +++ b/drivers/spi/atmel_dataflash_spi.c @@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc) } /* arm simple, non interrupt dependent timer */ - reset_timer_masked(); + reset_timer(); timeout = 0; writel(AT91_SPI_TXTEN + AT91_SPI_RXTEN, AT91_BASE_SPI + AT91_SPI_PTCR); while (!(readl(AT91_BASE_SPI + AT91_SPI_SR) & AT91_SPI_RXBUFF) && - ((timeout = get_timer_masked()) < CONFIG_SYS_SPI_WRITE_TOUT)); + ((timeout = get_timer(0)) < CONFIG_SYS_SPI_WRITE_TOUT)); writel(AT91_SPI_TXTDIS + AT91_SPI_RXTDIS, AT91_BASE_SPI + AT91_SPI_PTCR); pDesc->state = IDLE; -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about relocation
Me: >> but the calculation is done to move to end of ram, so dest is always >> higher than source. Albert: > I guess I can live with this if you put a big fat comment in the code to > explain *why* the copy is done end-to-beginning, so that if one day the > assumption stops holding, readers of the code can tell if they should > keep or change the direction. Actually, I was wrong. Since the display buffer is allocated over u-boot, we may already be too high. This never happens for current boards, which lived before relocation was there (I rember having lowered the u-boot address to fit a bigger display buffer above it) but may happen in the future. So, with the comment the thing may work (like "please for new boards load it low now that it relocates high by itself"). However, the copy is made in 35 assembly files. Only ARM has 14 almost-identical copies of the code (some of them are really identical), so I won't dare touching it. The only thing I can do is not making the copy by forcing dest = source if we will overlap ourselves, because the assembly will detect this: adr r0, _start cmp r0, r6 beq clear_bss /* skip relocation */ [I don't understand why here is _start and in C is _TEXT_BASE, which are different by 0x40 bytes, but it unexpectedly works] For me it is working, but the code is not clean at all. I'm sending the patches anyways. I found the the overwrite was only for the stack, which is the lowest address in the relocated place, so I compared some space below the would-be stack with bss_start. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about relocation
>> Ori, simply, end-to-beginning when moving up. Or always >> end-to-beginning since we are expected to always move up (upper than >> the target address it can't run). > Since the 'issue' is caused by the code assuming one direction, I'd > prefer it not to assume the other now; I prefer choosing > end-to-beginning if target is dest than source, beginning-to-end otherwise. but the calculation is done to move to end of ram, so dest is always higher than source. > Actually no, copying and fixing is not done in a single run. There is > the copying of the text+data+const area, then the fixing which runs > through the relocation table area; they are different. Yes, that's what I meant. It's not a memcpy, you also use the data after the copy so any overlap is an issue, indepentend of the order of copying. >> Or, easier: if we are already high enough to overlap, don't relocate >> at all. If it's acceptable, I'll patch for taht. > But then comes the question of how enough is "high enough". :) If there's no overlap, you can relocate. If the areas overal, you keep the current address which also is "high enough". If you ack (even offlist) I'll submit a patch tomorrow (monday) /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about relocation
> beginning-to-end copy or an end-to-beginning copy depending on the > source and destination addresses and size. Ori, simply, end-to-beginning when moving up. Or always end-to-beginning since we are expected to always move up (upper than the target address it can't run). It is safer, but not safe. Also, it's difficult to accomplish bcause copying and fixing addresses is done ina single run, so the relocation tables are read from the old area. Possibly relocatng first and copying then. Or, easier: if we are already high enough to overlap, don't relocate at all. If it's acceptable, I'll patch for taht. thanks /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: don't panic if no flash is there
> Sorry, but I reject this patch. Please let me restate the point once more. Maybe i've not been clear. > If you do not have NOR flash, then you should not enable it (and > define CONFIG_SYS_NO_FLASH). Otherwise, you are supposed to have > flash memory. I expect a serious boot loader to work in all possible situations and to be a development tool, the thing that was called a monitor ages ago (why do you have "mw" and "md" otherwise?). I've always loved u-boot usefulness as opposed to the crappy "do nothing at all" wince or freecale boot loaders. Thus, I see three reasons to revert the older behaviour. - even if flash got broken over time, the machine should be useable. hang() here gains nothing, as I may still be able to boot though the net and see what happens, without the need to recompile and reflesh a special recovery boot loader - during initial development it's common to have some parameter misconfigured (and thus see no flash) while still using u-boot to md/mw/whatever and see how's flash really mapepd. It makes no sense to be being forced to flash twice at each development loop (one trying new code and hang() and another to get an interactive session). - there may be board build both with and without NOR flash. On one side you added relocation to support boards with different memory sizes with a single u-boot binary, on the other you are now forbidding a single binary to work on two similar boards with a different set of peripherals. This is policy to me, and I see no reason to force policy in a boot loader. I expect only simple and uniform behaviour: do we hang() if no network is found? > If there are problems with the Qemu emulation of NOR flash these > should be fixed there. Sure, if you want flash. I'm not asking non-compliant code the be added in u-boot to deal with a flaky implementation elsewhere. I'd love a perfectly working, though incomplete, emulation to be supported just like real hardware prototypes with production bugs in the NOR mounting. Amicalment (even though this message sounds harsh it isn't meant to be) /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] versatile: support relocation
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
---
board/armltd/versatile/versatile.c |2 ++
include/configs/versatile.h|3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/board/armltd/versatile/versatile.c
b/board/armltd/versatile/versatile.c
index 6e836dd..deca47f 100644
--- a/board/armltd/versatile/versatile.c
+++ b/board/armltd/versatile/versatile.c
@@ -88,6 +88,8 @@ int misc_init_r (void)
**/
int dram_init (void)
{
+ gd->ram_size = get_ram_size(CONFIG_SYS_SDRAM_BASE,
+ CONFIG_SYS_SDRAM_SIZE);
return 0;
}
diff --git a/include/configs/versatile.h b/include/configs/versatile.h
index 45d8434..d883725 100644
--- a/include/configs/versatile.h
+++ b/include/configs/versatile.h
@@ -168,6 +168,9 @@
#define PHYS_SDRAM_1 0x /* SDRAM Bank #1 */
#define PHYS_SDRAM_1_SIZE 0x0800 /* 128 MB */
#define PHYS_FLASH_SIZE0x0400 /* 64MB */
+#define CONFIG_SYS_SDRAM_BASE 0x
+#define CONFIG_SYS_SDRAM_SIZE PHYS_SDRAM_1_SIZE
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000)
/*---
* FLASH and environment organization
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] versatile: use boards.confg
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
---
Makefile |9 --
board/armltd/versatile/split_by_variant.sh | 42
boards.cfg |5 ++-
3 files changed, 4 insertions(+), 52 deletions(-)
delete mode 100755 board/armltd/versatile/split_by_variant.sh
diff --git a/Makefile b/Makefile
index 93c33c7..bbd2e9c 100644
--- a/Makefile
+++ b/Makefile
@@ -998,15 +998,6 @@ edb9315a_config: unconfig
@$(MKCONFIG) -n $@ -t $(@:_config=) edb93xx arm arm920t edb93xx - ep93xx
#
-# ARM supplied Versatile development boards
-#
-
-versatile_config \
-versatileab_config \
-versatilepb_config : unconfig
- @board/armltd/versatile/split_by_variant.sh $@
-
-#
## XScale Systems
#
diff --git a/board/armltd/versatile/split_by_variant.sh
b/board/armltd/versatile/split_by_variant.sh
deleted file mode 100755
index 475e5a3..000
--- a/board/armltd/versatile/split_by_variant.sh
+++ /dev/null
@@ -1,42 +0,0 @@
-#!/bin/sh
-# -
-# Set the core module defines according to Core Module
-# -
-# -
-# Set up the Versatile type define
-# -
-
-mkdir -p ${obj}include
-variant=PB926EJ-S
-if [ "$1" = "" ]
-then
- echo "$0:: No parameters - using versatilepb_config"
- echo "#define CONFIG_ARCH_VERSATILE_PB" > ${obj}include/config.h
- variant=PB926EJ-S
-else
- case "$1" in
- versatilepb_config | \
- versatile_config)
- echo "#define CONFIG_ARCH_VERSATILE_PB" > ${obj}include/config.h
- ;;
-
- versatileab_config)
- echo "#define CONFIG_ARCH_VERSATILE_AB" > ${obj}include/config.h
- variant=AB926EJ-S
- ;;
-
-
- *)
- echo "$0:: Unrecognised config - using versatilepb_config"
- echo "#define CONFIG_ARCH_VERSATILE_PB" > ${obj}include/config.h
- variant=PB926EJ-S
- ;;
-
- esac
-
-fi
-# -
-# Complete the configuration
-# -
-$MKCONFIG -a versatile arm arm926ejs versatile armltd versatile
-echo "Variant:: $variant"
diff --git a/boards.cfg b/boards.cfg
index 80488b8..39a023e 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -115,7 +115,10 @@ nhk8815 arm arm926ejs
nhk8815 st
nhk8815_onenand arm arm926ejs nhk8815 st
nomadik nhk8815:BOOT_ONENAND
omap5912osk arm arm926ejs - ti
omap
edminiv2 arm arm926ejs - LaCie
orion5x
-dkb arm arm926ejs -
Marvellpantheon
+dkb arm arm926ejs -
Marvellpantheon
+versatilearm arm926ejs -
armltd versatile
+versatileab arm arm926ejs versatile
armltd versatile versatile:ARCH_VERSATILE_AB
+versatilepb arm arm926ejs versatile
armltd versatile versatile:
ca9x4_ct_vxp arm armv7 vexpressarmltd
efikamx arm armv7 efikamx -
mx5
mx51evk arm armv7 mx51evk
freescale mx5
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: don't panic if no flash is there
From: Alessandro Rubini
Commit f1d2b313c9eb6808d30c16a9eb5251240452a56c, which
introduced relocation, also added some ifdef to panic
for no flash is found but some is expected. This is policy,
in my opinion, and should not be part of the boot loader
like it wasn't there earlier.
This is mandatory to have the versatile port work on qemu,
where flash has never been correctly identified without any
side effect on the usefulness of the emulation.
Signed-off-by: Alessandro Rubini
---
arch/arm/lib/board.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index dc46e21..bc8b589 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -431,10 +431,6 @@ void board_init_f (ulong bootflag)
/* NOTREACHED - relocate_code() does not return */
}
-#if !defined(CONFIG_SYS_NO_FLASH)
-static char *failed = "*** failed ***\n";
-#endif
-
/
*
* This is the next part if the initialization sequence: we are now
@@ -501,9 +497,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
# else /* !CONFIG_SYS_FLASH_CHECKSUM */
print_size (flash_size, "\n");
# endif /* CONFIG_SYS_FLASH_CHECKSUM */
- } else {
- puts (failed);
- hang ();
}
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question about relocation
Hello. I'm trying to make at91sam9261ek working again, but relocation overlaps the destinatin address. In this board, u-boot runs already in RAM. This is exactly like the nhk8815 that I ported a few hours ago, but while there the IPL loaded our code at the beginning of RAM, in this case the IPL loaded us already at end of RAM. Now, this is the printout of the situation: U-Boot code: 23F0 -> 23F36EFC BSS: -> 23F78570 monitor len: 00078570 ramsize: 0400 TLB table at: 23ff Top of RAM usable for U-Boot at: 23ff Reserving 481k for U-Boot at: 23f64000 Reserving 180k for malloc() at: 23f37000 Reserving 24 Bytes for Board Info at: 23f36fe8 Reserving 144 Bytes for Global Data at: 23f36f58 New Stack Pointer is: 23f36f50 RAM Configuration: Bank #0: 2000 64 MiB relocation Offset is: 00064000 Since "tor len: 00078570" and "relocation Offset is: 00064000" the system data-aborts during relocation, as code overwrites relocation tables. What is the suggested solution? Changing the IPL is not acceptable for me, because it is an external tool used by everyone: everybody knows it loads and runs code at 23f0.. Thanks /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3 V2] nhk8815: add support for relocation
From: Alessandro Rubini
This patch defines all the needed symbols in the header file
and removes the now-unused config.mk in board directory.
Changes to board C file as requested.
Signed-off-by: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
Sorry, just noted that a parenthesis was missing in CONFIG_SYS_INIT_SP_ADDR.
It was a latent bug spitting a warning. This only changes that line
over V1 I sent earlier.
board/st/nhk8815/config.mk | 26 --
board/st/nhk8815/nhk8815.c |9 +++--
include/configs/nhk8815.h |5 +
3 files changed, 12 insertions(+), 28 deletions(-)
delete mode 100644 board/st/nhk8815/config.mk
diff --git a/board/st/nhk8815/config.mk b/board/st/nhk8815/config.mk
deleted file mode 100644
index 1789717..000
--- a/board/st/nhk8815/config.mk
+++ /dev/null
@@ -1,26 +0,0 @@
-# (C) Copyright 2007
-# STMicroelectronics,
-#
-# 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
-#
-#
-# image should be loaded at 0x0100
-#
-
-CONFIG_SYS_TEXT_BASE = 0x03F8
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index faef810..9b62011 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -82,13 +82,18 @@ int board_late_init(void)
int dram_init(void)
{
- /* set dram bank start addr and size */
+ gd->ram_size = get_ram_size(CONFIG_SYS_SDRAM_BASE,
+ CONFIG_SYS_SDRAM_SIZE);
+ return 0;
+}
+
+void dram_init_banksize(void)
+{
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
- return 0;
}
#ifdef CONFIG_CMD_NET
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index 49a16ab..758f19d 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -80,6 +80,11 @@
#define PHYS_SDRAM_1_SIZE 0x0400 /* 64 MB */
#define PHYS_SDRAM_2 0x0800 /* SDR-SDRAM BANK #2*/
#define PHYS_SDRAM_2_SIZE 0x0400 /* 64 MB */
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
+#define CONFIG_SYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE)
+/* The IPL loads us at 0, tell so to u-boot. Put stack pointer 1M into RAM */
+#define CONFIG_SYS_TEXT_BASE0x
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_TEXT_BASE + (1<<20))
#define CONFIG_STACKSIZE (128 * 1024)/* regular stack */
#ifdef CONFIG_USE_IRQ
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] nhk8815: move config targets from Makefile to boards.cfg
From: Alessandro Rubini Signed-off-by: Alessandro Rubini Acked-by: Andrea Gallo --- BTW: please note that file is not sorted and has some white-space error: "dkb" is aligned with tabs while all other use spaces and there is a spurious tab after "Target" (both begin and end) Makefile |9 - boards.cfg |2 ++ 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 713dba1..584105c 100644 --- a/Makefile +++ b/Makefile @@ -933,15 +933,6 @@ cp922_XA10_config \ cp1026_config: unconfig @board/armltd/integrator/split_by_variant.sh cp $@ -nhk8815_config \ -nhk8815_onenand_config:unconfig - @mkdir -p $(obj)include - @ > $(obj)include/config.h - @if [ "$(findstring _onenand, $@)" ] ; then \ - echo "#define CONFIG_BOOT_ONENAND" >> $(obj)include/config.h; \ - fi - @$(MKCONFIG) -n $@ -a nhk8815 arm arm926ejs nhk8815 st nomadik - xtract_omap1610xxx = $(subst _cs0boot,,$(subst _cs3boot,,$(subst _cs_autoboot,,$(subst _config,,$1 omap1610inn_config \ diff --git a/boards.cfg b/boards.cfg index 554e06c..9194610 100644 --- a/boards.cfg +++ b/boards.cfg @@ -103,6 +103,8 @@ dockstar arm arm926ejs - Seagate jadecpu arm arm926ejs jadecpu syteco mb86r0x imx27litearm arm926ejs imx27lite logicpdmx27 magnesiumarm arm926ejs imx27lite logicpdmx27 +nhk8815 arm arm926ejs nhk8815 st nomadik +nhk8815_onenand arm arm926ejs nhk8815 st nomadik nhk8815:BOOT_ONENAND omap5912osk arm arm926ejs - ti omap edminiv2 arm arm926ejs - LaCie orion5x dkb arm arm926ejs - Marvellpantheon -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] nhk8815: add support for relocation
From: Alessandro Rubini
This patch defines all the needed symbols in the header file
and removes the now-unused config.mk in board directory.
Changes to board C file as requested.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/config.mk | 26 --
board/st/nhk8815/nhk8815.c |9 +++--
include/configs/nhk8815.h |5 +
3 files changed, 12 insertions(+), 28 deletions(-)
delete mode 100644 board/st/nhk8815/config.mk
diff --git a/board/st/nhk8815/config.mk b/board/st/nhk8815/config.mk
deleted file mode 100644
index 1789717..000
--- a/board/st/nhk8815/config.mk
+++ /dev/null
@@ -1,26 +0,0 @@
-# (C) Copyright 2007
-# STMicroelectronics,
-#
-# 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
-#
-#
-# image should be loaded at 0x0100
-#
-
-CONFIG_SYS_TEXT_BASE = 0x03F8
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index faef810..9b62011 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -82,13 +82,18 @@ int board_late_init(void)
int dram_init(void)
{
- /* set dram bank start addr and size */
+ gd->ram_size = get_ram_size(CONFIG_SYS_SDRAM_BASE,
+ CONFIG_SYS_SDRAM_SIZE);
+ return 0;
+}
+
+void dram_init_banksize(void)
+{
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
- return 0;
}
#ifdef CONFIG_CMD_NET
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index 49a16ab..1cecc34 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -80,6 +80,11 @@
#define PHYS_SDRAM_1_SIZE 0x0400 /* 64 MB */
#define PHYS_SDRAM_2 0x0800 /* SDR-SDRAM BANK #2*/
#define PHYS_SDRAM_2_SIZE 0x0400 /* 64 MB */
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
+#define CONFIG_SYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE)
+/* The IPL loads us at 0, tell so to u-boot. Put stack pointer 1M into RAM */
+#define CONFIG_SYS_TEXT_BASE0x
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_TEXT_BASE + 1<<20)
#define CONFIG_STACKSIZE (128 * 1024)/* regular stack */
#ifdef CONFIG_USE_IRQ
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] nhk8815: remove platform.S, which was unused at link time
From: Alessandro Rubini This source file, which I got by the vendor in their own port, was not actually executing because lib-based compilation didn't call lowlevel_init (we have CONFIG_SKIP_LOWLEVEL_INIT). With the change to object-based linking, an undefined symbol in this file started hitting in the final link. Signed-off-by: Alessandro Rubini Acked-by: Andrea Gallo --- board/st/nhk8815/Makefile |2 +- board/st/nhk8815/platform.S | 340 --- 2 files changed, 1 insertions(+), 341 deletions(-) delete mode 100644 board/st/nhk8815/platform.S diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile index 3f360dc..60b87b1 100644 --- a/board/st/nhk8815/Makefile +++ b/board/st/nhk8815/Makefile @@ -30,7 +30,7 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(BOARD).o COBJS := nhk8815.o -SOBJS := platform.o +SOBJS := SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS)) diff --git a/board/st/nhk8815/platform.S b/board/st/nhk8815/platform.S deleted file mode 100644 index 2a67110..000 --- a/board/st/nhk8815/platform.S +++ /dev/null @@ -1,340 +0,0 @@ -/* - * Board specific setup info - * - * (C) Copyright 2005 - * STMicrolelctronics, - * - * (C) Copyright 2004, ARM Ltd. - * Philippe Robin, - * - * 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 -#include - -.globl lowlevel_init -lowlevel_init: - /* Jump to the flash address */ - ldr r0, =CFG_ONENAND_BASE - - /* -* Make it independent whether we boot from 0x0 or 0x3000. -* Non-portable: it relies on the knowledge that ip has to be updated -*/ - orr ip, ip, r0 /* adjust return address of cpu_init_crit */ - orr lr, lr, r0 /* adjust return address */ - orr pc, pc, r0 /* jump to the normal address */ - nop - - /* Initialize PLL, Remap clear, FSMC, MPMC here! */ - /* What about GPIO, CLCD and UART */ - - /* PLL Initialization */ - /* Prog the PLL1 @ 266 MHz ==> SDRAM Clock = 100.8 MHz */ - ldr r0, =NOMADIK_SRC_BASE - - ldr r1, =0x2B013502 - - str r1, [r0, #0x14] - - /* Used to set all the timers clock to 2.4MHZ */ - ldr r1, =0x2004 - str r1, [r0] - - ldr r1, =0x1000 - str r1, [r0, #0x10] - - /* FSMC setup */ - ldr r0, =NOMADIK_FSMC_BASE - - ldr r1, =0x10DB /* For 16-bit NOR flash */ - str r1, [r0, #0x08] - - ldr r1, =0x0333 /* For 16-bit NOR flash */ - str r1, [r0, #0xc] - - /* oneNAND setting */ - ldr r1, =0x105B /* BCR0 Prog control register */ - str r1, [r0] - - ldr r1, =0x0A200551 /* BTR0 Prog timing register */ - str r1, [r0, #0x04] - - /* preload the instructions into icache */ - add r0, pc, #0x1F - bic r0, r0, #0x1F - mcr p15, 0, r0, c7, c13, 1 - add r0, r0, #0x20 - mcr p15, 0, r0, c7, c13, 1 - - /* Now Clear Remap */ - ldr r0, =NOMADIK_SRC_BASE - - ldr r1, =0x2004 - str r1, [r0] - - ldr r1, =0x1000 - str r1, [r0, #0x10] - - ldr r0, =0x101E9000 - ldr r1, =0x2004 - str r1, [r0] - - ldr r0, =NOMADIK_SRC_BASE - ldr r1, =0x2104 - str r1, [r0] - - /* FSMC setup -- */ - mov r0, #(NOMADIK_FSMC_BASE & 0x1000) - orr r0, r0, #(NOMADIK_FSMC_BASE & 0x0FFF) - - ldr r1, =0x10DB /* For 16-bit NOR flash */ - str r1, [r0, #0x8] - - ldr r1, =0x0333 /* For 16-bit NOR flash */ - str r1, [r0, #0xc] - - /* MPMC Setup */ - ldr r0, =NOMADIK_MPMC_BASE - - ldr r1, =0xF3 - str r1, [r0]/* Enable the MPMC and the DLL */ - - ldr r1, =0x183 - str r1, [r0, #0x20] - - ldr r2, =NOMADIK_PMU_BASE - - ldr r1, =0x - str r1, [r2] - - ldr r1, =0x /* Prog the, mand delay strategy */ - str r1, [r0, #0x28] - - ldr r1, =0x103 /* NOP ,mand */ - str r1, [r0, #0x20] - - /* FIXME -- Wait required here */ - - ldr r1, =0x103 /* PALL ,mand*/ - str r1, [r0, #0x20]
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
> FWIW, I spent _far_ more than 30 minutes on this .. close to a full > day of frustration/banging my head against the wall. [...] I understand the feeling. I'm one of those who suggested (but not required) to put full-asm function in .S files for a reason; I personally think the reboot code may remain as it is, given the effort involved. There are minor details that may be better, but since I'm unable to suggest (and at least compile-test) them for lack of time, I'm not even listing them. Thank you very much for your efforts in following previous suggestions. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Tegra2: add support for A9 CPU init
>> It looks like most of your uses are standalone functions that would >> function just fine on their own. Is there a reason you prefer to have >> them in a C-file instead of in an assembly file? > Just laziness ;) > I'll move these to a new .S file in the next patchset. Actually, writing assembly-only C functions is difficul and error-pronet. I've seen you use "r0" and other registers esplicitly, but this is not allowed in general. I once wasted some hours in tracking why a non-submitted port of u-boot was not working with a newer compiler. The problem was just that: the new compiler was inlining a void(void) function; the asm used "r0" and "r1" explicitly, which worked over a function call but was corrupting data when inlined by the newer and more optimizing compiler. While your functions are currently not inlined (or, like cold_boot, they may be inlined in a place where no register needs to be preserved), another user may move them to a context where the semantics are different, for another board or another boot loader. If they are in a .S files, they will only be called by "bl" and you know the rules for register allocation appy. Besides, a _real_ lazy programmer avoids the extra quotes and \n in the code :) /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.
Dirk Behme:
> Just for the record:
>
> The trick is to ensure that the __arch_putx() containing the volatile
> is not the last statement in the GCC statement-expression. So, using
> something like
>
> #define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); v;})
>
> (note the additional 'v;') should result in correct code, too.
Yes, that's good. Also "0" may work, and may be more readable, (or not,
according to who reads it).
> The patches sent by Wolfgang and Alexander using
>
> #define writeb(v,c) do { __iowmb(); __arch_putb(v,c); } while (0)
>
> do the same with a slightly different syntax, so these patches are
> fine, too.
It's not just different syntax, it's different semantics.
The ({...}) trick turns statements into expressions, while the "do
{...} while(0)" does not. I'd better not forbid statements like
while (reg = readb(addr), reg != VALUE) { }
or
if (readb(addr) == VALUE) { ... }
or
swtich (readb(addr)) { ... }
While I agree they may in general not be clean, I can forsee
meaningful uses. Moreover, I'd better allow expression-looking macros
to really behave like expressions -- otherwise error messages are quite
hard to understand for the unaquainted.
IMHO, the only reason to use "do {} while(0)" over statemente
expressions is being portable but in u-boot we are gcc-specific
anyways.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
> I am not convinced, as we don't have an array context here. But sizeof(struct x) doesn't depend on how struct x is used. You can declare a pointer and then allocate for an array. > I don't see that with > > struct foo x; > struct foo y[N]; > > we have a guarantee that sizeof(x) == sizeof(y[0]). Yes, I see this requirement. But maybe we're already bikeshedding: I won't get offended if you keep the global +15 & ~15. regards /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
> Is it guaranteed (I mean by the C standard) that the alignment of a > struct (which affects only the possible start address) also has effect > on the sizeof() for that struct, in the sense that sizeof() is > guaranteed to be a multiple of that alignment requirement? Yes. Because if you make an array, all of them must be aligned, and the size of an array is a multiple of sizeof(array_item). While alignment is not in the standard, the sizeof/array relationship is. It's in C99 draft (http://busybox.net/~landley/c99-draft.html) 6.5.3.4 The sizeof operator #6 EXAMPLE 2 Another use of the sizeof operator is to compute the number of elements in an array: sizeof array / sizeof array[0] /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
>> This has already been applied, sooner than usual. Isn't it cleaner to >> force alignment on the structure itself? This way different architectures >> may use different values, if the need arises. > > It would be better, but how to implement that? Instead of: DEFINE(GENERATED_GBL_DATA_SIZE, (sizeof(struct global_data)+15) & ~15); I'd use: DEFINE(GENERATED_GBL_DATA_SIZE, (sizeof(struct global_data)), leaving the alignment requirement in the structure itself (include/asm/global_data.h for each architecture). /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
> + /* Round up to make sure size gives nice stack alignment */
> + DEFINE(GENERATED_GBL_DATA_SIZE,
> + (sizeof(struct global_data)+15) & ~15);
> +
This has already been applied, sooner than usual. Isn't it cleaner to
force alignment on the structure itself? This way different architectures
may use different values, if the need arises.
This shows it.
struct a {
int i;
} __attribute__((aligned(16)));
struct b {
int i;
};
int main()
{
printf("%i %i\n", sizeof(struct a), sizeof(struct b));
}
It prints "16 4" as expected.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/26] ARM: add relocation support
Hello Heiko. > Hmm.. at this place code is not relocated! So it should be executed > on the right address. May I say this is a huge step back from the non-relocation case? One of the things I love(d) with u-boot (at least the ARM one) is that I could place it in flash at any address and it would just work. So when I have a new binary I first write it to another flash sector and "go" to it. Only if it works I flash at offset 0. Sure I test in RAM first, but since writing the ram image to flash is not uncommon, the final test for me has always been in flash -- also for other reasons. I also think that simpler is better and I never understood the contorsions of relocation but I wouldn't argue if it wasn't a step back (I know the advantages, like going to end of ram, but they don't mean much to me). Is there any chance we could go on testing on a different flash address without relinking in-between (with the risk of mismatching the two images?) Thanks /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] AT91SAM9XE add embedded flash support
> Umm, the current branch would always have WIP. Sure, me too. > Always committing half done work to fix a problem in another branch > seems tedious to me. No, because you can use "git rebase -i" later, and thus squash together different commits. I have lots of "temporary" commits (which, btw, allows me to push to the backup place). Another useful tool is "git stash". It parks your current changes so you can switch branches, and reapply the changes laster when you are back (git stash apply). /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in IP/UDP defragment?
>> The patch below appears to solve my problem. > Can you please resubmit this (eventually integrating Alessandro's > comments) and add your Signed-off-by: line, so we can integrate this > fix into mainline? This already happened, it's upstream as e397e59e861aa818cda12a23206dde06f7e9f660 (v2010.06-rc2-36-ge397e59) and it went in through Ben Warren. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 17/19] arm cp15: setup mmu and enable dcache
Thanks Heiko for picking these up, wanted to reply today offlist. Nick Thompson: > As you noted, not all boards define these two symbols. I don't see where you > have added them in the config.h files. When I've done this, I couldn't find a name that all boards were using, so I had to make a choice. I think I just counted the various names and picked the more common. A board enabling cache must ensure to have the correct names defined, I see no easy solution. tornado% grep -rl CONFIG_SYS_SDRAM_BASE include/configs | wc -l 353 tornado% grep -rL CONFIG_SYS_SDRAM_BASE include/configs/ | wc -l 193 For example integratorcp is in this "grep -L", and it has PHYS_SDRAM_1/PHYS_SDRAM_1_SIZE . This matches less than half of those 193 boards: tornado% grep -rl PHYS_SDRAM_1_SIZE include/configs/ | wc -l 86 However, re-reading the patch looks like I chose the wrong symbol. This ought to be fixed, I'll try next week to address the issue. >> +page_table[i] = i << 20 | (3 << 10) | 0x1e; > > These numbers ought to be defines, no? Yes, it was a lazy RFC. I'll clean up ASAP (monday, hopefully), unless Heiko does it in his tree. Writeback or writethtough should be selectable. > I have previously tested this patch on da830 and it works fine, bar the two > issues above. Thanks for testing and your feedback /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling ARM DCache (and MMU setup) in U-Boot
> I am having exactly the same problem as described here by Drasko. Once I > enable MMU on ARM920T by setting the cp15 register 1, I get a data abort. Would you please try my patch? I haven't tried on 920T, but it worked well on 926. If needed I can try on 920T, as I have one. I sent it on Jan 26 2010. I think it's high time to add the missing flush and resend it, but it's in the archives anyways (message-id <20100126161608.ga20...@morgana.gnudd.com>) /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in IP/UDP defragment?
Hello.
Please forgive my delay.
> 16:58:32.290407 IP 10.12.48.10.33088 > 10.12.48.32.3285: UDP, length 2959
> 16:58:32.290410 IP 10.12.48.10 > 10.12.48.32: udp
> 16:58:32.290412 IP 10.12.48.10 > 10.12.48.32: udp
The third fragment here is less than 8 bytes of payload, and this
triggers the bug.
> I don't know yet what are the side effects of my patch.
Ok, I restudied the flow.
> - if (offset8 + (len / 8) <= h - payload) {
> + if (offset8 + (len / 8) < h - payload) {
> /* no overlap with holes (dup fragment?) */
> return NULL;
offset8 is the start of this fragment, as 8-byte-items, and h is the
current hole, the one that might be relevant. Since everything before
"h" is already filled, a fragment that ends where this hole starts
is duplicate, thus "<=".
Here len/8 is 0, so you force accepting this trailing fragment, but
you'll also accept duplicate packets. Looking at how following code
behaves in this case (it assumes some hole or part of is filled),
the "overlaps with initial part of the hole" will trigger, and the
hole will be rewritten unchanged.
So I don't see bad side effects in your fix, but if anyone will re-read
the code (looking for another bug, for example) after your change it will
be hard to understand (they'll suggest reverting the change for example).
I'd suggest to still discard duplicate fragments, by turning
if (offset8 + (len / 8) <= h - payload)
to
/* last fragment may be 1..7 bytes, the "+7" forces acceptance */
if (offset8 + ((len + 7) / 8) <= h - payload)
or something along these lines. Will you please post a patch?
Thanks a lof for your report and fix
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.06-rc1 is out / v2010.06 delayed by 2 weeks
> * U-Boot v2010.06-rc1 was released on Wed, 26 May 2010. Any reason why my Nomadik patches are not in? I reposted them on Apr 15th and got no negative feedback. Actually, the clcd patch which was accepted long ago is only used by the Nomadik patches, which don't touch anybody else. This is my internal short log --reverse. The first 7 which I posted should be uncontroversial. The last 4 are controversial so I haven't posted them. f23339f... nhk8815: change the order of initialization 9e63c76... drivers/misc: add stmpe2401 port extender and keypad controller 2bad55c... nhk8815.h: define we need stmpe 5c31564... nhk8815: added keypad afce697... nhk8815: start lower in RAM, so the 800x480 frame buffer fits 223e379... nhk8815: added lcd support 8425c4b... nhk8815: documented how to replace u-boot on flash 43d2fc0... NAND Nomadik: add CONFIG_NAND_NOMADIK_16BIT option cf6aaad... add calaso usb-s8815 d69e98d... lcd: support 32bpp (not lcd_color_fg/bg yet) 7fafa03... usb-s8815: use 32bpp not 16 Thanks /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] da850/L138 SPI flash transfer speed
>> To you knowledge, would enabling the >> cache for davinci da850 break anything in U-Boot? > > No, except that it should be done consistently for all ARM processors. Which reminds me I have to post V2 of my cache patch. V1 was sent on 2010-01-26 and some flush was missing. I didn't notice as network download worked fine. I'll try to respin it as soon as possible. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
Graeme, I reply to your messages since it gives somehow more information. I'm now not really convinced that reorganizing board directories would be a big step forward, although I still think it would be better. Si, I'm not arguing strongly, just bringing a point of view. Peter, Wolfgang, I'll try to do my homework and show how nhk8815/usb-s8815 would better share files when under cpu/, but I'm not sure to be able to complete it before a week or so. Graeme Russ: > Almost - it is more like > > board/ > $VENDOR/ >include/ >common/ >lib(?)/ >/ >$BOARDA/ >$BOARDB/ > > I really like this structure, particularly if the code under > $VENDOR/[common, include, lib] is arch independent. Yes, that would be good, if it was a common case. However, arch-independent code is usually under drivers. See at91 and avr32 for example: no common code under board/atmel/ . Even boards/freescale, which has three architectures, has only MPC stuff in common/ (no arm or coldfire files, checked by extracting the CONFIG_ symbols from Makefile and grepping for them in include/configs) > If a vendor develops a new board using a different CPU or SOC they > can easily re-use all their pre-existing platform independent code > for the new board. In theory you are correct. In practice, such platform independent material is using drivers/ . > And then there is also > > board/ > $BOARDC > $BOARDD > > I've never liked code existing on multiple depths like this. Agreed. > Maybe we move towards: > > board/ > $VENDOR > include/ > lib/ > $BOARDA/ > $BOARDB/ > $_generic/ > $BOARDC/ > $BOARDD/ That's an option. But "$_generic" is inferior to "cpu-$". At least listing will all "cpu-" directories nearby. If there really was vendor-specific cross-platform code, I agree something like you suggest is best. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
>> Most boards are very similar to the original evaluation kit. For >> example, [...] >> Similarly, I'm working on a dave-tech.eu board series based on >> ep9302-ep9315. [...] > I don't follow either argument, or the name-switching argument... Well, the name-switching is half a joke (but the philips 21xx is now nxp, motorola went freescale and so on). > How does putting boards in their appropriate CPU directory make > your coding any easier? Because if all boars with the same SoC are in the same directory they can share source files. In my example, st/nhk8815 and calao/usb-s8815 had several files replicated -- so Wolfgang rejected the patch. But in a vendor-based structure I won't merge in a single board dir boards from two different vendors. Same will happen for dave/zefeer where a lot is in commong with edb93xx. That's what the kernel is doing, actually. In arch-pxa, arch-at91 and other directories at the same level I have board file and some files that are used by several boards. Some are SoC wide, so would fit in cpu/ within u-boot, but some not (although, my fault, I'm not digging for filenames to show). I think there already is some replication in u-boot currently, but I haven't stats right now. On the other hand, having boards as subdirs of the same parent doesn't automatically make replication go away, but at least may avoid new replication in future boards thanks for your patience /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure
I can see how it'd be >> nice to split up boards into CPU directories, but we'd have to discuss >> some of the warts, like where vendor-specific code would be located if >> we went down that path. > > Right. I can see arguments pro and con each of the approaches, and I > must admit that I have no telling argument for either. > > My gut feeling is that I like the existing board/ approach better, but > I'm open to arguments. Here a pair of arguments... Most boards are very similar to the original evaluation kit. For example, within Nomadik, code for the Calao USB-S8815 is not much different from code for the NHK8815 evaluation board. But Wolfgang refused my patch as the files are very similar; I asked how to proceed, with no reply so far. Note that both board/calao and board/st exist (board/st only has 1 board, though). Similarly, I'm working on a dave-tech.eu board series based on ep9302-ep9315. board/edb93xx exists but "edb" is the evaluation board; mine should be board/dave/zefeer (board/dave already exists), though very similar to edb93xx code. Hope these are arguments WD would consider. Moreover, vendors switch names often, cpu families do it rarely. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] nhk8815: documented how to replace u-boot on flash
From: Alessandro Rubini Signed-off-by: Alessandro Rubini Acked-by: Andrea Gallo --- doc/README.nhk8815 | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/doc/README.nhk8815 b/doc/README.nhk8815 index 9008e39..365d7e1 100644 --- a/doc/README.nhk8815 +++ b/doc/README.nhk8815 @@ -26,6 +26,26 @@ where it was loaded from, the configurations differ in where the filesystem is looked for by default. +** How to replace U-Boot with your own + +Due to the "secure" boot described above, The U-Boot binary isn't +expected to live at the beginning of the NAND flash but rather at +0x80800 (offset 2kB within /dev/mtd). + +To replace it with your own binary you should either use the serial +flasher the vendor distributes (there is a version running on +GNU/Linux too) or with the following commands from U-Boot. +These commands read 256kB from the are that will be /dev/mtd2 and +overwrite U-Boot at offset 2kB: + +nand read 10 8 4 +bootp 100800 u-boot-nhl8815.bin +nand erase 8 4 +nand write 10 8 4 + + +** Further documentation + On www.st.com/nomadik and on www.stnwireless.com there are documents, summary data and white papers on Nomadik. The full datasheet for STn8815 is not currently available on line but under specific request -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] nhk8815: added lcd support
From: Alessandro Rubini
This adds lcd support for the board. It includes defines for 32-bit
parameter as well, although support for LCD_COLOR32 is not yet in
u-boot. This uses the stmpe2401 to turn on display backlight.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/Makefile |1 +
board/st/nhk8815/lcd.c | 88
board/st/nhk8815/nhk8815-devices.h |1 +
board/st/nhk8815/nhk8815.c |3 +
include/configs/nhk8815.h | 10
5 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 board/st/nhk8815/lcd.c
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index 1bb1d2c..7155f12 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -31,6 +31,7 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y:= nhk8815.o
COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+COBJS-$(CONFIG_LCD) += lcd.o
COBJS := $(COBJS-y)
SOBJS := platform.o
diff --git a/board/st/nhk8815/lcd.c b/board/st/nhk8815/lcd.c
new file mode 100644
index 000..d3acb48
--- /dev/null
+++ b/board/st/nhk8815/lcd.c
@@ -0,0 +1,88 @@
+/*
+ * board/st/nhk8815/lcd.c: use amba clcd and STMPE2401 for backlight/reset
+ *
+ * Copyright 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+#include
+
+/* Two configurations are supported: 32bpp and 16bpp */
+#if LCD_BPP == LCD_COLOR32
+# define CLCD_CNTL_VAL 0x0019182b
+# define CLCD_BPIX_VAL 5 /* 1<<5 = 32 */
+#elif LCD_BPP == LCD_COLOR16
+# define CLCD_CNTL_VAL 0x001d1829
+# define CLCD_BPIX_VAL 4 /* 1<<4 = 16 */
+#else
+# error "Invalid LCD_BPP in config file"
+#endif
+
+/* Horribly, these are precomputed registers */
+struct clcd_config nhk8815_clcd_config = {
+ .address = (struct clcd_registers *)NOMADIK_CLCDC_BASE,
+ .tim0 = 0xd52600c4, /* horizontal timings */
+ .tim1 = 0x220a01df, /* vertical timings */
+ .tim2 = 0x031f1821, /* clock and signal polarity */
+ .tim3 = 0, /* not used */
+ .cntl = CLCD_CNTL_VAL, /* control, pixel size etc */
+ .pixclock = 18*1000*1000, /* 18 MHz */
+};
+
+/* This is the panel_info for generic boards. Too little info, actually */
+vidinfo_t panel_info = {
+ .vl_col = 800,
+ .vl_row = 480,
+ .vl_bpix = CLCD_BPIX_VAL,
+ .priv = &nhk8815_clcd_config,
+};
+
+/* Don't turn on (too early), but configure data lines and remove reset */
+void lcd_enable(void)
+{
+ int i;
+
+ /* Turn the alternate functions as needed */
+ for (i = 32; i <= 39; i++)
+ nmk_gpio_af(i, GPIO_ALT_B);
+
+ /* EXP1_GPIO_5 = output high -- remove reset from display */
+ pe_gpio_af(STMPE1, 5, PE_GPIO_AF_GPIO);
+ pe_gpio_dir(STMPE1, 5, 1);
+ pe_gpio_set(STMPE1, 5, 1);
+}
+
+/* Called from late_init: we turn on the backlight through port expander */
+int nhk8815_backlight_on(void)
+{
+ int i;
+
+ /* Turn the alternate functions as needed */
+ for (i = 32; i <= 39; i++)
+ nmk_gpio_af(i, GPIO_ALT_B);
+
+ /* EXP0_GPIO_21 = output high -- backlight */
+ pe_gpio_af(STMPE0, 21, PE_GPIO_AF_GPIO);
+ pe_gpio_dir(STMPE0, 21, 1);
+ pe_gpio_set(STMPE0, 21, 1);
+ return 0;
+}
diff --git a/board/st/nhk8815/nhk8815-devices.h
b/board/st/nhk8815/nhk8815-devices.h
index 78252ed..aec5825 100644
--- a/board/st/nhk8815/nhk8815-devices.h
+++ b/board/st/nhk8815/nhk8815-devices.h
@@ -3,5 +3,6 @@
/* Prototypes for functions exported by device files in this directory */
extern int nhk8815_keypad_init(void); /* ./keypad.c */
+extern int nhk8815_backlight_on(void); /* in ./lcd.c */
#endif /* __NHK8815_DEVICES__ */
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index fbabd15..fedb3c0 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -113,6 +113,9
[U-Boot] [PATCH 5/7] nhk8815: start lower in RAM, so the 800x480 frame buffer fits
From: Alessandro Rubini This simply moves u-boot to a lower address, as the frame buffer is allocated after u-boot itself in memory. Signed-off-by: Alessandro Rubini Acked-by: Andrea Gallo --- board/st/nhk8815/config.mk |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/board/st/nhk8815/config.mk b/board/st/nhk8815/config.mk index 590393b..6e5e358 100644 --- a/board/st/nhk8815/config.mk +++ b/board/st/nhk8815/config.mk @@ -18,9 +18,7 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA -# -# -# image should be loaded at 0x0100 -# -TEXT_BASE = 0x03F8 +# Start 4MB before the end, as the frame buffer is allocate after +# u-boot. 800x480 @ 32bpp takes 1.5MB alone, so let's play safe. +TEXT_BASE = 0x03c0 -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] nhk8815: added keypad
From: Alessandro Rubini
This patch adds keypad support for the nhk8815 board, based on the
stmpe2401 driver. The keypad hosts 16 keys, so each of them sends a
string instead of a single key. The provided keymap is only an
example and must be customized according to the use case.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/Makefile |5 ++-
board/st/nhk8815/keypad.c | 99
board/st/nhk8815/nhk8815-devices.h |7 +++
board/st/nhk8815/nhk8815.c |4 ++
include/configs/nhk8815.h |3 +
5 files changed, 117 insertions(+), 1 deletions(-)
create mode 100644 board/st/nhk8815/keypad.c
create mode 100644 board/st/nhk8815/nhk8815-devices.h
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index b37fe53..1bb1d2c 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -29,7 +29,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := nhk8815.o
+COBJS-y:= nhk8815.o
+COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+
+COBJS := $(COBJS-y)
SOBJS := platform.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/st/nhk8815/keypad.c b/board/st/nhk8815/keypad.c
new file mode 100644
index 000..4bbcce6
--- /dev/null
+++ b/board/st/nhk8815/keypad.c
@@ -0,0 +1,99 @@
+/*
+ * board/st/nhk8815/keypad.c: keypad on nhk8815 board, based on STMPE2401
+ *
+ * Copyright 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+#include
+
+/*
+ * Keymap for our 4x4 matrix: since we have just
+ * a few keys, use a string for each of the keys.
+ */
+static char *keymap[4][4] = {
+ {"", "back", "ffw", "left"},
+ {"", "tvout", "playpause", "right"},
+ {"vol-", "lock", "rew", "up"},
+ {"vol+", "start", "ok", "down"}
+};
+
+/* this keeps track of the string being returned */
+static char *nextchar = "";
+
+/* This getc can return failure, not permitted in the caller */
+static int __nhk8815_getc(void)
+{
+ int row, col, res;
+
+ res = pe_kpc_getkey(STMPE0, &row, &col);
+ if (res < 0)
+ return res; /* invalid */
+ nextchar = keymap[row][col];
+ return 0;
+}
+
+/* This is low level: may not report a valid key (a release, for example) */
+static int __nhk8815_tstc(void)
+{
+ /* the interrupt is active low */
+ int gpio = nmk_gpio_get(76);
+ return !gpio;
+}
+
+/* This is the one that is being called, it reads the pending string */
+static int nhk8815_tstc(void)
+{
+ if (*nextchar) /* there's already data */
+ return 1;
+ if (!__nhk8815_tstc()) /* no new data? */
+ return 0;
+ __nhk8815_getc(); /* get (or not) new data */
+ return (nextchar[0] != '\0');
+}
+
+/* So this is only called when there is data in the currenct string */
+static int nhk8815_getc(void)
+{
+ return *(nextchar++);
+}
+
+/* called from late init */
+int nhk8815_keypad_init(void)
+{
+ struct stdio_dev dev;
+
+ /* The keypad is on EXP0, columns 0..3, rows 0..3 */
+ pe_kpc_init(STMPE0, 0x0f, 0x0f, 30 /* ms */);
+
+ /* Keypad interrupt: GPIO76 */
+ nmk_gpio_af(76, GPIO_GPIO);
+ nmk_gpio_dir(76, 0);
+
+ memset (&dev, 0, sizeof (dev));
+ dev.flags = DEV_FLAGS_INPUT;
+ dev.getc = nhk8815_getc;
+ dev.tstc = nhk8815_tstc;
+ strcpy(dev.name, "keypad");
+ stdio_register(&dev);
+ return 0;
+}
diff --git a/board/st/nhk8815/nhk8815-devices.h
b/board/st/nhk8815/nhk8815-devices.h
new file mode 100644
index 000..78252ed
--- /dev/null
+++ b/board/st/nhk8815/nhk8815-devices.h
@@ -0,0 +1,7 @@
+#ifndef __NHK8815_DEVICES__
+#define __NHK8815_DEVICES__
+
+/* Prototypes for functions exported by device files in this directory */
+extern int nhk8815_keypad_init(void); /* ./keypad.c */
+
+#endif /* __NHK8815_DEVICES__ */
diff --git a/board/st/nhk8815/
[U-Boot] [PATCH 3/7] nhk8815.h: define we need stmpe
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
include/configs/nhk8815.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index 2b640dc..fcb1b20 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -109,7 +109,7 @@
#define CONFIG_PL01x_PORTS { (void *)CFG_SERIAL0, (void *)CFG_SERIAL1 }
#define CONFIG_PL011_CLOCK 4800
-/* i2c, for the port extenders (uses gpio.c in board directory) */
+/* i2c, for the stmpe2401 port extenders (uses gpio.c in board directory) */
#ifndef __ASSEMBLY__
#include
#define CONFIG_CMD_I2C
@@ -125,6 +125,11 @@
#define I2C_DELAY (udelay(2))
#endif /* __ASSEMBLY__ */
+/* Activate port extenders and define their i2c address */
+#define CONFIG_STMPE2401
+#define STMPE0 0x43
+#define STMPE1 0x44
+
/* Ethernet */
#define PCI_MEMORY_VADDR 0xe800
#define PCI_IO_VADDR 0xee00
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] drivers/misc: add stmpe2401 port extender and keypad controller
From: Alessandro Rubini
This driver is an i2c device acting as a port extender. Since
the keypad can be configured to act on specific row and column lines,
the specific setup is passed by the board file. This is used by
the Nomadik nhk8815, through a later patch in this series.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
drivers/misc/Makefile|1 +
drivers/misc/stmpe2401.c | 191 ++
include/stmpe2401.h | 66
3 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/stmpe2401.c
create mode 100644 include/stmpe2401.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f6df60f..76c009a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,6 +30,7 @@ COBJS-$(CONFIG_DS4510) += ds4510.o
COBJS-$(CONFIG_FSL_LAW) += fsl_law.o
COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
+COBJS-$(CONFIG_STMPE2401) += stmpe2401.o
COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
COBJS := $(COBJS-y)
diff --git a/drivers/misc/stmpe2401.c b/drivers/misc/stmpe2401.c
new file mode 100644
index 000..f347d07
--- /dev/null
+++ b/drivers/misc/stmpe2401.c
@@ -0,0 +1,191 @@
+/*
+ * board/st/nhk8815/egpio.c: extended gpio as found on nhk8815 board
+ *
+ * Copyright 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+
+/*
+ * First, an interface to set and read registers, used in this file as well
+ */
+int pe_getreg(int addr, int reg)
+{
+ unsigned char val8 = reg;
+ int ret;
+
+ ret = i2c_read(addr, reg, 1 /* len */, &val8, 1);
+ if (ret < 0)
+ return ret;
+ return val8;
+}
+
+int pe_setreg(int addr, int reg, int val)
+{
+ unsigned char val8 = val;
+
+ return i2c_write(addr, reg, 1, &val8, 1);
+}
+
+/*
+ * Generic higher-level GPIO interface
+ */
+int pe_gpio_af(int addr, int pin, int af)
+{
+ int regval;
+
+ regval = pe_getreg(addr, PE_GPIO_AFR(pin));
+ if (regval < 0)
+ return regval;
+ regval &= ~PE_GPIO_AF_MASK(pin);
+ regval |= af << PE_GPIO_AF_SHIFT(pin);
+ return pe_setreg(addr, PE_GPIO_AFR(pin), regval);
+}
+
+int pe_gpio_dir(int addr, int pin, int dir)
+{
+ int regval;
+
+ /* 0 == input, 1 == output */
+ regval = pe_getreg(addr, PE_GPIO_GPDR(pin));
+ if (regval < 0)
+ return regval;
+ regval &= ~PE_GPIO_MASK(pin);
+ if (dir)
+ regval |= PE_GPIO_MASK(pin);
+ return pe_setreg(addr, PE_GPIO_GPDR(pin), regval);
+}
+
+int pe_gpio_pud(int addr, int pin, int pu, int pd)
+{
+ int regval, mask = PE_GPIO_MASK(pin);
+
+ /* change pullup */
+ regval = pe_getreg(addr, PE_GPIO_GPPUR(pin));
+ if (regval < 0)
+ return regval;
+ if (pu)
+ regval |= mask;
+ else
+ regval &= ~mask;
+ regval = pe_setreg(addr, PE_GPIO_GPPUR(pin), regval);
+ if (regval < 0)
+ return regval;
+
+ /* change pulldown */
+ regval = pe_getreg(addr, PE_GPIO_GPPDR(pin));
+ if (regval < 0)
+ return regval;
+ if (pu)
+ regval |= mask;
+ else
+ regval &= ~mask;
+ regval = pe_setreg(addr, PE_GPIO_GPPDR(pin), regval);
+ if (regval < 0)
+ return regval;
+
+ return 0;
+}
+
+int pe_gpio_set(int addr, int pin, int val)
+{
+ int reg;
+
+ if (val)
+ reg = PE_GPIO_GPSR(pin);
+ else
+ reg = PE_GPIO_GPCR(pin);
+
+ return pe_setreg(addr, reg, PE_GPIO_MASK(pin));
+}
+
+int pe_gpio_get(int addr, int pin)
+{
+ int regval;
+
+ regval = pe_getreg(addr, PE_GPIO_GPMR(pin));
+ if (regval < 0)
+ return regval;
+ return (regval & PE_GPIO_MASK(pin)) ? 1 : 0;
+}
+
+/*
+ * Generic higher-level keypad interface: we have 12 rows out, 8 columns in
+ */
+int pe_kpc_init(int addr, int rowmask, int colmask, int debounce_ms)
+{
+ int i;
+ /* note that gpio15 is missing
[U-Boot] [PATCH 1/7] nhk8815: change the order of initialization
From: Alessandro Rubini
Some inizialization was in board_late_init(), but to satisfy drivers
added in the next patches must be performed in normal board_init.
This patch leaves board_late_init() empty, but later patches fill it.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/nhk8815.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index faef810..eadce40 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -60,22 +60,26 @@ int board_init(void)
writel(0x02100551, NOMADIK_FSMC_BASE + 0x04); /* FSMC_BTR0 */
icache_enable();
- return 0;
-}
-int board_late_init(void)
-{
+ /*
+* Configure I2C pins, as we will use I2C in a later commit
+*/
+
/* Set the two I2C gpio lines to be gpio high */
nmk_gpio_set(__SCL, 1); nmk_gpio_set(__SDA, 1);
nmk_gpio_dir(__SCL, 1); nmk_gpio_dir(__SDA, 1);
nmk_gpio_af(__SCL, GPIO_GPIO); nmk_gpio_af(__SDA, GPIO_GPIO);
- /* Reset the I2C port expander, on GPIO77 */
- nmk_gpio_af(77, GPIO_GPIO);
- nmk_gpio_dir(77, 1);
- nmk_gpio_set(77, 0);
- udelay(10);
- nmk_gpio_set(77, 1);
+ /* Put the two I2C port expanders out of reset, on GPIO77 and 79 */
+ {
+ int n[2]={77, 79};
+ int i;
+ for (i = 0; i < ARRAY_SIZE(n); i++) {
+ nmk_gpio_af(n[i], GPIO_GPIO);
+ nmk_gpio_dir(n[i], 1);
+ nmk_gpio_set(n[i], 1);
+ }
+ }
return 0;
}
@@ -101,3 +105,10 @@ int board_eth_init(bd_t *bis)
return rc;
}
#endif
+
+/* Initialization callback, from lib_arm/board.c */
+int board_late_init(void)
+{
+ return 0;
+}
+
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] Nomadik: lcd and other stuff
From: Alessandro Rubini This patch set is the one from December, with one addition in documentation (last patch in the series). It is rebased to current master, although there was no dependency on the massive renames besides the "fix timer" patch which meanwhile got upstream. Alessandro Rubini (7): nhk8815: change the order of initialization drivers/misc: add stmpe2401 port extender and keypad controller nhk8815.h: define we need stmpe nhk8815: added keypad nhk8815: start lower in RAM, so the 800x480 frame buffer fits nhk8815: added lcd support nhk8815: documented how to replace u-boot on flash board/st/nhk8815/Makefile |6 +- board/st/nhk8815/config.mk |8 +- board/st/nhk8815/keypad.c | 99 +++ board/st/nhk8815/lcd.c | 88 + board/st/nhk8815/nhk8815-devices.h |8 ++ board/st/nhk8815/nhk8815.c | 38 +-- doc/README.nhk8815 | 20 drivers/misc/Makefile |1 + drivers/misc/stmpe2401.c | 191 include/configs/nhk8815.h | 20 - include/stmpe2401.h| 66 11 files changed, 528 insertions(+), 17 deletions(-) create mode 100644 board/st/nhk8815/keypad.c create mode 100644 board/st/nhk8815/lcd.c create mode 100644 board/st/nhk8815/nhk8815-devices.h create mode 100644 drivers/misc/stmpe2401.c create mode 100644 include/stmpe2401.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] Nomadik: move timer code to drivers/misc
>> > .../{asm-arm/arch-nomadik/mtu.h => nomadik_mtu.h} |0
>>
>> Move the nomadik_gpio.h and nomadik_mtu.h into nomadik.h
>> Just to have 1 nomadik *.h
>
> nomadik.h is currently used for 8815-specific addresses. If Alessandro
> has no objections, I will move it to, say, nmdk8815.h and then combine
> the common peripheral headers into nomadik.h.
While I preferred the original patch (each peripheral has an header file,
usually), I have no problem with this approach.
Actually, now that "nomadik" is the name of common code (not the
individual cpu), it's correct for "nomadik.h" to have "8815" in the name.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.03-rc2 is out
> - ARM: > > A few boards are broken or produce tons of warnings: otc570, suen3, > a320evb, etc. Fixes welcome / needed. Nomadik nhk8815 is broken as the timer fix is still missing (nand write doesn't work reliably, for example saveenv). Shall I repost "Nomadik: fix reset_timer()" ? Also, but this is less important, I don't understand what's the status of the other patches sent months ago. This is, as a reminder, my sequence from master, in the order they are applied (log --reverse). The first one is in the video queue, but for the others i don't know. 9cbed53... lcd: make 16bpp work 6a02362... Nomadik: fix reset_timer() 9df8630... nhk8815: change the order of initialization 45e9c21... drivers/misc: add stmpe2401 port extender and keypad controller cb55d95... nhk8815.h: define we need stmpe 43619fe... nhk8815: added keypad 0f31f00... nhk8815: start lower in RAM, so the 800x480 frame buffer fits 9112252... nhk8815: added lcd support Thanks a lot for you patience. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Hello.
> I have not received any updates from the gcc mailing list. Has anyone
> got any more ideas on this? Thanks!
Out of curiosity, I tried to reproduce the problem. I added EXT2 to my
binary and recompiled with eldk-4.2. As a reminder, this is the
source:
if (dirent.namelen != 0) {
char filename[dirent.namelen + 1];
ext2fs_node_t fdiro;
int type = FILETYPE_UNKNOWN;
status = ext2fs_read_file (diro,
fpos + sizeof (struct ext2_dirent),
dirent.namelen, filename);
Note that namelen is a uint8_t. What follows is the disassembled u-boot.
My comments follow each groups of lines.
a182025c: e55b2026ldrbr2, [fp, #-38]
a1820260: e352cmp r2, #0 ; 0x0
a1820264: 0a77beq a1820448
[so r2 is namelen]
a1820268: e282300fadd r3, r2, #15 ; 0xf
a182026c: e2033f7eand r3, r3, #504; 0x1f8
so here r3 is (namelen + 0xf) & 0x1f8 . I don't understand the "&0x1f8" since
r2 was known to be 8 bits at most.
a1820270: e50bd034str sp, [fp, #-52]
a1820274: e063d00drsb sp, r3, sp
stack pointer has been saved, and sp takes sp - r3. Looks fine.
a1820278: e1a041adlsr r4, sp, #3
a182027c: e51b3030ldr r3, [fp, #-48]
a1820280: e1a0a184lsl sl, r4, #3
shift back and forth to align sp ("ldr r3" in the middle is fpos, used
in building arguments for ext2fs_read_file).
a1820284: e1a7mov r0, r7
a1820288: e2831008add r1, r3, #8 ; 0x8
a182028c: e1a0300amov r3, sl
a1820290: ebfffe77bl a181fc74
So everything looks fine. I also tried a standalone program with both
a uint16_t and the official uint8_t namelen and it works fine (there
is no "& 0x1f8" any more in the assembly for 16-bit lengths). In that
test the callee has a stack pointer which is as low as needed according
to the namelen used by the caller.
Therefore, I suspect your problem can come out of
ext2fs_read_file. However, the calculations there look good to me
(actually, everybody uses them, so they must be good for normal uses).
However, in ext2fs_read_file, there might be an issue in the first
block (which "is not stored on disk but is zero filled instead"):
memset (buf, 0, blocksize - skipfirst);
should be
memset (buf, 0, blockend - skipfirst);
where blockend is == blocksize but might be shorter in the last block
of the read. So if you are reading a dirent in the first block you
might have a problem of stack overflow.
But I don't expect you'll read a dirent from first block, and even if
it was, then namelen would be zero as well. I suspect your problem is
elsewhere, although I can't imagine where, as this code doesn't look
like something that can stack overflow even if misused.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: make 16bpp work
Thank Anatolij. I re-tested it as first patch applied on master. This is my current sequence (git log --reverse ...). The first is yours, the next is my pending stack. f2a4dcb... lcd: make 16bpp work 79e3c0e... Nomadik: fix reset_timer() be8fb55... nhk8815: change the order of initialization e6a9a8a... drivers/misc: add stmpe2401 port extender and keypad controller aaf173b... nhk8815.h: define we need stmpe b6ce3d2... nhk8815: added keypad ce173d5... nhk8815: start lower in RAM, so the 800x480 frame buffer fits f6b2955... nhk8815: added lcd support The latter patches had no conflicts during rebase, so I don't think I need to post them again. I re-run "./MAKEALL arm" with no related issues, either. As Wolfgang noted, I'm now up to you and Tom (added to Cc:). If there's any step needed on my side, please tell me. Thanks /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 rev2] ep93xx: Refactoring of timer code
> i was/am working on a new version of the patch, taking into account > your remarks about the unit of TIMER_FREQ and fixing some issues > discussed with Alessandro Rubini off-list, who worked on a similar > patch. Actually, I checked the point we disagreed about, which is the unit of get_ticks() and get_tbclk(). You currently return hw-ticks in get_ticks, and CONFIG_SYS_HZ (i.e. 1000) in get_tbclk. However, these two functions are expected to be used together, so they must be consistent in their return value. It's true that the functions are little used (they are mostly used in ppc code, within cpu/*/interrupts), and that's why I didn't even provide them in cpu/arm926ejs/nomadik/timer.c. All few users assume they are consistent, but there is no documentation: tornado% grep -qr get_tbclk README* doc || echo not found not found tornado% grep -qr get_ticks README* doc/* || echo not found not found I've made a quick tour of all definitions in cpu/ and here is the result. As you see, at91 (which you used as reference, I understand) is wrong, while all the others use either hwticks or SYS_HZ consistently. source-fileget_ticks() get_tbclk arm920t/at91/timer.c get_timer() CONFIG_SYS_HZ arm920t/a320/timer.c get_timer() CONFIG_SYS_HZ arm920t/s3c24x0/timer.c hw-ticks (I didn't understand) arm920t/imx/timer.c get_timer() CONFIG_SYS_HZ arm920t/at91rm9200/timer.c get_timer() CONFIG_SYS_HZ pxa/timer.c hw-ticks-32bits TIMER_FREQ_HZ arm_cortexa8/omap3/timer.c get_timer() CONFIG_SYS_HZ arm_cortexa8/s5pc1xx/timer.c get_timer() CONFIG_SYS_HZ arm925t/timer.c get_timer() CONFIG_SYS_HZ ppc4xx/cpu.c lib_ppc/ticks.S freqProcessor blackfin/interrupts.cget_timer() CONFIG_SYS_HZ sa1100/timer.c get_timer() CONFIG_SYS_HZ mpc824x/cpu.clib_ppc/ticks.S bus_freq mpc8xx/cpu.c lib_ppc/ticks.S timebase mpc512x/cpu.clib_ppc/ticks.S timebase mpc5xxx/cpu.clib_ppc/ticks.S timebase mpc8220/cpu.clib_ppc/ticks.S timebase at32ap/interrupts.c hw-ticks cpu_hz mpc85xx/cpu.clib_ppc/ticks.S timebase 74xx_7xx/cpu.c lib_ppc/ticks.S timebase arm1136/omap24xx/timer.c get_timer() CONFIG_SYS_HZ mpc86xx/cpu.clib_ppc/ticks.S timebase mpc8260/cpu.clib_ppc/ticks.S timebase arm926ejs/omap/timer.c get_timer() CONFIG_SYS_HZ arm926ejs/davinci/timer.cget_timer() CONFIG_SYS_HZ arm926ejs/versatile/timer.c get_timer() CONFIG_SYS_HZ arm926ejs/at91/timer.c hwticks CONFIG_SYS_HZ arm926ejs/spear/timer.c hwticks CONFIG_SYS_HZ arm1176/s3c64xx/timer.c hwrticks (I didn't understand) lh7a40x/timer.c get_timer(I didn't understand) mpc5xx/cpu.c lib_ppc/ticks.S timebase /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
Hello Matthias. > i found some more information about the precharge workaround: > [...] > please test the below patch on your board when you get a chance. it > should be pretty much the same sequence that worked for you, i just > removed the *workaround* that makes my boards hang and restructured > the code a little It boots, but it takes one second more than my code -- don't know why. And neither the ethernet nor usb work properly any more. I suggest it's best if you leave your previous code here, and I'll have mine for my board in a different directory. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
Hello Matthias. I'm sorry I can't test before wednesday as I'll be offline. I am doubtful, as usually precharge is done before setting mode, but your chips are clearly different from mine, I now expect that no sequence works for both of them. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
> i gave my ack after a visual review of the patch, without having > tested it. i just installed a patched u-boot on one of my boards and > it doesn't boot :( Oh. The opposite of my board. Then, since I don't have a 9315A but only a similar one, it's better to drop the patch. I'll have a different sdram_cfg file for mine, then. Thanks for testing, Matthias /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] edb93xx sdram: fix initialization
The configuration of SDRAM needs two more writel() operations,
otherwise some boards won't be able to boot. These additional writes
are present in vendor assembly code but were forgotten during the
rewriting in C.
Signed-off-by: Alessandro Rubini
Acked-by: Matthias Kaehlcke
---
board/edb93xx/sdram_cfg.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/board/edb93xx/sdram_cfg.c b/board/edb93xx/sdram_cfg.c
index 6155f0e..418959a 100644
--- a/board/edb93xx/sdram_cfg.c
+++ b/board/edb93xx/sdram_cfg.c
@@ -59,13 +59,15 @@ void sdram_cfg(void)
static void force_precharge(void)
{
+ struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
+
+ writel(GLCONFIG_INIT | GLCONFIG_CKE, &sdram->glconfig);
/*
* Errata most EP93xx revisions say that PRECHARGE ALL isn't always
* issued.
*
* Do a read from each bank to make sure they're precharged
*/
-
PRECHARGE_BANK(0);
PRECHARGE_BANK(1);
PRECHARGE_BANK(2);
@@ -101,6 +103,9 @@ static void setup_refresh_timer(void)
static void program_mode_registers(void)
{
+ struct sdram_regs *sdram = (struct sdram_regs *)SDRAM_BASE;
+
+ writel(GLCONFIG_MRS | GLCONFIG_CKE, &sdram->glconfig);
/*
* The mode registers are programmed by performing a read from each
* SDRAM bank. The value of the address that is read defines the value
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ep93xx leds: remove arrays in data section
This code is used at early boot, and using arrays for status
generates references to RAM addresses that are not working.
The patch avoids such structures using a preprocessor macro and
by reading status from hardware in the toggle function.
Meanwhile, inline functions are turned to static to save code space.
Signed-off-by: Alessandro Rubini
Acked-by: Matthias Kaehlcke
---
cpu/arm920t/ep93xx/led.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/cpu/arm920t/ep93xx/led.c b/cpu/arm920t/ep93xx/led.c
index 7e2c897..8b2df04 100644
--- a/cpu/arm920t/ep93xx/led.c
+++ b/cpu/arm920t/ep93xx/led.c
@@ -25,24 +25,21 @@
#include
#include
-static uint8_t saved_state[2] = {STATUS_LED_OFF, STATUS_LED_OFF};
-static uint32_t gpio_pin[2] = {1 << STATUS_LED_GREEN,
- 1 << STATUS_LED_RED};
+/* We can't use arrays in data segment at early boot, but we know n is 0-1 */
+#define GPIO_PIN(n) (1 << (n))
-inline void switch_LED_on(uint8_t led)
+static inline void switch_LED_on(uint8_t led)
{
register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
- writel(readl(&gpio->pedr) | gpio_pin[led], &gpio->pedr);
- saved_state[led] = STATUS_LED_ON;
+ writel(readl(&gpio->pedr) | GPIO_PIN(led), &gpio->pedr);
}
-inline void switch_LED_off(uint8_t led)
+static inline void switch_LED_off(uint8_t led)
{
register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
- writel(readl(&gpio->pedr) & ~gpio_pin[led], &gpio->pedr);
- saved_state[led] = STATUS_LED_OFF;
+ writel(readl(&gpio->pedr) & ~GPIO_PIN(led), &gpio->pedr);
}
void red_LED_on(void)
@@ -72,17 +69,9 @@ void __led_init(led_id_t mask, int state)
void __led_toggle(led_id_t mask)
{
- if (STATUS_LED_RED == mask) {
- if (STATUS_LED_ON == saved_state[STATUS_LED_RED])
- red_LED_off();
- else
- red_LED_on();
- } else if (STATUS_LED_GREEN == mask) {
- if (STATUS_LED_ON == saved_state[STATUS_LED_GREEN])
- green_LED_off();
- else
- green_LED_on();
- }
+ register struct gpio_regs *gpio = (struct gpio_regs *)GPIO_BASE;
+
+ writel(readl(&gpio->pedr) ^ GPIO_PIN(mask), &gpio->pedr);
}
void __led_set(led_id_t mask, int state)
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] edb93xx: two patches for boot code
While working on a board similar to the EDB9315A, I had to fix two more things as my board doesn't boot without them. I already talked with Matthias Kaehlcke who gave me his ack on those patches. Alessandro Rubini (2): ep93xx leds: remove arrays in data section edb93xx sdram: fix initialization board/edb93xx/sdram_cfg.c |7 ++- cpu/arm920t/ep93xx/led.c | 29 + 2 files changed, 15 insertions(+), 21 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] enabling watchdog timer
> I'm using an at91sam9260ek board. I configured a watchdog driver in my > kernel only to find out that u-boot turns it off. The problem with 9260 and friends is that the watchdog can be configured once only. In my experience the best thing to do is leaving it unconfigured (it triggers in 13 seconds, more or less) so the kernel or application can configure it (either enable at a different timeout or or disable it). > The big top level README files says I need to define CONFIG_WATCHDOG, but > [...] I think you should grep around yourself. I did it with 1.1.5 and things are different now. > Also in 'README.at91', reference is made to make sure that the watchdog in > AT91Bootstrap is not disabled. Where's 'AT91Bootstrap'? It is a separate package. An initial program loader that loads the real boot loader from nand or dataflash. You may be using it or not, you have to check that on your setup. If u-boot is not programmed to offset 0 of your nand, you most likely have at91boot there. The stock sources of at91boot disable the watchdog, so you most likely want to change it. I used http://www.at91.com/repFichier/Project-209/at91bootstrap-2.3.tar.bz2 and removed line 84 of board/at91sam9260ek/at91sam9260ek.c . After that, you'll want u-boot to trigger the watchdog without configuring it, unless you need a shorter timeout since the beginning. Hope this helps. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] edb93xx: enable the uart in devicecfg register
printf goes to uart1, but it will block forever waiting for busy to go off unless the uart is enabled first. Signed-off-by: Alessandro Rubini --- board/edb93xx/edb93xx.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/board/edb93xx/edb93xx.c b/board/edb93xx/edb93xx.c index 4df2246..dde30ff 100644 --- a/board/edb93xx/edb93xx.c +++ b/board/edb93xx/edb93xx.c @@ -64,6 +64,12 @@ int board_init(void) value |= SYSCON_PWRCNT_UART_BAUD; writel(value, &syscon->pwrcnt); + /* Enable the uart in devicecfg */ + value = readl(&syscon->devicecfg); + value |= 1<<18 /* U1EN */; + writel(0xAA, &syscon->sysswlock); + writel(value, &syscon->devicecfg); + /* Machine number, as defined in linux/arch/arm/tools/mach-types */ gd->bd->bi_arch_number = CONFIG_MACH_TYPE; -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] edb93xx: change calculation un early_udelay.h
Previous code compiled with gcc-4.2.2 makes a call to
__aeabi_uidiv to divide by 20. As a side effect it was
not inline any more, and so sdram_cfg used the stack
as well, but this is early code that has no stack yet.
The patch explicitly removes the division, so no stack is used.
The calculation of the counter calls a division by 20
Signed-off-by: Alessandro Rubini
---
board/edb93xx/early_udelay.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/edb93xx/early_udelay.h b/board/edb93xx/early_udelay.h
index 3b26b3f..185283d 100644
--- a/board/edb93xx/early_udelay.h
+++ b/board/edb93xx/early_udelay.h
@@ -26,7 +26,7 @@
static inline void early_udelay(uint32_t usecs)
{
/* loop takes 4 cycles at 5.0ns (fastest case, running at 200MHz) */
- register uint32_t loops = (usecs * 1000) / 20;
+ register uint32_t loops = usecs * (1000 / 20);
__asm__ volatile ("1:\n"
"subs %0, %1, #1\n"
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] EP93xx: fix syscon_regs definition
The structure was missing a reserved entry (not listed in the manual,
actually), so the last registers had a wrong offset. This prevented
all swlocked registers to be modified as swlock is last in the structure.
Signed-off-by: Alessandro Rubini
---
include/asm-arm/arch-ep93xx/ep93xx.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/asm-arm/arch-ep93xx/ep93xx.h
b/include/asm-arm/arch-ep93xx/ep93xx.h
index 6cafe54..806557a 100644
--- a/include/asm-arm/arch-ep93xx/ep93xx.h
+++ b/include/asm-arm/arch-ep93xx/ep93xx.h
@@ -558,8 +558,9 @@ struct syscon_regs {
uint32_t i2sclkdiv;
uint32_t keytchclkdiv;
uint32_t chipid;
+ uint32_t reserved4;
uint32_t syscfg;
- uint32_t reserved4[8];
+ uint32_t reserved5[8];
uint32_t sysswlock;
};
#else
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Fixes for edb9315
I'm porting current u-boot to a board similar to EP9315A, so I'm using arm/master as a basis, as it includes the patches by Matthias Kaehlcke. I'm currently running from RAM (SKIP_LOWLEVEL_INIT), after setting up sdram and pll elsewhere (older vendor u-boot code, still to be ported). "fix syscon_regs definition" is needed to access any software-locked syscon register from C code (e.g., in reset_cpu() and devicecfg used by me in patch 3). "change calculation un early_udelay.h" is needed at least for eldk-4.2 (gcc-4.2.2), as without this patch it will use the stack before setting SP. Actually, we could use the ether buffer as a stack, if needed, but it's not really needed here. "enable the uart in devicecfg register" prevents u-boot from freezing at least with SKIP_LOWLEVEL_INIT set, but I'm pretty sure lowlevel_setup assembly code doesn't enable the uart, either. Alessandro Rubini (3): EP93xx: fix syscon_regs definition edb93xx: change calculation un early_udelay.h edb93xx: enable the uart in devicecfg register board/edb93xx/early_udelay.h |2 +- board/edb93xx/edb93xx.c |6 ++ include/asm-arm/arch-ep93xx/ep93xx.h |3 ++- 3 files changed, 9 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: remove symbolic links in tools/
Mike Frysinger about -delete: > i didnt suggest that because it isnt POSIX. it'll break on BSD systems which > typically ship with sh*t userland tools. Actually, I just copied the above line with "-name *" and stuff because I know there are portability issues I'm not aware of. Actually, Git blame says -name comes from an original "-lname *", that Jean Christophe turned to "-name * -type l" for posix compliance. He has been tricked by the original name-based match. I proposed the one-liner only because I remember a similar issue being addressed not long ago in the makefiles. But I'm fine with removing all such legacy, either, assuming novices will have a clean tool and git users are able to "git status" or "git clean". /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: remove symbolic links in tools/
Older versions created symbolic links for e.g. crc32.c. If such link remains in a tree, current Makefiles will use CC instead of HOSTCC to compile it; this results in a linker error. To be safe, let's remove any link from earlier checkouts. Signed-off-by: Alessandro Rubini --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 327aa8c..f85462c 100644 --- a/Makefile +++ b/Makefile @@ -3778,6 +3778,7 @@ clobber: clean @rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l -print | xargs rm -f + @[ ! -d $(obj)tools ] || find $(obj)tools -name "*" -type l -print | xargs rm -f ifeq ($(OBJTREE),$(SRCTREE)) mrproper \ -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: remove CONFIG_ATMEL_LCD ifdefs from lcd_setfgcolor
> Applied to u-boot-video/master Thanks. Then my "[PATCH V3 6/9] lcd: make 16bpp work" can use : ? lcd_color_fg : lcd_color_bg; instead of this worse choice that I sent in: ? 0x : 0; I don't feel like I should resend, but if asked to I'll resend. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] What linux kernel binary do I use????
> I am really REALLY stuck - I don't know what kernel image to use with > bootm (and where to load it and quite a few other things but getting the > right image would be a good start) I think bootm wants uImage. i.e., the "u-boot image". There is no rule for "make uImage" for x86, but you can run "mkimage" by yourself. The image format (thus uImage) is just a 64 byte header in front of a binary file, with magic number, lenght, checksum and other information. Actually, common/cmd_bootm.c::bootm_start() calls boot_get_kernel, which uses img_addr to look for the format. genimg_get_format then is in common/image.c, where image_header_t is used as defined in include/image.h. I admin "uImage" doesn't appear in the functions, though. Then there is the new FIT format, but I think your want to start with the legacy format. Hope this helps /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problems with tftp
>> Jan 27 09:24:33 lab7 atftpd[5910]: Requested file to big, increase >> BLKSIZE > In this case it is a server parameter. I actually think in _this_ case it is a client one. By reading atftpd manual page it says blksize is supported by default, but it's the client that must specify it, or the default 512 applies. Current u-boot supports it through CONFIG_TFTP_BLOCKSIZE as well as IP fragments. I use 4k blocksize like this (include/configs/nhk8815.h): #define CONFIG_IP_DEFRAG/* Allows faster download, TFTP and NFS */ #define CONFIG_TFTP_BLOCKSIZE 4096 #define CONFIG_NFS_READ_SIZE4096 /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/2] dcache on ARM
Hello Nick. > On TI DA830, the 1.0 & 1.1 revision of the silicon have a data caching > bug. You can use data caching, but only in write thru' mode. I see. So instead of both C and B you just need to C bit set in the page table, and no B. I propose to allow an extra option for write-back, leaving write-through as the default. This matches the blackfin, which has CONFIG_DCACHE_WB as an option, and leaves a safer default for those who won't explicitly require WB policy. Could you please confirm my patch works on that board after changing the magic bits from 0x1e to 0x1a ? (I'll use symbolic constants anyways in V2, this was just a quick RFC to see if the approach is acceptable). /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/2] dcache on ARM
> I don't see the flush_cache() call inside cmd_bootm.c. > Don't you think it is necessary before jumping to Linux? Yes, definitely. Actually, I checked it, but re-checking now I see I've been tricked by '[id]cache_disable' being grepped successfully in common/cmd_bootm.c . However, it's inside a false ifdef. I'm booting through the network, so that's probably why it works reliably for me (netboot_common does the propre flushing). > Or am I missing something? Not at all, thanks for catching this. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC 2/2] arm cp15: setup mmu and enable dcache
This has been tested on at91sam9263 and STN8815.
Again, I didn't check if it has bad effects
on non-arm926 cores.
Initially I had a "done" bit to only set up page tables
at the beginning. However, since the aligmnent requirement
was for the whole object file, this extra integer tool 16kB
in BSS, so I chose to remove it.
Also, note not all boards use PHYS_SDRAM, but it looks like
it's the most used name (more than CONFIG_SYS_DRAM_BASE for
example).
Signed-off-by: Alessandro Rubini
---
lib_arm/cache-cp15.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/lib_arm/cache-cp15.c b/lib_arm/cache-cp15.c
index 62ed54f..257aea1 100644
--- a/lib_arm/cache-cp15.c
+++ b/lib_arm/cache-cp15.c
@@ -32,6 +32,35 @@ static void cp_delay (void)
/* copro seems to need some delay between reading and writing */
for (i = 0; i < 100; i++)
nop();
+ asm volatile("" : : : "memory");
+}
+
+/* to activate the MMU we need to set up virtual memory: use 1M areas in bss */
+static inline void mmu_setup(void)
+{
+ static u32 __attribute__((aligned(16384))) page_table[4096];
+ int i;
+ u32 reg;
+
+ /* Set up an identity-mapping for all 4GB, rw for everyone */
+ for (i = 0; i < 4096; i++)
+ page_table[i] = i << 20 | (3 << 10) | 0x12;
+ /* Then, enable cacheable and bufferable for RAM only */
+ for (i = PHYS_SDRAM >> 20;
+i < ( PHYS_SDRAM + PHYS_SDRAM_SIZE) >> 20;
+i++) {
+ page_table[i] = i << 20 | (3 << 10) | 0x1e;
+ }
+ /* Copy the page table address to cp15 */
+ asm volatile("mcr p15, 0, %0, c2, c0, 0"
+: : "r" (page_table) : "memory");
+ /* Set the access control to all-supervisor */
+ asm volatile("mcr p15, 0, %0, c3, c0, 0"
+: : "r" (~0));
+ /* and enable the mmu */
+ reg = get_cr(); /* get control reg. */
+ cp_delay();
+ set_cr(reg | CR_M);
}
/* cache_bit must be either CR_I or CR_C */
@@ -39,6 +68,9 @@ static void cache_enable(uint32_t cache_bit)
{
uint32_t reg;
+ /* The data cache is not active unless the mmu is enabled too */
+ if (cache_bit == CR_C)
+ mmu_setup();
reg = get_cr(); /* get control reg. */
cp_delay();
set_cr(reg | cache_bit);
@@ -49,6 +81,11 @@ static void cache_disable(uint32_t cache_bit)
{
uint32_t reg;
+ if (cache_bit == CR_C) {
+ /* if disabling data cache, disable mmu too */
+ cache_bit |= CR_M;
+ flush_cache(0, ~0);
+ }
reg = get_cr();
cp_delay();
set_cr(reg & ~cache_bit);
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC 1/2] flush cache for arm926
This simple adds the cache flush for arm926. Most likely
the same works for other families, like arm920t, but I didn't
check as this is currently just an RFC.
Signed-off-by: Alessandro Rubini
---
lib_arm/cache.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib_arm/cache.c b/lib_arm/cache.c
index 61ee9d3..b36fd24 100644
--- a/lib_arm/cache.c
+++ b/lib_arm/cache.c
@@ -32,5 +32,11 @@ void flush_cache (unsigned long dummy1, unsigned long
dummy2)
arm1136_cache_flush();
#endif
+#ifdef CONFIG_ARM926EJS
+ /* test and clean, page 2-23 of arm926ejs manual */
+ asm("0: mrc p15, 0, r15, c7, c10, 3\n\t" "bne 0b\n" : : : "memory");
+ /* disable write buffer as well (page 2-22) */
+ asm("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+#endif
return;
}
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC 0/2] dcache on ARM
These patches enable the dcache for ARM9. It's mainly an RFC, as some details are still to be sorted out, but they work fine (and the speed increase is noticeable for kernel boots and cp.b -- didn't make more tests. I tested the code on at91sam9263ek and nhk8815. No makeall at this point, as I'm mainly interested in comments here. This is based on the cache-cp15.c infrastructure set up by Jean-Christophe for icache enabling. I'm sure Drasko Draskovic has better code, but since he has sent no a patch yet (asked in Mar 2009, and then again and again), here is my approach. Alessandro Rubini (2): flush cache for arm926 arm cp15: setup mmu and enable dcache lib_arm/cache-cp15.c | 37 + lib_arm/cache.c |6 ++ 2 files changed, 43 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] typo ([STATUS] Patch status update)
[damn, I re-read it over and over before sending]
> There is one minor delay about lcd_setfgcolor/lcd_setbgcolor that
^
> was sorted out by Anatolij on Dec 12 ("lcd: remove CONFIG_ATMEL_LCD
> ifdefs from lcd_setfgcolor").
It was a minor __detail__. No delay issues here. If his patch of Dec12
goes in, a one line cleanup in my own patch will follow.
Sorry for the mistype
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Patch status update
> 4051 11/06 Alessandro Rubini [U-Boot] [PATCH V3] Nomadik: fix reset_timer()
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/71200
Superseded by V4 below.
> 4940 11/25 Alessandro Rubini [U-Boot] [PATCH V4] Nomadik: fix reset_timer()
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72083
This is needed for saveenv to work reliably. I'd like it to be merged
Then there is my sequence of 9 nhk patches. V2 is obsoleted by V3 which
fixed structure definitions and removed a few debugging printf.
So these are obsolete:
> 4930 11/25 Alessandro Rubini [U-Boot] [PATCH V2 0/9] display and keypad
> support for nhk8815
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72073
> 4932 11/25 Alessandro Rubini [U-Boot] [PATCH V2 2/9] video: add amba-clcd
> prime-cell
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72075
> 4933 11/25 Alessandro Rubini [U-Boot] [PATCH V2 3/9] include/nomadik.h:
> add physical address for cldc
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72076
> 4934 11/25 Alessandro Rubini [U-Boot] [PATCH V2 4/9] drivers/misc: add
> stmpe2401 port extender and keypad controller
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72077
> 4935 11/25 Alessandro Rubini [U-Boot] [PATCH V2 5/9] nhk8815.h: define we
> need stmpe
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72078
> 4936 11/25 Alessandro Rubini [U-Boot] [PATCH V2 6/9] lcd: make 16bpp work
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72079
> 4937 11/25 Alessandro Rubini [U-Boot] [PATCH V2 7/9] nhk8815: added keypad
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72080
> 4938 11/25 Alessandro Rubini [U-Boot] [PATCH V2 8/9] nhk8815: start lower
> in RAM, so the 800x480 frame buffer fits
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72081
> 4939 11/25 Alessandro Rubini [U-Boot] [PATCH V2 9/9] nhk8815: added lcd
> support
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72082
As for V3 this is the status:
> 5259 12/05 Alessandro Rubini [U-Boot] [PATCH V3 0/9] display and keypad
> support for nhk8815
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72395
cover letter, please discard
> 5260 12/05 Alessandro Rubini [U-Boot] [PATCH V3 1/9] nhk8815: change the
> order of initialization
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72396
Needed for correct bringup of diplay in 7/9 and 9/9.
> 5261 12/05 Alessandro Rubini [U-Boot] [PATCH V3 2/9] video: add amba-clcd
> prime-cell
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72397
> 5262 12/05 Alessandro Rubini [U-Boot] [PATCH V3 3/9] include/nomadik.h:
> add physical address for cldc
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72398
These two have been applied to u-boot-video/next by Anatolij (Dec 12). Still in
next branch.
> 5263 12/05 Alessandro Rubini [U-Boot] [PATCH V3 4/9] drivers/misc: add
> stmpe2401 port extender and keypad controller
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72399
> 5264 12/05 Alessandro Rubini [U-Boot] [PATCH V3 5/9] nhk8815.h: define we
> need stmpe
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72400
> 5265 12/05 Alessandro Rubini [U-Boot] [PATCH V3 6/9] lcd: make 16bpp work
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72401
> 5266 12/05 Alessandro Rubini [U-Boot] [PATCH V3 7/9] nhk8815: added keypad
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72402
> 5267 12/05 Alessandro Rubini [U-Boot] [PATCH V3 8/9] nhk8815: start lower
> in RAM, so the 800x480 frame buffer fits
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72403
> 5268 12/05 Alessandro Rubini [U-Boot] [PATCH V3 9/9] nhk8815: added lcd
> support
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72404
These depend on the ones in video/next and apply cleanly to the
master branch as of today. There is one minor delay about
lcd_setfgcolor/lcd_setbgcolor that was sorted out by Anatolij on Dec
12 ("lcd: remove CONFIG_ATMEL_LCD ifdefs from lcd_setfgcolor").
But his patch isn't in master yet nor in the video branches.
Thanks
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Performance problems with gunzip
> I never said it was difficult, only non-trivial :) Not trivial, actually. > I am looking forward to something like this for a long time now and I'm > sure other people will value it too, so thanks in advance! It's still not working, but _I_ am working on it again after the weekend. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Add Nomadik board "usb-s8815" by Calao vendor
Wolfgang Denk: > I don't like to see such heavy copying of code. This is a clear > indication that we should factor out the common parts While I disagree (as explained), I'm trying hard to do it. Unfortunately what is currently a Makefile decision (COBJS-y and such) will sometimes become ifdef in the code. However, i've moved platform.S and lcd.c to the cpu directory, so they can be shared (the assembly really ought to be personalized for each board, as some cruft is still there from past history, and the lcd.c is really two small data structures, but let's ignore this by now). Now, reading better your message I see this that I don't understand. > Actually differences are so small that common code can be used > completely, and no separate board directories are needed. On one side we are asked to use the vendor directories, and now I should merge vendor/st/nhk8815 and vendor/calao/usb-8815. Now, I wonder where am I expected to place che board files. In cpu/arm926ejs/nomadik ? And using #ifdef in a single file to sort out differences? I got the idea a board should be a separate object (directory), which bases on the available infrastructure to pick up pieces and define own parameters. Adding a board should be as easy as adding a directory. Such parameters sometimes happen to match other parameters, but coalescing two boards just to save a few lines is not an advantage, in my opinion. Could you please explain how to proceed to have both boards upstream in the best possible way? I currently don't understand the policy. Please forgive me if the message looks aggressive. It's not meant to be, but ascii doesn't proprely convey tone. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Performance problems with gunzip
> I fear this is not as easy as flipping a bit in a register. Depending > on the platform caches tend to be tied to the MMU, so enabling the > caches require setting up correct data structures for the MMU to work. > That's the non-trivial work. Not that difficult, either. You just need to fill the top-level page table for 1MB sections (4096 sections = 16k bytes, which must be aligned on a 16k boundary). > Apart from that, there is CONFIG_CMD_CACHE which builds > common/cmd_cache.c. I see that at least two PXA250 platforms enable > this, so maybe simply try that? I think it's always disabled on arm, for the mmu reason. > Maybe you can reap the code from their repository. If you do, please > post it here ;) Or I can cook an RFC patch later, after redoing the 8815 patches. I was just considering trying it these days, as I've done the same on another straight-on-iron project and it's not that difficult. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] NAND Nomadik: add CONFIG_NAND_NOMADIK_16BIT option
Wolfgang Denk: >> Also, I suggest to change the name into CONFIG_NOMADIK_NAND_16BIT >> which seems more logical to me. Scott Wood: > It's an attribute of the hardware, so it should be > CONFIG_SYS_NOMADIK_NAND_16BIT. Actually, I would love to have this option passed from the board, to avoid an ifdef in the SoC driver, which actually can handle both. I haven't found how to do that. Any suggestion is welcome, otherwise I'll use the name suggested by Scott Wood. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Add Nomadik board "usb-s8815" by Calao vendor
[I'm re-adding Gregory Hermant in Cc:, while my message had the Cc: explicit, the copy I got from the list and your reply had no such header] > I don't like to see such heavy copying of code. I understand your point of view (although I didn't use --find-copies-harder you probably wouldn't have noticed). However, these are really different boards from different vendors. The Calao one is a stripped-down version of the development system, not uncommon to what happens elsewhere. Where do you suggest to place common code? While it is true that, currently, platform.S can be placed in common nomadik code, the file could as well be cleaned up of unneeded or redundant stuff, which is different in the two boards. (The file is something I got from the vendor and would benefit from some cleanup, now that I know more of the various register sets in the SoC). > Note that many of the existing diffrences can be avoided easily and > without need for #ifdef's: You are right. But one LCD needs a turn-on-backlight method, while the other does not. If I place it on cpu/arm926ejs/nomadik/ we'll have problems when another board mounts a different display. I'll try to factorize as I can, but I'm not sure it's the right thing to do. Will respin the patch by tomorrow night. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Add Nomadik board "usb-s8815" by Calao vendor
Signed-off-by: Alessandro Rubini
Cc: Gregory Hermant
---
MAINTAINERS|4 +
Makefile |4 +
board/{st/nhk8815 => calao/usb-s8815}/Makefile |3 +-
board/{st/nhk8815 => calao/usb-s8815}/config.mk|0
board/{st/nhk8815 => calao/usb-s8815}/lcd.c| 34 +--
board/{st/nhk8815 => calao/usb-s8815}/platform.S |0
.../nhk8815.c => calao/usb-s8815/usb-s8815.c} | 40 +
include/configs/{nhk8815.h => usb-s8815.h} | 98
8 files changed, 36 insertions(+), 147 deletions(-)
copy board/{st/nhk8815 => calao/usb-s8815}/Makefile (96%)
copy board/{st/nhk8815 => calao/usb-s8815}/config.mk (100%)
copy board/{st/nhk8815 => calao/usb-s8815}/lcd.c (68%)
copy board/{st/nhk8815 => calao/usb-s8815}/platform.S (100%)
copy board/{st/nhk8815/nhk8815.c => calao/usb-s8815/usb-s8815.c} (67%)
copy include/configs/{nhk8815.h => usb-s8815.h} (61%)
diff --git a/MAINTAINERS b/MAINTAINERS
index e8ba4bc..9d97b40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -699,6 +699,10 @@ Nomadik Linux Team
nhk8815 ARM926EJS (Nomadik 8815 Soc)
+Alessandro Rubini
+
+ usb-s8815 ARM926EJS (Nomadik 8815 Soc)
+
Steve Sakoman
omap3_overo ARM CORTEX-A8 (OMAP3xx SoC)
diff --git a/Makefile b/Makefile
index 793fcec..39e9a09 100644
--- a/Makefile
+++ b/Makefile
@@ -3068,6 +3068,10 @@ trab_old_config: unconfig
}
@$(MKCONFIG) -a $(call xtract_trab,$@) arm arm920t trab NULL s3c24x0
+usb-s8815_config: unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm926ejs usb-s8815 calao nomadik
+
+
VCMA9_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t vcma9 mpl s3c24x0
diff --git a/board/st/nhk8815/Makefile b/board/calao/usb-s8815/Makefile
similarity index 96%
copy from board/st/nhk8815/Makefile
copy to board/calao/usb-s8815/Makefile
index 7155f12..730d374 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/calao/usb-s8815/Makefile
@@ -29,8 +29,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS-y:= nhk8815.o
-COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+COBJS-y:= usb-s8815.o
COBJS-$(CONFIG_LCD) += lcd.o
COBJS := $(COBJS-y)
diff --git a/board/st/nhk8815/config.mk b/board/calao/usb-s8815/config.mk
similarity index 100%
copy from board/st/nhk8815/config.mk
copy to board/calao/usb-s8815/config.mk
diff --git a/board/st/nhk8815/lcd.c b/board/calao/usb-s8815/lcd.c
similarity index 68%
copy from board/st/nhk8815/lcd.c
copy to board/calao/usb-s8815/lcd.c
index d3acb48..744da67 100644
--- a/board/st/nhk8815/lcd.c
+++ b/board/calao/usb-s8815/lcd.c
@@ -1,5 +1,5 @@
/*
- * board/st/nhk8815/lcd.c: use amba clcd and STMPE2401 for backlight/reset
+ * board/calao/usb-s8815/lcd.c: use amba clcd and STMPE2401 for backlight/reset
*
* Copyright 2009 Alessandro Rubini
*
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
/* Two configurations are supported: 32bpp and 16bpp */
#if LCD_BPP == LCD_COLOR32
@@ -38,7 +38,7 @@
#endif
/* Horribly, these are precomputed registers */
-struct clcd_config nhk8815_clcd_config = {
+struct clcd_config s8815_clcd_config = {
.address = (struct clcd_registers *)NOMADIK_CLCDC_BASE,
.tim0 = 0xd52600c4, /* horizontal timings */
.tim1 = 0x220a01df, /* vertical timings */
@@ -53,36 +53,14 @@ vidinfo_t panel_info = {
.vl_col = 800,
.vl_row = 480,
.vl_bpix = CLCD_BPIX_VAL,
- .priv = &nhk8815_clcd_config,
+ .priv = &s8815_clcd_config,
};
-/* Don't turn on (too early), but configure data lines and remove reset */
+/* Set GPIO32..GPIO39 to ALTB, to enable LCD16..LCD23 */
void lcd_enable(void)
{
int i;
- /* Turn the alternate functions as needed */
- for (i = 32; i <= 39; i++)
+ for (i = 32; i < 40; i++)
nmk_gpio_af(i, GPIO_ALT_B);
-
- /* EXP1_GPIO_5 = output high -- remove reset from display */
- pe_gpio_af(STMPE1, 5, PE_GPIO_AF_GPIO);
- pe_gpio_dir(STMPE1, 5, 1);
- pe_gpio_set(STMPE1, 5, 1);
-}
-
-/* Called from late_init: we turn on the backlight through port expander */
-int nhk8815_backlight_on(void)
-{
- int i;
-
- /* Turn the alternate functions as needed */
- for (i = 32; i <= 39; i++)
- nmk_gpio_af(i, GPIO_ALT_B);
-
- /* EXP0_GPIO_21 = output high -- backlight */
- pe_gpio_af(STMPE0, 21, PE_GPIO_AF_GPIO);
- pe_gpio_dir(STMPE0, 21, 1);
- pe_gpio_set(STMPE0, 21, 1);
- return 0;
}
diff --git a/board/st/nhk8815/platform.S b/board/calao/usb-s8815/platform.S
similarity index 100%
copy from board/st/nhk8815/platform.S
copy to board/calao/usb-s8815/platform.S
diff --git a/board/st/nhk8815/nhk8815.c b/board/calao/usb
[U-Boot] [PATCH 1/2] NAND Nomadik: add CONFIG_NAND_NOMADIK_16BIT option
Signed-off-by: Alessandro Rubini
Cc: Gregory Hermant
---
drivers/mtd/nand/nomadik.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/nomadik.c b/drivers/mtd/nand/nomadik.c
index b76f4cb..149f68b 100644
--- a/drivers/mtd/nand/nomadik.c
+++ b/drivers/mtd/nand/nomadik.c
@@ -196,13 +196,20 @@ static void nomadik_nand_read_buf(struct mtd_info *mtd,
uint8_t *buf, int len)
int board_nand_init(struct nand_chip *chip)
{
- /* Set up the FSMC_PCR0 for nand access*/
- writel(0x004a, REG_FSMC_PCR0);
- /* Set up FSMC_PMEM0, FSMC_PATT0 with timing data for access */
+ u32 pcr0_val;
+
+ chip->options = NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING;
+ pcr0_val = 0x004a; /* Enabled, nand, enable ecc hw */
+
+#ifdef CONFIG_NAND_NOMADIK_16BIT
+ chip->options |= NAND_BUSWIDTH_16;
+ pcr0_val |= 0x0010; /* 16-bit access */
+#endif
+ /* Set up FSMC control0, PMEM0, PATT0 with timing data for access */
+ writel(pcr0_val, REG_FSMC_PCR0);
writel(0x00020401, REG_FSMC_PMEM0);
writel(0x00020404, REG_FSMC_PATT0);
- chip->options = NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING;
chip->cmd_ctrl = nomadik_nand_hwcontrol;
chip->dev_ready = nomadik_nand_ready;
/* The chip allows 32bit reads, so avoid the default 8bit copy */
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Add a new Nomadik board
These two patches add the USB-S8815 board by Calao.
The board is very similar to the nhk8815 evaluation kit,
but the NAND is connected on a 16-bit bus. Therefore, the first patch
adds the option to have 16-bit nand, and the second one uses it.
The patch depends on the LCD support patches I sent on Dec 05. Some
of them were picked up in the video-next branch (Dec 05), but I had no
feedback about the other ones (actually, only those two are needed for
this board, the other ones are for nhk8815 devices that are missing
here).
Also, for the board to work the pach for reset timer is needed. I
sent V4 on Nov 25th and I had no feedback (nor has it been applied).
The trivial patch is needed for NAND operations to work reliably on
both nhk8815 and usb-s8815 (this one).
Alessandro Rubini (2):
NAND Nomadik: add CONFIG_NAND_NOMADIK_16BIT option
Add Nomadik board "usb-s8815" by Calao vendor
MAINTAINERS|4 +
Makefile |4 +
board/{st/nhk8815 => calao/usb-s8815}/Makefile |3 +-
board/{st/nhk8815 => calao/usb-s8815}/config.mk|0
board/{st/nhk8815 => calao/usb-s8815}/lcd.c| 34 +--
board/{st/nhk8815 => calao/usb-s8815}/platform.S |0
.../nhk8815.c => calao/usb-s8815/usb-s8815.c} | 40 +
drivers/mtd/nand/nomadik.c | 15 ++-
include/configs/{nhk8815.h => usb-s8815.h} | 98
9 files changed, 47 insertions(+), 151 deletions(-)
copy board/{st/nhk8815 => calao/usb-s8815}/Makefile (96%)
copy board/{st/nhk8815 => calao/usb-s8815}/config.mk (100%)
copy board/{st/nhk8815 => calao/usb-s8815}/lcd.c (68%)
copy board/{st/nhk8815 => calao/usb-s8815}/platform.S (100%)
copy board/{st/nhk8815/nhk8815.c => calao/usb-s8815/usb-s8815.c} (67%)
copy include/configs/{nhk8815.h => usb-s8815.h} (61%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: fix nhk8815 board name
From: Alessandro Rubini Signed-off-by: Alessandro Rubini --- The board files were renamed long ago, but back then I forgot to rename it in the maintainer file. MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3879fde..e8ba4bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -697,7 +697,7 @@ Stefan Roese Alessandro Rubini Nomadik Linux Team - nmdk8815ARM926EJS (Nomadik 8815 Soc) + nhk8815 ARM926EJS (Nomadik 8815 Soc) Steve Sakoman -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 6/9] lcd: make 16bpp work
Sorry for this late though about lcd issues.
> - lcd_color_fg : lcd_color_bg;
> + *d++ = (bits & 0x80) ? 0x : 0;
Here my patch uses hardwired 0 and ~0 for 16-bit pixels. Anatolij
suggested to use lcd_color_fg and lcd_color_bg as in the original
code, but unfortunately it doesn't work.
lcd_color_fg is set by common/lcd.c itself, using this function:
static void lcd_setfgcolor (int color)
{
#ifdef CONFIG_ATMEL_LCD
lcd_color_fg = color;
#else
lcd_color_fg = color & 0x0F;
#endif
}
So, however white I declare my color, it turns out blue. While I'd
understand a difference based on LCD_COLOR8 and LCD_COLOR16 (but even
in that case I'd request the caller to do the right thing avoiding
this late "fix"), I really can't tell why the atmel display is
different from other ones.
It's true that I can force lcd_color_fg to whatever I want, but only
after lcd_clear() is called. Moreover, if there's centralized I
wouldn't cowardly change it behind it's back.
This is one of the reasons why my original post was an RFC.
common/lcd.c is quite a mess and touching it is difficult.
At this point I still think forcing 0x and 0, ignoring
lcd_color_fg, is the right thing to do at least until atmel specifics
are removed from common/lcd.c.
BTW: I have a 9263ek an a 9261ek, so I might be able to try to propose
an atmel-related cleanup in the future, but not on short term,
unfortunately.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 9/9] nhk8815: added lcd support
From: Alessandro Rubini
This adds lcd support for the board. It includes defines for 32-bit
parameter as well, although support for LCD_COLOR32 is not yet in
u-boot. This uses the stmpe2401 to turn on display backlight.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/Makefile |1 +
board/st/nhk8815/lcd.c | 88
board/st/nhk8815/nhk8815-devices.h |1 +
board/st/nhk8815/nhk8815.c |3 +
include/configs/nhk8815.h | 10
5 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 board/st/nhk8815/lcd.c
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index 1bb1d2c..7155f12 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -31,6 +31,7 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y:= nhk8815.o
COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+COBJS-$(CONFIG_LCD) += lcd.o
COBJS := $(COBJS-y)
SOBJS := platform.o
diff --git a/board/st/nhk8815/lcd.c b/board/st/nhk8815/lcd.c
new file mode 100644
index 000..d3acb48
--- /dev/null
+++ b/board/st/nhk8815/lcd.c
@@ -0,0 +1,88 @@
+/*
+ * board/st/nhk8815/lcd.c: use amba clcd and STMPE2401 for backlight/reset
+ *
+ * Copyright 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+#include
+
+/* Two configurations are supported: 32bpp and 16bpp */
+#if LCD_BPP == LCD_COLOR32
+# define CLCD_CNTL_VAL 0x0019182b
+# define CLCD_BPIX_VAL 5 /* 1<<5 = 32 */
+#elif LCD_BPP == LCD_COLOR16
+# define CLCD_CNTL_VAL 0x001d1829
+# define CLCD_BPIX_VAL 4 /* 1<<4 = 16 */
+#else
+# error "Invalid LCD_BPP in config file"
+#endif
+
+/* Horribly, these are precomputed registers */
+struct clcd_config nhk8815_clcd_config = {
+ .address = (struct clcd_registers *)NOMADIK_CLCDC_BASE,
+ .tim0 = 0xd52600c4, /* horizontal timings */
+ .tim1 = 0x220a01df, /* vertical timings */
+ .tim2 = 0x031f1821, /* clock and signal polarity */
+ .tim3 = 0, /* not used */
+ .cntl = CLCD_CNTL_VAL, /* control, pixel size etc */
+ .pixclock = 18*1000*1000, /* 18 MHz */
+};
+
+/* This is the panel_info for generic boards. Too little info, actually */
+vidinfo_t panel_info = {
+ .vl_col = 800,
+ .vl_row = 480,
+ .vl_bpix = CLCD_BPIX_VAL,
+ .priv = &nhk8815_clcd_config,
+};
+
+/* Don't turn on (too early), but configure data lines and remove reset */
+void lcd_enable(void)
+{
+ int i;
+
+ /* Turn the alternate functions as needed */
+ for (i = 32; i <= 39; i++)
+ nmk_gpio_af(i, GPIO_ALT_B);
+
+ /* EXP1_GPIO_5 = output high -- remove reset from display */
+ pe_gpio_af(STMPE1, 5, PE_GPIO_AF_GPIO);
+ pe_gpio_dir(STMPE1, 5, 1);
+ pe_gpio_set(STMPE1, 5, 1);
+}
+
+/* Called from late_init: we turn on the backlight through port expander */
+int nhk8815_backlight_on(void)
+{
+ int i;
+
+ /* Turn the alternate functions as needed */
+ for (i = 32; i <= 39; i++)
+ nmk_gpio_af(i, GPIO_ALT_B);
+
+ /* EXP0_GPIO_21 = output high -- backlight */
+ pe_gpio_af(STMPE0, 21, PE_GPIO_AF_GPIO);
+ pe_gpio_dir(STMPE0, 21, 1);
+ pe_gpio_set(STMPE0, 21, 1);
+ return 0;
+}
diff --git a/board/st/nhk8815/nhk8815-devices.h
b/board/st/nhk8815/nhk8815-devices.h
index 78252ed..aec5825 100644
--- a/board/st/nhk8815/nhk8815-devices.h
+++ b/board/st/nhk8815/nhk8815-devices.h
@@ -3,5 +3,6 @@
/* Prototypes for functions exported by device files in this directory */
extern int nhk8815_keypad_init(void); /* ./keypad.c */
+extern int nhk8815_backlight_on(void); /* in ./lcd.c */
#endif /* __NHK8815_DEVICES__ */
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index fbabd15..fedb3c0 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -113,6 +113,9
[U-Boot] [PATCH V3 8/9] nhk8815: start lower in RAM, so the 800x480 frame buffer fits
From: Alessandro Rubini This simply moves u-boot to a lower address, as the frame buffer is allocated after u-boot itself in memory. Signed-off-by: Alessandro Rubini Acked-by: Andrea Gallo --- board/st/nhk8815/config.mk |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/board/st/nhk8815/config.mk b/board/st/nhk8815/config.mk index 590393b..6e5e358 100644 --- a/board/st/nhk8815/config.mk +++ b/board/st/nhk8815/config.mk @@ -18,9 +18,7 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA -# -# -# image should be loaded at 0x0100 -# -TEXT_BASE = 0x03F8 +# Start 4MB before the end, as the frame buffer is allocate after +# u-boot. 800x480 @ 32bpp takes 1.5MB alone, so let's play safe. +TEXT_BASE = 0x03c0 -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 7/9] nhk8815: added keypad
From: Alessandro Rubini
This patch adds keypad support for the nhk8815 board, based on the
stmpe2401 driver. The keypad hosts 16 keys, so each of them sends a
string instead of a single key. The provided keymap is only an
example and must be customized according to the use case.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/Makefile |5 ++-
board/st/nhk8815/keypad.c | 99
board/st/nhk8815/nhk8815-devices.h |7 +++
board/st/nhk8815/nhk8815.c |4 ++
include/configs/nhk8815.h |3 +
5 files changed, 117 insertions(+), 1 deletions(-)
create mode 100644 board/st/nhk8815/keypad.c
create mode 100644 board/st/nhk8815/nhk8815-devices.h
diff --git a/board/st/nhk8815/Makefile b/board/st/nhk8815/Makefile
index b37fe53..1bb1d2c 100644
--- a/board/st/nhk8815/Makefile
+++ b/board/st/nhk8815/Makefile
@@ -29,7 +29,10 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS := nhk8815.o
+COBJS-y:= nhk8815.o
+COBJS-$(CONFIG_NHK8815_KEYPAD) += keypad.o
+
+COBJS := $(COBJS-y)
SOBJS := platform.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/st/nhk8815/keypad.c b/board/st/nhk8815/keypad.c
new file mode 100644
index 000..4bbcce6
--- /dev/null
+++ b/board/st/nhk8815/keypad.c
@@ -0,0 +1,99 @@
+/*
+ * board/st/nhk8815/keypad.c: keypad on nhk8815 board, based on STMPE2401
+ *
+ * Copyright 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+#include
+
+/*
+ * Keymap for our 4x4 matrix: since we have just
+ * a few keys, use a string for each of the keys.
+ */
+static char *keymap[4][4] = {
+ {"", "back", "ffw", "left"},
+ {"", "tvout", "playpause", "right"},
+ {"vol-", "lock", "rew", "up"},
+ {"vol+", "start", "ok", "down"}
+};
+
+/* this keeps track of the string being returned */
+static char *nextchar = "";
+
+/* This getc can return failure, not permitted in the caller */
+static int __nhk8815_getc(void)
+{
+ int row, col, res;
+
+ res = pe_kpc_getkey(STMPE0, &row, &col);
+ if (res < 0)
+ return res; /* invalid */
+ nextchar = keymap[row][col];
+ return 0;
+}
+
+/* This is low level: may not report a valid key (a release, for example) */
+static int __nhk8815_tstc(void)
+{
+ /* the interrupt is active low */
+ int gpio = nmk_gpio_get(76);
+ return !gpio;
+}
+
+/* This is the one that is being called, it reads the pending string */
+static int nhk8815_tstc(void)
+{
+ if (*nextchar) /* there's already data */
+ return 1;
+ if (!__nhk8815_tstc()) /* no new data? */
+ return 0;
+ __nhk8815_getc(); /* get (or not) new data */
+ return (nextchar[0] != '\0');
+}
+
+/* So this is only called when there is data in the currenct string */
+static int nhk8815_getc(void)
+{
+ return *(nextchar++);
+}
+
+/* called from late init */
+int nhk8815_keypad_init(void)
+{
+ struct stdio_dev dev;
+
+ /* The keypad is on EXP0, columns 0..3, rows 0..3 */
+ pe_kpc_init(STMPE0, 0x0f, 0x0f, 30 /* ms */);
+
+ /* Keypad interrupt: GPIO76 */
+ nmk_gpio_af(76, GPIO_GPIO);
+ nmk_gpio_dir(76, 0);
+
+ memset (&dev, 0, sizeof (dev));
+ dev.flags = DEV_FLAGS_INPUT;
+ dev.getc = nhk8815_getc;
+ dev.tstc = nhk8815_tstc;
+ strcpy(dev.name, "keypad");
+ stdio_register(&dev);
+ return 0;
+}
diff --git a/board/st/nhk8815/nhk8815-devices.h
b/board/st/nhk8815/nhk8815-devices.h
new file mode 100644
index 000..78252ed
--- /dev/null
+++ b/board/st/nhk8815/nhk8815-devices.h
@@ -0,0 +1,7 @@
+#ifndef __NHK8815_DEVICES__
+#define __NHK8815_DEVICES__
+
+/* Prototypes for functions exported by device files in this directory */
+extern int nhk8815_keypad_init(void); /* ./keypad.c */
+
+#endif /* __NHK8815_DEVICES__ */
diff --git a/board/st/nhk8815/
[U-Boot] [PATCH V3 6/9] lcd: make 16bpp work
From: Alessandro Rubini
Support for 16bpp was supposed to be in the code but was not working.
This makes it work and has been tested in the nhk8815 board.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
common/lcd.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 4e31618..3d9bfdf 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -63,7 +63,7 @@
//
#ifdef CONFIG_LCD_LOGO
# include /* Get logo data, width and height */
-# if (CONSOLE_COLOR_WHITE >= BMP_LOGO_OFFSET)
+# if (CONSOLE_COLOR_WHITE >= BMP_LOGO_OFFSET) && (LCD_BPP != LCD_COLOR16)
# error Default Color Map overlaps with Logo Color Map
# endif
#endif
@@ -218,8 +218,12 @@ static void lcd_drawchars (ushort x, ushort y, uchar *str,
int count)
for (row=0; row < VIDEO_FONT_HEIGHT; ++row, dest += lcd_line_length)
{
uchar *s = str;
- uchar *d = dest;
int i;
+#if LCD_BPP == LCD_COLOR16
+ ushort *d = (ushort *)dest;
+#else
+ uchar *d = dest;
+#endif
#if LCD_BPP == LCD_MONOCHROME
uchar rest = *d & -(1 << (8-off));
@@ -244,9 +248,8 @@ static void lcd_drawchars (ushort x, ushort y, uchar *str,
int count)
bits <<= 1;
}
#elif LCD_BPP == LCD_COLOR16
- for (c=0; c<16; ++c) {
- *d++ = (bits & 0x80) ?
- lcd_color_fg : lcd_color_bg;
+ for (c=0; c<8; ++c) {
+ *d++ = (bits & 0x80) ? 0x : 0;
bits <<= 1;
}
#endif
@@ -529,6 +532,13 @@ void bitmap_plot (int x, int y)
cmap = (ushort
*)&(cp->lcd_cmap[BMP_LOGO_OFFSET*sizeof(ushort)]);
#elif defined(CONFIG_ATMEL_LCD)
cmap = (uint *) (panel_info.mmio + ATMEL_LCDC_LUT(0));
+#else
+ /*
+* default case: generic system with no cmap (most likely 16bpp)
+* We set cmap to the source palette, so no change is done.
+* This avoids even more ifdef in the next stanza
+*/
+ cmap = bmp_logo_palette;
#endif
WATCHDOG_RESET();
@@ -567,10 +577,15 @@ void bitmap_plot (int x, int y)
}
}
else { /* true color mode */
+ u16 col16;
fb16 = (ushort *)(lcd_base + y * lcd_line_length + x);
for (i=0; ihttp://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 5/9] nhk8815.h: define we need stmpe
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
include/configs/nhk8815.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/configs/nhk8815.h b/include/configs/nhk8815.h
index a00c2fb..e1be45b 100644
--- a/include/configs/nhk8815.h
+++ b/include/configs/nhk8815.h
@@ -110,7 +110,7 @@
#define CONFIG_PL01x_PORTS { (void *)CFG_SERIAL0, (void *)CFG_SERIAL1 }
#define CONFIG_PL011_CLOCK 4800
-/* i2c, for the port extenders (uses gpio.c in board directory) */
+/* i2c, for the stmpe2401 port extenders (uses gpio.c in board directory) */
#ifndef __ASSEMBLY__
#include
#define CONFIG_CMD_I2C
@@ -126,6 +126,11 @@
#define I2C_DELAY (udelay(2))
#endif /* __ASSEMBLY__ */
+/* Activate port extenders and define their i2c address */
+#define CONFIG_STMPE2401
+#define STMPE0 0x43
+#define STMPE1 0x44
+
/* Ethernet */
#define PCI_MEMORY_VADDR 0xe800
#define PCI_IO_VADDR 0xee00
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/9] drivers/misc: add stmpe2401 port extender and keypad controller
From: Alessandro Rubini
This driver is an i2c device acting as a port extender. Since
the keypad can be configured to act on specific row and column lines,
the specific setup is passed by the board file. This is used by
the Nomadik nhk8815, through a later patch in this series.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
drivers/misc/Makefile|1 +
drivers/misc/stmpe2401.c | 191 ++
include/stmpe2401.h | 66
3 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/stmpe2401.c
create mode 100644 include/stmpe2401.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f6df60f..76c009a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,6 +30,7 @@ COBJS-$(CONFIG_DS4510) += ds4510.o
COBJS-$(CONFIG_FSL_LAW) += fsl_law.o
COBJS-$(CONFIG_NS87308) += ns87308.o
COBJS-$(CONFIG_STATUS_LED) += status_led.o
+COBJS-$(CONFIG_STMPE2401) += stmpe2401.o
COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
COBJS := $(COBJS-y)
diff --git a/drivers/misc/stmpe2401.c b/drivers/misc/stmpe2401.c
new file mode 100644
index 000..f347d07
--- /dev/null
+++ b/drivers/misc/stmpe2401.c
@@ -0,0 +1,191 @@
+/*
+ * board/st/nhk8815/egpio.c: extended gpio as found on nhk8815 board
+ *
+ * Copyright 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+
+/*
+ * First, an interface to set and read registers, used in this file as well
+ */
+int pe_getreg(int addr, int reg)
+{
+ unsigned char val8 = reg;
+ int ret;
+
+ ret = i2c_read(addr, reg, 1 /* len */, &val8, 1);
+ if (ret < 0)
+ return ret;
+ return val8;
+}
+
+int pe_setreg(int addr, int reg, int val)
+{
+ unsigned char val8 = val;
+
+ return i2c_write(addr, reg, 1, &val8, 1);
+}
+
+/*
+ * Generic higher-level GPIO interface
+ */
+int pe_gpio_af(int addr, int pin, int af)
+{
+ int regval;
+
+ regval = pe_getreg(addr, PE_GPIO_AFR(pin));
+ if (regval < 0)
+ return regval;
+ regval &= ~PE_GPIO_AF_MASK(pin);
+ regval |= af << PE_GPIO_AF_SHIFT(pin);
+ return pe_setreg(addr, PE_GPIO_AFR(pin), regval);
+}
+
+int pe_gpio_dir(int addr, int pin, int dir)
+{
+ int regval;
+
+ /* 0 == input, 1 == output */
+ regval = pe_getreg(addr, PE_GPIO_GPDR(pin));
+ if (regval < 0)
+ return regval;
+ regval &= ~PE_GPIO_MASK(pin);
+ if (dir)
+ regval |= PE_GPIO_MASK(pin);
+ return pe_setreg(addr, PE_GPIO_GPDR(pin), regval);
+}
+
+int pe_gpio_pud(int addr, int pin, int pu, int pd)
+{
+ int regval, mask = PE_GPIO_MASK(pin);
+
+ /* change pullup */
+ regval = pe_getreg(addr, PE_GPIO_GPPUR(pin));
+ if (regval < 0)
+ return regval;
+ if (pu)
+ regval |= mask;
+ else
+ regval &= ~mask;
+ regval = pe_setreg(addr, PE_GPIO_GPPUR(pin), regval);
+ if (regval < 0)
+ return regval;
+
+ /* change pulldown */
+ regval = pe_getreg(addr, PE_GPIO_GPPDR(pin));
+ if (regval < 0)
+ return regval;
+ if (pu)
+ regval |= mask;
+ else
+ regval &= ~mask;
+ regval = pe_setreg(addr, PE_GPIO_GPPDR(pin), regval);
+ if (regval < 0)
+ return regval;
+
+ return 0;
+}
+
+int pe_gpio_set(int addr, int pin, int val)
+{
+ int reg;
+
+ if (val)
+ reg = PE_GPIO_GPSR(pin);
+ else
+ reg = PE_GPIO_GPCR(pin);
+
+ return pe_setreg(addr, reg, PE_GPIO_MASK(pin));
+}
+
+int pe_gpio_get(int addr, int pin)
+{
+ int regval;
+
+ regval = pe_getreg(addr, PE_GPIO_GPMR(pin));
+ if (regval < 0)
+ return regval;
+ return (regval & PE_GPIO_MASK(pin)) ? 1 : 0;
+}
+
+/*
+ * Generic higher-level keypad interface: we have 12 rows out, 8 columns in
+ */
+int pe_kpc_init(int addr, int rowmask, int colmask, int debounce_ms)
+{
+ int i;
+ /* note that gpio15 is missing
[U-Boot] [PATCH V3 3/9] include/nomadik.h: add physical address for cldc
From: Alessandro Rubini Signed-off-by: Alessandro Rubini Acked-by: Andrea Gallo --- include/nomadik.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/nomadik.h b/include/nomadik.h index d9405fd..ea65b2d 100644 --- a/include/nomadik.h +++ b/include/nomadik.h @@ -4,6 +4,7 @@ #define __NOMADIK_H__ /* Base addresses of our peripherals */ +#define NOMADIK_CLCDC_BASE 0x1012 /* CLCD Controller */ #define NOMADIK_SRC_BASE 0x101E /* System and Reset Cnt */ #define NOMADIK_PMU_BASE 0x101E9000 /* Power Management Unit */ #define NOMADIK_MPMC_BASE 0x1011 /* SDRAM Controller */ -- 1.6.0.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/9] video: add amba-clcd prime-cell
From: Alessandro Rubini
This adds support for the CLCD logic cell. It accepts precompiled
register values for specific configuration through a board-supplied
data structure. It is used by the Nomadik nhk8815, added by a later
patch in this series.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
drivers/video/Makefile |1 +
drivers/video/amba.c | 79
include/amba_clcd.h| 77 ++
3 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/amba.c
create mode 100644 include/amba_clcd.h
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index bb6b5a0..a5e339a 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -29,6 +29,7 @@ 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_AMBA) += amba.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o
diff --git a/drivers/video/amba.c b/drivers/video/amba.c
new file mode 100644
index 000..ffa1c39
--- /dev/null
+++ b/drivers/video/amba.c
@@ -0,0 +1,79 @@
+/*
+ * Driver for AMBA PrimeCell CLCD
+ *
+ * Copyright (C) 2009 Alessandro Rubini
+ *
+ * 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
+#include
+#include
+#include
+
+/* These variables are required by lcd.c -- although it sets them by itself */
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+void *lcd_base;
+void *lcd_console_address;
+short console_col;
+short console_row;
+
+/*
+ * To use this driver you need to provide the following in board files:
+ * a panel_info definition
+ * an lcd_enable function (can't define a weak default with current code)
+ */
+
+/* There is nothing to do with color registers, we use true color */
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+ return;
+}
+
+/* Low level initialization of the logic cell: depends on panel_info */
+void lcd_ctrl_init(void *lcdbase)
+{
+ struct clcd_config *config;
+ struct clcd_registers *regs;
+ u32 cntl;
+
+ config = panel_info.priv;
+ regs = config->address;
+ cntl = config->cntl & ~CNTL_LCDEN;
+
+ /* Lazily, just copy the registers over: first control with disable */
+ writel(cntl, ®s->cntl);
+
+ writel(config->tim0, ®s->tim0);
+ writel(config->tim1, ®s->tim1);
+ writel(config->tim2, ®s->tim2);
+ writel(config->tim3, ®s->tim3);
+ writel((u32)lcdbase, ®s->ubas);
+ /* finally, enable */
+ writel(cntl | CNTL_LCDEN, ®s->cntl);
+}
+
+/* This is trivial, and copied from atmel_lcdfb.c */
+ulong calc_fbsize(void)
+{
+ return ((panel_info.vl_col * panel_info.vl_row *
+ NBITS(panel_info.vl_bpix)) / 8) + PAGE_SIZE;
+}
diff --git a/include/amba_clcd.h b/include/amba_clcd.h
new file mode 100644
index 000..db80517
--- /dev/null
+++ b/include/amba_clcd.h
@@ -0,0 +1,77 @@
+/*
+ * Register definitions for the AMBA CLCD logic cell.
+ *
+ * derived from David A Rusling, although rearranged as a C structure
+ * linux/include/asm-arm/hardware/amba_clcd.h -- Integrator LCD panel.
+ *
+ * Copyright (C) 2001 ARM Limited
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * CLCD Controller Internal Register addresses
+ */
+struct clcd_registers {
+ u32 tim0; /* 0x00 */
+ u32 tim1;
+ u32 tim2;
+ u32 tim3;
+ u32 ubas; /* 0x10 */
+ u32 lbas;
+#if !defined(CONFIG_ARCH_VERSATILE) && !defined(CONFIG_ARCH_REALVIEW)
+ u32 ienb;
+ u32 cntl;
+#else /* Someone rearranged these two registers on the Versatile */
+ u32 cntl;
+ u32 ienb;
+#endif
+ u32 stat; /* 0x20 */
+ u32 intr;
+ u32 ucur;
+ u32 lcur;
+ u32 unused[0x74]; /* 0x030..
[U-Boot] [PATCH V3 1/9] nhk8815: change the order of initialization
From: Alessandro Rubini
Some inizialization was in board_late_init(), but to satisfy drivers
added in the next patches must be performed in normal board_init.
This patch leaves board_late_init() empty, but later patches fill it.
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
board/st/nhk8815/nhk8815.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/board/st/nhk8815/nhk8815.c b/board/st/nhk8815/nhk8815.c
index faef810..eadce40 100644
--- a/board/st/nhk8815/nhk8815.c
+++ b/board/st/nhk8815/nhk8815.c
@@ -60,22 +60,26 @@ int board_init(void)
writel(0x02100551, NOMADIK_FSMC_BASE + 0x04); /* FSMC_BTR0 */
icache_enable();
- return 0;
-}
-int board_late_init(void)
-{
+ /*
+* Configure I2C pins, as we will use I2C in a later commit
+*/
+
/* Set the two I2C gpio lines to be gpio high */
nmk_gpio_set(__SCL, 1); nmk_gpio_set(__SDA, 1);
nmk_gpio_dir(__SCL, 1); nmk_gpio_dir(__SDA, 1);
nmk_gpio_af(__SCL, GPIO_GPIO); nmk_gpio_af(__SDA, GPIO_GPIO);
- /* Reset the I2C port expander, on GPIO77 */
- nmk_gpio_af(77, GPIO_GPIO);
- nmk_gpio_dir(77, 1);
- nmk_gpio_set(77, 0);
- udelay(10);
- nmk_gpio_set(77, 1);
+ /* Put the two I2C port expanders out of reset, on GPIO77 and 79 */
+ {
+ int n[2]={77, 79};
+ int i;
+ for (i = 0; i < ARRAY_SIZE(n); i++) {
+ nmk_gpio_af(n[i], GPIO_GPIO);
+ nmk_gpio_dir(n[i], 1);
+ nmk_gpio_set(n[i], 1);
+ }
+ }
return 0;
}
@@ -101,3 +105,10 @@ int board_eth_init(bd_t *bis)
return rc;
}
#endif
+
+/* Initialization callback, from lib_arm/board.c */
+int board_late_init(void)
+{
+ return 0;
+}
+
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/9] display and keypad support for nhk8815
This patch series is very similar to V2 I sent on Nov 25th, only 2/9 and 9/9 are different. Changes from V2: * the clcd driver using a C structure instead of numeric defines for register offsets. Renamed previous clcdc_regs to clcd_config, since regs is now the hardware-description structure. * added "address" field to clcd_config, so clcd.c doesn't include anithing specific to Nomadik and can be use unchanged by other clcd-equipped SoCs. ps: Wolfgang: while I understand patches must be posted, I offered to avoid extra traffic if it was only a matter of removing printf. Won't do that again, lesson learnt. Alessandro Rubini (9): nhk8815: change the order of initialization video: add amba-clcd prime-cell include/nomadik.h: add physical address for cldc drivers/misc: add stmpe2401 port extender and keypad controller nhk8815.h: define we need stmpe lcd: make 16bpp work nhk8815: added keypad nhk8815: start lower in RAM, so the 800x480 frame buffer fits nhk8815: added lcd support board/st/nhk8815/Makefile |6 +- board/st/nhk8815/config.mk |8 +- board/st/nhk8815/keypad.c | 99 +++ board/st/nhk8815/lcd.c | 88 + board/st/nhk8815/nhk8815-devices.h |8 ++ board/st/nhk8815/nhk8815.c | 38 +-- common/lcd.c | 27 - drivers/misc/Makefile |1 + drivers/misc/stmpe2401.c | 191 drivers/video/Makefile |1 + drivers/video/amba.c | 79 +++ include/amba_clcd.h| 77 +++ include/configs/nhk8815.h | 20 - include/nomadik.h |1 + include/stmpe2401.h| 66 15 files changed, 687 insertions(+), 23 deletions(-) create mode 100644 board/st/nhk8815/keypad.c create mode 100644 board/st/nhk8815/lcd.c create mode 100644 board/st/nhk8815/nhk8815-devices.h create mode 100644 drivers/misc/stmpe2401.c create mode 100644 drivers/video/amba.c create mode 100644 include/amba_clcd.h create mode 100644 include/stmpe2401.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Breakage on arm/next
> Could the macros defined in apollo.h also be defined in the
> other target board's config file ?
I don't think so (my board is one of the affected ones).
The macros are CONFIG_ENV_ADDR_FLEX and CONFIG_ENV_SIZE_FLEX . I just
don't have the flex device.
In the commit that introduced the problem, I see code like this:
env_addr = CONFIG_ENV_ADDR;
+ if (FLEXONENAND(this))
+ env_addr = CONFIG_ENV_ADDR_FLEX;
So why should CONFIG_ENV_ADDR_FLEX have a different name from CONFIG_ENV_ADDR ?
Same applies to CONFIG_ENV_SIZE_FLEX.
I think c758e947aa7d39a2be607ecdedd818ad300807b2 should be reverted
and done differently. If I got my reasoning right, the first hunk
should go and the next one:
instr.len = CONFIG_ENV_SIZE;
+ if (FLEXONENAND(this)) {
+ env_addr = CONFIG_ENV_ADDR_FLEX;
+ instr.len = CONFIG_ENV_SIZE_FLEX;
+ instr.len <<= onenand_mtd.eraseregions[0].numblocks == 1 ?
+ 1 : 0;
+ }
Shoul just become
+ if (FLEXONENAND(this))
+ instr.len <<= onenand_mtd.eraseregions[0].numblocks == 1 ? 1 :
0;
This has no adverse effect on other boards and handles the flex specifics,
withouth adding two unneeded macros.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/9] video: add amba-clcd prime-cell
> I understand your arguments. If Wolfgang will not reject my pull > request, I'm fine with it. Could you please use something like: Ok, I'll rearrange as a data structure as you both suggest. [I noted you already did the work for me in your message, thanks for that] /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/9] video: add amba-clcd prime-cell
Hello
>> +#define CLCD_LBAS 0x0014
>
> CLCD_LBAS isn't used in the code, please remove it.
I disagree for two reasons: the register exists in the logic block,
and the code is copied from a linux header (as noted in the file itself).
Since the clcd block is not something designed for the nomadik but the
standard primecell, I don't think trimming its definition is useful;
other boards can benefit from the header being complete.
>> +/* u-boot specific: cooked information (not used at this point) */
>> +struct clcd_params {
>> +int left_margin, right_margin, upper_margin, lower_margin;
>> +int hsync_len, vsync_len;
>> +int sync, vmode;
>> +};
>
> this is also not used, please do not add unused code.
I planned to used it, and this is the complete information that's
needed, and I plan to implement it sooner or later. Nonetheless, I
understand your request to remove it and I have no problems here.
> I couldn't comment on this in the first patch version, sorry.
Ok, no problem.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc: transform init_sequence into a function.
> I think most of the ugliness comes from the #ifdef hell in this list. > replacing the #ifdefs is another matter so looking behind > the #ifdef mess, I don't think it looks too bad. I think the approach I took with lib_arm/board.c may apply as well. A simple weak init_nop(), no change at all in board code and no more "CONFIG_BOARD_EARLY_INIT_F" kind of stuff. >> This is much more ugly, and I cannot see why it would be easier to >> debug. > > You can set breakpoints anywhere you like. When it crashes in here > somewhere, it isn't easy to tell where it did so. I agree it is uglier (and I've discussed with Joakim offlist), this is a very strong point. I never had problems with the u-boot init function, I had serious issues with kernel initcalls. Whils debug_initcall is great and good in the kernel, we can't do with printf ini u-boot, not in the first steps, at least. So while I strongly prefer data structures to a burst of "if () goto error;", I think Joakim has a point here -- after I argued against it offlist. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
