author for early startup code needed

Hi,

we have a small problem in v3: Author attributions for the early
16-bit/32-bit startup code have been lost. The earliest evidence of that
code is in v2 revision 1657, committed by Eric Biederman. Some code
there has a copyright 2000 by Ron, some other code is unclear.

I'd rather avoid wrong copyright headers in a new file in v3.

Regards,
Carl-Daniel

--

-- 
http://www.hailfinger.org/

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[PATCH] v3: factor out common stage0 code

We have lots of bit-for-bit identical code in the various stage0
implementations. Factor out the 16 bit code with associated protected
mode activation.

I'm open to moving even more common code out, but this is a well-defined
start.
If you think the stage0_common.S name is bad/evil/dumb, you're welcome
to suggest an alternative. No problem from my side.

This cleanup has been prepared for by r902, r905 and r907.

Boot tested on qemu. Build tested on i586, geodelx, k8.

The diffstat is most enlightening:
 amd/stage0.S     |  145 ---------------------------------------------
 geodelx/stage0.S |  145 ---------------------------------------------
 i586/stage0.S    |  145 ---------------------------------------------
 stage0_common.S  |  145 +++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 148 insertions(+), 432 deletions(-)

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>

Index: corebootv3-arch_x86_cleanup/arch/x86/geodelx/stage0.S
===================================================================
--- corebootv3-arch_x86_cleanup/arch/x86/geodelx/stage0.S	(Revision 907)
+++ corebootv3-arch_x86_cleanup/arch/x86/geodelx/stage0.S	(Arbeitskopie)
@@ -28,112 +28,7 @@
 #include <macros.h>
 #include <amd_geodelx.h>

libpayload: Rename Geode video driver to Geode LX video driver.

Please ack and commit. I can not commit to the libpayload repo, so
whoever acks it gets to commit too. After applying the patch, please
also run:

svn mv drivers/video/geode.c drivers/video/geodelx.c

//Peter

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[PATCH] Fix v3 GeodeLX stack and global variable pointer corruption

Fix v3 GeodeLX stack and global variable pointer corruption.
We had a jump instead of a call to stage1_main in geodelx/stage0.S. That
means all accesses to bist and init_detected were off by 8 bytes and
collided with accesses to the global variable pointer.

Found during my cleanup runs.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>

Index: corebootv3-arch_x86_cleanup/arch/x86/geodelx/stage0.S
===================================================================
--- corebootv3-arch_x86_cleanup/arch/x86/geodelx/stage0.S	(Revision 907)
+++ corebootv3-arch_x86_cleanup/arch/x86/geodelx/stage0.S	(Arbeitskopie)
@@ -376,7 +376,7 @@
 	pushl	$0
 	/* First parameter: bist */
 	pushl	%eax
-	jmp	stage1_main
+	call	stage1_main
 	/* We will not go back. */

 /* Reset vector. */

--

-- 
http://www.hailfinger.org/

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

r907 - in coreboot-v3/arch/x86: amd geodelx i586

Author: hailfinger
Date: 2008-10-08 01:53:02 +0200 (Wed, 08 Oct 2008)
New Revision: 907

Modified:
   coreboot-v3/arch/x86/amd/stage0.S
   coreboot-v3/arch/x86/geodelx/stage0.S
   coreboot-v3/arch/x86/i586/stage0.S
Log:
stage0 code for K8 and i586 has lots of mostly identical parts even in
CAR code.

Reduce the diff of the mostly identical parts to zero. That involves
changing comments, whitespace and instruction order.

Now we can split out the common parts more easily and concentrate on the
differences.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>

Modified: coreboot-v3/arch/x86/amd/stage0.S
===================================================================
--- coreboot-v3/arch/x86/amd/stage0.S	2008-10-07 23:13:49 UTC (rev 906)
+++ coreboot-v3/arch/x86/amd/stage0.S	2008-10-07 23:53:02 UTC (rev 907)
@@ -17,8 +17,14 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
  */
+

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 <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

r906 - in coreboot-v3: . mainboard/amd/dbm690t

Author: rminnich
Date: 2008-10-08 01:13:49 +0200 (Wed, 08 Oct 2008)
New Revision: 906

Modified:
   coreboot-v3/Rules.make
   coreboot-v3/mainboard/amd/dbm690t/Makefile
Log:
dbm690t now builds. Testers anyone?

Quick fix to Rules.make to avert issues with half-created statictree.[ch]
causing compiles to fail. This was confusing for users. 

