New IXP4XX-based Machine

New IXP4XX-based Machine

[Mark Gollahon]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

Hello!

As I have stated before, I am a bit new, so please bear with me.

I am trying to bring up OE on a new IXP4XX-based machine and having a little trouble with the "proper" way to do it.  For example, I created a whole new machine config, inserting what I think should be machine-specific settings, and importing the (now somewhat-defunct) ixp4xx.conf configuration (and later the ixp4xxbe.conf configuration).  My bootstrap-image gets everything compiled, but when it goes to build the rootfs, ipkg fails looking for task-base.

My question is not so much about getting ipkg to work (I have found several ways), but more about the "proper" way so that I don't go "spinning into the grass" in the future.  I noticed that during the rootfs build that the "ixp4xxbe" "arch" was not in the ipkg config file, so all of my "*_ixp4xxbe.ipk" files were completely ignored - stuff like "task-base"!  I ultimately had to append "armv5te" and "ixp4xxbe" to PACKAGE_EXTRA_ARCHS and that worked, but I worked on this on-and-off for over a week to figure it out.  I really don't want to do that again when/if I try to bring up another machine.

My question is - should I even be attempting to define a new machine and including ixp4xxbe.conf in it?  Should I define my own machine by copying the contents of ixp4xxbe.conf?  Should I have specified the "ixp4xxbe" machine file in my local.conf along with the extra (what I think should be) machine config?  Or should I define my own distro and put that machine config there?  What is the most appropriate way to do this?

Thank you!
-Mark Gollahon

Re: New IXP4XX-based Machine

[Rod Whitby]

Mark Gollahon wrote:
> I am trying to bring up OE on a new IXP4XX-based machine and having a
> little trouble with the "proper" way to do it.  For example, I
> created a whole new machine config, inserting what I think should be
> machine-specific settings, and importing the (now somewhat-defunct)
> ixp4xx.conf configuration (and later the ixp4xxbe.conf
> configuration).  My bootstrap-image gets everything compiled, but
> when it goes to build the rootfs, ipkg fails looking for task-base.
> 
> My question is not so much about getting ipkg to work (I have found
> several ways), but more about the "proper" way so that I don't go
> "spinning into the grass" in the future.  I noticed that during the
> rootfs build that the "ixp4xxbe" "arch" was not in the ipkg config
> file, so all of my "*_ixp4xxbe.ipk" files were completely ignored -
> stuff like "task-base"!  I ultimately had to append "armv5te" and
> "ixp4xxbe" to PACKAGE_EXTRA_ARCHS and that worked, but I worked on
> this on-and-off for over a week to figure it out.  I really don't
> want to do that again when/if I try to bring up another machine.

That was a bug in the newly rewritten ixp4xx conf which I believe is now
fixed.

> My question is - should I even be attempting to define a new machine
> and including ixp4xxbe.conf in it?  Should I define my own machine by
> copying the contents of ixp4xxbe.conf?  Should I have specified the
> "ixp4xxbe" machine file in my local.conf along with the extra (what I
> think should be) machine config?  Or should I define my own distro
> and put that machine config there?  What is the most appropriate way
> to do this?

Is there anything specific which means that you can't just use the
ixp4xxbe.conf as it is?

I'm willing to work with you to get this right.

-- Rod

Re: New IXP4XX-based Machine

[Mark Gollahon]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

Rod Whitby wrote ..
> Mark Gollahon wrote:
> > I am trying to bring up OE on a new IXP4XX-based machine and having a
> > little trouble with the "proper" way to do it.  For example, I
> > created a whole new machine config, inserting what I think should be
> > machine-specific settings, and importing the (now somewhat-defunct)
> > ixp4xx.conf configuration (and later the ixp4xxbe.conf
> > configuration).  My bootstrap-image gets everything compiled, but
> > when it goes to build the rootfs, ipkg fails looking for task-base.
> > 
> > My question is not so much about getting ipkg to work (I have found
> > several ways), but more about the "proper" way so that I don't go
> > "spinning into the grass" in the future.  I noticed that during the
> > rootfs build that the "ixp4xxbe" "arch" was not in the ipkg config
> > file, so all of my "*_ixp4xxbe.ipk" files were completely ignored -
> > stuff like "task-base"!  I ultimately had to append "armv5te" and
> > "ixp4xxbe" to PACKAGE_EXTRA_ARCHS and that worked, but I worked on
> > this on-and-off for over a week to figure it out.  I really don't
> > want to do that again when/if I try to bring up another machine.
> 
> That was a bug in the newly rewritten ixp4xx conf which I believe is now
> fixed.

Great!  When was the diff applied?  I'd like to get it.

> > My question is - should I even be attempting to define a new machine
> > and including ixp4xxbe.conf in it?  Should I define my own machine by
> > copying the contents of ixp4xxbe.conf?  Should I have specified the
> > "ixp4xxbe" machine file in my local.conf along with the extra (what I
> > think should be) machine config?  Or should I define my own distro
> > and put that machine config there?  What is the most appropriate way
> > to do this?
> 
> Is there anything specific which means that you can't just use the
> ixp4xxbe.conf as it is?

