headers
Chris Gilbert | 4 Oct 2003 17:48
Picon

Experimental ABLE firmware support

Hi,

Just a quick email to let people know that -current now has support for
ABLE firmware.  Both running a.out and ELF kernels.

Note that currently there are issues with ABLE that I'm working with
simtec to resolve.  These include:
Not booting from ffs
bootargs not being passed in
Note my testing hasn't been that thorough, I can boot kernels from
tftpboot via my tulip/de card, but you have to enter by hand the root
device, etc.  So I'd not recommend ABLE for those who need a system that
just boots.

Something I'm still looking into is how to handle symbol support on ELF
kernels.  Not sure if we need to do the SYMTAB_SPACE trick still.

Cheers,
Chris
Permalink | Reply | 0 comments |
headers
Mike Pumford | 4 Oct 2003 19:08
Picon
Picon

Issues with new i2c framework on acorn32 and acorn26

As I've already reported on current-users the new i2c framework has
broken the acorn32 port kernels. On digging a bit deeper it appears that
the acorn26 port is also broken but in a different way.

On acorn32 the new i2c framework conflicts with the port specific code
in sys/arch/arm/iomd/ 
This means that it is impossible to configure a usable kernel on this
device.

On acorn26 when the conversion to the new i2c framework it appears that
a file has not been committed. sys/arch/acorn26/conf/files.acorn26
declares that the ioc i2c support is in a file called
sys/arch/acorn26/ioc/iociic.c which does not appear in CVS.

I may be able to resolve the i2c issue for acorn32 but if the acorn26
support was complete it would probably make a better starting point than
the current source tree state.

Mike
Permalink | Reply | 3 comments |
headers
Jason Thorpe | 4 Oct 2003 20:55

Re: Issues with new i2c framework on acorn32 and acorn26


On Saturday, October 4, 2003, at 10:08  AM, Mike Pumford wrote:

> On acorn26 when the conversion to the new i2c framework it appears that
> a file has not been committed. sys/arch/acorn26/conf/files.acorn26
> declares that the ioc i2c support is in a file called
> sys/arch/acorn26/ioc/iociic.c which does not appear in CVS.

I'll take a look shortly... I must have forgot a couple of "cvs add" 
and "cvs delete" commands.

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
Matt Thomas | 4 Oct 2003 21:21

Re: SA_SIGINFO changes


On Saturday, September 13, 2003, at 01:20 PM, Chris Gilbert wrote:

> Hi,
>
> I've been working on porting the SA_SIGINFO code onto arm, and was
> wondering if people could review the attached files.

Modulo fix a few rejects, the patches are running run on my shark.
--

-- 
Matt Thomas                     email: matt <at> 3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this 
message.
Permalink | Reply | 0 comments |
headers
Chris Gilbert | 5 Oct 2003 20:58
Picon

Re: Issues with new i2c framework on acorn32 and acorn26

It's also upset the cats builds, the new i2c added a dsrtc device, which
somehow (not figured out how) ends up being part of a config on cats.

Chris

On Sat, 4 Oct 2003 18:08:55 +0100
Mike Pumford <mpumford <at> black-star.demon.co.uk> wrote:

> As I've already reported on current-users the new i2c framework has
> broken the acorn32 port kernels. On digging a bit deeper it appears
> that the acorn26 port is also broken but in a different way.
> 
> On acorn32 the new i2c framework conflicts with the port specific code
> in sys/arch/arm/iomd/ 
> This means that it is impossible to configure a usable kernel on this
> device.
> 
> On acorn26 when the conversion to the new i2c framework it appears
> that a file has not been committed.
> sys/arch/acorn26/conf/files.acorn26 declares that the ioc i2c support
> is in a file called sys/arch/acorn26/ioc/iociic.c which does not
> appear in CVS.
> 
> I may be able to resolve the i2c issue for acorn32 but if the acorn26
> support was complete it would probably make a better starting point
> than the current source tree state.
> 
> Mike
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Thorpe | 6 Oct 2003 18:12

Re: Issues with new i2c framework on acorn32 and acorn26


On Saturday, October 4, 2003, at 10:08  AM, Mike Pumford wrote:

> As I've already reported on current-users the new i2c framework has
> broken the acorn32 port kernels. On digging a bit deeper it appears 
> that
> the acorn26 port is also broken but in a different way.

Ok, I have fixed the acorn32 and acorn26 problems:

	- acorn26: I forgot to "cvs add" a file.
	- acorn32: I forgot to include the arch/arm/iomd directory
	  on my "cvs ci" command.

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 1 comment |
headers
Mike Pumford | 8 Oct 2003 22:34
Picon
Picon

More acorn32 breakage (was Re: Issues with new i2c framework)

On Mon, 6 Oct 2003 09:12:35 -0700
Jason Thorpe <thorpej <at> wasabisystems.com> wrote:

> Ok, I have fixed the acorn32 and acorn26 problems:
> 
> 	- acorn26: I forgot to "cvs add" a file.
> 	- acorn32: I forgot to include the arch/arm/iomd directory
> 	  on my "cvs ci" command.
> 
Thanks this looks good. However I have found another couple of
problems.

