From bugmaster at FreeBSD.org  Mon Jun  1 11:06:47 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jun  1 11:07:33 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200906011106.n51B6kAR020990@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From imp at bsdimp.com  Mon Jun  1 23:55:46 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon Jun  1 23:55:53 2009
Subject: svn commit: r193282 - stable/7/sys/libkern
In-Reply-To: <200906012209.n51M9gTU094161@svn.freebsd.org>
References: <200906012209.n51M9gTU094161@svn.freebsd.org>
Message-ID: <20090601.175146.255408209.imp@bsdimp.com>

In message: <200906012209.n51M9gTU094161@svn.freebsd.org>
            Kip Macy <kmacy@FreeBSD.org> writes:
: Author: kmacy
: Date: Mon Jun  1 22:09:42 2009
: New Revision: 193282
: URL: http://svn.freebsd.org/changeset/base/193282
: 
: Log:
:   memmove is defined in support.S on arm - don't compile in
: 
: Modified:
:   stable/7/sys/libkern/memmove.c
: 
: Modified: stable/7/sys/libkern/memmove.c
: ==============================================================================
: --- stable/7/sys/libkern/memmove.c	Mon Jun  1 22:05:08 2009	(r193281)
: +++ stable/7/sys/libkern/memmove.c	Mon Jun  1 22:09:42 2009	(r193282)
: @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$");
:  
:  #include <sys/libkern.h>
:  
: +#if !defined(__arm__)
:  void *
:  memmove(void *dest, const void *src, size_t n)
:  {
: @@ -36,3 +37,4 @@ memmove(void *dest, const void *src, siz
:  	bcopy(src, dest, n);
:  	return (dest);
:  }
: +#endif

Ummm, usually we don't bother to even include the .c file in cases
like this...  Is it this way in -head?


Warner
From kmacy at freebsd.org  Tue Jun  2 00:41:32 2009
From: kmacy at freebsd.org (Kip Macy)
Date: Tue Jun  2 00:41:38 2009
Subject: svn commit: r193282 - stable/7/sys/libkern
In-Reply-To: <20090601.175146.255408209.imp@bsdimp.com>
References: <200906012209.n51M9gTU094161@svn.freebsd.org>
	<20090601.175146.255408209.imp@bsdimp.com>
Message-ID: <3c1674c90906011709g757a3abds75a0cde8927bc46b@mail.gmail.com>

No, this is a band-aid for a mistake I made in the ZFS MFC. I had
hoped to avoid updating all the files.<arch>, but I will do that if
need be.

Cheers,
Kip



On Mon, Jun 1, 2009 at 4:51 PM, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <200906012209.n51M9gTU094161@svn.freebsd.org>
> ? ? ? ? ? ?Kip Macy <kmacy@FreeBSD.org> writes:
> : Author: kmacy
> : Date: Mon Jun ?1 22:09:42 2009
> : New Revision: 193282
> : URL: http://svn.freebsd.org/changeset/base/193282
> :
> : Log:
> : ? memmove is defined in support.S on arm - don't compile in
> :
> : Modified:
> : ? stable/7/sys/libkern/memmove.c
> :
> : Modified: stable/7/sys/libkern/memmove.c
> : ==============================================================================
> : --- stable/7/sys/libkern/memmove.c ? ?Mon Jun ?1 22:05:08 2009 ? ? ? ?(r193281)
> : +++ stable/7/sys/libkern/memmove.c ? ?Mon Jun ?1 22:09:42 2009 ? ? ? ?(r193282)
> : @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$");
> :
> : ?#include <sys/libkern.h>
> :
> : +#if !defined(__arm__)
> : ?void *
> : ?memmove(void *dest, const void *src, size_t n)
> : ?{
> : @@ -36,3 +37,4 @@ memmove(void *dest, const void *src, siz
> : ? ? ? bcopy(src, dest, n);
> : ? ? ? return (dest);
> : ?}
> : +#endif
>
> Ummm, usually we don't bother to even include the .c file in cases
> like this... ?Is it this way in -head?
>
>
> Warner
>



-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

    Edmund Burke
From vassilis.laganakos at yahoo.com  Tue Jun  2 11:59:18 2009
From: vassilis.laganakos at yahoo.com (Vassilis Laganakos)
Date: Tue Jun  2 11:59:54 2009
Subject: ARMv7 - EABI - Cross Compiler
Message-ID: <77926.36276.qm@web59405.mail.ac4.yahoo.com>

Hello,

I recently started working on getting a later version of GCC as a cross-compiler for FreeBSD.
The main reason is that I'm interested in having support for the "new" ARM EABI that will give 
the benefits of ARMv5TE onwards, to all the boards that use it (Mistral EVM, BeagleBoard, etc)

I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527), using the 7-STABLE headers where appropriate. 
I'm now trying to built libc from the same branch. I'm trying to pull out libc from the building tree, and
build it with the above toolchain so that it will be available to use it with that (once done, I'll commit a port for this); 
at the same time I'm try to drop the GCC 4.4.1 in the build tree to be able to use it for building the world.

Please let me know whether I'm  going down the wrong path or not :o) Tips and advice pointers towards
the right direction would be more than helpful!

I don't know if someone else is working on something similar, but if the answer is "yes" I would be quite 
happy to be of help. If not, any kind of help would be most appreciated :o)

Kind regards,
Vassilis L.



      
From sam at freebsd.org  Tue Jun  2 17:17:10 2009
From: sam at freebsd.org (Sam Leffler)
Date: Tue Jun  2 17:17:22 2009
Subject: cache corruption patch
In-Reply-To: <200905282320.n4SNK87M043401@casselton.net>
References: <200905282320.n4SNK87M043401@casselton.net>
Message-ID: <4A25566C.7020806@freebsd.org>

Mark Tinguely wrote:
> There has been several occurrences of memory corruption in ARM due to caching
> issues. A couple recent examples are problems with the SATA drive and new USB
> code.
>
> This patch tracks kernel mapped pages and detects when they are shared
> with existing user mapped pages and other kernel mapped pages. This patch
> has gone through some refinement in the last couple days with feed back
> from testers and is getting ready for being committed before the FreeBSD 8.0
> freeze.
>
> This patch should allow the removal of added cache invalidation commands to
> the dma. 
>
> The patch is located at:
>
> 	http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
>
> For those interested, I can give a long explanation of the patch.
>   

Have you measured the overhead of this additional state tracking 
(time+space)?  It appears to affect only dma buffers.

Not sure what "added cache invalidation commands" you're referring to, 
can you explain?  Perhaps you could just provide a separate patch that 
shows which bus_dma ops you think can go away.

    Sam

From sam at freebsd.org  Tue Jun  2 17:17:11 2009
From: sam at freebsd.org (Sam Leffler)
Date: Tue Jun  2 17:17:22 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <77926.36276.qm@web59405.mail.ac4.yahoo.com>
References: <77926.36276.qm@web59405.mail.ac4.yahoo.com>
Message-ID: <4A2555C8.8040405@freebsd.org>

Vassilis Laganakos wrote:
> Hello,
>
> I recently started working on getting a later version of GCC as a cross-compiler for FreeBSD.
> The main reason is that I'm interested in having support for the "new" ARM EABI that will give 
> the benefits of ARMv5TE onwards, to all the boards that use it (Mistral EVM, BeagleBoard, etc)
>
> I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527), using the 7-STABLE headers where appropriate. 
> I'm now trying to built libc from the same branch. I'm trying to pull out libc from the building tree, and
> build it with the above toolchain so that it will be available to use it with that (once done, I'll commit a port for this); 
> at the same time I'm try to drop the GCC 4.4.1 in the build tree to be able to use it for building the world.
>
> Please let me know whether I'm  going down the wrong path or not :o) Tips and advice pointers towards
> the right direction would be more than helpful!
>
> I don't know if someone else is working on something similar, but if the answer is "yes" I would be quite 
> happy to be of help. If not, any kind of help would be most appreciated :o)
>
>   

Your basic approach sounds fine.  I believe you will find many small 
changes to base code required by the later version of gcc (depending on 
compile options).  If you work with HEAD instead of RELENG_7 then these 
changes can likely be merged and will simplify your effort in the 
future.  Ideally you should be able to install the gcc port, pull 
freebsd code, and then use the xdev  build mechanism to cross-build w/ 
the toolchain.

    Sam

From stas at FreeBSD.org  Tue Jun  2 17:57:35 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Tue Jun  2 17:58:11 2009
Subject: cache corruption patch
In-Reply-To: <4A25566C.7020806@freebsd.org>
References: <200905282320.n4SNK87M043401@casselton.net>
	<4A25566C.7020806@freebsd.org>
Message-ID: <20090602215731.94a19635.stas@FreeBSD.org>

On Tue, 02 Jun 2009 09:42:20 -0700
Sam Leffler <sam@freebsd.org> mentioned:

> 
> Not sure what "added cache invalidation commands" you're referring to, 
> can you explain?  Perhaps you could just provide a separate patch that 
> shows which bus_dma ops you think can go away.
> 

I suppose he refers to Marcel's r192323 commit that added implicit data
cache invalidation for non-DMA requests.

-- 
Stanislav Sedov
ST4096-RIPE

!DSPAM:4a25680c994291921440317!


From tinguely at casselton.net  Tue Jun  2 18:39:31 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue Jun  2 18:39:37 2009
Subject: cache corruption patch
In-Reply-To: <4A25566C.7020806@freebsd.org>
Message-ID: <200906021839.n52IdSrY002806@casselton.net>


>  Have you measured the overhead of this additional state tracking 
>  (time+space)?  It appears to affect only dma buffers.

no, I haven't tracked the overhead of tracking and turning off the cache for
the multiply mapped page versus flushing the entire cache.

For space, the patch costs us 4 bytes/page. I removed 16 bytes/page
when I re-implemented the cache fixing routines (from pmap_vac_me_harder()
from NetBSD and in -7.x to pmap_fix_cache() which is new for -8.x). The
main reason to re-implement the cache fixing routines was to fix the
"big O" factor on the routines.

Right now we have the potential of stale caches any time a kernel mapped
page is shared with a user or another kernel mapping. Things like mmap
comes to mind.

>  Not sure what "added cache invalidation commands" you're referring to, 
>  can you explain?  Perhaps you could just provide a separate patch that 
>  shows which bus_dma ops you think can go away.

Yes, without the patch, some people placed cache flushes in the DMA sync
routines. That did solve the obvious problem. Those flushes are not in
the ARM code and the patch does not remove them.

A few months back, when new USB stack brought the cache problems to the
foreground, others mention strange intermittent memory corruption that
pointed to stale caches. We could start sticking in cache flushes for
each new one that pops up, but it seemed like a game of russian roulette.

--Mark.
From vassilis.laganakos at yahoo.com  Tue Jun  2 22:30:38 2009
From: vassilis.laganakos at yahoo.com (Vassilis Laganakos)
Date: Tue Jun  2 22:30:46 2009
Subject: ARMv7 - EABI - Cross Compiler
Message-ID: <180520.87347.qm@web59402.mail.ac4.yahoo.com>



Hello Sam,

----- Original Message ----
> From: Sam Leffler <sam@freebsd.org>
> To: Vassilis Laganakos <vassilis.laganakos@yahoo.com>
> Cc: freebsd-arm@freebsd.org
> Sent: Tuesday, June 2, 2009 5:39:36 PM
> Subject: Re: ARMv7 - EABI - Cross Compiler
> 
> Vassilis Laganakos wrote:
> > Hello,
> > 
> > I recently started working on getting a later version of GCC as a 
> cross-compiler for FreeBSD.
> > The main reason is that I'm interested in having support for the "new" ARM 
> EABI that will give the benefits of ARMv5TE onwards, to all the boards that use 
> it (Mistral EVM, BeagleBoard, etc)
> > 
> > I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527), using the 
> 7-STABLE headers where appropriate. I'm now trying to built libc from the same 
> branch. I'm trying to pull out libc from the building tree, and
> > build it with the above toolchain so that it will be available to use it with 
> that (once done, I'll commit a port for this); at the same time I'm try to drop 
> the GCC 4.4.1 in the build tree to be able to use it for building the world.
> > 
> > Please let me know whether I'm  going down the wrong path or not :o) Tips and 
> advice pointers towards
> > the right direction would be more than helpful!
> > 
> > I don't know if someone else is working on something similar, but if the 
> answer is "yes" I would be quite happy to be of help. If not, any kind of help 
> would be most appreciated :o)
> > 
> >  
> 
> Your basic approach sounds fine.  
>
Thanks for confirming the sanity of the approach. It's good to know that I'm walking
the right path. :o)

> I believe you will find many small changes to 
> base code required by the later version of gcc (depending on compile options).  
>
Ok, I'll log everything down.

> If you work with HEAD instead of RELENG_7 then these changes can likely be 
> merged and will simplify your effort in the future.  
>
Great. Although I want to track RELENG-7 for my box, until RELENG-8 moves to
stable :o) Would I have to use the latest binutils too, or these are already there
in HEAD?

> Ideally you should be able 
> to install the gcc port, pull freebsd code, and then use the xdev  build 
> mechanism to cross-build w/ the toolchain.
> 
Thanks for the outline. Do you mean an existing gcc port, or the port I'm trying to pull
together? Haven't used xdev before, I just build stuff by defining TARGET
and TARGET_ARCH. 

I'll look more into this and I'll get back with more results and almost certainly more 
questions! :o)

Many thanks,

Vassilis L.


      

From jhay at meraka.org.za  Wed Jun  3 15:13:34 2009
From: jhay at meraka.org.za (John Hay)
Date: Wed Jun  3 15:13:41 2009
Subject: avila on 7-stable
Message-ID: <20090603151329.GA90167@zibbi.meraka.csir.co.za>

Hi,

Is there anyone running an Avila arm board on a recent 7-stable? I have
a system built on April 1, which works fine, but I cannot get today's
source to work. The first hurdle I had was that devices connected to
the pci bus would not attach. The messages looked like this:

pci0: <PCI bus> on pcib0
ath0: <Atheros 5212> irq 28 at device 1.0 on pci0
pcib0: ath0 called activate_resource
ath0: cannot map register space
device_attach: ath0 attach returned 6

So I found svn rev 189630 that fixed that in ixp425.c and ixp425_pci.c.
Now it does find the atheroes cards on the pci bus, but it gets stuck
just after the "Trying to mount root from ufs:ad0s1a" message. Anybody
got any ideas?

John
-- 
John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
From dave at dogwood.com  Wed Jun  3 17:01:26 2009
From: dave at dogwood.com (David Cornejo)
Date: Wed Jun  3 17:01:58 2009
Subject: avila on 7-stable
Message-ID: <1955177375-1244046627-cardhu_decombobulator_blackberry.rim.net-1017842848-@bxe1204.bisx.prod.on.blackberry>

I tried this recently too - I am tftp booting and one thing I noticed, and I'm not sure is relevant, is that the board tried to get something from the tftp server but was denied. This happens right when it hangs.  (The initial kernel fetch worked) 

I haven't had time to troubleshoot what's going on. 

Dave c

------Original Message------
From: John Hay
Sender: owner-freebsd-arm@freebsd.org
To: freebsd-arm@freebsd.org
Subject: avila on 7-stable
Sent: Jun 3, 2009 05:13

Hi,

Is there anyone running an Avila arm board on a recent 7-stable? I have
a system built on April 1, which works fine, but I cannot get today's
source to work. The first hurdle I had was that devices connected to
the pci bus would not attach. The messages looked like this:

pci0: <PCI bus> on pcib0
ath0: <Atheros 5212> irq 28 at device 1.0 on pci0
pcib0: ath0 called activate_resource
ath0: cannot map register space
device_attach: ath0 attach returned 6

So I found svn rev 189630 that fixed that in ixp425.c and ixp425_pci.c.
Now it does find the atheroes cards on the pci bus, but it gets stuck
just after the "Trying to mount root from ufs:ad0s1a" message. Anybody
got any ideas?

John
-- 
John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
_______________________________________________
freebsd-arm@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"


Sent via BlackBerry from T-Mobile
From beattie at beattie-home.net  Wed Jun  3 21:48:04 2009
From: beattie at beattie-home.net (Brian Beattie)
Date: Wed Jun  3 21:48:11 2009
Subject: KB9202B
Message-ID: <1244064320.9543.44.camel@kokopelli>

I'm trying to figure out FreeBSD on arm and I'm trying to get it running
on a KwikByte 9202.  I've got a kernel that loads ovet tftp and runs,
but I can't mount a root filesystem.  I built a 2GB SD with on slice
using the method found here <http://people.freebsd.org/~xride/arm/> I
also tried mounting root via NFS (enabling NFSROOT in the kernel) trying
both entering the path name on to the mountroot prompt and setting the
root dev in the kernel config.

Any advice is welcome.  maybe a pointer to using an md root?

Console log below the sig.

-- 
"In years past, I knew of someone who used emacs as
his login shell, the only thing he found wanting in
emacs was a good text editor. So he ended up using vi."
- Anonymous
Brian Beattie<beattie@beattie-home.net>
http://www.beattie-home.net 

---------------- console log ------------------------------------
## Starting application at 0x200000E0 ...
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #2: Tue Jun  2 20:48:22 PDT 2009
    root@anansi.beattie-home.net:/usr/obj/arm/usr/src/sys/KB920X-NFS
CPU: ARM920T rev 0 (ARM9TDMI core)
  DC enabled IC enabled WB enabled LABT
  16KB/32B 64-way Instruction cache
  16KB/32B 64-way write-back-locking-A Data cache
