From sam at freebsd.org  Sun Feb  1 19:27:52 2009
From: sam at freebsd.org (Sam Leffler)
Date: Sun Feb  1 19:27:58 2009
Subject: NFS on ARM/IXP435
In-Reply-To: <4983B5D2.9040500@clearpathnet.com>
References: <49838270.7090301@clearpathnet.com> <4983B041.4050200@freebsd.org>
	<4983B5D2.9040500@clearpathnet.com>
Message-ID: <49866832.1080601@freebsd.org>

Alex Vinogradovs wrote:
> Sam Leffler wrote:
>>
>> I've had no problems using nfs-root, cf-root, or mounting nfs 
>> filesystems after boot.  The only thing to beware is to not use NPE-A 
>> as it doesn't work.
>>
>>    Sam
>>
>
> Yeah, my situation is kind of odd... I've got operational network, but 
> whether it is during startup
> (via fstab), or manually later on, mount_nfs just hangs, while / is 
> mounted via NFS by kernel. But
> since there is no proc/truss, I'm clueless how to see what is it doing...

Not sure why you cannot configure proc/truss, use ktrace, or something 
else to debug the issue.

>
> Indeed I've noticed I've only got one interface out of two, so you've 
> answered my question ahead of time :D
>
> just in case, here are my boot messages:
>
> 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 8.0-CURRENT #6: Fri Jan 30 13:47:27 PST 2009
>    alexv@alexv:/usr/src.2/sys/arm/compile/flex100
> CPU: IXP435 rev 1 (ARMv5TE) (XScale core)
>  DC enabled IC enabled WB enabled LABT branch prediction enabled
>  32KB/32B 32-way Instruction cache
>  32KB/32B 32-way write-back-locking Data cache
> real memory  = 134217728 (128 MB)
> avail memory = 125263872 (119 MB)
> ixp0: <Intel IXP4XX> on motherboard
> ixp0: 37fff<RCOMP,USB,HASH,AES,DES,HDLC,AAL,HSS,UTOPIA,ETH0,ETH1,PCI>
> ixpclk0: <IXP4XX Timer> on ixp0
> ixpiic0: <IXP4XX GPIO-Based I2C Interface> on ixp0
> iicbb0: <I2C bit-banging driver> on ixpiic0
> iicbus0: <Philips I2C bus> on iicbb0 master-only
> iic0: <I2C generic I/O> on iicbus0
> iicbus0: <unknown card> at addr 0x5a
> ad74180: <Analog Devices AD7418 ADC> at addr 0x50 on iicbus0
> ds16720: <Dallas Semiconductor DS1672 RTC> at addr 0xd0 on iicbus0
> ixpwdog0: <IXP4XX Watchdog Timer> on ixp0
> uart0: <Non-standard ns8250 class UART with FIFOs> on ixp0
> uart0: [FILTER]
> uart0: console (115200,n,8,1)
> ixpqmgr0: <IXP4XX Q-Manager> on ixp0
> ixpqmgr0: [ITHREAD]
> ixpqmgr0: [ITHREAD]
> npe0: <IXP NPE-C> on ixp0
> npe0: [ITHREAD]
> npe0: MAC at 0xc800a000
> npe0: MII at 0xc800a000
> npe0: load fw image IXP425.NPE-C Func 0x5 Rev 2.1
> miibus0: <MII bus> on npe0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> npe0: Ethernet address: 00:03:47:df:32:a8
> ata_avila0: <Gateworks Cambria IDE/CF Controller> on ixp0
> ata_avila0: [ITHREAD]
> ata0: <ATA channel 0> on ata_avila0
> ata0: [ITHREAD]
> ehci0: <IXP4XX Integrated USB 2.0 controller> on ixp0
> ehci0: [GIANT-LOCKED]
> ehci0: [ITHREAD]
> usb0: set host controller mode
> usb0: set big-endian mode
> usb0: EHCI version 1.0
> usb0: stop timeout
> usb0: set host controller mode
> usb0: set big-endian mode
> usb0 on ehci0
> usb0: USB revision 2.0
> uhub0: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb0
> uhub0: 1 port with 1 removable, self powered
> ehci1: <IXP4XX Integrated USB 2.0 controller> on ixp0
> ehci1: [GIANT-LOCKED]
> ehci1: [ITHREAD]
> usb1: set host controller mode
> usb1: set big-endian mode
> usb1: EHCI version 1.0
> usb1: stop timeout
> usb1: set host controller mode
> usb1: set big-endian mode
> usb1 on ehci1
> usb1: USB revision 2.0
> uhub1: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb1
> uhub1: 1 port with 1 removable, self powered
> ixpclk0: [FILTER]
> Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000
> Timecounters tick every 10.000 msec
> bootpc_init: wired to interface 'npe0'
> Sending DHCP Discover packet from interface npe0 (00:03:47:df:32:a8)
> Received DHCP Offer packet on npe0 from 10.1.16.109 (accepted) (no 
> root path)
> Received DHCP Offer packet on npe0 from 10.1.8.100 via 10.1.16.2 
> (ignored) (no root path)
> Received DHCP Offer packet on npe0 from 10.1.8.100 via 10.1.16.3 
> (ignored) (no root path)
> Sending DHCP Request packet from interface npe0 (00:03:47:df:32:a8)
> Received DHCP Ack packet on npe0 from 10.1.16.109 (accepted) (got root 
> path)
> npe0 at 10.1.16.114 server 10.1.16.109 boot file /tftpboot/flex100
> subnet mask 255.255.255.0 router 10.1.16.1 rootfs 10.1.16.109:/armroot 
> hostname flex100
> Adjusted interface npe0
> Trying to mount root from nfs:
> NFS ROOT: 10.1.16.109:/armroot
>
> 10.1.16.109:/armroot on / (nfs, read-only)
> devfs on /dev (devfs, local)
> /dev/md0 on /var (ufs, local)
> /dev/md1 on /tmp (ufs, local)
>
> npe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> 1500
>    ether 00:03:47:df:32:a8
>    inet 10.1.16.114 netmask 0xffffff00 broadcast 10.1.16.255
>    media: Ethernet autoselect (100baseTX <full-duplex>)
>    status: active

 From a build of today:

cambria# mount
10.0.0.251:/data/freebsd/roots/gateworks on / (nfs)
devfs on /dev (devfs, local)
/dev/md0 on /etc (ufs, local)
tubby:/data on /data (nfs)
cambria# uname -a
FreeBSD cambria 8.0-CURRENT FreeBSD 8.0-CURRENT #41 r187990:187992M: Sun 
Feb  1 19:23:36 PST 2009     
sam@trouble.errno.com:/usr/obj/arm/usr/sam/base/user/sam/wifi/sys/CAMBRIA  
arm
cambria# mount
10.0.0.251:/data/freebsd/roots/gateworks on / (nfs)
devfs on /dev (devfs, local)
/dev/md0 on /etc (ufs, local)
tubby:/data on /data (nfs)
cambria# ifconfig
npe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:d0:12:00:cd:5f
        inet 10.0.0.9 netmask 0xffffff00 broadcast 10.0.0.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet 127.0.0.1 netmask 0xff000000


From tinderbox at freebsd.org  Sun Feb  1 21:21:54 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sun Feb  1 21:22:00 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090202044044.482EF7302F@freebsd-current.sentex.ca>

