coreboot has many Project Ideas for various firmware ability levels and the coreboot project also hosts flashrom and SerialICE projects. Please visit the wiki for additional information.

• Dual Socket 771
• 1 PCI-e x4 Slot
• 2 PCI-e x8 Slot
• 3 PCI-X Slots
• Onboard Adaptec SCSI Controller
• two Gigabit NICs
• and of course various other I/O stuff like serial ATA, IDE, serial/parallel ports, etc

What isn’t working right now:

• Fan Control. All Fans are running on full speed, support for the Winbond W83793 and PECI has to be added
• using a PCI-e x1 graphics card. As soon as such a card is plugged in, the system dies with a Machine check exception during startup.
• Automatic MPTABLE generation. I’m currently working on a generic solution, but for now you have to edit devicetree.cb manually.

Changes in the repository

New boards

Gigabyte MA785GM-US2H was already committed, but not hooked up properly.

"blobs" repository

We provide a new repository for binary components and hooked it up in the build. So far it provides binaries for the Intel Sandybridge and Ivybridge platform, as well as the AMD Geode VSA binary that used to be distributed by Marc Jones.

The latter could be replaced by source in the main repository as soon as someone takes the time to port the VSA source (also part of the repository) from MASM assembly to some syntax compatible with our build system.

For VSA, the build system was slightly extended so its cbfs-files mechanism can be used to add coreboot stages.

SeaBIOS mirror

We mirror the SeaBIOS repository on review.coreboot.org. This isn't meant for patch submissions to SeaBIOS, but it provides a more robust source for the repository when using the build method that automatically integrates SeaBIOS in coreboot when behind firewalls.

Sandybridge support

Google provided various commits to improve their initial contributed code for Sandybridge and Ivybridge chipsets and boards.

Simplify using a driver for multiple PCI IDs

Instead of defining a device structure for a larger number of devices (eg. multiple revisions of the same device), extend them so they can optionally cover a set of devices.

static const struct pci_driver pch_sata_ahci_driver __pci_driver = {
   .ops    = &sata_ops,
   .vendor = PCI_VENDOR_ID_INTEL,
   .device = 0x1c02,
};
static const struct pci_driver pch_sata_mobile_ahci_driver __pci_driver = {
   .ops    = &sata_ops,
   .vendor = PCI_VENDOR_ID_INTEL,
   .device = 0x1c03,
};

becomes

static const struct pci_driver pch_sata_driver __pci_driver = {
    .ops    = &sata_ops,
    .vendor = PCI_VENDOR_ID_INTEL,
    .devices = { 0x1c02, 0x1c03 },
};

Remove Kconfig options

Stefan dropped CONFIG_MAX_PHYSICAL_CPUS on non-AMD boards. This Kconfig option is only used on AMD boards, but should eventually be removed there, too.

Fixed long time bug in Intel microcode update code

We used to have a couple of issues with cpuid in the past. It's an opcode that modifies a whole lot of registers, and we didn't always teach gcc about all of them.

The latest victim is Intel microcode updates - or rather, one of the earlier ones, since the code was broken since 2004. It only triggered bugs in later code if the compiler tried to reuse values in clobbered registers, and was rather elusive.

roda/rk886ex: Expose VGA devices

This one is interesting as it explains some of the less well documented properties in coreboot, devices in devicetree.cb:

As a rule of thumb, all devices should be listed (and not commented out) that are on-board. While coreboot can find them on its own, it only marks devices as "on mainboard" that are explicitely mentioned - among other things, the VGABIOS execution system uses that to determine the VGABIOS location, but we also run set_subsystem only on onboard hardware.

Console output

There were improvements to console output: The ACPI generation code can print PSS table entries as it generates them. The CBFS code prints more helpful debug output now. * MTRR debug output is more useful now.

Preprocessor mangling

Some preprocessor idioms were unified. CONFIG_FOO==1 became CONFIG_FOO, CONFIG_FOO==0 became !CONFIG_FOO.

We also added the config_enabled macro recently introduced with Linux. It works both for the preprocessor and inside code, and will allow us to eventually reduce the amount of changes we carry around in our version of Kconfig.

i915tool

Ron committed his research project, a set of Coccinelle scripts to convert Linux KMS code to code that can eventually be run from coreboot, as VGABIOS replacement.

AMD unification