real memory  = 67108864 (64 MB)
avail memory = 61853696 (58 MB)
atmelarm0: <AT91 device bus> on motherboard
at91_st0: <ST> mem 0xdffffd00-0xdffffdff irq 1 on atmelarm0
at91_st0: watchdog registered, timeout intervall max. 64 sec
at91_pio0: <PIOA> mem 0xdffff400-0xdffff5ff irq 1 on atmelarm0
at91_pio0: ABSR: 0x60 OSR: 0 PSR:0x3f380000 ODSR: 0
at91_pio0: [FILTER]
at91_pio1: <PIOB> mem 0xdffff600-0xdffff7ff irq 1 on atmelarm0
at91_pio1: ABSR: 0xff301 OSR: 0x2 PSR:0x3fc00cfe ODSR: 0
at91_pio1: [FILTER]
at91_pio2: <PIOC> mem 0xdffff800-0xdffff9ff irq 1 on atmelarm0
at91_pio2: ABSR: 0 OSR: 0x1000000a PSR:0xffffc075 ODSR: 0x10000000
at91_pio2: [FILTER]
at91_pio3: <PIOD> mem 0xdffffa00-0xdffffbff irq 1 on atmelarm0
at91_pio3: ABSR: 0 OSR: 0 PSR:0xfffffff ODSR: 0
at91_pio3: [FILTER]
at91_pmc0: <PMC> mem 0xdffffc00-0xdffffcff irq 1 on atmelarm0
at91_pmc0: Primary: 10000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 60 MHz
at91_mci0: <MCI mmc/sd host bridge> mem 0xdffb4000-0xdffb7fff irq 10 on
atmelarm0
at91_mci0: [ITHREAD]
mmc0: <mmc/sd bus> on at91_mci0
at91_twi0: <TWI> mem 0xdffb8000-0xdffbbfff irq 12 on atmelarm0
at91_twi0: [ITHREAD]
iicbus0: <Philips I2C bus> on at91_twi0
setting cwgr to 0x1a4a4
iicbus0: <unknown card> at addr 0
iic0: <I2C generic I/O> on iicbus0
icee0: <I2C EEPROM> at addr 0xa0 on iicbus0
ate0: <EMAC> mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0
ate0: No MAC address set
device_attach: ate0 attach returned 6
uart0: <DBGU> mem 0xdffff200-0xdffff3ff irq 1 on atmelarm0
uart0: [FILTER]?]X.???????(115200,n,8,1)
uart1: <USART0> mem 0xdffc0000-0xdffc3fff irq 6 on atmelarm0
uart1: [FILTER]
uart2: <USART1> mem 0xdffc4000-0xdffc7fff irq 7 on atmelarm0
uart2: [FILTER]
uart3: <USART2> mem 0xdffc8000-0xdffcbfff irq 8 on atmelarm0
uart3: [FILTER]
uart4: <USART3> mem 0xdffcc000-0xdffcffff irq 9 on atmelarm0
uart4: [FILTER]
at91_spi0: <SPI> mem 0xdffe0000-0xdffe3fff irq 13 on atmelarm0
at91_spi0: [ITHREAD]
spibus0: <spibus bus> on at91_spi0
ohci0: <AT91 integrated ohci controller> mem 0xdfe00000-0xdfefffff irq
23 on atmelarm0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0
usb0 on ohci0
usb0: USB revision 1.0
uhub0: <Atmel OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhub0: device problem (IOERROR), disabling port 2
Cannot get 100 Hz clock; using 100Hz
at91_st0: [FILTER]
Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000
Timecounters tick every 10.000 msec
mmc0: setting transfer rate to 30.000MHz
Trying to mount root from 172.16.0.7:/usr/kb9202

Manual root filesystem specification:
  <fstype>:<device>  Mount <device> using filesystem <fstype>
                       eg. ufs:/dev/da0a
  ?                  List valid disk boot devices
  <empty line>       Abort manual input

mountroot> 


From chuckr at telenix.org  Wed Jun  3 22:38:17 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Wed Jun  3 22:38:33 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <4A2555C8.8040405@freebsd.org>
References: <77926.36276.qm@web59405.mail.ac4.yahoo.com>
	<4A2555C8.8040405@freebsd.org>
Message-ID: <4A26FB34.7000209@telenix.org>

Sam Leffler wrote:
> Vassilis Laganakos wrote:
>> Hello,
>>
>> I recently started working on getting a later version of GCC as a
>> cross-compiler for FreeBSD.
>> The main reason is that I'm interested in having support for the "new"
>> ARM EABI that will give the benefits of ARMv5TE onwards, to all the
>> boards that use it (Mistral EVM, BeagleBoard, etc)
>>
>> I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527),
>> using the 7-STABLE headers where appropriate. I'm now trying to built
>> libc from the same branch. I'm trying to pull out libc from the
>> building tree, and
>> build it with the above toolchain so that it will be available to use
>> it with that (once done, I'll commit a port for this); at the same
>> time I'm try to drop the GCC 4.4.1 in the build tree to be able to use
>> it for building the world.
>>
>> Please let me know whether I'm  going down the wrong path or not :o)
>> Tips and advice pointers towards
>> the right direction would be more than helpful!
>>
>> I don't know if someone else is working on something similar, but if
>> the answer is "yes" I would be quite happy to be of help. If not, any
>> kind of help would be most appreciated :o)
>>
>>   
> 
> Your basic approach sounds fine.  I believe you will find many small
> changes to base code required by the later version of gcc (depending on
> compile options).  If you work with HEAD instead of RELENG_7 then these
> changes can likely be merged and will simplify your effort in the
> future.  Ideally you should be able to install the gcc port, pull
> freebsd code, and then use the xdev  build mechanism to cross-build w/
> the toolchain.

Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
"arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
me on a binary basis?
From antab at valka.is  Wed Jun  3 23:11:02 2009
From: antab at valka.is (Arnar Mar Sig)
Date: Wed Jun  3 23:11:09 2009
Subject: KB9202B
In-Reply-To: <1244064320.9543.44.camel@kokopelli>
References: <1244064320.9543.44.camel@kokopelli>
Message-ID: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>

On Jun 3, 2009, at 11:25 PM, Brian Beattie wrote:
> I'm trying to figure out FreeBSD on arm and I'm trying to get it  
> running
> on a KwikByte 9202.  I've got a kernel that loads ovet tftp and runs,
> but I can't mount a root filesystem.  I built a 2GB SD with on slice
> using the method found here <http://people.freebsd.org/~xride/arm/> I
> also tried mounting root via NFS (enabling NFSROOT in the kernel)  
> trying
> both entering the path name on to the mountroot prompt and setting the
> root dev in the kernel config.
Dont know about mmc/sd, but

>
> Any advice is welcome.  maybe a pointer to using an md root?
>
> Console log below the sig.
>
<snip>
> ate0: <EMAC> mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0
> ate0: No MAC address set
> device_attach: ate0 attach returned 6
looks like you have no working network device.

Arnar Mar Sig
From beattie at beattie-home.net  Wed Jun  3 23:59:39 2009
From: beattie at beattie-home.net (Brian Beattie)
Date: Wed Jun  3 23:59:46 2009
Subject: KB9202B
In-Reply-To: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
References: <1244064320.9543.44.camel@kokopelli>
	<2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
Message-ID: <1244073569.9543.46.camel@kokopelli>

On Thu, 2009-06-04 at 01:00 +0200, Arnar Mar Sig wrote:
> On Jun 3, 2009, at 11:25 PM, Brian Beattie wrote:
> > I'm trying to figure out FreeBSD on arm and I'm trying to get it  
> > running
> > on a KwikByte 9202.  I've got a kernel that loads ovet tftp and runs,

> >
> > Any advice is welcome.  maybe a pointer to using an md root?
> >
> > Console log below the sig.
> >
> <snip>
> > ate0: <EMAC> mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0
> > ate0: No MAC address set
> > device_attach: ate0 attach returned 6
> looks like you have no working network device.

Hmmm silly me I assumed that because I just downloaded the kernel, that
I had a working ethernet... Thanks, I'll look into that.

-- 
"In years past, I knew of someone who used emacs as
his login shell, the only thing he found wanting in
emacs was a good text editor. So he ended up using vi."
- Anonymous
Brian Beattie<beattie@beattie-home.net>
http://www.beattie-home.net 

From sam at freebsd.org  Thu Jun  4 01:36:23 2009
From: sam at freebsd.org (Sam Leffler)
Date: Thu Jun  4 01:36:29 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <4A26FB34.7000209@telenix.org>
References: <77926.36276.qm@web59405.mail.ac4.yahoo.com>	<4A2555C8.8040405@freebsd.org>
	<4A26FB34.7000209@telenix.org>
Message-ID: <4A27250B.2000100@freebsd.org>

Chuck Robey wrote:
> Sam Leffler wrote:
>   
>> Vassilis Laganakos wrote:
>>     
>>> Hello,
>>>
>>> I recently started working on getting a later version of GCC as a
>>> cross-compiler for FreeBSD.
>>> The main reason is that I'm interested in having support for the "new"
>>> ARM EABI that will give the benefits of ARMv5TE onwards, to all the
>>> boards that use it (Mistral EVM, BeagleBoard, etc)
>>>
>>> I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527),
>>> using the 7-STABLE headers where appropriate. I'm now trying to built
>>> libc from the same branch. I'm trying to pull out libc from the
>>> building tree, and
>>> build it with the above toolchain so that it will be available to use
>>> it with that (once done, I'll commit a port for this); at the same
>>> time I'm try to drop the GCC 4.4.1 in the build tree to be able to use
>>> it for building the world.
>>>
>>> Please let me know whether I'm  going down the wrong path or not :o)
>>> Tips and advice pointers towards
>>> the right direction would be more than helpful!
>>>
>>> I don't know if someone else is working on something similar, but if
>>> the answer is "yes" I would be quite happy to be of help. If not, any
>>> kind of help would be most appreciated :o)
>>>
>>>   
>>>       
>> Your basic approach sounds fine.  I believe you will find many small
>> changes to base code required by the later version of gcc (depending on
>> compile options).  If you work with HEAD instead of RELENG_7 then these
>> changes can likely be merged and will simplify your effort in the
>> future.  Ideally you should be able to install the gcc port, pull
>> freebsd code, and then use the xdev  build mechanism to cross-build w/
>> the toolchain.
>>     
>
> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
> processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
> FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
> me on a binary basis?
>   

Yes, I was thinking Warner had committed some other stuff he and I had 
talked about.  I haven't touched the buildtools in a while so not sure 
what's required specifically for freebsd (like printf extensions).

    Sam

From imp at bsdimp.com  Thu Jun  4 01:52:27 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu Jun  4 01:52:33 2009
Subject: KB9202B
In-Reply-To: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
References: <1244064320.9543.44.camel@kokopelli>
	<2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
Message-ID: <20090603.195059.1239873755.imp@bsdimp.com>

In message: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
            Arnar Mar Sig <antab@valka.is> writes:
: On Jun 3, 2009, at 11:25 PM, Brian Beattie wrote:
: > I'm trying to figure out FreeBSD on arm and I'm trying to get it  
: > running
: > on a KwikByte 9202.  I've got a kernel that loads ovet tftp and runs,
: > but I can't mount a root filesystem.  I built a 2GB SD with on slice
: > using the method found here <http://people.freebsd.org/~xride/arm/> I
: > also tried mounting root via NFS (enabling NFSROOT in the kernel)  
: > trying
: > both entering the path name on to the mountroot prompt and setting the
: > root dev in the kernel config.
: Dont know about mmc/sd, but
: 
: >
: > Any advice is welcome.  maybe a pointer to using an md root?
: >
: > Console log below the sig.
: >
: <snip>
: > ate0: <EMAC> mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0
: > ate0: No MAC address set
: > device_attach: ate0 attach returned 6
: looks like you have no working network device.

Looks like no MAC address is programmed into the MAC by the
boot loader...

Warner
From jroberson at jroberson.net  Thu Jun  4 07:21:51 2009
From: jroberson at jroberson.net (Jeff Roberson)
Date: Thu Jun  4 07:21:57 2009
Subject: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed (fwd)
Message-ID: <alpine.BSF.2.00.0906032055510.981@desktop>

Hi Folks,

I'm forwarding this in case you don't see it.  Please help test.

Thanks,
Jeff

---------- Forwarded message ----------
Date: Wed, 3 Jun 2009 20:55:39 -1000 (HST)
From: Jeff Roberson <jroberson@jroberson.net>
To: arch@freebsd.org
Subject: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed

http://people.freebsd.org/~jeff/dpcpu.diff

This patch implements dynamic per-cpu areas such that kernel code can do the 
following in a header:

DPCPU_DECLARE(uint64_t, foo);

and this in source:

DPCPU_DEFINE(uint64_t, foo) = 10;

local = DPCPU_GET(foo);
DPCPU_SET(foo, 11);

The dynamic per-cpu area of non-local cpus is accessable via 
DPCPU_ID_{GET,SET,PTR}.

If you provide an initializer as I used above that will be the default value 
when all cpus come up.  Otherwise it defaults to zero.  This is presently 
slightly more expensive than PCPU but much more flexible. Things like id and 
curthread should stay in PCPU forever.

I had to change the pcpu_init() call on every architecture to pass in storage 
for the dynamic area.  I didn't change the following three calls because it 
wasn't immediately obvious how to allocate the memory:

./powerpc/booke/machdep.c:      pcpu_init(pc, 0, sizeof(struct pcpu));
./mips/mips/machdep.c:  pcpu_init(&__pcpu[0], 0, sizeof(struct pcpu));
./mips/mips/machdep.c:  pcpu_init(pcpup, 0, sizeof(struct pcpu));


I have not tested anything other than amd64.  If you have a !amd64 
architecture, in particular any of the embedded architectures, I would really 
appreciate it.  Some of the arm boards postincrement the end address to 
allocate early memory and some pre-decriment.  Hopefully I got it right.

Thanks,
Jeff
From gballet at gmail.com  Thu Jun  4 13:12:29 2009
From: gballet at gmail.com (Guillaume Ballet)
Date: Thu Jun  4 13:12:35 2009
Subject: ARMv7 - EABI - Cross Compiler
Message-ID: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>

> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
> processor until 4.3.0. ?I was able to build a cross-gcc easily using a target of
> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
> FreeBSD. ?I'll worry about getting that gcc into the build, but will it work for
> me on a binary basis?
>

I used arm-none-eabi to compile my loader for the BeagleBoard so as to
get rid of the linux-specific stuff by default. But maybe you should
define something like arm-freebsd-eabi in gcc's build configuration?
From vassilis.laganakos at yahoo.com  Thu Jun  4 14:01:00 2009
From: vassilis.laganakos at yahoo.com (Vassilis Laganakos)
Date: Thu Jun  4 14:01:30 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
References: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
Message-ID: <360403.90502.qm@web59402.mail.ac4.yahoo.com>




> > Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?

> > That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
> > processor until 4.3.0.  I was able to build a cross-gcc easily using a target 
> of
> > "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
> > FreeBSD.  I'll worry about getting that gcc into the build, but will it work 
> for
> > me on a binary basis?
> >
> 
> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
> get rid of the linux-specific stuff by default. But maybe you should
> define something like arm-freebsd-eabi in gcc's build configuration?
>
The arm-none-eabi will give you stuff for bare-metal applications, and the 
arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now, 
from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1 
and it wouldn't accept it. 

What I've build is arm-unknown-freebsd, although the "unknown" part could
be ommited. Please bear with me while I look for the URL I found the naming
conventions...

Thanks,
Vasi



      

From gballet at gmail.com  Thu Jun  4 15:24:02 2009
From: gballet at gmail.com (Guillaume Ballet)
Date: Thu Jun  4 15:24:11 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <360403.90502.qm@web59402.mail.ac4.yahoo.com>
References: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
	<360403.90502.qm@web59402.mail.ac4.yahoo.com>
Message-ID: <fd183dc60906040824w3d70fad6p887c610fd7560bf8@mail.gmail.com>

> The arm-none-eabi will give you stuff for bare-metal applications, and the
> arm-linux-eabi (or arm-linux-gnueabi) ?will give you stuff for linux. For FreeBSD now,
> from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1
> and it wouldn't accept it.

Yeah, you would have to explicitely create it by tweaking the platform
definition files.

> What I've build is arm-unknown-freebsd, although the "unknown" part could
> be ommited. Please bear with me while I look for the URL I found the naming
> conventions...

That could actually be what we are looking for. Do you know if this
definition uses eabi?
From chuckr at telenix.org  Thu Jun  4 16:22:56 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Thu Jun  4 16:23:03 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <360403.90502.qm@web59402.mail.ac4.yahoo.com>
References: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
	<360403.90502.qm@web59402.mail.ac4.yahoo.com>
Message-ID: <4A27F4C9.5070100@telenix.org>

Vassilis Laganakos wrote:
> 
> 
>>> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
> 
>>> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
>>> processor until 4.3.0.  I was able to build a cross-gcc easily using a target 
>> of
>>> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
>>> FreeBSD.  I'll worry about getting that gcc into the build, but will it work 
>> for
>>> me on a binary basis?
>>>
>> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
>> get rid of the linux-specific stuff by default. But maybe you should
>> define something like arm-freebsd-eabi in gcc's build configuration?
>>

Thanks SO much, giving me the info on the targets was the item I most badly
needed, but you're the only fella who addressed that directly.  Basically, you
got rid of my single remaining problem (at the pre-build level, at least), it's
something that no amount of Googling would show me.

I'm so damned pleased!  From all the hints I got, there appears to be
vanishingly little chance of our tree going to gcc-4.3.+, because everyone wants
to use LLVM.  I don't stand against that, but I don't want to wait, either, and
(as of today) llvm doesn't support the Cortex-A8 (it will soon).

Actually, I'm rereading my Dragon book, so I can understand the llvm better.  It
does look to be better organized than gcc, from first glance.  I can't find the
code (outside ports) to build llvm, do you have any idea where it is?  If it's
in a p4 archive, you have a URL for it?

> The arm-none-eabi will give you stuff for bare-metal applications, and the 
> arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now, 
> from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1 
> and it wouldn't accept it. 
> 
> What I've build is arm-unknown-freebsd, although the "unknown" part could
> be ommited. Please bear with me while I look for the URL I found the naming
> conventions...
> 
> Thanks,
> Vasi
> 
> 
> 
>       
> 

From chuckr at telenix.org  Thu Jun  4 16:25:20 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Thu Jun  4 16:25:27 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <360403.90502.qm@web59402.mail.ac4.yahoo.com>
References: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
	<360403.90502.qm@web59402.mail.ac4.yahoo.com>
Message-ID: <4A27F55D.40101@telenix.org>

Vassilis Laganakos wrote:
> 
> 
>>> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
> 
>>> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
>>> processor until 4.3.0.  I was able to build a cross-gcc easily using a target 
>> of
>>> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
>>> FreeBSD.  I'll worry about getting that gcc into the build, but will it work 
>> for
>>> me on a binary basis?
>>>
>> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
>> get rid of the linux-specific stuff by default. But maybe you should
>> define something like arm-freebsd-eabi in gcc's build configuration?
>>

Thanks SO much, giving me the info on the targets was the item I most badly
needed, but you're the only fella who addressed that directly.  Basically, you
got rid of my single remaining problem (at the pre-build level, at least), it's
something that no amount of Googling would show me.

I'm so damned pleased!  From all the hints I got, there appears to be
vanishingly little chance of our tree going to gcc-4.3.+, because everyone wants
to use LLVM.  I don't stand against that, but I don't want to wait, either, and
(as of today) llvm doesn't support the Cortex-A8 (it will soon).

Actually, I'm rereading my Dragon book, so I can understand the llvm better.  It
does look to be better organized than gcc, from first glance.  I can't find the
code (outside ports) to build llvm, do you have any idea where it is?  If it's
in a p4 archive, you have a URL for it?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FORGET about the llvm question, I just saw the mail about it being imported to svn.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> The arm-none-eabi will give you stuff for bare-metal applications, and the 
> arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now, 
> from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1 
> and it wouldn't accept it. 
> 
> What I've build is arm-unknown-freebsd, although the "unknown" part could
> be ommited. Please bear with me while I look for the URL I found the naming
> conventions...
> 
> Thanks,
> Vasi
> 
> 
> 
>       
> 


