PCI range checking under qemu-system-sparc64

[Mark Cave-Ayland]

On 06/09/15 13:48, Alexey Dokuchaev wrote:

> On Sun, Sep 06, 2015 at 01:16:13PM +0100, Mark Cave-Ayland wrote:
>> On 06/09/15 12:03, Alexey Dokuchaev wrote:
>>> Mark did you have any success with getting the boot process further?
>>
>> Not really - due to changes with my job and involvment in GSoC this year
>> then my QEMU SPARC64 work hasn't really progressed much :(
>>
>> I don't have my FreeBSD environment setup right now (due to OS upgrade)
>> but can you post the console output for the boot as far as it gets with
>> the current version of the patch applied?
> 
> Last few lines:
> 
>   [...]
>   eeprom0: <EEPROM/clock> addr 0x1400002000-0x1400003fff on ebus0
>   eeprom0: cannot allocate resources
>   device_attach: eeprom0 attach returned 6
>   ebus0: <fdthree> addr 0 (no driver attached)
>   ebus0: <su> addr 0x14000003f8-0x14000003ff irq 43 (no driver attached)
>   ebus0: <kb_ps2> addr 0x1400000060-0x1400000067 (no driver attached)
>   pci0: <network, ethernet> at device 4.0 (no driver attached)
>   atapci0: <SiI (CMD) 646U2 UDMA33 controller> port 0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at device 5.0 on pci0
>   ata2: <ATA channel> at channel 0 on atapci0
>   ata3: <ATA channel> at channel 1 on atapci0
>   cryptosoft0: <software crypto> on nexus0
>   nexus0: <syscons> type unknown (no driver attached)
>   Timecounter "tick" frequency 100000000 Hz quality 1000
>   Event timer "tick" frequency 100000000 Hz quality 1000
>   Timecounters tick every 1.000 msec
>   IPsec: Initialized Security Association Processing.
> 
> Full log available here:
> 
> 	http://193.124.210.26/head-r287497-sparc64-qemu.log
> 
> ./danfe

Thanks a lot. I wonder if the problem is just that suitable console
drivers can't be found?

>   ebus0: <su> addr 0x14000003f8-0x14000003ff irq 43 (no driver attached)
>   ebus0: <kb_ps2> addr 0x1400000060-0x1400000067 (no driver attached)

The QEMU hardware model is still a WIP and the serial port currently
uses a 16550A UART (su) device rather than ESCC found in real hardware,
while the keyboard is a simple PS2 keyboard.

If you alter your kernel configuration to include building of the su and
ps2 driver modules, does this help with detection of the serial and
keyboard devices and if so, does boot progress any further at all?


ATB,

Mark.