Tim Rightnour | 1 Nov 19:17 2007
Picon

RE: Pegasos PCI-bus scan works


On 27-Oct-2007 Frank Wille wrote:
> So my assumption is that the BAT-settings are ignored and SmartFirmware
> redirects the installation of the exception handlers to another memory
> region. :P
> 
> Hmm... which means translation has to be disabled somewhere. But does OFW
> still work then? At least it still works with the MMU-tables of the kernel.
> Maybe only disable it during oea_init()?

Are you booting the kernel directly still, or are you booting via ofwboot?

---
Tim Rightnour <root <at> garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/

Frank Wille | 1 Nov 19:56 2007
Picon

Re: Pegasos PCI-bus scan works

Tim Rightnour wrote:

>> So my assumption is that the BAT-settings are ignored and SmartFirmware
>> redirects the installation of the exception handlers to another memory
>> region. :P
>> 
>> Hmm... which means translation has to be disabled somewhere. But does OFW
>> still work then? At least it still works with the MMU-tables of the
>> kernel. Maybe only disable it during oea_init()?
> 
> Are you booting the kernel directly still,

Yes.

> or are you booting via ofwboot?

To be honest, I don't even know how to do that, or how to build ofwboot.

I will send you my modified pegasospci.c in a private email, so you can
check yourself. After some failed attempts to disable translation temporarily
I have delayed oea_init() after pmap_bootstrap(). This way everything works
fine and I'm reaching askroot.

--

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

Tim Rightnour | 1 Nov 20:51 2007
Picon

Re: Pegasos PCI-bus scan works


On 01-Nov-2007 Frank Wille wrote:
> To be honest, I don't even know how to do that, or how to build ofwboot.
> 
> I will send you my modified pegasospci.c in a private email, so you can
> check yourself. After some failed attempts to disable translation temporarily
> I have delayed oea_init() after pmap_bootstrap(). This way everything works
> fine and I'm reaching askroot.

That very well could be part of the problem.  I'm not seeing the problems you
are describing.

Two easy ways to build it:

1) If you have a netbsd powerpc machine, just cd to ofppc/stand and run make
USETOOLS=NO.

2) if not, you can just fire off a release build, and it will get built as part
of that.  You can also probably manually build it with the cross-tools, but I'm
not sure how off the top of my head.

As for booting with it, just put netbsd on an nfs accessible directory, export
it, set it up as the root device in bootpd/dhcpd and then tftpboot ofwboot.

---
Tim Rightnour <root <at> garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/

(Continue reading)

Jochen Kunz | 1 Nov 22:53 2007
Picon

Re: Pegasos PCI-bus scan works

On Thu, 01 Nov 2007 19:56:31 +0100
Frank Wille <frank <at> phoenix.owl.de> wrote:

> > or are you booting via ofwboot?
> To be honest, I don't even know how to do that, or how to build
> ofwboot.
Run build.sh like this:
 ./build.sh -m ofppc -D /usr/src/current/destdir/ofppc \
	-O /usr/src/current/objdir/ofppc -T /usr/src/current/tooldir \
	-R /usr/src/current/releasedir -U tools
then run
cd /usr/src/current/src/sys/arch/ofppc/stand/
/usr/src/current/tooldir/bin/nbmake-ofppc 

Maybe "make" is not enough and you need to run the target sequence
"clean", "objdir", "dependall" by hand.

Or, as Tim sugested, just build a full release.

Once you have ofwboot put it in the place where you have the kernel at
the moment. The formware will load it via TFTP. ofwboot then does DHCP
to determine boot parameters. It asks for a root-directory, then it
NFS-mounts this and loads the file "netbsd" in that directory. Quite
simple.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
(Continue reading)

Matt Sealey | 1 Nov 23:54 2007

Re: Pegasos PCI-bus scan works

Frank Wille wrote:
> I will send you my modified pegasospci.c in a private email, so you can
> check yourself.

If stuff like this eventually goes to get committed, can we not call it
after the specific platform but after the chipset it's dealing with?

marvell_pci.c would be far more descriptive if another Discovery platform
comes along (we support 3 of their chipsets with our firmware.. and who
knows who else might bite) which needs the same trick.

I dunno though. Just, in the interest of not having a set of very very
specific platform files when they are not very specific at all :D

--

-- 
Matt Sealey <matt <at> genesi-usa.com>
Genesi, Manager, Developer Relations

Tim Rightnour | 2 Nov 02:57 2007
Picon

Re: Pegasos PCI-bus scan works


On 01-Nov-2007 Matt Sealey wrote:
> marvell_pci.c would be far more descriptive if another Discovery platform
> comes along (we support 3 of their chipsets with our firmware.. and who
> knows who else might bite) which needs the same trick.

I don't actually know what requires this hack currently.  I consider the code a
necc. evil that I will only be using on machines that absolutely need it.  Any
machine that works with ofwpci.c should be using that instead.

