Re: [coreboot] build failure: cannot move location counter backwards

[Darren Hart]

On 06/20/2011 04:09 PM, Cristian Măgherușan-Stanciu wrote:
> Hi,
> 
> I documented the latest developments (git and crossgcc) at
> http://www.coreboot.org/Build_HOWTO. Please someone double-check.

My build succeeded following these instructions. As a first-time user,
it would be helpful to have a quick-start guide which would be basically
this wiki page + the steps necessary to do boot what I built in qemu.
There are bits of that here:

http://www.coreboot.org/QEMU

So perhaps a link, although it is a bit unclear to me which bits of what
I built get used when I try to boot searbios in qemu. I don't seem to
need corebios.rom at all, just the seabios bios.bin:

$ qemu -bios ./payloads/external/SeaBIOS/seabios/out/bios.bin -hda
/dev/zero -serial stdio

I get an option to press F12 in the console and select a boot device.
Seems to work.

Am I using coreboot? Is it integrated into the payload? Reading the
QEMU_Build_tutorial, http://www.coreboot.org/QEMU_Build_Tutorial, led me
to try:

$ qemu -bios build/coreboot.rom -hda /dev/zero -serial stdio

This resulted in something else entirely, the shell output terminating
in the following:

coreboot memory table:
 0. -0fff: CONFIGURATION TABLES
 1. 1000-0009: RAM
 2. 000c-17fe: RAM
 3. 17ff-17ff: CONFIGURATION TABLES
 4. ff80-: RESERVED
Wrote coreboot table at: 17ff1400 - 17ff15c4  checksum 6c1c
coreboot table: 452 bytes.
Multiboot Information structure has been written.
 0. FREE SPACE 17ff3400 cc00
 1. GDT17ff0200 0200
 2. IRQ TABLE  17ff0400 1000
 3. COREBOOT   17ff1400 2000
Check CBFS header at fffcfc39
magic is 386f92fa
ERROR: No valid CBFS header found!
CBFS:  Could not find file fallback/payload
Boot failed.

It isn't clear to me from the various pages I've read which of the above
(if either) is the appropriate way to boot coreboot on qemu. Can anyone
clear that up for me?


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] hi every one...

[krishnateja kesineni]

i krishna teja kesineni. working in a research institute in india.. i and my
batch intended to develop a  a BIOS over a coreboot for our own design
boards.. we not interested to go for proprietary BIOS. plz say anyone is
there in india to teach and support us.. plzz get me know.. thank Q

-- 
*--*
*Regards,
Krishna Teja Kesineni,
Mtech in Information Security,
National Inistuite of Technology,
Rourkela,
India
Phone: +91-9692598754
E-mail: tejakesin...@gmail.com; 210cs2...@nitrkl.ac.in
Blog: http://teja4u.110mb.com/*
*


Please don’t print this e-mail unless it is necessary.
Save
 Trees.
*
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Wiki update/wiki access request: E350M1 sound supportverified

[Scott Duplichan]

Marshall Buschman wrote:

]Hello:
]
]The built-in sound on the ASRock E350M1 works properly.
]Could someone please update the wiki page accordingly?
]
]Also, a wiki account would be nice if possible.

Hello Marshall,

I did the wiki update.

http://www.coreboot.org/index.php?title=ASRock_E350M1&action=historysubmit&d
iff=10828&oldid=10826

Thanks,
Scott


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Wiki update/wiki access request: E350M1 sound support verified

[Marshall Buschman]

Hello:

The built-in sound on the ASRock E350M1 works properly.
Could someone please update the wiki page accordingly?

Also, a wiki account would be nice if possible.

Thank you!
-Marshall Buschman

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Patch set updated: a405a45 Move SB800 clock init earlier

[mbusch...@lucidmachines.com]

Marshall Buschman (mbusch...@lucidmachines.com) just uploaded a new patch set 
to gerrit, which you can find at
http://review.coreboot.org/32

-gerrit

commit a405a454515236058ca9c6b93c6051af0fafc070
Author: Marshall Buschman 
Date:   Mon Jun 20 21:23:36 2011 -0500

Move SB800 clock init earlier

Committing Scott's e350m1 changes (svn r6585):
Move SB800 clock init earlier,
Fixes problem where initial serial port output is garbled.