From vassilis.laganakos at yahoo.com  Thu Jun  4 23:59:30 2009
From: vassilis.laganakos at yahoo.com (Vassilis Laganakos)
Date: Thu Jun  4 23:59:36 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <200906041542.n54Fgdab019028@casselton.net>
References: <200906041542.n54Fgdab019028@casselton.net>
Message-ID: <985061.32128.qm@web59411.mail.ac4.yahoo.com>


Hi Mark,

> What configuration options are you using for an ARM cross compiler?
>
Please bear with me while I put everything in a wiki/log page to be accessible
- and visible for inspection :o) - to everyone. (should I submit this to the
freebsd/arm page as a howto as well?). Have to repeat though the procedure
now that I switched to HEAD.


> The cross compile fails for me when it gets to the arm "multilib" build.
> I tried with gcc44 and gcc45. I am trying one last time with the configuration
> option "--disable-multilib", but I am not holding my breath.
> 
I had faced the same problem. The problem is possibly something that 
was reported as a bug against gcc, that involves acx.m4  getting the wrong path
to ${host_subddir} 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191

What I did was hand editing the Makefile and changing the offended variable 
$host_subdir to what it should be. For me it was "host-i386-unknown-freebsd"
Then restarted gmake. So it doesn't seem to be --multilib, and although I had
thought exactly the same (disabling it!) it looks like it is required.

You will come across a few more sub-packages that face the same problem. 
The treatment is the same. :o)

It will ultimately stop (fail) when it will try to find libc... That's where I am now :o)

Kind regards,
Vassilis L.


      

From vassilis.laganakos at yahoo.com  Fri Jun  5 00:05:01 2009
From: vassilis.laganakos at yahoo.com (Vassilis Laganakos)
Date: Fri Jun  5 00:05:07 2009
Subject: ARMv7 - EABI - Cross Compiler
Message-ID: <344051.72501.qm@web59410.mail.ac4.yahoo.com>



> > What I've build is arm-unknown-freebsd, although the "unknown" part could
> > be ommited. Please bear with me while I look for the URL I found the naming
> > conventions...
> 
> That could actually be what we are looking for. Do you know if this
> definition uses eabi?
>
I think in GCC 4.3 is where you get ARMv7 architecture support, (see 
http://gcc.gnu.org/gcc-4.3/changes.html), which is EABI and at GCC 4.4
you have "EABI-compatible profiling interface for EABI targets." (again see
http://gcc.gnu.org/gcc-4.4/changes.html).

So I've chosen to work on 4.4 just to be sure, and it also supports Cortex-A9, as 
well as VFPv3 (yeah!).

If you meant whether "arm-unknown-freebsd" implies "arm-unknown-freebsd-eabi"
(and I've been mumbling about sth else :o) ) that answer I think is "yes".  Of course, 
if I'm mistaken please someone correct me!

Kind regards,
Vassilis L.



      

From beattie at beattie-home.net  Fri Jun  5 02:10:50 2009
From: beattie at beattie-home.net (Brian Beattie)
Date: Fri Jun  5 02:10:57 2009
Subject: KB9202B
In-Reply-To: <20090603.195059.1239873755.imp@bsdimp.com>
References: <1244064320.9543.44.camel@kokopelli>
	<2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
	<20090603.195059.1239873755.imp@bsdimp.com>
Message-ID: <1244167838.9543.116.camel@kokopelli>

On Wed, 2009-06-03 at 19:50 -0600, M. Warner Losh wrote:
> In message: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
>             Arnar Mar Sig <antab@valka.is> writes:
> : On Jun 3, 2009, at 11:25 PM, Brian Beattie wrote:
> : > I'm trying to figure out FreeBSD on arm and I'm trying to get it  
> : > running
> : > on a KwikByte 9202. 

...

> : > Console log below the sig.
> : >
> : <snip>
> : > ate0: <EMAC> mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0
> : > ate0: No MAC address set
> : > device_attach: ate0 attach returned 6
> : looks like you have no working network device.
> 
> Looks like no MAC address is programmed into the MAC by the
> boot loader...
> 
> Warner

Ok, I grabbed current sources via svn, and configured nanobsd to build
for the kb9202b. a console log for loading the kernel via tftp.  as the
kernel boots up it run the DHCP protocol producing the following
message:

Received DHCP Ack packet on ate0 from 0.0.0.0 (accepted) (no root path)

I'm interpreting this as meaning that it's looking for some information
from the DHCP server.  I can switch my DHCP server from my DD-WRT
firewall to a linux box if this is the case and I know what information
the freebsd kernel is looking for.

Can somebody point me to a resource that defines this?

Thanks

-- 
"In years past, I knew of someone who used emacs as
his login shell, the only thing he found wanting in
emacs was a good text editor. So he ended up using vi."
- Anonymous
Brian Beattie<beattie@beattie-home.net>
http://www.beattie-home.net 

From stas at FreeBSD.org  Fri Jun  5 05:53:53 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Fri Jun  5 05:53:59 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <4A27F4C9.5070100@telenix.org>
References: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
	<360403.90502.qm@web59402.mail.ac4.yahoo.com>
	<4A27F4C9.5070100@telenix.org>
Message-ID: <20090605095452.8669c3da.stas@FreeBSD.org>

On Thu, 04 Jun 2009 12:22:33 -0400
Chuck Robey <chuckr@telenix.org> mentioned:

> 
> Actually, I'm rereading my Dragon book, so I can understand the llvm better.  It
> does look to be better organized than gcc, from first glance.  I can't find the
> code (outside ports) to build llvm, do you have any idea where it is?  If it's
> in a p4 archive, you have a URL for it?

Check this page: http://wiki.freebsd.org/BuildingFreeBSDWithClang

-- 
Stanislav Sedov
ST4096-RIPE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090605/7ec6f701/attachment.pgp
From imp at bsdimp.com  Fri Jun  5 08:40:04 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri Jun  5 08:40:26 2009
Subject: KB9202B
In-Reply-To: <1244167838.9543.116.camel@kokopelli>
References: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
	<20090603.195059.1239873755.imp@bsdimp.com>
	<1244167838.9543.116.camel@kokopelli>
Message-ID: <20090605.023744.1137954643.imp@bsdimp.com>

In message: <1244167838.9543.116.camel@kokopelli>
            Brian Beattie <beattie@beattie-home.net> writes:
: On Wed, 2009-06-03 at 19:50 -0600, M. Warner Losh wrote:
: > In message: <2624C7F8-3639-405F-8E8C-A784FA4C1E0C@valka.is>
: >             Arnar Mar Sig <antab@valka.is> writes:
: > : On Jun 3, 2009, at 11:25 PM, Brian Beattie wrote:
: > : > I'm trying to figure out FreeBSD on arm and I'm trying to get it  
: > : > running
: > : > on a KwikByte 9202. 
: 
: ...
: 
: > : > Console log below the sig.
: > : >
: > : <snip>
: > : > ate0: <EMAC> mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0
: > : > ate0: No MAC address set
: > : > device_attach: ate0 attach returned 6
: > : looks like you have no working network device.
: > 
: > Looks like no MAC address is programmed into the MAC by the
: > boot loader...
: > 
: > Warner
: 
: Ok, I grabbed current sources via svn, and configured nanobsd to build
: for the kb9202b. a console log for loading the kernel via tftp.  as the
: kernel boots up it run the DHCP protocol producing the following
: message:
: 
: Received DHCP Ack packet on ate0 from 0.0.0.0 (accepted) (no root path)
: 
: I'm interpreting this as meaning that it's looking for some information
: from the DHCP server.  I can switch my DHCP server from my DD-WRT
: firewall to a linux box if this is the case and I know what information
: the freebsd kernel is looking for.
: 
: Can somebody point me to a resource that defines this?

I think that you need some special information in the DHCP server to
get the root path.  My isc dhcp server is configured for that like so:

        host avila.example.com {
                filename "kernel.avila";
                hardware ethernet 00:d0:12:02:76:58;
                fixed-address 192.168.0.10
                option root-path "192.168.0.2:/nfsroots/gateworks";
                option root-opts "nolockd";
        }

Warner

From chuckr at telenix.org  Fri Jun  5 23:26:32 2009
From: chuckr at telenix.org (Chuck Robey)
Date: Fri Jun  5 23:26:39 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
References: <fd183dc60906040612td250b16gb8b289293bb85671@mail.gmail.com>
Message-ID: <4A29A9AA.2090609@telenix.org>

Guillaume Ballet wrote:
>> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
>> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
>> processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
>> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
>> FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
>> me on a binary basis?
>>
> 
> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
> get rid of the linux-specific stuff by default. But maybe you should
> define something like arm-freebsd-eabi in gcc's build configuration?

Always a thing of extremes for me.  I know Makefiles pretty darned well, both
the BSD and teh GNU sort, but as well as I know them, that's how BADLY I
misunderstand anything dealing with those configure scripts.  I can't even begin
to pick apart the code for those things.  Irritates me, because if I find a
problem in a makefile, I pop out an answer with the greatest of ease, but if
it's well coded so that configure reruns itself immediately if there's any
change in the makefile, then it has to run configure, and I'm basically utterly
screwed.  I like our BSD build system, not a configure script in sight!

However, now that I understand that I can use arm-none-eabi, I am pretty sure I
can do things, and the configure scripts in gcc aren't so well engineered to
force me to deal with them like that.  If I can deal with a configure script as
a shell script, I can do that, it's dealing with it as m4 macros that leaves me
cold.
From tinguely at casselton.net  Sat Jun  6 14:36:36 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Sat Jun  6 14:36:45 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <4A29A9AA.2090609@telenix.org>
Message-ID: <200906061436.n56EaU6A025809@casselton.net>


You should talk to the tools team about the port. A person can get a
basic gcc4.5 cross compiler (gmake all-gcc / install-gcc) without the
libraries but the kernel sources expects a FreeBSD extended kernel
(a missing __FreeBSD_cc_version will pop up right away). There are
files in svn/gnu/usr.bin/cc/cc_tools that are new and svn/contrib/gcc/config
that differ from the gcc4.5 sources.

I tip my hat to the tools team to get the gnu software to natively and
cross compile and install in a normal location.

--Mark.
From bugmaster at FreeBSD.org  Mon Jun  8 11:06:49 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jun  8 11:07:40 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200906081106.n58B6mlT020561@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From putrycydestengier at gmail.com  Tue Jun  9 09:14:16 2009
From: putrycydestengier at gmail.com (Putrycy)
Date: Tue Jun  9 09:14:23 2009
Subject: NANOBSD->ARM example ?!
Message-ID: <eeb776570906090147ra11399dq6dec60a4dc49fef1@mail.gmail.com>

Hi everyone,

  Id like to ask if you could possibly help me finding example of how to
create small version of
freebsd using nanobsd, using crosscompilation ? Im particullary interested
in ARM architecture
as a target.I know it can be done using nanobsd, but im not sure if simply
setting
TARGET, TARGET_ARCH, TARGET_CPUTYPE and TARGET_BIGENDIAN vars in
configuration file will
do the trick. It probably needs much more effort, maybe you'll be able to
help me. Thanks in advance.



---
Putrycy
From jacques.fourie at gmail.com  Tue Jun  9 10:14:54 2009
From: jacques.fourie at gmail.com (Jacques Fourie)
Date: Tue Jun  9 10:15:01 2009
Subject: NANOBSD->ARM example ?!
In-Reply-To: <eeb776570906090147ra11399dq6dec60a4dc49fef1@mail.gmail.com>
References: <eeb776570906090147ra11399dq6dec60a4dc49fef1@mail.gmail.com>
Message-ID: <be2f52430906090254s795240dcoc4ad1ff70210eeb7@mail.gmail.com>

> Hi everyone,
>
> ?Id like to ask if you could possibly help me finding example of how to
> create small version of
> freebsd using nanobsd, using crosscompilation ? Im particullary interested
> in ARM architecture
> as a target.I know it can be done using nanobsd, but im not sure if simply
> setting
> TARGET, TARGET_ARCH, TARGET_CPUTYPE and TARGET_BIGENDIAN vars in
> configuration file will
> do the trick. It probably needs much more effort, maybe you'll be able to
> help me. Thanks in advance.
>
>
>
> ---
> Putrycy
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
>

The tools/tools/nanobsd/gateworks directory has some examples for
building ARM nanobsd images.

Jacques
From jeffa at sigware.com  Thu Jun 11 10:58:57 2009
From: jeffa at sigware.com (Maud Hooper)
Date: Thu Jun 11 10:59:04 2009
Subject: Replica Watches
Message-ID: <001b01c9ea80$64a04bb0$b4196cd4@homepcyxxie.iv>

A lot of brands, 100-300 usd.
Mail to order: daniel@goldwag.com

From tinderbox at freebsd.org  Thu Jun 11 11:26:43 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Jun 11 11:26:55 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090611112639.5A0507302F@freebsd-current.sentex.ca>

TB --- 2009-06-11 11:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-11 11:00:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-11 11:00:00 - cleaning the object tree
TB --- 2009-06-11 11:00:47 - cvsupping the source tree
TB --- 2009-06-11 11:00:47 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-11 11:00:56 - building world
TB --- 2009-06-11 11:00:56 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-11 11:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-11 11:00:56 - TARGET=arm
TB --- 2009-06-11 11:00:56 - TARGET_ARCH=arm
TB --- 2009-06-11 11:00:56 - TZ=UTC
TB --- 2009-06-11 11:00:56 - __MAKE_CONF=/dev/null
TB --- 2009-06-11 11:00:56 - cd /src
TB --- 2009-06-11 11:00:56 - /usr/bin/make -B buildworld
>>> World build started on Thu Jun 11 11:00:58 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bplist.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c: In function 'dmu_prefetch':
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: 'zfs_prefetch_enable' undeclared (first use in this function)
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: (Each undeclared identifier is reported only once
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: for each function it appears in.)
*** Error code 1

Stop in /src/cddl/lib/libzpool.
*** Error code 1

Stop in /src/cddl/lib.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-11 11:26:39 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-11 11:26:39 - ERROR: failed to build world
TB --- 2009-06-11 11:26:39 - 1189.27 user 152.84 system 1598.96 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Thu Jun 11 14:06:41 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Jun 11 14:06:47 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090611140637.DAF5B7302F@freebsd-current.sentex.ca>

TB --- 2009-06-11 13:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-11 13:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-11 13:40:00 - cleaning the object tree
TB --- 2009-06-11 13:40:42 - cvsupping the source tree
TB --- 2009-06-11 13:40:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-11 13:40:51 - building world
TB --- 2009-06-11 13:40:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-11 13:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-11 13:40:51 - TARGET=arm
TB --- 2009-06-11 13:40:51 - TARGET_ARCH=arm
TB --- 2009-06-11 13:40:51 - TZ=UTC
TB --- 2009-06-11 13:40:51 - __MAKE_CONF=/dev/null
TB --- 2009-06-11 13:40:51 - cd /src
TB --- 2009-06-11 13:40:51 - /usr/bin/make -B buildworld
>>> World build started on Thu Jun 11 13:40:56 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bplist.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c: In function 'dmu_prefetch':
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: 'zfs_prefetch_enable' undeclared (first use in this function)
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: (Each undeclared identifier is reported only once
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: for each function it appears in.)
*** Error code 1

Stop in /src/cddl/lib/libzpool.
*** Error code 1

Stop in /src/cddl/lib.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-11 14:06:37 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-11 14:06:37 - ERROR: failed to build world
TB --- 2009-06-11 14:06:37 - 1189.36 user 151.79 system 1597.51 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Thu Jun 11 16:45:44 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Jun 11 16:46:01 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090611164540.77B017302F@freebsd-current.sentex.ca>

TB --- 2009-06-11 16:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-11 16:20:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-11 16:20:00 - cleaning the object tree
TB --- 2009-06-11 16:20:14 - cvsupping the source tree
TB --- 2009-06-11 16:20:14 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-11 16:20:21 - building world
TB --- 2009-06-11 16:20:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-11 16:20:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-11 16:20:21 - TARGET=arm
TB --- 2009-06-11 16:20:21 - TARGET_ARCH=arm
TB --- 2009-06-11 16:20:21 - TZ=UTC
TB --- 2009-06-11 16:20:21 - __MAKE_CONF=/dev/null
TB --- 2009-06-11 16:20:21 - cd /src
TB --- 2009-06-11 16:20:21 - /usr/bin/make -B buildworld
>>> World build started on Thu Jun 11 16:20:23 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bplist.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c: In function 'dmu_prefetch':
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: 'zfs_prefetch_enable' undeclared (first use in this function)
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: (Each undeclared identifier is reported only once
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: for each function it appears in.)
*** Error code 1

Stop in /src/cddl/lib/libzpool.
*** Error code 1

Stop in /src/cddl/lib.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-11 16:45:40 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-11 16:45:40 - ERROR: failed to build world
TB --- 2009-06-11 16:45:40 - 1188.12 user 152.32 system 1539.60 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Thu Jun 11 19:25:45 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Jun 11 19:25:58 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090611192541.729837302F@freebsd-current.sentex.ca>

TB --- 2009-06-11 19:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-11 19:00:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-11 19:00:00 - cleaning the object tree
TB --- 2009-06-11 19:00:10 - cvsupping the source tree
TB --- 2009-06-11 19:00:10 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-11 19:00:20 - building world
TB --- 2009-06-11 19:00:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-11 19:00:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-11 19:00:20 - TARGET=arm
TB --- 2009-06-11 19:00:20 - TARGET_ARCH=arm
TB --- 2009-06-11 19:00:20 - TZ=UTC
TB --- 2009-06-11 19:00:20 - __MAKE_CONF=/dev/null
TB --- 2009-06-11 19:00:20 - cd /src
TB --- 2009-06-11 19:00:20 - /usr/bin/make -B buildworld
>>> World build started on Thu Jun 11 19:00:23 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bplist.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c: In function 'dmu_prefetch':
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: 'zfs_prefetch_enable' undeclared (first use in this function)
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: (Each undeclared identifier is reported only once
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: for each function it appears in.)
*** Error code 1

Stop in /src/cddl/lib/libzpool.
*** Error code 1

Stop in /src/cddl/lib.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-11 19:25:41 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-11 19:25:41 - ERROR: failed to build world
TB --- 2009-06-11 19:25:41 - 1186.52 user 154.31 system 1541.12 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Thu Jun 11 22:06:13 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Thu Jun 11 22:06:25 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090611220609.DE8797302F@freebsd-current.sentex.ca>

TB --- 2009-06-11 21:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-11 21:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-11 21:40:00 - cleaning the object tree
TB --- 2009-06-11 21:40:21 - cvsupping the source tree
TB --- 2009-06-11 21:40:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-11 21:40:28 - building world
TB --- 2009-06-11 21:40:28 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-11 21:40:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-11 21:40:28 - TARGET=arm
TB --- 2009-06-11 21:40:28 - TARGET_ARCH=arm
TB --- 2009-06-11 21:40:28 - TZ=UTC
TB --- 2009-06-11 21:40:28 - __MAKE_CONF=/dev/null
TB --- 2009-06-11 21:40:28 - cd /src
TB --- 2009-06-11 21:40:28 - /usr/bin/make -B buildworld
>>> World build started on Thu Jun 11 21:40:33 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bplist.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
cc -O -pipe  -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -DWANTS_MUTEX_OWNED -I/src/cddl/lib/libzpool/../../../lib/libpthread/thread -I/src/cddl/lib/libzpool/../../../lib/libpthread/sys -I/src/cddl/lib/libzpool/../../../lib/libthr/arch/arm/include -DNEED_SOLARIS
 _BOOLEAN -std=iso9899:1999 -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c: In function 'dmu_prefetch':
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: 'zfs_prefetch_enable' undeclared (first use in this function)
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: (Each undeclared identifier is reported only once
/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:329: error: for each function it appears in.)
*** Error code 1

Stop in /src/cddl/lib/libzpool.
*** Error code 1

Stop in /src/cddl/lib.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-11 22:06:09 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-11 22:06:09 - ERROR: failed to build world
TB --- 2009-06-11 22:06:09 - 1188.89 user 152.45 system 1568.98 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From xcllnt at mac.com  Fri Jun 12 21:19:48 2009
From: xcllnt at mac.com (Marcel Moolenaar)
Date: Fri Jun 12 21:19:54 2009
Subject: [ARM+NFS] panic while copying across NFS
Message-ID: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com>

I just ran into the following panic:

	panic: vm_page_insert: offset already allocated

I was copying a kernel across NFS at the time:

	orion% cd /nfs/netboot/arm
	orion% ls
	kernel-save.bin	kernel.bin	ubldr
	orion% sudo cp kernel.bin kernel-save.bin
	orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin  
kernel.bin

(/usr/obj is on a local disk)

With this backtrace:

db> bt
Tracing pid 26585 tid 100073 td 0xc22bd6f0
db_trace_thread() at db_trace_thread+0x10
scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484)
         rsp=0xc8492878 rfp=0xc8492898
         r10=0x00000001 r9=0xc0bb3e94
         r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000
         r4=0xc22bd6f0
db_command_init() at db_command_init+0x404
scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c)
         rsp=0xc849289c rfp=0xc8492940
         r6=0x00000002 r5=0x00000000
         r4=0xc0b8bb80
db_skip_to_eol() at db_skip_to_eol+0x1d0
scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50)
         rsp=0xc8492944 rfp=0xc8492954
         r10=0x00000001 r8=0x00000000
         r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598