TB --- 2009-02-02 03:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-02 03:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-02 03:40:00 - cleaning the object tree
TB --- 2009-02-02 03:40:34 - cvsupping the source tree
TB --- 2009-02-02 03:40:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-02 03:40:44 - building world
TB --- 2009-02-02 03:40:44 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-02 03:40:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-02 03:40:44 - TARGET=arm
TB --- 2009-02-02 03:40:44 - TARGET_ARCH=arm
TB --- 2009-02-02 03:40:44 - TZ=UTC
TB --- 2009-02-02 03:40:44 - __MAKE_CONF=/dev/null
TB --- 2009-02-02 03:40:44 - cd /src
TB --- 2009-02-02 03:40:44 - /usr/bin/make -B buildworld
>>> World build started on Mon Feb  2 03:40:47 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  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/for.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/hash_tables.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/job.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/lst.c
cc -O -pipe  -I/src/usr.bin/make -DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/make/main.c
/src/usr.bin/make/main.c:375:1: error: "OPTFLAGS" redefined
/src/usr.bin/make/main.c:374:1: error: this is the location of the previous definition
*** Error code 1

Stop in /src/usr.bin/make.
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-02 04:40:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-02 04:40:44 - ERROR: failed to build world
TB --- 2009-02-02 04:40:44 - 2834.77 user 344.06 system 3643.30 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From avinogradovs at clearpathnet.com  Mon Feb  2 10:19:52 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Mon Feb  2 10:19:58 2009
Subject: NFS on ARM/IXP435
In-Reply-To: <49866832.1080601@freebsd.org>
References: <49838270.7090301@clearpathnet.com> <4983B041.4050200@freebsd.org>
	<4983B5D2.9040500@clearpathnet.com> <49866832.1080601@freebsd.org>
Message-ID: <49873983.3070709@clearpathnet.com>

Yes, my mistake - got proc working. truss doesn't seem to be supported 
on ARM though... Will
look into ktrace, thanks.

Sam Leffler wrote:
>
> Not sure why you cannot configure proc/truss, use ktrace, or something 
> else to debug the issue.
>

From avinogradovs at clearpathnet.com  Mon Feb  2 13:35:31 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Mon Feb  2 13:35:37 2009
Subject: NFS on ARM/IXP435
In-Reply-To: <49866832.1080601@freebsd.org>
References: <49838270.7090301@clearpathnet.com> <4983B041.4050200@freebsd.org>
	<4983B5D2.9040500@clearpathnet.com> <49866832.1080601@freebsd.org>
Message-ID: <4987675D.9050900@clearpathnet.com>

Well, ktrace didn't help me much... Here is the output of kdump :

   764 ktrace   RET   ktrace 0
   764 ktrace   CALL  execve(0xbfffe7bc,0xbfffecfc,0xbfffed0c)
   764 ktrace   NAMI  "/sbin/mount_nfs"
   764 ktrace   NAMI  "/libexec/ld-elf.so.1"
   764 mount_nfs RET   execve 0
   764 mount_nfs CALL  __sysctl(0xbfffeaf0,0x2,0x2004ad54,0xbfffeaec,0,0)
   764 mount_nfs RET   __sysctl 0
   764 mount_nfs CALL  __sysctl(0xbfffea78,0x2,0xbfffea74,0xbfffea80,0,0)
   764 mount_nfs RET   __sysctl 0
   764 mount_nfs CALL  
mmap(0,0x8000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0)
   764 mount_nfs RET   mmap 537190400/0x2004e000
   764 mount_nfs CALL  issetugid
   764 mount_nfs RET   issetugid 0
   764 mount_nfs CALL  open(0x2003defc,O_RDONLY,<unused>0x1b6)
   764 mount_nfs NAMI  "/etc/libmap.conf"
   764 mount_nfs RET   open -1 errno 2 No such file or directory
   764 mount_nfs CALL  open(0x2003cfd0,O_RDONLY,<unused>0x14c)
   764 mount_nfs NAMI  "/var/run/ld-elf.so.hints"
   764 mount_nfs RET   open 3
   764 mount_nfs CALL  read(0x3,0xbfffe838,0x80)
   764 mount_nfs GIO   fd 3 read 128 bytes
       0x0000 746e 6845 0000 0001 0000 0080 0000 001e  |tnhE............|
       0x0010 0000 0000 0000 001d 0000 0000 0000 0000  |................|
       0x0020 0000 0000 0000 0000 0000 0000 0000 0000  |................|
       0x0030 0000 0000 0000 0000 0000 0000 0000 0000  |................|
       0x0040 0000 0000 0000 0000 0000 0000 0000 0000  |................|
       0x0050 0000 0000 0000 0000 0000 0000 0000 0000  |................|
       0x0060 0000 0000 0000 0000 0000 0000 0000 0000  |................|
       0x0070 0000 0000 0000 0000 0000 0000 0000 0000  |................|
   764 mount_nfs RET   read 128/0x80
   764 mount_nfs CALL  lseek(0x3,0,<invalid=128>,0)
   764 mount_nfs RET   lseek 0
   764 mount_nfs CALL  read(0x3,0x20052000,0x1e)
   764 mount_nfs GIO   fd 3 read 30 bytes
       "/lib:/usr/lib:/usr/lib/compat\0"
   764 mount_nfs RET   read 30/0x1e
   764 mount_nfs CALL  close(0x3)
   764 mount_nfs RET   close 0
   764 mount_nfs CALL  access(0x20053000,F_OK)
   764 mount_nfs NAMI  "/lib/libc.so.7"
   764 mount_nfs RET   access 0
   764 mount_nfs CALL  open(0x2004f020,O_RDONLY,<unused>0x2004acb8)
   764 mount_nfs NAMI  "/lib/libc.so.7"
   764 mount_nfs RET   open 3
   764 mount_nfs CALL  fstat(0x3,0xbfffeab8)
Bus error (core dumped)

And top shows that mount_nfs is stuck on RPC stuff :

  764 root          1   4    0  3436K  1148K rpccon   0:03  0.00% mount_nfs

I've tried compiling strace from ports, but it appeared to be supported 
on i386 only.

Alex.

Sam Leffler wrote:
>
> Not sure why you cannot configure proc/truss, use ktrace, or something 
> else to debug the issue.
>

From avinogradovs at clearpathnet.com  Mon Feb  2 14:01:43 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Mon Feb  2 14:01:50 2009
Subject: USB/UFS on ARM/IXP435
Message-ID: <49876D7C.4040003@clearpathnet.com>

Guys,

Another observation: UFS systems created on USB device on i386 are not 
recognized on
ARM, and vice versa. I guess that's something to do with byte ordering. 
I've tried removing
USB_EHCI_BIG_ENDIAN_DESC in kernel, but that would just render USB unusable.


Best regards,
Alex Vinogradovs
From avinogradovs at clearpathnet.com  Mon Feb  2 14:05:46 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Mon Feb  2 14:05:52 2009
Subject: USB/UFS on ARM/IXP435
In-Reply-To: <49876D7C.4040003@clearpathnet.com>
References: <49876D7C.4040003@clearpathnet.com>
Message-ID: <49876E70.3020907@clearpathnet.com>

Actually never mind, I think that's because of how UFS structures are 
written :)


Alex.


Alex Vinogradovs wrote:
> Guys,
>
> Another observation: UFS systems created on USB device on i386 are not 
> recognized on
> ARM, and vice versa. I guess that's something to do with byte 
> ordering. I've tried removing
> USB_EHCI_BIG_ENDIAN_DESC in kernel, but that would just render USB 
> unusable.
>
>
> Best regards,
> Alex Vinogradovs
> _______________________________________________
> 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"

From sam at freebsd.org  Mon Feb  2 14:18:05 2009
From: sam at freebsd.org (Sam Leffler)
Date: Mon Feb  2 14:18:11 2009
Subject: USB/UFS on ARM/IXP435
In-Reply-To: <49876E70.3020907@clearpathnet.com>
References: <49876D7C.4040003@clearpathnet.com>
	<49876E70.3020907@clearpathnet.com>
Message-ID: <49877119.20300@freebsd.org>

Correct.  I use makefs to image my CF parts.  We've discussed adding 
bi-endian support to the kernel but it's not been high priority.

    Sam

