Re: [PATCH 0/8] aspeed: I2C fixes, -drive removal (first step)

[Markus Armbruster]

Cédric Le Goater <clg@kaod.org> writes:

> On 2/15/23 07:38, Markus Armbruster wrote:
>> Cédric Le Goater <clg@kaod.org> writes:
>> 
>>> Hello,
>>>
>>> This series starts with a first set of patches fixing I2C slave mode
>>> in the Aspeed I2C controller, a test device and its associated test in
>>> avocado.
>>>
>>> Follow some cleanups which allow the use of block devices instead of
>>> drives. So that, instead of specifying :
>>>
>>>    -drive file=./flash-ast2600-evb,format=raw,if=mtd
>>>    -drive file=./ast2600-evb.pnor,format=raw,if=mtd
>>>    ...
>>>
>>> and guessing from the order which bus the device is attached to, we
>>> can use :
>>>
>>>    -blockdev node-name=fmc0,driver=file,filename=./bmc.img
>>>    -device mx66u51235f,bus=ssi.0,drive=fmc0
>>>    -blockdev node-name=fmc1,driver=file,filename=./bmc-alt.img
>>>    -device mx66u51235f,bus=ssi.0,drive=fmc1
>>>    -blockdev node-name=pnor,driver=file,filename=./pnor
>>>    -device mx66l1g45g,bus=ssi.1,drive=pnor
>>>    ...
>>>
>>> It is not perfect, the CS index still depends on the order, but it is
>>> now possible to run a machine without -drive ...,if=mtd.
>>
>> Lovely!
>>
>> Does this cover all uses of IF_MTD, or only some?
>
> All use for default devices in the aspeed machines. I think most
> machines use IF_MTD in a similar way.
>
> Yet, one extra use of IF_MTD is to fill a ROM region with the first
> drive contents. It avoids fetching instructions from the SPI flash
> mapping and speeds up boot quite significantly.
>
> Once the default flash devices are created and attached to their
> drive, it is possible to query the block backend without the
> drive_get() API. I have a couple of patches for it and it shouldn't
> be a problem.
>>
>>> This lacks the final patch enabling the '-nodefaults' option by not
>>> creating the default devices if specified on the command line. It
>>> needs some more evaluation of the possible undesired effects.
>>
>> Are you thinking of something similar to the default CD-ROM, i.e. use
>> default_list to have -device suppress a certain kind of default devices,
>> and also have -nodefaults suppress them all?
>
> I would have -nodefaults suppress all flash devices. There are also
> I2C devices but they are less problematic for the machine definition.
> (Well, eeprom contents can be complex to handle)
>
> The next step would be to get rid of the drive_get(IF_MTD) internal
> API, which means finding a way to attach block backend devices from
> the command line to the default flash devices. This should be done
> at machine init time and the blockdev should have some 'bus@addr'
> identifier. I lack the knowledge on how this could be done.

Possibly interesting for you: commit e0561e60f17 "hw/arm/virt: Support
firmware configuration with -blockdev".