Right now its not much more than a bunch of MACHINE_EXTRA_RDEPENDS and
MACHINE_EXTRA_RRECOMMENDS settings thanks to your changes.  However, there
is an embedded four-port eth switch chip in the box.  Since the
manufacturer had to patch a number of areas in the Intel drivers to get it
to work originally, I am expecting to have to do the same with the GPL
ixp4xx eth drivers.  That would mean kernel patches, which would probably
mean its own kernel .bb, etc.  From what I've seen of OE, it seems easier
to support a new machine .conf along with its own kernel .bb than trying
to shim a new kernel config in an old machine .conf (oh, BTW, to build for
*this machine*, you have to use *that machine's* .conf file, but make
PREFERRED_PROVIDER_virtual/kernel be *this*).  Newbies are already 
overwhelmed by OE's sheer configurability, throwing yet another exception
in on this just doesn't seem right to me.

> I'm willing to work with you to get this right.

I know - thank you.  I just wish I had discovered what was the issue with
building the root filesys image before now....

Regards,
-Mark Gollahon

Re: New IXP4XX-based Machine

[Rod Whitby]

Mark Gollahon wrote:
> Rod Whitby wrote ..
>> That was a bug in the newly rewritten ixp4xx conf which I believe is now
>> fixed.
> 
> Great!  When was the diff applied?  I'd like to get it.

Probably on Sunday:
Commit by rwhitby on org.oe.dev :: r0e933978... / (26 files in 10 dirs):
ixp4xx-related files: Replaced IXP4XX_MACHINE_ENDIAN with
SITEINFO_ENDIANESS throughout OE, removing all instances of
ixp4xx-specific ENDIAN checks in the OE metadata.

> Right now its not much more than a bunch of MACHINE_EXTRA_RDEPENDS and
> MACHINE_EXTRA_RRECOMMENDS settings thanks to your changes.  However, there
> is an embedded four-port eth switch chip in the box.  Since the
> manufacturer had to patch a number of areas in the Intel drivers to get it
> to work originally, I am expecting to have to do the same with the GPL
> ixp4xx eth drivers.  That would mean kernel patches, which would probably
> mean its own kernel .bb, etc.

Actually, it would be good for you to talk to the GPL ethernet driver
author, and get those patches upstream.

> From what I've seen of OE, it seems easier
> to support a new machine .conf along with its own kernel .bb than trying
> to shim a new kernel config in an old machine .conf (oh, BTW, to build for
> *this machine*, you have to use *that machine's* .conf file, but make
> PREFERRED_PROVIDER_virtual/kernel be *this*).  Newbies are already 
> overwhelmed by OE's sheer configurability, throwing yet another exception
> in on this just doesn't seem right to me.

Agreed.  What's the machine?  Got any internal photos ;-)

>> I'm willing to work with you to get this right.
> 
> I know - thank you.  I just wish I had discovered what was the issue with
> building the root filesys image before now....

Let's work together, and make sure that ixp4xx{be,le}.conf are files
that can be used for (included in) a number of such machine configurations.

-- Rod

Re: New IXP4XX-based Machine

[Mark Gollahon]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

Rod Whitby wrote ..
> Mark Gollahon wrote:
> > Rod Whitby wrote ..
> >> That was a bug in the newly rewritten ixp4xx conf which I
> >> believe is now fixed.
> > 
> > Great!  When was the diff applied?  I'd like to get it.
> 
> Probably on Sunday:
> Commit by rwhitby on org.oe.dev :: r0e933978... / (26 files in 10 dirs):
> ixp4xx-related files: Replaced IXP4XX_MACHINE_ENDIAN with
> SITEINFO_ENDIANESS throughout OE, removing all instances of
> ixp4xx-specific ENDIAN checks in the OE metadata.
> 
> > Right now its not much more than a bunch of MACHINE_EXTRA_RDEPENDS and
> > MACHINE_EXTRA_RRECOMMENDS settings thanks to your changes.  However,
> there
> > is an embedded four-port eth switch chip in the box.  Since the
> > manufacturer had to patch a number of areas in the Intel drivers to get
> it
> > to work originally, I am expecting to have to do the same with the GPL
> > ixp4xx eth drivers.  That would mean kernel patches, which would probably
> > mean its own kernel .bb, etc.
> 
> Actually, it would be good for you to talk to the GPL ethernet driver
> author, and get those patches upstream.

I will once I've determined that patches are necessary.  I'm really hoping they aren't - but I'm not "holding my breath"....

> > From what I've seen of OE, it seems easier
> > to support a new machine .conf along with its own kernel .bb than trying
> > to shim a new kernel config in an old machine .conf (oh, BTW, to build
> for
> > *this machine*, you have to use *that machine's* .conf file, but make
> > PREFERRED_PROVIDER_virtual/kernel be *this*).  Newbies are already 
> > overwhelmed by OE's sheer configurability, throwing yet another exception
> > in on this just doesn't seem right to me.
> 
> Agreed.  What's the machine?  Got any internal photos ;-)

It is an Arlotto SG205.  They also have an SG305, but I don't have access to that machine or know its contents.  However if the mainboard is any indication, its got at least a mini-pci slot more than the SG205.  I'm sending pics along with this message.  Hope you don't mind the megabyte pics.  Figured it would give you a better look that way.

> >> I'm willing to work with you to get this right.
> > 
> > I know - thank you.  I just wish I had discovered what was the issue
> with
> > building the root filesys image before now....
> 
> Let's work together, and make sure that ixp4xx{be,le}.conf are files
> that can be used for (included in) a number of such machine configurations.

Sounds good to me!

Regards,
-Mark Gollahon