Several general questions

Several general questions

[Shay Slobodkin]

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

Hi,

We have some general questions from our latest experience with the project:

1. We saw some corresponding about out of the box experience and we were wondering how does the BMC should be burnt for the first time in production. Currently we have limited speed of debug UART on AST2520, also Aspeed recommend to use this interface for debug purpose only. We also faced a problem to burn BMC using Abatron BDI3000, does anyone have experience working with it?

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?

3. Is there some standard method performing BMC upgrade on site from host CPU? Is there a best practice of upgrade granularity? Meaning, do you suggest to upgrade whole image or maybe just specific partition (only DTB for example)?

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?

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.

6. Building the project yields a lot of files under the "deploy" folder of build. We were wondering which files to use for simply flashing a system (using flashcp?) and which should be used for production.

Thank you for your assistance,
Shay


[-- Attachment #2: Type: text/html, Size: 3956 bytes --]

Re: Several general questions

[Norman James]

[-- Attachment #1.1: Type: text/plain, Size: 2841 bytes --]

I answered 1, 3, and 6


Regards,
Norman James
IBM - POWER Systems Architect
Phone: 1-512-286-6807 (T/L: 363-6807)
Internet: njames@us.ibm.com




From:	Shay Slobodkin <shays@mellanox.com>
To:	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Date:	04/19/2016 10:12 AM
Subject:	Several general questions
Sent by:	"openbmc" <openbmc-bounces+njames=us.ibm.com@lists.ozlabs.org>



Hi,

We have some general questions from our latest experience with the project:

1. We saw some corresponding about out of the box experience and we were
wondering how does the BMC should be burnt for the first time in
production. Currently we have limited speed of debug UART on AST2520, also
Aspeed recommend to use this interface for debug purpose only. We also
faced a problem to burn BMC using Abatron BDI3000, does anyone have
experience working with it?

>> For the first time flash, an external SPI flash programmer is usually
used.   The DediProg SF100 works with no issues.


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?

3. Is there some standard method performing BMC upgrade on site from host
CPU? Is there a best practice of upgrade granularity? Meaning, do you
suggest to upgrade whole image or maybe just specific partition (only DTB
for example)?

>> When flashing from the host, we do no currently support a partial
upgrade.   We boot the BMC into a mode where it doesn't use the flash
filesystem and then use SOCFlash from Aspeed.   You can reboot the BMC into
this special mode with ipmitool from host CPU.   Through REST, we do
support upgrades of kernel, readonly filesystem, rw filesystem, and uboot
separately.  In the deploy directory, the image-* files are for this and
packaged up in the tar.

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?

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.

6. Building the project yields a lot of files under the “deploy” folder of
build. We were wondering which files to use for simply flashing a system
(using flashcp?) and which should be used for production.

>> flash-[system_name] can be directly flashed with the a programmer,
SOCFlash, or flashcp.

Thank you for your assistance,
Shay
 _______________________________________________
openbmc mailing list
openbmc@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/openbmc



[-- Attachment #1.2: Type: text/html, Size: 4509 bytes --]

[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]

Re: Several general questions

[Chris Austen]

[-- Attachment #1: Type: text/html, Size: 7672 bytes --]

[-- Attachment #2: Image.1__=09BBF509DFCB9B178f9e8a93df938690918c09B@.gif --]
[-- Type: image/gif, Size: 105 bytes --]

[-- Attachment #3: Image.1__=09BBF509DFCB9B178f9e8a93df938690918c09B@.gif --]
[-- Type: image/gif, Size: 105 bytes --]

Re: Several general questions

[Teddy Reed]

On Tue, Apr 19, 2016 at 2:00 PM, Chris Austen <austenc@us.ibm.com> wrote:
>
> I semi answered the rest.  Hoping Teddy or others can really address #5
>
>
> Chris Austen
> POWER Systems Enablement Manager
> (512) 286-5184 (T/L: 363-5184)
>
>
>
> ----- Original message -----
> From: Norman James/Austin/IBM@IBMUS
> Sent by: "openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org>
> To: Shay Slobodkin <shays@mellanox.com>
> Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
> Subject: Re: Several general questions
> Date: Tue, Apr 19, 2016 11:45 AM
>
>
> I answered 1, 3, and 6
>
>
> Regards,
> Norman James
> IBM - POWER Systems Architect
> Phone: 1-512-286-6807 (T/L: 363-6807)
> Internet: njames@us.ibm.com
>
>
> Shay Slobodkin ---04/19/2016 10:12:49 AM---Hi, We have some general
> questions from our latest experience with the project:
>
> From: Shay Slobodkin <shays@mellanox.com>
> To: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
> Date: 04/19/2016 10:12 AM
> Subject: Several general questions
> Sent by: "openbmc" <openbmc-bounces+njames=us.ibm.com@lists.ozlabs.org>
>
> ________________________________
>
>
>
> Hi,
>
> We have some general questions from our latest experience with the project:
>
> 1. We saw some corresponding about out of the box experience and we were
> wondering how does the BMC should be burnt for the first time in production.
> Currently we have limited speed of debug UART on AST2520, also Aspeed
> recommend to use this interface for debug purpose only. We also faced a
> problem to burn BMC using Abatron BDI3000, does anyone have experience
> working with it?
>
>>> For the first time flash, an external SPI flash programmer is usually
>>> used. The DediProg SF100 works with no issues.
>
>
> 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?
>
>>> CA: Stay with the Teddy/Joel talk as it seems like they are just a couple
>>> of weeks away from getting us up to 2016.03.
>
>
> 3. Is there some standard method performing BMC upgrade on site from host
> CPU? Is there a best practice of upgrade granularity? Meaning, do you
> suggest to upgrade whole image or maybe just specific partition (only DTB
> for example)?
>
>>> When flashing from the host, we do no currently support a partial
>>> upgrade. We boot the BMC into a mode where it doesn't use the flash
>>> filesystem and then use SOCFlash from Aspeed. You can reboot the BMC into
>>> this special mode with ipmitool from host CPU. Through REST, we do support
>>> upgrades of kernel, readonly filesystem, rw filesystem, and uboot
>>> separately. In the deploy directory, the image-* files are for this and
>>> packaged up in the tar.
>
> 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?
>
>>> CA: simply because jffs2 was designed for flash file systems, it was
>>> known, we knew how to work with it.  Ubifs has some nice wear leveling
>>> support and that was not something we needed to be concerned about with our
>>> use of PNOR flash.  We did not perform any review of ubifs, so it seems
>>> reasonable to think (barring flash image size) that ubifs could be used
>
> 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.
>
>>> CA: The only reason why they were not on the AST2400 was because we never
>>> used them.  I suspect another company on this distro does already have
>>> versions of the USB (and maybe PWM?) for the 4.1 kernel.  Joel is working to
>>> get the AST2500 Kernel up to 4.4 however the priority for USB and PWM is
>>> likely lower.  If you are pushing towards support for them on the 4.4 Kernel
>>> work with Teddy and his group for the design beyond basic operations.
>

I don't think we're using either, but I'm not 100% certain that all
boards wont need USB or PWM. I can check and get back to you, in all
cases it's very difficult for us to submit patches upstream. The best
I could offer is testing. :)

>
> 6. Building the project yields a lot of files under the “deploy” folder of
> build. We were wondering which files to use for simply flashing a system
> (using flashcp?) and which should be used for production.
>
>>> flash-[system_name] can be directly flashed with the a programmer,
>>> SOCFlash, or flashcp.
>
> Thank you for your assistance,
> Shay
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>



-- 
Teddy Reed V

Re: Several general questions

[Joel Stanley]

Hello Shay,

Nice to hear from you again.

On Wed, Apr 20, 2016 at 12:26 AM, Shay Slobodkin <shays@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

RE: Several general questions

[Shay Slobodkin]

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@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel
> Stanley
> Sent: Wednesday, April 20, 2016 5:08 AM
> To: Shay Slobodkin <shays@mellanox.com>
> Cc: openbmc@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@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

Re: Several general questions

[Brad Bishop]

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/tune-arm1176jzf-s.inc (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:

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.

thx - brad

> On Apr 27, 2016, at 5:28 PM, Shay Slobodkin <shays@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@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel
>> Stanley
>> Sent: Wednesday, April 20, 2016 5:08 AM
>> To: Shay Slobodkin <shays@mellanox.com>
>> Cc: openbmc@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@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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

RE: Several general questions

[Shay Slobodkin]

Thanks for the enlightenment.
Will change accordingly.

Shay

> -----Original Message-----
> From: Brad Bishop [mailto:bradleyb@fuzziesquirrel.com]
> Sent: Thursday, April 28, 2016 4:03 AM
> To: Shay Slobodkin <shays@mellanox.com>
> Cc: openbmc@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@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@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of
> >> Joel Stanley
> >> Sent: Wednesday, April 20, 2016 5:08 AM
> >> To: Shay Slobodkin <shays@mellanox.com>
> >> Cc: openbmc@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@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@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc