[LinuxBIOS] Merge complete....

Ok.  After I finally developed a sane common ancestor between
the two trees it did not take much time to finish the merge.
> From that ancestor [e-mail]--devel/frebios--devel--2.0--base-0

I have merged each patch individually with star-merge and that worked
well allowing me to fix the small handful of conflicts that the new
development created.

I would love to move the changes into the public tree the same way but it does
not appear easily possible, instead it is trivial to simply merge my entire
tree into the public tree.

Since I want to avoid breaking things by acting too hastily I have
performed the merge and placed the code in the branch:
 [e-mail]--devel/freebios--lnxi--1--patch-1

If no one has any real objections after looking at it I will merge with
the main branch.  Otherwise I will listen to the objections and see
where I go from there.

Eric

[Ronald G. Minnich]

thanks Eric. Please don't do a real merge until we have positive 
confirmation from people that it will be ok.

thanks

ron

[Li-Ta Lo]

On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> Ok.  After I finally developed a sane common ancestor between
> the two trees it did not take much time to finish the merge.
> > From that ancestor [e-mail]--devel/frebios--devel--2.0--base-0
>
> I have merged each patch individually with star-merge and that worked
> well allowing me to fix the small handful of conflicts that the new
> development created.
>
> I would love to move the changes into the public tree the same way but it does
> not appear easily possible, instead it is trivial to simply merge my entire
> tree into the public tree.
>
> Since I want to avoid breaking things by acting too hastily I have
> performed the merge and placed the code in the branch:
>  [e-mail]--devel/freebios--lnxi--1--patch-1

How am I going to check out that branch?

[ollie@logarithm tmp]$ tla get [e-mail]--devel/freebios--
lxni--1 freebios_lxni
No such package (freebios--lxni)
  name: [e-mail]--devel
  location:
sftp://[e-mail]/srv/arch/[e-mail]--devel
  package-version: freebios--lxni--1

Do I have to "tla register archive" or something?

[Li-Ta Lo]

On Wed, 2005-06-22 at 09:33 -0600, Li-Ta Lo wrote:
> On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> > Ok.  After I finally developed a sane common ancestor between
> > the two trees it did not take much time to finish the merge.
> > > From that ancestor [e-mail]--devel/frebios--devel--2.0--base-0
> >
> > I have merged each patch individually with star-merge and that worked
> > well allowing me to fix the small handful of conflicts that the new
> > development created.
> >
> > I would love to move the changes into the public tree the same way but it does
> > not appear easily possible, instead it is trivial to simply merge my entire
> > tree into the public tree.
> >
> > Since I want to avoid breaking things by acting too hastily I have
> > performed the merge and placed the code in the branch:
> >  [e-mail]--devel/freebios--lnxi--1--patch-1
>
> How am I going to check out that branch?
>
> [ollie@logarithm tmp]$ tla get [e-mail]--devel/freebios--
> lxni--1 freebios_lxni
> No such package (freebios--lxni)
>   name: [e-mail]--devel
>   location:
> sftp://[e-mail]/srv/arch/[e-mail]--devel
>   package-version: freebios--lxni--1
>
> Do I have to "tla register archive" or something?

Sorry, it a typo.

Li-Ta Lo  writes:
> How am I going to check out that branch?
>
> [ollie@logarithm tmp]$ tla get [e-mail]--devel/freebios--lxni--1 freebios_lxni
> No such package (freebios--lxni)
>   name: [e-mail]--devel
>   location:
> sftp://[e-mail]/srv/arch/[e-mail]--devel
>   package-version: freebios--lxni--1
>
> Do I have to "tla register archive" or something?

The following just worked for me:
 tla get [e-mail]--devel/freebios--lnxi--1

so I think there is some subtle typo somewhere that
was causing you problems.

The first time I tried it. I had a failure as well.  But I
can't see anything wrong :(

Ok.  It looks like you just came to the same conclusion.

Eric

[Ronald G. Minnich]

On Wed, 22 Jun 2005, Li-Ta Lo wrote:
> On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> > Ok.  After I finally developed a sane common ancestor between
> > the two trees it did not take much time to finish the merge.
> > > From that ancestor [e-mail]--devel/frebios--devel--2.0--base-0
> >
> > I have merged each patch individually with star-merge and that worked
> > well allowing me to fix the small handful of conflicts that the new
> > development created.
> >
> > I would love to move the changes into the public tree the same way but it does
> > not appear easily possible, instead it is trivial to simply merge my entire
> > tree into the public tree.
> >
> > Since I want to avoid breaking things by acting too hastily I have
> > performed the merge and placed the code in the branch:
> >  [e-mail]--devel/freebios--lnxi--1--patch-1
>
> How am I going to check out that branch?
>
> [ollie@logarithm tmp]$ tla get [e-mail]--devel/freebios--
> lxni--1 freebios_lxni

lnxi

not lxni

ron

[yhlu]

At last Eric put the E7520 to the public....

YH

On 6/22/05, Ronald G. Minnich  wrote:
> On Wed, 22 Jun 2005, Li-Ta Lo wrote:
> > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> > > Ok.  After I finally developed a sane common ancestor between
> > > the two trees it did not take much time to finish the merge.
> > > > From that ancestor [e-mail]--devel/frebios--devel--2.0--base-0
> > >
> > > I have merged each patch individually with star-merge and that worked
> > > well allowing me to fix the small handful of conflicts that the new
> > > development created.
> > >
> > > I would love to move the changes into the public tree the same way but it does
> > > not appear easily possible, instead it is trivial to simply merge my entire
> > > tree into the public tree.
> > >
> > > Since I want to avoid breaking things by acting too hastily I have
> > > performed the merge and placed the code in the branch:
> > >  [e-mail]--devel/freebios--lnxi--1--patch-1
> >
> > How am I going to check out that branch?
> >
> > [ollie@logarithm tmp]$ tla get [e-mail]--devel/freebios--
> > lxni--1 freebios_lxni
>               lnxi
>
> not lxni
>
> ron
>
> LinuxBIOS mailing list
> [e-mail]
> http://www.openbios.org/mailman/listinfo/linuxbios

[Li-Ta Lo]

On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> Since I want to avoid breaking things by acting too hastily I have
> performed the merge and placed the code in the branch:
>  [e-mail]--devel/freebios--lnxi--1--patch-1
>
> If no one has any real objections after looking at it I will merge with
> the main branch.  Otherwise I will listen to the objections and see
> where I go from there.

First pass of objections, I think these files are cvs/tla removed (by 
you?) long time ago?

New-files:
    src/mainboard/Iwill/DK8S2/debug.c
    src/mainboard/Iwill/DK8S2/reset.c
    src/mainboard/Iwill/DK8X/debug.c
    src/mainboard/Iwill/DK8X/reset.c
    src/mainboard/amd/quartet/debug.c
    src/mainboard/amd/quartet/reset.c
    src/mainboard/amd/serenade/reset.c
    src/mainboard/amd/solo/debug.c
    src/mainboard/amd/solo/reset.c
    src/mainboard/arima/hdama/debug.c
    src/mainboard/arima/hdama/reset.c
    src/mainboard/ibm/e325/reset.c
    src/mainboard/newisys/khepri/debug.c
    src/mainboard/newisys/khepri/reset.c
    src/mainboard/tyan/s2735/reset.c
    src/mainboard/tyan/s2850/adaptec_scsi.c
    src/mainboard/tyan/s2850/broadcom_nic.c
    src/mainboard/tyan/s2850/debug.c
    src/mainboard/tyan/s2850/hypertransport.c
    src/mainboard/tyan/s2850/intel_nic.c
    src/mainboard/tyan/s2850/promise_sata.c
    src/mainboard/tyan/s2850/reset.c
    src/mainboard/tyan/s2875/reset.c
    src/mainboard/tyan/s2880/adaptec_scsi.c
    src/mainboard/tyan/s2880/debug.c
    src/mainboard/tyan/s2880/hypertransport.c
    src/mainboard/tyan/s2880/intel_nic.c
    src/mainboard/tyan/s2880/promise_sata.c
    src/mainboard/tyan/s2880/reset.c
    src/mainboard/tyan/s2880/tyan-fallback.config
    src/mainboard/tyan/s2880/tyan-normal.config
    src/mainboard/tyan/s2881/adaptec_scsi.c
    src/mainboard/tyan/s2881/debug.c
    src/mainboard/tyan/s2881/hypertransport.c
    src/mainboard/tyan/s2881/intel_nic.c
    src/mainboard/tyan/s2881/reset.c
    src/mainboard/tyan/s2881/si_sata.c
    src/mainboard/tyan/s2882/adaptec_scsi.c
    src/mainboard/tyan/s2882/debug.c
    src/mainboard/tyan/s2882/hypertransport.c
    src/mainboard/tyan/s2882/intel_nic.c
    src/mainboard/tyan/s2882/reset.c
    src/mainboard/tyan/s2882/si_sata.c
    src/mainboard/tyan/s2882/tyan-fallback.config
    src/mainboard/tyan/s2882/tyan-normal.config
    src/mainboard/tyan/s2885/adaptec_scsi.c
    src/mainboard/tyan/s2885/broadcom_nic.c
    src/mainboard/tyan/s2885/debug.c
    src/mainboard/tyan/s2885/hypertransport.c
    src/mainboard/tyan/s2885/intel_nic.c
    src/mainboard/tyan/s2885/reset.c
    src/mainboard/tyan/s2885/si_sata.c
    src/mainboard/tyan/s2885/ti_firewire.c
    src/mainboard/tyan/s2885/tyan-fallback.config
    src/mainboard/tyan/s2885/tyan-normal.config
    src/mainboard/tyan/s4880/adaptec_scsi.c
    src/mainboard/tyan/s4880/debug.c
    src/mainboard/tyan/s4880/hypertransport.c
    src/mainboard/tyan/s4880/intel_nic.c
    src/mainboard/tyan/s4880/reset.c
    src/mainboard/tyan/s4880/si_sata.c
    src/mainboard/tyan/s4882/reset.c

[Li-Ta Lo]

On Wed, 2005-06-22 at 11:42 -0600, Li-Ta Lo wrote:
> On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> > Since I want to avoid breaking things by acting too hastily I have
> > performed the merge and placed the code in the branch:
> >  [e-mail]--devel/freebios--lnxi--1--patch-1
> >
> > If no one has any real objections after looking at it I will merge with
> > the main branch.  Otherwise I will listen to the objections and see
> > where I go from there.
>
> First pass of objections, I think these files are cvs/tla removed (by 
> you?) long time ago?
>
> New-files:
>     src/mainboard/Iwill/DK8S2/debug.c
>     src/mainboard/Iwill/DK8S2/reset.c
>     src/mainboard/Iwill/DK8X/debug.c
>     src/mainboard/Iwill/DK8X/reset.c
>     src/mainboard/amd/quartet/debug.c
>     src/mainboard/amd/quartet/reset.c
>     src/mainboard/amd/serenade/reset.c
>     src/mainboard/amd/solo/debug.c
>     src/mainboard/amd/solo/reset.c
>     src/mainboard/arima/hdama/debug.c
>     src/mainboard/arima/hdama/reset.c
>     src/mainboard/ibm/e325/reset.c
>     src/mainboard/newisys/khepri/debug.c
>     src/mainboard/newisys/khepri/reset.c
>     src/mainboard/tyan/s2735/reset.c
>     src/mainboard/tyan/s2850/adaptec_scsi.c
>     src/mainboard/tyan/s2850/broadcom_nic.c
>     src/mainboard/tyan/s2850/debug.c
>     src/mainboard/tyan/s2850/hypertransport.c
>     src/mainboard/tyan/s2850/intel_nic.c
>     src/mainboard/tyan/s2850/promise_sata.c
>     src/mainboard/tyan/s2850/reset.c
>     src/mainboard/tyan/s2875/reset.c
>     src/mainboard/tyan/s2880/adaptec_scsi.c
>     src/mainboard/tyan/s2880/debug.c
>     src/mainboard/tyan/s2880/hypertransport.c
>     src/mainboard/tyan/s2880/intel_nic.c
>     src/mainboard/tyan/s2880/promise_sata.c
>     src/mainboard/tyan/s2880/reset.c
>     src/mainboard/tyan/s2880/tyan-fallback.config
>     src/mainboard/tyan/s2880/tyan-normal.config
>     src/mainboard/tyan/s2881/adaptec_scsi.c
>     src/mainboard/tyan/s2881/debug.c
>     src/mainboard/tyan/s2881/hypertransport.c
>     src/mainboard/tyan/s2881/intel_nic.c
>     src/mainboard/tyan/s2881/reset.c
>     src/mainboard/tyan/s2881/si_sata.c
>     src/mainboard/tyan/s2882/adaptec_scsi.c
>     src/mainboard/tyan/s2882/debug.c
>     src/mainboard/tyan/s2882/hypertransport.c
>     src/mainboard/tyan/s2882/intel_nic.c
>     src/mainboard/tyan/s2882/reset.c
>     src/mainboard/tyan/s2882/si_sata.c
>     src/mainboard/tyan/s2882/tyan-fallback.config
>     src/mainboard/tyan/s2882/tyan-normal.config
>     src/mainboard/tyan/s2885/adaptec_scsi.c
>     src/mainboard/tyan/s2885/broadcom_nic.c
>     src/mainboard/tyan/s2885/debug.c
>     src/mainboard/tyan/s2885/hypertransport.c
>     src/mainboard/tyan/s2885/intel_nic.c
>     src/mainboard/tyan/s2885/reset.c
>     src/mainboard/tyan/s2885/si_sata.c
>     src/mainboard/tyan/s2885/ti_firewire.c
>     src/mainboard/tyan/s2885/tyan-fallback.config
>     src/mainboard/tyan/s2885/tyan-normal.config
>     src/mainboard/tyan/s4880/adaptec_scsi.c
>     src/mainboard/tyan/s4880/debug.c
>     src/mainboard/tyan/s4880/hypertransport.c
>     src/mainboard/tyan/s4880/intel_nic.c
>     src/mainboard/tyan/s4880/reset.c
>     src/mainboard/tyan/s4880/si_sata.c
>     src/mainboard/tyan/s4882/reset.c

Are these files reversed patch too?

Modified-files:
    src/mainboard/Iwill/DK8S2/Config.lb
    src/mainboard/Iwill/DK8S2/Options.lb
    src/mainboard/Iwill/DK8S2/cmos.layout
    src/mainboard/Iwill/DK8S2/failover.c
    src/mainboard/Iwill/DK8S2/irq_tables.c
    src/mainboard/Iwill/DK8S2/mptable.c
    src/mainboard/Iwill/DK8X/Config.lb
    src/mainboard/Iwill/DK8X/Options.lb
    src/mainboard/amd/quartet/Config.lb
    src/mainboard/amd/quartet/Options.lb
    src/mainboard/amd/serenade/Config.lb
    src/mainboard/amd/serenade/Options.lb
    src/mainboard/amd/solo/Config.lb
    src/mainboard/amd/solo/Options.lb
    src/mainboard/arima/hdama/Config.lb
    src/mainboard/arima/hdama/Options.lb
    src/mainboard/arima/hdama/auto.c
    src/mainboard/arima/hdama/mptable.c
    src/mainboard/emulation/qemu-i386/Options.lb
    src/mainboard/ibm/e325/Config.lb
    src/mainboard/ibm/e325/Options.lb
    src/mainboard/newisys/khepri/Config.lb
    src/mainboard/newisys/khepri/Options.lb
    src/mainboard/tyan/s2735/Config.lb
    src/mainboard/tyan/s2735/Options.lb
    src/mainboard/tyan/s2850/Config.lb
    src/mainboard/tyan/s2850/Options.lb
    src/mainboard/tyan/s2875/Config.lb
    src/mainboard/tyan/s2875/Options.lb
    src/mainboard/tyan/s2880/Config.lb
    src/mainboard/tyan/s2880/Options.lb
    src/mainboard/tyan/s2881/Config.lb
    src/mainboard/tyan/s2881/Options.lb
    src/mainboard/tyan/s2882/Config.lb
    src/mainboard/tyan/s2882/Options.lb
    src/mainboard/tyan/s2882/auto.c
    src/mainboard/tyan/s2882/mptable.c
    src/mainboard/tyan/s2885/Config.lb
    src/mainboard/tyan/s2885/Options.lb
    src/mainboard/tyan/s2885/auto.c
    src/mainboard/tyan/s4880/Config.lb
    src/mainboard/tyan/s4880/Options.lb
    src/mainboard/tyan/s4882/Config.lb
    src/mainboard/tyan/s4882/Options.lb
    src/mainboard/tyan/s4882/auto.c
    src/mainboard/tyan/s4882/chip.h
    src/mainboard/tyan/s4882/failover.c
    src/mainboard/tyan/s4882/mainboard.c

Li-Ta Lo  writes:
> Are these files reversed patch too?

I think it is mostly node_link_to_bus and the like.
I have a DK8S2 (I think) and there were some significant problems
with that port.

Removing HARD_RESET_BUS and the like.

My change history isn't perfect but you have it all and that may
help.  The history of 2 parallel CVS trees what fun.

It may be a good idea to get my act together and push
out my main branch so you can see what pieces everything came in.
Unfortunately there wasn't a true common reference until a couple
of days ago.  Just two parallel trees.

So I think you will find on examination most of these changes are
fairly sane, and not arbitrary code reversions.

Eric

Li-Ta Lo  writes:
> On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote:
> > Since I want to avoid breaking things by acting too hastily I have
> > performed the merge and placed the code in the branch:
> >  [e-mail]--devel/freebios--lnxi--1--patch-1
> >
> > If no one has any real objections after looking at it I will merge with
> > the main branch.  Otherwise I will listen to the objections and see
> > where I go from there.
>
> First pass of objections, I think these files are cvs/tla removed (by 
> you?) long time ago?

Not by me.  Someone realized the code in reset.c was very similar
and made a common factor that wasn't truly common or generic, and
there were cases where the code would not work but we didn't have
a choice not to use it.  So in reset.c I removed the common factor
and put reset.c back.  It is now a single motherboard dependent
function call but it is general.

debug.c could go in a lot of cases but I don't quite find a generic
debug.c for a northbridge persuasive either.  At least on the boards
I am messing with I wrote debug.c to get my local debugging hacks
out of the mainline of the code.  And my debug.c continuted to mutate.
But everyone doesn't need one, and arguably production code could
do completely without one.

The rest may indeed be files someone else deleted that I missed.

Eric