Alex Vinogradovs wrote:
> Actually never mind, I think that's because of how UFS structures are 
> written :)
>
>
> Alex.
>
>
> Alex Vinogradovs wrote:
>> Guys,
>>
>> Another observation: UFS systems created on USB device on i386 are 
>> not recognized on
>> ARM, and vice versa. I guess that's something to do with byte 
>> ordering. I've tried removing
>> USB_EHCI_BIG_ENDIAN_DESC in kernel, but that would just render USB 
>> unusable.
>>
>>
>> Best regards,
>> Alex Vinogradovs
>> _______________________________________________
>> 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"
>
> _______________________________________________
> 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"
>
>

From imp at bsdimp.com  Mon Feb  2 14:24:05 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon Feb  2 14:24:11 2009
Subject: USB/UFS on ARM/IXP435
In-Reply-To: <49876D7C.4040003@clearpathnet.com>
References: <49876D7C.4040003@clearpathnet.com>
Message-ID: <20090202.152357.168011178.imp@bsdimp.com>

In message: <49876D7C.4040003@clearpathnet.com>
            Alex Vinogradovs <avinogradovs@clearpathnet.com> writes:
: Guys,
: 
: Another observation: UFS systems created on USB device on i386 are not 
: recognized on
: ARM, and vice versa. I guess that's something to do with byte ordering. 
: I've tried removing
: USB_EHCI_BIG_ENDIAN_DESC in kernel, but that would just render USB unusable.

That's different.

We need to have bi-endian ufs support from NetBSD...

Warner
From avinogradovs at clearpathnet.com  Mon Feb  2 14:25:22 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Mon Feb  2 14:25:28 2009
Subject: USB/UFS on ARM/IXP435
In-Reply-To: <20090202.152357.168011178.imp@bsdimp.com>
References: <49876D7C.4040003@clearpathnet.com>
	<20090202.152357.168011178.imp@bsdimp.com>
Message-ID: <49877302.70806@clearpathnet.com>

Yeah, would be nice to specify it as a mount option... even with performance
penalty.

Alex.

M. Warner Losh wrote:
> In message: <49876D7C.4040003@clearpathnet.com>
>             Alex Vinogradovs <avinogradovs@clearpathnet.com> writes:
> : Guys,
> : 
> : Another observation: UFS systems created on USB device on i386 are not 
> : recognized on
> : ARM, and vice versa. I guess that's something to do with byte ordering. 
> : I've tried removing
> : USB_EHCI_BIG_ENDIAN_DESC in kernel, but that would just render USB unusable.
>
> That's different.
>
> We need to have bi-endian ufs support from NetBSD...
>
> Warner
>   

From tinderbox at freebsd.org  Tue Feb  3 12:14:46 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb  3 12:14:53 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090203201441.7C9A57302F@freebsd-current.sentex.ca>

TB --- 2009-02-03 20:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-03 20:00:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-03 20:00:00 - cleaning the object tree
TB --- 2009-02-03 20:00:32 - cvsupping the source tree
TB --- 2009-02-03 20:00:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-03 20:00:40 - building world
TB --- 2009-02-03 20:00:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-03 20:00:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-03 20:00:40 - TARGET=arm
TB --- 2009-02-03 20:00:40 - TARGET_ARCH=arm
TB --- 2009-02-03 20:00:40 - TZ=UTC
TB --- 2009-02-03 20:00:40 - __MAKE_CONF=/dev/null
TB --- 2009-02-03 20:00:40 - cd /src
TB --- 2009-02-03 20:00:40 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  3 20:00:42 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/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/bcmp.c
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/arm/string/bcopy.S
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/arm/string/bzero.S
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/arm/string/ffs.S
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/index.c
cc -O -pipe  -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
/src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
/src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
*** Error code 1

Stop in /src/lib/libc.
*** 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-02-03 20:14:40 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-03 20:14:40 - ERROR: failed to build world
TB --- 2009-02-03 20:14:40 - 650.20 user 65.42 system 879.97 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From danger at FreeBSD.org  Tue Feb  3 12:47:26 2009
From: danger at FreeBSD.org (Daniel Gerzo)
Date: Tue Feb  3 12:47:32 2009
Subject: [head tinderbox] failure on arm/arm
In-Reply-To: <20090203201441.7C9A57302F@freebsd-current.sentex.ca>
References: <20090203201441.7C9A57302F@freebsd-current.sentex.ca>
Message-ID: <1924472521.20090203212920@rulez.sk>

Hello,

Tuesday, February 3, 2009, 9:14:41 PM, you wrote:

> TB --- 2009-02-03 20:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca

> -Wno-pointer-sign -c /src/lib/libc/string/memchr.c
> /src/lib/libc/string/memchr.c:43: error: conflicting types for 'memchr'
> /src/lib/libc/../../include/string.h:61: error: previous declaration of 'memchr' was here
> *** Error code 1

My fault, we are working with Warner on fix. Should be committed soon.

-- 
Best regards,
 Daniel                            mailto:danger@FreeBSD.org

From thompsa at FreeBSD.org  Tue Feb  3 15:30:34 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Tue Feb  3 15:30:40 2009
Subject: busdma problem
In-Reply-To: <20090130220714.GA10743@citylink.fud.org.nz>
References: <20090130072649.GF73709@citylink.fud.org.nz>
	<49833653.60509@freebsd.org>
	<20090130173147.GC2160@citylink.fud.org.nz>
	<20090130220714.GA10743@citylink.fud.org.nz>
Message-ID: <20090203233028.GA68871@citylink.fud.org.nz>

On Fri, Jan 30, 2009 at 02:07:14PM -0800, Andrew Thompson wrote:
> On Fri, Jan 30, 2009 at 09:31:47AM -0800, Andrew Thompson wrote:
> > >> I am having an issue with busdma when bounce buffers are used. I have
> > >> patched _bus_dmamap_sync_bp() to print out the details when a bounce
> > >> happens and also print the driver buffer before and after.
> > >> 
> > >> During normal dma everything is fine,
> > >> 
> > >> Before: 0xc7c1ab40 data=c1:4b:a4:80:c0:5d:ed:78:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02:
> > >> [...do dma...]
> > >> After:  0xc7c1ab40 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00:
> > >> 
> > >> The buffer 2c:03:4e:00:... is the correct response from the hardware.
> > >> When a bounce buffer is used I see the correct data come in and be
> > >> bcopy'd to my memory region but it is not visible when read later.
> > >> 
> > >> Before: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02:
> > >> dma bounced 0x1271000 -> 0xc7c29b40 len=193 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00:
> > >> After:  0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02:
> > >> 
> > >> 
> > >> This is on an xscale ixp425 with 128m memory, the PCI dma tag is limited
> > >> to 64m.
> > >>   
> > > What device is involved?  Is this on HEAD?
> > 
> > This is usb/ehci. The specific function I am looking at is
> > usbd_get_string() in usbdi.c, it does a usb request to fill
> > usb_string_descriptor_t that is a stack variable.
> 
> As suggested by Sam, this works properly when the buffer is malloc'd
> instead of taken from the stack. So is this now a bug or a feature??

As a test I removed the checking of KENTER_CACHE in
arm/arm/pmap.c:pmap_kenter_internal() so all memory is uncached and now
dma bounces to a stack variable work.

busdma remaps the address nocache into vaddr_nocache pointer and uses
that for the bcopy, obviously arm_remap_nocache() is not working
correctly.

Andrew
From tinguely at casselton.net  Tue Feb  3 16:09:59 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Tue Feb  3 16:10:11 2009
Subject: busdma problem
In-Reply-To: <20090203233028.GA68871@citylink.fud.org.nz>
Message-ID: <200902040009.n1409v7K033380@casselton.net>

