Re: UPDATE YOUR REPOSITORIES

Hello!
Okay, suppose we haven't added anything to our checked out repositories, how
do we retrieve these updated ones. Just follow the usual steps for a
checkout of a new one?

--
Gregg C Levine hansolofalcon <at> worldnet.att.net
"The Force will be with you always." Obi-Wan Kenobi
  

> -----Original Message-----
> From: coreboot-bounces <at> coreboot.org [mailto:coreboot-bounces <at> coreboot.org]
On
> Behalf Of Stefan Reinauer
> Sent: Saturday, October 31, 2009 5:21 AM
> To: coreboot
> Subject: [coreboot] UPDATE YOUR REPOSITORIES
> 
> Hi,
> 
> as discussed over the last year we finally cleaned up the subversion
> repository structure of the coreboot repository.
> 
> The reasons for this change are:
> - checking out all required utilities with coreboot is easier
> - No more svn externals, as they break https checkouts
> - branching and merging to/from other repositories will be a lot easier.
> - our tree structure more similar to that of other projects
> 
> The tree now roughly looks like this:

Re: UPDATE YOUR REPOSITORIES

Hi, Gregg,

On Nov 1, 2009, at 4:21, "Gregg C Levine" <hansolofalcon <at> worldnet.att.net 
 > wrote:

> Hello!
> Okay, suppose we haven't added anything to our checked out  
> repositories, how
> do we retrieve these updated ones. Just follow the usual steps for a
> checkout of a new one?

Absolutely!

In case of trouble check the download instructions in the coreboot  
wiki. I think I fixed them all. 

Stefan

>

--

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

[v2] r4904 - trunk/src/boot

Author: zbao
Date: 2009-11-01 10:18:23 +0100 (Sun, 01 Nov 2009)
New Revision: 4904

Modified:
   trunk/src/boot/selfboot.c
Log:
typo. trivial. Then -> Than.

Signed-off-by: Zheng Bao <zheng.bao <at> amd.com>
Acked-by: Zheng Bao <zheng.bao <at> amd.com>

Modified: trunk/src/boot/selfboot.c
===================================================================
--- trunk/src/boot/selfboot.c	2009-10-31 22:13:04 UTC (rev 4903)
+++ trunk/src/boot/selfboot.c	2009-11-01 09:18:23 UTC (rev 4904)
@@ -105,7 +105,7 @@
  * - Nearly arbitrary standalone executables can be loaded.
  * - Coreboot is preserved, so it can be returned to.
  * - The implementation is still relatively simple,
- *   and much simpler then the general case implemented in kexec.
+ *   and much simpler than the general case implemented in kexec.
  * 
  */

--

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

Intel P35/Q35/G33/Q33/G31/P31

   Here is a patch for inteltool to print the registers values
  for the P31..Q35 chipset. The registers are (as far as I
  can tell) unchanged with respect to those of the PM965.
  I've no strong ideas on the names: I've chosen
  PCI_DEVICE_ID_INTEL_82G33 as Northbridge name, it
  can obviously be changed to anything else. I've given
  "P35/Q35/G33/Q33/G31/P31" as description, it can also
  be freely changed.

    Please consider for applying,

          Thanks,

                  Loïc

--

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

Re: Intel P35/Q35/G33/Q33/G31/P31

Dear Loïc,

Am Sonntag, den 01.11.2009, 15:11 +0100 schrieb Loïc Grenié:
> Here is a patch for inteltool to print the registers values
> for the P31..Q35 chipset.

I did not receive an attachment and it looks like the list did not too
[1].

Could you resend it please, so that the developers can review it.

Thanks,

Paul

[1] http://www.coreboot.org/pipermail/coreboot/2009-November/054010.html

--

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

Intel P35/Q35/G33/Q33/G31/P31

     Sorry for the forgotten patch !

  Here is a patch for inteltool to print the registers values
 for the P31..Q35 chipset. The registers are (as far as I
 can tell) unchanged with respect to those of the PM965.
 I've no strong ideas on the names: I've chosen
 PCI_DEVICE_ID_INTEL_82G33 as Northbridge name, it
 can obviously be changed to anything else. I've given
 "P35/Q35/G33/Q33/G31/P31" as description, it can also
 be freely changed.

   Please consider for applying,

         Thanks,

                 Loïc

Index: inteltool.h
===================================================================
--- inteltool.h	(revision 4887)
+++ inteltool.h	(working copy)
@@ -52,6 +52,7 @@
 #define PCI_DEVICE_ID_INTEL_82945GM		0x27a0
 #define PCI_DEVICE_ID_INTEL_PM965		0x2a00
 #define PCI_DEVICE_ID_INTEL_82975X		0x277c
