David Hendricks wrote:
> AWESOME! I'd like to try this out on an AMD790 platform in the near
> future if possible :-)
>
> Just out of curiosity, is there an ER298 fix buried in here or should
> we try kernel workarounds first?
>
298 is commented out for the moment but it is there. I need to do so
AWESOME! I'd like to try this out on an AMD790 platform in the near future
if possible :-)
Just out of curiosity, is there an ER298 fix buried in here or should we try
kernel workarounds first?
On Dec 12, 2007 9:51 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> Here is the initial patches for AMD B
Changes to core lapic.h. This file is used by Intel multiprocessor CPUs
as well as AMDs. Could someone with Intel APIC experience take a close
look at this and try it?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessor
AMD 8111 southbridge adjustments for Barcelona.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Additional early AMD8111 southbridge support for Barcelona platforms.
Check that the SMBus controller is found and stop
ron minnich wrote:
> On Dec 12, 2007 6:00 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
>
>> There are a couple ways to address this.
>> 1. copy the stack to a new location.
>> 2. Set the tags dirty with by writing the way MSRs.
>> 3. enable the cache and copy the stack back on it's self to dirty th
On Dec 12, 2007 6:00 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> There are a couple ways to address this.
> 1. copy the stack to a new location.
> 2. Set the tags dirty with by writing the way MSRs.
> 3. enable the cache and copy the stack back on it's self to dirty the tags.
>
> I am least sure a
Quoting Corey Osgood <[EMAIL PROTECTED]>:
> On Dec 12, 2007 5:02 PM, <[EMAIL PROTECTED]> wrote:
>
>> Quoting Corey Osgood <[EMAIL PROTECTED]>:
>>
>> > Hey guys,
>> >
>> > I've been looking through the datasheet on this chip, and I've got no
>> > idea where the values you use come from. I know som
Carl-Daniel Hailfinger wrote:
> On 13.12.2007 02:29, Marc Jones wrote:
>>
>> Carl-Daniel Hailfinger wrote:
>>> You mean, the stack is "moved"? Or why do we need to adjust the
>>> pointers? Won't that leave pointers to variables on stack dangling?
>>>
>> I meant that ss, esp, ebp are adjusted to p
Marc Jones wrote:
>
> Carl-Daniel Hailfinger wrote:
>
>> Dumb question: We know the location of the stack when we enter
>> disable_car(). We also know that all memory belongs to us. Can we copy
>> CAR stack contents to some safe location and restore them after wbinvd()?
>>
>
> This shouldn't b
On Dec 12, 2007 8:53 PM, Carl-Daniel Hailfinger <
[EMAIL PROTECTED]> wrote:
> On 13.12.2007 01:46, ron minnich wrote:
> > Hey, carl-daniel, what's a good payload for testing my 'payload won't
> > work' problem? Also, I wonder if it is because the payload runs above
> > 0x10?
> >
>
> Sorry, Ron
On 13.12.2007 01:46, ron minnich wrote:
> Hey, carl-daniel, what's a good payload for testing my 'payload won't
> work' problem? Also, I wonder if it is because the payload runs above
> 0x10?
>
Sorry, Ron, I have no idea. Maybe we should create a "hello world"
payload. Memtest is probably t
On 13.12.2007 02:29, Marc Jones wrote:
>
>
> Carl-Daniel Hailfinger wrote:
>>
>> You mean, the stack is "moved"? Or why do we need to adjust the
>> pointers? Won't that leave pointers to variables on stack dangling?
>>
>
> I meant that ss, esp, ebp are adjusted to point at the new stack. The
> cont
Carl-Daniel Hailfinger wrote:
> Dumb question: We know the location of the stack when we enter
> disable_car(). We also know that all memory belongs to us. Can we copy
> CAR stack contents to some safe location and restore them after wbinvd()?
>
This shouldn't be needed. If the stack needed to
Carl-Daniel Hailfinger wrote:
>
> You mean, the stack is "moved"? Or why do we need to adjust the
> pointers? Won't that leave pointers to variables on stack dangling?
>
I meant that ss, esp, ebp are adjusted to point at the new stack. The
contents of the stack don't change.
--
Marc Jones
S
On Dec 12, 2007 5:02 PM, <[EMAIL PROTECTED]> wrote:
> Quoting Corey Osgood <[EMAIL PROTECTED]>:
>
> > Hey guys,
> >
> > I've been looking through the datasheet on this chip, and I've got no
> > idea where the values you use come from. I know some of you have been
> > adding dump support to variou
Hi Marc,
that's funny. We both wrote almost the same mail at the same time.
On 13.12.2007 02:14, Marc Jones wrote:
> ron minnich wrote:
>
>> On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I don't like this. disable_car() should just be able to retu
OK, will get some debug prints in there for you all and you can tell
me what to do.
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ron minnich wrote:
> On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>> I don't like this. disable_car() should just be able to return without
>> problems. If it can't do that, fix it.
I agree.
>> Why exactly do we invalidate the stack? If the stack is clobbered,
On 13.12.2007 01:59, ron minnich wrote:
> On Dec 12, 2007 4:57 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>
>> A few questions about the log:
>> The first boot seems to hang/reset at "Configuring PLL". Any idea why
>> this happens?
>>
>
> you usually have to reboot on power u
On 13.12.2007 01:58, ron minnich wrote:
> On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>
>> I don't like this. disable_car() should just be able to return without
>> problems. If it can't do that, fix it.
>>
>
> I've never found the fix. What if it is a har
On Dec 12, 2007 4:52 PM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 12, 2007 at 04:46:32PM -0800, ron minnich wrote:
> > well, is the banner enough to flush all the fifo's? I thought they
> > got pretty big nowadays. Anyone know?
>
> 16550 and compatible still only have 14/16/18/whatever
On Dec 12, 2007 4:57 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> A few questions about the log:
> The first boot seems to hang/reset at "Configuring PLL". Any idea why
> this happens?
you usually have to reboot on power up after that step. Once you
reconfigure the pll you have to go a
On Dec 12, 2007 4:50 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> I don't like this. disable_car() should just be able to return without
> problems. If it can't do that, fix it.
I've never found the fix. What if it is a hardware limitation on LX?
Note that on several LX platforms on V2
On 11.12.2007 06:20, ron minnich wrote:
> note it loads the payload, but that's all we get.
>
Ron, that is really great!
A few questions about the log:
The first boot seems to hang/reset at "Configuring PLL". Any idea why
this happens?
> It is uncompressed. I got an error on compressed payloa
On Wed, Dec 12, 2007 at 04:46:32PM -0800, ron minnich wrote:
> well, is the banner enough to flush all the fifo's? I thought they
> got pretty big nowadays. Anyone know?
16550 and compatible still only have 14/16/18/whatever bytes.
EHCI debug port is unbuffered.
.. are there more?
//Peter
--
l
On 11.12.2007 05:43, ron minnich wrote:
> note that the stage1_main code calls disable_car, then stage1_next.
> But disable_car calls stage1_next too! how
> can this works?
>
> The redundant call ensures this code works no
> matter whether the chip-dependent disable_car calls stage1_next or not.
>
On Dec 12, 2007 4:42 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> On 11.12.2007 02:38, ron minnich wrote:
> > Add a nice pretty banner printer so we have standard banners.
> >
>
> Maybe make the banner a little bit shorter so bigger strings will fit
> without wrapping?
Sure! what's a go
On 11.12.2007 02:38, ron minnich wrote:
> Add a nice pretty banner printer so we have standard banners.
>
Maybe make the banner a little bit shorter so bigger strings will fit
without wrapping?
> Make 'halt' just put out nulls forever instead of hlt(), to ensure that any
> fifos
> of any sor
On 10.12.2007 01:19, Torsten Duwe wrote:
> On Sunday 09 December 2007, Oliver McFadden wrote:
>
>
>> The opcodes and format of the binary scripts and data tables are described
>> by the parser code, so I think there is enough information, except for how
>> to actually flash the on-card ROM...
>>
On 12/13/07, Marc Jones <[EMAIL PROTECTED]> wrote:
>
>
> ron minnich wrote:
> > On Dec 11, 2007 2:42 PM, Martin-Éric Racine <[EMAIL PROTECTED]> wrote:
>
> >>> In regards to the DIVIL_BALL settings. FlashROM checks to see what
> >>> device was
> >>> booted from (i.e. LPC, flash controller) before
On Dec 12, 2007 2:38 PM, Sergei Antonov <[EMAIL PROTECTED]> wrote:
>
> 1. The keyboard doesn't work. Here is a piece of log from the serial port:
> =
> PNP: 03f0.5 init
> Keyboard init...
> Keyboard input buffer would not empty
>
On 06/12/07 17:40 -0500, Ward Vandewege wrote:
> On Thu, Dec 06, 2007 at 03:34:53PM -0700, Jordan Crouse wrote:
> > A few fixes before my v3 patch - this cleans up the menuconfig to be
> > a little bit more clear, and fixes a spurious variable that I removed
> > behind Ward's back.
Gah - I never c
Author: jcrouse
Date: 2007-12-12 23:54:25 +0100 (Wed, 12 Dec 2007)
New Revision: 83
Modified:
buildrom-devel/packages/linuxbios/generic-linuxbios.mk
Log:
[BUILDROM] Fix a syntax error
Fix a syntax error in one of the makefiles. Trivial patch.
Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
Author: jcrouse
Date: 2007-12-12 23:52:48 +0100 (Wed, 12 Dec 2007)
New Revision: 82
Modified:
buildrom-devel/Config.in
buildrom-devel/config/payloads/Config.in
buildrom-devel/packages/kernel/kernel.inc
buildrom-devel/packages/uclibc/uclibc.mk
buildrom-devel/scripts/Build.settings
Lo
On Dec 9, 2007 9:42 PM, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 07, 2007 at 01:39:43PM +0300, Sergei Antonov wrote:
> > I'd like to try LinuxBIOS on a 440BX-based Abit BE6-II V2.0.
> > After talking on IRC, I'm sending the output of 'lspci -tvnn' and
> > 'superiotool -dV' and a generat
ron minnich wrote:
> On Dec 11, 2007 2:42 PM, Martin-Éric Racine <[EMAIL PROTECTED]> wrote:
>>> In regards to the DIVIL_BALL settings. FlashROM checks to see what device
>>> was
>>> booted from (i.e. LPC, flash controller) before the flash device is
>>> identified. If the
>>> boot device is t
Quoting Corey Osgood <[EMAIL PROTECTED]>:
> Hey guys,
>
> I've been looking through the datasheet on this chip, and I've got no
> idea where the values you use come from. I know some of you have been
> adding dump support to various chips just for the sake of having them
> (which is a good thing,
Hey guys,
I've been looking through the datasheet on this chip, and I've got no
idea where the values you use come from. I know some of you have been
adding dump support to various chips just for the sake of having them
(which is a good thing, and I'm glad you're doing it), so I was hoping
you mig
Quoting ron minnich <[EMAIL PROTECTED]>:
> so can others besides me test this, and, Marc, thanks for the patch.
>
> ron
>
I just upgraded my laptop to FC8 x86_64. I will do some test building
this weekend and report back.
Thanks - Joe
--
linuxbios mailing list
linuxbios@linuxbios.org
http:/
so can others besides me test this, and, Marc, thanks for the patch.
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
I have no way to test, does anyone else or should we just ack it?
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Dec 12, 2007 11:19 AM, Marc Jones <[EMAIL PROTECTED]> wrote:
> Should it die if a a device isn't found? Seems like that would be a
> warning. I can imagine some cases where a device might or might not be
> installed on a mainboard that could be supported by a single ROM image.
I thought the sa
On Wed, 28 Nov 2007, Ulf Jordan wrote:
> Add dump support for NSC PC8741x.
ping?
/ulf
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Wed, 2007-12-12 at 11:15 -0800, ron minnich wrote:
> On Dec 12, 2007 11:05 AM, Steve Isaacs <[EMAIL PROTECTED]> wrote:
>
> >
> > I'm thinking that an experiment which might prove interesting is to
> > temporarily change pci_scan_bus to not die when this device is "Left
> > over..." and see wher
ron minnich wrote:
> On Dec 12, 2007 11:05 AM, Steve Isaacs <[EMAIL PROTECTED]> wrote:
>> I'm thinking that an experiment which might prove interesting is to
>> temporarily change pci_scan_bus to not die when this device is "Left
>> over..." and see where that gets me.
>
> sure, it can't hurt ..
On Dec 12, 2007 11:05 AM, Steve Isaacs <[EMAIL PROTECTED]> wrote:
> btw: based upon this information I've deduced that if a device is listed
> in the Config.lb but does not appear in the bus scan it is identified as
> a "Left over device." Is this correct?
yes.
>
> I'm thinking that an experimen
On Mon, 2007-12-10 at 17:32 -0700, Marc Jones wrote:
> When I have seen a soft reset at this point it has been due to a memory
> problem. Try simpler configurations and try putting some basic memory
> test just before CAR is disabled. I would try on the interesting
> boundaries. For example, c
On 12/12/07 09:40 +0900, Jun Koi wrote:
> On 12/10/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> > On Wed, Dec 05, 2007 at 12:31:54PM -0800, Wakefield, John wrote:
> > > I have an Acer 5102WLMi Notebook with Dual Core AMD TL50s, which are 64
> >
> > I'm afraid LinuxBIOS doesn't yet work on laptops,
2 LAN Adapter VIA VT6105M
1 Crypto Device - Fortinet FortiASIC-CP4
- Original Message -
From: "ron minnich" <[EMAIL PROTECTED]>
To: "Cimino Vittorio" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, December 12, 2007 5:14 PM
Subject: Re: [LinuxBIOS] TOPSEARCH TS-M-8V01C
> what device is connec
On Dec 12, 2007 12:28 AM, <[EMAIL PROTECTED]> wrote:
>
>
>
> Hello,
>
> Yesterday I wrote some code for the Syslinux boot loader that is meant to
> boot different images based on which revision of the CPU microcode that is
> currently loaded in the CPU (yes, this is a bit strange but we have a ver
what device is connected to smbus?
Is there an i2c mux on the board?
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Same Problem.
- Original Message -
From: "bari" <[EMAIL PROTECTED]>
To: "Cimino Vittorio" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, December 12, 2007 3:23 PM
Subject: Re: [LinuxBIOS] TOPSEARCH TS-M-8V01C
> Cimino Vittorio wrote:
> > LinuxBiosV3 (latest snapshot)
> >
> > Motherborad TOPS
On 11.12.2007 22:43, Oliver McFadden wrote:
> On 12/11/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
>
>> On 12/10/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Thanks for the pointers. I will look into implementing SPI support for
>>> these cards in a week or so. Ping me
Forgot to add my sign-off
Signed-off-by: Marc Karasek mailto:[EMAIL PROTECTED]
Original Message
Subject:Re: [LinuxBIOS] Patch file for Fedora 8 compile problems
Date: Tue, 11 Dec 2007 12:31:57 -0500
From: Marc Karasek <[EMAIL PROTECTED]>
To: ron minnich <[EMAIL
Cimino Vittorio wrote:
> LinuxBiosV3 (latest snapshot)
>
> Motherborad TOPSEARCH TS-M-8V01C
>
> SouthBridge : VT8231
> NorthBridge : VT8601
>
> This can be a VIA/EPIA compatible Motherboard.
> The make process and other operation (programming flash etc etc) are ok.
> When system start LinuxB
On Wed, Dec 12, 2007 at 02:04:17PM +0100, Cimino Vittorio wrote:
> LinuxBiosV3 (latest snapshot)
Look like v2. There's no support for via hardware in v3 yet either.
> SouthBridge : VT8231
> NorthBridge : VT8601
..
> This can be a VIA/EPIA compatible Motherboard.
Unfortunately it's not enough
LinuxBiosV3 (latest snapshot)
Motherborad TOPSEARCH TS-M-8V01C
SouthBridge : VT8231
NorthBridge : VT8601
This the data from motherboard
CPU
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping: 3
cpu MHz
Quoting [EMAIL PROTECTED]:
> Hello,
>
> Yesterday I wrote some code for the Syslinux boot loader that is meant
> to boot different images based on which revision of the CPU microcode
> that is currently loaded in the CPU (yes, this is a bit strange but we
> have a very good reason for it). I then
On 12/11/07, ron minnich <[EMAIL PROTECTED]> wrote:
> I use a script to set DIVIL_BALLS FWIW.
>
> but auto sensing? Never worked for me. Is it really possible?
Dave Frodin of AMD replied on the Geode mailing list (talking about
how their non-free gx_util.c and closed-source AMD flashrom work):
>
Hello,
Yesterday I wrote some code for the Syslinux boot loader that is meant
to boot different images based on which revision of the CPU microcode
that is currently loaded in the CPU (yes, this is a bit strange but we
have a very good reason for it). I then compared my implementation with
a few o
60 matches
Mail list logo
