[U-Boot-Users] Runtime switch from uart0 to uart1?

Greetings:
After having read the README and some code, I was wondering if there is a way to switch, at runtime (rather than at compile time) from UART0 to UART1.
The board is the ocotea, ppc440gx, u-boot 1.1.2, build tools from ELDK3
TIA,
Travis

In message 1092921384.24546.9.camel@pavement.sandburst.com you wrote:
After having read the README and some code, I was wondering if there is a way to switch, at runtime (rather than at compile time) from UART0 to UART1.
The board is the ocotea, ppc440gx, u-boot 1.1.2, build tools from ELDK3
Not out of the box. But doc/README.serial_multi shows what we did on MPC8xx processors; this can be used as a starting point to extend it for 4xx as well.
Best regards,
Wolfgang Denk

On Thu, 2004-08-19 at 10:16, Wolfgang Denk wrote:
In message 1092921384.24546.9.camel@pavement.sandburst.com you wrote:
After having read the README and some code, I was wondering if there is a way to switch, at runtime (rather than at compile time) from UART0 to UART1.
The board is the ocotea, ppc440gx, u-boot 1.1.2, build tools from ELDK3
Not out of the box. But doc/README.serial_multi shows what we did on MPC8xx processors; this can be used as a starting point to extend it for 4xx as well.
Best regards,
Wolfgang Denk
Wolfgang:
Thanx. I've been tasked out by my higher-ups to do this. I'm planning on adding the code directly to cpu/ppc4xx/serial.c.
However, I think this is going to add a little bit of text space even if CONFIG_SERIAL_MULTI is not defined.
For example:
Currently we have int serial_init(void) {...}
My vision:
int serial_init_dev(unsigned long dev_base) {...}
with: #if !defined(CONFIG_SERIAL_MULTI) int serial_init(void) { return(serial_init_dev(ACTING_UART0_BASE)); } #else int serial0_init(void) { return(serial_init_dev(UART0_BASE)); }
int serial1_init(void) { return(serial_init_dev(UART1_BASE)); } #endif
There are several functions that will need to have this done, thus adding 1 layer of indirection to the current code to allow for multiple serial channels.
Do you think this is OK? I _*KNOW_* the readme says not to add options that will bloat the code when the option is off.
Thank you,
Travis Sawyer

