Discussion of issues relevant to all PowerPC based NetBSD ports

Tim Rightnour | 23 Jun 2007 08:13

Re: NOTICE: major changes to ofppc incoming


On 22-Jun-2007 Frank Wille wrote:
>> ppcoea-rennovation branch as of yesterday.
>> [...]
> 
> What is the exact name of the branch tag? I would like to check it out and
> play with it a bit.

ppcoea-renovation.  Just like above, but spelled right.  :)

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

headers

Frank Wille | 23 Jun 2007 15:53

Re: NOTICE: major changes to ofppc incoming

Tim Rightnour wrote:

On 23.06.07 06:13:02 you wrote:

> On 22-Jun-2007 Frank Wille wrote:
>> What is the exact name of the branch tag? I would like to check it out
>> and play with it a bit.
> 
> ppcoea-renovation.  Just like above, but spelled right.  :)

Ok. Got it! :)

Hm. Any chance to have a look onto Jorge Acereda's modifications for
SmartFirmware and trying to include them?

At the moment I don't get any output at all. Even after setting the
kernel-base and textaddr to 0x400000 and including the SmartFirmware fix in
powerpc/powerpc/oea/ofw_subr.S (do not disable address-translation for SF).

I might debug it this weekend some more. Unfortunately I cannot remember all
of Jorge's patches.

--

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

headers

Tim Rightnour | 23 Jun 2007 17:25

Re: NOTICE: major changes to ofppc incoming

On 23-Jun-2007 Frank Wille wrote:
> Hm. Any chance to have a look onto Jorge Acereda's modifications for
> SmartFirmware and trying to include them?

Hrmm.. I'm not aware of those.. got a link?

> At the moment I don't get any output at all. Even after setting the
> kernel-base and textaddr to 0x400000 and including the SmartFirmware fix in
> powerpc/powerpc/oea/ofw_subr.S (do not disable address-translation for SF).

No output from anything, or just after the bootloader runs, no output?  What
device is this on?

Maybe try to throw printfs in the very early stages of
arch/powerpc/oea/ofwoea_machdep.c:ofwoea_initppc() and see if any fire.  There
were some changes made to that file to make macppc work, and it's possible that
they are interfering.

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

headers

Jochen Kunz | 26 Jun 2007 23:17

Re: NOTICE: major changes to ofppc incoming

On Sat, 23 Jun 2007 08:25:24 -0700 (MST)
Tim Rightnour <root <at> garbled.net> wrote:

> > Hm. Any chance to have a look onto Jorge Acereda's modifications for
> > SmartFirmware and trying to include them?
> Hrmm.. I'm not aware of those.. got a link?
Have a look at the mail from Jorge to this list:
Subject: Pegasos patches
Date: Mon, 31 Jul 2006 00:08:31 +0200

> > At the moment I don't get any output at all. Even after setting the
> > kernel-base and textaddr to 0x400000 and including the SmartFirmware
> > fix in powerpc/powerpc/oea/ofw_subr.S (do not disable
> > address-translation for SF).
> No output from anything, or just after the bootloader runs, no output?
>  What device is this on?
I tried with an EFIKA a few minutes ago. The last thing I get is:
Using IP address: 192.168.1.103
root addr=192.168.1.2 path=/nfsroot/NetBSD/ofppc
2715948+223740 [160768+156767]=0x31b754
 start=0x100000

I put some printf(9) in intppc() and ofwoea_initppc() but don't get
anything from them.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

(Continue reading)

headers

Frank Wille | 27 Jun 2007 18:45

Re: NOTICE: major changes to ofppc incoming

Jochen Kunz wrote:

>> No output from anything, or just after the bootloader runs, no output?
>>  What device is this on?
> I tried with an EFIKA a few minutes ago. The last thing I get is:
> Using IP address: 192.168.1.103
> root addr=192.168.1.2 path=/nfsroot/NetBSD/ofppc
> 2715948+223740 [160768+156767]=0x31b754
> start=0x100000

Yes, I'm booting the kernel via tftp as well. This is what I wrote to Tim in
an private email about the problem:

I wrote a small disassembler and monitor, running directly under OFW, so I
can inspect values written to memory. This is the way I am debugging at the
moment.

It shows me that the program always hangs in pmap_bootstrap. Usually during
TAILQ_INIT in arch/powerpc/oea/pmap.c, line 3348:

        for (i = 0; i < pmap_pteg_cnt; i++)
                TAILQ_INIT(&pmap_pvo_table[i]);

Then it manages to initialize only 15000 or 16000 of the 16384
(pmap_pteg_cnt) required lists. Sometimes it went some lines further, but
never returns from pmap_bootstrap.

The values for startkernel and endkernel, passed into initppc(), look ok:
  startkernel = 0x400000, endkernel = 0x625000

(Continue reading)

headers

Aymeric Vincent | 30 Jun 2007 17:58

Re: NOTICE: major changes to ofppc incoming

Frank Wille <frank <at> phoenix.owl.de> writes:

> It shows me that the program always hangs in pmap_bootstrap. Usually during
> TAILQ_INIT in arch/powerpc/oea/pmap.c, line 3348:
>
>         for (i = 0; i < pmap_pteg_cnt; i++)
>                 TAILQ_INIT(&pmap_pvo_table[i]);

