i486sx machine porting from oe-classic

i486sx machine porting from oe-classic

[Andrea Galbusera]

Hi,

In oe-classic there used to be a machine configuration for an i486sx
based machine called vortex86sx. In the past I was successful in
building a running image for such a target. Since I'd like to make a
new system based on vortex, my goal is to leverage the whole Yocto
Project infrastructure and port that old configuration to a BSP layer.
This will save me a lot of time in supporting developers with SDKs and
so.

Since I could not find any BSP based on hardware older than i586 in
recent Yocto trees, I'm concerned about this. Do you know of any
obstacle in doing such a port? I'm mainly interested in building
images with no graphics for that target: core-image-minimal is a
reasonable reference for me.

My plan was to initially lay out a new BSP by following guidelines
from Development Manual and BSP Guide. Then, what I suspect to be a
little trickier for my expertise, is the porting of the original
tune-i486sx.inc file to the current Yocto infrastructure. Is there any
document I can leverage to map the variables defined in the
oe-classic's syntax to the current ones for such a machine
configuration file?

The original i486 tune file was defining the following:

TARGET_ARCH = "i486"
TARGET_CC_ARCH = "-march=i486"
PACKAGE_EXTRA_ARCHS = "486sx"
BASE_PACKAGE_ARCH = "486sx"
FEED_ARCH = "${BASE_PACKAGE_ARCH}"

Are they still valid variables? Do I need any more?

Thank you in advance. Regards,
Andrea

Re: i486sx machine porting from oe-classic

[Mark Hatle]

On 1/20/12 8:07 AM, Andrea Galbusera wrote:
> Hi,
>
> In oe-classic there used to be a machine configuration for an i486sx
> based machine called vortex86sx. In the past I was successful in
> building a running image for such a target. Since I'd like to make a
> new system based on vortex, my goal is to leverage the whole Yocto
> Project infrastructure and port that old configuration to a BSP layer.
> This will save me a lot of time in supporting developers with SDKs and
> so.
>
> Since I could not find any BSP based on hardware older than i586 in
> recent Yocto trees, I'm concerned about this. Do you know of any
> obstacle in doing such a port? I'm mainly interested in building
> images with no graphics for that target: core-image-minimal is a
> reasonable reference for me.
>
> My plan was to initially lay out a new BSP by following guidelines
> from Development Manual and BSP Guide. Then, what I suspect to be a
> little trickier for my expertise, is the porting of the original
> tune-i486sx.inc file to the current Yocto infrastructure. Is there any
> document I can leverage to map the variables defined in the
> oe-classic's syntax to the current ones for such a machine
> configuration file?

A few things you will need.. a tune file for the CPU, and a tune file for the 
machine/bsp... and you'll have to make sure that eglibc/Linux can still run on 
that machine.

I know a while back some changes were made to the GNU toolchain, include gcc to 
change default optimization levels and such, I don't know if this negatively 
impacted the ability to generate i486 compatible code.

> The original i486 tune file was defining the following:
>
> TARGET_ARCH = "i486"
> TARGET_CC_ARCH = "-march=i486"
> PACKAGE_EXTRA_ARCHS = "486sx"
> BASE_PACKAGE_ARCH = "486sx"
> FEED_ARCH = "${BASE_PACKAGE_ARCH}"
>
> Are they still valid variables? Do I need any more?

Variables have changed.  The following is likely what you want (not tested of 
course) meta/conf/machine/include/tune-i486.inc (based off of tune-i586):

DEFAULTTUNE ?= "i486"
TUNE_PKGARCH_TMP = "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", 
"x86_64", d)}"
TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "i486", "i486", 
TUNE_PKGARCH_TMP, d)}"

require conf/machine/include/ia32/arch-ia32.inc

# Extra tune features
TUNEVALID[i486] = "Enable i486 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "i486", "-march=i486", "", 
d)}"

# Extra tune selections
AVAILTUNES += "i486"
TUNE_FEATURES_tune-i486 ?= "${TUNE_FEATURES_tune-x86} i486"
BASE_LIB_tune-i486 ?= "lib"
PACKAGE_EXTRA_ARCHS_tune-i486 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486"

--Mark

> Thank you in advance. Regards,
> Andrea
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: i486sx machine porting from oe-classic

[Andrea Galbusera]

Hi Mark!

On Fri, Jan 20, 2012 at 6:07 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 1/20/12 8:07 AM, Andrea Galbusera wrote:
>>
>> Hi,
>>
>> In oe-classic there used to be a machine configuration for an i486sx
>> based machine called vortex86sx. In the past I was successful in
>> building a running image for such a target. Since I'd like to make a
>> new system based on vortex, my goal is to leverage the whole Yocto
>> Project infrastructure and port that old configuration to a BSP layer.
>> This will save me a lot of time in supporting developers with SDKs and
>> so.
>>
>> Since I could not find any BSP based on hardware older than i586 in
>> recent Yocto trees, I'm concerned about this. Do you know of any
>> obstacle in doing such a port? I'm mainly interested in building
>> images with no graphics for that target: core-image-minimal is a
>> reasonable reference for me.
>>
>> My plan was to initially lay out a new BSP by following guidelines
>> from Development Manual and BSP Guide. Then, what I suspect to be a
>> little trickier for my expertise, is the porting of the original
>> tune-i486sx.inc file to the current Yocto infrastructure. Is there any
>> document I can leverage to map the variables defined in the
>> oe-classic's syntax to the current ones for such a machine
>> configuration file?
>
>
> A few things you will need.. a tune file for the CPU, and a tune file for
> the machine/bsp... and you'll have to make sure that eglibc/Linux can still
> run on that machine.
>
> I know a while back some changes were made to the GNU toolchain, include gcc
> to change default optimization levels and such, I don't know if this
> negatively impacted the ability to generate i486 compatible code.
>
>
>> The original i486 tune file was defining the following:
>>
>> TARGET_ARCH = "i486"
>> TARGET_CC_ARCH = "-march=i486"
>> PACKAGE_EXTRA_ARCHS = "486sx"
>> BASE_PACKAGE_ARCH = "486sx"
>> FEED_ARCH = "${BASE_PACKAGE_ARCH}"
>>
>> Are they still valid variables? Do I need any more?
>
>
> Variables have changed.  The following is likely what you want (not tested
> of course) meta/conf/machine/include/tune-i486.inc (based off of tune-i586):
>
> DEFAULTTUNE ?= "i486"
> TUNE_PKGARCH_TMP = "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86",
> "x86_64", d)}"
> TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "i486", "i486",
> TUNE_PKGARCH_TMP, d)}"
>
> require conf/machine/include/ia32/arch-ia32.inc
>
> # Extra tune features
> TUNEVALID[i486] = "Enable i486 specific processor optimizations"
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "i486", "-march=i486",
> "", d)}"
>
> # Extra tune selections
> AVAILTUNES += "i486"
> TUNE_FEATURES_tune-i486 ?= "${TUNE_FEATURES_tune-x86} i486"
> BASE_LIB_tune-i486 ?= "lib"
> PACKAGE_EXTRA_ARCHS_tune-i486 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486"

I set up the custom layer following your suggestions and it's building
now... By inspecting the logs I see "-march=i486" applied to
compiler's command lines. I won't be able to test the kernel until
next Monday. I will follow up to let you know if it works.

Thanks!
Regards,
Andrea