> 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
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
ven
lling 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 100
s 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
dri
Acked-by: Alessandro Rubini
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
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 +
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 +--
in
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
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
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 t
>> 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
> 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 saf
> 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
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
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
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.
Th
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
lo
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
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
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
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 hi
> 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
>> 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 assem
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;
> 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) ==
> 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 a
>> 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_SI
> + /* 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
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
> 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,
>> 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.0
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 choic
> 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 2
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.
> * 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 i
>> 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 ne
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
>> 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 p
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
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
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
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
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
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
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
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
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.
Alessan
>> > .../{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
> - 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, b
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) {
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
e6a9
> 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
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
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
__
> 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 differe
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/ed
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
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
> 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 seco
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
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
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
ill 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 c
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
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 |
> 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
> 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
>> 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 def
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
> 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
ool 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,
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 --
nt, 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 a
[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 her
> 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()
>
> 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.
/alessandr
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
> 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 th
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 i
[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 no
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}/con
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
. 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"
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
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 o
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
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
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
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
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
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
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
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
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
. 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
> 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 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
_
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 f
> 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 b
1 - 100 of 248 matches
Mail list logo