Change-Id: If05aa37726b962e8994ee69bf1882fcfae56aa19
Signed-off-by: Scott Duplichan 
Signed-off-by: Marshall Buschman 
---
 src/mainboard/asrock/e350m1/romstage.c |   26 +++---
 1 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/src/mainboard/asrock/e350m1/romstage.c 
b/src/mainboard/asrock/e350m1/romstage.c
index 61de9f6..e822899 100644
--- a/src/mainboard/asrock/e350m1/romstage.c
+++ b/src/mainboard/asrock/e350m1/romstage.c
@@ -55,6 +55,21 @@ void cache_as_ram_main(unsigned long bist, unsigned long 
cpu_init_detectedx)
// all cores: set pstate 0 (1600 MHz) early to save a few ms of boot 
time
__writemsr(0xc0010062, 0);
 
+   if (boot_cpu()) {   
+   u8 reg8;
+   // SB800: program AcpiMmioEn to enable MMIO access to MiscCntrl 
register
+   outb(0x24, 0xCD6);
+   reg8 = inb(0xCD7);
+   reg8 |= 1;
+   reg8 &= ~(1 << 1);
+   outb(0x24, 0xCD6);
+   outb(reg8, 0xCD7);
+
+   // program SB800 MiscCntrl
+   *(volatile u32 *)(0xFED8 + 0xE00 + 0x40) &= ~((1 << 0) | (1 
<< 2)); /* 48Mhz */
+   *(volatile u32 *)(0xFED8 + 0xE00 + 0x40) |= 1 << 1; /* 
48Mhz */
+   }
+
if (!cpu_init_detectedx && boot_cpu()) {
post_code(0x30);
sb_poweron_init();
@@ -63,17 +78,6 @@ void cache_as_ram_main(unsigned long bist, unsigned long 
cpu_init_detectedx)
w83627hf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
console_init();
}
-   //reg8 = pmio_read(0x24);
-   outb(0x24, 0xCD6);
-   reg8 = inb(0xCD7);
-   reg8 |= 1;
-   reg8 &= ~(1 << 1);
-   //pmio_write(0x24, reg8);
-   outb(0x24, 0xCD6);
-   outb(reg8, 0xCD7);
-
-   *(volatile u32 *)(0xFED8 + 0xE00 + 0x40) &= ~((1 << 0) | (1 << 2)); 
/* 48Mhz */
-   *(volatile u32 *)(0xFED8 + 0xE00 + 0x40) |= 1 << 1; /* 48Mhz */
 
/* Halt if there was a built in self test failure */
post_code(0x34);

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Patch set updated: b38b651 Add the coreboot config to CBFS

[cristi.magheru...@gmail.com]

Cristian Măgherușan-Stanciu (cristi.magheru...@gmail.com) just uploaded a new 
patch set to gerrit, which you can find at
http://review.coreboot.org/46

-gerrit

commit b38b651d1254ff9dd2e49c51120c40b5a787ce3d
Author: Cristian Măgherușan-Stanciu 
Date:   Sun Jun 19 03:03:28 2011 +0200

Add the coreboot config to CBFS

The CBFS will contain a new file, named 'config' of type 'raw' that
is a stripped-down stripped-down version of the .config file that
was used to build coreboot. For space savings, all the comments and
empty lines were removed from the original config.

This is done in order to easily reproduce the process of creating an
image made by someone else when only having the original binary
image.

Known issues/TODOs:
-when using abuild, the generated images will contain the config from
the coreboot tree, if anf only if this exists, and not the config file
generated for the current board by abuild.
-the coreboot git revision is not listed in the config file as of yet.

Change-Id: I784989aac0227d3679d30314b06dadaec402749e
Signed-off-by: Cristian Măgherușan-Stanciu 
---
 src/Kconfig   |6 ++
 src/arch/x86/Makefile.inc |6 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 9abbc21..7e6214a 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -106,6 +106,12 @@ config COMPRESS_RAMSTAGE
  that decompression might slow down booting if the boot flash
  is connected through a slow Link (i.e. SPI)
 
+config INCLUDE_CONFIG_FILE
+  bool "Include the coreboot config file into the ROM image"
+   default y
+  help
+Include in CBFS the coreboot config file that was used to compile the ROM 
image
+
 endmenu
 
 source src/mainboard/Kconfig
