My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.

[Keith Hui]

Previously on the resource allocator discussion, I was about to test
Arthur's fix for PARALLEL_MP when all my boards suddenly failed to
come up. I still refuse to let this legend die, so I managed to get it
going again, and look what it did for me in return.

First, I plugged the flash chip with vendor firmware to rule out
hardware failure. Came up just fine. Excellent! Swapped in my coreboot
chip and tried to flash my copy of coreboot (which is still carrying
PARALLEL_MP and the fix. It worked!). flashrom knows it has the 440BX
chipset but can't seem to convince itself it will work. See the
attached log. I have to calmly tell it "laptop=this is not a laptop"
and then it works as usual. I don't remember ever having to do this
before. Why? If I have a clue I can code up and submit a patch.

Back to how it failed to boot in the first place. The hard disk
booting stalled after SeaBIOS. Took me hours but eventually I found a
line in my serial log that there has been a DMA timeout. Turning UDMA
off in devicetree.cb and flash again made it boot again. So I would
have to revert 576315e1 (aka CB:40961), but I'm hesitant because that
seemed like the reasonable thing to do and it should have worked. So
I'm also unsure why it didn't.

Thanks
Keith

[Peter Stuge]

Keith Hui wrote:
> The hard disk booting stalled after SeaBIOS. Took me hours but
> eventually I found a line in my serial log that there has been a
> DMA timeout. Turning UDMA off in devicetree.cb and flash again made
> it boot again. So I would have to revert 576315e1 (aka CB:40961),
> but I'm hesitant because that seemed like the reasonable thing to
> do and it should have worked.

UDMA should only ever be enabled for a channel when an actual drive
that supports UDMA is connected. I don't believe it's a good idea to
enable UDMA on channels without a connected drive. And finally the
UDMA code can of course be buggy.

Regards

//Peter