Enabling Text mode on Graphics

The <frame.h> header -- mandatory or optional?

Hi,

for a while now the build of NetBSD on the MIPS ports has been
broken.  The trigger is regress/include/symbolcheck.c, which
seems to assert that <frame.h> is a mandatory header file.

 o sys/arch/Makefile installs a symlink from /usr/include/frame.h to
   /usr/include/machine/frame.h.

 o sys/arch/mips/include/Makefile does not install frame.h.

 o sys/arch/Makefile does however install a symlink from
   /usr/include/machine to /usr/include/${MACHINE}, which for
   e.g. the algor port ends up being /usr/include/algor.

 o sys/arch/algor/include/Makefile does not have a frame.h
   header, and does not install it.

Therefore, /usr/include/frame.h ends up pointing into thin air on the
MIPS ports, and this makes "make depend" in regress/symbolcheck/ fall
on it's face.

I wonder what the correct fix for this problem might be.  E.g. is
the <frame.h> header mandatory?  (I've heard some private comments
indicating that it should possibly not be mandatory.)

Regards,

- Håvard

Re: The <frame.h> header -- mandatory or optional?

On Nov 12, 2003, at 12:50 AM, Havard Eidnes wrote:

> Hi,
>
> for a while now the build of NetBSD on the MIPS ports has been
> broken.  The trigger is regress/include/symbolcheck.c, which
> seems to assert that <frame.h> is a mandatory header file.

It seems totally wrong to have a <frame.h>.  There is absolutely no 
reason to expose trapframes to userland.

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Porting to RTL8181

Hi,

I am new to NetBSD and have come across a new and cheap access point which
has a complete MIPS R3000 based SoC part on it.  Internally it has a PCI
bus, two RTL8139 10/100 ethernet MACs, an 801.11b MAC and externall 2MB of
FLASH and 8MB of SDRAM.  All that needs to be written for it as far as
NetBSD goes is the 802.11b MAC driver.  It runs Linux out of the box and
the OEM has released the Linux source code for everything bar crucial
driver stuff (like the 802.11b MAC).  It seems to me to be a great little
platform for hacking NetBSD - at AUD$99 it's a steal.

I have been trying to build NetBSD current using evbmips-eb on my Redhat
Fedora Linux machine.  The tools build fine but the cross compiled
development build fails.  I have yet to try building a kernel.

A few questions:

Is it better to try to get current working on it or 1.6.0/1?

Is writing a driver for the 802.11b MAC tricky?

All known hacking info can be found on this wiki, including data sheets
(unfortunately the JTAG BSDL file is yet to emerge from Realtek) on
http://melbourne.wireless.org.au/wiki?minitar

--

-- 
Cheers,
jASON
---------------------------------------------
--== http://www.wireless.org.au/~jhecker ==--
---------------------------------------------

Re: Porting to RTL8181

Hi Jason,

On Tue, Nov 25, 2003 at 05:50:19PM +1100, Jason Hecker wrote:

> I am new to NetBSD and have come across a new and cheap access point which
> has a complete MIPS R3000 based SoC part on it.  Internally it has a PCI
> bus, two RTL8139 10/100 ethernet MACs, an 801.11b MAC and externall 2MB of
> FLASH and 8MB of SDRAM.  All that needs to be written for it as far as
> NetBSD goes is the 802.11b MAC driver.  It runs Linux out of the box and
> the OEM has released the Linux source code for everything bar crucial
> driver stuff (like the 802.11b MAC).  It seems to me to be a great little
> platform for hacking NetBSD - at AUD$99 it's a steal.

The MIPS core is a Lexra core - we currently don't support any of those.
I'm not sure offhand how it's MMU differs from a standard R3000 MMU,
but especially with another OS's source code available you'd think it
shouldn't be too hard to get working.

> I have been trying to build NetBSD current using evbmips-eb on my Redhat
> Fedora Linux machine.  The tools build fine but the cross compiled
> development build fails.  I have yet to try building a kernel.
> 
> A few questions:
> 
> Is it better to try to get current working on it or 1.6.0/1?

-current; if we add a port for this device to our tree it'll go
in -current.  How are your builds failing?

> Is writing a driver for the 802.11b MAC tricky?

