Tim Rightnour wrote:

> On 28-Apr-2007 Frank Wille wrote:
>> Yes, that would be helpful. I stopped my work on NetBSD/amigappc some
>> weeks ago, because scanning the SCSI devices just returned empty
>> name-strings, for the devices found on the bus. No idea why.
> 
> Do you have dmesg or examples of this happening?

No serial console at the moment, so I have to type the screen output. But
the relevant part in my current development version looks like this:

---8<---
ahsc0 at mainbus0
scsibus0 at ahsc0: 8 targets, 8 luns per target
aucc0 at mainbus0
[...]
survived autoconf, going to enable interrupts
0...survived interrupt enable
survived configure
4 views configured
scsibus0: waiting 2 seconds for devices to settle...
ahsc0: target 4 now synchronous, period=252ns, offset=12.
sd0 at scsibus0 target 4 lun 0: <, , > disk fixed
sd0: fabricating a geometry
sd0: 2048, 0 cyl, 64 head, 32 sec, 2048 bytes/sect x 1 sectors
ahsc0: target 5 now synchronous, period=248ns, offset=7.
sd1 at scsibus0 target 5 lun 0: <, , > disk fixed
sd1: fabricating a geometry
sd1: 2048, 0 cyl, 64 head, 32 sec, 2048 bytes/sect x 1 sectors
sd2 at scsibus0 target 6 lun 0: <, , > disk fixed
sd2: fabricating a geometry
sd2: 512, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 1 sectors
Boot partition offset is 0
sd2: fabricating a geometry
sd2: rdb scan I/O error
sd1: fabricating a geometry
sd1: rdb scan I/O error
sd0: fabricating a geometry
sd0: rdb scan I/O error
survived findroot()
root device: _
---8<---

So it detects the correct target IDs, even tries to switch to synchronous
mode, but doesn't get any information about the name or the geometry of the
disks.

In this case target 4 would have been a CD-ROM, target 5 a CD-writer and 6 a
Zip-drive (sector sizes seem to be correct for those types).


> I've seen some pretty
> crazy stuff happen because of interrupt code being horked, or io mappings
> being in the wrong place.

Or timers not running correctly? Could very well be. I'm not sure if anything
of this works.


> I'm by no means a SCSI expert, but I will do my
> best to try to get amigappc compiling again and help you with the issues
> if someone with hardware is willing to stand up for the port.

Sure. I have done a lot of hacking on amigappc in the beginning of the year
and would appreciate any help to make it boot into multiuser.

I own two CSPPC boards. One in an A3000, the other in an A4000.


> Looking at the code, I think the port is fixable, it just needs some
> attention.

This is valid for most ports, I guess. :)


> There are some really odd things going on in there. I'm not
> sure if thats because it's an amiga or not though.

There is a lot of Amiga-specific code, which must be different to other PPC
ports. But there is also some code which is just obsolete now.


> What really concerns me
> about the code is that it seems to avoid using all the shared powerpc code
> and rolls its own.

I have fixed most of this and adapted the code to NetBSD current in the last
months. Before it was not even compiling, not talking about working.

Ignatios Souvatzis (NetBSD/amiga maintainer) has got my patches to have a
look and check them in (some NetBSD/amiga source is also affected).
Unfortunately he didn't have much time to do so...


> It's very likely that you might have a completely
> different set of problems than other ppc ports do. :)

Hmm... yes. And not much people I can ask then. :|

NetBSD/amigappc was only a training for me, working with hardware I know to
get familiar with NetBSD kernel hacking. My real goal is to get NetBSD running
on the Pegasos and the EFIKA... *sigh*


-- 
    _  Frank Wille (frank@phoenix.owl.de)
 _ //  http://sun.hasenbraten.de/~frank/
 \X/   Phx @ #AmigaGer