Re: [coreboot] [PATCH] more Kconfig default fixes

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

Re: [coreboot] [v2] r4776 - trunk/coreboot-v2/src/arch/i386/lib

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

Re: [coreboot] [v2] r4780 - trunk/coreboot-v2/src

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

Re: [coreboot] [PATCH] Drop duplicate CPU subdirs-y entries for "../../x86/mtrr"

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..

Re: [coreboot] [PATCH] s289x ACPI fix

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

Re: [coreboot] [PATCH] Maximum/default console log level for kconfig

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",

Re: [coreboot] build service results for r4795

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

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

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

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

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

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

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

Re: [coreboot] PCI config

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

Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig

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

Re: [coreboot] [PATCH] Major cleanups of hard_reset() related code/config

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

Re: [coreboot] PCI config

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

Re: [coreboot] PCI config

• 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

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

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

[coreboot] [patch] console code cleanup

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

[coreboot] [PATCH] k8 uma and high tables

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

[coreboot] [PATCH] rework keyboard driver

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

[coreboot] [PATCH] Fix USB EHCI Debug Device for Intel ICH

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

[coreboot] [PATCH] refactor SMI handler

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: [coreboot] [patch] console code cleanup

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. >> >

Re: [coreboot] [PATCH] k8 uma and high tables

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

Re: [coreboot] [PATCH] Fix USB EHCI Debug Device for Intel ICH

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

Re: [coreboot] [PATCH] k8 uma and high tables

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

Re: [coreboot] [PATCH] refactor SMI handler

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

Re: [coreboot] [PATCH] rework keyboard driver

Myles Watson wrote: > > > 2009/10/23 Stefan Reinauer <mailto:ste...@coresystems.de>> > > Index: src/pc80/keyboard.c > === > --- src/pc80/keyboard.c (revision 4832) > +++

[coreboot] [PATCH] use intel core instead of core 2 on eagleheights

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

[coreboot] [PATCH] x86.c and x86emu/YABEL updates

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

[coreboot] [PATCH] usbdebug fixes for core / core 2

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

[coreboot] [PATCH] simplify keyboard "API"

: 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

[coreboot] [PATCH] resource allocator hole handling (simple and old)

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

[coreboot] [PATCH] reduce default verbosity of resource allocator

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

[coreboot] [PATCH] add proper "memory management" for high table area (aka CBMEM)

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

Re: [coreboot] [PATCH] More Kconfig changes

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

Re: [coreboot] [PATCH] refactor SMI handler

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.

Re: [coreboot] [PATCH] x86.c and x86emu/YABEL updates

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

Re: [coreboot] [PATCH] use intel core instead of core 2 on eagleheights

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-

Re: [coreboot] [PATCH] x86.c and x86emu/YABEL updates

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

Re: [coreboot] SMM included twice

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

Re: [coreboot] SMM included twice

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

[coreboot] [PATCH] ACPI updates + S3 Resume without hole at 31MB

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) @@ -

Re: [coreboot] [v2] r4863 - trunk/coreboot-v2/src/arch/i386/lib

/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

Re: [coreboot] [PATCH] cross compiler

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

Re: [coreboot] [PATCH] ACPI updates + S3 Resume without hole at 31MB

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

Re: [coreboot] [v2] r4875 - in trunk/coreboot-v2: . src/arch/i386 util/cbfstool util/sconfig

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

Re: [coreboot] [v2] r4874 - in trunk/coreboot-v2: . src/arch/i386/boot src/arch/i386/lib src/console src/devices src/include/device src/northbridge/intel/i440bx src/southbridge/intel/i82371eb util/rom

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

Re: [coreboot] [v2] r4871 - in trunk/coreboot-v2: src/arch/i386/boot src/arch/i386/include src/arch/i386/lib src/boot src/devices src/include src/include/cpu/x86 src/include/device src/lib src/pc80 sr

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

Re: [coreboot] small patch for prototypes and unused variables

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

Re: [coreboot] [PATCH] resource allocator hole handling (simple and old)

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

Re: [coreboot] small patch for prototypes and unused variables

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