Good question!  I don't know how an 802.11 MAC differs from a "normal"
one.  Maybe tech-net <at> netbsd.org would be a good place to ask.

In all, looks like an interesting project.  I might grab one myself.
Questions about general MIPS info (like support for the Lexra core)
should go to this list.  Questions about the box itself are better
suited to say port-evbmips <at> netbsd.org but that list has almost no
subscribers and I can't recall the last time there was a message on
it, so probably send those questions to this list too.

Simon.
--
Simon Burge                                   <simonb <at> wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/

Re: Porting to RTL8181

Minitar are actively supporting hacking of the AP with their own forums 
http://www.minitar.com/forums/index.php?showforum=14

> -current; if we add a port for this device to our tree it'll go
> in -current.  How are your builds failing?

Using (In Redhat Fedora Core 1 which has GCC3.3 as it's primary compiler):

[blah <at> blah src]$ ./build.sh -m evbmips-eb -T /home/blah/netbsd/tools -R 
/home/blah/netbsd/release -D /home/blah/netbsd/dest  -O 
/home/blah/netbsd/objs -u -U tools distribution

It ends up stopping at the point below.  Luke thought it might be a problem 
with the PC variable in termcap.h colliding with PC in one of the MIPS 
headers.  I am not sure how to resolve this myself... :(

dependall ===> regress/include/bitstring
#      link  bitstring/bitstring_test
/home/blah/netbsd/tools/bin/mipseb--netbsd-gcc    -o bitstring_test -nostdlib  
-Wl,-rpath-link,/home/blah/netbsd/dest/lib:/home/blah/netbsd/dest/usr/lib  
-L/home/blah/netbsd/dest/lib /home/blah/netbsd/dest/usr/lib/crt0.o 
/home/blah/netbsd/dest/usr/lib/crti.o 
/home/blah/netbsd/dest/usr/lib/crtbegin.o bitstring_test.o  
-L/home/blah/netbsd/dest/usr/lib -L/home/blah/netbsd/dest/usr/lib  -lgcc -lc 
-lgcc /home/blah/netbsd/dest/usr/lib/crtend.o 
/home/blah/netbsd/dest/usr/lib/crtn.o
dependall ===> regress/include/okheaders
#   compile  okheaders/symbolcheck.o
/home/blah/netbsd/tools/bin/mipseb--netbsd-gcc -O2  -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional 
-Wno-uninitialized -Wreturn-type -Wswitch -Wshadow  -Werror    -nostdinc 
-isystem /home/blah/netbsd/dest/usr/include  -c    
/home/blah/netbsd/src/regress/include/okheaders/symbolcheck.c
In file included from /home/blah/netbsd/dest/usr/include/curses.h:42,
                 from 
/home/blah/netbsd/src/regress/include/okheaders/symbolcheck.c:222:
/home/blah/netbsd/dest/usr/include/termcap.h:67: error: parse error before 
numeric constant

*** Failed target:  symbolcheck.o
*** Failed command: /home/blah/netbsd/tools/bin/mipseb--netbsd-gcc -O2 -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare 
-Wno-traditional -Wno-uninitialized -Wreturn-type -Wswitch -Wshadow -Werror 
-nostdinc -isystem /home/blah/netbsd/dest/usr/include -c 
/home/blah/netbsd/src/regress/include/okheaders/symbolcheck.c
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src/regress/include/okheaders

*** Failed target:  dependall
*** Failed command: cd /home/blah/netbsd/src/regress/include/okheaders; 
/home/blah/netbsd/tools/bin/nbmake realall
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src/regress/include/okheaders

*** Failed target:  dependall-okheaders
*** Failed command: targ=dependall;dir=okheaders; case "$dir" in /*) echo 
"$targ ===> $dir"; cd "$dir"; /home/blah/netbsd/tools/bin/nbmake 
"_THISDIR_=$dir/" $targ; ;; *) echo "$targ ===> regress/include/$dir"; cd 
"/home/blah/netbsd/src/regress/include/$dir"; 
/home/blah/netbsd/tools/bin/nbmake "_THISDIR_=regress/include/$dir/" $targ; 
;; esac
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src/regress/include

*** Failed target:  dependall-include
*** Failed command: targ=dependall;dir=include; case "$dir" in /*) echo "$targ 
===> $dir"; cd "$dir"; /home/blah/netbsd/tools/bin/nbmake "_THISDIR_=$dir/" 
$targ; ;; *) echo "$targ ===> regress/$dir"; cd 
"/home/blah/netbsd/src/regress/$dir"; /home/blah/netbsd/tools/bin/nbmake 
"_THISDIR_=regress/$dir/" $targ; ;; esac
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src/regress

*** Failed target:  dependall-regress
*** Failed command: targ=dependall;dir=regress; case "$dir" in /*) echo "$targ 
===> $dir"; cd "$dir"; /home/blah/netbsd/tools/bin/nbmake "_THISDIR_=$dir/" 
$targ; ;; *) echo "$targ ===> $dir"; cd "/home/blah/netbsd/src/$dir"; 
/home/blah/netbsd/tools/bin/nbmake "_THISDIR_=$dir/" $targ; ;; esac
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src

*** Failed target:  do-build
*** Failed command: (cd /home/blah/netbsd/src && 
/home/blah/netbsd/tools/bin/nbmake dependall BUILD_tools=no BUILD_lib=no)
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src

*** Failed target:  build
*** Failed command: (cd /home/blah/netbsd/src && 
/home/blah/netbsd/tools/bin/nbmake do-build)
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src

*** Failed target:  distribution
*** Failed command: (cd /home/blah/netbsd/src && 
/home/blah/netbsd/tools/bin/nbmake NOPOSTINSTALL=1 build)
*** Error code 1

Stop.
nbmake: stopped in /home/blah/netbsd/src

ERROR: Failed to make distribution
*** BUILD ABORTED ***

Re: Porting to RTL8181

Jason Hecker wrote:

> It ends up stopping at the point below.  Luke thought it might be a problem 
> with the PC variable in termcap.h colliding with PC in one of the MIPS 
> headers.  I am not sure how to resolve this myself... :(

Just comment out okheaders from src/regress/include/Makefile
It's only a regression test, and a broken one for this platform
it seems.  Reaching as far as you did means that everything you
care about has been compiled already.

	-- Lennart

Re: Porting to RTL8181

> Just comment out okheaders from src/regress/include/Makefile
> It's only a regression test, and a broken one for this platform

Oh happy day!  That did the trick!  Built to completion.  Now for the 
kernel... It's great to see I can do this on a non-NetBSD box.

Thanks very much!

Jason Hecker

Renaming constants in regnum.h and mcontext.h?

Hi,

the newish regression test for name space pollution,
regress/include/okheaders/ currently trips up the release build all
the MIPS-based ports.

The reason is that mips/regnum.h gets included via the chain
sys/ptrace.h -> machine/ptrace.h -> mips/ptrace.h -> machine/regnum.h
-> mips/regnum.h.  The header file mips/regnum.h defines a constant,
PC, which termcap.h wants to use when declaring a global variable.

It ought to be possible to combine <termcap.h> and <sys/ptrace.h>.

My local build tree has some diffs which tackle this by hiding the
constants from mips/regnum.h from the user's name space, and which
renames the constants in mips/mcontext.h.  The diffs do basically the
following:

 o mips/mcontext.h: rename _REG_xxx to _MC_REG_xxx (mostly to make
   room for the subsequent rename in regnum.h)

 o mips/regnum.h: add _REG_ prefix to the register names, and move
   FPBASE to _FPBASE

The diffs also clean up all the uses of these constants in the tree,
and I have completed release builds for all the MIPS-based ports with
these diffs.

Can anyone think of a good reason I should not go ahead and commit
this set of changes?

Regards,

- Håvard

Re: Renaming constants in regnum.h and mcontext.h?

On Nov 25, 2003, at 4:12 AM, Havard Eidnes wrote:

>  o mips/mcontext.h: rename _REG_xxx to _MC_REG_xxx (mostly to make
>    room for the subsequent rename in regnum.h)

How about not doing this part...

>  o mips/regnum.h: add _REG_ prefix to the register names, and move
>    FPBASE to _FPBASE

...and using _R_ instead of _REG_ here?

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>