On 12/01/18 12:32, Jens Bauernfeind wrote:
> Hi Mark,
> the keyboard is still not working, but the line with the ISA bridge disappeared.
Gah, that's a shame. Do you see the same issue in QEMU with the q35
machine i.e. qemu-system-x86 -M q35 -bios path/to/bios ? If I can
reproduce it here, I'm sure I can debug it.
On 12/01/18 11:03, Jens Bauernfeind wrote:
> Hi Mark,
> I installed coreboot succesfully on my t430.
> I build openbios in the x86 version and added the openbios-bultin.elf as addtional payload to the image (with seabios as primary, so i could easily test openbios )
> Unfortunately when I start it, it doesn't recognize the keyboard and several messages "cannot manage <device name>...."
> I know that the laptop keyboard is attached via PS/2, and in the drivers/pci.c is a PS2 Keyboard block.
> Is there anything I can debug?
> Best Regards,
Fascinating, thanks for the screenshot! I suspect the issue with the
keyboard is because it exists behind the PCI-ISA bridge, and since
OpenBIOS isn't able to match your particular bridge against its internal
list then it never generates the appropriate DT nodes.
Now it appears that OpenBIOS does have a default set of legacy devices
for the i82378 PCI-ISA bridge, however they should be equally valid for
your QM77 PCI-ISA bridge and fairly standard.
How about the attached patch which renames i82378_config_cb() to
isa_bridge_config_cb() and also adds in the PCI device and vendor ids
for your particular PCI-ISA bridge into the OpenBIOS configuration?
If this is able to get your keyboard working, a photo of the output of
"show-devs" would be quite helpful :)
I want to build the openbios image for use in coreboot, but it fails.
I am running a 32bit debian 8.10 vm.
Building OpenBIOS for x86
libdrivers.a(pci.o): In function `ob_pci_unmap':
/tmp/openbios/drivers/pci.c:405: undefined reference to `ofmem_unmap'
rules.mak:235: recipe for target 'openbios.multiboot' failed
make: *** [openbios.multiboot] Error 1
make: Leaving directory '/tmp/openbios/obj-x86'
Makefile:19: recipe for target 'build' failed
make: *** [build] Error 1
if i select amd64 on a 64bit machine it works without a problem.
What is the problem here?
> On Dec 29, 2017, at 12:14 AM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote:
> On 2017-Dec-29 00:00 , Jd Lyons wrote:
>> Segher, do you think I maybe tripping over the “ config-l@“?
>> Seems to be a few words called next, after the b(>resolve) I’m catching the exception on.
> Those are words to read and write config space on pci cards. I'm pretty sure the words work (otherwise the vendor-id and product-id values wouldn't have been able to be fetched), the question is whether they are being called with unexpected values. The config-l@ must be called with a mod 4 values, the config-w@ must be called with a mod 2 value.
> The usual mode of accessing config space is adding your desired offset to my-space, and then call config-l@. That looks to be what you are in the middle of:
> 8010039 : (compile) [ 0x9bd ]
> 801003a : (compile) b(lit) [ 0x10 ]
> 801003f : (compile) and [ 0x23 ]
> 8010041 : (compile) my-space [ 0x103 ]
> 8010042 : (compile) + [ 0x1e ]
> 8010044 : (compile) [ 0xa08 ] <<<<<<< is this config-l@?
> 8010045 : (compile) b(lit) [ 0x10 ]
> 801004a : (compile) and [ 0x23 ]
> 801004b : (compile) b(lit) [ 0x10 ]
> 8010050 : (compile) = [ 0x3c ]
> The above looks to me like he's testing for the presence of 0x10 in a register (0x10 and 0x10 =). If he's looking at a series of BARs, that's the prefetchable bit he's looking for.
Do you think it’s having trouble reading the PCI Configuration registers, it was able to change the subsystem-id from 0x50 to 0x10, so I was hoping it had calculated the base address of the PCI card correctly.
I’m really at a loss, never had to dive this deep into forth when hacking these Rom’s for card flashing. It seemed to me that:
b(>resolve) ( 0x0b2 )
(unnamed-fcode) [0xddf]<————This calls the offset? 0xddf
new-token ( 0x0b5 ) 0xddf
b(:) ( 0x0b7 )
b(lit) ( 0x010 ) 0x10
(unnamed-fcode) [0xdde] <——This calls the offset? 0xdde
new-token ( 0x0b5 ) 0xdde
b(:) ( 0x0b7 )
my-space ( 0x103 )
+ ( 0x01e )
dup ( 0x047 )
(unnamed-fcode) [0xa08]<—— this calls 0xa08
new-token ( 0x0b5 ) 0xa08
b(:) ( 0x0b7 )
b(") ( 0x012 ) ( len=9 )
$call-parent ( 0x209 )
b(;) ( 0x0c2 )
I’m sure I’m being too linear in my thinking, as you’ve already pointed out, my-space and config-l@ were called before my exception.
I just can’t figure out what is throwing the exception?