On Tue, Apr 5, 2011 at 9:38 AM, Joseph Smith wrote:
> Yeah and Intel is great at only giving you half the picture ;-)
If you have half the picture you're doing unusually well :-)
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Sun, Dec 18, 2011 at 1:04 AM, nap wrote:
> The problem is the family is 06 and model 17 (hexadecimals), not
> directly compatible with the model_xx convention used so far. I don't
> know how deep is going this convention into coreboot.
>
it's a convention. If we can't take an arbitrary name t
> + /* It isn't safe to enable multiple VGA cards.
> + * Windows will report resource conflict when more than one
> + * VGA-compatible legacy graphic card in the system.
> + */
> +#if CONFIG_VGA_BRIDGE_SETUP == 1
> + extern de
On Sun, Dec 18, 2011 at 10:01 PM, She, Kerry wrote:
> Hello, Ron
>
>> I asked:
>> What do Linux or *BSD do in the same situation? Do they handle it cleanly?
> Linux VGA Arbiter module(vgaarb) will handle this explicitly.
> So dual vga card would works together, even coreboot not disable IO& MEM
>
I'm just getting back to coreboot. Is libpayload used verbatim in the
kernel? The phys/virt map in coreboot is 1:1 by design. The mapping
seems unnecessary to me. Just wondering.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Dec 29, 2011 at 10:03 AM, Philip Prindeville
wrote:
> What's the difference between that VSA file and the amd_vsa_lx.bin that's in:
>
> svn://coreboot.org/vsa/trunk/gplvsa2
probably not much. It's been years since I did geode work.
You need to add the vsa to the image by hand, at least
They're going to differ because the values of those registers depend
on how things are wired up.
I'd be careful about changing that sort of thing. It drove me crazy.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Jan 5, 2012 at 6:56 PM, Philip Prindeville
wrote:
> Also, the Alix 6F2 doesn't have a keyboard controller... is there a way to
> turn off the i8042 stuff?
it used to be as simple as not putting pc80/keyboard or some such in
the mainboard Config. I'll look tomorrow if I get time.
ron
-
It's almost certainly impossible to get coreboot going on your T60.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, Jan 17, 2012 at 1:51 PM, Peter Stuge wrote:
> ron minnich wrote:
>> It's almost certainly impossible to get coreboot going on your T60.
>
> I believe Sven's port is working!
on x60, good news. But T60?
ron
--
coreboot mailing list: coreboot@coreboot.or
On Tue, Jan 17, 2012 at 4:22 PM, Peter Stuge wrote:
> Yes, also. Sven is using it on his machine already. It needed some
> more work besides the X60, but it works for him.
I am in awe of these accomplishments! Geez, I go away for just a
little while and these great things happen :-)
ron
--
co
Ali, you've changed ram setup code. Ram setup is probably the single
hardest thing to get right. It can take a year. You need to let people
see your code before any one can help you.
It's very common for a new port to pass a ram test and fail in actual
use. Just about everyone who has done a port
reading your note leads me to believe you are not familiar with how
sdram startup works. It's a lot more than just setting one register.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
we worked a few years back to remove all __asm__ stuff from coreboot
because it has so many tricky parts to making it work. If you're going
to write assembly, put it in a .s. a .c file should have C.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/cor
you commented out a number of calls to critical functions. You can't
just simply set a register and assume it all works. Maybe I
misunderstood.
I think stepan's i945 code is a great example of how to turn on dram.
Or you can look at sdram_enable in the lx440 code for the basic sdram
startup cycle
For problems at this level with qemu I would usually use Bochs with
debug enabled so I could watch every instruction. You might want to
try that.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I'm seeing the ld problem on all my linux systems.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
The solution in other projects I have worked on is to have an
initialized struct and just copy it at runtime to the right place.
This gets around all the issues with ld (which have been issues in
various ways for 12 years now ... just different ones :)
How big are the tables? If they're not that b
we would need to track down the first appearance of the IPI code and
try to figure out why it's there. I just don't recall.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, Mar 13, 2012 at 1:13 PM, Kyösti Mälkki wrote:
> Seems like the patch just appeared and was merged without any
> discussion. It would have been nice to describe the circumstances under
> which Intel Core Duo failed...
Assuming one is allowed to. Keep in mind that there are changes that
go
we made a decision in the early days to NOT include the chip part name
in the function names. This was not a mistake or omission, it was a
deliberate design choice.
The reason to name things this way is because a board is composed of a
set of parts, and the partname is in the file name path. Hence
On Tue, Mar 20, 2012 at 4:58 AM, Kyösti Mälkki wrote:
> Bootblock is special, probably for simplicity the chip objects were
> dropped. BTW: There are boards with two super-ios.
the objects were never used because this was usually a romcc-based
stage. And, yes, there are boards with two super-ios
On Tue, Mar 27, 2012 at 2:23 AM, ali hagigat wrote:
> My RAM code was OK(I remember all the members of this mailing list
> said:"your RAM initialization is not OK", if RAM is not OK how
> "romstage", "ramstage" and now "filo" are being executed!!
I've had this work with RAM that is not OK.
> Now
On Wed, Apr 4, 2012 at 10:53 AM, Patrick Georgi wrote:
> The linker should kick it out again. I oppose having a config flag for
> every single source file.
by analogy, there is a huge amount of code compiled into glibc that I
don't use. It's the compilers/linkers job to not build in those things
On Thu, Apr 5, 2012 at 4:58 PM, Peter Stuge wrote:
> Stefan Reinauer wrote:
> Maybe it should be made clear also in the names that these tags are
> chromeos specific?
I don't think we should. I am hoping that some other vendor will
figure out how neat these things are and use them too.
ron
--
On Fri, Apr 6, 2012 at 11:12 AM, Marc Jones wrote:
>> 3. Microcode updates
>>
>> The "tiny" bootblock doesn't seem like the correct place for microcode
>> updates.
>>
>
> Does microcode have to be this early? Before CAR?
Yes. Some history. We started out doing microcode updates in linux.
Then it
I'm trying an experiment and I welcome anyone who wants to help.
It's a simple idea motivated by a very hard problem. The problem is
that we have unending problems with binary video bioses. We'd like to
get to a source based video bios on, e.g., chromebook.
The linux driver for the intel i915 ser
On Mon, Apr 9, 2012 at 11:42 AM, Peter Stuge wrote:
> I think it's a good approach. I would like having separate
> repositories for our tools, but for now adding one more is
> not making the problem worse I guess.
OK, what I will do for now is put it on code.google.com and, when we
think it's re
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 m
On Sun, Apr 15, 2012 at 3:49 PM, Carl-Daniel Hailfinger
wrote:
> Am 15.04.2012 04:57 schrieb ron minnich:
> It's a slippery slope, though. We call the blob from coreboot and expect
> it to return to coreboot (whether the return is a JMP/RET/... doesn't
> matter). Unless I&#
On Mon, Apr 16, 2012 at 5:06 PM, Kevin O'Connor wrote:
This has been done for Geode vga. I'm not familiar
> with the i915 chipset, but there's a chance that you just need to copy
> the C initialization code over.
no, it's quite complex, especially when you take the aux/ddc channel
into account a
On Jan 18, 2008 9:20 AM, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> Suggestions for the new name?
something that maybe is easier to say?
fixcmos?
:-)
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Jan 18, 2008 8:13 AM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> In addition to that, I left some occurences of the name in LANL license
> headers.
>
I recommend not touching those LANL headers.
thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/lis
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
http://www.coreboot.org/mailman/listinf
With the as-yet uncommitted patch I just posted, we're getting much
better results. My comments in [[[]]]
LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting...
Choosing fallback boot.
LAR: Attempting to open 'fallback/initram/segment0'.
LAR: Start 0xfff8 len 0x8
LAR: seen member normal/
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:
> >
On Jan 18, 2008 6:49 AM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> I have a mad scheme which would work for v3 without downsides (except
> for the fact that the boot block and initram have to be in the upper 512
> kB, but that's the case anyway even without my scheme).
> Basically, we cr
On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> Is this same situation as before or is it worse? If it is worse, please
> try to fix before you commit.
The fix is going to be a bit harder, so I am committing this now.
Committed revision 557.
One thing to add. I am p
Marc, should we modify the LX build to somehow wget the VSA and copy
it in to LAR? Or should we have a top-level "blob" directory in v3
that includes the vsa file, and then build it in to LAR?
I am thinking it is now time to solve the VSA problem, and LAR is the key piece.
Also, it looks like we
On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> Is this same situation as before or is it worse? If it is worse, please
> try to fix before you commit.
> Could it be that we try to find the south bridge by PCI ID and the VSA
> is needed for that?
I figured it out. The
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 dev_find_
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 PCI_CLASS_DISPL
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 c
On Jan 19, 2008 8:18 AM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> On 19.01.2008 07:39, ron minnich wrote:
> > Marc, should we modify the LX build to somehow wget the VSA and copy
> > it in to LAR? Or should we have a top-level "blob" directory in v3
>
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
coreboo
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 us
On Jan 21, 2008 10:12 AM, Marc Jones <[EMAIL PROTECTED]> wrote:
> > ./include/device/smbus.h:int smbus_read_byte(struct device *dev, u8 addr);
> > ./device/smbus_ops.c:int smbus_read_byte(struct device *dev, u8 addr)
> > (introduced in r307)
> >
> > ./include/lib.h:int smbus_read_byte(unsigned dev
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 havin
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
> followe
On Jan 21, 2008 1:14 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
===
> --- LinuxBIOSv3.orig/include/lib.h 2008-01-11 15:52:52.0 -0700
> +++ LinuxBIOSv3/include/lib.h 2008-01-11 16:04:12.0 -0700
> @@ -36,11 +36,4 @@
Just FYI, some luck writing this chip on the sis board ...
The write had no errors. The -v failed. But on using the -r to read to
a file, I find
no differences between the file used for -w and the file used for -v!
Next is to try to actually put the vga bios onto the image and see if,
this time,
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
coreboot@c
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
> cor
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
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 of
here's a positive note, it works fine for me on fc8.
[EMAIL PROTECTED] ga_2761gxdk]$ ld -v -v
GNU ld version 2.17.50.0.12-4 20070128
GNU ld version 2.17.50.0.12-4 20070128
[EMAIL PROTECTED] ga_2761gxdk]$ gcc -v -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --pref
It fails on ubuntu. I just did an svn up and:
nput/output = 130304/53382 = 2.441
cp coreboot_ram.nrv2b coreboot_ram.rom
echo '/*ldoptions*/' > ldscript.ld; cat ldoptions >> ldscript.ld ; for
file in /home/rminnich/src/bios/coreboot-v2/src/arch/i386/init/ldscript.lb
/home/rminnich/src/bios/coreboo
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 out
On Jan 22, 2008 5:33 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> Besides the obvious stuff (storing the VSA as a file in the LAR) there
> are two points to solve which are rather interesting:
> - Entry point specification
> - Load address specification
> Both are not trivial because we
These are incomplete and will continue to evolve, but I want to see if
I can get it working at all.
attached.
ron
This is a first cut at the implementation of VSM support. What has do be done, long term,
is to remove almost all of the vsmsetup.c file and use functions in the vm86.c file.
The b
On Jan 23, 2008 11:06 AM, Marc Jones <[EMAIL PROTECTED]> wrote:
> BUT, I don't think that you need them. VSA should default to reasonable
> settings without the in15 calls. I need to test it in v2 this afternoon.
> If VSA does require them I would rather change VSA. There is no reason
> it can't g
On Jan 23, 2008 5:09 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
>
> I didn't get to test this today but I will first thing in the AM.
OK, the code I sent won't run, the only test I have done so far is compiole.
rn
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/list
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 c
On Jan 24, 2008 10:06 AM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
===
> > --- northbridge/amd/geodelx/vsmsetup.c(revision 0)
> > +++ northbridge/amd/geodelx/vsmsetup.c(revision 0)
> > @@ -0,0 +1,302 @@
> > +/*
Many thanks for the comments!
Committed revision 560.
Marc, do I need to put those two interrupt support cases back, then? I
just deleted them :-)
Let me know when the VSA is available that won't call them.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/list
On Jan 25, 2008 9:29 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 25, 2008 at 09:12:45AM -0800, ron minnich wrote:
> > Add Kconfig files for the northbridge. Currently we only need this
> > for the geodelx, so we can select nrv2b decompression.
>
> Why is nr
Well, we got MUCH further, but it did not work.
LAR: CHECK blob/vsa @ 0xfff9c730
start 0xfff9c770 len 60466 reallen 60466 compression 0 entry
0x loadaddress 0x
LAR: Compression algorithm #0 used
buf ilen 60466 real len 60466ld
buf 0x0006 *buf 186 buf[256k] 0
buf[0x20] signature
On Jan 25, 2008 5:57 PM, Carl-Daniel Hailfinger
> > + olen = file.reallen;
> > + printk(BIOS_DEBUG, "buf ilen %d olen%ld\n", file.len, olen);
> >
>
> Hm. Why is olen an unsigned long when reallen is u32?
Fixed. I got rid of olen, this was its only use.
> > + printk(BIOS_DEBUG, "biosi
Attached.
It's pretty simple and short and untested :-)
ron
This change will support stage2 running LAR files. The initial example is running the VSA in
the geode lx northbridge.
lar.h: make LAR functions SHARED
lar.c: make process_file non-static
vsmsetup.c: modify to use LAR functions.
stag
On Jan 25, 2008 11:46 PM, Patrick Georgi <[EMAIL PROTECTED]> wrote:
> How about renaming LAR to "lightweight archive(r)" and keep the short
> name?
Good one. Works for me.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
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.
> >
> > si
On Jan 25, 2008 1:06 PM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> * ron minnich <[EMAIL PROTECTED]> [080125 19:06]:
> > Actually, I did model the mainboard tree with the northbridge Kconfig tree.
> >
> > If you all can help decide on this nrv2b issue, that woul
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 that
On Jan 25, 2008 10:15 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> Hmm - probably the right move, but the changes in buildrom are not
> trivial for v2. We would need to figure out what the ROM size is (by greping
> Config.lb, probably), compress the VSA, calculate the difference and
> pad. It
On Jan 25, 2008 10:08 AM, Marc Jones <[EMAIL PROTECTED]> wrote:
> I am going to make an new VSA release soon so this would be a good time
> to make this change.
>
> Thoughts?
>
Yes. Let's go ahead and make the change to uncompressed VSA. I will
probably delete my Kconfig patch.
Thanks!
ron
--
Actually, I did model the mainboard tree with the northbridge Kconfig tree.
If you all can help decide on this nrv2b issue, that would help me a lot.
Thanks
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
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 lo
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 PROTEC
OK, VSA is running fine. BUT, after VSA runs, memory at 0x1000 is
ZERO'd. This is Bad, as this is where stage2 lives!
Any ideas :-)
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Jan 26, 2008 9:35 PM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> Can you confirm it is not zero before calling do_vsmbios() and zero
> immediately after returning? That would indicate that the VSA setup
> empties the area.
Confirmed. But why would it do this?
Is area above %esp supposed to be u
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, i
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/s
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 hap
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 w
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]>
I don't know buildrom, but you did not need the DISTRO_CFLAGS?
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Jan 28, 2008 3:48 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> Ron, can you provide us with logs of the last revision before VSA
> support went in and of your current local codebase? I hope to pinpoint
> the location of the explosion better.
Console logs? oh boy. That may be hard ..
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 i
On Jan 28, 2008 7:30 PM, Tom Sylla <[EMAIL PROTECTED]> wrote:
> Looking at one of your old logs, it looks like the VSA init code is
> *running* in the 0x1000 segment:
>
> http://www.coreboot.org/pipermail/coreboot/2008-January/029736.html
>
> (cs 0x1000)
Thanks tom, that's a good catch! I will try
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
thanks
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
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 suspicio
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;
idts[1].offset = 16384;
memcpy((void *)16384, &debug
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. e
On Jan 28, 2008 11:23 PM, Tom Sylla <[EMAIL PROTECTED]> wrote:
> Yep, I checked with FS2, things look pretty good until it gets into
> biosint. At the call to biosint, the v2 and v3 stack look the same, and
> esp is in the right spot. The code for biosint is very different for v2
> vs v3, however.
1 - 100 of 3487 matches
Mail list logo
