On Sun, Jan 02, 2022 at 09:09:02AM -0300, Crystal Kolipe wrote: > On Sun, Jan 02, 2022 at 07:17:35AM -0300, Crystal Kolipe wrote: > > On Sun, Dec 26, 2021 at 07:00:31PM +0100, Patrick Wildt wrote: > > > So you might want to find out why sxirsb(4) isn't working well. > > > > The errors I'm seeing are: > > > > RD8 failed for run-time address 0x2d > > WR8 failed for run-time address 0x2d > > > > The only code paths that can generate these error messages are in > > fdt/sxirsb.c, rsb_read_1 and rsb_write_1, when the call to sxirsb_do_trans > > returns either EIO or ETIMEDOUT. > > > > After adding debug code, it seems that the value of 'stat' returned from > > macro HREAD4 is not RSB_STAT_TRANS_OVER as expected, so sxirsb_do_trans is > > returning EIO. > > > > The value of 'stat' depends on whether it's a read or write operation, but > > it's always the same: > > > > READ 0x103 > > WRITE 0x003 > > > > Whereas the code expects to see 0x001... > > So as I understand it, this value 'stat' is the value returned from the > status register of the RSB controller, which according to documentation is > supposed to include an error code in bits 8 - 23. > > But in this case, at least for writes, all of the high bits are set to zero. > > I notice that stat is declared as a uint16_t, so presumably the contents of > bits 16 - 23 from the status register are being lost.
Expanding stat to uint32_t, it now returns 0x10003 on write, so bit 16 is being set.
