[U-Boot-Users] Porting UBoot without UART
Hi,
We're using some emulation box to develop our SoC. Somehow the UART will the last component available for firmware development. Without UART, it's very hard to debug UBoot. Can we "easily" drive a car without eyes?
But it's not impossible to do that. My first thought about porting UBoot under this circumstance is to disable the serial driver in UBoot and to redirect all printf to a fixed memory area, just as what a circular log buffer does. I'm wondering how much workload this will be. Is this kind of mechasim already existent in UBoot?
Thank you for your comments. -Shawn.
On Tue, Feb 22, 2005 at 11:21:01AM -0800, Shawn Jin wrote:
My first thought about porting UBoot under this circumstance is to disable the serial driver in UBoot and to redirect all printf to a fixed memory area, just as what a circular log buffer does. I'm wondering how much workload this will be. Is this kind of mechasim already existent in UBoot?
Provide our own console functions. See common/console.c and common/devices.c how it is initialized and used.
Best regards, ladis
In message 20050222194931.GA13447@linux-mips.org you wrote:
Provide our own console functions. See common/console.c and common/devices.c how it is initialized and used.
Note thatt he "devices" are intialized pretty late in the boot sequence. Until then, all of the most of the important console messages have already beeen printed.
Best regards,
Wolfgang Denk
On Thu, 24 Feb 2005 23:39:33 +0100, Wolfgang Denk wd@denx.de wrote:
In message 20050222194931.GA13447@linux-mips.org you wrote:
Provide our own console functions. See common/console.c and common/devices.c how it is initialized and used.
Note thatt he "devices" are intialized pretty late in the boot sequence. Until then, all of the most of the important console messages have already beeen printed.
From the original post: "We're using some emulation box to develop our
SoC. Somehow the UART will the last component available for firmware development."
I don't think that is the situation that Shawn is describing. To me it sounded like he is starting firmware development before all of the functionality is delivered by the hardware engineers. I don't think that he is refering to initialization order. Shawn, could you please clarify?
Cheers, g.
Dear Grant,
in message 528646bc0502242240233e0d7f@mail.gmail.com you wrote:
Provide our own console functions. See common/console.c and common/devices.c how it is initialized and used.
Note thatt he "devices" are intialized pretty late in the boot sequence. Until then, all of the most of the important console messages have already beeen printed.
From the original post: "We're using some emulation box to develop our
SoC. Somehow the UART will the last component available for firmware development."
I don't think that is the situation that Shawn is describing. To me it sounded like he is starting firmware development before all of the functionality is delivered by the hardware engineers. I don't think
You are right. Then Ladislav Michl suggested to use special console functions for output, which works, but misses most of the "interesting" startup messages which are printed long before the device funtions are installed.
that he is refering to initialization order. Shawn, could you please clarify?
Initialization order plays only a role here as a console device starts working too late. The native console port is the serial port.
Best regards,
Wolfgang Denk
On Fri, 25 Feb 2005 08:51:47 +0100, Wolfgang Denk wd@denx.de wrote:
Dear Grant,
in message 528646bc0502242240233e0d7f@mail.gmail.com you wrote:
From the original post: "We're using some emulation box to develop our
SoC. Somehow the UART will the last component available for firmware development."
I don't think that is the situation that Shawn is describing. To me it sounded like he is starting firmware development before all of the functionality is delivered by the hardware engineers. I don't think
You are right. Then Ladislav Michl suggested to use special console functions for output, which works, but misses most of the "interesting" startup messages which are printed long before the device funtions are installed.
Ahh, thank you. I had misunderstood what you were talking about.
that he is refering to initialization order. Shawn, could you please clarify?
Initialization order plays only a role here as a console device starts working too late. The native console port is the serial port.
So what needs to be modified to do this? Create new serial_putc, _getc, _init etc. functions that send messages to where he needs them?
Cheers, g.
In message 528646bc0502250800b68e268@mail.gmail.com you wrote:
Initialization order plays only a role here as a console device starts working too late. The native console port is the serial port.
So what needs to be modified to do this? Create new serial_putc, _getc, _init etc. functions that send messages to where he needs them?
Add a working serial port :-)
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 528646bc0502250800b68e268@mail.gmail.com you wrote:
Initialization order plays only a role here as a console device starts working too late. The native console port is the serial port.
So what needs to be modified to do this? Create new serial_putc, _getc, _init etc. functions that send messages to where he needs them?
For what it's worth, I have recently completed a port of U-Boot to a custom board with no serial port in the design. It does, however, have a functioning ethernet port, which we set up to use as a netconsole. Sure, most of the informative boot up messages are missed, but to paraphrase Wolfgang, "get a BDI 2000"! ;)
Good Luck, Adam Kent
I don't think that is the situation that Shawn is describing. To me it sounded like he is starting firmware development before all of the functionality is delivered by the hardware engineers. I don't think that he is refering to initialization order. Shawn, could you please clarify?
Both of you are right. I'm starting firmware development before all h/w components are ready. H/W folks are pushing to test some of components before UART is delivered.
Thanks, -Shawn.
On Fri, 25 Feb 2005 09:55:41 -0800, Shawn Jin shawnxjin@gmail.com wrote:
Both of you are right. I'm starting firmware development before all h/w components are ready. H/W folks are pushing to test some of components before UART is delivered.
Sounds like some percussive maintenance is needed about the ears of said H/W folks. :-P
g.
In message c3d0340b0502221121c489be4@mail.gmail.com you wrote:
We're using some emulation box to develop our SoC. Somehow the UART will the last component available for firmware development. Without
What a major mistake of design...
UART, it's very hard to debug UBoot. Can we "easily" drive a car without eyes?
Easily yes, savely no ;-)
But it's not impossible to do that. My first thought about porting UBoot under this circumstance is to disable the serial driver in UBoot and to redirect all printf to a fixed memory area, just as what a circular log buffer does. I'm wondering how much workload this will be. Is this kind of mechasim already existent in UBoot?
There is a log driver, yes.
But U-Boot really assumes that you have a working console port. Anything else is a major pain in the ...
Best regards,
Wolfgang Denk
participants (5)
-
Adam Kent -
Grant Likely -
Ladislav Michl -
Shawn Jin -
Wolfgang Denk