I had a similar behaviour when I disactivated the caches of the PPC
core on my Efika. (Useful for debugging, but implied this crash) If
you also notice that, it could be worth investigating and making the
code work without caches.

> In ofw_consinit.c, function cninit(), the device_type is "serial", but the
> name-property of the console_node is "failsafe" in my case. So nothing in
> the function applies and no console is attached.

You have to use nvedit/nvstore to explicitly select serial as your IO
system on the Efika.

Something like

" /builtin/serial" io

at the end of the script.

Cheers,
 Aymeric

(Continue reading)

headers

Frank Wille | 1 Jul 2007 19:11

Re: NOTICE: major changes to ofppc incoming

Aymeric Vincent wrote:

> Frank Wille <frank <at> phoenix.owl.de> writes:
> 
>> It shows me that the program always hangs in pmap_bootstrap. Usually
>> during TAILQ_INIT in arch/powerpc/oea/pmap.c, line 3348:
>> 
>>         for (i = 0; i < pmap_pteg_cnt; i++)
>>                 TAILQ_INIT(&pmap_pvo_table[i]);
> 
> I had a similar behaviour when I disactivated the caches of the PPC
> core on my Efika.

But my caches are active! On the Efika, caches and adress translation are
already enabled when booting the kernel. And I found nothing in the ofppc
source which changes that.

Maybe I should check what happens when caches are disabled?

>> In ofw_consinit.c, function cninit(), the device_type is "serial", but
>> the name-property of the console_node is "failsafe" in my case. So
>> nothing in the function applies and no console is attached.
> 
> You have to use nvedit/nvstore to explicitly select serial as your IO
> system on the Efika.
> 
> Something like
> 
> " /builtin/serial" io
>

(Continue reading)

headers

Tim Rightnour | 2 Jul 2007 09:29

Re: NOTICE: major changes to ofppc incoming


On 01-Jul-2007 Frank Wille wrote:
> Oh no. I don't think that a user should be forced to use nvedit just to be
> able to boot a kernel. Here I agree with Matt. This should be handled in the
> source!
> 
> I like the idea of Jochen to delay the console attachment, and just use
> ofcons until the real serial driver is available.

I haven't had a chance yet to really stare at these two ideas and see if I can
find a solution to either of them, but I don't object at all to the concept of
them.  I think they are both fine ideas.

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

headers

Jochen Kunz | 2 Jul 2007 17:34

Re: NOTICE: major changes to ofppc incoming

On Mon, 02 Jul 2007 00:29:11 -0700 (MST)
Tim Rightnour <root <at> garbled.net> wrote:

> > Oh no. I don't think that a user should be forced to use nvedit just
> > to be able to boot a kernel. Here I agree with Matt. This should be
> > handled in the source!
> > 
> > I like the idea of Jochen to delay the console attachment, and just
> > use ofcons until the real serial driver is available.
> 
> I haven't had a chance yet to really stare at these two ideas and see
> if I can find a solution to either of them, but I don't object at all
> to the concept of them.  I think they are both fine ideas.
Maybe port-sparc64 can be an inspiration. It utilizes OFW too and has
similar problems with the console. See consinit.c, pcons.c, com_ebus.c
and sab.c in src/sys/arch/sparc64/dev.

Also: Making the console independent from bus_space(9) eases debugging
of bus_space(9). 

An other problem can arise on machines with multiple PCI-host bridges
like the Pegasos or some of the higher end RS/6000. In that case we have
multiple independent bus_space(9)s. But which of them leads to the
console?

I hope to get some time to have a look at this tonight.
--

-- 

tschüß,
       Jochen

(Continue reading)

headers

Jochen Kunz | 3 Jul 2007 23:54

Re: NOTICE: major changes to ofppc incoming

On Mon, 2 Jul 2007 17:34:45 +0200
Jochen Kunz <jkunz <at> unixag-kl.fh-kl.de> wrote:

> Also: Making the console independent from bus_space(9) eases debugging
> of bus_space(9). 
[...]
> I hope to get some time to have a look at this tonight.
Looks good. I now have a working ofcons on the EFIKA and the Motorola
PowerStack II. But it still fails on the RS/6000 43P-150. Maybe a
firmware issue. I attached a patch for the ofcons to your enjoyment.

EFIKA:
root addr=192.168.1.2 path=/nfsroot/NetBSD/ofppc
2744816+223736 [162560+157678]=0x3232a4
 start=0x100000

Hallo Welt!

found a map reclen=6 cur=0
found a map reclen=6 cur=0
[ Kernel symbol table missing! ]
panic: call to null-ptr from 0x348bcc
Stopped at      0x318e38:       lwz     r0, r1, 0x14
db> 

PowerStack II:
root addr=192.168.1.2 path=/nfsroot/NetBSD/ofppc
2744816+223736 [162560+157678]=0x3232a4
 start=0x100000

(Continue reading)

headers

Frank Wille | 4 Jul 2007 21:54

Re: NOTICE: major changes to ofppc incoming

Jochen Kunz wrote:

