Re: [PATCH v2 1/1] hw/arm/aspeed: Add fby35 machine type

[Peter Delevoryas]

> On May 5, 2022, at 11:30 PM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> On 5/4/22 18:34, Peter Delevoryas wrote:
>>> On May 4, 2022, at 12:39 AM, Cédric Le Goater <clg@kaod.org> wrote:
>>> 
>>> On 5/4/22 00:59, Peter Delevoryas wrote:
>>>> Add the 'fby35-bmc' machine type based on the kernel DTS[1] and userspace
>>>> i2c setup scripts[2]. Undefined values are inherited from the AST2600-EVB.
>>>> Reference images can be found in Facebook OpenBMC Github Release assets
>>>> as "fby35.mtd". [3]
>>>> You can boot the reference images as follows (fby35 uses dual-flash):
>>>> qemu-system-arm -machine fby35-bmc \
>>>> -drive file=fby35.mtd,format=raw,if=mtd \
>>>> -drive file=fby35.mtd,format=raw,if=mtd \
>>>> -nographic
>>>> [1] 
>>>> https://github.com/facebook/openbmc-linux/blob/412d5053258007117e94b1e36015aefc1301474b/arch/arm/boot/dts/aspeed-bmc-facebook-fby35.dts
>>>> [2] 
>>>> https://github.com/facebook/openbmc/blob/e2294ff5d31dd65c248fe396a385286d6d5c463d/meta-facebook/meta-fby35/recipes-fby35/plat-utils/files/setup-dev.sh
>>>> [3] https://github.com/facebook/openbmc/releases
>>>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>>> 
>>> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>> Thanks!
> 
> Could you please send a v2 with an update of the documentation ?
> or a follow up ? no need to resend the first patch unless you
> want to change something. A one-liner in :
> 
> https://qemu.readthedocs.io/en/latest/system/arm/aspeed.html 
> [ ... ]
> 

Oh, yeah I’ll send a follow-up, I don’t have anything else to change on the 
first patch I suppose.

>> As a matter of fact yes! I tested booting our OpenBIC Zephyr kernel last 
>> week with the 1030, that worked. I also used the experimental i2c 
>> multi-master patches from Klaus to make a i2c-netdev device that connects 
>> two separate QEMU instances through a socket and sends their i2c messages 
>> back and forth. I was able to test a basic MCTP transaction.
> 
> Nice ! And do you need anything special from the I2C Aspeed models ?
> Apart from :
> 
> https://patchwork.ozlabs.org/project/qemu-devel/list/?series=292928 

Nope, I don’t need anything else, those exact patches were sufficient. I didn’t 
need any additional
modifications to the i2c send_async model Klaus made.

My code was not very sophisticated though, it just assumes ACK for every byte 
in an i2c message,
buffers them, and then sends the i2c message as a UDP packet. The receiver 
buffers the i2c message
and asynchronously dequeues each byte through send_async (after mastering the 
bus). I’ll post the
diff as an RFC soon, in case it helps with evaluating Klaus’s changes.

https://github.com/facebook/openbmc-qemu/commit/c03730986d521ca2a06fd4570d29f2452d13f8da

The problem I foresee is that people are interested in NACK emulation, Smbus 
ARP, and generally,
emulating an i2c _bus_ with a multicast UDP socket and not point-to-point i2c 
device connections.
That way you can have multiple QEMU’s listen to a single multicast UDP socket 
or something
and filter out messages that are directed at other i2c devices, something like 
that. And, probably
send each byte individually instead of buffering and sending. But, buffering 
stuff works for
my purposes for now, since I’m more interested in enabling higher level MCTP 
testing than
simulating i2c multi-master contention.

>> I’m hoping to help however possible with merging Klaus’s changes, 
> 
> They don't need much work. Klaus doesn't have the datasheet, so we
> should help him with the changes requiring some internal knowledge.
> 
>> and then propose the i2c-netdev thing too.
> 
> I was going to ask since I didn't see any models for such devices.
> 
> I hope to do something similar with the usb-net device but it needs
> fixes first.

Oh I wasn’t aware anyone was doing something similar, I’ll have to look at how 
you did
that.

> 
> Thanks,
> 
> C.