I'm trying to get LinuxBIOS booting on a custom board with a Socket AM2 Athlon and an MCP55. There is no SuperIO; instead, we're using the MCP55's internal serial UART. A couple of the MCP55's GPIO pins are hooked up to LEDs.
I have had no luck getting either the serial port or the LEDs to work, though. My cache_as_ram_main() sets up the serial port by:
- enabling the serial port and configuring the IO address and IRQ in register 0x78 on PCI device 1:0 - NOT redirecting IO address 0x3f8 to the LPC bus in register 0xa0 on PCI device 1:0 (as is done when the serial port is on a SuperIO) - setting GPIO pins 11, 12, 13 and 14 to their "normal" (non-GPIO) mode, which I hope is RX, TX, DTR and DSR
It also tries to turn on an LED on GPIO pin 1 by setting it to GPIO output mode, drive low.
Has anyone tried tried this with an MCP55-based board? Any ideas for other ways to communicate with the outside world when the serial port doesn't work?
--Ed
On Tue, Mar 13, 2007 at 10:13:39PM -0700, Ed Swierk wrote:
Has anyone tried tried this with an MCP55-based board? Any ideas for other ways to communicate with the outside world when the serial port doesn't work?
Let a logic analyzer trigger on special read sequences on a suitable bus.
//Peter
On 3/13/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
Let a logic analyzer trigger on special read sequences on a suitable bus.
So far we're just using a scope with too few channels; a logic analyzer would be pretty useful. Our plan for tomorrow is to write special values on the LPC bus, as they should stand out from the stream of reads from the LPC flash. IO address 0x80 should be easy to redirect to LPC.
(I just spent a week working on a PowerPC-based system and am now completely spoiled by the convenience of a JTAG debugger...)
--Ed
Ed Swierk wrote:
(I just spent a week working on a PowerPC-based system and am now completely spoiled by the convenience of a JTAG debugger...)
A64 certainly supports JTAG debuggers. Is there an HDT header designed onto your board? There are commercial wigglers to buy, and then you can use AMD's HDT software (from their NDA site, very powerful) or software from the commercial vendor.
Ed Swierk schrieb:
(I just spent a week working on a PowerPC-based system and am now completely spoiled by the convenience of a JTAG debugger...)
I know exactly how you feel ;-) (famous standard phrase)
After staring at the code for a while I realized that I wasn't mapping the GPIO registers into IO space properly. (I'm still using the ck804 code with a bunch of hacks, as I haven't had time to integrate the mcp55 support, but there are indeed some important differences :-)
I changed ck804_early_set_port() to use the proper device ID and function (1:1, not 1:0), and now both the serial port and the LEDs work fine.
Now I'm fantasizing about using gdb to step my way through the rest of the code, which hangs somewhere after ck804_early_setup_x(). When I set CONFIG_GDB_STUB=1 and add a call to gdb_stub_breakpoint(), I get a linker error:
cache_as_ram_auto.c:8740: undefined reference to `gdb_stub_breakpoint'
What's the right magic to export the gdb_stub_breakpoint symbol from c_start.S?
--Ed
On Tue, Mar 13, 2007 at 10:40:39PM -0700, Ed Swierk wrote:
On 3/13/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
Let a logic analyzer trigger on special read sequences on a suitable bus.
So far we're just using a scope with too few channels;
Use just a few bits then. :)
Maybe make a simple homebrew POST card..
(I just spent a week working on a PowerPC-based system and am now completely spoiled by the convenience of a JTAG debugger...)
..unless the JTAG works out of course.
//Peter
Hello! Ed, you are describing this board as a custom one. This tells me that it might have been made for a customer I am using it that way because I frequently end up looking at a similar design for a project. It's the complexities that end up stopping me. Can you provide a good photo of the board? I freely admit that I am curious.
And I do admit that your problems with this design are not unique, I've heard stories of problems similar to yours for the PPC family, and that's with its own ideas of how to start up properly. -- Gregg C Levine hansolofalcon@worldnet.att.net "The Force will be with you. Always." Obi-Wan Kenobi
-----Original Message----- From: linuxbios-bounces+hansolofalcon=worldnet.att.net@linuxbios.org
[mailto:linuxbios-
bounces+hansolofalcon=worldnet.att.net@linuxbios.org] On Behalf Of Ed
Swierk
Sent: Wednesday, March 14, 2007 1:14 AM To: LinuxBIOS Subject: [LinuxBIOS] Accessing MCP55 internal serial UART, GPIOs
I'm trying to get LinuxBIOS booting on a custom board with a Socket AM2 Athlon and an MCP55. There is no SuperIO; instead, we're using the MCP55's internal serial UART. A couple of the MCP55's GPIO pins are hooked up to LEDs.
I have had no luck getting either the serial port or the LEDs to work, though. My cache_as_ram_main() sets up the serial port by:
- enabling the serial port and configuring the IO address and IRQ in
register 0x78 on PCI device 1:0
- NOT redirecting IO address 0x3f8 to the LPC bus in register 0xa0 on
PCI device 1:0 (as is done when the serial port is on a SuperIO)
- setting GPIO pins 11, 12, 13 and 14 to their "normal" (non-GPIO)
mode, which I hope is RX, TX, DTR and DSR
It also tries to turn on an LED on GPIO pin 1 by setting it to GPIO output mode, drive low.
Has anyone tried tried this with an MCP55-based board? Any ideas for other ways to communicate with the outside world when the serial port doesn't work?
--Ed
-
Ed Swierk -
Gregg C Levine -
Peter Stuge -
Quux -
Tom Sylla