[coreboot] FOSDEM Hardware Enablement Devroom: call for speakers.
Hi, At FOSDEM on sunday the 2nd of february 2020, there will be another hardware enablement DevRoom. URL: https://fosdem.org/2020/ This devroom covers topics related to hardware support and enablement with free software. It includes the following topics: * peripheral/controller firmwares * hw support and drivers in bootloaders * kernel drivers and hardware interfaces * hardware-related adaptation in operating systems * tools for firmware flashing * tools for low-level development FOSDEM is very much an open source community event, please refrain from turning in a talk that is meant to be purely corporate or a product commercial. Also, this is a highly technical devroom on a conference aimed at developers and advanced users, so only submit a talk on a subject you actually are involved with. Finally, this devrooms focus is the technical aspects of the hardware and its enablement in free projects, rather than the specific applications and use cases that benefit from it. With the return of the Embedded and Automotive DevRoom, we have the ability to schedule full hour talks again, and to go in-depth. If you however only need half an hour, then this is of course also possible. Talk Submission: The venerable pentabarf system will once again be used for talk submission. https://penta.fosdem.org/submission/FOSDEM20 When in pentabarf, spend some time on the abstract and description, for both the event and the speaker. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. As soon as your talk is scheduled by the devroom managers, you can see the result of your handiwork on the main website. Please re-use your old pentabarf account instead of creating a new one: lost password: https://penta.fosdem.org/user/forgot_password Talks are either 50 minutes or 20 minutes long, plus 5 minutes for questions. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY, sometimes minutes after your talk has finished. As for deadlines, the fosdem organizers want to have a finished schedule by the 15th of december, but do not count on that deadline, there are only a limited number of slots available. Given my belatedness in sending out this CFP, i might get a few more days if i am really really nice to the core FOSDEM organizers, but again, do not count on that (extra hugs only go so far when you're built like i am). On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Hardware Enablement Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Schedule: * select your preferred talk length, either 55 or 25 minutes. * Links: * Add relevant links. The mobile phone number is the hardest requirement, so you can be contacted on-the-day when something comes up. Speakers will all receive my mobile number in return. Neither email nor phonenumber are publicy visible, nor will this information be used for anything outside of devroom organization. After your talk has been scheduled, i usually only send out a single email with some organizational details in the days before the event. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email (hardware-devroom-mana...@fosdem.org). That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] Matrix instead (or additionally to) IRC
On Sun, Oct 28, 2018 at 03:10:11PM +0100, Philipp Stanner wrote: > Hey, > > have you guys already heard of Matrix? > https://matrix.org/blog/home/ > > It's some sort of modern IRC, using JSON to format messages. It's more > modern than IRC. Features are: > * Source code formatting and highlighting in messages > * multiple devices > * history + history synchronization between multiple devices > * possible E2C encryption > > and many more. > In theory it will be a decentralized protocol, but there aren't that > many servers yet and actually only one working server-software > > Many projects, especially tech-based ones like the Rust programming > language already use the service. > > Personally I think it's an enormous progress to IRC. I would give it a > chance if I were you :) > > P. Ooh, bait, on a sunday afternoon with nothing better to do. I'll bite. Matrix is not even 4 years old. IRC has been good around for just over 3 decades. Many here have been using it for more than 2 already. Yes, 2 decades. 20 years. Chat/IM protocols come and go, IRC remains. After this, someone will come along to suggest that we should all switch to whatsapp. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD doesn't get it either in some ways
On Sat, Apr 05, 2014 at 03:20:08PM +0200, Rudolf Marek wrote: > Hi all, > > I think there is OpenRadeonBios. The problem is that thhe AtomBIOS > bytecode is vendor specific blob, which cannot be in principle released > by AMD because it is written by board manufacturers for specific wireup > of graphical output. This is what I have learnt when I was interested in > that way more. Iirc, this does not replace atombios in any way, just replaces the bits around atombios. > Ron, if you create dummy atombios bios whithout an x86 code the radeon > driver in kernel should be able to post it. It even works now. If you > include the orginal rom in the cbfs but don't run it, the kernel driver > is able to modeset it and "post" it. I think David Hubbard was > interested in the replacement BIOS as well.. Atombios has bytecode which is run through an interpreter. There is no x86 code in there. All the ASIC and board specific bits should be in the function and data tables of atombios... But that might have changed already... Initially (for the R500), the promise was that all board specific bits would live in the datatables, and would not protrude into the function tables. but that got thrown wildly but of the window with rv610/630. Of course, not all things can ever be hidden away completely by atombios, and we had to do hard stuff ourselves still. Plus, the fglrx/windows driver worked around bugs in both the hw _and_ atombios. So who knows to what extent that rot has spread in the past 5 years, and to what extent the ATI VGA bios code works around atombios today? For all i know, ATI still doesn't allow people to flash their bioses. Iirc, Biostar gave some of their users the tool to do so back in late 2007, and ATI was not exactly happy. So fixing shipped hardware can only be done through fglrx/windows driver. Did you know that read access to the bios was disabled from within the original ASIC_Init atombios function? Egbert Eich had to go and bisect the atombios bytecode to pinpoint what did that, as of course ATI couldn't or wouldn't tell us. Why was that important? Well, suppose you would restart your X server... > I think still that graphics modesetting is only minor problem. I feel > very disturbed about AMD plans considering to go same way as Intel. I > always liked AMD for opening their systems as much as possible. There was > always my goal to have some x86 blob free at least for the x86 CPU code. > This worked fine with VIA K8M890 where in VGA bios could be replaced by > QEMU bios ;) Now we are drifting slowly away from any truly open x86 > system. Ah, the long dead and now utterly irrelevant unichrome. It spawned a great many things. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Re : Re: AMD doesn't get it either in some ways?(the?bastards!!!)
On Sat, Apr 05, 2014 at 10:41:18AM +0200, eche...@free.fr wrote: > > Naive question : Is it too late to find a remedy to that? Why? This was mid 2007 til early 2009. Have you seen any ATI documentation since then? Have you seen anyone trying to write proper C display code for radeon hw since then? Have you seen anyone pry apart atombios code since then? You're a bit late to this party. > Can you elaborate further on this? I wasn't aware that Redhat has this > kind of attitude.. So you missed the whole ATI freeing story, and the RadeonHD vs Radeon mess that ensued? As for some details: A quick summary of the worst from the redhat side is: http://libv.livejournal.com/26434.html under the header "More shouting" Another quick summary of how the X.org community acted (in this case mostly the work of a single person) but with references this time is at: http://libv.livejournal.com/25325.html under the header "software fascism". While still in the middle of RadeonHD, and therefor still obliged to work with "the other side", i talk about atombios and the attempts of some ati employees to remarket its content as "Scripts": http://libv.livejournal.com/15571.html It is worth reading the comments as well there. I had seriously overstepped the line there, but looking back, i should've done this earlier and much much louder, as the other side knew no such boundaries (and then some). I never did write a full sequence of events publically. I did a terse one for SuSE internally in june 2008, as this was requested by the "executive oversight" we had at that point gotten. It was excruciating to write this as it ended up showing how we had been played by some ATI employees, over and over again. The executive oversight discreetly ended afterwards. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD doesn't get it either in some ways (the bastards!!!)
On Fri, Apr 04, 2014 at 12:38:07PM -0500, mrnuke wrote: > On Friday, April 04, 2014 10:00:41 AM ron minnich wrote: > > I have this nice board, with a nice AMD cpu, and I get no graphics. > > Why? Because AMD won't release the VGA blob. So the board is headless. > > > Are you talking about a board which originally came with IBV firmware? In > that > case, you may be able to extract the blob from linux while running on said > firmware. > > > Another addition to the blob matrix. sigh. > > > How can you add a blob that you don't have? And what CPU is that? Do you > think > we can get native VGA init running? (fork thread if you answer this second > question) If only we at the RadeonHD project had had our way... We were only a few hundred lines of C away from full hw init with our modesetting code. Basically, the board specific bits were not done by us, but that was reasonably limited, and i was hoping that someone would find the time and would port the first IGP or even discrete card, and open the floodgates... But that of course never happened. AMD lost further control of ATI and Redhat saw it necessary to join forces with ATI. The enemy of my enemy and such. And RadeonHD was declared to be the code from the MS devil, amongst many other baseless things... Now we get to keep both pieces, thank you redhat. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] haswell firmware graphics support
On Mon, Aug 05, 2013 at 08:29:07PM -0700, ron minnich wrote: > > We're finally breaking open the video bios situation; with luck, it > will soon be as open as ARM platforms ;-) To be brutally honest, this was done before (http://libv.livejournal.com/19432.html), as part of my, soon, 10y old struggle to get rid of the ludicrous dependency on video bioses (it seems ludicrous now, but i once was on my own with this view). But this was on (now) much less interesting hw, namely VIA chipsets. And if only AMD hadn't lost control over ATI, we would've easily had it with discrete ATI cards too 6 years ago (as we had reduced the BIOS dependency to only a few hundred lines of board specific bootstrap code). But good to see this work being done now on recent IGPs. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch merged into coreboot/master: e4fc528 Add the memory reference code binary for sandybridge chipsets
On Tue, Apr 17, 2012 at 03:04:38PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > That still has _you_ going around > > I went *around* nothing. I'm one of several who can ack and commit a > proposed commit, and including a commit takes exactly one submit and > one ack, as per our process since forever. > > Sorry if anyone feels that I stepped on their toes, but you can bet > that I will ack this commit over and over again. Then what is the point of review, discussion, heck even a mailing list or gerrit? > > the people who were discussing this patch and the outcome of that > > discussion. > > The discussion wasn't very useful, and was clearly going nowhere. > It's very similar to the quarter million line patch submitted for > another modern platform. There's very little that needs to be said. That's what you think. > Keep focus on the fact that coreboot now supports current platforms > from both AMD and Intel. > > > //Peter Then let's just rename coreboot to "Emperor Stuge's little empire", and be done with. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch merged into coreboot/master: e4fc528 Add the memory reference code binary for sandybridge chipsets
On Tue, Apr 17, 2012 at 02:07:48PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > > I still believe that we the coreboot community can create more > > > innovative init code, as we have done for a decade already, but > > > someone has to do it. So far I don't know of significant effort to > > > create Sandy Bridge/Ivy Bridge memory controller init, but if one > > > is underway then once it is done I would suggest using that by > > > default, and relegating the MRC to an expert Kconfig option. > > > > you just committed a binary blob to a free software project, a > > free software project that used to take pride in providing the > > functionality that that binary blob now provides. > > Please read what I wrote above. Focus obviously remains the same > for coreboot. > > A fact is that there is no commit in Gerrit for native memory > controller init for the particular hardware. > > When there is one, as I wrote, then I'll be the first to want to > replace the MRC binary. > > What the MRC does on a high level is well-known. The DDR3 JESD is > available to anyone and everyone. If Intel desperately wants to > hide some registers for now then I really could not care less. > > I do however care a lot about the fact that coreboot can be used on > Sandy Bridge and Ivy Bridge platforms now. > > > coreboot does, and should, take pride in the hardware init done with > native code, because the init gets done really well. This is > obviously still true for all parts of coreboot which run before and > after the MRC, where the resource allocator is no small part. > > I agree that coreboot memory init, especially with ECC, has merit, > but I don't think it's the pride of coreboot. > > As you know, the MRC binary is quite specific to the platform, so > it's not at all true that the MRC has taken over a function that > other code in coreboot was already doing, as you make it sound. > > I would really like to see native init code for the memory controller > so please push to Gerrit if you have it, even if it's only in an > early stage! > > > //Peter That still has _you_ going around the people who were discussing this patch and the outcome of that discussion. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch merged into coreboot/master: e4fc528 Add the memory reference code binary for sandybridge chipsets
On Mon, Apr 16, 2012 at 05:03:39PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > > the following patch was just integrated into master: > > > > > > Add the memory reference code binary for sandybridge chipsets > > > > > > Reviewed-By: Peter Stuge at Mon Apr 16 01:12:57 2012, > > > giving +2 > > > > ? > > For the first time in history, coreboot now supports the very latest > hardware platforms from both AMD and Intel! > > I think this is an incredibly exciting development, and adding the > MRC is an absolute no-brainer. > > Calling vendor reference code hooks for parts of the initialization > is not ideal, but it is a lot better than not supporting a platform > at all. For industry (which we want to reach) it may actually *be* > ideal, since they are already familiar with the way the reference > code works, so understanding coreboot becomes just a little bit > easier. > > I still believe that we the coreboot community can create more > innovative init code, as we have done for a decade already, but > someone has to do it. So far I don't know of significant effort to > create Sandy Bridge/Ivy Bridge memory controller init, but if one > is underway then once it is done I would suggest using that by > default, and relegating the MRC to an expert Kconfig option. > > I think Ron's effort on native Intel graphics init by refactoring KMS > drivers is a great idea to have more native init, and it could well > be *the* way we will finallyx get rid of the sucky VGA BIOS! > > I'm very thankful for the efforts David, Stefan, Ron, and the rest > of their team at Google have put into making coreboot a serious > alternative for the latest Intel hardware in the industry! > > You rock guys! > > > //Peter You just committed a patch that was under heavy discussion, completely ignoring this discussion, and you definitely ruined the outcome of that discussion. On top of that, you just committed a binary blob to a free software project, a free software project that used to take pride in providing the functionality that that binary blob now provides. You rock! Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch merged into coreboot/master: e4fc528 Add the memory reference code binary for sandybridge chipsets
On Mon, Apr 16, 2012 at 01:13:02AM +0200, ger...@coreboot.org wrote: > the following patch was just integrated into master: > commit e4fc5283d5c2e5fe8f75875a8229319696f8990b > Author: Ron Minnich > Date: Thu Apr 12 04:26:22 2012 -0700 > > Add the memory reference code binary for sandybridge chipsets > > This binary is required for anyone who wishes to build a > sandybridge mainboard. > > Change-Id: I779ef5e2b77166b81cb05eada37291368e74fbb6 > Signed-off-by: Ron Minnich > > Build-Tested: build bot (Jenkins) at Sat Apr 14 01:36:38 2012, giving +1 > Reviewed-By: Peter Stuge at Mon Apr 16 01:12:57 2012, giving > +2 > See http://review.coreboot.org/897 for details. > > -gerrit ? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New patch to review for coreboot: e4fc528 Add the memory reference code binary for sandybridge chipsets
On Sat, Apr 14, 2012 at 07:57:19PM -0700, ron minnich wrote: > On Sat, Apr 14, 2012 at 3:12 AM, Carl-Daniel Hailfinger > wrote: > > > I hope this is not going into the main repository, but into some > > separate repository instead. > > Right now we can tell people that all code in our official git > > repository is GPL-compatible, and I'd like to keep it that way. > > We maintain GPL V2 compatibility as this is a blob that is placed into > cbfs. There is no linking. > > I don't see it as different from what we do today with microcode, > which has been in the coreboot tree for many years now. While that > code is in "source" form in some sense, it really is a binary blob. We > would not have wanted to force people to maintain all that as as > separate repo. > > Hope that helps. I'd like to make sandybridge support as convenient as > possible. > > thanks > > ron Convenience... at what cost? What _other_ microcode are you shipping today? And here i thought that fully free memory controller setup is what made coreboot shine. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2V-MX problems
On Tue, Jan 31, 2012 at 10:36:54PM +0100, Rudolf Marek wrote: > >> 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 do not think that there is anything board specific in the VGA code that i once wrote for this display hardware. Did my code break in the last two years? > 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) Again, this board should have native code for bringing a basic vga textmode to life. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Announce new posts in blogs.coreboot.org on list
On Tue, Jan 17, 2012 at 03:16:18PM +0100, Paul Menzel wrote: > Dear coreboot folks, > > > as hopefully everyone of you knows, coreboot has a blog [1]. > Unfortunately not a lot of posts are written. So for people interested > in coreboot and subscribed to the list but not using RSS/Atom feeds > maybe an announcement could be sent to the list? (At least until ten > blog posts per day are written.) > > If no subscriber objects during the next week, maybe Patrick could set > up a hook in Wordpress? That would be great. > > > Thanks, > > Paul > > > [1] http://blogs.coreboot.org/ Thanks, I never knew about this. First off, a list of bloggers who are posting there might be a nice feature which other "planets" tend to have. Secondly, feel free to add libv.livejournal.com, even though i am too deep in graphics driver development these days to actively do coreboot or flashrom work. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ali m1541
On Wed, Sep 15, 2010 at 06:08:54PM +0200, Anders Jenbo wrote: > Sorry i was mistaking, it is Socket 7 old :p > Well, the good side of the ali is that the docs are available. But if it is the p5a, the asus specific superio will trump whatever effort that could happen. But, why bother? Find a chipset and superio that are supported, buy some board that hasn't been implemented yet from like ebay. There is tons of options there. This will get you much more recent hardware, which, when working well, gives you a freer system, that you can use yourself afterwards. Makes things more useful for the world, and give yourself more satisfaction. So forget the ali chipsets. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ali m1541
On Wed, Sep 15, 2010 at 01:51:37PM +0200, Anders Jenbo wrote: > What is the Lilly hood of porting coreboot to a mb based on the Ali m1541 > chipset? > > - Anders How old is that board that you are talking about? My Asus P5A is 12years old, at least, and barely wants to boot still. Maybe ali chipsets are not worth ones time any more. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] FOSDEM DevRoom schedule completed.
http://www.coreboot.org/FOSDEM_2010 Schedule is now complete: * 13:00 : Peter Stuge - coreboot introduction. * 14:00 : Peter Stuge - coreboot and PC technical details. * 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot. * 16:00 : Rudolf Marek - coreboot board porting. * 17:00 : Carl-Daniel Hailfinger - Flashrom. * 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering. Hope to see tons of people there. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
On Fri, Jan 08, 2010 at 03:08:41PM +, j...@settoplinux.org wrote: > > Any chance the talks are going to get captured on video? > Depends on there being other interesting things that Michael Larabel from phoronix might prefer over coreboot stuff at the same time. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
On Fri, Jan 08, 2010 at 02:45:00PM +0100, Paul Menzel wrote: > Am Freitag, den 08.01.2010, 13:44 +0100 schrieb Luc Verhaegen: > > On Fri, Jan 08, 2010 at 12:39:05AM +0100, Rudolf Marek wrote: > > > Btw what is the duration of the talk? > > > > Aim for 45 minutes. Slots are 1h, but people move in and out on the > > hourly edges anyway, and then there is some time to resync, and get > > stuff set up for the next talk, etc. So aim for 45 minutes, if it is > > a bit more, then no problem, you will get stopped at the hour. > > […] > > > All sounds good, but you will have to tone it down to ~45 minutes. > > Or Rudolf can split this up into two talks. > > > Thanks, > > Paul a 45 minute talk is pretty enduring, not only for the speaker but also for the public :) But when not all slots are filled up, then nothing stops this, but we will pause for a bit on the hour. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
On Fri, Jan 08, 2010 at 12:39:05AM +0100, Rudolf Marek wrote: > Hi again, > > Btw what is the duration of the talk? Aim for 45 minutes. Slots are 1h, but people move in and out on the hourly edges anyway, and then there is some time to resync, and get stuff set up for the next talk, etc. So aim for 45 minutes, if it is a bit more, then no problem, you will get stopped at the hour. >> Rudolf Marek - ACPI and Suspend/Resume under coreboot > > Ever wanted to know more about ACPI? The aim of the talk is to introduce > the software part of ACPI as well as provide the necessary hardware > details to get the bigger picture. The tour through Coreboot ACPI > implementation will be given. Suspend and resume procedure will be > presented with all nifty parts explained. > > Thats it. I think I need like hour or hour and half for this. Do you like it? > What sort of audience should I expect? Developers and advanced users, i think full house easily (in this case 50 people), everyone is very friendly and helpful on fosdem. > Perhaps it could even start with a question - what OS needs to know about > the hardware -> and then show how it is connected to the ACPI (irq > routing, PM, PCI buses). When done, one could show how this is > implemented in Coreboot/what files and what does it do. Plus perhaps some > hints how to port ACPI to some new board. At the end I would like to > describe the suspend/resume with some details and pitfalls. > > Maybe some "a" or "the" is missing in the abstract. We don't use them in > Czech language so I don't have big "sense" for them. > > Thanks, > Rudolf I know, SUSE has a prague office :) All sounds good, but you will have to tone it down to ~45 minutes. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FOSDEM2010 devroom needs speakers :)
On Mon, Jan 04, 2010 at 08:33:46PM +0100, Rudolf Marek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > I think I could have a talk too. I could talk bit about coreboot and ACPI and > maybe the suspend/resume stuff? > > Ideas? > > Rudolf Ok, so Rudolf Marek - ACPI and Suspend/Resume under coreboot So far, right after Peter sounds like a good spot for this. 4 talks, 2 slots remaining :) Any abstract i can put up on the wiki? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] FOSDEM2010 devroom needs speakers :)
http://www.coreboot.org/FOSDEM_2010 I am not entirely sure when the FOSDEM organizers will need their schedule data for printing the folder, but i doubt there is much time left. Therefor we should try to finalize the schedule for our devroom ASAP. This means that for each of the 6 available slots, the following needs to be available on the wiki page: speaker name, talk title and talk abstract. I remember that after some limited armtwisting Peter agreed to hold the "main" coreboot talk and carldaniel agreed to hold the "main" flashrom talk. Next to that, i was going to talk about board enable RE-ing, you can see an example of the information that needs to be collected on http://www.coreboot.org/FOSDEM_2010 Thanks. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Integrated graphics controller on second bus?
On Sun, Jan 03, 2010 at 10:15:33PM +0100, Rudolf Marek wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> I think I can help you. It looks to me that bit 7 at offset 0xe1 is not set as
> default anymore (otherwise the code never worked?). You would need to set it
> early so VGA gets visible in "enable" phase. The patch fixes that. Also I
> disabled the direct access FB because it was hardcoded. I forgotten what is
> for,
> maybe libv will know. It looks like the code sets VGA framebuffer size to 32MB
> (this is hardcoded elsewhere check the comments)
>
> Please try the attached patch I think it could fix it.
>
> Thanks,
>
> Rudolf
> Index: northbridge.c
> ===
> --- northbridge.c (revision 4978)
> +++ northbridge.c (working copy)
> @@ -41,32 +41,32 @@
> pci_write_config16(dev, 0x80, 0x610f);
> pci_write_config32(dev, 0x88, 0x0002);
>
> + /* dont know if this is right ID fix it */
> fb_dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0);
> if (fb_dev) {
This is just a quick way of checking whether the unichrome was enabled
at all, so yes, right id.
> - /* Fixup GART and framebuffer addresses properly.
> - * First setup frame buffer properly.
> - */
> - //fb = pci_read_config32(dev, 0x10); /* Base addres of
> framebuffer */
> - fb = 0xd000;
> - printk_debug("Frame buffer at %8x\n",fb);
> -
> - c = pci_read_config8(dev, 0xe1) & 0xf0; /* size of vga */
> - c |= fb>>28; /* upper nibble of frame buffer address */
> - c = 0xdd;
> - pci_write_config8(dev, 0xe1, c);
> - c = 0x81;/* enable framebuffer
> */
> - pci_write_config8(dev, 0xe0, c);
> + /* step 1 enable */
> + pci_write_config8(dev, 0xe1, 0x80);
> + /* step 2 enable the VGA without the direct access framebuffer
> - TOPMEM-32MB must get reserved */
> + pci_write_config8(dev, 0xe1, 0xd0);
> pci_write_config8(dev, 0xe2, 0x42); /* 'cos award does */
> }
> }
>
> static void nullfunc(){}
>
> +static void vga_en(struct device *dev)
> +{
> + /* enable VGA, so the bridges gets VGA_EN and resources are set */
> + pci_write_config8(dev, 0xe1, 0x80);
> +}
> +
> +
> static struct device_operations northbridge_operations = {
> .read_resources = nullfunc,
> .set_resources= pci_dev_set_resources,
> .enable_resources = pci_dev_enable_resources,
> - .init = northbridge_init
> + .init = northbridge_init,
> + .enable = vga_en,
> };
>
> static const struct pci_driver northbridge_driver __pci_driver = {
> @@ -108,11 +108,15 @@
> msr_t clocks1,clocks2,instructions,setup;
>
> printk_debug("VGA random fixup ...\n");
> +
> +
> + // why it does not rely on std resource system?
> +/*
> pci_write_config8(dev, 0x04, 0x07);
> pci_write_config8(dev, 0x0d, 0x20);
> pci_write_config32(dev,0x10,0xd808);
> pci_write_config32(dev,0x14,0xdc00);
> -
> +*/
History.
> // set up performnce counters for debugging vga init sequence
> //setup.lo = 0x1c0; // count instructions
> //wrmsr(0x187,setup);
> @@ -254,6 +258,7 @@
> ramregs[i]);
> }
> printk_debug("I would set ram size to 0x%x Kbytes\n",
> (rambits)*16*1024);
> +//it looks like one set 32MB of VGA?
> tomk = rambits*16*1024 - 32768;
> /* Compute the top of Low memory */
> tolmk = pci_tolm >> 10;
Anything else than 32mb and it dies a horrible death later on when linux
tries to use the disks.
Direct fb access allows any access to the framebuffer on the unichrome
to be intercepted by the memory controller. Unichrome and memory
controller are on the same die here, and since the unichrome uses part
of main ram for its memory, any access to the unichrome memory would
mean requests being made from the unichrome to the memory controller.
Without direct fb access, a lot of on chip bandwidth is effectively
thrown away sending fb accesses back and forth.
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] bios_extract
On Tue, Dec 22, 2009 at 12:54:33AM +0100, Rudolf Marek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > 1) there is a flag for uncompressed module 0x90 instead of 0x80 dunno why > > 2) if the module size in rom > 0x some bytes before the structure are > > used > > as size, the second number looks like crc maybe. > > It turns out the extra header is there for all modules. > > The unknown value is a simple 32bit sum over HEADER and BODY to sum up to 0 ;) > > Dont know how it works for compressed modules nor how it works for modules > with > not multiple of 4. It should be easy to get. > > Rudolf I have seen these headers on compressed too i think. Will have another look at the 2MB module to check. In the meantime, we should add this info. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] CMOS options
On Sat, Dec 12, 2009 at 02:30:01PM +0100, Stefan Reinauer wrote: > On 12/11/09 8:39 PM, ron minnich wrote: > > On Wed, Dec 9, 2009 at 2:57 AM, Andrew Goodbody > > wrote: > > > >> Luc Verhaegen wrote: > >> > >>> We have 892 bytes to our disposal in cmos. We can reserve 128 for > >>> board/cmos versioning, and reserve even 256 for the bootloader, and still > >>> have 512bytes left for coreboot options, which is tons when bits are used > >>> properly and when strings are not used. > >>> > >> Most boards I have used have a maximum space of 256 bytes that includes the > >> RTC. Where does the extra come from? > >> > > On much of my hardware, the most I can assume is 128 bytes - > > subtracting many bytes that are weirdly hardware controlled (such as > > date). > > > > Some of our hardware has 256 bytes. > > > > The io ports only support an 8-bit address I thought? > > > > The ports 0x70/0x71 even only support 7 bits... The 8th bit is used for > NMI control. > > Higher CMOS bytes can be accessed by 0x72/0x73, 0x74/0x75 > > However, if you try to access the upper 128 bytes by setting the topmost > bit in 0x70 it will just look like the upper 128 byte are a mirror of > the lower 128 bytes. > > Stefan Ah, my bad, i guess 1024 bits is why my synapses brought up that figure. Still, it should still be possible to segment this up nicely, and then we suddenly do have a lot of space for bools, sets and integers. And maybe a string or two to denote the board. Luc Verhaegen -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Support for MSI KT4 Ultra (MS-6590)
On Wed, Dec 09, 2009 at 04:28:27PM +0100, freeman2411 wrote: > Oh thats bad, I thought I would get support for my motherboard that I could > run it with coreboot. :-( > > But I will try to get a full lspci -wnnxx so that I can send it to you. No, sorry, i mixed this up with adding support to the flashrom tool. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Support for MSI KT4 Ultra (MS-6590)
On Wed, Dec 09, 2009 at 12:54:03PM +0100, Luc Verhaegen wrote: > > Please provide a full lspci -vvnnxx attached to an email sent to this > thread. > > This is an AMI BIOS, so please send me personally the file created by: > > dd if=/dev/mem of=/tmp/msi_kt4_ultra.system.rom bs=64k count=1 skip=15 > > I am sure that support for your board can then be added. > > Thanks, > > Luc Verhaegen. Support for flashrom... ... and this is not the flashrom list... *slaps head* Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot Support for MSI KT4 Ultra (MS-6590)
On Sun, Nov 15, 2009 at 01:29:27AM +0100, freeman2411 wrote: > Hi Guys! > > Could you please help me with my MSI Mainboard. I would really like to get > it running on this Mainboard. > > *1.)* > MSI KT4 Ultra (MS-6590) > AMD Athlon XP 2200+ > > *2.)* > -[:00]-+-00.0 VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host > Bridge [1106:3189] >+-01.0-[:01]-- >+-0a.0 Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ > [10ec:8139] >+-0c.0 C-Media Electronics Inc CM8738 [13f6:0111] >+-10.0 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller > [1106:3038] >+-10.1 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller > [1106:3038] >+-10.2 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller > [1106:3038] >+-10.3 VIA Technologies, Inc. USB 2.0 [1106:3104] >+-11.0 VIA Technologies, Inc. VT8235 ISA Bridge [1106:3177] >\-11.1 VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] > > > *3.)* ... > *5.)* > http://www.msi-computer.de/index.php?func=proddesc&maincat_no=1&cat2_no=&cat3_no=&prod_no=502# > > *6.)* > Sorry I can't give more hints at this time. :-( > > Thank you for your help! > > Greetings > > > Freeman Please provide a full lspci -vvnnxx attached to an email sent to this thread. This is an AMI BIOS, so please send me personally the file created by: dd if=/dev/mem of=/tmp/msi_kt4_ultra.system.rom bs=64k count=1 skip=15 I am sure that support for your board can then be added. Thanks, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] CMOS options
On Tue, Dec 08, 2009 at 11:01:43PM +0100, Rudolf Marek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > Is there someone who is actively using most of the CMOS options? For example I > just know that Luc is using at least the VRAM size. I think he mentioned that > on > M2V-MX SE memory init options are too dangerous and board won't boot anymore > if > set wrong - maybe even after cmos clear? > > I noticed that century byte is happily ignored - need to check if it really > collides. > > Question is what to do with that. Maybe it would be useful if someone could do > some payload aka "setup" screen to change those options. Maybe it would make > sense to get rid of most and have there only which are really used. > > What do you think? > > Rudolf On m2v mx se, if you set Videoram, then the cmos checksum becomes valid, no matter what bullshit is in the rest of cmos. Then amd k8 init fails, because some of the options on the m2v mx se influence the k8 lethally.. Options which are there for development purposes are ok, but for a board as well implemented as the m2v-mx they should no longer be necessary. As stepan said: people copy paste cluelessly. Last time i posted a patch, and then only after it was commited did it became clear that a "string" is reserved for the seabios/filo at least on the kontron board, making the patch invalid. People spent time discussing a fantastic great future far far away, requiring a copy of flashrom to be available and everything, but no-one involved in that discussion bothered to review the patch properly, and the only Acker did so from the best of his knowledge (and the patch really was sane, just the requirements were wrong). This bootloader option stuff needs to be done differently. Why not just reserve the top 64bytes or so for the bootloader? Then, coreboot board info should be stored in a few bytes too, together with a version number carried in the cmos.options file, bumped as it changes. Option retrieval should check * checksum valid. * board valid. * version valid before it accepts any cmos options. On top of that, cmos.options needs to have a way to specify defaults. We need defaults. If any of the above checks fail when running nvramtool, the tool should ask whether the defaults should be written in, if not, the checksum should not be validated (which should be able to be forcibly overwritten). And nvram tool also needs to be able to work with the space reserved for the bootloader, so the common bootloaders better get reserved space structured too. All of this is a lot of work, but all a lot more useful than doing even more work on a pipedream. We have 892 bytes to our disposal in cmos. We can reserve 128 for board/cmos versioning, and reserve even 256 for the bootloader, and still have 512bytes left for coreboot options, which is tons when bits are used properly and when strings are not used. CMOS is there, and it is easy to access and alter, all it needs is structure and properly implemented infrastructure. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] We have a FOSDEM DevRoom!
On Wed, Dec 02, 2009 at 11:09:04PM +, j...@settoplinux.org wrote: > > According to the wiki it looks like you want to get into bios security a bit. > This may be an opritune time to introduce SerialICE??? If we can get Stepan to talk about it on FOSDEM, sure :) Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] We have a FOSDEM DevRoom!
On Wed, Dec 02, 2009 at 01:13:18AM +0100, Carl-Daniel Hailfinger wrote: > On 02.12.2009 00:36, Luc Verhaegen wrote: > > The kind FOSDEM organizers have given us a DevRoom on saturday the 6th > > of February, as requested. > > > > Thanks a lot for organizing this, Luc! > > > > We have a total of 6 slots available, two of which should be filled with > > an "introductory" talk about coreboot and one about flashrom. > > Introductory here means "this is what $project is, and now we dive > > straight into the gory details." So there are 4 more which i would like > > to see filled up in the next month. > > > > Possible topics from me (time requirements vary, I'm pretty flexible in > that regard): > - Writing a flashrom driver for your favourite programmer (can do in 15 > minutes or less). > - Hands-on flash chip programming (one flash chip and one cheap > home-built programmer for interested participants). Could be combined > with the topic above for a "Total Flashrom Experience(tm)". > - Managing user emergency support and development (flashrom is one of > the most dangerous-to-working-computer projects out there). Mostly a > management talk about how to deal with desperate users and nonconforming > hardware without getting a black eye. Not really my favourite topic, but > if there is overwhelming demand, I can do. > - Using flashrom to detect BIOS rootkits and other nasty stuff living in > your BIOS chip (with demo and background). > > I gave the BIOS rootkit detection talk at 0sec conference in Berne and > OpenExpo in Zürich (with quite a lot of audience participation each > time), tailored for the needs of each event. Depending on what the > audience expects, I will come up with some new stuff and adjust the main > focus of that talk on the security aspect or the real-world problems > faced by this task. > > It would be great if someone else who is involved in flashrom > development right now could fill one of the slots. With Luc tackling the > flash enable stuff, I can either cover one of the topics I mentioned > above or give a general introductory flashrom talk. Cooperative talks > are an option for me as well. > > Oh, and we need all the external programmers supported by flashrom for > display purposes. (Photos are also acceptable, but being able to show > the real stuff is so much more exciting for the audience.) > > Regards, > Carl-Daniel Well, i definitely want you to do the introductory flashrom talk. But on the other hand, the introductory part with flashrom is rather limited, after which you can go and delve deeper into one or several further topics that you mentioned. Chances are that it gets filmed in HDTV and makes it onto phoronix.com. And for showing off, maybe we should get a webcam along that we then can use to show hardware up close on the projector. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] We have a FOSDEM DevRoom!
On Tue, Dec 01, 2009 at 03:43:52PM -0800, ron minnich wrote: > Wonderful work! I really envy you guys going to FOSDEM -- it is a > really great meeting. > > ron Ah, too bad that you're not able to make it this year. I watched your excellent talk there in 2007. Oh, and how do people here feel about getting together with X.org folk in some great restaurant with belgian cooking (le mirabelle) 500ms from FOSDEM on saturday evening? Luc Verhaegen -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] We have a FOSDEM DevRoom!
The kind FOSDEM organizers have given us a DevRoom on saturday the 6th of February, as requested. We got room AW.124, in the AW building on the other side of the campus road from the main building. A "smallish" room at 60 seats, the perfect size for coreboot, and we will have like a window for ventilation and such, which is a nice luxury. Some key european developers are already coming; Carl-Daniel Hailfinger, Peter Stuge and Rudolf Marek, and i hope many more will spend a bit of time and a bit of money (FOSDEM is all free, but travel costs money) on coming to the greatest open source event in europe. We have a total of 6 slots available, two of which should be filled with an "introductory" talk about coreboot and one about flashrom. Introductory here means "this is what $project is, and now we dive straight into the gory details." So there are 4 more which i would like to see filled up in the next month. The page where fosdem info will be kept for coreboot is: http://www.coreboot.org/FOSDEM_2010 Hope to see many of you there! Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [URGENT] FOSDEM DevRoom on Saturday 6th of February 2010?
On Sun, Nov 22, 2009 at 01:13:21PM +0100, Carl-Daniel Hailfinger wrote: > On 22.11.2009 12:56, Luc Verhaegen wrote: > > Carl-Daniel Hailfinger, Peter Stuge, Rudolf Marek are all going to be > > there, and that means that there is enough response from some prominent > > developers for me to go ahead and request a devroom. > > > > It would be great if the devroom was on Saturday. > > Regards, > Carl-Daniel Yeah, that is the plan, and either i get the whole thing denied (unlikely) or we will have coreboot on saturday and X.org on sunday. The real big question mark for me is whether i get this as two different places, in which case, i have a lot more work, or i get the easy way out and can just keep my stuff (powercables/plugs, posters) in one room. So you do not have to worry there, either we get the devroom, or we don't, either way you can have sunday morning off :) Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [URGENT] FOSDEM DevRoom on Saturday 6th of February 2010?
Carl-Daniel Hailfinger, Peter Stuge, Rudolf Marek are all going to be there, and that means that there is enough response from some prominent developers for me to go ahead and request a devroom. When i get it, and there is a very good chance for that, you'll hear some more noise surrounding this in the coming weeks :) Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [URGENT] FOSDEM DevRoom on Saturday 6th of February 2010?
On Fri, Nov 20, 2009 at 07:49:19PM +0100, Luc Verhaegen wrote: > I have been organising the fosdem devroom for Xorg for many years now, > but i am kind of tired of begging and scraping together talks to fill > out a rather well-visited devroom. I feel it is better to only spend > sunday on Xorg and would like to organise a coreboot devroom on saturday > instead. It will be just as much, or even less organisational labour for > me, and this way the coreboot can have saturday afternoon for a cool > devroom on the coolest open source conference around. > > Saturday means that we have 5 talk slots, and i would like to see at > least a few general talks, one general about coreboot, one about > flashrom (i think carldaniel has already "volunteered" for that one) and > one about SerialICE. And then we have 2 more slots where we can take > another topic further in depth. > > When i say general here, you don't have to worry about staying shallow, > the average fosdem visitor is a very experienced user and often a > developer and is not afraid of technical stuff. General talks about the > 3 main topics mean: start off general, then dive into the nitty-gritty, > but the situation of coreboot, and the two sideprojects, is that people > are not that well informed about these projects (it is not something > that everyone has been exposed to in daily free software use). > > Now, why should we do this? Because we really reach a cool audience here > who will be contributing to the projects later on. It's also a nice > place to meet up with current contributors. And when the coreboot > devroom is not on, you can of course go and visit the massive selection > of other talks and other projects represented at FOSDEM. And when the > event is over, you get some known people together and go and eat well in > brussels. > > Fosdem website is here: http://www.fosdem.org you can still check the > shedules for the previous years. > > For those who are interested in coming; you are responsible for your own > expenses, but FOSDEM is an amazingly good value event. No other > conference i have visited has given me more knowledge, contacts, or > motivation than FOSDEM. > > I currently do not need to know who will be holding which talk, i just > need to know that there is enough interest in this, so i can write up my > proposal (due sunday). If we can get a few of the core european > developers to come to brussels that weekend, then some can be > blackmailed into holding talks (:)), and then the whole thing will be a > success. > > Get me some shouts asap, because if i don't get any, i'll just do the > usual Xorg thing, but without begging this year. > > Luc Verhaegen. Seems Peter Stuge didn't need much blackmailing already :) Come on people, we can get this thing rolling. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [URGENT] FOSDEM DevRoom on Saturday 6th of February 2010?
I have been organising the fosdem devroom for Xorg for many years now, but i am kind of tired of begging and scraping together talks to fill out a rather well-visited devroom. I feel it is better to only spend sunday on Xorg and would like to organise a coreboot devroom on saturday instead. It will be just as much, or even less organisational labour for me, and this way the coreboot can have saturday afternoon for a cool devroom on the coolest open source conference around. Saturday means that we have 5 talk slots, and i would like to see at least a few general talks, one general about coreboot, one about flashrom (i think carldaniel has already "volunteered" for that one) and one about SerialICE. And then we have 2 more slots where we can take another topic further in depth. When i say general here, you don't have to worry about staying shallow, the average fosdem visitor is a very experienced user and often a developer and is not afraid of technical stuff. General talks about the 3 main topics mean: start off general, then dive into the nitty-gritty, but the situation of coreboot, and the two sideprojects, is that people are not that well informed about these projects (it is not something that everyone has been exposed to in daily free software use). Now, why should we do this? Because we really reach a cool audience here who will be contributing to the projects later on. It's also a nice place to meet up with current contributors. And when the coreboot devroom is not on, you can of course go and visit the massive selection of other talks and other projects represented at FOSDEM. And when the event is over, you get some known people together and go and eat well in brussels. Fosdem website is here: http://www.fosdem.org you can still check the shedules for the previous years. For those who are interested in coming; you are responsible for your own expenses, but FOSDEM is an amazingly good value event. No other conference i have visited has given me more knowledge, contacts, or motivation than FOSDEM. I currently do not need to know who will be holding which talk, i just need to know that there is enough interest in this, so i can write up my proposal (due sunday). If we can get a few of the core european developers to come to brussels that weekend, then some can be blackmailed into holding talks (:)), and then the whole thing will be a success. Get me some shouts asap, because if i don't get any, i'll just do the usual Xorg thing, but without begging this year. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] consolidate K8M890 VGA code
cessary. A sane default value _and_ a CMOS option is what is needed. What will a KConfig option lead to: * developers will bother even less with cmos in future, leaving the crap that is in there for everyone to run into. * uwe then does not have to do the mental work to restore the cmos options for the other graphics chips. * users will think we're complete idiots, but we will never be told anyway, as it will be even more obvious that we are living in a world of our own. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] consolidate K8M890 VGA code
On Wed, Oct 28, 2009 at 05:00:11PM -0600, Myles Watson wrote: > On Wed, Oct 28, 2009 at 4:44 PM, Myles Watson wrote: > > > fbbits = ((log2(uma_memory_size >> 20) - 2) << 4); > > Why not use CONFIG_VIDEO_MB here? If it is going to be fixed at compile > > time, it seems like you can get rid of uma_memory_size. > > > Either way: > > Acked-by: Myles Watson > > Thanks, > Myles NACK. WHY? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] consolidate K8M890 VGA code
On Wed, Oct 28, 2009 at 10:53:41PM +0100, Rudolf Marek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello all, > > Following patch changes the K8M890 VGA handling. It reverts the framebuffer > size > to option based (similar what Uwe did) and also it uses GFXUMA to handle the > high_tables_start offset from memory top. > > It adds HAVE_MOTHERBOARD_RESOURCES to kconfig because we do have the > resources ;) > > Signed-off-by: Rudolf Marek > > Rudolf Wtf? Do you really want to get rid of dynamically being able to set the FB size? Why? Don't you think that this is a feature that regular users of probably the only fully implemented coreboot motherboards might actually want to touch? Why is no time being spent on removing the other options that actually harm booting this device? Why does this feel like more pointless pedanticity? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] AMD CS5530(A) ROM enable
On Tue, Oct 06, 2009 at 04:42:54PM +0200, Carl-Daniel Hailfinger wrote: > On 06.10.2009 16:34, Uwe Hermann wrote: > > +* Make the ROM write-protected. > > > > Does that mean we have to unprotect the ROM in flashrom? > > Regards, > Carl-Daniel I am happy with that if, and only if, the flashrom chipset enable takes care of that. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Original bios as payload
On Wed, Jul 29, 2009 at 09:36:20AM -0400, Ivan Barrera A. wrote: > Hi ! > > My previous attemps to put coreboot on my laptop (Asus G1, with > vgarom on bios) have failed. > I want to keep trying to get something to work but it is a real pain > in the behind to keep taking out the flash chip and reprogramming it. I > think it could be easier to have coreboot booting the original bios , > and run any other payload on some key press (or something like that). > That way, i could keep flashing new code to try, and in case it doesnt > work just boot the orig. bios and reflash. (this is asuming coreboot > gets to run) > > Is it possible ? Or, do you have any other sugestions to keep trying ? > > Thanks Ok, here is a thought... Every x86 cpu starts in real mode, at address 0xF000:0xFFF0. The last 16 bytes of your address space, and the last 16 bytes of your rom. You will find a jump there, and some extra space to put in a longer jump if needs be. Have the original image sit at the top of a bigger flash chip, replace the jump to jump somewhere in the bottom halve of the flash (if that's still addressable by real mode). This code then checks some RTC value while remaining in realmode. If the rtc content is valid, and this fixed location byte is telling it to boot the original image, then just jump to the vector of the original jump. If not, go to the coreboot location and run coreboot. The question is: is the change in the original image (the different reset vector) going to hit a checksum check somewhere? After some discussion on irc, it is not there on phoenix trusted core (for the initial bios code and the decompression bios) so then it will most likely not be there for less paranoid bioses. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] sb/via/k8t890: add vga textmode code for k8m890 chrome igp.
On Mon, Jul 27, 2009 at 04:06:45PM +0200, Luc Verhaegen wrote: > > No; a general VGA bios is a broken concept to begin with. > > What you should know is that VGA is _not_ a standard, and one should > never, ever try to change the mode without more detailed hw knowledge. > It is only a standard through the int10 and vbe interfaces, where the > manufacturers vga bios does all the vga and hw specific stuff for you. > > What such a general bios should do is find out, one way or another, what > mode has been set and how to stuff things into the framebuffer. > > In this case: mode 3h: 80x25 with 8x16 fonts, with the framebuffer > living at 0xB8000 and with vga standard cursor and fb offset handling. > > So a general int10 bios should find this out and then claim to only > support this and absolutely nothing else. > > Everything else requires a whole bunch of hw specific code, and while > you could spend the rest of your days porting graphics drivers from fb > or X to this code, i think there are much better ways to spend ones > time. > > Luc Verhaegen. Let me further quantise this: It would be great if there was int10 infrastructure which would do just the above. * Seabios can show us its menu. * Grub will then give us its menu too. * The linux kernel will no longer think that it is talking to CGA and will use the correct fontsize while setting the cursor (so that we no longer get a floating cursor). Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] sb/via/k8t890: add vga textmode code for k8m890 chrome igp.
On Sun, Jul 26, 2009 at 02:21:34PM -0400, Kevin O'Connor wrote: > On Thu, Jul 23, 2009 at 02:20:53PM +0200, Luc Verhaegen wrote: > > Add initialisation for the VIA Chrome 9 IGP on the k8m890 through native > > code > > and through the general vga infrastructure i committed a month or two ago. > > Add videoram_size option for k8m890 and the Asus M2V-MX SE. > > > > Now the Asus M2V-MX SE will magically come up with a working standard VGA > > 80x25 textmode. > > Hi Luc, > > With your code, will the SeaBIOS vgabios (make out/vgabios.bin) run on > the board? > > -Kevin No; a general VGA bios is a broken concept to begin with. What you should know is that VGA is _not_ a standard, and one should never, ever try to change the mode without more detailed hw knowledge. It is only a standard through the int10 and vbe interfaces, where the manufacturers vga bios does all the vga and hw specific stuff for you. What such a general bios should do is find out, one way or another, what mode has been set and how to stuff things into the framebuffer. In this case: mode 3h: 80x25 with 8x16 fonts, with the framebuffer living at 0xB8000 and with vga standard cursor and fb offset handling. So a general int10 bios should find this out and then claim to only support this and absolutely nothing else. Everything else requires a whole bunch of hw specific code, and while you could spend the rest of your days porting graphics drivers from fb or X to this code, i think there are much better ways to spend ones time. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] sb/via/k8t890: add vga textmode code for k8m890 chrome igp.
On Thu, Jul 23, 2009 at 03:18:49PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > sb/via/k8t890: add vga textmode code for k8m890 chrome igp. > > > > Add initialisation for the VIA Chrome 9 IGP on the k8m890 through native > > code > > and through the general vga infrastructure i committed a month or two ago. > > Add videoram_size option for k8m890 and the Asus M2V-MX SE. > > > > Now the Asus M2V-MX SE will magically come up with a working standard VGA > > 80x25 textmode. > > > > Many thanks to the people who worked hard on the Asus M2V-MX SE, and all > > of its components; this vga bringup was a breeze thanks to your hard work > > for this excellently supported board. And separate thanks to Rudolf Marek > > for spurring me on and for providing a register dump. > > > > Signed-off-by: Luc Verhaegen > > Acked-by: Peter Stuge Thanks: -> r4465 Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] sb/via/k8t890: add vga textmode code for k8m890 chrome igp.
On Thu, Jul 23, 2009 at 05:29:01PM +0200, Rudolf Marek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Luc, > > looks fine. Please check the vga_init.c as we discussed on IRC. For that, we need to figure out what these two registers really do depend on and what their effect is. > Also, maybe you > can develop simple patch that will write the memsize and speedgrade to scratch > registers. Tell you what; i'll go off for two days, and develop the solid PLL calculation routine needed to bring up the k8m890 in my unichrome driver. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] sb/via/k8t890: add vga textmode code for k8m890 chrome igp.
Luc Verhaegen. sb/via/k8t890: add vga textmode code for k8m890 chrome igp. Add initialisation for the VIA Chrome 9 IGP on the k8m890 through native code and through the general vga infrastructure i committed a month or two ago. Add videoram_size option for k8m890 and the Asus M2V-MX SE. Now the Asus M2V-MX SE will magically come up with a working standard VGA 80x25 textmode. Many thanks to the people who worked hard on the Asus M2V-MX SE, and all of its components; this vga bringup was a breeze thanks to your hard work for this excellently supported board. And separate thanks to Rudolf Marek for spurring me on and for providing a register dump. Signed-off-by: Luc Verhaegen --- src/mainboard/asus/m2v-mx_se/Options.lb|7 +- src/mainboard/asus/m2v-mx_se/cmos.layout |8 ++ src/southbridge/via/k8t890/Config.lb |1 + src/southbridge/via/k8t890/k8m890_chrome.c | 179 src/southbridge/via/k8t890/k8t890.h|3 + src/southbridge/via/k8t890/k8t890_dram.c | 43 ++- 6 files changed, 235 insertions(+), 6 deletions(-) create mode 100644 src/southbridge/via/k8t890/k8m890_chrome.c diff --git a/src/mainboard/asus/m2v-mx_se/Options.lb b/src/mainboard/asus/m2v-mx_se/Options.lb index 75925ea..203f770 100644 --- a/src/mainboard/asus/m2v-mx_se/Options.lb +++ b/src/mainboard/asus/m2v-mx_se/Options.lb @@ -44,7 +44,7 @@ uses CONFIG_XIP_ROM_SIZE uses CONFIG_XIP_ROM_BASE uses CONFIG_STACK_SIZE uses CONFIG_HEAP_SIZE -# uses CONFIG_USE_OPTION_TABLE +uses CONFIG_USE_OPTION_TABLE uses CONFIG_LB_MEM_TOPK uses CONFIG_HAVE_ACPI_TABLES uses CONFIG_HAVE_MAINBOARD_RESOURCES @@ -74,6 +74,7 @@ uses CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL uses CONFIG_CONSOLE_SERIAL8250 uses CONFIG_HAVE_INIT_TIMER uses CONFIG_GDB_STUB +uses CONFIG_VGA uses CONFIG_CONSOLE_VGA uses CONFIG_PCI_ROM_RUN # bx_b001- uses K8_HW_MEM_HOLE_SIZEK @@ -101,7 +102,7 @@ default CONFIG_HAVE_HARD_RESET = 1 default CONFIG_HAVE_PIRQ_TABLE = 0 default CONFIG_IRQ_SLOT_COUNT = 11 # FIXME? default CONFIG_HAVE_MP_TABLE = 0 -default CONFIG_HAVE_OPTION_TABLE = 0 # FIXME +default CONFIG_HAVE_OPTION_TABLE = 1 # FIXME # Move the default coreboot CMOS range off of AMD RTC registers. default CONFIG_LB_CKS_RANGE_START = 49 default CONFIG_LB_CKS_RANGE_END = 122 @@ -136,6 +137,7 @@ default CONFIG_SB_HT_CHAIN_ON_BUS0 = 1 # Only offset for SB chain?, default is yes(1). default CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY = 0 +default CONFIG_VGA = 1 default CONFIG_CONSOLE_VGA = 1 # Needed for VGA. default CONFIG_PCI_ROM_RUN = 0 # Needed for VGA. default CONFIG_USE_DCACHE_RAM = 1 @@ -157,6 +159,7 @@ default CONFIG_HEAP_SIZE = 256 * 1024 default CONFIG_LB_MEM_TOPK = 32768 # to 1MB default CONFIG_RAMBASE = 0x1F0 +default CONFIG_USE_OPTION_TABLE = 0 # default CONFIG_USE_OPTION_TABLE = !CONFIG_USE_FALLBACK_IMAGE default CONFIG_ROM_PAYLOAD = 1 default CC = "$(CONFIG_CROSS_COMPILE)gcc -m32" diff --git a/src/mainboard/asus/m2v-mx_se/cmos.layout b/src/mainboard/asus/m2v-mx_se/cmos.layout index 758c8dc..8276376 100644 --- a/src/mainboard/asus/m2v-mx_se/cmos.layout +++ b/src/mainboard/asus/m2v-mx_se/cmos.layout @@ -43,6 +43,7 @@ entries 440 4 e 9slow_cpu 444 1 e 1nmi 445 1 e 1iommu +448 3 e 10 videoram_size 728256 h 0user_data 984 16 h 0check_sum # Reserve the extended AMD configuration registers @@ -90,6 +91,13 @@ enumerations 9 5 37.5% 9 6 25.0% 9 7 12.5% +# videoram_size: mimics the bits in the ramcontroller. +10 1 8MB +10 2 16MB +10 3 32MB +10 4 64MB +10 5 128MB +10 6 256MB checksums diff --git a/src/southbridge/via/k8t890/Config.lb b/src/southbridge/via/k8t890/Config.lb index 27e80b9..72502c2 100644 --- a/src/southbridge/via/k8t890/Config.lb +++ b/src/southbridge/via/k8t890/Config.lb @@ -25,3 +25,4 @@ driver k8t890_host_ctrl.o driver k8t890_pcie.o driver k8t890_traf_ctrl.o driver k8t890_error.o +driver k8m890_chrome.o diff --git a/src/southbridge/via/k8t890/k8m890_chrome.c b/src/southbridge/via/k8t890/k8m890_chrome.c new file mode 100644 index 000..544b08e --- /dev/null +++ b/src/southbridge/via/k8t890/k8m890_chrome.c @@ -0,0 +1,179 @@ +/* + * Copyright (C) 2007-2009 Luc Verhaegen + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You s
[coreboot] bios_extract.
As many probably know already, i have been poking on cleaning up some code that has been floating around the web to extract individual modules out of common legacy bios images. It's called bios_extract and it should be able to extract award, standard phoenix and ami bioses. It contains code and information retrieved from code of both Anton Borisov and Veit Kannegieser, and the lh5 extraction routine was stripped out of lha. The tree can be found here, the git-uri is also available from this page: http://cgit.freedesktop.org/~libv/bios_extract/ Simply point it to a bios image, and watch it clutter up your working directory. If it doesn't work for you, you know where to find me :) Enjoy, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] superiotool: Add IT8703F support.
On Fri, Jul 10, 2009 at 12:17:03PM +0200, Uwe Hermann wrote:
> On Thu, Jul 09, 2009 at 06:36:59PM +0200, Luc Verhaegen wrote:
> > Superiotool: Add IT8703F support.
> >
> > Kudos to ITE for quickly providing information.
> >
> > Signed-off-by: Luc Verhaegen
>
> Looks good, but see below for minor consistency fixes.
>
>
> > Index: ite.c
> > ===
> > --- ite.c (revision 4407)
> > +++ ite.c (working copy)
> > @@ -66,6 +66,44 @@
> > {EOT}}},
> > {0x8681, "IT8671F/IT8687R", {
> > {EOT}}},
> > + {0x8701, "IT8703F", {
> > + {NOLDN, NULL,
> > +{0x20,0x21,0x23,0x24,0x26,0x29,0x2A,0x2B,EOT},
> > +{0x87,0x00,0x00,0x80,0x00,0x00,0x7C,0xC0,EOT}},
> ^
>
> Indent this part by one TAB also please (and wrap lines at 80 chars if
> needed) to match the rest of superiotool style.
>
>
> > + {0x0, "Floppy Disk Controller",
>
> Also, "Floppy disk controller" (or even just "Floppy"), i.e., only first
> word capitalized, to match the conventions in rest of superiotool. The
> same applies to the other LDNs ("Parallel port" etc). "Consumer IR" is
> fine as "IR" is an abbreviation.
>
>
> Other than that:
>
> Acked-by: Uwe Hermann
>
>
> Uwe.
Done.
Committed as r4424.
Thanks,
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Patch] superiotool: Add IT8703F support.
Glenn, can you run this on your Asus A7V8X and attach the output?
Thanks,
Luc Verhaegen.
Superiotool: Add IT8703F support.
Kudos to ITE for quickly providing information.
Signed-off-by: Luc Verhaegen
Index: ite.c
===
--- ite.c (revision 4407)
+++ ite.c (working copy)
@@ -66,6 +66,44 @@
{EOT}}},
{0x8681, "IT8671F/IT8687R", {
{EOT}}},
+ {0x8701, "IT8703F", {
+ {NOLDN, NULL,
+{0x20,0x21,0x23,0x24,0x26,0x29,0x2A,0x2B,EOT},
+{0x87,0x00,0x00,0x80,0x00,0x00,0x7C,0xC0,EOT}},
+ {0x0, "Floppy Disk Controller",
+{0x30,0x60,0x61,0x70,0x74,0xF0,0xF1,0xF2,0xF3,0xF4,0xF5,EOT},
+{0x00,0x03,0xf0,0x06,0x02,0x0E,0x00,0xFF,0x00,0x00,0x00,EOT}},
+ {0x1, "Parallel Port",
+{0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,EOT},
+{0x00,0x03,0x78,0x00,0x80,0x07,0x03,0x03,EOT}},
+ {0x2, "Serial Port 1",
+{0x30,0x60,0x61,0x70,0xf0,EOT},
+{0x00,0x03,0xf8,0x04,0x00,EOT}},
+ {0x3, "Serial Port 2",
+{0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT},
+{0x00,0x02,0xf8,0x03,0x00,0x00,0x00,0x7f,EOT}},
+ {0x5, "Keyboard Controller",
+{0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+{0x01,0x00,0x60,0x00,0x64,0x01,0x0C,0x80,EOT}},
+ {0x6, "Consumer IR",
+{0x30,0x60,0x61,0x70,EOT},
+{0x00,0x00,0x00,0x00,EOT}},
+ {0x7, "Game Port, MIDI, GPIO Set 1",
+{0x30,0x60,0x61,0x62,0x63,0x70,0xF0,0xF1,0xF2,EOT},
+{0x00,0x02,0x01,0x03,0x30,0x00,0xFF,0x00,0x00,EOT}},
+ {0x8, "GPIO Set 2",
+{0x30,0xF0,0xF1,0xF2,0xF3,0xF5,EOT},
+{0x00,0xFF,0x00,0x00,0x00,0x00,EOT}},
+ {0x9, "GPIO Set 3 and 4",
+{0x30,0x60,0x61,0xF0,0xF1,0xF2,0xF3,0xF4,EOT},
+{0x00,0x02,0x90,0xFF,0x00,0x00,0x00,0x00,EOT}},
+ {0xA, "ACPI",
+
{0x30,0x70,0xE0,0xE1,0xE2,0xE3,0xE4,0xE5,0xE6,0xE7,0xF3,0xF4,0xF6,0xF7,0xF9,EOT},
+
{0x00,0x00,0x00,0x00,NANA,NANA,0x00,0x00,0x00,0x00,NANA,NANA,0x00,0x00,0x00,EOT}},
+ {0xC, "GPIO Set 5, 6 and 7",
+{0x30,0x60,0x61,0xF0,0xF3,0xF6,EOT},
+{0x00,0x03,0x70,0x00,0xFF,0xFF,EOT}},
+ {EOT}}},
{0x8702, "IT8702F", {
{EOT}}},
{0x8705, "IT8705F/AF / IT8700F", {
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Patch] superiotool: add vt1211 support.
I spent a bit of time on adding support for the vt1211 superio found on
the epia-m board. It does not add io dumping, yet.
Compared to the rest of the superiotool, this support is highly
different; i see quite a lot of possibility for superiotool to be
improved (more on that later in this mail).
This here is the output of superiotool on my vt1211:
VT1211 LDN 0: "Floppy Disk Controller"
0x30: 0x01(0x00)"Activate"
0x60: 0xFC(0xFC)"I/O Base Address"
0x70: 0x06(0x06)"IRQ Select"
0x74: 0x02(0x01)"DRQ Select"
0xF0: 0x00(0x00)"Configuration"
0xF1: 0x00(0x00)"Drive Select"
Notice how it lists one register per line, with:
index: value (default).
The string is just there because it was easy to add while adding the
other information.
Why do i prefer 1 register per line as opposed to whole blobs for other
chipsets:
* we're human and this is easier to read.
* diff is also surprisingly human.
I would like to alter the printing of other superios to the same, one
per line, output. I have been told on irc that this might break some
peoples scripts (if there are any), but for humans, this is the sanest
thing to do.
Further changes that might be good:
* decouple probing from dumping.
* add single value dumping and then also writing (requires tracking of
RO/WO).
* there are only a few probe routines out there, create a general table
so that we can tie io_port and the return value of the probe routine
to an id and thus reduce probing to once per probe routine.
* etc, etc...
Tons of room for improvement and also discussion :)
But first, let's scrutinize this way of outputting and if acceptable,
also alter the output of other superio dumps. I will be adding IT8103F
support today, which will also further my view of what needs to be done
here.
Luc Verhaegen.
Index: via.c
===
--- via.c (revision 0)
+++ via.c (revision 0)
@@ -0,0 +1,321 @@
+/*
+ * This file is part of the superiotool project.
+ *
+ * Copyright (C) 2009 Luc Verhaegen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ * Supports VIA VT1211.
+ */
+
+#include "superiotool.h"
+
+/*
+ * Low level operations.
+ */
+#define VT1211_REG_IDX 0x2E
+#define VT1211_REG_DATA 0x2F
+
+static void
+vt1211_confmode_enter(void)
+{
+ OUTB(0x87, VT1211_REG_IDX);
+ OUTB(0x87, VT1211_REG_IDX);
+}
+
+static void
+vt1211_confmode_leave(void)
+{
+ OUTB(0xAA, VT1211_REG_IDX);
+}
+
+static unsigned char
+vt1211_read(unsigned char index)
+{
+ OUTB(index, VT1211_REG_IDX);
+ return INB(VT1211_REG_DATA);
+}
+
+static void
+vt1211_write(unsigned char index, unsigned char data)
+{
+ OUTB(index, VT1211_REG_IDX);
+ OUTB(data, VT1211_REG_DATA);
+}
+
+static void
+vt1211_ldn_select(unsigned char ldn)
+{
+ vt1211_write(0x07, ldn);
+}
+
+/*
+ * now define our tables
+ */
+struct vt1211_register {
+ uint8_t index;
+ uint8_t def;
+ char *name;
+};
+
+/* Main registers */
+static struct vt1211_register
+vt1211_configuration_space[] = {
+ {0x07, 0x00, "Logical Device Number"}, /* no default */
+ {0x20, 0x3C, "Device ID"}, /* RO */
+ {0x21, 0x01, "Device Revision"}, /* RO */
+ {0x22, 0x00, "Power Down Control"},
+ {0x23, 0x11, "LPC Wait State Select"},
+ {0x24, 0x00, "GPIO Port 1 Pin Select"},
+ {0x25, 0x00, "GPIO Port 2 Pin Select"},
+ {0x26, 0x00, "GPIO Port 7 Pin Select"},
+ {0x27, 0x00, "UART2 Multi Function Pin Select"},
+ {0x28, 0x00, "MIDI Multi Function Pin Select"},
+ {0x29, 0x00, "HWM Multi Function Pin Select"},
+ {0x2E, 0x00, "Test Mode A (Do Not Program)"},
+ {0x2E, 0x00, "Test Mode B (Do Not Program)"},
+ {0, 0, NULL}
+};
+
+/* Floppy Disk Controller */
+static struct vt1211_register
+vt1211_ldn_0_registers[] = {
+ {0x30, 0x00, &qu
Re: [coreboot] [Patch] flashrom: board enable for shuttle ak31.
Re-posted to flashrom ml, waiting for board owner to get back to us properly. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] User:Hailfinger/Drafts/Women
On Thu, Jun 25, 2009 at 06:57:31PM +0200, Carl-Daniel Hailfinger wrote: > On 25.06.2009 18:08, Joseph Smith wrote: > > Carl-Daniel what does this have to do with anything? > > > > http://www.coreboot.org/User:Hailfinger/Drafts/Women > > > > I placed this under my user page because it is still a draft. > Basically, the idea behind this page is to encourage women to become > active coreboot developers/users. Compared to other lowlevel free > software projects, we have a pretty OK female/male ratio, but since > we're developer-starved (in the sense of having enough TODO items to > keep everyone busy for more than a year), any way to recruit additional > developers seems good to me. Saying that we explicitly welcome > participation from women may get us mentioned in a few key blogs and > possibly result in increased participation. > > I hope the explanation above is sufficient. If not, feel free to ask. > > Regards, > Carl-Daniel You don't get closer to hw than coreboot, you can barely get geekier than coreboot. What you're hoping for here is as likely to happen as getting hit by lightning, and even when that happens, it's going to be over quickly, so why bother? Why not work on attracting more geeky people who like being close to hw? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Clean up Makefile
On Tue, Jun 23, 2009 at 01:51:06PM +0200, Carl-Daniel Hailfinger wrote: > On 23.06.2009 13:40, Luc Verhaegen wrote: > > On Tue, Jun 23, 2009 at 12:49:55PM +0200, Carl-Daniel Hailfinger wrote: > > > >> The makefile rules for %.o and flashrom.o are identical. Let %.o handle > >> flashrom.o as well. > >> > >> Signed-off-by: Carl-Daniel Hailfinger > >> > > Acked-by: Luc Verhaegen > > > > Thanks, committed in r626. > > > > Why am i seeing your patches double in your emails? Np for small ones, > > but for a big patch, seeing it double might be confusing. > > > > Some developers use Gmail and it seems Gmail mangles inline patches and > doesn't display attached patches automatically. So the inline version if > for reviewing and the attached version is for applying. > If that problem doesn't exist anymore, I'll gladly skip attaching the > patches and send them inline only. > > Regards, > Carl-Daniel Oh, trusty old mutt here, with the setup i use, happily includes text attachments in the reply, and it nicely scrolls from the end of the actual mail straight into the attachment. So I'd rather not see an inlined patch, and prefer just the attachment. You are aiding the people that are unable to deal with text attachments properly, but at the same time you are hurting those who do have that ability. Which of those two setups is "broken", and which of those are you spending some extra time on? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom][PATCH] invalid local variable declaration
On Tue, Jun 23, 2009 at 01:51:21PM +0200, Stefan Reinauer wrote: > Hi, Luc, > > I agree we should set standards as low as possible, and try to make it > easier for people to write good code, but.. > > On 23.06.2009 13:39 Uhr, Luc Verhaegen wrote: > > I personally dislike this, as it is only done to make it easier for > > people to be lazy. > > > > Or to make the code more compact and easier to read. I believe that this one can go both ways. People can argue these both points from either side. > > By being forced to declare variables at the beginning of blocks, people > > are pushed towards creating smaller blocks and therefor expose natural > > deliniations quicker. > > While you may be right for many cases, I don't believe that cutting > features of a programming language automatically makes people write > better code. If it were, we'd all be writing firmware in Forth. ;-) This is one of those things that i believe are not a feature, and is just something that c++ developers got used to and then claim they missed when they were back in the C world for a bit. > > Just because the compiler can handle it doesn't mean that you should > > write less good code than you could. > > > Just because the compiler allows you to declare variables inline does > not mean that you should create bigger code blocks or write worse code. It is something that cannot be stopped. It is human nature and it will always happen. Not everybody is always as nitpicky when writing or reviewing code. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Clean up Makefile
On Tue, Jun 23, 2009 at 12:49:55PM +0200, Carl-Daniel Hailfinger wrote: > The akefile rules for %.o and flashrom.o are identical. Let %.o handle > flashrom.o as well. > > Signed-off-by: Carl-Daniel Hailfinger > > Index: flashrom-makefile_cleanup/Makefile > === > --- flashrom-makefile_cleanup/Makefile(Revision 624) > +++ flashrom-makefile_cleanup/Makefile(Arbeitskopie) > @@ -70,11 +70,8 @@ > > FEATURE_LIBS = $(shell LANG=C grep -q "FTDISUPPORT := yes" .features && > printf "%s" "-lftdi") > > -flashrom.o: flashrom.c .features > - $(CC) $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) -c -o $@ $< $(SVNDEF) > - > %.o: %.c .features > - $(CC) $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) -c $< -o $@ $(SVNDEF) > + $(CC) $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< > > clean: > rm -f $(PROGRAM) *.o Ah, more simple flashrom things that even i understand... Acked-by: Luc Verhaegen Why am i seeing your patches double in your emails? Np for small ones, but for a big patch, seeing it double might be confusing. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom][PATCH] invalid local variable declaration
On Tue, Jun 23, 2009 at 12:32:05PM +0200, Stefan Reinauer wrote:
> stephan.guill...@free.fr wrote:
> > Hello all,
> >
> > To start teh day, a small patch for an invalid local variable...
> > In C, local variable must be declared before any statment, and not, like in
> > C++
> > in the middle of the function.
> >
> >
> Thanks a lot for the patch!
>
> The restriction of local variable declarations only working at the top
> of the function has been revised in the C99 standard. Every compiler
> that is C99 compliant will understand the code and do the right thing.
>
> Stefan
I personally dislike this, as it is only done to make it easier for
people to be lazy.
By being forced to declare variables at the beginning of blocks, people
are pushed towards creating smaller blocks and therefor expose natural
deliniations quicker. Then people are more likely to create small
(inlined) functions out of those blocks instead of using {} in the
middle of a block.
Just because the compiler can handle it doesn't mean that you should
write less good code than you could.
Let's keep variable declarations old style, as it is a style choice
which has some consequences with respect to human behaviour.
Luc Verhaegen,
A very lazy man who knows what he would be doing if things were made too
easy on him.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: SB600 SPI: Kill unused variable
On Mon, Jun 22, 2009 at 04:31:44PM +0200, Carl-Daniel Hailfinger wrote:
> SB600 SPI: Kill unused variable.
>
> Signed-off-by: Carl-Daniel Hailfinger
>
> Index: flashrom-sb600spi_unneeded_struct/sb600spi.c
> ===
> --- flashrom-sb600spi_unneeded_struct/sb600spi.c (Revision 622)
> +++ flashrom-sb600spi_unneeded_struct/sb600spi.c (Arbeitskopie)
> @@ -25,6 +25,7 @@
> #include "flash.h"
> #include "spi.h"
>
> +/* This struct is unused, but helps visualize the SB600 SPI BAR layout. */
> struct sb600_spi_controller {
> unsigned int spi_cntrl0;/* 00h */
> unsigned int restrictedcmd1;/* 04h */
> @@ -36,7 +37,6 @@
> unsigned int spi_fakeid;/* 1Ch */
> };
>
> -struct sb600_spi_controller *spi_bar = NULL;
> uint8_t *sb600_spibar;
>
> int sb600_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len)
> @@ -111,8 +111,6 @@
>
> writecnt--;
>
> - spi_bar = (struct sb600_spi_controller *) sb600_spibar;
> -
> printf_debug("%s, cmd=%x, writecnt=%x, readcnt=%x\n",
>__func__, cmd, writecnt, readcnt);
>
>
>
> --
> http://www.hailfinger.org/
>
If this builds, then what can be wrong with this :)
I guess you are keeping this struct because publically available
documentation is perhaps not as clear as it should be? Why not comment
it completely so that no-one else will complain about it in future? If
it is a comment, people are more likely to leave it or scroll over it,
if it remains a useless struct definition, then people will eventually
stumble over it and try to remove it, and therefor possibly remove
useful information.
Please also make reset_internal_fifo_pointer and execute_command static
so thatthese symbols, when unused, will turn up in the build as well.
Apart from that, of course:
Acked-by: Luc Verhaegen
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Patch] flashrom: board enable for shuttle ak31.
Board enable for Shuttle AK31.
All AK31 versions, 1.x, 2.x and 3.x are supported by this board enable.
Sadly this board can not be autodetected.
Re-uses the epox ep 8k5a2 board enable, which now lost its check for
the VT8235 ISA bridge and got renamed to w836xx_memw_enable_2e.
Signed-off-by: Luc Verhaegen
Index: board_enable.c
===
--- board_enable.c (revision 612)
+++ board_enable.c (working copy)
@@ -297,18 +297,13 @@
}
/**
- * Suited for EPoX EP-8K5A2 and Albatron PM266A.
+ * Suited for:
+ * - EPoX EP-8K5A2: VIA KT333 + VT8235.
+ * - Albatron PM266A: VIA P4M266A + VT8235.
+ * - Shuttle AK31 (all versions): VIA KT266 + VT8233.
*/
-static int board_epox_ep_8k5a2(const char *name)
+static int w836xx_memw_enable_2e(const char *name)
{
- struct pci_dev *dev;
-
- dev = pci_dev_find(0x1106, 0x3177); /* VT8235 ISA bridge */
- if (!dev) {
- fprintf(stderr, "\nERROR: VT8235 ISA bridge not found.\n");
- return -1;
- }
-
w836xx_memw_enable(0x2E);
return 0;
@@ -811,14 +806,14 @@
/* first pci-id set [4], second pci-id set [4],
coreboot id [2], vendor nameboard nameflash enable
*/
{0x8086, 0x1130, 0, 0, 0x105a, 0x0d30, 0x105a, 0x4d33,
"acorp", "6a815epd","Acorp", "6A815EPD",
board_acorp_6a815epd},
{0x1022, 0x746B, 0x1022, 0x36C0, 0, 0, 0, 0,
"AGAMI", "ARUMA", "agami", "Aruma",
w83627hf_gpio24_raise_2e},
- {0x1106, 0x3177, 0x17F2, 0x3177, 0x1106, 0x3148, 0x17F2, 0x3148, NULL,
NULL, "Albatron","PM266A",
board_epox_ep_8k5a2},
+ {0x1106, 0x3177, 0x17F2, 0x3177, 0x1106, 0x3148, 0x17F2, 0x3148, NULL,
NULL, "Albatron","PM266A",
w836xx_memw_enable_2e},
{0x1022, 0x2090, 0, 0, 0x1022, 0x2080, 0, 0,
"artecgroup", "dbe61", "Artec Group", "DBE61",
board_artecgroup_dbe6x},
{0x1022, 0x2090, 0, 0, 0x1022, 0x2080, 0, 0,
"artecgroup", "dbe62", "Artec Group", "DBE62",
board_artecgroup_dbe6x},
{0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL,
NULL, "ASUS","A7V8-MX SE",
board_asus_a7v8x_mx},
{0x8086, 0x1a30, 0x1043, 0x8070, 0x8086, 0x244b, 0x1043, 0x8028, NULL,
NULL, "ASUS","P4B266", ich2_gpio22_raise},
{0x10B9, 0x1541, 0, 0, 0x10B9, 0x1533, 0, 0,
"asus", "p5a", "ASUS","P5A",
board_asus_p5a},
{0x1106, 0x3149, 0x1565, 0x3206, 0x1106, 0x3344, 0x1565, 0x1202, NULL,
NULL, "BioStar", "P4M80-M4",
board_biostar_p4m80_m4},
- {0x1106, 0x3177, 0x1106, 0x3177, 0x1106, 0x3059, 0x1695, 0x3005, NULL,
NULL, "EPoX","EP-8K5A2",
board_epox_ep_8k5a2},
+ {0x1106, 0x3177, 0x1106, 0x3177, 0x1106, 0x3059, 0x1695, 0x3005, NULL,
NULL, "EPoX","EP-8K5A2",
w836xx_memw_enable_2e},
{0x8086, 0x7110, 0, 0, 0x8086, 0x7190, 0, 0,
"epox", "ep-bx3", "EPoX","EP-BX3",
board_epox_ep_bx3},
{0x1039, 0x0761, 0, 0, 0, 0, 0, 0,
"gigabyte", "2761gxdk","GIGABYTE","GA-2761GXDK",
it87xx_probe_spi_flash},
{0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000, NULL,
NULL, "GIGABYTE","GA-7VT600",
board_biostar_p4m80_m4},
@@ -842,6 +837,7 @@
{0x1106, 0x0571, 0x1462, 0x7120, 0, 0, 0, 0,
"msi","kt4v","MSI", "MS-6712 (KT4V)",
board_msi_kt4v},
{0x13f6, 0x0111, 0x1462, 0x5900, 0x1106, 0x3177, 0x1106, 0,
"msi","kt4ultra","MSI", "MS-6590 (KT4
Ultra)",board_msi_kt4v},
{0x8086, 0x2658, 0x1462, 0x7046, 0x1106, 0x3044, 0x1462, 0x046d, NULL,
NULL, "MSI", "MS-7046",ich6_gpio19_raise},
+ {0x1106, 0x3099, 0, 0, 0x1106, 0x3074, 0, 0,
"shuttle","ak31","Shuttle", "A
Re: [coreboot] [flashrom] VIA VT8233 support
On Wed, Jun 17, 2009 at 06:56:57PM +0200, Mateusz Murawski wrote: > 00:00.0 0600: 1106:3099 > Subsystem: 1106:3099 > Flags: bus master, medium devsel, latency 0 > Memory at e000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 2.0 > Capabilities: [c0] Power Management version 2 > Kernel driver in use: agpgart-via > > 00:01.0 0604: 1106:b099 (prog-if 00 [Normal decode]) > Flags: bus master, 66MHz, medium devsel, latency 0 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > Memory behind bridge: e600-e7ff > Prefetchable memory behind bridge: e400-e5ff > Capabilities: [80] Power Management version 2 > > 00:09.0 0200: 10ec:8139 (rev 10) > Subsystem: 10ec:8139 > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at d000 [size=256] > Memory at e900 (32-bit, non-prefetchable) [size=256] > [virtual] Expansion ROM at 3000 [disabled] [size=64K] > Capabilities: [50] Power Management version 2 > Kernel driver in use: 8139too > Kernel modules: 8139too, 8139cp > > 00:11.0 0601: 1106:3074 > Subsystem: 1106:3074 > Flags: bus master, stepping, medium devsel, latency 0 > Capabilities: [c0] Power Management version 2 > Kernel modules: i2c-viapro, via-ircc > > 00:11.1 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP]) > Subsystem: 1106:0571 > Flags: bus master, medium devsel, latency 32, IRQ 11 > [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] > [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] > [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] > [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] > I/O ports at d400 [size=16] > Capabilities: [c0] Power Management version 2 > Kernel driver in use: pata_via > Kernel modules: pata_via > > 00:11.2 0c03: 1106:3038 (rev 1b) (prog-if 00 [UHCI]) > Subsystem: 0925:1234 > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at d800 [size=32] > Capabilities: [80] Power Management version 2 > Kernel driver in use: uhci_hcd > > 00:11.3 0c03: 1106:3038 (rev 1b) (prog-if 00 [UHCI]) > Subsystem: 0925:1234 > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at dc00 [size=32] > Capabilities: [80] Power Management version 2 > Kernel driver in use: uhci_hcd > > 00:11.4 0c03: 1106:3038 (rev 1b) (prog-if 00 [UHCI]) > Subsystem: 0925:1234 > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at e000 [size=32] > Capabilities: [80] Power Management version 2 > Kernel driver in use: uhci_hcd > > 00:11.5 0401: 1106:3059 (rev 30) > Subsystem: 1106:4511 > Flags: medium devsel, IRQ 5 > I/O ports at e400 [size=256] > Capabilities: [c0] Power Management version 2 > > 01:00.0 0300: 10de:002d (rev 15) (prog-if 00 [VGA controller]) > Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 > Memory at e600 (32-bit, non-prefetchable) [size=16M] > Memory at e400 (32-bit, prefetchable) [size=32M] > [virtual] Expansion ROM at e700 [disabled] [size=64K] > Capabilities: [60] Power Management version 1 > Capabilities: [44] AGP version 2.0 > For the record, this is the lspci -vn for a Shuttle AK31 V2.0. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Add board-enable for Shuttle AK38N
On Thu, Jun 18, 2009 at 04:50:07AM +0200, Uwe Hermann wrote:
> See patch.
>
> Thanks to Luc Verhaegen and Peter Stuge for help and suggestions on IRC.
>
>
> Uwe.
> --
> http://www.hermann-uwe.de | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
> Add board-enable code for the Shuttle AK38N.
>
> FYI, this board can only decode 256 KB chips (not 512 KB ones) unfortunately.
>
> The it8705f_write_enable() is kept generic enough so it can be reused for
> other
> board-enables, possibly in the board_biostar_p4m80_m4() for example, but that
> shouldn't be touched for now, unless someone can test the code.
>
> Signed-off-by: Uwe Hermann
>
> Index: board_enable.c
> ===
> --- board_enable.c(revision 602)
> +++ board_enable.c(working copy)
> @@ -692,7 +692,25 @@
> return 0;
> }
>
> +static int it8705f_write_enable(uint8_t port, const char *name)
> +{
> + enter_conf_mode_ite(port);
> + sio_mask(port, 0x24, 0x04, 0x04); /* Flash ROM I/F Writes Enable */
> + exit_conf_mode_ite(port);
> +
> + return 0;
> +}
> +
> /**
> + * Suited for Shuttle AK38N: VIA KT333CF + VIA VT8235 + ITE IT8705F
> + */
> +static int it8705f_write_enable_2e(const char *name)
> +{
> + it8705f_write_enable(0x2e, name);
> + return 0;
> +}
> +
> +/**
> * We use 2 sets of IDs here, you're free to choose which is which. This
> * is to provide a very high degree of certainty when matching a board on
> * the basis of subsystem/card IDs. As not every vendor handles
> @@ -747,6 +765,7 @@
> {0x1106, 0x0571, 0x1462, 0x7120, 0, 0, 0, 0,
> "msi","kt4v","MSI", "MS-6712 (KT4V)",
> board_msi_kt4v},
> {0x13f6, 0x0111, 0x1462, 0x5900, 0x1106, 0x3177, 0x1106, 0,
> "msi","kt4ultra","MSI", "MS-6590 (KT4
> Ultra)",board_msi_kt4v},
> {0x8086, 0x2658, 0x1462, 0x7046, 0x1106, 0x3044, 0x1462, 0x046d, NULL,
> NULL, "MSI", "MS-7046",
> ich6_gpio19_raise},
> + {0x1106, 0x3177, 0, 0, 0x1106, 0x3199, 0, 0,
> "shuttle","ak38n", "Shuttle", "AK38N",
> it8705f_write_enable_2e},
> {0x1106, 0x3038, 0x0925, 0x1234, 0x1106, 0x3058, 0x15DD, 0x7609, NULL,
> NULL, "Soyo","SY-7VCA",
> board_soyo_sy_7vca},
> {0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498, NULL,
> NULL, "Tyan","S2498 (Tomcat K7M)",
> board_asus_a7v8x_mx},
> {0x1106, 0x0314, 0x1106, 0xaa08, 0x1106, 0x3227, 0x1106, 0xAA08, NULL,
> NULL, "VIA", "EPIA-CN",
> board_via_epia_sp},
Three things:
* return the value of the it8705f_write_enable in
it8705f_write_enable_2e
* check whether we can match any board ids there.
* please attach lspci -vnn for future reference.
Once done: Acked-by: Luc Verhaegen
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Flashrom support for EPIA-N(L) - patch for review
> No, this is reasonable, i will add an extra comment and commit. Plus some whitespace/formatting changes, and a comment. -> r607. Jon, could you please attach a full lspci -vnn of this board under non-coreboot circumstances for future reference? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Flashrom support for EPIA-N(L) - patch for review
On Fri, Jun 19, 2009 at 12:06:51PM +0100, Harrison, Jon (SELEX GALILEO, UK) wrote: > Received and understood, then the basic issue is that at this point my > coreboot build is still broken and will not boot, so there are no > tables. (I had not realised the tables were read from RAM rather than > the ROM image) > > The upshot is that the flashrom ids are required to allow development > from the original bios for the time being. > > Once the build is booting properly and flashrom can autodetect I will > remove the ids. In the mean time I'm hoping that having this early > flashrom support will help others to help in the effort for the > CN400/epia-n(l)/Luke. > > If this is still all to immature for general release then fair enough, > it can wait until things are working better. > > Thanks, > Jon No, this is reasonable, i will add an extra comment and commit. Plus, i think that we need to track down some badly filled out boards, pciid wise, so that we can change behaviour around the ids a bit. Make it a bit tighter: * require 2 main ids, always. * don't allow -m when a valid subsystem id is there. But that's a discussion for some other time, and anyway, it has a rather tough prerequisite. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Flashrom: board enable for Mitac 6513WU
On Fri, Jun 19, 2009 at 01:57:21PM +0200, Luc Verhaegen wrote: > > Ok, patch going in. > > Luc Verhaegen. -> r609. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Flashrom: board enable for Mitac 6513WU
On Fri, Jun 19, 2009 at 07:38:43AM -0400, Michael Gold wrote:
> On Fri, Jun 19, 2009 at 13:05:49 +0200, Luc Verhaegen wrote:
> > On Fri, Jun 19, 2009 at 02:13:35AM -0400, Michael Gold wrote:
> > > I've also attached the lspci output.
> > >
> > > Why do you think coreboot support is unlikely? Is 82810E support a
> > > problem?
> > >
> > > -- Michael
> >
> > It is a laptop, so yes, quite unlikely. On the other hand, if coreboot
> > support gets added, you probably won't do this board specific rom access
> > disable :)
>
> It's a desktop board with these chips:
> Intel 82810e GMCHe
> Intel 82801AA ICH
> SMSC LPC47U332 super I/O
>
> The manual is at http://www.motherboards.org/files/manuals/78/6513WU.pdf
>
> The 82810e isn't listed as supported on the wiki, but the 82810 is, and
> their datasheets appear largely identical based on a quick look. I was
> hoping to get coreboot running on it.
Ah, i only know mitac as a laptop odm.
In that case, you do not want the coreboot ids because you will
hopefully not set the board specific rom disable in your coreboot code.
> > > + {0x8086, 0x2411, 0x8086, 0x2411, 0x8086, 0x7125, 0x0e11, 0xb165, NULL,
> > > NULL, "Mitac", "6513WU",
> > > board_mitac_6513wu},
> >
> > From your pciids i would use:
> > {0x8086, 0x7125, 0x0e11, 0xb165, 0x125d, 0x1988, 0x0e11, 0xb19d
> >
> > instead, as the first oen uses just a copy of the main ids. 0x0e11 is
> > compaq.
>
> I avoided the 0x125d ID because that's the onboard audio, and there's a
> jumper to disable it. I've now confirmed that the device disappears
> from lspci when that jumper is moved, so I don't think it's an
> appropriate device for autodetection. The other devices on bus 1 (09
> and 0a) are also unusable since those are PCI cards.
Ok, makes sense.
>
> > > 00:01.0 0300: 8086:7125 (rev 03) (prog-if 00 [VGA controller])
> > > Subsystem: 0e11:b165
> >
> > > 01:05.0 0401: 125d:1988 (rev 10)
> > > Subsystem: 0e11:b19d
> >
> > Can you verify this?
>
> I'm not sure what you mean, but those IDs do appear in the config space
> for the devices when lspci's -x flag is used.
>
> -- Michael
Ok, patch going in.
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Flashrom: board enable for Mitac 6513WU
On Fri, Jun 19, 2009 at 02:13:35AM -0400, Michael Gold wrote:
> I've also attached the lspci output.
>
> Why do you think coreboot support is unlikely? Is 82810E support a
> problem?
>
> -- Michael
It is a laptop, so yes, quite unlikely. On the other hand, if coreboot
support gets added, you probably won't do this board specific rom access
disable :)
> + {0x8086, 0x2411, 0x8086, 0x2411, 0x8086, 0x7125, 0x0e11, 0xb165, NULL,
> NULL, "Mitac", "6513WU",
> board_mitac_6513wu},
>From your pciids i would use:
{0x8086, 0x7125, 0x0e11, 0xb165, 0x125d, 0x1988, 0x0e11, 0xb19d
instead, as the first oen uses just a copy of the main ids. 0x0e11 is
compaq.
> 00:01.0 0300: 8086:7125 (rev 03) (prog-if 00 [VGA controller])
> Subsystem: 0e11:b165
> 01:05.0 0401: 125d:1988 (rev 10)
> Subsystem: 0e11:b19d
Can you verify this?
Apart from that:
Acked-by: Luc Verhaegen
and a thumbs up on irc from both Carl-Daniel and Uwe.
Will commit as soon as this is tested.
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Flashrom support for EPIA-N(L) - patch for review
On Thu, Jun 18, 2009 at 01:05:40PM +0100, Harrison, Jon (SELEX GALILEO, UK) wrote: > I didn't mean to suggest that there is anything wroung with flashrom > itself, there is either some issue with reading the coreboot tables from > the coreboot flash after booting from the stock flash (which I have to > do all of the time at the moment) or my coreboot image is broken in some > way ... I've not had the hex editor out (yet) as I'm working more on > getting the initial CN400 work done and personally I am quite happy with > having to -m at this stage of development. > > I was keener to get the flashrom functionality that does work out there, > so that there is a minimum level of functionality available for anyone > else out there that wants to start contributing to the development > effort on this MB. > > Of course this may all turn to be linked .. > On Thu, Jun 18, 2009 at 11:36:49AM +0100, Harrison, Jon (SELEX GALILEO, > UK) wrote: > > > > Auto detection doesn't seem to be working properly and at this stage > I'm > > breaking things so much that the -m switch is necessary for reliable > > operation. > > Why doesn't it seem to work properly? > > Luc Verhaegen. Ok. communication error here. You will only have the coreboot tables when coreboot has succesfully booted and your config has USE_OPTION_TABLE. But... like with many of the other epia boards, you will never disable rom access from coreboot and therefor flashrom does not need to enable specifically for this board. So: * original bios has an extra write disable, but also has subsystem ids. here flashrom should use the subsystem ids to autodetect this board. * coreboot, from reset, should not touch set the board specific disable. So flashrom doesn't need to know or touch this. * when coreboot is ran after the normal bios, the subsystem ids usually still are there, and so is the write protection (if you're plugging chips). Flashrom then should still autodetect through subsystem ids still. So, do you really need flashrom to run the board specific enable when you've booted coreboot? If not, remove the coreboot ids, and also make it impossible for people to randomly try board enables (through the command line) and accidentally hit this code. I am quite happy with the rest of the code though. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Flashrom: board enable for Soyo SY-6BA+III.
On Thu, Jun 18, 2009 at 01:54:32PM +0200, Uwe Hermann wrote: > On Thu, Jun 18, 2009 at 02:47:33AM +0200, Luc Verhaegen wrote: > > > Board enable for soyo sy-6ba+iii. > > > > This board enable drops GPO26 on the southbridge (PIIX4). Since there > > was another board raising GPO22 on the same southbridge, a general > > routine was created reducing both board enables to a single line. > > > > This routine does full gpo pin checking and filters out those which > > are most likely in use already, enables dual-function gpo pins properly, > > and then sets the relevant gpo line. It should be fully implemented for > > all gpo setting on PIIX4, except when a supposed used gpo pin does happen > > to be available for gpio. > > > > The board itself predates proper subsystem id usage and can therefor not > > be autodetected. > > > > Signed-off-by: Luc Verhaegen > > With the changes below: > Acked-by: Uwe Hermann Sadly, we then found out on irc that this was not needed. I should chase down the owner of the epox board and see wether he can test this. Thanks for the thorough review though, i hope the main function can still make it in. > Nice! > > This also makes the board_epox_ep_bx3() more generic, as the 0x4036 > address might not always be 0x4036 if $SOMETHING (BIOS? OS?) decide?? > to map it elsewhere, correct? Yup, it is a bios decision, so it could be that 0x4000 never moves, but other boards can then also use this board enable when they raise the same pin. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Flashrom: board enable for Mitac 6513WU
On Thu, Jun 18, 2009 at 04:52:13PM -0400, Michael Gold wrote:
> This patch adds code to flashrom to disable write protection on the
> Mitac 6513WU (Compaq OEM) Pentium 3 board. I've tested it by writing
> and verifying an image.
>
> It raises WP# on the FWH via GP30 on the super I/O (SMSC LPC47U332).
> TBL# is hard-wired to VCC on this board.
>
> Signed-off-by: Michael Gold
> Index: util/flashrom/board_enable.c
> ===
> --- util/flashrom/board_enable.c (revision 605)
> +++ util/flashrom/board_enable.c (working copy)
> @@ -693,6 +693,73 @@
> }
>
> /**
> + * Find the runtime registers of an SMSC Super I/O, after verifying its
> + * chip ID.
> + *
> + * Returns the base port of the runtime register block, or 0 on error.
> + */
> +static uint16_t smsc_find_runtime(uint16_t sio_port, uint16_t chip_id,
> + uint8_t logical_device)
> +{
> + uint16_t rt_port = 0;
> +
> + /* Verify the chip ID. */
> + OUTB(0x55, sio_port); /* enable configuration */
> + if (sio_read(sio_port, 0x20) != chip_id) {
> + fprintf(stderr, "\nERROR: SMSC super I/O not found.\n");
> + goto out;
> + }
> +
> + /* If the runtime block is active, get its address. */
> + sio_write(sio_port, 0x07, logical_device);
> + if (sio_read(sio_port, 0x30) & 1) {
> + rt_port = (sio_read(sio_port, 0x60) << 8)
> + | sio_read(sio_port, 0x61);
> + }
> +
> + if (rt_port == 0) {
> + fprintf(stderr, "\nERROR: "
> + "Super I/O runtime interface not available.\n");
> + }
> +out:
> + OUTB(0xaa, sio_port); /* disable configuration */
> + return rt_port;
> +}
> +
> +/**
> + * Disable write protection on the Mitac 6513WU. WP# on the FWH is
> + * connected to GP30 on the Super I/O, and TBL# is always high.
> + */
> +static int board_mitac_6513wu(const char *name)
> +{
> + struct pci_dev *dev;
> + uint16_t rt_port;
> + uint8_t val;
> +
> + dev = pci_dev_find(0x8086, 0x2410); /* Intel 82801AA ISA bridge */
> + if (!dev) {
> + fprintf(stderr, "\nERROR: Intel 82801AA ISA bridge not
> found.\n");
> + return -1;
> + }
> +
> + rt_port = smsc_find_runtime(0x4e, 0x54, 0xa);
> + if (rt_port == 0)
> + return -1;
> +
> + /* Configure the GPIO pin. */
> + val = INB(rt_port + 0x33); /* GP30 config */
> + val &= ~0x87; /* output, non-inverted, GPIO, push/pull */
> + OUTB(val, rt_port + 0x33);
> +
> + /* Disable write protection. */
> + val = INB(rt_port + 0x4d); /* GP3 values */
> + val |= 0x01;/* set GP30 high */
> + OUTB(val, rt_port + 0x4d);
> +
> + return 0;
> +}
> +
> +/**
> * We use 2 sets of IDs here, you're free to choose which is which. This
> * is to provide a very high degree of certainty when matching a board on
> * the basis of subsystem/card IDs. As not every vendor handles
> @@ -742,6 +809,7 @@
> /* Note: There are >= 2 version of the Kontron 986LCD-M/mITX! */
> {0x8086, 0x27b8, 0, 0, 0, 0, 0, 0,
> "kontron","986lcd-m","Kontron", "986LCD-M",
> board_kontron_986lcd_m},
> {0x10ec, 0x8168, 0x10ec, 0x8168, 0x104c, 0x8023, 0x104c, 0x8019,
> "kontron","986lcd-m","Kontron", "986LCD-M",
> board_kontron_986lcd_m},
> + {0x8086, 0x2410, 0, 0, 0x8086, 0x7124, 0, 0,
> "mitac", "6513wu", "Mitac", "6513WU",
> board_mitac_6513wu},
> {0x10de, 0x005e, 0, 0, 0, 0, 0, 0,
> "msi","k8n-neo3","MSI", "MS-7135 (K8N Neo3)",
> w83627thf_gpio4_4_raise_4e},
> {0x1106, 0x3149, 0x1462, 0x7094, 0x10ec, 0x8167, 0x1462, 0x094c, NULL,
> NULL, "MSI", "MS-6702E (K8T
> Neo2-F)",w83627thf_gpio4_4_raise_2e},
> {0x1106, 0x0571, 0x1462, 0x7120, 0, 0, 0, 0,
> "msi","kt4v","MSI", "MS-6712 (KT4V)",
> board_msi_kt4v},
You should be able to get subsystem ids for autodetection and the
likelyhood of this device having actual coreboot support approaches 0.
So please fill out the subsystem ids and/or provide the output of lspci
-vn and remove the coreboot ids.
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Flashrom support for EPIA-N(L) - patch for review
On Thu, Jun 18, 2009 at 11:36:49AM +0100, Harrison, Jon (SELEX GALILEO, UK) wrote: > > Auto detection doesn't seem to be working properly and at this stage I'm > breaking things so much that the -m switch is necessary for reliable > operation. Why doesn't it seem to work properly? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Patch] Flashrom: board enable for Soyo SY-6BA+III.
Board enable for soyo sy-6ba+iii.
This board enable drops GPO26 on the southbridge (PIIX4). Since there
was another board raising GPO22 on the same southbridge, a general
routine was created reducing both board enables to a single line.
This routine does full gpo pin checking and filters out those which
are most likely in use already, enables dual-function gpo pins properly,
and then sets the relevant gpo line. It should be fully implemented for
all gpo setting on PIIX4, except when a supposed used gpo pin does happen
to be available for gpio.
The board itself predates proper subsystem id usage and can therefor not
be autodetected.
Signed-off-by: Luc Verhaegen
Index: board_enable.c
===
--- board_enable.c (revision 602)
+++ board_enable.c (working copy)
@@ -208,6 +208,78 @@
}
/**
+ * Helper function to raise/drop a given gpo line on intel PIIX4*
+ */
+static int intel_piix4_gpo_set(int gpo, int raise)
+{
+ struct pci_dev *dev;
+ uint32_t tmp, base;
+
+ dev = pci_dev_find(0x8086, 0x7110); /* Intel PIIX4 ISA bridge */
+ if (!dev) {
+ fprintf(stderr, "\nERROR: Intel PIIX4 ISA bridge not found.\n");
+ return -1;
+ }
+
+ /* sanity check */
+ if ((gpo < 0) || (gpo > 30)) {
+ fprintf(stderr, "\nERROR: Intel PIIX4 has no GPO%d.\n", gpo);
+ return -1;
+ }
+
+ /* these are dual function pins which are most likely in use already */
+ if (((gpo >= 1) && (gpo <= 7)) ||
+ ((gpo >= 9) && (gpo <= 21)) || (gpo == 29)) {
+ fprintf(stderr, "\nERROR: Unsupported PIIX4 GPO%d.\n", gpo);
+ return -1;
+ }
+
+ /* dual function that need special enable. */
+ if ((gpo >= 22) && (gpo <= 26)) {
+ tmp = pci_read_long(dev, 0xB0); /* GENCFG */
+ switch (gpo) {
+ case 22: /* XBUS: XDIR#/GPO22 */
+ case 23: /* XBUS: XOE#/GPO23 */
+ tmp |= 0x1000;
+ break;
+ case 24: /* RTCSS#/GPO24 */
+ tmp |= 0x2000;
+ break;
+ case 25: /* RTCALE/GPO25 */
+ tmp |= 0x4000;
+ break;
+ case 26: /* KBCSS#/GPO26 */
+ tmp |= 0x8000;
+ break;
+ default:
+ fprintf(stderr, "\nERROR: Unsupported PIIX4 GPO%d.\n",
gpo);
+ return -1;
+ }
+ pci_write_long(dev, 0xB0, tmp);
+ }
+
+ /* GPO {0,8,27,28,30} are always available. */
+
+ dev = pci_dev_find(0x8086, 0x7113); /* Intel PIIX4 PM */
+ if (!dev) {
+ fprintf(stderr, "\nERROR: Intel PIIX4 PM not found.\n");
+ return -1;
+ }
+
+ /* PM IO base */
+ base = pci_read_long(dev, 0x40) & 0xFFC0;
+
+ tmp = INL(base + 0x34); /* GPO register */
+ if (raise)
+ tmp |= 0x01 << gpo;
+ else
+ tmp |= ~(0x01 << gpo);
+ OUTL(tmp, base + 0x34);
+
+ return 0;
+}
+
+/**
* Suited for VIAs EPIA M and MII, and maybe other CLE266 based EPIAs.
*
* We don't need to do this when using coreboot, GPIO15 is never lowered there.
@@ -413,18 +485,7 @@
*/
static int board_epox_ep_bx3(const char *name)
{
- uint8_t tmp;
-
- /* Raise GPIO22. */
- tmp = INB(0x4036);
- OUTB(tmp, 0xEB);
-
- tmp |= 0x40;
-
- OUTB(tmp, 0x4036);
- OUTB(tmp, 0xEB);
-
- return 0;
+ return intel_piix4_gpo_set(22, 1);
}
/**
@@ -661,6 +722,16 @@
}
/**
+ * Suited for Soyo SY-6BA+III: i440BX + PIIX4.
+ * Might also work on other SY-6BA+ variations, as there is no superio poking.
+ */
+static int board_soyo_sy_6ba_plus_iii(const char *name)
+{
+ return intel_piix4_gpo_set(26, 0);
+}
+
+
+/**
* Suited for Soyo SY-7VCA: Pro133A + VT82C686.
*/
static int board_soyo_sy_7vca(const char *name)
@@ -747,6 +818,7 @@
{0x1106, 0x0571, 0x1462, 0x7120, 0, 0, 0, 0,
"msi","kt4v","MSI", "MS-6712 (KT4V)",
board_msi_kt4v},
{0x13f6, 0x0111, 0x1462, 0x5900, 0x1106, 0x3177, 0x1106, 0,
"msi","kt4ultra","MSI", "MS-6590 (KT4
Ultra)",board_msi_kt4v},
{0x8086, 0x2658, 0x1462, 0x7046, 0x1106, 0x3044, 0x1462, 0x046d, NULL,
NULL, "MSI", "MS-7046",ich6_gpio19_raise},
+ {0x8086, 0x7190, 0, 0, 0x8086, 0x7110, 0, 0,
"soyo", "sy-6ba+iii", "Soyo",&quo
Re: [coreboot] Flashrom support for EPIA-N(L) - patch for review
On Wed, Jun 17, 2009 at 12:36:41PM +0100, Harrison, Jon (SELEX GALILEO, UK)
wrote:
> Hi Guys,
>
> See below patch for flashrom to add support for EPIA-N(L) Programming.
>
> This has been built against R599 and tested for read, write and verify
> on an EPIA-NL 800
>
> Seems to work for me!
>
> Regards,
> Jon
>
>
> Index: util/flashrom/board_enable.c
> ===
> --- util/flashrom/board_enable.c (revision 599)
> +++ util/flashrom/board_enable.c (working copy)
> @@ -270,6 +270,44 @@
> }
>
> /**
> + * Suited for VIAs EPIA N & NL.
> + */
> +static int board_via_epia_n(const char *name)
> +{
> + struct pci_dev *dev;
> + uint16_t base;
> + uint8_t val;
> +
> + dev = pci_dev_find(0x1106, 0x3227); /* VT8237R ISA bridge */
> + if (!dev) {
> + fprintf(stderr, "\nERROR: VT8237R ISA bridge not
> found.\n");
> + return -1;
> + }
> +
> + /* All memory cycles, not just ROM ones, go to LPC */
> + val = pci_read_byte(dev, 0x59);
> + val &= ~0x80;
> + pci_write_byte(dev, 0x59, val);
> +
> + /* GPIO9 -> output */
> + val = pci_read_byte(dev, 0xE4);
> + //printf("GPO Pin Select Reg = 0x%02X\n", val);
> + val |= 0x20;
> + pci_write_byte(dev, 0xE4, val);
> +
> + /* Get Power Management IO address. */
> + base = pci_read_word(dev, 0x88) & 0xFF80;
> +
> + /* Enable GPIO9 which is connected to write protect. */
> + val = INB(base + 0x4D);
> + //printf("PMM GPIO = 0x%02X\n", val);
> + val |= 0x02;
> + OUTB(val, base + 0x4D);
> +
> + return 0;
> +}
> +
Please use
vt823x_set_all_writes_to_lpc
and
vt823x_gpio_set
I will verify and fix gpio_set for setting other gpio lines than 12-15,
in the next hour or so.
Remove the //printf.
> + {0x1106, 0x0259, 0x1106, 0xaa08, 0x1106, 0x3227, 0x1106,
> 0xAA08, "via","epia-n", "VIA", "EPIA-N/NL",
> board_via_epia_n},
Please remove the coreboot ids. This hardware can be autodetected, and
you should not disable rom access in your upcoming coreboot support, and
therefor will not need this board enable.
So NACK on this first pass, but will ack once issues are addressed, and
once vt823x_gpio_set is fixed.
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: board enable for soyo sy-7vca.
On Wed, Jun 17, 2009 at 03:42:33AM +0100, Andrew Morgan wrote: > Acked-by: Andrew Morgan > > Here's the output from running flashrom after the patch: > > flashrom v0.9.0-r599 > No coreboot table found. > Found chipset "VIA VT82C686A/B", enabling flash write... OK. > Found board "Soyo SY-7VCA", enabling flash write... OK. > Calibrating delay loop... OK. > Found chip "SST SST39SF020A" (256 KB) at physical address 0xfffc. > > > Looks good! Thanks! -> #602 Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] flashrom: board enable for soyo sy-7vca.
Board enable for Soyo SY-7VCA.
Signed-off-by: Luc Verhaegen
Index: board_enable.c
===
--- board_enable.c (revision 599)
+++ board_enable.c (working copy)
@@ -661,6 +661,38 @@
}
/**
+ * Suited for Soyo SY-7VCA: Pro133A + VT82C686.
+ */
+static int board_soyo_sy_7vca(const char *name)
+{
+ struct pci_dev *dev;
+ uint32_t base;
+ uint8_t tmp;
+
+ /* VT82C686 Power management */
+ dev = pci_dev_find(0x1106, 0x3057);
+ if (!dev) {
+ fprintf(stderr, "\nERROR: VT82C686 PM device not found.\n");
+ return -1;
+ }
+
+ /* GPO0 output from PM IO base + 0x4C */
+ tmp = pci_read_byte(dev, 0x54);
+ tmp &= ~0x03;
+ pci_write_byte(dev, 0x54, tmp);
+
+ /* PM IO base */
+ base = pci_read_long(dev, 0x48) & 0xFF00;
+
+ /* Drop GPO0 */
+ tmp = INB(base + 0x4C);
+ tmp &= ~0x01;
+ OUTB(tmp, base + 0x4C);
+
+ return 0;
+}
+
+/**
* We use 2 sets of IDs here, you're free to choose which is which. This
* is to provide a very high degree of certainty when matching a board on
* the basis of subsystem/card IDs. As not every vendor handles
@@ -715,6 +747,7 @@
{0x1106, 0x0571, 0x1462, 0x7120, 0, 0, 0, 0,
"msi","kt4v","MSI", "MS-6712 (KT4V)",
board_msi_kt4v},
{0x13f6, 0x0111, 0x1462, 0x5900, 0x1106, 0x3177, 0x1106, 0,
"msi","kt4ultra","MSI", "MS-6590 (KT4
Ultra)",board_msi_kt4v},
{0x8086, 0x2658, 0x1462, 0x7046, 0x1106, 0x3044, 0x1462, 0x046d, NULL,
NULL, "MSI", "MS-7046",ich6_gpio19_raise},
+ {0x1106, 0x3038, 0x0925, 0x1234, 0x1106, 0x3058, 0x15DD, 0x7609, NULL,
NULL, "Soyo","SY-7VCA",board_soyo_sy_7vca},
{0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498, NULL,
NULL, "Tyan","S2498 (Tomcat K7M)",
board_asus_a7v8x_mx},
{0x1106, 0x0314, 0x1106, 0xaa08, 0x1106, 0x3227, 0x1106, 0xAA08, NULL,
NULL, "VIA", "EPIA-CN",board_via_epia_sp},
{0x1106, 0x3177, 0x1106, 0xAA01, 0x1106, 0x3123, 0x1106, 0xAA01, NULL,
NULL, "VIA", "EPIA M/MII/...", board_via_epia_m},
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] VIA VT8233 support
On Tue, Jun 16, 2009 at 08:38:55PM +0200, Mateusz Murawski wrote: > Hi > Small patch to support VIA VT8233 > > Signed-off-by: Mateusz Murawski The rest of the support code for this board of yours is still waiting on an lspci -vn of this board to this ml. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] it's beginning to occur to people that BIOSes are hackable.
On Mon, Jun 15, 2009 at 11:09:41AM -0500, bari wrote: > There was another article a few years ago on Award: > > http://www.geocities.com/mamanzip/Articles/POST_jump_table_hacking.html This guy wrote a book which is actually hard to come by, and i also believe he did GSoC a few years ago for coreboot. > ron minnich wrote: > >http://www.phrack.org/issues.html?issue=66&id=7#article "For this modification we used a common motherboard (Asus A7V8X-MX)" Urgh. I helped make this trash possible... I feel very dirty now. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte M57SLI-S4 Interrupt Fix
On Thu, Jun 11, 2009 at 01:06:05AM +0200, Luc Verhaegen wrote:
> On Tue, Jun 09, 2009 at 09:18:58PM +0200, Harald Gutmann wrote:
> > Hello,
> >
> > after a few tries of me to fix the interrupt problems which occurred on the
> > M57SLI here is the final patch from me.
> >
> > The Patch fixes the following issues on M57SLI:
> > * Interrupt routing in the MPTable
> >
> > which affects the following hardware parts:
> > * PCI-E 16x Slots (blue and black) - both are working now like a charm
> > * PCI-E 1x Slots - all three should be fine, but I have no card to test.
> > (untested)
> > * PCI Slots - both work fine now.
> >
> > This is the first and (hopefully) the last patch on this issue which gets a
> >
> > Signed-off-by: Harald Gutmann
> >
> > from me.
> >
> > I'm really looking forward to commit this patch (which is my first one) and
> > mark the interrupt issues on the wiki page to the M57SLI as solved. :)
> >
> >
> > Kind regards,
> > Harald Gutmann
> >
> >
>
> > @@ -87,19 +87,17 @@
> > if (res) {
> > smp_write_ioapic(mc, apicid_mcp55, 0x11,
> > res->base);
> > }
> > -
> > - dword = 0x43c6c643;
> > + dword = 0xc643c643;
> > pci_write_config32(dev, 0x7c, dword);
> >
> > - dword = 0x81001a00;
> > + dword = 0x8da01009;
> > pci_write_config32(dev, 0x80, dword);
> >
> > - dword = 0xd0001202;
> > + dword = 0x200018d2;
> > pci_write_config32(dev, 0x84, dword);
> > -
> > }
> > }
> > -
> > +
>
> Anal stuff: while you're here, do get rid of dword :)
>
> > /* The PCIe slots, each on its own bus */
> > - for(j=7; j>=2; j--) {
> > - if(!bus_mcp55[j]) continue;
> > - for(i=0;i<4;i++) { /* map all functions */
> > - PCI_INT(j,0,i, 16+(1+j+i)%4);
> > - }
> > - }
> > +k = 1;
> > +for(i=0; i<=3; i++){
> > +for(j=7; j>=2; j--){
> > +if(k>3) k=0;
> > +PCI_INT(j,0,i, 16+k);
> > +k++;
> > +}
> > +k--;
> > +}
>
> Anal stuff: i<4 and j>1 is easier on the eye :)
>
> >
> > /* On bus 1: the physical PCI bus slots... */
> > - for(j=0; j<2; j++) /* on a Rev 1.x board, they are devs 7 and 8 */
> > - for(i=0;i<4;i++) { /* map all functions */
> > - PCI_INT(1,7+j,i, 16+(3+i+j)%4);
> > - }
> > - /* ... and OB FireWire */
> > - PCI_INT(1,0x0a,0, 18);
> > +k=2;
> > +for(i=0; i<=3; i++){
> > +for(j=6; j<=10; j++){
> > +if(k>3) k=0;
> > +PCI_INT(1,j,i, 16+k);
> > +k++;
> > +}
> > +}
>
> This is the only bit i have a real question about: you remove the comment:
> /* on a Rev 1.x board, they are devs 7 and 8 */
> and have gone from 7+[0,1] to [6,7,8,9,10] for the devices.
>
> While i like the for loops used this way, you are touching devices 6,9,10
> which weren't touched before. What board revision are you using? Could this
> be the difference between your board and what yinghai had? What possible
> effects are there with assigning irqs in the apic to devices which possibly
> aren't there (as i have no clue about apics)?
>
> Please keep at least some of Yinghai's comment and expand this with your
> information.
>
> This is the only question i have with this change, if i see a good answer
> to this, you have:
>
> Acked-by: Luc Verhaegen
>
> Luc Verhaegen.
Apparently the email in the copyright statement was no longer valid.
Yinghai, maybe you should traverse over the tree and adjust it everywhere :)
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte M57SLI-S4 Interrupt Fix
On Tue, Jun 09, 2009 at 09:18:58PM +0200, Harald Gutmann wrote:
> Hello,
>
> after a few tries of me to fix the interrupt problems which occurred on the
> M57SLI here is the final patch from me.
>
> The Patch fixes the following issues on M57SLI:
> * Interrupt routing in the MPTable
>
> which affects the following hardware parts:
> * PCI-E 16x Slots (blue and black) - both are working now like a charm
> * PCI-E 1x Slots - all three should be fine, but I have no card to test.
> (untested)
> * PCI Slots - both work fine now.
>
> This is the first and (hopefully) the last patch on this issue which gets a
>
> Signed-off-by: Harald Gutmann
>
> from me.
>
> I'm really looking forward to commit this patch (which is my first one) and
> mark the interrupt issues on the wiki page to the M57SLI as solved. :)
>
>
> Kind regards,
> Harald Gutmann
>
>
> @@ -87,19 +87,17 @@
> if (res) {
> smp_write_ioapic(mc, apicid_mcp55, 0x11,
> res->base);
> }
> -
> - dword = 0x43c6c643;
> + dword = 0xc643c643;
> pci_write_config32(dev, 0x7c, dword);
>
> - dword = 0x81001a00;
> + dword = 0x8da01009;
> pci_write_config32(dev, 0x80, dword);
>
> - dword = 0xd0001202;
> + dword = 0x200018d2;
> pci_write_config32(dev, 0x84, dword);
> -
> }
> }
> -
> +
Anal stuff: while you're here, do get rid of dword :)
> /* The PCIe slots, each on its own bus */
> - for(j=7; j>=2; j--) {
> - if(!bus_mcp55[j]) continue;
> - for(i=0;i<4;i++) { /* map all functions */
> - PCI_INT(j,0,i, 16+(1+j+i)%4);
> - }
> - }
> +k = 1;
> +for(i=0; i<=3; i++){
> +for(j=7; j>=2; j--){
> +if(k>3) k=0;
> +PCI_INT(j,0,i, 16+k);
> +k++;
> +}
> +k--;
> +}
Anal stuff: i<4 and j>1 is easier on the eye :)
>
> /* On bus 1: the physical PCI bus slots... */
> - for(j=0; j<2; j++) /* on a Rev 1.x board, they are devs 7 and 8 */
> - for(i=0;i<4;i++) { /* map all functions */
> - PCI_INT(1,7+j,i, 16+(3+i+j)%4);
> - }
> - /* ... and OB FireWire */
> - PCI_INT(1,0x0a,0, 18);
> +k=2;
> +for(i=0; i<=3; i++){
> +for(j=6; j<=10; j++){
> +if(k>3) k=0;
> +PCI_INT(1,j,i, 16+k);
> +k++;
> +}
> +}
This is the only bit i have a real question about: you remove the comment:
/* on a Rev 1.x board, they are devs 7 and 8 */
and have gone from 7+[0,1] to [6,7,8,9,10] for the devices.
While i like the for loops used this way, you are touching devices 6,9,10
which weren't touched before. What board revision are you using? Could this
be the difference between your board and what yinghai had? What possible
effects are there with assigning irqs in the apic to devices which possibly
aren't there (as i have no clue about apics)?
Please keep at least some of Yinghai's comment and expand this with your
information.
This is the only question i have with this change, if i see a good answer
to this, you have:
Acked-by: Luc Verhaegen
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: Albatron PM266A board enable.
On Tue, Jun 09, 2009 at 08:48:28AM -0700, ron minnich wrote: > Acked-by: Ronald G. Minnich Thanks, -> #581. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] flashrom: Albatron PM266A board enable.
Add board enable for Albatron PM266A boards.
There are multiple albatron pm266a boards which all share the same bios
image. This means that both the board enable and the subsystem ids are
exactly the same.
The board enable is the same as the epox EP-8K5A2, namely only raising
memw on the superio.
Signed-off-by: Luc Verhaegen
Index: board_enable.c
===
--- board_enable.c (revision 580)
+++ board_enable.c (working copy)
@@ -685,6 +685,7 @@
/* first pci-id set [4], second pci-id set [4],
coreboot id [2], vendor nameboard nameflash enable
*/
{0x8086, 0x1130, 0, 0, 0x105a, 0x0d30, 0x105a, 0x4d33,
"acorp", "6a815epd","Acorp", "6A815EPD",
board_acorp_6a815epd},
{0x1022, 0x746B, 0x1022, 0x36C0, 0, 0, 0, 0,
"AGAMI", "ARUMA", "agami", "Aruma",
w83627hf_gpio24_raise_2e},
+ {0x1106, 0x3177, 0x17F2, 0x3177, 0x1106, 0x3148, 0x17F2, 0x3148, NULL,
NULL, "Albatron","PM266A",
board_epox_ep_8k5a2},
{0x1022, 0x2090, 0, 0, 0x1022, 0x2080, 0, 0,
"artecgroup", "dbe61", "Artec Group", "DBE61",
board_artecgroup_dbe6x},
{0x1022, 0x2090, 0, 0, 0x1022, 0x2080, 0, 0,
"artecgroup", "dbe62", "Artec Group", "DBE62",
board_artecgroup_dbe6x},
{0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL,
NULL, "ASUS","A7V8-MX SE",
board_asus_a7v8x_mx},
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4335 - in trunk/coreboot-v2: src/console src/cpu/amd/dualcore src/cpu/amd/model_fxx src/cpu/amd/quadcore src/cpu/intel/hyperthreading src/include/console src/include/pc80 src/main
On Wed, Jun 03, 2009 at 04:19:34PM +0200, s...@coreboot.org wrote: > Author: libv > Date: 2009-06-03 16:19:33 +0200 (Wed, 03 Jun 2009) > New Revision: 4335 > > Modified: > Log: > Revert "CMOS: Add set_option and rework get_option." > > This reverts commit eb7bb49eb5b48c39baf7a256b7c74e23e3da5660. > > Stepan pointed out that "s" means string, which makes the following statement > in this commit message invalid: "Since we either have reserved space (which > we shouldn't do anything with in these two functions), an enum or a > hexadecimal value, unsigned int seemed like the way to go." > > Signed-off-by: Luc Verhaegen > Acked-by: Luc Verhaegen Not to minimise my own part in this mess, but; several people found it necessary to chime in on a brainfart of mine, but only Peter spent the time reviewing this patch. If people had spent some time reviewing this, then maybe the wrong assumption would've been caught in time. Instead, several people, some of whom should have intimate enough knowledge of the cmos handling, found it necessary to weigh in on a discussion where it was clear that the person who started it (me) wasn't intending on putting his weight behind any code in the very near future anyway. The code that was actually there did get ignored, and with one ACK in the pocket, it ended up getting committed, with this mess as a result. This is where this whole acking system breaks down, and no tool, which will incur even more overhead and less willingness to review, will help, it will only make things worse. And another thing: the option table building tool is some of the worst examples of C code that i have seen in quite a while. Whatever option handling stuff you (whoever you are) are thinking up now, know that it also needs to be implemented, and properly this time, and you better be prepared to do so by yourself. Yes, i am quite miffed. I care about the code i produce and i spent quite some time on this patch, cleaning up several things that weren't ever given a single thought before, providing an actually working integer bit retrieval, trying hard to cover all angles, but apparently i still missed one. So what i got in return is 1 big commit, 1 build breakage with shortly after the fixing commit, then both getting quickly reverted, and i rather dislike this. I do not like to see halfarsed or broken stuff going out, especially not if i am myself responsible for having produced the crap in the first place. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] build service results for r4332
On Wed, Jun 03, 2009 at 01:07:21PM +0200, coreboot information wrote: > Dear coreboot readers! > > This is the automatic build system of coreboot. > > The developer "libv" checked in revision 4332 to > the coreboot repository. This caused the following > changes: > > Build Log: > Compilation of kontron:986lcd-m has been broken > See the error log at > http://qa.coreboot.org/log_buildbrd.php?revision=4332&device=986lcd-m&vendor=kontron&num=2 Should be fixed with r4333. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] CMOS: Add set_option and rework get_option.
On Fri, May 29, 2009 at 04:14:07PM +0200, Luc Verhaegen wrote: > On Fri, May 29, 2009 at 03:48:09PM +0200, Peter Stuge wrote: > > > Acked-by: Peter Stuge > > That was mighty fast :) > > Since this changes "known" behaviour of cmos options, i would prefer at > least a second Ack though, especially since the above reasoning might > not be agreed with fully by all. Since no has provided a secondary ack since friday, i have committed this anyway. -> r4332. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Flashrom: Add gA-k8n-sli board enable.
On Tue, Jun 02, 2009 at 10:43:56PM +0400, Alexander Gordeev wrote: > On Tuesday 02 June 2009 18:13:52 Luc Verhaegen wrote: > > Still needs to be tested by alexander. > > > > Luc Verhaegen. > > WOW, it is working now! Thanks a lot! > > a...@tornado:~/bios$ sudo ../development/flashrom/trunk/flashrom > flashrom v0.9.0-r566 > No coreboot table found. > Found chipset "NVIDIA CK804", enabling flash write... OK. > Found board "GIGABYTE GA-K8N-SLI", enabling flash write... OK. > Calibrating delay loop... OK. > Found chip "PMC Pm49FL004" (512 KB) at physical address 0xfff8. > No operations were specified. > > I also tested read, write, erase and verify operations and rebooted the > machine with the new bios. Everything is ok! > > -- > Alexander Great, thanks! -> r568 Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] CMOS: Add set_option and rework get_option.
On Tue, Jun 02, 2009 at 06:45:28PM +0200, Luc Verhaegen wrote: > On Sat, May 30, 2009 at 11:59:00AM -0400, Kevin O'Connor wrote: > > On Fri, May 29, 2009 at 03:44:28PM +0200, Luc Verhaegen wrote: > > > To ease some of my debugging pain on the unichrome, i decided i needed to > > > move FB size selection into cmos, so i could test a size and then reset it > > > to the default after loading this value so that the next reboot uses the > > > (working) default again. This meant implementing set_option in parallel to > > > get_option. > > > > As an aside, I think long-term coreboot should have a config file in > > flash and use that instead of nvram. > > > > The issues with using nvram: > > > > * it's small and it leads to weird hacks to store data > > You have, iirc, 228 bytes to your disposal. > > Even if we would put all current cmos.layouts on byte boundaries, no-one > would run out of space anyway. > > How would you want to store information, and how would you want to > handle parsing of this information? Do you really want to store > configuration in xml and include an xml parser in a bios? Do you want to > invent your own structured information storage system? If so, what is > wrong with what we do now, especially, since we do not have to reprogram > part of our flash every 5 seconds? > > 228 bytes is plenty if you are not storing whole strings. > > > * the coreboot layout conflicts with the vendor layout and it's a > > pain when switching between coreboot and factory bios > > This is what the board-id-ing and versioning in both cmos and optiom > table will solve. > > > * the batteries frequently get old and nvram storage becomes flaky > > In such a case, too bad, get a new battery and program defaults. > > CMOS is the best part of 256bytes that's available for everyone to use. > It's there, it's free, we know how to access it, we know how to make > very efficient use of it. We can write to it almost infinitely and very > quickly. Sure, you cannot stuff many kBs in there, but how would you use > such space anyway? > > Why not make maximal use of infrastructure/hardware that is freely > available? > > Luc Verhaegen. I cannot help but feel that this is just trying to be different for the sake of trying to be different. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] CMOS: Add set_option and rework get_option.
On Sat, May 30, 2009 at 11:59:00AM -0400, Kevin O'Connor wrote: > On Fri, May 29, 2009 at 03:44:28PM +0200, Luc Verhaegen wrote: > > To ease some of my debugging pain on the unichrome, i decided i needed to > > move FB size selection into cmos, so i could test a size and then reset it > > to the default after loading this value so that the next reboot uses the > > (working) default again. This meant implementing set_option in parallel to > > get_option. > > As an aside, I think long-term coreboot should have a config file in > flash and use that instead of nvram. > > The issues with using nvram: > > * it's small and it leads to weird hacks to store data You have, iirc, 228 bytes to your disposal. Even if we would put all current cmos.layouts on byte boundaries, no-one would run out of space anyway. How would you want to store information, and how would you want to handle parsing of this information? Do you really want to store configuration in xml and include an xml parser in a bios? Do you want to invent your own structured information storage system? If so, what is wrong with what we do now, especially, since we do not have to reprogram part of our flash every 5 seconds? 228 bytes is plenty if you are not storing whole strings. > * the coreboot layout conflicts with the vendor layout and it's a > pain when switching between coreboot and factory bios This is what the board-id-ing and versioning in both cmos and optiom table will solve. > * the batteries frequently get old and nvram storage becomes flaky In such a case, too bad, get a new battery and program defaults. CMOS is the best part of 256bytes that's available for everyone to use. It's there, it's free, we know how to access it, we know how to make very efficient use of it. We can write to it almost infinitely and very quickly. Sure, you cannot stuff many kBs in there, but how would you use such space anyway? Why not make maximal use of infrastructure/hardware that is freely available? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] CMOS: Add set_option and rework get_option.
On Fri, May 29, 2009 at 07:45:18PM +0200, Stefan Reinauer wrote: > On 29.05.2009 16:14 Uhr, Luc Verhaegen wrote: > > > Currently, our security of the cmos value being correct with respect to > > the options table, is the existence of the option name string in the > > optionstable, and the validity of the checksum. We need more than this, > > we need a better way of matching cmos data with the options table. > > > > Why? Example: Run native bios on epia-m. It stops booting, loads the defaults and tells you to go into the config. Alter the config, boot again, and it is happy. Then plug in a coreboot image. It flags that the checksum is invalid, and therefor most of the users of cmos data use a default, yet it continues booting. Alter a single value with nvramtool, and suddenly the cmos checksum is correct. No matter what the other values are. Sometimes you're lucky, but in the epia-m case, you lose serial output (as it suddenly is the lowest value, a value which screen wasn't used to) and seabios tries to boot off the network. All one can do is clear the cmos and then boot properly... What can be done to fix this: 1) track board and version information. 2) add some way to define the default settings in the cmos.layout. Then there are several situations possible. * when a legacy bios was run and the rtc is full of garbage (for us), or when a different board is used, or when the major is different. This should be treated the same way as an invalid checksum. Booting refuses to use it and feeds back defaults (which can also be overridden by code depending on the return value of get_option). Nvramtool can catch this nicely and can offer to fill in defaults, or at least refuse to correct the checksum. * when booting, and when a minor difference between cmos and option table is detected, treat the retrieved information as in the previous point. * when a minor difference between rom option table and cmos.layout is detected, then nvramtool can offer to program the default value of the difference, because it can find out the difference. * when the cmos.layout is for a different board, or of a lower version, then nvramtool should basically refuse to accept it. Also when nvramtool detects invalid values, it can offer to program defaults or at least refuse to validate the checksum. nvramtool should be able to write anything though, through the use of some argument like --force. It should also be able to just set up everything by default. Before any of this is done, the table generation code should get fixed to output more sensible things (why do we dump this to a list of chars in a table?) with things like defines or enums for the values. And we should be able to do checking at boottime as well. I know that this all nontrivial to implement, and that therefor it'll take some time for someone to implement it. But i believe it makes sense, and it will definitely avoid a board booting up with invalid settings, and at least go for defaults. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Flashrom: Add gA-k8n-sli board enable.
On Tue, Jun 02, 2009 at 04:34:14PM +0200, Carl-Daniel Hailfinger wrote: > On 02.06.2009 16:13, Luc Verhaegen wrote: > > Board enable: Gigabyte GA K8N SLI. > > > > Raises bits 0 and 2 on offset 0xE1 in the system control area of the > > nvidia ck804 lpc. > > > > Signed-off-by: Luc Verhaegen > > > > With the comment below addressed, this is > Acked-by: Carl-Daniel Hailfinger > > > > Index: board_enable.c > > === > > --- board_enable.c (revision 564) > > +++ board_enable.c (working copy) > > @@ -372,6 +372,31 @@ > > + base = pci_read_long(dev, 0x64) & 0xFF00; /* System control area */ > > > > base is an I/O port which is restricted to 16 bits on x86 compatible > platforms. Suggestion: > > base = pci_read_long(dev, 0x64) & 0xFF00; > > > Regards, > Carl-Daniel Ok! Still waiting for alexander though, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4323 - trunk/coreboot-v2/src/arch/i386/lib
On Tue, Jun 02, 2009 at 04:37:54PM +0200, Stefan Reinauer wrote: > On 02.06.2009 14:05 Uhr, Luc Verhaegen wrote: > > Is this correct? > > > > Aren't some files supposed to be added and some supposed to be removed > > with this commit? At least i seem to remember something like that from > > the patch that was sent in a week or so ago, and the log message also > > points in this direction. > > > > Luc Verhaegen. > > > > > > check the following two commits. the added / removed stuff is > svn:external'ed in from another repository. (what a pain!) Ah, that's why it didn't show in the git-log of this tree. Sorry for the noise, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Patch] Flashrom: Add gA-k8n-sli board enable.
Still needs to be tested by alexander.
Luc Verhaegen.
Board enable: Gigabyte GA K8N SLI.
Raises bits 0 and 2 on offset 0xE1 in the system control area of the
nvidia ck804 lpc.
Signed-off-by: Luc Verhaegen
Index: board_enable.c
===
--- board_enable.c (revision 564)
+++ board_enable.c (working copy)
@@ -372,6 +372,31 @@
return 0;
}
+/**
+ * Suited for the Gigabyte GA-K8N-SLI: CK804 southbridge.
+ */
+static int board_ga_k8n_sli(const char *name)
+{
+ struct pci_dev *dev;
+ uint32_t base;
+ uint8_t tmp;
+
+ dev = pci_dev_find(0x10DE, 0x0050); /* NVIDIA CK804 LPC */
+ if (!dev) {
+ fprintf(stderr, "\nERROR: NVIDIA LPC bridge not found.\n");
+ return -1;
+ }
+
+ base = pci_read_long(dev, 0x64) & 0xFF00; /* System control area */
+
+ /* if anyone knows more about nvidia lpcs, feel free to explain this */
+ tmp = inb(base + 0xE1);
+ tmp |= 0x05;
+ outb(tmp, base + 0xE1);
+
+ return 0;
+}
+
static int board_hp_dl145_g3_enable(const char *name)
{
/* Set GPIO lines in the Broadcom HT-1000 southbridge. */
@@ -670,6 +695,7 @@
{0x8086, 0x7110, 0, 0, 0x8086, 0x7190, 0, 0,
"epox", "ep-bx3", "EPoX","EP-BX3",
board_epox_ep_bx3},
{0x1039, 0x0761, 0, 0, 0, 0, 0, 0,
"gigabyte", "2761gxdk","GIGABYTE","GA-2761GXDK",
it87xx_probe_spi_flash},
{0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000, NULL,
NULL, "GIGABYTE","GA-7VT600",
board_biostar_p4m80_m4},
+ {0x10DE, 0x0050, 0x1458, 0x0C11, 0x10DE, 0x005e, 0x1458, 0x5000, NULL,
NULL, "GIGABYTE","GA-K8N-SLI", board_ga_k8n_sli},
{0x10de, 0x0360, 0, 0, 0, 0, 0, 0,
"gigabyte", "m57sli", "GIGABYTE","GA-M57SLI-S4",
it87xx_probe_spi_flash},
{0x10de, 0x03e0, 0, 0, 0, 0, 0, 0,
"gigabyte", "m61p","GIGABYTE","GA-M61P-S3",
it87xx_probe_spi_flash},
{0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4391, 0x1458, 0xb000, NULL,
NULL, "GIGABYTE","GA-MA78G-DS3H",
it87xx_probe_spi_flash},
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom touches only 0x70000-0x80000 addresses of my bios flash
On Wed, May 27, 2009 at 02:42:15AM +0400, Alexander Gordeev wrote: > Hi Luc, > > On Tuesday 26 May 2009 14:19:26 you wrote: > > Can you provide the output of lspci -vvnxxx so that we: > > * get device/subsystem id pairs for the board enable table. > > * can spot the location of the pmio base address and make this function > > useful for both cases. > > Sure, attached it. > > -- > Alexander Device: NVIDIA CK804 LPC > 00:01.0 0601: 10de:0050 (rev a3) Dump of some extra io resource areas in pci config space of the lpc: > 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff This is it: ^^ ^^ ^^ ^^ Offset 0xE1 in this "System control area" is where we do our magic. The one in the trac interface uses a different offset in probably the same resource, because it is mcp55 or younger. I will write up a patch for this and send it in.. Luc Verhaegen -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4323 - trunk/coreboot-v2/src/arch/i386/lib
On Fri, May 29, 2009 at 03:08:27PM +0200, s...@coreboot.org wrote: > Author: stepan > Date: 2009-05-29 15:08:27 +0200 (Fri, 29 May 2009) > New Revision: 4323 > > Modified: >trunk/coreboot-v2/src/arch/i386/lib/c_start.S > Log: > drop most of the crappy vm86 code and replace it with a rewritten > version that has all assembler in a .S file and all C code in a .c > file. Also, remove requirement to move around between GDTs. > > This version includes the suggestions from Peter to clean up CR0 manipulation > and to guard critical code paths by cli/sti. Tested and working on my > hardware. > > Signed-off-by: Stefan Reinauer > Acked-by: Peter Stuge > > > > Modified: trunk/coreboot-v2/src/arch/i386/lib/c_start.S > === > --- trunk/coreboot-v2/src/arch/i386/lib/c_start.S 2009-05-29 03:44:47 UTC > (rev 4322) > +++ trunk/coreboot-v2/src/arch/i386/lib/c_start.S 2009-05-29 13:08:27 UTC > (rev 4323) > @@ -253,7 +253,7 @@ > > /* This is the gdt for GCC part of coreboot. >* It is different from the gdt in ROMCC/ASM part of coreboot > - * which is defined in entry32.inc */ > + * which is defined in entry32.inc */ /* BUT WHY?? */ > gdt: > /* selgdt 0, unused */ > .word 0x, 0x /* dummy */ > @@ -275,6 +275,13 @@ > .word 0x, 0x /* dummy */ > .byte 0x00, 0x00, 0x00, 0x00 > > + /* selgdt 0x28 16-bit 64k code at 0x */ > + .word 0x, 0x > + .byte 0, 0x9a, 0, 0 > + > + /* selgdt 0x30 16-bit 64k data at 0x */ > + .word 0x, 0x > + .byte 0, 0x92, 0, 0 > gdt_end: > > idtarg: Is this correct? Aren't some files supposed to be added and some supposed to be removed with this commit? At least i seem to remember something like that from the patch that was sent in a week or so ago, and the log message also points in this direction. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] CMOS: Add set_option and rework get_option.
On Fri, May 29, 2009 at 04:16:33PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > That was mighty fast :) > > I read it through and I liked it. :) > > A quick suggestion would be this: > > Or store a 32 bit CRC in NVRAM, calculated from a canonicalized form > of the cmos.layout contents. Yeah, that would be a good solution for checking the validity too. > Versioning is nice - but do we need it? I think this nvram stuff is > the most infrequent changing part of all of coreboot. To be absolutely honest, i was just spewing some thoughts, my itch is scratched with this patch, i have what i needed for my board, and i see it less likely that i will implement this than that i will fix up the TODOs in vga_console.c :) Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] CMOS: Add set_option and rework get_option.
On Fri, May 29, 2009 at 03:48:09PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > From 261d18b8825a849d6e7b678294cf13ede5f0e8c9 Mon Sep 17 00:00:00 2001 > > From: Luc Verhaegen > > Date: Fri, 29 May 2009 15:18:33 +0200 > > Subject: [PATCH] CMOS: Add set_option and rework get_option. > > > > To ease some of my debugging pain on the unichrome, i decided i needed to > > move FB size selection into cmos, so i could test a size and then reset it > > to the default after loading this value so that the next reboot uses the > > (working) default again. This meant implementing set_option in parallel to > > get_option. > > > > get_option was then found to have inversed argument ordering (like outb) and > > passing char * and then depending on the cmos layout length, which made me > > feel quite uncomfortable. Since we either have reserved space (which we > > shouldn't do anything with in these two functions), an enum or a > > hexadecimal value, unsigned int seemed like the way to go. So all users of > > get_option now have their arguments inversed and switched from using ints > > to unsigned ints now. > > > > The way get_cmos_value was implemented forced us to not overlap byte and to > > have multibyte values be byte aligned. This logic is now adapted to do a > > full uint32_t read (when needed) at any offset and any length up to 32, and > > the shifting all happens inside an uint32_t as well. set_cmos_value was > > implemented similarly. Both routines have been extensively tested in a > > quick separate little program as it is not easy to get this stuff right. > > > > build_opt_tbl.c was altered to function correctly within these new > > parameters. The enum value retrieval has been changed strol(..., NULL, 10) > > to stroul(..., NULL, 0), so that we not only are able to use unsigned ints > > now but so that we also interprete hex values correctly. The 32bit limit > > gets imposed on all entries not marked reserved, an unused "user_data" field > > that appeared in a lot of cmos.layouts has been changed to reserved as well. > > > > Signed-off-by: Luc Verhaegen > > Acked-by: Peter Stuge That was mighty fast :) Since this changes "known" behaviour of cmos options, i would prefer at least a second Ack though, especially since the above reasoning might not be agreed with fully by all. One future change that could be considered is to make build_opt_table no longer spew out a blob of chars. This whole char stuff makes me feel very uncomfortable as well, and the state of and code in build_opt_table.c does not exactly help get rid of that feeling. It would be nice if this program spewed out #define's for options where we now blindly use strings (this makes another issue that i will address later more prominent). It would also be nice if the values of the enums would also be provided in a header file as _, so that we no longer can feed or read invalid data. Currently, our security of the cmos value being correct with respect to the options table, is the existence of the option name string in the optionstable, and the validity of the checksum. We need more than this, we need a better way of matching cmos data with the options table. A quick suggestion would be this: * use 2 shorts of for some sort of board id thingie, so that we can match th with the options table. * use 2 shorts as a major and minor revision number. Both are present in cmos and in the options table, and the values are of course defined in cmos.layout. If the board id differs or the major revision number differs, we should act the same way as if the checksum is invalid: flag the data as invalid to the users of get_option. Minor number should be bumped on additional entries or additional values, so that only newer option tables (from cb tables or from cmos.layout) are allowed by nvram_tool. Thoughts, suggestions? Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Native VGA support.
On Thu, May 28, 2009 at 02:22:41AM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > I could also first cut down vga.h > > Nah. Go ahead. > > Acked-by: Peter Stuge Thanks, committed as r4321, with one change: I noticed that the maximum values in the comments of the vga mode set were off and i fixed them. Thanks! Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Native VGA support.
On Wed, May 27, 2009 at 08:03:56PM +0200, Peter Stuge wrote: > Luc Verhaegen wrote: > > Implement native VGA Support. > > Looks great! Just one question: > > > > --- src/include/pc80/vga.h (revision 4298) > > +++ src/include/pc80/vga.h (working copy) > > @@ -1,228 +1,43 @@ > > /* > > + * Copyright (C) 2007-2009 Luc Verhaegen > > * > > - * modified > > - * by Steve M. Gehlbach > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License as published by the > > Free > > + * Software Foundation; either version 2 of the License, or (at your > > option) > > + * any later version. > > * > > - * Originally from linux/drivers/video/vga16.c by > .. > > Is all the stuff in vga.h useless? Not used anywhere? Would it make > sense to first rm the file and then add your new file instead, for a > cleaner commit? > > > //Peter Mostly useless, yes, only the console code used a very minor part of it. It was a direct copy of the code from the kernel, and no code to back it was actually left in the tree. A cleaner commit would mean a broken state in between, and the resulting vga.h is really rather small and boring. But if a broken in between state is acceptable then sure. If only svn (or whatever - everything has this issue) diff was intelligent enough not to treat "^ *\n" or "^\n" as valid points of comparison, then it would not be an issue here :) I could also first cut down vga.h until only what the console code uses remains and then apply the other one on top. This will mean the best of both i guess. Thanks, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Native VGA support.
On Tue, May 26, 2009 at 03:02:08PM +0200, Luc Verhaegen wrote:
> Since i have some spare time on my hands now (;)) and because ruik
> tickled me, i dusted off some native VGA code i had sitting around since
> 2007.
>
> This is only part of the solution, as the complete thing adds full
> native vga textmodeset support for the VIA CLE266. But i am still trying
> to track down an issue there.
>
> Part of the explanation of this patch is of course in the diff header,
> so read that first, then read on here.
>
> Issue: kernel calls int10 set video mode, and (unless provided by
> something else) consequently assumes that since this hook isn't
> implemented it must be talking to a CGA device. So a message appears
> that the vt is a CGA 80x25, and the character height is assumed to be 8.
> The real character height is 16 though, but the only effect is that you
> have the cursor floating halfway the character, everything else is just
> fine.
>
> Usage: Here is a snippet of the code in my
> northbridge/via/vt8623/unichrome.c .init hook:
>
> +#if CONFIG_VGA == 1
> + /* Now set up the VGA console */
> + vga_io_init(); /* Enable full IO access */
> +
> + unichrome_vga_init(dev);
> +
> + vga_textmode_init();
> +
> +#if CONFIG_CONSOLE_VGA == 1
> + vga_console_init();
> +#endif
> +
> + printk_info("UniChrome VGA Textmode initialized.\n");
> +
> +#if CONFIG_CONSOLE_VGA == 0
> + /* if we don't have console, at least print something... */
> + vga_line_write(0, "UniChrome VGA Textmode initialized.");
> +#endif
> +
> +#endif /* CONFIG_VGA */
>
> TODO's in the vga console code will be dealt with. Right now i want to
> reduce my diff and make the whole more manageable.
>
> Luc Verhaegen.
> Implement native VGA Support.
>
> This code brings a rather complete set of VGA IO routines for whoever wants
> it.
> These consist of the by now familiar read/write/mask sets. Due to the crazy
> nature of VGA, an ancient standard with bits all over the place, it makes no
> sense to define individual registers. You need a vga register spec at hand if
> you want to do anything anyway. These IO routines are always exposed.
>
> It also provides code to natively set up a 640x400 VGA textmode with an 8x16
> font. The native VGA mode code is behind the OPTION_VGA option, as the font
> really adds to the size of the compiled/compressed rom. The font is the one
> also present in the linux kernel, but this file is unlicensed. Another copy of
> this is also present in coreboot in the deprecated console/btext code.
>
> The vga console code has been cleaned up, but it still has some TODO's left
> open, but that's for when i finally have found the remaining issue with the
> epia-m. Right now, it is important to get parts of my work out already and to
> make the remainder managable again.
>
> Signed-off-by: Luc Verhaegen
No takers?
Luc Verhaegen.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Patch] Some fixes to util/vgabios.
On Wed, May 27, 2009 at 11:32:39AM +0200, Stefan Reinauer wrote: > On 27.05.2009 9:39 Uhr, Luc Verhaegen wrote: > > Continuing to clean out my repo. > > > > Luc Verhaegen. > > > Acked-by: Stefan Reinauer > > Stefan Thanks, #4312. Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [Patch] Some fixes to util/vgabios.
Continuing to clean out my repo.
Luc Verhaegen.
>From 83a7542fede9b9b461092cabb69fe99dc5455574 Mon Sep 17 00:00:00 2001
From: Luc Verhaegen
Date: Wed, 27 May 2009 09:33:56 +0200
Subject: [PATCH] util/vgabios: build/warning fixes.
Signed-off-by: Luc Verhaegen
---
util/vgabios/Makefile |9 ++---
util/vgabios/helper_exec.c|5 -
util/vgabios/helper_exec.h|2 ++
util/vgabios/helper_mem.c |6 --
util/vgabios/pci-userspace.c |5 +
util/vgabios/testbios.c |1 +
util/vgabios/x86emu/include/x86emu/regs.h |6 +++---
util/vgabios/x86emu/src/x86emu/sys.c |7 ---
8 files changed, 25 insertions(+), 16 deletions(-)
create mode 100644 util/vgabios/helper_exec.h
diff --git a/util/vgabios/Makefile b/util/vgabios/Makefile
index 5fadba6..c1359bb 100644
--- a/util/vgabios/Makefile
+++ b/util/vgabios/Makefile
@@ -7,11 +7,7 @@
#
CC = gcc
-CFLAGS = -Wall -Ix86emu/include -O2 -g \
- -DLIBPCI_MAJOR_VERSION=2 \
- -DLIBPCI_MINOR_VERSION=1 \
- -DLIBPCI_MICRO_VERSION=11
-
+CFLAGS = -Wall -Ix86emu/include -O2 -g
INTOBJS = int10.o int15.o int16.o int1a.o inte6.o
OBJECTS = testbios.o helper_exec.o helper_mem.o $(INTOBJS)
@@ -20,12 +16,11 @@ LIBS = x86emu/src/x86emu/libx86emu.a
# user space pci is the only option right now.
OBJECTS += pci-userspace.o
-LIBS+= /usr/lib/libpci.a
all: testbios
testbios: $(OBJECTS) $(LIBS)
- $(CC) -o testbios $(OBJECTS) $(LIBS)
+ $(CC) -o testbios $(OBJECTS) $(LIBS) -lpci
helper_exec.o: helper_exec.c test.h
diff --git a/util/vgabios/helper_exec.c b/util/vgabios/helper_exec.c
index 8d18798..3ec2c23 100644
--- a/util/vgabios/helper_exec.c
+++ b/util/vgabios/helper_exec.c
@@ -15,9 +15,12 @@
* on PIO.
*/
#include
+#include "helper_exec.h"
#include "test.h"
-#include
+#include
#include
+#include
+
int port_rep_inb(u16 port, u32 base, int d_f, u32 count);
u8 x_inb(u16 port);
diff --git a/util/vgabios/helper_exec.h b/util/vgabios/helper_exec.h
new file mode 100644
index 000..2657b6e
--- /dev/null
+++ b/util/vgabios/helper_exec.h
@@ -0,0 +1,2 @@
+u32 getIntVect(int num);
+int run_bios_int(int num);
diff --git a/util/vgabios/helper_mem.c b/util/vgabios/helper_mem.c
index be53598..50a303b 100644
--- a/util/vgabios/helper_mem.c
+++ b/util/vgabios/helper_mem.c
@@ -4,6 +4,8 @@
* execute BIOS int 10h calls in x86 real mode environment
* Copyright 1999 Egbert Eich
*/
+#include
+
#define _INT10_PRIVATE
#define REG pInt
@@ -35,7 +37,7 @@ void dprint(unsigned long start, unsigned long size)
printf("%2.2x ", (unsigned char) (*(c++)));
c = d;
for (i = 0; i < 16; i++) {
- printf("%c", u8) (*c)) > 32) && (((u8) (*c)) <
128)) ?
+ printf("%c", unsigned char) (*c)) > 32) &&
(((unsigned char) (*c)) < 128)) ?
(unsigned char) (*(c)) : '.');
c++;
}
@@ -122,7 +124,7 @@ void reset_int_vect(void)
* 64kB. Note that because this data doesn't survive POST, int 0x42
should
* only be used during EGA/VGA BIOS initialisation.
*/
- static const u8 VideoParms[] = {
+ static const unsigned char VideoParms[] = {
/* Timing for modes 0x00 & 0x01 */
0x38, 0x28, 0x2d, 0x0a, 0x1f, 0x06, 0x19, 0x1c,
0x02, 0x07, 0x06, 0x07, 0x00, 0x00, 0x00, 0x00,
diff --git a/util/vgabios/pci-userspace.c b/util/vgabios/pci-userspace.c
index 7578e6f..bc71a61 100644
--- a/util/vgabios/pci-userspace.c
+++ b/util/vgabios/pci-userspace.c
@@ -2,11 +2,16 @@
#include
#include "pci.h"
+#ifdef PCI_LIB_VERSION
+#define LIBPCI_CHECK_VERSION(major,minor,micro) \
+major) << 16) | ((minor) << 8) | (micro)) <= PCI_LIB_VERSION)
+#else
#define LIBPCI_CHECK_VERSION(major,minor,micro) \
( (LIBPCI_MAJOR_VERSION > (major)) || \
(LIBPCI_MAJOR_VERSION == (major) && LIBPCI_MINOR_VERSION > (minor)) || \
(LIBPCI_MAJOR_VERSION == (major) && LIBPCI_MINOR_VERSION == (minor)) && \
LIBPCI_MICRO_VERSION >= (micro) )
+#endif
#define PCITAG struct pci_filter *
diff --git a/util/vgabios/testbios.c b/util/vgabios/testbios.c
index 06f6109..e38315a 100644
--- a/util/vgabios/testbios.c
+++ b/util/vgabios/testbios.c
@@ -11,6 +11,7 @@
#define warn(x) { perror(x); }
#include
+#include "helper_exec.h"
#include "test.h"
#include "pci-userspace.h"
diff --git a/util/vgabios/x86emu/include/x86emu/regs.h
b/util/vgabios/x86emu/include/x86emu/regs.h
index 726b7ac..e77c564 100755
--- a/util/vgab
Re: [coreboot] flashrom touches only 0x70000-0x80000 addresses of my bios flash
On Tue, May 26, 2009 at 12:19:26PM +0200, Luc Verhaegen wrote: > > This is the same as another report (another nvidia board), except for a > different IO offset (0x44C0 + 0x10): > http://tracker.coreboot.org/trac/coreboot/ticket/131 Can anyone with a trac account read the opens...@... email address and include this person in CC. It would be nice the get the following from that guy as well: > Can you provide the output of lspci -vvnxxx so that we: > * get device/subsystem id pairs for the board enable table. > * can spot the location of the pmio base address and make this function > useful for both cases. Thanks, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom touches only 0x70000-0x80000 addresses of my bios flash
On Tue, May 26, 2009 at 02:04:01PM +0400, Alexander Gordeev wrote: > > > Could you please help me to solve this? > > > > We can try. This is the board enable routine for this board (on top of the standard chipset enable): tmp = inb(0x14bf + 0x22); outb(tmp, 0xEB); /* delay */ tmp &= ~0x0F; tmp |= 0x05; outb(tmp, 0x14bf + 0x22); outb(tmp, 0xEB); /* delay */ This is the same as another report (another nvidia board), except for a different IO offset (0x44C0 + 0x10): http://tracker.coreboot.org/trac/coreboot/ticket/131 Can you provide the output of lspci -vvnxxx so that we: * get device/subsystem id pairs for the board enable table. * can spot the location of the pmio base address and make this function useful for both cases. Thanks, Luc Verhaegen. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