+#define PCI_DEVICE_ID_INTEL_82G33		0x29c0
 #define PCI_DEVICE_ID_INTEL_X58			0x3405

 #define PCI_DEVICE_ID_INTEL_82443LX		0x7180

Re: Intel P35/Q35/G33/Q33/G31/P31

Am Sonntag, den 01.11.2009, 21:24 +0100 schrieb Loïc Grenié:

[…]

>    Please consider for applying,

One more thing. Could you add your Signed-off-by line as explained in
the Sign-off Procedure [1]. So that the developers can acknowledge and
commit your patch.

Thanks,

Paul

[1] http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

--

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

Re: The filo crashes if the filo and coreboot overlap.

In relocate_segment().
If the coreboot and filo overlap, it will "slice off" a piece at the
beginning or end. A new segment is allocated. If it is inserted before
the "seg" that is being processed, is there any chance that the "new"
segment will be processed? I am confused about it. On my fam 10 board,
it seems that the "new" segment was not processed and an error happens
when the code jumps to filo which is actually middle of nowhere.

Zheng

-----Original Message-----
From: coreboot-bounces+zheng.bao=amd.com <at> coreboot.org
[mailto:coreboot-bounces+zheng.bao=amd.com <at> coreboot.org] On Behalf Of
Patrick Georgi
Sent: Sunday, November 01, 2009 12:13 AM
To: Zheng Bao
Cc: coreboot <at> coreboot.org
Subject: Re: [coreboot] The filo crashes if the filo and coreboot
overlap.

Am Samstag, den 31.10.2009, 15:43 +0000 schrieb Zheng Bao:
> The filo crashes if the filo and coreboot overlap.
> Since the CBFS is the must-have feature, my family 10
>  board crashes when it jumps to filo. I am trying to
>  find out why. I need help.
> Based on current code, the AMD Family 10 will cause the filo
> and coreboot overlap in RAM. The overlaps_coreboot() in selfboot.c
> will return 1. But I am not sure if it will make the system
> crashes.
What revision is that? There was an issue like that but I fixed it

Re: Error executing VGA ROM with coreboot

On 10/31/2009 10:29 AM, Kevin O'Connor wrote:
> On Sat, Oct 31, 2009 at 01:14:21PM +0530, Mansoor wrote:
> [...]
>> c000:0087 0f01                 ILLEGAL EXTENDED X86 OPCODE
>> c000:0087: 01 ILLEGAL EXTENDED X86 OPCODE!
>> halt_sys: file /prdmd/coreboot-v2/src/devices/../../util/x86emu/x86emu/ops2.c, line 60
>> halted
>> 	AX=0000  BX=0000  CX=0000  DX=0080  SP=ffec  BP=0000  SI=0000  DI=0057
>> 	DS=c000  ES=0000  SS=1000  CS=c000  IP=0089   NV UP EI PL NZ NA PO NC
>> c000:0089 e0                   ILLEGAL EXTENDED X86 OPCODE
>
> If I dissasemble 0f01e0 I get:
>
>     0:   0f 01 e0                smsww  %ax
>
> Though, that might differ depending on the next bytes?
>
> In any case, I get the feeling your rom may be about to enter 32bit
> mode..
>
> You might want to try running:
>
> objdump -m i386 -M i8086 -M suffix -D -b binary myvgarom.rom
>
> and see what it says is at offset 0x0087.
>
Interesting, the Atom has a 32-bit vga bios?
Mansoor please let us know what 0x0087 says.

--

-- 

Re: Error executing VGA ROM with coreboot

> -----Original Message-----
> From: coreboot-bounces+mansoor=iwavesystems.com <at> coreboot.org
> [mailto:coreboot-bounces+mansoor=iwavesystems.com <at> coreboot.org] On Behalf
> Of Peter Stuge
> Sent: Sunday, November 01, 2009 4:14 AM
> To: coreboot <at> coreboot.org
> Subject: Re: [coreboot] Error executing VGA ROM with coreboot
> 
> Mansoor wrote:
> > I have attached the YABEL output.
> 
> Thanks. I think it is helpful. Please follow Kevin's suggestions to
> find out more about what the ROM is trying to do.
> 
> 
 Yes. I will do it

> > Even though coreboot does only the hardware initialization, it has
> > to do a VGA rom init for payloads other than seabios?
> 
> VGA is often not very important for payloads, and option ROMs in
> general fundamentally require a BIOS, which coreboot does not, and
> shall not, offer. If a BIOS environment is needed, then SeaBIOS is
> the way to go.
> 
> 
> > I my case I was planning to use FILO as payload to boot Linux. FILO
> > doesn't do any VGA init.
>