diff --git a/src/arch/x86/Makefile.inc b/src/arch/x86/Makefile.inc
index 8c1a887..986a72a 100644
--- a/src/arch/x86/Makefile.inc
+++ b/src/arch/x86/Makefile.inc
@@ -99,6 +99,12 @@ ifeq ($(CONFIG_GEODE_VSA_FILE),y)
$(LD) -m elf_i386 -e 0x60020 --section-start .data=0x6 $(obj)/vsa.o 
-o $(obj)/vsa.elf
$(CBFSTOOL) $@.tmp add-stage $(obj)/vsa.elf vsa
 endif
+ifeq ($(CONFIG_INCLUDE_CONFIG_FILE),y)
+   @printf "CONFIG   $(CONFIG_INCLUDE_CONFIG_FILE)\n"
+   if [ -f $(top)/.config ]; then \
+   sed -e '/^#/d' -e '/^ *$$/d' $(top)/.config > $(obj)/config.tmp ; \
+   $(CBFSTOOL) $@.tmp add $(obj)/config.tmp config raw; rm -f 
$(obj)/config.tmp ; fi
+endif
mv $@.tmp $@
@printf "CBFSPRINT  $(subst $(obj)/,,$(@))\n\n"
$(CBFSTOOL) $@ print

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] asrock e350m1: configure sb800 gpp ports to support onboard pcie nic

[Marc Jones]

On Mon, Jun 20, 2011 at 3:43 PM, Scott Duplichan  wrote:
> Marc Jones wrote:
>
> ]Hi Scott,
> ]
> ]On Fri, Jun 17, 2011 at 10:26 PM, Scott Duplichan  wrote:
> ]> The attached patch allows the asrock e350m1 onboard nic to work.
> ]> 1) Update the asrock e350m1 devicetree.cb to match the hardware.
> ]> 2) Change the way the sb800 cimx wrapper code works. The original
> ]> cimx code calls sb800 cimx function sbBeforePciInit() once. When
> ]> ported to coreboot, the gpp component of this function was called
> ]> once for each gpp port, as the gpp port's enable/disable state
> ]> became known. A 05/15/2011 change makes the early gpp code run
> ]> only once, triggered by processing the 4th gpp port. This method
> ]> is not general enough because the 4th gpp port is not enabled on
> ]> all boards. With the current change, the early gpp code runs when
> ]> the first gpp port is processed. If any gpp ports are enabled, the
> ]> first must be enabled. Tested with Win7 and linux on asrock e350m1.
> ]> This change will also affect amd inagua, and has not been tested
> ]> on that board.
> ]>
> ]> Signed-off-by: Scott Duplichan 
> ]
> ]-              sb_config->PORTCONFIG[0].PortCfg.PortPresent = dev->enabled;
> ]-              return;
> ]-      case (0x15 << 3) | 1: /* 0:15:1 PCIe PortB */
> ]-              sb_config->PORTCONFIG[1].PortCfg.PortPresent = dev->enabled;
> ]-              return;
> ]-      case (0x15 << 3) | 2: /* 0:15:2 PCIe PortC */
> ]-              sb_config->PORTCONFIG[2].PortCfg.PortPresent = dev->enabled;
> ]-              return;
> ]-      case (0x15 << 3) | 3: /* 0:15:3 PCIe PortD */
> ]-              sb_config->PORTCONFIG[3].PortCfg.PortPresent = dev->enabled;
> ]+              {
> ]+              device_t device;
> ]+              for (device = dev; device; device = device->next) {
> ]+                      if (dev->path.type != DEVICE_PATH_PCI) continue;
> ]+                      if ((device->path.pci.devfn & ~7) !=
> PCI_DEVFN(0x15,0)) ]break;
> ]+                      sb_config->PORTCONFIG[device->path.pci.devfn &
> ]3].PortCfg.PortPresent = device->enabled;
> ]+              }
> ]
> ]The allocator is going to loop through and call this function for each
> ]device in the devicetree.cb. Is there a reason to change this to a
> ]loop here? It looks like the real fix is moving the SB_BEFORE_PCI_INIT
> ]call to the last device, and to not run for each device. Did I miss
> ]something more subtle in this patch?
> ]
> ]Marc
>
> Hello Marc,
>
> I wanted to call the standard cimx entry point only once, the way it is done
> in the reference BIOS. This is difficult to do with coreboot, because all
> the portPresent values need to be known before making the call. All of the
> dev->enable values are not available in parallel from coreboot. The previous
> code captured the dev->enable values for functions 0, 1, and 2 in the local
> sb_config struct, then returned. When function 3 was processed all 4 values
> were ready. I think that is similar to what you suggest. The difference is
> that the prevoius code called only the sbPcieGppEarlyInit part of
> SB_BEFORE_PCI_INIT.
>
> I think your suggestion works for boards that use the sb800 option for 4 x1
> ports, as asrock e350m1 does. But what about a board that uses one of the
> other sb800 pcie options such as single x4 port? My concern was that
> functions 1, 2, and 3 might not even be visible. Even if they are visible,
> the person writing devicetree might not choose to include them since they
> are not present in a booted system. Because function 0 is visible in all
> cases, I thought that is the best place to trigger the cimx call. Because
> function 0 is processed first, getting the dev->enable values is not so
> easy. The new code scans the devicetree.cb nodes following device 0x15
> function 0. Scanning stops on the first pci node not for device 0x15, so
> the loop will run a maximum of 3 times. That lets the code gather the needed
> dev->enable values.

Hi Scott,

I see what you were thinking about the visible ports. I was thinking
that the devicetree.db would have the IDs, they would just be turned
off. I agree that this way works too and may be more clear for a
developer.

i added Kerry to see if he has an opinion.

Marc




-- 
http://se-eng.com

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] build failure: cannot move location counter backwards

[Cristian Măgherușan-Stanciu]

Hi,

You need to use our cross-compiler. Run 'make crossgcc' in the
coreboot directory and you will get our reference toolchain compiled.
Then run 'make' once again and everything should compile.

I will try to fix the doc if this is missing from there.

Cristi

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] build failure: cannot move location counter backwards

[Cristian Măgherușan-Stanciu]

Hi,

I documented the latest developments (git and crossgcc) at
http://www.coreboot.org/Build_HOWTO. Please someone double-check.

Cristi

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] build failure: cannot move location counter backwards

[Stefan Reinauer]

Hi Darren,

* Darren Hart  [110621 00:19]:
> I'm new to coreboot and just trying to get it to boot into qemu. I've
> tried using SeaBios as well as just copying "yes" to payload.elf. I
> updated the Makefile to use gcc 4.5 instead of the 4.4 that ships with
> my distribution (Ubuntu 10.10):
 
> Index: Makefile
> ===
> --- Makefile  (revision 6637)
> +++ Makefile  (working copy)
> @@ -64,7 +64,7 @@
>  endif
>  endif
> 
> -HOSTCC = gcc
> +HOSTCC = gcc-4.5
>  HOSTCXX = g++
>  HOSTCFLAGS := -I$(srck) -I$(objk) -g
>  HOSTCXXFLAGS := -I$(srck) -I$(objk)

This will only change the compiler used to compile your userland
utilities. You need to change the script util/xcompile/xcompile to get
the target compiler changed. (And possibly delete the file .xcompile in
your coreboot directory before trying again)

> CC coreboot_ram
> src/arch/x86/coreboot_ram.ld:129 cannot move location counter backwards
> (from 00118000 to 4000)
> collect2: ld returned 1 exit status
> make: *** [build/coreboot_ram] Error 1

This is a common tool chain bug we hit mostly on Ubuntu based systems so
far. (Maybe someone could open a bug report so they know about this
breakage?)

So far, the easiest way to get a known good toolchain is to build the
coreboot reference toolchain. It should build out of the box on any
Linux, MacOSX (with Xcode and MacPorts installed) and Windows (with
MINGW or Cygwin installed) system. To build it, go to util/crossgcc in
your coreboot tree and run the buildgcc script:

$ ./buildgcc

Then sit back and wait for a few minutes for the build to finish.

The resulting toolchain will per default end up in util/crossgcc/xgcc
and will be automatically picked up by the coreboot build system. Again,
you should delete your coreboot/.xcompile file after making changes to
the toolchain.

Hope that helps,

Stefan



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] build failure: cannot move location counter backwards

[Paul Menzel]

Am Montag, den 20.06.2011, 15:19 -0700 schrieb Darren Hart:
> I'm new to coreboot

Welcome!

> and just trying to get it to boot into qemu. I've
> tried using SeaBios as well as just copying "yes" to payload.elf. I
> updated the Makefile to use gcc 4.5 instead of the 4.4 that ships with
> my distribution (Ubuntu 10.10):

[…]