db_command_loop() at db_command_loop+0x18
scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0)
         rsp=0xc8492958 rfp=0xc8492a74
         r4=0xc849295c
X_db_sym_numargs() at X_db_sym_numargs+0x18
scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0)
         rsp=0xc8492a78 rfp=0xc8492aa0
         r4=0x000000c0
kdb_trap() at kdb_trap+0x10
scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124)
         rsp=0xc8492aa4 rfp=0xc8492b18
         r10=0xc22bd6f0 r9=0x00000000
         r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000
         r4=0x00000000
undefinedinstruction() at undefinedinstruction+0x10
scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50)
         rsp=0xc8492b1c rfp=0xc8492b7c
         r10=0xc0d147c8 r8=0x00000000
         r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000
kdb_enter() at kdb_enter+0x14
scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0)
         rsp=0xc8492b80 rfp=0xc8492b94
         r5=0xc0b4c994 r4=0x00000100
panic() at panic+0x1c
scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164)
         rsp=0xc8492ba8 rfp=0xc8492bc8
vm_page_insert() at vm_page_insert+0x10
scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304)
         rsp=0xc8492bcc rfp=0xc8492bf4
         r8=0x00001e03 r7=0x00000061
         r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000
vm_page_alloc() at vm_page_alloc+0x10
scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4)
         rsp=0xc8492bf8 rfp=0xc8492c48
         r10=0x00000000 r9=0x00001000
         r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061
         r4=0xc1e03000
kmem_malloc() at kmem_malloc+0x14
scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0)
         rsp=0xc8492c4c rfp=0xc8492c88
         r10=0xc0ac5efc r9=0xc0e36640
         r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003
         r4=0xc0e2d280
uma_zcreate() at uma_zcreate+0x70
scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198)
         rsp=0xc8492c8c rfp=0xc8492cac
         r10=0xc0e319d8 r9=0x00000020
         r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203
         r4=0xc0e2d280
uma_prealloc() at uma_prealloc+0xd4
scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458)
         rsp=0xc8492cb0 rfp=0xc8492cc8
         r7=0x00000002 r6=0xc0e36640
         r5=0x00000003 r4=0xc0e2d280
uma_prealloc() at uma_prealloc+0x42c
scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c)
         rsp=0xc8492ccc rfp=0xc8492d10
         r6=0xc1a5dcc0 r5=0x00000013
         r4=0x00000013
uma_zalloc_arg() at uma_zalloc_arg+0x10
scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec)
         rsp=0xc8492d14 rfp=0xc8492d5c
         r10=0xc4bc0fcc r9=0x00008000
         r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800
         r4=0x00000000
nfsm_uiotombuf() at nfsm_uiotombuf+0x10
scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8)
         rsp=0xc8492d60 rfp=0xc8492ddc
         r10=0xc3884910 r9=0x00008000
         r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900
         r4=0x00000000
nfs_writerpc() at nfs_writerpc+0x10
scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204)
         rsp=0xc8492de0 rfp=0xc8492e4c
         r10=0xc3884910 r9=0xc235cca8
         r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0
         r4=0x00000000
nfs_doio() at nfs_doio+0x10
scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4)
         rsp=0xc8492e50 rfp=0xc8492e80
         r10=0x00000000 r9=0xc0d13ab4
         r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000
         r4=0xc3884910
nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac
scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64)
         rsp=0xc8492e84 rfp=0xc8492ea8
         r10=0xc0a870b0 r9=0xc0d1f6c0
         r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0
         r4=0xc22bd6f0
fork_exit() at fork_exit+0x10
scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14)
         rsp=0xc8492eac rfp=0x00000000
         r10=0xc0d1f6c0 r8=0x00000104
         r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0


FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com



From bugmaster at FreeBSD.org  Mon Jun 15 11:06:51 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jun 15 11:07:30 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200906151106.n5FB6oW2076834@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From tinguely at casselton.net  Mon Jun 15 21:04:19 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Mon Jun 15 21:04:25 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <77926.36276.qm@web59405.mail.ac4.yahoo.com>
Message-ID: <200906152104.n5FL4HYR013525@casselton.net>


In case any of the Cortex/v7 projects or anyone else is interested, I have
gcc-4.5 cross compiling the current GUMSTIX kernel on a i386 FreeBSD 6.4
computer (QEMU runs better under FreeBSD 6.4) - I have not tried the libs
yet to a "build world".

The kernel sources need some FreeBSD (format and at least one built-in define)
extensions to compile that are not in the standard gcc. Besides the extensions
that I copied over the code to put the binaries in the standard, reasonable
places /usr/cross/libexec/cc1, for example).

Gcc 4.5 -O option found a few inline and structure warnings, that required
either the removal of the -O option or -Werror option for these files.
I chose to remove the -Werror. The warnings are:

wanted to add parenthesis around the &:
ddb/db_ps.c

-O detects inline optimizations in the files:
devfs_vnops.c pseudofs_vnops.c  kern_descrip.c kern_jail.c sys_pipe.c
tty.c uipc_mbuf.c vfs_default.c vfs_lookup.c vfs_mount.c vfs_syscalls.c
ffs_snapshot.c trap.c pmap.c

variably modified in the definition of a structure (and some inline opt):
ufs_dirhash.c ufs_inode.c ufs_lookup.c  ufs_vfsops.c ufs_vnops.c

I made changes to the gcc-4.5-20090528 directory and the build directory.
I will look at the libraries too.

--Mark Tinguely.
From tinderbox at freebsd.org  Mon Jun 15 23:59:19 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Mon Jun 15 23:59:31 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090615235916.277527302F@freebsd-current.sentex.ca>

TB --- 2009-06-15 23:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-15 23:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-15 23:40:00 - cleaning the object tree
TB --- 2009-06-15 23:40:42 - cvsupping the source tree
TB --- 2009-06-15 23:40:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-15 23:40:53 - building world
TB --- 2009-06-15 23:40:53 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-15 23:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-15 23:40:53 - TARGET=arm
TB --- 2009-06-15 23:40:53 - TARGET_ARCH=arm
TB --- 2009-06-15 23:40:53 - TZ=UTC
TB --- 2009-06-15 23:40:53 - __MAKE_CONF=/dev/null
TB --- 2009-06-15 23:40:53 - cd /src
TB --- 2009-06-15 23:40:53 - /usr/bin/make -B buildworld
>>> World build started on Mon Jun 15 23:40:55 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
[...]
===> kerberos5/lib/libroken (obj,depend,all,install)
rm -f .depend
mkdep -f .depend -a    -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/concat.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/dumpdata.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ecalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/emalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/environment.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/erealloc.c /src/kerberos5/lib/libroken/../../../cryp
 to/heimdal/lib/roken/esetenv.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/estrdup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ewrite.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_default_username.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_window_size.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getaddrinfo_hostspec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getarg.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getnameinfo_verified.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hex.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hostent_find_fqdn.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/issuid.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwnam.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwuid.c /src/kerberos5/lib/libroken/../../../c
 rypto/heimdal/lib/roken/mini_inetd.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ndbm_wrap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_read.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_write.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_bytes.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/resolve.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken_gethostby.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/rtbl.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/simple_exec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/snprintf.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/socket.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/s
 trcollect.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strlwr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strndup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strnlen.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strpool.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strsep_copy.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strupr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/timeval.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/tm2time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/warnerr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/write_pid.c
cc -O -pipe  -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99  -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c
cc -O -pipe  -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99  -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c
cc -O -pipe  -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99  -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c
/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c:50: error: conflicting types for 'closefrom'
/obj/arm/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here
*** Error code 1

Stop in /src/kerberos5/lib/libroken.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-15 23:59:16 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-15 23:59:16 - ERROR: failed to build world
TB --- 2009-06-15 23:59:16 - 831.69 user 98.77 system 1155.47 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From venkiece2005 at gmail.com  Tue Jun 16 10:01:47 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Tue Jun 16 10:01:59 2009
Subject: [libc] dlclose gives "invalid shared object handle" without pthread
	combination.
Message-ID: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com>

Hi,

I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/)
for ARM/MIPS.

I have C++ static constructor/destructor issue with my rtld.

Problem Report:
"ld.elf_so does not execute .init/.fini functions in order" and [libc]
dlclose gives
"invalid shared object handle" when called through the fini function of another
module.

The similar NetBSD/freeBSD issues are found from the following References:
[1] http://gnats.netbsd.org/37347
[2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956

The above issues are already commited in NetBSD-5-0-RELEASE.

I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided
static constructor/destructor test and did not find any issues
with shared pthread combination but noticed [libc] dlclose gives
"invalid shared object handle" without pthread combination.

The static constructor/destructor test results:

It should be :
--------------

$ ./foobar
foo_ctor
bar_ctor
tar_ctor
main_ctor
dep1_ctor
dep2_ctor
dll_ctor
dll_dtor
dep2_dtor
dep1_dtor
main_dtor
tar_dtor
bar_dtor
foo_dtor

While currently I get:
----------------------

with pthreads:

$ ./foobar
foo_ctor
bar_ctor
tar_ctor
main_ctor
dep1_ctor
dep2_ctor
dll_ctor
dll_dtor
dep2_dtor
dep1_dtor
main_dtor
tar_dtor
bar_dtor
foo_dtor

without pthreads:

$ ./foobar
foo_ctor
bar_ctor
tar_ctor
main_ctor
dep1_ctor
dep2_ctor
dll_ctor
dll_dtor
dep2_dtor
dep1_dtor
main_dtor
tar_dtor
bar_dtor
foo_dtor
Invalid shared object handle 0xbdbed400

This gives a "invalid shared object handle" message
because the refcount field (obj->dl_refcount) for the handle is zero.

I have little bit confused about dlclose destructor
with/without pthreads.

I have some queries:
1) Is it required any changes apart from the NetBSD-5-0-RELEASE/{Ref[1],[2]}?
2) Are any changes required in thread-stub?

Could anyone provide any inputs to the my issue?

Thanks in advance.

Thanks & Regards,
Venkappa
From kabaev at gmail.com  Wed Jun 17 00:34:26 2009
From: kabaev at gmail.com (Alexander Kabaev)
Date: Wed Jun 17 00:34:33 2009
Subject: [libc] dlclose gives "invalid shared object handle" without
 pthread combination.
In-Reply-To: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com>
References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com>
Message-ID: <20090616200756.70206fda@kan.dnsalias.net>

Hi,

I do not think we on FreeBSD support NetBSD rtld with our pthread
libraries, unless you already implemented all the necessary glue.
The interface between threading library and rtld is rather intimate and
tricky to get right.

You provide no code to look at nor explicitly mention what OS and
what version you are running your test on (FreeBSD?), I think you are
on your own. Furthermore, your claim on 'correct'
constructor/destructor is wrong given the sample code provided by
NetBSD PR.

Some more comments are inline.

On Tue, 16 Jun 2009 14:59:36 +0530
venki kaps <venkiece2005@gmail.com> wrote:

> Hi,
> 
> I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/)
> for ARM/MIPS.
> 
> I have C++ static constructor/destructor issue with my rtld.
> 
> Problem Report:
> "ld.elf_so does not execute .init/.fini functions in order" and [libc]
> dlclose gives
> "invalid shared object handle" when called through the fini function
> of another module.
> 
> The similar NetBSD/freeBSD issues are found from the following
> References: [1] http://gnats.netbsd.org/37347
> [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956
> 
> The above issues are already commited in NetBSD-5-0-RELEASE.
> 
> I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided
> static constructor/destructor test and did not find any issues
> with shared pthread combination but noticed [libc] dlclose gives
> "invalid shared object handle" without pthread combination.
> 
> The static constructor/destructor test results:
> 
> It should be :
> --------------
> 
> $ ./foobar
> foo_ctor
> bar_ctor
> tar_ctor
> main_ctor
> dep1_ctor
> dep2_ctor
> dll_ctor
> dll_dtor
> dep2_dtor
> dep1_dtor
> main_dtor
> tar_dtor
> bar_dtor
> foo_dtor

Given the test in Ref[1], both constructor and destructor orders are
wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked
before dep1_ctor and consequently dep2_dtor should be invoked after
dep1_dtor.
 
> While currently I get:
> ----------------------
> 
> with pthreads:
> 
> $ ./foobar
> foo_ctor
> bar_ctor
> tar_ctor
> main_ctor
> dep1_ctor
> dep2_ctor
> dll_ctor
> dll_dtor
> dep2_dtor
> dep1_dtor
> main_dtor
> tar_dtor
> bar_dtor
> foo_dtor
> 
> without pthreads:
> 
> $ ./foobar
> foo_ctor
> bar_ctor
> tar_ctor
> main_ctor
> dep1_ctor
> dep2_ctor
> dll_ctor
> dll_dtor
> dep2_dtor
> dep1_dtor
> main_dtor
> tar_dtor
> bar_dtor
> foo_dtor
> Invalid shared object handle 0xbdbed400

Again, given the sample code from NetBSD PR cannot possibly print this
message because it never even calls dlerr(). You must be looking at
some other code and unless you provide it, understanding your problem
and fixing it is next to impossible.

Said that, thanks for pointing the FreeBSD PR to me. I will commit the
fix for the problem described here shortly.
 
> This gives a "invalid shared object handle" message
> because the refcount field (obj->dl_refcount) for the handle is zero.
> 
> I have little bit confused about dlclose destructor
> with/without pthreads.
> 
> I have some queries:
> 1) Is it required any changes apart from the
> NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in
> thread-stub?
> 
> Could anyone provide any inputs to the my issue?
> 
> Thanks in advance.
> 
> Thanks & Regards,
> Venkappa

-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090617/d67258cc/signature.pgp
From sam at freebsd.org  Wed Jun 17 18:10:32 2009
From: sam at freebsd.org (Sam Leffler)
Date: Wed Jun 17 18:10:39 2009
Subject: HEADS UP: xscale users
Message-ID: <4A393196.20703@freebsd.org>

Let me know if you see any regressions w/ this change on your xscale boards.

    Sam

-------------- next part --------------
An embedded message was scrubbed...
From: Sam Leffler <sam@FreeBSD.org>
Subject: svn commit: r194378 - head/sys/arm/xscale/ixp425
Date: Wed, 17 Jun 2009 17:57:52 +0000 (UTC)
Size: 5950
Url: http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090617/218f9fa7/ixp425.eml
From vassilis.laganakos at yahoo.com  Wed Jun 17 23:23:59 2009
From: vassilis.laganakos at yahoo.com (Vassilis Laganakos)
Date: Wed Jun 17 23:24:06 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <200906152104.n5FL4HYR013525@casselton.net>
References: <200906152104.n5FL4HYR013525@casselton.net>
Message-ID: <523661.6738.qm@web59407.mail.ac4.yahoo.com>




> In case any of the Cortex/v7 projects or anyone else is interested, I have
> gcc-4.5 cross compiling the current GUMSTIX kernel on a i386 FreeBSD 6.4
> computer (QEMU runs better under FreeBSD 6.4) - I have not tried the libs
> yet to a "build world".
> 
That's nice Mark, good job :o)

> The kernel sources need some FreeBSD (format and at least one built-in define)
> extensions to compile that are not in the standard gcc. Besides the extensions
> that I copied over the code to put the binaries in the standard, reasonable
> places /usr/cross/libexec/cc1, for example).
> 
> Gcc 4.5 -O option found a few inline and structure warnings, that required
> either the removal of the -O option or -Werror option for these files.
> I chose to remove the -Werror. The warnings are:
> 
> wanted to add parenthesis around the &:
> ddb/db_ps.c
> 
> -O detects inline optimizations in the files:
> devfs_vnops.c pseudofs_vnops.c  kern_descrip.c kern_jail.c sys_pipe.c
> tty.c uipc_mbuf.c vfs_default.c vfs_lookup.c vfs_mount.c vfs_syscalls.c
> ffs_snapshot.c trap.c pmap.c
> 
> variably modified in the definition of a structure (and some inline opt):
> ufs_dirhash.c ufs_inode.c ufs_lookup.c  ufs_vfsops.c ufs_vnops.c
> 
I don't know what are the changes from previous versions of GCC with the trunk.
Maybe the release notes have more info on this....

> I made changes to the gcc-4.5-20090528 directory and the build directory.
> I will look at the libraries too.
> 
Cool!

Kind regards,
Vassilis L.



      

From tinguely at casselton.net  Thu Jun 18 03:05:54 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Thu Jun 18 03:06:00 2009
Subject: ARMv7 - EABI - Cross Compiler
In-Reply-To: <523661.6738.qm@web59407.mail.ac4.yahoo.com>
Message-ID: <200906180305.n5I35qci045136@casselton.net>


>  I don't know what are the changes from previous versions of GCC with the trunk.
>  Maybe the release notes have more info on this....

FreeBSD compiler has a variable defined into it that the kernel sources
expect to find, it has extended format commands, and it modifies
gcc/gcc.c to look for the support programs in normal places.

>  > I made changes to the gcc-4.5-20090528 directory and the build directory.
>  > I will look at the libraries too.
>  > 
>  Cool!

I am still using modified GNU make file. Static libraries can cross
compile an application to ARM but I gave up on configure/gmake on
libmudflap. My library compile process became a hacking in the configure
files. I was just walking around the problems as they popped up. Had
I read and understood all the configure options, maybe it would have
gone smoother. The "-Werror" complaints and "xgcc -E" as a pre-processor
command are the two biggest problem in the library compilation process.

Once we have a cross compiler that can make a kernel, it seems a waste
of time to keep going with the configure/gmake route. Your idea of
moving the sources over to the head/contrib/gcc and editing the BSD
make files in head/gnu/usr.bin/cc is the way to go because making
the compiler from sources is part of the cross build world.

I diff-ed the sources from the GNU original (4.2.1 if memory serves me
right) sources and filled in the missing pieces into the GCC 4.5 files.
Some things have already been put into GCC 4.5, some areas seemed re-written.
I was mostly interested in getting the FreeBSD extensions in. I can give you
diff of my sources against GCC 4.5 original code or tar up both the source
and build directory.  The changes would be simular for GCC 4.4.

There is nothing special about GCC 4.5, I just took the most recent source
that is available. Also, I just blindly copied the freebsd* header files
from head source into GCC 4.5. The real way of doing this is to edit up
the existing GCC 4.5 header files and add the new items. I did that with
a couple that are used in the ARM build.

The sources in the gcc support library files are not changed; it would
just take some BSD make file editing to get them to compile under the
head directory.

--Mark.
From venkiece2005 at gmail.com  Thu Jun 18 06:08:45 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Thu Jun 18 06:08:52 2009
Subject: [libc] dlclose gives "invalid shared object handle" without 
	pthread combination.
In-Reply-To: <20090616200756.70206fda@kan.dnsalias.net>
References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com>
	<20090616200756.70206fda@kan.dnsalias.net>
Message-ID: <6d53329e0906172308j28c7f404y49f759fea4842a29@mail.gmail.com>

Hi,

I have been porting NetBSD source in the Linux environment with our own
pthread library.

system environment:
Compiler: arm-linux-gcc-4.3.3
OS: Linux
Kernel: 2.6.29

Yes, it never even calls dlerr() in dlcose
but NetBSD __dlclose(void *handle) source sequence,

int
dlclose(void *handle)
{
	Obj_Entry *root = _rtld_dlcheck(handle);

	if (root == NULL)
		return -1;

	_rtld_debug.r_state = RT_DELETE;
	_rtld_debug_state();

	--root->dl_refcount;
	_rtld_unload_object(root, true);

	_rtld_debug.r_state = RT_CONSISTENT;
	_rtld_debug_state();

	return 0;
}

static Obj_Entry *
_rtld_dlcheck(void *handle)
{
        Obj_Entry *obj;

        for (obj = _rtld_objlist; obj != NULL; obj = obj->next)
                if (obj == (Obj_Entry *) handle)
                        break;
        xprintf("obj->dl_refcount is %d\n",obj->dl_refcount);
        if (obj == NULL || obj->dl_refcount == 0) {
                xwarnx("Invalid shared object handle %p", handle);
                return NULL;
        }
        return obj;
}

I have printed  xprintf("obj->dl_refcount is %d\n",obj->dl_refcount);
 obj->dl_refcount is getting zero(0).
So due to "obj->dl_refcount == 0"
the error "invalid shared object handle" is showing.

i do not know why this error is coming even though all the
constructor/destructor sequences are completed.

is it rtld_exit->fini->static C++ destructor->dlcose sequence problem?

Thanks & Regards,
Venkappa
On Wed, Jun 17, 2009 at 5:37 AM, Alexander Kabaev<kabaev@gmail.com> wrote:
> Hi,
>
> I do not think we on FreeBSD support NetBSD rtld with our pthread
> libraries, unless you already implemented all the necessary glue.
> The interface between threading library and rtld is rather intimate and
> tricky to get right.
>
> You provide no code to look at nor explicitly mention what OS and
> what version you are running your test on (FreeBSD?), I think you are
> on your own. Furthermore, your claim on 'correct'
> constructor/destructor is wrong given the sample code provided by
> NetBSD PR.
>
> Some more comments are inline.
>
> On Tue, 16 Jun 2009 14:59:36 +0530
> venki kaps <venkiece2005@gmail.com> wrote:
>
>> Hi,
>>
>> I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/)
>> for ARM/MIPS.
>>
>> I have C++ static constructor/destructor issue with my rtld.
>>
>> Problem Report:
>> "ld.elf_so does not execute .init/.fini functions in order" and [libc]
>> dlclose gives
>> "invalid shared object handle" when called through the fini function
>> of another module.
>>
>> The similar NetBSD/freeBSD issues are found from the following
>> References: [1] http://gnats.netbsd.org/37347
>> [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956
>>
>> The above issues are already commited in NetBSD-5-0-RELEASE.
>>
>> I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided
>> static constructor/destructor test and did not find any issues
>> with shared pthread combination but noticed [libc] dlclose gives
>> "invalid shared object handle" without pthread combination.
>>
>> The static constructor/destructor test results:
>>
>> It should be :
>> --------------
>>
>> $ ./foobar
>> foo_ctor
>> bar_ctor
>> tar_ctor
>> main_ctor
>> dep1_ctor
>> dep2_ctor
>> dll_ctor
>> dll_dtor
>> dep2_dtor
>> dep1_dtor
>> main_dtor
>> tar_dtor
>> bar_dtor
>> foo_dtor
>
> Given the test in Ref[1], both constructor and destructor orders are
> wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked
> before dep1_ctor and consequently dep2_dtor should be invoked after
> dep1_dtor.
>
>> While currently I get:
>> ----------------------
>>
>> with pthreads:
>>
>> $ ./foobar
>> foo_ctor
>> bar_ctor
>> tar_ctor
>> main_ctor
>> dep1_ctor
>> dep2_ctor
>> dll_ctor
>> dll_dtor
>> dep2_dtor
>> dep1_dtor
>> main_dtor
>> tar_dtor
>> bar_dtor
>> foo_dtor
>>
>> without pthreads:
>>
>> $ ./foobar
>> foo_ctor
>> bar_ctor
>> tar_ctor
>> main_ctor
>> dep1_ctor
>> dep2_ctor
>> dll_ctor
>> dll_dtor
>> dep2_dtor
>> dep1_dtor
>> main_dtor
>> tar_dtor
>> bar_dtor
>> foo_dtor
>> Invalid shared object handle 0xbdbed400
>
> Again, given the sample code from NetBSD PR cannot possibly print this
> message because it never even calls dlerr(). You must be looking at
> some other code and unless you provide it, understanding your problem
> and fixing it is next to impossible.
>
> Said that, thanks for pointing the FreeBSD PR to me. I will commit the
> fix for the problem described here shortly.
>
>> This gives a "invalid shared object handle" message
>> because the refcount field (obj->dl_refcount) for the handle is zero.
>>
>> I have little bit confused about dlclose destructor
>> with/without pthreads.
>>
>> I have some queries:
>> 1) Is it required any changes apart from the
>> NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in
>> thread-stub?
>>
>> Could anyone provide any inputs to the my issue?
>>
>> Thanks in advance.
>>
>> Thanks & Regards,
>> Venkappa
>
> --
> Alexander Kabaev
>
From tinderbox at freebsd.org  Sat Jun 20 02:25:40 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Jun 20 02:25:53 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090620022536.ED32F7302F@freebsd-current.sentex.ca>

TB --- 2009-06-20 01:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-20 01:20:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-20 01:20:00 - cleaning the object tree
TB --- 2009-06-20 01:20:34 - cvsupping the source tree
TB --- 2009-06-20 01:20:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-20 01:20:42 - building world
TB --- 2009-06-20 01:20:42 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-20 01:20:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-20 01:20:42 - TARGET=arm
TB --- 2009-06-20 01:20:42 - TARGET_ARCH=arm
TB --- 2009-06-20 01:20:42 - TZ=UTC
TB --- 2009-06-20 01:20:42 - __MAKE_CONF=/dev/null
TB --- 2009-06-20 01:20:42 - cd /src
TB --- 2009-06-20 01:20:42 - /usr/bin/make -B buildworld
>>> World build started on Sat Jun 20 01:20:45 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c
cc -O -pipe  -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign  -o newsyslog newsyslog.o ptimes.o 
gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz
gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz
===> usr.sbin/nfscbd (all)
cc -O -pipe  -std=gnu99  -c /src/usr.sbin/nfscbd/nfscbd.c
In file included from /src/usr.sbin/nfscbd/nfscbd.c:50:
/obj/arm/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function)
*** Error code 1

Stop in /src/usr.sbin/nfscbd.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-20 02:25:36 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-20 02:25:36 - ERROR: failed to build world
TB --- 2009-06-20 02:25:36 - 3025.02 user 368.67 system 3936.20 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Sat Jun 20 09:12:51 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Jun 20 09:13:09 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090620091248.58CBD7302F@freebsd-current.sentex.ca>

TB --- 2009-06-20 08:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-20 08:00:01 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-20 08:00:01 - cleaning the object tree
TB --- 2009-06-20 08:00:34 - cvsupping the source tree
TB --- 2009-06-20 08:00:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-20 08:00:44 - building world
TB --- 2009-06-20 08:00:44 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-20 08:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-20 08:00:44 - TARGET=arm
TB --- 2009-06-20 08:00:44 - TARGET_ARCH=arm
TB --- 2009-06-20 08:00:44 - TZ=UTC
TB --- 2009-06-20 08:00:44 - __MAKE_CONF=/dev/null
TB --- 2009-06-20 08:00:44 - cd /src
TB --- 2009-06-20 08:00:44 - /usr/bin/make -B buildworld
>>> World build started on Sat Jun 20 08:00:46 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc -O -pipe  -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c
cc -O -pipe  -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign  -o newsyslog newsyslog.o ptimes.o 
gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz
gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz
===> usr.sbin/nfscbd (all)
cc -O -pipe  -std=gnu99  -c /src/usr.sbin/nfscbd/nfscbd.c
In file included from /src/usr.sbin/nfscbd/nfscbd.c:50:
/obj/arm/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function)
*** Error code 1

Stop in /src/usr.sbin/nfscbd.
*** Error code 1

Stop in /src/usr.sbin.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-20 09:12:48 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-20 09:12:48 - ERROR: failed to build world
TB --- 2009-06-20 09:12:48 - 3030.41 user 373.41 system 4367.23 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From bugmaster at FreeBSD.org  Mon Jun 22 11:06:51 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jun 22 11:07:30 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200906221106.n5MB6on0017945@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From tinderbox at freebsd.org  Wed Jun 24 22:41:46 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Jun 24 22:41:53 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090624224143.45B527302F@freebsd-current.sentex.ca>

