OpenBIOS January 2018

openbios@openbios.org

8 participants
14 discussions

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

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. > > Jens 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. ATB, Mark.

2 1

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

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, > Jens 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 :) ATB, Mark.

2 1

failed to build
by mr.jb＠gmx.de 12 Jan '18

12 Jan '18

Hello, I want to build the openbios image for use in coreboot, but it fails. I am running a 32bit debian 8.10 vm. $ make /usr/bin/xsltproc Building OpenBIOS for x86 Building... error: AR libfs.a CC target/libgcc/ashldi3.o CC target/libgcc/ashrdi3.o CC target/libgcc/__lshrdi3.o CC target/libgcc/__divdi3.o CC target/libgcc/__udivdi3.o CC target/libgcc/__udivmoddi4.o CC target/libgcc/__umoddi3.o AR libgcc.a LINK openbios.multiboot 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[1]: *** [openbios.multiboot] Error 1 make[1]: 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? Thanks Jens

3 4

Re: [OpenBIOS] b?branch
by Jd Lyons 02 Jan '18

02 Jan '18

> 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. >> >> config-l@ >> config-l! >> config-w@ >> config-w! > > 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 ) " config-l@" $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?

5 22