> src/arch/x86/coreboot_ram.ld:129 cannot move location counter backwards
> (from 00118000 to 4000)
> collect2: ld returned 1 exit status
> make: *** [build/coreboot_ram] Error 1

You should try the tested tool chain crossgcc [1].

make crossgcc

which should be doing something similar as the following [2].

cd coreboot/util/crossgcc 
./buildgcc 
cd ../.. 
rm -f .xcompile


Thanks,

Paul


[1] http://patchwork.coreboot.org/patch/2964/
[2] 
http://www.taringa.net/comunidades/linuxeros-debian/2899363/[Tutorial]+Compilar+coreboot.html


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] build failure: cannot move location counter backwards

[Darren Hart]

I'm new to coreboot and just trying to get it to boot into qemu. I've
tried using SeaBios as well as just copying "yes" to payload.elf. I
updated the Makefile to use gcc 4.5 instead of the 4.4 that ships with
my distribution (Ubuntu 10.10):

dvhart@doubt:~/source/coreboot.svn
$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dvhart@doubt:~/source/coreboot.svn
$ gcc-4.5 --version
gcc-4.5 (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Index: Makefile
===
--- Makefile(revision 6637)
+++ Makefile(working copy)
@@ -64,7 +64,7 @@
 endif
 endif

-HOSTCC = gcc
+HOSTCC = gcc-4.5
 HOSTCXX = g++
 HOSTCFLAGS := -I$(srck) -I$(objk) -g
 HOSTCXXFLAGS := -I$(srck) -I$(objk)

I followed the instructions here:
http://www.coreboot.org/Build_HOWTO
to configure for qemux86 with a 256K ROM.

The build output and resulting failure follow. Am I doing something dumb
or have I hit a legitimate bug?

$ make
GENbootblock/ldscript.ld
LINK   bootblock.elf
OBJCOPYcoreboot.bootblock
CC lib/memset.romstage.o
CC lib/memcpy.romstage.o
CC lib/memcmp.romstage.o
CC lib/cbfs.romstage.o
CC lib/lzma.romstage.o
CC lib/uart8250.romstage.o
CC console/vtxprintf.romstage.o
CC console/post.romstage.o
CC console/die.romstage.o
GENbuild.h
ROMCC  romstage.inc
GENromstage/crt0.S
CC mainboard/emulation/qemu-x86/crt0.s
CC mainboard/emulation/qemu-x86/crt0.romstage.o
CC arch/x86/lib/romstage_console.romstage.o
CC arch/x86/lib/cbfs_and_run.romstage.o
CC southbridge/intel/i82371eb/early_pm.romstage.o
CC southbridge/intel/i82371eb/early_smbus.romstage.o
GENromstage/ldscript.ld
LINK   coreboot.romstage
CBFS   coreboot.pre
CC arch/x86/lib/c_start.ramstage.o
CC console/uart8250_console.driver.o
CC southbridge/intel/i82371eb/i82371eb.driver.o
CC southbridge/intel/i82371eb/isa.driver.o
CC southbridge/intel/i82371eb/ide.driver.o
CC southbridge/intel/i82371eb/usb.driver.o
CC southbridge/intel/i82371eb/smbus.driver.o
CC southbridge/intel/i82371eb/reset.driver.o
CC mainboard/emulation/qemu-x86/static.ramstage.o
CC lib/memset.ramstage.o
CC lib/memcpy.ramstage.o
CC lib/memcmp.ramstage.o
CC lib/memmove.ramstage.o
CC lib/malloc.ramstage.o
CC lib/delay.ramstage.o
CC lib/fallback_boot.ramstage.o
CC lib/compute_ip_checksum.ramstage.o
CC lib/version.ramstage.o
CC lib/cbfs.ramstage.o
CC lib/lzma.ramstage.o
CC lib/gcc.ramstage.o
CC lib/clog2.ramstage.o
CC lib/cbmem.ramstage.o
CC lib/uart8250.ramstage.o
CC boot/hardwaremain.ramstage.o
CC boot/selfboot.ramstage.o
CC console/printk.ramstage.o
CC console/console.ramstage.o
CC console/vtxprintf.ramstage.o
CC console/vsprintf.ramstage.o
CC console/post.ramstage.o
CC console/die.ramstage.o
CC devices/device.ramstage.o
CC devices/root_device.ramstage.o
CC devices/device_util.ramstage.o
CC devices/pci_device.ramstage.o
CC devices/pcix_device.ramstage.o
CC devices/pciexp_device.ramstage.o
CC devices/agp_device.ramstage.o
CC devices/cardbus_device.ramstage.o
CC devices/pnp_device.ramstage.o
CC devices/pci_ops.ramstage.o
CC devices/smbus_ops.ramstage.o
CC devices/pci_rom.ramstage.o
CC mainboard/emulation/qemu-x86/mainboard.ramstage.o
CC mainboard/emulation/qemu-x86/irq_tables.ramstage.o
CC mainboard/emulation/qemu-x86/northbridge.ramstage.o
CC pc80/mc146818rtc.ramstage.o
CC pc80/isa-dma.ramstage.o
CC pc80/i8259.ramstage.o
CC pc80/udelay_io.ramstage.o
CC pc80/keyboard.ramstage.o
CC devices/oprom/x86.ramstage.o
CC devices/oprom/x86_asm.ramstage.o
CC devices/oprom/x86_interrupts.ramstage.o
CC arch/x86/boot/boot.ramstage.o
CC arch/x86/boot/coreboot_table.ramstage.o
CC arch/x86/boot/multiboot.ramstage.o
CC arch/x86/boot/gdt.r

Re: [coreboot] [PATCH] asrock e350m1: configure sb800 gpp ports to support onboard pcie nic

[Scott Duplichan]

Marc Jones wrote:

]Hi Scott,
]
]On Fri, Jun 17, 2011 at 10:26 PM, Scott Duplichan  wrote:
]> The attached patch allows the asrock e350m1 onboard nic to work.
]> 1) Update the asrock e350m1 devicetree.cb to match the hardware.
]> 2) Change the way the sb800 cimx wrapper code works. The original
]> cimx code calls sb800 cimx function sbBeforePciInit() once. When
]> ported to coreboot, the gpp component of this function was called
]> once for each gpp port, as the gpp port's enable/disable state
]> became known. A 05/15/2011 change makes the early gpp code run
]> only once, triggered by processing the 4th gpp port. This method
]> is not general enough because the 4th gpp port is not enabled on
]> all boards. With the current change, the early gpp code runs when
]> the first gpp port is processed. If any gpp ports are enabled, the
]> first must be enabled. Tested with Win7 and linux on asrock e350m1.
]> This change will also affect amd inagua, and has not been tested
]> on that board.
]>
]> Signed-off-by: Scott Duplichan 
]
]-  sb_config->PORTCONFIG[0].PortCfg.PortPresent = dev->enabled;
]-  return;
]-  case (0x15 << 3) | 1: /* 0:15:1 PCIe PortB */
]-  sb_config->PORTCONFIG[1].PortCfg.PortPresent = dev->enabled;
]-  return;
]-  case (0x15 << 3) | 2: /* 0:15:2 PCIe PortC */
]-  sb_config->PORTCONFIG[2].PortCfg.PortPresent = dev->enabled;
]-  return;
]-  case (0x15 << 3) | 3: /* 0:15:3 PCIe PortD */
]-  sb_config->PORTCONFIG[3].PortCfg.PortPresent = dev->enabled;
]+  {
]+  device_t device;
]+  for (device = dev; device; device = device->next) {
]+  if (dev->path.type != DEVICE_PATH_PCI) continue;
]+  if ((device->path.pci.devfn & ~7) !=
PCI_DEVFN(0x15,0)) ]break;
]+  sb_config->PORTCONFIG[device->path.pci.devfn &
]3].PortCfg.PortPresent = device->enabled;
]+  }
]
]The allocator is going to loop through and call this function for each
]device in the devicetree.cb. Is there a reason to change this to a
]loop here? It looks like the real fix is moving the SB_BEFORE_PCI_INIT
]call to the last device, and to not run for each device. Did I miss
]something more subtle in this patch?
]
]Marc

Hello Marc,

I wanted to call the standard cimx entry point only once, the way it is done
in the reference BIOS. This is difficult to do with coreboot, because all
the portPresent values need to be known before making the call. All of the
dev->enable values are not available in parallel from coreboot. The previous
code captured the dev->enable values for functions 0, 1, and 2 in the local
sb_config struct, then returned. When function 3 was processed all 4 values
were ready. I think that is similar to what you suggest. The difference is
that the prevoius code called only the sbPcieGppEarlyInit part of
SB_BEFORE_PCI_INIT.

I think your suggestion works for boards that use the sb800 option for 4 x1
ports, as asrock e350m1 does. But what about a board that uses one of the
other sb800 pcie options such as single x4 port? My concern was that
functions 1, 2, and 3 might not even be visible. Even if they are visible,
the person writing devicetree might not choose to include them since they
are not present in a booted system. Because function 0 is visible in all
cases, I thought that is the best place to trigger the cimx call. Because
function 0 is processed first, getting the dev->enable values is not so
easy. The new code scans the devicetree.cb nodes following device 0x15
function 0. Scanning stops on the first pci node not for device 0x15, so
the loop will run a maximum of 3 times. That lets the code gather the needed
dev->enable values.

Thanks,
Scott


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] asrock e350m1: configure sb800 gpp ports to support onboard pcie nic