> Looks good. I now have a working ofcons on the EFIKA and the Motorola
> PowerStack II. But it still fails on the RS/6000 43P-150. Maybe a
> firmware issue. I attached a patch for the ofcons to your enjoyment.

Hmm. I tried the patch, but I still have the same linking problem as I had
myself, last week.

ofw_consinit.o: In function `cninit':
/usr/src_current/sys/arch/powerpc/oea/ofw_consinit.c:204: undefined reference to `consdev_ofcons'
/usr/src_current/sys/arch/powerpc/oea/ofw_consinit.c:204: undefined reference to `consdev_ofcons'
/usr/src_current/sys/arch/powerpc/oea/ofw_consinit.c:205: undefined reference to `consdev_ofcons'

Where does consdev_ofcons come from?

--

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

headers

Jochen Kunz | 4 Jul 2007 23:21

Re: NOTICE: major changes to ofppc incoming

On Wed, 04 Jul 2007 21:54:49 +0200
Frank Wille <frank <at> phoenix.owl.de> wrote:

> Hmm. I tried the patch, but I still have the same linking problem as I
> had myself, last week.
> 
> ofw_consinit.o: In function `cninit':
> /usr/src_current/sys/arch/powerpc/oea/ofw_consinit.c:204: undefined
> reference to `consdev_ofcons'
[...]
> Where does consdev_ofcons come from?
Nowhere? At least at the moment.

In my source code tree ofw_consinit.c has revision:
$NetBSD: ofw_consinit.c,v 1.1.2.3 2007/06/21 18:19:47 garbled Exp $
And the part referencing consdev_ofcons is disabled with
#if 0
[...]
#endif

Maybe you need a "cvs update"?
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

headers

Frank Wille | 5 Jul 2007 21:56

Re: NOTICE: major changes to ofppc incoming

Jochen Kunz wrote:

>> /usr/src_current/sys/arch/powerpc/oea/ofw_consinit.c:204: undefined
>> reference to `consdev_ofcons'
> [...]
>> Where does consdev_ofcons come from?
> Nowhere? At least at the moment.
> 
> In my source code tree ofw_consinit.c has revision:
> $NetBSD: ofw_consinit.c,v 1.1.2.3 2007/06/21 18:19:47 garbled Exp $
> And the part referencing consdev_ofcons is disabled with
> #if 0
> [...]
> #endif
> 
> Maybe you need a "cvs update"?

Oh... sorry! I enabled this part some days ago, because I wanted to
reactivate the default console. Now it works, and I get the same hang in
pmap_bootstrap as before. But my Efika doesn't drop into ddb, like yours.

--

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

headers

Tim Rightnour | 5 Jul 2007 23:09

Re: NOTICE: major changes to ofppc incoming


On 05-Jul-2007 Frank Wille wrote:
> Oh... sorry! I enabled this part some days ago, because I wanted to
> reactivate the default console. Now it works, and I get the same hang in
> pmap_bootstrap as before. But my Efika doesn't drop into ddb, like yours.

in arch/powerpc/oea/pmap.c, there are a bunch of debugging options.

in you kerenl config, define PMAPDEBUG, and then in pmap.c, look for 

unsigned int pmapdebug = 0;

and change that value to 0xffff; to turn on all the debugging tricks.  Try
again with those, and post the output.  It is actually helpful.

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

headers

Frank Wille | 6 Jul 2007 19:52

Re: NOTICE: major changes to ofppc incoming

Tim Rightnour wrote:

>> [...] Now it works, and I get the same hang in
>> pmap_bootstrap as before. But my Efika doesn't drop into ddb, like yours.
> 
> in arch/powerpc/oea/pmap.c, there are a bunch of debugging options.
> 
> in you kerenl config, define PMAPDEBUG, and then in pmap.c, look for 
> 
> unsigned int pmapdebug = 0;
> 
> and change that value to 0xffff; to turn on all the debugging tricks.  Try
> again with those, and post the output.  It is actually helpful.

Ok, here it is:

found a map reclen=6 cur=0
found a map reclen=6 cur=0
pmap_bootstrap: memory configuration:
pmap_bootstrap: mem start 0x0 size 0x8000000
pmap_bootstrap: avail start 0x19111e4 size 0x66eee1c
pmap_bootstrap: b-avail[0] start 0x1912000 size 0x66ee000
pmap_bootstrap: a-avail[0] start 0x1912000 size 0x66ee000
pmap_bootstrap: avail[0] start 0x1912000 size 0x66ee000
pmap_pteg_cnt: 0x4000
pmap_boot_find_memory: size=100000, alignment=100000, at_end=0: 1a00000
pmap_boot_find_memory: b-avail[0] start 0x1912000 size 0x66ee000
pmap_boot_find_memory: a-avail[0] start 0x1912000 size 0xee000
pmap_boot_find_memory: a-avail[1] start 0x1b00000 size 0x6500000
PTEG cnt: 0x4000 HTAB size: 0x00100000 bytes, address: 0x1a00000

(Continue reading)

headers

Tim Rightnour | 7 Jul 2007 19:14

Re: NOTICE: major changes to ofppc incoming


On 06-Jul-2007 Frank Wille wrote:
> pmap_bootstrap: UVM memory = 101 MB (26060 pages)

Oh..  well.. that means you made it all the way through pmap_bootstrap and back
into initppc.  Now I would go back into ofwoea_initppc() and start throwing
printfs around after pmap_bootstrap and see where it hangs.

It is probably dying in restore_ofmap, so, I would printf up that routine and
see where.

Basically, the first stage of this debugging excersize is to find exactly which
line does it in.  Once we know that, we start looking at the values of
variables around that line, and try to determine why.  Sprinkle printfs
everywhere.

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

headers

Frank Wille | 8 Jul 2007 01:41

Re: booting Efika with ppc-oea-renovation

Tim Rightnour wrote:

> On 06-Jul-2007 Frank Wille wrote:
>> pmap_bootstrap: UVM memory = 101 MB (26060 pages)
> 
> Oh.. well.. that means you made it all the way through pmap_bootstrap and
> back into initppc.

Not really. ;)

Sorry, I'm wasting your time! I forgot another debugging modification of me.
A "for (;;)" at the end of pmap_bootstrap()!

Now I'm sure the source is clean an updated again.

> Now I would go back into ofwoea_initppc() and start
> throwing printfs around after pmap_bootstrap and see where it hangs.

The only remaining problem was that it cannot map ISA IO. The call caused
the same crash as seen in Jochen's post.

As the Efika has no ISA IO area, everything is included in the 5200B SoC, I
have just disabled the call and reached askroot:

NetBSD 4.99.20 (EFIKA) #4: Sat Jul  7 22:53:53 CEST 2007
        frank <at> compaq.owl.de:/usr/src_current/sys/arch_ppcoea-renovation/ofppc/compile/obj/EFIKA
total memory = 128 MB
avail memory = 99 MB
bootpath 
mainbus0 (root)

(Continue reading)

headers

Matt Sealey | 9 Jul 2007 21:42

Re: booting Efika with ppc-oea-renovation

Frank Wille wrote:
>
> How can we determine that we have to map ISA IO or not?

Look for an "isa" bus node as defined by the Open Firmware specification.

Don't do ANYTHING that isn't in the device tree. If you think something
should be in the device tree and it isn't.. bug me and I'll send you my
Forth script which adds device tree nodes for the rest of the MPC5200B.
You can boot it before you boot NetBSD :]

There is no point mapping isa if you don't have an ISA bus. On the
Pegasos though the NetBSD could should be very careful that it is
not ISA, it is merely an LPC controller which acts like an ISA bus,
and it is in fact a native PCI device. Therefore maybe it should be
mapped differently (please don't start making crazy mappings in the
first 64kb to IO registers..)

> other hand, might need it. Or maybe the Efika doesn't fit into ofppc at all,
> and should go into evbppc?

I'd suggest keeping it in ofppc. *device tree*.

--

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

headers

Tim Rightnour | 8 Jul 2007 04:08

Re: booting Efika with ppc-oea-renovation

On 07-Jul-2007 Frank Wille wrote:
> The only remaining problem was that it cannot map ISA IO. The call caused
> the same crash as seen in Jochen's post.
> 
> As the Efika has no ISA IO area, everything is included in the 5200B SoC, I
> have just disabled the call and reached askroot:

In ofwoea_map_space it tries to do a find_ranges() call for RANGE_TYPE_ISA. 
It then looks to see if the range and cur values are zero, and if either are,
it should exit out.  I'd throw some printfs in the find_ranges call and try to
figure out why it's not failing on the efika, which has no ISA.

> How can we determine that we have to map ISA IO or not? The Pegasos, on the
> other hand, might need it. Or maybe the Efika doesn't fit into ofppc at all,
> and should go into evbppc?
> 
> To do:
> - bootpath is missing (easy to fix)
> - ofwpci is not detected (SmartFirmware shows: /pci <at> 80000000)

Yeah.. I don't have a dump of the pci node itself for the efika. Could you cd
to /pci and do a .properties for me there?  It would help a bunch.  The match
routine just probably needs some fiddling.  I also don't have code written to
decode the reg format that the efika uses.  That code shouldn't be too hard to
write though, its the same data, just in a different format.

> - The PIC type is unknown (only 8259 and openpic supported)
> 
> I guess the last point will be the biggest task. There should be a new

(Continue reading)

headers

Frank Wille | 9 Jul 2007 22:30

Re: booting Efika with ppc-oea-renovation

Tim Rightnour wrote:

> In ofwoea_map_space it tries to do a find_ranges() call for
> RANGE_TYPE_ISA. It then looks to see if the range and cur values are zero,
> and if either are, it should exit out. I'd throw some printfs in the
> find_ranges call and try to figure out why it's not failing on the efika,
> which has no ISA.

Ok. ofwoea_map_space() returns with -1 and doesn't detect any ISA.

But the crash is caused by doing bus_map_space() in map_isa_ioregs() for the
genppc_isa_io_space_tag without the function-pointers of this structure being
ever initialized by bus_space_init(). Therefore, crash while jumping to 0!

>> - ofwpci is not detected (SmartFirmware shows: /pci <at> 80000000)
> 
> Yeah.. I don't have a dump of the pci node itself for the efika. Could you
> cd to /pci and do a .properties for me there? It would help a bunch. The
> match routine just probably needs some fiddling.

I wonder how this match routine ever worked for other systems. The problem
is in ofwpci.c, where you access a property named "device-type", but correct
would have been "device_type".

After fixing that the PCI bus is recognized and mapped, but then a crash of
OFW follows in genofw_setup_pciintr_map() while calling
  OF_getprop(parent, "#interrupt-cells", &pcells, sizeof(pcells)
with a parent-node of 0.

Refering to my previous mail, the properties of "pci" were:

(Continue reading)

headers

Matt Sealey | 9 Jul 2007 21:48

Re: booting Efika with ppc-oea-renovation

Tim Rightnour wrote:
> Yeah.. I don't have a dump of the pci node itself for the efika. Could you cd
> to /pci and do a .properties for me there?  It would help a bunch.  The match
> routine just probably needs some fiddling.  I also don't have code written to
> decode the reg format that the efika uses.  That code shouldn't be too hard to
> write though, its the same data, just in a different format.

The reg format the Efika uses is totally inconsequential. What you see in
.properties is nothing more than a pretty print.

The "decode-phys" (an Open Firmware standard function) word will happily turn
it from a property into the same long winded ssnndd00000blah blah blah PCI
address format as Apple uses. Both of them are in the PCI bus binding spec.

decode-phys is what you should use - you can loop over "assigned-addresses" with
that, and loop over "reg" with decode-phys then decode-int for start/length.

Please use the OF interface if you can.

>> - The PIC type is unknown (only 8259 and openpic supported)
>>
>> I guess the last point will be the biggest task. There should be a new
>> directory in sys/arch/powerpc, called mpc52xx, or similar, which will
>> contain all the builtin 52xx functions.
> 
> Yeah..  because it has it's own special PIC and little builtin bus, you will
> have to do some additional work there.

Well, the PIC is pretty well documented. In any case I'd make sure you are

(Continue reading)

headers

Frank Wille | 8 Jul 2007 21:38

Re: booting Efika with ppc-oea-renovation

Tim Rightnour wrote:

>> As the Efika has no ISA IO area, everything is included in the 5200B SoC,
>> I have just disabled the call and reached askroot:
> 
> In ofwoea_map_space it tries to do a find_ranges() call for
> RANGE_TYPE_ISA. It then looks to see if the range and cur values are zero,
> and if either are, it should exit out. I'd throw some printfs in the
> find_ranges call and try to figure out why it's not failing on the efika,
> which has no ISA.

Ok. Will try that tomorrow.

I had not much time for it today, as I wanted to enjoy the first day without
rain since weeks... :P

>> - ofwpci is not detected (SmartFirmware shows: /pci <at> 80000000)
> 
> Yeah.. I don't have a dump of the pci node itself for the efika. Could you
> cd to /pci and do a .properties for me there? It would help a bunch.

Here it is:

ok cd pci
ok ls
display <at> 10
display <at> 10,1
ok .properties 
name                  "pci"
device_type           "pci"

(Continue reading)

headers

Tim Rightnour | 8 Jul 2007 21:49

Re: booting Efika with ppc-oea-renovation

On 08-Jul-2007 Frank Wille wrote:
> name                  "pci"
> device_type           "pci"

Thats really odd.  The match routine must not be getting called against the
right device, or something similar, because thats exactly what it looks for.

Maybe printf up the mainbus_attach stuff down where it looks for pci bridges on
the root node, and see if it is finding the right things.

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

headers

Toru Nishimura | 3 Jul 2007 07:21

Re: NOTICE: major changes to ofppc incoming

Jochen Kunz said;

> Also: Making the console independent from bus_space(9) eases debugging
> of bus_space(9). 

Seconded...

I believe in that having comcnattach() will be a plain mistake to make
whole porting/debugging complicated and awesome enough like as
forehead bang'ng near-by wall since bus_space remains an illusion to
get materialized in very premature stage of NetBSD kernel bootstrap.
I would choose cn_tab = kcons assignment glue as early as fooinit()
which is guranteed working just as bootloader has done.

Toru Nishimura/ALKYL Technology

headers

Jochen Kunz | 3 Jul 2007 10:56

Re: NOTICE: major changes to ofppc incoming

On Tue, 3 Jul 2007 14:21:48 +0900
"Toru Nishimura" <locore64 <at> alkyltechnology.com> wrote:

> I would choose cn_tab = kcons assignment glue as early as fooinit()
> which is guranteed working just as bootloader has done.
Yesterday night I pulled the old ofcons code into machdep.c and
initialized it at the beginning of initppc(). I think it can't be done
any earlier.  I still don't get any console output. I suspect it
fails in locore.S. Frank send me some debugging code. (Thanks!) I'll
have a look at it later...
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

headers

Matt Sealey | 1 Jul 2007 11:19

Re: NOTICE: major changes to ofppc incoming

Aymeric Vincent wrote:
> Frank Wille <frank <at> phoenix.owl.de> writes:
> 
>> In ofw_consinit.c, function cninit(), the device_type is "serial", but the
>> name-property of the console_node is "failsafe" in my case. So nothing in
>> the function applies and no console is attached.
> 
> You have to use nvedit/nvstore to explicitly select serial as your IO
> system on the Efika.
> 
> Something like
> 
> " /builtin/serial" io
> 
> at the end of the script.

You should fix the NetBSD code first!

We had this discussion with the Linux guys. stdout is stdout and serial
is serial; checking for node *names* in order to attach is really out
of this world crazy.

Are you going to list every ppc serial port on every machine in there, or
just attach to the first one that says 'serial'? If stdin/sdout are set
to failsafe, then this is your console (it means there is no display
and/or keyboard pair).

Note; NetBSD should *also* be able to attach to the display node if
present. In VGA text mode (3) the firmware emulates a serial terminal

(Continue reading)

headers

Aymeric Vincent | 2 Jul 2007 12:46

Re: NOTICE: major changes to ofppc incoming


Matt Sealey wrote:

> You should fix the NetBSD code first!

Sure, but... I was just describing a workaround. They usually come  
first. 

  Aymeric

headers

Matt Sealey | 2 Jul 2007 14:25

Re: NOTICE: major changes to ofppc incoming

I think the code, as described, is doing it in totally stupid way in the
first place. No offense to the guy who wrote it :D

Just imagine, if everyone works around it using the nvramrc then any fix
won't be automatically tested. The problem is that it won't attach to
failsafe - but you changed it so it won't use failsafe. Now you need to
change it back to test the fix. I think this is too much work and effort
for something that can be just fixed, compiled and booted, and no firmware
changes need to be made whatsoever :D

--

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

Aymeric Vincent wrote:
> 
> Matt Sealey wrote:
> 
>> You should fix the NetBSD code first!
> 
> Sure, but... I was just describing a workaround. They usually come
> first. 
> 
>  Aymeric
>

headers

Jochen Kunz | 27 Jun 2007 09:35

Re: NOTICE: major changes to ofppc incoming

On Tue, 26 Jun 2007 23:17:59 +0200
Jochen Kunz <jkunz <at> unixag-kl.fh-kl.de> wrote:

> I put some printf(9) in intppc() and ofwoea_initppc() but don't get
> anything from them.
Similar on an IBM RS/6000 43P-150 / B50:

Using IP address: 192.168.1.103
root addr=192.168.1.2 path=/nfsroot/NetBSD/ofppc
2715948+223740 [160768+156767]=0x31b754
 start=0x100000
DEFAULT CATCH!, code=fff00700 at   %SRR0: 0010167c   %SRR1: 00080030 
 ok
0 >   ok
0 > 

The old ofppc code did run on this machine. So I suspect some of the
locore.S et all. changes broke it. Any ideas to debug this without
working console IO and before ddb(4) is usable?
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

headers

Makoto Fujiwara | 27 Jun 2007 10:09

panic("Could not map ISA IO") (Re: NOTICE: major changes to ofppc incoming


J> Jochen Kunz <jkunz <at> unixag-kl.fh-kl.de> wrote:

J>  start=0x100000
J> DEFAULT CATCH!, code=fff00700 at   %SRR0: 0010167c   %SRR1: 00080030 
J>  ok

This particular problem seems to panic on 598th line of
sys/arch/powerpc/oea/ofwoea_machdep.c:
   591  ofwoea_bus_space_init(void)
   592  {
   593          int error;
   594  
   595          error = ofwoea_map_space(RANGE_TYPE_ISA, RANGE_IO, -1,
   596              &genppc_isa_io_space_tag, "isa-ioport");
   597          if (error > 0)
   598                  panic("Could not map ISA IO");
   599          error = ofwoea_map_space(RANGE_TYPE_ISA, RANGE_MEM, -1,
   600              &genppc_isa_mem_space_tag, "isa-iomem");
   601          if (error > 0)
   602                  panic("Could not map ISA MEM");
   603  }

If you insert the following line on 594, output stays after start= line.
while (1) {}; 
---
Makoto Fujiwara, 
Chiba, Japan, Narita Airport and Disneyland prefecture.

(Continue reading)

headers

Matt Sealey | 27 Jun 2007 00:48

Re: NOTICE: major changes to ofppc incoming

Two quick questions

1) where do I get this tree quickly and easily (I'm loathe to guess through
cvs/svn documentation, I always seem to miss something if it's not written
in "cvs for dummies" like sourceforge has)

2) does it crosscompile? I don't have any way of building a powerpc system
from anything but a linux x86 laptop at the moment. the last time I tried
this the suggestion (from the FreeBSD team I got the same result) was for
me to buy a cheap old Mac to get the first stuff built. That's really beyond
my means and the Efika will be all I have to do any further builds (not
using it for builds means I can do more work)

--

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

Jochen Kunz wrote:
> On Sat, 23 Jun 2007 08:25:24 -0700 (MST)
> Tim Rightnour <root <at> garbled.net> wrote:
> 
>>> Hm. Any chance to have a look onto Jorge Acereda's modifications for
>>> SmartFirmware and trying to include them?
>> Hrmm.. I'm not aware of those.. got a link?
> Have a look at the mail from Jorge to this list:
> Subject: Pegasos patches
> Date: Mon, 31 Jul 2006 00:08:31 +0200
> 
>>> At the moment I don't get any output at all. Even after setting the
>>> kernel-base and textaddr to 0x400000 and including the SmartFirmware

(Continue reading)

headers

Frank Wille | 27 Jun 2007 18:49

Re: NOTICE: major changes to ofppc incoming

Matt Sealey wrote:

> 2) does it crosscompile? I don't have any way of building a powerpc system
> from anything but a linux x86 laptop at the moment. the last time I tried
> this the suggestion (from the FreeBSD team I got the same result) was for
> me to buy a cheap old Mac to get the first stuff built. That's really
> beyond my means and the Efika will be all I have to do any further builds
> (not using it for builds means I can do more work)

Is there anything easier to crosscompile than NetBSD? :)

Read the cross-compilation guides, as Jochen already pointed out.
For speed reasons I'm building NetBSD/ofppc on a NetBSD/i386 machine at the
moment, and it is as easy as this:

cd /usr/src
./build.sh -m ofppc tools
./build.sh -m ofppc -u kernel=EFIKA

You only have to create you EFIKA-config file in sys/arch/ofppc/conf first.

--

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

headers

Matt Sealey | 28 Jun 2007 00:46

Re: NOTICE: major changes to ofppc incoming

Well, I was thinking from x86 Linux. Bringing up a NetBSD in another
Virtual Machine is going to destroy my laptop (I barely have enough
for Windows and Gentoo).

I suppose I could live with it.

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

Frank Wille wrote:
> Matt Sealey wrote:
> 
>> 2) does it crosscompile? I don't have any way of building a powerpc system
>> from anything but a linux x86 laptop at the moment. the last time I tried
>> this the suggestion (from the FreeBSD team I got the same result) was for
>> me to buy a cheap old Mac to get the first stuff built. That's really
>> beyond my means and the Efika will be all I have to do any further builds
>> (not using it for builds means I can do more work)
> 
> Is there anything easier to crosscompile than NetBSD? :)
> 
> Read the cross-compilation guides, as Jochen already pointed out.
> For speed reasons I'm building NetBSD/ofppc on a NetBSD/i386 machine at the
> moment, and it is as easy as this:
> 
> cd /usr/src
> ./build.sh -m ofppc tools
> ./build.sh -m ofppc -u kernel=EFIKA
>

(Continue reading)

headers

Jochen Kunz | 28 Jun 2007 11:07

Re: NOTICE: major changes to ofppc incoming

On Wed, 27 Jun 2007 23:46:56 +0100
Matt Sealey <matt <at> genesi-usa.com> wrote:

> Well, I was thinking from x86 Linux.
You should be able to cross build NetBSD from Linux. Maybe you need a
bit of hacking to get it going. I suspect that it will just work on
Linux, given how much it has in common with NetBSD (compiler etc.).

There are people cross building NetBSD on MacOS X and Solaris. I did
cross builds on IRIX. These build environements are much more "strange"
then Linux.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

headers

Jochen Kunz | 27 Jun 2007 09:27

Re: NOTICE: major changes to ofppc incoming

On Tue, 26 Jun 2007 23:48:09 +0100
Matt Sealey <matt <at> genesi-usa.com> wrote:

> 1) where do I get this tree quickly and easily
Get source via anoncvs:
http://www.netbsd.org/docs/current/index.html
cd src/sys/arch
cvs -q up -dP -r ppcoea-renovation

> 2) does it crosscompile?
Crosscompilation is the normal way to build NetBSD for some years now.
Any POSIX compliant Unix (like) OS should be usable as build host.
http://www.netbsd.org/docs/guide/en/chap-build.html

Please don't expect somthing that will run well on the EFIKA or Pegasos.
Especially the EFIKA. As it is based on a SOC all on chip peripherals
are not attached via PCI. So all of those peripherals will need a bit
bus_space(9) / bus_dma(9) and machine dependent attachment glue.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

headers

Frank Wille | 27 Jun 2007 19:02

Re: NOTICE: major changes to ofppc incoming

Jochen Kunz wrote:

>> 1) where do I get this tree quickly and easily
> Get source via anoncvs:
> http://www.netbsd.org/docs/current/index.html
> cd src/sys/arch
> cvs -q up -dP -r ppcoea-renovation

Provided that src already contains the complete current source tree (really
current?). This confused me at first.

--

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

headers

Matt Sealey | 28 Jun 2007 00:47

Re: NOTICE: major changes to ofppc incoming

This is exactly why I asked :)

I'll work it out somehow. It looks like I will be installing NetBSD tonight
first though.

--

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

Frank Wille wrote:
> Jochen Kunz wrote:
> 
>>> 1) where do I get this tree quickly and easily
>> Get source via anoncvs:
>> http://www.netbsd.org/docs/current/index.html
>> cd src/sys/arch
>> cvs -q up -dP -r ppcoea-renovation
> 
> Provided that src already contains the complete current source tree (really
> current?). This confused me at first.
>

headers

Tim Rightnour | 28 Jun 2007 01:47

Re: NOTICE: major changes to ofppc incoming

On 27-Jun-2007 Matt Sealey wrote:
> I'll work it out somehow. It looks like I will be installing NetBSD tonight
> first though.

You actually *should* be able to cross compile from linux.  Mind you, the
cross-compiling scripts sometimes need just a bit of tweaking to get working on
linux, whereas they are pretty much guaranteed to work on NetBSD.

As for the branch itself.. a few people are a bit confused by the branch
layout.  Basically, the branch covers sys/arch only.. so the easy way to get
the sources is:

checkout the netbsd cvs tree.
cd sys/arch
cvs update -r ppcoea-renovation -dP .

Then you can keep it up to date by cd'ing to sys/arch and doing a
cvs update -dP .

Please note.. if you generate patches/fixes to the branch, I will gladly
review/commit them for you.  (This goes for anyone who isn't a developer)

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

headers

Matt Sealey | 27 Jun 2007 12:06

Re: NOTICE: major changes to ofppc incoming

Okay thanks.

The goal is not to get a desktop on the first try; I want to see where
it gets to, and see if I can do anything with it from that point.

The bus_* stuff seems like a cute thing to do :)

--

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

> Crosscompilation is the normal way to build NetBSD for some years now.
> Any POSIX compliant Unix (like) OS should be usable as build host.
> http://www.netbsd.org/docs/guide/en/chap-build.html
> 
> Please don't expect somthing that will run well on the EFIKA or Pegasos.
> Especially the EFIKA. As it is based on a SOC all on chip peripherals
> are not attached via PCI. So all of those peripherals will need a bit
> bus_space(9) / bus_dma(9) and machine dependent attachment glue.

headers

..I'd rather be coding ASM! | 27 Jun 2007 02:56

Re: NOTICE: major changes to ofppc incoming


PSIM

On Tue, 26 Jun 2007, Matt Sealey wrote:

> Two quick questions
>
> 1) where do I get this tree quickly and easily (I'm loathe to guess through
> cvs/svn documentation, I always seem to miss something if it's not written
> in "cvs for dummies" like sourceforge has)
>
> 2) does it crosscompile? I don't have any way of building a powerpc system
> from anything but a linux x86 laptop at the moment. the last time I tried
> this the suggestion (from the FreeBSD team I got the same result) was for
> me to buy a cheap old Mac to get the first stuff built. That's really beyond
> my means and the Efika will be all I have to do any further builds (not
> using it for builds means I can do more work)
>
>

headers

Matt Sealey | 27 Jun 2007 11:59

Re: NOTICE: major changes to ofppc incoming

I want to run it on the Efika board. Considering we make it.

Not a simulator.

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

..I'd rather be coding ASM! wrote:
> 
> 
> PSIM
> 
> On Tue, 26 Jun 2007, Matt Sealey wrote:
> 
>> Two quick questions
>>
>> 1) where do I get this tree quickly and easily (I'm loathe to guess
>> through
>> cvs/svn documentation, I always seem to miss something if it's not
>> written
>> in "cvs for dummies" like sourceforge has)
>>
>> 2) does it crosscompile? I don't have any way of building a powerpc
>> system
>> from anything but a linux x86 laptop at the moment. the last time I tried
>> this the suggestion (from the FreeBSD team I got the same result) was for
>> me to buy a cheap old Mac to get the first stuff built. That's really
>> beyond
>> my means and the Efika will be all I have to do any further builds (not

(Continue reading)

headers

..I'd rather be coding ASM! | 27 Jun 2007 00:51

Re: NOTICE: major changes to ofppc incoming


Where's your console set to dump?

On Tue, 26 Jun 2007, Jochen Kunz wrote:

> On Sat, 23 Jun 2007 08:25:24 -0700 (MST)
> Tim Rightnour <root <at> garbled.net> wrote:
>
>>> Hm. Any chance to have a look onto Jorge Acereda's modifications for
>>> SmartFirmware and trying to include them?
>> Hrmm.. I'm not aware of those.. got a link?
> Have a look at the mail from Jorge to this list:
> Subject: Pegasos patches
> Date: Mon, 31 Jul 2006 00:08:31 +0200
>
>>> At the moment I don't get any output at all. Even after setting the
>>> kernel-base and textaddr to 0x400000 and including the SmartFirmware
>>> fix in powerpc/powerpc/oea/ofw_subr.S (do not disable
>>> address-translation for SF).
>> No output from anything, or just after the bootloader runs, no output?
>>  What device is this on?
> I tried with an EFIKA a few minutes ago. The last thing I get is:
> Using IP address: 192.168.1.103
> root addr=192.168.1.2 path=/nfsroot/NetBSD/ofppc
> 2715948+223740 [160768+156767]=0x31b754
> start=0x100000
>
> I put some printf(9) in intppc() and ofwoea_initppc() but don't get
> anything from them.
>

(Continue reading)

headers

Jochen Kunz | 27 Jun 2007 09:10

Re: NOTICE: major changes to ofppc incoming

On Wed, 27 Jun 2007 01:51:17 +0300 (EEST)
"..I'd rather be coding ASM!" <uridium <at> deviate.fi> wrote:

> Where's your console set to dump?
You mean serial console?
Yes. I only use serial console for this type of hacking.

But it should not matter. I didn't check the new branch but in the old
code NetBSD uses only OFW calls to do console IO in early stages of
bootup. So the actual console device does not matter.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/