On Thu, 2026-07-23 at 10:26 +0000, Bernhard Beschow wrote:
>
>
> Am 23. Juli 2026 08:20:34 UTC schrieb "Philippe Mathieu-Daudé"
> <[email protected]>:
> > On 23/7/26 09:00, Bernhard Beschow wrote:
> > > As indicated in the comments, the `mb[]` a.k.a. `mbs []` views
> > > should
> > > cover 0x400 (1024) bytes. However, the `mb[]` array covers four
> > > times
> > > the size since `sizeof(FlexcanRegsMessageBuffer)` returns the
> > > size in
> > > bytes instead of counting the number of uint32_t fields. This
> > > shifts the
> > > subsequent register offsets by 0xc00 which is not intended. Fix
> > > the size
> > > and thus the offsets by dropping the now unused `mb[]` view.
> > >
> > > Note that the different size changes the migration layout. Since
> > > the device
> > > model is new, no change in the version fields is needed.
> >
> > typedef struct FlexcanState {
> > ...
> > union {
> > FlexcanRegs regs;
> > uint32_t regs_raw[sizeof(FlexcanRegs) / 4];
> > };
> > ...
> > } FlexcanState;
> >
> > static const VMStateDescription vmstate_can = {
> > .name = TYPE_CAN_FLEXCAN,
> > .version_id = 1,
> > .minimum_version_id = 1,
> > .fields = (const VMStateField[]) {
> > ...
> > VMSTATE_UINT32_ARRAY(regs_raw, FlexcanState,
> > sizeof(FlexcanRegs) / 4),
> >
> > ^^^
> >
> > This "consider this structure as a casted array of u32" is very
> > fragile
> > anyway, and will unlikely scale over time.
> >
> > ...
> > VMSTATE_END_OF_LIST(),
> > },
> > };
>
> Any suggestions what to do instead?
The oversized mb[] view is my mistake, it should have been the same
length as mbs[], i forgot to divide its size by sizeof(u32)... I realy
meant the mailboxes to be an u32 array, and the struct laid over it was
just a convenience. It should have been
uint32_t mb[sizeof(FlexcanRegsMessageBuffer) * FLEXCAN_MAILBOX_COUNT /
4];
The regs_raw entry in FlexcanState is the same idea. We tried to avoid
any endianess-related bugs by treating the registers as an array of
u32's, and always accessing them as dwords. I see now it's not the
ideal solution, and I should have documented this choice.
Sorry, Matt
--
Matyáš (Matt) Bobek
Email: [email protected]
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
