Arm gcc3 toolchain guru wanted

 	Mozilla needs CPU/OS/Compiler specific xptc glue for each
 	platform. NetBSD/arm has this for gcc 2.95, but not for gcc3.x.
 	Links has code for both 2.95 and 3.x. Would any ARM toolchain
 	expert be able to take a look at what would be needed to fixup
 	for NetBSD/arm and gcc3?

 	The files are in mozilla/xpcom/reflect/xptcall/src/md/unix in
 	a standard mozilla distribution (the xptcstubs_arm_netbsd.cpp
 	attached here is the one from pkgsrc which has a patch for a.out
 	support).

--

-- 
 			   David Brownlee -- abs <at> absd.org

/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/* ***** BEGIN LICENSE BLOCK *****
 * Version: NPL 1.1/GPL 2.0/LGPL 2.1
 *
 * The contents of this file are subject to the Netscape Public License
 * Version 1.1 (the "License"); you may not use this file except in
 * compliance with the License. You may obtain a copy of the License at
 * http://www.mozilla.org/NPL/

 *
 * Software distributed under the License is distributed on an "AS IS" basis,
 * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
 * for the specific language governing rights and limitations under the
 * License.
 *
 * The Original Code is mozilla.org code.
 *

Updating Shark to current/2.0

[Context is hang when running find or du over a big chunk of disk.  Advice 
was new kernel.]

Is there a ready-to-go pile of Shark bits for current?  If so, where?  I 
didn't find a shark slot in sup.   ...

This looks like the best recipe to update from 1.6 to current.
    http://www.netbsd.org/Documentation/current/#updating
Is that likely to work without much tinkering if I'm willing to let the 
machine do a lot of work?

I think I built a kernel correctly.  It boots, and ran a lot of disk activity 
without hanging.

But the network didn't work.   Will that all get better if I keep going and 
build/install a new userland.  Or will I be getting in deeper?   (Backing out 
of a new kernel is simple.  I've never tried backing out of a new userland.)

What's the schedule for 2.0?    Should I just wait a while and help with the 
official pre-release testing?

--

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Re: Updating Shark to current/2.0

On Sun, 6 Jun 2004, Hal Murray wrote:

> [Context is hang when running find or du over a big chunk of disk.  Advice
> was new kernel.]
>
> Is there a ready-to-go pile of Shark bits for current?  If so, where?  I
> didn't find a shark slot in sup.   ...
>
> This looks like the best recipe to update from 1.6 to current.
>    http://www.netbsd.org/Documentation/current/#updating
> Is that likely to work without much tinkering if I'm willing to let the
> machine do a lot of work?
>
> I think I built a kernel correctly.  It boots, and ran a lot of disk activity
> without hanging.
>
> But the network didn't work.   Will that all get better if I keep going and
> build/install a new userland.  Or will I be getting in deeper?   (Backing out
> of a new kernel is simple.  I've never tried backing out of a new userland.)
>
> What's the schedule for 2.0?    Should I just wait a while and help with the
> official pre-release testing?

 	I'd pull down a 2.0_BETA set from releng.netbsd.org

ftp://releng.netbsd.org/pub/NetBSD-daily/netbsd-2-0/200405310000/shark/

 	The new kernel should just work with the 1.6 userland, including
 	network. One way to test a new userland is to extract the
 	userland into /subdir, boot the new kernel single user and then

OMAP cannot reboot

Re: Updating Shark to current/2.0

>  	I'd pull down a 2.0_BETA set from releng.netbsd.org
> ftp://releng.netbsd.org/pub/NetBSD-daily/netbsd-2-0/200405310000/shark/

Thanks.  That's what I was looking for.  Is there an obvious link from the 
main web pages that I missed?

I tried the bits from 200406060000
There is also a 200406120000, but it only goes up to atari.  (I assume 
something died.)

The generic kernel doesn't get off the ground.  Firmware says "Data Abort" 
before the screen switches to the NetBSD booting messages.

I also tried the kernel from 200405310000 but that didn't change anything.

netbsd-INSTALL (from 200406060000) boots.  I couldn't get the network to 
work.  (which was the symptom of the kernel I built)

I'm working with a Rev4 Shark.  I can try a Rev5.  I don't think the network 
area changed.

--

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

RE: OMAP cannot reboot

Re: link_set_... sections and objcopy

On Tue, Apr 27, 2004 at 01:42:26PM -0700, Jason Thorpe wrote:
> 
> Yes.  Because explicitly listing the link sets in the linker script 
> defeats the purpose of them.  Any arbitrary code can define additional 
> link sets, which would then have to be listed here in the linker 
> script.

Since we have to live with objcopy lossage for now, how about dynamically
generating the ldscript?

The below simple script outputs the dynamic part from the kernel objects,
someone with awk knowledge could easily redo that and output the whole 
ldscript.

Martin

#! /bin/sh

SETS=`objdump -x *.o | fgrep "RELOCATION RECORDS FOR [link_set" | \
        sort -u | sed 's/^.*\[\(.*\)\]:$/\1/'`

for s in $SETS; do
        printf "  . = ALIGN(4);\n"
        printf "  PROVIDE (__start_%s = .);\n" $s
        printf "  *(%s)\n" $s
        printf "  PROVIDE (__stop_%s = .);\n" $s
done

Re: link_set_... sections and objcopy

In article <64BD8AB2-988B-11D8-A332-000A957650EC <at> wasabisystems.com>,
Jason Thorpe <thorpej <at> wasabisystems.com> wrote:
>-=-=-=-=-=-
>
>We really need to figure out how to make the a.out back-end copy them 
>reliably.

Or we need to fix the boot block to be able to load ELF?

christos

Re: link_set_... sections and objcopy

On Sat, Jun 19, 2004 at 03:03:48PM +0000, Christos Zoulas wrote:
> Or we need to fix the boot block to be able to load ELF?

There is no bootblock on shark - firmware does it all.
(And all efforts to write a working bootloader have failed so far, blamed
on firmware bugs)

Martin

Re: link_set_... sections and objcopy

On Jun 19,  5:22pm, martin <at> duskware.de (Martin Husemann) wrote:
-- Subject: Re: link_set_... sections and objcopy

| On Sat, Jun 19, 2004 at 03:03:48PM +0000, Christos Zoulas wrote:
| > Or we need to fix the boot block to be able to load ELF?
| 
| There is no bootblock on shark - firmware does it all.
| (And all efforts to write a working bootloader have failed so far, blamed
| on firmware bugs)

Right, use the firmware a.out loader to load an elf boot loader. The
elf loader will be simpler that making kernels load.

christos