Carl-Daniel Hailfinger wrote:
> On 15.10.2009 13:04, Stefan Reinauer wrote:
>
>> ron minnich wrote:
>>
>>
>>> On Mon, Oct 12, 2009 at 8:51 PM, Myles Watson wrote:
>>>
>>>
>>>
>>>
>>>> So
for (;;);
> + }
>
Can we do for (;;) asm("hlt"); instead?
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
G
On Oct 16, 2009, at 0:33, Uwe Hermann wrote:
On Thu, Oct 15, 2009 at 12:01:12PM -0600, Myles Watson wrote:
config HAVE_ACPI_TABLES
bool
+help
+ This variable specifies whether a given board has ACPI table
support.
+ It is usually set in mainboard/*/Kconfig.
+ Whether or
Peter Stuge wrote:
> Uwe Hermann wrote:
>
>> subdirs-y += ../../x86/tsc
>> -subdirs-y += ../../x86/mtrr
>> subdirs-y += ../../x86/fpu
>> subdirs-y += ../../x86/mmx
>> subdirs-y += ../../x86/sse
>>
>
> Could these last two be set in cpu/x86 by CONFIG_{MMX,SSE} ?
>
That, or dropped..
Peter Stuge wrote:
>> @@ -61,7 +74,7 @@ unsigned long acpi_fill_madt(unsigned lo
>>
>> /* IRQ9 ACPI active low. */
>> current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)
>> -current, 0, 9, 9, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW);
>> +curre
ssages don't show up anymore.
...
While I was fooling with it, I made Kconfig ensure that
MAXIMUM_CONSOLE_LOGLEVEL >= DEFAULT_CONSOLE_LOGLEVEL to minimize the
number of test cases I needed.
Signed-off-by: Myles Watson
Ping.
I'd like to be able to say "Try Kconfig with SPEW",
Myles Watson wrote:
>
>
> On Fri, Oct 16, 2009 at 2:38 PM, coreboot information
> mailto:i...@coresystems.de>> wrote:
>
> Dear coreboot readers!
>
> This is the automatic build system of coreboot.
>
> The developer "myles" checked in revision 4795 to
> the coreboot repository. This
Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>
>>> The code does not really support more than one CPU "type" at a time.
>>>
>> CAR code for K8/Fam10 autodetects the CPU and issues the right
>> commands based on autodetection.
>>
>
> That's fine, but it's not worth much without
Paweł Stawicki wrote:
>
> I was able run my VIA c3 processor :-)
>
> changing the line:
> chip cpu/intel/socket_PGA370# CPU
> to:
> chip cpu/via/model_c3
>
> in Config.lb
>
> but how to turn on intel processors AND via C3 processors ?
Instead of the above, you should add the VIA cp
Peter Stuge wrote:
>> but how to turn on intel processors AND via C3 processors ?
>>
>
> This is the first time it has been done.
>
Supporting several CPUs on one socket is not so new though.
> The code does not really support more than one CPU "type" at a time.
>
Not exactly. All requir
Myles Watson wrote:
> The attached patch fixes booting for arima/hdama.
>
> How should we really fix it? In v3 didn't we just scrap type 2
> accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes absolutely no sense.
I sent a patch for this some days
Myles Watson wrote:
>>> Right now I'd like to match newconfig and kill it as
>>> quickly as possible.
>>>
>> Sure, same here. I don't think this patch interferes with this effort
>> though.
>>
> As long as all of the code that gets enabled/disabled is only print
> statements, that's pro
Uwe Hermann wrote:
> See patch.
>
> I'm happy for any comments. Also, I'm not sure how all this
> hard_reset() stuff is meant to work. Many southbridges have _two_
> implementations of hard_reset(). Why? Some only have one.
> Some have none, but I guess that's OK, as their RAM init or other
> coreb
resystems.de • 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
• Fax: +49 761 7664613
Email: i...@coresystems.de • 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
A CPU fits in it.
good plan.
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
re-order
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Fix K8 boards high tables on UMA systems (KT690 for example)
Thanks to Carl-Daniel for pointing this out with some example code.
Signed
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Rework
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Fix USB
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Carl-Daniel Hailfinger wrote:
> On 24.10.2009 03:12, Stefan Reinauer wrote:
>
>> re-order console output functions, add proper prototypes,
>> drop claim that our files were blatantly copied, because they have been
>> rewritten a very long time ago.
>>
>
Carl-Daniel Hailfinger wrote:
> On 24.10.2009 03:14, Stefan Reinauer wrote:
>
>> See patch. Carl Daniel sent something very similar before... This one is
>> the same but adds some preprocessing sugar to it so it does the right
>> thing both for UMA and non-UMA cases
&g
Carl-Daniel Hailfinger wrote:
> On 24.10.2009 03:31, Stefan Reinauer wrote:
>
>> Fix USB Debug Device for Intel ICH chipsets
>>
>>
>
> Acked-by: Carl-Daniel Hailfinger
>
> Regards,
> Carl-Daniel
>
>
Thanks, r4836
--
core
Myles Watson wrote:
>
>
> +#if CONFIG_GFXUMA == 1
> + printk_debug("node %d :
> uma_memory_base/1024=0x%08x, mmio_basek=0x%08x, basek=0x%08x,
> limitk=0x%08x\n", i, uma_memory_base >> 10, mmio_basek, basek,
> limitk);
> + if ((uma_memory_base >> 1
Myles Watson wrote:
>
>
> 2009/10/23 Stefan Reinauer <mailto:ste...@coresystems.de>>
>
> See patch
>
> --
> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
> Tel.: +49 761 7668825 • Fax: +49 761 7664613
> Email: i...@cor
Myles Watson wrote:
>
>
> 2009/10/23 Stefan Reinauer <mailto:ste...@coresystems.de>>
>
> Index: src/pc80/keyboard.c
> ===
> --- src/pc80/keyboard.c (revision 4832)
> +++
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Use
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Option
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
intel
: Stefan Reinauer • Ust-IdNr.: DE245674866
drop runtime configuration checking layer from the code.
Don't check for errors we can't handle gracefully anyways.
It's always better to try initializing the keyboard controller
when IO in the device tree is != 0x60/0x64 than to just dr
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Get the
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Now that
See patch
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
CBMEM
Uwe Hermann wrote:
> We should add a MEM_TRAIN_SEQ comment or help text, it's unclear to me what
> it is
> supposed to do. Is it a per-chipset, per-cpu, or per-board option? What
> do the values of the variable mean?
>
> Regardless of that, it seems like it should be a user-visible option in
> men
Peter Stuge wrote:
> Myles Watson wrote:
>
>>> No, but it would make sense... What's the right place for this?
>>> include/uart8250.h ?
>>>
>> maybe include/pc80/serial.h or include/pc80/uart8250.h?
>>
>
> If either exists, use that. If neither exists I prefer the simpler
> serial.h.
Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>> Option ROM init x86/x86emu update
>>
>> - use default display in int 15 5f35
>> - move REALMODE_BASE to 0x600, 0x500 can be BDA
>> - add regparm for assembler functions
>> - use memset instead of own im
Uwe Hermann wrote:
> On Sun, Oct 25, 2009 at 03:08:49PM +0100, Peter Stuge wrote:
>
>> Stefan Reinauer wrote:
>>
>>> Use Intel Core code for eagleheights CAR init, not Intel Core 2, as
>>> any of the CPUs might be used.
>>>
>>> Signed-
Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>>>> - YABEL: copy back the IVT, BDA and VBIOS. Some Xorg drivers
>>>> require this.
>>>>
>>> Which drivers?
>>>
>> As you might imagine I did not test this on the
Myles Watson wrote:
> src/cpu/x86/smm/Makefile.inc:33: warning: overriding commands for
> target
> `/home/myles/try/buildrom-devel/work/coreboot/svn/build/cpu/x86/smm/smm.o'
> src/cpu/x86/smm/Makefile.inc:33: warning: ignoring old commands for
> target
> `/home/myles/try/buildrom-devel/work/coreboo
Myles Watson wrote:
>
>
>
> Ooops my fault.. Whatever appeals people most ...
>
> Whatever seems most consistent.
>
>
> If a socket includes intel/model_6ex and intel/model_6fx and both
> include smm, we would get duplicates again,.. so just including
> x86 from
> cpu and incl
CPI_TABLES
and just define a reasonable maximum for now.
Signed-off-by: Stefan Reinauer
Index: src/arch/i386/boot/acpi.c
===
--- src/arch/i386/boot/acpi.c (revision 4861)
+++ src/arch/i386/boot/acpi.c (working copy)
@@ -
/arch/i386/lib/cbfs_and_run.c
> Log:
> reasonable output in cbfs loading (part 2)
> run hlt in endless loop, be friendly to the cpu
>
> Signed-off-by: Stefan Reinauer <mailto:ste...@coresystems.de>>
> Acked-by: Stefan Reinauer <mailto:ste...@core
Myles Watson wrote:
> I'm worried about tool chain problems, so I wanted to be able to build
> with a cross compiler. This patch adds that functionality to Kconfig.
>
That functionality is already there... see util/xcompile.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.o
do for resume
> but in car
> stage just to find out where the tables are...
Speaking of hacks, we could remember the CBMEM base address in the low
4KB so we can find them again...
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +4
5 • Fax: +49 761 7664613
Email: i...@coresystems.de • 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
ciexp_scan_bus(struct bus *bus,
>
What kind of tuning should be done here?
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • 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
68825 • Fax: +49 761 7664613
Email: i...@coresystems.de • 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
iles,.. check src/include for a fitting one.
If there is none, we should think about creating one.
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht
urg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • 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
Myles Watson wrote:
>
>> -Original Message-
>> From: Stefan Reinauer [mailto:ste...@coresystems.de]
>> Sent: Wednesday, October 28, 2009 4:25 AM
>> To: Myles Watson
>> Cc: 'Maciej Pijanka'; coreboot@coreboot.org
>> Subject: Re: [coreboot
atson mailto:myle...@gmail.com>>
Acked-by: Stefan Reinauer
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Myles Watson wrote:
> Signed-off-by: Myles Watson mailto:myle...@gmail.com>>
>
> Thanks,
> Myles
I wouldn't move those, ... they're never ever going to be called by
anyone. (explicitly)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Carl-Daniel Hailfinger wrote:
> Hi Ward,
>
> was it intentional that you placed these tools below coreboot-v2/ in the
> tree?
>
Yes, can we please move the other tools there, too?
I miss them and now I have two do two checkouts and two svn ups
everytime I need them.
Stefan
--
coreboot mai
tdump,newconfig,nrv2b,optionlist,options,resetcf}
\
svn://coreboot.org/repos/trunk/util
svn mv
svn://coreboot.org/repos/trunk/coreboot-v2/util/{romcc,sconfig,vgabios,x86emu,xcompile}
\
svn://coreboot.org/repos/trunk/util
svn rm svn://coreboot.org/repos/trunk/coreboot-v2/
Signed-off-by: S
Robert Millan wrote:
> On Mon, Oct 26, 2009 at 09:20:53PM +0100, Andreas B. Mundt wrote:
>
>> Hi,
>>
>> first, congratulations to the 1.97-release!
>>
>> I vainly tried to run the latest grub2 (Revision: 2663) as payload to
>> coreboot (Revision: 4852) following the wikipage:
>>
>>http:
Bao, Zheng wrote:
> Ping. Have you guys tested on all the supported boards?
>
> Zheng
>
Untested, but the patch looks look. You shouldn't need
CONFIG_VGA_ROM_RUN on boards with CONFIG_PCI_ROM_RUN set already.
CONFIG_PCI_ROM_RUN: Run all option roms
CONFIG_VGA_ROM_RUN: Run only VGA option roms
their bug fixes and contributions to
this release.
See http://www.serialice.com/ for more information.
Comments and patches are of course very welcome!
Best regards,
Stefan Reinauer
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 766
Carl-Daniel Hailfinger wrote:
> On 29.10.2009 09:52, Stefan Reinauer wrote:
>
>> I know some people will claim this hurts. But it will hurt the same way
>> when the version number is up to 4, so we better do it now than later:
>>
>>
>
> Sorry, NACK.
Myles Watson wrote:
>
>
> On Thu, Oct 29, 2009 at 2:38 AM, Stefan Reinauer
> mailto:ste...@coresystems.de>> wrote:
>
> Myles Watson wrote:
> > Signed-off-by: Myles Watson <mailto:myle...@gmail.com> <mailto:myle...@gmail.com
> <mailt
rea needs to grow from 64KB to 1MB in order for the
ACPI RESUME table to fit...
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HR
t; Signed-off-by: Myles Watson
> Acked-by: Myles Watson
>
>
Nice catch!
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HR
Carl-Daniel Hailfinger wrote:
> On 30.10.2009 01:54, Peter Stuge wrote:
>
>> Stefan Reinauer wrote:
>>
>>
>>> (this moves all sudirectories of coreboot-v2 to trunk and wipes the
>>> coreboot-v2 directory as soon as it's empty. Then the d
Carl-Daniel Hailfinger wrote:
> On 30.10.2009 03:49, Peter Stuge wrote:
>
>> Carl-Daniel Hailfinger wrote:
>>
>>
If moving then I prefer this. Do the job properly when the knife is
out anyway. :)
>>> NACK!!!
>>>
>>> Are you two aware that every checkou
Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>> CONFIG_PCI_ROM_RUN: Run all option roms
>> CONFIG_VGA_ROM_RUN: Run only VGA option roms
>>
>
> Would anyone cry if these were renamed?
>
I don't think the names are particularly bad, so I guess
Myles Watson wrote:
>
>
> On Thu, Oct 29, 2009 at 7:28 PM, Peter Stuge <mailto:pe...@stuge.se>> wrote:
>
> Stefan Reinauer wrote:
> > CONFIG_PCI_ROM_RUN: Run all option roms
>
> Now it's run all option roms except VGA.
Ouch... when did that chan
Peter Stuge wrote:
> Myles Watson wrote:
>
>>> I'd like __ROMCC__ to stay, but I agree very much with a new #define
>>> BEFOREDEVICETREE or somesuch.
>>>
>> How about __PRE_RAM__, since it could be CAR but it is before RAM init?
>>
>
> I like __PRE_RAMINIT__ a lot!
>
wouldn't __D
copied to a new (directory|repository).
>
> Both hold some weight. In practise v2 is already no longer v2. Until
> there are resources to start work on a new branch, let's just be
> version free!
>
>
> Stefan Reinauer wrote:
>
>> (this moves all sudirectories of c
Myles Watson wrote:
>
>
> On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer
> mailto:ste...@coresystems.de>> wrote:
>
> Peter Stuge wrote:
> > Myles Watson wrote:
> >
> >>> I'd like __ROMCC__ to stay, but I agree very much w
Carl-Daniel Hailfinger wrote:
> Software development usually tries to improve the codebase (if we ignore
> developmestruction environments). This move is guaranteed to make the
> codebase worse, and even after fixups the end result will still be worse
> than what we had before.
>
Sorry, I comple
ron minnich wrote:
> well how about this as a first step. We're getting exception 6. What
> is that again?
> Also: is 0x8e41a854 even remotely valid as a bios int?
> And: 8831:eb60 -- 96E70 -- is that a sensible place for the CPU to be?
>
> It looks to me like the stack is somewhere odd: 774a. Is t
Patrick Georgi wrote:
> Am Freitag, den 30.10.2009, 12:15 -0600 schrieb Myles Watson:
>
>> for gccprefixes in `pwd`/../crossgcc/xgcc/bin/i386-elf- i386-elf- "";
>> do
>>
> Maybe add $PWD/util/crossgcc/xgcc/bin/i386-elf- to the list, too - it
> can't hurt.
>
Yes, I think the `pwd`/../cros
Uwe Hermann wrote:
> See patch.
>
> More patches to further improve this stuff are planned, e.g. to check up
> to Top-of-memory, and to make it runtime (CMOS) configurable.
>
>
NACK
I don't think this should be user visible. In fact I think it should be
dropped from all boards once they are wor
ease let me know.
Best regards,
Stefan Reinauer
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsfüh
Hi, Gregg,
On Nov 1, 2009, at 4:21, "Gregg C Levine" > wrote:
Hello!
Okay, suppose we haven't added anything to our checked out
repositories, how
do we retrieve these updated ones. Just follow the usual steps for a
checkout of a new one?
Absolutely!
In case of trouble check the download
See patch..
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
x86emu
See patch
Some fixes.
Atom does not like 36bit MTRRs in CAR setup.
Enable XIP setup again (works with 32bit MTRRs)
Keep code more similar to 6ex code..
Signed-off-by: Patrick Georgi
Signed-off-by: Stefan Reinauer
Index: src/cpu/intel/model_106cx/cache_as_ram_post.c
Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>> Ok, new version: I added CPUID and removed a whole bunch of
>> warnings, too.
>>
>
> Looks fine.
>
>
>
>> x86emu: Add support for the following opcodes:
>>
>> * SMSW
>> * INVD
ron minnich wrote:
> Acked-by: Ronald G. Minnich
>
>
thanks, r4907
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ilt by the script coreboot/util/crossgcc/buildgcc ... It
will produce a known good toolchain.
> Thank you.
Good luck!
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • 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
Stefan Reinauer wrote:
> See patch. This works nicely on two i945 machines I have here
> (unfortunately not the Kontron 986lcd-m due to some other reason)
> Probably needs some fixing for the AMD board that Rudolf got running
> with Resume. Rudolf, can you jump in, I don't h
; is a better idea, as "0" is the value used when
> cbfstool add-stage can freely choose the location. "1" should already
> lead to an error.
>
>
> Signed-off-by: Patrick Georgi
>
We need a new and working failover..
Acked-by: Stefan Reinauer
--
coresystem
61 7664613
Email: i...@coresystems.de • 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
Rudolf Marek wrote:
> Hi
>
> Sorry I tried to get it working on K8 but got distracted by the
> network support
> for SerialICE and network console for coreboot ;)
How's that going?
> I think I can Acked-by: Rudolf Marek
Thanks, r4932
> Although I would
> prefer to have the wakeup trampoline loc
letely enough to drop the graphics device from
Config.lb/devicetree.cb and say
chip southbridge/amd/rs780
device pci 0.0 on end # HT 0x9600
device pci 1.0 on end # Internal Graphics P2P bridge 0x9602
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Myles Watson wrote:
>> The good news is:
>> chip southbridge/amd/rs780 unconditionally pulls in the graphics driver
>> which is still executed per PCI ID, and not per notation of static.c
>>
>> So it's completely enough to drop the graphics device from
>> Config.lb/devicetree.cb and say
>>
>> chip
Myles Watson wrote:
>> The good news is:
>> chip southbridge/amd/rs780 unconditionally pulls in the graphics driver
>> which is still executed per PCI ID, and not per notation of static.c
>>
>> So it's completely enough to drop the graphics device from
>> Config.lb/devicetree.cb and say
>>
>> chip
Peter Stuge wrote:
> Myles Watson wrote:
>
unsigned char option_table[] = {
0xc8,0x00,0x00,0x00,0x88,0x04,0x00,0x00,0x0c,0x00,
>>> Second 32 bits 0x88,0x04,0x00,0x00 is the length. We're small endian.
>>> So it's 0x488 or 1160 bytes. Does that match?
>>>
>>
Peter Stuge wrote:
> Myles Watson wrote:
>
>>> It is completely unclear to me why it is safe to write beyond the
>>> struct lb_record
>>>
>> lb_record is just the header. The data follows it, but isn't a
>> member of the struct.
>>
>
> Right, but what checks that the data is not col
Myles Watson wrote:
> On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka
> wrote:
>
>> On 12/11/2009, Myles Watson wrote:
>>
> This doesn't seem like it should be a config option any more.
>
Ideally, it will become some automatic "as small as possible"
configurat
Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>>> Right, but what checks that the data is not colliding with something
>>> else.
>>>
>> Like?
>>
>
> Like another table? Or is this the first thing written - and
> everything aft
Knut Kujat wrote:
> Hi,
>
> I'm trying to get coreboot running on a A8V-E SE MOBO with a Athlon64
> 3800+ on it, I have Suse 11.0 running on it and tried to compile
> coreboot. The first make worked fine I set up all the option I think
> necessary. But at the second time I execute make it stops wit
/Debugging
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE24567
ems.de • 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
bbreviations.
There is GPLed VSA but there never was and probably never will be GPLed
AGESA.
AMD planned to do this in 2006, but changed minds later again.
Stefan
> On Wed, Nov 18, 2009 at 8:26 AM, Stefan Reinauer
> wrote:
>
>> On 11/18/09 7:50 AM, Darmawan Salihun wrote:
>
. HRB 7656
Geschäftsführer: Stefan Reinauer . Ust-IdNr.: DE245674866
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 11/19/09 3:29 PM, Myles Watson wrote:
>> Therefore, I am sorry it took so long to get back to you.
>> Making the stack bigger did the trick, thanks a bunch! The drawback
>> however is that it fails at the end of the bootprocess now once coreboot
>> tries to load the payload (filo 0.5).
>>
M
ixes and
contributions to
this release.
See http://www.serialice.com/ for more information.
Comments and patches are of course very welcome!
Best regards,
Stefan Reinauer
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystem
On 11/23/09 11:08 AM, Bao, Zheng wrote:
>
> Since you need to call it in early stage, it is not good to put in pc80.
>
I don't think this is a problem... There is other code in src/pc80 that
runs in early stage, like mc4168rtc_early.c and usbdebug_direct_serial.c
src/pc80 seems like a better plac
901 - 1000 of 1444 matches
Mail list logo