Re: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets

[Myles Watson]

> On Thu, Jan 10, 2008 at 04:39:57PM -0700, Myles Watson wrote:
> > Sorry to be so dense, but it looks like you added mkdir -p in a lot of
> > places for directories, even though there are already makefile rules for
> > them.
> 
> Right, that was stupid, I had not noticed those. This patch fixes that,
> and
> it's updated to r94. Thanks for catching that :)

Thanks for catching my "echo" (Debug statement I forgot to remove) too.

This patch breaks the dependencies somehow.  Before your patch, I could
remove the work/uclibc directory and only uclibc would get rebuilt.  Now it
rebuilds mkelfimage, the kernel, etc.

I looked for the problem, but didn't see it right away.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] AMD SimNOW question

[Myles Watson]

Sorry I misunderstood.

I still recommend the same thing, only tell the Linux kernel to use the
serial port as the console, console=ttyS0,115200

You don't want to try to capture the actual VGA probably.

Good luck,

Myles

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 11, 2008 2:52 PM
> To: [EMAIL PROTECTED]
> Cc: 'LinuxBIOS'
> Subject: Re: [LinuxBIOS] AMD SimNOW question
> 
> No the serial port output looks ok.  It is the "vga" ouput I need to
> capture.  The kernel as loader is crashing...
> 
> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
> 
> 
> 
> Myles Watson wrote:
> > There are a couple of ways, which you can find here:
> >
> > http://linuxbios.org/AMD_SimNow
> >
> > if you want it to go to a file, instead of
> >
> > cat /home/myles/.simnow/com1/simnow_out
> >
> > try
> >
> > cat /home/myles/.simnow/com1/simnow_out > myfile.log
> >
> > otherwise, if you're using snserial there is some option to do that as
> well.
> >
> > Myles
> >
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, January 11, 2008 2:33 PM
> >> To: Myles Watson; LinuxBIOS
> >> Subject: Re: [LinuxBIOS] AMD SimNOW question
> >>
> >> Is there anyway under SimNow to send the console output to a log file.
> >>
> >> I have linuxbios up and running :-) but the Linux kernel I have as a
> >> boot loader is crashing..  I have tried to stop it at the point when it
> >> starts dmping the same message to the screen but it is nearly
> impossible
> >> to time it right.
> >>
> >> /*
> >> Marc Karasek
> >> MTS
> >> Sun Microsystems
> >> mailto:[EMAIL PROTECTED]
> >> ph:770.360.6415
> >> */
> >>
> >>
> >>
> >> Myles Watson wrote:
> >>
> >>> Marc,
> >>>
> >>> I sent the wrong one for serengeti-cheetah last time.  Sorry.
> >>>
> >>> Myles
> >>>
> >>> On Jan 11, 2008 11:49 AM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> I have managed to cobble together a build structure that tries to
> >>>>
> >> build.
> >>
> >>>> It gets to the point of building the linuxbios image and it chokes
> >>>> because the image is to large for the romsize.
> >>>>
> >>>> Can someone shed some light on what Config.lb should be set to to get
> >>>> this to compile.
> >>>>
> >>>> The payload buildrom is generating is 790,000+ bytes big.
> >>>>
> >>>> /*
> >>>> Marc Karasek
> >>>> MTS
> >>>> Sun Microsystems
> >>>> mailto:[EMAIL PROTECTED]
> >>>> ph:770.360.6415
> >>>> */
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ron minnich wrote:
> >>>>
> >>>>
> >>>>> On Jan 8, 2008 2:38 PM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I have found the main problem with svn.  It looks like if you use
> svn
> >>>>>>
> >> co
> >>
> >>>>>> http://  it will use the proxy settings under servers.  If you do a
> >>>>>>
> >> svn
> >>
> >>>>>> co svn:// it tries to do a dns lookup, which fails behind a proxy
> >>>>>>
> >> server
> >>
> >>>>>> :-(.  I have not been able to find any info on setting svn up to
> use
> >>>>>>
> >> a
> >>
> >>>>>> proxy when doing svn:// type checkouts.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> There is a way to do it, maybe:
> >>>>>
> >> http://subversion.tigris.org/faq.html#proxy
> >>
> >>>>> ron
> >>>>>
> >>>>>
> >>>>>
> >
> >
> >



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] AMD SimNOW question

[Myles Watson]

There are a couple of ways, which you can find here: 

http://linuxbios.org/AMD_SimNow

if you want it to go to a file, instead of 

cat /home/myles/.simnow/com1/simnow_out

try

cat /home/myles/.simnow/com1/simnow_out > myfile.log

otherwise, if you're using snserial there is some option to do that as well.

Myles

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 11, 2008 2:33 PM
> To: Myles Watson; LinuxBIOS
> Subject: Re: [LinuxBIOS] AMD SimNOW question
> 
> Is there anyway under SimNow to send the console output to a log file.
> 
> I have linuxbios up and running :-) but the Linux kernel I have as a
> boot loader is crashing..  I have tried to stop it at the point when it
> starts dmping the same message to the screen but it is nearly impossible
> to time it right.
> 
> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
> 
> 
> 
> Myles Watson wrote:
> > Marc,
> >
> > I sent the wrong one for serengeti-cheetah last time.  Sorry.
> >
> > Myles
> >
> > On Jan 11, 2008 11:49 AM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >
> >> I have managed to cobble together a build structure that tries to
> build.
> >>
> >> It gets to the point of building the linuxbios image and it chokes
> >> because the image is to large for the romsize.
> >>
> >> Can someone shed some light on what Config.lb should be set to to get
> >> this to compile.
> >>
> >> The payload buildrom is generating is 790,000+ bytes big.
> >>
> >> /*
> >> Marc Karasek
> >> MTS
> >> Sun Microsystems
> >> mailto:[EMAIL PROTECTED]
> >> ph:770.360.6415
> >> */
> >>
> >>
> >>
> >>
> >> ron minnich wrote:
> >>
> >>> On Jan 8, 2008 2:38 PM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> I have found the main problem with svn.  It looks like if you use svn
> co
> >>>> http://  it will use the proxy settings under servers.  If you do a
> svn
> >>>> co svn:// it tries to do a dns lookup, which fails behind a proxy
> server
> >>>> :-(.  I have not been able to find any info on setting svn up to use
> a
> >>>> proxy when doing svn:// type checkouts.
> >>>>
> >>>>
> >>> There is a way to do it, maybe:
> http://subversion.tigris.org/faq.html#proxy
> >>>
> >>> ron
> >>>
> >>>



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] r3021 build service

[Myles Watson]

Here's my attempt at fixing abuild for serengeti_cheetah_fam10.

It's pretty trivial, since I'm just using the ROM_IMAGE_SIZE in
Config.lb and putting it in Config-abuild.lb.  When I reduce this size
(past what it is in Config-abuild.lb), it gives me the same overlap
error in my system that abuild is seeing.

I also added XIP_ROM_SIZE, although I admit freely that I don't know
anything about this variable.  I just wanted to make it match Marc's
Config.lb.

Maybe the right thing to do would be to remove both XIP_ROM_SIZE
references in Config-abuild.lb

Either way,  I think the ROM_IMAGE_SIZE change will help.

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

On Dec 20, 2007 12:19 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
>
> Corey Osgood wrote:
> > Corey Osgood wrote:
> >
> >> On Dec 19, 2007 4:26 PM, LinuxBIOS information <[EMAIL PROTECTED]
> >> <mailto:[EMAIL PROTECTED]>> wrote:
> >>
> >> Dear LinuxBIOS readers!
> >>
> >> This is the automated build check service of LinuxBIOS.
> >>
> >> The developer "cozzie" checked in revision 3021 to
> >> the LinuxBIOS source repository and caused the following
> >> changes:
> >>
> >> Change Log:
> >> More abuild fixes, this should be the last (trivial)
> >>
> >> Signed-off-by: Corey Osgood < [EMAIL PROTECTED]
> >> <mailto:[EMAIL PROTECTED]>>
> >> Acked-by: Corey Osgood <[EMAIL PROTECTED]
> >> <mailto:[EMAIL PROTECTED]>>
> >>
> >>
> >>
> >> Build Log:
> >> Compilation of amd:serengeti_cheetah_fam10 is still broken
> >> See the error log at
> >> 
> >> http://qa.linuxbios.org/log_buildbrd.php?revision=3021&device=serengeti_cheetah_fam10&vendor=amd
> >> 
> >> <http://qa.linuxbios.org/log_buildbrd.php?revision=3021&device=serengeti_cheetah_fam10&vendor=amd>
> >>
> >>
> >> Oh for cripe's sake, ld now? Will fix when I make it home tonight.
> >>
> >> -Corey
> >>
> >
> > Scratch that, someone else can wrap it up. I don't know if it just needs
> > a ROM_SIZE increase or something deeper is wrong, I've been completely
> > unable to reproduce the error. Someone with access to the build server
> > or a similar setup is probably the best candidate to fix this (I've done
> > my share ;-) )
> >
> > -Corey
> >
> >
>
> Corey,
>
> I looked at the output and I don't see anything obvious. It doesn't fail
> for me either. I'll work with Stefan when he is able to look at it.
>
> Marc
>
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:[EMAIL PROTECTED]
> http://www.amd.com/embeddedprocessors
>
>
>
>
>
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>
Index: targets/amd/serengeti_cheetah_fam10/Config-abuild.lb
===
--- targets/amd/serengeti_cheetah_fam10/Config-abuild.lb	(revision 3046)
+++ targets/amd/serengeti_cheetah_fam10/Config-abuild.lb	(working copy)
@@ -13,7 +13,8 @@
 
 romimage "fallback" 
 	option USE_FALLBACK_IMAGE=1
-	option ROM_IMAGE_SIZE=0x2
+	option ROM_IMAGE_SIZE=0x3f000
+	option XIP_ROM_SIZE=0x4
 	option LINUXBIOS_EXTRA_VERSION=".0-fallback"
 	payload __PAYLOAD__
 end
@@ -26,4 +27,4 @@
 	option LINUXBIOS_EXTRA_VERSION=".0-failover"
 end
 
-buildrom ./linuxbios.rom ROM_SIZE "fallback" "failover"
\ No newline at end of file
+buildrom ./linuxbios.rom ROM_SIZE "fallback" "failover"
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets

[Myles Watson]

> -Original Message-
> From: Corey Osgood [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 11, 2008 12:27 PM
> To: [EMAIL PROTECTED]
> Cc: 'Jordan Crouse'; linuxbios@linuxbios.org
> Subject: Re: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets
> 
> Myles Watson wrote:
> >> Author: jcrouse
> >> Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008)
> >> New Revision: 3046
> >>
> >> Modified:
> >>trunk/LinuxBIOSv2/targets/buildtarget
> >> Log:
> >> Add the ability to extend CFLAGS as needed for several new distros
> >> Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
> >> Acked-by: Peter Stuge <[EMAIL PROTECTED]>
> >> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
> >> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
> >>
> >>
> >>
> >> Modified: trunk/LinuxBIOSv2/targets/buildtarget
> >> ===
> >> --- trunk/LinuxBIOSv2/targets/buildtarget  2008-01-11 00:32:07 UTC
> (rev
> >> 3045)
> >> +++ trunk/LinuxBIOSv2/targets/buildtarget  2008-01-11 18:23:47 UTC
> (rev
> >> 3046)
> >> @@ -53,4 +53,25 @@
> >>  export PYTHONPATH=$config_dir
> >>  $PYTHON $config_py $config_lb $lbpath
> >>
> >> +# now start checking for distro-specific breakage.
> >> +## This check is for the no stack protector mess.
> >> +EXTRA_CFLAGS=
> >> +
> >> +if [ -z "$CC" ]; then
> >> +   CC=gcc
> >> +fi
> >> +
> >> +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp
> >> +
> >> +if [ $? -eq 0 ]; then
> >> +   EXTRA_CFLAGS=-fno-stack-protector
> >> +fi
> >>
> >
> > This adds the flag for me, even though I didn't need it.  Was that
> intended?
> >
> > Myles
> I don't think it matters, if your gcc wasn't compiled to do stack
> checking it'll just ignore it. But I think it breaks gcc 3.x, do we
> care? IMHO, no.

In that case we shouldn't do a check, we should just add it to the flags.

Myles

> -Corey



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] AMD SimNOW question

[Myles Watson]

Here are my Config.lb files for Serengeti Cheetah and fam 10.

Good luck,
Myles

On Jan 11, 2008 12:17 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> In the TARGET file, you can put something like this:
>
> option ROM_SIZE=1024*1024
>
> that gets you 1M
>
> ron
>


Config.lb
Description: Binary data


Config.lb
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] r90 - in buildrom-devel: . config/platformspackages/linuxbios packages/linuxbios/conf.v3

[Myles Watson]

> 
> AHHH!! That completely slipped my mind.  I'm so sorry.
> 

No problem.  It happens.
Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets

[Myles Watson]

> Author: jcrouse
> Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008)
> New Revision: 3046
> 
> Modified:
>trunk/LinuxBIOSv2/targets/buildtarget
> Log:
> Add the ability to extend CFLAGS as needed for several new distros
> Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
> Acked-by: Peter Stuge <[EMAIL PROTECTED]>
> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
> 
> 
> 
> Modified: trunk/LinuxBIOSv2/targets/buildtarget
> ===
> --- trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 00:32:07 UTC (rev
> 3045)
> +++ trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 18:23:47 UTC (rev
> 3046)
> @@ -53,4 +53,25 @@
>  export PYTHONPATH=$config_dir
>  $PYTHON $config_py $config_lb $lbpath
> 
> +# now start checking for distro-specific breakage.
> +## This check is for the no stack protector mess.
> +EXTRA_CFLAGS=
> +
> +if [ -z "$CC" ]; then
> +   CC=gcc
> +fi
> +
> +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp
> +
> +if [ $? -eq 0 ]; then
> +   EXTRA_CFLAGS=-fno-stack-protector
> +fi

This adds the flag for me, even though I didn't need it.  Was that intended?

Myles

> +
> +rm -rf .$$.tmp
> +
> +for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings
> +do
> + echo CFLAGS+=$EXTRA_CFLAGS >>$i
> +done
> +
>  exit $?
> 
> 
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] r90 - in buildrom-devel: . config/platformspackages/linuxbios packages/linuxbios/conf.v3

[Myles Watson]

> 
> Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
> 

The rest is in r91.
Thanks,
Myles


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] LinuxBIOSv3 Config files

[Myles Watson]

> On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote:
> > it really should be a feature that kconfig offers.
> 
> It's make defconfig in Linux.
> 

Make defconfig ignores your .config file.  What I wanted was something
similar to make allyesconfig, which chooses yes for anything you didn't
specify.  Maybe make alldefconfig?

Myles

> //Peter




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets

[Myles Watson]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxbios-
> [EMAIL PROTECTED] On Behalf Of Ward Vandewege
> Sent: Thursday, January 10, 2008 4:19 PM
> To: linuxbios@linuxbios.org
> Subject: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-
> config,uclibc-config targets
> 
> 

Sorry to be so dense, but it looks like you added mkdir -p in a lot of
places for directories, even though there are already makefile rules for
them.  

The config stuff looks fine, though.

Myles

> 
> --
> Ward Vandewege <[EMAIL PROTECTED]>
> Free Software Foundation - Senior System Administrator



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] LinuxBIOSv3 Config files

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 10, 2008 12:18 PM
> To: ron minnich
> Cc: Myles Watson; Linuxbios
> Subject: Re: LinuxBIOSv3 Config files
> 
> On 10/01/08 11:03 -0800, ron minnich wrote:
> > On Jan 10, 2008 10:29 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> > >
> > > On 10/01/08 10:19 -0800, ron minnich wrote:
> > > > On Jan 9, 2008 1:56 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > make oldconfig < newlines.txt
> > > >
> > > > yes y | make oldconfig
> > >
> > > Dangerous - not all defaults are 'y'.
> > >
> >
> > sure, but it's at least as safe as newlines.txt
> 
> His goal was to get the defaults - newlines.txt will do that.  Your option
> may turn very undesirable options - saying 'y' to "experimental" is not
> always the best way.
> 
> I am on record as forcing the buildrom developer to generate and maintain
> a complete configuration file - I think it supports more reproducible
> builds
> and eliminates doubt and confusion.  That I said, I understand what Myles
> is trying to do, and it really should be a feature that kconfig offers.
> 

This brings us back to the reason we started this conversation.  I think
it's too bad to force the ROM_size argument from a config file.  Having a
different config file for each architecture * rom_size * console_option *
boot_Device means that no one will implement/maintain them.

I think it would be nice to allow people (maybe only with "Advanced Options"
selected) to configure v3 (at least specify the ROM size and the
architecture) from buildrom.  I think the easier we make it to try out
different things, the more people will try things and help us improve.

We can also do checks to see if payloads will fit from buildrom if we have
some idea about the ROM size.

Myles

> Jordan
> 
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] LinuxBIOSv3 Config files

[Myles Watson]

> -Original Message-
> From: ron minnich [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 10, 2008 12:04 PM
> To: Jordan Crouse
> Cc: Myles Watson; Linuxbios
> Subject: Re: LinuxBIOSv3 Config files
> 
> On Jan 10, 2008 10:29 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> >
> > On 10/01/08 10:19 -0800, ron minnich wrote:
> > > On Jan 9, 2008 1:56 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > >
> > > > make oldconfig < newlines.txt
> > >
> > > yes y | make oldconfig
> >
> > Dangerous - not all defaults are 'y'.
> >
> 
> sure, but it's at least as safe as newlines.txt
> 
> ron

The reason I used new lines was that it selected the defaults.  For example,
for numerical choices 'y' is not a good choice and sends it into an infinite
loop.

I'll grant that new lines are only as safe as the default values.

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND)

[Myles Watson]

On Jan 3, 2008 10:30 AM, ron minnich <[EMAIL PROTECTED]> wrote:
> On Jan 3, 2008 9:12 AM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> > * ron minnich <[EMAIL PROTECTED]> [080103 17:25]:
> > > This patch will enable setting distro variables such as
> > > -fno_stack_protector as needed. It is a simple patch to  buildtarget
> > > and can be extended for other uses.
> > >
> > > If this patch is acceptable then we can fix the various makefiles to
> > > include the variable.
> > >
> > > The only remaining question is the name -- is CPU_OPT really appropriate?
> >
> > Why not make it CFLAGS? The C compiler is called CC in our environment,
> > too.
>
>
> like this?
>
> Tested on FC8 and works fine.

This patch adds -fno-stack-protector to my FLAGS too, even though I
don't need them.  It still builds, with or without the patch.

Myles

> ron
>
> --

> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND)

[Myles Watson]

On Jan 3, 2008 10:30 AM, ron minnich <[EMAIL PROTECTED]> wrote:
> On Jan 3, 2008 9:12 AM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> > * ron minnich <[EMAIL PROTECTED]> [080103 17:25]:
> > > This patch will enable setting distro variables such as
> > > -fno_stack_protector as needed. It is a simple patch to  buildtarget
> > > and can be extended for other uses.
> > >
> > > If this patch is acceptable then we can fix the various makefiles to
> > > include the variable.
> > >
> > > The only remaining question is the name -- is CPU_OPT really appropriate?
> >
> > Why not make it CFLAGS? The C compiler is called CC in our environment,
> > too.
>
>
> like this?
>
> Tested on FC8 and works fine.

This patch adds -fno-stack-protector to my FLAGS too, even though I
don't need them.  It still builds, with or without the patch.

Myles

> ron
>
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] PCI device memory resource

[Myles Watson]

I think the confusion comes because of the difference between memory and
memory address space.  The PCI controller is asking for 32 MB of the
physical address space, not memory.  When the BIOS allocates this region in
the address space, it is trusting that the PCI controller will respond to
any reads/writes to that address space.

 

There is no need to have actual RAM backing up every bit of address space,
but the device needs to respond to accesses to its address space.

 

Myles

 

 

  _  

From: Baski [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 10, 2008 8:14 AM
To: [EMAIL PROTECTED]; linuxbios@linuxbios.org
Subject: RE: [LinuxBIOS] PCI device memory resource

 

Pardon my bad phrasing of the original question.  I have a mem-mapped PCI
controller which has no on-board memory, but is asking for 32MB memory
resource.  Is this legal?  While BIOS gives it 32MB address space, who is
going to malloc and give it the required memory to work with?
Thanks - Baski
Myles Watson <[EMAIL PROTECTED]> wrote:

I'm guessing that you're asking if it has to have as much memory as the
resource.  If that's the case, the answer is no.  You just have to respond
to any request in that region.

 

In other words, you could request a 1 GB region and only respond with useful
data in the first 1 MB (respond to any other read with zeros), or map the 1
MB 1024 times into the 1 GB, or anything else you decide.

 

Sorry if I totally missed the intent of your question,

Myles

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baski
Sent: Wednesday, January 09, 2008 7:06 PM
To: linuxbios@linuxbios.org
Subject: [LinuxBIOS] PCI device memory resource

 

For a PCI device to request memory resource of ,say 1MB, should it have
onboard
memory of 1MB ?
TIA 


--
People wielding power and authority always desire to destroy the sources
which gave them that power. Or, is it the other way round?

  

  _  

Never miss a thing. Make Yahoo
<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>  your homepage.





--
People wielding power and authority always desire to destroy the sources
which gave them that power. Or, is it the other way round?

  

  _  

Never miss a thing. Make Yahoo
<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>  your homepage.


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] PCI device memory resource

[Myles Watson]

I'm guessing that you're asking if it has to have as much memory as the
resource.  If that's the case, the answer is no.  You just have to respond
to any request in that region.

 

In other words, you could request a 1 GB region and only respond with useful
data in the first 1 MB (respond to any other read with zeros), or map the 1
MB 1024 times into the 1 GB, or anything else you decide.

 

Sorry if I totally missed the intent of your question,

Myles

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Baski
Sent: Wednesday, January 09, 2008 7:06 PM
To: linuxbios@linuxbios.org
Subject: [LinuxBIOS] PCI device memory resource

 

For a PCI device to request memory resource of ,say 1MB, should it have
onboard
memory of 1MB ?
TIA 


--
People wielding power and authority always desire to destroy the sources
which gave them that power. Or, is it the other way round?

  

  _  

Never miss a thing. Make Yahoo
  your homepage.


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Expand linuxbiosv3 support

[Myles Watson]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myles
> Watson
> Sent: Tuesday, January 08, 2008 2:21 PM
> To: Jordan Crouse; Linuxbios
> Subject: Re: Expand linuxbiosv3 support
> 
> This patch is Jordan's buildrom patch with a few additions, so I'm
> including
> his original message:
> 
> [BUILDROM] Expand linuxbiosv3 support
> 
> Add more generic support for LinuxBIOSv3 - add specialized package
> for v3, and add support for using LAR to put it all together.  Also
> add expanded (and better) option ROM support, though we're not actually
> using it right away.
> 
> Myles again:
> 
> It also changes LINUXBIOS variables to LBV2 unless they are used for both.
> I
> added dependencies between vendors that don't have any v3 platforms and
> LINUXBIOS_V2.
> 

I accidentally changed one instance of LINUXBIOS_ROM_NAME to LBV2_ROM_NAME,
which broke the v2 build. It's in linuxbios.inc.  I've fixed it in my tree
but decided to spare you another large patch for one tiny change.

Myles

> One of the changes Jordan made was to always build v3 with no payload
> and then add it later with any binary blobs that might be needed.
> This way you can change them without rebuilding v3.
> 
> Signed-off-by: Myles Watson <[EMAIL PROTECTED]>



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] LinuxBIOSv3 Config files

[Myles Watson]

On Jan 8, 2008 4:38 PM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> On 08/01/08 16:30 -0700, Myles Watson wrote:
> > In buildrom, I want to be able to set the variables I care about, then
> > use make oldconfig to choose the (hopefully) sane defaults for the
> > rest of the options.
>
> That would make sense, but I'm not sure if there is a way to make kconfig
> do that.  At least, in my experience, we've always needed to the user
> to build the entire .config, to avoid oldconfig asking questions.
>
> But there might be a conf option that can avoid that.

The only way I can find isn't as clean as I would like.

make oldconfig < newlines.txt

newlines.txt makes it choose the defaults by "hitting enter"

It may be worth it because it would allow us to generate .config files
instead of having to have one for every architecture.

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] LinuxBIOSv3 Config files

[Myles Watson]

In buildrom, I want to be able to set the variables I care about, then
use make oldconfig to choose the (hopefully) sane defaults for the
rest of the options.

Here is a sample .config file that I'd like to use:

--Begin .config 
#
# General setup
#
CONFIG_LOCALVERSION="-buildrom"

#
# Mainboard
#
CONFIG_VENDOR_EMULATION=y
CONFIG_MAINBOARD_NAME="emulation/qemu-x86"
CONFIG_BOARD_EMULATION_QEMU_X86=y
CONFIG_LINUXBIOS_ROMSIZE_KB_1024=y
CONFIG_ARCH_X86=y
CONFIG_ARCH="x86"

#
# Devices
#
CONFIG_PCI_OPTION_ROM_RUN=y

#
# Payload
#
CONFIG_PAYLOAD_NONE=y
--End .config 

Unfortunately, I get this warning and it requires me to hit enter on
every line (suboptimal for an automated build script.)  The defaults
are what I want, though.

Kconfig:102:warning: defaults for choice values not supported

Is there a reason why we don't let people use the defaults?

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised...

[Myles Watson]

On Jan 8, 2008 3:41 PM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> So what is the general consensus ==1 or >0?

I like the idea of using grep.  It seems much cleaner, and avoids that issue.

The other sticking point for the patch the changes in
src/arch/i386/lib/id.lds (See Ed's last message.)

Myles

> Also,  I think I know how to commit back to the tree,  but do I need a
> user account for this?
>
> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
>
>
>
>
> Myles Watson wrote:
> > On Jan 7, 2008 8:15 AM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >
> >> After looking at the script Myles sent, I immediately saw the problem.
> >> I forgot that if  [ $build_id ] will always be true because it checks to
> >> see if it is defined not the value of build_id.  My bad, sorry.
> >>
> >> I have made the changes and added an == 1 to the if statement.  Attached
> >> is the new and I hope final patch file for this.
> >>
> >>
> > It works for me (it doesn't add the load option.)
> >
> > Sorry to be picky, but it seems like this breaks if they mention
> > build-id more than once in the help in the future.  I think >0 would
> > be better than ==1.
> >
> > With that fixed, or if no one thinks that will ever happen:
> > Acked-by: Myles Watson <[EMAIL PROTECTED]>
> >
> >> /*
> >> Marc Karasek
> >> MTS
> >> Sun Microsystems
> >> mailto:[EMAIL PROTECTED]
> >> ph:770.360.6415
> >> */
> >>
> >>
> >>
> >> Ed Swierk wrote:
> >>
> >>
> >>> On 1/4/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> I made a test script and ran it and it sets build_id = 1 properly.  I
> >>>> have also included this script.
> >>>>
> >>>>
> >>> The problem is that on Planet Bourne, zero means true and nonzero means 
> >>> false.
> >>>
> >>> --Ed
> >>>
> >>>
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] AMD SimNOW question

[Myles Watson]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 08, 2008 3:02 PM
> To: Myles Watson
> Cc: LinuxBIOS
> Subject: Re: [LinuxBIOS] AMD SimNOW question
> 
> You are right.  I saw that it needed the files under svn/.  So I moved
> the files into this directory under sources.  This was from the svn co I
> did for version 2950.Could I use the tip of the tree for this or is
> it better to use version 2950?
> 
> Now it needs the patch for the compile problems, ld, etc..  for Fedora 8.
> 
> Progress no matter how slow is progress,  I guess.. :-
> )
> 

You can use the head of the tree.  Buildrom is supposed to be a stable
version, so a working version is always specified for v2.

Good luck,
Myles

> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
> 
> 
> 
> Myles Watson wrote:
> > On Jan 8, 2008 12:09 PM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >
> >> I am trying to get LinuxBIOS and AMD SimNOW working.
> >>
> >> I tried to follow the how-to and have run into a brick wall.
> >>
> >> It gets to the point of compiling linuxbios.  Originally it could not
> >> find the file linuxbios-svn-2950.tar.gz file under sources and was
> >> failing.  I then got this revision via svn and created this file.  I
> put
> >> it in the sources directory, now the patch file for linuxbios is
> failing.
> >>
> >
> > Here's my guess: When you got the revision and made the tarball, your
> > directory structure ended up wrong so the patch won't apply.  When you
> > check it out from svn you get a LinuxBIOSv2/* and you need a svn/*
> >
> > If that doesn't help, I don't have enough information to help you.
> > Are you building for fam10 or the original Serengeti_cheetah?  Which
> > payload are you using?  What patch is failing?  What's the error
> > message?
> >
> > I just built LAB payloads for both versions of Serengeti Cheetah, and
> > they worked for me.
> >
> > Myles
> >
> >
> >> It took me a lot work to get to this point as I have been having proxy
> >> server problems.  The machine I am building/testing with is in a lab
> and
> >> is behind the proxy.
> >>
> >> I am pretty close to getting this compiled.  I already have a system
> >> setup with SimNOW (NDA version).  Any help would be appreciated...
> >>
> >>
> >> --
> >> /*
> >> Marc Karasek
> >> MTS
> >> Sun Microsystems
> >> mailto:[EMAIL PROTECTED]
> >> ph:770.360.6415
> >> */
> >>
> >>
> >> --
> >> linuxbios mailing list
> >> linuxbios@linuxbios.org
> >> http://www.linuxbios.org/mailman/listinfo/linuxbios
> >>
> >>



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] AMD SimNOW question

[Myles Watson]

On Jan 8, 2008 12:09 PM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> I am trying to get LinuxBIOS and AMD SimNOW working.
>
> I tried to follow the how-to and have run into a brick wall.
>
> It gets to the point of compiling linuxbios.  Originally it could not
> find the file linuxbios-svn-2950.tar.gz file under sources and was
> failing.  I then got this revision via svn and created this file.  I put
> it in the sources directory, now the patch file for linuxbios is failing.

Here's my guess: When you got the revision and made the tarball, your
directory structure ended up wrong so the patch won't apply.  When you
check it out from svn you get a LinuxBIOSv2/* and you need a svn/*

If that doesn't help, I don't have enough information to help you.
Are you building for fam10 or the original Serengeti_cheetah?  Which
payload are you using?  What patch is failing?  What's the error
message?

I just built LAB payloads for both versions of Serengeti Cheetah, and
they worked for me.

Myles

> It took me a lot work to get to this point as I have been having proxy
> server problems.  The machine I am building/testing with is in a lab and
> is behind the proxy.
>
> I am pretty close to getting this compiled.  I already have a system
> setup with SimNOW (NDA version).  Any help would be appreciated...
>
>
> --
> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
>
>
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised...

[Myles Watson]

On Jan 7, 2008 8:15 AM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> After looking at the script Myles sent, I immediately saw the problem.
> I forgot that if  [ $build_id ] will always be true because it checks to
> see if it is defined not the value of build_id.  My bad, sorry.
>
> I have made the changes and added an == 1 to the if statement.  Attached
> is the new and I hope final patch file for this.
>
It works for me (it doesn't add the load option.)

Sorry to be picky, but it seems like this breaks if they mention
build-id more than once in the help in the future.  I think >0 would
be better than ==1.

With that fixed, or if no one thinks that will ever happen:
Acked-by: Myles Watson <[EMAIL PROTECTED]>
>
> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
>
>
>
> Ed Swierk wrote:
>
> > On 1/4/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >
> >> I made a test script and ran it and it sets build_id = 1 properly.  I
> >> have also included this script.
> >>
> >
> > The problem is that on Planet Bourne, zero means true and nonzero means 
> > false.
> >
> > --Ed
> >
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised...

[Myles Watson]

It doesn't work for me.  It says build-id is supported, and it's not.

The script I attached works for me, though.

Myles

On Jan 4, 2008 3:48 PM, Marc Karasek <[EMAIL PROTECTED]> wrote:
> Sorry about the patch, I had to edit it out for some other changes that
> got pulled into the file and accidentally deleted a line that should
> have been there.  This patch should be better.
>
> And I also did a svn diff one level up in the tree (flags.patch)
>
> I made a test script and ran it and it sets build_id = 1 properly.  I
> have also included this script.
>
> /*
> Marc Karasek
> MTS
> Sun Microsystems
> mailto:[EMAIL PROTECTED]
> ph:770.360.6415
> */
>
>
>
> Ed Swierk wrote:
>
> > On 1/4/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> >
> >> Ed sorry for the duplicate, but I only originally replied to you.
> >>
> >> I will take a look at it.   When I ran it it did add the option on my
> >> system.   The only question I had was for an older ld version would it
> >> behave properly.
> >>
> >
> > Try running this snippet from buildtarget in a shell and you'll see what I 
> > mean:
> >
> > ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END
> > {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [
> > $build_id \
> > ]; then echo 'yes'; else echo 'no'; fi
> >
> >
> >> I did the patch using svn diff from the tree.  Is there another way to
> >> generate it?
> >>
> >
> > Not sure...
> >
> > --Ed
> >
>
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>
ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}'
build_id=$?
echo $build_id
echo -n 'ld supports --build-id?' 
echo $build_id
if [ $build_id == 0 ]; then 
	echo ' no'
else 
	echo ' yes'
fi
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised...

[Myles Watson]

> I did the patch using svn diff from the tree.  Is there another way to
> generate it?

If you have just the changes you want to include in the tree, you can go one
level up and do 

svn diff LinuxBIOSv2

This makes it easier for me.  Then I use the -p1 option to patch and it
finds the files correctly.

It looks like you did 

svn diff file1 >diff1
svn diff file2 >diff2
svn diff file3 >diff3

And then put the resulting files together.  Because a line got deleted from
the end of the src/config/Config.lb diff, it complains about a malformed
patch and doesn't do the next two.

Then again, maybe that line disappeared another way.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] flashrom on the host or target ?

[Myles Watson]

On Jan 1, 2008 1:24 PM, Phani Babu Giddi <[EMAIL PROTECTED]> wrote:
> Hi Corey,
>
> Is there a way by which I can use the external programmer to flash the
> complete chip at once. I mean There is the Linux BIOS image which includes
> the kernel and then there is the root file system and a fall back image. So
> that I can have a single file which I can generate and distribute.
>
> Have this been done before ?

It sounds like your problem is not how to flash the BIOS, but how to
generate a single image including LinuxBIOS, the filesystem, and the
kernel.

If this is your question, then you should look at a LAB (Linux As
Bootloader) implementation.  It puts everything in a single ROM image.
 The easiest way to do this is to get buildrom and follow one of the
configurations for LAB.  You need to have at least a 1MB chip to fit
LinuxBIOS and a kernel.  With a 2MB chip you wouldn't have to strip it
down so much.

Good luck,
Myles

> Regards,
> Phani
>
>
>
> On Jan 1, 2008 9:32 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
>
> >
> > Phani Babu Giddi wrote:
> > > Hi Corey,
> > >
> > > Thanks for your reply but I am not clear. Let me list the steps, may
> > > be that will explain the problem I see.
> > >
> > > 1. I have a host target environment
> > > 2. I build Linux Kernel image with initrd on the host
> > > 3. I also build the root file system on the host
> > > 4. Now I build Linux BIOS and specify the Linux Kernel as payload.
> > > 5. So at this point I have the .bin/.rom for Linux BIOS and an image
> > > file for the root file system.
> > > 6. So my question was how do I get this on the flash device. Do I have
> > > to use an external programmer for this ? Because there is nothing on
> > > the target for me to run flashrom.
> >
> > Yep, you can use an external programmer, or you can use some other board
> > that's compatible with flashrom and your flash chip, by hot swapping the
> > flash chips.
> >
> > -Corey
> >
>
>
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the Cheetah FAM10 target to buildrom

[Myles Watson]

> Can you check this in to buildrom svn? Jordan is driving across Wyoming
> today (lovely weather) and I don't have buildrom access.

I don't envy him.  It's been icy here.

> Thanks,
> Marc
> 
Revision 89

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] VGA help under QEMU

[Myles Watson]

On Dec 13, 2007 3:01 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> my apologies, it was a big going-away lunch and I am now sleepy.
>
> I just did a build with latest v3, built a 256kb bios, copy it to a
> directory, run qemu as follows:
> qemu -serial stdio -L . -kernel linux-2.6.15-bochs/vmlinux -hdc hda -hda hda
>
> and I get video.
>
> I am using the vgabios-cirrus.bin
>
> Option ROMS are run in Phase 6.
> Mine looks like this:
>
> Phase 6: Initializing devices...
> Phase 6: Root Device init.
> Phase 6: PCI: 00:00.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> Phase 6: PCI: 00:01.0 init.
> Initializing realtime clock.
> RTC: Checksum invalid zeroing cmos
> Invalid LinuxBIOS CMOS checksum.
> Phase 6: PCI: 00:01.1 init.
> Enabling IDE channel 1
> Enabling IDE channel 2
> Enabling Legacy IDE
> Phase 6: PCI: 00:01.3 init.
> Enabling SMBus.
> Enable Power Management Functions
> Phase 6: PCI: 00:02.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> ROM address for PCI: 00:02.0 = c
> PCI Expansion ROM, signature 0xaa55, INIT size 0x8c00, data ptr 0x0038
> PCI ROM Image, Vendor 1013, Device 00b8,
> PCI ROM Image, Class Code 03, Code Type 00
> Copying VGA ROM image from 0x000c to 0xc, 0x8c00 bytes
> Phase 6: PCI: 00:03.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> Phase 6: PCI: 00:04.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> Phase 6: Devices initialized.
>
>
> When I look at yours I see an error:
> Phase 6: PCI: 00:02.0 init.
>
> PCI: pci_dev_init
>
> Probing for option ROM
>
> ROM address for PCI: 00:02.0 = c
>
> PCI Expansion ROM, signature 0xaa55, INIT size 0x8a00, data ptr 0x736f
>
> PCI ROM Image, Vendor 0846, Device ec89,
>
> Device or Vendor ID mismatch Vendor 0846, Device ec89
>
>
> see the mismatch? So it will not run the rom. The option rom does not
> match the hardware .
>
> What vga bios are you using? I hope to wake up more soon and might
> actually give a useful answer :-)
>
> ron

I looked at it some more, and it looks like it is messed up before it
gets to the Vendor.

> PCI Expansion ROM, signature 0xaa55, INIT size 0x8a00, data ptr 0x736f

The size is wrong, and the data ptr looks questionable.  Since v2
finds the ROM in the right place I'm leaning toward it being a problem
with the compiler I'm using to build v3, or v3.

I'm using gcc version 4.1.2 20070626 (Red Hat 4.1.2-13) for x86_64 if
that makes a difference.

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Long delay between messages.

[Myles Watson]

> 
> I'm seeing delays between each of the following messages --
> approximately 8 seconds. Is this normal?

Not for me on Tyan s2895 (Dual Opteron NVidia CK804.)

Myles

> core0 started:  01
> *01*0001
> *02*0001
> *03*0001
> 
> This is a dual opteron system.
> 
> Thanks,
> 
> Steve
> 
> 
> --
> linuxbios mailing list
> linuxbios@linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the Cheetah FAM10 target to buildrom

[Myles Watson]

> Myles Watson wrote:
> >> Myles Watson wrote:
> >>
> >>> On Dec 20, 2007 12:15 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> >>>
> >>
> >> Ah! missed the LAB stuff, sorry.  I will make those changes.
> >> Is the serengeti_cheetah_fam10-payload.patch really needed? It cleans
> up
> >> the config.lb a little but I don't see a functional difference.
> >>
> >
> >
> > You're right.  It's only clean-up.  That may be true for the
> > Serengeti_cheetah-payload.patch as well.
> >
> > Myles
> OK, I removed added lab but not the payload patch for fam10.
> 
> Marc

Acked-by: Myles Watson <[EMAIL PROTECTED]>



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the Cheetah FAM10 target to buildrom

[Myles Watson]

> Myles Watson wrote:
> > On Dec 20, 2007 12:15 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> >
> >> Myles Watson wrote:
> >>
> >>>> Hey all - following on Marc's awesome Barcelona patches, here is the
> >>>> code to add the fam10 target to buildrom.
> >>>>
> >>>>
> >>> It works for me, but since you used the generic.mk instead of a
> specific
> >>> one, it didn't catch that I didn't have iasl installed.
> >>>
> >>> That said, it seems like it would be nicer to have a FAMILY_10 option
> and
> >>> just take care of the three variables that change in
> Serengeti_cheetah.conf.
> >>> That way you get 64-bit support and the iasl check for free.
> >>>
> >>> If you still want to keep it separate, I'd like the name to be
> >>> Serengeti_cheetah_fam_10.conf instead of cheetah_fam_10.conf, so it's
> easy
> >>> to see what it is.
> >>>
> >>> Myles
> >>>
> >>>
> >>>
> >>>
> >>>
> >> Myles,
> >>
> >> I agree using the same serengeti_cheetah.conf is better so here is my
> >> attempt..
> >>
> >> Marc
> >>
> >
> > It works for me with the attached patch, which patches the fam10
> > Config.lb instead of the serengeti_cheetah/Config.lb for changing the
> > payload.
> >
> > If you add this, or something that is cleaner I'll test and ack it.
> >
> > Myles
> >
> Ah! missed the LAB stuff, sorry.  I will make those changes.
> Is the serengeti_cheetah_fam10-payload.patch really needed? It cleans up
> the config.lb a little but I don't see a functional difference.


You're right.  It's only clean-up.  That may be true for the
Serengeti_cheetah-payload.patch as well.

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the Cheetah FAM10 target to buildrom

[Myles Watson]

On Dec 20, 2007 12:15 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> Myles Watson wrote:
> >> Hey all - following on Marc's awesome Barcelona patches, here is the
> >> code to add the fam10 target to buildrom.
> >>
> >
> > It works for me, but since you used the generic.mk instead of a specific
> > one, it didn't catch that I didn't have iasl installed.
> >
> > That said, it seems like it would be nicer to have a FAMILY_10 option and
> > just take care of the three variables that change in Serengeti_cheetah.conf.
> > That way you get 64-bit support and the iasl check for free.
> >
> > If you still want to keep it separate, I'd like the name to be
> > Serengeti_cheetah_fam_10.conf instead of cheetah_fam_10.conf, so it's easy
> > to see what it is.
> >
> > Myles
> >
> >
> >
> >
> Myles,
>
> I agree using the same serengeti_cheetah.conf is better so here is my
> attempt..
>
> Marc

It works for me with the attached patch, which patches the fam10
Config.lb instead of the serengeti_cheetah/Config.lb for changing the
payload.

If you add this, or something that is cleaner I'll test and ack it.

Myles
Index: packages/linuxbios/serengeti_cheetah.mk
===
--- packages/linuxbios/serengeti_cheetah.mk	(revision 88)
+++ packages/linuxbios/serengeti_cheetah.mk	(working copy)
@@ -16,7 +16,16 @@
 endif
 
 
+ifeq ($(CONFIG_PLATFORM_CHEETAH_FAM10),y)
 ifeq ($(CONFIG_PAYLOAD_LAB),y)
+	LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah_fam10-lab.patch
+else
+	LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah_fam10-payload.patch
+endif
+endif
+
+ifeq ($(CONFIG_PLATFORM_SERENGETI_CHEETAH),y)
+ifeq ($(CONFIG_PAYLOAD_LAB),y)
 	LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah-lab.patch
 else
 	LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah-payload.patch
@@ -25,6 +34,7 @@
 ifeq ($(CONFIG_SIMNOW),y)
 LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/simnow.patch
 endif
+endif
 
 LINUXBIOS_BASE_DIR=svn
 LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2
Index: packages/linuxbios/patches/serengeti_cheetah_fam10-lab.patch
===
--- packages/linuxbios/patches/serengeti_cheetah_fam10-lab.patch	(revision 0)
+++ packages/linuxbios/patches/serengeti_cheetah_fam10-lab.patch	(revision 0)
@@ -0,0 +1,45 @@
+Index: svn/targets/amd/serengeti_cheetah_fam10/Config.lb
+===
+--- svn/targets/amd/serengeti_cheetah_fam10/Config.lb	(revision 3018)
 svn/targets/amd/serengeti_cheetah_fam10/Config.lb	(working copy)
+@@ -29,29 +29,14 @@
+ # At a maximum only compile in this level of debugging
+ 	option  MAXIMUM_CONSOLE_LOGLEVEL=11
+ 
+-# 512KB ROM
+-option ROM_SIZE=512*1024
++# 1024KB ROM
++option ROM_SIZE=1024*1024
++option FALLBACK_SIZE=ROM_SIZE-FAILOVER_SIZE
+ 
+-# Cheetah Family 10
+-#romimage "normal"
+-#	1MB ROM
+-#	option ROM_SIZE = 0x10
+-#	option USE_FAILOVER_IMAGE=0
+-#	option USE_FALLBACK_IMAGE=0
+-#	option ROM_IMAGE_SIZE=0x2
+-#	option ROM_IMAGE_SIZE=0x3
+-#	option XIP_ROM_SIZE=0x4
+-#	option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal"
+-#	payload ../payload.elf
+-#end
+-
+ romimage "fallback"
+ 	option USE_FAILOVER_IMAGE=0
+ 	option USE_FALLBACK_IMAGE=1
+-#	option ROM_IMAGE_SIZE=0x13800
+-#	option ROM_IMAGE_SIZE=0x19800
+-	option ROM_IMAGE_SIZE=0x3f000
+-#	option ROM_IMAGE_SIZE=0x15800
++	option ROM_IMAGE_SIZE=0x3
+ 	option XIP_ROM_SIZE=0x4
+ 	option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback"
+ 	payload ../payload.elf
+@@ -65,6 +50,5 @@
+ 	option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover"
+ end
+ 
+-#buildrom ./amd-cheetah-fam10.rom ROM_SIZE "normal" "fallback" "failover"
+ buildrom ./amd-cheetah-fam10.rom ROM_SIZE "fallback" "failover"
+ 
Index: packages/linuxbios/patches/serengeti_cheetah_fam10-payload.patch
===
--- packages/linuxbios/patches/serengeti_cheetah_fam10-payload.patch	(revision 0)
+++ packages/linuxbios/patches/serengeti_cheetah_fam10-payload.patch	(revision 0)
@@ -0,0 +1,38 @@
+Index: svn/targets/amd/serengeti_cheetah_fam10/Config.lb
+===
+--- svn/targets/amd/serengeti_cheetah_fam10/Config.lb	(revision 3018)
 svn/targets/amd/serengeti_cheetah_fam10/Config.lb	(working copy)
+@@ -32,26 +32,10 @@
+ # 512KB ROM
+ option ROM_SIZE=512*1024
+ 
+-# Cheetah Family 10
+-#romimage "normal"
+-#	1MB ROM
+-#	option ROM_SIZE = 0x10
+-#	opt

Re: [LinuxBIOS] Broken build for kexec-boot-loader inbuildrom x86_64?

[Myles Watson]

> Acked-by: Andreas Mundt 

> > > > > The attached patch fixes the build for me.  I've included it
> > > > > separately (cross_compile.patch), and as a patch to buildrom
> > > > > (kbl_compile.patch).
> > > > >
> > > > > It looks like a case where make was too smart, so it used the
> > > > > assembler for the .S files, and the build environment hadn't
> > > > > overwritten the assembler flags.
> > > > >
> > > > > Myles
> > > > >
> > > > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

Revision 86
Thanks,
Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Broken build for kexec-boot-loader inbuildrom x86_64?

[Myles Watson]

> On Thu, Dec 13, 2007 at 08:56:22AM -0700, Myles Watson wrote:
> > Did the patch work for anyone else?  Any concerns?
> >
> 
> Hi Myles,
> 
> sorry for my late answer, I was away for a few days. Your patch works
> for me (GA_M57SLI_S4, 32BIT-LAB, debian lenny amd64).
> 
> Thanks!
> 
>   Andi

If you give me an "Acked-by:" line I'll commit it.

Myles 

> > > The attached patch fixes the build for me.  I've included it
> > > separately (cross_compile.patch), and as a patch to buildrom
> > > (kbl_compile.patch).
> > >
> > > It looks like a case where make was too smart, so it used the
> > > assembler for the .S files, and the build environment hadn't
> > > overwritten the assembler flags.
> > >
> > > Myles
> > >
> > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]>




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the Cheetah FAM10 target tobuildrom

[Myles Watson]

> 
> Hey all - following on Marc's awesome Barcelona patches, here is the
> code to add the fam10 target to buildrom.

It works for me, but since you used the generic.mk instead of a specific
one, it didn't catch that I didn't have iasl installed.
 
That said, it seems like it would be nicer to have a FAMILY_10 option and
just take care of the three variables that change in Serengeti_cheetah.conf.
That way you get 64-bit support and the iasl check for free.

If you still want to keep it separate, I'd like the name to be
Serengeti_cheetah_fam_10.conf instead of cheetah_fam_10.conf, so it's easy
to see what it is.

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Tyan S2891 LinuxBios VGA ROM Question.

[Myles Watson]

>Now after I try to flashrom the "tyan-s2891.rom" file, I get a size
>mismatch because the rom built is only 988K and I have a 1024K rom. Is it
>necessary that I concatenate a 36K VGA rom? If not, how to I get buildrom
>to build a 1024K rom rather than a 988K rom?

Change the size with the ROM_SIZE variable in Config.lb

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] AMD Barcelona(family 10) support 2 of 4

[Myles Watson]

> AMD 8111 southbridge adjustments for Barcelona.
> Marc

Still works for Serengeti_cheetah.  I can't test the Barcelona hardware, but
it compiles.

Myles

Acked-by: Myles Watson <[EMAIL PROTECTED]> 



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] AMD Barcelona(family 10) support 1 of 4 repost

[Myles Watson]

Index: LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc
===
...
+   movl%edx, %eax
+   wrmsr
movl$0x269, %ecx
wrmsr

Extra tab before wrmsr

+#if CAR_FAM10 == 1
+#define CacheSizeAPStack 0x400 /* 1K */
+//#define CacheSizeAPStack 0x200 /* 512 */
+#endif

A comment of when you might want to switch to 512 would be nice, or just
remove the 512.


I don't have the hardware to test with Barcelona, but the patch doesn't
change the functionality of the base code (except for adding some POST
codes).

Thanks for separating the patches, it made it a lot easier to see the
changes.

Myles

Acked-by: Myles Watson <[EMAIL PROTECTED]>

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxbios-
> [EMAIL PROTECTED] On Behalf Of Marc Jones
> Sent: Thursday, December 13, 2007 6:32 PM
> To: LinuxBIOS Mailing List
> Subject: Re: [LinuxBIOS] [PATCH] AMD Barcelona(family 10) support 1 of 4
> repost
> 
> 
> 
> Marc Jones wrote:
> > Here is the initial patches for AMD Barcelona support! These patches
> > provide support for the Barcelona revision Bx. There is still a lot of
> > work to do as you will see in the FIXME comments. Please focus most
> > attention on the few places where changes were made to preexisting
> > files. I understand that these patches are large and will take some time
> > to get through. My hope is that they are accepted soon so that we can
> > continue to develop and amend the code as we find issues and support
> > more features.
> >
> > A buildrom update will follow.
> >
> > Marc
> >
> 
> I separated out the whitespace and other cleanup to a cleanup patch. I
> also removed two files that were no longer used from the patch. This
> patch is now two patches but this should make it easier to review.
> 
> For those with email issues, get the entire patch set here:
> http://linuxbios.org/~mjones/barc121307.tar.gz
> 
> Marc
> 
> 
> --
> Marc Jones
> Senior Firmware Engineer
> (970) 226-9684 Office
> mailto:[EMAIL PROTECTED]
> http://www.amd.com/embeddedprocessors



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] [PATCH] buildrom qemu patch

[Myles Watson]

This patch puts build output from qemu into log files, corrects a
reference to the compiler in the Makefile, and updates the default
compiler to be gcc34 instead of gcc32.

I'd have called it trivial except that I changed the default compiler.

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
Index: buildrom-devel/config/platforms/Config.in
===
--- buildrom-devel/config/platforms/Config.in	(revision 84)
+++ buildrom-devel/config/platforms/Config.in	(working copy)
@@ -112,15 +112,16 @@
 	default n
 	help
 	  Say 'y' here to build a patched version of QEMU to work with
-	  LinuxBIOS. This downloads the correct version and patches it
-	  it even builds it if you specify the QEMU_CC correctly.
+	  LinuxBIOS. This downloads the correct version and patches it;
+	  it even builds it if you specify the QEMU_CC correctly
 
 config QEMU_CC
 	string "Compiler to use when building QEMU"
 	depends BUILD_QEMU
-	default "gcc32"
+	default "gcc34"
 	help
-	  Set this string to point to your compiler (GCC_VER <=3.2)
+  qemu has known problems when built using gcc 4.x
+	  Set this string to point to your compiler (GCC_VER 3.x)
 
 config SIMNOW
 	bool "Build for the AMD SimNow (TM) emulator"
Index: buildrom-devel/packages/qemu/qemu.mk
===
--- buildrom-devel/packages/qemu/qemu.mk	(revision 84)
+++ buildrom-devel/packages/qemu/qemu.mk	(working copy)
@@ -32,11 +32,11 @@
 	@ touch $@
 
 $(QEMU_STAMP_DIR)/.configured: $(QEMU_STAMP_DIR)/.patched
-	@ cd $(QEMU_SRC_DIR); ./configure --cc=gcc32 --target-list=i386-softmmu
+	@ cd $(QEMU_SRC_DIR); ./configure --cc=$(CONFIG_QEMU_CC) --target-list=i386-softmmu > $(QEMU_CONFIG_LOG) 2>&1
 	@ touch $@
 
 $(QEMU_SRC_DIR)/i386-softmmu/qemu: $(QEMU_STAMP_DIR)/.configured
-	@ make -C $(QEMU_SRC_DIR) CC=$(CONFIG_QEMU_CC) CCFLAGS="" CFLAGS="" LDFLAGS=""
+	@ make -C $(QEMU_SRC_DIR) CC=$(CONFIG_QEMU_CC) CCFLAGS="" CFLAGS="" LDFLAGS="" > $(QEMU_BUILD_LOG) 2>&1
 	@ echo "the qemu executable is in $(QEMU_SRC_DIR)/i386-softmmu/"
 
 $(QEMU_STAMP_DIR) $(QEMU_LOG_DIR):
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] VGA help under QEMU

[Myles Watson]

On Dec 13, 2007 3:01 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> my apologies, it was a big going-away lunch and I am now sleepy.

No problem.

> I just did a build with latest v3, built a 256kb bios, copy it to a
> directory, run qemu as follows:
> qemu -serial stdio -L . -kernel linux-2.6.15-bochs/vmlinux -hdc hda -hda hda
>
> and I get video.
>
> I am using the vgabios-cirrus.bin

I'm not specifying the vgabios specifically, but v2 finds the vgabios-cirrus.bin

> Option ROMS are run in Phase 6.
> Mine looks like this:
>
> Phase 6: Initializing devices...
> Phase 6: Root Device init.
> Phase 6: PCI: 00:00.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> Phase 6: PCI: 00:01.0 init.
> Initializing realtime clock.
> RTC: Checksum invalid zeroing cmos
> Invalid LinuxBIOS CMOS checksum.
> Phase 6: PCI: 00:01.1 init.
> Enabling IDE channel 1
> Enabling IDE channel 2
> Enabling Legacy IDE
> Phase 6: PCI: 00:01.3 init.
> Enabling SMBus.
> Enable Power Management Functions
> Phase 6: PCI: 00:02.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> ROM address for PCI: 00:02.0 = c
> PCI Expansion ROM, signature 0xaa55, INIT size 0x8c00, data ptr 0x0038
> PCI ROM Image, Vendor 1013, Device 00b8,
> PCI ROM Image, Class Code 03, Code Type 00
> Copying VGA ROM image from 0x000c to 0xc, 0x8c00 bytes
> Phase 6: PCI: 00:03.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> Phase 6: PCI: 00:04.0 init.
> PCI: pci_dev_init
> Probing for option ROM
> Phase 6: Devices initialized.
>
>
> When I look at yours I see an error:
> Phase 6: PCI: 00:02.0 init.
>
> PCI: pci_dev_init
>
> Probing for option ROM
>
> ROM address for PCI: 00:02.0 = c
>
> PCI Expansion ROM, signature 0xaa55, INIT size 0x8a00, data ptr 0x736f
>
> PCI ROM Image, Vendor 0846, Device ec89,
>
> Device or Vendor ID mismatch Vendor 0846, Device ec89
>
>
> see the mismatch? So it will not run the rom. The option rom does not
> match the hardware .

Good catch.

> What vga bios are you using? I hope to wake up more soon and might
> actually give a useful answer :-)

I don't know where it's getting another VGA bios.  I tried removing
the other vgabios.bin file from the directory, but I get the same
results.

I looked in the pci.ids file, and the Vendor ID is not there, so I'm
not sure what the problem is.

Myles

>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] VGA help under QEMU

[Myles Watson]

On Dec 13, 2007 2:43 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> > I'm attaching the serial log of my boot.  Maybe I just don't see where
> > it's being executed and there's another problem?
> FILO version 0.5 ([EMAIL PROTECTED]) Thu Dec 13 13:53:00 MST 2007
>
> menu: hda3:/boot/filo/menu.lst
>
> It's all good to this point.

It loads FILO fine.  I'm using a blank hard drive, so I know that it
won't find what it's looking for. I just do that so it's easy to tell
where I am.  No need to boot into a complicated payload if the VGA
didn't get initialized correctly.

I was hoping you could point out where in the log it said it was
executing my VGA Bios.  I don't see that happening, even though v2
executes it and initializes the console correctly.

Thanks,
Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] VGA help under QEMU

[Myles Watson]

On Dec 13, 2007 1:50 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > I am trying to boot LinuxBIOS using qemu with VGA support.  I have got
> > both V2 & V3 to boot with a FILO payload and the linux test disk image
> > from QEMU website using the -nographic option.
> >
> > I can boot the disk image using qemu and the bios & vgabios it came with.
> >
> > I cannot get it to come up with either V2 or V3.  I have tried copying
> > the vgabios.bin image to a local directory and then booting qemu with
> > the -L ./ option.  I see the initial QEMu messages a blank screen
> > appears that looks like the VGA output and then it goes down to a small
> > block on the screen.
> >
> > I have compiled  V3 with x86emu support.  Under V2 I could not figure
> > out how to get it to compile with VGA support.
>
> Under v2 I just used the default config in buildrom and made sure that the
> ROM file from LinuxBIOS and the vgabios*.bin files were in the same
> directory.  It hangs during the boot, but not because of the VGA.  I'm
> looking into it more.
>
> For v3 I get the same thing you do.
>
> I started qemu with "-L BIOS_DIR hd.img"
>
> Myles

My v2 hang seems to be the choice of Linux kernel for LAB and a qemu bug.

I used filo as the payload for testing, a blank hard drive so nothing
loads.  Under v2 it executes the vga ROM and initializes correctly.
Under v3 it doesn't seem to execute the ROM.  I changed the default
configuration to try using MULTIPLE_VGA_INIT, and using x86emu and
vm86, but it didn't seem to make a difference.

I'm attaching the serial log of my boot.  Maybe I just don't see where
it's being executed and there's another problem?

Myles


v3ser.out
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] VGA help under QEMU

[Myles Watson]

> I am trying to boot LinuxBIOS using qemu with VGA support.  I have got
> both V2 & V3 to boot with a FILO payload and the linux test disk image
> from QEMU website using the -nographic option.
> 
> I can boot the disk image using qemu and the bios & vgabios it came with.
> 
> I cannot get it to come up with either V2 or V3.  I have tried copying
> the vgabios.bin image to a local directory and then booting qemu with
> the -L ./ option.  I see the initial QEMu messages a blank screen
> appears that looks like the VGA output and then it goes down to a small
> block on the screen.
> 
> I have compiled  V3 with x86emu support.  Under V2 I could not figure
> out how to get it to compile with VGA support.

Under v2 I just used the default config in buildrom and made sure that the
ROM file from LinuxBIOS and the vgabios*.bin files were in the same
directory.  It hangs during the boot, but not because of the VGA.  I'm
looking into it more.

For v3 I get the same thing you do.

I started qemu with "-L BIOS_DIR hd.img"

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Buildrom remove lgdt patch

[Myles Watson]

On Dec 13, 2007 10:55 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
>
> On 13/12/07 08:00 -0700, Myles Watson wrote:
> > This patch removes the option from buildrom to use the lgdt patch for
> > LinuxBIOSv3.
> >
> > On a compiler that doesn't need the patch, this patch makes the image
> > unbootable.
> >
> > Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
Thanks,
Rev 84

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] AMD Barcelona(family 10) support 1 of 4

[Myles Watson]

> Please focus most
> attention on the few places where changes were made to preexisting
> files.

>Index: LinuxBIOSv2/src/config/Options.lb
>===
>--- LinuxBIOSv2.orig/src/config/Options.lb 2007-12-12
>11:03:38.0 -0700
>+++ LinuxBIOSv2/src/config/Options.lb  2007-12-12 14:16:22.0 ->0700
>@@ -291,6 +291,11 @@
>   export always
>   comment "Use data cache as temporary RAM if possible"
> end
>+define CAR_FAM10
>+  default 0
>+  export always
>+  comment "AMD family 10 CAR need set more"
>+end

This could be a little more clear.  Did you mean "needs more setup" or
something else?

>Index: LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc
>Index: LinuxBIOSv2/src/cpu/amd/microcode/microcode.c

It looks like most of the changes are white space in these files. It would
be a lot easier to understand the changes if you submitted the patch as 
1. a white space and license patch 
2. a CAR_FAM10 patch

I also didn't understand why the type change from uint32_t to u32 was
important.

Myles





-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Broken build for kexec-boot-loader in buildrom x86_64?

[Myles Watson]

Did the patch work for anyone else?  Any concerns?

Thanks,
Myles

On Dec 7, 2007 10:45 AM, Myles Watson <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007 10:23 AM, Myles Watson <[EMAIL PROTECTED]> wrote:
> >
> >
> > > buildrom gives me still an error when building kexec-boot-loader
> > > (x86_64) for the m57sli:
> > >
> > > gcc --32-c -o kexec/x86-setup-32.o kexec/x86-setup-32.S
> > > cc1: error: unrecognized command line option "-f32"
> > >
> > > This has been reported for the tyan_s2891 before:
> > >
> > > http://www.linuxbios.org/pipermail/linuxbios/2007-November/026649.html
> > >
> > > Did I something wrong?
> >
> > You didn't do anything wrong.  Jordan's response to my email was:
> >
> > "It looks like it got the ASFLAGS when it wanted the CFLAGS."
> >
> > I haven't looked at it more, but I hope that helps.
>
> The attached patch fixes the build for me.  I've included it
> separately (cross_compile.patch), and as a patch to buildrom
> (kbl_compile.patch).
>
> It looks like a case where make was too smart, so it used the
> assembler for the .S files, and the build environment hadn't
> overwritten the assembler flags.
>
> Myles
>
> Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] [PATCH] Buildrom remove lgdt patch

[Myles Watson]

This patch removes the option from buildrom to use the lgdt patch for
LinuxBIOSv3.

On a compiler that doesn't need the patch, this patch makes the image
unbootable.

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
Index: buildrom-devel/Config.in
===
--- buildrom-devel/Config.in	(revision 83)
+++ buildrom-devel/Config.in	(working copy)
@@ -54,16 +54,6 @@
 	help
 	  Use the v3 tree.  LinuxBIOSv3 doesn't support all platforms yet.
 
-config LINUXBIOS_V3_LGDT_PATCH
-	bool "Avoid an error in stage0_i586 with some compilers"
-	depends LINUXBIOS_V3
-	default n
-	help
-	  Say 'y' here to use the patch from the mailing list to replace 
-	  "data32  lgdt %cs:gdtptr" with 
-	  "movl $gdtptr"
-  "%ebx lgdt %cs:(%bx)"
-
 config USE_LZMA
 	bool "Enable LZMA compression"
 	depends !PAYLOAD_OFW
Index: buildrom-devel/packages/linuxbios/patches/lgdt.patch
===
--- buildrom-devel/packages/linuxbios/patches/lgdt.patch	(revision 83)
+++ buildrom-devel/packages/linuxbios/patches/lgdt.patch	(working copy)
@@ -1,14 +0,0 @@
-Index: svn/arch/x86/stage0_i586.S
-===
 svn/arch/x86/stage0_i586.S	(revision 539)
-+++ svn/arch/x86/stage0_i586.S	(working copy)
-@@ -56,7 +56,8 @@
- 	 * the ld hackery and other things. So leave it as is with this comment. 
- 	 */
- 
--	data32	lgdt %cs:gdtptr
-+	movl	$gdtptr, %ebx
-+	lgdt	%cs:(%bx)
- 
- 	movl	%cr0, %eax
- 	andl	$0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0 */
Index: buildrom-devel/packages/linuxbios/qemu.mk
===
--- buildrom-devel/packages/linuxbios/qemu.mk	(revision 83)
+++ buildrom-devel/packages/linuxbios/qemu.mk	(working copy)
@@ -17,9 +17,6 @@
 ifeq ($(CONFIG_LINUXBIOS_V3),y)
 	LINUXBIOS_URL=svn://linuxbios.org/repository/LinuxBIOSv3
 	LINUXBIOS_TARBALL=linuxbiosv3-svn-$(LINUXBIOS_TAG).tar.gz
-	ifeq ($(CONFIG_LINUXBIOS_V3_LGDT_PATCH),y)
-	LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/lgdt.patch
-	endif
 	LINUXBIOS_SVN_DIR=$(SOURCE_DIR)/linuxbiosv3
 else
 	ifeq ($(CONFIG_PAYLOAD_LAB),y)
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] LinuxBIOSv3 lgdt and gdtptr patch

[Myles Watson]

> > > > It was submitted (but not in patch form) by Brendan Trotter
> > > > http://www.mail-archive.com/linuxbios@linuxbios.org/msg08771.html
> > > >
> > > > Here it is in patch form.
> > > > -   data32  lgdt %cs:gdtptr
> > > > +   movl$gdtptr, %ebx
> > > > +   lgdt%cs:(%bx)
> > > >
> > > > It removes the first line, which causes some compilers to give a
> > > > "truncated gdtptr" error, and replaces it with an intermediate load
> > > > step. I think it should be tested by someone with the "working"
> > > > compiler, to compare the output.
> > >
> > > Please repost with a Signed-off-by.
> >
> > I was hoping Brendan Trotter would supply that, since it was his work.
> It
> > could be considered trivial, though, if the compiler output is the same.
> 
> Yes, I guess this is trivial enough so you can post it with your
> Signed-off-by, but if Brendan (CC'd) can re-send with a Signed-off-by
> that's fine too, of course.

I tried it on a different compiler (4.1.1) and the patch builds, but won't
boot on qemu.  Without the patch it builds and boots.

I'll just upgrade my compiler.

Myles 




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] 1. Re: USB floppy boot (Peter Stuge)

[Myles Watson]

On Dec 9, 2007 11:25 PM, Baski <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> On Sun, Dec 09, 2007 at 12:26:21AM -0800, Baski wrote:
> > I have a tiny kernel (not linux) and GRUB in a floppy disk. How can
> > I make it to boot using linuxbios?
>
> A few things need to be considered:
>
> * How does the kernel try to find the system information that is
>  usually exported by the BIOS in quite old-fashioned ways?
>  At a minimum, the kernel needs to know how much memory is in the
>  system. LB does not offer the same methods as a BIOS to learn this.
>
> * Does the kernel use other BIOS interrupt services? LB does not
>  offer any.
>
> * How large is your kernel?
>  If it can fit with LB in the boot flash (which is between 256kb and
>  1MB) you don't need the floppy at all.
> The kernel in experiment is very tiny in nascent stage,  about 50KB, and has
> only one functionality, printing out to serial port in loop.  Can I just put
> it in the flash instead of FILO?  Pl. advise.

Sure.  The easiest way is to make your kernel into an elf, then use it
as the payload for LinuxBIOS.

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] USB floppy boot

[Myles Watson]

> On Sun, Dec 09, 2007 at 12:26:21AM -0800, Baski wrote:
> > I have a tiny kernel (not linux) and GRUB in a floppy disk. How can
> > I make it to boot using linuxbios?
> 
> A few things need to be considered:
> 
> * How does the kernel try to find the system information that is
>   usually exported by the BIOS in quite old-fashioned ways?
>   At a minimum, the kernel needs to know how much memory is in the
>   system. LB does not offer the same methods as a BIOS to learn this.

> * Does the kernel use other BIOS interrupt services? LB does not
>   offer any.

You could try ADLO (The Bochs emulator's BIOS as a LinuxBIOS payload) to
supply these services.  The most recent BIOS from Bochs (not the one in the
LinuxBIOS tree) has some timing fixes that allow it to work in real
hardware.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Expand linuxbiosv3 support

[Myles Watson]

> further question, could we get rid of mkelfimage? I can't see why
> we're still using it.

mkelfimage combines the kernel and the init.rd so it an be loaded by kexec.


Myles  



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Buildrom setup broken for GA-M57SLI?

[Myles Watson]

> Doesn't seem to work for me.
> 
> The -fno-stack-protector checking isn't working. After hacking the
> necessary makefiles to have -fno-stack-protector I get:
> 
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> /usr/bin/ld: section .id [ef64 -> ef7f] overlaps
> section .rom [5e28 -> f00f]
> /usr/bin/ld: linuxbios: section .id lma 0xef64 overlaps previous
> sections
> /usr/bin/ld: linuxbios: section .reset lma 0xeff0 overlaps previous
> sections
> collect2: ld returned 1 exit status
> make[2]: *** [linuxbios] Error 1
> 
> Which IIRC means that my linuxbios image is too big.  The build tutorial
> for this board seems to suggest that this is supposed to work.  Is this
> a regression or is my Ubuntu gutsy toolchain to blame?


If your payload isn't too big, try increasing the ROM_IMAGE_SIZE in
Config.lb.  You may still have room.  You could also check the abuild Config
file to see what size to set ROM_IMAGE_SIZE to.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] many trivial patches

[Myles Watson]

>
> I'm running abuild now.

It passes abuild.

Thanks,
Myles

> > If the boards still build (which I suspect they will),
> >
> > Acked-by: Ward Vandewege <[EMAIL PROTECTED]>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] many trivial patches

[Myles Watson]

> > > This is a resend.  Does anyone have objections to this patch still?
> >
> > Did you check with abuild that all boards still build fine after the
> > patch? Did you compare the sizes, i.e. does it make a real difference
> > in behaviour of the build, or is it just a "cosmetical" change?
> 
> It's not cosmetic. Without this patch, we can't have an LZMA precompressed
> payload for the board (which is an option in buildrom).

As I understand it, all the precompressed payload option does is tells the
build process not to try to run lzma on the payload when LZMA compression is
enabled.  

It allows buildrom to use its own compiled version of lzma instead of the
one that the user might have in his path.

Since I didn't set the variable, but just allowed it to be set in the
future, my hypothesis is that it changes nothing for abuild.

I'm running abuild now.

> 
> If the boards still build (which I suspect they will),
> 
> Acked-by: Ward Vandewege <[EMAIL PROTECTED]>

Thanks,
Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [PATCH] many trivial patches

[Myles Watson]

This is a resend.  Does anyone have objections to this patch still?

It adds "uses CONFIG_PRECOMPRESSED_PAYLOAD" to the Options.lb files so
that buildrom can build for these targets only changing the Config.lb
file, instead of patching the Options.lb files as well.

Myles

-- Forwarded message ------
From: Myles Watson <[EMAIL PROTECTED]>
Date: Nov 7, 2007 2:02 PM
Subject: [PATCH] many trivial patches
To: Linuxbios 

This adds the same line (uses CONFIG_PRECOMPRESSED_PAYLOAD) to every
Options.lb file that already had a "uses
CONFIG_COMPRESSED_PAYLOAD_LZMA" line in it.

I figure that only adding it to the files that already have support
for LZMA payloads makes sure I don't break anything.

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>


PRECOMPRESSED.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Expand linuxbiosv3 support

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 06, 2007 4:47 PM
> To: Myles Watson
> Cc: linuxbios@linuxbios.org
> Subject: Re: Expand linuxbiosv3 support
> 
> On 06/12/07 16:32 -0700, Myles Watson wrote:
> > It complains that the logs directory doesn't exist when it tries to
> fetch
> > and create the linuxbiosv3/logs/fetch.log file.
> 
> oops - my bad - I can fix that.
> 
> > I prefer to have LinuxBIOSv2 and LinuxBIOSv3 represented in the same
> way.  I
> > think it's confusing to have one be LBV3 and one LINUXBIOS.  It seems
> like
> > LINUXBIOS should be used in the generic case, and things that are
> specific
> > to v2 or v3 should be labeled that way.
> 
> The problem is that v2 and v3 are way too different - so regardless of
> the nomenclature, you're going to need to have ifeq statements everywhere,
> and I personally think that is messier then having different variables
> names.  If you want, we _can_ reuse the variables since we're only
> including
> either the v2 or the v3 .mk file, but to me that makes things more
> confusing
> to the person porting the platform.

I was just voting for the variables to look the same if they were the same.
(LINUXBIOS_V2_BUILD_DIR and LINUXBIOS_V3_BUILD_DIR or LBV2_BUILD_DIR and
LBV3_BUILD_DIR)  

I wasn't complaining about the separation.

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Expand linuxbiosv3 support

[Myles Watson]

It complains that the logs directory doesn't exist when it tries to fetch
and create the linuxbiosv3/logs/fetch.log file.

I prefer to have LinuxBIOSv2 and LinuxBIOSv3 represented in the same way.  I
think it's confusing to have one be LBV3 and one LINUXBIOS.  It seems like
LINUXBIOS should be used in the generic case, and things that are specific
to v2 or v3 should be labeled that way.

Which platform uses the extra ROM functionality you added?  I didn't try
that out.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Some fixes

[Myles Watson]

> [BUILDROM] Some fixes
>
> Remove a spurious variable from the GPXE stuff, rearrange the menu
> a little bit, and switch the Make jobs to an integer to make it
> easier to understand and use.
>
> Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>

It works for me.
Acked-by: Myles Watson <[EMAIL PROTECTED]>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] LinuxBIOSv3 lgdt and gdtptr patch

[Myles Watson]

> On Thu, Dec 06, 2007 at 10:14:41AM -0700, Myles Watson wrote:
> > It was submitted (but not in patch form) by Brendan Trotter
> > http://www.mail-archive.com/linuxbios@linuxbios.org/msg08771.html
> >
> > Here it is in patch form.
> > -   data32  lgdt %cs:gdtptr
> > +   movl$gdtptr, %ebx
> > +   lgdt%cs:(%bx)
> >
> > It removes the first line, which causes some compilers to give a
> > "truncated gdtptr" error, and replaces it with an intermediate load
> > step. I think it should be tested by someone with the "working"
> > compiler, to compare the output.
> 
> Please repost with a Signed-off-by.

I was hoping Brendan Trotter would supply that, since it was his work.  It
could be considered trivial, though, if the compiler output is the same.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] ADLO & biosdecode

[Myles Watson]

> > You need to add a new version of the loader since the BIOS is larger,
> and
> > use the larger elf header.
> 
> You mean the new version of ADLO is needed?
> 
Yes,

The file loader.s copies the BIOS into RAM and sets up the CMOS values.  If
you use the 32-bit BIOS, you need to make sure all of it gets copied.  I was
also messing around with this because the loader needs to be 4k-aligned to
work with kexec, and that's the pathway I want to use.

> >
> > I'm planning on doing that in the near future.
> >
> 
> Anything I can help here? Or if you can give some hints, I will try to
> do something (Currently I am not used to the ADLO code yet)

These emails are from my latest progress.  I hope to get back to it soon,
but I'd love it if you beat me to it.

http://www.mail-archive.com/linuxbios@linuxbios.org/msg12748.html
http://www.mail-archive.com/linuxbios@linuxbios.org/msg12724.html

Feel free to ask specific questions once you're digging.

Thanks,
Myles

> Thanks,
> Jun



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] LinuxBIOSv3 lgdt and gdtptr patch

[Myles Watson]

> -Original Message-
> From: Carl-Daniel Hailfinger [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 06, 2007 9:40 AM
> To: [EMAIL PROTECTED]
> Cc: 'Linuxbios'
> Subject: Re: [LinuxBIOS] r77 - in buildrom-devel: . config/payloads
> config/platforms packages/linuxbios
>
> On 06.12.2007 17:33, Myles Watson wrote:
> >>> Modified: buildrom-devel/Config.in
> >>> ===
> >>> --- buildrom-devel/Config.in  2007-12-05 23:27:08 UTC (rev 76)
> >>> +++ buildrom-devel/Config.in  2007-12-06 16:18:18 UTC (rev 77)
> >>> @@ -43,6 +43,23 @@
> >>>
> >>>  menu "LinuxBIOS configuration"
> >>>
> >>> +config LINUXBIOS_V3
> >>> + bool "Use LinuxBIOSv3"
> >>> + depends ADVANCED
> >>> + default n
> >>> + help
> >>> +   Use the v3 tree.  LinuxBIOSv3 doesn't support all platforms yet.
> >>> +
> >>> +config LINUXBIOS_V3_LGDT_PATCH
> >>> + bool "Avoid an error in stage0_i586 with some compilers"
> >>> + depends LINUXBIOS_V3
> >>> + default n
> >>> + help
> >>> +   Say 'y' here to use the patch from the mailing list to replace
> >>> +   "data32  lgdt %cs:gdtptr" with
> >>> +   "movl $gdtptr"
> >>> +  "%ebx lgdt %cs:(%bx)"
> >>> +
> >>>  config USE_LZMA
> >>>   bool "Enable LZMA compression"
> >>>   depends !PAYLOAD_OFW
> >>>
> >>>
> >> While I welcome almost everything in that patch, I dislike that part.
> >> Either we agree on some code sequence that works for everyone or we
> mark
> >> some compilers "broken".
> >>
> >
> > I like the "code sequence that works for everyone" thought.  That's more
> of
> > a LinuxBIOSv3 issue than a buildrom issue, though.  I'd hoped to make
> people
> > happy by not applying the patch by default.
> >
>
> Can you send it in as a patch with a short description? If comments are
> positive, we should just commit.

It was submitted (but not in patch form) by Brendan Trotter
http://www.mail-archive.com/linuxbios@linuxbios.org/msg08771.html

Here it is in patch form.
-   data32  lgdt %cs:gdtptr
+   movl$gdtptr, %ebx
+   lgdt%cs:(%bx)

It removes the first line, which causes some compilers to give a
"truncated gdtptr" error, and replaces it with an intermediate load
step. I think it should be tested by someone with the "working"
compiler, to compare the output.

Myles


lgdt.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> >
> > None of the new files came through.  They look like they're in the
> patch,
> > but not in the commit. Am I supposed to generate the patches
> differently?
> > I'm just using
> > svn diff buildrom-devel
> 
> My bad - I screwed it up on my end.
> 

It seems easy to do.  Is there an automated way to add files to svn with a
patch.

"svn patch" seems like it might be nice. (It would "svn add" files added in
a patch)

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 06, 2007 9:26 AM
> To: Myles Watson
> Cc: Linuxbios
> Subject: Re: State of the buildrom
> 
> On 06/12/07 09:00 -0700, Myles Watson wrote:
> > And the patch :)
> > >
> > > Myles
> > >
> > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
> > >
> 
> r77. Everybody please update - and go nuts.

None of the new files came through.  They look like they're in the patch,
but not in the commit. Am I supposed to generate the patches differently?
I'm just using 
svn diff buildrom-devel

Thanks,
Myles

> 
> > --
> > linuxbios mailing list
> > linuxbios@linuxbios.org
> > http://www.linuxbios.org/mailman/listinfo/linuxbios
> 
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] r77 - in buildrom-devel: . config/payloads config/platforms packages/linuxbios

[Myles Watson]

> > Modified: buildrom-devel/Config.in
> > ===
> > --- buildrom-devel/Config.in2007-12-05 23:27:08 UTC (rev 76)
> > +++ buildrom-devel/Config.in2007-12-06 16:18:18 UTC (rev 77)
> > @@ -43,6 +43,23 @@
> >
> >  menu "LinuxBIOS configuration"
> >
> > +config LINUXBIOS_V3
> > +   bool "Use LinuxBIOSv3"
> > +   depends ADVANCED
> > +   default n
> > +   help
> > + Use the v3 tree.  LinuxBIOSv3 doesn't support all platforms yet.
> > +
> > +config LINUXBIOS_V3_LGDT_PATCH
> > +   bool "Avoid an error in stage0_i586 with some compilers"
> > +   depends LINUXBIOS_V3
> > +   default n
> > +   help
> > + Say 'y' here to use the patch from the mailing list to replace
> > + "data32  lgdt %cs:gdtptr" with
> > + "movl $gdtptr"
> > +  "%ebx lgdt %cs:(%bx)"
> > +
> >  config USE_LZMA
> > bool "Enable LZMA compression"
> > depends !PAYLOAD_OFW
> >
> 
> While I welcome almost everything in that patch, I dislike that part.
> Either we agree on some code sequence that works for everyone or we mark
> some compilers "broken".

I like the "code sequence that works for everyone" thought.  That's more of
a LinuxBIOSv3 issue than a buildrom issue, though.  I'd hoped to make people
happy by not applying the patch by default.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 06, 2007 9:09 AM
> To: Myles Watson
> Cc: Linuxbios
> Subject: Re: State of the buildrom
> 
> On 06/12/07 08:57 -0700, Myles Watson wrote:
> > This is the same patch, updated to use HEAD instead of 539.  Because
> > of the way linuxbios.inc works, this only gets the true head the first
> > time, then it just takes the previously built tarball.  So if you
> > really want the new head you have to remove the tarball.
> 
> The decision to force the user to chose what revision to use was mine, and
> I've taken a lot of flack for it.  I still think there is real value in
> directly specifying where the code comes from (for reproducability)
> purposes,
> but if everybody complains at the same time, I can change my mind
> (and reserve the right to say "I told you so" later).
> 

It seems like a two-edged sword to me.  Right now if you install the latest
iasl and use buildrom, it will fail on any platform that needs iasl, since
iasl changed.

If we took from the latest, we'd have to update iasl before it worked again.

Either way works for me.

Myles





-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

This is the same patch, updated to use HEAD instead of 539.  Because
of the way linuxbios.inc works, this only gets the true head the first
time, then it just takes the previously built tarball.  So if you
really want the new head you have to remove the tarball.

I also created a new variable LINUXBIOS_SVN_DIR to keep it from
getting v2 and v3 confused with version numbers when you switch back
and forth.

I added an option to use the lgdt patch from the mailing list which
enables compilation on the compilers I have.

I fixed a bug I introduced in the last patch when I added an extra @
to a line in linuxbios.inc

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> > That said, I haven't used v3 yet.
> >
>
> give it a try first :-)
>
> thanks
>
> ron
>

This patch adds support for QEMU to buildrom, for both v2 and v3.  It
also allows you to build QEMU from sources with the patches.

I've built it for v2 and v3 and it boots in v2, I'm not sure why it
builds but doesn't boot in v3.  Anyone care to send me their config
file that works?

In both v2 and v3 I turned of lzma compression because the
decompressor was running out of space, and emulated ROM space was
cheap today.

I set it to use revision 539 of v3 because that was the last revision
before it was broken on purpose to mirror hardware better.

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] ADLO & biosdecode

[Myles Watson]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxbios-
> [EMAIL PROTECTED] On Behalf Of Jun Koi
> On 12/5/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> > Peter Stuge wrote:
> > > Hello Jun,
> > >
> > > On Wed, Dec 05, 2007 at 12:54:42PM +0900, Jun Koi wrote:
> > >
> > >> If I use the original QEMU BIOS, at least biosdecode reports BIOS32
> > >> Service Dir + PCI IRQ table + ACPI.
> > >>
> > >> So why LinuxBIOS removes those information?
> > >>
> > >
> > > This is on purpose.
> > >
> > > One motivation for LB is that most if not all interfaces that are
> > > associated with the term BIOS should be deprecated.
> > >
> > > LB does not strive to be BIOS compatible by design.
> > >
> > But this is not true for Jun's setting with LinuxBIOS + ADLO.
> >
> > I don't think we remove anything on purpose there.
> 
> Yes, I guess the information (biosdecode) must be there, as I use Boch
> BIOS with LinuxBIOS, but not LinuxBIOS only.
> 
> And interestingly, there is no option to make 32bit BIOS in
> ADLO/bochs/bios/Makefile. I simply generated bochs/bios/bios.bin by
> running "make" inside ADLO/
> 
> So I think the question becomes: how to get 32bit BIOS now?

You need to add a new version of the loader since the BIOS is larger, and
use the larger elf header.

I'm planning on doing that in the near future.

Myles




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Add support for the AMD SimNow (TM) simulator (try2)

[Myles Watson]

> > > > Is there a howto on the web page to show how to use this sim
> > > > environment? This is really cool.
> > >
> > I put up a basic page today that should help someone get started.
> > It's at http://www.linuxbios.org/AMD_SimNow and it's linked to from
> > the homepage, down by QEMU.
> 
> Very nice, thanks! But please add a license at the bottom of the page
> (use {{GPL}} or {{PD-self}} etc).

Done.  
Thanks,
Myles





-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> On Mon, Dec 03, 2007 at 11:29:27AM -0700, Jordan Crouse wrote:
> > > I think it's more important to figure out how we really want to
> configure
> > > LinuxBIOS (it seems to be a large hurdle for newbies), not buildrom.
> >
> > Agreed - being able to do these things easily with v3 is a priority.
> > We have to think about what we would want to control externally, and
> then
> > make those knobs easy to turn.
> 
> Isn't that easy in v3 already? You just use / modify defconfig files as
> with the kernel.

>From my point of view, modifying defconfig files from buildrom is not that
easy.  Very small changes frequently require you to run make oldconfig so
that you can handle all of the options that were not set, but now need to be
set because you changed an option.

Maybe there is a good way to do hierarchical make menuconfig, but then you
get the problem that the sources haven't been downloaded yet when you are
configuring buildrom.

That said, I haven't used v3 yet.

It seems like in the current state, the addition of new options (a new form
of compression, for instance) in v3's config files might require patching
all of the .config files in buildrom.  That doesn't seem nice.

I'm just hoping that when v3 supports the platforms I'm interested in it
will be easy for buildrom to select which images to include and do some
rudimentary calculations to see if they'll fit in the ROM.

Thanks,

Myles
PS If I'm overlooking the obvious, easy ways to do things I'm all ears.
It's easy to end up doing things the hard way if you don't know what the
easy way is.



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] Add iso9660 support to LAB kernel for serengeti-cheetah

[Myles Watson]

This is a trivial patch that adds support for iso9660 file systems to
the LAB kernel for serengeti-cheetah.

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>


iso9660_for_serengeti_cheetah_LAB.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> * Optimizations:  There are always things we can do to clean up - add -j N
> support for make, reduce memory usage, avoid stupid gmake tricks and the
> like.  I think things are stable enough in the core that we can start to
> twist some knobs without blowing everything up.
>

This patch adds -jN support to speed builds.  It passes it as an
argument to make for the kernel and uClibc.  It breaks the build for
busybox, so it isn't passed there.

The default is -j1, or the status quo.

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>


make_jobs.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Add support for the AMD SimNow (TM) simulator (try 2)

[Myles Watson]

On 11/28/07, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> On 28/11/07 12:31 -0800, ron minnich wrote:
> > Is there a howto on the web page to show how to use this sim
> > environment? This is really cool.
>
I put up a basic page today that should help someone get started.
It's at http://www.linuxbios.org/AMD_SimNow and it's linked to from
the homepage, down by QEMU.

Feel free to ask questions or clean it up as suits your tastes.

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

[LinuxBIOS] buildrom patch

[Myles Watson]

I forgot one more file:
 packages/busybox/conf/defconfig-serengeti_cheetah-x86_64

There are two options:
1. apply defconfig-busybox.patch, which adds the file
2. apply defconfig-busybox2.patch, which removes the dependency and
lets serengeti_cheetah have the same busybox as everyone else

The difference is that I'd added tab completion, command editing, and
a history of 15 commands to make it easier to mount drives, etc.

--- packages/busybox/conf/defconfig 2007-12-03 14:59:55.0 -0700
+++ packages/busybox/conf/defconfig-serengeti_cheetah-x86_64
2007-12-03 15:19:50.0 -0700
@@ -576,11 +576,11 @@
 #
 CONFIG_FEATURE_SH_EXTRA_QUIET=y
 CONFIG_FEATURE_SH_STANDALONE_SHELL=y
-# CONFIG_FEATURE_COMMAND_EDITING is not set
+CONFIG_FEATURE_COMMAND_EDITING=y
 # CONFIG_FEATURE_COMMAND_EDITING_VI is not set
-CONFIG_FEATURE_COMMAND_HISTORY=0
+CONFIG_FEATURE_COMMAND_HISTORY=15
 # CONFIG_FEATURE_COMMAND_SAVEHISTORY is not set
-# CONFIG_FEATURE_COMMAND_TAB_COMPLETION is not set
+CONFIG_FEATURE_COMMAND_TAB_COMPLETION=y
 # CONFIG_FEATURE_COMMAND_USERNAME_COMPLETION is not set
 # CONFIG_FEATURE_SH_FANCY_PROMPT is not set

Put another way, the difference is about 5K in the ROM

Either way is fine with me.

Myles

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

PS  I've since learned to use svn stat, so I'll hopefully forget fewer
files in future diffs


defconfig-busybox.patch
Description: Binary data


defconfig-busybox2.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> > > > There just isn't any good way to change v2 config files without
> > > > lots of pain
> > >
> > > > Not that we really have a great story for v3 either,
> > > ..
> > > > really a generic way to override config without editing text files
> > > > would be the most ideal.
> > >
> > > How about one environment variable that points to another file with
> > > options?
> >
> > The unfortunate thing is that either this adds lots more Config.lb files
> > (one for each payload combination or ROM size), or forces you to patch
> the
> > buildrom-specific file you just introduced.
> 
> What scared me about changing the configs on the fly was the extreme
> amount
> of sed magic we would have to do to get it right.  In this case, that fear
> isn't there since we're not actually modifying any existing files, so we
> can
> easily add the config options we want with echo >:
> 
> ifeq ($(CONFIG_LZMA),y)
> echo "NEEDLZMAPLEASE=1" >> $(LBOVERRIDE)
> endif
> 

All right.  At least it will document what the Config.lb variables mean if
they "need" to be tweaked.

Myles

> That will be pretty generic for most cases - if there is something really
> special for a particular platform, we can specify a static override file
> to start and then modify it as above, but that will be the exception, not
> the rule.
> 
> > I think it's more important to figure out how we really want to
> configure
> > LinuxBIOS (it seems to be a large hurdle for newbies), not buildrom.
> 
> Agreed - being able to do these things easily with v3 is a priority.
> We have to think about what we would want to control externally, and then
> make those knobs easy to turn.
> 
> Jordan
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] State of the buildrom

[Myles Watson]

> > There just isn't any good way to change v2 config files without
> > lots of pain
> 
> > Not that we really have a great story for v3 either,
> ..
> > really a generic way to override config without editing text files
> > would be the most ideal.
> 
> How about one environment variable that points to another file with
> options?

The unfortunate thing is that either this adds lots more Config.lb files
(one for each payload combination or ROM size), or forces you to patch the
buildrom-specific file you just introduced.

I think it's more important to figure out how we really want to configure
LinuxBIOS (it seems to be a large hurdle for newbies), not buildrom.

Once it's easy to configure LinuxBIOS it will be easy to do it with
buildrom.

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Broken build for kexec-boot-loader in buildrom x86_64?

[Myles Watson]

> buildrom gives me still an error when building kexec-boot-loader
> (x86_64) for the m57sli:
> 
> gcc --32-c -o kexec/x86-setup-32.o kexec/x86-setup-32.S
> cc1: error: unrecognized command line option "-f32"
> 
> This has been reported for the tyan_s2891 before:
> 
> http://www.linuxbios.org/pipermail/linuxbios/2007-November/026649.html
> 
> Did I something wrong?

You didn't do anything wrong.  Jordan's response to my email was:

"It looks like it got the ASFLAGS when it wanted the CFLAGS."

I haven't looked at it more, but I hope that helps.

> Regards
> 
>Andi
> 




-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the AMD SimNow (TM) simulator (try 2)

[Myles Watson]

On 11/28/07, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> Here is the refreshed patch for the SimNow support against current RCS.
> Something is triggering my bat sense that the tree isn't exactly in a
> right state, but I can't remember what it is.  Please test the tree with
> and without the patch to make sure that its sane.
>
> Jordan
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.
>
> [BUILDROM] Add support for the AMD SimNow (TM) simulator
>
> Add a build option and a patch against LinuxBIOS to allow the
> Serengeti-Cheetah platform to come up on its emulated self in
> the SimNow simulator.
>
> Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
It boots for me with the patch, and builds with and without.
Acked-by: Myles Watson <[EMAIL PROTECTED]>

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -Original Message-
> From: Ward Vandewege [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 27, 2007 2:05 PM
> To: Myles Watson
> Cc: 'Jordan Crouse'; 'Linuxbios'
> Subject: Re: [LinuxBIOS] Complete and generic 32bit/64bit support
> 
> Hi Myles,
> 
> On Mon, Nov 26, 2007 at 07:55:48AM -0700, Myles Watson wrote:
> > > Your patch seems ok, except it does not pass -fno-stack-protector
> through
> > > to
> > > mkelfimage anymore, which breaks the build on modern Debian based
> systems.
> > >
> > > Can you fix that?
> >
> > Can you help me know how I broke it?  I don't see anywhere that I
> modified
> > the flags passed to the compiler in mkelfimage.mk.  I also looked at the
> > other changes in the patch, but didn't see anything obvious.  I don't
> have
> > Debian, so it's less obvious for me.
> 
> It's unclear to me as well. Basically buildrom is not perfect yet wrt
> adding
> -fno-stack-protector.
> 
> I suggest we merge your patch now, and fix that later. Other parts of the
> LAB
> payload also don't get -fno-stack-protector as they should.

Sounds good.
Myles

> 
> Thanks,
> Ward.
> 
> --
> Ward Vandewege <[EMAIL PROTECTED]>
> Free Software Foundation - Senior System Administrator


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> > > I don't get this patch - do we still need
> > > packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does
> all
> > > the heavy lifting now.  Or not?
> >
> > My understanding is that packages/kernel/serengeti_cheetah-kernel-
> x86_64.mk
> > sets the kernel version, url, config file, etc.  kernel.inc builds the
> > kernel you specified in the .mk file.
> 
> is there enough different about it that we need two files?  I was planning
> on setting the configuration information in the platform configuration:
> 
> ifeq ($(CONFIG_TARGET_64BIT),y)
> KERNEL_VERSION=2.6.22.2

> KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk

So do you want to remove this line if you only want one .mk file?  Do we
want to make a new variable CONFIG_TINY that downloads the tiny patches for
the KERNEL_VERSION we've selected?  Once we go that far is there any reason
to have board-specific .mk files for the kernel at all?  That would be nice
from my perspective (many of the boards can/do use the same kernel
versions), but it is a major change. 

Myles

> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah-
> x86_64
> BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64
> UCLIBC_VER=0.9.29
> UCLIBC_CONFIG=defconfig-x86_64
> else
> KERNEL_VERSION=2.6.20.2
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah
> UCLIBC_VER=0.9.28
> endif
> 
> That would save us having to have mutiple copies of the kernel make files
> for 32 and 64 bit.  Is this bad?
> 
> Jordan
> 
> > The other two files are Config.lb files depending on which payload you
> want
> > to use.
> 
> Yes - those made sense to me.
> 
> 
> > Myles
> >
> > >
> > > Jordan
> >
> >
> >
> >
> 
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> 
> Your patch seems ok, except it does not pass -fno-stack-protector through
> to
> mkelfimage anymore, which breaks the build on modern Debian based systems.
> 
> Can you fix that?

Can you help me know how I broke it?  I don't see anywhere that I modified
the flags passed to the compiler in mkelfimage.mk.  I also looked at the
other changes in the patch, but didn't see anything obvious.  I don't have
Debian, so it's less obvious for me.

Thanks,
Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 26, 2007 4:54 PM
> To: Myles Watson
> Cc: 'Linuxbios'
> Subject: Re: Complete and generic 32bit/64bit support
> 
> On 26/11/07 16:36 -0700, Myles Watson wrote:
> >
> >
> > > -Original Message-
> > > From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> > > On 21/11/07 16:41 -0700, Myles Watson wrote:
> > > > I forgot to add these 3 files to the diff.  Sorry.
> > > > I also don't know how to remove s-c-payload.patch from
> > > > packages/linuxbios/patches and have it show up in the patch.
> > >
> > > I don't get this patch - do we still need
> > > packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does
> all
> > > the heavy lifting now.  Or not?
> >
> > My understanding is that packages/kernel/serengeti_cheetah-kernel-
> x86_64.mk
> > sets the kernel version, url, config file, etc.  kernel.inc builds the
> > kernel you specified in the .mk file.
> 
> is there enough different about it that we need two files?  I was planning
> on setting the configuration information in the platform configuration:
> 
> ifeq ($(CONFIG_TARGET_64BIT),y)
> KERNEL_VERSION=2.6.22.2
> KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah-
> x86_64
> BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64
> UCLIBC_VER=0.9.29
> UCLIBC_CONFIG=defconfig-x86_64
> else
> KERNEL_VERSION=2.6.20.2
> KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah
> UCLIBC_VER=0.9.28
> endif
> 

That's fine with me.  The other difference is the tiny patches.

It won't build for 64-bit Serengeti cheetah until we figure it out.

Myles

> That would save us having to have mutiple copies of the kernel make files
> for 32 and 64 bit.  Is this bad?
> 
> Jordan
> 
> > The other two files are Config.lb files depending on which payload you
> want
> > to use.
> 
> Yes - those made sense to me.
> 
> 
> > Myles
> >
> > >
> > > Jordan
> >
> >
> >
> >
> 
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> On 21/11/07 16:41 -0700, Myles Watson wrote:
> > I forgot to add these 3 files to the diff.  Sorry.
> > I also don't know how to remove s-c-payload.patch from
> > packages/linuxbios/patches and have it show up in the patch.
> 
> I don't get this patch - do we still need
> packages/kernel/serengeti_cheetah-kernel-x86_64.mk?  kernel.inc does all
> the heavy lifting now.  Or not?

My understanding is that packages/kernel/serengeti_cheetah-kernel-x86_64.mk
sets the kernel version, url, config file, etc.  kernel.inc builds the
kernel you specified in the .mk file.

The other two files are Config.lb files depending on which payload you want
to use.

Myles

> 
> Jordan



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

I forgot to add these 3 files to the diff.  Sorry.
I also don't know how to remove s-c-payload.patch from
packages/linuxbios/patches and have it show up in the patch.

Thanks,
Myles

In case we need a separate signed off
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

On 11/21/07, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> On 21/11/07 14:51 -0500, Ward Vandewege wrote:
> > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > It makes the same changes as mentioned before, but it also uses the
> > > correct kernel image depending on the architecture.  mkelfimage
> > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > generates a _much_ larger elf.
> >
> > Ah, is that what's happening? Bug in mkelfimage?
> >
> > I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great work.
> >
> > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
> >
> > Acked-by: Ward Vandewege <[EMAIL PROTECTED]>
>
> r58 - thanks a lot to everybody!  Happy thanksgiving if that happens to
> be a holiday in your part of the world.
>
> Jordan
>
>
>


forgotten_files.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

On 11/21/07, yhlu <[EMAIL PROTECTED]> wrote:
> On Nov 21, 2007 12:03 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > > > It makes the same changes as mentioned before, but it also uses the
> > > > correct kernel image depending on the architecture.  mkelfimage
> > > > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > > > generates a _much_ larger elf.
>
> for x86_64 support
> there is a patch i posted several months ago.
>
> because late x86_64 kernel vmlinux is elf64, you need to use melfImage
> to convert that to elf32.
>
> YH

I tested it using the amd serengeti_cheetah LAB (64-bit) platform in buildrom

With mkelfimage 2.5 using bzImage (vmlinux doesn't work)
Payload takes 901210 Bytes (880 KBytes) in ROM:

With mkelfimage 2.7 and Yinghai's patch using bzImage
Payload takes 900919 Bytes (879 KBytes) in ROM:

With mkelfimage 2.7 and Yinghai's patch using vmlinux
Payload takes 770726 Bytes (752 KBytes) in ROM:

So 2.7 is marginally better anyway, and blows 2.5 away by using vmlinux.

I tested it and it boots.  I think we should upgrade to 2.7 and use the patch.

My patch makes it so all targets use vmlinux and 2.7
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>


mkelfimage.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> 
> On Wed, Nov 21, 2007 at 12:13:23PM -0700, Myles Watson wrote:
> > It makes the same changes as mentioned before, but it also uses the
> > correct kernel image depending on the architecture.  mkelfimage
> > doesn't work with an x86_64 vmlinux, and with an i386 bzImage it
> > generates a _much_ larger elf.
> 
> Ah, is that what's happening? Bug in mkelfimage?

I guess so.  It took me a long time and a lot of random tries to figure out
that it worked with x86_64 because all the makefiles used vmlinux.

It was last year, so I don't remember why I finally tried using a bzImage,
but at least it works now.

> 
> I've built an m57sli-s4 LAB image on 32-bit, and just booted it. Great
> work.
> 
> > Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
> 
> Acked-by: Ward Vandewege <[EMAIL PROTECTED]>

Thanks for testing it.

Myles

> 
> Thanks,
> Ward.
> 
> --
> Ward Vandewege <[EMAIL PROTECTED]>
> Free Software Foundation - Senior System Administrator


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> This patch does not set the UCLIBC_ARCH variable correctly on 32 bit; it
> needs to be forced to i386 there instead of $(TARGET_ARCH), which is i686 on
> my box.
>
> For 64 bit it's fine, because there the UCLIBC_ARCH variable needs to be
> x86_64 which happens to match $(TARGET_ARCH).
>
> Here's a simple fix for the m57sli board:
>
> --- config/platforms/m57sli.conf(revision 57)
> +++ config/platforms/m57sli.conf(working copy)
> @@ -6,8 +6,15 @@
>  STRIP=strip
>  AS=as
>
> +ifeq ($(CONFIG_TARGET_64BIT),y)
> +TARGET_ARCH=x86_64
> +UCLIBC_ARCH=x86_64
> +CFLAGS_platform =
> +else
>  TARGET_ARCH=i686
> -CFLAGS_platform = -m32
> +UCLIBC_ARCH=i386
> +CFLAGS_platform =
> +endif
>
> Can you fix that for all boards?

How about this fix?  Can you test the attached patch?  It fixes it in
uclibc.mk instead of in each individual board.

If the patch works for you, I'll send a full patch from the latest svn.
>
> The other thing I was wondering about is why the exit -1 is dropped in
> buildrom-devel/bin/checkrom.sh when the image won't fit? It's nice for the
> build to fail explicitly if the image is too big instead of producing obscure
> linker errors further down the line.

The problem is that the amount that is free in the ROM is dependent on
the size of the ROM, the size of LinuxBIOS, and any other payloads you
have in your configuration.  Thus checkrom depends on a magic number
to say if it will fail or not.

Choose a platform with a ROM_SIZE smaller than 1 MB and checkrom
doesn't protect you from linker errors.  Choose to use a 2 MB ROM and
checkrom fails even when it shouldn't.

Maybe the warning needs to be more verbose, but I really don't like
the magic number test and fail.

Myles


uclibc_arch.patch
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Setup of Memory Controller

[Myles Watson]

>  Im currently looking at the resourcemap.c for the tyan s2891 and looking at
> simply changing the hex value for the DRAM Limit and Base address for offset
> 44 and 40 to point to node 1 rather than node 0 and cross my fingers.

I've been wondering what would happen if I did that too.  I was
worried that it would try to send coherent packets if it thought the
region mapped to DRAM on another node.

>
>  I should receive my biossavior tomorrow and commence testing over the
> break.
>

I'll be interested to see how it turns out for you.

Myles

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> This needs to be added on top of your big patch to make the m57sli-s4
> build:
> 
> --- config/platforms/m57sli.conf-orig   2007-11-22 11:11:08.0 -
> 0500
> +++ config/platforms/m57sli.conf2007-11-22 10:55:47.0 -
> 0500
> @@ -26,7 +26,7 @@
>  ifeq ($(CONFIG_TARGET_64BIT),y)
>  $(error You must specify a kernel configuration for 64 bit)
>  else
> -KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/m57sli-defconfig
> +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-m57sli
>  endif
> 
>  #UCLIBC_ARCH=$(TARGET_ARCH)

The same patch is needed for almost every config/platforms/*.conf because of
the decision to put defconfig first in the file names.

Myles



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] lzma compression and filo/etherboot payloads in buildrom

[Myles Watson]

> I seem to have a problem when trying to use a lzma pre-compressed payload
> in
> buildrom in combination with an etherboot (or filo) payload. Things work
> fine
> with a kernel or LAB payload.
> 
> I've attached the LinuxBIOS Config.lb I used, and the boot output for
> etherboot. I recall having similar problems with a filo payload.
> 
> If I disable CONFIG_COMPRESSED_PAYLOAD_LZMA and
> CONFIG_PRECOMPRESSED_PAYLOAD
> in Config.lb and disable the LZMA compression in buildrom's kconfig the
> Etherboot payload works just fine.

I just tried it with serengeti_cheetah, and it worked for me with just a
fallback image. I've attached my Config and bootlog.

I noticed that you have CONFIG_COMPRESSED_PAYLOAD_LZMA and
CONFIG_PRECOMPRESSED_PAYLOAD set in your Failover image, even though there
is no official payload.

I couldn't see anything else, but I hope this helps.

Myles





Config.filoLZMA.lb
Description: Binary data
LinuxBIOS-2.0.0_serengenti_cheetah_Fallback Thu Nov 15 13:03:09 MST 2007 
starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
01 nodes initialized.
core0 started:
started ap apicid:
SBLink=00
NC node|link=00
Ram1.00
Ram2.00
Registered
200Mhz
RAM: 0x0004 KB
Ram3
Initializing memory:  done
set DQS timing:RcvrEn:Pass1: 00 done
set DQS timing:DQSPos: 00 done
set DQS timing:RcvrEn:Pass2: 00 done
Total DQS Training : tsc [00]=0192427d
Total DQS Training : tsc [01]=01c17da8
Total DQS Training : tsc [02]=020e4f48
Total DQS Training : tsc [03]=0243c3a8
Ram4
v_esp=000cefc8
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now
Clearing initial memory region: Done
Copying LinuxBIOS to RAM.
src=fffe6000
dst=0010
linxbios_ram.nrv2b length = f4de
linxbios_ram.bin   length = 00026f4c
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0_serengenti_cheetah_Fallback Thu Nov 15 13:03:09 MST 2007 
booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN:  enabled
  PCI: 00:18.3 siblings=0
Found Rev E or Rev F later single core
CPU: APIC: 00 enabled
PCI: pci_scan_bus for bus 00
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] enabled

--8<---Snip->8-

Adjust rom_table_end from 0x000f2400 to 0x0010
Wrote linuxbios table at: 0530 - 0dfc  checksum 801f

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

rom_stream: 0xfff0 - 0xfffe5fff
Uncompressing to RAM 0x0100  olen = 0xeb68 done.
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x10 size 0x2d580 offset 0xc0 filesize 0xe868
(cleaned up) New segment addr 0x10 size 0x2d580 offset 0xc0 filesize 0xe868
New segment addr 0x12d580 size 0x48 offset 0xe940 filesize 0x48
(cleaned up) New segment addr 0x12d580 size 0x48 offset 0xe940 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0ff24000 memsz: 0x0002d580 filesz: 
0xe868
Clearing Segment: addr: 0x0ff32868 memsz: 0x0001ed18
Loading Segment: addr: 0x0ff51580 memsz: 0x0048 filesz: 
0x0048
Jumping to boot code at 0x10a2b0
FILO version 0.5 ([EMAIL PROTECTED]) Thu Nov  1 08:23:45 MST 2007
menu: hda1:/boot/filo/menu.lst
hda: LBA48 4295MB: Advanced Micro Devices HDD Device.
Mounted fat
File not found
Press any key to continue.
Press any key to continue.
Press any key to continue.

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> On 09/11/07 17:00 -0700, Myles Watson wrote:
> >
> > It complains the first time because it's trying to copy the payload to a
> > directory that doesn't exist yet (the LinuxBIOS build directory) because
> in
> > my Config.lb I made it use serengeti_cheetah-x86_64.  Either the config
> or
> > the BUILD_DIR variable needs to change.
> 
> Is there a reason for this - are you building both architectures at the
> same
> time?  That hasn't really been our model in the past - but if its
> compelling,
> we can make it happen (there are lots of config options that make
> assumptions
> about where the code lives).

It seemed simple to do (Just the BUILD_DIR option needed to be set), but
it's not important. I was thinking that it would make testing easier.

> 
> I'll make the other changes.
> 

Thanks,
Myles


> Jordan
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Complete and generic 32bit/64bit support

[Myles Watson]

Jordan,

I like it.  It's much cleaner.

It doesn't build my 64-bit Serengeti Cheetah yet because of the UCLIBC_VER,
which needs to be 0.9.29

It also needs to choose KERNEL_VERSION 2.6.22.2 for LAB when it's 64-bit.

The tiny patches don't get applied for the kernel anymore, which adds 25K

I know this is picky, but I meant to include iso9660 support too (here's the
new defconfig file attached

It also looks like the
packages/busybox/conf/defconfig-serengeti_cheetah-x86_64 didn't make it in
the patch

It complains the first time because it's trying to copy the payload to a
directory that doesn't exist yet (the LinuxBIOS build directory) because in
my Config.lb I made it use serengeti_cheetah-x86_64.  Either the config or
the BUILD_DIR variable needs to change.

Same thing about serengeti_cheetah.rom.  In my Config.lb I left it
linuxbios.rom

I haven't tested the final image, but it builds now.

Myles



defconfig-serengeti_cheetah-x86_64
Description: Binary data
-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] #35: Make it possible to boot Windowsusing LinuxBIOS

[Myles Watson]

Here's a new patch which changes the loader (adds a new one) and the
Makefile so that you can have a 4K loader to keep things page aligned.
 I'm also including a new elf header which is updated to use the 4K
loader.  It needs to be put in ADLO/elf/

This allows me to use kexec to load ADLO.

It still isn't working completely, but without this patch kexec
complains that it can't use an elf that isn't page aligned.

Signed-off-by: Myles Watson <[EMAIL PROTECTED]>


elf-header-068kb.payload
Description: Binary data
Index: loader4K.s
===
--- loader4K.s	(revision 0)
+++ loader4K.s	(revision 0)
@@ -0,0 +1,467 @@
+;*
+; $Id: loader.s,v 1.1 2002/11/25 02:07:53 rminnich Exp $
+;*
+USE32
+; code it is loaded into memory at 0x7000
+;*
+nop
+nop
+;*
+; A) setup GDT, so that we do not depend on program 
+; that loaded us for GDT. 
+; Ex: LinuxBIOS and EtherBOOT use different GDT's.
+
+;-
+; 0)
+
+cli
+
+;-
+; I)
+
+lgdt [0x7000+protected_gdt]
+
+;-
+; II) setup CS
+
+jmp 0x08:0x7000+newpgdt
+
+newpgdt: nop
+
+;-
+; III) setup all other segments
+
+mov ax,  #0x10
+mov ss,  ax
+mov ds,  ax
+mov es,  ax
+mov fs,  ax
+mov gs,  ax
+
+;-
+; IV) 
+
+; not now
+;sti
+
+;*
+nop
+nop
+;*
+; B) shadow - ON (enable/read/write)
+
+mov eax, #0x8070
+mov dx,  #0x0cf8
+out dx,  eax
+
+mov eax, #0x
+mov dx,  #0x0cfc
+out dx,  eax
+
+;*
+nop
+nop
+;*
+; C) copy -- boch bios
+
+; counter - 64kb. 
+mov ecx, #0x1
+
+; source - 0x8000  ( 0x7000+0x1000 = 0x8000 ) 
+mov ax,  #0x10; src-segment - 2nd entry in GDT
+mov ds,  ax
+mov eax, #0x8000  ; src-offset  - 0x8000
+mov esi, eax
+
+; destination - 0xE
+mov ax,  #0x10; dst-segment - 2nd entry in GDT
+mov es,  ax 
+mov eax, #0xF ; dst-offset  - 0xF
+mov edi, eax
+
+; clear direction flag
+cld
+
+; the copy
+rep
+  movsb
+
+;*
+nop
+nop
+;*
+; X) copy -- LinuxBIOS table into safe place.
+
+	;; TODO.
+	;; Q1 :	 what is the size of table.
+	;; Q2 :	 where to copy?
+		
+;*
+nop
+nop	
+;*
+; E) shadow - OFF (write)
+
+mov eax, #0x8070
+mov dx,  #0x0cf8
+out dx,  eax
+
+;mov eax, #0x
+mov eax, #0x
+mov dx,  #0x0cfc
+out dx,  eax
+
+;*
+nop
+nop
+;*
+; F) do a little prep work.
+
+;-
+; I) disable cache
+
+; if you disable cache, GRUB's GFX mode will be VERY slow.
+; so DO NOT DISABLE
+
+;mov eax, cr0
+;or  eax, #0x6000
+;wbinvd
+;mov cr0, eax
+;wbinvd
+
+;-
+; II) disable MTRR
+; clear the "E" (0x800) and "FE" (0x400) flags in 
+; IA32_MTRRdefType register (0x2FF)
+
+;---
+
+;mov ECX,#0x2FF
+
+; select either of the two below 
+; depending on if your compiler suports 
+; {RD,WR}MSR or not
+;rdmsr
+; .byte 0x0F, 0x32
+
+;xor edx, edx
+; xor eax, eax
+;and eax, #0xF3FF
+
+; select either of the two below 
+; depending on if your compiler suports 
+; {RD,WR}MSR or not
+;wrmsr
+; .byte 0x0F, 0x30
+
+;---
+;; This is what PC BIOS is setting. -- P6STMT.
+; add VIDEO BIOS cacheable
+;---
+; Fixed Range C0--C8
+;mov ECX,#0x268
+;mov EDX,#0x05050505 
+;mov EAX,#0x05050505 
+;wrmsr
+;---
+; Fixed Range C8--CF
+;mov ECX,#0x269
+;mov EDX,#0x0 
+;mov EAX,#0x05050505 
+;wrmsr
+;---
+
+;-
+; III) tell BOCHS' BIOS we want to boot from hdd.
+; 0x00 - floppy
+; 0x02 - hdd
+; It's changed now //With El Torito enabled
+; 0x0 - none
+; 0x1 - floppy
+; 0x2 - hdd
+; 0x3 - cdrom
+; i.e., 0x23 means try the cdrom first, then the hdd
+; In future there will be 'fd failover'option in bochs.
+
+mov  al, #0x3d ;; cmos_reg
+out  0x70, al
+mov  al, #0x23 ;; val (cd then hdd)
+out  0x71, al
+
+;-
+; IV) tell BOCHS' BIOS l

Re: [LinuxBIOS] Which svn revision works with VIA EPIA M-II?

[Myles Watson]

I forgot a couple of things:

 

> > option ROM_SIZE=256*1024

  You need something like this:

 

option ROM_SIZE=256*1024-64*1024  # This assumes a 64K video BIOS

 

> The reason that they're different is that 12*65536 != 790528

> 

> You should check the first few bytes of a video ROM to look for the 

> signature (AA55)

 

Use 

  hexdump | head

  or view it in a hex editor.

 

> 

> You can also use strings. The ROMs I've seen have some recognizable 

> strings in them.

 

Note that this needs to be coupled with looking for the signature to make
sure that you're starting in the right place.

 

Hopefully when you build you'll have a (256-64)*1024 = 192K image that you
can prepend your 64K Video BIOS to.

 

Myles

 

 

-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Which svn revision works with VIA EPIA M-II?

[Myles Watson]

This may not fix everything, but it should help.
Myles

> Coquelicot
> Sent: Friday, November 09, 2007 11:52 AM
> To: linuxbios@linuxbios.org
> Subject: [LinuxBIOS] Which svn revision works with VIA EPIA M-II?
> 
> Hi guys,
> 
> I finally have spare ROM chips to play with and I am ready to put
> LinuxBIOS on them - I have problems with compiling the beast, however.
> I have checkied out the latest revision from SVN and here's what I'm
> getting when trying to compile:
> 
> 
> 
> --- CUT 
> 
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
> /home/luke/src/carpc-project/LinuxBIOSv2/src/config/linuxbios_ram.ld
> linuxbios_ram.o
> nm -n linuxbios_ram | sort > linuxbios_ram.map
> objcopy --gap-fill 0xff -O binary linuxbios_ram linuxbios_ram.bin
> gcc -O2 -DENCODE -DDECODE -DMAIN -DVERBOSE -DNDEBUG -DBITSIZE=32
> -DENDIAN=0 /home/luke/src/carpc-project/LinuxBIOSv2/util/nrv2b/nrv2b.c
> -o nrv2b
> ./nrv2b e linuxbios_ram.bin linuxbios_ram.nrv2b
> input/output = 64748/29627 = 2.185
> cp linuxbios_ram.nrv2b linuxbios_ram.rom
> echo '/*ldoptions*/' > ldscript.ld; cat ldoptions >> ldscript.ld ; for
> file in  /home/luke/src/carpc-
> project/LinuxBIOSv2/src/arch/i386/init/ldscript_fallback.lb
> /home/luke/src/carpc-project/LinuxBIOSv2/src//cpu/x86/16bit/entry16.lds
> /home/luke/src/carpc-project/LinuxBIOSv2/src//cpu/x86/32bit/entry32.lds
> /home/luke/src/carpc-project/LinuxBIOSv2/src//cpu/x86/16bit/reset16.lds
> /home/luke/src/carpc-project/LinuxBIOSv2/src//arch/i386/lib/id.lds
> /home/luke/src/carpc-project/LinuxBIOSv2/src//arch/i386/lib/failover.lds
> ; do echo /\* $file \*/ >> ldscript.ld; cat $file >> ldscript.ld ;
> done
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> /usr/bin/ld: warning: dot moved backwards before `.reset'
> /usr/bin/ld: warning: dot moved backwards before `.id'
> /usr/bin/ld: warning: dot moved backwards before `.id'
> /usr/bin/ld: warning: dot moved backwards before `.id'
> /usr/bin/ld: section .id [ffd9 -> ffef]
> overlaps section .rom [b3bf -> 0001192f]
> /usr/bin/ld: linuxbios: section .id lma 0xffd9 overlaps previous
> sections
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> make[1]: Leaving directory
> `/home/luke/src/carpc-project/LinuxBIOSv2/targets/via/epia-m/epia-
> m/fallback'
> make: *** [fallback/linuxbios.rom] Error 1
> 
> --- CUT 
> 
> Here's my Config.lb:
> 
> 
> --- CUT 
> 
> # Sample config file for EPIA-M
> # This will make a target directory of ./epia-m
> 
> target epia-m
> 
> mainboard via/epia-m
> 
> option  MAXIMUM_CONSOLE_LOGLEVEL=8
> option  DEFAULT_CONSOLE_LOGLEVEL=8
> option  CONFIG_CONSOLE_SERIAL8250=1
> 
> option ROM_SIZE=256*1024
> option HAVE_OPTION_TABLE=1
> option CONFIG_ROM_PAYLOAD=1
> option HAVE_FALLBACK_BOOT=1
> 
> ###
> ### Compute the location and size of where this firmware image
> ### (linuxBIOS plus bootloader) will live in the boot rom chip.
> ###
> option FALLBACK_SIZE=0x18000

  option FALLBACK_SIZE=ROM_SIZE

> 
> ## LinuxBIOS C code runs at this location in RAM
> option _RAMBASE=0x4000
> 
> ###
> ### Compute the start location and size size of
> ### The linuxBIOS bootloader.
> ###
> 


Take out this section, because you don't want to build "normal" anymore.
> #
> # EPIA-M
> #
> romimage "normal"
> option USE_FALLBACK_IMAGE=0
> option ROM_IMAGE_SIZE=0xc000
> option ROM_SECTION_OFFSET=0x1
> option ROM_SECTION_SIZE=0x18000
> option LINUXBIOS_EXTRA_VERSION=".0-Normal"
> payload $(HOME)/src/carpc-project/filo-0.5/filo.elf
> end
> 


> romimage "fallback"
> option USE_FALLBACK_IMAGE=1
> option ROM_IMAGE_SIZE=0xc000
> option LINUXBIOS_EXTRA_VERSION=".0-Fallback"
> payload $(HOME)/src/carpc-project/filo-0.5/filo.elf
> end
> 
> #buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
> buildrom ./linuxbios.rom ROM_SIZE "fallback"
> 
> 
> --- CUT 
> 
> I have commented out the normal build because I want to prepend
> original VGA BIOS from the board to LinuxBIOS and I guess the fallback
> one is the right one to use (at least according to LinuxBIOS
> documentation (documentation/HOWTO/EPIA-M-howto). This file also
> states how to get the VGA bios:
> 
> dd if=/dev/mem of=/video.bios.bin \
>bs=1 count=65536 skip=790528
> 
> while Confirmed working SVN revisions at
> 
>   http://www.linuxbios.org/index.php/Confirmed_working_svn_revisions
> 
> says something different:
> 
> dd if=/dev/mem of=video.bios.bin.4 bs=65536 count=1 skip=12
> 
> (I have checked that generated files differ)

The reason that they're different is that 12*65536 != 790528

You should check the first few bytes of a video ROM to look for the
signature (AA55)

You can also use strings. The ROMs I've seen have some recognizable strings
in them.

Re: [LinuxBIOS] Add support for the AMD SimNow (TM) simulator

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 09, 2007 1:32 PM
> To: Myles Watson
> Cc: linuxbios@linuxbios.org
> Subject: Re: Add support for the AMD SimNow (TM) simulator
> 
> On 09/11/07 13:26 -0700, Myles Watson wrote:
> > > -Original Message-
> > > From: Jordan Crouse [mailto:[EMAIL PROTECTED]
> > >
> > > It will reset once - it shouldn't reset repeatedly (doesn't on my
> > > test setup).  I haven't tried the public version yet, I'll do that.
> > > The issue is on the non-coherent devices - the coherent ones should
> > > optimize correctly - if they don't, thats a way bigger problem.
> >
> > It continuously reset for me.  It seems to work fine with a LAB payload
> with
> > the soft_reset commented out.
> 
> what version of SimNow are you using, and what BSD?

4.4.1 cheetah_1p.bsd

When I use cheetah_1p_jh.bsd it works.

Myles

> 
> > > > I haven't run into the other issues (beside the reset), so I don't
> > > > know how to test them.
> > >
> > > If it boots quickly, then you don't hit the other problem.  If the
> > > thing grinds to a halt then you hit it.
> >
> > Maybe that's related to the single reset?
> 
> No, it has to do with CAR issues on multiple nodes - you might not hit it
> if you only have 1 processor x 1 core.
> 
> --
> Jordan Crouse
> Systems Software Development Engineer
> Advanced Micro Devices, Inc.



-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] Add support for the AMD SimNow (TM) simulator

[Myles Watson]

> -Original Message-
> From: Jordan Crouse [mailto:[EMAIL PROTECTED]
>
> It will reset once - it shouldn't reset repeatedly (doesn't on my
> test setup).  I haven't tried the public version yet, I'll do that.
> The issue is on the non-coherent devices - the coherent ones should
> optimize correctly - if they don't, thats a way bigger problem.

It continuously reset for me.  It seems to work fine with a LAB payload with
the soft_reset commented out.

> > I haven't run into the other issues (beside the reset), so I don't
> > know how to test them.
> 
> If it boots quickly, then you don't hit the other problem.  If the
> thing grinds to a halt then you hit it.

Maybe that's related to the single reset?

Myles


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: [LinuxBIOS] [BUILDROM] Add support for the AMD SimNow (TM) simulator

[Myles Watson]

On 11/9/07, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> By popular request, this is a patch to buildrom adding support for
> the AMD SimNow simulator.  Basically, it patches LinuxBIOS to work
> around a few SimNow related quirks that are currently in the
> public version of SimNow.  The quirks themselves have been reported,
> and hopefully will be fixed in future releases.
>
> What is SimNow, and why does it rock, you might ask?  SimNow (TM) is
> a processor simulator that we have developed at AMD.  Its a great way
> to simulate the processor / chipset boot process and develop LinuxBIOS
> and payloads, because it features an integrated debugger, and its easy
> to fix when you brick the thing (just hit reset).  There is a public
> version here:
>
> http://developer.amd.com/simnow.jsp
>
> For the more commercial customers out there, there is also a NDA
> version that has support for more processors (contact your friendly
> AMD representative for more information).  I'll put this information
> on the wiki as well, for posterity.
>
> Myles and other SimNow users - let me know if this works.

It doesn't work for me yet.
1. It still resets (I comment out the actual soft reset, not the
needs_reset calculation when I do it)
2. You modify generic-linuxbios.mk instead of a specific one for the
target (see my earlier patch)
3.  I'd like it if it depended on either serengeti-cheetah config
option (also in the earlier patch)

I also commented inline with the patch if it's more clear.

I haven't run into the other issues (beside the reset), so I don't
know how to test them.

Thanks,
Myles

> Thanks,
> Jordan
>
>
>
>
> [BUILDROM] Add support for the AMD SimNow (TM) simulator
>
> Add a build option and a patch against LinuxBIOS to allow the
> Serengeti-Cheetah platform to come up on its emulated self in
> the SimNow simulator.
>
> Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
>
> Index: buildrom-devel/config/platforms/Config.in
> ===
> --- buildrom-devel.orig/config/platforms/Config.in
> +++ buildrom-devel/config/platforms/Config.in
> @@ -81,4 +81,13 @@ config PLATFORM_SERENGETI_CHEETAH
> depends VENDOR_AMD
> select PLATFORM
>  endchoice
> +
> +config SIMNOW
> +   bool "Build for the AMD SimNow (TM) emulator"
> +   depends PLATFORM_SERENGETI_CHEETAH

How about:
+   depends PLATFORM_SERENGETI_CHEETAH | PLATFORM_SERENGETI_CHEETAH_64
To let mine use the same option

> +   default n
> +   help
> + Say 'y' here to patch the build to work on an
> + emulated platform in the AMD SimNow (TM) simulator
> +
>  endmenu
> Index: buildrom-devel/packages/linuxbios/generic-linuxbios.mk

Should modify specific linuxbios.mk file

===
> --- buildrom-devel.orig/packages/linuxbios/generic-linuxbios.mk
> +++ buildrom-devel/packages/linuxbios/generic-linuxbios.mk
> @@ -21,6 +21,10 @@ endif
>
>  LINUXBIOS_PATCHES += 
> $(PACKAGE_DIR)/linuxbios/patches/s-c-buildrom-payload.patch
>
> +ifeq ($(CONFIG_SIMNOW),y)
> +LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/simnow.patch
> +endif
> +
>  include $(PACKAGE_DIR)/linuxbios/linuxbios.inc
>
>  $(SOURCE_DIR)/$(LINUXBIOS_TARBALL):
> Index: buildrom-devel/packages/linuxbios/patches/simnow.patch
> ===
> --- /dev/null
> +++ buildrom-devel/packages/linuxbios/patches/simnow.patch
> @@ -0,0 +1,59 @@
> +Index: svn/src/northbridge/amd/amdk8/raminit_f_dqs.c
> +===
> +--- svn.orig/src/northbridge/amd/amdk8/raminit_f_dqs.c
>  svn/src/northbridge/amd/amdk8/raminit_f_dqs.c
> +@@ -1987,6 +1987,16 @@ static inline void train_ram_on_node(uns
> +   struct sys_info *sysinfox = ((CONFIG_LB_MEM_TOPK<<10) - 
> DCACHE_RAM_GLOBAL_VAR_SIZE);
> +   wait_till_sysinfo_in_ram(); // use pci to get it
> +
> ++  /* In SimNow, when we get to this point, CAR is disabled, so
> ++   * our stack pointer points to never-never land, andjust it.
> ++   */
> ++
> ++  __asm__ volatile (
> ++  "subl   %0, %%ebp\n\t"
> ++  "subl   %0, %%esp\n\t"
> ++  ::"a"( (DCACHE_RAM_BASE + DCACHE_RAM_SIZE)- 
> (CONFIG_LB_MEM_TOPK<<10) )
> ++  );
> ++
> +   if(sysinfox->mem_trained[nodeid] == 0x80) {
> +   #if 0
> +   sysinfo->tom_k = sysinfox->tom_k;
> +Index: svn/src/mainboard/amd/serengeti_cheetah/Options.lb
> +===
> +--- svn.orig/src/mainboard/amd/serengeti_cheetah/Options.lb
>  svn/src/mainboard/amd/serengeti_cheetah/Options.lb
> +@@ -218,7 +218,7 @@ default CONFIG_USE_INIT=0
> + ##
> + ## for rev F training on AP purpose
> + ##
> +-default CONFIG_AP_CODE_IN_CAR=1
> ++default CONFIG_AP_CODE_IN_CAR=0
> + default MEM_TRAIN_SEQ=1
> + default WAIT_BEFORE_CPUS_INIT=1
> +
> +Index: svn/src/mainboa

Re: [LinuxBIOS] [PATCH] many trivial patches

[Myles Watson]

> > This adds the same line (uses CONFIG_PRECOMPRESSED_PAYLOAD) to every
> > Options.lb file that already had a "uses
> > CONFIG_COMPRESSED_PAYLOAD_LZMA" line in it.
> 
> If I understood correctly there should be a corresponding
> default CONFIG_PRECOMPRESSED_PAYLOAD x
> 
> line in the target/ Options.lb files.

None of the architectures have a default CONFIG_PRECOMPRESSED_PAYLOAD.

Since "uses CONFIG_PRECOMPRESSED_PAYLOAD" allows you to use the option, but
doesn't force it, I don't think you need the default line.  It might be
better style. There are a lot of CONFIG_... options that don't have defaults
in the Options.lb files, though.

Myles


-- 
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios