Flashy will break on AST2600 about openbmc

[zhdaniel12]

thanks @lhl2617, recently we landed 1d35aa0, thus flashy shall be able to fix flashy.

[lsiudut]

@lhl2617 I don't think w should rely on the new structures to detect the system as it won't work on the systems that are not having it implemented. This applies to golden images across the fleet.

[lhl2617]

cc: @zhdaniel12 @kawmarco @amithash

Addendum

There are other issues I wish to discuss as well, most notably keeping flash utilities in harmony. Currently fw-util is understandably the gold standard for up-and-coming platforms, and thus we'd need to figure out a way to keep flashy etc. in sync. There are however differences in how flashy and fw-util works (esp vboot flashing--see

openbmc/tools/flashy/lib/flash/flashcp_step.go

Line 66 in 1db223d

var flashCpAndValidate = func(

: flashy skips the 84K RO region, whereas fw-util makes a new image and patches the image with the flash device's RO region).

Another issue is one that I've recently tackled in f4e9048 in response to f137c9a . An extra note that the flashy fix is in fact redundant, as flashy's validation is not tied to 32MB, and flashcp (both flashy's and the normal implementation) does a health check to make sure the size of the image is smaller than that of the device. The fw-util change is likely in response to the check_image implementation which assumes 32MB max image size (there is a calloc for that exact size here to validate images). This is a blocker for >32MB image sizes, so I'm flagging this up as well to @amithash. I reckon a similar fix as to how @zhdaniel12 implemented the vboot-util fix should suffice on newer platforms with bigger image sizes.

There was also a fbnd -> northdome issue: 6e7e782 & e2cf878
I think I wrote internal documentation about platform issues in the internal Wiki before I left, but I do not recall now.

In short, maintaining these tools with vague dependencies is hard, and responding to them passively would prove problematic in the long run. It'd be nice if we can discuss on how to deal with these problems.

Understandably, a lot of docs + tooling are internal--I will be starting in LDN at 19th July, and while unfortunately it seems that I will be unable to join the DUB/MPK based OpenBMC PE team, I'd be very happy to connect and jump in a meeting to discuss these issues.

[lhl2617]

I researched further: perhaps flashy should also have its own soc-util?

https://github.com/facebook/openbmc/blob/helium/meta-aspeed/recipes-utils/soc-utils/files/soc-utils.sh

[lhl2617]

@zhdaniel12 Working on a fix :) Thanks!

[lhl2617]

@lsiudut good point, I'm looking at it now. My plan was to fall back to the default one for AST2400/AST2500.

I can however read off the device tree as in 1d35aa0