[Cristian Măgherușan-Stanciu]

Hi Scott,

Please send this patch and the others you might have in the pipeline
to the new gerrit system for review.

Thanks,
Cristi

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Video card bios project

[Stefan Reinauer]

* dove - railing  [110619 14:11]:
> I have phoned Australia and spoke to an expert in Procon.com.au about 2 times
> and corresponded via email.  Procon.com.au are wanting several hundred dollars
> whether it's  my font or theirs.  This is not affordable.  I don't know why 
> vga
> bios is proprietary still and there is not any opensource alternatives.  Thus
> if some opensource enthusiast does it that would be great.  Coreboot project
> are doing main bios.  Similarly if it's done for video card bios that would be
> tremendous.

There is an open source VGA Option ROM coming as part of the SeaBIOS
repository (http://www.seabios.org/). However, it only has support for
the Qemu graphics hardware (and some AMD Geode iirc). So in order to get
it working on your particular graphics card you will have to write code
that initializes the card (that might include initializing the RAM and
GPU on the card, etc). You can run your graphics card option rom in
x86emu and turn logging on to see what hardware accesses it does and try
to replay some of it. It will still need a lot of work to get this
running. Good luck!

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Patch merged into master: b9b5f06 sb800: move spi prefetch and fast read mode to sb bootblock.

[gerrit]

the following patch was just integrated into master:
commit b9b5f06edeabec7fe0ac60d436e507ff555f9b50
Author: Stefan Reinauer 
Date:   Sat Jun 4 10:37:35 2011 -0700

sb800: move spi prefetch and fast read mode to sb bootblock.

So we don't waste time on the first cbfs scan.

Signed-off-by: Stefan Reinauer 
Signed-off-by: Patrick Georgi 
[adapt persimmon with the same change, and work around romcc bug
 in bootblock code: it doesn't like MEMACCESS[idx] |= value;]

Change-Id: Ic4d0e53d3102be0de0bd18b1b8b29c500bd6d997

See http://review.coreboot.org/9 for details.

-gerrit

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Patch merged into master: 8cabd6d Introduced support for 8MB and 16MB flash sizes

[gerrit]

the following patch was just integrated into master:
commit 8cabd6d70581b7f75eebdebd91312ddf787c847d
Author: Cristian Măgherușan-Stanciu 
Date:   Sun Jun 19 21:07:20 2011 +

Introduced support for 8MB and 16MB flash sizes

Change-Id: I217ff84be3575ec09781710f19ad272c88227663
Signed-off-by: Cristian Măgherușan-Stanciu 

See http://review.coreboot.org/49 for details.

-gerrit

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Patch merged into master: e50646e ASRock E350M1: Enable USB3 support

[gerrit]

the following patch was just integrated into master:
commit e50646e88e64af4305517ea8ded3c52bdf9f5bcc
Author: Marshall Buschman 
Date:   Sat Jun 18 12:04:41 2011 -0500

ASRock E350M1: Enable USB3 support

Requires Scott Duplichan's patch for NIC support.
Enables required PCIe port for USB3 - does not interfere
with normal operations on non-USB3 model.

Change-Id: I451bb1b4f799d6485e75fa949933e25e821b65f9
Signed-off-by: Marshall Buschman 

See http://review.coreboot.org/45 for details.

-gerrit

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] asrock e350m1: configure sb800 gpp ports to support onboard pcie nic

[Marc Jones]

Hi Scott,

On Fri, Jun 17, 2011 at 10:26 PM, Scott Duplichan  wrote:
> The attached patch allows the asrock e350m1 onboard nic to work.
> 1) Update the asrock e350m1 devicetree.cb to match the hardware.
> 2) Change the way the sb800 cimx wrapper code works. The original
> cimx code calls sb800 cimx function sbBeforePciInit() once. When
> ported to coreboot, the gpp component of this function was called
> once for each gpp port, as the gpp port's enable/disable state
> became known. A 05/15/2011 change makes the early gpp code run
> only once, triggered by processing the 4th gpp port. This method
> is not general enough because the 4th gpp port is not enabled on
> all boards. With the current change, the early gpp code runs when
> the first gpp port is processed. If any gpp ports are enabled, the
> first must be enabled. Tested with Win7 and linux on asrock e350m1.
> This change will also affect amd inagua, and has not been tested
> on that board.
>
> Signed-off-by: Scott Duplichan 

-   sb_config->PORTCONFIG[0].PortCfg.PortPresent = dev->enabled;
-   return;
-   case (0x15 << 3) | 1: /* 0:15:1 PCIe PortB */
-   sb_config->PORTCONFIG[1].PortCfg.PortPresent = dev->enabled;
-   return;
-   case (0x15 << 3) | 2: /* 0:15:2 PCIe PortC */
-   sb_config->PORTCONFIG[2].PortCfg.PortPresent = dev->enabled;
-   return;
-   case (0x15 << 3) | 3: /* 0:15:3 PCIe PortD */
-   sb_config->PORTCONFIG[3].PortCfg.PortPresent = dev->enabled;
+   {
+   device_t device;
+   for (device = dev; device; device = device->next) {
+   if (dev->path.type != DEVICE_PATH_PCI) continue;
+   if ((device->path.pci.devfn & ~7) != PCI_DEVFN(0x15,0)) 
break;
+   sb_config->PORTCONFIG[device->path.pci.devfn &
3].PortCfg.PortPresent = device->enabled;
+   }

The allocator is going to loop through and call this function for each
device in the devicetree.cb. Is there a reason to change this to a
loop here? It looks like the real fix is moving the SB_BEFORE_PCI_INIT
call to the last device, and to not run for each device. Did I miss
something more subtle in this patch?

Marc




-- 
http://se-eng.com

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Trac reminder: list of new ticket(s)

[coreboot tracker]

  
Ticket
Owner
Status
Description
	
  
#176 ste...@coresystems.de new inteltool: added PCI_DEVICE_ID_INTEL_X44 		0x29e0
  
  
#174 ste...@coresystems.de new Unable to boot from qemu-kvm -- seems to be a cbfs problem
  
  
#170 ste...@coresystems.de new Need coreboot for ASUS P4PE_X/SE
  
  
#169 ste...@coresystems.de new ASUS P4PE-X/SE.
  
  
#168 ste...@coresystems.de new USBDEBUG might slow down coreboot
  
  
#162 oxygene new Move SYSTEM_TYPE to Kconfig
  
  
#160 oxygene new Build system: There's no convincing CFLAGS management for util/*
  
  
#158 w...@gnu.org new buildrom svn error
  
  
#156 hailfinger new Add Layout File capability to v3 and LAR tool
  
  
#154 hailfinger new Flashing BIOSes from Fujitsu/Siemens is not supported
  
  
#150 somebody new AMD DB800 dev board PLL strapping leaves CPU and GLIU in non-optimal clock
  
  
#147 somebody new Linux kernel halts when scanning the PCI bus below 0:14.4 on RS690
  
  
#145 somebody new Fix CMOS handling
  
  
#143 oxygene new unify intel car for model_6[ef]x
  
  
#135 ward new Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E)
  
  
#129 stepan new etherboot payload does not work with HIGH_TABLES
  
  
#128 somebody new Improve email user interface for trac
  
  
#125 somebody new BCM5785 / HT1000 reset functions
  
  
#111 somebody new Add i18n support for translating strings e.g. for bayou / coreinfo
  
  
#110 somebody new Allow for per-device subsystem IDs
  
  
#77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module
  
  
#76 rminnich new coreboot messages should be accessible in dmesg
  
  
#18 oxygene new autoprobe apic cluster and application processors on K8 systems
  
  
#17 stepan new clean up coreboot table handling
  
  
#16 ollie new I2C driver and mainboard Config.lb
  
  
#11 yhlu new pirq table automation
  
  
#5 uwe new Add license header to all source files
  
  
#2 somebody new Complete tables of supported motherboards
  





-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot