[coreboot] k8 status: it speaks for itself
CPU 804 Mhz Etherboot 5.4.3 (GPL) http://etherboot.org Drivers: VIA-VELOCITY/PCI Images: ELF Protocols: DHCP TFTP Relocating _text from: [000100e0,000349c0) to [0007b720,000a) Boot from (N)etwork or (Q)uit? Probing pci nic... Probing isa nic... I've committed the last set of changes which mainly consist of fixing a null pointer bug that I believe is in v2. Next steps are to better fill out the dts, and start working on the warnings etc. I get. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] k8 status: it speaks for itself
there is lots of work for those interested. Code style cleanups, vetting for more bogus code in k8, building a filo for this board, and so on. Help is welcome! thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Multiboot
On Thu, Sep 18, 2008 at 2:59 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Thanks. I'm surprised by the unconditional usage of multiboot, though. I > thought Ron and Stefan asked for unconditional lbtable and conditional > multiboot. Especially the unconditional inline asm instead of the old C > call to the payload worries me. > it's me and my dislike for conditional code and conditional structures. It always seems to bite us when we do it that way. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Multiboot
On Fri, Sep 19, 2008 at 6:33 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > Note the stage1/stage2 separation. It would require either: > > - multiboot.c to be linked in twice, once for stage1 and once for stage2 > > - multiboot.c to be split in two files, one for stage1 and one for stage2 build multiboot into stage 1, and its functions can be called from stage 2 thanks to carl-daniel. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v2: Two coding issues: asm invd, pci resources
On Fri, Sep 19, 2008 at 5:58 AM, Mats Erik Andersson <[EMAIL PROTECTED]> wrote: > 2) Has it been judged superfluous to support configuration entries > such as > > device pci 7.2 on # USB > io 0x20 = 0xe001ul > irq 0x3c = 0x0a > end > > on grounds that pci-devices _can_ do auto detection? I inserted two > instances of 'print_debug' to make sure that pci_set_resources() > is executed for the USB Host Controler, but the above specification > never came into action. Were they even parsed? > it makes sense to put as little device info as possible into the config. Unless this entry is essential it could be left out but ... note the irq setting. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
OK I am acking this patch. What I would request is that in future all the k8 code be processed by: indent -kr -i 8 before a patch is made. But we can clean this up, it is important to get this code in. Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
I think these are the proper extra copyright holders (from v3) * Copyright (C) 2002 Linux Networx * (Written by Eric Biederman <[EMAIL PROTECTED]> for Linux Networx) * Copyright (C) 2004 YingHai Lu -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] the patches of AMD s1g1 socket
On Fri, Sep 19, 2008 at 10:05 AM, Peter Stuge <[EMAIL PROTECTED]> wrote: > ron minnich wrote: >> But we can clean this up, it is important to get this code in. > > History shows that we don't, although we can, and that a few years > later someone else comes along and doesn't understand a thing. :\ > I've got a commitment from AMD to do a whitespace/copyright fix, and I trust 'em :-) It's gonna be fine :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD RS690 and SB600 documents
wonderful news! Thanks to you all at AMD! ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r869 - in coreboot-v3: mainboard/amd/serengeti northbridge/amd/k8
On Fri, Sep 19, 2008 at 1:28 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > How common are F0 and F1? Were they sold? > > If yes, and maybe also if no, I think we should detect them and let > the user know why nothing is working. > We can put that in. I had a discussion with marc and the feeling was that we should, rather, just support newer boards that can't run these ancient parts. I.e it will not be possible to use them, since the mainboards won't be supported. thanks, I (really* appreciate it when people read these patches! You've got an eagle eye. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] patch: make node id/core id available on all arch; really implement stop_ap
attached. We've been faking stop_ap in stage1 since the beginning. This is a proposed option that builds ron smp.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: make node id/core id available on all arch; really implement stop_ap
Thanks for the review Peter, here is try 2. Also, yes, the order of some includes had to change. ron smp2.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: make node id/core id available on all arch; really implement stop_ap
ok, I'm on travel for the next 10 days, so this won't get done :-)
On Sat, Sep 20, 2008 at 3:59 AM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> On 20.09.2008 06:51, ron minnich wrote:
>> Thanks for the review Peter, here is try 2.
>>
>> Also, yes, the order of some includes had to change.
>>
The include thing is a difference of opinion, I sometimes get in Plan
9 habits. I'm not concerned too much, sure I'll include it in
global_variables.h in 10 days.
>>
>
> While the new code is obviously what we wanted back then, please tell me
> why we pass BIST to stage1 if we totally ignore it. Should we die()
> early if bist!=0 or die even earlier in stage0?
Let's leave bist as a parameter. Just because we do not yet use it
does not mean we never will.
it's a hard problem. if BIST is non zero things are bad. But we need
to do a lot of work to even print a message.
> Please leave that comment in. Once we have to run raminit from each node
> (family 10h), that code will be run by all cores. I'd say that your
> original patch for this was better because it made execution conditional.
>
v2 runs raminit on all nodes on some machines now. But they will never
run this particular code. They will be given an
IPI with the address of the AP code to be run for starting their ram.
So checks for a non-zero core id are not needed here.
The most we should do:
stop_ap();
if (me.nodeid || me.coreid)
die("Things look dark");
The k8 raminit is a very interesting piece of code, worth learning
from. We've got some smart people out there :-)
If somebody wants to take this patch and improve it would be a big
help. I think we know what we need.
thanks
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The patch of AMD DBM690T board
any suggested boards people can buy to try this out? I need to buy a board anyway as i want to have two for development uses. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] splash screen
I need some help with getting a splashscreen up. This is a short deadline,, I am looking to have coreboot boot and show this screen for, say, 5 seconds. I need it working by oct. 20. If anyone has pointers on where to start in learning how to set this up, I would appreciate it. It needs to be on real hardware -- I might try it with a DBE62 if I can get one in time, or and ADL board if not. Any vendor who would like their logo on this splash (if it makes sense) be sure to send me your logo and your permission. This demo is for a cybersecurity workshop I am going to, various people in the US are realizing now that security concerns extend into the BIOS, and they're also understanding the value of an open source bios. Actually some folks are *very* concerned about what can go on in the BIOS as this point ... I will try to remember to put a recent talk up on the web site next week. thanks ron <>-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] what are ELF boot notes?
On Wed, Sep 24, 2008 at 11:23 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > > Hi, > > Does anyone know what "ELF boot notes" are? I've seen this reference in > coreboot-v2/src/arch/i386/boot/boot.c. There's a struct named elf_boot_notes > whose pointer is passed to the payload via %ebx, and a magic signature in > %eax as well. > IIRC elf boot notes is where we stashed the command line argument to mkelfimage. > This interface is not in v3. Does this mean it's no longer being used? yes, it is not being used. ELF parsing is not a default in v3 and will I hope someday be completely gone. You're going to need it in v2 as long as you have elfboot. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] what are ELF boot notes?
On Thu, Sep 25, 2008 at 5:10 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 12:14:15PM -0700, ron minnich wrote: >> yes, it is not being used. ELF parsing is not a default in v3 and will >> I hope someday be completely gone. > > I have a working patch already. Now the question is, since both options are > incompatible, which do we make the default? > muliboot ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: make node id/core id available on all arch; really implement stop_ap
On Sat, Sep 20, 2008 at 7:36 AM, ron minnich <[EMAIL PROTECTED]> wrote: > If somebody wants to take this patch and improve it would be a big > help. I think we know what we need. OK, I am back from travel and patches are going to start up again. Acked-by: Stefan Reinauer <[EMAIL PROTECTED]> r872. Thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] only fallback works, and only after cmos clear...
On Sun, Sep 28, 2008 at 4:14 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > Daniel Lindenaar wrote: >> I've now worked around this by changing my failover.c file to just >> return and thus boot the fallback image always... > > What happens if you change Config.lb to only have fallback and no > normal? > yes, that is how you want to do it. This is a weird one ... ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] debug_pubnames etc.
how do we build in such a way that these are NOT built in? Seems they are always there on fc9 and I for sure do not need/want them. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] buildrom: Add serengeti-cheetah to the v3 family
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom: [PATCH] Fully working EON EN29F002NT
note to all: we did find, long ago, on one mainboard with one particular chip, that a POST cycle at the wrong time would hang flashrom. The issue is that every POST cycle is a failed cycle, in the sense that no device ever responds. The chipset timeout cycle was long enough to glitch the timing. Linux does indeed have some POST cycles in the kernel. So, it is possible that on some chipsets, now and in the future, this could be an issue. The best part is that the actual problem can appear or not appear depending on chipset, revision, and bios revision. Isn't that fun? Just an FYI. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] buildrom: make external build dir work for CBv3 too
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> I think this is a great idea. It makes it easy for us to build our fallback and normal images. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] libpayload
r774, make menuconfig compiles like this: gcc -m32 -Wall -Werror -fno-stack-protector -nostdinc -Iinclude -Ibuild -I/usr/lib64/gcc/x86_64-caos-linux-gnu/4.3.0/include -ffreestanding -c -o /home/rminnich/i945/trunk/filo/libpayload/build/util/kconfig/lxdialog/checklist.o /home/rminnich/i945/trunk/filo/libpayload/util/kconfig/lxdialog/checklist.c -nostdinc? Fails badly on my platofrm as the includes in -I/usr/lib64/gcc/x86_64-caos-linux-gnu/4.3.0/include are pretty limited. Is caos wrong or is the build a little wrong? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] K8 platforms should use PRINTK_IN_CAR
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]>
On Mon, Sep 29, 2008 at 3:48 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> This fixes the four platforms that the recent K8 changes broke.
> Thanks,
> Marc
>
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:[EMAIL PROTECTED]
> http://www.amd.com/embeddedprocessors
>
> AMD K8 platforms must use CAR so it makes sense to use the PRINK_IN_CAR
> option.
> This patch converts the following patches to use PRTINK_IN_CAR
> amd/serngeti_cheetah
> msi/ms9185
> msi/ms9828
> supermicro/h8dmr
>
> Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
>
> Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/Options.lb
> ===
> --- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/Options.lb
> 2008-09-29 16:05:06.0 -0600
> +++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/Options.lb 2008-09-29
> 15:07:22.0 -0600
> @@ -286,7 +286,7 @@
> ##
> ## The Serial Console
> ##
> -default CONFIG_USE_PRINTK_IN_CAR=0
> +default CONFIG_USE_PRINTK_IN_CAR=1
>
> # To Enable the Serial Console
> default CONFIG_CONSOLE_SERIAL8250=1
> Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
> ===
> --- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
>2008-09-29 16:09:17.0 -0600
> +++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
> 2008-09-29 15:15:47.0 -0600
> @@ -33,6 +33,7 @@
> #include "option_table.h"
> #include "pc80/mc146818rtc_early.c"
>
> +
> #if 0
> static void post_code(uint8_t value) {
> #if 1
> @@ -64,11 +65,6 @@
>
> #if CONFIG_USE_INIT == 0
>#include "lib/memcpy.c"
> - #if CONFIG_USE_PRINTK_IN_CAR == 1
> - #include "lib/uart8250.c"
> - #include "console/vtxprintf.c"
> - #include "arch/i386/lib/printk_init.c"
> - #endif
> #endif
> #include "northbridge/amd/amdk8/debug.c"
> #include "cpu/amd/mtrr/amd_earlymtrr.c"
> Index: coreboot-v2/src/mainboard/amd/serengeti_cheetah/apc_auto.c
> ===
> --- coreboot-v2.orig/src/mainboard/amd/serengeti_cheetah/apc_auto.c
> 2008-09-29 16:17:07.0 -0600
> +++ coreboot-v2/src/mainboard/amd/serengeti_cheetah/apc_auto.c 2008-09-29
> 15:16:43.0 -0600
> @@ -24,11 +24,6 @@
>
> #if CONFIG_USE_INIT == 0
>#include "lib/memcpy.c"
> - #if CONFIG_USE_PRINTK_IN_CAR == 1
> - #include "lib/uart8250.c"
> - #include "console/vtxprintf.c"
> - #include "arch/i386/lib/printk_init.c"
> - #endif
> #endif
>
> #include "arch/i386/lib/console.c"
> Index: coreboot-v2/src/mainboard/msi/ms9185/Options.lb
> ===
> --- coreboot-v2.orig/src/mainboard/msi/ms9185/Options.lb2008-09-29
> 16:18:48.0 -0600
> +++ coreboot-v2/src/mainboard/msi/ms9185/Options.lb 2008-09-29
> 15:21:44.0 -0600
> @@ -104,7 +104,7 @@
> uses CONFIG_PCI_64BIT_PREF_MEM
>
> uses CONFIG_LB_MEM_TOPK
> -
> +uses CONFIG_USE_PRINTK_IN_CAR
>
> ###
> ### Build options
> @@ -222,7 +222,7 @@
> default DCACHE_RAM_BASE=0xcc000
> default DCACHE_RAM_SIZE=0x04000
> default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
> -default CONFIG_USE_INIT=0
> +default CONFIG_USE_INIT=0
>
> ##
> ## Build code to setup a generic IOAPIC
> @@ -287,6 +287,7 @@
> ##
> ## The Serial Console
> ##
> +default CONFIG_USE_PRINTK_IN_CAR=1
>
> # To Enable the Serial Console
> default CONFIG_CONSOLE_SERIAL8250=1
> Index: coreboot-v2/src/mainboard/msi/ms9282/Options.lb
> ===
> --- coreboot-v2.orig/src/mainboard/msi/ms9282/Options.lb2008-09-29
> 16:28:46.0 -0600
> +++ coreboot-v2/src/mainboard/msi/ms9282/Options.lb 2008-09-29
> 15:22:01.0 -0600
> @@ -100,6 +100,7 @@
> uses CONFIG_COMPRESSED_PAYLOAD_LZMA
> uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
> uses CONFIG_PRECOMPRESSED_PAYLOAD
> +uses CONFIG_USE_PRINTK_IN_CAR
>
> ## ROM_SIZE is the size of boot ROM that this board will use.
> #512K bytes
> @@ -203,7 +204,6 @@
> default APIC_ID_OFFSET=0x10
> default LIFT_BSP_APIC_ID=0
>
> -
> ##
> ## Build code to setup a generic IOAPIC
> ##
> @@ -267,7 +267,8 @@
> ##
> ## The Serial Console
> ##
> -
> +default CONFIG_USE_PRINTK_IN_CAR=1
> +
> # To Enable the Serial Console
> default CONFIG_CONSOLE_SERIAL8250=1
>
> Index: coreboot-v2/src/mainboard/supermicro/h8dmr/Options.lb
> ===
> --- coreboot-v2.orig/src/mainboard/supermicro/h8dmr/Options.lb 2008-09-29
> 16:35:16.0 -0600
> +++ coreboot-v2/src/mainboard/supermicro/h8dmr/Options.lb 2008-09-29
> 15:21:14.0 -0600
> @@ -236,7 +236,7 @@
> default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000
> default CONFIG_USE_INIT=0
>
> -default CONFIG_AP_CODE_IN_CAR=0
>
Re: [coreboot] [v2][patch] update k8 fid/vid setup
If some enterprising person wants to try to apply this to v3 that would help. I know there are people out there looking for ways to help, and this is one of them. I can verify the patch. We are getting closer to having k8 support ready in v3, such that new platforms can go into v3 first. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Master degree student wanting to give some help.
On Tue, Sep 30, 2008 at 7:35 AM, bari <[EMAIL PROTECTED]> wrote: > It would be great if you could get the AM2, 690/600 code to work on a few > production boards that are readily available through distributors. > > I'd be happy to get you a board to start on and supervise. > we sure could use the help on getting this on v3. I'm really anxious to get our v3 support up for the new k8 and k10 boards. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot gpxe
is this better or are we still unable to use gpxe? What does it require? Just the elf file creation? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fam10h support for Tyan S2912-E (1/2)
On Tue, Sep 30, 2008 at 8:57 AM, Marc Jones <[EMAIL PROTECTED]> wrote: > Peter Stuge wrote: >> >> Arne Georg Gleditsch wrote: >>> >>> Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912. >> >> Why? Isn't it better to only have one target that supports both CPU >> types? > > > The target has different build and cpu init requirements. We want to work > towards a combined ROM that supports both CPUs but that doesn't exist yet. > that should be a v3 effort anyway. It's fine to clone because it is easier to see the differences. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD RS690 / SB600 candidate boards with socketed ROM
On Tue, Sep 30, 2008 at 9:00 AM, Uwe Hermann <[EMAIL PROTECTED]> wrote: > See http://www.coreboot.org/Desktops for details. > lots of options. Let's pick one we can all use and go for that. Suggestions? I'm ready to order ... ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD RS690 / SB600 candidate boards with socketed ROM
On Tue, Sep 30, 2008 at 9:24 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote: > On 30/09/08 09:15 -0700, ron minnich wrote: >> On Tue, Sep 30, 2008 at 9:00 AM, Uwe Hermann <[EMAIL PROTECTED]> wrote: >> >> > See http://www.coreboot.org/Desktops for details. >> > >> >> lots of options. Let's pick one we can all use and go for that. >> Suggestions? I'm ready to order ... > > If you want my honest opinion, I think it would be better in the long > run for the project if everybody picked something *different*. > as long as it gets to be more than me writing the v3 code, that makes sense. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot gpxe
On Tue, Sep 30, 2008 at 10:24 AM, Peter Stuge <[EMAIL PROTECTED]> wrote: > ron minnich wrote: >> is this better or are we still unable to use gpxe? >> >> What does it require? Just the elf file creation? > > http://www.whiterocker.com/gpxe/ > wow! that is ever so much smarter than what I am doing now. Thanks! ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] if I can get just one other person for the 690 port
just one person who can take the time to do some testing ... I'll start on the v3 work this week. Now there's a nice deal, right :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] if I can get just one other person for the 690 port
On Tue, Sep 30, 2008 at 2:20 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > ron minnich wrote: >> just one person who can take the time to do some testing ... I'll >> start on the v3 work this week. >> >> Now there's a nice deal, right :-) > > You had me with the m57sli but I don't have a 690 board. :\ > ok, then, m57sli comes first if you can do testing! ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r877 - in coreboot-v3: arch/x86/amd/model_fxx mainboard/gigabyte/m57sli northbridge/amd/k8 southbridge/nvidia/mcp55
On Wed, Oct 1, 2008 at 7:02 AM, ron minnich <[EMAIL PROTECTED]> wrote: >> What's in stage0 that makes it so big? Is that part really required in >> stage0? > > hyptertransport setup has to be in stage0. I can't see a way around it. > The issue is that the mcp55 needs this function: set_ht_link_buffer_counts_chain and that in turn brings in all of incoherent_ht. I will see if I can seperate these out. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r877 - in coreboot-v3: arch/x86/amd/model_fxx mainboard/gigabyte/m57sli northbridge/amd/k8 southbridge/nvidia/mcp55
On Wed, Oct 1, 2008 at 2:32 AM, Stefan Reinauer <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >> Author: rminnich >> Date: 2008-10-01 09:23:05 +0200 (Wed, 01 Oct 2008) >> New Revision: 877 >> >> Modified: >>coreboot-v3/arch/x86/amd/model_fxx/init_cpus.c >>coreboot-v3/mainboard/gigabyte/m57sli/mainboard.h >>coreboot-v3/northbridge/amd/k8/dqs.c >>coreboot-v3/northbridge/amd/k8/raminit.c >>coreboot-v3/southbridge/nvidia/mcp55/ide.c >>coreboot-v3/southbridge/nvidia/mcp55/lpc.c >>coreboot-v3/southbridge/nvidia/mcp55/mcp55.c >>coreboot-v3/southbridge/nvidia/mcp55/pci.c >>coreboot-v3/southbridge/nvidia/mcp55/pcie.c >>coreboot-v3/southbridge/nvidia/mcp55/sata.c >>coreboot-v3/southbridge/nvidia/mcp55/usb2.c >> Log: >> m57sli mostly builds again. The stage0 is too large at 24k. >> We need to figure out if we should just grow stage0. My inclination is >> to say 'yes'. >> > > What's in stage0 that makes it so big? Is that part really required in > stage0? hyptertransport setup has to be in stage0. I can't see a way around it. > > If so, we need to grow stage0. But we should try to answer that question > first. yes, I was able to hold the line on serengeti but m57sli needs more. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is Coreboot selfmodifying? Award legacy Bios is!
we don't rewrite flash. Yes, this is hazardous I think as well. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
here is the current version of the splash screen. Now, I *know* there are others of you out there who have helped. If you want your logo on here, please send it to me -- .svg is preferred. What is a good mode for int 10 4f02 to use for this? thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
OK I should read my mail more ... mode 3 it is. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
On Wed, Oct 1, 2008 at 11:47 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote: > On 01/10/08 11:03 -0700, ron minnich wrote: >> OK I should read my mail more ... mode 3 it is. > > No - not mode 3. You'll want to kick into a VESA mode of suitable > size so you can draw directly to the framebuffer. > I'm trying x117 now? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Master degree student wanting to give some help.
Cedric this is good news. You'll be working on v3 right :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Some v3 Kconfig options into dts?
On Wed, Oct 1, 2008 at 12:44 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >> config K8_SCAN_PCI_BUS >> + Whether to scan the PCI bus in stage1. >> I adopted this from v2 but it would only be a mainboard issue; it should never be in dts since it's not an option anyone should ever set. >> config K8_ALLOCATE_IO_RANGE >> + Whether to allocate I/O space in stage1. >> >> config K8_ALLOCATE_MMIO_RANGE >> + Whether to allocate MMIO space in stage1. > same. >> config LOGICAL_CPUS >> + How many logical CPUs there are. FIXME. >> should always be determined dynamically by what cpus are installed. >> config MAX_PHYSICAL_CPUS >> + Maximum number of physical CPUs (sockets). > > dts? > This comes down to wires. I don't see it in the dts. > >> config MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED >> + Config with 4 CPUs even if more are installed. > > But I think this should stay in Kconfig. > yes. It's a bizarre variable which I hope to remove some day. > >> config CROSS_BAR_47_56 >> + Configure for the type of crossbar on the mainboard. > > dts? no. It's wires. > > >> help >> This option is used to determine whether the mainboard has >> + a PIRQ table, which is the old way to set up interrupt routing. >> It is usually set in mainboard/*/Kconfig. >> >> config ACPI_TABLE >> boolean >> help >> This option is used to determine whether the mainboard has >> + an ACPI table. >> It is usually set in mainboard/*/Kconfig. > > dts? no. it's a build option. > > >> config SMP > >> depends CPU_I586 || CPU_AMD_K8 >> default 0 >> help >> + This option is used to enable certain functions to make coreboot >> + work correctly on symmetric multi processor systems. >> It is usually set in mainboard/*/Kconfig. > > Could this be derived from the number of logical CPUs? Yes. this is not an OS, it's a BIOS, and SMP should always be enabled. > > >> config IOAPIC >> @@ -153,7 +152,7 @@ >> depends ARCH_X86 && CPU_AMD_K8 >> default 0 >> help >> + If you want to configure an IOAPIC, set this. > > Will the builder really have an opinion on this? Isn't it chip > dependent? (ie -> dts?) it's something they should never want to see or change. Not even dts. > > >> config K8_HT_FREQ_1G_SUPPORT >> + 1 GHz support. Opteron E0 or later can support 1G HT, >> + but still depends on the mainboard. > > dts? no, it's a mainboard issue. > > >> config HT_FREQ_800MHZ >> + Can we run HT at 800 MHz. > > dts? same. > > >> config USBDEBUG_DIRECT >> depends SOUTHBRIDGE_NVIDIA_MCP55 > > Chip specific and board specific so a chip dts setting that is > filtered through the board dts and can make a Kconfig option visible > that the builder can use to disabled USB debug output? Here's the big issue. There are things that can be set in Kconfig AND in dts; there are things that are settings that should not be in Kconfig OR dts, because setting them could cause Bad Things To Happen. For that latter type of variable, I just created mainboard.h. For the Kconfig/dts issue, it's a judgement call. Possibly the best thing to do is have the dts able to use Kconfig variables in some settings: baud = "CONFIG_TTYS0_BAUD"; > > >> config APIC_ID_OFFSET >> + This is entirely mainboard dependent. > > dts? no, I don't ever want a person building a bios to think this is a variable they should touch. But it really gets down to the role of the dts. I think of it as something people can change. Things that can never change don't belong in dts or Kconfig I think. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
On Wed, Oct 1, 2008 at 2:48 PM, Jordan Crouse <[EMAIL PROTECTED]> wrote: > But as always, I'm open for suggestions to the contrary. What do > you think? > I think you're always right. [I'm serious!] Let's do it. We'll use that standard. I realize this seems like a silly project. I don't much like splashscreens myself. But I've found the hard way that Purty Pictures often win over substance. It's almost as if politics were a beauty contest or something. I think the splash screen is going to have impact -- I think very positive impact. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Some v3 Kconfig options into dts?
On Wed, Oct 1, 2008 at 3:40 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > My idea was that dts are pure hardware description and Kconfig should be > pure feature and board selection. That's a good point and I think Peter was making it as well. > > >>> [EMAIL PROTECTED] wrote: >>> config K8_SCAN_PCI_BUS + Whether to scan the PCI bus in stage1. >> >> I adopted this from v2 but it would only be a mainboard issue; it >> should never be in dts since it's not an option anyone should ever >> set. >> > > I'm not sure I understand this completely. Do you suggest to keep > mainboard settings nobody should ever touch out of the dts? on re-reading this I am no longer so sure. BUT: remember that some of this stuff is stage1 and dts is not there in stage1. This is arguably a design problem. But after two years I am tired of designing and want to get this thing running :-) > > config K8_ALLOCATE_IO_RANGE + Whether to allocate I/O space in stage1. config K8_ALLOCATE_MMIO_RANGE + Whether to allocate MMIO space in stage1. >> >> same. >> > > Are there any boards which need the option? There probably are else it would not be in there :-) > config MAX_PHYSICAL_CPUS + Maximum number of physical CPUs (sockets). >>> dts? >>> >>> >> >> This comes down to wires. I don't see it in the dts. >> > > So it's a hardware description. In theory, we could derive the number of > sockets from the dts if we ever place complete HT tree info there. yeah, good point. But the HT tree is even deeper in startup. You can't, for example, expand FLASH decoding to large size until you've wired up hypertransport, There is always going to be a chicken-and-egg issue with these early bits. > > config MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED + Config with 4 CPUs even if more are installed. >>> But I think this should stay in Kconfig. >>> >>> >> >> yes. It's a bizarre variable which I hope to remove some day. >> > > Should it really be user-selectable? If so, would NVRAM be a better place? I am not sure. > > config CROSS_BAR_47_56 + Configure for the type of crossbar on the mainboard. >>> dts? >>> >> >> no. It's wires. >> > > Hardware description -> dts. You win. (You too peter!) > config IOAPIC @@ -153,7 +152,7 @@ depends ARCH_X86 && CPU_AMD_K8 default 0 help + If you want to configure an IOAPIC, set this. >>> Will the builder really have an opinion on this? Isn't it chip >>> dependent? (ie -> dts?) >>> >> >> it's something they should never want to see or change. Not even dts. >> > > If it is mainboard-hardware-specific and should not be changed, we > should place it in the dts. you win again! I am losing bonus points! > > config K8_HT_FREQ_1G_SUPPORT + 1 GHz support. Opteron E0 or later can support 1G HT, + but still depends on the mainboard. >>> dts? >>> >> >> no, it's a mainboard issue. >> > > dito. yeah. Except we need to see if this comes up in stage 1. > > I'd like to treat the dts as "don't touch" for normal users anyway. It's > hardware description and users are extremely unlikely to change the > board wiring. which is fine but there are going to be some variables set in kconfig which might need to change variables in dts. > > >> For that latter type of variable, I just created mainboard.h. For the >> Kconfig/dts issue, it's a judgement call. Possibly the best thing to >> do is have the dts able to use Kconfig variables in some settings: >> baud = "CONFIG_TTYS0_BAUD"; >> > > Hm. That's an interesting idea. Maybe we could couple it with my "dts > from stage1" idea. mainboard.h is a stopgap, I bet, until we get your idea. > > That's where our understanding about the role of the dts differs. IMO > there should not be any reason why anybody would touch the dts (except > maybe for configurations like a FPGA in an Opteron socket). umm :-) So we don't touch it unless we need to touch it? That worries me. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Some v3 Kconfig options into dts?
On Wed, Oct 1, 2008 at 4:09 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > I have 296 coreboot mails to reply to, so this will probably take a few > days. > 296!?!? Yikes! thanks, I needed that chuckle :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
On Wed, Oct 1, 2008 at 4:16 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > ron minnich wrote: >> almost as if politics were a beauty contest > > I think it's about pleasing people. Beautiful things go a long way. > Yeah, I was making an indirect joke about our election :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
On Wed, Oct 1, 2008 at 4:19 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Wed, Oct 1, 2008 at 4:16 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: >> ron minnich wrote: >>> almost as if politics were a beauty contest >> >> I think it's about pleasing people. Beautiful things go a long way. >> > > Yeah, I was making an indirect joke about our election :-) > and let's leave it at that, we've never had a political discussion on this list and I apologize for even hinting at one :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Status of OpenVSA?
On Thu, Oct 2, 2008 at 3:21 AM, Stephen Crocker <[EMAIL PROTECTED]> wrote: > I have been experimenting with the OpenVSA code and have found that it > becomes stuck on POST code 17. By adding extra codes, I have narrowed this > down to the SAVE_STATE macro, which reads the PCI address port (cf8). > > Furthermore, in order to build it, I had to remove the -Werror flag from the > Makefile because of several "cast from pointer to integer of different size" > errors. I think you really want to fix that error. I don't like to let that kind of thing go by. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r877 - in coreboot-v3: arch/x86/amd/model_fxx mainboard/gigabyte/m57sli northbridge/amd/k8 southbridge/nvidia/mcp55
On Thu, Oct 2, 2008 at 6:34 AM, Stefan Reinauer <[EMAIL PROTECTED]> wrote: > ron minnich wrote: >>>> m57sli mostly builds again. The stage0 is too large at 24k. >>>> We need to figure out if we should just grow stage0. My inclination is >>>> to say 'yes'. >>>> >>>> >>> What's in stage0 that makes it so big? Is that part really required in >>> stage0? >>> >> >> hyptertransport setup has to be in stage0. I can't see a way around it. >> > > Why? Can't this go to initram? > not for the mcp55. I am gong to do a quick detour to 690 support, it looks not too bad and the nvidia parts are making my head hurt. I just remembered the special microcode support they need, with the special ldscript Owie. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
On Thu, Oct 2, 2008 at 7:36 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote: > Thats just my opinion - as always, patches are gladly accepted. Just > remember who we are, what we are doing. Somebody at the Linux Plumbers > Conference said, "Every time I see a splash screen, I wonder what they > have to hide". Coreboot is the only loader on earth that doesn't actually > have anything to hide. Lets try not to go overboard architecting a solution > for one problem we don't have. > in fact I may let linux do the splash screen anyway -- all other options are looking painful. Remember the original linuxbios slogan? "Let Linux do it". One thing I've noticed is that, having dropped Linux as a primary payload, we are recreating lots of code for things linux can already do. Once we start to implement IPV6 in a payload, we need to stop and think hard about what we are doing. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] sb600 support in v3
I just committed it, because I want some eyeballs on it. Corrections etc. welcome. rs690 is next, then the socket, then the mainboard. This should be interesting. I'm trying to get a simnow for this board, but it's the nda version, so I'm still working it. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] splash screen
On Thu, Oct 2, 2008 at 9:01 AM, Patrick Georgi <[EMAIL PROTECTED]> wrote: > ron minnich schrieb: >> Remember the original linuxbios slogan? "Let Linux do it". >> > Just that Linux grew _large_. (and its devs have no interest in being > firmware agnostic) yes, they lost their way. "We don't need no steenking BIOS" is no longer true. I wonder if they removed that quote yet. What a shame. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
did you get any serial IO? do a bx fff0, reset it, and start it up. I notice I always have to reset each time I start it. No idea why. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] stop_ap is missing for QEMU, breaks v3 compile
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> it will be nice if we ever get smp qemu. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
On Thu, Oct 2, 2008 at 1:58 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > I can't get v3 for simnow to work with coreinfo as the payload. I get no > VGA even if I enable it, VGA is never mentioned in the boot log, and it ends > with a triple fault: > > cisc-cpu.cpp: CProcessor::GenerateException(): shutdown due to triple fault > > Fatal error reached, stopping simulation. Error message(s) follow: > > cisc-cpu.cpp: CProcessor::GenerateException(): shutdown due to triple fault > > NOTE: Simulation cannot be restarted until a reset is asserted. > Simulation state CAN be inspected with the SimNow debugger. > > -- end triple fault -- > > This error shows up in the boot log for simnow 4.4.4pub: > k8_domain_scan_bus > pci_scan_bus start bus 0xce2c, bus->dev 0xcbe0 > ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is > PCI_DOMAIN: > PCI: pci_scan_bus for bus 00 > pci_scan_bus: old_devices 0xcee0, dev for this bus 0xcbe0 (domain_0) > PCI: scan devfn 0xc0 to 0xff > I'll try it again tonight. > It also shows up now in QEMU (it didn't use to.) > pci_domain_scan_bus: calling pci_scan_bus > pci_scan_bus start bus 0xac0c, bus->dev 0xa9c0 > ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is > PCI_DOMAIN: > PCI: pci_scan_bus for bus 00 > > This "Not a multi function device" message is new to QEMU too. > PCI: 00:00.0 [PCI: 8086:1237] enabled > PCI: pci_scan_bus pci_probe_dev returns dev 0xb918(dynamic PCI: 00:00.0) > Not a multi function device, or the device is not present. Skip to next it's just noise. I am glad to see you looking at simnow. Keep me posted and I will do what I can to help. We need more testers (we only have one :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] mode 117
it's not pretty but this is working to get into mode 117 on the
(private) tree I am using.
It's in the emulator. The 'entering emulator' is what you would see;
the first X86EMU_exec is when we run the vga bios.
src/devices/emulator/biosemu.c
The way it works is that I put an INT 10 at f, followed by a HLT.
It's ok to scribble there because that is the 55aa signature for the
expansion bios -- it's not needed any more, the BIOS is installed.
This appears to work. Tomorrow I'll try scribbling on the frame buffer
and see how it goes.
As Jordan has pointed out,coreboot starts up so fast that I'm going to
need to put a delay in to let the splash screen be visible. But this
is important enough that it is worth doing.
Now I need a modern opteron laptop :-)
thanks
ron
printk_info("entering emulator\n");
X86EMU_exec();
printk_err("Done; now try to set the mode to x117\n");
X86_AX = 0x4f02;
X86_BX = 0x117;
X86_CX = 1;
X86_DX = 0x0;
X86_DI = 0;
X86_EIP = 0x;
X86_CS = initialcs;
/* Initialize stack and data segment */
X86_SS = initialcs;
X86_SP = 0xfffe;
X86_DS = 0x0040;
X86_ES = 0x;
/* We need a sane way to return from bios
* execution. A hlt instruction and a pointer
* to it, both kept on the stack, will do.
*/
pushw(0xf4f4); /* hlt; hlt */
pushw(X86_SS);
pushw(X86_SP + 2);
#if 0
1.code16
2 CD10 int $0x10
3 0002 F4hlt
4 0003 F4hlt
#endif
MEM_WB(initialcs<<4+0, 0xCD);
MEM_WB(initialcs<<4+1, 0x10);
MEM_WB(initialcs<<4+2, 0xF4);
MEM_WB(initialcs<<4+3, 0xF4);
// MEM_WB(initialcs<<4+0, 0xF4);
// X86EMU_trace_on();
printk_err("entering emulator\n");
X86EMU_exec();
printk_err("Mode should now be set\n");
#endif
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
On Thu, Oct 2, 2008 at 7:36 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > It was after the payload started. The serial console gets cleared and then > there is no more output until the triple fault. > can you try filo? I would like to see if we can get at least to both having filo work. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH v2] CAR for C7, newest version
I can't tell if it will work until we test. But I trust you both, it looks fine. Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r881 - in coreboot-v3/southbridge/amd: . sb600
On Thu, Oct 2, 2008 at 9:34 PM, Peter Stuge <[EMAIL PROTECTED]> wrote: > I'm not thrilled with how stage1 code is scattered about, I would > like stage1 to be able to pull in code from components in an orderly > fashion. This looks good for now though. > you mean the three files in the sb600 directory? They have to be seperated out. The day may come when a system with an sb600 has a different chip for usb. Sounds crazy but we've seen that sort of thing before. Or do you mean something else? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
On Fri, Oct 3, 2008 at 8:29 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > Filo 75 comes up to its grub-like prompt in the serial console. Even though > I enable option ROMS, VGA doesn't get initialized. > and coreinfo requires vga? I'd like to take on one broken thing at a time :-) shall we take on vga? I don't think I'm even putting a vga bios in there yet. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] patch: all superios in v3 are set up wrong
attached. ron superio.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix ITE IT8712F pnp_dev_info[] items
I just submitted a patch for this part for v3, If you want to correct my patch I would be grateful. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] dbm690t initial attempt which fails; not signed off
I could use some help here; what am I doing wrong? attached. ron dbm690t.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard tricks in SimNOW?
I don't know the trick but you can always just look at the view config space window :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: all superios in v3 are set up wrong
I appreciate the very high quality and fast review. The ite8712f is wrong I am sure. I have tried to fix this patch to address the reviews. Let me know what you think. Thanks ron superio2.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] dbm690t initial attempt which fails; not signed off
On Fri, Oct 3, 2008 at 9:59 AM, Peter Stuge <[EMAIL PROTECTED]> wrote: > Add this after endchoice: > > config MAINBOARD_DIR >string >default amd/dbm690t >depends BOARD_AMD_DBM690T ah, right, thanks. I don't know how I missed that. OK, now later this weekend I get to track all the compile errors :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard tricks in SimNOW?
On Fri, Oct 3, 2008 at 10:34 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > It seems that DSL doesn't empty the keyboard buffer for some reason. If I > keep typing long enough it gives this warning: > > m_KybKeyBuffer: dropping byte 24 buffer full > > Interesting that this only happens after it boots. I can type at the boot > prompt as long as I type slowly. > this sounds like interrupts are not happening. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Missing devices in v3 serengeti
On Fri, Oct 3, 2008 at 11:03 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > 1 4 0 Display Controller (Factory and v2, missing in v3) > 1 5 0 82540 Gigabit Eth (Factory and v2, missing in v3) > is this as simple an issue as a missing dts entry? I'm not near the build machine right now. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] triple fault in SimNOW
how are you switching? close the bsd, or just change the bios rom and reset and go? I'm not totally inclined to totally trust the sim depending on how you are doing the switch. The sim seems to like reset between switching bios flash parts. My procedure is to have a coreboot bsd, and always close and open that bsd when I change things; and, finally, once the bsd opens, I always hit reset. I start with a break at fff0 to make doubly sure I started up ok. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
On Thu, Oct 2, 2008 at 12:55 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Hi Ron, > > you accidentially committed the SB600 v3 stuff into the v2 tree. Do you > want to revert or should I take care of that? > revert. My apologies. I accidentally picked up the .svn from v2 and so I committed to the v2 tree. That was dumb ... ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
On Fri, Oct 3, 2008 at 3:41 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > Ron and Carl-Daniel, > > How are we fixing this? v2 is broken right now. > do you want to pick up my mess? I don't trust myself at present. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] triple fault in SimNOW
OK I have this nice laptop with 2G for simnow. This is a bit faster than what I was using. If only X had a radeon 1100 driver I could do more than 640x480 :-) Anyway I just got v3 to get to filo and now I can look at the problem you're having. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3630 build service
On Fri, Oct 3, 2008 at 3:57 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > I wasn't going to undo the history. I am not that skilled. I was just going > commit on top of that change. > commit over the change with the comment "Ron owes me big time" ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Missing devices in v3 serengeti
I think our bus setup is not working. We never scan bus 1. That's a place to start llooking. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Missing devices in v3 serengeti
one last note: I see this in the output. PCI: pci_scan_bus for bus 01 pci_scan_bus: old_devices 0x, dev for this bus 0x00011010 (dynamic PCI: 00:0b.0) PCI: scan devfn 0x0 to 0xff PCI: devfn 0x0 it's certainly trying to scan bus 1. So next guess is that the config space routing is wrong? or pci1234 is wrong? Myles, if you get a chance, you might see in config space for 18:0.0 what is going wrong. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Kill 'pnp_ops', have all Super I/Os use their own 'ops'
On Sat, Oct 4, 2008 at 8:35 AM, Stefan Reinauer <[EMAIL PROTECTED]> wrote: > Uwe Hermann wrote: >> Please correct me if I'm wrong, but I think pnp_ops will never be used >> anyway (every Super I/O defines its own 'ops' struct)... >> >> > > Stupid question, but could we instead drop all the superio chips' own > ops instead? I had the same question. Can't we use the generic ops? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: all superios in v3 are set up wrong
I hope I got all the points that Uwe mentioned, but it was pretty urgent to get this commit in. Committed revision 888. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] patch: print out msg level on printk
This patch provides output like this:
<8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 initialized 1
<7>Stage2 code done.
<6>LAR: Attempting to open 'normal/payload/segment0'.
<8>LAR: Start 0xfff8 len 0x8
<8>LAR: seen member normal/[EMAIL PROTECTED], size 1776
<8>LAR: seen member normal/initram/[EMAIL PROTECTED], size 31644
We can thus get SPEW data but then easily filter it by log level.
Index: lib/console.c
===
--- lib/console.c (revision 884)
+++ lib/console.c (working copy)
@@ -136,8 +136,14 @@
return 0;
}
+ console_tx_byte('<', (void *)0);
+ console_tx_byte(msg_level + '0', (void *)0);
+ console_tx_byte('>', (void *)0);
+
+ i = 3;
+
va_start(args, fmt);
- i = vtxprintf(console_tx_byte, (void *)0, fmt, args);
+ i += vtxprintf(console_tx_byte, (void *)0, fmt, args);
va_end(args);
return i;
Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
But better code is welcome.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: print out msg level on printk
On Sun, Oct 5, 2008 at 3:54 PM, Stefan Reinauer <[EMAIL PROTECTED]> wrote: > I think printing the log level makes sense only if there's a klogd > running on the other side. But I don't particularly care either. It > should be an option, and yes, it should be fixed the way Carl-Daniel > suggests, if it goes in. > it's handy for debug. You can print at SPEW, and then easily run the text through a filter to get DEBUG or less. I'm not that worried about it going in; I can keep my own version handy. It's already proving to be very nice for me. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Menlow platform again - is anybody working on this?
does it have to be an atom? Not a Via or AMD part? can you get docs? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] v3 updates
I just pushed a lot of bits across. The problem with serengeti, if anybody wants to work on it, is that the 8111 device is not scanning its subordinate busses. It would be great if someone could take a look. The dbm690t is almost ready for test, once the stage0 fits.It's 23k. Help welcome. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
On Mon, Oct 6, 2008 at 11:06 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > I also noticed that phase3_scan is null in 8111_ops. Could that be the > problem? Which function should be used to scan this bus? I tried > pci_scan_bridge and pci_domain_scan_bus, but neither Just Worked for me. > yes, missing phase3_scan is bad. I wonder how I missed that. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
On Mon, Oct 6, 2008 at 11:59 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > Could you help me understand how we get from this picture from the 8111 data > sheet to the serengeti dts? It looks like to me that the nic and ide > portions should be included in the amd8111 dts, not the board dts. I'm also > confused why the ide and nic entries seem to be on the same bus. > nic and ide are in mainboard dts so we can set control variables. v3 is like v2 in that dts topology reflects mainboard topology but does also show some detailsof chipset topology. nic and ide on same bus? That's my mistake, pure and simple. The mainboard dts is wrong. We're in the learning phase here on dts for boards like this. We understand simple boards like geode boards. This is our first complex hierarchy board. Welcome to Adventure! ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 stage0
On Mon, Oct 6, 2008 at 1:15 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Hi, > > currently we have 3 different files with stage0 asm code sharing lots of > delicate code: > - amd/stage0.S > - geodelx/stage0.S > - stage0_i586.S > and all of them share at least the complete 16bit code which is near > unreadable in itself. > > Can we extract the 16bit code into a common file and include it? I know > that choice isn't going to be too popular because it makes the code more > greppy. However, keeping all instances of that code in sync is a major > headache and we even have remaining bugs in the common copied 32bit > parts of that code. > If that's not possible, I'd like to at least enforce a rule which keeps > the common 16-bit code bit-for-bit identical including comments. > one file is fine. The v32 code is a total nightmare, so I would really like to avoid turning it into that mess. I almost have a kscope setup ready for v3 and it will make it far less greppy! It's nice. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 stage0
What's happening to my typing today? Try again. I think the dbm690t work fried my brain. On Mon, Oct 6, 2008 at 1:46 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Mon, Oct 6, 2008 at 1:15 PM, Carl-Daniel Hailfinger > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> currently we have 3 different files with stage0 asm code sharing lots of >> delicate code: >> - amd/stage0.S >> - geodelx/stage0.S >> - stage0_i586.S >> and all of them share at least the complete 16bit code which is near >> unreadable in itself. >> >> Can we extract the 16bit code into a common file and include it? I know >> that choice isn't going to be too popular because it makes the code more >> greppy. However, keeping all instances of that code in sync is a major >> headache and we even have remaining bugs in the common copied 32bit >> parts of that code. >> If that's not possible, I'd like to at least enforce a rule which keeps >> the common 16-bit code bit-for-bit identical including comments. >> > > one file is fine. The v32 code is a total nightmare, so I would really > like to avoid turning it into that mess. > One include file is fine. I want to avoid the v2 experience but there is a middle ground and I think you could find it. Thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] patch: change Rules.make so that the dtc run is all or nothing
i.e. we don't end up with half-built statictree.[ch] ron make sure that the dtc runs correctly and we don't leave a half built statictree.[ch] Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]> Index: Rules.make === --- Rules.make (revision 899) +++ Rules.make (working copy) @@ -27,13 +27,17 @@ $(Q)printf " CC $(subst $(shell pwd)/,,$(@))\n" $(Q)$(CC) $(INITCFLAGS) $(COREBOOTINCLUDE) -c -o $@ $< +# Create a tmp file so that if the dtc fails we don't end up with a +# half-correct statictree.[ch] $(obj)/mainboard/$(MAINBOARDDIR)/statictree.c: $(src)/mainboard/$(MAINBOARDDIR)/dts $(obj)/util/dtc/dtc $(Q)printf " DTC $(subst $(shell pwd)/,,$(@))\n" - $(Q)$(obj)/util/dtc/dtc -O lb mainboard/$(MAINBOARDDIR)/dts > $@ + $(Q)$(obj)/util/dtc/dtc -O lb mainboard/$(MAINBOARDDIR)/dts > /tmp/statictree.c.$$ + $(Q)mv /tmp/statictree.c.$$ $@ $(obj)/statictree.h: $(src)/mainboard/$(MAINBOARDDIR)/dts $(obj)/util/dtc/dtc $(Q)printf " DTC $(subst $(shell pwd)/,,$(@))\n" - $(Q)$(obj)/util/dtc/dtc -O lbh mainboard/$(MAINBOARDDIR)/dts > $@ + $(Q)$(obj)/util/dtc/dtc -O lbh mainboard/$(MAINBOARDDIR)/dts > /tmp/statictree.h.$$ + $(Q)mv /tmp/statictree.h.$$ $@ $(obj)/mainboard/$(MAINBOARDDIR)/option_table.c: $(obj)/util/options/build_opt_tbl $(src)/mainboard/$(MAINBOARDDIR)/cmos.layout $(Q)printf " OPTIONS $(subst $(shell pwd)/,,$(@))\n" @@ -84,4 +88,3 @@ $(Q)mkdir -p $(dir $@) $(Q)printf " CC $(subst $(shell pwd)/,,$(@))\n" $(Q)$(CC) $(INITCFLAGS) -c $< -o $@ - -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r900 - coreboot-v3/arch/x86
On Mon, Oct 6, 2008 at 4:17 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> Hi Ron,
>
> congratulations for commit #900. We've come a far way since the first v3
> commit.
>
> One minor nipick, though. Unless I'm reading the patch wrong, we now
> discard .note.* twice.
>
> Regards,
> Carl-Daniel
>
> On 07.10.2008 01:13, [EMAIL PROTECTED] wrote:
>> Author: rminnich
>> Date: 2008-10-07 01:13:38 +0200 (Tue, 07 Oct 2008)
>> New Revision: 900
>> Modified: coreboot-v3/arch/x86/ldscript.ld
>> ===
>> --- coreboot-v3/arch/x86/ldscript.ld 2008-10-06 23:06:32 UTC (rev 899)
>> +++ coreboot-v3/arch/x86/ldscript.ld 2008-10-06 23:13:38 UTC (rev 900)
>> @@ -43,6 +43,7 @@
>> }
>> /DISCARD/ : {
>> *(.comment)
>> + *(.note.*)
>> *(.note)
>> *(.note.*)
>> }
>>
>>
oh boy. this is weird. I did an svn up and then checked this and did
the commit. owie.
I'll look at why this might have happened.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r900 - coreboot-v3/arch/x86
fixed r901 ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] patch: allow kscope support for mainboard source code browsing.
attached.
ron
These changes allow users to use kscope to browse v3 source.
Want to find a function definition? Click and hit CTL-1
Want to see what it calls? CTL-2
Want to see who calls it? CTl-3
And so on.
For information on kscope please see: http://kscope.sourceforge.net/
It's a great way to browse a project. The key idea here is that the
kscope configuration is *specific to your mainboard* -- you only see the
source and includes used in your mainboard!
Improvements to the mkdep script are MOST welcome. I am no
expert.
Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
Index: util/mkdep
===
--- util/mkdep (revision 0)
+++ util/mkdep (revision 0)
@@ -0,0 +1,16 @@
+#!/bin/bash
+out=$1
+shift
+o=""
+while [ "$1" != "--" ]; do
+o="$o $1"
+shift
+done
+shift
+p=`pwd`
+while [ "$1" ] ; do
+echo $1 >>${out}
+cpp -M -m32 $o $1 | sed 's/.*://' | sed 's/^ *//g' | tr ' ' '\n' | tr '\\' ' ' |sed "s,^include,${p}/include," >>${out}
+shift
+done
+sort -o ${out} -u ${out}
Index: arch/x86/Makefile
===
--- arch/x86/Makefile (revision 900)
+++ arch/x86/Makefile (working copy)
@@ -23,7 +23,7 @@
ifeq ($(CONFIG_ARCH_X86),y)
INITCFLAGS := $(CFLAGS) -I$(src)/include/arch/x86 -I$(src)/include \
- -I$(obj) -I$(src)/mainboard/$(MAINBOARDDIR)/-fno-builtin
+ -I$(obj) -I$(src)/mainboard/$(MAINBOARDDIR)/ -fno-builtin
SILENT := >/dev/null 2>&1
@@ -275,3 +275,17 @@
$(Q)$(NM) $(obj)/coreboot.initram | sort -u > $(obj)/coreboot.initram.map
endif
+
+#
+# For Kscope
+#
+
+kscope: $(obj)/mainboard/$(MAINBOARDDIR)/kscope/cscope.files
+ kscope $(obj)/mainboard/$(MAINBOARDDIR)/kscope
+ALLSRC=$(STAGE0_SRC) $(INITRAM_SRC) $(STAGE2_SRC)
+$(obj)/mainboard/$(MAINBOARDDIR)/kscope/cscope.files: $(ALLSRC)
+ $(Q)mkdir -p $(obj)/mainboard/$(MAINBOARDDIR)/kscope
+ $(Q)cp cscope.proj $(obj)/mainboard/$(MAINBOARDDIR)/kscope
+ $(Q)sh util/mkdep $@ $(INITCFLAGS) "--" $(ALLSRC)
+# $(Q)sort -u -o $@ $@
+
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] coreboot: Don't loop forever waiting for HDA codecs
Acked for v2: Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> This applied cleanly to v3 and built just fine. Committed revision 904. (v3) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
On Mon, Oct 6, 2008 at 2:14 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> All right. I'd love to help fix it. Here's the relevant snippet from
> serengeti/dts
>
> /* guesses; we need a real lspci */
> [EMAIL PROTECTED],0 {
> /config/("northbridge/amd/k8/pci");
> [EMAIL PROTECTED],0 {
> /config/("southbridge/amd/amd8111/amd8111.dts");
> };
> [EMAIL PROTECTED],0 {
> /config/("southbridge/amd/amd8111/ide.dts");
> };
> [EMAIL PROTECTED],0 {
> /config/("southbridge/amd/amd8111/nic.dts");
> };
> };
>
> from amd8111.dts:
>
> {
> device_operations = "amd8111";
> };
>
> from amd8111/ide.dts:
>
> {
> device_operations = "amd8111_ide";
> ide0_enable = "0";
> ide1_enable = "1";
> };
>
> from amd8111/nic.dts:
>
> {
> device_operations = "amd8111_nic";
> phy_lowreset = "0";
> };
>
> I see that the device_operations structures get used, but I don't see how
> there are parameters being passed here. I'm sorry to be so clueless, I
> don't understand the meaning of the dts yet.
>
There are no parameters to pass on some things, so that is one issue.
You need these dts nodes in there to make the connection to the data
structure for the device_operations. This is a change in v3: no linker
sets, so arrays of structs that were created by the linker in v2 are
now created by the device tree compiler in v3 (which means you can
browse these structs with, e.g., kscope; the arrays of structs were
invisible in v2 as they were created by the linker).
Here is a proposed change to dts. I've forgotten all I ever knew about
the 8111 so I am pretty sure this is incomplete, but it's something
like what we want.
Index: mainboard/amd/serengeti/dts
===
--- mainboard/amd/serengeti/dts (revision 904)
+++ mainboard/amd/serengeti/dts (working copy)
@@ -28,18 +28,17 @@
/config/("northbridge/amd/k8/domain");
[EMAIL PROTECTED],0{
};
- /* guesses; we need a real lspci */
[EMAIL PROTECTED],0 {
/config/("northbridge/amd/k8/pci");
- [EMAIL PROTECTED],0 {
+ [EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/amd8111.dts");
+ [EMAIL PROTECTED],0 {
+
/config/("southbridge/amd/amd8111/nic.dts");
+ };
};
[EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/ide.dts");
};
- [EMAIL PROTECTED],0 {
- /config/("southbridge/amd/amd8111/nic.dts");
- };
};
[EMAIL PROTECTED],0 {
/config/("northbridge/amd/k8/pci");
It still doesn't seem quite right. Segher?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: allow kscope support for mainboard source code browsing.
On Mon, Oct 6, 2008 at 5:36 PM, Uwe Hermann <[EMAIL PROTECTED]> wrote: > Actually, maybe it's better to merge mkdep in the Makefile itself? > That would save us yet another tiny file cluttering up the space... > Opinions? > it's fine by me. That is a really generic script that would even work on Plan 9 ... the acid test. Whatever this group thinks best. Thanks again. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Menlow platform again - is anybody working on this?
On Tue, Oct 7, 2008 at 3:40 AM, Piotr Kempa <[EMAIL PROTECTED]> wrote: > 1. I hear rumors that Intel is generally against coreboot (maybe > somebody could prove me wrong here?) because they're betting on their > own (U)EFI system, which is more or less 'closed'. Which is why I doubt > any Intel guys would really help us. But if you (Intel guys) are out > there and reading this and willing to help, please prove me wrong! intel is a business. According to other companies that have built coreboot in the past, if you make the business case to intel, you can get support. > > 2. Because of 1 above, even if we get necessary documentation on chipset > and CPU, I fear Intel can legally forbid us from using this > documentation to contribute to coreboot (with NDA or something), so we > would not be able to use their documents to write open source code. This > is a legal problem and I'm far from being a lawyer so this might be much > more complicated (or simple) than I'm imagining. > I think you should try. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD RS690 / SB600 candidate boards with socketed ROM
On Tue, Sep 30, 2008 at 9:44 AM, bari <[EMAIL PROTECTED]> wrote: > Socketed Flash and mini-itx: > > AB6S-RS690IKM > http://www.eqscomputers.com/products/mobo/details.php?model=AB6S-RS690IKM optional lan? Are they serious? > > A270 > http://www.winmate.com.tw/PPc/PPcSpec.asp?Prod=05_0007&Typeid=050302 http://www.winmate.com.tw/PPc/PPcSpec.asp?Prod=05_0007&Typeid=050302 I thought this one was pretty nice. Is there a realtek 8111 driver yet? Where to buy? Fly to taiwan it seems. > > KI690-AM2 > http://www.albatron.com.tw/English/product/mb/pro_detail.asp?rlink=Specification&no=239 marvell lanl? no no no no ... > > KI51PV-754 > http://www.albatron.com.tw/English/product/mb/pro_detail.asp?rlink=Specification&no=215 marvell lanl? no no no no ... > > KINO-690S1 > http://www.ieiworld.com/product_groups/industrial/content.aspx?gid=1102&cid=08133752007657537117&id=08142308567763377074 > > KINO-690AM2 > http://www.ieiworld.com/product_groups/industrial/content.aspx?gid=1102&cid=08133752007657537117&id=08142308800717537197 no joy from the website. well, so far no good :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD RS690 / SB600 candidate boards with socketed ROM
On Tue, Oct 7, 2008 at 11:08 AM, bari <[EMAIL PROTECTED]> wrote: > Happy to track these down if you do the porting :) > if you can find the good one the port is in progress ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
On Tue, Oct 7, 2008 at 9:44 AM, Myles Watson <[EMAIL PROTECTED]> wrote:
>
>
>> Here is a proposed change to dts. I've forgotten all I ever knew about
>> the 8111 so I am pretty sure this is incomplete, but it's something
>> like what we want.
>>
>>
>> Index: mainboard/amd/serengeti/dts
>> ===
>> --- mainboard/amd/serengeti/dts (revision 904)
>> +++ mainboard/amd/serengeti/dts (working copy)
>> @@ -28,18 +28,17 @@
>> /config/("northbridge/amd/k8/domain");
>> [EMAIL PROTECTED],0{
>> };
>> - /* guesses; we need a real lspci */
>> [EMAIL PROTECTED],0 {
>> /config/("northbridge/amd/k8/pci");
>> - [EMAIL PROTECTED],0 {
>> + [EMAIL PROTECTED],0 {
>>
> /config/("southbridge/amd/amd8111/amd8111.dts");
>> + [EMAIL PROTECTED],0 {
>> +
> /config/("southbridge/amd/amd8111/nic.dts");
>> + };
>> };
>> [EMAIL PROTECTED],0 {
>> /config/("southbridge/amd/amd8111/ide.dts");
>> };
>> - [EMAIL PROTECTED],0 {
>> - /config/("southbridge/amd/amd8111/nic.dts");
>> - };
>> };
>> [EMAIL PROTECTED],0 {
>> /config/("northbridge/amd/k8/pci");
>>
>> It still doesn't seem quite right. Segher?
>
> I've played with it a little more, no luck yet. Could you help me
> understand the naming convention?
>
> [EMAIL PROTECTED],0 = pci at device 5 function 0 ?
yes
>
> I don't see how we say there's a pci bridge at device 0 function 0 on this
> bus, then specify the devices on the pci bus from there.
the bridge is actually implied by the fact that the node has child
nodes (as in v2). But yes, I see your point.
I don't have time to look today but there is some simple thing wrong.
The devices are straight from v2.
>
> Should we be using the amd8111/pci.dts here too? Maybe that's why you had
> the phase3_scan = 0, since the pci bus should take care of its scan?
>
Hmm, not sure, ref. v2 again.
I think we should take a careful look at v2 again but I think this is
a simple problem that just needs
close looking at ...
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Proposed rom renaming change
On Tue, Oct 7, 2008 at 12:55 PM, Jordan Crouse <[EMAIL PROTECTED]> wrote: > Our current ROM naming scheme in buildrom is -.rom. > This is all nice and good, but for archiving (or rom-o-matic) purposes, > we need to be more descriptive. Therefore, I propose that we move to > the more unwieldly, but also more descriptive: > > --cbv[23]-.rom > excellent idea! ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] dbm690t and v3
this board now builds and creates a rom. If anybody wants a flyby with simnow I welcome but reports. Of course, I welcome non-bug reports more but hey ... I *know* the s1g1 support is not really in there. Serial out from stage0 would be really nice to start. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix.2c3 stops at mainboard_pre_payload: done
can you build filo to ONLY use serial port and let us know how that goes? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
On Wed, Oct 8, 2008 at 7:43 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > I'm trying to undertand dts better, and found this. This patch removes > extra devices from the v2 Config.lb file for serengeti cheetah. > > The only change without these devices is that now these lines are missing > from the log: > > Disabling static device: PCI: 00:19.0 > Disabling static device: PCI: 00:19.1 > Disabling static device: PCI: 00:19.2 > Disabling static device: PCI: 00:19.3 > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > no patch? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