Signed-off-by: Ronald G. Minnich <rminnich <at> gmail.com>
Acked-by: Ronald G. Minnich <rminnich <at> gmail.com>

Modified: coreboot-v3/Rules.make
===================================================================
--- coreboot-v3/Rules.make	2008-10-07 21:59:21 UTC (rev 905)
+++ coreboot-v3/Rules.make	2008-10-07 23:13:49 UTC (rev 906)
@@ -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.$$

alix.2c3 stops at mainboard_pre_payload: done

Hello!

I'm experimenting with alix.2c3 here, but have no luck.
I tried coreboot v3 (r870, r898) with filo (r64, r80) and coreinfo
(r3640) payloads (with libpayload r3640). All ends up with following:

last n-lines snippet (can do full log if it's needed)
.......
Wrote coreboot table at: 0x00000500 - 0x00000bbc  checksum 50f0
Show all devs...
root(Root Device): enabled 1 have_resources 0 initialized 1
cpus: Unknown device path type: 0
cpus(): enabled 1 have_resources 0 initialized 0
apic_0(APIC: 00): enabled 1 have_resources 1 initialized 1
domain_0_pci_1_0(PCI: 00:01.0): enabled 1 have_resources 1 initialized 1
domain_0_pci_f_0(PCI: 00:0f.0): enabled 1 have_resources 1 initialized 1
domain_0_pci_f_2(PCI: 00:0f.2): enabled 1 have_resources 1 initialized 1
domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0
dynamic PCI: 00:01.1(PCI: 00:01.1): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:01.2(PCI: 00:01.2): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:09.0(PCI: 00:09.0): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0a.0(PCI: 00:0a.0): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0b.0(PCI: 00:0b.0): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0f.3(PCI: 00:0f.3): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0f.4(PCI: 00:0f.4): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0f.5(PCI: 00:0f.5): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0f.6(PCI: 00:0f.6): enabled 1 have_resources 1 initialized 1
dynamic PCI: 00:0f.7(PCI: 00:0f.7): enabled 1 have_resources 1 initialized 1
Stage2 code done.
LAR: Attempting to open 'normal/payload'.

r905 - in coreboot-v3/arch/x86: amd geodelx i586

Author: hailfinger
Date: 2008-10-07 23:59:21 +0200 (Tue, 07 Oct 2008)
New Revision: 905

Modified:
   coreboot-v3/arch/x86/amd/stage0.S
   coreboot-v3/arch/x86/geodelx/stage0.S
   coreboot-v3/arch/x86/i586/stage0.S
Log:
stage0 code for GeodeLX, K8 and i586 is mostly identical everywhere
except for the actual CAR code and inital #includes and #defines.

Reduce the diff of the mostly identical parts to zero. That involves
changing comments, whitespace and instruction order to the best variant
present in the 3 files.

Now we can split out the common parts more easily and concentrate on the
differences.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>

Modified: coreboot-v3/arch/x86/amd/stage0.S
===================================================================
--- coreboot-v3/arch/x86/amd/stage0.S	2008-10-07 00:29:36 UTC (rev 904)
+++ coreboot-v3/arch/x86/amd/stage0.S	2008-10-07 21:59:21 UTC (rev 905)
@@ -43,6 +43,7 @@
 	/* Save the BIST result. */
 	movl	%eax, %ebp;

Proposed rom renaming change

Our current ROM naming scheme in buildrom is <vendor>-<platform>.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:

<vendor>-<platform>-cbv[23]-<payload>.rom

Thoughts?

Jordan
--

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: keyboard tricks in SimNOW?

> -----Original Message-----
> From: Jordan Crouse [mailto:jordan.crouse <at> amd.com]
> Sent: Tuesday, October 07, 2008 11:10 AM
> To: Myles Watson
> Subject: Re: keyboard tricks in SimNOW?
> 
> On 06/10/08 10:09 -0600, Myles Watson wrote:
> > I'm pretty sure it was the default.  My machine can't build a working
> LAB
> > image right now.  It gets the "linuxrc[1] trap divide error".
> >
> > There also seems to be a problem with the permission bits of
> > bin/construct-rom.sh  I had to make it executable.  I don't know how to
> make
> > that update in svn, or I'd just do it.
> >
> > I'm using this image that I built a while ago on a different machine.
> 
> Okay - I just built a v2 image and it works fine.  I'm going to try v3
> next.
> 

I forgot to say that I was using the 64-bit kernel.  It's smaller and what I
needed.  Hopefully you get the same success there too.

Thanks,
Myles

--