Re: Atom platform porting problem.

On 11/30/2009 09:39 PM, Scott.Hsiao wrote:
> Hello! Joseph,
> Yes, the process stopped at same place everytime.
> Completed log is attatched.
>
> Scott Hsiao
>
> -----Original Message-----
> From: Joseph Smith [mailto:joe <at> settoplinux.org]
> Sent: Tuesday, December 01, 2009 10:31 AM
> To: Scott.Hsiao
> Cc: coreboot <at> coreboot.org
> Subject: Re: [coreboot] Atom platform porting problem.
>
> On 11/30/2009 03:29 AM, Scott.Hsiao wrote:
>> I am porting coreboot to a Intel Atom based mainboard which
>> incorperate atom (N270) + 945GSE + it8718f.
>> The initial progress of north bridge seems okay but I got error in the
>> "dev_initialize" function.
>> Here are the partial output:
>> ....
>> Initializing devices...
>> Root Device init
>> APIC_CLUSTER: 0 init
>> malloc Enter, size 91, free_mem_ptr 0013b998 malloc 0013b998
>> start_eip=0x0000a000, offset=0x00100000, code_size=0x0000005b
>> Initializing SMM handler... ... pmbase = 0x0500
>> SMI_STS: PM1
>> PM1_STS: WAK PWRBTN TMROF
>> GPE0_STS:

Re: Atom platform porting problem.

On 11/30/2009 03:29 AM, Scott.Hsiao wrote:
> I am porting coreboot to a Intel Atom based mainboard which incorperate
> atom (N270) + 945GSE + it8718f.
> The initial progress of north bridge seems okay but I got error in the
> "dev_initialize" function.
> Here are the partial output:
> ....
> Initializing devices...
> Root Device init
> APIC_CLUSTER: 0 init
> malloc Enter, size 91, free_mem_ptr 0013b998
> malloc 0013b998
> start_eip=0x0000a000, offset=0x00100000, code_size=0x0000005b
> Initializing SMM handler... ... pmbase = 0x0500
> SMI_STS: PM1
> PM1_STS: WAK PWRBTN TMROF
> GPE0_STS:
> TCO_STS:
> ... raise SMI#
> Initializing CPU #0
> CPU: vendor Intel device 106c2
> CPU: family 06, model 1c, stepping 02
> Using generic cpu ops (good)
> Enabling cache
> microcode_info: sig = 0x000106c2 pf=0x00000004 rev = 0x00000000
> CPU: Intel(R) Core(TM) CPU N270 @ 1.60GHz.
> Setting fixed MTRRs(0-88) Type: UC
> Setting fixed MTRRs(0-16) Type: WB
> Setting fixed MTRRs(24-88) Type: WB
> DONE fixed MTRRs

[commit] r4969 - trunk/src/superio/smsc/smscsuperio

Author: zbao
Date: 2009-12-01 04:22:16 +0100 (Tue, 01 Dec 2009)
New Revision: 4969

Modified:
   trunk/src/superio/smsc/smscsuperio/superio.c
Log:
Trivial. SCH4304 and SCH4307 have the same device id.

Signed-off-by: Zheng Bao <zheng.bao <at> amd.com>
Acked-by: Peter Stuge <peter <at> stuge.se>
Acked-by: Uwe Hermann <uwe <at> hermann-uwe.de>

Modified: trunk/src/superio/smsc/smscsuperio/superio.c
===================================================================
--- trunk/src/superio/smsc/smscsuperio/superio.c	2009-11-30 23:53:06 UTC (rev 4968)
+++ trunk/src/superio/smsc/smscsuperio/superio.c	2009-12-01 03:22:16 UTC (rev 4969)
@@ -61,7 +61,7 @@
 #define SCH3112		0x7c
 #define SCH5307		0x81	/* Rebranded LPC47B397(?) */
 #define SCH5027D	0x89
-#define SCH4304		0x90	/* SCH4304 */
+#define SCH4304		0x90	/* SCH4304, SCH4307 */

 /* Register defines */
 #define DEVICE_ID_REG	0x20	/* Device ID register */

--

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

Re: Atom platform porting problem.

> >> DONE fixed MTRRs
> >> call enable_fixed_mtrr()
> >> Setting variable MTRR 0, base: 0MB, range: 512MB, type WB
> >> ADDRESS_MASK_HIGH=0xf Unexpected Exception: 13 @ 10:001025e9 - Halting
> >> Code: 0 eflags: 00010002
> >> eax: e0000800 ebx: 0000000f ecx: 00000201 edx: 0000000f
> >> edi: e0000000 esi: 00000000 ebp: 0000000f esp: 00139df4
The register contents look like they are from setting the MTRR, so I'd think
the problem was there.

It seems like some processors don't like having too many bits of the MTRRs
set.  I would suggest hacking it so that it doesn't set the upper bits to
see if that makes a difference.

Thanks,
Myles

--

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

Re: Atom platform porting problem.

Hi Scott,

I am also working on Intel atom based platform.
I got the same problem
Please try to change the following line 
	/* Setup MTRRs */
	x86_setup_mtrrs(36);

to 

	/* Setup MTRRs */
	x86_setup_mtrrs(32);

Atom support only 32 bit address lines

> -----Original Message-----
> From: coreboot-bounces <at> coreboot.org [mailto:coreboot-bounces <at> coreboot.org]
> On Behalf Of Myles Watson
> Sent: Tuesday, December 01, 2009 9:04 AM
> To: 'Scott.Hsiao'; 'coreboot'
> Subject: Re: [coreboot] Atom platform porting problem.
> 
> 
> > >> DONE fixed MTRRs
> > >> call enable_fixed_mtrr()
> > >> Setting variable MTRR 0, base: 0MB, range: 512MB, type WB
> > >> ADDRESS_MASK_HIGH=0xf Unexpected Exception: 13 @ 10:001025e9 -
> Halting
> > >> Code: 0 eflags: 00010002
> > >> eax: e0000800 ebx: 0000000f ecx: 00000201 edx: 0000000f