I named it pegasospci, in the hopes that only the pegasos II would ever need
this particular chunk of code.  The layout is similar to how we laid out
macppc's PCI busses.  We have a few sets of basic general pci routines, that
multiple platforms use, like the indirect pci conf stuff, or the of_method conf
stuff.  Then if a particular machine/bridge has something funky about it, we
write a quick little autoconf front-end that ties in the right routines, adds
one of it's own, and is basically for that machine only.

If the code ends up being necc. for a larger number of machines, we will break
out the config routines into a file of it's own, and place it next to
pciconf_indirect.c in arch/powerpc/pci.

Eventually I hope to write an rtas conf backend as well, but thats farther down
the road.

---
Tim Rightnour <root <at> garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/

(Continue reading)

Frank Wille | 2 Nov 09:01 2007
Picon

Re: Pegasos PCI-bus scan works

Matt Sealey wrote:

>> I will send you my modified pegasospci.c in a private email, so you can
>> check yourself.
> 
> If stuff like this eventually goes to get committed, can we not call it
> after the specific platform but after the chipset it's dealing with?

I tend to agree here. Although my original version was named
peg2pci.c I used to call the PCI host bridge "marvell", which
resulted in something like:

marvell0 at mainbus0
pci0 at marvell0 bus 0: indirect configuration space access

--

-- 
Frank Wille

Frank Wille | 2 Nov 09:10 2007
Picon

Re: Pegasos PCI-bus scan works

Tim Rightnour wrote:
> On 01-Nov-2007 Matt Sealey wrote:
> 
>>marvell_pci.c would be far more descriptive if another Discovery platform
>>comes along (we support 3 of their chipsets with our firmware.. and who
>>knows who else might bite) which needs the same trick.
> 
> [...]
> I named it pegasospci, in the hopes that only the pegasos II would ever need
> this particular chunk of code.

Yes, I think so. The Pegasos 1 (using Mai's Articia-S northbridge)
should work with ofwpci.c, IIRC. But then you should call it
pegasos2pci.c or peg2pci.c.

We want to support the Pegasos 1 as well, do we? :)

> The layout is similar to how we laid out macppc's PCI busses.

But macppc uses the name of the northbridge, i.e. "bandit0 at
mainbus0", or "grackle0" or "uninorth0" ...

So... marvell0 would be nice.

--

-- 
Frank Wille

Frank Wille | 2 Nov 21:30 2007
Picon

Re: Pegasos PCI-bus scan works

Tim Rightnour wrote:

> [..not using ofwboot..]
> That very well could be part of the problem. I'm not seeing the problems
> you are describing.
> 
> Two easy ways to build it:
> 
> 1) If you have a netbsd powerpc machine, just cd to ofppc/stand and run
> make USETOOLS=NO.

Yes, I have a macppc-system but this doesn't work, because I lack gcc 4 in my
NetBSD 3.1 installation. But I got ofwboot compiled with nbmake-ofppc, as
Jochen suggested.

> As for booting with it, just put netbsd on an nfs accessible directory,
> export it, set it up as the root device in bootpd/dhcpd and then tftpboot
> ofwboot.

Wow! I'm impressed! You're right, ofwboot really makes a difference! All the
hacks are no longer needed, and I don't even have to change the start
address of the kernel to 0x400000. :)

Now we can start inserting the required device drivers into the config file.
There are still enough problems. Two examples:

viaide0 at pci0 dev 12 function 1
viaide0: VIA Technologies VT8231 ATA100 controller
viaide0: couldn't map native-PCI interrupt
viaide0: couldn't map native-PCI interrupt
(Continue reading)

Frank Wille | 3 Nov 16:03 2007
Picon

Pegasos interrupt mapping and dmamem_alloc

Hi!

Today I found the reason for the "couldn't map interrupt" error on the Pegasos.
There is a bug in pci_machdep_ofw.c genofw_setup_pciintr_map(), when
creating the dictionary entry for Pegasos interrupt pins.

At least the last method for "super-annoying OFW" is affected, which reads
the interrupt lines directly from the PCI bus. Reading the "interrupt"
property returns a pin number from 1 to 4, but this is erroneously added to
'A' (generating pins from 'B' to 'E'!). The following diff fixes that:

--- pci_machdep_ofw.c.orig  2007-11-03 13:24:48.000000000 +0100
+++ pci_machdep_ofw.c   2007-11-03 14:15:38.000000000 +0100
 <at>  <at>  -312,7 +312,8  <at>  <at> 
            if (OF_getprop(node, "interrupts", &pin, 4) < 0)
                pin = 1;
            intr_num = prop_number_create_integer(irq);
-           sprintf(key, "pin-%c", 'A' + pin);
+
+           sprintf(key, "pin-%c", 'A' + (pin-1));
            prop_dictionary_set(sub, key, intr_num);
            prop_object_release(intr_num);
            sprintf(key, "devfunc-%d", dev*0x8 + func);

Now it looked a bit better:
---8<---
pcib0 at pci0 dev 12 function 0: VIA Technologies VT8231 PCI-ISA Bridge (rev. 0x10)
viaide0 at pci0 dev 12 function 1
viaide0: VIA Technologies VT8231 ATA100 controller
viaide0: using irq 14 for native-PCI interrupt
(Continue reading)


Gmane