On Mon, Jan 03, 2022 at 05:04:48PM -0300, Crystal Kolipe wrote: > 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.
Interestingly, I get the equivalent behavior running NetBSD 9.2, I.E. communication with the PMIC fails. So it seems unlikely to be a trivial bug in our implementation.