>  On Fri, Jan 30, 2009 at 02:07:14PM -0800, Andrew Thompson wrote:
>  > On Fri, Jan 30, 2009 at 09:31:47AM -0800, Andrew Thompson wrote:
>  > > >> I am having an issue with busdma when bounce buffers are used. I have
>  > > >> patched _bus_dmamap_sync_bp() to print out the details when a bounce
>  > > >> happens and also print the driver buffer before and after.
>  > > >> 
>  > > >> During normal dma everything is fine,

	[Deleted items]

>  > As suggested by Sam, this works properly when the buffer is malloc'd
>  > instead of taken from the stack. So is this now a bug or a feature??
>
>  As a test I removed the checking of KENTER_CACHE in
>  arm/arm/pmap.c:pmap_kenter_internal() so all memory is uncached and now
>  dma bounces to a stack variable work.
>
>  busdma remaps the address nocache into vaddr_nocache pointer and uses
>  that for the bcopy, obviously arm_remap_nocache() is not working
>  correctly.
>
>  Andrew

I suspected this was another occurrance of the same cache problem that
has been mentioned starting about 3 weeks ago. I even was going to ask
you if it was using arm_remap_nocache().

I have a new concept patch for the kernel caching issue at:

	http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff

I am still waiting for a drive to build a -current machine. I will also
look at any other caching ideas that others have.

--Mark Tinguely.

From thompsa at FreeBSD.org  Tue Feb  3 18:00:14 2009
From: thompsa at FreeBSD.org (Andrew Thompson)
Date: Tue Feb  3 18:00:21 2009
Subject: busdma problem
In-Reply-To: <200902040009.n1409v7K033380@casselton.net>
References: <20090203233028.GA68871@citylink.fud.org.nz>
	<200902040009.n1409v7K033380@casselton.net>
Message-ID: <20090204015958.GA71913@citylink.fud.org.nz>

On Tue, Feb 03, 2009 at 06:09:57PM -0600, Mark Tinguely wrote:
> >  On Fri, Jan 30, 2009 at 02:07:14PM -0800, Andrew Thompson wrote:
> >  As a test I removed the checking of KENTER_CACHE in
> >  arm/arm/pmap.c:pmap_kenter_internal() so all memory is uncached and now
> >  dma bounces to a stack variable work.
> >
> >  busdma remaps the address nocache into vaddr_nocache pointer and uses
> >  that for the bcopy, obviously arm_remap_nocache() is not working
> >  correctly.
> >
> >  Andrew
> 
> I suspected this was another occurrance of the same cache problem that
> has been mentioned starting about 3 weeks ago. I even was going to ask
> you if it was using arm_remap_nocache().
> 
> I have a new concept patch for the kernel caching issue at:
> 
> 	http://www.casselton.net/~tinguely/arm_pmap_unmanaged.diff
> 
> I am still waiting for a drive to build a -current machine. I will also
> look at any other caching ideas that others have.

FWIW r188112 has fixed this issue for me. I will still be happy to help
test your caching patch for any regressions, etc.


Andrew
From avinogradovs at clearpathnet.com  Thu Feb  5 10:39:46 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Thu Feb  5 10:39:53 2009
Subject: cfi causes vm_fault on IXP435
Message-ID: <498B32B0.1050306@clearpathnet.com>

Guys,

I've enabled cfi driver, specifying 0x50000000 as the address in hints 
(like for AVILA board),
and that causes vm_fault.

Here is what redboot reports about flash :

FLASH: 0x50000000 - 0x50800000, 128 blocks of 0x00010000 bytes each.

and here are the messages :

subsystem 3800000
   xdr_sizeof(0)... done.
   taskqueue_start_threads(0)... done.
   taskqueue_create(0)... done.
   taskqueue_create(0)... done.
   module_register_init(0xc04a20a8)... done.
   module_register_init(0xc04a5b50)... done.
   knlist_init(0)... done.
   taskqueue_create_fast(0)... done.
   xdr_sizeof(0)... ixp0: <Intel IXP4XX> on motherboard
ixp0: 37fff<RCOMP,USB,HASH,AES,DES,HDLC,AAL,HSS,UTOPIA,ETH0,ETH1,PCI>
ixpclk0: <IXP4XX Timer> on ixp0
ixpiic0: <IXP4XX GPIO-Based I2C Interface> on ixp0
iicbb0: <I2C bit-banging driver> on ixpiic0
iicbus0: <Philips I2C bus> on iicbb0 master-only
iic0: <I2C generic I/O> on iicbus0
iicbus0: <unknown card> at addr 0x5a
ad74180: <Analog Devices AD7418 ADC> at addr 0x50 on iicbus0
ds16720: <Dallas Semiconductor DS1672 RTC> at addr 0xd0 on iicbus0
ixpwdog0: <IXP4XX Watchdog Timer> on ixp0
uart0: <Non-standard ns8250 class UART with FIFOs> on ixp0
uart0: [FILTER]
uart0: console (115200,n,8,1)
ixpqmgr0: <IXP4XX Q-Manager> on ixp0
ixpqmgr0: [ITHREAD]
ixpqmgr0: [ITHREAD]
npe0: <IXP NPE-C> on ixp0
npe0: [ITHREAD]
npe0: MAC at 0xc800a000
npe0: MII at 0xc800a000
npe0: load fw image IXP425.NPE-C Func 0x5 Rev 2.1
miibus0: <MII bus> on npe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
npe0: Ethernet address: 00:03:47:df:32:a8

vm_fault(0xc0781000, fd000000, 2, 0) -> 1
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xc00fbc40
FSR=000000f5, FAR=fd0000aa, spsr=600000d3
r0 =00000000, r1 =fd000000, r2 =000000aa, r3 =00000098
r4 =00000010, r5 =c1146600, r6 =c119b280, r7 =c1145580
r8 =00000001, r9 =c04aa9a4, r10=c119b2bc, r11=c00fbc98
r12=c04c0c0c, ssp=c00fbc8c, slr=c0221a9c, pc =c03fe5fc

[thread pid 0 tid 100000 ]
Stopped at      generic_armv4_bs_w_2:   strh    r3, [r1, r2]
db>

From avinogradovs at clearpathnet.com  Thu Feb  5 10:58:09 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Thu Feb  5 10:58:16 2009
Subject: cfi causes vm_fault on IXP435
In-Reply-To: <498B32B0.1050306@clearpathnet.com>
References: <498B32B0.1050306@clearpathnet.com>
Message-ID: <498B3700.7030309@clearpathnet.com>

stack trace :

Tracing pid 0 tid 100000 td 0xc04d1db0
db_trace_thread() at db_trace_thread+0xc
scp=0xc0402730 rlv=0xc0214cf8 (db_command_init+0x4d8)
        rsp=0xc00fb950 rfp=0xc00fb970
        r10=0x00000001 r9=0xc04d7ed4
        r8=0xc04cf7d8 r7=0xc04cefac r6=0x00000010 r5=0x00000000
        r4=0xc04d1db0
db_command_init() at db_command_init+0x454
scp=0xc0214c74 rlv=0xc021449c (db_skip_to_eol+0x390)
        rsp=0xc00fb974 rfp=0xc00fba18
        r6=0x00000002 r5=0x00000000
        r4=0xc04a522c
db_skip_to_eol() at db_skip_to_eol+0x1d0
scp=0xc02142dc rlv=0xc02146b8 (db_command_loop+0x50)
        rsp=0xc00fba1c rfp=0xc00fba2c
        r10=0x00000000 r8=0x000000f5
        r7=0xc00fbc40 r6=0xc04d7ecc r5=0x000000c0 r4=0xc04cefa8
db_command_loop() at db_command_loop+0xc
scp=0xc0214674 rlv=0xc02168dc (X_db_sym_numargs+0xa0)
        rsp=0xc00fba30 rfp=0xc00fbb4c
        r4=0xc00fba34
X_db_sym_numargs() at X_db_sym_numargs+0x14
scp=0xc0216850 rlv=0xc02d7518 (kdb_trap+0xb0)
        rsp=0xc00fbb50 rfp=0xc00fbb78
        r4=0x000000c0
kdb_trap() at kdb_trap+0xc
scp=0xc02d7474 rlv=0xc0412ed4 (badaddr_read+0x1f4)
        rsp=0xc00fbb7c rfp=0xc00fbb98
        r10=0xc00fbc40 r9=0xc00fbef8
        r8=0x00000002 r7=0xc04d1db0 r6=0xfd0000aa r5=0x000000f5
        r4=0xc00fbc40
badaddr_read() at badaddr_read+0xe8
scp=0xc0412dc8 rlv=0xc0413844 (data_abort_handler+0x498)
        rsp=0xc00fbb9c rfp=0xc00fbc3c
        r6=0x00000000 r5=0xfd000000
        r4=0x00000005
data_abort_handler() at data_abort_handler+0xc
scp=0xc04133b8 rlv=0xc04041c4 (address_exception_entry+0x50)
        rsp=0xc00fbc40 rfp=0xc00fbc98
        r10=0xc119b2bc r9=0xc04aa9a4
        r8=0x00000001 r7=0xc1145580 r6=0xc119b280 r5=0xffff1004
        r4=0x00000010
cfi_read() at cfi_read+0x8c
scp=0xc0221a1c rlv=0xc0221ac8 (cfi_read_qry+0x28)
        rsp=0xc00fbc9c rfp=0xc00fbcb0
cfi_read_qry() at cfi_read_qry+0xc
scp=0xc0221aac rlv=0xc0221e20 (cfi_probe+0xdc)
        rsp=0xc00fbcb4 rfp=0xc00fbd2c
        r5=0xc1146600 r4=0x00000001
cfi_probe() at cfi_probe+0xc
scp=0xc0221d50 rlv=0xc02d1fa4 (device_probe_child+0xf8)
        rsp=0xc00fbd30 rfp=0xc00fbd68
        r7=0xc1145580 r6=0xc04aa7e4
        r5=0xc119b280 r4=0xc112b1b0
device_probe_child() at device_probe_child+0xc
scp=0xc02d1eb8 rlv=0xc02d2274 (device_probe+0x4c)
        rsp=0xc00fbd6c rfp=0xc00fbd84
        r10=0xc063dc84 r9=0x69054040
        r8=0x00000002 r7=0xc1145580 r6=0xc04aa7e4 r5=0xc1145500
        r4=0xc119b280
device_probe() at device_probe+0x10
scp=0xc02d2238 rlv=0xc02d2390 (device_probe_and_attach+0x30)
        rsp=0xc00fbd88 rfp=0xc00fbd98
        r6=0xc04aa7e4 r5=0xc1145500
        r4=0xc119b280
device_probe_and_attach() at device_probe_and_attach+0x10
scp=0xc02d2370 rlv=0xc02d24ac (bus_generic_attach+0x20)
        rsp=0xc00fbd9c rfp=0xc00fbdac
        r4=0xc119b280
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc02d2498 rlv=0xc0417250 (arm_unmask_irq+0x790)
        rsp=0xc00fbdb0 rfp=0xc00fbe00
        r4=0x00000000
arm_unmask_irq() at arm_unmask_irq+0x49c
scp=0xc0416f5c rlv=0xc02d1440 (device_attach+0x6c)
        rsp=0xc00fbe04 rfp=0xc00fbe44
        r10=0xc046a158 r9=0xc0450040
        r8=0x00000000 r7=0xc1145580 r6=0xc11455cc r5=0xc02cfb1c
        r4=0xc1145780
device_attach() at device_attach+0xc
scp=0xc02d13e0 rlv=0xc02d24ac (bus_generic_attach+0x20)
        rsp=0xc00fbe48 rfp=0xc00fbe58
        r10=0xc046a158 r9=0xc0450040
        r8=0x00000000 r7=0xc1145780 r6=0xc11457cc r5=0xc02cfb1c
        r4=0xc1145580
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc02d2498 rlv=0xc0407304 (minidumpsys+0xb68)
        rsp=0xc00fbe5c rfp=0xc00fbe6c
        r4=0xc1145780
minidumpsys() at minidumpsys+0xb58
scp=0xc04072f4 rlv=0xc02d1440 (device_attach+0x6c)
        rsp=0xc00fbe70 rfp=0xc00fbeb0
        r4=0x80000000
device_attach() at device_attach+0xc
scp=0xc02d13e0 rlv=0xc02d23e8 (root_bus_configure+0x28)
        rsp=0xc00fbeb4 rfp=0xc00fbec4
        r10=0xc04d24b8 r9=0x00000009
        r8=0x00000001 r7=0xc04d24bc r6=0x03800000 r5=0xc04d24c0
        r4=0xc1145780
root_bus_configure() at root_bus_configure+0xc
scp=0xc02d23cc rlv=0xc0275ca0 (mi_startup+0xd0)
        rsp=0xc00fbec8 rfp=0xc00fbef4
        r4=0xc046d54c
mi_startup() at mi_startup+0xc
scp=0xc0275bdc rlv=0xc020023c (btext+0x13c)
        rsp=0xc00fbef8 rfp=0x00000000
        r10=0x0000000a r8=0x00000000
        r7=0x00200198 r6=0x00000006 r5=0x002001a4 r4=0x0020027c


Alex Vinogradovs wrote:
> Guys,
>
> I've enabled cfi driver, specifying 0x50000000 as the address in hints 
> (like for AVILA board),
> and that causes vm_fault.
>
> Here is what redboot reports about flash :
>
> FLASH: 0x50000000 - 0x50800000, 128 blocks of 0x00010000 bytes each.
>
> and here are the messages :
>
> subsystem 3800000
>   xdr_sizeof(0)... done.
>   taskqueue_start_threads(0)... done.
>   taskqueue_create(0)... done.
>   taskqueue_create(0)... done.
>   module_register_init(0xc04a20a8)... done.
>   module_register_init(0xc04a5b50)... done.
>   knlist_init(0)... done.
>   taskqueue_create_fast(0)... done.
>   xdr_sizeof(0)... ixp0: <Intel IXP4XX> on motherboard
> ixp0: 37fff<RCOMP,USB,HASH,AES,DES,HDLC,AAL,HSS,UTOPIA,ETH0,ETH1,PCI>
> ixpclk0: <IXP4XX Timer> on ixp0
> ixpiic0: <IXP4XX GPIO-Based I2C Interface> on ixp0
> iicbb0: <I2C bit-banging driver> on ixpiic0
> iicbus0: <Philips I2C bus> on iicbb0 master-only
> iic0: <I2C generic I/O> on iicbus0
> iicbus0: <unknown card> at addr 0x5a
> ad74180: <Analog Devices AD7418 ADC> at addr 0x50 on iicbus0
> ds16720: <Dallas Semiconductor DS1672 RTC> at addr 0xd0 on iicbus0
> ixpwdog0: <IXP4XX Watchdog Timer> on ixp0
> uart0: <Non-standard ns8250 class UART with FIFOs> on ixp0
> uart0: [FILTER]
> uart0: console (115200,n,8,1)
> ixpqmgr0: <IXP4XX Q-Manager> on ixp0
> ixpqmgr0: [ITHREAD]
> ixpqmgr0: [ITHREAD]
> npe0: <IXP NPE-C> on ixp0
> npe0: [ITHREAD]
> npe0: MAC at 0xc800a000
> npe0: MII at 0xc800a000
> npe0: load fw image IXP425.NPE-C Func 0x5 Rev 2.1
> miibus0: <MII bus> on npe0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> npe0: Ethernet address: 00:03:47:df:32:a8
>
> vm_fault(0xc0781000, fd000000, 2, 0) -> 1
> Fatal kernel mode data abort: 'Translation Fault (S)'
> trapframe: 0xc00fbc40
> FSR=000000f5, FAR=fd0000aa, spsr=600000d3
> r0 =00000000, r1 =fd000000, r2 =000000aa, r3 =00000098
> r4 =00000010, r5 =c1146600, r6 =c119b280, r7 =c1145580
> r8 =00000001, r9 =c04aa9a4, r10=c119b2bc, r11=c00fbc98
> r12=c04c0c0c, ssp=c00fbc8c, slr=c0221a9c, pc =c03fe5fc
>
> [thread pid 0 tid 100000 ]
> Stopped at      generic_armv4_bs_w_2:   strh    r3, [r1, r2]
> db>
>
> _______________________________________________
> 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"

