On Sun, Jan 8, 2012 at 02:48, Andreas Färber <afaer...@suse.de> wrote: > Am 07.01.2012 18:29, schrieb Blue Swirl: >> On Thu, Jan 5, 2012 at 17:45, Andreas Färber <afaer...@suse.de> wrote: >>> Am 15.10.2011 15:50, schrieb Blue Swirl: >>>> Remove now incorrect address base arithmetic, missed by >>>> 9936d6e42392f1440505dfa9df065eabd251cadf. Fixes Sparc64 boot. >>> >>> ...but breaks PReP boot: >>> >>> ERROR: BUG caught... >>> BIOS execution exception >>> nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000 >>> Stopping execution >>> >>> I verified by checking out the preceding commit, applying a variation of >>> http://patchwork.ozlabs.org/patch/134519/ on top; that restored PReP >>> boot to what it used to look like. >>> >>> Any insights? >> >> Sparc64 problem was that the io_base did not match what was passed to >> the functions and then the calculation made the offset totally >> incorrect. Could you add printfs to see what is the offset? > > info qtree: > > dev: m48t59, id "" > dev-prop: size = 8192 > dev-prop: type = 59 > dev-prop: io_base = 0x74 > irq 1 > mmio ffffffffffffffff/0000000000002000 > > #define DEBUG_NVRAM: > > NVRAM_writeb: 0x00000074 => 0x00000000 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000001 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000002 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000003 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000004 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000005 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000006 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000007 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000008 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x00000009 > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x0000000a > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x0000000b > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x0000000c > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x0000000d > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x0000000e > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff > NVRAM_writeb: 0x00000074 => 0x0000000f > NVRAM_writeb: 0x00000075 => 0x00000000 > NVRAM_readb: 0x00000077 <= 0xffffffff
This is what happens on Sparc64: NVRAM_writeb: 0x00000000 => 0x00000000 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x00000070 NVRAM_writeb: 0x00000000 => 0x00000001 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x0000001a NVRAM_writeb: 0x00000000 => 0x00000002 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x00000000 NVRAM_writeb: 0x00000000 => 0x00000003 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x00000002 NVRAM_writeb: 0x00000000 => 0x00000004 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x00000073 NVRAM_writeb: 0x00000000 => 0x00000005 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x00000079 NVRAM_writeb: 0x00000000 => 0x00000006 NVRAM_writeb: 0x00000001 => 0x00000000 NVRAM_readb: 0x00000003 <= 0x00000073 NVRAM_writeb: 0x00000000 => 0x00000007 NVRAM_writeb: 0x00000001 => 0x00000000 I/O base offset is kept with PIO but removed from MMIO, which is not consistent. Avi, could we fix this? Alternatively there could be different handlers for MMIO and PIO, or in this case masking the address with 0x3 could be used but I'd rather unify the I/O handlers.