Various aspects of AMD code were unified into generic code: FADT table generation for sb800, cbtypes.h was copied across AMD southbridge drivers,

Add SPI flash driver for Intel chipsets

After AMD added a tiny (and highly specialized) SPI driver for sb800, we now also have support to write to SPI flash on Intel chipsets. Like with AMD, it's used to store configuration data that is required on wakeup-from-S3.

I'm happy to finally announce an open-source (GNU GPL), cross-platform (Linux, Mac OS X, FreeBSD, Windows, ...) logic analyzer software package myself and Bert Vermeulen have been working on for quite a long time now: sigrok (it groks your signals).

History

I originally started working on an open-source logic analyzer software named "flosslogic" in 2010, because I grew tired of almost all devices having a proprietary and Windows-only software, often with limited features, limited input/output file formats, limited usability, limited protocol decoder support, and so on. Thus, the goal was to write a portable, GPL'd, software that can talk to many different logic analyzers via modules/plugins, supports many input/output formats, and many different protocol decoders.

The advantage being, that every time we add a new driver for another logic analyzer it automatically supports all the input/output formats we already have, you can use all the protocol decoders we already wrote, etc. It also works the other way around: If someone writes a new protocol decoder or file format driver, it can automatically be used with any of the supported logic analyzers out of the box.

Turns out Bert Vermeulen had been working on a similar software for a while too (due to exactly the same reasons, crappy Windows software, etc.) so it was only logical that we joined forces and worked on this together. We kept Bert's name for the software package ("sigrok"), set up a SourceForge project, mailing lists, IRC channel, wiki, etc. and started working.

Overview, Features

You can get the lastest sigrok source code from our main git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok

Here's a short overview of sigrok and its features as of today. The software consists of the following components:

• libsigrok, a shared library written in C, which contains the general infrastructure for handling logic analyzer data in a streaming fashion.
  
  It also contains the individual hardware drivers which add support for various logic analyzers. Currently supported hardware includes: Saleae Logic, CWAV USBee SX, Openbench Logic Sniffer (OLS), ZEROPLUS Logic Cube LAP-C, ASIX Sigma/Sigma2, ChronoVu LA8, and others. Many more devices are on our TODO list (and we already own them), it's just a matter of time to reverse engineer the USB protocols and implement a driver for them.

  Thanks ASIX for being open and helping with the ASIX Sigma driver, and many thanks to ChronoVu for being open as well and providing information about the ChronoVu LA8 protocol! Thanks to Håvard Espeland, Martin Stensgård, and Carl Henrik Lunde (who contributed the ASIX Sigma driver), Sven Peter and "Haxx Enterprises"/bushing (for contributing the ZEROPLUS Logic Cube LAP-C driver, ported from their zerominus tool). Also, thanks to Daniel Ribeiro and Renato Caldas who worked on the Link Instruments MSO-19 driver (still work in progress).

  Finally, libsigrok also contains the individual input/output file format drivers. Currently supported are: sigrok session (the default format, which contains all metadata), bits, hex, ASCII, binary, gnuplot, the OpenBench Logic Sniffer format, the ChronoVu LA8 format, Value Change Dump (VCD) viewable in gtkwave, and Comma-separated values (CSV).
  

• libsigrokdecode, a shared library written in C, which contains the protocol decoder infrastructure and the protocol decoders themselves, which are written in Python (>= 3.0).

  The list of currently supported protocol decoders includes:
  

    dcf77                DCF77 time protocol
    lpc                  Low-Pin-Count
    mx25lxx05d           Macronix MX25Lxx05D
    jtag_stm32           Joint Test Action Group / ST STM32
    i2s                  Integrated Interchip Sound
    spi                  Serial Peripheral Interface
    edid                 Extended display identification data
    pan1321              Panasonic PAN1321
    mlx90614             Melexis MLX90614
    jtag                 Joint Test Action Group
    rtc8564              Epson RTC-8564 JE/NB
    transitioncounter    Pin transition counter
    usb                  Universal Serial Bus
    i2cdemux             I2C demultiplexer
    i2c                  Inter-Integrated Circuit
    i2cfilter            I2C filter
    mxc6225xu            MEMSIC MXC6225XU
    uart                 Universal Asynchronous Receiver/Transmitter
  

  Many more decoders are on our TODO list, and we especially welcome contributed protocol decoders, of course! We intentionally chose Python as implementation language for the decoders, to make them as easy to write (and understand) as possible, even if that means that performance suffers a bit. Have a look at the SPI decoder for example, to get a feeling for the implementation.

  Protocol decoders can be stacked on top of each other, e.g. you can run the i2c decoder and pipe its output into the rtc8564 (Epson RTC-8564 JE/NB) decoder for further processing of the RTC-specific, higher-level protocol. We also plan to support more complex stacking and combining of decoders in various ways in the nearer future.

• sigrok-cli, is a command-line frontend, which uses both libsigrok and libsigrokdecode. It can acquire samples from logic analyzers and output them in various formats into files or to stdout, and/or run protocol decoders on the aquired data.

  Example: Data acquisition with 1MHz samplerate into a file.
  

   $ sigrok-cli -d chronovu-la8:samplerate=1mhz --time 1ms -o test.sr
  

  Example: Protocol decoding (JTAG).
  

   $ sigrok-cli -i test.sr -a jtag:tdi=5:tms=2:tck=3:tdo=7
   [...]
   jtag: "New state: EXIT1-IR"
   jtag: "IR TDI: 11111110, 8 bits"
   jtag: "IR TDO: 11110001, 8 bits"
   jtag: "New state: UPDATE-IR"
   jtag: "New state: RUN-TEST/IDLE"
   [...]
  

• sigrok-qt, a Qt-based GUI for sigrok, using both libsigrok and libsigrokdecode.

  This is intended to be a cross-platform GUI (runs fine and looks "native" on Linux, Windows, Mac OS X) supporting data acquisition and protocol decoding.

  NOTE: The Qt GUI is not yet usable! We're working on getting it out of alpha-stage for the next release.

• sigrok-gtk, a GTK+-based GUI for sigrok, using both libsigrok and libsigrokdecode (soon).
  
  This is a cross-platform GUI contributed by Gareth McMullin (thanks!), supporting data aqcuisition (and soon protocol decoding).

  NOTE: The GTK+ GUI is not yet fully usable (but it's more usable than sigrok-qt)! Consider it alpha-stage software for now.

We're happy to hear about other (maybe special-purpose) frontends you may want to write using libsigrok/libsigrokdecode as helper libs!

Firmware

Some logic analyzer devices require firmware to be uploaded before they can be used. As always, firmware is a bit of a pain, but here's what we currently do: For non-free firmware we provide instructions how to extract it from the vendor software or from USB dumps, if possible. For distributable firmware we have a git repo where you can get it (thanks ASIX for allowing us to distribute the ASIX Sigma/Sigma2 firmware files!).

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-firmwares

Finally, for all Cypress FX2 based logic analyzers we have an open-source (GNU GPL) firmware named fx2lafw, started by myself, but most work (and finishing the firmware) was then done by Joel Holdsworth, thanks! The support list includes Saleae Logic, CWAV USBee SX, CWAV USBee AX, Robomotic Minilogic/BugLogic3, Braintechnology USB-LPS, and many others. Get the code from the fw2lafw git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/fx2lafw

Example dumps

We collect various captured logic analyzer signals / protocol dumps in the sigrok-dumps git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-dumps

They can be useful for testing the sigrok command-line application, the sigrok GUIs, or the protocol decoders.

We're happy to include further contributed example data in our repository, please send us .sr files of any interesting data/protocol you may come across (even if sigrok doesn't yet have a protocol decoder for that protocol). See the Example dumps wiki page for details.

Packages, distros, installers

I'm currently working on updated Debian packages for sigrok (will be apt-get install sigrok to get everything), and we're happy about further packaging efforts for other distros. We have preliminary Windows installer files (using NSIS), but the Windows code needs some more fixes and portability improvements before it's really usable. On Mac OS X you can use fink/Macports to install as usual, fancier .app installer files are being worked on.

Future

Apart from support for more logic analyzers, input/output formats, and protocol decoders, we have a number of other plans for the next few releases. This includes support for analog data, i.e. support for (USB) oscilloscopes, multimeters, spectrum analyzers, and such stuff. This will also require additional GUI support (which could take a while). Also, we want to improve/fix the Windows support, and test/port sigrok to other architectures we come across. Performance improvements for the protocol decoding as well as more features there are also planned.

Contact

Feel free to contact us on the sigrok-devel mailing list, or in the IRC channel #sigrok on Freenode. There's also an identi.ca group for sigrok. We're always happy about feedback, bug reports, suggestions for improving sigrok, and patches of course!

Check out the article on Phoronix.

coreboot was not selected to participate in GSoC 2012. This is
disappointing new for the project. I do not know why we were not
selected this year. I will attend the post selection meeting to see
what we can do to improve our chances of selection next year.

Students, thank you for your interest in coreboot. We are happy that
you are engaging with our community. I hope that you continue
exploring your interest in coreboot. Please let us know what we can do
to assist you in your learning.

Feel free to send me questions, comments, or concerns.

Regards,
Marc

http://google-opensource.blogspot.com/

Flip bits, not burgers!

coreboot is applying for Google Summer of Code 2012. We are currently
looking for mentors, project ideas, and prospective students.

Please visit the coreboot GSoC page: http://www.coreboot.org/GSoC

Students:
Prospective students should join the email list and join IRC #coreboot to
get familiar with the coreboot community. Please forward any potential GSoC students
to the coreboot GSoC page.

Projects:
We are interested in all types of projects that support coreboot,
including payload and infrastructure projects.
If you have project ideas please post them here:
http://www.coreboot.org/Project_Ideas

Mentors:
We need mentors! The more qualified mentors we have registered, the
more GSoC projects/students we can support. We will match students
with mentors once the student proposal phase is complete.  If you might like to be
a mentor, please register with google and add yourself to the mentor
list on the wiki.:
http://www.google-melange.com/gsoc/homepage/google/gsoc2012

Please feel free to contact me by email or in IRC #coreboot if you
have questions.

Regards,
Marc

Actually i didn’t expect the port progressing so fast. One tool that was a great help was serialice. I used it to watch the original BIOS initializing memory. To get serialice running, all you have to do is writing a few lines of board specific C code, which initializes the serial port and some basic chipset parts required for accessing the serial port registers. On the host side, a patched QEMU is running, executing the vendor BIOS while redirecting HW accesses to the target computer. Which HW accesses are redirected can be configured by a small lua script. LUA can also be used to pretty print the output from serialice.

So with a bit of hacking i had the following output from serialice:

pci_mmmo_read_config32(PCI_ADDR(0, 16, 1, 0), MC) == 0x0040000;
pci_mmio_write_config32(PCI_ADDR(0, 16, 1, 0), MC, 00040000);
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, EI);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDHPC, STATE_INIT);
pci_mmio_read_config8(PCI_ADDR(0, 21, 0, 0), FBDST) == 0x10;
amb_smbus_write_config32(0, 1, 0, 1, AMB_FBDSBCFGNXT, 0x20b1b);
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDSBTXCFG0, 0x05);
pci_mmio_write_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBTXPAT2EN, 00000000);
pci_mmio_write_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBRXPAT2EN, 00000000);
pci_mmio_read_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL) == 0x1000032;
pci_mmio_write_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL, 00000012);
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS0);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS1);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_read_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL) == 0x0000016;
pci_mmio_read_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL) == 0x0000016;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS2);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_read_config8(PCI_ADDR(0, 21, 0, 0), FBDLVL0) == 0x14;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS2);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS3);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDHPC, STATE_READY);
pci_mmio_read_config8(PCI_ADDR(0, 21, 0, 0), FBDST) == 0x20;
pci_mmio_write_config16(PCI_ADDR(0, 21, 0, 0), AMBPRESENT0, 0x8FFF);
pci_mmio_write_config16(PCI_ADDR(0, 21, 0, 0), AMBPRESENT0, 0x8FFF);
MEM:  readl AMB_ID => 0482111d *
MEM: writel AMB_FERR <= 00000009 *
MEM: writel AMB_NERR <= 00000009 *
pci_mmio_write_config16(PCI_ADDR(0, 21, 0, 0), AMBPRESENT0, 0x8001);
pci_mmio_read_config32(PCI_ADDR(0, 16, 1, 0), MC) == 0x0040000;
pci_mmio_write_config32(PCI_ADDR(0, 16, 1, 0), MC, 40040020);

As you can see, this almost looks like C code. Even if it looks like porting coreboot to this chipset should be simple with that level of output, there where some challenges.

First, i5000 uses FBDIMMs. Each of the memory modules contains an AMB (Advanced Memory Buffer) in addition to the memory chips. This AMB has to be initialized and trained during the Memory initalization sequence. So you have three things to setup right to get working memory:

