From mlfbsd at ci0.org Wed Apr 1 02:36:43 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Wed Apr 1 02:36:50 2009 Subject: locore.S question In-Reply-To: <200903312350.n2VNoAwK060973@casselton.net> References: <20090331230945.GA8584@ci0.org> <200903312350.n2VNoAwK060973@casselton.net> Message-ID: <20090401093815.GA23622@ci0.org> On Tue, Mar 31, 2009 at 06:50:10PM -0500, Mark Tinguely wrote: > I was wondering why the kernel is loaded 16MB into the physical memory? > Don't know in this case, but it often happens the bootloader is loaded at the beginning of the ram, and so won't let you load the kernel there. Olivier From gballet at gmail.com Wed Apr 1 03:25:54 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Wed Apr 1 03:26:00 2009 Subject: locore.S question In-Reply-To: <20090401093815.GA23622@ci0.org> References: <20090331230945.GA8584@ci0.org> <200903312350.n2VNoAwK060973@casselton.net> <20090401093815.GA23622@ci0.org> Message-ID: On Wed, Apr 1, 2009 at 11:38 AM, Olivier Houchard wrote: > On Tue, Mar 31, 2009 at 06:50:10PM -0500, Mark Tinguely wrote: >> I was wondering why the kernel is loaded 16MB into the physical memory? >> > > Don't know in this case, but it often happens the bootloader is loaded at > the beginning of the ram, and so won't let you load the kernel there. > > Olivier > I have indeed u-boot and my intermediate kernel-loader that are loaded at the beginning of the RAM. This is not carved in stone: I will probably move the kernel-loader further away and overwrite u-boot. During platform bringup, though, I have put it here. Nothing to worry about, I was just wondering if there was some concealed requirement for the kernel to be below the first 16MB of RAM. Guillaume From newsletter at piekmarketing.eu Wed Apr 1 06:41:43 2009 From: newsletter at piekmarketing.eu (Piek International Education Centre (I.E.C.)) Date: Wed Apr 1 06:42:10 2009 Subject: Newsletter PIEK International Education Center I.E.C. Message-ID: From raj at semihalf.com Wed Apr 1 11:30:08 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Wed Apr 1 11:30:14 2009 Subject: locore.S question In-Reply-To: References: <20090331230945.GA8584@ci0.org> <200903312350.n2VNoAwK060973@casselton.net> <20090401093815.GA23622@ci0.org> Message-ID: <8A463EAA-0970-448C-A8D1-DB1E31AD013F@semihalf.com> On 2009-04-01, at 12:25, Guillaume Ballet wrote: > On Wed, Apr 1, 2009 at 11:38 AM, Olivier Houchard > wrote: >> On Tue, Mar 31, 2009 at 06:50:10PM -0500, Mark Tinguely wrote: >>> I was wondering why the kernel is loaded 16MB into the physical >>> memory? >>> >> >> Don't know in this case, but it often happens the bootloader is >> loaded at >> the beginning of the ram, and so won't let you load the kernel there. >> >> Olivier >> > > I have indeed u-boot and my intermediate kernel-loader that are loaded > at the beginning of the RAM. This is not carved in stone: I will > probably move the kernel-loader further away and overwrite u-boot. > During platform bringup, though, I have put it here. > Nothing to worry about, I was just wondering if there was some > concealed requirement for the kernel to be below the first 16MB of > RAM. Ideally, we'd have loader(8) load the kernel to the desired location (set by the user interactively) in memory, which is not in place yet, but also not a difficult thing to do. Rafal From stas at FreeBSD.org Fri Apr 3 01:43:38 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Apr 3 01:44:14 2009 Subject: s3c24xx port In-Reply-To: References: Message-ID: <20090403124319.7c9d488d.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 26 Feb 2009 09:23:59 -0800 Maksim Yevmenkin mentioned: > 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? > I think Andrew is a person to contact to, as he has done a lot of work on s3c24xx and continues to work on this. He has also made a great wiki page on it. The same page can probably be used to communicate on the development. I recently got the openmoko phone too and was going to help out with port but has stuck with $reallife problems. I expect to return to the development soon. It's really great you're going to work on the port too! - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAknVzDMACgkQK/VZk+smlYHs/wCcDVXrzDh+55MearCtQQa9Cqco v0IAmQFm4qn9zJ7MFrLSHeDeQ9jIJPey =uVGq -----END PGP SIGNATURE----- !DSPAM:49d5cc37967002160828694! From stas at FreeBSD.org Fri Apr 3 02:05:54 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Apr 3 02:06:01 2009 Subject: does the s3c2xx0 code in perforce compilable? In-Reply-To: <708189660903270220r7991ae8fq16c0ab4d25312dfa@mail.gmail.com> References: <708189660903270220r7991ae8fq16c0ab4d25312dfa@mail.gmail.com> Message-ID: <20090403130544.3e60a224.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 27 Mar 2009 17:20:30 +0800 Gavin Mu mentioned: > Hi, > > I downloaded the s3c2xx0 code from perforce web (files in > /sys/arm/s3c2xx0 and file /sys/arm/conf/FS2410), and merged to my > 7-STABLE source tree. when I run ``config FS2410'', an error was > reported that can't find option ARM32_NEW_VM_LAYOUT. does anybody know > if the code is compilable and runable? and where's the option defined > in? Thanks. > At least it was used to compile at some point in past. I suppose, the code in p4 is based on current and may not work with stable. I'd suggesting checking out the entire p4 arm repo and trying it first. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAknV0WoACgkQK/VZk+smlYFiPgCbBeN/XEJnWfnEteD08S4U8zrB qwYAnAlCVIa26DDMk2Ege4H0FMt8C8Lz =nLMm -----END PGP SIGNATURE----- !DSPAM:49d5d171967008090317306! From andrew at fubar.geek.nz Sat Apr 4 20:18:32 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Sat Apr 4 20:18:39 2009 Subject: does the s3c2xx0 code in perforce compilable? In-Reply-To: <708189660903270220r7991ae8fq16c0ab4d25312dfa@mail.gmail.com> References: <708189660903270220r7991ae8fq16c0ab4d25312dfa@mail.gmail.com> Message-ID: <20090405150012.1dd294f4@fubar.geek.nz> On Fri, 27 Mar 2009 17:20:30 +0800 Gavin Mu wrote: > Hi, > > I downloaded the s3c2xx0 code from perforce web (files in > /sys/arm/s3c2xx0 and file /sys/arm/conf/FS2410), and merged to my > 7-STABLE source tree. when I run ``config FS2410'', an error was > reported that can't find option ARM32_NEW_VM_LAYOUT. does anybody know > if the code is compilable and runable? and where's the option defined > in? Thanks. The FS2410 code is unmaintained as I'm the only person working on the s3c2xx0 code. As I don't have the hardware to run the FS2410 kernel on I have not updated it as I've changed the rest of the kernel. If you are attempting to build the code because you have that hardware I can help update the FS2410 code to work. If it was because you have a different board it would be better to use the LN2410SBC code as a starting point as I know it boots to single user mode on real hardware. Andrew From tinderbox at freebsd.org Sun Apr 5 11:16:30 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 11:16:42 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090405181626.35E867302F@freebsd-current.sentex.ca> TB --- 2009-04-05 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 17:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-05 17:20:00 - cleaning the object tree TB --- 2009-04-05 17:20:41 - cvsupping the source tree TB --- 2009-04-05 17:20:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-05 17:20:49 - building world TB --- 2009-04-05 17:20:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 17:20:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 17:20:49 - TARGET=arm TB --- 2009-04-05 17:20:49 - TARGET_ARCH=arm TB --- 2009-04-05 17:20:49 - TZ=UTC TB --- 2009-04-05 17:20:49 - __MAKE_CONF=/dev/null TB --- 2009-04-05 17:20:49 - cd /src TB --- 2009-04-05 17:20:49 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 17:20:51 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 [...] cc1: warnings being treated as errors /src/sbin/routed/if.c: In function 'rt_xaddrs': /src/sbin/routed/if.c:631: warning: cast increases required alignment of target type /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:705: warning: cast increases required alignment of target type /src/sbin/routed/if.c:706: warning: cast increases required alignment of target type /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:954: warning: format '%ld' expects type 'long int', but argument 3 has type 'time_t' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 18:16:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 18:16:26 - ERROR: failed to build world TB --- 2009-04-05 18:16:26 - 2568.48 user 323.70 system 3385.48 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Sun Apr 5 18:16:15 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 18:16:33 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090406011612.42FB67302F@freebsd-current.sentex.ca> TB --- 2009-04-06 00:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-06 00:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-06 00:20:00 - cleaning the object tree TB --- 2009-04-06 00:20:39 - cvsupping the source tree TB --- 2009-04-06 00:20:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-06 00:20:56 - building world TB --- 2009-04-06 00:20:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-06 00:20:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-06 00:20:56 - TARGET=arm TB --- 2009-04-06 00:20:56 - TARGET_ARCH=arm TB --- 2009-04-06 00:20:56 - TZ=UTC TB --- 2009-04-06 00:20:56 - __MAKE_CONF=/dev/null TB --- 2009-04-06 00:20:56 - cd /src TB --- 2009-04-06 00:20:56 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 6 00:20: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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] echo rtquery: /obj/arm/src/tmp/usr/lib/libc.a /obj/arm/src/tmp/usr/lib/libmd.a >> .depend cc -O -pipe -DRESCUE -std=gnu99 -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/sbin/routed/if.c cc1: warnings being treated as errors /src/sbin/routed/if.c: In function 'rt_xaddrs': /src/sbin/routed/if.c:631: warning: cast increases required alignment of target type /src/sbin/routed/if.c: In function 'ifinit': /src/sbin/routed/if.c:710: warning: cast increases required alignment of target type /src/sbin/routed/if.c:954: warning: format '%ld' expects type 'long int', but argument 3 has type 'time_t' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-06 01:16:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-06 01:16:12 - ERROR: failed to build world TB --- 2009-04-06 01:16:12 - 2564.27 user 326.12 system 3371.60 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From MondoBancoPosta at bancopostaonline.net Mon Apr 6 12:55:16 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 12:55:31 2009 Subject: Premio vi aspetta! Message-ID: <1239045562.43839.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltą. Per ricevere il bonus č necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltą » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From xcllnt at mac.com Tue Apr 7 11:28:44 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Apr 7 11:28:56 2009 Subject: Root mount fails again. CAM related? In-Reply-To: References: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> Message-ID: <74181BF8-E111-4208-8C3E-8F1B39808E0B@mac.com> On Apr 7, 2009, at 11:22 AM, pluknet wrote: >> My ARM board boots from a USB mass storage device and >> for the second time the the root mount fails. First is >> was because the root mount wouldn't wait for the USB >> stack to complete the discovery process. Now CAM seems >> to have entered the picture: >> > Can this be a similar one? That was committed not far ago in rev. > 190676. > http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005635.html It could be the cause of the problem. Things worked fine before CAM grew calls to root_mount_hold()... -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Tue Apr 7 11:31:10 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Apr 7 11:31:17 2009 Subject: Root mount fails again. CAM related? Message-ID: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> All, My ARM board boots from a USB mass storage device and for the second time the the root mount fails. First is was because the root mount wouldn't wait for the USB stack to complete the discovery process. Now CAM seems to have entered the picture: ... Timecounter "CPU Timer" frequency 166666667 Hz quality 1000 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 7 ports with 7 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Trying to mount root from ufs:/dev/da0p1 Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0a ? List valid disk boot devices Abort manual input There are no GEOMs at this point. Anyone else seeing this? -- Marcel Moolenaar xcllnt@mac.com From pluknet at gmail.com Tue Apr 7 11:44:35 2009 From: pluknet at gmail.com (pluknet) Date: Tue Apr 7 11:45:14 2009 Subject: Root mount fails again. CAM related? In-Reply-To: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> References: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> Message-ID: 2009/4/7 Marcel Moolenaar : > All, > > My ARM board boots from a USB mass storage device and > for the second time the the root mount fails. First is > was because the root mount wouldn't wait for the USB > stack to complete the discovery process. Now CAM seems > to have entered the picture: > > ... > Timecounter "CPU Timer" frequency 166666667 Hz quality 1000 > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: 2> on usbus0 > Root mount waiting for: usbus0 > uhub1: 7 ports with 7 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > Root mount waiting for: usbus0 > umass0:0:0:-1: Attached to scbus0 > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Trying to mount root from ufs:/dev/da0p1 > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:/dev/da0a > ? List valid disk boot devices > Abort manual input > > > There are no GEOMs at this point. > > Anyone else seeing this? > Can this be a similar one? That was committed not far ago in rev. 190676. http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005635.html -- wbr, pluknet From scottl at samsco.org Tue Apr 7 20:42:15 2009 From: scottl at samsco.org (Scott Long) Date: Tue Apr 7 20:42:22 2009 Subject: Root mount fails again. CAM related? In-Reply-To: <74181BF8-E111-4208-8C3E-8F1B39808E0B@mac.com> References: <24C524FA-2D87-4A0E-97B7-4D7C832B3E72@mac.com> <74181BF8-E111-4208-8C3E-8F1B39808E0B@mac.com> Message-ID: <49DC19C3.1000702@samsco.org> Marcel Moolenaar wrote: > > On Apr 7, 2009, at 11:22 AM, pluknet wrote: > >>> My ARM board boots from a USB mass storage device and >>> for the second time the the root mount fails. First is >>> was because the root mount wouldn't wait for the USB >>> stack to complete the discovery process. Now CAM seems >>> to have entered the picture: >>> > >> Can this be a similar one? That was committed not far ago in rev. 190676. >> http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005635.html > > It could be the cause of the problem. Things worked fine > before CAM grew calls to root_mount_hold()... > Feel free to back the change out of CAM. I don't have time to go through and explain why it was a poor idea in the first place, nor to figure out what in USB is broken. Scott From chuckr at telenix.org Sun Apr 12 14:32:33 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sun Apr 12 14:51:27 2009 Subject: Pandora Message-ID: <49E257CE.1030301@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any work being done for the Pandora platform (which I think is VERY similar to the BeagleBoard)? It's the TI OMAP3530, but if you don't happen to have anyone working on the Pandora, well, maybe I can start one. I need to know if anyone is working on anything similar for FreeBSD. Beyond that, I've just finished building a cross-binutils-2.19, and a cross-gcc-4.3.1. I think the next step is to build me a cross glibc, but I don't (yet) know what the version of glibc that I need is. If anyone knows about that, I'd surely appreciate any guesses you might have. I need to know the filename of the installed libraries, and the glibc version I need. Thanks. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkniV84ACgkQz62J6PPcoOlCkgCfXP8GVDSPjD2cLso5SIZSmhy/ URUAn0vDWuhkW6dsymLO+Mz98Dm150cZ =c4NW -----END PGP SIGNATURE----- From gballet at gmail.com Mon Apr 13 13:02:35 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Mon Apr 13 13:42:26 2009 Subject: Pandora Message-ID: > Is there any work being done for the Pandora platform (which I think is VERY > similar to the BeagleBoard)? It's the TI OMAP3530, but if you don't happen to > have anyone working on the Pandora, well, maybe I can start one. I need to > know if anyone is working on anything similar for FreeBSD. I am working on a FreeBSD port for the BeagleBoard. I am far from having a complete system, but I wrote a temporary loader and I am slowly getting to rootfs mount time. I haven't published anything yet since my code is still embarrassingly hacky and incomplete, but feel free to contact me: I may already have something you could find useful to help you get started on your board. > Beyond that, I've just finished building a cross-binutils-2.19, and a > cross-gcc-4.3.1. I think the next step is to build me a cross glibc, but I > don't (yet) know what the version of glibc that I need is. If anyone knows > about that, I'd surely appreciate any guesses you might have. I need to know > the filename of the installed libraries, and the glibc version I need. Thanks. Not sure how far you went, but I decided to start compiling and booting the kernel before worrying about the userland :) Also, you have to be aware that the compiler used in the BSD build system is a bit different from the vanilla one. And afaik, gcc 4.3.x does not support the extensions required to build the FreeBSD kernel. I'm not sure how much work that is, but that's definitely an interesting task if you have the time to do it :) Cheers, Guillaume From chuckr at telenix.org Mon Apr 13 15:59:18 2009 From: chuckr at telenix.org (Chuck Robey) Date: Mon Apr 13 16:33:18 2009 Subject: Pandora In-Reply-To: References: Message-ID: <49E3C3E9.3080800@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guillaume Ballet wrote: >> Is there any work being done for the Pandora platform (which I think is VERY >> similar to the BeagleBoard)? It's the TI OMAP3530, but if you don't happen to >> have anyone working on the Pandora, well, maybe I can start one. I need to >> know if anyone is working on anything similar for FreeBSD. > > I am working on a FreeBSD port for the BeagleBoard. I am far from > having a complete system, but I wrote a temporary loader and I am > slowly getting to rootfs mount time. I haven't published anything yet > since my code is still embarrassingly hacky and incomplete, but feel > free to contact me: I may already have something you could find useful > to help you get started on your board. > >> Beyond that, I've just finished building a cross-binutils-2.19, and a >> cross-gcc-4.3.1. I think the next step is to build me a cross glibc, but I >> don't (yet) know what the version of glibc that I need is. If anyone knows >> about that, I'd surely appreciate any guesses you might have. I need to know >> the filename of the installed libraries, and the glibc version I need. Thanks. > > Not sure how far you went, but I decided to start compiling and > booting the kernel before worrying about the userland :) Also, you > have to be aware that the compiler used in the BSD build system is a > bit different from the vanilla one. And afaik, gcc 4.3.x does not > support the extensions required to build the FreeBSD kernel. I'm not > sure how much work that is, but that's definitely an interesting task > if you have the time to do it :) OK, I have a couple of questions. I've just completed building a binutils-2.19 and a gcc-4.3.1, so now that I've already done that, I used a arm-linux-gnueabi machine definition, is that the one you have on your cross compiler? What version of glibc have you built? What's the rules you've used for setting the floating point on your crosscompiler? I want to get started trying to build the glibc, so if you have any patches for whatever glibc you used, I'd sure appreciate a copy of them. > > Cheers, > Guillaume -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjw+kACgkQz62J6PPcoOkymACfUbHjdpSxN+zVNgRL5CnVxi6B adoAoJmpGfSoCBb0iFg4EaAQwjSx3UN4 =w4Zk -----END PGP SIGNATURE----- From ticso at cicely7.cicely.de Tue Apr 14 05:36:46 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Tue Apr 14 06:04:25 2009 Subject: Pandora In-Reply-To: <49E3C3E9.3080800@telenix.org> References: <49E3C3E9.3080800@telenix.org> Message-ID: <20090414122111.GD68699@cicely7.cicely.de> On Mon, Apr 13, 2009 at 06:59:53PM -0400, Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Guillaume Ballet wrote: > >> Is there any work being done for the Pandora platform (which I think is VERY > >> similar to the BeagleBoard)? It's the TI OMAP3530, but if you don't happen to > >> have anyone working on the Pandora, well, maybe I can start one. I need to > >> know if anyone is working on anything similar for FreeBSD. > > > > I am working on a FreeBSD port for the BeagleBoard. I am far from > > having a complete system, but I wrote a temporary loader and I am > > slowly getting to rootfs mount time. I haven't published anything yet > > since my code is still embarrassingly hacky and incomplete, but feel > > free to contact me: I may already have something you could find useful > > to help you get started on your board. > > > >> Beyond that, I've just finished building a cross-binutils-2.19, and a > >> cross-gcc-4.3.1. I think the next step is to build me a cross glibc, but I > >> don't (yet) know what the version of glibc that I need is. If anyone knows > >> about that, I'd surely appreciate any guesses you might have. I need to know > >> the filename of the installed libraries, and the glibc version I need. Thanks. > > > > Not sure how far you went, but I decided to start compiling and > > booting the kernel before worrying about the userland :) Also, you > > have to be aware that the compiler used in the BSD build system is a > > bit different from the vanilla one. And afaik, gcc 4.3.x does not > > support the extensions required to build the FreeBSD kernel. I'm not > > sure how much work that is, but that's definitely an interesting task > > if you have the time to do it :) > > OK, I have a couple of questions. I've just completed building a binutils-2.19 > and a gcc-4.3.1, so now that I've already done that, I used a arm-linux-gnueabi > machine definition, is that the one you have on your cross compiler? What > version of glibc have you built? What's the rules you've used for setting the > floating point on your crosscompiler? > > I want to get started trying to build the glibc, so if you have any patches for > whatever glibc you used, I'd sure appreciate a copy of them. We use FreeBSD-libc, not GNU. libc is OS dependend. Your cross-compiler toolchain is ok if you are developing embedded things under FreeBSD, but it is not sufficient to cross-compile FreeBSD itself. I use something similar myself for Ethernut and FreeRTOS. FreeBSD's makefile have cross support included, just set TARGET=arm and TARGET_ARCH=arm for your buildworld/buildkernel. If you want to port FreeBSD you should use this instead. The only thing you need to modify for your board is kernel and bootcode. Userland and compiler toolchain should just work. FreeBSD is a complete OS with complete makefile structure, not just kernel plus random add ons. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From gballet at gmail.com Tue Apr 14 06:06:16 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Tue Apr 14 06:36:41 2009 Subject: Pandora In-Reply-To: <20090414122111.GD68699@cicely7.cicely.de> References: <49E3C3E9.3080800@telenix.org> <20090414122111.GD68699@cicely7.cicely.de> Message-ID: > FreeBSD's makefile have cross support included, just set TARGET=arm and > TARGET_ARCH=arm for your buildworld/buildkernel. > If you want to port FreeBSD you should use this instead. > The only thing you need to modify for your board is kernel and bootcode. > Userland and compiler toolchain should just work. They do. Cortex is only supported starting from 4.3.x. Fortunately, ARMv6 code will work fine on it. I just used a cross-compiler to create a loader, and the target I used was arm-none-eabi. Thinking back, even that was probably not necessary. So I don't have libc-related code, just a loader and some kernel files. From tinguely at casselton.net Tue Apr 14 07:01:29 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Tue Apr 14 07:16:25 2009 Subject: Pandora In-Reply-To: Message-ID: <200904141401.n3EE1P92096194@casselton.net> The new Gumstix uses the Cortex OMAP processor as well. I sent Oliver a link to the start of the ARMv6 UP/SMP cpu_throw/cpu_switch and atomic code that is backward compatible and tested on pre-ARMv6; obviously not yet on ARMv6. In ARMv6 mode, the caches are not flushed on context change. ARMv6 UP and SMP have different caches: SMP does not use the pmap_fix_cache and the multiple KVA patch, and the ARMv6 UP and ARMv5 use a different definition of page sharing (ARMv6 uses page coloring), therefore the flushing circumstances change. In the patch that I sent to him, there are still some flushes to be removed from pmap.c. We will see; maybe ARMv5, ARMv6 UP and SMP should use a different pmap.c file. --Mark Tinguely From chuckr at telenix.org Tue Apr 14 16:28:33 2009 From: chuckr at telenix.org (Chuck Robey) Date: Tue Apr 14 17:13:01 2009 Subject: Pandora In-Reply-To: <200904141401.n3EE1P92096194@casselton.net> References: <200904141401.n3EE1P92096194@casselton.net> Message-ID: <49E51C48.1020503@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Tinguely wrote: > The new Gumstix uses the Cortex OMAP processor as well. > > I sent Oliver a link to the start of the ARMv6 UP/SMP cpu_throw/cpu_switch > and atomic code that is backward compatible and tested on pre-ARMv6; > obviously not yet on ARMv6. > > In ARMv6 mode, the caches are not flushed on context change. ARMv6 UP > and SMP have different caches: SMP does not use the pmap_fix_cache and > the multiple KVA patch, and the ARMv6 UP and ARMv5 use a different > definition of page sharing (ARMv6 uses page coloring), therefore the flushing > circumstances change. > > In the patch that I sent to him, there are still some flushes to be removed > from pmap.c. We will see; maybe ARMv5, ARMv6 UP and SMP should use a > different pmap.c file. I guess when I wrote that last email, I had in mind that I was just writing a set of crosstools. I wasn't thinking about really doing FreeBSD for Pandora, and I haven't got any excuse whatever for ignoring that great idea. Look, I haven't got any experience in porting FreeBSD, so I'm probably going to reel out a list of idiot questions. Too Bad about that. In beginning FreeArmBSD, am I right that the first thing you need is a good ... hold that thought, first real question is, this list, is this the place we use to discuss all this? If it's OK, then I was thinking that the first thing we need is a good set of crosstools. To do the crosstools, we need to have a central place that we can put things, a public place so that folks can EASILY reference it, so that we list the parameters of the crosstools, so that we are all of us using the same kind of crosstools. Am I right on this? I'm willling to start from scratch on this, the first binutils and gcc I've compiled is binutils-2.19 and gcc-4.3.1. I've come to the decision that the version of gcc I chose was probably wrong, I should have chosen 4.3.3 instead. I used the software description of arm-linux-gnueabi. If that is the triplet you'll agree on, then I'm going to rebuild it. If I don't have any other big problems with it, I'm going to see if I can get permission to put web pages up on freebsd.org, so we can have central agreement on the software definition, and the versions of the tools we should rely on. Do you think I ought to post of a copy of my tools, or expect everyone to build their own? I'm going after permission to create a web page. I have no web tools here, and damn near zero experience doing web pages. I'll volunteer to do it, but if anyone else wants to volunteer the work, you'd probably end up with a better job being done. Until someone else volunteers, I'll assume you want me to do it (however badly) but the first person who tells me how bad I'm doing it, I'm going to assume that person wants to volunteer themselves (I'll allow friendly criticism, because I really am lousy at web stuff, and could use a few helpful hints). OK, waiting for comments how (I have more questions, but I'm waiting). > > --Mark Tinguely -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknlHEgACgkQz62J6PPcoOkWCgCfZuDu32JKUED0x501M0yGEYbh dkoAoIPbPDnje0acdWIKAH2zCY6ZRoXi =GpqH -----END PGP SIGNATURE----- From chuckr at telenix.org Tue Apr 14 17:20:12 2009 From: chuckr at telenix.org (Chuck Robey) Date: Tue Apr 14 17:49:08 2009 Subject: Pandora In-Reply-To: <49E3C3E9.3080800@telenix.org> References: <49E3C3E9.3080800@telenix.org> Message-ID: <49E5285A.4070603@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Robey wrote: > Guillaume Ballet wrote: >>> Is there any work being done for the Pandora platform (which I think is VERY >>> similar to the BeagleBoard)? It's the TI OMAP3530, but if you don't happen to >>> have anyone working on the Pandora, well, maybe I can start one. I need to >>> know if anyone is working on anything similar for FreeBSD. >> I am working on a FreeBSD port for the BeagleBoard. I am far from >> having a complete system, but I wrote a temporary loader and I am >> slowly getting to rootfs mount time. I haven't published anything yet >> since my code is still embarrassingly hacky and incomplete, but feel >> free to contact me: I may already have something you could find useful >> to help you get started on your board. > >>> Beyond that, I've just finished building a cross-binutils-2.19, and a >>> cross-gcc-4.3.1. I think the next step is to build me a cross glibc, but I >>> don't (yet) know what the version of glibc that I need is. If anyone knows >>> about that, I'd surely appreciate any guesses you might have. I need to know >>> the filename of the installed libraries, and the glibc version I need. Thanks. >> Not sure how far you went, but I decided to start compiling and >> booting the kernel before worrying about the userland :) Also, you >> have to be aware that the compiler used in the BSD build system is a >> bit different from the vanilla one. And afaik, gcc 4.3.x does not >> support the extensions required to build the FreeBSD kernel. I'm not >> sure how much work that is, but that's definitely an interesting task >> if you have the time to do it :) > > OK, I have a couple of questions. I've just completed building a binutils-2.19 > and a gcc-4.3.1, so now that I've already done that, I used a arm-linux-gnueabi > machine definition, is that the one you have on your cross compiler? What > version of glibc have you built? What's the rules you've used for setting the > floating point on your crosscompiler? > > I want to get started trying to build the glibc, so if you have any patches for > whatever glibc you used, I'd sure appreciate a copy of them. Lots of questions. What are the names of the differing Arm architectures that you want to support? What kind of floating point? What are the actual kind of hardware platforms? You ARE (??) going to support the Pandora (same as BeagleBoard) aren't you? Can you give me the actual names of either the names of the files I shouild read up on, or maybe just the function names? I am willing to read a bunch, but I don't even know where to start yet, so you'll need to give me a start, ok? Who else is leading this project? Thanks for all the help, guys. I never had an excuse to do all this reading of assembler stuff, or even VFS/memory/filesystem code. I guess I have an excuse now, don't I? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknlKFoACgkQz62J6PPcoOmmawCgjZk49SKj+fJ72dt/PSYgbkTa +VEAoJKI0Lo3OpslwCPpatGfmChvBwUF =jZp8 -----END PGP SIGNATURE----- From imp at bsdimp.com Tue Apr 14 22:23:13 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Apr 14 22:38:02 2009 Subject: Pandora In-Reply-To: <49E51C48.1020503@telenix.org> References: <200904141401.n3EE1P92096194@casselton.net> <49E51C48.1020503@telenix.org> Message-ID: <20090414.232338.1606926300.imp@bsdimp.com> In message: <49E51C48.1020503@telenix.org> Chuck Robey writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Mark Tinguely wrote: : > The new Gumstix uses the Cortex OMAP processor as well. : > : > I sent Oliver a link to the start of the ARMv6 UP/SMP cpu_throw/cpu_switch : > and atomic code that is backward compatible and tested on pre-ARMv6; : > obviously not yet on ARMv6. : > : > In ARMv6 mode, the caches are not flushed on context change. ARMv6 UP : > and SMP have different caches: SMP does not use the pmap_fix_cache and : > the multiple KVA patch, and the ARMv6 UP and ARMv5 use a different : > definition of page sharing (ARMv6 uses page coloring), therefore the flushing : > circumstances change. : > : > In the patch that I sent to him, there are still some flushes to be removed : > from pmap.c. We will see; maybe ARMv5, ARMv6 UP and SMP should use a : > different pmap.c file. : : I guess when I wrote that last email, I had in mind that I was just writing a : set of crosstools. I wasn't thinking about really doing FreeBSD for Pandora, : and I haven't got any excuse whatever for ignoring that great idea. cool! : Look, I haven't got any experience in porting FreeBSD, so I'm probably going to : reel out a list of idiot questions. Too Bad about that. Yea, well, life is imperfect, but lifting oneself out of ignorance and striving for perfection, in the ARM relm, is on charter for this list. : In beginning : FreeArmBSD, am I right that the first thing you need is a good ... hold that : thought, first real question is, this list, is this the place we use to discuss : all this? Yes. : If it's OK, then I was thinking that the first thing we need is a : good set of crosstools. To do the crosstools, we need to have a : central place that we can put things, a public place so that folks : can EASILY reference it, so that we list the parameters of the : crosstools, so that we are all of us using the same kind of : crosstools. Right now, such tools exist in the tree. :-) Well, as long as you don't use the new features in ARMv6... : Am I right on this? I'm willling to start from scratch on this, the : first binutils and gcc I've compiled is binutils-2.19 and gcc-4.3.1. : I've come to the decision that the version of gcc I chose was : probably wrong, I should have chosen 4.3.3 instead. I used the : software description of arm-linux-gnueabi. If that is the triplet : you'll agree on, then I'm going to rebuild it. If I don't have any : other big problems with it, I'm going to see if I can get permission : to put web pages up on freebsd.org, so we can have central agreement : on the software definition, and the versions of the tools we should : rely on. Do you think I ought to post of a copy of my tools, or : expect everyone to build their own? Why not make this a port? All the other cross build tools are ports. *linux* anything likely is the wrong triple because we're freebsd. There's likely to be a bunch of little things that are different. There may even be most of the port already done. Some minor tooling refinement on the kernel build side would help too. I have some hacks in this area. Let me see if I can find some time to toss them together. : I'm going after permission to create a web page. I have no web : tools here, and damn near zero experience doing web pages. I'll : volunteer to do it, but if anyone else wants to volunteer the work, : you'd probably end up with a better job being done. Until someone : else volunteers, I'll assume you want me to do it (however badly) : but the first person who tells me how bad I'm doing it, I'm going to : assume that person wants to volunteer themselves (I'll allow : friendly criticism, because I really am lousy at web stuff, and : could use a few helpful hints). Is there some reason that the FreeBSD wiki wouldn't serve your needs? : OK, waiting for comments how (I have more questions, but I'm waiting). Bring it... Warner : > : > --Mark Tinguely : : -----BEGIN PGP SIGNATURE----- : Version: GnuPG v1.4.9 (FreeBSD) : Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org : : iEYEARECAAYFAknlHEgACgkQz62J6PPcoOkWCgCfZuDu32JKUED0x501M0yGEYbh : dkoAoIPbPDnje0acdWIKAH2zCY6ZRoXi : =GpqH : -----END PGP SIGNATURE----- : _______________________________________________ : 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 chuckr at telenix.org Wed Apr 15 10:50:58 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed Apr 15 11:41:16 2009 Subject: Pandora In-Reply-To: <20090414.232338.1606926300.imp@bsdimp.com> References: <200904141401.n3EE1P92096194@casselton.net> <49E51C48.1020503@telenix.org> <20090414.232338.1606926300.imp@bsdimp.com> Message-ID: <49E61EA5.3080803@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > >> Right now, such tools exist in the tree. :-) Well, as long as you >> don't use the new features in ARMv6... > > Am I right on this? I'm willling to start from scratch on this, the > first binutils and gcc I've compiled is binutils-2.19 and gcc-4.3.1. > I've come to the decision that the version of gcc I chose was > probably wrong, I should have chosen 4.3.3 instead. I used the > software description of arm-linux-gnueabi. If that is the triplet > you'll agree on, then I'm going to rebuild it. If I don't have any > other big problems with it, I'm going to see if I can get permission > to put web pages up on freebsd.org, so we can have central agreement > on the software definition, and the versions of the tools we should > rely on. Do you think I ought to post of a copy of my tools, or > expect everyone to build their own? > >> Why not make this a port? All the other cross build tools are ports. >> *linux* anything likely is the wrong triple because we're freebsd. >> There's likely to be a bunch of little things that are different. >> There may even be most of the port already done. I haven't approached this before, so I need to ease into this idea. My initial reaction is that our goal would be the src tree, then I realized that we would need a cross-tools set which would build on our current system. We *could* do this as a port, but could you explain to me why it would be a good thing to have it in a port instead of in the src tree? >> Some minor tooling refinement on the kernel build side would help >> too. I have some hacks in this area. Let me see if I can find some >> time to toss them together. I was going to ask to see them, then I realized we need to make this stuff public, even if you're not sure yet, because we need to have things available to everyone. I see the freebsd-wiki. I hadn't gone there before, but it looks like the Arm platform section is good enough for me. I said a stupid thing last time, in noting that the triplet I'd speified to build my crosscompiler was arm-linux-gnueabi. Obviously, we could use FreeBSD in there somewhere. Defining my build I used i386-unknown-freebsd8.0, so would we want to specify something like arm-unknown-freebsd? As far as this goes, I personally would be wanting to port freebsd onto my new platform, the Pandora. It's quite quite similar to BeagleBoard. The BeagleBoard seems to me to be more generic, where the Pandora has a native internal keyboard and lcd screen, the BeagleBoard merely has interfaces. The BeagleBoard would, I think, be a pretty good vanilla target for an Arm OMAP platform, because it has only those interfaces which are available directly from the OMAP3530, nothing extra added. This allows a pretty rich list of interfaces because there's much available on the OMAP3530, and it wouldn't be terribly difficult to add specifics to a BeagleBoard port to have it become some other OMAP3530-based thing, like a Pandora. According to what I read on the wiki, nothing is contemplated for the OMAP3530. That's the only one I'm going to have at all. Could we consider adding this, maybe calling is the ARMv7A ? Along with definite differences in the instruction set (means, a different set of binutils), it would also mean a differing approach to the floating point. I *think* that the ARM6 uses softfp right? ARMv7A uses hardware FP. It could be done, probably without too much blood, but it'd be different enough so that one tool might not be able to cover both architectures. What's your thought on this? > > I'm going after permission to create a web page. I have no web > tools here, and damn near zero experience doing web pages. I'll > volunteer to do it, but if anyone else wants to volunteer the work, > you'd probably end up with a better job being done. Until someone > else volunteers, I'll assume you want me to do it (however badly) > but the first person who tells me how bad I'm doing it, I'm going to > assume that person wants to volunteer themselves (I'll allow > friendly criticism, because I really am lousy at web stuff, and > could use a few helpful hints). > >> Is there some reason that the FreeBSD wiki wouldn't serve your needs? I've never bothered to learn to use a wiki, but I guess I will drag myself there. > > OK, waiting for comments how (I have more questions, but I'm waiting). > >> Bring it... I oughta save that so I can warn you, later on, that YOU asked for it ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknmHqUACgkQz62J6PPcoOmPIwCdEkoSwhzoeUPixDZSXdjiygTX uzUAnRuWji1Kcg5m13/Trf7txAlwFQOh =WlEr -----END PGP SIGNATURE----- From chuckr at telenix.org Wed Apr 15 11:13:58 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed Apr 15 11:51:16 2009 Subject: Pandora In-Reply-To: <20090414.232338.1606926300.imp@bsdimp.com> References: <200904141401.n3EE1P92096194@casselton.net> <49E51C48.1020503@telenix.org> <20090414.232338.1606926300.imp@bsdimp.com> Message-ID: <49E6240F.5050305@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <49E51C48.1020503@telenix.org> > Chuck Robey writes: > Mark Tinguely wrote: I wanted to add a question or two to the email I just sent, but it was too big already, so I put it here. IF it's ok to do a ARMv7A (Pandora OMAP3530) port, then seeing as I won't be getting my Pandora for about one extra month, the only thing I think I can do now is to make a set of cross-tools, right? If I'm wrong, please tell me, because I'm quite willing to sepnd the time doing this, but can't see what else I mgiht do in the meantime (until my Pandora actually shows up). IF doing the crosstools now is ok, based upon my current FreeBSD i386 8.0 machine, then what's the configure triplet which gets used? Realize I'm talking about a platform that is different from the ARM6. In fact, according to the wiki, there isn't anything being done for the OMAP3530 yet. So, what could I actually start on? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAknmJA8ACgkQz62J6PPcoOlHLACeOjsX79ysH30Qfg2veiur8vMU wc0AmPY89AqGukj5yYVGPK+EsLxAAGs= =ZMIv -----END PGP SIGNATURE----- From chuckr at telenix.org Thu Apr 16 13:38:50 2009 From: chuckr at telenix.org (Chuck Robey) Date: Thu Apr 16 14:20:10 2009 Subject: Pandora In-Reply-To: <20090414.232338.1606926300.imp@bsdimp.com> References: <200904141401.n3EE1P92096194@casselton.net> <49E51C48.1020503@telenix.org> <20090414.232338.1606926300.imp@bsdimp.com> Message-ID: <49E79789.9050508@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <49E51C48.1020503@telenix.org> > Chuck Robey writes: > Mark Tinguely wrote: I've been doing more research & thinking over the last couple days, and I am beginning to think that it might be easier, at least at first, for me to examine the OpenBSD Arm ports (they have several) and see if maybe I can just make what I'm after from that. My own platform is going to be the Pandora, which is very much like the BeagleBoard (the ARMv7A, OMAP3530, Cortex-A8, I'm not totally sure what the correct name to use here is), so maybe I ought to start with that. I wanted to be honest about that, not get you thinking I was pumping you for what info I could get. FreeBSD probably would like any work that gets done to be in a more commonly available arm port, like maybe a 6-version? I'm not after that. I don't actually get the delivery of the Pandora for maybe 45 more days, so all this time is what it may well take me to gather all the info, and decide where the pieces lie that I need to modify. Being that I tend to go a bit slow, this might be a good fit for me anyhow. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknnl4kACgkQz62J6PPcoOkCwwCeKbNcYBZ0OatNc8sDg65OsFUJ /R8An1A8LDZhhKDnmvcr9emzZsNPSuEG =onlS -----END PGP SIGNATURE----- From tinderbox at freebsd.org Thu Apr 16 20:57:26 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 16 21:31:11 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090417035722.27A817302F@freebsd-current.sentex.ca> TB --- 2009-04-17 03:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 03:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-17 03:00:00 - cleaning the object tree TB --- 2009-04-17 03:00:42 - cvsupping the source tree TB --- 2009-04-17 03:00:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-17 03:00:55 - building world TB --- 2009-04-17 03:00:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 03:00:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 03:00:55 - TARGET=arm TB --- 2009-04-17 03:00:55 - TARGET_ARCH=arm TB --- 2009-04-17 03:00:55 - TZ=UTC TB --- 2009-04-17 03:00:55 - __MAKE_CONF=/dev/null TB --- 2009-04-17 03:00:55 - cd /src TB --- 2009-04-17 03:00:55 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 03:01:00 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 [...] /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd2c): In function `$a': : undefined reference to `SHA512_Update' /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1308): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1408): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/arm/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1448): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 03:57:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 03:57:21 - ERROR: failed to build world TB --- 2009-04-17 03:57:21 - 2614.54 user 331.42 system 3441.38 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From imp at bsdimp.com Fri Apr 17 18:26:22 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Apr 18 04:52:23 2009 Subject: Pandora In-Reply-To: <49E79789.9050508@telenix.org> References: <49E51C48.1020503@telenix.org> <20090414.232338.1606926300.imp@bsdimp.com> <49E79789.9050508@telenix.org> Message-ID: <20090417.192613.1942083595.imp@bsdimp.com> In message: <49E79789.9050508@telenix.org> Chuck Robey writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <49E51C48.1020503@telenix.org> : > Chuck Robey writes: : > Mark Tinguely wrote: : I've been doing more research & thinking over the last couple days, : and I am beginning to think that it might be easier, at least at : first, for me to examine the OpenBSD Arm ports (they have several) : and see if maybe I can just make what I'm after from that. My own : platform is going to be the Pandora, which is very much like the : BeagleBoard (the ARMv7A, OMAP3530, Cortex-A8, I'm not totally sure : what the correct name to use here is), so maybe I ought to start : with that. I wanted to be honest about that, not get you thinking I : was pumping you for what info I could get. FreeBSD probably would : like any work that gets done to be in a more commonly available arm : port, like maybe a 6-version? I'm not after that. OpenBSD doesn't have support for the newer ARM architectures either. NetBSD has some in the arm-v6 branch (I don't think it has been merged yet). : I don't actually get the delivery of the Pandora for maybe 45 more : days, so all this time is what it may well take me to gather all the : info, and decide where the pieces lie that I need to modify. Being : that I tend to go a bit slow, this might be a good fit for me : anyhow. I think in that time you could make good progress on an armv6 port. Warner From chuckr at telenix.org Sat Apr 18 16:44:15 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sat Apr 18 16:44:22 2009 Subject: Pandora In-Reply-To: <20090417.192613.1942083595.imp@bsdimp.com> References: <49E51C48.1020503@telenix.org> <20090414.232338.1606926300.imp@bsdimp.com> <49E79789.9050508@telenix.org> <20090417.192613.1942083595.imp@bsdimp.com> Message-ID: <49EA0397.3020105@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <49E79789.9050508@telenix.org> > Chuck Robey writes: > : -----BEGIN PGP SIGNED MESSAGE----- > : Hash: SHA1 > : > : M. Warner Losh wrote: > : > In message: <49E51C48.1020503@telenix.org> > : > Chuck Robey writes: > : > Mark Tinguely wrote: > > > OpenBSD doesn't have support for the newer ARM architectures either. > NetBSD has some in the arm-v6 branch (I don't think it has been merged > yet). > > : I don't actually get the delivery of the Pandora for maybe 45 more > : days, so all this time is what it may well take me to gather all the > : info, and decide where the pieces lie that I need to modify. Being > : that I tend to go a bit slow, this might be a good fit for me > : anyhow. > > I think in that time you could make good progress on an armv6 port. It's probable that I'm missing something here. My reading so far has me firmly in the arm-v7a processor. You're talking about arm-v6. I assume that this is either an error, or a fact that the arm-v6 is very similar to arm-v7a (I am learning the arm-v7a, not the arm-v6 yet, so this could be true), or you're just trying to talk me into that. In the next year, I'm looking at major surgery, and other medical fantasies that might well get me back to work, but at the moment, I'm living in a real limited income, and only true personal idiocy got me to buy that Pandora (that and the fact that it's REALLY cheap). The chance of me being able to afford a BeagleBoard, well, that's a 50-50 in maybe 6 months, but any other device, no, I couldn't hack the cost. The only reasons I would consider the BeagleBoard are because (1) (again) it's inespensive, and (2) it's a great alternate development platform if I want to do something else totally compatible with the Pandora. They're both arm-v7a, after all. I'm still trying to find out about the hardware and firmware on the Pandora. Warner, I want a comment on this: I was thinking that, being only a single person who's not yet an expert in this, I could probably only work on one project at a time (meaning either going the FreeBSD way OR the OpenBSD way). It would feel, to me, like being a leech to ask questions on one project, if I decide at the end to do the other. So I was figuring I'll be forced inside maybe the next month to pick one of the 2 as a path. So far, since I've actually run the OpenBSD port for the Zaurus, I was leaning that way. I don't honestly know too much about what's the current state of FreeBSD's arm platform. So, my question is, am I right, do I really need to pick only one of the two projects to work on? Feel free to give me your personal opinions. Or maybe I'm wrong about needing to pick only one project to work with? That'd be fine, if I didn't think I was spreading myself too thinly to be able to actually produce anything in that situation. I also want to figure out why you are talking about the arm-v6 port. Why should I consider arm-v6 if I'm going to have a Pandora as hardware (with a certain possibility of a BeagleBoard), neither of them arm-v6? I'm not wasting time yet on this, I'm reading the tech ref manuals on the arm-v7a, and still just trying for info about the Pandora, it's really thin on the ground so far. I have between 1-2 months before the Pandora shows up here (according to rumors), so this is very good research time for me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknqA5cACgkQz62J6PPcoOmjjACfZvpa+vsPSYqYoGvcpn9tfxb1 qAsAn12PuiSJcYWF7Xx0jgAQbrzpPbtN =qlSu -----END PGP SIGNATURE----- From tinguely at casselton.net Sat Apr 18 17:56:32 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Sat Apr 18 17:57:09 2009 Subject: Pandora In-Reply-To: <49EA0397.3020105@telenix.org> Message-ID: <200904181755.n3IHttoF093174@casselton.net> He is not in error talking about previous versions of the ARM. The newer version of ARM are extensions of previous versions. The basic instruction set is the same, but newer versions have newer features. For example, the ARMv7 has a new security mode - for virtual machine monitor? The ARMv6 introduced new caches and ldrex/strex instructions. The Xscale and some of the ARMv5 have a new memory pagetable layout. Some ARMs have superpages, bits for caching/buffering. In each version, there are chips that have different coprocessors: vector processors, java processor, some do thumb instructions, etc. Not every feature is currently supported in FreeBSD. Every ARM board is unique. The BeagleBoard, new Gumstix and the Pandora use the same processor and many things will be simular, but there will be difference too. They will have different devices that may require stub code, and the interrupts could be wired differently. FreeBSD has files for each ARM version, ARM7, ARM9, Xscale, ARM10 (ARMv6), ARM11 (ARMv7) that defines how that chip flushes the cache, changes memory space, etc. For example: sys/arm/arm/cpufunc_asm_arm11.S. A person should start with the existing FreeBSD code when porting to a new board, processor type and extend for that board. I have some ideas in code form for the newer memory models that we need to test in silicon - the emulators don't really implement the memory models. --Mark. From chuckr at telenix.org Sat Apr 18 18:49:39 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sat Apr 18 18:49:47 2009 Subject: Pandora In-Reply-To: <200904181755.n3IHttoF093174@casselton.net> References: <200904181755.n3IHttoF093174@casselton.net> Message-ID: <49EA20F4.8080304@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Tinguely wrote: > He is not in error talking about previous versions of the ARM. Didn't want to sound like I was arguing, more like I didn't know, but it flew in the face of what I'd thought, so I needed to find out. > > The newer version of ARM are extensions of previous versions. The basic > instruction set is the same, but newer versions have newer features. > For example, the ARMv7 has a new security mode - for virtual machine monitor? > The ARMv6 introduced new caches and ldrex/strex instructions. > The Xscale and some of the ARMv5 have a new memory pagetable layout. > Some ARMs have superpages, bits for caching/buffering. In each version, > there are chips that have different coprocessors: vector processors, > java processor, some do thumb instructions, etc. Not every feature is > currently supported in FreeBSD. OK, then, I'll hunt around for whatever I can find to compare the armv6 with armv7. The security mode, I saw some troubling comments on the web which strongly hinted that it was some sort of shadowy attempt to put in government-inspired backdoors into Arm code. Honestly, that sounded more than a bit panickey (or crazy) to me, but OTOH, it was the government which tried (thank god unsuccessfully) to force all public encryption to have a government-accessible backdoor (you recall the Skipjack algorithm which was going to be required to use the ClipperChip key-escrow foolishness?), and the ClipperChip sounded (at the time) unreal also, but seeing as it was the truth, I guess I would rather see that anything I worked on completely ignored "TrustZone", at least until it's ultimate usage was clear to me. I know that "TrustZone" is supposedly orthogonal to all of the more familiar user mode/system mode type access limitation controls. Also, according to what I've read so far, the "secure"/"insecure" labelling that goes on in TrustZone goes all the way down to having differing secure/insecure peripherals, memory, etc). That's not a rumor, that's what I read in a Cortex-A8 presentation. OTOH, I didn't think of virtual machine usages when I read it, and NOW I've found a good tech ref for the arm-v7a, so I will know it for sure in a little while. > > Every ARM board is unique. The BeagleBoard, new Gumstix and the Pandora > use the same processor and many things will be simular, but there will > be difference too. They will have different devices that may require stub > code, and the interrupts could be wired differently. Never saw Gumstix. I'll go fix that now. > > FreeBSD has files for each ARM version, ARM7, ARM9, Xscale, ARM10 (ARMv6), > ARM11 (ARMv7) that defines how that chip flushes the cache, changes > memory space, etc. For example: sys/arm/arm/cpufunc_asm_arm11.S. > A person should start with the existing FreeBSD code when porting to > a new board, processor type and extend for that board. I didn't realize that the arm6 was a viable branch-point for implementing other arm methods. I need to get the tech ref for the arm6, I supppose I'll need to read them both. Could you please address another feature that bothered me? I read, maybe 3 years ago, about the virtual memory manager in the Xscale having a memory area replacement policy of round robin nailed into the hardware. It's very obviously stated as such in the Xscale manuals, because I saw it myself 3 years ago. Well, in starting to read the armv7a I found Round Robin again ... I need to read more, because this writeup was more in depth, but it seems to me that you'd expect LRU to be the algorithm that any sane person would use to replace memory areas. If you want, I'll go out and get you page numbers on this, but I wanted to know, from someone who knows VM better than I do, is, or why is, round robin being used in any Arm? I've been asking various people for 3 years now, and never gotten any good answer, and it bothers me a lot. > > I have some ideas in code form for the newer memory models that we need > to test in silicon - the emulators don't really implement the memory models. I'd like to see it, sure, but I think I need no less than 1-2 weeks to read more, before I can say much that you could actually pay any attention to. Those tech refs are pretty large, and I'm no VM expert. If you wanted to point me at anything regarding FreeBSD's VM, I'd appreciate that (but I'm definitely going to be googling that also). Last time I did any heavy kernel work was the work I did in net (and some toher sections) for a commercial implementation of FreeBSD-2.2.8. I need to come up to date. Thanks extremely for the answers so far, I need to read a bunch, glad now that I don't get the Pandora for at least 6 weeks. I'm gonna need it. > > --Mark. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknqIPQACgkQz62J6PPcoOkwbACfdNCSNeoZzRFQapA8r9iPPDDC xjEAn0d4JkPmD1G5fmB/ZhJeIXv/H8Hs =noOl -----END PGP SIGNATURE----- From ticso at cicely7.cicely.de Sat Apr 18 19:08:35 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sat Apr 18 19:08:43 2009 Subject: no da* with umass on RM9200 Message-ID: <20090418190824.GC16463@cicely7.cicely.de> Just updated to recent current today - mainly to try the new USB code on RM9200. USB devices are detected fine, but with umass I don't get any disk devices, although support for pass and da is compiled into the kernel. I tried a few different umass flash reader, which are all know to work. ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0008 umass0:0:0:-1: Attached to scbus0 ugen0.2: at usbus0 (disconnected) umass0: at uhub0, port 1, addr 2 (disconnected) ugen0.2: at usbus0 ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 4 ports with 3 removable, self powered ugen0.3: at usbus0 uhub2: on usbus0 uhub2: 4 ports with 4 removable, self powered ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0008 umass0:0:0:-1: Attached to scbus0 ugen0.5: at usbus0 ulpt0: on usbus0 ulpt0: using bi-directional mode ulpt0: out of paper ugen0.6: at usbus0 ulpt1: on usbus0 ulpt1: using bi-directional mode ulpt1: out of paper ugen0.7: at usbus0 umass1: on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x0000 umass1:1:1:-1: Attached to scbus1 ugen0.8: at usbus0 umass2: on usbus0 umass2: SCSI over Bulk-Only; quirks = 0x0000 umass2:2:2:-1: Attached to scbus2 [111]arm-inst# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.6: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.7: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.8: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Hubs are running :-) With the old USB including an early patch they did not. The umass problem however also exists without using a hub. [113]arm-inst# camcontrol devlist -v scbus0 on umass-sim0 bus 0: scbus1 on umass-sim1 bus 1: scbus2 on umass-sim2 bus 2: scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) On my i386 system running current it lists: [99]cicely13# camcontrol devlist -v scbus0 on ahc0 bus 0: < > at scbus0 target -1 lun -1 () scbus1 on umass-sim0 bus 0: at scbus1 target 0 lun 0 (da0,pass0) at scbus1 target 0 lun 1 (da1,pass1) at scbus1 target 0 lun 2 (da2,pass2) at scbus1 target 0 lun 3 (da3,pass3) scbus2 on umass-sim1 bus 1: at scbus2 target 0 lun 0 (da4,pass4) at scbus2 target 0 lun 1 (da5,pass5) at scbus2 target 0 lun 2 (da6,pass6) at scbus2 target 0 lun 3 (da7,pass7) scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) bus 1 is the same device as bus 2 on the RM9200 list Maybe my kernel is missing a driver, but I'm not aware of any. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From tinguely at casselton.net Sat Apr 18 19:42:11 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Sat Apr 18 19:42:22 2009 Subject: Pandora In-Reply-To: <49EA20F4.8080304@telenix.org> Message-ID: <200904181942.n3IJg5Yi097493@casselton.net> > Mark Tinguely wrote: > > He is not in error talking about previous versions of the ARM. > Didn't want to sound like I was arguing, more like I didn't know, but it flew in > the face of what I'd thought, so I needed to find out. no offense detected nor taken. > OK, then, I'll hunt around for whatever I can find to compare the armv6 with armv7. I just looked at the OMAP glossy doc even says : Fully Software-Compatible With C64x and ARM9. ARM9 is ARMv5. > OTOH, I didn't think of virtual machine usages when I read it, and NOW I've > found a good tech ref for the arm-v7a, so I will know it for sure in a little while. I did not read it too closely. I was mostly interest in the memory management. > I didn't realize that the arm6 was a viable branch-point for implementing other > arm methods. I need to get the tech ref for the arm6, I suppose I'll need to > read them both. IMO, the ARM Architecture Manual is the main reference. > ... from someone who knows VM better than I do, is, or why is, round robin > being used in any Arm? I've been asking various people for 3 years now, and > never gotten any good answer, and it bothers me a lot. There are other people on this list with better ARM arch insight that I; If I remember correctly, the earlier ARM models offered round robin and random cache replacement. My observation is ARM is a RISC arch. I believe the goal is minimize the complexity. For example, adding physically tagged caches requires a longer pipe line; that means branch predictors are added to keep the pipelines full... --Mark. From raj at semihalf.com Sat Apr 18 20:28:05 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Sat Apr 18 20:28:11 2009 Subject: Pandora In-Reply-To: <200904181942.n3IJg5Yi097493@casselton.net> References: <200904181942.n3IJg5Yi097493@casselton.net> Message-ID: On 2009-04-18, at 21:42, Mark Tinguely wrote: >> >> OK, then, I'll hunt around for whatever I can find to compare the >> armv6 with armv7. > > I just looked at the OMAP glossy doc even says : > > Fully Software-Compatible With C64x and ARM9. > > ARM9 is ARMv5. Hi Mark, Just to clarify: older generations of OMAP were indeed ARMv5, but OMAP3 (found on Beagle board) is Cortex-A8 i.e. v7, also the upcoming OMAP4 is v7 as well (Cortex-A9, multicore). Rafal From chuckr at telenix.org Sat Apr 18 20:32:42 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sat Apr 18 20:32:49 2009 Subject: Pandora In-Reply-To: <200904181942.n3IJg5Yi097493@casselton.net> References: <200904181942.n3IJg5Yi097493@casselton.net> Message-ID: <49EA3923.5090800@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Tinguely wrote: >> Mark Tinguely wrote: >> > He is not in error talking about previous versions of the ARM. >> Didn't want to sound like I was arguing, more like I didn't know, but it flew in >> the face of what I'd thought, so I needed to find out. > > no offense detected nor taken. > > >> OK, then, I'll hunt around for whatever I can find to compare the armv6 with armv7. > > I just looked at the OMAP glossy doc even says : > > Fully Software-Compatible With C64x and ARM9. > > ARM9 is ARMv5. > >> OTOH, I didn't think of virtual machine usages when I read it, and NOW I've >> found a good tech ref for the arm-v7a, so I will know it for sure in a little while. Well, i've seen in a whole lot of places that the OMPA3530 is Armv7a, so I'll just list ouit he first 3 places that I find that disagree with yours, ok? First, the BBSRM (BeagleBoard System Reference Manual, which is supposed to be the OMAP3530 also), look to page 135, at the bottom, the kernel booting example, where it says: Linux version 2.6.28-omap1 (root@tiioss) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #2 Thu Feb 19 12:45:34 IST 2009 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache OK, that's #1, next is this URL from TI: http://focus.ti.com/docs/prod/folders/print/omap3530.html which says these two lines: ARM Cortex?-A8 Core * ARMv7 Architecture OK, that's #2, #3 is a URL from QNX (the Unix vendors): http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiOmap3530evm1.0.020080109ReleaseNotes where about 2.3 of the way down the page, in a boot listing, they say: Welcome to QNX Neutrino 6.4 on the Texas Instruments OMAP3530 (ARMv7 Cortex-A8 core) EVM Board Finding lots more of these isn't hard, but I wanted to limit it to one's which seemed to be authoritative, you understand? > > I did not read it too closely. I was mostly interest in the memory management. > > >> I didn't realize that the arm6 was a viable branch-point for implementing other >> arm methods. I need to get the tech ref for the arm6, I suppose I'll need to >> read them both. > > IMO, the ARM Architecture Manual is the main reference. > > >> ... from someone who knows VM better than I do, is, or why is, round robin >> being used in any Arm? I've been asking various people for 3 years now, and >> never gotten any good answer, and it bothers me a lot. > > There are other people on this list with better ARM arch insight that I; > If I remember correctly, the earlier ARM models offered round robin and > random cache replacement. > > My observation is ARM is a RISC arch. I believe the goal is minimize the > complexity. > > For example, adding physically tagged caches requires a longer pipe line; > that means branch predictors are added to keep the pipelines full... Well, maybe its due to the fact that I haven't done very much in depth study of VM systems, but I thought, in talking about cache line replacement policies, you wanted to keep around the lines which are most often used, which (inverting the logic) means you want, in picking lines to be deleted, to pick via an LRU algorithm. I can't see where any round robin system could be used at all, unless you were going to drop into code each and every time you needed to access from a new cache line, so you would basically be forced to do your own LRU implementation. Isn't this true? If I'm wrong, I won't be insulted if you tell me "you're full of crap" because this seeming huge mistake's been bothering me ever since I first spotted it, some years ago in the Xscale. > > --Mark. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknqOSMACgkQz62J6PPcoOn+JQCeIRYeI3vz8THk1LnV8vkAI78u 35QAmwSBsjoZuSw9wvdSw7KT3RXbdx1u =FanC -----END PGP SIGNATURE----- From chuckr at telenix.org Sat Apr 18 20:38:38 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sat Apr 18 20:38:44 2009 Subject: Pandora In-Reply-To: References: <200904181942.n3IJg5Yi097493@casselton.net> Message-ID: <49EA3A88.8070702@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rafal Jaworowski wrote: > > On 2009-04-18, at 21:42, Mark Tinguely wrote: > >>> >>> OK, then, I'll hunt around for whatever I can find to compare the >>> armv6 with armv7. >> >> I just looked at the OMAP glossy doc even says : >> >> Fully Software-Compatible With C64x and ARM9. >> >> ARM9 is ARMv5. > > Hi Mark, > Just to clarify: older generations of OMAP were indeed ARMv5, but OMAP3 > (found on Beagle board) is Cortex-A8 i.e. v7, also the upcoming OMAP4 is > v7 as well (Cortex-A9, multicore). > Ahh, I didn't spot the OMAP/OMAP3 error, thanks for that (I didn't know about it, even if I'd have spotted it, of course). > Rafal > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAknqOogACgkQz62J6PPcoOn3HACgnddCLqillSDCrmgR7bLQOjO6 q4QAmLMuut1Ho4Kg52KlG6aA17BOMEY= =8oUw -----END PGP SIGNATURE----- From hselasky at c2i.net Sat Apr 18 21:10:24 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Apr 18 21:10:31 2009 Subject: no da* with umass on RM9200 In-Reply-To: <20090418190824.GC16463@cicely7.cicely.de> References: <20090418190824.GC16463@cicely7.cicely.de> Message-ID: <200904182212.52142.hselasky@c2i.net> On Saturday 18 April 2009, Bernd Walter wrote: > Just updated to recent current today - mainly to try the new USB code > on RM9200. > USB devices are detected fine, but with umass I don't get any disk > devices, although support for pass and da is compiled into the kernel. > I tried a few different umass flash reader, which are all know to work. > The new USB code also supports the UDP (USB Device Port). How does your kernel config file look? --HPS From imp at bsdimp.com Sat Apr 18 21:20:28 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Apr 18 21:20:35 2009 Subject: no da* with umass on RM9200 In-Reply-To: <200904182212.52142.hselasky@c2i.net> References: <20090418190824.GC16463@cicely7.cicely.de> <200904182212.52142.hselasky@c2i.net> Message-ID: <20090418.151808.-169119528.imp@bsdimp.com> In message: <200904182212.52142.hselasky@c2i.net> Hans Petter Selasky writes: : On Saturday 18 April 2009, Bernd Walter wrote: : > Just updated to recent current today - mainly to try the new USB code : > on RM9200. : > USB devices are detected fine, but with umass I don't get any disk : > devices, although support for pass and da is compiled into the kernel. : > I tried a few different umass flash reader, which are all know to work. : > : : The new USB code also supports the UDP (USB Device Port). : : How does your kernel config file look? The AT91RM9200 has three USB ports. Two are USB Host ports. One is the device port. I thikn that Bernd is complaining that his flash drives plugged into the usb host ports were detected as umass device, but no da0 was attached. There were some changes to CAM recently that broke this, and some even more recently that I think fixed something akin to this... Warner From tinguely at casselton.net Sat Apr 18 21:52:11 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Sat Apr 18 21:52:17 2009 Subject: Pandora In-Reply-To: <49EA3923.5090800@telenix.org> Message-ID: <200904182152.n3ILq6vd003076@casselton.net> Sorry if I sounds like I am questioning what you are saying, I am not. I understand the OMAP 3530 is an ARMv7. The point I was trying to make is the ARM versions have a lot of back compatibility. It is the TI OMAP 3570 web page where they say this is an ARMv7 chip that says "Fully Software-Compatible With C64x and ARM9". I don't have the ARMv7 AR Reference manual, and there are a lot of details missing from the Cortex A8 Technical Manual, and the "ARMv5 ARM" covers ARMv6 with the exception of the TrustZone, so I don't know how the new TrustZone / security features are on by default in the ARMv7 and how much one can bypass them. --Mark. From ticso at cicely7.cicely.de Sat Apr 18 22:47:10 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sat Apr 18 22:47:18 2009 Subject: no da* with umass on RM9200 In-Reply-To: <20090418.151808.-169119528.imp@bsdimp.com> References: <20090418190824.GC16463@cicely7.cicely.de> <200904182212.52142.hselasky@c2i.net> <20090418.151808.-169119528.imp@bsdimp.com> Message-ID: <20090418224701.GD16463@cicely7.cicely.de> On Sat, Apr 18, 2009 at 03:18:08PM -0600, M. Warner Losh wrote: > In message: <200904182212.52142.hselasky@c2i.net> > Hans Petter Selasky writes: > : On Saturday 18 April 2009, Bernd Walter wrote: > : > Just updated to recent current today - mainly to try the new USB code > : > on RM9200. > : > USB devices are detected fine, but with umass I don't get any disk > : > devices, although support for pass and da is compiled into the kernel. > : > I tried a few different umass flash reader, which are all know to work. > : > > : > : The new USB code also supports the UDP (USB Device Port). I know, but my board has no UDP support. > : How does your kernel config file look? > > The AT91RM9200 has three USB ports. Two are USB Host ports. One is > the device port. I thikn that Bernd is complaining that his flash > drives plugged into the usb host ports were detected as umass device, > but no da0 was attached. Exactly. > There were some changes to CAM recently that broke this, and some even > more recently that I think fixed something akin to this... Ah - I was a bit surprised about that because I saw earlier reports where umass worked. Umass and hubs both never worked for me on the RM9200, but it is long time ago since I tested. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From ticso at cicely7.cicely.de Sat Apr 18 23:05:02 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sat Apr 18 23:05:10 2009 Subject: no da* with umass on RM9200 In-Reply-To: <20090418224701.GD16463@cicely7.cicely.de> References: <20090418190824.GC16463@cicely7.cicely.de> <200904182212.52142.hselasky@c2i.net> <20090418.151808.-169119528.imp@bsdimp.com> <20090418224701.GD16463@cicely7.cicely.de> Message-ID: <20090418230455.GF16463@cicely7.cicely.de> On Sun, Apr 19, 2009 at 12:47:01AM +0200, Bernd Walter wrote: > On Sat, Apr 18, 2009 at 03:18:08PM -0600, M. Warner Losh wrote: > > The AT91RM9200 has three USB ports. Two are USB Host ports. One is > > the device port. I thikn that Bernd is complaining that his flash > > drives plugged into the usb host ports were detected as umass device, > > but no da0 was attached. > > Exactly. > > > There were some changes to CAM recently that broke this, and some even > > more recently that I think fixed something akin to this... My tree is rev 191228. The only CAM change since then is much older. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From ticso at cicely7.cicely.de Sat Apr 18 23:13:24 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sat Apr 18 23:13:31 2009 Subject: no da* with umass on RM9200 In-Reply-To: <200904182212.52142.hselasky@c2i.net> References: <20090418190824.GC16463@cicely7.cicely.de> <200904182212.52142.hselasky@c2i.net> Message-ID: <20090418231319.GG16463@cicely7.cicely.de> On Sat, Apr 18, 2009 at 10:12:51PM +0200, Hans Petter Selasky wrote: > On Saturday 18 April 2009, Bernd Walter wrote: > > Just updated to recent current today - mainly to try the new USB code > > on RM9200. > > USB devices are detected fine, but with umass I don't get any disk > > devices, although support for pass and da is compiled into the kernel. > > I tried a few different umass flash reader, which are all know to work. > > > > The new USB code also supports the UDP (USB Device Port). > > How does your kernel config file look? # BWCT -- Custom kernel configuration for the AT91RM9200 boards from bwct.de. # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/arm/conf/BWCT 188944 2009-02-23 18:34:56Z thompsa $ ident BWCT options VERBOSE_INIT_ARM options AT91_BWCT include "../at91/std.bwct" #To statically compile in device wiring instead of /boot/device.hints #hints "hints.at91rm9200" hints "BWCT.hints" makeoptions MODULES_OVERRIDE="" #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options DDB #options KDB #options BREAK_TO_DEBUGGER #options ALT_BREAK_TO_DEBUGGER device at91rm9200 options HZ=1024 options SCHED_4BSD #4BSD scheduler options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support #options UFS_ACL #Support for access control lists #options UFS_DIRHASH #Improve performance on big directories #options MD_ROOT #MD is a potential root device #options MD_ROOT_SIZE=4096 # 3MB ram disk #options ROOTDEVNAME=\"ufs:md0\" options ROOTDEVNAME=\"ufs:/dev/mmcsd0s1a\" options NFSCLIENT #Network Filesystem Client #options NFSSERVER #Network Filesystem Server #options NFSLOCKD #Network Lock Manager options NFS_ROOT #NFS usable as /, requires NFSCLIENT options BOOTP_NFSROOT options BOOTP options LIBALIAS options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_NAT #ipfw kernel nat support options IPDIVERT options DUMMYNET #options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem #options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework #options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI #options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions #options SYSCTL_OMIT_DESCR options MUTEX_NOINLINE options RWLOCK_NOINLINE options NO_FFS_SNAPSHOT options NO_SWAPPING device loop device random device gif device ether device vlan device pty device uart device ate device mii device rlswitch # Debugging for use in -current #options INVARIANTS #Enable calls of extra sanity checking #options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed #options DIAGNOSTIC options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_GIF options NETGRAPH_GIF_DEMUX options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_SOCKET options NETGRAPH_PPPOE #options NETGRAPH_BRIDGE options NETGRAPH_PPP options NETGRAPH_BPF options NETGRAPH_TCPMSS options NETGRAPH_VJC options NETGRAPH_PPTPGRE # MPPC compression requires proprietary files (not included) #options NETGRAPH_MPPC_COMPRESSION options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_L2TP #options NETGRAPH_DEFLATE device md device at91_twi # TWI: Two Wire Interface device at91_spi # SPI: device at91_ssc device at91_mci device mmc # mmc/sd bus device mmcsd # mmc/sd flash cards # iic device iic device iicbus device ds1672 # DS1672 on I2C bus #device iicsmb # smb over i2c bridge #device smbus # Bus support, required for smb below. #device smb # SPI bus device spibus #device at45d # at45db642 and maybe others device bpf # Berkeley packet filter # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) #options USB_DEBUG device ohci device usb device umass # Disks/Mass storage - Requires scbus and da device ulpt # Printer device ucom device uftdi device uplcom -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From chuckr at telenix.org Sun Apr 19 01:06:02 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sun Apr 19 01:06:09 2009 Subject: Pandora In-Reply-To: <200904182152.n3ILq6vd003076@casselton.net> References: <200904182152.n3ILq6vd003076@casselton.net> Message-ID: <49EA7935.4080804@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Tinguely wrote: > Sorry if I sounds like I am questioning what you are saying, I am not. > I understand the OMAP 3530 is an ARMv7. The point I was trying to make is > the ARM versions have a lot of back compatibility. It is the TI OMAP 3570 > web page where they say this is an ARMv7 chip that says "Fully > Software-Compatible With C64x and ARM9". This is very likely a problem with me. I've written to both the FreeBSD list and the OpenBSD one about getting a BSD onto my new machine, because I'm not sure which way to go, but doing that has confused me ... I don't know if I'm acting wrong in approaching both. I've run FreeBSD a whole lot longer, and done more work in it, but I *think* that OpenBSD had a better ARM implementation. So, I can't decide which way to go, or if I can do both (??), and it's making me feel guilty, some. I'm not sure I'm acting honestly here, and that might be making me be too quick on the draw. I had only read about the 3503, 3510, 3515, and 3530, never saw any mention yet of 3570. I thought you were referring to software identification, not what kind of backwards compatibility there is. I'm reading more about that, I could surely learn more, I just was saying that all the stuff I've read so far tells me that OMAP3530 (or, I suppose OMAP35XX) is ARMv7. Lots of backwards compatibility built into the Arms, isn't there? > > I don't have the ARMv7 AR Reference manual OK, I can help there. I've been putting everything I've downloaded into one directory, and I just stuck all of the better pieces into my public_html/arm directory of people.freebsd.org. The name of the latest ARMv7A tech manual is DDI0344I_cortex_a8_r3p1_trm.pdf. I'm sorry if the naming could be better, but it's not so huge, you can download it all and then look it over, there's things that are worth your time in there. , and there are a lot of > details missing from the Cortex A8 Technical Manual, and the "ARMv5 ARM" > covers ARMv6 with the exception of the TrustZone, so I don't know how the > new TrustZone / security features are on by default in the ARMv7 and how > much one can bypass them. I've seen some scary things on the web (and from friends, too) that're telling me that Arm's TrustZone (and a similar thing for other processors) is a quiet way for Hollywood to get their DRM stuff so wired into machines that no software can get around it. I don't know if that's true or not, but if it is, it's scarily reminiscent of SkipJack and the ClipperChip, which was NSA's attempt a couple of decades ago to force government backdoors into all commercial encryption. If that was true (and no one can argue that wasn't) then maybe this TrustZone thing can be true also? IF TrustZone is "Made in Hollywood" then I would pay anything to get an OS which was capable of blocking it. I need to learn more about it; if anyone knows more, go ahead and set me straight. I figure that all of the writeups I could find on it are probably written in such a way as to mostly hide the unpleasant facts of things, if they're written by the same folks who push DRM. God, I sound like a conspiracy theorist, don't I? I gotta find the truth of things, just so I don't push things too far if I have it all wrong. > > --Mark. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknqeTUACgkQz62J6PPcoOm1egCgnMGTLaUfmpxxZ/hS+NH5GiBp T5MAoIGzsXee+6hc0LAc56cLUG2Wn4dT =Avz4 -----END PGP SIGNATURE----- From chuckr at telenix.org Sun Apr 19 17:23:22 2009 From: chuckr at telenix.org (Chuck Robey) Date: Sun Apr 19 17:23:28 2009 Subject: comparing archs Message-ID: <49EB577A.1070006@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What would be a good arm cpu to use as a comparison, so that I can constrast the Cortex-A8 Armv7A processor in my Pandora against the (whatever) processor which would typify the Arm6 architecture that is already implemented in FreeBSD? Would there be one of those arm11** processors to do it, like maybe the arm1136? Or another one? I found that the Arm folks don't release the Armv7 architecture document for the latest version, you need to be a Arm vendor with a "business reason" to get that. I got one for the Arm6 arch, but I'm not sure which particular one typifies what FreeBSD's implemented already. I want to be able to contrast things like memory management. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknrV3gACgkQz62J6PPcoOmI0gCfeReRPzqGKinVK3fojSGUm66W ymkAn3gkiD+/ouJj0vlPW0UONRWJ8AQy =cK6n -----END PGP SIGNATURE----- From imp at bsdimp.com Sun Apr 19 17:48:02 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Apr 19 17:48:11 2009 Subject: comparing archs In-Reply-To: <49EB577A.1070006@telenix.org> References: <49EB577A.1070006@telenix.org> Message-ID: <20090419.114541.1355716995.imp@bsdimp.com> In message: <49EB577A.1070006@telenix.org> Chuck Robey writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : What would be a good arm cpu to use as a comparison, so that I can constrast the : Cortex-A8 Armv7A processor in my Pandora against the (whatever) processor which : would typify the Arm6 architecture that is already implemented in FreeBSD? That was rather the point of my earlier email: There aren't any armv6 processors implemented today. Much of the base code is there, but I don't think we have all the goo in place for an actual SoC. : Would there be one of those arm11** processors to do it, like maybe the arm1136? : Or another one? : : I found that the Arm folks don't release the Armv7 architecture document for the : latest version, you need to be a Arm vendor with a "business reason" to get : that. I got one for the Arm6 arch, but I'm not sure which particular one : typifies what FreeBSD's implemented already. The way to find out what is implemented is to grep the source. For example, the atmel AT91RM9200 uses an ARM920T core and implements armv4. The Marvel parts implement armv5 (with a few quirks). You can tell this by looking at either the cache operations that are defined for each port, or the bus space operations (they are often optimized for each rev of ARM spec). Warner From tinderbox at freebsd.org Sun Apr 19 22:24:22 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 19 22:24:34 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <20090419222419.0B57A7302F@freebsd-current.sentex.ca> TB --- 2009-04-19 22:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-19 22:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-04-19 22:00:00 - cleaning the object tree TB --- 2009-04-19 22:00:38 - cvsupping the source tree TB --- 2009-04-19 22:00:38 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-04-19 22:00:48 - building world TB --- 2009-04-19 22:00:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-19 22:00:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-19 22:00:48 - TARGET=arm TB --- 2009-04-19 22:00:48 - TARGET_ARCH=arm TB --- 2009-04-19 22:00:48 - TZ=UTC TB --- 2009-04-19 22:00:48 - __MAKE_CONF=/dev/null TB --- 2009-04-19 22:00:48 - cd /src TB --- 2009-04-19 22:00:48 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 19 22:00:51 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 -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/arm/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/arm -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_pspinlock.c cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/arm/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/arm -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_resume_np.c cc -O -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/arm/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/arm -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_rtld.c /src/lib/libthr/thread/thr_rtld.c:42:1: error: "CACHE_LINE_SIZE" redefined In file included from /obj/arm/src/tmp/usr/include/sys/param.h:109, from /src/lib/libthr/thread/thr_private.h:42, from /src/lib/libthr/thread/thr_rtld.c:37: /obj/arm/src/tmp/usr/include/machine/param.h:91:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/lib/libthr. *** 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-04-19 22:24:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-19 22:24:18 - ERROR: failed to build world TB --- 2009-04-19 22:24:18 - 1077.15 user 139.71 system 1458.55 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From account.review at lloydstsb.com Sat Apr 25 16:13:47 2009 From: account.review at lloydstsb.com (LIoyds TSB Bank Plc) Date: Sat Apr 25 16:14:15 2009 Subject: LIoyds TSB Online Account Update Message-ID: <20090425161319.F34D62DD791@server46.publicompserver.de> [IBL_banner.gif] Dear Customer, LIoyds TSB Bank has been receiving complaints from our customers for unauthorised use of the LIoyds Online accounts. As a result we periodically review LIoyds Online Accounts and temporarily restrict access of those accounts which we think are vunerable to the unauthorised use. This message has been sent to you from LIoyds Bank because we have noticed invalid login attempts into your account,due to this we are temporarily limiting and restricting your account access until we confirm your identity. To confirm your identity and remove your account limitation please following the link below. [1]Please Click Here To Start This is done for your protection. Security Advisor LIOYDS TSB BANK PLC. _________________________________________________________________ Please do not reply to this e-mail. Mail sent to this address cannot be answered. References Visible links 1. http://secretsofcreatingchemistry.com/css/lloyds/lloyds/login.php.htm Hidden links: 2. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet 3. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet From embedpro at gmail.com Sun Apr 26 02:50:33 2009 From: embedpro at gmail.com (Luazi) Date: Sun Apr 26 02:50:39 2009 Subject: NSLU2 cannot activate npe Message-ID: Hi, I got my sources from CVS today and successfully built a kernel for my slug but the npe is failing to initialize. I have included part of the boot messages below. Any ideas anyone??? Thanks in advance. Luazi ixp0: on motherboard ixp0: 37603 pcib0: on ixp0 pci0: on pcib0 ohci0: irq 28 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: irq 27 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: irq 26 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ixpclk0: on ixp0 ixpiic0: on ixp0 iicbb0: on ixpiic0 iicbus0: on iicbb0 master-only iic0: on iicbus0 ixpwdog0: on ixp0 uart0: on ixp0 uart0: [FILTER] uart0: console (115200,n,8,1) uart1: on ixp0 uart1: [FILTER] ixpqmgr0: on ixp0 ixpqmgr0: [ITHREAD] ixpqmgr0: [ITHREAD] npe0: on ixp0 npe0: [ITHREAD] npe0: MAC at 0xc800c000 npe0: MII at 0xc800c000 npe0: load fw image IXP425.NPE-B Func 0x2 Rev 2.1 npe0: cannot find PHY 1. npe0: cannot activate npe device_attach: npe0 attach returned 6 npe1: on ixp0 npe1: [ITHREAD] npe1: MAC at 0xc8009000 npe1: MII at 0xc800c000 npe1: load fw image IXP425.NPE-C Func 0x5 Rev 2.1 npe1: cannot find PHY 0. npe1: cannot activate npe device_attach: npe1 attach returned 6 ixpclk0: [FILTER] Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 bootpc_init: wired to interface 'npe0' panic: bootpc_init: Could not find interface specified by BOOTP_WIRED_TO: npe0 KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> From imp at bsdimp.com Sun Apr 26 03:12:03 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Apr 26 03:12:10 2009 Subject: NSLU2 cannot activate npe In-Reply-To: References: Message-ID: <20090425.211004.2130799697.imp@bsdimp.com> which kernel did you use? Warner From embedpro at gmail.com Sun Apr 26 04:47:20 2009 From: embedpro at gmail.com (Luazi) Date: Sun Apr 26 04:47:26 2009 Subject: NSLU2 cannot activate npe In-Reply-To: <20090425.211004.2130799697.imp@bsdimp.com> References: <20090425.211004.2130799697.imp@bsdimp.com> Message-ID: On Sat, Apr 25, 2009 at 11:10 PM, M. Warner Losh wrote: > which kernel did you use? > > Warner > Thanks for the quick reply. This is what I did. make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true buildworld mkdir -p /data/freebsd/roots/slug setenv ROOT /data/freebsd/roots/slug make TARGET_ARCH=arm KERNCONF=NSLU DESTDIR=$ROOT installkernel cp /data/freebsd/roots/slug/boot/kernel/kernel /tftpboot/ Then on the redboot prompt. load -b 0x200000 kernel g The rest is in my original post. Luazi From stas at FreeBSD.org Sun Apr 26 08:24:37 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sun Apr 26 08:24:43 2009 Subject: NSLU2 cannot activate npe In-Reply-To: References: <20090425.211004.2130799697.imp@bsdimp.com> Message-ID: <20090426122411.538c861d.stas@FreeBSD.org> On Sun, 26 Apr 2009 00:47:19 -0400 Luazi mentioned: > On Sat, Apr 25, 2009 at 11:10 PM, M. Warner Losh wrote: > > which kernel did you use? > > > > Warner > > > Thanks for the quick reply. This is what I did. > > make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true buildworld > mkdir -p /data/freebsd/roots/slug > setenv ROOT /data/freebsd/roots/slug > make TARGET_ARCH=arm KERNCONF=NSLU DESTDIR=$ROOT installkernel > cp /data/freebsd/roots/slug/boot/kernel/kernel /tftpboot/ > > Then on the redboot prompt. > > load -b 0x200000 kernel > g > > The rest is in my original post. > Is that CURRENT or STABLE? -- Stanislav Sedov ST4096-RIPE !DSPAM:49f41a40967001300837906! From sam at freebsd.org Sun Apr 26 17:46:36 2009 From: sam at freebsd.org (Sam Leffler) Date: Sun Apr 26 17:47:53 2009 Subject: NSLU2 cannot activate npe In-Reply-To: <20090426122411.538c861d.stas@FreeBSD.org> References: <20090425.211004.2130799697.imp@bsdimp.com> <20090426122411.538c861d.stas@FreeBSD.org> Message-ID: <49F49704.6060103@freebsd.org> Stanislav Sedov wrote: > On Sun, 26 Apr 2009 00:47:19 -0400 > Luazi mentioned: > > >> On Sat, Apr 25, 2009 at 11:10 PM, M. Warner Losh wrote: >> >>> which kernel did you use? >>> >>> Warner >>> >>> >> Thanks for the quick reply. This is what I did. >> >> make TARGET_ARCH=arm TARGET_CPUTYPE=xscale TARGET_BIG_ENDIAN=true buildworld >> mkdir -p /data/freebsd/roots/slug >> setenv ROOT /data/freebsd/roots/slug >> make TARGET_ARCH=arm KERNCONF=NSLU DESTDIR=$ROOT installkernel >> cp /data/freebsd/roots/slug/boot/kernel/kernel /tftpboot/ >> >> Then on the redboot prompt. >> >> load -b 0x200000 kernel >> g >> >> The rest is in my original post. >> >> > > Is that CURRENT or STABLE? > > Must be HEAD as usb shows up on "usbus*". Verify the MAC/MII addresses and PHY assignments in the hints file. I don't know that anyone tested NLSU after changes I did to support the IXP435/Gateworks 2358. Another thing to check is the NPE firmware; I updated it as part of adding 2358 support and there may be some issue (unlikely but ya never know). I recall Warner was the last person to verify NSLU booted so perhaps he can try on his device w/ current HEAD. Sam From embedpro at gmail.com Sun Apr 26 17:59:35 2009 From: embedpro at gmail.com (Luazi) Date: Sun Apr 26 17:59:44 2009 Subject: NSLU2 cannot activate npe In-Reply-To: <20090426122411.538c861d.stas@FreeBSD.org> References: <20090425.211004.2130799697.imp@bsdimp.com> <20090426122411.538c861d.stas@FreeBSD.org> Message-ID: On Sun, Apr 26, 2009 at 4:24 AM, Stanislav Sedov wrote: > On Sun, 26 Apr 2009 00:47:19 -0400 > Luazi mentioned: > >> >> Then on the redboot prompt. >> >> load -b 0x200000 kernel >> g >> >> The rest is in my original post. >> > > Is that CURRENT or STABLE? > > -- > Stanislav Sedov It is CURRENT. From gavin at FreeBSD.org Sun Apr 26 18:52:44 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sun Apr 26 18:52:50 2009 Subject: NSLU2 cannot activate npe In-Reply-To: References: Message-ID: <20090426192012.G34731@ury.york.ac.uk> On Sat, 25 Apr 2009, Luazi wrote: > Hi, > > I got my sources from CVS today and successfully built a kernel for my > slug but the npe is failing to initialize. I have included part of the > boot messages below. Any ideas anyone??? Yes, the hints file is incorrect. Here's a fix (you'll have to apply it by hand though, I don't have time right now to give a real patch) --- src-head/sys/arm/conf/NSLU.hints 3 Aug 2008 07:10:25 -0000 1.1 +++ src-head/sys/arm/conf/NSLU.hints 4 Feb 2009 17:13:31 -0000 @@ -17,22 +17,23 @@ # NPE Hardware Queue Manager hint.ixpqmgr.0.at="ixp0" -# NPE wireless NIC's, requires ixpqmgr +# NPE wired NIC's, requires ixpqmgr hint.npe.0.at="ixp0" -hint.npe.0.mac="A" -hint.npe.0.mii="A" +hint.npe.0.mac="B" +hint.npe.0.mii="B" hint.npe.0.phy=1 # The second MAC isn't used on the NSLU, but it needs to be configured or # we timeout on dhcp packets hint.npe.1.at="ixp0" -hint.npe.1.mac="B" -hint.npe.1.mii="A" -hint.npe.1.phy=0 +#hint.npe.1.mac="B" +#hint.npe.1.mii="A" +#hint.npe.1.phy=0 Gavin From gavin at FreeBSD.org Sun Apr 26 19:01:00 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sun Apr 26 19:01:06 2009 Subject: NSLU2 cannot activate npe In-Reply-To: <20090426192012.G34731@ury.york.ac.uk> References: <20090426192012.G34731@ury.york.ac.uk> Message-ID: <20090426192821.R63028@ury.york.ac.uk> On Sun, 26 Apr 2009, Gavin Atkinson wrote: > On Sat, 25 Apr 2009, Luazi wrote: >> I got my sources from CVS today and successfully built a kernel for my >> slug but the npe is failing to initialize. I have included part of the >> boot messages below. Any ideas anyone??? > > Yes, the hints file is incorrect. Here's a fix (you'll have to apply it by > hand though, I don't have time right now to give a real patch) Should have said: I've got drivers for the RTC, LEDs and buzzer if you want them now, or wait and I'll submit them for inclusion in the tree within the next week or two. Gavin From embedpro at gmail.com Sun Apr 26 19:07:39 2009 From: embedpro at gmail.com (Luazi) Date: Sun Apr 26 19:07:46 2009 Subject: NSLU2 cannot activate npe In-Reply-To: <20090426192821.R63028@ury.york.ac.uk> References: <20090426192012.G34731@ury.york.ac.uk> <20090426192821.R63028@ury.york.ac.uk> Message-ID: On Sun, Apr 26, 2009 at 2:29 PM, Gavin Atkinson wrote: > On Sun, 26 Apr 2009, Gavin Atkinson wrote: >> >> On Sat, 25 Apr 2009, Luazi wrote: >>> >>> I got my sources from CVS today and successfully built a kernel for my >>> slug but the npe is failing to initialize. I have included part of the >>> boot messages below. Any ideas anyone??? >> >> Yes, the hints file is incorrect. ?Here's a fix (you'll have to apply it >> by hand though, I don't have time right now to give a real patch) > > Should have said: I've got drivers for the RTC, LEDs and buzzer if you want > them now, or wait and I'll submit them for inclusion in the tree within the > next week or two. > > Gavin > Thanks. Please send the files if you don't mind. Your work will save me a lot of time. Luazi From embedpro at gmail.com Sun Apr 26 19:45:20 2009 From: embedpro at gmail.com (Luazi) Date: Sun Apr 26 19:45:27 2009 Subject: NSLU2 cannot activate npe In-Reply-To: <20090426192012.G34731@ury.york.ac.uk> References: <20090426192012.G34731@ury.york.ac.uk> Message-ID: On Sun, Apr 26, 2009 at 2:21 PM, Gavin Atkinson wrote: > On Sat, 25 Apr 2009, Luazi wrote: > >> Hi, >> >> I got my sources from CVS today and successfully built a kernel for my >> slug but the npe is failing to initialize. I have included part of the >> boot messages below. Any ideas anyone??? > > Yes, the hints file is incorrect. ?Here's a fix (you'll have to apply it by > hand though, I don't have time right now to give a real patch) > It works now. Thanks. From gavin at FreeBSD.org Tue Apr 28 11:31:06 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Apr 28 11:31:13 2009 Subject: strncmp issue In-Reply-To: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> Message-ID: <1240918262.85945.1.camel@buffy.york.ac.uk> This probably belongs on the -arm list, which I'm CCing. On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: > Hi, > > I am using the freebsd implementation of strncmp for ARM which is an > assembly implementation. > I have a small doubt, when i tested the strncmp by passing the third argument: > 'n' as -1 the return values is '0' instead it should '-1'. > When the third argument to strncmp is as below: > > ret = strncmp("a","b",-1) > > I think the assembly implementation in > src/lib/libc/arm/string/strncmp.S file needs > to be modified to take care of the above condition. > > In the current implementation > /* if ((len - 1) < 0) return 0 */ > subs r2, r2, #1 > movmi r0, #0 > RETc(mi) > > This should be changed to check as below > > /* if ((len ) < 0) return 0 */ > /* Assembly code here */ > > Could anyone help in solving the above issue.? > > Thanks & Regards, > Channagoud > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From mlfbsd at ci0.org Tue Apr 28 11:46:21 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Tue Apr 28 11:46:27 2009 Subject: strncmp issue In-Reply-To: <1240918262.85945.1.camel@buffy.york.ac.uk> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> Message-ID: <20090428115510.GA98699@ci0.org> > On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: > > Hi, > > > > I am using the freebsd implementation of strncmp for ARM which is an > > assembly implementation. > > I have a small doubt, when i tested the strncmp by passing the third argument: > > 'n' as -1 the return values is '0' instead it should '-1'. > > When the third argument to strncmp is as below: > > > > ret = strncmp("a","b",-1) > > > > I think the assembly implementation in > > src/lib/libc/arm/string/strncmp.S file needs > > to be modified to take care of the above condition. > > > > In the current implementation > > /* if ((len - 1) < 0) return 0 */ > > subs r2, r2, #1 > > movmi r0, #0 > > RETc(mi) > > > > This should be changed to check as below > > > > /* if ((len ) < 0) return 0 */ > > /* Assembly code here */ > > > > Could anyone help in solving the above issue.? > > Hi, This shouldn't be an issue, as the second argument of strncmp is unsigned, -1 is not a valid value. Regards, Olivier From mlfbsd at ci0.org Tue Apr 28 12:04:01 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Tue Apr 28 12:04:07 2009 Subject: strncmp issue In-Reply-To: <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> Message-ID: <20090428121255.GA99020@ci0.org> On Tue, Apr 28, 2009 at 05:29:28PM +0530, Channa wrote: > 2009/4/28 Olivier Houchard : > >> On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: > >> > Hi, > >> > > >> > I am using the freebsd implementation of strncmp for ARM which is an > >> > assembly implementation. > >> > I have a small doubt, when i tested the strncmp by passing the third argument: > >> > 'n' as -1 the return values is ?'0' instead it should '-1'. > >> > When the third argument ?to strncmp is as below: > >> > > >> > ret = strncmp("a","b",-1) > >> > > >> > I think the assembly implementation in > >> > src/lib/libc/arm/string/strncmp.S file needs > >> > to be modified to take care of the above condition. > >> > > >> > In the current implementation > >> > /* if ((len - 1) < 0) return 0 */ > >> > ? ? ? ? subs ? ?r2, r2, #1 > >> > ? ? ? ? movmi ? r0, #0 > >> > ? ? ? ? RETc(mi) > >> > > >> > This should be changed to check as below > >> > > >> > /* if ((len ) < 0) return 0 */ > >> > /* Assembly code here */ > >> > > >> > Could anyone help in solving the above issue.? > >> > > > > > Hi, > > > > This shouldn't be an issue, as the second argument of strncmp is unsigned, > > -1 is not a valid value. > > > > Regards, > > > > Olivier > > > Hi, > Thanks for the reply. > True the third argument of strncmp is unsigned but the return value in > the below call to strncmp > > ret = strncmp("a","b",-1) > > is '0' but it should be -1 i suppose. > > Please let me know if anything is wrong. > True, sorry. I'll fix this later today, thanks a lot for reporting ! Regards, Olivier From channa.kad at gmail.com Tue Apr 28 12:32:13 2009 From: channa.kad at gmail.com (Channa) Date: Tue Apr 28 12:32:19 2009 Subject: strncmp issue In-Reply-To: <20090428115510.GA98699@ci0.org> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> Message-ID: <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> 2009/4/28 Olivier Houchard : >> On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: >> > Hi, >> > >> > I am using the freebsd implementation of strncmp for ARM which is an >> > assembly implementation. >> > I have a small doubt, when i tested the strncmp by passing the third argument: >> > 'n' as -1 the return values is ?'0' instead it should '-1'. >> > When the third argument ?to strncmp is as below: >> > >> > ret = strncmp("a","b",-1) >> > >> > I think the assembly implementation in >> > src/lib/libc/arm/string/strncmp.S file needs >> > to be modified to take care of the above condition. >> > >> > In the current implementation >> > /* if ((len - 1) < 0) return 0 */ >> > ? ? ? ? subs ? ?r2, r2, #1 >> > ? ? ? ? movmi ? r0, #0 >> > ? ? ? ? RETc(mi) >> > >> > This should be changed to check as below >> > >> > /* if ((len ) < 0) return 0 */ >> > /* Assembly code here */ >> > >> > Could anyone help in solving the above issue.? >> > > > Hi, > > This shouldn't be an issue, as the second argument of strncmp is unsigned, > -1 is not a valid value. > > Regards, > > Olivier > Hi, Thanks for the reply. True the third argument of strncmp is unsigned but the return value in the below call to strncmp ret = strncmp("a","b",-1) is '0' but it should be -1 i suppose. Please let me know if anything is wrong. Thanks & Regards, Channagoud From channa.kad at gmail.com Tue Apr 28 14:02:16 2009 From: channa.kad at gmail.com (Channa) Date: Tue Apr 28 14:02:23 2009 Subject: strncmp issue In-Reply-To: <20090428121255.GA99020@ci0.org> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> <20090428121255.GA99020@ci0.org> Message-ID: <515c64960904280702s5e29f916s5e03564adf96f9b0@mail.gmail.com> Hi, Thank you very much for your response. I am looking forward for your fix. Thanks & Regards, Channa 2009/4/28 Olivier Houchard : > On Tue, Apr 28, 2009 at 05:29:28PM +0530, Channa wrote: >> 2009/4/28 Olivier Houchard : >> >> On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: >> >> > Hi, >> >> > >> >> > I am using the freebsd implementation of strncmp for ARM which is an >> >> > assembly implementation. >> >> > I have a small doubt, when i tested the strncmp by passing the third argument: >> >> > 'n' as -1 the return values is ?'0' instead it should '-1'. >> >> > When the third argument ?to strncmp is as below: >> >> > >> >> > ret = strncmp("a","b",-1) >> >> > >> >> > I think the assembly implementation in >> >> > src/lib/libc/arm/string/strncmp.S file needs >> >> > to be modified to take care of the above condition. >> >> > >> >> > In the current implementation >> >> > /* if ((len - 1) < 0) return 0 */ >> >> > ? ? ? ? subs ? ?r2, r2, #1 >> >> > ? ? ? ? movmi ? r0, #0 >> >> > ? ? ? ? RETc(mi) >> >> > >> >> > This should be changed to check as below >> >> > >> >> > /* if ((len ) < 0) return 0 */ >> >> > /* Assembly code here */ >> >> > >> >> > Could anyone help in solving the above issue.? >> >> > >> > >> > Hi, >> > >> > This shouldn't be an issue, as the second argument of strncmp is unsigned, >> > -1 is not a valid value. >> > >> > Regards, >> > >> > Olivier >> > >> Hi, >> Thanks for the reply. >> True the third argument of strncmp is unsigned but the return value in >> the below call to strncmp >> >> ret = strncmp("a","b",-1) >> >> is '0' but it should be -1 i suppose. >> >> Please let me know if anything is wrong. >> > > True, sorry. > I'll fix this later today, thanks a lot for reporting ! > > Regards, > > Olivier > From richard at inf.ed.ac.uk Tue Apr 28 14:37:10 2009 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Tue Apr 28 14:37:17 2009 Subject: strncmp issue In-Reply-To: Olivier Houchard's message of Tue, 28 Apr 2009 13:55:10 +0200 Message-ID: <20090428140037.342BB6682CD@macpro.inf.ed.ac.uk> > This shouldn't be an issue, as the second argument of strncmp is unsigned, (you mean third) > -1 is not a valid value. In the presence of a prototype, -1 will be converted to the maximum value of the unsigned type. So strncmp(x, y, -1) should be much the same as strcmp(x, y). -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From imp at bsdimp.com Tue Apr 28 14:45:00 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Apr 28 14:45:07 2009 Subject: strncmp issue In-Reply-To: <1240918262.85945.1.camel@buffy.york.ac.uk> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> Message-ID: <20090428.084207.-1597329356.imp@bsdimp.com> In message: <1240918262.85945.1.camel@buffy.york.ac.uk> Gavin Atkinson writes: : : This probably belongs on the -arm list, which I'm CCing. : : On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: : > Hi, : > : > I am using the freebsd implementation of strncmp for ARM which is an : > assembly implementation. : > I have a small doubt, when i tested the strncmp by passing the third argument: : > 'n' as -1 the return values is '0' instead it should '-1'. : > When the third argument to strncmp is as below: : > : > ret = strncmp("a","b",-1) This is the same as strncnp("a", "b", UMAXINT) because the len argument is "size_t" which is unsigned. : > I think the assembly implementation in : > src/lib/libc/arm/string/strncmp.S file needs : > to be modified to take care of the above condition. : > : > In the current implementation : > /* if ((len - 1) < 0) return 0 */ : > subs r2, r2, #1 : > movmi r0, #0 : > RETc(mi) : > : > This should be changed to check as below : > : > /* if ((len ) < 0) return 0 */ : > /* Assembly code here */ : > : > Could anyone help in solving the above issue.? This is a bug in your code not in strncmp. Warner : > Thanks & Regards, : > Channagoud : > _______________________________________________ : > freebsd-current@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-current : > To unsubscribe, send any mail to "freebsd-current-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 mlfbsd at ci0.org Tue Apr 28 15:02:31 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Tue Apr 28 15:02:42 2009 Subject: strncmp issue In-Reply-To: <20090428.084207.-1597329356.imp@bsdimp.com> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428.084207.-1597329356.imp@bsdimp.com> Message-ID: <20090428151121.GA1389@ci0.org> On Tue, Apr 28, 2009 at 08:42:07AM -0600, M. Warner Losh wrote: > In message: <1240918262.85945.1.camel@buffy.york.ac.uk> > Gavin Atkinson writes: > : > : This probably belongs on the -arm list, which I'm CCing. > : > : On Tue, 2009-04-28 at 15:22 +0530, Channa wrote: > : > Hi, > : > > : > I am using the freebsd implementation of strncmp for ARM which is an > : > assembly implementation. > : > I have a small doubt, when i tested the strncmp by passing the third argument: > : > 'n' as -1 the return values is '0' instead it should '-1'. > : > When the third argument to strncmp is as below: > : > > : > ret = strncmp("a","b",-1) > > This is the same as strncnp("a", "b", UMAXINT) because the len > argument is "size_t" which is unsigned. > > : > I think the assembly implementation in > : > src/lib/libc/arm/string/strncmp.S file needs > : > to be modified to take care of the above condition. > : > > : > In the current implementation > : > /* if ((len - 1) < 0) return 0 */ > : > subs r2, r2, #1 > : > movmi r0, #0 > : > RETc(mi) > : > > : > This should be changed to check as below > : > > : > /* if ((len ) < 0) return 0 */ > : > /* Assembly code here */ > : > > : > Could anyone help in solving the above issue.? > > This is a bug in your code not in strncmp. > > Warner > > Still, strncmp("a", "b", UMAXINT) should not return 0, so if it does, it's a bug. Olivier From cswiger at mac.com Tue Apr 28 18:26:24 2009 From: cswiger at mac.com (Chuck Swiger) Date: Tue Apr 28 18:26:30 2009 Subject: strncmp issue In-Reply-To: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> Message-ID: Hi, Channa-- On Apr 28, 2009, at 2:52 AM, Channa wrote: > I am using the freebsd implementation of strncmp for ARM which is an > assembly implementation. > I have a small doubt, when i tested the strncmp by passing the third > argument: > 'n' as -1 the return values is '0' instead it should '-1'. > When the third argument to strncmp is as below: > > ret = strncmp("a","b",-1) Thanks for the thought, but strncmp() is defined to take a size_t as the third argument, which is unsigned (ie, uint32_t or uint64_t). Presumably when you tell it to compare with length of -1, that will be converted to UINT_MAX or ULONG_MAX, and strncmp() will run until it finds a null somewhere in one the strings and then return the comparison result. (Or get a segfault, perhaps, if you run off the end into unallocated address space.) Regards, -- -Chuck From mlfbsd at ci0.org Tue Apr 28 19:21:07 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Tue Apr 28 19:21:13 2009 Subject: strncmp issue In-Reply-To: <515c64960904280702s5e29f916s5e03564adf96f9b0@mail.gmail.com> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> <20090428121255.GA99020@ci0.org> <515c64960904280702s5e29f916s5e03564adf96f9b0@mail.gmail.com> Message-ID: <20090428193004.GA5465@ci0.org> On Tue, Apr 28, 2009 at 07:32:14PM +0530, Channa wrote: > Hi, > > Thank you very much for your response. > I am looking forward for your fix. > > Thanks & Regards, > Channa > Hi, I just committed a fix to -CURRENT, as rev 191633. It basically just checks if the length is 0, instead of len - 1 < 0. Thanks again, Olivier From channa.kad at gmail.com Wed Apr 29 06:16:25 2009 From: channa.kad at gmail.com (Channa) Date: Wed Apr 29 06:16:31 2009 Subject: strncmp issue In-Reply-To: <20090428193004.GA5465@ci0.org> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> <20090428121255.GA99020@ci0.org> <515c64960904280702s5e29f916s5e03564adf96f9b0@mail.gmail.com> <20090428193004.GA5465@ci0.org> Message-ID: <515c64960904282316k5f3e80cdu1c04a8dc3ab25883@mail.gmail.com> 2009/4/29 Olivier Houchard : > On Tue, Apr 28, 2009 at 07:32:14PM +0530, Channa wrote: >> Hi, >> >> Thank you very much for your response. >> I am looking forward for your fix. >> >> Thanks & Regards, >> Channa >> > > Hi, > > I just committed a fix to -CURRENT, as rev 191633. > It basically just checks if the length is 0, instead of len - 1 < 0. > > Thanks again, > > Olivier > > > Hi Thank you very much. I used your fix and tested again. When i tested as below : TEST 1 : ret = strncmp("a", "L", -1); <----------------- ret is '0' TEST 2: ret = strncmp("1", "2", UINT_MAX); <------ ret is '-1' But since size_t is unsigned int call to strncmp with third argument as -1 should consider third argument as UINT_MAX in TEST 1, but its not happening so. Could you please help me to know what could be the problem. Thanks & Regards, Channa From gavin at FreeBSD.org Wed Apr 29 14:20:02 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed Apr 29 14:20:10 2009 Subject: arm/134092: [patch] NSLU.hints contains wrong hints for on board npe(4) NIC Message-ID: <200904291339.n3TDd0jw095739@buffy.york.ac.uk> >Number: 134092 >Category: arm >Synopsis: [patch] NSLU.hints contains wrong hints for on board npe(4) NIC >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 29 14:20:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Gavin Atkinson >Release: FreeBSD 7.1-STABLE amd64 >Organization: >Environment: System: FreeBSD buffy.york.ac.uk 7.1-STABLE FreeBSD 7.1-STABLE #5: Fri Feb 13 11:25:58 GMT 2009 root@buffy.york.ac.uk:/usr/obj/usr/src/sys/GENERIC amd64 >Description: The NSLU kernel will fail to find the associated PHYs. The attached patch fixes this for both me, and for the user in http://lists.freebsd.org/pipermail/freebsd-arm/2009-April/001649.html The patch also removes the PHY/MAC hints for npe1 - all that is required is the single "at" hint, and not the full config. While here, fix a comment. >How-To-Repeat: Presumably, just try booting on an NSLU2. >Fix: --- NSLU.hints.diff begins here --- Index: src-head/sys/arm/conf/NSLU.hints =================================================================== RCS file: /home/ncvs/src/sys/arm/conf/NSLU.hints,v retrieving revision 1.1 diff -u -r1.1 NSLU.hints --- src-head/sys/arm/conf/NSLU.hints 3 Aug 2008 07:10:25 -0000 1.1 +++ src-head/sys/arm/conf/NSLU.hints 27 Jan 2009 16:06:24 -0000 @@ -17,17 +17,17 @@ # NPE Hardware Queue Manager hint.ixpqmgr.0.at="ixp0" -# NPE wireless NIC's, requires ixpqmgr +# NPE wired NICx's, requires ixpqmgr hint.npe.0.at="ixp0" -hint.npe.0.mac="A" -hint.npe.0.mii="A" +hint.npe.0.mac="B" +hint.npe.0.mii="B" hint.npe.0.phy=1 # The second MAC isn't used on the NSLU, but it needs to be configured or # we timeout on dhcp packets hint.npe.1.at="ixp0" -hint.npe.1.mac="B" -hint.npe.1.mii="A" -hint.npe.1.phy=0 +#hint.npe.1.mac="B" +#hint.npe.1.mii="A" +#hint.npe.1.phy=0 #not yet # RTC --- NSLU.hints.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From mlfbsd at ci0.org Wed Apr 29 22:03:18 2009 From: mlfbsd at ci0.org (Olivier Houchard) Date: Wed Apr 29 22:03:24 2009 Subject: strncmp issue In-Reply-To: <515c64960904282316k5f3e80cdu1c04a8dc3ab25883@mail.gmail.com> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> <20090428121255.GA99020@ci0.org> <515c64960904280702s5e29f916s5e03564adf96f9b0@mail.gmail.com> <20090428193004.GA5465@ci0.org> <515c64960904282316k5f3e80cdu1c04a8dc3ab25883@mail.gmail.com> Message-ID: <20090429221236.GA28784@ci0.org> On Wed, Apr 29, 2009 at 11:46:23AM +0530, Channa wrote: > 2009/4/29 Olivier Houchard : > > On Tue, Apr 28, 2009 at 07:32:14PM +0530, Channa wrote: > >> Hi, > >> > >> Thank you very much for your response. > >> I am looking forward for your fix. > >> > >> Thanks & Regards, > >> Channa > >> > > > > Hi, > > > > I just committed a fix to -CURRENT, as rev 191633. > > It basically just checks if the length is 0, instead of len - 1 < 0. > > > > Thanks again, > > > > Olivier > > > > > > > > Hi > Thank you very much. I used your fix and tested again. > When i tested as below : > > TEST 1 : > ret = strncmp("a", "L", -1); <----------------- ret is '0' > I'm a bit confused here, when I test this I get 21, which is the intended result. Are you sure you weren't still using the old strncmp() ? Regards, Olivier From channa.kad at gmail.com Thu Apr 30 05:21:37 2009 From: channa.kad at gmail.com (Channa) Date: Thu Apr 30 05:21:43 2009 Subject: strncmp issue In-Reply-To: <20090429221236.GA28784@ci0.org> References: <515c64960904280252sc9fe2afy24e8db8ab13b13e4@mail.gmail.com> <1240918262.85945.1.camel@buffy.york.ac.uk> <20090428115510.GA98699@ci0.org> <515c64960904280459p3c2ef8bdu3600157eb0c47bcc@mail.gmail.com> <20090428121255.GA99020@ci0.org> <515c64960904280702s5e29f916s5e03564adf96f9b0@mail.gmail.com> <20090428193004.GA5465@ci0.org> <515c64960904282316k5f3e80cdu1c04a8dc3ab25883@mail.gmail.com> <20090429221236.GA28784@ci0.org> Message-ID: <515c64960904292221v1e927ef2vb3ed2940f76d32cf@mail.gmail.com> 2009/4/30 Olivier Houchard : > On Wed, Apr 29, 2009 at 11:46:23AM +0530, Channa wrote: >> 2009/4/29 Olivier Houchard : >> > On Tue, Apr 28, 2009 at 07:32:14PM +0530, Channa wrote: >> >> Hi, >> >> >> >> Thank you very much for your response. >> >> I am looking forward for your fix. >> >> >> >> Thanks & Regards, >> >> Channa >> >> >> > >> > Hi, >> > >> > I just committed a fix to -CURRENT, as rev 191633. >> > It basically just checks if the length is 0, instead of len - 1 < 0. >> > >> > Thanks again, >> > >> > Olivier >> > >> > >> > >> >> Hi >> Thank you very much. I used your fix and tested again. >> When i tested as below : >> >> TEST 1 : >> ? ret = strncmp("a", "L", -1); ?<----------------- ret is '0' >> > > I'm a bit confused here, when I test this I get 21, which is the intended > result. Are you sure you weren't still using the old strncmp() ? Hi, Yes i am using the latest version of strncmp.S in the CURRENT branch. Sorry there was a typo i tested strncmp as ret = strncmp("a","b",-1) <------ ret value is still '0' I am still getting the return value as zero, it should be -1. Thanks & Regards, Channa From imp at bsdimp.com Thu Apr 30 06:11:50 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Apr 30 06:12:14 2009 Subject: strncmp issue In-Reply-To: <515c64960904292221v1e927ef2vb3ed2940f76d32cf@mail.gmail.com> References: <515c64960904282316k5f3e80cdu1c04a8dc3ab25883@mail.gmail.com> <20090429221236.GA28784@ci0.org> <515c64960904292221v1e927ef2vb3ed2940f76d32cf@mail.gmail.com> Message-ID: <20090430.000846.1484329326.imp@bsdimp.com> In message: <515c64960904292221v1e927ef2vb3ed2940f76d32cf@mail.gmail.com> Channa writes: : 2009/4/30 Olivier Houchard : : > On Wed, Apr 29, 2009 at 11:46:23AM +0530, Channa wrote: : >> 2009/4/29 Olivier Houchard : : >> > On Tue, Apr 28, 2009 at 07:32:14PM +0530, Channa wrote: : >> >> Hi, : >> >> : >> >> Thank you very much for your response. : >> >> I am looking forward for your fix. : >> >> : >> >> Thanks & Regards, : >> >> Channa : >> >> : >> > : >> > Hi, : >> > : >> > I just committed a fix to -CURRENT, as rev 191633. : >> > It basically just checks if the length is 0, instead of len - 1 < 0. : >> > : >> > Thanks again, : >> > : >> > Olivier : >> > : >> > : >> > : >> : >> Hi : >> Thank you very much. I used your fix and tested again. : >> When i tested as below : : >> : >> TEST 1 : : >> ? ret = strncmp("a", "L", -1); ?<----------------- ret is '0' : >> : > : > I'm a bit confused here, when I test this I get 21, which is the intended : > result. Are you sure you weren't still using the old strncmp() ? : : Hi, : Yes i am using the latest version of strncmp.S in the CURRENT branch. : Sorry there was a typo i tested strncmp as : : ret = strncmp("a","b",-1) <------ ret value is still '0' : : I am still getting the return value as zero, it should be -1. Yes. We should get the following results: strncmp("a", "b", 0); 0 strncmp("a", "b", *); < 0 where * is any other number :) Warner From tinguely at casselton.net Thu Apr 30 17:06:02 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Thu Apr 30 17:06:09 2009 Subject: strncmp issue In-Reply-To: <20090430.000846.1484329326.imp@bsdimp.com> Message-ID: <200904301705.n3UH5wg2057498@casselton.net> > Yes. We should get the following results: > > strncmp("a", "b", 0); 0 > strncmp("a", "b", *); < 0 > > where * is any other number :) > > Warner ENTRY(strncmp) /* if (len == 0) return 0 */ cmp r2, #0 moveq r0, #0 RETeq /* ip == last src address to compare */ add ip, r0, r2 1: ldrb r2, [r0], #1 ldrb r3, [r1], #1 cmp ip, r0 - cmpcs r2, #1 + beq 2f + cmp r2, #1 cmpcs r2, r3 beq 1b +2: sub r0, r2, r3 RET also ip < r0 if r2 = (unsigned int) -1 using 32 bit math. so original loop will terminate and compare the first characters. For example strncmp("ab", "aa", -1) will result is 0. I sent Olivier a couple patches, both wrong. Again, sorry for all the noise. The above code, though, should work in all cases. strncmp("b", "a", 0) result is 0 strncmp("abcdef", "abcdef", n) result is 0 strncmp("abcde", "abcdef", n) 0 if 0 <= n < 6 neg if n < 0 or n > 5 strncmp("abcdef", "abcde", n) 0 if 0 <= n < 6 pos if n < 0 or n > 5 The "beq" will break out of the loop if we give a count <= the string length the first arguement. The next cmp looks for the NULL byte, and the last cmp checks the characters in the strings. --Mark.