Hi Cedric > -----Original Message----- > From: Cédric Le Goater <c...@kaod.org> > Sent: Wednesday, February 10, 2021 3:27 PM > To: Sai Pavan Boddu <saip...@xilinx.com>; Edgar Iglesias <edg...@xilinx.com>; > Joel Stanley <j...@jms.id.au>; Andrew Jeffery <and...@aj.id.au> > Cc: qemu-devel@nongnu.org; Philippe Mathieu-Daudé <f4...@amsat.org> > Subject: Re: eMMC support > > Hello Sai Pavan, > > [ ... ] > > >>> The patchset is in the aspeed-6.0 branch : > >>> > >>> df91d012672c Cédric Le Goater - hw/arm/aspeed: Load eMMC first boot > >>> area as a boot rom > >>> 27b75a7ad322 Cédric Le Goater - hw/arm/aspeed: Add eMMC property > >>> 2836cf5a15a1 Joel Stanley - hw/arm/aspeed: Set boot device to > >>> emmc > > > > [Sai Pavan Boddu] I see you guys have implemented the boot area access > > here, > > The boot partition modeling fits our needs to boot the Aspeed machine but > this is very custom. > > > I was assuming, your use-case just need to access data from boot partitions. > > We are not implementing eMMC boot operations or Alternative bootmode > right ? > > Joel could say more about it ? [Sai Pavan Boddu] Anyway BOOT_PARTITION_ENABLE bits are persistent over power cycles, which needs be implemented as properties. > > > And also is it good to calculate the address offset once when > > partition access bits are set, rather than doing it for every read/write ? > > Yes and no. It would add state to the sd object. [Sai Pavan Boddu] Yeah. We already have a member in the state "sd->data_start", which can be updated based on value in PARTITION_ACCESS. I feel there is no harm in updating data_start, correct me if I'm wrong.
Regards, Sai Pavan > > Thanks, > > C.
