On Tue, Sep 16, 2008 at 8:21 PM, Joseph Smith <[EMAIL PROTECTED]> wrote:
>
> Can I just say MICRON is an awsome company. Many praises to them.
> Did anyone know that they list SPD dumps for every piece of memory they
> make?
> That makes life so much easier when trying to trouble shoot memory and S
OK, the new code properly sets parent links and also boots on both
simnow and dbe62.
I am attaching my statictree.c for perusal.
thanks
ron
#include
struct device dev_root;
struct device dev_cpus;
struct device dev_apic_0;
struct device dev_domain_0_pci_1_0;
struct device dev_domain_0_pci0_18_0
On Tue, Sep 16, 2008 at 6:12 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> I feel bad for pointing out more problems.
> IIRC dev->bus.dev used to point to the parent device. With the current
> patch, lots of devices are their own parents.
OK, my bad, I just fixed it and it removed 3 lin
Hi Carl-Daniel,
How about this?
Signed-off-by: mxie <[EMAIL PROTECTED]>
Thank you.
-Original Message-
From: Carl-Daniel Hailfinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2008 10:18 AM
To: Xie, Michael
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] the patch for AMD
Can I just say MICRON is an awsome company. Many praises to them.
Did anyone know that they list SPD dumps for every piece of memory they
make?
That makes life so much easier when trying to trouble shoot memory and SPD
values.
I think we should add a link to the wiki. What do you think?
http://ww
I'll send another patch but you have to promise to check things again :-)
thanks for the reviews.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Committed revision 863.
Thanks for the comments, Peter and Carl-Daniel!
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Author: rminnich
Date: 2008-09-17 04:19:59 +0200 (Wed, 17 Sep 2008)
New Revision: 863
Modified:
coreboot-v3/include/globalvars.h
coreboot-v3/southbridge/amd/cs5536/smbus_initram.c
Log:
Here is an alternate approach to getting rid of the static in cs5536
smbus.
Set up a global var variable
Dear Michael,
thank you for these patches.
Would it be possible for you to regenerate the S1G1 CPU patch as unified
diff (instead of context diff)? That makes the diff easier to read for us.
The S1G1 RAM init patch looks good. There are a few small things
(copyright notice, whitespace) which may
<> <>
s1g1_cpu.patch
Description: s1g1_cpu.patch
s1g1_k8.patch
Description: s1g1_k8.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 17.09.2008 02:40, ron minnich wrote:
> You might like this one better.
>
> Just a tiny change, not code dup, but the opportunity is open for more
> complex cases.
>
> This global variable infrastructure is really nice.
>
Cool thing. You're using the infrastructure in novel ways and that make
On 16.09.2008 18:29, ron minnich wrote:
> Here we go again.
>
> I've made Carl-Daniel's dts the default serengeti dts for now and
> changed dt compiler to eliminate the bug pointed out yesterday.
>
Cool, thanks.
> The dt compiler now creates the correct structures as near as I can
> tell.
I
Joseph Smith wrote:
> Now we just need to figure out what kind of hardware to convert the
> DATA & CLK lines to serial.
They just need to be retransmitted at a different baud rate.
It could certainly be done with a single PICmicro or other small
microcontroller. I suggest bitbanging the sync (PS/
You might like this one better.
Just a tiny change, not code dup, but the opportunity is open for more
complex cases.
This global variable infrastructure is really nice.
ron
smbus.diff
Description: Binary data
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/list
On 17.09.2008 02:06, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>
>> All of them have PS/2. However, some only have one PS/2 port which
>> is either a pure keyboard or a combined keyboard/mouse connector.
>> The latter may pose challenges regarding pinouts and/or electrical
>> interfaces
> The bug with all these ideas is that the superio has to be up. :\
>
Hmm. Correct me if I'm wrong but the superio has to come up for normal
serial console doesn't it?
--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.
On Wed, 17 Sep 2008 01:24:29 +0200, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> On 17.09.2008 00:34, Joseph Smith wrote:
>>> Guys, have you noticed how similar this idea is to the often-derided
> USB
>>> flash key plugged into a USB<->PS/2 converter? That's a great thing! It
>>> means we
Carl-Daniel Hailfinger wrote:
> All of them have PS/2. However, some only have one PS/2 port which
> is either a pure keyboard or a combined keyboard/mouse connector.
> The latter may pose challenges regarding pinouts and/or electrical
> interfaces (multiplexing?).
PS/2 uses four signals; power, g
Rudolf Marek wrote:
> In theory you could do the console out of SMBus,
> special dimm module just with SDA and SCL.
>
> This would just require additional hardware module. I think not so
> complicated.
The bug with all these ideas is that the superio has to be up. :\
(SMBus may be somewhere else
On 17.09.2008 00:34, Joseph Smith wrote:
>> Guys, have you noticed how similar this idea is to the often-derided USB
>> flash key plugged into a USB<->PS/2 converter? That's a great thing! It
>> means we'll attract all sorts of crazy hardware hackers.
>>
>>
> I've never heard of anyone doing t
On Mon, Sep 15, 2008 at 5:01 PM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> But I don't like all the duplication. Could it be made more generic?
>\
how about we go with this patch and take an action to make it more
generic when the time comes?
I've done it this way because I want to make sure that
> Guys, have you noticed how similar this idea is to the often-derided USB
> flash key plugged into a USB<->PS/2 converter? That's a great thing! It
> means we'll attract all sorts of crazy hardware hackers.
>
I've never heard of anyone doing that? I'd be curious if you have any
links?
--
Thank
Hans Schmid wrote:
> General question:
> Is there any reasonable way to debug BIOS code. I checked (almost)
> everything like AMD's SimNow, Bochs, Qemu, hardware tools like
> interposers and so on but they don't fit my expectations/requirements?
> What I would need were a hardware based debugger
On 16.09.2008 21:10, Joseph Smith wrote:
> On Tue, 16 Sep 2008 20:17:36 +0200, Peter Stuge <[EMAIL PROTECTED]> wrote:
>
>> Joseph Smith wrote:
>>
Joe, I remember you were interested in crazy hardware hacks.
Would designing a floppy->parallel port interface (or
floppy->serial)
In theory you could do the console out of SMBus, connect some PIC microcessor
with serial port to SMBus on the host. You can always have special dimm module
just with SDA and SCL.
This would just require additional hardware module. I think not so complicated.
Rudolf
--
coreboot mailing list:
On Tue, 16 Sep 2008 20:17:36 +0200, Peter Stuge <[EMAIL PROTECTED]> wrote:
> Joseph Smith wrote:
>> > Joe, I remember you were interested in crazy hardware hacks.
>> > Would designing a floppy->parallel port interface (or
>> > floppy->serial) fit your bill?
>>
>> That would be a crazy hardware ha
Joseph Smith wrote:
> > Joe, I remember you were interested in crazy hardware hacks.
> > Would designing a floppy->parallel port interface (or
> > floppy->serial) fit your bill?
>
> That would be a crazy hardware hack. I don't think it would be too
> dificult considering floppies are basicly seria
In trying to use the latest coreboot with my Jetway board, I've run into
the following errors:
First, in src/southbridge/via/vt8237r/vt8237r.h:
vt8237r.h:96.24: Unknown attribute:packed
Simple enough to remove the relevant attribute...
Then:
vt8237r_early_smbus.c:342.62: Junk at end of integer
On Tue, Sep 16, 2008 at 4:11 AM, Vincent Legoll
<[EMAIL PROTECTED]> wrote:
> Wouldn't a macro be appropriate to minimize line count ?
>
Probably. I'll take a patch! We can always use v3 contributors! (hint, hint :-)
I think we can revisit this but for now I want to see simnow boot.
This file badl
Here we go again.
I've made Carl-Daniel's dts the default serengeti dts for now and
changed dt compiler to eliminate the bug pointed out yesterday.
The dt compiler now creates the correct structures as near as I can
tell. Maybe we're done with bugs for now :-)
If this passes the mailing list tes
> Joe, I remember you were interested in crazy hardware hacks. Would
> designing a floppy->parallel port interface (or floppy->serial) fit your
> bill?
>
That would be a crazy hardware hack. I don't think it would be too dificult
considering floppies are basicly serial devices. I'll do some resea
On 16/09/08 10:14 +0200, Paul Millar wrote:
> *delurk*
>
> Hi,
>
> I saw this announced on freshmeat:
>
> http://code.google.com/p/sgabios/
>
> I guess it's not terribly interesting to coreboot (which already does serial
> output, right?).
>
> What might be interesting is there's a nego
On 16/09/08 16:35 +0200, Robert Millan wrote:
> I don't understand what you mean here.
>
> > - Please investigate the possibility to add that multiboot code to
> > libpayload so that Bayou can use it. Bayou is our recommended default
> > payload chooser and it would be nice if Bayou could support
On 16.09.2008 08:53, Corey Osgood wrote:
> On Mon, Sep 15, 2008 at 8:14 PM, Joseph Smith <[EMAIL PROTECTED]> wrote:
>
>>
>> On Tue, 16 Sep 2008 01:28:40 +0200, Carl-Daniel Hailfinger
>> <[EMAIL PROTECTED]> wrote:
>>
>>> since the market share of machines with a serial port is shrinking
>>>
On Mon, Sep 15, 2008 at 10:54:20PM +0200, Carl-Daniel Hailfinger wrote:
> On 15.09.2008 21:49, Robert Millan wrote:
> > The attached patch adds a build option so that one can choose between
> > native coreboot tables and multiboot information (or both, or neither).
> >
>
> Have you tested it wi
35 matches
Mail list logo