• The Northbridge (MCH in Intel’s terminologie)
• The AMB
• The memory chips on the module itself.

The training sequence is needed to account for the high bit rate used on this communication channel: stuffing 12 Bits into one Clock cycle at 166Mhz. But even if it makes initialization more complicated, the AMB can be really helpful during development. It allows to test the Memory chips without help from the MCH, so you can test if the memory module itself is working without having to rely on MCH setup. We’re (and the vendor BIOS does as well) are using it also for clearing the Memory during initialization. But we made one difference: The vendor BIOS clears the memory modules one after another, while the coreboot code sends the command to clear the memory to all modules at the same time, and collects the status response afterwards from all modules. This has the advantage of requiring only the time the slowest module needs, instead of the sum of all modules.

I spent several evenings investigating why Interrupts were not working, just to discover that i accidentally reset the Busmaster Flag on the Northbridge. This had the effect of having Interrupts in Virtual Wire mode, but not in APIC mode. After fixing this nasty bug, linux was booting properly, and i even had a working keyboard and mouse

Having i5000 code in coreboot, i’m aiming at supporting the following Boards in coreboot:

• Supermicro X7DB8(+)
• Asus DSBF-D12 (i have this board in my Desktop  Box)

There are also a lot of HP/Dell/FSC servers out there using this chipset, which might also be a nice target. Unfortunately i don’t have such hardware at home

As on any other system, best would be to get some datasheets describing in great details everything about the system. Luckily Prochip, Russian company offers on FTP quite complete SDK even with the GPL redboot sources together with JTAG tools datasheets. The board has 64Mbit flash soldered, and of course producing a little brick is always an option.

Internally the system has PCI bus with USB, Network and NB and SB. Checking the redboot sources it turns out that system initialization is actually quite simple. Setup few registers for memory enable timer1 for system SDRAM refresh, enable flash decoding (chipselect). On SB front, just assign IRQs to PCI routers and USB and network and possibly enable the ROMCS write decoding. Yeah and just set level/edge in ELCR and write BIOS IRQs into the PCI registers. Plus assign few PCI BARs for EHCI/OHCI and network and set serial to internal decode and you are done. No need to worry about the CMOS because there is none.

I have taken the emulation/qemu-x86 as the base, because I really did not need any fancy structures, all initialization is just couple of PCI writes. It is still unknown if CPU can do CAR setup and this target uses romcc. First thingie to do was implementing a bootblock.c which enables whole decode of flash rom. Second step was to fill all init into the romstage.c. Third step was to fill the PCI BIOS IRQs in ramstage as well as filling the system resources like maximum RAM size and PCI MMIO and IO regions.

Ready to flash and boot. Flash but how? The biffboot enables flashing everything except the last 64KB of itself and flashrom has no support for this system (yet). Also I did not want to have a pernament little brick and the bifferboard has a JTAG connector and schematics for the JTAG, which is just buffered Xilinx parallel cable. You can even buy a debrick set (hw + sw) on the bifferboard page for 20 quids, but it would mean to purchase it separately and nearly with the price of whole system.

I did a soldering and produced a JTAG adapter which agreed with schematics and was on purely software side again. The RDC Loader is a Windows application which can be used to flash stuff using the JTAG. My flash was not listed, but there were some similar which gave me hope that could flash it. Now what? I examined the RDC DLL and found out that in Windows 98 version it was doing straight port 0×378 IO. Great time to write a short iopl(3) / ioperm wrapper and run the wine emulator on second coreboot board with parallel port.

With everything ready there was a time similar to big bang, the first try of everything. First connect JTAG and double check all wires, then check again, because if magic smoke escapes out of the chips (which was added there during manufacture process apparently) the magic would be broken and would leave me very sad. Now power on, magic stays inside chips.

Now run the wine wrapper with the application. It does not complain about unconnected JTAG… scan the PCI bus… oh it works! A flashing time! It takes long to move a progress bar but still something is happening. Ah it worked too! Now do reset and run… Yes coreboot is here, and it seems to die quite at the end where all tables are being generated.

It prints just couple of strange letters as last message. I knew what it was. Of course it was just GDB protocol. I seem to get some exception and we still have GDB enabled as default. I really need to push a change to turn it off to receive human readable exception at first. Now re-flash with gdb disabled and check again. Exception 6, unknown opcode 0f a2.

