OpenBMC on the OpenWRT

[Anton D. Kachalov]

Hi, Joel.

10.08.2016, 14:06, "Joel Stanley" <joel at jms.id.au>:
> Hey Anton,
>
> On Wed, Aug 10, 2016 at 7:26 PM, Anton D. Kachalov <mouse at yandex-team.ru> wrote:
>>  Hello everybody.
>>
>>  I'm working on a separate project for rack solution which utilize many portions of OpenBMC:
>>
>>     https://github.com/ya-mouse/openbmc-target
>
> Nice! I came across your repository the other day.
>
>>  As a system base we choose OpenWRT (flexible kernel-style configurations, package manager,
>>  wide and experienced support for embedded systems with limited resources).
>
> I'm not too familiar with OpenWRT aside from using it on my WiFi
> router at home. I do have experience with buildroot, which uses
> Kconfig and does a good job at creating small, configurable images.
>
> Have you been happy with OpenWRT as a build system?

Yep, we happy with it. We rebase other project from micro ubuntu system
(handcrafted files' lists to keep system as small as 4M + additional app packs) to the
OpenWRT on x86 in our HW load testing and servers' pre-deployment environment.
Of course, there are several tricks that needed to be learned :)

>>  We still use old u-boot that came from OpenSource release of AMI SDK.
>>  Have plans to move to the OpenBMC's version to start using of DTS.
>
> Great! Let me know how you go. I'm happy to apply patches in order to
> support your configuration. Our goal is to upstream our patches to
> remove the need to fork it all together.

I'll try to rebase our current code to the latest OpenBMC (pwmfan, pinctrl, i2c slave).

>>  And a few modifications over OpenBMC kernel tree:
>>
>>  1. I2C slave support for the aspeed adapter (it is ugly a bit).
>
> Did you see the slave patch that Brendan submitted? Would it work for
> your requirements?
>
>   https://github.com/openbmc/linux/commit/090cb02e01906e7a7cf9c210237c4899972a9770

It's good! I'll try it. Next thing that we should think is a buffer mode additional to the byte mode transfer.
It's good for big transactions to offload byte ACKing to HW but requires some changes in, for instance,
i2c slave support design. I've started such discussion in kernel's i2c maillist:

    http://www.spinics.net/lists/linux-i2c/msg25656.html

> Thanks for sharing your results. How does nginx go with memory usage?

It is twice more than uhttpd, but still has a little memory footprint (3-4MB).

I would like to start a little discussion around board setup process in arch/arm/mach-aspeed/aspeed.c.
For most cases this process is "flat": just modifying regs one-by-one. Sometimes with applying mask.
I have an idea to add an array of "instructions" to the Device Tree in the following manner
(I hope dtc's preprocess via cpp resolve ORed macro in the correct way):

==========
#include <dt-bindings/soc/aspeed.h>

/ {
    model = "Our HW";
    compatible = "aspeed,ast2400";
    board-setup = <WR, AST_BASE_LPC | 0x9c, 0x02010023, 0>,
                           <WR, AST_BASE_SCU, SCU_PASSWORD, 0>,
                           <WR, AST_BASE_SCU | 0x80, 0xcb000000, 0>,
                           ...
                            /* write(read() | 0x1000) */
                           <OR, AST_BASE_SCU | 0x2c, 0x00001000, 0>,

                           /* write((read() &~ 0x2000) | 0x1000) */
                           <OR, AST_BASE_SCU | 0x2c, 0x00001000, 0x2000>;
==========

or in less talkative way:

==========
                            /* write((read() &~ 0) | 0xcb000000) */
                           <AST_BASE_SCU | 0x80, 0xcb000000, 0>,
                           ...
                            /* write((read() &~ 0x1000) | 0x1000) */
                           <AST_BASE_SCU | 0x2c, 0x00001000, 0x1000>,
==========

to completely eliminate board-specific init functions.

-- 
Anton D. Kachalov