Modify

Opened 5 years ago

Closed 5 years ago

#149 closed defect (fixed)

AMD DB800 Hangs at "Decompressing Coreboot to Ram"

Reported by: edwin_beasant@… Owned by: somebody
Priority: major Milestone:
Component: coreboot Keywords:
Cc: Dependencies:
Patch Status: patch needs review

Description

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).

Attachments (2)

geode_lx_stack_fix_r4971.patch (1.7 KB) - added by edwin_beasant@… 5 years ago.
Patch to remove extraneous stack creation on geode lx
coreboot-trunk-geode-lx-cache-fix.patch (5.2 KB) - added by edwin_beasant@… 5 years ago.
patch to fix cache and stack creation on geode under v2

Download all attachments as: .zip

Change History (15)

Changed 5 years ago by edwin_beasant@…

Patch to remove extraneous stack creation on geode lx

comment:1 Changed 5 years ago by marcj303@…

Sorry, I don't understand why moving the stack is a problem. Does that stack not work at that location? Have you done some stack push/pop tests or other memory tests?

comment:2 Changed 5 years ago by edwin_beasant@…

Hi there:

I've run both a ram test and also checked using push/pop - at least for basic operations, the stack seems to function fine at the new location.(including adding debug that writes raw to the serial port to effectively single step trace the problem).

But: After the stack move to 0x400000, then all the previously functioning printk_* functions fail (as does the entire boot process, printk just is the first thing that occurs after the stack move).

A similar failure also occurs if the stack is not moved, and the cache is invalided and written back (wbinvd at done_cache_as_ram_main:). (might be a candidate for trying mb instead).

Hope this provides some more info.

pre-stack move, printk and other functions are fine, post stack move use causes "hang".

I've also been cautious of the CONSOLE_DEBUG_TX_STRING(), need to run some more tests to possibly bisect a little more.

This code was pulled in as a lump with the CBFS transition, along with the interesting caveat that warned that this place was a good place to start! (trac search for geode and cbfs will show it)

Any help appreciated: this patch is what works for me, consistently and reliably.

comment:3 Changed 5 years ago by hailfinger

Is there any reason to use coreboot v2 instead of v3 on the AMD DB800 target?

comment:4 Changed 5 years ago by edwin_beasant@…

I was following the caveats on the front page of coreboot.org download page that most of coreboot v3 has been merged back to the coreboot main repository, and that coreboot v3 branch was now obselete?

comment:5 Changed 5 years ago by hailfinger

v3 is obsolete in theory. However, if you have any GeodeLX target, v3 is the preferred branch because it works very well. v2 is not recommended for GeodeLX until someone ports all the v3 GeodeLX code to v2.

comment:6 Changed 5 years ago by anonymous

Hmm. I did try v3 but had no luck getting it to build. I'll try harder.

In the meantime, this patch does get you a working DB800 board....

comment:7 Changed 5 years ago by hailfinger

Very odd. I just downloaded latest svn of v3, ran "make menuconfig", picked Mainboard->AMD-DB800, save&exit, ran "make" and got an image. Can you tell us about the error message you're seeing in the v3 build?

comment:8 Changed 5 years ago by edwin_beasant@…

V3 issues resolved : someone had messed up the gcc install (how I will never know) on our build system. Coreboot v3 sucessfully built and running on a db800. if only seabios didn't reset on execution now :-) Anyway, I guess it might be an idea to park the patch until v3 DB800 is backported to v2? Thanks again, Edwin

comment:9 Changed 5 years ago by hailfinger

I'm happy to hear that v3 now works. I don't know about SeaBIOS/v3 interactions. It could also depend on which VSA you're using.

comment:10 Changed 5 years ago by edwin_beasant@…

Yup, v3 works very nicely... the reset on 'run payload' seems oddly related to the volume of debugging output created (high level=reset on payload jump, regardless of payload). Working on that one now!

comment:11 Changed 5 years ago by edwin_beasant@…

Properly fixed in this patch:

  • Cache now flushed to RAM correctly via tag-invalidate and winbvd
  • Cache re-enabled at startup, fixes slow coreboot copy
  • Added cache configuration MSR's in V3 style

Changed 5 years ago by edwin_beasant@…

patch to fix cache and stack creation on geode under v2

comment:12 Changed 5 years ago by stepan

Is this patch still needed? Can you please try with the latest v4 HEAD revision?

comment:13 Changed 5 years ago by stepan

  • Resolution set to fixed
  • Status changed from new to closed

The patch was included already.

Add Comment

Modify Ticket

Action
as closed The owner will remain somebody.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.