I wanted to compile without an mptable for debugging, but it wasn't as easy as I'd hoped. This makes it easier.
Since the asus/m2v_mx_se doesn't need mptables, remove mptable.c now that it compiles without it.
Build tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On 12.03.2009 18:21 Uhr, Myles Watson wrote:
I wanted to compile without an mptable for debugging, but it wasn't as easy as I'd hoped. This makes it easier.
Since the asus/m2v_mx_se doesn't need mptables, remove mptable.c now that it compiles without it.
Build tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, r3998. I committed the generic part, but not the part that actually drops the mptable from m2v_mx_se since you mentioned you did this for debugging.
Stefan
On Thu, Mar 12, 2009 at 11:43 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 12.03.2009 18:21 Uhr, Myles Watson wrote:
I wanted to compile without an mptable for debugging, but it wasn't as easy as I'd hoped. This makes it easier.
Since the asus/m2v_mx_se doesn't need mptables, remove mptable.c now that it compiles without it.
Build tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, r3998. I committed the generic part, but not the part that actually drops the mptable from m2v_mx_se since you mentioned you did this for debugging.
Thanks for committing it.
Sorry I wasn't more clear. I was debugging a different board (Tyan s2895) that actually has an mptable.
Dropping the compilation of the empty file was just minor cleanup.
Thanks, Myles
On Thu, Mar 12, 2009 at 11:21:09AM -0600, Myles Watson wrote:
I wanted to compile without an mptable for debugging, but it wasn't as easy as I'd hoped. This makes it easier.
Since the asus/m2v_mx_se doesn't need mptables, remove mptable.c now that it compiles without it.
Hi Myles,
While working on this code, do you think you could clean it up a little too? There is no reason to ever put the mptable in the first 4K of ram (it's not even in spec to put the table there). It's fine to put it in the 0xf0000 segment, and it's fine to put it at the end of ram when HAVE_HIGH_TABLES is set, but putting it in the first 4K doesn't make any sense.
-Kevin
On Thu, Mar 12, 2009 at 5:15 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Mar 12, 2009 at 11:21:09AM -0600, Myles Watson wrote:
I wanted to compile without an mptable for debugging, but it wasn't as easy as I'd hoped. This makes it easier.
Since the asus/m2v_mx_se doesn't need mptables, remove mptable.c now that it compiles without it.
Hi Myles,
While working on this code, do you think you could clean it up a little too? There is no reason to ever put the mptable in the first 4K of ram (it's not even in spec to put the table there). It's fine to put it in the 0xf0000 segment, and it's fine to put it at the end of ram when HAVE_HIGH_TABLES is set, but putting it in the first 4K doesn't make any sense.
Does that apply to all the tables? I don't know the code that well. All I was doing was disabling the mptable cleanly. If there's consensus that we don't need any tables that low it would be an easy change to make. Otherwise I think it's better left to someone who understands all the tables and why they are where they are. It makes sense to me to put them all in one place.
Thanks, Myles
On Fri, Mar 13, 2009 at 10:37:06AM -0600, Myles Watson wrote:
Does that apply to all the tables? I don't know the code that well. All I was doing was disabling the mptable cleanly. If there's consensus that we don't need any tables that low it would be an easy change to make. Otherwise I think it's better left to someone who understands all the tables and why they are where they are. It makes sense to me to put them all in one place.
The coreboot table should go at 0x500 - that table is defined by the coreboot group to be valid at that location. All the other tables can go in 0xf0000 (or they can all go in the end of ram if HAVE_HIGH_TABLES is set).
-Kevin
On 14.03.2009 0:53 Uhr, Kevin O'Connor wrote:
On Fri, Mar 13, 2009 at 10:37:06AM -0600, Myles Watson wrote:
Does that apply to all the tables? I don't know the code that well. All I was doing was disabling the mptable cleanly. If there's consensus that we don't need any tables that low it would be an easy change to make. Otherwise I think it's better left to someone who understands all the tables and why they are where they are. It makes sense to me to put them all in one place.
The coreboot table should go at 0x500 - that table is defined by the coreboot group to be valid at that location. All the other tables can go in 0xf0000 (or they can all go in the end of ram if HAVE_HIGH_TABLES is set).
Would there be another 40 bytes available for a coreboot table "root pointer/floating table" structure somewhere at 0xf0000? I've seen issues with packing the coreboot table at 0x500 and I would like to put it to the HIGH_TABLES area. Question is, how can SeaBIOS find it there?
On Sat, Mar 14, 2009 at 12:00:27PM +0100, Stefan Reinauer wrote:
On 14.03.2009 0:53 Uhr, Kevin O'Connor wrote:
The coreboot table should go at 0x500 - that table is defined by the coreboot group to be valid at that location. All the other tables can go in 0xf0000 (or they can all go in the end of ram if HAVE_HIGH_TABLES is set).
Would there be another 40 bytes available for a coreboot table "root pointer/floating table" structure somewhere at 0xf0000? I've seen issues with packing the coreboot table at 0x500 and I would like to put it to the HIGH_TABLES area.
I agree - it would be nice to put all the tables in one place.
Question is, how can SeaBIOS find it there?
How about passing the location of the coreboot table pointer as a parameter to the payload? (Either in EAX or as the first parameter on the stack.)
-Kevin
Kevin O'Connor wrote:
Question is, how can SeaBIOS find it there?
How about passing the location of the coreboot table pointer as a parameter to the payload? (Either in EAX or as the first parameter on the stack.)
I like these ideas!
Maybe also relevant - how does ofw pass the device tree on?
//Peter
-
Kevin O'Connor -
Myles Watson -
Peter Stuge -
Stefan Reinauer