I put a copy of serialice.lua in the qemu directory and ran it from
there. These patches refer to that file.
size8.diff: The factory BIOS wanted to do 8-byte writes, so I split it
into two 4-byte writes to minimize the changes necessary in SerialICE.
serial.diff: When using a Coreboot image, serial output gets to be too
verbose. Send it to Qemu's serial port, and make it much less verbose
in the log.
pci.diff: Add some helper functions so that PCI is easier to use in
serialice.lua
Signed-off-by: Myles Watson <mylesgw(a)gmail.com>
Some of the other patches I had for serialice.lua were specific to my
boards. I wonder what the best way of keeping track of board-specific
changes is. For example, the PCIe bar code conflicted with my
chipset's initialization.
Maybe we should have the SerialICE script query the board and then
check which board it is?
Another option would be to keep useful pieces that users should cobble together.
Yet another option would be to keep multiple scripts for boards.
Thanks,
Myles
I was surprised how easy it was to brick my board. These ideas might
be useful to somebody:
Before you start messing with PCI & I/O values that might keep their state:
- have a lspci -vvvxxx from the factory BIOS
- record as much of the boot process from the factory BIOS as possible
I wanted to collect the bit masks from my factory BIOS, so I modified
the filter to return 0x0 and then 0xffffffff for the PCI registers.
That way I could see which bits were being changed. After some of the
registers were changed, I couldn't boot the board with Coreboot or the
factory BIOS. I used SerialICE to set the PCI values to what they
were in a saved run of the factory BIOS, and it booted again.
Thanks,
Myles
All right. With the patches that I sent for Serengeti Cheetah support
and Jordan's snserial tool
http://www.coreboot.org/index.php?title=AMD_SimNow&redirect=no#Using_the_sn…
+ a simple patch for making it compile on my compiler (attached)...
It works! I can run SimNOW with a SerialICE, snserial to make it go
to /dev/pts/13, and qemu with the serialice patches. It looks like I
need to update the lua script so that I don't kill the serial port,
since this is the last thing I get:
MEM: writel fee00380 <= 00000033 *
IO: outb 002e <= 87
IO: outb 002e <= 87
IO: outb 002e <= 07
IO: outb 002f <= 02
IO: outb 002e <= 30
IO: outb 002f <= 00
IO: outb 002e <= 60
I thought I'd use gdb to skip over those, but when I use gdb to
connect (adding -s -S to the qemu command line), I get a lot of these
messages:
MEM: readl 000c9900 => ffffffff *
Readback error! 38/39
Readback error! 63/34
Any ideas of why connecting gdb would cause readback errors on the port?
Thanks,
Myles
I'd like to have SerialICE working on my Tyan boards, but I don't see
any output from the serial port after my porting attempt.
I took a step back and tried Qemu and SimNOW. I see the SerialICE
prompt, but I don't know how to test that interface.
SerialICE v1.5 (Jun 21 2010)
>
I was expecting to be able to enter some commands at the prompt, to
read/write memory locations and registers.
I'm attaching the patches I am working with:
emulators.diff: Add trivial support for qemu and copy support for
SimNOW from Tyan s2912 since they use the same SuperIO chip.
pci_read.diff: Add pci_read functions, since my Tyan s2895 Serial init
code uses them (copied from Coreboot)
tyan.diff: Add code for s2895 (s2892 is just a copy of s2895 right now)
debug_romstrap.diff: Make the romstrap end up looking like Coreboot's romstrap.
Status:
Qemu & SimNOW give me a prompt, but I don't know how to interact with it.
Tyan s2895 - No output.
Signed-off-by: Myles Watson <mylesgw(a)gmail.com>
Thanks,
Myles