Problem 1:
Syntax error in GENERIC for new ATA bus attachments.
GENERIC line 233 has:
wd*	at atabus? ? drive ?
which should be:
wd*	at atabus?  drive ?

and at line 296:
atabus*	at dtide? channel
which should be 
atabus*	at dtide? channel ?

I've attached a patch for this to this message. I have not checked if
the other kernel configs have been updated correctly.

Fixing these leads to:

Problem 2:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Earnshaw | 9 Oct 2003 11:46
Favicon

Re: More acorn32 breakage (was Re: Issues with new i2c framework)


> 
> Problem 2:
> /usr/tools//bin/arm--netbsdelf-gcc   -ffreestanding  -O2 -march=armv3m
> -mtune=strongarm -Wcomment -Werror -Wall -Wno-main
> -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
> -Wstrict-prototypes -Wno-sign-compare -Wno-uninitialized  -Darm32 -I. 
> -I/work/src/sys/arch -I/work/src/sys -nostdinc -DNMBCLUSTERS="0x800"
> -DNBUF="0x800" -DLKM -DARM32_PMAP_NEW -DMAXUSERS=32 -D_KERNEL
> -D_KERNEL_OPT   -c
> /work/src/sys/arch/arm/arm32/fault.c/var/tmp//ccKPl5KD.s: Assembler
> messages:/var/tmp//ccKPl5KD.s:184: Error: selected processor does not
> support `ldrh r1,[r5]'
> 
> *** Failed target:  fault.o
> 
> 
> 
> fault.c contains an ARMV4 specific instruction ldrh. Which is not
> available on ARM6/7 and even StrongARM on acorn32 due to limitations of
> the CPU bus. I'm not sure what the correct fix for this is. Looking at
> CVS this has been in the code since revision 1.3 of this file but the
> new tools are being more strict and complaining about the problem.
> 

Well, the bad instruction is in badaddr_read, which is currently only 
needed for PCI support.   And PCI support is going to be unlikely on any 
machine that doesn't support ldrh.  So why not just include "opt_pci.h and 
wrap the entire badaddr_read function in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jaromir Dolecek | 11 Oct 2003 14:58
Picon

Changing /dev/zero minor for ARM

I'd like to get rid of ARM having different /dev/zero minor number
than all other archs. Anyone sees a problem with this change?
The MAKEDEVs for ARM ports would need to be adjusted to create
/dev/zero with minor 12 too, of course.

Jaromir

Index: sys/conf.h
===================================================================
RCS file: /cvsroot/src/sys/sys/conf.h,v
retrieving revision 1.112
diff -u -p -r1.112 conf.h
--- sys/conf.h	7 Aug 2003 16:34:00 -0000	1.112
+++ sys/conf.h	11 Oct 2003 12:54:02 -0000
 <at>  <at>  -199,11 +199,8  <at>  <at>  extern struct swdevt swdevt[];
 #define	DEV_MEM		0	/* minor device 0 is physical memory */
 #define	DEV_KMEM	1	/* minor device 1 is kernel memory */
 #define DEV_NULL	2	/* minor device 2 is EOF/rathole */
-#ifdef __arm__			/* XXX: FIX ME ARM! */
-#define DEV_ZERO	3	/* minor device 3 is '\0'/rathole */
-#else
+#define _DEV_ZERO_oARM	3	/* reserved: old /dev/zero for __arm__ */
 #define DEV_ZERO	12	/* minor device 12 is '\0'/rathole */
-#endif

 #endif /* _KERNEL */

Index: arch/arm/arm32/mem.c
===================================================================
RCS file: /cvsroot/src/sys/arch/arm/arm32/mem.c,v
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Gilbert | 11 Oct 2003 21:18
Picon

Re: Changing /dev/zero minor for ARM

Why?  Is there a reason for the change (yes I know it's strange, but
then so are some of the arm ports major's as well.)

Shouln't the diff also check these defines:
COMPAT_15 COMPAT_14 COMPAT_13 COMPAT_12 
bearing in mind that acorn32 is actually older than most people expect.

Also I assume you'd do the MAKEDEV changes for all the arm based archs?

Chris

On Sat, 11 Oct 2003 14:58:21 +0200 (CEST)
Jaromir Dolecek <jdolecek <at> netbsd.org> wrote:

> I'd like to get rid of ARM having different /dev/zero minor number
> than all other archs. Anyone sees a problem with this change?
> The MAKEDEVs for ARM ports would need to be adjusted to create
> /dev/zero with minor 12 too, of course.
> 
> Jaromir
> 
> Index: sys/conf.h
> ===================================================================
> RCS file: /cvsroot/src/sys/sys/conf.h,v
> retrieving revision 1.112
> diff -u -p -r1.112 conf.h
> --- sys/conf.h	7 Aug 2003 16:34:00 -0000	1.112
> +++ sys/conf.h	11 Oct 2003 12:54:02 -0000
>  <at>  <at>  -199,11 +199,8  <at>  <at>  extern struct swdevt swdevt[];
>  #define	DEV_MEM		0	/* minor device 0 is physical memory */
(Continue reading)

Permalink | Reply | 0 comments |

Gmane