do you want to make this a coreboot target? We can start with that info.
If there is any way for you to run getpir that would help.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I assume you don't want a PIRQ table at all?
In your TARGET config file, e.g.
targets/iwill/dk8s2/Config.lb
add the lines
uses HAVE_PIRQ_TABLE
option HAVE_PIRQ_TABLE=0
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Jan 16, 2008 4:10 AM, Cimino Vittorio [EMAIL PROTECTED] wrote:
I have made a pirq table as show into the web page of the linuxbios.org with
a kernel 2.6.23. The routing table made for the motherboard work, the
request are signaled to the kernel and after to the driver better.
With the
This is the beginning of a set of needed changes to get the geode
running. Comments welcome.
I'll hold off on further patches until people get a look at this and
see if it is ok.
Thanks!
ron
This change is for tidying up some unfinished business in the device code.
I just uncovered this
On Jan 17, 2008 2:32 PM, Ronald Hoogenboom [EMAIL PROTECTED] wrote:
Now I'm looking at how to make the rom_stream read the flash chip like
in the over512k_read_chip.
But I'm a bit stuck on the overal mechanics of the initialization
process and how to get hold of the assigned io port for the
On Jan 17, 2008 11:31 PM, Robinson Tryon [EMAIL PROTECTED] wrote:
The name 'coreboot' is lower-cased on the front page of the wiki, so
it sounds like there is support for both all-lowercase (coreboot) as
well as capitalized (Coreboot).
I just talked to Stefan.
Capitalize as needed. Stefan,
On Jan 18, 2008 9:14 AM, Peter Stuge [EMAIL PROTECTED] wrote:
I think v1 should be completely unchanged. It's neither active nor
supported so I don't think it should have the current name.
I agree.
ron
--
coreboot mailing list
coreboot@coreboot.org
can one of you try to build the ga 2671gxdk and see if it works?
Probably update the version as well.
thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Jan 18, 2008 1:52 PM, Marc Jones [EMAIL PROTECTED] wrote:
ron minnich wrote:
[[[ here comes the bad news ]]]
chipsetinit: Could not find the south bridge!
[[[ damn!]]]
Before VSA:
After VSA:
Finding PCI configuration type.
PCI: Sanity check failed
pci_check_direct failed
This change resolves the earlier report of 'can't find southbridge'
which was due to dev_find_device not being able
to find a device in the static tree.
ron
include/device/device.h
Remove old vendor,device struct members since we are now using the device_id struct.
Change declaration of
pci_sanity_check is confusing. It looks like this:
static int pci_sanity_check(const struct pci_bus_operations *o)
{
u16 class, vendor;
unsigned bus;
int devfn;
struct bus pbus; /* Dummy device */
#define PCI_CLASS_BRIDGE_HOST 0x0600
#define
On Jan 19, 2008 7:58 AM, Peter Stuge [EMAIL PROTECTED] wrote:
It would be really awesome to support the bus natively.
I get this request a lot -- just heard the same comment a few days ago.
We could create a method to do this natively, but would need to create
pci bios tables for linux, or
On Jan 19, 2008 9:48 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
What exactly does stop us from using stage 2 phase 1 for that purpose?
nothing. I will do that.
I will use the coreboot repo for the blob.
Thanks all, you cleared up my thinking.
ron
--
coreboot mailing list
On Jan 19, 2008 5:37 PM, Jordan Crouse [EMAIL PROTECTED] wrote:
Please don't. coreboot is not about the VSA, its not about VGA blobs
or NIC blobs or Bob's random blob. Its about the core boot code. If
it takes an extra step to build the final rom, well, so be it. Write
a script or use an
On Jan 21, 2008 12:34 PM, Stefan Reinauer [EMAIL PROTECTED] wrote:
I recommend u16 device, u16 address. The address can be up to 10 bits
as I understand it
on some versions of smbus. Am I wrong on this however?
I thought a device always has to be struct device? No?
I'm having a slow
On Jan 21, 2008 12:42 PM, Marc Jones [EMAIL PROTECTED] wrote:
I looked at the smbus spec (it is public) and didn't see anything about
10bit address.
http://smbus.org/specs/
SMBus addresses are 7 binary
bits long and are conventionally expressed as 4 bits followed by 3 bits
followed by the
On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Ron?
See my other note, this works but verify did not, which I think you
also just fixed.
The board still does not boot or even POST for me. I am wishing I had
some 512kB parts.
ron
--
coreboot mailing list
On Jan 22, 2008 10:20 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
I'd say we refuse to execute the ROM in v3. If the ROM is broken, we
have no way to determine how broken it is. Unconditional execution may
prevent booting the machine, thereby forcing an out-of-system flash of
coreboot
On Jan 22, 2008 10:46 AM, Peter Stuge [EMAIL PROTECTED] wrote:
Small thing; I would prefer something else than a comma after the
type, so that it is separated from the real information. Maybe:
id=pci:vendor,device;
I think that would make the syntax much more clear.
Thats fine with me, it
brand new shuttle box
phoenix-award bios
keyboard error or no keyboard present
Press F1 to continue
It's just too funny. Imagine a beowulf of these!
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Don't try to register for the hotel just yet, as we are getting the
conf. rate extended to april 6.
But if people could start registering it would help us a great deal
with arrangements.
Also, potential sponsors, please contact me if you can help support
this meeting.
If you can buy a six-pack
OK, with 3073, something went worse.
Last night, I was flashing just fine. As of today, it's not id'ing it
and it is reading 0xff back for that pass. I am attaching a failed
(first) and successfull on the 4mbit part (second half) of the file.
I'm trying to get to the point of trying to figure
Good. now if only ubuntu worked. :-)
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Jan 24, 2008 6:34 AM, Carl-Daniel Hailfinger
What about compression of the VSA?
On v3, we have the 'use compression' option in the Kconfig dialog.
Long term, I intend to use the same compression for vsa that we use
for everything else, and to decompress it as is done in v2, but use
whatever
On Jan 24, 2008 3:23 PM, Peter Stuge [EMAIL PROTECTED] wrote:
On Thu, Jan 24, 2008 at 03:43:31PM -0700, Marc Jones wrote:
For correctness do a read-modify-write of the ROM write-protect area.
Thank you.
Correctly disable the ROM area Write Protect bit in the Geode LX.
signed-off by:
how does stage 2 access LAR? The mem_file struct is an auto (local) for stage1.
void __attribute__((stdcall)) stage1_main(u32 bist)
{
int ret;
struct mem_file archive, result;
int elfboot_mem(struct lb_memory *mem, void *where, int size);
void *entry;
You need
On Jan 25, 2008 10:07 AM, Peter Stuge [EMAIL PROTECTED] wrote:
We were discussing an overlay config - that is applied after the
current Config.lb if specified in an environment variable. Is that
still interesting? Would it solve the problem? I think that's a quick
hack, I could take a look.
On Jan 25, 2008 10:04 AM, Uwe Hermann [EMAIL PROTECTED] wrote:
Yes, this one is per-board instead of per-chipset, but well...
I think we need to get per-chipset settings into per-chipset Kconfigs.
Anything else is going to drive us totally crazy :-)
Let's fix this thing I did which is broken
attached
Add Kconfig files for the northbridge. Currently we only need this for the geodelx,
so we can select nrv2b decompression.
This has been tested in build and behaves as we want it to: nrv decompression
is enabled and the code compiled in.
Signed-off-by: Ronald G. Minnich [EMAIL
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.
coreboot seems to by dying in VSM on some config access as well.
Carl-Daniel pointed out to me:
IIRC there is also a VSM stack which is located in a place differing
from the one clobbered between 0x1000 and 0x2000.
Notice how it blows up exactly at the time where the first virtual PCI
access
This patch needed because some chips (mostly north) can have more than
one function.
patch attached.
ron
In the current version of dtc, if one has the line:
/config/ = northbridge/amd/geodelx;
Then the file northbridge/amd/geodelx/dts is read in and processed.
Magic(TM) appends the name /dts
On Jan 28, 2008 11:18 AM, Jordan Crouse [EMAIL PROTECTED] wrote:
On 28/01/08 11:14 -0800, ron minnich wrote:
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
I don't know buildrom, but you did not need the DISTRO_CFLAGS?
Gah! That will teach me to read the other patches. Did we move
On Jan 28, 2008 3:58 PM, Marc Jones [EMAIL PROTECTED] wrote:
I don't think so. It is coreboot that sets the stack for VSA
initialization. The more I think about it, the stack shouldn't be moved.
Just switch to real mode and VSA can use the same stack as LinuxBIOS
(maybe pad it a little if you
putting vsa in v3 is very simple.
lar -a build/bios.bin your-vsa-file:blob/vsa
That last is a tad confusing, maybe. The part before the : is the unix
pathname. The part after the : is the lar pathname.
Make sure it is blob/vsa, NOT /blob/vsa
To see if it is there,
lar -l build/bios.bin
nice work and congrats. This is neat!
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
here's an interesting bug in
/home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c
/* Dump zeros in the other segment registers */
mov %ax, %es\n
mov %ax, %fs\n
mov %ax, %gs\n
On Jan 28, 2008 10:15 PM, Marc Jones [EMAIL PROTECTED] wrote:
Can you try using vsmsetup.c instead of vm86.c? Something looks strange
in the reporting. ebp 0x6000. Are the variables aligned on the stack
correctly? Is this debug info correct? Are we being mislead?
This looks suspicious in
Another data point.
From my log.
biosint: INT# 0x18
biosint: eax 0x84e53 ebx 0x38 ecx 0xff0 edx 0x87ed8
biosint: ebp 0x6000 esp 0x87f60 edi 0x15 esi 0x0
biosint: ip 0x28 cs 0x1000 flags 0x26
That's just bogus as far as I can tell. Note that edi is 15, kind of looks like
the interrupt.
On Jan 29, 2008 12:00 AM, ron minnich [EMAIL PROTECTED] wrote:
And this is bad too.
in setup_realmode_idt -- both v2 and v3 ...
/* debug handler - useful to set a programmable delay between
instructions if the
TF bit is set upon call to real mode */
idts[1].cs = 0
boy, do I feel dumb!
OK, where do I want to put this page. I am thinking leave it where it
is and move coreboot text up to, e.g., 16K so we have room for this
type of thing in future?
thanks!
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I think the simple thing to do is move the text base up to 0x2000, so
we can move forward with getting the LX working.
ron
Set the text base from 0x1000 to 0x2000, since the emulator needs a page for the IDT.
Signed-off-by: Ronald G. Minnich [EMAIL PROTECTED]
Index: arch/x86/Makefile
I am pretty sure one or both of those targets has serial console
enabled. The next thing to do is boot standard bios on that board,
with linux, hook up serial to a box you know works, run minicom on
each end, and just verify that serial works at all.
Then we can talk about coreboot serial :-)
With this set of changes, the lx target loads VSA and configures the PCI bus,
with VSA operating correctly. This is tested with AMD's recently released
new-model VSA code. Note that v3 build is correctly compressing the uncompressed
vsa payload. I am really happy with v3 so far.
Signed-off-by:
Have you set up serial console? Or is that your question?
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
can you get kermit or some other terminal emulator for windows CE?
just to test?
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Committed revision 571.
I included your svn mv suggestion, and have also removed the pci
biosint support in vsmsetup.c
Thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 1, 2008 1:21 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
- boot with a 4 Mbit chip and switch to the 16 Mbit chip during runtime
That's how I'm doing this -- how swap.
No choice, I don't have a bios on the big parts.
- find out if the chips are wired differently (this includes
On Feb 1, 2008 1:44 PM, Marc Jones [EMAIL PROTECTED] wrote:
How is VSA being compressed and built in? I seem to have missed something.
No, I missed something: it's not being compressed. Oops. That's for buildrom.
./build/util/lar/lar -a build/bios.bin lxvsa:blob/vsa
I could nrv2b encode it by
On Feb 1, 2008 1:47 PM, Jeremy Wright [EMAIL PROTECTED] wrote:
Hi Juergen,
Is it that you don't have the superio (or whatever it's called)
parallel/serial card for the Capio, or does Coreboot not recognize it? I
have the card, I just need to know how to use it for debugging, or even if I
On Feb 1, 2008 2:08 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Why nrv2b? Default compression does work out just fine.
no real reason.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 1, 2008 2:42 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 01.02.2008 23:05, Jeremy Wright wrote:
Can Etherboot load a secondary payload like that?
Sure. I've loaded filo and etherboot with etherboot.
ron
--
coreboot mailing list
coreboot@coreboot.org
Closer ...
it's dying in pci init somewhere. It gets to 0:f.7 and then no more output.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 2, 2008 5:15 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Can we celebrate working memtest? That would be really great.
Any remaining patches in your tree?
memtest fails with some sort of exception. Not sure what yet.
ron
--
coreboot mailing list
coreboot@coreboot.org
it was a minicom/terminal size issue. A big minicom caused memtest to
get a divide by zero. It's running!
It has confusion:
L1 Cache: Unknown | Test #6 [Moving inversions, 32 bit pattern]
L2 Cache: Unknown | Testing: 120K - 256M 255M
but hey ...
ron
--
coreboot mailing
On Feb 2, 2008 5:34 PM, [EMAIL PROTECTED] wrote:
Hello,
Is there a way to run a PCI rom before the PCI bus scan runs???
Yes, we have to do this on any later geode. The LX port should give
you a hint on how it's done.
Thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
turned out the problem was some weirdness between minicom/memtest on
serial. I resized the terminal window that minicom was in and memtest
has been running fine for almost 5 hours.
I also have mode cache enable around so that it happens in
disable_car. This helps a bit. But I still feel we're not
Joe, I think Carl-Daniel is asking: where is the image for the PCI ROM
located? In BIOS flash, as it is on some systems? or on some PCI card?
If on a PCI card, that makes running it before PCI is configured more
interesting. Not impossible, just harder.
ron
--
coreboot mailing list
On Feb 3, 2008 12:52 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
OK, so the PCI ROM is located inside the main system flash. IMO we
should invent a name for such constellations. Off-card ROM?
we pretty much named this already for VGA. It is supported in various
mainboards, via
On Feb 3, 2008 3:26 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Have you tried adding a fillup file to the lar which occupies the
remaing unsused space? That should help a lot.
That's no longer the big time item. The big time item is now the
decompress, which seems to run
at 4
Here is the patch that does not do the move.
Thanks
ron
This change moves the geodelxinit code from stage2 to stage1, which in
turn gets cache turned on much sooner. The system boots a bit faster.
We're still far too slow, perhaps because we are not caching ROM?
Index: arch/x86/Makefile
Add
On Feb 4, 2008 1:48 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Hi Ron,
I really like it. One minor typo in arch/x86/Makefile, rest looks very
good.
Compile tested, no new warnings, no new errors.
Acked-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
I fixed the two //
Committed
So, this is an example of the reason for the (void *) param I was
suggesting some time back. Such needs come up.
One option is to have a convention that globals are at the base of the
stack, rounded to 64k.
e.g. %esp 0x is where globals live.
ron
--
coreboot mailing list
we can provide a function, cycles, in the arch-dependent code. cycles
returns whatever makes sense for the architecture.
Then this patch can be cleaned up.
thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I think we're making this too hard.
Given a CAR address space, starting at CARBASE and ending at CAREND, we
partition it as follows:
bottom 1/2: stack
top 1/2: defined by the Linux log buffer struct.
All done.
ron
--
coreboot mailing list
coreboot@coreboot.org
On Feb 4, 2008 8:47 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
That could work, although in a slightly different way. I would store a
pointer at the base of the stack. That pointer would point to a struct
which has all global info.
sure. At that point it's actually a parameter by
On Feb 4, 2008 11:40 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Are you using top and bottom in the sense of memory addresses or
their place on the stack?
memory addresses.So for example log buf could be 0x8c000 to 0x8 and
stack from 0x8 to 0x8bfff
ron
--
coreboot
Why can't we shadow?
If we never write to the ROM space, at all, why not put the changed
cache settings in right BEFORE we jump to the payload? i.e. don't
change it to slow mode until we no longer need it cached?
thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
On Feb 5, 2008 4:00 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Remember that we load stage 2 like a payload, so we'd have execution
order stage 0,1,3,4,5,2,3,4,5,realpayload.
Not if the stage definition is in main. I realized some time ago that
arch/x86/stage1.c is misnamed (my
Carl-Daniel, you could never irritate me, your comments are too
incredibly useful for that!
let's forget I said anything.
Marc, your proposed patch (pre-payload) is
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
let's try it out.If you can commit I will test tonight or tomorrow night.
ron
--
On Feb 4, 2008 12:54 PM, Jordan Crouse [EMAIL PROTECTED] wrote:
How about the Serengeti-Cheetah on SimNow? Thats a free platform that
everybody can use (and the new public release fixes some of the bugs that
we have discovered).
is the v3 support for this in buildrom? That could be a first
On Feb 6, 2008 5:53 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
I'm very interested in how well v3 compares against v2. The cleanliness
of v3 is great, but if it even comes with better speed, we have a really
strong selling point.
Now there is a nice simple idea. Will try it tonight,
With this patch to FILO:
Index: i386/timer.c
===
--- i386/timer.c(revision 35)
+++ i386/timer.c(working copy)
@@ -105,7 +105,7 @@
return (end - start) * CLOCK_TICK_RATE / (1000*LATCH);
}
-static unsigned long
And it just broke again. Something in phase 6 init is not happening
for some reason.
The cs5536 init is not getting called in phase 6. If somebody wants to
look at the last 30 minutes change log and see what I might have done,
be my guest.
Damn. I hope it is something simple. This is getting
On Feb 7, 2008 11:16 AM, Marc Jones [EMAIL PROTECTED] wrote:
I preferred the v2 way of doing this. If the AMD IDE device was found it
got initialized. I think it needs a DTS and I think other southbridges
with multiple PCI headers will need this too.
So it's more like the northbridge part as
Lar does not currently process bss quite right.
I kind of blame ELF, but see what you think.
Here is filo. These are program headers used in Execution (the 'E' in ELF):
LOAD 0xc0 0x0010 0x0010 0x11430 0x36890 RWE 0x20
LOAD 0x011500 0x001368a0 0x001368a0
We need to start a program. I am thinking I might do a section on
anatomy of the v3 port to LX.
I wonder if any AMD folks could talk about issues relevant to AMD.
FSF -- would be nice to from you.
Anyone at VIA or SiS care to talk?
Intel -- I know you're out there, we'd be happy to see you if
If we want real hardware it is probably going to have to be a cheap via board?
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 7, 2008 12:28 PM, Stefan Reinauer [EMAIL PROTECTED] wrote:
Do we ever want to define devices and compile them in that we don't want
to use?
That's what I can't figure out. I can't recall why that test is there.
ron
--
coreboot mailing list
coreboot@coreboot.org
This patch has LAR create segments for bss.
ron
Fix lar so that it parses .bss section headers.
This is not terribly clean but it works.
Signed-off-by: Ronald G. Minnich [EMAIL PROTECTED]
Index: util/lar/stream.c
===
---
This was easier than I thought :-)
ron
Remove the requirement that all ops have a constructor, since many of them
just use the default.
Signed-off-by: Ronald G. Minnich [EMAIL PROTECTED]
Index: device/device.c
===
---
On Feb 8, 2008 7:53 AM, ron minnich [EMAIL PROTECTED] wrote:
On Feb 8, 2008 3:51 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 08.02.2008 06:54, ron minnich wrote:
This patch (which is NOT signed off) adds (or tries to) PIRQ support
for the alix1c.
it crashes and burns
so far it looks like I have some pretty great speakers, two talks from
AMD, one on the consumer market and another on chipsets; a talk from a
company on a board with an FPGA coprocessor (I'm working on another);
a good chance we'll get a talk from Sun.
I invite others to talk. I think we'd love
The only fully open source implementation of EFI is based on coreboot.
Coreboot + tiano core provides a full open source EFI.
No EFI-based BIOS can make that statement.
Coreboot can reduce the costs of the platform, because
1. no per-unit license
2. distributed support model (same model as
changes to support PIRQ tables. This now builds,runs, loads FILO, and
loads linux.
But interrupts are still not set right. That's for tomorrow.
ron
This set of changes creates irq tables for alix1c and adds the functions
from v2 to install them. Linux boots fine but still doesn't find the
On Feb 8, 2008 11:44 PM, Corey Osgood [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_PIRQ_TABLES
+rom_table_end = write_pirq_routing_table(rom_table_end);
+rom_table_end = (rom_table_end + 1023) ~1023;
+#endif
Should be CONFIG_PIRQ_TABLE?
Yes, I fixed that last night in the second
Here is my suggested copyright notice for the
arch/x86/pirq_routing.c
file
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2000 Ollie Lo, Silicon Integrated Systems
* Copyright (C) 2000 Ron Minnich
* Copyright (C) 2001 Eric Biederman
* Copyright (C) 2002 Andrew Ip
Carl-Daniel, I agree with your comments, will add them, but I need an
ack from *somebody* :-)
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 8, 2008 1:37 PM, Jordan Crouse [EMAIL PROTECTED] wrote:
tha t oldy but
goody, -fno-stack-protector.
we need a patch for filo too, if anyone gets the time.
Wow, all these distros broke ALL standalone programs. I'm proud of them.
ron
--
coreboot mailing list
coreboot@coreboot.org
On Feb 9, 2008 9:40 AM, ron minnich [EMAIL PROTECTED] wrote:
OK, I will look at this dts issue. I wonder if we need a pirq node in the dts?
Well, let's toss some ideas around here. I don't quite know how we
should specify pirq in the dts. Before you join this discussion, be
sure you have read
I think it would be interesting to have a buildrom option for 'build EFI'.
It could fetch tiano core and build an EFI from that. Somebody want to
take this on as a project? It would really be valuable.
Then we could just say oh, you want EFI? It's a simple config option
to the coreboot buildrom
taping is fine but we need people who are coming to start signing up
so we have someone to tape :-)
Depending on how many people we have, I might cancel the room on
saturday and we can just hide out in a coffee shop. We had 50+ people
in santa fe, and a dozen in Hamburg, so it's hard to get a
This patch adds more path support to coreboot and to the dtc.
This support in turn reduces annoying warning messages as coreboot comes up.
ron
These changes extend support for paths for devices.
path.h: add superio path
alix1c/dts: add paths for each component.
device/device_util.c: add
Here's a simple proposal.
Define an option
PRINTK_TSC
What it does: each time printk would print a newline, it will instead
print this:
(16 hex digits of TSC)\n
Here's another simpler option:
Define a new format letter, T, such that %T as a format means time.
first option allows comprehensive
I thought ACPI was a superset of _MP_. I have a friend who claims not:
0x0390 A P I C
Local APIC Address 0xfee0, flags 0x0001
type 0, length 8
ACPI Processor ID 1
APIC ID 0
Flags 0x0001
type 0, length 8
ACPI Processor ID 2
APIC ID 1
Flags 0x0001
type 0, length 8
ACPI
On Feb 9, 2008 2:09 PM, yhlu [EMAIL PROTECTED] wrote:
you are right.
for irq routing:
ACPI: need madt + dsdt
NON ACPI: need mptable
current linux kernel seem could use lapic from ACPI MADT, and other
irq routing for device from MPTABLE...never tried... don't think it
will work other than
On Feb 9, 2008 2:33 PM, Ronald Hoogenboom [EMAIL PROTECTED] wrote:
-- During coreboot 'Initializing devices', the following is printed:
rom address for PCI: 07:00.0 = f700
Incorrect Expansion ROM Header Signature
Hmm. that's bad. :-)
-- The VGA card is on PCI bus 07 according to
On Feb 9, 2008 9:23 PM, Peter Stuge [EMAIL PROTECTED] wrote:
Should the Signed-off-by: procedure be used also for the openvsa repo?
Once it settles in for sure, but for now, it's pretty much one guy.
ron
--
coreboot mailing list
coreboot@coreboot.org
On Feb 9, 2008 9:21 PM, Peter Stuge [EMAIL PROTECTED] wrote:
It should be simple enough to get the type if struct property had
a struct node *node; member so that the owner-parent node could
be reached from within the property foreach loop.
it's there. but that doesn't totally tell you what
On Feb 9, 2008 9:51 PM, yhlu [EMAIL PROTECTED] wrote:
and linux kernel will use ACPI table with DSDT and use MP Table to get
irq routing for devices.
So that means that ACPI is not a superset of _MP_. If you need both
tables, then ACPI can not be a proper superset.
Which means we can not
1 - 100 of 3036 matches
Mail list logo
