headers
Uwe Hermann | 1 May 2008 01:27
Picon
Favicon
Gravatar

Re: ADLO for buildrom

On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote:
> > I think we should move to not wget the tarball but rather get specific git
> > versions to make grabbing fixes from git easier (if no release happens
> > early enough for our purposes).
> > 
> 
> I'd rather not live on the edge.  Since it's a one-developer project we
> should be able to talk him into releases when there's a major change and
> it's stabilized, but if it's important to you we can change it.

Yes please, I'd really like to get the code via git. We don't _have_ to
use HEAD or always update to the latest git version, but we have the
_chance_ to easily update to a newer version, no matter if there's a
tarball or not.

I'm fine using the git version which corresponds to a released tarball
in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3)
I'd say we use the currently latest git.

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jordan Crouse | 1 May 2008 01:32
Picon
Favicon

Re: ADLO for buildrom

On 01/05/08 01:27 +0200, Uwe Hermann wrote:
> On Wed, Apr 30, 2008 at 04:23:47PM -0600, Myles Watson wrote:
> > > I think we should move to not wget the tarball but rather get specific git
> > > versions to make grabbing fixes from git easier (if no release happens
> > > early enough for our purposes).
> > > 
> > 
> > I'd rather not live on the edge.  Since it's a one-developer project we
> > should be able to talk him into releases when there's a major change and
> > it's stabilized, but if it's important to you we can change it.
> 
> Yes please, I'd really like to get the code via git. We don't _have_ to
> use HEAD or always update to the latest git version, but we have the
> _chance_ to easily update to a newer version, no matter if there's a
> tarball or not.
> 
> I'm fine using the git version which corresponds to a released tarball
> in the normal case, but for now (in order to get the fixes for gcc 4.2/4.3)
> I'd say we use the currently latest git.

I just want to say - fear the git fetcher in buildrom.  There be
dragons.

Jordan

--

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Reinauer | 1 May 2008 01:41
Picon

Re: ADLO for buildrom

Myles Watson wrote:
>   
>> -----Original Message-----
>> From: Jordan Crouse [mailto:jordan.crouse <at> amd.com]
>> Sent: Wednesday, April 30, 2008 10:08 AM
>> To: Myles Watson
>> Cc: Coreboot
>> Subject: Re: ADLO for buildrom
>>
>> I don't know what the history of the ADLO code is - any reason why we
>> can't
>> give it a home in payloads/ on SVN instead of living in the buildrom
>> code?
>>     
>
> I don't think so.  The old code was in v2's tree under utils/
>
> I didn't think it was too big of a deal, since it's only one assembly file,
> a make file, and two elf headers.  I admit it looks like a lot with all the
> documentation.
>
> I'm happy to have it live wherever's best.  Who has to set that up?
>
> Thanks,
> Myles
>
>
>   

For v3 we should really integrate the one assembly file rewritten in C
(Continue reading)

Permalink | Reply | 6 comments |
headers
Uwe Hermann | 1 May 2008 01:37
Picon
Favicon
Gravatar

Re: ADLO for buildrom

On Wed, Apr 30, 2008 at 04:24:47PM -0600, Myles Watson wrote:
> > > Index: adlo/elf/elf-header-065kb.payload
> > > Index: adlo/elf/elf-header-068kb.payload
> > 
> > Not sure I like storing blobs in svn. How were they generated?
> 
> By hand with a hex editor.
> 
>  If
> > possible we should store the "source" or some scripts which generates
> > them on-the-fly in svn? This won't hold up a commit though, can be
> > done later. Hm, seems they're hand-crafted, but I'd still like a
> > small script which "crafts" them better than storing blobs nobody
> > can read or understand.
> 
> I'd love a script that crafts them.  Using readelf -a and trial and error
> gets old.

Yep, we should put this on a TODO list (trac).

> > Also, v2's ADLO has three of those, what's the difference to these?
> 
> There used to be a 64K payload for the 16-bit BIOS and a 128K payload for
> the 32-bit BIOS that added other features like ACPI.  Now the 32-bit BIOS
> fits into 64K, so no need for the 128-bit ELF headers.  The reason there are
> two is that I hope to be able to use kexec to load ADLO so that the kernel
> can initialize all the hardware on the motherboard correctly.  Kexec can't
> handle ELFs that have data that isn't page-aligned.  The 68K payload has
> that 4K-aligned loader.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Reinauer | 1 May 2008 01:44
Picon

Re: ADLO for buildrom

Jordan Crouse wrote:
> On 30/04/08 11:21 -0600, Myles Watson wrote:
>   
>> On Wed, Apr 30, 2008 at 10:18 AM, Jordan Crouse <jordan.crouse <at> amd.com> wrote:
>>     
>>> On 30/04/08 10:16 -0600, Myles Watson wrote:
>>>  >
>>>  >
>>>  > > -----Original Message-----
>>>  > > From: Jordan Crouse [mailto:jordan.crouse <at> amd.com]
>>>  > > Sent: Wednesday, April 30, 2008 10:08 AM
>>>  > > To: Myles Watson
>>>  > > Cc: Coreboot
>>>  > > Subject: Re: ADLO for buildrom
>>>  > >
>>>  > > I don't know what the history of the ADLO code is - any reason why we
>>>  > > can't
>>>  > > give it a home in payloads/ on SVN instead of living in the buildrom
>>>  > > code?
>>>  >
>>>  > I don't think so.  The old code was in v2's tree under utils/
>>>  >
>>>  > I didn't think it was too big of a deal, since it's only one assembly file,
>>>  > a make file, and two elf headers.  I admit it looks like a lot with all the
>>>  > documentation.
>>>  >
>>>  > I'm happy to have it live wherever's best.  Who has to set that up?
>>>
>>>  Its all set up - just push - I recommend payloads/adlo.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Reinauer | 1 May 2008 01:47
Picon

Re: ADLO for buildrom

Myles Watson wrote:
> There is very little duplicated here.  The ADLO in coreboot relies on
> building the BOCHS bios from source with dev86, but the payloads/adlo uses
> the new legacybios version.  The only thing that is exactly the same is one
> of the elf headers.

please also note we have a gsoc student working on legacy bios
integration again this summer. maybe we should stop the plenty
discussion here and leave things as they are until that project is done?

Does legacybios from Kevin O'Connor boot Vista?

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 4 comments |
headers
Stefan Reinauer | 1 May 2008 01:48
Picon

Re: ADLO for buildrom

Myles Watson wrote:
>> On Wed, 30 Apr 2008 09:58:56 -0600, "Myles Watson" <mylesgw <at> gmail.com>
>> wrote:
>>     
>>> It boots Windows XP in QEMU.
>>>       
>> Sweet:-)
>>
>> What about booting XP on real hardware?
>>     
>
> The loader needs to be customized for each board, or we need to pass some
> information like RAM map from coreboot before that will work.
>   

Which is why it really should, no, it has to be built into coreboot
itself. coreboot already has all the knowledge required for this.
Duplicating efforts that we did in C in another assembler chunk is plain
b0rked.

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 15 comments |
headers
Stefan Reinauer | 1 May 2008 01:51
Picon

Re: ADLO for buildrom

Uwe Hermann wrote:
> On Wed, Apr 30, 2008 at 01:31:33PM -0600, Myles Watson wrote:
>   
>> There is very little duplicated here.  The ADLO in coreboot relies on
>> building the BOCHS bios from source with dev86, but the payloads/adlo uses
>> the new legacybios version.  The only thing that is exactly the same is one
>> of the elf headers.
>>     
>
> Can you elaborate? I think I never heard of legacybios so far. What's
> the purpose and history and relation to ADLO of that? Does it _replace_
> ADLO completely or enhance it or... ? Also, from a quick glance it
> doesn't seem to be written specifically for coreboot, what's the
> original purpose (just curious)?
>
> Do you have a comparison between ADLO as in v2 svn vs. legacybios?
>
>   
Please please please do not make 5 trees in 5 places with different
copies of ADLO and its legacy bios. This is not the way to go.

1. if it needs to be moved to payloads/ lets move it.
2. if we should switch to legacybios from Kevin O'Connor let's do this
too, or lets leave a choice.

> Also note that legacybios is GPLv3, not sure if that's a problem
> for us. Do we link GPLv2 code against that?

It's not linked in at any point. It's loaded. Just like the linux kernel
loads ELF files. At least for v3 we can say for sure.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan A. Kollasch | 1 May 2008 01:54
Gravatar

Re: [PATCH] MS7135 fixes and updates

On Wed, Apr 30, 2008 at 01:09:56PM -0400, Ward Vandewege wrote:
> On Wed, Apr 30, 2008 at 01:03:21PM -0400, Joe wrote:
> > 
> > 
> > 
> > On Wed, 30 Apr 2008 15:21:13 +0000, "Jonathan A. Kollasch"
> > <jakllsch <at> kollasch.net> wrote:
> > > Fix various issues on MSI MS7135 board.
> > > 
> > >  - enable floppy drive controller so that some legacy VGA ROMs will work
> > 
> > Little confused by this. Why does the floppy drive controller have to be
> > enabled for VGA??
> 
> I think this might be a 'feature' of the proprietary VGA ROM... Who knows
> why - there's no source...

Yeah, I found that a RV370 board I have was working when the
superio address was wrong, because the floppy controller
was in the power-on-reset state of enabled.  When I corrected
the superio address, and the FDC got disabled as instructed,
the VGA BIOS did weird things I don't exactly recall and
didn't work.  I then tried enabling the FDC again and
found that this made the VGA BIOS work again.  I have
no idea why it wants to touch the floppy controller,
but I have to let it or it won't work.

	Jonathan Kollasch

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Stefan Reinauer
 | 
1 May 2008 01:58






Picon





Re: ADLO for buildrom


Myles Watson wrote:

> Legacybios is the Bochs BIOS ported to compile on gcc instead of with the
> dev86 tools.  Kevin's intent (I'm paraphrasing) was to make it easy to
> update the BIOS so that more developers would be able to fix/improve it.  He
> hoped that the ability to boot operating systems with BIOS callbacks would
> make Coreboot more popular as well.
>   

Is it tested and reliable in depth anywhere close to Qemu/Bochs BIOS? Or
are we exchanging a fragile piece of code with a fragile and untested one?
The latest legacybios (0.2.0) was very bochs/qemu dependent, ie. it
expected ram size reported in cmos instead of reading lbtable. We should
definitely have a
#define COMPILE_FOR_COREBOOT in either legacybios or bochs/qemu bios.

I am all for using legacybios with coreboot, and we should not only use
it for ADLO but also for our vga init code (which implements half a
legacy bios, too)
And for loading blocks from SCSI controllers with int13.

Lets clean this up once and forever.

I am copying Zhang Rui on this mail. He is the guy who is going to work
on booting from SCSI (or, more generically int13 callback based boot
devices) for our GSoC project.

> ADLO in v2 is based on a very old version of Bochs' BIOS that has many
> timing problems (e.g., small loops that were supposed to wait until the CD
> spun up.)  The new Bochs BIOS as compiled with dev86 is 128K, while Kevin's

(Continue reading)






Permalink
| Reply
| 3 comments  
| 



  

  

  

  


  





    



Gmane