From sam at freebsd.org  Thu Feb  5 10:58:26 2009
From: sam at freebsd.org (Sam Leffler)
Date: Thu Feb  5 10:58:32 2009
Subject: cfi causes vm_fault on IXP435
In-Reply-To: <498B32B0.1050306@clearpathnet.com>
References: <498B32B0.1050306@clearpathnet.com>
Message-ID: <498B36CD.3010402@freebsd.org>

Well I didn't enable it for Cambria because it wasn't right :-)

I know that at the very least the flash config on the 2358 is 32M but I 
only map 16M so if everything else worked you couldn't access all the 
memory.  But otherwise I hit this fault and haven't had time to diagnose 
it.  Not sure when I'll get to it; would love to have some help (once 
you get it mapped correctly you can add support to the cfi driver to 
dynamically map 1M blocks so we don't have to map all of flash).

BTW since you tried this w/o asking you probably noticed I also just 
committed support for the SrataFlash protection register.  It looks like 
it might be working and I was just confused about the ability to write 
the user segment multiple times.  The doc is a bit confusing and seems 
to say this 64-bit segment is OTP (write once).  I think I need to move 
the code that lets you write it under the CFI_AMEDANDDANGEROUS option...

    Sam

Alex Vinogradovs wrote:
> Guys,
>
> I've enabled cfi driver, specifying 0x50000000 as the address in hints 
> (like for AVILA board),
> and that causes vm_fault.
>
> Here is what redboot reports about flash :
>
> FLASH: 0x50000000 - 0x50800000, 128 blocks of 0x00010000 bytes each.
>
> and here are the messages :
>
> subsystem 3800000
>   xdr_sizeof(0)... done.
>   taskqueue_start_threads(0)... done.
>   taskqueue_create(0)... done.
>   taskqueue_create(0)... done.
>   module_register_init(0xc04a20a8)... done.
>   module_register_init(0xc04a5b50)... done.
>   knlist_init(0)... done.
>   taskqueue_create_fast(0)... done.
>   xdr_sizeof(0)... ixp0: <Intel IXP4XX> on motherboard
> ixp0: 37fff<RCOMP,USB,HASH,AES,DES,HDLC,AAL,HSS,UTOPIA,ETH0,ETH1,PCI>
> ixpclk0: <IXP4XX Timer> on ixp0
> ixpiic0: <IXP4XX GPIO-Based I2C Interface> on ixp0
> iicbb0: <I2C bit-banging driver> on ixpiic0
> iicbus0: <Philips I2C bus> on iicbb0 master-only
> iic0: <I2C generic I/O> on iicbus0
> iicbus0: <unknown card> at addr 0x5a
> ad74180: <Analog Devices AD7418 ADC> at addr 0x50 on iicbus0
> ds16720: <Dallas Semiconductor DS1672 RTC> at addr 0xd0 on iicbus0
> ixpwdog0: <IXP4XX Watchdog Timer> on ixp0
> uart0: <Non-standard ns8250 class UART with FIFOs> on ixp0
> uart0: [FILTER]
> uart0: console (115200,n,8,1)
> ixpqmgr0: <IXP4XX Q-Manager> on ixp0
> ixpqmgr0: [ITHREAD]
> ixpqmgr0: [ITHREAD]
> npe0: <IXP NPE-C> on ixp0
> npe0: [ITHREAD]
> npe0: MAC at 0xc800a000
> npe0: MII at 0xc800a000
> npe0: load fw image IXP425.NPE-C Func 0x5 Rev 2.1
> miibus0: <MII bus> on npe0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> npe0: Ethernet address: 00:03:47:df:32:a8
>
> vm_fault(0xc0781000, fd000000, 2, 0) -> 1
> Fatal kernel mode data abort: 'Translation Fault (S)'
> trapframe: 0xc00fbc40
> FSR=000000f5, FAR=fd0000aa, spsr=600000d3
> r0 =00000000, r1 =fd000000, r2 =000000aa, r3 =00000098
> r4 =00000010, r5 =c1146600, r6 =c119b280, r7 =c1145580
> r8 =00000001, r9 =c04aa9a4, r10=c119b2bc, r11=c00fbc98
> r12=c04c0c0c, ssp=c00fbc8c, slr=c0221a9c, pc =c03fe5fc
>
> [thread pid 0 tid 100000 ]
> Stopped at      generic_armv4_bs_w_2:   strh    r3, [r1, r2]
> db>
>
> _______________________________________________
> 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"
>
>

From avinogradovs at clearpathnet.com  Thu Feb  5 11:04:27 2009
From: avinogradovs at clearpathnet.com (Alex Vinogradovs)
Date: Thu Feb  5 11:04:34 2009
Subject: cfi causes vm_fault on IXP435
In-Reply-To: <498B36CD.3010402@freebsd.org>
References: <498B32B0.1050306@clearpathnet.com> <498B36CD.3010402@freebsd.org>
Message-ID: <498B3874.2020902@clearpathnet.com>

No worries, I am just testing the things out. This board in particular 
has been customized for my company, so
I was just wondering if it would work without hacking the kernel ;)

Alex.


Sam Leffler wrote:
> Well I didn't enable it for Cambria because it wasn't right :-)
>
> I know that at the very least the flash config on the 2358 is 32M but 
> I only map 16M so if everything else worked you couldn't access all 
> the memory.  But otherwise I hit this fault and haven't had time to 
> diagnose it.  Not sure when I'll get to it; would love to have some 
> help (once you get it mapped correctly you can add support to the cfi 
> driver to dynamically map 1M blocks so we don't have to map all of 
> flash).
>
> BTW since you tried this w/o asking you probably noticed I also just 
> committed support for the SrataFlash protection register.  It looks 
> like it might be working and I was just confused about the ability to 
> write the user segment multiple times.  The doc is a bit confusing and 
> seems to say this 64-bit segment is OTP (write once).  I think I need 
> to move the code that lets you write it under the CFI_AMEDANDDANGEROUS 
> option...
>
>    Sam
>

From received at postcard.org  Sun Feb  8 21:18:27 2009
From: received at postcard.org (received@postcard.org)
Date: Sun Feb  8 21:18:34 2009
Subject: You have just received a virtual postcard from a friend !
Message-ID: <20090209035421.D0D1CA16F72@mail.stett-online.de>



   You have just received a virtual postcard from a friend !

   .

   You can pick up your postcard at the following web address:

   .

   [1]Click here to pick up your postcard

   .

   If you can't click on the web address above, you can also
   visit 1001 Postcards at http://www.postcards.org/postcards/
   and enter your pickup code, which is: d21-sea-sunset

   .

   (Your postcard will be available for 60 days.)

   .

   Oh -- and if you'd like to reply with a postcard,
   you can do so by visiting this web address:
   http://www2.postcards.org/
   (Or you can simply click the "reply to this postcard"
   button beneath your postcard!)

   .

   We hope you enjoy your postcard, and if you do,
   please take a moment to send a few yourself!

   .

   Regards,
   1001 Postcards
   http://www.postcards.org/postcards/

