[U-Boot] Strange data behaviour
Hi,
I'm trying to get my LPC2468 based board to work. I've some problems with the external memory databus. I would like to know the settings of internal registers to see whether I've initialized them correctly, so I tried making a function that prints the content over the serial link. I'm still in the lowlevel_init function, so I do not have the U-boot puts functions available. I wrote the following function to convert a long to a HEX string: ------------------- void print_long(unsigned long data) { char i; char hex_data[]={'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};
for(i=0; i<8; i++) { while((U0LSR & (1<<5)) == 0); /* Wait for empty U0THR */ // U0THR = hex_data[(0xDEADBEEF>>i*4)&0xF]; U0THR = hex_data[(0xDEADBEEF>>4)&0xF]; } } --------------- When I run it likes this I get 8 E's. Which is what I expect. When I run it with the commented-out line, I get back 8 0x0's. So it seems that the output is only correct when it is constant. Does anyone have a clue on why that is?
Kind regards,
Remco Poelstra
Dear Remco Poelstra,
In message 499AA5B8.7030805@duran-audio.com you wrote:
I'm trying to get my LPC2468 based board to work. I've some problems with the external memory databus. I would like to know the settings of internal registers to see whether I've initialized them correctly, so I tried making a function that prints the content over the serial link. I'm still in the lowlevel_init function, so I do not have the U-boot puts functions available. I wrote the following function to convert a long to a HEX string:
void print_long(unsigned long data) { char i; char hex_data[]={'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};
for(i=0; i<8; i++) { while((U0LSR & (1<<5)) == 0); /* Wait for empty U0THR */ // U0THR = hex_data[(0xDEADBEEF>>i*4)&0xF];
For clearity of the code I would write that as "...>>(i*4)...", but that's not relevant here.
U0THR = hex_data[(0xDEADBEEF>>4)&0xF];} }
When I run it likes this I get 8 E's. Which is what I expect. When I run it with the commented-out line, I get back 8 0x0's. So it seems that the output is only correct when it is constant. Does anyone have a clue on why that is?
What exactly is U0THR ?
The only definition I can find in the U-Boot sources is here:
include/asm-arm/arch-lpc2292/lpc2292_registers.h:#define U0THR 0xE000C000
but that is obviously not what you are using.
You probably forget the effects of compiler optimization and/or caching here.
I bet you are using a plain pointer access without a "volatile", which is essential here. Maybe even some form of "sync" is needed. In any case, you should use appropriate accessor functions to access device registers.
Best regards,
Wolfgang Denk
Wolfgang Denk schreef:
U0THR = hex_data[(0xDEADBEEF>>4)&0xF];} }
When I run it likes this I get 8 E's. Which is what I expect. When I run it with the commented-out line, I get back 8 0x0's. So it seems that the output is only correct when it is constant. Does anyone have a clue on why that is?
What exactly is U0THR ?
Hi,
Thanks for your reply.
For my processor, U0THR is defnied as: #define U0THR (*(volatile unsigned char *)(UART0_BASE_ADDR + 0x00))
UART0_BASE_ADDR is equal to 0xE000C000
The register itself represents the top of the UART0 transmit FIFO.
The only definition I can find in the U-Boot sources is here:
include/asm-arm/arch-lpc2292/lpc2292_registers.h:#define U0THR 0xE000C000
but that is obviously not what you are using.
You probably forget the effects of compiler optimization and/or caching here.
I bet you are using a plain pointer access without a "volatile", which is essential here. Maybe even some form of "sync" is needed. In any case, you should use appropriate accessor functions to access device registers.
I do not know any accessor functions. What do you mean with a "sync"?
Kind regards,
Remco Poelstra
On Wed, 18 Feb 2009 09:19:08 +0100 Remco Poelstra remco.poelstra@duran-audio.com wrote:
Wolfgang Denk schreef:
I bet you are using a plain pointer access without a "volatile", which is essential here. Maybe even some form of "sync" is needed. In any case, you should use appropriate accessor functions to access device registers.
I do not know any accessor functions.
things like out_be32 (at least that's what it's called on ppc arch).
What do you mean with a "sync"?
it's a processor instruction that ensures that memory and/or i/o accesses occur exactly when you specify they occur. For this reason, a sync instruction is included as a part of the accessor functions.
Kim
participants (3)
-
Kim Phillips -
Remco Poelstra -
Wolfgang Denk