Re: [coreboot] [PATCH] build vs. $(obj) in Makefiles (was Re: [v2] r4875 ...)

atson mailto:myle...@gmail.com>> Acked-by: Stefan Reinauer -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] D945GCLF

HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] Add prototypes for wrapped libgcc calls

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

Re: [coreboot] [v2] r4886 - in trunk/coreboot-v2/util: . amdtools amdtools/example_input

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

[coreboot] [PATCH] We're not just version 2 anymore

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

Re: [coreboot] grub as coreboot payload

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:

Re: [coreboot] FW: [PATCH]: vga bios was added into image by cbfstool, not by "cat" any more.

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

[coreboot] SerialICE - Qemu based x86 firmware debugger

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

Re: [coreboot] [PATCH] We're not just version 2 anymore

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.

Re: [coreboot] [PATCH] Add prototypes for wrapped libgcc calls

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

Re: [coreboot] [PATCH] ACPI updates + S3 Resume without hole at 31MB

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

Re: [coreboot] [v2] r4889 - trunk/coreboot-v2/src/devices

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

Re: [coreboot] [PATCH] We're not just version 2 anymore

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

Re: [coreboot] [PATCH] We're not just version 2 anymore

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

Re: [coreboot] FW: [PATCH]: vga bios was added into image by cbfstool, not by "cat" any more.

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

Re: [coreboot] FW: [PATCH]: vga bios was added into image by cbfstool, not by "cat" any more.

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

Re: [coreboot] [PATCH] Remove warnings

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

Re: [coreboot] [PATCH] We're not just version 2 anymore

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

Re: [coreboot] [PATCH] Remove warnings

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

Re: [coreboot] [PATCH] We're not just version 2 anymore

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

Re: [coreboot] Error executing VGA ROM with coreboot

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

Re: [coreboot] [PATCH] cross compiler

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

Re: [coreboot] [PATCH] Start unifying ram_check() usage in coreboot

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

[coreboot] UPDATE YOUR REPOSITORIES

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

Re: [coreboot] UPDATE YOUR REPOSITORIES

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

[coreboot] [PATCH] x86emu: add SMSW, RDMSR, WRMSR, INVD, WBINVD

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

[coreboot] [PATCH] Atom 106cx fixes

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

Re: [coreboot] [PATCH] x86emu: add missing ops

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

Re: [coreboot] [PATCH] Atom 106cx fixes

ron minnich wrote: > Acked-by: Ronald G. Minnich > > thanks, r4907 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Puzzles about coreboot when compiling "Kontron 986LCD-M"

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

Re: [coreboot] [PATCH] ACPI updates + S3 Resume without hole at 31MB

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

Re: [coreboot] [PATCH]cbfs locate function

; 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

Re: [coreboot] [v2] r4925 makes my linux hang

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

Re: [coreboot] [PATCH] ACPI updates + S3 Resume without hole at 31MB

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

Re: [coreboot] [v2] r4925 makes my linux hang

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.

Re: [coreboot] [v2] r4925 makes my linux hang

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

Re: [coreboot] [v2] r4925 makes my linux hang

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

Re: [coreboot] Coreboot bug?

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? >>> >>

Re: [coreboot] Coreboot bug?

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

Re: [coreboot] [PATCH]clean up bootblocksize handling in cbfstool, kconfig

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

Re: [coreboot] Coreboot bug?

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

Re: [coreboot] building coreboot for A8V-E SE compiling errors

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

Re: [coreboot] [v2] r4925 makes my linux hang

/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

Re: [coreboot] Looking for AMD AGESA GPL-ed source code

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

Re: [coreboot] Looking for AMD AGESA GPL-ed source code

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: >

[coreboot] SerialICE mailing list

. HRB 7656 Geschäftsführer: Stefan Reinauer . Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] failing fam10 code in 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

[coreboot] SerialICE 1.5 released - Qemu based firmware debugger

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

Re: [coreboot] [PATCH] The PC buzzer for TIM-5690.

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

<    5   6   7   8   9   10   11   12   13   14   >