Several general questions

[Shay Slobodkin]

Thanks for the enlightenment.
Will change accordingly.

Shay

> -----Original Message-----
> From: Brad Bishop [mailto:bradleyb at fuzziesquirrel.com]
> Sent: Thursday, April 28, 2016 4:03 AM
> To: Shay Slobodkin <shays at mellanox.com>
> Cc: openbmc at lists.ozlabs.org
> Subject: Re: Several general questions
> 
> Hi Shay
> 
> the yocto-poky dir is just a snapshot of the yocto project so we try to keep
> that vanilla.

Sounds very reasonable.

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

Will move it there, looks like the proper location.

> 
> Then as more SOC layers that use this core get added - for example:
> 
> meta-openbmc-bsp/meta-aspeed/meta-ast2520
> meta-openbmc-bsp/meta-aspeed/meta-ast-soc-based-on-arm1176
> meta-openbmc-bsp/meta-other-arm-vendor/meta-other-arm1176-based-
> soc
> 
> they can all reference this tune file.
> 
> The file contents look good to me.

Thank you for reviewing.

> 
> thx - brad
> 
> > On Apr 27, 2016, at 5:28 PM, Shay Slobodkin <shays at mellanox.com>
> 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/tune-arm1176jzf-s.inc
> >
> > 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/arch-armv6.inc
> >
> >    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 gmail.com [mailto:joel.stan at gmail.com] On Behalf Of
> >> Joel Stanley
> >> Sent: Wednesday, April 20, 2016 5:08 AM
> >> To: Shay Slobodkin <shays at mellanox.com>
> >> Cc: openbmc at lists.ozlabs.org
> >> 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 mellanox.com>
> >> 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:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-
> >> 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 lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc