Re: [coreboot] rename LAR to CBAR and LBTABLE to CBTABLE?
On 27.01.2008 03:01, Stefan Reinauer wrote: * Carl-Daniel Hailfinger [EMAIL PROTECTED] [080126 02:28]: while I agree fully with renaming the project, we need to consider the point where we stop the renaming, also because some code referencing our code is outside of our control. We have LBTABLE structures and can rename them to CBTABLE. But will Linux kernel folks merge patches renaming the structs? what code in the linux kernel are you particularly referring to? Linux should be pretty much coreboot agnostic. Didn't the kernel have coreboot table parsing some time in the past? I'm not sure about current Linux code, though. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] PNP logical device handling
Hi all, I have some problem with overwriting of PNP register 0x30. Normally the logical device is enabled when 0x1 is written to register 0x30. This is what pnp_enable_device will do, but Winbond decided that they will abuse this register and put some extra enable bit in it. So, if I have in my lb conf that the logical device is disabled it will overwrite whole register with 0 And if enabled, then with one. I need to leave there 0x9 (yeah it is coincidence that it is also logical number) For further details please check W83627EHF/EHG datasheet - logical device 9 register 0x30 http://www.winbond.com/NR/rdonlyres/A6A258F0-F0C9-4F97-81C0-C4D29E7E943E/0/W83627EHF.pdf The logical device for SPI flash has only bit 1 for enable/disable. Bit 0 is reserved. Question is how to solve that? Would help to ommit 2e.9 off/on in Config.lb? And enable this manually in sio_init in MB specific setup? Thanks, Rudolf -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoreBIOS: a viable option for me?
Peter Stuge wrote: On Sat, Jan 26, 2008 at 08:20:06AM +, Brendan Trotter wrote: Basically, I want to implement code that complies with some sort of Coreboot Specification and know that my code will work for all (past, present and future) versions of Coreboot It would be great if you would help create this. Back in 2005 I started writing up specifications compliant to the according IEEE standards for project management and testing. It's just a start and nowhere near complete, but may be worth a look: http://www.coreboot.org/Distributed_and_Automated_Testsystem Please, if you have time, ideas, contributions, help us to improve those documents. Stuff like this is relevant to get LinuxBIOS into safety critical applications. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 signature.asc Description: OpenPGP digital signature -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] flashrom: use the read function for verifying
On 27.01.2008 05:28, Stefan Reinauer wrote: * Carl-Daniel Hailfinger [EMAIL PROTECTED] [080122 15:59]: Flashrom did not use the read function for verifying, it used direct memory access instead. That fails if the flash chip is not mapped completely. If the read function is set in struct flashchip, use it for verification as well. This fixes verification of all SPI flash chips 512 kByte behind an IT8716F flash translation chip. Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED] looks reasonable, but i could not test it. Acked-by: Stefan Reinauer [EMAIL PROTECTED] Thanks, was already committed in r3070. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH: Add Spansion S25FL016A to flashrom
On 27.01.2008 08:08, Peter Stuge wrote:
On Sun, Jan 27, 2008 at 03:15:58AM +0100, Stefan Reinauer wrote:
#define ID is well tested but I'm not adamant in any way. You're
basically asking for less information in source and more at run
time. I like more info at run time but I still think it would be
nice to have IDs in the code.
Not really less information in the source. Just a single place for
that information. flash.h is the only place where the VENDOR_ID
defines are defined and the array in flashchips.c is the only place
where they are used.
In fact i think it would add information if we replace the
VENDOR_ID defines with strings and drop the DEVICE_ID defines
completely.
{W29C011, WINBOND_ID, W_29C011, 128, 128, ...}
should rather read
{Winbond, W29C011, 0xda, 0xc1, 128, 128, ...}
I like it.
Please don't change this unless you are willing to add support for all
chips mentioned in a #define to flashchips.c. That of course includes
testing.
Right now flash.h is an ID database which helps greatly if you need to
look up an unsupported ID which is already known. Unfortunately no
search engine is able to find data sheets based on the ID, so the
flash.h database is absolutely essential.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxTag 2008 in Berlin, May 28-31
Quoting Corey Osgood [EMAIL PROTECTED]: Peter Stuge wrote: On Fri, Jan 25, 2008 at 07:08:58PM -0500, [EMAIL PROTECTED] wrote: I am certainly interested in exhibiting coreboot. Anyone else? I would love to help but traveling to Germany is out of the question. Let me know if there is anything I can do to help remotely. Last year we had an idea about a competition in the booth, but time did not let it happen. We showcased a few different CPU boards with LB and had the serial output for each board showing on a screen. The idea was to let people guess boot times for one board each day as precisely as we could measure, and have a reset button for visitors to press while they were watching the serial output. I would love to hear other, more fun, competition ideas, but if nothing else surfaces I think I'll try to realize the timer thing this year. :) //Peter A bit off-topic, but this is an idea I've been toying with for a little while now: a web-based interface to see coreboot in action. Somebody visiting the site is presented with an option, to start the machine (most likely QEMU) with either coreboot or the factory BIOS. They can then see the machine start up, and use busybox or bash to do some basic commands, look at the coreboot log, etc. I'm not a real web developer, so I have very little of an idea what it would take to do this, I just think it would be cool. Comments? -Corey That's a pretty cool idea Corey. I am pretty fluent in php / html. I could see something like that working, although I think you would have to account for the overhead. If you have 100 people visiting the site all trying to run the coreboot qemu, the web server would probably choke? Thanks - Joe -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] list headers
On 27.01.2008 06:55, Peter Stuge wrote: On Sun, Jan 27, 2008 at 06:32:42AM +0100, Peter Stuge wrote: Hi Andreas, So, this wasn't really meant for the list. I only saw the list address in To just as I hit send. No problem for me, but; Should we really have a Mail-Followup-To header? The Mail-Followup-To header appears in all mails from you to the list, in all mails from Ward and in one fourth of the mails from Stefan. The mails I got from you which did not go via the list do not have the header. I believe it is what makes my mutt reply command send messages only to the list and never to the original poster - which hasn't happened before. For replying to the list there's an awesome list-reply command. Is the intent of Mail-Followup-To the same as for Reply-To - to help people with non-list-aware mailers to always send messages to the list? In that case I would like to ask that it is removed, elitist as that may seem. If instead my mutt config is just all broken please let me know. (But it has worked very well so far.) Unfortunately, it seems that your mailer (or a filter on your side) inserts the Mail-Followup-To header in the mails you receive and in the mails you send... or there is some really strange interaction between you mailer and the list software. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Donations?
On 27.01.2008 13:49, [EMAIL PROTECTED] wrote: Quoting Peter Stuge [EMAIL PROTECTED]: On Sat, Jan 26, 2008 at 07:00:43PM -0500, Danny Piccirillo wrote: Can random people donate money or hardware to coreboot? I'd love to see a page on the wiki with instructions for people who would like to. This has come up before. When someone wants to donate hardware it's good to ask on the list if anyone is interested in receiving the hardware. We currently don't have any bank account for the project. Can you suggest practical ways to actually handle donations? Paypal AFAIK they subtract quite a sizable amount of money from donations. For a humorous look at this surf to http://ars.userfriendly.org/cartoons/?id=20060703mode=classic Besides that it seems that donation accounts trigger some paypal security machanisms quite often, so the money will be frozen and be held by paypal until they decide you may have it. Some part of their terms and conditions gave them the right to decide such stuff at their sole discretion, no idea whether they changed this. Finally, although they act like a bank, they used a legal loophole to not fall under EU banking regulations and had no EU banking license until July 2007. However, there question about practical ways to handle donations is still open. Is there any service like paypal which has a better record of dealing with customers? Or is paypal the best one of a pack of bad services? I'm not suggesting we avoid paypal at any cost (especially because I'm not going to be the person who handles donations), I'd simply like to understand with how many and how good alternatives we could deal. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PNP logical device handling
On Sun, Jan 27, 2008 at 01:51:15PM +0100, Rudolf Marek wrote: The logical device for SPI flash has only bit 1 for enable/disable. Bit 0 is reserved. I guess bit 3 also reserved? Question is how to solve that? Would help to ommit 2e.9 off/on in Config.lb? And enable this manually in sio_init in MB specific setup? Is this MB-specific? It sounds like it's superio-specific, in which case I guess the superio code should take care of not trashing the register. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] flashrom verify fails, CK804, MCP55
Hi. Both failed, tried with two different BIOS chips. Flashing with AWDFlash works fine though. Had to flash it again in a VIA K8T890 board, which works flawlessly. Any ideas, fix? Best regards, Tiago Marques -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxTag 2008 in Berlin, May 28-31
On Sun, Jan 27, 2008 at 03:01:50PM +0100, Patrick Georgi wrote: When that works, we could provide a .jar file with a demo bios image or something like that, for instant experimentation as java applet. Indeed neat! Do you know if jpc is actively worked on? //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Competition at LinuxTag 2008 in Berlin, May 28-31
On Sun, Jan 27, 2008 at 07:59:33AM -0500, [EMAIL PROTECTED] wrote: I am pretty fluent in php / html. Going back to the competition, we will need a database, an entry form and some way to pick the winner. I think a web based entry form is a good idea. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxTag 2008 in Berlin, May 28-31
On 27.01.2008 16:07, Peter Stuge wrote: On Sun, Jan 27, 2008 at 03:01:50PM +0100, Patrick Georgi wrote: When that works, we could provide a .jar file with a demo bios image or something like that, for instant experimentation as java applet. Indeed neat! Do you know if jpc is actively worked on? Having a target which can be run from a web browser lowers the barrier to entry indeed. However, even though JPC is actively worked on, I doubt we have the resources to port v3 to it and fix the emulator at the same time. Qemu may not be the easiest codebase for adding functionality, but it already works well enough for v2 and v3 modulo a few bugs. If anyone wants to port v3 to JPC or tell the JPC people about coreboot, great! Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] list headers
On Sun, Jan 27, 2008 at 02:53:49PM +0100, Carl-Daniel Hailfinger wrote: Should we really have a Mail-Followup-To header? The Mail-Followup-To header appears in all mails from you to the list, in all mails from Ward and in one fourth of the mails from Stefan. The mails I got from you which did not go via the list do not have the header. Indeed. I believe it is what makes my mutt reply command send messages only to the list and never to the original poster - which hasn't happened before. For replying to the list there's an awesome list-reply command. Is the intent of Mail-Followup-To the same as for Reply-To - to help people with non-list-aware mailers to always send messages to the list? In that case I would like to ask that it is removed, elitist as that may seem. If instead my mutt config is just all broken please let me know. (But it has worked very well so far.) Unfortunately, it seems that your mailer (or a filter on your side) inserts the Mail-Followup-To header in the mails you receive and in the mails you send... Quite right. Mutt adds it by default for subscribed lists. Good discussion at http://cr.yp.to/proto/replyto.html and it's actually not a bad thing. Also it was not the cause of my mistake. I noticed there was a Reply-To header (with the list address) in Andreas' message (but not in messages from others) and that's what steered me and mutt off track. Sorry for the noise. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PNP logical device handling
Peter Stuge napsal(a): On Sun, Jan 27, 2008 at 01:51:15PM +0100, Rudolf Marek wrote: The logical device for SPI flash has only bit 1 for enable/disable. Bit 0 is reserved. I guess bit 3 also reserved? Yes all others are reserved too. Question is how to solve that? Would help to ommit 2e.9 off/on in Config.lb? And enable this manually in sio_init in MB specific setup? Is this MB-specific? It sounds like it's superio-specific, in which case I guess the superio code should take care of not trashing the register. Well yes, it is superio specific. They simply overloaded one logical device with more subdevices. I dont know how to fit this into PNP model. The best would be to ignore this logical device in PNP system config at all and handle the programming in MB specific code. This problem is more general and not MB specific. I can't even fix the code not trashing just whole register. For example the enable for SPI flash is at bit 1 and not bit0, so the generic code can't be used at all. In my case I need bits 0 and 4 set, so fixing the generic code to handle just bit0 would work for me, but not in general - like the SPI logical device. I hope it is more clear now. Imho datasheet at 0x30 says it all ;) Thanks, Rudolf Thanks, Rudolf -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] rename LAR to CBAR and LBTABLE to CBTABLE?
* Carl-Daniel Hailfinger [EMAIL PROTECTED] [080127 15:56]: So if we want to pass any new information to a Linux kernel, we have to teach the bootloader about a new LBTABLE element and the bootloader has to translate that to an e820 section Linux can understand? Painful. e820 is memory description only. You can't really put anything else in there. Most enhanced stuff (HPET) has to be passed via ACPI anyways. Which lead to this dream of mine to have one central data structure which can be used to create acpi, pirq, mptable, dmi/smbios, ... structures from the same consistent source. Via e820? I have some code which keeps all messages from the beginning of CAR up to payload handoff in a local buffer. If anyone wants to write code which copies the buffer to some place where Linux expects it and handles the glue logic, be my guest. e820 is not a solution here. I am not sure. Ron said he had a patch that made linuxbios logs available in linux at some point but i think it got lost. At least I could never find it on the net. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH: Make vendor name optional for flashrom -m
* Peter Stuge [EMAIL PROTECTED] [080127 08:11]: Make the vendor name optional in the -m flashrom parameter when there's only one board name that matches. The full syntax still works, and is required when two vendors have boards with the same names. Signed-off-by: Peter Stuge [EMAIL PROTECTED] Acked-by: Stefan Reinauer [EMAIL PROTECTED] -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: [EMAIL PROTECTED] • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] rename LAR to CBAR and LBTABLE to CBTABLE?
On Sun, Jan 27, 2008 at 05:12:34PM +0100, Stefan Reinauer wrote: Most enhanced stuff (HPET) has to be passed via ACPI anyways. Which lead to this dream of mine to have one central data structure +1 which can be used to create acpi, pirq, mptable, dmi/smbios, ... structures from the same consistent source. ..for now, and later we'll teach Linux to read it directly. In Hamburg we thought the device tree would do it. Does that still hold? //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom verify fails, CK804, MCP55
On Sun, Jan 27, 2008 at 06:06:45PM +, Tiago Marques wrote: On two boards, one MCP55 based and another CK804, if I flash the proprietary BIOS with: flasrom -wv bios.bin Verification fails and if I try to boot, it doesn't. Have to flash the BIOS in another board based on K8T890 that I have. In that one all works fine, with both BIOS chips I have - one winbond and a PMC. Haven't tried flashing coreboot due to lack of support. Since the chipsets are support, this isn't supposed to happen, right? Which board(s)? Which superio? I'm assuming your bios is a plcc chip, not an spi chip? Thanks, Ward. -- Ward Vandewege [EMAIL PROTECTED] Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom verify fails, CK804, MCP55
On 27.01.2008 20:19, Tiago Marques wrote: Yes, PLCC. SuperIO? See http://www.coreboot.org/Superiotool for details. The chips are a w39v040B and a Pm49FL004. Which boards? We need exact vendor name, board name and revision. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom verify fails, CK804, MCP55
On Sun, Jan 27, 2008 at 07:19:55PM +, Tiago Marques wrote: Yes, PLCC. SuperIO? The chips are a w39v040B and a Pm49FL004. What *motherboards*? That will tell us which superio is on the board. Thanks, Ward. -- Ward Vandewege [EMAIL PROTECTED] Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] list headers
Hi Andreas, On Sun, Jan 27, 2008 at 08:04:53PM +0100, Andreas Rudin wrote: I have icedove (thunderbird) as mail client, where I have the possibility to answer a mail with the button reply and reply to all. Oh! Then have a look at this: http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension Therefore it seems that reply to is not configured by the administrator of this list in the mailman options. Right - and it shouldn't be IMO. That's why I have configured icedove for all my mails to this mailinglist to always set the answer to to the mailinglist, as I prefer to just click on the reply to button, when answering mails to a mailinglist. I understand. It is unfortunate that the reply to list functionality has been missing from Thunderbird for so long. It's really helpful. If most of you don't like this, I of course could change it. There is the technical aspect (that reply-to is intended to solve a different problem) and it is even considered harmful when inserted by mailing lists; http://www.unicom.com/pw/reply-to-harmful.html but if you want to keep it I will remember to navigate around it. Personally, I would certainly appreciate if you (and others) did not add a reply-to header with the list address however. Plus, it doesn't really benefit _you_ unless you reply to your own messages which I'm sure does happen now and then just like it does for me, but it is probably not as common as replying to messages from others. :) Thanks for being so receptive in this matter! //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxBIOS/coreboot and security
On Saturday 26 January 2008, Carl-Daniel Hailfinger wrote: Hi Philipp, On 25.01.2008 12:50, Philipp Marek wrote: My question is this. I'd like to secure machines against the people that should work with them [1]. Ah. Classic DRM. DRM does not work. The only use I can think of is a student pool at the university. Do you control (manufacture) the hardware? Even that does not help. Ask M$ about a thing called Ex-box (or so...) There is no easy way to set the bar higher. It will almost always cost you a lot more time to secure a machine than it takes the user to break it. Not if it's under surveillance, like a student's computer pool room, subject to unannounced inspection. In that scenario cases with a single screw have proven themselves. That screw is then chained and locked. HTH, Torsten -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxBIOS/coreboot and security
On Sunday 27 January 2008, Peter Stuge wrote: On Sun, Jan 27, 2008 at 11:32:26PM +0100, Torsten Duwe wrote: DRM does not work. I think this is because it tries to provide an all-encompassing solution to a generic problem. No, because it tries to provide a technical solution to a social phenomenon percieved as a problem. Securing machines against the user is also very generic. If you can be more specific, Phillip, perhaps we can offer some suggestions. Yepp. A defense strategy needs an attack scenario first. Torsten -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxBIOS/coreboot and security
On Sun, Jan 27, 2008 at 11:32:26PM +0100, Torsten Duwe wrote: My question is this. I'd like to secure machines against the people that should work with them [1]. Ah. Classic DRM. DRM does not work. I think this is because it tries to provide an all-encompassing solution to a generic problem. Securing machines against the user is also very generic. If you can be more specific, Phillip, perhaps we can offer some suggestions. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GENFADT and GENDSDT
Urbez Santana Roma wrote: I have not found one tool that can obtain the fadt.c and dsdt.c from the machine trough /proc/acpi/fadt and /proc/acpi/dsdt I have write the two utilities, if one needs it. Urbez. NOTE: you can compile the tools simply written make genfadt and make gendsdt Cool! Can you repost them with a copyright header and Signed-off-by: line (http://www.coreboot.org/Development_Guidelines)? Then I can give them a permanent home in the repos. I'll try them out in a few minutes. Question to others, do we want this to be grabbed by externals, in one repo or the other, or just leave in /utils as a separate checkout (with a wiki page)? Thanks, Corey -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot support for socket 775 mainboards
On Sun, Jan 27, 2008 at 08:55:24PM +0100, Andreas Rudin wrote: It's a fantastic thing you all are doing here and I hope, after having done our first steps with coreboot, we will be able to make some contribution as well. Thank you, and welcome to the project! :) //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r3084 - trunk/util/mptable
Author: cozzie
Date: 2008-01-28 01:04:23 +0100 (Mon, 28 Jan 2008)
New Revision: 3084
Modified:
trunk/util/mptable/mptable.c
Log:
Fix mptable util so the output will compile
Signed-off-by: Jon Dufresne [EMAIL PROTECTED]
Acked-by: Corey Osgood [EMAIL PROTECTED]
Modified: trunk/util/mptable/mptable.c
===
--- trunk/util/mptable/mptable.c2008-01-27 17:25:49 UTC (rev 3083)
+++ trunk/util/mptable/mptable.c2008-01-28 00:04:23 UTC (rev 3084)
@@ -302,10 +302,10 @@
/* preamble to the mptable. This is fixed for all coreboots */
char *preamble[] = {
+#include console/console.h,
#include arch/smp/mpspec.h,
+#include device/pci.h,
#include string.h,
-#include printk.h,
-#include pci.h,
#include stdint.h,
,
void *smp_write_config_table(void *v),
@@ -361,31 +361,35 @@
char *ioapic_code[] = {
smp_write_ioapic(mc, 2, 0x20, 0xfec0);,
{,
- struct pci_dev *dev;,
- uint32_t base;,
- dev = pci_find_slot(1, PCI_DEVFN(0x1e,0));,
+ device_t dev;,
+ struct resource *res;,
+ dev = dev_find_slot(1, PCI_DEVFN(0x1e,0));,
if (dev) {,
- pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, base);,
- base = PCI_BASE_ADDRESS_MEM_MASK;,
- smp_write_ioapic(mc, 3, 0x20, base);,
+ res = find_resource(dev, PCI_BASE_ADDRESS_0);,
+ if (res) {,
+ smp_write_ioapic(mc, 3, 0x20, res-base);,
+ },
},
- dev = pci_find_slot(1, PCI_DEVFN(0x1c,0));,
+ dev = dev_find_slot(1, PCI_DEVFN(0x1c,0));,
if (dev) {,
- pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, base);,
- base = PCI_BASE_ADDRESS_MEM_MASK;,
- smp_write_ioapic(mc, 4, 0x20, base);,
+ res = find_resource(dev, PCI_BASE_ADDRESS_0);,
+ if (res) {,
+ smp_write_ioapic(mc, 4, 0x20, res-base);,
+ },
},
-dev = pci_find_slot(4, PCI_DEVFN(0x1e,0));,
+dev = dev_find_slot(4, PCI_DEVFN(0x1e,0));,
if (dev) {,
-pci_read_config_dword(dev, PCI_BASE_ADDRESS_0,
base);,
-base = PCI_BASE_ADDRESS_MEM_MASK;,
-smp_write_ioapic(mc, 5, 0x20, base);,
+ res = find_resource(dev, PCI_BASE_ADDRESS_0);,
+ if (res) {,
+ smp_write_ioapic(mc, 5, 0x20, res-base);,
+ },
},
-dev = pci_find_slot(4, PCI_DEVFN(0x1c,0));,
+dev = dev_find_slot(4, PCI_DEVFN(0x1c,0));,
if (dev) {,
-pci_read_config_dword(dev, PCI_BASE_ADDRESS_0,
base);,
-base = PCI_BASE_ADDRESS_MEM_MASK;,
-smp_write_ioapic(mc, 8, 0x20, base);,
+ res = find_resource(dev, PCI_BASE_ADDRESS_0);,
+ if (res) {,
+ smp_write_ioapic(mc, 8, 0x20, res-base);,
+ },
},
},
0
@@ -1122,10 +1126,10 @@
};
char* polarityMode[] = {
-conforms, MP_IRQ_POLARITY_HIGH, reserved, MP_IRQ_POLARITY_LOW
+MP_IRQ_POLARITY_DEFAULT, MP_IRQ_POLARITY_HIGH, reserved,
MP_IRQ_POLARITY_LOW
};
char* triggerMode[] = {
-conforms, MP_IRQ_TRIGGER_EDGE, reserved, MP_IRQ_TRIGGER_LEVEL
+MP_IRQ_TRIGGER_DEFAULT, MP_IRQ_TRIGGER_EDGE, reserved,
MP_IRQ_TRIGGER_LEVEL
};
static void
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r3084 build service
Dear coreboot readers! This is the automated build check service of coreboot. The developer cozzie checked in revision 3084 to the coreboot source repository and caused the following changes: Change Log: Fix mptable util so the output will compile Signed-off-by: Jon Dufresne [EMAIL PROTECTED] Acked-by: Corey Osgood [EMAIL PROTECTED] Build Log: Compilation of a-trend:atc-6220 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=atc-6220vendor=a-trend Compilation of abit:be6-ii_v2_0 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=be6-ii_v2_0vendor=abit Compilation of advantech:pcm-5820 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=pcm-5820vendor=advantech Compilation of agami:aruma has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=arumavendor=agami Compilation of amd:db800 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=db800vendor=amd Compilation of amd:norwich has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=norwichvendor=amd Compilation of amd:rumba has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=rumbavendor=amd Compilation of amd:serengeti_cheetah has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=serengeti_cheetahvendor=amd Compilation of amd:serengeti_cheetah_fam10 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=serengeti_cheetah_fam10vendor=amd Compilation of arima:hdama has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=hdamavendor=arima Compilation of artecgroup:dbe61 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=dbe61vendor=artecgroup Compilation of asi:mb_5blmp has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=mb_5blmpvendor=asi Compilation of asus:a8n_e has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=a8n_evendor=asus Compilation of asus:a8v-e_se has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=a8v-e_sevendor=asus Compilation of asus:mew-am has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=mew-amvendor=asus Compilation of asus:mew-vm has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=mew-vmvendor=asus Compilation of asus:p2b has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=p2bvendor=asus Compilation of asus:p2b-f has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=p2b-fvendor=asus Compilation of asus:p3b-f has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=p3b-fvendor=asus Compilation of axus:tc320 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=tc320vendor=axus Compilation of azza:pt-6ibd has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=pt-6ibdvendor=azza Compilation of bcom:winnet100 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=winnet100vendor=bcom Compilation of biostar:m6tba has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=m6tbavendor=biostar Compilation of broadcom:blast has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=blastvendor=broadcom Compilation of compaq:deskpro_en_sff_p600 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=deskpro_en_sff_p600vendor=compaq Compilation of dell:s1850 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=s1850vendor=dell Compilation of digitallogic:adl855pc has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=adl855pcvendor=digitallogic Compilation of digitallogic:msm586seg has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=msm586segvendor=digitallogic Compilation of digitallogic:msm800sev has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=msm800sevvendor=digitallogic Compilation of eaglelion:5bcm has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3084device=5bcmvendor=eaglelion Compilation of emulation:qemu-i386 has been broken See the error log at
Re: [coreboot] GENFADT and GENDSDT
On Sun, Jan 27, 2008 at 07:08:10PM -0500, Corey Osgood wrote: Question to others, do we want this to be grabbed by externals, Isn't utils already externaled into both v2 and v3? Afaik, just the individual utilities are, so we can pick and choose which utilities we want with each repo. Oh - I think that was mostly to be able to exclude some utils that we don't want but don't want to drop. If mptable and getpir are in, these two might as well be too. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On 27/01/08 23:23 -0500, Tom Sylla wrote: ron minnich wrote: If I move the stage2 text address from 0x1000 to 0x2000 (see arch/x86/Makefile: -T 0x1000), I get past the problem. It's dying later but I think I know what that is. But what piece of code is trashing memory at 0x1000? Could it be VSA? If so, do we just go with moving the text address to 0x2000, instead of 0x1000? Well, you might want to take a look at real_mode_switch_call_vsm. I see the code telling it to use real mode address 0:0x1000 as the location for the stack. http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c#L182 Maybe that is why it is getting stomped :) (link is to v2, but the code is the same. Why can't I browse v3 in trac or viewvc?) http://coreboot.org/viewvc/coreboot-v3/?root=coreboot-v3 View coreboot-v3 if you want, then change repository on upper right of screen you must. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On Jan 27, 2008 8:23 PM, Tom Sylla [EMAIL PROTECTED] wrote: Well, you might want to take a look at real_mode_switch_call_vsm. I see the code telling it to use real mode address 0:0x1000 as the location for the stack. http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c#L182 Maybe that is why it is getting stomped :) well, I do manage to frequently confuse myself, but stack grows down, right? If so, 0x1000 is not an issue. First push drops it into below 1000 territory. Also, it's a big blob of zeros, at least 128 of them, starting at 0x1000 and going up. Much more than I expect from errant stack pushes. thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxBIOS/coreboot and security
Hello everybody! On Sunday 27 January 2008, Peter Stuge wrote: On Sun, Jan 27, 2008 at 11:32:26PM +0100, Torsten Duwe wrote: DRM does not work. I think this is because it tries to provide an all-encompassing solution to a generic problem. No, because it tries to provide a technical solution to a social phenomenon percieved as a problem. Securing machines against the user is also very generic. If you can be more specific, Phillip, perhaps we can offer some suggestions. Yepp. A defense strategy needs an attack scenario first. I'm fully aware that *every* security can be broken - it's always a question of how much money/time gets invested (both by the defender, and the attacker). The scenario is to protect the system installation against the user. - Using some operating system unencrypted - boot from a CD. - Protect the boot order - reset the CMOS. - Store important information in the CMOS. That's my thoughts by now. Of course, you'd need a dead-man switch in the case (that deletes the CMOS), but that's available in quite some cases - just connect the cable to the right motherboard position, and you're find (if it's the correct switch - close/open). Simply substituting the BIOS with another one won't be so easy. If it's a notebook, possibly a hardened one, getting to the motherboard might mean some work - and tripping the intrusion detection. All I'm asking for is a BIOS password, that gets stored as a salted hash in a fixed location in the CMOS - then a system installation process can write some generated value there, and use that for harddisk encryption. Securing the hardware is necessary, too - but there coreboot won't help me :-) Thank you for your answers! Regards, Phil -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
