January 2012 - coreboot - mail.coreboot.org

#95: Run coreboot in VirtualBox
by coreboot Dec. 9, 2014

Dec. 9, 2014

#95: Run coreboot in VirtualBox ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: misc | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ It would be nice if we could test coreboot images in VirtualBox, see http://virtualbox.org/. VirtualBox does not (yet) provide a simple mechanism to use a different BIOS in their emulated machines (something like "-L" in qemu). Instead the BIOS image (a custom bochs BIOS + LGPL'g VGABIOS) is converted to C code (an array of bytes, or the like) and merged into the VirtualBox executable. The relevant files are {{{ src/VBox/Devices/PC/DevPcBios.cpp bldprogs/bin2c.c }}} if someone want to hack VirtualBox to easily support using coreboot images instead of their usual BIOS. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/95> coreboot <http://www.coreboot.org/>

2 8

EHCI debug port finder
by Carl-Daniel Hailfinger May 30, 2014

May 30, 2014

I wanted to know which physical port of my multiple USB controllers have the debug capability. There was no way to find that easily, so I created a tool which will do most of the work for the user. Example output: The following PCI devices support a USB debug port (says lspci): 0000:00:1d.7 The following PCI devices support a USB debug port (says the kernel): 0000:00:1d.7 PCI device 0000:00:1d.7, USB bus 3, USB physical port 1 Currently connected high-speed devices: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M |__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M The output can be improved, but it's a good start. Regards, Carl-Daniel -- http://www.hailfinger.org/

5 13

#186: 3com 3c905tx / gpxe boot problem
by coreboot Jan. 10, 2014

Jan. 10, 2014

#186: 3com 3c905tx / gpxe boot problem -----------------------------------+---------------------------------- Reporter: jeroenkrabbendam@… | Owner: stepan@… Type: defect | Status: new Priority: minor | Milestone: Component: coreboot | Keywords: gpxe Dependencies: | Patch Status: there is no patch -----------------------------------+---------------------------------- Although (or: just because) novice in the field, I encountered some problems with netbooting with coreboot. Mobo's tried: Asus P2B, VTech with bios id ITE8671-2A69KV3IC-00. All mobo's boot '''harddisk''' fine with Asus P2B / Gigabyte GA-6BX{CE} respectively. NIC ROM is started, and loads the kernel by tftp. This is vvvveeeerrrryyy slow! Although loading, the kernel is never able to start itself. Same kernel on HDU is no problem at all (GRUB2) Note: the gpxe-image is on the nic, coreboot payload is seabios. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/186> coreboot <http://www.coreboot.org/>

1 1

New patch to review: 49493f5 T60: add volume CMOS setting
by gerrit＠coreboot.org Jan. 28, 2013

Jan. 28, 2013

Sven Schnelle (svens(a)stackframe.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/12 -gerrit

6 10

#131: New flashrom motherboard support
by coreboot Sept. 17, 2012

Sept. 17, 2012

#131: New flashrom motherboard support ---------------------------------+------------------------------------------ Reporter: anonymous | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Going mainstream Component: flashrom | Version: v2 Keywords: flashrom asus | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ Did not know where I should put this but the bugtracker seemed like the right place. I tried flashrom and it could not detect my chip on my ASUS P5ND2-SLI Deluxe motherboard. The board has a SST49LF004B flash chip and after enforcing the right chip flashrom seems to work fine. {{{ # ./flashrom -V -f -r -c SST49LF004A/B test Calibrating delay loop... 796M loops per second, 100 myus = 201 us. OK. No coreboot table found. WARNING: No chipset found. Flash detection will most likely fail. Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x21, id2 0x5e, id1 parity violation No EEPROM/flash device found. Force read (-f -r -c) requested, forcing chip probe success: Probing for SST SST49LF004A/B, 512 KB: Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff80000. Force reading flash... done. }}} This should probably apply to the P5ND-SLI board, too. What do you need from me for adding autodetection of this board/chip? -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/131> coreboot <http://www.coreboot.org/>

1 15

Re: [coreboot] how to delete symbol link created at compile time
by She, Kerry July 17, 2012

July 17, 2012

> -----Original Message----- > From: Marc Jones [mailto:marcj303@gmail.com] > Sent: Tuesday, October 18, 2011 10:39 AM > To: Stefan Reinauer > Cc: She, Kerry; coreboot > Subject: Re: [coreboot] how to delete symbol link created at compile time > > On Mon, Oct 17, 2011 at 4:44 PM, Stefan Reinauer > <stefan.reinauer(a)coreboot.org> wrote: > > * Marc Jones <marcj303(a)gmail.com> [111016 10:10]: > >> >> > I have created 2 devicetree file : > >> >> > > >> >> > devicetree_f15.cb for platform with family 15 CPU > >> >> > > >> >> > devicetree_f10.cb for platform with family 10 CPU > >> >> > > >> >> > > >> >> > > >> >> > I changed the makefile to create a symbol link "devicetree.cb" > link to > >> >> > devicetree_f10.cb or devicetree_f15.cb at compile time. > >> >> > > >> >> > The problem is that I can't delete the symbol link when make > >> >> > clean/distclean. > >> > > >> > Please fix the problem by using one device tree for both platforms. > > > >> Stefan, > >> > >> Can you explain your thoughts on how that would work? Can we put a #if > >> in the devicetree.cb? It uses the c precompiler? It requires different > >> CPU files/device locations. We can try it next week. > > > > Usually the way this is handled in coreboot is that there is one socket > > that binds together all CPU types. Then in the device tree only the > > socket type is specified, and code for both CPUs is pulled in. > > Maybe we need something like a socket for northbridge code, since the > > northbridge now lives in the CPU? > > > > It seems like a bad idea to have to recompile your BIOS because you > > change the CPU. We did a lot of nastyness with K8 and Fam10, but we > > should find a better way to do this for future chipsets/CPUs. > > > Yes, we are discussing how the AGESA code would work. The socket > decision is rather complicated as we need a way to handle multiple > calls with the same names (function point tables etc). I think that > there may be a solution within AGESA, but the device tree may still be > a problem as the CPUs have different HT link numbering. This makes it > hard to have the same device tree layout for the same socket. Because of the function name conflict, put cpu code of 2 families together would not compile. We need to dig into AGESA more to figure out a solution. As for the devicetree problem, following text is the devicetree difference in detail: --- devicetree_fam10.cb 2011-08-15 15:00:14.426692437 +0800 +++ devicetree_fam15.cb 2011-08-15 15:00:14.426692437 +0800 @@ -16,19 +16,17 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA # -chip northbridge/amd/agesa/family10/root_complex +chip northbridge/amd/agesa/family15/root_complex device lapic_cluster 0 on - chip cpu/amd/agesa/family10 - device lapic 0x10 on end + chip cpu/amd/agesa/family15 + device lapic 0x20 on end end end device pci_domain 0 on subsystemid 0x15d9 0xab11 inherit #SuperMicro - chip northbridge/amd/agesa/family10 # CPU side of HT root complex - device pci 18.0 on end # link 0 - device pci 18.0 on end # link 1 - device pci 18.0 on end # link 2 - device pci 18.0 on # link 3, SB on socket0 link 2, on internal Node0 Link 3 + chip northbridge/amd/agesa/family15 # CPU side of HT root complex + device pci 18.0 on end # Link 0 + device pci 18.0 on # Link 1, IO-HUB on socket0 link 2(internal Node0 Link 1) chip northbridge/amd/cimx/rd890 # Southbridge PCI side of HT Root complex device pci 0.0 on end # HT Root Complex 0x9600

2 4

#135: Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E)
by coreboot March 24, 2012

March 24, 2012

#135: Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E) ---------------------------------+------------------------------------------ Reporter: Jan@… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ I've tried updating the BIOS of a Tomcat n3400B (S2925-E). The update itself worked fine, but the MAC addresses of the onboard NVidia-Gigabit Ethernet chips were set to bogus values (66:55:44:33:22:11 or something like that) afterwards. Restoring the old flash backup worked. This does not happen with the official update tool from Tyan. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/135> coreboot <http://www.coreboot.org/>

1 11

Set top box update
by Gregg Levine March 10, 2012

March 10, 2012

Hello! Amazon tells me that there are now two people selling their Akimbo boxes. Perhaps I'll definitely buy one. And Joe here is the linked page which contains a reference to the STB kit from Intel: http://cerberus.teamhackaday.com/?p=3 It turns out that it comes up right below the description for the device. It seems the only thing nonstandard about it is the crappy BIOS that Akimbo insisted on. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 2

flaschip (and compatibles)
by Oliver Schinagl Feb. 22, 2012

Feb. 22, 2012

Hey list, I want (in the far? future) play with coreboot on my new board, an Asus M5A97 (900 series amd chipset) thing. Having it not even build into my case yet, I was wondering if you guys know what a compatible flash chip is. I have an 8 legged little socketable chip on here, with the following markings: MXIC b111376-12G MX25L3206EPI 3F204500 So far I found the best results from google with the MX25L3206EPI labeling but the few links I got where mostly in chinese and the datasheet links where the 'pay' kind. Any pointers what I can ask for when I go to my local hardware store so I can order 3 or 4? Shouldn't be too expensive right? Anything in NL/BE/DE I suppose would work best :)

4 8

Re: [coreboot] Asus M2V-MX problems
by Rudolf Marek Feb. 14, 2012

Feb. 14, 2012

Hi, > I was hoping to use the board above to experiment with Coreboot. The board has > the same northbridge as the Asus M2V-MX SE (VIA K8M890) and the same southbridge > as the Asus M2V (VIA 8237A). Both of those chipsets are fully supported. > Thinking that maybe I can at least get the board to boot ASAP, I built Coreboot > for the Asus M2V board to get the southbridge functionality. I also didn't use > the M2V-MX SE profile because it has the SPI chip, while the M2V-MX board has a > PLCC-32 chip. OK > The board booted fine, except I have no video, serial port or ability to write > to the BIOS chip. No video -> you need to include the extracted VGA bios from original BIOS. No serial port looks like wrong superio setup. No ability to write to the chip sounds interesting ? What do you mean by that. Flashrom cannot no-long overwrite the chip content? Maybe just some GPIO needs to be raised. Do you have more PLCC chips or other boards so you can hotswap them? > I know the board booted fine because I was able to SSH into > the box using a PCI network card. Considering that both the M2V and M2V-MX have > the same southbridge chip, I don't understand why there was not serial port or > write access to the BIOS chip. Can someone shed some light on that for me, please. Yep see above. I would suggest to run the superiotool (see utils dir) and check what kind of superio is really there. Or even better provide ./superiotool -d dump best with original bios running if possible. Then you just need to change few lines and you should get serial back. I can even help with that but we need to know not only the chip there but also how the chip is configured. For the VGA you need to use bios_extract and extract the VGA bios from orig bios image and tell coreboot via menu to include that (you need just pci ID lspci -n will tell) > My other problem is I would like to create a build profile for the M2V-MX using > the code from the M2V for the southbridge and the code from the M2V-MX SE for > the northbridge. Is that a good idea or would I have to do some other things? > I learned C programming in 1993 and used it only until 1998; I am a little > rusty. Well C is simple you will got it back soon. > My ability to make sense of low-level chipset stuff is also very > narrow. If you ask good questions you will get answers. > However, I am a fast learner and I am desperate to get something > accomplished for a homebrew thin client project that I have spent way too much > time working on. > > My goal is to extend the life of boards that people send in for recycling by > turning them into more reliable diskless information terminals. A nice coreboot use! Thanks Rudolf

3 3