I've been working on some code to ensure I can debug a system even if coreboot fails to boot an OS. The attached patch adds this code to the tree: - serialprobe watches the serial port for about a second, and boots the system normally unless 32 consecutive null bytes are seen. - xcshell allows the CPU to be controlled via the serial port, using a binary protocol.
The code assembles to about 1 KB, so it can be left in an image for emergency use. It's also modular in case someone wants to use it with something other than a serial port.
xcsinterp.inc describes the protocol, and xccmd.inc describes the command set.
Signed-off-by: Michael Gold mgold@ncf.ca --- It should possible to jump to the 'xcshell' or 'serialprobe' symbol (with the return address in ESP) as soon as the serial port is configured and the CPU is executing 32-bit code (e.g., after console_init in auto.c). I'm using these lines in my mainboard's Config.lb to include the code: mainboardinit arch/i386/xcshell/jmp_xccmd_end.inc mainboardinit arch/i386/xcshell/serialprobe.inc mainboardinit arch/i386/xcshell/io_serial.inc mainboardinit arch/i386/xcshell/xcsinterp.inc mainboardinit arch/i386/xcshell/xccmd.inc
I'm not sure whether there's anything that needs to be added, but suggestions are welcome. I'm hoping the command set is sufficient to initialise RAM, though so far I've only tested cache-as-RAM mode (which just seems to work for data, not code).
-- Michael
I like it. We talked about something like this in v3. How would you feel about putting in emergency flash upgrade support :-)
Acked-by: Ronald G. Minnich rminnich@gmail.com
On Tue, Jul 14, 2009 at 08:38:15 -0700, ron minnich wrote:
I like it. We talked about something like this in v3. How would you feel about putting in emergency flash upgrade support :-)
I like the flash upgrade idea, but I'm not sure how to do it yet (in a generic way). Any suggestions?
I think it might be possible without any changes by marking the part of the ROM containing xcshell as cacheable, and then using pokes to rewrite the rest of the chip. It would be slow, but a small flash upgrade program could be uploaded that would do the rest of the work more quickly.
My original idea was that one would set up CAR, upload code, and jump to it; this would allow the system to be extended without having to include much code. It doesn't work, at least on my Pentium 3, but the same thing could be done with RAM once it's initialised (or with flash for occasional use).
-- Michael
On 14.07.2009 18:55, Michael Gold wrote:
On Tue, Jul 14, 2009 at 08:38:15 -0700, ron minnich wrote:
I like it. We talked about something like this in v3. How would you feel about putting in emergency flash upgrade support :-)
I like the flash upgrade idea, but I'm not sure how to do it yet (in a generic way). Any suggestions?
If you have RAM, downloading a flashrom binary linked against libpayload would be best. The good news is that flashrom itself is written in a way that allows you to put it on top of any backend, even a backend which does nothing but perform remote control of xcshell. I think that would be easiest.
I think it might be possible without any changes by marking the part of the ROM containing xcshell as cacheable, and then using pokes to rewrite the rest of the chip. It would be slow, but a small flash upgrade program could be uploaded that would do the rest of the work more quickly.
If you have a generic "write X to loation y" interface, flashrom can deal with that, even remotely.
My original idea was that one would set up CAR, upload code, and jump to it; this would allow the system to be extended without having to include much code. It doesn't work, at least on my Pentium 3, but the same thing could be done with RAM once it's initialised (or with flash for occasional use).
As long as RAM works, we could even upload a complete flashrom binary over zmodem.
Regards, Carl-Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As long as RAM works, we could even upload a complete flashrom binary over zmodem.
You dont need RAM, because if you just do remote calls via flashrom you will directly write to SPI controller for example ;)
Rudolf
On Tue, Jul 14, 2009 at 21:51:51 +0200, Carl-Daniel Hailfinger wrote:
I think it might be possible without any changes by marking the part of the ROM containing xcshell as cacheable, and then using pokes to rewrite the rest of the chip. It would be slow, but a small flash upgrade program could be uploaded that would do the rest of the work more quickly.
If you have a generic "write X to loation y" interface, flashrom can deal with that, even remotely.
That interface exists. I guess you'd need to execute xcshell from RAM, or use the --estart and --eend options to exclude the portion of the ROM it's executing from.
My original idea was that one would set up CAR, upload code, and jump to it; this would allow the system to be extended without having to include much code. It doesn't work, at least on my Pentium 3, but the same thing could be done with RAM once it's initialised (or with flash for occasional use).
As long as RAM works, we could even upload a complete flashrom binary over zmodem.
I don't have zmodem support currently. It would be easy to add a command that writes both 32-bit operands to RAM, using the accumulator as the pointer (auto-incremented afterwards). Then only 3 of 11 bytes would be protocol overhead, which should be fine if the binary isn't too large. Adding an automatic increment to peekl and pokel might be useful as well.
-- Michael
On 14.07.2009 11:23 Uhr, Michael Gold wrote:
I've been working on some code to ensure I can debug a system even if coreboot fails to boot an OS. The attached patch adds this code to the tree:
- serialprobe watches the serial port for about a second, and boots the system normally unless 32 consecutive null bytes are seen.
- xcshell allows the CPU to be controlled via the serial port, using a binary protocol.
The code assembles to about 1 KB, so it can be left in an image for emergency use. It's also modular in case someone wants to use it with something other than a serial port.
xcsinterp.inc describes the protocol, and xccmd.inc describes the command set.
Hi,
out of curiosity..
Would it be possible to enhance the already existing "llshell" with your features? I would want to prevent more than one assembler written shell of this type floating around in the coreboot tree.
Best wishes,
Stefan
On Tue, Jul 14, 2009 at 18:20:56 +0200, Stefan Reinauer wrote:
Hi,
out of curiosity..
Would it be possible to enhance the already existing "llshell" with your features? I would want to prevent more than one assembler written shell of this type floating around in the coreboot tree.
I considered extending it, but I didn't like how closely the command implementations are tied to the protocol. xcshell could be easily extended to execute opcodes from RAM (or CAR), for instance, which would be difficult with llshell; or, someone may want to define a new protocol that works with a USB debug device.
The llshell protocol is also designed for direct human use, which would make it more difficult for a remote script to control it and ensure the commands are being received/executed properly. Programmatic control of xcshell is simple, and the sequence numbers and checksums allow errors to be detected and recovered from.
I also noticed that xcshell implements all the commands needed for SerialICE; I haven't tried using them together, but I probably will at some point.
-- Michael
Ah, well, stefan, sorry if I messed up.
I will agree that we don't want to go the linux path of fifty slightly different versions of the same capability. It's bad enough in a kernel but far worse in coreboot. So, maybe we can take it on ourselves to figure out how to get one thing that does what we want?
ron
On 14.07.2009 11:23, Michael Gold wrote:
I've been working on some code to ensure I can debug a system even if coreboot fails to boot an OS. The attached patch adds this code to the tree:
- serialprobe watches the serial port for about a second, and boots the system normally unless 32 consecutive null bytes are seen.
- xcshell allows the CPU to be controlled via the serial port, using a binary protocol.
The code assembles to about 1 KB, so it can be left in an image for emergency use. It's also modular in case someone wants to use it with something other than a serial port.
How does this relate to RemoteBIOS? AFAIK RemoteBIOS is explicitly designed to be machine controllable even if CAR does not work. http://linuxupc.upc.es/~urbez/RemoteBIOS.eng.html
Regards, Carl-Daniel
On Tue, Jul 14, 2009 at 21:54:30 +0200, Carl-Daniel Hailfinger wrote:
How does this relate to RemoteBIOS? AFAIK RemoteBIOS is explicitly designed to be machine controllable even if CAR does not work. http://linuxupc.upc.es/~urbez/RemoteBIOS.eng.html
I may have seen that page before, but I'm not really familiar with the project. The command set looks pretty similar. Like the SerialICE shell, though, it appears to require 64 KB of ROM space, which means it's unlikely to be included in an image when it's not being actively used. I've already had some trouble with image size when including both
-- Michael
-
Carl-Daniel Hailfinger -
Michael Gold -
ron minnich -
Rudolf Marek -
Stefan Reinauer