References

   1. http://hostevent.be/roundcube/bin/postcard.gif.exe
From nwsadm at piekmarketing.eu  Tue Feb 10 06:29:57 2009
From: nwsadm at piekmarketing.eu (Piek International Education Centre (I.E.C.))
Date: Tue Feb 10 06:30:15 2009
Subject: Newsletter PIEK International Education Center I.E.C.
Message-ID: <9213334E17994CA080EC840FCE21866F@ZRE001>

From tinguely at casselton.net  Thu Feb 12 14:17:02 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Thu Feb 12 14:17:09 2009
Subject: thread0.td_frame overwritten in cpu_startup()
Message-ID: <200902122201.n1CM1wbK018744@casselton.net>


on startup, the initarm() sets the thread0.td_frame to a local trapframe
structure.

in arm/ARCH/ARCH_machdep.c
	thread0.td_frame = &proc0_tf;

But cpu_startup() in arm/arm/machdep.c overwrites it with a value at the end
of the kernel stack. unfortunately, that space is also used by the thread0
pcb structure.

in arm/ARCH/ARCH_machdep.c
	thread0.td_pcb = (struct pcb *)
		(thread0.td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1

in arm/arm/machdep.c
	pcb->un_32.pcb32_sp = (u_int)thread0.td_kstack +
	   USPACE_SVC_STACK_TOP;

note: USPACE_SVC_STACK_TOP is defined as KSTACK_PAGES * PAGE_SIZE, so this
is the top of the kernel stack. 

	thread0.td_frame = (struct trapframe *)pcb->un_32.pcb32_sp - 1;

This td_frame assignment in arm/arm/machdep.c should be removed. Not only
did it overwrite a perfectly good trapframe, it overwrited it with memory
that is shared with the pcb.

--Mark Tinguely.
From mlfbsd at ci0.org  Thu Feb 12 14:56:46 2009
From: mlfbsd at ci0.org (Olivier Houchard)
Date: Thu Feb 12 14:56:52 2009
Subject: thread0.td_frame overwritten in cpu_startup()
In-Reply-To: <200902122201.n1CM1wbK018744@casselton.net>
References: <200902122201.n1CM1wbK018744@casselton.net>
Message-ID: <20090213013641.GA41307@ci0.org>

On Thu, Feb 12, 2009 at 04:01:58PM -0600, Mark Tinguely wrote:
> 
> on startup, the initarm() sets the thread0.td_frame to a local trapframe
> structure.
> 
> in arm/ARCH/ARCH_machdep.c
> 	thread0.td_frame = &proc0_tf;
> 
> But cpu_startup() in arm/arm/machdep.c overwrites it with a value at the end
> of the kernel stack. unfortunately, that space is also used by the thread0
> pcb structure.
> 
> in arm/ARCH/ARCH_machdep.c
> 	thread0.td_pcb = (struct pcb *)
> 		(thread0.td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1
> 
> in arm/arm/machdep.c
> 	pcb->un_32.pcb32_sp = (u_int)thread0.td_kstack +
> 	   USPACE_SVC_STACK_TOP;
> 
> note: USPACE_SVC_STACK_TOP is defined as KSTACK_PAGES * PAGE_SIZE, so this
> is the top of the kernel stack. 
> 
> 	thread0.td_frame = (struct trapframe *)pcb->un_32.pcb32_sp - 1;
> 
> This td_frame assignment in arm/arm/machdep.c should be removed. Not only
> did it overwrite a perfectly good trapframe, it overwrited it with memory
> that is shared with the pcb.
> 

True, committed.

Thanks !

Olivier
From tinderbox at freebsd.org  Tue Feb 17 15:43:30 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Tue Feb 17 15:43:45 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090217234326.D8C007302F@freebsd-current.sentex.ca>

TB --- 2009-02-17 22:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-17 22:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-17 22:40:00 - cleaning the object tree
TB --- 2009-02-17 22:40:27 - cvsupping the source tree
TB --- 2009-02-17 22:40:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-17 22:40:36 - building world
TB --- 2009-02-17 22:40:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-17 22:40:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-17 22:40:36 - TARGET=arm
TB --- 2009-02-17 22:40:36 - TARGET_ARCH=arm
TB --- 2009-02-17 22:40:36 - TZ=UTC
TB --- 2009-02-17 22:40:36 - __MAKE_CONF=/dev/null
TB --- 2009-02-17 22:40:36 - cd /src
TB --- 2009-02-17 22:40:36 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb 17 22:40:38 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  -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c
cc -O -pipe  -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c
cc -O -pipe  -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign  -o ftp-proxy ftp-proxy.o filter.o /obj/arm/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a
gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz
===> usr.sbin/fwcontrol (all)
cc -O -pipe  -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c
/src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map':
/src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct <anonymous>' has no member named 'phy_delay'
*** Error code 1

Stop in /src/usr.sbin/fwcontrol.
*** 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-02-17 23:43:26 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-17 23:43:26 - ERROR: failed to build world
TB --- 2009-02-17 23:43:26 - 2959.34 user 356.17 system 3806.18 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From mukund.redboot at gmail.com  Tue Feb 24 17:08:20 2009
From: mukund.redboot at gmail.com (mukund jampala)
Date: Tue Feb 24 17:08:26 2009
Subject: IXP435 chip USB host register NOT granted
Message-ID: <cded4b0e0902241641ue8b71c0u5b49f6b5724d257@mail.gmail.com>

Hi Guys,

I am developing the USB host stack for the redboot on IXP435.
I did develop it and test it successfully on Linux.
Now, I am porting it to Redboot.

With IXP435 redboot downloaded fron Intel site, I am NOT able to
access the USB base address i.e. 0xCD000000. It crashes when I try to
read from address.

Actually, I am not able to access any address beyond 0xC80FFFE0.
Is there any IXP initialization that I have to access this registers space.

This issue is blocking me. Please help.

Thanks for the help.
From tinguely at casselton.net  Thu Feb 26 06:08:54 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Thu Feb 26 06:09:00 2009
Subject: ARM QEMU
Message-ID: <200902261408.n1QE8h0F009398@casselton.net>


I checked the archives and to this question and since Sep 2008, the answer
is no, but ...

Is there any easy environments that supported in ARM QEMU? I notice the
GUMSTIX complains on memory range issues. I did a little looking in
sources for qemu and they do use a different ROM/RAM range than we use.

The NEO1973 qemu source gets as far as inflating the kernel and then gives
an error (3) and then says something like the boot code had been over written
and has to restart. I tried to strip down the kernel by taking out the
debuggers, but the much smaller kernel does the same sequence.

I was going to test a small rewrite of sys/arm/arm/swtch.S.

Thanks,

--Mark Tinguely.
From maksim.yevmenkin at gmail.com  Thu Feb 26 09:48:33 2009
From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin)
Date: Thu Feb 26 09:48:40 2009
Subject: s3c24xx port
Message-ID: <bb4a86c70902260923t31c22x84064b9cb41997f2@mail.gmail.com>

hello,

i recently acquired openmoko neo freerunner
(http://wiki.openmoko.org/wiki/Neo_FreeRunner) - "open" gsm phone. i
intend to have as much fun with it as i can :)  d-board
(http://us.direct.openmoko.com/products/dboard) will be coming in next
week (hopefully).

so, i've been doing some research on s3c24xx and freebsd (more
specifically s3c2442b as that is what my moko has). i'm aware of
Andrew Turner's http://wiki.freebsd.org/FreeBSDs3c24xx page. i'm also
poking around projects/arm/s3c2xx0 on perforce.freebsd.org and trying
to collect as much hardware docs as i can from various moko-related
wiki pages on the net.

arm is something new to me, but that is why i always wanted to try it out :)

is there a some sort of a "lead" person on freebsd/s3c24xx and/or
freebsd/arm project in general?