In message 1095207529.2892.12.camel@localhost.localdomain you wrote:
Thanx. I've been tasked out by my higher-ups to do this. I'm planning on adding the code directly to cpu/ppc4xx/serial.c.
Fine.
However, I think this is going to add a little bit of text space even if CONFIG_SERIAL_MULTI is not defined.
You know the reply: I don't like this idea ;-)
There are several functions that will need to have this done, thus adding 1 layer of indirection to the current code to allow for multiple serial channels.
Maybe we can use function pointers instead which can be overloaded? [Just be careful and remember that function pointers don't get relocated automagically.]
Best regards,
Wolfgang Denk

On Wed, 2004-09-15 at 04:21, Wolfgang Denk wrote:
However, I think this is going to add a little bit of text space even if CONFIG_SERIAL_MULTI is not defined.
You know the reply: I don't like this idea ;-)
There are several functions that will need to have this done, thus adding 1 layer of indirection to the current code to allow for multiple serial channels.
Maybe we can use function pointers instead which can be overloaded? [Just be careful and remember that function pointers don't get relocated automagically.]
Hmmm... Wouldn't this also increase the text and data space?
Regardless, I've gotten multiple serial to work on the ocotea board. I'll attempt to change the code so as to keep the non multi code the same size. However, for maintenance I think it will be more of a problem than what I currently have. I did an objdump of the original object file, the new one both with and with out multi turned on:
Original: Idx Name Size VMA LMA File off Algn 0 .text 00000610 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000000 00000000 00000000 00000644 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000644 2**0 ALLOC 3 .debug_abbrev 000001e6 00000000 00000000 00000644 2**0 CONTENTS, READONLY, DEBUGGING 4 .debug_info 00004c3e 00000000 00000000 0000082a 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 5 .debug_line 000005ce 00000000 00000000 00005468 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 6 .debug_frame 00000160 00000000 00000000 00005a38 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 7 .debug_pubnames 000000d2 00000000 00000000 00005b98 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 8 .debug_aranges 00000020 00000000 00000000 00005c6a 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 9 .debug_str 0000003d 00000000 00000000 00005c8a 2**0 CONTENTS, READONLY, DEBUGGING 10 .comment 0000003d 00000000 00000000 00005cc7 2**0 CONTENTS, READONLY
NEW (MULTI OFF) Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000638 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000000 00000000 00000000 0000066c 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 0000066c 2**0 ALLOC 3 .debug_abbrev 0000020a 00000000 00000000 0000066c 2**0 CONTENTS, READONLY, DEBUGGING 4 .debug_info 00004cb2 00000000 00000000 00000876 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 5 .debug_line 00000689 00000000 00000000 00005528 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 6 .debug_frame 000001e8 00000000 00000000 00005bb4 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 7 .debug_pubnames 0000014c 00000000 00000000 00005d9c 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 8 .debug_aranges 00000020 00000000 00000000 00005ee8 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 9 .debug_str 0000003d 00000000 00000000 00005f08 2**0 CONTENTS, READONLY, DEBUGGING 10 .comment 0000003d 00000000 00000000 00005f45 2**0 CONTENTS, READONLY
New (MULTI ON): Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000768 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000068 00000000 00000000 0000079c 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .bss 00000000 00000000 00000000 00000804 2**0 ALLOC 3 .debug_abbrev 00000236 00000000 00000000 00000804 2**0 CONTENTS, READONLY, DEBUGGING 4 .debug_info 00004ec9 00000000 00000000 00000a3a 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 5 .debug_line 00000809 00000000 00000000 00005903 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 6 .debug_frame 00000274 00000000 00000000 0000610c 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 7 .debug_pubnames 000001e0 00000000 00000000 00006380 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 8 .debug_aranges 00000020 00000000 00000000 00006560 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 9 .debug_str 0000003d 00000000 00000000 00006580 2**0 CONTENTS, READONLY, DEBUGGING 10 .comment 0000003d 00000000 00000000 000065bd 2**0 CONTENTS, READONLY
So, as you can see, the new source with MULTI OFF is a little larger.
If it is preferred to _*ABSOLUTELY*_ keep the size the same I'll try some surgery.
Thanx
Travis

On Wed, 2004-09-15 at 09:41, Travis Sawyer wrote:
On Wed, 2004-09-15 at 04:21, Wolfgang Denk wrote:
However, I think this is going to add a little bit of text space even if CONFIG_SERIAL_MULTI is not defined.
You know the reply: I don't like this idea ;-)
<SNIP>
Regardless, I've gotten multiple serial to work on the ocotea board. I'll attempt to change the code so as to keep the non multi code the same size. However, for maintenance I think it will be more of a problem than what I currently have. I did an objdump of the original object file, the new one both with and with out multi turned on:
<SNIP>
If it is preferred to _*ABSOLUTELY*_ keep the size the same I'll try some surgery.
Here I am answering my own post (again).
Surgery has been performed. text and data are the same for orignal and new with MULTI turned off. (Phew!)
Patch will follow as soon as MAKEALL is done.
Should I update doc/README.serial_multi?
thx
travis

Dear Travis,
in message 1095255660.7405.10.camel@pavement.sandburst.com you wrote:
Hmmm... Wouldn't this also increase the text and data space?
Proably, but it might also increase the readbility of the code?
Original: Idx Name Size VMA LMA File off Algn 0 .text 00000610 00000000 00000000 00000034 2**2 1 .data 00000000 00000000 00000000 00000644 2**0 2 .bss 00000000 00000000 00000000 00000644 2**0
...
NEW (MULTI OFF) 0 .text 00000638 00000000 00000000 00000034 2**2 1 .data 00000000 00000000 00000000 0000066c 2**0 2 .bss 00000000 00000000 00000000 0000066c 2**0
...
New (MULTI ON): Idx Name Size VMA LMA File off Algn 0 .text 00000768 00000000 00000000 00000034 2**2 1 .data 00000068 00000000 00000000 0000079c 2**2 2 .bss 00000000 00000000 00000000 00000804 2**0
So we're talking about 0x638 vs. 0x610 or 40 bytes? Let's be reasonable - I consider this background noise.
Don't waste any effort on this.
Best regards,
Wolfgang Denk
participants (3)
-
Travis B. Sawyer
-
Travis Sawyer
-
Wolfgang Denk