Re: [coreboot] Patch merged into coreboot/master: c35c461 Invalidate cache before first jump
I'm not sure why it would be breaking anything, but it just doesn't make sense. From Volume 3: Because all internal cache lines are invalid following reset initialization, it is not necessary to invalidate the cache before enabling caching. It is pretty weird, I downloaded one random Sandybridge ROM image from ECS, and I did not see the WBINVD before the far jmp. Also, caches *should* remain valid after INIT, but this change will invalidate them unconditionally (unless INIT follows a different path in coreboot) Tom On Fri, Apr 6, 2012 at 11:26 AM, Stefan Reinauer stefan.reina...@coreboot.org wrote: * Patrick Georgi patr...@georgi-clan.de [120406 17:32]: Am 06.04.2012 17:27, schrieb Marc Jones: Can you be more descriptive to how it fails? Does it hang on that instruction? That change might also break on future CPUs (if they finally manage to make the TPM stuff secure, so that's a big if) How so? Guess I'll have to work making that a CONFIG option. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch set updated for coreboot: 6709bdd Fix multipleVGA cards resource conflict on Windows
The open-graphics people had this question a while back, I think I took a look at some different platforms and BIOSes: http://lists.duskglow.com/open-graphics/2007-August/010402.html Turning on the decoders for only one of each type of legacy device sounds right. On Mon, Dec 19, 2011 at 6:13 PM, She, Kerry kerry@amd.com wrote: Hello, Patrick -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Patrick Georgi Sent: Tuesday, December 20, 2011 1:31 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Patch set updated for coreboot: 6709bdd Fix multipleVGA cards resource conflict on Windows Am 19.12.2011 18:02, schrieb ron minnich: I wonder if a better way to manage this is via a CMOS (aka NVRAM) setting. No user visible configuration if it can be avoided, please. I kind of hate to limit coreboot because Windows is limited. But I'm a n00b in a sense, having just come back onto this project, so I'm happy to be told I'm wrong :-) It sounds just wrong to have IO/MEM decoding on the _same_ areas activated for two devices. Yes, exactly. vgaarb should still work with one of them having resources disabled by default, I think. I have tested Linux vgaarb still works. We just do a part of the vgaarb job in coreboot. Otherwise coreboot would be the _only_ chance for vgaarb to work, as all other boot systems will support Windows even to the detriment of Linux support. Which means that vgaarb wouldn't exist, given their position towards coreboot. It make sense on the OS lacking a mechanism like vgaarb. Anyway, more test on different OS is needed. Thanks Changing circumstances mean I get to work on it again, which is nice. Yay! Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] I am reading the source code of coreboot, how do I understand the functions
If you want to browse around a bit, there is an LXR cross reference of coreboot available here: http://lxr.linux.no/coreboot Tom On Mon, Sep 12, 2011 at 8:48 AM, Jianmin Pan dsp...@gmail.com wrote: I am a newbie to coreboot, I am wondering is there an easy approach to understand the functions. For instance, when I am reading fallback_boot.c, it's very difficult for me to understand such functions as inb(), outb(),RTC_PORT(). The method I am using now is to grep the function name and find out which file it is in. Then read it. However, I still feel inconvenient. I am used to use vim. So, anybody have good suggestions? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Flashing via TPM
Hello Andrew, AMD SB800-ish southbridges will only selectively fetch BIOS from LPC or SPI based on straps. Your board won't fetch from LPC unless you change the strap (which are unknown resistors on your board). Your best option is SPI in-system programming, and you can just use the SPI header that is already in place. There are some cheap SPI wigglers supported by flashrom. Tom On Fri, Jul 15, 2011 at 7:30 AM, Andrew Bolster m...@andrewbolster.infowrote: Hi folks; I've got a MSI350IA-E45 board, which is a AMD fam 14h board with a AMD SB700/800 southbridge. I'd like to contribute by porting coreboot to the board, but I'm not sure where to start; there's no LPC header! I threw together a patch-cable for my secondary LPC bios, and the board doesn't explode when I use the cable (always a good sign) but it doesn't appear to effect the boot; I assume that the stock bios is refusing to let it take over. There is an SPI header, but I don't have an SPI ROM emulator, so at this point, what are my options? Is there a way to force the board to look at the TPM/LPC socket? Regards Andrew Bolster http://andrewbolster.info/blog/?utm_source=correspondenceutm_medium=emailutm_campaign=Personal%2BEmailhttp://www.linkedin.com/in/andrewbolsterhttp://facebook.com/andrew.bolsterhttp://twitter.com/bolster No trees were killed to send this message, but a large number of electrons were terribly inconvenienced.I enjoy the massacre of ads. This sentence will slaughter ads without a messy bloodbath. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI clock rate
Hello Andreas, Your ideas sound pretty good, but here are a couple of ideas that might make your life easier (and cheaper). I found some high-res pictures of your board on the web, and it looks like that board has a footprint for a SPI programming header (labelled SPI1, between USB1 and the SPI ROM). Board manufacturers put these headers on the board for BIOS development, to do exactly what you are trying to do: in-system SPI flash programming (they are often called in-system programming headers). One common commercial programmer is the SF100 from dediprog: http://www.dediprog.com/SPI-flash-in-circuit-programming You can solder in a header (looks like a 2mm), or even just wires, and connect whatever USB to SPI adapter you want. You just leave the SPI ROM installed, and program it through the header. The header is designed so that even with the board off, the programmer hardware supplies power to the ROM device (only). Your board manual may have the pinout, or just use a meter to figure out how it connects to the SPI ROM. Also, if you haven't seen it yet, take a look at the flashrom project: http://www.flashrom.org/Flashrom which can update flash from an OS, but also supports external programmers like you are trying to achieve: http://www.flashrom.org/FT2232SPI_Programmer To answer your question, SPI clock rates are often about 33MHz, but some devices support faster speeds. You can usually run it much slower though. Tom On Mon, Jul 4, 2011 at 1:42 PM, Andreas Galauner andr...@galauner.de wrote: Hello everybody, I recently started to discover this great project you have here. I want to play with it a bit and port it to an AMD E-350 Motherboard (Sapphire Pure Fusion Mini E-350 - what a name...) I have at home in my spare time. Now I don't think that the development work is much fun, when you have to take the SPI chip off the motherboard, program it, put it back into the board, see the code failing and repeat the whole process ;) So, I had the idea of developing a small Board which contains a USB port and an SPI flash. I first thought about emulating the SPI flash completely by an AVR, but I think the clock rates of the SPI bus are too high to do this. My new approach is a SPI flash which resides on the AVR board which can be multiplexed between the AVR to program it and the motherboard. If I want to test a new BIOS, the AVR puts the motherboard into reset, detaches the flash chip with a multiplexer from the motherboard, programs it, switches it back to the motherboard and let off the reset. Rapid BIOS development :) As an added bonus, I'm thinking about using a USB 2.0 port of an USB-capable AVR as a USB debug interface (those USB debugging cables are expensive for a poor student ;) ) and add a second USB 1.1 port with a MAX3420 for host-communication, but that's step 2. I know that I won't get the full 480MBit/s with this, but I think I can live with that. As I am currently looking for suitable parts, I need to know some basic parameters of the SPI communication. Does anybody of you know what the typical clock rates between the chipset and the flash are? Andy -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte GA AMD E350N USB3 Board
Hi Marek, When I first got the board, I checked the signals of the DB_PORT header with a meter, and found several connections going to the Super I/O instead of the flash chip. I was thinking it might be a serial port header of some non standard pinout instead of a SPI header. It would be good to double-check though. Tom On Mon, Apr 18, 2011 at 5:53 AM, Marek mlf.c...@gmail.com wrote: Hi Tom and Niklas, What about the DB_PORT programming header? Is the dual BIOS stored on the MX25L1606EM2I-12G chip? I'm not interested in USB3 that much although it's a nice and useful feature but it seems to be a very good board in general. Marek On 16.4.2011, at 11:12, Tom Sylla tsy...@gmail.com wrote: Hi Marek, I do own this board, and it is probably one of the more painful to get ported. There is no SPI header, no serial port, and it has the gigabyte dual-BIOS mechanism to deal with. I also have an MSI e350 mini-ITX board, without any of those problems, and maybe someday I will try to make a port for it. Tom On Tue, Apr 12, 2011 at 7:07 AM, Marek mlf.c...@gmail.com wrote: Hi Peter, On 12.4.2011, at 15:08, Peter Stuge pe...@stuge.se wrote: Marek wrote: with regards to recent AMD patches, Note that the patches did not include support for your mainboard. I'd like to ask whether it would be possible to install coreboot on Gigabyte GA AMD E350N USB3 board (AMD E350, chipset FCH A50 Hudson M1, iTE 8720). The answer is, as always, no it will not work unless you make it work. The final piece of the puzzle, mainboard support, is still missing, but all the other 4999 pieces have been put in place for you by AMD and the rest of the coreboot community. thanks for your answer, I'm fully aware of the situation, my question was more directed to people (if there are any) who own that MB, perhaps work on coreboot support, or have considered it and abanonded it in the initial phase or even made progress but were unable to continue due to various circumstances. No answer most likely means that there isn't anyone who owns this board so far, so I just pushed all information I could find out without buying that board in case someone wants to buy one and add coreboot support for it. Marek //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte GA AMD E350N USB3 Board
Hi Marek, I do own this board, and it is probably one of the more painful to get ported. There is no SPI header, no serial port, and it has the gigabyte dual-BIOS mechanism to deal with. I also have an MSI e350 mini-ITX board, without any of those problems, and maybe someday I will try to make a port for it. Tom On Tue, Apr 12, 2011 at 7:07 AM, Marek mlf.c...@gmail.com wrote: Hi Peter, On 12.4.2011, at 15:08, Peter Stuge pe...@stuge.se wrote: Marek wrote: with regards to recent AMD patches, Note that the patches did not include support for your mainboard. I'd like to ask whether it would be possible to install coreboot on Gigabyte GA AMD E350N USB3 board (AMD E350, chipset FCH A50 Hudson M1, iTE 8720). The answer is, as always, no it will not work unless you make it work. The final piece of the puzzle, mainboard support, is still missing, but all the other 4999 pieces have been put in place for you by AMD and the rest of the coreboot community. thanks for your answer, I'm fully aware of the situation, my question was more directed to people (if there are any) who own that MB, perhaps work on coreboot support, or have considered it and abanonded it in the initial phase or even made progress but were unable to continue due to various circumstances. No answer most likely means that there isn't anyone who owns this board so far, so I just pushed all information I could find out without buying that board in case someone wants to buy one and add coreboot support for it. Marek //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SuperI/O Access (Kernelspace)
Your address is in I/O address space, not memory address space. Take a
look at io_rw.c in iotools, you need to be using inb/outb (not just
reading/writing memory).
Tom
On Thu, Apr 14, 2011 at 4:12 PM, Jeremy Moles jer...@emperorlinux.com wrote:
Hey guys, me again. :)
So, my device is working great now that I can access the GPIO pins via
userspace (using iotools w/ Tom Sylla's help) and can power on the
device. However, I'd like to be able to toggle the power on via a kernel
driver as well, but I'm having trouble accessing the same memory range
from kernelspace.
For example:
iotools io_read8 0xA00
Will return the state of the first 5 GPIO pins. I see that iotools calls
iopl() to be able to access this location from userspace.
When I try to do the same thing in the kernel:
unsigned short b;
unsigned short* ptr = (unsigned short*)(0xA00);
if(access_ok(VERIFY_READ, ptr, 8)) {
get_user(b, ptr);
...I immediately get a segfault. From what I've read and seen in other
example code, I believe I'm doing this right. However, I may be making
some wrong assumptions. I was just curious if anyone would be able to
shed some light on the subject--perhaps I'm missing some virtual memory
offset functions or similar...
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot meeting @ Google, Sunday Mar. 13
Central Computers has a couple in stock also, the GA-E350N-USB3 (dual BIOS pain) and I believe the E35M1-M Pro (microATX) On Fri, Mar 11, 2011 at 6:29 PM, David Hendricks dhend...@google.com wrote: Hey everyone, Stefan and I are going to be @ Google in Mountain View hacking on Coreboot this weekend, so we figured this would be a good time to host another users group meeting for those interested. This time we'll be hacking on our shiny new AMD Persimmons (Fam 14h / Fusion) dev boards which I have been assured by AMD are non-confidential so anyone curious can come in and poke at 'em. Or you can swing by Fry's before coming and pick up a generic E350 board, like the one Scott Duplichan recently ported: http://www.coreboot.org/pipermail/coreboot/2011-February/063737.html When: Sunday Mar. 13, noon to 8pm Where: 1950 Charleston Rd. in Mountain View [ Link ], Alamitos conference room (1st floor, adjacent to lobby) Contact #: 408-512-3445 (last meeting's participants bcc'd since this is pretty short notice) -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Proliant dl145 g3 Can't read Boot disk
This is all a bit fuzzy now, but this is what I recall: The HT1000 SATA controller can also be configured as a PATA/IDE device. It will show up as 024B instead of 024A when it is configured that way: http://pci-ids.ucw.cz/read/PC/1166/024b The mechanism to do the switch is in the HT1000 (BCM5785) databook, which no one probably has access to. If you can get it into that mode, legacy IDE access should work. For the native mode, there should be an option ROM to give int13 replies. If you want to program it in SATA mode, there is a Linux driver for reference (it is not AHCI). The option ROM is probably easiest. You might want to ask the HT COE guys (the originators of the DL145 code) to see how they were booting. On Mon, Feb 21, 2011 at 3:45 PM, Kevin O'Connor ke...@koconnor.net wrote: Hi Jay, I'm CC'ing the list. On Mon, Feb 21, 2011 at 05:22:19PM -0500, jarray52 jarray52 wrote: Hi Kevin, Here is the output of lspci -vvv. http://coreboot.pastebin.com/PxF6JdKT Currently, there is one SATA hard disk attached to an on board SATA connector. The machine does not have any other hard drives attached. The LSI SAS controller has been removed from the HP Proliant dl 145 g3 server. Thanks. The lspci shows: 01:0e.0 RAID bus controller: Broadcom BCM5785 [HT1000] SATA (Native SATA Mode) (prog-if 05) So, the device doesn't use a standard class code. Does anyone know if it accepts standard ATA or AHCI commands? If so, SeaBIOS could be hardcoded to try and use the device. I sent two E-mails to the mailing list. The other E-mail I sent to the mailing list contains the errors when the LSI SAS controller is attached. The second email - the one with the SAS controller - did not have debug level set to 8. -Kevin Thanks, Jay On Mon, Feb 21, 2011 at 8:53 AM, Kevin O'Connor ke...@koconnor.net wrote: On Sat, Feb 19, 2011 at 06:26:30PM -0500, jarray52 jarray52 wrote: Hi, My HP Proliant dl145 g3 with Coreboot Bios and SeaBIOS payload cannot read my hard disk. Here is the serial console output. http://coreboot.pastebin.com/HYee3u0t For easy reference, here is the coreboot page on the HP Proliant dl145 g3. http://www.coreboot.org/HP_DL145_G3 To ensure the problem was not caused by an HP BIOS or the LSI SAS controller raid initialization of hard drives, I used a hard drive with OS created on a non HP(Asus) without either hardware or software raid. No hard drive with boot sector was readable by coreboot/seabios. The log shows SeaBIOS found an ATA controller, but did not find any drives attached to the controller. It did not find an option rom on any cards - so no scsi option rom was run. Can you post the output of lspci and identify which device you expected to boot from? -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More SeaBIOS timings
This looks like it was an interesting task. I had some questions and comments from previous fast-POST exercises: On Mon, Dec 21, 2009 at 12:44 AM, Kevin O'Connor ke...@koconnor.net wrote: * cpu appears to start running around 350ms Do you have a scope at all?. The only way to know this number for sure would be to put a scope on the reset wire and the rs-232 to see how long the power sequence takes. * smbus power stabilizes around 400ms I don't understand this. SMBus power is 3.3V, and I don't know why a platform would be executing code before 3.3V is stable. The ATX is turning on 3.3, 5, and 12 *first*, then the various regulators, including the core regulator, come on after that. There should be various hardware voltage monitors keeping things in reset until all the voltages are up. Am I not understanding something? What exactly do you mean by smbus power stabilizes? * I've commented out the calls to wbinvd() in coreboot's mtrr cache_disable logic - those calls are expensive and the code seems to work without it. You removed *all* of them? You might just be getting lucky, that is a bit dangerous. Just a note: PCI has a specified time called Trhfa which is the time from reset going high to the first allowable configuration access. It is specified as 2^25 clocks, which is 1 second for 33MHz PCI and 500ms for 66MHz PCI. You have to heed that if you want to generically support random PCI plugin cards. If you are making fixed-configuration concessions, then you can do it as fast as your particular hardware allows. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Looking for AMD AGESA GPL-ed source code
Sorry, I don't understand this mail. AMD VSA is for Geode PCI configuration space emulation and AGESA is for FamF and Fam10 initialization. They are unrelated. On Wed, Nov 18, 2009 at 8:26 AM, Stefan Reinauer ste...@coresystems.de wrote: On 11/18/09 7:50 AM, Darmawan Salihun wrote: Hello all, Sorry if this sounds like a rather stupid question. Is the GPL-ed AGESA source code already becomes part of the coreboot svn? or I have to download it somewhere else? Thanks. svn://coreboot.org/vsa Additionally there's OpenVSA which compiles with a GNU toolchain but does not work completely, yet: svn://coreboot.org/openvsa Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPD sanity check
On Fri, Oct 2, 2009 at 4:07 PM, ron minnich rminn...@gmail.com wrote: Maybe it is a difference in view. The address is 7 bits in all the docs. How it is laid out in the register and on the bits on the wire is really a different concern. Sorry for the dead horse revival, but I was just looking at an SMBus spec today, and it reminded me that the specs I look at always seem to show the address left justified; 8 bits big. See page 10 of this doc: http://www.atmel.com/dyn/resources/prod_documents/doc5226.pdf or page 6 of this one: http://www.nxp.com/acrobat_download/datasheets/PCA9555_8.pdf the documents show the register pictures like 0xAX, not 0x5X+1bit :) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fallback/normal support [PATCH]Remove non-CBFS
Peter Stuge wrote: Patrick Georgi wrote: What I don't know is, do we require any chipset setup to _reach_ CMOS? It's not generally in the CPU, so some setup may be needed. On the other hand, maybe 70/71 are decoded correctly on power up, just like flash access? It's not like there is a spec or anything, but most of the PC AT junk in IO space will be accessible from first fetch. Disassemble the early portions of some AMI or Phoenix BIOSes, and you'll see accesses to things like CMOS in the first few instructions. Legacy accesses have to die somewhere subtractively, and the RTC usually is in that path. Tom -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPD sanity check
On Fri, Oct 2, 2009 at 12:53 PM, ron minnich rminn...@gmail.com wrote: On Fri, Oct 2, 2009 at 4:53 AM, Carl-Daniel Hailfinger The lm_sensors tools are handy when everything is working fine. They're not when things are not. In my case, things are not and, sadly, the tools are largely useless -- I'm going to have to write my own. I have a collection of DIMMs I use for testing platforms, and I keep SPD dumps for each DIMM handy. Then I can look in my list of eeprom dumps to find the aprticualr specs I need to test easily. I don't really use any tools, Appendix A and hexdump are all you need. A further problem is the lm_sensors guys don't always understand Unix (a common problem nowadays :-) or decode-dimms would be two tools: 1. get_spd 2. decode_spd get_spd is 'modprobe eeprom; cp /sys/bus/i2c/devices/0-0054/eeprom ./eeprom' Regarding your other mail, I think you did not decode it carefully enough. It looks ok to me, I even see this string: 4D 33 20 39 33 54 33 32 35 33 46 5A 30 2D 43 43 M3 93T3253FZ0-CC and google says 93T3253FZ0 is a Samsung DDR2, registered, ECC DIMM You said offset 2 is fundamental memory type, which is true. '08' is certainly valid though, I see 08 as DDR II SDRAM in appendix A (is yours the latest?) Here are the first lines of the dumps of some of the DIMMs in my collection: [tsy...@x DDR2]$ for i in `ls`; do hexdump -C $i/eeprom|grep ; done 80 08 08 0e 0a 60 48 00 05 25 40 06 82 08 08 00 |.`h...@.| 80 08 08 0d 0b 60 48 00 05 3d 50 02 82 04 04 00 |.`H..=P.| 80 08 08 0e 0a 61 48 00 05 25 40 06 82 08 08 00 |.ah...@.| They are pretty consistent with yours. Please get the latest JEDEC specs and decode your dump more carefully; I think you will find it makes sense. (I checked for you that the checksum at 3f is correct) As a side rant, why does do Linux and coreboot insist on referring to SMBus addresses shifted right byte one bit? They are 7 bits long, and should be *left* justified in the byte. Take a look at every SMBus controller, and you will see that is how the register is laid out, address is the top 7 bits, and the bottom bit is read/write. Take a look at the SMBus drivers in coreboot, and you will see the access function doing something like: dimm_address 1 | READ_WRITE. It just seems silly to me :) Tom -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GPIOs on CS5536 based boards
On Wed, Sep 23, 2009 at 1:10 PM, Daniel Mack dan...@caiaq.de wrote: Could you outline which steps would need to be taken in order to find out the correct address to use? Any maybe a way to sany detect the precence of that function on the board? I might go ahead and send a patch for the driver then. Not really an outline; it is just one MSR read. Take a look at the GPIO kernel driver: http://lxr.linux.no/#linux+v2.6.31/drivers/char/cs5535_gpio.c#L188 Also, to correct the 0xF scan ickiness, the proper way to detect a board revision is usually done by reading a PCI subvendor/subdevice ID too. I don't know if alix's non-coreboot BIOS does that properly. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Geode LX VGA BIOS Patch
On Sat, Aug 15, 2009 at 12:00 AM, Chris Kindtchriski...@umbc.edu wrote:
+static union u64_u32_u lx_msrRead(u32 msrAddr)
+{
+ union u64_u32_u val;
+ asm __volatile__ (
+ movw $0x0AC1C, %%dx \n
+ movl $0xFC530007, %%eax \n
+ outl %%eax, %%dx \n
+ addb $2, %%dl \n
+ inw %%dx, %%ax \n
+ : =a (val.lo), =d(val.hi)
+ : c(msrAddr)
Does the geode do something magical with the above sequence?
Otherwise, I'm a bit confused on how the asm works.
This is a magic port. The geode SMM (VSA2) provides a few functions from
this interface.
To be a little more clear, writing to port ac1c causes an SMI, VSA
looks at the value written to the fake port, does whatever it is
asked, and returns things based on the function being called. If
this particular case is just used to read an MSR, you could just do it
natively instead.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Eagle Height evaluation board support
On Wed, Jun 24, 2009 at 8:43 AM, Thomas JOURDANthomas.jour...@gmail.com wrote: I forgot to mention that on the IRC, someone suspected a missing timer setup leading to a division by zero. This might help. In the past, when trying to figure out a VGA ROM execution hang or errors, it has been very helpful to watch full IO tracing in the emulator to see what IOs were being accessed just before the hang. It would be interesting if you could do the same, especially if you are suspecting that some legacy part is not set up properly. I don't know the exact mechanism to do that in the emulators you are trying (or if it is possible any more), but it may be helpful to try. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCIe config and MMCONF
On Wed, May 13, 2009 at 10:26 PM, Peter Stuge pe...@stuge.se wrote: If MMCONFIG is the term that applies, then better use that instead: MMCONFIG_BAR_BASE and _SIZE One note, BAR might be a little bit confusing. BAR has a pretty strong tie to an actual register in a PCI config header. I think the variables you are describing are really just the address and size where MMCONFIG is located, not necessarily an actual register. MMCONFIG_BASE and MMCONFIG_SIZE seem pretty clear and simple -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fix for cbfs error for longer file names
On Tue, May 12, 2009 at 11:09 AM, ron minnich rminn...@gmail.com wrote: The next big step in my view is setting a flash-friendly value of zero. Do you mean flashrom-friendly value of 0xFF? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP DL145G3 - BuildBot
On Tue, May 12, 2009 at 7:44 AM, samuel samuel.verstra...@gmail.com wrote: Because SeaBIOS does not support AHCI SATA it can not start the bootable drive of the machine so i had to add filo to seabios to manage booting: ./cbfstool coreboot.rom add-payload filo.elf img/FILO I think you may still be able to get this part working without FILO, but I am not sure how. The HT1000 SATA is not AHCI, so support for AHCI won't actually help. The controller has normal PATA emulation mode, as well as its own QDMA SATA mode (in lieu of AHCI). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP DL145G3 - BuildBot
On Tue, May 12, 2009 at 12:46 PM, Myles Watson myle...@gmail.com wrote: I think you may still be able to get this part working without FILO, but I am not sure how. The HT1000 SATA is not AHCI, so support for AHCI won't actually help. The controller has normal PATA emulation mode, as well as its own QDMA SATA mode (in lieu of AHCI). Are you saying that FILO shouldn't be working, or that SeaBIOS should be working? What Peter said, it seems like SeaBIOS could work, with some more effort. There is some sort of combination of controller mode or settings that should make it work, on our HT1000 platform, with non-coreboot BIOS, we can boot all OSes in HT1000 PATA mode. The controller seems to be in SATA mode and works with FILO. That sort of sounded non-ideal from the original mail, but if it is no problem, then there doesn't need to be more effort. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] First support for HP DL145 G3
On Wed, Apr 22, 2009 at 8:00 AM, samuel samuel.verstra...@gmail.com wrote: 2. VGA output is still not working. I have tried both YABEL and X86BIOS to load the vga rom but i get errors... X86BIOS: http://merlin.ugent.be/~samuel/dl145g3/vgarom/corebootx86bios.log relevant part: On mainboard, rom address for PCI: 00:04.0 = fff0 copying VGA ROM Image from fff0 to 0xc, 0x8000 bytes entering emulator int1a vector at 274af YABEL: http://merlin.ugent.be/~samuel/dl145g3/vgarom/corebootYABEL.log relevant part: On mainboard, rom address for PCI: 00:04.0 = fff0 copying VGA ROM Image from fff0 to 0xc, 0x8000 bytes pci_cfg_read(): Config read access invalid device! bus: 00 (00), devfn: 00 (20), offs: 00 I only see two int 1as in the ROM binary: seg000:77DC B8 02 B1 mov ax, 0B102h seg000:77DF B9 41 15 mov cx, 1541h seg000:77E2 BA B9 10 mov dx, 10B9h seg000:77E5 BE 00 00 mov si, 0 seg000:77E8 CD 1A int 1Ah ... seg000:7801 B8 02 B1 mov ax, 0B102h seg000:7804 B9 43 52 mov cx, 5243h seg000:7807 BA B9 10 mov dx, 10B9h seg000:780A BE 00 00 mov si, 0 seg000:780D CD 1A int 1Ah so it is searching for the 0th instance of ven/dev 10b9:1541 or 10b9:5243: http://www.ctyme.com/intr/rb-2372.htm Those are: 10b9 ALi Corporation 1541 M1541 10b9 1541 ALI M1541 Aladdin V/V+ AGP System Controller 5243 M1541 PCI to AGP Controller which seems kind of weird. Maybe it does some workaround when on a platform with those devices. Also, is there any tracing you can enable (or just add) in the emulators? (to see more closely where it is failing, there is probably more execution after the int 1a and the config read of 0) I don't know if YABEL's and X86BIOS's messages are warnings or errors. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] First support for HP DL145 G3
On Tue, Mar 31, 2009 at 12:56 PM, Stefan Reinauer ste...@coresystems.de wrote: thank you very much for your patch. Do you happen to know if the component's name is HT2100 or HT21000? Just to make sure we have it in the repository correctly. The naming in the patch looks right. Broadcom refers to it as HT-2100 on their website: http://www.broadcom.com/products/Small-Medium-Business/SystemI-O-Products/HT-2100 and as both HT-2100 and BCM21000 in the datasheet (often as BCM21000 (HT-2100) ). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] msrtool CS5536 interrupt and DIVIL LBAR MSRs
2009/1/30 Peter Stuge pe...@stuge.se:
Peter Stuge wrote:
Can someone please review these register definitions? Thank you!
Attaching latest version also available at
http://stuge.se/mt.cs5536_pic_divil3.patch
const struct msrdef cs5536_msrs[] = {
+ /* 0x5148-0x514f per 33238G pages 356-361 */
+ /* 0x51400015 per 33238G pages 365-366 */
+ /* 0x51400020-0x51400027 per 33238G pages 379-385 */
+ { 0x5148, MSRTYPE_RDWR, MSR2(0, 0), DIVIL_LBAR_IRQ, Local BAR
- IRQ Mapper, {
+ { 63, 15, RESERVED },
+ { 48, 1, RESERVED },
I'm sure there is some reason, but why isn't this just { 63, 16, RESERVED }, ?
+ { 47, 4, IO_MASK, I/O Address Mask Value, PRESENT_BIN, {
The masks are probably most readable as hex, especially to match the
display type of the BAR.
+ { 0x5149, MSRTYPE_RDWR, MSR2(0, 0), DIVIL_LBAR_KEL, Local BAR
- KEL from USB OHC Host Controller, {
Copied directly from the spec, but just Local BAR - KEL from USB OHC
wouldn't propagate RAS Syndrome.
+ { 0x51400020, MSRTYPE_RDWR, MSR2(0, 0), PIC_YSEL_LOW, IRQ Mapper
Unrestricted Y Select Low, {
+ { 63, 32, RESERVED },
+ { 31, 4, MAP_Y7, Map Unrestricted Y Input 7, PRESENT_BIN, {
HEX is maybe more readable for all of these selects?
+ { 0, 1, IG8_STS_PRIM, Primary Input 8, PRESENT_BIN, {
+ { MSR1(0), No interrupt. },
+ { MSR1(1), Interrupt status. },
Like Myles said, Interrupt set or maybe Interrupt requested for value '1'
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SCALE
Do most normal motherboards supply +5V on pin 7 of their SATA connectors to make this work? Are you using them on an off-the-shelf motherboard? This looks like something intended for an embedded design, where you make your connector a non-standard pinout to support it. On Mon, Jan 12, 2009 at 4:03 PM, Dan Lykowski engineerguy3...@yahoo.com wrote: I would suggest this part: http://www.innodisk.com/flashstorage_specification.jsp?flashid=29 They plug right in to the SATA port. They have a minor quirk where you have to 'force.libata=1:1.5g' to get them to work under Linux but that is the only negative I have run across so far. Dan Lykowski --- On Mon, 1/12/09, Peter Stuge pe...@stuge.se wrote: From: Peter Stuge pe...@stuge.se Subject: Re: [coreboot] SCALE To: coreboot@coreboot.org Date: Monday, January 12, 2009, 2:55 PM -Inline Attachment Follows- ron minnich wrote: I'd like to have the 5 second boot to X demo at the table. If somebody can help direct me to getting that set up, I'd appreciate it. If you don't want to cram everything into a 16Mbit flash chip, which could be tight, you need some ATA flash to store apps on. Since the dbm690 has an LPC PLCC socket you can use the dongle and my adapter plug though, that way you have 32Mbit which is already more roomy. Maybe the dongle occupied for the ALIX already? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Yet another idea of an SPI flash chip programmer
This will definitely work, a couple of years ago, we researched this exact setup. Our plan was to put headers on the motherboards were we deisnging, to have an easy de-bricking mechanism. A co-worker wrote a windows SPI flasher in a day or so. I have seen that exact device used to program SPI ROMs, as well as master JTAG, and program Altera FPGAs (they have a generic bit-bang mode too). It works quite well. I think I have sent these to the list before, but DLP Design makes pretty cheap little adapter boards ($20-40), including one for the 2232 series: http://www.dlpdesign.com/usb/2232m.shtml That with a protoboard and an appropriate socket is all you need for a SPI programmer. If you have a SPI programming socket on your motherboard, it is even easier. It should be pretty fast too. I am actually making an LPC ROM reader/writer from a FT245 (similar to paraflasher, but using USB instead of parallel) Both windows and linux support for the devices is very good. On Mon, Dec 22, 2008 at 6:45 AM, FENG Yu Ning fengyuning1...@gmail.com wrote: There are lots of flash programmer out there, but none of them (those I know about) fits my requirement well. I would like a programmer to be: * able to program SPI flash chips, * not slow (program 512k bytes in 3 mins), * with a driver whose source code is available (or not difficult to write one), * simple, and * cheap. There is one that almost does the job, http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer but [0] would it be very slow? Recently I find a chip FT2232x http://www.ftdichip.com/Products/FT2232C.htm It seems that the chip's IO could be configured to work in bit-bang mode and thus able to implement as an SPI I/F. [1] I think it is easy to build a prototype programmer using this chip. Is it? [2] Is the programmer going to meet my requirement? yu ning -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LPCflasher Project
On Sat, Nov 15, 2008 at 2:29 PM, Joseph Smith [EMAIL PROTECTED] wrote: Anyone know if USB ports have power feedback protection. What I mean by that is if I use the LPCflasher as a inline flasher with a PLCC32 socket plug, flash the chip and then power up the motherboard, I don't want the VCC's from the motherboard to short out the flasher and or the USB port from the host PC. The 3.3V regulator I am using has a internal diode so I am not so worried about that. I am just worried about the power source 5V USB. I could always use a Schottky diode that will only drop the voltage by .6V, but I don't know if 4.4V will suffice??? I am a little bit confused about your usage model. What it sounds like: You will have a target PC for which you are developing firmware. Some sort of PCB or protoboard with one PLCC socket and one PLCC stacking connector will be plugged into the ROM socket of that PC. A ROM device will be plugged in to the PLCC socket of your PCB. Another PC will be a development system, and a USB and parallel cable will connect from your PCB to the development PC. With the target PC *off*, you will re-flash the ROM from the development PC If that is an accurate description, I think you have a few more things to be careful about. The hazard you are asking about deals with the 3V from the target PC turning on and fighting the ~3-5 of your protoboard. What about while you are flashing? You will be injecting 3V from your prototype into the 3V rail of the target motherboard, which is not generally a good idea. Also, you will be attempting to drive the LPC signals against a dead motherboard, which may or may not work. If the ROM is socketed, why not just program the ROM in your device, then pull it out and put it in the target? If you really want the convenience of not having to do that, you'll probably have to be a little more careful about not fighting the target. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] K8 HT architecture
On Fri, Oct 24, 2008 at 8:24 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Would you mind posting lspci -tvnn for that 5-processor board as well? It would help me a lot to understand this issue better. Here they are, if you are still interested. There is a 5-node, and 8-node, and a 2-node with an nc device attached. This system is Barcelona, so you will see more devices for each Opteron. -+-[:20]---06.0 Unknown device [1872:001c] \-[:00]-+-01.0-[:01-02]--+-0d.0-[:02]-- |+-0e.0 Broadcom BCM5785 [HT1000] SATA (PATA/IDE Mode) [1166:024b] |\-0e.1 Broadcom BCM5785 [HT1000] SATA (PATA/IDE Mode) [1166:024b] +-02.0 Broadcom BCM5785 [HT1000] Legacy South Bridge [1166:0205] +-02.1 Broadcom BCM5785 [HT1000] IDE [1166:0214] +-02.2 Broadcom BCM5785 [HT1000] LPC [1166:0234] +-03.0 Broadcom BCM5785 [HT1000] USB [1166:0223] +-03.1 Broadcom BCM5785 [HT1000] USB [1166:0223] +-03.2 Broadcom BCM5785 [HT1000] USB [1166:0223] +-04.0 XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7 [18ca:0020] +-06.0-[:03-08]00.0-[:04-08]--+-01.0-[:05]-- | +-02.0-[:06]-- | +-03.0-[:07]-- | \-04.0-[:08]-- +-07.0-[:09]-- +-08.0-[:0a]-- +-09.0-[:0b]-- +-0a.0-[:0c]--+-00.0 Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] | \-00.1 Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] +-18.0 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-18.1 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-18.2 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-18.3 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] +-18.4 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204] +-19.0 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-19.1 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-19.2 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-19.3 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] \-19.4 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204] -[:00]-+-01.0-[:01-02]--+-0d.0-[:02]-- |+-0e.0 Broadcom BCM5785 [HT1000] SATA (PATA/IDE Mode) [1166:024b] |\-0e.1 Broadcom BCM5785 [HT1000] SATA (PATA/IDE Mode) [1166:024b] +-02.0 Broadcom BCM5785 [HT1000] Legacy South Bridge [1166:0205] +-02.1 Broadcom BCM5785 [HT1000] IDE [1166:0214] +-02.2 Broadcom BCM5785 [HT1000] LPC [1166:0234] +-03.0 Broadcom BCM5785 [HT1000] USB [1166:0223] +-03.1 Broadcom BCM5785 [HT1000] USB [1166:0223] +-03.2 Broadcom BCM5785 [HT1000] USB [1166:0223] +-04.0 XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7 [18ca:0020] +-06.0-[:03-08]00.0-[:04-08]--+-01.0-[:05]-- | +-02.0-[:06]-- | +-03.0-[:07]-- | \-04.0-[:08]-- +-07.0-[:09]-- +-08.0-[:0a]-- +-09.0-[:0b]-- +-0a.0-[:0c]--+-00.0 Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] | \-00.1 Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] +-18.0 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-18.1 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-18.2 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-18.3 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] +-18.4 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204] +-19.0 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Re: [coreboot] K8 HT architecture
On Fri, Oct 24, 2008 at 8:24 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: AGESA has a default discovery method (I think breadth first, lowest link number first) but it has options to over-ride the discovery mechanism to change the order of nodes in a system. All that matters is that the routing tables are correct and consistent for the traffic to get where it needs to and without deadlock. Getting the routing tables right is non-trivial for MP setups, especially if we don't know how the hardware is wired. My hope was to be able to express the cHT topologies in a way which allows us to derive correct routing tables. I'm postponing that goal for now. Yeah, that is a very complex thing to do. Just spewing values into the routing table registers is a reasonable way to go, especially at first. Once that is complete, the processors just show up in PCI as devices 18-1f (or fewer) They show up on bus 0 as you wrote. Will/can any devices attached via ncHT also show up on bus 0? If we have multiple ncHT links, what decides about the bus numbers for each of them? Yes, they can sometimes, and it is sort of a special case. If you look in my lspci dump, you will see lots of southbridge devices on bus 0. If you added another ncHT device, e.g. another HT1000, that southbridge would have to have its bus number shifted so devices would not conflict. You could put it at 1, 6, 20, etc. Other nc devices are the same, we have the ability to add up to 3 ncHT FPGAs to our system, and when we do so, they appear on busses 20, 21, and 22 (we picked those and set them in our BIOS). I think I have seen coreboot code using 40, 80, c0, etc. The NC devices I have seen all have registers to program their PCI bus number. You might want to look at the HT spec's information about bus numbering. It describes the reasoning about SB stuff living on bus 0. If we add or remove processors, nothing beside the 18-1f devices will change (SB Bus numbers, device numbers, etc do not change). When we add another *non* coherent HT device attached to one of the Opterons, it gets a new bus number (we start at 20 with ours, but it is arbitrary). All of the routing associated with HT for both coherent and non-coherent is contained in the mapping registers and routing table registers in all of the Opterons. The mapping registers map mem/io/cfg regions to nodes, and the routing table says how to get to that node. The ncHT devices can have BARs, and take up memory mapped IO just the same as another PCI device. If I understand you correctly, it would be easy to have 00:01.0-00:0a.0 appear as 01:01.0-01:0a.0 (bus 1) while still keeping the 18-1f devices on the hardcoded bus 0. As long as the nc device lets you change the bus number that it sits on (and it should, though I have only looked at a couple). You might want to see how these ever-confusing options are used in v2: HT_CHAIN_UNITID_BASE, HT_CHAIN_END_UNITID_BASE, SB_HT_CHAIN_ON_BUS0, SB_HT_CHAIN_UNITID_OFFSET_ONLY. I am a little bit confused by this. What are the exact differences you see between coreboot and factory? The number of Opterons should be that same. The position in config space of a particular socket may change, based on node discovery differences between the BIOSes. Their is no reason for other devices to move because of the HT changes, but they may move just by other differences in coreboot. IIRC I saw a board which only had 18-1f on bus 0 and everything else on other buses. AFAICS having devices on the same bus as the processor devices or not is a topology difference. Hopefully it is clear now how things can move like that. The Opterons won't move. It is possible with HT that other devices may exist on higher bus numbers without a bridge (real or fake) from bus 0. It is weird, and non-legacy compatible, so it should not happen with NB and SB devices. There are exceptions, though, when we connect our nc FPGAs, and put them at bus 20, we have no bridge in config space connecting them to bus 0. By default, the linux kernel will not find them (it does a normal PCI scan, looking for bridges, subordinates, etc). We must advertise the non-contiguous PCI busses in an ACPI table for Linux and Windows to see the higher busses that are not bridged to bus 0. (there are some other ways to force the linux kernel to find the devices, but the ACPI method works for all the current OSes we've tried). The point is that making the PCI busses discontiguous is weird, and makes you jump through other hoops to play well with OSes. Would you mind posting lspci -tvnn for that 5-processor board as well? It would help me a lot to understand this issue better. Yep, when I am at the machine again, I'll send it. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HT revision 1.02 in K8
On Fri, Oct 24, 2008 at 11:13 AM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Note the warning about Possibly incomplete decoding which stems from the fact that the processor mentions HT revision 1.02 which is the last non-public revision. Every revision from 1.03 and beyond seems to be publically available. Now the big question is: Can we decode HT 1.02 like HT 1.03 or have there been fundamental changes in between? I'd like to create a patch for PCIutils (lspci) so we can have full info without a warning message. I think the only people who can really answer that are inside AMD. My company is NDAed with AMD, and also a HyperTransport Consortium member, but I have only ever seen the 1.03 spec and later. I also have not found a changelog from 1.02 to 1.03. Maybe Jordan and/or Marc might be able to help. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] K8 HT architecture
The HT topology is not really directly reflected in PCI config space. They are obviously linked, but there is not really a way to map a HT topology of Opteron nodes to a graphical view of config space, it just doesn't exist. The Opterons just are where they are. All of the processor PCI devices are on Bus 0, and will always be on Bus 0. Devices 18-1f are the only ones that will ever exist for Opterons. The device number that each Opteron responds to is based on NodeID (0-7), which is set on each Opteron during discovery. There won't ever be holes, the NodeIDs must always be contiguous. Node IDs are not set in stone based on topology, node 0 is always the BSP, but 1-7 can basically be distributed out any of the 3 links to any other CPUs in any manner. AGESA has a default discovery method (I think breadth first, lowest link number first) but it has options to over-ride the discovery mechanism to change the order of nodes in a system. All that matters is that the routing tables are correct and consistent for the traffic to get where it needs to and without deadlock. Once that is complete, the processors just show up in PCI as devices 18-1f (or fewer) Here is an lpsci from one of our systems with 5 nodes (AMI BIOS with AGESA): 00:01.0 PCI bridge: Broadcom BCM5785 [HT1000] PCI/PCI-X Bridge 00:02.0 Host bridge: Broadcom BCM5785 [HT1000] Legacy South Bridge 00:02.1 IDE interface: Broadcom BCM5785 [HT1000] IDE 00:02.2 ISA bridge: Broadcom BCM5785 [HT1000] LPC 00:03.0 USB Controller: Broadcom BCM5785 [HT1000] USB (rev 01) 00:03.1 USB Controller: Broadcom BCM5785 [HT1000] USB (rev 01) 00:03.2 USB Controller: Broadcom BCM5785 [HT1000] USB (rev 01) 00:04.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7 00:06.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2) 00:07.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2) 00:08.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2) 00:09.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2) 00:0a.0 PCI bridge: Broadcom HT2100 PCI-Express Bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:1a.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:1a.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:1a.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:1a.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:1b.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:1b.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:1b.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:1b.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:1c.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:1c.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:1c.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:1c.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:0d.0 PCI bridge: Broadcom BCM5785 [HT1000] PCI/PCI-X Bridge (rev c0) 01:0e.0 IDE interface: Broadcom BCM5785 [HT1000] SATA (PATA/IDE Mode) 01:0e.1 IDE interface: Broadcom BCM5785 [HT1000] SATA (PATA/IDE Mode) 03:00.0 PCI bridge: PLX Technology, Inc. Unknown device 8518 (rev aa) 04:01.0 PCI bridge: PLX Technology, Inc. Unknown device 8518 (rev aa) 04:02.0 PCI bridge: PLX Technology, Inc. Unknown device 8518 (rev aa) 04:03.0 PCI bridge: PLX Technology, Inc. Unknown device 8518 (rev aa) 04:04.0 PCI bridge: PLX Technology, Inc. Unknown device 8518 (rev aa) 0c:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) If we add or remove processors, nothing beside the 18-1f devices will change (SB Bus numbers, device numbers, etc do not change). When we add another *non* coherent HT device attached to one of the Opterons, it gets a new bus number (we start at 20 with ours, but it is
Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson [EMAIL PROTECTED] wrote: C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a : FF Yep, b102 is not a common signature. I'm looking for the place where the interrupt vector was supposed to have been set. I am confused, your coreboot log shows several int1a before the failure: int1a vector at 10ffef dev_find_device: find PCI: 1022:2067 ... int1a vector at 37da2 int1a vector at 37da2 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS debug output
On Thu, Jul 17, 2008 at 12:40 PM, Myles Watson [EMAIL PROTECTED] wrote: Here are the two logs for the Windows XP install CD. I'm wondering if we should make SeaBIOS pretend to be an older BIOS and see what happens. It seems like there was some structure that is returned on a BIOS call that tells what version it is. I used to be able to make it through the install process with ADLO (just rombios.c, not rombios32.c), so maybe something in the PCI code is messing me up. I don't know what else to try. Hopefully you can spot something in the logs. Could you try what Kevin did, and install XP on your factory BIOS (ideally with ACPI disabled) and then try and boot that image with SeaBIOS? From going through a few x86 cpu and chipset turn-ons, I know that in general, debugging OS boot of a full installation is usually much easier than trying to debug the installation process of an OS. There are less obstacles to booting an already-installed image, and there are much more tools available for debugging the aleady-installed OS. Once you get that working, you can go back to debugging the CD. It would be interesting to see if your platform has the same sort of success that Kevin got on the epia. Maybe your different graphics controller will work even better. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] superiotool: add dump support for Winbond (NSC) PC87427
Here is a dump for the wiki: superiotool r3361 Found NSC PC87427 (sid=0xf2, srid=0x04) at 0x2e Register dump: idx 10 12 13 1d 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val 00 00 00 00 f2 19 a0 40 20 00 02 04 00 14 00 04 12 00 00 00 def 00 00 00 00 f2 11 a0 MM MM MM 02 NA 00 MM 00 00 MM MM RR RR LDN 0x00 (Floppy) idx 30 60 61 70 71 74 75 f0 f1 val 00 03 f0 06 03 02 04 24 00 def 00 03 f2 06 03 02 04 24 00 LDN 0x02 (COM2) idx 30 60 61 70 71 74 75 f0 val 00 00 00 00 03 04 04 02 def 00 02 f8 03 03 04 04 02 LDN 0x03 (COM1) idx 30 60 61 70 71 74 75 f0 val 01 03 f8 04 03 04 04 02 def 00 03 f8 04 03 04 04 02 LDN 0x04 (System wake-up control (SWC)) idx 30 60 61 62 63 64 65 66 67 70 71 74 75 val 01 0a 20 0a 00 0a 04 0a 10 00 03 04 04 def 00 00 00 00 00 00 00 00 00 00 03 04 04 LDN 0x05 (Mouse) idx 30 70 71 74 75 val 01 0c 02 04 04 def 00 0c 02 04 04 LDN 0x06 (Keyboard) idx 30 60 61 62 63 70 71 74 75 f0 val 01 00 60 00 64 01 02 04 04 40 def 00 00 60 00 64 01 02 04 04 40 LDN 0x07 (GPIO) idx 30 50 60 61 70 71 74 75 f0 f1 f2 f3 f4 f5 f6 f7 f8 val 01 00 0a 40 00 03 04 04 35 00 00 00 00 00 00 00 00 def 00 00 00 00 00 03 04 04 00 MM 01 00 00 00 00 00 00 LDN 0x09 (Fan Monitor and Control (FMC)) idx 30 50 60 61 70 71 74 75 f0 f1 val 01 00 0a a0 00 03 04 04 19 06 def 00 00 00 00 00 03 04 04 19 06 LDN 0x0a (Watchdog timer (WDT)) idx 30 50 60 61 70 71 74 75 f0 val 01 00 0a 80 00 03 04 04 00 def 00 00 00 00 00 03 04 04 00 LDN 0x0f (X-Bus) idx 30 60 61 70 71 74 75 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff val 00 0a 60 00 00 04 04 10 00 00 00 00 00 00 00 02 00 00 00 00 00 80 10 def 00 00 00 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 10 LDN 0x10 (Real-time clock (RTC)) idx 30 60 61 62 63 70 71 74 75 f0 f1 f2 f3 f6 f7 val 01 00 70 00 72 08 00 04 04 00 7d 7e 32 80 03 def 00 00 70 00 72 08 00 04 04 00 00 00 00 MM 00 LDN 0x14 (Health Monitoring and Control (HMC)) idx 30 50 60 61 62 63 70 71 74 75 f0 val 01 00 0a c0 0a e0 00 03 04 04 04 def 00 00 00 00 00 00 00 03 04 04 05 -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: grow grafix memory, and fix PLL on dbe62
On Wed, Jul 9, 2008 at 12:05 PM, ron minnich [EMAIL PROTECTED] wrote: This does not fix the problem with the memory errors. We've still got something wrong in memory, and it is not clear what. Does DBE62 have an unterminated memory interface? Can you compare MSR 0x4c0f from coreboot to a working BIOS? Unterminated platforms are supposed to have a special value (0xF2F100FF 0x56960004) for that register, which is in a comment in geodelx.c, but I don't see that value in any table. (maybe I am missing it, but the special value should be set for DB800, too) -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB debug cables and emulation
On Thu, Jul 3, 2008 at 8:45 AM, Joseph Smith [EMAIL PROTECTED] wrote: Well it looks like in the pdf presentation above they have a Serial-USB debugger. It looks like a development board though because there are a bunch of unnecessary stuff on it. I'm thinking a Serial-USB debugger is the way to go to keep the costs down, and it gives the terminal PC (serial end) more flexability. If one wanted to have it USB on both ends they could always use a USB-Serial adapter for the terminal PC (serial end). Also, this way there would be no need for any kind of a special driver for windows/linux, it would just show up as a serial communications device. Any suggestions, questions, comments? I think I am still a bit confused about your goal. A Net20DC is ~$90 right now. You aren't going to be able to take some off-the-shelf USB-Serial adapter and make it into a debug device. Those adapters use fixed-function USB-Serial ICs that are cheap and small. You can't re-program the firmware to make them into debug devices. If you buy a development kit with an appropriate IC and allows you to develop the firmware, you will easily be at $90 or above. To make a replacement, you need: Net2272 (or equivalent, Cypress, etc) ~$10 host side interface chip ~$5 ($5 for serial, USB would be ~10 instead) Connectors, SEEP, passives, etc $10 PCB $20 So, $50 *cost* (and the above numbers are very best-case). Then you need to assemble and test your board, develop the firmware for the USB debug Device, and possibly the firmware for the host-side interface. (Please don't try and argue less than $20 for a PCB, for your quantities, that is what it will be) Even if you consider all of your time free, you still are comparing $50 to $90. If you could sell a USB debug cable for $20, it would make sense. If the Net20DC was $200, it would make sense. Otherwise, I am not so sure. Am I missing something? -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB debug cables and emulation
Others have pretty much replied with what I was trying to point out, but here are a couple more comments: On Thu, Jul 3, 2008 at 12:28 PM, Joseph Smith [EMAIL PROTECTED] wrote: I guess you don't get it. I am not doing it to mass produce and sell at a lower cost. I don't really care about any kind of profit. I'm simply doing it for a HOWTO build your own USB 2.0 Debugger For Around 20 Dollars. $20 Dollars for a PCB??? I am going to use a generic PCB you can pick up at radio shack for 2 dollars. If I have to get some of the components at a larger volume to get a cheaper price and re-sell them to interested parties so they get a cheaper price I will. This is more for educational, learning, and teaching purposes. Everything is not about money you know (or not) :-( I am not at all talking about greed, I am talking about practicality. You said you want to create instructions to build a $20 USB debug cable. I am saying that I don't think that is possible, and at *best*, you will be closer to the $50 number in the end. I am just hoping you realize that before you spend a lot of time and effort on it. What sort of volume discounts are you expecting? The number I said for the 2272 *was* for high quantity. I see 1 for $11, 100 for $9.73, and 500 for $9.45. Still pretty high. If there are other USB device ICs of the *same caliber* that are much cheaper, I would be very interested to know about them. If your goal is to learn USB, great, you'll learn a lot from doing something like that. Just expect that the kits or instructions you may offer in the end will get pretty close to the price of the Net20DC (at least in the US). Maybe you could create a cheaper solution for people outside the US, but expect that you will need to spin a PCB, and supply them to whoever might want to do it. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memory clock cycles - microseconds (us)
Busy wait is a loop of some number of NOP instructions, as opposed to relying on some CPU peripheral such as a timer to signal elapsed time. The number of NOP instructions has to be calculated from the current CPU frequency. That seems more complicated than it needs to be. Here is what I am thinking: JEDEC specifies what the wait/delay is supposed to be between memory initialization steps. They specify/measure these in memory clock cycles. Currently we just guess, and round up in microseconds (us) (I guess it is better to wait too long than not enough). But, even if we wait 1/2 a microsecond or more than needed on each step, That's 3 or 4 microseconds longer than needed. See where I am going with this? It really can't be less complicated, but a lot of the work is already done. Take a look at delay_tsc.c, which uses the tsc for delays (which is a little bit nicer than counting NOPs) It does the tsc calibration vs. the PIT (or even vs. port 80s) to get the CPU frequency. delay_tsc has udelay now, but could reasonably easily have ndelay too. Precision in the 10s of ns should be possible. Peter's point is that it probably does not matter too much. Even if you rounded up 5 individual delays to 1 usec each, that is only 5us. You can reclaim a lot of it, but it may be more work than it is worth. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dump GPIO I/O Registers
The dump tool is the way to go now, but just to answer a couple of your questions: [EMAIL PROTECTED] wrote: OK, so lets clarify? GPIOBASE?GPIO Base Address (LPC I/F?D31:F0) 31:16 Reserved 15:6 Base Address ? R/W. Provides the 64 bytes of I/O space for GPIO. 5:1 Reserved 0 Resource Indicator ? RO. Hardwired to 1; indicates I/O space. 1. My value is 0x0501. So if only bits 15:6 are the base address this would make my base address 0x14 correct? This value would become 0xbasehere? Bits 15:6 of that register become bits 15:6 of the address range, meaning your base is just 0x500. (that isn't really stated in the datasheet, but that is they way those type of registers usually work, see regular PCI BARs for another example) Also, 0x14 would just not be an appropriate I/O base, take a look at an I/O port reference (i.e., ports.lst from Ralf Brown), and you will see that 14 is in the legacy DMA controller's I/O space. Anything less than 0x100 is really only for legacy stuff. 2. Would I put 64 in asmanyasyouwant to dump the whole 64 bytes of I/O space? Yes 3. What is the pipe xxd for? When you use dd to read from /dev/port, you get out raw binary data. xxd turns that binary into a human-readable hex listing. (there are other tools to do this too, hexdump, etc) -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dump GPIO I/O Registers
If you want to look at the GPIOs, from the 82801DB datasheet, it looks like you should look at: 9.1.14 GPIOBASE—GPIO Base Address (LPC I/F—D31:F0) and 9.1.15 GPIO_CNTL—GPIO Control (LPC I/F—D31:F0) (offsets 58 and 5c in D31:f0, lspci -xxx as root is one way to dump) What value is in those registers? Check to see if an address is assigned, and if the decode is enabled. If so, you have something to dump. That register is not a real PCI BAR, so it may not show up in /proc/ioports Once you have the base address, you can read the GPIO control registers from /dev/port, with the seek equal to the base address. It looks like the register set is described in: 9.10 General Purpose I/O Registers (D31:F0) and Table 9-12 in the 82801DB datasheet. On Feb 18, 2008 8:15 AM, [EMAIL PROTECTED] wrote: Quoting Carl-Daniel Hailfinger [EMAIL PROTECTED]: On 18.02.2008 02:45, [EMAIL PROTECTED] wrote: Quoting Carl-Daniel Hailfinger [EMAIL PROTECTED]: On 16.02.2008 17:57, [EMAIL PROTECTED] wrote: Hello, How do I dump the GPIO I/O Registers in linux. I need to dump the GPIO's from the southbridge. Anyone? Depends on the southbridge. It could be directly/indirectly memory-mapped or port-based. Simply tell us what the data sheet says about reading the GPIO state and we can help. The southbridge is the Intel 82801DB ICH4. I don't see anything in the datasheet about reading the GPIO statejust says: The control for the general purpose I/O signals is handled through a separate 64-byte I/O space. I can find out the base offset address from the LPC pci configuration registers, but how do I dump it into human readable form?? Is this a memory address or I/O port number? Once you know that, you can modify existing utilities for your purpose. If you have no idea, tell us the values and we can guess. Having /proc/ioports and /proc/iomem contents would help guessing. Here is /proc/ioports: -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 0376-0376 : ide1 03c0-03df : vga+ 03f8-03ff : serial 0400-047f : :00:1f.0 0400-0403 : ACPI PM1a_EVT_BLK 0404-0405 : ACPI PM1a_CNT_BLK 0408-040b : ACPI PM_TMR 0410-0415 : ACPI CPU throttle 0420-0420 : ACPI PM2_CNT_BLK 0428-042f : ACPI GPE0_BLK 0460-047f : iTCO_wdt 0500-053f : :00:1f.0 0a00-0a3f : pnp 00:0b 0cf8-0cff : PCI conf1 c000-cfff : PCI Bus #01 cc00-cc3f : :01:08.0 cc00-cc3f : e100 d800-d81f : :00:1d.0 d800-d81f : uhci_hcd d880-d89f : :00:1d.1 d880-d89f : uhci_hcd dc00-dc1f : :00:1d.2 dc00-dc1f : uhci_hcd e000-e01f : :00:1f.3 e000-e01f : i801_smbus e080-e0bf : :00:1f.5 e080-e0bf : Intel 82801DB-ICH4 e400-e4ff : :00:1f.5 e400-e4ff : Intel 82801DB-ICH4 e800-e8ff : :00:1f.6 ec00-ec7f : :00:1f.6 ffa0-ffaf : :00:1f.1 ffa0-ffa7 : ide0 ffa8-ffaf : ide1 Here is /proc/iomem: -0009fbff : System RAM - : Crash kernel 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-077c : System RAM 0040-006200ec : Kernel code 006200ed-00736543 : Kernel data 077d-077defff : ACPI Tables 077df000-077f : ACPI Non-volatile Storage 1000-13ff : :00:1f.1 e800-efff : :00:02.1 f000-f7ff : :00:02.0 ff70-ff7f : PCI Bus #01 ff7ff000-ff7f : :01:08.0 ff7ff000-ff7f : e100 ff98-ff9f : :00:02.1 ffa7f400-ffa7f7ff : :00:1d.7 ffa7f400-ffa7f7ff : ehci_hcd ffa7f800-ffa7f8ff : :00:1f.5 ffa7f800-ffa7f8ff : Intel 82801DB-ICH4 ffa7fc00-ffa7fdff : :00:1f.5 ffa7fc00-ffa7fdff : Intel 82801DB-ICH4 ffa8-ffaf : :00:02.0 ffc0-fff7 : pnp 00:08 According to the original bios I think the 64 bytes of I/O space for GPIO is 0x14. Does that make sense??? Thanks - Joe -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3: dts and arrays
ron minnich wrote: On Thu, Feb 14, 2008 at 2:32 PM, Carl-Daniel Hailfinger Indeed. That would solve the problem very nicely without putting hacks into the dts. OK, so we put nodes under the 5536, and specify 'disabled', and the 5536 code knows to actually call VSA when it sees that they are disabled. This is nice. It would use the device tree in a sensible way. Hm, hold on. I think there is a little bit of confusion with the word disabled here. For a Geode VPCI device, disabling it means completely hiding the header from config space. If you disable it with VPCI, and try to do config cycles to that device, VSA will respond as if it does not exist. (returning all 1's) That behavior continues forever, unless you enable the device again using VSA. (you wouldn't ever do that, in general) What does disabled mean for a real hardware device in the dts? I am pretty sure it does not mean hide the header (that is not possible in general, it is a VSA-ism). What if I want the VPCI device to exist, but want it disabled in the normal dts sense of disable? Overloading disabled in the dts makes that not possible (and is also *really* confusing) Maybe a better idea would be to just change: /* Disable unwanted virtualized PCI devices */ to /* Hide headers for unwanted virtualized PCI devices */ since the original words seem to have lead to this confusion. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Geode LX/CS5536 VSA
On Feb 8, 2008 3:05 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Within the tarball there is a file modification_notes.txt that highlights what I have done. I'm hoping to foster some discussion on a testing approach that lays somewhere between manual inspection and slapping the open-tools blob into a coreboot ROM and crossing our fingers... I fear that for most of us the only way to test is to burn the generated VSA into a ROM and start the machine. However, I have to admit I didn't read the modification notes you supplied. I will read it. Maybe AMD has some sort of test battery that they run against the old VSA, that someone could do on this one. :) -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] memtest running on alix1c!
It has confusion: L1 Cache: Unknown | Test #6 [Moving inversions, 32 bit pattern] L2 Cache: Unknown | Testing: 120K - 256M 255M See if you can make sure this is not another memtest bug. For a long time, memtest did not know that Geode LX CPUID meant to read the cache information like an AMD processor. I think the issue was fixed in more recent memtest versions. If memtest is ok, make sure the cache information MSRs for CPUID are being programmed correctly. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Run PCI rom before PCI bus scan??
[EMAIL PROTECTED] wrote: Here is what I think the PCI rom does with the original bios: 1. powers on and enables device 2. sets up PHY registers 3. sets up it PCI config registers 4. and requests use of the PCI bridge If I could figure out how to do #1 the rest would be fairly simple to setup,although I am not exactly sure about PHY registers. Then I wouldn't need the pci rom at all. I'm not sure it really works this way. A normal platform has some mechanism to set the default values for the LAN config registers. It can be a dedicated SPI ROM, or a dedicated chunk of your boot ROM, or you could program them in your BIOS. I would guess that a PCI ROM is expecting all of those registers to have been programmed already. Furthermore, many of those settings are *platform specific*, so they would not be in any sort of generic PCI ROM that you would get from Intel, or generate using their tools. I recently designed a platform with an 82571 Intel LOM, and I programmed proper values in the SPI, and don't load any PCI ROM at all. It works fine in all OSes. The PCI ROM usually just provides things like PXE or manageability stuff. You need to figure out how your platform is handling this. I think it is unlikely that the PCI expansion ROM is doing what you think it is. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
Looking at one of your old logs, it looks like the VSA init code is *running* in the 0x1000 segment: http://www.coreboot.org/pipermail/coreboot/2008-January/029736.html (cs 0x1000) That is probably smashing the region. The int18s are certainly bad, you should just have the normal two int15s, with cs 0x6000. How do I get vsa into coreboot v3? I built an alix image, and I am able to boot it on a different lx platform, but it does not find vsa, since I didn't build it in. I'll look at the VSA load with FS2 if someone tells me how. On Jan 28, 2008 7:07 PM, ron minnich [EMAIL PROTECTED] wrote: On Jan 28, 2008 3:58 PM, Marc Jones [EMAIL PROTECTED] wrote: I don't think so. It is coreboot that sets the stack for VSA initialization. The more I think about it, the stack shouldn't be moved. Just switch to real mode and VSA can use the same stack as LinuxBIOS (maybe pad it a little if you are worried about alignment). This is how it works in a standard BIOS. Stack is at 8ffxx, which is way out of 64k area ... I am lazy and set %es to 0. It's really much easier to leave it on page 0 :-) It is in the VSA memory area. It is setup by VSA during init. Ron, can you provide us with logs of the last revision before VSA support went in and of your current local codebase? I hope to pinpoint the location of the explosion better. I should be building shortly and be able to find what is blowing up. Thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
Marc Jones wrote: Tom is right, something funny is going on here. We see the VSA decompressed to buf 0x0006 which is a good place for VSA. Then we don't see an error that VSA isn't found. That means that it found the first post code as expected. Yep, I checked with FS2, things look pretty good until it gets into biosint. At the call to biosint, the v2 and v3 stack look the same, and esp is in the right spot. The code for biosint is very different for v2 vs v3, however. something inside of biosint is what is screwing up. The printk's were to annoying to trace through, so I stopped there. The only thing I noticed different in the source was that v3 biosint is declared static. If I remove the static, it won't compile. All of this pain is to basically get some speed and memory size parameters into VSA. Maybe it would be best to just wait for Marc's new int15-less VSA and save that pain. It probably isn't an issue that will be uncovered later, since it can all just be ripped out. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
ron minnich wrote: here's an interesting bug in /home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c /* Dump zeros in the other segment registers */ mov %ax, %es\n mov %ax, %fs\n mov %ax, %gs\n mov $0x40, %ax \n--WHAT? mov %ax, %ds\n mov %cx, %ax\n Why did somebody move 0x40 to the ds? That's not even a valid gdt selector? Anybody know why this was done? That is probably normal. These are real mode selectors (segment registers), and that code is calling a VGA ROM. 0x40:xx is the BDA. I think that is one of the expectations of a VGA ROM is that it is called with the BDA pointed to be ds. cx has the device/function of the card being called. Your generic case won't want that stuff (and it doesn't have it now) -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] pci_check_sanity is confusing; do we need VSA to read LX CS5536 config registers? ; how to handle VSA?
ron minnich wrote: I thought that even without VSA, a pci config read of 0:1.0 would give me something reasonable back. But the devices that are found without VSA are 0:c.0, 0:d.0, and then 0:f.0 etc. Without VSA, the only thing you are going to see south of LX are the real hardware PCI devices (probably your c.0 and d.0) and then one device in 5536, 0:F:0, which is the one real hardware header on 5536. Please post the vendor/device IDs, and we can see what you are finding. For 5536, you should find 208F1022 for that one hardware header. That device is the ISA bridge, and doesn't do anything. Like Marc said, you need VSA to access PCI config space for IDE, audio, USB, etc. Everything is a virtual device on 5536. Of course, you can access MSRs on those devices before VSA is loaded. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