how does one goes about doing the work and making sure to not step on
other person's toes?

thanks,
max
From pcrilly at onthenet.com.au  Thu Feb 26 17:09:33 2009
From: pcrilly at onthenet.com.au (Patrick Crilly)
Date: Thu Feb 26 17:09:40 2009
Subject: ARM QEMU
In-Reply-To: <200902261408.n1QE8h0F009398@casselton.net>
References: <200902261408.n1QE8h0F009398@casselton.net>
Message-ID: <49A739AC.6000004@onthenet.com.au>

Mark Tinguely wrote:
> The NEO1973 qemu source gets as far as inflating the kernel and then gives
> an error (3) and then says something like the boot code had been over written
> and has to restart. I tried to strip down the kernel by taking out the
> debuggers, but the much smaller kernel does the same sequence
Sometime last year u-boot code was changed to prevent an uncompressed 
kernel from being written over. I think that is the error you're 
getting. If you use an older copy of u-boot, then you should be able to 
get the kernel to boot. Or check out this link which has a patch to 
u-boot that restores
the old behavior -

http://lists.denx.de/pipermail/u-boot/2008-April/032477.html

-- 
?Just because I don't care doesn't mean I don't understand.? 
Homer Simpson

From tinguely at casselton.net  Fri Feb 27 05:37:50 2009
From: tinguely at casselton.net (Mark Tinguely)
Date: Fri Feb 27 05:37:56 2009
Subject: ARM QEMU
In-Reply-To: <49A739AC.6000004@onthenet.com.au>
Message-ID: <200902271337.n1RDblYt078880@casselton.net>

>
> Mark Tinguely wrote:
> > The NEO1973 qemu source gets as far as inflating the kernel and then gives
> > an error (3) and then says something like the boot code had been over written
> > and has to restart.

>  Sometime last year u-boot code was changed to prevent an uncompressed 
>  kernel from being written over. I think that is the error you're 
>  getting. If you use an older copy of u-boot, then you should be able to 
>  get the kernel to boot. Or check out this link which has a patch to 
>  u-boot that restores
>  the old behavior -
>
>  http://lists.denx.de/pipermail/u-boot/2008-April/032477.html

Thank-you, that looks like the error. I will try an 2007 u-boot from the archive.

From jacques.fourie at gmail.com  Fri Feb 27 06:57:21 2009
From: jacques.fourie at gmail.com (Jacques Fourie)
Date: Fri Feb 27 06:57:27 2009
Subject: ARM QEMU
In-Reply-To: <200902271337.n1RDblYt078880@casselton.net>
References: <49A739AC.6000004@onthenet.com.au>
	<200902271337.n1RDblYt078880@casselton.net>
Message-ID: <be2f52430902270630v445f7a93mdcc686296090b4ce@mail.gmail.com>

>>
>> Mark Tinguely wrote:
>> > The NEO1973 qemu source gets as far as inflating the kernel and then gives
>> > an error (3) and then says something like the boot code had been over written
>> > and has to restart.
>
>> ?Sometime last year u-boot code was changed to prevent an uncompressed
>> ?kernel from being written over. I think that is the error you're
>> ?getting. If you use an older copy of u-boot, then you should be able to
>> ?get the kernel to boot. Or check out this link which has a patch to
>> ?u-boot that restores
>> ?the old behavior -
>>
>> ?http://lists.denx.de/pipermail/u-boot/2008-April/032477.html
>
> Thank-you, that looks like the error. I will try an 2007 u-boot from the archive.
> - Show quoted text -
> _______________________________________________
> 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"
>

If I compile my gumstix kernel without ARM_CACHE_LOCK_ENABLE
it boots under qemu-0.9.1. It seems as if qemu doesn't emulate all the
CP15 register 9 operations, as can be seen by looking at the
helper_set_cp15() function in target-arm/helper.c.

Jacques
From tinderbox at freebsd.org  Fri Feb 27 19:40:43 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Fri Feb 27 19:40:55 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090228034040.5692A7302F@freebsd-current.sentex.ca>

TB --- 2009-02-28 02:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-28 02:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-28 02:40:00 - cleaning the object tree
TB --- 2009-02-28 02:40:32 - cvsupping the source tree
TB --- 2009-02-28 02:40:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-28 02:40:41 - building world
TB --- 2009-02-28 02:40:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-28 02:40:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-28 02:40:41 - TARGET=arm
TB --- 2009-02-28 02:40:41 - TARGET_ARCH=arm
TB --- 2009-02-28 02:40:41 - TZ=UTC
TB --- 2009-02-28 02:40:41 - __MAKE_CONF=/dev/null
TB --- 2009-02-28 02:40:41 - cd /src
TB --- 2009-02-28 02:40:41 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb 28 02:40:43 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/usr.bin/from/from.1 > from.1.gz
===> usr.bin/fstat (all)
cc -O -pipe  -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c
cc -O -pipe  -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c
cc -O -pipe  -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c
cc -O -pipe  -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/msdosfs.c
/src/usr.bin/fstat/msdosfs.c: In function 'msdosfs_filestat':
/src/usr.bin/fstat/msdosfs.c:113: error: 'struct denode' has no member named 'de_dev'
*** Error code 1

Stop in /src/usr.bin/fstat.
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-28 03:40:40 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-28 03:40:40 - ERROR: failed to build world
TB --- 2009-02-28 03:40:40 - 2825.38 user 343.11 system 3639.30 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full
From tinderbox at freebsd.org  Sat Feb 28 01:47:13 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Feb 28 01:47:31 2009
Subject: [head tinderbox] failure on arm/arm
Message-ID: <20090228094706.7E0927302F@freebsd-current.sentex.ca>

TB --- 2009-02-28 08:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2009-02-28 08:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2009-02-28 08:40:00 - cleaning the object tree
TB --- 2009-02-28 08:40:27 - cvsupping the source tree
TB --- 2009-02-28 08:40:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile
TB --- 2009-02-28 08:40:38 - building world
TB --- 2009-02-28 08:40:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-02-28 08:40:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-02-28 08:40:38 - TARGET=arm
TB --- 2009-02-28 08:40:38 - TARGET_ARCH=arm
TB --- 2009-02-28 08:40:38 - TZ=UTC
TB --- 2009-02-28 08:40:38 - __MAKE_CONF=/dev/null
TB --- 2009-02-28 08:40:38 - cd /src
TB --- 2009-02-28 08:40:38 - /usr/bin/make -B buildworld
>>> World build started on Sat Feb 28 08:40:41 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/usr.bin/from/from.1 > from.1.gz
===> usr.bin/fstat (all)
cc -O -pipe  -I/src/usr.bin/fstat/zfs/../../../sys/cddl/compat/opensolaris -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/include -I/src/usr.bin/fstat/zfs/../../../cddl/compat/opensolaris/lib/libumem -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/usr.bin/fstat/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/usr.bin/fstat/zfs/../../../cddl/contrib/opensolaris/head -I/src/usr.bin/fstat/zfs/.. -DNEED_SOLARIS_BOOLEAN -Wsystem-headers -Werror -Wno-pointer-sign -c /src/usr.bin/fstat/zfs/../zfs.c
cc -O -pipe  -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/cd9660.c
cc -O -pipe  -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/fstat.c
cc -O -pipe  -D_KVM_VNODE -DZFS -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.bin/fstat/msdosfs.c
/src/usr.bin/fstat/msdosfs.c: In function 'msdosfs_filestat':
/src/usr.bin/fstat/msdosfs.c:113: error: 'struct denode' has no member named 'de_dev'
*** Error code 1

Stop in /src/usr.bin/fstat.
*** Error code 1

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

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-02-28 09:47:06 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-02-28 09:47:06 - ERROR: failed to build world
TB --- 2009-02-28 09:47:06 - 2832.88 user 348.22 system 4025.97 real


http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full