TB --- 2009-06-24 22:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-06-24 22:00:01 - starting HEAD tinderbox run for arm/arm
TB --- 2009-06-24 22:00:01 - cleaning the object tree
TB --- 2009-06-24 22:00:39 - cvsupping the source tree
TB --- 2009-06-24 22:00:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-06-24 22:00:57 - building world
TB --- 2009-06-24 22:00:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-06-24 22:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-06-24 22:00:57 - TARGET=arm
TB --- 2009-06-24 22:00:57 - TARGET_ARCH=arm
TB --- 2009-06-24 22:00:57 - TZ=UTC
TB --- 2009-06-24 22:00:57 - __MAKE_CONF=/dev/null
TB --- 2009-06-24 22:00:57 - cd /src
TB --- 2009-06-24 22:00:57 - /usr/bin/make -B buildworld
>>> World build started on Wed Jun 24 22:01:02 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
gzip -cn /src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/man/lwres_packet.3 > lwres_packet.3.gz
gzip -cn /src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/man/lwres_resutil.3 > lwres_resutil.3.gz
===> libexec (all)
===> libexec/atrun (all)
cc -O -pipe  -DATJOB_DIR=\"/var/at/jobs/\"  -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/src/libexec/atrun/../../usr.bin/at -I/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99  -c /src/libexec/atrun/atrun.c
cc -O -pipe  -DATJOB_DIR=\"/var/at/jobs/\"  -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/src/libexec/atrun/../../usr.bin/at -I/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99  -c /src/libexec/atrun/gloadavg.c
cc -O -pipe  -DATJOB_DIR=\"/var/at/jobs/\"  -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/src/libexec/atrun/../../usr.bin/at -I/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99   -o atrun atrun.o gloadavg.o -lpam -lutil
/obj/arm/src/tmp/usr/lib/libc.so: undefined reference to `freebsd7___semctl'
*** Error code 1

Stop in /src/libexec/atrun.
*** Error code 1

Stop in /src/libexec.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-06-24 22:41:43 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-06-24 22:41:43 - ERROR: failed to build world
TB --- 2009-06-24 22:41:43 - 1866.94 user 261.82 system 2501.96 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From hselasky at c2i.net  Sun Jun 28 10:55:17 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Sun Jun 28 10:55:24 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906231912.20741.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<20090623121129.d18492a3.ray@dlink.ua>
	<200906231912.20741.hselasky@c2i.net>
Message-ID: <200906281154.43392.hselasky@c2i.net>

Hi Piotr and Rafal,

Your patch is not fully correct. It will break support for x86 and more when 
bounce pages are uses.

Let's get the definitions right:

man busdma
<cite>

             BUS_DMASYNC_PREREAD    Perform any synchronization required prior
                                    to an update of host memory by the device.

             BUS_DMASYNC_PREWRITE   Perform any synchronization required after
                                    an update of host memory by the CPU and
                                    prior to device access to host memory.

             BUS_DMASYNC_POSTREAD   Perform any synchronization required after
                                    an update of host memory by the device and
                                    prior to CPU access to host memory.

             BUS_DMASYNC_POSTWRITE  Perform any synchronization required after
                                    device access to host memory.

</cite>

My view:

XXX_PREXXX functions should be used prior to read/write device access.

In other words, PRE has to be a flush operation.

XXX_POSTXXX functions should be used after read/write device access.

In other words, POST has to be an invalidate operation.

Reading:

src/sys/arm/arm/busdma_machdep.c

I find bus_dmamap_sync_buf() to be coherent with this view.

Can you check if the COHERENT bit is set for your allocation?

        if (map->flags & DMAMAP_COHERENT)
                return;

Summed up:

The existing code is doing correct. What is known is a problem with the memory 
mapping, so that the same memory page can get mapped with different 
attributes, which makes the problem appear.

--HPS

From venkiece2005 at gmail.com  Mon Jun 29 07:33:18 2009
From: venkiece2005 at gmail.com (venki kaps)
Date: Mon Jun 29 07:33:25 2009
Subject: Fwd: [libc] dlclose gives "invalid shared object handle" without 
	pthread combination.
In-Reply-To: <6d53329e0906182148k57b36ab6n6ddf1124ad4dfd6c@mail.gmail.com>
References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com>
	<6d53329e0906182148k57b36ab6n6ddf1124ad4dfd6c@mail.gmail.com>
Message-ID: <6d53329e0906290033g54895993iae826416e9d08f4@mail.gmail.com>

Hi,

Ref:
http://www.mail-archive.com/svn-src-all@freebsd.org/msg10960.html

Log:
  Allow order of initialization of loaded shared objects to be
  altered through their .init code. This might happen if init
  vector calls dlopen on its own and that dlopen causes some not
  yet initialized object to be initialized earlier as part of that
  dlopened DAG.

  Do not reset module reference counts to zero on final fini vector
  run when process is exiting. Just add an additional parameter to
  force fini vector invocation regardless of current reference count
  value if object was not destructed yet. This allows dlclose called
  from fini vector to proceed normally instead of failing with handle
  validation error.

Query:
-------
I have one question regarding " Do not reset module reference counts
to zero on final fini vector
  run when process is exiting".

Observation:
---------------
The above issue normally happened when object is destructed and gives handle
 validation error.

I have expected this is related to dl_refcount issue when process is exiting.

Am just giving some more explanation regarding this issue:

When i tested in the my Linux environment it shows the
dl_reference count is 1 when dlopen and 0 when dlclose.
In this test when the main dlclose invokes, the reference count is decremented
to zero But still other dependent objects are present and for these objects
dl_reference count is required with one(1) to close the handle successfully.

As per dl* scenario, the
dl_reference count has to be incremented by one(1) for the main
object(main executable)
as well as other ELF dependencies object.

Now, I have invoked dl_reference count is incremented by one(1) for main object
handle in _rtld_map_object function which is called by _rtld().

rtld Changes:
---------------
_rtld():
/* Load the main program. */
Location: src/libexec/ld.elf_so/rtld.c:

  _rtld_objmain = _rtld_map_object(obj_name, fd, NULL);
 _rtld_map_object():

/ *
  * Map a shared object into memory.  The argument is a file descriptor,
  * which must be open on the object and positioned at its beginning.
  * The return value is a pointer to a newly-allocated Obj_Entry structure
  * for the shared object.  Returns NULL on failure.
  */

 --- a/src/libexec/ld.elf_so/map_object.c
+++ b/src/libexec/ld.elf_so/map_object.c

@@ -181,6 +181,10 @@ _rtld_map_object(const char *path, int f
        phdr = (Elf_Phdr *) ((caddr_t)ehdr + ehdr->e_phoff);
        phlimit = phdr + ehdr->e_phnum;
        nsegs = 0;

+
+         /*
+          * And it was opened directly If trying to open
+          * the link map for the main executable. So the dl_recount
+          * must be the main dlopen one.
+          */
+          ++obj->dl_refcount;
+
            while (phdr < phlimit) {
                switch (phdr->p_type) {
                case PT_INTERP:


After the above changes, [libc] dlclose does not give
"invalid shared object handle" with/without pthread combination
Since the dl_reference count is 2 instead of 1 for main object handle
and 1 instead of 0 for other dependent objects.

Could you give opinion about the above issue?


Thanks & Regards,
Venkappa

---------- Forwarded message ----------
From: venki kaps <venkiece2005@gmail.com>
Date: Fri, Jun 19, 2009 at 10:18 AM
Subject: [libc] dlclose gives "invalid shared object handle" without
pthread combination.
To: gnats-bugs@netbsd.org


Hi,

I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/)
for ARM/MIPS and ?have been porting NetBSD source in the Linux
environment with our own
pthread library.

system environment:
Compiler: arm-linux-gcc-4.3.3
OS: Linux
Kernel: 2.6.29

I have C++ static constructor/destructor issue with my rtld.

Problem Report:
"ld.elf_so does not execute .init/.fini functions in order" and [libc]
dlclose gives
"invalid shared object handle" when called through the fini function of another
module.

The similar NetBSD/freeBSD issues are found from the following References:
[1] http://gnats.netbsd.org/37347
[2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956

The above issues are already commited in NetBSD-5-0-RELEASE.

I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided
static constructor/destructor test and did not find any issues
with shared pthread combination but noticed [libc] dlclose gives
"invalid shared object handle" without pthread combination.

The static constructor/destructor test results:

It should be :
--------------

$ ./foobar
foo_ctor
bar_ctor
tar_ctor
main_ctor
dep1_ctor
dep2_ctor
dll_ctor
dll_dtor
dep2_dtor
dep1_dtor
main_dtor
tar_dtor
bar_dtor
foo_dtor

While currently I get:
----------------------

with pthreads:

$ ./foobar
foo_ctor
bar_ctor
tar_ctor
main_ctor
dep1_ctor
dep2_ctor
dll_ctor
dll_dtor
dep2_dtor
dep1_dtor
main_dtor
tar_dtor
bar_dtor
foo_dtor

without pthreads:

$ ./foobar
foo_ctor
bar_ctor
tar_ctor
main_ctor
dep1_ctor
dep2_ctor
dll_ctor
dll_dtor
dep2_dtor
dep1_dtor
main_dtor
tar_dtor
bar_dtor
foo_dtor
Invalid shared object handle 0xbdbed400

This gives a "invalid shared object handle" message
because the refcount field (obj->dl_refcount) for the handle is zero.

it never even calls dlerr() in dlcose
but __dlclose(void *handle) source sequence,

int
dlclose(void *handle)
{
? ? ? Obj_Entry *root = _rtld_dlcheck(handle);

? ? ? if (root == NULL)
? ? ? ? ? ? ? return -1;

? ? ? _rtld_debug.r_state = RT_DELETE;
? ? ? _rtld_debug_state();

? ? ? --root->dl_refcount;
? ? ? _rtld_unload_object(root, true);

? ? ? _rtld_debug.r_state = RT_CONSISTENT;
? ? ? _rtld_debug_state();

? ? ? return 0;
}

static Obj_Entry *
_rtld_dlcheck(void *handle)
{
? ? ? Obj_Entry *obj;

? ? ? for (obj = _rtld_objlist; obj != NULL; obj = obj->next)
? ? ? ? ? ? ? if (obj == (Obj_Entry *) handle)
? ? ? ? ? ? ? ? ? ? ? break;
? ? ? xprintf("obj->dl_refcount is %d\n",obj->dl_refcount);
? ? ? if (obj == NULL || obj->dl_refcount == 0) {
? ? ? ? ? ? ? xwarnx("Invalid shared object handle %p", handle);
? ? ? ? ? ? ? return NULL;
? ? ? }
? ? ? return obj;
}

I have printed ?xprintf("obj->dl_refcount is %d\n",obj->dl_refcount);
?obj->dl_refcount is getting zero(0).
So due to "obj->dl_refcount == 0"
the error "invalid shared object handle" is showing.

I have little bit confused about dlclose destructor
with/without pthreads.

I have some queries:
1) Is it required any changes apart from the NetBSD-5-0-RELEASE/{Ref[1],[2]}?
2) Are any changes required in thread-stub?
3) i do not know why this error is coming even though all the
? constructor/destructor sequences are completed.
4) is it rtld_exit/fini/static C++ destructor/dlcose sequence problem?
?(OR)
?is it crtstuff/exit/atexit/cxa_finalize/cxa_atexit sequence problem?

Could anyone provide any inputs to the my issue?

Thanks in advance.

Thanks & Regards,
Venkappa
From hackr_d at yahoo.com  Mon Jun 29 08:19:51 2009
From: hackr_d at yahoo.com (Donn Miller)
Date: Mon Jun 29 08:19:58 2009
Subject: Support for the Friendly Arm (mini 2440) development board
Message-ID: <992872.90651.qm@web35703.mail.mud.yahoo.com>

http://www.developmentboard.net/index.php/productdetail/Development+board/ARM9/SAMSUNG/S3C2440/MINI2440+with+LCD/info/1
http://www.friendlyarm.net/products/mini2440
http://code.google.com/p/mini2440/

Partial dmesg of Linux kernel I managed to boot on this device:

Linux version 2.6.30-rc8 (dmmiller@localhost) (gcc version 4.4.0 (Gentoo 4.4.0 p1.1) ) #1
Thu Jun 4 07:54:48 EDT 2009^M
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177^M
CPU: VIVT data cache, VIVT instruction cache^M
Machine: MINI2440^M
Memory policy: ECC disabled, Data cache writeback^M
CPU S3C2440A (id 0x32440001)^M
S3C24XX Clocks, (c) 2004 Simtec Electronics^M
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz^M
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on^M
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256^M
Kernel command line: root=/dev/mtdblock3 rootfstype=jffs2 console=ttySAC0,115200^M
NR_IRQS:85^M
irq: clearing pending status 02000000^M
irq: clearing subpending status 00000003^M
irq: clearing subpending status 00000002^M
PID hash table entries: 256 (order: 8, 1024 bytes)^M
Console: colour dummy device 80x30^M
console [ttySAC0] enabled^M
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)^M
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)^M
Memory: 64MB = 64MB total^M
Memory: 60748KB available (3472K code, 409K data, 128K init, 0K highmem)^M

I also attached the output from the serial console, showing an attempt to boot a Linux arm kernel.  Note that mounting root was unsuccessful (didn't install a small embedded distribution yet).

I figured this dmesg, though from Linux, will suffice to sufficiently describe what this device is and if I can boot FreeBSD-arm on it.

Thanks for your help.

Donn


      
-------------- next part --------------
Script started on Mon Jun 29 03:47:40 2009
gateway# cu -s 115200 -l ttyU0
Connected
þ

U-Boot 1.3.2-mini2440 (Jun  4 2009 - 02:31:33)

I2C:   ready
DRAM:  64 MB
Flash:  2 MB
NAND:  64 MiB
Found Environment offset in OOB..
USB:   S3C2410 USB Deviced
In:    serial
Out:   serial
Err:   serial
MAC: 08:08:11:18:12:27
Hit any key to stop autoboot:  3  2  1  0 
MINI2440 # nboot kernel;bootm

Loading from NAND 64MiB 3,3V 8-bit, offset 0x60000
   Image Name:   
   Created:      2009-06-18   7:31:03 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1997232 Bytes =  1.9 MB
   Load Address: 30008000
   Entry Point:  30008000
## Booting kernel from Legacy Image at 32000000 ...
   Image Name:   
   Created:      2009-06-18   7:31:03 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1997232 Bytes =  1.9 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................ done, booting the kernel.
Linux version 2.6.30-rc8 (dmmiller@localhost) (gcc version 4.4.0 (Gentoo 4.4.0 p1.1) ) #1 Thu Jun 4 07:54:48 EDT 2009
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: MINI2440
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C24XX Clocks, (c) 2004 Simtec Electronics
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=/dev/mtdblock3 rootfstype=jffs2 console=ttySAC0,115200
NR_IRQS:85
irq: clearing pending status 02000000
irq: clearing subpending status 00000003
irq: clearing subpending status 00000002
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x30
console [ttySAC0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60748KB available (3472K code, 409K data, 128K init, 0K highmem)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 201.93 BogoMIPS (lpj=504832)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 704 bytes
NET: Registered protocol family 16
MINI2440: Option string mini2440=0tb
MINI2440: LCD [0:240x320] 1:800x480 2:1024x768
S3C2440: Initialising architecture
S3C2440: IRQ Support
S3C24XX DMA Driver, (c) 2003-2004,2006 Simtec Electronics
DMA channel 0 at c4808000, irq 33
DMA channel 1 at c4808040, irq 34
DMA channel 2 at c4808080, irq 35
DMA channel 3 at c48080c0, irq 36
S3C244X: Clock Support, DVS off
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
s3c2440-i2c s3c2440-i2c: slave address 0x10
s3c2440-i2c s3c2440-i2c: bus frequency set to 98 KHz
s3c2440-i2c s3c2440-i2c: i2c-0: S3C I2C adapter
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 118
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Console: switching to colour frame buffer device 60x53
fb0: s3c2410fb frame buffer device
s3c2440-uart.0: ttySAC0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: ttySAC1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: ttySAC2 at MMIO 0x50008000 (irq = 76) is a S3C2440
brd: module loaded
at24 0-0050: 1024 byte 24c08 EEPROM (writable)
dm9000 Ethernet Driver, V1.31
eth0 (dm9000): not using net_device_ops yet
eth0: dm9000e at c486e300,c4872304 IRQ 51 MAC: 08:08:11:18:12:27 (chip)
S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c2440-nand s3c2440-nand: Tacls=1, 9ns Twrph0=3 29ns, Twrph1=2 19ns
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)
Creating 4 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x000000000000-0x000000040000 : "u-boot"
ftl_cs: FTL header not found.
0x000000040000-0x000000060000 : "u-boot-env"
ftl_cs: FTL header not found.
0x000000060000-0x000000560000 : "kernel"
ftl_cs: FTL header not found.
0x000000560000-0x000004000000 : "root"
ftl_cs: FTL header not found.
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new interface driver libusual
s3c2440-usbgadget s3c2440-usbgadget: S3C2440: increasing FIFO to 128 bytes
mice: PS/2 mouse device common for all mice
input: gpio-keys as /devices/platform/gpio-keys/input/input0
s3c2440-ts s3c2440-ts: Starting
  Created group ts filter len 12 depth 2 close 10 thresh 6
  Created Median ts filter len 20 depth 2 dec 24
  Created Mean ts filter len 4 depth 2 thresh 65535
  Created Linear ts filter depth 2
s3c2440-ts s3c2440-ts: 4 filter(s) initialized
s3c2440-ts s3c2440-ts: successfully loaded
input: s3c2410 TouchScreen as /devices/virtual/input/input1
S3C24XX RTC, (c) 2004,2006 Simtec Electronics
s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling
s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0
i2c /dev entries driver
S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
cpuidle: using governor ladder
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mapped channel 0 to 0
s3c2440-sdi s3c2440-sdi: powered down.
s3c2440-sdi s3c2440-sdi: initialisation done.
Registered led device: led1
Registered led device: led2
Registered led device: led3
Registered led device: led4
Registered led device: backlight
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.20.
No device for DAI UDA134X
No device for DAI s3c24xx-i2s
S3C24XX_UDA134X SoC Audio driver
UDA134X SoC Audio Codec
asoc: UDA134X <-> s3c24xx-i2s mapping ok
ALSA device list:
  #0: S3C24XX_UDA134X (UDA134X)
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
s3c2410-rtc s3c2410-rtc: setting system clock to 2009-06-29 03:43:07 UTC (1246246987)
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03a98370: 0xffff instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03a9c370: 0xffff instead
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
empty_blocks 3749, bad_blocks 1, c->nr_blocks 3752
VFS: Cannot open root device "mtdblock3" or unknown-block(31,3)
Please append a correct "root=" boot option; here are the available partitions:
1f00             256 mtdblock0 (driver?)
1f01             128 mtdblock1 (driver?)
1f02            5120 mtdblock2 (driver?)
1f03           60032 mtdblock3 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
[<c002d650>] (unwind_backtrace+0x0/0xd8) from [<c02bbd1c>] (panic+0x40/0x110)
[<c02bbd1c>] (panic+0x40/0x110) from [<c0008e18>] (mount_block_root+0x1c8/0x208)
[<c0008e18>] (mount_block_root+0x1c8/0x208) from [<c00090ac>] (prepare_namespace+0x160/0x1b8)
[<c00090ac>] (prepare_namespace+0x160/0x1b8) from [<c00083f4>] (kernel_init+0xb8/0xe4)
[<c00083f4>] (kernel_init+0xb8/0xe4) from [<c003d200>] (do_exit+0x0/0x588)
[<c003d200>] (do_exit+0x0/0x588) from [<c381a000>] (0xc381a000)
~
[EOT]
gateway# ^Dexit

Script done on Mon Jun 29 03:48:23 2009
From stas at FreeBSD.org  Mon Jun 29 08:38:26 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Mon Jun 29 08:38:33 2009
Subject: Support for the Friendly Arm (mini 2440) development board
In-Reply-To: <992872.90651.qm@web35703.mail.mud.yahoo.com>
References: <992872.90651.qm@web35703.mail.mud.yahoo.com>
Message-ID: <20090629123815.c0c2ad11.stas@FreeBSD.org>

On Mon, 29 Jun 2009 00:53:08 -0700 (PDT)
Donn Miller <hackr_d@yahoo.com> mentioned:

> http://www.developmentboard.net/index.php/productdetail/Development+board/ARM9/SAMSUNG/S3C2440/MINI2440+with+LCD/info/1
> http://www.friendlyarm.net/products/mini2440
> http://code.google.com/p/mini2440/
> 

S3C24xx is not yet supported in FreeBSD.  The current code for Samsung CPUs are
available in FreeBSD P4 repo but the ports is not complete yet.

-- 
Stanislav Sedov
ST4096-RIPE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090629/80bd5b63/attachment.pgp
From kosmo at semihalf.com  Mon Jun 29 09:29:42 2009
From: kosmo at semihalf.com (Piotr =?utf-8?q?Zi=C4=99cik?=)
Date: Mon Jun 29 09:29:49 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906281154.43392.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906231912.20741.hselasky@c2i.net>
	<200906281154.43392.hselasky@c2i.net>
Message-ID: <200906291111.20725.kosmo@semihalf.com>

Sunday 28 June 2009 11:54:40 Hans Petter Selasky napisa?(a):
> Hi Piotr and Rafal,
>
> Your patch is not fully correct. It will break support for x86 and more
> when bounce pages are uses.
>
> Let's get the definitions right:
>
> man busdma
> (...)
>
> My view:
>
> XXX_PREXXX functions should be used prior to read/write device access.
>
> In other words, PRE has to be a flush operation.
>
> XXX_POSTXXX functions should be used after read/write device access.
>
> In other words, POST has to be an invalidate operation.
>
> Reading:
>
> src/sys/arm/arm/busdma_machdep.c
>
> I find bus_dmamap_sync_buf() to be coherent with this view.

If everything is OK, then why USB does not work on ARM and MIPS ?
Let's look into busdma for these platforms:

usb_pc_cpu_invalidate(): [BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE]
	i386:		NOP
	arm:		Invalidate + hacks for VIPT cache.
	mips:		NOP

usb_pc_cpu_flush(): [BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE]
	i386:		NOP
	arm:		Writeback invalidate
	mips:		Writeback invalidate.

I do not see direct coherency between flags passed to bus_dma and cache 
operations, which could be source of problem.

Let's also look at usb_pc_cpu_invalidate() usage in 
sys/dev/usb/controller/ehci.c:
<cite>
while (1) {
		usb_pc_cpu_invalidate(td->page_cache);
                status = hc32toh(sc, td->qtd_status);

		(...)

		if (status & EHCI_QTD_HALTED) {
			break;
		}

		(...)

		td = td->obj_next;
</cite>

In my oppinion usb_pc_cpu_invalidate() used here suggests that it is doing 
cache invalidation not "Perform any synchronization required after 					     
an update of host memory by the device and prior to CPU access to host 
memory".

As this function is implemented as bus_dmamap_sync() all busdma rules should 
be applied:
<cite>
If read and write operations are not preceded and followed by the
appropriate synchronization operations, behavior is undefined.
</cite>

In code shown above (and many more places in USB stack) there is no following
synchronization operation, which also could be source of problem.

My major question here is why bus_dma is used for flushing and invalidation
CPU caches instead of cpu_*() functions wich was written for this purpuose.

> Can you check if the COHERENT bit is set for your allocation?
>
>         if (map->flags & DMAMAP_COHERENT)
>                 return;
>

No. This bit is not set.

> Summed up:
>
> The existing code is doing correct. What is known is a problem with the
> memory mapping, so that the same memory page can get mapped with different
> attributes, which makes the problem appear.

I don't think so:
$ man busdma
<cite>
BUS_DMA_COHERENT
	Attempt to map this memory such that cache sync operations are as cheap as
	possible.  This flag is typically set on memory that will be accessed by both
	a CPU and a DMA engine, frequently.  Use of this flag does not remove the 
	requirement of using bus_dmamap_sync, but it may reduce the cost of 	
	performing these operations. 
</cite>

This means that BUS_DMA_COHERENT does not guarantee no-cache mapping - this is
only a hint for busdma subsystem that region will be synced frequently. Please 
look at discussion at 
http://kerneltrap.org/mailarchive/freebsd-current/2009/5/27/5817243

-- 
Best regards.
Piotr Ziecik
From hselasky at c2i.net  Mon Jun 29 09:55:46 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Jun 29 09:55:53 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291111.20725.kosmo@semihalf.com>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906281154.43392.hselasky@c2i.net>
	<200906291111.20725.kosmo@semihalf.com>
Message-ID: <200906291155.13941.hselasky@c2i.net>

Hi Piotr and Rafal,


On Monday 29 June 2009 11:11:20 Piotr Zi?cik wrote:
> Sunday 28 June 2009 11:54:40 Hans Petter Selasky napisa?(a):
> > Hi Piotr and Rafal,
> >
> > Your patch is not fully correct. It will break support for x86 and more
> > when bounce pages are uses.
> >
> > Let's get the definitions right:
> >
> > man busdma
> > (...)
> >
> > My view:
> >
> > XXX_PREXXX functions should be used prior to read/write device access.
> >
> > In other words, PRE has to be a flush operation.
> >
> > XXX_POSTXXX functions should be used after read/write device access.
> >
> > In other words, POST has to be an invalidate operation.
> >
> > Reading:
> >
> > src/sys/arm/arm/busdma_machdep.c
> >
> > I find bus_dmamap_sync_buf() to be coherent with this view.
>
> If everything is OK, then why USB does not work on ARM and MIPS ?

I'm not saying everything is OK, I just don't agree that the problem is in 
USB.

If you look at:

http://fxr.watson.org/fxr/source/i386/i386/busdma_machdep.c#L931

Then you see the XXX_PREXXX means copy from client buffer (bpage->datavaddr) 
to real DMA buffer (bpage->vaddr). That means flush memory from cache to RAM. 
You want to change it into a XXX_POSTXXX (???) in the USB code, and that won't 
work for x86 and amd64 ...

Then you also see that XXX_POSTXXX is doing the opposite, cleaning the cache 
and copying from RAM into the "cache" buffer.

> Let's look into busdma for these platforms:


>
> usb_pc_cpu_invalidate(): [BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE]
> 	i386:		NOP
> 	arm:		Invalidate + hacks for VIPT cache.
> 	mips:		NOP

Isn't this correct cleaning the cache on ARM?

>
> usb_pc_cpu_flush(): [BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE]
> 	i386:		NOP
> 	arm:		Writeback invalidate
> 	mips:		Writeback invalidate.

Isn't this correct flushing the cache to RAM on ARM?

>
> I do not see direct coherency between flags passed to bus_dma and cache
> operations, which could be source of problem.

Can you explain a little bit more what you see is not coherent?

>
> Let's also look at usb_pc_cpu_invalidate() usage in
> sys/dev/usb/controller/ehci.c:
> <cite>
> while (1) {
> 		usb_pc_cpu_invalidate(td->page_cache);
>                 status = hc32toh(sc, td->qtd_status);
>
> 		(...)
>
> 		if (status & EHCI_QTD_HALTED) {
> 			break;
> 		}
>
> 		(...)
>
> 		td = td->obj_next;
> </cite>
>
> In my oppinion usb_pc_cpu_invalidate() used here suggests that it is doing
> cache invalidation not "Perform any synchronization required after
> an update of host memory by the device and prior to CPU access to host
> memory".

The invalidate means: Clean the cache, so that the succeeding read fetches its 
value from RAM.

>
> As this function is implemented as bus_dmamap_sync() all busdma rules
> should be applied:
> <cite>
> If read and write operations are not preceded and followed by the
> appropriate synchronization operations, behavior is undefined.
> </cite>
>
> In code shown above (and many more places in USB stack) there is no
> following synchronization operation, which also could be source of problem.

All cases where transfer descriptors are updated are wrapped with bus-sync 
operations, through the "usb_pc_cpu_xxx()" functions. Else mutexes are used. 
Please give an example of such a place where improper synchronisation happens.

>
> My major question here is why bus_dma is used for flushing and invalidation
> CPU caches instead of cpu_*() functions wich was written for this purpuose.

Because that is what other drivers are doing. I think using cpu_*() is more 
alike Linux, and also, if the memory is on a bounce page, cpu_*() will yield 
the wrong result.

> > Can you check if the COHERENT bit is set for your allocation?
> >
> >         if (map->flags & DMAMAP_COHERENT)
> >                 return;
>
> No. This bit is not set.
>
> > Summed up:
> >
> > The existing code is doing correct. What is known is a problem with the
> > memory mapping, so that the same memory page can get mapped with
> > different attributes, which makes the problem appear.
>

--HPS

From kosmo at semihalf.com  Mon Jun 29 10:49:46 2009
From: kosmo at semihalf.com (Piotr =?utf-8?q?Zi=C4=99cik?=)
Date: Mon Jun 29 10:49:52 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291155.13941.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291111.20725.kosmo@semihalf.com>
	<200906291155.13941.hselasky@c2i.net>
Message-ID: <200906291249.43983.kosmo@semihalf.com>

Monday 29 June 2009 11:55:11 Hans Petter Selasky napisa?(a):
> Hi Piotr and Rafal,
>
> I'm not saying everything is OK, I just don't agree that the problem is in
> USB.
>
> If you look at:
>
> http://fxr.watson.org/fxr/source/i386/i386/busdma_machdep.c#L931
>
> Then you see the XXX_PREXXX means copy from client buffer
> (bpage->datavaddr) to real DMA buffer (bpage->vaddr). That means flush
> memory from cache to RAM. You want to change it into a XXX_POSTXXX (???) in
> the USB code, and that won't work for x86 and amd64 ...
>
> Then you also see that XXX_POSTXXX is doing the opposite, cleaning the
> cache and copying from RAM into the "cache" buffer.
>
> Isn't this correct flushing the cache to RAM on ARM?
>

It is correct if you use busdma in correct way:
	[... prepare data to transfer ...]
	bus_dmamap_sync(..., PREREAD | PREWRITE);
	[... do transfer ...]
	bus_dmamap_sync(..., POSTREAD | POSTWRITE);
	[... check results ...]

> > I do not see direct coherency between flags passed to bus_dma and cache
> > operations, which could be source of problem.
>
> Can you explain a little bit more what you see is not coherent?

I thought about direct relation between calling bus_dmamap_sync()
with given flag and cache operation. usb_pc_cpu_invalidate() not always
is doing invalidate and usb_pc_cpu_flush() not always is doing flush.

> > In my oppinion usb_pc_cpu_invalidate() used here suggests that it is
> > doing cache invalidation not "Perform any synchronization required after
> > an update of host memory by the device and prior to CPU access to host
> > memory".
>
> The invalidate means: Clean the cache, so that the succeeding read fetches
> its value from RAM.

But usb_pc_cpu_invalidate(), which should do cache invalidate, doing
NOP or other operations depending on architecture bus_dma implementation. 
Therefore these functions should not be used for enforcing cache operations.

> > As this function is implemented as bus_dmamap_sync() all busdma rules
> > should be applied:
> > <cite>
> > If read and write operations are not preceded and followed by the
> > appropriate synchronization operations, behavior is undefined.
> > </cite>
> >
> > In code shown above (and many more places in USB stack) there is no
> > following synchronization operation, which also could be source of
> > problem.
>
> All cases where transfer descriptors are updated are wrapped with bus-sync
> operations, through the "usb_pc_cpu_xxx()" functions. Else mutexes are
> used. Please give an example of such a place where improper synchronisation
> happens.

Look into ehci_check_transfer() function 
(http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294) 

usb_pc_cpu_invalidate() [bus_dmamap_sync()] is not used in this function 
correcly. It is not paired with usb_pc_cpu_flush() [opposite 
bus_dmamap_sync()] as busdma requires (see part of manpage cited above).
The same problem is in part of code shown in previous mail.

If usb_pc_cpu_invalidate()/usb_pc_cpu_flush() functions had been implemented 
without using busdma, for example as cpu_*() functions, ehci_check_transfer() 
would have been 100% correct. In current code busdma requirements are simply 
not met.

> > My major question here is why bus_dma is used for flushing and
> > invalidation CPU caches instead of cpu_*() functions wich was written for
> > this purpuose.
>
> Because that is what other drivers are doing. I think using cpu_*() is more
> alike Linux, and also, if the memory is on a bounce page, cpu_*() will
> yield the wrong result.

Ok. So if you use bus_dma(), please use it in correct way.

-- 
Best Regards.
Piotr Ziecik
From andrew at fubar.geek.nz  Mon Jun 29 10:55:41 2009
From: andrew at fubar.geek.nz (Andrew Turner)
Date: Mon Jun 29 10:55:48 2009
Subject: Support for the Friendly Arm (mini 2440) development board
In-Reply-To: <992872.90651.qm@web35703.mail.mud.yahoo.com>
References: <992872.90651.qm@web35703.mail.mud.yahoo.com>
Message-ID: <20090629223744.14ff27b3@fubar.geek.nz>

On Mon, 29 Jun 2009 00:53:08 -0700 (PDT)
Donn Miller <hackr_d@yahoo.com> wrote:
> I also attached the output from the serial console, showing an
> attempt to boot a Linux arm kernel.  Note that mounting root was
> unsuccessful (didn't install a small embedded distribution yet).
> 
> I figured this dmesg, though from Linux, will suffice to sufficiently
> describe what this device is and if I can boot FreeBSD-arm on it.
I have run FreeBSD on a mini2440 board before. Support for it is still
in development as I've been working on support for NAND flash.

Unfortunately the kernel appears to not boot anymore due to an
alignment fault early on in the boot process.

Andrew
From hackr_d at yahoo.com  Mon Jun 29 10:56:18 2009
From: hackr_d at yahoo.com (Donn Miller)
Date: Mon Jun 29 10:56:24 2009
Subject: Support for the Friendly Arm (mini 2440) development board
Message-ID: <793595.43066.qm@web35704.mail.mud.yahoo.com>




--- On Mon, 6/29/09, Andrew Turner <andrew@fubar.geek.nz> wrote:

> From: Andrew Turner <andrew@fubar.geek.nz>
> Subject: Re: Support for the Friendly Arm (mini 2440) development board
> To: "Donn Miller" <hackr_d@yahoo.com>
> Cc: freebsd-arm@freebsd.org
> Date: Monday, June 29, 2009, 6:37 AM
> On Mon, 29 Jun 2009 00:53:08 -0700
> (PDT)
> Donn Miller <hackr_d@yahoo.com>
> wrote:
> > I also attached the output from the serial console,
> showing an
> > attempt to boot a Linux arm kernel.? Note that
> mounting root was
> > unsuccessful (didn't install a small embedded
> distribution yet).
> > 
> > I figured this dmesg, though from Linux, will suffice
> to sufficiently
> > describe what this device is and if I can boot
> FreeBSD-arm on it.
> I have run FreeBSD on a mini2440 board before. Support for
> it is still
> in development as I've been working on support for NAND
> flash.
> 
> Unfortunately the kernel appears to not boot anymore due to
> an alignment fault early on in the boot process.

Were you able to get it to boot FreeBSD from a smartmedia card?  That would be another area that possibly needs working on as well.


      
From bugmaster at FreeBSD.org  Mon Jun 29 11:06:55 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jun 29 11:07:31 2009
Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org
Message-ID: <200906291106.n5TB6sHm046252@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o arm/134368   arm        [patch] nslu2_led driver for the LEDs on the NSLU2
o arm/134338   arm        [patch] Lock GPIO accesses on ixp425
o arm/134092   arm        [patch] NSLU.hints contains wrong hints for on board n

3 problems total.

From hselasky at c2i.net  Mon Jun 29 11:38:25 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Jun 29 11:38:38 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291249.43983.kosmo@semihalf.com>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291155.13941.hselasky@c2i.net>
	<200906291249.43983.kosmo@semihalf.com>
Message-ID: <200906291337.43635.hselasky@c2i.net>

Hi,

On Monday 29 June 2009 12:49:43 Piotr Zi?cik wrote:
> Monday 29 June 2009 11:55:11 Hans Petter Selasky napisa?(a):
> > Hi Piotr and Rafal,

>
> Look into ehci_check_transfer() function
> (http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294)
>
> usb_pc_cpu_invalidate() [bus_dmamap_sync()] is not used in this function
> correcly. It is not paired with usb_pc_cpu_flush() [opposite
> bus_dmamap_sync()] as busdma requires (see part of manpage cited above).
> The same problem is in part of code shown in previous mail.
>
> If usb_pc_cpu_invalidate()/usb_pc_cpu_flush() functions had been
> implemented without using busdma, for example as cpu_*() functions,
> ehci_check_transfer() would have been 100% correct. In current code busdma
> requirements are simply not met.

Good point. Unfortunately I cannot pair like you suggest, because then I can 
overwrite values updated by the hardware, if I first read the status for 
example, and the same 32-bits are updated by hardware, before the old value is 
flushed over the new one.. Also I cannot find the word "pair" in the busdma 
manpage? Where is this requirement stated?

I see some things:

You wrote earlier that the COHERENT flag was not set. That means your setup is 
using bounce pages for DMA? Right?

Then I see a problem, if I do several POST operations in a row then I can see 
that the real DMA memory can get cached:

In: "src/sys/arm/arm/busdma_machdep.c"

Is "vaddr_nocache" set or cleared?

                if (op & BUS_DMASYNC_POSTREAD) {
                        if (bpage->vaddr_nocache == 0) {
                                cpu_dcache_inv_range(bpage->vaddr,
                                    bpage->datacount);
                                cpu_l2cache_inv_range(bpage->vaddr,
                                    bpage->datacount);
                        }
                        bcopy((void *)(bpage->vaddr_nocache != 0 ? 
                            bpage->vaddr_nocache : bpage->vaddr),
                            (void *)bpage->datavaddr, bpage->datacount);
                        dmat->bounce_zone->total_bounced++;
                }

USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If 
cpu_dcache_inv_range() is called with an address not starting at the cache 
line what will the cpu_dcache_inv_range() do? Will it skip to the next cache 
line? Or will it completely skip the whole cache sync operation?! In the 
function just above in the file I refer to, "bus_dmamap_sync_buf()", there is 
quite some more code to handle invalidation when the destination address is 
not properly aligned. I'm not an ARM expert. Maybe you can do an experiment 
for me:

Change: bpage->vaddr into (bpage->vaddr & ~arm_dcache_align_mask)
Change: bpage->datacount into (bpage->datacount + (bpage->vaddr & 
arm_dcache_align_mask) + arm_dcache_align_mask - 1) & ~arm_dcache_align_mask;

You don't need any memcpy there, because we own the complete memory page which 
vaddr is a part of!

>
> Ok. So if you use bus_dma(), please use it in correct way.

What has to be changed in busdma_machdep.c for ARM/MIPS so that the problem is 
resolved. I think there are something missing there and not in USB!

--HPS

From stas at FreeBSD.org  Mon Jun 29 12:10:20 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Mon Jun 29 12:10:26 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291337.43635.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291155.13941.hselasky@c2i.net>
	<200906291249.43983.kosmo@semihalf.com>
	<200906291337.43635.hselasky@c2i.net>
Message-ID: <20090629161011.2a657c4b.stas@FreeBSD.org>

On Mon, 29 Jun 2009 13:37:41 +0200
Hans Petter Selasky <hselasky@c2i.net> mentioned:

> USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If 
> cpu_dcache_inv_range() is called with an address not starting at the cache 
> line what will the cpu_dcache_inv_range() do? Will it skip to the next cache 
> line? Or will it completely skip the whole cache sync operation?!

Currently, the address passed to cpu_dcache_inv_range will be rounded up
to the cache line boundary and the whole line will be invalidated if the
range requested is smaller than 16KiB.  Otherwise, the whole cache will
be invalidated.

-- 
Stanislav Sedov
ST4096-RIPE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090629/1db1373a/attachment.pgp
From hselasky at c2i.net  Mon Jun 29 12:15:16 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Jun 29 12:15:29 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <20090629161011.2a657c4b.stas@FreeBSD.org>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291337.43635.hselasky@c2i.net>
	<20090629161011.2a657c4b.stas@FreeBSD.org>
Message-ID: <200906291414.46341.hselasky@c2i.net>

On Monday 29 June 2009 14:10:11 Stanislav Sedov wrote:
> On Mon, 29 Jun 2009 13:37:41 +0200
>
> Hans Petter Selasky <hselasky@c2i.net> mentioned:
> > USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If
> > cpu_dcache_inv_range() is called with an address not starting at the
> > cache line what will the cpu_dcache_inv_range() do? Will it skip to the
> > next cache line? Or will it completely skip the whole cache sync
> > operation?!
>
> Currently, the address passed to cpu_dcache_inv_range will be rounded up
> to the cache line boundary and the whole line will be invalidated if the
> range requested is smaller than 16KiB.  Otherwise, the whole cache will
> be invalidated.

That maybe explains it, because USB will require rounding down the address and 
rounding up the length accordingly, because it uses the 
"BUS_DMA_KEEP_PG_OFFSET" flag.

--HPS
From kosmo at semihalf.com  Mon Jun 29 12:16:15 2009
From: kosmo at semihalf.com (Piotr =?utf-8?q?Zi=C4=99cik?=)
Date: Mon Jun 29 12:16:21 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291337.43635.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291249.43983.kosmo@semihalf.com>
	<200906291337.43635.hselasky@c2i.net>
Message-ID: <200906291416.13749.kosmo@semihalf.com>

Monday 29 June 2009 13:37:41 Hans Petter Selasky napisa?(a):

> > Look into ehci_check_transfer() function
> > (http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294)
> >
> > usb_pc_cpu_invalidate() [bus_dmamap_sync()] is not used in this function
> > correcly. It is not paired with usb_pc_cpu_flush() [opposite
> > bus_dmamap_sync()] as busdma requires (see part of manpage cited above).
> > The same problem is in part of code shown in previous mail.
> >
> > If usb_pc_cpu_invalidate()/usb_pc_cpu_flush() functions had been
> > implemented without using busdma, for example as cpu_*() functions,
> > ehci_check_transfer() would have been 100% correct. In current code
> > busdma requirements are simply not met.
>
> Good point. Unfortunately I cannot pair like you suggest, because then I
> can overwrite values updated by the hardware, if I first read the status
> for example, and the same 32-bits are updated by hardware, before the old
> value is flushed over the new one.. Also I cannot find the word "pair" in
> the busdma manpage? Where is this requirement stated?

Look for bus_dmamap_sync() sync description, last sentence:
<cite>
If read and write operations are not preceded and followed by the
appropriate synchronization operations, behavior is undefined.
</cite>

> I see some things:
>
> You wrote earlier that the COHERENT flag was not set. That means your setup
> is using bounce pages for DMA? Right?

No. On ARM BUS_DMA_COHERENT flag enforces no-cache page mapping.
This is performance killer and should be avoided. In addition space for 
uncached mappings is also limted.

Bounce pages are used if busdma subsystem is not able to directly met 
alignment constrains specified in dma tag. In this case, a bounce page is 
allocated and data is copied (!) to the bounce page. Busdma returns physical 
address of bounce page which mets constraints specified in the dma tag.

When sync operation is preformed and given mapping uses bounce pages,
data is copied between the bounce pages and original location. All cache
operations are performed on bounce pages.

-- 
Best Regards.
Piotr Ziecik
From kosmo at semihalf.com  Mon Jun 29 13:07:33 2009
From: kosmo at semihalf.com (Piotr =?utf-8?q?Zi=C4=99cik?=)
Date: Mon Jun 29 13:07:40 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291337.43635.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291249.43983.kosmo@semihalf.com>
	<200906291337.43635.hselasky@c2i.net>
Message-ID: <200906291507.31594.kosmo@semihalf.com>

Monday 29 June 2009 13:37:41 Hans Petter Selasky napisa?(a):
>                 if (op & BUS_DMASYNC_POSTREAD) {
>                         if (bpage->vaddr_nocache == 0) {
>                                 cpu_dcache_inv_range(bpage->vaddr,
>                                     bpage->datacount);
>                                 cpu_l2cache_inv_range(bpage->vaddr,
>                                     bpage->datacount);
>                         }
>                         bcopy((void *)(bpage->vaddr_nocache != 0 ?
>                             bpage->vaddr_nocache : bpage->vaddr),
>                             (void *)bpage->datavaddr, bpage->datacount);
>                         dmat->bounce_zone->total_bounced++;
>                 }
>
> Change: bpage->vaddr into (bpage->vaddr & ~arm_dcache_align_mask)
> Change: bpage->datacount into (bpage->datacount + (bpage->vaddr &
> arm_dcache_align_mask) + arm_dcache_align_mask - 1) &
> ~arm_dcache_align_mask;

I have checked above changes and I do not observe any changes
is USB behaviour. Problem still exists.

-- 
Best Regards.
Piotr Ziecik
From hselasky at c2i.net  Mon Jun 29 13:17:29 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Jun 29 13:17:37 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906231035.43096.kosmo@semihalf.com>
References: <200906231035.43096.kosmo@semihalf.com>
Message-ID: <200906291516.58725.hselasky@c2i.net>

On Tuesday 23 June 2009 10:35:42 Piotr Zi?cik wrote:
> --- a/sys/dev/usb/usb_busdma.c
> +++ b/sys/dev/usb/usb_busdma.c
> @@ -658,8 +658,7 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc)
>                 /* nothing has been loaded into this page cache! */
>                 return;
>         }
> -       bus_dmamap_sync(pc->tag, pc->map,
> -           BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD);
> +       bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD);
>  }
>
>  /*------------------------------------------------------------------------
>* @@ -672,8 +671,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc)
>                 /* nothing has been loaded into this page cache! */
>                 return;
>         }
> -       bus_dmamap_sync(pc->tag, pc->map,
> -           BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
> +       bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE);
>  }

Hi,

Let's restart the discussion with the initial patch.

You want to change the flags passed to bus_dmamap_sync() so that the 
flush/invalidate mapping gets right. I understand why your patch makes it 
work. That's not the problem.

In "src/sys/arm/arm/busdma_machdep.c" there is a function called 
"_bus_dmamap_sync_bp()". If you look at that function you see that it only 
triggers on the "BUS_DMASYNC_PREWRITE" and "BUS_DMASYNC_POSTREAD" flags. After 
your patching only the PREXXXX flags are used, so if bouce pages are used on 
ARM and x86 and amd64 +++, then only BUS_DMASYNC_PREWRITE will do anything. 
This indicates that your patch is not fully correct.

Grepping through the source code for ARM, I found a line like this:

/*XXX*/ arm9_dcache_wbinv_range,        /* dcache_inv_range     */

which is not correct. If we are only invalidating, then it is not correct to 
do a flush first.

Summed up:

static void
bus_dmamap_sync_buf(void *buf, int len, bus_dmasync_op_t op)
{
        char _tmp_cl[arm_dcache_align], _tmp_clend[arm_dcache_align];

        if ((op & BUS_DMASYNC_PREWRITE) && !(op & BUS_DMASYNC_PREREAD)) {
                cpu_dcache_wb_range((vm_offset_t)buf, len);
                cpu_l2cache_wb_range((vm_offset_t)buf, len);
        }
        if (op & BUS_DMASYNC_PREREAD) {
                if (!(op & BUS_DMASYNC_PREWRITE) &&
                    ((((vm_offset_t)(buf) | len) & arm_dcache_align_mask) == 
0)) {
                        cpu_dcache_inv_range((vm_offset_t)buf, len);
                        cpu_l2cache_inv_range((vm_offset_t)buf, len);
                } else {

Because the USB code specifies both PREREAD and PREWRITE we end up in the 
following case, which is not implemented correctly. The function name 
indicates write back first, then invalidate, but when looking at the 
implementation:

<example>

        arm8_cache_purgeID,             /* idcache_wbinv_all    */
        (void *)arm8_cache_purgeID,     /* idcache_wbinv_range  */

</example>

You see that it only performs purge and no prior flush. This is what needs 
fixing! If semihalf could go through the "arm/arm/cpufunc.c" file and fix 
those flush and invalidate functions then many people would become happy!

Again, it is not a problem in USB firstly, it is a problem in "arm/xxx".

                        cpu_dcache_wbinv_range((vm_offset_t)buf, len);
                        cpu_l2cache_wbinv_range((vm_offset_t)buf, len);
                }
        }
        if (op & BUS_DMASYNC_POSTREAD) {
                if ((vm_offset_t)buf & arm_dcache_align_mask) {
                        memcpy(_tmp_cl, (void *)((vm_offset_t)buf & ~
                            arm_dcache_align_mask),
                            (vm_offset_t)buf & arm_dcache_align_mask);
                }
                if (((vm_offset_t)buf + len) & arm_dcache_align_mask) {
                        memcpy(_tmp_clend, (void *)((vm_offset_t)buf + len),
                            arm_dcache_align - (((vm_offset_t)(buf) + len) &
                           arm_dcache_align_mask));
                }
                cpu_dcache_inv_range((vm_offset_t)buf, len);
                cpu_l2cache_inv_range((vm_offset_t)buf, len);

                if ((vm_offset_t)buf & arm_dcache_align_mask)
                        memcpy((void *)((vm_offset_t)buf &
                            ~arm_dcache_align_mask), _tmp_cl, 
                            (vm_offset_t)buf & arm_dcache_align_mask);
                if (((vm_offset_t)buf + len) & arm_dcache_align_mask)
                        memcpy((void *)((vm_offset_t)buf + len), _tmp_clend,
                            arm_dcache_align - (((vm_offset_t)(buf) + len) &
                           arm_dcache_align_mask));
        }
}

--HPS
From hselasky at c2i.net  Mon Jun 29 13:25:19 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Jun 29 13:25:24 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291416.13749.kosmo@semihalf.com>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291337.43635.hselasky@c2i.net>
	<200906291416.13749.kosmo@semihalf.com>
Message-ID: <200906291424.46954.hselasky@c2i.net>

On Monday 29 June 2009 14:16:13 Piotr Zi?cik wrote:
> Look for bus_dmamap_sync() sync description, last sentence:
> <cite>
> If read and write operations are not preceded and followed by the
> appropriate synchronization operations, behavior is undefined.
> </cite>

I don't think this is a problem. I do flush read buffers before using them, 
and invalidate them afterwards. Write buffers only get flushed once.

--HPS
From stas at FreeBSD.org  Mon Jun 29 13:34:45 2009
From: stas at FreeBSD.org (Stanislav Sedov)
Date: Mon Jun 29 13:34:51 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291414.46341.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291337.43635.hselasky@c2i.net>
	<20090629161011.2a657c4b.stas@FreeBSD.org>
	<200906291414.46341.hselasky@c2i.net>
Message-ID: <20090629173438.75953a18.stas@FreeBSD.org>

On Mon, 29 Jun 2009 14:14:45 +0200
Hans Petter Selasky <hselasky@c2i.net> mentioned:

> On Monday 29 June 2009 14:10:11 Stanislav Sedov wrote:
> > On Mon, 29 Jun 2009 13:37:41 +0200
> >
> > Hans Petter Selasky <hselasky@c2i.net> mentioned:
> > > USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If
> > > cpu_dcache_inv_range() is called with an address not starting at the
> > > cache line what will the cpu_dcache_inv_range() do? Will it skip to the
> > > next cache line? Or will it completely skip the whole cache sync
> > > operation?!
> >
> > Currently, the address passed to cpu_dcache_inv_range will be rounded up
> > to the cache line boundary and the whole line will be invalidated if the
> > range requested is smaller than 16KiB.  Otherwise, the whole cache will
> > be invalidated.
> 
> That maybe explains it, because USB will require rounding down the address and 
> rounding up the length accordingly, because it uses the 
> "BUS_DMA_KEEP_PG_OFFSET" flag.
>

My apologies, it appears that my wording in previous email was incorrect.  The
current cpu_dcache_inv_range ARM implementation obviously rounds down the
address passed to the cache line boundary and then invalidates all the lines
affected.

-- 
Stanislav Sedov
ST4096-RIPE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20090629/58420c24/attachment.pgp
From tinguely at casselton.net  Mon Jun 29 15:06:41 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Mon Jun 29 15:06:48 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291337.43635.hselasky@c2i.net>
Message-ID: <200906291506.n5TF6boc010668@casselton.net>

>
>  What has to be changed in busdma_machdep.c for ARM/MIPS so that the problem=
>   is=20
>  resolved. I think there are something missing there and not in USB!
>
>  =2D-HPS

I unsuccessfully looked for the start of this thread. Which version of FreeBSD
are you using?

--Mark T.
From hselasky at c2i.net  Mon Jun 29 15:09:28 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Mon Jun 29 15:09:34 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291506.n5TF6boc010668@casselton.net>
References: <200906291506.n5TF6boc010668@casselton.net>
Message-ID: <200906291708.56737.hselasky@c2i.net>

On Monday 29 June 2009 17:06:37 Mark Tinguely wrote:
> >  What has to be changed in busdma_machdep.c for ARM/MIPS so that the
> > problem= is=20
> >  resolved. I think there are something missing there and not in USB!
> >
> >  =2D-HPS
>
> I unsuccessfully looked for the start of this thread. Which version of
> FreeBSD are you using?

This thread is all about FreeBSD-8-current.

--HPS

From andrew at fubar.geek.nz  Mon Jun 29 20:43:11 2009
From: andrew at fubar.geek.nz (Andrew Turner)
Date: Mon Jun 29 20:43:18 2009
Subject: Support for the Friendly Arm (mini 2440) development board
In-Reply-To: <793595.43066.qm@web35704.mail.mud.yahoo.com>
References: <793595.43066.qm@web35704.mail.mud.yahoo.com>
Message-ID: <20090630084310.02ea492f@fubar.geek.nz>

On Mon, 29 Jun 2009 03:56:16 -0700 (PDT)
Donn Miller <hackr_d@yahoo.com> wrote:
> Were you able to get it to boot FreeBSD from a smartmedia card?  That
> would be another area that possibly needs working on as well.
> 
I've been loading the kernel from the network then getting the root
file system from a md device in the kernel. There is currently a limited
number of devices on the board that are supported by FreeBSD. The
smartmedia is one of them along with the PHY (DM9000). USB might be
working however there are dma issues (see other thread).

Andrew
From kosmo at semihalf.com  Tue Jun 30 08:37:52 2009
From: kosmo at semihalf.com (Piotr =?iso-8859-2?q?Zi=EAcik?=)
Date: Tue Jun 30 08:38:05 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906291516.58725.hselasky@c2i.net>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291516.58725.hselasky@c2i.net>
Message-ID: <200906301037.49367.kosmo@semihalf.com>

Monday 29 June 2009 15:16:56 Hans Petter Selasky napisa?(a):
>
> You want to change the flags passed to bus_dmamap_sync() so that the
> flush/invalidate mapping gets right. I understand why your patch makes it
> work. That's not the problem.
>
> In "src/sys/arm/arm/busdma_machdep.c" there is a function called
> "_bus_dmamap_sync_bp()". If you look at that function you see that it only
> triggers on the "BUS_DMASYNC_PREWRITE" and "BUS_DMASYNC_POSTREAD" flags.
> After your patching only the PREXXXX flags are used, so if bouce pages are
> used on ARM and x86 and amd64 +++, then only BUS_DMASYNC_PREWRITE will do
> anything. This indicates that your patch is not fully correct.

That is true. I have missed "bounce page" case. I can change flags passed to 
bus_dmamap_sync() to fix this on ARM, but this will break MIPS.

This clearly shows the problem - using side effect of busdma to manage CPU 
cache. Current USB implementation relies of this side effect assuming that 
bus_dmamap_sync() with given flags will do cpu cache flush/invalidation.
This is not true even on i386 !

This thread is not about my patch. It is only a fast and dirty hack
making USB working on platforms without hardware cache coherency
and showing the problem. I see two proper solutions:

1. Implement usb_pc_cpu_invalidate() / usb_pc_cpu_flush() with
cpu_*() functions realizing requested operation.

2. Using busdma in proper way:
        [... prepare data to transfer ...]
        bus_dmamap_sync(..., PREREAD | PREWRITE);
        [... do transfer ...]
        bus_dmamap_sync(..., POSTREAD | POSTWRITE);
        [... check results ...]
as manpage says:
	<cite>
	If read and write operations are not preceded and followed by the
	appropriate synchronization operations, behavior is undefined.
	</cite>
Requirement cited above is currently not met in USB stack. Funtion
shown in http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294
is just an example of improper usage of bus_dmamap_sync(), which is hidden 
under usb_pc_cpu_invalidate().

This thread started from my question about general usage of usb_pc_cpu_*() 
functions. So I am asking once again - why these functions relies on side 
effect of busdma instead of simply doing cache flush/invalidation through 
cpu_*() functions ?

> Grepping through the source code for ARM, I found a line like this:
> (...)
> You see that it only performs purge and no prior flush. This is what needs
> fixing! If semihalf could go through the "arm/arm/cpufunc.c" file and fix
> those flush and invalidate functions then many people would become happy!

My developement platform is sheeva. CPU functions for this platform are 
implemented correctly.

> Again, it is not a problem in USB firstly, it is a problem in "arm/xxx".

You are suggesting that the problem is in ARM busdma (and in MIPS busdma, as 
on this platform USB also does not work). Could you give me example of 
platform _without_ hardware coherency where new USB stack simply works ?

-- 
Best regards.
Piotr Ziecik
From hselasky at c2i.net  Tue Jun 30 09:28:57 2009
From: hselasky at c2i.net (Hans Petter Selasky)
Date: Tue Jun 30 09:29:05 2009
Subject: CPU Cache and busdma usage in USB
In-Reply-To: <200906301037.49367.kosmo@semihalf.com>
References: <200906231035.43096.kosmo@semihalf.com>
	<200906291516.58725.hselasky@c2i.net>
	<200906301037.49367.kosmo@semihalf.com>
Message-ID: <200906301128.26046.hselasky@c2i.net>

On Tuesday 30 June 2009 10:37:48 Piotr Zi?cik wrote:
> Monday 29 June 2009 15:16:56 Hans Petter Selasky napisa?(a):
> > You want to change the flags passed to bus_dmamap_sync() so that the
> > flush/invalidate mapping gets right. I understand why your patch makes it
> > work. That's not the problem.
> >
> > In "src/sys/arm/arm/busdma_machdep.c" there is a function called
> > "_bus_dmamap_sync_bp()". If you look at that function you see that it
> > only triggers on the "BUS_DMASYNC_PREWRITE" and "BUS_DMASYNC_POSTREAD"
> > flags. After your patching only the PREXXXX flags are used, so if bouce
> > pages are used on ARM and x86 and amd64 +++, then only
> > BUS_DMASYNC_PREWRITE will do anything. This indicates that your patch is
> > not fully correct.
>

Hi,

> That is true. I have missed "bounce page" case. I can change flags passed
> to bus_dmamap_sync() to fix this on ARM, but this will break MIPS.

Right, so there is inconsistency among the platforms in how the BUSDMA is 
implemented, which should be fixed.

> This clearly shows the problem - using side effect of busdma to manage CPU
> cache. Current USB implementation relies of this side effect assuming that
> bus_dmamap_sync() with given flags will do cpu cache flush/invalidation.
> This is not true even on i386 !

i386 handles this differently.

> This thread is not about my patch. It is only a fast and dirty hack
> making USB working on platforms without hardware cache coherency
> and showing the problem. I see two proper solutions:

Ok.

>
> 1. Implement usb_pc_cpu_invalidate() / usb_pc_cpu_flush() with
> cpu_*() functions realizing requested operation.
>
> 2. Using busdma in proper way:
>         [... prepare data to transfer ...]
>         bus_dmamap_sync(..., PREREAD | PREWRITE);
>         [... do transfer ...]
>         bus_dmamap_sync(..., POSTREAD | POSTWRITE);
>         [... check results ...]
> as manpage says:
> 	<cite>
> 	If read and write operations are not preceded and followed by the
> 	appropriate synchronization operations, behavior is undefined.
> 	</cite>
> Requirement cited above is currently not met in USB stack. Funtion
> shown in http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294
> is just an example of improper usage of bus_dmamap_sync(), which is hidden
> under usb_pc_cpu_invalidate().

I'm not violating any rules in busdma. The busdma manual is silent about doing 
multiple sync operations of the same kind in a row. If the sheeva hardware you 
are using works differently, you have to fix it.

>
> This thread started from my question about general usage of usb_pc_cpu_*()
> functions. So I am asking once again - why these functions relies on side
> effect of busdma instead of simply doing cache flush/invalidation through
> cpu_*() functions ?

Because busdma is the interface for doing these kinds of operations and not 
cpu_xxx(). The DMA memory is allocated using busdma and loaded using busdma, 
and cpu_xxx() is not a part of the busdma interface.

>
> > Grepping through the source code for ARM, I found a line like this:
> > (...)
> > You see that it only performs purge and no prior flush. This is what
> > needs fixing! If semihalf could go through the "arm/arm/cpufunc.c" file
> > and fix those flush and invalidate functions then many people would
> > become happy!
>
> My developement platform is sheeva. CPU functions for this platform are
> implemented correctly.
>
> > Again, it is not a problem in USB firstly, it is a problem in "arm/xxx".
>
> You are suggesting that the problem is in ARM busdma (and in MIPS busdma,
> as on this platform USB also does not work). Could you give me example of
> platform _without_ hardware coherency where new USB stack simply works ?

If I find time later today I will fix the cache sync operations for AT91RM9200 
which has a built in OHCI, which has been working fine with my new USB stack.

Can you please add some prints to the "bus_dmamap_sync_buf()" code on ARM, and 
verify which cases the CPU is entering, without your patch and with your 
patch. From my analysis your patch will just change the execution path:

With your patch it calls:

                cpu_dcache_wb_range((vm_offset_t)buf, len);
                cpu_l2cache_wb_range((vm_offset_t)buf, len);

Without your patch it calls:

                        cpu_dcache_wbinv_range((vm_offset_t)buf, len);
                        cpu_l2cache_wbinv_range((vm_offset_t)buf, len);

In my view these execution paths are equivalent with regard to clean or cache 
flush. They should both perform a cache flush, which is what the USB code 
wants to do, but obviously the latter case is not implemented correctly, most 
likely because it doesn't flush the buffer like expected!

Try adding:

                cpu_dcache_wb_range((vm_offset_t)buf, len);
                cpu_l2cache_wb_range((vm_offset_t)buf, len);

Before:

                        cpu_dcache_wbinv_range((vm_offset_t)buf, len);
                        cpu_l2cache_wbinv_range((vm_offset_t)buf, len);

In: sys/arm/arm/busdma_machdep.c

Yours,
--HPS