Examing the fail address with objdump we see the culprit immediately. It is the cpuid in the SMBios tables generator (CPU table). Yeah I believe not many 486 had CPUID, lets disable quickly the SmBios tables and re-flash. Boots gets a bit further and it seems to die inside the SeaBIOS.

Now what? I checked the resources and realized that I forgot to add flash resource thus making PCI devices memory BARs overlap flash memory. Same happened for IO ports which overlaped legacy resources, but it still hung. Luckily the JTAG is also an integrated debugger. There was still couple of places in SeaBIOS with CPUID stuff, and one particular hidden in the header which took me some time to find. But it still does not work.

Failing instruction 0f 31 RDTSC. Now it gets interesting. SeaBIOS seems to calibarate the TSC using timer2 and uses TSC for the timekeeping. Rest of the evening is spent to rewrite this using just low accuracy timer1. Late in the night I got “No bootable devices found” which sounds as the best error message I could get! (Yeah Sven likes that too).

Next evening it is a boot Linux time. I want to boot from USB stick (which is not possible from biffboot) using syslinux to boot some custom compiled kernel. SeaBIOS loads syslinux, it loads kernel and… nothing.

JTAG is quite handy… HLT quite early not even running in 0xC0000000 range. I forgot to mention that I tried to load bzImage, most likely it fails in that pre-boot stage. I study the kernel sources and realize even if I enabled early printk’s they go to INT 10H which means I cannot see them.

I quickly hack the function to send it to serial and got this back:

Unable to boot – please use a kernel appropriate to your CPU.

Hm even if cross compiled with ARCH=i386 the menuconfig default was i586. Fix it. Boot again. Linux complains about missing FPU. Oh really a CPU from the past. Turn on FPU emulation in kernel boot again. And nothing again. JTAG came handy again and it fails with invalid opcode again. This time a CMOV instruction. It seems a misc.c file misses -march=i386 and gcc is using CMOV there. After fixing this I got kernel to boot ending with kernel panic.

Something wrong with interrupts. Linux complains that it is unable to route IRQ for OHCI/EHCI and I intended to use USB as rootfs. After short research I realize coreboot writes 0 to PCI 0x3c (BIOS IRQ reg) and I really need to call assign_pci_irq in the ramstage.

After fixing this system finally boots. Sunday trip to visit the parents is partly a flashrom time too, making myself present in living room and not watching TV and hacking flashrom instead (during evening hours again). Afternoon spent fixing sisters car central lock system and fixing unrelated parents radio remote controller. Yeah hacking time all around the clock. Back to flashrom again.

Rule #1 make sure your datasheet matches your chip. I googled the datasheet and found some different one and I even check if the chip’s name under a sticker on board matches. After some time in desperate move I google for full chip name again with last “B” included.

It turns out that the B/T variant of EN29LV640 is something completely different. The chip has a standard JEDEC command set but requires word access (16 bit) for that. The 8bit mode with BYTE# signal grounded is used on bifferboard. The chip probing worked with 8 bit mode and erase too. I even managed to erase the chip. But unable to program anything. The JEDEC toggle bit toggle for eternity and examining the dumps I managed to write first nibble of the byte programmed and also second byte is zero… It sounds fishy but I tried many different things but still no chip programming. Late in the evening I found some kernel module which has biffboot config space writes and they use the 8bit sequence, BUT the programming is in WORD mode, programming two bytes at one.

Fixing flashrom. Verified. Fixing flashrom again, because this “B” variant has non-uniform sectors at the start of the flash.

Now what? Xvilka is working on Vortex86 which is much faster x86 SoC from DMP, but it seems that it has very similar NB and SB. Most likely merging a code is a option here. As for the SeaBIOS programming TSC emulation using timer2 could produce better timming functions even without TSC (task for near future maybe).

As the ultimate goal, maybe reviving the coreboot + u-boot from last April would be nice option here.

More pictures and bootlog.

PORTWELL ANNOUNCES REVOLUTIONARY IN-VEHICLE PC
WITH THE BOOT SPEED OF AN APPLIANCE New PCS-8277 telematics system based on Coreboot® technology with HD graphics processing engine 

I think that we are starting to see vendors and customers becoming more knowledgeable about what is going into their products and how coreboot is an advantage in many situations. I hope to see more announcements in the coming months.