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

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@...
https://lists.yoctoproject.org/listinfo/yocto

Hi Mark!

On Fri, Jan 20, 2012 at 6:07 PM, Mark Hatle <mark.hatle@...> 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