Several general questions

Brad Bishop bradleyb at
Thu Apr 28 11:03:19 AEST 2016

Hi Shay

the yocto-poky dir is just a snapshot of the yocto project so we try to keep that vanilla.

I’d suggest putting it here:
meta-openbmc-bsp/conf/machine/include/ (note that these tune includes don’t go in the ‘arm’ subdir in upstream Yocto).

Then as more SOC layers that use this core get added - for example:


they can all reference this tune file.

The file contents look good to me.

thx - brad

> On Apr 27, 2016, at 5:28 PM, Shay Slobodkin <shays at> wrote:
> Thank you guys for you quick reply and assistance.
> We have taking your input into our design, still digesting, and let you know if we have more questions.
> We have also added a tuning file under:
> yocto-poky/meta/conf/machine/include/
> Would you put the file elsewhere?
> We wonder if there is anything else we should add/remove from this file.
> Current content is:
>    EFAULTTUNE ?= "armv6"
>    require conf/machine/include/arm/
>    TUNEVALID[arm1176jzf-s] = "Enable arm1176jzf-s specific processor optimizations"
>    TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm1176jzf-s", " -mtune=arm1176jzf-s", "", d)}"
>    AVAILTUNES += "arm1176jzf-s"
>   ARMPKGARCH_tune-arm1176jzf-s = "arm1176jzf-s"
>   TUNE_FEATURES_tune-arm1176jzf-s = "${TUNE_FEATURES_tune-armv6} arm1176jzf-s"
>   PACKAGE_EXTRA_ARCHS_tune-arm1176jzf-s = "${PACKAGE_EXTRA_ARCHS_tune-armv6} arm1176jzf-s-vfp"
> Thanks,
> Shay
>> -----Original Message-----
>> From: joel.stan at [mailto:joel.stan at] On Behalf Of Joel
>> Stanley
>> Sent: Wednesday, April 20, 2016 5:08 AM
>> To: Shay Slobodkin <shays at>
>> Cc: openbmc at
>> Subject: Re: Several general questions
>> Hello Shay,
>> Nice to hear from you again.
>> On Wed, Apr 20, 2016 at 12:26 AM, Shay Slobodkin <shays at>
>> wrote:
>>> 2. Several u-boot versions were mentioned this week at mailing list,
>>> we currently use u-boot based on 2013.7 with porting AST2520 stuff
>>> from Aspeed EVB u-boot. Can you suggest a u-boot version to merge with?
>> We're in the process of cleaning up the u-boot. You have three options
>> 1. v2013.07-aspeed-openbmc tree. This is the tree used in Barreleye  2.
>> v2016.03-openbmc tree. There's a few versions floating around, but it's the
>> barreleye tree rebased on 2016.03.
>> 3. wait for us to add aspeed support to upstream u-boot. This isn't ready yet
>> It might make sense to go with 1 with the intention of moving to 3 when it's
>> ready, but it's up to you to.
>>> 4. We saw that most openbmc systems are using jffs2 file system. We
>>> thought to use ubifs as it has some advantages over jffs2. Can you
>>> share the motivation of using jffs2 for BMC project and is there
>>> special reason for doing so?
>> This was a design decision made when implementing this part of the system.
>> Milton might be able to remind us what the reasons were.
>> If you wish to instead use ubifs I think that it is a good choice.
>>> 5. Some Aspeed EVB drivers such as USB, PWM were not ported to
>> openbmc
>>> kernel tree yet. We were planning to port them and wonder if there is
>>> any special reason they weren’t ported yet.
>> As Chris mentioned, this was simply because we didn't require them.
>> Our dev-4.4 tree contains support for the following:
>> - irq controller, uarts and timer. these are the basics required to boot
>> - i2c master. Only byte-at-a-time, no DMA support
>> - gpio. direction, state, and interrupts are supported
>> - internal rtc. this isn't battery backed so we disable it and instead use a i2c
>> attached battery backed rtc
>> - watchdog. required for rebooting the soc
>> - spi-nor. this is the mode we use our flash in; it supports both the SMC and
>> FMC
>> - ethernet mac with NSCI
>> - bt character device, for in-band IPMI communication with the host
>> - vuart
>> As we didn't use the PWM, USB host nor USB device on Barreleye so no time
>> was spent on these.
>> If there is interest in writing clean drivers for these devices I would welcome
>> patches, and can assist with review and integration.
>> I'm no longer working on our own tree. My focus is now cleaning up patches
>> and submitting them upstream. Last week I sent out a series that adds basic
>> support for the ast2400:
>> April/422110.html
>> I intend to follow that up with some fixes as well as ast2500 support today.
>> Cheers,
>> Joel
> _______________________________________________
> openbmc mailing list
> openbmc at

More information about the openbmc mailing list