Re: Atom platform porting problem.

Hi! Mansoor,
It works after adding your patch.
Now coreboot can go on to load the payload (and die XD) and this is just a
second time trial build.
Seems like I have more work to do now.

Thank you to  everyone. 

Scott Hsiao 

-----Original Message-----
From: Mansoor [mailto:mansoor <at> iwavesystems.com] 
Sent: Tuesday, December 01, 2009 1:37 PM
To: 'Myles Watson'; 'Scott.Hsiao'; 'coreboot'
Subject: RE: [coreboot] Atom platform porting problem.

Hi Scott,

I am also working on Intel atom based platform.
I got the same problem
Please try to change the following line 
	/* Setup MTRRs */
	x86_setup_mtrrs(36);

to 

	/* Setup MTRRs */
	x86_setup_mtrrs(32);

Atom support only 32 bit address lines

[commit] r4970 - trunk/src/cpu/intel/model_106cx

Author: stepan
Date: 2009-12-01 09:15:38 +0100 (Tue, 01 Dec 2009)
New Revision: 4970

Modified:
   trunk/src/cpu/intel/model_106cx/model_106cx_init.c
Log:
Atom only supports 32bit MTRRs (trivial)
Signed-off-by: Stefan Reinauer <stepan <at> coresystems.de>
Acked-by: Stefan Reinauer <stepan <at> coresystems.de>

Modified: trunk/src/cpu/intel/model_106cx/model_106cx_init.c
===================================================================
--- trunk/src/cpu/intel/model_106cx/model_106cx_init.c	2009-12-01 03:22:16 UTC (rev 4969)
+++ trunk/src/cpu/intel/model_106cx/model_106cx_init.c	2009-12-01 08:15:38 UTC (rev 4970)
@@ -181,7 +181,7 @@
 #endif

 	/* Setup MTRRs */
-	x86_setup_mtrrs(36);
+	x86_setup_mtrrs(32);
 	x86_mtrr_check();

 #if CONFIG_USBDEBUG_DIRECT

--

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

[commit] r4971 - trunk/src/arch/i386/init

Author: oxygene
Date: 2009-12-01 10:35:19 +0100 (Tue, 01 Dec 2009)
New Revision: 4971

Modified:
   trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb
Log:
Not all boards cope with automatically sized bootblocks, leading to 4GB
images due to the "helpful" 4GB rollover behaviour of ld(1).

Back out r4961, something like this should go in eventually, but more
completely tested and working.

Signed-off-by: Patrick Georgi <patrick.georgi <at> coresystems.de>
Acked-by: Stefan Reinauer <stepan <at> coresystems.de>

Modified: trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb
===================================================================
--- trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb	2009-12-01 08:15:38 UTC (rev 4970)
+++ trunk/src/arch/i386/init/ldscript_fallback_cbfs.lb	2009-12-01 09:35:19 UTC (rev 4971)
@@ -40,10 +40,8 @@
 	_x = .;
 	. = (_x < (CONFIG_ROMBASE - 0x10000 +  CONFIG_ROM_IMAGE_SIZE)) ? (CONFIG_ROMBASE - 0x10000 + 
CONFIG_ROM_IMAGE_SIZE) : _x;

-	__my_rom_start = .; 
-
 	/* This section might be better named .setup */
-	.rom _myrom : {
+	.rom . : {

ldscript_fallback_cbs.lb and 4G files

Hello

Sorry for troubles caused by my ldscript patch that triggered slightly
misbehaviour resulting in 4GB image files in abuild. I didn't noticed
such behaviour on my machine and thats why i send it to ML.

I created separated from ld way to reuse space in top 64k not used by bootblock
patch in attachment. Only missing thing in this patch would be option to enable
firing script that calculates size that can be claimed and adjusting gapsize
so it might be disabled by default.

Signed-off: Maciej Pijanka <maciej.pijanka <at> gmail.com>
(or should i add Blames-To: also?)

best regards
Maciej

-- 
Maciej Pijanka
reg. Linux user #133161

--

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

#149: AMD DB800 Hangs at "Decompressing Coreboot to Ram"

#149: AMD DB800 Hangs at "Decompressing Coreboot to Ram"
-------------------------------------------+--------------------------------
   Reporter:  edwin_beasant@…              |          Owner:  somebody
       Type:  defect                       |         Status:  new     
   Priority:  major                        |      Milestone:          
  Component:  coreboot                     |        Version:  v2      
   Keywords:                               |   Dependencies:          
Patchstatus:  patch needs review           |  
-------------------------------------------+--------------------------------
 A vanilla build of r4971 appears to hang at the "Decompressing Coreboot to
 Ram" message when run on the Zoom DB800 development board.

 After tearing this down, it appears that the code pre "call
 cbfs_and_run_core" (and post done_cache_as ram_main) in cache_as_ram.inc
 for the geode appears to have gained some code from the crt0.S.lb generic
 i386 infrastructure.

 From the end of "done_cache_as_ram_main" to the point of calling
 cbfs_and_run_core appears to attempt to "reset" the stack after flushing
 the cache.

 This causes the subsequent calls to printk_debug() (or related functions)
 to fail.

 (CONSOLE_DEBUG_TX_STRING would also appear to not clean up after itself)

 Solution is to leave the stack as is until the copy to ram has completed.

 Patch attached as tested working on Zoom AMD DB800 board, 256MB of RAM,
 1024k Flash (SST 49LF008A).